La complejidad de desarrollar software Análisis crítico LI

La complejidad de desarrollar software
Análisis crítico
L. I. Adolfo Luna Sánchez
División de Licenciatura en Informática
Av. José Luis Martínez Vázquez No. 2000
Jicolapa, Zacatlán, Pue., C.P. 73310,
Tel: 01(797)97 5 16 94, 97 5 08 51 Ext. 114
adolus@hotmail.com
Por mucho tiempo el software se ha
mostrado ante los ojos de los usuarios
como algo simple de utilizar, para
muchos de ellos existe la idea de que
mediante la computadora todo es fácil,
sólo es cuestión de pulsar un botón y ya
está. Desafortunadamente, para un
ingeniero de software un pequeño
capricho del usuario puede implicar
varias horas de programación.[1]
Esta
complejidad
inherente
al
software se debe en parte a que el
software es un sistema como cualquier
otro, así como un árbol, una casa o una
organización, el software es un conjunto
de elementos que interactúan entre sí
para lograr un fin. Esta complejidad del
software también permanece oculta
porque por naturaleza el software es
abstracto, a tal grado que en ocasiones
puede verse más como un servicio que
como un producto. Hay autores que
consideran que el software va más allá
de un conjunto de programas, y que
debe
incluir
elementos
como
documentación de uso y de estructura
del sistema y además sitios web del
fabricante que permitan a los usuarios
descargar
actualizaciones
y/o
información de productos recientes.[2]
Profundizando
más
sobre
la
complejidad del software, se pueden
comentar otras causas básicas de ello,
por un lado encontramos el complicado
contexto en el cual surge la necesidad o
idea del software, esta necesidad puede
no ser entendida de parte del analista
como el cliente lo quisiera, y puede
concluir, por el contrario, en una
especificación de requisitos del
software demasiado burda o errónea.
Asiamismo, con el paso del tiempo y de
la compenetración producida por una
relación continua con los ingenieros del
software, los clientes pueden sentirse
con la confianza de “proponer” nuevos
requisitos de software, que para ellos
pueden
parecer
simples,
pero
desencadenar en modificaciones de la
base estructural de la aplicación. Como
ejemplo consideremos el caso de un
sistema de facturación, el cual se ve
afectado por nuevas disposiciones
hacendarias,
que
implican
una
declaración de impuestos en forma
distinta, normatividades que pueden ser
emitidas
durante
la
etapa
de
implementación del software.
Otra causa inherente es la gestión del
equipo que se encarga de desarrollar el
software, esto implica gran habilidad
técnica del administrador de los
proyectos, puesto que tiene la
encomienda de dirigir a un conjunto de
personas que se deben apegar a ciertos
estándares, herramientas y técnicas
para lograr un proceso de desarrollo
de software exitoso. Además, el hecho
de tener más personas involucradas en
un proyecto no siempre implica
terminarlo en menor tiempo. En cuanto
al software se refiere, esta situación
puede resultar perjudicial por la simple
razón de tener una necesidad mayor de
comunicación y coordinación con y entre
los empleados.
Todas las buenas prácticas que el
equipo de desarrollo tenga a bien utilizar
permitirán controlar, desde sus inicios,
la calidad del producto de software, de
no ser así puede ser que durante el
proyecto se termine “reinventando la
rueda”. El éxito logrado en otras
ingenierías como la de la construcción
radica en el uso de estándares ya
establecidos desde hace tiempo.
Por último, el hecho de crear un
sistema, implica predecir y controlar sus
distintos estados, esta situación se
vuelve más compleja cuando al sistema
lo conforman gran cantidad de variables
y estructuras de datos, pues la
combinación de estas da origen a su
vez a un número elevado de
combinaciones, y consecuentemente a
que sea difícil probar todas antes de
implementar el sistema.
El entendimiento de todo lo anterior
nos da un cierto dominio sobre un
sistema, puesto que de antemano
sabemos que un sistema complejo va a
comportarse así, y sobre todo nos
permite
saber
contra
que
nos
enfrentamos.
Esta
es
de
gran
importancia,
porque
también
por
naturaleza, el ser humano no puede
dominar todos los detalles de un
sistema complejo.
Es aquí donde surge el modelo de
objetos, el cual originalmente se basa
en la idea de identificar las “cosas” que
existen en el sistema, de esta forma, es
más fácil identificar sólo los elementos
comunes dentro del sistema, aquellas
características y operaciones que
ciertas
entidades
del
sistema
comparten, algo que se conoce como
abstracción.
El
analista
puede
concentrarse en los objetos esenciales
del
sistema,
los
que
inciden
directamente en el comportamiento del
mismo o en su funcionamiento,
concentrar sus atributos comunes y
crear clases.
De
este
modo,
surge
una
descomposición
del
dominio
del
sistema, ahora se puede entender al
sistema como un conjunto de objetos y
procesos que colaboran para obtener
un resultado. Esta distinción de objetos
permite observar que algunos son más
genéricos y que abarcan a otros,
estableciendo cierta jerarquía entre
ellos, y cuando algunos se dividen en
otros se propicia la descomposición.
Considerando
los
elementos
anteriores se consolida un modelo que
permite percibir a un sistema desde una
perspectiva más simple, y para ello se
requieren entonces herramientas que
permitan llevarlo a su nivel de aplicación
sobre
cualquier
dominio.
Surgen
entonces los lenguajes de programación
orientados a objetos, herramientas que
brindan la posibilidad de crear sistemas
de software complejos con un nivel de
esfuerzo menor al requerido por los
paradigmas
estructurados.
Se
introducen conceptos ambiciosos e
interesantes para los proyectos de
software, como la reducción de riesgos,
la reusabilidad y la posibilidad de
adaptar
sistemas
a
entornos
cambiantes con costos mínimos.
Para
concluir,
el
concepto
complejidad por si mismo puede
provocar temor natural, ambigüedad y
confusión, pero si dentro de todo esto
logramos reconocer patrones comunes
de comportamiento de los sistemas,
podemos entonces proponer estrategias
para modelar ese comportamiento y
utilizarlo a nuestro favor.
Precisamente en eso consiste el
modelo de objetos, pues éste surge
como una manera de entender y
representar la complejidad de los
sistemas de software, algo que excede
la capacidad intelectual del ser humano
y que se complica aún más cuando el
ingeniero de software tiene la difícil
encomienda de crear sistemas simples
para que los usuarios los puedan utilizar
sin problemas. Todo ello se torna más
simple cuando el enfoque se centra en
distinguir entidades y procesos que
tienen
comportamiento
y
que
interactúan entre sí.
Referencias:
[1] Sommerville, Ian (2006), Ingeniería de Software, Pearson (USA).
[2] Booch, Grady – Jacobson, Ivar – Rumbaugh, James (2007), Object-oriented
Analysis and Design with Applications, Addison-Wesley (USA).