dilemas profesionales y éticos en ingeniería de software

11
Dilemas profesionales y éticos en Ingeniería de Software Los autores identifican, categorizan y nombran nueves dilemas específicos, éticos y profesional en ingeniería de software, poniéndose en el contexto de la IEEE del código de conducta, con la esperanza de que tal comportamiento al tener un nombre aumente la conciencia y disminuya la frecuencia en la que ocurren estos dilemas. Humanos, han estado en la ingeniería de las cosas por cientos de años, y durante todo este tiempo se han enfrentado en esencia a los mismos retos éticos que hemos señalado en otra parte. Entonces, ¿qué hace que la ingeniería de software sea muy diferente?. La ingeniería de software es una disciplina con las que muchas personas no están familiarizadas y donde las cuestiones y los problemas son más fáciles de detectar con antelación. Por lo tanto la gente tiene que confiar en los expertos de ingeniería de software aún más que en los expertos en otros campos de ingeniería. Los ingenieros de software a menudo se involucran en el comportamiento poco profesional o ético sin darse cuenta. En los cursos de ética, o por medio de los códigos profesionales de la asociación, los profesionales podrán ser advertidos de las situaciones o diles que eventualmente podría conducir a un comportamiento poco ético, como “Avoid harm to others” (evitar el daño a los otros). En conjunto con ACM/IEEECS grupos de trabajos han creados un código de ética para abordar los problemas de comportamiento no ético (www.nspe.org/Ethics/index.html). Pero con mucha frecuencia la atención esta enfocada en los escenarios de primera línea y no en situaciones (inicialmente) mundanas que abundan en nuestra profesión. Además, la formación ética no se le podría dar el énfasis necesario en la educación de pregrado. En lugar de una falta ética aislada, lo que normalmente crea los titulares es el resultado de una secuencia de fallas éticas relacionadas. Cuando hay escenarios de cascadas de estas situaciones, tiene de a haber un efecto de amplificación. El dilema ético ocurre en la ingeniería de software, cuando el profesional debe hacer una elección entre valores en competencia, tales como personales versus profesionales. Por ejemplo, un gerente de ventas podría firma un contrato para entregar un producto de software, conociendo o pudiendo sido advertidos, de que el producto podría requerir más tiempo para la entregar de la fecha prometida. El dilema del gerente de ventas podría ser que su empleador está bajo presión para cumplir con una meta financiera, o puede haber consecuencias relacionadas con el trabajo. En respuesta, el jefe de proyecto crea un cronograma del proyecto realista, que conducen el desarrollo del personal optar por aplazar hasta fin de que puedan alcanzar los objetivos políticos o de organización. Una cadena de conductas contrarias a la ética o poco profesional podría tener lugar que a la larga conduce a enormes multas, juicios, despidos, o incluso la quiebra. Sin embargo, ninguno de

Upload: michael-cardenas-pavez

Post on 06-Nov-2015

214 views

Category:

Documents


0 download

DESCRIPTION

etica, etica profesional, ingenieria

TRANSCRIPT

  • Dilemas profesionales y ticos en Ingeniera de Software Los autores identifican, categorizan y nombran nueves dilemas especficos, ticos y profesional en ingeniera de software, ponindose en el contexto de la IEEE del cdigo de conducta, con la esperanza de que tal comportamiento al tener un nombre aumente la conciencia y disminuya la frecuencia en la que ocurren estos dilemas. Humanos, han estado en la ingeniera de las cosas por cientos de aos, y durante todo este tiempo se han enfrentado en esencia a los mismos retos ticos que hemos sealado en otra parte. Entonces, qu hace que la ingeniera de software sea muy diferente?. La ingeniera de software es una disciplina con las que muchas personas no estn familiarizadas y donde las cuestiones y los problemas son ms fciles de detectar con antelacin. Por lo tanto la gente tiene que confiar en los expertos de ingeniera de software an ms que en los expertos en otros campos de ingeniera. Los ingenieros de software a menudo se involucran en el comportamiento poco profesional o tico sin darse cuenta. En los cursos de tica, o por medio de los cdigos profesionales de la asociacin, los profesionales podrn ser advertidos de las situaciones o diles que eventualmente podra conducir a un comportamiento poco tico, como Avoid harm to others (evitar el dao a los otros). En conjunto con ACM/IEEE-CS grupos de trabajos han creados un cdigo de tica para abordar los problemas de comportamiento no tico (www.nspe.org/Ethics/index.html). Pero con mucha frecuencia la atencin esta enfocada en los escenarios de primera lnea y no en situaciones (inicialmente) mundanas que abundan en nuestra profesin. Adems, la formacin tica no se le podra dar el nfasis necesario en la educacin de pregrado. En lugar de una falta tica aislada, lo que normalmente crea los titulares es el resultado de una secuencia de fallas ticas relacionadas. Cuando hay escenarios de cascadas de estas situaciones, tiene de a haber un efecto de amplificacin. El dilema tico ocurre en la ingeniera de software, cuando el profesional debe hacer una eleccin entre valores en competencia, tales como personales versus profesionales. Por ejemplo, un gerente de ventas podra firma un contrato para entregar un producto de software, conociendo o pudiendo sido advertidos, de que el producto podra requerir ms tiempo para la entregar de la fecha prometida. El dilema del gerente de ventas podra ser que su empleador est bajo presin para cumplir con una meta financiera, o puede haber consecuencias relacionadas con el trabajo. En respuesta, el jefe de proyecto crea un cronograma del proyecto realista, que conducen el desarrollo del personal optar por aplazar hasta fin de que puedan alcanzar los objetivos polticos o de organizacin. Una cadena de conductas contrarias a la tica o poco profesional podra tener lugar que a la larga conduce a enormes multas, juicios, despidos, o incluso la quiebra. Sin embargo, ninguno de

  • los jugadores en este proceso admitir o reconocer que su comportamiento no era tico o poco profesional. Categorizacin de dilemas Para despertar conciencia sobre este tipo de situaciones sutiles pero sin embargo no ticas o poco profesional, les hemos otorgado a cada dilema un nombre. En el cual los lectores pueden estar en desacuerdo con nuestra eleccin de las etiquetas, pero dudamos de que no estarn de acuerdo que el comportamiento es inapropiado. Esta lista no es ni puede ser exhaustiva. Cubrimos las instancias ms significativas de los dilemas ticos. Todos los que se describe implican situaciones comunes. No podemos estar seguros de que slo nombrarlas va a resolver nada, pero ayudar para analizarlas. Hay que considerar que no todos lo malos comportamientos son no ticos. Si no que la gente no sabe bien como interactuar y se comporta mal, por lo cual no esta actuando sin tica, sin embargo, para las personas a tomar decisiones cuando saben que carecen de los conocimientos necesarios para tomar buenas decisiones profesionales. El comportamiento tico se refiere a cmo un individuo o una organizacin se asegura de que todas sus decisiones, acciones e interacciones de las partes interesadas se ajusten a la persona o los principios morales y profesionales de la organizacin. Estos principios deben apoyar todas las leyes y reglamentos aplicables y son la base de la cultura del individuo o la organizacin y los valores. Ellos definen lo correcto de lo incorrecto. Normalmente, la incompetencia, el comportamiento poco profesional, mala conducta personal, la mala gestin o, ms comnmente, una cadena aparentemente sin importancia de las pequeas faltas ticas o profesional trae consigo las situaciones que aparecen en los titulares. Por ejemplo, si un proyecto est atrasado, el director del proyecto podra tener la tentacin de acortar la fase de definicin de requisitos, con la esperanza de recuperar el tiempo perdido. Con el fin de obtener el producto fuera de la puerta, los desarrolladores deben de basar su anlisis no en los requisitos, sino que en las descripciones de desarrolladores de cmo su cdigo funcionar. Posteriormente, el equipo ofrece el resultado para el cliente, con consecuencias posiblemente catastrficas, como un producto inservible, cancelacin del contrato, o demandas judiciales. Este comportamiento es miope y poco profesional y siendo el mejor sin duda. Decisiones equivocadas llevan a malos resultados. Si una persona que debera saber mejor toma las decisiones, se equivoca, y si los intereses personales motivado tales decisiones, el comportamiento se convierte en inmoral.

  • Cuando los estudiantes se matriculan en los cursos introductorios de tica, aprenden acerca de situaciones claras y extremas. Este ambiente hace que sea relativamente fcil distinguir cuando la conducta cruza la lnea o no es tico. Sin embargo, la vida real no es tan simple, y los dilemas a continuacin proceden de escenarios que se producen con demasiada frecuencia. Mision Imposible Este dilema se presenta cuando una persona se le pedir que cree o aceptar un horario que es obviamente imposible de cumplir. Debido a la presin percibida, o por otras razones, la persona que crea o acepta el programa sabiendo que no es realista. El dilema de mea culpa se produce cuando los miembros del personal debe entregar un producto que todava carece de algunas funciones clave o ha conocido los defectos de software. Las consecuencias de este error de juicio puede ir desde la prdida de personal calificado a la prdida significativa de ingresos. El exceso de trabajo y la prdida de agotamiento causa del personal. La prdida de ingresos puede derivar de la divulgacin prematura de la disponibilidad de un producto, que luego llega al mercado ms tarde de lo previsto. Mientras tanto, los clientes dejen de comprar el producto actual a la espera de la llegada del nuevo producto. Mea culpa Este dilema se presenta cuando los miembros del personal debe entregar un producto que todava carece de algunas funciones clave o ha conocido los defectos de software. La anticipacin del mercado puede crear una presin para liberar el producto antes de tiempo, antes de que un competidor lo hace, o antes de las obligaciones contractuales, posiblemente asociadas a una clusula de penalizacin-vencimiento. Una evaluacin del riesgo vale la pena y podra revelar que, en determinadas circunstancias, la liberacin temprana podra ser beneficioso. Sin embargo, podran surgir problemas si nadie realiza una evaluacin del riesgo o los riesgos reales de ser mucho mayor que percibe. En el corto plazo, la entrega de los productos incompletos de software hace que la insatisfaccin del cliente. Repercusiones a largo plazo podran incluir una mala reputacin y la prdida de cuota de mercado o de ventas. Si las entregas incompletas sucede con bastante frecuencia, la empresa podra quedar fuera del negocio. En el peor de los casos, personal de la empresa podra estar expuesto a sanciones civiles o penales. Trabajo urgente.

  • Ocasiones puede ocurrir que sea una tica de trabajo pobre o la presin percibida para ofrecer una calidad compromisos. Un desarrollador que trabaja en un producto de software proporciona el cdigo de trabajo, pero la calidad del producto es de mala calidad, con mnima o ninguna razn de ser y de poca o ninguna documentacin. El programador puede sentirse bajo presin para entregar, cada vez ms preocupados acerca de las etapas de reuniones que garantizar la calidad. El trabajo urgente y dilemas mea culpa difieren notablemente. En los desarrolladores de modo de mea culpa dan a luz a un producto, a pesar de que falta la funcionalidad. Sin embargo, en el escenario de trabajo urgente, la funcionalidad completa puede estar presente, pero el resultado de baja calidad de los productos no cumplen con los estndares establecidos por los desarrolladores de forma intencionada negocian calidad por la velocidad de ejecucin. La diligencia no se produce cuando la documentacin ms importante, tales como solicitudes de propuestas, documentos de requisitos, o los contratos no recibe una revisin a fondo. No es mi problema De vez en cuando, un equipo de proyecto o el personal se ocupar de las actividades del da a da, aceptando quo de la cultura de desarrollo de la situacin y que no muestran inclinacin a mejorar la productividad o la calidad. Por ejemplo, los cdigos de error puede ser codificado en el software en lugar de colocarse en una mesa. Cuando los desarrolladores de ignorar las mejores prcticas, que pueden dejar la puerta abierta para la sociedad civil, y en algunos casos raros, la responsabilidad penal,. Llamamos a este dilema no es mi problema, ya que los miembros del equipo con frecuencia indicar que las cuestiones de calidad, productividad, y las mejores prcticas son responsabilidad de otra persona Mentiras rojas Red mentiras se producen durante las reuniones con clientes o de gestin, cuando los representantes de formular declaraciones acerca de un producto o proyecto que se sabe que son falsas, como indicando que la entrega de un proyecto es en la fecha prevista, cuando el equipo ya sabe que no puede entregar a tiempo. Hay un poco de mi problema, no en la mentira de color rojo. Por ejemplo, en lugar de admitir que un proyecto est atrasado, un director de proyecto que se podra racionalizar la carga de hacer recuperar el tiempo perdido recaer en el equipo de desarrollo. Esto permite que el administrador de informar de un programa ideal. Si el equipo de desarrollo no cumple con este horario, que si no se convierte en su problema.

  • El uso del color rojo es importante en este caso, ya que indica lo que podra pasar a la lnea final de la empresa, si este comportamiento se vuelve dominante o en curso Fictionware versus vaporware El dilema fictionware ocurre cuando una organizacin o las promesas o contratos individuales para ofrecer un sistema para el que algunas de las caractersticas convenido en no son factibles. Fictionware y el vaporware trmino de uso frecuente se diferencian en que un producto fictionware existe, pero carece de una cantidad variable de la funcionalidad especificada. En el caso de vaporware, el producto simplemente no existe. Esta situacin se produce normalmente cuando la gente se siente bajo una intensa presin para cumplir con los objetivos de ventas, la negacin puede hacer que sea difcil de leer una solicitud de propuesta de manera objetiva. Contratos Fictionware son endmicas en las organizaciones contratantes que separan las comisiones de ventas de la entrega. El representante de ventas puede tener una idea vaga de que el proyecto contratado, para el no es factible, pero esa persona realmente no le importa, porque la comisin est supeditada a la adjudicacin del contrato, no en la rentabilidad a largo plazo. Mitigar los problemas con fictionware puede lograrse mejor mediante el acoplamiento de los pagos por mrito o bono de utilidades afterCompletion proyecto, y dando a profesionales de la ingeniera la responsabilidad inicial importante y la autoridad para influir en el proceso de licitacin o cotizacin No a la diligencia Este comportamiento se produce cuando la documentacin ms importante, tales como solicitudes de propuestas, documentos de requisitos, o los contratos no recibe una revisin a fondo. En el caso de nondiligence, los acuerdos pueden hacerse sin una cuidadosa comprensin de lo que se acord, ya sea por falta de evaluar cuidadosamente una especificacin o falta de pago de atencin al personal a su expresar sus preocupaciones Cancelacion de vacaciones Un sndrome de vacaciones cancelados pueden surgir cuando los gerentes de los miembros del personal de presin en el ltimo minuto para cancelar los viajes planeados o no sacrificar su tiempo y personal, posiblemente, dinero a travs de, por ejemplo, el viaje no reembolsable de reservas para cumplir con un plazo a corto plazo. Mientras trabajaba en una empresa de consultora, uno de nosotros observ varios consultores que le dicen que cancelar sus planes de vacaciones para que una etapa del proyecto se pudo cumplir. En un caso, los padres de los empleados fueron en

  • avin desde el extranjero, y los planes de viaje haba finalizado casi un ao antes de la fecha del viaje. La interrupcin forzosa indica una falta de planificacin por parte de la gestin de proyectos, y mientras que potencialmente resolver un problema a corto plazo, en esta situacin particular que caus una an ms grave a largo plazo la dotacin de personal y el problema de la moral. Cada empleado le pregunt a cancelar unas vacaciones dej la compaa en un ao. Por otra parte, la gestin del proyecto muerto poco despus de las cancelaciones de viaje se produjo. As que la empresa que promovi este sndrome vacaciones canceladas no gan nada y perdi varios empleados valiosos Tabla 1: estrategias de mitigacin: referencias cruzadas con los dilemas imprescindible Dilema tico Aplicable ACM-IEEE imprescindible Comentario Misin imposible Cumplir los contratos, acuerdos y responsabilidades asignadas, "un profesional de la informtica tiene la responsabilidad de solicitar un cambio en cualquier tarea que l o ella siente que no puede ser completado como definido ".

    La dificultad de cumplir los acuerdos y no aceptar tareas imposibles que a menudo es en la aceptacin de la cultura organizacional de cualquier trabajo es la norma cuando se trata de la asignacin de un supervisor Mea culpa Esforzarse por lograr la ms alta calidad, la eficacia y la dignidad tanto en el proceso y los productos de los profesionales de trabajo "El profesional de la informtica debe esforzarse por alcanzar la calidad y ser consciente de las graves consecuencias negativas que pueden derivarse de un sistema de baja calidad."

    El imperativo es demasiado amplia para permitir que el profesional de reconocer cuando se aplica en situaciones de rutina. Rush job Vea mea culpa Vea mea culpa No es mi problema Vea mea culpa Vea mea culpa No dilegencias Dar evaluaciones completas y extensas de los sistemas informticos y sus consecuencias, incluidos los riesgos posibles.

    Los equipos mixtos de gestin de proyectos, marketing y ventas puede hacer que sea difcil de lograr este objetivo, especialmente si los dictmenes emitidos no coinciden con los objetivos de la alta direccin. Fictionware/ Vaporwar Ser honesto y confiable La honestidad y la honradez son mucho ms difciles de lograr con la dinmica organizativa que como un individuo. No obstante, por los imperativos de ACM, hay veces en que un profesional debe tomar una posicin o alejarse de una misin

  • Cancelar las vacaciones No est cubierto por el cdigo de ACM de la tica. Los imperativos de ACM frente a la justicia y la discriminacin, no al maltrato del personal. El cdigo de ACM slo se refiere a la equidad genrica y no discriminacin Barrer bajo la alfombra Esforzarse por lograr la ms alta calidad, la eficacia y la dignidad tanto en el proceso y los productos del trabajo profesional, tambin, cumplir los contratos. La administracin a menudo resuelve los problemas que se producen durante la construccin y prueba de software, por desgracia, muchos gerentes no saben o no consideran a s mismos que no est obligado por los cdigos ticos de ACM. Barrer bajo la alfombra Este sndrome se produce cuando las cuestiones que surjan imprevistos que podran potencialmente daar un proyecto o empresa, pero, para mantener las cosas funcionando sin problemas, los desarrolladores de ignorar los problemas en la vana esperanza de que se desvanecer. Por ejemplo, un probador descubre una falla en un sistema de comunicacin y lo llama a la atencin de sus supervisores. Ellos determinan que, si bien el fallo es real, las probabilidades de su impacto en el producto entregado es relativamente pequeo y, adems, una vez que el cliente empiece a usar ella, los responsables se han trasladado a otro proyecto. Barrer bajo la alfombra, no se diferencia de mi problema en que se trata de una manipulacin o ignorando poco frecuentes problemas nicos, mientras que no es mi problema se produce cuando los desarrolladores no tienen en cuenta los problemas sistmicos de infraestructura o proceso ACM y el IEEE cdigos de tica El Cdigo de Ingeniera de Software de tica y Prctica Profesional contiene un conjunto de 24 imperativos que tienen que ver con el profesionalismo, la interaccin de los profesionales de la apuesta de Ween y la sociedad, y el liderazgo (www.ieee.org/portal/pages/iportals/aboutus/ethics/code.html), el Cdigo ACM de tica y Conducta profesional contiene un conjunto de 10 imperativos que tienen que ver con la honesta y, lA RESPONSABILIDAD, licts conf de inters, competencia tcnica, y la equidad (www.acm.org/about/codeof-ethics). Hemos referencias cruzadas a los dilemas que figuran con sus imperativos pertinentes de los cdigos de ACM-IEEE, como muestra la Tabla 1. Los imperativos son bien elaborado y completo. Estos imperativos, no han servido a los profesionales software de la comunidad, as como lo haran para una variedad de razones: Un gran porcentaje de profesionales de software no pertenecen a la IEEE o ACM.

  • Muchas personas que trabajan en proyectos que no pueden ser profesionales de software, sino que son los gerentes de producto o proyecto. Muchos miembros de la ACM y de IEEE est familiarizado con estos cdigos de tica. Incluso cuando algo familiarizado con los imperativos, presiones de los compaeros, organizativas o de otro tipo puede ser ejercida. En algunos casos, los imperativos son vagas y requieren un estudio para entender cuando se aplican a una situacin particular. Hemos seleccionado varios imperativos relacionados con los dilemas ticos que se describen aqu para poner de relieve la forma en que puede no proporcionar una gua adecuada para el software profesional durante las actividades diarias Profesionales de software deben ser conscientes de las repercusiones financieras, legales y polticos de la conducta irresponsable. Ser honesto y confiable La determinacin de lo que implica la honestidad podra estar abierto a la pregunta. Al igual que un campo gravitacional intenso puede doblar la luz, la fuerte presin de la organizacin o financiera puede torcer la verdad. Por ejemplo, contando un cliente que el software es operativo cuando, de hecho, est en construccin; pronosticar una fecha de entrega que se puede lograr slo si el personal trabaja 24 horas al da, o indicando que no hay problemas conocidos con software cuando, de hecho, las pruebas o desarrollo han reportado problemas serios. El problema es que la honestidad no slo podra ser abierto a la interpretacin, sino que la intensa presin financiera y organizativa podra aplicarse para lanzar los temas desde una perspectiva particular, sesgada. Calidad, eficacia y dignidad Como desarrolladores de conciencia, debemos esforzarnos para lograr la mejor calidad y mayor eficacia, tanto en los procesos y productos de nuestro trabajo profesional-y debemos hacerlo con dignidad. Aprendemos en la ingeniera de requisitos que trminos como "la ms alta calidad" son intrnsecamente ambigua. Tambin sabemos que la calidad tiene un precio. Llega un punto en el cual el costo de encontrar un producto de defectos ltimos es mayor que los beneficios de la bsqueda de ellos. A veces, el reconocimiento de

  • que el logro de la ms alta calidad podra no ser factible hace que todo el tema de discutible calidad. Por ejemplo, debido a la escasez de personal profesional, o por otras razones, puede haber no a los exmenes sobre un proyecto. Las revisiones de cdigo son uno de los mecanismos ms eficaces para encontrar defectos de software, sin revisiones por pares, una organizacin podra buscar problemas. El personal no podra saber que los exmenes no estn en su proceso o puede ser que reconocen que las revisiones que faltan, pero acepta la posicin de la administracin de que no hay tiempo para llevar a cabo de manera adecuada. Si una organizacin no es diligente, el proceso puede degenerar fcilmente en un entorno de hacking anrquica. COMPORTAMIENTO CRIMINAL contra la antittica A veces un individuo o una organizacin se involucra en prcticas que van ms all de tica y perdida en el penal de plano. El individuo en cuestin no puede darse cuenta de que la prctica o la falta de mejores prcticas es criminal. En los EE.UU., no puede haber variaciones en todos los estados de cmo las leyes se interpretan. Fuera de Norteamrica, las leyes pueden variar ampliamente, y una prctica que no es criminal en una localidad puede estar en otro. De este modo, los individuos pueden violar la ley sin darse cuenta. En todos los casos, en todo momento, los profesionales del software deben ser conscientes de las repercusiones financieras, jurdicas y polticas de comportamiento irresponsable, incluyendo el comportamiento tolerancia de la que ellos mismos no podran tomar parte. Homicidio por negligencia Homicidio por negligencia implica la muerte de otra persona por negligencia grave o sin malicia. Por lo general, este tipo de homicidio involuntario involucra a actores que deberan saber que estaban creando riesgos sustanciales e injustificados de la muerte de una conducta que se desva de la atencin sumamente comn. El Cdigo de tica de IEEE se compromete "a aceptar la responsabilidad en la toma de decisiones coherentes con la seguridad, la salud y el bienestar de la poblacin, y dar a conocer rpidamente los factores que podran poner en peligro al pblico o el medio ambiente." Imprudencia temeraria Imprudencia temeraria ocurre cuando una persona participa en una conducta que crea un grave riesgo de muerte a otro. Quienes practican este comportamiento podra no ser conscientes de que estn poniendo en peligro el bienestar de los dems. Un comportamiento imprudente es en s misma. Indiferencia depravada

  • Dependiendo de las leyes de la jurisdiccin, en un tipo ms grave de imprudencia temeraria de la persona que ejerza en el comportamiento que tuvo la vida de otro lo hizo en circunstancias que mostraba una indiferencia depravada de la vida humana, plenamente consciente de que esas acciones podran dar lugar a otro de lesiones o la muerte, pero indiferente a ese resultado. el comportamiento poco tico contra criminales Un profesional podra incurrir en conductas delictivas, sin darse cuenta de que l o ella lo haba hecho al actuar de la siguiente manera: No rastreo requisitos para casos de prueba. Un requisito podra indicar que una dosis de radiacin para una mquina de rayos X puede, en ningn caso, exceder del 5 RAD. Si el desarrollador permite dosis ms grandes que se produzca, y las pruebas no recoger esto, la organizacin podra ser penalmente responsable por no seguir las mejores prcticas tales como la trazabilidad de extremo a extremo. Codificar los cdigos de error. Un sistema de sealizacin ferroviaria codifica los errores. Sin una tabla que contiene los cdigos de error, se hace imposible para encontrar eficazmente y probar cada condicin de error. Esto hace posible que un error no probado que se produce durante la operacin para producir una seal de congelar en la posicin de marcha, resultando en una colisin del tren. La compaa que cre el sistema de sealizacin puede ser considerado penalmente responsable por los textos bsicos de ingeniera de software puede demostrar que la gestin de errores durante el desarrollo de software es una de las mejores prcticas fundamentales. Una ACM-IEEE imperativo es "Conocer y respetar las leyes existentes relacionadas con el trabajo profesional." Desafortunadamente, en algunos casos poco frecuentes, los profesionales aprenden despus de que el hecho de que podran haber violado las leyes o estn sujetos a sanciones penales o civiles. A los ojos de la ley, sigue siendo responsabilidad de la persona para asegurarse de que las mejores prcticas se siguen, independientemente de la presin percibida de organizacin o de gestin. EFECTOS DILEMA AMPLIACIN Cuando los dilemas ticos se acoplan o encadenados juntos, los resultados pueden ser ms perjudiciales que cualquier dilema que ocurre una sola. Por ejemplo, nondiligence podra resultar en la entrega tarda. En ese momento, podra ser posible renegociar un calendario viable. Sin embargo, para compensar el tiempo perdido, se produce una misin imposible dilema en los horarios difciles con la presin de la organizacin aplicada. La probabilidad de fracaso del proyecto ahora aumenta a medida que las cosas se vuelven ms caticas y sufre el proceso. Presin de transporte hace que el dilema trabajo urgente ya que los desarrolladores abandonan las mejores prcticas para obtener el software a la puerta. La probabilidad de fracaso del proyecto aumenta de nuevo, como si no se

  • siguen las mejores prcticas podra resultar en un producto insostenible o entrega que nunca funciona. En general, los dilemas tienden a caer en cascada: El anterior en el proceso los dilemas son reconocidos, ms fcil podra ser la de modificar el comportamiento y dirigir hacia un positivo o por lo menos menos resultado negativo. estrategias de mitigacin Cuando nos enfrentamos a un dilema tico potencial, una de las mejores estrategias de mitigacin consiste en realizar un anlisis de riesgos antes de decidir sobre un curso de accin. Una estrategia preventiva eficaz consiste en proporcionar un cdigo de conducta de trabajo y la celebracin de sesiones de entrenamiento en tica para todo el personal. La tabla 1 recoge las estrategias de prevencin adicionales Mientras la mayora de las empresas y organizaciones tienen cdigos ticos de conducta, los profesionales de software no puede reconocer que tales cdigos se aplican a las prcticas cotidianas tambin. Todos los dilemas que hemos descrito se producen frecuentemente, pero a menudo los participantes no reconocen que su comportamiento no es tico. Tal vez por nombrar a los dilemas que los desarrolladores ver con los patrones de software, ser ms fcil reconocer su presencia y tomar medidas correctivas. Los dilemas ticos pueden conectar en cascada, con una mayor probabilidad de fracaso del proyecto con cada paso en falso. Por desgracia, carecemos de los datos para cuantificar la contribucin de cada dilema a la probabilidad de fracaso del proyecto. Dicha informacin se puede encontrar generalmente enterrados en el archivador de proyectos fallidos. Un posible mecanismo para la prevencin de este comportamiento es la educacin profesional o empresarial. Claramente, no es suficiente para llegar a los miembros de la IEEE o ACM como el dilema inicial o causal en una cadena puede ocurrir en una fase previa, durante la negociacin del contrato o la definicin del producto, por ejemplo. Por otra parte, los imperativos ticos de IEEE y ACM debe ser claramente comunicada a la informtica y los estudiantes de ingeniera de software y profesionales para que puedan reconocer el comportamiento poco tico, ver la relevancia de su trabajo, y rpidamente detener o mitigarlo.