CONCEPTOS BASICOS DE INGENIERIA DE SISTEMAS Tomás Bradanovic P.

Presentación del tema: "CONCEPTOS BASICOS DE INGENIERIA DE SISTEMAS Tomás Bradanovic P."— Transcripción de la presentación:

1 CONCEPTOS BASICOS DE INGENIERIA DE SISTEMAS Tomás Bradanovic P.

2 La ingeniería de software surge frente a la crisis del software detectada a fines de los años 60 cuando los programas comenzaron a crecer en tamaño y complejidad. En un comienzo la programación completa para resolver un problema era hecha por una sola persona o un pequeño grupo de dos o tres personas que se repartían tareas, los primeros programas eran todos listas de instrucciones que se ejecutaban en una secuencia estricta por ejemplo Inicio del programa Aparece un menú de opciones Si se escoge la opción 1 se ejecuta el procedimiento 1 (secuencia de instrucciones del procedimiento 1) Si se escoge la opción 2 se ejecuta el procedimiento 2 (secuencia de instrucciones del procedimiento 2) etc.. Vuelta al menú al terminar alguno de los procedimientos Fin del programa Estos se conocían como lenguajes de programación procedurales, es decir que consistían en listas secuenciales de procedimientos. En sus niveles más bajos todos los sistemas son procedurales.

3

4 Los lenguajes procedurales aún se usan, todo lenguaje de bajo nivel (o sea los que interactúan directamente con la máquina) son procedurales y cuando programamos sistemas pequeños se puede usar el método procedural sin problema. Como los lenguajes procedurales son escencialmente listas de instrucciones son los que se usan en modo de consola (opuesto al modo gráfico o de ventanas). Al complicarse cada vez más los programas y aumentar de manera monstruosa la cantidad de instrucciones (hoy no es raro encontrar programas con millones de líneas de instrucciones), se hizo necesario el desarrollo en colaboración, los programas pasaron a llamarse sistemas y se hacían de manera modular por equipos de jefe de proyecto, analistas, programadores, documentadores, etc.

5 Otra consecuencia de estos cambios fue la necesidad de desarrollar los sistemas en módulos porque era imposible que una sola persona pudiese entender o controlar un sistema en su totalidad, esta modularidad desarrolló el concepto de cajas negras y aislación en capas donde cada módulo era una cápsula cerrada de código a la que se le conocían sus entradas y salidas, pero los detalles internos quedaban restringidos y ocultos para quienes trabajaban en los demás módulos, así las cápsulas o módulos de código se podían ensamblar como piezas de un Lego y también podían reusarse para otros programas.. Los sistemas dejaron de ser un solo archivo monstruosamente grande para convertirse en un ejecutable principal muy grande que llamaba a las funciones de otros ejecutables relacionados llamados bibliotecas. Por ejemplo en Windows estas bibliotecas son los archivos con extensión dll, ocx y otras. Por eso los programas modernos y complejos (especialmente en Windows) tienen normalmente una API (Aplication Programmers Interface) que permite agregar procedimientos accediendo a las rutinas de bajo nivel sin violar la estructura de capas. Ejemplos de API: Facebook, Twitter, Windows, etc. Las APIs son como “ventanas” que permiten enviar mensajes a algunas capas de bajo nivel de los programas, permitiendo que desarrolladores independientes les agreguen nuevas funciones o aplicaciones

6 Hasta fines de los sesentas la programación de computadores era una especie de arte donde personas muy dotadas (los programadores) veían un problema, diseñaban un modelo abstracto de solución, diseñaban los procedimientos lógicos y finalmente codificaban todos estos procedimientos. Sin embargo al crecer la complejidad de los programas ya nadie era capáz de manejar un diseño por si solo y la programación "artística" colapsó por múltiples razones: Al trabajar en equipo no todos los programadores son igualmente hábiles, esto creaba enormes cuellos de botella en la producción de un sistema. Como la codificación dependía mucho de la habilidad del programador, lo normal era que el único que entendía el código era quien lo había programado, o sea los programadores se convertían en indispensables e irremplazables. Al no existir procedimientos estrictos de desarrollo el código resultaba enredado, lleno de errores que se iban parchando en el camino y quedaban sin documentar, el desarrollo se demoraba, etc. Para corregir esta situación surgió la Ingeniería de Software con el objetivo de "la producción sistemática y el mantenimiento de productos de software, su desarrollo y modificación en el tiempo previsto y dentro de los costos estimados" NOTA IMPORTANTE: Para sistemas pequeños muchos de los problemas mencionados no existen y por ello algunos de los criterios desarrollados por la Ingeniería de Software no se aplican.

7 Los productos de software (que en adelante llamaremos Sistemas) pueden ser de dos clases Genéricos (por ejemplo Word, Excel, etc.) A la medida (por ejemplo el software del control de las fronteras) Los sistemas, además de el conjunto de archivos con ejecutables compilados y bibliotecas usualmente tienen los siguientes componentes adicionales Documentación de los requerimientos (casos de uso) Documentación de los diseños (especificaciones de diseño) Código fuente Planes de prueba (casos de prueba) Manual de operación y ayuda (manual de usuario) Instrucciones de instalación Procedimientos de mantenimiento (planes de respaldo, protocolos de reporte de error, planes de contingencia, etc.)

8 Como se desarrolla un sistema Planificación y estimaciones: en esta etapa se planifican las actividades, se asignan los tiempos, los requerimientos de recursos humanos, físicos y se estima el presupuesto de cada etapa así como el presupuesto total del proyecto Análisis de los requisitos: aquí se descompone el problema que se pretende modelar en sus detalles, determinando que es lo que se requiere que haga el sistema Diseño: en esta etapa se crea el modelo y el diseño lógico con todas las entradas, salidas y procesos que debe ejecutar el sistema Codificación: el diseño creado en la etapa anterior se materializa escribiendo en lenguaje de programación las instrucciones para llevar a cabo cada una de los módulos según las especificaciones del diseño lógico Prueba: la etapa de prueba es simultánea a la de codificación a nivel de detalle pero también posterior, cuando se ensamblan los módulos. Finalmente cuando se entrega todo el sistema para producción comienza una tercera fase de la etapa de prueba que es para todo el sistema bajo condiciones reales. Mantenimiento: en esta etapa se agregan nuevos módulos, se modifican o se quitan según vayan cambiando los requerimientos del sistema, se ejecutan programas de respaldo de datos y sistema, etc.

9 Concepto de Calidad de Software La calidad de un software tiene que ver con la percepción subjetiva acerca de su desempeño, robustez, prestaciones, etc. y se percibe en dos niveles: Nivel Externo, es como perciben el software los usuarios del sistema Nivel Interno, es como perciben el software los profesionales de la computación En el nivel externo, la percepción de calidad suele variar mucho según las expectativas de los usuarios algunas de estas son objetivas como: Corrección: cuando el sistema ejecuta sin errores todas sus funciones, tal como han sido especificadas en el diseño. Robustez: cuando el sistema no se cae en condiciones excepcionales o anormales Modificabilidad: la capacidad para adaptarse al cambio en sus especificaciones Compatibilidad: capacidad para acoplarse y trabajar en conjunto con otros sistemas Ergonomía: capacidad para hacer las tareas con la mayor facilidad para el operador, evitando la duplicación de entrada de datos, el paso innecesario por varias etapas para hacer una tarea, etc. Integridad: capacidad para protegerse contra accesos no autorizados, robo de información, modificación maliciosa, etc. Facilidad de uso: aprendizaje sencillo, operación sencilla, reportes de calidad

10 Sin embargo existen otros criterios de percepción de calidad por parte de los usuarios que, sin ser tan objetivos, son los que causan los mayores conflictos: Disconformidad con el diseño del sistema: pese a que el diseño se construye en base a encuestas y estudio de las necesidades de los usuarios, este no es siempre 100% funcional a sus intereses porque existen muchos otros criterios que el diseño debe considerar, por ejemplo al mejorar la seguridad y los controles normalmente se perjudica la ergonomía, los jefes pueden haber introducido requisitos adicionales al sistema para prestaciones y trabajos que antes no se efectuaban, el sistema puede ser menos robusto ante el ingreso equivocado de datos, etc. En general los usuarios siempre comparan el nuevo sistema con el antiguo y distintos usuarios tienen distintas prioridades, por lo que no existe un sistema que pueda dejar a todos conformes por igual, los operadores desearan hacer lo mismo con menos trabajo, los clientes desearán tener prestaciones adicionales, los jefes más control y seguridad, etc. todos esos requerimientos están frecuentemente en conflicto por lo que no es raro que la percepción de calidad difiera para los diferentes usuarios. Aversión al cambio: operadores y usuario están acostumbrados al sistema antiguo y se molestan al tener que cambiar sus métodos de operación y aprender otros nuevos. Falsos errores de sistema: producidos por errores de operación durante la curva de aprendizaje, durante el período de prueba en explotación suelen producirse fuertes tensiones y recriminaciones mutuas entre operadores y el equipo de desarrollo por esta causa

11 En el nivel interno algunos de los principales factores de calidad son: Seguridad: es la capacidad de protección del sistema ante ataques intencionados o negligencias para mantener la integridad y confidencialidad de los datos Robustez: es la capacidad de continuar funcionando correctamente en circunstancias adversas tales como flujos anormalmente grandes, errores de operación, etc. Modularidad: que es la capacidad de cada componente del programa de funcionar de manera independiente, posibilitando el reemplazo, reutilización, etc. sin tener que afectar al sistema completo Legibilidad: el código debe estar escrito de manera clara y tan auto documentado como sea posible en cada uno de sus módulos de manera que cualquiera lo pueda entender, mantener, reparar, etc.

12 Ciclo de vida del software El ciclo de vida son las etapas por las que pasa un sistema desde su concepción hasta su explotación en régimen. Existen varios modelos de los cuales revisaremos tres: Clasico El ciclo de vida clásico consiste en el desarrollo secuencial en una serie de pasos, cada paso genera las entradas y la documentación para el siguiente: Entrevistas Especificaciones de casos de uso Diseño lógico Diseño Físico Casos de Prueba Documentación Producción Este ciclo de vida todavía se ocupa para el desarrollo de sistemas pequeños por su simplicidad, pero en la mayoría de los sistemas se usa una variante llamada

13 Ciclo Clásico en Cascada En este caso también se recoge información, se hacen especificaciones de diseño, se hace un diseño lógico y finalmente se codifica, la diferencia es que el flujo no es secuencial sino que las correcciones afectan no solo a la etapa inmediatamente anterior sino a todas las etapas. Al crecer los sistemas aparecen una serie de inconvenientes en el desarrollo en cascada, como: * Es difícil imaginar de antemano los requerimientos de las etapas que siguen * Muchos problemas no siguen un flujo secuencial * Los errores se detectan solo cuando se pone a prueba todo el sistema Ciclo de vida por prototipado Los prototipos son versiones iniciales de un producto o un módulo, que permiten que el cliente y el futuro operador vean como se va a comportar, den sus impresiones y críticas, ayudan a establecer las necesidades reales del cliente quien muchas veces no las tiene claras al momento de ser entrevistado.

14 EL DISEÑO EN CASCADA La ingeniería de sistemas se preocupa del análisis y modelamiento del sistema que se pretende construir. El trabajo consiste a grandes rasgos en entender el problema, fijar las prioridades y especificarlas en un modelo lógico que normalmente se concreta como un listado exhaustivo de especificaciones sobre estructuras de datos, que es lo que el programa debe hacer, las entradas, procesos y salidas.. listado exhaustivo de especificaciones estructuras de datos El trabajo de la ingeniería de sistemas tiene que ver con la organización, las necesidades y expectativas de los clientes, la idea es definir y ordenar las prioridades en una capa lógica abstracta, antes de enredarse con los detalles técnicos de la codificación y es por eso que se le da gran importancia al trabajo de encuestas en esta etapa, de manera de tener claras las prioridades y expectativas. Luego viene el trabajo de ingeniería de software que consiste en codificar las especificaciones entregadas y convertirlas en un programa que funcione. El trabajo en una primera instancia consiste en construir prototipos de las interfases de usuario, es decir un programa "de mentira" para determinar las mejores interfases hombre-máquina y, una vez elegido esto dedicarse a codificar y optimizar los procesos que el sistema debe realizar, todo esto apegado a las especificaciones entregadas por el diseño lógico. La construcción de prototipos semi funcionales es de gran ayuda al momento de probar el comportamiento real de las ideas del diseño. Esta es la teoría. La construcción de un programa debe ser un proceso en cascada donde el diseño ideal debe preceder a la codificación. En el desarrollo de programas computacionales según se nos ha enseñado, existen dos etapas claramente definidas: el diseño lógico y el diseño físico. En la realidad sin embargo, esta separación ha sido fuente de diversos problemas

15 POR QUE SE DISEÑA EN CASCADA Esta separación entre diseño lógico y el diseño físico es consecuencia de los problemas de crecimiento de tamaño y complejidad en los sistemas. En un principio ambas etapas estaban estrechamente relacionadas, y lo siguen estando en el caso de los sistemas pequeños donde trabaja solo un programador o un pequeño grupo de personas. Pero al hacer sistemas más complejos y dividir las tareas entre un equipo de programadores era necesario fijar prioridades y criterios de diseño de antemano, de manera que todos trabajen bajo normas claras y criterios comunes. Esto evita el problema de desviarse de los grandes objetivos por percepciones o necesidades particulares de alguno de sus subsistemas. También divide el trabajo en una parte creativa y normativa (diseño lógico) y otra mecanizada y sujeta a normas (diseño físico). El diseño en cascada ha formado una verdadera cultura que separa a analistas y programadores. Harry Boehm de la Universidad de California del Sur cuenta su experiencia al respecto: "Cuando tratamos de introducir el uso de prototipos en proyectos con alta interacción de usuarios en TRW, los ingenieros de software, resistiéndose al cambio, golpeaban la mesa y gritaban, "¡No pueden hacer esto! ¡hacer prototipos es codificar sin haber pasado la revisión crítica del diseño, esto esta absolutamente prohibido por las políticas corporativas!", tomó años deshacer las muchas formas en que el modelo de cascada se había infiltrado en varios aspectos de nuestra cultura corporativa tales como el marketing, preparación de propuestas, estimación de costos, contratos, contabilidad y gerenciamiento"

16 Y CUAL ES EL PROBLEMA? Hay un viejo cuento de un ingeniero de sistemas que decía haber diseñado finalmente un software que podía rivalizar con el cerebro humano. Al pedírsele que lo demostrara entregó una larga lista con las especificaciones comunes de un computador a las que había agregado las especificaciones de "imaginación", "conciencia de si mismo", "lenguaje sofisticado" etc. "Bueno", dijo a modo de explicación "allí tienen el diseño, ahora solo es cosa de los programadores y los ingenieros de hardware implementarla. Lo principal ya esta hecho. Bueno, ese es uno de los mayores problemas de trabajar en abstracto desentendiéndose de los problemas prosaicos tales como la codificación, los recursos disponibles, costos y el rendimiento. Los ingenieros de sistema vienen normalmente de las áreas de la ingeniería industrial o de la administración (ingeniería comercial en Chile), no son fuertes en programación y a menudo ven con cierto desprecio la labor del programador, considerándola mecánica y poco creativa. No es raro que los diseños lógicos, al desentenderse de los detalles del mundo real tales como las limitaciones de hardware o la complicación excesiva en el código terminen en una serie de especificaciones y requisitos que no es factible de implementar con éxito. Esos son los conocidos "desastres informáticos" o sistemas que llevan mucho tiempo, esfuerzo y dinero en desarrollarse y que nunca llegan a funcionar del todo bien (muchos simplemente jamás funcionan).