Ingeniero Técnico en Informática de Sistemas

Desarrollo de Proyectos

Compartir 0 Me sirvió 0 No me sirvió

APUNTES DE LA MATERIA: DESARROLLO DE PROYECTOS

CARRERA: LIC. EN INFORMATICA.

ALUMNO:

ADVERTENCIA: SE AUTORIZA LA REPRODUCCION TOTAL O PARCIAL DE ESTE MATERIAL SIN FINES DE LUCRO.

TEMARIO

I Detección de Necesidades

II Definición del Problema

III Estudio de Factibilidad

IV Elaboración del Proyecto

V Documentación

Unidad I

Evolución del Sw.

Primeros años

Orientaciones por lotes
Distribución limitada
Sw a medida

Segunda era

Multiusuario
Tiempo real
B.D.
Sw como producto

Tercera era

Sistemas distribuidos
Incorporación de inteligencia
Hw bajo costo
Impacto en el consumo

Cuarta era

Potentes sistemas
Tecn. Orientados a objetos
Sistemas expertos
Comp. Paralela

Características del Sw

Para poder comprender que es el sw es importante examinar las características que lo diferencian de las otras cosas que los hombres pueden construir. El sw es un elemento del sistema que es lógico en lugar de físico. El sw tiene una característica considerable distintivas a las del hw:

El sw se desarrolla, no se fabrica en un sentido clásico
El sw no se estropea
La mayoría del sw se construye a medidas, en vez de ensamblar componentes existentes.

Componentes del SW

El sw de computadoras en formación existen 2 formas básicas:

Componentes ejecutables de las maquinas
Componentes no ejecutables de las maquinas
Los componentes de sw se crean mediante una serie de traducciones que hacen corresponder a los requisitos del cliente con un código ejecutable en la maquina. Se traduce un modelo (prototipo de requisitos a un diseño). Se traduce el diseño del sw a una forma en un lenguaje que especifica la estructura de datos. Los atributos procedimentales y los requisitos del sw. La forma del lenguaje es procesado por un traductor que la convierte en instrucciones ejecutables en la maquina.

Los componentes del sw se construyen mediante un lenguaje de programación que tienen un vocabulario limitado, una gramática definida explícitamente y reglas bien formada de sintaxis y semántica.

Aplicaciones del sw

El sw puede explicarse en cualquier situación en la que haya definido previamente un conjunto especifico de procedimiento. Para determinar la naturaleza de una aplicación de sw hay 2 factores importantes que se deben considerar: EL CONTENIDO Y EL DETERMINISMO DE LA INFORMACION.

El contenido se refiere al significado y a ala información de E/S.

El determinismo de la información se refiere a la predicibilidad del orden y del tiempo de llegada de los datos. Un programa de ing. Acepta datos que están en orden predefinido, ejecuta el algoritmo sin interrupción y produce los datos resultantes en un informe o formado gráfico. Se dice que tales aplicaciones son determinadas.

Areas del sw

Sw de sistemas: es un conjunto de programas que han sido escritos para servir a otros programas (ejemplo: interpretes, traductores, editores, compiladores)
Sw de tiempo real: mide, analiza, controla sucesos del mundo real conforme ocurren por ejemplo, una maquina que recolecta la información comercial recibida del entorno externo y a través de monitorización de una respuesta de tiempo real.
Sw de Gestión: accede a una o más base de datos grande que contiene la información comercial además de realizar cálculos interactivos como el procesamiento de transacciones en puntos de venta.
Sw de Ing y Científico: esta caracterizado por algoritmos de manejo de números, simulación de sistemas y aplicaciones interactivas (autocat, gpss/h)
Sw exportado: este reside en memoria de solo lectura y se utiliza para controlar productos y sistemas.
Sw de PC: abarca desde el procesamiento de textos, hojas de cálculo, gráficos, aplicaciones de uso comercial.
Sw de Ing Artificial: hace uso de algoritmos no numéricos para resolver problemas complejos para lo que no son adecuados en análisis directos. Podemos citar los sistemas expertos, patrones de reconocimiento de imagen y voz o las redes neuronales artificiales (simulando la estructura del proceso del cerebro).

Configuración del Sw

Ing. Del Sw

La Ing. Del Sw abarca conjuntos de 3 elementos claves que son:

Métodos
Herramientas
Procedimientos

Que facilitan controlar el proceso del desarrollo del sw y suministrar las bases para construir sw de alta calidad de una forma productiva.

Métodos de la Ing. Del Sw

Indica como construir técnicamente un sw. Los métodos incluyen planificación y especificación del proyecto, el análisis de los requisitos del sistema y del Sw, diseño de la estructura de datos, arquitectura de programas, procedimientos algoritmicos, codificación, prueba y mantenimiento.

Herramientas de la Ing. Del Sw

Suministra un soporte automático o semiautomático para los métodos.

Procedimientos de la Ing. Del Sw

Son el pegamento que junta a los métodos y las herramientas y facilitan un desarrollo racional y oportuno del sw de la computadora. Los procedimientos definen la secuencia en la que se aplican los métodos, las entregas que se requieren, los controles que ayudan a asegurar la calidad y coordinar los cambios.

La Ing. Del Sw esta compuesta por una serie de pasos que abarcan los métodos, las herramientas y los procedimientos. Estos pasos se denominan frecuentemente Paradigma de Ing. Del Sw.

El paradigma del ciclo de vida exige un enfoque sistemático y secuencial del desarrollo de Sw que comienza en un nivel del sistema y progresa a través del análisis, diseño, codificación, prueba y mantenimiento. El ciclo de vida abarca las siguientes etapas:

Ing. Y Análisis del Sistema: El trabajo comienza estableciendo los requisitos de todos los elementos del sistema. Este planteamiento del sistema es esencial cuando el sw se relaciona con otros elementos como Hw, B.D. y personas.
Análisis de los requisitos del sw: el proceso de recopilación de los requisitos se centra especialmente para el Sw.
Diseño: el diseño se enfoca sobre 4 atributos distintos de programa: la lectura de datos, arquitectura del Sw, el detalle procedimental y la caracterización de la interfaz.
Codificación: el diseño se traduce en una forma legible para la maquina
Prueba: la prueba se centra en la lógica interna del sw aceptando que todas las sentencias se han probado y asegurar que la entrada definida producen los resultados que realmente se requieren.
Mantenimiento: el sw sufrirá cambios después de que se le entregue al cliente.

Construcción de prototipos

Es un proceso que facilita al programador la creación de un modelo de sw a construir. El modelo tomará una de las siguientes tres formas:

Un prototipo en papel que describa la interacción hombre - maquina de forma que facilite al usuario la comprensión de cómo se producirá tal interacción.

Un prototipo que implemente algunos subconjuntos de la función requerida del programa deseado.

Un programa existente que ejecute parte de toda la función deseada pero que tenga otras características que deba ser mejorada en el nuevo trabajo de desarrollo.

Modelo en Espiral

Planificación.- Determinación de objetivos alternativas y retricc.

Análisis de Riesgo.- análisis de alternativas e identificación y resolución de riesgos

Ingeniería.- Desarrollo de productos del siguiente nivel

Evaluación del Cliente.- Valuación de los resultados de la Ingeniería.

Elementos del Sistema

Sistema basado en Computadora.- Conjunto u ordenación de elementos organizados para llevar a cabo algún método, procedimiento o control mediante el procesamiento de información.

SW.- Programa de computadora, estructura de datos y la documentación asociada para realizar algún método lógico. Procedimiento o control requerido.

HW.- Dispositivos electrónicos y electromecánicos que proporcionan la capacidad de computación y dispositivos electromecánicos que proporcionan las funciones del mundo exterior.

Gente.- Individuos que son usuarios y operadores de sw-hw

B.D..- Colección de información que accede mediante sw y que es una parte integral del funcionamiento del sistema.

Documentación.- Manuales impresos e información descriptiva que explica el uso y/o la operación del sistema.

Procedimientos.- Pasos que definen el uso especifico de cada elemento del sistema o el contexto procedimental en que reside el sistema.

Análisis del Sistema

El análisis del sistema se realiza teniendo presente los siguientes objetivos:

Identifica las necesidades del cliente

Evaluar la Factibilidad del sistema

Realizar un análisis técnico y económico

Asignar funciones al sw, hw y otros elementos del sistema

Restablecer restricciones de costo y tiempo

Crear una definición del sistema que sea la base para todo el trabajo posterior de ingeniería.

En el análisis del sistema todavía surgen 3 preguntas:

¿Cuánto esfuerzo se debe emplear en el análisis y en la definición del sistema y de sw?

El tamaño del sistema en su complejidad, el área de aplicación, el uso final y las obligaciones del contrato son solo una de muchas variables que afectan al esfuerzo focal dedicado al análisis.

¿Quién lo hace?

Todas las tareas han de ser dirigidas por un analista bien formado y con experiencia ya que trabaja en contacto con el personal técnico y administrativo.

¿Por qué es tan difícil?

Porque durante el análisis la comunicación es densa, abundan las oportunidades de mal entendimiento, inconsistencia y errores.

Identificación de necesidades

El primer paso del proceso del análisis del sistema implica la identificación de necesidades. El analista se entrevista con el cliente o su representante, la identificación de necesidades es el punto de partida en la evaluación de un sistema basado en computadora.

Información requerida por el analista

Funcionamiento y requerimientos
Aspectos de la fiabilidad
Fines grales. Del sistema
Limitación del costo
Requisitos de fabric.
Mercado y competencia
Tecn. Disponible
Ampliaciones futuras

Para empezar el analista da asistencia al cliente definiendo los objetivos del sistema, la información que se va a obtener, la información que se va a suministrar, las funciones de rendimiento requerido. El analista se asegura de distribuir entre lo que necesita el cliente y lo que el cliente quiere.

Una vez que se han identificado todos los objetivos, el analista pasa a la evaluación de la información suplementaria: ¿existe la tecnología necesaria para construir el sistema? ¿Qué recursos de fabricación y desarrollo especiales se requerirán? ¿Qué limites se han impuesto al costo?

Actividades de la determinación de necesidades

Anticipación.

Proveer las características del sistema con base en la experiencia previa. Esto puede llevar al analista a investigar áreas y aspectos que de otra forma no serían tomados en cuenta.

Investigación.

Estudio y documentación del sistema actual utilizando para ello técnicas para hallar hechos análisis de flujo de datos y análisis de decisión.

Especificación.

Análisis de los datos que describen el sistema para determinar que tan bueno es us desempeño, que requerimientos se deben satisfacer y estrategias para lanzarlo.

TECNICAS PAPA ENCONTRAR HECHOS

Los analista.5 utilizan métodos especificas, denominados técnicas para encontrar hechos, con el objeto de reunir datos relacionados con los requerimientos. Entro estos se incluye la entrevista, el cuestionario, la revisión de los registros y la observación. En general, los analistas emplean más de una de estas técnicas para estar seguros de llevar acabo una investigación amplia y exacta.

ENTREVISTAS

Los analistas emplean las entrevistas para reunir información provenientes de personas o de grupos. Por lo común, los entrevistados son ususarios de los sistemas existentes o usuarios en potencia de¡ sistema propuesto. En algunos casos, los entrevistados son gerentes o empleados que proporcionan datos para el sistema propuesto o que serán afectado por él. 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 requiere de tiempo es necesario utilizar otros métodos para optener la información necesaria para conducir una investigacion.

Es importante recordar que los entrevistados y los analistas conversan durante una entrevista, es decir no se interroga a los primeros.

Las entrevistas dan a los analistas oportunidades para reunir informacion de las personas que han seleccionado debido a su conocimiento de¡ sistema que esta bajo estudio.

ENTREVISTA ESTRUCTURADA

Las entrevistas estructuradas utilizan preguntas estándar en un formato de respuesta abierta o cerrada. El primero permite que el entrevistado dé respuestas a las preguntas con sus propias palabras; el segundo utiliza un conjunto anticipado de respuestas.

VENTAJAS

1. Asegurar términos uniformes en las preguntas para todos los entrevistados.

2. Fácil de administrar o evaluar.

3. Evaluación más objetiva de preguntas y respuestas por parte de los que participan en la entrevista.

4. Se necesita un entrenamiento limitado por parte de¡ entrevistador.

5. Se obtiene resultados con entrevistas cortas.

DESVENTAJAS

1. El costo de la preparación es alto.

2. Es posible que los entrevistados no acepten un alto nivel en la estructura y planteamiento metálico de las preguntas.

3. El alto nivel de la estructura quizá no sea el mas adecuado para todas las situaciones.

4. El alto nivel de la estructura disminuye tanto la espontaneidad como la habilidad de¡ entrevistador para seguir los comentarios durante la entrevista

ENTREVISTA NO ESTRUCTUPADA

Las entrevistas pueden clasificarse como estructuradas o no estructuradas, las entrevistas no estructuradas utilizan un formato pregunta-rer>puesta y son apropiadas cuando el analista desea adquirir informacion general a cerca de un sistema.

VENTAJAS

1. El entrevistador tiene mayor flexibilidad para cambiar los términos de las preguntas para que se acomoden mejor al entrevistado.

2. El entrevistador puede ahondar en áreas que aparesen de manera espontáneas durante la entrevista

4. La entrevista puede proporcionar información relacionadas con áreas que en un principio no fueron tomadas en cuenta.

DESVENTAJAS

1. El entrevistador puede introducir sus propios sesgos en las preguntas o a notificar

los resultados. y

2. Se puede obtener información ajena al problema.

CUESTIONARIOS

El uso de cuestionario 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 pueden proporcionar datos mas contables 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 nos permite al analista observar las expresiones o reacciones de los encuestados a si mismo la respuesta puede ser limitada ya que es posible que no tenga mucha importancia para los encuestados llenar los cuestionarios.

Con frecuencia los analistas utilizan cuestionarios abiertos para descubrir sentimientos, opiniones y experiencias para explorar un problema.

Los cuestionarios cerrados controlan el marco de referencia al presentar a los encuestados respuestas especificas para escoger. Este formato es apropiado para obtener información basada en hechos reales.

RE'VlSION DE LOS REGISTROS

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 de¡ estudio, coiyio introducción, a también después, y sirve de base para comparar las operaciones actuales, por lo tanto los registros pueden indicar qué está 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 la realidad, donde se encuentra todo el poder de la toma de decisiones, o cómo se realizan todas las tareas.

OBSERVACION

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, Este método es más útil cuando el analista necesita observar, 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 qué buscar y cómo evaluar la significancia de lo que observan.

Solicitud del proyecto

¿Cuál es el problema?

Detalles del problema

Importancia del problema

¿Cuál cree el usuario que sea la solución?

En que forma será de ayuda un S.I.

¿Qué otras personas tienen conocimiento del problema y si pueden contactar?

Diagrama de Barras

La planificación más simple usa diagramas de barras que muestran cada actividad en un proyecto de sistema y la cantidad de tiempo que se tomará dicha actividad. Este método emplea barras para indicar la cantidad de tiempo usada en cada tarea.

El analista identifica primero cada tarea y estima la cantidad de tiempo necesaria para ella.

Los diagramas de barras son más manejables si el proyecto consta de un número limitado de tareas o actividades.

Unidad II

Definición del problema

El problema debe de ser significativo, viable y tiene que estar claramente formulad. Para abarcar el problema es necesario contar con los conocimientos requeridos y con una experiencia en el tema que lo califique como investigador capaz de comprometerse con la profundidad necesaria.

Es imprescindible que su curiosidad personal como investigador de problemas este involucrado, que realmente tenga el deseo de resolver un problema para contribuir al conocimiento para cambiar una situación social o para mejorar una condición. Muchas veces se ha dicho que un problema bien definido esta resuelto en un 50 %.

Antes de definir el problema es necesario hacer una introducción referida del mismo. La introducción debe de ser pequeña. Despertar el interés del lector y presentar la información que este necesita para comprender el problema que se intenta solucionar en la investigación. Esta parte debe de ser breve, suave, fina y moderada para evitar lo tedioso de un trabajo extenso y un posible choque de detalles técnicos. Puede ser de un párrafo paro nunca mas de 3 cuartillas.

Inmediatamente después de la introducción el investigador debe de exponer el problema concreto sobre el cual se hará la investigación. El problema en si debe estimularse en una sola oración como conclusión final a la introducción que se le halla dado al trabajo. Esta oración debe estar redactada con una estructura sencilla y n debe incluirle posibles detalles o subtemas del problema. El enunciado puede redactarse en forma de pregunta pero no debe de incluir varias preguntas.

Uno de los errores más comunes en las introducciones es que la redacción no va al grano, no indica cual es el punto fundamental. El otro error es que generaliza demasiado, es decir, no se le indica la importancia especifica del problema en relación con la teoría o con la práctica del área en cuestión.

PLANEACION DEL PROYECTO

El objetivo de la planificación de¡ proyecto de software es el de suministrar una estructura que permita al director hacer estimaciones razonables de recursos, costos.

La primera actividad de la planificación del proyecto de software es determinar el ámbito del software. Se deben evaluar la función y el rendimiento asignado al software durante la ingeniería del sistema de computadora, con el fin de establecer un ámbito de¡ proyecto que no sea ambiguo ni incomprensible a nivel de directivos y técnicos. La especificación del ámbito de¡ software debe estar delimitado, es decir, han de establecerse explícitamente los datos cuantitativos (número de usuarios), las restricciones y/o limitaciones (costo de¡ producto).

El ámbito del software describe la función, rendimiento, restricciones, interfaces y la factibilidad.

Las funciones descritas en la especificación se evalúan y en algunos casos se refinan para dar mas detalle antes de¡ comienzo de la estimación.

Las consideraciones de rendimiento abarcan los requisitos de tiempo y respuesta y de procesamiento.

Las restricciones identifican limites de¡ software debido al hardware externo o la memoria disponible y a otros sistemas existentes.

La segunda tarea de la planificación del desarrollo de software es la estimación de los recursos requeridos para acometer el esfuerzo de desarrollo de software.

El plan comienza evaluando el ámbito y seleccionando las habilidades técnicas que se requieren para llevar a cabo el desarrollo. Para proyectos pequeños una sola persona puede llevar a cabo todos los pasos de ingeniería del software, consultando con especialistas siempre que lo requiera.

Durante la planificación del proyecto del software se deben considerar tres categorías de hardware: el sistema de desarrollo, la máquina objetivo y los demás elementos del hardware del nuevo sistema.

El sistema de desarrollo esta compuesto por la computadora que se utilizará durante la fase de desarrollo del software y sus periféricos asociados.

En otra parte inicial no se requieren citas o referencias extensas.

En la base se encuentran las herramientas existentes para dar soporte al esfuerzo de desarrollo, en el nivel más alto se encuentra el recurso primario que se requiere simpre, gente.

Herramientas automáticas

Herramientas de planificación de sistemas de gestión.

Mediante la modelización de los requisitos de información estratégica de una organización, estas herramientas proporcionan un “metamodelo” del cual se pueden obtener sistemas de información específicos, el objetivo principal de las herramientas de esta categoría es ayudar a comprender mejor como se mueve la información de las distintas unidades organizativas.

Herramientas de gestión de proyectos.

Hoy en día, la mayoría de las herramientas CASE de GESTION DE PROYECTOS se centran en un elemento especifico de la gestión de proyectos en lugar de proporcionar un soporte global para la actividad de gestión. Utilizando un conjunto seleccionado de herramientas CASE, el director del proyecto puede hacer estimaciones útiles del esfuerzo, costo y duración de un proyecto, definir una estructura de participación del trabajo “EPT” y hacer una planificación realista del mismo y hacer el seguimiento de proyectos de forma continua.

Herramientas de soporte.

La categoría de herramienta de soporte engloba las herramientas de aplicación y de sistemas complementan el proceso de Ing. De Sw. Las herramientas que caen en esta amplia categoría recogen las actividades aplicadas en todo el procesos de Ing. De Sw. Estas incluyen herramientas de documentación, herramientas para gestión de redes y sw de sistemas, herramientas de control de calidad, herramientas de gestión de B.D. y de configuración del sw.

Herramientas de análisis y diseño.

Estas permiten al Ing. De sw crear un modelo de sist. Que se va a construir. El modelo contiene un representante de los datos y del flujo de control del contenido, representaciones de los procesos específicos de control y otras representaciones del modelo. Estas herramientas permiten la creación de un modelo y también la evaluación de la calidad de un modelo. Mediante la comprobación de validez y la consistencia del modelo, estas herramientas proporcionan al Ing. Cierto grado de confianza en la representación del análisis y ayuda a eliminar errores antes de que se propaguen al diseño o al código mismo.

Herramientas de integración y prueba

Estos definen las siguientes categorías:

Adquisición de datos: herramientas que adquieren datos para ser usados durante la prueba.
Medición técnica: analizan el código fuente sin ejecutar de prueba.
Medición dinámica: analizan el código fuente durante la ejecución.
Simulación: simulan la función del hw o de otros elementos externos.
Gestión de pruebas: ayudan a la planificación, el desarrollo y control de las pruebas.
Herramientas de funcionalidad cruzada: realizar varias de las funciones anteriores.

Herramientas de creación de prototipos

Todas las herramientas de creación de prototipos se sitúan en el lugar del espectro de implementación en la parte baja del espectro. Hay herramientas para la creación de un “prototipo en papel”.

Herramientas de mantenimiento

Estas herramientas pueden subdividirse de la sig. Forma:

Herramientas de Ing. Inversa a especificaciones: toman el código fuente como entrada y generan modelo de diseño y análisis estructurado. Listas de utilización y otra información relacionada con el diseño.
Herramientas de estructuración y análisis de código
Herramientas interactiva de reingeniería de sistemas: se utiliza para modificar sistemas de B.D.

Herramientas de estructura

Tienen componentes funcionales para el tratamiento de datos, e interfaces y con capacidad de integración con otras herramientas.

Para realizar estimaciones seguras de costos y esfuerzos tenemos varias opciones posibles.

Estimación del proyecto del Sw

Dejar la estimación para más adelante, el esfuerzo del proyecto.

Utilizar técnicas de descomp. Relativ. Senc. Para generar la estimación del costo y

Desarrollar un modelo empírico para el cálculo de costo y esfuerzo del sw.

Adquirir una o varias herramientas automáticas de estimación.

Técnicas de descomposición.

La estimación de proyectos del sw es una forma de resolución del problema y en la mayoría de los casos el problema a resolverse es demasiado complejo para considerarlo como una sola parte, por esta razón se descompone el problema recaracterizandolo como un conjunto de pequeños problemas.

Modelo de estimaciones.

El modelo de estimación utiliza formulas empíricamente para poder predecir los datos que se requieren en el paso de planificación del proyecto del sw. Los datos empíricos que soportan la mayoría de los modelos se obtienen de una muestra del proyecto limitada, por esta razón un mismo modelo de estimación no es adecuado para todas las clases de sw ni para todos los entornos de desarrollo.

Los modelos de recurso consisten en una forma o varias ecuaciones obtenidas empíricamente que predicen el esfuerzo, la duración del proyecto y otros datos relativos al proyecto.

Herramientas automáticas de estimación.

Permiten estimar costo y esfuerzos, así como llevar a cabo análisis de tipo “Que pasa si” con importantes variables del proyecto, tales como la fecha de entrega o la selección del personal.

Muchas herramientas automáticas de estimación requieren una o más de las sigs. Clases de datos:

Una estimación cuantitativa del tamaño del proyecto o de la funcionalidad.

Característica cualitativa del proyecto tales como la complejidad, la fiabilidad requerida o el grado crítico del negocio.

Alguna descripción del personal de desarrollo y/o el entorno de desarrollo.

A partir de estos datos el modelo implementado por la herramienta automática de estimación proporcionará estimaciones del esfuerzo requerido para llevar a cabo el proyecto de los costos y de la carga del personal.

Recursos del Sw

Al igual que se utiliza más Hw para construir nuevo Hw se puede utilizar Sw como ayuda en el desarrollo del nuevo Sw.

La Ing. Del sw utiliza un conjunto de herramientas que son parecidas a las que utilizan los Ing. Del hw en el diseño y la Ing. Asistido por computadora.

Ingeniería del sw asistido por computadora.

Descomposición: Requiere un embozo de las principales funciones del sw.

Modelo de estimación: Usan exp. Empíricamente p/ predecir datos.

Automática: Implementa un modo empírico.

Análisis de riesgo

Consideraciones.

¿Cuáles son los riesgos que pueden hacer que fracasen los proyecto de sw?

¿Cómo afectan al éxito global a los plazos los cambios de requerimientos del cliente, en las Tecnologías de desarrollo y en todas las entidades relacionadas con el proyecto?

¿Qué métodos y herramientas debemos usar, cuanta gente debe estar involucrada, cuanta información hay que darle a la calidad?

Actividades.

Identificación de riesgos
Riesgo del proyecto
Cálculo del riesgo
Gestión del riesgo

Identificación del riesgo: consiste en enumerar los riesgos concretos del proyecto.

Clasificación del riesgo.

Riesgo del proyecto: identifican riesgos presupuestarios de personal de recursos cliente y requisitos.
Riesgos técnicos: identifican problemas de diseño implementación, interfaz verificación y mantenimiento.
Riesgos del negocio: son indicios porque pueden llevar los resultados a mejores proyectos del sw.

Ejemplo: RIESGO DE ASIGNACION DE PERSONAL

Se dispone del mejor personal
Tiene el personal un conjunto de habilidades adecuadas
Se dispone de la gente suficiente
A recibido el personal entrenamiento adecuado
Esta comprometido el personal a lo largo de todo el proyecto

Proyección del riesgo: también conocida como estimación del R. Intenta evaluar el riesgo en dos formas:

La probabilidad de que el riesgo sea real
Las consecuencias de los problemas asociados con el riesgo

Actividades de proyección de riesgo:

Establecimiento de una escala que refleja la probabilidad observada del riesgo.

Definición de las características del riesgo.

Estimación del impacto del riesgo en el proyecto.

Anotación de la exactitud gral. De la proyección del riesgo.

Evaluación del riesgo: durante la evaluación del riesgo se examina la exactitud fr las estimaciones que se han realizado durante la proyección de riesgo, se intenta dar prioridad a los riesgos que no se han cubierto y se comienza a pensar en las formas de controlar y/o prevenir los riesgos que tengan probabilidad de ocurrir.

Gestión de riesgo: la supervisión de riesgos es una actividad del seguimiento del proyecto con 3 objetivos básicos:

Detectar la ocurrencia de un riesgo que halla sido previsto.

Asegurar que los pasos de gestión del riesgo definido para cada riesgo se estén analizando efectivamente.

Recopilar información que se pueda utilizar para futuros análisis de riesgo.

Planificación temporal del proyecto.

Planificación Temporal.

¿Cómo hacer corresponder el tiempo cronológico con el esfuerzo humano?

¿Qué tareas se pueden encontrar?

¿se dispone de métodos de análisis para la planificación temporal?

Relaciones cliente - trabajo

Definición de tareas.

Cuando en el proyecto están involucrados más de una persona las características de desarrollo se pueden realizar en paralelo.

El análisis y la especificación son as primeras tareas que se deben realizar y son la base para el paralelismo en las tareas posteriores.

Una vez identificado y examinados los requisitos comienzan la distribución del esfuerzo. El esfuerzo gastado en el análisis o en la creación de un prototipo deben crecer en proporción directa al tamaño y a la complejidad del proyecto.

Métodos de planificación temporal.

Técnicas de evaluación y revisión de prog. (PERT)
Método de camino crítico (CPM)

Técnicas

Desarrollan una descripción de la red de las tareas del proyecto, es decir, una representación gráfica o tabular de las tareas que deben meterse desde el principio hasta el final del proyecto.

Estas técnicas permiten al planificador del sw.

Determinar el camino crítico (secuencia de tareas que determina la duración total del proyecto).

Establecer estimaciones de tiempo más probables para las tareas individuales con la aplicación de modelos estadísticos.

Calcular los limites de tiempo que definen “ventana temporal” para cada tarea individual.

Seguimiento y control del proyecto.

El seguimiento se puede llevar a cabo:

Realizando reuniones periódicas sobre el estado del proyecto.
Evaluando los resultados de todas las revisiones realizadas en el proceso.
Reuniéndose periódicamente para conocer las valoraciones acerca del progreso de cada momento.

Los administradores del proyecto de sw utilizan el control para administrar los recursos del proyecto para hacer frente a los problemas y para dirigir al personal del proyecto.

El plan del proyecto del sw se produce como culminación de la etapa de planeación.

Plan del proyecto de Sw

Definir los riesgos y sugerir técnicas para el riesgo
Comunicar el ámbito y los recursos a los gestores de sw personal técnico y al cliente
Definir el costo para la revisión de la gestión
Proporcionar un enfoque global del desarrollo del sw para toda la gente involucrada en el proyecto.

HERRAMIENTAS PARA DOCUMENTAR PROCEDIMIENTOS Y DECISIONES

Seguir procedimientos y tomar decisiones son aspectos importantes de cualquier empresa. De hecho, la administración misma es, esencialmente, toma de decisiones. Algunas, como aceptar o no ofertas, afectan a todas las organizaciones. Otras, como decidir cuándo volver a pedir materiales para el almacén, dependen de pocas personas y siguen procedimientos paso por paso. Sin embargo, las decisiones y procedimientos son de importancia para el analista cuando éste conduce una investigación de sistemas dentro de la empresa. (El desarrollo de un sistema para reabastecer el inventario, por ejemplo, sin examinar la decisión sobre qué cantidad de un determinado artículo incluir en el pedido, puede conducir a un desastre.)

Esta sección examina varias herramientas para el estudio de procedimientos de operación y de los pasos a seguir para la toma de decisiones junto con los medios para documentar estos aspectos en el estudio. Una herramienta es cualquier dispositivo, objeto u operación utilizada para ejecutar una tarea específica. El analista de sistema depende de las herramientas para realizar su trabajo de la misma manera que otras personas de sus actividades cotidianas. Por ejemplo,

ANALISIS Y DETERMINACION DE REQUERIMIENTOS

Es importante conocer qué herramientas existen, pero más aún saber utilizarlas adecuadamente. (Por ejemplo, el martillo no se utiliza para fijar tornillos, aunque algunas personas intenten hacerlo.)

Las herramientas ayudan al analista a integrar los datos recopilados por los diversos métodos estudiados en la sección anterior. Pero, como sucede con todas las herramientas, las que emplea el analista para documentar procedimientos y decisiones deben utilizarse adecuadamente.

La primera sección presenta las características que, son comunes a todos los procedimientos y decisiones. Hecho esto, 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 está preguntando por las condiciones, que son los posibles estados de una entidad (persona, lugar, objeto o evento). Es indudable que la mayoría de las personas describen automóviles, muebles e incluso a otras personas de acuerdo con sus condiciones buenas y malas. "Bueno" y "malo" son dos condiciones que pueden aplicarse a cada una de las entidades anteriores. Las condiciones cambian y es por esto que el analista se refiere a ellas como variables de decisión. En una empresa, el manejo de una factura está basado en una condición que constituye una variable de decisión. Algunas organizaciones insisten en que todas las facturas lleven una firma (quizá del contralor o del encargado de efectuar las compras) como requisito para autorizar el pago. En tales casos existen dos alternativas para la recepción de facturas por parte de la organización: con firma o sin ella. La misma factura también puede ser descrita por otras condiciones: autorizada o no autorizada, con el monto correcto o incorrecto.

Al documentar la decisión sobre cómo procesar facturas (o cualquier otro procedimiento), el investigador debe identificar tanto las condiciones permisibles como las relevantes que pueden presentarse en determinada situación. Sólo deben incluirse en el estudio aquellas condiciones que son relevantes. El hecho de que la factura esté o no firmada es una variable relevante. Sin embargo, el tamaño de la hoja de papel sobre la que está impresa probablemente no lo sea.

Acciones

Cuando se conocen todas las posibles condiciones, el siguiente paso del analista es determinar qué hacer cuando se presentan algunas de éstas. Las acciones son las opciones, que comprenden pasos, actividades o procedimientos, que puede elegir una persona cuando se enfrenta ante un conjunto de condiciones (Fig. 3.6). En algunos casos las acciones pueden ser bastante sencillas, mientras que en otros muy extensas.

El ejemplo del procesamiento de pedidos estudiado anteriormente, demanda acciones específicas que dependen, entre otras cosas, de que la factura esté o no firmada (las condiciones). Si está firmada entonces se verifica que la factura sea correcta. Si no está firmada, entonces se verifica si la mercancía fue aceptada (es decir, si llegó la mercancía al almacén y fue aceptada). En este ejemplo las acciones relevantes son iniciar el procesamiento para comprobar el pedido y

2) comenzar el proceso de aceptación de la mercancía (Fig. 3.7). Asimismo, las acciones pueden estar relacionadas con condiciones

cuantitativas. Por ejemplo, a menudo las empresas ofrecen descuentos diferentes en la venta de mercancía de acuerdo con el volumen del pedido. Una compañía puede basar el monto de los descuentos sobre tres valores diferentes para la condición VOLUMEN DEL PEDIDO: más de 10000 dólares, entre 5000 y 10000 dólares y menos de 5000 d¿>Iares. Las acciones son: 3% de descuento, 2% de descuento y ningún descuento (Fig. 3.8).

. 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. Estas herramientas se estudian a continuación.

Árboles de decisión

Las personas tienen diferentes formas de decir lo mismo. Por ejemplo, las condiciones de descuento que se mencionaron en las líneas de arriba también pueden formularse de las siguientes maneras:

l. Mayor que 1'0 000 dólares, mayor o igual que 5000 pero menor o igual que 10 000 dólares, y menos de 5000 dólares.

2. No menos de 10 000 dólares, no más de 10 000 pero por lo menos de 5000 dólares, y no más de 5000 dólares.

Características de los árboles de decisión

El árbol de decisión es un diagrama que representa en forma secuencias condiciones y acciones; muestra qué condiciones se consideran en primer lugar, cuáles en segundo y asi sucesivamente. -Este método tarnbi¿ñ permíte mostrar la relación que existe entre cada condición y el grupo de acciones permisibles asociado con ell4l Los diagramas de este tipo se parecen a las ramas de un árbol, de aquí su nombre (Fig. 3.9).

La raíz del árbol, que aparece en la parte izquierda de la figura, 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 éstas, 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 preceden.

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 llevándola a los analistas a identificar de manera formal las decisiones que actualmente deben tomar 1 De esta forma, es difícil para 'ellos pasar por alto cualquier etapa del proceso de decisión, sin importar que éste dependa de variables cuantitativas o cualitativas.

Es posible, por ejemplo, señalar qué acción de descuento emprender de acuerdo con la cantidad de dólares gastados por los clientes. Cuando una organización abre cuentas con proveedores y distribuidores, formaliza un acuerdo para efectuar descuentos del total del acuerdo se especifican dos condiciones: primera, que factura. En este acuerdo el monto de la factura debe pagarse dentro de los diez días siguientes a la fecha de su recepción, y, segundo, el porcentaje de descuento va de acuerdo con el monto de la factura. Se entiende que bajo algunas condiciones la organización puede tomar la acción de deducir el 3%, en otras el 2%, y para todas las demás no hay descuento. Los árboles de decisión también obligan a los analistas a considerar la secuencia de las decisiones. Considerese la secuencia de decisiones de este ejemplo (Fig. 3. 1 O). Del diagrama puede observarse con rapidez que la sola existencia de una condición -el monto total de la factura- no es importante, a menos que se cumpla otra condición y la factura sea pagada dentro del tiempo establecido por el proveedor, es decir diez días. Las demás condiciones son relevantes únicamente si esta condición es verdadera.

Identificación de los requerimientos de datos

Ya se ha señalado el empleo de árboles de decisión para subrayar de manera formal la naturaleza de muchas decisiones en la empresa; así mismo , se ha demostrado que los árboles de decisión son eficaces

cuando es necesario describir problemas con más de una dimensión o condición. Sin embargo, 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 datos explícitos en el ejemplo de las cuentas por pagar (Fig. 3.16' ) son los siguientes: datos del pago, monto de la factura y porcentaje de descuento. Existen otros datos importantes que son implícitos (es decir no se aparecen en el árbol de decisión), como los detalles de la factura (número de la factura, nombre y dirección del proveedor), nuevo monto por pagar y ajustes al "descuento aplicado. El analista debe identificar y elaborar una lista de todos los datos utilizados en el proceso de decisión, aunque el árbol de decisión no muestre todos los datos. j 1 . Si los árboles de decisión se construyen después de completar el análisis de flujo de datos (que es el seguimiento del flujo de datos por todos los procesos de la empresa), entonces es posible que los datos críticos se encuentren ya definidos en el diccionario de datos.(el cual describe los datos utilizados por el sistema y dónde se emplean)

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

Los árboles de decisión no siempre son las mejores herramientas 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 número de ramas que pertenecen a varias trayectorias constituye más un problema que una ayuda para el análisis. En estos casos los analistas corren el riesgo de no determinar qué políticas o estrategias de la empresa son la guía para la toma de decisiones específicas. Cuando aparecen estos problemas, entonces es momento de considerar las tablas de decisión.

Tablas de decisión

Más que un árbol, 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. Este método se emplea desde mediados de la década de los cincuentas, cuando fue desarrollado por General Electric para el análisis de funciones de la empresa como control de inventarias, análisis de ventas, análisis de créditos y control de transporte y rutas.

Características de las tablas de decisión

La tabla de decisión está integrada por cuatro secciones: identificación de condiciones, entradas de condiciones, identificación de acciones y entradas de acciones (Fig. 3.12). La identificación de condiciones señala aquellas que son relevantes. Las entradas de condiciones indican qué 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 específicas del conjunto que deben emprenderse cuando ciertas condiciones o combinaciones de éstas son verdaderas. En ocasiones se añaden notas en la parte inferior de la tabla para indicar cuándo utilizar la tabla o para diferenciarla de otras tablas de decisión.

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 tábla 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. Rernover 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: I) dos

Verificación de tablas de decisión

regias 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.

La figura 3.16 contiene reglas de decisión redundantes: las regias de decisión 1 y 2. Para ambas reglas se sugiere, por medio de la X en la sección de entradas de acciones, tomar la acción "Seleccionar un artículo para su compra" correspondiente a las columnas 1 y 2. Un examen más detenido de los renglones de condiciones revela que las reglas de decisión son idénticas para las condiciones 1 y 2 pero opuestas para la condición 3. Esto indica que las acciones no dependen del valor de la condición 3 ya que sin importar cuál sea este valor, las acciones son las mismas. Dado que lo anterior siempre es verdadero, las reglas de decisión son redundantes y pueden combinarse en una sola regla. La condición sobre el renglón dgnde ellas difieren se puede reemplazar por un espacio en blanco o un guión para indicar que esa condición no es importante. La figura 3.17 muestra los resultados obtenidos al remover esta redundancia de la tabla original.

Supresión de contradicciones Las reglas de decisión son contradictorias entre sí cuando dos o más reglas tienen el mismo conjunto de condiciones pero sus acciones son diferentes. (Recuerde que si son las mismas entonces las reglas de decisión son redundantes.)

Las contradicciones indican que la información que tiene el analista es incorrecta o bien que existe un error en la construcción de la tabla. Sin embargo, muchas veces la contradicción es resultado de las discrepancias en la información que recibe el analista de diferentes personas con respecto a la forma en que éstas toman decisiones. Se puede tomar una decisión específica 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.

En la figura 3.16 existe una contradicción entre las reglas de decisión 5 y 7. Las dos tienen los mismos valores para las condiciones 1, 2 y 3 (S, N y S), pero la regla 5 afirma que se debe seguir la estrategia Al mientras que la regia 7 señala A2.

Tipos de entradas en la tabla

Forma de entrada limitada La estructura básica de la tabla utilizada en los ejemplos anteriores, consistentes en S, N y entradas en blanco, es una forma de entrada limitada. Éste es uno de los formatos más comunes. Existen otros dos que también se emplean de manera amplia.

Forma de entrada extendida Esta forma reemplaza las S y N con acciones que le indican al lector cómo 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 más detalles que una S y N.

La figura 3.18 ilustra el método de entrada extendida para el ejemplo de los descuentos. La tabla con entradas limitadas lista tres condiciones en la sección de identificación de acciones. La X en esta sección indica la acción correcta. Sin embargo, la forma de entrada extendida tiene sólo una identificación de acción: ACCIÓN. Para cada regla, se coloca una frase breve en la sección de identificación de acciones: DESCONTAR 3%, DESCONTAR 2%, PAGAR EL MONTO TOTAL DE LA FACTURA.

Muchas personas favorecen este formato sobre el método de entradas limitadas porque es más explicito para señalar las acciones.

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 sólo una forma en cada sección de la tabla, pero entre las secciones de condiciones y acciones se puede utilizar cualquier forrna. El ejemplo de entrada mixta de la figura 3.14 coinbina el forrnato de entrada limitada para las acciones con el mixto para las entradas de condiciones.

Forma ELSE Esta es otra variante en las tablas de decisión que tiene como finalidad ornitir la repetición por medio de reglas ELSE. Para construir una tabla de decisión en Iaforma ELSE, se especifican las reglas, i unto 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 cuando ninguna de las demás condiciones explicitas es verdadera. Esta regla se encuentra en la columna final del r,nargen derecho, que es la columna ELSE. Si ninguna de las otras condiciones es válida, entonces se sigue la regla de decisión ELSE. Esta regla elimina la necesidad de repetir condiciones que conducen a las mismas acciones.

La tabla de decisión de la figura 3.19 para el descuento en el pago, utiliza una forma ELSE. Como puede observarse, la regla de decisión ELSE reemplaza cuatro regias de decisión que invocan la misrna acción.

Tablas múltiples

tablas de decisión. Otra manera de alcanzar este mismo objetivo es enlazando varias tablas de decisión. De acuerdo con las acciones seleccionadas en la primera tabla, otras se explican en una o iná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.

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 cuál es la siguiente tabla que se va a examinar. La figura 3.20 es el bosquejo de una tabla con transferencia directa. La proposición "GO TO Tabla 2" le indica al lector que examine otra tabla de decisión, en este caso la que está marcada como Tabla 2. Se examinan las condiciones, decisiones y acciones especificadas en esta tabla y se selecciona la apropiada para completar el trabajo.

Español estructurado

El español estructurado es otro método para evitar los problemas de ambigüedad de¡ 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 método no muestra las 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 tornar cuando esto sucede, junto con las acciones correspondientes. Sin embargo, este método también le permite hacer una lista de todos los pasos en el orden en que se llevan a cabo, como lo muestran los ejemplos de esta sección. Para ello no se utilizan símbolos y formatos especiales, características de los árboles y tablas de decisión que para algunos resultan incómodos. Además, es posible describir con rapidez los procedimientos en su totalidad ya que para ello se emplean decla-

raciones muy similares al español.

La terminología utilizada en la descripción estructurado 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. Estas estructuras son adecuadas para el análisis de decisión y pueden trasladarse al desarrollo de software y programación, corno se indica en los capítulos de este libro

dedicados al desarrollo de software.

Estructuras de secuencia Una estructura de secuencia es un solo paso o acción incluido en un proceso. Éste . 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.

dimiento sirnilar al siguiente:

l. Escoger el libro deseado.

2. Llevar el libro al mostrador de salida.

3. Pagar el libro.

4. Obtener el recibo,

5. Abandonar la librería.

Este ejemplo sencillo muestra una secuencia de cinco pasos. Ninguno contiene alguna decisión o condiciones que determinen la realización del siguiente paso. Por otra parte, los pasos se efectúan en el orden mostrado. Por ejemplo, tiene poco sentido pagar por un libro antes de seleccionarlo. Por consiguiente, el procedimiento señala el orden correcto de las acciones.

La figura 3.23 muestra la secuencia de pasos para el ejemplo del procesamiento de cuentas por pagar. Tal como aparecen en la í-igura, siempre se lleva a cabo esta secuencia de cinco pasos, uno después de otro sin ninguna decisión sobre el orden o relacionada con las excepciones.

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 específica. 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 asociado con esta condición. Una vez determinada la condición las acciones son incondicionales, como se mencionó anteriormente.

Para ilustrar las estructuras de decisión, considérese de nuevo el ejemplo anterior. Al ir a la librería es posible que ésta no tenga en existencia el libro que se desea comprar. En este caso se tienen dos condiciones: encontrar el libro y no encontrar el libro. Estas condiciones, junto con las acciones correspondientes, pueden indicarse de la siguiente manera:

SI se encuentra el libro deseado ENTONCES Llevar el libro al mostrador de salida.

Pagar el libro.

Asegurarse de obtener el recibo de compra.

Abandonar la librería.

DE OTRO MODO

No llevar libros al mostrador de salida.

Abandonar la librería.

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 éstas'se presentan. Las instrucciones de iteración permiten al analista describir estos casos.

La búsqueda de un libro en la librería puede realizarse repitiendo los siguientes pasos:

EJECUTAR MIENTRAS se examinan más libros:

Leer el título del libro

SI el título suena interesante

ENTONCES tomar el libro y hojearlo.

Buscar el precio.

SI la decisión es llevar el libro

Colocarlo en la pila de LIBROS PARA LLEVAR.

OTRO regresar el libro al estante.

FIN DE SI

OTRO continuar

FIN DE EJECUTAR

SI se encuentran los libros deseados ENTONCES Llevar los libros al mostrador de salida.

Pagar los libros.

Asegurarse de obtener el recibo.

Abandonar la librería.

OTRO

No llevar libros al mostrador de salida.

Abandonar la librería.

FIN DE SI

Beneficios del espaií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 utilizar el español estructurado para declarar las reglas de decisión que se aplican las estrategias para determinar los requerimientos también se abordarán aspectos sobre la estructuración del proceso de análisis, esto es analizar un sistema existente de manera tal que se asegure la captura de todos los detalles pertinentes relacionados con dalos y procesos. El análisis estructurado tiene relación con los aspectos presentados por Mary Helen en la historia al inicio del capítulo, reconocer la naturaleza dinámica de los sistemas en las organizaciones. En este capítulo primero se explica la finalidad del análisis estructurado y después se explora el análisis de flujo de datos, resaltando la utilidad que tiene para los analistas y describiendo su uso. Cada estrategia depende de la habilidad de los analistas para hacer uso de las técnicas, estudiadas en el capítulo anterior, para detectar hechos y recopilar detalles relacionados con el sisterna.

ANÁLISIS ESTRUCTURADO

Cuando los analistas comienzan a trabajar sobre un proyecto de sistemas de información, a menudo tienen que 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 esa área. Cualquier nuevo sistema o conjunto de recomendaciones para cambios en el sistema existente, ya sea éste manual o automatizado, debe conducir hacia una 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 su interrelación), y de una manera que permita manejar el desarrollo del nuevo sistema.

¿Qué es el análisis estructurado?

Considérense las siguientes preguntas:

- ¿Deben dos analistas desarrollar una lista idéntica de requerimientos cuando estudian en forma independiente la misma situa-

ción?

- Para una situación dada, ¿existe siempre un solo diseño correcto

para el sistema?

- ¿Las aplicaciones que el analista observa tienen una naturaleza bien estructurado o están mal definidas?

Obtener las respuestas a estas preguntas es un reto. Cuando una persona visita al médico se piensa que el diagnóstico para una condición o enfermedad en particular es correcto o equivocado. Esta tendencia también se observa en otras áreas, incluyendo los sistemas de información.

El hecho es que dos analistas que examinart-,una situación en forma independiente, sin lineamientos o herramientas y técnicas preestablecidos, recopilan información diferente para describir el sistema. Esta información a su vez conduce a la determinación de diferentes requerimientos. De acuerdo con lo apropiado de los requerimientos especificados, el sistema puede o no satisfacer las necesidades

de los usuarios.

Por su propia naturaleza, quizá los escenarios de los sistemas de información sean mal estructurados. No siguen leyes, como en la ciencia. Dependen de los seres humanos para funcionar o no funcionar, y junto con otras actividades se ven influenciados por las políticas los analistas de sistemas deben determinar los requerimientos de los sistemas de información.

El análisis estructurado es un método para el análisis de sistemas rnanuales 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 dónde 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, como señaló Mary Helen en su seminario. El análisis estructurado permite al analista conocer un sistema o proceso (actividad) en una forma lógica y manejable al mismo tiempo que proporciona la base para asegurar que no se omite ningún detalle pertinente.

Significado de "estructurado"

¿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 la comprensión completa y exacta de una situaci¿>n dada. A partir de aquí se determinan los requerimientos que serán la base de un sistema nuevo o modificado.

En el análisis estructurado, la palabra estructura significa que: l) el método intenta estructurar el proceso de determinación de los requerimientos comenzando con la documentación de¡ sistema existente; 2) el proceso está organizado de tal forma que intenta incluir todos los detalles relevantes que describen al sistema en uso- 3) es fácil verificar cuándo se han omitido detalles relevantes; 4) la identificación de los requerimientos será similar entre varios analistas e incluirá las 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 comunicación eficientes.

¿Qué es el análisis de flujo de datos?

Los analistas desean conocer las respuestas a cuatro preguntas específicas: ¿qué procesos integran el sistema?, ¿qué datos emplea cada proceso?, ¿qué datos son almacenados? y ¿qué datos ingresan y abandonan el sistema? De lo anterior es claro que se da gran importancia al

análisis de los datos.

Los datos son la guía de las actividades de la empresa. Ellos pueden iniciar eventos (por ejemplo, los datos sobre nuevos pedidos) y ser procesados para dar información útil al personal que desea saber qué tan bien se han manejado los eventos (al medir la calidad y tasa del trabajo, rentabilidad, etc.). El análisis de sistemas conoce el papel central que tienen los datos de la empresa en las organizaciones. Seguir el flujo de datos por todos los procesos de la ernpresa, que es la finalidad del análisis de flujo de datos, les dice mucho a los analistas sobre cómo se alcanzan los objetivos de la organización. En el transcurso del manejo de transacciones y terminación de tareas los datos entran, son procesados, almacenados, recuperados, analizados, utilizados, cambiados y presentados como salidas. El análisis deflujo de datos estudia el empleo de los datos en cada actividad. Documenta los hallazgos con diagramas de flujo de datos que muestran en forma gráfica 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.

¿Qué es el análisis de flujo de datos?

análisis de los datos.

Limitaciones del proyecto

Son las condiciones que pueden frenar la investigación, las “debilidades restrictivas” en la realización del trabajo.

Tiempo
Dinero
Dsiponibilidad de inf.

Inv. Invalida

Permanencia de los sujetos
Desarrollo físico o mental
Falta de recepción de cuestionarios
Anticipar todos los problemas

Delimitación

Describe la población hacia la cual se pueden generalizar los resultads de la investigación.

Justificación

¿Por qué nos preocupamos por este problema especifico?

¿Cuál es la importancia potencial del trabajo a desarrollar?

Dar la razón p/la cual el prob. Es importante, pero no justifica los resultados de la investigación, ya que aun no se tienen.

Involucra:

El porque vale la pena realizar el estudio

Las implicaciones que pueden tener los resultados

Quienes se beneficiaran de los resultados

Objetivos

Prob. “Que” del estudio General

Constituye el “Porque” Especifico

Indicar exactamente lo que se desea y definalo con precisión, exactitud, claridad y palabras necesarias que permitan seguir el rumbo trazado por el método que se establezca.

UNIDAD III

ESTUDIO DE FACTIBILIDAD

Las investigaciones preliminares examinan la factibilidad del proyecto, la posibilidad de que el sistema sea de utilidad para la organización. Las pruebas de factibilidad son: Operacional, Técnica y Financiera.

FACTIBILIDAD OPERACIONAL

Los proyectos propuestos únicamente tienen beneficio cuando logran ingresar al grupo de sistemas de información que satisfacen los requerimientos de la organización.

En esta prueba de factibilidad se formulan las siguientes preguntas:

¿ Trabajará el sistema cuando esté terminado e instalado ?
¿ Existen barreras para la implantación ?

Para poder probar la factibilidad operacional se pueden hacer las siguientes preguntas:

¿ Existe el apoyo suficiente para el proyecto por parte de la administración y por parte de los usuarios ?

Si el sistema en uso es bien visto y es utilizado por muchas personas entonces no hay ninguna razón para efectuar cambios.

¿ Los métodos que actualmente se emplean en la empresa son aceptados por los usuarios ?

Si no es así entonces los usuarios darán la bienvenida a cualquier cambio que permita tener un sistema más útil y operacional.

¿ Los usuarios han participado en la planeación y desarrollo del proyecto ?

La participación desde un principio disminuye los riesgos de rechazo hacia el sistema y el cambio.

¿ El sistema propuesto causará perjuicios ?

¿ Producirá resultados pobres en algún área o aspecto ?

¿ Se perderá el control en alguna área ?

¿ Se perderá la factibilidad de acceso a la información ?

¿ La productividad de los empleos será menor después que antes de la implantación?

¿ Los clientes se verán afectados en forma poca favorable ?

¿ El sistema reducirá la productividad de otras áreas ?

FACTIBILIDAD TECNICA

Entre los aspectos técnicos incluyen lo siguiente:

Existe o se puede adquirir la tecnología necesaria para realizar lo que se pide.

El equipo propuesto tiene la capacidad técnica para soportar todos los datos requeridos para usar el nuevo sistema.

El sistema propuesto ofrecerá respuesta adecuada a las peticiones sin importar el número y ubicación de los usuarios.

Si se desarrolla el sistema puede crecer con facilidad.

Existen garantías técnicas de exactitud, confiabilidad, facilidad de acceso y seguridad de los datos.

FACTIBILIDAD FINANCIERA

Un sistema que puede ser desarrollado desde el punto de vista técnico y además será utilizado si se llega a instalar debe ser una buena inversión para la organización.

Las cuestiones económicas y financieras tienen el propósito de estimar lo siguiente:

1.- Costo de llevar a cabo la investigación completa del sistema.

2.- Costo de hardware y software para la aplicación que se está considerando.

3.- Beneficios en la forma de reducción de costo o de menos errores costosos.

4.- Costo si nada sucede.

FACTIBILIDAD ECONOMICA.- Evaluación del costo de desarrollo frente al beneficio final producido por le sistema desarrollado.

FACTIBILIDAD TECNICA.- Estudio de la funcionalidad, el rendimiento y las restricciones que pueden afectar a la posibilidad de la restauración de un sistema aceptable.

No es necesario llevar a cabo un estudio de factibilidad para sistemas en donde la justificación económica es obvia del riesgo técnico es bajo. La justificación económica es normalmente la principal consideración para la mayoría de los sistemas. La justificación económica comprende un amplio rango de aspectos entre los que se encuentran el análisis de costo-beneficio, el costo de los recursos que se necesitan para el desarrollo y el crecimiento potencial del mercado.

ESTUDIO DE FACTIBILIDAD

INTRODUCCIÓN.

Declaración del problema.
Entorno de implementación.
Restricciones.

RESUMEN Y RECOMENDACIONES.

Hallazgo imp.
Comentarios.
Recomendaciones / impacto.

ALTERNATIVAS.

Config. Del s. altern.
Crit. Util. En la selec. De enfoq.

DESCRIPCION.

Declar. Resum. Del amb.
Factib. De los elem. Asign.

AN. DE COSTO Y BENEFICIO.

EV. DEL RIESGO TECNICO.

CONSID. LEGALES.

OTROS ASUNTOS ESPEC. DEL PROYECTO.

ANALISIS ECONOMICO

Entre la información más relevante que contiene el estudio de factibilidad se encuentra el análisis de costo beneficio. Este análisis señala los costos del desarrollo del proyecto y los contraste con los beneficios tangibles e intangibles del sistema.

El análisis de costo-beneficio varía según las características del sistema a desarrollar, el tamaño relativo del proyecto y la recuperación esperada de la inversión, los beneficios de un sistema nuevo siempre se determinan de acuerdo con el modo de trabajo ya existente.

POSIBLES COSTOS DEL SISTEMA DE INFORMACION

COSTOS DE ACONDICIONAMIENTO

Consultoría

Compra o alquiler del equipo actual

Instalación del equipo

COSTOS DE PUESTA

Software de sistema operativo

Instalación del equipo de comunicaciones

Actividades de búsqueda y contratación del personal

COSTOS RELATIVOS AL PROYECTO

Compra de software de aplicación

Modificaciones del software para ajustarse a los sistemas locales

Preparación de documentación

COSTOS CONTINUOS

Mantenimiento del sistema

Alquileres

ANALISIS TECNICO

Durante el análisis técnico el analista evalúa los méritos técnicos del concepto del sistema mientras que al mismo tiempo recoge información adicional sobre el rendimiento facilidad de mantenimiento y posibilidad de producción.

El análisis técnico empieza con una definición de la factibilidad técnica del sistema propuesto.

¿ Qué tecnologías se requieren para conseguir la funcionalidad y el rendimiento del sistema ?

¿ Qué nuevos materiales, métodos, algoritmos o procesos se requieren y cuál es el riesgo de su desarrollo ?

¿ Cómo afectará el costo de estos elementos de tecnología ?

Una de las herramientas para el análisis técnico se encuentran las técnicas matemáticas de modelización y optimización.

La modelización es un mecanismo efectivo para el análisis técnico del sistema basándose en computadora.

El modelo se crea a partir de la observación del mundo real o de una aproximación basada en los objetivos del sistema.

El analista comprueba el comportamiento del modelo y la compara con el del mundo real o con el del sistema operado, obteniendo información de factibilidad técnica para el sistema propuesto.

CRITERIOS PARA EL USO DE MODELOS

Debe representar la dinámica de la configuración del sistema que está siendo evaluado de forma simple de comprender y manipular.

Debe realizar aquellos factores que sean más relevantes para el problema y suprimir aquello no importantes.

Debe ser amplio incluyendo los factores relevantes y fiables en cuanto a los resultados.

Debe ser simple para permitir una rápida implementación de la resolución del problema.

Debe incorporar previsiones para poder modificarlo y/o expandirlo fácilmente y permitir la evaluación de factores adicionales si se requieren.

Los resultados del análisis técnico son la base de otra decisión del tipo “seguir / no seguir” con el sistema.

CRITERIOS PARA EL USO DE MODELOS

ORDEN DE LOS PARAMETROS DE EVALUACION

UNIDAD IV

ELABORACION DEL PROYECTO

DISEÑO (Elemento Lógico del sistema)

El diseño de un sistema tiene dos etapas:

1.- Diseño Lógico: se describen las especificaciones detalladas del nuevo sistema, es decir, aquellos que describen las características:

entradas;

salidas;

archivos;

base de datos;

procesamientos

El conjunto formado por todas estas características recibe el nombre de “especificaciones de diseño del sistema”.

2.- Construcción Física: Produce el software los archivos y un sistema que funciona. Las especificaciones de diseño indican a los programadores lo que el sistema debe hacer.

Diseño Lógico Diseño Físico

Especificaciones de las Producto (prog.) archivos

características

Un objetivo en el diseño de un sistema de información es asegurar que este brinde apoyo a la actividad de la empresa para la que fué desarrollada.

Se dice que un sistema de información satisface las necesidades de los usuarios si:

Realiza en forma apropiada los procedimientos correctos.

Presenta información e instrucciones en forma aceptable y efectiva.

Produce resultados exactos.

Proporciona un interfaz y método de iteracción aceptables.

Es percibido por los usuarios como un sistema confiable.

El objetivo del diseño del sistema es:

“Determinar y proporcionar el sistema correcto”.

El analista debe procurar formular el diseño del sistema en forma que:

Incorpore características del sistema que sean fáciles de comprender y utilizar, desaliente los errores cometidos por los usuarios o la falta de cuidado por parte de ellos.

Evite fallas o procedimientos inapropiados que generen perjuicios o complicaciones para los usuarios.

Tenga suficiente flexibilidad para adaptarse a las necesidades de cada usuario.

Funciona en una forma que parezca natural al usuario.

ESTANDARES DE DISEÑO

1.- Estándares para datos: lineamientos para asignar nombre a los datos y especificar su longitud y tipo. (diccionario de datos).

2.- Estándares de codificación: abreviaturas y designaciones formales para describir actividades y entidades dentro de la organización (identificadores) (abreviaturas personales).

3.- Estándares estructurales: lineamientos de como estructurar el software y el sistema.

4.- Estándares de documentación: descripción de las características del diseño de sistema de la relación entre componentes y de las características de operación que pueden ser revisadas para conocer los detalles de la aplicación (manuales).

CARACTERÍSTICAS QUE SE DEBEN DISEÑAR

Las especificaciones de diseño describen las características del sistema, los componentes o elementos del sistema y la forma en que estos aparecerán ante los usuarios.

ELEMENTOS DEL DISEÑO

Flujo de datos: Movimiento de datos hacia alrededor y desde el sistema.

Almacenes de datos: Conjuntos temporales o permanentes de datos.

Proceso: Actividad para aceptar, manejar y suministrar datos e información.

Procedimientos: Métodos y rutinas para utilizar el sistema de información y lograr con ello los resultados esperados.

Controles: Stándares y lineamientos para determinar si las actividades están corriendo en forma anticipada o acertada.

Funciones del personal: las responsabilidades de todas las personas que tienen que ver con el nuevo sistema incluyendo los usuarios, operadores de computadoras y personal de apoyo.

DISEÑO DE PROCEDIMIENTOS

Los procedimientos especifican que tareas deben ejecutarse al utilizar el sistema y quienes son los responsables de llevarlas a cabo entre los procedimientos importantes se encuentran:

Procedimientos para entrada de datos:

Métodos para al captura de datos de las transacciones y su ingreso en el sistema.

Procedimientos durante la ejecución:

Acciones realizadas por los operadores del sistema interacción de los usuarios finales para alcanzar resultados deseados.

Procedimientos para el manejo de errores:

Acciones a seguir cuando se presentan resultados inesperados.

Procedimientos de seguridad y respaldo:

Acciones para proteger al sistema y sus recursos contra posibles daños.

Estos procedimientos deben formularse por escrito y formar parte de la documentación del sistema.

DISEÑO DE ESPECIFICACIONES DE PROGRAMAS

Describe como transformar las especificaciones del diseño del sistema (salida, entrada, archivos, procedimientos) en software de computadora.

El diseño del software es importante para asegurar:

Los programas producidos lleven a cabo todas las tareas y lo hagan en la forma establecida.

La estructuración del software en módulos permita su prueba y validación para determinar si los procedimientos son correctos.

Las modificaciones futuras se puedan realizar en forma eficiente y con un mínimo de interrupción en el diseño del sistema.

ELABORACION DE MODULOS

Un sistema estructurado es modular y desarrollado en forma descendente, es decir, separado 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.

Las conexiones entre módulos son limitadas y la interacción de datos es mínima.

ANOTACION Y TRANSFERENCIA DE DATOS

EN DIAGRAMA DE ESTRUCTURA

Las notas en el diagrama de estructura indican los parámetros que se transfieren y la dirección de movimiento de los datos.

Los módulos A y B interactúan los datos identificados como X y Y se pasan al módulo B. El cual a su vez regresa el valor Z.

Un módulo que hace una llamada puede interactuar con más de un módulo subordinado.

L llama a los módulos M y N subordinados; M es llamado en un punto de decisión en (").

DISEÑO DEL SOFTWARE

° MODULACIÓN Y FRAGMENTACIÓN.

Cada sistema debe estar formado por una jerarquía de módulos. Los módulos de niveles inferiores son menores en avance y tamaño comparados con los módulos de nivel superior y sirven para fragmentar procesos en funciones separadas.

° ACOPLAMIENTO.

Los módulos de un sistema deben tener poca dependencia entre si (relación de módulos pero sin que un módulo dependa de otro).

° COHESIÓN.

Los módulos deben llevar a cabo solo una función de procesamiento.

° EXTENSIÓN DE CONTROL.

Los módulos deben interactuar y coordinar las funciones de un número limitado de módulos de nivel inferior.

° TAMAÑO.

El número de instrucciones contenidas en un módulo debe ser limitado, el tamaño del módulo es generalmente pequeño.

° USO COMPARTIDO.

Las funciones no deben repetirse en módulos separados sino establecerse en un único módulo que se pueda utilizar para cualquier otro cuando sea necesario.

MODULARIDAD.

El método descendente se usa en todo el proceso de análisis y diseño. Cada función que el sistema lleva a cabo se identifica primero y después se desarrolla con mayor detalle. Los diseñadores de programa lo llaman refinamiento por pasos: los procedimientos y procesos se desarrollan uno a la vez desde lo general hasta lo particular.

ACOPLAMIENTO.

Un buen acoplamiento minimiza la interdependencia entre los módulos para lograr esto se debe:

• Controlar el número de parámetros que se transfieren entre los módulos.

• Evitar la transferencia innecesaria de datos a los módulos que se llaman.

• Transferir datos solo cuando sea necesario.

• Mantener relaciones superior - inferior entre los módulos que se llaman y los que son llamados.

• Transferir datos no información de control.

COHESIÓN DE UN MÓDULO.

EXTENSIÓN DE CONTROL.

Se refiere al número de módulos subordinados controlados por el módulo que hace llamada. En general hay que tratar de no tener más de 5 a 7 módulos subordinados.

La extensiva extensión de control crea un peso considerable cuando se desea determinar cual módulo llamar bajo ciertas condiciones y al establecer secuencias de llamadas para transferir datos y recibir resultados.

TAMAÑO DEL MÓDULO.

En general debemos procurar diseños en donde los módulos tengan una función específica, sean altamente colisivos y estén aceptados ordenadamente. Los módulos no deben ser demasiado pequeños. El tamaño del módulo también depende del lenguaje que se use.

USO COMPARTIDO.

Este surge del deseo de tener una cierta función, cálculo o tipo de proceso llevado a cabo en un lugar del sistema. Hay varias razones para compartir módulos:

Minimiza la cantidad de software que debe diseñarse y escribirse.
Minimiza el número de cambios que hay que hacer durante el mantenimiento del sistema.
Al tener un único modo compartido que reduce la probabilidad de error.

INTEGRACIÓN.

Si se desea que las actividades tengan el potencial para cambiar actividades que están allá de su ámbito de trabajo entonces deben ser sistemas integrados.

TIPOS DE INTEGRACIÓN.

° INTEGRACIÓN HORIZONTAL: Abarca áreas funcionales de la empresa y asegura que el flujo de información sea manejado de forma tal que un área conozca la manera en que sus actividades afectan o influyen las de otras áreas.

° INTEGRACIÓN VERTICAL: Eslabona las aplicaciones con la jerarquía de mandos dentro de una función específica de la empresa.

° INTEGRACIÓN FÍSICA: Dado que en la actualidad las empresas realizan sus operaciones en una verdadera economía global, los sistemas de información deben dar soporte a transacciones efectuadas con clientes y proveedores de todo el mundo, mientras que al mismo tiempo permite penetrar en la competencia en los mercados internacionales.

° INTEGRACIÓN DE MEDIO EXTERNO AL INTERNO: Reconoce la necesidad tanto de poner a disposición de la organización fuentes externas de datos como de comunicarse con entidades externas tales como clientes, vendedores y proveedores de la industria de datos.

PROPÓSITOS DE LOS DIAGRAMAS DE ESTRUCTURA

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

Presentan cuales módulos interactuan dentro de un sistema y también muestran gráficamente los datos que se comunican entre varios módulos.

Los diagramas de estructura se desarrollan antes de escribir el código del programa. No se pretenden que expresen la lógica del procedimiento.

Los módulos del programa se identifican mediante rectángulos con el nombre del módulo escrito dentro del rectángulo, las flechas indican las llamadas, las cuales son cualquier mecanismo para invocar un módulo particular.

PRUEBA Y DEPURACIÓN

Los diseños de las entradas tienen como finalidad, recibir las posibilidades de cometer errores o equivalentes durante la entrada de datos.

VALIDACIÓN DE ENTRADA, es el término que se le da a los métodos cuya finalidad es detectar errores en la entrada.

VALIDACIÓN DE LAS TRANSACCIONES, lo primero es identificar todas las transacciones que no son válidas, ya sean porque están incompletas, no autorizadas e incluso fuera de lugar.

VERIFICACIÓN DE LA TRANSACCIÓN

Es responsabilidad del analista especificar los procedimientos de validación que proveerán la aceptación de una transacción. La transacción debe ser aceptable para el sistema antes de que pueda ser procesada por el.

Los pasos que el sistema sigue para asegurarse de que la transacción es aceptable recibe el nombre de validación de transacciones. El analista también debe asegurarse que los procesos de validación de transacción detecten situaciones donde se envía una entrada aceptable por un usuario que no está autorizado para hacerlo.

Las pruebas de secuencia utilizan códigos en los datos para probar una de las dos diferentes condiciones dependiendo de las características del sistema. Las pruebas de secuencias también señalan faltantes.

Las pruebas de completes son una forma más de validar la transacción y con ello asegurar que esta sea exacta y aceptable para que el sistema pueda procesarla o almacenarla.

El procesamiento por lotes significa proceso retardado por la acumulación de transacciones en lote o grupo de registros. Cuando las transacciones se acumulan y no se procesan justo en el momento en que ocurren existe la posibilidad de que alguna de ellas sea mal procesada, olvidada o pasada por alto.

METODO PARA VALIDAR LOS DATOS

Prueba de existencia, examina los campos esenciales para determinar que estos contengan datos. La tarea de los analistas es determinar que datos deben estar presentes y cuando su ausencia es aceptables.

Verificación de límites o rangos, estas pruebas verifican la veracidad de los datos de una transacción. Las pruebas de límites sirven para validar la cantidad mínima o máxima aceptable para un dato. Las pruebas de rango validan tanto los valores mínimos como máximos.

Prueba de combinación, validan el hecho de que varios datos tengan al mismo tiempo valores aceptables es decir, el valor de un campo determina si son correctos los valores de los demás datos.

Procesamiento duplicado, asegura la mayor exactitud si existe un acuerdo entonces se tienen procesamientos específicos para resolver las diferencias.

METODO PARA LA CORRECCIÓN DE DATOS

DE LA TRANSACCIÓN

CORRECCIÓN AUTOMÁTICA, este método para validar los datos se emplea con el fin de reducir el número de pasos necesarios para corregir errores o rechazos de transacciones durante el procesamiento. Este método solo requiere que el programa detecte un error y efectúe la corrección automática.

VERIFICACIÓN DE DÍGITOS, este método añade un dígito más al dato que será utilizado con fines de identificación. El dígito de verificación se añade al número original antes que se haga uso de este.

PRUEBAS DE SISTEMAS

DISEÑO DE CONTROLES.

Los analistas de sistemas deben anticipar los errores que pueden ocurrir al ingresar los datos en el sistema o al solicitar la ejecución de ciertas funclgiics.

Algunos errores no tienen ninguna importancia ni consecuencias, pero otros pueden ser tan serios qtie ocasionarían el borrado de los datos o el uso inapropiado de¡ sistema, aunqtie existe sólo la más iiiíninia probabilidad de cometer iin error serio, in buen diseño de sistemas de información ofrecerá los medios para detectar y manejar el error.

Los controles de entrada proporcionan medios para:

· Asegurar que sólo los usuarios autorizados tengan acc.-so al sistema.

· Garantizar que las transacciones sean aceptables.

· Validar los datos para comprobar su exactitud.

· Determinar si se han omitido datos que son necesarios.

VALIDACION.

Método cuya finalidad es detectar errores en las entrada de datos,

Verificación de las Transacciones.- identifica todas las transacciones que no sean validas porque estén incompletas o fuera de lugar.

Controles de Lote: Es un termino que significa proceso retardado por la acumulación de transacciones. Existe la posibilidad de que algunas de ellas se mal procesada o pasada por alto

Durante la sesión es importante conocer el número de lotes acumulados y enviados con la finalidad de que todos sean procesados y no pasados por alto.

Debe de asegurar que t,)das las transacciones sean procesadas adectiadamente, El tamaño de lote señalan si todas transacciones se encuentran en el lote, el conteo en el lote señala si se ha perdido u olvidado, alguna y el total por le señala cuando las transacciones han sido procesos.

Validación de las Transacciones.- Los pasos que el sistema sigue para asegurarse de que las transacciones es aceptable.

Pruebas de Secuencia: Utilizan códigos en los datos para probar una de las condiciones del sistema. Es importante el orden de las transacciones, señalan faltantes, no tiene caso particular transacciones donde falten datos.

Prueba de Completez: Son una forma más de validar las transacciones y con esto asegurar que estas sea)i exactas y aceptables para que el sistema pueda procesarla y almacenara.

verificación de los datos de la transacción,

Aun las transacciones válidas pueden contener datos que no lo son. Por lo consiguiente, los analistas deben asegurarse de especificar métodos para validar los datos cuando desarrollan los procedimientos de entrada, Existen 4 métodos para validar los datos:

Pruebas de existencia: Algunos de los cambios de datos de las transacciones son diseñados para no dejarlos vacíos o en blanco, Las pruebas de existencia examinan los campos esenciales para determinar que estos contengan datos. Por ejemplo en el procesamiento de] inventario, no es como aceptar pedidos que no especifiquen la cantidad solicitada de determinado articulo, Es inaceptable dejar en blanco este campo y esto, a su vez, es un indicador de que se ha cometido sin error.

Pruebas de limites: Estas pruebas verifican la veracidad de los datos de tina transacción. Las pruebas de límites sirven para validar la cantidad mínima o maxima aceptable para un dato. Las pruebas de rango ,,aildan tanto los valores mínimo como máximo.

Pruebas de combinación: Las pruebas de zorr'¿,inación validan el hecho de que varios datos tengan al mismo tiempo valores aceptables; en otras palabras, el valor de tin campo determina si son correctos los valores de los demás datos.

Procesamiento duplicado: En áreas especialmente importantes, quizás sea necesario procesar los datos más de una vez, ya sea en un equipo diferente o en sin forma distinta, Después de dicho procesamiento, los resultados se comparan para determinar si] consistencia y exactitvid. El procesamiento diplicado asegura la mayor exactitud.

modificación de los datos de la transacción.

Una tercera forma de validación de los datos implica modificar los mismos datos, Dos de los métodos vitilizados son la corrección automática de errores y los dígitos de autoverificación de los campos llave.

Corrección automática.,- Este método para al dar los datos se emplea con el fin de reducir el número de pasos necesarios para correcciones o rechazos de transacciones durante el procesamiento. Este método solo requiere que el programa detecte el error y efectué la corrección en forma automática.

Dígitos de verificación- Dos de los errores más comunes en el manejo de datos se presentan cuando los datos son capturados en forma 'incorrecta, estos errores se conocen como errores de transcripción. Este método, de-,ominado dígito de verificación, haga de un dígito más al dato que será utilizado con fines de identificación. El dígito de verificación se añade al número original aires se haga uso de éste.

DISEÑO DE ENTRADA DE DATOS

El diseño de la entrada es el enlace que une al sistema de información con el mundo y sus usuarios.

Los analistas de sistemas deciden los siguientes de talles del diseño de entradas:

l. Qué datos ingresan al sistema.

2. Qué medios utilizar.

3. La forma en que se deben disponer o codificar los datos.

4. El diálogo que servirá de guía a los usuarios para dar entrada a los datos.

5. Validación necesaria de datos y transacciones para detectar errores.

6. Métodos para llevar a cabo la validación de las entradas y los pasos a seguir ctiando se presentan errores.

Las decisiones de diseño para el manejo de entradas, especifican la forma en que serán aceptados datos para su procesamiento por computadora.

Los analistas deciden si los datos serán proporcionados directamente, quizá a través de una estación de trabajo, o por el uso de documentos, como talones de venta, cheques bancarios o facturas donde los datos a su vez son transferidos a la computadora para su procesamiento.

El diseño de la entrada también incluye la especificación de los medios por los que tanto los usuarios finales coi-no los operadores darán instrucciones al sistema sobre las acciones que debe emprender.

El diseiío de la entrada especifica como deben ingresar los datos en sistema por lotes o línea para su procesamiento.

.Los sistemas en línea incluyen un dialogo o conversación entre los usuarios y el sistema. Por medio del dialogo el usuario solicita servicios al sistema y le indica cuando realizar cierta función.

ASPECTOS QUE GUIAN EL DISEÑO DE ENTRADAS.

Algunos aspectos del diseño cambian, lo que dependen si el sistema esta orientado hacia lotes o línea. Pero sin considerar el sistema existen aspectos generales en la entrada que se deben tener en cuenta. Estos aspectos son los objetivos de diseiío de la entrada y los métodos de captura de datos.

OBJETIVOS DEL DISE.ÑO DE ENTRADAS

Los analistas de sistemas deben anticipar los

errores que pueden ocurrir al ingresar los datos en el sis.

Al disminuir los requerimientos de los datos o entrada se pueden reducir los costos y

asegurar todo el proceso desde la captiira de datos hasta que los resultados llegan a manos de los usuarios.

Ei,itar los retrasos..- un retraso en el procesamiento que es resultado de las operaciones o de entradas de datos, recibe el nombre de cuello de botella. Evitar los cuellos de botellas debe ser siempre uno de los objetivos que el analista persiga al diseñar la entrada.

Evitar los errores en los datos.- en cierto sentido la tasa de errores depende de la cantidad de datos, ya que entre más pequeña sea esta menores serán las oportunidades para cometer errores.

Evitar los pasos adicionales.- algunas veces el volumen de transacciones y la cantidad de datos en preparación, o el trabajo de entrada de datos, es algo que no se puede controlar. Cuando no es posible reducir el volumen de las transacciones, el analista debe asegurar que el proceso sea lo mas eficiente posible, evitando disefío para la entrada que traigan corno consecuencia una mayor cantidad de pasos a seguir.

Mantener la sencillez del proceso.- el analista debe alcanzar todos los objetivos de la forma más sencilla posible. Cuesta trabajo que los usuarios acepten diseños para la entrada que sean complejos confusos

LINEAMIENTOS PARA LA CAPTURA

Existen dos tipos de datos que deben proporcinarse como entradas cuando se procesan transacciones.

1 . Datos variables.--son aquellos datos que cambian para cada transacción o toma de decisiones.

2. Datos de identificación..- es el dato que identifica en forma única el artículo que esta siendo procesado.

Los procedimientos de entrada no deben incluir lo siguiente:

1 . Datos constantes.- datos que son los mismos para cualquier transacción.

2. Detalles que e de recul2erw.- Sor¡ los datos almacenados que el sistema puede recuperar con rapidez de sus archivos.

3. Detalles que el sistema quede calcular.- Son los resultados que se pueden producir al pedir que el sistema utilice combinaciones de datos almacenados y proporcionados

DISENO DE DOCUMENTOS FUENTE

El documento fuente es la forma en la que inicialmente se capturan los datos.

Para diseñar el documento fuente el analista primeramente debe decidir que datos va a capturar. Una vez hecho esto debe desarrollar una forma para el documento en la que se muestre que datos van a incluirse y dónde serán colocados. El documento también incluye

títulos e información que le dice al usuario para completar la forma y qué información se debe de proporcionar.

FORMAS

La fonna organiza el documento al colocar la información importante donde más llame la atención y establece la secuencia apropiada de datos.

En el diseño de la forma se deben considerar las zonas en las que se divide una forma.

Los encabezados aparecen en la parte superior de la fon-na, los totales y otros resultados en la parte inferior. La información utilizada con mayor frecuencia aparece en la parte superior y del lado izquierdo.

Otro aspecto a considerar en las fon-nas es que se tenga el suficiente espacio para proporcionar la infon-nación solicitada.

TITULOS Y CAPTURA DE DATOS

Los títulos sobre el documento fuente le dicen al usuan'o que dato proporcionar v dónde debe asentarlo. Los títulos tienen que ser breves pero fáciles de comprender, con términos estándares que conozcan todas las personas que utilicen la forma. En general se deben evitar las abreviaturas.

METODOS DE CODIFICACION

Los métodos de codificación se utilizan para acelerar todo el proceso, controlar los errores y reducir la entrada; con ellos las condiciones, palabras, ideas o relaciones se expresan por medio de un código. El código es un número, título o símbolo breve que se emplea en lugar de una descripción más larga o ambigua.. Con el código se necesitan menos detalles de la entrada, pero esto no trae como consecuencia pérdida de la información. Existen seis métodos de clasificación.

Códigos de clasificación.- Estos colocan entidades separadas, como eventos, personas u objetos, en grupos distintos que reciben el nombre de clases. El código se emplea para distinguir una clase de otra

Los códigos de clasificación simplifican en gran medida el proceso de entrada porque sólo es necesario el código de un dígito. De esta manera se elimina la necesidad de escribir descripciones extensas o de hacer juicios..

Códigos de funciones.- Estos señalan las actividades o trabajos a efectuar sin proporcionar todos los detalles. Por ejemplo, el diseño para el procesamiento de un archivo puede especificar la adición de registros en una traripacción por medio de tina A o un 1, o de cualquier otro esquema de codificación que se seleccione.

Códigos de secuencia.- son números o letras asignados en secuencia. Ellos indican el orden en que ocurrirán los eventos.

Los códigos en secuencia también se emplean con fines de identificación, pero se asignan en el orden en que los clientes entran al sistema.

Códigos con subconjuntos de dígitos significativos.- Los códigos pueden dividirse en subconjuntos o subcódigos que son caracteres que forman parte de número de identificación y que tienen un significado especial. Los subcódigos dan al usuario

información adicional sobre el artículo.

Códigos nemónicos.- Estos códigos usan letras y símbolos del producto para describirlo en una forma visual. Por ejemplo, es útil usar el códi-o TV~BN-21 para describir un televisor de color de 21 pulgadas.

METODOS DE CAPTURA DE DATOS

Existen 4 métodos diferentes a considerar y cada uno emplea equipo y preparación de datos específicos:

Captura de datos fuente por medio de perforadoras.- En este método el documento fuente se llena mientras se lleva a cabo la transacción. Después los datos de la transacción se transcriben hacia una frma codificada y se perforan en tarjetas.

Captura de datos fuente con dispositivo teclado-almacenamiento.-Los datos ingresan al sistema por una estación de trabajo. A medida que se van ingresando los detalles la estación realiza verificaciones para detectar errores de escritura, números de

producto incorrecto o datos inaceptables.

Captura de datos fuente con un scanner.- Para esto se necesita un documento fuente que pueda ser utilizado de manera directa por el scanner como documento de entrada. Cuando ocurre la transacción los datos son escrito o marcados en forma tal que

puedan ser leídos.

Entrada directa a través terminales inteligentes.- Estas son similares a las de tubo de rayos catódicos y tienen capacidades de procesamiento como si contaran con un microprocesador en u interior.

Unidad V

DOCUMENTACIÓN

Se refiere a los datos que describen el sistema de procesamiento de datos o una parte de él como puede ser un programa.

La preparación de estos documentos es una fase necesaria en el procesamiento de datos por computadora pero a menudo es manejada en forma deficiente.

La principal finalidad de la documentación es comunicar. El analista al usuario, el analista al programador, el analista y el programador al operador, etc. Otros objetivos de la documentación son los siguientes:

Supervisión del avance del desarrollo de una aplicación.
Comunicación de los hechos del sistema a los usuarios.
Comunicación entre el personal que trabaja en el desarrollo del proyecto.
Obtención de la información necesaria para hacer correcciones o revisiones de un sistema o de sus programas en computadora.
Suministración e instrucciones de operación a los usuarios y operadores.
Ayuda para instruir al personal nuevo enseñándole el marco general de la aplicación y sus programas.
Preparar la reconstrucción del sistema en casos de que este se destruya.

La documentación es tan importante que muchas instalaciones reusan utilizar cualquier programa que no este documentado en forma adecuada. También la documentación se utiliza en todas las fases del ciclo de vida y es un factor importante para medir el avance y para el control de calidad.

Una regla razonable en la mayoría de los casos es el “si el proceso no está bien documentado no se debe realizar” además la revisión y el control de calidad adecuado solo son posibles cuando el trabajo está bien documentado.

La documentación es especialmente importante para el mantenimiento del programa y para contestar las preguntas que surjan acerca de la forma en que estas funcionan. Sin embargo cuando en una organización o empresa no se ha mantenido la documentación en forma adecuada y ha sido necesario modificar un programa se han visto en la necesidad de hacer una cantidad considerable de gastos extras.

La documentación cuenta con 4 tipos de documentos importantes, y cada uno de ellos tiene una finalidad, pero también puede haber documentación adicional como datos históricos acerca del análisis que se hizo antes de establecer el sistema.

DOCUMENTACIÓN DEL SISTEMA

Describe todo el sistema de aplicación del procesamiento de datos. Esta documentación es resultado de la fase de diseño y análisis. Proporciona una explicación completa del sistema de aplicación excepto que no tiene los detalles del programa. En general el sistema de documentación está compuesta de los siguientes elementos:

Definición del problema. Consiste en explicar las razones del sistema y lo que este hace.

Diagramas de flujo del sistema. Lógica general del procesamiento.

Especificaciones de datos y archivos. Matriz de las series y formatos de los archivos.

Especificaciones de entrada/salida. Estos son documentos o registros de planes de entrada y salida.

Control de errores del sistema.

Plan de pruebas del sistema

Especificación de programas.

MANUAL DE CORRIDAS

Los programadores preparan el manual de corridas en forma de documentación completa del programa, utilizado en la corrida del procesamiento de datos, es decir, contiene la documentación de un programa en una corrida.

INSTRUCCIONES AL OPERADOR DE LA COMPUTADORA

Las instrucciones que se dan al operador de la computadora para una corrida (a veces llamado libro de corridas de la consola) son una copia de la sección de operaciones del conjunto completa de documentos del manual de corridas.

Las instrucciones que se dan al operador para una corrida puede colocarse en un expediente a parte o talvez constituir una sección de una o más libretas de anotaciones que contengan las instrucciones que se dan al operador para todas las corridas.

INSTRUCCIONES PARA EL USUARIO

Típicamente las nuevas aplicaciones de procesamiento requieren que los usuarios lleven nuevas formas, utilicen nuevos informes y sigan nuevos procedimientos con respecto a los controles y corrección de errores. Se debe instruir al personal existente en los nuevos procedimientos del sistema y, también es necesario adiestrar al nuevo personal y al personal de reemplazo, por lo tanto debe haber una guía para el usuario o un conjunto de instrucciones al usuario para este sistema. Sin embargo esta guía se redacta en forma tal que sea legible para el usuario y no contenga detalles acerca de los programas y procesos para la computadora.

DISEÑO DEL SISTEMA

Produce detalles que establecen la forma en la que el sistema cumplirá con los registros identificados durante la fase del análisis (diseño lógico), desarrollo de software (diseño físico).

PROCESO DE DISEÑO

Se identifican primero los reportes y demás salidas que den producir el sistema.

Determinar con precisión los datos específicos para cada reporte y salida.

Indicar los datos de entrada, aquellos que serán calculados y los que deben ser almacenados.

Detallar los procedimientos de cálculo y los datos individuales.

Seleccionar as estructuras de archivo y los dispositivos de almacenamiento.

RESPONSABILIDADES EN EL DESARROLLO HECHOS POR LOS USUARIOS/ANALISTAS.

USUARIOS

Comprender el problema que va ha ser abordado por la aplicación.

Conocer los datos necesarios para abordar el problema.

Saber como utilizar el software.

Saber como utilizar el equipo.

Adherirse a los lineamientos y estándares establecidos.

NOTA: A cada responsabilidad del usuario corresponde una del analista.

ANALISTA

Reconocer los beneficios de las aplicaciones desarrolladas por los usuarios.

Traducir las necesidades generales de datos en especificaciones para estos y en requerimientos de procedimientos.

Proporcionar educación y página de entrenamiento.

Ser consultores del diseño y proceso de desarrollo de los usuarios.

Proporcionar asistencia en la detección y corrección de errores.

DESARROLLO DE PROYECTOS

PAG 28

PLAN

ESPECIFICACION DE REQUISITOS

DISEÑO

LISTADO

Un programa que funciona es solo una parte de una configuración de sw que incluye todos los elementos. La documentación es la base de un buen desarrollo y proporciona guías para la tarea de mantenimiento del Sw.

ESPECIFICACION DE PRUEBA

Ing. De Sw

Análisis

Diseño

Codificación

prueba

Mantto.

Ciclo de Vida Clásico

Comienzo

Recolección y refinamiento

Diseño rápido

Codificación del prototipo

Evaluación del prototipo por el cliente

Refinamiento del prototipo

Producto de Ingeniería

Identifican todos los requisitos conocidos y perfilan las áreas en donde sea necesario una mayor definición.

Representación de los aspectos del Sw visibles al usuario (met. De entrada y formato de salida)

Recolección de req. Y plan. Del prog. Inicial. Planificación basada en los comentarios de la gente

Analisis del riesgo basado en los req iniciales.

Análisis de riesgo basado en la reacción del cliente

Evaluación del cliente

Hacia el sistema final

Prototipo del sw

Prototitpo del siguiente nivel

Sistema de Ing.

PLANIFICACION

ANALISIS DE RIESGO

EVALUACION DEL CLIENTE

INGENIERIA

Procedimientos

Doctos

sistema

B.D.

Gente

Entrada

Salida

Actividades Agosto

Sem 1 sem 2 sem 3

Gente

Herramientas

HW/SW

ESPECIFICAR:

Habilidades requeirdas
Disponibilidad
Duración de las tareas
Fecha de comienzo

ESPECIFICAR:

Descripción
Disponibilidad
Duración del uso
Fecha de distribución

Planific. Del sist. Comerc.
Gestión de proyectos
Soporte
Análisis y diseño
Programación
Prueba e integración
Herramientas de simulación y creación de prototipos
Mantenimiento
estructura

B.D.

PROGRAMADOR

ESTIMACION DEL PROYECTO

Cuanto durara

Cuanto esfuerzo requerirá

Cuanta gente estará involucrada

PREDECIR RECURSOS

Que se requiere y el riesgo implicado

ESPECIFICACION DEL AMBITO DE SW

DESARROLLAR ESTIMACIONES TECNICAS

DESCOMPOSICION

MODELO DE ESTIMACION

H. AUTOMATICAS

Fecha final de lanzamiento de sist. Basado en comp. Ya han sido establecidos

Distribuir el esfuerzo del marco descrito

Fecha final es por la organización del sw

Distribución para hacer uso de los recursos y la fecha final se define después del análisis del elemento de sw

Análisis de requerimiento

Realizar dist.

Generar cod.

Realizar pruebas

Peq.

Proy.

INVOLUCRAR CLIENTE

COMPRENDER EL SIST

MIENTRAS SE ENSEÑA NO SE TRABAJA Y EL PROYECTO SE RETRASA

LA GETNE QUE ENSEÑA SERA LA MISMA QUE ESTA REALIZANDO EL TRABAJO

PLANIFICACION TEMP

RELAC. GENTE TRAB.

DEF. DE REQ.

MUNDO REAL

MODELO

OBSERVACION

MEDIDA

SUPOSICION

APROXIMACION

PREDICCION

VERIFICACION

MODIFICACION

INTERPRETACION

INTUICION

EXPERIENCIA

TEORIA

Datos

Pará-metro

Estructura

percibida

Presentación simbólica

Comportamiento

observado

Comportam.

Del modelo

MODELIZACION

DEL

SISTEMA

PARAMETROS DEL

SISTEMA ASIGNADO

Alternativa 1

Alternativa 2

Alternativa n

ENFOQUES

ALTERNATIVAS

EVALUACION DE ALTERNATIVAS

SELECCIÓN DE LOS CRITERIOS DE EVALUACION

RENDIMIENTO, COSTO

APLICACIÓN DE TECNICAS ANALITICAS

MODELOS

GENERACION DE DATOS

RESULTADOS DE LA EVALUACION

ANALISIS DE SENSIBILIDAD

ENFOQUE SELECCIONADO

ES FACIL

EL ENFOQUE

SELECCIONADO

SINTESIS Y

DEFINICION DEL

SISTEMA

EFECTIVIDAD EN COSTO

COSTO DE CICLO DE VIDA

EFECTIVIDAD DEL SISTEMA

Investigación y desarrollo de la inversión

Operación y soporte.

Rendimiento

Disponibilidad operativa

Dependencia

Capacidad

2ª- orden

1ª- orden

3ª- orden

De investigación

Diseño

Prueba y evaluación

Fabricación

Inventario

Mantenimiento

Rango y exactitud

Fiabilidad

Portabilidad

Soporte

Mantenimiento

ACCESIBILIDAD

MANEJO

FACILIDAD DE INTERCAMBIO

MONTAJE

FACILIDAD DE PRODUCCION

SERVICIO

SEGURIDAD

ALMACENAMIENTO

PROVISIONES DE PRUEBA

UTILIDADES

4ª- orden

5ª- orden

Transacción

o mantto.

Ent. De datos

Soporte para dec.

Generar

reportes

comunicado

Consulta

mantto.

Reporte

Respaldo

Esp. De

salida

Esp. De

entrada

Esp. De

archivo B.D.

Esp. De proced.

Requer. De

datos

Determ. El procedimiento

terminado

MODULO

MODULO L

MODULO

Parametros

Inf. De control

Llamada directa a un módulo subordinado.

La elección del módulo subordinado depende de los puntos de decisión o proceso iteractivo.

TRANSFERENCIA DE DATOS

INFORM. DE CONTROL

PRINCIPIO

MODULARIDAD Y

FRAGMENTACIÓN

ACOPLAMIENTO

DESCRIPCIÓN

Diseño de un sistema como jerarquía de módulos.

La fuerza de las relaciones entre módulos.

OBJETIVO

Diseñar la estructura en forma desc. Con módulo que realicen funciones específicas.

Maximizar la indepen- dencia entre los módulos

PRINCIPIO

COHESIÓN (INTEG).

EXTENSIÓN DE CONTROL

TAMAÑO

USO

COMPARTIDO

DESCRIPCIÓN

La fuerza de las relaciones dentro de un módulo.

No. de módulo subordinado al módulo que hace la llamada.

No. de instrucción que componen a un módulo.

Uso de un módulo por otros módulo.

OBJETIVO

Maximizar la cohesión de los elementos altamente relaciona- dos que deben estar en el mismo módulo.

Limita la extensión de control de 5 a 7 módulos.

Limitar el tamaño de forma que la función de todo módulo se centre en un solo propósito.

Evitar la duplicación.

CONTENIDO DE UN MODULO

Contenido de un módulo determinado por la función desarrollada.

(EDITAR UNA TRANSACCIÓN)

Contenido de un módulo determinado por la lógica del procesamiento.

(IMPRIMIR, DESPLEGAR, COPIAR)

Contenido de un módulo determinado por la lógica del procesamiento.

(OPERACIONES DE E/S)

Contenido no relacionado de un módulo.

EXPLICACIÓN

Todas las actividades en un módulo tiene el mismo propósito llevar acabo una función específica.

Todos los elementos de un módulo se refieren a los mismos datos o archivos.

Todos los datos se realizan juntos o manejan las mismas funciones.

Los módulos se desarrollan por tamaño o número de instrucciones.

MODULO QUE HACE

LA LLAMADA

MODULO

Módulo hace la llamada

Nombre del módulo

Rectángulo denota el módulo

Flecha indica que un módulo llama al otro; la dirección indica cual módulo hace la llamada. La flecha también implica a transferencia de información entre módulos.

Módulo

llamado

Nombre del módulo

Asegurarse de que la transacción es válida

Verificación de los datos contenidos en la transacción.

Asegurarse de que los datos sean válidos

Asegurarse que los datos no son válidos por causa de error.

• Controles de lote

• Validación de transacción

• Prueba de secuencia

• Prueba de completes

• Corrección automática

• Verificación de dígitos

• Prueba de existencia

• Verificación de limites o rangos

• Prueba de combinación

• Procesamiento duricado

Cambios de los datos de la transacción

TIPO DE PRUEBA

PRUEBA DE CARGA MAXIMA

PRUEBA DE ALMACENA- MIENTO

PRUEBA DE TIEMPO DE EJECUCIÓN

PRUEBA DE RECUPERACIÓN

PRUEBA DE PROCESAMIEN- TOS

PRUEBA DE FACTORES HUMANOS

DESCRIPCIÓN

Determinar si el sistema manejará el volumen de actividades que ocurran cuando el sistema este en el punto más alto de su demanda de procesamiento.

Determinar la capacidad del sistema para almacenar datos de transacciones en un disco u otros archivos.

Determinar el tiempo de maquina que el sistema necesita para procesar los datos de una transacción.

Determinar la capacidad del usuario para recuperar los datos o restablecer el sistema después de una falla.

Determinar la claridad de la documentación en los aspectos de operación y uso de un sistema haciendo que los usuarios lleven a cabo exactamente lo que el manual pide.

Determinar como utilizaran los usuarios el sistema a procesar datos o preparar informes.

Tal vez te pueda interesar:

Descargar

Enviado por:	Braulio Mendiola
Idioma:	castellano
País:	México

Palabras clave:

Ingeniería del software Modelos Ciclo de vida Software Identificación necesidades Documentación proyecto Tablas decisión

Te va a interesar