Este documento trata sobre ingeniería de software educativo. Explica brevemente qué es la ingeniería de software y por qué es importante aplicarla de manera responsable. También describe algunos roles clave en el proceso de desarrollo de software como gerente de proyectos, analista funcional y arquitecto de software. Finalmente, resalta la importancia de la calidad de software y algunas características como funcionalidad, confiabilidad y usabilidad.

1. Ingeniería de Software Educativo
¿Para qué complicarnos si podemos hacerlo fácil?
Mg. Juan Antonio CARBAJAL MAYHUA

2. Sensibilización
Juan Antonio Carbajal Mayhua

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

4. Con esta cátedra 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”

5. ¿Qué es Ingeniería de Software?
Busquemos una definición

6. 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.

7. Ingeniería del Software es el estudio de
los principios y metodologías para
desarrollo y mantenimiento de sistemas
de software.
Zelkovitz - 1978

8. 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.

9. 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
http://es.wikipedia.org/wiki/Ingenier%C3%ADa_del_software

10. Todo eso parece un
concepto muy elevado
para algo que parece ser
tan simple como
“hacer software”

11. 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…

12. ¡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?

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

14. Pero créanos, tampoco se la
inventaron ayer…

15. Se han preguntado alguna vez
¿Dónde hay software?
Para empezar a entender todo esto
hagamos una pequeña reflexión

23. ¿Quién es un ingeniero de software?
En esta cátedra, 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!

24. ¿Lo duda?
Veamos que tanto lo
involucra todo esto
Intente responder un par de
preguntas típicas

25. ¿Iría en un viaje
alrededor de la tierra
en globo, sabiendo
que este esta
controlado por una
computadora?

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

27. 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=UZq4sZ
z56qM

28. 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?

29. Comparemos…
¿Dudan los enfermos
del corazón de sus
médicos cirujanos?

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

31. ¿Dudan los acusados del abogado que defenderá
su inocencia?

32. ¿Dudan las personas
de los contadores
que les ayudan a
llevar sus finanzas?

33. ¿Dudas de ti? ¿Dudas de tu
equipo de trabajo?
Esto es una invitación a cuestionarse

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. 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…

36. ¿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)

37. 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

38. 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

39. 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=IONc
gYzVFlg

40. 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=_E
M0hDchVlY

41. ¿Qué tal las
respuestas?
¡Nada agradables
si me permiten
decirles!

42. 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.

43. Usemos otra analogía para entender
de que estamos hablando…

44. Si una edificación fuera nuestro proyecto…
¿Qué necesitaríamos para construirlo?

45. Veamos…
Herramientas
Personas
Tiempo
Dinero
Recursos
Estrategia

46. Parece intuitivo
¿No?

47. Sin embargo sabemos que en realidad, es
un poco más difícil de lo que imaginamos

48. Pues bien lo mismo sucede con la
construcción de software…
Para desarrollar software existen una
serie de roles asociados, encargados de
analizar, planificar y 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

49. 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.

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

51. Proceso de Software
juancarbajalm@undac.edu.pe

52. El ciclo de vida describe los estados
por los que pasa un producto de
software, desde su concepción
hasta su muerte.
Ciclo de Vida Clásico

53. Análisis
Diseño
Construcción
Pruebas
Operación y
Mantenimiento
Ciclo de Vida Clásico

54. 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…

55. Métodologías Estructuradas

57. MSF

58. Métodologías Ágiles

59. SCRUM
Individuos e
Interacciones
Software que
funciona
Colaboración con el
cliente
Responder ante el
cambio
Procesos y
herramientas
Documentación
exhaustiva
Negociación de
contratos
Seguimiento de un
plan
sobre
sobre
sobre
sobre
Manifiesto Ágil

60. 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…

61. Criterios de
selección

62. Complejidad

63. Costo/Beneficio Económico

64. Robustez del
software

65. Conocimiento disponible

66. Roles del Proceso
juancarbajalm@undac.edu.pe

67. 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.

68. Con el tema
de los roles
tampoco
debemos
permitir que
nos suceda
esto…

69. Gerente de Proyectos

70. Analista Funcional

71. Arquitecto de Software

72. Analista Diseñador

73. Analista Programador

74. Analista de Pruebas

75. Líder
técnico
Otros Roles

76. Dinámica Vivencial (Procesos y Roles)
www.juancarbajalm.net

77. Dinámica de Grupos
• Se requieren 3 grupos de 4 personas cada uno
• Cada grupo recibirá unos materiales (hoja de
números, resaltador, marcador y unas tijeras) y un conjunto de
instrucciones a seguir
• Cada grupo debe leer sus instrucciones en silencio y sin conversar
entre los integrantes a menos que así lo indique la hoja de
instrucciones.
• Los equipos deben seguir la estrategia definida en la hoja de
instrucciones sin modificarla, no debe copiarse la estrategia de otro
grupo.
• 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

78. 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“

79. Calidad de Software
UNDAC

80. ¿Qué es calidad?
“Quality is Value
to some person”
Gerald Weinberg

81. ¿Les ha ocurrido esto?
Lo sentimos por un error
en el sistema, no podemos
darle la información que
necesita. Por favor regrese
otro día…

82. ¿Nos tenemos que
acostumbrar?
¿Qué están
haciendo para
corregirlo?
¿Siempre vamos
a vivir con estos
errores?

83. “Cambiar la primera
impresión es muy
difícil”
“Perder la confianza
es fácil, volverla a
recuperar cuesta”
Dichos populares

84. Portabilidad
Mantenibilidad
Eficiencia
Usabilidad
Confiabilidad
Funcionalidad
ISO / IEC 9126
¿Cuáles son las características de calidad
para productos de software?

85. Funcionalidad
¿Las funciones y propiedades
satisfacen las necesidades explícitas
e implícitas?

86. Funcionalidad
Adecuación
Exactitud
Interoperabilidad
Conformidad
Seguridad

87. Confiabilidad
¿Puede mantener el nivel de
rendimiento, bajo ciertas
condiciones y por cierto
tiempo?

88. Confiabilidad
Nivel de Madurez
Tolerancia a Fallas
Recuperación

89. Usabilidad
¿El software es fácil de usar y
aprender?

90. Usabilidad
Comprensibilidad
Facilidad para Aprender
Operabilidad

91. Eficiencia
¿Es rápido y minimalista en cuanto al
uso de recursos?

92. ¿Cuáles son las características de calidad
para productos de software?
Eficiencia
{
Comportamiento con respecto al
tiempo
Comportamiento con respecto a
recursos

93. Mantenibilidad
¿Es fácil de modificar y
verificar?

94. Mantenibilidad
{
Capacidad de Análisis
Capacidad de Modificación
Estabilidad
Facilidad de Pruebas

95. Portabilidad
¿Es fácil de transferir de un
sistema a otro?

96. Portabilidad
Adaptabilidad
Facilidad de Instalación
Conformidad
Capacidad de Reemplazo

97. Requirement Analysis Acceptance Testing
Coding Unit Testing
Module Design
Integration Testing
Architecture Design
System Design System Testing
¿Cómo mejoramos la calidad?

98. Conclusiones
La calidad no se debe dejar para el final, es
una actividad transversal a todo el proceso

99. Es muy valiosa la percepción del usuario, pues es
quien trabaja y recibe nuestro producto.
Es común ver software hechos para quienes lo
desarrollaron y no para quienes lo van a usar
Conclusiones

100. El ser humano cuenta con una gran
capacidad para crear hábitos.
Creemos hábitos para construir software
con calidad
Conclusiones

101. ¿La ingeniería de software está en pañales?
No tanto, ya existen muchos trabajos y estudios
en torno a ella, de nosotros depende su
adopción, para que esta disciplina siga
madurando.
Conclusiones

103. Dinámica Vivencial (Calidad de Software)

104. ¿Qué atributos de calidad tendrían los
siguientes elementos?
Idea original de la dinámica: @betancur
Estas imágenes son usadas con propósitos exclusivamente educativos

105. Errores Típicos
UNDAC

106. 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…

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

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

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

111. Pues bien,
muchos de estos errores son aducidos
principalmente a falta de planeación y buen
aná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

112. ¿Qué errores se comenten?

113. Falta de comunicación

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

115. Falta de planificación

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

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

118. Mala estimación
de tiempos

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

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

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

122. Falta de seguimiento al
avance del proyecto

123. Falta de control del
presupuesto

124. Recursos Insuficientes

125. Tratar de construir sin tener una
arquitectura definida

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

127. 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

128. Ingeniería de Requisitos

129. 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.

130. Si, Ingeniería de
Requisitos y NO de
Requerimientos

131. 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.

132. ¿Les ha ocurrido?¿De quien es el error?

133. #OffTopic
¡Aquí otro
ejemplo de
problemas en
la definición
de requisitos!

134. “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

135. “No se puede conocer la
solución de un problema si
antes no se conoce el
problema.”
Mirador - Monterrey, México 1994

136. 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

137. 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.

138. Técnicas de Elicitación de Requisitos
 Lectura de información
 Cuestionarios y encuestas
 Observación
 Entrevistas
 Lluvia de Ideas
 JAD (Joint Application Design - Desarrollo
Conjunto de Aplicaciones)
 Modelos y/o prototipado
 Ingeniería reversa

139. ¿Quiénes debería estar involucrados?
Clientes
Usuarios
AnalistasDirectores
de Proyecto
Desarrolladores Arquitectos
Reguladores Expertos

140. Hay una serie de condiciones que
debe cumplir un requisito, para ser
considerado un buen requisito

141. Características de los Requisitos
 Comprensible por Clientes y Usuarios
 Correcto
 No Ambiguo
 Completo
 Consistente
 Verificable
 Rastreable
 Anotado con Importancia y Estabilidad
 Independiente del Diseño e Implementación

142. Hagamos un ejercicio, para
empezar a practicar… ¡Juguemos!

144. ¿Conocen el juego?
Si lo conocen, vamos a recordar, si
no, vamos a aprender, ¡Como niños!

145. 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.

146. ¿Todo está claro?

148. 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?

149. ¡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.

150. ¿Lo intentamos?
Workshop de
Requisitos

151. 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

152. ¡Gracias!