1.

CONCEPTO 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 ms conocido y documentado del Proceso Unificado es el Proceso Unificado de Rational o simplemente RUP. El Proceso Unificado no es simplemente un proceso, sino un marco de trabajo extensible que puede ser adaptado a organizaciones o proyectos especficos. De la misma forma, el Proceso Unificado de Rational, tambin 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 ciclo de vida del software en el Proceso Unificado

Las fases del ciclo de vida del software son: concepcin, elaboracin, construccin y transicin. y y y y La concepcin: es definir el alcance del proyecto y definir el caso de uso. La elaboracin: es proyectar un plan, definir las caractersticas y cimentar la arquitectura. La construccin: es crear el producto. La transicin: es transferir el producto a sus usuarios

2. DISEO DE SOFTWARE
Segn el diseo de software se realiza a tres niveles: conceptual, lgico y fsico.

 Diseo Conceptual
El diseo conceptual se considera como un anlisis de actividades y consiste en la solucin de negocios para el usuario y se expresa con los casos de uso. El diseo lgico es la solucin del equipo de proyecto del negocio y consiste de las siguientes tareas: y y y y y y Identificar los usuarios y sus roles Obtener datos de los usuarios Evaluar la informacin Documentar los escenarios de uso Validar con los usuarios Validar contra la arquitectura de la empresa

Una forma de obtener estos requerimientos es construir una matriz usuarios-actividades de negocios, realizar entrevistas, encuestas y/o visitas a los usuarios, de tal manera que se obtenga quin, qu, cundo, dnde y por qu de la solucin.

 Diseo Lgico
El diseo lgico traduce los escenarios de uso creados en el diseo conceptual en un conjunto de objetos de negocio y sus servicios. El diseo lgico se convierte en parte en la especificacin funcional que se usa en el diseo fsico. El diseo lgico es independiente de la tecnologa. El diseo lgico refina, organiza y detalla la solucin de negocios y define formalmente las reglas y polticas especficas de negocios.

Un objeto de negocios es la encapsulacin de un servicio que abstrae las cualidades esenciales de algo de inters. Un servicio es una unidad con capacidad de cmputo. Un servicio debe satisfacer lo siguiente:     Ser seguro, lo que equivale a un uso correcto y con autorizacin Ser vlido, qu tareas o reglas se pueden aplicar Manejar excepciones, informando al cliente Contar con un catlogo de servicios que constituye un repositorio de servicios.

Los objetos de negocio deben verificarse y probarse de tal manera que asegure que los mdulos operen como unidades completas de trabajo. Las tareas de verificacin incluyen:  Una verificacin independiente: o Pre y post condiciones o Lgica y funcionalidad individual  Una verificacin dependiente: o Verificacin de dependencias o Que operan como una unidad especfica de trabajo El diseo lgico comprende las siguientes tareas:       Identificar y definir los objetos de negocio y sus servicios Definir las interfases Identificar las dependencias entre objetos Validar contra los escenarios de uso Comparar con la arquitectura de la empresa Revisar y refinar tanto como sea necesario

Para definir los objetos de negocios y sus servicios se puede usar la tcnica de anlisis nombre-verbo de los escenarios de uso. Tambin se puede emplear la tcnica sujeto-verbo-objeto directo. En estas tcnicas los sujetos y el objeto directo son los candidatos a objetos de negocio y los verbos activos son los candidatos a servicios. Una interfase tiene las siguientes partes:      Nombre Precondiciones, lo que debe estar presente antes de ejecutarse Postcondiciones, estado final Capacidad o funcionalidad (SQL, pseudocdigo, funcin matemtica) Dependencias

La tarea de identificar las dependencias entre objetos permite identificar eventos, sucesos o condiciones que permitan la realizacin de tareas de negocios coordinadamente o transaccionalmente. Para ello se debe considerar lo siguiente:        Identificar los eventos disparadores (triggers) Determinar cualquier dependencia (existencial o funcional) Determinar cualquier problema de consistencia o secuencia Identificar cualquier regulacin de tiempo crtica Considerar algn problema organizacional (transacciones) Identificar y auditar los requerimientos de control Determinar lugares y dependencias a travs de la ubicacin

 Determinar cuando el servicio que controla la transaccin es dependiente de los servicios contenidos en otros objetos de negocio La validacin del modelo lgico debe ser tal que ste sea:  Completo debe representar todos los escenarios de uso,  Correcto el comportamiento lgico debe corresponder con el comportamiento conceptual, y  Claro los objetos de negocio y servicios no deben ser ambiguos En el diseo lgico conceptualmente se divide en tres niveles de servicios con el fin de que la aplicacin resulte flexible ante los cambios de requerimientos y/o de tecnologa cambiando nicamente la capa o capas necesarias. Los tres niveles son: servicios de usuario, servicios de negocio y servicios de datos. Los servicios de usuario (userservices) controlan la interaccin. Un servicio de usuario son personas, aplicaciones, otros servicios o la combinacin de stos. Generalmente involucra una interfase grfica de usuario (GUI) o pude ser no visual (mensajes o funciones), maneja todos los aspectos de la interaccin con la aplicacin. El objetivo central es minimizar el esfuerzo de conocimiento requerido para interpretar la informacin. Un servicio de usuario incluye un contenido (qu se necesita comunicar al usuario) y una forma (cmo se comunica el contenido) cuando es necesaria la comunicacin. Los servicios de negocio (bussinesservices) convierten datos recibidos de los servicios de datos y de usuario en informacin (datos + regla de negocio) y pueden usar otros servicios de negocio para completar su tarea. Las tareas de los servicios de negocio son:     Dar formato a los datos Obtener y mover datos desde y hasta los servicios de datos Transformar los datos en informacin Validar los datos inmediatamente en el contexto o en forma diferida una vez terminada la transaccin.

Los servicios de datos (data services) son los servicios de bajo nivel que apoyan los servicios de negocio y son de una amplia gama de categoras como las siguientes:  Declaracin del esquema y su evolucin (estructuras de datos, tipos, acceso indexado, SQL, APIs)  Respaldo y recuperacin (recuperacin de datos si un evento falla)  Bsqueda y Lectura (bsquedas, compilacin, optimizacin y ejecucin de solicitudes, formacin de un conjunto de resultados)  Insercin, actualizacin y borrado (procesar modificaciones consistentemente transaccional). Una transaccin es atmica (ocurre o no), consistente (preserva integridad), aislada (otras transacciones ocurren antes o despus) y durable (una vez completada, sta sobrevive).  Bloqueo (permite al acceso concurrente a los datos)  Validacin de datos (verifica la integridad del dominio, triggers y gateways para verificar el estado de los datos antes de aceptarlos, manejo de errores)  Seguridad (acceso seguro a los objetos, operaciones, permisos a usuario y grupos y servicios)  Administracin de la conexin (mecanismos bsicos para establecer una sesin de los servicios de datos). Establecer una conexin involucra: una identificacin, la colocacin y provisin de datos, tiempo de sesin, el tipo de interaccin (conversacional, transaccional, multiusuario, monousuario).

 Distribucin de datos (Distribuye informacin, a mltiples unidades de recuperacin, bases de datos heterogneas, segn la topologas de la red).

 Diseo fsico
El diseo fsico traduce el diseo lgico en una solucin implementable y costo-efectiva o econmica. El componente es la unidad de construccin elemental del diseo fsico. Las caractersticas de un componente son:      Se define segn cmo interacta con otros Encapsula sus funciones y sus datos Es reusable a travs de las aplicaciones Puede verse como una caja negra Puede contener otros componentes

En el diseo fsico se debe cuidar el nivel de granularidad (un componente puede ser tan grande o tan pequeo segn su funcionalidad, es decir, del tamao tal que pueda proveer de una funcionalidad compleja pero de control genrico) y la agregacin y contencin (un componente puede reusar utilizando tcnicas de agregacin y contencin, sin duplicar cdigo).El diseo fsico debe involucrar:  El diseo para distribucin debe minimizarse la cantidad de datos que pasan como parmetros entre los componentes y stos deben enviarse de manera segura por la red.  El diseo para multitarea debe disearse en trminos de la administracin concurrente de dos o ms tareas distintas por una computadora y el multithreadingo mltiples hilos de un mismo proceso)  El diseo para uso concurrente el desempeo de un componente remoto depende de si est corriendo mientras recibe una solicitud.  El diseo con el manejo de errores y prueba de eventos:  Validando los parmetros- a la entrada antes de continuar con cualquier proceso.  Protegiendo recursos crticos manejar excepciones para evitar la falla o terminacin sin cerrar archivos, liberar objetos sincronizados o memoria.  Protegiendo datos importantes contar con una excepcin a la mitad de la actuacin en las bases de datos.  Debugging crear una versin para limpiar errores.  Proteccin integral de transacciones de negocios los errores deben regresarse al componente que llama. El diseo fsico comprende las siguientes tareas:        Definir los componentes Refinar el empaquetamiento y distribucin de componentes Especificar las interfases de los componentes Distribuir los componentes en la red Distribuir los repositorios fsicos de datos Examinar la tolerancia a fallas y la recuperacin de errores Validar el diseo fsico

De las tareas anteriores la ms importante es la distribucin de los datos que pueden ser centralizados, una particin, un extracto o una rplica.

Los datos centralizados equivalen a una base de datos maestra ubicada en un lugar central. No hay copias de los datos. Una particin de datos es una segmentacin de la base de datos maestra. Es til cuando los datos se pueden fragmentar fcilmente y actualizarse en un sitio local con cambios frecuentes. No hay sobreposicin entre particiones. En una particin horizontal cada hilera existe en una sola base de datos. En una particin vertical cada columna es contenida en una y solo una base de datos. Un extracto de datos es una copia de toda o una porcin de la base de datos maestra. No se permite la actualizacin. Se usa un timestamp o etiqueta de tiempo para indicar qu tan viejos son los datos. Una rplica de datos es un fragmento de la bases de datos maestra que se puede actualizar. Una rplica de datos es cuando el sitio de actualizacin cambia a un sitio local. No se permiten actualizaciones en la base de datos rplica y en la base de datos maestra a la vez, por lo que debe de haber sincronizacin entre ambas. El diseo fsico est ntimamente ligado a una alternativa tecnolgica. Ante la acelerada evolucin tecnolgica es importante considerar los estndares del momento y las tendencias ya que una mala decisin implicar un costo enorme (en dinero y en tiempo) al actualizarse a otra plataforma distinta. La tendencia actual en la arquitectura cliente/servidor es crear el back-end como un servidor robusto multitareas y multithreading y el front-end como un cliente muy delgado que no acapare al servidor comunicndose entre s en una plataforma internet con protocolos estndar en redes heterogneas.

3. CARACTERSTICAS  Iterativo e Incremental

El Proceso Unificado es un marco de desarrollo iterativo e incremental compuesto de cuatro fases denominadas Inicio, Elaboracin, Construccin y Transicin. Cada una de estas fases es a su vez dividida en una serie de iteraciones (la de inicio slo consta de varias iteraciones en proyectos grandes). Estas iteraciones ofrecen como resultado un incremento del producto desarrollado que aade o mejora las funcionalidades del sistema en desarrollo. Cada una de estas iteraciones se divide a su vez en una serie de disciplinas que recuerdan a las definidas en el ciclo de vida clsico o en cascada: Anlisis de requisitos, Diseo, Implementacin y Prueba. Aunque todas las iteraciones suelen incluir trabajo en casi todas las disciplinas, el grado de esfuerzo dentro de cada una de ellas vara a lo largo del proyecto. Diagrama ilustrando como el nfasis relativo en las distintas disciplinas cambia a lo largo del proyecto.

 Dirigido por los casos de uso

En el Proceso Unificado los casos de uso se utilizan para capturar los requisitos funcionales y para definir los contenidos de las iteraciones. La idea es que cada iteracin tome un conjunto de casos de uso o escenarios y desarrolle todo el camino a travs de las distintas disciplinas: diseo, implementacin, prueba, etc. el proceso dirigido por casos de uso es el rup. Nota: en UP se est Dirigido por requisitos y riesgos de acuerdo con el Libro UML 2 de ARLOW, Jim que menciona el tema.

 Centrado en la arquitectura
El Proceso Unificado asume que no existe un modelo nico que cubra todos los aspectos del sistema. Por dicho motivo existen mltiples modelos y vistas que definen la arquitectura de software de un sistema. La analoga con la construccin es clara, cuando construyes un edificio existen diversos planos que incluyen los distintos servicios del mismo: electricidad, fontanera, etc.

 Enfocado en los riesgos

El Proceso Unificado requiere que el equipo del proyecto se centre en identificar los riesgos crticos en una etapa temprana del ciclo de vida. Los resultados de cada iteracin, en especial los de la fase de Elaboracin, deben ser seleccionados en un orden que asegure que los riesgos principales son considerados primero.

4. LENGUAJE UNIFICADO DE MODELADO

El Lenguaje unificado de modelado no es el sucesor de la oleada de mtodos de anlisis y diseo orientados a objetos que surgi a finales de la dcada de los 1980 y principios de la siguiente. El UML unifica, sobre todo, los mtodos de Booch, Rumbaugh, Brhl (OMT) y Jacobson, pero su alcance llegara ser mucho ms amplio. En estos momentos el UML est en pleno proceso de estandarizacin con el OMG (Object Management Group o Grupo de administracin de objetos).

Por qu analizar y disear?

En resumidas cuentas, la cuestin fundamental del desarrollo del software es la escritura del cdigo. Despus de todo, los diagramas son solo imgenes bonitas. Ningn usuario va a agradecer la belleza de los dibujos; lo que el usuario quiere es software que funcione (UML Gota a Gota, Addison Wesley, Pag 7). Por lo tanto, cuando considere usar el UML es importante preguntarse por qu lo har y como le ayudara a usted cuando llegue el momento de escribir el cdigo. No existe una evidencia emprica adecuada que demuestre si estas tcnicas son buenas o malas.

5. VENTAJAS Y DESVENTAJAS DEL PROCESO UNIFICADO

Entre lasventajaspodemos anotar las siguientes: Mediante este proceso de desarrollo de software hay variasoportunidades para revisar el sistema a desarrollar hasta quesea correcto. Se pueden encontrar errores y corregirlos. Adaptabilidad del desarrollo a nuevos requisitos o nuevoscambios. Se define una arquitectura slida en etapas tempranas deldesarrollo. La arquitectura de un sistema se define como unconjunto de componentes y las interacciones entre ellas. Deeste modo este tipo de ciclo de vida debe ser ampliable, por loque el sistema es robusto y tiene facilidad de mantenimiento. Se reducen los riesgos de no obtener el producto deseado. En cada momento hay una versin del sistema funcionandoque se modifica segn las necesidades y deseos del cliente. Progreso visible en las primeras etapas. Reducir la redundancia e incrementa la productividad, unsoftware bien diseado evita la duplicidad del cdigo con locual se obtiene un software robusto. Fcil ejecucin del proceso de elaboracin del sistemasoftware, ya que describen como est estructurado el sistemadesde diferentes perspectivas orientadas a los diferentesinvolucrados en un proyecto.

El proceso es comprensible. La metodologa de PU es ms adaptable para proyectos delargo plazo.

Entre lasdesventajastenemos: El mtodo de PU requiere costos de dedicacin altos por lo queno es conveniente usarlo en procesos de un proyecto pequeo. Si el proceso no se aplica bien desde el inicio el PU se puedevolver muy grande y difcil, tanto para aprender como paraadministrar. Una cantidad sustancial de tiempo se gasta en tratar deadecuar el PU a cada proyecto. Aqu, tambin, se corre elriesgo de volverse un esclavo del proceso y perder de vista larazn del proceso. Es un proceso pesado. Se basa mucho en la documentacin.

6. HERRAMIENTA CASE
Las herramientas CASE (ComputerAidedSoftware Engineering, Ingeniera de Software Asistida por Computadora) son diversas aplicaciones informticas destinadas a aumentar la productividad en el desarrollo de software reduciendo el coste de las mismas en trminos de tiempo y de dinero. Estas herramientas nos pueden ayudar en todos los aspectos del ciclo de vida de desarrollo del software en tareas como el proceso de realizar un diseo del proyecto, clculo de costes, implementacin de parte del cdigo automticamente con el diseo dado, compilacin automtica, documentacin o deteccin de errores entre otras.

 Clasificacin
Aunque no es fcil y no existe una forma nica de clasificarlas, las herramientas CASE se pueden clasificar teniendo en cuenta los siguientes parmetros:     Las plataformas que soportan. Las fases del ciclo de vida del desarrollo de sistemas que cubren. La arquitectura de las aplicaciones que producen. Su funcionalidad.

La siguiente clasificacin es la ms habitual basada en las fases del ciclo de desarrollo que cubren: y y y Upper CASE (U-CASE), herramientas que ayudan en las fases de planificacin, anlisis de requisitos y estrategia del desarrollo, usando, entre otros diagramas UML. Middle CASE (M-CASE), herramientas para automatizar tareas en el anlisis y diseo de la aplicacin. Lower CASE (L-CASE), herramientas que semi-automatizan la generacin de cdigo, crean programas de deteccin de errores, soportan la depuracin de programas y pruebas. Adems automatizan la documentacin completa de la aplicacin. Aqu pueden incluirse las herramientas de Desarrollo rpido de aplicaciones.

Existen otros nombres que se le dan a este tipo de herramientas, y que no es una clasificacin excluyente entre s, ni con la anterior: y Integrated CASE (I-CASE), herramientas que engloban todo el proceso de desarrollo software, desde anlisis hasta implementacin.

y y

MetaCASE, herramientas que permiten la definicin de nuestra propia tcnica de modelado, los elementos permitidos del metamodelo generado se guardan en un repositorio y pueden ser usados por otros analistas, es decir, es como si definiramos nuestro propio UML, con nuestros elementos, restricciones y relaciones posibles. CAST (Computer-Aided Software Testing), herramientas de soporte a la prueba de software. IPSE (IntegratedProgrammingSupportEnvironment), herramientas que soportan todo el ciclo de vida, incluyen componentes para la gestin de proyectos y gestin de la configuracin.

7. LENGUAJE DE PROGRAMACIN
Un lenguaje de programacin es un idioma artificial diseado para expresar computaciones que pueden ser llevadas a cabo por mquinas como las computadoras. Pueden usarse para crear programas que controlen el comportamiento fsico y lgico de una mquina, para expresar algoritmos con precisin, o como modo de comunicacin humana. Tambin la palabra programacin se define como el proceso de creacin de un programa de computadora, mediante la aplicacin de procedimientos lgicos, a travs de los siguientes pasos: y y y y y El desarrollo lgico del programa para resolver un problema en particular. Escritura de la lgica del programa empleando un lenguaje de programacin especfico (codificacin del programa). Ensamblaje o compilacin del programa hasta convertirlo en lenguaje de mquina. Prueba y depuracin del programa. Desarrollo de la documentacin.

8. CONCLUSION
Consideramos que el Proceso Unificado es una metodologa completa y bien documentada. Lo utilizamos como una interesante fuente de ideas y herramientas y con una amplia disponibilidad de formacin tcnica y prctica. Los conceptos anteriormente tratados dirigido por casos de uso, centrado en arquitectura, desarrollo iterativo e incremental son igualmente importantes. La arquitectura provee la estructura sobre la cual guiar el trabajo en iteraciones, mientras que los casos de uso definen las metas y dirigen el trabajo en cada iteracin. Remover cualquiera de estos conceptos reducir severamente el valor del Proceso Unificado. Es como una mesa de tres patas, sin alguna de ellas, la mesa se caer. Siendo que estamos bien entrenados en esta tecnologa es que nos sentimos con la confianza de utilizarla, aumentando as significativamente nuestra probabilidad de xito al adaptar este proceso al futuro proyecto a realizarse en adelante.

9. BIBLIOGRAFA
y y y y y y y y y y y y y y JACOBSON, Ivar; BOOCH, Grady; RUMBAUGH, James. El Proceso Unificado de Desarrollo de Software. Pearson Addisson-Wesley. Ao 2000.. Implementacin Software de NOMINA para la Universidad Tcnica de Machala Universidad Tcnica Particular de Loja15. monografias.com artculo interesante con algo de la historia y gnesis de las herramientas CASE Universidad Jaume I Definicin de glosario, uso en el contexto de bases de datos. Herramientas CASE un directorio de herramientas CASE, bastante til y actualizado, con una wiki y folksonomy sobre herramientas CASE. CASE toolindex- un poco desactualizada pero til UML CASE tools -otra lista muy interesante orientada a herramientas CASE especficas para trabajar con UML. Est un poco desactualizada Herramientas CASE gil Algunos lineamientos tiles para trabajar y seleccionar herramientas CASE de manera gil. [Mark] (2010). O'Reilly Media, Inc. (ed.): LearningPython, FourthEdition (libro). O'Reilly. Consultado el 11 de febrero de 2010 http://www.softwarepreservation.org/projects/FORTRAN/index.html#By_FORTRAN_pr oject_members Wilson, Leslie B. (1993). Comparative Programming Languages, Second Edition.Addison-Wesley. pp. 75. ISBN 0-201-56885-3. (en ingls). Wilson, Leslie B. (1993). Comparative Programming Languages, Second Edition.Addison-Wesley.pp. 213.ISBN 0-201-56885-3. (eningls). Wilson, Leslie B. (1993). Comparative Programming Languages, Second Edition.Addison-Wesley. pp. 244. ISBN 0-201-56885-3. (en ingls).

INDICE
1. CONCEPTO PROCESO UNIFICADO  El ciclo de vida del software en el Proceso Unificado
y y y La concepcin La elaboracin La construccin La transicin

2. DISEO DE SOFTWARE  Diseo Conceptual  Diseo Lgico  Diseo fsico 3. CARACTERSTICAS  Iterativo e Incremental  Dirigido por los casos de uso  Centrado en la arquitectura  Enfocado en los riesgos 4. LENGUAJE UNIFICADO DE MODELADO Por qu analizar y disear?

5. VENTAJAS Y DESVENTAJAS DEL PROCESO UNIFICADO 6. HERRAMIENTA CASE  Clasificacin 7. LENGUAJE DE PROGRAMACIN 8. CONCLUSION 9. BIBLIOGRAFA

AO DEL CENTENARIO DE MACHU PICCHO PARA EL MUNDO

DOCENTE: KARINA CACHAY PANDURO

CURSO: INGENIERIA DE SISTEMASII

TEMA: PROCESO UNIFICADO

CICLO: IV

AUTORES: TATIANA RAMIREZ SOLIS

TARAPOTO-PERU 2011