Para resolver los problemas reales de una industria, un ingeniero del software o un equipo de ingenieros debe incorporar una estrategia de desarrollo.

Presentación del tema: "Para resolver los problemas reales de una industria, un ingeniero del software o un equipo de ingenieros debe incorporar una estrategia de desarrollo."— Transcripción de la presentación:

1

2 Para resolver los problemas reales de una industria, un ingeniero del software o un equipo de ingenieros debe incorporar una estrategia de desarrollo que acompañe al proceso, métodos y capas de herramientas. modelo de proceso o paradigma de ingeniería del software Esta estrategia se llama modelo de proceso o paradigma de ingeniería del software. Se selecciona un modelo de proceso para la ingeniería del software según la naturaleza del proyecto y de la aplicación, los métodos y las herramientas a utilizarse, los controles y entregas que se requieren.

3 Todo el desarrollo del software se puede caracterizar como bucle de resolución de problemas en el que se encuentran cuatro etapas distintas: DEFINICION DE PROBLEMAS DESARROLLO TECNICO INTEGRACION DE SOLUCIONES ESTADO ACTUAL

4 ESTADO ACTUAL (STATUS QUO): «representa el estado actual de sucesos». DEFINICIÓN DE PROBLEMAS: identifica el problema específico a resolverse; el DESARROLLO TÉCNICO : resuelve el problema a través de la aplicación de alguna tecnología INTEGRACIÓN DE SOLUCIONES: ofrece los resultados (por ejemplo: documentos, programas, datos, nueva función comercial, nuevo producto) a los que solicitan la solución en primer lugar.

5 con independencia del modelo de proceso que se seleccione para un proyecto de software, todas las etapas coexisten simultáneamente en algún nivel de detalle. las cuatro etapas tratadas anteriormente se aplican igualmente al análisis de una aplicación completa y a la generación de un pequeño segmento de código.

6 MODELO LINEAL SECUENCIAL Llamado algunas veces «ciclo de vida básico» o modelo en cascada», el modelo lineal secuencial sugiere un enfoque sistemático, secuencial, para el desarrollo del software que comienza en un nivel de sistemas y progresa con el análisis, diseño, codificación, pruebas y mantenimiento

7 Análisis de los requisitos del software. Para comprender la naturaleza del (los) programa(s) a construirse, el ingeniero («analista») del software debe comprender el dominio de información del software, así como la función requerida, comportamiento, rendimiento de interconexión. Diseño. se centra en cuatro atributos distintos de programa: estructura de datos, arquitectura de software, representaciones de interfaz y detalle procedimental (algoritmo). Generación de código. El diseño se debe traducir en una forma legible por la máquina. El paso de generación de código lleva a cabo esta tarea. Si se lleva a cabo el diseño de una forma detallada, la generación de código se realiza mecánicamente.

8 Pruebas. Una vez que se ha generado el código, comienzan las pruebas del programa. detección de errores y asegurar que la entrada definida produce resultados reales de acuerdo con los resultados requeridos. ¿Por qué algunas veces falla el modelo lineal? A menudo es difícil que el cliente exponga explícitamente todos los requisitos. El modelo lineal secuencial lo requiere y tiene dificultades a la hora de acomodar la incertidumbre natural al comienzo de muchos proyectos. El cliente debe tener paciencia. Una versión de trabajo del (los) programa(s) no estará disponible hasta que el proyecto esté muy avanzado.

9 El paradigma de construcción de prototipos comienza con la recolección de requisitos. El desarrollador y el cliente encuentran y definen los objetivos globales para el software, identifican los requisitos conocidos y las áreas del esquema en donde es obligatoria más definición.

10 El diseño rápido se centra en una representación de aspectos del software que serán visibles para el usuario/cliente (enfoques de entrada y formatos de salida). El diseño rápido lleva a la construcción de un prototipo. En la mayoría de los proyectos, el primer sistema construido apenas se puede utilizar y se tiene que tirar, porque incluso la mejor planificación no es omnisciente como para que esté perfecta la primera vez. la construcción de prototipos puede ser problemática por las siguientes razones:  El cliente ve una versión de trabajo del software, sin saber que con la prisa de hacer que funcione no se ha tenido en cuenta la calidad del software global o la facilidad de mantenimiento a largo plazo. Se puede utilizar un sistema operativo o lenguaje de programación inadecuado simplemente porque está disponible La iteración ocurre cuando el prototipo se pone a punto para satisfacer las necesidades del cliente, permitiendo al mismo tiempo que el desarrollador comprenda mejor lo que se necesita hacer.

11 Modelo DRA El Desarrollo Rápido de Aplicaciones (DRA) es un modelo de proceso del desarrollo del software lineal secuencial que enfatiza un ciclo de desarrollo extremadamente corto. Es una adaptación a «alta velocidad» del modelo lineal secuencial en el que se logra el desarrollo rápido utilizando una construcción basada en componentes.

12 Si se comprenden bien los requisitos y se limita el ámbito del proyecto, el proceso DRA permite al equipo de desarrollo crear un «sistema completamente funcional» dentro de períodos cortos de tiempo (por ejemplo: de 60 a 90 días) Modelado de Gestión. El flujo de información entre las funciones de gestión se modela de forma que responda a las siguientes preguntas: ¿Qué información conduce el proceso de gestión? ¿Qué información se genera? ¿Quién la genera? ¿A dónde va la información? ¿Quién la procesa? Modelado de datos. Se definen las características (llamadas atributos) de cada uno de los objetos y las relaciones entre estos objetos. Modelado del proceso. Los objetos de datos definidos en la fase de modelado de datos quedan transformados para lograr el flujo de información necesario para implementar una función de gestión. Las descripciones del proceso se crean para añadir, modificar, suprimir, o recuperar un objeto de datos.

13 Generación de aplicaciones. En lugar de crear software con lenguajes de programación de tercera generación, trabaja para volver a utilizar componentes de programas ya existentes (cuando es posible) o a crear componentes reutilizables (cuando sea necesario). Se utilizan herramientas para facilitar la construcción del software. Pruebas y entrega. Como el proceso DRA enfatiza la reutilización, ya se han comprobado muchos de los componentes de los programas. Esto reduce tiempo de pruebas. Sin embargo, se deben probar todos los componentes nuevos y se deben ejercitar todas las interfaces a fondo.

14 Modelos Evolutivos de Proceso Del Software Los modelos evolutivos son iterativos. Se caracterizan por la forma en que permiten a los ingenieros del software desarrollar versiones cada vez mas completas del software. El modelo incremental: El modelo incremental combina elementos del modelo lineal secuencial con la filosofía interactiva de construcción de prototipos. el modelo incremental aplica secuencias lineales de forma escalonada mientras progresa el tiempo en el calendario. Cada secuencia lineal produce un «incremento» del software suplementarias.

15

16 Modelo Espiral es un modelo de proceso de software evolutivo que conjuga la naturaleza iterativa de construcción de prototipos con los aspectos controlados y sistemáticos del modelo lineal secuencial. se desarrolla en una serie de versiones incrementales. Durante las primeras iteraciones, la versión incremental podría ser un modelo en papel o un prototipo. Durante las últimas iteraciones, se producen versiones cada vez más completas del sistema diseñado.

17 El modelo en espiral se divide en un número de actividades de marco de trabajo, también llamadas regiones de tareas. La Figura 2.8 representa un modelo en espiral que contiene seis regiones de tareas: Comunicación con el cliente- las tareas requeridas para establecer comunicación entre el desarrollador y el cliente. planificación- las tareas requeridas para definir recursos, el tiempo y otra información relacionadas con el proyecto. análisis de riesgos- las tareas requeridas para evaluar riesgos técnicos y de gestión. ingeniería- las tareas requeridas para construir una o más representaciones de la aplicación. construcción y acción- las tareas requeridas para construir, probar, instalar y proporcionar soporte al usuario (por ejemplo: documentación y práctica) evaluación del cliente- las tareas requeridas para obtener la reacción del cliente según la evaluación de las representaciones del software creadas durante la etapa de ingeniería e implementada durante la etapa de instalación.

18 El objetivo de esta actividad es mostrar los requisitos del cliente. En un contexto ideal, el desarrollador simplemente pregunta al cliente lo que se necesita y el cliente proporciona detalles suficientes para continuar. Desgraciadamente, esto raramente ocurre. En realidad el cliente y el desarrollador entran en un proceso de negociación, donde el cliente puede ser preguntado para sopesar la funcionalidad, rendimiento, y otros productos o características del sistema frente al coste y al tiempo de comercialización Modelo espiral WINWIN

19 Define una serie de acontecimientos que dispararán transiciones de estado a estado para cada una de las actividades de la ingeniería del software. Por ejemplo, durante las primeras etapas del diseño, no se contempla una inconsistencia del modelo de análisis. Esto genera la corrección del modelo de análisis de sucesos, que disparará la actividad de análisis del estado hecho al estado cambios en espera. El modelo de proceso concurrente se utiliza a menudo como el paradigma de desarrollo de aplicaciones cliente/ servidor

20 La dimensión de componentes se afronta con dos actividades: diseño y realización. La concurrencia se logra de dos formas: (1) las actividades de sistemas y de componentes ocurren simultáneamente y pueden modelarse con el enfoque orientado a objetos (2) una aplicación cliente/servidor típica se implementa con muchos componentes, cada uno de los cuales se pueden diseñar y realizar concurrentemente. En realidad, el modelo de proceso concurrente es aplicable a todo tipo de desarrollo de software y proporciona una imagen exacta del estado actual de un proyecto.

21 Desarrollo basado en Componentes Enfatiza la creación de clases que encapsulan tanto los datos como los algoritmos que se utilizan para manejar los datos. Si se diseñan y se implementan adecuadamente, las clases orientadas a objetos son reutilizables por las diferentes aplicaciones y arquitecturas de sistemas basados en computadora.

22 El modelo de métodos formales comprende un conjunto de actividades que conducen a la especificación matemática del software de computadora. Los métodos formales permiten que un ingeniero de software especifique, desarrolle y verifique un sistema basado en computadora aplicando una notación rigurosa y matemática. Sin embargo, se ha hablado de una gran preocupación sobre su aplicabilidad en un entorno de gestión: 1. El desarrollo de modelos formales actualmente es bastante caro y lleva mucho tiempo. 2. Se requiere un estudio detallado porque pocos responsables del desarrollo de software tienen los antecedentes necesarios para aplicar métodos formales. 3. Es difícil utilizar los modelos como un mecanismo de comunicación con clientes que no tienen muchos conocimientos técnicos.

23 Técnicas De Cuarta Generación facilitan al ingeniero del software la especificación de algunas características del software a alto nivel. Luego, la herramienta genera automáticamente el código fuente basándose en la especificación del técnico. Cada vez parece más evidente que cuanto mayor sea el nivel en el que se especifique el software, más rápido se podrá construir el programa.

24 T4G puede incluir todas o algunas de las siguientes herramientas: lenguajes no procedimentales de consulta a bases de datos, generación de informes, manejo de datos, interacción y definición de pantallas, generación de códigos, capacidades gráficas de alto nivel y capacidades de hoja de cálculo, y generación automatizada de HTML y lenguajes similares utilizados para la creación de sitios web usando herramientas de software avanzado.

25 Tecnologías De Proceso Las herramientas de tecnología de procesos permiten que una organización de software construya un modelo automatizado del marco de trabajo común de proceso, conjuntos de tareas y actividades de protección. La herramienta de tecnología de proceso también se puede utilizar para coordinar el uso de otras herramientas de ingeniería del software asistida por computadora adecuadas para una tarea de trabajo en particular.

26 Producto y Proceso Si el proceso es débil, el producto final va a sufrir indudablemente. Aunque una dependencia obsesiva en el proceso también es peligrosa. La ingeniería del software es una disciplina que integra procesos, métodos y herramientas para el desarrollo del software de computadora. Se han propuesto varios modelos de procesos para la ingeniería del software diferentes, cada uno exhibiendo ventajas e inconvenientes, pero todos tienen una serie de fases genéricas en común. En Resumen