Las actividades relacionadas con la creación del software son muy parecidas a las que se realizan en cualquier proyecto. Considerando la propuesta de Pressman (2012) estas actividades son comunicación, planeación, modelado, construcción y despliegue, mismas que se describen a continuación.
Haz clic en cada actividad para revisar en qué consiste
El proceso de software puede llevarse a cabo a través de varios modelos de desarrollo. A continuación se explican algunos.
2.1 Modelo cascada
El modelo cascada se le atribuye a Winston Royce, no porque lo haya propuesto, sino porque fue el primero en analizarlo en un documento publicado en 1970. Este modelo de desarrollo de software establece etapas definidas y delimitadas de un proyecto de software. Tiene ese nombre debido a la secuencia de cada una de las etapas. Su característica fundamental es que cada etapa se realiza de modo independiente y no es posible iniciar una etapa hasta que su antecesora haya sido completada.
Fuente: Royce, W. (1970). Managing the development of large software systems. Recuperado de http://www.serena.com/docs/agile/papers/Managing-The-Development-of-Large-Software-Systems.pdf
Royce (1970) establecen las etapas que describen el modelo cascada:
Se definen los requerimientos del hardware necesario para el sistema.
Estos son los requisitos que describen las funciones del software.
Se establece un proceso de análisis de factibilidad del sistema y se documentan todos los requerimientos que deberá cubrir el sistema.
Incluyen tareas destinadas a generar la arquitectura que tendrá el sistema.
Se realiza la construcción del software a través de un lenguaje de codificación.
Se realizan acciones para probar que el sistema no tenga errores.
Son las actividades destinadas a mantener el sistema en operación.
En la literatura actual podrás encontrar algunas variantes del modelo en cuanto a los nombres de las etapas, pero coinciden en generalizar la secuencia de las actividades: análisis, diseño, construcción, pruebas e implantación.
La desventaja de este modelo es que las pruebas se realizan una vez concluida la construcción del sistema, poniendo el desarrollo en riesgo, ya que cualquier error detectado que esté relacionado con el análisis o diseño provocará un gasto enorme al tener que realizar ajustes de última hora, que podrían retrasar la entrega y mermar la calidad del producto.
Otro punto negativo es que el equipo de trabajo no podría adelantar actividades hasta que la etapa anterior inmediata haya terminado, lo que implica que habrá un tiempo de espera considerable y el cliente tiene que esperar hasta cuando el proyecto haya avanzado lo suficiente para ver el producto. Esto impide que pueda sugerir cambios que no impacten en el tiempo, costo o alcance del proyecto.
La ventaja que tiene es que cada etapa está claramente acotada y es posible determinar en qué momento termina una etapa y comienza la siguiente. En la práctica es factible realizar una revisión antes de cerrar cada etapa con la firma de los involucrados, para aumentar la certidumbre de haber trabajado conforme a los requerimientos iniciales del cliente.
Este modelo es útil en desarrollos pequeños, es decir, aquellos que no exceden los 3 meses en su implementación y en los que existe una alta estabilidad en los requerimientos.
Variantes del modelo cascada
Modelo V
El modelo V permite realizar actividades de verificación y validación del software en cada una de las etapas del modelo. Esto permite realizar acciones de aseguramiento de la calidad del software. Como se puede apreciar en la figura, su nombre proviene de la figura que se forma, por una parte (lado izquierdo) se avanza en el desarrollo del sistema y una vez completado el código se va comprobando cada etapa (lado derecho).
Ciclo de vida de desarrollo de un sistema
Al modelo cascada también se le conoce como “Ciclo de vida del desarrollo del sistema”. El ciclo se completa cada vez que se realizan adecuaciones al sistema. Como puedes observar, en la versión propuesta por ISACA (2008) el ciclo inicia con un estudio de factibilidad que deberá realizarse cada vez que se necesite realizar un cambio en el sistema. Después de la definición de requerimientos se puede decidir realizar el sistema de manera interna o adquirir el software. En la primera se realiza el diseño y desarrollo, mientras que en la adquisición se selecciona la mejor alternativa del mercado y se configura.
En la etapa de Implementación se realizan actividades de despliegue explicadas anteriormente.
En la post-implementación se realizan actividades de validación del software con el cliente y se responden a las preguntas como las siguientes: ¿Se cumplieron los objetivos y metas planteadas por el estudio de factibilidad (económica, operativa y técnica)? ¿El cliente se encuentra satisfecho con el producto entregado? ¿El sistema cubrió con las expectativas acordadas en la definición de requerimientos?
Finalmente, en la etapa de eliminación se realizan actividades de desactivación de sistemas antiguos que han sido reemplazados por el nuevo desarrollo, almacenamiento de datos para consulta y administración de accesos a datos históricos.
2.2 Modelo incremental
En ocasiones los clientes no desean esperar a tener todas las funciones del software implementadas, sino que prefieren tener en sus manos un sistema limitado en sus funciones, mientras el equipo de software construye las funcionalidades de forma completa. Cada entrega se dice que es un incremento a la versión.
En opinión de Pressman (2010), “el modelo incremental aplica secuencias lineales en forma escalonada a medida que avanza el calendario de actividades”. Como puedes observar en la siguiente gráfica, en el calendario del proyecto aparecen diferentes incrementos que producen una entrega independiente. En cada incremento se realizan las actividades del proceso de software de forma lineal y paralelamente se inicia la actividad “comunicación” del siguiente incremento, lo que permite aprovechar mejor los recursos, al mismo tiempo que aumentan las funcionalidades y las actividades que realiza el software.
Modelo incremental
Fuente: Pressman, R. (2010). Ingeniería de Software. Un enfoque práctico (7ª ed.). México: McGraw Hill.
Una particularidad de este modelo es que el primer incremento se llama producto fundamental e incluye los requerimientos básicos del sistema. Por ejemplo, si el cliente desea un sistema de administración de reservaciones de hotel, el producto fundamental tendrá el módulo de búsqueda de disponibilidad por fechas y reservación de un tipo de cuarto. Los siguientes incrementos podrían incluir el uso de promociones, acceso a tarifas que incluyan transportación, reservación de salas de conferencias, entre otras.
Esta primera entrega es inicialmente determinada por el cliente al decidir qué debe contener, ya sea por la prioridad que le esté asignando en relación a su negocio o a lo que desea. Las funciones que no sean prioritarias se podrán dejar para incrementos posteriores.
La ventaja de este modelo es que el cliente puede utilizar un producto con funciones básicas, además tiene la oportunidad de evaluarlo y solicitar modificaciones en el siguiente incremento, o bien solicitar funcionalidades que no había considerado en un principio, lo que lo hace flexible en comparación al modelo cascada.
Otra ventaja de este modelo radica en el uso eficiente de los recursos humanos que participan en el desarrollo. El primer incremento puede ser desarrollado por un equipo reducido de ingenieros de software. Si el cliente se encuentra satisfecho con el producto fundamental, se pueden agregar más recursos, a la vez que es posible llevar actividades en paralelo, lo que hace que se aproveche mejor el tiempo al eliminar tiempos de espera.
En opinión de Sommerville (2011) el modelo incremental tiene un lado negativo. Es difícil dimensionar la cantidad de recursos que se requerirán al inicio del proyecto dado que no se sabe con exactitud la cantidad de incrementos o su complejidad. Esto dificulta el estudio de factibilidad del proyecto completo.
Otra desventaja es que no son útiles cuando se trata de desarrollos que reemplazarán un sistema existente, ya que los usuarios no están dispuestos a cambiar de sistema a menos que el nuevo tenga todas las funcionalidades del anterior.
2.3 Modelo de proceso evolutivo
Los productos de software por naturaleza se mantienen en constante cambio, ya sea por que necesitan adaptarse a nuevos requerimientos del cliente, por cambios en la legislación vigente o bien por cambios en el uso de las tecnologías de información.
Piensa por ejemplo en sistemas destinados a llevar a cabo la contabilidad de las empresas mexicanas. Por obligación tributaria estas empresas deben generar facturas electrónicas, lo que implica realizar algunos cambios para cumplir con ese requisito. Otro ejemplo de la necesidad del cambio lo constituyen las tecnologías móviles, particularmente los teléfonos inteligentes. Los clientes ahora desean acceder a sus datos desde cualquier lugar y en cualquier momento. Esto ha provocado que el diseño del software evolucione para cubrir con esas necesidades.
Prototipos
Un prototipo es utilizado en varias industrias con el fin de reconocer las características de un producto antes de iniciar su fabricación. Contar con un diseño rápido a menor escala permite ahorrar dinero y tiempo en tomar decisiones importantes, que tienen que ver con su forma física y su funcionalidad.
En ingeniería de software los prototipos son muy útiles, ya que permiten darle una idea al cliente de cómo se vería el sistema y cómo funcionaría. El equipo desarrollador puede generarlo rápidamente sin mucho esfuerzo y el cliente puede dar su opinión directa sobre detalles del look & feel del sistema.
Al realizar prototipos es indispensable hacerle ver al cliente que no es un producto en sí, sino una simulación de cómo se podría ver y usar el software por construir. Es importante hacer esta aclaración, ya que enseñarle algo al cliente le hace pensar que ya se está trabajando en el desarrollo y que será muy rápida la entrega del producto final, lo que eleva mucho sus expectativas.
Pressman (2010) propone el siguiente modelo utilizando lo que él llama el “paradigma de hacer prototipos”, para aprovechar las ventajas que ofrecen los prototipos en la validación de requerimientos desde antes de iniciar la construcción del sistema. Pressman propone las siguientes actividades en este modelo:
Haz clic en cada actividad para revisar en qué consiste
El paradigma de hacer prototipos
Fuente: Pressman, R. (2010). Ingeniería de Software. Un enfoque práctico (7a ed.) México: McGraw Hill. Figura 2.6
Modelo espiral
Este modelo de desarrollo de software permite construir versiones con mayor complejidad con cada una de las iteraciones, adaptándose así a nuevas necesidades del cliente con forme avanza. Es un modelo cíclico que requiere un análisis de riesgo por cada iteración, a la vez que se realizan las actividades de desarrollo del software. Como puedes observar en la figura, este modelo está dividido en 4 sectores.
Según Pressman (2010) las desventajas de este modelo es que suele ser difícil convencer a los clientes de que este enfoque es controlable. Además se requiere de mucha experiencia para determinar los riesgos de cada iteración.
Modelo espiral de Boehm’s
Fuente: Sommerville, I. (2011). Ingeniería de Software (9ª ed.). México: Pearson.
Figura 2.11
