Desarrollo de Software Esbelto

 

Desarrollo de Software Esbelto

 M.C. Juan Ca Carlos rlos Olivare Olivaress Rojas Profesor de la Escuela de Ingeniería en Sistemas Computacionales Computacionales.. Muchas de las técnicas del área de producción de la Ingeniería Industrial se han migrado al desarrollo de software en muchos casos con buen éxito. Recientemente los conceptos de manufactura esbelta se han empezado a utilizar en el área del desarrollo de software. Los orígenes de la manufactura esbelta se remontan a la década de 1960 con el sistema de producción de Toyota denominado Kanban cuyas características principal principales es eran la autonomía total, el realizar los procesos justo a tiempo lo cual implica no manejar almacén y no realizar inspecciones. Este esquema hizo que ráp rápidamente idamente T Toyota oyota se ubicará como la primera armadora de carros en los Estados Unidos. Todos estos conceptos se migraron al área de producción para crear el concepto de manufactura esbelta. Los principios esbeltos aplicados a la producción más importantes son los siguientes: 1. Los que hacen las cosas son los que saben 2. Se manejan lotes chicos (privilegia los desarrollos personalizados a los de masa)  Lean Softw Software are Dev Developme elopment  nt ) fueron En lo referente al desarrollo de software esbelto ( Lean Mary y Tom Tom Poppendieck los primeros en transferir los p principios rincipios de la manufactura esbelta al software software.. El desarrollo de software esbelto está muy casado con el concepto de desarrollo ágiles aunque son conceptos totalmente distintos. distintos. El desarrollo esbelto implica agilidad aunque la agilidad no necesariamente implica ser esbelto. Por ejemplo una persona que es esbelta generalmente es ágil, una persona que es ágil no necesariamente esbelta (hay muchas personas que aun siendo obesas desarrollan agilidad). En cuestión de desarrollo de software, la agilidad implica desarrollar cosas con destreza (no necesariamente rápido) mientras que el desarrollo de software esbelto de manera esencial consiste en eliminar procesos innecesarios. En una era donde ser esbelto está de moda , ¿se puede poner a dieta los procesos de desarrollo de softwa software? re? Por raro que parezca, no existe una denición formal de metodologías esbeltas simplemente se usan los principios del pensamiento ágil. Cada autor varía los principios manejados. A continuación se muestran algunos principios básicos y su explicación. Principio1: Eliminar el desperdicio Por desperdicio se entiende todo aquel proceso que no crea valor para los clientes y que en muchas ocasiones retrasa la entrega de proyectos proyectos.. ¿Qué cosas no crean valor en el desarrollo de software? Lista de requerimientos, diseño de la aplicación, errores y sobre todo funcionalidad no usada. Se tiene el mito que la especicación temprana del producto de software reduce el

 

desperdicio. En la práctica se ha comprobado que inuye más la forma de desarrollar que en sí el mismo producto debido a la complejidad del software. P Por or ejemplo: el desarrollar un software a través del modelo de cascada en teoría debería evitar problemas en el desarrollo. En la práctica siempre se dan problemas dado que el software es un producto no tangible cuyas especicaciones van cambiando frecuentemente. Principio 2: Construir con calidad La inspección es un proceso fundamental para lograr el aseguramiento de la calidad del software.. Se recomienda guiar nuestro desarrollo a través pruebas automatizadas software sobretodo del tipo unitarias y de aceptación. En este sentido se tiene el mito de que el trabajo del tester es encontrar errores cuando su rol principal es vericar que el producto de software sea de calidad. Una de las metas fundamental del desarrollo esbelto de software es reducir el tamaño del código de manera considerable tomando en cuenta la premisa que a menor código menor probabilidad de error. error. En este tenor tenor,, se debe seguir el prin principio cipio de mantener lo más simple el diseño del software así como utilizar técnicas más avanzadas como la refactorización de código. Principio 3: Crear conocimiento Dada la naturaleza del software no es posible conocer las necesidades de un producto de software desde el inicio y tampoco es posible el diseñar sin implementar dado que en general el diseño se va puliendo poco a poco. Se debe de ver el desarrollo de software como un proceso de aprendizaje y mejora tanto del producto como del negocio en sí. Bajo este contexto, se tiene la creencia que el manejar predicciones crean predictibilidad, este concepto es erroneo dado que el desarrollo de software es un proceso sociotecnológico sociotecnológico que al verse involucrado por el capital intelectual no es predecible. Principio 4: P Postergar ostergar co compromiso mpromiso En este apartado se deben de tomar decisiones que no sean reversibles y encontrar soluciones que se puedan invertir. En palabras más claras, se debe tratar que el proceso de desarrollo no cambie, se quede estandarizado pero que la solución pueda ser modicada fácilmente. En este punto el mito más generalizado en el desarrollo de software es la idea de que la planicación crea compromiso. En el desarrollo de software no se cumple tal cual por que los requerimientos cambian. Principio 5: Entregas rápidas El entregar versiones del software software antes de que esté terminado al 100% hace que se mejore la calidad, calidad, que el costo sea más bajo, que haya menos cambios. Se tiene el mito que el apuro causa desperdicio y en la práctica se ha demostrado que en software entre más rápido se entreguen partes funcionales del software Principio 6: Respetar a las personas Se debe fomentar el liderazgo y el emprendurismo a todos los niveles del equipo de desarrollador de software. El control del software debe estar basado en los objetivos. Principio 7: Optimizar el todo

 

Se debe tener esta premisa siempre pero se debe de recordar que el cliente siempre quiere las cosas para ayer y las pruebas siempre están sobrecargadas por falta de tiempo. En este sentido se debe optimizar cuando se pueda y realmente sea necesario. Se tiene el mito generalizado de que si se maneja optimización automáticamente se mejora la calidad del producto de software. En la práctica pocas mejoras son sustanciales y sólo hacen generar desperdicio. Mito: optimizar por descomposición Referencias

Gabardini, J. J. (2009) Lean Software Development. F Facultad acultad de Ingeniería – UBA, Argentina  Wikipe  Wik ipedi diaa Fu Funda ndati tion on (200 (2009) 9),, So Soft ftwa ware re Es Esbe belt lto o, ht http tp:/ ://w /www ww.w .wiki ikipe pedia dia.o .org rg,, co cons nsult ultado ado en Agosto 2009.