REVISTA ANTIOQUEÑA DE LAS CIENCIAS COMPUTACIONALES Y LA INGENIERÍA DE SOFTWARE

ISSN: 2248-7441

Vol. 3, No. 1 (2013) Enero - Junio

Una publicación semestral del Instituto Antioqueño de Investigación IAI

© 2013 Instituto Antioqueño de Investigación

De Medellín para el mundo

Investigar – Aplicar – Innovar

REVISTA ANTIOQUEÑA DE LAS CIENCIAS COMPUTACIONALES Y LA INGENIERÍA DE SOFTWARE

—RACCIS—

Instituto Antioqueño de Investigación IAI

Enero - Junio 2013

Vol. 3, No. 1 Enero - Junio 2013

ISSN: 2248-7441

Dirección - Edición Prof. Edgar Serna M.

Diseño y Publicación

Instituto Antioqueño de Investigación –IAI–

El contenido y/o cualquier restricción legal que afecte los artículos, es responsabilidad exclusiva de los autores.

Derechos Creative Commons

Por favor hacer mención de la fuente

RACCIS

www.fundacioniai.org/raccis raccis@fundacioniai.org

IAI

www.fundacioniai.org contacto@fundacioniai.org

Objetivo de la Revista RACCIS

“Divulgar la producción científica nacional e internacional a través de artículos producto de la investigación, la reflexión o la revisión alrededor de las Ciencias Computacionales y la Ingeniería de Software”.

CONTENIDO

5 Editorial

6-11 Systems Engineering Analysis Análisis a la Ingeniería de Sistemas Serna, A.A.

12-18 What is that Thing Called Computer Science? ¿Qué es esa Cosa Llamada Ciencias Computacionales? Schokosva, N. & Buskova, I.

19-24 Analysis to the Culture Shock in Scientific Software Development Análisis al Choque de Culturas en el Desarrollo de Software Científico Boleros, C.

25-32 Introduction of the Formal Methods in Software Engineering Training

Introducción de los Métodos Formales en la Formación en Ingeniería de Software Toledo, B.J.

33-37 Software Testing as Science La Prueba del Software como Ciencia Gallesdic, I. & Killiospy, G.

38-42 The Interview as an Approach to Elicit Requirements La Entrevista como Enfoque para Elicitar Requisitos Iriarte, L.M.

Revista Antioqueña de las

Ciencias Computacionales y la Ingeniería de Software

ISSN: 2248-7441

www.fundacioniai.org/raccis raccis@fundacioniai.org

5

Editorial

Evaluar la actualidad de la Formación en Ingeniería de Sistemas La evolución natural de las necesidades sociales no se detiene. Tal es el caso de la actual Sociedad de la Información y el Conocimiento, en la que la complejidad de los problemas es cada vez mayor y donde se requiere la micro-especialización para poderlos comprender y presentarles soluciones. En esta sociedad, ya no es suficiente con asistir cinco o seis años a un proceso formativo de educación superior, hoy se requieren profesionales especializados en áreas determinadas, contrario a lo que se vivió en la era industrial, cuando el conocimiento era poco y los problemas sencillos. Es por esto que es necesario hacer un alto y evaluar la pertinencia de seguir formando en Ingeniería de Sistemas. Porque estos programas lo que han hecho en su corta historia es egresar profesionales con conocimientos en diversas áreas de los sistemas, pero sin una especialidad determinada. Actualmente, el desarrollo de las nuevas tecnologías exige que el conocimiento se distribuya en cómo ponerlo al servicio de las necesidades sociales, para responder a los requerimientos y en los momentos que se necesite. Pero los ingenieros de sistemas de hoy están capacitados para mucho y, al parecer, para nada. Esto se percibe en las manifestaciones de la industria, en el sentido que se ven en la necesidad de capacitarlos para enfrentar procesos y resolver situaciones, para las que deberían estar preparados desde la academia. Esta situación es comprensible desde el punto de vista que para el conocimiento de este siglo, tan amplio y tan diverso, es necesario seleccionar el área para la cual la mente se encuentra mejor preparada, y especializarse en ella para el ejercicio profesional. La Ingeniería de Sistemas cubre tantas áreas como intereses formativos tenga la academia y los profesores, pero esto lo ve la industria como un error, porque no necesita profesionales con estos perfiles, sino que posean un conocimiento orientado de acuerdo con el pensamiento de Descartes, de que debemos ocuparnos sólo de aquellos objetos que pueden ser conocidos por nuestro espíritu de un modo cierto e indubitable. Es decir, para el área que se tiene la vacante. Desde el área de los sistemas se han originado diversos campos de especialidad, los cuales también se reflejan en las necesidades industriales. Por ejemplo, hoy se requieren Arquitectos de Sistemas, quienes son los encargados de integrar las diversas tecnologías que necesita una empresa para hacer funcionar su modelo de negocio. Por otro lado, los Ingenieros de Software se convierten en imprescindibles, porque los productos software que se requieren hoy necesitan ser desarrollados, no programados, por profesionales en el área. Resulta que la academia asegura que sus ingenieros de sistemas están capacitados para llevar a cabo ambas funciones, aunque una rápida revisión a las mallas curriculares y a los contenidos temáticos denote que esto no es cierto en el sentido amplio que se expresa. Porque cada institución estructura sus programas de acuerdo con unos intereses particulares, esencialmente de los profesores, para responder a un entorno del que, en la mayoría de los casos, no tiene un conocimiento adecuado. Al parecer, una cosa es lo que piensa y hace la academia y otra muy diferente es lo que necesita y solicita la industria y la sociedad. La finalidad de la formación en Ingeniería de Sistemas debería ser la de atender los requerimientos sociales de estos profesionales pero, de acuerdo con las observaciones de estos actores, no se está logrando. Es el momento de hacer un análisis a esta situación y atenderla lo más pronto posible. Mientras que el desarrollo no se detiene, los problemas incrementan su complejidad, la sociedad solicita mayor atención y la industria desea ser más competitiva, la academia y el Estado parecen no enterarse y continúan con su mismo objetivo formativo. Por todo lo anterior, es hora de analizar el presente y la prospectiva de la Ingeniería de Sistemas. Ni la industria, ni la sociedad necesitan más profesionales “toderos”, hoy se requieren especialistas para poner a funcionar o para proyectar los modelos industriales, y lograr productos que satisfagan las cada vez más complicadas necesidades sociales. Se necesita un trabajo de diálogo entre la academia, la industria y el Estado, para llegar a acuerdos sobre el terreno, y que la academia y los profesores comprendan que el hecho de que en sus aulas todo funcione, esto no pasa de la misma manera en el contexto social e industrial, es decir, en la realidad.

RACCIS, 3(1), 5, 2013

Revista Antioqueña de las

Ciencias Computacionales y la Ingeniería de Software

ISSN: 2248-7441

www.fundacioniai.org/raccis

raccis@fundacioniai.org

6

Systems Engineering Analysis

Análisis a la Ingeniería de Sistemas

Alexei Serna M. Instituto Antioqueño de Investigación. alexei.serna(AT)fundacioniai.org INFORMACIÓN DEL ARTÍCULO Tipo de artículo: Reflexión Historia del artículo Recibido: 10-04-2013 Correcciones: 01-05-2013 Aceptado: 15-06-2013 Categories and Subject Descriptors K.3.2 [Computers and Education]: Computer and Information Science Education – Computer science education. General Terms Systems Engineering, Computer Science. Keywords Engineering, Training, Systems engineering, sciences, Computer Science. Palabras clave Ingeniería, Formación, Ingeniería de Sistemas, ciencias, ciencias computacionales.

ABSTRACT The challenges proposed by the development of the new computer systems demand new guidance related to engineer´s education, because they will solve these problems. In the XXI century, system engineers must be able to integrate a number of topics and knowledge disciplines that complement that traditionally has been known as Computer Systems Engineering. We have enough software development engineers, today we need professional engineers for software integration, leaders and system architects that make the most of the technological development for the benefit of society, leaders that integrate sciences to the solutions they build and propose. In this article the current situation of Computer Systems Engineering is analyzed and is presented a theory proposing the need for modifying the approach Universities have given to these careers, to achieve the education of leader engineers according to the needs of this century. RESUMEN Los retos que plantea el desarrollo de los nuevos sistemas exigen una nueva orientación en la formación de los ingenieros, quienes les plantearán soluciones a esos problemas. En el siglo XXI se requiere ingenieros de sistemas que integren una serie de áreas y disciplinas del conocimiento que complementan lo que hasta ahora se conoce como Ingeniería de Sistemas. Ya no se necesitan ingenieros desarrolladores, hoy se requieren profesionales integradores, líderes y arquitectos de sistemas que aprovechen el desarrollo tecnológico para beneficio de la sociedad, que integren las ciencias a las soluciones que plantean y construyen. En este artículo se analiza la situación actual de la Ingeniería de Sistemas y se desarrolla una teoría que plantea la necesidad de modificar el enfoque que las Universidades les dan a estos programas, para formar ingenieros líderes de acuerdo con las necesidades de este siglo.

© 2013 IAI. All rights reserved.

1. INTRODUCCIÓN Desde el nacimiento hasta la muerte el ser humano vive apoyado en un complejo e interconectado conjunto de sistemas: financieros, de asistencia médica, de transporte, de información,… que soportan infraestructuras como las de comunicación, agua, energía, economía,… que esenciales para la supervivencia de una sociedad avanzada [1]. Si bien muchos de estos sistemas son importantes para la supervivencia, no son jurisdicción directa de los ingenieros. Por ejemplo, el ser humano interactúa con uno o más sistemas de educación y a menudo termina interactuando con alguna versión de un sistema de atención en salud, sistemas principalmente sociales que implican cómo una sociedad atiende a sus ciudadanos, que han sido analizados a través del lente de la política y la economía y, en ambos casos, desarrollan conocimientos científicos acerca de cómo funcionan nuestros cuerpos y cómo aprenden nuestras mentes.

De igual manera la sociedad de este siglo interactúa cada vez más con una clase de sistemas que dependen para su existencia de las tecnologías o artefactos tecnológicos, y que son jurisdicción directa de la Ingeniería de Sistemas [2]. Estos sistemas proporcionan gran parte de las funciones de la sociedad moderna, como el control de tráfico aéreo mundial, la Internet, la red de comunicaciones global, el sistema de movilidad nacional ―automóviles, trenes, aviones, carreteras, estaciones y aeropuertos―, entre otros. Sistemas que poseen importantes componentes tecnológicos pero que también realizan importantes interacciones a nivel corporativo y de interfaces socio-técnicas, que determinan el diseño u operación del mismo. Por supuesto, muchos están interconectados y juntos conforman sistemas de sistemas, por ejemplo, el de control de tráfico aéreo, el de comunicaciones y el de movilidad están interconectados entre sí. Dicha interconexión quedó evidenciada con los incidentes del 9/11 en Nueva York, momento en el que se demostró con claridad cómo algunas de las

RACCIS, 3(1), 6-11, 2013

Revista Antioqueña de las Ciencias Computacionales y la Ingeniería de Software

ISSN: 2248-7441

www.fundacioniai.org/raccis raccis@fundacioniai.org

7

infraestructuras críticas en los EE.UU. están conectadas entre sí y cómo los fallos en uno pueden tener efectos inmediatos o a largo plazo sobre los otros. Estos sistemas han sido analizados parcialmente mediante herramientas de investigación de operaciones, de análisis de sistemas y económicas, y fueron diseñados mediante procesos de Ingeniería de Sistemas. Las técnicas de gestión de ingeniería para la creación de muchos de ellos son procesos ad-hoc, y a menudo las políticas que rigen su uso surgen después de la fabricación. Calcular los presupuestos para su realización se considera en gran medida como un arte, por lo que muchos de ellos, principalmente los grandes y complejos, sobrepasan estimaciones y calendarios. Además, algunos tienen consecuencias sociales sorprendentes, como utilizar Internet para la divulgación de correo spam, la interacción entre este uso emergente y el mismo diseño técnico de la Internet [3]. Para satisfacer las demandas de la Sociedad de la Información y el Conocimiento se necesita desarrollar una visión holística de estos sistemas que tenga en cuenta todas las cuestiones asociadas con ellos. Esta visión integradora para sistemas desarrollados tecnológicamente es el campo que le concierne a la Ingeniería de Sistemas de este siglo, y debe ser el núcleo pare el desarrollo profesional de sus ingenieros. En la Universidad moderna, con su amplio y valioso énfasis en la ciencia detrás de la ingeniería, esta visión integradora ha sido descuidada por mucho tiempo, debido a que va más allá de muchas de las demás disciplinas [4]. Por supuesto, esto se debe a que detrás del poder del enfoque de las ciencias ingenieriles se encuentran mentes reduccionistas, combinadas con un poder de manipulación agudo de parte de las matemáticas. Para apreciar completamente esta complejidad los sistemas interconectados requieren una visión que haga el enlace entre los enfoques de la ingeniería tradicional con los puntos de vista de la gestión y las ciencias modernas. Al igual que en todos los modelos, el objetivo final de esta combinación de disciplinas debe ser el de modelar y predecir el comportamiento de los sistemas complejos en un contexto completo. En este trabajo se explora y proyecta un futuro desarrollo para lo que hasta el momento se denomina Ingeniería de Sistemas, contextualizado en las exigencias y problemas de este siglo, que exigen ingenieros líderes que les presenten soluciones. 2. ESTADO ACTUAL DE LA INGENIERÍA DE SISTEMAS La palabra sistemas tiene una connotación bastante amplia. Un sistema es una colección de piezas cuya función colectiva es mayor que la función de las piezas individuales. En la base matemática del mundo riguroso y científico de la ingeniería esta vaguedad ha dado lugar a algunas críticas, debido principalmente a esa amplitud de significado: si sistemas se aplica para todo entonces también se aplica para nada. Con el objetivo de ser específicos este artículo se centra en la Ingeniería de

Sistemas y en los sistemas que posean las siguientes características: Que sean operables tecnológicamente. Que sean de gran escala ―gran número de

interconexiones y componentes―. Que sean complejos. Que sean dinámicos ―con la participación de múltiples

escalas de tiempo e incertidumbre―. Que tengan interacciones sociales y naturales con la

tecnología. Que posean propiedades emergentes. La expresión operable tecnológicamente se aplica a sistemas con uno o más artefactos de tecnología en su base, es decir, los que no existen aparte de los artefactos tecnológicos. Un buen ejemplo es el sistema de control de tráfico aéreo, el cual tiene en su núcleo aviones, radares y aeropuertos. Los sistemas que nos interesa comprender también son importantes en el sentido que tienen gran número de interconexiones. Este mapa puede tener una amplia escala física ―está claro que eso es un sistema de control de tráfico aéreo―, pero no necesariamente tiene que serlo ―así como no se puede atribuir ninguna magnitud física a Internet―, pero tiene un gran número de interconexiones. La descripción de Ingeniería de Sistemas como compleja se entiende desde el punto de vista que tiene propiedades no lineales, en las que las salidas del sistema no están relacionadas directamente con sus entradas. En parte este comportamiento no lineal de los flujos desde múltiples escalas de tiempo es subyacente al sistema, junto con la inocultable presencia de la incertidumbre. Además, también se deriva del hecho de que estos sistemas los conforman importantes piezas y decisiones determinadas por su interacción con el mundo social o natural. Finalmente, se observa que suelen poseer propiedades emergentes, generalmente en cómo la sociedad los utiliza o responde a ellos. Por ejemplo, utilizar Internet para enviar spam no fue en absoluto previsto o entendido cuando se estableció la arquitectura técnica subyacente a la misma [3]; o que el desarrollo de los centros de actividad en los aeropuertos, donde se evidencia el crecimiento de centros comerciales para servir a las personas que tienen que matar el tiempo a la espera de los vuelos de conexión, tampoco fuera considerado al diseñar el sistema de control de tráfico aéreo. Por lo tanto, para comprender la actual Ingeniería de Sistemas se requiere: 1. Una perspectiva tecnológica interdisciplinar que

involucre a las ciencias y otras áreas del conocimiento: Que en el proceso de diseño incorpore propiedades

del sistema, como sostenibilidad, seguridad, calidad y flexibilidad, es decir, propiedades del ciclo de vida en lugar de las de primer uso.

Con perspectiva de empresa. Que tenga en cuenta las diferentes perspectivas de

las partes interesadas.

8

2. Un conjunto de propiedades llamadas no-funcionales, que hacen hincapié en el hecho de que existen consideraciones intelectuales asociadas al uso de los sistemas que pueden ser muy diferentes de los de primer uso, para los que los fueron diseñados y que pueden llegar a dominar el uso de los mismos.

Luego de definir la Ingeniería de Sistemas es necesario explorar el estado actual de la comprensión de los sistemas, en el camino hacia la definición de los atributos que deben poseer los profesionales que los diseñan y operan. La jerarquía de conocimientos con la que es posible explorar esta comprensión se propone representada en niveles: 1. Observación 2. Clasificación 3. Abstracción 4. Cuantificación y medición 5. Representación simbólica 6. Manipulación simbólica 7. Predicción Algunas áreas ingenieriles comenzaron en el nivel 1 y progresaron hasta el nivel 7. Un buen ejemplo de esto es la termodinámica, que se inició con las observaciones a las máquinas de vapor fabricadas mediante un proceso de prueba y error, luego se descubrieron y promulgaron nuevas leyes y finalmente se indujeron las de la termodinámica clásica, lo que le permitió la ingeniería avanzar al nivel 7 con los motores termodinámicos. Esto también permitió darse cuenta de que las tres leyes de la termodinámica sustentaban todas las observaciones previas y permitió la construcción de nuevos tipos de máquinas. Este proceso también es válido para la aerodinámica que al principio, para desarrollar una comprensión del aerodinamismo, se basaba únicamente en la observación de cómo volaban las aves, y que luego, una vez que las leyes de conservación se comprendieron y aplicaron a los gases compresibles, se originó el conocimiento moderno de la aerodinámica. Por supuesto actualmente se encuentra en el nivel de predicción, que se manifiesta por la facilidad con que se diseña las aeronaves de forma que puedan volar adecuadamente. Ahora bien, muchos de los temas acerca de los modernos aviones comerciales generalmente no son aerodinámicos, como el proceso de fabricación y el costo-eficiencia del ciclo de vida. De acuerdo con la definición descrita previamente, el estado actual de la Ingeniería de Sistemas se encuentra entre los niveles 2 y 4, porque algunos de los sistemas han sido abstraídos, medidos y cuantificados. Como el desarrollo de cualquier campo ingenieril, su objetivo es ascender en la jerarquía del conocimiento hasta el punto en que pueda predecir el comportamiento de los sistemas más complejos. Será entonces cuando estos sistemas se construyan con una perspectiva holística, pero con un buen conocimiento de los probables beneficios, costos y consecuencias del producto terminado. Esto les permitirá

a los ingenieros desarrollarlos dentro del presupuesto, entregarlos a tiempo y con el rendimiento esperado por los usuarios. 3. BASES DISCIPLINARES DE LA INGENIERÍA DE

SISTEMAS DE ESTE SIGLO 3.1 Fundamentos intelectuales El desarrollo de cualquier campo multidisciplinar requiere de los avances en las disciplinas que lo sustentan. Por ejemplo, el progreso en la ingeniería de energía de fusión requirió de los avances de la física del plasma. Sin embargo, aunque comprender la física del plasma es fundamental para diseñar un reactor de fusión, no es suficiente porque no incluye la totalidad de las cuestiones necesarias para hacer funcionar un reactor real. En la práctica el proceso de diseñar y operar un reactor requiere de la unión mancomunada entre la física del plasma, la ingeniería nuclear y la ingeniería de materiales con el análisis de riesgos. De manera similar existe una serie de disciplinas subyacentes para comprender el diseño y la operación de la Ingeniería de Sistemas real, por lo que las Universidades deben formar a sus futuros ingenieros mediante procesos formativos interdisciplinares. Esto facilitaría una mayor comprensión y progreso de esta ingeniería, a la vez que avanza en los niveles de la jerarquía de conocimientos. Las disciplinas subyacentes necesarias planteadas en este trabajo son: 1) arquitectura de sistemas y desarrollo de productos, 2) investigación de operaciones y análisis de sistemas, 3) el área administrativa y 4) las tecnologías y políticas necesarias [2]. 3.2 Arquitectura de sistemas y desarrollo de

productos Estas disciplinas describen un conjunto de procesos ordenados mediante un diseño que linealmente llevan al producto desde la elicitación de requisitos hasta su manifestación específica en un entregable. La arquitectura de sistemas describe procesos completos mediante conceptos que desarrollan mapas de las funciones deseadas y de las posibles formas que toman, y en ellas es donde el producto experimenta el proceso ingenieril. Si bien el desarrollo de la Ingeniería de Sistemas estructurada en árboles y en capas ha experimentado un considerable desarrollo, no se puede decir lo mismo de la arquitectura de sistemas, porque todavía se considera un arte mediante el cual los arquitectos tratan de llegar a consensos acerca de los conceptos que satisfacen las necesidades del cliente. Gran parte del desarrollo intelectual que estos arquitectos necesitan proviene de la cuantificación y manipulación de las arquitecturas de los sistemas, algo que Crawley et al. [5] discuten en su trabajo. 3.3 Investigación de operaciones y análisis de

sistemas La investigación de operaciones desarrolla en gran medida la teoría de optimización para diferentes tipos de funciones de costo. En el mismo sentido se desarrollaron diversas técnicas para analizar el comportamiento de los

9

sistemas una vez que se reducen a redes cuantificables. A través de esta área se desarrolla una comprensión de la naturaleza de optimización, en la que son importantes cuestiones como el ciclo de vida del producto y la cuantificación de la flexibilidad. En esto existe un desarrollo significativo que se puede aplicar mediante técnicas financieras para valorar la flexibilidad, temática que Neufville [6] analiza en su trabajo. Por otro lado, el análisis de sistemas desarrolla técnicas macroscópicas de dinámica de sistemas [7] como método para modelar muchos productos de la Ingeniería de Sistemas, porque a pesar de que abarcan diversos puntos de vista, a menudo se reducen a comprender la relación de los coeficientes con las existencias y los flujos. El modelado basado en agentes es una metodología de análisis reciente en la que los sistemas se modelan a un nivel más elemental, y con una serie de reglas simples se construye un conjunto complejo de interacciones. El desarrollo de técnicas de análisis para la Ingeniería de Sistemas requiere la integración de las técnicas de modelado para formar una paleta operacional para el analista. Estas temáticas se amplían suficientemente en el trabajo de Carloni et tal. [8]. 3.4 Área administrativa Los sistemas de ingeniería reales se construyen al interior de las empresas y operan al interior de la sociedad, por lo que la interacción entre la empresa de diseño y la Ingeniería de Sistemas es profunda. Si bien los teóricos organizacionales desarrollan teorías acerca de cómo funcionan las organizaciones y la toma de decisiones, este conocimiento necesita integrarse en la fase de diseño de los productos de forma que se pueda cuantificar. Entonces se podría conocer a priori el efecto de la organización empresarial en el sistema de ingeniería y no esperar a que sea una sorpresa, como lo plantea el U.S. Department of Commerce [9]. 3.5 Tecnologías y políticas Las interacciones socio-técnicas significativas son una propiedad de los sistemas a gran escala, a la vez que de mucho interés para la Ingeniería de Sistemas. Frecuentemente, estas interacciones se observan después que se diseñan los sistemas y que se han invertido considerables recursos. El análisis concienzudo de estas interacciones hace parte del quehacer de los politólogos y los sociólogos y, como desarrollos de la Ingeniería de Sistemas, se modelan de forma que sean cuantificables y que se puedan incluir en el análisis de los sistemas complejos. Varios modelos de este tipo se pueden encontrar en el trabajo de Cutcher-Gershenfeld et al. [10]. 4. EL FUTURO DE LA INGENIERÍA DE SISTEMAS Para que la Ingeniería de Sistemas avance en la jerarquía de conocimiento hasta alcanzar el nivel 7 se tendrá que formalizar la interdisciplinariedad de las cuatro áreas subyacentes que se proponen en este trabajo, o al menos llevarla a una simulación computacional aplicable en diferentes ámbitos de la Ingeniería de Sistemas. Esto ayudará a: 1) descubrir principios generalizables y cuantificables que vayan más allá del nivel heurístico y 2)

desarrollar métodos aplicables en los diferentes ámbitos de esta ingeniería. Los principios serán similares a las leyes de conservación en la mecánica de fluidos y los métodos se podrán cuantificar en simulaciones computacionales para modelar los sistemas complejos. Una vez que se comprendan estos principios y métodos, se podrá estructurar arquitecturas y diseños en Ingeniería de Sistemas que tengan en cuenta los requisitos y los usos futuros parcialmente desconocidos; además, se diseñarán de manera predictiva en los sistemas los usos incorporados a través de los requisitos no-funcionales. Entonces se diseñarán sistemas de forma que se pueda demostrar la incorporación de propiedades como seguro y seguridad, con cuestiones de sostenibilidad y flexibilidad incorporadas en la formulación original del problema, y con la posibilidad de predecir cuantitativamente el grado en que estas propiedades están presentes en los sistemas. Alcanzar la realización de estas propiedades necesitará reunir conceptos como economía, teoría de juegos, teoría de la complejidad, teoría de grafos y teoría de opciones reales, junto con la arquitectura de sistemas y la optimización multidisciplinar, que se deben combinar con poderosas simulaciones por computador para modelarlos y predecirlos. Una cuestión de fondo es si la dimensión humana de la Ingeniería de Sistemas se podrá incluir plenamente alguna vez en la predicción cuantitativa de los sistemas. Aunque el análisis de decisiones y la teoría de juegos permiten la inclusión de muchos aspectos humanos, estos métodos tienen limitaciones conocidas. La dinámica de sistemas utiliza bucles de retroalimentación para ver con claridad los sistemas, aunque en principio los modelos basados en agentes permiten simulaciones a gran escala desde un nivel elemental. La cuestión de que estos métodos permitan o no la interacción de actividades humanas en los sistemas técnicos es una cuestión discutible. Cuando la Ingeniería de Sistemas se desarrolle complemente como un área científica a través de los niveles de la jerarquía de conocimiento, será posible predecir dos consecuencias importantes: 1) los estudiantes de pregrado se formarán en ciencias ingenieriles, como lo hacen actualmente, pero también se les dará una apreciación del contexto de Ingeniería de Sistemas en el que ejercerán como ingenieros, sobre todo en aspectos sociales y de los desarrollos tecnológicos de punta y 2) a nivel de posgrado se desarrollarán maestrías y doctorados en los diferentes aspectos interdisciplinares de la ingeniería. El desarrollo de este campo de formación se utilizará para predecir el desarrollo de nuevos tipos de sistemas y para predecir cómo diseñarlos y cómo se comportarán. 4.1 Nuevos profesionales en Ingeniería de Sistemas Luego que en las Universidades y en la educación superior se desarrolle esta comprensión de la Ingeniería de Sistemas podrá surgir un nuevo tipo de ingeniero: un

10

profesional líder [10]. Serán líderes capacitados para integrar los componentes tecnológicos y sociales como parte de los sistemas grandes y complejos, y utilizarán los nuevos y diferentes enfoques con base en el paradigma de la ciencia de la ingeniería tradicional. Estos profesionales examinarán como una variable de diseño al contexto en el que el sistema operará y no como una restricción. Por lo tanto, tendrán en cuenta el diseño organizacional sobre el que operará el producto; los reglamentos y políticas públicas que regularán su uso y disposición; la comercialización y la relación con proveedores, distribuidores y otros participantes en la cadena de valor. Desde esta perspectiva el proceso de diseño incluirá los atributos físicos del dominio de la ingeniería tradicional; los atributos del proceso del dominio de los ingenieros y de los administradores, y los atributos de contexto que tradicionalmente han sido del dominio de los administradores, los gobiernos y las área sociales. Como tal, serán útiles en la sociedad y en la academia de este siglo para desarrollar un enfoque interdisciplinar en el diseño de las soluciones a los problemas, y considerarán el contexto en que los sistemas se inician, se diseñan, se fabrican, se construyen, se aplican y se mantienen. Este contexto estará sometido a cambios significativos como resultado de la globalización, la revolución de la información y las necesidades sociales emergentes ─particularmente la sostenibilidad─. Esta perspectiva se refleja en cuestiones como que los avances de la humanidad dependerán cada vez más de nuevos planteamientos integradores a los sistemas complejos, los problemas y las estructuras, y que la síntesis de diseño y la sinergia entre las fronteras disciplinares tradicionales serán elementos esenciales de la educación superior y la investigación en las universidades de este siglo [11]. Como ingenieros de sistemas serán importantes para el futuro desarrollo de la academia, donde ayudarán a los estudiantes a lograr la perspectiva holística necesaria para convertirse en ingenieros y líderes productivos para la sociedad de este siglo. Una vez estos estudiantes se gradúen, no serán diferentes de aquellos profesionales que se forman en otras áreas, como la medicina y la física, sino que además ayudarán a orientar a la sociedad de manera técnicamente competente y con conciencia social. Ese nuevo tipo de maestros en Ingeniería de Sistemas llevará a cabo un proceso riguroso de integración e impulsará la ciencia tradicional, orientando a la Universidad a pensar con mayor amplitud acerca de la naturaleza de la nueva ingeniería, que los desarrollos tecnológicos y sociales reclaman para este siglo. Las facultades de Ingeniería y los estudiantes les ayudarán a la educación superior a abordar de mejor manera las cuestiones enmarcadas por Kennedy [12], que en el capítulo final se pregunta si las universidades realmente pueden hacer una diferencia con respecto a los grandes problemas que tenemos ante nosotros. Su lista de desafíos va desde la proliferación de armas y el desarme hasta cuestiones éticas en las pruebas genéticas y en el asesoramiento sin incentivos en los sistemas de atención

en salud. Los intelectuales que deseen trabajar en estos desafíos puede que reciban el menosprecio de la academia, porque, como afirma el autor, la Universidad tradicional desprecia estos problemas por considerarlos de poca aplicación y, en parte, por la percepción común de que problemas multidisciplinares como éstos hacen parte de las llamadas ciencias blandas. Sin embargo, son reales, complejos y de gran escala, y requieren la atención de los intelectuales reflexivos. Kennedy se pregunta si la academia podrá superar la resistencia de las estructuras tradicionales para rediseñarse así misma frente a estos desafíos. Parte de la respuesta a esta pregunta está en la propuesta descrita en este trabajo para formar líderes que puedan operar con la interfaz entre tecnología y sociedad, con una visión integradora de los sistemas y con la capacidad de predecir su futuro comportamiento. Esos profesionales le ayudarán a la educación superior a vencer lo que Snow [13] llamó el mundo de las dos culturas, y será la Universidad el lugar en el que estos líderes prosperarán y en el que sus estudiantes podrán ser formados. Pero las administraciones educativas no podrán ser las de siempre, porque una Universidad dividida por estrechas líneas disciplinares y con desdén por el trabajo multidisciplinario no lo logrará. La academia debe cambiar la forma en que piensa sobre los medios, los fines y la finalidad de su propia innovación. Es necesario que prevea las implicaciones de los nuevos sistemas emergentes, y que se enfrente y solucione los problemas que los retos y oportunidades de este siglo le plantea. La Universidad de este siglo necesita posicionarse estratégicamente si desea formar al tipo de líderes que la Sociedad de la Información y el Conocimiento necesita para enfrentar esos retos. Una forma de lograrlo es asumir una perspectiva ampliada de la ingeniería, desde la que se derive el progreso de la Ingeniería de Sistemas y la lleve hasta una perspectiva multidisciplinar, clave para los futuros líderes en los sistemas emergentes y para las cuestiones importantes que tenderán el puente que se requiere para superar la brecha entre las mencionadas dos culturas. 5. CONCLUSIONES Las cuestiones sociales y la división cultural que se ha creado y perpetuado desde los Sistema Educativos se centran en dos polos: 1) la ciencia y 2) las artes. Pero el ritmo acelerado del desarrollo tecnológico de este siglo demanda también un cambio en la educación superior y exige un nuevo tipo de profesional en ingeniería como producto de esa nueva y ampliada visión. De esta forma la Universidad podrá graduar ingenieros líderes con las características necesarias para este siglo: 1. Calificados intelectualmente para hacer frente a las

dimensiones cruciales de esta sociedad tecnológica. 2. Con orientación hacia resultados prácticos. 3. Con el coraje basado en la experiencia propia para

asumir los problemas más difíciles. 4. Con capacidad de liderazgo para hacer que otros

avancen en la misma línea.

11

Al hacerlo ayudarán a mejorar la respuesta de la sociedad a los cambios tecnológicos que la conducen y transforman. Si la academia no se transforma el statu quo prevalecerá y la Ingeniería de Sistemas no avanzará en los niveles de la jerarquía de conocimiento hasta la predicción, y dejará de ser la base sobre la que funcionará el motor que conducirá la sociedad hacia el nuevo mundo. El desarrollo y actualización académica para formar ingenieros líderes es una de las formas como esta ingeniería responderá a las necesidades sociales y como la educación superior y las Universidades formarán profesionales en ingeniería que sienten las bases para un mejor el futuro socio-tecnológico. 6. REFERENCIAS [1] Serna, M.E. (2010). Sistemas de Información y Sociedad del

Conocimiento. Textos y Argumentos, No. 17. [2] Serna, M.E. (2009). La ingeniería de sistemas y su

evolución hacia la arquitectura de sistemas. Lámpsakos, 2, pp. 96-105.

[3] Serna, M.E. (2008). Cómo no naufragar en la Internet. Cátedra abierta Facultad de Administración. Universidad de Antioquia. Colombia.

[4] Serna, M.E. (2009). El modelo pedagógico en la educación superior: Reto para un mundo globalizado. Revista Acierto, 4, pp. 23-37.

[5] Crawley, E. et al. (2004). The Influence of Architecture in Engineering Systems. Engineering systems Monograph. The ESD Architecture Committee, MIT.

[6] Nuefville, R. (2004). Uncertainty Management for Engineering Systems Planning and Design. Engineering systems Monograph. The ESD Architecture Committee, MIT.

[7] Sterman, J. D. (2000). Business Dynamics: Systems Thinking and Modeling for a Complex World. USA: McGraw-Hill/Irwin.

[8] Carloni, L. et al. (2004). Modeling Techniques, Programming Languages, Design Toolsets and Interchange Formats for Hybrid Systems. Project IST-2001-38314 Columbus School. USA, Columbus.

[9] U.S. Department of Commerce. (1999). Strategic planning for economic development: Moving beyond the overall economic development program. Corporation for Enterprise Development.

[10] Cutcher-Gershenfeld, J. et al (2004). Sustainability as an Organizing Design Principle for Large-Scale Engineering Systems. Engineering systems Monograph. The ESD Architecture Committee, MIT.

[11] Hastings, D. (2004). The Development of Leaders who are Engineers. MIT Engineering Systems Division.

[12] Kennedy, D. (1997). Academic Duty. Cambridge: Harvard University Press.

[13] Snow, C.P. (1993). The Two Cultures. USA, Cambridge University Press.

12

What is that Thing Called Computer Science?

¿Qué es esa Cosa Llamada Ciencias Computacionales?

Nadya Schokosva1, Irina Buskova2 Software Engineering Institute. 1Nadya.s(AT)softute.ro; 2Irina.b(AT)softute.ro

INFORMACIÓN DEL ARTÍCULO Tipo de artículo: Reflexión Historia del artículo Recibido: 10-01-2013 Correcciones: 15-04-2013 Aceptado: 20-04-2013 Categories and Subject Descriptors K.3.2 [Computers and Education]: Computer and Information Science Education – Computer science education. General Terms Computer Science, Computing, Algorithms. Keywords Computer Science, Software Engineering, Computer Engineering, computational scientists. Palabras clave Ciencias Computacionales, Ingeniería de Software, Ingeniería Informática, científicos computacionales.

ABSTRACT XXI century society, called Knowledge Society, has a direct dependency of the software products, considered by many as the most important development of modern technology. This dependence generates the need of scientists and professionals who research and develop products that meet social demands. This article describes the computer science area as one of the most demanded professions in this reality, and in order to make it known to more people. RESUMEN La sociedad del siglo XXI, llamada Sociedad del Conocimiento, tiene una dependencia directa de los productos software, considerados por muchos como el desarrollo más importante de la tecnología moderna. Esa dependencia genera la necesidad de que científicos y profesionales investiguen y desarrollen productos que satisfagan las demandas sociales. En este artículo se describe el área de las Ciencias Computacionales como una de las profesiones más demandadas en esta realidad, y con el objetivo de darla a conocer a un mayor número de personas.

© 2013 IAI. All rights reserved.

1. INTRODUCCIÓN En los 30, Turing y Church desarrollaron los principios matemáticos fundamentales de la computación. Los principios computacionales implementados en la década de 1940 por von Neumann, Wilkes, Eckert, Atanasoff y otros, dieron lugar al nacimiento de la computación científica y comercial en los años 50, lo mismo que de lenguajes de programación matemática como Fortran, comerciales como COBOL, y de Inteligencia Artificial como LISP. En los 60, el rápido desarrollo y la consolidación de la algoritmia, las estructuras de datos, las bases de datos y los sistemas operativos formaron el núcleo de lo que hoy se conoce como Ciencias Computacionales tradicionales, y en los 70 surgió la Ingeniería de Software, la programación estructurada y la orientada por objetos. La aparición en los 80 de la computación personal y las redes, preparó el escenario para el progreso del paralelismo, la graficación computacional y la tecnología del software. En los 90 apareció la Internet como un

medio para el intercambio académico y científico, y como un vehículo para el comercio y la comunicación internacional [1]. Las Ciencias Computacionales entonces se consolidaron como el estudio de los procesos computacionales y las estructuras de la información, incluyendo sus realizaciones hardware y modelos lingüísticos, y sus aplicaciones [2]. Por otro lado, el uso rápido y generalizado de los computadores y de las tecnologías de la información ha generado una necesidad de trabajadores altamente cualificados con dominio en diversas áreas de trabajo. Estos especialistas en informática son los científicos computacionales y los analistas de sistemas. Las áreas de trabajo y los títulos ocupacionales utilizados para describirlos evolucionan rápida y continuamente, reflejando nuevas áreas de especialización o cambios en la tecnología, así como las preferencias y prácticas de los empleadores.

RACCIS, 3(1), 12-18, 2013

Revista Antioqueña de las

Ciencias Computacionales y la Ingeniería de Software

ISSN: 2248-7441

www.fundacioniai.org/raccis

raccis@fundacioniai.org

13

Los científicos computacionales se desempeñan como teóricos, investigadores o inventores. Su trabajo se caracteriza por un mayor nivel de conocimientos teóricos y de innovación, el cual aplican a problemas complejos y a crear o aplicar nuevas tecnologías. Las áreas de investigación de las Ciencias Computacionales (CC) van desde las teorías complejas para diseñar hardware hasta el diseño de lenguajes de programación. Algunos investigadores trabajan en proyectos multidisciplinares, como el desarrollo y el uso avanzado de la realidad virtual, extendiendo la interacción persona-computador, o el diseño de robots. Pueden trabajar en equipos de diseño con ingenieros eléctricos, ingenieros de software y otros especialistas. Además, los investigadores en Ciencias Computacionales empleados en las instituciones académicas desempeñan funciones similares en muchos aspectos a las empleadas en otras organizaciones. En general, tienen más flexibilidad para centrarse en la teoría pura, mientras que los que trabajan en otras organizaciones por lo general se centran en proyectos que tienen la posibilidad de generar patentes y beneficios. Sin embargo, algunos en entornos no académicos tienen una considerable libertad para determinar el rumbo de su investigación [3]. Con la Internet y el comercio electrónico se generan grandes volúmenes de datos, y existe una creciente necesidad de almacenarlos, gestionarlos y extraerlos de manera eficaz. Los administradores de bases de datos trabajan con software de sistemas de gestión de base de datos y determinan maneras de organizar y almacenar esos datos. Identifican las necesidades del usuario y diseñan nuevas bases de datos informáticas. En muchos casos, estos administradores deben integrar los datos de los sistemas obsoletos en un nuevo sistema; también prueban y coordinan las modificaciones en el sistema cuando sea necesario y resuelven los problemas cuando ocurren. Estos profesionales aseguran el rendimiento del sistema, comprenden la plataforma en la que se ejecuta la base de datos, y añaden nuevos usuarios al sistema. Debido a que muchas bases de datos están conectadas a Internet, también deben planificar y coordinar las medidas de seguridad con los administradores de la red. Con el creciente volumen de datos sensibles, el aumento en la interconexión de las redes de computadores, la integridad de datos y los sistemas de resguardo, la seguridad de las base de datos se han convertido cada vez más en un aspecto importante de la labor de estos administradores [3]. Los analistas de sistemas, también conocidos como arquitectos de sistemas, diseñan, prueban, evalúan e integran sistemas, como las redes de área local (LAN) y de área amplia (WAN), Internet, intranets y otros sistemas de comunicación y de tratamiento de datos. Los sistemas actuales están configurados de muchas maneras y pueden ir desde una conexión entre dos oficinas en el mismo edificio hasta redes distribuidas globalmente, correo de voz y sistemas de correo electrónico de una organización multinacional. Los arquitectos realizan el modelado, el análisis y la planificación de las redes, que a menudo requieren tanto soluciones de hardware como de

software. Por ejemplo, una red puede implicar la instalación de varios componentes hardware, como routers y concentradores, adaptadores inalámbricos y cables, al mismo tiempo que la instalación y configuración del software respectivo, como los controladores de red y la integración al sistema de información de la organización. Los analistas también pueden investigar los productos y hacer recomendaciones en el hardware y el software necesarios [3]. En el resto de este artículo se presenta una descripción detallada del área de conocimiento y de trabajo de las Ciencias Computacionales. El objetivo es ofrecer la mayor información posible acerca de esta área del conocimiento, considerada como la base para el desarrollo de otras dependientes como las ya mencionadas bases de datos y arquitectura de sistemas, y de otras de gran importancia como la Ingeniería de Software. Con la información que aquí se presenta será posible que los interesados en alguna de ellas puedan comprenderlas mejor y para que los estudiantes tengan mejores bases para tomar la decisión de estudiar Ciencias Computacionales.

2. FORMACIÓN Los Científicos Computacionales deben ser creativos, inquisitivos, analíticos y orientados al detalle. Deben tener buenos conocimientos en matemáticas, incluyendo cálculo, probabilística y estadística, y de sistemas informáticos. También es necesaria la adecuada preparación en una o más de las ciencias básicas, como física, química, o biología. Es importante que posean habilidades para trabajar en equipo y para comunicarse tanto verbal como por escrito, porque el trabajo en esta área con frecuencia requiere la interacción con especialistas por fuera de la informática o la ingeniería. Para perfeccionar estas habilidades se recomienda dominar una segunda lengua, básicamente inglés, ser un buen lector y escritor, y desarrollar su capacidad como ser humano social [4]. 2.1 Ciencias Computacionales vs Ingeniería

Informática vs Ciencias de la Información Muchos programas de pregrado de cuatro y cinco años en Ciencias Computacionales e Ingeniería Informática están acreditados por el Accreditation Board for Engineering and Technology (ABET), y normalmente están adscritos a las escuelas de ingeniería. En algunos casos, como por ejemplo en el MIT y en Berkeley, los títulos se ofrecen en el Departamento de Ingeniería Eléctrica y Ciencias Computacionales. Otra característica común es que existe una considerable superposición en los pregrados de Ingeniería Informática y Ciencias Computacionales. La principal diferencia entre ellos es que el primero requiere un componente de diseño para ingeniería [5]. Los pregrado en Ciencias de la Información están diseñados para preparar a los estudiantes en la aplicación de los computadores en los negocios. Por lo tanto, generalmente residen en las escuelas de negocios y no están acreditados por ABET, aunque existen algunos programas acreditados que se ofrecen en escuelas de ingeniería. Además de los cursos en programación,

14

organización y operación de computadores, redes y bases de datos, estos programas requieren cursos en negocios y administración, y una menor cantidad de cursos en matemáticas y ciencias que los necesarios en Ciencias Computacionales e Ingeniería Informática. 2.2 Cursos de Estudio En un programa típico de cuatro años y con semestres de 120 horas, los estudiantes de Ciencias Computacionales asisten a 40 horas semestrales en temas propios del área, a 30 horas en temas de matemáticas ―matemáticas discretas, cálculo diferencial e integral y probabilística y estadísticas― y de ciencia, que deben incluir trabajo de laboratorio. En esas horas recibirán formación en lógica, abstracción, algoritmia, estructuras de datos, diseño de software, conceptos de lenguajes de programación y organización y arquitectura de computadores. Además, fundamentos teóricos, análisis y resolución de problemas y diseño de soluciones. Estarán expuestos a una variedad de lenguajes y sistemas de programación ―generalmente como trabajo independiente―, y deben ser competentes en al menos un lenguaje de alto nivel y en métodos formales. Desarrollarán habilidades de comunicación verbal y escrita y recibirán formación general en humanidades y en áreas sociales y artes. 2.3 Formación continua En el campo de la computación los avances tecnológicos vienen tan rápidamente que es necesaria la formación continua, luego de la graduación, para mantener las habilidades adquiridas. Los empleadores, los proveedores de hardware y de software, las asociaciones, las universidades y las instituciones privadas ofrecen este tipo de formación. El entrenamiento adicional también puede provenir de seminarios profesionales ofrecidos por las sociedades en informática. 2.4 Programas acreditados Los interesados en carreras en Ciencias Computacionales deben considerar la revisión de los programas que están acreditados por ABET. Esta acreditación se basa en una evaluación al rendimiento de los estudiantes del programa, al mejoramiento del programa, el profesorado, los contenidos curriculares, las instalaciones, y el compromiso institucional. En cada país que ofrecen pregrados en esta área del conocimiento tienen otros estándares para acreditar los programas, pero en términos generales deben apuntar a que cada día se ofrezca mejores profesionales a la sociedad. 3. ÁREAS DE ESPECIALIDAD La mayoría de Científicos Computacionales se clasifican por sus áreas de interés. La siguiente es una lista de las áreas de especialidad dentro de las CC: Algoritmos y Teoría Inteligencia Artificial Arquitectura y Computación Paralela Bioinformática y Biología Computacional Bases de Datos y Sistemas de Información Gráficos, Visualización e Interfaces Hombre-

Computador

Sistemas Distribuidos y Redes Lenguajes de programación Sistemas y Métodos Formales Ingeniería de Software Computación Científica Teoría Computacional 3.1 Algoritmos y Teoría La investigación en esta área se centra en el diseño y análisis de algoritmos y estructuras de datos para los problemas que surgen en diversas áreas de las Ciencias Computacionales, incluidas la Verificación automática de software, la geometría computacional, la minería de datos y el aprendizaje automático. 3.2 Inteligencia Artificial Esta área de especialización se centra en una amplia gama de temas que incluyen la representación del conocimiento, el aprendizaje, la visión, el razonamiento, la robótica, los sistemas de información y la planificación. Las áreas de aplicación incluyen a la biología molecular, la manufactura, la teoría de control y la codificación. 3.3 Arquitectura y Computación Paralela El área de arquitectura se centra especialmente en desarrollar arquitecturas, diseñar hardware, lenguajes de programación y sus compiladores, para computadores de última generación y componentes informáticos. En computación paralela se trabaja en proyectos de diversos tamaños y se investiga los aspectos del software computacional en computadores con multi-procesadores. 3.4 Bioinformática y Biología Computacional La investigación en esta área incluye el desarrollo de algoritmos eficientes y escalables para la simulación biomolecular y la aplicación de la minería de datos, el aprendizaje estadístico automático, el procesamiento del lenguaje natural y la recuperación de información para analizar y extraer todo tipo de datos biológicos, incluyendo secuencias de ADN, secuencias y estructuras de proteínas, micro-arreglos de datos y literatura de biología, con el propósito de facilitar los descubrimientos. 3.5 Bases de Datos y Sistemas de Información Los científicos que trabajan en esta área llevan a cabo investigación de vanguardia en bases de datos, minería de datos, minería web, recuperación de información y procesamiento del lenguaje natural. Los enfoques actuales podrían incluir la integración de datos, la exploración y la integración de la "Web profunda", la seguridad, los flujos de minería de datos y los datos secuenciales y semi-estructurados, el soporte a los sistemas operativos para los sistemas de almacenamiento, recuperación de textos, bioinformática, soporte para bases de datos para la computación de alto rendimiento y el procesamiento de consultas top-k. 3.6 Gráficos, Visualización e Interfaces Hombre-

Computador La investigación en gráficos y visualización incluye el modelado y la animación de los fenómenos naturales, la topología computacional, la utilización de hardware de

15

gráficos, renderización basada en imágenes, superficies implícitas, procesamiento y simplificación de mallas, procesos de modelado y texturización, modelado de formas, parametrización de superficies y procesamiento de la visibilidad. La investigación en interfaces hombre-computador involucra herramientas de interfaz de usuario que apoyan mejor las primeras tareas de diseño, es decir, sistemas y ambientes que les ayudan a los usuarios a mantener el conocimiento de la información, herramientas para la creación y el diseño multimedia, interfaces que fomentan la interacción social y en general la interacción humano-computador. 3.7 Sistemas Distribuidos y Redes La investigación en el grupo de Redes y Sistemas Distribuidos incluye una amplia gama de temas, entre los que se encuentran los sistemas móviles, los protocolos inalámbricos, las redes ad-hoc, la gestión de la calidad del servicio, las redes multimedia, las redes peer-to-peer, el enrutamiento, las simulaciones de red, la gestión de cola activa y las redes de sensores. El área de los Sistemas Operativos se centra en la gestión de recursos distribuidos, la gestión de los entornos de computación ubicua, middleware reflexivo, sistemas meta-operativos middleware, diseño de sistemas operativos orientados por objetos, interfaces que les permitan a los usuarios individuales interactuar con múltiples computadores, servicios para sistemas operativos peer-to-peer, sistemas de archivos distribuidos en contextos sensitivos, gestión de energía para centros de datos, sistemas de almacenamiento de archivos, computación autonómica, sistemas de soporte para software robusto, y sistemas de soporte para bases de datos. La investigación en seguridad incluye arquitecturas de seguridad dinámica, seguridad para redes activas, privacidad, autenticación, autorización, control de acceso, confianza en entornos de computación ubicua para usuarios móviles, autenticación en redes de sensores, especificación y validación de las políticas de control de acceso de seguridad, simulación de problemas de seguridad en redes y sus soluciones incluyendo la denegación de servicio, y la próxima generación de seguridad telefónica. En Sistemas de tiempo real y Embebidos las áreas de investigación incluyen sistemas en tiempo real QoS conducidos por protocolos de programación y de comunicación, diseño integrado de controladores y planificadores en tiempo real, integración en tiempo real, protocolos de tolerancia a fallos y de seguridad y dinámica y arquitectura en tiempo real para dispositivos de red y espacios inteligentes. 3.8 Lenguajes de Programación, Sistemas y Métodos

Formales Los científicos que trabajan en esta área estudian e investigan el diseño y la implementación de lenguajes de programación, con el objetivo de mejorar tanto la productividad del desarrollador como la calidad del programa. Los temas van desde las teorías abstractas de los lenguajes de programación hasta las cuestiones prácticas acerca del uso y la implementación de lenguajes de alto nivel. La investigación en Métodos Formales

incluye áreas como especificación formal, lenguajes formales, matemáticas computacionales, lenguajes de especificación formal, Verificación.

3.9 Ingeniería de Software El software es el desarrollo tecnológico de mayor impacto en la actual Sociedad del Conocimiento y como tal se deben realizar procesos de investigación en Ingeniería de Software para mejorar la calidad de sus productos. Las áreas de investigación en este campo cubren temas como Ingeniería de Requisitos, pruebas del software, automatización de las pruebas, Verificación y Validación, integración de sistemas, formalización, simulación y lógica y abstracción.

3.10 Computación Científica Las personas que trabajan en esta área conducen investigaciones en desarrollo y análisis de técnicas numéricas para aproximar los modelos matemáticos de sistemas físicos y algoritmos a la resolución de las ecuaciones resultantes en los sistemas informáticos de alto rendimiento. Las aplicaciones científicas y de ingeniería específicas consideradas incluyen: dinámicas de biología molecular, ciencias de los materiales, simulación de semiconductores, astrofísica y diseño de cohetes de combustible sólido.

3.11 Teoría Computacional En las Ciencias Computacionales teóricas y las matemáticas, la teoría computacional es la rama que se ocupa de y cómo resolver problemas de manera eficiente en un modelo computacional, utilizando la algoritmia. Actualmente existen varios modelos pero el más examinado es la máquina de Turing, porque es fácil de formular, puede ser analizado y utilizado para demostrar resultados, y porque representa lo que muchos consideran el más poderoso y posible modelo "razonable" de la computación. El campo de la Teoría Computacional se divide en tres ramas principales [6]: 1) teoría de autómatas, 2) teoría de la computabilidad y 3) teoría de la complejidad computacional (Ver la Figura 1).

4. HABILIDADES Y DESTREZAS Los Científicos Computacionales deben ser capaces de pensar lógicamente y tener buenas habilidades comunicativas, además de desarrollar una capacidad lógico-interpretativa y abstractiva que les permita comprender los problemas antes de analizarlos y solucionarlos. Debido a que a menudo se enfrentan con una serie de tareas simultáneas, es importante que posean capacidad de concentración, de observación y prestar mucha atención a los detalles. Para lograrlo deben poseer conocimientos sólidos en matemáticas y ciencias básicas, ser buenos oradores y tener vocación por escribir y hablar en público, porque parte de su trabajo consiste en publicar resultados y exponerlos ante la comunidad científica internacional. Los Científicos Computacionales Teóricos proponen teorías y demuestran o desmienten hipótesis, y los resultados los comunican a las diferentes comunidades relacionadas, mientras que los Experimentales se orientan a demostrar teorías o simular las demostraciones propuestas por los primeros [4].

16

Figura 1. Relación entre la Teoría Computacional, la Teoría de la Complejidad y la Teoría de los Lenguajes Formales [6]

Por su propia naturaleza, las Ciencias Computacionales es una disciplina multifacética que se puede ver a partir de por lo menos cuatro perspectivas diferentes. Tres de ellas, la teoría, la abstracción y el diseño subrayan la idea de que los científicos computacionales en todas las áreas pueden enfocar su trabajo desde diferentes puntos de vista y objetivos intelectuales, mientras que en la cuarta, el contexto social y profesional, se reconoce que las aplicaciones de estas ciencias afectan directamente la calidad de vida de las personas, de modo que los científicos deben comprender y confrontar los problemas sociales con los que su trabajo se tropieza exclusiva y regularmente. 4.1 Teoría La Teoría de las Ciencias Computacionales se basa en los principios de las matemáticas y de los métodos formales de las ciencias físicas, biológicas y de comportamiento y de las áreas sociales. Normalmente se requiere aplicar las ideas abstractas y los métodos tomados de sub-campos de las matemáticas, como la lógica, el álgebra, el análisis y la estadística. También incluye el uso de diversas técnicas de prueba y argumentación, como la inducción y la contradicción, para establecer propiedades de los sistemas formales que justifican y explican lo que subyace a los algoritmos básicos y a las estructuras de datos utilizados en los modelos computacionales. Los ejemplos incluyen el estudio de los problemas sin solución algorítmica y el estudio de los límites superior e inferior de la complejidad de diversas clases de problemas algorítmicos.

4.2 Abstracción La abstracción en las Ciencias Computacionales incluye el uso de la investigación científica, el modelado y la experimentación para probar la validez de las hipótesis sobre los fenómenos computacionales. Todos los científicos computacionales utilizan la abstracción como una herramienta fundamental de investigación, y muchos podrían argumentar que las Ciencias Computacionales son en sí la ciencia de la construcción y el examen de los modelos computacionales abstractos de la realidad. La abstracción surge en la arquitectura de computadores, donde la máquina de Turing sirve como un modelo abstracto para los equipos reales complejos, y en los lenguajes de programación, donde se utilizan modelos semánticos simples, como el cálculo lambda, como marcos

para el estudio de lenguajes complejos; también aparece en el diseño de algoritmos heurísticos y en la aproximación a problemas cuya solución óptima es intratable computacionalmente. Además, se utiliza en los gráficos y la computación visual, donde los modelos de los objetos tridimensionales se construyen matemáticamente, debido a que las propiedades de iluminación, color y textura de la superficie, se proyectan de manera realista en una pantalla bidimensional.

4.3 Diseño El diseño es un proceso mediante el cual se modela la estructura esencial de los sistemas complejos como el preludio para su aplicación práctica. También abarca el uso de métodos tradicionales de ingeniería, incluyendo al modelo de ciclo de vida clásico, para implementar sistemas computacionales eficientes y útiles en hardware y software. Incluye el uso de herramientas como el análisis costo-beneficio de las alternativas, el análisis de riesgos y la tolerancia a fallos que garantizan que las aplicaciones se implementen efectivamente. El diseño es una preocupación central de los arquitectos de sistemas y los ingenieros de software que desarrollan sistemas hardware y aplicaciones software. El diseño es una actividad muy importante en las Ciencias Computacionales, la gestión de la información, la interacción humano-computador, los sistemas operativos y la computación centrada en red.

4.4 Contexto social y profesional Este contexto incluye muchas de las preocupaciones que surgen en la interfaz humano-computador, como la responsabilidad por los errores de hardware y software, la seguridad y la privacidad de la información en bases de datos y redes, las cuestiones de propiedad intelectual y equidad y de patentes y derechos de autor. Los científicos computacionales deben considerar el contexto ético en el que se produce su trabajo y las responsabilidades especiales que lo asisten. 5. PROSPECTIVA De acuerdo con el US Department of Labor, Bureau of Labor Statistics, las Ciencias Computacionales será una de las ocupaciones de más rápido crecimiento en las próximas décadas [7]. El fuerte crecimiento del empleo combinado con la cantidad limitada de profesionales cualificados dará como resultado buenas perspectivas de

17

empleo para esta ocupación y una alta demanda de sus habilidades. Se espera que el porcentaje de ocupación de estos científicos sea de un 37% hasta 2016, mucho más rápido que el promedio para todas las ocupaciones. Debido a los desarrollos tecnológicos de este siglo las organizaciones necesitan profesionales para adoptar e integrar productos cada vez más sofisticados. El aumento del empleo será impulsado por un crecimiento rápido en el diseño de sistemas informáticos y los servicios conexos, que se prevé será una de las industrias de más rápido crecimiento en la economía mundial. La demanda por redes que faciliten el intercambio de información, la expansión de los entornos cliente-servidor, y la necesidad de especialistas en informática para utilizar sus conocimientos y habilidades como capacidad para la resolución de problemas serán los principales factores en el aumento de la demanda para los Científicos Computacionales. Las empresas seguirán buscando a quienes sean capaces de implementar las últimas tecnologías y de aplicarlas para atender sus necesidades, en la lucha por mantener una ventaja competitiva. Debido a que los computadores se utilizan cada vez más en las funciones de negocio, igualmente se necesita implementar tecnología más sofisticada y compleja en las organizaciones, lo que genera la demanda por profesionales mejor calificados. La expansión del comercio electrónico y la continua necesidad de construir y mantener bases de datos para almacenar información crítica, están impulsando la demanda por administradores de bases de datos familiarizados con las tecnologías de punta. Además, debido a la creciente dependencia de Internet entre las empresas, la seguridad de la información es una preocupación constante. La expansión de la integración de las tecnologías de Internet en las empresas ha dado lugar a una creciente necesidad de especialistas que puedan desarrollar y apoyar las aplicaciones de Internet e intranet, y el crecimiento del comercio electrónico significa que más establecimientos utilizan la Internet para llevar a cabo sus negocios en línea, lo que genera demanda por más especialistas en seguridad para proteger sus sistemas. El crecimiento explosivo en estas áreas también se espera que impulse la demanda de profesionales bien capacitados en redes de datos y en la seguridad de las comunicaciones. La tecnología de este siglo es cada vez más sofisticada y compleja, por lo que exigirán un mayor nivel de habilidades y experiencias de quienes la administran. Las personas con un grado avanzado en Ciencias Computacionales o Ingeniería Informática deberán disfrutar de perspectivas de empleo favorables. Esto se debe a que los empleadores continuarán buscando especialistas que puedan combinar fuertes habilidades técnicas con buenas habilidades de negocios, y los individuos con una combinación de experiencia dentro y fuera de la arena tendrán mejores posibilidades de trabajo. 6. ORGANIZACIONES PROFESIONALES Las organizaciones y asociaciones profesionales ofrecen una amplia gama de recursos para planificar y navegar

por una carrera en Ciencias Computacionales. Estos grupos juegan un papel clave en el desarrollo del área y mantienen a los interesados al tanto de lo que está sucediendo en la industria. Las asociaciones promueven los intereses de sus miembros y proporcionan una red de contactos que ayudan a encontrar puestos de trabajo y a lograr mejor cualificación. Ellas pueden ofrecer una variedad de servicios, incluidos el de referencias de empleo, cursos de formación continua, aseguramiento, publicaciones periódicas y reuniones y oportunidades para conferencias. A continuación se describen algunas de estas asociaciones, pero una lista más amplia está disponible en www.careercornerstone.org. Association for Computing Machinery ACM (www.acm.org) Fundada en 1947, ACM es una fuerza importante para el avance en los conocimientos de los profesionales en tecnologías de la información y estudiantes de todo el mundo. Sus más de 80.000 miembros actuales y el público en general ingresan al portal de literatura, relacionada en publicaciones autorizadas y conferencias pioneras, que proporciona liderazgo y conocimiento permanente para el siglo XXI. Institute of Electrical and Electronics Engineers IEEE (www.ieee.org) Las raíces del IEEE se remontan a 1884, cuando la electricidad empezaba a convertirse en una fuerza importante en la sociedad. Es una asociación dedicada a promover la innovación y la excelencia tecnológica en beneficio de la humanidad, y es la sociedad técnica profesional más grande del mundo. Está diseñado para servir a los profesionales involucrados en todos los aspectos de los campos eléctricos, electrónicos y de computación, y áreas afines de la ciencia y la tecnología en la que se basa la civilización moderna. IEEE Computer Society (www.computer.org) Con más de 100.000 miembros, IEEE es la organización de profesionales en informática líder a nivel mundial. Fundada en 1946, es la más grande de las 39 sociedades del IEEE. 7. CONCLUSIONES Este artículo tiene como objetivo caracterizar las Ciencias Computacionales, incorporando el crecimiento explosivo de Internet y la creciente importancia de las áreas temáticas como la interacción persona-computador, la computación científica masivamente en paralelo, la tecnología de la información ubicua, y otros sub-campos que podrían no haber aparecido hace diez años. El campo de las Ciencias Computacionales ha experimentado una dramática evolución en sus cortos 70 años de vida. A medida que madura, emergen nuevas áreas de investigación y de aplicación y se unen a los descubrimientos clásicos en un ciclo continuo de la revitalización y crecimiento. En 2002, ACM celebraba su 55 aniversario. En estas cinco décadas las Ciencias Computacionales se caracterizaron por un alto crecimiento y evolución. A pesar de que es seguro reafirmar que este campo ha alcanzado cierto nivel de

18

madurez, seguramente es claro suponer que no se mantendrá sin cambios durante mucho tiempo. Porque la comunidad está pidiendo y trabaja en nuevas visiones que le permitan a la disciplina seguir su rápida evolución como respuesta a la continua demanda mundial de nuevas tecnologías e innovaciones. Este trabajo está diseñado para comunicar el espíritu moderno, los logros y la dirección de las Ciencias Computacionales. Se proporcionan respuestas actuales a las preguntas computacionales planteadas por los profesionales e investigadores que trabajan en las áreas temáticas que conforman estas Ciencias. Además, se identifican las cuestiones profesionales y sociales que se encuentran en la intersección de los aspectos técnicos y de las personas cuyas vidas se ven afectadas por este tipo de tecnologías. El futuro es muy prometedor para las próximas generaciones de científicos computacionales. Porque van a resolver los problemas que recientemente se están concibiendo, como los "grandes desafíos" sugeridos por el Advisory Committee for Cyberinfrastructure de la National Science Foundation (National Science Foundation 2011). Para hacerles frente a estos problemas de forma que se beneficie a los ciudadanos del mundo se

requiere una considerable energía y el compromiso y la inversión real por parte de instituciones y profesionales de todos campos. Los desafíos son grandes, y las soluciones no son susceptibles de ser obvias. 8. REFERENCIAS [1] Stevenson, D.E. (1994). Science, computational science, and

computer science. Communications of the ACM, 37(12), pp. 85-96.

[2] Gibbs, N. & Tucker, A. (1986). A Model Curriculum for a Liberal Arts Degree in Computer Science. Communications of the ACM, 29(3), pp. 202-210.

[3] Bryant, R.E. & Vardi, M.Y. (2002). 2000–2001 Taulbee Survey: Hope for More Balance in Supply and Demand. Computing Research News, 14(2), pp. 4-11.

[4] http://ai.stanford.edu/users/sahami/CS2013/ [Feb. 2013]. [5] Denning, P. et al. (1989). Computing as a discipline:

preliminary report of the ACM task force on the core of computer science. Communications of the ACM, 20(1), pp. 41.

[6] Sipser, M. (2012). Introduction to the Theory of Computation. Wadsworth Publishing Co Inc.

[7] Advisory Committee for Cyber-infrastructure. (2011). Task Force on Grand Challenges. National Science Foundation. Final Report.

19

Analysis to the Culture Shock in Scientific Software Development

Análisis al Choque de Culturas en el Desarrollo de Software Científico

Charles Boleros Agencia Gubernamental de las Ciencias Computacionales. Boleros.Charles(AT)gacs.ca

INFORMACIÓN DEL ARTÍCULO Tipo de artículo: Reflexión Historia del artículo Recibido: 17-03-2013 Correcciones: 10-06-2013 Aceptado: 12-06-2013 Categories and Subject Descriptors K.3.2 [Computers and Education]: Computer and Information Science Education – Computer science education. General Terms Software Engineering, Requirements Engineering, Computational Complexity, Algorithmic Analysis. Keywords Software development, Software Engineering, IT projects, scientific software. Palabras clave Desarrollo de software, Ingeniería de Software, proyectos informáticos, software científico.

ABSTRACT In this paper are analyzed two cultures, the scientists who develop their own software and software engineers who develop scientific software, It describes some of the problems that arise when both cultures come together to develop scientific software, and discusses the impact that arises when their representatives intend to carry out joint projects. RESUMEN En este trabajo se analizan dos culturas, la de los científicos que desarrollan su propio software y la de los ingenieros de software que desarrollan software científico, se describen algunos de los problemas que surgen cuando ambas culturas se unen para desarrollar software científico, y se analiza el choque que surge cuando sus representantes intentan llevar a cabo proyectos conjuntos.

© 2013 IAI. All rights reserved.

1. INTRODUCCIÓN Una de las diferencias entre el desarrollo del software comercial y desarrollo de software científico reside en la complejidad de su dominio. La mayoría de ingenieros de software tienen cierta intuición sobre lo que se requiere, por ejemplo, de un sistema de reservas de vuelo, uno bancario o uno de nómina, pero pocos intuyen lo que se necesita, por ejemplo, para modelar un sistema estocástico, uno de química cuántica o uno de cristalografía de proteínas. La implicación de esto es que los científicos necesitan estar profundamente involucrados en el desarrollo del sistema, o interpretar ellos mismos el rol de desarrolladores profesionales, o suministrar y explicar los requisitos, a la vez que retroalimentan y realizan pruebas de aceptación de usuario final en los productos software que requieren. Para una mayor comprensión del objetivo de este trabajo es necesario definir los términos desarrolladores

profesionales y cultura. El primero se refiere a los científicos y a los ingenieros que trabajan en campos muy técnicos, que tienen amplio conocimiento de un dominio, y que desarrollan software con el fin de alcanzar sus propios objetivos profesionales y/o los de sus colegas más cercanos [1]; también se incluye a otros desarrolladores que no se consideran a sí mismos desarrolladores de software, que tienen poca o ninguna formación en Ingeniería de Software, y que contrario a la mayoría de desarrolladores la codificación per se les presenta algunos problemas, porque están acostumbrados a desarrollar en lenguajes formales. El término cultura en sí tiene muchos significados, pero en este artículo se toma como una referencia al conjunto de valores y comportamientos habituales de un grupo identificable de personas, que para esta investigación son los desarrolladores profesionales y los ingenieros de software.

RACCIS, 3(1), 19-24, 2013

Revista Antioqueña de las

Ciencias Computacionales y la Ingeniería de Software

ISSN: 2248-7441

www.fundacioniai.org/raccis

raccis@fundacioniai.org

20

Este documento se basa en estudios de campo realizados con grupos matemáticos financieros, científicos planetarios y de la tierra, científicos espaciales y biólogos moleculares. En el contenido se describe la cultura dentro de la cual se inscriben los científicos que desarrollan software por su propio uso y/o para sus colegas más cercanos, y se presenta el modelo que emplean para desarrollar sus productos. Posteriormente se detallan algunos problemas que tienen los ingenieros de software cuando trabajan en estrecha colaboración con los científicos para desarrollar software científico, y que se originan a partir del desajuste cultural que se presenta en el equipo. En el primer caso, los ingenieros tratan de imponer la cultura tradicional de la Ingeniería de Software, y en el segundo, los científicos esperan que los ingenieros adopten la cultura del desarrollo profesional. También se discuten las limitaciones de los estudios de campo, porque a pesar de que exploran una amplia variedad de contextos, de ninguna manera se pueden considerar exhaustivos. Además, se analiza si modelos de desarrollo como el de cascada o el incremental se ajustan mejor al software científico, y si las características de la cultura que se describen son comunes en todos los contextos de desarrollo de software científico. 2. LAS DOS CULTURAS 2.1 Valores La característica más sobresaliente de la cultura de los desarrolladores profesionales, observada en los estudios de campo con los matemáticos y los científicos de la tierra y el espacio, es el escaso valor atribuido a los conocimientos necesarios para desarrollar software, en comparación con la apreciación del conocimiento del dominio matemático/científico [1]. Estas personas se expresan en términos como que todo el mundo sabe cómo desarrollar software, que dicho conocimiento es simplemente parte de la armería del científico promedio, y que un componente software es algo que se puede construir en una hora de almuerzo. En los contextos formativos de estos científicos, el desarrollo de software es algo que se practica al inicio de sus carreras profesionales. A medida que ascienden en el escalafón profesional, van dejando atrás esta actividad para que la realicen los jóvenes. La situación, en la que este no es el caso, es decir, en la que un desarrollador profesional o un ingeniero de software que trabaja en una organización desarrollando software a tiempo completo, no parece diferir significativamente en lo que tiene que ver con el bajo valor que la misma organización le da a los conocimientos y habilidades necesarias para hacerlo. Los biólogos moleculares, aunque la automatización es clave para su trabajo de laboratorio, y por supuesto el software es clave para lograrla, sienten que desarrollando software no podrán llegar a ser jefes del laboratorio. Su creencia es que a esa posición siempre llegan biólogos tradicionales, a pesar de que la biología tradicional juega una parte relativamente pequeña en el trabajo de laboratorio. De acuerdo con la opinión de los ingenieros de software que están vinculados con centros de investigación,

gubernamentales o privados, los desarrolladores no logran fácilmente los ascensos debido a que debe mantener una publicación científica constante para lograrlo. Esto a pesar del hecho de que su competencia es el desarrollo de software y no la de escribir artículos científicos. Además, consideran que su labor no es adecuadamente comprendida, y que no se puede juzgar al desarrollo de software profesional como si fuera una labor rutinaria para la organización. Porque los criterios de calidad que el producto necesita involucran, en muchas ocasiones, vidas humanas, a diferencia del trabajo que realizan muchos otros científicos, donde lo más preocupante es que entreguen datos incorrectos y vean lesionada su imagen y credibilidad. Ese bajo valor atribuido a los conocimientos y habilidades sin duda contribuye a las dificultades que los desarrolladores profesionales tienen para adquirirlas [1], a pesar de que se supone que todo el mundo sabe lo que debe hacer. Los desarrolladores profesionales rara vez han tenido una formación adecuada en Ingeniería de Software, sin embargo, lo mismo se puede decir de muchos ingenieros de software; y de hecho, frecuentemente muchos cursos universitarios en esta área son impopulares entre los potenciales desarrolladores profesionales, porque a menudo se les imparten de forma independiente del dominio, y los estudiantes son incapaces de establecer vínculos entre la manera como se forma en Ingeniería de Software y la ciencia que han elegido [2]. Una cuestión importante para una adecuada formación son los procesos formativos soportados en la resolución de problemas y en las prácticas continuas. En el trabajo de campo se encontró que los ingenieros de software adquieren conocimientos y habilidades a través de una variedad de medios, pero que todos dependen de comunidades o redes en la que se practica el desarrollo de programas. Estos procesos incluyen el trabajo con una variedad de otros desarrolladores, en una diversidad de proyectos y compartiendo conocimientos de manera informal, lecturas de libros y estudio de tutoriales, atendiendo recomendaciones de los colegas, y asistiendo a conferencias técnicas y cursos de corta duración, y los productos se dan a conocer para discusión práctica en la red. Para los desarrolladores profesionales no existen estas comunidades, porque los procesos se desenvuelven en el dominio de aplicación, es decir, la ciencia. Además, suelen trabajar solos o en grupos muy pequeños y rara vez tienen la oportunidad de compartir conocimientos de manera informal. En al menos uno de los estudios de campo se encontró la percepción de que el conocimiento para el desarrollo de software es trivial y conocido por todos, lo que significa que la coordinación es reacia a gastar dinero en recursos como cursos diseñados para mejorar ese conocimiento. 2.2 Comportamientos

La Figura 1 representa el modelo estándar que aplican los desarrolladores profesionales [3], que de acuerdo con los estudios de campo al parecer es el mismo que aplican los científicos.

21

Figura 1. Modelo de desarrollo de los científicos [3]

En este modelo, el desarrollador comienza con una idea vaga de lo que se necesita, desarrolla rápidamente un componente software, y luego se sienta y reflexiona acerca de si el producto hace lo que necesita y en cómo ampliarlo o modificarlo; en algunos casos consultado a sus colegas. Realiza y evalúa varias veces este proceso hasta que decide que tiene una versión adecuada. No tiene en cuenta las pruebas o ejecuta casos muy superficiales; por ejemplo, introduce algunos tipos de datos similares a los que se pueden aparecer cuando se libere el producto, y comprueba la salida para ver si es correcta, o al menos que se acerque a lo esperado. Entonces, el software está listo para ser liberado como una herramienta para uso científico. Las características principales de este modelo son: 1) falta de un modelo inicial de requisitos, 2) entrelazamiento de la evaluación y la identificación de las necesidades emergentes y 3) carácter superficial de la prueba final. Este patrón no se trabaja en los cursos de Ingeniería de Software, sin embargo, a juzgar por su omnipresencia, funciona, aunque en el contexto parte de una idea vaga de lo que se necesita y depende de que el desarrollador tenga un conocimiento suficiente y amplio del dominio. La confianza en la retroalimentación obedece a que el desarrollador esté involucrado en la comunidad de usuarios. En la mayoría de proyectos software se tiene problemas para lograr que los potenciales usuarios participen en el proceso de desarrollo ofreciendo sus opiniones y aportando en la construcción. Conseguir tal retroalimentación es mucho más fácil si el usuario, como desarrollador, les pide a sus colegas la opinión sobre el producto. En cuanto a la superficialidad de las pruebas se puede decir lo siguiente: 1) el escaso valor asignado al software en relación con el colocado a la ciencia: el software se valora sólo en la medida en que avanza la ciencia. Aquí es necesario que los científicos consideren al software de la misma manera que a cualquier otro instrumento que les permite lograr sus esfuerzos científicos. Filósofos e historiadores de la ciencia [4] afirman que los científicos asumen que sus instrumentos funcionan sólo cuando los

confrontan con pruebas absolutamente incontrovertibles. Tal vez esta hipótesis también se cumple para su software: la calidad innata del software no se cuestiona a menos que quede claro que no está apoyando la ciencia. 2) El hecho de que el desarrollador esté involucrado en la comunidad de usuarios: si un científico encuentra fallas en un componente software de un colega tiene la ventaja de que hacen parte de la misma comunidad, y las modificaciones las puede implementar con facilidad. 3) La dificultad para validar un producto en el que el dominio es poco conocido: tiene que ver con la naturaleza del software científico, y se refiere a que su finalidad es poder avanzar en la comprensión del mismo dominio [5]. En este caso, simplemente no hay forma de que los científicos puedan saber si la salida del software es correcta: sólo tienen que confiar en sus instintos de que la salida no es absolutamente incorrecta. 3. CHOQUE DE CULTURAS En esta sección se describen dos situaciones: 1) los ingenieros de software tratan de imponerles a los científicos la cultura tradicional de la Ingeniería de Software y 2) los científicos asumen que los ingenieros de software están trabajando dentro de la cultura del modelo de desarrollo de software científico. 3.1 Por qué los científicos no pueden ser más como

ingenieros de software El análisis de esta cuestión se basa en el estudio de campo que describe Segal [6]. El contexto del estudio es la siguiente: los científicos estaban familiarizados con la escritura de su propio código en el laboratorio para hacer funcionar instrumentos como el espectrómetro y para analizar los datos procedentes de los mismos. En un momento del proceso estaban a punto de embarcarse en una tarea muy arriesgada: en lugar de recoger el material del espacio y traerlo de vuelta a la Tierra para analizarlo en el laboratorio, iban a enviar un instrumento al espacio para hacer el análisis in situ y retransmitir los resultados a la Tierra. Contrataron ingenieros de software para escribir una biblioteca de componentes que podrían utilizar para conducir al instrumento, y tenían en el laboratorio un modelo del mismo que se podría utilizar para materializar esas necesidades. Los ingenieros

22

siguieron un modelo de desarrollo tipo cascada escalonada, de acuerdo con lo recomendado por la European Space Agency (ESA). Los científicos en el laboratorio siguieron el modelo de desarrollo de la Figura 1. El primer problema que surgió fue el de los requisitos,

tal como se ilustra en la Figura 2. Los ingenieros necesitaban un documento de especificación, mientras que los científicos esperaban que la mayoría de requisitos emergieran en el proceso.

Figura 2. Por qué los científicos no pueden ser más como ingenieros de software [3]

3.2 Por qué los ingenieros de software no pueden ser

más como científicos Este análisis se basa en aspectos de un estudio de campo inédito en el que unos biólogos moleculares emplearon a ingenieros de software para escribir algunos programas para la comunidad. Los biólogos habían sido todos alguna vez desarrolladores profesionales, y algunos todavía estaban desarrollando su propio software. Sin embargo, la comunidad para la que estaba destinado el software era diversa y el producto en sí era mucho más grande que cualquiera que un desarrollador profesional hubiese

abordado, por lo tanto se consideró necesario que los científicos emplearan a los ingenieros de software. El primer problema que enfrentaron fue, nuevamente, los requisitos. Al entregarle al director del proyecto de los ingenieros una lista de características, los biólogos indicaron verbalmente que los requisitos se conocían con exactitud y que ahí estaban. Por supuesto, la descripción estaba en un lenguaje demasiado alto como para que los ingenieros la pudieran aplicar. En la Figura 3 se ilustra un ejemplo hipotético de esta situación, aunque muy cercana a la realidad.

Figura 3. Por qué los ingenieros de software no pueden ser más como científicos

El proceso que aplican los científicos para escribir un componente de software con una determinada funcionalidad científica es perfectamente razonable, siempre que el desarrollador sea un científico. En este caso, el desarrollador conoce el dominio, tiene alguna intuición acerca de cómo puede funcionar y puede utilizar un programa de adaptación gráfica simple, puede desarrollar un primer prototipo y pedirles a sus colegas que lo revisen, y generalmente sigue el modelo de desarrollo de la Figura 1. El ingeniero de software, sin

embargo, con una, aunque sea débil, comprensión del dominio, tiene grandes dificultades para continuar. La Figura 3 ilustra otro choque entre las expectativas de los desarrolladores profesionales y los ingenieros de software, y tiene que ver con el tiempo que toma el desarrollo de programas, que a su vez depende de los distintos valores y comportamientos adoptados por cada uno de ellos. En general, al desarrollador profesional le toma menos tiempo. Hay varias razones para esto:

23

1. Los requisitos. Para el desarrollador profesional la elicitación de requisitos está totalmente integrada con el desarrollo mismo, como se ilustra en la Figura 1; además, en el contexto en el que se desenvuelve es un fiel representante del grupo de usuarios finales, lo que implica que el grupo es homogéneo y no se divide en subgrupos con objetivos y comportamientos diversos. Para el ingeniero de software, que desarrolla para una comunidad diversa, la elicitación de requisitos es una tarea que le consume tiempo y es difícil. Los usuarios potenciales tienen que ser persuadidos para desvincularse de sus tareas y comprometerse con el desarrollo de un sistema, que posiblemente nunca utilizarán cuando esté finalizado. Los ingenieros de software tienen que asegurar que la diversidad de la comunidad de usuarios esté representada adecuadamente, que los enfrentamientos entre los diferentes sectores de la misma se resuelvan, y así sucesivamente.

2. Aquellas cuestiones que reflejan los valores de la

ingeniería de software, en comparación con los de los desarrolladores profesionales. Una de ellas es la prueba. Previamente se discutió que la prueba superficial es una característica del modelo de los desarrolladores profesionales, en parte porque se hace énfasis en la ciencia que el producto está destinado a apoyar y no en el software per se. Por otro lado, para los ingenieros de software lo ideal sería identificar los objetivos de calidad para cualquier componente software, y asignar el tiempo de prueba de acuerdo con ellos. Por ejemplo, un objetivo de calidad podría ser la robustez, en cuyo caso se debe destinar tiempo suficiente a las pruebas de tal forma que el producto responda sin importar la variedad de entradas. Otras cuestiones que no suelen tener mayor impacto para los desarrolladores profesionales es la portabilidad y la facilidad de mantenimiento. También puede haber problemas de seguridad cuando se trata de una comunidad de usuarios diversos, por ejemplo, los problemas de acceso a los datos cuando varios usuarios utilizan a la vez el mismo sistema.

4. LIMITACIONES DE LA INVESTIGACIÓN Los estudios de campo presentados en este trabajo [1, 6] se desarrollaron en una amplia variedad de configuraciones; sus dominios de aplicación son las matemáticas financieras, las ciencias planetarias y la biología molecular, en los que los científicos han desarrollado su software en colaboración con ingenieros de software o por su propia cuenta, los cuales incluyen aplicaciones para impulsar los instrumentos, los modelos de mercados financieros y para almacenar, analizar y apoyar la interpretación de datos. En esta variedad se encontró una serie de elementos comunes, como el escaso valor atribuido a los conocimientos y habilidades para desarrollar software en comparación con el conocimiento y habilidades en el dominio, y la ubicuidad del modelo aplicado por los desarrolladores profesionales. Sin embargo, estos estudios de ninguna manera son integrales. Por ejemplo, los ingenieros de software en

ningún momento adoptaron metodologías ágiles, que de acuerdo con otros desarrolladores es un proceso iterativo de bucles de retroalimentación y de comunicación cara a cara [7], y que podrían ofrecer más al desarrollo de software científico que los métodos tradicionales por etapas de tipo cascada. En la literatura se encuentran informes de experiencias de ingenieros de software que han participado con éxito en el desarrollo ágil científico [8, 9]. Sin embargo, para este trabajo no se encontraron datos de estudios de campo con objetivos en las áreas tratadas, y dados los resultados de los trabajos analizados en desarrollo de software científico, surge el interrogante de si cuando los científicos se refieren a sí mismos como que aplican una metodología ágil, se están refiriendo al modelo de retroalimentación iterativa de la Figura 1. Además, los estudios de campo tratados aquí no cubren los sistemas de alto rendimiento (HPCS por sus siglas en inglés), es decir, sistemas en los que varios procesadores actúan en paralelo. Estos sistemas son de uso común en la ciencia para simular fenómenos naturales que son demasiado grandes, o demasiado pequeños, o demasiado peligrosos, o demasiado complejos, para ser investigados en vivo. Recientemente, en los EE.UU. se ha incrementado el interés por la investigación en HPCS, impulsado por grandes proyectos múltiple-fases, como el DARPA [10]. Este proyecto se inició como respuesta a la preocupación de que la productividad científica, usando sistemas HPCS, no parecía progresar a la velocidad que mejoran las capacidades hardware. El objetivo es mejorar la productividad científica en un factor de diez, a fuerza de mejorar el software y el hardware. Sin embargo, la naturaleza exacta del concepto de productividad científica no parece haber sido explicado completamente. DARPA ha generado varios estudios de campo de los científicos que están profundamente involucrados en el desarrollo de simulaciones software [5, 11]. Los contextos en que los científicos utilizan HPCS son variados y algunos aceptan que sus estudios no son exhaustivos [11]. También reconocen que, incluso dentro de sus estudios de campo, se encontraron con gran cantidad de variaciones. Sin embargo, esos estudios de campo demuestran similitudes con el trabajo que aquí se presenta. Por ejemplo, encontraron que para la ciencia el software era de suma importancia, que el proceso aplicado tiene una dependencia directa de los requisitos emergentes, y que en todos tienen dificultades con las pruebas. De la misma forma, algunos de sus resultados difieren de los presentados en este artículo. Por ejemplo, no siempre encuentra en sus estudios de caso el estado relativamente bajo del desarrollo de software. Otra cuestión es la que se refiere al estatus del desarrollador profesional, porque en su investigación encontraron, por ejemplo, que a veces los físicos que desarrollan HPCS se veían como una élite entre los físicos, y que la opinión de sí mismos no se basaba en lo que podían llevar a la física, sino más bien por su destreza para emplear trucos de los desarrolladores para apoyar el procesamiento paralelo. Esto es totalmente contrario a las conclusiones en este artículo. Una posible

24

explicación es que estos científicos consideran que la física tiene esencialmente tres ramas de igual valor: la teórica, la experimental y la in silico ―simulaciones software―. Este no parece ser el caso de estudios de campo analizados en esta investigación, porque el software, a excepción de los matemáticos financieros, se ve como una herramienta de apoyo a la investigación científica y no como un modelo de ciencia que se puede consultar directamente. Dada la importancia de las simulaciones en la ciencia, es evidente que los HPCS representan un dominio del desarrollo de software científico que representa un área de trabajo futuro. 5. CONCLUSIONES En los estudios de campo analizados se identificaron dos características de la cultura de los científicos desarrolladores profesionales: 1) el bajo valor que se da al conocimiento y habilidades para el desarrollo de software, en comparación con el conocimiento del dominio, y 2) un modelo de desarrollo profesional. A juzgar por su omnipresencia, este último es un gran éxito, aunque sólo en un contexto particular. Para este contenido se identificaron las siguientes características: El desarrollador se inserta en la comunidad de

usuarios La comunidad de usuarios es coherente Los requisitos no están plenamente establecidas desde

el principio El valor del software reside en la medida en que

progresa la ciencia Otra cuestión que llama la atención en esta investigación son los enfrentamientos que se producen cuando los ingenieros de software tratan de imponer a los científicos su cultura de desarrollo tradicional, y viceversa. La cobertura de los estudios de campo analizados ilustra sólo algunas de las variedades de desarrollo de software científico. Otros estudios de campo han investigado la situación en la que se desarrollan sistemas de computación de alto rendimiento para fines de simulación, y han confirmado que en ellos prima la ciencia sobre el software, la importancia de los requisitos emergentes y las dificultades de las pruebas. Esta investigación es importante porque se demuestra que los ingenieros de software no pueden esperar proporcionar herramientas, tecnologías y métodos eficaces para mejorar el desarrollo de software científico sino comprenden el contexto cultural, los valores y los comportamientos habituales, en los que este desarrollo tiene lugar. La falta de comprensión de este contexto puede generar importantes problemas en el proceso, pero todavía hay mucho trabajo por hacer en este campo. Por ejemplo, un programa de investigación completo podría abarcar lo siguiente: 1. Identificar las dimensiones sobresalientes en las que

se pueden caracterizar contextos de computación científica. Esto podría incluir: si los científicos están

desarrollando el software por su cuenta, y si no, el grado en que los ingenieros de software están implicados, y el valor atribuido al desarrollo de software en la comunidad de usuarios. Otras dimensiones pueden ser: si la comunidad de usuarios es homogénea o diversa, el tamaño del equipo de desarrollo, la longevidad del código, entre otras tantas.

2. Identificar aquellas técnicas de ingeniería de software

establecidas que podrían ayudar a los desarrolladores de software científico.

3. Establecer una correlación entre las técnicas de

software identificadas en ambas culturas y los contextos caracterizados por las dimensiones de los desarrolladores profesionales y la cultura.

4. Identificar los medios por los que los científicos

podrían estar al tanto de las técnicas y herramientas de ingeniería de software que pueden ser relevantes para sus desarrollos.

Este último punto es especialmente importante dadas las dificultades de intercambio de conocimientos entre los desarrolladores profesionales. Esta agenda de investigación puede parecer desalentadora, pero se espera que este trabajo y otros similares puedan contribuir a un importante primer paso. 6. REFERENCIAS [1] Segal, J. (2007). Some problems of professional end user

developers. In proceedings IEEE Symposium on Visual Languages and Human-Centric Computing, VLHCC’07 (Idaho, USA, September 23-27), pp. 111-118.

[2] Kelly, D.F. (2007). A software chasm: software engineering and scientific computing. IEEE Software, 24(6), pp. 120-199.

[3] Segal, J. & Morris, C. (2008). Developing scientific software. IEEE Software, 25(4), pp. 18-20.

[4] Chalmers, A.F. (1999). What is this thing called science? Hackett; Edición: 3.

[5] Carver, J.C. et al. (2007). Software Development Environments for Scientific and Engineering Software: A Series of Case Studies. In proceedings Int’l Conf. Software Engineering, CSE’07 (Minneapolis, USA, May 19-27), pp. 550-559.

[6] Segal, J. (2005). When software engineers met research scientists: a case study. Empirical Software Engineering, 10(4), pp. 517-536.

[7] http://agilemanifesto.org/ [Jan. 2013]. [8] Bache, E. (2003). Building software for scientists: a report

about incremental adoption of XP. In proceedings 4th International Conference, XP2003 (Genoa, Italy, May 25-29), pp. 24.

[9] Kane, D. (2003). Introducing agile development into bioinformatics: an experience report. In proceedings Agile Development Conference, ADC2003 (Salt Lake City, USA, June 25-28), pp. 132-139.

[10] www.highproductivity.org [Jan. 2013]. [11] Basili, V.R et al. (2008). Understanding the high

performance computing community: a software engineer’s perspective. IEEE Software, 25(4), pp. 29-36.

25

Introduction of the Formal Methods in Software Engineering Training

Introducción de los Métodos Formales en la Formación en Ingeniería de Software

Jorge Toledo B. Instituto Europeo de Investigación en Ingeniería de Software. Toledobj(AT)erise.de

INFORMACIÓN DEL ARTÍCULO

Tipo de artículo: Reflexión

Historia del artículo Recibido: 22-02-2013 Correcciones: 28-05-2013 Aceptado: 01-06-2013

Categories and Subject Descriptors K.3.2 [Computers and Education]: Computer and Information Science Education – Computer science education.

General Terms Computer Science, Software Engineering, Computational Mathematics, Formal Methods. Keywords Formal Methods, training, Software Engineering, teaching methods. Palabras clave Métodos formales, formación, Ingeniería de Software, métodos de enseñanza.

ABSTRACT Formal methods were developed to provide systematic and rigorous techniques for software development, and as initiative will be introduced in training in Software Engineering (SE). This article discusses the importance of including these scientific principles and describes several specific techniques in order to improve the processes of the IS. It also provides an analysis of the principles that should be taken into account in a curriculum to systematically introduce in university education and business. Several methods have been tried in recent years to achieve this goal in undergraduate and graduate universities programs, as well as IT professionals. Experience shows that participants gain confidence in formal methods only when they learn their clear benefits in the context of software engineering. RESUMEN Los métodos formales se desarrollaron para proporcionar técnicas sistemáticas y rigurosas para el desarrollo de software, y como iniciativa se deben introducir en la formación en Ingeniería de Software (IS). En este artículo se discute la importancia de incluir estos principios científicos y se describen varias técnicas específicas para lograr mejorar los procesos de la IS. También se hace un análisis a los principios que se deben tener en cuenta en un plan de estudios para introducirlos sistemáticamente en la formación universitaria y empresarial. Varias metodologías se han probado en los últimos años para lograr este objetivo en programas de pregrado y de posgrado en diversas universidades, así como para los profesionales de TI. La experiencia muestra que los participantes ganan confianza en los métodos formales sólo cuando se enteran de sus claros beneficios en el contexto de la Ingeniería de Software.

© 2013 IAI. All rights reserved

1. INTRODUCCIÓN A pesar de que hace más de cuarenta años que se vienen realizando esfuerzos para desarrollar teorías, lenguajes, métodos y herramientas de soporte, la Ingeniería de Software práctica todavía es como un desierto, debido a la falta de instrucciones y modos eficaces de encontrar la manera de salir de la crisis del software. Los métodos formales se desarrollaron para hacer frente a este problema mediante la aplicación de técnicas matemáticas, incluidas la especificación formal, el refinamiento y la Verificación. En teoría, ya se sabe cómo utilizar las notaciones formales para escribir las especificaciones, el refinamiento de cálculo para transformar gradualmente una especificación en una implementación correcta y la lógica de Hoare y Dijkstra para probar la correctitud de los programas, con el mismo rigor que se aplica en los teoremas matemáticos. Sin embargo, ninguna de estas técnicas es fácil de utilizar por los profesionales para hacer frente a los proyectos de software reales. El

problema es la complejidad y la incapacidad de los métodos formales en el tratamiento de sistemas a gran escala y los frecuentes cambios en requisitos y diseños. Estos desafíos para la aplicación directa de los métodos formales no quieren decir que éstos sean inútiles. De hecho, hoy son más necesarios que nunca porque el software se integra cada vez más en los sistemas que requiere y utiliza la sociedad, lo que pasa es que su papel es diferente al de otras técnicas relacionadas. El rol de los métodos formales es la formación, y su poder se puede transferirse a los proyectos de Ingeniería de Software a través de los desarrolladores que los aprenden y dominan. La manera de utilizarlos es mediante la práctica en la ingeniería formal [1]. Por ejemplo, el Structured Object-Oriented Formal Language (SOFL), un método de ingeniería formal, proporciona un enfoque de tres pasos para construir especificaciones formales para ayudar al análisis de requisitos, al diseño del sistema, a la

RACCIS, 3(1), 25-32, 2013

Revista Antioqueña de las

Ciencias Computacionales y la Ingeniería de Software

ISSN: 2248-7441

www.fundacioniai.org/raccis

raccis@fundacioniai.org

26

especificación basada en la inspección y a las pruebas para la detección de errores [2]. El desarrollo de proyectos software es una actividad humana, que deben ser completados en un tiempo específico y dentro del presupuesto especificado, y que a menudo se enfrentan a la inestabilidad de los equipos de desarrollo. En tal situación, aplicar los métodos formales completamente rara vez es práctico, pero mejorar la calidad del software se puede lograr equipando a los desarrolladores de una forma disciplinada y rigurosa de pensar mediante procesos de capacitación en métodos formales. Para alentar a más estudiantes, con o sin experiencia en desarrollo de software, a formarse en métodos formales, primero es necesario motivarlos a través de demostraciones claras de los beneficios que presentan los métodos formales para mejorar la práctica actual de la Ingeniería de Software. Si bien esto es un gran reto debido a la falta de evidencias cuantitativas fiables en la industria, muchos estudios empíricos, algunos de los cuales se han realizado en entornos industriales [3-5], se podrían utilizar para este propósito. La clave para que los estudiantes disfruten aprendiendo métodos formales son excelentes estilos y técnicas de formación, contenidos curriculares razonables y la colaboración permanente entre la academia y la industria. En este trabajo se describe varias técnicas para formar en métodos formales, a través de un eficaz plan de estudios en la academia y de un programa exitoso para la industria. El objetivo fundamental es introducir la formación en métodos formales en el contexto de la Ingeniería de Software, con la idea de que los ingenieros lleven sus principios a la industria. Por supuesto, como señala Parnas [6], los métodos formales no se deben limitar a la Ingeniería de Software, deben estar relacionados e integrados en las matemáticas generales de ingeniería. Dado que la cuestión de la aplicación general de los métodos formales está más allá del alcance de este artículo, el debate se centra en la cuestión de la formación para la Ingeniería de Software. El resto del artículo se organiza de la siguiente manera: en la sección 2 se discuten las técnicas de formación, en la 3 se describe la disposición actual de un plan de estudios relacionado, en la 4 se presenta un exitoso programa para la formación en métodos formales para la industria, en la sección 5 se discute la importancia de la formación permanente, y en la 6 se presentan las conclusiones. 2. TÉCNICAS DE FORMACIÓN En esta sección se presentan algunas técnicas específicas para la formación en métodos formales [1, 7, 8], las cuales han sido probadas durante algún tiempo en las universidades y las empresas. 2.1 Iniciar con ejemplos Aprender métodos formales es similar a aprender otras teorías o técnicas, por lo que se recomienda iniciar con ejemplos sencillos, que deben provenir de la vida diaria y deben ser capaces de vincular el problema con una potencial solución con métodos formales. Esta técnica motiva a los estudiantes y desarrolla su interés en estos

estos métodos. Por ejemplo, para explicar la ambigüedad de un problema especificado informalmente al mismo tiempo que demostrar que se puede resolver con formalización, se recomienda utilizar una operación de búsqueda de un número entero en una lista de números. Después de explicar la imprecisión de las declaraciones informales de requisitos, se presenta una especificación formal, que es a la vez precisa y concisa. Este ejemplo les ayuda a los estudiantes a comprender el poder potencial de la formalización. 2.2 Introducir gradualmente los conceptos

importantes Los conceptos importantes son la clave para entender el espíritu de los métodos formales. Si se hacen los esfuerzos suficientes para impartirlos son eficaces para ayudarles a los estudiantes a comprender el principio esencial de los métodos formales. Por ejemplo, al introducir las especificaciones formales, el tema central son las pre y post condiciones, una forma efectiva para comprender el concepto es comparándolas con el algoritmo correspondiente y dejar que los estudiantes entiendan la diferencia real y la relación entre una especificación y un algoritmo. La comparación se puede hacer sobre la base de la computación científica simple. Por ejemplo, a menudo se utiliza la operación de la raíz cuadrada de un número entero. La condición previa de la operación es x ≥ 0 y la post condición de esta operación puede ser y² = x, donde x es la entrada y y es la salida. Sin embargo, el algoritmo correspondiente sería algo así como y = Math.sqrt (x). Este ejemplo da lugar a un problema en el que la salida y producida por el algoritmo no puede satisfacer las post condiciones de la operación debido a que el algoritmo obtiene sólo una aproximación a la raíz cuadrada real de algunos números enteros positivos. En este caso, es útil mostrarles a los estudiantes la importancia de darse cuenta de esta falta de coherencia entre la especificación y la implementación. Este también es un buen ejemplo para mostrar la necesidad de usar o construir teorías adecuadas en el dominio de aplicación. 2.3 Problemas enmarcados en lo básico Escribir eficientemente especificaciones formales precisas requiere que el desarrollador tenga una buena comprensión de las características de los distintos tipos de datos y buenas habilidades para aplicar operadores bien definidos sobre los tipos de datos, como booleanos, conjuntos, secuencias y tipos de mapas. Por lo tanto, los estudiantes deben solucionar problemas enmarcados en los operadores básicos. Una forma eficaz para incorporar estos problemas en los programas es que los estudiantes los resuelvan inmediatamente después que se introduce un tipo de datos. Por ejemplo, después de la presentación de los tipos de conjuntos, deben comprender el significado de operadores como unión, intersección, cardinalidad, pertenencia, subconjunto, conjunto propio, y así sucesivamente, mediante la aplicación al conjunto de valores específicos. Si el tiempo lo permite, es útil un debate público acerca de los resultados de los estudiantes, porque esta discusión puede ayudarles a encontrar la razón de sus errores y para encaminarlos en la forma adecuada de pensar. Este entrenamiento es similar al de

27

la formación básica en deportes. Para ser un buen jugador de fútbol, por ejemplo, hay que ser rápido y tener un cuerpo fuerte. Para alcanzar estas cualidades, se debe practicar mucho tiempo y hacer un gran esfuerzo en la formación básica, porque si la olvida no se podrá desempeñar satisfactoriamente en los partidos. 2.4 Patrones de especificación para desarrollar

habilidades lógicas y abstractivas Para utilizar eficazmente un método formal se requiere que el desarrollador tenga buenas habilidades y capacidades en lógica y abstracción matemática, especialmente en el contexto del desarrollo de software. Por lo tanto, ayudarles a los estudiantes a desarrollar sus habilidades lógico-interpretativas y abstractivas se convierte en un tema importante en la formación en métodos formales. Teniendo en cuenta el hecho de que las operaciones básicas que se requieren en un sistema software por lo general incluyen buscar, clasificar, fusionar colecciones de objetos, adicionar, eliminar y actualizar elementos a partir de una colección existente, cálculos matemáticos, y sus posibles combinaciones, se debe hacer énfasis en formar en cómo expresar todas estas funciones con tipos de datos apropiados y sus operadores relacionados. Cada una de esas expresiones formará un patrón de especificación que permanecerá en la mente de los estudiantes y estará disponible para que la apliquen en el proceso del desarrollo de software real. Por ejemplo, ¿cuáles son los posibles patrones de especificación de una función que comprueba que una colección de enteros está vacía? Para responder a esta pregunta, primero se define una colección de números enteros como un conjunto y una secuencia en SOFL —VDM, Z u otro lenguaje formal— respectivamente. A continuación, se analizan los patrones de especificación más utilizados para cada una de las abstracciones de datos. Por supuesto, se puede tener el número de patrones que se desee para expresar el mismo significado, pero esto sería mucho más complejo y no mejora la legibilidad. Corresponde al profesor decidir si discutir en el aula un modelo más complejo o dejarlo como trabajo independiente para los estudiantes. Después que los estudiantes comprenden y aplican los patrones de especificación básicos, se puede incrementar el nivel de formación explicando cómo aplicarlos en situaciones más complicadas. Por ejemplo, se puede tomar una operación para buscar un número entero en una colección de números. Para explicar cómo especificar una operación, se toma el mismo enfoque descrito para los patrones básicos definiendo en primer lugar la colección de enteros como un conjunto de enteros y una secuencia de números enteros, respectivamente, y a continuación se explica cómo especificar la operación mediante la combinación de los patrones básicos para cada una de las abstracciones de datos. 2.5 Prácticas a través de proyectos Mientras que el entrenamiento básico es importante en la formación y el estudio de los métodos formales, no se puede olvidar brindarles a los estudiantes oportunidades para vincularlos a la Ingeniería de Software. Es decir, ellos

necesitan que se les forme en cómo los métodos formales les ayudará en la práctica del desarrollo de software, de lo contrario, tal vez con algunas excepciones, se corre el riesgo de perder la motivación por su aprendizaje o aplicación en la práctica. La manera más eficaz para esto es que los estudiantes trabajen en proyectos. Por ejemplo, después de la introducción de ejercicios masivos en fundamentos de VDM-SL, se les puede pedir que diseñen proyectos aplicativos, como la construcción de una especificación formal de un sistema de bibliotecas o de un ATM. A través de estos pequeños proyectos, ellos podrán sentir cómo construir las especificaciones formales y aspirar a que las escalen a proyectos de desarrollo de software reales. Por supuesto, esta práctica también puede dar a los estudiantes la oportunidad de encontrar la debilidad del lenguaje de especificación que estén utilizando. Por ejemplo, pueden detectar la falta de un mecanismo intuitivo en VDM para la estructuración de un sistema completo de manera estructurada. De hecho, muchas notaciones formales existentes se centran en sólo un aspecto del problema en la Ingeniería de Software e ignoran los demás, pero un proyecto de software real se tiene que hacer cargo de todos los aspectos posibles. Si un método o técnica ayuda a resolver sólo un problema a la vez que crea otros problemas en el contexto de la Ingeniería de Software, es poco probable que sea popular entre los profesionales y que lo apliquen en proyectos reales. En este sentido, es conveniente seleccionar uno que haya demostrado ser eficiente en estos aspectos, y que proporcione un proceso sistemático y riguroso para integrar las técnicas formales a las prácticas existentes de Ingeniería de Software, y que no cree más problemas. 2.6 Utilizar métodos de Ingeniería formal El objetivo final de la formación en métodos formales —FM por sus siglas en inglés— es crear la posibilidad de que los estudiantes los apliquen en la práctica. Los Métodos de Ingeniería Formal —FEM por sus siglas en inglés— muestran cómo se pueden aplicar los FM en proyectos reales. Uno de los aspectos más importantes de la FEM es el énfasis en la combinación de diagramas, notación formal y lenguaje natural en una forma coherente y sistemática para escribir especificaciones [1]. El propósito de esto es ayudarles a los desarrolladores a comprender fácilmente las especificaciones que están escribiendo y las escritas por otros. La visualización es intuitiva y adecuada para describir la idea general y la arquitectura del sistema, la notación formal se utiliza para lograr precisión en las declaraciones de la especificación, y el lenguaje natural para proporcionar una interpretación amable de las expresiones formales. En general, FM difiere de FEM en intenta responder a la pregunta qué se debe hacer y por qué en el desarrollo de software, mientras que FEM intenta responder a qué se puede hacer y cómo. Para este fin, la segunda se centra en las técnicas y los métodos para la integración de los métodos formales en todo el proceso de desarrollo de software, de manera que la fortaleza de los métodos formales se pueda utilizar en la práctica y evitar su debilidad de ser complejos. FEM facilita el cómo los sistemas software, incluyendo todos los documentos por nivel, se crean en la realidad y se expresaron

28

formalmente, y que no son simplemente una mezcla de notaciones formales con imágenes. Debido a que una introducción detallada a FEM está más allá del alcance de este trabajo, se puede consultar en [1]. De hecho, el mismo principio de los FEM también se puede aplicar eficazmente a la formación en métodos formales, porque como se mencionó antes es a través de proyectos software que se logra este objetivo. Por ejemplo, al explicar una expresión matemática, como Z = X U Y, se puede utilizar una representación gráfica como los diagramas de Venn para ilustrar la operación de unión, y al mismo tiempo usar un texto para explicar el significado de la operación. Cuando se introduce una operación en VDM, se puede dibujar un proceso para mostrar la entrada, la salida y las variables externas, pero los detalles de la función de la operación se definen mediante pre y post-condiciones. Con explicaciones informales en texto, el significado de la especificación de la operación puede ser comprendida fácilmente por los estudiantes. 2.7 Herramientas de soporte Casi todos los profesionales han experimentado el uso de herramientas para aplicar lenguajes de programación, y los estudiantes han descubierto que les son útiles para escribir, ejecutar y probar los programas, y muchos profesores de métodos formales también las aplican en sus cursos. Sin embargo, la experiencia es que se centran en técnicas de especificación formal, y sugieren que el uso de herramientas para formar en métodos formales necesariamente no es efectivo; pero tal vez sea menos eficaz no usar herramienta alguna. Existen dos razones para ello: 1) el aprendizaje de los métodos formales requiere que los estudiantes aprendan la sintaxis y la semántica del lenguaje de especificación correspondiente mediante la escritura a mano, y la manera más efectiva para que los estudiantes sean capaces de escribir especificaciones formales adecuadas es utilizando el Inglés como lengua extranjera y fortaleciendo la formación en la sintaxis y la profundización de la comprensión de las técnicas de extracción, porque de esta manera los estudiantes no tendrían ninguna posibilidad de "copiar y pegar" sin pensar por sí mismos. 2) El propósito de escribir una especificación no es la de ejecutarla directamente en el computador, sino para que las personas la lean y la entiendan. Por lo tanto, escribir a mano con un buen estilo las especificaciones formales es mucho más útil, y la herramienta se utiliza para mejorar automáticamente su estilo y formato. En el caso de la programación, sin una herramienta, por ejemplo un compilador, no se puede ejecutar el programa. Pero en el caso de escribir una especificación, no hay necesidad de ejecutar, por lo que sin un soporte de la herramienta no se van a crear mayores inconvenientes. En cambio, para algunos estudiantes que no quieren estudiar métodos formales, la herramienta de soporte les va a crear oportunidades para copiar y pegar sin pensar primero. Lo anterior no significa que el apoyo de una herramienta no sea necesario para utilizar los métodos formales en la práctica. Por el contrario, ese soporte es crucial para

mejorar de la productividad y reducir las posibilidades de errores en el desarrollo práctico. Por esta razón, es conveniente que los estudiantes utilicen una herramienta de apoyo cuando lleven a cabo un proyecto, luego de un aprendizaje sistemático de las técnicas de especificación formal. Pero aprender a utilizar debe ser una labor de trabajo independiente, es decir por fuera del aula con la asesoría del profesor; porque es necesario que él también haga parte activa de su proceso formativo y porque no es comprende cómo un profesor invierta el tiempo en el aula para enseñar herramientas. De esta manera también se logra un efecto en los estudiantes, quienes se sienten a gusto con la herramienta que seleccionaron, que saben manipular y que les ofrece una alta automatización, para la escritura y el análisis de sus especificaciones. Pero lo más importante es que han llegado a este punto luego de haber pasado por el momento difícil en el aprendizaje de utilizar los métodos formales a mano. Esto es similar a la situación en la que una persona se siente feliz cuando tiene la oportunidad de comer una deliciosa comida que ella misma ha preparado y después de un largo periodo de hambre.

2.8 Limitaciones de tiempo Los conceptos y expresiones matemáticas requieren por lo general un tiempo para que los estudiantes las digieran, por lo que la formación en ellas debe hacerse al ritmo de ellos y con muchos ejemplos y problemas aplicativos. Sin embargo, un curso es como un proyecto software: tiene limitaciones de tiempo. Es por esto que los profesores se enfrentan a un dilema: quieren cubrir contenidos que son de suma importancia para el estudio de los métodos formales, pero no tienen el tiempo suficiente para lograrlo. Para hacer frente a este problema, la experiencia sugiere que los cursos no deben ser demasiado ambiciosos, sino que se deben diseñar de forma focalizada. Por ejemplo, distribuir la formación en especificación formal, refinamiento y verificación formal en tres cursos diferentes; de esta forma el profesor se podría enfocar en cada uno de ellos en las partes fundamentales, y darles a los estudiantes el tiempo suficiente para que puedan aplicar las técnicas aprendidas. Después de terminar cada curso, pedirles estructurar y ejecutar un pequeño proyecto en el que requieran aplicar todo el conocimiento aprendido en el aula. De esta forma se les ofrece mayores oportunidades para aprender cómo aplicar los conceptos teóricos de manera efectiva en la práctica. 3. UN CURRÍCULO SISTEMÁTICO Mientras que las técnicas de enseñanza son fundamentales para una formación exitosa en métodos formales, un plan de estudios relacionado con los métodos formales, razonado y estructurado, también juega un papel importante desde una visión global de los procesos formativos. Se recomienda adoptar un plan de estudios sistemático y de paso a paso relacionado con el área; ir involucrando todos los programas y estudiantes en el departamento o facultad, que en el futuro pueda demostrar su efectividad y eficiencia entre los actores que han recibido la formación con esta visión. La propuesta es organizar el plan de estudios de la siguiente manera:

29

introducir a los estudiantes de primer año en las temáticas de los métodos formales, la matemática discreta, la lógica, la abstracción y la resolución de problemas, presentar las técnicas de especificación simples, en un lenguaje formal, a los de segundo año, las técnicas de especificación más complejas a los de tercer año, y un curso sistemático en métodos de ingeniería formales a los de cuarto año, y finalmente, llevar a los de quinto año a los laboratorios de Ingeniería de Software para aplicar las técnicas formales aprendidas en sus proyectos de grado. Todos estos cursos son electivos. A los estudiantes de posgrado se les ofrece un curso en depuración y Verificación y Validación formal, dependiendo de los cursos que tomaron en el pregrado, porque es posible que ingresen algunos que no eligieron los cursos ofrecidos durante sus estudios de pregrado. 1. El primer semestre del primer año se ofertan cursos

de introducción a la lógica computacional, la resolución de problemas, la abstracción y la algoritmia, y para los cursos del segundo se va incrementado la complejidad, se tocan los temas de métodos formales, matemática discreta, matemática computacional y pruebas de programas, y sus aplicaciones respectivas a problemas simples a través de un lenguaje de programación, el cual deben aprender en el trabajo independiente.

2. En el segundo año, primer semestre, se comienza el

trabajo en lenguajes de especificación formales, y en el segundo en pre-y post-condiciones. Los estudiantes resuelven problemas escritos en lenguaje natural, lo que les permite construir una percepción básica desde la programación y la computación, lo que facilitará la introducir de técnicas de especificación sencillas en el próximo semestre. En este proceso se aplica un enfoque paso a paso para comenzar con las especificaciones sencillas y poco a poco aumentar el grado de complicación. Después de una breve explicación, los estudiantes están obligados a comprender la mecánica de la especificación para luego ponerla en práctica en el lenguaje de programación, y finalmente aplicar casos de prueba adecuados.

3. En el tercer año, se introducen expresiones más

complejas en el lenguaje de especificación, como let, if-then-else y case, y la compuestas y los conjuntos tipos para mejorar la capacidad expresiva de la especificación formal. Se aplica el mismo estilo de trabajo utilizado en el primer y segundo año, pero a un nivel más complejo. En este año se espera que los estudiantes hayan adquirido de cuenta propia un manejo y conocimiento adecuados del lenguaje de programación tradicional.

4. En el cuarto año se oferta un curso sistemático en

métodos de ingeniería formales. Se espera que asistan muchos más estudiantes que a los cursos de los primeros años, porque parecen estar motivados por tomar cursos en nuevas tecnologías. Esto se debe a que tienen mayor conciencia de la importancia de

esta formación para su vida laboral, debido a que la industria en el mundo las exige como requisito.

5. En el quinto año, los estudiantes aplicarán los

métodos y técnicas aprendidas al modelado, el diseño, el desarrollo y las pruebas de sus sistemas software. A través de estos proyectos, adquirirán más experiencia en el uso de la notación formal y la representación esquemática mediante diagramas de flujo de datos. Se organiza a los estudiantes en grupos para que puedan experimentar cómo les pueden ayudar las especificaciones formales en la comunicación, la cooperación y la documentación de su trabajo. A pesar de que los métodos formales presentan actualmente una penetración lenta en la industria, los egresados estarán preparados en las técnicas de especificación formal para cuando se les exija su aplicación en el análisis y diseño de sistemas.

Para los estudiantes de postgrado, en maestrías o doctorados, se proponen cursos como el que ofrece el profesor Morgan en su libro [8], para que puedan aprender cómo aplicar los métodos formales durante el proceso de desarrollo. Dado que la mayoría de estudiantes que toman estos cursos no han recibido formación en Ingeniería de Software, sino en áreas como diseño, Inteligencia Artificial, aplicaciones de red, ingeniería de sistemas o bases de datos, por lo general se enfrentan a un momento difícil. Debido a que hay pocas esperanzas de que hayan aplicado los conceptos matemáticos en la práctica, suelen olvidar sus leyes específicas, aunque recuerdan algunos conceptos fundamentales o al menos su idea, lo cual les ayudará a tomar decisiones sensatas en las prácticas de desarrollos de software. 4. FORMAR A LA INDUSTRIA Muchas empresas fabrican productos como televisores, automóviles, trenes y sistemas de tránsito. Para aumentar sus funciones y reducir el costo en la mejora y el mantenimiento de los sistemas, implementan más y más funciones software. Debido a que una falla en el software de alguno de estos componentes embebidos es probable que genere la discapacidad de todo el sistema, causando molestias, frustraciones, e incluso peligro para las personas y posiblemente una gran pérdida económica para los fabricantes, muchas empresas empiezan a prestar más y más atención a los métodos formales. Pero existen muchas dificultades que se deben superar para lograr una adecuada introducción para su uso en la industria, como convencer a los ejecutivos y a los ingenieros en los distintos niveles de formar a los empleados en métodos formales, y de que apoyen las iniciativas técnicas para aplicarlos en la práctica. Es difícil imaginar la existencia de una solución uniforme para todos los problemas de todas las empresas, pero es posible encontrar diversos ejemplos en los cuales se ha tenido éxito [9-11]. Una forma de alcanzar estos objetivos podría ser como se describe a continuación. Se diseña y aplica un programa dividido en dos fases. En la primera, se logra convencer a los ejecutivos de que la

30

adopción delos métodos formales creará un gran potencial para mejorar la calidad de los sistemas y será de beneficio para la empresa; posteriormente se presenta un plan para capacitar a los ingenieros en todo lo relacionado con esta área. El plan consiste en seleccionar y capacitar a algunas personas desde los grupos relevantes, los cuales se convertirán en formadores de sus propios equipos de trabajo. Para mejorar la comprensión y poder alcanzar los objetivos trazados, el trabajo se debe llevar a cabo a través de una estrecha colaboración academia-industria. La primera tarea de este proyecto de colaboración es revisar y discutir el plan inicial de capacitación, y luego elaborar un plan eficaz de enseñanza en términos de horario, contenidos y estilos didácticos. Se programan seminarios y discusiones acerca de casos de éxito en otras industrias, para motivar a los participantes a que pueden lograr lo mismo en su empresa, y para motivar a los ingenieros y ayudarles a construir una comprensión exacta del potencial real de los métodos formales. El éxito de esta fase es fundamental para avanzar a la siguiente. La principal actividad en la segunda fase es lograr el apoyo de los ejecutivos de la empresa para incorporar a los métodos formales en un programa de capacitación sistemática de la empresa. Todo el personal técnico puede solicitar libremente el curso, incluyendo a los novatos como a los más experimentados. De acuerdo con la población objetivo, se determina de forma flexible la duración de los cursos y las técnicas didácticas a utilizar. Esto es conveniente porque la mayoría de los empleados no tuvo contacto con los métodos formales en su formación anterior, y el objetivo es concientizarlos de sus ventajas y beneficios para ellos y la industria misma. Este proceso se puede apalancar mediante la conformación de institutos spin-off al interior de las facultades, los cuales se convertirán en formadores y asesores para las empresas y garantizarán de mejor forma que los métodos formales penetren la industria y se mejore a futuro el desarrollo de productos software. 5. FORMACIÓN CONTINUA La experiencia en la aplicación y enseñanza de los métodos formales en la academia y en la industria ha demostrado que es necesaria y útil, pero eso no significa que sea muy popular entre los estudiantes. Las personas con cierta experiencia de trabajo suelen encontrar a los métodos formales y a las técnicas de especificación formal, particularmente fáciles de aprender y aplicar, pero esto puede no ser cierto para estudiantes sin experiencia laboral. Las razones más importantes son que generalmente no entienden profundamente la importancia del papel de los métodos formales en la garantía de calidad del software y que los contenidos a los que se ven expuestos son complejos. Dado que la formación en esta área es necesaria y útil, una posible solución a este problema es ofrecerlos como cursos obligatorios en lugar de asignaturas electivas. De esta manera todos los estudiantes se verán obligados a participar de la formación y a aprender métodos formales. Sin embargo, aunque esta posibilidad se convierta en realidad, no garantiza que esta área de

formación sea atractiva para ellos. Para ser atractivos, la formación en métodos formales debe lograr un buen equilibrio entre: simplicidad, visualización y precisión, y deben demostrar sus beneficios para garantizar la calidad del software y para reducir el costo de los proyectos. Además, la didáctica aplicada debe proporcionarles diversión a los estudiantes, como en la computación gráfica o la animación. Por desgracia, algunos métodos formales existentes cumplen con estos criterios, y es difícil imaginar que cualquier didáctica mejoraría significativamente la situación. Dado que el desarrollo de software necesita la aplicación de una forma matemática de pensar, no importa si los métodos formales son atractivos o no, el esfuerzo en su formación debe continuar en el mundo académico y se espera que en la industria también. Sólo procesos serios en los sistemas de formación pueden lograr que sea posible la aplicación de métodos formales en la Ingeniería de Software. 6. UN CASO DE APLICACIÓN A continuación se describe la integración de técnicas de métodos formales en un curso de posgrado en Ingeniería de Software avanzada. Las características de esta experiencia son: 6.1 Antecedentes de los estudiantes Dado que el programa de posgrado enfatiza en el reentrenamiento, los estudiantes pueden provenir de una amplia variedad de pregrados. La mayoría de las universidades tienen en sus malla curriculares algunos cursos de matemáticas, sin embargo los estudiantes o bien no han experimentado las matemáticas discretas o no las aplican adecuadamente en los proyectos que realizan en sus cursos. El curso avanzado de Ingeniería de Software requiere el dominio de unas habilidades básicas de programación y de dos cursos que cubren los temas de análisis y diseño de sistemas. 6.2 Descripción del curso El objetivo de este curso es familiarizar al estudiante con el modelo de procesos de la Ingeniería de Software: análisis de requisitos, especificación, diseño, implementación, Verificación y Validación. Dadas las limitaciones de tiempo y la falta de conocimientos del estudiante de la lógica formal, las técnicas de los métodos formales sólo se incorporan en las etapas de requisitos y de especificación. Atención se tarda en volver a introducir tanto proposicional y cálculo de predicados. Se tuvo cuidado de reintroducir tanto el cálculo proposicional como el de predicados. El esquema del curso es el siguiente: 1. Modelo de Procesos de Ingeniería Software (1

semana) 2. Análisis de Requisitos (2 semanas) 3. Cálculo Proposicional y de Predicados (1 semana) 4. Métodos Formales de Especificación: Algebraica, VDM,

y Z (5 semanas) 5. Metodologías de Diseño de Software (3 semanas) 6. Validación y Verificación (2 semanas) 7. Gestión de Proyectos Software (1 semana)

31

El texto de Somerville [12], fue seleccionado por su cobertura de las metodologías formales de especificación, y se complementó con el texto de Spivey [13], porque se seleccionó a Z como el lenguaje de especificación para aplicar en el proyecto del curso. 6.3 Didáctica del curso El método utilizado en el curso para la presentación de los métodos formales de especificación y su aplicación fue una mezcla de asesorías teóricas y de resolución de problemas. Las conferencias se utilizaron para establecer las bases de la lógica de primer orden y la estructura de las notaciones de especificaciones particulares. Para reforzar el material se presentaron ejemplos pequeños centrados en funciones independientes e individuales. Los estudiantes se dividieron en grupos de tres personas y se les instó a escribir las especificaciones de las versiones extendidas de los ejemplos pequeños. Un representante del grupo presenta la solución final, y analiza las discusiones que tuvieron lugar a raíz de las diversas soluciones que los demás miembros del grupo produjeron. Estas sesiones de discusión proporcionan una idea de lo que los estudiantes están aprendiendo el material y que están sustentando sus postulados. Se alentó a la estudiante a que buscaran todo tipo de ayuda adicional por parte pares, ya fuera al interior o por fuera de la universidad. 6.4 Proyecto de aula Los estudiantes se dividieron en equipos y cada uno eligió un líder. Cada equipo se encargó de escribir la elicitación y especificación de los requisitos, el diseño arquitectónico, y las especificaciones formales de los componentes del sistema en Z del siguiente proyecto:

Una biblioteca requiere un sistema automatizado completamente integrado que se encargue de ordenar, catalogar, editar y almacenar sus libros. Se requiere que el catálogo sea accesible a los usuarios de la biblioteca, ya sea en el sitio o de forma remota; además, que puedan reservar libros que se encuentran actualmente en préstamo al marcarlos en el catálogo de la biblioteca.

De acuerdo con el plan de trabajo, los equipos deben presentar las distintas fases del proyecto, de modo que las aclaraciones y correcciones puedan ocurrir en su vida útil. En la primera fase, la elicitación de requisitos, el sistema se analiza a partir de dos contextos: 1) el funcional, para describir los servicios que esperan los usuario y 2) el no-funcional, que incorpora tanto las limitaciones con las que debe operar el sistema como las normas que debe respectar. Los estudiantes dividen el sistema en dos grupos de usuarios independientes relacionados con la funcionalidad: los estudiantes y el personal. Para cada grupo se identifican las tareas que llevan a cabo y se tratan de concretar los detalles implícitos, como los de colocar un libro en reserva y los recargos. La segunda fase, la especificación de requisitos y el diseño de la arquitectura, contiene una descripción de las tareas que el software debe realizar, y en ella los estudiantes

escriben un prototipo funcional del sistema utilizando un lenguaje de programación. Los grupos se sentían incapaces de comprender el funcionamiento básico del sistema sin poder experimentar diferentes secuencias de interacción con la automatización. En un documento presentaron la especificación de requisitos descritos en términos de análisis estructurado. Este método incorpora el uso de diagramas de flujo y de control de flujo de datos que capturan los cuadros de diálogo de la funcionalidad. Luego de esta fase los grupos de funcionalidad se ampliaron de dos a cinco: usuarios, personal de circulación, administrador, departamento de contactos, y mantenimiento. La tercera fase, la especificación formal de los componentes en Z, fue la más extensa. Los estudiantes no tardaron en darse cuenta de que los prototipos de esquema les permitían utilizar parámetros para especializar una tarea particular para un grupo de funcionalidad particular, ya que muchos grupos compartían tareas similares. El documento resultante contenía las asignaciones y los tipos de datos que se utilizaron los esquemas. La mayoría escribió esquemas precisos y necesarios en Z. El número de páginas no se incrementó con respecto al documento anterior, sin embargo, la mayoría de grupos prefirieron la notación Z en diagramas como punto de partida para el diseño del sistema. La cantidad de tiempo utilizado en el desarrollo de esta fase fue dos veces la de la segunda. 6.5 Evaluación de resultados por el profesor La capacidad de los estudiantes y el deseo de superar el desafío fue impresionante. Fueron capaces de escribir especificaciones Z con poca o ninguna formación en matemáticas discretas, y al capturar los requisitos de un sistema software grande y complejo demostraron habilidades analíticas excepcionales. Con sólo seis semanas de asesoría, los grupos fueron capaces de capturar la funcionalidad del sistema en las especificaciones Z. Esta experiencia también ha demostrado su capacidad para incorporar fácilmente las especificaciones formales con los métodos de análisis/diseño estándar que se utilizan tradicionalmente para las especificaciones de los requisitos. En el futuro, el esquema del curso incluirá más material para escribir especificaciones. Existe una amplia brecha entre los esquemas Z simples empleados para escribir las especificaciones del proyecto, y los esquemas de los componentes de sistemas a gran escala. En un intento de salvar esta brecha, se dedicará más tiempo a la elaboración de especificaciones formales para pequeños y medianos sistemas que sean similares en estructura al proyecto asignado. También se podrá incorporar especificaciones existentes y una herramienta de verificación de prototipos [14]. Este tipo de herramientas apoya la lógica de orden superior como su lenguaje de especificación y un sistema tipo expresivo, los cuales pueden estar restringidos en una notación como la de Z, y proporcionar un demostrador de teoremas interactivo eficaz que automatizar los pasos de la prueba de bajo nivel. Los niveles de motivación de los estudiantes

32

tienden a aumentar cuando al material difícil se incorpora actividades con herramientas. 6.6 Evaluación de resultados por los estudiantes Los estudiantes consideraron de gran valor la presentación de varias técnicas formales de especificación para el aprendizaje de la notación Z. Aunque encontraron otros lenguajes formales, dedicaron el tiempo necesario para aprender y lograr experiencia con el lenguaje seleccionado. Algunos estudiantes se sentían frustrados por tener que escribir a mano las especificaciones de Z. No fueron capaces de editar y compartir fácilmente sus esquemas para compartir en las reuniones de grupo. Pero esto es necesario para lograr que mecanicen el lenguaje y su gramática. Algunos creyeron que el uso de los métodos formales proporciona un marco más riguroso para el diseño del sistema y este marco centró su atención en las fases de transición coherentes y completas de su sistema. Sin embargo, se preguntaban si los empleadores invertirían o apreciarían el valor en el desarrollo de especificaciones formales a pesar de la clara ventaja de la precisión del diseño de las especificaciones formales. Desde su limitada experiencia en las entrevistas de trabajo, opinaron que los entrevistadores no conocían qué son ni qué hacen los métodos formales. Esto causó dificultades para convencerlos de que su inversión en el aprendizaje de técnicas de métodos formales se compensaría en los empleos. 7. CONCLUSIONES La responsabilidad por la introducción de los métodos formales en el sistema formativo no sólo es un deber de la academia, la industria y el Estado, o las regulaciones y las normas, también es responsabilidad de una percepción general para reconocer a la Ingeniería de Software como una ingeniería, y aceptar que la formación respectiva carece de suficiente énfasis en matemáticas y ciencias ingenieriles. Un esquema factible de aplicar debe incluir una amplia revisión a los objetivos formativos, a los métodos y metodologías aplicados en esos procesos, a los contenidos curriculares y a las evaluaciones que se realizan a la experiencia de los profesores y su investigación y formación continua. La formación es el medio más necesario y efectivo para transferir los métodos formales a la industria del software. El factor de influencia más importante para alcanzar este objetivo es poner los procesos formativos

en el contexto de la Ingeniería de Software. En este trabajo, se han descrito varias técnicas para formar en métodos formales en ese contexto, tanto para estudiantes con y sin experiencia, y cada una es factible de probar en la práctica. No importa si los métodos formales se pueden utilizar directamente como una técnica de Ingeniería de Software efectiva en la práctica, pero sin duda una adecuada formación en ellos beneficiará las prácticas al contar con ingenieros bien entrenados y disciplinados. La única forma alcanzar la transferencia efectiva de los métodos formales a la industria es: formación, formación y formación. 8. REFERENCIAS [1] Liu, S. (2004). Formal Engineering for Industrial Software

Development Using the SOFL Method. Springer-Verlag. [2] Liu, S. et al. (1998). SOFL: A Formal Engineering

Methodology for Industrial Applications. IEEE Transactions on Software Engineering, 24(1), pp. 24-45.

[3] Collins, B.P. & Nix, C.J. (1988). The Use of Software Engineering, Including the Z notation, in the Development of CICS. Quality Assurance, 14(2), pp. 103-110.

[4] Parnas, D.L. (2001). Inspection of Safety-Critical Software Using Program-Function Tables. In Hoffman, D.M. & Weiss, D.M. (Ed.), Software Fundamentals. Addison Wesley, pp. 371-382.

[5] Sahara, S. (2004). An Experience of Applying Formal Method on a Large Business Application. In Proceedings 2004 Symposium of Science and Technology on System Verification (Osaka, Japan, Feb. 4-6), pp. 93-100.

[6] Parnas, D.L. (1990). Education for Computing Professionals. Computer, 23(1), pp. 17-22.

[7] Jones, C.B. (1990). Systematic Software Development Using VDM. Prentice Hall.

[8] Morgan, C. (1998). Programming from Specifications. Prentice-Hall.

[9] Lecomte, T. (2009). Applying a Formal Method in Industry: a 15-year trajectory. In Proceedings of the 14th International Workshop on Formal Methods for Industrial Critical Systems FMICS '09 (Eindhoven, The Netherlands, Nov. 2-3), pp. 26-34.

[10] Bicarregui, J.C. (2009). Industrial Practice in Formal Methods: a Review. Lecture Notes in Computer Science, 5850, pp. 810-813.

[11] Abrial, J.R. (2006). Formal Methods in Industry: Achievements, Problems, Future. In Proceedings of the 28th international conference on Software engineering ICSE'06 (Shanghai, China, May 20-28), pp. 761-767.

[12] Somerville, I. (2010). Software Engineering. Addison-Wesley Publishing Company.

[13] Spivey, J.M. (2001). The Z Notation: A Reference Manual. Prentice Hall International Series in Computer Science.

[14] Owre, S.; Shankar, N. & Rushby, J.M. (1996). User Guide for the PVS Specification and Verification System. Computer Science Laboratory, SRI International.

33

Software Testing as Science

La Prueba del Software como Ciencia

Ingrid Gallesdic, George Killiospy Centro Australiano de Excelencia para la Computación Cuántica y las Tecnologías de la Comunicación. Gallesdic(AT)cqt.edu.au

INFORMACIÓN DEL ARTÍCULO Tipo de artículo: Reflexión Historia del artículo Recibido: 27-03-2013 Correcciones: 28-05-2013 Aceptado: 10-06-2013 Categories and Subject Descriptors K.6.3 [Management of computing and information systems]: Software Management – Software process. General Terms Computer Science, Software Engineering, Software Testing. Keywords Software testing, scientific method, experiments, hypothesis. Palabras clave Prueba del software, método científico, experimento, hipótesis.

ABSTRACT The most widespread opinion among people who have some connection with software testing is that this activity is an art. In fact, books have been published widely whose titles refer to it as art, role or process. But because software complexity is increasing every year, this paper proposes a new approach, conceiving the test as a science. This is because the processes by which they are applied are the steps of the scientific method: inputs, processes, outputs. The contents of this paper examines the similarities and test characteristics as science. RESUMEN La opinión más ampliamente difundida entre las personas que tienen alguna relación con la prueba del software es que esta actividad es un arte. De hecho, se han publicado libros de amplia difusión cuyos títulos se refieren a ella como arte, oficio o proceso. Pero debido a que la complejidad del software se incrementa cada año, en este artículo se propone un enfoque nuevo, concebir a las pruebas como una ciencia. Esto se debe a que los procesos mediante los cuales se aplican siguen los pasos del método científico: entradas, procesos, salidas. En el contenido del presente trabajo se analizan las semejanzas y características de la prueba como ciencia.

© 2013 IAI. All rights reserved.

1. INTRODUCCIÓN La prueba de software ha sido descrita como un arte [1], un oficio [2], y un proceso [3], pero en este artículo se presenta un concepto un poco diferente: la prueba de software como ciencia. En las comunidades de software comercial, las pruebas del software fueron vistas alguna vez como una idea de último momento. Los gerentes de producto novatos e incluso los desarrolladores las consideraban como una disciplina fuera de foco, que casi cualquier persona podía realizar. Incluso, algunos libros de divulgación sobre el tema incluyen en sus títulos palabras como arte y oficio [1,3], lo que puede haber llevado a algunas personas en la industria a la conclusión de que las pruebas para la calidad no eran una verdadera disciplina de la Ingeniería de Software. Por el contrario, la prueba efectiva es una disciplina de esta ingeniería y un componente crítico del ciclo de vida del desarrollo de software, cuyo objetivo es ayudar a mejorar la calidad y fiabilidad del producto mediante la identificación de defectos, la prevención de errores, y la observación y presentación de reportes.

Esencialmente, la prueba proporciona información para un análisis de riesgos racional y analítico [4]. En este trabajo se presenta una comparación entre los procesos de la ciencia y las pruebas de software. Es un análisis reflexivo en el que se busca mejorar la imagen de los procesos que se aplican para mejorar la calidad y fiabilidad de los productos software. Somos una sociedad que depende ampliamente del software, por lo que todos los aportes que ayuden a mejorar estos aspectos en sus productos deben tratarse y difundirse, porque el objetivo es que cada vez los usuarios puedan tener acceso a aplicaciones de mejor calidad. 2. EL MÉTODO CIENTÍFICO El método científico tradicional ha sido el método predominante para las personas observar y comprender el funcionamiento del mundo y el universo. En los últimos años, algunos científicos han desarrollado métodos que son menos rigurosos [5], pero el tradicional [6] es el que se utiliza como base para este artículo. El algoritmo de este método es:

RACCIS, 3(1), 33-37, 2013

Revista Antioqueña de las

Ciencias Computacionales y la Ingeniería de Software

ISSN: 2248-7441

www.fundacioniai.org/raccis

raccis@fundacioniai.org

34

1. Observar algún aspecto del universo 2. Inventar una teoría que sea consistente con lo que se

ha observado 3. Utilizar la teoría para hacer predicciones 4. Probar esas predicciones con experimentos o nuevas

observaciones 5. Modificar la teoría de acuerdo con los resultados 6. Volver al paso 3. Existen diferentes puntos de vista entre los científicos de hoy en cuanto a lo que constituye una teoría, una hipótesis y un hecho, y de cómo se definen estos términos depende su visión de la ciencia. Exponer plenamente los diferentes puntos de vista acerca del método científico y cómo se definen los términos es una cuestión que está más allá del alcance de este trabajo. Sin embargo, es importante entender que a menudo hay un nivel de sesgo, porque las personas aceptan las definiciones, acerca de cómo funciona el mundo, siempre que sean coherentes con sus creencias. Este es un razonamiento circular, porque si se trata de explicar cómo y por qué sucede algo, esto está basado en cierto grado en un marco en el que ya se cree [7], por lo que uno de los grandes retos de la ciencia es mantener la objetividad. Con el propósito de enmarcar las definiciones que se utilizan en este artículo a continuación se describen algunos términos, aunque puede ser que no sean aceptadas totalmente. Observación. Es el acto de reconocer y notar algún

hecho u ocurrencia en la naturaleza, como una aurora, una corona, o la estructura de un animal. Específicamente, es el acto de medir, con instrumentos adecuados, cierta magnitud, como el tiempo de una ocultación con un reloj, la ascensión recta de una estrella con un instrumento de tránsito y un reloj, la altura del sol o la distancia a la luna desde una estrella con un sextante; la temperatura con un termómetro, etc.. Es la información así adquirida. Nota: Cuando un fenómeno es analizado como una ocurrencia en la naturaleza, el acto se denomina una observación, y cuando las condiciones en las que se produce el fenómeno son artificiales, o han sido dispuestas de antemano por el observador, el proceso se denomina un experimento. El experimento incluye a la observación.

Experimento. Es un ensayo u observación especial, hecha para confirmar o refutar algo dudoso; es un acto u operación realizada con el fin de descubrir algún principio o efecto desconocido, o para probar, establecer, o ilustrar alguna sugerencia o verdad conocida; es un examen práctico; es una prueba.

Hipótesis. Es una suposición, una proposición o

principio que se supone o se da por sentado, con el fin de llegar a una conclusión o inferencia para probar el punto en cuestión; algo que no se ha probado, pero que se asume para el propósito del argumento, o para contar un hecho o un acontecimiento, como la hipótesis de que los vientos de proa detienen un barco. En Ciencias Naturales, es una teoría tentativa o suposición adoptada provisionalmente para explicar

ciertos hechos, y para orientar en la investigación de otros, por lo que con frecuencia se llama hipótesis de trabajo.

Presunción. Lo que supone; un postulado o

proposición asumida; una suposición. Teoría. Es una doctrina o esquema de cosas, que

termina en especulación o contemplación, sin una visión práctica; es una hipótesis; es una especulación. Es una exposición de los principios generales o abstractos de cualquier ciencia. Es ciencia a diferencia del arte. Es una explicación filosófica de los fenómenos, ya sea física o moral.

Hecho. Es un efecto producido o logrado; cualquier

cosa sucedida o que va a pasar; es un acto; es un evento; es una circunstancia. Es una realidad; una actualidad; una verdad. La afirmación o declaración de un acto realizado o existente

Ley. En filosofía y física, es una regla de ser, operar o

cambiar, con certeza o confirmación, algo que se concibe como impuesto por la voluntad de alguna autoridad de control, como la ley de la gravedad, la leyes del movimiento, las leyes del pensamiento, las leyes de causa y efecto, la ley de la auto-conservación. En matemáticas, es la regla según la cual nada procede. En las artes, el trabajo o los juegos, son las reglas de construcción, o de procedimiento, establecidas para lograr el éxito.

3. LAS PRUEBAS COMO CIENCIA Algunos métodos de prueba se llevan a cabo al nivel de la ciencia basura, porque a menudo se basan en pequeñas muestras y experimentos mal controlados o documentados [8]. En el desarrollo de software esto se suele llamar demo, y se lleva a cabo para ejecutar el software con casos de prueba construidos y que se sabe de antemano que funcionan. Por el contrario, las pruebas rigurosas se basan en la observación de la diferencia entre el comportamiento real y el comportamiento esperado del software bajo prueba (la hipótesis). Las pruebas se deben ver como Verificación (probar contra las especificaciones) y como Validación (probar contra el mundo real), y ambas son necesarias porque las especificaciones no siempre son perfectas. Esto se debe a que el software es similar a una hipótesis científica, y ambos son inherentemente falibles. El marco básico del proceso de depuración del software es similar a la práctica del ensayo y error que insinúan las hipótesis científicas. El software es una simple conjetura técnica. A través de pruebas rigurosas los ingenieros de prueba tratan de refutar la presunción de un software sin defectos, destinadas sobre todo a demostrar la existencia de los mismos (falsificación). El proceso de falsificación contrasta con los enfoques basados en datos, como la inducción y la deducción, que intentan justificar la validez basada en la repetición de los hechos. La mayoría de enfoques justificativos tratan de soportar las peticiones a través de la confirmación, y de esta forma confirman ante

35

todo los esfuerzos para validar la incertidumbre sin errores utilizando datos específicos que demuestren un funcionamiento correcto [9]. Este enfoque claramente demuestra que el software sólo funciona correctamente bajo ciertas condiciones, pero no prueba que el software está libre de errores. Los aspectos científicos de las pruebas del software son: 3.1 Pre-definición de los resultados esperados Pre-definir los resultados esperados en la prueba es similar al científico que predice el resultado de un experimento, antes que se lleve a cabo, mediante la propuesta de una hipótesis. Hay algo acerca de predecir el resultado de antemano que añade un grado de rigor a los hallazgos: si se espera hasta que el experimento haya terminado para tratar de interpretar los resultados, a la luz de la comprensión y la observación, es fácil convencerse a sí mismo y a los demás de que lo observado fue una validación de la hipótesis, porque después de todo se consideraron todas las cosas. Cuando los resultados reales del experimento no coinciden con los resultados esperados pre-definidos, la discrepancia puede llevar a cuestionar el experimento, la hipótesis, o a ambas. 3.2 Observación Sin la observación es imposible determinar el resultado de una prueba o experimento. Aunque esto tiene sentido, es tentador diseñar pruebas y experimentos que sean difíciles, si no imposibles, de observar. Es posible que se desee comprobar o probar algo, pero las limitaciones del mundo real dificultan la construcción de un experimento exacto. Es por eso que no se puede probar todo, porque no todo es comprobable. 3.3 Repetitividad En ciencia, un experimento se puede realizar miles de veces antes de poder establecer una tendencia. La primera vez que un científico observa un resultado no está seguro de si se debió a un aspecto desconocido del experimento o a un comportamiento predecible del objeto, por lo que para proporcionar una confirmación del experimento puede ser necesario repetirlo muchas veces. Del mismo modo, cuando en las pruebas se observa un defecto, la primera prueba puede ser vista como el indicador y las siguientes como la confirmación. Después que un defecto ha sido corregido, la prueba se debe repetir exactamente como antes de encontrarlo, para así asegurar que se ha superado. Aunque esto suena simple, en la práctica puede ser muy difícil obtener un segundo entorno de prueba configurado exactamente como en el primero. 3.4 Construir el Experimento En la investigación científica, los experimentos son cuidadosamente planificados y controlados. El ambiente del laboratorio surgió de la necesidad de probar las condiciones durante un experimento y poderlo repetir nuevamente. En esta analogía de las pruebas como ciencia, muchas personas parecen realizar los experimentos en la cocina, no en un entorno de laboratorio controlado. Esta es una cuestión crítica, porque el entorno de la prueba puede afectar muchos

factores externos e internos de la misma, que podrían dar lugar a resultados erróneos. Se puede afirmar que en ninguna otra disciplina se podrían hallar resultados con los métodos simples que muchos utilizan en las pruebas del software, especialmente cuando se trata de los entornos [10]. En las pruebas, a veces se necesitan entornos cuidadosamente construidos y controlados para obtener el nivel de confiabilidad adecuado al riesgo. ¡La prueba es tan buena como el entorno de la misma! 3.5 Realizar el experimento La realización del experimento es un ejercicio en el que se sigue cuidadosamente el diseño previo. El científico investigador no improvisa a menos que esté trabajando por fuera del plan. Por supuesto, algunos de los grandes descubrimientos científicos se han producido porque el investigador intentó algo más que no estaba planeado, pero son excepciones más que reglas. En las pruebas, es importante apegarse a al plan de pruebas. Está bien probar otros casos, pero se debe documentar el proceso para, si es necesario, poderlo repetir. 3.6 El grupo de control En los experimentos científicos, los grupos de control se utilizan como una línea base para comparar los resultados. Por ejemplo, un investigador podría probar un fármaco de prueba en un grupo de personas, mientras que administra un placebo a otro grupo. Las personas en el experimento no saben si se les ha suministrado el medicamento real o el placebo. Esta investigación doble ciego ayuda a contrarrestar los prejuicios subconscientes. En la prueba también se tiene como referencia una línea base del funcionamiento correcto del sistema. Interpretar los resultados y llegar a conclusiones es uno de los grandes desafíos de la ciencia, y consiste en observar la prueba de una hipótesis y hacer una interpretación razonada de los resultados. El reto de hacer esta tarea es mantener la objetividad y tener el valor de reportar lo que realmente se observó, como algo contradictorio a lo que se esperaba ver. Eso suena bastante familiar para algunas ciencias [11]. En las pruebas, sólo se puede hablar de lo que se observa, y no es realista ni prudente predecir resultados de lo que podría ser visto a partir de pruebas no realizadas. 3.7 Modificar la hipótesis A menudo la hipótesis principal en las pruebas es que el sistema debe funcionar en determinadas condiciones. Sin embargo, existe otra hipótesis opuesta según la cual, aunque el sistema funciona, necesariamente no que quiere decir que no tiene defectos. La segunda hipótesis es la más segura. Cuando los resultados de las pruebas demuestran que la segunda hipótesis es verdadera, entonces comienza a producirse un cambio fundamental en las mentes y actitudes de las personas que trabajaron con la primera hipótesis. Esto sucede cuando, en lugar de modificar la hipótesis, se trata de desacreditar o invalidar el experimento, y a menudo consiste en culpar a los probadores de los defectos, que es lo mismo que culpar a un científico por los resultados de la investigación, aunque haya llevado a cabo el experimento correctamente.

36

Sin embargo, suponga por un momento que las personas llegan a un acuerdo de que la primera hipótesis era incorrecta y que el software tiene defectos que necesitan ser determinados. Esto puede implicar que se entregue el software y esperar a que otros tengan que rendir cuentas. Aunque se puedan producir estas consecuencias, las personas tienen que enfrentar la realidad y corregir los problemas en lugar de centrarse en sus propias agendas. Tal vez este aspecto de la prueba está más estrechamente alineado con la ciencia que se practica actualmente [4]. Si la investigación confirma la hipótesis, se hace amplia difusión del suceso, pero si la investigación confirma la hipótesis contraria, especialmente una que resulta ser políticamente incorrecta, los resultados pueden no ser publicados. 3.8 Visión a largo plazo La razón por la que se realiza investigación científica es para explicar la forma en que se comporta la naturaleza observable. Se ha dicho que lo que distinguía a Thomas Edison de otros inventores era que siempre tenía un agudo sentido de cómo la ciencia podía ayudarles a las personas a mejorar sus vidas. También tenía un buen sentido de los negocios, y sabía cuándo dejar de investigar para construir el proyecto. En las pruebas, el objetivo inicial es encontrar defectos, sin embargo, esta es una visión miope y desaprovecha los recursos que han sido invertidos en la creación y fijación del defecto. La visión a largo plazo de la prueba consiste en construir formas para evitar problemas similares en el futuro, mediante la mejora de los procesos utilizados para fabricar el producto. Al parecer estamos lejos de ver las pruebas como un proceso científico, pero nos da algo para pensar y relacionar, especialmente cuando se trata de evaluar el rigor y la fiabilidad de los resultados de las pruebas. 3.9 Creatividad Aunque algunos pueden considerar a las pruebas de software como un arte, la única similitud es que implica una gran dosis de creatividad. Se podría argumentar que la prueba de un programa computacional a gran escala requiere más creatividad que su diseño. Myers [1] respalda esta teoría al afirmar que la prueba es una tarea extremadamente creativa e intelectualmente desafiante. De hecho, muchas personas que diseñan y desarrollan software admiten que se encuentra más satisfacción estética en la creatividad de las pruebas. 3.10 Visión filosófica Desde el principio de los tiempos, los seres humanos han participado de las pruebas en diversas formas, ya fuera al cuestionar los diseños de herramientas o al criticar los procesos. Esta constante re-evaluación dio lugar a una mejor calidad y a ganancias significativas en eficacia y eficiencia. Pero la prueba basada puramente en ensayo y error es laboriosa y lenta. Karl Popper [12] aborda el crecimiento del conocimiento desde un proceso más científico, y plantea la hipótesis de que la ciencia progresa mediante la reducción de la falsedad. Esencialmente, el progreso se logra mediante la conversión de teorías (conjetura - razonamiento que implica la formación de conclusiones a partir de pruebas incompletas) en hipótesis

comprobables (refutaciones - alguna evidencia que ayude a establecer la falsedad de algo). 3.11 Establecer confianza La mejor forma para establecer la confianza en la fiabilidad del software no es sólo demostrar que funciona dentro de los límites de la especificación del producto, sino también al exponer los defectos potenciales en el diseño o la funcionalidad del mismo. Sin embargo, cualquier conjetura puede consumir muchas horas de exhaustivas pruebas y todavía contener errores. La refutación no garantiza un software impecable, porque simplemente hay demasiadas hipótesis para poner a prueba en un plazo razonable de tiempo. William Hetzel [13] explica la futilidad de las pruebas exhaustivas y las limitaciones de la refutación, y opina que existen más casos de prueba en un programa con 70 funciones que cucharaditas de agua en el Océano Pacífico. Cuando un probador refuta con éxito el software (encuentra un error), informa el defecto; entonces, el desarrollador (con suerte) resuelve el problema, por lo que se supone que el software funciona correctamente, y el proceso de refutación se repite. Aunque la prueba no puede demostrar que el software está libre de errores, detectar errores demuestra problemas, lo que en última instancia se traduce en mayor fiabilidad y calidad del producto, o al menos ofrece una perspectiva fundamental para el análisis y la mitigación de riesgos. 4. QUÉ HACE REALMENTE UN PROBADOR Cuando se le pide a los ingenieros de pruebas que describan su trabajo, la mayoría responde: quebrar el software. Tal vez por eso algunas personas consideran erróneamente al papel del probador como un proceso destructivo. Sin embargo, los probadores realmente no rompen software, simplemente exponen los errores que ya existen, al refutar o falsear el supuesto de que el software es impecable a través de los resultados que observan, luego de aplicar pruebas estructuradas, de deducción lógica y de experimentos. Sin embargo, los errores que encuentran sólo son un aspecto de las pruebas; los ingenieros de pruebas realmente lo que hacen es agregar valor al proceso de desarrollo mediante la validación del software, la detección de errores, proporcionándoles a los desarrolladores información para evitar errores y a la administración para evaluar el riesgo, y actuando como defensores de los clientes. Entonces, ¿qué cualidades debe tener un gran probador de software? James McCaffrey [] las reduce a ocho: 1. Pasión por el análisis y las pruebas 2. Habilidades técnicas 3. Capacidad Intelectual pura 4. Capacidad para priorizar y organizar 5. Capacidad de adaptación y aprendizaje 6. Capacidad para trabajar sin supervisión directa 7. Capacidad para comunicarse 8. Capacidad para comprender la estrategia de negocios Como los sistemas software aumentan en complejidad, el valor de las pruebas de software se está incrementando y convirtiendo en una actividad cada vez más importante.

37

5. CONCLUSIONES Existen muchos puntos en común entre las pruebas del software y la ciencia tradicional. De hecho, las primeras pueden estar más cerca de la ciencia que cualquier otra cosa que podamos relacionar. Estas similitudes pueden ser útiles para su comprensión y para explicarlas a otros. Las similitudes también proporcionan un punto de referencia de la rigurosidad del proceso que se utilizan en la definición y realización de los procesos de prueba. Aunque no es necesario que cada prueba se realice con el rigor de la investigación científica, algunas sí requieren ese nivel, especialmente las de productos de alto riesgo. Al igual que en la ciencia, en las pruebas de software se buscan respuestas correctas. O bien el producto cumple con los requisitos o no lo hace. A través de pequeños pasos incrementales las pruebas se aproximan a la verdad sobre el software. El objetivo es entregar el software con el menor número de errores posible, para que el usuario reciba un producto fiable y de calidad.

6. REFERENCIAS [1] Myers, G. (2004). The Art of Software Testing. John Wiley

& Sons. [2] Marick, B. (1995). The Craft of Software Testing -

Subsystem Testing Including Object-Based and Object-Oriented Testing. PTR Prentice Hall

[3] Perry, W.E. (2006). Effective Methods for Software Testing - Includes Complete Guidelines, Checklists, and Templates. Wiley.

[4] Lensmar, O. (2013). The new science of software testing. Online [Feb. 2013].

[5] Lehrer, J. (2010). The Truth Wears Off - Is there something wrong with the scientific method? Online [Mar. 2013].

[6] Platt, J.R. (1964). Strong Inference - Certain systematic methods of scientific thinking may produce much more rapid progress than others. Science, 146(3642), pp. 347-353.

[7] Chomsky, N. (2011). How the World Works. Soft Skull Press.

[8] Agin, D. (2006). Junk Science - How Politicians, Corporations, and Other Hucksters Betray Us. Thomas Dunne Books.

[9] Cerrosen, J. & Pong, J. (2012). Science in Computational Sciences. RACCIS, 2(2), pp. 12-20.

[10] Eickehnann, N. & Richardson, D. (). An Evaluation of Software Test Environment Architecture. In Proceedings of the 18th international conference on Software engineering ICSE’96 (Berlin, Germany, March 25-26), pp. 353-364.

[11] Serna, M. E. Social Control for Science and Technology. In Larrondo, M. et al. (Eds.), Proceedings 10th Latin American and Caribbean Conference for Engineering and Technolog LACCEI'12, (Panama City, Panama, July 23-27), paper 35.

[12] Popper, K. (2002). Conjectures and Refutations. Routledge. [13] Hetzel, W. (1988). The Complete Guide to Software

Testing. QED Inforíation Sciences. [14] McCaffrey, J. (2008). What Makes A Good Software Tester?

Online [Jan. 2013].

38

The Interview as an Approach to Elicit Requirements

La Entrevista como Enfoque para Elicitar Requisitos

Luz Marina Iriarte Centro de Investigación en Ingeniería de Software del Oeste Americano. Luziriarte(AT)rcseaw.com INFORMACIÓN DEL ARTÍCULO Tipo de artículo: Investigación Historia del artículo Recibido: 15-01-2013 Correcciones: 15-05-2013 Aceptado: 20-05-2013 Categories and Subject Descriptors K.3.2 [Computers and Education]: Computer and Information Science Education – Computer science education. General Terms Computer Science, Requirements Engineering. Keywords Requirements elicitation, interviews, techniques, methods. Palabras clave Elicitación de requisitos, entrevistas, técnicas, métodos.

ABSTRACT In many software projects requirements elicitation is incomplete or inconsistent. One issue that works for this is presented has to be with the requirements engineers use a single method to do it, which can cause a deficiency in the expected results. Among the factors contributing to the success of this stage of the life cycle is an adequate selection of the elicitation technique and other approaches needed. This article describes an experimental study to elicit requirements, in which was applied a combination of methods and techniques, and discusses the advantages of doing it this way. The results obtained allow concluding that to achieve adequate elicitation is necessary to combine several techniques and methods. RESUMEN En muchos proyectos software la elicitación de requisitos es incompleta o inconsistente. Una cuestión que colabora para que esto se presente tiene que ver con que los ingenieros de requisitos utilizan un sólo método para hacerlo, lo que puede causar deficiencia en los resultados esperados. Entre los factores que contribuyen al éxito de esta etapa del ciclo de vida se encuentra una adecuada selección de la técnica de elicitación y de otros enfoques necesarios. En este artículo se describe un estudio experimental para elicitar requisitos, en el que aplicó una combinación de métodos y técnicas, y se analizan las ventajas de hacerlo de esta manera. Los resultados obtenidos permiten concluir que para lograr una elicitación adecuada es necesario combinar varias técnicas y métodos.

© 2013 IAI. All rights reserved

1. INTRODUCCIÓN El objetivo de la mayoría de técnicas o herramientas de elicitación de requisitos es reducir la ambigüedad de éstos y mejorar su claridad. Sin embargo, sólo unas cuantas pueden soportar correctitud, coherencia e integridad de los requisitos, a la vez que le hacen frente a la ambigüedad. Los métodos cara-a-cara, como las entrevistas, se centran en capturar los requisitos adecuados, y no tanto en resolver esta última. En consecuencia, la formación de grupos focales está diseñada para ayudar a elicitar los requisitos de los usuarios con mucha más claridad y para eliminar inconsistencias. Otras herramientas, como los diagramas de flujo, los procesos de negocio, la documentación, los manuales de usuario, los organigramas, los modelos de procesos y sistemas y las especificaciones de procesos, ayudan y apoyan a los desarrolladores y diseñadores cuando traducen los requisitos lógicos en ayudas visuales que muestran las etapas y secuencias. Del mismo modo, mientras que los métodos basados en la acción y las

técnicas de observación, como el análisis in situ, los estudios de mercado y el análisis de competencias, se concentran en reducir la ambigüedad, se enfocan menos en elicitar requisitos apropiados. Asegurar la completitud y correctitud de los requisitos es importante para el equipo de desarrollo, porque de esta manera puede desarrollar un sistema que responda adecuadamente a los deseos y necesidades de los usuarios. Desafortunadamente, elicitar los requisitos del negocio es un proceso que consume mucho tiempo, tanto para los analistas de negocio como para los usuarios. Aplicar métodos como el prototipado y utilizar casos ayuda a comprobar los requisitos, en lugar de reducir la complejidad de los requisitos de negocio y los tecnológicos. Ninguno de estos métodos es bueno para delinear la integridad y para asegurar su exactitud.

De otro lado, la mayoría de analistas de negocios o desarrolladores de software afirman que prefieren utilizar sólo las entrevistas como técnica para elicitar requisitos, porque son fáciles de aplicar y por su

RACCIS, 3(1), 38-42, 2013

Revista Antioqueña de las

Ciencias Computacionales y la Ingeniería de Software

ISSN: 2248-7441

www.fundacioniai.org/raccis

raccis@fundacioniai.org

39

conveniencia para los usuarios y para ellos mismos. Sugieren utilizar técnicas múltiples cuando una sola no da lugar a requisitos claros. En el contexto de la literatura de la Ingeniería de Requisitos se han discutido ampliamente las ventajas y desventajas de aplicar una sola técnica, sin embargo, pocos han investigado los resultados de aplicar cada técnica individualmente durante la elicitación. El objetivo de este artículo es profundizar en los resultados de aplicar una sola técnica en la Ingeniería de requisitos, la entrevista, e investigar enfoques que sean eficaces en la elicitación de requisitos de negocios completos y consistentes. Para alcanzar este objetivo, este trabajo se estructura de la siguiente manera: en la sección

dos se discuten los trabajos relacionados; en la tercera se describe el experimento y se presenta el esquema de cómo se utilizaron los métodos aplicados; la cuarta contiene los resultados preliminares, y en la quinta se sugieren futuras investigaciones. 2. TRABAJOS RELACIONADOS Los investigadores Davey y Cope [1] proporcionan información en el área y presentan una tabla interesante de dificultades, que toman de Tsumaki y Tamai [2] como base para realizar un estudio sobre los problemas de la elicitación de requisitos. Sugieren 22 fuentes de dificultades diferentes, las cuales se detallan en la Tabla 1.

Tabla 1. Dificultades con los requisitos

Requisitos incompletos Comprensión incompleta de las necesidades

Conocimiento del dominio incompleto Pobre colaboración de los usuarios

Supuestos tácitos Requisitos incorrectos

Límites del sistema mal definidos Malentendido del propósito del sistema

Requisitos ambiguos Términos sinónimos y homónimos

Términos incomprobables Consideraciones de diseño innecesarias

Requisitos inconsistentes Intenciones no sólidas de los solicitantes

Diferentes usuarios con diferentes puntos de vista Requisitos no fijados

Requisitos fluctuantes Aceptación continua de requisitos adicionales

Requisitos excesivos Fuentes de información voluminosas y no organizadas

Demasiados solicitantes Exceso de compromiso por parte del personal de ventas

Otros autores han reportado problemas adicionales entre los que se incluyen atributos desconocidos [3], requisitos de usuario mal definidos [4], mala comprensión de las necesidades de los usuarios [5], requisitos de usuario difíciles de entender por el equipo de desarrollo de software, y requisitos del usuario incorrectos que conducen a confusiones en los desarrolladores. De todos los factores considerados, el mayor impacto proviene de los requisitos de usuario ambiguos, lo que incrementa la exposición de un proyecto a diferentes riesgos [6]. Desde una perspectiva de mantenimiento del software, Chua et al. [7] describen requisitos de usuario iniciales poco claros que conducen necesariamente a cambios durante la prueba y el mantenimiento. En otras palabras, el esfuerzo por el re-trabajo aumenta debido al cambio de requisitos, y como resultado, se incrementa el costo del mantenimiento del software.

Los métodos y técnicas de Ingeniería de Requisitos formales se desarrollaron con el objetivo de resolver los problemas de los requisitos. Davis et al. [8] mencionan que las entrevistas son la técnica más popular para recopilar requisitos, pero que no son la técnica individual más eficaz. Frey y Oishi [9] definen a las entrevistas como un medio para lograr la comprensión de un tema en particular, y como un medio de comunicación y de intercambio de información en el que una persona hace preguntas preparadas ―entrevistador― y otro las responde ―entrevistado―. Los estilos de entrevistas son variados y cada uno tiene su propio efecto individual, que puede tener un impacto significativo en la recopilación de requisitos.

En el campo de los requisitos de software [5], técnicas como la lluvia de ideas, el prototipado, la clasificación de tarjetas, las entrevistas y las metodologías ágiles [10-15] son eficaces como apoyo a la elicitación de requisitos. Estas técnicas son importantes cuando se realizan en el ámbito académico, y pueden ayudar a promover el aprendizaje mediante el fomento de la socialización y la interacción entre los estudiantes, sin embargo, necesariamente no soportan la completitud de los requisitos. Aunque se han introducido diversas técnicas, los analistas de negocios terminan eligiendo las entrevistas, porque son simples, implican pocos pasos, y son eficaces para recolectar requisitos estructurados. El otro argumento es que la entrevista ha sido calificada por los profesionales como una de las técnicas más eficaces para elicitar requisitos [8].

Decidir aplicar una técnica individual o combinar varias para elicitar requisitos depende del enfoque utilizado y de cada situación en particular. Algunas son adecuadas para extractar factores, variables o nombres, mientras que otras se requieren para seleccionar opciones, o tomar decisiones de soporte y priorización; por ejemplo, con el fin de organizar qué son los requisitos de usuario Chia y Okamoto [16] entrevistaron usuarios mediante la aplicación de un enfoque basado en modelado, con el objetivo de modelar sus experiencias y participación en una actividad o situación, y para identificar factores en los requisitos que se pudieran utilizar para desarrollar un sistema. Firesmith [17] destacó que si bien las entrevistas pueden ayudar a reducir los conflictos y la priorización de los requisitos entre las partes interesadas, no hacen frente a los requisitos incompletos o incorrectos.

40

La forma en que se utiliza la entrevista no está diseñada para corregir requisitos incompletos e inconsistentes. Muchas veces se escucha a los analistas de negocio que han capturado suficientes requisitos de usuario, pero luego se descubre que no son tan precisos como deberían ser. La pregunta de fondo es ¿cuál es el método más eficaz para que los entrevistadores eliciten requisitos, especialmente en situaciones donde se sabe implícitamente que éstos no están explícitamente claros? 3. EL EXPERIMENTO A los estudiantes en un curso de pregrado se les pidió que leyeran un corto escenario y luego construyeran un diagrama con las inquietudes, opiniones y expectativas de las partes interesadas acerca del uso de un nuevo sistema de información. Se trata de un escenario común en la práctica donde los buenos requisitos son importantes. En particular, un equipo de desarrollo de software necesita información explícita acerca de los requisitos de usuario o del sistema para construir una solución apropiada. Por desgracia, en la realidad, los requisitos de usuarios no son constantes y se debe esperar que los cambios surjan continuamente, por lo que antes de implementar adecuadamente los cambios en los requisitos, es necesario comprender los efectos y analizar el cambio con el fin de determinar las consecuencias sobre el alcance del proyecto y el impacto sobre otros requisitos. Para fomentar el entusiasmo de los estudiantes que realizan el experimento, se les informó que cada uno jugaría dos roles: 1) como analista de requisitos, responsable de recogerlos desde las partes interesadas y 2) como parte interesada, cuya responsabilidad es proporcionar los requisitos para el analista. El propósito de este experimento es investigar los efectos de las técnicas de elicitación que utilizan los estudiantes. Se formaron grupos de trabajo de entre cinco y seis integrantes para llevar a cabo discusiones y para participar en la actividad de Ingeniería de Requisitos. Se les indicó que podían utilizar cualquier técnica de elicitación de la que fueran conscientes. Sobre esta base, no se les dio ninguna instrucción detallada acerca de

cómo elicitar y recolectar los requisitos. Al final de la actividad, se les pidió que presentaran sus resultados mediante la construcción de un diagrama. Una semana más tarde, se distribuyeron cuestionarios para la complementación; una de las preguntas de la encuesta indagaba acerca de cómo recogieron los requisitos desde los diferentes grupos. 87 de los 90 estudiantes completaron la encuesta y regresaron al análisis. La investigación incluía explorar los efectos de una técnica en particular aplicada en un contexto determinado, y qué tipo de efectos se logran luego de aplicarla de forma individual y combinada. Como era de esperar, muchos estudiantes optaron por utilizar la entrevista como la única técnica de elicitación de requisitos. Desde la perspectiva del tiempo, una posible razón es que cualquier otra técnica necesitaría más tiempo del que disponían, porque debían reunir los requisitos y completar el ejercicio en un día. Otra razón es porque la entrevista les permite interactuar cara-a-cara y lograr una buena comunicación con los otros estudiantes. Este hallazgo sustenta los resultados en [8], de que la entrevista es la técnica de elicitación más comúnmente utilizado en la práctica. En la Tabla 2 se relacionan los estudiantes que utilizaron una sola técnica y un único enfoque. El 63% discutió el problema como grupo y desarrollaron entrevistas con preguntas abiertas, antes de acercarse a otros grupos, a lo que se denominó método 1. El 15% dijo que discutieron el problema en su grupo y desarrollaron entrevista con preguntas cerradas, lo que se llamó método 2. El 14% dijeron que discutieron el problema como grupo y que desarrollaron entrevistas con preguntas cerradas, sin embargo, no llevaron a cabo entrevistas en grupo, sino que cada uno se encargó individualmente de entrevistar a cada jugador de rol en los otros grupos, lo que se llamó enfoque 3. El restante 8% dijo que discutieron el problema como grupo y no desarrollaron ninguna pregunta para la entrevista, sino que se acercaron a cada grupo y le pidieron a cada jugador de rol que os retroalimentara, a este se llamó enfoque 4.

Tabla 2. Respuestas de los estudiantes que utilizaron una sola técnica

Enfoque Número Discutimos como grupo y desarrollamos entrevistas con preguntas abiertas

55 63%

Discutimos como grupo y desarrollamos entrevista con preguntas cerradas

13 15%

Discutimos como grupo y desarrollamos entrevista con preguntas cerradas, y luego nos encargamos individualmente de entrevistar a cada jugador de rol en los otros grupos

12 14%

Discutimos como grupo y no desarrollamos ninguna pregunta para la entrevista, luego le pedimos a cada jugador de rol en cada grupo que nos retroalimentara

7 8%

La mayoría de estudiantes aplicó los enfoques 1 y 2, porque: 1) las preguntas son fáciles de desarrollar y no requieren mucho tiempo para pensar de forma crítica y 2) las preguntas que construyeron se centraron en el contexto objeto y no el contenido en sí. Estos resultados confirman los de [8], donde se afirma que las entrevistas

estructuradas reúnen más información que las no estructuradas, y que éstas reúnen más que las técnicas de selección y clasificación. Curiosamente, las entrevistas no estructuradas parecen reunir más información que la técnica de pensar en voz alta.

41

El hecho de que la entrevista como técnica individual fuera la más seleccionada es interesante para aprender de los grupos que utilizaron más de un enfoque. Los dos enfoques combinados, elegidos con menor frecuencia por los estudiantes, fueron 1-3 y 1-2-3-4. Aunque muy pocos grupos optaron por utilizar enfoques combinados, el resultado no parece afectar los resultados de la investigación. La preocupación fundamental es identificar qué enfoque es más eficaz en la elicitación de requisitos implícitos, que sean explícitamente comprensibles para los analistas de negocios, y útiles para reunir requisitos completos y coherentes para un sistema propuesto. Los estudiantes que participaron en el experimento se habían graduado recientemente de la escuela secundaria y estaban en su primer año universitario. La mayoría no tenía experiencia en la industria, y sólo algunos poseían algún conocimiento en el tema. A pesar de la falta de experiencia en la elicitación de requisitos para un proyecto de desarrollo de software, eran conscientes que se requiere la evaluación de otros actores, lo que les obliga a realizar trabajo de campo y acercarse a la industria para que los requisitos recolectados sean buenos y completos. Como resultado, la técnica de la entrevista fue la que se utilizó más comúnmente. Quince grupos presentaron sus diagramas para revisión; en dos de ellos la información recogida era una coincidencia cercana a la solución. Se realizó un análisis de contenidos para agrupar y clasificar las respuestas ejemplo, lo que ayudó a entender por qué algunos requisitos elicitados eran incompletos o inexactos. Se encontraron cuatro métodos que utilizan comúnmente los analistas de negocios como base para elicitar requisitos cuando entrevistan, de los cuales se cree que tienen un efecto sobre la integridad y la exactitud de los requisitos: 1) basado en factores, que se definen como atributos, propiedades y valores utilizados para describir los requisitos, 2) basado en prioridades, que se refiere a la numeración y secuencia de los requisitos en función de su importancia, 3) basado en elección, que define los requisitos que se incorporan con el de factores y el de priorización, y 4) basado en integración, que se refiere a una combinación de los otros métodos. En la Tabla 2 se muestra claramente que los grupos que desarrollaron entrevistas con preguntas abiertas entrevistaron a otros grupos ―método 1―. Un par de estudiantes diseñaron preguntas para la entrevista, y las refirieron en los diagramas que presentaron. Con base en sus diagramas y la información proporcionada en la Tabla 2, se observa que muchos de los requisitos de los diagramas se reunieron a partir de los roles y se presentaron como factores. Las preguntas de las entrevistas no-estructuradas les permitieron presentar diagramas consistentes de factores heterogéneos ―diferentes tipos―, atributos y variables de las necesidades de las partes interesadas y de sus puntos de vista. Para el enfoque 2 se revisaron las preguntas estructuradas y las respuestas en los diagramas, y se identificaron los requisitos recogidos y se clasificaron de acuerdo con el factor. Los factores para el enfoque 1 y el 2

son de un mismo tipo. Más específicamente, los factores, atributos y variables son homogéneos. En este enfoque, los grupos desarrollaron entrevistas con preguntas cerradas antes de dirigirse a otro grupo para entrevistarlo. Ninguno de los enfoques aplicados en las entrevistas demostró eficacia para suministrar información completa sobre el sistema requerido. Los grupos que utilizaron el enfoque 3 mantuvieron conversaciones en grupo y desarrollaron entrevistas con preguntas cerradas. Sin embargo, no realizaron entrevistas en grupo, sino que asignaron miembros individuales para que entrevistaran a los jugadores de rol en los otros grupos. Esto significa que cada miembro del equipo entrevistó a otro jugador de rol particular en cada grupo. Por ejemplo, un analista de negocio entrevistó a otros 6 jugadores, cuyo rol era de comprador. Después que se recogió la información de los compradores, el analista de requisitos agrupa y prioriza lo que considera importante. Los diagramas que presentaron revelaron que la información presentada se centra en un enfoque basado en prioridades. Este enfoque parece mostrar que los analistas de negocios contralaban bien la situación y decidieron que lo que mejor encajaba era utilizar palabras clave para describir a las partes interesadas, sus preocupaciones y sus puntos de vista. El enfoque muestra efectos inconsistentes con respecto a la validación de la completitud de los requisitos de las partes interesadas en el mismo rol. Al revisar los diagramas presentados se observa que proporcionan números al lado de cada requisito. Al parecer, intentaron insinuar el nivel más adecuado de cada uno, sin embargo, cuando clasificaron la importancia de cada requisito, los numeraron de acuerdo con cada nivel de importancia. El enfoque 4 fue el único sin ningún trabajo de preparación real. Dos grupos eligieron esta técnica y la información presentada por las partes interesadas demuestra falta de trabajo en equipo. Los diagramas de los grupos que utilizaron métodos combinados 1 y 3 presentaron las necesidades y puntos de vista de las partes interesadas con base en el método basado en opciones. Curiosamente, a nivel de grupo, reunieron información con base en los factores, y a nivel individual, recogieron palabras clave similares y luego las priorizaron. Con base en las decisiones que reunieron, seleccionaron la que mejor encajaba. Sus respuestas resultaron ser muy similares a las del curso ejemplo. El otro enfoque combinado utilizado fue 1, 2, 3 y 4. Los diagramas que muestran las necesidades y opiniones de las partes interesadas son interesantes pero algo complicados. A esto se le llamó basado en integración. Se puede interpretar como que algunos de los miembros en el grupo fueron asignados a diferentes enfoques. Para sorpresa, esta técnica también coincidió con el ejemplo solución. En resumen, el objetivo de aplicar los enfoques basado en factores y basados en prioridad para elicitar requisitos es

42

ampliar y afinar las dimensiones de un problema al nivel superficial, en el contexto de una situación particular, para que los analistas de negocios puedan evaluar menos la completitud de los requisitos. La aplicación de entrevistas combinando las técnicas basadas en la elección y basadas en la integración dio como resultado un enfoque más limitado, lo que a su vez se tradujo en requisitos más consistentes y completos. 4. CONCLUSIONES Y TRABAJO FUTURO El objetivo de este experimento tuvo dos momentos: 1) alentar a los analistas de negocios, o a los estudiantes que necesitan elicitar requisitos, a que no se limiten a un enfoque estándar. Por ejemplo, enfoques que se utilizan para factorizar o dar prioridad a los requisitos importantes. Los enfoques basados en integración y en elección raramente permiten descubrir o discutir requisitos eficaces e integrales, que pueden estar más allá de lo que se espera. 2) Proporcionarles a los analistas de negocios, con o sin experiencia, algunas ideas acerca de que el problema en las entrevistas no se debe a la técnica, sino la necesidad de centrarse en los enfoques que se están utilizando. Este documento hace dos contribuciones: 1) al conocimiento de la elicitación de requisitos, en el sentido de que a pesar de que la técnica de la entrevista es sin duda muy popular y conocida, a menos que se utilice con los enfoques adecuados, el efecto sobre la recogida de requisitos estará incompleto y 2) no se debe asumir que identificar requisitos, a través de enfoques basados en factores y en prioridad, es una elección adecuada para identificar requisitos completos y coherentes, al menos así lo demuestran los resultados en el experimento. Los enfoques basados en la elección y en la integración muestran signos alentadores de ser más adecuados en un contexto de elicitación de requisitos. El trabajo futuro incluirá la investigación de los enfoques en un caso de estudio del mundo real, relacionado con empresas de investigación de mercados que quieren retroalimentar la elicitación y las necesidades de clientes nuevos y experimentados, con el fin de que puedan clarificar su enfoque. 5. REFERENCIAS [1] Davey, B. & Cope, C. (2008). Requirements Elicitation –

what’s missing? Issues in Informing Science and Information Technology, 5(1), pp. 543-551.

[2] Tsumaki, T. & Tamai, T. (2006). Framework for matching requirements elicitation techniques to project

characteristics. Software Process Improvement and Practice, 11(5), pp. 505-519.

[3] Hickey, A.M. & Davis, A.M. (2003). Requirements elicitation and elicitation technique selection – A model for two knowledge-intensive software development processes. In Proceedings of the 36th Annual Hawaii International Conference on System Sciences, HICSS’03 (Hawaii, Jan. 6-9).

[4] Kotonya, G. & Sommerville, I. (1998). Requirements Engineering - Processes and Techniques. John Wiley and Sons.

[5] Beck, K. (2000). Extreme Programming Explained: Embrace Change. Addison-Wesley.

[6] The Standish Group. (1995). The CHAOS Report. Online [Jan. 2013].

[7] Chua, B.; Bernardo, D. & Verner, J. (2008). Criteria for estimating effort for requirements changes. In Proceedings 15th European Conference of Software Process Improvement, EuroSPI, (Dublin, Ireland, Sep. 3-5), pp. 36-46.

[8] Davis, A; Dieste, O; Hickey, A; Juristo, N. & Moreno, A.M. (2006). Effectiveness of requirements elicitation techniques: Empirical results derived from a systematic review. In Proceedings of the 14th IEEE International Requirements Engineering Conference, (Minnesota, USA, Sep. 11-15), pp. 176-185.

[9] Frey, H. & Oishi, S.M. (1995). How to Conduct Interviews by Telephone and in Person. Sage Publications.

[10] Ambler, S.W. (2002). Agile Modelling - Effective Practices for eXtreme Programming and the Unified Process. John Wiley and Sons.

[11] Coughlan, J. & Macredie, R.D. (2002). Effective communication in requirements elicitation - A comparison of methodologies. Requirements Engineering, 7(2), pp. 47-60

[12] Merwe, A. & Kotze, P. (2007). Criteria used in selecting effective requirements elicitation procedures. In ACM Proceedings of the Annual Research Conference of the South African Institute of Computer Scientists and Information Technologists on IT Research in Developing Countries (Sunshine Coast, South Africa, Sep. 30 – Oct. 03), pp. 162 - 171

[13] Cockburn, A. & Highsmith, J. (2001). Agile software development: The people factor. Journal of the Business of Innovation, 34(11), pp. 131-133.

[14] Kotonya, G. & Sommerville, I. (1996). Requirements Engineering with Viewpoints. BCS/IEE Software Engineering Journal, 11(1), pp. 5-18

[15] Vonk, R. (2002). Prototyping: The Effective Use of CASE Technology. Prentice Hall.

[16] Chia, Y. & Okamoto, M. (2009). The Method of User’s Requirement Analysis by Participation of the User: Constructing an Information System for Travelers. Lecture Notes in Computer Science, 5619, pp. 862-868.

[17] Firesmith, D.G. (2004). Prioritzing requirements. Journal of Object Technology, 3(8), pp. 35-47.