La Crisis del Software

Bueno… las crisis no tienen que ser necesariamente malas, si las

afrontamos bien podemos sacarles provecho, por ejemplo, de la
reciente pandemia del COVID19 podemos sacar muchas lecciones
¿podrán ustedes mencionar algunas? Yo sí, la educación a distancia
específicamente la educación virtual es una alternativa viable para
aprender, mientras universidades como la UNED
(https://www.uned.es) llevan años aplicando esta modalidad, en la
Honduras de acá no se creía en esto ¿y ahora? ¿ustedes que
piensan? ¿la educación a distancia abre oportunidades? ¿realmente
se aprende?

Pero bueno, sigamos con las crisis específicamente con la Crisis del
Software, resulta que por la época anterior a los años 70 cuando
quizás ninguno de ustedes había nacido, ¡ni siquiera yo! El software
resultaba caro, poco fiable y escaso; es decir si las computadoras eran
pocas, los programas también y no digamos los programadores, a esto
súmenle que los programas no se terminaban a tiempo y para colmo
no funcionaban bien, lo que generaba que se excedieran del
presupuesto.

Se imaginan ustedes contar con un millón de Lempiras para construir

una casa en cuatro meses; pero no se encontraron suficientes
albañiles, luego que estos no son tan buenos como decían y terminan
la casa en nueve meses y para colmo no instalaron bien las tuberías
para tratar adecuadamente las aguas negras, no les alcanzó el dinero
para construir uno de los cuartos y se les olvidó pintarla y para colmo
gastaron ochocientos mil Lempiras más.

Así de caótica estaba la situación con el software por aquellos años. 

Pero en 1968 la OTAN viendo esta situación patrocina una conferencia
sobre software y acuñan los términos Crisis del
Software e Ingeniería del Software y la aceptación que la falta de
metodologías y todo lo relacionado a esta eran la causa de la
mencionada crisis, así pues, de un plumazo desaparece la crisis del
software, surge la Programación Estructurada, se crea el Ciclo de
Vida del Software y ya todos felices… ¿o no?  Este es buen momento
para preguntarnos si actualmente seguimos en crisis del software o es
una crisis selectiva.  Piensen en esto y lo comentamos en la próxima
clase sincrónica.

Si analizamos el software vemos que éste en realidad tiene su nivel de

complejidad, yo diría que bastante alto aunque para nosotros sea
común tener una APP que nos lleve a un lugar determinado de la
ciudad evitándonos grandes congestionamientos viales, o una que nos
permita negociar el precio de un servicio de taxi, u otra que nos
permita comprar una hamburguesa… en fin la popularidad de los
programas de computadora no significa que estos no sean complejos,
es más reafirma esta hipótesis: Al utilizar programas de computadoras
para resolver problemas cotidianos y generalmente relacionados, se
aumenta la complejidad de dichos programas de computadoras.

“La complejidad del software es una propiedad esencial, no accidental”

esta frase de Brooks (https://es.wikipedia.org/wiki/Ley_de_Brooks)
nos hace analizar que existe una complejidad inherente al software y
que esta se deriva de cuatro elementos: la complejidad del dominio del
problema, la dificultad de gestionar el proceso de desarrollo, la posible
flexibilidad a través del software y los problemas de caracterización del
comportamiento de sistemas discretos.

Sobre la complejidad del dominio del problema

¿Conocen la aplicación Waze

(https://es.wikipedia.org/wiki/Waze)? Resolver el problema de
navegación resulta en una actividad compleja que depende de varios
factores que posiblemente no esté en control de los programadores
que ahora llamaremos desarrolladores de software y que en algún
momento estos factores podrían incluso “jugar en contra” del mismo
programa, la aplicación en mención depende de los usuarios quienes
dan información del flujo vehicular, también depende del conocimiento
que sobre la infraestructura vial tenga acceso el programa.

Lo anterior como ejemplo de la complejidad a la que se deben

enfrentar los desarrolladores y ¡qué decir del factor más problemático!
que es la incompatibilidad natural entre los usuarios y los
desarrolladores quienes comúnmente tienen perspectivas diferentes
del problema.  Agreguen a lo anterior que es normal y esperado que
los requisitos de un sistema software cambien durante el desarrollo de
este… ¿se imaginan?: Estar desarrollando el programa de matricula
de clases de la UNAH en el entendido que los alumnos se matriculan
en secciones previamente creadas; pero que durante se está
trabajando en dicho desarrollo con la condición antes mencionada se
incluya el requisito que, si una sección se llena, automáticamente se
debe abrir otra y asignar espacio físico y docente para la misma.  Esto
sería fenomenal para el alumno, pero para los desarrolladores un dolor
de cabeza.

Ahora supongamos que este programa de matrícula de clases debe

intercambiar información con el programa de registro de la universidad
y también hacer intercambio con todas las instituciones bancarias del
país que aceptan los pagos correspondientes… se imaginan
la Dificultad de gestionar el proceso de desarrollo, pues tenemos
que considerar que en el desarrollo participan grupos profesionales
distintos y hasta de distintas instituciones y aunque se desee que sean
la menor cantidad de personal posible, esto no siempre se logra y el
gerente de dicho proceso de desarrollo está en “fuego cruzado” entre
los desarrolladores, los usuarios, los requisitos, las fechas límites y el
presupuesto.

Y como los seres humanos somos así, imagínense que ahora las
clases pueden ser virtuales y ahora los espacios de aprendizaje no
son tangibles, pero los alumnos, docentes y administrativos ocupan
acceder a ellos para recibir o brindar los servicios según competan a
su rol y este acceso debe ser transparente para ellos; entonces el
desarrollador debe poder expresar casi cualquier abstracción
explotando la Flexibilidad a través del software, y los resultados
deben ser discretos es decir: al final del proceso un alumno deberá o
no estar matriculado, pero jamás deberá estar más o menos
matriculado, es decir el producto debe ser un Sistema discreto.

Como ven esto de desarrollar software es complejo, a veces una

simple solicitud de cambio del usuario final implica una avalancha de
cambios para el equipo de desarrollo.  Para disminuir esta complejidad
se plantea una situación para algunos utópica en la que se tienen
programas de computadoras que realizan tareas específicas y que se
puedan hacer interactuar para aligerar el proceso de desarrollo y que
estos programas de computadoras se puedan reutilizar en distintos
proyectos.

Actividades

Para ayudarse a entender mejor el tema tratado en esta clase virtual,

realice las siguientes actividades, que no debe entragar y que tampoco
tiene puntaje.

1. ¿Cree usted que una asignatura como esta puede impartirse en

modalidad virtual?
2. En su opinión: ¿aún experimentamos crisis de software?
Argumente su respuesta.
3. ¿Considera usted que los cuatro argumentos sobre la
complejidad del software son válidos? ¿que vivencias puede
comentarnos que al respecto reafirmen la veracidad de dichos
argumentos o al contrario lo niegue?
4. Investigue la frase "existe una bala de plata" en el contexto de la
ingeniería del software y luego relacionelo con la programación
orientada a objetos. ¿que puede decir al respecto?

Estoy seguro que si repasan varias veces esta clase y hacen las
actividades empezarán a entender mejor el proceso de desarrollo de
software. Nos vemos en la siguiente clase,
La abstracción en el software

¿Y qué es la abstracción? Cuando decimos carro entendemos esto  o

esto   es decir entendemos lo que es un carro, lo mismo pasa al
referirnos a una deuda; nos referimos entonces a los conceptos a
todas esas características que nos hacen reconocer dicho concepto.

Vivimos con esto desde que nacemos, de niños nos señalan un objeto
y nos dicen su nombre, por ejemplo televisor y entonces al haber dos
televisores en casa de distinta forma los reconocemos hasta cuando
entendemos el concepto y es así como cuando llegamos a otra casa o
a una tienda y vemos otro televisor lo reconocemos, aunque tenga otra
forma. Vean la siguiente imagen con algunas de las formas que han
tenido los televisores a lo largo del tiempo y aunque quizás nunca
vimos unos de esos, si sabemos que son televisores.

Y que luego aprendemos más conceptos como: ayer, mañana... que 1

+ 1 es 2; y luego entendemos chistes como que “la mitad de uno es el
ombligo” y hasta creamos memes como este del dinosaurio y no
sabemos quién es más nerd, si el que lo crea o e que lo entiende.

Con el tiempo en nuestra carrera, en las clases de programación

aprendemos que una función puede llegar a representar conceptos
realmente complejos como los son el comportamiento de un producto,
o un cálculo.

En programación utilizamos la abstracción para entender que una

variable de tipo numérico no puede ser concatenada con una variable
de tipo cadena, entendemos que hay acciones válidas para cada tipo
de dato.

Entonces es claro que un programa de computadoras es una

abstracción de la solución de un problema utilizando una CPU.

Con lo anterior creo que ya entendimos el concepto de “programa

fumado”   Si aún no está claro, pueden preguntar en el foro
de preguntas técnicas, o volver a llevar la clase de filosofía.

El siguiente video nos resume lo que hemos platicado en esta clase

virtual
Desarrollemos las siguientes actividades para validar lo que hemos
aprendido hoy

Actividades

1. ¿Cuan importante considera usted que es la abstracción en el

área de la ingeniería en sistemas? expréselo para su estudio
personal.
2. ¿Cuan importante considera que es la abstracción en el
desarrollo de software?
3. Recordando los conceptos que aprendió en la clase de
Programación II ¿considera usted que existe relación entre la
POO y la abstracción? 
4. Para la próxima clase, busque información sobre la relación
entre abstracción y tipos abstractos de datos y objetos.
Paradigmas
¿Alguna vez se han preguntado por qué algunas cosas de hacen de
determinada manera? Por ejemplo se han preguntado el ¿por qué en
la India las vacas no pueden ser sacrificadas para servir de alimento a
los humanos y en los países de occidente si?; o el ¿por qué en Arabia
Saudita hay algunas leyes sobre tutelas de las mujeres que no les
permite las libertades que si en los países de occidente?.

Pues todas estas actuaciones obedecen a los Paradigmas seguidos

por esas sociedades. Wikipedia hace mención a paradigma como un
ejemplo o un modelo de conocimiento aceptado por una comunidad
científica.

Otro ejemplo de paradigma es la esfericidad de la tierra que desplazó

al paradigma de la tierra plana, lo que nos muestra que un paradigma
es sustituido por otro paradigma cuando aquel deja de responder o
brindar solución práctica en un hecho.

Un ejemplo de la sustitución de un paradigma por otro se dio en los

relojes, para 1968 la construcción de relojes era liderada por los
Suizos, pero una ruptura en el paradigma que indicaba que los relojes
se deberían hacer con engranajes y agujas fue sustituido por los
japoneses cuando introdujeron el reloj de cuarzo.

Como ya nos hemos podido dar cuenta, la sustitución de un

paradigma por otro no ocurre de forma repentina y a veces genera
grandes debates como lo muestra el siguiente vídeo tomado del
Parlamento argentino en 1947 mientras discutían si una mujer podía
tener el derecho de votar.

En el campo de la informática también tenemos paradigmas, en lo que

se refiere a los lenguajes de programación Doris Appleby en su
libro Lenguajes de Programación, paradigma y práctica identifica dos
grandes paradigmas: Imperativo y Declarativo.

Es de hacer notar que esta división difiere según los diferentes

enfoques o perspectivas de donde sean vistos.
Hasta el momento, en lo que al plan de estudios de la carrera se
refiere ustedes han tenido experiencia con un único paradigma, el
paradigma imperativo o según lo antes expuesto sobre que la
identificación de paradigmas difiere según los diferentes enfoques, es
válido también decir que nos hemos encontrado con el paradigma
estructurado y el orientado a objetos; el punto crítico aquí es si la
programación orientada a objetos y la estructurada son cada una un
descendiente del paradigma imperativo o son técnicas que obedecen
a este paradigmas.  Esta discusión tendrá mayor énfasis mientras
avancemos en la clase de Lenguajes de Programación, pero para ir
progresando en el debate definimos al paradigma imperativo como
aquel que describe la programación en términos del estado del
programa y sentencias que cambian dicho estado.

Entonces el programador usando un lenguaje imperativo escribe las

instrucciones que le indicarán al CPU cómo realizar los cambios en las
variables de memoria.

En este sentido la Programación Estructurada y la Orientada a Objetos

pueden ser vistas como una técnica del paradigma imperativo pues
ambos son un conjunto de instrucciones que modifican el estado del
programa representado por las variables de memoria.

No obstante antes de la Programación Estructurada no escribíamos

los programas usando sentencias especializadas para el control de
flujo de las instrucciones como lo son los iteradores y los
condicionales;  en su defecto se usaba exclusivamente la sentencia
GoTo que evitaba al programadora abstraerse de estas tareas de
control y debía estar pendiente de retornar el control de flujo a la línea
de código fuente correspondiente. ¿se podrá considerar este cambio
tan significativo que convierte a la programación estructurada en un
paradigma?

De igual forma cuando consideramos que en la Programación

Orientada a Objetos las instrucciones y las variables de memoria
forman parte de una misma entidad que intercambia mensajes con
otras entidades podemos decir que la POO es más bien un paradigma
que una técnica.

Nos seguimos leyendo en las próximas clases y foros.

Actividades

1. En su vida personal ¿ha cambiado algún paradigma?, ¿identifica

paradigmas en nuestra sociedad?. ¿y en otras sociedades?
2. Busque en Internet un listado de los paradigmas de
programación. ¿Qué nota?, ¿todos los listados coinciden?,
¿Cuáles son las similitudes y diferencias?
3. Realice otra búsqueda en Internet e intente identificar si alguno
de esos paradigmas otros autores los identifican como técnicas.
4. Compare la POO y la PE ¿que similitudes y diferencias
identifica?
5. ¿Qué influencia tiene la PE en la POO?