Implementacion y prueba de unidades. Figura 2.1. El ciclo de vida del software. 1

Transcripción

1 2.1 Introducción al análisis de sistemas Ciclo de vida del desarrollo de sistemas La concepción de sistemas viene de las ciencias naturales al tratar de analizar un ser vivo a través del estudio de cada una de sus partes y sus relaciones. Como tal, cualquier ser vivo tiene un ciclo de vida (nace, crece, se reproduce y muere). De igual manera, los sistemas de información tienen su propio ciclo: análisis, diseño, implementación, pruebas, implantación y mantenimiento. De acuerdo con Ian Somerville, estas etapas o fases pueden ser más o menos las mismas, integrarse en una o cambiar de nombre, pero en esencia son lo mismo. En la siguiente figura observamos gráficamente esta propuesta. Definicion de requerimientos Diseño de sistemas y de software Implementacion y prueba de unidades Integración y prueba del sistema Operación y mantenimiento Figura 2.1. El ciclo de vida del software. 1 Es necesario recalcar que el ciclo de vida de sistemas es un modelo teórico que tiene como propósito agrupar las actividades en fases, que se tienen que realizar para construir un sistema. Por otro lado, el modelo del ciclo de vida de sistemas no indica la forma o secuencia en que se tienen que aplicar las fases. 1 Somerville Ian, Ingeniería de Software,. 6 a Ed. (2000) Addison Wesley p. 45.

2 Análisis Esta fase contesta a la pregunta qué?, en otras palabras es una descripción de las causas de las necesidades y/o problemas. Además, se observa y modela cómo está funcionando la organización y/o sistema actual. Otro nombre que recibe esta fase es el de requerimientos. Diseño Esta fase contesta a la pregunta cómo voy a dar solución a las necesidades y/o problemas?. No hay que confundirlo con el cómo de la fase de análisis donde se investiga cómo se hacen las cosas. Implementación Esta fase se encarga de construir los componentes de software que le darán funcionalidad al sistema. Otros nombres que recibe esta fase son: desarrollo, programación o construcción. Pruebas Esta fase se encarga de asegurar que la calidad del software sea la correcta. Por un lado, se verifica que el software se construya de manera correcta, es decir, se apegue a los estándares establecidos, por otro lado, se valida que el software que se construya sea el correcto, es decir, satisfaga las necesidades para lo cual se concibió el sistema. Otros nombres que recibe esta fase son: verificación y/o validación, evaluación. Implantación Esta fase se encarga de poner en marcha el software construido y capacitar a las personas involucradas para su uso. Otro nombre que recibe esta fase es el de despliegue. Mantenimiento Esta fase se encarga de darle mantenimiento al sistema en caso de que surja una falla no detectada en la fase de pruebas, se requiera extender, adecuar o mejorar el sistema.

3 2.1.2 Modelo de cascada Descripción Aplicación Ventajas Desventajas Las fases se aplican de manera secuencial donde no se puede avanzar a la siguiente fase hasta haber terminado la anterior. Cuando la complejidad de los sistemas es baja. Adecu ado para sistemas pequeños y de complejidad baja. Cuadro 2.1. Características del modelo en Cascada Si se comete un error en alguna fase repercute en las fases subsecuentes, pero no se descubre sino hasta que se tiene el sistema. El sistema sólo se ve funcionando hasta el final por lo que el usuario se desespera por no ver resultados. Las personas responsables de las fases subsecuentes no pueden empezar hasta que terminen las personas de la fase antecedente Modelo en espiral Descripción Aplicación Ventajas Desventajas Creado por Bohem en los años 80, integra el modelo de prototipos y el modelo en cascada. Dirige su aplicación mitigando los riesgos técnicos con mayor probabilidad e impacto. Se aplica una serie de ciclos en cascada en espiral, de ahí viene su nombre. Al finalizar cada ciclo o un poco antes, se realiza la planeación del siguiente ciclo. Cuando la complejidad de los sistemas es muy alta. Se ajusta el plan de trabajo de cada ciclo, por lo que siempre está actualizado. Se afrontan los riesgos más peligrosos desde un principio por lo que si uno no se puede resolver se minimizan las pérdidas económicas. Se requiere de personas que puedan detectar los riesgos y generar los planes de contingencia y/o contención, lo cual implica una gran experiencia y conocimiento por lo que se ve reflejado en los costos. Cuadro 2.2. Características del modelo en espiral

4 2.1.4 Marco de Trabajo Iterativo Incremental (Iterative Incremental Framework) El modelo en espiral es una evolución del modelo en cascada, y, a su vez, el modelo incremental es una evolución del modelo en espiral. Este marco está compuesto de cuatro grandes fases: concepción, elaboración, construcción y transición. Concepción.- En esta fase se establece la visión y metas del proyecto. Se exponen las ideas de lo que debe hacer el sistema, pero eso no significa que se vayan a desarrollar todas. Estas ideas se tienen que evaluar en cuanto a su factibilidad operativa, técnica y económica. Elaboración.- El propósito de esta fase es profundizar en el proyecto, analizar el problema, desarrollar el plan del proyecto y eliminar los riesgos en el proyecto. Al final de esta fase, los analistas y diseñadores deben tener un buen entendimiento del proyecto, pero no muy detallado. Y se debe tener la definición de la arquitectura del sistema. En las dos fases anteriores se establece el análisis y diseño que sustenta la programación como tal, con la ayuda de prototipos se establece si el análisis y diseño es correcto. Construcción.- En la fase de construcción se inicia la programación, pero con la ventaja de que previamente ya se probó la arquitectura del sistema por lo que ya no se está adivinando en donde se tienen que colocar los archivos ejecutables o cómo se tienen que nombrar las tablas de la base de datos. Transición.- Esta fase consiste en entregar el sistema, agregándole nuevas características, haciendo optimizaciones, reparando errores, etc. También incluye la escritura final del manual de usuario.

5 Marco de Trabajo Iterativo fases Concepción Elaboración Construcción Transición forma la genera la permite la entrega el Visión del sistema Arquitectura del sistema Los ejecutables del sistema Sistema Figura 2.2 Fases del Marco de trabajo Iterativo El Proceso Unificado Racional (RUP) RUP (Rational Unified Process) es un proceso de Ingeniería de Software. Éste provee un enfoque disciplinado para asignar tareas y responsabilidades al equipo de trabajo que desarrolla software. Esta meta es para asegurar la producción de un software con alta calidad que satisfaga las necesidades de los usuarios finales, con un tiempo predecible y dentro del presupuesto. RUP mejora la productividad del equipo, provee a cada miembro del equipo con un fácil acceso a la base de conocimiento con líneas guía, templates y herramientas para las actividades críticas de desarrollo. Las actividades de RUP crean y mantienen modelos. Este proceso enfatiza el desarrollo y mantenimiento de modelos (un modelo es una representación semántica del sistema que se está desarrollando).

6 RUP es una guía para usar efectivamente el Lenguaje Unificado de Modelado (UML Unified Modeling Language). UML es un lenguaje estándar de la industria que permite clarificar la comunicación de los requerimientos, arquitectura y diseño. En el subtema 2.2. Vamos a analizar como mayor detalle el UML. El RUP es un proceso configurable. No hay proceso único que se pueda aplicar a todos los desarrollos de software de manera transparente. El Proceso Unificado se adapta tanto a equipos de desarrollo pequeños como a grandes organizaciones. RUP describe cómo desarrollar las mejores estrategias de desarrollo de software. Éstas son llamadas buenas prácticas; no reciben este nombre por el valor que proporcionan al desarrollo de software, sino porque son las prácticas que se utilizan ampliamente en la industria de software con resultados exitosos. El proceso puede ser descrito a lo largo de dos ejes: El eje horizontal representa el tiempo y muestra el aspecto dinámico del proceso, y se expresa en términos de ciclos, fases, iteraciones e hitos. El eje vertical representa el aspecto estático del proceso, y se expresa en términos de actividades, artefactos, trabajadores y flujos de trabajo.

7 En el siguiente cuadro se esquematizan las dos dimensiones y las buenas prácticas: Modelo de Negocio Requerimientos Análisis y Diseño Implementación Pruebas Implantación Administración de Proyectos Administración de Cambios y de Configuración Ambiente Concepción Elaboración Construcción Transición Buenas prácticas 1. Desarrollo de software iterativo. 2. Administración de requerimientos. 3. Arquitectura basada en componentes. 4. Modelado visual de software. 5. Verificación de la calidad de software. 6. Control de cambios al software. Cuadro 2.3. Los dos ejes de RUP y las buenas prácticas