Taller ingenieria de software

6.971 visualizaciones

Publicado el

Taller ingenieria de software

  1. 1. Taller: Ingeniería de Software<br />¿Para qué complicarnos si podemos hacerlo fácil?<br />
  2. 2. Talleristas<br />Hernán Guzmán<br />Cristian Aroca<br />Sorey García<br />Apoyo<br />Orlando Contreras<br />David Ramirez<br />Cubrimiento<br />Angelo Cardona (Streaming)<br />Jenny Chica (Fotografía)<br />Pavel Espitia (Twitter y Chat)<br />Asesor Tecnoparque<br />Julián Guevara<br />
  3. 3. ¿Qué es Avanet?<br />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.<br />
  4. 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: <br />“Asociación de personas cuyo objeto es el cultivo y el progreso de las artes, las letras, ciencia, tecnología, etc.”<br />
  5. 5. Sensibilización<br />Sorey García (@soreygarcia)<br />
  6. 6. El por qué de este taller<br />La ingeniería de software y la calidadnos resultan temas apasionantes…<br />Ser humanamente responsable <br />nos resulta un reto<br />Intentar hacer las dos primeras sin la última es claramente un despropósito <br />
  7. 7. Con este taller no pretendemos enseñarle a ser “humanamente responsable”<br />Lo único que queremos es darle algunas ideas de “por qué debería serlo” <br />si se dedica usted al tema de <br />“hacer software”<br />
  8. 8. ¿Qué es Ingeniería de Software?<br />Busquemos una definición<br />
  9. 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. <br />Bohem - 1976. <br />
  10. 10. Ingeniería del Software es el estudio de los principios y metodologías para desarrollo y mantenimiento de sistemas de software. <br />Zelkovitz - 1978<br />
  11. 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. <br />IEEE - 1993. <br />
  12. 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 <br />
  13. 13. Todo eso parece un concepto muy elevado <br />para algo que parece ser tan simple como <br />“hacer software”<br />
  14. 14. Si, es cierto…<br />Es tan simple que puedes aprenderlo en internet, incluso trabajar en ello <br />y ganar mucho más, <br />que muchos de los que estudian física, <br />matemáticas y ética…<br />
  15. 15. ¡Ups!...<br />Un momento, nadie dijo que lo hicieras bien, solo que también podías hacerlo, hacer lo simple…<br />y… ¿Por qué conformarse con eso?<br />
  16. 16. Quizá la Ingeniería de Software no tiene tantos años como la física, matemáticas o arquitectura… <br />
  17. 17. Pero créanos, tampoco se la inventaron ayer…<br />
  18. 18. Para empezar a entender todo esto<br />hagamos una pequeña reflexión<br />Se han preguntado alguna vez¿Dónde hay software?<br />
  19. 19.
  20. 20.
  21. 21.
  22. 22.
  23. 23.
  24. 24.
  25. 25.
  26. 26. ¿Quién es un ingeniero de software?<br />En este taller, cuando hablamos de un ingeniero de software no hablamos de un ingeniero titulado, hablamos de una persona involucrada en el proceso <br />de construcción de cualquier producto de software… <br />¡Hablamos de usted!<br />
  27. 27. ¿Lo duda?Veamos que tanto lo involucra todo estoIntente responder un par de preguntas típicas<br />
  28. 28. ¿Iría en un viaje alrededor de la tierra en globo, sabiendo que este esta controlado por una computadora?<br />
  29. 29. ¿Viajaría usted en un avión cuyo software ha sido construido por usted?<br />
  30. 30. Si estas preguntas le producen un tanto de risa o duda, lo invitamos a replantearse…<br />El tema de que nuestra profesión sea un chiste, ha sido comparado con este video:<br />¿Qué pasaría si los programadores construyeran aviones?<br />http://www.youtube.com/watch?v=UZq4sZz56qM<br />
  31. 31. Gracioso¿No?¡Pues NO!<br />No es gracioso que siendo un profesional tu trabajo <br />sea tomado en broma…El problema es<br />¿Qué pasa si nosotros mismos nos tomamos nuestro trabajo en broma?<br />
  32. 32. Comparemos…¿Dudan los enfermos del corazón de sus médicos cirujanos?<br />
  33. 33. ¿Dudan los empresarios de los ingenieros civiles y arquitectos que construyen sus edificios?<br />
  34. 34. ¿Dudan los acusados del abogado que defenderá su inocencia?<br />
  35. 35. ¿Dudan las personas de los contadores que les ayudan a llevar sus finanzas?<br />
  36. 36. Esto es una invitación a cuestionarse<br />¿Dudas de ti? ¿Dudas de tu equipo de trabajo?<br />
  37. 37. Aquí va una propuesta de una definición menos formal<br />La ingeniería de software es una idea casi ética (no solo ética) de como hacer el software de forma correcta (software de calidad)<br />
  38. 38. Y hacer las cosas bien, siempre va a requerir un poco más de esfuerzo, que hacerlas de cualquier otro modo<br />No hacerlo, siempre va a tener consecuencias… <br />
  39. 39. ¿Qué consecuencias?¿Acaso en software no importa es básicamente que funcione?Veamos algunas respuestas a esa pregunta…<br />(Ojo, lassiguientesimagenes son meramenteilustrativa, no todaspertenecen al hechodescrito)<br />
  40. 40. Therac-25 <br />(1985 – 1987)<br />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<br />
  41. 41. Mariner 1<br />(28 de Julio de 1962)<br />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<br />
  42. 42. Vuelo 501 del ARIANE-5<br />(4 de Junio de 1996)<br />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)<br />http://www.youtube.com/watch?v=IONcgYzVFlg<br />
  43. 43. A-320 de Air France<br />(26 de junio de 1988)<br />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. <br />Justo después, el mundo se pregunta las causas del accidente del avión anunciado como "el más seguro del mundo".<br />Una de las causas se le atribuye a un error en el software de navegación<br />http://www.youtube.com/watch?v=_EM0hDchVlY<br />
  44. 44. ¿Qué tal las respuestas?<br />¡Nada agradables si me permiten decirles!<br />
  45. 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.<br />
  46. 46. Usemos otra analogía para entender<br />de que estamos hablando…<br />
  47. 47. Si una edificación fuera nuestro proyecto…<br />¿Qué necesitaríamos para construirlo?<br />
  48. 48. Veamos…<br /><ul><li>Herramientas
  49. 49. Personas
  50. 50. Tiempo
  51. 51. Dinero
  52. 52. Recursos
  53. 53. Estrategia</li></li></ul><li>Parece intuitivo ¿No?<br />
  54. 54. Sin embargo sabemos que en realidad, es un poco más difícil de lo que imaginamos<br />
  55. 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<br />
  56. 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.<br />
  57. 57. Practicas y Principios<br />Actividades<br />Herramientas<br />Personas<br />Proceso de Software<br />Notación<br />Roles<br />Artefactos<br />Pressman<br />
  58. 58. Proceso de Software<br />Hernan Guzmán (@hernandgr)<br />
  59. 59. Ciclo de Vida Clásico<br />El ciclo de vida describe los estados por los que pasa un producto de software, desde su concepción hasta su muerte.<br />
  60. 60. Ciclo de Vida Clásico<br />Análisis<br />Diseño<br />Construcción<br />Pruebas<br />Operación y Mantenimiento<br />
  61. 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.<br />Conozcamos algunas…<br />
  62. 62. MétodologíasEstructuradas<br />
  63. 63. RUP<br />
  64. 64. Microsoft <br />Solutions<br />Framework<br />MSF<br />
  65. 65. MétodologíasÁgiles<br />
  66. 66. SCRUM<br />AUP<br />Manifiesto Ágil<br />Individuos e Interacciones<br />Procesos y herramientas<br />sobre<br />XP<br />Software que funciona<br />Documentación exhaustiva<br />sobre<br />Colaboración con el cliente<br />Negociación de contratos<br />sobre<br />Responder ante el cambio<br />Seguimiento de un plan<br />sobre<br />
  67. 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… <br />
  68. 68. Criterios de <br />selección<br />
  69. 69. Complejidad<br />
  70. 70. Costo/BeneficioEconómico<br />
  71. 71. Robustez del software<br />
  72. 72. Conocimiento disponible<br />
  73. 73. Roles del Proceso<br />Hernan Guzmán (@hernandgr)<br />
  74. 74. El desarrollo de software es una actividad que, dada su complejidad, debe desarrollarse en grupo. <br />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.<br />Cada una de esas personas aportará al grupo parte del total de las capacidades necesarias para llevar a cabo con éxito el desarrollo.<br />
  75. 75. Con el tema de los roles tampoco debemos permitir que nos suceda esto…<br />
  76. 76. Gerente de Proyectos<br />
  77. 77. Analista Funcional<br />
  78. 78. Arquitecto de Software<br />
  79. 79. Analista Diseñador<br />
  80. 80. Analista Programador<br />
  81. 81. Analista de Pruebas<br />
  82. 82. Revisor<br />par<br />Usuario<br />Otros Roles<br />Líder técnico<br />
  83. 83. Dinámica Vivencial (Procesos y Roles)<br />Orlando Contreras (@magicovercast)<br />
  84. 84. Dinámica de Grupos<br /><ul><li>Se requieren 3 grupos de 4 personas cada uno
  85. 85. Cada grupo recibirá unos materiales (hoja de números, resaltador, marcador y unas tijeras) y un conjunto de instrucciones a seguir
  86. 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. 87. Los equipos deben seguir la estrategia definida en la hoja de instrucciones sin modificarla, no debe copiarse la estrategia de otro grupo.
  88. 88. A la señal los equipos deben iniciar con las tareas que se estarán proyectando. La proyección no se devolverá.</li></ul>Idea original de la dinámica: Luis Fernando Londoño<br />
  89. 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… <br />Uno puede comer comida sana o comida chatarra y vive, puede vivir con mas dificultades pero vive,… <br />Sin embargo "el que se alimenta bien tiene más posibilidades de sobrevivir“<br />Luis Fernando Londoño<br />
  90. 90. Calidad de Software<br />Cristian Aroca (@caroca315)<br />
  91. 91. ¿Quéescalidad?<br />“Quality is Value <br />to some person”<br />Gerald Weinberg<br />
  92. 92. ¿Les ha ocurridoesto?<br />Lo sentimos por un error en el sistema, no podemos darle la información que necesita. Por favor regrese otro día…<br />
  93. 93. ¿Siempre vamos a vivir con estos errores? <br />¿Nos tenemos que acostumbrar? <br />¿Qué están haciendo para corregirlo? <br />
  94. 94. “Cambiar la primeraimpresiónesmuydifícil”<br />“Perder la confianzaesfácil, volverla a recuperarcuesta”<br />Dichospopulares<br />
  95. 95. ¿Cuáles son lascaracterísticas de calidadparaproductos de software?<br />}<br />Portabilidad<br />Mantenibilidad<br />Eficiencia<br />Usabilidad<br />Confiabilidad<br />Funcionalidad<br />ISO / IEC 9126<br />
  96. 96. Funcionalidad<br />¿Las funciones y propiedadessatisfacenlasnecesidadesexplícitas e implícitas?<br />
  97. 97. {<br />Funcionalidad<br />Adecuación<br />Exactitud<br />Interoperabilidad<br />Conformidad<br />Seguridad<br />
  98. 98. Confiabilidad<br />¿Puedemantener el nivel de rendimiento, bajociertascondiciones y porciertotiempo?<br />
  99. 99. {<br />Confiabilidad<br />Nivel de Madurez<br />Tolerancia a Fallas<br />Recuperación<br />
  100. 100. Usabilidad<br />¿El software esfácil de usar y aprender?<br />
  101. 101. {<br />Usabilidad<br />Comprensibilidad<br />FacilidadparaAprender<br />Operabilidad<br />
  102. 102. Eficiencia<br />¿Es rápido y minimalista en cuanto al uso de recursos?<br />
  103. 103. ¿Cuáles son lascaracterísticas de calidadparaproductos de software?<br />{<br />Eficiencia<br />Comportamiento con respecto al tiempo<br />Comportamiento con respecto a recursos<br />
  104. 104. Mantenibilidad<br />¿Es fácil de modificar y verificar?<br />
  105. 105. {<br />Capacidad de Análisis<br />Capacidad de Modificación<br />Mantenibilidad<br />Estabilidad<br />Facilidad de Pruebas<br />
  106. 106. Portabilidad<br />¿Es fácil de transferir de un sistema a otro?<br />
  107. 107. {<br />Portabilidad<br />Adaptabilidad<br />Facilidad de Instalación<br />Conformidad<br />Capacidad de Reemplazo<br />
  108. 108. ¿Cómomejoramosla calidad?<br />Acceptance Testing<br />Requirement Analysis<br />System Testing<br />System Design<br />Architecture Design<br />Proceso<br />Producto<br />Integration Testing<br />Module Design<br />Coding<br />Unit Testing<br />
  109. 109. Conclusiones<br />La calidad no se debedejarpara el final, esunaactividad transversal a todo el proceso<br />
  110. 110. Conclusiones<br />Es muyvaliosa la percepción del usuario, puesesquientrabaja y recibenuestroproducto.<br />Es comúnver software hechosparaquienes lo desarrollaron y no paraquienes lo van a usar<br />
  111. 111. Conclusiones<br />El ser humanocuenta con unagrancapacidadparacrearhábitos. <br />Creemoshábitosparaconstruir software con calidad<br />
  112. 112. Conclusiones<br />¿La ingeniería de software está en pañales?<br />No tanto, yaexistenmuchostrabajos y estudios en torno a ella, de nosotrosdependesuadopción, paraqueestadisciplinasigamadurando.<br />
  113. 113. La calidad es exigida por todas las partes. <br />Si la exigimos debemos colaborar con ella.<br />
  114. 114. Dinámica Vivencial (Calidad de Software)<br />Orlando Contreras (@magicovercast)<br />
  115. 115. ¿Qué atributos de calidad tendrían los siguientes elementos?<br />Estas imágenes son usadas con propósitos exclusivamente educativos<br />Idea original de la dinámica: @betancur<br />
  116. 116. Errores Típicos<br />Sorey García (@soreygarcia)<br />
  117. 117. Los principios y practicas que pueden seguirse en la Ingeniería de Software, buscan garantizar un mejor resultado y uso de los recursos<br />Pero, por alguna razón el comportamiento de los proyectos no es “aún” el esperado…<br />
  118. 118.
  119. 119. ¿Quién dice que siempresale mal?A pues no, no siempre sale mal…Solo algunas veces<br />
  120. 120. CHAOS Report <br />(Estudio de Resultado de Ejecución de los Proyectos de Software)<br />Fuente: http://vidanp.wordpress.com/2010/02/01/estandares-de-medida/<br />
  121. 121. Seguimos cayendo en los mismos errores una y otra vez…<br />
  122. 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<br />
  123. 123. ¿Qué errores se comenten?<br />
  124. 124. Falta de comunicación<br />
  125. 125. Ausencia de objetivos y metas claras durante la ejecución del proyecto<br />
  126. 126. Falta de planificación<br />
  127. 127. Falta de análisis y entendimiento de las necesidades del cliente<br />
  128. 128. Requisitos poco claros y falta de acceso a la información<br />
  129. 129. Mala estimación<br />de tiempos<br />
  130. 130. Indefinición del alcance y las responsabilidades de las partes<br />
  131. 131. Falta de identificación y gestión de los riesgos<br />
  132. 132. Carencia de habilidades en la ejecución de un rol<br />
  133. 133. Falta de seguimiento al avance del proyecto<br />
  134. 134. Falta de control del presupuesto<br />
  135. 135. Recursos Insuficientes<br />
  136. 136. Tratar de construir sin tener una arquitectura definida<br />
  137. 137. Falta de conocimiento e interés en la aplicación de mejores prácticas<br />
  138. 138. Hasta ahora hemos hablando de conceptos generales, en la primera etapa, la etapa de análisis, hay muchas tareas por hacer…<br />Para poner manos a la obra empezaremos por una tarea muy importante, la identificación de las necesidades del cliente<br />
  139. 139. Ingeniería de Requisitos<br />Sorey García (@soreygarcia)<br />
  140. 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.<br />
  141. 141. Si, Ingeniería de Requisitosy NO de<br />Requerimientos<br />
  142. 142. Un requisito por definición es: una condición necesaria para algo.<br />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.<br />
  143. 143. ¿Les ha ocurrido?¿De quien es el error?<br />
  144. 144. #OffTopic<br />¡Aquí otro ejemplo de problemas en la definición de requisitos!<br />
  145. 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”<br />Roger S. Pressman<br />
  146. 146. “No se puede conocer la solución de un problema si antes no se conoce el problema.”<br />Mirador - Monterrey, México 1994<br />
  147. 147. Importancia de los Requisitos<br />Mostrar que resultados quieren los participantes<br />Dar a los participantes oportunidad de decir que quieren<br />Representar diferentes puntos de vista<br />Probar el diseño<br />Medir el progreso<br />Aceptar productos contra criterios precisos<br />
  148. 148. Elicitación de Requisitos<br />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.<br />
  149. 149. Técnicas de Elicitación de Requisitos<br /><ul><li>Lectura de información
  150. 150. Cuestionarios y encuestas
  151. 151. Observación
  152. 152. Entrevistas
  153. 153. Lluvia de Ideas
  154. 154. JAD (JointApplicationDesign - Desarrollo Conjunto de Aplicaciones)
  155. 155. Modelos y/o prototipado
  156. 156. Ingeniería reversa</li></li></ul><li>¿Quiénes debería estar involucrados?<br />Clientes<br />Analistas<br />Directores<br />de Proyecto<br />Desarrolladores<br />Arquitectos<br />Expertos<br />Reguladores<br />Usuarios<br />
  157. 157. Hay una serie de condiciones que debe cumplir un requisito, para ser considerado un buen requisito<br />
  158. 158. Características de los Requisitos<br /><ul><li>Comprensible por Clientes y Usuarios
  159. 159. Correcto
  160. 160. No Ambiguo
  161. 161. Completo
  162. 162. Consistente
  163. 163. Verificable
  164. 164. Rastreable
  165. 165. Anotado con Importancia y Estabilidad
  166. 166. Independiente del Diseño e Implementación</li></li></ul><li>Hagamos un ejercicio, para empezar a practicar… ¡Juguemos!<br />
  167. 167.
  168. 168. ¿Conocen el juego?Si lo conocen, vamos a recordar, si no, vamos a aprender, ¡Como niños!<br />
  169. 169. Escaleras y Serpientes<br />Esta es la “Especificación” que se da a un niño de 5 años para que participe en el juego.<br />Los jugadores se sitúan en la casilla de salida. <br />Empieza a jugar quien mayor puntuación obtenga.<br />El turno avanza de derecha a izquierda.<br />Cada jugador lanza por turnos y avanza con su ficha tantas casillas como puntos saque.<br />Si cae en una casilla situada al pie de las escaleras, avanza hasta el final de la misma.<br />Si cae en la casilla ocupada por la cabeza de la serpiente, retrocede hasta la cola.<br />
  170. 170. ¿Todo está claro? <br />
  171. 171.
  172. 172. De acuerdo a la “Especificación”<br />¿Cual es el objetivo del juego?<br />¿Cual es la casilla de salida?<br />¿Cual es la ultima casilla?<br />¿Con cuantos dados se juega?<br />Y es que, ¿Quién dijo que eran dados?<br />¿Hacia que dirección se avanza?<br />¿Cuantos jugadores pueden participar?<br />Si se para en la cabeza ¿Retrocede hasta la cola?<br />
  173. 173. ¡Ouch!<br />Lo mismo sucede con las especificaciones de requisitos cuando son entregadas a los desarrolladores para que estos construyan los sistemas.<br />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.<br />“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.<br />
  174. 174. ¿Lo intentamos?<br />Workshop de Requisitos<br />
  175. 175. Quedan muchos temas por aprender…<br />Análisis, Modelamiento, Diseño y Arquitectura, Mejores Practicas de Codificación, Integración Continua, Pruebas de Software y más.<br />Esperamos haber sembrado en ustedes la inquietud de aprender mucho más sobre Ingeniería de Software<br />
  176. 176. ¡Gracias!<br />

×