|
Ciclos de vida para el desarrollo de sistemas La producción del software es algo más que la programación; hay etapas que la preceden y otras que le siguen. El ciclo de vida del software está constituido por un conjunto de etapas. Los método y técnicas de la ingeniería de software se inscriben dentro del marco delimitado por el ciclo de vida del software y más concretamente , por las diferentes etapas que se distinguen. La misma existencia de distintos modelos de ciclo de vida del software hace comprender que no hay ninguno que se ideal o que no tenga grandes limitaciones. Modelo de la cascada Hay veces en las que los requrimientos para cierto problema se comprende bien: cuando el trabajo desde la comunicación hasta el despliegue fluye en forma razonablemente lineal. Esta situación se encuentra en ocasiones cuando deben hacerse adaptaciones o mejoras bien definidas a un sistema ya existente (por ejemplo: una adaptación para software de contabilidad que es obligatorio hacer debido a cambios en las regulaciones gubernamentales). También ocurre en cierto número limitado de nuevos esfuerzos de desarrollo, pero sólo cuando los requerimientos están bien definidos y tienen una estabilidad razonable. El modelo de cascada, a veces llamado ciclo de vida clásico, sugiere un enfoque sistemático y secuencial para el desarrollo del software, que comienza con la especificación de los requerimientos por parte del cliente y avanza a través de planeación, modelado, construcción y despliegue, para concluir con el apoyo del software terminado. Una variante de la representación del modelo de la cascada se denomina modelo en V. A medida que el equipo de software avanza hacia abajo desde el lado izquierdo de la V, los requerimientos básicos del problema mejoran hacia representaciones técnicas cada vez más detalladas del problema y de su solución. Una vez que se ha generado el código, el equipo sube por el lado derecho de la V, y en esencia ejecuta una serie de pruebas que validan cada uno de los modelos creados cuando el equipo fue hacia abajo por el lado izquierdo. Este último proporciona una forma de visualizar del modo de aplicación de las acciones de verificación y validación al trabajo de ingeniería inicial. El modelo de cascada es el paradigma más antigüo de la ingeniería de software. Sin embargo, en las última décadas, las críticas hechas al modelo han ocasionado que incluso sus defensores más obstinados cuestionen su eficacia. Dentro los problemas que en ocasiones surgen al aplicar el modelo de cascada se encuentran los siguientes:
Modelo lineal secuencial El modelo lineal secuencial sugiere un enfoque sistemático secuencial, para el desarollo del software que comienza en un nivel de sistemas y progresa con el análisis, diseño, codificación, pruebas y mantenimiento.
Modelo de proceso incremental El modelo incremental combina los elementos de los flujos de proceso lineal y paralelo. El modelo incremental aplica secuencias lineales en forma escalonada a medida que avanza el calendario de actividades. Cada secuencia lineal produce "incrementos" de software suceptibles de entregarse de manera parecida a los incrementos producidos en un flujo de proceso evolutivo. Cuando se utiliza el modelo incremental, es frecuente que el primer programa sea el producto fundamental. Es decir, se abordan los requerimientos básico, pero no se porporcionan muchas características suplementarias. El cliente usa el producto fundamental (o lo somete a una evaluación detallada). como resultado del uso y/o evaluación, se desarrolla un plan para el incremento que sigue. el plan incluye la modifcación del producto fundamental para cumplir mejor las necesidades del cliente, así como la entrega de características adicionales y más funcionalidad. Este proceso se repite después de entregar cada incremento, hasta termiar el producto final. El modelo de proceso incremental se centra en que en cada incremento se entrega un producto que ya opera. Los primeros incrementos son versiones desnudas del producto final, pero porporcionan capacidad que sirve al usuario y también le dan una plataforma de evaluación.
Modelo de proceso evolutivo Los modelos evolutivos son iterativos. Se caracterizan por la manera en la que permiten desarrollar versiones cada vez más completas del software. Prototipos El paradigma de hacer prototipos comienza con comunicación. Usted se reúne con otros participantes para definir los objetivos generales del software. Identifica cualesquiera requerimientos que conozca y detecta las áreas en las que es imprescendible una mayor definición. Se planea rápidamente una iteración para hacer el prototipo, y se lleva a cabo el modelado. Éste se centra en la represetación de aquellos aspectos del software que serán visibles para los usuarios finales. El diseño rápido lleva a la construcción de un prototipo. Éste se entregar y es evaluado por los participantes, que dan retroalimentación para mejorar los requerimientos. La iteración ocurre a medida, y al mismo tiempo permite a usted entender mejor lo que se necesita hacer. El ideal es que el prototipo sirva como mecanismo para identficar los requerimientos del software. Si va a construirse un prototipo, pueden utilizarse fragmentos de programas existentes o aplicar herramientas (por ejemplo, generadores de reportes y administradores de ventas) que permitan generar rápidamente programas que funcionen. Tanto a los participante como a los desarrolladores de softwar les gusta el paradignam de hacer portotipos. Los usuarios adquieren sensación del sistema real, y los desarrolladores logran construir algo de inmediato.
Modelo espiral El modelo de desarrollo espiral es un generador de modelo de proceso impulsado por el riesgo, que se usa para guiar la ingeniería concurrente con participantes multiples de sistemas intensivos en software. Tiene dos caracteristicas que los distinguen entre los demas:
Un modelo espiral es dividido por el equipo de software en un conjunto de actividades estructurales. Para fines ilustrativos, se utilizan las actividades estructurales ya analizadas. Cada una de ellas representa un segmento de la trayectoria espiral. Al comenzar el proceso evolutivo, el equipo de software realiza actividades implícitas en un circuito alrededor de la espiral en el sentido horario, partiendo del centro. El riesgo se considera conforme se desarrolla cada revolución. En cada paso evolutivo se marcan puntos de referencia puntuales: combinación de productos del trabajo y condiciones que se encuentran a lo largo de la trayectoria de la espiral. El primer circuito alrededor de la espiral da como resultado el desarrollo de una especifiación del producto; las vueltas sucesivas se usan para desarrollar un prototipo y, luego, versiones cada vez más sofisticadas del software. Cada paso paso por la región de planeación da como resultado ajustes en el plan del proyecto. El costo y la programación de actividades se ajustan con base en la retroalimentación obtenida del cliente después de la entrega. Además, el gerente del proyecto ajusta el número planeado de iteraciones que se requieren para terminar el software. Modelos concurrentes El modelo de desarrollo concurrente, en ocasiones llamado ingenría concurrente, permite que un equipo de sofware represente elementos iterativos y concurrentes. La actividad -modelado- puede estar en cualquiera de los estados mencionados en un momento dado. En forma similar, es posible representar de manera análoga otras actividades, acciones o tareas (por ejemplo, comunicación o construcción). Todas las acividades de ingeniría de software existen de manera concurrente, pero se hallan en diferentes estados. La actividad de comunicación termina su primera iteración al principio de un proyecto y existe en el estado de cambios de espera. La actividad de modelado, ahora hace una transición al estado en desarrollo, la actividad de modelado pasa del estado en desarrollo al de cambios de espera.
Modelos de desarrollo basado en componentes El modelo de desarrollo basado en componentes incorpora muchas de las características del modelo espiral. Es de naturaleza evolutivo y demanda un enfoque iterativo para la creación de software. Sin embargo, el modelo de desarrollo basado en componenetes construye aplicaciones a partir de fragmentos de software prefabricados. Sin importar la tecnología usada para crear los componentes, el modelo de desarrollo basado en componenetes incorpora las etapas siguientes:
El modelo del desarrollo basado en componentes lleva a la reutilización del software, y eso da a los ingenieros de software varios beneficios en cuanto a la mensurabilidad. |
