Aspectos Sociales y Éticos de la Ingeniería de Software

Marcelo Aliaga Quezada
Universidad de Talca – Facultad de Ingeniería Camino Los Niches S/N, Curicó, CHILE Phone: (+56 9) 2157368 marcelo@aliaga.cl

Abstract
Este paper orienta desde tres perspectivas el tema de lo social y lo ético en la Ingeniería de Software. Se analiza conceptualmente la ética y la ingeniería de software como construcción humana. Posteriormente se aborda el tema desde dos Códigos Éticos de organizaciones relacionadas al área. También analiza en detalle el proceso de Ingeniería de Software en cada una de sus etapas, para finalizar con un análisis a lo ético y social desde la perspectiva de las metodologías de desarrollo.

2. Marco General
Para hacer mención a conceptos que por lo general se encuentran en el campo de las ciencias sociales más que de las ciencias exactas, cabe comenzar por mantener un marco general que nos de una referencia conceptual en cuanto nos referimos a conceptos como la ética. De forma similar, para dar un marco común al concepto de Ingeniería de software, se explica lo anterior como una acción humana con todo lo que ello conlleva.

2.1. Ética y acción humana 1. Introducción
El software es una creación humana. Como toda creación realizada por humanos, tiene factores que la afectan directamente: intereses, motivaciones, estados de ánimo y formación tanto social como técnica de quienes forman parte de esta obra. La ingeniería de software ha definido etapas en las cuales el proceso de creación se atomiza. En cada una de ellas los factores sociales y éticos cobran especial relevancia, dado que de ellas depende el éxito o fracaso que finalmente tenga el proyecto que se realice. Como la complejidad humana hace que el análisis de su acción sea una difícil tarea, se ha dividido el tema en los siguientes aspectos: Marco general de entendimiento, en donde se aborda a la ética y acción humana e Ingeniería de Software por separado. Continuando, se analizan de forma detallada dos Códigos Éticos más relevantes en la literatura del área, que son ACM y IEEE. Enseguida se desarrolla el tema desde las Perspectivas sociales y éticas en cada una de las etapas del proceso de Ingeniería de Software y Las Metodologías de desarrollo de software desde la ética. El concepto de ética, que proviene del griego antiguo ethos usado en su origen como costumbre, hábito, el que es frecuentemente confundido con el concepto de moral. Como primera distinción fundamental en este trabajo, se establece que la ética además de tener mayor amplitud como concepto, se ocupa de fundamentar racionalmente la moral, que es definida como conjunto de valores, normas y costumbres de un individuo o grupo humano determinado. Una doctrina ética elabora y verifica afirmaciones o juicios. Esta sentencia ética, juicio moral o declaración normativa, es una afirmación que contendrá términos tales como 'malo', 'bueno', 'correcto', 'incorrecto', 'obligatorio', 'permitido', referido a una acción o decisión. Cuando se emplean sentencias éticas se está valorando moralmente a personas, situaciones, cosas o acciones. [1] Desde otro punto de vista, la ética podemos verla como un concepto más amplio que el de moral. La moral, puede entenderse como aquel comportamiento que es basado en nuestro entorno y asumido sin cuestionamiento, por lo mismo es frecuente que se le asocie a las premisas religiosas. A diferencia de la moral, la ética implica un libre examen y pensamiento activo en lo relacionado al comportamiento. La ética y la moral no son excluyentes, son asociables aunque la ética es considerada como la moral con mayoría

de edad debido a que se puede ver como una evolución basada en el pensamiento y reflexión. Toda acción humana tiene una dimensión ética. Todo comportamiento es susceptible de ser analizado con distinciones de valor. El software es una creación humana. Todo acto humano tiene lugar en el lenguaje. Todo acto en el lenguaje trae a la mano el mundo que se crea con otros en el acto de convivencia que da origen a lo humano; por esto, todo acto humano tiene sentido ético [2]. Por encontrarnos con una creación humana, podemos entender que este sentido ético existe. 2.2. Ingeniería de software La ingeniería del software es el establecimiento y uso de principios robustos de la ingeniería a fin de obtener económicamente software que sea fiable y que funcione eficientemente sobre máquinas reales. Estos principios, al igual que en la mayor parte de las ingenierías, cuentan con un proceso que los cohesiona, estandariza y ordena, en donde se distinguen las etapas de factibilidad, elicitación de requerimientos, diseño, implementación, pruebas y mantención [3]. Como se señaló anteriormente, el software es una creación humana, por lo mismo la disciplina que se encarga de su estudio y elaboración tiene asociada una componente ética.

para sancionar o penar a quien no cumpla con las declaraciones que contiene, sino que pretende una actitud ética por parte de quienes a el se adscriben. En ambas piezas, se aprecia un interés por definir al ingeniero no solo como un humano con competencias técnicas al interior de un equipo definido, sino que intenta reflejar el rol de ente social activo con las consiguientes responsabilidades que se desprenderán de sus actos profesionales. 3.1.1. Código Ético ACM En cuanto al Código Ético elaborado por la Association for Computing Machinery (ACM), es posible constatar un detalle profundo [4]. Además de abordar aspectos netamente profesionales, define minuciosamente aspectos de comportamiento, tales como “ser justo”, “evitar el engaño” o “respetar la intimidad”, recomendaciones conductuales que de alguna forma pueden considerarse inatingentes de tratar en un código ético enfocado a lo profesional. De cierto modo inclusive podría realizarse el símil entre el texto señalado, con libros de fe como La Biblia, El Corán, La Torá o El Talmud, conservando las proporciones, claro está. Este código cuenta de cuatro grandes áreas: Imperativos Morales, Responsabilidades profesionales específicas, Imperativos organizacionales y Cumplimiento del código. En perspectiva comparada, vemos que este código cuenta con muchas más solicitudes de cumplimiento a quienes se reconocen como miembros de ACM a diferencia de lo que sucede con los miembros de IEEE como se analizará en el apartado siguiente. Vemos por ejemplo que en cuanto a los Imperativos Morales detalla ocho postulados frente a uno de la IEEE. En cuanto a las Responsabilidades profesionales específicas, la coincidencia es amplia y existe consistencia entre los tópicos que ambas abordan. Cabe preguntarse entonces que hace que aparezcan diferencias entre los códigos éticos de ambas entidades mundialmente reconocidas. Una respuesta posible la encontramos en su campo de acción. Mientras que ACM aúna profesionales relacionados con el área computacional e informática, la IEEE abarca un mayor campo de acción. Expuesto de otra manera, vemos que además de profesionales del área computacional, la IEEE, incluye entre sus integrantes a profesionales relacionados con la electrónica, eléctrica, física, y otras disciplinas relacionadas. Además de esta respuesta, vemos que ambas entidades tienen historias disímiles. Mientras una es

3. Códigos éticos
Un código ético es un documento consensuado elaborado por integrantes de una organización en particular, con el fin de que sus integrantes tengan una guía o parámetros de comportamiento al cual acudir en momentos de dudas o cuestionamientos éticos o simplemente para adoptarlo como una opción profesional permanente. En cuanto a códigos éticos relacionados con la Ingeniería de Software tenemos dos esenciales provenientes de las dos organizaciones mundialmente reconocidas del área, como son la ACM y la IEEE, los que pasamos a analizar a continuación. 3.1. Comparativa de códigos éticos: ACM y IEEE Tanto la IEEE como la ACM poseen un código ético que da a sus miembros pautas o lineamientos del como actuar en su vida profesional, es decir, norma desde un punto de vista simbólico el proceder y comportamiento en lo laboral y lo social. Un código ético no se elabora solo

fundada en el siglo XIX (IEEE, 1884), la otra es fundada en el siglo XX (ACM, 1943), en periodos históricos claramente opuestos. Mientras que la IEEE gozaba del auge de la revolución industrial en su creación, en donde el desarrollo de la técnica era central y de gran cantidad de recursos científicos y económicos, la ACM aparece en el periodo de post segunda guerra mundial y comienzo de guerra fría. Este periodo, en donde la desconfianza hace presa también del mundo técnico y científico, fundamenta la creación detallada de un código que no de lugar a dudas o segundas interpretaciones. Vemos entonces que los códigos éticos actuales vistos como una evolución de los de aquellas épocas simplemente son un reflejo de la época en la que fueron creados. Si bien es cierto, dichos códigos han evolucionado, mantienen las premisas esenciales. 3.1.2. Código Ético IEEE En cuanto a la IEEE, en su código ético aprobado en última instancia en Enero de 2006, llama a sus miembros a reflexionar acerca de cómo la tecnología afecta al entorno, solicitando asumir como una obligación personal, una conducta profesional altamente ética [5]. Entre sus principales postulados, el código ético de la IEEE solicita a sus miembros:  Aceptar la responsabilidad en la toma de decisiones que afecten al entorno, ya sea en su salud, seguridad y bienestar, dando a conocer con prontitud los factores que puedan ponerlos en peligro tanto a ellos como al medio ambiente. Mejorar la comprensión de la tecnología por la gente, así como su aplicación adecuada y consecuencias que se desprendan de su uso.

 

Ser honestos y realistas al exponer estimaciones basadas en los datos disponibles Rechazar sobornos en todas sus formas

En el caso de los tres postulados anteriores, se expone el problema ético en su máxima expresión: ¿Qué hacer ante conflictos de intereses? ¿Que hacer si la estimación no es correcta? ¿Solo el dinero es soborno?, ante necesidad económica del profesional o de su empresa, ¿se aceptará lo anterior?  Mantener y mejorar las competencias técnicas y emprender tareas tecnológicas para otros, solamente si se tiene el entrenamiento o experiencia adecuada o después de exponer las limitaciones técnicas propias del ejecutor. Buscar, aceptar y ofrecer la critica honesta al trabajo técnico, reconocer y corregir errores y aporte de trabajo de los demás.

Ambas premisas corresponden al ámbito netamente laboral y técnico. Tienen como trasfondo el entender que la formación profesional no es una labor únicamente individual, sino que también es fruto de un trabajo en conjunto, producto quizá de errores o de un aprendizaje colaborativo que crea finalmente competencias nuevas.  Dar un trato equitativo a todas las personas, independiente de raza, religión, género, discapacidad, edad u origen nacional. Evitar lastimar a otros, a su propiedad, reputación, o trabajo por acciones falsas o maliciosas – Ayudar a los colegas y compañeros de trabajo en su desarrollo profesional y apoyarlos en seguir este código ético

Como se aprecia y se detalló anteriormente, la simpleza del Código Ético de la IEEE probablemente haga dudar al lector acerca de si su campo de competencia es realmente suficiente como para ser efectivo como guía de comportamiento.

Desde un inicio la organización toma en consideración que el trabajo afecta a terceros e intenta salvaguardar posibles efectos negativos en ellos o en el ambiente. Desde un punto de vista formal, reconoce la existencia del otro y la preocupación por él. Sitúa al ingeniero dentro de un contexto social y otorga el valor que requiere. El primer postulado de este código ético reconoce la acción social, al igual que el segundo que se ha agrupado desde dicho punto de vista social  Evitar y poner en antecedentes cuando existan conflictos de intereses.

4. Perspectivas sociales y éticas presentes en las etapas del proceso de ingeniería de Software
La ingeniería de software podemos dividirla etapas definidas como factibilidad, elicitación de requerimientos, diseño, implementación, pruebas y mantención 4.1. Factibilidad

Durante esta etapa se reconoce el contexto, stakeholders, intereses y motivaciones de los clientes y usuarios, así como el dominio que aborda la solución pedida. Se analizará en la etapa de Elicitación de Requerimientos tanto a los Stakeholders como al tiempo y al precio. En esta etapa, uno de los puntos más importantes desde la ética es por una parte entregar toda la información ajustada a la realidad que la solución requiere. La tentación en esta etapa inicial del proceso suele ser tanto por el precio y tiempo, como por la no declaración de falta de competencia para emprender la tarea encomendada. Tanto o más falto de ética será entonces aceptar llevar a cabo una solución sin estar preparado y sin haber declarado esa falta de declaración al cliente. Por cierto que ante dicha falta, es posible incurrir en nuevas acciones poco éticas como dejar de identificar requerimientos a propósito o simplemente crear una solución que no será útil al cliente o a los usuarios. 4.2. Elicitación de Requerimientos La frase de von Neumann: “No tiene sentido en ser preciso cuando aún no se conoce de lo que se está hablando”1 expresa con claridad el motivo por el cual muchos proyectos de software han fracasado. Resolver el problema correcto depende en gran medida de conocer cabalmente cuál es el problema. Es por ello que la Elicitación de Requerimientos apunta a mejorar la forma en que se comprende un problema para luego definir el sistema de software adecuado. [4] La esta fase es sin dudas una de las más importantes dentro del la creación de software. En ella el ingeniero de software entiende el contexto donde su aplicación cobrará vida, quienes se verán afectados por su trabajo, que es lo que el cliente y los usuarios esperan de su trabajo y finalmente entender al otro. A su vez en esta primera etapa del proceso de desarrollo de software el ingeniero de software comienza a verse enfrentado a dimensiones sociales y éticas en las que debe desenvolverse en el proyecto. La primera de ellas y quizá una de las más relevantes en el proceso son los stakeholders. 4.2.1. Los Stakeholders Cada sistema que requiera una solución por parte de los ingenieros de software, estará formado por humanos. Quien pide es un humano. Quien se compromete y contrata, también lo es. Quien dice que es lo que requiere, es parte fundamental de esta danza conversacional que tiene como objetivo una solución exitosa. Desde un punto lingüístico, la elaboración de un software es un pedido [5], y como tal requiere de ciertas

componentes para que sea exitoso su logro. Una de aquellas condiciones es que el pedido sea sincero. Este gran pedido, que es la pieza de software, esta formado por pequeños pedidos llamados requerimientos, los cuales son definidos por los stakeholders implicados en el dominio del pedido. Pues bien, nos vemos enfrentados a solicitar o valorar aquel requerimiento o pedido como sincero o no, lo que sin duda es una gran interrogante dado que por lo general el cliente o los stakeholders no tienen absoluta claridad en lo que requieren, o bien, basan sus requerimientos en intuiciones fundadas en la experiencia previa en su contexto. Este proceso no es simple, sobre todo, en el bien entendido que un proceso de elicitación de requerimientos está compuesto por un periodo de iteraciones que desencadenará un documento final de requerimientos que será la base para las consiguientes acciones del proceso de Ingeniería de Software.

4.2.2. Los Plazos En base a la experiencia previa, o a un detallado análisis, el ingeniero luego de contar con una documentación de requerimientos puede definir con cierta certeza, el tiempo que requerirá para realizar la pieza de software. Cabe preguntarse en este momento ¿el tiempo que se declare, debe ser efectivamente el estimado? El análisis de esta cuestión puede entenderse de dos maneras. Por una parte, el cliente siempre requerirá lo antes posible la solución. Por otra, desde el punto de vista del ingeniero de software, necesita entregar una solución completa y de calidad que no ponga en riesgo ni su trabajo ni el del contexto en donde la solución será utilizada. Hay quienes señalan que a la estimación realizada debe de agregarse un porcentaje de tiempo razonable (del orden del 20%) por si el proyecto sufriera demoras o inconvenientes que lo retrasaran.

4.2.3. El Precio Al igual que en el caso de los plazos, el precio también es estimable de una forma mas certera al fin de esta etapa. La pregunta ahora es ¿Cuánto vale la solución? ¿la solución vale lo que nos cuesta realizarla?¿la solución vale lo que al cliente le será de utilidad?. Criterios pueden ser múltiples al momento de intentar responder a los cuestionamientos señalados anteriormente. Algunos de ellos pueden ser desde la técnica pura o desde el conocimiento del mercado en donde nos desenvolvemos. No obstante el criterio a utilizar, la decisión final la tiene un humano, el que responderá a diversos estímulos que le harán aplicar la tarifa que decida con las consiguientes ganancias, riesgos o pérdidas.

4.3. Diseño e Implementación En cuanto a estas etapas, vemos que posiblemente no existan grandes problemáticas éticas, mas, cuando entramos poco a poco al terreno del desarrollo del software, comienzan a aparecer los distintos elementos de la personalidad de los integrantes del equipo encargado de crear la pieza de software. La confianza en el trabajo realizado por ejemplo por un equipo independiente que haya realizado el proceso de elicitación de requerimientos consta de una de aquellas fortalezas éticas y sociales dentro del proceso de elaboración de aplicaciones. Lograr un diseño que complique innecesariamente al equipo que posteriormente, también será tarde o temprano un punto de conflicto social interno que debe gestionarse y obviamente considerarse como un riesgo, sobre todo si de expertos se trata, ya que por lo general dentro de la organización el gurú suele aislarse como un ente casi místico gracias al conocimiento que por lo general le cuesta transmitir. 4.4. Pruebas Las pruebas y la calidad dentro del software exigen honestidad, respeto por el trabajo del otro y sentido constructivo de la crítica. Cuando testeamos una aplicación o parte de ella, debemos trabajar entendiendo que detrás existe un humano que puso esfuerzo y que, si no realizó bien la tarea, estará dispuesto a realizar un esfuerzo por lograrlo. En cambio si apreciamos por un lado que no se respeta el trabajo del otro, o que no existe un deseo por superar las deficiencias del trabajo realizado, el proceso se verá predestinado al fracaso o al menos a demoras indeseables, incumplimientos en presupuesto o descoordinación. La claridad, confianza, certeza, respeto y apoyo serán conductas éticas que deban primar entonces para lograr éxito en la tarea. 4.5. Mantención Al igual que en las primeras etapas, en la etapa de Mantención es posible negociar nuevamente tarifas asociadas al software. Nuevamente también se requiere fijar plazos, volviendo a los problemas éticos analizados al comienzo de este ciclo. El proceso de Ingeniería de Software sin duda es una ardua labor en la que se mezclan diversos factores, siendo los éticos y sociales junto con los técnicos los más relevantes. Por lo mismo es fácil notar que existe un vínculo claro entre dichos conceptos con el éxito que

tenga en el proceso la labor encomendada. Visto de otra manera, los riesgos asociados a estos aspectos fundamentalmente humanos, disminuyen mientras trabajemos en un ambiente en armonía, disposición, respeto y esfuerzo.

5. Metodologías de desarrollo de software
En la actualidad existen al menos dos grandes metodologías de desarrollo de software que se encuentran entre las más utilizadas por diversos motivos. Cabe preguntarse entonces si la aplicación de una u otra metodología afecta en el ámbito ético relacionado con el desarrollo del software. Las metodologías a las cuales se hace mención son las Metodologías Tradicionales y las Metodologías Ágiles.Ambas tienen diferencias significativas, pero un objetivo similar. Se ha considerado relevante entonces, estudiar la problemática ética asociada a ambas metodologías. 5.1 Metodologías tradicionales Las metodologías tradicionales dada su estructura y poca versatilidad mantienen en gran parte del tiempo ocupado al equipo en documentación y otros aspectos que le alejan de la posibilidad de sociabilizar en el trabajo que realizan [6]. El trabajo en conjunto que se realiza con el cliente suele limitarse a reuniones formales en donde pautas preparadas por lo general, guían la interacción, llevando la conversación a un área netamente profesional. En cuanto a la comunicación que se encuentra en este tipo de metodologías, vemos que las entregas de prototipos y captura de requerimientos suele ser a menudo la mayor opción a lograr de algún modo la sociabilidad. Al no tener cercanía con quien es el cliente, el grado de cercanía será casi nulo, lo que al momento de enfrentarse a un dilema ético puede ser más difícil de enfrentar. Visto de otra forma, el tiempo de decisión ante el dilema será mayor al igual que la probabilidad de optar por una vía éticamente discutible. 5.2 Metodologías ágiles En el caso de las metodologías como XP, Scrum, Crystal y otras, dentro de su modelo de interacción con stakeholders, en donde por lo general el cliente pasa a ser parte esencial del equipo de desarrollo, esto contribuye a que pueda lograrse entender a fondo al cliente, pero a su vez, a lograr sociabilizar mas allá del mero trabajo. Lazos de confianza y convivencia van creando un ambiente mas

propicio para lograr un producto que en definitiva sea útil para quien lo necesita. Por lo general los comportamientos éticos positivos los mostramos a quienes más estimamos, a quienes mas afectos les prodigamos o bien en quienes mas confiamos. Es poco frecuente ver actos poco éticos entre miembros de un hogar por ejemplo. Finalmente, la cercanía social entre quienes dan vida a esta obra humana llamada software es un pilar de equilibrio para no solo propender un alto nivel ético y una mejor convivencia.

inquietud de si será adecuado considerar este comportamiento por ejemplo de forma explícita al momento de elaborar requerimientos no funcionales. Ciertamente parecería extraño agregar este tipo de requerimientos que frecuentemente se asume como natural, sin que necesariamente lo sea. La falta de literatura que contemple la unión de la Ética con la Ingeniería de Software, no permite poder realizar nuevas interpretaciones de resultados de estudio o papers específicos, lo que por una parte limita llegar a fondo en el tema y por otra permite posibilidades de continuar desarrollando esta investigación con un enfoque más sistemático y ordenado. La relación entre ética y éxito final del proyecto no ha sido documentada. La relación en este caso no es directa dado que un bajo nivel ético puede lograr sin embargo un software exitoso. Se concluye que la formación valórica es relevante por si misma no solo en esta labor, sino en los diversos contextos en los que el lector pueda desempeñarse.

6. Conclusiones
Ciertamente la capacidad técnica es importantísima al momento de realizar cualquier trabajo de ingeniería. La formación en específico del área del software como el área ingenieril es una de las piedras que forman la base de esta catedral. No obstante lo anterior, un punto altamente importante es la formación humana ética de quienes componen un equipo de ingenieros de software. La creación de códigos éticos entrega parámetros que sirven de guía al momento de verse enfrentado a conflictos éticos, más aún en un mundo en donde es más frecuente contar con equipos en donde la multidisciplinariedad profesional se hace presente, la que sumada a la posible diversidad cultural nos da un marco común de entendimiento. Los códigos éticos profesionales deberán contener tópicos relacionados al tema de discusión, dado que parametrizar el comportamiento ajeno al ámbito profesional hace que exista preocupación por temas que no necesariamente competen al mundo profesional. La cercanía entre el equipo técnico hacia dentro, y junto con el cliente y stakeholders es esencial para lograr una mayor comunicación y confianza que aumente por una parte la probabilidad de que sea un proyecto exitoso, como también propender un ambiente en donde el comportamiento ético no sea ausente. A más cercanía, mayor cuidado; a mayor cuidado, mayor ética. Se concluye que dada la cercanía que se alcanza en el proceso, alguna Metodología Ágil proveerá de un contexto ético mayor. La ética es frecuentemente asumida como un comportamiento estándar al momento de establecer una relación tanto dentro del equipo como con agentes externos como cliente o usuarios. Queda abierta la

7. Referencias
[1] WIKIPEDIA (2007, Diciembre). Enciclopedia Virtual Wikipedia. Wikipedia Website. [Online]. Disponible: http://es.wikipedia.org [2] MATURANA, Humberto. El árbol del Conocimiento: Las bases biológicas del entendimiento humano. 18va edición. Santiago, Editorial Universitaria, 2006. [3] SOMMERVILLE, Ian. Ingeniería del Software. 7ma edición. Madrid, Pearson Educación, 2005. [4] ACM Council (1992, Octubre). ACM Code of Ethics and Professional Conduct. ACM Website. [Online]. Disponible http://www.acm.org/about/code-of-ethics. [5] IEEE Board of Directors (2006, Febrero). IEEE Code of Ethics. IEEE Website. [Online]. Disponible: http://www.ieee.org/portal/pages/iportals/aboutus/ethic s/code.html. [4] DOHORN, Jorge. Comprendiendo el Universo del Discurso Futuro con Escenarios. WER-02, Valencia, España, 2002. [5] ECHEVERRIA, Rafael. Ontología del Lenguaje. 5ta edición. Santiago, Dolmen Ediciones, 1998. Capítulo III, Los actos lingüísticos básicos, p. 69-105

[6] PRESSMAN, Roger. Ingeniería del Software, Un enfoque práctico. 5ta edición. Madrid, Mc Graw – Hill, 2002.

Sign up to vote on this title
UsefulNot useful