No hay bala de plata: esencia y accidentes de la Ingeniería de Software M.C. Ricardo Quintero (iscrquinter@acm.org) 1ra Et...
Reflexiones <ul><li>El disfrute del oficio </li></ul><ul><li>Las desgracias del oficio </li></ul><ul><li>La leyenda del Ho...
El  disfrute  del oficio Lo  divertido  de  hacer  cosas... El  placer  de que las  cosas que hacemos sean útiles a otras ...
El  disfrute  del oficio <ul><li>La programación es divertida porque despierta la creatividad que hay dentro de nosotros, ...
Las  desgracias  del oficio Debe   realizarse perfecto Dependemos   de  otros Otra persona  nos  asigna  los objetivos, re...
A pesar de todo ... <ul><li>Para muchos de nosotros  el disfrute sobrepasa a las desgracias  y hemos decidido continuar co...
La leyenda del “Hombre-lobo” De todos los monstruos que tenemos como parte del folclore  de nuestras pesadillas, ninguno e...
La leyenda del “Hombre-lobo” Para el  Hombre-lobo  buscamos una  bala de plata  que pueda -mágicamente- destruirlo ...o al...
Los proyectos de software tienen algo del “Hombre-lobo”... Al principio son  inocentes  y hasta parecen  factibles  (y has...
Ley de Brooks - 1986 <ul><li>“ ...there is no single development, in either technology or management technique, which by i...
Las Dificultades pueden ser Esenciales o Accidentales <ul><li>Esencial : una  cualidad   fundamental  del software. </li><...
Pero muchas de las dificultades accidentales ya han sido resueltas, por ejemplo... Mucha de la ganancia lograda en product...
¿Cuánto del esfuerzo realizado por los ingenieros de software es hacia lo accidental y no hacia lo esencial? <ul><li>“ ......
¿Cuál es la esencia del software? El software es una  construcción de   conceptos  interrelacionados: Esta  esencia es abs...
¿Cuál es la esencia del software? <ul><li>“ ...La parte difícil de construir software es la  especificación, diseño y prue...
El software es  complejo <ul><li>Porque: </li></ul><ul><ul><li>No hay dos partes iguales  (a menos a nivel superior al est...
Por esta  complejidad  se han generado muchos de los problemas del desarrollo de software Dificultad de comunicación  entr...
Por esta  complejidad  se han generado muchos de los problemas del desarrollo de software Dificultades de  gestión del pro...
Por esta  complejidad  se han generado muchos de los problemas del desarrollo de software Estas dificultades en la gestión...
Conformidad No solamente la gente que desarrolla software se enfrenta a la complejidad.  Los físicos, por ejemplo se tiene...
Conformidad Muchas de las veces los  sistemas de software  llegan  después  que los  sistemas de negocios  (estos ya exist...
Maleabilidad  Los  cambios  en edificios, automóviles y hardware de computadoras ocurren pero  no con la misma frecuencia ...
Maleabilidad  Todo software exitoso tiene  cambios  en dos aspectos principales ... Conforme el software resulta útil, los...
Invisibilidad El software es  invisible  y  no visualizable... Las  abstracciones geométricas  son poderosas para capturar...
Invisibilidad La realidad es que los  aspectos estructurales  son ... Muy complejos ... Ocultos ... Y poseen solamente una...
¿Hay alguna esperanza? Comparemos con la  medicina Se  dejó a un lado  las soluciones simples y creencias falsas para cura...
¿Hay alguna esperanza? Y comparemos con la  química Se  dejó a un lado  la  alquimia  ... ¿Podremos aprender algo de estas...
¡ Sí ! <ul><li>“ ...Un  esfuerzo disciplinado , consistente para desarrollar, propagar y explotar estas innovaciones, debe...
¿Qué podemos hacer para tratar de atacar la esencia? Ningún monto de actividad que se dedique a la  expresión de las const...
¿Qué podemos intentar para tratar de atacar la esencia? Comprar ,  no construir (reutilizar)... Refinamiento  de requisito...
Algunas referencias <ul><li>Parnas, D.L. “Designing software for ease of extention and contraction”, IEEE Trans. on SE, 5,...
 
Upcoming SlideShare
Loading in …5
×

No Silver Bullet

2,076 views
1,983 views

Published on

Published in: Technology, Education
1 Comment
0 Likes
Statistics
Notes
  • Be the first to like this

No Downloads
Views
Total views
2,076
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
47
Comments
1
Likes
0
Embeds 0
No embeds

No notes for slide

No Silver Bullet

  1. 1. No hay bala de plata: esencia y accidentes de la Ingeniería de Software M.C. Ricardo Quintero (iscrquinter@acm.org) 1ra Etapa de Capacitación Nacional
  2. 2. Reflexiones <ul><li>El disfrute del oficio </li></ul><ul><li>Las desgracias del oficio </li></ul><ul><li>La leyenda del Hombre-lobo </li></ul><ul><li>Dificultades esenciales y accidentales </li></ul><ul><li>La esencia del software </li></ul><ul><li>Conclusiones - ¿Qué podemos intentar? </li></ul>
  3. 3. El disfrute del oficio Lo divertido de hacer cosas... El placer de que las cosas que hacemos sean útiles a otras personas La fascinación de diseñar complejos rompecabezas... La diversión que conlleva el siempre aprender ... El disfrute de trabajar con algo tan maleable : el pensamiento (como los poetas)...
  4. 4. El disfrute del oficio <ul><li>La programación es divertida porque despierta la creatividad que hay dentro de nosotros, con la cual podemos obtener placeres comunes que tenemos todos los seres humanos. </li></ul>
  5. 5. Las desgracias del oficio Debe realizarse perfecto Dependemos de otros Otra persona nos asigna los objetivos, recursos y la información necesaria Diseñar conceptos es divertido, pero construirlos es el trabajo real Usualmente el producto que se está construyendo se nos vuelve obsoleto antes de terminarlo
  6. 6. A pesar de todo ... <ul><li>Para muchos de nosotros el disfrute sobrepasa a las desgracias y hemos decidido continuar con esta profesión ... </li></ul>
  7. 7. La leyenda del “Hombre-lobo” De todos los monstruos que tenemos como parte del folclore de nuestras pesadillas, ninguno es más terrorífico que el Hombre-lobo , porque se transforma –inesperadamente- de lo familiar a lo horrorífico ...
  8. 8. La leyenda del “Hombre-lobo” Para el Hombre-lobo buscamos una bala de plata que pueda -mágicamente- destruirlo ...o al menos “mandarlo a descansar”
  9. 9. Los proyectos de software tienen algo del “Hombre-lobo”... Al principio son inocentes y hasta parecen factibles (y hasta fáciles ) ... Entregas fuera de tiempo ... Presupuestos incorrectos ... y productos inútiles Pero son capaces de convertirse en Caracterizados por ...
  10. 10. Ley de Brooks - 1986 <ul><li>“ ...there is no single development, in either technology or management technique, which by itself promises even one order of magnitud improvement in productivity, in reliability, in simplicitiy within ten years ...” </li></ul>Frederick P. Brooks ganador del premio A. M. Turing (ACM) en 1999 (El Premio Nobel de la Computación)
  11. 11. Las Dificultades pueden ser Esenciales o Accidentales <ul><li>Esencial : una cualidad fundamental del software. </li></ul><ul><ul><li>Constituye o forma parte de la esencia de algo; es inherente. </li></ul></ul><ul><li>Accidental : un problema en los métodos de producción actuales </li></ul><ul><ul><li>Relativo a una propiedad, factor o atributo que no es esencial </li></ul></ul>
  12. 12. Pero muchas de las dificultades accidentales ya han sido resueltas, por ejemplo... Mucha de la ganancia lograda en productividad de software ha sido consecuencia de eliminar estas barreras artificiales que hacen que las tareas accidentales sean “inordinariamente” difíciles La dificultad de programar por el bajo nivel de abstracción de los lenguajes ... Facilitar el acceso al poder de cómputo ... El uso de múltiples herramientas : ambientes integrados de desarrollo ...
  13. 13. ¿Cuánto del esfuerzo realizado por los ingenieros de software es hacia lo accidental y no hacia lo esencial? <ul><li>“ ...para que exista una mejora significativa en la productividad, confiabilidad y simplicidad, el 90% de las dificultades al desarrollar software deberían ser accidentales (poco probable) y las técnicas y herramientas deberían buscar reducirlas al 0% (difícil que ocurra)...” </li></ul>
  14. 14. ¿Cuál es la esencia del software? El software es una construcción de conceptos interrelacionados: Esta esencia es abstracta , en el sentido de que la construcción conceptual es la misma bajo muchas representaciones diferentes . No obstante es altamente precisa y ricamente detallada . Conjuntos de datos Relaciones entre datos Algoritmos Invocación de funciones
  15. 15. ¿Cuál es la esencia del software? <ul><li>“ ...La parte difícil de construir software es la especificación, diseño y prueba de esta construcción conceptual , no la labor de representarla y probar la fidelidad de esta representación...” </li></ul>Si esto es verdad, construir software siempre será difícil . De forma inherente la bala de plata no existe ... Consideremos entonces las propiedades inherentes de esta esencia irreducible de los sistemas de software: complejidad , conformidad , maleabilidad e invisibilidad
  16. 16. El software es complejo <ul><li>Porque: </li></ul><ul><ul><li>No hay dos partes iguales (a menos a nivel superior al estatuto, si así fuera lo hacemos subrutina). </li></ul></ul><ul><ul><li>El número de estados del software es mucho mayor que cualquier otro hardware creado por el hombre. </li></ul></ul><ul><ul><li>Escalar software no es la repetición de elementos en un tamaño mayor: es necesario incrementar el número de elementos (y esto se ve afectado por el aumento en la complejidad de la interrelación con los elementos restantes). </li></ul></ul>
  17. 17. Por esta complejidad se han generado muchos de los problemas del desarrollo de software Dificultad de comunicación entre los miembros del equipo... Dificultad de enumerar (mucho menos entender) todos los posibles estados de un programa (y de ahí viene la falta de confiabilidad)... Dificultad de invocar funciones complejas, lo cual hace a los programas difíciles de utilizar
  18. 18. Por esta complejidad se han generado muchos de los problemas del desarrollo de software Dificultades de gestión del proyecto
  19. 19. Por esta complejidad se han generado muchos de los problemas del desarrollo de software Estas dificultades en la gestión de proyectos conllevan al problema de Integridad Conceptual La Integridad Conceptual es la consideración más importante en el diseño de sistemas. Es mejor tener un sistema que omita ciertas características fantásticas y mejoras, pero que refleje un conjunto de ideas de diseño coherente y no un conjunto de ideas brillantes independientes y no coordinadas Muchas catedrales Europeas muestran diferencias en los planes y el estilo arquitectónico entre partes construidas por diferentes generaciones y diferentes constructores. Los últimos intentaron mejorar los diseños de los primeros por moda o gusto personal ...
  20. 20. Conformidad No solamente la gente que desarrolla software se enfrenta a la complejidad. Los físicos, por ejemplo se tienen que enfrentar con objetos terriblemente complejos , aún en las partículas fundamentales... Sin embargo, los físicos fundamentan su labor en una fe firme de que existen principios unificadores que deben encontrarse en cualquier área de su estudio “ Deben existir explicaciones sencillas de la naturaleza, porque Dios no es caprichoso o arbitrario ...”
  21. 21. Conformidad Muchas de las veces los sistemas de software llegan después que los sistemas de negocios (estos ya existen). A diferencia de la naturaleza, estos sistemas fueron creados por humanos ... Mucha de la complejidad que debe enfrentar el ingeniero de software es arbitraria, forzada sin ritmo y razón por las instituciones humanas y los sistemas a los cuales las interfaces de la aplicación debe conformarse “ Como el sistema suele ser el último que llega , a él le toca conformarse. Además siempre es visto como lo más fácil de conformar (sic) ...”
  22. 22. Maleabilidad Los cambios en edificios, automóviles y hardware de computadoras ocurren pero no con la misma frecuencia que el software... Esto es porque el software encierra funcionalidad y esta es la parte más sujeta a la presión del cambio . A su vez esta funcionalidad está hecha del material más altamente maleable : el pensamiento “ Los edificios también se pueden cambiar, pero los costos son altos y eso impide el cambio frecuente..”
  23. 23. Maleabilidad Todo software exitoso tiene cambios en dos aspectos principales ... Conforme el software resulta útil, los usuarios intentan usarlo en nuevos casos en la frontera del dominio (o más allá) inventan nuevos usos para él ... El software exitoso sobrevive más allá de la vida normal del hardware
  24. 24. Invisibilidad El software es invisible y no visualizable... Las abstracciones geométricas son poderosas para capturar realidades geométricas, pero la realidad del software es que no está incrustado en el espacio
  25. 25. Invisibilidad La realidad es que los aspectos estructurales son ... Muy complejos ... Ocultos ... Y poseen solamente una vista externa de entrada/salida
  26. 26. ¿Hay alguna esperanza? Comparemos con la medicina Se dejó a un lado las soluciones simples y creencias falsas para curar las enfermedades... Para aplicar un esfuerzo persistente que lentamente logre erradicar las enfermedades
  27. 27. ¿Hay alguna esperanza? Y comparemos con la química Se dejó a un lado la alquimia ... ¿Podremos aprender algo de estas disciplinas? Para invertir muchos años en la comprensión del átomo y después aprender a sintetizar el oro...
  28. 28. ¡ Sí ! <ul><li>“ ...Un esfuerzo disciplinado , consistente para desarrollar, propagar y explotar estas innovaciones, debería llevarnos a una mejora significativa en orden-de-magnitud. No hay camino de reyes, pero al menos hay un camino...” </li></ul>¡Este se parece a mi!
  29. 29. ¿Qué podemos hacer para tratar de atacar la esencia? Ningún monto de actividad que se dedique a la expresión de las construcciones conceptuales de las tareas puede darnos grandes ganancias en productividad Se debe entonces considerar atacar la esencia del software , en pocas palabras “ la formulación de las complejas estructuras conceptuales ”
  30. 30. ¿Qué podemos intentar para tratar de atacar la esencia? Comprar , no construir (reutilizar)... Refinamiento de requisitos y prototipado rápido ... Desarrollo incremental (grow don’t build)... Más entrenamiento en SE y nutrirse de los grandes
  31. 31. Algunas referencias <ul><li>Parnas, D.L. “Designing software for ease of extention and contraction”, IEEE Trans. on SE, 5,2 (March, 1979), pp. 128-138 </li></ul><ul><li>Parnas, D.L. “Software aspects of strategic defense systems”, Communications of the ACM, 28, 12 (De. 1985). Pp. 1326-1335. </li></ul><ul><li>Boehm, B.W., “A spiral model of software development and enhancement”, Computer, 20, 5 (May, 1985). </li></ul>

×