Metodologia Rup

Universidad Nacional de Trujillo
DEFINICIN DE METODOLOGIA Metodologa es una forma explcita de estructurar el pensamiento y las acciones. Las metodologas contienen modelos y reflejan perspectivas particulares de la realidad basndose en un conjunto de paradigmas filosficos. Una metodologa debera sealarnos qu pasos tomar y cmo llevarlos a cabo, pero ms importante es definir las razones del por qu esos pasos se deben tomar en ese orden.
Metodologia e Ingenieria del Software
Ing. Arturo Diaz Pulido
METODOLOGA EMPLEADA
Esta metodologa (Proceso Unificado de Desarrollo de Software) conlleva a desarrollar un producto de software de una arquitectura consistente, til y con una documentacin tcnica.
REFERENCIAS DEL PROCESO UNIFICADO DE DESARROLLO DE SOFTWARE

DEFINICIN El Proceso Unificado de Desarrollo de Software (USDP Unified Software Development Process) es un conjunto de tareas que permiten transformar los requerimientos de los usuarios en un sistema de software. Sin embargo el Proceso Unificado es ms que un proceso nico, es un proceso con un marco referencial genrico que puede ser especializado para una variedad de clases de sistemas software, para diferentes reas de aplicacin, diferentes tipos de organizaciones, diferentes niveles de competencia y diferentes tamaos de proyectos.
Requerimientos de Usuario
Proceso de Desarrollo de Software

Un Proceso de Desarrollo de Software
Sistema de Software
El Proceso Unificado utiliza UML (Lenguaje Unificado de Modelado) cuando se especifica formalmente un proyecto de software.
ENFOQUE METODOLGICO Los aspectos que distinguen al Proceso Unificado estn definidos en tres frases o conceptos clave: Orientado a Casos de Uso (Uses Cases). Enfocado en la Arquitectura. Desarrollo Iterativo e Incremental. Esto es lo que hace que el Proceso Unificado sea nico y haga evidente hacia donde va encaminado. A continuacin abordamos cada uno de estos aspectos:
Orientado a Casos de Uso Para la construccin de un sistema exitoso nosotros debemos conocer que es lo que desean o necesitan los usuarios, por ello debemos utilizar una estrategia que fuerce a pensar en trminos de valor para el usuario y no simplemente en una especificacin funcional que puede ser vista como la respuesta a la pregunta: Qu es lo que se supone que hace el sistema?. La estrategia de casos de uso (uses cases) extiende la interrogante agregndole tres palabras: para cada usuario, de esta manera los casos de uso se convierten en piezas de
funcionalidad del sistema que dan a los usuarios un resultado valioso. Sin embargo, los casos de uso no son slo una herramienta para especificar los requerimientos de un sistema. Ellos tambin orientan su diseo, implementacin y prueba. Es decir, dirigen el proceso de desarrollo.
Enfocado en la Arquitectura.
El rol de la arquitectura del software es similar al rol que juega la arquitectura en la construccin de un edificio. El edificio es estudiado desde varios puntos de vista: estructura, servicios, calefaccin, electricidad, etc. De igual forma, la arquitectura de un sistema software puede ser descrita bajo diferentes puntos de vista. El concepto de arquitectura del software encierra los aspectos de mayor significado esttico y dinmico del sistema. Adems, debe ajustarse a las exigencias de los usuarios, es decir debe ser un fiel reflejo de los casos de uso. Sin embargo, tambin se ve influenciado por muchos otros factores tales como: la plataforma sobre la que el software se ha de ejecutar (arquitectura de la computadora, sistema operativo, sistema administrador de base de datos, protocolos de red, etc).
La arquitectura y los casos de uso no se excluyen mutuamente ya que todo producto software tiene funcin y forma. Estas dos fuerzas deben estar balanceadas. En este caso la funcin es a los casos de uso como la forma es a la arquitectura. En consecuencia a medida que los casos de uso van madurando, la arquitectura va siendo descubierta, este proceso continuar hasta que la arquitectura se considere estable.
Desarrollo Iterativo e Incremental. El proceso de desarrollo de un sistema software puede llevar varios meses e incluso aos de acuerdo al tamao y funcionalidad del mismo si su desarrollo no es planificado correctamente. Para subsanar lo anterior es preciso dividir el
trabajo en partes ms pequeas o mini proyectos. De esta manera cada mini proyecto es una iteracin que resulta en un incremento. Para ser mas efectivos, las iteraciones deben ser controladas; es decir deben ser seleccionadas y llevadas a una forma de plan.
Para ello las primeras iteraciones a seleccionar y realizar han de basarse en casos de uso considerados como crticos, claves o que extienden en gran medida la funcionalidad del sistema. Cada iteracin o mini proyecto comprender la realizacin de los casos de uso a travs de etapas como las de anlisis, diseo, implementacin y prueba. Por supuesto que un incremento no es necesariamente aditivo, especialmente en las primeras fases del ciclo de vida, as los desarrolladores pueden reemplazar un anlisis o diseo superficial con uno ms detallado o sofisticado; lo aditivo del incremento se har notar en las ltimas fases del ciclo de vida.
Entre los beneficios que se logran en un proceso iterativo controlado tenemos: Reduce el costo de los riesgos al desembolso de un solo incremento. Si los desarrolladores necesitan repetir la iteracin, la organizacin slo perder el esfuerzo mal dirigido de una iteracin y no el valor del producto completo. Reduce el riesgo de no obtener el producto para la fecha en la que se plane. Identificando los riesgos anticipadamente, el tiempo que se invierte resolvindolos se consume cuando la gente est menos apresurada que en las ltimas fechas en el programa.
Permite que los desarrolladores trabajen eficientemente hacia resultados claros.
Estos conceptos -orientado a casos de uso, enfocado en la arquitectura y desarrollo iterativo e incremental- son igualmente importantes. La arquitectura proporciona la estructura sobre la cual se basar el trabajo en las iteraciones mientras que los casos de uso definen los objetivos y encaminan el trabajo de cada iteracin. El remover una de estas ideas claves reducira severamente el valor del Proceso Unificado.
CICLO DE VIDA El Proceso Unificado se repite sobre varios ciclos que componen la vida de un sistema. Cada ciclo concluye con una versin del producto software a los clientes o usuarios.
Tiempo
Inicio
Iteracin #1 Iteracin #2 ...
Elaboracin
Construccin
Transicin
Iteracin #n-1 Iteracin #n ...
Un ciclo con sus fases e iteraciones.
Observacin: Cada ciclo consiste de cuatro fases: planeacin, elaboracin, construccin y transicin. Cada fase es subdividida en iteraciones, como se discuti en prrafos anteriores.
El Producto. Cada ciclo resulta en una nueva versin del sistema y cada versin es un producto listo a entregar. El producto final incluye los requerimientos, uses cases, especificaciones no funcionales y casos de prueba. Incluye la arquitectura y los distintos modelos visuales artefactos modelados con UML (Unified Modeling Language). Una de las constantes en el desarrollo de software es el cambio en los requerimientos, por lo que los desarrolladores deben iniciar un nuevo ciclo; para esto necesitarn todas las representaciones del producto software generadas en el ciclo anterior:
Un modelo Use Case con todos los casos de uso y sus relaciones con los usuarios. Un modelo de Anlisis, el cual tiene dos propsitos: refinar los casos de uso e iniciar la asignacin del comportamiento del sistema a un conjunto de objetos. Un modelo de Diseo que define la estructura esttica del sistema a travs de subsistemas, clases, interfaces y la realizacin de los casos de uso como colaboraciones o interacciones entre los subsistemas, clases e interfaces. Un modelo de implementacin, el cual incluye componentes y el mapeo de clases a componentes. Un modelo de despliegue, el cual define nodos fsicos tales como computadoras y el despliegue de los componentes sobre esos nodos. Un modelo de prueba, el cual describe los casos de prueba que verifican los casos de uso. Y, por supuesto, una representacin de la arquitectura.
El sistema deber tambin tener un modelo de dominio o de negocio que describa el contexto del negocio del sistema.
Todos estos modelos estn relacionados. Juntos, stos representan el sistema como un todo.
especificado por Modelo Use Case

:A
distribuido por realizado por

:B
:D
:C Modelo de
Anlisis implementado por Modelo de Diseo Modelo de Despliegue
Modelo de Implementacin
Dependencias de los Modelos del Proceso Unificado.
Fases dentro de un ciclo. Cada ciclo consume un tiempo. En este tiempo, el ciclo es dividido en cuatro fases como se muestra a continuacin:
Inicio
Elaboracin
Construccin
Transicin
Flujos de trabajo Principales

Requerimientos Anlisis
Diseo
Implementacin
Prueba iter. #1 iter. #2 iter. #n-1 iter. #n
Iteraciones
Las cinco fases del ciclo de vida de desarrollo del Software - requerimientos, anlisis, diseo, implementacin, y prueba - toman lugar sobre las cuatro fases: inicio, elaboracin, construccin, y transicin.
Durante la fase de planeacin, se desarrolla la idea del producto. Esencialmente, en esta fase se da respuesta a las siguientes preguntas: Qu es lo que el sistema har para cada uno de los usuarios principales? Qu arquitectura podra ajustarse al sistema? Cul es el plan y cunto costar desarrollar el producto?
En este estado la arquitectura es tentativa, los riesgos mas importantes son identificados y priorizados, la fase de elaboracin es planeada en detalle y el proyecto entero es estimado sin mucho detalle.
Durante la fase de elaboracin, varios de los casos de uso son especificados en detalle y la arquitectura del sistema es diseada. Al final de esta fase se est en condicin de planear las actividades y estimar los recursos requeridos para completar el proyecto de desarrollo asegurando que los casos de uso, arquitectura y control de los riesgos sean estables y claros para poder dar inicio al desarrollo del sistema.
Durante la fase de construccin el producto software es construido, los recursos requeridos son consumidos. La arquitectura del sistema es estable, sin embargo debido a que los desarrolladores pueden descubrir mejores formas de estructurar el sistema, ellos pueden sugerir cambios en la arquitectura de poca trascendencia al arquitecto. Al concluir esta fase, el producto contiene todos los casos de uso con los que la administracin y los clientes estn de acuerdo.
La fase de transicin cubre el periodo durante el cual el producto es una versin beta. Con la versin beta un pequeo nmero de usuarios experimentan o prueban el producto pudiendo reportar defectos y deficiencias. Los desarrolladores corrigen los problemas reportados y lanzan la versin final a la comunidad de usuarios. TCNICAS Ahora que tenemos en claro las nociones bsicas en las que se fundamenta el Proceso Unificado, describiremos a continuacin en forma breve los principales flujos de trabajo y las tcnicas utilizadas en cada uno de ellos. Los modelos obtenidos de los flujos de trabajo utilizan el UML como lenguaje de modelado.
1. Requerimientos. Un requerimiento es una caracterstica con la que debe contar el sistema software a construir y que entrega algo de valor a un usuario determinado, para identificarlos se utiliza la estrategia denominada Casos de Uso (Use Cases). Este Portal incluye de manera general la realizacin de las actividades que se muestran en la siguiente tabla:
Actividad Identificar requerimientos candidatos. Definicin del contexto del sistema. Captura de requerimientos funcionales
Artefacto resultante Lista de caractersticas Modelo de dominio del problema o de negocio. Modelo Use Case.
Captura de requerimientos no funcionales. Requerimientos suplementarios por caso de uso. Descripcin inicial de la arquitectura. Descripcin de la Arquitectura.
Tabla 1. Artefactos resultantes de la captura de requerimientos
Para una descripcin ms detallada de cada uno de los artefactos ver capitulo de Requerimientos. 2. Anlisis. En este punto se efecta el anlisis de los requerimientos capturados para refinarlos y estructurarlos. El propsito de hacer esto es alcanzar un entendimiento mas preciso de los requerimientos y obtener una descripcin de los mismos que sea fcil de mantener.
Como producto de este Portal se obtiene el Modelo de Anlisis, el cual posee las siguientes caractersticas: Es descrito usando el lenguaje de los desarrolladores y por lo tanto introduce ms formalismo y es usado para entender como trabaja el sistema internamente. Es una entrada o insumo muy importante para desarrollar el modelo de diseo y de implementacin. Esto es debido a que el sistema deber ser mantenido como un todo descripcin de sus requerimientos. y no slo la
El modelo de anlisis incluye los siguientes elementos: Las clases del anlisis, sus responsabilidades, atributos, relaciones, y requerimientos especiales. Distinguiendo entre clases lmite, de control y entidad. Una caracterstica de la interfaz de usuario o en las interfaces de comunicacin se
reflejan en las clases lmite, la informacin mantenida por el sistema es localizada en una o ms clases entidad. As mismo el control, la coordinacin, secuencia, transacciones y lgica del negocio se localiza en una o ms clases de control. Las realizaciones de los Casos de Uso-Anlisis, las cuales describen como cada caso de uso es refinado en trmino de colaboraciones entre las clases de anlisis. La vista de la arquitectura del modelo de anlisis, incluye elementos importantes en la arquitectura del sistema. Los paquetes de anlisis y de servicios, y sus dependencias y contenidos. Las actividades a realizar se muestran en la siguiente tabla:
Actividad Anlisis de los casos de uso. Anlisis arquitectnico. Artefacto resultante Clases del anlisis y realizacin de casos de uso. Paquetes del anlisis, dependencias y descripcin de la Arquitectura. Anlisis de clases Anlisis de paquetes Clases del anlisis completa (atributos y relaciones). Paquetes del anlisis completo, (clases y dependencias)
Tabla 2. Artefactos resultantes del anlisis.
Para una descripcin ms detallada de cada uno de los artefactos ver captulo de Anlisis.
3. Diseo. El modelo del Diseo trata de preservar la estructura del sistema establecida por el modelo del anlisis. A diferencia del modelo del
Metodologia e Ingenieria del Software Ing. Arturo Diaz Pulido
anlisis que es un modelo conceptual, el modelo del diseo es un modelo fsico. El modelo del anlisis es un diseo genrico (aplicable a varios diseos), en cambio el modelo del diseo no lo es, ya que es especfico para una implementacin. El primero es menos formal, el ltimo lo es ms. Incluye los siguientes elementos: Diseo de clases, incluyendo clases activas, y sus operaciones, atributos, relaciones y requerimientos de implementacin. Algunas clases del diseo con significado arquitectnico se establecen a partir de las clases del anlisis ms significativas. En general, las clases del anlisis son usadas como especificaciones cuando las clases del diseo son bosquejadas. Subsistemas del diseo, servicios de subsistemas y sus dependencias, interfaces y contenidos. Los subsistemas del diseo en las dos capas ms altas (capa de aplicacin especfica y capa de aplicacin genrica) se elaboran en base a los paquetes del anlisis. Algunas de las interfaces se elaboran basndose en las clases del anlisis. Las realizaciones de los Casos de Uso-Diseo, las cuales describen como sern diseados los casos de uso en trminos de colaboraciones dentro del modelo del diseo. La vista de la arquitectura del modelo de diseo, incluyendo los elementos ms significativos. Los elementos ms significativos de la arquitectura del modelo del anlisis son tomados como especificaciones.
Del diseo tambin se obtiene un Modelo de Despliegue, que describe la configuracin de la red sobre la cual se distribuirn los subsistemas o componentes. El modelo de despliegue incluye: Nodos, sus caractersticas y conexiones. Un mapeo inicial de las clases activas sobre los nodos. La vista de la arquitectura del modelo de despliegue, incluyendo los elementos de mayor significado.
Tanto el modelo del diseo como el de despliegue son considerados como las principales entradas para el subsiguiente modelo de implementacin y actividades de prueba.
Las actividades a realizar dentro de este Portal se muestran en la siguiente tabla:

Actividad Diseo de los casos de uso. Diseo arquitectnico. Artefacto resultante Clases del diseo y realizacin de casos de uso (bosquejo). Subsistemas del diseo (bosquejo), dependencias y descripcin de la Arquitectura. Diseo de clases Diseo de subsistemas Clases del diseo completas (atributos y relaciones). Subsistemas del diseo completos (clases y dependencias)
Tabla 3. Artefactos resultantes del diseo.
4. Implementacin.
El principal resultado de la implementacin es el modelo de implementacin, el cual incluye los siguientes elementos:
Implementacin
de
los
subsistemas
del
diseo
sus
dependencias, interfaces y contenidos. Los componentes que incluyen archivos y componentes ejecutables y las dependencias entre ellos. Los componentes son unidades testeadas o comprobadas. La vista arquitectnica del modelo de implementacin, que incluye los elementos ms significantes.
La implementacin tambin resulta en el refinamiento de la vista arquitectnica del modelo de despliegue, cuando los archivos o componentes ejecutables son colocados sobre los nodos. El modelo de implementacin es considerado como la entrada principal para las subsecuentes actividades de testeo o prueba.
5. Prueba. En el Sistema Portal de prueba, se verifican cada uno de las implementaciones de los casos de uso ya sea en las etapas iniciales, intermedias como en las versiones finales. Ms especficamente, el propsito de este Portal es: Planear las pruebas requeridas en cada iteracin, incluyendo pruebas de integracin y pruebas de sistema. Las pruebas de
integracin son requeridas para cualquier versin dentro de las iteraciones, mientras que las pruebas de sistema son requeridas solo al final de las iteraciones. Disear e implementar casos de prueba que especifiquen qu se va a probar, crear procedimientos de prueba que especifiquen como llevar a cabo las pruebas, y crear componentes de prueba ejecutables para automatizar las pruebas si fuera posible. Ejecutar los casos de prueba y analizar los resultados para que de esta manera se puedan ubicar los defectos, en algunos casos ser necesario volver a las etapas anteriores del Portal como diseo o implementacin significativos. para poder subsanar los defectos ms
REQUERIMIENTOS
En esta etapa tiene como propsito cubrir las actividades correspondientes a delimitar el dominio del problema que se pretende atacar e identificar, los ejemplos de uso del sistema que describen los escenarios fundamentales para el funcionamiento del sistema. Estos escenarios en conjunto describen las funciones del sistema y los actores participantes en este dominio.
DEFINICIN DEL SISTEMA

El Sistema Portal Web, permite brindar apoyo legal a quienes lo visitan, mediante el asesoramiento a travs un forum abierto, documentacin preparada y un software adicional que conserva el propsito de ser actualizado, segn los requerimientos del usuario; todo esto se lleva a cabo en base a los diferentes roles que cumplen los usuarios en el Sistema.
DESCRIPCIN DEL SISTEMA

El Sistema Portal Web, apoya y asesora a los usuarios que estn involucrados en los diversos procesos legales ya sean estos de ndole civil o penal. Esto se realiza de la siguiente manera: El Sistema es cargado y configurado en el Servidor, por el Administrador de la aplicacin o por el Especialista (Consultor); este realiza una supervisin de las preguntas formuladas (e-mail), por el usuario, siendo estas respondidas segn su naturaleza por los especialistas en la materia.
El Usuario cuando accede al Portal Web, es libre de elegir una de las diversas opciones que se encuentran accesibles, las cuales especifican las condiciones de transicin de las mismas segn su estado.
El Usuario una vez que accede al Portal Web, puede registrarse en un libro de visitas implcito del portal, informarse de la Institucin (empresa consultora), participar en Forum a travs de preguntas formuladas va e-mail, as como consultar informacin en lnea (archivos de texto) y actualizar/ adquirir el software (compuleg).
Para realizar una Consulta en Lnea para Actualizar/ Adquirir el Software, es prerrequisito ser miembro activo de la empresa, ya que mediante esta condicin el usuario poseer una contrasea que le permitir ser verificado como tal, y as podr acceder a la informacin requerida.
MODELO DEL NEGOCIO
Usuario
Administrador del Sistema
Consultor (Especialista)
Actualiza Sistema Gestor Envi de Registra E-mail Datos Software Visualiza Consulta versin
Libro Visitas
Forum
Institucin
Informacin en Lnea
MODELO DEL DOMINIO

En el modelo del Dominio se captura los tipos ms importantes de objetos en el contexto del Sistema.
pertenece
1..*
mantiene
Software 1..*
1..* actual iza
Version Software
1..*
1 Administrador 1..*
mantiene
1 Usuario
(f rom Actors)
almacena
1 1
envi a
Datos
1
actual iza
0..* Preguntas
1 Consultor
1..*
Documentacion
1..* pertenece 1..*
Archivos de Texto
MODELO DE CASOS DE USO
<<include>> Entonces
Regis trars e en Libro de Visitas
Almacenar Usuario <<extend>> Preguntas Almacenadas
Participar en Forum <Usuario>

(from Actors)
<<include>> Formular Pregunta Almacenar Preguntas
Responder E-mail
Iniciar sesion <<include>> Conocer Empres a Visualizar Datos de Empresa <<extend>> Contrasea Correcta Administrador del Sistema <<extend>> Actualizacion Actualizar Compuleg Mantener Vers ion Software(Com puleg) Consultar en Linea <<extend>> Contrasea Correcta Administrador del Sistema <<extend>> Actualizacion Visualizar Informacion Mantener Archivos de Texto Supervis ion de E-mails Especialis ta
Actualizar Software
DESCRIPCIN DE LOS CASOS DE USO
1. Inicio de Sesin. Descripcin: El Administrador del Sistema o el Especialista (Consultor) cargan o configuran el sistema. Pasos: 1. Verificar Estado de Servidor (Apagado/ Prendido). 2. Cargar Portal Web.
2. Registrase en Libro de Visitas. Descripcin: Significa que los usuarios visitantes al Portal Web, pueden incorporar sus datos mediante una opcin (firmar el libro de visitas). Pasos: 1. Seleccionar la opcin Firmar el Libro de Visitas. 2. Ingresar Nombre. 3. Ingresar E-mail. 4. Ingresar Pagina Web. 5. Ingresar Pas. 6. Ingresar Titulo. 7. Ingresar Mensaje. 25
3. Almacenar Usuarios. Descripcin: Despus de Firmar el Libro de Visitas los usuarios quedan almacenados en un repositorio de la Base de Datos.
Pasos: 1. Si firma el Libro de Visitas entonces Usuario Almacenado en Base de Datos. Fin _si.
4. Supervisar E-mails. Descripcin: Tanto el Administrador del sistema como el Especialista (Consultor) verifican si se encuentran almacenados e-mails (preguntas formuladas) enviados por los usuarios durante la fase de participacin en el Forum. Pasos: 1. Verificar el almacenamiento actual de los e-mails enviados.
3. Responder E-mail. Descripcin: Implica contestar las preguntas formuladas (e-mail), que el usuario realizo durante su participacin en el Forum, segn la naturaleza de la pregunta (civil/ penal), por los especialistas (consultores). Pasos: Si hay preguntas almacenadas entonces Inicio de Responder (remitir e-mail). 1. Recepcionar Remitente. 2. Recepcionar Destinatario. 3. Recepcionar Asunto. 4. Recepcionar Mensaje. 26
5. Enviar Mensaje Fin_si.
4. Almacenar Preguntas. Descripcin: Implica almacenar o registrar las preguntas formuladas (e-mails), enviados en el Forum, por los usuarios. Pasos: 1. Archivar o almacenar preguntas (e-mails).
5. Formular Pregunta (Enviar E-mail). Descripcin: Los Usuarios cuando participan en el Forum tienen la libertad de crear preguntas las cuales se manifiestan con el uso de e-mails, que ellos pueden enviar en lnea a la empresa consultora. Pasos: 1. Recepcionar Remitente. 2. Recepcionar Destinatario (Empresa Consultora). 3. Recepcionar Asunto. 4. Recepcionar Mensaje. 5. Enviar Mensaje 27
6. Participar en Forum. Descripcin: Los Usuarios cuando participan en el Forum tienen la libertad de crear preguntas las cuales se manifiestan con el uso de e-mails, que ellos pueden enviar en lnea a la empresa consultora.
Pasos: 1. Si participa en Forum entonces Formula pregunta a travs de e-mail. Fin_si.
7. Conocer Datos de la Empresa. Descripcin: Permite informar al usuario sobre los datos de la empresa. Pasos: 1. Visualiza informacin acerca de la Empresa (Consultora), para su seleccin y sugerencias.
8. Visualizar Datos de la Empresa (Consultora). Descripcin: Implica informarse acerca de la institucin o empresa (Consultora), de quien el usuario hace objeto para asesorarse en su caso. Pasos: 1. Selecciona informacin acerca de la Empresa (Consultora). 2. Lista o visualiza informacin acerca de la Empresa (Consultora). 28
9. Actualizar Software. Descripcin: Este requerimiento, indica que el usuario puede tratar de solicitar la actualizacin del software del cual hace uso, para su asesoramiento. Pasos: 1. Solicita Versin Actual.
10. Actualizar Versin (Compuleg). Descripcin: Implica ser miembro activo de la Empresa (Consultora), con lo cul se consigue administrar un password o clave de seguridad para poder acceder a los requerimientos de est naturaleza. Pasos: 1. Si password es correcto entonces Actualizar Software (Versin de Compuleg) Caso Contrario Mensaje Password Incorrecto. Fin _ si.
11. Mantener Versin de Software Descripcin: Significa que encargados de la Empresa (Administrador de Aplicacin y/o Consultor), pueden dar mantenimiento (insertar, modificar, eliminar) a las versiones de Software actualmente expuestas al usuario comn. Pasos: 1. Si Existen versiones mas actuales que versin actual entonces Dar mantenimiento a la versin actual Caso Contrario Mensaje Versiones anterior y actual son iguales. Fin _si. 29
12. Consultar en Lnea.
Descripcin: Significa ser miembro activo de la Empresa (Consultora), con lo cul se consigue administrar un password o clave de seguridad para poder acceder a los requerimientos de est naturaleza, como es de solicitar obtener informacin de Documentacin Jurdica en Lnea. Pasos: 1. Si password es correcto entonces Consultar en Lnea (Archivos de Textos) Caso Contrario Mensaje Password Incorrecto. Fin _ si.
13. Visualizar Informacin. Descripcin: Despus de haber ingresado el password de seguridad correcto se puede seleccionar la informacin requerida. Pasos: 1. Mientras Password sea correcto hacer a. Seleccionar Informacin. b. Mostrar Informacin. Fin _Mientras. 30
14. Mantener Informacin. Descripcin: Significa que encargados de la Empresa (Administrador de Aplicacin y/o Consultor), pueden dar mantenimiento (insertar, modificar,
eliminar) a la Documentacin que se actualmente expone al usuario comn, a travs de Archivos de Textos almacenados en el Servidor. Pasos: 1. Buscar la Documentacin que requiera ser actualizada. 2. Dar mantenimiento (insertar, modificar, eliminar) a la Documentacin seleccionada. 3. Colocar Documentacin a disposicin del usuario.
31
PAQUETE DE REQUERIMIENTOS
us uario
Firma/ regs itra en libro de vis itas Lee libro de vis itas Form ula preguntas informacion ins titucional consulta infomacion
Inform aci on en l a red
actualizacion mantenimiento verificacion claves vis ualizacion
Cons ultor
Supervis a m ens ajes res ponde m ens ajes mantenimiento inicia s es ion
32
ANALISIS
En esta etapa se procede con el estudio de cada escenario identificado en la fase de requerimientos. A medida que se pasa por cada caso de uso se van identificando los objetos que participan en l, las responsabilidades de cada objeto, y como esos objetos colaboran con otros, en trminos de las operaciones que invoca cada uno sobre el otro u otros. Para ello se hace uso de dos herramientas notacionales que son utilizadas para modelar el comportamiento de un sistema y que forman parte del UML, stas son: los diagramas de colaboracin y los de secuencia. Un diagrama de colaboracin representa una instantnea en el tiempo de una corriente de eventos sobre una cierta configuracin de objetos. Esta clase de diagrama lo usaremos para mostrar la existencia de objetos y sus relaciones dentro de los casos de uso previamente identificados. Un diagrama de secuencia se usa para realizar una traza de la ejecucin de un escenario o caso de uso en el mismo contexto que un diagrama de colaboracin pero con la salvedad de que resulta mas fcil de leer el paso de mensajes en un orden temporal. 33
REGISTRAR USUARIO
Diagrama de Colaboracin
2: Registrar Usuario (Obj. Usuario) 3: Nuevo Usuario.
1: Registrar Usuario
: Actualizador de Usuarios
Usuario GUI: Libro de Visitas.
: Usuarios
Diagrama de Secuencia
Usuario
GUI: Libro de Visitas
Actualizador de Usuarios
: Usuarios
Registrar Usuario Registrar Usuario (Obj. Usuario)
34 Flujo de Eventos
Registrar Usuario () Recepcionar Datos del Usuario Nombre
New Usuario
E-mail Pgina Web Pas Titulo Mensaje Fin Registrar Usuario
PARTICIPAR EN FORUM
2: Enviar E-mail (Obj. E-mail) 3: Nuevo E-mail.
1: Enva E-mail
: Actualizador de E-mails
Usuario GUI: Forum.
: E-mails
35
Usuario
GUI: Forum
Actualizador de E-mails
: E-mails
Enviar E-mail Enviar E-mail (Obj. E-mail) New E-mail
E-mail registrado E-mail recibido Confirma E-mail
Flujo de Eventos
Participar en Forum () Recepcionar Remitente. Recepcionar Destinatario (Empresa Consultora). Recepcionar Asunto. Recepcionar Mensaje. Enviar Mensaje
36
CONOCER EMPRESA
1: Consulta Informacin
2: Consulta Informacin (Obj. Informacin)
5: Lista Datos Usuario GUI: Web Institucional. :Visualizador de Datos 3: Revisa 4: Obtiene
: Informacin
37
Usuario GUI: Web Institucional : Informacin Consulta Informacin Solicita Datos Envo de Datos Visualizacin de Datos
Flujo de Eventos
Conocer Empresa () Consulta Informacin de Empresa (Consultora). Visualiza Datos de Empresa (Consultora).
38
ACTUALIZAR SOFTWARE
M 1/5. SW Actualizar 2. Actualizar SW (Obj. SW) 4. Obtiene Versin
Usuario
:GUI: Actualizacin de SW Jurdico
: Buscador de SW
:Usuario
:Consultor
6. Mantener Versin
8. Versin Renovada
3. Get Versin
7. New Versin
: Versiones SW : Actualizador de SW
39
: Usuario Consulta Versin
:GUI: Actualizacin de SW Jurdico
Buscador de SW
:Versiones SW
Actualizador de SW
: Consultor
Solicita Versin Verifica Versin Mantiene Versin
Actualiza Versin
Confirma Versin Obtiene Versin Enva Versin
Versin Actualizada
Confirma Actualizacin
Flujo de Eventos
Actualizar Software () Solicita Versin de Software. Si Existe Versin Solicitada Entonces Obtiene Versin de Software Caso Contrario Mensaje No Existe Versin Solicitada Fin _ si. Mantener Software () Si Existe Versin Anterior Entonces Versin Actual de Software Caso Contrario Mensaje No Existe Versin Solicitada Fin _ si.
40
CONSULTAR EN LINEA
M 1/5. Consultar Documento
Usuario
2. Buscar Documento
:GUI: Consultas en Lnea 6. Mantener Archivo
4. Listar Documento
: Buscador de Documentos
:Usuario
:Consultor
8. Archivo Renovado
3. Get Archivo
7. New Archivo
: Actualizador de Documentos
: Archivos de Texto
41
: Usuario Consulta Documento
:GUI: Consultas en Lnea
Buscador de Documentos
:Archivos de Texto
Actualizador de Documentos
: Consultor
Solicita Documento Verifica Existencia de Archivo Mantiene Documento
Actualiza Documento
Confirma Existencia Enva Documento Lista Documento
Documento Actualizado
Confirma Actualizacin
Flujo de Eventos 42
Consultar en Lnea () Solicita documentacin en Lnea. Si Existe Archivo Solicitado Entonces Lista documento. Caso Contrario Mensaje No Existe Documentacin Solicitada Fin _si. Mantener Documento () Si Existe Documentacin Actual Entonces Actualizar o dar mantenimiento a Documentacin Existente Caso Contrario Mensaje No se puede dar mantenimiento, documentacin es igual. Fin _ si.
43
PAQUETES DEL ANLISIS

Usuario: Clase Lmite/ Clase Interfaz Clase de Control Clase Entidad Usuarios. Actualizador de Usuarios Registrador de Usuarios (GUI: Libro de Visitas).
Documentos Clase Lmite/ Clase Interfaz Clase de Control 44 Clase Entidad Archivos de Texto. Buscador de Documentos. Actualizador de Documentos. Consultas en Lnea.
Software
Clase Lmite/ Clase Interfaz Clase de Control Clase Entidad Versiones de SW. Buscador de Documentos. Actualizador de Documentos. Actualizacin de SW Jurdico.
Consultor Clase Lmite/ Clase Interfaz Clase de Control 45 Clase Entidad Almacn de Archivos de textos. Almacn de Versiones de Software Jurdico (Compuleg). Actualizador de Software. Actualizador de Documentos Actualizacin de SW Jurdico. Actualizacin de Documentacin Jurdica.
Actualizar Software Consultar Software Mantener Software Listar Software
Usuario
Registra Usuario Emite Mensajes
Documento Software
Actualizar Documento Consultar Documento Mantener Documento Listar Documento
Consultor
Inicia Sesion Revisa Mensajes Responde Mensajes
Diagrama de Paquetes del Anlisis
46
DIAGRAMA DE CLASES
Software 1..* 1..*

1..* mantiene actual iza
pertenece
Vers ion Software 1..*

ID Stri ng Descri pcion String Version integer Autor Stri ng
Adminis trador
ID Stri ng Nom bre String Direccion String Cargo String T elefono Stri ng e-m ail String
1 1 Us uario
(from Actors) ID Stri ng Nom bres Stri ng Apel li dos String Direccion String T elefono Stri ng E-m ai l String almacena
Datos
envi a
1..* Cons ultor

mantiene
Preguntas 1
actual iza
0..*
ID integer Asunto String T ipo String
1
1..*
Documentacion
1..* pertenece 1..*
47
Archivos de Texto
ID Stri ng Dispositivo Stri ng Resum en String Procedenci a String Expediente String
DIAGRAMA DE ESTADOS
Registro de Usuarios/ Actualizacin de Documentos y Software.
Abrir Libro de Visitas registrar usuario
Usuario suscrito Suscribir cierra libro Actualiza Software Abierto actualizar Clave Correcta actualizar clave incorrecta Consulta en Linea(Abierto) Clave Correcta Actualiza Documentacion actualizar software Clave incorrecta
48
49
DISEO
Esta tiene como objetivo principal dar forma al sistema, es decir elaborar una arquitectura del mismo que incluya tanto los requerimientos funcionales como los no funcionales y otras exigencias. Para ello ser necesario refinar las clases del anlisis ms significativas, siendo necesario modelar su comportamiento en trminos de estados que permita de manera satisfactoria disear y posteriormente implementar los procesos de flujo de trabajo que permitan la creacin, organizacin, configuracin y rastreo del proceso de revisin de un documento. As como tambin refinar los casos de uso identificados previamente materializndolos en trminos de interfaces de usuario y describiendo la secuencia de navegacin entre stas. Poner nfasis en el cumplimiento tanto de requerimientos funcionales como no funcionales y tener en cuenta stos ltimos como criterios de seleccin de la tecnologa a utilizar. As mismo identificar los subsistemas y componentes que constituyen el sistema en desarrollo. Presentar el modelo de despliegue el cual describe la configuracin de red sobre la cual el sistema deber ser distribuido. 50
INTERFACES GRFICAS DE USUARIO

A continuacin presentamos las principales GUI del sistema que hacen posible la realizacin de los casos de uso: Principal
51
Libro de Visitas
Firmar Libro de Visitas.
52 Leer Libro de Visitas.
Forum
Web Institucional
53
Sistema de Leyes en Lnea
54
Actualizacin de Software Jurdico
55
DIAGRAMAS DE NAVEGACIN
Los diagramas que se presentan a continuacin tienen el propsito de ilustrar como se transita a travs de las distintas interfaces grficas de usuario para poder llevar a cabo el desarrollo de los casos de uso identificados y descritos en los captulos anteriores. Para ello, aprovechamos una vez ms los diagramas de secuencia del UML.
Principal
: Sistema Portal Web

: Usuario
GUI: Principal
Click Mostrar Pgina
Visualiza Pgina
56
Libro de Visitas

: Usuario Clic en Libro de Visitas
GUI: Firmar Libro
:Usuarios
Mostrar Pgina Clic en Firmar Libro de Visitas Escribir Nombre Escribir E-mail Escribir Pagina Web Escribir Titulo Escribir Pas Escribir Mensaje Clic en Firmar en el Libro Mensaje Gracias por Firmar el Libro Recargar Nuevo Usuario
57
Firmar el Libro de Visitas.
GUI: Leer Libro de Visitas
: Usuarios
Clic en Libro de Visitas Mostrar Pgina Clic Leer Libro
Lee Remitente Lee Fecha de remisin Lee Pas Lee Asunto Selecciona () Retorna () Clic Volver
Recargar ()
Leer Libro de Visitas.
58
Forum
GUI: Foro Jurdico
: Preguntas (E-mails)
Clic en Foro Jurdico Especializado Mostrar Pgina
Escribir Asunto Escribir Mensaje Clic en Enviar Enviar () Mensaje Mensaje enviado satisfactoriamente
Nuevo E-mail ()
Clic en Aceptar Recargar ()
59
Sistema de Consultas en Lnea
GUI: Password
GUI: Sistema de Leyes en Lnea
: Archivos de Texto
Clic en Sistema de Leyes en Lnea Mostrar Pgina Escribir Usuario Escribir Password Verificar () Mensaje Password Correcto Mostrar Pgina Selecciona Informacin Busca () Retorna () Obtiene Informacin
60
Actualizacin de Software Jurdico

: Sistema Portal Web GUI: Password GUI: Actualizacin de Software Jurdico : Versiones de Software
Clic en Actualizacin de Software Jurdico Mostrar Pgina Escribir Usuario Escribir Password Verificar () Mensaje Password Correcto Mostrar Pgina Selecciona Versin Busca () Retorna () Obtiene Versin Solicitada
61
Web Institucional de la Empresa

: Usuario
GUI: Principal
GUI: Web Institucional
Click Mostrar Pgina Clic en Web Institucional
Visualiza Pgina
DIAGRAMA DE CLASES
Software 1..* <<com m unicate>> Adminis trador

ID Stri ng Nom bre String Direccion String Cargo String T elefono String e-m ail String Ini ci aSesion() Supervi saM ensajes() RespondeM ensajes() mantiene 1..* actual iza pertenece
Vers ion Software 1..* 1..*

ID Stri ng Descri pcion String Version integer Autor Stri ng Actual iza() M antiene() Lista() Consulta()
1 Us uario
(from Actors) ID Stri ng Nom bres Stri ng Apel li dos String Direccion String T elefono String E-m ai l String
almacena
Datos 1
Regi straUsuari o() ListaUsuari o()
1 1
envi a
1..*
mantiene
Em iteM ensajes()
0..* 1
actual iza
Preguntas
ID integer Asunto Stri ng T ipo String Alm acenaPreguntas()
Cons ultor
1
1..*
Documentacion
1..* pertenece 1..*
62
Archivos de Texto
ID Stri ng Dispositivo Stri ng Resum en String Procedenci a String Expediente String Actual iza() M antiene() Listar() Consultar()
REQUERIMIENTOS ESPECIALES O NO FUNCIONALES

Logro de la persistencia de las clases de diseo. Este requerimiento se cubre agencindose de un sistema administrador de base de datos relacionales, en el cual las clases de diseo (clases entidad) pasarn a ser tablas, de esta manera se asegura la persistencia de la informacin que contienen los atributos de cada uno de sus objetos (instancias de clase). La seleccin del sistema administrador de base de datos depender en gran medida de la compatibilidad y grado de complemento que tenga con la herramienta que se pretende utilizar.
Caractersticas de seguridad. Habindose elegido PHP como herramienta de desarrollo para la construccin de nuestra solucin de flujo de trabajo, se puede tomar ventaja de la seguridad integrada que sta proporciona. As se aprovechar la seguridad a nivel de base de datos, tablas, vistas y columnas que mySQL provee para restringir el acceso a la informacin a usuarios ajenos a la solucin. 63 El mantenimiento de un directorio de usuarios y roles o perfiles de usuario es una exigencia que ha de atenderse para la correcta organizacin de los usuarios de la solucin y despliegue del modelo de seguridad a implantar Es necesario adems limitar las acciones que los usuarios de la solucin realicen en un determinado proceso basndose en los roles que desempean en ella.
En consecuencia se requiere de una solucin dotada de cierta "inteligencia" que autoconfigure el nivel de seguridad requerido para un determinado usuario que haya iniciado una sesin en la aplicacin. Dado que esto involucra la integracin de varias caractersticas de seguridad a distintos niveles, el modelo de seguridad de nuestra solucin ha de estar integrado para cumplir con este objetivo.
Control de concurrencia. Debido a que la solucin a desarrollar se enmarca en un entorno multiusuario es necesario el control de la simultaneidad de accesos a la informacin. El cumplimiento de esta exigencia desde luego quedar en manos de un servidor de base datos tal como mySQL que administrar las transacciones y utilizar el bloqueo para el control de esta situacin.
Control de tiempos. El establecimiento de plazos o fechas lmite para el cumplimiento de la supervisin de los e-mails por parte del Administrador del Sistema / Consultor y la toma de las medidas correspondientes por parte del sistema en caso de incumplimientos y el manejo de excepciones basadas en este contexto, requiere la automatizacin del control del tiempo. Afortunadamente mySQL cuenta con el servicio Agente SQL, el cual permite programar trabajos o tareas que han de ejecutarse de manera peridica de acuerdo a las necesidades. Aprovechando sta caracterstica se puede llevar a cabo el manejo de los e-mails segn el 64
plazo asignado a las tareas de supervisin por parte del gestor de base de datos y tomar las medidas apropiadas, convirtiendo a nuestra solucin en un sistema proactivo.
6.1.
DISEO DE SEGURIDAD DEL SISTEMA

Consideraciones de la Seguridad del Sistema Debido a que el modelo de seguridad de Linux y el de mySQL, dos de las herramientas sobre las cuales se implementa el sistema, influyen en el propio modelo de seguridad. Cabe destacar que la seguridad de la aplicacin Web que se est diseando puede tratarse y mantenerse de forma paralela a la seguridad de la propia red.
La seguridad de las aplicaciones Web es un asunto muy complejo, ya que puede establecerse en diferentes niveles y de varias formas distintas. Las opciones dependen del sistema y de los servidores utilizados, as como de las necesidades de la aplicacin Web. 65
As en el contexto del Sistema basado en Web que se disea podemos identificar tres niveles de seguridad: Nivel de Sistema Operativo Nivel de Base de Datos Nivel de Aplicacin
Nivel de Sistema Operativo

Las opciones de seguridad elegidas para el sistema operativo dependen de las caractersticas y opciones ofrecidas por dicho sistema. Por ejemplo, en el caso de Linux, los mecanismos de seguridad trabajan con cuentas de usuario y de grupo, entidades que permiten implementar la autenticacin y autorizacin a recursos de red. Esto exige la creacin de cuentas de usuarios y grupos con los permisos pertinentes para poder establecer niveles de privilegios de acuerdo a los roles que cumplirn los usuarios en el sistema y para que stos puedan iniciar una sesin en el mismo.
66
Nivel de Base de Datos

Cuando trabajamos con mySQL los usuarios pasan por dos fases de seguridad: la autenticacin y la validacin de permisos. La fase de autenticacin identifica al usuario usando una cuenta de inicio de sesin que puede ser estndar o basada en una cuenta de inicio de sesin del sistema operativo, en este caso Windows NT 4 o Windows 2000, sta fase solo permite la capacidad de conectarse al servidor de base de datos. El usuario entonces requiere permisos de acceso a la base de datos
sobre el servidor, lo que se resuelve creando una nueva cuenta en la base de datos a la que se quiere acceder basada en una cuenta de inicio de sesin del servidor de base de datos.
La validacin de permisos se implementa por medio de roles de bases de datos por medio de los cuales se pueda catalogar a los usuarios y asignarles los privilegios correspondientes sobre objetos en la base de datos tales como tablas, vistas, etc. Para la implementacin de este sistema Web los roles de base de datos son crticos ya que stos materializan los roles participantes en los procesos de supervisin de e-mails y gracias a ellos podemos definir que informacin puede ser respondida para los usuarios que pertenecen a cada rol. Estos roles son los siguientes: Supervisor: Puede revisar e-mails que le han sido asignados para su evaluacin/ contestacin. Usuario: Puede registrarse. Tambin tiene el privilegio de leer los e-mails respondidos. Administrador de Aplicacin: Puede definir procesos de supervisin para determinadas categoras, segn la naturaleza de las preguntas. Administra las categoras de e-mails. Es el rol con los mayores privilegios a nivel de la aplicacin Web. 67
Nivel de Aplicacin
La seguridad en este nivel est definida por la validacin de permisos durante la interaccin de los usuarios con la aplicacin web.
REQUERIMIENTOS DE SOFTWARE Y HARDWARE

Considerando los requerimientos especiales contemplados anteriormente se hace necesario definir los requisitos de software y de hardware tanto en el lado servidor como cliente para el correcto desenvolvimiento del sistema. 6.1.1. PARA EL SERVIDOR Requerimientos de software:
Categora Sistema operativo Servidor de Base de Datos Objetos de Base de Datos Software de red Software Internet Software de red integrado de Conectiva Linux Apache Web Server Tablas, Vistas, Procedimientos Almacenados, Triggers. Requisito Linux Conectiva Server Edition versin 4.5 mySQL
Requerimientos de hardware: Se toman como base los recomendados para el servidor de red:
Categora Equipo Pentium III a mas. 128 Mb o superior 2.1 Gb o superior (incluyendo archivos de sistema operativo) Tarjeta de Red Ethernet 100 Mb o superior. Tarjeta de red compatible con Linux y su cable correspondiente. Requisito
68
Memoria (RAM) Espacio en disco
6.1.2. PARA EL CLIENTE Requerimientos de software:

Categora Sistema operativo Requisito Cualquiera de los existentes en el mercado. Se recomienda plataforma Windows. Software de red Software Internet Software de red integrado con plataforma en uso. Internet Explorer 4.0 o superior Nestcape Communicator 4.0 o superior.
Requerimientos de hardware:
Categora Equipo Memoria (RAM) Tarjeta de Red Pentium a ms. 32 Mb o superior. 64 MB (recomendado). Ethernet 10 Mb o superior. Tarjeta de red compatible con la plataforma en uso. Requisito
69
DIAGRAMA DE DESPLIEGUE
Im preso ra 1 RS 232
Servidor
Conectiva Linux Apache Web Server Portal Web
Internet
Estacion
* Web Browser Cualquier Plataform a
* TCP/IP
1 router 1 TCP/IP 1 modem
Diagrama de Despliegue de los Componentes que integran la aplicacin.
70
IMPLEMENTACIN
En esta etapa se toma en cuenta los detalles del diseo para la implementacin del sistema en trminos de cdigo fuente, scripts, archivos html y componentes. El objetivo de esta etapa es implementar las clases del diseo como objetos persistentes para que la informacin que almacenan en sus atributos sea persistente as como tambin implementar los subsistemas identificados durante el diseo. Estos ltimos en nuestro caso estarn constituidos por archivos html y algunos componentes reutilizables. ESTRUCTURA DE LA BASE DE DATOS
71
DIAGRAMA DE COMPONENTES DE LA APLICACIN WEB
Firmar Libro.html
<<hyperlink>>
Leer Libro.html
<<hyperlink>>
Foro Jurdico Especializado.html
Sistema de Leyes en Lnea.html
<<hyperlink>> <<hyperlink>> <<hyperlink>>
Libro de Visitas.html
<<hyperlink>>
ArchivosTexto.zip
Index.html
<<hyperlink>> <<hyperlink>>
72
Actualizacin de Software Jurdico.html
<<hyperlink>>
Web Institucional.html
Versiones.zip
VISTA DE LA ARQUITECTURA DEL SISTEMA
Apache
MySQL (Servidor de Base Datos)
73
PRUEBA DEL SOFTWARE

El propsito de esta fase es documentar de manera concisa los casos de prueba planeados y ejecutados en el software desarrollado. Cabe resaltar que las pruebas se realizaron de manera implcita en todo momento de la codificacin e implementacin del Sistema basado en Web. La prueba del software es un elemento crtico para la garanta de la calidad del software y representa una revisin final de las especificaciones, del diseo y de la codificacin. Se planificaron dos tipos de prueba como son: Pruebas de Caja Blanca. Pruebas de Caja Negra. Estos planes nos ayudaron a definir el camino a seguir y mantenernos centrados en 74 cumplir con nuestros objetivos y hacer del software funcional y con una arquitectura estable.
LISTA DE COMPROBACIN
Al final de la codificacin, el software presentar las siguientes caractersticas que lo harn fcil de probar: Operatividad. Observabilidad.
Controlabilidad. Capacidad de descomposicin. Simplicidad. Estabilidad. Facilidad de comprensin.
PRUEBAS DE CAJA BLANCA

Se ha considerado realizar planes de prueba con el mtodo de caja blanca utilizando el modelo del Camino Bsico. La eleccin de este mtodo se debe a que se necesita saber exactamente como es el comportamiento del flujo de datos dentro de los algoritmos programados, realizar un minucioso examen de los detalles procedimentales, comprobacin de caminos lgicos, bucles y condiciones. Se puede examinar el estado del programa en varios puntos par a determinar si el estado real coincide con el esperado o mencionado.
75
BOOCH Grady. Anlisis y Diseo Orientado a Objetos. Edit Addison Wesley, 2da. ed., USA 1996, 650 pp.
BOOCH Grady, JACOBSON Ivar y RUMBAUGH James. The Unified Modeling Language User Guide. Edit Addison Wesley, USA 1999.
LARMAN, Craig. UML y Patrones: Introduccin al anlisis y diseo orientado a objetos. Edit Prentice Hall, 1ra. ed, Mxico 1999, 536 pp.
BOOCH Grady, JACOBSON Ivar y RUMBAUGH James. El Proceso Unificado de Desarrollo de Software. Edit Addison Wesley, USA 1999.
76

Metodologia Rup

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Metodologia Rup

Hochgeladen von

Copyright:

Verfügbare Formate

Universidad Nacional de Trujillo

Metodologia e Ingenieria del Software

Ing. Arturo Diaz Pulido

Universidad Nacional de Trujillo

REFERENCIAS DEL PROCESO UNIFICADO DE DESARROLLO DE SOFTWARE

Proceso de Desarrollo de Software

Metodologia e Ingenieria del Software

Ing. Arturo Diaz Pulido

Universidad Nacional de Trujillo

Metodologia e Ingenieria del Software

Ing. Arturo Diaz Pulido

Universidad Nacional de Trujillo

Metodologia e Ingenieria del Software

Ing. Arturo Diaz Pulido

Universidad Nacional de Trujillo

Metodologia e Ingenieria del Software

Ing. Arturo Diaz Pulido

Universidad Nacional de Trujillo

Permite que los desarrolladores trabajen eficientemente hacia resultados claros.

Metodologia e Ingenieria del Software

Ing. Arturo Diaz Pulido

Universidad Nacional de Trujillo

Un ciclo con sus fases e iteraciones.

Metodologia e Ingenieria del Software

Ing. Arturo Diaz Pulido

Universidad Nacional de Trujillo

Metodologia e Ingenieria del Software

Ing. Arturo Diaz Pulido

Universidad Nacional de Trujillo

especificado por Modelo Use Case

distribuido por realizado por

Anlisis implementado por Modelo de Diseo Modelo de Despliegue

Dependencias de los Modelos del Proceso Unificado.

Metodologia e Ingenieria del Software

Ing. Arturo Diaz Pulido

Universidad Nacional de Trujillo

Flujos de trabajo Principales

Prueba iter. #1 iter. #2 iter. #n-1 iter. #n

Metodologia e Ingenieria del Software

Ing. Arturo Diaz Pulido

Universidad Nacional de Trujillo

Metodologia e Ingenieria del Software

Ing. Arturo Diaz Pulido

Universidad Nacional de Trujillo

Metodologia e Ingenieria del Software

Ing. Arturo Diaz Pulido

Universidad Nacional de Trujillo

Tabla 1. Artefactos resultantes de la captura de requerimientos

Metodologia e Ingenieria del Software

Ing. Arturo Diaz Pulido

Universidad Nacional de Trujillo

Tabla 2. Artefactos resultantes del anlisis.

Universidad Nacional de Trujillo

Metodologia e Ingenieria del Software

Ing. Arturo Diaz Pulido

Universidad Nacional de Trujillo

Las actividades a realizar dentro de este Portal se muestran en la siguiente tabla:

Tabla 3. Artefactos resultantes del diseo.

Metodologia e Ingenieria del Software

Ing. Arturo Diaz Pulido

Universidad Nacional de Trujillo

Metodologia e Ingenieria del Software

Ing. Arturo Diaz Pulido

Universidad Nacional de Trujillo