Objetivo Particular:
Comprender la metodología y herramientas mas usuales en el desarrollo de la ingeniería de software.
Modelos de Proceso de sw.
Para resolver problemas reales en la industria o en la vida real, un experto de sw debe incorporar una estrategia de desarrollo.
Esta estrategia es llamada Modelo o Paradigma de la ing de sw. Aquí incluimos la naturaleza del proyecto, métodos, herramientas, etcétera.
Todo desarrollo de sw se caracteriza por un bucle de 4 etapas:
Diagrama del Status Actual
El sw, es un sistema complejo que evoluciona con el tiempo, los requerimientos cambian sobre el tiempo necesitado para el desarrollo del producto.
Modelo Lineal Secuencial
Definición:
Es la manera mas sencilla y simple de realizar una respuesta ordenada a los problemas de sw, es llamado “ciclo de vida básico” o “modelo en cascada”, el modelo lineal secuencial sugiere un enfoque sistemático secuencial del desarrollo de software, que comienza en un nivel de sistemas y progresa con el análisis, diseño, codificación, pruebas y mantenimiento, se acompaña a las siguientes actividades.
Ingeniería y modelado de Sistemas/Información.
Características:
* MODELO ANTIGUO
* ENTREGA FACIL
* ES MUY BASICO
DESVENTAJAS
* PROGRAMAcion IRREAL
* EL CLIENTE DEBE DE TENER MUCHA PACIENCIA
* SE RETRAZA MUCHO
VENTAJAS
* FACIL MANEJO
* MANTO SENCILLO
* MUY ECONOMICO POR SOLO LLEVAR POCOS PASOS
Modelo de construccion de prototipos
El cliente a menudo define un conjunto de objetivos generales para el sw, pero no identifica los requisitos detallados de entrada, procesamiento o salida.
El paradigma de la construcción de prototipos comienza con la recolección de requisitos. Entonces aparece un “diseño rápido”. Éste se centra en una representación de esos aspectos del sw que serán visibles para el usuario/cliente. El diseño rápido lleva a la construcción de un prototipo, el prototipo lo evalúa el usuario/cliente y lo utiliza para refinar los requisitos del software a desarrollar. La interacción ocurre cuando el prototipo satisface las necesidades del cliente, a la vez que permite que el desarrollador comprenda mejor lo que se necesita hacer.
Características.-
Solo necesitan los objetivos generales
Puede usarse para revisar la interacción entre el cliente y el prog
Puede ser usado como el “primer sistema”. Aunque pueda ser descartado.
Ventajas:
Es rápido de construir.
El cliente percibe un producto terminado.
El desarrollador puede construir algo inmediatamente.
Desventajas:
1.- Al cliente se le queda la idea de que el producto esta a punto de ser liberado con algunos ajustes menores, ve la rapidez en la implementación, pero no ve que la calidad no ha alcanzado su punto maximo.
2.- El desarrollador por lo general hace compromisos de implementación mal planeados y si se adopta el prototipo como base para su desarrollo, se pueden terminar usando las opciones menos ideales para la solución del problema original.
Conclusión.
La clave para hacer este paradigma exitoso, es definir las reglas del juego desde el comienzo, el cliente y el desarrollador, se deben poner de acuerdo en que el prototipo es construido para servir como mecanismo en la definición de requisitos, una vez logrado se descarta total o parcialmente dependiendo del nivel de calidad necesitado.
El modelo de desarrollo DRA
Este modelo es muy similar al modelo Lineal Secuencia, pero que enfatiza un ciclo de desarrollo extremadamente corto. Es una adaptación a “alta velocidad”, del modelo LS, el éxito en el desarrollo de este modelo es que utiliza una construccion basada en componentes. 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 periodos cortos de tiempo.
El enfoque DRA comprende las siguientes fases.
Modelado de Gestión.
Saber que información se genera, por quienes es generada, a donde va esta información, quien la procesa, etcétera.
Modelado de Datos.
Esta etapa toma el flujo de la información como un conjunto de objetos de datos necesarios para apoyar la empresa. Se definen las características (atributos) 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.
Generacion de aplicaciones.
El DRA asume la utilización de tecnicas de cuarta generacion, en lugar de crear sw con lenguajes de programación de tercera generacion, el proceso DRA trabaja para volver a utilizar componentes de programas ya existentes, cuando sea posible, o a crear componentes reutilizables, cuando sea necesario, utilizando en todo momento herramientas para facilitar la construccion del sw.
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 ejercitar todas las interfaces a fondo.
Ventajas:
Mismas que LS
Desventajas:
-Para proyectos grandes, aunque por escalas, el DRA requiere recursos humanos suficientes como para crear el número correcto de equipos DRA.
-DRA requiere clientes y desarrolladores comprometidos en las rapidas actividades necesarias para completar un sistema en un marco de tiempo abreviado.
-No todos los tipos de aplicaciones son apropiados para DRA si un sistema no se puede modularizar adecuadamente, la construccion de los componentes necesarios para DRA sera problemático.
-DRA no es adecuado cuando los riesgos tecnicos son altos. Esto ocurre cuando una nueva aplicación hace uso de tecnologías nuevas.
MODELOS EVOLUTIVOS
Modelos evolutivos de proceso del Software
Se reconoce que el sw, al igual que todos los sistemas complejos, evoluciona con el tiempo, los requisitos definidos a menudo cambian conforme a que el desarrollo avanza, haciendo que el camino que lleva al producto final no sea real, se hace imposible finalizar un producto completo, por lo que se debe introducir una versión limitada para cumplir la presión competitiva, el alcance del proyecto comprende perfectamente el conjunto de requisitos de productos centrales o del sistema, pero todavía se tienen que definir los detalles de extensiones y requisitos secundarios o cambiantes.
Es por esto que los desarrolladores, necesitan un modelo de proceso que se ha diseñado explícitamente para acomodarse a un producto que evolucione con el tiempo.
El modelo LS, se desarrolla en linea recta, es decir entrega el producto final una vez que la secuencia lineal haya terminado.
El modelo de construccion por prototipos, se diseña para ayudar al cliente y al desarrollador, a comprender los requisitos. En general, no esta diseñado para entregar un sistema de producción.
En ninguno de los paradigmas de ingenieria del software se tiene en cuenta la naturaleza evolutiva del software.
Los modelos evolutivos son iterativos, se caracterizan por la forma en que permiten a los ingenieros del sw desarrollar versiones cada vez mas completas del sw.
DE 1968 A 1985. MODELO INCREMENTAL
• El sistema no se entrega de una vez, sino que se divide y se entregan incrementos.
• Con cada incremento se entrega la parte de la funcionalidad que se ha establecido.
• Los requisitos son priorizados. Los requisitos con una más alta prioridad se incluyen en los incrementos más tempranos.
• Los requisitos de un incremento son inamovibles. Sin embargo estos puede verse modificados en incrementos posteriores.
• Este proceso se repite hasta la obtención de un producto completo.
• Tanto el modelo incremental como el de prototipos comparten una naturaleza interactiva.
• Sin embargo el modelo incremental se centra en la entrega de un producto operativo en cada incremento.
VENTAJAS E INCONVENIENTES DEL MODELO INCREMENTAL
• Los clientes no tienen que esperar hasta tener el sistema completo. El primer incremento satisface los requisitos más críticos.
• Los primeros incrementos sirven como prototipo y ayudan en la tarea de detectar los posteriores requisitos.
• Existe un riesgo bajo de fallar en el proyecto total.
• Los servicios del sistema con la prioridad más alta tienden a ser los más probados.
• Puede ser difícil ajustar los requisitos a los incrementos.
MODELO ESPIRAL
Es un modelo de proceso de software evolutivo que acompaña la naturaleza interactiva de construccion de prototipos, unido a los aspectos controlados y sistemáticos del modelo LS. Se proporciona el potencial para el desarrollo rapido de versiones incrementales del proyecto. En este modelo, el sw se desarrolla en una serie de versiones incrementales, durante las primeras interacciones y entregas, la versión incremental podria ser un modelo en papel o un prototipo. Conforme se va avanzando en el proyecto, se entregan versiones cada vez mas completas de ingenieria del sistema.
El modelo espiral, se divide en un número de actividades estructurales, llamadas también regiones de tareas:
1.-Comunicación con el cliente.
Son las tareas requeridas para establecer comunicación entre el desarrollador y el cliente.2.-Planificacion.
Son las tareas necesarias para definir recursos, el tiempo y otras informaciones relacionadas con el proyecto.3.-Análisis de riesgos.
Tareas para evaluar riesgos tecnicos y de gestión.4.-Ingeniería.
Tareas requeridas para construir una o mas representaciones de la aplicación.5.-Construccion y adaptación.
Tareas para construir probar, instalar y proporcionar Soporte al usuario. (incluye documentación y practicas).6.-Evaluacion del Cliente.
Tareas requeridas para obtener las reacciones del cliente según la evaluacion de las representaciones del sw creadas durante la etapa de ingenieria e implementadas durante la etapa de instalacion.
Cada una de las regiones cuentan con una serie de tareas y actividades definidas en función del proyecto, y están en función del alcance y sus características.
A diferencia de los modelos clasicos, este desarrollo no termina cuando entregamos el sw, este modelo puede adaptarse y aplicarse a lo largo del ciclo de vida del sw de la computadora. En esencia, la espiral permanece operativa y funcional hasta que el sw se retira.
Este modelo es un enfoque realista del desarrollo de sistemas y de sw a gran escala; como el sw evoluciona a medida que progresa el proceso, el desarrollador y el cliente comprenden y reaccionan mejor ante riesgos, en cada uno de los niveles evolutivos.
ENSAMBLADO DE COMPONENTES
Incorpora muchas de las características del Modelo Espiral. Es evolutivo por naturaleza y exige un enfoque iteractivo para la creación del software. Sin embargo, el modelo ensamblador de componentes configura aplicaciones desde componentes separados del software (algunas veces llamados "clases").
Esto se debe gracias a que, 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 computadoras.
En primer lugar se identifica las clases candidatas examinando los datos que se van a manejar por parte de la aplicación y el algoritmo que se va a crear para conseguir el tratamiento. Si estas clases han sido creadas por programas anteriores se almacenan en un biblioteca de clases o deposito. Acto seguido, se determina cuales de ellas ya existen a fin de reutilizarlas. En caso de que exista alguna que no este diseñada, se aplican los métodos orientados a objetos. Este proceso de inicia en el estado de Análisis de Riesgos del Espiral y se inserta en el estado de Construcción de Ingeniería.
MODELO CONCURRENTE
El modelo de proceso concurrente se puede representar en forma de esquema como una serie de actividades técnicas importantes, tareas y estados asociados a ellas. Todas las actividades existen concurrentemente, pero residen en estados diferentes. Por ejemplo: al principio del proyecto, la actividad de comunicación con el cliente ha finalizado su primera interacción y existe en el estado de cambios en espera. La actividad de análisis ahora hace transición al estado bajo desarrollo. Sin embargo, si el cliente indica que se deben hacer cambios en requisitos, la actividad análisis cambia del estado bajo desarrollo al estado cambios en espera.
El modelo de proceso concurrente define una serie de acontecimientos que dispararan 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 disparara 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. Un sistema cliente/servidor se compone de un conjunto de componentes funcionales. Cuando se aplica a cliente/servidor, El modelo de proceso concurrente define actividades en dos dimensiones: una dimensión de sistemas y una dimensión de componentes. Los aspectos del nivel de sistemas se afrontan mediante tres actividades: diseño, ensamblaje y uso. La dimensión de componentes se afronta con dos actividades: diseño y realización. La concurrencia se logra de dos formas:
• las actividades de sistemas y de componentes ocurren simultáneamente y pueden moderarse con el enfoque orientado a objetos.
• Una aplicación cliente/servidor típica se implenta 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. En vez confinar las actividades de ingeniería de software a una secuencia de sucesos, define una red de actividades. Los sucesos generados dentro de una actividad dada o en algún otro lugar en la red de actividad inician las transiciones entre los estados de una actividad.
¿ Qué es un Diagrama de Flujo ?
Es una herramienta de modelaje que nos permite representar un sistema como una red funcional de procesos, conectados entre sí a través de datos, representados por entradas y salidas.
Puede ser utilizado como una herramienta de planeación de negocios y de planeación estratégica.
Pasos para construir un Diagrama de nivel cero Contexto:
El objetivo principal de un Diagrama de Contexto es el de mostrar las interfases entre el sistema y el ambiente externo.
1) Determinar qué se necesita examinar y a quién, para determinar el enfoque del sistema
2) Identificar los Agentes externos, los flujos y los almacenes de datos
3) Utilizar y verificar las especificaciones del usuario para crear el diagrama
4) Verificar con el usuario que el diagrama se encuentra completo y refleja la visión del sistema.
Nivel n en un DFD
Dentro de los siguientes niveles de un DFD, deben seguirse las siguientes reglas:
1) Cada flujo de entrada en el Diagrama de Contexto, debe ser un flujo de entrada en los subsecuentes niveles de un DFD
2) Cada flujo de salida en el Diagrama de Contexto, debe ser un flujo de salida en los subsecuentes niveles de un DFD
3) Cada acceso a un almacén de datos mostrado en el Diagrama de Contexto, debe al menos ser accesado una vez dentro de los siguientes niveles
4) Cada Nivel Hijo debe ser nombrado de acuerdo a la numeración del proceso (padre) que se está detallando
DER
DTE.
El Modelado del Comportamiento o DtE, es uno de los principios fundamentales de todos los métodos de análisis de requisitos, aunque no es difundida su notación. El diagrama de transición de estado indica que acciones se llevan a cabo como consecuencia de un suceso determinado. Un estado es un modo observable de comportamiento, cada estado representa un modo observable. En lugar de un diagrama también se puede usar una representación tabular de las transiciones de estados.
(Estado = modo observable de comportamiento.)
DICCIONARIO DE DATOS
El diccionario de datos es un listado organizado de todos los elementos de datos que son pertinentes para el sistema, con definiciones precisas y rigurosas que permiten que el usuario, y el analista del sistema tengan una misma comprensión de las entradas, salidas, de las componentes de los almacenes y de los cálculos intermedios.
MODELADO ORIENTADO A OBJETOS.
Actualmente una de las áreas más novedosas es la orientación a objetos. La orientación a objetos promete mejoras de amplio alcance en la forma de diseño, desarrollo y mantenimiento del software ofreciendo una solución a largo plazo a los problemas y preocupaciones que han existido desde el comienzo en el desarrollo de software: la falta de portabilidad del código y reusabilidad, código que es dificil de modificar, ciclos de desarrollo largos y tecnicas de codificacion no intuituvas.
Un lenguaje orientado a objetos ataca estos problemas. Tiene tres características basicas: debe estar basado en objetos, basado en clases y capaz de tener herencia de clases. Muchos lenguajes cumplen uno o dos de estos puntos; muchos menos cumplen los tres. La barrera más difícil de sortear es usualmente la herencia.
Ejemplo 1.-
La Silla.
La SILLA es un miembro (también llamado “instancia”) de una clase mucho mas grande de objetos, que llamaremos MOBILIARIO, un conjunto de atributos genericos puede asociarse con cada objeto, en la CLASE Mobiliario, por ejemplo, todo Mueble tiene un costo, dimensiones, colores, peso, localizacion, etc.
Por lo tanto Silla hereda todos los atributos definidos para la clase.
Figura de Herencia.
Este enfoque se propuso por primera vez a finales de los años 60, sin embargo las tecnologías que ayudarian a crear esta visión, han necesitado casi veinte años para llegar a ser ampliamente usadas, durante la primera mitad de la decada de los 90, este paradigma de desarrollo fue elegido por muchos profesionales de la ingenieria, y esto desato una carrera que ha ido avanzando conforme el tiempo pasa, de forma que las tecnologías de objetos sustituiran a otros enfoques clasicos del desarrollo de software..
“Porque?”.
Las tecnologías de objeto llevan a reutilizar y esto nos ofrece un desarrollo mas rápido, con programas de mejor calidad, de igual forma el software con orientación a objetos es mas fácil de mantener debido a que su estructura esta inteligentemente disgregada. Lo que nos causa menos problemas cuando se deben hacer cambios. De igual forma, un sistema orientado a objetos es mas fácil de mantener y de escalar.
En este resumen se incluyen conceptos básicos que forman el fundamento para la comprension de tecnologías objetos.
El paradigma Orientado a Objetos.
Durante muchos años el termino OO (Orientado a Objetos) se uso para significar un enfoque de desarrollo de software que usaba uno de los lenguajes existentes, por ejemplo: el ADA95, el C++, Eiffel, Smalltalk, etc. Hoy en día este paradigma encierra una completa visión de la ingenieria de software.
Los beneficios de la tecnología orientada a Objetos se fortalecen si se usa antes y durante el proceso de ingenieria de software. Esta tecnología orientada a objetos debe impactar todo el proceso de desarrollo de software. Un simple uso de la POO nos ofrece mejores resultados. Se compone de Análisis OO, Diseño OO, Dominio OO, Gestión de Bases de Datos OO, ingenieria de Software OO, etcétera.
Si tuviéramos que nombrar cinco creadores de metodologías que fueran los líderes
de los métodos orientados a objetos, en casi cualquier grupo encontraremos tres de
ellos: Dr. Ivar Jacobson, Dr. James Rumbaugh y Sr. Grady Booch.