DISEO DE ENTRADA Si mis datos de entrada no son los adecuados, el sistema me devolver malos resultados primero defino las

salidas y despus determino que datos deber ingresar. Ejemplo si no hago control de duplicaciones, no verifico la autenticacin de artculos o alumnos, entonces mis entradas sern deficientes, errneas o no vlidas. Todas las cuestiones que no se validan cuando se programa nos darn futuros problemas y no ser un sistema confiable. Por ello es que debemos disear, se usan los principios de diseo para minimizar el impacto que puede tener la informacin de salida generada por el sistema. Objetivos de diseo de entrada: 1. Efectivo: cada pantalla tiene su uso especifico 2. Preciso: cada campo tiene su propio dato correspondiente 3. Fcil de usar: el tipo de interfaz que uso (ej. Un combo para pocos datos) 4. Consistente: agrupacin adecuada de los datos 5. Simple: tener la esttica en cuenta sin alterar formas o amontonar datos 6. Atractivo: volcado a la esttica del sistema 7. Calidad: datos adecuados, informacin relevante y bien definida Buen diseo 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 impresin pero la copia digital se mantiene en su estado original). Formas fcil de llenar: deben tener ttulos 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 fcil de llenar cuando el lenguaje que utilice sea el adecuado (depende hacia quien va dirigido). Si no diseo algo que no vaya a cumplir los objetivos para los cuales irn 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 eleccin del usuario. Esa carga tambin hace a la calidad de los datos ya que estos estarn uniformemente cargados. Si es posible planteo todas las mscaras posibles al usuario (formatos de presentacin de los datos) Diseo 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 explotacin y el
1

mantenimiento de un producto de software, abarcando la vida del sistema desde la definicin de requisitos hasta la finalizacin de su uso [ISO/IEC, 1995] Se denomina ciclo de desarrollo del software al perodo de tiempo que comienza con la decisin de desarrollar un producto software y finaliza cuando se ha entregado ste. Este ciclo incluye, en general, una fase de requisitos, una fase de diseo, una fase de implantacin, una fase de pruebas, y a veces, una fase de instalacin y aceptacin [AECC, 1986] Segn el modelo clsico tenemos: - Investigacin preliminar - Anlisis - Diseo - Codificacin - Prueba - Mantenimiento Diseo ascendente (de abajo a arriba o bottom-up) Este diseo se refiere a identificar los procesos que necesitan computarizarse conforme surgen, analizarlos como sistemas y codificar los procesos o comprar software empaquetado para resolver el problema inmediato. Los problemas que requieren computarizarse normalmente se encuentran en el nivel ms bajo de la organizacin. Con frecuencia este tipo de problemas son estructurados y por lo tanto son ms sensibles a la computarizacin; tambin son los ms rentables. Por lo tanto, el nombre ascendente se refiere al nivel inferior en el cual se introduce primero la computarizacin. Cuando la programacin interna se hace con un enfoque de ascendente, es difcil interconectar los subsistemas de manera que se desempeen fcilmente como un sistema. Es muy costoso corregir las fallas de la interconexin y muchas de ellas no se descubren sino hasta que se completa la programacin, cuando los analistas intentan reunir el sistema en la fecha lmite sealada para la entrega. En esta situacin, hay poco tiempo, presupuesto o paciencia del usuario para la depuracin de interconexiones delicadas que se han ignorado. Aunque cada subsistema aparenta conseguir lo que quiere, al considerar el sistema global hay serias limitantes para tomar un enfoque de ascendente. Una es que hay duplicidad de esfuerzo en comprar software e incluso en introducir los datos. Otra es que se introducen datos invlidos en el sistema. Una tercera, y quizs la desventaja ms seria del enfoque ascendente, es que no se consideran los objetivos organizacionales globales, y por lo tanto dichos objetivos no se pueden cumplir. Diseo descendente (de arriba abajo o top-down), significa ver una descripcin amplia del sistema y despus dividirla en partes ms pequeas o subsistemas. El diseo descendente permite a los analistas de sistemas determinar primero los objetivos organizacionales globales, as como tambin determinar cmo se renen mejor en un sistema global. Despus el analista divide dicho sistema en subsistemas y sus requerimientos. Cuando los analistas de sistemas utilizan un enfoque descendente, estn pensando en la manera en que las interrelaciones e interdependencias de subsistemas se adaptan a la organizacin existente. El enfoque descendente tambin proporciona el nfasis deseable en la colaboracin o interconexiones que los sistemas y sus subsistemas necesitan, el cual falta en el enfoque ascendente. Las ventajas de usar un enfoque descendente para el diseo de sistemas incluyen evitar el caos de intentar disear un sistema de repente. Como hemos visto, planear e implementar sistemas de informacin de administracin es increblemente
2

complejo. Intentar colocar todos los subsistemas en su lugar y ejecutarlos en seguida es casi un fracaso seguro. Una segunda ventaja es que permite separar a los equipos de anlisis de sistemas para trabajar en paralelo en diferentes subsistemas, lo cual puede ahorrar mucho tiempo. El uso de equipos para el diseo de subsistemas se ajusta particularmente bien a un enfoque de control de calidad total. Una tercera ventaja es que un enfoque descendente evita un problema mayor asociado con un enfoque ascendente; 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 algunas dificultades con el diseo descendente que el analista de sistemas necesita saber. La primera es el riesgo de que el sistema se divida en subsistemas "errneos". Se debe poner atencin a las necesidades que se traslapen y a la comparticin de recursos de manera que la particin en subsistemas tenga sentido para todos los sistemas. Adems, es importante que cada subsistema solucione el problema correcto. Un segundo riesgo es que una vez que se hacen las divisiones de un subsistema, sus interfaces se podran descuidar o ignorar. Es necesario detallar de quin es la responsabilidad de las interfaces. Una tercera advertencia que acompaa al uso de un diseo descendente es que los subsistemas se deben reintegrar eventualmente. Los mecanismos para la reintegracin se necesitan poner en funcionamiento desde el principio. Una sugerencia es negociar informacin regular entre los equipos del subsistema; otra es usar herramientas que permiten flexibilidad si se requieren cambios para los subsistemas interrelacionados. La administracin de la calidad total y el enfoque descendente para disear pueden estar relacionados. El enfoque descendente proporciona el grupo de sistemas con una divisin ms natural de usuarios en grupos de trabajo para subsistemas. Los grupos de trabajo establecidos de esta forma despus pueden servir a una funcin dual como crculos de calidad para el sistema de informacin de administracin. La estructura necesaria para el control de calidad est en el lugar, as como la motivacin apropiada para obtener el subsistema para lograr las metas departamentales que son importantes para los usuarios involucrados. NIVEL DE OBJETIVOS ORGANIZACIONALES (coordinar los sistemas para conocer los objetivos de la compaa) NIVEL DE SISTEMAS FUNCIONALES (por ejemplo, nmina, contabilidad y sistemas de produccin) NIVEL DE SISTEMAS OPERACIONALES (por ejemplo, administracin de edicin, actualizacin e impresin) NIVEL DE MODULO (por ejemplo leer clasificar escribir en archivos e imprimir datos) Enfoque sistmico y estructurado Divide y vencers Administrar mejor los recursos Mnimo acoplamiento es fcil mantenimiento Es ms fcil el mantenimiento del sistema

Repaso estructurado: es poder documentar cuantos subsistemas estamos desarrollando, quien est codificando y haciendo las pruebas, hay integracin entre los mdulos, aceptamos el trabajo o hubo que modificarlo, etc. Voy a documentar la
3

metodologa, la tcnica y/o herramienta que utilizamos para analizar y disear, el lenguaje que utilizamos, el cdigo, el motor utilizado, las fechas, los modulos. La documentacin es importante para registrar las soluciones, las respuestas de los problemas ms frecuentes, los errores que surgieron, entre otros. Existe una tcnica que es el Folclore. Adems la documentacin 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 anlisis. Identificar totalmente el funcionamiento de la empresa. Si mi aplicacin no cumple especficamente con las actividades de la empresa no puedo realizar un manual adecuado. Manual de Procedimientos: Se tendr que conocer todas las actividades de la organizacin. Por ejemplo para una pantalla de ventas tendr que contar con el relevamiento de ventas (circuito total del procedimiento de una venta). Bsicamente para escribir el manual de procedimientos tengo que saber el funcionamiento de las cosas

Uso de diagramas de estructura para disear sistemas Es una herramienta recomendada para disear un sistema modular descendente. Este grfico simplemente es un diagrama que consiste de cuadros rectangulares, los cuales representan los mdulos, y de flechas de conexin. Los mdulos de nivel superior se numeran por lOOs o l,000s y los mdulos de nivel inferior se numeran por lOs o lOOs. Esta enumeracin permite a programadores insertar mdulos que usan un nmero entre los nmeros de mdulo adyacentes. A los lados de las lneas de conexin, se dibujan dos tipos de flechas. Las flechas con los crculos vacos se denominan parejas de datos y las flechas con los crculos rellenados se denominan banderas de control o interruptores. Un interruptor es lo mismo que una bandera de control excepto por que est limitado por dos valores: s o no. Estas flechas indican que algo se pasa hacia abajo al mdulo inferior o hacia arriba al superior. El analista debe mantener a la perfeccin este acoplamiento al mnimo. Cuando hay pocas parejas de datos y banderas de control en el sistema, lo ms fcil es cambiar el sistema. Cuando finalmente se programan estos mdulos, es importante pasar el menor nmero de parejas de datos entre los mdulos. An ms importante es que se deben evitar las banderas de control numerosas. El control se disea para ser pasado de los mdulos de nivel inferior a los de nivel superior en la estructura. Sin embargo, en raras ocasiones ser necesario pasar el control hacia abajo en la estructura. Las banderas de control deciden qu parte de un mdulo se ejecuta y estn asociadas con las instrucciones IR..THEN...ELSE... y otros tipos similares de instrucciones. Cuando el control se pasa en forma descendente, se permite que un mdulo de nivel inferior tome una decisin y el resultado es un mdulo que desempea dos tareas diferentes. Este resultado rompe con el modelo de un mdulo funcional: un mdulo slo debe desempear una tarea.