Metodologa de desarrollo de software

Saltar a: navegacin, bsqueda Metodologa de desarrollo de software en ingeniera de software es un marco de trabajo usado para estructurar, planificar y controlar el proceso de desarrollo en sistemas de informacin.1

Tres patrones bsicos en las metodologas de desarrollo de software.

ndice

1 Introduccin 2 Historia 3 Metodologas de desarrollo de software 4 Enfoques de desarrollo de software o 4.1 Modelo en cascada o 4.2 Prototipado o 4.3 Incremental o 4.4 Espiral o 4.5 Rapid Application Development (RAD) o 4.6 Otros enfoques de desarrollo de software 5 Referencia

Introduccin
Una metodologa de desarrollo de software se refiere a un framework que es usado para estructurar, planear y controlar el proceso de desarrollo en sistemas de informacin. A lo largo del tiempo, una gran cantidad de mtodos han sido desarrollados diferencindose por su fortaleza y debilidad.

El framework para metodologa de desarrollo de software consiste en:

Una filosofa de desarrollo de programas de computacion con el enfoque del proceso de desarrollo de software Herramientas, modelos y mtodos para asistir al proceso de desarrollo de software

Estos frameworks son a menudo vinculados a algn tipo de organizacin, que adems desarrolla, apoya el uso y promueve la metodologa. La metodologa es a menudo documentada en algn tipo de documentacin formal.

Historia
El desarrollo de los sistemas tradicionales de ciclo de vida se origin en la dcada de 1960 para desarrollar a gran escala funcional de sistemas de negocio en una poca de grandes conglomerados empresariales. La idea principal era continuar el desarrollo de los sistemas de informacin en una muy deliberada, estructurada y metdica, reiterando cada una de las etapas del ciclo de vida. Los sistemas de informacin en torno a las actividades resueltas pesadas para el procesamiento de datos y rutinas de clculo. Metodologas de Desarrollo de Software tiene como objetivo presentar un conjunto de tcnicas tradicionales y modernas de modelado de sistemas que permitan desarrollar software de calidad, incluyendo heursticas de construccin y criterios de comparacin de modelos de sistemas. Para tal fin se describen, fundamentalmente, herramientas de Anlisis y Diseo Orientado a Objetos (UML), sus diagramas, especificacin, y criterios de aplicacin de las mismas. Como complemento se describirn las metodologas de desarrollo de software que utilizan dichas herramientas, ciclos de vida asociados y discusin sobre el proceso de desarrollo de software ms adecuado para las diferentes aplicaciones ejemplos que se presentarn. Principalmente, se presentar el Proceso Unificado el cual utiliza un ciclo de vida iterativo e incremental.

Kendall y Kendall

I. Identificacin del problema, oportunidades y objetivos. II. Determinacin de los requerimientos de informacin. III. Anlisis de las necesidades del sistema. IV. Diseo del sistema recomendado. V. Desarrollo y documentacion del software. VI. Pruebas y mantenimiento del sistema. VII. Implantacin y evaluacin del sistema.

James Senn

I. Ciclo de vida y desarrollo del sistema. II. Desarrollo por anlisis estructurado III. Prototipo del sistema.

Llorens Fabregas

I. Requerimientos. II. Analisis/Diseo. III. Construccin. IV. Pruebas. V. Produccin y mantenimiento.

Jonas Montilva

I. Definir el proyecto. II. Anlisis del contexto. III. Definicin de los requerimientos. IV. Diseo preliminar. V. Diseo detallado.

Roger Pressman

I. Anlisis de los requerimientos del Software. II. Diseo. III. Genaracion de codigo. IV. Pruebas. V. Mantenimiento.

Metodologas de desarrollo de software

1970s

Programacin estructurada sol desde 1969 Programacin estructurada Jackson desde 1975

1980s

Structured Systems Analysis and Design Methodology (SSADM) desde 1980 Structured Analysis and Design Technique (SADT) desde 1980 Ingeniera de la informacin (IE/IEM) desde 1981

1990s

Rapid application development (RAD) desde 1991. Programacin orientada a objetos (OOP) a lo largo de la dcada de los 90's Virtual finite state machine (VFSM) desde 1990s Dynamic Systems Development Method desarrollado en UK desde 1995. Scrum (desarrollo), en la ltima parte de los 90's Rational Unified Process (RUP) desde 1999.

Nuevo milenio

Extreme Programming(XP) desde 1999 Enterprise Unified Process (EUP) extensiones RUP desde 2002 Constructionist design methodology (CDM) desde 2004 por Kristinn R. Thrisson Agile Unified Process (AUP) desde 2005 por Scott Ambler

Enfoques de desarrollo de software

Cada metodologa de desarrollo de software tiene ms o menos su propio enfoque para el desarrollo de software. Estos son los enfoques ms generales, que se desarrollan en varias metodologas especficas. Estos enfoques son los siguientes:1

Modelo en cascada: Framework lineal. Prototipado: Framework iterativo. Incremental: Combinacin de framework lineal e iterativo. Espiral: Combinacin de framework lineal e iterativo. RAD: Rapid Application Development, framework iterativo.

Modelo en cascada
Es un proceso secuencial de desarrollo en el que los pasos de desarrollo son vistos hacia abajo (como en una cascada de agua) a travs de las fases de anlisis de las necesidades, el diseo, implementacin, pruebas (validacin), la integracin, y mantenimiento. La primera descripcin formal del modelo de cascada se cita a menudo a un artculo publicado por Winston Royce W.2 en 1970, aunque Royce no utiliza el trmino "cascada" de este artculo. Los principios bsicos del modelo de cascada son los siguientes:1

El proyecto est dividido en fases secuenciales, con cierta superposicin y splashback aceptable entre fases. Se hace hincapi en la planificacin, los horarios, fechas, presupuestos y ejecucin de todo un sistema de una sola vez. Un estricto control se mantiene durante la vida del proyecto a travs de la utilizacin de una amplia documentacin escrita, as como a travs de comentarios y aprobacin / signoff por el usuario y la tecnologa de la informacin de gestin al final de la mayora de las fases antes de comenzar la prxima fase.

Prototipado
El prototipado es el framework de actividades dedicada al desarrollo de software prototipo, es decir, versiones incompletas del software a desarrollar.

Incremental
Provee una estrategia para controlar la complejidad y los riesgos, desarrollando una parte del producto software reservando el resto de aspectos para el futuro. Los principios bsicos son:

Una serie de mini-Cascadas se llevan a cabo, donde todas las fases de la cascada modelo de desarrollo se han completado para una pequea parte de los sistemas, antes de proceder a la prxima incremental Se definen los requisitos antes de proceder con lo evolutivo, se realiza un miniCascada de desarrollo de cada uno de los incrementos del sistema El concepto inicial de software, anlisis de las necesidades, y el diseo de la arquitectura y colectiva bsicas se definen utilizando el enfoque de cascada, seguida por iterativo de prototipos, que culmina en la instalacin del prototipo final.

Espiral

Los principios bsicos son:

La atencin se centra en la evaluacin y reduccin del riesgo del proyecto dividiendo el proyecto en segmentos ms pequeos y proporcionar ms facilidad de cambio durante el proceso de desarrollo, as como ofrecer la oportunidad de evaluar los riesgos y con un peso de la consideracin de la continuacin del proyecto durante todo el ciclo de vida. Cada viaje alrededor de la espiral atraviesa cuatro cuadrantes bsicos: (1) determinar objetivos, alternativas, y desencadenantes de la iteracin; (2) Evaluar alternativas; Identificar y resolver los riesgos; (3) desarrollar y verificar los resultados de la iteracin, y (4) plan de la prxima iteracin.3 Cada ciclo comienza con la identificacin de los interesados y sus condiciones de ganancia, y termina con la revisin y examinacin.3

Rapid Application Development (RAD)

El desarrollo rpido de aplicaciones (RAD) es una metodologa de desarrollo de software, que implica el desarrollo iterativo y la construccin de prototipos. El desarrollo rpido de aplicaciones es un trmino originalmente utilizado para describir un proceso de desarrollo de software introducido por James Martin en 1991. Principios bsicos:

Objetivo clave es para un rpido desarrollo y entrega de una alta calidad en un sistema de relativamente bajo coste de inversin. Intenta reducir el riesgos inherente del proyecto partindolo en segmentos ms pequeos y proporcionar ms facilidad de cambio durante el proceso de desarrollo. Orientacin dedicada a producir sistemas de alta calidad con rapidez, principalmente mediante el uso de iteracin por prototipos (en cualquier etapa de desarrollo), promueve la participacin de los usuarios y el uso de herramientas de desarrollo computarizadas. Estas herramientas pueden incluir constructores de Interfaz grfica de usuario (GUI), Computer Aided Software Engineering (CASE) las herramientas, los sistemas de gestin de bases de datos (DBMS), lenguajes de programacin de cuarta generacin, generadores de cdigo, y tcnicas orientada a objetos. Hace especial hincapi en el cumplimiento de la necesidad comercial, mientras que la ingeniera tecnolgica o la excelencia es de menor importancia. Control de proyecto implica el desarrollo de prioridades y la definicin de los plazos de entrega. Si el proyecto empieza a aplazarse, se hace hincapi en la reduccin de requisitos para el ajuste, no en el aumento de la fecha lmite. En general incluye Joint application development (JAD), donde los usuarios estn intensamente participando en el diseo del sistema, ya sea a travs de la creacin de consenso estructurado en talleres, o por va electrnica. La participacin activa de los usuarios es imprescindible. Iterativamente realiza la produccin de software, en lugar de enfocarse en un prototipo. Produce la documentacin necesaria para facilitar el futuro desarrollo y mantenimiento.

Otros enfoques de desarrollo de software

Metodologas de desarrollo Orientado a objetos, Diseo orientado a objetos (OOD) de Grady Booch, tambin conocido como Anlisis y Diseo Orientado a Objetos (OOAD). El modelo incluye seis diagramas: de clase, objeto, estado de transicin, la interaccin, mdulo, y el proceso. Top-down programming, evolucionado en la dcada de 1970 por el investigador de IBM Harlan Mills (y Niklaus Wirth) en Desarrollo Estructurado. Proceso Unificado, es una metodologa de desarrollo de software, basado en UML. Organiza el desarrollo de software en cuatro fases, cada una de ellas con la ejecucin de una o ms iteraciones de desarrollo de software: creacin, elaboracin, construccin, y las directrices. Hay una serie de herramientas y productos diseados para facilitar la aplicacin. Una de las versiones ms populares es la de Rational Unified Process.

Metodologas para el desarrollo de software

UNIDAD VI. Asignatura: 071-4323

Metodologa de desarrollo de software se describe como el conjunto de herramientas, tcnicas, procedimientos y soporte documental para el diseo de Sistemas de informacin. En Ingeniera de software cuando se habla de desarrollo de software se habla de desarrollo de programas y por lo tanto se considera como una tarea de ingeniera, en el cul se debe ejecutar una serie de fases, etapas para obtener un programa que funcione de acuerdo con mtodos ya establecidos en otras disciplinas de ingeniera.1 Las actividades que los ingenieros de software realizan se encuentran asociadas a un proceso de software donde intervienen diferentes elementos (fases, actividades, producto, roles, agentes) que permiten la definicin del software a producir (producto), el desarrollo o el diseo del software, la validacin del software tanto lo interno(requerimientos especficos)como lo externo(expectativas del cliente), y la evolucin del software donde se modifica para adaptarlo a los cambios.2 Por otro lado, Sommerville (2002) define que un mtodo de ingeniera de software es un enfoque estructurado para el desarrollo de software cuyo propsito es facilitar la produccin de software de alta calidad de una forma costeable, cabe destacar que para

usar este enfoque se debe manejar conceptos fundamentales tales como; procesos, mtodos, tareas, procedimientos, tcnicas, herramientas, productos, entre otros. Particularmente, una metodologa se basa en una combinacin de los modelos de proceso genricos para obtener como beneficio un software que soluciones un problema. Adicionalmente una metodologa debera definir con precisin los artefactos, roles y actividades, junto con prcticas, tcnicas recomendadas y guas de adaptacin de la metodologa al proyecto. Sin embargo, la complejidad del proceso de creacin de software es netamente dependiente de la naturaleza del proyecto mismo, por lo que el escogimiento de la metodologa estar acorde al nivel de aporte del proyecto, ya sea pequeo, mediano o de gran nivel.

Contenido
[ocultar]

1 Evolucin histrica de las metodologas de desarrollo de software 2 Generaciones de metodologas o 2.1 Desarrollo Convencional o 2.2 Desarrollo Estructurado o 2.3 Desarrollo Orientado a Objetos 3 Caractersticas deseables de una metodologa 4 Metodologas Vs. Ciclo de vida 5 Modelos de procesos en el desarrollo de software 6 Clasificacin de las Metodologas segn el modelo de proceso o 6.1 Modelos Convencionales o Prescriptivos de Procesos 6.1.1 Modelo en Cascada 6.1.2 Modelo de Procesos Incrementables 6.1.3 Modelo de desarrollo rpido de aplicaciones (DRA) 6.1.4 Modelos Evolutivos 6.1.4.1 Construccin de Prototipos 6.1.4.2 Modelo en Espiral 6.1.4.3 Modelo de desarrollo concurrente 6.1.5 Modelos iterativos o 6.2 Modelos de Desarrollo giles 6.2.1 Programacin Extrema (XP) 6.2.2 Desarrollo Adaptativo del Software (DAS) 6.2.3 Modelo de Desarrollo de Sistemas Dinmicos (MDSD) 6.2.4 Modelo Scrum 6.2.5 Desarrollo conducido por caractersticas (DCC) 6.2.6 Proceso Unificado de Rational (RUP) o 6.3 Diferencias entre los modelos de proceso convencionales y giles 7 Clasificacin de las metodologas segn su enfoque o 7.1 Metodologas estructuradas 7.1.1 Metodologas orientadas a procesos 7.1.2 Metodologas orientadas a datos o 7.2 Metodologas para sistemas de tiempo real o 7.3 Metodologas Orientadas a Objetos 8 Que metodologa es conveniente usar? 9 Modelos de procesos utilizados en el desarrollo de software

9.1 Modelado de Negocios 9.2 Modelado de Negocios e Ingeniera de Requisitos 9.3 Cadena de Valor 10 Conclusiones 11 Referencias

o o o

Evolucin histrica de las metodologas de desarrollo de software

Desde que se empez a trabajar sobre el desarrollo de programas, se siguieron ciertos mtodos que permitan llevar a producir un buen proyecto, estas metodologas aplicadas eran simples, solo se preocupaban por los procesos mas no por los datos, por lo tanto los mtodos eran desarrollados hacia los procesos. El modelo de procesos predominaba para los aos 60 y consista en codificar y corregir (Code-and-Fix), si al terminar se descubra que el diseo era incorrecto, la solucin era desecharlo y volver a empezar 3, este modelo implementaba el cdigo y luego se pensaba en los requisitos, diseo, validacin y mantenimiento. los principales problemas del modelo de procesos son:

Los arreglos se hacen costosos, despus de tantas correcciones el cdigo tenia una mala estructura. El software no se ajusta a las necesidades del usuario, por lo que es rechazado o su reconstruccin es muy cara. El cdigo es difcil de reparar por su pobre preparacin para probar y modificar.

En la dcada de los setenta empez a tomar la importancia de los datos, y para solucionar sistemas complejos empez el anlisis por partes o etapas, se introducen la planeacin y administracin. El modelo en cascada surge como respuesta al modelo de procesos, este modelo tiene mas disciplina y se basa en el anlisis, diseo, pruebas y mantenimientos. 4 La dcada de los ochenta es la poca marcada por las metodologas dirigida a datos cuya importancia va tomando cuerpo en las organizaciones. Se empiezan a estudiar los objetos en s como unidades de informacin. Para los aos 90 se quiere dar respuesta al entorno siempre cambiante y en rpida evolucin en que se han de desarrollar los programas informticos, lo cual da lugar a trabajar en ciclos cortos (como miniproyectos) que implementan una parte de las funcionalidades, pero sin perder el rumbo general del proyecto global. Por otra parte las metodologas de desarrollo comienzan a interesarse no slo en lograr que el proyecto sea puesto en funcionamiento sino en minimizar costos durante su desarrollo y sobre todo durante su mantenimiento. Los nuevos mtodos van buscando minimizar riesgos y, puesto que los errores ms perjudiciales se producen en los primeros pasos, se comienza ya desde la fase ms general del estudio por analizar los riesgos que significa seguir con las siguientes fases del desarrollo.

Las metodologas ms utilizadas a nivel mundial en orden cronolgico:13 Dcada de los 70s

Programacin Estructurada Jackson desde 1975

Dcada de los 80s

Structured Systems Analysis and Design Methodology (SSADM) desde 1980 Structured Analysis and Design Technique (SADT) desde 1980 Ingeniera de la Informacin (IE/IEM) desde 1981

Dcada de los 90s

Rapid Application Development (RAD) desde 1991. Programacin Orientada a Objetos (OOP) a lo largo de la dcada de los 90's Virtual Finite State Machine (VFSM) desde 1990s Dynamic Systems Development Method desarrollado en UK desde 1995. Rational Unified Process (RUP) desde 1999

Ao 2000 en adelante

Extreme Programming (XP) desde 1999 Enterprise Unified Process (EUP) extensiones RUP desde 2002 Constructionist Design Methodology (CDM) desde 2004 por Kristinn R. Thrisson Agile Unified Process (AUP) desde 2005 por Scott Ambler

La trascendencia de las metodologas se ha hecho notoria, pasando de solo programar, luego a establecer funciones en etapas o mdulos, continuar en resaltar en la primera etapa el anlisis de los requisitos, seguido de basarse en objetos, y por ltimo agilizar el desarrollo del software y minimizar los costos. Estos cambios de paradigma han logrado las mejoras para desarrollar software y aunque principalmente buscar acortar el tiempo de solucin sin reprochar los recursos disponibles.

Generaciones de metodologas

Las metodologas han ido cambiando con el tiempo, al surgir nuevos paradigmas que rompe con lo tradicional para abrir paso a nuevas tcnicas de solucin.5Han evolucionando a lo largo del tiempo estas herramientas, inicialmente el periodo de desarrollo convencional (practicas artesanales), luego surge el Desarrollo estructurada (parte de la programacin estructurada seguido de los mtodo de anlisis y diseo, cubre todo el ciclo de vida completo). Actualmente aparece el paradigma de la orientacin a objetos.

Desarrollo Convencional
En los aos 50 el desarrollo estaba a cargo de programadores, por lo que se vio la importancia del anlisis y diseo en el desarrollo de los sistemas. Aparecen los analistas programadores y analistas de sistemas.6 En esta misma poca, no existan metodologas de desarrollo. Las personas que desarrollaban los sistemas eran programadores ms enfocados en la tarea de codificar, que en la de recoger y comprender las necesidades de los usuarios. Estos, a menudo, no quedaban satisfechos con el sistema, porque sus necesidades no estaban definidas con claridad en una fase de anlisis previo. Ante esta perspectiva se vio la importancia del anlisis y del diseo en el desarrollo de un sistema. Ahora se empieza a hablar de analistas programadores y analistas de sistemas. Hasta hace relativamente poco tiempo cuando se hablaba de desarrollo se aluda nicamente al crecimiento econmico dando por supuesto que dicho crecimiento se revierte de manera casi automtica en los otros sectores de la estructura social. Las estrategias de desarrollo se han concentrado fundamentalmente en estrategias econmicas, que aunque incorporan elementos de otros sectores por ejemplo del sector social-, buscan como objetivo fundamental el crecimiento econmico. Por otra parte los ndices de desarrollo social se han centrado nicamente en los niveles de satisfaccin de necesidades relacionadas como la subsistencia. El desarrollo convencional tiene serios problemas, como los siguientes:

Los resultados finales son impredecibles, es decir no se sabe cundo debe acabar un proyecto. No hay forma de controlar lo que est sucediendo en el proyecto, al no existir fases establecidas y productos intermedios sobre los que realizar verificaciones. Los cambios organizativos afectan negativamente al proceso de desarrollo, no suele existir documentacin estandarizada o no se actualizan oportunamente.

En el desarrollo convencional todo el programa est en un solo bloque, con ejecucin secuencial de instrucciones. Eran los tiempos del ensamblador, las capacidades reducidas y la necesidad de optimizar al mximo. Se enfoca tanto a las necesidades del cliente y por lo cual, los programas se hacan sin usar una metodologa concreta,solo los programadores se

proponan a construir un cdigo y si contena errores era muy difcil prever donde se encontraban.

Desarrollo Estructurado
El desarrollo estructurado comenz con la programacin. A mediados de los 60 el enfoque estructurado se extiende a la fase de diseo que se conoce como diseo estructurado, el cual se basa en definir una abstraccin ms amplia usando los mdulos de programa como componentes bsicos de construccin. A mediados de los 70, se empezaron a surgir las tcnicas estructuradas, donde se empez a construir programas de una forma artesanal con mtodos de ingeniera. El desarrollo estructurado permiti facilitar la comprensin de programas, normas para la aplicacin de estructuras de datos y de control.6 En el diseo estructurado se caracteriza por lo siguiente:

Mayor nivel de abstraccin (independencia del lenguaje programacin). -Elemento bsico de diseo: mdulo. Modularidad que permite medir la calidad de programas. Representa los procesos, flujos y estructuras de datos, de una manera jerrquica y descendente. Ven el sistema como entradas-proceso-salidas. Se concentran el la parte del proceso. Se lee de porciones, independientes de las especificaciones.

Aunque este desarrollo permite disear un buen proceso y estructura de un programa, tiene inconvenientes como:

Leer todas las especificaciones para entender el problema. Se repeta la misma informacin en partes diferentes del documento. El enfoque de requisitos se interpretaba diferente por cada usuario. Cuando se finalizaba el proceso de desarrollo las especificaciones eran obsoletas.

Este enfoque se conoce como anlisis estructurado o anlisis descendente o top - down. Desde su aparicin se han hecho mejoras como dar menor importancia a la construccin de los modelos fsicos actuales y a los modelos lgicos actuales, diferenciar ms los modelos fsicos y lgicos. Ampliar las tcnicas de anlisis estructurado, para modelar sistemas en tiempo real y enfocarse en el modelo de datos.

En el desarrollo estructurado los programas estn divididos en distintos bloques, estos bloques tienen funciones que se van confeccionado en forma de arriba-abajo, empezando desde las generales hasta las particulares, hasta llegar a detallar cada uno de los procedimientos y su interaccin. Este desarrollo se enfoca al diseo del programa y la compresin se hace mas fcil. Se ha hecho evidente que este enfoque aun est un poco arraigado ya que se tiende a no pasar de un proceso o iteracin a otra, sin culminar con la anterior, ademas que el ciclo de vida debe recorrerse completo y al manejarse de esta manera, trae como consecuencias informacin redundante, costos y desperdicio de tiempo.

Desarrollo Orientado a Objetos

El desarrollo del paradigma de Orientado a Objetos (OO) trata los procesos y datos de forma conjunta. Este comienza a mediados de los 80 con los lenguajes de programacin Orienta a Objetos en los que se daba nfasis a la abstraccin de datos para los que se adjuntaba un conjunto de operaciones. Por otra parte los conceptos de tcnicas estructuradas han servido de base para muchas de las metodolgicas OO.6 La orientacin a objetos empieza con los lenguajes de programacin orientados a objetos; en estos lenguajes los problemas del mundo real se representan como un conjunto de objetos para los que se adjuntan un conjunto de operaciones. Ej: C++, Java. En la metodologa orientada a objetos el sistema se organiza como una coleccin de objetos que interactan entre s y que contienen tanto estructuras de datos como un comportamiento. Esto se opone a la programacin convencional, en la cual las estructuras de datos y el comportamiento solamente estn relacionadas de forma dbil, ya que estos se enfocan principalmente a las funciones. Los principios del modelo OO son:7

Abstraccin: Es una descripcin simplificada o especificacin de un sistema que enfatiza algunos de los detalles o propiedades del sistema, mientras suprime otros. Encapsulacin: En el proceso de ocultar todos los detalles de un objeto que no contribuyen a sus caractersticas esenciales. Modularidad: Es la propiedad de un sistema que ha sido descompuesto en un conjunto de mdulos coherentes e independientes. Jerarqua o herencia: Es el orden de las abstracciones organizado por niveles.

Tipificacin: Es la definicin precisa de un objeto de tal forma que objetos de diferentes tipos no puedan ser intercambiados o, cuando mucho, puedan intercambiarse de manera muy restringida. Concurrencia: Es la propiedad que distingue un objeto que est activo de uno que no lo est. Persistencia: Es la propiedad de un objeto a travs de la cual su existencia trasciende el tiempo (es decir, el objeto continua existiendo despus de que su creador ha dejado de existir) y/o el espacio (es decir, la localizacin del objeto se mueve del espacio de direccin en que fue creado).

Booch (1986) dice que si un modelo que se dice OO no contiene alguno de los primeros cuatro elementos, entonces no es Orientado a Objetos.

El desarrollo orientado a objetos comprende dividir un programa en clases, donde estas clases estarn estructuradas por propiedades, atributos, variables, pretendiendo simular y describir de manera conceptual a un objeto, y lo importante de este desarrollo es que al usar el principio de encapsulamiento proporciona la ventaja de que se evite interferencias extraas entre distintas partes del programa y podemos cambiar la implementacin concreta de un objeto sin afectar al resto del sistema. Actualmente este desarrollo es el que esta aflorando mas en los aspectos de desarrollo de software ya que permite crear un modelo parecido a la realidad y ver las cosas como un objeto, es decir, realmente como son y como se comportan.

Caractersticas metodologa

deseables

de

una

Existencia de reglas predefinidas, fases y subfases, tareas, productos intermedios, tcnicas y herramientas tales que se amolden a cualquier desarrollo. Cobertura total del ciclo de desarrollo. Verificaciones intermedias. Planificacin y control. Comunicacin efectiva. Utilizacin sobre un abanico amplio de proyectos. Fcil formacin. Herramientas case.

La metodologa debe contener actividades que mejoren el proceso de desarrollo. Soporte al mantenimiento. Por ejemplo. Reingeniera. Soporte de la reutilizacin de software, no solo reutilizacin de cdigo. Actualmente, se huye de mtodos muy burocrticos o monolticos.

Lo que se quiere de una metodologa es que permita definir las etapas, las salidas, entradas de un proyecto. Mantener un programa no es fcil pero se puede lograr, por lo tanto, las metodologas deben permitir una robusta formacin del proyecto que permita utilizar mecanismos de mejora y que se usen los recursos disponibles con su mayor rendimiento y eficacia.

Metodologas Vs. Ciclo de vida

Una metodologa es un conjunto integrado de tcnicas y mtodos que permite abordar de forma homognea y abierta cada una de las actividades del ciclo de vida de un proyecto de desarrollo. Una definicin estndar de metodologa puede ser el conjunto de mtodos que se utilizan en una determinada actividad con el fin de formalizarla y optimizarla. Determina los pasos a seguir y cmo realizarlos para finalizar una tarea.15

Si esto se aplica a la Ingeniera de software, podemos destacar que una metodologa:

Optimiza el proceso y el producto software. Es una gua en la planificacin y en el desarrollo del software. Define qu hacer, cmo y cundo durante todo el desarrollo y mantenimiento de un proyecto.

Una metodologa define una estrategia global para enfrentarse con el proyecto. Entre los elementos que forman parte de una metodologa se pueden destacar:

Fases: tareas a realizar en cada fase. Productos: E/S de cada fase, documentos. Procedimientos y herramientas: apoyo a la realizacin de cada tarea. Criterios de evaluacin: del proceso y del producto. Saber si se han logrado los objetivos.

El ciclo de vida es el conjunto de fases por las que pasa el sistema que se est desarrollando desde que nace la idea inicial hasta que el software es retirado o remplazado (muere).15 Entre las funciones que debe tener un ciclo de vida se pueden destacar:

Determinar el orden de las fases del proceso de software. Establecer los criterios de transicin para pasar de una fase a la siguiente. Definir las entradas y salidas de cada fase. Describir los estados por los que pasa el producto. Describir las actividades a realizar para transformar el producto. Definir un esquema que sirve como base para planificar, organizar, coordinar, desarrollar, entre otros.

Las etapas de un ciclo de vida de un software son:

Inicio: ste es el nacimiento de la idea. Aqu definimos los objetivos del proyecto y los recursos necesarios para su ejecucin. Hacia dnde queremos ir, y no cmo queremos ir. Las caractersticas implcitas o explcitas de cada proyecto hacen necesaria una etapa previa destinada a obtener el objetivo por el cual se escribirn miles o cientos de miles de lneas de cdigo. Un alto porcentaje del xito de nuestro proyecto se definir en estas etapas que, al igual que la etapa de debugging, muchos lderes de proyecto subestiman.

Planificacin: idearemos un planeamiento detallado que gue la gestin del proyecto, temporal y econmicamente. Implementacin: acordaremos el conjunto de actividades que componen la realizacin del producto. Puesta en produccin: nuestro proyecto entra en la etapa de definicin, all donde se lo presentamos al cliente o usuario final, sabiendo que funciona correctamente y responde a los requerimientos solicitados en su momento. Esta etapa es muy importante no slo por representar la aceptacin o no del proyecto por parte del cliente o usuario final sino por las mltiples dificultades que suele presentar en la prctica, alargndose excesivamente y provocando costos no previstos. Control en produccin: control del producto, analizando cmo el proceso difiere o no de los requerimientos originales e iniciando las acciones correctivas si fuesen necesarias. Cuando decimos que hay que corregir el producto, hacemos referencia a pequeas desviaciones de los requerimientos originales que puedan llegar a surgir en el ambiente productivo. Si nuestro programa no realiza la tarea para lo cual fue creada, esta etapa no es la adecuada para el rediseo. Incluimos tambin en esta etapa el liderazgo, documentacin y capacitacin, proporcionando directivas a los recursos humanos, para que hagan su trabajo en forma correcta y efectiva.

Objetivos de cada etapa:

Expresin de necesidades:Esta etapa tiene como objetivo el armado de un documento en el cual se reflejan los requerimientos y funcionalidades que ofrecer al usuario el sistema a implementar (qu, y no cmo, se va a implementar). Especificaciones: Formalizamos los requerimientos; el documento obtenido en la etapa anterior se tomar como punto de partida para esta etapa. Anlisis: Determinamos los elementos que intervienen en el sistema a desarrollar, su estructura, relaciones, evolucin temporal, funcionalidades, tendremos una descripcin clara de qu producto vamos a construir, qu funcionalidades aportar y qu comportamiento tendr. Diseo: Ya sabemos qu hacer, ahora tenemos que determinar cmo debemos hacerlo (cmo debe ser construido el sistema en cuestin?); definimos en detalle entidades y relaciones de las bases de datos, seleccionamos el lenguaje que vamos a utilizar, el Sistema Gestor de Bases de Datos, entre otros). Implementacin: Empezamos a codificar algoritmos y estructuras de datos, definidos en las etapas anteriores, en el correspondiente lenguaje de programacin o para un determinado sistema gestor de bases de datos. En muchos proyectos se pasa directamente a esta etapa; son proyectos muy arriesgados que adoptan un modelo de ciclo de vida de code & fix (codificar y corregir) donde se eliminan las etapas de especificaciones, anlisis y diseo con la consiguiente prdida de control sobre la gestin del proyecto. Debugging (Depuracin): El objetivo de esta etapa es garantizar que nuestro programa no contiene errores de diseo o codificacin. En esta etapa no deseamos saber si

nuestro programa realiza lo que solicit el usuario, esa tarea le corresponde a la etapa de implementacin. En sta deseamos encontrar la mayor cantidad de errores. Todas los programas contienen errores: encontrarlos es cuestin de tiempo. Lo ideal es encontrar la mayora, si no todos, en esta etapa. Tambin se pueden agregar pruebas de rendimiento.

Validacin: Esta etapa tiene como objetivo la verificacin de que el sistema desarrollado cumple con los requerimientos expresados inicialmente por el cliente y que han dado lugar al presente proyecto. En muchos proyectos las etapas de validacin y debugging se realizan en paralelo por la estrecha relacin que llevan. Sin embargo, tenemos que evitar la confusin: podemos realizarlos en paralelo, pero no como una nica etapa. Evolucin: En la mayora de los proyectos se considera esta etapa como Mantenimiento y evolucin, y se le asigna, no slo el agregado de nuevas funcionalidades (evolucin); sino la correccin de errores que surgen (mantenimiento). En la prctica esta denominacin no es del todo errnea, ya que es posible que aun luego de una etapa de debugging y validacin exhaustiva, se filtren errores.

Una metodologa puede seguir uno o varios modelos de ciclo de vida, adaptndose a cada uno de ellos, dependiendo de las necesidades dadas en un momento determinado, es decir, el ciclo de vida indica lo que hay que obtener a lo largo del desarrollo del proyecto pero no da las indicaciones de como obtenerlo. La metodologa indica los diferentes pasos y fases para obtener los distintos productos parciales y finales. En s para el desarrollo de software, se necesita aplicar una metodologa o varias metodologas, dentro de un ciclo de vida, de manera que sepamos que hacer y como hacerlo para conseguir lo que se quiere y cumplir con las metas planteadas.

Modelos de procesos en el desarrollo de software

Un modelo de proceso para el desarrollo de software es una representacin simplificada de pasos, representada desde una perspectiva especfica. Por su naturaleza los modelos son simplificados, por lo tanto un modelo de procesos del software es una abstraccin de un proceso real. 2

Estos modelos tienen como propsito la produccin eficaz y eficiente de un producto software que rena los requisitos del cliente. Este proceso es intensamente intelectual, afectado por la creatividad y juicio de las personas involucradas.La mayora de los modelos de procesos de desarrollo del software son dirigidos por el tiempo; cuanto ms tarde sea, ms atrs se encontrar en el proceso de desarrollo. Como todo proceso, estn constituido de pasos o fases que contienen a su vez actividades, estos modelos de desarrollo de software se basan en un ciclo de vida para desarrollar el mismo, como lo son:

La necesidad de solucionar un problema (surgimiento de necesidades) Inicio del proceso (desarrollo), dentro de esta fase se encuentra la definicin del proyecto, el anlisis del contexto, definicin de requerimientos, diseo del sistema, construccin del sistema, pruebas e implantacin. Operacin y mantenimiento, donde realiza ajustes y se buscan fallas. Renovacin o extincin.

Los procesos de software son complejos debido a que un producto de software es intangible y por lo general muy abstracto, esto dificulta la definicin del producto y sus requisitos, sobre todo cuando no se tiene precedentes en productos software similares. En general este producto esta compuesto por hardware y software. En cuanto al hardware, su produccin se realiza sistemticamente y la base de conocimiento para el desarrollo de dicha actividad est claramente definida. Respecto del software, su construccin y resultados han sido histricamente cuestionados debido a los problemas asociados

Los modelos de procesos permiten al analista de sistemas desarrollar un plan de requisitos del software, permiten establecer un trabajo en forma ordenada, adems que existen muchos modelos que se adaptan a las exigencias del proyecto, solo debemos saber cual nos conviene, pero lo mas importante, es que estos modelos nos llevan a presentar los proyectos al cliente de manera que ste vea su diseo y sus funciones y que la mayora de ellos estn orientados al mantenimiento.

Clasificacin de las Metodologas segn el modelo de proceso

Modelos Convencionales o Prescriptivos de Procesos
Los modelos convencionales o modelos prescriptivos de procesos permiten llenar el marco de trabajo con un conjunto de tareas orientadas al desarrollo de un software. Se les llama "prescriptivos" porque presciben un conjunto de elementos del proceso, tales como:21

Actividades del Marco de Trabajo. Acciones de la Ingeniera del software. Tareas. Productos de trabajo. Aseguramiento de la calidad. Mecanismos de control del cambio para cada proyecto.

Estos modelos son tiles si queremos describir un conjunto nico de actividades dentro de un marco de trabajo para un proceso de software. cada actividad debe contener un conjunto de acciones de ingeniera del software, y definir cada accin en cuanto a un conjunto de tareas que identifique el trabajo (y los productos del trabajo) que deben completarse para alcanzar las metas de desarrollo. Sin importar el modelo del proceso que se desee usar, los ingenieros de software eligen una manera tradicional para realizar el marco de trabajo genrico para el proceso, ya que estos modelos se caracterizan por ser en esencia rgidos,estrictos y los mas utilizados.

En las metodologas convencionales, el ciclo de vida de un proyecto, puede definirse como un ciclo de vida lineal, ya que imponen una disciplina de trabajo sobre el proceso

de desarrollo del software, con el fin de conseguir un software ms eficiente. Para ello, se hace nfasis en la planificacin total de todo el trabajo a realizar y una vez que est todo detallado, comienza el ciclo de desarrollo del producto software. Se centran especialmente en el control del proceso, mediante una rigurosa definicin de roles, actividades, artefactos, herramientas y notaciones para el modelado y documentacin detallada. Adems, las metodologas tradicionales no se adaptan adecuadamente a los cambios, por lo que no son mtodos adecuados cuando se trabaja en un entorno, donde los requisitos no pueden predecirse o bien pueden variar.

Los modelos prescriptivos de proceso definen un conjunto distinto de actividades, acciones, tareas fundamentos y productos de trabajo que es requieren para desarrollar software de alta calidad. Los ingenieros de software y sus gerentes deben adaptar un modelo prescripto de proceso a sus necesidades y despus lo siguen. Adems, la gente que ha solicitado el software tiene un papel por desempear se ejecuta el modelo de software. Por qu es importante? Porque proporciona estabilidad, control y organizacin a una actividad que si no se controla puede volverse catica. Cules son los pasos? El proceso conduce a un equipo de software a travs de un conjunto de actividades del marco de trabajo que se organizan en un flujo de proceso. Cul es un obtenido? Desde punto de vista de un ingeniero de software, los productos de trabajo son los programas, documentos y datos que se producen como consecuencia de las actividades y tareas que define el proceso. Modelo en Cascada

El modelo en cascada, algunas veces llamado el ciclo de vida clsico, sugiere un enfoque sistemtico, secuencial hacia el desarrollo del software, que se inicia con la especificacin de requerimientos del cliente y que contina con la planeacin, el modelado, la construccin y el despliegue para culminar en el soporte del software terminado. Este modelo es aplicable en donde existen ocasiones en que los requisitos de un problema se entienden de una manera razonable y deben estar bien definidos, tambin

cuando el trabajo fluye desde la comunicacin a travs del despliegue de una manera casi lineal, esta situacin se encuentra a veces cuando es necesario hacer adaptaciones o mejoras bien definidas a un sistema existente. El modelo en cascada es el paradigma ms antiguo para la ingeniera del software. Sin embargo, en las dcadas pasadas, las criticas a este modelo de proceso han ocasionado que aun sus ms fervientes practicantes hayan cuestionado su eficacia. Entre los problemas que algunas veces se encuentran al aplicar el modelo en cascada estn: 1. Es muy raro que los proyectos reales sigan el flujo secuencial que propone el modelo. A pesar de que el modelo lineal incluye iteraciones, lo hace de manera indirecta. Como resultado, los cambios confunden mientras el equipo de proyecto acta. 2. Con frecuencia es difcil para el cliente establecer todos los requisitos de manera explcita. El modelo en cascada lo requiere y se enfrentan dificultades al incorporar la incertidumbre natural presente en el inicio de muchos proyectos. 3. El cliente debe tener paciencia. Una versin que funcione de los programas estar disponible cuando el proyecto est muy avanzado. Un error grave ser desastroso si no se detecta antes de la revisin del programa. En un anlisis interesante de proyectos reales, Bradac(1994) concluy que la naturaleza lineal del modelo en cascada conduce a "estados de bloqueo" en los cuales algunos miembros del equipo del proyecto deben esperar a otros para terminar tareas dependientes. De hecho, el tiempo de espera puede superar el que se aplica en el trabajo productivo. El estado de bloqueo tiende a ser ms comn al principio y al final del proceso secuencial. En la actualidad, el trabajo del software est acelerado y sujeto a una cadena infinita de cambios (de caractersticas, funciones y contenido de la informacin). Con frecuencia, el modelo en cascada no es apropiado para dicho trabajo. Sin embargo, puede servir como un modelo de proceso til en situaciones donde los requerimientos estn fijos y donde el trabajo se realiza, hasta su conclusin, de una manera lineal. Las principales etapas de este modelo segn Sommerville (2005) son:

Anlisis y definicin de requerimientos. Los servicios, restricciones y metas del sistema se definen a partir de las consultas con los usuarios. Se define una especificacin del sistema. Diseo del sistema y del software. El proceso de diseo del sistema divide los requerimientos en sistemas hardware o software. Establece una arquitectura completa del sistema. El diseo del software identifica y describe las abstracciones fundamentales del sistema software y sus relaciones. Implementacin y prueba de unidades. Durante esta etapa, el diseo del software se lleva a cabo como un conjunto o unidades de programas.

Integracin y prueba del sistema. Los programas o las unidades individuales de programas se integran y prueban como un sistema completo para asegurar que se cumplan los requerimientos del software. Funcionamiento y mantenimiento. El sistema se instala y se pone en funcionamiento prctico. El mantenimiento implica corregir errores no descubiertos en las etapas anteriores del ciclo de vida.

Algunas veces llamado el ciclo de vida clsico, sugiere un enfoque sistemtico, secuencial hacia el desarrollo del software, que se inicia con la especificacin de requerimiento del cliente y que contina con la planeacin, el modelo, la construccin, y el despliegue para culminar en el soporte del software. Es un enfoque pasado de moda pero til cuando los requisitos son fijos. Modelo de Procesos Incrementables

El modelo incremental combina elementos del modelo en cascada aplicado en forma iterativa.El modelo incremental aplica secuencias lineales de manera escalonada conforme avanza el tiempo en el calendario. Cada secuencia lineal produce "incrementos" del software. Por ejemplo, el software procesador de texto, desarrollado con el paradigma incremental en su primer incremento, podra realizar funciones bsicas de administracin de archivos, edicin y produccin de documentos; en el segundo incremento, ediciones ms sofisticadas, y tendra funciones ms complejas de produccin de documentos; en el tercer incremento, funciones de correccin ortogrfica y gramatical; y en el cuarto, capacidades avanzadas de configuracin de pgina. Se debe tener en cuenta que el flujo del proceso de cualquier incremento puede incorporar el paradigma de construccin de prototipos que se expone ms adelante. A menudo, al utilizar un modelo incremental el primer incremento es un producto esencial. Es decir, se incorporan los requisitos bsicos, pero muchas caractersticas suplementarias (algunas conocidas, otras no) no se incorporan. El producto esencial queda en manos del cliente (o se somete a una evaluacin detallada). Como resultado de la evaluacin se desarrolla un plan para el incremento siguiente. El plan afronta la

modificacin del producto esencial con el fin de satisfacer de mejor manera las necesidades del cliente y la entrega de caractersticas y funcionalidades adicionales. Este proceso se repite despus de la entrega de cada incremento mientras no se haya elaborado el producto completo. El modelo de proceso incremental, al igual que la construccin de prototipos y otros enfoques evolutivos, es iterativo por naturaleza. Pero a diferencia de la construccin de prototipos, el modelo incremental se enfoca en la entrega de un producto operacional con cada incremento. Los primeros incrementos son versiones incompletas del producto final, pero proporcionan al usuario la funcionalidad que necesita y una plataforma para evaluarlo. El desarrollo incremental es til sobre todo cuando el personal necesario para una implementacin completa no est disponible. Los primeros incrementos se pueden implementar con menos gente. Si el producto esencial es bien recibido se agrega (si se requiere) ms personal para implementar el incremento siguiente. Adems, los incrementos se pueden planear para manejar los riesgos tcnicos. Por ejemplo, un sistema grande podra requerir la disponibilidad de un hardware nuevo que est en desarrollo y cuya fecha de entrega es incierta. Sera posible planear los primeros incrementos de forma que se evite el uso de este hardware, lo que permitira la entrega de funcionalidad parcial a los usuarios finales sin retrasos desordenados.

Combina elementos del modelo en cascada aplicado en forma iterativa. El modelo incremental aplica secuencias lineales de manera escalonada conforme avanza el tiempo en el calendario. Cada secuencia lineal produce incrementos. Produce entregas de software pequeas pero usables (incrementos). Cada parte se construye sobre partes ya entregadas. Modelo de desarrollo rpido de aplicaciones (DRA)

El desarrollo rpido de aplicaciones (DRA) es un modelo de proceso de software incremental que resalta un ciclo de desarrollo corto. El modelo DRA es una adaptacin

a "alta velocidad" del modelo en cascada en el que se logra el desarrollo rpido mediante un enfoque de construccin basado en componentes. Si se entienden bien los requisitos y se limita el mbito del proyecto, el proceso DRA permite que un equipo de desarrollo cree un "sistema completamente funcional" dentro de un periodo muy corto (por ejemplo, de 60 a 90 das). Como otros modelos de proceso, el enfoque DRA cumple con las actividades genricas del marco de trabajo que ya se han presentado. La comunicacin trabaja para entender el problema de negocios y las caractersticas de informacin que debe incluir el software. La planeacin es esencial porque varios equipos de software trabajan en paralelo sobre diferentes funciones del sistema. El modelado incluye tres grandes fases modelado de negocios, modelado de datos y modelado del proceso y establece representaciones del diseo que sirven como base para la actividad de construccin del modelo DRA. La construccin resalta el empleo de componentes de software existente y la aplicacin de la generacin automtica de cdigo. Por ltimo, el despliegue establece una base para las iteraciones subsecuentes, si stas son necesarias. El modelo de proceso DRA se ilustra en la siguiente figura. Es obvio que las restricciones de tiempo impuestas sobre un proyecto DRA exigen un "mbito de escalas". Si una aplicacin de negocios se puede modular de forma que cada gran funcin pueda completarse en menos de tres meses (mediante la aplicacin del enfoque ya descrito), sta es una candidata para el DRA. Cada gran funcin se puede abordar mediante un equipo de DRA por separado, para despus integrarlas y formar un todo. Como todos los modelos de procesos, el enfoque DRA tiene inconvenientes: 1) Para proyectos grandes, pero escalables, el DRA necesita suficientes recursos humanos para crear en nmero correcto de equipos DRA. 2) Si los desarrolladores y clientes no se comprometen con las actividades rpidas necesarias para completar el sistema en un marco de tiempo muy breve, los proyectos DRA fallarn. 3) Si un sistema no se puede modular en forma apropiada, la construccin de los componentes necesarios para el DRA ser problemtica.

4) Si el alto rendimiento es un aspecto importante, y se alcanzar al convertir interfaces en componentes del sistema, el enfoque DRA podra no funcionar. 5) El DRA sera inapropiado cuando los riesgos tcnicos son altos (por ejemplo, cuando una aplicacin nueva aplica muchas nuevas tecnologas). Es un modelo de proceso del software incremental que resulta un ciclo de desarrollo corto. El modelo DRA es una adaptacin a alta velocidad del modelo en cascada en el que se logra el desarrollo rpido mediante un enfoque de construccin basado en componentes. Hace un uso intensivo de componentes reusables de software con un ciclo de desarrollo extremadamente corto.

Es importante destacar que los Modelo Prescriptivos proporcionan un conjunto de pautas para el diseo, uso y reuso de los objetos de aprendizaje, como complemento al proceso de su descripcin, de una manera iterativa o incremental, desde la concepcin del objeto de aprendizaje hasta su reusabilidad a corto, mediano y largo plazo. Pero el xito en la creacin de cualquier objeto de aprendizaje depender de la adecuada aplicacin del proceso de Ingeniera de Software, cuyas etapas facilitan el desarrollo de los objetos de aprendizaje. Modelos Evolutivos

Se reconoce que el software al igual que todos los sistemas complejos evoluciona con el tiempo, los requisitos de gestin y de producto a menudo cambian conforme a que el desarrollo procede haciendo que el camino que lleva al producto final no sea real. El desarrollo evolutivo consta del desarrollo de una versin inicial que luego de exponerse se va refinando de acuerdo de los comentarios o nuevos requerimientos por parte del cliente o del usuario final. Los modelos evolutivos son iterativos, se caracteriza por la forma en que permiten a los ingenieros en software desarrollar versiones cada vez ms completas del software. A continuacin se presentan algunos de los modelos que se clasifican en esta categora.

Construccin de prototipos Modelos en espiral Modelo de desarrollo concurrente

En los modelos evolutivos se produce un sistema inicial que evoluciona segn las necesidades del cliente hasta cumplir con los requisitos de este, para luego producir un sistema que satisfaga sus necesidades. Este enfoque enlaza las actividades de especificacin, desarrollo y validacin.

Construccin de Prototipos

En Ingeniera de software la construccin de prototipos pertenece a los modelos de desarrollo evolutivo, El prototipo debe ser construido en poco tiempo, usando los programas adecuados y no se debe utilizar mucho dinero pues a partir de que este sea aprobado es que el desarrollador puede iniciar el verdadero desarrollo del software. El diseo rpido se basa en una representacin de aquellos aspectos del software que sern visibles para el cliente o el usuario final (por ejemplo, la configuracin de la interfaz con el usuario y el formato de los despliegues de salida). El diseo rpido conduce a la construccin de un prototipo, el cual es evaluado por el cliente o el usuario para una retroalimentacin; gracias a sta se refinan los requisitos del software que se desarrollar. La iteracin ocurre cuando el prototipo se ajusta para satisfacer las necesidades del cliente. Esto permite que al mismo tiempo el desarrollador entienda mejor lo que se debe hacer y el cliente vea resultados a corto plazo. La construccin de prototipos se puede utilizar como un modelo del proceso independiente. Sin importar la forma en que ste se aplique, el paradigma de construccin de prototipos ayuda al desarrollador de software y al cliente a entender de mejor manera cul ser el resultado de la construccin cuando los requisitos estn satisfechos. Etapas:

Plan rpido.

Modelado, diseo rpido. Construccin del Prototipo. Desarrollo, entrega y retroalimentacin. Comunicacin.

Ventajas:

Este modelo es til cuando el cliente conoce los objetivos generales para el software, pero no identifica los requisitos detallados de entrada, procesamiento o salida. Tambin ofrece un mejor enfoque cuando el responsable del desarrollo del software est inseguro de la eficacia de un algoritmo, de la adaptabilidad de un sistema operativo o de la forma que debera tomar la interaccin humanomquina. Reduce el riesgo de construir productos que no satisfagan las necesidades de los usuarios. Reduce costos y aumenta la probabilidad de xito. Exige disponer de las herramientas adecuadas. Una vez identificados todos los requisitos mediante el prototipo, se construye el producto de ingeniera.

Desventajas:

El usuario tiende a crearse unas expectativas cuando ve el prototipo de cara al sistema final. A causa de la intencin de crear un prototipo de forma rpida, se suelen desatender aspectos importantes, tales como la calidad y el mantenimiento a largo plazo, lo que obliga en la mayor parte de los casos a reconstruirlo una vez que el prototipo ha cumplido su funcin. Es frecuente que el usuario se muestre reacio a ello y pida que sobre ese prototipo se construya el sistema final, lo que lo convertira en un prototipo evolutivo, pero partiendo de un estado poco recomendado. El desarrollador suele tomar algunas decisiones de implementacin poco convenientes (por ejemplo, elegir un lenguaje de programacin incorrecto porque proporcione un desarrollo ms rpido). Con el paso del tiempo, el desarrollador puede olvidarse de la razn que le llev a tomar tales decisiones, con lo que se corre el riesgo de que dichas elecciones pasen a formar parte del sistema final.

Cuando el cliente define el software que desea que el analista construya, pero no identifica los requisitos detallados de entrada, procesamiento o salida. El responsable del desarrollo del software est inseguro de la adaptabilidad del sistema operativo o de la forma que debera tomar la interaccin hombre mquina, entonces en este caso es cuando se puede emplear la construccin de prototipos. Se crea un diseo rpido que se centra en una representacin de aquellos aspectos del software que sern visibles para el usuario final, a su vez el diseo rpido conduce a la construccin de un prototipo. Despus, el prototipo lo evala el usuario y con la retroalimentacin se refinan los requisitos del software que se desarrollar. Modelo en Espiral

El modelo en espiral representa en forma de espiral una secuencia de actividades.2 Este modelo fue originalmente propuesto por Boehm en 1988, y se diferencia de los dems modelos por considerar el riesgo. El modelo en espiral para la ingeniera de software es actualmente el enfoque ms realista para el desarrollo de software y de sistemas a gran escala. Utiliza un enfoque evolutivo, permitiendo al desarrollador y al cliente entender y reaccionar ante los riesgos en cada nivel evolutivo.2 El modelo en espiral se divide en un nmero de actividades estructurales, tambin llamadas regiones de tareas, segn Sommerville (2005) el ciclo de vida del modelo en espiral se divide cuatro sectores: 1. Definicin de objetivos. En esta fase se identifica las restricciones del proceso y le producto, y dependiendo los riesgos para trazar objetivos y respectivamente panes estratgicos. 2. Evaluacin y reduccin de riesgos. Se hace un anlisis detallado para casa riesgo y se establece los pasos para reducirlos. 3. Desarrollo y validacin. Despus de evaluar los riesgos, se elige un modelo para el desarrollo del sistema.

4. Planificacin. El proyecto se revisa y se toma la decisin de si debe continuar con un ciclo posterior de la espiral. Las caractersticas que se pueden indicar del modelo en espiral son:

El software se desarrolla en una serie de versiones incremntales. Durante las primeras iteraciones. La versin incremental podra ser un modelo en papel o un prototipo. A medida que se va incrementando el nmero de iteraciones, se producen versiones cada vez mas completas.

Ventajas:

Puede adaptarse y aplicarse a lo largo de la vida del software. Como el software evoluciona, a medida que progresa el proceso, el desarrollador y el cliente comprenden y reaccionan mejor ante riesgos en cada uno de los niveles evolutivos. Permite a quien lo desarrolla aplicar el enfoque de construccin de prototipos en cualquier etapa de evolucin del producto. Demanda una consideracin directa de los riesgos tcnicos en todas las etapas del proyecto. Reduce los riesgos antes de que se conviertan en problemticos.

Desventajas:

Puede resultar difcil convencer la grandes clientes de que el enfoque evolutivo es controlable (particularmente en situaciones de contrato). Si un riesgo importante no es descubierto y gestionado, indudablemente surgirn problemas. Como es un modelo relativamente nuevo no es muy utilizado. Otros inconvenientes que pueden surgir es convencer al cliente que es un enfoque controlable,por lo que se requiere de experiencia en la identificacin de riesgos y refinamiento para su uso generalizado.

Lo caracterstico del modelo es espiral es que incluye un anlisis de riesgo es decir que podemos analizar si el proyecto puede continuar o mejor lo suspendemos. Este modelo se basa en que antes de hacer algo debemos analizarlo, tambin debemos buscar varias opciones de resolucin de problemas para de all escoger la opcin ms conveniente, y adems analizar los riesgos que se pueda tener. Este modelo necesita de otro mtodos para poder desarrollarse.

Modelo de desarrollo concurrente

Davis Sitaram describe el modelo de desarrollo concurrente de la siguiente forma:18 "Los gestores de proyectos que siguen los pasos del estado del proyecto en lo que se refiere a las fases importantes [del ciclo de vida clsico] no tiene ideal del estado de sus proyectos. Estos son ejemplos de un intento por seguir los pasos extremadamente simples. Tenga en cuenta que aunque un proyecto [grande] este en la fase de codificacin, hay personal de ese proyecto implicado en actividades asociadas generalmente a muchas fases de desarrollo simultneamente. Por ejemplo,...el personal esta escribiendo requisitos diseando, codificando, haciendo pruebas y probando la integracin (todo al mismo tiempo). Los modelos de proceso de ingeniera del software de Humphrey y Kellner han mostrado la concurrencia que existe para actividades que ocurren para cualquier fase. El trabajo ms reciente de Kellner utiliza diagramas de estado para representar la relacin concurrente que existe entre actividades asociadas a un acontecimiento especifico, pero falla en capturar la riqueza de la concurrencia que existe en todas las actividades del desarrollo y de gestin del software en mi proyecto...La mayora de los modelos de procesos de desarrollo del software son

dirigido por el tiempo; cuanto ms tarde sea, mas atrs se encontrara en el proceso de desarrollo. (Un modelo de proceso concurrente) esta dirigido por las necesidades del usuario, las decisiones de la gestin y los resultados de las revisiones." Acorde con la descripcin de Davis podemos decir que el modelo concurrente se define una serie de acontecimientos que dispararan transiciones de estado a estado para cada una de las actividades de la ingeniera del software proporcionando una visin certera del estado actual del proyecto. Se puede representar en forma de esquema como una serie de actividades tcnicas importantes, tareas y estados asociados a ellas. 19 Funcionalidad del proceso:

Cada actividad, accin o tarea dentro de la red existe de manera simultnea con otras. Los sucesos generados dentro de una actividad dada o algn otro lado de la red de actividad inicia las transiciones entre los estado de una actividad.

El modelo de proceso concurrente se utiliza como paradigma de desarrollo de aplicaciones cliente/servidor. Un sistema cliente/servidor se compone de un conjunto de componentes funcionales. Cuando se aplica a cliente/servidor, el modelo de proceso concurrente define actividades en dos dimensiones: una divisin de sistemas y una divisin de componentes. Los aspectos del nivel de sistemas se afrontan mediante dos actividades: diseo y realizacin. La concurrencia se logra de dos formas: 1. Las actividades del sistema y de componente ocurren simultneamente y pueden modelarse con el enfoque orientado a objetos descrito anteriormente. 2. Una aplicacin cliente/servidor tpica se implementa con muchos componentes, cada uno de los cuales se pueden disear y realizar concurrentemente. Ventajas:

Excelente para proyectos en los que se conforman grupos de trabajo independientes. Proporciona una imagen exacta del estado actual de un proyecto.

Desventajas:

Si no se dan las condiciones sealadas no es aplicable. Si no existen grupos de trabajo no se puede trabajar en este mtodo

Modelos iterativos

Este modelo busca reducir el riesgo que surge entre las necesidades del usuario y el producto final por malos entendidos durante la etapa de recogida de requisitos. Consiste en la iteracin de varios ciclos de vida en cascada. Al final de cada iteracin se le entrega al cliente una versin mejorada o con mayores funcionalidades del producto. El cliente es quien despus de cada iteracin evala el producto y lo corrige o propone

mejoras. Estas iteraciones se repetirn hasta obtener un producto que satisfaga las necesidades del cliente. 15 El modelo iterativo se suele utilizar en proyectos en los que los requisitos no estn claros por parte del usuario, por lo que se hace necesaria la creacin de distintos prototipos para presentarlos y conseguir la conformidad del cliente. Cada iteracin es un mini proyecto en cascada auto contenido compuesto de actividades como anlisis de requerimientos, diseo, programacin y pruebas. 15 Ventajas:

Permite crear cada vez versiones ms completas de software Resolucin de problemas de alto riesgo en tiempos tempranos del proyecto. Visin de avance en el desarrollo desde las etapas iniciales del desarrollo. Menor tasa de fallo del proyecto, mejor productividad del equipo, y menor cantidad de defectos El trabajo iterativo deja una experiencia en el equipo que permite ir ajustando y mejorando las planificaciones, logrando menores desvos en la duracin total del proyecto.

Desventajas:

Requiere de un cliente involucrado durante todo el curso del proyecto. Hay clientes que simplemente no estarn dispuestos a invertir el tiempo necesario. Infunde responsabilidad en el equipo de desarrollo al trabajar directamente con el cliente, requiriendo de profesionales sobre el promedio.

Una de las grandes ventajas que ofrece este modelo es que los requisitos se pueden ir refinando en cada una de las iteraciones, es decir cuando no se puede especificar a priori todos los requisitos del software, sino que este proceso ayudar a ir descubriendo paso a paso los requisitos a partir de cada nueva entrega, mediante iteraciones las cuales no son mas que mini proyectos en cascada, en este modelo el cliente tiene la oportunidad de incluir o desechar elementos al final de cada iteracion, buscando cada vez versiones mas ccompletas hasta que cumpla sus espectativas o se adapte a sus necesidades

Modelos de Desarrollo giles

Las metodologas giles son un conjunto de mtodos de ingeniera del software, que se basan en el desarrollo iterativo e incremental, teniendo presente los cambios y respondiendo a estos mediante la colaboracin de un grupo de desarrolladores autoorganizados y multidisciplinares.

En las metodologas giles, los procesos se desarrollan de manera solapada, donde el ciclo de vida del proyecto, es cclico. La diferencia en el ciclo de vida de un proyecto gil, en comparacin con uno tradicional, se debe a la forma en la que el agilismo, solapa los procesos de manera iterativa.

La tendencia del control de procesos para desarrollo de software ha trado como resultado que proyectos no resulten exitosos debido al cambiante contexto que existe, por lo cul las metodologas giles pretende resolver este inconveniente, construyendo soluciones a la medida asegurando la calidad. Los mtodos giles fueron pensados especialmente para equipos de desarrollo pequeos, con plazos reducidos, requisitos voltiles y nuevas tecnologas. La filosofa de las metodologas giles, pretenden dar mayor valor al individuo, a la colaboracin con el cliente y al desarrollo incremental del software con iteraciones muy cortas. Este enfoque est mostrando su efectividad en proyectos con requisitos muy cambiantes y cuando se exige reducir drsticamente los tiempos de desarrollo pero manteniendo una alta calidad.14 La direccin del enfoque de establecer una metodologa que solventara los cambios drsticos del ambiente, di origen en febrero de 2001, tras una reunin celebrada en Utah-EEUU, en esta reunin participan un grupo de 17 expertos de la industria del software, incluyendo algunos de los creadores o impulsores de metodologas de software. Su objetivo fue esbozar los valores y principios que deberan permitir a los equipos desarrollar software rpidamente y respondiendo a los cambios que puedan surgir a lo largo del proyecto. Se pretenda ofrecer una alternativa a los procesos de desarrollo de software tradicionales (metodologas pesadas), caracterizados por ser rgidos y dirigidos por la documentacin que se genera en cada una de las actividades desarrolladas. La fundacin del manifiesto gil, una organizacin, sin nimo de lucro, dedicada a promover los conceptos relacionados con el desarrollo gil de software y ayudar a las

organizaciones para que adopten dichos conceptos, promovi a que los grupos de desarrolladores se enfocarn y estableciern los siguientes valores:

Al individuo y las interacciones del equipo de desarrollo sobre el proceso y las herramientas. La gente es el principal factor de xito de un proyecto software. Es ms importante construir un buen equipo que construir el entorno. Muchas veces se comete el error de construir primero el entorno y esperar que el equipo se adapte automticamente. Es mejor crear el equipo y que ste configure su propio entorno de desarrollo en base a sus necesidades. Desarrollar software que funciona ms que conseguir una buena documentacin. La regla a seguir es no producir documentos a menos que sean necesarios de forma inmediata para tomar un decisin importante. Estos documentos deben ser cortos y centrarse en lo fundamental. La colaboracin con el cliente ms que la negociacin de un contrato. Se propone que exista una interaccin constante entre el cliente y el equipo de desarrollo. Esta colaboracin entre ambos ser la que marque la marcha del proyecto y asegure su xito. Responder a los cambios ms que seguir estrictamente un plan. La habilidad de responder a los cambios que puedan surgir a los largo del proyecto (cambios en los requisitos, en la tecnologa, en el equipo, entre otros) determina tambin el xito o fracaso del mismo. Por lo tanto, la planificacin no debe ser estricta sino flexible y abierta.

Estos valores inspiraron los doce principios del manifiesto gil: I. La prioridad es satisfacer al cliente mediante tempranas y continuas entregas de software que le aporte un valor. II. Dar la bienvenida a los cambios. Se capturan los cambios para que el cliente tenga una ventaja competitiva. III. Entregar frecuentemente software que funcione desde un par de semanas a un par de meses, con el menor intervalo de tiempo posible entre entregas. IV. La gente del negocio y los desarrolladores deben trabajar juntos a lo largo del proyecto. V. Construir el proyecto en torno a individuos motivados. Darles el entorno y el apoyo que necesitan y confiar en ellos para conseguir finalizar el trabajo. VI. El dilogo cara a cara es el mtodo ms eficiente y efectivo para comunicar informacin dentro de un equipo de desarrollo. VII. El software que funciona es la medida principal de progreso. VIII. Los procesos giles promueven un desarrollo sostenible. Los promotores, desarrolladores y usuarios deberan ser capaces de mantener una paz constante.

IX. La atencin continua a la calidad tcnica y al buen diseo mejora la agilidad. X. La simplicidad es esencial. XI. Las mejores arquitecturas, requisitos y diseos surgen de los equipos organizados por s mismos. XII. En intervalos regulares, el equipo reflexiona respecto a cmo llegar a ser ms efectivo, y segn esto ajusta su comportamiento. En definicin las metodologas giles son un conjunto de mtodos de ingeniera del software, que se basan en el desarrollo iterativo e incremental, teniendo presente los cambios y respondiendo a estos mediante la colaboracin de un grupo de desarrolladores auto-organizados y multidisciplinares. Las caractersticas esenciales del proceso de desarrollo gil para la mayora de los proyectos son las siguientes:

Busca la satisfaccin del cliente. Entrega temprana de software incremental. Utilizan mtodos informales. Simplicidad general del desarrollo. La comunicacin entre los desarrolladores y los clientes durante el desarrollo del proyecto debe ser activa y continua. La idea es que se mantenga un canal de retroalimentacin con el cliente, a traves de entregas de prototipos ejecutable o porcin de un sistema operacional, en periodos cortos para que la adaptabilidad mantenga un buen ritmo con el cambio.

Programacin Extrema (XP)

La programacin extrema (XP, extreme Programming) es un modelo de proceso de software el fue acuado por Beck el cual toma los principios y practicas aceptadas y las lleva a niveles extremos. Tiene como objetivo reducir el riesgo en el ciclo de vida del software mediante grupos de desarrollo pequeos, considera que la mejor manera de tratar la falta de requisitos estables en un sistemas, es mediante la agilidad de un grupo pequeo de desarrollo 8 . Esta se basa en la simplicidad, la comunicacin y el reciclado continuo de cdigo. El modelo considera varios aspectos problemticos del desarrollo de software como lo son los retrasos , proyectos cancelados, cambios en el negocio y la rotacin del personal. Sus actividades bsicas son : Codificar, hacer pruebas, escuchar y disear. Los objetivos de XP son muy simples:

1. La satisfaccin del cliente: trata de dar al cliente el software que l necesita y cuando lo necesita. 2. Potenciar al mximo el trabajo en grupo: Tanto los jefes de proyecto, los clientes y desarrolladores, son parte del equipo y estn involucrados en el desarrollo del software. XP define cuatro variables para proyectos de software: coste, tiempo, calidad y mbito. Adems de estas cuatro variables, Beck propone que slo tres puedan ser establecidas por las fuerzas externas (jefes de proyecto y clientes), mientras que el valor de la cuarta variable debe ser establecido por los programadores en funcin de las otras tres. 8 Los valores originales de la programacin extrema son:4

Simplicidad: XP propone el principio de hacer la cosa ms simple que pueda funcionar, en relacin al proceso y la codificacin. Esta es la base de la programacin extrema. Comunicacin: Los programadores se comunican constantemente gracias a la programacin por parejas y adems la comunicacin con el cliente es fluida ya que el cliente forma parte del equipo de desarrollo Retroalimentacin: retroalimentacin concreta y frecuente del cliente, del equipo y de los usuarios finales da una mayor oportunidad de dirigir el esfuerzo. Coraje o valenta : La valenta le permite a los desarrolladores que se sientan cmodos con reconstruir su cdigo cuando sea necesario. Esto significa revisar el sistema existente y modificarlo si con ello los cambios futuros se implementaran mas fcilmente.

Principios bsicos en la Programacin extrema: 9

Planificacin Incremental: los requerimientos se registran en tarjetas de historias, estas incluyen el tiempo y la prioridad relativa. Entregas pequeas: estas entregas son frecuentes e incrementalmente aaden funcionalidad al primera entrega Diseo sencillo: solo se lleva a cabo el diseo necesario para cumplir los requerimientos actuales Desarrollo previamente probado; se utiliza un sistema de pruebas, para escribir pruebas de las nuevas funcionalidades antes de que estas se implementen. Refactorizacin: conserva el cdigo sencillo y mantenible. Programacin en parejas: esta es la mas importante de todos los principios, los desarrolladores trabajan en parejas, verificando cada uno el trabajo del otro, proporcionando la ayuda para hacer siempre un buen trabajo Propiedad colectiva: las parejas trabajan en todas las reas del sistema.

Integracin continua: cuanto acaba el trabajo en una tarea, se integra en el sistema entero. Ritmo sostenible: No se consideran aceptables grandes cantidades de horas extras, ya que a menudo, reduce la calidad del codigo y la productividad a medio plazo. Cliente presente: Debe estar disponible al equipo de XP, un represente de los usuarios finales del sistema a tiempo completo. En un proceso XP el cliente es parte del equipo de desarrollo

La programacin extrema es uno de los mtodo giles ms conocido y ampliamente utilizados, donde el usuario o cliente forma parte del equipo de trabajo, engloba en una serie de principios dentro de los ms importantes se encuentra la programacin en parejas y el desarrollo de pruebas, as como tambin reulitizacin de los cdigos. Para el uso de XP los requerimientos deben de estar bien definidos, mediante las historias de usuario. Este modelo se basa en la retroalimentacin continua entre el cliente y el equipo de desarrollo, especialmente muy utilizada para proyectos con requisitos imprecisos y muy cambiantes, centrada en potenciar las relaciones interpersonales como clave para el xito en el desarrollo de software, promoviendo el trabajo en equipo y preocupndose por el aprendizaje de los desarrolladores y la satisfaccin del cliente Desarrollo Adaptativo del Software (DAS)

El desarrollo adaptativo de software (DAS) 1998 fue propuestos por Jim Highsmith como una metodologa para desarrollar el software y sistemas muy complejos. Este se centra en la colaboracin humana y la organizacin del equipo 2. El Desarrollo adaptativo del software proporciona un marco para el desarrollo iterativo de sistemas grandes y complejos, el mismo fomenta el desarrollo iterativo e incremental con el uso de prototipos. El ciclo de vida del DAS se conforma de tres fases: Especulacin, colaboracin y aprendizaje - Fase de especulacin: Es la primera de las fases esta inicia en el desarrollo del proyecto. Se utiliza informacin como la visin del cliente, las restricciones del proyecto y los requisitos bsicos para definir el conjunto de ciclos en el que se harn los incrementos del software. En esta fase es donde se lleva a cabo la planificacin tentativa del proyecto en funcin de las entregas que se iran realizando - Fase de colaboracin: Se busca que el equipo colabore inmensamente para lograr la funcionalidad planeada, se comunique o se encuentre completamente integrados, se desea que exista confianza, donde se puedan realizar crticas constructivas y ayudar si resentimientos, as como tambin comunicar de una forma oportuna los problemas que

se presenten para tomar acciones efectivas y poseer un conjunto de actitudes que contribuyan al trabajo que se encuentran realizando. - Fase del aprendizaje: consiste en la revisin de calidad que se realiza al final de cada ciclo, esto permite mejorar el entendimiento real sobre la tecnologa, los procesos utilizados y el proyecto. El aprendizaje individual permite al equipo tener mayor posibilidad de xito.

Esta metodologa no proporciona el tipo de prcticas detalladas como lo hace XP, pero proporciona la base fundamental de por qu el desarrollo adaptable es importante y las consecuencias a los ms profundos niveles de la organizacin y la gerencia. Los apoyos filosficos del DAS se enfocan en la colaboracin humana y la organizacin propia del equipo, y es un modelo para la construccin de software y sistemas complejos, incluye tres fases que son: especulacin, colaboracin y aprendizaje, cada una de estas fases son fundamental para el desarrollo de la otra. Es adaptativo, se hace uso de la reutilizacin del cdigo para adaptarlo a lo que se desea Modelo de Desarrollo de Sistemas Dinmicos (MDSD)

Es un metodo de desarrollo agil de software que apoyado por su continua implicacion del usuario en un desarrollo iterativo y creciente que sea sensible a los requerimientos cambiantes, para desarrollar un sistema que reuna las necesiadades de la empresa en tiempo y presuspuesto. Este se caracteriza por proporcionar un marco de trabajo el cual permita construir y mantener sistemas con restricciones de tiempo muy estrechas mediante el empleo de la construccin de prototipos incremntales en un ambiente de proyecto controlado 10 El MDSD comienza con un estudio de viabilidad y de negocio, son las primeras actividades que deben realizarse

Estudio viabilidad: Se evala si la aplicacin es viable, para el proceso teniendo en cuenta los requisitos bsicos del negocio y sus restricciones asociadas. Estudio de negocios: establece los requisitos funcionales y de informacin que permitirn que la aplicacin proporcione un valor al negocio; tambin define la arquitectura bsica de la aplicacin.

El resto del proceso forma tres ciclos iterativos que son:

Iteracin de modelo funcional: produce una serie de prototipos incremntales que demuestran la funcionalidad para el cliente. Su propsito durante este ciclo es recopilar requisitos adicionales y producir documentacin de anlisis.

Iteracin de construccin y diseo: revisa la construccin de prototipos durante la iteracin del modelo funcional, en este se disea el sistema para el uso operacional. En algunos casos, la iteracin del modelo funcional y esta, suceden en forma concurrente. Implementacin: coloca el incremento de software ms reciente en el ambiente operativo, se ocupa del despliegue al uso operacional. Puede destacarse que 1) el incremento puede no estar 100 por ciento completo o 2) se pueden requerir cambios cuando el incremento se coloca en el sitio.

El modelo de desarrollo de sistemas dinmicos tiene como objetivo fundamental la entrega de sistemas software en tiempo y presupuesto , ajustndose a los cambios de requisitos que puedan surgir durante el proceso de desarrollo. Para su implementacin se hacen dos estudios principalmente el de negocio y el de viabilidad, para posteriormente dar inicio a sus 3 ciclos de vida . Al igual que XP el desarrollo es iterativo e incremental as como tambin basado por la retroalimentacin del usuario, de esa manera logrando converger la solucin del negocio mas efectiva. Ademas de lo mencionado anteriormente el MDSD incluyen enttregas frecuentes, equipos autorizados, y pruebas a lo largo de todo su ciclo Modelo Scrum

Scrum es una metodologa gil de gestin de proyectos cuyo objetivo primordial es elevar al mximo la productividad de un equipo, fue desarrollado por Jeff Sutherland y elaborado ms formalmente por Ken Schwaber. 11. Se enfoca en el hecho de que procesos definidos y repetibles slo funcionan para atacar problemas definidos y repetibles con gente definida y repetible en ambientes definidos y repetibles. Y se divide un proyecto en iteraciones (que ellos llaman carreras cortas) de 30 das. La literatura de Scrum se orienta principalmente en la planeacin iterativa y el seguimiento del proceso
12

Caracteristicas:

Enfatiza valores y prcticas de gestin, sin pronunciarse sobre requerimientos, prcticas de desarrollo, implementacin y dems cuestiones tcnicas. Hace uso de Equipos auto-dirigidos y auto-organizados Puede ser aplicado tericamente a cualquier contexto en donde un grupo de gente necesita trabajar junta para lograr una meta comn. Desarrollo de software iterativos incrementales basados en prcticas agiles Iteraciones de treinta das; aunque se pueden realizar con mas frecuencia, estas iteraciones, conocidas como Sprint Dentro de cada Sprint se denomina el Scrum Master al Lder de Proyecto quien llevar a cabo la gestin de la iteracin Se convocan diariamente un Scrum Daily Meeting el cual representa una reunin de avance diaria de no ms de 15 minutos con el propsito de tener realimentacin sobre las tareas de los recursos y los obstculos que se presentan. En la cual se responden

preguntas como: Qu has hecho desde el ultimo encunetro? Qu obstaculos hay para cumplir la meta? Qu haras antes del proximo encuentro?

Ciclo de Vida de Scrum En cuanto al ciclo de vida del modelo Scrum es el siguiente 12: 1. Pre-Juego / Planeamiento: El propsito es establecer la visin, definir expectativas y asegurarse la financiacin. Las actividades son la escritura de la visin, el presupuesto, el registro de acumulacin o retraso Metodologas giles (backlog) del producto inicial y los tems estimados, as como la arquitectura de alto nivel, el diseo exploratorio y los prototipos. El registro de acumulacin es de alto nivel de abstraccin. 2. Pre-Juego / Montaje (Staging): El propsito es identificar ms requerimientos y priorizar las tareas para la primera iteracin. Las actividades son planificacin, diseo exploratorio y prototipos. 3. Juego / Desarrollo: El propsito es implementar un sistema listo para entrega en una serie de iteraciones de treinta das llamadas corridas (sprints). Las actividades son un encuentro de planeamiento de corridas en cada iteracin, la definicin del registro de acumulacin de corridas y los estimados, y encuentros diarios de Scrum. 4. Pos-Juego/ Liberacin: El propsito es el despliegue operacional. Las actividades, documentacin, entrenamiento, mercadeo y venta.

Scrum es una metodologa para la gestin y desarrollo de software basada en un proceso iterativo e incremental, uno de sus principios claves radica en el reconocimiento de que durante un proyecto los clientes pueden cambiar sus pensamientos sobre lo que quieren y necesitan. En este modelo se hacen reuniones diarias o tambin denominadas reuniones cortas (15 min aprox) donde se discute lo que se hizo, lo que se hace, y lo que posteriormente se har . Es una ayuda para organizar a las personas y el flujo de trabajo, es importante destacar que en este modelo los equipos son auto-organizados (no auto-dirigidos), con margen de decisin suficiente para tomar las decisiones que consideren oportunas. Desarrollo conducido por caractersticas (DCC)

El desarrollo conducido por caractersticas (DCC) lo concibieron originalmente Peter Coad como un modelo de proceso prctico para la ingeniera del software orientada a objetos. Stephen Palmer y John Felsin han extendido y mejorado el trabajo de Coad, al describir un proceso adaptativo y gil que puede aplicarse en proyectos de software de tamao moderado y grande. En el contexto del DCC una caracterstica "es una funcin evaluada por el cliente que puede implementarse en dos semanas o menos.13 Beneficios que se le concede a la definicin de caractersticas:13

Las caractersticas se pueden organizar en un agrupamiento jerrquico relacionado con el negocio. Como las caractersticas son bloques pequeos de funcionalidad entregable, los usuarios las describen con mayor facilidad, pueden entender cmo stas se relacionan con otras con mayor rapidez, y pueden revisarlas de mejor manera en bsqueda de ambigedades, errores u omisiones. Una caracterstica es el incremento de software entregable, el equipo desarrolla caractersticas operativas cada dos semanas. Debido a que las caractersticas son pequeas, sus diseos y representaciones de cdigo son ms fciles de inspeccionar de manera efectiva

El DCC se encuentra dividido en cinco fases o actividades:13 1. Desarrollar un modelo General 2. Elaborar una lista de caractersticas 3. Plan por caractersticas 4. Diseo por caractersticas 5. Construccin por caractersticas El desarrollo de un modelo general: En una fase ya se tiene el dominio, el contexto, y los requerimientos del sistema a construir. En este momento se posee informacin bsica de las especificaciones funcionales. referencias La construccin de la lista de caractersticas los ensayos, modelos de objetos y documentacin de requerimientos proporcionan la base para construir una amplia lista de caractersticas . Las funciones se agrupan conforme a diversas actividades en reas de dominio especificas y la lista de caractersticas es revisada por los usuarios para asegurar su validez y exhaustividad El diseo y la construccin por caractersticas, se selecciona las caractersticas a desarrollar y los equipos dispuestos por cada una de ellas. Luego se procede iterativamente hasta que se producen las caractersticas seleccionadas.

El desarrollo conducido por caractersticas es un modelo de proceso prctico para la ingeniera de software orientada a objetos debido a que las caractersticas se pueden organizar en un grupos relacionado con el negocio, y este busca que el equipo de proyecto desarrolle las caractersticas o funciones que son evaluadas por el cliente, las cuales pueden ser implementadas en un corto tiempo de dos semanas o menos, es un modelo que se enfoca ms hacia la parte de la direccin y gestin de proyectos

Proceso Unificado de Rational (RUP)

El Proceso Unificado de Rational es una metodologa de desarrollo de software orientada a objetos creada por Rational Software Corporation. Es una de las metodologas ms extendidas y conocidas por su amplia difusin comercial. Se puede estudiar como una metodologa representativa de tipo clsico. Fue definido por los creadores del UML unificando los mtodos de Ivar Jacobson, Grady Booch y James Rumbaugh. El hecho de que la empresa RATIONAL tambin distribuya herramientas especficas basadas en el mismo mtodo, que facilitan el desarrollo, ha contribuido a su gran expansin. 16 Este proceso se maneja por casos de uso (correspondientes a los modos uso por los actores o agentes usuarios) para la extraccin de requisitos y la identificacin de las partes funcionales en las que se divide la solucin. La arquitectura del proceso se modela con orientacin a objetos. Estos metodologistas, fueron reunidos por Rational para formar un marco de metodologas unificadas, cohesivas y comprehensivas de desarrollo de sistemas de software. Su trabajo, que producen durante varios aos y basados en metodologas probadas, han dado a lugar a importantes normas en la comunidad de desarrollo, Como toda metodologa de desarrollo software su finalidad es convertir las especificaciones que da el cliente en un sistema software. Las caractersticas que tiene el RUP. son:

Est basado en componentes. Estos componentes a su vez estn conectados entre s a travs de interfaces. Utiliza el UML como notacin bsica. Dirigido por casos de uso. El proceso utiliza Casos de Uso para manejar el proceso de desarrollo desde la Incepcin hasta el Despliegue. Centrado en la arquitectura. El proceso busca entender los aspectos estticos y dinmicos ms significativos en trminos de arquitectura de software. La arquitectura se define en funcin de las necesidades de los usuarios y se determina a partir de los Casos de Uso base del negocio. Ciclo de vida iterativo e incremental. El proceso reconoce que es prctico dividir grandes proyectos en proyectos ms pequeos o mini-proyectos. Cada mini-proyecto comprende una iteracin que resulta en un incremento. Una iteracin puede abarcar la totalidad de los flujos del proceso. Las iteraciones son planificadas en base a los Casos de Uso.

Proceso de cuatro fases El proceso Unificado consta de ciclos que puede repetir a lo largo del ciclo de vida de un sistema. Un ciclo consiste en cuatro fases: Incepcin, Elaboracin, Construccin y Transicin. Un ciclo concluye con una liberacin, tambien hay versiones dentro de un ciclo. Esta es una descripcin breve de las fases de un ciclo:

Fase de Incepcin: Durante la fase inicial se concibe la idea central del producto, se arma el documento de visin. En esta fase, se revisan y confirma nuestro entendimiento sobre los objetivos centrales del negocio. Queremos entender los argumentos comerciales en favor de porqu el proyecto debe intentarse. La fase de incepcin establece la viabilidad del producto y delimita el alcance del proyecto.

Se describe el producto final. Se responde a las preguntas: Cules son las principales funciones del sistema para sus usuarios ms importantes?. La respuesta est en el modelo de casos de uso simplificado. Cmo podra ser la arquitectura del sistema? Cul es el plan del proyecto y cunto costar desarrollar el producto?

Fase de Elaboracin: Durante la fase de elaboracin la mayora de los Casos de Uso son especificados en detalle y la arquitectura del sistema es diseada. Esta fase se focaliza en las -bilidades del proyecto. Se identifican los riesgos significativos y se preparan el calendario, el equipo de trabajo y el costo del proyecto. Fase de Construccin: Durante la fase de construccin, el foco del producto se mueve de la arquitectura de base a un sistema lo suficientemente completo como para llevarlo al usuario. El baseline de arquitectura crece en complejidad y se convierte en

un sistema completo, de la misma manera, se refina el disea para llevarlo a cdigo fuente.

Se construye el producto, se utilizan la mayor parte de los recursos, y al finalizar se cubren todos los casos de uso. La pregunta que se realiza es: Cubre el producto las necesidades de los usuarios como para hacer una primera entrega?

Fase de Transicin: En la fase de transicin el objetivos es garantizar que los requisitos se han cumplido, con la satisfaccin de las partes interesadas. Esta fase a menudo se inicia con una versin beta de la aplicacin. Otras actividades incluyen la preparacin del ambiente, se completan, se identifican y corrigen defectos. La fase de transicin termina con un cierre dedicado al aprendizaje de lecciones, las cuales quedan para futuros ciclos.El producto existe en versin Beta.

La metodologa de RUP es una forma disciplinada de asignar tareas y responsabilidades en una empresa de desarrollo (quin hace qu, cundo y cmo), este proceso de RUP estiman tareas y horario del plan midiendo la velocidad de iteraciones concerniente a sus estimaciones originales. RUP se enfocan fuertemente sobre la arquitectura del software. para su implementacin se hace a travs de cuatro etapas o fases y en cada una de estas etapas es desarrollada mediante el ciclo de iteraciones, la cual consiste en reproducir el ciclo de vida en cascada a menor escala, este tiene grandes ventajas con respectos a XP, ya que se enfoca en los requisitos y el diseo, as como tambin el cliente interacta con el equipo de desarrollo mediante reunionesa diferencia de la metodologa XP que el cliente es parte del equipo

Diferencias entre los modelos de proceso convencionales y giles

Metodologas giles:

Estn basadas en heurstica provenientes de prcticas de produccin de cdigos. Estn preparadas para cambios durante el proyecto. Son impuestas internamente (por el equipo). Proceso menos controlado. No existe contrato tradicional. Son bastante flexibles. El cliente es parte del equipo de desarrollo. Grupos pequeos y trabajando en el mismo sitio.

Menos nfasis en la arquitectura del software.

Metodologas convencionales:

Basadas en normas provenientes de estndares. Presentan cierta resistencia a los cambios. Impuestas externamente. Proceso mucho mas controlado, con numerosas polticas. Existe un contrato prefijado. Son un poco rgidas. El cliente interacta con el equipo de desarrollo mediante reuniones. Grupos grandes y posiblemente distribuidos. La arquitectura del software es esencial y se expresa mediante modelos.

Clasificacin de las metodologas segn su enfoque

Metodologas estructuradas
Se basan en la forma top-down. Entre estas estn:
Metodologas orientadas a procesos

Se basan en la utilizacin de un mtodo descendente de descomposicin funcional para definir los requisitos del sistema, dan lugar a un nuevo concepto "la especificacin estructurada" que es un modelo grfico particionado, descendente y jerrquico de los procesos del sistema. La metodologa orientada a procesos est compuesta por:

Diagrama de flujo de datos: Estos son diagramas que representan los procesos de datos que deben llevar acabo un sistema a distintos niveles de abstraccin y los datos que hay entre las funciones. Diccionario de datos: Es el conjunto de las definiciones de todos los datos que aparecen en el diagrama de flujos de datos. Especificaciones de procesos: como se obtienen las salidas del proceso a partir de sus entradas.

Las metodologas orientadas a procesos comprende una fase de anlisis estructurado y los mtodos de DeMarco, Gene y Sarson, Yourdon, son algunos que permiten lograr esto.

Metodologa de Demarco: se basa en el estudio del sistema fsico actual, derivacin del modelo lgico actual, derivacin al nuevo modelo lgico y creacin de modelos fsicos alternativos. Metodologa de Gane y Sarson: Es parecida a la de Demarco, la diferencia es que elimina el primer paso y crea uno nuevo que es cuando construye el modelo lgico del sistema. Tambin construye un modelo lgico de datos. Metodologa de Yourdon: Realiza los DFDs del sistema, a partir de los DFD realiza el diagrama de estructuras, evaluacin del diseo y preparacin del diseo.

Metodologas orientadas a datos

Son metodologas basadas en la informacin, ya que los datos son ms estables que los procesos. Primero se definen las estructuras de datos y, a partir de stos, se derivan los componentes procedimentales. Ejemplos de esta clasificacin son: metodologas de Jackson, Warnier, Warnier-Orr. Estas metodologas se dividen en jerrquicas y no jerrquicas: Metodologa orientada a datos jerrquicas:

La estructura de control del programa debe ser jerrquica y se debe derivar de la estructura de datos del programa. El proceso de diseo consiste en definir primero las estructuras de los datos de entrada y salida, mezclarlas todas en una estructura jerrquica de programa y despus ordenar detalladamente la lgica procedimental para que se ajuste a esta estructura. El diseo lgico debe preceder y estar separado del diseo fsico.

Metodologa orientada a datos no jerrquicas: Metodologa Ingeniera de la Informacin.

Planificacin: construir una arquitectura de la Informacin y una estrategia que soporte los objetivos de la organizacin . Anlisis: comprender las reas del negocio y determinar los requisitos del sistema. Diseo: establecer el comportamiento del sistema deseado por el usuario y que sea alcanzable por la tecnologa. Construccin: construir sistemas que cumplan los tres niveles anteriores.

Las metodologas estructuradas estn orientadas a procesos y a objetos. Intentan aplicar ingeniera para solucionar problemas tcnicos de un sistema de informacin, proponen la creacin de modelos, flujos y estructuras mediante un top-down. La metodologa orientada a procesos est fundamentada en el modelo entrada-proceso-salida., aplica un proceso interactivo para lograr un refinamiento progresivo. La metodologa orientada a objetos se divide en jerrquica y no jerrquica, la jerrquica est orientada a las entradas y salidas, las no jerrquicas definen un sistema a partir de la informacin que este maneja.

Metodologas para sistemas de tiempo real

Las metodologas en tiempo real procesan informacin orientada al control ms que a los datos. Se caracterizan por:

Concurrencia. Priorizacin de procesos. Comunicacin y sincronizacin entre tareas. Acceso simultneo a datos comunes. Permiten el manejo de interrupciones. Gestin de procesos concurrentes Respuesta oportuna ante eventos externos. Datos continuos o discretos.

Metodologas Orientadas a Objetos

La orientacin a objetos unifica procesos y datos encapsulndolos en el concepto de objetos. La esencia del desarrollo orientado a objetos es la identificacin y organizacin de conceptos del dominio de la aplicacin y no tanto de su representacin final en un lenguaje de programacin. Tiene dos enfoques distintos:

Revolucionario, puro u ortodoxo: Rompen con las metodologas tradicionales. La Orientacin a objetos se entiende como un cambio profundo de las metodologas estructuradas que se ven como obsoletas. Ejemplos: metodologas OOD de Booch, CRC/RDD de Wirfs-Brock. Sintetista o evolutivo:El anlisis y diseo estructurado se considera como la base para el desarrollo Orientado a objetos.

Ventajas de las metodologas orientadas a objetos: Reutilizacin. Las clases estn diseadas para que se reutilicen en muchos sistemas. Para maximizar la reutilizacin, las clases se construyen de manera que se puedan

adaptar a los otros sistemas. Un objetivo fundamental de las tcnicas orientadas a objetos es lograr la reutilizacin masiva al construir el software. Estabilidad. Las clases diseadas para una reutilizacin repetida se vuelven estables, de la misma manera que los microprocesadores y otros chips se hacen estables. El diseador piensa en trminos del comportamiento de objetos y no en detalles de bajo nivel. El encapsulamiento oculta los detalles y hace que las clases complejas sean fciles de utilizar. Se construyen clases cada vez ms complejas. Se construyen clases a partir de otras clases, las cuales a su vez se integran mediante clases. Esto permite construir componentes de software complejos, que a su vez se convierten en bloques de construccin de software ms complejo. Calidad. Los diseos suelen tener mayor calidad, puesto que se integran a partir de componentes probados, que han sido verificados y pulidos varias veces. Un diseo ms rpido. Las aplicaciones se crean a partir de componentes ya existentes. Muchos de los componentes estn construidos de modo que se pueden adaptar para un diseo particular. Integridad. Las estructuras de datos (los objetos) slo se pueden utilizar con mtodos especficos. Esto tiene particular importancia en los sistemas cliente-servidor y los sistemas distribuidos, en los que usuarios desconocidos podran intentar el acceso al sistema. Mantenimiento ms sencillo. El programador encargado del mantenimiento cambia un mtodo de clase a la vez. Cada clase efecta sus funciones independientemente de las dems. Una interfaz de pantalla sugestiva para el usuario. Hay que utilizar una interfaz de usuario grfica de modo que el usuario apunte a iconos o elementos de un men desplegado, relacionados con los objetos. En determinadas ocasiones, el usuario puede ver un objeto en la pantalla. Ver y apuntar es ms fcil que recordar y escribir. Independencia del diseo. Las clases estn diseadas para ser independientes del ambiente de plataformas, hardware y software. Utilizan solicitudes y respuestas con formato estndar. Esto les permite ser utilizadas en mltiples sistemas operativos, controladores de bases de datos, controladores de red, interfaces de usuario grficas, etc. El creador del software no tiene que preocuparse por el ambiente o esperar a que ste se especifique. Interaccin. El software de varios proveedores puede funcionar como conjunto. Un proveedor utiliza clases de otros. Existe una forma estndar de localizar clases e interactuar con ellas. El software desarrollado de manera independiente en lugares ajenos debe poder funcionar en forma conjunta y aparecer como una sola unidad ante el usuario.

Computacin Cliente-Servidor. En los sistemas cliente-servidor, las clases en el software cliente deben enviar solicitudes a las clases en el software servidor y recibir respuestas. Una clase servidor puede ser utilizada por clientes diferentes. Estos clientes slo pueden tener acceso a los datos del servidor a travs de los mtodos de la clase. Por lo tanto los datos estn protegidos contra su corrupcin. Computacin de distribucin masiva. Las redes a nivel mundial utilizarn directorios de software de objetos accesibles. El diseo orientado a objetos es la clave para la computacin de distribucin masiva. Las clases de una mquina interactan con las de algn otro lugar sin saber donde residen tales clases. Ellas reciben y envan mensajes orientados a objetos en formato estndar. Mayor nivel de automatizacin de las bases de datos. Las estructuras de datos (los objetos) en las bases de datos orientadas a objetos estn ligadas a mtodos que llevan a cabo acciones automticas. Una base de datos OO tiene integrada una inteligencia, en forma de mtodos, en tanto que una base de datos relacional bsica carece de ello.

Las metodologas orientadas a objetos han evolucionado para ayudar a los desarrolladores a explotar el poder de los lenguajes de programacin basados en objetos y orientados a objetos, utilizando las clases y objetos como bloques de construccin bsicos. Una orientacin a objetos nos ayuda a hacer frente a la inherente complejidad de muchos tipos de sistemas.

Que metodologa es conveniente usar?

Tener metodologas diferentes para aplicar de acuerdo con el proyecto que se desarrolle resulta una idea interesante. Estas metodologas pueden involucrar prcticas tanto de metodologas giles como de metodologas tradicionales. De esta manera podramos tener una metodologa para cada proyecto, la problemtica sera definir cada una de las prcticas, y en el momento preciso definir parmetros para saber cual usar.Es importante tener en cuenta que el uso de un mtodo gil no es para todos. Sin embargo, una de las principales ventajas de los mtodos giles es su peso inicialmente ligero y por eso las personas que no estn acostumbradas a seguir procesos encuentran estas metodologas bastante agradables. Por otro lado, las metodologas tradicionales o convencionales permiten crear software de manera mas segura ya que estas entan mas establecidas segn por sus pasos.

Modelos de procesos utilizados en el desarrollo de software

Modelado de Negocios
Para conseguir sus objetivos, una empresa organiza su actividad por medio de un conjunto de procesos de negocio. Cada uno de ellos se caracteriza por una coleccin de

datos que son producidos y manipulados mediante un conjunto de tareas, en las que ciertos agentes (por ejemplo, trabajadores o departamentos) participan de acuerdo a un flujo de trabajo determinado. Adems, estos procesos se hallan sujetos a un conjunto de reglas de negocio, que determinan las polticas y la estructura de la informacin de la empresa. Por tanto, la finalidad del modelado del negocio es describir cada proceso del negocio, especificando sus datos, actividades (o tareas), roles (o agentes) y reglas de negocio. Con esta disciplina se pretende llegar a un mejor entendimiento de la organizacin. Los objetivos especficos del modelado de negocio son: 1. Asegurar que clientes, usuarios finales y desarrolladores tengan un entendimiento comn de la organizacin objetivo. 2. Derivar los requerimientos del sistema necesarios para apoyar a la organizacin objetivo en su mejora. 3. Entender el problema actual en la organizacin objetivo e identificar potenciales mejoras. 4. Entender la estructura y la dinmica de la organizacin para la cual el sistema va a ser desarrollado (organizacin objetivo).

Para lograr estos objetivos, el modelado de negocio describe como desarrollar una visin de la nueva organizacin, basado en esta visin se definen procesos, roles y responsabilidades de la organizacin por medio de un Modelo de Casos de Uso del Negocio. Los artefactos del modelo de negocio sirven como entrada y referencia para la definicin de los requerimientos del sistema. La importancia de esta disciplina radica en que sin el panorama completo del alcance del negocio y sin el entendimiento de sus procesos no podrn identificarse las necesidades inmediatas de mejora y continuidad relativa a las actividades relacionadas con los sistemas informticos, que son el producto final del desarrollo.

Orientacin del modelado de negocio. Dominios principales en los que se emplea: Dominios orientados al negocio Gerencia Teora de Organizaciones E-business, E-commerce Dominios orientados a la tecnologa

Sistemas de Informacin Ingeniera de Software Informtica Industrial

Los dominios definen dos puntos de vista diferentes del Modelado de:

Orientado al valor/cliente

Busca explicar cmo la empresa crea valor para el cliente, que valor le proporciona a sus clientes los productos o servicios de una empresa, en este caso entenderemos el modelo de negocio como una herramienta conceptual que tiene un conjunto de objetos, conceptos y relaciones con el objetivo de expresar la lgica del negocio de una empresa Osterwalde , Pigneur (2005).

Orientado a la actividad/rol

Hace nfasis en el modelado de los procesos y actores de la empresa , en las actividades que realiza la empresa y quienes participan en ellas, el modelo de negocio se define en este caso como una abstraccin de cmo una empresa funciona proporciona una vista simplificada de la estructura del negocio que acta como la base para la comunicacin, mejoras o innovacin y define los requisitos de los sistemas de informacin que intervienen en la empresa Erikson y Peker (2000).

Un Modelado del Negocio es una descripcin de los elementos que constituyen una organizacin, o una parte de ella, as como de las relaciones entre estos elementos. Un Modelo del Negocio es una conceptualizacin de una empresa u organizacin, es la caracterizacin de los aspectos ms significativos de la empresa o de una parte de ella, para ello se debe tener claro cul es el fin que se busca con ese modelo, para as tener claro los elementos del negocio que se deseen representar.

Modelado de Negocios e Ingeniera de Requisitos

El Modelado de Negocios y la Ingeniera de Requisitos son los dos procesos tcnicos iniciales del desarrollo ingenieril de aplicaciones de software. El Modelado de Negocios se realiza en el espacio del problema; se encarga de estudiar el dominio de la aplicacin con la finalidad de formular y analizar el problema que da origen a la aplicacin. La Ingeniera de Requisitos, por su parte, ocurre en el espacio de la solucin; se encarga, por lo tanto, de caracterizar la aplicacin en base a las necesidades y los requisitos que los usuarios de la aplicacin tienen. El proceso de ingeniera de requerimientos se utiliza para definir todas las actividades involucradas en el descubrimiento, documentacin y mantenimiento de los requerimientos para un producto de software determinado, donde es muy importante

tomar en cuenta la viabilidad de llevar a cabo el software (si es factible llevarlo a cabo o no), pasando posteriormente por un subproceso de obtencin y anlisis de requerimientos, su especificacin formal, para finalizar con el subproceso de validacin donde se verifica que los requerimientos realmente definen el sistema que quiere el cliente.
En el desarrollo de software, el Modelado de Negocios aporta informacin esencial para la Ingeniera de Requisitos, ya que en el modelado de negocio se ve lo que es el problema y en la ingeniera de requisitos se define la solucin al problema.

Cadena de Valor

La cadena de valor es esencialmente una forma de anlisis de la actividad empresarial mediante la cual descomponemos una empresa en sus partes constitutivas, buscando identificar fuentes de ventaja competitiva en aquellas actividades generadoras de valor. La cadena de valor representa todas las actividades que se llevan a cabo en una empresa, en la cual se realiza una separacin entre las actividades de mayor inters (actividades primarias) y las actividades que le sirven de apoyo con la finalidad de prestar mayor atencin y centrarse en aquellas actividades que generan mayores ventajas al momento de competir con otras empresas. 20 Como se menciono anteriormente la cadena de valor se divide en actividades primarias y secundarias

Actividades primarias: Conforman la creacin fsica del producto, las actividades relacionadas con su venta y la asistencia post-venta.

Se dividen en: Logstica interna Operaciones

Logstica externa Ventas y marketing: actividades con las cuales se da a conocer el producto. Servicios post-venta (mantenimiento): actividades destinadas a mantener o realizar el valor del producto.

Actividades secundarias o de apoyo, estn conformadas por:

Infraestructura de la organizacin Direccin de recursos humanos: bsqueda, contratacin y motivacin del personal. Desarrollo de tecnologa (investigacin y desarrollo) Abastecimiento o compras

La cadena de valor es una herramienta de gran importancia ya que permite determinar cuales son aquellas actividades de valor de la empresa. Es muy til que las empresas conozcan no solo su cadena de valor si no tambin la de sus competidores, ya que esta proporciona un mejor anlisis interno de la organizacin, as como tambin identificar las ventajas competitivas y comprender de una mejor manera el comportamiento de los costos y las diversas fuentes de diferenciacin con la competencia.

Conclusiones

Una metodologa se basa en una combinacin de los modelos de proceso genricos para obtener como beneficio un software que soluciones un problema La trascendencia de las metodologas se ha hecho notoria, pasando de solo programar, establecer funciones en etapas o mdulos, objetos, y por ltimo agilizar el desarrollo del software y minimizar los costos. En el desarrollo convencional todo el programa est en un solo bloque, con ejecucin secuencial de instrucciones En el desarrollo estructurado los programas estn divididos en distintos bloques, estos bloques tienen funciones que se van confeccionado en forma de arriba-abajo, empezando desde las generales hasta las particulares, hasta llegar a detallar cada uno de los procedimientos y su interaccin. El desarrollo orientado a objetos comprende dividir un programa en clases, donde estas clases estarn estructuradas por propiedades, atributos, variables, pretendiendo simular y describir de manera conceptual a un objeto.

Los mtodos giles fueron pensados especialmente para equipos de desarrollo pequeos, con plazos reducidos, requisitos voltiles y nuevas tecnologas. El modelado de negocio describe como desarrollar una visin de la nueva organizacin, basado en esta visin se definen procesos, roles y responsabilidades de la organizacin por medio de un Modelo de Casos de Uso del Negocio Los modelos de procesos permiten al analista de sistemas desarrollar un plan de requisitos del software, permiten establecer un trabajo en forma ordenada, adems que existen muchos modelos que se adaptan a las exigencias del proyecto, solo debemos saber cual nos conviene.

Referencias
1. Alonso, F. y Martnez, L. (2005). Introduccin a la ingeniera del software: modelos de desarrollo de programas (primera edicin). Espaa: Delta Publicaciones. Pg. 75-76 2. Sommerville, I. (2005). Ingeniera del software (Sptima Edicin). Espaa: Pearson Educacin. 3. Hernn, M. (2004). Diseo de una Metodologa gil de Desarrollo de Software. Tesis de Grado de Ingeniera en Informtica. Universidad de Buenos Aires. Pg. 11-12 4. Sommerville, I. (2006). Ingeniera del software (Sptima Edicin). Madrid. Pg. 62 5. Espinoza, A. Metodologas de desarrollo de software [documento en lnea].Disponible en: www.slideshare.net/juliopari/4-clase-metodologia-de-desarrolode-software [consulta: 11 de junio de 2012] 6. Carballar, D. Ingeniera de software [documento en lnea]. www.eduinnova.es/dic09/Ingenieria_Software.pdf [consulta: 10 de junio de 2012] 7.Disponible en la www.angelfire.com/scifi/jzavalar/apuntes/IngSoftware.html#paradigmaOO [consulta: 10 de junio de 2012] web:

8. Kenneth, E. y Kendall, J. (2005). Analisis Y Diseo de Sistemas(Sexta edicin). Mxico. 9. Sols, M. (2003). Una explicacin de la programacin extrema (XP). Madrid. Pg. 103 10. Ordonez (2011). Metodo de Desarrollo de sistemas dinamicos[documento en lnea]. Disponible en: www.slideshare.net/oscarfico/metodos-dinamicos [consulta: 8 de junio de 2012] 11. Citn, M.(2006). Mtodo gil scrum aplicado al desarrollo de un software de trazabilidad. Argentina.

12. Amaro , S. y Valverde, J. (2007). Metodologas giles. Per:Trujillo. 13. Mendez, E. (2006). Modelo de Evaluacion de Metodologia para el Desarrollo de Software. Trabajo de Grado, Universidad Catlica Andrs Bello,Caracas,Vzla. 14. Cans J. y Letelier P. (2003, noviembre). Metodologas giles en el desarrollo de software [resumen]. Taller realizado en el marco de las VIII jornadas de Ingeniera del software y bases de datos en la Universidad politcnica de Valencia, Espaa-Alicante. 15. Laboratorio Nacional de Calidad del Software de INTECO. (2009, Marzo) Ingeniera del software: metodologas y ciclos de vida. Espaa. 16. Oscar lvarez Imaz. (2008, Abril). "Introduccin a RUP" Versin 0.1 17. Alonso, F. y Martnez, L. (2005). Introduccin a la ingeniera del software: modelos de desarrollo de programas (primera edicin). Espaa: Delta Publicaciones. Pg. 112-113 18. Disponible en la web: www.laprole431.blogspot.com/2010/12/que-es-un-modelode-desarrollo.html [consulta: 6 de julio de 2012] 19. Disponible en la web: www.ingenieraupoliana.blogspot.com/2010/10/modelo-dedesarrollo-concurrente.html [consulta: 6 de julio de 2012] 20. David, F. (2008). Conceptos de Administration Estratgica (Decimoprimera Edicin). Editorial Pearson Educacin, Mxico.
21. de 2012] Disponible en la web:

www.aprendecomputofacil.blogspot.com/2009_07_01_archive.html [consulta: 10 de julio

ANLISIS Y DETERMINACIN DE REQUERIMIENTOS

Herramientas para determinar requerimientos de sistemas

La determinacin de requerimientos es el estudio de un sistema para conocer como trabaja y donde es necesario efectuar mejoras, dando como resultado una evaluacin de la forma como trabajan los mtodos empleados y si es necesario o posible realizar ajustes.

Un requerimiento es una caracterstica que debe incluirse en un nuevo sistema. Esta puede ser la inclusin de determinada forma para capturar o procesar datos, producir informacin, controlar una actividad de la empresa o brindar soporte a la gerencia. Es as como la determinacin de requerimientos vincula el estudio de un sistema existente con la recopilacin de detalles relacionados con l.

Actividades de la determinacin de requerimientos Es til ver la determinacin de requerimientos a travs de tres grandes actividades: Anticipacin de requerimientos: La experiencia de los analistas les permite anticipar ciertos problemas o caractersticas y requerimientos para un nuevo sistema. Por un lado, la experiencia de estudios previos puede conducir a la investigacin de reas que no considerara un analista novato. Tener las bases necesarias para saber que preguntar o que aspectos investigar puede ser de beneficio substancial para la organizacin. Por otra parte, si se introducen sesgos o atajos al conducir la investigacin entonces es muy probable que la anticipacin de requerimientos se convierta en un problema. Por lo tanto, siempre deben darse lineamientos para estructurar una investigacin alrededor de cuestiones bsicas con la finalidad de evitar consecuencias indeseables de la anticipacin de requerimientos.

Investigacin de requerimientos: Es la ms importante del anlisis de sistemas. Los analistas estudian el sistema actual con la ayuda de varias herramientas y habilidades, y documentan caractersticas para, mas adelante, emprender el anlisis. La investigacin de requerimientos depende de las tcnicas para encontrar datos, que sern explicadas mas adelante, e incluyen los mtodos para documentar y describir las caractersticas de l sistema.

Especificaciones 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:

- Anlisis de datos basados en hechos reales: Se examinan los datos recopilados durante el estudio, incluidos en la documentacin de flujo de datos y anlisis de decisiones, para examinar el grado de desempeo del sistema y si cumple con las demandas de la organizacin.

Identificacin de requerimientos esenciales: Caractersticas que deben incluirse en el nuevo sistema y que van desde detalles e operacin hasta criterios de desempeo. - Seleccin de estrategias para satisfacer los requerimientos: Mtodos que sern utilizados para alcanzar los requerimientos establecidos seleccionados. Estos forman la base para el diseo de sistemas, los cuales deben cumplir con la especificacin de requerimientos.

La especificacin de requerimientos implica gran responsabilidad para los analistas de sistemas, ya que la calidad de trabajo realizado en esta etapa se vera reflejada mas adelante en las caractersticas del nuevo sistema.

Requerimientos bsicos Los analistas estructuran su investigacin al buscar respuestas a las siguientes cuatro importantes preguntas: Cul es el proceso bsico de la empresa? Qu datos utiliza o produce esta empresa? Cules son los limites impuestos por el tiempo y la carga de trabajo? Qu controles de desempeo utiliza?

Comprensin del proceso Los analistas hacen preguntas que, cuando reciben la 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:

Cual es la finalidad de esta actividad dentro de la empresa? Qu pasos se siguen para llevarla a cabo? Dnde se realizan estos pasos? Quines lo realizan? Cunto tiempo tardan n efectuarlos? Con cuanta frecuencia lo hacen? Quines emplean la informacin resultante?

Identificacin de los datos empleados e informacin generada El siguiente paso es detectar que datos se utilizan para llevar a cabo cada actividad. Por ejemplo, para reabastecer el inventario, el comprador requiere datos que describan para cada articulo la cantidad existente, la demanda esperada, el nombre del proveedor y el costo. Para saber cuando hacer cada pedido, el comprador debe considerar el tiempo de entrega de la mercanca. Por otra parte, muchas transacciones comerciales producen informacin til para los gerentes cuando estos evalan el desempeo de empleados, negocios y sistemas; esta informacin tambin puede ser de utilidad, en otro contexto, para los gerentes y analistas. Por ejemplo, los analistas curiosos encuentran que los datos relacionados con e abasto del inventario y almacenaje tambin proporcionan informacin con respecto a demandas del almacn, practicas de compras, ventas y flujo de efectivo.

Frecuencia y volumen del proceso La frecuencia con la que se presentan actividades en una empresa cambia mucho. Por ejemplo, algunas como el pago de impuestos suceden pocas veces al ao mientras que el pago de la nomina de empleados es algo que ocurre cada semana. Por consiguiente, los analistas deben investigar con cuanta frecuencia se repite una actividad. Conocer esta informacin puede llevar al analista a considerar mas preguntas importantes para determinar la razn de esta frecuencia y su efecto sobre las actividades de la empresa.

Muchas veces la forma ms fcil de obtener esta informacin es identificar el objetivo de la actividad: Cul es la causa de la actividad? En ocasiones los analistas se refieren a la causa directa como la funcin de iniciacin. Las actividades pueden ser iniciadas por los clientes por sucesos y por el paso del tiempo. Los analistas corren el riesgo de no comprender adecuadamente la razn de una actividad y darle mayor o menos importancia de la que tiene en el sistema, a menos que conozcan que es lo que inicia la actividad.

Identificacin de controles En situaciones donde se ejerce buen control ya sea por parte de la gerencia o por el seguimiento del proceso, quizs no sea problema determinar si una actividad se ha llevado a cabo en forma adecuada. Aun as, los analistas deben examinar los mtodos de control durante la etapa de anlisis: existen estndares especficos de desempeo?, quin se encarga de comparar el desempeo contra los estndares?, cmo se detectan los errores?, cmo se corrigen los errores?, se cometen demasiados errores?. La falta o debilidad de los controles es un descubrimiento importante en cualquier investigacin de sistemas.

Requerimientos de las transacciones de los usuarios Los sistemas a nivel de transacciones, capturan, procesan y almacenan datos por alguna razn. Por ejemplo, en un sistema de pedidos, los pedidos de los clientes son procesados de forma tal quesea posible enviar los artculos indicados. Este proceso se aplica a todos los pedidos que se reciben. Los analistas seleccionados para trabajar en un sistema de procesamiento de pedidos, deben conocer todo lo relacionado con la forma en que se procesan estas transacciones. Para entender los requerimientos de las transacciones, los analistas sin lugar a dudas formularan preguntas como las siguientes:

Qu es lo que forma parte de la transaccin que esta siendo procesada? Qu es lo que inicia la transaccin? Quin inicia los pedidos? Con que propsito? Con que frecuencia ocurren los pedidos? Qu volumen esta asociado con cada pedido? Existen diferentes condiciones que pueden afectar la forma en que se procesan los pedidos? Que detalles son necesarios para procesar la transaccin? Qu informacin se genera? Qu datos se guardan?

Requerimientos de decisin de los usuarios A diferencia de las actividades de transaccin, las relacionadas con decisiones no siguen un procedimiento especifico. Las rutinas no son muy claras y es posible que los controles sean vagos. Las decisiones se toman al integrar la informacin en forma tal que los gerentes puedan saber que acciones emprender. Es probable que los sistemas de decisin tengan que ver con el pasado, el presente y el futuro. Algunos brindan soporte para decisiones recurrentes mientras que otros son nicos y no recurrentes. Los analistas que investigan sistemas para el soporte de decisiones, deben formular las mismas preguntas sobre frecuencia y volumen mencionadas anteriormente, pero tambin deben hacer otras para determinar los requerimientos de las decisiones:

1- Qu informacin se utiliza para tomar la decisin? 2- Cul es la fuente de informacin? Qu sistemas de transacciones producen los datos 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? 3- Cmo se deben procesar los datos para producir la informacin necesaria?

4- Cmo debe plantearse la informacin?

Estas preguntas tambin sealan la relacin entre los sistemas de transacciones y los de decisiones. Informacin muy valiosa puede perderse si los sistemas de transacciones no capturan y guardan los datos necesarios para las decisiones. Los sistemas de inventario capturan informacin relacionada con los continuos pedidos, recepciones, ventas y envi de artculos. Los datos que estos sistemas almacenan son procesados nuevamente para generar informacin de manera peridica para analizar ventas, determinar polticas de procesos o decidir planes de mercadotecnia para lneas de productos.

Todo esto significa que: 1) los analistas que investigan sistemas para el soporte de decisiones deben considerar los sistemas de procesamiento de transacciones y 2) que los sistemas eficaces para el soporte de decisiones requieren primero de procedimientos adecuados para el procesamiento de transacciones.

Requerimientos de toda organizacin En las empresas, los departamentos dependen unos de otros para brindar servicios, fabricar productos y satisfacer a los clientes. Por consiguiente, el trabajo hecho en un departamento afecta al de los otros. Cuando los analistas estudian sistemas para un departamento tambin deben evaluar las implicaciones para los dems departamentos con los que interacta el sistema bajo investigacin. Es responsabilidad del analista identificar las dependencias entre departamentos y determinar como los afecta un proyecto de sistemas. En muchas ocasiones, cuando trabajan con usuarios, los analistas escuchan como deberan manejarse las excepciones. Claro esta que una aplicacin debe disearse para dar cabida a los eventos rutinarios. Pero los analistas deben abordar lo que esta fuera de la rutina ya que estos sucesos son una prueba de fuego para el sistema. Deben asegurarse de hacer preguntas a los usuarios que saquen a luz los casos excepcionales: El procedimiento que emplea el usuario siempre trabaja? Con cuanta frecuencia es necesario hacer una excepcin al procedimiento? Todos los empleados siguen el mismo procedimiento?

TCNICAS PARA ENCONTRAR HECHOS Los analistas utilizan mtodos especficos, denominados tcnicas para encontrar hechos, con el objeto de reunir datos relacionados con los requerimientos. Entre estos se incluyen la entrevista, el cuestionario, la revisin de los registros y la observacin. En general, los analistas emplean mas de una de estas tcnicas para llevar a cabo una investigacin amplia y exacta.

Entrevistas: Los analistas emplean la entrevista para reunir informacin proveniente de personas o de grupos. Por lo comn, los entrevistados son usuarios de los sistemas existentes o usuarios en potencia del sistema propuesto. En algunos casos, los entrevistados son gerentes o empleados que proporcionan datos para el sistema propuesto o que sern afectados por el. Aunque algunos analistas prefieren la entrevista sobre otras tcnicas, esta no siempre es la mejor fuente de datos sobre la aplicacin. Dado que la entrevista lleva tiempo, es necesario utilizar otros mtodos para obtener la informacin necesaria para conducir una investigacin. Las entrevistas pueden clasificarse como estructuradas o no estructuradas. Las entrevistas no estructuradas utilizan un formato pregunta-respuesta y son apropiadas cuando el analista desea adquirir informacin general del sistema. Este formato anima a los entrevistados a compartir sus sentimientos, ideas y creencias. Por otro lado, las entrevistas estructuradas utilizan preguntas estndar en un formato de respuesta abierta o cerrada. El primero permite que el entrevistado de respuesta a las preguntas con sus propias palabras; el segundo utiliza un conjunto anticipado de respuestas. Cada enfoque tiene sus ventajas y desventajas.

Cuestionarios: El uso de los cuestionarios permite a los analistas reunir informacin proveniente relacionada con varios aspectos de un sistema de un grupo grande de personas. El empleo de formatos estandarizados para las preguntas puede proporcionar datos mas confiables que otras tcnicas; por otra parte, su amplia distribucin asegura el anonimato de los encuestados, situacin que puede conducir a respuestas mas honestas. Sin embargo, este mtodo permite al analista observar las excepciones o reacciones de los encuestados. Asimismo, la respuesta puede ser limitada ya que es posible que no tenga mucha importancia para los encuestados llenar el cuestionario. Con frecuencia los analistas utilizan cuestionarios abiertos para descubrir sentimientos, opiniones y experiencias generales o para explotar un proceso o problema. Los cuestionarios cerrados controlan el marco de referencia al presentar a los encuestados respuestas especificas para escoger.

Revisin de los registros Varios tipos de registros y reportes pueden proporcionar al analista informacin valiosa con respecto a las organizaciones y a sus operaciones. Al revisar los registros, el analista examina la informacin asentada en ellos relacionada con el sistema y los usuarios. La revisin de los registros puede efectuarse al comienzo del estudio, como introduccin, o tambin despus, y sirve de base para completar las operaciones actuales. Por lo tanto los registros pueden indicar que esta sucediendo.

Los registros incluyen manuales de polticas, reglamentos y procedimientos estndares de operacin utilizados por la mayor parte de las organizaciones como guas para los gerentes y empleados. Estos registros no indican la forma en la que se desarrollan las actividades en realidad, donde se encuentra todo el poder de la toma de decisiones, o como se realizan todas las tareas. Sin embargo, pueden ser de gran ayuda para el analista en su afn de comprender el sistema al familiarizarlo con aquellas operaciones que necesitan apoyo con las relaciones formales dentro de la organizacin.

Observacin La observacin permite al analista ganar informacin que no se puede obtener por otras tcnicas. Por medio de la observacin el analista obtiene informacin de primera mano sobre la forma en que se efectan las actividades. El mtodo es mas til cuando el analista necesita observas, por un lado, la forma en que se manejan los documentos y se llevan a cabo los procesos y, por otro, si se siguen todos los pasos especificados. Los observadores experimentados saben que buscar y como evaluar la significancia de lo que observan.

HERRAMIENTAS DECISIONES

PARA

DOCUMENTAR

PROCEDIMIENTOS

Seguir procedimientos y tomar decisiones son aspectos importantes de cualquier empresa. Las decisiones y procedimientos son de importancia para el analista cuando este conduce una investigacin de sistemas dentro de la empresa. Las herramientas ayudan al analista a integrar los datos recopilados por los diversos mtodos estudiados anteriormente. Pero, como sucede con todas las herramientas, la que emplea el analista para documentar procedimientos y decisiones deben utilizarse adecuadamente. Se presentan tres herramientas para documentar procedimientos: rboles de decisin, tablas de decisin y espaol estructurado.

Conceptos bsicos sobre decisiones Cuando se analizan procedimientos y decisiones el primer paso es identificar condiciones y acciones, conceptos comunes a todas las actividades.

Condiciones y variables de decisin Cuando se observa un sistema y se pregunta cules son las posibilidades? O qu puede suceder?, en realidad se esta preguntando por las condiciones, que son los

posibles estados de una entidad. Las condiciones cambian, y es por eso que el analista se refiere a ellas como variables de decisin. Al documentar la decisin de cmo procesar un procedimiento, el investigador debe identificar tanto las condiciones permisibles como las relevantes que pueden presentarse en determinada situacin. Solo deben incluirse en el estudio aquellas condiciones que son relevantes. El hecho de que una factura este firmada o no es una variable relevante. Sin embargo, el tamao de la hija de papel sobre la que esta impresa probablemente no lo sea.

Acciones Cuando se conocen todas las posibles condiciones, el siguiente paso del analista es determinar que hacer cuando se presentan algunas de estas. Las acciones son opciones, que comprenden pasos, actividades o requerimientos, que puede elegir una persona cuando se enfrenta ante un conjunto de condiciones. En muchos procedimientos el analista debe considerar combinaciones de condiciones y acciones. Como ayuda para comprender y adaptar estas combinaciones, emplean rboles de decisin, tablas de decisin y el espaol estructurado.

rboles de decisin Las personas pueden tener diferentes formas de decir lo mismo. Tener diferentes formas e decir la misma cosa pueden crear dificultades de comunicacin durante los estudios de sistemas. Por consiguiente, el analista busca evitar las malas interpretaciones. Asimismo, el analista necesita organizar la informacin recopilada con respecto a la toma de decisiones.

Caractersticas de los rboles de decisin El rbol de decisin es un diagrama que representa en forma secuencial condiciones y acciones; muestra que condiciones se consideran en primer lugar, cuales en segundo y as sucesivamente. Este mtodo tambin permite mostrar la relacin que existe entre cada condicin y el grupo de acciones permisibles asociado con ella. La raz del rbol es el punto donde comienza la secuencia de decisin. La rama a seguir depende de las condiciones existentes y de la decisin que debe tomarse. Al avanzar de izquierda a derecha por una rama en particular, se obtiene una serie de toma de decisiones. Despus de cada punto de decisin, se encuentra el siguiente conjunto de decisiones a considerar. De esta forma, los nodos del rbol representan condiciones y sealan la necesidad de tomar una determinacin relacionada con la existencia de alguna de estas, antes de seleccionar la siguiente trayectoria. La parte que se encuentra a

la derecha del rbol indica las acciones que deben realizarse, las que a su vez dependen de la secuencia de condiciones que las proceden.

Uso de rboles de decisin El desarrollo de rboles de decisin beneficia al analista en dos formas. Primero que todo, la necesidad de describir condiciones y acciones llevan a los analistas a identificar de manera formal las decisiones que actualmente deben tomarse. De esta forma, es difcil para ellos pasar por alto cualquier etapa del proceso de decisin, sin importar que este dependa de variables cualitativas o cuantitativas. Los rboles de decisin tambin obligan a los analistas a considerar la secuencia de las decisiones.

Identificacin de los requerimientos de datos Los rboles de decisin tambin son tiles para identificar los requerimientos de datos crticos que rodean al proceso de decisin; es decir, los rboles indican los conjuntos de datos que la gerencia requiere para formular decisiones o tomar acciones. Los rboles de decisiones se construyen despus de completar el anlisis de flujo de datos, entonces es posible que los datos crticos se encuentren ya definidos en el diccionario de datos. Si nicamente se utilizan rboles de decisin, entonces el analista debe tener la certeza de identificar con precisin cada dato necesario para tomar la decisin. Los analistas necesitan describir y definir todos los datos utilizados en la toma de decisiones para que sea posible disear el sistema de forma tal que los genere apropiadamente.

Como evitar los problemas que se generan al utilizar rboles de decisin Los rboles de decisin no siempre son la mejor herramienta para el anlisis de decisiones. El rbol de decisin de un sistema complejo con muchas secuencias de pasos y combinaciones de condiciones puede tener un tamao considerable. El gran numero de ramas que pertenecen a varias trayectorias constituye mas un problema que una ayuda para el anlisis. En estos casos el analista corre el riesgo de no determinar que polticas o estrategias de la empresa son la gua para la toma de decisiones especificas.

Tablas de decisin

La tabla de decisin es una matriz de renglones y columnas que indican condiciones y acciones. Las reglas de decisin, incluidas en una tabla de decisin, establecen el procedimiento a seguir cuando existen ciertas condiciones.

Caractersticas de las tablas de decisin La taba de decisin esta integrada por cuatro secciones: identificacin de condiciones, entradas de condiciones, identificacin de acciones y entradas de acciones. La identificacin de condiciones seala aquellas que son relevantes. Las entradas de condiciones indican que valor, si es que lo hay, se debe asociar para una determinada condicin. La identificacin de acciones enlista el conjunto de todos los pasos que se deben seguir cuando se presenta cierta condicin. Las entradas de acciones muestran las acciones especificas del conjunto que deben emprenderse cuando ciertas condiciones o combinaciones de estas son verdaderas. En ocasiones se aaden notas en la parte inferior de la tabla para indicar cuando utilizar la tabla o para diferenciarla de otras tablas de decisin. Las columnas del lado derecho de la tabla enlazan condiciones y acciones, forman reglas de decisin que establecen condiciones que deben satisfacerse para emprender un determinado conjunto de acciones. La regla de decisin incorpora todas las condiciones que deben ser ciertas y no solo una a la vez.

Como construir tablas de decisin Para desarrollar tablas de decisin, los analistas deben emprender los siguientes pasos:

1-

Determinar los factores determinados como ms relevantes en la toma de decisiones. Esto permite identificar las condiciones en la decisin. Cada condicin seleccionada debe tener la caracterstica de ocurrir o no ocurrir; en este caso no es posible la ocurrencia parcial.

2- Determinar los pasos o actividades ms factibles bajo condiciones que cambian. Esto permite identificar las acciones. 3- Estudiar las diferentes posibilidades de combinaciones de condiciones. Para cualquier numero n de condiciones, existen 2 a la n combinaciones a considerar. 4- Llenar la tabla con las reglas de decisin. Existen dos formas para hacerlo. La primera, y ms larga, es llenar los renglones de condicin con valores si o no para cada combinacin posible de condiciones. Esto es, llenar la primera mitad del rengln con Si y la segunda con No. El siguiente rengln se llena alternando con S y N cada 25% del rengln; es decir, 25% Si, 25% No, 25% Si y 25% No. Se repite de nuevo este

proceso: se llena ada rengln faltante en forma alterna con S y con N, dividiendo cada vez por potencias sucesivas de 2. El otro mtodo para llenar la tabla considera una condicin a la vez y, por cada condicin adicional le aade una tabla pero sin considerar las combinaciones de condiciones y acciones duplicadas.

Verificacin de tablas de decisin Despus de construir una tabla, los analistas verifican que sea correcta y completa con la finalidad de asegurar que la tabla incluye todas las condiciones junto con las reglas de decisin que las relacionan con las acciones. Asimismo, los analistas tambin deben examinar la tabla para encontrar redundancias y contradicciones. Eliminacin de la redundancia: Las tablas de decisin pueden volverse muy grandes y difciles de manejar si se permite que crezcan sin ningn control. Remover las entradas redundantes puede ser de ayuda para manejar el tamao de la tabla. La redundancia se presenta cuando las siguientes condiciones son verdaderas al mismo tiempo: 1) dos reglas de decisin son idnticas salvo para una condicin del rengln y 2) las acciones para las dos reglas son idnticas. Supresin de contradicciones: las reglas de decisin son contradictorias entre si cuando dos o ms reglas tienen el mismo conjunto de contradicciones pero sus acciones son diferentes. Las contradicciones indican que la informacin que tiene el analista es incorrecta o bien existe un error en la construccin de la tabla. Sin embargo, muchas veces la contradiccin es resultado de las dependencias en la informacin que recibe el analista de diferentes personas con respecto a la forma en que estas toman decisiones. Se puede tomar una decisin especifica utilizando diferentes reglas. Encontrar tales discrepancias puede ser de gran utilidad para el analista que trabaja con la finalidad de mejorar una situacin de decisin.

Tipos de entradas en una tabla Forma de entrada limitada: La estructura bsica de la tabla consistentes en S y N y entradas en blanco, es la forma de entrada limitada. Este es uno de los formatos mas comunes. Existen otros dos que tambin se emplean de manera amplia. Forma de entrada extendida: Esta forma reemplaza las S y las N con acciones que le indican al lector como decidir. En este formato, los identificadores de condicin y accin no estn completos y es la razn por la que las entradas contienen mas detalles que una S y N. Forma de entrada mixta: En ocasiones los analistas prefieren combinar en la misma tabla las caractersticas de los dos mtodos anteriores. En general, debe utilizarse solo

una forma en cada seccin de la tabla, pero entre las secciones de condiciones y acciones se puede utilizar cualquier forma.

Forma ELSE: Esta es otra variante de las tablas de decisin que tiene como finalidad omitir la repeticin por medio de reglas ELSE . Para construir una tabla de decisin en la forma ELSE, se especifican las reglas, junto con las entradas de condiciones, que cubren todo el conjunto de acciones con excepcin de una que se convierte en la regla a seguir cando ninguna de las dems condiciones explicitas es verdadera. Esta regla e encuentra en la columna final del margen derecho, que es la columna ELSE. Si ninguna de las otras condiciones es valida, entonces se sigue la regla de decisin ELSE. Esta regla elimina la necesidad de repetir condiciones que conducen a las mismas acciones.

Tablas mltiples La forma ELSE es una alternativa para controlar el tamao de las tablas de decisin. Otra manera de hacer esto es enlazando varias tablas de decisin. De acuerdo con las acciones seleccionadas en la primera tabla, otras se explican en una o ms tablas adicionales; cada tabla proporciona mayores detalles relacionados con las acciones a emprender. Por otra parte, las tablas mltiples permiten al analista establecer las acciones repetitivas que deben realizarse despus de tomar las decisiones y que continan hasta que se alcanza determinada condicin. Para utilizar este mtodo los analistas construyen, por separado, tablas de decisin que satisfacen todos los requerimientos normales y que estn relacionadas con una decisin especifica. Las tablas de enlazan en forma jerrquica: Una tabla de nivel-alto contiene las condiciones principales que, cuando son seleccionadas, determinan las tablas y acciones adicionales donde se encuentran otros detalles. Existen dos tipos de transferencia: directa y temporal.

Transferencia directa: La transferencia directa se emplea una sola vez; la tabla que es seleccionada de esta manera no vuelve a referirse a la tabla original. La proposicin GO TO (nombre de la tabla) indica cual es la siguiente tabla que se va a examinar. Transferencia temporal: En contraste con la tabla anterior, la tabla 1 se enlaza con la proposicin PERFORM tabla 2. Al final de la tabla 2 la proposicin RETURN regresa de nuevo el control a la proposicin que sigue al GO TO en la tabla 1.

Procesadores de tablas de decisin Las tablas de decisin han sido parcialmente automatizadas. Los procesadores de tablas de decisin son programas para computadora que manejan la formulacin actual de una tabla con base en la informacin de entrada proporcionada por el analista. Estos

procesadores tambin emprenden todas las verificaciones necesarias para detectar inconsistencias y redundancias. La utilidad de los procesadores de tablas de decisin radica en el ahorro de tiempo de programacin y deteccin de errores.

Espaol estructurado El espaol estructurado es otro mtodo para evitar los problemas de ambigedad del lenguaje al establecer condiciones y acciones, tanto en procedimientos como en decisiones. Este mtodo no hace uso de rboles o tablas; en su lugar utiliza declaraciones para describir el proceso. El proceso no muestra reglas de decisin; las declara. Aun con esta caracterstica, las especificaciones en espaol estructurado requieren que el analista primero identifique las condiciones que se presentan en un proceso y las decisiones que se deben tomar cuando esto sucede, junto con las acciones correspondientes. Sin embargo, el mtodo tambin permite hacer una lista de todos los pasos en el orden que se llevan a cabo. Para ello no se utilizan smbolos y formatos especiales, caractersticas de los rboles y las tablas de decisin que par algunos resultan incmodos. Adems, es posible describir con rapidez los procedimientos en su totalidad ya que para ello de emplean declaraciones muy similares al espaol. La terminologa utilizada en la descripcin estructurada de una aplicacin consiste, en gran medida, en nombres de datos para los elementos que estn definidos en el diccionario de datos desarrollado para el proyecto.

Desarrollo de declaraciones estructuradas El espaol estructurado emplea tres tipos bsicos de declaraciones para describir un proceso: estructuras de secuencia, estructuras de decisin y estructuras de iteracin. Estructuras de secuencia: Una estructura de secuencia es un solo paso o accin incluido en un proceso. Este no depende de la existencia de ninguna condicin y, cuando se encuentra, siempre se lleva a cabo. En general, se emplean varias instrucciones en secuencia para describir un proceso. Estructuras de decisin: El espaol estructurado es otro camino para mostrar el anlisis de decisin. Por tanto, a menudo se incluyen las secuencias de acciones dentro de estructuras de decisin que sirven para identificar condiciones. Es as como las estructuras de decisin aparecen cuando se pueden emprender dos o ms acciones, lo que depende del valor de una condicin especifica. Para esto primero se evala la condicin y despus se toma la decisin de emprender las acciones o el grupo de acciones asociados con esta condicin. Una vez determinada la condicin las acciones son incondicionales.

Estructuras de iteracin: En las actividades rutinarias de operacin, es comn encontrar que algunas de ellas se repiten mientras existen ciertas condiciones o hasta que estas se presentan. Las instrucciones de iteracin permiten al analista describir estos casos.

Beneficios del espaol estructurado Como puede observarse, el espaol estructurado puede ser de utilidad para describir con claridad condiciones y acciones. Cuando se examina el ambiente de una empresa, los analistas pueden usar el espaol estructurado para declarar las reglas de decisin que se aplican en este medio. Si los analistas no pueden declarar que accin emprender cuando se toma una decisin, entonces necesitan adquirir mayor informacin para descubrir la situacin. Por otro lado, despus de describir las actividades en forma estructurada, los analistas pueden pedir a otras personas que revisen la descripcin y determinen con rapidez los errores u omisiones cometidos al establecer los procesos de decisin.

ANLISIS ESTRUCTURADO Cuando los analistas comienzan a trabajar sobre un proyecto de sistemas de informacin, a profundo tienden a profundizar en un rea de la organizacin con la que tienen poca familiaridad. A pesar de esto, deben desarrollar un sistema que ayude a los gerentes y personal los futuros usuarios- de esta rea. Cualquier nuevo sistema o conjunto de recomendaciones para cambios en el sistema existente, ya sea este manual o automatizado, debe conducir hacia la mejora. Para alcanzar este resultado, se espera que los analistas de sistemas hagan lo siguiente:

- Aprendan los detalles y procedimientos del sistema en uso - Obtengan una idea de las demandas futuras de la organizacin como resultado del crecimiento, del aumento de la competencia en el mercado, de los cambios en las necesidades de los consumidores, de la evolucin de las estructuras financieras, de la introduccin de la nueva tecnologa y cambios en las polticas del gobierno entre otros. - Documentar detalles del sistema actual para su revisin y discusin por otros. Evaluar la eficiencia y efectividad del sistema actual y sus procedimientos, tomando en cuenta el impacto sobre las demandas anticipadas para el futuro. - Recomendar todas las revisiones y ampliaciones del sistema actual, sealando su justificacin. Si es apropiado, quiz la propuesta de un nuevo sistema completo. - Documentar las caractersticas del nuevo sistema con un nivel de detalle que permita comprender a otros sus componentes, y de una manera que permita manejar el desarrollo del nuevo sistema. Fomentar la participacin de gerentes y empleados en todo el proceso, tanto para aprovechar su experiencia y conocimiento del sistema

actual, como para conocer sus ideas, sentimientos y opiniones relacionadas con los requerimientos de un nuevo sistema o de los cambios para el actual.

Para tener xito, los buenos analistas de sistemas estructuran el proceso que siguen para el desarrollo de un nuevo sistema. Aunque cada lugar donde trabaja l analista es diferente, las tareas que llevan a cabo son similares y existe un conjunto comn de preguntas por contestar cuando las emprenden.

El anlisis estructurado es un mtodo para el anlisis de sistemas manuales o automatizados, que conduce al desarrollo de especificaciones para sistemas nuevos o para efectuar modificaciones a los ya existentes. Cuando los analistas de sistemas abordan una situacin poco familiar, siempre existe una pregunta sobre donde comenzar el anlisis. Una situacin dinmica siempre puede ser vista como abrumadora debido a que muchas de las actividades se llevan a cabo constantemente. El anlisis estructurado permite al analista conocer un sistema o proceso en forma lgica y manejable al mismo tiempo que proporciona la base para asegurar que no se omite ningn detalle pertinente.

Qu es lo que se desea estructurar? Qu significa estructura? El objetivo que persigue el anlisis estructurado es organizar las tareas asociadas con la determinacin de requerimientos para obtener comprensin completa y exacta de una situacin dada. En el anlisis estructurado, la palabra estructura significa que: 1) el mtodo intenta estructurar el proceso de determinacin de los requerimientos comenzando con la documentacin del sistema existente; 2) el proceso esta organizado de tal forma que intenta incluir todos los detalles relevantes que describen el sistema en uso; 3) es fcil verificar cuando se han omitido detalles relevantes; 4) la identificacin de los requerimientos ser similar entre varios analistas e incluir mejores soluciones y estrategias para las oportunidades de desarrollo de sistemas; y 5) los documentos de trabajo generados para documentar los sistemas existente y propuesto son dispositivos de documentacin eficiente.

Componentes del anlisis estructurado El anlisis estructurado hace uso de los siguientes componentes:

1-

Smbolos grficos: iconos y convenciones para identificar y describir los componentes de un sistema junto con las relaciones entre estos componentes.

2- Diccionario de datos: descripciones de todos los datos utilizados en el sistema. Puede ser manual o automatizado. 3- Descripciones de procesos y procedimientos: declaraciones formales que emplean tcnicas y lenguajes que permiten a los analistas describir actividades importantes que forman parte del sistema. 4- Reglas: estndares para describir y documentar el sistema en forma correcta y completa.

Los analistas desean conocer las respuestas a cuatro preguntas especificas: qu procesos integran el sistema?, qu datos emplea cada proceso?, qu datos son almacenados? y qu datos ingresan y abandonan el sistema?. Los datos son la gua de actividades de la empresa. Ellos pueden iniciar eventos y ser procesados para dar informacin til al personal que desean saber que tan bien se han manejado los eventos. Seguir el flujo de datos por todos los procesos de la empresa les dice mucho a los analistas sobre como se alcanzan los objetivos de la organizacin. El anlisis de flujo de datos estudia el empleo de los datos en cada actividad. Documenta los hallazgos con diagramas de flujo de datos que muestran en forma grafica la relacin entre procesos y datos, y en los diccionarios de datos que describen de manera formal los datos del sistema y los sitios donde son utilizados.

CARACTERSTICAS DE LAS ESTRATEGIAS DE FLUJO DE DATOS El anlisis de flujo de datos analiza el empleo de los datos para llevar acabo procesos especficos de la empresa dentro del mbito de una investigacin de sistemas. El anlisis puede pensarse de tal manera que se estudien las actividades del sistema desde el punto de vista de los datos: donde se originan, donde se utilizan o cambian, hacia donde van, incluyendo las paradas a lo largo del camino que siguen desde su origen hasta su destino. Herramientas de la estrategia de flujo de datos La estrategia de flujo de datos muestra el empleo de estos en forma grafica. Las herramientas utilizadas al seguir esta estrategia muestran todas las caractersticas esenciales del sistema y la forma en que se ajustan entre si.

El anlisis de flujo de datos utiliza las siguientes herramientas: 1- Diagrama de flujo de datos: una herramienta grafica se emplea para describir y analizar el movimiento de datos a travs de un sistema, ya sea que este fuera manual o automatizado, incluyendo procesos, lugares para almacenar datos y retrasos en el sistema. Los diagramas de flujo de datos son la herramienta mas

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 asociados con el sistema. Estos diagramas reciben el nombre de diagramas lgicos de flujos de datos. 2- Diccionario de datos: el diccionario contiene las caractersticas lgicas de los sitios donde se almacenan los datos del sistema, incluyendo nombre, descripcin, alias, contenido y organizacin. tambin identifica los procesos donde se emplean los datos y los sitios donde se necesita el acceso inmediato a la informacin. 3- Diagrama de estructura de datos: es una descripcin de la relacin entre las entidades de un sistema y el conjunto de informacin relacionado con la entidad. No considera el almacenamiento fsico de los datos. 4- Grafica 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 entradasalida y el anlisis de transacciones.

Ventajas del anlisis de flujo de datos El anlisis de flujo de datos permite a los analistas aislar reas de inters en la organizacin y estudiarlas al examinar los datos que estn en el proceso, de tal manera que puedan observar la manera en que cambian cuando lo abandonan. 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.

DESARROLLO DE DIAGRAMAS DE FLUJO DE DATOS Para que sean de utilidad y proporcionen informacin, los diagramas de flujo de datos deben dibujarse de forma adecuada. Proceso de desarrollo Los analistas de sistemas estudian primero el sistema en uso, esto es, las actividades y procesos que ocurren en el presente. En la terminologa del anlisis estructurado, este es el estudio del sistema fsico. El sistema fsico se transada en una descripcin lgica que se centra en datos y procesos. Durante el anlisis de flujo de datos se evalan todos los detalles en trminos de los componentes lgicos de flujos de datos, procesos, almacenes de datos, orgenes y destinos.

En todas las etapas de diseo que siguen, los requerimientos del sistema se trasladan en detalles de diseo lgico. En las fases de construccin, como la programacin del software para computadora, las especificaciones lgicas son trasladadas en caractersticas fsicas y en un sistemas de informacin que trabaja.

Diagramas fsicos de flujo de datos Los diagramas de flujo de datos son de dos tipos: Diagramas fsicos de flujo de datos: proporcionan un panorama del sistema en uso, que es dependiente de la implantacin, que muestra que tareas se llevan a cabo y como. Las caractersticas fsicas incluyen:

Nombre de personas Nombres o nmeros de formatos y documentos Nombres de departamentos Archivos maestros de transacciones Equipo y dispositivos utilizados Ubicaciones Nombres de procedimientos

Diagramas lgicos de flujos de datos: proporcionan un panorama del sistema independiente de la implantacin, que se centra en el flujo de datos entre los procesos sin considerar los dispositivos especficos y la localizacin de almacenes de datos o personas en el sistema. En este tipo de diagramas no se indican las caractersticas fsicas.

Reglas generales para el dibujo de diagramas lgicos de flujo de datos

1- Cualquier flujo de datos que abandone un proceso debe estar basado en los datos que entran al proceso. 2- Todos los flujos de datos reciben un nombre, el nombre refleja los datos que influyen entre procesos, almacenes de datos, fuentes o destinos. 3- Solo deben entrar al proceso los datos necesarios para llevarlo a cabo. 4Un proceso no debe ser nada de ningn otro sistema, es decir, debe ser independiente; la nica dependencia que debe existir es aquella que esta basada en sus propios datos de entrada y salida.

5- Los procesos siempre estn en continua ejecucin; no se indican ni tampoco de detienen. Los analistas deben suponer que un proceso siempre esta listo para funcionar o realizar e trabajo necesario. 6- La salida de los procesos puede tomar las siguientes formas: a- Flujo de datos con informacin aadida por el proceso. b- Una respuesta o cambio en la forma de los datos. c- Un cambio de decisin. d- Un cambio de contenido. e- Cambios en la organizacin. Seguir convenciones de nivelacin significativa

Nivelacin es un termino que se refiere al manejo de archivos locales. Los detalles relacionados con un solo proceso en un determinado nivel, deben permanecer dentro del proceso. Los almacenes y flujos de datos que son relevantes nicamente para el interior del proceso, son ocultados hasta que el proceso se extiende con mayor detalle.

Asignar etiquetas significativas

Las descripciones asignadas a los flujos de datos y procesos deben decirle al lector que esta ocurriendo. Todos los flujos de datos deben tener un nombre que refleje con exactitud su contenido.

Asignacin de nombre al flujo de datos: los nombres dados a los flujos de datos deben reflejar los datos de inters para los analistas, no los documentos o el lugar donde residen. Los datos que fluyen hacia los procesos experimentan cambios. Por consiguiente, el flujo de datos de salida tiene un nombre diferente al de entrada.

Asignacin de nombre a los procesos: se deben asignar nombres a todos los procesos que les digan a los usuarios algo especifico con respecto a la naturaleza de las actividades del proceso.

Los siguientes lineamientos tienen como finalidad servir de ayuda para identificar los procesos de forma tal que sean tiles a las actividades subsecuentes de anlisis y diseo:

1- Seleccionar nombres que indiquen la accin que se lleva a cabo. 2- Asegurar que el nombre describa completamente al proceso. 3- Seleccionar nombres para los procesos que expliquen el enlace entre los flujos de entrada y los de salida. 4- Evitar nombres vagos para los procesos. 5Utilizar los nombres de los procesos de bajo nivel ya que estos son mas especficos y descriptivos que los asociados con los procesos de alto nivel.

6- Asignar nombres a los procesos que sean nicos para la actividad que ellos describen.

Evaluacin del flujo de datos para verificar que es correcto

Las siguientes preguntas son de utilidad para evaluar los diagramas de flujo de datos:

1- Existen en el diagrama de flujo de datos componentes que no tienen nombre? 2- Existen almacenes de datos que son entradas y a los que nunca se les hace referencia? 3- Existen procesos que no reciben entradas? 4- Existen procesos que no generan salidas? 5- Existen procesos que tienen varias finalidades? 6- Existen almacenes de datos a los que nunca se les hace referencia? 7- Es el flujo de datos que llega a un proceso adecuado para realizarlo? 8- Existen demasiados datos en el almacn de datos? 9- El flujo de datos que llega a un proceso es demasiado extenso para la salida que este produce?

10- Se introducen alias en la descripcin del sistema? Aparecen en el diccionario de datos? 11- Los procesos son independientes entre s? Dependen solo de los datos que reciben como entrada?

CARACTERSTICAS DE LOS DICCIONARIOS DE DATOS Los diccionarios de datos son un componente importante del anlisis estructurado ya que por si solos los diagramas de flujo de datos no describen el objeto de la investigacin. El diccionario de datos proporciona mas informacin relacionada con el sistema. Un diccionario de datos es un catalogo, un deposito, de los elementos en un sistema. Como su nombre lo sugiere, estos elementos se centran alrededor de los datos y la forma en que estn estructurados para satisfacer los requerimientos de los usuarios y las necesidades de la organizacin. Los elementos mas importantes son flujos de datos, almacenes de datos y procesos.

Importancia del diccionario Los analistas utilizan el diccionario de datos por cinco razones importantes:

Para manejar los detalles en sistemas grandes. Para comunicar un significado comn para todos los elementos del sistema Para documentar las caractersticas del sistema Para 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 Todas las partes de un sistema de informacin dependen de loas datos. El diccionario contiene dos tipos de descripciones para flujo de datos dentro del sistema:

Elementos dato: son los bloques bsicos para todos los dems datos del sistema. Por si mismo no conllevan suficiente significado para ningn usuario.

Estructuras de datos: es un grupo de datos elementales que estn relacionados con otros y que en conjunto describen un componente del sistema.

Descripcin de los elementos dato

Cada entrada en el diccionario de datos consiste de un conjunto de detalles que describen los datos utilizados o producidos por el sistema. Cada uno esta identificado con un nombre, descripcin, alias y longitud, junto con el intervalo de valores especficos para el dato permitidos por el sistema bajo estudio. Nombre de los datos: Para distinguir un dato del otro, los analistas les asignan nombres que sean significativos. Los nombres se emplean para hacer referencia a cada elemento durante todo el proceso de desarrollo de sistemas.

Descripcin de los datos: La descripcin de un dato describe de manera breve lo que este representa en el sistema. Las descripciones de los datos deben escribirse con la suposicin de que la persona que las leer no sabe nada con respecto al sistema.

Alias: Con frecuencia el mismo dato recibe varios nombres, mismos que dependen e quien haga uso del dato. Estos nombres se denominan alias. Un diccionario significativo debe incluir todos los alias.

Longitud: La longitud identifica el numero de espacios necesarios para cada dato pero sin considerar la forma en que sern almacenados.

Valores de los datos: En algunos procesos solo son permitidos valores muy especficos para los datos. Todos los detalles sern de utilidad a los analistas mas adelante, cuando diseen los controles del sistema.

Descripcin de las estructuras de datos Las estructuras de datos se construyen sobre cuatro relaciones de componentes:

Relacin secuencial: define los componentes que siempre se incluyen en una estructura de datos en particular; concatenacin de dos o ms datos. - Relacin de seleccin: define alternativa para datos o estructuras de datos incluidas en una estructura de datos. - Relacin de iteracin: define la repeticin de un componente cero o ms veces. - Relacin opcional: caso especial de la iteracin; los datos pueden estar o no incluidos, esto es, una o ninguna iteracin.

FINES DE LOS PROTOTIPOS DE APLICACIONES La finalidad del desarrollo de prototipos se entiende mejor al examinar las razones para seleccionar esta estrategia y la forma en la que incrementa el nivel de productividad en el desarrollo de sistemas. Por otra parte tambin se explora la naturaleza de las aplicaciones que son buenos candidatos para desarrollo con el mtodo del prototipo.

Usos de los prototipos de aplicaciones El desarrollo de prototipos de aplicacin tiene dos usos principales. Por un lado, es un medio eficaz para aclarar los requerimientos de os usuarios. Las especificaciones por escrito se crean, en general, como vehculos para describir las caractersticas y requerimientos que debe satisfacer la aplicacin. El segundo uso del prototipo de aplicacin es verificar la factibilidad del diseo de un sistema. Los analistas pueden experimentar con diferentes caractersticas de la aplicacin y evaluar la reaccin y respuesta por parte del usuario.

Razones para el empleo de prototipos Las razones para el uso de prototipos son el resultado directo de la necesidad de disear y desarrollar sistemas de informacin con rapidez, eficiencia y eficacia.

Aumento de la productividad La productividad es importante para los analistas de sistemas y para la organizacin en la que trabajan. Los analistas de sistemas son ms productivos si toman precauciones que:

Minimicen el tiempo que se pierde debido al desarrollo incorrecto.

- Minimicen los errores del diseo. - Garanticen que los esfuerzos realizados por ellos sean fructferos. - Garanticen que los usuarios reciban la aplicacin que necesitan. Garanticen que no tendr que volverse a hacer el trabajo de desarrollo.

Al mismo tiempo, los analistas se enfrentan a muchos obstculos para alcanzar sus objetivos de desarrollo. A continuacin se mencionan varios hechos que deben considerarse:

- Los usuarios tienen gran dificultad para especificar con anticipacin sus necesidades de informacin, en especial cuando la situacin es nueva o cambia con rapidez. La especificacin completa de los requerimientos de informacin depende en particular de la forma en que debe utilizarse la tecnologa. - A menudo las descripciones estticas de sistemas no son suficientes para proporcionar detalles sobre situaciones dinmicas. - La mala comunicacin, que siempre es una posibilidad, parece que siempre se presenta en el momento menos oportuno.

Aplicaciones para candidatos Los prototipos son ms eficaces en el desarrollo de sistemas de informacin cuando se cumples ciertas condiciones- Cualquiera de las siguientes cinco condiciones sugieren la necesidad de utilizar un prototipo.

- No se conocen los requerimientos: La naturaleza de la aplicacin es tal que existe poca informacin disponible con respecto a las caractersticas que debe tener l sistema para satisfacer los requerimientos el usuario. Los requerimientos necesitan evaluarse: Se conocen los requerimientos aparentes de informacin, tanto de los usuarios finales como de la organizacin, pero es necesario verificarlos y evaluarlos. Costos altos: La inversin de recursos financieros y humanos as como el tiempo necesario para generar la aplicacin es sustancial. Existen otros proyectos que tambin compiten por los mismos recursos. Alto riesgo: La evaluacin inexacta de los requerimientos del sistema o el desarrollo incorrecto de una aplicacin ponen en peligro a la organizacin, a sus empleados y tambin a sus propios recursos. - Nueva tecnologa: El deseo de instalar nueva tecnologa ya sea con los campos de la computacin, de las comunicaciones de datos u otras reas relacionadas, abre nuevas fronteras para la organizacin. Muchas

compaas no tienen experiencia en el uso de cierta tecnologa ni tampoco las dems organizaciones con las que se comunican.

ETAPAS DEL MTODO DE PROTOTIPOS Identificacin de requerimientos conocidos La determinacin de los requerimientos de una aplicacin es tan importante para el mtodo de desarrollo de prototipos como lo es para los mtodos del ciclo clsico de desarrollo de sistemas o anlisis estructurado. Por consiguiente, antes de crear el prototipo, los analistas y usuarios deben trabajar juntos para identificar los requerimientos conocidos que tienen que satisfacerse.

Desarrollo de un modelo de trabajo La construccin de un prototipo es un proceso iterativo de desarrollo. Antes de la primera iteracin, los analistas de sistemas explican el mtodo a los usuarios, las actividades a realizar, la secuencia en la que se llevaran a cabo y tambin discuten las responsabilidades de cada participante. Un cronograma para el inicio y fin de la primera iteracin es de gran ayuda, por tanto, debe elaborarse justo antes de iniciar las actividades. En el desarrollo de un prototipo se preparan los siguientes componentes:

El lenguaje para el dialogo o conversacin entre el usuario y el sistema. - Pantallas y formatos para la entrada de datos. - Mdulos esenciales de procesamiento. - Salida del sistema.

USO DE PROTOTIPOS Cuando el prototipo esta terminado, el siguiente paso es tomar la decisin sobre como proceder. Existen cuatro caminos a seguir despus de evaluar la informacin obtenida con el desarrollo y uso del prototipo:

Abandono de la aplicacin En algunos casos, la decisin es descartar el prototipo y abandonar el desarrollo de la aplicacin. Esta conclusin no significa que fuese un error emprender el proceso de

desarrollo del prototipo o un desperdicio de recursos. Mas bien, la informacin y experiencia ganada con el desarrollo y empleo del prototipo condujo hacia una decisin de desarrollo. Es probable que los usuarios y analistas hayan aprendido que el sistema era innecesario o hayan descubierto otra solucin durante el proceso.

Implantacin del prototipo Algunas veces el prototipo se convierte en el sistema que se necesita. En este caso, se implanta sin ninguna modificacin y no se emprenden mas esfuerzos de desarrollo. Esta decisin es ms probable tomarse bajo una o ms de las siguientes circunstancias:

La evolucin de prototipo condujo a una aplicacin que tiene las caractersticas, capacidades y desempeo requeridos. - La aplicacin ser utilizada con poca frecuencia y no es importante su rapidez o eficiencia operacional. - La aplicacin no tiene efecto sobre otras aplicaciones o datos de la organizacin y tampoco interacciona con ellos; adems satisface las necesidades de os usuarios inmediatos. - El medio ambiente de la aplicacin se encuentra en un estado de flujo; es difcil determinar necesidades a largo plazo o condiciones de operacin mas estables. En consecuencia no es posible justificar otras actividades de desarrollo. El prototipo es de utilidad para las condiciones actuales.

Desarrollo de la aplicacin Cuando un prototipo tiene xito puede proporcionar informacin muy amplia con respecto a los requerimientos de la aplicacin y conducir a su completo desarrollo. Terminar el prototipo n significa finalizar el proceso de desarrollo. Mas bien seala el comienzo de la siguiente actividad: el desarrollo completo de la aplicacin. El desarrollo de una aplicacin puede presentarse como parte del mtodo de ciclo de vida de los sistemas de informacin. Las dos formas ms comunes de incorporar la construccin de un prototipo para la aplicacin son las siguientes:

- El prototipo se emplea como una opcin para la determinacin de requerimientos; las caractersticas del prototipo son consideradas como los requerimientos a satisfacer en subsecuentes actividades de desarrollo. - El prototipo se utiliza como sustituto para el diseo e implantacin de la aplicacin, es decir, como un esqueleto a partir del que se construye el resto del sistema.

Inicio de un nuevo prototipo Algunas veces la informacin ganada con el desarrollo y uso del prototipo, sugiere el empleo de un enfoque muy diferente para satisfacer las necesidades de la organizacin. En este caso es posible encontrar que las caractersticas de la aplicacin con muy diferentes si el prototipo es inadecuado para demostrarlas y evaluarlas.

HERRAMIENTAS PARA EL DESARROLLO DE PROTOTIPOS Lenguajes de cuarta generacin Los lenguajes de cuarta generacin fueron creados para ayudar a satisfacer la necesidad de desarrollar un software con mayor eficiencia. Los lenguajes de cuarta generacin incluyen un amplio espectro de lenguajes de computadora que hacen hincapi sobre lo que debe hacerse mas que sobre como realizar la tarea.

Los lenguajes de cuarta generacin se clasifican en tres categoras: Lenguajes no orientados hacia procedimientos: El lenguaje con el que trabajan los analistas y usuarios finales no esta orientado hacia procedimientos. Algunas veces el lenguaje recibe l nombre de lenguajes no-procedurales. Un solo mandato lleva a cabo una funcin completa. No es raro encontrar que el mandato de un lenguaje no orientado hacia procedimientos remplace al equivalente de mas de cien instrucciones de un lenguaje de tercera generacin. Lenguajes de consulta y recuperacin: Estos lenguajes facilitan la recuperacin de datos almacenados sin necesidad de escribir muchas instrucciones orientadas hacia procedimientos, o especificar el formato de los datos. Estos lenguajes permiten a los usuarios formular preguntas en formatos tabulares o parecidos al ingles.

Generadores de reportes Los generadores de reportes permiten a los usuarios obtener con facilidad datos de archivos o bases de datos. Se puede obtener el contenido parcial o total de los registros. En comparacin con los lenguajes de consulta y recuperacin, los generadores de reportes dan a los usuarios mayor control sobre la apariencia y contenido de la salida. Los resultados se pueden presentar en un formato de reporte que se establece en forma automtica por software, o el usuario tambin puede proporcionar las especificaciones que instruyan al sistema para preparar ttulos especficos, descripciones de pagina y encabezados de columnas.

Generadores de aplicaciones Los generadores de aplicaciones son programas de software que permiten la especificacin de toda una aplicacin de un nivel muy alto. Ellos proporcionan las condiciones para desarrollar aplicaciones que acepten datos, efecten clculos, sigan complicadas rutinas de procesamiento lgico y produzcan reportes y salidas. El generador de aplicaciones produce el cdigo fuente. Algunos producen programas completos. Otros, denominados generadores de programas, reparan el cdigo del programa, como mdulos individuales, y permiten al usuario enlazar otros mdulos con los producidos por el generador.

Generadores de pantalla Un generador de pantalla es una herramienta interactiva para dibujar pantallas y efectuar la validacin automtica de la entrada y procesamiento. Es posible seleccionar con respuestas sencillas preferencias sobre el presentar con mayor brillantez la informacin ms importante, el utilizar determinados colores o hacer uso del video inverso. Los generadores de pantalla tambin permiten que los usuarios preparen automticamente componentes que sean de ayuda en la interaccin usuario-maquina, incluyendo la localizacin de campos para entrada de datos, campos para presentar datos, encabezados de columna, etiquetas y mensajes.

IMPORTANCIA DE LAS HERRAMIENTAS EN EL DESARROLLO DE SISTEMAS Las herramientas son esenciales para el anlisis de sistemas. Ellas mejoran la forma en que ocurre el desarrollo y tienen influencia sobre la calidad del resultado final.

Beneficios del empleo de herramientas Con las herramientas, el analista tiene el potencial de ser ms productivo; se pueden completar las mismas actividades de desarrollo en un tiempo menor que el que se necesita usando no se utilizan las herramientas. Las herramientas sugieren procedimientos que conducen al empleo de procesos ms eficaces. Si la productividad significa realizar la tarea correcta, la eficacia significa hacer la tarea en forma correcta. Cuando las herramientas mejoran los procesos, por lo general tambin ocurre lo mismo con los resultados.

Beneficios de las herramientas asistidas por la computadora La introduccin de herramientas asistidas por la computadora en los esfuerzos de anlisis y desarrollo aumentan los beneficios que se derivan del uso de las herramientas. Las herramientas del anlisis asistido por la computadora mejoran la velocidad y disminuyen el tiempo necesario para completar la tarea de desarrollo. La automatizacin tambin se hace cargo de algunas tareas que son pesadas. El desarrollo de diagramas de flujo de datos es una tarea que puede consumir mucho tiempo. Las herramientas automatizadas para flujo de datos hacen posible dejar al software de la computadora el proceso de dibujo. Cuando los procedimientos forman parte del software, estos se realizan en forma ms consistente. Se convierten en rutinas. La consistencia que pueden ofrecer los procedimientos es una excelente razn para ampliar el conjunto de herramientas asistidas por computadora para el desarrollo de sistemas. Una ventaja que distingue a muchos sistemas automatizados es la captura, almacenamiento, procesamiento y recuperacin de los detalles de un sistema. Una vez en forma procesable por la computadora, los detalles del sistema pueden utilizarse para muchas finalidades.

CLASIFICACIN DE HERRAMIENTAS AUTOMATIZADAS Herramientas de tipo front-end Las herramientas de tipo front-end automatizan las primeras actividades del proceso de desarrollo de sistemas. Entre los muchos aspectos que se toman en cuenta al desarrollar herramientas para esta fase, se hallan tcnicas de soporte para ayudar al analista a preparar especificaciones formales que carezcan de ambigedades, a validar las descripciones del sistema con el objeto de determinar su consistencia y completez, y a seguir la evolucin de los requerimientos de la aplicacin en caractersticas que formen parte del sistema que finalmente ser implantado.

Herramientas de tipo back-end Las herramientas de tipo back-end tienen como finalidad ayudar al analista a formular la lgica del programa, los algoritmos de procesamiento y la descripcin fsica de los datos, tambin ayudan a la interaccin con los dispositivos, etc. Estas actividades convierten los diseos lgicos del software en un cdigo de programacin que es el que finalmente da existencia a la aplicacin.

Herramientas integrales Las actividades de anlisis abordan los detalles de alto nivel mientras que las actividades de desarrollo dan mayor importancia a los detalles de bajo nivel. Las especificaciones de alto nivel describen los requerimientos del usuario, como entradas, salidas y expectativas de funcionamiento. Las especificaciones de bajo nivel indican la forma en que sern satisfechos estos requerimientos por medio de detalles que son especficos de la computadora.

HERRAMIENTAS ASISTIDAS POR INGENIERA DE SISTEMAS (CASE)

COMPUTADORA

PARA

LE

Las herramientas de tipo CASE incluyen los siguientes cinco componentes: Herramientas para diagramacin: Estas herramientas dan soporte al anlisis y documentacin de los requerimientos de una aplicacin. Por lo general, incluyen facilidades para producir diagramas de flujo de datos. Las herramientas ofrecen la capacidad de dibujar diagramas y cartas, adems de guardar los detalles en forma interna. Deposito centralizado de informacin: La captura, anlisis, procesamiento y distribucin de todos los sistemas de informacin es asistida por un deposito de informacin centralizado o diccionario de datos. Aunque los diccionarios son diseados para que el acceso a la informacin sea sencillo, tambin incluyen controles y medidas de proteccin que preservan la exactitud y consistencia de los detalles del sistema. Generador de interfaces: Los generadores de interfaces ofrecen la capacidad para preparar imitaciones y prototipos para las interfaces con los usuarios. Por lo general, soportan la rpida creacin de mens de demostracin para el sistema, de pantallas de presentacin y del formato de los informes. Generadores de cdigo: Los generadores de cdigo automatizan la preparacin del software. Estos incorporan mtodos que permiten convertir las especificaciones del sistema en cdigo ejecutable. Herramientas de administracin: Algunas herramientas CASE para administracin permiten que los gerentes de proyecto especifiquen elementos de su propia eleccin. Otras permiten definir metodologas de desarrollo propias, incluyendo las reglas de validacin y los estndares para datos nombres de procedimientos.

Integracin de la herramientas CASE La integracin de la herramientas ocurre en tres formas: Interfase uniforme: Significa que todas las herramientas en el sistema CASE son activadas de la misma manera y desde un lugar comn en el sistema. Facilidad para la transferencia de datos: Significa que los detalles desarrollados con una herramienta pueden estar disponibles para otras. El diccionario de datos es el elemento critico que hace posible la transferencia de datos entre herramientas distintas. Unir de las actividades de desarrollo: La facilidad para transferir datos y la unin de las fases de desarrollo se encuentran relacionadas, ya que se pueden utilizar una y otra vez los datos transferidos entre herramientas a travs de todo el proceso de desarrollo.

USO DE UNA HERRAMIENTA CASE Operaciones iniciales Los sistemas CASE almacenan informacin por proyecto. Cada aplicacin de sistemas de informacin es considerada como un proyecto. Antes de iniciar el trabajo, el analista debe proporcionar su nombre y contrasea. Si es correcta, Excelerator presenta sobre la pantalla una lista de todos los proyectos para los que el analista tiene autorizado el acceso. Men principal de funciones El men principal presenta los nombres de las siete funciones mas importantes d Excelerator: graficas, XLDicionario, pantallas y reportes, documentacin, anlisis, interfaces y utileras.

Dibujo de diagramas de flujo de datos Cuando se selecciona la funcin de graficas, aparece otro men que muestra las opciones disponibles para l analista. Los diagramas de flujo de datos son uno de los muchos tipos de diagramas y cartas disponibles en el men de graficas.

Diccionario por proyecto A medida que se formulan las especificaciones y la documentacin, toda la informacin con respecto al proyecto se acumula en el diccionario de datos que Excelerator mantiene para dicho proyecto. Parte de la informacin, como el flujo de datos entre procesos, la graba directamente la persona que hace uso de la herramienta.

Pantallas e informes Excelerator, como muchas otras herramientas de tipo CASE, proporciona un mtodo rpido y sencillo para desarrollar prototipos de pantallas para que los usuarios finales trabajen con ellas. El analista puede disear y ejecutar pantallas y reportes con el apoyo de un men, e incluso desarrollar el prototipo de una base de datos.

Herramientas para el anlisis y documentacin Excelerator ofrece caractersticas tales como un conjunto de reportes que validan las descripciones del sistema. Los reportes del anlisis contienen una lista de relaciones inconsistentes o ilegales entre datos, flujos de datos y procesos, as como consistencias al seguir las convenciones para asignar nombres. tambin es posible detectar y notificar diagramas no balanceados.

Utileras La informacin utilizada por el sistema Excelerator se encuentra descrita por las funciones de utilera. Existe tambin una funcin especial para el manejo de proyectos que los analistas emplean para dar nombre al proyecto, proporcionar descripciones del mismo y definir la notacin que utilizaran para los diagramas de flujo de datos.

Beneficios de CASE Entre los beneficios ofrecidos por la tecnologa CASE se encuentran los siguientes:

- Facilidad para llevar a cabo la tarea de revisin de especificaciones del sistema as como de representaciones graficas. Facilidad para desarrollar prototipos de sistemas para desarrollar prototipos de sistemas por medio de la capacidad para cambiar especificaciones y, por otro lado, para determinar el efecto que sobre el desempeo del sistema tendrn otras alternativas. - Generacin de cdigo. - Soporte para mantenimiento como resultado de haber guardado las especificaciones del sistema en un deposito central de informacin. Aumentar las posibilidades de satisfacer los requerimientos del usuario.

Debilidades de CASE Entre las debilidades de CASE se encuentran las siguientes:

- Muchas herramientas CASE estn construidas teniendo como base las metodologas del anlisis estructurado y del ciclo de vida de desarrollo de sistemas. Por si sola, esta caracterstica puede convertirse en la principal limitante ya que no todas las organizaciones emplean mtodos de anlisis estructurado. - Falta de niveles estndar para el soporte de tecnologa. - Conflictos en el uso de diagramas. - Diagramas no utilizados. En algunos casos las herramientas graficas automatizadas o manuales no se emplean del todo. - Aunque una herramienta puede apoyar varias fases del ciclo de vida de desarrollo de sistemas o adaptarse a diferentes metodologas de desarrollo, por lo general su enfoque primario esta dirigido hacia una fase o mtodo especifico. - Aunque muchas herramientas basadas en computadora incluyen la capacidad de verificar las especificaciones para determinar su completez o consistencia, virtualmente no llevan a cabo ningn anlisis de los requerimientos de la aplicacin. - Las tareas humanas siguen siendo criticas. Las herramientas deben adaptarse a la arquitectura de la informacin as como a las metodologas de desarrollo utilizadas por la organizacin.

DISEO DE SISTEMAS El diseo de sistemas es convertir los requerimientos en soluciones que los satisfagan. Para disear un sistema se deben especificar los requerimientos de la aplicacin, anteriormente se nombraron y explicaron herramientas para especificar estos requerimientos . Estos mtodos o herramientas son de gran ayuda para la documentacin del sistema, pero no realizan el anlisis necesario para identificar los requerimientos del sistema. El analista de sistemas es el responsable de identificar estos requerimientos. Los requerimientos del sistema se formulan a partir del resultado del anlisis Para determinar los requerimientos del usuario y revisar los hechos de un sistema se puede seguir el siguiente marco de referencia: Capacidad: se refiere a la capacidad que tiene el sistema existente para alcanzar sus metas y cumplir con sus objetivos. Esta capacidad viene dada por personas, equipo, espacio y procedimientos. El problema esta cuando estas personas o

equipos, etc; no satisfacen los niveles de rendimiento esperados. Las soluciones son las siguientes: 1. Aumentar el personal, equipo u otros recursos necesarios para satisfacer las necesidades requeridas 2. Reducir los requerimientos de efectividad, esto se puede lograr aumentando el espacio de tiempo de cada tarea a realizar 3. Cambiar el grado de exigencia de las actividades

Control: es un conjunto de mecanismos que se utilizan para aumentar la probabilidad de que las tareas de una empresa u organizacin se lleven a cabo de la manera deseada. Hay varias preguntas que el analista debe hacer cuando evala el control de los procedimientos como por ejemplo Los pasos del proceso se realizan en forma apropiada?, Existe la posibilidad de que se estn efectuando pasos no autorizados?, Se pueden duplicar actividades?, La gerencia esta al tanto de tareas no realizadas?, Existe verificacin de datos, cdigos de procedimientos, etc? Las soluciones a un problema de control de procedimientos pueden ser las siguientes: 1. Disear el sistema de manera que los fallos en los controles estn prohibidos y de esta forma se neutralizan los eventos que no pueden ocurrir 2. Disear detectores de errores o fallos que los identifiquen y los notifiquen para que la persona autorizada los corrija 3. Disear correctores de fallos en los controles, una vez detectados se puede proporcionar al sistema con una rutina que emprenda las acciones correctivas necesarias. Accesibilidad de la Informacin: ya sea por que no existe o por que su acceso es muy difcil, se pueden producir problemas con el acceso a la informacin necesaria para realizar una labor. Para evitar este problema existen varias estrategias: 1. Eliminar la necesidad de informacin rediseando el sistema de una forma en la cual las reglas y procesos de decisin formen parte de l. 2. Facilitar el acceso a la informacin 3. Disminuir la necesidad de procesamiento, esto se puede lograr almacenando los detalles mas utilizados o accesados por el usuario en una forma en la que si se vuelve a utilizar no se requiera procesarlo 4. Mejorar la presentacin Complejidad: cuando las tareas son muy complejas es mas fcil que la persona la evite que la realice, entonces es probable que esta tarea no se realice. Para reducir la complejidad se debe considerar lo siguiente:

1. Simplificacin: se obtiene eliminando pasos innecesarios, registros que no se utilizan, etc. 2. Dividir los procesos complejos en tareas separadas 3. Cambiar la secuencia de un proceso puede disminuir la complejidad

El diseo de sistemas tiene dos etapas: Diseo Lgico:

Especificaciones de Salida Especificaciones de Entrada Especificaciones de archivos y bases de datos Especificaciones de procesamiento Requerimientos de datos

Diseo Fsico:

Entrada de datos Soporte para decisiones Generacin de Reportes Consultas Comunicacin Mantenimiento de Archivos Respaldo Archivos de Transaccin, de reporte, maestro, etc.

En general, el analista debe disear el sistema de manera que:

Sea fcil de utilizar Este bien validado Evite fallas en procedimientos crticos para la empresa Sea flexible Sea Adaptable Sea ergonmico

En la actualidad existen estndares de diseo de sistemas, a continuacin se dan ejemplos de reas incluidas en estos estndares:

Estndares para datos: modelos a seguir para nombrar a los datos y especificar su longitud y tipo, esto est contenido en el diccionario de datos. Estndares de Codificacin: Abreviaturas para describir procesos y entidades dentro de una organizacin Estndares Estructurales: lineamientos para dividir el sistema en mdulos, para la codificacin estructurada, reutilizacin de cdigo. Estndares de Documentacin: descripcin de los detalles de la aplicacin

Elementos del Diseo

Flujos de Datos: movimientos de datos hacia, alrededor y desde el sistema.

Almacenes de Datos: conjuntos temporales o permanentes de datos

Procesos: transforma los datos en informacin. Pueden ser manuales o automatizados

Controles: lineamientos para determinar si los procesos estn siendo ejecutados de forma correcta

Funciones del Personal: la interaccin que tiene el usuario con el sistema, entradas de datos, etc.

Diseo de la Salida

El analista debe realizar lo siguiente:

Identificar la informacin que desea presentar al usuario Decidir por que medio ser presentada esa informacin (impresora, pantalla, etc.) La informacin debe ser presentada en un formato aceptable

Diseo de Archivos El diseo de los archivos se basa fundamentalmente en los siguientes aspectos:

Los datos que deben incluirse en los registros del archivo La longitud de cada registro La secuencia en la que se van a almacenar los registros (secuencial, indexada o relativa)

En algunos casos el sistema que estamos diseando interacta con un archivo maestro que ya esta creado, los detalles de este archivo se incluyen en las especificaciones de diseo del sistema, pero el archivo no vuelve a disearse.

Diseo de Interacciones con la base de datos El diseo de las bases de datos es establecido y vigilado por un administrador de bases de datos, l tiene la responsabilidad de mantener y desarrollar esa base de datos a medida que los requerimientos se lo exijan. El analista de sistemas no disea la base de datos sino que consulta con el administrador de la base de datos para establecer las interacciones con la base de datos. El analista en este caso solo proporciona al administrador de BD la descripcin de los datos que van a ser ingresados all y las acciones que se efectuaran en esa BD.

Diseo de Entrada Los analistas de sistemas detallan los siguientes puntos del diseo de entradas:

Datos de entrada Recursos que utiliza el sistema para la captura de datos La codificacin de los datos Dilogos para ayudar a los usuarios a ingresar los datos en el sistema

Validacin de datos

La ubicacin de las entradas de datos (textbox, combobox, etc) tambin formar parte del diseo de la entrada de datos, as como tambin los encabezados, los ttulos de los formularios, etc.

Diseo de Controles Los analistas de sistemas deben predecir los errores creados al momento de que el usuario ingrese datos errados o cuando solicite la ejecucin de una funcin especifica. Un buen sistema de informacin sabe como lidiar con este tipo de errores. Los controles de entrada aseguran que slo los usuarios autorizados tengan acceso al sistema, determinar si faltan datos de entradas importantes, validan los datos para verificar que sean correctos.

Diseo de Procedimientos Los procedimientos determinan las tareas que deben efectuarse al utilizar la aplicacin y especifica quienes son los responsables de realizarlas. Los procedimientos mas importantes son:

Procedimientos para entrada de datos: captura de datos

Procedimientos durante la ejecucin: pasos que realizan los usuarios del sistema para llegar a los resultados deseados

Procedimientos para el manejo de errores: acciones que realiza el sistema al momento de ocurrir algn error.

Procedimientos de seguridad y respaldo: acciones que toma el sistema para proteger sus recursos de posibles daos o ataques.

Diseo de Especificaciones para programas Describen cmo transformar las especificaciones de diseo del sistema (salidas, entradas, archivos, etc) en software de computadora. El diseo del software asegura que: los programas finales realicen todas sus tareas en la forma establecida, la programacin modular permita probar y validar el sistema para verificar si los procedimientos son acertados, las actualizaciones del sistema se puedan llevar a cabo de forma eficiente.

Carpeta de Descripcin del diseo del sistema Ningn diseo esta completo sin la carpeta de diseo ya que esta contiene toda la informacin detallada acerca del sistema, sus procesos, datos, etc. La informacin contenida en esta carpeta se desglosa de la siguiente manera:

Propuesta de desarrollo Diagramas de flujo de datos Cuadros de despliegue: describe las entradas y salidas, y muestra la ubicacin detallada de los reportes que aparecern, documentos y pantallas. Estructuras de los registros: describe los datos almacenados en los archivos maestros y de movimientos y tambin contiene los diagramas relacionados con la BD Sistemas de codificacin: describe los cdigos que explican o establecen los tipos de transacciones, clasificaciones y categora de eventos o entidades Especificaciones de programas: son cuadros, tablas, grficos, etc que explican todos los mdulos del sistema y establecen la relacin entre ellos. Especificaciones de procedimientos: son los procedimientos planificados para instalar y operar la aplicacin cuando este culminado Plan de desarrollo: cronograma de actividades de los analistas, programadores y dems personal involucrado con el desarrollo del sistema Costo del paquete: gastos anticipados para el desarrollo del sistema clasificados en categoras como personal, equipo, etc.

Participacin de los usuarios Para disear un buen sistema de informacin que satisfaga todas y cada una de las necesidades del usuario, ste debe participar en el diseo del mismo porque de esta manera se asegura que los usuarios tengan un punto de vista no tcnico

de lo que hace y de lo que no hace el sistema. El sistema no se disea para ser usado por el analista de sistemas sino para ser usado por personas que no tienen los mismos conocimientos que tiene un analista, por lo tanto esas personas (usuarios) deben participar en el desarrollo del sistema.

Manejo de sistemas desarrollados por usuarios finales Estos sistemas deben estar bien manejados y apoyados en forma apropiada para que tengan xito, de lo contrario podran ser perjudiciales para la organizacin. Los usuarios y los analistas tienen responsabilidades en el manejo de estos sistemas:

Responsabilidades de los usuarios en el diseo

Comprender el problema que va a ser solucionado por el sistema a implantar Conocer los datos necesarios para el desarrollo de este sistema Saber manejar el software Apegarse a los estndares establecidos

Responsabilidades del Analista

Transformar las necesidades de datos en requerimientos Impartir educacin y entrenamiento a los usuarios Apoyar al usuario en el diseo y proceso de desarrollo del sistema Asistir al usuario en la parte de deteccin y correccin de errores

Lineamientos para el manejo del desarrollo hecho por los usuarios finales

Descarga de datos: es copiar una parte del archivo o BD desde un sistema ajeno

Evitar que los usuarios ingresen datos: esto impide la entrada de errores en la base de datos o la modificacin de los datos ya validados

Estandarizacin: para obtener consistencia y uniformidad en el desarrollo

Documentacin del Diseo: explica la forma en la cual esta diseado el sistema y como utilizarlo

Revisin de las especificaciones de diseo: para aumentar la confiabilidad de las aplicaciones desarrolladas por los usuarios, stas tienen que estar en constante revisin

Diseo de salida del sistema de computo Las salidas del sistema son cualquier informacin que arroje el sistema de informacin, ya se impreso o por pantalla. El analista para disear estas salidas debe identificar la salida que se necesita para cubrir la necesidad de informacin, debe especificar los mtodos para el diseo de stas salidas y por ultimo deben crear los documentos o reportes que contienen la informacin que arroja el sistema.

Objetivos de la Salida 1. Expresar la informacin que tengan relacin con actividades realizadas en el pasado, de estados actuales o informacin proyectada hacia el futuro 2. Resaltar eventos de importancia, ya sean problemas, errores o advertencias 3. Ejecutar acciones 4. Verificar esas acciones

Las salidas deben ser diseadas tomando muy en cuenta la funcin que stas van a cumplir.

Tipos de Salida

1. Un reporte 2. Un documento 3. Un mensaje

Las salidas pueden ser impresas o presentadas por pantalla.

Las fuentes de las salidas pueden ser: 1. Recuperacin de un almacenamiento de datos 2. Paso de mensajes desde un proceso a otro 3. Dispositivos de Entrada

Aspectos importantes de la salida A travs de las siguientes cinco preguntas se puede comprender mejor lo que debe ser la salida de un sistema: 1. 2. 3. 4. 5. Quines recibirn la informacin? Cul es el uso que se le dar a la informacin? Cuntos detalles se necesitan? Cundo se necesita la informacin? Qu mtodo utilizar?

Cmo presentar la informacin Existen varios lineamientos para presentar la informacin al usuario, el analista debe utilizar en que mas le convenga al usuario para hacer uso de esa informacin

Formato Tabular ste formato debe utilizarse:

Cuando los detalles dominan y no se necesitan muchos comentarios Cuando los detalles son presentados en categoras discretas Cuando cada categora deba tener una etiqueta Cuando es necesario obtener totales o comparar diferentes componentes Cuando las entidades dependan del tiempo

Formato Grfico Como su nombre lo indica utiliza grficos para presentar la informacin. Existen distintos tipos de grficas:

De Sectores: describen las distintas partes que conforman un todo, y que tienen relacin con una actividad determinada Curvas: muestran cambios en la actividad a lo largo de cierto tiempo De escalones o superficie: muestran cambios en categoras Barras y columnas Mapas: muestran variaciones en distintas zonas geogrficas

Las grficas se utilizan por varias razones:

Para mejorar el entendimiento por parte del usuario de la informacin que sta siendo presentada Para poder manejar mayor volumen de informacin Para que la informacin se ajuste a las preferencias del usuario

Estndares para el diseo de grficas

Toda grfica debe incluir un titulo Fecha en que se realizo Aadir nmeros de pgina Deben colocarse etiquetas bien ubicadas y utilizando un tipo de letra que ayuda a que sea legible No deben utilizarse abreviaturas

Uso de conos

Los conos son representaciones grficas de entidades, por lo tanto ofrecen una gran ayuda al momento de acceder rpidamente a la informacin, y tienen un efecto visual que los hace atractivos para el usuario, ayudndolo as a manejar mejor el sistema

Lineamientos de cuando y como utilizar los conos en un sistema de informacin:

Utilizar conos que sean reconocidos fcilmente por el usuario Si no existe algn icono que represente grficamente lo que queremos presentar, es mejor utilizar etiquetas en vez de utilizar un icono que confunda al usuario Utilizar el mismo icono para la misma entidad as ste aparezca en diferentes partes del sistema Evitar colocar etiquetas en los iconos, ya que stos por s solos deben comunicar su significado con claridad Distribuir los iconos de forma de que no se agrupen en una zona pequea para evitar la sobrecarga de imgenes Mantener un mismo tamao para todos los iconos

Diseo de salida impresa Las salidas impresas se utilizan cuando se necesita el fsico de la informacin por cualquier razn que tenga el usuario: que necesite enviar por correo la informacin, etc. El analista debe determinar aquellas salidas impresas que sean absolutamente necesarias, por que el desarrollo de un sistema debe disminuir en lo posible el uso de reportes impresos en la organizacin

Lineamientos:

1. Los documentos deben estar diseados para ser ledos de izquierda a derecha y de arriba hacia abajo 2. Los datos de mayor importancia deben estar ubicados de tal forma que sean fciles de encontrar 3. Todas las pginas deben tener ttulo, nmero de pgina y fecha en que fue impresa

4. Todas las columnas deben estar etiquetadas 5. No utilizar abreviaturas

Diseo de salida por pantalla

Las salidas por pantalla tienen la desventaja del espacio comparada con las salidas impresas, adems los usuarios saben buscar la informacin en un reporte impreso (saben voltear las paginas, etc), en cambio no podemos suponer esto cundo se disean pantallas

En este diseo se incluyen el uso de grficas e iconos, existen diversas formas de presentar la informacin por pantalla, la ms usada es a travs del uso de ventanas. Hay ventanas estticas y ventanas de aparicin repentina, las estticas se utilizan para mostrar alguna informacin que el usuario requiera, en cambio las de aparicin repentina sirven para pedir informacin, dar advertencias o incluso mostrar errores.

Diseo de Entradas

El diseo de entradas une al sistema con los usuarios. Objetivos del diseo de la entrada:

Control de la calidad de entrada: esto se refiere a disminuir los requerimientos de datos en el sistema debido a que en el proceso se entrada de datos se pierde mucho tiempo, entonces debemos disminuir estos requerimientos para que el proceso de entrada sea ms rpido.

Evitar los cuellos de botella: los cuellos de botella son retrasos que ocurren en el procesamiento, stos retrasos son producto del proceso de entrada de datos

Evitar los errores en los datos: el analista puede reducir el nmero de errores disminuyendo el volumen de datos que deben entrar en el sistema.

Evitar pasos adicionales: el analista debe disear la entrada de datos de forma que no se tenga que utilizar pasos o procesos adicionales.

Mantener la sencillez del proceso

Lineamientos para la captura de datos

El analista debe disear el sistema de forma que capture slo aquellos datos que deben proporcionarse como entradas cuando se procesan transacciones:

1. Datos variables: son los datos que cambian para cada transaccin 2. Datos de identificacin: es el dato de identificacin de artculo en cada registro de transaccin

Tambin es importante resaltar los datos que no deben proporcionarse al sistema:

1. Datos constantes: por ejemplo la fecha, la cual puede ser obtenida por el sistema a travs del reloj/calendario del computador 2. Detalles que el sistema puede recuperar: son los datos que se encuentran almacenados en un archivo o base de datos los cuales pueden ser ledos por el sistema 3. Detalles que el sistema puede calcular: por ejemplo una diferencia entre una fecha de entrada de un producto y la fecha de venta del producto

Diseo de documentos fuente Es la forma en la cual se capturan los datos inicialmente. Para disear estos documentos fuente los analistas de sistemas debe plantearse las siguientes preguntas: Los datos que se encuentran en la forma pueden ser ledos por el sistema? Cul es el mejor mtodo para introducir los datos y que minimice la cantidad de entradas?

Mtodos de codificacin Es expresar las palabras, ideas o relaciones por medio de un cdigo; esto ayuda al ahorro de espacio, tiempo y costos, y acelera todos los procesos. Existen varios mtodos de codificacin:

Cdigos de clasificacin: los cdigos de clasificacin separan las entidades, eventos, personas u objetos, colocndolos en grupos distintos que reciben el nombre de clases.

Cdigos de funciones: es asignar un cdigo a las tareas o trabajos a realizar por el programa sin tener que proporcionar todos los detalles.

Cdigos en secuencia: son nmeros o letras asignados en secuencia para saber en que orden ocurrirn los eventos.

Cdigos con subconjuntos de dgitos significativos: son varios cdigos organizados secuencialmente que en conjunto representan la informacin detallada del articulo. Estos subconjuntos de cdigos indican cada uno por separado aspectos como clase de articulo, vendedor, etc.

Cdigos nemnicos: estos cdigos utilizan nmeros y letras para describir algo en forma visual. Por ejemplo, un televisor de color de 21 pulgadas se puede traducir en TV-CL-21.

Mtodos de captura de datos

Captura de datos fuente por medio de perforadoras: en la actualidad este mtodo se usa muy rara vez, consiste en: 1. Escribir los datos sobre el documento fuente 2. Perforar los datos en tarjetas 3. Verificar las tarjetas perforadas volviendo a introducir los datos a la mquina de verificacin, la cual los compara con los datos ya perforados 4. Colocar las tarjetas perforadas en un lote para ser ledas y procesadas por la computadora 5. Ir validando los datos mientras la computadora los lee 6. Procesar los datos

Captura de datos fuente con dispositivos teclado-almacenamiento:

1. Escribir los datos sobre el documento fuente 2. De ser necesario, los datos del documento fuente se deben codificar en un formato aceptable para poder ser procesados por la computadora 3. Procesar directamente el disco que contiene los datos 4. Se debe validar los datos a medida que son ledos por el computador para luego ser procesados 5. Procesar los datos

Captura de datos fuente con un scanner: este proceso acelera en un 60% aproximadamente el proceso de captura de datos. Consiste en:

1. Escribir los datos en el documento fuente

2. Agrupar un lote de documentos fuente y leerlos a travs del lector ptico de caracteres 3. La validacin se realiza a medida que se van ingresando los datos en la computadora 4. Procesar los datos

Entrada directa a travs de terminales inteligentes: estos terminales tienen la capacidad de procesamiento de datos, gracias a esto no se necesitan documentos fuente. Este mtodo se puede resumir en los siguientes pasos: 1. Proporcionar los datos en el terminal 2. Validar los datos a medida que se vayan ingresando en el terminal 3. Procesar los datos

Validacin de entrada

Durante el proceso de entrada de datos pueden ocurrir errores que tienen que ser detectados y corregidos antes de guardar los datos o procesarlos. Para realizar esto existen tres categoras principales de mtodos: verificacin de la transaccin, la verificacin de los datos de la transaccin y el cambio de ellos.

Verificacin de la transaccin

Cuando se trabaja por lotes, puede ocurrir que las transacciones se acumulen y no se procesen justo en el momento en que se ejecutan, esto trae como consecuencia un alto riesgo de que alguna de ellas no se procese correctamente o que sea olvidada. Un mtodo de control de lotes es asignar una cantidad limitada de lotes, las transacciones se van acumulando por ejemplo en grupos de 50 registros. Cada uno de estos grupos forma un lote, los lotes indudablemente se van a acumular y es posible que el analista especifique un nmero de serie para cada lote de manera de identificarlos con facilidad para que ninguno de ellos pase por alto y no sea procesado.

Verificacin de los datos de la transaccin

Las transacciones validas pueden contener datos invlidos, entonces los analistas deben establecer mtodos de validacin de datos cuando se desarrollan los procedimientos de entrada.

Pruebas de existencia Estas pruebas examinan los campos que son necesarios que contengan datos, para que no sean dejados en blanco o vacos.

Pruebas de lmites y rangos Validan el mnimo y el mximo de caracteres aceptables para un dato

Pruebas de combinacin Cuando un solo dato afecta a los dems, por ejemplo al introducir una categora no se puede colocar en los otros campos datos que no tengan que ver con esa categora, por ello se valida si todos esos campos tienen relacin

Procesamiento duplicado Es procesar lo mismo varias veces y comparar los resultados obtenidos para conocer la veracidad de los mismos

Modificacin de los datos de la transaccin

Esta forma de validacin implica la modificacin automtica de los datos errneos ingresados por el usuario. Para ello existen los siguientes mtodos:

Correccin automtica Este mtodo slo implica que el sistema detecte el error y lo corrija automticamente, por ejemplo no se ingresan ceros en un campo numrico por error del usuario, el sistema lo detecta y agrega los ceros en los espacios en blanco.

Dgitos de verificacin Es aadir un nmero automticamente siguiendo un lineamiento especifico al cdigo que el usuario esta ingresando, de esta manera evitamos los errores de transcripcin y de transposicin.

Diseo de dialogo en lnea La mayora de las aplicaciones de sistemas de informacin desarrolladas hoy en da en las organizaciones utilizan mtodos en lnea, en donde el usuario interacta de forma directa con el sistema de cmputo por medio de una estacin de trabajo o dispositivo familiar.

Los sistemas en lnea se diferencian de aplicaciones en lote porque estos dan respuesta inmediata a las solicitudes del usuario, demanda poco predecible y contacto directo entre la computadora y el usuario. Esto se logra mediante el diseo de una interfase apropiada.

Propsitos de la interfase

Decir al sistema las acciones a realizar

Facilitar el uso del sistema

Evitar los errores del usuario

Caractersticas de la interfase

Las caractersticas de la interfase incluyen los dispositivos utilizados para introducir y recibir datos tales como el teclado, el ratn, scanner, lpiz ptico, etc; el dilogo que incita y gua a los usuarios y los mtodos o patrones que se siguen al mostrar la informacin.

Acciones que se llevan a cabo en la interfase

Navegacin En un sistema manual de reportes y documentos, los usuarios pueden ver cmo saltase la informacin que tienen ante ellos. Debido a que la pantalla del monitor presenta nicamente una pgina de informacin a la vez, el analista debe mantener informado al usuario acerca de qu pgina se est mostrando y cundo cambiar a otras pginas. He aqu algunas de las preguntas que usted podra formular:

Dnde estoy en el sistema? Adnde puedo ir dentro del sistema? Cmo llego al principio? Cmo me muevo hacia atrs? Cmo cancelo el efecto de mi ltima accin? Cmo corrijo mi error? Cmo puede detener la accin de procesamiento que acaba de comenzar?

Diseo del Dilogo

Un dilogo es la forma en la que el usuario interacta con el sistema. Por lo tanto es muy importante el diseo correcto de estos.

Diagramas para dilogos Presentan las secuencias de actividades que se pueden llevar a cabo en un sistema y tambin cmo iniciar las acciones. Por convencin, las funciones de procesamiento se muestran en rectngulos que incluyen el nombre de la funcin. Cada funcin est ligada a funciones de niveles superiores e inferiores mediante una flecha con el nombre de la opcin elegida en el nivel superior.

Decisiones en el diseo de dilogos

La conversacin entre el usuario y el sistema depende completamente del diseo del dilogo. Un diseo fcil de usar significa que la conversacin puede fluir con facilidad. Las decisiones que debe hacer el analista son las siguientes: 1. 2. 3. 4. 5. 6. 7. Estrategia general del dilogo Dilogo de entrada de datos Paginacin y scrolling Mensajes y comentarios Navegacin del usuario Asignacin de teclas Sistema de ayuda

Estrategias de dilogo

Dilogo conducido por men Debido a que los sistemas en lnea proporcionan varias opciones de entrada y procesamiento a los usuarios, se requiere de un mtodo para mostrar a los usuarios las alternativas disponibles. Los mens cumple este propsito, de modo de que el usuario pueda elegir entre las funciones que se encuentran en ese men.

Dilogo por medio del teclado Los usuarios llamas a las actividades de procesamiento tecleando un comando que el sistema entiende. Las tres formas de dilogo mediante teclado incluyen las formas de comando nico, nemnico y de lenguaje natural.

Forma de comando nico: el usuario teclea la palabra clave que el sistema asociar con la realizacin de un proceso especfico Forma de comando nemnico: son abreviaturas de frases largas que se utilizan como comandos para que el usuario no tenga que teclear tanto Forma de lenguaje natural: permite que los usuarios instruyan al sistema con comandos menos rgidos. En vez de utilizar la sintaxis convencional de los comandos, los usuarios aplican su propio vocabulario de palabras u operaciones.

Dilogo pregunta/respuesta

Estos se basan en la presentacin de preguntas al usuario. La respuesta que el usuario d gua el procesamiento resultante

Dilogo con entrada de datos La entrada de datos se ve afectada por la forma en que el sistema ayuda a los usuarios y les pide los datos

Formatos para entrada de datos Es un bosquejo que muestra la informacin a introducir. Adems de los ttulos y encabezados en la pantalla, el formato contiene etiquetas que identifican los datos por introducir

Indicacin pregunta/respuesta Se piden datos al usuario mediante preguntas que hace el sistema. El mtodo pregunta/respuesta, que es sencillo de usar, ofrece la ventaja adicional de permitir el control total de la secuencia en que se recibe la informacin.

Manejo de Pantalla Las pantallas deben seguir un diseo general que proporcione un uso consistente de las reas o ventanas en el monitor. Entre las consideraciones del diseo estn la estandarizacin de uso de ventanas, el manejo de navegacin y secuencias de escape, y la paginacin y scrolling.

Uso de ventanas

Ventana de ttulo: Identifica el ttulo de la pantalla, la funcin a desarrollar o la aplicacin en ejecucin; puede incluir datos del sistema Ventana de instrucciones: Le dice al usuario cmo introducir datos, elegir un procesamiento alternativo o salir del sistema Ventana principal de texto: La porcin ms grande de la pantalla; incluye pantalla para captura de datos, mens o procesamientos alternativos rea de navegacin y men: Instruye al usuario sobre cmo moverse entre las pginas de informacin, pantallas o mens; tambin identifica la informacin de escape Ventana de mensajes: Contiene mensajes de informacin y control Ventana de banderas: Una alternativa que puede utilizarse para sealar las actividades actuales o las instrucciones a procesar

Facilidad de navegacin del usuario Es frecuente que los usuarios se pierdan y requieran de un mapa del sistema. Los mens anidados pueden inhibir la facilidad de navegacin. Para mejorar la navegacin se puede tener una ventana principal en la cual se vayan desglosando las ventanas secundarias de manera que no tengamos que pasar por todos los procesos para salir del sistema por ejemplo.

Paginacin y Scrolling La paginacin se refiere a manejar grandes cantidades de informacin para poder presentarla al usuario as esta informacin ocupe ms de una pantalla la paginacin la divide en varias. El scrolling es cuando la pantalla se mueve hacia arriba o hacia abajo para poder leer toda la informacin. Esta es otra forma de presentar grandes cantidades de informacin.

Mensajes y comentarios: En general los mensajes tienen alguna de las siguientes finalidades:

Indicar el estado del procesamiento Indicar que se ha detectado un error Solicitar al usuario que elija una accin Verificar que una accin elegida sea correcta

Mensajes de estado Los mensajes de estado informan al usuario sobre el progreso de un procesamiento en especifico

Mensajes de error Reportan equivocaciones o eventos inesperados que ha detectado el sistema

Mensajes de solicitud de acciones Le dicen al usuario que hacer

Mensajes de verificacin de acciones Las solicitudes que produzcan cambios significativos o que puedan iniciar procesos de ejecucin larga necesitan verificacin

Sistemas de ayuda Aun en los sistemas mejor diseados, se necesitan funciones de ayuda, no para instruir al usuario, sino para proporcionar informacin acerca de las preguntas que surjan. Por ejemplo dar una breve explicacin de lo que hace un comando antes de ser introducido por el usuario. Una tecla especifica debe estar programada para llamar a la ayuda, independientemente de la funcin a consultar. Algunas caractersticas de ayuda son sensibles al contexto, es decir, determinan la accin que el usuario intenta llevar a cabo y lo auxilian para que termine con xito.

Diagrama de Estructura de datos Estos son utilizados como una herramienta para desarrollar un marco de referencia manejando datos en forma de campos, registros y archivos; aplicndolos en las interacciones con una base de datos. Entre sus principales finalidades se encuentran: 1. 2. 3. 4. Verificar los requerimientos de informacin Describir los datos asociados con las entidades. Mostrar la relacin entre entidades Comunicar los requerimientos de datos a un diseador de archivo o administrador de la base de datos.

Para la realizacin de estos diagramas se utiliza una notacin comn en la cual las entidades se representan mediante rectngulos, con el nombre de la entidad en la parte superior y posteriormente una lista de campos que describan la entidad, a su vez cada entidad se puede identificar con un atributo llave, el cual por general es el primer campo utilizado. Esta realizacin requiere tambin que el analista se plantee las siguientes preguntas: 1. Cuales son los campos que identificaran de manera nica una ocurrencia de la entidad? 2. Por que medios se accesar la informacin acerca de la entidad? 3. Cules otros datos describen los atributos de la entidad?

Tipos de archivo Archivo Maestro:

Es un conjunto de registros acerca de un aspecto de las actividades de una organizacin. Puede contener datos que describan el estado actual de eventos especficos o indicadores de la empresa. Estos son permanentes y duran mientras exista el sistema. Sin embargo, los contenidos de los archivos cambian como resultado del procesamiento y actualizacin.

Archivos de Transacciones: Es un archivo temporal con dos propsitos: acumular datos acerca de los eventos al momento que ocurran y actualizar los archivos maestros para reflejar los resultados de las transacciones actuales. En algn momento ya no son necesarios y se borran o se destruyen, dependiendo del mtodo utilizado para almacenar los datos. Los archivos de transacciones pueden retenerse por meses, a veces incluso por aos, despus de que han sido creado, dependiendo de las necesidades legales y de la organizacin.

Archivo de tablas: Los archivos de tablas contienen datos de referencia utilizados en el procesamiento de transacciones, actualizacin de los archivos maestros o produccin de salida. Estos conservan el espacio de almacenamiento y facilitan el mantenimiento del programa guardado en un archivo de datos que, de otro modo, se incluirn en los programas de los archivo maestro.

Archivo de Reporte: Son archivos temporales que se utilizan cuando el tiempo de impresin no esta disponible para todos los reportes producidos, situacin que surge con frecuencia en el procesamiento sobrepuesto. La computadora escribe el reporte o documento a un archivo en disco o en cinta magntica, donde permanece hasta que pueda imprimirse. Estos se pueden utilizar con muchos otros dispositivos de salida, tales como los graficadotes, unidades de microfilm y microficha o sistemas topogrficos comerciales.

Mtodos de organizacin de archivos Los registros se almacenan en archivos, utilizando una organizacin de archivo que determina como se almacena, localizan y recuperan los registros.

Organizacin secuencial: es la forma mas simple de almacenar y recuperar los registros en un archivo. Estos almacenan los registros unos tras otros sin importar el valor real de los datos en los registros.

Lectura de archivos secuenciales: Para leer un archivo secuencial, el sistema siempre comienza al principio del archivo y lee un registro a la vez hasta llegar al registro deseado.

Evaluacin de archivos secuenciales: Solo se almacenan o leen registros unos despus de otro. Para procesar el archivo, se comienza desde el principio y se lee un registro despus del otro. Es necesario acceder cada registro en el archivo para una aplicacin particular. En este caso en archivo secuencial es un buen mtodo de organizacin.

Organizacin de acceso directo Son archivos con llave. Asocian un registro con un valor llave especfico y un lugar de almacenamiento. Este mtodo le pide al programa que diga al sistema donde de almacena un registro antes de poderlo accesar.

Direccionamiento por hashing: Este mtodo se utiliza cuando no puede ser procesado el acceso directo pero el mismo es necesario. Para la realizacin de este mtodo es necesario disear un algoritmo para transformar un valor de la llave en otro valor que sirva como direccin de almacenamiento.

Requerimientos para los algoritmos de hashing:

Posibilidad de repeticin: La capacidad de almacenar un registro mediante un algoritmo y recuperarlo, utilizado el mismo algoritmo, es un requerimiento importante.

Distribucin uniforme: Esta distribucin los registros deben distribuirse de manera uniforme en todo el espacio asignado en vez de acumularse todos juntos. Minimizar sinnimos: No existe un algoritmo de hashing perfecto, aunque algunos son mejores que otros cuando se trata de minimizar sinnimos. En la prctica, los sinnimos aparecen cuando el procedimiento de dispersin se aplica a llaves distintas y produce la misma direccin en el almacenamiento.

Organizacin indexada: Es la manera de accesar a un registro por medio de un ndice. Esto permite que la bsqueda de un registro sea mas fcil si se usa el ndice, ya que toma menos tiempo buscar un ndice que un archivo completo de datos.

Caractersticas de un ndice: Es un archivo aparte del archivo maestro. Cada registro en el ndice contiene nicamente dos datos: una llave de registro y una de almacenamiento. Para encontrar un registro por el mtodo de la organizacin indexada, se busca primero el ndice para hallar la llave del registro deseado.

Organizacin indexada no secuencial: Existe un registro en el ndice por cada registro en el archivo maestro.

Organizacin indexada secuencial: Es la mas utilizada en los sistemas de informacin, crea un archivo seudosecuencial. Los registros se almacenan en bloques con capacidad de una cantidad especfica de datos.

Desarrollo de sistemas en un ambiente de base datos Permite compartir los datos entre distintas aplicaciones. Adems de la responsabilidad de disear archivos, determinar sus contenidos y elegir los

mtodos apropiados para organizar los datos, se debe disear los medios de interaccin con las bases de datos de organizacin.

Diagramas de estructura de datos Construiremos un diagrama a partir de la informacin obtenida, al preparar el diagrama de relacin entre las entidades.

Apuntadores atributos: Enlazan dos entidades mediante la informacin comn, usualmente un atributo llave en uno y un atributo (no llave) en el otro.

Apuntadores lgicos: Identifica las relaciones entre las entidades; sirven para obtener acceso inmediato a la informacin en una entidad, definiendo un atributo llave en otra entidad.

El impacto de los sistemas de manejo de una base de datos en el diseo de sistemas Este proporciona la flexibilidad en el almacenamiento y recuperacin de datos y produccin de la informacin.

Esquema: El DBMS es un puente entre el programa de aplicacin, el cual determina qu datos son necesarios y como se les procesar, adems del sistema operativo de la computadora, que es el responsable de colocar los datos en los dispositivos de almacenamiento.

Para recupera los datos de la base de datos:

El programa de aplicacin determina que datos se necesitan y comunica la necesidad al DBMS.

El DBMS determina que los datos solicitados realmente estn almacenados en la base de datos (aun cuando podran estar almacenados bajo un nombre distinto, un alias) El DBMS instruye al sistema operativo para localizar y recuperar los datos del lugar especfico en el disco magntico. Se da una copia de los datos al programa de aplicacin para su procesamiento.

Estructuras de datos para los datos interrelacionados

Multilista: Es como una cadena, en donde cada eslabn es un registro que cumple con los requerimientos especificados por el usuario mediante el programa de aplicacin.

Archivo invertido: Este utiliza un ndice para almacenar la informacin acerca de la ubicacin de registros con atributos particulares.

Modelos de datos Modelo relacional: Es en la actualidad el ms popular en los sistemas de manejo de una base de datos, puesto que es conceptualmente sencillo y compresible por profesionales.

Estructuracin de datos Normalizacin: Es el proceso de simplificar la relacin entre los campos de un registro. Por este mtodo, un conjunto de datos en registro se reemplaza por varios registros que son ms simples y predecibles. Se lleva a cabo por cuatro razones:

 Estructurar los datos de forma que se puedan representar las relaciones pertinentes entre los datos. Permitir la recuperacin sencilla de los datos en respuesta a las solicitudes de consultas y reportes. Simplificar el mantenimiento de los datos actualizndolos, insertndolos y borrndolos. Reducir la necesidad de reestructurar o reorganizar los datos cuando surjan nuevas aplicaciones.

Manipulacin de datos

Operaciones SELECT: Es cuando produce una nueva tabla en respuestas a una consulta o solicitud de reporte creada a partir de los renglones de la tabla inicial que cumplan los criterios de la solucin.

Operaciones PROJECT: Es la que crea una nueva tabla a partir de los datos extrados, utilizando atributos especificados en la pregunta.

Operaciones JOIN: Es la que crea una nueva relacin combinando dos tablas existentes, eligiendo los registros que cumplan los criterios establecidos en la pregunta y removiendo despus los registros duplicados.

Modelo jerrquico. Es el que relaciona las entidades por medio de una relacin superior/ subordinado.

Modelo de red Es parecido al modelo jerrquico excepto que una entidad puede tener ms de un superior.

DISEO PARA COMUNICACIN DE DATOS Canales de comunicacin Un canal es la ruta que interconecta al punto de donde se transmiten los datos con su destino.

Cable telefnico por pares: Es el mas antiguo y comn de los canales de comunicacin.

Velocidades de transmisin: Esta velocidad se mide en bits por segundo. La velocidad de transmisin depende de varios factores distintos, incluyendo las caractersticas del canal de comunicacin, dispositivos asociados al canal y los componentes de hardware o software.

Cable coaxial: Este medio hace posible velocidades ms altas de transmisin, y permite que ms datos se muevan en el canal en un periodo de tiempo.

Microondas: No se utilizan cables, las estaciones de envo y recepcin llevan la transmisin por el aire.

Satlite:

Los datos se transmiten desde las instalaciones del usuario a una estacin terrena, de donde se envan a un satlite ubicado en el espacio, este recibe la seal y la retransmite a otro destino en la tierra.

Fibras pticas: Una fibra de vidrio o plstico se introduce en un largo cilindro que acta como medio de transmisin. Los pulsos de luz transportan los datos.

Redes de comunicacin Estas pueden cubrir diferentes distancias, segn los requerimientos de la organizacin y el sistema de informacin. Las redes operan en las reas siguientes: 1 Internacionales 2 Entre los estados 3 En el interior de un estado 4 Dentro de las instalaciones locales

Topologa de red: Las redes de comunicaciones utilizan 4 topologas distintas, que son la disposicin de los dispositivos de comunicacin y rutas de datos que llevan acabo la transmisin de datos.

Sistema entre puntos: Funcionan con terminales o estaciones de captura de datos en una instalacin conectadas directamente a un sistema en otra instalacin. Estos sistemas pueden comunicar computadoras, interconectando lugares separados para que sean capases de comunicarse entre si.

Topologa estrella:

Cada estacin de trabajo o computadora puede comunicarse solamente con la instalacin central y no con los dems nodos de la red.

Topologa de anillo: Permite la comunicacin directa entre los nodos y con la computadora central, en otras palabras la instalacin central no maneja los datos que se transmiten de un nodo a otro.

Modelo de interconexin IEA Este modelo pone nfasis en la capacidad de poder utilizar el equipo de varios fabricantes distinto en las redes de comunicacin. Este modelo divide una red en 7 niveles, cada uno con tareas y funciones claras y proporciona entradas especficas para los niveles adyacentes.

Nivel fsico: Este nivel une la computadora y el flujo de datos con el canal de comunicacin. Aqu se consideran los aspectos elctricos y no el como se empacan los datos o los patrones de los datos. Nivel de lnea de datos: En este nivel predomina el intercambio de marcos de datos, garantizando que cada dispositivo pueda enviar y recibir datos. Su servicio principal es la deteccin y control de errores.

Nivel de la red: Este es el responsable de establecer, mantener y terminar las conexiones entre los componentes de una red. Aqu se crea y se manejan paquetes de datos. Todos los datos se transfieren en paquetes individuales.

Nivel de transporte: Este nivel nombra, direcciones, almacena y utiliza un multiplexor para los mensajes formados en paquetes en el nivel de la red; tambin establece y termina las secciones de transmisin.

Nivel de seccin: Este nivel crea y maneja las interconexiones que existen entre dos entes que se comunican, tambin maneja las tcnicas de recuperacin en el caso en que la comunicacin termine de forma abrupta debido a un error, falla o desconexin.

Nivel de presentacin: Este nivel maneja la traduccin y formateo de los datos; la traduccin de cdigos y la compresin de datos.

Nivel de aplicacin: El punto de acceso del usuario a la red, consta del software de aplicacin.

Diseo de redes locales Estas tienen como finalidad conectar las computadoras y componentes de un sistema de cmputo dentro de una rea geogrfica limitada. La mayora de estas redes usan una topologa de distribuidas y se basan en el cable coaxial para enlazar a los participantes de su propia red. En algunos casos estas son muy tiles para los analistas, ya que tienen que conectar este tipo de redes con la de cobertura amplia utilizando compuertas.

Sistemas Distribuidos: Un sistema distribuido conecta los lugares a travs de los dispositivos de cmputo en diversos lugares para permitir el procesamiento local de los datos y aun as permitir la transmisin y elaboracin de resmenes para otras oficinas centrales de una corporacin. Una ventaja es que se puede compartir software aun cuando el equipo de cada punto de la red sea de marcas distintas.

Registros de auditorias: Estos estn diseados para permitir el rastreo de cualquier registro de entrada o proceso llevado a cabo en un sistemas son un mtodo esencial para conservar la

integridad y confiabilidad de un sistema, ya que cuando los analistas desarrollan sistemas tienen que tomar en cuenta la validacin del usuario, las solicitudes de procesamientos y la proteccin de las transacciones en lnea. Aun cuando el procesamiento se difiera un gran tiempo despus de la captura inicial de los datos, se requieren protecciones para salvaguardar los datos y el sistema contra la perdida de su estabilidad.

Objetivos de diseo: Las personas que desarrollan los sistemas buscan dos objetivos operacionales que son la confiabilidad y la facilidad de mantenimiento del sistema.

Diseo de sistema confiable Un sistema es confiable si, al usarse de manera razonable no produce fallas peligrosas o costosas. Esta definicin distingue entre los errores del software, en los que el sistema no arroja los resultados esperados, y las fallas que se presentan. A diferencia del hardware, en el que puede haber fallas de fabricacin y del equipo, las fallas del software son resultados de errores de diseo introducidos cuando se formularon las especificaciones y se escribi el software.

Un aspecto adicional del aseguramiento de la calidad es evitar la necesidad de mejoras, y desarrollar software que sean fciles de mantener.

Grafica de estructura de programas Un sistema estructurado modular y desarrollado en forma descendiente, separados en componentes manejables. Los mdulos deben disearse de forma que tengan un mnimo efecto sobre los dems mdulos del sistema

Los diagramas de estructura Es una herramienta de diseo que muestra grficamente las relaciones entre los mdulos de un programa.

Informacin de control

Ayuda a controlar el proceso, indicando la ocurrencia de errores o condiciones que afectan el proceso, tal como el indicador de fin de archivo.

Diseo del software Seis principios caracterizan a los buenos diseos del software:

1. Modularidad y fragmentacin: cada sistema va a estar formado por una jerarqua de mdulos, los mdulos de niveles inferiores son menores en alcance y tamao comparados con los mdulos de nivel superior. 2. Acoplamiento: los mdulos de un sistema deben tener poca dependencia entre si. 3. Cohesin: los mdulos deben llevar a cabo solo una funcin de procesamiento 4. Extensin de control: los mdulos deben interactuar y coordinar las funciones de un nmero limitados de mdulos de nivel inferior. 5. Tamao: las instrucciones contenidas en un modulo debe ser limitadas; el tamao del modulo es generalmente pequeo 6. Uso compartido: las funciones no deben repetirse en mdulos separados sino establecerse en nico modulo que se puede utilizar en cualquier otro cuando sea necesario.

Diseo del software y herramientas de documentacin

Diagrama de flujo estructurado

Son herramientas graficas que fuerzan al diseador a estructurar software que sea modular y descendiente

Elementos bsicos

Existen tres elementos bsicos para el desarrollo de los diagramas de flujos estructurados: proceso, decisin e iteracin.

Proceso: esto se representa mediante un rectngulo y representa la inicializacin de variables, actividades de entrada y salida, y las llamadas para ejecutar otros procedimientos.

Decisin: este smbolo representa condiciones alternativas que pueden ocurrir y que el programa debe poder manejar.

Iteracin: representa los ciclos y repeticin de operaciones mientras exista una condicin dada o hasta que haya una condicin.

Hipo: es un diagrama grafico del sistema y esta formado por una tabla visual de contenido que describe el sistema en general. Cada diagrama muestra la entrada, salida, pasos del proceso y flujos de datos.

Diagramas de Warnier-Orr Muestran de forma explcita las relaciones jerrquicas entre los procesos y subprocesos, en este modelo el analista trabaja de reversa, empezando con la salida del sistema y definiendo el sistema cada vez con ms detalles. Estos fciles diagramas son una forma excelente de mostrar las relaciones entre los procesos que integran un sistema.

Niveles de seguridad de la calidad Prueba: estas garantizan que el sistema se desempea de forma adecuada y que cumple con sus requerimientos, el propsito principal de esta es hallar errores, no el demostrar lo correcto de un sistema

Verificacin y validacin: La verificacin tiene la intencin de hallar errores a igual que la prueba. Este se lleva a cabo ejecutando un programa en un ambiente simulado.

La validacin esta se refiere al proceso del uso del software en un ambiente no simulado para hallar sus errores.

Certificacin: Es una garanta de lo correcto de un programa, su importancia va en aumento para las aplicaciones de sistemas de informacin.

Estrategias de prueba:

Prueba de cdigo: Esta examina la lgica del programa. Para seguir este mtodo, se ejecutan casos de programa para la realizacin de cada instruccin en el programa o mdulo; es decir, se prueba cada ruta del programa.

Prueba de especificacin: Esta se lleva a cabo cuando se examina las especificaciones que sealan lo que el programa debe hacer y cmo lo debe llevar a cabo bajo diferentes condiciones.

Niveles de prueba El analista debe llevar a cabo pruebas parciales y pruebas de sistemas.

Pruebas parciales: Se centran primero en los mdulos, dependientes entre si, localizar los errores esto permite al que realice la prueba detectar errores en el cdigo y lgica contenidos dentro de ese nico mdulo. Los casos de prueba necesarios para las pruebas parciales deben probar cada condicin u opcin. Las pruebas parciales se pueden llevar a cabo en forma ascendente, comenzando con los mdulos mas pequeos y a nivel inferior y continuando de uno en uno.

Prueba de sistemas:

Las pruebas de sistemas no prueba el software en s, sino la integracin de cada mdulo en el sistema. Tambin busca las discrepancias entre el sistema y su objetivo original, especificaciones y documentacin del sistema. La preocupacin principal es la compatibilidad de los mdulos individuales.

Pruebas especiales de sistemas Existen seis pruebas especiales que son: la prueba de carga mxima, almacenamiento, tiempo de ejecucin, recuperacin, procedimiento y de factores humanos. Tanto los datos reales como los artificiales se usan para probar sistema. Algunas organizaciones guardan los datos en bibliotecas de prueba para garantizar que todos los sistemas relacionados pueden procesar un conjunto comn de datos de prueba cuidadosamente preparados. Las fallas en la prueba se muestran rpidamente cuando el sistema se implanta.

Administracin de proceso de implantacin del sistema

Capacitacin:

La implantacin de un nuevo sistema en una empresa es una situacin que debe pensarse debido a que no se sabe el impacto que va a tener el nuevo sistema en los dems empleados, a lo mejor algunos de los empleados no han tenido contacto con los equipos del nuevo sistema, aunque poco a poco esto ah ido cambiando ya que la nuevas tecnologas estn en nuestros hogares y es difcil conseguir a empleados que no tengan ningn tipo de relacin con una computadora, y lo mas importante es que ahora no les tienen miedo sabes y estn concientes que ellas le van a aminorar el trabajo adems de optimizarlo. Algo bien importante a la hora de implantar un sistema nuevo es la capacitacin del personal operador del sistema, yendo desde los conceptos mas bsicos de computacin como lo pueden ser hardware y software, generalidades del procesamiento de datos. Tambin se le debe entrenar o capacitar directamente con el sistema, la navegacin por el mismo, por sus mens, funciones, caractersticas. Tambin se le debe capacitar con lo que esta relacionado con los almacenamientos de registros, datos, entrega de reportes, impresin de salidas. una vez dado este aprendizaje previo se le deja utilizar el sistema bajo una supervisin.

La implantacin engloba todos los pasos que van desde el sistema viejo hasta llegar al nuevo, aunque existen casos en que el sistema nuevo saca totalmente al viejo. Estos sistemas pueden ser manuales o automatizados. Sin importar lo anterior lo que se busca es una buena implantacin para as lograr que el sistema sea confiable y funcional. Esta parte es esencial para una empresa ya que si el analista se pierde de detalles de implantacin aunque el sistema se optimo este no rendir como lo pudiese hacer. Existen dos etapas para el momento de la capacitacin como son : la capacitacin del personal como hicimos una breve resea anteriormente, y los procedimientos de conversin y revisin despus de la implementacin.

Capacitacin: Explicando mejor esta parte ya que pensamos que es sper importante para que el sistema fluya de la mejor manera, es importante que cada una de las personas que estn involucradas con el sistema conozca cada detalle sus roles, que har y que no har el sistema. Cmo capacitar a los operadores del sistema? Siempre es importantsimo que el departamento de computo este sper entrenado con el sistemas para que as le pueda brindar un soporte bien sea por cosas sencillas como para cosas extraordinarias que se puedan presentar en el da a da. Si la implantacin necesita una nueva plataforma tecnolgico, nuevos equipos, etc. si es necesario ensearle hasta como encenderlo, como apagarlo, como trabaja, todo lo que concierne a la captura de datos. Al operador se le debe de entrenar en lo que son los posibles errores y as ir crendole una lista de estos con sus posibles soluciones, as como tambin los nmeros telefnicos de las personas que realizaron el sistema por si ocurre algo que no sepan como resolver. Muy importante es tambin capacitarlo o famirializarlo con los procedimientos del sistema, como puede ser la creacin de archivos, facilitar la rpida navegacin por el sistema entre otras cosas.

Algo que es muy importante tambin es la capacitacin que se le tiene que dar al usuario. Capacitacin del usuario: Esta capacitacin tambin tiene que venir desde lo mas bsico como puede ser la introduccin de un diskete, cuando apagar el Aquino sin perder datos etc. ya que hay muchos casos en el cual el operador es el mismo usuario, tambin hay que capacitarlos con el reconocimiento de los errores ya que as ellos sabrn si el error es producido por su culpa o por problemas de software. La mayor parte de la capacitacin de usuario es con el trato especficamente con el sistema, enfatizando con los estndares de la captura de datos. Tambin es importante que sepa como utilizar los perifricos como impresoras, saber que hay que meterle papel, recargar tinta entre otras cosas.

Es importante que el analista realice un manual de usuario el cual contemplara toda la informacin que requerir el usuario. Estas clases o cursos de capacitacin pueden llevarse a cabo desde la mima empresa donde se esta implantando como tambin el en hoteles o sitios ajenos a la empresa ya que puede ser que el proveedor haga uso del sistema tambin.

Conversin: Este es el proceso de cambiar el sistema anterior al nuevo, existen nos mtodos para el logro efectivo de esta conversin. Existen 4 mtodos para llevar a cabo esta conversin, estos mtodos deben ser estudiados con cuidado para que as se implante el mtodo que mejor se le encaje a la conversin.

Mtodos de conversin:

Sistemas paralelos: es el mtodo mas seguro, el cual consiste en poner a trabajar los dos sistemas en paralelo, de esta manera los usuario siguen utilizando el sistema anterior de manera acostumbrada aunque van teniendo mas contacto con el otro. La data va a ser poco a poco migrada de un sistema a otro y sin que el usuario se de cuenta vamos obligndolo a usar poco a poco mas el nuevo sistema. Una de las desventajas es que al estar operando los dos sistemas los costos se duplicaran debido a que pudiera ser que se tenga que contratar personal para que opere los dos sistemas, puede que tambin el nuevo sistema sea rechazado por los usuarios y se vuelva al sistema anterior. Conversin directa: este tipo de conversin se hace de manera radical debido que se hace de un da a otro obligando tanto fsico como psicolgicamente al usuario que no existe otro sistema y debe usar ese. Esto tiene una desventaja ya que al eliminar por completo el sistema antiguo se quedan sin respaldo, y si el sistema nuevo llegase a tener problemas este quedara parando a la empresa hasta que se solucione, tambin la empresa se retrasa varias semanas debido que toda la captura de datos debe empezarse de nuevo y los departamentos deben ponerse a trabajar con eso. una vez que empiece este proceso debe seguirse a pesar de las frustraciones que pueden haber por cuestin de tiempo perdido. Este mtodo necesita una buena planificacin, para que as no exista perdida de ningn tipo. Enfoque piloto: este mtodo funciona de la siguiente manera, tenemos el sistema pero solo se lo aplicamos a un departamento a manera de prueba para as tambin ir probndolo y mejorndolo una vez capaces de trabajar con el, y saber que el sistema esta trabajando en su

plenitud y no tiene errores y ah minimizado tareas en ese departamento tanto como costos, tiempo etc. se va a implementar en toda la empresa. Modelo por etapas: este mtodo se da debido a la tardanza de la llegada del nuevo sistema que pasara de das a meses y es por eso que solo algunos tendrn acceso a el. Ejemplo: soy un empresario, tengo 15 tiendas de ropa, automatizar a las 15 tiendas alomejor me sale muy costoso y es por eso que la implanto primero en 5 tiendas y luego en el resto.

Plan de conversin:

Esto no es mas que hacer un plan donde se explique o salga explicito las personas que estn involucradas con el nuevo sistema y que responsabilidad tiene con el, programas de actividades, cuando debe llevarse a cabo una situacin cuando otra, todos los archivos que van a ser convertidos, los datos necesarios para estos archivos, nuevos procedimientos, etapas de verificacin para as ver si cada uno de las personas o el sistema esta trabajando al da, las asignaciones de responsabilidades, as como tambin el tiempo para cada rutina para que al final se haga la nueva implantacin de la manera mas estable que es con la que se planeo. Este plan tambin debe contener posibles errores y como deben ser enfrentados.

Es necesario que el analista establezca y acondicione el sitio para que soporte este nuevo sistema, cables, computadores, controles de humedad etc. para que as el local esta listo antes que lleguen los equipos.

Preparacin de datos y archivos: Es necesario tener los archivos ya migrados de un sistema a otro ya que es esta la etapa que mas se tarda ya que al principio se va a tener que teclear unos cuando registros, siempre es recomendable tener medidores de errores ya que debemos evitar que este pase de informacin se haga de manera segura que no haya errores ya que repercutirn despus con el desenvolvimiento del sistema. Para evitar que falten registros que trabaja con lo llamado procesos por lotes que no es mas que enviar o almacenar cada 50 o 100 registros y as se puede verificar cada grupo antes de ser accedidos. Siempre es bueno que toda transaccin de archivos se haga de manera seriada si es que esta viene de un dispositivo remoto as sabemos que si de un sitio salieron 1000 en el otro estn los 1000 archivos.

Revisin despus de la implementacin: Una vez listo el sistema con todas sus conversiones de archivos el analista con su grupo de trabajo deben probar el sistema para determinar el buen funcionamiento del mismo y si se deben hacer los ajustes o no. Despus de tener un trato con el sistema se hace como un estudio de expectativas, como se sinti el usuario con el sistema si optimizo el proceso o no? Todo esto es muy importante ya que hay que ver si el sistema impuesto es el mas optimo, esto se hace a travs de encuestas a los usuarios, entrevistas y as se sabr el impacto del sistema entre los usuarios que son aquellos que lo van a manejar u operar y si a ellos no les conviene a la empresa tampoco ya que lo que se busca es optimizar procesos y no desmejorarlos.

Administracin del proceso de desarrollo de sistemas de informacin Todo proyecto exitoso de sistemas de informacin debe esto a que son dirigidos de una manera correcta. A pesar de todo los programas fallan ya que a veces no c toma en cuenta lo critico que lo procesos pueden ser o que no se haya usado el personal mas calificado. Para evitar esto se formulan unas estimaciones y se calendariza para que as se pueda hacer un estudio de su desempeo.

Estimacin y control del tiempo de desarrollo: un desarrollo tarda de un proyecto es un poco desanimante para los usuarios es por eso que continuacin le presentaremos un mtodo para el mejor desarrollo de la planificacin de el tiempo. Estimacin de los requerimientos del tiempo: Las estimaciones son las horas, meses, das, segundos de esfuerzo necesario para desarrollar el sistema deseado. Estas van a ser determinadas por la habilidad del analista, o programadores o sencillamente por la complejidad del sistema. Mtodo de estimacin del tiempo: Existen tres mtodos para la estimacin del tiempo de desarrollo del proyecto. Mtodo histrico: se trata de los registros cuidadosos que tienen de realizaciones de proyectos anteriores, con todas sus caractersticas pa que sean despus comparados con los actuales y as se pueda hacer la estimacin, es por eso que no es el mas utilizado ya que es difcil mantener los registros tan rigurosos y adems el proyecto nuevo debe ser muy parecido al antiguo para que la estimacin sea de confiar.

Mtodo intuitivo: es el mtodo que lo lleva a cabo las personas con mas antigedad en la empresa y con mas experiencia con proyectos. Este mtodo es bastantemente utilizado ya que es rpido pero dependiendo de la experiencia de la persona ser preciso. Mtodo estndar: este va a venir determinado por el estudio detallado de cada proceso y cada peso individual y despus a travs de una formula aritmtica especifica que nos llevara al resultado mas acertado y confiable

Para realizar cualquiera de estos mtodos es necesario tomar en cuenta cada uno de los detalles del proyecto debido a que son muy importantes para la buena estimacin (desde el momento en que se decide hacerse el proyecto, pasando por el lenguaje de programacin a utilizar hasta su implementacin). Es recomendable la utilizacin de software de programacin de proyectos como puede ser el MS. Project.

Administracin del personal: Es muy importante la seleccin de buenos equipos de trabajo y saber adems como estructurarlo ya que bien sabemos como nos ha podido haber pasado en los anos de estudiantes la importancia de este punto. Los equipos se pueden estructurar de las siguientes maneras:

Equipos con programador en jefe: este equipo consta con un jefe programador, uno de respaldo y un grupo de apoyo. El programador en jefe debe ser una persona con grandes habilidades y experiencia, el cual esta a la cabeza del diseo. El programador de respaldo es quien tiene las opciones alternativas, una persona con diseo de estrategias, aunque con menos experiencia que el programador en jefe. Y el resto es el grupo de apoyo que son los que vana a trabajar bajo la supervisin de sus jefes. Equipos de especialistas: como su nombre lo indica es un grupo de trabajo donde cada uno de los integrantes son especialistas en un rea el cual se va a complementar con la unicidad del grupo. Este tipo de agrupacin tambin tiene su programador en jefe y el de respaldo Equipos sin liderazgos: a diferencia de los dems este tipo de agrupacin no tiene ninguna figura de lder establecida, esta lo que hace es dejar fluir el grupo y se ve que poco a poco va a surgir un jefe o lder de manera informal dependiendo de su habilidad. estos se reparten el trabajo dependiendo de las habilidades de cada quien, estos son grupos de trabajo que no se disgregan estos siguen juntos en todos los proyectos.

Recorridos estructurados:

Esto no es ms que una revisin detallada, y planificada de un sistema o software. Generalmente estn involucradas en ella las personas que lo crearon, los jefes de departamento esta revisin tiene unas caractersticas y son las siguientes: El propsito de este recorrido es hallar las reas en las que se puede mejor el proceso. El proceso de revisin no se afinca en la reparacin de errores si no en la optimizacin de ellos. Siempre la organizacin designa a como que un lder para esta revisin, casi siempre es el analista ya que es este el que esta mas familiarizado con el proceso. Cada vez mas los coordinadores del sistema se estn dando cuenta de lo importante que es seguir con un estndar para todo ya que as su revisin va a ser mas fcil, y de mantenimiento para futuros grupos de revisin.

Revisin de los requerimientos: Esto es la revisin que se lleva a cabo por los requerimientos expuestos por el analista, trata de ver las funciones que el nuevo sistema debe manejar y verificar que lo este haciendo, esto se hace para verificar si existe inconsistencia en los datos o en el diseo para as poder atacar este problema.

Revisin de diseo: Este recorrido es por la parte lgica del diseo, para ver si cumple con las necesidades efectivamente. si lo usuarios muestran una insatisfaccin con el resultado esto lo re estudiara el analista.

Revisin del cdigo: Aqu se revisa los mdulos principales de el cdigo fuente a fin de ver si ese modulo arroja los resultados esperados, verificar si coincide con las especificaciones originales. As se puede mejorar de manera paulatina y los usuarios no se vern frustrados con un sistema vago.

Revisin de las pruebas: En esta etapa es cuando la empresa contrata a una empresa consultara para que realice este trabajo aunque es bien importante que la empresa ya sepa antes de llamar a la empresa consultora que trabajo va a ellos consultar venga la redundancia. Un consultor va a ser contratado para dar una opinin objetiva dar observaciones

objetivas debido a su experiencia, dar informacin tcnica acerca de un tema en especfico, y dar sugerencias que mejoraran el sistema implantado. Todo estas revisiones deben ser realizadas antes de ser aprobado el sistema nuevo si no supera las pruebas debe ser mejorado hasta que lo haga y una vez hecho ser aprobado.

Seleccin del hardware: En este segmento hablaremos de la necesidad de hardware y el como decidir cual escoger sin dejarnos llevar por los consejos otras personas. Las computadores pueden variar desde un microcomputador hasta una gran instalacin de red se nos hace muy difcil la eleccin del equipo. Existen muchas caractersticas que se deben tomar en cuenta como por ejemplo: la memoria, velocidad de procesamiento, canales de comunicacin, almacenamientos auxiliares entre otras cosas. As como tambin una buena configuracin, niveles de acceso,. Es necesario tambin que se implante un equipo compatible, ya que as se minoriza costos ya que se esta trabajando con una empresa que nos puede brindar a su vez un soporte tcnico de las maquinas, etc. Otra opcin pudiese ser el rentar el equipo, y en el momento que este obsoleto se cambia el equipo sin ningn problema, pero es muy costoso este tipo de solucin. Tambin existen rentas a largo plazo (3 a 7 anos) este es menos caro que la renta antes mencionada.

Mantenimiento y soporte: Esto es muy importante ya que los equipos usualmente son utilizados por gente que no les interesa mucho su equipo es por eso que existen las garantas, o por sencillamente el equipo vino con algn defecto de fabrica ellos se harn responsables esta garanta ser de 90 das o bien dependiendo de el trato llegado en la negociacin. El analista debe tomar en cuenta muchas cosas y esta no se le puede pasar por alto y debe tratar que en el contrato se especifique esta parte para el as poder cubrirse las espaldas y tener un buen mantenimiento del equipo que seguramente es muy costoso, por que no sirve de nada para la empresa que se gaste grandes cantidades de dinero en un bien inmueble para que despus se pierda por que se le dejo morir.

Seleccin del software: Esta seleccin es muy importante al igual que la seleccin del software. Para la eleccin del software es necesario tener encuesta el sistema que se va a implantar, para as ver cual software es el ms adecuado. Lo mas esencial al momento de la eleccin es saber que tipo de transacciones de datos se va a realizar, tipo de reportes,

que manejadores de bases de datos vamos a necesitar, el sistema tendr alguna caracterstica especifica que deba ser atendida por alguna aplicacin en especifico, el hardware, limitaciones del mismo etc. este a su vez debe ser flexible ya que debe cumplir con todas las necesidades de los usuarios aunque tampoco tan flexible, mas bien en la parte de los reportes. Tambin se busca que el software tenga algun tipo de soporte tcnico por que si llegase a fallar seria un gran percance y un gran retraso para la empresa, todo esto debe estar contenido en el contrato del software con la casa productora con todas sus especificaciones y utilidades.