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 )
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
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
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…
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…
40.
41.
42.
43.
44.
45.
46.
47. ¿Se imaginan de verdad construyendo este tipo de sistemas “en el aire” ?
48.
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
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…
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…
71.
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
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
