Metodología de desarrollo de softwareSaltar a: navegación, búsqueda

Metodología de desarrollo de software en ingeniería de software es un marco de trabajo usado para estructurar, planificar y controlar el proceso de desarrollo en sistemas de información.1

Tres patrones básicos en las metodologías de desarrollo de software.

Índice

1 Introducción 2 Historia 3 Metodologías 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

Introducción

Una metodología de desarrollo de software se refiere a un framework que es usado para estructurar, planear y controlar el proceso de desarrollo en sistemas de información.

A lo largo del tiempo, una gran cantidad de métodos han sido desarrollados diferenciándose por su fortaleza y debilidad.

El framework para metodología de desarrollo de software consiste en:

Una filosofía de desarrollo de programas de computacion con el enfoque del proceso de desarrollo de software

Herramientas, modelos y métodos para asistir al proceso de desarrollo de software

Estos frameworks son a menudo vinculados a algún tipo de organización, que además desarrolla, apoya el uso y promueve la metodología. La metodología es a menudo documentada en algún tipo de documentación formal.

Historia

El desarrollo de los sistemas tradicionales de ciclo de vida se originó en la década 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 información en una muy deliberada, estructurada y metódica, reiterando cada una de las etapas del ciclo de vida. Los sistemas de información en torno a las actividades resueltas pesadas para el procesamiento de datos y rutinas de cálculo.

Metodologías de Desarrollo de Software tiene como objetivo presentar un conjunto de técnicas tradicionales y modernas de modelado de sistemas que permitan desarrollar software de calidad, incluyendo heurísticas de construcción y criterios de comparación de modelos de sistemas.

Para tal fin se describen, fundamentalmente, herramientas de Análisis y Diseño Orientado a Objetos (UML), sus diagramas, especificación, y criterios de aplicación de las mismas. Como complemento se describirán las metodologías de desarrollo de software que utilizan dichas herramientas, ciclos de vida asociados y discusión sobre el proceso de desarrollo de software más adecuado para las diferentes aplicaciones ejemplos que se presentarán. Principalmente, se presentará el Proceso Unificado el cual utiliza un ciclo de vida iterativo e incremental.

Kendall y Kendall

I. Identificación del problema, oportunidades y objetivos. II. Determinación de los requerimientos de información. III. Análisis de las necesidades del sistema. IV. Diseño del sistema recomendado. V. Desarrollo y documentacion del software. VI. Pruebas y mantenimiento del sistema. VII. Implantación y evaluación del sistema.

James Senn

I. Ciclo de vida y desarrollo del sistema. II. Desarrollo por análisis estructurado III. Prototipo del sistema.

Llorens Fabregas

I. Requerimientos. II. Analisis/Diseño. III. Construcción. IV. Pruebas. V. Producción y mantenimiento.

Jonas Montilva

I. Definir el proyecto. II. Análisis del contexto. III. Definición de los requerimientos. IV. Diseño preliminar. V. Diseño detallado.

Roger Pressman

I. Análisis de los requerimientos del Software. II. Diseño. III. Genaracion de codigo. IV. Pruebas. V. Mantenimiento.

Metodologías de desarrollo de software

1970s

Programación estructurada sol desde 1969 Programación estructurada Jackson desde 1975

1980s

Structured Systems Analysis and Design Methodology (SSADM) desde 1980 Structured Analysis and Design Technique (SADT) desde 1980 Ingeniería de la información (IE/IEM) desde 1981

1990s

Rapid application development (RAD) desde 1991. Programación orientada a objetos (OOP) a lo largo de la década 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.

Thórisson Agile Unified Process (AUP) desde 2005 por Scott Ambler

Enfoques de desarrollo de software

Cada metodología de desarrollo de software tiene más o menos su propio enfoque para el desarrollo de software. Estos son los enfoques más generales, que se desarrollan en varias metodologías específicas. Estos enfoques son los siguientes:1

Modelo en cascada: Framework lineal. Prototipado: Framework iterativo. Incremental: Combinación de framework lineal e iterativo. Espiral: Combinación 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 través de las fases de análisis de las necesidades, el diseño, implementación, pruebas (validación), la integración, y mantenimiento. La primera descripción formal del modelo de cascada se cita a menudo a un artículo publicado por Winston Royce W. 2 en 1970, aunque Royce no utiliza el término "cascada" de este artículo.

Los principios básicos del modelo de cascada son los siguientes:1

El proyecto está dividido en fases secuenciales, con cierta superposición y splashback aceptable entre fases.

Se hace hincapié en la planificación, los horarios, fechas, presupuestos y ejecución de todo un sistema de una sola vez.

Un estricto control se mantiene durante la vida del proyecto a través de la utilización de una amplia documentación escrita, así como a través de comentarios y aprobación / signoff por el usuario y la tecnología de la información de gestión al final de la mayoría de las fases antes de comenzar la próxima 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 básicos 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 pequeña parte de los sistemas, antes de proceder a la próxima incremental

Se definen los requisitos antes de proceder con lo evolutivo, se realiza un mini-Cascada de desarrollo de cada uno de los incrementos del sistema

El concepto inicial de software, análisis de las necesidades, y el diseño de la arquitectura y colectiva básicas se definen utilizando el enfoque de cascada, seguida por iterativo de prototipos, que culmina en la instalación del prototipo final.

Espiral

Los principios básicos son:

La atención se centra en la evaluación y reducción del riesgo del proyecto dividiendo el proyecto en segmentos más pequeños y proporcionar más facilidad de cambio durante el proceso de desarrollo, así como ofrecer la oportunidad de evaluar los riesgos y con un peso de la consideración de la continuación del proyecto durante todo el ciclo de vida.

Cada viaje alrededor de la espiral atraviesa cuatro cuadrantes básicos: (1) determinar objetivos, alternativas, y desencadenantes de la iteración; (2) Evaluar alternativas; Identificar y resolver los riesgos; (3) desarrollar y verificar los resultados de la iteración, y (4) plan de la próxima iteración.3

Cada ciclo comienza con la identificación de los interesados y sus condiciones de ganancia, y termina con la revisión y examinación.3

Rapid Application Development (RAD)

El desarrollo rápido de aplicaciones (RAD) es una metodología de desarrollo de software, que implica el desarrollo iterativo y la construcción de prototipos. El desarrollo rápido de aplicaciones es un término originalmente utilizado para describir un proceso de desarrollo de software introducido por James Martin en 1991.

Principios básicos:

Objetivo clave es para un rápido desarrollo y entrega de una alta calidad en un sistema de relativamente bajo coste de inversión.

Intenta reducir el riesgos inherente del proyecto partiéndolo en segmentos más pequeños y proporcionar más facilidad de cambio durante el proceso de desarrollo.

Orientación dedicada a producir sistemas de alta calidad con rapidez, principalmente mediante el uso de iteración por prototipos (en cualquier etapa de desarrollo), promueve la participación de los usuarios y el uso de herramientas de desarrollo computarizadas. Estas herramientas pueden incluir constructores de Interfaz gráfica de usuario (GUI), Computer Aided Software Engineering (CASE) las herramientas, los sistemas de gestión de bases de datos (DBMS), lenguajes de programación de cuarta generación, generadores de código, y técnicas orientada a objetos.

Hace especial hincapié en el cumplimiento de la necesidad comercial, mientras que la ingeniería tecnológica o la excelencia es de menor importancia.

Control de proyecto implica el desarrollo de prioridades y la definición de los plazos de entrega. Si el proyecto empieza a aplazarse, se hace hincapié en la reducción de requisitos para el ajuste, no en el aumento de la fecha límite.

En general incluye Joint application development (JAD), donde los usuarios están intensamente participando en el diseño del sistema, ya sea a través de la creación de consenso estructurado en talleres, o por vía electrónica.

La participación activa de los usuarios es imprescindible. Iterativamente realiza la producción de software, en lugar de enfocarse en un

prototipo. Produce la documentación necesaria para facilitar el futuro desarrollo y

mantenimiento.

Otros enfoques de desarrollo de software

Metodologías de desarrollo Orientado a objetos, Diseño orientado a objetos (OOD) de Grady Booch, también conocido como Análisis y Diseño Orientado a Objetos (OOAD). El modelo incluye seis diagramas: de clase, objeto, estado de transición, la interacción, módulo, y el proceso.

Top-down programming, evolucionado en la década de 1970 por el investigador de IBM Harlan Mills (y Niklaus Wirth) en Desarrollo Estructurado.

Proceso Unificado , es una metodología de desarrollo de software, basado en UML. Organiza el desarrollo de software en cuatro fases, cada una de ellas con la ejecución de una o más iteraciones de desarrollo de software: creación, elaboración, construcción, y las directrices. Hay una serie de herramientas y productos diseñados para facilitar la aplicación. Una de las versiones más populares es la de Rational Unified Process.

Metodologías para el desarrollo de software

UNIDAD VI. Asignatura: 071-4323

Metodología de desarrollo de software se describe como el conjunto de herramientas, técnicas, procedimientos y soporte documental para el diseño de Sistemas de información.

En Ingeniería 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 ingeniería, en el cuál se debe ejecutar una serie de fases, etapas para obtener un programa que funcione de acuerdo con métodos ya establecidos en otras disciplinas de ingeniería.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 definición del software a producir (producto), el desarrollo o el diseño del software, la validación del software tanto lo interno(requerimientos específicos)como lo externo(expectativas del cliente), y la evolución del software donde se modifica para adaptarlo a los cambios.2

Por otro lado, Sommerville (2002) define que “un método de ingeniería de software es un enfoque estructurado para el desarrollo de software cuyo propósito es facilitar la producción de software de alta calidad de una forma costeable”, cabe destacar que para

usar este enfoque se debe manejar conceptos fundamentales tales como; procesos, métodos, tareas, procedimientos, técnicas, herramientas, productos, entre otros.

Particularmente, una metodología se basa en una combinación de los modelos de proceso genéricos para obtener como beneficio un software que soluciones un problema. Adicionalmente una metodología debería definir con precisión los artefactos, roles y actividades, junto con prácticas, técnicas recomendadas y guías de adaptación de la metodología al proyecto. Sin embargo, la complejidad del proceso de creación de software es netamente dependiente de la naturaleza del proyecto mismo, por lo que el escogimiento de la metodología estará acorde al nivel de aporte del proyecto, ya sea pequeño, mediano o de gran nivel.

Contenido

[ocultar]

1 Evolución histórica de las metodologías de desarrollo de software 2 Generaciones de metodologías

o 2.1 Desarrollo Convencional o 2.2 Desarrollo Estructurado o 2.3 Desarrollo Orientado a Objetos

3 Características deseables de una metodología 4 Metodologías Vs. Ciclo de vida 5 Modelos de procesos en el desarrollo de software 6 Clasificación de las Metodologías según 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 rápido de aplicaciones (DRA) 6.1.4 Modelos Evolutivos

6.1.4.1 Construcción 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 Programación Extrema (XP) 6.2.2 Desarrollo Adaptativo del Software (DAS) 6.2.3 Modelo de Desarrollo de Sistemas Dinámicos (MDSD) 6.2.4 Modelo Scrum 6.2.5 Desarrollo conducido por características (DCC) 6.2.6 Proceso Unificado de Rational (RUP)

o 6.3 Diferencias entre los modelos de proceso convencionales y ágiles 7 Clasificación de las metodologías según su enfoque

o 7.1 Metodologías estructuradas 7.1.1 Metodologías orientadas a procesos 7.1.2 Metodologías orientadas a datos

o 7.2 Metodologías para sistemas de tiempo real o 7.3 Metodologías Orientadas a Objetos

8 ¿Que metodología es conveniente usar? 9 Modelos de procesos utilizados en el desarrollo de software

o 9.1 Modelado de Negocios o 9.2 Modelado de Negocios e Ingeniería de Requisitos o 9.3 Cadena de Valor

10 Conclusiones 11 Referencias

Evolución histórica de las metodologías de desarrollo de software Desde que se empezó a trabajar sobre el desarrollo de programas, se siguieron ciertos métodos que permitían llevar a producir un buen proyecto, estas metodologías aplicadas eran simples, solo se preocupaban por los procesos mas no por los datos, por lo tanto los métodos eran desarrollados hacia los procesos. El modelo de procesos predominaba para los años 60 y consistía en codificar y corregir (Code-and-Fix), si al terminar se descubría que el diseño era incorrecto, la solución era desecharlo y volver a empezar 3, este modelo implementaba el código y luego se pensaba en los requisitos, diseño, validación y mantenimiento. los principales problemas del modelo de procesos son:

Los arreglos se hacen costosos, después de tantas correcciones el código tenia una mala estructura.

El software no se ajusta a las necesidades del usuario, por lo que es rechazado o su reconstrucción es muy cara.

El código es difícil de reparar por su pobre preparación para probar y modificar.

En la década de los setenta empezó a tomar la importancia de los datos, y para solucionar sistemas complejos empezó el análisis por partes o etapas, se introducen la planeación y administración. El modelo en cascada surge como respuesta al modelo de procesos, este modelo tiene mas disciplina y se basa en el análisis, diseño, pruebas y mantenimientos. 4

La década de los ochenta es la época marcada por las metodologías dirigida a datos cuya importancia va tomando cuerpo en las organizaciones. Se empiezan a estudiar los objetos en sí como unidades de información. Para los años 90 se quiere dar respuesta al entorno siempre cambiante y en rápida evolución en que se han de desarrollar los programas informáticos, lo cual da lugar a trabajar en ciclos cortos (como mini-proyectos) que implementan una parte de las funcionalidades, pero sin perder el rumbo general del proyecto global.

Por otra parte las metodologías de desarrollo comienzan a interesarse no sólo en lograr que el proyecto sea puesto en funcionamiento sino en minimizar costos durante su desarrollo y sobre todo durante su mantenimiento. Los nuevos métodos van buscando minimizar riesgos y, puesto que los errores más perjudiciales se producen en los primeros pasos, se comienza ya desde la fase más general del estudio por analizar los riesgos que significa seguir con las siguientes fases del desarrollo.

Las metodologías más utilizadas a nivel mundial en orden cronológico:13

Década de los 70s

Programación Estructurada Jackson desde 1975

Década de los 80s

Structured Systems Analysis and Design Methodology (SSADM) desde 1980

Structured Analysis and Design Technique (SADT) desde 1980

Ingeniería de la Información (IE/IEM) desde 1981

Década de los 90s

Rapid Application Development (RAD) desde 1991.

Programación Orientada a Objetos (OOP) a lo largo de la década 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

Año 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. Thórisson

Agile Unified Process (AUP) desde 2005 por Scott Ambler

La trascendencia de las metodologías se ha hecho notoria, pasando de solo programar, luego a

establecer funciones en etapas o módulos, continuar en resaltar en la primera etapa el análisis

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 solución sin reprochar los

recursos disponibles.

Generaciones de metodologías

Las metodologías han ido cambiando con el tiempo, al surgir nuevos paradigmas que rompe con lo tradicional para abrir paso a nuevas técnicas de solución.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 programación estructurada seguido de los método de análisis y diseño, cubre todo el ciclo de vida completo). Actualmente aparece el paradigma de la orientación a objetos.

Desarrollo Convencional

En los años 50 el desarrollo estaba a cargo de programadores, por lo que se vio la importancia del análisis y diseño en el desarrollo de los sistemas. Aparecen los analistas programadores y analistas de sistemas.6

En esta misma época, no existían metodologías de desarrollo. Las personas que desarrollaban los sistemas eran programadores más 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 análisis previo. Ante esta perspectiva se vio la importancia del análisis y del diseño 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 aludía únicamente al crecimiento económico dando por supuesto que dicho crecimiento se revierte de manera casi automática en los otros sectores de la estructura social. Las estrategias de desarrollo se han concentrado fundamentalmente en estrategias económicas, que aunque incorporan elementos de otros sectores –por ejemplo del sector social-, buscan como objetivo fundamental el crecimiento económico. Por otra parte los índices de desarrollo social se han centrado únicamente en los niveles de satisfacción 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 cuándo 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 documentación estandarizada o no se actualizan oportunamente.

En el desarrollo convencional todo el programa está en un solo bloque, con ejecución

secuencial de instrucciones. Eran los tiempos del ensamblador, las capacidades reducidas y la

necesidad de optimizar al máximo. Se enfoca tanto a las necesidades del cliente y por lo cual,

los programas se hacían sin usar una metodología concreta,solo los programadores se

proponían a construir un código y si contenía errores era muy difícil prever donde se

encontraban.

Desarrollo Estructurado

El desarrollo estructurado comenzó con la programación. A mediados de los 60 el enfoque estructurado se extiende a la fase de diseño que se conoce como diseño estructurado, el cual se basa en definir una abstracción más amplia usando los módulos de programa como componentes básicos de construcción. A mediados de los 70, se empezaron a surgir las técnicas estructuradas, donde se empezó a construir programas de una forma artesanal con métodos de ingeniería. El desarrollo estructurado permitió facilitar la comprensión de programas, normas para la aplicación de estructuras de datos y de control.6

En el diseño estructurado se caracteriza por lo siguiente:

Mayor nivel de abstracción (independencia del lenguaje programación).

-Elemento básico de diseño: módulo.

Modularidad que permite medir la calidad de programas.

Representa los procesos, flujos y estructuras de datos, de una manera jerárquica 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 diseñar un buen proceso y estructura de un programa, tiene inconvenientes como:

Leer todas las especificaciones para entender el problema.

Se repetía la misma información 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 análisis estructurado o análisis descendente o top - down. Desde su aparición se han hecho mejoras como dar menor importancia a la construcción de los modelos físicos actuales y a los modelos lógicos actuales, diferenciar más los modelos físicos y lógicos. Ampliar las técnicas de análisis estructurado, para modelar sistemas en tiempo real y enfocarse en el modelo de datos.

En el desarrollo estructurado los programas están 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

interacción. Este desarrollo se enfoca al diseño del programa y la compresión se hace mas fácil.

Se ha hecho evidente que este enfoque aun está un poco arraigado ya que se tiende a no pasar

de un proceso o iteración 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 información

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 programación Orienta a Objetos en los que se daba énfasis a la abstracción de datos para los que se adjuntaba un conjunto de operaciones. Por otra parte los conceptos de técnicas estructuradas han servido de base para muchas de las metodológicas OO.6

La orientación a objetos empieza con los lenguajes de programación 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 metodología orientada a objetos el sistema se organiza como una colección de objetos que interactúan entre sí y que contienen tanto estructuras de datos como un comportamiento. Esto se opone a la programación convencional, en la cual las estructuras de datos y el comportamiento solamente están relacionadas de forma débil, ya que estos se enfocan principalmente a las funciones.

Los principios del modelo OO son:7

Abstracción: Es una descripción simplificada o especificación de un sistema que enfatiza algunos de los detalles o propiedades del sistema, mientras suprime otros.

Encapsulación: En el proceso de ocultar todos los detalles de un objeto que no contribuyen a sus características esenciales.

Modularidad: Es la propiedad de un sistema que ha sido descompuesto en un conjunto de módulos coherentes e independientes.

Jerarquía o herencia: Es el orden de las abstracciones organizado por niveles.

Tipificación: Es la definición 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 través de la cual su existencia trasciende el tiempo (es decir, el objeto continua existiendo después de que su creador ha dejado de existir) y/o el espacio (es decir, la localización del objeto se mueve del espacio de dirección 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

estarán 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 extrañas entre

distintas partes del programa y podemos cambiar la implementación 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.

Características deseables de una metodología

Existencia de reglas predefinidas, fases y subfases, tareas, productos intermedios, técnicas y herramientas tales que se amolden a cualquier desarrollo.

Cobertura total del ciclo de desarrollo.

Verificaciones intermedias.

Planificación y control.

Comunicación efectiva.

Utilización sobre un abanico amplio de proyectos.

Fácil formación.

Herramientas case.

La metodología debe contener actividades que mejoren el proceso de desarrollo.

Soporte al mantenimiento. Por ejemplo. Reingeniería.

Soporte de la reutilización de software, no solo reutilización de código.

Actualmente, se huye de métodos muy burocráticos o monolíticos.

Lo que se quiere de una metodología es que permita definir las etapas, las salidas, entradas de

un proyecto. Mantener un programa no es fácil pero se puede lograr, por lo tanto, las

metodologías deben permitir una robusta formación del proyecto que permita utilizar

mecanismos de mejora y que se usen los recursos disponibles con su mayor rendimiento y

eficacia.

Metodologías Vs. Ciclo de vida

Una metodología es un conjunto integrado de técnicas y métodos que permite abordar de forma homogénea y abierta cada una de las actividades del ciclo de vida de un proyecto de desarrollo. Una definición estándar de metodología puede ser el conjunto de métodos que se utilizan en una determinada actividad con el fin de formalizarla y optimizarla. Determina los pasos a seguir y cómo realizarlos para finalizar una tarea.15

Si esto se aplica a la Ingeniería de software, podemos destacar que una metodología:

Optimiza el proceso y el producto software.

Es una guía en la planificación y en el desarrollo del software.

Define qué hacer, cómo y cuándo durante todo el desarrollo y mantenimiento de un proyecto.

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

Fases: tareas a realizar en cada fase.

Productos: E/S de cada fase, documentos.

Procedimientos y herramientas: apoyo a la realización de cada tarea.

Criterios de evaluación: 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 transición 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 ejecución. Hacia dónde queremos ir, y no cómo queremos ir. Las características implícitas o explícitas de cada proyecto hacen necesaria una etapa previa destinada a obtener el objetivo por el cual se escribirán miles o cientos de miles de líneas de código. Un alto porcentaje del éxito de nuestro proyecto se definirá en estas etapas que, al igual que la etapa de debugging, muchos líderes de proyecto subestiman.

Planificación: idearemos un planeamiento detallado que guíe la gestión del proyecto, temporal y económicamente.

Implementación: acordaremos el conjunto de actividades que componen la realización del producto.

Puesta en producción: nuestro proyecto entra en la etapa de definición, 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 sólo por representar la aceptación o no del proyecto por parte del cliente o usuario final sino por las múltiples dificultades que suele presentar en la práctica, alargándose excesivamente y provocando costos no previstos.

Control en producción: control del producto, analizando cómo 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 pequeñas 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 rediseño. Incluimos también en esta etapa el liderazgo, documentación y capacitación, proporcionando directivas a los recursos humanos, para que hagan su trabajo en forma correcta y efectiva.

Objetivos de cada etapa:

Expresión 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 cómo, se va a implementar).

Especificaciones: Formalizamos los requerimientos; el documento obtenido en la etapa anterior se tomará como punto de partida para esta etapa.

Análisis: Determinamos los elementos que intervienen en el sistema a desarrollar, su estructura, relaciones, evolución temporal, funcionalidades, tendremos una descripción clara de qué producto vamos a construir, qué funcionalidades aportará y qué comportamiento tendrá.

Diseño: Ya sabemos qué hacer, ahora tenemos que determinar cómo debemos hacerlo (¿cómo debe ser construido el sistema en cuestión?); 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).

Implementación: Empezamos a codificar algoritmos y estructuras de datos, definidos en las etapas anteriores, en el correspondiente lenguaje de programación 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, análisis y diseño con la consiguiente pérdida de control sobre la gestión del proyecto.

Debugging (Depuración): El objetivo de esta etapa es garantizar que nuestro programa no contiene errores de diseño o codificación. En esta etapa no deseamos saber si

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

Validación: Esta etapa tiene como objetivo la verificación 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 validación y debugging se realizan en paralelo por la estrecha relación que llevan. Sin embargo, tenemos que evitar la confusión: podemos realizarlos en paralelo, pero no como una única etapa.

Evolución: En la mayoría de los proyectos se considera esta etapa como Mantenimiento y evolución, y se le asigna, no sólo el agregado de nuevas funcionalidades (evolución); sino la corrección de errores que surgen (mantenimiento). En la práctica esta denominación no es del todo errónea, ya que es posible que aun luego de una etapa de debugging y validación exhaustiva, se filtren errores.

Una metodología puede seguir uno o varios modelos de ciclo de vida, adaptándose 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 metodología 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 metodología o varias metodologías, 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 representación simplificada de pasos, representada desde una perspectiva específica. Por su naturaleza los modelos son simplificados, por lo tanto un modelo de procesos del software es una abstracción de un proceso real. 2

Estos modelos tienen como propósito la producción eficaz y eficiente de un producto software que reúna los requisitos del cliente. Este proceso es intensamente intelectual, afectado por la creatividad y juicio de las personas involucradas.La mayoría de los modelos de procesos de desarrollo del software son dirigidos por el tiempo; cuanto más tarde sea, más atrás se encontrará en el proceso de desarrollo. Como todo proceso, están 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 definición del proyecto, el análisis del contexto, definición de requerimientos, diseño del sistema, construcción del sistema, pruebas e implantación.

Operación y mantenimiento, donde realiza ajustes y se buscan fallas.

Renovación o extinción.

Los procesos de software son complejos debido a que un producto de software es intangible y por lo general muy abstracto, esto dificulta la definición 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 producción se realiza sistemáticamente y la base de conocimiento para el desarrollo de dicha actividad está claramente definida. Respecto del software, su construcción y resultados han sido históricamente 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, además 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 diseño y sus funciones y que la mayoría de ellos están orientados al

mantenimiento.

Clasificación de las Metodologías según 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 Ingeniería 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 ingeniería del software, y definir cada acción 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 genérico para el proceso, ya que estos modelos se caracterizan por ser en esencia rígidos,estrictos y los mas utilizados.

En las metodologías 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 más eficiente. Para ello, se hace énfasis en la planificación 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 definición de roles, actividades, artefactos, herramientas y notaciones para el modelado y documentación detallada. Además, las metodologías tradicionales no se adaptan adecuadamente a los cambios, por lo que no son métodos 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 después lo siguen. Además, la gente que ha solicitado el software

tiene un papel por desempeñar se ejecuta el modelo de software. ¿Por qué es importante?

Porque proporciona estabilidad, control y organización a una actividad que si no se controla

puede volverse caótica. ¿Cuáles son los pasos? El proceso conduce a un equipo de software a

través de un conjunto de actividades del marco de trabajo que se organizan en un flujo de

proceso. ¿Cuál 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 clásico, sugiere un enfoque sistemático, secuencial hacia el desarrollo del software, que se inicia con la especificación de requerimientos del cliente y que continúa con la planeación, el modelado, la construcción 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, también

cuando el trabajo fluye desde la comunicación a través del despliegue de una manera casi lineal, esta situación se encuentra a veces cuando es necesario hacer adaptaciones o mejorías bien definidas a un sistema existente.

El modelo en cascada es el paradigma más antiguo para la ingeniería del software. Sin embargo, en las décadas pasadas, las criticas a este modelo de proceso han ocasionado que aun sus más fervientes practicantes hayan cuestionado su eficacia. Entre los problemas que algunas veces se encuentran al aplicar el modelo en cascada están:

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 actúa.

2. Con frecuencia es difícil para el cliente establecer todos los requisitos de manera explícita. 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 versión 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 revisión del programa.

En un análisis 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 más común 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 características, funciones y contenido de la información). 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 están fijos y donde el trabajo se realiza, hasta su conclusión, de una manera lineal.

Las principales etapas de este modelo según Sommerville (2005) son:

Análisis y definición de requerimientos. Los servicios, restricciones y metas del sistema se definen a partir de las consultas con los usuarios. Se define una especificación del sistema.

Diseño del sistema y del software. El proceso de diseño del sistema divide los requerimientos en sistemas hardware o software. Establece una arquitectura completa del sistema. El diseño del software identifica y describe las abstracciones fundamentales del sistema software y sus relaciones.

Implementación y prueba de unidades. Durante esta etapa, el diseño del software se lleva a cabo como un conjunto o unidades de programas.

Integración 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 práctico. El mantenimiento implica corregir errores no descubiertos en las etapas anteriores del ciclo de vida.

Algunas veces llamado el ciclo de vida clásico, sugiere un enfoque sistemático, secuencial hacia

el desarrollo del software, que se inicia con la especificación de requerimiento del cliente y que

continúa con la planeación, el modelo, la construcción, 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, podría realizar funciones básicas de administración de archivos, edición y producción de documentos; en el segundo incremento, ediciones más sofisticadas, y tendría funciones más complejas de producción de documentos; en el tercer incremento, funciones de corrección ortográfica y gramatical; y en el cuarto, capacidades avanzadas de configuración de página. Se debe tener en cuenta que el flujo del proceso de cualquier incremento puede incorporar el paradigma de construcción de prototipos que se expone más adelante.

A menudo, al utilizar un modelo incremental el primer incremento es un producto esencial. Es decir, se incorporan los requisitos básicos, pero muchas características suplementarias (algunas conocidas, otras no) no se incorporan. El producto esencial queda en manos del cliente (o se somete a una evaluación detallada). Como resultado de la evaluación se desarrolla un plan para el incremento siguiente. El plan afronta la

modificación del producto esencial con el fin de satisfacer de mejor manera las necesidades del cliente y la entrega de características y funcionalidades adicionales. Este proceso se repite después de la entrega de cada incremento mientras no se haya elaborado el producto completo.

El modelo de proceso incremental, al igual que la construcción de prototipos y otros enfoques evolutivos, es iterativo por naturaleza. Pero a diferencia de la construcción 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 implementación 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) más personal para implementar el incremento siguiente. Además, los incrementos se pueden planear para manejar los riesgos técnicos. Por ejemplo, un sistema grande podría requerir la disponibilidad de un hardware nuevo que está en desarrollo y cuya fecha de entrega es incierta. Sería posible planear los primeros incrementos de forma que se evite el uso de este hardware, lo que permitiría 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 pequeñas pero

usables (incrementos). Cada parte se construye sobre partes ya entregadas.

Modelo de desarrollo rápido de aplicaciones (DRA)

El desarrollo rápido de aplicaciones (DRA) es un modelo de proceso de software incremental que resalta un ciclo de desarrollo corto. El modelo DRA es una adaptación

a "alta velocidad" del modelo en cascada en el que se logra el desarrollo rápido mediante un enfoque de construcción 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 días).

Como otros modelos de proceso, el enfoque DRA cumple con las actividades genéricas del marco de trabajo que ya se han presentado. La comunicación trabaja para entender el problema de negocios y las características de información que debe incluir el software. La planeación 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 diseño que sirven como base para la actividad de construcción del modelo DRA. La construcción resalta el empleo de componentes de software existente y la aplicación de la generación automática de código. 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 aplicación de negocios se puede modular de forma que cada gran función pueda completarse en menos de tres meses (mediante la aplicación del enfoque ya descrito), ésta es una candidata para el DRA. Cada gran función se puede abordar mediante un equipo de DRA por separado, para después 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 número correcto de equipos DRA.

2) Si los desarrolladores y clientes no se comprometen con las actividades rápidas necesarias para completar el sistema en un marco de tiempo muy breve, los proyectos DRA fallarán.

3) Si un sistema no se puede modular en forma apropiada, la construcción de los componentes necesarios para el DRA será problemática.

4) Si el alto rendimiento es un aspecto importante, y se alcanzará al convertir interfaces en componentes del sistema, el enfoque DRA podría no funcionar.

5) El DRA sería inapropiado cuando los riesgos técnicos son altos (por ejemplo, cuando una aplicación nueva aplica muchas nuevas tecnologías).

Es un modelo de proceso del software incremental que resulta un ciclo de desarrollo corto. El modelo DRA es una adaptación a alta velocidad del modelo en cascada en el que se logra el desarrollo rápido mediante un enfoque de construcción 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 diseño, uso y reuso de los objetos de aprendizaje, como complemento al proceso de su

descripción, de una manera iterativa o incremental, desde la concepción del objeto de

aprendizaje hasta su reusabilidad a corto, mediano y largo plazo. Pero el éxito en la creación de

cualquier objeto de aprendizaje dependerá de la adecuada aplicación del proceso de Ingeniería

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 gestión 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 versión 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 más completas del software. A continuación se presentan algunos de los modelos que se clasifican en esta categoría.

Construcción de prototipos

Modelos en espiral

Modelo de desarrollo concurrente

En los modelos evolutivos se produce un sistema inicial que evoluciona según 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 especificación, desarrollo y

validación.

Construcción de Prototipos

En Ingeniería de software la construcción 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 diseño rápido se basa en una representación de aquellos aspectos del software que serán visibles para el cliente o el usuario final (por ejemplo, la configuración de la interfaz con el usuario y el formato de los despliegues de salida). El diseño rápido conduce a la construcción de un prototipo, el cual es evaluado por el cliente o el usuario para una retroalimentación; gracias a ésta se refinan los requisitos del software que se desarrollará. La iteración 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 construcción de prototipos se puede utilizar como un modelo del proceso independiente. Sin importar la forma en que éste se aplique, el paradigma de construcción de prototipos ayuda al desarrollador de software y al cliente a entender de mejor manera cuál será el resultado de la construcción cuando los requisitos estén satisfechos.

Etapas:

Plan rápido.

Modelado, diseño rápido.

Construcción del Prototipo.

Desarrollo, entrega y retroalimentación.

Comunicación.

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.

También 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 debería tomar la interacción humano-máquina.

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 ingeniería.

Desventajas:

El usuario tiende a crearse unas expectativas cuando ve el prototipo de cara al sistema final. A causa de la intención de crear un prototipo de forma rápida, 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 función. Es frecuente que el usuario se muestre reacio a ello y pida que sobre ese prototipo se construya el sistema final, lo que lo convertiría en un prototipo evolutivo, pero partiendo de un estado poco recomendado.

El desarrollador suele tomar algunas decisiones de implementación poco convenientes (por ejemplo, elegir un lenguaje de programación incorrecto porque proporcione un desarrollo más rápido). Con el paso del tiempo, el desarrollador puede olvidarse de la razón 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 debería

tomar la interacción hombre – máquina, entonces en este caso es cuando se puede emplear la

construcción de prototipos. Se crea un diseño rápido que se centra en una representación de

aquellos aspectos del software que serán visibles para el usuario final, a su vez el diseño rápido

conduce a la construcción de un prototipo. Después, el prototipo lo evalúa el usuario y con la

retroalimentación 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 demás modelos por considerar el riesgo. El modelo en espiral para la ingeniería de software es actualmente el enfoque más 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 número de actividades estructurales, también llamadas regiones de tareas, según Sommerville (2005) el ciclo de vida del modelo en espiral se divide cuatro sectores:

1. Definición de objetivos. En esta fase se identifica las restricciones del proceso y le producto, y dependiendo los riesgos para trazar objetivos y respectivamente panes estratégicos.

2. Evaluación y reducción de riesgos. Se hace un análisis detallado para casa riesgo y se establece los pasos para reducirlos.

3. Desarrollo y validación. Después de evaluar los riesgos, se elige un modelo para el desarrollo del sistema.

4. Planificación. El proyecto se revisa y se toma la decisión de si debe continuar con un ciclo posterior de la espiral.

Las características que se pueden indicar del modelo en espiral son:

El software se desarrolla en una serie de versiones increméntales. Durante las primeras iteraciones.

La versión incremental podría ser un modelo en papel o un prototipo.

A medida que se va incrementando el número 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 construcción de prototipos en cualquier etapa de evolución del producto.

Demanda una consideración directa de los riesgos técnicos en todas las etapas del proyecto. Reduce los riesgos antes de que se conviertan en problemáticos.

Desventajas:

Puede resultar difícil 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 surgirán 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 identificación de riesgos y refinamiento para su uso generalizado.

Lo característico del modelo es espiral es que incluye un “análisis 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, también debemos buscar varias opciones de

resolución de problemas para de allí escoger la opción más conveniente, y además analizar los

riesgos que se pueda tener. Este modelo necesita de otro métodos 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 clásico] 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 codificación, hay personal de ese proyecto implicado en actividades asociadas generalmente a muchas fases de desarrollo simultáneamente. Por ejemplo,...el personal esta escribiendo requisitos diseñando, codificando, haciendo pruebas y probando la integración (todo al mismo tiempo). Los modelos de proceso de ingeniería del software de Humphrey y Kellner han mostrado la concurrencia que existe para actividades que ocurren para cualquier fase. El trabajo más reciente de Kellner utiliza diagramas de estado para representar la relación 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 gestión del software en mi proyecto...La mayoría de los modelos de procesos de desarrollo del software son

dirigido por el tiempo; cuanto más tarde sea, mas atrás se encontrara en el proceso de desarrollo. (Un modelo de proceso concurrente) esta dirigido por las necesidades del usuario, las decisiones de la gestión y los resultados de las revisiones."

Acorde con la descripción 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 ingeniería del software proporcionando una visión certera del estado actual del proyecto. Se puede representar en forma de esquema como una serie de actividades técnicas importantes, tareas y estados asociados a ellas. 19

Funcionalidad del proceso:

Cada actividad, acción o tarea dentro de la red existe de manera simultánea con otras.

Los sucesos generados dentro de una actividad dada o algún 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 división de sistemas y una división de componentes. Los aspectos del nivel de sistemas se afrontan mediante dos actividades: diseño y realización.

La concurrencia se logra de dos formas:

1. Las actividades del sistema y de componente ocurren simultáneamente y pueden modelarse con el enfoque orientado a objetos descrito anteriormente. 2. Una aplicación cliente/servidor típica se implementa con muchos componentes, cada uno de los cuales se pueden diseñar 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 señaladas no es aplicable. Si no existen grupos de trabajo no se puede trabajar en este método

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 iteración de varios ciclos de vida en cascada. Al final de cada iteración se le entrega al cliente una versión mejorada o con mayores funcionalidades del producto. El cliente es quien después de cada iteración evalúa el producto y lo corrige o propone

mejoras. Estas iteraciones se repetirán 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 están claros por parte del usuario, por lo que se hace necesaria la creación de distintos prototipos para presentarlos y conseguir la conformidad del cliente. Cada iteración es un mini proyecto en cascada auto contenido compuesto de actividades como análisis de requerimientos, diseño, programación y pruebas. 15

Ventajas:

Permite crear cada vez versiones más completas de software

Resolución de problemas de alto riesgo en tiempos tempranos del proyecto.

Visión 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 desvíos en la duración total del proyecto.

Desventajas:

Requiere de un cliente involucrado durante todo el curso del proyecto. Hay clientes que simplemente no estarán 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 metodologías ágiles son un conjunto de métodos de ingeniería del software, que se basan en el desarrollo iterativo e incremental, teniendo presente los cambios y respondiendo a estos mediante la colaboración de un grupo de desarrolladores auto-organizados y multidisciplinares.

En las metodologías ágiles, los procesos se desarrollan de manera solapada, donde el ciclo de vida del proyecto, es cíclico. La diferencia en el ciclo de vida de un proyecto ágil, en comparación 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 traído como resultado que proyectos no resulten exitosos debido al cambiante contexto que existe, por lo cuál las metodologías ágiles pretende resolver este inconveniente, construyendo soluciones a la medida asegurando la calidad. Los métodos ágiles fueron pensados especialmente para equipos de desarrollo pequeños, con plazos reducidos, requisitos volátiles y nuevas tecnologías. La filosofía de las metodologías ágiles, pretenden dar mayor valor al individuo, a la colaboración 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 drásticamente los tiempos de desarrollo pero manteniendo una alta calidad.14

La dirección del enfoque de establecer una metodología que solventara los cambios drásticos del ambiente, dió origen en febrero de 2001, tras una reunión celebrada en Utah-EEUU, en esta reunión participan un grupo de 17 expertos de la industria del software, incluyendo algunos de los creadores o impulsores de metodologías de software. Su objetivo fue esbozar los valores y principios que deberían permitir a los equipos desarrollar software rápidamente y respondiendo a los cambios que puedan surgir a lo largo del proyecto. Se pretendía ofrecer una alternativa a los procesos de desarrollo de software tradicionales (metodologías pesadas), caracterizados por ser rígidos y dirigidos por la documentación que se genera en cada una de las actividades desarrolladas.

La fundación del manifiesto ágil, una organización, 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 enfocarán y establecierán 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 más 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 automáticamente. Es mejor crear el equipo y que éste configure su propio entorno de desarrollo en base a sus necesidades.

Desarrollar software que funciona más que conseguir una buena documentación. La regla a seguir es “no producir documentos a menos que sean necesarios de forma inmediata para tomar un decisión importante”. Estos documentos deben ser cortos y centrarse en lo fundamental.

La colaboración con el cliente más que la negociación de un contrato. Se propone que exista una interacción constante entre el cliente y el equipo de desarrollo. Esta colaboración entre ambos será la que marque la marcha del proyecto y asegure su éxito.

Responder a los cambios más 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 tecnología, en el equipo, entre otros) determina también el éxito o fracaso del mismo. Por lo tanto, la planificación 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 diálogo cara a cara es el método más eficiente y efectivo para comunicar información 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 deberían ser capaces de mantener una paz constante.

IX. La atención continua a la calidad técnica y al buen diseño mejora la agilidad.

X. La simplicidad es esencial.

XI. Las mejores arquitecturas, requisitos y diseños surgen de los equipos organizados por sí mismos.

XII. En intervalos regulares, el equipo reflexiona respecto a cómo llegar a ser más efectivo, y según esto ajusta su comportamiento.

En definición las metodologías ágiles son un conjunto de métodos de ingeniería del software, que se basan en el desarrollo iterativo e incremental, teniendo presente los cambios y respondiendo a estos mediante la colaboración de un grupo de desarrolladores auto-organizados y multidisciplinares.

Las características esenciales del proceso de desarrollo ágil para la mayoría de los proyectos son las siguientes:

Busca la satisfacción del cliente.

Entrega temprana de software incremental.

Utilizan métodos informales.

Simplicidad general del desarrollo.

La comunicación 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 retroalimentación con el cliente, a traves de entregas de prototipos ejecutable o porción de un sistema operacional, en periodos cortos para que la adaptabilidad mantenga un buen ritmo con el cambio.

Programación Extrema (XP)

La programación extrema (XP, extreme Programming) es un modelo de proceso de software el fue acuñado 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 pequeños, considera que la mejor manera de tratar la falta de requisitos estables en un sistemas, es mediante la agilidad de un grupo pequeño de desarrollo 8 . Esta se basa en la simplicidad, la comunicación y el reciclado continuo de código. El modelo considera varios aspectos problemáticos del desarrollo de software como lo son los retrasos , proyectos cancelados, cambios en el negocio y la rotación del personal. Sus actividades básicas son : Codificar, hacer pruebas, escuchar y diseñar.

Los objetivos de XP son muy simples:

1. La satisfacción del cliente: trata de dar al cliente el software que él necesita y cuando lo necesita.

2. Potenciar al máximo el trabajo en grupo: Tanto los jefes de proyecto, los clientes y desarrolladores, son parte del equipo y están involucrados en el desarrollo del software.

XP define cuatro variables para proyectos de software: coste, tiempo, calidad y ámbito. Además de estas cuatro variables, Beck propone que sólo 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 función de las otras tres. 8

Los valores originales de la programación extrema son:4

Simplicidad: XP propone el principio de hacer la cosa más simple que pueda funcionar, en relación al proceso y la codificación. Esta es la base de la programación extrema.

Comunicación: Los programadores se comunican constantemente gracias a la programación por parejas y además la comunicación con el cliente es fluida ya que el cliente forma parte del equipo de desarrollo

Retroalimentación: retroalimentación concreta y frecuente del cliente, del equipo y de los usuarios finales da una mayor oportunidad de dirigir el esfuerzo.

Coraje o valentía : La valentía le permite a los desarrolladores que se sientan cómodos con reconstruir su código cuando sea necesario. Esto significa revisar el sistema existente y modificarlo si con ello los cambios futuros se implementaran mas fácilmente.

Principios básicos en la Programación extrema: 9

Planificación Incremental: los requerimientos se registran en tarjetas de historias, estas incluyen el tiempo y la prioridad relativa.

Entregas pequeñas: estas entregas son frecuentes e incrementalmente añaden funcionalidad al primera entrega

Diseño sencillo: solo se lleva a cabo el diseño 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.

Refactorización: conserva el código sencillo y mantenible.

Programación 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.

Integración 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 programación extrema es uno de los método ágiles más conocido y ampliamente utilizados,

donde el usuario o cliente forma parte del equipo de trabajo, engloba en una serie de principios

dentro de los más importantes se encuentra la programación en parejas y el desarrollo de

pruebas, así como también reulitización de los códigos. Para el uso de XP los requerimientos

deben de estar bien definidos, mediante las historias de usuario. Este modelo se basa en la

retroalimentación 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 preocupándose por el aprendizaje de los desarrolladores y la satisfacción

del cliente

Desarrollo Adaptativo del Software (DAS)

El desarrollo adaptativo de software (DAS) 1998 fue propuestos por Jim Highsmith como una metodología para desarrollar el software y sistemas muy complejos. Este se centra en la colaboración humana y la organización 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: Especulación, colaboración y aprendizaje

- Fase de especulación: Es la primera de las fases esta inicia en el desarrollo del proyecto. Se utiliza información como la visión del cliente, las restricciones del proyecto y los requisitos básicos para definir el conjunto de ciclos en el que se harán los incrementos del software. En esta fase es donde se lleva a cabo la planificación tentativa del proyecto en función de las entregas que se iran realizando

- Fase de colaboración: 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 críticas constructivas y ayudar si resentimientos, así como también 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 revisión de calidad que se realiza al final de cada ciclo, esto permite mejorar el entendimiento real sobre la tecnología, los procesos utilizados y el proyecto. El aprendizaje individual permite al equipo tener mayor posibilidad de éxito.

Esta metodología no proporciona el tipo de prácticas detalladas como lo hace XP, pero

proporciona la base fundamental de por qué el desarrollo adaptable es importante y las

consecuencias a los más profundos niveles de la organización y la gerencia. Los apoyos

filosóficos del DAS se enfocan en la colaboración humana y la organización propia del equipo, y

es un modelo para la construcción de software y sistemas complejos, incluye tres fases que son:

especulación, colaboración y aprendizaje, cada una de estas fases son fundamental para el

desarrollo de la otra. Es adaptativo, se hace uso de la reutilización del código para adaptarlo a

lo que se desea

Modelo de Desarrollo de Sistemas Dinámicos (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 construcción de prototipos increméntales 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 evalúa si la aplicación es viable, para el proceso teniendo en cuenta los requisitos básicos del negocio y sus restricciones asociadas.

Estudio de negocios: establece los requisitos funcionales y de información que permitirán que la aplicación proporcione un valor al negocio; también define la arquitectura básica de la aplicación.

El resto del proceso forma tres ciclos iterativos que son:

Iteración de modelo funcional: produce una serie de prototipos increméntales que demuestran la funcionalidad para el cliente. Su propósito durante este ciclo es recopilar requisitos adicionales y producir documentación de análisis.

Iteración de construcción y diseño: revisa la construcción de prototipos durante la iteración del modelo funcional, en este se diseña el sistema para el uso operacional. En algunos casos, la iteración del modelo funcional y esta, suceden en forma concurrente.

Implementación: coloca el incremento de software más 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 dinámicos tiene como objetivo fundamental la entrega de

sistemas software en tiempo y presupuesto , ajustándose a los cambios de requisitos que

puedan surgir durante el proceso de desarrollo. Para su implementación 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 también basado por la

retroalimentación del usuario, de esa manera logrando converger la solución 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 metodología ágil de gestión de proyectos cuyo objetivo primordial es elevar al máximo la productividad de un equipo, fue desarrollado por Jeff Sutherland y elaborado más formalmente por Ken Schwaber. 11. Se enfoca en el hecho de que procesos definidos y repetibles sólo 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 días. La literatura de Scrum se orienta principalmente en la planeación iterativa y el seguimiento del proceso 12

Caracteristicas:

Enfatiza valores y prácticas de gestión, sin pronunciarse sobre requerimientos, prácticas de desarrollo, implementación y demás cuestiones técnicas.

Hace uso de Equipos auto-dirigidos y auto-organizados Puede ser aplicado teóricamente a cualquier contexto en donde un grupo de gente

necesita trabajar junta para lograr una meta común. Desarrollo de software iterativos incrementales basados en prácticas agiles Iteraciones de treinta días; aunque se pueden realizar con mas frecuencia, estas

iteraciones, conocidas como Sprint Dentro de cada Sprint se denomina el Scrum Master al Líder de Proyecto quien llevará

a cabo la gestión de la iteración Se convocan diariamente un “Scrum Daily Meeting” el cual representa una reunión de

avance diaria de no más de 15 minutos con el propósito de tener realimentación sobre las tareas de los recursos y los obstáculos 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 propósito es establecer la visión, definir expectativas y asegurarse la financiación. Las actividades son la escritura de la visión, el presupuesto, el registro de acumulación o retraso Metodologías Ágiles (backlog) del producto inicial y los ítems estimados, así como la arquitectura de alto nivel, el diseño exploratorio y los prototipos. El registro de acumulación es de alto nivel de abstracción.

2. Pre-Juego / Montaje (Staging): El propósito es identificar más requerimientos y priorizar las tareas para la primera iteración. Las actividades son planificación, diseño exploratorio y prototipos.

3. Juego / Desarrollo: El propósito es implementar un sistema listo para entrega en una serie de iteraciones de treinta días llamadas “corridas” (sprints). Las actividades son un encuentro de planeamiento de corridas en cada iteración, la definición del registro de acumulación de corridas y los estimados, y encuentros diarios de Scrum.

4. Pos-Juego/ Liberación: El propósito es el despliegue operacional. Las actividades, documentación, entrenamiento, mercadeo y venta.

Scrum es una metodología para la gestión 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 también 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 decisión suficiente

para tomar las decisiones que consideren oportunas.

Desarrollo conducido por características (DCC)

El desarrollo conducido por características (DCC) lo concibieron originalmente Peter Coad como un modelo de proceso práctico para la ingeniería 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 tamaño moderado y grande. En el contexto del DCC una característica "es una función evaluada por el cliente que puede implementarse en dos semanas o menos”.13

Beneficios que se le concede a la definición de características:13

Las características se pueden organizar en un agrupamiento jerárquico relacionado con el negocio.

Como las características son bloques pequeños de funcionalidad entregable, los usuarios las describen con mayor facilidad, pueden entender cómo éstas se relacionan con otras con mayor rapidez, y pueden revisarlas de mejor manera en búsqueda de ambigüedades, errores u omisiones.

Una característica es el incremento de software entregable, el equipo desarrolla características operativas cada dos semanas.

Debido a que las características son pequeñas, sus diseños y representaciones de código son más fáciles 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 características 3. Plan por características 4. Diseño por características 5. Construcción por características

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 información básica de las especificaciones funcionales. referencias

La construcción de la lista de características los ensayos, modelos de objetos y documentación de requerimientos proporcionan la base para construir una amplia lista de características . Las funciones se agrupan conforme a diversas actividades en áreas de dominio especificas y la lista de características es revisada por los usuarios para asegurar su validez y exhaustividad

El diseño y la construcción por características, se selecciona las características a desarrollar y los equipos dispuestos por cada una de ellas. Luego se procede iterativamente hasta que se producen las características seleccionadas.

El desarrollo conducido por características es un modelo de proceso práctico para la ingeniería

de software orientada a objetos debido a que las características se pueden organizar en un

grupos relacionado con el negocio, y este busca que el equipo de proyecto desarrolle las

características 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 más

hacia la parte de la dirección y gestión de proyectos

Proceso Unificado de Rational (RUP)

El Proceso Unificado de Rational es una metodología de desarrollo de software orientada a objetos creada por Rational Software Corporation.

Es una de las metodologías más extendidas y conocidas por su amplia difusión comercial. Se puede estudiar como una metodología representativa de tipo clásico. Fue definido por los creadores del UML unificando los métodos de Ivar Jacobson, Grady Booch y James Rumbaugh. El hecho de que la empresa RATIONAL también distribuya herramientas específicas basadas en el mismo método, que facilitan el desarrollo, ha contribuido a su gran expansión. 16

Este proceso se maneja por casos de uso (correspondientes a los modos uso por los actores o agentes usuarios) para la extracción de requisitos y la identificación de las partes funcionales en las que se divide la solución. La arquitectura del proceso se modela con orientación a objetos.

Estos metodologistas, fueron reunidos por Rational para formar un marco de metodologías unificadas, cohesivas y comprehensivas de desarrollo de sistemas de software. Su trabajo, que producen durante varios años y basados en metodologías probadas, han dado a lugar a importantes normas en la comunidad de desarrollo,

Como toda metodología de desarrollo software su finalidad es convertir las especificaciones que da el cliente en un sistema software. Las características que tiene el RUP. son:

Está basado en componentes. Estos componentes a su vez están conectados entre sí a través de interfaces.

Utiliza el UML como notación básica.

Dirigido por casos de uso. El proceso utiliza Casos de Uso para manejar el proceso de desarrollo desde la Incepción hasta el Despliegue.

Centrado en la arquitectura. El proceso busca entender los aspectos estáticos y dinámicos más significativos en términos de arquitectura de software. La arquitectura se define en función 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 práctico dividir grandes proyectos en proyectos más pequeños o mini-proyectos. Cada mini-proyecto comprende una iteración que resulta en un incremento. Una iteración 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: Incepción, Elaboración, Construcción y Transición. Un ciclo concluye con una liberación, tambien hay versiones dentro de un ciclo.

Esta es una descripción breve de las fases de un ciclo:

Fase de Incepción: Durante la fase inicial se concibe la idea central del producto, se arma el documento de visión. 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 incepción establece la viabilidad del producto y delimita el alcance del proyecto.

Se describe el producto final. Se responde a las preguntas:

¿Cuáles son las principales funciones del sistema para sus usuarios más importantes?. La respuesta está en el modelo de casos de uso simplificado.

¿Cómo podría ser la arquitectura del sistema?

¿Cuál es el plan del proyecto y cuánto costará desarrollar el producto?

Fase de Elaboración: Durante la fase de elaboración la mayoría de los Casos de Uso son especificados en detalle y la arquitectura del sistema es diseñada. 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 Construcción: Durante la fase de construcción, 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 diseña para llevarlo a código 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 Transición: En la fase de transición el objetivos es garantizar que los requisitos se han cumplido, con la satisfacción de las partes interesadas. Esta fase a menudo se inicia con una versión beta de la aplicación. Otras actividades incluyen la preparación del ambiente, se completan, se identifican y corrigen defectos. La fase de transición termina con un cierre dedicado al aprendizaje de lecciones, las cuales quedan para futuros ciclos.El producto existe en versión Beta.

La metodología de RUP es una forma disciplinada de asignar tareas y responsabilidades en una

empresa de desarrollo (quién hace qué, cuándo y cómo), 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

implementación se hace a través 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 diseño, así como también el cliente interactúa con el equipo de desarrollo

mediante reunionesa diferencia de la metodología XP que el cliente es parte del equipo

Diferencias entre los modelos de proceso convencionales y ágiles

Metodologías ágiles:

Están basadas en heurística provenientes de prácticas de producción de códigos.

Están 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 pequeños y trabajando en el mismo sitio.

Menos énfasis en la arquitectura del software.

Metodologías convencionales:

Basadas en normas provenientes de estándares.

Presentan cierta resistencia a los cambios.

Impuestas externamente.

Proceso mucho mas controlado, con numerosas políticas.

Existe un contrato prefijado.

Son un poco rígidas.

El cliente interactúa con el equipo de desarrollo mediante reuniones.

Grupos grandes y posiblemente distribuidos.

La arquitectura del software es esencial y se expresa mediante modelos.

Clasificación de las metodologías según su enfoque

Metodologías estructuradas

Se basan en la forma top-down. Entre estas están:

Metodologías orientadas a procesos

Se basan en la utilización de un método descendente de descomposición funcional para definir los requisitos del sistema, dan lugar a un nuevo concepto "la especificación estructurada" que es un modelo gráfico particionado, descendente y jerárquico de los procesos del sistema.

La metodología 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 abstracción 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 metodologías orientadas a procesos comprende una fase de análisis estructurado y los métodos de DeMarco, Gene y Sarson, Yourdon, son algunos que permiten lograr esto.

Metodología de Demarco: se basa en el estudio del sistema físico actual, derivación del modelo lógico actual, derivación al nuevo modelo lógico y creación de modelos físicos alternativos.

Metodología 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 lógico del sistema. También construye un modelo lógico de datos.

Metodología de Yourdon: Realiza los DFDs del sistema, a partir de los DFD realiza el diagrama de estructuras, evaluación del diseño y preparación del diseño.

Metodologías orientadas a datos

Son metodologías basadas en la información, ya que los datos son más estables que los procesos. Primero se definen las estructuras de datos y, a partir de éstos, se derivan los componentes procedimentales.

Ejemplos de esta clasificación son: metodologías de Jackson, Warnier, Warnier-Orr.

Estas metodologías se dividen en jerárquicas y no jerárquicas:

Metodología orientada a datos jerárquicas:

La estructura de control del programa debe ser jerárquica y se debe derivar de la estructura de datos del programa.

El proceso de diseño consiste en definir primero las estructuras de los datos de entrada y salida, mezclarlas todas en una estructura jerárquica de programa y después ordenar detalladamente la lógica procedimental para que se ajuste a esta estructura.

El diseño lógico debe preceder y estar separado del diseño físico.

Metodología orientada a datos no jerárquicas:

Metodología Ingeniería de la Información.

Planificación: construir una arquitectura de la Información y una estrategia que soporte los objetivos de la organización .

Análisis: comprender las áreas del negocio y determinar los requisitos del sistema.

Diseño: establecer el comportamiento del sistema deseado por el usuario y que sea alcanzable por la tecnología.

Construcción: construir sistemas que cumplan los tres niveles anteriores.

Las metodologías estructuradas están orientadas a procesos y a objetos. Intentan aplicar

ingeniería para solucionar problemas técnicos de un sistema de información, proponen la

creación de modelos, flujos y estructuras mediante un top-down. La metodología orientada a

procesos está fundamentada en el modelo entrada-proceso-salida., aplica un proceso

interactivo para lograr un refinamiento progresivo. La metodología orientada a objetos se

divide en jerárquica y no jerárquica, la jerárquica está orientada a las entradas y salidas, las no

jerárquicas definen un sistema a partir de la información que este maneja.

Metodologías para sistemas de tiempo real

Las metodologías en tiempo real procesan información orientada al control más que a los datos.

Se caracterizan por:

Concurrencia. Priorización de procesos. Comunicación y sincronización entre tareas. Acceso simultáneo a datos comunes. Permiten el manejo de interrupciones. Gestión de procesos concurrentes Respuesta oportuna ante eventos externos. Datos continuos o discretos.

Metodologías Orientadas a Objetos

La orientación a objetos unifica procesos y datos encapsulándolos en el concepto de objetos. La esencia del desarrollo orientado a objetos es la identificación y organización de conceptos del dominio de la aplicación y no tanto de su representación final en un lenguaje de programación.

Tiene dos enfoques distintos:

Revolucionario, puro u ortodoxo: Rompen con las metodologías tradicionales. La Orientación a objetos se entiende como un cambio profundo de las metodologías estructuradas que se ven como obsoletas. Ejemplos: metodologías OOD de Booch, CRC/RDD de Wirfs-Brock.

Sintetista o evolutivo:El análisis y diseño estructurado se considera como la base para el desarrollo Orientado a objetos.

Ventajas de las metodologías orientadas a objetos:

Reutilización. Las clases están diseñadas para que se reutilicen en muchos sistemas. Para maximizar la reutilización, las clases se construyen de manera que se puedan

adaptar a los otros sistemas. Un objetivo fundamental de las técnicas orientadas a objetos es lograr la reutilización masiva al construir el software.

Estabilidad. Las clases diseñadas para una reutilización repetida se vuelven estables, de la misma manera que los microprocesadores y otros chips se hacen estables.

El diseñador piensa en términos del comportamiento de objetos y no en detalles de bajo nivel. El encapsulamiento oculta los detalles y hace que las clases complejas sean fáciles de utilizar.

Se construyen clases cada vez más 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 construcción de software más complejo.

Calidad. Los diseños suelen tener mayor calidad, puesto que se integran a partir de componentes probados, que han sido verificados y pulidos varias veces.

Un diseño más rápido. Las aplicaciones se crean a partir de componentes ya existentes. Muchos de los componentes están construidos de modo que se pueden adaptar para un diseño particular.

Integridad. Las estructuras de datos (los objetos) sólo se pueden utilizar con métodos específicos. Esto tiene particular importancia en los sistemas cliente-servidor y los sistemas distribuidos, en los que usuarios desconocidos podrían intentar el acceso al sistema.

Mantenimiento más sencillo. El programador encargado del mantenimiento cambia un método de clase a la vez. Cada clase efectúa sus funciones independientemente de las demás.

Una interfaz de pantalla sugestiva para el usuario. Hay que utilizar una interfaz de usuario gráfica 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 más fácil que recordar y escribir.

Independencia del diseño. Las clases están diseñadas para ser independientes del ambiente de plataformas, hardware y software. Utilizan solicitudes y respuestas con formato estándar. Esto les permite ser utilizadas en múltiples sistemas operativos, controladores de bases de datos, controladores de red, interfaces de usuario gráficas, etc. El creador del software no tiene que preocuparse por el ambiente o esperar a que éste se especifique.

Interacción. El software de varios proveedores puede funcionar como conjunto. Un proveedor utiliza clases de otros. Existe una forma estándar 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.

Computación 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 sólo pueden tener acceso a los datos del servidor a través de los métodos de la clase. Por lo tanto los datos están protegidos contra su corrupción.

Computación de distribución masiva. Las redes a nivel mundial utilizarán directorios de software de objetos accesibles. El diseño orientado a objetos es la clave para la computación de distribución masiva. Las clases de una máquina interactúan con las de algún otro lugar sin saber donde residen tales clases. Ellas reciben y envían mensajes orientados a objetos en formato estándar.

Mayor nivel de automatización de las bases de datos. Las estructuras de datos (los objetos) en las bases de datos orientadas a objetos están ligadas a métodos que llevan a cabo acciones automáticas. Una base de datos OO tiene integrada una inteligencia, en forma de métodos, en tanto que una base de datos relacional básica carece de ello.

Las metodologías orientadas a objetos han evolucionado para ayudar a los desarrolladores a

explotar el poder de los lenguajes de programación basados en objetos y orientados a objetos,

utilizando las clases y objetos como bloques de construcción básicos. Una orientación a objetos

nos ayuda a hacer frente a la inherente complejidad de muchos tipos de sistemas.

¿Que metodología es conveniente usar?Tener metodologías diferentes para aplicar de acuerdo con el proyecto que se desarrolle resulta una idea interesante. Estas metodologías pueden involucrar prácticas tanto de metodologías ágiles como de metodologías tradicionales. De esta manera podríamos tener una metodología para cada proyecto, la problemática sería definir cada una de las prácticas, y en el momento preciso definir parámetros para saber cual usar.Es importante tener en cuenta que el uso de un método ágil no es para todos. Sin embargo, una de las principales ventajas de los métodos ágiles es su peso inicialmente ligero y por eso las personas que no estén acostumbradas a seguir procesos encuentran estas metodologías bastante agradables. Por otro lado, las metodologías tradicionales o convencionales permiten crear software de manera mas segura ya que estas entan mas establecidas según 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 colección 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. Además, estos procesos se hallan sujetos a un conjunto de reglas de negocio, que determinan las políticas y la estructura de la información 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 organización.

Los objetivos específicos del modelado de negocio son:

1. Asegurar que clientes, usuarios finales y desarrolladores tengan un entendimiento común de la organización objetivo.

2. Derivar los requerimientos del sistema necesarios para apoyar a la organización objetivo en su mejora.

3. Entender el problema actual en la organización objetivo e identificar potenciales mejoras.

4. Entender la estructura y la dinámica de la organización para la cual el sistema va a ser desarrollado (organización objetivo).

Para lograr estos objetivos, el modelado de negocio describe como desarrollar una visión de la nueva organización, basado en esta visión se definen procesos, roles y responsabilidades de la organización por medio de un Modelo de Casos de Uso del Negocio. Los artefactos del modelo de negocio sirven como entrada y referencia para la definición 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 podrán identificarse las necesidades inmediatas de mejora y continuidad relativa a las actividades relacionadas con los sistemas informáticos, que son el producto final del desarrollo.

Orientación del modelado de negocio.

Dominios principales en los que se emplea:

Dominios orientados al negocio

Gerencia

Teoría de Organizaciones

E-business, E-commerce

Dominios orientados a la tecnología

Sistemas de Información

Ingeniería de Software

Informática Industrial

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

Orientado al valor/cliente

Busca explicar cómo 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 lógica 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 abstracción de cómo una empresa funciona… proporciona una vista simplificada de la estructura del negocio que actúa como la base para la comunicación, mejoras o innovación y define los requisitos de los sistemas de información que intervienen en la empresa ” Erikson y Peker (2000).

Un Modelado del Negocio es una descripción de los elementos que constituyen una

organización, o una parte de ella, así como de las relaciones entre estos elementos. Un Modelo

del Negocio es una conceptualización de una empresa u organización, es la caracterización de

los aspectos más significativos de la empresa o de una parte de ella, para ello se debe tener

claro cuál 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 Ingeniería de Requisitos

El Modelado de Negocios y la Ingeniería de Requisitos son los dos procesos técnicos 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 aplicación con la finalidad de formular y analizar el problema que da origen a la aplicación. La Ingeniería de Requisitos, por su parte, ocurre en el espacio de la solución; se encarga, por lo tanto, de caracterizar la aplicación en base a las necesidades y los requisitos que los usuarios de la aplicación tienen.

El proceso de ingeniería de requerimientos se utiliza para definir todas las actividades involucradas en el descubrimiento, documentación 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 obtención y análisis de requerimientos, su especificación formal, para finalizar con el subproceso de validación donde se verifica que los requerimientos realmente definen el sistema que quiere el cliente.

En el desarrollo de software, el Modelado de Negocios aporta información esencial para la

Ingeniería de Requisitos, ya que en el modelado de negocio se ve lo que es el problema y en la

ingeniería de requisitos se define la solución al problema.

Cadena de Valor

La cadena de valor es esencialmente una forma de análisis 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 separación entre las actividades de mayor interés (actividades primarias) y las actividades que le sirven de apoyo con la finalidad de prestar mayor atención 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 creación física del producto, las actividades relacionadas con su venta y la asistencia post-venta.

Se dividen en:

•Logística interna

•Operaciones

•Logística 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, están conformadas por:

• Infraestructura de la organización

• Dirección de recursos humanos: búsqueda, contratación y motivación del personal.

• Desarrollo de tecnología (investigación 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 también la de sus competidores, ya que esta proporciona un mejor

análisis interno de la organización, así como también identificar las ventajas competitivas y

comprender de una mejor manera el comportamiento de los costos y las diversas fuentes de

diferenciación con la competencia.

Conclusiones Una metodología se basa en una combinación de los modelos de proceso genéricos

para obtener como beneficio un software que soluciones un problema

La trascendencia de las metodologías se ha hecho notoria, pasando de solo programar, establecer funciones en etapas o módulos, 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 ejecución secuencial de instrucciones

En el desarrollo estructurado los programas están 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 interacción.

El desarrollo orientado a objetos comprende dividir un programa en clases, donde estas clases estarán estructuradas por propiedades, atributos, variables, pretendiendo simular y describir de manera conceptual a un objeto.

Los métodos ágiles fueron pensados especialmente para equipos de desarrollo pequeños, con plazos reducidos, requisitos volátiles y nuevas tecnologías.

El modelado de negocio describe como desarrollar una visión de la nueva organización, basado en esta visión se definen procesos, roles y responsabilidades de la organización 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, además que existen muchos modelos que se adaptan a las exigencias del proyecto, solo debemos saber cual nos conviene.

Referencias 1. Alonso, F. y Martínez, L. (2005). Introducción a la ingeniería del software: modelos de desarrollo de programas (primera edición). España: Delta Publicaciones. Pág. 75-76

2. Sommerville, I. (2005). Ingeniería del software (Séptima Edición). España: Pearson Educación.

3. Hernán, M. (2004). Diseño de una Metodología Ágil de Desarrollo de Software. Tesis de Grado de Ingeniería en Informática. Universidad de Buenos Aires. Pág. 11-12

4. Sommerville, I. (2006). Ingeniería del software (Séptima Edición). Madrid. Pág. 62

5. Espinoza, A. Metodologías de desarrollo de software [documento en línea].Disponible en: « www.slideshare.net/juliopari/4-clase-metodologia-de-desarrolo-de-software » [consulta: 11 de junio de 2012]

6. Carballar, D. Ingeniería de software [documento en línea]. « www.eduinnova.es/dic09/Ingenieria_Software.pdf » [consulta: 10 de junio de 2012]

7.Disponible en la web: « www.angelfire.com/scifi/jzavalar/apuntes/IngSoftware.html#paradigmaOO » [consulta: 10 de junio de 2012]

8. Kenneth, E. y Kendall, J. (2005). Analisis Y Diseño de Sistemas(Sexta edición). México.

9. Solís, M. (2003). Una explicación de la programación extrema (XP). Madrid. Pág. 103

10. Ordonez (2011). Metodo de Desarrollo de sistemas dinamicos[documento en línea]. Disponible en:« www.slideshare.net/oscarfico/metodos-dinamicos » [consulta: 8 de junio de 2012]

11. Citón, M.(2006). Método ágil scrum aplicado al desarrollo de un software de trazabilidad. Argentina.

12. Amaro , S. y Valverde, J. (2007). Metodologías Ágiles. Perú:Trujillo.

13. Mendez, E. (2006). Modelo de Evaluacion de Metodologia para el Desarrollo de Software. Trabajo de Grado, Universidad Católica Andrés Bello,Caracas,Vzla.

14. Canós J. y Letelier P. (2003, noviembre). Metodologías ágiles en el desarrollo de software [resumen]. Taller realizado en el marco de las VIII jornadas de Ingeniería del software y bases de datos en la Universidad politécnica de Valencia, España-Alicante.

15. Laboratorio Nacional de Calidad del Software de INTECO. (2009, Marzo) Ingeniería del software: metodologías y ciclos de vida. España.

16. Oscar Álvarez Imaz. (2008, Abril). "Introducción a RUP" Versión 0.1

17. Alonso, F. y Martínez, L. (2005). Introducción a la ingeniería del software: modelos de desarrollo de programas (primera edición). España: Delta Publicaciones. Pág. 112-113

18. Disponible en la web: « www.laprole431.blogspot.com/2010/12/que-es-un-modelo-de-desarrollo.html » [consulta: 6 de julio de 2012]

19. Disponible en la web: « www.ingenieraupoliana.blogspot.com/2010/10/modelo-de-desarrollo-concurrente.html » [consulta: 6 de julio de 2012]

20. David, F. (2008). Conceptos de Administration Estratégica (Decimoprimera Edición). Editorial Pearson Educación, México.

21. Disponible en la web:

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

de 2012]

ANÁLISIS Y DETERMINACIÓN DE REQUERIMIENTOS

 

Herramientas para determinar requerimientos de sistemas

 

La determinación de requerimientos es el estudio de un sistema para conocer como trabaja y donde es necesario efectuar mejoras, dando como resultado una evaluación de la forma como trabajan los métodos empleados y si es necesario o posible realizar ajustes.

Un requerimiento es una característica que debe incluirse en un nuevo sistema. Esta puede ser la inclusión de determinada forma para capturar o procesar datos, producir información, controlar una actividad de la empresa o brindar soporte a la gerencia. Es así como la determinación de requerimientos vincula el estudio de un sistema existente con la recopilación de detalles relacionados con él.

 

Actividades de la determinación de requerimientos

Es útil ver la determinación de requerimientos a través de tres grandes actividades:

Anticipación de requerimientos: La experiencia de los analistas les permite anticipar ciertos problemas o características y requerimientos para un nuevo sistema.

Por un lado, la experiencia de estudios previos puede conducir a la investigación de áreas que no consideraría un analista novato. Tener las bases necesarias para saber que preguntar o que aspectos investigar puede ser de beneficio substancial para la organización.

Por otra parte, si se introducen sesgos o atajos al conducir la investigación entonces es muy probable que la anticipación de requerimientos se convierta en un problema. Por lo tanto, siempre deben darse lineamientos para estructurar una investigación alrededor de cuestiones básicas con la finalidad de evitar consecuencias indeseables de la anticipación de requerimientos.

 

Investigación de requerimientos: Es la más importante del análisis de sistemas. Los analistas estudian el sistema actual con la ayuda de varias herramientas y habilidades, y documentan características para, mas adelante, emprender el análisis.

La investigación de requerimientos depende de las técnicas para encontrar datos, que serán explicadas mas adelante, e incluyen los métodos para documentar y describir las características de l sistema.

 

Especificaciones de requerimientos: Los datos obtenidos durante la recopilación de hechos se analizan para determinar las especificaciones de los requerimientos, es decir, la descripción de las características del nuevo sistema. Esta actividad tiene tres partes relacionadas entre sí:

 

-         Análisis de datos basados en hechos reales: Se examinan los datos recopilados durante el estudio, incluidos en la documentación de flujo de datos y análisis de decisiones, para examinar el grado de desempeño del sistema y si cumple con las demandas de la organización.

-         Identificación de requerimientos esenciales: Características que deben incluirse en el nuevo sistema y que van desde detalles e operación hasta criterios de desempeño.

-         Selección de estrategias para satisfacer los requerimientos: Métodos que serán utilizados para alcanzar los requerimientos establecidos  seleccionados. Estos forman la base para el diseño de sistemas, los cuales deben cumplir con la especificación de requerimientos.

 

La especificación 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 características del nuevo sistema.

 

Requerimientos básicos

Los analistas estructuran su investigación al buscar respuestas a las siguientes cuatro importantes preguntas:

¿Cuál es el proceso básico de la empresa?

¿Qué datos utiliza o produce esta empresa?

¿Cuáles son los limites impuestos por el tiempo y la carga de trabajo?

¿Qué controles de desempeño utiliza?

 

Comprensión 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 comprensión necesaria:

 

¿Cual es la finalidad de esta actividad dentro de la empresa? ¿Qué pasos se siguen para llevarla a cabo? ¿Dónde se realizan estos pasos? ¿Quiénes lo realizan? ¿Cuánto tiempo tardan n efectuarlos? ¿Con cuanta frecuencia lo hacen? ¿Quiénes emplean la información resultante?

 

Identificación de los datos empleados e información 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 mercancía.

Por otra parte, muchas transacciones comerciales producen información útil para los gerentes cuando estos evalúan el desempeño de empleados, negocios y sistemas; esta información también 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 también proporcionan información con respecto a demandas del almacén, 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 año 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 información puede llevar al analista a considerar mas preguntas importantes para determinar la razón de esta frecuencia y su efecto sobre las actividades de la empresa.

 

Muchas veces la forma más fácil de obtener esta información es identificar el objetivo de la actividad: ¿Cuál es la causa de la actividad? En ocasiones los analistas se refieren a la causa directa como la función de iniciación. 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 razón 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.

 

Identificación de controles

En situaciones donde se  ejerce buen control ya sea por parte de la gerencia o por el seguimiento del proceso, quizás no sea problema determinar si una actividad se ha llevado a cabo en forma adecuada. Aun así, los analistas deben examinar los métodos de control durante la etapa de análisis: ¿existen estándares específicos de desempeño?, ¿quién se encarga de comparar el desempeño contra los estándares?, ¿cómo se detectan los errores?, ¿cómo se corrigen los errores?, ¿se cometen demasiados errores?. La falta o debilidad de los controles es un descubrimiento importante en cualquier investigación de sistemas.

 

Requerimientos de las transacciones de los usuarios

Los sistemas a nivel de transacciones, capturan, procesan y almacenan datos por alguna razón. Por ejemplo, en un sistema de pedidos, los pedidos de los clientes son procesados de forma tal quesea posible enviar los artículos 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 transacción que esta siendo procesada? ¿Qué es lo que inicia la transacción? ¿Quién inicia los pedidos? ¿Con que propósito? ¿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 transacción? ¿Qué información se genera? ¿Qué datos se guardan?

 

Requerimientos de decisión de los usuarios

A diferencia de las actividades de transacción, 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 información en forma tal que los gerentes puedan saber que acciones emprender. Es probable que los sistemas de decisión 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 también deben hacer otras para determinar los requerimientos de las decisiones:

 

1-     ¿Qué información se utiliza para tomar la decisión?

2-     ¿Cuál es la fuente de información? ¿Qué sistemas de transacciones producen los datos en el proceso de decisión? ¿Qué otros datos son necesarios y no es posible obtener del procesamiento de transacciones? ¿Qué datos se originan en fuentes externas a la organización?

3-     ¿Cómo se deben procesar los datos para producir la información necesaria?

4-     ¿Cómo debe plantearse la información?

 

Estas preguntas también señalan la relación entre los sistemas de transacciones y los de decisiones. Información muy valiosa puede perderse si los sistemas de transacciones no capturan y guardan los datos necesarios para las decisiones. Los sistemas de inventario capturan información relacionada con los continuos pedidos, recepciones,  ventas y envió de artículos. Los datos que estos sistemas almacenan son procesados nuevamente para generar información de manera periódica para analizar ventas, determinar políticas de procesos  o decidir planes de mercadotecnia para líneas 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 organización

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 también deben evaluar las implicaciones para los demás departamentos con los que interactúa el sistema bajo investigación. 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 deberían manejarse las excepciones. Claro esta que una aplicación debe diseñarse 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 excepción al procedimiento? ¿Todos los empleados siguen el mismo procedimiento?

 

TÉCNICAS PARA ENCONTRAR HECHOS

 Los analistas utilizan métodos específicos, denominados técnicas para encontrar hechos, con el objeto de reunir datos relacionados con los requerimientos. Entre estos se incluyen la entrevista, el cuestionario, la revisión de los registros  y la observación. En general, los analistas emplean mas de una de estas técnicas para llevar a cabo una investigación amplia y exacta.

 

Entrevistas:

Los analistas emplean la entrevista para reunir información proveniente de personas o de grupos. Por lo común, 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 serán afectados por el. Aunque algunos analistas prefieren la entrevista sobre otras técnicas, esta no siempre es la mejor fuente de datos sobre la aplicación. Dado que la entrevista lleva tiempo, es necesario utilizar otros métodos para obtener la información necesaria para conducir una investigación.

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 información general del sistema. Este formato anima a los entrevistados a compartir sus sentimientos, ideas y creencias. Por otro lado, las entrevistas estructuradas utilizan preguntas estándar 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 información 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 técnicas; por otra parte, su amplia distribución asegura el anonimato de los encuestados, situación que puede conducir a respuestas mas honestas. Sin embargo, este método 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.

 

Revisión de los registros

Varios tipos de registros y reportes pueden proporcionar al analista información valiosa con respecto a las organizaciones y a sus operaciones. Al revisar los registros, el analista examina la información asentada en ellos relacionada con el sistema y los usuarios. La revisión de los registros puede efectuarse al comienzo del estudio, como introducción, o también después, y sirve de base para completar las operaciones actuales. Por lo tanto los registros pueden indicar que esta sucediendo.

Los registros incluyen manuales de políticas, reglamentos y procedimientos estándares de operación utilizados por la mayor parte de las organizaciones como guías 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 afán de comprender el sistema al familiarizarlo con aquellas operaciones que necesitan apoyo con las relaciones formales dentro de la organización.

 

Observación

La observación permite al analista ganar información que no se puede obtener por otras técnicas. Por medio de la observación el analista obtiene información de primera mano sobre la forma en que se efectúan las actividades. El método 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 PARA DOCUMENTAR PROCEDIMIENTOS Y DECISIONES

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 investigación de sistemas dentro de la empresa.

Las herramientas ayudan al analista a integrar los datos recopilados por los diversos métodos 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 decisión, tablas de decisión y español estructurado.

 

Conceptos básicos 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 decisión

Cuando se observa un sistema y se pregunta ¿cuáles 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 decisión.

Al documentar la decisión de cómo procesar un procedimiento, el investigador debe identificar tanto las condiciones permisibles como las relevantes que pueden presentarse en determinada situación. 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 tamaño 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 decisión, tablas de decisión y el español estructurado.

 

Árboles de decisión

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

 

Características de los árboles de decisión

El árbol de decisión 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 método también permite mostrar la relación que existe entre cada condición y el grupo de acciones permisibles asociado con ella.

La raíz del árbol es el punto donde comienza la secuencia de decisión. La rama a seguir depende de las condiciones existentes y de la decisión que debe tomarse. Al avanzar de izquierda a derecha por una rama en particular, se obtiene una serie de toma de decisiones. Después de cada punto de decisión, se encuentra el siguiente conjunto de decisiones a considerar. De esta forma, los nodos del árbol representan condiciones y señalan la necesidad de tomar una determinación 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 decisión

El desarrollo de árboles de decisión 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 difícil para ellos pasar por alto cualquier etapa del proceso de decisión, sin importar que este dependa de variables cualitativas o cuantitativas.

Los árboles de decisión también obligan a los analistas a considerar la secuencia de las decisiones.

 

Identificación de los requerimientos de datos

Los árboles de decisión también son útiles para identificar los requerimientos de datos críticos que rodean al proceso de decisión; 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 después de completar el análisis de flujo de datos, entonces es posible que los datos críticos se encuentren ya definidos en el diccionario de datos. Si únicamente se utilizan árboles de decisión, entonces el analista debe tener la certeza de identificar con precisión cada dato necesario para tomar la decisión.

Los analistas necesitan describir y definir todos los datos utilizados en la toma de decisiones para que sea posible diseñar el sistema de forma tal que los genere apropiadamente.

 

Como evitar los problemas que se generan al utilizar árboles de decisión

Los árboles de decisión no siempre son la mejor herramienta para el análisis de decisiones. El árbol de decisión de un sistema complejo con muchas secuencias de pasos y combinaciones de condiciones puede tener un tamaño considerable. El gran numero de ramas que pertenecen a varias trayectorias constituye mas un problema que una ayuda para el análisis. En estos casos el analista corre el riesgo de no determinar que políticas o estrategias de la empresa son la guía para la toma de decisiones especificas.

 

Tablas de decisión

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

 

Características de las tablas de decisión

La taba de decisión esta integrada por cuatro secciones: identificación de condiciones, entradas de condiciones, identificación de acciones y entradas de acciones.  La identificación de condiciones señala aquellas que son relevantes. Las entradas de condiciones indican que valor, si es que lo hay, se debe asociar para una determinada condición. La identificación de acciones enlista el conjunto de todos los pasos que se deben seguir cuando se presenta cierta condición. 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 añaden notas en la parte inferior de la tabla para indicar cuando utilizar la tabla o para diferenciarla de otras tablas de decisión.

Las columnas del lado derecho de la tabla enlazan condiciones y acciones, forman reglas de decisión que establecen condiciones que deben satisfacerse para emprender un determinado conjunto de acciones. La regla de decisión incorpora todas las condiciones que deben ser ciertas y no solo una a la vez.

 

Como construir tablas de decisión

Para desarrollar tablas de decisión, los analistas deben emprender los siguientes pasos:

 

1-     Determinar los factores determinados como más relevantes en la toma de decisiones. Esto permite identificar las condiciones en la decisión. Cada condición seleccionada debe tener la característica de ocurrir o no ocurrir; en este caso no es posible la ocurrencia parcial.

2-     Determinar los pasos o actividades más 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 decisión. Existen dos formas para hacerlo.

La primera, y más larga, es llenar los renglones de condición con valores si o no para cada combinación posible de condiciones. Esto es, llenar la primera mitad del renglón con Si y la segunda con No. El siguiente renglón se llena alternando con  S y N cada 25% del renglón; es decir, 25% Si, 25% No, 25% Si y 25% No. Se repite de nuevo este

proceso: se llena ada renglón faltante en forma alterna con S y con N, dividiendo cada vez por potencias sucesivas de 2.

El otro método para llenar la tabla considera una condición a la vez y, por cada condición adicional le añade una tabla pero sin considerar las combinaciones de condiciones y acciones duplicadas.

 

Verificación de tablas de decisión

Después 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 decisión que las relacionan con las acciones. Asimismo, los analistas también deben examinar la tabla para encontrar redundancias y contradicciones.

Eliminación de la redundancia: Las tablas de decisión pueden volverse muy grandes y difíciles de manejar si se permite que crezcan sin ningún control. Remover las entradas redundantes puede ser de ayuda para manejar el tamaño de la tabla. La redundancia se presenta cuando las siguientes condiciones son verdaderas al mismo tiempo: 1) dos reglas de decisión son idénticas salvo para una condición del renglón y 2) las acciones para las dos reglas son idénticas.

Supresión de contradicciones: las reglas de decisión son contradictorias entre si cuando dos o más reglas tienen el mismo conjunto de contradicciones pero sus acciones  son diferentes.

Las contradicciones indican que la información que tiene el analista es incorrecta o bien existe un error  en la construcción de la tabla. Sin embargo, muchas veces la contradicción es resultado de las dependencias en la información que recibe el analista de diferentes personas con respecto a la forma en que estas toman decisiones. Se puede tomar una decisión especifica utilizando diferentes reglas. Encontrar tales discrepancias puede ser de gran utilidad para el analista que trabaja con la finalidad de mejorar una situación de decisión.

 

Tipos de entradas en una tabla

Forma de entrada limitada: La estructura básica 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 también 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 condición y acción no están completos y es la razón 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 características de los dos métodos anteriores. En general, debe utilizarse solo

una forma en cada sección 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 decisión que tiene como finalidad omitir la repetición por medio de reglas ELSE . Para construir una tabla de decisión en la forma ELSE, se especifican las reglas, junto con las entradas de condiciones, que cubren todo el conjunto de acciones con excepción de una que se convierte en la regla a seguir cando ninguna de las demás 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 decisión ELSE. Esta regla elimina la necesidad de repetir condiciones que conducen a las mismas acciones.

 

Tablas múltiples

La forma ELSE es una alternativa para controlar el tamaño de las tablas de decisión. Otra manera de hacer esto es enlazando varias tablas de decisión. De acuerdo con las acciones seleccionadas en la primera tabla, otras se explican en una o más tablas adicionales; cada tabla proporciona mayores detalles relacionados con las acciones a emprender. Por otra parte, las tablas múltiples permiten al analista establecer las acciones repetitivas que deben realizarse después de tomar las decisiones y que continúan hasta que se alcanza determinada condición.

Para utilizar este método los analistas construyen, por separado, tablas de decisión que satisfacen todos los requerimientos normales y que están relacionadas con una decisión especifica. Las tablas de enlazan en forma jerárquica: 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 proposición “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 proposición “PERFORM tabla 2”. Al final de la tabla 2 la proposición RETURN regresa de nuevo el control a la proposición que sigue al GO TO en la tabla 1.

 

Procesadores de tablas de decisión

Las tablas de decisión han sido parcialmente automatizadas. Los procesadores de tablas de decisión son programas para computadora que manejan la formulación actual de una tabla con base en la información de entrada proporcionada por el analista. Estos

procesadores también emprenden todas las verificaciones necesarias para detectar inconsistencias y redundancias.

La utilidad de los procesadores de tablas de decisión radica en el ahorro de tiempo de programación y detección de errores.

 

Español estructurado

El español estructurado es otro método para evitar los problemas de ambigüedad del lenguaje al establecer condiciones y acciones, tanto en procedimientos como en decisiones. Este método no hace uso de árboles o tablas; en su lugar utiliza declaraciones para describir el proceso. El proceso no muestra reglas de decisión; las declara.

Aun con esta característica, las especificaciones en español 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 método también permite hacer una lista de todos los pasos en el orden que se llevan a cabo. Para ello no se utilizan símbolos y formatos especiales, características de los árboles y las tablas de decisión que par algunos resultan incómodos. Además, es posible describir con rapidez los procedimientos en su totalidad ya que para ello de emplean declaraciones muy similares al español.

La terminología utilizada en la descripción estructurada de una aplicación consiste, en gran medida, en nombres de datos para los elementos que están definidos en el diccionario de datos desarrollado para el proyecto.

 

Desarrollo de declaraciones estructuradas

El español estructurado emplea tres tipos básicos de declaraciones para describir un proceso: estructuras de secuencia, estructuras de decisión y estructuras de iteración.

Estructuras de secuencia: Una estructura de secuencia es un solo paso o acción incluido en un proceso. Este no depende de la existencia de ninguna condición y, cuando se encuentra, siempre se lleva a cabo. En general, se emplean varias instrucciones en secuencia para describir un proceso.

Estructuras de decisión: El español estructurado es otro camino para mostrar el análisis de decisión. Por tanto, a menudo se incluyen las secuencias de acciones dentro de estructuras de decisión que sirven para identificar condiciones. Es así como las estructuras de decisión aparecen cuando se pueden emprender dos o más acciones, lo que depende del valor de una condición especifica. Para esto primero se evalúa la condición y después se toma la decisión de emprender las acciones o el grupo de acciones asociados con esta condición. Una vez determinada la condición las acciones son incondicionales.

Estructuras de iteración: En las actividades rutinarias de operación, es común encontrar que algunas de ellas se repiten mientras existen ciertas condiciones o hasta que estas se presentan. Las instrucciones de iteración permiten al analista describir estos casos.

 

Beneficios del español estructurado

Como puede observarse, el español 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 español estructurado para declarar las reglas de decisión que se aplican en este medio. Si los analistas no pueden declarar que acción emprender cuando se toma una decisión, entonces necesitan adquirir mayor información para descubrir la situación. Por otro lado, después de describir las actividades en forma estructurada, los analistas pueden pedir a otras personas que revisen la descripción y determinen con rapidez los errores u omisiones cometidos al establecer los procesos de decisión.

 

ANÁLISIS ESTRUCTURADO

Cuando los analistas comienzan a trabajar sobre un proyecto de sistemas de información, a profundo tienden a profundizar en un área de la organización 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 organización como

resultado del crecimiento, del aumento de la competencia en el mercado, de los cambios en las necesidades de los consumidores, de la evolución de las estructuras financieras, de la introducción de la nueva tecnología y cambios en las políticas del gobierno entre otros.

-         Documentar detalles del sistema actual para su revisión y discusión 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, señalando su justificación. Si es apropiado, quizá la propuesta de un nuevo sistema completo.

-         Documentar las características 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 participación 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 común de preguntas por contestar cuando las emprenden.

 

El análisis estructurado es un método para el análisis 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 situación poco familiar, siempre existe una pregunta sobre donde comenzar el análisis. Una situación dinámica siempre puede ser vista como abrumadora debido a que muchas de las actividades se llevan a cabo constantemente. El análisis estructurado permite al analista conocer un sistema o proceso en forma lógica y manejable al mismo tiempo que proporciona la base para asegurar que no se omite ningún detalle pertinente.

 

¿Qué es lo que se desea estructurar? ¿Qué significa “estructura”? El objetivo que persigue el análisis estructurado es organizar las tareas asociadas con la determinación de requerimientos para obtener comprensión completa y exacta de una situación dada.

En el análisis estructurado, la palabra estructura significa que: 1) el método intenta estructurar el proceso de determinación de los requerimientos comenzando con la documentación 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 fácil verificar cuando se han omitido detalles relevantes; 4) la identificación 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 documentación eficiente.

 

Componentes del análisis estructurado

El análisis estructurado hace uso de los siguientes componentes:

 

1-     Símbolos gráficos: 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 técnicas y lenguajes que permiten a los analistas describir actividades importantes que forman parte del sistema.

4-     Reglas: estándares 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 guía de actividades de la empresa. Ellos pueden iniciar eventos y ser procesados para dar información ú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 organización. El análisis 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 relación 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.

 

CARACTERÍSTICAS DE LAS ESTRATEGIAS DE FLUJO DE DATOS

El análisis de flujo de datos analiza el empleo de los datos para llevar acabo procesos específicos  de la empresa dentro del ámbito de una investigación de sistemas. El análisis 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 características esenciales del sistema y la forma en que se ajustan entre si.

 

El análisis 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 través 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 transformación de datos de entrada en salida por medio de procesos puede describirse en forma lógica e independiente de los componentes físicos asociados con el sistema. Estos diagramas reciben el nombre de diagramas lógicos de flujos de datos.

2-     Diccionario de datos: el diccionario contiene las características lógicas de los sitios donde se almacenan los datos del sistema, incluyendo nombre, descripción, alias, contenido y organización. también identifica los procesos donde se emplean los datos y los sitios donde se necesita el acceso inmediato a la información.

3-     Diagrama de estructura de datos: es una descripción de la relación entre las entidades de un sistema y el conjunto de información relacionado con la entidad. No considera el almacenamiento físico de los datos.

4-     Grafica de estructura: herramienta de diseño que muestra con símbolos la relación entre los módulos de procesamiento y el software de la computadora. Describen la jerarquía de los módulos componentes y los datos que serán transmitidos entre ellos. Incluye el análisis de las transformaciones entrada-salida y el análisis de transacciones.

 

Ventajas del análisis de flujo de datos

El análisis de flujo de datos permite a los analistas aislar áreas de interés en la organización y estudiarlas al examinar los datos que están en el proceso, de tal manera que puedan observar la manera en que cambian cuando lo abandonan. A medida que los analistas reúnen hechos y detalles, comprenden mejor el proceso; esto los conduce a formular preguntas relacionadas con aspectos específicos del mismo y los lleva a una investigación adicional.

 

DESARROLLO DE DIAGRAMAS DE FLUJO DE DATOS

Para que sean de utilidad y proporcionen información, 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 terminología del análisis estructurado, este es el estudio del sistema físico. El sistema físico se transada en una descripción lógica que se centra en datos y procesos.

Durante el análisis de flujo de datos se evalúan todos los detalles en términos de los componentes lógicos de flujos de datos, procesos, almacenes de datos, orígenes y destinos.

En todas las etapas de diseño que siguen, los requerimientos del sistema se trasladan en detalles de diseño lógico. En las fases de construcción, como la programación del software para computadora, las especificaciones lógicas son trasladadas en características físicas y en un sistemas de información que trabaja.

 

Diagramas físicos de flujo de datos

Los diagramas de flujo de datos son de dos tipos:

Diagramas físicos de flujo de datos: proporcionan un panorama del sistema en uso, que es dependiente de la implantación, que muestra que tareas se llevan a cabo y como. Las características físicas incluyen:

-         Nombre de personas -         Nombres o números de formatos y documentos -         Nombres de departamentos -         Archivos maestros de transacciones -         Equipo y dispositivos utilizados -         Ubicaciones -         Nombres de procedimientos

 

 Diagramas lógicos de flujos de datos: proporcionan un panorama del sistema independiente de la implantación, que se centra en el flujo de datos entre los procesos sin considerar los dispositivos específicos y la localización de almacenes de datos o personas en el sistema. En este tipo de diagramas no se indican las características físicas.

 

 

Reglas generales para el dibujo de diagramas lógicos 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.

4-     Un proceso no debe ser nada de ningún 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 están en continua ejecución; 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 información añadida por el proceso.

b-     Una respuesta o cambio en la forma de los datos.

c-     Un cambio de decisión.

d-     Un cambio de contenido.

e-     Cambios en la organización.

Seguir convenciones de nivelación significativa

 

Nivelación 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.

 

Asignación de nombre al flujo de datos: los nombres dados a los flujos de datos deben reflejar los datos de interés 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.

 

Asignación 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 análisis y diseño:

 

1-     Seleccionar nombres que indiquen la acción 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.

5-     Utilizar los nombres de los procesos de bajo nivel ya que estos son mas específicos 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.

 

Evaluación 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 almacén 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 descripción del sistema? ¿Aparecen en el diccionario de datos?

11- ¿Los procesos son independientes entre sí? ¿Dependen solo de los datos que reciben como entrada?

 

CARACTERÍSTICAS DE LOS DICCIONARIOS DE DATOS

Los diccionarios de datos son un componente importante del análisis estructurado ya que por si solos los diagramas de flujo de datos no describen el objeto de la investigación. El diccionario de datos proporciona mas información 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 están estructurados para satisfacer los requerimientos de los usuarios y las necesidades de la organización. 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 común para todos los elementos del sistema Para documentar las características del sistema Para facilitar el análisis de los detalles con la finalidad de evaluar las

características 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 información dependen de loas datos. El diccionario contiene dos tipos de descripciones para flujo de datos dentro del sistema:

 

Elementos dato: son los bloques básicos para todos los demás datos del sistema. Por si mismo no conllevan suficiente significado para ningún usuario.

 

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

 

Descripción 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, descripción, alias y longitud, junto con el intervalo de valores específicos 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.

 

Descripción de los datos: La descripción de un dato describe de manera breve lo que este representa en el sistema.

Las descripciones de los datos deben escribirse con la suposición 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 serán almacenados.

 

Valores de los datos: En algunos procesos solo son permitidos valores muy específicos para los datos. Todos los detalles serán de utilidad a los analistas mas adelante, cuando diseñen los controles del sistema.

 

Descripción de las estructuras de datos

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

 

-         Relación secuencial: define los componentes que siempre se incluyen en una estructura de datos en particular; concatenación de dos o más datos.

-         Relación de selección: define alternativa para datos o estructuras de datos incluidas en una estructura de datos.

-         Relación de iteración: define la repetición de un componente cero o más veces.

-         Relación opcional: caso especial de la iteración; los datos pueden estar o no incluidos, esto es, una o ninguna iteración.

  

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 también se explora la naturaleza de las aplicaciones que son buenos candidatos para desarrollo con el método del prototipo.

 

Usos de los prototipos de aplicaciones

El desarrollo de prototipos de aplicación 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 vehículos para describir las características y requerimientos que debe satisfacer la aplicación.

El segundo uso del prototipo de aplicación es verificar la factibilidad del diseño de un sistema. Los analistas pueden experimentar con diferentes características de la aplicación y evaluar la reacción 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 diseñar y desarrollar sistemas de información con rapidez, eficiencia y eficacia.

 

Aumento de la productividad

La productividad es importante para los analistas de sistemas y para la organización en la que trabajan. Los analistas de sistemas son más productivos si toman precauciones que:

 

-         Minimicen el tiempo que se pierde debido al desarrollo incorrecto.

-         Minimicen los errores del diseño. -         Garanticen que los esfuerzos realizados por ellos sean fructíferos. -         Garanticen que los usuarios reciban la aplicación que necesitan. -         Garanticen que no tendrá que volverse a hacer el trabajo de

desarrollo.

 

Al mismo tiempo, los analistas se enfrentan a muchos obstáculos para alcanzar sus objetivos de desarrollo. A continuación se mencionan varios hechos que deben considerarse:

 

-         Los usuarios tienen gran dificultad para especificar con anticipación sus necesidades de información, en especial cuando la situación es nueva o cambia con rapidez.

-         La especificación completa de los requerimientos de información depende en particular de la forma en que debe utilizarse la tecnología.

-         A menudo las descripciones estáticas de sistemas no son suficientes para proporcionar detalles sobre situaciones dinámicas.

-         La mala comunicación, que siempre es una posibilidad, parece que siempre se presenta en el momento menos oportuno.

 

Aplicaciones para candidatos 

Los prototipos son más eficaces en el desarrollo de sistemas de información 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 aplicación es tal que existe poca información disponible con respecto a las características que debe tener l sistema para satisfacer los requerimientos el usuario.

-         Los requerimientos necesitan evaluarse: Se conocen los requerimientos aparentes de información, tanto de los usuarios finales como de la organización, pero es necesario verificarlos y evaluarlos.

-         Costos altos: La inversión de recursos financieros y humanos así como el tiempo necesario para generar la aplicación es sustancial. Existen otros proyectos que también compiten por los mismos recursos.

-         Alto riesgo: La evaluación inexacta de los requerimientos del sistema o el desarrollo incorrecto de una aplicación ponen en peligro a la organización, a sus empleados y también a sus propios recursos.

-         Nueva tecnología: El deseo de instalar nueva tecnología ya sea con los campos de la computación, de las comunicaciones de datos u otras áreas relacionadas, abre nuevas fronteras para la organización. Muchas

compañías no tienen experiencia en el uso de cierta tecnología ni tampoco las demás organizaciones con las que se comunican.

 

ETAPAS DEL MÉTODO DE PROTOTIPOS 

Identificación de requerimientos conocidos

La determinación de los requerimientos de una aplicación es tan importante para el método de desarrollo de prototipos como lo es para los métodos del ciclo clásico de desarrollo de sistemas o análisis 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 construcción de un prototipo es un proceso iterativo de desarrollo. Antes de la primera iteración, los analistas de sistemas explican el método a los usuarios, las actividades a realizar, la secuencia en la que se llevaran a cabo y también discuten las responsabilidades de cada participante. Un cronograma para el inicio y fin de la primera iteración 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 conversación entre el usuario y el sistema.

-         Pantallas y formatos para la entrada de datos. -         Módulos esenciales de procesamiento. -         Salida del sistema.

 

USO DE PROTOTIPOS

Cuando el prototipo esta terminado, el siguiente paso es tomar la decisión sobre como proceder. Existen cuatro caminos a seguir después de evaluar la información obtenida con el desarrollo y uso del prototipo:

 

Abandono de la aplicación

En algunos casos, la decisión es descartar el prototipo y abandonar el desarrollo de la aplicación. Esta conclusión no significa que fuese un error emprender el proceso de

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

 

Implantación del prototipo

Algunas veces el prototipo se convierte en el sistema que se necesita. En este caso, se implanta sin ninguna modificación y no se emprenden mas esfuerzos de desarrollo. Esta decisión es más probable tomarse bajo una o más de las siguientes circunstancias:

 

-         La evolución de prototipo condujo a una aplicación que tiene las características, capacidades y desempeño requeridos.

-         La aplicación será utilizada con poca frecuencia y no es importante su rapidez o eficiencia operacional.

-         La aplicación no tiene efecto sobre otras aplicaciones o datos de la organización y tampoco interacciona con ellos; además satisface las necesidades de os usuarios inmediatos.

-         El medio ambiente de la aplicación se encuentra en un estado de flujo; es difícil determinar necesidades a largo plazo o condiciones de operación mas estables. En consecuencia no es posible justificar otras actividades de desarrollo. El prototipo es de utilidad para las condiciones actuales.

 

Desarrollo de la aplicación

Cuando un prototipo tiene éxito puede proporcionar información muy amplia con respecto a los requerimientos de la aplicación y conducir a su completo desarrollo. Terminar el prototipo n significa finalizar el proceso de desarrollo. Mas bien señala el comienzo de la siguiente actividad: el desarrollo completo de la aplicación.

El desarrollo de una aplicación puede presentarse como parte del método de ciclo de vida de los sistemas de información. Las dos formas más comunes de incorporar la construcción de un prototipo para la aplicación son las siguientes:

 

-         El prototipo se emplea como una opción para la determinación de requerimientos; las características del prototipo son consideradas como los requerimientos a satisfacer en subsecuentes actividades de desarrollo.

-         El prototipo se utiliza como sustituto para el diseño e implantación de la aplicación, es decir, como un esqueleto a partir del que se construye el resto del sistema.

 

Inicio de un nuevo prototipo

Algunas veces la información ganada con el desarrollo y uso del prototipo, sugiere el empleo de un enfoque muy diferente para satisfacer las necesidades de la organización. En este caso es posible encontrar que las características de la aplicación con muy diferentes si el prototipo  es inadecuado para demostrarlas y evaluarlas.

 

HERRAMIENTAS PARA EL DESARROLLO DE PROTOTIPOS

Lenguajes de cuarta generación

Los lenguajes de cuarta generación fueron creados para ayudar a satisfacer la necesidad de desarrollar un software con mayor eficiencia. Los lenguajes de cuarta generación 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 generación se clasifican en tres categorías:

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 función 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 generación.

Lenguajes de consulta y recuperación: Estos lenguajes facilitan la recuperación 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 comparación con los lenguajes de consulta y recuperación, 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 automática por software, o el usuario también puede proporcionar las especificaciones que instruyan al sistema para preparar títulos específicos, descripciones de pagina y encabezados de columnas.

 

Generadores de aplicaciones

Los generadores de aplicaciones son programas de software que permiten la especificación de toda una aplicación de un nivel muy alto. Ellos proporcionan las condiciones para desarrollar aplicaciones que acepten datos, efectúen cálculos, sigan complicadas rutinas de procesamiento lógico y produzcan reportes y salidas. El generador de aplicaciones produce el código fuente. Algunos producen programas completos. Otros, denominados generadores de programas, reparan el código del programa, como módulos individuales, y permiten al usuario enlazar otros módulos con los producidos por el generador.

 

Generadores de pantalla

Un generador de pantalla es una herramienta interactiva para dibujar pantallas y efectuar la validación automática de la entrada y procesamiento. Es posible seleccionar con respuestas sencillas preferencias sobre el presentar con mayor brillantez la información más importante, el utilizar determinados colores o hacer uso del video inverso.

Los generadores de pantalla también permiten que los usuarios preparen automáticamente componentes que sean de ayuda en la interacción usuario-maquina, incluyendo la localización 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 análisis 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 más 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 más 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 también ocurre lo mismo con los resultados.

 

Beneficios de las herramientas asistidas por la computadora

La introducción de herramientas asistidas por la computadora en los esfuerzos de análisis y desarrollo aumentan los beneficios que se derivan del uso de las herramientas. Las herramientas del análisis asistido por la computadora mejoran la velocidad y disminuyen el tiempo necesario para completar la tarea de desarrollo.

La automatización también 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 más consistente. Se convierten en rutinas. La consistencia que pueden ofrecer los procedimientos es una excelente razón 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 recuperación de los detalles de un sistema. Una vez en forma procesable por la computadora, los detalles del sistema pueden utilizarse para muchas finalidades.

 

CLASIFICACIÓN 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 técnicas de soporte para ayudar al analista a preparar especificaciones formales que carezcan de ambigüedades, a validar las descripciones del sistema con el objeto de determinar su consistencia y completez, y a seguir la evolución de los requerimientos de la aplicación en características 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 lógica del programa, los algoritmos de procesamiento y la descripción física de los datos, también ayudan a la interacción con los dispositivos, etc. Estas actividades convierten los diseños lógicos del software en un código de programación que es el que finalmente da existencia a la aplicación.

 

Herramientas integrales

Las actividades de análisis 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 serán satisfechos estos requerimientos por medio de detalles que son específicos de la computadora.

 

 

HERRAMIENTAS ASISTIDAS POR COMPUTADORA PARA LE INGENIERÍA DE SISTEMAS (CASE)

Las herramientas de tipo CASE incluyen los siguientes cinco componentes:

Herramientas para diagramación: Estas herramientas dan soporte al análisis y documentación de los requerimientos de una aplicación. Por lo general, incluyen facilidades para producir diagramas de flujo de datos.

Las herramientas ofrecen la capacidad de dibujar diagramas y cartas, además de guardar los detalles en forma interna.

Deposito centralizado de información: La captura, análisis, procesamiento y distribución de todos los sistemas de información es asistida por un deposito de información centralizado o diccionario de datos.

Aunque los diccionarios son diseñados para que el acceso a la información sea sencillo, también incluyen controles y medidas de protección 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 rápida creación de menús de demostración para el sistema, de pantallas de presentación y del formato de los informes.

Generadores de código: Los generadores de código automatizan la preparación del software. Estos incorporan métodos que permiten convertir las especificaciones del sistema en código ejecutable.

Herramientas de administración: Algunas herramientas CASE para administración permiten que los gerentes de proyecto especifiquen elementos de su propia elección.

Otras permiten definir metodologías de desarrollo propias, incluyendo las reglas de validación y los estándares para datos  nombres de procedimientos.

 

Integración de la herramientas CASE

La integración 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 común 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 unión de las fases de desarrollo se encuentran relacionadas, ya que se pueden utilizar una y otra vez los datos transferidos entre herramientas a través de todo el proceso de desarrollo.

 

USO DE UNA HERRAMIENTA CASE

Operaciones iniciales

Los sistemas CASE almacenan información por proyecto. Cada aplicación de sistemas de información es considerada como un proyecto.

Antes de iniciar el trabajo, el analista debe proporcionar su nombre y contraseña. 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, documentación, análisis, interfaces y utilerías.

 

Dibujo de diagramas de flujo de datos

Cuando se selecciona la función 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 documentación, toda la información con respecto al proyecto se acumula en el diccionario de datos que Excelerator mantiene para dicho proyecto. Parte de la información, 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 método rápido y sencillo para desarrollar prototipos de pantallas para que los usuarios finales trabajen con ellas. El analista puede diseñar y ejecutar pantallas y reportes con el apoyo de un menú, e incluso desarrollar el prototipo de una base de datos.

 

Herramientas para el análisis y documentación

Excelerator ofrece características tales como un conjunto de reportes que validan las descripciones del sistema. Los reportes del análisis 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. también es posible detectar y notificar diagramas no balanceados.

 

Utilerías

La información utilizada por el sistema Excelerator se encuentra descrita por las funciones de utilería. Existe también una función especial para el manejo de proyectos que los analistas emplean para dar nombre al proyecto, proporcionar descripciones del mismo y definir la notación que utilizaran para los diagramas de flujo de datos.

 

Beneficios de CASE

Entre los beneficios ofrecidos por la tecnología CASE se encuentran los siguientes:

 

-         Facilidad para llevar a cabo la tarea de revisión 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 desempeño del sistema tendrán otras alternativas.

-         Generación de código. -         Soporte para mantenimiento como resultado de haber guardado las

especificaciones del sistema en un deposito central de información. -         Aumentar las posibilidades de satisfacer los requerimientos del

usuario.

 

 

Debilidades de CASE

Entre las debilidades de CASE se encuentran las siguientes:

 

-         Muchas herramientas CASE están construidas teniendo como base las metodologías del análisis estructurado y del ciclo de vida de desarrollo de sistemas. Por si sola, esta característica puede convertirse en la principal limitante ya que no todas las organizaciones emplean métodos de análisis estructurado.

-         Falta de niveles estándar para el soporte de tecnología. -         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 metodologías de desarrollo, por lo general su enfoque primario esta dirigido hacia una fase o método 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 ningún análisis de los requerimientos de la aplicación.

-         Las tareas humanas siguen siendo criticas. Las herramientas deben adaptarse a la arquitectura de la información así como a las metodologías de desarrollo utilizadas por la organización.

DISEÑO DE SISTEMAS

El diseño de sistemas es convertir los requerimientos en soluciones que los satisfagan.

Para diseñar un sistema se deben especificar los requerimientos de la aplicación, anteriormente se nombraron y explicaron herramientas para especificar estos requerimientos . Estos métodos o herramientas son de gran ayuda para la documentación del sistema, pero no realizan el análisis 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 análisis

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 organización se lleven a cabo de la manera deseada. Hay varias preguntas que el analista debe hacer cuando evalúa el control de los procedimientos como por ejemplo ¿Los pasos del proceso se realizan en forma apropiada?, ¿Existe la posibilidad de que se estén efectuando pasos no autorizados?, ¿Se pueden duplicar actividades?, ¿La gerencia esta al tanto de tareas no realizadas?, ¿Existe verificación de datos, códigos de procedimientos, etc?

Las soluciones a un problema de control de procedimientos pueden ser las siguientes:

1. Diseñar el sistema de manera que los fallos en los controles estén prohibidos y de esta forma se neutralizan los eventos que no pueden ocurrir

2. Diseñar detectores de errores o fallos que los identifiquen y los notifiquen para que la persona autorizada los corrija

3. Diseñar 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 Información: ya sea por que no existe o por que su acceso es muy difícil, se pueden producir problemas con el acceso a la información necesaria para realizar una labor. Para evitar este problema existen varias estrategias:

1. Eliminar la necesidad de información rediseñando el sistema de una forma en la cual las reglas y procesos de decisión formen parte de él.

2. Facilitar el acceso a la información 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 presentación

Complejidad: cuando las tareas son muy complejas es mas fácil 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. Simplificación: se obtiene eliminando pasos innecesarios, registros que no se utilizan, etc.

2.  Dividir los procesos complejos en tareas separadas3. Cambiar la secuencia de un proceso puede disminuir la

complejidad

 

 El diseño de sistemas tiene dos etapas:

Diseño Lógico:

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

 

Diseño Físico:

Entrada de datos Soporte para decisiones Generación de Reportes Consultas Comunicación Mantenimiento de Archivos Respaldo Archivos de Transacción, de reporte, maestro, etc.

 

 

En general, el analista debe diseñar el sistema de manera que:

Sea fácil de utilizar Este bien validado Evite fallas en procedimientos críticos para la empresa Sea flexible Sea Adaptable Sea ergonómico

 

En la actualidad existen estándares de diseño de sistemas, a continuación se dan ejemplos de áreas incluidas en estos estándares:

Estándares para datos: modelos a seguir para nombrar a los datos y especificar su longitud y tipo, esto está contenido en el diccionario de datos.

Estándares de Codificación: Abreviaturas para describir procesos y entidades dentro de una organización

Estándares Estructurales: lineamientos para dividir el sistema en módulos, para la codificación estructurada, reutilización de código.

Estándares de Documentación: descripción de los detalles de la aplicación

 

 

Elementos del Diseño

 

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 información. Pueden ser manuales o automatizados

 

Controles: lineamientos para determinar si los procesos están siendo ejecutados de forma correcta

 

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

 

 

Diseño de la Salida

 

El analista debe realizar lo siguiente:

Identificar la información que desea presentar al usuario Decidir por que medio será presentada esa información

(impresora, pantalla, etc.) La información debe ser presentada en un formato aceptable

 

 

Diseño de Archivos

El diseño 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 diseñando interactúa con un archivo maestro que ya esta creado, los detalles de este archivo se incluyen en las especificaciones de diseño del sistema, pero el archivo no vuelve a diseñarse.

 

Diseño de Interacciones con la base de datos

El diseño 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 diseña 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 descripción de los datos que van a ser ingresados allí y las acciones que se efectuaran en esa BD.

 

 

Diseño de Entrada

Los analistas de sistemas detallan los siguientes puntos del diseño de entradas:

 

Datos de entrada Recursos que utiliza el sistema para la captura de datos La codificación de los datos Diálogos para ayudar a los usuarios a ingresar los datos en el

sistema Validación de datos

 

La ubicación de las entradas de datos (textbox, combobox, etc) también formar parte del diseño de la entrada de datos, así como también los encabezados, los títulos de los formularios, etc.

  

Diseño de Controles

Los analistas de sistemas deben predecir los errores creados al momento de que el usuario ingrese datos errados o cuando solicite la ejecución de una función especifica. Un buen sistema de información sabe como lidiar con este tipo de errores. Los controles de entrada aseguran que sólo los usuarios autorizados tengan acceso al sistema, determinar si faltan datos de entradas importantes, validan los datos para verificar que sean correctos.

 

 

Diseño de Procedimientos

Los procedimientos determinan las tareas que deben efectuarse al utilizar la aplicación y especifica quienes son los responsables de realizarlas. Los procedimientos mas importantes son:

Procedimientos para entrada de datos: captura de datos

 

Procedimientos durante la ejecución: 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 algún error.

 

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

 

 

Diseño de Especificaciones para programas

Describen cómo transformar las especificaciones de diseño del sistema (salidas, entradas, archivos, etc) en software de computadora. El diseño del software asegura que: los programas finales realicen todas sus tareas en la forma establecida, la programación 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 Descripción del diseño del sistema

Ningún diseño esta completo sin la carpeta de diseño ya que esta contiene toda la información detallada acerca del sistema, sus procesos, datos, etc.

La información 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 ubicación detallada de los reportes que aparecerán, documentos y pantallas.

Estructuras de los registros: describe los datos almacenados en los archivos maestros y de movimientos y también contiene los diagramas relacionados con la BD

Sistemas de codificación: describe los códigos que explican o establecen los tipos de transacciones, clasificaciones y categoría de eventos o entidades

Especificaciones de programas: son cuadros, tablas, gráficos, etc que explican todos los módulos del sistema y establecen la relación entre ellos.

Especificaciones de procedimientos: son los procedimientos planificados para instalar y operar la aplicación cuando este culminado

Plan de desarrollo: cronograma de actividades de los analistas, programadores y demás personal involucrado con el desarrollo del sistema

Costo del paquete: gastos anticipados para el desarrollo del sistema clasificados en categorías como personal, equipo, etc.

 

 

Participación de los usuarios

Para diseñar un buen sistema de información que satisfaga todas y cada una de las necesidades del usuario, éste debe participar en el diseño del mismo porque de esta manera se asegura que los usuarios tengan un punto de vista no técnico de lo que hace y de lo que no hace el sistema. El sistema no se diseña 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 podrían ser perjudiciales para la organización. Los usuarios y los analistas tienen responsabilidades en el manejo de estos sistemas:

 

 

Responsabilidades de los usuarios en el diseño

 

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 estándares establecidos

 

Responsabilidades del Analista

 

Transformar las necesidades de datos en requerimientos Impartir educación y entrenamiento a los usuarios Apoyar al usuario en el diseño y proceso de desarrollo del

sistema Asistir al usuario en la parte de detección y corrección 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 modificación de los datos ya validados

 

Estandarización: para obtener consistencia y uniformidad en el desarrollo

 

Documentación del Diseño: explica la forma en la cual esta diseñado el sistema y como utilizarlo

 

Revisión de las especificaciones de diseño: para aumentar la confiabilidad de las aplicaciones desarrolladas por los usuarios, éstas tienen que estar en constante revisión

 

 

Diseño de salida del sistema de computo

Las salidas del sistema son cualquier información que arroje el sistema de información, ya se impreso o por pantalla. El analista para diseñar estas salidas debe identificar la salida que se necesita para cubrir la necesidad de información, debe especificar los métodos para el diseño de éstas salidas y por ultimo deben crear los documentos o reportes que contienen la información que arroja el sistema.

 

Objetivos de la Salida

1. Expresar la información que tengan relación con actividades realizadas en el pasado, de estados actuales o información proyectada hacia el futuro

2. Resaltar eventos de importancia, ya sean problemas, errores o advertencias

3. Ejecutar acciones4. Verificar esas acciones

Las salidas deben ser diseñadas tomando muy en cuenta la función que éstas van a cumplir.

 

 

Tipos de Salida

 

1. Un reporte2. Un documento3. Un mensaje

 

Las salidas pueden ser impresas o presentadas por pantalla.

 

Las fuentes de las salidas pueden ser:

1. Recuperación de un almacenamiento de datos2. Paso de mensajes desde un proceso a otro3. Dispositivos de Entrada

 

 

Aspectos importantes de la salida

A través de las siguientes cinco preguntas se puede comprender mejor lo que debe ser la salida de un sistema:

1. ¿Quiénes recibirán la información?2. ¿Cuál es el uso que se le dará a la información?3. ¿Cuántos detalles se necesitan?4. ¿Cuándo se necesita la información?5. ¿Qué método utilizar?

 

Cómo presentar la información

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

 

Formato Tabular Éste formato debe utilizarse:

Cuando los detalles dominan y no se necesitan muchos comentarios

Cuando los detalles son presentados en categorías discretas Cuando cada categoría deba tener una etiqueta Cuando es necesario obtener totales o comparar diferentes

componentes Cuando las entidades dependan del tiempo

 

Formato Gráfico

Como su nombre lo indica utiliza gráficos para presentar la información. Existen distintos tipos de gráficas:

De Sectores: describen las distintas partes que conforman un todo, y que tienen relación con una actividad determinada

Curvas: muestran cambios en la actividad a lo largo de cierto tiempo

De escalones o superficie: muestran cambios en categorías Barras y columnas Mapas: muestran variaciones en distintas zonas geográficas

Las gráficas se utilizan por varias razones:

Para mejorar el entendimiento por parte del usuario de la información que ésta siendo presentada

Para poder manejar mayor volumen de información Para que la información se ajuste a las preferencias del usuario

 

Estándares para el diseño de gráficas

Toda gráfica debe incluir un titulo Fecha en que se realizo Añadir números de página 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 gráficas de entidades, por lo tanto ofrecen una gran ayuda al momento de acceder rápidamente a la información, y tienen un efecto visual que los hace atractivos para el usuario, ayudándolo así a manejar mejor el sistema

 

Lineamientos de cuando y como utilizar los íconos en un sistema de información:

 

Utilizar íconos que sean reconocidos fácilmente por el usuario Si no existe algún icono que represente gráficamente 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 pequeña para evitar la sobrecarga de imágenes

Mantener un mismo tamaño para todos los iconos

 

 

Diseño de salida impresa

Las salidas impresas se utilizan cuando se necesita el físico de la información por cualquier razón que tenga el usuario: que necesite enviar por correo la información, 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 organización

 

Lineamientos:

 

1. Los documentos deben estar diseñados para ser leídos de izquierda a derecha y de arriba hacia abajo

2. Los datos de mayor importancia deben estar ubicados de tal forma que sean fáciles de encontrar

3. Todas las páginas deben tener título, número de página y fecha en que fue impresa

4. Todas las columnas deben estar etiquetadas5. No utilizar abreviaturas

 

 

Diseño de salida por pantalla

 

Las salidas por pantalla tienen la desventaja del espacio comparada con las salidas impresas, además los usuarios saben buscar la

información en un reporte impreso (saben voltear las paginas, etc), en cambio no podemos suponer esto cuándo se diseñan pantallas

 

En este diseño se incluyen el uso de gráficas e iconos, existen diversas formas de presentar la información por pantalla, la más usada es a través del uso de ventanas.

Hay ventanas estáticas y ventanas de aparición repentina, las estáticas se utilizan para mostrar alguna información que el usuario requiera, en cambio las de aparición repentina sirven para pedir información, dar advertencias o incluso mostrar errores.

 

 

 

Diseño de Entradas

 

El diseño de entradas une al sistema con los usuarios. Objetivos del diseño 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 más rápido.

 

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 número de errores disminuyendo el volumen de datos que deben entrar en el sistema.

 

Evitar pasos adicionales: el analista debe diseñar 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 diseñar el sistema de forma que capture sólo aquellos datos que deben proporcionarse como entradas cuando se procesan transacciones:

 

1. Datos variables: son los datos que cambian para cada transacción

2. Datos de identificación: es el dato de identificación de artículo en cada registro de transacción

 

También 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 través 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 leídos 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

 

 

Diseño de documentos fuente

Es la forma en la cual se capturan los datos inicialmente. Para diseñar estos documentos fuente los analistas de sistemas debe plantearse las siguientes preguntas:

¿Los datos que se encuentran en la forma pueden ser leídos por el sistema?

¿Cuál es el mejor método para introducir los datos y que minimice la cantidad de entradas?

 

 

Métodos de codificación

Es expresar las palabras, ideas o relaciones por medio de un código; esto ayuda al ahorro de espacio, tiempo y costos, y acelera todos los procesos. Existen varios métodos de codificación:

 

Códigos de clasificación: los códigos de clasificación separan las entidades, eventos, personas u objetos, colocándolos en grupos distintos que reciben el nombre de clases.

 

Códigos de funciones: es asignar un código a las tareas o trabajos a realizar por el programa sin tener que proporcionar todos los detalles.

 

Códigos en secuencia: son números o letras asignados en secuencia para saber en que orden ocurrirán los eventos.

 

Códigos con subconjuntos de dígitos significativos: son varios códigos organizados secuencialmente que en conjunto representan la información detallada del articulo. Estos subconjuntos de códigos indican cada uno por separado aspectos como clase de articulo, vendedor, etc.

 

Códigos nemónicos: estos códigos utilizan números y letras para describir algo en forma visual. Por ejemplo, un televisor de color de 21 pulgadas se puede traducir en TV-CL-21.

 

 

Métodos de  captura de datos

 

Captura de datos fuente por medio de perforadoras: en la actualidad este método se usa muy rara vez, consiste en:

1. Escribir los datos sobre el documento fuente2. Perforar los datos en tarjetas3. Verificar las tarjetas perforadas volviendo a introducir los

datos a la máquina de verificación, la cual los compara con los datos ya perforados

4. Colocar las tarjetas perforadas en un lote para ser leídas y procesadas por la computadora

5. Ir validando los datos mientras la computadora los lee6. Procesar los datos

 

 

Captura de datos fuente con dispositivos teclado-almacenamiento:

 

1. Escribir los datos sobre el documento fuente2. 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 datos4. Se debe validar los datos a medida que son leídos por el

computador para luego ser procesados5. 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 través del lector óptico de caracteres

3. La validación se realiza a medida que se van ingresando los datos en la computadora

4. Procesar los datos

 

 

Entrada directa a través de terminales inteligentes: estos terminales tienen la capacidad de procesamiento de datos, gracias a esto no se necesitan documentos fuente. Este método se puede resumir en los siguientes pasos:

1. Proporcionar los datos en el terminal2. Validar los datos a medida que se vayan ingresando en el

terminal3. Procesar los datos

 

 

Validación 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 categorías principales de métodos: verificación de la transacción, la verificación de los datos de la transacción y el cambio de ellos.

 

 

Verificación de la transacción

 

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 método 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 número de serie para cada lote de manera de identificarlos con facilidad para que ninguno de ellos pase por alto y no sea procesado.

 

 

Verificación de los datos de la transacción

 

Las transacciones validas pueden contener datos inválidos, entonces los analistas deben establecer métodos de validación 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 vacíos.

 

Pruebas de límites y rangos

Validan el mínimo y el máximo de caracteres aceptables para un dato

 

Pruebas de combinación

Cuando un solo dato afecta a los demás, por ejemplo al introducir una categoría no se puede colocar en los otros campos datos que no tengan que ver con esa categoría, por ello se valida si todos esos campos tienen relación

 

Procesamiento duplicado

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

 

 

Modificación de los datos de la transacción

 

Esta forma de validación implica la modificación automática de los datos erróneos ingresados por el usuario. Para ello existen los siguientes métodos:

 

Corrección automática

Este método sólo implica que el sistema detecte el error y lo corrija automáticamente, por ejemplo no se ingresan ceros en un campo numérico por error del usuario, el sistema lo detecta y agrega los ceros en los espacios en blanco.

 

Dígitos de verificación

Es añadir un número automáticamente siguiendo un lineamiento especifico al código que el usuario esta ingresando, de esta manera evitamos los errores de transcripción y de transposición.

 

 

Diseño de dialogo en línea La mayoría de las aplicaciones de sistemas de información desarrolladas hoy en día en las organizaciones utilizan métodos en línea, en donde el usuario interactúa de forma directa con el sistema de cómputo por medio de una estación de trabajo o dispositivo familiar.

 

Los sistemas en línea 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 diseño de una interfase apropiada.

 

Propósitos de la interfase

 

Decir al sistema las acciones a realizar

 

Facilitar el uso del sistema

 

Evitar los errores del usuario

 

 

Características de la interfase

 

Las características de la interfase incluyen los dispositivos utilizados para introducir y recibir datos tales como el teclado, el ratón, scanner, lápiz óptico, etc; el diálogo que incita y guía a los usuarios y los métodos o patrones que se siguen al mostrar la información.

 

 

Acciones que se llevan a cabo  en la interfase

 

Navegación

En un sistema manual de reportes y documentos, los usuarios pueden ver cómo saltase la información que tienen ante ellos. Debido a que la pantalla del monitor presenta únicamente una página de información a la vez, el analista debe mantener informado al usuario acerca de qué página se está mostrando y cuándo cambiar a otras páginas.

He aquí algunas de las preguntas que usted podría formular:

¿Dónde estoy en el sistema? ¿Adónde puedo ir dentro del sistema? ¿Cómo llego al principio? ¿Cómo me muevo hacia atrás? ¿Cómo cancelo el efecto de mi última acción?

¿Cómo corrijo mi error? ¿Cómo puede detener la acción de procesamiento que acaba de

comenzar?

 

 

 

Diseño del Diálogo

Un diálogo es la forma en la que el usuario interactúa con el sistema. Por lo tanto es muy importante el diseño correcto de estos.

 

Diagramas para diálogos

Presentan las secuencias de actividades que se pueden llevar a cabo en un sistema y también cómo iniciar las acciones.

Por convención, las funciones de procesamiento se muestran en rectángulos que incluyen el nombre de la función. Cada función está ligada a funciones de niveles superiores e inferiores mediante una flecha con el nombre de la opción elegida en el nivel superior.

 

 

Decisiones en el diseño de diálogos

 

La conversación entre el usuario y el sistema depende completamente del diseño del diálogo. Un diseño fácil de usar significa que la conversación puede fluir con facilidad. Las decisiones que debe hacer el analista son las siguientes:

1. Estrategia general del diálogo2. Diálogo de entrada de datos3. Paginación y scrolling4. Mensajes y comentarios5. Navegación del usuario6. Asignación de teclas7. Sistema de ayuda

 

 

Estrategias de diálogo

 

Diálogo conducido por menú

Debido a que los sistemas en línea proporcionan varias opciones de entrada y procesamiento  a los usuarios, se requiere de un método para mostrar a los usuarios las alternativas disponibles. Los menús cumple este propósito, de modo de que el usuario pueda elegir entre las funciones que se encuentran en ese menú.

 

Diálogo por medio del teclado

Los usuarios llamas a las actividades de procesamiento tecleando un comando que el sistema entiende. Las tres formas de diálogo mediante teclado incluyen las formas de comando único, nemónico y de lenguaje natural.

 

Forma de comando único: el usuario teclea la palabra clave que el sistema asociará con la realización de un proceso específico

Forma de comando nemónico: 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 rígidos. En vez de utilizar la sintaxis convencional de los comandos, los usuarios aplican su propio vocabulario de palabras u operaciones.

 

 

Diálogo pregunta/respuesta

 

Estos se basan en la presentación de preguntas al usuario. La respuesta que el usuario dé guía el procesamiento resultante

 

 

 

Diálogo 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 información a introducir. Además de los títulos y encabezados en la pantalla, el formato contiene etiquetas que identifican los datos por introducir

 

Indicación pregunta/respuesta

Se piden datos al usuario mediante preguntas que hace el sistema. El método pregunta/respuesta, que es sencillo de usar, ofrece la ventaja adicional de permitir el control total de la secuencia en que se recibe la información.

 

 

Manejo de Pantalla

Las pantallas deben seguir un diseño general que proporcione un uso consistente de las áreas o ventanas en el monitor. Entre las consideraciones del diseño están la estandarización de uso de ventanas, el manejo de navegación y secuencias de escape, y la paginación y scrolling.

 

Uso de ventanas

 

Ventana de título: Identifica el título de la pantalla, la función a desarrollar o la aplicación en ejecución; puede incluir datos del sistema

Ventana de instrucciones: Le dice al usuario cómo introducir datos, elegir un procesamiento alternativo o salir del sistema

Ventana principal de texto: La porción más grande de la pantalla; incluye pantalla para captura de datos, menús o procesamientos alternativos

Área de navegación y menú: Instruye al usuario sobre cómo moverse entre las páginas de información, pantallas o menús; también identifica la información de escape

Ventana de mensajes: Contiene mensajes de información y control

Ventana de banderas: Una alternativa que puede utilizarse para señalar las actividades actuales o las instrucciones a procesar

 

Facilidad de navegación del usuario

Es frecuente que los usuarios se pierdan y requieran de un mapa del sistema. Los menús anidados pueden inhibir la facilidad de navegación. Para mejorar la navegación 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.

 

Paginación y Scrolling

La paginación se refiere a manejar grandes cantidades de información para poder presentarla al usuario así esta información ocupe más de una pantalla la paginación la divide en varias.

El scrolling es cuando la pantalla se mueve hacia arriba o hacia abajo para poder leer toda la información. Esta es otra forma de presentar grandes cantidades de información.

 

 

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 acción Verificar que una acción 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 verificación de acciones

Las solicitudes que produzcan cambios significativos o que puedan iniciar procesos de ejecución larga necesitan verificación

 

Sistemas de ayuda

Aun en los sistemas mejor diseñados, se necesitan funciones de ayuda, no para instruir al usuario, sino para proporcionar información acerca de las preguntas que surjan. Por ejemplo dar una breve explicación 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 función a consultar. Algunas características  de ayuda son sensibles al contexto, es decir, determinan la acción 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; aplicándolos en las interacciones con una base de datos. Entre sus principales finalidades se encuentran:

1. “Verificar los requerimientos de información2. Describir los datos asociados con las entidades.3. Mostrar la relación entre entidades4. Comunicar los requerimientos de datos a un diseñador de

archivo o administrador de la base de datos.”

 

Para la realización de estos diagramas se utiliza una notación común en la cual las entidades se representan mediante rectángulos, 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 realización requiere también 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 información acerca de la entidad?

3. ¿Cuáles 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 organización. Puede contener datos que describan el estado actual de eventos específicos 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 actualización.  

 

Archivos de Transacciones:

Es un archivo temporal con dos propósitos: acumular datos acerca de los eventos al momento que ocurran y actualizar los archivos maestros para reflejar los resultados de las transacciones actuales. En algún momento ya no son necesarios y se borran o se destruyen,

dependiendo del método utilizado para almacenar los datos. Los archivos de transacciones pueden retenerse por meses, a veces incluso por años, después de que han sido creado, dependiendo de las necesidades legales y de la organización.

 

Archivo de tablas:

Los archivos de tablas contienen datos de referencia utilizados en el procesamiento de transacciones, actualización de los archivos maestros o producción 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 incluirán en los programas de los archivo maestro.

 

Archivo de Reporte:

Son archivos temporales que se utilizan cuando el tiempo de impresión no esta disponible para todos los reportes producidos, situación que surge con frecuencia en el procesamiento sobrepuesto. La computadora escribe el reporte o documento a un archivo en disco o en cinta magnética, 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 topográficos comerciales.

 

Métodos de organización de archivos

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

 

Organización 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.

 

Evaluación de archivos secuenciales:

 Solo se almacenan o leen registros unos después de otro. Para procesar el archivo, se comienza desde el principio y se lee un registro después del otro. Es necesario acceder cada registro en el archivo para una aplicación particular. En este caso en archivo secuencial es un buen método de  organización.

 

Organización de acceso directo

Son archivos con llave. Asocian un registro con un valor llave específico y un lugar de almacenamiento. Este método le pide al programa que diga al sistema donde de almacena un registro antes de poderlo accesar.

 

Direccionamiento por hashing:

Este método se utiliza cuando no  puede ser procesado el acceso directo pero el mismo es necesario. Para la realización de este método es necesario diseñar un algoritmo para transformar un valor de la llave en otro valor que sirva como dirección de almacenamiento. 

 

Requerimientos para los algoritmos de hashing:

 

Posibilidad de repetición:

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

 

Distribución uniforme:

Esta distribución los registros deben distribuirse de manera uniforme en todo el espacio asignado en vez de acumularse todos juntos.

Minimizar sinónimos:

No existe un algoritmo de hashing perfecto, aunque algunos son mejores que otros cuando se trata de minimizar sinónimos. En la práctica, los sinónimos aparecen cuando el procedimiento de dispersión se aplica a llaves distintas y produce la misma dirección en el almacenamiento.

 

Organización indexada:

Es la manera de accesar a un registro por medio de un índice. Esto permite que la búsqueda de un registro  sea mas fácil  si se usa el índice, ya que toma menos tiempo buscar un índice que un archivo completo de datos.

 

Características 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 método de la organización indexada, se busca primero el índice para hallar la llave del registro deseado.

 

Organización indexada no secuencial:

Existe un registro en el índice  por cada registro en el archivo maestro.

 

Organización indexada secuencial:

Es la mas utilizada en los sistemas de información, crea un archivo seudosecuencial. Los registros se almacenan en bloques con capacidad de una cantidad específica de datos.

 

Desarrollo de sistemas en un ambiente de base datos

Permite compartir los datos entre distintas aplicaciones. Además de la responsabilidad de diseñar archivos, determinar sus contenidos y elegir los métodos apropiados para organizar los datos, se debe diseñar los medios de interacción con las bases de datos de organización.

 

Diagramas de estructura de datos   

Construiremos un diagrama a partir de la información obtenida, al preparar el diagrama de relación entre las entidades.

 

Apuntadores atributos:

Enlazan dos entidades mediante la información común, usualmente un atributo llave en uno y un atributo (no llave) en el otro.

 

Apuntadores lógicos:

Identifica las relaciones entre las entidades; sirven para obtener acceso inmediato a la  información en una entidad, definiendo un atributo llave en otra entidad.

 

 

El impacto de los sistemas de manejo de una base de datos en el diseño de sistemas

Este proporciona la flexibilidad en el almacenamiento y recuperación de datos y producción de la información.

 

Esquema:

El DBMS es un puente entre el programa de aplicación, el cual determina qué datos son necesarios y como se les procesará, además 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 aplicación determina que datos se necesitan y comunica la necesidad al DBMS.

El DBMS determina que los datos solicitados realmente estén almacenados en la base de datos (aun cuando podrían estar almacenados bajo un nombre distinto, un alias)

El DBMS instruye al sistema operativo para localizar y recuperar los datos del lugar específico en el disco magnético.

Se da una copia de los datos al programa  de aplicación para su procesamiento.

 

 

Estructuras de datos para los datos interrelacionados

 

Multilista:

Es como una cadena, en donde cada eslabón es un registro que cumple con los requerimientos especificados por el usuario mediante el programa de aplicación.

 

Archivo invertido:

Este utiliza un índice para almacenar la información acerca de la ubicación de registros con atributos particulares.

 

Modelos de datos

Modelo relacional:

Es en la actualidad el más popular en los sistemas de manejo de una base de datos, puesto que es conceptualmente sencillo y compresible por profesionales.

 

Estructuración de datos

Normalización:

Es el proceso de simplificar la relación entre los campos de un registro. Por este método, un conjunto de datos en registro se reemplaza por varios registros que son más 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 recuperación sencilla de los datos en respuesta a las solicitudes de consultas y reportes.

·        Simplificar el mantenimiento de los datos actualizándolos, insertándolos y borrándolos.

·        Reducir la necesidad de reestructurar o reorganizar los datos cuando surjan nuevas aplicaciones.

 

 

 

Manipulación 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 solución.

 

Operaciones  PROJECT:

Es la que crea una nueva tabla a partir de los datos extraídos, utilizando atributos especificados en la pregunta.

 

Operaciones JOIN:

 Es la que crea una nueva relación combinando dos tablas existentes, eligiendo los registros que cumplan los criterios establecidos en la pregunta y removiendo después los registros duplicados.

 

Modelo jerárquico.

Es el que relaciona las entidades por medio de una relación superior/ subordinado.

 

Modelo de red

Es parecido al modelo jerárquico excepto que una  entidad puede tener más de un superior.

 

 

DISEÑO PARA COMUNICACIÓN DE DATOS 

Canales de comunicación

Un canal es la ruta que interconecta al punto de donde se transmiten los datos con su destino.

 

Cable telefónico por pares:

Es el mas antiguo y común de los canales de comunicación.

 

Velocidades de transmisión:

Esta velocidad se mide en bits por segundo. La velocidad de transmisión depende de varios factores distintos, incluyendo las características del canal de comunicación, dispositivos asociados al canal y los componentes de hardware o software.

 

Cable coaxial:

Este medio hace posible velocidades más altas de transmisión, y permite que más datos se muevan en el canal en un periodo de tiempo.

 

Microondas:

No se utilizan cables, las estaciones de envío y recepción llevan la transmisión por el aire.

 

Satélite:

Los datos se transmiten desde las instalaciones del usuario a una estación terrena, de donde se envían a un satélite ubicado en el espacio, este recibe la señal y la retransmite a otro destino en la tierra.

 

Fibras ópticas:

Una fibra de vidrio o plástico se introduce en un largo cilindro que actúa como medio de transmisión. Los pulsos de luz transportan los datos.

 

Redes de comunicación

Estas pueden cubrir diferentes distancias, según los requerimientos de la organización y el sistema de información. 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

 

Topología de red:

Las redes de comunicaciones utilizan 4 topologías distintas, que son la disposición de los dispositivos de comunicación y rutas de datos que llevan acabo la transmisión de datos.

 

Sistema entre puntos:

Funcionan con terminales o estaciones de captura de datos en una instalación conectadas directamente a un sistema en otra instalación.

Estos sistemas pueden comunicar computadoras, interconectando lugares separados para que sean capases de comunicarse entre si.

 

Topología estrella:

Cada estación de trabajo o computadora puede comunicarse solamente con la instalación central y no con los demás nodos de la red.

 

Topología de anillo:

Permite la comunicación directa entre los nodos y con la computadora central, en otras palabras la instalación central no maneja los datos que se transmiten de un nodo a otro.

 

Modelo de interconexión IEA

Este modelo pone énfasis en la capacidad de poder utilizar el equipo de varios fabricantes distinto en las redes de comunicación.

Este modelo divide una red en 7 niveles, cada uno con tareas y funciones claras y proporciona entradas específicas para los niveles adyacentes.

 

Nivel físico:

Este nivel une la computadora y el flujo de datos con el canal de comunicación. Aquí se consideran los aspectos eléctricos y no el como se empacan los datos o los patrones de los datos.

Nivel de línea 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 detección 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; también establece y termina las secciones de transmisión.

 

Nivel de sección:

Este nivel crea y maneja las interconexiones que existen entre dos entes que se comunican, también maneja las técnicas de recuperación en el caso en que la comunicación termine de forma abrupta debido a un error, falla o desconexión.

 

Nivel de presentación:

Este nivel maneja la traducción y formateo de los datos; la traducción de códigos y la compresión de datos.

 

Nivel de aplicación:

El punto de acceso del usuario a la red, consta del software de aplicación.

 

 

Diseño de redes locales

Estas tienen como finalidad conectar las computadoras y componentes de un sistema de cómputo dentro de una área geográfica limitada. La mayoría de estas redes usan una topología 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 través de los dispositivos de cómputo en   diversos lugares para permitir el procesamiento local de los datos y aun así permitir la transmisión y elaboración de resúmenes para otras oficinas centrales de una corporación. 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 están diseñados para permitir el rastreo de cualquier registro de entrada o proceso llevado a cabo en un sistemas son un método esencial para conservar la integridad y confiabilidad de un sistema,  ya que cuando los analistas desarrollan sistemas tienen que tomar en cuenta la validación del usuario,  las solicitudes de procesamientos y la protección de las transacciones en línea. Aun cuando el procesamiento se difiera un gran tiempo después 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 diseño:           

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

 

Diseño de sistema confiable

Un sistema es confiable si, al usarse de manera razonable no produce fallas peligrosas o costosas. Esta definición 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 fabricación y del equipo, las fallas del software son resultados de errores de diseño 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 fáciles de mantener.

 

Grafica de estructura de programas

Un sistema estructurado modular y desarrollado en forma descendiente, separados en componentes manejables. Los módulos deben diseñarse de forma que tengan un mínimo efecto sobre los demás módulos del sistema

 

Los diagramas de estructura

Es una herramienta de diseño que muestra gráficamente las relaciones entre los módulos de un programa.

 

Información 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.

 

Diseño del software

Seis principios caracterizan a los buenos diseños del software:

 

1. Modularidad y fragmentación: cada sistema va a estar formado por una jerarquía de módulos, los módulos de niveles inferiores son menores en alcance y tamaño comparados con los módulos de nivel superior.

2. Acoplamiento: los módulos de un sistema deben tener poca dependencia entre si.

3. Cohesión: los módulos deben llevar a cabo solo una función de procesamiento

4. Extensión de control: los módulos deben interactuar y coordinar las funciones de un número limitados de módulos de nivel inferior.  

5. Tamaño: las instrucciones contenidas en un modulo debe ser limitadas; el tamaño del modulo es generalmente pequeño

6. Uso compartido: las funciones no deben repetirse en módulos separados sino establecerse en único modulo que se puede utilizar en cualquier otro cuando sea necesario.

 

Diseño del software y herramientas de documentación

 

Diagrama de flujo estructurado

 

Son herramientas graficas que fuerzan al diseñador a estructurar software que sea modular y descendiente

 

Elementos básicos

 

 Existen tres elementos básicos para el desarrollo de los diagramas de flujos estructurados: proceso, decisión e iteración.

 

Proceso: esto se representa mediante un rectángulo y representa la inicialización de variables, actividades de entrada y salida, y las llamadas para ejecutar otros procedimientos.

 

Decisión: este símbolo representa condiciones alternativas que pueden ocurrir y que el programa debe poder manejar.

 

Iteración: representa los ciclos y repetición de operaciones mientras exista una condición dada o hasta que haya una condición.

 

 

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 explícita las relaciones jerárquicas 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 más detalles. Estos fáciles 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 desempeña de forma adecuada y que cumple  con sus requerimientos, el propósito principal de esta es hallar errores, no el demostrar lo correcto de un sistema

 

Verificación y validación:

La verificación tiene la intención de hallar errores a igual que la prueba. Este se lleva a cabo ejecutando un programa en un ambiente simulado.

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

 

Certificación:

Es una garantía de lo correcto de un programa, su importancia va en aumento para las aplicaciones de sistemas de información.

 

Estrategias de prueba:

 

Prueba de código:

Esta examina la lógica del programa. Para seguir  este método, se ejecutan casos de programa para la realización de cada instrucción  en el programa o módulo; es decir, se prueba cada ruta del programa.

 

Prueba de especificación:

Esta se lleva a cabo cuando se examina las especificaciones que señalan lo que el programa debe hacer y cómo 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 módulos, dependientes entre si, localizar los errores esto permite al que realice la prueba detectar errores en el código y lógica contenidos dentro de ese único módulo. Los casos de prueba necesarios para las pruebas parciales deben probar cada condición u opción.

Las pruebas parciales se pueden llevar a cabo en forma ascendente, comenzando con los módulos mas pequeños 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 integración de cada módulo en el sistema. También busca las discrepancias entre el sistema y su objetivo original, especificaciones y documentación del sistema. La preocupación principal es la compatibilidad de los módulos individuales.

 

Pruebas especiales de sistemas

Existen seis pruebas especiales que son: la prueba de carga máxima, almacenamiento, tiempo de ejecución, recuperación, 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 común de datos de prueba cuidadosamente preparados.

Las fallas en la prueba se muestran rápidamente cuando el sistema se implanta.

 Administración de proceso de implantación del sistema

 

Capacitación:

 

La implantación de un  nuevo sistema en una empresa es una situación que debe pensarse debido a que no se sabe el impacto que va a tener el nuevo sistema en los demás 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 tecnologías están en nuestros hogares y es difícil conseguir  a empleados que no tengan ningún tipo de relación con una computadora, y lo mas importante es que ahora no les tienen miedo  sabes y están concientes que ellas le van a aminorar el trabajo además de optimizarlo.

Algo bien importante a la hora de implantar un sistema nuevo es la capacitación del personal operador del sistema, yendo desde los conceptos mas básicos de computación como lo pueden ser hardware y software, generalidades del procesamiento de datos.

También se le debe entrenar o capacitar directamente con el sistema, la navegación por el mismo, por sus menús, funciones, características. También se le debe capacitar con lo que esta relacionado con los almacenamientos de registros, datos, entrega de reportes,  impresión de salidas. una vez dado este aprendizaje previo se le deja utilizar el sistema bajo una supervisión.

La implantación 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  implantación 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 implantación aunque el sistema se optimo este no rendirá como lo pudiese hacer.

Existen dos etapas  para el momento de la capacitación como son : la capacitación del personal como hicimos una breve reseña anteriormente, y los procedimientos de conversión y revisión después de la implementación.

 

Capacitación:

Explicando mejor esta parte ya que pensamos que es súper importante para que el sistema fluya de la mejor manera,  es importante que cada una de las personas que estén involucradas con el sistema conozca cada detalle sus roles, que hará y que no hará el sistema.

¿Cómo capacitar a los operadores del sistema?

Siempre es importantísimo que el departamento de computo este súper 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 día a día. Si la implantación necesita una nueva plataforma tecnológico, nuevos equipos, etc. si es necesario enseñarle 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 creándole una lista de estos con sus posibles soluciones, así como también los números telefónicos de las personas que realizaron el sistema por si ocurre algo que no sepan como resolver. Muy importante es también capacitarlo o famirializarlo con los procedimientos del sistema, como puede ser la creación de archivos, facilitar la rápida navegación por el sistema entre otras cosas.

 

Algo que es muy importante también es la capacitación que se le tiene que dar al usuario.

Capacitación del usuario:

Esta capacitación también tiene que venir desde lo mas básico como puede ser la introducción 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, también hay que capacitarlos con el reconocimiento de los errores ya que así ellos sabrán si el error es producido por su culpa o por problemas de software. La mayor parte de la capacitación de usuario es con el trato específicamente con el sistema, enfatizando con los estándares de la captura de datos. También es importante que sepa como utilizar los periféricos 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 información que requerirá el usuario.

Estas clases o cursos de capacitación  pueden llevarse a cabo desde la mima empresa donde se esta implantando como también el  en hoteles  o sitios ajenos a la empresa ya que puede ser que el proveedor  haga uso del sistema también.

 

 

Conversión:

Este es el proceso de cambiar el sistema anterior  al nuevo, existen nos métodos para el logro efectivo de esta conversión.

Existen 4 métodos para llevar a cabo esta conversión, estos métodos deben ser estudiados con cuidado para que así se implante el método que mejor se le encaje a la conversión.

 

Métodos de conversión:

Sistemas paralelos: es el método 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 obligándolo 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 también el nuevo sistema sea rechazado por los usuarios y se vuelva al sistema anterior.

Conversión directa: este tipo de conversión se hace de manera radical debido que se hace de un día a otro obligando tanto físico como psicológicamente 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, también 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 cuestión de tiempo perdido. Este método necesita una buena planificación, para que así no exista perdida de ningún tipo.

Enfoque piloto:   este método funciona de la siguiente manera, tenemos el sistema pero solo se lo aplicamos a un departamento a manera de prueba para así también ir probándolo y mejorándolo 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 método se da debido a la tardanza de la llegada del nuevo sistema que pasara de días  a meses y es por eso que solo algunos tendrán 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 conversión:

 

Esto no es mas que hacer un plan donde se explique o salga explicito las personas que están involucradas con el nuevo sistema y que responsabilidad tiene con el, programas de actividades, cuando debe llevarse a cabo una situación cuando otra, todos los archivos que van a ser convertidos, los datos necesarios para estos archivos, nuevos procedimientos, etapas de verificación para así ver si cada uno de las personas o el sistema esta trabajando al día, las asignaciones de responsabilidades, así como también el tiempo para cada rutina para que al final se haga la nueva implantación  de la manera mas estable  que es con la que se planeo. Este plan también 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.

 

 

Preparación 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 información se haga de manera segura que no haya errores ya que repercutirán después 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 transacción 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 están los 1000 archivos.

 

Revisión después de la implementación:

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. Después 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 través 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.

 

 

Administración del proceso de desarrollo de sistemas de información

Todo proyecto exitoso de sistemas de información  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 desempeño.

 

Estimación y control del tiempo de desarrollo:

un desarrollo tardía de un proyecto es un poco desanimante para los usuarios  es por eso que continuación le presentaremos un método para el mejor desarrollo de la planificación de el tiempo.

      Estimación  de los requerimientos del tiempo:

Las estimaciones son las horas, meses, días, 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.

Método de estimación del tiempo:

Existen tres métodos para la estimación del tiempo de desarrollo del proyecto.

        Método histórico: se trata de los registros cuidadosos que tienen de realizaciones de proyectos anteriores, con todas sus características pa que sean después comparados con los actuales y así se pueda hacer la estimación, es por eso que no es el mas utilizado ya que es difícil mantener los registros tan rigurosos y además el proyecto nuevo debe ser muy parecido al antiguo para que la estimación  sea de confiar.

        Método intuitivo: es el método que lo lleva a cabo las personas con mas antigüedad en la empresa y con mas experiencia con proyectos. Este método es bastantemente utilizado ya que es rápido pero dependiendo de la experiencia de la persona será preciso.

        Método estándar: este va a venir determinado por el estudio detallado de cada proceso  y cada peso individual y después a través de una formula aritmética especifica que nos llevara al resultado mas acertado y confiable

Para realizar cualquiera de estos métodos es necesario tomar en cuenta cada uno de los detalles del proyecto debido a que  son muy importantes para la buena estimación (desde el momento en que se decide hacerse el proyecto, pasando por el lenguaje de programación a utilizar hasta su implementación).

Es recomendable la utilización de software de programación de proyectos como puede ser el MS. Project.

 

Administración del personal:

Es muy importante la selección de buenos equipos de trabajo y saber además 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 diseño. El programador de respaldo es quien tiene las opciones alternativas, una persona con diseño 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 supervisión 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 agrupación   también tiene su programador en jefe y el de respaldo

Equipos sin liderazgos:  a diferencia de los demás  este tipo de agrupación no tiene ninguna figura de líder establecida, esta lo que hace es dejar fluir el grupo y se ve que poco a poco va a surgir un jefe o líder 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 más que una revisión detallada, y planificada de un sistema o software. Generalmente están involucradas en ella las personas que lo crearon, los jefes de departamento esta revisión tiene unas características  y son las siguientes:

El propósito de este recorrido es hallar las áreas en las que se puede mejor el proceso.

El proceso de revisión no se afinca en la reparación de errores si no en la optimización de ellos. Siempre la organización designa a como que un líder para esta revisión, 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 están dando cuenta de lo importante que es seguir con un estándar para todo ya que así su revisión va a ser mas fácil, y de mantenimiento para futuros grupos de revisión.

 

Revisión de los requerimientos:

Esto es la revisión 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 diseño para así poder atacar este problema.

 

Revisión de diseño:

Este recorrido es por la parte lógica del diseño, para ver si cumple con las necesidades efectivamente. si lo usuarios muestran una insatisfacción con el resultado  esto lo re estudiara el analista.

 

Revisión del código:

Aquí se revisa los módulos principales de el código 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 verán frustrados con un sistema vago.

 

Revisión 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 opinión objetiva dar observaciones objetivas debido a su experiencia, dar información técnica acerca de un tema en específico, 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.

 

Selección 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 instalación de red se nos hace muy difícil la elección del equipo. Existen muchas características que se deben tomar en cuenta como por ejemplo: la memoria, velocidad de procesamiento, canales de comunicación, almacenamientos auxiliares entre otras cosas. Así como también una buena configuración, niveles de acceso,. Es necesario también  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 técnico de las maquinas, etc.

Otra opción pudiese ser el rentar el equipo, y en el momento que este obsoleto se cambia el equipo sin ningún problema, pero es muy costoso este tipo de solución. También 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 garantías, o por sencillamente el equipo vino con algún defecto de fabrica  ellos se harán responsables esta garantía será de 90 días o bien dependiendo de el trato llegado en la negociación. 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 después se pierda por que se le dejo morir.

 

Selección del software:

Esta selección es muy importante al igual que la selección del software. Para la elección del software es necesario tener encuesta el sistema que se va a implantar,

para así ver cual software  es el más adecuado. Lo mas esencial al momento de la elección 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 característica especifica que deba ser atendida por alguna aplicación 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. También se busca que el software tenga algun tipo de soporte técnico 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.