Tag Archives: Software Assembly Line

Programacion finalice primero / Done first programming


Agile Programming
Chaos produced by not well managed agile programming

Cuando nos dedicamos a realizar software, se nos mide por la cantidad y calidad de programas terminados que tengamos en nuestro historial, ya sea como desarrolladores individuales o como empresa desarrolladora de software. Si queremos tener buena reputación, debemos tener en nuestra experiencia proyectos culminados de desarrollo en los cuales demostremos que conocemos el ciclo completo para desarrollos de software. De esta forma si es una empresa nueva que empieza a desarrollar, debe hacer el doble de esfuerzo, terminar su primer proyecto y hacerlo bien. Mientras no termine este primer proyecto, siempre va a seguir siendo una empresa novata y no va a lograr tener un alcance de mercado significativo. Recordemos, si no terminamos el software que iniciamos no tendremos buena reputación como desarrolladores de software.

El continuo uso del concepto de programación ágil ha cambiado la mentalidad de los clientes, mientras que la mayoría de las empresas de desarrollo que ofrecen este servicio siguen igual, haciendo internamente una gran cantidad de procesos que anulan la posibilidad de manejo ágil. El manejo ágil sirve para muchos proyectos, pero no todos los proyectos pueden ser manejados de esta forma. Normalmente un proyecto muy grande no puede ser manejado como un “super proyecto ágil” porque no quedaría bien. Lo más cercano sería manejarlo como muchos proyectos ágiles e irlos engranando a medida que se van finalizando, pero cada caso es particular. La experiencia del director de proyecto, el arquitecto, los desarrolladores y los probadores es fundamental para saber como se debe abordar cada caso. Se necesita siempre de un gran equipo para lograr excelentes resultados en cada proyecto. Debe existir una cadena de conocimiento que se aplique a cada proyecto para garantizar su feliz término. Una de mis propuestas como técnica de desarrollo ágil puede ser SAL (Software Assembly Line) / LES (Línea de Ensamblaje de Software)

No importa finalmente si se decida realizar programación ágil o programación no ágil, lo importante es terminar siempre cada proyecto. Basándonos en que el cliente siempre tiene la razón, debemos tener algo con que negociar siempre. Si hay al menos un prototipo, tenemos con que negociar. Así que necesitamos siempre algo tangible para poder tener un patrón de comportamiento a seguir, luego de cada reunión con nuestro cliente. Negociar con base en supuestos genera “incertidumbres infinitas”, mientras que negociar con un “bosquejo”, “prototipo”, etc. puede darnos certezas medibles y “ejecutables”.

Mas vale tener siempre un producto finalizado que se pueda modificar que una gran cantidad de ideas no realizables. Cabe añadir que no nos sirve tampoco tener un prototipo sin haber hablado con el cliente y aterrizado sus requerimientos. Esto si debe permanecer siempre si queremos que nuestro primer prototipo tenga el valor que hará que el cliente se sienta satisfecho.

Advertisements

Software development technologies (Introducing SAL: Software Assembly Line)- Tecnologías de desarrollo de software


When searching on internet to find the best method to create or modify software what will we find? A LOT of methods, architectures, patterns, etc. How can we deal with that? what to trust? If we know someone that is using some of these methodologies and it’s working fine, we can start with that, but what if we don’t? Just to list some of the actual methodologies (to know more about any of them, just search the name listed plus the word methodology):

  1. Waterfall
  2. EVO
  3. Crystal
  4. EUP
  5. AUP
  6. EssUP
  7. OpenUP
  8. MSF
  9. FDD
  10. CMMI
  11. PMBOK
  12. Prince2
  13. DSDM
  14. RUP
  15. LeanSD
  16. USDP
  17. XP
  18. Scrum
  19. Prototype
  20. Spiral
  21. ……and a lot more

So, what is the main goal of all of these methods? Answer: to create excellent software. And all they have the same sources as well: Stakeholders, Processes and Data. Nothing else, so when in this life this becomes so complicated?

Trying to get the best results people or engineers use existing methods to create new ones.

Starting with the fact that the source to create software is Always the same we can deduct this:

  1. Stakeholders, processes and data are the sources to create the software.
  2. We need to understand in the most exact way the requirements for the software talking with stakeholders until we and they are complete sure everything related is correctly written.
  3. Create a design for the new software and show it to the stakeholders until its accepted making the proper changes.
  4. Start to develop the software.

And I call that: SOFTWARE ASSEMBLY LINE

This is needed for any of the existing methodologies, the difference is how we use the sources. What I can tell right now is that We cannot create software if the source is not telling us exactly what they need. Once we know what to do and the design is accepted, we are done. How to construct the software is just a matter of what the stakeholders want (web, desktop, mobile, Tablet, tv, or any device).

All these methodologies are good enough to create software, We just need to know the proper one and go through that. Or We can just: create software by using SOFTWARE ASSEMBLY LINE – “SAL”. If you need the Methods and specifications for SAL, kindly live me a message.

*********************************************Español

Al buscar en Internet los mejores métodos para crear o modificar el software que vamos a encontrar? Una gran cantidad de métodos, arquitecturas, patrones, etc ¿Cómo podemos lidiar con eso? en qué confiar? Si conocemos a alguien que está usando alguna de estas metodologías y está funcionando muy bien, podemos empezar con eso, pero lo que si no lo hacemos? Sólo para enumerar algunas de las metodologías actuales (para saber más sobre cualquiera de ellos, sólo buscar la palabra metodología más el nombre listado): 1.Waterfall 2.EVO 3.crystal 4.EUP 5.AUP 6.EssUP 7.OpenUP 8.MSF 9.FDD 10.CMMI 11.PMBOK 12.Prince2 13.DSDM 14.RUP 15.LeanSD 16.USDP 17.XP 18.Scrum 19.Prototype 20.Spiral 21 ……. y mucho más

Así que, ¿cuál es el objetivo principal de todos estos métodos? Respuesta: crear un excelente software. Y todos ellos tienen las mismas fuentes, como son: las partes interesadas (stakeholders), procesos y datos. Nada más, por lo que, cuando en esta vida, esto se volvió tan complicado?

Tratando de obtener los mejores resultados los ingenieros y otras personas utilizan métodos existentes para crear otras nuevas metodologías.

Empezando por el hecho de que la fuente de la creación de software es siempre la misma, podemos deducir lo siguiente: 1.Stakeholders, los procesos y los datos son las fuentes para crear el software. 2.Se debe entender de la manera más exacta los requisitos para el software que hablando con los stakeholders hasta nosotros y ellos estemos completamente seguros que todos los requisitos relacionados están escritos correctamente. 3.Crear un diseño para el nuevo software y mostrar a las partes interesadas hasta su aceptación haciendo los cambios adecuados. 4.Iniciar a desarrollar el software.

Y esto lo llamo: SOFTWARE LÍNEA DE MONTAJE (SLM o SAL en inglés)

Esto es necesario para cualquiera de las metodologías existentes, la diferencia es la forma en que utilizamos las fuentes. Lo que puedo decir ahora es que no podemos crear software si la fuente no nos dice exactamente lo que necesitan. Una vez que sabemos qué hacer y el diseño es aceptado, hemos terminado. Cómo construir el software es sólo una cuestión de lo que los stakeholders quieren (web, escritorio, portátiles, Tablet, tv, o cualquier dispositivo).

Todos estos métodos son lo suficientemente buenos para un proyecto, sólo necesitamos saber el adecuado y listo. O podemos simplemente: crear software utilizando SOFTWARE LÍNEA DE MONTAJE – “SLM”. (Software Assembly Line SAL). Si desea los métodos y especificaciones puede dejarme un mensaje.