teoría_intro desarrollo sw

Teoría: Desarrollo de aplicaciones web en el entorno servidor(MF0492_3)

FRANCISCO JAVIER BELCHÍ ALTAMAYO [email protected] Pág. 1

UT1. Introducción al Desarrollo Software (2 sesiones, 3 horas)

Algunas definiciones de software:

IEEE Std. 610 define el software como “programas, procedimientos y documentación y datos asociados, relacionados con la operación de un sistema informático”

Según el Webster’s New Collegiate Dictionary (1975), “software es un conjunto de programas, procedimientos y documentación relacionada asociados con un sistema, especialmente un sistema informático”.

El software se puede definir como el conjunto de tres componentes:

Programas (instrucciones): este componente proporciona la funcionalidad deseada y el rendimiento cuando se ejecute.

Datos: este componente incluye los datos necesarios para manejar y probar los programas y las estructuras requeridas para mantener y manipular estos datos.

Documentos: este componente describe la operación y uso del programa.

1. El proceso del desarrollo de software

Una aplicación o software puede ser desde un simple programa que sume dos números, que requerirá unas pocas líneas de código, hasta una aplicación que integre diferentes tecnologías de desarrollo y que supondrá "picar" miles de líneas de código.

Para abordar proyectos de desarrollo de software o aplicaciones de cierta magnitud, será necesario planificar y organizar todo el proceso de elaboración. Se empezará definiendo el concepto de "Ciclo de vida de una aplicación o software".

El ciclo de vida es el conjunto de fases por las que pasa el sistema que se está desarrollando desde que nace la idea inicial hasta que el software es retirado o remplazado (muere). También se denomina a veces paradigma.

Entre las funciones que debe tener un ciclo de vida se pueden destacar:

Determinar el orden de las fases del proceso de software

Establecer los criterios de transición para pasar de una fase a la siguiente

Definir las entradas y salidas de cada fase

Describir los estados por los que pasa el producto

Describir las actividades a realizar para transformar el producto

Definir un esquema que sirve como base para planificar, organizar, coordinar, desarrollar…

Un ciclo de vida para un proyecto se compone de fases sucesivas compuestas por tareas que se pueden planificar. Según el modelo de ciclo de vida, la sucesión de fases puede ampliarse con bucles de realimentación, de manera que lo que conceptualmente se considera una misma fase se pueda ejecutar más de una vez a lo largo de un proyecto, recibiendo en cada pasada de ejecución aportaciones a los resultados intermedios que se van produciendo (realimentación).



Fases: una fase es un conjunto de actividades relacionadas con un objetivo en el desarrollo del proyecto. Se construye agrupando tareas (actividades elementales) que pueden compartir un tramo determinado del tiempo de vida de un proyecto. La agrupación temporal de tareas impone requisitos temporales correspondientes a la asignación de recursos (humanos, financieros o materiales).

Entregables: son los productos intermedios que generan las fases. Pueden ser materiales o inmateriales (documentos, software). Los entregables permiten evaluar la marcha del proyecto mediante comprobaciones de su adecuación o no a los requisitos funcionales y de condiciones de realización previamente establecidos.

1.1. Modelos del ciclo de vida del software.

La ingeniería del software establece y se vale de una serie de modelos que establecen y muestran las distintas etapas y estados por los que pasa un producto software, desde su concepción inicial, pasando por su desarrollo, puesta en marcha y posterior mantenimiento, hasta la retirada del producto. A estos modelos se les denomina “Modelos de ciclo de vida del software”. El primer modelo concebido fue el de Royce, más comúnmente conocido como Cascada o “Lineal Secuencial”. Este modelo establece que las diversas actividades que se van realizando al desarrollar un producto software, se suceden de forma lineal.

Los modelos de ciclo de vida del software describen las fases del ciclo de software y el orden en que se ejecutan las fases.

Un modelo de ciclo de vida de software es una vista de las actividades que ocurren durante el desarrollo de software, intenta determinar el orden de las etapas involucradas y los criterios de transición asociados entre estas etapas.

Un modelo de ciclo de vida del software:

Describe las fases principales de desarrollo de software

Define las fases primarias esperadas de ser ejecutadas durante esas fases

Ayuda a administrar el progreso del desarrollo

Provee un espacio de trabajo para la definición de un proceso detallado de desarrollo de software

En cada una de las etapas de un modelo de ciclo de vida, se pueden establecer una serie de objetivos, tareas y actividades que lo caracterizan. Existen distintos modelos de ciclo de vida, y la elección de un modelo para un determinado tipo de proyecto es realmente importante; el orden es uno de estos puntos importantes.

Existen varias alternativas de modelos de ciclo de vida. A continuación se muestran algunos de los modelos tradicionales y más utilizados:

o En cascada (waterfall). o Iterativo. o Incremental. o En V. o Basado en componentes (CBSE). o Desarrollo rápido (RAD).



En cascada (waterfall).

Es el enfoque metodológico que ordena rigurosamente las etapas del ciclo de vida del software, de forma que el inicio de cada etapa debe esperar a la finalización de la inmediatamente anterior.

El modelo en cascada es un proceso de desarrollo secuencial, en el que el desarrollo se ve fluyendo hacia abajo (como una cascada) sobre las fases que componen el ciclo de vida.

Se cree que el modelo en cascada fue el primer modelo de proceso introducido y seguido ampliamente en la ingeniería el software. La innovación estuvo en la primera vez que la ingeniería del software fue dividida en fases separadas.

La primera descripción formal del modelo en cascada se cree que fue en un artículo publicado en 1970 por Winston W. Royce, aunque Royce no usó el término cascada en este artículo. Irónicamente, Royce estaba presentando este modelo como un ejemplo de modelo que no funcionaba, defectuoso.

En el modelo original de Royce, existían las siguientes fases:

1. Especificación de requisitos

2. Diseño

3. Construcción (Implementación o codificación)

4. Integración

5. Pruebas

6. Instalación

7. Mantenimiento

Para seguir el modelo en cascada, se avanza de una fase a la siguiente en una forma puramente secuencial.



Si bien ha sido ampliamente criticado desde el ámbito académico y la industria, sigue siendo el paradigma más seguido a día de hoy.

Ventajas:

o Puede ser apropiado, en general, para proyectos estables (especialmente los proyectos con requisitos no cambiantes) y donde es posible y probable que los diseñadores predigan totalmente áreas de problema del sistema y produzcan un diseño correcto antes de que empiece la implementación. Funciona bien para proyectos pequeños donde los requisitos están bien entendidos.

o Es un modelo en el que todo está bien organizado y no se mezclan las fases. Es simple y fácil de usar.

o Debido a la rigidez del modelo es fácil de gestionar ya que cada fase tiene entregables específicos y un proceso de revisión. Las fases son procesadas y completadas de una vez.

Inconvenientes:

o En la vida real, un proyecto rara vez sigue una secuencia lineal, esto crea una mala implementación del modelo, lo cual hace que lo lleve al fracaso.

o Difícilmente un cliente va a establecer al principio todos los requisitos necesarios, por lo que provoca un gran atraso trabajando en este modelo, ya que este es muy restrictivo y no permite movilizarse entre fases.

o Los resultados y/o mejoras no son visibles progresivamente, el producto se ve cuando ya está finalizado, lo cual provoca una gran inseguridad por parte del cliente que quiere ir viendo los avances en el producto. Esto también implica el tener que tratar con requisitos que no se habían tomado en cuenta desde el principio, y que surgieron al momento de la implementación, lo cual provocará que haya que volver de nuevo a la fase de requisitos.

o Hay muchas personas que argumentan que es una mala idea en la práctica, principalmente a causa de su creencia de que es imposible, para un proyecto no trivial, conseguir tener una fase del ciclo de vida del producto software perfecta antes de moverse a las siguientes fases. Por ejemplo, los clientes pueden no ser conscientes exactamente de los requisitos que quieren antes de ver un prototipo del trabajo; pueden cambiar los requisitos constantemente, y los diseñadores e implementadores pueden tener poco control sobre esto. Si los clientes cambian sus requisitos después de que el diseño está terminado, este diseño deberá ser modificado para acomodarse a los nuevos requisitos, invalidando una buena parte del esfuerzo.

o Muchas veces se considera un modelo pobre para proyectos complejos, largos, orientados a objetos y por supuesto en aquellos en los que los requisitos tengan un riesgo de moderado a alto de cambiar. Genera altas cantidades de riesgos e incertidumbres.

Existen muchas variantes de este modelo. En respuesta a los problemas percibidos con el modelo en cascada puro, se introdujeron muchos modelos de cascada modificados. Estos modelos pueden solventar algunas o todas las críticas del modelo en cascada puro.

De hecho muchos de los modelos utilizados tienen su base en el modelo en cascada.



Iterativo.

Es un modelo derivado del ciclo de vida en cascada. Este modelo busca reducir el riesgo que surge entre las necesidades del usuario y el producto final por malos entendidos durante la etapa de recogida de requisitos.

Consiste en la iteración de varios ciclos de vida en cascada. Al final de cada iteración se le entrega al cliente una versión mejorada o con mayores funcionalidades del producto. El cliente es quien después de cada iteración evalúa el producto y lo corrige o propone mejoras. Estas iteraciones se repetirán hasta obtener un producto que satisfaga las necesidades del cliente.

Este modelo se suele utilizar en proyectos en los que los requisitos no están claros por parte del usuario, por lo que se hace necesaria la creación de distintos prototipos para presentarlos y conseguir la conformidad del cliente.

Ventajas:

o No hace falta que los requisitos estén totalmente definidos al inicio del desarrollo, sino que se pueden ir refinando en cada una de las iteraciones.

o Las ventajas propias de realizar el desarrollo en pequeños ciclos, lo que permite gestionar mejor los riesgos, gestionar mejor las entregas…

Inconvenientes:

o La primera de las ventajas que ofrece este modelo, el no ser necesario tener los requisitos definidos desde el principio, puede verse también como un inconveniente ya que pueden surgir problemas relacionados con la arquitectura.

Incremental.

El modelo incremental combina elementos del modelo en cascada con la filosofía interactiva de construcción de prototipos. Se basa en la filosofía de construir incrementando las funcionalidades del programa. Este modelo aplica secuencias lineales de forma escalonada mientras progresa el tiempo en el calendario. Cada secuencia lineal produce un incremento del software.



Cuando se utiliza un modelo incremental, el primer incremento es a menudo un producto esencial, sólo con los requisitos básicos. Este modelo se centra en la entrega de un producto operativo con cada incremento. Los primeros incrementos son versiones incompletas del producto final, pero proporcionan al usuario la funcionalidad que precisa y también una plataforma para la evaluación.

Ventajas:

o Mediante este modelo se genera software operativo de forma rápida y en etapas tempranas del ciclo de vida del software.

o Es un modelo más flexible, por lo que se reduce el coste en el cambio de alcance y requisitos.

o Es más fácil probar y depurar en una iteración más pequeña. o Es más fácil gestionar riesgos. o Cada iteración es un hito gestionado fácilmente

Inconvenientes:

Para el uso de este modelo se requiere una experiencia importante para definir los incrementos y distribuir en ellos las tareas de forma proporcionada.

o Cada fase de una iteración es rígida y no se superponen con otras. o Pueden surgir problemas referidos a la arquitectura del sistema porque no

todos los requisitos se han reunido, ya que se supone que todos ellos se han definido al inicio.

En V.

El modelo en v se desarrolló para terminar con algunos de los problemas que se vieron utilizando el enfoque de cascada tradicional. Los defectos estaban siendo encontrados demasiado tarde en el ciclo de vida, ya que las pruebas no se introducían hasta el final del proyecto. El modelo en v dice que las pruebas necesitan empezarse lo más pronto posible en el ciclo de vida. También muestra que las pruebas no son sólo una actividad basada en la ejecución. Hay una variedad de actividades que se han de realizar antes del fin de la fase de codificación. Estas actividades deberían ser llevadas a cabo en paralelo con las actividades de desarrollo, y los técnicos de pruebas necesitan trabajar con los desarrolladores y analistas de negocio de tal forma que puedan realizar estas actividades y tareas y producir una serie de entregables de pruebas. Los productos de trabajo generados por los desarrolladores y analistas de



negocio durante el desarrollo son las bases de las pruebas en uno o más niveles. El modelo en v es un modelo que ilustra cómo las actividades de prueba (verificación y validación) se pueden integrar en cada fase del ciclo de vida. Dentro del modelo en v, las pruebas de validación tienen lugar especialmente durante las etapas tempranas, por ejemplo, revisando los requisitos de usuario y después por ejemplo, durante las pruebas de aceptación de usuario.

El modelo en v es un proceso que representa la secuencia de pasos en el desarrollo del ciclo de vida de un proyecto. Describe las actividades y resultados que han de ser producidos durante el desarrollo del producto. La parte izquierda de la v representa la descomposición de los requisitos y la creación de las especificaciones del sistema. El lado derecho de la v representa la integración de partes y su verificación. V significa “Validación y Verificación”.

Realmente las etapas individuales del proceso pueden ser casi las mismas que las del modelo en cascada. Sin embargo hay una gran diferencia. En vez de ir para abajo de una forma lineal las fases del proceso vuelven hacia arriba tras la fase de codificación, formando una v. La razón de esto es que para cada una de las fases de diseño se ha encontrado que hay un homólogo en las fases de pruebas que se correlacionan.

Ventajas:

o Es un modelo simple y fácil de utilizar. o En cada una de las fases hay entregables específicos. o Tiene una alta oportunidad de éxito sobre el modelo en cascada debido al

desarrollo de planes de prueba en etapas tempranas del ciclo de vida. o Es un modelo que suele funcionar bien para proyectos pequeños donde los

requisitos son entendidos fácilmente.

Inconvenientes:

o Es un modelo muy rígido, como el modelo en cascada. o Tiene poca flexibilidad y ajustar el alcance es difícil y caro. o El software se desarrolla durante la fase de implementación, por lo que no se

producen prototipos del software.



o El modelo no proporciona caminos claros para problemas encontrados durante las fases de pruebas.

Basado en componentes (CBSE).

El paradigma del Desarrollo Software Basado en Componentes (DSBD) o Component Based Software Development (CBSD) en su denominación en inglés, supone adoptar un enfoque diferente al tradicional, ya que su objetivo es evitar abordar el desarrollo de los sistemas desde cero, sino hacerlo mediante la aplicación de técnicas de reutilización de partes del software ya desarrolladas y probadas. Estos elementos reutilizables son los llamados componentes.

A partir de una discusión inicial sobre el término componente, qué es y qué no es, se ha llegado a una definición comúnmente aceptada, debida a Szypersky [Szy98] quien afirma que:

"Un componente software es una unidad de composición binaria que especifica un conjunto de interfaces que el componente ofrece al entorno y un conjunto de dependencias que el componente tiene del entorno."

Además, un componente software en general se desarrolla de forma independiente, para ser compuesto posteriormente con otros componentes.

Hoy se considera que un componente es una unidad de composición reutilizable. Su reutilización en diferentes contextos hace necesario que se tenga que prestar especial atención a la descripción de sus interfaces. Esto es así porque mediante ellas el componente se comunica con los otros con los que se relaciona, proporcionando servicios al resto y recibiendo del entorno los servicios que ofrecen otros componentes. Los lenguajes de definición de interfaces deberían proporcionar información que permita manejar los componentes como cajas negras que encapsulan una cierta funcionalidad a la que no sería necesario acceder.

Bajo este paradigma, un sistema se define como un conjunto de componentes que deben conectarse adecuadamente. La fase que permite definir la arquitectura del sistema final, estableciendo las conexiones entre los componentes que la forman, se denomina fase de ensamblado, de especial importancia en este tipo de desarrollos. Sin embargo, para definir la arquitectura de un sistema no basta con definir las interfaces de los componentes, sino que es necesario que todos se hayan desarrollado siguiendo ciertas convenciones relativas a cómo debe componerse cada uno. Es decir, se deben haber construido siguiendo el mismo modelo de componentes.

Considerando que una de las razones para aplicar el DSBC es hacer más flexible la estructura del sistema final al aplicar un desarrollo basado en la composición de elementos, el último objetivo de un componente no es ejecutarse de forma aislada, sino conectarse a otros componentes en un cierto contexto. Así, el diseño de la



arquitectura es una fase esencial en el DSBC, al entenderse que los componentes son una parte intrínseca de la arquitectura de la que forman parte.

En lo que se refiere al trabajo que aquí se presenta, el modelo que se propone trabaja en torno a la definición de un modelo basado en componentes, sin que estos tengan que estar definidos bajo ningún modelo de componentes concreto.

Ventajas:

o Mejora de la productividad. Gracias a la reutilización de software. En una

primera fase se produce el efecto contrario, al invertir tiempo y esfuerzo en conseguir reusabilidad.

o Disminución de la complejidad del software. o Mejora de los tiempos de acceso al mercado. Consecuencia de los dos

aspectos anteriores. o Incremento de la calidad del software. Siempre que se emplee un mercado de

componentes certificados. o Mejora del mantenimiento. Errores más fáciles de detectar y subsanar.

Posibilidad de actualización dinámica

Inconvenientes:

o Disponibilidad de componentes. Sólo existe en algunos campos: GUIs, ofimática, etc.

o Falta de estandarización. Intereses empresariales. Interoperabilidad a través de pasarelas “bridges”.

o Falta de procesos de certificación que garanticen la calidad de los componentes.

o Falta de un proceso de ingeniería software basado en componentes bien definido. Riesgo para las empresas de cambiar sus procesos de desarrollo.

Desarrollo rápido (RAD).

La metodología de desarrollo rápido de aplicaciones (RAD) se desarrolló para responder a la necesidad de entregar sistemas muy rápido. El enfoque de RAD no es apropiado para todos los proyectos. El alcance, el tamaño y las circunstancias, todo ello determina el éxito de un enfoque RAD.

El método RAD tiene una lista de tareas y una estructura de desglose de trabajo diseñada para la rapidez. El método comprende el desarrollo iterativo, la construcción de prototipos y el uso de utilidades CASE (Computer Aided Software Engineering). Tradicionalmente, el desarrollo rápido de aplicaciones tiende a englobar también la usabilidad, utilidad y rapidez de ejecución.

A continuación, se muestra un flujo de proceso posible para el desarrollo rápido de aplicaciones:



El desarrollo rápido de aplicaciones es un proceso de desarrollo de software, desarrollado inicialmente por James Martin en 1980. El término fue usado originalmente para describir dicha metodología. La metodología de Martin implicaba desarrollo iterativo y la construcción de prototipos. Más recientemente, el término y su acrónimo se están usando en un sentido genérico, más amplio, que abarca una variedad de técnicas dirigidas al desarrollo de aplicaciones rápidas.

El desarrollo rápido de aplicaciones fue una respuesta a los procesos no ágiles de desarrollo desarrollados en los 70 y 80, tales como el método de análisis y diseño de sistemas estructurados y otros modelos en cascada. Un problema con las metodologías previas era que llevaba mucho tiempo la construcción de las aplicaciones y esto podía llevar a la situación de que los requisitos podían haber cambiado antes de que se completara el sistema, resultando en un sistema inadecuado o incluso no usable. Otro problema era la suposición de que una fase de análisis de requisitos metódica sola identificaría todos los requisitos críticos. Un evidencia amplia avala el hecho de que esto se da rara vez, incluso para proyectos con profesionales de alta experiencia a todos los niveles.

Empezando con las ideas de Brian Gallagher, Alex Balchin, Barry Boehm y Scott Shultz, James Martin desarrolló el enfoque de desarrollo rápido de aplicaciones durante los 80 en IBM y lo formalizó finalmente en 1991, con la publicación del libro, “Desarrollo rápido de aplicaciones”.

Es una fusión de varias técnicas estructuradas, especialmente la ingeniería de información orientada a datos con técnicas de prototipos para acelerar el desarrollo de sistemas software.

RAD requiere el uso interactivo de técnicas estructuradas y prototipos para definir los requisitos de usuario y diseñar el sistema final. Usando técnicas estructuradas, el desarrollador primero construye modelos de datos y modelos de procesos de negocio preliminares de los requisitos. Los prototipos ayudan entonces al analista y los usuarios a verificar tales requisitos y a refinar formalmente los modelos de datos y procesos. El ciclo de modelos resulta a la larga en una combinación de requisitos de negocio y una declaración de diseño técnico para ser usado en la construcción de nuevos sistemas.



Los enfoques RAD pueden implicar compromisos en funcionalidad y rendimiento a cambio de permitir el desarrollo más rápido y facilitando el mantenimiento de la aplicación.

Ventajas:

o Velocidad de desarrollo o Calidad: según lo definido por el RAD, es el grado al cual un uso entregado

resuelve las necesidades de usuarios así como el grado al cual un sistema entregado tiene costes de mantenimiento bajos. El RAD aumenta la calidad con la implicación del usuario en las etapas del análisis y del diseño.

o Visibilidad temprana debido al uso de técnicas de prototipado. o Mayor flexibilidad que otros modelos. o Ciclos de desarrollo más cortos..

Inconvenientes:

o Características reducidas. o Escalabilidad reducida. o Más difícil de evaluar el progreso porque no hay hitos clásicos.

Una de las críticas principales que suele generar este tipo de desarrollo es que, ya que el desarrollo rápido de aplicaciones es un proceso iterativo e incremental, puede conducir a una sucesión de prototipos que nunca culmine en una aplicación de producción satisfactoria. Tales fallos pueden ser evitados si las herramientas de desarrollo de la aplicación son robustas, flexibles y colocadas para el uso correcto.

1.2. Análisis y especificación de requisitos.

A la hora de ponernos mano a la obra con el desarrollo de una aplicación o software, nos encontraremos con el problema de concretar exáctamente lo que se va a desarrollar. Esto se debe a que:

Los usuarios no saben lo que quieren.

Un sistema tiene muchos usuarios y ninguno tiene una visión de conjunto.

No saben cómo hacer más eficiente la operación en su conjunto.

No saben qué partes de su trabajo pueden transformarse en software.

No saben detallar lo que saben de forma precisa.

Una solución es analizar el problema y establecer una serie de requisitos, con el objetivo de concretar lo que se nos pide implementar. También se valorará la viabilidad de lo que se nos propone y el alcance del mismo.

La Ingeniería de Requisitos trata de los principios, métodos, técnicas y herramientas que permiten descubrir, documentar y mantener los requisitos para sistemas basados en computadora de forma sistemática y repetible.

Ejemplo de definición de requisitos

Supóngase que hay que desarrollar el software para un sistema de control de una caldera de vapor

Posibles requisitos:

El agua entra en ebullición a 100 Grados Centígrados y a 1 atm de presión.

El sistema evitará que el agua entre en ebullición.

El sistema leerá la temperatura del agua por medio del sensor.

El sistema podrá subir la temperatura del agua por medio del regulador.



Tipos de requisitos.

En el análisis de requisitos, éstos se clasifican:

En funcionales vs. No funcionales (Capacidades vs. Restricciones)

Por prioridades

Por coste de implementación

Por niveles (alto nivel, bajo nivel)

Según su volatilidad/estabilidad

Si son requisitos sobre el proceso o sobre el producto

Modelos para el análisis de requisitos.

El modelo de análisis es la primera representación técnica de un sistema. Utiliza una mezcla de formatos en texto y diagramas para representar los requisitos del software, las funciones y el comportamiento. De esta manera se hace mucho más fácil de comprender dicha representación, ya que es posible examinar los requisitos desde diferentes puntos de vista aumentando la probabilidad de encontrar errores, de que surjan debilidades y de que se descubran descuidos.

Análisis de requisitos

El análisis de requisitos le proporciona al diseñador de software una representación de datos, función y comportamiento que puede trasladar a diseños arquitectónicos de interfaz. Este, junto al modelo de análisis, ofrece al desarrollador y al cliente los medios para evaluar la calidad una vez construido el software.

Objetivos generales del modelo de análisis

El modelo de análisis debe cumplir tres objetivos primarios:

1. Describir los que requiere el cliente 2. Establecer una base para la creación de un diseño de software 3. Definir un conjunto de requisitos que pueda validarse una vez construido el

software.



Elementos del modelo de análisis

El modelo de análisis se complementa de cuatro elementos fundamentales. Estos elementos sirven para clasificar principalmente los diferentes diagramas y otros derivados conocidos en plataformas como sistemas de información e ingeniería de software entre otros. Además estos con clasificados en elementos de escenario, elementos de flujo, elementos de clases y elementos de comportamiento.



A. MODELOS BASADOS EN ESCENARIOS

Este modelo en simples palabras sirve para una interacción más amena entre el sistema y el usuario, por lo tanto el modelo de análisis con UML comienza con la creación de escenarios en la forma de “los casos de uso, diagrama de actividad y diagrama de carril”.

Caso de uso: Describe un escenario de un caso específico en un lenguaje directo desde el punto de vista de un actor definido.



Diagrama de actividad: es un modelo muy parecido al caso de uso pero mucho mejor complementado y proporciona una representación del flujo de interacción dentro de un escenario específico.



Diagrama de carril: Consiste en tomar el diagrama actividad y situarlo en filas o en carriles. En este modelo los actores son fundamentales ya que en el diagrama de carril se especifica claramente, con un carril, la responsabilidad a cada actor.

B. MODELOS ORIENTADOS AL FLUJO

Tiene una visión del sistema del tipo entrada-proceso-salida. Los objetos de datos fluyen hacia el interior del software, se transforman mediante elementos de procesamiento y los objetos de datos resultantes fluyen al exterior del software.



Diagrama de flujo de datos

Propiedades del DFD:

1. El nivel 0 del diagrama del flujo debe representar al software.

2. La entrada y la salida primaria se deben establecer con cuidado.

3. La refinación debe comenzar por el aislamiento de procesos, objetos de datos

y almacenamiento de datos candidatos a ser representados en el siguiente

nivel

4. Toda las flechas y burbujas se deben rotular con el nombre

5. Se debe tener la continuidad de flujo al cambiar el nivel

6. La refinación de burbujas debe hacerse una por una.

Este diagrama es orientado al tiempo y rendimiento . Cada elemento o evento de control se puede implementar con valores V o F, 1 ó 0 o también otros similares.



C. MODELOS BASADOS EN CLASES

Una clase orientada a objetos encapsula atributos de los datos pero también incorpora las operaciones que manipulan los datos implicados por dichos atributos. Las clases se manifiestan en la siguiente forma: entidades externas, sucesos o eventos, cosas, papeles o roles, unidades organizacionales, sitios y estructuras.

D. MODELOS DE COMPORTAMIENTO

El modelo de comportamiento indica la forma en que el software responderá a los eventos o estímulos externos.

Diagrama de estado: representa el comportamiento de las clases cuando el sistema



Diagrama de Secuencia: representa el comportamiento al describir la forma en que las clases se mueven de estado a estado.

Documentación de requisitos.

La elaboración de documentos de requisitos es el modo habitual de guardar y comunicar requisitos.

Es buena práctica utilizar, al menos, dos documentos, a distinto nivel de detalle

DRU = Documento de Requisitos de Usuario (URD)

ERS = Especificación de Requisitos Software (SRS)

Con “Documento” nos referimos a cualquier medio electrónico de almacenamiento y distribución:

Procesador de textos

Base de Datos

Herramienta de Gestión de Requisitos

El DRU se escribe desde el punto de vista del usuario o cliente o interesado. Normalmente los requisitos de usuario, contenidos en la DRU, no poseen demasiado nivel de detalle. Se incluye la descripción del problema actual (razones por las que el sistema de trabajo actual es insatisfactorio) y las metas que se espera lograr con la construcción del nuevo sistema.

La ERS desarrolla mucho más los contenidos de la DRU. Los requisitos del software contenidos en la ERS son, por tanto, más detallados. Contiene la respuesta a la pregunta: ¿Qué características debe poseer un sistema que nos permita alcanzar los objetivos, y evitar los problemas, expuestos en la DRU?



Existen estándares para la elaboración de los documentos de requisitos, por ejemplo:

IEEE Std. 830 (versión actual de 1998)

PSS-05 de la Agencia Espacial Europea (ESA) Las herramientas de gestión de requisitos permiten generar documentación en los anteriores formatos, a partir de una base de datos de requisitos. El esquema para los documentos que define el estándar IEEE 830 es el siguiente:

Introducción o Propósito o Alcance o Definiciones o Referencias o Visión General

Descripción General o Perspectiva del producto o Funciones del producto o Características del usuario o Restricciones o Suposiciones

Requisitos específicos

Apéndices

Índice

Características de una ERS Una ERS de calidad debería poseer 24 características

No ambigua:

• La ERS es no ambigua si todo requisito posee una sola

interpretación

Completa:

• Una ERS es completa si todo lo que se supone que el software debe hacer

está incluido en la ERS. Por completitud, deberían describirse todas las

posibles respuestas a todas las posibles entradas y en todas las

situaciones posibles. Además, la ERS no contendrá, secciones de tipo “por

determinar...”

Correcta:

• Todo requisito de la ERS contribuye a satisfacer una necesidad real.

Comprensible:

• Todo tipo de lectores (clientes, usuarios, desarrolladores, equipo de

pruebas, gestores, etc.) entienden la ERS.



Verificable:

• Si para cada requisito expresado en la ERS existe un procedimiento de

prueba finito y no costoso para demostrar que el futuro sistema lo satisface.

Internamente Consistente:

• No existen subconjuntos de requisitos contradictorios.

Externamente Consistente:

• Ninguno de los requisitos está en contradicción con lo expresado en

documentos de nivel superior. Por ejemplo, en un sistema (hardware +

software), los requisitos del software no pueden contradecir los requisitos

del sistema.

Realizable:

• Si, dados los actuales recursos, la ERS es implementable.

Concisa:

• La ERS debe ser lo más breve posible, sin que esto afecte al resto de

atributos de calidad.

Independiente del diseño:

• Existen más de un diseño e implementación que realizan la ERS. Para ello

la ERS deber debería limitarse a describir el a comportamiento externo del

sistema.

Trazable:

• Cada requisito se puede referenciar de forma un unívoca. Es fundamental

para precisar qué requisitos son implementados por qué componente del

diseño, lo cual es imprescindible a la hora de realizar las pruebas de dicho

componente-

Modificable:

• Los cambios son fáciles de introducir.

Electrónicamente almacenada:

• Se encuentra en un archivo de texto, en una base de datos o, mejor aún,

ha sido creada con una herramienta de gestión de requisitos (RequisitePro,

Doors, etc.).

Ejecutable/Interpretable/Prototipable/Animable:

• Si existe una herramienta software que, recibiendo como entrada la ERS,

realice un modelo ejecutable de la misma. Aplicable tan sólo a ciertas

notaciones como las notaciones lo formales o los diagramas de transición

de estados.



Anotada por importancia relativa:

• Si los requisitos se clasifican según su importancia. Como n mínimo un

requisito puede ser “Obligatorio, Deseable u Opcional”. Esto sirve para no

asignar demasiados recursos a la implementación de requisitos no

esenciales.

Anotada por estabilidad relativa:

• Los requisitos son, en general, inestables y volátiles. A cada requisito se le

asigna una probabilidad de cambio (p.ej. “Alta, Media o Baja Baja”). Esto

ayudará a los diseñadores a diferenciar.

Anotada por versión:

• Si un lector de la ERS puede determinar qué requisitos ser serán

satisfechos por qué versión del producto.

No redundante:

• Cada requisito se expresa en un solo lugar de la ERS. La redundancia, de

todas formas, no es del todo mala si aumenta la legibilidad.

Al nivel adecuado de abstracción:

• Ni demasiado detallada ni demasiado vaga.

Precisa:

• Una ERS es precisa si hace uso de valores numéricos para precisar las

características del sistema. La precisión es aplicable, ante todo, a los

requisitos no funcionales. Por ejemplo, no es útil decir “El tiempo de

respuesta ser será más bien rápido”, sino “El tiempo de respuesta ser será

menor que dos segundos”.

• OJO: en la práctica diaria, este atributo es dificilísimo de conseguir pues es

fuertemente dependiente de la tecnología disponible, lo cual no siempre se

conoce al principio de un proyecto.

Reutilizable:

• Si ciertas secciones de la ERS se pueden reutilizar

Trazada:

• Si está claro el origen de cada requisito (quién o qué lo pide)

Organizada:

• Si el lector puede fácilmente encontrar la información buscada.

Con referencias cruzadas:

• Si se utilizan referencias entre requisitos relacionados (trazabilidad intra-

ERS) o entre secciones relacionadas



Calidad de la ERS

• Una ERS perfecta es imposible.

• La calidad de la ERS es muy difícil de cuantificar.

• En general, una ERS de calidad NO garantiza la ausencia de problemas,

pero una ERS pésima garantiza su presencia.

Validación de requisitos.

La elaboración de sucesivas revisiones de los requisitos es la fórmula más empleada para validación. Un grupo de personas (incluyendo usuarios) se ocupan de revisar el documento de requisitos.

El proceso de validación se compone de tres fases:

Búsqueda de problemas.

Reunión de las partes interesadas.

Llegar a acuerdos.

Como guía para identificar problemas habituales, se pueden utilizar listas de comprobación (“checklists”). Hay “checklists” adaptadas a distintos tipos de sistemas.

Existen otros métodos de validación:

Prototipado: Permite descubrir con rapidez si el usuario se encuentra

satisfecho, o no, con los requisitos

Validación de modelos: Cuando los requisitos se expresan por medio de

modelos (de objetos, DFDs, etc.)

Validación de su “testeabilidad”: El equipo de pruebas debe revisar los

requisitos.

Gestión de requisitos.

La gestión de requisitos es el conjunto de actividades que ayudan al equipo de trabajo a identificar, controlar y seguir los requisitos y sus cambios en cualquier momento. Es decir, la gestión de requisitos consiste en gestionar los cambios de los requisitos, las relaciones entre ellos, las dependencias entre la especificación de requisitos y otros documentos producidos por el proceso de desarrollo de software. De esta forma se asegura la consistencia entre los requisitos y el sistema construido.

Por lo tanto, los objetivos principales del proceso de gestión de requisitos serán:

Gestionar la recogida de requisitos

Obtener la aprobación de los participantes del proyecto

Gestionar los cambios (trazabilidad)

La gestión de requisitos es un proceso que se desarrolla a lo largo de toda la vida del producto.



Gestión de cambios

Los requisitos cambian durante todo el ciclo de vida de desarrollo del producto como se vio en apartados anteriores. Los cambios deben controlarse y documentarse, es decir, hay que convivir con ellos y por ello la gestión de cambios es esencial para tratar dichos cambios.

Cuando, durante el proyecto y una vez aceptada la línea base de requisitos, se solicita un cambio sobre esta línea base, estos cambios no se pueden aceptar sin más ya que podrían afectar al desarrollo de todo el sistema, o alguna parte esencial del mismo.

El siguiente gráfico muestra el proceso de gestión de cambios con las actividades a llevar a cabo durante el desarrollo del mismo:

En definitiva, podríamos destacar tres importantes actividades dentro del proceso de gestión de cambios:

1. Evaluar el impacto

La primera tarea a realizar tras recibir una petición de cambio es valorar el impacto del mismo. Para ello se deberá ir recorriendo todo el árbol de requisitos viendo como les afecta el cambio, y aquí es donde entra la trazabilidad de los requisitos.



2. Aceptación del cambio

Una vez analizado el impacto del cambio, se debe tomar una decisión. Si se acepta el cambio, tras negociarlo con el cliente, se continuará con la actividad de implementar el cambio. En caso contrario, se deberá negociar con el cliente el siguiente paso a realizar.

3. Implementación del cambio

Si se ha aceptado el cambio, hay que reflejar ese cambio en todos los productos que resulten afectados por dicho cambio (si el cambio es mínimo algunos productos como el plan del proyecto, puede que no sea necesario modificar). Además se deberá generar un nuevo punto de partida (línea base) de requisitos.

Trazabilidad

Un concepto clave en el proceso de gestión de cambios es la Trazabilidad. Los requisitos deben ser trazables, es decir, “rastreables”. Se podría decir que un requisito es trazable si se pueden identificar todas las partes del producto existente relacionadas con ese requisito. Todos los requisitos deberían ser trazables para mantener consistencia entre los distintos documentos de un proyecto.

Es importante conocer aspectos de los requisitos tales como:

Su origen (Quién los propuso)

Necesidad (Por qué existe)

Relación con otros requisitos (Dependencias)

Relación con otros elementos (Dependencias)

1.3. Diseño. Diagramas de diseño.

o Modelos para el diseño de sistemas. o Diagramas de diseño. El estándar UML. o Documentación.

1.4. Implementación. Conceptos generales de desarrollo de software.

o Principios básicos del desarrollo de software. o Técnicas de desarrollo de software.

1.5. Validación y verificación de sistemas.

o Planificación. o Métodos formales de verificación. o Métodos automatizados de análisis.

1.6. Pruebas de software.

o Tipos. o Pruebas funcionales (BBT). o Pruebas estructurales (WBT). o Comparativa. Pautas de utilización. o Diseño de pruebas. o Ámbitos de aplicación. o Pruebas de Sistemas. o Pruebas de componentes. o Automatización de pruebas. Herramientas. o Estándares sobre pruebas de software.



1.7. Gestión de proyectos de desarrollo de software.

o Planificación de proyectos. o Control de proyectos. o Ejecución de proyectos. o Herramientas de uso común para la gestión de proyectos

1.8. Calidad del software. Principios y métricas.

o Principios de calidad del software. o Métricas y calidad del software. o Concepto de métrica y su importancia en la medición de la calidad. o Principales métricas en las fases del ciclo de vida software. o Estándares para la descripción de los factores de Calidad. o ISO-9126. o Otros estándares. Comparativa.

2. Arquitecturas web

Servidores web

Los servidores web son los encargados de recibir las peticiones referidas a páginas o elementos de la web a través del protocolo http o https y de devolver el resultado de la petición, que suele ser un recurso alojado en el servidor.

Normalmente es el navegador el que pide al servidor web el recurso que desea el usuario, para finalmente recibir dicho recurso (si fue válida la petición) y traducirle si es necesario a su forma legible por el usuario (es decir la traducción de HTML la hace el navegador).

Servidores de aplicaciones web

Los servidores web sólo tienen la capacidad comentada: resolver peticiones de elementos web. Pero no se molestan en descifrar el código de estos elementos. Esa tarea la dejan en manos del cliente que hizo la petición (normalmente un navegador web).

2.1. El modelo de capas.

Una aplicación típica de la Web en la actualidad utiliza múltiples tecnologías.

El modelo más común organiza la arquitectura de una aplicación en tres capas diferenciadas:

1. Capa de presentación: aplicaciones de mejora de la interactividad con el

usuario. Solicitud de datos en segundo plano. Actualización dinámica de los

contenidos. Diseño y estilo. JavaScript(con acceso DOM) o AJAX. CSS.

Plugins.

2. Capa de lógica o de negocio: aplicaciones de tratamiento y generación del

contenido. Lenguajes de script o de propósito general: PHP, Java, C, C#, etc.

3. Capa de datos: fuentes de datos utilizadas para generar el contenido(bases de

datos, imágenes, video, animaciones). A través de S.G.B.D. (Sist. Gestores de

Bases de Datos): MySQL, Oracle, PostgreSQL,...



2.2. Plataformas para el desarrollo en las capas servidor.

Lenguajes de script de servidor

PHP (Personal Home Pages). Se trata de un lenguaje de scripts de servidor;

es decir código que se incrusta en las páginas HTML y que requiere ser

traducido por un servidor de aplicaciones que devolverá un resultado en

formato HTML.

ASP (Active Server Pages). Tecnología de Microsoft similar a la anterior, sólo

está pensada para utilizar en servidores de Windows, especialmente en IIS.

JSP (Java Server Pages). Competidor de ASP que usa como base el lenguaje

Java.

Cold Fussion. Otro lenguaje de scripts, esta vez propiedad de Adobe. Es el

más sencillo de todos, pero es de uso más caro porque requiere servidores

especiales (Servidores de Cold Fussion).



Plataformas de desarrollo de servicios web empresariales

J2EE (Java 2 Enterprise Edition). Nombre que se da a la plataforma de

creación de aplicaciones web empresariales de Java. Está formada

fundamentalmente por el propio lenguaje Java, EJB (Enterprise Java Beans,

componentes reutilizables empresariales), servlets y JSP además de otros

componentes.

.NET. Plataforma de Microsoft que permite (entre otras muchas posibilidades)

crear aplicaciones y servicios web, haciendo especial énfasis en el transporte

de datos mediante XML.

2.3. Herramientas de desarrollo orientadas a servidor de aplicaciones web.

Frameworks MVC

En inglés framework se puede traducir como estructura; en el sentido que nos ocupa un framework sería un marco de trabajo. MVC son las siglas del Modelo-Vista-Controlador, comentado antes, un paradigma de programación de aplicaciones que separa en tres niveles el trabajo:

El modelo. Especifica la forma de manipular los datos por parte de la

aplicación. Es decir especifica cómo son los datos (qué tipo tienen) y la forma

de manipularles. Este modelado de datos enlaza con la lógica de negocio, es

decir con la forma en la que los datos se almacenan en la capa de negocio (en

la base de datos en definitiva).

La vista. Hace referencia al aspecto visual de la aplicación de cara el usuario,

especifica la forma de interaccionar que tendrá la aplicación con el usuario.

El controlador. Es la parte que controla las acciones del usuario y las

comunica a los dos niveles anteriores.

MVC es, en definitiva, un modelo de trabajo que facilita la creación de aplicaciones web complejas. Hoy en día esta separación en tres capas de las aplicaciones se realiza con marcos o plantillas de trabajo (más conocidas como frameworks por su uso en inglés) que facilitan la creación de aplicaciones MVC generando casi sin esfuerzo el núcleo de las aplicaciones. Las más populares son:

Ruby on Rails. Se trata de un marco de trabajo muy exitoso por la facilidad

que tiene de programar y sus buenos resultados visuales. Se puede ejecutar

en casi cualquier servidor web, basta con instalar el componente

correspondiente.

Apache Struts. El marco de trabajo más famoso para la creación de

aplicaciones J2EE. Muy preparado para utilizar con Apache.

Spring. Otro marco para trabajar en Java J2EE que tiene bastante éxito. Tiene

incluso una versión para las aplicaciones .NET



Django. Escrita en Python y pensada para utilizar en ese lenguaje que facilita

la creación de aplicaciones web.

Zend. Framework escrito para PHP. Uno de los más populares para este

lenguaje.

Yii. Otro framework PHP de reciente creación, pero de gran crecimiento

comercial.

teoría_intro desarrollo sw

Documents