Este documento describe los conceptos básicos de la ingeniería de sistemas. Explica que surgió en respuesta al crecimiento en tamaño y complejidad de los programas en los años 60. También describe la evolución de los lenguajes de programación procedurales a lenguajes más modulares y cómo esto llevó al desarrollo de sistemas por equipos interdisciplinarios. Finalmente, explica que la ingeniería de sistemas busca producir software de manera sistemática y mantenerlo para cumplir con los tiempos y costos estimados.

1. CONCEPTOS BASICOS DE INGENIERIA DE
SISTEMAS

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.

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..
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).