<>
Ingeniería de Software
El término ingenieria de software fue acuñado en 1968 como respuesta al nivel de progreso desolador del objetivo de desarrollar software de calidad a tiempo y dentro del presupuesto. Los desarrolladores de software no fueron capaces de definir objetivos concretos, predecir los recursos necesarios para lograr esos objetivos y manejar las expectativas de los clientes. Con mucha frecuencia se prometía la luna y la construcción de un vehículo lunar, y se entregaba un par de ruedas cuadradas.
El énfasis de la ingeniería de software está en dos palabras: Ingeniería y software. Un ingeniero es capaz de construir un producto de alta calidad usando componentes ya elaborados e integrándolos bajo restricciones de tiempo y presupuesto. El ingeniero se enfrenta a un mundo con problemas mal definidos y con soluciones parciales, y tiene que apoyarse en métodos empíricos para evaluar soluciones. Los ingenieros que trabajan en campos de aplicación como el diseño de aeronaves de pasajeros y la construcción de puentes han resuelto en forma satisfactoria retos similares. Los ingenieros de software no han tenido tanto éxito.
Se ha investigado de manera activa el problema de construir y entregar a tiempo sistemas de software complejos. Se ha culpado a todo, desde el cliente ("¿qué quiere decir usted con que no puedo obtener la luna por $50.?") hasta lo "blando" en software ("si pudiera añadir una última característica...") y la juventud de esta disciplina. ¿cuál es el problema?
Los sistemas de software útiles son complejos. Para seguir siendo útiles necesitan evolucionar con las necesidades de los usuarios finales y el ambiente de destino.
Los sistemas de software son creaciones complejas: realizan muchas funciones, están construidos para lograr muchos objetivos diferentes y con frecuencia conflictivos, comprenden muchos componentes, algunos de los cuales son en sí mismos complejos y hechos a la medida, muchos participantes de disciplinas diferentes intervienen en el desarrollo de estos componentes, el proceso de desarrollo y el ciclo de vida del software a menudo abarcan muchos años y, por último, los sistemas complejos son difíciles de comprender por completo para una sola persona. Muchos sistemas son tan difíciles de comprender, incluso durante su fase de desarrollo, que nunca llegan a ser terminados: a éstos se les llama vaporware.
¿Que es la ingeniería de software?
Es una actividad de modelado. Los ingenieros de software manejan la complejidad mediante el modelado, enfocándose siempre sólo en los detalles relevantes e ignorando todo lo demás. En el curso del desarrollo, los ingenieros de software construyen muchos modelos diferentes del sistema y del dominio de aplicación.
La ingeniería de software es una actividad para la solución de problemas. Se usan los modelos para buscar una solución aceptable. Esta búsqueda es conducida por la experimentación. Los ingenieros de software no tienen recursos infinitos, y están restringidos por presupuestos y tiempos de entega. Dada la falta de teoría fundamental, con frecuencia tiene que apoyarse en métodos empíricos para evaluar los beneficios de alternativas diferentes.
La ingeniería de software es una actividad para la adquisición de conocimientos. En el modelado de los dominios de la aplicación y la solución, el ingeniero de software recopila datos, los organiza en información y los formaliza en conocimietno. La adquisición de conocimientos no es lineal, ya que un solo dato puede invalidar modelos completos.
La ingeniería de software es una actividad dirigida por una fundamentación. Cuando se adquiere conocimiento y se toman decisiones acerca del sistema o sus dominios de aplicación, los ingenieros de software también necesitan captar el contexto en el que se tomaron las decisiones y las razones que hay tras las mismas. La información de la fundamentación, representada como un conjunto de modelos de problemas, permite que los ingenieros de software comprendan las implicaciones de un cambio propuesto cuando revisan una decisión.
El propósito de la ciencia es describir y comprender sistemas complejos, como un sistema de átomo, una sociedad de seres humanos o un sistema solar. Por tradición se hace una distinción entre ciencias naturales y ciencias sociales para distinguir entre los dos tipos principales de sistemas. El propósito de las ciencias naturales es comprender la naturaleza y sus subsistemas. la ciencias naturales incluyen, por ejemplo, biología, física, química y paleontología. El propósito de las ciencias sociales es comprender a los seres humanos. Las ciencias sociales incluyen psicología y sociología.
Hay otro tipo de sistemas a los que llamamos sistemas artificiales. Ejemplo, el transbordador espacial, los sistemas de reservación de boletos de avión y los sistemas de comercialización de acciones. Herbert Simon acuñó el término ciencias de lo artificial para describir las ciencias que tratan sobre los sistemas artificiales (Simon 1970) Mientras que las ciencias naturales has existido durante siglos, las ciencias de lo artificial son recientes. Las ciencias de la computación, por ejemplo, la ciencia que trata de la comprensión de los sistemas de computadora, es una hija del siglo pasado.
Muchos métodos que se han aplicado de modo satisfactorio en las ciencias naturales y en las humanidades también pueden aplicarse en las ciencias de lo artificial. Observando las demás ciencias podemos aprender un poco. Uno de los métodos básicos de la ciencia es el modelado. Un modelo es una representación abstracta de un sistema que nos permite responder preguntas acerca del sistema. Los modelos son útiles cuando se manejan sistemas que son demasiado grandes, demasiado pequeños, demasiado complicados o demasiado caros para tener una experiencia de primera mano. Los modelos también nos permiten visualiizar y comprender sistemas que ya no existen o que solo se suponen que existen.
Los ingenieros de software enfrentan retos similares a los de los biólogos de fósiles y físicos de alta energía. Primero, los ingenieros de software necesitan comprender el ambiente en el que va a operar el sistema. Para un sistema de control de tráfico de trenes, los ingenieros de software necesitan conocer los procedimientos de señalización de los trenes. Para un sistema de comercialización de acciones, los ingenieros de software necesitan conocer las reglas de comercio. Los ingenieros de software no necesitan llegar a ser por completo despachadores de trenes certificados o corredores de bolsa, sino que sólo necesitan aprender los conceptos del dominio de problema que son relevantes para el sistema. En otras palabras, necesitan construir un modelo del dominio de problema.
segundo, los ingenieros de software necesitan comprender los sistemas que podrían construir para evaluar diferentes soluciones y compromisos. La mayoría de los sistemas son demasiado complejos para que sean comprendidos por una sola persona y cuesta mucho construirlos. Para atacar estos retos los ingenieros de software describen los aspectos importantes de los sistemas alternativos que investigan. En otras palabras, necesitan construir un modelo del dominio de solución.
Los métodos orientados a objetos combinan las actividades de los dominios de problema y de solución en uno solo. Primero se modela el dominio de problema como un conjunto de objetos y relaciones. Luego, el sistema usa este modelo para representar los conceptos del mundo real que manipula un sistema de control de tráfico de trenes incluye objetos de trenes que representan a los trenes que supevisa. Un sistema de comercialización de acciones incluye objetos de transacción que representan la compra y venta de acciones. Luego, también se modelan como objetos los conceptos del dominio de solución. El conjunto de líneas que se usan para representar un tren o una transacción son objetos que son parte del dominio de solución. La idea de los métodos orientados a objetos es que el modelo del dominio de solución es una extensión del modelo del dominio de problema. El desarrollo de software se traduce en las actividades necesarias para identificar y describir un sistema como un conjunto de modelos que abordan el problema del usuario final
La ingeniería es una actividad para la solución de problemas: Los ingenieros buscan una solución adecuada, a menudo mediante ensayo y error, evaluando alternativas en forma empírica con recursos limitados y con conocimiento incompleto. En su forma más simple, el método de la ingeniería incluye cinco pasos:
1. Formular el problema
2. Analizar el problema
3. Buscar soluciones
4. Decidir cuál es la solución adecuada
5. Especificar la solución
La ingeniería de software es una actividad de ingeniería. No es algorítmica. Requiere experimentación, la reutilización de soluciones patrón y la evolución creciente del sistema hacia una solución que sea aceptable para el cliente.
El desarrollo del software incluye, por lo general, cinco actividades de desarrollo: obtención de requerimientos, análisis, diseño del sistema, diseño de objetos e implementación. Durante la obtención de requerimientos y el análisis, los ingenieros de software formulan el problema junto con el cliente y construyen el modelo del dominio de problema. La obtención de requerimientos y el análisis corresponde a los pasos uno y dos del método de ingeniería. Durante el diseño del sistema los ingenieros despues de analizar el problema lo dividen en partes pequeñas y seleccionan extrategias generales para su diseño. Durante el diseño de objetos seleccionan soluciones detalladas para cada parte, decidiéndose por la más adecuada. El diseño del sistema y el de objetos dan como resultado el modelo del dominio de solución. Los diseños de sistema y objeto corresponde a los pasos tres y cuatro del metodo de ingeniería. Durante la implementación, los ingenieros de software realizan el sistema transladando el modelo del dominio de solución hacia una representación ejecutable. La implementación corresponde al paso cinco del método de ingeniería. Lo que hace que la ingeniería de software sea diferente a la solución de problemas en otras ciencias es que los cambios suceden mientras se está resolviendo el problema.
El desarrollo del software también incluye actividades cuyo propósito es evaluar lo adecuado de los modelos respectivos. Durante la revisión de análisis, el modelo del dominio de aplicación se compara con la realidad del cliente, la cual a su vez, puede cambiar como resultado del modelado. Durante la revisión el diseño se evalúa el modelo del dominio de solución contra los objetivos del proyecto. Durante las pruebas se valida el sistema contra el modelo del dominio de solución, el cual puede cambiar a causa de la introducción de nuevas tecnologías.
Un error común de los ingenieros y gerentes de software es suponer que la adquisición del conocimiento necesario para desarrollar un sistema es lineal. Este error también se puede encontrar en otras áreas.
La adquisición de conocimentos es un proceso no lineal. La adición de una nueva parte de información puede invalidar todo el conocimiento que hemos adquirido para la comprensión de un sistema.
La falta de linealidad del proceso de adquisición de conocimientos tiene implicaciones severas en el desarrrollo del sistema. Hay varios procesos de software que manejan este problema evitando las dependencias lineales inherentes al modelo de cascada. el desarrollo basado en el riesgo trata de anticipar sorpresas tardías en un proyecto mediante la identificación de los componentes de alto riesgo. El desarrollo basado en problemas también trata de eliminar la linealidad.Cualquier actividad de desarrollo, ya sea análisis, diseño del sistema, diseño de objetos, implementación, pruebas o entrega, puede influir en cualquier otra actividad. En el desarrollo basado en problemas todas estas actividades se ejecutan en paralelo. Sin embargo, el problema con los modelos de desarrollo que no son lineales es que son difíciles de manejar.
Administración de la fundamentación
Las suposiciones que hacen los desarrolladores acerca de un sistema cambian en forma constante. Aunque los modelos del dominio de aplicación se estabilizan a la larga una vez que los desarrolladores adquieren una comprensión adecuada del problema, los modelos del dominio de solución están en flujo constante. Las fallas de diseño e implementación descubiertas durante las pruebas, y los problemas de utilización descubiertos durante la evaluación del usuario activan cambios a los modelos de solución. Los cambios también pueden ser causados por nuevas tecnologías. La disponibilidad de baterías de vida larga y las comunicaciones de gran ancho de banda, por ejemplo, pueden provocar que se revisen los conceptos de una terminal portátil. El cambio introducido por nuevas tecnologías permite, con frecuencia, la formulación de nuevos requerimientos funcionales o no funcionales. Una tarea típica que deben realizar los ingenieros de software es cambiar un sistema operativo actualmente operacional para que incorpore esta nueva tecnología que lo permite. Para cambiar el sistema no es suficiente comprender sus componentes y comportamientos actuales. También es necesario capturar y comprender el contexto en el cual se tomó cada decisión de diseño. A este conocimiento adicional se le llama la fundamentación del sistema.
La fundamentación representa una cantidad de información mucho mayor que la que tienen los modelos de solución. Para manejar los sistemas cambiantes, los ingenieros de software deben enfrentar el reto de capturar y tener acceso a la fundamentación.
El desarrollo de un sistema de software requiere la colaboración de muchas personas con diferentes formaciones o intereses. El ciente ordena y paga el sistema. Los diseñadores contruyen, el gerente del proyecto planea y calcula el presupuesto del proyecto y coordina a los desarrolladores y al cliente. Los usuarios finales son apoyados por el sistema. compuesto por personas involucradas " participantes" y al conjunto de responsabilidades "papel".
Considere una máquina que distribuye boletos para un tren. Los viajeros tienen la opción de seleccionar un boleto para un solo viaje, para varios o una tarjeta temporal para un día. El distribuidor de boletos calcula el precio solicitado con base en el área en donde se realizará el viaje y a la edad del viajero. En este ejemplo, los viajeros son usuarios finales. La compañía de trenes que contrata el desarrollo del distribuidor de boletos es el cliente del proyecto. Los ingenieros que realizan el sistema (y el software), Carlos, Bladimir y Javier son desarrolladores.Su jefa Alicia, que coordina el trabajo y la comunicación con el cliente, es la gerente del proyecto. Usuario final, cliente, desarrollador y gerente del proyecto son papeles. Alicia, Carlos, Javier la compañía de trenes y los viajeros son participantes.
Sistema se refiere a realidad subyacente, y Modelo es cualquier abstracción de la realidad. Un distribuidor de boletos para tren subterráneo es un sistema. Los planos para el distribuidor, los esquemas de su alambrado eléctrico y los modelos de objetos de su software son modelos del distribuidor de boletos. Observe que un proyecto de desarrollo es, en sí mismo, un sistema que puede ser modelado. La calendarización del proyecto, su presupuesto y su tiempo de entrega planeado son modelos del proyecto de desarrollo.
Un producto de trabajo es un artefacto que se produce durante el desarrollo, como documento de software para los demás desarrolladores o el cliente. Nos referimos a un producto de trabajo para el consumo interno del proyecto como producto de trabajo interno. Nos referimos a un producto de trabajo para un cliente como una entrega. Las entregas se definen, por lo general, antes del inicio del proyecto, y están especificadas en un contrato que enlaza a los desarrolladores con el cliente.
En el ejm. de distribuidor de boleto, los manuales de operación y mantenimiento que necesita la compañía de trenes son entregas. los distribuidores de boletos y su software también. Los prototipos de demostración, escenarios de prueba y resultados producidos por los desarrolladores para el gerente del proyecto son productos de trabajo interno, a menos que estén especificados en el contrato como artículos que serán entregados al cliente.
Actividades, tareas y recursos
Una actividad es un conjunto de tareas que se realizan con un propósito específico. ej. la obtención de requerimientos es una actividad cuyo propósito es definir con el cliente lo que hará el sistema. La actividad puede estar compuesta por otras actividades o fases.
Una tarea representa una unidad atómica de trabajo que puede ser administrada: un gerente la asigna a un desarrollador, el desarrollador la realiza y el gerente supervisa el avance y terminación de la tarea. Las tareas consumen recursos, dan como resultados productos de trabajo y dependen de productos de trabajo que son producidos por otras tareas.
Los recursos son bienes que se usan para realizar el trabajo. Incluyen tiempo, equipo y mano de obra. Cuando se planea un proyecto, un gerente divide el trabajo en tareas y les asigna recursos.
Objetivos, requerimientos y restricciones
Un objetivo es un principio de alto nivel que se usa para guiar el proyecto. Los objetivos definen los atributos del sistema que son importantes. Proyectos diferentes tienen objetivos diferentes. El objetivo principal del desarrollo de software de guía del transbordador espacial es producir un sistema que sea seguro (es decir, que no ponga en peligro la vida humana). El objetivo principal del distribuidor de boletos es producir un sistema que sea altamente confiable (es decir, que funcione en forma correcta la mayor parte del tiempo).
Los objetivos a menudo entran en conflicto, es decir, es difícil lograrlos en forma simultánea. Por ejemplo, la producción de un sistema seguro, como una aeronave de pasajeros, es cara. Sin embargo, los fabricantes de aeronaves también necesitan poner atención en el costo de venta. Esto es, producir una que sea más barata que las de la competencia. La seguridad y el bajo costo son objetivos en conflicto. Una buena parte de la complejidad en el desarrollo de software viene de objetivos mal definidos.
Los requerimientos son características que debe tener el sistema. Un requerimiento funcional es un área de funcionalidad que debe soportar el sistema y, en cambio, un requerimiento no funcional es una restricción sobre la operación del sistema.
Proporcionar al usuario información sobre los boletos es un requerimiento funcional. Proporcionar retroalimentación en menos de un segundo es un requerimiento no funcional. Proporcionar un sistema confiable es un objetivo de diseño. Producir un sistema a bajo costo es un objetivo gerencial. Otras restricciones incluyen que se requiera una plataforma de hardware específica para el sistema o compatibilidad retrospectiva con un sistema heredado que el cliente no quiere retirar.
Notaciones, métodos y metodologías
Una notación es un conjunto de reglas gráficas o textuales para representar un modelo El alfabeto romano es una notación para representar palabras. El UML (Lenguaje de modelado unificado) es una notación orientada a objetos para la representación de modelos. Z es una notación para la representación de sistemas basado en la teoría de conjuntos.
Un método es una técnica repetible para la resolución de un problema específico. Una receta es un método para cocinar un plato específico. Un algoritmo de ordenamiento es un método para ordenar elementos de una lista. La administración de la fundamentación es un método para la justificación de los cambios. La administración de la configuración es un método para el seguimiento de los cambios.
Una metodología es una colección de métodos para la resolución de una clase de problemas. Un libro de cocina de mariscos es una metodología para la preparación de mariscos. El proceso de desarrollo de software unificado, la técnica de modelado de objetos, la metodología Booch, son metodologías orientadas a objetos para el desarrollo de software.
Las metodologías de desarrollo de software descomponen el proceso en actividades. La OMT proporciona métodos para tres actividades: Análisis, que se enfoca en la formalización de los requerimientos del sistema en un modelo de objeto. Diseño del sistema, que se enfoca en decisiones estratégicas, y Diseño del objeto, que transforma el modelo de análisis en un modelo de objeto que puede ser puesto en práctica. OMT supone que ya se han definido los requerimientos y no proporciona métodos para la obtención de los mismos. El proceso de desarrollo de software unificado también incluye una actividad de análisis y trata al diseño del sistema y al del objeto como una sola actividad llamada diseño, pero sí incluye una actividad de captura de requerimientos para la obtención y modelado de requerimientos.
Actividades de desarrollo de ingeniería de software
Las actividades de desarrollo incluyen:
Durante la obtención de requerimientos, el cliente y los desarrolladores definen el propósito del sistema. El resultado de esta actividad es una descripción del sistema en términos de actores y casos de uso. Los actores representan las entidades externas que interactúan con el sistema. Incluyen papeles como los usuarios finales, otra computadora con la que necesite tratar el sistema (por ejemplo, un banco de computadoras central, una red) y el ambiente (ejemplo, un proceso químico). Los casos de uso son secuencias de eventos generales que describen todas las acciones posibles entre un actor y el sistema para un fragmento de funcionalidad dado. (Fig. 1-2).
Durante el análisis, los desarrolladores tratan de producir un modelo del sistema que sea correcto, completo, consistente, claro, realista y verificable. Los desarrolladores transforman los casos de uso producidos durante la obtención de requerimientos en un modelo de objeto que describa por completo al sistema. Durante esta actividad, los desarrolladores transforman los casos de usos producidos durante la obtención de requerimientos en un modelo de objeto que describa por completo al sistema. Durante esta actividad, los desarrolladores descubren ambigüedades e inconsistencias en el modelo de casos de uso y las resuelven con el cliente. El resultado del análisis es un modelo de objeto comentado con atributos, operaciones y asociaciones.
Los desarrolladores definen los objetivos de diseño del sistema y descomponen el sistema en subsistemas que pueden realizar los equipos individuales. Los desarrolladores también seleccionan estrategias para la construcción del sistema, como la plataforma de hardware y software en la que ejecutará el sistema, la estrategia de almacenamiento de datos persistentes, el flujo de control global, la política de control de acceso y el manejo de las condiciones de frontera. El resultado de un diseño de sistema es una descripción clara de cada una de estas estrategias, una descomposición en subsistemas y un diagrama de organización que representa el mapeo en hardware y software del sistema.
Los desarrolladores definen objetos personalizados para cubrir el vacío entre el modelo de análisis y la plataforma de hardware y software definida durante el diseño del sistema. Esto incluye definir con precisión los objetos e interfaces de subsistemas, la selección de componentes hechos, la reestructuración del modelo de objeto para lograr los objetivos de diseño, tales como extensibilidad o comprensión, y la optimización del modelo de objetos para el desempeño. El resultado de la actividad de diseño de objetos es un modelo de objetos detallado, comentado con restricciones y descripciones precisas para cada elemento.
Los desarrolladores traducen el modelo de objetos en código fuente. Esto incluye la implementación de los atributos y métodos de cada objeto y la integración de todos los objetos de forma tal que funcionen como un solo sistema. La implementación cubre el vacío entre el modelo de diseño de objetos detallado y el conjunto completo de archivos de código fuente que pueden ser compilados juntos.
Las posibilidades y el mercado del software
Las características de los ambientes de producción y de uso del software han sufrido cambios radicales en las pocas décadas en que éste existe. Solamente con observar la evolución sufrida –y sufriente- de los Sistemas Operativos y de las formas de hacer computación que aquello conlleva, entrega una pauta clara de lo que la misma palabra “evolución” o “cambio” significa en el contexto de quien desarrolla y opera software.
Los profesionales de la informática no pueden estar ausentes de esta realidad, tanto porque ellos son llamados a imprimir este ritmo vertiginoso como que son las víctimas más directas de las desactualizaciones que se pueda sufrir en su propio ámbito de trabajo. Es difícil pensar en un profesional de la informática –entiéndase por ingeniero, analista, programador, etc.- que pueda dormir tranquilamente sobre los laureles del conocimiento adquirido en tal o cual método o sobre tal o cuál lenguaje de programación o sobre tal o cuál herramienta de apoyo al desarrollo de software.
En general, cualquier usuario del Software está sometido a presiones semejantes. Por ejemplo, cualquiera que haya pensado en comprar un computador se pregunta por la durabilidad de aquel, ya no contra el hecho concreto de la resistencia al paso del tiempo o del esfuerzo de soportar una carga de trabajo, como nuestros abuelos se preguntaban sobre el martillo recién adquirido. La pregunta clave es por la obsolecencia. Las compañías de hardware –y de muchos productos- han disminuido el ciclo a extremos en que la nueva versión de producto que actualmente se vende, aparecerá sólo un par de meses más tarde. Dejando como un modelo discontinuado el que actualmente se escribe estas líneas.
Quizá el software tenga un ciclo de vida mayor que el hardware, pero no es sustancialmente mayor. Por ejemplo, si el hardware aumenta el ancho de palabra de 32 a 64 bits aquello significará que es necesario un nuevo sistema operativo que permita aprovechar esa diferencia. Si a los pocos meses ese nuevo sistema operativo sale al mercado, es necesario que existan software que aproveche aquella plataforma, lo que involucra herramientas que permitan construir aquel software y así también aumenta la presión por la producción de nuevos productos, ya sea para diferenciarse de otros de la competencia ya sea para mantenerse en la cumbre de la actualización.
Las posibilidades en el mundo actual han aumentado explosivamente. Cualquiera puede comprar y/o vender en cualquier parte del mundo, ya no existen mercados aislados y los que lo son pierden rápidamente atractivo –observen el ejemplo de Corea del Norte y Cuba en algunos aspectos- y es como si no existiesen –de hecho no existe como posibilidades. Este aumento de las posibilidades de hacer negocios es lo que ha llevado a la situación que se describía en los párrafos anteriores.
Por ejemplo, en la edición No. 41, del 1 al 15 de Octubre de 1997, el periódico InfoWeek señala a raiz de la conversión de Taiwán de uno de los principales centros de desarrollo de tecnología de vanguardia luego de ser por años considerado la base de la piratería informática, lo siguiente:
“Analistas concuerdan que gran parte de este éxito se debe a que el país es pequeño y contiene cientos de industrias de diversos tamaños, versus el modelo de unos pocos gigantes dominando la industria. Esto le permite a los fabricantes instalados en Taiwán un fácil acceso a cientos de proveedores de de piezas a bajo costo, algo que la industria estadounidense no tiene. Además, el tamaño limitado de muchas de sus empresas les brinda mucha flexibilidad y adaptabilidad al constantemente cambiante mercado de las Tecnologías de la Información.”
En el ejemplo anterior se puede observar claramente cómo el aumento de posibilidades genera una dinámica que no existe en mercados en que aquellas posibilidades no están o está remitidas dentro de los márgenes de una organización.
¿Cuál es la moraleja de todo esto? Primero está en la importancia de las posibilidades, en el caso de Taiwan este desarrollo no hubiese ocurrido si es que no hubiese existido esa base de pequeñas empresas que conforman todo un espacio de posibilidades para la combinación y recombinación de sistemas de producción. Cosa que nunca hubiese podido ocurrir si la economía no permitiese la sobrevivencia de este tipo de empresas y con ello tenemos una segunda conclusión, la importancia de la cooperación por sobre la de la competencia, a diferencia del mercado estadounidense donde existen pocas grandes empresas resultado de años de competencia, el mercado taiwanés ya sea por su juventud o por formas distintas de hacer negocios todavía no manifiesta esa forma de reducción de posibilidades que sí –desde la perspectiva del artículo- manifestaría el mercado estadounidense.
Naturalmente la problemática que significan los mercados es mucho más compleja y, quizá las conclusiones que se han esgrimido sean parciales, producto de un análisis apresurado. Pero por eso no deja de ser cierto que las cantidad de oportunidades en un mercado es un catalizador sorprendente para el cambio.
Ahora la pregunta que nos interesa es sobre el surgimiento de las posibilidades. Claro, la dinámica del negocio informático es tal que ello significa que existen muchas posibilidades, y la pregunta es de donde ellas han surgido. Algo se anticipaba con relación al desarrollo del hardware que estaba presionado por factores como el aumento de la velocidad del cálculo, orientación que lleva al desarrollo de hardware cada vez más veloz y, por lo mismo, esto presiona a la industria del software a responder a aquella presión del hardware creando nuevo software adecuado a los nuevos requerimientos de la máquina.
La pregunta que ahora surge es: ¿es esto una forma de un desarrollo adecuado para quienes utilizan tanto el hardware como el software? No es simple responder esta pregunta, sobre todo que ella remite a dominios en que la ciencia no ha formulado respuestas muy adecuadas, como son los dominios del pensar, del sentir, del vivir de las personas. ¿Hemos sido responsables como desarrolladores al producir tales “artefactos”? ¿Es esta pléyade de oportunidades un beneficio? Quizá, no tenemos a mano aún las respuestas a tales cuestiones y el futuro lo dirá, si es que lo hace.
Independiente de lo que se entienda por información, no se puede negar que los profesionales del área de la computación y la informática trabajan han estructurado gran parte de su trabajo alrededor de este término. Es usual encontrarse con conceptos como: "Sistemas de Información", "Tecnologías de Información", "Procesamiento de la Información", etc. en la conversación cotidiana de los estudiantes y profesionales del área.
La noción de información sobre la que se articulan muchos de los conceptos anteriores es postulada por Shannon yWeaver en 1949 y se basa en un concepto de información definido por una expresión isomorfa con la entropía negativa de la termodinámica. Es un concepto clave en el posterior desarrollo de la "Teoría de La información" que adquiere importancia en el campo de la comunicación. El Trabajo de Shannon y Weaver se centró en algunos de los siguientes problemas que surgen en los sistemas destinados a manipular información: cómo hallar los mejores métodos para utilizar los diversos sistemas de comunicación; cómo establecer el mejor método para separar las señales del ruido; y cómo determinar los límites posibles de un canal.
Otra contribución importante a la formación del concepto de información es el aporte de la Cibernética (Wiener, 1948), que es una teoría de los sistemas de control basada en la comunicación (como transferencia de información) entre sistema y medio circundante, y dentro del sistema entre el mecanismo de control y la unidad de producción.
Lo anterior junto al desarrollo de la arquitectura de Von Neumman son los puntos de partida para el desarrollo de las "Tecnologías de la Información".
¿Qué es software?
La pregunta por el concepto de software no es una pregunta fácil de dilucidar.
Primero, no es posible tener una clara visión de lo que ha sido el software
durante los años que tiene de vida, poco más de cuarenta.
El software tiene una corta vida pero no por ello menos interesante, desde la
perspectiva de este trabajo aquellos 40 años de vida son profundamente
decidores. Para ello se ha extractado del libro: "Ingeniería de software,
un enfoque práctico" de Roger S. Pressman, los párrafos en que se detalla
esta evolución histórica:
El mismo Pressman avala más adelante esta visión que se intenta potenciar:
La cuarta era en software está ahora empezando...Ya, las técnicas de la cuarta generación para el desarrollo de software están cambiando la forma en que algunos segmentos de la comunidad informática construyen los programas de computadora. Roger Pressman, Ingeniería de Software, p.14.
Por ejemplo, si consideramos que un sitio WEB es software, esto determina una redefinición de lo que es este concepto, independiente de si él es o no explícito. Incorporar a la clase "software" una página HTML es, de todas maneras, una redefinición de la clase.
Tanto el concepto de software como el de información corresponden a las piedras angulares en las que se sustenta el trabajo del Ingeniero en Informática. Por lo mismo cualquier discusión que se determine en torno a ellos es de sumo provecho, tanto para reafirmar las posibilidades existentes como para incorporar nuevas.
Software toma el camino hacia las soluciones integrales
Hasta hace poco, cada vez que una compañía -grande, mediana o pequeña adquiría un software específico enfocado a satisfacer sus necesidades de negocios y de administración, debía incurrir muchas veces en una serie de costos antes de poder implementar eficazmente la aplicación en sus distintas áreas de trabajo.
Gastos de instalación, capacitación de los empleados, servicio técnico, imposibilidad de centralizar las funciones operativas, posibles fallas o caídas del sistema en momentos críticos eran sólo algunos de los problemas que a diario debían afrontar los clientes. La disyuntiva más grave era que estos clientes habían adquirido un producto que supuestamente debía facilitar y agilizar el trabajo . o, pero en cambio, el software se volvía un dolor de cabeza más para ellos.
Al parecer, este problema estaría llegando a su fin. El desarrollo y crecimiento constante de las redes informáticas -especialmente de Intemet- están cambiando la orientación de las soluciones en la gestión de los negocios. Y el servicio parece ser el elemento clave en este asunto.
Un nuevo tipo de compañías llamadas Proveedores de Servicios de Aplicaciones (PSA) están transformando el concepto que define al software como un producto grande, costoso y a menudo "irritante", en un servicio más amigable, eficiente y fácil de utilizar.
Los PSA -un nombre tentativo, no muy reconocido aún- proveen de todo el soporte y las herramientas necesarias para entregar tina solución integral de negocios a sus clientes. Además, muchos veces manejan paquetes complejos de software corporativo y los adecuan a las necesidades específicas de cada empresa, de manera que las aplicaciones sean más simples de manejar y de organizar.
Es decir, este nuevo tipo de proveedores está cambiando la forma en que los
programas son vendidos y distribuidos. ¿Se está generando una nueva revolución
en la forma de hacer negocios? ¿Quiénes son estos nuevos PSA? ¿Qué tipo de
cambios se están produciendo en el mercado actual? ¿A quiénes beneficiará
directamente y qué tipo de ganancias podrían generar?
Entonces, el cambio surge a partir de la capacidad de saber alinear el software, los servicios integrales e incluso el hardware a esta nueva demanda requerida por el mercado, tal como afirman los ejecutivos de IBM Chile, Rafael Guzmán, gerente de Servicios Profesionales, y Alonso Pérez-Luna, gerente de Software Group.
El tema no es nuevo para ellos: "Mientras otros están comenzando a hacerlo, nosotros lo estamos implementando hace mucho tiempo", afirma Pérez Luna, quien agrega que el e-business es una de sus principales armas de lucha en este campo.
Sin duda, para todas las compañías proveedoras de software esta nueva estrategia constituye un cambio importante en cuanto a la reestructuración interna que debe asumir cada una de éstas y a la capacitación que deben entregar a sus empleados.
"Esto significa un gran cambio respecto a lo que hacíamos hace 5 años. Esta era una compañía basada en tecnología y actualmente se ha transformado en proveedora de soluciones de negocios, capaz de crear nuevas habilidades y actitudes humanas", afirma el gerente general de Oracle para Chile y Perú, Fernando Prieto.
Para IBM el asunto también es muy relevante. Rafael Guzmán afirma que la
empresa posee un foco especializado en el tema, ya que cuentan con un grupo de
profesionales dedicados al software y, al mismo tiempo, poseen una organización
especializada en servicios de software. "El valor agregado está asociado a
los servicios profesionales", añade.
El otro gran aspecto que han debido tomar en cuenta estas organizaciones es la interacción con los clientes y la forma en que éstos han cambiado su forma de ver las cosas.
"Hemos tenido que aprender a conocer el negocio de nuestros clientes y cual es la relación de ellos, a su vez, con sus clientes", sostiene Fernando Prieto.
El gerente general de SAP Chile, Eugenio Pies, va más allá aún y establece incluso una fuerte autocrítica: "Un cliente no compra sólo un producto, porque con ello no resuelve su problema de negocios; eso es sólo una herramienta para resolver el problema. La clave es tener la funcionalidad y el conjunto de transacciones adecuadas para poder vender y planificar la producción, eso es lo que le da la razón de ser a la tecnología: su utilización, y su uso lo marca claramente la aplicación.
Con el concepto de la utilización hemos sido bien pobres en cuanto a dar una buena propuesta para las medianas y pequeñas empresas; éstas todavía piensan como trabajar con informática. Los costos son muy altos y no dependen del tamaño de la empresa sino del tamaño del proyecto, o sea, del costo fijo y eso es lo que había que cambiar".
Rafael Guzmán concuerda con ello y agrega que en Chile los participantes del mercado no han logrado cumplir una promesa que se hizo al mercado, ya que las expectativas de los clientes han sobrepasado largamente la oferta de servicios empresas. "Hay mucho aún por desarrollar".
Por lo visto, el cliente es el que manda, ya que hoy en día cuenta con mucho
mayor información y conocimientos, lo que le permite ser más exigente y tomar
mejores decisiones: él decide a quién le compra cómo y cuándo. Pero, la
pregunta parece ser ¿por qué?
Con esta herramienta, las empresas pueden "ubicarse" del lado del cliente: ver lo que éste necesita y desea en el ámbito de las prestaciones globales.
Asimismo, las compañías deben elaborar software cada vez más fáciles de utilizar, flexibles y adaptables a las necesidades de cada empresa en particular. Pero tal vez, lo más importante es que este cambio genera un significativo ahorro económico a los clientes.
La empresa ya no necesita contar con una interminable lista de organizaciones que diseñen los procesos de negocios, configuren el software de comercio electrónico, mantengan los computadores y organicen las redes, entre muchas otras cosas, sino que a partir de ahora le entrega toda la responsabilidad a una sola compañía. Y más aún, la empresa tiene la posibilidad de arrendar periódicamente el servicio y si no le gusta... se va y elige otra organización
Por ejemplo, Samsung cancela un poco más de US$ 10.000 al mes a la empresa USi por este servicio y gracias a que ahora se puede enfocar libremente en nuevas estrategias de negocios, actualmente cuenta con una posibilidad cierta de establecer un sitio en línea de sus productos que podría generar a la compañía más de US$ 100 millones en ventas anuales.
"Creo que el servicio que viene de ahora en adelante, trascenderá al servicio de implantación. En vez de contratar a alguien el hardware, a otro el software y a un tercero que los implante, ahora se van a subcontratar servicios en Internet que lleven la contabilidad, los inventarios y el apoyo informático para manejarse con los clientes; ése es el servicio del futuro", sostiene Eugenio Pies.
Vale decir, el software puede ser rápidamente aplicado y habilitado y, a la vez, el usuario puede recoger y actualizar información desde sus aplicaciones por la vía simple de los buscadores de la Red.
Pero no todas las compañías proveedoras de software están aplicando este nuevo servicio. Pedro Sorop, gerente general de Microsoft Chile, afirma que "las empresas tradicionales del rubro del software van a ser aquellas que van a ofrecer este nuevo servicio de soluciones integrales y muy posiblemente el canal de comercialización va a tener que ir emigrando hacia estos nuevos esquemas de trabajo".
El ejecutivo agregó que Microsoft aún no implementa este servicio y sólo están realizando una fase experimental en algunos países con el fin de conocer la reacción de sus clientes. "El hecho de que el software se pueda comercializar por medio de Internet a través de claves de activación no implica que vaya a desaparecer el canal, lo que esto implica es que la forma de hacer negocios va a cambiar. De hecho, Microsoft maneja todo el proceso de compra y al momento de vender, nuestra empresa hace referencia a partners que hacen la venta definitiva", puntualizó.
Los ejecutivos de las empresas proveedoras de software entrevistados
coincidieron en señalar que en nuestro pais, a, menos, resultará fundamental
contar con aliados estratégicos a fin de implementar de mejor forma posible las
soluciones globales para los clientes. Pastelero a tus pasteles" parece ser
la consigna que reina en el medio.
Es más, los ejecutivos coinciden en que más que una competencia para ellos, la labor de outsourcing implica un complemento a su propio trabajo. "Nosotros también podemos hacer outsourcing, hay complementación entre todos. Incluso, en CA trabajamos en forma complementaria con SAP", señala Arturo Ilabaca.
La mayoría habla de un cambio paulatino más que de una revolución del sistema. "No todas las empresas creen, hoy en día, en este servicio. Hay algunas que aún siguen siendo casas de software", afirma Ilabaca. Por su parte, Sorop agrega que "esto es una evolución, pero no una revolución. Estamos frente a un cambio de paradigmas, pero hay que ver primero la reacción de los clientes".
Eso sí, el cambio parece ser inevitable. El camino ya se trazó y todas las compañías parecen seguir inevitablemente el mismo destino: soluciones globales y completas para los clientes. Tal vez, las compañías que no ofrezcan este servicio seguirán en carrera, pero perderán competitividad en el mercado. Rafael Guzmán es tajante y afirma que si las empresas no cambian, ello se convertirá en "la crónica de una muerte anunciada".
Al parecer, todas las empresas "grandes", o por lo menos casi todas, están tomando parte en este mercado. "Yo diría que no hay que parar el cambio que se viene. Las empresas que no hagan uso de Internet verán menoscabadas sus oportunidades y eventualmente pueden tener peligro de desaparecer. Si hay alguien que no aporte a la cadena de valor, se verá desplazado", concluye Fernando Prieto.
El gerente general de SAP Chile concuerda con estas palabras y agrega un punto interesante al tema: "Los procesos de negocios ya no tienen fronteras. Antes se decía que el negocio llegaba hasta la puerta de tu empresa, ahora se traspasa esa puerta y se necesitan nuevas aplicaciones y servicios por medio de Internet para afrontar esta situación, Es decir, estos no son procesos que ocurren dentro de una empresa, sino que trascienden las fronteras de ella".
De las palabras de ambos ejecutivos se desprende que el valor agregado es el "plus" que marca la diferencia sustancial entre las empresas tradicionales y aquellas que desean entrar al mundo de las soluciones globales integrales.
IBM, según señala Rafael Guzmán, marca la diferencia con una clara metodología empresarial de servicios. Para Arturo Ilabaca, CA posee un capital insuperable: gente calificada y experta, tanto propia como de sus partners.
Tal vez, las palabras de Eugenio Pies resumen de manera acertada el nuevo
enfoque empresarial que enfrenta a las compañías de software: "Quizá, lo
más importante no es la calidad del producto o su diseño, sino el respaldo y
soporte que una empresa puede ofrecer. Es el valor agregado lo que está detrás
y lo que, a fin de cuentas, importa. Ese es el desafío planteado para más
adelante".
Arturo Ilabaca afirma que CA facturó en 1998, en el primer año en el área de los servicios, cerca de US$ 1.100 millones, lo que indica que en un tiempo tan corto de implementación hay una rentabilidad muy grande. Para este año esperan duplicar las ganancias. "Por cada dólar que se genera por un producto, existen US$ 2 en servicios, es decir hay una clara tendencia a que los servicios superen a los productos". A su vez, Fernando Prieto, manifestó que el pasado año fiscal la empresa generó en este rubro ganancias por cerca de US$ 31 millones en negocios verticales en Chile y Perú.
Según se puede concluir, las empresas más preparadas para ofrecer estos servicios parecen ser las proveedoras de software (y sus partners), aunque los expertos no descartan a otras organizaciones que se interesen por participar en este mercado tan apetitoso.
Hoy en día, existe un gran mercado de clientes que desea satisfacer sus múltiples negocios en forma rápida, económica y más efectiva. Entonces, la habilidad para saber entregar a cada cliente lo que necesita en forma particular y específica, es lo que puede hacer que este nuevo mundo del software despegue hasta dimensiones aún por descubrir.
Falta describir con los detalles suficientes los atributos físicos y las características de funcionamiento de la solución propuesta, de manera que las personas que deben aprobarla, los encargados de su construcción y quienes la manejarán y conservarán, puedan desempeñar satisfactoriamente sus funciones. El hecho de que alguien distinto de nosotros por lo general construya, opere y cuide nuestras obras, hace que adquiera especial importancia la presentación cuidadosa por escrito y la comunicación exacta de ellas.
Los datos de salida de esta fase consisten usualmente de dibujos del proyecto, un informe escrito y, posiblemente, un modelo físico o icónico tridimensional. Los primeros de estos medios de comunicación, que se llaman a menudo "los planos" simplemente, son dibujos de la solución cuidadosamente realizados; detallados y acotados.
El segundo medio, el informe técnico suele ser un documento bastante formal que describe la propuesta con palabras, diagramas y croquis. Este informe también describe el funcionamiento de la solución y proporciona una evaluación cabal de ella. Es por medio de estos informes como la aptitud de expresarse se manifiesta a la gente, a la que queremos impresionar favorablemente.
A veces se complementarán los planos y el informe con un modelo físico. Este es un medio de comunicación efectivo y de gran ayuda para favorecer la aceptación de la propuesta por nuestros superiores, clientes y el público.
Es probable que esta fase del proceso de diseño comprenda detalles considerables. Los dibujantes y otros auxiliares técnicos pueden librarlo a uno de una parte de la carga; pero, en general, usted debe especificar los tipos y propiedades de los materiales con los que se construirá su obra, así como sus dimensiones, métodos de unión o fijación, tolerancias y detalles esenciales semejantes.
El Proceso de Diseño en vista retrospectiva
Probablemente usted sea víctima de ciertos hábitos de pensamiento que interfieren con su habilidad de resolver problemas. Si ha de desechar tales hábitos, tendrá que trabajar en ello. Para esto se requiere una disciplina consciente de la mente. El esfuerzo valdrá la pena, pues la retribución consistirá en obtener resultados adecuados en la resolución de problemas profesionales y personales. Autores famosos recomiendan que dediquemos cuidadosa atención a nuestra técnica de diseño. Estudie y aplique el proceso hasta que sea algo natural para usted. Examine su enfoque y realice una autocrítica constructiva. Después que haya tenido experiencia, quizá desee modificar el procedimiento que se ha recomendado, y adoptar otro que se ajuste mejor a sus necesidades y preferencias. Lo anterior será excelente, pues significaría que está prestando atención a sus métodos de diseño, lo cual es exactamente lo que desean los famosos autores.
Una encuesta entre profesionales y maestros de ingeniería amantes del progreso, revela una creencia general de la existencia de un procedimiento particular de diseño, que a largo plazo da excelentes resultados, tanto en la calidad de las soluciones como en el costo de llegar a ellas. Es cierto que aun el más deficiente enfoque para resolver problemas puede dar ocasionalmente una solución aceptable, pues un elemento del azar está comprendido en la generación de ideas. Además, el empleo de un enfoque óptimo no garantizará que las soluciones finales de todos los problemas serán mejores que las que pudieran obtenerse mediante procedimientos deficientes. La diferencia está en la probabilidad de obtener superiores resultados de modo que la ganancia consistirá en el mejor desempeño de usted en su trabajo, a largo plazo.
Aunque hay un acuerdo general sobre la existencia de un procedimiento óptimo de diseño y sobre sus principales características, las autoridades en la materia no concuerdan en los aspectos específicos. Por ejemplo, todos los autores recomiendan que se empiece el ataque de un problema con una cuidadosa definición de éste. En este aspecto otros autores no están de acuerdo con la mayoría, sino que recomiendan una definición del problema en dos etapas: el cuadro general primero y luego los detalles. Algunos autores no dicen nada concreto acerca de cómo definir un problema; otros recomiendan seguir un sistema y una nomenclatura. Se mencionan estas diferencias para que usted esté preparado si ha de seguir estudiando más la materia del diseño, lo cual es muy recomendable.
El proceso de diseño es una serie de etapas en la evolución de la solución a un problema. El objeto de cada fase es diferente; asimismo lo será el tipo de actividad en la resolución de problemas que predomine en cada uno. Sin embargo, estas etapas no tienen fronteras bien definidas, ni tampoco constituyen la serie ordenada de pasos concretos y bien definidos que esperaría el idealista. Hay cierta confusión a medida que el énfasis pasa de una fase a la siguiente. Ocasionalmente, las soluciones se le ocurrirán a uno mientras la definición del problema sea la actividad predominante; durante la fase de búsqueda puede decidirse reformular el problema. Similarmente, es imposible no efectuar una cierta evaluación en la fase de búsqueda. El azar juega un papel significativo en este proceso; nuevas informaciones y nuevas ideas se descubren inesperadamente, se revelan consecuencias adversas y se encuentran callejones sin salida.
En algunos casos el proceso de diseño estudia sólo las características generales de la solución, tratando temporalmente los subsistemas y componentes como "cajas negras". Lo anterior se realiza a veces en un estudio de factibilidad, donde los detalles se especifican solamente al grado necesario para permitir al ingeniero predecir satisfactoriamente los costos de desarrollar y producir el dispositivo, y pronosticar la aceptación por los consumidores. El diseño detallado depende de las predicciones favorables.
En el diseño de sistemas a gran escala se emplea un procedimiento similar debido a la complejidad del trabajo total. Un satélite de telecomunicaciones tiene numerosos subsistemas principales, cada uno con cientos o miles de elementos en los cuales interviene el trabajo de muchos ingenieros. En el diseño de tan complicado dispositivo, las características generales de cada subsistema se especifican sin dar mucha atención a los detalles de los componentes. Después que se hayan establecido tentativamente los aspectos más amplios del sistema total, se inicia al diseño detallado de subsistemas y elementos. Se asigna un equipo de ingenieros a cada subsistema principal y a cada equipo se le dan determinados datos de entrada y de salida, restricciones sobre tamaño, peso, etc., que se fijaron en la fase de diseño del sistema total. El diseño del sistema total y el de sus subsistemas obviamente están muy relacionados, como sucede también con las actividades de los diferentes equipos.
La recurrente cuestión de la factibilidad económica
Hay notablemente pocas cosas que el hombre no pueda lograr con el tiempo y el dinero suficientes. Rara vez el problema consiste en si un dispositivo puede ser creado para un fin determinado. Es casi seguro que podrá realizarse si alguien está dispuesto a pagar el precio. La cuestión real suele ser la siguiente: ¿puede crearse una solución conveniente? Por lo tanto, en la mayoría de los casos la factibilidad técnica no es un obstáculo, pero sí lo es la factibilidad económica.
La concepción de un diseño implica la hipótesis de que una solución al problema es factible económicamente y que será retribuida con creces la inversión en ingeniería y otros recursos para crear una solución. Antes de empezar a diseñar una máquina para ensamblar o montar algo, los ingenieros deliberan sobre las posibilidades de un resultado ventajoso. La decisión para llevarlo a cabo se funda en su juicio, en la experiencia anterior en trabajos semejantes y en la disposición a aceptar un cierto riesgo.
Desde el momento en que comienza un diseño se pone a prueba la hipótesis de que se producirá una solución ventajosa
Esta cuestión se plantea repetidamente, aunque no siempre en forma explícita, en el proceso de diseño: "Sobre la base de lo que se ha aprendido hasta ahora en el proyecto, ¿se tienen indicios de una utilidad suficientemente alta para que se justifique la continuación?" Así, pues, en cualquier momento desde su etapa conceptual hasta la de especificaciones, un proyecto está sujeto a ser suspendido si la información acumulada indica que probablemente no se hallará una solución conveniente según las condiciones actuales de la tecnología.
Por supuesto, al principio de un proyecto se sabe relativamente poco acerca de la probable solución final, de manera que en esta etapa hay mucha incertidumbre y, por lo tanto, un riesgo apreciable de estar equivocado al suponer que el resultado es económicamente factible. A medida que se avance en el proyecto se obtendrán soluciones alternativas, se apreciarán otras posibilidades y adquirirá más importancia alguna otra información sobre la cual basar una respuesta a la cuestión siempre presente de la utilidad o conveniencia. Por lo tanto, el riesgo de tomar una decisión equivocada es máximo al principio de un proyecto, y disminuye progresivamente a medida que se avanza y se acumula la información.
Las recomendaciones relativas a la factibilidad económica de los proyectos en perspectiva son una parte muy importante del trabajo de un ingeniero. Tales decisiones están lejos de ser sencillas y, sin embargo, al ingeniero que ha cometido varios errores a este respecto no se le considera favorablemente.
El trabajo de un ingeniero rara vez termina al especificar una solución; su responsabilidad se extiende ordinariamente hasta la obtención de la aceptación de su diseño, la vigilancia de su instalación o construcción y su uso inicial, la observación y evaluación del mismo durante su funcionamiento y la decisión (o bien, la ayuda para tal decisión) de cuándo sea aconsejable un nuevo diseño.
Acondicionamiento de la solución. No suponga que las soluciones ideadas serán adoptadas automáticamente, construidas en forma apropiada y utilizadas como se ha previsto. Muchas cosas pueden ir equivocadas y hay que tornar medidas para evitar esto, entre el momento que se especifica una solución y aquél en que se ha realizado.
Por ejemplo, se necesitan algunas disposiciones para asegurar que la solución sea aceptada por la gente a quien corresponda. Los ingenieros a menudo comienzan su carrera con la errónea impresión de que si sus proposiciones son técnica y económicamente correctas, serán naturalmente aceptadas. Pero la ingeniería es por lo general una función jerarquizada en una organización, de manera que los ingenieros emiten sólo recomendaciones y no órdenes. Lo anterior, más la posibilidad de que haya diferencias de opinión, hace imperativo el hecho de que hay que dedicar una cuidadosa atención al aspecto de lograr la aceptación de las propuestas.
Los ingenieros jóvenes son susceptibles a desanimarse después de que varias de sus proposiciones hayan sido rechazadas. Están inclinados a culpar a otras personas, a su organización y a cualquier otra persona o circunstancia, menos a ellos mismos. Pero lo cierto es que han subestimado la necesidad de una presentación adecuada de sus propuestas, de persuadir a otros del valor de sus ideas, de tener un cierto compromiso realista respecto a algunas de las características de sus diseños propuestos, y de una cuidadosa planeación para reducir al mínimo la oposición al cambio.
Vigilancia continua. La vigilancia periódica de sus soluciones en uso, es especialmente valiosa por su utilidad para mejorar futuros diseños. Raro es el ingeniero que no puede beneficiarse por la observación de su obras puestas en servicio.
Reactivación del proceso de diseño. La evaluación periódica de las soluciones en uso también proporciona una base para decidir cuándo hay que diseñarlas de nuevo. Ninguna solución a un problema práctico conserva indefinidamente su calidad. Con el tiempo se descubren nuevos métodos, se presentan nuevas demandas, se acumulan nuevos conocimientos, cambian las condiciones y se produce el deterioro físico. En consecuencia, se alcanza un punto, en la vida de un diseño en que es ventajoso buscar una mejor solución. Un departamento de ingeniería puede decidir inteligentemente cuándo emprender un rediseño sólo si se revisan periódicamente las soluciones corrientes a los problemas de su campo.
El ciclo de diseño se completa cuando, después de que una solución a un problema se ha ideado y utilizado por varios años, se da uno cuenta de que sería provechoso un nuevo diseño, y entonces se inicia otra vez el proceso de hallar una solución adecuada.
Variedad de los problemas de Diseño en Ingeniería
Se describirán a continuación dos trabajos de ingeniería para ilustrar la amplia aplicabilidad del proceso de diseño. El trabajo A comprende el diseño de un dispositivo que convierta directamente la palabra hablada en escrita. La entrada será un mensaje verbal y la salida tiene que ser el registro en papel de dicho mensaje. Tal dispositivo obviamente tiene valor comercial.
El trabajo B implica también un diseño. Un ingeniero está empleado en una compañía que fabrica equipos eléctricos, tales como motores y transformadores, y monta estos elementos en sistemas de potencia diseñados para satisfacer las necesidades particulares de clientes individuales. La mayor parte de éstos son fábricas, refinerías, empresas tipográficas, etc. Un cliente potencial, una compañía manufacturera de papel que planea construir una nueva planta, ha solicitado al ingeniero que se familiarice con el proceso de fabricación de papel, que efectúe una cabal investigación de las necesidades de la empresa y que diseñe luego un sistema eléctrico completo de potencia adaptado al proceso. Al realizar lo anterior, el ingeniero se basará naturalmente en los equipos fabricados por su compañía y presentará al futuro cliente su diseño junto con el precio del sistema. Si su sistema es comprado, supervisará su instalación y permanecerá en contacto con su obra hasta que el nuevo sistema esté funcionando normalmente.
El trabajo A trata principalmente de la concepción de un nuevo dispositivo. Hay un mínimo de experiencia anterior en qué apoyarse; se requieren muchas ideas originales y puede ser necesaria la investigación.
El trabajo B trata primordialmente de la aplicación de dispositivos y elementos existentes a la satisfacción de las necesidades de clientes específicos. Para este tipo de trabajo el ingeniero puede utilizar un gran acervo de experiencia en el diseño de tales sistemas para casos semejantes. Aunque cada situación es diferente hasta cierto grado, el trabajo de diseño difícilmente podría considerarse como exclusivamente original.
Mientras que la principal dificultad del trabajo A proviene de su naturaleza de obra única sin antecedentes, en el caso B consiste en adquirir un completo conocimiento de los requisitos particulares de un cliente específico. La principal recompensa ofrecida por el trabajo A es la oportunidad de crear algo básicamente nuevo para beneficio de la humanidad; en el caso B, es la oportunidad de servir directamente a un cliente y observar los resultados y la satisfacción experimentada por él.
Estas dos clases de trabajo están cerca de los extremos de una amplia
variedad de tipos de actividades de diseño. En tal variedad quedan comprendidos
trabajos tales como el diseño de un vehículo interplanetario para pasajeros,
una cortadora automática del cabello, una carretera a prueba de accidentes, una
fábrica, un automóvil, una planta de cemento, un puente y algún otro que
usted se
encuentre. La solución de cada uno de estos problemas requiere la
aplicación del proceso de diseño.
Por ejemplo, hay un grado óptimo para el refinamiento de un modelo. A largo plazo los errores originados por las predicciones hechas con el modelo tendrán un costo apreciable. Lo anterior se debe a que se producen equivocaciones, fallas, accidentes, reparaciones y cambios cuando las decisiones se han basado en predicciones erróneas, o a que se necesitan altos factores de seguridad para prevenir tales condiciones adversas (por ejemplo, cuando se construye una viga con un tamaño del doble del que predice una ecuación).
Los proyectistas de una planta química confían en un modelo analógico para hacer predicciones en las que puedan basar su diseño. Si después que la planta haya sido construida hay un pequeño desacuerdo entre el funcionamiento predicho y el real, tal situación es de poca importancia práctica y se acepta como inevitable. En este caso es despreciable el costo de la falta de correlación entre los resultados predichos y los reales.
Selección de una "Herramienta para el Trabajo"
Imagínese que está usted en su escritorio trabajando en un cierto problema y que en primer lugar tiene un sistema de ecuaciones simultáneas que resolver. Es de esperarse que no proceda a resolverlas automáticamente, en la forma en que su profesor le enseñó en la universidad; en vez de eso haga una pausa y piense... ¿el método de substitución, el de substracción, el de tanteos, los medios gráficos, los determinantes, la computadora, algunos otros? Luego, para elegir la mejor de estas posibilidades, considere el tiempo probable requerido por cada procedimiento, el costo del equipo utilizado y la exactitud obtenida. Sobre la base de estos criterios juzgue qué alternativa se adapta mejor a esta situación.
0 bien, suponga que tiene un conjunto de números cada uno de los cuales debe elevarse al cuadrado, sumado, promediando, etc. Desde luego, la computadora no es automáticamente el medio adecuado. Muy posiblemente el método más rápido y barato es el procedimiento ordinario de lápiz y papel, o bien, la calculadora o aun la exploración a ojo de las cifras y la estimación de las cantidades que se necesitan. Quizá, también, se pudiera dar ese trabajo a un empleado. El punto es que hay numerosas alternativas y se deben considerar antes de emprender una tarea determinada.
Ya se ha dicho: Hay alternativas. Estos estudios de casos de los métodos alternativos de resolución de problemas, ilustran la naturaleza de casi toda técnica, procedimiento y dispositivo que podrá emplearse. Se verifica lo anterior ya sea que se trate de medir, predecir, calcular, comunicar, etc. Y como ninguna de las alternativas es óptima en todos los casos, toca a uno considerar las posibilidades y hacer una selección inteligente antes de iniciar un trabajo dado. Pero, pongámonos de acuerdo primero. Las escuelas de ingeniería actuales, en general, no cumplen con la tarea de estimular al alumno a efectuar lo anterior, ya que no enseñan cómo. De manera que incumbe a algunos profesores que sí dan atención a este asunto y principalmente a usted, el desarrollo de su aptitud para optimizar sus métodos de resolución de problemas.
Cómo no hay que hacer la selección?. En parte por falta de tiempo, no se le enseñan a usted en sus estudios superiores todas las formas aceptables de resolver un tipo dado de problemas. Pero no hay que permitir que lo confunda a uno el hecho de que se le enseñe sólo un modo de resolución; puede suponerse de seguro que para cada problema existen alternativas que vale la pena considerar. Además, probablemente lo más sensato mientras se está en la universidad es resolver cada tipo de problema como se le haya enseñado, pero una vez graduado se deben explorar todas las alternativas y utilizarlas cuando sea apropiado. No hay que continuar por años resolviendo un tipo particular de problema con un método determinado, sólo porque es el procedimiento que se aprendió en la academia. (Es muy probable que sea caprichoso y consuma más tiempo del necesario en un determinado número de casos.)
Hay otras razones indeseables para resolver siempre un tipo de problema de cierta manera. Una es el hábito o costumbre, que por supuesto es el camino de menor resistencia. A menudo es mucho más fácil utilizar mecánicamente y a ciegas el mismo procedimiento cada vez que se presenta un tipo de problema, que detenerse y razonar, considerar y quizás cambiar el método. Y no se piense que en la práctica de la ingeniería no hay manías, ni tampoco ingenieros que resuelven problemas por métodos ultrarrefinados sólo con el fin de impresionar a sus colegas. De seguro que algunos trabajos son efectuados con una computadora cuando bastarían procedimientos más simples y baratos, sencillamente porque estas máquinas están de moda y se causa una buena impresión. (Pero lo anterior no es propio de la buena práctica de la ingeniería.)
Cómo se debe hacer la selección?. Primero, búsquense las alternativas disponibles para el trabajo que se tenga, luego aplíquese un sólido criterio para elegir el enfoque que sea óptimo en la situación particular.
Supóngase que se está diseñando una gran terminal de autobuses que pueda manejar varios miles de vehículos de transbordo por día. En particular, se desea predecir la capacidad, las líneas de espera (o colas) de personas, los conflictos en el abordaje de los autobuses y la efectividad general de los diferentes diseños considerados. Para este objeto se puede recurrir a uno o a varios de los siguientes métodos principales de predicción: su propio juicio, un modelo matemático, la simulación o los experimentos con el objeto real. Al elegir un método para este trabajo se deben aplicar estos criterios:
• El costo del error en las predicciones, que depende de la magnitud de tal error y de su influencia sobre la situación concreta. En un cierto caso un error podría no tener consecuencias; en otro, el mismo error podría originar pérdidas de vidas y daños a la propiedad.
• El tiempo absoluto necesario para hacer las predicciones. Un juicio puede formularse en unos cuantos segundos; la construcción de un prototipo a escala natural para ensayarlo en las condiciones reales, puede demorar semanas o meses un proyecto.
"Herramientas" elegantes. Hasta ahora hemos hablado de
optimización, razón beneficio a costo, alternativas y criterios, en lo que se
refiere a su aplicación a los métodos de resolución de problemas. Un aspecto
que es particularmente apropiado es el concepto de elegancia. Obsérvese que las
recomendaciones de sencillez y elegancia se aplican tanto a
los métodos para lograr las soluciones como a las soluciones mismas. En este
sentido la elegancia es la utilidad de una "herramienta" con relación
a su complejidad. Hay programas elegantes de computadora y otros no tanto, y lo
mismo puede decirse de los métodos de análisis de esfuerzos, procedimientos
computacionales, métodos de medición, etc. Aunque quizá se piense que uno
nunca utilizaría una técnica o procedimiento innecesariamente complicado en el
curso de la resolución de un problema, vale la pena mencionar este punto. Sin
vacilación empléense computadoras o matemáticas complicadas cuando sean los
mejores medios para el trabajo que va a realizarse, pero hay que evitar ser como
el individuo que toma un tractor para hacer un trabajo de dos minutos que sólo
requiere una pala.
La ingeniería de Software fue definida por Bauer a finales de los 60s como el establecimiento y uso de principios de ingeniería para obtener software que fuera confiable y que funcionara eficientemente con las máquinas reales. A pesar de ser vieja, esta definición da el sentimiento correcto detrás de la disciplina.
La importancia del uso de estas medidas es característica para todas las disciplinas de la ingeniería. En un framework de ingeniería, la métrica se refiere a estándares de las medidas usadas para cuantificar aspectos específicos de un proceso, de un producto o de un proyecto de la ingeniería. Una medida es el mapa de un mundo empírico a un mundo más formal y más matemático.
Los desarrollos de ingeniería de Software comenzaron con la técnica de programación y después fueron utilizados en otras fases del ciclo vital del software. La programación estructurada fue seguida por otros métodos estructurados de análisis y tambien métodos estructurados de diseño. Además, comenzaron tecnologías orientadas a objeto. En épocas tempranas la programación era la tarea de oro de ingeniería del Software pero ahora la ingeniería y el diseño de requisito son más populares. En los años 90s la gerencia de proyecto ganó interés y llego a ser un componente importante en ingeniería del Software. En la década pasada, los estándares de la ingeniería de Software y la madurez de proceso han caracterizado la industria del software como una disciplina madura.
En un nivel técnico, la ingeniería de sistema de información comienza con una serie de tareas que hacen modelos y que resultan en una especificación completa de requisitos y una representacion comprensiva de diseño del software que será construido. Se han desarrollado muchos métodos para hacer modelos de sistemas de información. Sin embargo, los métodos orientado a objeto van a llegar a ser el estandard. Para ciertos sistemas de información crítico, se han desarrollado métodos formales para producir sistemas con la integridad más alta. Los métodos formales confían en las técnicas matemáticas que expresan y modelan los requisitos de cualquier producto en el ciclo vital del software. El uso de métodos formales es recomendado cuando sea posible en un ciclo vital del software.
El Desarrollo de Software Orientado a Objecto comenzó en los 80s como una etapa natural de los métodos estructurados. UML (Unified Modeling Language) ha emergido como una unificación de los diversos métodos orientados a objeto y se está convirtiendo en un estándard de ISO.
Actualmente, la tecnología de componente es un método para desarrollar sistemas de información que está creciendo. A diferencia de los métodos tradicionales, la tecnología de componente ensambla componentes para formar una solución de software. Acualmente, hay dos estándares de componentes en competencia: JavaBeans por Sun y DCOM por Microsoft. Los componentes de software son materiales reusables para construir sistemas de software. La tecnología Component-Base (Basada en Componentes) es un método poderoso por la empresa de la ingeniería de sistemas de información porque es una tecnología que reduce el conflicto entre sistemas de alta complejidad y de la búsqueda para la alta calidad y la productividad.
La ingeniería de Software es una disciplina que todavía se está desarrollando. Podemos esperar en el futuro su crecimiento y madurez en los próximos años.
(Ver Bibliografía y enlaces de interés)
Ing. Gustavo Martínez Villalobos <gmartin@nevado.cui.edu.co>