Primeros Proyectos 

(primeras experiencias)

No fueron en el área del software , pero aprendí mucho de ellos

-La primera  vez que me pidieron formalmente que hiciera un "proyecto" fue cuando era estudiante en la catedra "estructuras metálicas" , el profesor me pidió hacer un "proyecto" para galpón de acopio y expedición de cereales a granel , en una zona rural ,donde también había una procesadora de la cosecha de granos.

Fui a Reunión donde me informaron algo mas: el tipo de grano acopiado , las dimensiones esperadas , la circulación esperada de vehículos , las alturas mínimas , el clima de la zona .

Tenia que presentar un plano de estructura , con memoria de calculo.

Yo estudiaba ingeniería industrial , era el único "colado" en esa materia común con ingeniería civil. Así que consultando con mis compañeros me entere que los cálculos de los materiales a utilizar no se hacían con la clásica teoría estudiada de resistencia de materiales . las solicitudes se calculaban en base a los conceptos estudiados , pero la propuesta de implementación (perfiles y uniones)  se hacia en base a una NORMA  standard que se aceptaba en la regíon.

Resumiendo , ese "proyecto" era un conjunto de documentos (normalizados) que permitían al solicitante evaluar si lo que yo proponía era aceptable , construible y : una solución beneficiosa para la situación planteada  .

-Mas adelante en la catedra de "proyectos industriales"  me pidieron que propusiera una planta industrial para la obtención de gas carbónico.

Eso fue mucho mas interesante , me pedían un volumen de producción mínima y dejaban a mi elección la materia prima , la localización , y el equipamiento de planta.

En realidad era un anteproyecto , porque el objetivo era: decidir si era factible y rentable: una fabrica

Esperaban que mi proyecto supere los problemas básicos de adquisición  de la materia prima y que los procesos elegidos consigan el producto a un costo que justifique la inversión

La evaluación no era parte del trabajo

Tenia que entregar una justificación de la elección de la materia prima , un esquema de la línea  de producción con las capacidades seleccionadas para cada proceso y su posible equipamiento. Una memoria de calculo de cada proceso y un calculo estimado de costo de producción

Tenia un profesor como tutor , la biblioteca de la universidad , manuales de presentación de proyectos , y promesas de contactos para satisfacer todas mis dudas

Fue un trabajo que me entusiasmo mucho. No me atraían tanto los procesos productivos , pero me volaba la cabeza el proceso de elaboración del proyecto

- En condición de pasante en empresas mineras ; en una boratera , presente un proyecto de "decantador "  de el material extraído "in situ"  . Justificado con mediciones de laboratorio. 

- En una empresa de extracción de mineral de hierro ,mi proyecto fue: alternativas para la formación de colas de camiones transportadores de mineral desde la extracción hasta planta de clasificación . Para justificar mi propuesta hice un estudio de movimientos y tiempos de camiones en el trayecto : bocamina- planta de clasificación . 

Estos 2 últimos , eran anteproyectos para un análisis de factibilidad y oportunidad.  La boratera estaba en plena producción desde hace años y la extractora de hierro estaba en etapa de preparación para explotación de la mina.

- Apenas recibido generamos con otros profesores de la universidad un proyecto para implementar modelos econométricos computarizados de auxilio para las cátedras de ingeniería i administración de empresas (eran los primeros años de las microcomputadoras) . Entonces hubo un concurso regional para financiar proyectos y hubo que llenar formularios para contar lo que pensábamos hacer ... Pero no con nuestra idiosincrasia o lenguaje. Se trataba de una intimidante cantidad de formularios a rellenar para que un evaluador decidiera apoyar o no la inversión del estado en nuestro proyecto.

Proyectos de Software (capitulo 1)

Conceptos básicos

Ì   CONCEPTO DE PROYECTO: Como ya vimos el termino “proyecto” tiene 2 significados habituales

1- Conjunto de antecedentes que permiten estimar las ventajas y desventajas de aplicar ciertos recursos a la solución de necesidades en forma de productos o servicios

2-  Actividad de cualquier naturaleza que requiere para su realización,  del uso o concurso de algunos recursos escasos (o limitados) , con la esperanza de obtener beneficios superiores a los que se obtienen con el empleo actual de dichos recursos    

    Proyecto de un automóvil , de una carretera , de un puente , de una computadora ,de una nueva maquina industrial ,de producción de automóviles , de construcción de un edificio , de mejora de la producción ,etc  tienen en común que el objeto del proyecto es algo concreto y que para su elaboración se recurre a disciplinas con métodos  y  estándares establecidos 

Y que sucede con el software?  ...   resulta que no se trata de algo concreto . mas bien se caracteriza por (segun F. Brooks) :

 Ì CARACTERISTICAS ESCENCIALES :

Complejidad: La complejidad del software es una propiedad esencial no una accidental

Muchos de los problemas clásicos del desarrollo de productos de soft derivan de su esencia compleja y su crecimiento no lineal … 

Conformidad: Mucha de la complejidad que debemos manejar es "complejidad arbitraria" forzada por instituciones y sistemas creados por humanos , a cuyas interfaces el soft debe conformar...

Cambiabilidad (posibilidad de cambio) La entidad de software está constantemente sujeta a presiones de cambio. Por supuesto, también lo son los edificios, coches, ordenadores. Pero las cosas manufacturadas rara vez se modifican después de su fabricación; Son reemplazados por modelos posteriores, o se incorporan cambios esenciales en modelos que son el mismo diseño básico pero con numero de serie nuevos.  Las evoluciones de  automóviles son realmente bastante infrecuente; los cambios  de las computadoras lo son un poco menos. Ambos son mucho menos frecuentes que modificaciones al software .  En parte, esto se debe a que el software de un sistema resuelve su función, y la función es la parte que más siente las presiones del cambio. En parte se debe a que el software puede ser cambiado  más fácilmente ( es pura materia de pensamiento, infinitamente maleable. )                         De hecho, los edificios pueden cambiar , pero los altos costos del cambio, entendidos por todos, sirven para amortiguar los caprichos de los cambiadores. Recordar que:Todo el software exitoso se cambia. 

Hay dos procesos en juego:     Como el producto de software resulta útil, la gente lo prueba en casos nuevos que se encuentran en el límite o más allá del  dominio original. Las presiones para ampliar la función provienen principalmente de usuarios a quienes les gustan las funciones básicas e inventan nuevos usos para el soft.          En segundo lugar, el software exitoso también sobrevive más allá de la vida normal de la máquina para la  que se escribio por primera vez. Si no son computadoras nuevas, al menos discos nuevos, pantallas nuevas. Cambian  las impresoras; y el software debe adaptarse a sus nuevos vehículos de oportunidad. 

En resumen, el producto de software está integrado en una matriz cultural de aplicaciones, usuarios, leyes y vehículos mecánicos. Todos ellos cambian continuamente, y sus cambios inexorablemente fuerzan el cambio en el producto de software

esta caraceristica sera un aspecto central en un proyecto moderno de software de pequeño y mediano tamaño

Invisibilidad: El soft es invisible e imperceptible. No puede ser explicitado en un espacio , como la geometría (no en uno sino en muchos gráficos superpuestos)

El  proyecto de software tiene algo de  carácter intimidante (al menos tal como lo ve un gerente que no es  del área), generalmente inocente y directo, pero capaz de convertirse en un monstruo de cronogramas incumplidos , presupuestos arruinados y productos defectuosos. 

A pesar de todas estas precauciones , un proyecto de  software en una empresa , sera evaluado como cualquier otro. Es decir: un proyecto sera analizado como una alternativa  de aplicacion de los recursos de una empresa. (alternativa limite: el proyecto o no hacer nada)

Ì INVERSION:                                                                                                                                                                                Definición clásica : Asignación de recursos efectuado con la esperanza de obtener beneficios futuros  que permitan recuperar los fondos invertidos y lograr ganancias económicas , satisfacción de una necesidad o el aprovechamiento de una oportunidad

Ì FLUJO DE FONDOS:

Cuando se haga una análisis económico de un proyecto, se evaluara su posible impacto sobre los objetivos seleccionados comparando las diversas maneras como se podrían utilizar los recursos que el proyecto requiere.El impacto es analizado técnicamente y económicamente. El análisis económico debe fundar toda decisión en criterios aplicables a todas las alternativas .  El movimiento de efectivo constituye un hecho concreto claramente definido , no susceptible de interpretación ni tratamiento discrecional.                                                                                                                                                                           NO confundir con costos y beneficios

Hay que considerar los proyectos que no generan flujo de fondos (los llamados ahorradores) que tienen mucho que ver con la productividad y los métodos de trabajo , son casos comunes en el software. Hay que analizar cuidadosamente y no buscar ciegamente calcular la ROI

Los costos seran analizados contra los costos de las alternativas , generalmente la de no hacer el proyecto . 

información  para la dirección de un proyecto bajo PERT

Generada por el modelo PERT para  una fecha (T)

-probabilidad de completar el proyecto en fecha (F)  establecida 

 -sucesos alcanzados y actividades terminadas

-actividades que deberían haber empezado

-actividades que deberian haber terminado

-actividades que deberían empezar y terminar en el próximo periodo

-actividades anticipadas con relación al tiempo de comienzo o de terminación previstos

-duración total estimada para una actividad

-duración restante o tiempo de la fracción de actividad que queda por realizar a la fecha del informe

-cantidad o porcentaje de proyecto realizada hasta la fecha o en el periodo de informe,  si se establecieron estos parámetros en el programa

-fecha en que debería terminar la actividad si se altero la fecha de comienzo

-tiempo que puede desplazarse el comienzo o la terminación de la tarea si se produjo cambio en el margen total.

-actividades añadidas o suprimidas desde el informe anterior

-cambios en las previsiones de tiempos de los anteriores informes

-márgenes negativos en relación con la fecha impuesta para la terminación del proyecto

Breve resumen de la evolución de métodos de desarrollo 

de soft     "agile"

( hasta 2013)

El desarrollo ágil es un marco conceptual que reconoce las distintas interacciones y cambios que ocurren en todo desarrollo de software. Evolucionó a partir de varios métodos. El Término "Ágil" fue definido por el "Manifiesto Ágil" en 2001. A continuación presentamos una línea de tiempo con los principales eventos en la historia del movimiento ágil:

1930 - Ciclo PDCA

Walter Shewhart propone el ciclo de "Planear", "Hacer", "Estudiar" y "Actuar", un concepto que luego fue difundido por Deming.

1940 - Kanban, Sistemas de Producción de Toyota y el Lean Manufacturing  (Manufactura esbelta)

Taiichi Ohno inventa el método Kanban en Toyota. El Lean Manufacturing es una fuente de inspiración y precursor del movimiento ágil.

1974 - El Proceso de Desarrollo de Software Adaptativo

Un Paper de E.A. Edmonds presenta el concepto de "Proceso de Desarrollo de Software Adaptativo" en 1974. Asimismo, también durante los 70, Tom Gild publica conceptos sobre la Gestión de Proyectos Evolutiva (EVO).

1992 - Crystal

Alistair Cockbur presenta los Métodos Crystal, el punto de inicio de la evolución de las metodologías de desarrollo de software que eventualmente resultaron en lo que hoy se conoce como el movimiento ágil.

Crystal puede ser aplicada en equipos de trabajo de entre 6 y 8 desarrolladores localizados en la misma área, trabajando en sistemas no críticos para la vida (es decir los fallos son tolerables).

1993 - Refactorización

Bill Opdyke presenta el concepto de "Refactorización" en su paper titulado "Creando Superclases Abstractas por medio dela Refactorización".

La Refactorización de código es una técnica para la reestructuración de piezas de código existente, alterando su estructura interna sin afectar su comportamiento con el exterior, que se ejecuta para mejorar los atributos no funcionales de un software.

995 - Programación en Pares (Pair Programming)

Es un concepto que fue simultáneamente ideado, pero de forma independiente por varios autores. Por una parte JimCoplien publicó un Paper , que definió la "Programación en Pares" como un patrón de desarrollo de software. Por otraparte Larry Constantine definió los "duos dinámicos" en su libro "Constantine on Peopleware" del mismo año.

Este concepto se convirtió en una parte integral de la Programación Extrema.

Se han realizado muchas investigaciones que han demostrado la efectividad de la programación en pares. Sin embargo, lafilosofía no está reflejada en el Manifiesto Ágil.

1995 - Scrum

El método Scrum  fue ideado por Ken Schwaber y Jeff Sutherland, quienes lo presentaron en la conferencia OOPSLA95 (Object-Oriented Programming, Systems, Languages & Applications) en Austin Texas. Jeff Sutherland es el Presidente(CEO) de Scrum, Inc y Ken Schawaber es el fundador de Scrum.org.

Mike Beedle fue uno de los pioneros en adoptar Scrum y colaboró con su adopción en muchas organizaciones. Como se sabe, Scrum es prácticamente el estándar de facto para el desarrollo ágil.

1997 - Desarrollo guiado por funcionalidades / Feature Driven Development (FDD)

El método FDD fue inicialmente ideado por Jeff De Luca. En él se definen mejores prácticas como son: Modelado de objetos de dominio, Desarrollo por funcionalidades, Propiedad individual de las clases (Código), Equipos de trabajo por funcionalidad, Inspecciones, Gestión de Configuración, Compilaciones regulares (periódicas) y visibilidad del avance y resultados.

El Proceso FDD fue explicado por medio de la publicación del libro "Modelado Java a Colores con UML: Componentes yProcesos Empresariales", cuyos coautores son Jeff De Luca y Peter Coad.

1999 Desarrollo de Software Adaptativo

Jim Highsmith formalizó el concepto de Desarrollo de Software Adaptativo y público su libro del mismo nombre. La ideacreció y evolucionó hacia las metodologías de Desarrollo Rápido de Aplicaciones (RAD). La metodología propone un ciclode vida de 3 fases: Especulación, Colaboración y Aprendizaje.

1999 - Programación Extrema / Extreme Programming (XP)

Mientras trabajaba en Chrysler, Kent Beck desarrolla el concepto de Programación Extrema

, publicando el método en1999 en un libro titulado "Extreme Programming Explained". Como parte de la Programación Extrema, también formuló los conceptos de  Historias de Usuario y Planificación de Releases. La metodología especifica buenas prácticas para la planificación, gestión, diseño, codificación y pruebas.

Ward Cunningham y Ron Jeffries colaboraron con Beck al escribir el libro sobre XP, a los tres se les considera losfundadores de la Programación Extrema.

1999 - Integración Continua

Kent Beck definió este concepto también, pero fue un paper de Martin Fowler el que lo popularizó.

2001 - El Manifiesto Ágil

Bob Martin, reúne a otros 16 líderes del movimiento ágil, para escribir el "Manifiesto Ágil", que engloba las metodologíasque hasta ese momento se les conocía como "Metodologías de Desarrollo de Software de peso liviano".

2002 - Desarrollo guiado por pruebas / Test Driven Development (TDD)

El concepto se originó el enfoque de "Probar primero" asociado a la Programación Extrema (XP). Luego tomo mayor conla publicación del libro "Desarrollo guiado por pruebas: Por ejemplos" (Test Driven Development: By Example), escrito porKent Beck.

Luego Kent Beck escribe otros libros sobre el tema como "Rediscovering Test-Driven Development".

2002 - Planning Poker

También en 2002 nace la técnica de Planning Poker, ideada por James Greening y escrita en un Paper.

2003 - Desarrollo de Software Esbelto / Lean Software Development

Mary y Tom Poppendieck presentan su obra "Lean Software Development".

El Lean Software Development es una adaptación de los principios de la manufactura esbelta y de los del desarrollo de software. Presenta 7 principios: Eliminar desperdicio, amplificar el aprendizaje, Decidir tan tarde como sea posible, entregar lo más rápido posible, dar poder al equipo (empowerment), construir integridad y ver la totalidad. Como se puede ver estos principios están alineados con la filosofía ágil.

¿Es el Lean Software Development una metodología ágil?, o es algo distinto, muchos la consideran como el próximo eslabon en la evolución del desarrollo ágil.

2006 - Desarrollo guiado por comportamiento / Behavior Driven Development

Dan North presenta su obra "Behavior Driven Development", un método que combina las principales ideas y técnicas delTDD con las ideas del Diseño guiado por dominio y el Análisis y Diseño orientado a objetivos. El método se enfoca en proporcionar herramientas y procesos colaborativos entre desarrolladores de software y analistas funcionales, buscando acercar a los técnicos de software con las necesidades que impulsan al área de negocio.

2007 - Retrospectivas

Esther Derby y Diana Larsen escriben su obra "Agile Retrospectives", estableciendo las reuniones retrospectivas como práctica ágil estándar.

2007 - Kanban para el Desarrollo de Software

David Anderson presenta su obra "Kanban", adaptando el Kanban para el desarrollo de software. El método se enfoca en la entrega "justo a tiempo" y en no sobrecargar a los desarrolladores de software, tal como su precursor el Kanban para manufactura perfeccionado por Toyota. Bajo este enfoque, todas las tareas necesarias para entregar una funcionalidad al cliente se le muestran a los desarrolladores, quienes toman la tarea a realizar de una cola, de forma similar al backlog definido en Scrum.

El Kanban no prescribe una serie de pasos o métodos, no existe algo como "el método de Gestión de Proyectos Kanban",en su lugar, la intención es iniciar con los roles y procesos que se tienen actualmente y partir de allí estimular cambios continuos, incrementales y evolucionarios sobre el método de trabajo.

2009 - Manifiesto de la Artesanía de Software (Software Craftmanship)

Los asistentes a la primera conferencia internacional de Artesanía de Software escriben sus conclusiones y promulgan el "Manifiesto de Artesanía de Software". La artesanía de software no solamente se trata de prácticas de programación sino también de formar a la siguiente generación.

2009 - Lean Startup

Eric Ries escribe su obra "Lean Startup". Es una metodología mayormente teórica para el desarrollo de empresas yproductos. Basado en las experiencias de Ries trabajando con varios emprendimientos (startups), el método se basa enque los ciclos de desarrollo de productos pueden reducirse en duración por medio de ciclos continuos deexperimentaciones, iteraciones y lanzamientos de producto.

Ries establece que si las Compañías construyen sus productos o servicios de forma iterativa, buscando lanzarlos al cliente lo antes posible y adquirir aprendizaje a partir de allí, pueden evitarse los costosos proyectos y lanzamientos de nuevos productos.

tomado de: www.pmoinformatica.com/2013/06/una-breve-historia-de-las-metodologias.html