Crónicas sobre la ingeniería del software (3/3)

Enlace a Crónicas sobre la ingeniería del software (1/3)

Enlace a Crónicas sobre la ingeniería del software (2/3)

Octubre de 1968, (primera) conferencia sobre ingeniería software, organizada por la OTAN en Alemania. Transcripción de algunos debates durante la conferencia.

Nota: tercera parte de una serie de post con extractos de las cintas de audio que se grabaron durante los debates de la primera conferencia sobre ingeniería software. La conferencia se celebró en 1968.

– Kinslow: El proceso de diseño es iterativo. […].  Para mí el diseño consta de:
1.    Diagramas de flujo hasta que creas que entiendes el problema.
2.    Escribir código hasta que te das cuenta de que no es así [no entiendes el problema].
3.    Volver atrás y rehacer el diagrama de flujo.
4.    Escribir más código e iterar hasta que sientas que estás en la solución correcta.
Si estás en un proyecto grande, tratando de construir un gran sistema, tienes una fecha límite para escribir las especificaciones y el código. A menos que te esfuerces conscientemente acabarás saltándote especificaciones diciéndote: esto ya lo haré más tarde. Sabrás que estás iterado cuando no termines trabajos a la primera. Por desgracia, lo que ocurre es que se empieza con 200 personas tirando líneas de código. […] Si estás construyendo un sistema grande y estás escribiendo especificaciones no podrás iterar, la iteración se ve truncada por tener un plazo arbitrario. Esto debería cambiar.
(Nota: Hablando del ciclo de vida iterativo en 1968)
Enlace a Crónicas sobre la ingeniería del software (1/3)
Enlace a Crónicas sobre la ingeniería del software (2/3)

Javier Garzás

0 comentarios en “Crónicas sobre la ingeniería del software (3/3)”

  1. Pingback: Bitacoras.com

  2. Estimado Javier, Gracias por seguir compartiendo -como acostumbras- este tipo de noticias que son realmente valiosas.
    Sin duda, todos estos son temas importantes que se deben tratar de manera seria y detallada.
    Yo creo que lo más importante es encontrar la forma de integrar las prácticas ágiles al contexto de grandes proyectos, con equipos donde el PO es un área completa ubicada en diferentes lugares, con diferentes prioridades, donde el especialista de negocio forma parte integral del equipo de desarrollo, lo que requiere abordar proyectos que en la estimación “tradicional” puede llegar a planes/presupuestos multianuales.
    Es ahí donde las oportunidades son más grandes y donde haciendo una buena mezcla de Agile-CMMI-PMI-6Sigma y seguramente otras más, podemos hacer el cambio necesario para que el Chaos Report sea solo un mal recuerdo.
    Suerte!
    RMG

  3. Pingback: Crónicas sobre la ingeniería del software (2/3) - Javier Garzás, sobre calidad software y otros temas relacionados

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Ir arriba