2. Talleristas Hernán Guzmán Cristian Aroca Sorey García Apoyo Orlando Contreras David Ramirez Cubrimiento Angelo Cardona (Streaming) Jenny Chica (Fotografía) Pavel Espitia (Twitter y Chat) Asesor Tecnoparque Julián Guevara
3. ¿Qué es Avanet? Avanet(Academia Virtual Altruista) es una comunidad virtual abierta orientada a generar mecanismos de proyección y capacitación profesional, a través de la difusión y gestión de conocimiento, por medio de herramientas de autoaprendizaje dinámicas que faciliten la apropiación y conservación de este, de y hacia todas las personas que desean adquirir o fortalecer las habilidades necesarias para el desarrollo de sus actividades profesionales y laborales.
4. Muchos se preguntan ¿Por qué academia? La siguiente definición nos inspira a usar el término "Academia" como parte de nuestro lema y nombre: “Asociación de personas cuyo objeto es el cultivo y el progreso de las artes, las letras, ciencia, tecnología, etc.”
6. El por qué de este taller La ingeniería de software y la calidadnos resultan temas apasionantes… Ser humanamente responsable nos resulta un reto Intentar hacer las dos primeras sin la última es claramente un despropósito
7. Con este taller no pretendemos enseñarle a ser “humanamente responsable” Lo único que queremos es darle algunas ideas de “por qué debería serlo” si se dedica usted al tema de “hacer software”
9. 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.
10. Ingeniería del Software es el estudio de los principios y metodologías para desarrollo y mantenimiento de sistemas de software. Zelkovitz - 1978
11. 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.
12. 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.Wikipediahttp://es.wikipedia.org/wiki/Ingenier%C3%ADa_del_software
13. Todo eso parece un concepto muy elevado para algo que parece ser tan simple como “hacer software”
14. 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…
15. ¡Ups!... Un momento, nadie dijo que lo hicieras bien, solo que también podías hacerlo, hacer lo simple… y… ¿Por qué conformarse con eso?
16. Quizá la Ingeniería de Software no tiene tantos años como la física, matemáticas o arquitectura…
18. Para empezar a entender todo esto hagamos una pequeña reflexión Se han preguntado alguna vez¿Dónde hay software?
19.
20.
21.
22.
23.
24.
25.
26. ¿Quién es un ingeniero de software? En este taller, cuando hablamos de un ingeniero de software no hablamos de un ingeniero titulado, hablamos de una persona involucrada en el proceso de construcción de cualquier producto de software… ¡Hablamos de usted!
27. ¿Lo duda?Veamos que tanto lo involucra todo estoIntente responder un par de preguntas típicas
28. ¿Iría en un viaje alrededor de la tierra en globo, sabiendo que este esta controlado por una computadora?
30. Si estas preguntas le producen un tanto de risa o duda, lo invitamos a replantearse… El tema de que nuestra profesión sea un chiste, ha sido comparado con este video: ¿Qué pasaría si los programadores construyeran aviones? http://www.youtube.com/watch?v=UZq4sZz56qM
31. Gracioso¿No?¡Pues NO! No es gracioso que siendo un profesional tu trabajo sea tomado en broma…El problema es ¿Qué pasa si nosotros mismos nos tomamos nuestro trabajo en broma?
36. Esto es una invitación a cuestionarse ¿Dudas de ti? ¿Dudas de tu equipo de trabajo?
37. Aquí va una propuesta de una definición menos formal La ingeniería de software es una idea casi ética (no solo ética) de como hacer el software de forma correcta (software de calidad)
38. Y hacer las cosas bien, siempre va a requerir un poco más de esfuerzo, que hacerlas de cualquier otro modo No hacerlo, siempre va a tener consecuencias…
39. ¿Qué consecuencias?¿Acaso en software no importa es básicamente que funcione?Veamos algunas respuestas a esa pregunta… (Ojo, lassiguientesimagenes son meramenteilustrativa, no todaspertenecen al hechodescrito)
40. Therac-25 (1985 – 1987) Era una máquina empleada en terapia de radiación, producida por AtomicEnergy of CanadaLimited, 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
41. 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
42. 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
43. 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
44. ¿Qué tal las respuestas? ¡Nada agradables si me permiten decirles!
45. 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.
54. Sin embargo sabemos que en realidad, es un poco más difícil de lo que imaginamos
55. Pues bien lo mismo sucede con la construcción de software…Para desarrollar software existen una serie de roles asociados, encargados de analizar, planificary establecer, qué es lo que va a desarrollarse, cómo, con cuantos recursos, en cuanto tiempo e incluso a que nivel de calidad, es lo que conocemos como el Proceso Software
56. El Proceso de Software es el conjunto de actividades que se realizan para la construcción, liberación y evolución de un producto de software, comenzando con el estudio de una idea y finalizando con el retiro final del sistema.
57. Practicas y Principios Actividades Herramientas Personas Proceso de Software Notación Roles Artefactos Pressman
59. Ciclo de Vida Clásico El ciclo de vida describe los estados por los que pasa un producto de software, desde su concepción hasta su muerte.
60. Ciclo de Vida Clásico Análisis Diseño Construcción Pruebas Operación y Mantenimiento
61. 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. Conozcamos algunas…
66. SCRUM AUP Manifiesto Ágil Individuos e Interacciones Procesos y herramientas sobre XP Software que funciona Documentación exhaustiva sobre Colaboración con el cliente Negociación de contratos sobre Responder ante el cambio Seguimiento de un plan sobre
67. 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 cual de ellos es más conveniente, teniendo en cuenta algunos criterios…
74. El desarrollo de software es una actividad que, dada su complejidad, debe desarrollarse en grupo. Además, esta actividad requiere de distintas capacidades, las que no se encuentran todas en una sola persona. Por ello, se hace necesario formar el grupo de desarrollo con las personas que cubran todas las capacidades requeridas. Cada una de esas personas aportará al grupo parte del total de las capacidades necesarias para llevar a cabo con éxito el desarrollo.
75. Con el tema de los roles tampoco debemos permitir que nos suceda esto…
85. Cada grupo recibirá unos materiales (hoja de números, resaltador, marcador y unas tijeras) y un conjunto de instrucciones a seguir
86. Cada grupo debe leer sus instrucciones en silencio y sin conversar entre los integrantes a menos que así lo indique la hoja de instrucciones.
87. Los equipos deben seguir la estrategia definida en la hoja de instrucciones sin modificarla, no debe copiarse la estrategia de otro grupo.
88. A la señal los equipos deben iniciar con las tareas que se estarán proyectando. La proyección no se devolverá.Idea original de la dinámica: Luis Fernando Londoño
89. El tema que tiene que ver con procesos es como el habito de comer, uno puede comer de dos maneras, bien o mal en ultima instancia el fin "para muchas personas" es llenarse… Uno puede comer comida sana o comida chatarra y vive, puede vivir con mas dificultades pero vive,… Sin embargo "el que se alimenta bien tiene más posibilidades de sobrevivir“ Luis Fernando Londoño
95. ¿Cuáles son lascaracterísticas de calidadparaproductos de software? } Portabilidad Mantenibilidad Eficiencia Usabilidad Confiabilidad Funcionalidad ISO / IEC 9126
103. ¿Cuáles son lascaracterísticas de calidadparaproductos de software? { Eficiencia Comportamiento con respecto al tiempo Comportamiento con respecto a recursos
108. ¿Cómomejoramosla calidad? Acceptance Testing Requirement Analysis System Testing System Design Architecture Design Proceso Producto Integration Testing Module Design Coding Unit Testing
109. Conclusiones La calidad no se debedejarpara el final, esunaactividad transversal a todo el proceso
110. Conclusiones Es muyvaliosa la percepción del usuario, puesesquientrabaja y recibenuestroproducto. Es comúnver software hechosparaquienes lo desarrollaron y no paraquienes lo van a usar
111. Conclusiones El ser humanocuenta con unagrancapacidadparacrearhábitos. Creemoshábitosparaconstruir software con calidad
112. Conclusiones ¿La ingeniería de software está en pañales? No tanto, yaexistenmuchostrabajos y estudios en torno a ella, de nosotrosdependesuadopción, paraqueestadisciplinasigamadurando.
113. La calidad es exigida por todas las partes. Si la exigimos debemos colaborar con ella.
115. ¿Qué atributos de calidad tendrían los siguientes elementos? Estas imágenes son usadas con propósitos exclusivamente educativos Idea original de la dinámica: @betancur
117. 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…
118.
119. ¿Quién dice que siempresale mal?A pues no, no siempre sale mal…Solo algunas veces
120. CHAOS Report (Estudio de Resultado de Ejecución de los Proyectos de Software) Fuente: http://vidanp.wordpress.com/2010/02/01/estandares-de-medida/
122. Pues bien, muchos de estos errores son aducidos principalmente a falta de planeación y buenanálisis, cosa que tiene mucho sentido pero que sin embargo, no es la única razón…Como seres humanos involucrados en el Proceso de Software, cometemos errores que de no ser corregidos a tiempo, van aumentando su costo y consecuencias
138. Hasta ahora hemos hablando de conceptos generales, en la primera etapa, la etapa de análisis, hay muchas tareas por hacer… Para poner manos a la obra empezaremos por una tarea muy importante, la identificación de las necesidades del cliente
140. La ingeniería de software comprende una serie de actividades lo suficientemente diversas como para poder considerar la necesidad de otras ingenierías dentro de la propia Ingeniería de software, la Ingeniería de Requisitos es una de ellas.
142. Un requisito por definición es: una condición necesaria para algo. Podemos entenderlo en nuestro caso como un enunciado que identifica una capacidad, característica o factor de calidad de un sistema con el fin de que tenga utilidad para un cliente o usuario.
145. “La parte más difícil de construir de un sistema software es decidir qué construir. [..] Ninguna otra parte del trabajo afecta más negativamente al sistema final si se realiza de manera incorrecta. Ninguna otra parte es más difícil de rectificar después” Roger S. Pressman
146. “No se puede conocer la solución de un problema si antes no se conoce el problema.” Mirador - Monterrey, México 1994
147. Importancia de los Requisitos Mostrar que resultados quieren los participantes Dar a los participantes oportunidad de decir que quieren Representar diferentes puntos de vista Probar el diseño Medir el progreso Aceptar productos contra criterios precisos
148. Elicitación de Requisitos Especificación de todos los requisitos de un sistema, restricciones y condiciones definidas por los usuarios para el correcto, eficiente, y eficaz funcionamiento del sistema a construir.
168. ¿Conocen el juego?Si lo conocen, vamos a recordar, si no, vamos a aprender, ¡Como niños!
169. Escaleras y Serpientes Esta es la “Especificación” que se da a un niño de 5 años para que participe en el juego. Los jugadores se sitúan en la casilla de salida. Empieza a jugar quien mayor puntuación obtenga. El turno avanza de derecha a izquierda. Cada jugador lanza por turnos y avanza con su ficha tantas casillas como puntos saque. Si cae en una casilla situada al pie de las escaleras, avanza hasta el final de la misma. Si cae en la casilla ocupada por la cabeza de la serpiente, retrocede hasta la cola.
172. De acuerdo a la “Especificación” ¿Cual es el objetivo del juego? ¿Cual es la casilla de salida? ¿Cual es la ultima casilla? ¿Con cuantos dados se juega? Y es que, ¿Quién dijo que eran dados? ¿Hacia que dirección se avanza? ¿Cuantos jugadores pueden participar? Si se para en la cabeza ¿Retrocede hasta la cola?
173. ¡Ouch! Lo mismo sucede con las especificaciones de requisitos cuando son entregadas a los desarrolladores para que estos construyan los sistemas. Los desarrolladores no tienen la información suficiente para poder llevar a cabo bien su tarea, y si para colmo, cometen el error de suponer aquello que no saben, tenemos un problema mayor. “El sentido común, el es menos común de los sentidos”, y tiene una alta probabilidad de no coincidir con las necesidades de los usuarios.
175. Quedan muchos temas por aprender… Análisis, Modelamiento, Diseño y Arquitectura, Mejores Practicas de Codificación, Integración Continua, Pruebas de Software y más. Esperamos haber sembrado en ustedes la inquietud de aprender mucho más sobre Ingeniería de Software
