Hoy presentamos. . .
A View of 20th and 21st Century
Software Engineering
por Barry Boehm1, presentado en la ACM ICSE 2006
Daniela Blanco, Diego de Estrada, Matías Marino y Laura Pérez Vultaggio
21 de Octubre, 2010
1Nacido en 1937 en los EEUU, se doctoró en Matemáticas en la UCLA en
En la primera clase. . .
Santiago nos lo dejó picando:
!" #$%&%'()*&+,&*-'+./012&3*&+,&425*20*)6,&3*&7'89:,)*
4=">?@"->A0(%)+%&"%&+&("&+"B?&+%)"C?&"D)"B0+=%(?BB-E+" '&"=01%2)(&"B)>F-E"'($=%-B)>&+%&"&+"D)="GD%->)=" 'HB)')=I
-HIHD%RHKPHQORV³(VFXFKDPHDWHQWDPHQWH
&=%0@"A),)+'0"J;;"'ED)(&="A0("K0()"A0("&=%)" B0>A?%)'0()"@":"'ED)(&="A0("K0()"A0("L0=9")=."C?&"
HVSHURTXHDFW~HVGHDFXHUGRDHVR´
#)')"HA0B)"'&ME"A(-+B-A-0="1?+')>&+%)D&= N&("70&K>I"³$9LHZRIWKDQGVW&HQWXU\
6RIWZDUH(QJLQHHULQJ´9"*#/4":;;JO"
6+)"L-=-E+"P&,&D-)+)"'&"D)"*+,&+-&(.)"'&"/01%2)(&I" %&=-=9")+%.%&=-=9"=.+%&=-=
El idealismo dialéctico
En 1808, Hegel presentó la hipótesis de que el incremento en el entendimiento humano sigue un camino:
1 Tesis explicación de por qué suceden ciertas cosas. 2 Antítesis la tesis falla en algunas circunstancias
importantes; aquí hay una mejor explicación.
3 Síntesis la antítesis rechaza demasiado de la tesis original;
aquí hay un híbrido que captura lo mejor de ambos y evita sus defectos.
Perspectiva hegeliana de la evolución
Tesis
Síntesis
1950s: hacer software como si fuera hardware
Los programadores eran ingenieros y matemáticos.
Tenían buenas prácticas, como razonar antes de programar. Usaban procesos secuenciales de desarrollo, como con el hardware.
1960s: software y hardware son muy distintos
El SW es mucho más barato de replicar que el HW. También es fácil de modificar, hay lenguajes de alto nivel: surgeCode and fix.
Estimar la confiabilidad y hacer mantenimiento de SW es muy distinto a HW: se hacen las conferencias NATO para sentar las bases en 1968 y 1969.
Especificar SW es muy difícil, dijo Winston Royce: “Para un dispositivo de HW de $5 millones, una especificación de 30 páginas provee un nivel de detalle adecuado para controlarlo. Para $5 millones de SW, una especificación de 1500 páginas sería necesaria para lograr un control comparable.”
La demanda de programadores sobrepasa a la disponibilidad de ingenieros: Code and fixse vuelve ubicuo; código
espagueti; nace la cultura hacker con loscowboy programmers
1970s: modelo Waterfall y Programación estructurada
Surge la Programación estructurada; principios de
modularización de Constantine (acoplamiento y cohesión), Parnas (information hiding) y Liskov (TADs).
Síntesis de los paradigmas de 50s y 60s: modelo Waterfall de Royce. Fue malinterpretado como puramente secuencial, incluso por el gobierno al estandarizarlo.
Esto favoreció el enfoque cuantitativo para estimar
confiabilidad, calidad, costos y tiempo, e identificar módulos problemáticos.
1980s: aumentar productividad y escalabilidad
Surgen entornos de desarrollo integrados y herramientas CASE (Ingeniería de SW asistida por computadora). El DoD crea el programa STARS: énfasis en generar código automáticamente desde especificaciones formales y acelerar la transición tecnológica (los conceptos tardaban en promedio
18 añosen llegar a la práctica).
“No silver bullet”pone en perspectiva las ideas de
productividad de la época (sistemas expertos, lenguajes de muy alto nivel, programación visual). Propone diseñar bien, prototipar rápido y desarrollar evolutivamente.
El camino es evitar trabajo reutilizando código: la POO lo hace posible, facilitando el mantenimiento de código (que ocupaba entre 50 y 75 % de las agendas).
1990s: procesos concurrentes y usabilidad
POO se fortalece con patrones de diseño, arquitecturas y sus lenguajes de descripción, y UML.
Usabilidad de software, investigación seria en Interacción persona-computador.
El mercado se vuelve muy competitivo: necesario disminuir el
time to market.
Productos interactivos con el usuario: requerimientos no preespecificables (“No sé cómo lo quiero, pero lo sabré cuando lo vea”).
Por los dos últimos ítems se abandona el modelo Waterfall secuencial: surgen procesos de desarrollo concurrentes, incrementales y evolutivos.
2000s: agilidad y valor
El ritmo de cambio se acelera, hay frustración con la documentación pesada (ejemplo: una organización presentó 99 carpetas para unaevaluación CMM).
Surgen los métodos ágiles (Agile Manifestoen 2001): sirven para proyectos chicos con requerimientos cambiantes y personal muy capacitado.
Resultan ideales para reaccionar ante los cambios de tendencias (usuarios cambian prioridades según pirámide de Maslow).
Hacen énfasis en usabilidad y valor agregado vs. featuresy precio. Deseo: adaptar la tecnología a las personas y no al revés.
2000s: agilidad y valor (2)
La dependencia en el SW se vuelve crítica: los clientes
presionan por mayor calidad y garantías, pero no hay reacción. Para Boehm, esto va a seguir así hasta quehaya una
catástrofe inducida por SW similar en impacto al 11/9, que según predice será antes de 2025.
Algo de progreso en SW confiable: Hoare con los productos de Microsoft, Scherlis con la concurrencia en Java, otros en model-checking, etc.
Disponibilidad de sistemas y componentes COTS (SW comercial, listo para usar). Permiten desarrollar productos complejos en poco tiempo, pero difíciles de integrar. La curva de productividad anual del SW tan buena como la del HW: se mide en LOCS (contar líneas de código en servicio) en vez de SLOC (contar nuevas líneas de código).
Futuro
Los sistemas se basan cada vez más en SW, pero los fallos provienen de la Ingeniería en Sistemas: se buscaintegrarla
con la Ingeniería del SW. MDD es un paso en ese sentido. Conectividad global posibilita externalización y desarrollo rápido en tres turnos de 8hs: desafíos para sincronizar, gestionar, crear confianza y valores compartidos. Infraestructura basada en estándares, proveedores competidores trabajando juntos para hacer “sistemas de sistemas” sin precedentes.
Qué aprendimos
De cada década obtenemos tres consejos para el futuro, dos aprendidos del éxito y uno del mal ejemplo.
1950s
No ignorar a las ciencias. Pensar en las consecuencias antes de hacer algo.
• Evitar usar un proceso secuencial riguroso.
1960s
Incentivar el pensamiento lateral (divertirse
prototipando).
Respetar las diferencias del software con el hardware.
Qué aprendimos (2)
1970s
Eliminar errores temprano. Determinar el propósito del sistema.
• Evitar el desarrollotop-down
y el reduccionismo.
1990s
El tiempo es dinero. Hacer software útil para la gente.
• Ser rápido, pero no apurarse.
1980s
Hay muchas maneras de incrementar la productividad. Lo que es bueno para los productos es bueno para el proceso (incluye arquitectura, reusabilidad, adaptabilidad).
Qué aprendimos (3)
2000s
Si el cambio es rápido hay que saber adaptarse. Considerar y satisfacer las proposiciones de valor de todos los stakeholders.
• Evitar enamorarse de slogans (siempre tienen excepciones).
2010s
Mantener la mirada en lo que está a tu alcance. Tener una estrategia de salida (control de proyectos).
Conclusiones
El análisis está muy centrado en los EEUU y en su experiencia personal (aunque del conjunto de análisis realizables por cada humano X, tomar X=Boehm posiblemente maximiza la exactitud de la historia.)
Algunos creíamos que “al fin y al cabo, todo es sobre programar” y que la Ingeniería del SW sólo toma conceptos previos y los hace conocidos, sin generar ideas útiles por sí misma. Ahora por lo menos no nos animamos a decirlo. Es importante para la disciplina el llevar el registro de su propia historia, para repetir los aciertos y no caer en los mismos errores.
Antes el SW se utilizaba en ámbitos gubernamentales y académicos. Ahora está inmerso en la lógica del mercado, con reglas variables por las tendencias humanas.
