Estaba escribiendo una respuesta a un post en “historias de jp” sobre las software factories y me estaba quedando tan largo que finalmente he decidido liberarlo como un post propio.
Hay un movimiento desde hace ya décadas que intenta seguir procesos industrializados en la creación de sistemas software. En mi opinión intentar encajar el desarrollo de software dentro de una serie de procesos industriales al modo clásico es un error por los siguientes motivos:
- La cláve del éxito en el desarrollo de software está en los profesionales más que en una metodología repetible y medible. Un proceso industrial implica que los trabajadores son facilmente reemplazables sin repercusión en el resultado final. Cualquiera que haya desarrollado software el problema que supone la rotación de profesionales incluso en organizaciónes con procesos fuertes.
- Los requisitos cambian constantemente porque modelamos procesos de organizaciones vivas. Es imposible pretender que durante el desarrollo de un sistema ( que dura meses o incluso años) , la organización que lo va a utilizar no cambie su forma de operar. Esto nos lleva al siguiente punto:
- El diseño inicial no es fundamental. Si te dedicas a fabricar tornillos tendrás un diseño previo que se utilizará para construir múltiples instancias que serán iguales. Sin embargo, en el software cada sistema es único. Por otra parte debemos realizar un diseño previo suficientemente flexible como para admitir los cambios de los que hablamos en el punto anterior.
Como resumen final, la motivación y “calidad” de los profesionales es el factor de éxito principal en un proyecto software. Simplemente se necesita un poco de proceso (metodologías ágiles) para coordinar a los profesionales. Desde luego que un “operario” con un curso de Java de 300 horas con un montón de manuales describiendo procesos a 6 usos horarios de diferencia del cliente (que probablemente ahora mismo esté pensando en optimizar la logística ) sea la forma de hacer buen software.
2 respuestas hasta el momento ↓
JP // 30 Sep 2008 a 8:46 am |
Muy de acuerdo en lo que comentas, a medida que leía estaba pensando en metodologias ágiles, que chocan de frente con las Software factories.
Saludos,
JP
TheCoffeMaker // 21 Feb 2009 a 2:38 am |
Lamento tener que discrepar con tu comentario, en primer lugar para todo proyecto es muy importante el recurso humano, la mayoría de las veces, mantener los recursos importantes es una de las prioridades, aunque la realidad es que para muchas empresas, somos prescindibles … pero eso es otra cuestión que, personalmente, se la asignaría al departamento de recursos humanos. Sobre este mismo punto, debemos tener en cuenta, que por cada movimiento de personal, tenemos una perdida en la productividad de nuestro equipo, ya que tenemos un miembro que debe entrenarse.
Estoy completamente de acuerdo con que los requerimientos son cambiantes sobre todo el ciclo de vida de un sistema, pero debo objetar nuevamente. Los metodos que vienen desarrollandose desde las ultimas decadas tienen contemplado esto desde la misma definicion del metodo … UP y RUP son metodologias de desarrollo iterativos e incrementales (dirigidos por casos de uso y centrados en la arquitectura), lo cual implica que en cada iteracion se analizan los requisitos, se diseña, implementa y se prueba y así incrementalmente llegar al producto final, si hay cambios en los requerimientos, estos deben ser contemplados en las iteraciones. Los metodos agiles, tienen principios parecidos, los cuales implican una alta participacion del cliente, entregas incrementales y aceptacion del cambio entre otras cosas.
Ahora bien, hablando de la face de diseño (notece que puse face, ya que no quiero hacer mención del documento resultante de dicha face), tenemos que aclarar que los resultados de dicha face no tienen que definir al sistema completamente … siempre hablando de las ultimas metodologías, claro está, que para el método en cascada, cada face debe completarse para poder continuar con la otra, esto quiere decir, que para metodologias iterativas e incrementales, podemos seleccionar varios componentes, mejor dicho, seleccionar los casos de prueba de los casos de uso que mas riesgo, complejidad o importancia tengan(depende de la planificación y la disponibilidad de recursos), y luego ir añadiendo componentes en las proximas iteraciones.
Para ir cerrando un poco la idea, estas metodologías pueden encajar tranquilamente en un modelo formal, el cual garantiza la calidad y eficiencia de los procedimientos utilizados por la empresa en determinadas áreas. En concreto modelos como el muy conocido CMMI evalúan la capacidad y madures de áreas especificas de una organización, como ser, desarrollo, servicios y adquisición.
Saludos!!!