Alguno de los Dream team

Alguno de los Dream team

martes, 25 de mayo de 2010

PROJECT MANAGEMENT . CUADERNO II

Estimados colegas
Seguimos con esta entrega del cuaderno V, siendo esta la segunda parte.
La entrega contiene documentos referidos al análisis de técnicas de control de proyectos de software.
Podríamos decir que ,en algunos casos, no se tratan en esencia de técnicas de control de proyectos sino de practicas o procesos de mejorapara el desarrollo de software .
Aun entendiendo la diferencia, preferimos incluirlas dentro de este tópico (administración de proyectos) porque el modo en el que se enuncian dichas practicas en los documentos que enviamos, exceden el marco de recetas y se centran en que es diseñar, producir software y que es un proyecto de software. Y creemos que las lecturas y el análisis de estos documentos ayudan a que los arquitectos, los ingenieros de software y los administradores o gerentes de proyecto encuentren que pueden formar un UNICO EQUIPO DE PROYECTO donde cada parte tiene una serie de roles de valor. Y esto solo sucederá si mas allá de la imprescindible voluntad de trabajar en equipo, se construye una visión común sobre nuestra profesión, sus riesgos y la riqueza y limitaciones de su domino de aplicación.
---------------------------SITIOS DE LA COMUNIDAD SCP--------------------------- Invitamos a todos a visitar el sitio de hosting del proyecto de código abierto que mantenemos alrededor del Framework de construcción de software al que llamamos CIRCO. (www.codeplex.com/circo).

El proyecto no solo trata de ser la prueba de concepto de las ideas que discutimos sino también un sitio donde pueda producirse colaboración en un proyecto de código abierto. Allí encontraran los releases del framework , discusiones sobre el rationale del mismo y videos y documentos sobre como utilizarlo. Hemos liberado una versión nueva del Framework y sus utilidades relacionadas , mejorado la documentación de uso, el proceso de instalación y el de aprendizaje.
También los invitamos a participar de las discusiones y novedades que están hosteadas en Linkedin: http://www.linkedin.com/groups?gid=107996&trk=hb_side_g
Estos son los documentos que adjuntamos con este envio y algunos comentarios sobre los mismos.
SEI Document_CMMI or AGile.pdf
*******************************
Este es un white paper del SEI: Software Engineering Institute) en el que se analizan los orígenes de CMMI y de los métodos Agiles y sus practicas de desarrollo de software. La lectura sobre los orígenes de ambas escuelas realmente paga la lectura del articulo.
Uno de los valores del informe esta en el rastreo del origen de las metodologías agiles en escuelas de ingeniera no ligadas al software, y el uso de estas técnicas y conceptos en proyectos de software y de otro tipo en el propio DoD (Department of Defense de los EEUU).
Hay referencias al trabajo de Tom Gilb (de quien también entregamos un white paper en este envío) y nosotros también agregaríamos que en este punto es de valor el documento de Craig Larman: “A History of Iterative and Incremental Development”. (Con referencia a este ultimo documento digamos que estaremos entregándolo con la tercer parte de este cuaderno V).
El valor que encontramos en este enfoque esta en que permite salir del ruido del marketing y las palabras de moda que estan en boga en los ambientes donde se promueve y se discute de metodologías agiles, tratando que las ideas y la experiencia sean las que produzcan valor.
Saliendo del ruido de marketing y enfocándonos en las ideas, podremos tomar lo mejor de las mismas y hacer crecer las nuestras, las propias que como ingenieros, programadores, arquitectos o gerentes debemos tener.
En algunos casos estas discusiones parecen perder de vista que se discute sobre como producir software. Y, mas allá que los conceptos agiles puedan haber nacido o sean aplicados en otras ramas de la ingeniería, para los ingenieros de software el problema es la construcción y entrega del software mismo. Este documento del SEI va al punto no solamente indicando los aspectos de valor en cada paradigma (Agile o CMMI) sino en aquello que NINGUNO DE LOS DOS PARADIGMAS PRODUCE NI RESUELVE.

Link a la nota comentada

http://www.box.net/files/0/f/30066664/1/f_312384976#/files/0/f/30066664/1/f_312397670


Ron Jeffries-Extreme Programming and the Capability Maturity Model.doc
************************************************************************
Este documento es un corto resumen que bien podrían ser las notas de lecturas del autor (Ron Jeffries) del libro de Paulk sobe el modelo CMM. Pero Ron no solo ha sido uno del firmantes originales del Documento sobre métodos agiles (Agile Manifesto), sino que fue el coach del equipo que trabajo en el legendario proyecto C3 de Chrysler, un proyecto seminal en el desarrollo de las metodologías agiles.
Lo que lleva a Ron Jeffries a hacer esta nota es una referencia a una discusión en un grupo e Google afirmando que exTreme Programming puede ser uno de los procesos del SEI , Nivel I (uno). De modo que es una opinión valiosa. Y aunque es menos extensa y profunda que el documento anterior, nos parece una buena fuente de reflexión, siendo que esta escrita por quien administraba los esfuerzos del proyecto C3 y manejaba la relación con el cliente y sus expectativas. Algo que esta en la verdadera esencia de la administración de proyectos.

Link a la nota comentada :

http://www.box.net/files/0/f/30066664/1/f_312384976#/files/0/f/30066664/1/f_312397590
---------------
UNA REFLEXION:
---------------
Mas alla de la necesidad (como hemos marcado en otras entregas) de tomar de cada escuela o paradigma lo que se consideremejor y formar el PROPIO CUERPO DE IDEAS, creemos que existe una diferencia fundamental en la cultura de los practicantesde CMMI y AGile: La certificación. Si las metodologías agiles se transformasen en un MODELO, que requiere certificación veríamos una proliferación mayor aun de gurúes, un aumento del marketing (alrededor de la certificación y no de la practica) y una miríada de evangelizadores, que por haber leído la "palabra divina" creerán estar en condiciones de decir como se hace software.
De modo que mientras los métodos agiles eviten conformar una Central que, través de la certificación, indique que es lo que esta bien y que lo que esta mal, tendrán el crédito de quienes tratamos de pensar libremente y armar nuestras propias conclusiones.
De todos modos queda abierta la duda de si el ámbito de aplicación de las metodologías agiles escala adecuadamente, en proyectos con varios contratistas, de larga duración y con equipos distribuidos. En mi punto de vista no veo como estas metodologías pueden aplicarse como núcleo de la administración de proyectos de escala. Un punto a discutir y del que nos gustaría conocer sus ideas.

Gilb-EVO-Evolutionary Project Management.pdf
********************************************
Este documento de Tom Gilb nos resulta interesante porque es la opinión, respecto del manejo de proyectos de alguien formado en el corazón de las escuelas formales de administración de proyectos: El DoD (Deparmento de Defensa de los EEUU). Gilb explica los conceptos de un método de administración que considera que la construcción y el diseño son una evolución y que no es correcto asumir para (la mayoría de los proyectos) que los requerimientos de los usuarios NO están definidos y cerrados en la etapa previa al construcción. Las ideas plasmadas en esta técnica datan de 1960 ,bien antes que Cockburn, Beck, Jeffries o Fowler implementasen y relanzasen estas técnicas a través de XP, TDD , Integración continua, etc.
Con simpleza Gilb sostiene que esta mecánica incremental de construcción ( Y POR ENDE DE ENTENDIMIENTO DEL PROBLEMA, por lo tanto de alcance, por lo tanto de plazo-recursos-dinero) es parte de un ciclo de la naturaleza: Aprender, adaptarse y sobrevivir.
Evo tiene principios que han inspirado a las metodologías agiles y muestran que esta discusión es critica para que podamos encarar proyectos exitosamente:
Early delivery of project results to stakeholders (for example, ‘next week’!)
Frequent releases to stakeholders (for example, ‘every Friday’)
Small increments (‘steps’) (for example, no more than 2% of total project)
Useful-to-stakeholder steps (benefit delivered, value experienced)
Selection and sequencing of steps according to degree of stakeholder benefit; usually but not always, high-profit steps first (using dynamic priority determination).

Link a la nota comentada

http://www.box.net/files/0/f/30066664/1/f_312384976#/files/0/f/30066664/1/f_312397574

Estos 3 documentos de la segunda entrega de este cuaderno V, son realmente ricos y un soporte conceptual para quienesdebemos participar de la visión general, implementación y administración de un proyecto para entregar un producto útil a los usuarios finales.
Esperamos que estas lecturas ayuden a sus tareas, a la evolución de sus ideas y al éxito de sus emprendimientos
Atentamente

jueves, 20 de mayo de 2010

PROJECT MANAGEMENT - CUADERNO I

Estimados:

Les agradecemos los comentarios que hemos recibido y trabajaremos para avanzar en varios de los puntos, temas y modalidades solicitadas.-
Respecto de este ultimo punto (modalidad de envío), consideramos que es mejor que enviemos documentos como lo hacemos actualmente y no links a un repositorio de publicación.-
Esto facilita la manipulación y el almacenamiento individual de los documentos para cada receptor, aun cuando al principio represente una carga en el buzón de e-mail.-
Documentos traducidos: No nos resulta facil disponer de tiempo para traducir documentos al castellano o al portugues.
Creemos firmemente que cada uno de nosotros piensa y describe sus ideas en su lengua maternaY asi debe ser. En un punto debemos encontrar una LINGUA FRANCA que actue como nexo. No discutiremos aca por que dicha LINGUA FRANCA es la inglesa. La inteligencia de nuestros colegas nos exime de eseanalisis. Pero eso es un hecho. De modo que debemos adecuarnos al mismo
De todos modos, va de suyo, que no hay ni habrá, documentos en lengua extranjera que no sea la inglesa.-
También agradecemos a aquellos que nos mandaron las direcciones de colegas que desean recibir estos envíos. Desde ya que los hemos invitado a ser parte de la comunidad (SCP:Software Construction Process) que es la unica forma de quedarregistrado para tales envios
Con respecto al contenido de los documentos que estamos compartiendo hoy:

Agile Project Management.pdf
******************************
Agile Project Management es un documento generado en CC Pace Systems por dos ingenieros que son gerentes de proyecto : Sanjiv Augustine y Susan Woodcook.-El punto de este documento es presentar una visión de las metodologías agiles como aporte real a la administración de proyectos. –Algo que en general no se valora correctamente por una mezcla de prejuicios de quienes prefieren metodologías formales y por fallas reales de quienes consideramos que estas metodologías son adecuadas sin aclarar su campo efectivo de alcance.-
La visión de Augustine y Woodcook es audaz: Mirar a los equipos de proyectos como sistemas complejos adaptativos.
El punto parecería mas bien una tesis para presentaciones universitarias, pero el origen del informe es de una consultora de prestigio en el “mundo real” y los autores, son ingenieros de campo en la administración de proyectos.- Nos parece que este tipo de documentos ayudan a aumentar la visión sobre lo que un administrador o gerente de proyectos debe hacer. No colocando su foco tanto en los documentos y las planificaciones, sino en el coaching sobre los que participan y el producto que el cliente espera.- En fin, el tema siempre es opinable y suscita discusiones.

M3 Algunas lecciones aprendidas_v1 0 2.pdf
******************************************
Y para eso, quisimos compartir una que tuvimos en M3 al cierre de un proyecto, como lecciones aprendidas (M3 Algunas lecciones aprendidas).- El informe es una compilación de posiciones del equipo de arquitectura y desarrollo, luego del cierre de un proyecto complejo.-En el contexto del tema que tratamos, preferimos compartir un documento de discusión de un caso real en carne propia, antes que un documento con una opinión “políticamente correcta”.- Ese proceso de discusión ayudo a enfocar aspectos importantes en el momento de cotizar un proyecto: ¿Cuanto sabemos de el ? ¿Cuanto sabe el cliente ¿? ¿Que grado de imprecisión tiene el requerimiento? Estos temas relacionados a la (inherente) baja calidad de ingeniería de especificación de los proyectos de software son los que afectan el día a día de cada proyecto. Los problemas en la especificación nacen no de la misma, sino de la ciega confianza que se desea depositar a menudo como algo totalmente definido al inicio de la construcción. En el documento tratamos sobre algunos aspectos que diferencian a la ingeniería del software con otras ramas de la ingeniería.-

The New Methodology.docx
*************************
Muchos de los conceptos vertidos en el documento anterior encuentran su soporte en este maravilloso articulo de Martin Fowleren el que razona sobre las caracteristicas especificas de la construccion de software y los problemas de la produccion de DISEÑO.Ya que eso, diseño, es precisamente el software. Esa caracteristica natural de nuestra porfesion es pasada por alto muchasveces por quienes administran proyectos de software como si fuesen pavimentaciones de calles... (o mas aun, preparacionesde tortas con una receta perfectamente experesada en cantidades). Esa discusion encuentra una base en el llamado "sentido comun": Tenemos que planificar y dar fechas certeras, asi como estimaciones certeras de tiempos y recursos.Si no lo hacemos no entendemos como son los negocios. Seamos claros. Los que sostenemos otras posiciones entendemos tambien como son los negocios. Solo que los negocios no sontodos iguales. ALgunas desafios admiten una mayor prediccion que otros. Algunos negocios son mas riesgosos que otros. En fin, nos gustaria que lo central en este analisis estuviese en una mayor comprension de las particularidades y caracteristicas del proceso de construccion de software, y entendemos que este artiuclo de Fowler va en ese sentido

Famous failures of complex engineering systems.docx
****************************************************
Y finalmente el documento “Famous failures of complex engineering systems”, es un extracto de unas presentaciones del año 1997 del Instituto de Tecnología de California (Caltech) sobre fallas en sistemas de ingeniería complejos. Nos interesa que revisen el caso del sistema de equipajes del Aeropuerto de Denver y el del transportador de satélites Ariane 5. Estos son clásicos ejemplos de “errores de software”, que pueden ser entendidos mejor como “errores de diseño”. Es esa esquiva cualidad de diseñar, la que finalmente termina regulando la calidad de los proyectos.-
Esperamos que disfruten de estas lecturas.-
Atentamente

LINKS a documentos mencionados en esta nota

http://www.box.net/files/0/f/30066652/1/f_312406480#/files/0/f/30066664/1/f_312384976

http://www.box.net/files/0/f/30066652/1/f_312406480#/files/0/f/30066664/1/f_437877813

http://www.box.net/files/0/f/30066652/1/f_312406480#/files/0/f/30066664/1/f_437878735

http://www.box.net/files/0/f/30066652/1/f_312406480#/files/0/f/30066664/1/f_312385120

EL PROCESO DE CONSTRUCCION - CUADERNO II

Estimados colegas:
Seguimos con esta entrega del cuaderno VI, siendo esta la segunda parte.
La entrega contiene documentos referidos al análisis sobre el proceso de construccion de software
Hemos elegido para esta entrega un material clasico y uno actual El primero es un capitulo del libro de Uno Frederick Brooks "The Mythical man-month" El otro es un extracto de un capitulo del libro de Allistair Cockburn "Agile Software Development"- 2nd Edition

Mythical Man Month-Chapter 2
****************************
"...When a task cannot be partitioned because of sequential constraints,the application of more effort has no effect on the schedule (Fig. 2.2). The bearing of a child takes nine months, no matter how many women are assigned. Many software tasks have this characteristic because of the sequential nature of debugging..."

Allistair Cockburn-Cooperative Game-II:
**************************************
Imagine a competition in which each team must build something somewhere in a swamp. They don't know exactly what they have to build, they don't know where they have to build it, and they don't have a map of the swamp, but they are in a race to build it. They will create subteams. Some will scavenge for building materials, others will explore the swamp, and so on. Note that this corresponds to people finding different specialties in software development.If they have to play only one round of the game, they will find it optimal to build the weakest, sloppiest bridges and to draw the most careless maps possible to get to the end of the game. However, if they know another team will be coming in after them, they may choose to make better maps, better bridges, better paths. This difference between strategies corresponds to a software project team updating their system documentation and training their junior people.

----

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

EStos son los links a los documentos mencionados en esta nota

http://www.box.net/files#/files/0/f/30066652/1/f_312407236

http://www.box.net/files#/files/0/f/30066652/1/f_312406322

domingo, 25 de abril de 2010

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

sábado, 24 de abril de 2010

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