DIAPOSITIVAS DE INGENIERIA DE SOFTWARE INCISOS
by ALFJZ in DOCUMENTOS IMPORTANTES , m 0
} ADMINISTRACION Y CONFIGURACION DE CAMBIOS
} MANEJO DE CAMBIOS Y CONFIGUARACIONES
} Su objetivo es controlar los cambios y rastreas y mantener la integridad de los artefactos de un proyecto.
} El control de cambio permite mantener la integridad de todos los artefactos que se crean en el proceso y métodos. As como de mantener información del proceso evolutivo que han seguido.
} MANEJO DE SOLICITUDES DE CAMBIO (CRM)
} Captura y administra los cambios por involucrados
} Analiza el impacto de los cambios
} Realiza el seguimiento de los cambios hasta que se completan
} define la infraestructura organizacional necesaria para evaluar el impacto de una solicitud de cambio en la planificación (costo, tiempo, recursos..))
} MANEJO DE SOLICITUDES DE CAMBIO (CRM)
Incluye:
} Identificar y mantener de los elementos de una configuración
} Controlar los cambios(restringir, rastrear y auditar los cambios sobre los elementos)
} Definir u administrar las configuraciones de estos elementos
} Permitir la selección de versiones
} Permitir la manufactura de software
} Manejar espacios de trabajo
} ADMINISTRACION DE CONFIGURACIONES (CM)
Permite la identificación de :
} artefactos, versiones, dependencias entre artefactos y los elementos interrelacionados que constituyen una configuración
} Espacios de trabajo que permitan a los equipos trabajar en forma coordinada
} ADMINISTRACION DE CONFIGURACIONES (CM)
CM se enfoca en:
} describir la estructura del producto
} Identificar los elementos versionables que son tratados como simples en el proceso de manejo de configuraciones
} definir las configuraciones
} construir, recolectar u etiquetar artefactos versionados en conjunto constituyentes, manteniendo la rastreabilidad entre versiones
} MEDIDAS
Las medidas proporcionan información útil para la gerencia del proyecto:
} Estado del producto
} Grado de avance
} Estado de las entregas
} Áreas criticas
} PLAN DE CONFIGURACION Y CONTROL DE CAMBIOS DEL PROYECTO
propósito.:
} Las políticas de manejo de configuraciones (CM) se utilizan para monitorear y proteger los activos del proyecto y reforzar las practicas de desarrollo.
} Las políticas pueden manejar la comunicación entre los miembros del equipo de desarrollo y minimizar los problemas encontrados cuando se integran sus trabajos
} ACTIVIDADES
} Definir las practicas de identificación de configuraciones
} Definir las practicas de línea base
} Definir las practicas de archivo
} Definir los requerimientos de reportes del estado de la configuraciones
} LINEA BASE
Una línea base es un concepto de gestión de configuración del software que nos ayuda a controlar los cambios sin impedir seriamente los cambios justificados.
} Provee un punto estable, una foto de los artefactos del sistema en un momento dado
} Conjunto de versiones establecida de archivos y directorios creados al alcanzar ciertos hitos en el desarrollo de un proyecto
} LINEA BASE
} Provee un estándar a partir del cual se realizaran los cambios correspondientes a solicitudes de cambio aprobadas
Permiten:
} Reproducir
} Trazar
} Reportar
} VANTAJAS DE LAS LINEAS BASE
} A partir de una línea base pueden desarrollarse nuevos proyectos, que puedan evolucionar de forma independiente de los cambios que puedan producirse sobre el sistema original.
} Los desarrolladores pueden tomar componentes de la línea base para actualizar sus espacios de trabajo
} Las líneas base proveen una vía para el equipo deshaga cambios que consideren inestables o sospechosos
} DEFINIR LAS PRACTICAS DE ARCHIVO
El propósito de este paso es asegurar que el software y los documentos maestros del proyecto han sido obtenidos, catalogados y transferidos al espacio de almacenamiento designados para ello.
FLUJO DE TRABAJO
En las primeras iteraciones del proyecto, se da inicio al flujo de trabajo preparando el ambiente para el proyecto. Las actividades relacionadas desarrollarán el proceso específico para el proyecto. Entonces, se hacen ajustes al ambiente del proyecto según sea necesario para cada iteración
PREPARAR AMBIENTE PARA EL PROYECTO
El propósito de esta actividad es convertir el proceso de desarrollo general en un proceso específico para el proyecto y tener disponible el ambiente de herramientas listo para realizar el proyecto.:
Definir como el proyecto va a usar el proceso de desarrollo configurado.
ü Desarrollar un Caso de desarrollo que describa las desviaciones con respecto al proceso base.
ü Cualificar los artefactos en términos de los requerimientos de tiempo y formalidad.
ü Preparar los acuerdos específicos para el proyecto, como guías y templates de acuerdo con el caso de desarrollo.
ü Producir una lista de las herramientas candidatas para usarse en el desarrollo.
DAR SOPORTE AL AMBIENTE DURANTE LA ITERACION
El propósito de esta actividad es dar soporte a los desarrolladores en el uso de las herramientas y procesos durante una iteración. Dar soporte al ambiente de un proyecto es una actividad en curso que permite a los miembros de un proyecto hacer su trabajo eficientemente sin verse frenados debido a detalles con el ambiente de desarrollo. Esto incluye la instalación del software requerido, asegurar que el hardware funciona correctamente y que problemas potenciales de la red son resueltos sin retrasos
ANALISIS
Durante el análisis, analizamos los requisitos que se describieron en la captura de requisitos, refinándolos y estructurándolos. El objetivo de hacerlo es conseguir una comprensión más precisa de los requisitos y una descripción de l os mismos que sea fácil de mantener y que nos ayude a estructurar el sistema entero, incluyendo su arquitectura.
IMPORTANCIA
Analizar los requisitos en la forma de un modelo de análisis es importante por varios motivos:
Un modelo de análisis ofrece una especificación más precisa de los requisitos que la que tenemos como resultado de la captura de requisitos, incluyendo al modelo de casos de uso.
Un modelo de análisis se describe utilizando el lenguaje de los desarrolladores, y se puede por tanto introducir un mayor formalismo y ser utilizado para razonar sobre los funcionamientos internos del sistema.
Un modelo de análisis estructura los requisitos de un modo que facilita su comprensión, su preparación, su modificación, y en general, su mantenimiento.
Un modelo de análisis puede considerarse como una primera aproximación al modelo de diseño (aunque es un modelo por sí mismo), y es por tanto una entrada fundamental cuando se da forma al sistema en el diseño y en la implementación.
ARTEFACTOS
Compuesto por un sistema de análisis que es el paquete de más alto nivel , el cual se compone a su vez de otros paquetes y clases de análisis y realizaciones de casos de
uso.
Clase del análisis
Se centra en el tratamiento de requisitos funcionales y pospone los no funcionales para el diseño.
Es más “conceptual”.
Raramente define una interfaz en términos de operaciones y sus signaturas. Su comportamiento se define mediante “responsabilidades” en un nivel más alto y menos formal. Una responsabilidad es una descripción textual de un conjunto cohesivo del comportamiento de una clase.
Define atributos en un nivel también conceptual y reconocibles en el dominio del problema, mientras que en el diseño l os atributos se ajustan a tipos del lenguaje de programación.
Las relaciones entre clases del análisis también son más conceptual es. Por ejemplo no se da importancia a l a navegación de l a relación.
Las cl ases de análisis siempre encajan en alguno de los estereotipos básicos: de interfaz, de control , o entidad.
REALIZACION CASO DE USO ANALISIS
Una realización de caso de uso – análisis es una colaboración dentro del modelo de análisis que describe cómo se lleva a cabo y se ejecuta un caso de uso determinado en términos de las clases del análisis y sus objetos del análisis en interacción.
Una realización de caso de uso análisis posee una descripción textual del flujo de sucesos, diagramas de cl ases participantes, y diagramas de interacción que muestran la realización de un flujo o escenario particular del caso de uso en término de objetos del análisis.
PAQUETE DEL ANALISIS
Los paquetes del análisis proporcionan un medio para organizar los artefactos del modelo de análisis en piezas manejables. Un paquete de análisis puede constar de clases de análisis, de realizaciones de casos de uso, y de otros paquetes del análisis recursivamente.
Los paquetes del análisis son particionamientos funcional s del sistema basados en el dominio del problema y debería ser reconocibles por las personas con conocimiento del dominio.
Los paquetes del análisis probablemente se convertirán en subsistemas en las dos capas de aplicación superiores del modelo de diseño, o se distribuirán entre ellos.
DESCRIPCION DE LA ARQUITECTURA
se consideran significativos para la arquitectura:
Descomposición del modelo de análisis en paquetes de análisis y sus dependencias. Esta descomposición suele tener su efecto en los subsistemas de las capas superiores durante el di seño e implementación.
Las clases fundamentales del análisis.
Realizaciones de casos de uso que describen funcionalidades importantes y críticas, probablemente l as correspondientes a los casos de uso que aparecen en l a vista de l a arquitectura del modelo de casos de uso.
APLICACIONES DE LA METODOLOGIA RUP
ž Aplicaciones de la Metodología RUP
ž *Es la mas adaptable para procesos de largo plazo.
ž 1.En el Ámbito Empresarial
ž Permite explicar procesos que se dan dentro de los departamentos existentes en la empresa.
ž DESARROLLO DE LA METODOLOGÍA PARA LA IMPLANTACIÓN DEL AXIONAL ERP
ž Obtener una metodología para obtener productos software.
ž Optimizar el tiempo y el coste invertidos.
ž 2.En el Ámbito Educativo
ž Determina y evalúa la calidad del software educativo permitiendo que se realicen proyectos adecuados en el ámbito virtual de aprendizaje.
ž ANALISIS, DISEÑO E IMPLEMENTACION DE UNA HERRAMIENTA WEB DE EVALUACION DE DESEMPEÑO POR COMPETENCIAS
ž Es adaptable al contexto, alcance y desarrollo del proyecto.
ž Fase de concepción
ž Se realizaron actividades del modelo de negocio, el alcance del sistema y la captura de requerimiento.
ž Fase de elaboración
ž el interés estuvo puesto en la especificación de requisitos análisis y diseño del sistema.
ž Fase de construcción
ž Se llevo acabo la programación y ejecución del plan de pruebas.
PROCESO ITERATIVO E INCREMENTAL
ELIZABETH RAMIREZ MENDOZA
JOSE LUIS MARTINEZ ARRIETA
Desarrollo en pequeños pasos:
La tercera clave importante del RUP consiste en desarrollar un producto software en pasos pequeños manejables:
Planificar un poco.
Especificar, diseñar, e implementar un poco.
Integrar, probar, y ejecutar un poco en cada iteración.
¿Por qué un desarrollo iterativo e incremental?
vPara tomar las riendas de los riesgos críticos y significativos desde el principio.
v Para poner en marcha una arquitectura que guíe el desarrollo del software.
v Para proporcionar un marco de trabajo que gestione de mejor forma los inevitables cambios en los requisitos y en otros aspectos.
vPara construir el sistema a lo largo del tiempo en lugar de hacerlo de una sola vez cerca del final, cuando el cambiar algo se ha vuelto costoso.
v Para proporcionar un proceso de desarrollo a través del cual el personal puede trabajar de manera más eficaz.
LA ITERACIÓN GENÉRICA:
Una iteración es un mini proyecto.
Inicio
Elaboración
Construcción
Transición
GRACIAS!!
} FLUJO DE DESPLIEGUE
} Karina Ríos Mora
} Luis Felipe Calderón
} Universidad Popular Del Cesar
} DESPLIEGUE
Este tiene como objetivo producir con éxito distribuciones del producto y distribuirlo a los usuarios. Las actividades implicadas incluyen:
-*- Probar el producto en su entorno de ejecución final.
-*-Empaquetar el software para su distribución.
-*-Distribuir el software.
-*-Instalar el software.
-*Proveer asistencia y ayuda a los usuarios.
-*-Formar a los usuarios y al cuerpo de ventas.
-*-Migrar el software existente o convertir bases de datos.
Este Flujo de trabajo se desarrolla con mayor intensidad en la fase de transición, ya que el propósito del flujo es asegurar una aceptación y adaptación sin complicaciones del software por parte de los usuarios.
Una vez que el producto de software ha sido implementado y probado exitosamente, es momento de llevar el producto al cliente. El propósito es producir releases del producto y llevar el software a los usuarios finales.
Una vez que el producto de software ha sido implementado y probado exitosamente, es momento de llevar el producto al cliente. El propósito es producir releases del producto y llevar el software a los usuarios finales.
} VISTA GENERAL DEL FLUJO DE TRABAJO
Implica probar el software en su ambiente operacional final, empacar el software para la entrega, distribuir el software, instalar el software, entrenar a los usuarios finales y convertirlas bases de datos anteriores para la carga de datos. Hay tres maneras de proveer del producto al usuario final:
Ø LA INSTALACIÓN EN EL CLIENTE: Se entrega un “instalador” (generado con algún producto de compresión e instalación)
Ø ACCESAR AL SOFTWARE POR LA INTERNET: Cualquiera que sea el método escogido para entregar al cliente, la prueba del producto ocurre en el site de desarrollo seguido por la prueba Beta y finalmente liberando el producto al cliente. El flujo de trabajo de Despliegue está relacionado a otros del RUP, como sigue: Planificar el Despliegue
Ø DESARROLLAR MATERIAL DE SOPORTE: Produce el material de soporte, el cual incluye instrucciones para instalación, operación y mantenimiento para el sistema desplegado. También incluye el material de entrenamiento para las diversas posiciones requeridas para usar el sistema efectivamente.
§ Manejar las Pruebas de Aceptación
§ Producir la Unidad de Despliegue
§ Empaquetar el Producto
§ Proveer Acceso al Site de Descarga
§ Producto en Beta
} REPORTES PARA LAS PRUEBAS
Ø Configuración y Notas sobre el Workflow de Despliegue: Las organizaciones grandes pueden empacar el producto y dar acceso a un sito de descarga; sin embargo, la mayoría no necesita efectuar estos flujos de trabajo de detalle.
Ø Artefactos para el Despliegue: Los artefactos de Despliegue capturan y presentan información relativa a posicionar el sistema, presentado en el flujo de trabajo de Implementación, dentro del ambiente de producción.
Ø Reportes para el Despliegue: Ningún reporte será producido durante el flujo de trabajo de Despliegue. Los artefactos producen la necesaria información.
GRACIAS POR SU ATENCIÓN
šimplementación
En la implementación empezamos con el resultado del diseño e implementamos el sistema en término de componentes, es decir, ficheros de código fuente, scripts, ficheros de código binario, ejecutables, y similares.
šTRABAJADORES Y ARTEFACTOS
šARTEFACTOS
šArtefacto:
Modelo de Implementación
Modelo de Implementación
El modelo de diseño es un modelo de objetos que describe la realización física de los elementos del modelo de diseño.
šArtefacto:
Componente
Componente
Un componente es el empaquetamiento físico de los elementos de un modelo, como son las clases en el modelo de diseño. Algunos estereotipos típicos son:
<<executable>> programa ejecutable en un nodo
<<file>> fichero que contiene código fuente o datos
<<library>> librería estática o dinámica
<<table>> es una tabla de base de datos
<<document>> es un documento
šStubs
Un Stub es un componente con una implementación esquelética o de propósito especial que puede ser utilizado para desarrollar o probar otro componente que depende del stub.
šArtefacto:
Subsistema de Implementación
Subsistema de Implementación
Los subsistemas de implementación proporcionan una forma de organizar los artefactos del modelo de implementación en trozos más manejables.
Un subsistema de implementación se manifiesta a través de un mecanismo de empaquetamiento concreto en un entorno de implementación determinado, como:
- Un paquete en Java
- Un proyecto en VB.
- Un directorio de ficheros en un proyecto de C++
- Un paquete en una herramienta de modelado como Rational Rose.
šArtefacto:
Interfaz
Interfaz
En el modelo de implementación las interfaces pueden ser utilizadas para especificar las operaciones implementadas por componentes y subsistemas de implementación.
šARTEFACTO:
DESCRIPCIÓN DE LA ARQUITECTURA
DESCRIPCIÓN DE LA ARQUITECTURA
La descripción de la arquitectura tiene la visión de la arquitectura del modelo de implementación.
Los siguientes artefactos son considerados arquitectónicamente significativos:
- Descomposición del modelo de implementación en subsistemas, sus interfaces, y dependencias entre ellos.
- Componentes clave que siguen la traza de las clases de diseño significativas arquitectónicamente.
šArtefacto:
Plan de Integración
Plan de Integración
El sistema se desarrolla incrementalmente a pasos manejables. Cada paso de construcción debe ser sometido a pruebas de integración.
Para prepararse ante el fallo de una construcción se lleva un control de versiones para poder volver atrás a una construcción anterior.
šTRABAJADORES
šTrabajador:
Arquitecto
Arquitecto
Durante la fase de implementación, el arquitecto es responsable de la integridad del modelo de implementación y asegura que el modelo como un todo es correcto, completo, y legible.
šTrabajador:
Ingeniero de Componentes
Ingeniero de Componentes
Define y mantiene el código fuente de uno o varios componentes, garantizando que el componente implementa la funcionalidad correcta.
šTrabajador:
Integrador de Sistemas
Integrador de Sistemas
Es responsable del plan de integración de construcciones.
šFlujo de Trabajo
šActividad:
Implementación de la Arquitectura
Implementación de la Arquitectura
El propósito de la implementación de la arquitectura es exlicar el modelo de implementación y su arquitectura mediante:
vIdentificación de componentes significativos arquitectónicamente tales como componentes ejecutables.
vLa asignación de componentes a los nodos en las configuraciones de redes relevantes.
šActividad:
Integrar el Sistema
Integrar el Sistema
Los objetivos de la integración son:
šCrear un plan de integración de construcciones
šIntegrar cada construcción antes de que sea sometida a pruebas de integración.
šActividad:
Implementar un Subsistema
Implementar un Subsistema
El propósito de implementar un subsistema es el de asegurar que un subsistema cumpla su papel en cada construcción.
šActividad:
Realizar prueba de unidad
Realizar prueba de unidad
El propósito de realizar la prueba de unidad es probar los componentes implementados como unidades individuales. Existen dos tipos de prueba:
šPrueba de especificación, o prueba de “caja negra”, que verifica el comportamiento de la unidad observable externamente.
šPrueba de estructura o prueba de “caja blanca”, que verifica la implementación interna de la unidad.
šActividad:
Implementar una Clase
Implementar una Clase
El propósito de implementar una clase es implementar una clase de diseño en un componente fichero. Esto incluye:
šEsbozo de un componente fichero que contendrá el código.
šGeneración del código fuente a partir de la clase de diseño y de las relaciones en que participa.
šImplementación de las operaciones de la clase de diseño en forma de métodos.
šComprobación de que el componente proporciona las mismas interfaces que la clase de diseño.
UN PROCESO CENTRADO EN LA ARQUITECTURA
INTEGRANTES:
JESSICA DURANTES
JHONATAN VEGA
IMPORTANCIA Y NECESIDAD DE UNA ARQUITECTURA
Ø Comprender el sistema
Ø Organizar el desarrollo
Ø Fomentar la reutilización
Ø Hacer evolucionar el sistema
DESARROLLO DE LA ARQUITECTURA
La arquitectura se desarrolla mediante iteraciones, principalmente en la etapa de elaboración.
la línea base de la arquitectura: un esqueleto del sistema con pocos músculos de software.
DESCRIPCIÓN DE LA ARQUITECTURA
La línea base de la arquitectura, es la versión interna del sistema al final de la fase de elaboración.
El papel de la descripción de la arquitectura es guiar al equipo de desarrollo a través del ciclo de vida del sistema.
La descripción de la arquitectura puede adoptar diferentes formas.
SECCIONES DE LA ARQUITECTURA
• vista del modelo de casos de uso
• una vista del modelo de diseño
• una vista del modelo de despliegue
• una vista del modelo de implementación
LA VISTA DE LA ARQUITECTURA DEL MODELO DE CASOS DE USO
Presenta los actores y casos de uso más Importantes.
LA VISTA DE LA ARQUITECTURA DEL MODELO DE DISEÑO
Presenta los clasificadores más importantes para la arquitectura pertenecientes al modelo de diseño.
LA VISTA DE LA ARQUITECTURA DEL MODELO DE DESPLIEGUE
Presenta los nodos interconectados y las clases activas que se ejecutan en ellos identificados durante el diseño.
LA VISTA DE LA ARQUITECTURA DEL MODELO DE IMPLEMENTACIÓN
El modelo de implementación es una correspondencia directa de los modelos de diseño y de despliegue.
INGENIERIA DE SOFTWARE
— objetivos
— Planificar las pruebas necesarias en cada iteración, incluyendo las pruebas de integración y las pruebas de sistema.
— Diseñar e implementar pruebas creando los casos de prueba (especifican qué probar), procedimientos de prueba (especifican cómo realizar las pruebas), creando componentes de prueba para automatizar las pruebas.
— Realizar las pruebas.
— Trabajadores y Artefactos
— Artefactos
— Artefacto: Modelo de pruebas Describe como se prueban los componentes en el modelo de implementación. El modelo de pruebas es una colección de casos de prueba, procedimientos de prueba, y componentes de prueba.
— Artefacto: Caso de prueba Un caso de prueba especifica una forma de probar el sistema, incluyendo la entrada o resultado con la que se ha de probar y las condiciones bajo las que ha de probarse.
— Artefacto: Procedimiento de prueba Un procedimiento de prueba especifica cómo realizar uno o varios casos de prueba o partes de estos.
— Artefacto: Defecto Un defecto es una anomalía del sistema. Un defecto puede ser utilizado para localizar cualquier cosa que los desarrolladores necesitan registrar como síntoma de un problema.
— Artefacto: Evaluación de prueba Una evaluación de prueba es una evaluación de los resultados de la prueba.
— TRABAJADORES
— Trabajador: diseñador de pruebas Un diseñador de pruebas es responsable de la integridad del modelo de pruebas, asegurando que el modelo cumple con su propósito. Planean las pruebas. Seleccionan y describen los casos de prueba y procedimientos de prueba.
— Trabajador: ingeniero de componentes Son responsables de los componentes de prueba que automatizan algunos de los procedimientos de prueba.
— Trabajador: ingeniero de pruebas de sistema Un ingeniero de pruebas de sistema es responsable de realizar las pruebas de sistema necesarias sobre una construcción que muestra el resultado de una iteración completa. Las pruebas de sistema se llevan a cabo para verificar interacciones entre los actores y el sistema.
— FLUJO DE TRABAJOS
— FLUJO DE TRABAJO
— Actividad: planificar prueba
— Actividad: diseñar la prueba
— Actividad: implementar la prueba
— Actividad: realizar prueba del sistema
— Actividad: evaluar la prueba
Un proceso conducido por casos de Uso
INTEGRANTES:
Romario roca ESCORCIA
Yeraldine Fernández Rincones
El Modelo de Caso de Usos representa los requisitos funcionales
El objetivo de
esta fase es determinar los requerimientos del sistema. Los requerimientos funcionales
son plasmados a través de casos de uso en un Modelo de Casos de Uso.
Creación del modelo de análisis a partir de los casos de uso
El modelo del análisis es opcional. En él, se describen un conjunto de Clases del
Análisis que se utilizan para realizar una descripción abstracta de la realización de los
casos de uso del modelo de casos de uso. Las clases del análisis luego evolucionan
hacia otras clases más detalladas en el Modelo del Diseño.
Durante el Análisis se utilizan diagramas de colaboraciónpara describir la
realización de un caso de uso.
Creación del modelo de diseño a partir del modelo de análisis
El modelo de diseño se crea tomando el modelo de análisis como entrada principal
(cuando este fue creado), y se lo adapta a un entorno de implementación particular.
Esta adaptación incluye considerar por Ej. adecuaciones a un framework de
construcción de GUI particular, uso de un ORB, frameworks, sistemas heredados, etc.
Diagrama de secuencia para representar la realización del caso de uso Sacar
Dinero en el modelo de diseño.
Agrupación de clases en subsistemas
Es imposible utilizar sólo clases para realizar los casos de uso en un sistema grande
con cientos o miles de clases. Es imposible comprender el sistema sin una
organización de más alto nivel. Las clases se agrupan en subsistemas.
Creación del modelo de implementación a partir del modelo de diseño
El modelo de implementación está formado por componentes, que incluyen todos los
ejecutables (Ej. ActiveX, JavaBeans, .exe), y otro tipo de componentes como ser
componentes de fichero (código fuente, shell scripts, etc.), componentes de tabla
(elementos de base de datos), etc.
Prueba de casos de uso
Durante la prueba, verificamos que el sistema implementa correctamente su
especificación.
El modelo de prueba está compuesto por: casos de prueba y procedimientos de
prueba.
Un procedimiento de prueba es una especificación de cómo llevar a cabo la
preparación, ejecución, y evaluación de los resultados de un caso de prueba particular.
›RUP
›JORGE PERTUZ EGEA
›YEINER MERIÑO RESTREPO
›Visión General del Proceso Unificado
›El Proceso Unificado es un proceso de desarrollo de software: “conjunto de actividades necesarias para transformar los requisitos del usuario en un sistema software”.
RUP es un marco genérico que puede especializarse para una variedad de
tipos de sistemas, diferentes áreas de aplicación, tipos de organizaciones,
niveles de aptitud y diferentes tamaños de proyectos.
RUP está basado en componentes. El sw esta formado por componentes
software interconectados a través de interfaces.
RUP está dirigido por casos de uso, centrado en la arquitectura, y es iterativo e incremental.
›Casos de Uso
Un caso de uso es un fragmento de funcionalidad del sistema que proporciona
un resultado de valor a un usuario. Los casos de uso modelan los
requerimientos funcionales del sistema.
Los casos de uso también guían el proceso de desarrollo (diseño, impementación, y prueba).
›Centrado en la Arquitectura
›La arquitectura de un sistema software se describe mediante diferentes vistas del
›sistema en construcción.
›El concepto de arquitectura software incluye los aspectos estáticos y dinámicos más
›significativos del sistema.
›La arquitectura es una vista del diseño completo con las características más
›importantes resaltadas, dejando los detalles de lado.
›Arquitectura:
Conjunto de decisiones significativas acerca de la organización de un sistema software, la selección de los elementos estructurales a partir de los cuales se compone el sistema, las interfaces entre ellos, su comportamiento, sus colaboraciones, y su composición.
›Iterativo e Incremental
Es práctico dividir el esfuerzo de desarrollo de un proyecto d e software en partes mas pequeñas o mini proyectos. Cada mini proyecto es una iteración que resulta en un incremento. Las iteraciones hace referencia a pasos en el flujo de trabajo, y los incrementos a crecimientos en el producto.
›Beneficios del enfoque iterativo
q- La iteración controlada reduce el riesgo a los costes de un solo incremento.
q- Reduce el riesgo de retrasos en el calendario atacando los riesgos mas importantes
q- Acelera el desarrollo. Los trabajadores trabajan de manera más eficiente al obtener resultados a corto plazo.
q- Tiene un enfoque más realista al reconocer que los requisitos no pueden definirse
qcompletamente al principio.
›El Ciclo de Vida del Proceso Unificado
›El Proceso Unificado se repite a lo largo de una serie de ciclos que constituyen la vida de un sistema. Cada ciclo constituye una versión del sistema.
›FASES
›Cada ciclo constas de cuatro fases: inicio, elaboración, construcción, y transición.
›Disciplinas
Cada disciplina es un conjunto de actividades relacionadas (flujos de trabajo)
vinculadas a un área específica dentro del proyecto total. Las más importantes son:
Requerimientos, Análisis, Diseño, Codificación, y Prueba.
El agrupamiento de actividades en disciplinas es principalmente una ayuda para
comprender el proyecto desde la visión tradicional en cascada.
›Fase de Inicio
Durante la fase de inicio se desarrolla una descripción del producto final, y se presenta el análisis del negocio. Esta fase responde las siguientes preguntas:
›¿Cuáles son las principales funciones del sistema para los usuarios mas importantes?
›¿Cómo podría ser la mejor arquitectura del sistema?
›¿Cuál es el plan del proyecto y cuanto costará desarrollar el producto?
›En esta fase se identifican y priorizan los riesgos mas importantes.
›Fase de Elaboración
Durante la fase de elaboración se especifican en detalle la mayoría de los casos de
uso del producto y se diseña la arquitectura.
Las iteraciones en la fase de elaboración:
q- Establecen una firme comprensión del problema a solucionar.
q- Establece la fundación arquitectural para el software.
q- Establece un plan detallado para las siguientes iteraciones.
q- Elimina los mayores riesgos.
›Fase de Construcción
Durante la fase de construcción se crea el producto. La línea base de la arquitectura
crece hasta convertirse en el sistema Completo. Al final de esta fase, el producto contiene todos los casos de uso implementados, sin embargo puede que no este libre de defectos. Los artefactos producidos durante esta fase son:
qEl sistema software
q- Los casos de prueba
q- Los manuales de usuario
›Fase de Transición
qLa fase de transición cubre el período durante el cual el producto se convierte en la versión beta. Las iteraciones en esta fase continúan agregando características al sw. Sin embargo las características se agregan a un sistema que el usuario se encuentra utilizando activamente.
