El siguiente articulo esta conformado por las experiencias y opiniones de su autor, Silicio mantiene una posición neutra al respecto de los argumentos debatidos.
Las actividades o procesos del ciclo de vida del software son: requerimientos, diseño,construcción,pruebas y mantenimiento, en ese mismo orden.
Estas actividades principales se dividen y definen de la siguiente forma:
Requerimientos:
“Un requerimiento es definido como una propiedad que debe ser exhibida a fin de resolver algún problema del mundo real” [SWEBOK]
- Levantamiento
- Análisis
- Especificación
- Validación
Diseño:
El diseño es tanto el proceso como el resultado de definir la arquitectura, componente, interfaces y otras características de un sistema o componente [IEEE 610.12-90]
- Arquitectura
- Métodos y Estructura
- Documentación
- Evaluación
Construcción:
La creación detallada de software funcional mediante una combinación de codificación, verificación, pruebas unitarias, pruebas de integración y depuración
- Gestión de la construcción
- Aspecto Prácticos
Pruebas:
Verificación dinámica del comportamiento de un programa sobre un conjunto finito de casos de prueba contra su comportamiento esperado
- Niveles
- Técnicas
- Mediciones
- Procesos
Mantenimiento:
Aplicación de cambios al software para corregir defectos, acomodar nuevos requerimientos o cambios a requerimientos existentes y/o al ambiente operativo
- Procesos
- Técnicas
Ya teniendo conocimiento sobre de que se trata este proceso es bueno considerar la siguiente pregunta:
¿Es económicamente factible realizar actividades o procesos del ciclo de vida del software?
Para tomar en cuenta la factibilidad económica que tiene realizar el ciclo de vida del software, también hay que tomar en cuenta el tipo de aplicación que se está desarrollando, se toma en cuenta el lugar, las circunstancias, el equipo, necesidades, etc. Por ejemplo, no es lo mismo desarrollar una aplicación personal, que una aplicación para un cliente.
Para una aplicación personal sería indiferente realizar el ciclo de vida del software completo o no, porque no tienes tiempo de entrega, tu nombre no está en juego, puedes terminarla o no a gusto e incluso tendría más costo en tiempo realizar el ciclo de vida completo, por ende no tiene factibilidad económica realizarlo en este caso. Todo esto puede variar si quieres convertir la aplicación en unaaplicación como producto, hacer esa transición podría costar 3 veces más, es decir que en muchas ocasiones cuando te saltas pasos como el de Documentación o Diseño, y tu aplicación cambia su objetivo, te costará más de lo que te ahorraste por no hacerlo al principio, así que si aspiras a que tu aplicación evolucione, es factible económicamente realizar el ciclo de vida del software.
Otro caso particular es cuando estás en contra del tiempo, cuando te piden desarrollar una aplicación en corto tiempo y debes elegir entre entregar a tiempo o entregar una aplicación con todas sus pruebas y documentación como es debido. Cuando es un cliente exigente, o es para un jefe que no conoce de desarrollo de software, donde pierdes el proyecto o te despiden del trabajo, es obvio que lo factible en este caso es entregar a tiempo y las consecuencias del costo la pagaran el cliente o jefe.
Por lo visto en todos los casos, sea uno mismo o el cliente, alguien debe pagar el costo de no haber completado el ciclo de vida, aunque en los casos que no somos nosotros es factible porque es a nosotros a quien nos deben pagar más. Como dije antes, esto es cuando se hace una aplicación contendencia a evolucionar o ser modificada, no pasa en aplicaciones que tienen una sola finalidad y no se planea una evolución o modificación de esta, aunque en muchos casos nunca se hace lo que se planea y sucede lo anterior ya explicado.
Un paso del ciclo de vida es hacer un prototipo de la aplicación, este me parece factible económicamente porque puedes mostrar al cliente cómo será su aplicación y de esa manera te evitas que quieran cambios después de haber completado el trabajo o durante su elaboración. En contra de esto está el factor tiempo que puede convertir un prototipo en la fase final y entregar algo inestable que costará mucho hacerle cambios.
Hacer el ciclo de vida completo implica aplicar ingeniería al software, ¿Por qué aplicar ingeniería al software?, porque el software o el concepto de ingeniería de software es de los más jóvenes entre todas las ingenierías y es de las ingenierías que más se les exige. La diferencia está en que si un ingeniero civil dice: “yo termino este proyecto en 5 años y costará una cantidad ‘X’ ”, simplemente le responden con un “está bien”, ahora, si el ingeniero en software dice lo mismo le responden: “Lo quiero en 5 meses y solo puedo darte la mitad del dinero que pides”, en ese caso tienes 2 opciones, aceptar la oferta y olvidarte de todo el ciclo de vida para poder entregar el proyecto como lo quieren, o no aceptarlo, y es aquí donde los ingenieros de software fallamos porque siempre habrá uno que acepte y empezamos a desvalorizar nuestro trabajo, por ende este es otro caso donde no es factible económicamente saltarse estos paso y aceptar ofertas de este tipo.
De todo lo que les he hablado es de aplicaciones donde no se involucran vidas humanas, en este caso es muy diferente, no hay peros que valga, ya que un simple error puede costar la vida de cientos de personas,aquí es hacer el ciclo de vida completo sí o sí. En estos tipos de trabajos se aplica la ingeniería al software de manera correcta y económicamente es más factible hacerlo porque un simple error puede costar tu confianza como desarrollador al hacer una aplicación que involucre vidas humanas.
Todos estos aspectos hay que considerarlos a la hora de decidir si realizar el ciclo de vida del software o no.
En conclusión, personalmente considero que en todos los casos donde sea posible hacerlo(a ‘posible’ me refiero que el cliente o jefe te permitan hacerlo), debes realizar las actividades o procesos del ciclo de vida del software, porque como demostré en cada uno de mis ejemplos, en cada caso hay alguien que siempre termina pagando los costos de no realizar este tipo de actividades, aunque parece que no cuesta o que es más sencillo no hacer estas actividades, al final cuando quieres que tu aplicación crezca, el costo por no hacerla es mucho mayor, ya que al final tendrás que realizarlas y será mucho más complicado.
Su aspecto se aleja bastante de la imagen clásica, con un toque bastante más futurista y con ligeros cambios en la paleta de colores. De esta forma pierden parte de su esencia, pero ganan un aspecto mucho más amenazador.
