SISTEMAS DE INFORMACIÓN I TEORÍA

Transcripción

1 CONTENIDO: CICLO DE VIDA DE DESARROLLO DE SI DISEÑO- CODIFICACIÓN - PRUEBA - MANTENIMIENTO Material diseñado y elaborado por: Prof. Luis Eduardo Mendoza M. Revisado y actualizado por: Prof. Anna Grimán

2 DISEÑO El proceso de diseño traduce los requisitos en una representación lógica del SI que pueda ser establecida de forma que obtenga la calidad requerida antes de que comience la codificación. El diseño del SI es realmente un proceso multipaso que se centra en cuatro (4) atributos distintos: la estructura de los datos, la arquitectura del SI, el detalle procedimental y la caracterización de la interfaz. El analista debe diseñar procedimientos de control y respaldo para proteger al sistema y a los datos y producir paquetes de especificaciones de programa para los programadores. Cada paquete debe contener diseños de entrada y salida, especificaciones de archivos y detalles de procesamiento, y también puede incluir árboles o tablas de decisión, diagramas de flujo de datos, un diagrama de flujo del sistema y los nombres y funciones de cualquiera de las rutinas de código que ya hayan sido escritas. Al igual que con los requerimientos y el análisis, el diseño se documenta y forma parte de la configuración del SI.

3 DISEÑO MÉTODOS PARA EL DISEÑO DE SI DISEÑO ORIENTADO AL FLUJO DE DATOS. Es una metodología que utiliza las características del flujo de información para derivar la estructura de los programas. Un diagrama de flujo de datos se convierte en una estructura de programa (jerarquía de control o carta estructurada) usando una de las dos técnicas de correspondencias: El análisis de transformación se aplica a un flujo de información que exhibe unos límites claros para los datos entrantes y los salientes. El DFD se convierte en una estructura que asigna control a la entrada, al procesamiento y a la salida, en tres jerarquías de módulos separados. El análisis de transacción se aplica cuando un elemento de información hace que el flujo se bifurque hacia uno de entre muchos caminos. El DFD se convierte en una estructura que asigna el control a una subestructura que toma y evalúa una transacción. Otras subestructuras controlan todas la potenciales acciones de procesamiento basadas en una transacción. Se definen los módulos, se establecen las interfaces y se desarrollan las estructuras de datos. Estas representaciones del diseño forman la base de todo el trabajo posterior de desarrollo.

4 DISEÑO MÉTODOS PARA EL DISEÑO DE SI DISEÑO ORIENTADO A OBJETOS (DOO). Crea un modelo del mundo real que puede ser realizado en software. Los objetos representan el ámbito de la información, mientras que las operaciones describen el procesamiento asociado con el ámbito de la información. Los mensajes (un mecanismo de interfaz) proporcionan el medio por el que se invocan las operaciones. La característica distintiva del AOO/DOO es que los objetos saben qué operaciones se pueden aplicar sobre ellos. Este conocimiento se consigue combinando abstracciones de datos y de procedimientos en un solo componente de programa (denominado objeto o paquete). La metodología AOO/DOO consiste en tres pasos que requieren que el diseñador establezca el problema, defina una estrategia informal de resolución y formalice la estrategia, identificando objetos y operaciones, especificando interfaces y proporcionando detalles de implementación para las abstracciones de datos y de procedimientos. El papel del DOO es tomar las clases y los objetos básicos definidos en el AOO y refinarlos con detalles adicionales de diseño. Los diseños se representan mediante alguna de las notaciones gráficas existentes y el lenguaje de diseño de programas (por. Ej. Modelo de objetos o diagramas de clases).

5 DISEÑO MÉTODOS PARA EL DISEÑO DE SI DISEÑO ORIENTADO A LA ESTRUCTURA DE DATOS. Al igual que los anteriores, se centra en el ámbito de la información; sin embargo, en vez de centrarse en el flujo de los datos, los métodos orientados a la estructura de datos utilizan la estructura de la información como conductor para la derivación del diseño. Dos métodos importantes de este tipo de diseño son: El desarrollo de sistemas de Jackson (DSJ) introdujo un conjunto de notaciones preliminares que tienen poco que ver con las estructuras de datos, centrándose en el modelaje y el control del proceso. El diseño y la implementación del proceso continúa dependiendo de la representación de la estructura de datos. El desarrollo de sistemas estructurados en datos (DSED) incorporó elementos de las técnicas de flujo de datos (durante el análisis) y adapta métodos como el DSJ para sus procedimientos de diseño. Cada uno de los métodos de diseño orientados a la estructura de datos son hijos de los años 70. Cada uno abarca ideas importantes sobre la naturaleza del buen diseño y especifica métodos para lograrlo. Conforme estos métodos han madurado, su singular enfoque sobre las estructuras de datos se ha ido ensanchando, conforme ha evolucionado la concepción de lo que es calidad de sistemas.

6 DISEÑO DOS CONSIDERACIONES IMPORTANTES EN EL DISEÑO DE SI DISEÑO DE LA INTERFAZ DE USUARIO. Es la puerta hacia aplicaciones interactivas. El diseño de interfaces de usuario (denominadas también interfaces hombre-máquina) requiere el conocimiento tanto de factores humanos como tecnológicos. La percepción humana, el nivel de preparación y el perfil de comportamiento del usuario, así como el resto de las tareas que éste realiza, son factores que influyen en le diseño de una interfaz. Además, el estilo de la interfaz, la disponibilidad del hardware, la tecnología del software y la aplicación misma, son piezas del resultado final. DISEÑO DE APLICACIONES DE TIEMPO REAL. Abarca todos los aspectos del diseño convencional de aplicaciones aunque, al mismo tiempo, introduce un nuevo conjunto de criterios y aspectos de diseño. Debido a que el software de tiempo real debe responder a sucesos del mundo real en un tiempo dictado por dichos sucesos, cualquier tipo de diseño (arquitectónico, procedimental y de datos) se vuelve más complejo. El procesamiento de interrupciones y la tasa de transferencia de datos, las bases de datos distribuidas y los sistemas operativos, los lenguajes de programación especializados y los métodos de sincronización, son algunos de los asuntos que debe considerar el diseñador de sistemas de tiempo real.

7 CODIFICACIÓN El diseño debe traducirse en una forma legible para la(s) máquina(s). El paso de la codificación realiza esta tarea. Si el diseño se realiza de una manera detallada, la codificación puede realizarse mecánicamente. La codificación se encuentra en el corazón del proceso de la ingeniería del software; sin embargo, no hay que olvidar que le preceden pasos de importancia crítica, relegándola a alguna forma de traducción mecánica de las especificaciones del diseño detallado. Los programadores tienen el papel principal en esta fase, ya que diseñan, codifican y eliminan errores de sintaxis en las aplicaciones. Para asegurar la calidad, los programadores explican y comparten constantemente las partes complejas (un diseño o un ensayo de código) del programa a su equipo de programadores.

8 CODIFICACIÓN Las características psicológicas y técnicas de un lenguaje de programación afectan a la facilidad de la traducción del diseño y al esfuerzo requerido para la prueba y el mantenimiento del software. El estilo es un atributo importante del código fuente que puede determinar la inteligibilidad de un programa. Los elementos de estilo incluyen la documentación interna, los métodos de declaración de datos, los procedimientos de construcción de sentencias y las técnicas de codificación de la entrada/salida. Una derivación del estilo de codificación es la eficiencia obtenida en tiempo de ejecución y en memoria. Aunque la eficiencia puede ser un requisito muy importante, se debe recordar que un programa eficiente que sea inteligible tiene un valor muy cuestionable. Paralelamente durante esta fase, el analista de SI también trabaja con los usuarios para desarrollar documentación efectiva para el SI, incluyendo los manuales de procedimientos. La documentación le dice al usuarios la manera de usar el SI y también qué hacer si se presentan problemas con la aplicación.

9 PRUEBA Una vez que se ha generado el código, comienza la prueba de la aplicación. Antes de que pueda ser usado, el SI debe ser probado. Es mucho menos costoso encontrar problemas antes de que es SI sea entregado a los usuarios. La prueba se centra en la lógica interna de la aplicación, asegurando que todas las sentencias se han probado, y en las funciones externas, realizando pruebas que aseguren que la entrada definida produce los resultados que realmente se requieren. Algunas de las pruebas son realizadas por los programadores solos y otras por los analistas de SI junto con los programadores. Primero se ejecuta una serie de pruebas para que destaquen los problemas con datos de prueba y eventualmente con datos reales del sistema actual. El mantenimiento del SI y de su documentación comienzan en esta fase y es efectuado rutinariamente a lo largo de la vida del SI.

10 PRUEBA ESTRATEGIAS DE PRUEBA DE SI Para descubrir errores, se planifican y se ejecutan: Las pruebas de unidad y de integración se centran en la verificación funcional de cada módulo y en la incorporación de los módulos en una estructura de programa. La prueba de validación demuestra el seguimiento de los requisitos del software. La prueba del sistema valida la aplicación una vez que se ha incorporado en un sistema mayor. Cada paso de prueba se lleva a cabo mediante una serie de técnicas sistemáticas de prueba que ayudan en el diseño de casos de prueba. Con cada paso de prueba se amplía el nivel de abstracción con el que se considera el SI. A diferencia de la prueba (una actividad sistemática y planificada), la depuración se puede considerar un arte. A partir de una indicación sintomática de un problema, la actividad de depuración debe rastrear la causa del error.

11 PRUEBA DISEÑO DE CASOS DE PRUEBA DE SI El objetivo es derivar un conjunto de pruebas que tengan la mayor probabilidad de descubrir los defectos del software. Para lograr esto, se usan dos categorías diferentes de técnicas: Las pruebas de la caja blanca, también llamadas pruebas a pequeña escala, se centran en la estructura de control del programa. Se derivan casos de prueba que aseguren que durante la prueba se han ejecutado por lo menos una vez todas las sentencias del programa y que se ejercitan todas las condiciones lógicas. La prueba del camino básico hace uso de grafos de programa (o matrices de grafos) para derivar el conjunto de caminos linealmente independientes que aseguren la cobertura. La prueba de condiciones y del flujo de datos ejercitan más aun la lógica del programa. La prueba de bucles complementa a las otras técnicas de la caja blanca, proporcionando un procedimiento para ejercitar bucles de distintos grados de complejidad.

12 PRUEBA DISEÑO DE CASOS DE PRUEBA DE SI Las pruebas de caja negra son diseñadas para validar los requisitos funcionales sin fijarse en el funcionamiento interno de un programa. Se centran en el ámbito de la información de un programa, de forma que se proporcione una cobertura completa de la prueba. La partición equivalente divide el campo de entrada en clases de datos que tienden a ejercitar determinadas funciones del software. El análisis de valores límites prueba la habilidad del programa para manejar datos que se encuentran en los límites aceptables. Los grafos de causa-efecto se usan en una técnica que permite al encargado de la prueba validar complejos conjuntos de acciones y condiciones. Los experimentados realizadores de SI afirman que la prueba nunca termina, simplemente se transfiere del encargado del desarrollo al cliente. Cada vez que el cliente usa la aplicación, lleva a cabo una prueba.

13 MANTENIMIENTO El SI, indudablemente, sufrirá cambios después de que se entregue al cliente. Mucho del trabajo rutinario del programador consiste en el mantenimiento, ya que los negocios gastan gran cantidad de dinero en dicho mantenimiento. Una de las razones para realizar el mantenimiento de los SI es para mejorar las capacidades de las aplicaciones en respuesta a las necesidades organizacionales cambiantes, que involucran lo siguiente: Los usuarios frecuentemente solicitan características adicionales después de que se familiarizan con el SI y sus capacidades. El negocio cambia a través del tiempo. El hardware y el software cambian a un ritmo acelerado, impactando fuertemente el rendimiento y capacidades de los SI. El mantenimiento de los SI aplica cada uno de los pasos precedentes del ciclo de vida a una aplicación existente en vez de a uno nuevo.

14 MANTENIMIENTO Sobre las aplicaciones de computadora se llevan a cabo cuatro tipos de mantenimiento: El correctivo actúa para corregir errores que no han sido descubiertos antes de poner en uso el SI. El adaptativo se aplica cuando los cambios del entorno externo precipitan las modificaciones del SI. El perfectivo incorpora mejoras solicitadas por la comunidad de usuarios. El preventivo mejora la futura facilidad de mantenimiento y la fiabilidad como base para las futuras mejoras. Las tareas desarrolladas durante el proceso de ingeniería del software definen la facilidad de mantenimiento y tienen un gran impacto sobre el éxito de cualquier método de mantenimiento. La ingeniería de reversa extrae información de diseño del código fuente de un programa sin disponer de ninguna otra documentación. La reingeniería toma la información obtenida y reestructura el programa para conseguir una mayor calidad y, por tanto, una mejor facilidad de mantenimiento en el futuro.