PROCESO UNIFICADO

INTRODUCCIÓN 

El Proceso Unificado no es simplemente un proceso, sino un marco de trabajo que puede ser adaptado a organizaciones o proyectos específicos para así llegar a cumplir el objetivo planteado. 

El proceso Unificado reconoce la importancia de la comunicación con el cliente y los métodos  directos para describir su punto de vista respecto de un sistema.

El Proceso Unificado  es un marco de trabajo extensible, por lo que muchas veces resulta imposible decir si un refinamiento particular del proceso ha sido derivado del Proceso Unificado o del RUP. 

Por dicho motivo, los dos nombres suelen utilizarse para referirse a un mismo concepto.

El Proceso Unificado no es simplemente un proceso, sino un marco de trabajo extensible que puede ser adaptado a organizaciones o proyectos específicos. De la misma forma, el Proceso Unificado de Rational, también es un marco de trabajo extensible, por lo que muchas veces resulta imposible decir si un refinamiento particular del proceso ha sido derivado del Proceso Unificado o del RUP. Por dicho motivo, los dos nombres suelen utilizarse para referirse a un mismo concepto.

MARCO TEÓRICO

PROCESO UNIFICADO

El Proceso Unificado de Desarrollo Software o simplemente Proceso Unificado es un marco de desarrollo de software que se caracteriza por estar dirigido por casos de uso, centrado en la arquitectura y por ser iterativo e incremental. El refinamiento más conocido y documentado del Proceso Unificado es el Proceso Unificado de Rational o simplemente RUP.

El proceso unificado conocido como RUP, es un modelo de software que permite el desarrollo de software a gran escala, mediante un proceso continuo de pruebas y retroalimentación, garantizando el cumplimiento de ciertos estándares de calidad. Aunque con el inconveniente de generar mayor complejidad en los controles de administración del mismo. Sin embargo, los beneficios obtenidos recompensan el esfuerzo invertido en este aspecto.

BIBLIOGRAFIA

Pressman, R. 2010. INGENIERÍA DEL SOFTWARE. Un enfoque práctico. Séptima edición

DIAGRAMAS DE COMPORTAMIENTO: CASOS DE USO

INTRODUCCIÓN

 Este articulo describe cómo modelar la funcionalidad del sistema utilizando casos de uso. En el UML, los casos de uso son los principales medios para capturar la funcionalidad del sistema desde la perspectiva del usuario y muchas veces puede remplazar al documento "requisitos funcionales". 

MARCO TEÓRICO

DIAGRAMAS DE CASOS DE USO

Los diagramas de casos de uso documentan el comportamiento de un sistema desde el punto de vista del usuario. Por lo tanto los casos de uso determinan los requisitos funcionales del sistema, es decir, representan las funciones que un sistema puede ejecutar.

Su ventaja principal es la facilidad para interpretarlos, lo que hace que sean especialmente útiles en la comunicación con el cliente.

ELEMENTOS BÁSICOS

Los actores representan un tipo de usuario del sistema. Se entiendo como usuario cualquier cosa externa  que interactúa con el sistema. No tiene por qué ser un ser humano, puede ser otro sistema informático o unidades organizativas o empresas. Siempre hay que intentar independizar los actores de la forma  en que se interactúa con el sistema. Por ejemplo un teclado  no es un actor en la mayor parte de los casos, sólo un medio para introducir información al sistema. Suele ser útil mantener una lista de los usuarios reales para cada actor.

Un actor en un diagrama de casos de uso representa un rol que alguien puede estar jugando, no un individuo particular por lo tanto puede haber personas particulares que puedan estar usando el sistema de formas diferentes en diferentes ocasiones: socio de biblioteca y bibliotecario.

CONCLUSIÓN

Los diagramas de caso de uso son uno de los cinco tipos de diagramas en UML para modelar aspectos dinámicos de sistemas (diagramas de actividad, diagramas de estados, diagramas de secuencia y diagramas de colaboración son otros cuatro tipos de diagramas en UML para modelar los aspectos dinámicos de un sistema). Los diagramas de casos de uso son importantes para modelar el comportamiento de un sistema, un subsistema o una clase. Cada uno muestra un conjunto de casos de uso, actores y sus relaciones.

BIBLIOGRAFIA

Pressman, R. 2010. INGENIERÍA DEL SOFTWARE. Un enfoque práctico. Séptima edición.

DIAGRAMAS DE COMPORTAMIENTO: ACTIVIDAD

INTRODUCCIÓN

Los diagramas de comportamiento se emplean para visualizar, especificar, construir y documentar los aspectos dinámicos de un sistema.

MARCO TEÓRICO

DIAGRAMA DE ACTIVIDAD

representa los flujos de trabajo paso a paso de negocio y operacionales de los componentes en un sistema. Un Diagrama de Actividades muestra el flujo de control general.

En un diagrama de actividades se muestra un proceso de negocio o un proceso de software como un flujo de trabajo a través de una serie de acciones. Estas acciones las pueden llevar a cabo personas, componentes de software o equipos.

Puede usar un diagrama de actividades para describir procesos de diversos tipos, como los ejemplos siguientes:

• Un proceso de negocio o un flujo de trabajo entre los usuarios y el sistema. Para obtener más información, vea Crear modelos de los requisitos de los usuarios.
• Los pasos realizados en un caso de uso. Para obtener más información, vea Diagramas de casos de uso de UML: Instrucciones.
• Un protocolo de software, es decir, las secuencias de interacciones permitidas entre los componentes.
• Un algoritmo de software.

CONCLUSIÓN

Los diagramas puede considerarse como un caso especial de un diagrama de estados en el cual casi todos los estados son estados acción (identifican una acción que se ejecuta al estar en él) y casi todas las transiciones evolucionan al término de dicha acción (ejecutada en el estado anterior). Un diagrama de actividades puede dar detalle a un caso de uso, un objeto o un mensaje en un objeto. Permiten representar transiciones internas al margen de las transiciones o eventos externos.

BIBLIOGRAFIA

Pressman, R. 2010. INGENIERÍA DEL SOFTWARE. Un enfoque práctico. Séptima edición.

DIAGRAMAS DE COMPORTAMIENTO: INTERACCIÓN

INTRODUCCIÓN

Todos los sistemas tienen una estructura estática y un comportamiento dinámico, y el  UML proporciona diagramas para capturar y describir ambos aspectos. Los diagramas de clases se usan para documentar y expresar la estructura estática de un sistema, es decir, las clases y sus relaciones. Los diagramas de estado y los diagramas de interacción describen el comportamiento de un sistema, para demostrar cómo los objetos interactúan dinámicamente en diferentes momentos durante la ejecución del sistema.

MARCO TEÓRICO

DIAGRAMA DE INTERACCIÓN 

El diagrama de interacción, representa la forma en como un Cliente (Actor) u Objetos (Clases) se comunican entre si en petición a un evento. Esto implica recorrer toda la secuencia de llamadas, de donde se obtienen las responsabilidades claramente.

Dicho diagrama puede ser obtenido de dos partes, desde el Diagrama Estático de Clases o el de Casos de Uso (son diferentes).

Los componentes de un diágrama de interacción son:

• Un objeto o actor
• Mensaje de un objeto a otro objeto 
• Mensaje de un objeto a su mismo

ELEMENTOS 

OBJETO/ACTOR

El rectángulo representa una instancia de un Objeto en particular, y la línea punteada representa las llamadas a métodos del objeto.

MENSAJE A OTRO OBJETO

MENSAJE AL MISMO OBJETO

CONCLUSIÓN 

El Diagrama de Secuencia:

• Esta centrado en los objetos individuales.
• Es más adecuado para observar la perspectiva cronológica de las interacciones.
• Muestra la secuencia explícita de mensajes
• Son mejores para especificaciones de tiempo real y para escenarios complejos.

BIBLIOGRAFIA

Pressman, R. 2010. INGENIERÍA DEL SOFTWARE. Un enfoque práctico. Séptima edición.

DIAGRAMAS DE COMPORTAMIENTO: ESTADO

INTRODUCCIÓN

Las clases y las interacciones implementan los casos de uso en el sistema. Las interacciones son expresadas en diagramas de secuencia y/o colaboración. Entonces hay un enlace entre la visión funcional y la visión dinámica del sistema. Las clases utilizadas en la implementación de los casos de uso son modeladas y descritas en los diagramas de clase, en los diagramas de estado y/o actividad. 

DIAGRAMA DE ESTADO

Los diagramas de estado son una técnica conocida para describir el comportamiento de un sistema. Describen todos los estados posibles en los que puede entrar un objeto particular y la manera en que cambia el estado del objeto, como resultado de los eventos que llegan a el. En la mayor parte de las técnicas Orientadas a Objetos, los diagramas de estado se dibujan para una sola clase, mostrando el comportamiento de un solo objeto durante todo su ciclo de vida.

Existen muchas formas de diagramas de estado, cada una con semántica ligeramente diferente. La mas popular que se emplea en las técnicas de OO se basa en la tabla de estados de David Harel (Vol. 8). OMT fue quien la uso por primera vez para los métodos de OO y fue adoptada por Grady Booch en su segunda edición (1994).

El estado en el que se encuentra un objeto determina su comportamiento. Cada objeto sigue el comportamiento descrito en el Diagrama de Estados asociado a su clase. Los Diagramas de Estados y escenarios son complementarios, los Diagramas de Estados son autómatas jerárquicos que permiten expresar concurrencia, sincronización y jerarquías de objetos, son grafos dirigidos y deterministas. La transición entre estados es instantánea y se debe a la ocurrencia de un evento.

CONCLUSIÓN

Los diagramas de estados son buenos para describir el comportamiento de un objeto a través de varios casos de uso. No son tan buenos para describir un comportamiento que involucra cierto número de objetos que colaboran entre ellos. Así pues, es útil combinar los diagramas de interacción son buenos para la descripción del comportamiento de varios objetos en un mismo caso de uso. Por su parte, los diagramas de actividades son buenos para mostrar la secuencia general de las acciones de varios objetos y casos de uso.

BIBLIOGRAFIA

Pressman, R. 2010. INGENIERÍA DEL SOFTWARE. Un enfoque práctico. Séptima edición.

DIAGRAMAS DE COMPORTAMIENTO: SECUENCIA, COMUNICACIÓN, TIEMPOS

INTRODUCCIÓN

En esta clase aprendimos a usar estos diagramas Esencialmente, consisten en un diagrama de flujo en

el que se muestran los pasos que deben ejecutarse para cumplir un proceso de cómputo, 

pudiendo también incluir aspectos de sincronización.

MARCO TEÓRICO

DIAGRAMA DE SECUENCIA

Un diagrama de secuencia muestra la interacción de un conjunto de objetos en una aplicación a través del tiempo y se modela para cada caso de uso. Mientras que el diagrama de casos de uso permite el modelado de una vista  del escenario, el diagrama de secuencia contiene detalles de implantación del escenario, incluyendo los objetos y clases que se usan para implementar el escenario y mensajes intercambiados entre los objetos.

Típicamente se examina la descripción de un caso de uso para determinar qué objetos son necesarios para la implementación del escenario. Si se dispone de la descripción de cada caso de uso como una secuencia de varios pasos, entonces se puede "caminar sobre" esos pasos para descubrir qué objetos son necesarios para que se puedan seguir los pasos. Un diagrama de secuencia muestra los objetos que intervienen en el escenario con líneas discontinuas verticales, y los mensajes pasados entre los objetos como flechas horizontales.

BIBLIOGRAFIA

Pressman, R. 2010. INGENIERÍA DEL SOFTWARE. Un enfoque práctico. Séptima edición.

DIAGRAMA DE ESTRUCTURA: CLASE

INTRODUCCIÓN

En esta clase aprendimos a usar los diagramas de clases ya que estas son una descripción visual  de como se representan los modelos de los proyectos.Una clase también puede tener una representación (metaobjeto) en tiempo de ejecución, que proporciona apoyo en tiempo de ejecución para la manipulación de los metadatos relacionados con la clase.

MARCO TEÓRICO

DIAGRAMA DE CLASES

Un diagrama de clases es una descripción visual de los posibles sistemas. Un diagrama de clases y un diagrama de objetos son las alternativas de representación de modelos de objetos, aunque los diagramas de clases prevalec en más que los de objetos. Normalmente se puede construir un diagrama de clases y ocasionalmente uno de objetos para ilustrar las estructuras de datos más complejas.

Un diagrama de clases contiene íconos que representan las clases. Se pueden crear una o más diagramas que representan el nivel más alto de abstracción en el modelo e ir representando cada nivel con diagramas separados.

Una clase captura la estructura y comportamiento común de un conjunto de objetos. Una clase es una abstracción de ítemes del mundo real.

Una clase es una ícono que se representa como una caja, en OMT, la que se divide en tres partes, con el nombre de la clase en la parte superior, la lista de sus atributos en la segunda y la lista de sus operaciones o métod os en la última

GENERALIZACIÓN: Relación entre clases y muestra que la subclase comparte la estructura o comportamiento definida en una o mas superclases. 

ASOCIACIÓN: Representa una conexión semántica entre dos clases. La asociación es bidireccional, es la relación más general y la más débil semánticamente.

AGREGACIÓN: Representa una relación parte todo entre dos clases. Muestra que el objeto agregado está físicamente construido a partir de otro objeto, o que lógicamente lo contiene.

CONCLUSIÓN

Computadora y están en lo cierto para la resolución de problemas mediante algoritmos y diagramas de flujo se ha convertido hoy en día en un instrumento efectivo para el desarrollo de habilidades y destrezas lógicas de y creativas del pensamiento humano.

Hoy diferentes formas de resolver un problema, esto es debido a la forma de razonar del ser humano, al igual que cada algoritmo, o diagrama de flujo de datos elaborado.

El término lógica define la exposición de leyes, modos y formas aplicadas al razonamiento. El ser humano aplica la lógica para la resolución de problemas de diferentes tipos.

Algunos instructores del área de computación no hace mucho hincapié sobre el desarrollo de algoritmo y diagramas de flujo de datos. 

BIBLIOGRAFÍA

Pressman, R. 2010. INGENIERÍA DEL SOFTWARE. Un enfoque práctico. Séptima edición.

CONCLUSIONES

CONCLUSIOSIONES

• Utilización de la ingeniería de software como mecanismo de aplicación y
  evaluación de la eficiencia y calidad operacional de un sistema de función
  crítica, visto como la definición de criterios de operación bajo condiciones
  y límites establecidos por el sistema y por las características externas del
  medio externo. 
  
  
  El modelo planteado en este proyecto pretende establecer unos parámetros
  

  de diseño generales que permitan agilizar la implementación de proyectos 

  tipo sistemas de control por software, cuya base común es el procesamiento 

  de señales digitales en busca de comportamientos de interés 

  caracterización de señales)

  
  
  
  
  
  
  

   

RESUMEN

 

RESUMEN

Un modelo general del proceso para la ingeniería de software incluye un conjunto de actividades estructurales y sombrilla, acciones y tareas de trabajo. Cada uno de los modelos de proceso puede describirse por un flujo distinto del proceso: descripción de cómo se organizan secuencial y cronológicamente las actividades estructurales, acciones y tareas. Los patrones del proceso pueden utilizarse para resolver los problemas comunes que surgen como parte del proceso delsoftware.
Los modelos de proceso prescriptivo se han aplicado durante muchos años en un esfuerzo
por introducir orden y estructura al desarrollo de software. Cada uno de dichos modelos sugiere  un flujo de proceso algo distinto, pero todos llevan a cabo el mismo conjunto de actividades estructurales generales: comunicación, planeación, modelado, construcción y desarrollo.
Los modelos de proceso secuencial, como el de la cascada y en Vantiguos del software. Sugieren un flujo lineal del proceso que con frecuencia no es congruente
con las realidades modernas (cambio continuo, sistemas en evolución, plazos ajustados, etc.)
del mundo del software. Sin embargo, tienen aplicación en situaciones en las que los requerimientos están bien definidos y son estables.

 

MARCO TEORICO

CICLO DE VIDA DEL SOFTWARE

El término ciclo de vida del software describe el desarrollo de software, desde la fase inicial hasta la fase final. El propósito de este programa es definir las distintas fases intermedias que se requieren para validar el desarrollo de la aplicación, es decir, para garantizar que el software cumpla los requisitos para la aplicación y verificación de los procedimientos de desarrollo: se asegura de que los métodos utilizados son apropiados. 

Estos programas se originan en el hecho de que es muy costoso rectificar los errores que se detectan tarde dentro de la fase de implementación. El ciclo de vida permite que los errores se detecten lo antes posible y por lo tanto, permite a los desarrolladores concentrarse en la calidad del software, en los plazos de implementación y en los costos asociados.

Componentes comerciales y reutilización. Generando la riqueza de modelos y sub-modelos de patrones que algunos textos clasifican de forma lineal y agrupada como “modelos de ciclos de vida” 

FLUJO DEL PROCESO

MODELO DE CASCADA

MODELO EN V

 

MODELO INCREMENTAL

PROTOTIPO

ESPIRAL

MODELO DEL PROCESO CONCURRENTE

 PROCESO UNIFICADO

DESARROLLO BASADO EN COMPONENTES

Los componentes comerciales de software general (COTS, por sus siglas en inglés), desarrolla- dos por vendedores que los ofrecen como productos, brindan una funcionalidad que se persigue  con interfaces bien definidas que permiten que el componente se integre en el software que se va a construir. El modelo de desarrollo basado en componentes incorpora muchas de las características del modelo espiral. Es de naturaleza evolutiva [Nie92] y demanda un enfoque iterativo para la creación de software. Sin embargo, el modelo de desarrollo basado en componentes construye aplicaciones a partir de fragmentos de software prefabricados.
Las actividades de modelado y construcción comienzan con la identificación de candidatos
de componentes.

EL MODELO DE METODOS FORMALES

El modelo de métodos formales agrupa actividades que llevan a la especificación matemática formal del software de cómputo. Los métodos formales permiten especificar, desarrollar y verificar un sistema basado en computadora por medio del empleo de una notación matemática rigurosa.
Ciertas organizaciones de desarrollo de software aplican una variante de este enfoque,que se denomina ingeniería de software de quirófano Cuando durante el desarrollo se usan métodos formales , se obtiene un mecanismo
para eliminar muchos de los problemas difíciles de vencer con otros paradigmas de la ingeniería de software.