El documento habla sobre la responsabilidad social en la ingeniería de software. Explica que la ingeniería de software involucra más que solo hacer que funcione el software, ya que los errores pueden tener graves consecuencias que afecten a muchas personas. También señala que todos los involucrados en el proceso de desarrollo de software, como gerentes, analistas y programadores, comparten la responsabilidad de asegurar la calidad y evitar errores.

1. Entendiendo la Responsabilidad Social de la Ingeniería de Software @Avanet - @SoreyGarcia

2. El por qué de esta conferencia La ingeniería de software y la calidad de software nos resultan temas apasionantes… Ser humanamente responsable nos resulta un reto Intentar hacer las dos primeras sin la última es claramente un despropósito

3. Con esta charla no pretendemos enseñar a nadie a ser “humanamente responsable” Lo único que queremos es compartir algunas ideas de “ por qué deberíamos serlo” si nos dedicamos a esto de “ hacer software” siendo entusiastas o profesionales de cualquier área ( si, de cualquiera )

4. Empecemos por entender lo básico ¿Qué es Ingeniería de Software?

5. La Ingeniería de Software es la aplicación práctica del conocimiento científico en el diseño y construcción de programas de computadora, y la documentación asociada requerida para construirlos, operarlos y mantenerlos. Bohem - 1976.

6. La Ingeniería de Software es la aplicación de un enfoque sistemático, disciplinado y cuantificable al desarrollo, operación, y mantenimiento del software. IEEE - 1993.

7. La Ingeniería de Software es la disciplina o área de la informática que ofrece métodos y técnicas para desarrollar y mantener software de calidad . Wikipedia

8. ¿Está claro? Si, … o quizá… Sin embargo todo eso parece un concepto muy elevado para algo tan simple como “ hacer sofware”

9. Si, es cierto… Es tan simple que puedes aprenderlo en Internet, incluso trabajar en ello y ganar mucho más que muchos de los que estudian física, matemáticas y ética …

10. Y es que hace algunos años, ser ingeniero de sistemas parecía ser una de esas carreras que ofrecía un futuro prometedor

11. Y saber de eso que pocos sabían hacía que fueras alguien “ interesante ” …

12. En la práctica… Las cosas resultaron ser un poco distintas para la mayoría de nosotros…

13. Es típico escuchar a las actuales generaciones de programadores profesionales, hablando de lo aburrido que resulta trabajar horas extras bajo presión, con planificaciones y presupuestos ajustados , pero eso si, con la firme convicción por parte de la administración de que haciéndolo todo no tan bien y con prisa el resultado tendrá que ser lo que el cliente espera ¡A como dé lugar!

14. Y ni hablemos sobre el concepto de “ interesante ” en el que nos tiene la mayoría…

15. Bajo esta perspectiva, resulta un poco extraño que tantas personas (entusiastas y profesionales de otras áreas) quieran hacer “lo mismo” que nosotros, y se aventuren en masa a la tarea de “ construir software”

16. Un momento, nadie dijo que lo hicieran bien (no todos) , solo que también podían hacerlo…

17. Sin embargo, No se trata solo de eso Bueno, eso sería, si lo único que importara de “desarrollar software” fuera “lograr que funcione”

18. ¡Espere un momento! Aunque me gusta mi profesión, no estoy sugiriendo que debe ser un ingeniero titulado para hacer Ingeniería de Software. Lo que queremos resaltar es que si usted se quiere participar de la tarea de hacer software o si usted necesita contratar quien lo haga, debería entender como mínimo que implicaciones hay detrás de todo eso…

19. Sin embargo y sin ánimo de ser duros, déjenos preguntarles,… ¿Qué clase de persona se arriesgaría a realizar una cirugía por haber encontrado las instrucciones en Internet? Y ¿quién en su sano juicio se sometería a que alguien así le hiciera una cirugía?

20. ¡La verdad es que no suena nada agradable! ¡Ah! Pero es que usted no pretende hacer cirugías ¿verdad? Veamos, pruébese así mismo, responda la siguiente pregunta ya bastante típica

21. ¿Viajaría usted en un avión cuyo software ha sido construido por usted?

22. Esta pregunta es una de esas que generalmente produce duda o risa… Si fue así, le invitamos a cuestionarse… Sea usted o no, un profesional informático La razón es evidente y simple…

23. Hay personas, si subirán a ese mismo avión, es decir que usarán su software

24. Veamos otras preguntas… ¿Dudan los enfermos del corazón de sus médicos cirujanos?

25. ¿Dudan los empresarios de los ingenieros civiles y arquitectos que construyen sus edificios?

26. La falta de un lugar como profesional de sistemas, está al punto de considerar que lo que más sabemos hacer es instalar Word, manejar Excel o vacunar el computador cuando la familia lo llena de virus

27. Puede que ese sea uno de los muchos orígenes de la idea de que un tutorial en Internet será suficiente para suplir la academia.

28. Pues bien, esto lejos de ser una charla de desmotivación (como seguro parece) es una invitación a reflexionar y no solo como ingenieros, más bien como personas a los que nos afectará tarde o temprano todo esto

29. Por otro lado… ¿Qué tan seguros estamos de que los profesionales de ingeniería valoran y entienden su papel?

30. La mayoría de la gente piensa que la gente dedicada a la tecnología, se parece más a las máquinas con las que trabaja, que a la gente y que son como robots, por pasar todo el día frente a la computadora

31. Bueno, en realidad no importa mucho si lo que piensan es correcto o no… Pero hay un problema

32. Algunos ingenieros piensan exactamente lo mismo, actúan tal cual como si estuviesen programados y hacen exclusivamente lo que “deben” hacer o lo que alguien les dice que hagan, finalmente, así el trabajo es “más simple” y evitan preguntarse, por qué es importante…

33. La Ingeniería de Software tiene un poco más que ver con un tema ético y humano de lo que muchos piensan

34. La ingeniería de software es una idea casi ética ( no solo ética ) de como hacer el software de forma correcta (software de calidad) Aquí va una propuesta de una definición menos formal

35. Quizá no tiene tantos años como la física, matemáticas o arquitectura…

36. Pero créanos, tampoco se la inventaron ayer, ni está en pañales…

37. Pero puede que “muchos de nosotros” si…

39. Se han preguntado alguna vez ¿Dónde hay software? Ahora, pongamos en una perspectiva más real el símil de construir el avión en vuelo…

47. ¿Se imaginan de verdad construyendo este tipo de sistemas “en el aire” ?

49. En la mayoría de proyectos de desarrollo, los costes de mantenimiento, superan por un amplio margen los costos de desarrollo, se habla de un 30% en Desarrollo y un 70% en Mantenimiento.

50. No debería ser así ¿verdad? Todos sabemos que cometer errores en la construcción de software puede tener serias consecuencias…

51. ¿Qué consecuencias? ¿Acaso en software no importa es básicamente que funcione ? Veamos algunas respuestas a esa pregunta… (Ojo, las siguientes imagenes son meramente ilustrativa, no todas pertenecen al hecho descrito)

52. Therac-25 (1985 – 1987) Era una máquina empleada en terapia de radiación, producida por Atomic Energy of Canada Limited , notoria por haber sido objeto del error de software, causando al menos seis accidentes y que le costó la vida al menos a cinco personas

53. Mariner 1 (28 de Julio de 1962) Un guión en las instrucciones del programa de guiado del cohete provocó la desviación del Atlas y tuvo que enviarse un comando para su autodestrucción a los 4 minutos y 53 segundos de su lanzamiento

54. Vuelo 501 del ARIANE-5 (4 de Junio de 1996) Otro ejemplo documentado sobre el daño ocasionado por software mal diseñado es el de la explosión de la lanzadera Ariane-5, cuando a 40 segundos después de la iniciación de la secuencia de vuelo, la lanzadera se desvió de su ruta, se partió y explotó. En el proyecto global se invirtieron 10 años de construcción y 7 mil millones de euros, lo que supuso un duro golpe para la Agencia Espacial Europea (ESA) http :// www.youtube.com / watch?v=IONcgYzVFlg

55. A-320 de Air France ( 26 de junio de 1988) Durante una presentación en el meeting de Habsheim, cerca de Mulhouse (Francia), un A-320 de Air France se estrella en el bosque, al final de la pista. Habrá tres muertos y una centena de heridos. Justo después, el mundo se pregunta las causas del accidente del avión anunciado como "el más seguro del mundo". Una de las causas se le atribuye a un error en el software de navegación http :// www.youtube.com / watch?v=_EM0hDchVlY

56. ¡Si, ya sé! Usted no hace software para aviones o para la NASA Lo que lo estoy invitando a cuestionarse es…

57. Antes de poner sus aplicaciones de software en producción, se pregunta… ¿el trabajo de cuantas personas puede afectar que algo salga mal? Entiendes que, ¿Qué algo salga mal puede significar hasta el simple hecho de que usar tu software puede ser desde confuso hasta una tortura?

58. Es común ver software hechos para quienes lo desarrollaron y no para quienes lo van a usar

59. Pues bien, aunque actualmente existen muchas personas que construyen software con conocimiento empírico , tal como si fuera arte , lo que debe diferenciar un trabajo bien hecho ( profesional o empírico ), es los métodos y la evidente forma de hacer el trabajo teniendo en mente la calidad de los procesos ejecutados y de los productos desarrollados .

60. Hacer las cosas bien, siempre va a requerir un poco más de esfuerzo, que hacerlas de cualquier otro modo

61. Practicas y Principios Pressman Actividades Personas Herramientas Roles Artefactos Notación Proceso de Software

62. Existe una gran la variedad de propuestas de Proceso de Software , sin embargo el conjunto de actividades fundamentales definidas en el Ciclo de Vida Clásico se encuentran presentes en todos ellos. Análisis Diseño Construcción Pruebas Operación y Mantenimiento

63. Es así como encontramos las Métodologías Estructuradas

64. Y también las Métodologías Ágiles

65. No existe un proceso de desarrollo de software universal que sea efectivo para todos los contextos de proyectos de desarrollo, de allí que sea necesario elegir responsablemente cual de ellos es más conveniente, teniendo en cuenta algunos criterios…

66. Complejidad

67. Costo/Beneficio Económico

68. Robustez del software

69. Conocimiento disponible

70. Los principios y practicas que pueden seguirse en la Ingeniería de Software, buscan garantizar un mejor resultado y uso de los recursos Pero, por alguna razón el comportamiento de los proyectos no es “aún” el esperado…

72. ¿Quién dice que siempre sale mal? A pues no, no siempre sale mal… Solo algunas veces

73. (Estudio de Resultado de Ejecución de los Proyectos de Software) Fuente: http :// vidanp.wordpress.com /2010/02/01/ estandares -de-medida/ CHAOS Report

74. Seguimos cayendo en los mismos errores una y otra vez…

75. ¿Qué errores se comenten?

76. Falta de comunicación

77. Ausencia de objetivos y metas claras durante la ejecución del proyecto

78. Falta de planificación

79. Requisitos poco claros y falta de acceso a la información

80. Falta de análisis y entendimiento de las necesidades del cliente

81. Mala estimación de tiempos

82. Indefinición del alcance y las responsabilidades de las partes

83. Falta de identificación y gestión de los riesgos

84. Carencia de habilidades en la ejecución de un rol

85. Falta de seguimiento al avance del proyecto

86. Falta de control del presupuesto

87. Recursos Insuficientes

88. Tratar de construir sin tener una arquitectura definida

89. Falta de conocimiento e interés en la aplicación de mejores prácticas

91. Hoy en día pocos comprenden, que la responsabilidad de lograr productos de software tiene que ver con todos los que participan en cualquier rol de proceso de Ingeniería de Software Mencionemos algunos

92. Gerente de Proyectos

93. Analista Funcional

94. Arquitecto de Software

95. Analista Diseñador

96. Analista Programador

97. Analista de Pruebas

98. ¿Son esos “ Todos” ?

99. En la academia Gobierno, instituciones, docentes y estudiantes

100. En la empresa Directivos, clientes, usuarios, analistas de negocio, profesionales de sistemas

101. ¿Tu?

102. ¿Preguntas? @avanet @soreygarcia

103. ¡Gracias!