You are on page 1of 4

DISEÑO DE ENTRADA Si mis datos de entrada no son los adecuados, el sistema me devolverá malos resultados… primero defino las

salidas y después determino que datos deberé ingresar. Ejemplo si no hago control de duplicaciones, no verifico la autenticación de artículos o alumnos, entonces mis entradas serán deficientes, erróneas o no válidas. Todas las cuestiones que no se validan cuando se programa nos darán futuros problemas y no será un sistema confiable. Por ello es que debemos diseñar, se usan los principios de diseño para minimizar el impacto que puede tener la información de salida generada por el sistema. Objetivos de diseño de entrada: 1. Efectivo: cada pantalla tiene su uso especifico 2. Preciso: cada campo tiene su propio dato correspondiente 3. Fácil de usar: el tipo de interfaz que uso (ej. Un combo para pocos datos) 4. Consistente: agrupación adecuada de los datos 5. Simple: tener la estética en cuenta sin alterar formas o amontonar datos 6. Atractivo: volcado a la estética del sistema 7. Calidad: datos adecuados, información relevante y bien definida Buen diseño de formas: no cualquiera puede llenar cualquier entrada o forma, cada entrada está orientada a un tipo de usuario. Es bueno tener siempre un archivo original para comparar inconsistencias (por ejemplo hay cosas que se modifican para impresión pero la copia digital se mantiene en su estado original). Formas fácil de llenar: deben tener títulos o referencias en los campos y dejar espacio para que se rellene el campo, es decir, indicar en forma clara que dato de está solicitando para ingresar. Será fácil de llenar cuando el lenguaje que utilice sea el adecuado (depende hacia quien va dirigido). Si no diseño algo que no vaya a cumplir los objetivos para los cuales irán dirigidos esos datos de entrada no me sirve de un pedo. Formas que aseguren el llenado preciso: depende de la cantidad de datos que requiero por ejemplo si lo doy a escoger entre 3 o 4 opciones directamente muestro esas opciones en pantalla de una sola vez, de esta forma soy yo el que está dando las opciones de llenado y solo depende de la elección del usuario. Esa carga también hace a la calidad de los datos ya que estos estarán uniformemente cargados. Si es posible planteo todas las máscaras posibles al usuario (formatos de presentación de los datos) Diseño y desarrollo de sistemas: Ciclo de vida del software El ciclo de vida del software es un marco de referencia que contiene los procesos, las actividades y las tareas involucradas en el desarrollo, la explotación y el
1

analizarlos como sistemas y codificar los procesos o comprar software empaquetado para resolver el problema inmediato.Investigación preliminar . también son los más rentables. Por lo tanto. Como hemos visto. así como también determinar cómo se reúnen mejor en un sistema global. y a veces. hay poco tiempo. es difícil interconectar los subsistemas de manera que se desempeñen fácilmente como un sistema. 1995] Se denomina ciclo de desarrollo del software al período de tiempo que comienza con la decisión de desarrollar un producto software y finaliza cuando se ha entregado éste. abarcando la vida del sistema desde la definición de requisitos hasta la finalización de su uso [ISO/IEC.Codificación . significa ver una descripción amplia del sistema y después dividirla en partes más pequeñas o subsistemas. Este ciclo incluye. Los problemas que requieren computarizarse normalmente se encuentran en el nivel más bajo de la organización.Mantenimiento Diseño ascendente (de abajo a arriba o bottom-up) Este diseño se refiere a identificar los procesos que necesitan computarizarse conforme surgen. Con frecuencia este tipo de problemas son estructurados y por lo tanto son más sensibles a la computarización. 1986] Según el modelo clásico tenemos: . una fase de instalación y aceptación [AECC. y por lo tanto dichos objetivos no se pueden cumplir. Cuando los analistas de sistemas utilizan un enfoque descendente. presupuesto o paciencia del usuario para la depuración de interconexiones delicadas que se han ignorado. Es muy costoso corregir las fallas de la interconexión y muchas de ellas no se descubren sino hasta que se completa la programación.mantenimiento de un producto de software. El enfoque descendente también proporciona el énfasis deseable en la colaboración o interconexiones que los sistemas y sus subsistemas necesitan. el cual falta en el enfoque ascendente. El diseño descendente permite a los analistas de sistemas determinar primero los objetivos organizacionales globales. en general. el nombre ascendente se refiere al nivel inferior en el cual se introduce primero la computarización. Una es que hay duplicidad de esfuerzo en comprar software e incluso en introducir los datos. Diseño descendente (de arriba abajo o top-down). Después el analista divide dicho sistema en subsistemas y sus requerimientos. es que no se consideran los objetivos organizacionales globales.Prueba . Cuando la programación interna se hace con un enfoque de ascendente. al considerar el sistema global hay serias limitantes para tomar un enfoque de ascendente. En esta situación. una fase de implantación. Las ventajas de usar un enfoque descendente para el diseño de sistemas incluyen evitar el caos de intentar diseñar un sistema de repente.Análisis . están pensando en la manera en que las interrelaciones e interdependencias de subsistemas se adaptan a la organización existente. planear e implementar sistemas de información de administración es increíblemente 2 . una fase de requisitos. una fase de diseño. Una tercera. Otra es que se introducen datos inválidos en el sistema. una fase de pruebas. Aunque cada subsistema aparenta conseguir lo que quiere.Diseño . y quizás la desventaja más seria del enfoque ascendente. cuando los analistas intentan reunir el sistema en la fecha límite señalada para la entrega.

nómina.complejo. Intentar colocar todos los subsistemas en su lugar y ejecutarlos en seguida es casi un fracaso seguro. La administración de la calidad total y el enfoque descendente para diseñar pueden estar relacionados. Hay algunas dificultades con el diseño descendente que el analista de sistemas necesita saber. Una sugerencia es negociar información regular entre los equipos del subsistema. Voy a documentar la 3 . Además. Una segunda ventaja es que permite separar a los equipos de análisis de sistemas para trabajar en paralelo en diferentes subsistemas. Un segundo riesgo es que una vez que se hacen las divisiones de un subsistema. La estructura necesaria para el control de calidad está en el lugar. actualización e impresión)  NIVEL DE MODULO (por ejemplo leer clasificar escribir en archivos e imprimir datos) Enfoque sistémico y estructurado Divide y vencerás Administrar mejor los recursos Mínimo acoplamiento es fácil mantenimiento Es más fácil el mantenimiento del sistema Repaso estructurado: es poder documentar cuantos subsistemas estamos desarrollando. sus interfaces se podrían descuidar o ignorar. Se debe poner atención a las necesidades que se traslapen y a la compartición de recursos de manera que la partición en subsistemas tenga sentido para todos los sistemas. Es necesario detallar de quién es la responsabilidad de las interfaces. etc. El uso de equipos para el diseño de subsistemas se ajusta particularmente bien a un enfoque de control de calidad total. quien está codificando y haciendo las pruebas. Una tercera advertencia que acompaña al uso de un diseño descendente es que los subsistemas se deben reintegrar eventualmente. administración de edición. evita que los analistas de sistemas se metan tanto en los detalles que pierdan de vista lo que se supone que el sistema hace. hay integración entre los módulos. otra es usar herramientas que permiten flexibilidad si se requieren cambios para los subsistemas interrelacionados. Una tercera ventaja es que un enfoque descendente evita un problema mayor asociado con un enfoque ascendente. contabilidad y sistemas de producción)  NIVEL DE SISTEMAS OPERACIONALES (por ejemplo. Los mecanismos para la reintegración se necesitan poner en funcionamiento desde el principio. La primera es el riesgo de que el sistema se divida en subsistemas "erróneos".  NIVEL DE OBJETIVOS ORGANIZACIONALES (coordinar los sistemas para conocer los objetivos de la compañía)  NIVEL DE SISTEMAS FUNCIONALES (por ejemplo. Los grupos de trabajo establecidos de esta forma después pueden servir a una función dual como círculos de calidad para el sistema de información de administración. lo cual puede ahorrar mucho tiempo. El enfoque descendente proporciona el grupo de sistemas con una división más natural de usuarios en grupos de trabajo para subsistemas. aceptamos el trabajo o hubo que modificarlo. así como la motivación apropiada para obtener el subsistema para lograr las metas departamentales que son importantes para los usuarios involucrados. es importante que cada subsistema solucione el problema correcto.

se dibujan dos tipos de flechas.metodología. entre otros. La documentación es importante para registrar las soluciones. Este resultado rompe con el modelo de un módulo funcional: un módulo sólo debe desempeñar una tarea. Cuando finalmente se programan estos módulos. los modulos. se permite que un módulo de nivel inferior tome una decisión y el resultado es un módulo que desempeña dos tareas diferentes. los errores que surgieron. Si mi aplicación no cumple específicamente con las actividades de la empresa no puedo realizar un manual adecuado. Los módulos de nivel superior se numeran por lOOs o l. Este gráfico simplemente es un diagrama que consiste de cuadros rectangulares. Esta enumeración permite a programadores insertar módulos que usan un número entre los números de módulo adyacentes.. Cuando el control se pasa en forma descendente. El analista debe mantener a la perfección este acoplamiento al mínimo. Las banderas de control deciden qué parte de un módulo se ejecuta y están asociadas con las instrucciones IR. Por ejemplo para una pantalla de ventas tendré que contar con el relevamiento de ventas (circuito total del procedimiento de una venta). las respuestas de los problemas más frecuentes. el código. El control se diseña para ser pasado de los módulos de nivel inferior a los de nivel superior en la estructura. Cuando hay pocas parejas de datos y banderas de control en el sistema. Sin embargo. es importante pasar el menor número de parejas de datos entre los módulos. Estas flechas indican que algo se pasa hacia abajo al módulo inferior o hacia arriba al superior. Existe una técnica que es el Folclore. el motor utilizado.ELSE. Además la documentación es un elemento que hace la calidad del software y un medio de soporte para el usuario y que pueda satisfacer sus necesidades Informe de relevamiento: da pie a todo mi análisis.000s y los módulos de nivel inferior se numeran por lOs o lOOs. Identificar totalmente el funcionamiento de la empresa. las fechas.. Básicamente para escribir el manual de procedimientos tengo que saber el funcionamiento de las cosas Uso de diagramas de estructura para diseñar sistemas Es una herramienta recomendada para diseñar un sistema modular descendente. Un interruptor es lo mismo que una bandera de control excepto por que está limitado por dos valores: sí o no. la técnica y/o herramienta que utilizamos para analizar y diseñar..THEN. los cuales representan los módulos.. Aún más importante es que se deben evitar las banderas de control numerosas. y otros tipos similares de instrucciones. el lenguaje que utilizamos. 4 .. lo más fácil es cambiar el sistema. Manual de Procedimientos: Se tendrá que conocer todas las actividades de la organización. Las flechas con los círculos vacíos se denominan parejas de datos y las flechas con los círculos rellenados se denominan banderas de control o interruptores. en raras ocasiones será necesario pasar el control hacia abajo en la estructura. y de flechas de conexión. A los lados de las líneas de conexión.