EL PROCESO DE CONSTRUCCION CUADERNO I

Link a los documentos mencionados en este articulo al pie
Estimados colegas:

Seguimos con esta entrega del cuaderno VI, siendo esta la primer parte.

La entrega contiene documentos referidos al análisis sobre el proceso de construccion de software

Hemos elegido para esta entrega dos materiales de intensa reflexion sobre los proyectos de software
Uno es el conocido manifiesto : The Cathedral and the Bazaar de Eric raymond.
Otro es un documento reflexivo llamado "Iterative and Incremental Development" que explica el desarrollo de las ideas que
llevan al concepto de desarrollo Iterativo e Incremental (IID).
Y el ultimo es el trabajo base del doctor Winston Royce sobre el que se desarrollo el modelo waterfall

cathedral-bazaar.pdf
*********************

EN este legendario ensayo Eric Raymond intenta describir las diferencias entre la rigurosidad y la formalidad en la
planificacion y los modelos abiertos. Estas diferencias se relatan referidas al exito de uno u otro modelo.
Es una reflexion interesante que pone el eje en los resultados obtenidos con cada modelo.

Como dice Raymond : "...I anatomize a successful open-source project, fetchmail, that was run as a deliberate test
of the surprising theories about software engineering suggested by the history of Linux.
I discuss these theories in terms of two fundamentally different development styles, the “cathedral” model of most of
the commercial world versus the “bazaar” model of the Linux world..."

Desde ya que el resultado que Raymond observa (Linux) ha sido exitoso con el "bazar" y Raymond no muestra o no analiza
resultados equivalentes en la "Catedral".
Esto es una lectura sesgada ya que ambos modelos pueden representar exitos :
La "Catedral" ha permitido empresas como IBM , Microsoft, Sun u ORACLE, productos como Lotus, Oracle DB ,
el lenguaje de programacion C y los sistemas operativos UNIX y Windows
El "Bazar" por otra parte, dio nacimiento a empresas como Netscape, Google y productos como Linux, Mosaic, Firefox o Apache.

La reflexion de Raymond se basa en los resultados del mundo UNIX, ya que esa es su preocupacion principal.
Raymond ha sido uno de los programadores del editor Emacs, en ese sentido ha trabajado con Stallman, la figura relevante
del software libre.
Es importante entonces la opinion de Raymond ya que la comparacion entre Catedral y Bazar no la centra entre corporaciones
y comunidades de programadores sino en modos de trabajo para la produccion de software.
Cuando fue que escribio Raymond este documento ?: En 1997.
Alli fue cuando considero que el aporte de Linus Torvalds mas importante no fue el kernel de Linux,sino el metodo de
construccion ("Bazar") que utilizo para el mismo
Para quienes construimos software, estas ideas de mas de una decada de vida, siguen teniendo una impresionante actualidad.

Iterative and Incremental Development:
**************************************
La segunda es una nota de Craig Larman y Victor Basili, es un aporte a la vision sobre los metodos de desarrollo, iterativos
e incrementales ligados en general a las metodologias agiles.
Este paper sigue la linea del entregado en el envio V de estos cuadernos. Nos referimos a EVO-Evolutionary Project Management.pdf
del notable Tom Gilb
Este tipo de reflexiones son altamente importante para los ingenieros, arquitectos y diseñadores de software
Nos ponen en contexto con otras ramas de la ingenieira enfocadas al desarrollo y al diseño de bienes y productos que se
HACEN POR PRIMERA VEZ.
Nos habla de como los ingenieros , los diseñadores de productos y los administradores de proyectos inteligentes no creen que
el mundo entra en un papel membretado sino que necesita de la elaboracion, de la discusion de alternativas y de los intentos
para plasmar un modelo valido de producto.

Un comentario de los autores al inicio del documento es revelador en este sentido:

"...Although some prefer to reserve the phrase 'iterative development' merely for rework, in modern agile methods
the term implies not just revisiting work, but also evolutionary advancement—a usage that dates from at least 1968. ..."

A nuestro entender este tipo de documentos importan por las ideas de los autores, pero mas aun porque hacen un analisis del
problema explicando mejor su genesis es decir su inicio y los motivos de su evolucion posterior.
Por eso es importante leer detenidamente la parte de la nota que refiere al documento de Winston Royce (el padre del modelo Waterfall)
Como comentan los autores y lo podemos hacer nosotros en una lectura atenta del documento de Winston Royce (que adjuntamos
en esta entrega)
El Dr. Royce no propone esa version de modelo estatico de waterfall que se cansaron de presentar y hacer fracasar los
analistas y gerentes de proyectos de las grandes consultoras (Accenture, Andersen Consulting, IBM Services , Unisys, etc).
El modelo IID es simple tal como lo enuncia uno de los autorees de la nota (Victor Basili) :

"...
The basic idea behind iterative enhancement is to develop a software system incrementally, allowing the developer to take advantage of what was being
learned during the development of earlier, incremental,deliverable versions of the system.
Learning comes from both the development and use of the system, where possible. Key steps in the process were to start with a simple implementation of
a subset of the software requirements and iteratively enhance the evolving sequence of versions
until the full system is implemented. At each iteration, design modifications are made along with adding new functional capabilities
..."



Managing the development of large software systems:
***************************************************
En este paper el Dr Royce (padre del modelo de desarrollo denominado waterfall) encontramos las ideas seminales sobre el modelo waterfall.
EL nombre del modelo, que literalmente significa cascada puede deducirse del grafico que presenta Royce en su escrito como Grafico 2
Alli los distintos procesos de la construccion : requerimientos del sistema, requerimientos del software,de operacion, etc son colocados como escalones en caida.
Como se observa en los graficos 3 y 4 de la nota , Royce entiende que no existe solo una caida sino un ida y vuelta entre cada paso de la ieracion y su inmediato anterior.
Indica que debe haber iteraciones y que las mismas deberian en teoria producirse en pasos contiguos. Es decir la retroalimentacion de
Requerimientos del sistema deberia producirse de Requerimientos del software (que es el paso inmediato siguiente a Requerimientos del sistema).

En palabras de Royce : "...The ordering of steps is based on the following concept: that as each step progresses and the design is further
detailed, there is an iteration with the preceding and succeeding steps but rarely with the more remote steps in the sequence..."
Sin embargo Royce vio enseguida mas alla que cualquiera de sus divulgadores:

"...I believe in this concept, but the implementation described above is risky and invites failure. The problem is illustrated in Figure 4.
The testing phase which occurs at the end of the development cycle is the first event for which timing, storage, input/output transfers, etc.,
are experienced as distinguished from analyzed. These phenomena are not precisely analyzable...
...Yet if these phenomena fail to satisfy the various external constraints, then invariably a major redesign is required..."
Es decir el problema basico del waterfall es que llevado a su extremo, la prueba de eficiencia y cumplimiento del sistema diseñado, SOLO se
constata al final del proceso general. Es decir cuando cualquier cambio tiene un costo altisimo.
Entonces , como lograr pruebas mas tempranas ?
Como obtener constataciones mas tempranas de que el sistema cumple con lo que el usuario quiere , necesita y estaba dispuesto a pagar ?
Es alli donde la idea de iteraciones COMPLETAS de pasos sucesivos nacen como necesarias para manejar este punto.

----
Estimados, como ven, este envio tiene material que es bueno leer mas de una vez y analizar y discutir con colegas que construyen software y
llevan adelante proyectos de desarrollo de software.
El analisis de estas ideas junto a una practica intensa de estos modelos para diseñar y construir nos llevara sin duda a conceptos mas solidos
y maduros para nuestras soluciones

Atentamente


LINK a los documentos mencionados en la nota
http://www.linkedin.com/osview/canvas?_ch_page_id=1&_ch_panel_id=1&_ch_app_id=17798120&_applicationId=1300&appParams=%7B%22subview%22%3A%22shared%22%2C%22item_type%22%3A%22folder%22%2C%22shared_name%22%3A%22imjzp7jiji%22%7D&_ownerId=9863329&completeUrlHash=Sor7