CAPÍTULO 3. Modelos Prescriptivos del desarrollo de Sistemas de Información

CAPÍTULO 3. Modelos Prescriptivos del desarrollo de Sistemas de InformaciónPara comenzar veamos lo que ya sabeRecuperación de información inicial

Defina que es un modelo de desarrolloConoce algún modelo de desarrolloDescriba el modelo de desarrollo que conoceImportancia del uso de un modelo de desarrollo en la empresa

Todo esfuerzo en el desarrollo del software conlleva un “ciclo de vida” que consiste en realizar todas las actividades comprendidas entre el momento en el que se inicia la versión 1.0 de un sistema como una chispa en la imaginación de alguien y el momento en el que la versión 6.74b exhala su último aliento en la máquina del último cliente. Un modelo de ciclo de vida es un modelo prescriptivo de lo que pasaría entre la primera chispa y el último aliento.

Modelo en Cascada.El predecesor de todos los modelos de ciclo de vida es el Modelo en Cascada. Aunque presenta muchos problemas, sirve de base para otros modelos de ciclo de vida más efectivos.

En un Modelo en Cascada, un proyecto progresa a través de una secuencia ordenada de pasos partiendo del concepto inicial del software hasta la prueba del sistema. Ver Figura 1

Figura 1. El Modelo en Cascada

Concepto de

software

Análisis de

requeriientos

Diseño global

Diseño detallado

Codificación y

depuración

Prueba del

sistema

En este modelo se describen las siguientes etapas: Concepto del software Análisis de requerimientos Diseño global Diseño detallado Codificación y depuración Prueba del sistema.

El proyecto realiza una revisión al final de cada etapa para determinar si está preparado para pasar a la siguiente. Cuando la revisión determinaque el proyecto no está listo para pasar a la siguiente etapa, permanece en la etapa actual hasta que esté preparado. (McConnell, 1997)

El Modelo en Cascada está dirigido por documentos, es decir, los productos principales del trabajo que se pasan de una etapa a la siguiente son documentos. En este modelo las etapas también son discontinuas, esto es, que no se traslapan entre sí y no inicia una hastaque la anterior ha terminado.

El Modelo en Cascada pura se utiliza correctamente para ciclos de proyectos en los que se tiene una definición estable del producto y también cuando se está trabajando con metodologías técnicas conocidas. Enestos casos, el Modelo en Cascada ayuda a localizar errores en las primeras etapas del proyecto a un bajo coste.

El Modelo de Cascada pura ayuda a minimizar los gastos de la planificación porque permite realizarla sin problemas. No proporciona resultados tangibles en forma de software hasta el final del ciclo de vida, pero, para alguien familiarizado con el modelo, la documentación que genera proporciona indicaciones significativas del progreso a lo largo del ciclo de vida.

El Modelo en Cascada funciona bien con proyectos complejos que se entienden correctamente, debido a que se pueden obtener beneficios al enfrentarse a la complejidad de forma ordenada. Funciona correctamente cuando los requerimientos de calidad dominan sobre los requerimientos de costes y de planificación. El modelo evita una fuente común de errores importantes, eliminando los cambios que se pueden producir a medio camino.

Las desventajas del Modelo en Cascada pura se centran en la dificultad para especificar claramente los requerimientos al comienzo del proyecto,

antes de que se realice ningún trabajo de diseño y antes de escribir ningún código.

El principal problema del Modelo en Cascada es no permitir flexibilidad en los cambios. Se tienen que especificar completamente todos los requerimientos al comienzo del proyecto, lo que puede suponer meses o incluso años antes de tener el software funcionando.

Generalmente se considera que este modelo no permite el volver atrás paracorregir los errores. Esto no es completamente cierto, puede hacerse, pero es muy difícil y puede ponerse en riesgo el éxito del proyecto completo. Si se descubre un fallo en la arquitectura durante la codificación y la depuración, es muy difícil nadar contra corriente y rehacer la arquitectura y si logra hacerse, tendrá que volverse a pasar por todas las etapas intermedias y rehacer ese trabajo, con las consiguientes complicaciones en la duración y coste del proyecto.

Para un proyecto de desarrollo rápido, el Modelo en Cascada puede suponeruna cantidad excesiva de documentación. Si se intenta mantener la flexibilidad, la actualización de la especificación se puede convertir enun trabajo a tiempo completo. El Modelo en Cascada genera pocos signos visibles de progreso hasta el final. Esto puede dar la impresión de un desarrollo lento, incluso sin ser verdad.

En resumen, los inconvenientes del venerado Modelo en Cascada hacen que sea, a menudo, un modelo poco apropiado para un proyecto de desarrollo rápido. Incluso en los casos en los que las ventajas del Modelo en Cascada pura superan los inconvenientes, los Modelos de Cascada modificada pueden funcionar mejor. (McConnell, 1997)

Modelos EvolutivosLos Modelos Evolutivos son aquellos que tratan el desarrollo del proyectocomo una secuencia de etapas en las que no existe una frontera claramentedefinida entre ellas y donde en un punto determinado en el tiempo, no puede definirse claramente si se encuentra en una etapa o en otra. (McConnell, 1997)

Característica de estos modelos es el que pueden contener ciclos o repeticiones de etapas en las que se entra en múltiples ocasiones, ya seapara refinar el proyecto o incrementar la cantidad de funciones del mismoo en el caso de las etapas iniciales, el detallar los requerimientos del mismo.

El más sofisticado de los Modelos Evolutivos es El Modelo en Espiral. Este modelo es un modelo de ciclo de vida orientado a riesgos que divide un proyecto de software en miniproyectos. Cada miniproyecto se centra en uno o más riesgos importantes hasta que todos estos estén controlados. Elconcepto “riesgo” se define ampliamente en este contexto y puede referirse a requerimientos poco comprensibles, arquitecturas poco conocidas, problemas de ejecución importantes, problemas con la tecnología subyacente y demás. (McConnell, 1997). Ver Figura 2

Figura 2. El Modelo en Espiral

Después de controlar todos los riesgos más importantes, El Modelo en Espiral finaliza del mismo modo que el Modelo de Ciclo de Vida en Cascada.

En este modelo se inicia con un conjunto de requerimientos pequeños y se va ampliando el alcance del sistema de manera cíclica repetitiva y pasando en cada iteración por las siguientes etapas:

1. Determinar objetivos, alternativas y límites.2. Identificar y resolver los riesgos.3. Evaluar las alternativas.4. Generar las entregas de esta iteración y comprobar que son

correctas.

5. Planificar la siguiente iteración.6. Establecer un enfoque para la siguiente iteración (si es que se

decide ejecutarla).En este Modelo en Espiral, las primeras iteraciones son las menos costas.Supone menos gasto desarrollar el concepto de operación que realizar el desarrollo de los requerimientos, y también es menos costos desarrollar los requerimientos que llevar a cabo el desarrollo del diseño., la implementación del producto y la prueba del mismo.

El modelo se puede combinar con otros modelos de ciclo de vida de dos formas distintas. Se puede comenzar con un proyecto con una serie de iteraciones para reducir los riesgos; después de que se hayan reducido los riesgos a un nivel aceptable, se puede finalizar el esfuerzo de desarrollo con un Ciclo de Vida en Cascada y otro modelo de ciclo de vidano basado en riesgos.

También es aceptable el incorporar otros modelos de ciclo de vida como iteraciones dentro del Modelo en Espiral. Por ejemplo, si uno de los riesgos consiste en que no se tiene seguridad de alcanzar los objetivos de rendimiento, puede incluir una iteración de prototipado para investigar si es posible la consecución de estos objetivos.

Una de las ventajas más importantes del Modelo en Espiral es que mientraslos costes suben, los riesgos disminuyen.

La única desventaja del Modelo en Espiral es que se trata de un modelo complicado. Requiere de una gestión concienzuda, atenta y que exige conocimientos profundos. Por otro lado, en algunos casos, el desarrollo del producto es suficientemente lineal y los riesgos del proyecto son tanpocos que no se necesita la flexibilidad y la gestión de riesgos que ofrece El Modelo en Espiral.

Otro modelo característico de los evolutivos es el modelo de entrega evolutiva. Este modelo se encuentra entre el Prototipado Evolutivo y la entrega por etapas. Se desarrolla una versión del producto, se muestra alcliente, y se refina el producto en función de la realimentación del cliente. El parecido entre la entrega evolutiva y el Prototipado Evolutivo depende realmente de hasta qué punto se lleva a cabo una planificación para adaptarse a las solicitudes de los clientes. Si se planifica para adaptarse a la mayoría de las solicitudes, la entrega evolutiva se parecerá más al Prototipado Evolutivo. Si se planifica para

adaptarse a pocas solicitudes de modificación, la entrega evolutiva se aproximará a la entrega por etapas. (McConnell, 1997)

En la entrega evolutiva, el énfasis inicial se pone en el núcleo del sistema, que está constituido por funciones de bajo nivel que probablemente no van a ser modificadas por la realimentación del cliente

El Prototipado Evolutivo es un modelo de ciclo de vida en el que se desarrolla el concepto del sistema a medida que avanza el proyecto. Normalmente se comienza desarrollando los aspectos más visible del sistema. Puede presentar la parte del sistema al cliente y entonces continuar el desarrollo del prototipo basándose en la realimentación que recibe. Ver Figura 3

Figura 3. Modelo de Prototipado Evolutivo

El Prototipado Evolutivo se utiliza especialmente cuando los requerimientos cambian con rapidez, cuando el cliente es reacio a especificar el conjunto de los requerimientos, o cuando ni el analista niel cliente identifican de forma apropiada el área de aplicación. También es útil cuando los desarrolladores no están seguros de la arquitectura o los algoritmos adecuados a utilizar. Se generan signos visibles de

progreso, que se pueden utilizar especialmente cuando existe una gran demanda en la velocidad de desarrollo. (McConnell, 1997)

El principal inconveniente de este tipo de prototipado es la imposibilidad de conocer al comienzo del proyecto lo que se tardará en crear un producto aceptable. Incluso no se sabe cuántas iteraciones se tendrán que realizar. Este inconveniente aparece de algún modo por el hecho de que los clientes pueden ver signos firmes de progreso y entoncestienden a ponerse menos nerviosos con la adquisición eventual de un producto que con otras aproximaciones. También es posible utilizar el Prototipado Evolutivo dentro de la aproximación “seguiremos prototipando hasta que se acaben el tiempo y el dinero y a continuación diremos que hemos terminado correctamente”. Otro inconveniente es que esta aproximación puede convertirse fácilmente en una excusa para realizar el desarrollo con el Modelo Codificar y Corregir. Un Prototipado Evolutivo real incluye análisis de requerimientos real, diseño real y código pensado para el mantenimiento real, en niveles ligeramente inferiores de los que se utilizan con las aproximaciones tradicionales.

Modelos EspecialesCodificar y corregir. El Modelo Codificar y Corregir es un modelo poco útil, pero sin embargo bastante común. Cuando se utiliza el Modelo Codificar y Corregir, se empieza con una idea general de lo que se necesita construir. Se puede tener una especificación formal, o no tenerla. Entonces, se utiliza cualquier combinación de diseño, código, depuración y métodos de prueba no formales que sirven hasta que se tiene el producto listo para entregarlo. El Modelo Codificar y Corregir tiene dos ventajas. En primer lugar, no conlleva ninguna gestión; no se pierde tiempo en la planificación, en la documentación, el control de calidad, en el cumplimiento de los estándares, o en cualquier otra actividad que no sea la codificación pura. Como se pasa directamente a codificar, se pueden mostrar inmediatamente indicios de progreso. En segundo lugar, requiere poca experiencia: cualquier persona que haya escrito alguna vez un programa de computadora está familiarizada con el Modelo Codificar y Corregir. Cualquiera puede utilizarlo. (McConnell, 1997)

Este modelo resulta peligroso para otro tipo de proyectos que no sean pequeños. Puede que no suponga gestión alguna, pero tampoco ofrece mediosde evaluación del progreso; se codifica justo hasta que se termina. No

proporciona medios de evaluación de la calidad o de identificación de riesgos. Si al llevar tres cuartas partes de la codificación descubre queel diseño es incorrecto, no hay otra solución que desechar el trabajo y comenzar de nuevo. Otros modelos le permitirán detectar un error tan fundamental mucho antes, cuando hubiera sido menos costoso solucionarlo.

Cascadas Modificadas. Las actividades que se identifican en el Modelo de Cascada Pura son intrínsecas del desarrollo de software y esto no se puede evitar, no se pueden suprimir actividades ni se pueden ordenar en forma diferente. La mayoría de los inconvenientes del Modelo de Cascada Pura surgen no en los problemas que se plantean con estas actividades si no en el tratamiento de estas actividades como etapas secuenciales disjuntas. Puede por lo tanto corregirse los inconvenientes más importantes en el Modelo de Cascada Pura con modificaciones relativamentepequeñas. Puede modificarse de tal forma que las etapas se traslapen entre sí, puede reducirse el énfasis en la documentación o puede permitirse una mayor regresión. (McConnell, 1997)

El Modelo de Cascada Modificada que permite un solapamiento o traslape entre las actividades consecutivas se conoce como Sashimi o cascada con fases solapadas. Recibe este curioso nombre japonés por la costumbre que existe en aquel país, de presentar las rebanadas de pescado con un ligerotraslape entre ellas. El Modelo en Cascada tradicional permite un solapamiento mínimo entre las etapas en la revisión final de cada etapa. En este modelo se sugiere un grado mayor de solapamiento, por ejemplo, sesugiere que se debería tener bien hecho el diseño global y quizás a mediohacer el diseño detallado antes de considerar completo el análisis de requerimientos.

Este modelo también plantea a su vez algunos problemas. Debido al solapamiento entre las etapas, los hitos son más ambiguos, y esto hace más difícil trazar el progreso correctamente. La realización de actividades en paralelo puede suponer una mala comunicación, suposicionesincorrectas e ineficacia. Si se está trabajando en un proyecto pequeño y bien definido, algo más cercano al Modelo de Cascada pura puede ser el mejor modelo disponible.

El Modelo de Cascada Pura plantea el problema de que debe de terminarse con cualquiera de las etapas de manera completa antes de poder pasar a lasiguiente. Esto provoca que en el caso de que se esté elaborando un proyecto con secciones que ya han sido anteriormente elaboradas (en

proyectos anteriores) y que son bien conocidas y están adecuadamente analizadas y definidas, se retrase la codificación y desarrollo de estas por estar esperando a completar al análisis y diseño de las otras. Para evitar esto, si la arquitectura del proyecto ha dividido el sistema en subsistemas lógicamente independientes, puede dividirse en proyectos separados, cada uno de los cuales puede proseguir a su propio ritmo sin tener que esperar que se completen las etapas de las otras secciones del proyecto. Este Modelo de Cascada con Subproyectos tiene a su vez un riesgo principal que es la presencia de interdependencias imprevistas. Sepueden tener parcialmente en cuenta eliminando dependencias durante el desarrollo de la arquitectura, o esperar hasta después del diseño detallado para dividir el proyecto en subproyectos. (McConnell, 1997)

Cascada con Reducción de Riesgos. Otro de los inconvenientes del Modelo en Cascada es que requiere la definición completa de los requerimientos antes de comenzar el diseño de la arquitectura, algo que parece razonableexcepto porque también requiere comprender totalmente los requerimientos antes de comenzar el diseño global, cosa que en la realidad es muy raro que suceda. Modificando la cascada muy poco, puede colocarse una espiral de actividades para reducir el riesgo en lo alto de la cascada para controlar el riesgo de los requerimientos. Puede desarrollarse un prototipo de interfaz de usuario, tener entrevistas o utilizar otros métodos que se consideren apropiados para la identificación delos requerimientos.

El preámbulo de la reducción de riesgos para el Ciclo de Vida en Cascada no está limitado a los requerimientos. Podría utilizarse para reducir el riesgo de la arquitectura o cualquier otro riesgo del proyecto. Cuando elproducto depende del desarrollo de un núcleo de alto riesgo para el sistema, se debería utilizar un ciclo de reducción de riesgos para desarrollar totalmente el núcleo de alto riesgo antes de acometer un proyecto a gran escala.

El Proceso Unificado de Desarrollo de SoftwareEl Proceso Unificado de software, también es conocido como Proceso Unificado, es un marco de desarrollo de software que se caracteriza por estar dirigido por casos de uso, centrado en la arquitectura y por ser iterativo e incremental. Comercialmente a este proceso se le conoce como

Proceso Unificado de Rational o por sus siglas en ingles RUP. (McConnell, 1997)

El Primer libro sobre el tema se denominó “El Proceso Unificado de Desarrollo de Software”, publicado en 1999 por Ivar Jacobson, Grady Boochy James Rumbaugh, también conocidos por ser los desarrolladores de UML, el Lenguaje Unificado de Modelado.

Este proceso se caracteriza por ser iterativo e incremental, está compuesto de cuatro fases denominadas: Inicio, Elaboración, Construcción y Transición. Cada una de estas fases es a su vez dividida en una serie de iteraciones (la de inicio puede incluir varias iteraciones en proyectos grandes). Estas iteraciones ofrecen como resultado un incremento del producto desarrollado que añade o mejora las funcionalidades del sistema en desarrollo. (McConnell, 1997). Ver Figura 4

Figura 4. Proceso Unificado de Desarrollo de Software

Cada una de estas iteraciones se divide a su vez en una serie de disciplinas que recuerdan a las definidas en el Ciclo de Vida Clásico o en Cascada: Análisis de requisitos, Diseño, Implementación y Prueba. Aunque todas las iteraciones suelen incluir trabajo en casi todas las disciplinas, el grado de esfuerzo dentro de cada una de ellas varía a lo largo del proyecto.

En el Proceso Unificado, los casos de uso se utilizan para capturar los requisitos funcionales y para definir los contenidos de las iteraciones. La idea es que cada iteración tome un conjunto de casos de uso o escenarios y desarrolle todo el camino a través de las distintas disciplinas; diseño, implementación, prueba, etc. El proceso dirigido porcaos de uso es el RUP (Proceso Unificado de Rational).

El Proceso Unificado asume que no existe un modelo único que cubra todos los aspectos del sistema. Por este motivo existen múltiples modelos y vistas que definen la arquitectura de software de un sistema. La analogíacon la construcción es clara: Cuando construyes un edificio existen diversos planos que incluyen los distintos servicios del mismo; electricidad, fontanería, etc.

El Proceso Unificado requiere que el equipo del proyecto se centre en identificar los riesgos críticos en una etapa temprana del ciclo de vida.Los resultados de cada iteración, en especial los de la fase de Elaboración deben ser seleccionados en un orden que asegure que los riesgos principales son considerados primero. (McConnell, 1997)

Proceso Unificado de Rational (RUP)El Proceso Unificado de Rational es un proceso de desarrollo de software originado por la empresa Rational Software, actualmente propiedad de IBM.Junto con el Lenguaje Unificado de modelado (UML), constituye la metodología estándar más utilizada para el análisis, diseño, implementación y documentación de sistemas orientados a objetos.

El RUP no es un sistema con pasos firmemente establecidos, sino más bien es un conjunto de metodologías adaptables al contexto y necesidades de cada organización.

También se conoce por este nombre al software, también desarrollado por Rational, que incluye información entrelazada de diversos artefactos y descripciones de las diversas actividades. Está incluido en el Rational Method Composer, que permite la personalización de acuerdo con las necesidades.

Originalmente se diseñó un proceso genérico y de dominio público, el Proceso Unificado, y una especificación más detallada, el Rational Unified Process que se vendiera como un producto independiente.

EL RUP está basado en seis principios clave que son los siguientes:

Adaptar el proceso.- El proceso deberá adaptarse a las necesidades del cliente ya que es muy importante interactuar con él. Las características propias del proyecto y organización, el tamaño del mismo, así como su tipo o las regulaciones que lo condicionen, influirán en su diseño específico. También se deberá tener en cuenta el alcance del proyecto en un área subformal para hacer un proceso de satisfacción del software.

Equilibrar prioridades.- Los requisitos de los diversos participantes pueden ser diferentes, contradictorios o disputarse recursos limitados. Debe encontrarse un equilibrio que satisfaga los deseos de todos. Gracias a este equilibrio se podrán corregir desacuerdos que surjan en el futuro.

Demostrar valor iterativamente.- Los proyectos se entregan, aunque sea de un modo interno, en etapas iteradas. En cada iteración se analiza la opinión de los inversores, la estabilidad y calidad del producto, y se refina la dirección del proyecto así como también los riesgos involucrados.

Colaboración entre equipos.- El desarrollo de software no lo hace una única persona si no múltiples equipos. Debe haber una comunicación fluida para coordinar requisitos, desarrollo, evaluación, planes, resultados, etc.

Elevar el nivel de abstracción.- Este principio dominante motiva eluso de conceptos reutilizables tales como patrón del software, lenguajes 4GL o marcos de referencia por nombrar algunos. Esto evita que los ingenieros de software vayan directamente de los requisitos a la codificación de software a la medida del cliente, sin saber con certeza qué codificar para satisfacer de la mejor manera los requisitos y sin comenzar desde un principio pensando enla reutilización del código. Un alto nivel de abstracción también permite discusiones sobre diversos niveles y soluciones arquitectónicas. Éstas se pueden acompañar por las representacionesvisuales dela arquitectura, por ejemplo con el lenguaje UML.

Enfocarse en la calidad.- El control de calidad no debe realizarse al final de cada iteración, sin no en todos los aspectos de la producción. El aseguramiento de la calidad forma parte del proceso de desarrollo y no de un grupo independiente. (McConnell, 1997)

Ciclo de vida

El ciclo de vida RUP es una implementación del Modelo en Espiral. Fue creado ensamblando los elementos en secuencias semiordenadas. El ciclo devida organiza las tareas en fases e iteraciones.RUP divide el proceso en cuatro fases, dentro de las cuales se realizan varias iteraciones en número variable según el proyecto y en las que se hace un mayor o menor hincapié en las distintas actividades.

Las primeras iteraciones (en las fases de Inicio y Elaboración) se enfocan hacia la compresión del problema y la tecnología, la delimitacióndel ámbito del proyecto, la eliminación de los riesgos críticos y al establecimiento de una línea base de la arquitectura.

Durante la fase de inicio las iteraciones hacen mayor énfasis en actividades de modelado del negocio y de requisitos.

En la fase de elaboración, las iteraciones se orientan al desarrollo de la line base de la arquitectura, abarcan más los flujos de trabajo de requisitos, modelo de negocios (refinamiento), análisis, diseño y una parte de implementación orientado a la línea base de la arquitectura.

En la fase de construcción, se lleva a cabo la construcción del producto por medio de una serie de iteraciones.

Para cada iteración se seleccionan algunos Casos de Uso, se refinan su análisis y diseño y se procede a su implementación y pruebas. Se realiza una pequeña cascada para cada ciclo. Se realizan iteraciones hasta que setermine la implementación de la nueva versión del producto.

En la fase de transición se pretende garantizar que se tiene un producto preparado para su entrega a la comunidad de usuarios.

Como se puede observar en cada fase participan todas las disciplinas, pero dependiendo de la fase el esfuerzo dedicado a una disciplina varía.(McConnell, 1997)

Modelo de Proceso de Software IEEEEl modelo de proceso de software, se formaliza dentro de la IEEE con el estándar 1074 y sus posteriores revisiones IEEE Std 1074-1998 IEEE Standard for Developing Software Life Cycle Processes. (IEEE Computer Society, 1997). Este es un estándar para la generación del proceso que gobierna el desarrollo del software y su mantenimiento para un proyecto.

Más que un modelo de proceso en sí mismo, este estándar provee un procesopara crear un “SLCP” (Software Life Cycle Process, Proceso del ciclo de vida del software) con el que el arquitecto de procesos puede guiar su trabajo para un proyecto de software dado.

Esta metodología inicia con la selección de un modelo de ciclo de vida desoftware (SLCM, Software Life Cycle Model) apropiado para usarse en el proyecto. Continúa a través de la creación de un ciclo de vida del software (SLC, Software Life Cycle), utilizando un conjunto de actividades dado que se proveen en el mismo estándar. La metodología finaliza con el detallado del SLC con los Elementos del proceso organizacional (OPA, Organizational Process Assets) para crear el SLCP.(McConnell, 1997)

El estándar define, entre otros, una serie de conceptos, siendo los más relevantes:

Software Life Cycle (SLC) – Ciclo de vida del software: La secuencia de actividades específicas al proyecto que se crean mediante la referencia de las actividades en el estándar con el modelo de ciclo de vida del software (SLCM) seleccionado.Software Life Cycle Model (SLCM) – Modelo del ciclo de vida del software: El marco de trabajo seleccionado por cada organización que lo usa, en el que se referencian las actividades del estándar para producir el ciclo de vida del software (SLC).Software Life Cycle Process (SLCP) – Proceso del ciclo de vida del software: Es la descripción del proceso específico al proyecto que está basado en el ciclo de vida del software (SLC) y los recursos del proceso organizacional (OPA). (McConnell, 1997).

La implementación del estándar consta de los siguientes pasos:

1. Seleccionar un SLCM. Inicialmente, el arquitecto del proceso debe identificar el SLCM a las que las actividades tienen que referenciarse. Este paso comprende ubicar, evaluar, seleccionar y adquirir un SLCM. Es posible que una organización tenga varios SLCM, sin embargo, solo un modelo se seleccione para un proyecto.

2. Crear un SLC. Las actividades que se mencionan en el estándar, deben de referenciarse dentro del SLCM.

a. Colocar las actividades en una secuencia ejecutable.b. Desarrollar y justificar una lista de actividades que no se

usarán.

c. Verificar el mapeo.3. Establecer el SLCP. Los pasos anteriores constituyen el SLC. Como

paso siguiente, las OPA disponibles deben aplicarse a las actividades del SLC, y las restricciones o colisiones deben de resolverse. (McConnell, 1997)

El estándar a continuación describe una larga lista de actividades que son las que deben de integrarse en el SLC según lo que se haya seleccionado y que se agrupan de la siguiente manera:

Actividades de administración del proyectoo Actividades de iniciación del proyecto.o Actividades de planeación del proyecto.o Actividades de monitoreo y control del proyecto.

Actividades previas al desarrolloo Actividades de exploración de concepto.o Actividades de ubicación del sistema.o Actividades de importación de Software.

Actividades de desarrolloo Actividades de requerimientos.o Actividades de diseño.o Actividades de implementación.

Actividades post-desarrolloo Actividades de instalación.o Actividades de operación y soporte.o Actividades de mantenimiento.

Actividades de retiroActividades integrales

o Actividades de evaluación.o Actividades de administración de la configuración del

software.o Actividades de documentación del desarrollo.o Actividades de entrenamiento. (McConnell, 1997)

Herramientas CASELas herramientas CASE (Computer Aided Software Engineering, Ingeniería deSoftware Asistida por Computadora) es la aplicación científica de un conjunto de herramientas y métodos a un sistema de software que resulta en productos de software de alta calidad, libres de defectos y mantenibles. También se refiere a los métodos para el desarrollo de

Sistemas de Información junto con herramientas automatizadas que pueden usarse en el proceso de desarrollo de software. (Sanchez , Sicilia, & Rodríguez, 2012)

Para empezar, es necesario definir que es una herramienta de software. Una herramienta de software es un programa de computadora que ayuda a realizar un determinado proceso o lo automatiza completamente.

Cuando las herramientas de software se aplican a la propia tarea de desarrollar software, se habla entonces de herramientas CASE. Una herramienta CASE es una herramienta software que se utiliza en una o más fases del desarrollo de un producto software para apoyo de alguna tarea específica de Ingeniería del Software.

La necesidad de utilizar herramientas en la Ingeniería del Software no sediscute actualmente, ya que se asume como indispensable. Sin embargo, lasherramientas CASE son relativamente recientes, pues las primeras aparecieron en la década de los años 1980. Hoy en día, las herramientas CASE son una tecnología madura y ampliamente utilizada. (Sanchez , Sicilia, & Rodríguez, 2012)

Algunas razones fundamentales para su utilización se describen a continuación:

La dificultad inherente al propio desarrollo de software. La existencia de tareas tediosas, repetitivas o simplemente

automatizables, que pueden facilitarse introduciendo un software que las mecanice parcial o completamente.

El volumen de información que se genera a lo largo del desarrollo, algo difícilmente controlable y que no cabe en una, o en unas pocas“mentes” de desarrolladores.

La necesidad de una perspectiva global a la hora de tomar ciertas decisiones durante el desarrollo, algo difícil de obtener cuando los datos sobre los diferentes aspectos del desarrollo no se encuentran centralizados.

La posibilidad real de trabajar sobre los mismos datos, incluso aunque los diferentes actores involucrados en el desarrollo (clientes, usuarios, desarrolladores, etc.) se encuentren en localizaciones físicamente dispersas.

La inversión en herramientas CASE es, salvo raras excepciones, beneficiosa para las organizaciones, pues conlleva un importante aumento

de la productividad. Genéricamente, el aumento de la productividad se mide en términos de aumento del rendimiento originado por la variación decualquiera de los factores que intervienen en la producción. En el caso de las herramientas CASE, la automatización de muchas tareas de diseño y desarrollo reduce considerablemente el esfuerzo en recursos humanos, lo cual hace que aumente el ratio entre el valor producido y los productos obtenidos, que se refleja en un beneficio directo en términos de productividad. Esta mejora de la productividad justifica, por sí misma, el empleo de herramientas CASE en una organización. (Sanchez , Sicilia, & Rodríguez, 2012)

Los beneficios del empleo de herramientas CASE en el desarrollo de software son patentes. Algunos de los más importantes son:

Aumento de la productividad, pues cuando se utilizan herramientas CASE son necesarios menos recursos para realizar el mismo trabajo.

Software de mayor calidad, consecuencia directa del aumento de la fiabilidad

Posibilidad de elaborar informes u obtener datos del desarrollo queno sería posible realizar de otro modo.

Facilita la aplicación sistemática de un proceso, así como la fidelidad a un estándar u otras restricciones, pues la herramienta implementa mecanismos de control que no permiten realizar acciones no autorizadas o fuera del estándar.

Sin embargo y a pesar de los muchos beneficios que su uso reporta, también es posible identificar un cierto número de desventajas:

La utilización de herramientas CASE tiene un coste que la organización que realiza el desarrollo debe asumir. Esto no siemprese refleja en costes directos de adquisición de la herramienta, si no costes indirectos de formación de desarrolladores en el manejo de la herramienta y otros.

Las herramientas CASE, que como todo el software en general, evolucionan y lo hacen muy rápidamente. La dependencia de los cambios en las herramientas en un problema para las organizaciones que las utilizan.

No todas las herramientas CASE son capaces de interoperar con otrasherramientas para trabajar de manera integrada.

Con no poca frecuencia, su introducción pervierte el funcionamientode una organización o de un desarrollo en particular; debido a un uso equivocado de las mismas. Debe tenerse muy claro que las

herramientas no dictan el proceso de desarrollo: es el proceso el que indica qué herramientas serán necesarias.

A pesar de estas desventajas, los beneficios de su uso compensan de largosu empleo, como lo demuestran numerosos estudios y la generalización de su empleo. (Sanchez , Sicilia, & Rodríguez, 2012)

Clasificación de las herramientas CASETradicionalmente las herramientas CASE han sido categorizadas dependiendode la fase del ciclo de vida donde se emplea. No obstante, resulta igualmente interesante su clasificación de acuerdo con el nivel de integración, una preocupación creciente en la Ingeniería del Software asistida por computadora.

Herramientas CASE según el ciclo de vida. La clasificación más habitual divide las herramientas CASE según la fase del ciclo de vida para la cualhan sido concebidas. No es infrecuente tampoco, ver cómo se distingue entre herramientas Upper-CASE y herramientas Lower-CASE dependiendo de las fases del ciclo de vida a que proporcionen soporte. Las herramientas Upper-CASE dan soporte a tareas del desarrollo más cercanas a la definición conceptual (obtención de requisitos, análisis, etc.), mientrasque las Lower-CASE dan soporte a tareas de programación, diseño, pruebas,mantenimiento o gestión de la configuración. (Sanchez , Sicilia, & Rodríguez, 2012)

A continuación se muestra una clasificación detallada de las herramientasCASE según la fase del ciclo de vida del desarrollo de software en la quese aplican:

Herramientas para requisitoso Herramientas para el modelado de requisitos.- Se utilizan

para la obtención, análisis, especificación y validación de los requisitos.

o Herramientas para el seguimiento de los requisitos (trazabilidad). Permiten hacer un seguimiento a los requisitos a lo largo de todo el ciclo de vida del desarrolloidentificando, por ejemplo, qué artefactos implementan un determinado requisito o que elementos de diseño dan cumplimiento a un cierto número de requisitos.

Herramienta para diseñoo Herramientas para el diseño de interfaces.o Herramientas para la elaboración de prototipos.

o Herramientas para la creación de diagramas de análisis y diseño.

o Herramientas para la representación e implementación de arquitecturas software.

o Herramientas para la descripción y comprobación de restricciones.

o Diccionarios de datos, que permiten almacenar información sobre las entidades del diseño y sus relaciones.

Herramientas para construcción Herramientas para pruebas

o Generadores de pruebas.o Marcos de trabajo (frameworks) para la ejecución de pruebas.o Herramientas de evaluación de pruebas.o Herramientas de gestión de las actividades de prueba.o Analizadores de rendimiento.

Herramientas para mantenimientoo Herramientas de análisis de código

Analizadores estáticos. Analizadores dinámicos o inspectores. Gestores de referencias cruzadas.

o Herramientas para la ingeniería inversa Compiladores inversos (o decompiladores). Herramientas de análisis de código de bajo nivel. Generadores de diagramas de diseño a partir del código

fuente. Generadores de diagramas de bases de datos.

Herramientas para la gestión de la configuracióno Herramientas para detección y seguimiento.o Herramientas de control de versiones.o Herramientas de construcción y generación de entregas.

Herramientas para gestióno Herramientas de planificación y seguimiento de proyectos.o Herramientas de gestión de riesgos.o Herramientas para medición.

Herramientas para procesoso Herramientas de modelado.o Herramientas de gestión de procesos.o Entornos integrados.

Herramientas para garantizar la calidad

o Herramientas de auditoría e inspeccióno Herramientas de análisis estático

A medida que la industria del software se ha desarrollado, han ido apareciendo herramientas cada vez más potentes y complejas que dan soporte, bien a actividades puntuales o bien a conjuntos de actividades relacionadas. Según este criterio, es posible clasificar las herramientasCASE en cuatro tipos con muy distinto nivel de integración. (Sanchez , Sicilia, & Rodríguez, 2012)

Con frecuencia se hace uso de más de una herramienta CASE durante las distintas actividades del ciclo de vida de un software. De hecho, para cubrir todas las actividades a realizar suelen emplearse combinaciones deherramientas que soportan conjuntos de tareas (conocidas como bancos de trabajo o toolkits) y herramientas específicas para una tarea (denominadas herramientas independientes).

Dado que en los desarrollos actuales se utilizarán, casi con seguridad, herramientas en muchos puntos diferentes del ciclo de vida, y dado que será deseable que dichas herramientas puedan cooperar, es importante estudiar diferentes técnicas o categorías de integración entre herramientas. Así, es posible identificar cinco niveles de integración:

1. La integración a nivel de plataforma se refiere a la capacidad de diferentes herramientas para interoperar en un entorno de red heterogéneo.

2. La integración a nivel de interfaz tiene que ver con la uniformidaden la representación de la información al usuario.

3. La integración a nivel de proceso se da cuando existe una relación entre las herramientas y el propio proceso de desarrollo que permite enlazarlos.

4. La integración a nivel de datos se da cuando existe la posibilidad de que diferentes herramientas intercambien y compartan datos.

5. La integración de control tiene que ver con la capacidad de una herramienta para desencadenar comportamientos en otra.

La discusión subsiguiente analiza los diferentes conjuntos o entornos de herramientas según su nivel de integración. Este criterio permitirá clasificarlos en cuatro grupos distintos: herramientas independientes, cajas de herramientas (a menudo conocidos como toolkits), bancos de trabajo y entornos CASE, los cuales, a su vez, se clasifican en entornosCASE integrados y entornos CASE centrados en el proceso.

Una caja de herramientas (toolkit) es un conjunto de herramientas CASE débilmente integradas (o no integradas en absoluto) que se distribuyen conjuntamente.

Un banco de trabajo (workbench) es un conjunto uniforme de herramientas integradas que facilita las tareas de desarrollo en algún punto del mismo.

Un entorno CASE es una colección integrada de herramientas CASE y otros componentes que proporciona soporte a todas las fases del ciclo de vida del desarrollo de software.

Desarrollo de competencias. Actividad para el portafolio de evidenciasActividad Colaborativa

En corrillos de cinco personas, exponer un modelo de desarrollo, donde se incluya: definición, características, ventajas y desventajas y tipos de proyectos donde es recomendable su aplicación.Realizar un cuadro comparativo de los modelos de desarrollo.

Actividad IndividualRealizar la siguiente lectura:

Selección de un modelo ineficaz de ciclo de vida

Los representantes de Giga-Safe estaban solicitando una actualización de Giga-Quote 1.0, tanto para corregir defectos como para solucionar fallos molestos en la interfaz de usuarios. Bill ha sido reelegido como jefe del proyecto Giga-Quote1.1, después de haber sido destituido al final de Giga-Quote 1.0, y se puso en contacto con Randy para pedirle consejo. Randy es un consultor muy valorado que había conocido en un bar.

<<Esto es lo que debes hacer>> dijo Randy. <<Tuviste muchos problemas de planificación la última vez, y por eso, esta vez necesitas organizar el proyecto para alcanzar la máxima velocidad de desarrollo. El prototipado es el enfoque másrápido, y por eso tu equipo debe utillizarlo.>> Bill creyó que era buena idea, y por tanto, cuando se reunió con el equipo más tarde, les comunicó que utilizaran el prototipado.

Mike era el responsable técnico del proyecto, y se sorprendió. <<Bill, no estoy de acuerdo contigo>>, le dijo. <<Tenemos seis semanas para solucionar un montón de problemas y realizar algunas pequeñas modificaciones en la interfaz del usuario. ¿Para qué quieres utilizar el prototipado?>>.

<<Necesitamos un prototipo para acelerar el proyecto>>. Contestó Bill malhumorado. <<El prototipado es el enfoque más rápido y novedoso, y esto es lo que quiero utilizar. ¿Hay algún problema?>>

Mal asunto, pensó Mike. <<De acuerdo>>, dijo, <<desarrollaremos un prototipo, si eso es lo que quieres>>.

Mike y una desarrolladora, Sue, comenzaron a trabajar en el prototipo. Como era casi idéntico a su sistema actual, sólo tardaron unos cuantos días en preparar elsistema completo.

Al comienzo de la segunda semana, mostraron el prototipo al director de los representantes, A. J. <<¡Maldición, no puedo decirles a mis representantes que esto es todo lo que vamos a tener!>>, exclamó A. J. <<¡Esto hace poco más de lo que realiza el programa actual! Mis representantes no paran de decir que necesitan algo mejor. Tengo algunas ideas para los nuevos informes. Os las mostraré.>> Mike y Sue escucharon atentamente, y después de la reunión Mike se reunió con Bill.

<<Le mostramos el prototipo a A. J. Quiere añadir unos informes nuevos, y no acepta un no por respuesta. Sin embargo, estamos totalmente ocupados con el trabajo que supuestamente tenemos que realizar en la actualidad.>>

<<No hay problema>>. Comentó Bill. <<Él es el director de los representantes. Si él dice que necesitan nuevos informes, ellos necesitan nuevos informes. Tenemos que encontrar la forma de tenerlos hechos a tiempo>>

<<Lo intentaré>>, le dijo Mike. <<Pero tengo que decirte que solamente tenemos un 1 por 100 de posibilidades de terminar a tiempo si incluimos estos informes>>

<<Bien, tienes que hacerlos>>, le comentó Bill. <<Quizás el trabajo se puede realizar más rápido de lo que esperas, ahora que estás utilizando el prototipado>>

Dos días más tardes, A. J. se detuvo en el despacho de Mike. <<Le he echado un vistazo al prototipo, y creo que necesitamos rediseñar también algunas de las pantallas de entrada. Ayer les mostré a algunos de mis representantes el prototipo en nuestra reunión regional de cada mes. Me comentaron que te llamaríanpara para proporcionarte algunas ideas adicionales. Les di tu número de teléfono; espero que no te importe. ¡Continúa haciendo un buen trabajo!>>

<<Gracias>>, le dijo Mike escurriéndose en su silla. Más tarde, Mike le pregunto a Bill si iba a tratar de hablar con A. J. de las modificaciones, pero Bill le contestó: <<No>>

Al día siguiente, Mike recibió dos llamadas de los representantes que habían asistido a la reunión regional. Ambos querían realizar más modificaciones en el sistema. Durante las dos semanas siguientes, recibió llamadas todos los días, acumulándose la lista de modificaciones.

En la cuarta semana de las seis que tiene el proyecto, Mike y Sue estimaron que se necesitaban seis meses para las modificaciones que se pensaban tener en dos semanas. Mike se reunió con Bill de nuevo. <<Estoy decepcionado contigo>>, le comentó Bill. <<Me he comprometido con A. J. y con los representantes a que harían las modificaciones que te propusieron. No le estás dando ninguna oportunidad al prototipado. Espera un poco y verás como funciona>>

Ya veo como funciona, pensó Mike. Y me van a echar. Pero Bill seguía firme.

En la octava semana, Bill comenzó a quejarse de que Mike y Sue no estabantrabajando lo suficiente. En la décima semana, Bill comenzó a pasarse porsus despachos dos veces al día y comprobar sus progresos. Al llegar la duodécima semana, los representantes estaban quejándose, y Bill comentó: << Tenemos que presentar algo. Entregar justo lo que tengáis ahora>>. Como no se habían finalizado los nuevos informes ni las pantallas de entrada. Mike y Sue simplemente finalizaron el código del desarrollo y entregaron una versión que consistía principalmente en resolver y corregir fallos molestos en la interfaz de usuario; en términos generales, lo que habían planificado desarrollar y entregar en primer lugar, pero necesitaron 12 semanas en lugar de 6.

Citado del libro Desarrollo y Gestión de Proyectos Informáticos. Autor: Steve McConnell

Describir cuáles son los modelos de desarrollo que se pretendieron utilizar, cuáles fueron los problemas que se tuvieron en la aplicación de dichos modelos y cuál hubiera sido su elección de modelo en las condiciones que se plantean.