Módulo 1 - Modelos y Proceso de desarrollo de Software PDF

Preview

Summary

Download Módulo 1 - Modelos y Proceso de desarrollo de Software PDF

Description

Módulo 1 Modelos y Proceso de desarrollo de Software.

1.1- Modelos, conceptos. ¿Qué es un modelo y por qué modelamos? Los proyectos de software que fracasan lo hacen por circunstancias propias, pero todos los proyectos con éxito se parecen en muchos aspectos. Entre todos los aspectos que hacen que un proyecto tenga éxito uno en común es el uso del modelado. El modelado es una técnica de Ingeniería probada y bien aceptada. Se construyen modelos arquitectónicos de casas y edificios para ayudar a sus usuarios a visualizar el producto final antes que el mismo esté construido. Incluso podemos elaborar modelos matemáticos para analizar los efectos de vientos o terremotos sobre los edificios. Un modelo es una simplificación de la realidad. Un modelo proporciona los planos de un sistema. Pueden ser planos generales, que ofrecen una visión global del sistema en consideración, así como planos detallados. Un buen modelo incluye, para un nivel de abstracción dado, los elementos que tienen gran influencia y omite aquellos menores que no son relevantes. Todo sistema puede ser caracterizado desde diferentes perspectivas, utilizando diferentes modelos. Un modelo puede ser estructural resaltando la organización del sistema o puede ser de comportamiento, destacando su dinámica. Se construyen modelos para comprender mejor el sistema que estamos desarrollando. A través del modelado se persiguen los siguientes objetivos: Los modelos ayudan a visualizar cómo es, o queremos que sea un sistema. Los modelos permiten especificar comportamiento de un sistema.

la

estructura

o

el

Los modelos proporcionan plantillas que sirven de guía en la construcción de un programa.

1

Los modelos documentan las decisiones que se han adoptado. Construimos modelos de sistemas complejos porque es difícil comprender el sistema en su totalidad. El ser humano tiene una capacidad limitada para comprender y abordar la complejidad, por ello a través del modelado podemos reducir el problema que se está estudiando y enfocarnos en un aspecto a la vez. En general, aún en el proyecto más simple, los desarrolladores siempre realizan alguna actividad de modelado como un bosquejo en hoja de papel o en algún software graficador. Sin embargo, estos modelos informales no proporcionan frecuentemente un lenguaje común que pueda compartirse entre todos los desarrolladores y no siempre queda debidamente documentado. Así como existe un lenguaje común para realizar planos en la industria de la construcción, en la Ingeniería Civil, Eléctrica, entre otros, también es beneficioso para una empresa de software que todos sus desarrolladores utilicen un lenguaje común para el modelado del software.

Principios básicos de modelado Como se plantea en el libro “El lenguaje Unificado de Modelado”, la experiencia en el uso del modelado sugiere los siguientes cuatro principios básicos (Booch G., Rumbaugh J. y Jacobson I., 1999, págs. 7,8):

“La elección de los modelos a crear tiene mucha influencia sobre cómo se aborda el problema y cómo de da forma a la solución.” Esto quiere decir que hay que elegir bien los modelos. Los modelos adecuados pueden arrojar mucha luz sobre los problemas de desarrollo más complicados, brindando una comprensión que no podríamos obtener de otra manera. Ahora bien, si se incurre en la utilización de modelos erróneos o inadecuados, éstos desorientarán haciendo que uno se centre en cuestiones irrelevantes. “Todo modelo puede ser expresado a distintos niveles de precisión.” Los mejores tipos de modelos son aquellos que permiten elegir el grado de detalle dependiendo de quién está viendo el sistema y por qué necesita verlo. Lo que un usuario final espera de un modelo del sistema no es lo mismo que necesita un diseñador. Un analista o un usuario final se centrarán en “qué” hace el sistema; un diseñador/desarrollador se

2

centrará en el “cómo”. Tanto unos como otros querrán visualizar un sistema a diferentes niveles de detalle en diferentes momentos. “Los mejores modelos son los que están ligados a la realidad.” Todos los modelos simplifican la realidad; lo importante es que esta simplificación no enmascare ningún detalle importante. Es mejor tener modelos que tengan una clara conexión con la realidad y donde esta conexión sea débil saber concretamente cómo se apartan estos modelos del mundo real. “No es suficiente confeccionar un único modelo. Todo sistema no trivial se aborda mejor a través de un conjunto de modelos casi independientes.” Si por ejemplo, se estuviera realizando la construcción de una casa, no hay un único conjunto de planos que indiquen todos sus detalles sino que se necesitarán planos de planta, de electricidad, de lozas, de agua, entre otros. Lo mismo se aplica para los sistemas de software. Para comprender la arquitectura de tales sistemas se necesitan varias vistas complementarias y entrelazadas. Cuando se habla de modelos “casi independientes” se refiere a tener modelos que podemos construir y estudiar separadamente pero que están interrelacionados.

1.2- Tipos de metodologías Concepto de Metodología. En principio podemos definir una metodología como “... un conjunto de filosofías, fases, procedimientos, reglas, técnicas, herramientas, documentación y aspectos de formación para los desarrolladores de sistemas de información” 2, según lo expresa Piattini (2004, pág. 79)citando a Maddison - . De acuerdo a esta definición, una metodología es entonces un conjunto de componentes que especifican: Cómo dividir un proyecto en etapas. Las tareas que se llevan a cabo en cada etapa. 3

Las salidas que se producen y cuándo se deben producir. Las restricciones se aplican. Las herramientas que se van a utilizar. Cómo se gestiona y controla un proyecto. Considerando una definición más genérica, podemos decir que una metodología de desarrollo es un conjunto de procedimientos, técnicas, herramientas y un soporte documental que ayuda a los desarrolladores a realizar un nuevo software. Normalmente consistirá en una serie de fases descompuestas en subfases (módulos, etapas, pasos, entre otras formas de denominación). Esta descomposición del proceso de desarrollo guía a los desarrolladores en la elección de las técnicas que debe elegir para cada estado del proyecto, así como facilita la planificación, gestión, control y evaluación de los proyectos. Una metodología, por lo tanto, representa el camino para desarrollar software de manera sistemática. Se mencionan a continuación algunos conceptos relacionados con las metodologías: Métodos: Indican cómo construir técnicamente un sistema. Abarcan un amplio espectro de tareas que incluyen la comunicación, el análisis de los requisitos, el modelado de diseño, la construcción de programas, la realización de pruebas y el soporte. Se basan en un conjunto de principios básicos que gobiernan cada área de la tecnología e incluyen actividades de modelado y otras técnicas descriptivas. Técnica: Es un método estructurado y repetible para lograr una tarea específica. Herramientas: Suministran un soporte automatizado o semiautomatizado para el proceso y los métodos. Cuando se integran herramientas para que la información creada por una herramienta la pueda utilizar otra, se establece un sistema de soporte para el desarrollo del software llamada Ingeniería de Software Asistido por Computadora (CASE).

Objetivos de las Metodologías. Se pueden identificar, de forma general, tres necesidades principales que se intentan cubrir con una metodología:

4

Mejores aplicaciones. De todos modos hay que tener en cuenta que el seguimiento de una metodología no basta para asegurar la calidad del producto, sino que esto depende de muchos pequeños factores. Un mejor proceso de desarrollo que identifica las salidas o productos intermedios de cada fase, lo que permite planificar y controlar el proyecto. Un proceso estándar en la organización, lo que aporta entre otros beneficios una mayor integración entre los proyectos de sistemas en marcha y una mayor facilidad en el cambio de personal de un proyecto a otro. Entre los objetivos que pueden tener las metodologías, podemos mencionar: Registrar los requisitos de un sistema de información de manera apropiada. Proporcionar un método sistemático de desarrollo de forma que se pueda controlar su progreso. Construir un sistema de información dentro de un tiempo apropiado y costos aceptables. Construir un sistema bien documentado y que sea fácil de mantener. Ayudar a identificar lo más pronto posible cualquier cambio que sea necesario a realizar dentro del proceso de desarrollo. Proporcionar un sistema que satisfaga a todas las personas afectadas por el mismo, ya sean clientes, directivos, auditores, usuarios.

Características deseables en una buena Metodología. Entre las características deseables que debería incluir una metodología se pueden destacar las siguientes:

5

Existencia de reglas predefinidas: La metodología debería indicar formalmente reglas que definan sus fases, las tareas, productos intermedios, técnicas y herramientas a utilizar. Cobertura total del ciclo de desarrollo: Debe indicar los pasos a seguir para cubrir desde el planteamiento de un sistema hasta su mantenimiento. Verificaciones intermedias: Debe contemplar la realización de verificaciones sobre los productos generados en cada fase para comprobar su corrección. Enlace con procesos de gestión: Debe proporcionar una forma de desarrollar software de manera planificada, controlada y de calidad. Comunicación efectiva: Debería proporcionar un medio de comunicación efectiva entre los desarrolladores para facilitar el trabajo en grupo y con los usuarios. Utilización sobre un abanico amplio de proyectos: Debe ser flexible para poder emplearse en proyectos de diverso tamaño, variedad y entorno. Fácil formación: La organización debe formar a su personal en todos los procedimientos y técnicas definidos por la metodología. Uso de herramientas CASE: La metodología debe ser soportada por herramientas automatizadas que mejoren la productividad del equipo de desarrollo y la calidad de los productos obtenidos. Contener actividades que mejoren el proceso de desarrollo: Es necesario definir mediciones que indiquen la calidad y el costo asociado a cada etapa del proceso. Estos datos se utilizarán para analizar y modificar el proceso para su mejora. Soporte al mantenimiento: El campo de la evolución del software debería ser tenido en cuenta por las metodologías para facilitar las modificaciones sobre los sistemas existentes. Soporte de la reutilización de software: Se deberían incluir procedimientos para la creación, mantenimiento y recuperación de componentes reutilizables que no se limiten sólo al código. La aplicación de patrones de software en las distintas etapas del proceso de desarrollo ayuda a la reutilización de soluciones de análisis y diseño.

6

Tipos de Modelos de Proceso Como ya se mencionó anteriormente, una metodología debe cubrir todo el ciclo de desarrollo de un sistema de software desde su planteamiento hasta su evolución. Dentro de este ciclo de vida una porción muy importante lo constituye el desarrollo del sistema de software. Cualquier organización de ingeniería de software debe describir un conjunto único de actividades para el proceso de software que adopte para el desarrollo del sistema. También debe completar cada actividad con un conjunto de acciones de ingeniería de software y definir cada acción en cuanto a un conjunto de tareas que identifique el trabajo y los productos del trabajo que deben completarse para alcanzar las metas de desarrollo. Después, la organización debe adaptar el modelo de proceso resultante y ajustarlo a la naturaleza específica de cada proyecto, a las personas que lo realizarán y el ambiente en el que se ejecutará el trabajo. Se mencionan a continuación algunos de los modelos prescriptivos de proceso que consideramos más representativos tal como los presenta Roger Pressman (2006) en su libro “Ingeniería de Software” (ver Bibliografía), sin que esta enumeración sea exhaustiva ni la única manera de clasificar los mismos. Luego en la Unidad 2 se presentará el Proceso Unificado de Desarrollo.

El ciclo de vida clásico o en cascada. El modelo en cascada, llamado también el ciclo de vida clásico, sugiere un enfoque sistemático, secuencial hacia el desarrollo de software tal como se visualiza en la siguiente figura:

Fuente: Libro “Ingeniería del Software” – Roger Pressman (2006), Pág. 50.

7

El modelo en cascada es el más antiguo para la Ingeniería de software, sin embargo las críticas realizadas a este modelo durante las décadas precedentes ocasionaron que aún sus más fervientes seguidores se hayan cuestionado su eficacia. Entre los problemas que presenta el modelo en cascada podemos enunciar: Los proyectos reales rara vez siguen el flujo secuencial que propone el modelo. Frecuentemente es difícil para el cliente definir todos los requisitos de manera explícita en el inicio del proyecto. Una versión funcional de los programas sólo estará disponible cuando el proyecto esté bastante avanzado, por lo que el cliente deberá tener paciencia. La naturaleza lineal del modelo en cascada conduce a situaciones en las cuales algunos miembros del equipo de trabajo deben esperar a otros para terminar tareas dependientes, lo cual “bloquea” el avance del proyecto. Sin embargo, este modelo de proceso puede resultar útil en casos donde los requerimientos están fijos y donde el trabajo se realice en forma lineal hasta su conclusión. Modelos de procesos incrementales. Muchas veces los requisitos iniciales del software están bien definidos de manera razonable, pero el enfoque global del esfuerzo de desarrollo excluye un proceso puramente lineal. Además, es probable que sea necesario proporcionar de manera rápida un conjunto limitado de funcionalidad para el usuario y luego refinarla y expandirla en las entregas posteriores del software. En estos casos es conveniente elegir un modelo de proceso diseñado para producir el software de manera incremental. Se presentan a continuación dos modelos de proceso de este tipo. a) El modelo incremental. El modelo incremental combina elementos del modelo en cascada aplicado en forma iterativa. Como se muestra en la siguiente figura, este modelo aplica secuencias lineales de manera escalonada conforme avanza el tiempo en el calendario.

8

Fuente: Libro “Ingeniería del Software” – Roger Pressman (2006), pág. 52.

Cada secuencia lineal produce incrementos en el software. Con frecuencia, el primer incremento es un producto esencial, es decir se consideran los requisitos básicos pero muchas características complementarias aún no se incorporan. El producto producido se muestra al cliente y como resultado de la evaluación se desarrolla un plan para el incremento siguiente que afronta la modificación del producto esencial a fin de satisfacer mejor las necesidades del cliente e incorporar características y funcionalidades adicionales. Este proceso se repite después de la entrega de cada incremento hasta producir el producto completo. El desarrollo incremental es útil cuando el personal necesario para una implementación completa no está disponible; si el producto esencial es bien recibido se agrega el personal necesario para implementar el incremento siguiente. Además los incrementos se pueden planear para manejar los riesgos técnicos; por ejemplo, cierta funcionalidad puede requerir el uso de un hardware nuevo que aún no está disponible entonces se planean los primeros incrementos de manera que se evite el uso de este hardware. b) El modelo DRA. El desarrollo rápido de aplicaciones (DRA) es un modelo de proceso incremental que resalta un ciclo de desarrollo corto. El modelo DRA es una adaptación a “alta velocidad” del modelo en cascada en el que se logra el desarrollo rápido mediante un enfoque de construcción basado en componentes. Con una buena comprensión de los requisitos y se limita el ámbito del proyecto, el proceso DRA permite que un equipo de desarrollo

9

obtenga el producto de software completamente funcional dentro de un período muy corto, por ejemplo entre 60 y 90 días. En la siguiente figura se ilustra el proceso DRA:

Fuente: Libro “Ingeniería del Software” – Roger Pressman (2006), pág. 54.

Si una aplicación de negocios se puede modular de modo que cada gran función se pueda completar en menos de tres meses es una candidata para aplicar DRA. Cada gran función se puede abordar por un equipo separado aplicando DRA, luego se integran y se forma el todo. Como todos los modelos de proceso, este enfoque presenta algunos inconvenientes: Para proyectos grandes escalables se necesitan suficientes recursos humanos para crear el número correcto de equipos DRA. Los proyectos DRA pueden fracasar si los desarrolladores y clientes no se comprometen con las actividades rápidas necesarias para completar el sistema en tiempo breve. Es problemática la construcción de los componentes necesarios para el DRA si el sistema no se puede modular en forma apropiada. Si el alto rendimiento es un aspecto importante y se alcanzará al convertir interfaces en componentes del sistema, este enfoque puede no funcionar.

10

El modelo DRA no es apropiado cuando los riesgos técnicos son altos, por ejemplo cuando la nueva aplicación requerirá muchas nuevas tecnologías.

Modelos de procesos evolutivos. Al igual que todos los sistemas complejos, el software evoluciona con el tiempo. Los requisitos del negocio y productos frecuentemente cambian durante el proceso de desarrollo; en estos casos una ruta lineal que conduzca al producto final no será real. En estas situaciones los ingenieros de software necesitan un modelo de proceso que haya sido diseñado de manera explícita para incluir un producto que evolucione con el tiempo. Los modelos evolutivos son iterativos y se caracterizan por la forma en que permiten que se desarrollen versiones cada vez más completas del software. Se presentan a continuación dos modelos de proceso de este tipo: a) Construcción de prototipos. Frecuentemente los clientes definen un conjunto de objetivos generales para el software pero no identifican los requisitos detallados de entrada, proceso o salida. En estos casos y en muchas otras situaciones un modelo de construcción de prototipos puede ser de utilidad. En este modelo el proceso se inicia con la comunicación, en la cual el ingeniero de software y el cliente encuentran y definen los objetivos globales para el software, identifican los requisitos conocidos y las áreas del esquema en las que se necesita más definición. Se plantea entonces con rapidez una iteración de construcción de prototipos y se presenta el modelado en forma de un diseño rápido. Este diseño rápido se centra en una representación de los aspectos del software que serán visible para el usuario final y conduce a la construcción de un prototipo. El cliente/usuario evalúa el prototipo y con la retroalimentación se refinan los requisitos del software que se desarrollará. La iteración ocurre cuando el prototipo se ajusta para satisfacer las necesidades del cliente.

11

Fuente: Libro “Ingeniería del Software” – Roger Pressman (2006), pág. 55.

Si bien la construcción de prototipos se puede utilizar como un modelo de proceso independiente, se emplea más comúnmente como una técnica que puede implementarse dentro del contexto de cualquiera de los modelos de proceso expuestos. La construcción de prototipos también plantea algunos inconvenientes: El cliente ve lo que parece una versión en funcionamiento del software sin saber que por la prisa de hacer funcionar el prototipo no se ha considerado la calidad del software global o la facilidad de mantenimiento a futuro y le cuesta comprender que debe construirse otra vez para mantener los altos niveles de calidad. Muchas veces el desarrollador establece compromisos de implementación para lograr que el prototipo funcione con rapidez y luego se familiariza con las selecciones realizadas y se olvidan las razones por las que son inapropiadas. b) ...