La calidad en los Sistemas de Información
La administración de la calidad total es un concepto que hace de la calidad una responsabilidad total a ser compartida por todas las personas dentro de una institución, con el alcance del control de calidad considerado como un fin en sí mismo.
Como contribuyen los Sistemas de Información a la Administración de la calidad total.
Mientras más trata una empresa de llevar a cabo su programa, más los sistemas de información pueden contribuir a su éxito en toda la empresa.
Los sistemas de información pueden desempeñar un papel especial en los programas corporativos de calidad porque están profundamente involucrados con el trabajo diario de otros departamentos a lo largo de toda la institución.
La necesidad de aseguramiento de la calidad en el software.
La producción de software es única y presenta su propio conjunto de problemas. Una característica especial del desarrollo de software es que su meta normal es construir sólo un ejemplar del producto final. Para la mayor parte de los productos manufacturados una vez que se inicia el desarrollo, se fabrican cientos, miles o aun millones de copias del producto. Con el software, los problemas de calidad deben resolverse desde la primera vez; el diseño debe ser de la más alta calidad a la primera.
El cumplir con las necesidades del usuario puede ser difícil en un proceso en donde el usuario final se compromete con el producto antes de que éste se haya construido. La mayor parte de los proyectos de desarrollo de sistemas se inicia en la definición de los requerimientos de información del usuario y en las especificaciones en la forma de análisis de sistemas y documentos de diseño.
Mantenimiento.
El mantenimiento, el proceso de modificación de un sistema en uso productivo, es la fase más cara del proceso de desarrollo de sistemas.
La empresa puede experimentar fuertes cambios internos en su estructura o liderazgo, o el cambio puede venir del medio ambiente. Estos cambios organizacionales afectan los requerimientos de información. Pero una causa igualmente común de problemas de mantenimiento a largo plazo es el análisis de requerimientos de información.
Para ser capaz de manejar el mantenimiento rápida y económicamente, un sistema de software debe ser flexible. Un sistema flexible puede ser reparado de manera más rápida y fácil cuando ocurran los problemas. Tal sistema puede también ser modificado a medida que los requerimientos de los sistemas cambien con el tiempo, que es con toda seguridad lo que ha de pasar. De lo contrario un sistema que pueda tener éxito en el corto plazo puede ser un fracaso en el largo. La inflexibilidad es un problema muy común. Sin embargo, aun cuando diseñen un sistema flexible, la flexibilidad puede llegar a verse como demasiado cara y consumidora de tiempo. Sus beneficios no siempre son comprendidos o apreciados por los usuarios.
Monsergas y Defectos.
Un problema importante con el software es la presencia de monsergas ocultas o defectos en el código de programas. Es imposible eliminar a todas las monsergas de los grandes programas. La fuente principal de monsergas es la complejidad del código de toma de decisiones.
Pero la presencia de estas monsergas puede tener resultados costosos y aun desastrosos
Un sistema de calidad debe:
•Alcanzar las metas de los negocios articuladas por el departamento de usuarios.
•Operar a un costo aceptable, dimensionalmente congruente con el valor producido para la empresa.
•Cumplir escrupulosamente con las normas de desempeño definidas (como tiempo de respuesta y disponibilidad de sistemas).
•Producir un resultado preciso y confiable.
•Ser fácil de aprender y utilizar.
•Ser flexible.
Algunas soluciones a problemas de calidad en Sistemas de Información.
Los sistemas de información son complejos, y las soluciones a problemas de calidad también.
El papel de las metodologías.
Para limitar los problemas e incrementar la calidad al construir sistemas, los desarrolladores deben empezar con una metodología disciplinada que establezca normas para todas las fases del proyecto. Las buenas metodologías de desarrollo se refieren a las metodologías de desarrollo estructurado, donde se proporciona:
•Métodos probados para determinar y documentar las especificaciones del sistema y su diseño.
•Normas de programación cuyo resultado sea un código comprensible, susceptible de mantenimiento y que no sea demasiado complejo.
•Lineamientos para el desarrollo de parámetros de medición de calidad que sean aceptados por todas las partes interesadas, antes de su desarrollo.
•Normas y métodos para probar el sistema.
•Herramientas de software para ser usadas en todas las fases para estandarizar el trabajo en el proyecto y mejorar la calidad en el resultado.
•Métodos de control del proyecto, en donde se incluyan numerosas marcas y se requiera la autorización del usuario.
Una metodología de desarrollo es en realidad sólo una colección de métodos, una o más para cada actividad dentro de cada fase de un proyecto de desarrollo. Los departamentos de sistemas de información, junto con la administración de otros departamentos, seleccionan la metodología que creen que se adapta mejor a las necesidades de su empresa. Las corporaciones más grandes que emplean diversas tecnologías pueden seleccionar múltiples metodologías para usarlas con las diferentes tecnologías. Sin embargo, la clave para el desarrollo de la calidad es seleccionar una metodología adecuada y luego hacerla cumplir.
Asignación de recursos durante el desarrollo de los sistemas.
Los puntos de vista sobre la asignación de recursos durante el desarrollo de los sistemas han cambiado significativamente con el curso de los años. La asignación de recursos determina la manera como los costos, el tiempo y el personal son asignados a las distintas fases de un proyecto.
Métrica del Software.
La métrica del software puede jugar un papel en el incremento de la calidad del proyecto. La métrica del software consiste en evaluaciones objetivas de los sistemas en la forma de mediciones cuantificadas. El uso continuo de las métricas permite que el departamento de SI y el usuario midan conjuntamente el desempeño del sistema e identifiquen problemas tan pronto como ocurran. La métrica del software incluye métrica de entrada, de salida, de capacidad, de desempeño y de valor.
El análisis de punto de función mide el número de entradas, salidas consultas, archivos e interfaces externas usadas para otro software empleado en una aplicación. Se emplea para evaluar la productividad del desarrollador y la eficiencia del software.
Pruebas.
La realización de pruebas se inicia en la etapa de diseño. Como aun no existe ninguna codificación, la prueba que normalmente se utiliza es un tránsito, que es la revisión de un documento de especificaciones o de diseño por un grupo de personas cuidadosamente seleccionado según las habilidades necesarias para los objetivos particulares que serán probados. Una vez que se inicia la codificación, los tránsitos de esta también pueden ser usados para revisar el código del programa. Sin embargo, El código debe probarse realizando corridas de computadora. Cuando se descubren los errores, la fuente se encuentra y elimina mediante un proceso llamado depuración.
La realización de pruebas será exitosa solamente si se planea con cuidado. Temprano en el proyecto, antes de que principie ninguna prueba, es necesario preparar un plan de pruebas que debe incluir casos particulares de manera que los desarrolladores puedan estar seguros de que han probado una gama apropiada de entradas válidas e inválidas. Los datos de entrada inválidos deben también ser probados para saber que el sistema maneja adecuadamente los errores. Las pruebas también deben ser confeccionadas de acuerdo con la tecnología a ser probada.
Herramientas de calidad.
Finalmente la calidad del sistema puede ser significativamente mejorada mediante el uso de herramientas de calidad. Hay muchos tipos de herramientas para ayudar en proceso de depuración. El conjunto más reciente de herramientas automatiza mucha de la preparación para pruebas comprensivas. La tecnología de las herramientas es relativamente nueva y en muchos casos su valor debe ser aún demostrado. Sin embargo, Las herramientas están teniendo un impacto significativo en la calidad del sistema y en los costos de desarrollo.
Herramientas y metodologías tradicionales.
Anteriormente la programación era no estructurada y se usaban códigos de programa confusos con lógica rebuscada que metafóricamente se parece a una olla de espagueti.
Las metodologías y métodos que incluían normalmente son descritos mediante los términos estructurado y descendentes. Estructurado se refiere al hecho de que las técnicas son instrucciones cuidadosamente descritas, con frecuencia paso a paso, donde cada paso se desprende del anterior. Descendente se refiere a un enfoque que avanza desde el nivel de la más alta abstracción hasta el más bajo de detalle; desde lo general a lo específico.
Las metodologías tradicionales de estructuración están orientadas hacia el proceso en vez de orientadas hacia los datos. Estas metodologías son en gran medida lineales: cada fase debe quedar terminada antes que la siguiente pueda empezar.
Las metodologías incluyen el análisis estructurado, diseño estructurado, programación estructurada, tablas de decisión, árboles de decisiones, pseudocódigos y diagramas de flujos. Mediante el uso de estas metodologías se promueve la calidad al suscitar la comunicación, reducir los errores ocasionados por la lógica defectuosa en los programas o especificaciones poco claras y creando software que sea más fácil de entender y mantener.
Análisis estructurado.
El análisis estructurado es un método que se utiliza ampliamente para definirlas entradas de sistemas, procesos y salidas, así como para dividir los sistemas en subsistemas. Ofrece un modelo gráfico lógico de flujo de información, que divide a un sistema en módulos que muestran niveles manejables de detalles. El enfoque estructurado permite:
•Tener vistas de un sistema de arriba hacia abajo.
•Especificar las interfases que existen entre modelos.
•Especificar rigurosamente los procesos o las transformaciones que ocurren dentro de cada modelo.
El análisis estructurado puede aplicarse a los análisis de sistemas, especificación de requerimientos y diseño.
Diagramas de Flujo de Datos.
En el análisis estructurado la herramienta primaria es el diagrama de flujo de datos (DFD), que es una representación gráfica de los procesos que componen el sistema y de las interfases entre ellos. Los DFD muestran como los datos fluyen desde, hacia y dentro de un sistema de información y los procesos en donde los datos se transforman. Los DFD también muestran donde se almacenan los datos.
Los diagramas de flujo se construyen utilizando cuatro símbolos básicos:
•El símbolo de flujo de datos, una flecha que muestra el flujo de los datos
•El símbolo del proceso, cuadros redondeados o burbujas que describen procesos que transforman los datos.
•El símbolo de almacenamiento de datos, un rectángulo abierto que indica donde se almacenan los datos.
•El símbolo d entidad externa, ya sea un rectángulo o un cuadrado que indica las fuentes o los destinos de los datos.
1. Flujo de datos 3. Almacenamiento de datos
2. Proceso 4. Entidad externa
Los flujos de datos muestran el movimiento de los datos entre los procesos, entidades externas y almacenamiento de datos.
Los procesos implican la transformación de los flujos de datos de entrada a flujo de datos de salida.
Los almacenamientos de datos pueden ser inventarios manuales o automatizados de datos.
Las entidades externas son originadores o receptores de información. Las entidades externas algunas veces reciben el nombre de interfases externas porque se encuentran fuera de las fronteras o alcances del sistema descrito en el diagrama de flujos de datos.
Los diagramas pueden ser usados para describir procesos de alto nivel así como detalles de bajo nivel. A través de los diagramas de flujo de datos a niveles un proceso complejo se puede fraccionar a diversos niveles de detalles. Todo un sistema puede ser dividido en subsistemas con un DFD de alto nivel. Cada subsistema, a su vez, puede ser dividido en subsistemas adicionales con DFD de menor nivel.
El diagrama de contexto describe siempre a un sistema entero como un proceso sencillo con sus principales entradas y salidas. Los diagramas subsecuentes pueden entonces fragmentar el sistema hacia abajo en mayor nivel de detalle.
Otras herramientas del análisis estructurado.
En el análisis estructurado, el diccionario de datos contiene información acerca de los elementos individuales de datos y de agrupamientos de datos dentro de un sistema. El diccionario de datos define los contenidos de los flujos de datos y el almacenamiento de datos de manera que los desarrolladores de sistemas comprendan exactamente que elementos de datos contienen.
El diccionario también proporciona información sobre el significado y formato de cada elemento de datos y los flujos y los almacenamientos de datos en donde se utiliza.
Las especificaciones de proceso describen las transformaciones que ocurren dentro de las burbujas de más bajo nivel en los diagramas de flujo de datos. Expresan la lógica para cada proceso usando uno de los tres métodos para documentar las reglas de decisión que se describen en:
•Seudocódigo o inglés estructurado.
•Tablas de decisión.
•Árboles de decisión.
El resultado del análisis estructurado es un documento de especificaciones estructuradas que incluye los diagramas de flujo de datos para las funciones del sistema, las descripciones del diccionario de los flujos de datos y los almacenamientos de datos, especificaciones del proceso y documentos de entrada o salida más los requerimientos de seguridad, control, conversión y desempeño.
Documentación de las reglas de decisión. Tablas de Decisiones.
Las tablas de decisiones se consideran como muy útiles para documentar situaciones en las que el proceso de decisiones es altamente estructurado y claramente entendido. Las decisiones se representan de manera gráfica en una tabla en la que se expresan una serie de condiciones. Cuando ciertas condiciones se cumplen (si, no) las decisiones se toman de acuerdo con reglas especificadas. La tabla debe especificar todas las posibles condiciones que afectan la decisión.
Árboles de Decisiones.
Los árboles de decisiones son diagramas secuenciales en forma de árbol que presentan las condiciones que afectan a una decisión y las acciones que pueden ser tomadas. Las ramas representan las trayectorias que pueden ser tomadas en el proceso de toma de decisiones.
Seudocódigo.
El seudocódigo es un método para expresar la lógica de programas que usa inglés común y corriente en vez de símbolos gráficos, árboles, tablas o lenguajes de programación para describir un procedimiento.
El seudocódigo usa los mismos patrones lógicos como estructuras básicas de control de la programación estructurada. Estos son 3:
•La estructura de la secuencia que son los pasos o acciones individuales de la secuencia en la lógica de un programa que no dependen de ninguna condición.
•La estructura de la selección es el patrón lógico de programación en donde una condición ya enunciada determina cuales de las dos o más acciones pueden ser tomadas, dependiendo de cuál satisface la condición establecida.
•La estructura de iteración es el patrón lógico del programa en donde ciertas acciones se repiten si cierta condición ocurre o hasta que cierta condición se satisfaga.
Diseño Estructurado.
El diseño estructurado es una disciplina de diseño de software que abarca un conjunto de reglas y técnicas de diseño para elaborar en forma descendente a un sistema de forma jerárquica.
A medida que se formula el diseño, se documenta en un diagrama estructurado.
El diagrama estructurado es una gráfica descendente, que muestra cada nivel de diseño, su relación con otros niveles y su lugar en toda la estructura de diseño; puede documentar un programa, un sistema o parte de un programa.
Programación estructurada.
La programación estructurada es un método para organizar y codificar programas que simplifica las rutas de control de manera que los programas puedan ser comprendidos fácilmente y en consecuencia modificados. Emplea las estructuras y los módulos básicos de control que sólo tienen un punto de acceso y uno de salida.
Cada una de las cajas del diagrama estructurado representa un componente modular o módulo. Los programas pueden ser particionados en módulos, cada uno de los cuales constituye una unidad lógica que lleva acabo una o un número pequeño de funciones. Los módulos deben estar interconectados de manera que tengan una entrada y una salida de sus módulos padres. Deben compartir datos con los menos módulos posibles para que no hayan conexiones oscuras.
Diagramas de Flujo.
Los diagramas de flujo de los sistemas detallan el flujo de datos a lo largo de todo el sistema de información. Los diagramas de flujo de programas describen los procesos que ocurren dentro de un programa individual en el sistema y la secuencia en la que deben ejecutarse.
Diagramas de flujo de Sistemas (FLUJOGRAMAS):
El flujograma de sistema es un amanera gráfica de describir todos los procedimientos que toman datos de entrada y los transforman a su forma final de salida.
Limitaciones de los métodos tradicionales.
La mayoría de los críticos considera que las metodologías estructuradas son lentas y no tiene respuesta en el mundo de cambios tan rápidos de los noventas. El proceso es demasiado lineal y esto hace que las metodologías estructuradas sean más bien inflexibles. Los sistemas que se enfocan a los procesos son a menudo largos e inflexibles, en cambio, los sistemas que se enfocan hacia los datos pueden ser más cortos y mucho más flexibles, lo que los hace más fáciles de modificar y de mayor respuesta a las necesidades cambiantes de los negocios.
Para atacar muchos de estos problemas se han desarrollado nuevas técnicas como el diseño de aplicaciones conjuntas que es un método de diseño que reúne a los usuarios y a los profesionales de SI en una oficina para un diseño interactivo del sistema.
Nuevos enfoques hacia la calidad.
Además de las nuevas metodologías y herramientas tradicionales, los constructores de sistemas están inclinándose hacia el desarrollo orientado a objeto, a la ingeniería de software asistida por computadora (CASE) y a la reingeniería de software para ayudar a enfrentar a los problemas de calidad de los sistemas de información.
Desarrollo de software orientado a objetos.
El desarrollo de software orientado a objetos es un enfoque que niega la importancia de los procesos y cambia el enfoque del modelaje de los procesos de negocios y de los datos, hacia la combinación de datos y procedimientos para crear objetos.
Beneficios de un enfoque orientado a objetos.
El desarrollo de software orientado a objetos aborda directamente la cuestión de la reutilizabilidad y se espera que reduzca el tiempo y costo de escribir software.
Obstáculos en el uso de técnicas orientadas a objetos.
No existe aún una metodología universal orientada a objetos y todavía no está probado lo suficiente para que muchas empresas adopten el desarrollo de software orientado a objetos, porque muchas de ellas se muestran reticentes en intentarla porque requiere de una gran cantidad de capacitación del personal y una importante reorientación metodológica.
Es necesario desarrollar nuevas tecnologías para los métodos orientados a objetos. Los diccionarios de datos para almacenamiento de definiciones de datos estructurados y de códigos de programa no son adecuados para la programación orientada a objetos. Nuevos diccionarios de datos orientados a objetos deben ser desarrollados. Las herramientas CASE se han desarrollado para dar soporte a las metodologías estructuradas y necesitan ser rediseñadas para ser utilizadas con desarrollos orientados a objetos. Aún deben desarrollarse nuevas métricas, pues muchas de
las existentes para evaluar la calidad de los sistemas no pueden ser aplicadas a la codificación orientada a objetos.
Ingeniería de software apoyada por computadora (CASE).
La ingeniería de software apoyada por computadora (CASE) es la automatización de metodologías paso a paso para el desarrollo de software y de sistemas para reducir la cantidad de trabajo repetitivo que el desarrollador debe hacer. Su adopción puede librar a los desarrolladores para hacer taras más creativas de solución de problemas. Las herramientas CASE también facilitan la creación de documentación más clara y de la coordinación de los esfuerzos de desarrollo de los equipos. Los miembros de los equipos pueden compartir su trabajo con más facilidad al accesarse sus respectivos archivos para revisar o modificar lo que se ha hecho. Los sistemas desarrollados con CASE y las metodologías más nuevas han probado ser más confiables y requieren ser reparados con menor frecuencia. En general, las herramientas CASE tratan de incrementar la productividad y la calidad al:
•Respetar una metodología de desarrollo y una disciplina de diseño estándar.
•Mejorar las comunicaciones entre los usuarios y especialistas técnicos.
•Organizar y correlacionar las componentes de diseño y proporcionar rápido acceso a ellas mediante una alacena de diseño.
•Automatizar porciones tediosas y proclives a errores de análisis y diseño.
•Automatizar la agenda de pruebas y controles.
Ejemplos de herramientas CASE.
Las herramientas CASE se clasifican en términos de si dan apoyo a actividades en el frente o en la parte posterior del proceso del desarrollo de sistema. Las herramientas CASE para la parte frontal se enfocan en la captación del análisis y el diseño de información en las primeras etapas del desarrollo de sistemas. Las herramientas CASE para la parte posterior se enfocan en las actividades de codificación, pruebas y mantenimiento.
El Reto de Usar el CASE.
Para ser utilizadas eficazmente, las herramientas CASE requieren de mayor disciplina organizacional que en el enfoque manual. Todo miembro del proyecto de desarrollo debe adherirse a un conjunto común de convenciones de nombres, normas y metodologías de desarrollo. Las mejores herramientas CASE refuerzan métodos y normas comunes, lo que puede desaconsejar su uso en situaciones en donde se adolece de falta de disciplina organizacional.
Reingeniería de software.
La reingeniería de software es una metodología que ataca el problema del envejecimiento del software. El propósito de la reingeniería es salvar mucho del software, revaluarlo de manera que los usuarios puedan evitar un proyecto largo y caro de reemplazo. Esencialmente, los desarrolladores usan la reingeniería para extraer inteligencia de los sistemas existentes y por tanto crear nuevos sistemas sin empezar de cero. La reingeniería implica tres pasos: ingeniería reversiva, revisión del diseño y especificaciones de programas, e ingeniería prospectiva.
La ingeniería reversiva, o retrospectiva, implica la extracción de las especificaciones subyacentes del negocio de los sistemas existentes. Con documentación estructurada de la cual partir, el equipo del proyecto puede revisar el diseño y especificaciones para cumplir con los requerimientos actuales del sistema. En el paso final, ingeniería prospectiva, las especificaciones revisadas son usadas para generar un código nuevo y estructurado para un sistema estructurado y mantenible.
La reingeniería permite que los desarrolladores eliminen las redundancias reduciendo así el tamaño y complejidad de los programas, lo que da como resultado menores oportunidades para monsergas actuales y futuras.
