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 [email protected] 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).