Anda di halaman 1dari 23

METODOS DEL DESARROLLO DE SISTEMA DE INFORMACION Mtodos de Desarrollo de Sistemas Son Pautas de desarrollo brindado por los modelos

de ciclos de vida, los cuales estn constituidos por las siguientes etapas: Especificacin de requerimientos: Se realizan entrevistas con el usuario identificando los requerimientos y necesidades del usuario. Anlisis: Modela los requerimientos del usuario. Diseo: Se modela la solucin del sistema, teniendo en cuenta el ambiente de implementacin a utilizar, por ejemplo, si el sistema es centralizado o distribuido, la base de datos a utilizar, lenguaje de programacin, performance deseada, etc. Implementacin: Dado el lenguaje de programacin elegido se implementa el sistema. Testeo: En esta etapa se verifica y valida el sistema teniendo en cuenta algunos criterios determinados por el grupo correspondiente. Mantenimiento: Es la etapa ms difcil de desarrollo del sistema, actualiza y modifica el sistema si surgen nuevos requerimientos. METODOLOGIAS DEL DESARROLLO DE SISTEMAS DE INFORMACION Son mtodos que indican cmo hacer ms eficiente el desarrollo de sistemas de informacin. Para ello suelen estructurar en fases la vida de dichos sistemas con el fin de facilitar su planificacin, desarrollo y mantenimiento. Las metodologas de desarrollo de sistemas deben definir: objetivos, fases, tareas, productos y responsables, necesarios para la correcta realizacin del proceso y su seguimiento. Los principales objetivos de una metodologa de desarrollo son:

y y y y y y

Asegurar la uniformidad y calidad tanto del desarrollo como del sistema en s. Satisfacer las necesidades de los usuarios del sistema. Conseguir un mayor nivel de rendimiento y eficiencia del personal asignado al desarrollo. Ajustarse a los plazos y costes previstos en la planificacin. Generar de forma adecuada la documentacin asociada a los sistemas. Facilitar el mantenimiento posterior de los sistemas.

METODO DE CASCADA PURA En un modelo en cascada, un proyecto progresa a travs de una secuencia ordenada de pasos partiendo de la especificacin de requerimientos hasta el mantenimiento del mismo. El mtodo realiza una revisin al final de cada etapa para determinar si est preparado para pasar a la siguiente etapa, por ejemplo, desde el anlisis de requerimientos hasta el diseo. Cuando la revisin determina que el proyecto no est listo pasar a la siguiente, permanece en la etapa actual hasta que est preparado. El modelo en cascada est dirigido por documentos. Ayuda a localizar errores en las primeras etapas del proyecto a un bajo costo. Ayuda a minimizar los gastos de la planificacin porque permite realizarla sin planificacin porque permite realizarla sin problemas. Funciona especialmente bien si se dispone de personal poco cualificado o dispone de personal poco cualificado o inexperto, porque presenta el proyecto inexperto, porque presenta el proyecto con una estructura que ayuda a minimizar con una estructura el esfuerzo intil. En resumen, los inconvenientes del venerado modelo en cascada hacen que sea, a menudo, un modelo poco apropiado para un proyecto de desarrollo rpido. Incluso en los casos en los que las ventajas del modelo en cascada pura superan los inconvenientes, los modelos de cascada modificada (con retroceso) pueden funcionar mejor. Las desventajas del modelo se centran en las dificultades para especificar claramente los requerimientos al comienzo del proyecto, antes de que se realice ningn trabajo de diseo y antes de escribir ningn cdigo. No proporciona resultados tangibles en forma de software hasta el final del ciclo de forma de software del ciclo de vida de Algunas herramientas, mtodos y actividades que abarcan varias etapas de la cascada; estas actividades son difciles de ajustar en las etapas discontinuas del modelo para un proyecto de desarrollo rpido, el modelo en cascada puede suponer una cantidad excesiva de documentacin. El modelo genera pocos signos visibles de progreso hasta el final. Esto puede dar la impresin de un desarrollo lento, existe la incertidumbre de los clientes si sus proyectos sern entregados a tiempo. METODO ESPIRAL Es un modelo de ciclo de vida orientado a riesgos que divide un proyecto software en mini-proyectos. Cada mini proyecto se centra en uno o ms riesgos importantes hasta que todos estn controlados. Despus de controlar todos los riesgos ms importantes, el modelo en espiral finaliza del mismo modo que el ciclo de vida en cascada. Mtodo Desarrollo en Espiral Funcionamiento: Se parte de una escala pequea en medio de la espiral, se localizan los riesgos, se genera un plan para manejar los riesgos, y a continuacin se establece una aproximacin a la siguiente interaccin. Cada iteracin supone que el proyecto pasa a una escala superior. Se avanza un nivel en el Espiral, se comprueba que se tiene lo que se desea, y despus se comienza a trabajar en el siguiente nivel:

Con cada iteracin a travs del espiral se construye sucesivas versiones de software cada vez ms completas. En cada bucle alrededor del espiral, la culminacin del anlisis de riesgo resulta una decisin de seguir o no seguir. Cada interaccin en el mtodo espiral lleva consigo los seis pasos que a continuacin se nombran: Determinar objetivos, alternativas y lmites, Identificar y resolver riesgos, Evaluar alternativas, Generar las entregas de esa iteracin, y comprobar que son correctas. En el modelo en espiral, las primeras iteraciones son las menos costosas. Supone menos gasto desarrollar el concepto de operacin que realizar el desarrollo de los requerimientos, y tambin es menos costoso desarrollar los requerimientos que llevar a cabo el desarrollo del diseo, la implementacin del producto y la prueba del mismo. En cada Cuadrante del Mtodo espiral se realiza las siguientes actividades: Planificacin: Determinacin de objetivos, alternativas, restricciones, y elaboracin del plan de desarrollo para el ciclo actual. Anlisis de Riesgos: Evaluacin de las alternativas, identificacin y resolucin de riesgos. Se decide si se sigue o no con el proyecto Ingeniera: Desarrollo del producto siguiendo un modelo: del ciclo de vida o cascada, prototipo, etc. Evaluacin por el cliente, Valoracin de resultados. METODO DE CODIFICAR Y CORREGIR (Code-and-fix) Es un modelo poco til, pero sin embargo bastante comn Se puede tener una especificacin formal, o no tenerla Si no se ha utilizado formalmente un mtodo, probablemente ya se est usando el mtodo Codificar y Corregir en forma intuitiva Cuando se utiliza ste mtodo se empieza con una idea general de lo que se necesita construir, Se utiliza cualquier combinacin de diseo, cdigo, depuracin y mtodos de prueba no formales que sirven hasta que se tiene el producto listo para entregarlo. Ventajas: No conlleva ninguna gestin; no se pierde tiempo en la planificacin, en la documentacin, en el control de calidad, en el cumplimiento de los estndares, o en cualquier otra actividad que no sea codificacin pura. Como se pasa directamente a codificar, se pueden mostrar inmediatamente indicios de progreso. Requiere poca experiencia: cualquier persona que haya escrito alguna vez un programa est familiarizada con ste modelo. Para proyectos pequeos que se intentan liquidar en un tiempo breve, o para modelos como programas de demostracin o prototipos desechables, el modelo codificar y corregir puede ser til. Desventajas:

El modelo resulta peligroso para otro tipo de proyectos que no sean pequeos. Puede que no suponga gestin alguna, pero tampoco ofrece medios de evaluacin del progreso. No proporciona medios de evaluacin de la calidad o de identificacin de riesgos. Si al llevar tres cuartas partes de la codificacin descubre que el diseo es incorrecto, no hay otra solucin que desechar el trabajo y comenzar de nuevo. METODO PROTOTIPO Este mtodo hace que el usuario participe de manera ms directa en la experiencia de anlisis y diseo que cualquiera de los ya presentados. La construccin de prototipos es muy eficaz bajo las circunstancias correctas. Sin embargo, al igual que los otros mtodos, el mtodo es til slo si se emplea en el momento adecuado y en la forma apropiada. Qu es un prototipo? El prototipo es un sistema que funciona, no solo una idea en el papel, desarrollado con la finalidad de probar ideas y suposiciones relacionadas con el nuevo sistema. Al igual que cualquier sistema basado en computadora, est constituido por software que acepta entradas, realiza clculos, produce informacin ya sea impresa o presentada en una pantalla, o que lleva a cabo otras actividades significativas. Es la primera versin, o iteracin, de un sistema de informacin. Lo usuarios evalan el diseo y la informacin generada por el sistema. Lo anterior slo puede hacerse con efectividad si los datos utilizados, al igual que las situaciones, son reales. Por otra parte, deben esperarse cambios a medida que el sistema es utilizado. Razones para desarrollar prototipos de sistemas: Los requerimientos de informacin no siempre estn bien definidos. Es probable que los usuarios conozcan slo ciertas reas de la empresa donde se necesiten mejoras o cambios en los procedimientos actuales. Tambin es posible que reconozcan la necesidad de tener mejor informacin para administrar ciertas actividades pero que no estn seguros cual de esta informacin ser la adecuada. Los requerimientos del usuario pueden ser demasiado vagos aun al formular el diseo. En otros casos, es probable que una investigacin de sistemas bien llevada necesite del desarrollo de nueva tecnologa. Los prototipos permiten evaluar situaciones extraordinarias donde los encargados de disear e implantar sistemas no tienen informacin ni experiencia, o tambin donde existen situaciones de riesgo y costo elevados, y aquellas donde el diseo propuesto es novedoso y an no se demuestra es la factibilidad de que los vendedores enven ordenes de pedido al sistema de cmputo de la compaa desde el sitio donde efectan la operacin por medio de terminales porttiles enlazadas a telfonos pblicos. Para probar el concepto los administradores y encargados de sistemas pueden optar por construir una versin en pequea escala del software, adquirir unas cuantas terminales y seleccionar un grupo de vendedores. El prototipo proporcionar informacin preliminar sobre la funcionalidad del concepto. El prototipo es, en realidad, un modelo piloto o de prueba, en general, los analistas de sistemas encuentran que los prototipos tienen mayor utilidad bajo las siguientes condiciones:

Los encargados de disear e implantar sistemas nunca han desarrollado uno con las caractersticas del sistema propuesto. Se conoce slo una parte de las caractersticas esenciales del sistema; las dems no son identificables a pesar de un cuidadoso anlisis de requerimientos. La experiencia con el uso del sistema aadir una lista significativa de requerimientos que el sistema debe satisfacer.

Las diferentes versiones del sistema evolucionan con la experiencia al igual que el desarrollo adicional y el refinamiento de sus caractersticas. Los usuarios del sistema participan en el proceso de desarrollo.

Los pasos a seguir en el proceso de desarrollo de prototipos son los siguientes: Identificar los requerimientos de informacin que el usuario conoce junto con las caractersticas necesarias del sistema. Desarrollar un prototipo que funcione. Utilizar el prototipo anotando las necesidades de cambios y mejoras. Esto expande la lista de los requerimientos de sistemas conocidos. Revisar el prototipo con base en la informacin obtenida a travs de la experiencia del usuario. Repetir los pasos anteriores las veces que sea necesario hasta obtener5 un sistema satisfactorio. l analista debe de reunirse con los usuarios una o dos veces con la finalidad de identificar los requerimientos. El resultado de estas reuniones forma la base para la construccin del prototipo. El desarrollo de un prototipo que funcione es responsabilidad del analista de sistemas, cuando el analista y el usuario deciden que cuentan ya con la suficiente informacin proveniente del proceso de construccin del prototipo, determinan cmo satisfacer los requerimientos ya identificados. En general se opta por una de las siguientes opciones: Volver a desarrollar el prototipo. Esta alternativa quiz signifique volver a programar por completo, empezando desde el principio. Implantar el prototipo como sistema terminado La eficiencia en el funcionamiento junto con los mtodos para interactuar con el usuario son suficientes; esto permite utilizar el sistema tol como est. Abandonar el proyecto. En este caso el prototipo ha proporcionado informacin suficiente para demostrar que no es posible desarrollar el sistema para satisfacer los objetivos deseados dentro del marco de la tecnologa existente o de lineamientos econmicos u operacionales. Iniciar otra serie de construccin de prototipos. La informacin ganada con la experiencia sugiere ya sea un enfoque totalmente distinto o caractersticas contrastantes. Cada una de estas opciones se considera como un xito en el proceso de la construccin de prototipos. Mtodos para el desarrollo de prototipos Con los prototipos la velocidad de desarrollo es ms importante que la eficiencia en el procesamiento. Un sistema prototipo se construye con rapidez, los sistemas prototipo pueden desarrollarse con mtodos y lenguajes de programacin convencionales, quiz falten los controles de entrada y procesamiento y, en general, la documentacin del sistema es un punto que suele evitarse. Lo importante es ensayar ideas y generar hiptesis relacionadas con los requerimientos y que la eficiencia y perfeccin alcanzadas. La industria de computadora busca continuamente generadores de aplicaciones, programas que sirven para generar otros programas, para apoyar los esfuerzos de la construccin de prototipos. En algunos casos, aquellos donde el sistema ser utilizado con poca frecuencia, el prototipo puede, de hecho, convertirse en el sistema terminado. METODO DE ANALISIS Y DISEO ESTRUCTURADO

Muchos especialistas en sistemas de informacin reconocen la dificultad de comprender de manera completa sistemas grandes y complejos. El mtodo de desarrollo del anlisis estructurado tiene como finalidad superar sa dificultad por medio de 1) la divisin del sistema en componentes y 2) la construccin de un modelo del sistema. El mtodo incorpora elementos tanto de anlisis como de diseo. Qu es el anlisis estructurado? El anlisis estructurado concentra en especificar lo que se requiere que haga el sistema o la aplicacin. No se establece cmo se cumplirn los requerimientos o la forma en que implantar la aplicacin. Ms bien permite que las personas observen los elementos lgicos (lo que har el sistema) separados de los componentes fsicos (computadoras, terminales, sistemas de almacenamiento, etc.) Despus de esto se puede desarrollar un diseo fsico eficiente para la situacin donde ser utilizado. Elementos del anlisis estructurado: Los elementos esenciales son smbolos grficos, diagramas de flujo de datos y diccionario centralizado de datos. Descripcin grfica Una de las formas de describir un sistema es preparar un bosquejo que seale sus caractersticas, identifique la funcin para la que sirve e indique cmo ste interacta con otros elementos, entre otras cosas. Sin embargo, describir de esta manera un sistema grande es un proceso tedioso y propenso a errores ya que es fcil omitir algn detalle o dar una explicacin que quiz los dems no entiendan. En lugar de las palabras el anlisis estructurado utiliza smbolos, o conos, para crear un modelo grfico del sistema. Los modelos de este tipo muestran los detalles del sistema. Si se seleccionan los smbolos y notacin correctos entonces casi cualquier persona puede seguir la forma en que los componentes se acomodarn entre si para formar el sistema. El diagrama lgico de flujo de datos muestra las fuentes y destinos de los datos, identifica y da nombre a los procesos que se llevan a cabo, identifica y da nombre a los grupos de datos que relacionan una funcin con otra y seala los almacenes de datos a los que se tiene acceso. Diagrama de flujo de datos: El modelo del sistema recibe el nombre de diagrama de flujo de datos (DFD). La descripcin completa de un sistema est formada por un conjunto de diagramas de flujo de datos. Para desarrollar una descripcin del sistema por el mtodo de anlisis estructurado se sigue un proceso descendente (TOP-down). El modelo original se detalla en diagramas de bajo nivel que muestran caractersticas adicionales del sistema. Cada proceso puede desglosarse en diagramas de flujo de datos cada vez ms detallados. Esta secuencia se repite hasta que se obtienen suficientes detalles que permiten al analista comprender en su totalidad la parte del sistema que se encuentra bajo investigacin. Diccionario de datos: Todas las definiciones de los elementos en el sistema (flujo de datos, procesos y almacenes de datos) estn descritos en forma detallada en el diccionario de datos. Si algn miembro del equipo encargado del proyecto desea saber alguna definicin del nombre de un dato o el contenido particular de un flujo de datos, esta informacin debe encontrarse disponible en el diccionario de datos. Que es el diseo estructurado Se enfoca en el desarrollo de especificaciones del software. La meta del diseo estructurado es crear programas formados por mdulos independientes unos de otros desde el punto de vista funcional. El diseo estructurado es una tcnica especfica para el diseo de programas y no un mtodo de diseo de comprensin. Esta tcnica conduce a la especificacin de mdulos de programa que son funcionalmente

independientes. La herramienta fundamental del diseo estructurado es el diagrama estructurado, los cuales son de naturaleza grfica y evitan cualquier referencia relacionada con el hardware o detalles fsicos. Su finalidad no es mostrar la lgica de los programas. Los diagramas estructurados describen la interaccin entre mdulos independientes junto con los datos que un mdulo pasa a otro cuando interacciona con l. Estas especificaciones funcionales para los mdulos se proporcionan a los programadores antes que d comienzo la fase de escritura de cdigo. Empleo del Anlisis estructurado con otros mtodos de desarrollo: El anlisis estructurado se combina, con bastante frecuencia, con el mtodo ya presentado de ciclo de vida clsico de desarrollo de sistemas. Por ejemplo, los analistas pueden optar ms de flujo de datos como una forma para documentar las relaciones entre componentes durante la investigacin detallada de algn sistema existente, Asimismo, se puede definir los archivos y datos en un diccionario centralizado de datos de acuerdo con las reglas de anlisis estructurado. Sin embargo muchas organizaciones optan por no utilizar este mtodo de desarrollo. Por ejemplo, los analistas deciden con frecuencia que el desarrollo de diagramas y esquemas es una tarea que consume mucho tiempo, sobre todo si el sistema es grande y complejo. (Es comn que los diagramas tengan que dibujarse una y otra vez conforme se adquiere nueva informacin). Como se ver ms adelante, se han desarrollado herramientas asistidas por computadora para superar este problema. Otros analistas sealan que los elementos que faltan, tales como las personas y los procedimientos de control, son parte del sistema mismo y no pueden omitirse en la descripcin de ste. Ms adelante se considerar este aspecto tan importante. Anlisis de Sistemas (Resumen del grupo de lecturas del curso de Anlisis y diseo de sistemas I) INDICE Tema Pgina Investigacin Preliminar................................................................................ 03 Prueba de Factibilidad Factibilidad Tcnica Factibilidad Operacional Factibilidad Econmica Determinacin de requerimientos.................................................................. 06 Determinacin de procesos Determinacin de datos Anlisis del flujo de los datos......................................................................... 10 Anticipacin de requerimientos Investigacin de requerimientos

Especificacin de requerimientos Diagramas de Flujo de datos........................................................................... 10 Primer nivel del DFD Expansin de los procesos a diagramas de mayor nivel Reglas adicionales para el dibujo de DFD Diccionario de Datos...................................................................................... 14 Importancia del diccionario Contenido de un registro del diccionario Notacin empleada en el Diccionario de datos Comentario final............................................................................................ 16 Cualquiera que sea la necesidad de informacin de una organizacin, siempre se debe fundamentar en una solicitud (por escrito y firmada) por parte de alguna parte involucrada en el mismo, sea este un usuario, analista, gerente, encargado de proyectos, etc. En ella se debe establecer muy claramente los siguientes puntos:

y y y y y y y

Cul es el problema? Detalles del problema Importancia del problema Cul cree el solicitante que puede ser la solucin al mismo? En qu forma ayuda un sistema de informacin? Breve resumen de los reportes usados y funciones que se realizan Qu otras personas tienen conocimiento del problema y que se pueden contactar?

Esta propuesta debe ser analizada por un comit (o su equivalente), que determina lo urgente de poner a andar los medios necesarios para tratar resolver la situacin. Investigacin Preliminar Por cualquiera que sea la estrategia mediante la cual se va a desarrollar el sistema (SDLC, prototipos, anlisis estructurado, o por una combinacin de stos) primero es necesario revisar la solicitud del proyecto. La eleccin de una estrategia es secundario, lo importante es determinar si la solicitud merece o no la inversin de recursos en un proyecto de sistemas de informacin. El tiempo estimado es aproximadamente entre 4 a 6 seis das. Ambito del estudio

La finalidad de la investigacin preliminar es evaluar las solicitudes de proyectos. No es un estudio de diseo ni tampoco incluye la recoleccin de detalles para describir el sistema de la empresa. Ms bien, es la reunin de informacin que permita a los miembros del comit evaluar los mritos de la solicitud de proyecto y emitir un juicio, con conocimiento de causa, con respecto a la factibilidad del proyecto propuesto Durante la investigacin preliminar se deben satisfacer los siguientes objetivos:
y Aclarar y comprender la solicitud del proyecto: y Determinar el tamao del proyecto y Evaluar los costos y beneficios de las diversas opciones y Determinar la factibilidad tcnica y operacional de las diferentes alternativas y Reportar los hallazgos a la administracin y formular recomendaciones que esbocen el criterio de aceptacin o rechazo del proyecto.

Ahora bien, los datos recogidos durante la investigacin se renen por medio de principalmente la revisin de documentos la conduccin de entrevistas. El resumen de cada entrevistado debe indicar:

y y y y y

Resumen de las funciones que realiza Clasificacin de los problemas identificados Anlisis de las mejoras potenciales Cambios propuestos y su impacto Anlisis de la relacin entre los cambios propuestos y los planes existentes para la organizacin y el departamento

Prueba de factibilidad del proyecto La investigacin preliminar examina la factibilidad del proyecto, la posibilidad de que el sistema sea de utilidad para la organizacin; a saber en tres reas:

Factibilidad operacional: se refiere al hecho de que si trabajar o no el sistema si este se llega a desarrollar, preguntas claves aqu son: Existe apoyo suficiente para el proyecto por parte de la administracin?, Y por parte de los usuarios? Los mtodos que actualmente se usan en la empresa, son aceptados por los usuarios? Los usuarios han participado en la planeacin y desarrollo del proyecto?, Cmo lo han hecho? El sistema propuesto causar perjuicios? Producir resultados pobres en alguna rea? Se perder control en alguna rea especfica?

y y y y y

y y y y y y

Se perder la facilidad de acceso a la informacin? La productividad de los empleados ser menor despus de instalado el sistema? Los clientes se vern afectados por la implantacin? Factibilidad Tcnica: Existe o se puede adquirir la tecnologa necesaria para realizar lo que se pide? El equipo propuesto tiene la capacidad tcnica para soportar todos los datos requeridos para usar el nuevo sistema? El sistema propuesto ofrecer respuestas adecuadas a las peticiones sin importar el nmero y ubicacin de los usuarios? Si se desarrolla el sistema, se puede crecer con facilidad? Existen garantas tcnicas de exactitud, confiabilidad, facilidad de acceso y seguridad de los datos? Factibilidad financiera y econmica: un sistema puede ser factible desde el punto de vista tcnico y operacional, pero sino es factible econmicamente para la organizacin no puede ser implantado. Las cuestiones econmicas y financieras formuladas por los analistas deben incluir El costo de llevar a cabo la investigacin completa de sistemas El costo del hardware y software para la aplicacin Beneficios en la forma de reduccin de costos o de menos errores costosos El costo si nada sucede (si el proyecto no se lleva a cabo)

y y y

y y y y

Aprobacin de la solicitud No todos los proyectos solicitados son factibles. Algunas organizaciones reciben tantas solicitudes de sus empleados que solo es posible atender unas cuantas. Sin embargo, aquellos casos que son deseables y factibles deben incorporarse en los planes de desarrollo de la organizacin, para ser atendidos lo ms rpido posible, segn los recursos de la organizacin. Dentro de los beneficios que el sistema podra brindar tenemos:

y y y y y

Obtencin de informacin no disponible actualmente Elaboracin ms oportuna de la informacin Mejoras en las operaciones de la organizacin Posibilidades de efectuar clculos o estimaciones que actualmente no es posible Reduccin de costo

y y y

Obtencin de una posicin competitiva dentro del mercado Mejoras en la toma de decisiones. Mejoras en la imagen, atencin, seguridad, etc.

La siguiente tabla detalla una lista de actividades que se desarrollan en esta etapa, acompaada de los productos generados por cada actividad Lista de Actividades Productos Lista de actividades de esta etapa Programacin de la lista de actividades Programacin de las entrevistas 2. Recopilacin de datos Informes y diagnsticos de soluciones Archivo de proyecto e ndice Programacin actualizada en entrevistas con base en modificaciones que sufra el producto de la actividad Resumen de las entrevistas 4. Anlisis de los datos Beneficios esperados Entradas y salidas claves 3. Realizacin de las entrevistas Flujos de datos Organigramas Costos previos Evaluacin econmica 5. Evaluacin de la necesidad de realizar la prxima etapa Plan de etapas restantes Resumen administrativo 6. preparacin de plan de trabajo para la siguiente etapa Lista de actividades de la siguiente etapa Programacin de la lista de actividades de la prxima

1. Planeacin de la etapa

etapa (con estimacin, fecha calendario y personas) 7.Revisin de los resultados con el comit de decisin Solo despus de que un analista comprende en su totalidad el sistema, est en posicin de analizarlo y generar recomendaciones para el diseo de sistemas. En el estudio de factibilidad se trata de determinar si realmente existe un problema, cules son sus caractersticas y en trminos generales las posibles soluciones y la factibilidad tcnica, operacional y econmica de aplicar dichas soluciones. Pero nada ms. Determinacin de requerimientos Un requerimiento es una caracterstica necesaria que deber poseer el nuevo sistema. Por otra parte, la determinacin de requerimientos es el estudio de un sistema para comprender cmo trabaja y dnde es necesario efectuar mejoras. Ahora bien, existen tres formas (= actividades) de determinar de requerimientos, a saber

Anticipacin de requerimientos: prever las caractersticas del nuevo sistema con base en experiencia previa. Investigacin de requerimientos: actividad ms importante del anlisis de sistemas. Es el estudio y documentacin del sistema actual usando para ellos tcnicas de para hallar hechos, anlisis de flujo de datos y anlisis de decisin. Es aqu donde aplicamos entrevistas, cuestionarios, observacin y revisin de documentacin entre otros. Especificacin de requerimientos: los datos obtenidos durante la recopilacin de hechos se analizan para determinar las especificaciones de los requerimientos, es decir, la descripcin de las caractersticas del nuevo sistema. Esta actividad tiene tres partes relacionadas entre s, a saber: Anlisis de datos basados en hechos reales Identificacin de requerimientos esenciales Seleccin de estrategias para satisfacer los requerimientos

y y y

Todo sistema de informacin posee un conjunto de requerimientos bsicos y un conjunto de requerimientos especficos dependiendo si el sistema ser de soporte para transacciones o para la toma de decisiones. En lo que resta del presente documento se elaborar un grupo de preguntas que al drseles respuesta presentarn un conjunto de hechos de los que posteriormente se obtendr una especificacin de requerimientos lo ms apegada posible a las necesidades de cualquier organizacin.

Requerimientos bsicos: los analistas estructuran su investigacin al buscar respuestas a las siguientes cuatro preguntas: Cul es el proceso bsico de la empresa?

y y y

Qu datos utiliza o produce este proceso? Cules son los lmites impuestos por el tiempo y la carga de trabajo? Qu controles de desempeo utiliza?

Son esas las preguntas que tienen que tener una respuesta concreta al tener terminada la fase de investigacin de requerimientos. Siempre se debe comenzar con lo bsico. Los analistas hacen preguntas que cuando reciben respuesta, proporcionan antecedentes sobre detalles fundamentales relacionados con el sistema y que sirven para describirlo. Las siguientes preguntas son de utilidad para adquirir la comprensin necesaria:

y y y y y y y

Cul es la finalidad de la actividad dentro de la empresa? Qu pasos se siguen para realizarla? Dnde se realizan estos pasos? Quines los realizan? Cunto tiempo tardan en efectuarlos? Con cunta frecuencia lo hacen? Quines emplean la informacin resultante?

Respuestas concisas a estas preguntas proporcionan un conocimiento amplio de una actividad en particular y muestra tambin su objetivo. Pero analista no se detiene ah, todava no existe informacin para comprender en su totalidad la actividad; ms bien lo que se tiene son los antecedentes que permiten a los analistas formular preguntas ms detalladas. Durante esta, debemos identificar muy claramente los siguientes elementos:

y y y y y

procesos flujos de datos entre procesos datos de cada flujo de datos almacenes de datos datos de los almacenes de datos.

Para ello el cuestionario que se aplica debe requerir la siguiente informacin:

y y y

nombre de la entidad nombre los campos descripcin

y y y y

fuente y sensibilidad (= seguridad) valor o importancia de los datos relaciones de los campos y entidades Criterio de retencin y almacenamiento.

Preguntas clsicas para una determinacin de requerimientos:

y y

Preguntas generales: Cuntos empleados laboran para la organizacin en el rea(s) que se pretende desarrollar el sistema; o sea, cuntos tienen relacin directa con el proyecto que se est investigando. ? Cules son las personas claves en el sistema? Por qu son importantes? Existen obstculos o influencias de tipo poltico que afectan la eficiencia del sistema? Existen manuales de procedimientos, polticas o lineamientos de desempeo documentados oficial o no oficialmente?. Si los hay, Se cumplen en forma cabal en el 100% de las ocasiones?, es decir, se respetan dichos procedimientos? Existen mtodos para evadir el sistema?, Por qu se presentan? Qu reas necesitan un control especfico? Qu criterios se emplean para medir y evaluar el desempeo?

y y y

y y y

Por otra parte:

y y

Existen actividades que considere podran mejorarse?, De qu manera? Tiene alguna idea de actividades que podran implementarse para mejorar el rendimiento del sistema en general? Determinacin de procesos: Cules son las principales actividades que se realizan en la organizacin y que tienen relacin con el proceso que se est modelando? Descripcin de cada proceso identificado Qu es lo que da inicio a la actividad? Cul es el objetivo de la misma? Cunto tiempo se tarda en realizarla? Qu retrasos ocurren o pueden ocurrir?

y y

y y y y y

y y

Qu mtodos se emplean para medir y evaluar el desempeo de esta actividad? Se toman precauciones especficas de seguridad para la proteccin contra alguna actividad impropia que se pudiera presentar? Qu tan frecuente es el ciclo con el que se desarrolla dicha actividad? De acuerdo al ciclo con el que se presenta la actividad, Cul es el volumen de informacin que aqu se procesa? Qu pasos, sub-procesos, o funciones constituyen la actividad? (describir la actividad paso a paso) Existe algn tipo de control desarrollado en el proceso en cuestin? Determinacin de datos (flujos y contenido de los flujos) - hacer la pregunta por cada proceso o actividad identificada De dnde proviene la informacin que se utiliza en esta actividad? (fuentes) Cules son especficamente los datos que recibe esta actividad? (dts de flujos) De qu manera ingresan a este proceso? (flujos) Qu tablas de referencia y diagramas u otros datos intervienen en la actividad? (documentacin involucrada) Qu informacin se genera en esta actividad? (producto de la actividad) El resultado identificado anteriormente producto de los datos que se procesan Hacia qu o quin van dirigidos? -persona o entidad- (destinos) Con qu finalidad la utilizan? Cules datos se conservan o almacenan en este proceso? Y en qu forma quedan almacenados? Existe informacin que se genera pero que no es utilizada nunca por nadie? (partes extraas) Para cada dato identificado: Qu formato posee cada dato que interviene en esta actividad? Para qu es usado? Se interpone algn tipo de seguridad para la verificacin de la veracidad del dato en mencin? Qu tan importante es dicho dato? Por cunto tiempo es importante mantener el dato en el sistema?

y y

y y y

y y y y

y y

y y y y y y y y y

Por otra parte si el sistema que se est investigando es para el soporte de decisiones se deben, adems de las anteriores, formular otras preguntas para determinar los requerimientos de las decisiones, un esbozo de las mismas bien podra ser:

y y

Qu informacin se usa para tomar la decisin? Cul es la fuente de esa informacin? Qu sistemas transnacionales producen los datos utilizados en el proceso de decisin? Qu otros datos son necesarios y no es posible obtener del procesamiento de transacciones? Qu datos se originan en fuentes externas a la organizacin? Cmo se deben procesar los datos para producir la informacin necesaria? Cmo debe presentarse la informacin.

y y

Una vez que se tenga recopilado el conjunto de hechos que se generan con relacin al sistema que estamos modelando, es posible dar una especificacin de requerimientos, mediante como se dijo un anlisis de los datos obtenidos durante la recopilacin de hechos. Es despus de esto entonces, que se puede ya dar un conjunto de requerimientos que nos servirn para modelar el sistema mediante un DFD y del que surge el diagrama E-R Anlisis del Flujo de Datos La estrategia del flujo de datos muestra el empleo de stos en forma grfica. Las herramientas usadas para seguir esta estrategia muestran todas las caractersticas esenciales del sistema y la forma en que se ajustan entre s. Puede ser difcil comprender en su totalidad un proceso de la empresa si se emplea para ello solo una descripcin verbal; las herramientas para el flujo de datos ayudan a ilustrar los componentes esenciales de un sistema junto con sus interacciones. El anlisis de flujo de datos usa las siguientes herramientas:

y y y

Diagrama de flujo de datos (explicado ms adelante) Diccionario de datos (explicado ms adelante) Diagrama de estructura de datos (diagrama de E-R, ver documentacin del curso de bases de datos I) Grfica de estructura: herramienta de diseo que muestra con smbolos la relacin entre los mdulos de procesamiento y el software de la computadora. Describen la jerarqua de los mdulos componentes y los datos que sern transmitidos entre ellos. Incluye el anlisis de las transformaciones entrada- salida y el anlisis de las transacciones. Diagramas de flujo de datos

Son una de las cuatro herramientas del anlisis estructurado. Es una herramienta grfica que se emplea para describir y analizar el movimiento de los datos a travs de un sistema, ya sea este manual o automatizado, incluyendo procesos, lugares para almacenar datos y retrasos en el sistema. Los DFD, como se les conoce popularmente son la herramienta ms importante y la base sobre la cual se desarrollan otros componentes. La transformacin de datos de entrada en salida por medio de procesos puede describirse en forma lgica e independiente de los componentes fsicos (computadoras, gabinetes de archivos, y procesadores de texto) asociados con el sistema. Notacin: los DFD se pueden dibujar con solo cuatro notaciones sencillas, a saber:

Flujo de datos: movimiento de datos en determinada direccin, desde un origen hasta un destino en forma de documentos, cartas, llamadas telefnicas o virtualmente cualquier otro medio. El flujo de datos es un paquete de datos Representacin: Procesos: personas procedimientos o dispositivos que usan o producen (transforman) datos. Representacin: Fuente o destino de datos: fuentes o destinos externos de datos, que pueden ser personas, programas, organizaciones u otras entidades que interactan con el sistema pero que se encuentran fuera de sus fronteras. La diferencia fundamental con los procesos es que las fuentes o destinos no transforman informacin, al menos no dentro de las fronteras del sistema que se est modelando Representacin: Almacenamiento de datos: es el lugar donde se guardan los datos o al que referencian los procesos en el sistema. El almacenamiento de datos puede representar dispositivos tanto computarizados como no computarizados. Representacin:

y y y y

y y

Los DFD se concentran en el movimiento de los datos a travs del sistema, no en los dispositivos o el equipo. Los analistas identifican y describen, desde el inicio hasta del final proceso, para comprender un rea de aplicacin o los datos que fluyen por todo el sistema y entonces explican por qu los datos entran o salen y cul es el procesamiento que se realiza con ellos. Es muy importante determinar cundo entran los datos al rea de aplicacin y cundo salen de sta. A medida que los analistas renen hechos y detalles, comprenden mejor el proceso; esto los conduce a formular preguntas relacionadas con aspectos especficos del mismo y los lleva a una investigacin adicional. La investigacin se divide en detalles que tienen cada vez un nivel menor hasta que se comprenden todos los componentes esenciales junto con sus interrelaciones.

Lo que se quiere dar a entender con esto, es que una investigacin de sistemas produce muchos conjuntos de DFD, algunos (los primeros) brindan panoramas de procesos importantes, mientras que otros (los que se obtienen de los primeros) nos muestran con bastante detalle elementos dato, almacenes de datos y pasos de procesamiento para componentes especficos de un sistema grande.

A los primeros diagramas obtenidos se les conoce como diagramas de alto nivel, mientras que a los resultantes de estos se les conoce como diagramas de bajo nivel. En este sentido el primer diagrama que se obtiene se le conoce con el nombre de diagrama de contexto, es un diagrama de nivel muy general (alto nivel); es tambin conocido como diagrama de nivel 0. Contiene un solo proceso pero juega un papel muy importante en el estudio del sistema en uso; ya que define fronteras. Todo lo que no se encuentre dentro de las fronteras identificadas en el diagrama no forman parte del estudio de sistemas. La forma en que funcionen otras organizaciones o elementos externos (las fuentes y destinos) est fuera de nuestro control y no ser estudiado con detalle. Cada flujo de datos(cada flecha) emplea una etiqueta que describe que datos emplea. Cuando los datos se mueven de un lugar a otro el flujo de datos apunta hacia el lugar donde se dirige el flujo. Ejemplo:

Un sistema est formado por varias actividades o procesos, cada uno de los cuales contiene varios sub-procesos con marcadas interrelaciones entre ellos. Por ejemplo un proceso de cuentas por pagar puede estar integrado por tres sub-procesos que podran llamarse: autorizacin de la factura, revisin del adeudo en la cuenta y elaboracin del cheque. A su vez cada sub-proceso se divide en sub-procesos ms especficos. Los nombres dados a los procesos especifican acciones y procedimientos de control que realizan Cada proceso se etiqueta adems con un nmero que identifica de donde proviene (excepto el diagrama de contexto que solo se identifica con un nivel 0 ms el nombre que se le proporcione) En trminos generales todo componente de los DFD se etiquetan con un nombre que sea representativo.

y y y

Primer nivel del DFD En el primer nivel, es muy importante identificar los principales procesos, y flujos que dan en forma conjunta sentido operacional al sistema que se est modelando. Algunos analistas consideran ventajoso trabajar primero con todos los flujos de datos y asignar, como ya se dijo nombres que sean significativos y descriptivos. Se identifican todos los procesos, como ya se mencion pero no se les da nombre hasta que sean bien entendidos todos los flujos de datos. Despus cuando se les ha asignado nombre a los procesos, si el analista tiene dificultas para ligar los flujos de datos con los nombres apropiados entonces esta situacin indica que es necesario dividir aun ms el proceso. Expansin de los procesos a diagramas de mayor nivel Una vez que se ha desarrollado el sistema como est descrito en el diagrama de primer nivel, es indudable que el analista formule preguntas en relacin con la forma que se lleven a cabo los procesos. (Ver documento de determinacin de requerimientos) En general se debe estar seguro de:

Todos los flujos de datos que explican el proceso en el diagrama previo deben incluirse en el diagrama del siguiente nivel inferior Los flujos y almacenes de datos nuevo se aaden si son usados internamente por el proceso para eslabonar otros procesos introducidos por primera vez en la expansin de este nivel. Se deben mostrar los flujos y almacenes de datos originados en el proceso dentro en este nivel. Ninguna entrada debe contradecir las descripciones de los DFD de niveles ms altos (si lo hacen uno o ambos son incorrectos y deben introducirse cambios)

En general la expansin de niveles depende de la naturaleza y complejidad del sistema que se modele; no es posible especificar un nmero de niveles, en general se debe continuar con el proceso de expansin todo lo que sea necesario para comprender los detalles del sistema y la forma en que trabaja, teniendo cuidado de verificar todos los aspectos con usuarios que conocen el sistema, en general, se debe expandir todo aquel proceso que incluyen varias tareas para las que es necesario, el flujo de datos entre diferentes personas o localidades. Por otra parte no requieren expansin aquellas tareas que son realizadas por una persona o en un escritorio, donde no existe flujo de datos. Reglas adicionales para el dibujo de DFD: ya se han identificado la mayor parte de los lineamientos que se siguen para el dibujo de los DFD, he aqu algunas ms:

Cualquier flujo de datos que abandone un proceso debe estar basado en los datos que entran al proceso

Todos los flujos de datos tienen un nombre que refleja los datos que fluyen entre procesos, almacenes de datos, fuentes o destinos Solo deben entrar al proceso, los datos necesarios para llevarlo a cabo Un proceso no debe saber nada de ningn otro en el sistema, es decir debe ser independiente, la nica dependencia que debe existir es aquella basada en sus propios datos de entrada y salida Los procesos siempre estn en continua ejecucin, no se inician ni tampoco se detienen. Los analistas siempre deben suponer que un proceso est listo para ejecutar su trabajo La salida de los procesos puede tomar una de las siguientes formas Flujo de datos con informacin aadida por el proceso (i.e: una anotacin a una factura) Una respuesta o cambio en la forma de los datos (i.e: un cambio en la forma de expresar las utilidades -de a $-) Un cambio de condicin (i.e: de autorizado a no autorizado) Cambio de contenido (i.e: integracin o separacin de la informacin contenida en uno o ms flujos entrantes de datos) Cambios en la organizacin (i.e: separacin fsica o redondeo de datos) La norma comn es definir cada nivel inferior en trminos de 3 a 7 procesos para cada proceso de nivel superior, si son necesarios ms detalles se puede hacer en el siguiente nivel. Los almacenes y flujos de datos que son relevantes solo para el interior del proceso, son ocultados hasta que el proceso se extiende con mayor detalle Los datos que fluyen hacia los procesos experimentan cambios. Por consiguiente, el flujo de datos de salida tiene un nombre diferente al de la entrada; si no se efecta algn cambio en el flujo de datos, entonces cul es la finalidad del proceso? En cuanto a los nombres de los procesos lo ms apropiado es escoger un verbo y un sujeto que reciba la accin y no nombre generales que no digan nada. Si un nombre de proceso es vago o complejo tal vez se deba subdividir el proceso an ms.

y y

y y y

y y

y y

Por otra parte no se ha mencionado nada an sobre controles en los DFD, no hemos mencionado nada al respecto sobre como manejar errores o excepciones, por ejemplo el procesamiento de facturas incorrectas. Aunque esta informacin es necesaria para el anlisis final, no es importante identificar todos los flujos de datos (los errores o excepciones son tambin flujos de datos). Los diagramas secundarios (por debajo del segundo o tercer nivel), deben mostrar el manejo de errores y excepciones del proceso. Aun as ciertos detalles fsicos como el da de la semana que se debe hacer un pago u otros controles de este tipo son innecesarios en los DFD, puesto que no tienen nada que ver con los aspectos lgicos y de datos de la determinacin de requerimientos. Los elementos importantes para comprender un proceso durante el anlisis lgico de flujo de datos, no son el nmero de copias que se requieren de un documento sino las descripciones de los datos necesarios para llevar a cabo el proceso. Diccionario de datos

Un diccionario de datos es un catlogo, un depsito, de los elementos de un sistema. Estos elementos se centran alrededor de los datos y la forma en que estn estructurados para satisfacer los requerimientos y las necesidades de la organizacin. En l se encuentran la lista de todos los elementos que forman parte del flujo de datos en todo el sistema. Importancia del diccionario: Los analistas usan los diccionarios de datos por cinco razones principales:

y y y y

Manejar los detalles en sistemas grandes Comunicar un significado comn para todos los elementos del sistema Documentar las caractersticas del sistema Facilitar el anlisis de los detalles con la finalidad de evaluar las caractersticas y determinar donde efectuar cambios en el sistema Localizar errores y omisiones en el sistema

Contenido de un registro del diccionario:

Campos: es el nivel ms importante de datos; ninguna unidad ms pequea tiene significado para los analistas. La descripcin de los datos debe ir acompaada por los siguientes elementos: Estructuras de datos: son un grupo de datos elementales que estn relacionados con otros y que en conjunto describen un componente del sistema. Los flujos de datos, o los almacenes de datos son ejemplo de estructuras de datos. Dicho de otra forma si las estructuras estn en movimiento reciben el nombre de flujos y si son estticas son almacenes de datos. Se construyen sobre cuatro relaciones de componentes; que bien pueden ser datos o estructuras de datos tambin. Se pueden usar las siguientes combinaciones ya sea en forma individual o en conjuncin con alguna otra: Relacin secuencial Relacin de seleccin Relacin de iteracin Relacin opcional

y y y y

Notacin empleada en el Diccionario de datos: Se usa smbolos especiales con la finalidad de limitar la cantidad de texto necesario empleado para describir las relaciones entre los datos y al mismo tiempo mostrar con claridad las relaciones estructurales. La simbologa empleada se describe a continuacin: Smbolo = + Significado Es equivalente a Y Explicacin Alias Concatenacin, componentes que siempre estn incluidos en una estructura Uso Denota sinnimos Denota una relacin de secuencia

[] {} ()

Uno u otro Iteraciones de Opcional

Define opciones entre los componentes de una estructura Define la repeticin de un componente de la estructura Define componentes de la estructura que puede o no estar presente una sola vez

Denota una relacin de seleccin Denota una relacin de iteracin Denota una relacin opcional.

Registro de las descripciones de datos en el diccionario:

y y y y y y y y y y y y y y y y y y y y

Flujos de datos Nombre del flujo de datos Descripcin Proviene de los procesos Para los procesos Estructuras de datos: Almacenes de datos Nombre del almacn Descripcin Flujos de datos recibidos Flujos de datos proporcionados Descripcin de los datos (mencin a los datos o estructuras que contiene) Volumen Acceso Estructuras de datos (es aqu donde es emplea la notacin descrita en la tabla anterior) Nombre de la estructura Descripcin Contenido Volumen Elementos datos

y y y y y y y y y y y y y y

Nombre del dato Descripcin Tipo Longitud Alias Rango de valores Lista de valores especficos (en caso que existan) Otros detalles de edicin Procesos Nombre del proceso Descripcin Flujos que entran Flujos que salen Resumen de la lgica

Comentario: Una forma para desarrollar la investigacin y desarrollo de sistemas puede verse como sigue:
y Investigacin preliminar y Determinacin de requerimientos y DFD del sistema en uso

y y y
y DD

Flujos Almacenes procesos

y y

Datos Flujos

y y y
y E-R

Almacenes Estructuras Procesos

y DFD del sistema propuesto y Diseo

y y y

Entradas Salidas Etc.

y Implementacin

Fin de comentario James A. Senn, Anlisis y Diseo de Sistemas, Segunda edicin, cap. tres, pg. 122. Esta notacin es la empleada para describir un sistema en uso Gerardo Barquero Rodrguez ULACIT `00

Anda mungkin juga menyukai