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

Analisis de estimacion de esfuerzos-Cuaderno II

AL PIE DE ESTE ARTICULO ESTA EL LINK A LOS DOCUMENTOS MENCIONADOS


Igual que en el envío anterior, la información base la tomamos del ISBSG y agregamos un capitulo de un libro dedicado al tema.-

Nos han hecho llegar consultas sobre TECNICAS DE ESTIMACION. Es decir, los documentos de estos envíos cubren en general el análisis de exactitud de la estimación de proyectos y la incidencia de varios factores en el tamaño de un proyecto.-

Uno de los documentos que enviamos hoy (Early Lifecycle Software Estimation 060905.pdf) es una aproximación al problema, aunque debe ser manejado con el conocimiento o las técnicas que hay por ejemplo en:
Practical Project Estimation (2da edición): http://www.isbsg.org/isbsg.nsf/weben/Estimation%20Toolkit
Otro de los documentos “Six Forms of SW Cost Estimation.pdf” es un extracto de publicación libre del libro “Estimating Software Costs”, Second Edition escrito por Capers Jones y publicado por The McGraw-Hill Companies.


*********************************

Un resumen de los documentos que enviamos:

Early Lifecycle Software Estimation 060905.pdf: Hay varios escritos sobre la estimación de software en una etapa temprana. Es el caso clásico de las estimaciones para conseguir el presupuesto o siquiera para analizar si el mismo es posible. Este White paper del ISBSG, basa sus reglas de calculo en el análisis de 1942 proyectos que han sido estimados a través de técnicas de estimación por puntos de función (IFPUG- V 4 o superior) o por la aproximación que propone NESMA.-
En el informe se brindan coeficientes de calculo. De todos modos vale remarcar que las formulas requieren del SIZE, esto es de una estimación previa de los puntos de funcionalidad que el sistema debe tener para cumplir con los requerimientos del usuario.-
Esto lleva de suyo que es necesario un trabajo de Análisis de Requerimientos previo para poder tener una valor con un margen de error por debajo del 40%.-

-----
Project Cost - Special Report.pdf : Este documento analiza el costo de proyectos que están en la base del ISBSG. Se trata de una muestra de 591 proyectos. En este caso también se trata de analizar datos de algo que “ya sucedió”. Es decir son documentos en los que se analiza como se estima o cuanto costo un proyecto luego de terminado. Visto de ese ángulo la información es rica: El costo medio de un proyecto en USA o Europa es de U$S 80 la hora/hombre y U$S 750 por punto de función.-
Esos valores triplican al menos lo que cuestan los proyectos de software en nuestro país, CUANDO SON HECHOS CON ESPECIFICACIONES DE REQUERIMIENTOS CLARAS Y BUENA INGENIERIA.
Detalle este ultimo, que la mayoría de las veces no es considerado adecuadamente por los gerentes de sistemas o de las áreas de negocio a la hora de contratar.-

-----
Package Customisation 240305.pdf. Este ultimo es un estudio sobre 470 proyectos en los que se midió el esfuerzo de adecuación y parametrización (customization) de paquetes de software. La mayor parte de la muestra (400 proyectos) no involucro paquetes instalables y 70 de los proyectos si, fueron en paquetes instalables que requirieron algún tipo de parametrización.
El informe muestra relaciones interesantes:
Los paquetes de software parametrizables tienen una tasa de implementación mejor en comparación con los desarrollos ad-hoc, es decir se agrega funcionalidad en MENOS TIEMPO (“…This suggests that projects involving customising a package deliver about 30% more FP per month per person than projects that do not involve customising a package…”)
Los proyectos que implican el uso de paquetes parametrizables SON MAS LARGOS EN TIEMPO y los equipos de proyecto SON MAYORES.-
De todos modos, como marcan los autores del informe, la muestra no es todavía suficiente para sacar conclusiones mas firmes.-
-----
Six Forms of SW Cost Estimation.pdf. Como comentamos antes es un capitulo del libro “Estimating Software Costs”. Nos pareció interesante como enfoque de estimación en el que NO SE USA LA FUNCIONALIDAD a entregar como partida de la estimación sino que se usan las ACTIVIDADES como base de la estimación. Como todas las técnicas su utilidad esta en su correcta interpretación y consistencia en el uso.-

LINK A LOS DOCUMENTOS DE ESTA 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%22kdg3n63ns8%22%7D&_ownerId=9863329&completeUrlHash=ZIip

Analisis de Estimacion de esfuerzos - Cuaderno I

LINK A LOS DOCUMENTOS MENCIONADOS EN ESTA NOTA AL PIE

Hemos elegido como tema de este mes el análisis de las estimaciones de proyectos de software.-

Este es un tema de constante discusión en la industria, no solo en nuestro país.-
Nos pareció de interés abrir una línea de discusión sobre este tema ya que es habitual la mala estimación de esfuerzos.
Todos sabemos que esto trae perjuicios al ejecutor en su economía, perjuicios al comprador en sus plazos y calidad y perjuicios en la visión general de la industria respecto a la madurez con la que encaramos nuestros negocios.-

Este problema tiene diversos orígenes:

Una es la falta de criterios de ingeniería por parte de quien compra, haciendo muchas veces compulsas sin definiciones de requerimientos claras.-

La otra es de las propias empresas de software y consultoría, que usamos técnicas de estimación que no unen la funcionalidad que se entregara con el resultado real del esfuerzo del desarrollo.-

Un tercer origen es la ausencia por parte de las empresas de software y consultoría proveedores de estos servicios de la convicción en los procesos de construcción de software y la normalización de las tareas previsibles, dejando el aspecto naturalmente creativo de la actividad, dentro de su ámbito especifico.-

Por ultimo es la ausencia de mediciones, casi como un hecho cultural. Y no nos referimos a comparar un proyecto nuevo con alguno ya hecho que nos resulte parecido (algo que hacemos a menudo), sino al hecho de tener repositorios de datos de los que podamos sacar información estadística.-

Y esto ultimo es, precisamente, lo que nos parece rico de la serie de notas que compartiremos con ustedes.-

Se trata de trabajos publicados en el 2005 por el prestigioso International Software Benchmarking Standards Group (www.isbsg.org).-

Estos trabajos son el resultado del análisis de proyectos de software por parte se expertos en estadística, matemáticos
e ingenieros, sobre datos recolectados en proyectos de software terminados.

En el repositorio de la ISBSG existen seguramente mas de 3000 proyectos de software clasificados.-

La información proviene de distintos países (Australia, Japón , Holanda, Estados Unidos, Brasil, etc.).

Corresponde a proyectos de alcances muy variados, ramas de la industria distintas y tecnologías diferentes.-

De conjuntos de estos proyectos, se puede entender que se extraen muestras ya que las mismas cumplen con determinados patrones
que el análisis estadístico, permite revisar.-

Y a partir de allí surgen análisis de los datos , patrones de comportamiento y conclusiones muy ricas.-

En general no es bueno extrapolar situaciones, pero la diversidad de origen de las muestras y el rigor del análisis nos han llevado a pensar ( y sobre eso hemos hecho algunos trabajos de campo) de que se trata de lecturas indispensables.-

Si a eso agregamos que la lectura es simple, consideramos que es un material ideal para estos cuadernos mensuales que Millennium3 comparte con ustedes.-
------------------------------------------

Un resumen de los documentos que enviamos:

M3-Estadistica simple v1-0.pdf : En esta serie de notas el rigor estadístico es parte esencial del análisis. Aun cuando, como lectores, no debemos manejar esta materia, es bueno que recordemos algunos significados para simplificar la lectura.-
De allí que incluimos una nota técnica nuestra, con un resumen simple de términos de estadística comunes en este tipo de informes.-
-----
Estimates - how accurate are they - 200105.pdf : Este es un informe de Enero del 2005 y corresponde al análisis de alrededor de 400 proyectos del repositorio del ISBSG para los cuales existe información normalizada de los esfuerzos en proyectos de software estimados y REALMENTE utilizados.-
La información base cubre un periodo que va desde 1998 hasta mediados del 2004.-
Las herramientas que cubren el 77% de los proyectos son Access, COBOL, C/C++/C#, Java/J2EE/Javascript, Visual Basic, PL/I, ORACLE y SQL. Al menos 15 proyectos analizados, han sido realizados con estas herramientas.-
El análisis es una comparación entre el presupuesto inicial del proyecto con sus estimaciones de size (alcance funcional), effort (esfuerzo de desarrollo Level 1), delivery (tiempo calendario de extensión del proyecto), cost (costo) y PDR (Project Delivery rate como medida de productividad).-

Algunos puntos que surgen de este informe:

El esfuerzo (equipo de desarrollo Nivel 1 medido en horas hombre), centrado esencialmente en la construcción del software es el que tiene tasas mas altas de sub-estimación.-

El principal componente del costo es precisamente el esfuerzo.-

Las mejores estimaciones de esfuerzo se producen en proyectos cortos y de corta duración.

NO EXISTE una correlación entre productividad y buenas estimaciones.-

Las técnicas de estimación basadas en alcance funcional (Functional size o Use case Point) son mas seguras que las basadas en apertura de tareas (Work Breakdown).-
-----
Team Size Impact - Special Report 070705.pdf. Este es un informe del ISBSG que nos permite analizar la productividad de los equipos y su DISMINUCION a medida que el tamaño de los mismos aumenta. Algo que la mayoría de nosotros ha percibido o medido de modo disperso, pero aca con el soporte de números reales.-

LINK A LOS DOCUMENTOS MENCIONADOS EN EL ARTICULO

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%22kdg3n63ns8%22%7D&_ownerId=9863329&completeUrlHash=ZIip

Sobre Arquitectura - Cuaderno II

LINK A LOS DOCUMENTOS MENCIONADOS EN ESTE ARTICULO AL PIE DE LA NOTA

Colegas
Seguimos en este cuaderno con las notas relacionadas a la arquitectura del software y repetimos el formato del envio
anterior:

-Opiniones e ideas de los adherentes a los métodos formales
-Opiniones e ideas de los adherentes a las metodologías agiles
-Un documento propio de M3, que al igual que el del envío anterior, es el diseño de arquitectura de un sistema.-



AtribDrivenDesign-A Practical Example.pdf:
A Practical Example of Applying Attribute-Driven Design (ADD)
*************************************************************
Este es un paper de William Wood (miembro eminente del SEI, redactor de especificaciones del DoD y promotor
de estas metodologias). Nos ha resultado muy interesante primero porque es una descripcion de un metodo
aplicado en un caso real. Pero en segundo lugar porque, si se sigue el texto con la misma seriedad con la que el autor lo
ha escrito,creo que llegaremos a la conclusion en que este metodo obliga a generar una documentacion tediosa que no parece
aportar valor al producto, al menos en proporcion al esfuerzo.

Queremos ser claros en esto, en terminos generales acordamos con una metodologia como puede ser esta, que a modo
de receta propone iteraciones hasta definir el modelo de arquitectura elegido.

Lo que no nos parece practico y esta es la diferencia esencial entre las metodologias agiles y las formales, es completar
un conjunto de documentacion , que NO ACTUA COMO CHECKLIST O AYUDA-MEMORIA sino como "jaula" de la expresion de un diseño.
Y si se piensa que esta posicion es demasiado extrema, es bueno leer los comentarios que en el punto 6 del paper realiza
el autor:

"...2. The documentation of the ADD results is awkward at times, since we documented development according to the structure
of the ADD method. The result was rather clumsy documentation with Section 4 having four levels of indentation and the
other sections having only one or two. However, in most real software architecture description documents, the documentation
structure will not be dependent on the development method (ADD) but rather on the most effective way of capturing the views
developed..."

Estos comentarios del Ingeniero Wood no solo nos parecen acertados conforme a lo que se deduce del informe, sino que muestran
el talento y la honestidad intelectual del autor.-

AGILE ENTERPRISE ARCHITECURE -Ambler.pdf
******************************************
En la segunda página de este documento, usted encontrara que Ambler asume ( A few Assumptions) que el lector debe haber
leído previamente los principios de las Metodologías Agiles.
Si bien esto es un plus, no es necesario haberlo hecho si esta realmente interesado en la discusión sobre el tema.
De modo que siga adelante con la lectura y tome esto solo como una parte de la "ferocidad" Ambler.

Lo importante no es el extremismo de Ambler sino la claridad de sus ideas.

Los tópicos del documento suenan como una buena fuente de consejos:

“Lo importante es la gente, no la tecnología” es uno de los lemas de este documento (una idea tomada de Brooks) que habla
sobre la importancia de convencer y generar sinergia por encima de las herramientas y las técnicas a usar.-

“Roll up your Sleeves” o sea ARREMANGARSE… y trabajar desde y con el equipo (y no desde la torre de marfil).-

“Mantenerlo simple”. El principio de menor complejidad aceptable para los diseños y arquitecturas

Solo por mencionar algunos de los puntos que se tocan en este documento de sencilla lectura.-

M3-Especificacion Arquitectura Emisión de Reportes v1-6.pdf
************************************************************
Este es un documento de arquitectura que creamos en Millennium3 para un software de benchmarking. Se trata de uno de esos
sistemas que hemos hecho durante años, en distintas tecnologías, lenguajes y épocas.-
Por eso mismo, nos ha permitido tomarlo como patrón para medir diferencias entre lenguajes y técnicas de implementación.
El documento sigue la línea del entregado con el envío anterior y se corresponde al patrón de documento que usamos para
estos casos.-
Creemos que muestra de modo adecuado como está (o estará) construido el sistema y como interactúan las partes.-


Este es el segundo envio sobre temas de arquitectura. Las consultas y opiniones recibidas nos llevan a que generemos un tercer envio
sobre el tema que distribuiremos en el mes de Marzo

Esperamos como siempre que estas lecturas sean de su interes y los inspiren en ,esta, nuestra creativa y amada actividad

Atentamente

LINK A LOS DOCUMENTOS:
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%225xau9onhts%22%7D&_ownerId=9863329&completeUrlHash=tnNC

SObre Arquitectura - Cuaderno I

LINK A LOS DOCUMENTOS MENCIONADOS EN ETSA 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%225xau9onhts%22%7D&_ownerId=9863329&completeUrlHash=tnNC


Estimados Colegas :

El presente cuaderno esta referido a uno de los temas en los que hemos recibido consultas o sugerencias: Que es la arquitectura en un
proyecto de software ?.-

En una época en la que jóvenes que apenas tienen un par de años programando en un lenguaje dado, se postulan como
arquitectos, surge la duda o al menos la discusión sobre que cual es esa famosa tarea que tantos postulantes tiene y
tan pocos practicantes reales reconoce.-

Hemos elegido para este envío (que se continuara bajo el mismo tópico en Enero) notas de los adherentes a los métodos
formales y para ello elegimos ingenieros del SEI (Clements, Jazayeri, Batman), tambien elegimos adherentes a los métodos
agiles y para ello seleccionamos a Scott Ambler y Allistair Cockburn y decidimos agregar algunos documentos propios
generados en nuestros proyectos. Estos últimos no como conceptos sino como implementaciones de documentos de arquitectura.-

La seleccion de los representantes de cada "escuela" se ha hecho con el mayor de los respetos, en tanto, para quien esto firma,
ambas escuelas tienen aportes de real valor.-

El cuaderno estara compuesto por 3 envios y este es el primero de ellos.-



Cuadernos del SEI.pdf
**********************

La primera de las notas es de Paul Clements, senior member del staff técnico del SEI (Software Engineering Institute).
La nota “What’s difference between architecture and design?” es un articulo corto en el que se expresan, de modo sencillo,
ideas sobre como definir elementos arquitectónicos (es decir de interés para la arquitectura del software) y elementos de
diseño (es decir de interés de quienes implementan).

La segunda nota “Architecture Paradox” es del Dr Subrahmanyam Allamaraju un reconocido ingeniero en desarrollos sobre
tecnologías J2EE. Es una reflexión sobre las dos fuerzas opuestas que enfrenta un diseño de software: Sobrevivencia y
Evolución. Entendidas como la capacidad de cumplir con el cometido para el que fue construido (Sobrevivencia) y la capacidad
de cambiar a medida que las demandas de negocio así lo requieren (Evolución).-

La tercer nota son extractos de un libro de Jazayeri y otros ("Software Architecture for Product Families").
Los primeros extractos se refieren a la elección de vistas (como cortes parciales de la realidad) para modelar y especificar
una arquitectura.-
La segunda parte, que se refiere a un Marco de conceptual para la arquitectura de software nos parece un buen ejemplo de la
idea de la que parten las Software Factories (tema al que dedicamos el primero de nuestros envíos).-
Recordamos que, en este caso, usamos este termino (Software Factories) no como el espacio físico y de procesos con el que se construye el
software, sino el entorno de desarrollo y el marco en el que se conciben aplicaciones para un dominio dado.-

AGILE ARCHITECURE MODELING-Ambler.pdf
**************************************
Este es un documento 100% Ambler. Y en cierto modo radical. Comienza con el enunciado habitual de igualdad entre todos los
participantes de un equipo de desarrollo (en contra de la cultura “gerente-proyecto-céntrica” demasiado instalada por caso
en nuestro país).-
Y continua con agudas observaciones sobre arquitectos que viven en “torres de marfil”. Es este tipo de observaciones las que
han hecho que Ambler gane fama entre los ambientes de programadores.
De todos modos nos pareció interesante el articulo no por sus primeros enunciados, algo provocativos, sino porque en el
cuerpo de la nota Ambler se extiende en una serie de PRINCIPIOS y NORMAS que un buen arquitecto debe seguir.
Son estas ideas y no las discusiones casi ideológicas las que dan fuerza a las ideas de Extreme Programming y los métodos
agiles de construcción de software y administración de proyectos.-

Agile Programming y los métodos formales son compatibles?

Entendemos que son visiones distintas y a esta altura difíciles de conciliar.-

Igual que las estrategias para ciclos de vida de proyecto, quizás lo mejor este en partes de cada mundo y la sabiduría del
arquitecto y el diseñador esta en elegir las ideas mas adecuadas que lo lleven al éxito en cada proyecto:

Patrones, si.
Dogmas, no.-

Hunting the product line architecture-Batman.pdf
***************************************************
Es un paper de Joseph Batman que es senior member del staff técnico del SEI (Software Engineering Institute).
Este documento nos parece interesante porque se enfoca en la definición de una arquitectura para una Familia de productos
de software que una empresa puede producir. (sea una empresa de software o no).-

Este enfoque con otros nombres (Por ejemplo SDL : Specific Domain Language) es un tema de discusión común cuando se trata de
implementar fabricas de software como entorno y marco de desarrollo.-
En ese sentido una arquitectura de línea de productos es una abstracción de arquitectura que se debe implementar para cada
producto.
Pero así enviamos una nota de Ambler que nos pareció prototípica de las metodologías agiles,
lo que hizo que elijamos este paper como representativo de las escuelas formales y tradicionales es la comparación que hace
Batman entre la necesidad de arquitectura de los productos de software y la organización para un despliegue militar.-

Las ideas del SEI y el Carnegie Mellon se producen (y son esencialmente financiadas) para conducir y medir los enormes
proyectos del DOD (Deparment of Defense) de Estados Unidos.
Y esto no es una observación menor, en tanto esas metodologías aplican a proyectos de gran escala , con participación de
múltiples contratistas y donde la esencia es un dado nivel de calidad (que deben cumplir todos los contratistas del DOD),
respeto a estrictas reglas de seguridad en el envio de informacion y el personal involucrado y participacion de OTROS
CONTRATISTAS certificados. Esto significa que las habituales reglas de decision de proyectos que conocemos (quiero pagar tanto
y lo necesito para tal fecha) no son las de estos casos.-

Esto no confina las ideas del SEI a los proyectos del DOD ya que otros adherentes a estos procesos son, por ejemplo
la empresa Bosch que tiene una línea de software para control del sistema de nafta de motores o Philips con su software
para televisores de bajo costo.-

Pero creemos honestamente, que es necesario entender que, no todas las practicas propuestas por los ingenieros del SEI tienen
aplicación universal y para eso precisamos siempre entender el contexto en el que una determinada idea se considera
valida.-

Con esto en mente entendemos que el documento es rico en ideas útiles para quien desee implementar arquitecturas para sus
líneas de productos de software.

LA IDEA APARECE COMO ESENCIAL PARA AQUELLAS EMPRESAS QUE NO SON PRODUCTORAS DE SOFTWARE, pero tienen en su área de sistemas
la necesidad de hacer con equipos propios o de terceros desarrollos propietarios de considerable volumen y variedad , de
considerable criticidad para el negocio pero siempre apuntados a UNA LINEA DE NEGOCIOS DETERMINADA.-

M3-Architecture Specification for the Autodesk Icon Database - v1.0.6.pdf
**************************************************************************

Por ultimo en esta primer parte (igual haremos en la Parte II de este envío) incorporamos un documento nuestro.
No para abundar en conceptos(ya que en ese terreno no seriamos una digna compañía de quienes mencionamos previamente), sino
para mostrar una implementación de esas ideas en un documento de arquitectura.

Corresponde a un trabajo que Millennium3 hizo para la firma Autodesk, fabricante entre otros productos de
AUTOCAD® .-
Este trabajo lo realizo un equipo de ingenieros de Millennium3 y participaron desde el punto de vista del control técnico
un equipo chino (China Autodesk Development Center) y un equipo estadounidense.-
En un equipo tan diverso y geográficamente disperso se necesitan artefactos de comunicación eficaces.
Nos pareció entonces una buena posibilidad adjuntar este documento, que demas esta decirlo ...no fue el unico artefacto de comunicacion !!.-

------------------------------------------
En fin, estas notas y las ideas subyacentes nos llevan al maravilloso sueño de cualquier diseñador:

“Un diseño no esta terminado cuando no hay nada mas para agregarle, sino cuando su equilibrio interno es tal , que no hay
mas nada que quitarle”.

Ojala podamos lograrlo la mayoría de las veces.-

Las Fabricas de software-Cuaderno I B

(Para obetner los documentos mismo link que la entrada I de software factories)
En articulo "The case for software factories", Jack Greenfield da interesantes definiciones e ideas sobre cuales son los limites reales de la industrializacion del software y la diferencia entre produccion a escala (como las automotrices) y diseño a escala (como los constructores civiles de edificios y viviendas).-




La nota “Moving To Software Factories” de Greenfield y Keith Short es una explicacion del concepto de Software Factories como un ambiente integrado de desarrollo. En este caso con herramientas de Microsoft, aun cuando el concepto excede por lejos las propuestas de un solo fabricante .Por ejemplo, IBM WebSphere Studio es un entormo que permite armar estos ambientes tal como lo permite el Visual Studio Team System de Microsoft .-



Los autores de la nota son tambien autores del libro “Software Factories: Assembling Applications using Patterns, Models, Frameworks and Tools”



Por eso hemos elegido tambien la nota homonima (“Software Factories: Assembling Applications using Patterns, Models, Frameworks and Tools”) en la que se resumen ideas expuestas en el libro mencionado.-



Los conceptos, que se complementan con las notas de los dos primeros envios, enfatizan sobre el armado de un conjunto de herramientas y patrones apuntados a la construccion de software.-



Un esquema de la factory (es decir un conjunto de directorios, scripts y guias para elegir lo adecuado al momento de construir

Una plantilla que contenga los patrones y el Framework que se utilizara

Un ambiente integrado y extensible. En este caso estamos hablando de un producto de un fabricante como Microsoft VSTS + TFS, IBM WebSphere Studio + Rational o conjuntos de herramientas de software libre (Eclipse, SubVersion, CVS, Cruise Control, Nant,etc) con criterios de integracion.-



Esos son los puntos marcados por los autores como claves, para armar entornos productivos con alto grado de predicibilidad.-



Todos sabemos que aun asi, la construccion de software presenta imponderables que no nacen necesariamente, de la “inmadurez” de la ingenieria del software, como sostienen demasiado ligeramente algunos escritores o analistas.-

Nace de la íntima relacion entre el diseño y la construccion, a un punto tal que no es simple encontrar su verdadera separacion como sucede en otras ramas de la ingenieria.-



Colegas que disfruten de estas lecturas

Las fabricas de software- Cuaderno I

LINK PARA OBTENER LOS DOCUMENTOS MENCIONADOS EN ESTE ARTICULO
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%229zdc3d9hv7%22%7D&_ownerId=9863329&completeUrlHash=sM8H


El presente cuaderno tiene una serie de articulos que consideramos de interes para las areas de software e ingenieria de sistemas: Las fábricas de software.-
Lo hemos divido en dos envio que haremos en sendos e-mails. Este es el primero Estas lecturas, seleccionadas de una serie mayor que forman parte de nuestros seminarios, deseamos compartirlas con ustedes, ya que entendemos que ayudan a que podamos manejar conceptos comunes de nuestra profesion.-
La produccion de software off-shore, el diseño a escala, el uso de patrones, los Frameworks, los DSL y las software factories son algunas de las aproximaciones a la solucion de los problemas que encontramos a diario.-
Todos los articulos que seleccionamos estan escritos por profesionales activos y exitosos en el dificil oficio de la ingenieria y el diseño de software.-El articulo "Success with Soft Factories" (de dos ingenieros cuyo background comentamos mas adelante) se expone una vision realista sobre como varios aspectos de la construccion de software pueden ser estandarizados y como los Frameworks pueden devenir de meros contenedores de bibliotecas de funciones a completos entornos de desarrollo, algunos incluso para dominios de negocio especificos.-
Los autores del artículo son Marcel de Vries y Jack Greenfield.-
Marcel es un ingeniero de software, holandes, que actua como arquitecto lider en Info Support y es un reconocido especialista en Visual Studio Team System.- Es ademas el arquitecto jefe en la Endeavour software factory, enfocada en la creacion de aplicaciones administrativas orientadas a servicio.-
Jack Greenfield es un arquitecto Lider en Microsoft Corporation del area de creacion de herramientas y entornos para desarrollo de software corporativo.- Fue Arquitecto Jefe en Rational Software Corporation y fundador y Jefe de Tecnologia en InLine Software Corporation. - Trabajo tambien en el magnifico "sueño" de Steve Jobs: NeXT Computer donde desarrollo un framework que hoy es parte del software Web objects de Apple Computer, Inc.- Aparte de escribir articulos tecnicos y dar conferencias, Jack ha contribuido en la definicion de las especificaciones UML, J2EE, OMG y JSP.-
**************************************************