You are on page 1of 14

Reporte de Diseo de Software (RDS)

Versin <x.y.z> [Nombre del proyecto]

[Este documento es la plantilla base para elaborar el documento Reporte de Diseo de Software. Los textos que aparecen entre parntesis rectos son explicaciones de que debe contener cada seccin. Dichos textos se deben seleccionar y sustituir por el contenido que corresponda. En caso que alguna de las secciones del presente documento no aplique a su proyecto pueden usarse las frases No hay cambios, No hay impacto en esta seccin, La solucin que se est implementando no tiene impacto en esta seccin, No aplican para el proyecto (No borrar secciones del documento)]

____________________________________________________________________________________
Reporte de Especificacin de Software (RES) Pgina 1 de 14

HISTORIAL DE REVISIONES
Fecha de Elaboraci n <Fecha de Elaboracin >

Versi n

Autor

Descripcin

Fecha de Revisin

Revisado por <Persona(s) que revisa(n) el documento>

<Persona que elabora <x.y.z> el documento >

<Detalles>

<Fecha de Revisin>

____________________________________________________________________________________
Reporte de Diseo de Software (RDS) Pgina 2 de 14

Contenido
1.1.PROPSITO......................................................................................................................................3 1.2.ALCANCE........................................................................................................................................3 1.3.DEFINICIONES , ACRNIMOS Y ABREVIATURAS ........................................................................................3 1.4.REFERENCIAS...................................................................................................................................4 5.1.REALIZACIN DE CASOS DE USO MODELO DE ANLISIS.........................................................................6 5.2.MODELO CONCEPTUAL.......................................................................................................................6 5.3.MODELO LGICO..............................................................................................................................6 5.4.MODELO DE DISEO ........................................................................................................................7 9.1.C RITERIOS DE INTEGRACIN DE SOFTWARE...........................................................................................11 9.2.SECUENCIA DE INTEGRACIN.............................................................................................................12 9.3.E NTORNO NECESARIO PARA LA INTEGRACIN........................................................................................13

1.

Introduccin
[Describa de manera breve el contenido del documento orientando descripcin hacia la utilidad que la misma busca. Recuerde que para elaboracin del documento debe considerar lo desarrollado en el Reporte Especificacin de Software (RES) y que es posible que en esta seccin pueda complementar la informacin del documento base RES.] la la de se

1.1.

Propsito
[En esta seccin se debe proporcionar una visin general de la arquitectura del sistema haciendo referencia a las diferentes vistas que implementarn los diferentes aspectos.]

1.2.

Alcance
[Indicar cul es el alcance del documento. Considere que en el RES se ha desarrollado la Vista de Sistema (funcional) y que para completar la visin total es necesario incluir la vista de arquitectura, vista lgica, vista de implementacin, vista de despliegue y vista de datos. A menudo es necesario incluir una representacin de la arquitectura con consideraciones de infraestructura tecnolgica, relacin con otros sistemas y una vista de procesos en donde se describe la descomposicin del sistema en procesos y los mtodos de comunicacin del sistema.]

1.3.

Definiciones, Acrnimos y Abreviaturas


[Proporcione las definiciones, acrnimos y abreviaturas que se utilizarn en el desarrollo del documento.]

1.3.1.

Definiciones
[Indique cada una de las definiciones que son relevantes para el entendimiento del presente documento. Cada definicin deber ir acompaada de una breve descripcin.] Definicin Asistente de Gestin Descripcin Trabajador encargado de procesar las rectificaciones de los ciudadanos que lo solicitan. Tambin coordina las entregas de hologramas.
Pgina 3 de 14

____________________________________________________________________________________
Reporte de Diseo de Software (RDS)

1.3.2.

Acrnimos
[Indique cada una de los acrnimos que son relevantes para el entendimiento del presente documento, para el entendimiento de la arquitectura propuesta y para el diseo detallado. Cada acrnimo deber ir acompaada de una breve descripcin.] Acrnimo RUP Descripcin Rational Unified Process

1.3.3.

Abreviaturas
[Indique cada una de las abreviaturas que son relevantes para el entendimiento del presente documento, para el entendimiento de la arquitectura propuesta y para el diseo detallado. Cada abreviatura deber ir acompaada de una breve descripcin.] Acrnimo SIGA Descripcin Sistema Integrado de Administrativa Gestin

1.4.

Referencias
[Mencione los documentos que sirven como entrada, o salida, y herramientas que se usarn para el desarrollo del presente documento.]

2.

Vista General de la Arquitectura


[En esta seccin describa la arquitectura de software para el sistema actual, y cmo este ser representado. De las vistas de casos de uso, lgica, procesos, despliegue e implementacin; se enumerarn las vistas necesarias, y por cada vista, se deber explicar qu tipo de elementos del modelo contienen.] Ejemplo: A continuacin se muestra la Arquitectura del Sistema ABC, sta est dividida en tres capas: Capa de Presentacin Capa de Negocios Capa de Integracin As mismo la aplicacin por un criterio de funcionalidad se ha dividido en seis mdulos: Mdulo de Administracin del Negocio Mdulo de Empaquetamiento Mdulo de Mensajera Mdulo de Administracin de Datos Servicios Web X12 Capa de Componentes EDI Web SGSS
Presentacin

Servicios Web X12 Aplicativo Externo 1 Mdulo de Administracin del Negocio Mdulo de Empaquetam.

Componentes EDI Mdulo de Mensajera

Capa de Aplicacin y Lgica de Negocio

Mdulo de Administracin Aplicativo de Datos Externo N ____________________________________________________________________________________


Reporte de Diseo de Software (RDS) Pgina 4 de 14
Capa de Base de Datos

Base de Datos del Sistema

Base de Datos 1

Base de Datos 2

Base de Datos N

La figura anterior muestra la distribucin de los mdulos del software que tendr el sistema, adems de brindar una visin general del sistema. En el grfico, se observa la distribucin en tres capas de la arquitectura, las cuales se describen a continuacin.

Capa de presentacin En esta capa se encuentra la aplicacin Web dedicada a la administracin y configuracin DEL SISTEMA XYZ, la cual estar conformada por las pantallas de presentacin al usuario. Estas aplicaciones Web sern pginas ASP.NET. Capa de Lgica de Negocio Esta capa provee todo lo que es la lgica del negocio, es decir la funcionalidad del sistema, ya sean los procesos administrativos, y los procesos referidos a la elegibilidad, crdito hospitalario (cartas de garanta) y crdito ambulatorio (pedidos de reembolso). Adems, en esta capa se encuentran los servicios publicados, como los Web Services y los Servicios EDI sobre TCP/IP. Capa de acceso a datos Esta capa provee los servicios y conexiones a la base de datos requeridos por la capa de lgica de Negocio. Por otro lado, el manejador de base de datos utilizado para este sistema ser Microsoft SQL Server 2000.

3.

Metas y Restricciones de la Arquitectura


[En sta seccin se describe describen los requerimientos de software y objetivos que tienen algn significativo impacto sobre la arquitectura; por ejemplo: seguridad, privacidad de uso del producto, portabilidad, distribucin y reuso. Esto tambin captura las restricciones especiales que quizs apliquen en la: Estrategia de diseo e implementacin, herramientas de desarrollo, estructura del equipo, cronograma, leyes y regulaciones legales y otros. Las restricciones que aqu se recogen pueden complementar a las identificas en el RES a excepcin de aquellas funcionales.]

4.

Vista de Casos de Uso


[En sta seccin se listan los casos de uso o escenarios del modelo de casos de uso. Debe tomar como referencia lo desarrollado en el RES en los puntos punto 7.3, 7.4 y 7.5. Recuerde que debe respetar la codificacin indicada en

____________________________________________________________________________________
Reporte de Diseo de Software (RDS) Pgina 5 de 14

el RES para los paquetes y para los casos de uso. Si fuse necesario ampliar en esta seccin recuerde que es necesario se actualice el RES.]

5.

Vista Lgica
[La vista lgica est representada por los diagrama de clases del sistema donde se muestran sus relaciones estructurales y de herencia. La definicin de clase incluye definiciones para atributos y operaciones. El modelo de casos del punto 3 del presente documento uso aporta informacin para establecer las clases, objetos, atributos y operaciones.]

5.1.

Realizacin de Casos de Uso Modelo de Anlisis


[Esta seccin ilustra cmo el software trabaja a partir de los casos de uso o escenarios seleccionados, y explica cmo varios elementos del modelo de anlisis contribuyen con ellos funcionalmente. Por cada caso de uso deber desarrollar un diagrama de secuencia y de clases de anlisis. Para ello deber usar el patrn MVC. Para la realizacin deber identificar los escenarios. Dichos escenarios se obtienen de las combinaciones entre el flujo principal y flujos alternativos del la especificacin expandida de casos de uso (ver punto 7.8.2 del RES).]

5.1.1.

Cdigo del CUS Nombre del CUS Nombre del Escenario


[Identifica el escenario a ser realizado y una breve descripcin. Se recomienda identificar con un cdigo nico a cada escenario. Por ejemplo ESC01]

Diagrama de Secuencia de Anlisis


[Incluya el diagrama de secuencia de anlisis en el cual se observe el uso del patrn MVC que implementa el escenario identificado.]

5.1.2.

Diagrama de Clases de Anlisis


[Incluya el diagrama de clases de anlisis obtenido del conjunto de diagramas de secuencia que se implementan por cada escenario.]

5.2.

Modelo Conceptual
[Esta seccin ilustra cmo a partir de las clases del tipo entidad se pueden identificar una primera propuesta de modelo de persistencia. Para ello se utiliza un diagrama clases por cada paquete que forma parte de la arquitectura del sistema. Se puede hacer uso de tarjetas CRC para documentar las responsabilidades y colaboraciones de cada clase de persistencia identificada.]

5.3.

Modelo Lgico
[El modelo lgico es el refinamiento del Modelo Conceptual. Aqu se reducen y/o aumentan clases y slo quedan aquellas que van a ser diseadas como tablas de la Base de Datos. El modelo lgico debe representarse con un diagrama de clases de acuerdo a la arquitectura propuesta. Tenga presente que para la transformacin del modelo conceptual al modelo lgico se debe tener en cuenta: Pasar las reglas de negocio

____________________________________________________________________________________
Reporte de Diseo de Software (RDS) Pgina 6 de 14

Colocar las multiplicidades entre clases Identificar los atributos de Enlace o Clase de Enlace de las asociaciones de muchos a muchos NO INCLUIR los atributos identificadores de la clase (se agregarn en el modelo fsico) Incluir los atributos de las clases que se necesitan para satisfacer los requerimientos del sistema Documentar un registro de glosario de trminos Verificar que las reglas de negocio se sigan cumpliendo. Se sugiere que por cada clase se tenga un diccionario que incluya el nombre, el tipo, la descripcin, atributos, tipo de dato, visibilidad y valor inicial] Nombre Tipo Descripcin Atributo Nombre atributo del Nombre de la Clase Tipo de Clase (Ejemplo Entidad) Descripcin representa Tipo de Dato Integer String Boolean / / de la clase identificando que

Visibilidad Pblico Privado /

Valor inicial

5.4.

Modelo de Diseo
[En esta seccin debe representar el refinamiento del modelo de anlisis considerando los requisitos no funcionales identificados en el RES.]

5.4.1.

Vista de Capas y Subsistemas


[Incluir el diagrama en el que se represente la arquitectura de diseo. Para ello puede usar un patrn en el cual se usen capas y subsistemas. Adems deber identificar subsistemas requeridos por el uso de algn patrn de diseo como el DAO Factory, Singleton, Front Controller, entre otros. Por cada capa y subsistema deber identificar las clases de diseo que se implementarn]

____________________________________________________________________________________
Reporte de Diseo de Software (RDS) Pgina 7 de 14

<<layer>> Presentacion

<<layer>> Business

<<layer>> Integration

<<layer>> Interface <<layer>> Entidad <<layer>> Data

5.4.1.1. Capa de Presentacin


[Identifique las clases de diseo de la capa de presentacin. Ordene dicha identificacin utilizando los paquetes al interior de las capas denominados subsistemas.]

5.4.1.2. Capa de Negocio


[Identifique las clases de diseo de la capa de negocio. Ordene dicha identificacin utilizando los paquetes al interior de las capas denominados subsistemas.]

5.4.1.3. Capa de Integracin


[Identifique las clases de diseo de la capa de integracin. Ordene dicha identificacin utilizando los paquetes al interior de las capas denominados subsistemas.] ____________________________________________________________________________________
Reporte de Diseo de Software (RDS) Pgina 8 de 14

5.4.1.4. Capa de Datos


[Identifique las clases de diseo de la capa de datos. Ordene dicha identificacin utilizando los paquetes al interior de las capas denominados subsistemas.]

5.4.1.5. Capa de Entidad


[Identifique las clases de diseo de la capa de entidad. Ordene dicha identificacin utilizando los paquetes al interior de las capas denominados subsistemas.]

5.4.1.6.

Capa de Interfaces o Elementos Comunes


[Identifique las clases de diseo de la capa de elementos comunes. Ordene dicha identificacin utilizando los paquetes al interior de las capas denominados subsistemas.]

5.4.2.

Realizacin de Casos de Uso Modelo de Diseo


[Esta seccin deber desarrollar los diagramas de secuencia y de clases de diseo a partir de los requisitos no funcionales identificados en el RES y considerando los escenarios identificados en el punto 4.1 del presente documento. Debe asegurarse que las clases que se incorporen deben ser aquellas que se han identificado en el punto 4.4.1 del presente documento.]

5.4.2.1. Cdigo del CUS Nombre del CUS


[A partir de los casos de uso realizados del modelo de anlisis deber identificar los casos de uso que usar para las realizaciones de diseo.]

Nombre del Escenario


[Identifica el escenario a ser realizado y una breve descripcin. Se recomienda identificar con un cdigo nico a cada escenario. Por ejemplo ESC01. Deber reusar los escenarios identificados en el modelo de anlisis]

Diagrama de Secuencia de Diseo


[Incluya el diagrama de secuencia de diseo en el cual se observe el uso de patrones de diseo para las clases que implementarn cada una de las clases lgicas.]

5.4.2.2. Diagrama de Clases de Diseo


[Incluya el diagrama de clases de diseo obtenido del conjunto de diagramas de secuencia que se implementan por cada escenario.] ____________________________________________________________________________________
Reporte de Diseo de Software (RDS) Pgina 9 de 14

6.

Vista de Procesos
[Esta seccin describe la descomposicin del sistema en procesos de primer nivel (un solo hilo de control) y los procesos de ltimo nivel (grupos de procesos de primer nivel). Tambin describe la ubicacin de objetos y clases. Organizar la seccin por los grupos de los procesos que se comunican u obran recprocamente. Describir los modos principales de la comunicacin entre los procesos, tales como el paso de mensajes, interrupciones y qu pasa, las interrupciones, y puntos de encuentro entre procesos.]

7.

Vista de Despliegue
[En esta seccin se describen unas o ms configuraciones fsicas de la red (hardware) que se usarn para el despliegue de los componentes de software que forman parte de la solucin. Para ello puede usar un Diagrama de Despliegue indicando como mnimo, para cada configuracin, en qu nodos fsicos (computadoras, CPU) se ejecuta el software y sus interconexiones (bus, LAN, punto a punto, y as sucesivamente). De ser posible se debe incluir un mapeo de los procesos de la vista de procesos sobre los nodos fsicos. Adems deber especificar los detalles tcnicos de cada nodo en la vista de despliegue.]
S i s t e m a O p e r a t i v o W i n d o w s 2 0 0 0 / X P / 2 0 0 3 P r o f e s s s io n a l I n t e r n e t E x p l o r e r 6 . 0 o s u p e r i o r P C C l ie n t e I n t e P r nC o C l i e n t e I n t e r n o

I n t r a n

e t

S i s t e m a O p e r a t i v o W i n d o w s 2 0 0 3 S e r v e r I IS ( I n t e r n e t I n f o r m a t i o n S e r v e r ) N e t F r a m e w o r k 2 .0

S i s t e m a O p e r a t i v o W i n d o w s 2 0 0 3 S e r v e r C O M + ( C o m p o n e n t S i s t e m a O p e r a t i v o S e r v i c e s ) W i n d o w s 2 0 0 3 S e r v e r N e t F r a m e w o k 2 .0 S Q L S e r v e r 2 0 0 0

S In m u e b le s A d j u d i c a d o s P r e s u p u e s t o A

e r v i d

I n t r a nS e e t r v i d

o r

+ S

e r v i d o r

r c h i v o

x c e l S e r v i d o r B D O

i s t e m a O p e r a t i v o W i n d o w s 2 0 0 3 S e r v e r S Q L S e r v e r 2 0 0 0 S i s t e m a s : S p r i n g ( M a c r o ) C o n t a b i l i d a d M C A d e l a n t o s ( M a c r o ) t r o s P Sr oi s v t i es mi o an s e s ( M a c r o ) I n m u e b l e s P r o p i o s

DS

I n W e b S e r v i c e

t e r n e t S p r i n P g a g o A c t i v o H O S T M a in f r a m e I B M Z S C o m p r o b a n t e s C o n t a b i l id a d e r ie s

I n t e r f a c e

8.

Vista de Implementacin
[En esta seccin se describe la estructura total del modelo de implementacin, utilizando la descomposicin del software en capas y subsistemas y cmo ste se pondr en prctica. Deber identificar cualquier componente arquitectnico significativo. Debe nombrar y definir las capas y contenidos de las mismas, las reglas que gobiernan la inclusin de una u otra capa, y las caractersticas entre capas. Incluya el diagrama de componentes que muestra las relaciones entre capas. Para cada capa, incluya una sub-seccin con el nombre de la capa, una enumeracin de los subsistemas localizados dentro de la capa y un diagrama de componentes.]

9.

Vista de Integracin del Software


[De requerirlo en esta seccin pude incluir un diagrama integracin del software desarrollado y su interaccin con las diferentes interfaces identificadas en el modelo de diseo.]

____________________________________________________________________________________
Reporte de Diseo de Software (RDS) Pgina 10 de 14

INTERFAZ INT1

DESCRIPCION BREVE La interfaz 1 apoya la integracin del Paquete 1 y el Paquete 2, incluye las clases C1, C2, etc. La interfaz 1 apoya la integracin del Paquete 1 y el Paquete 2, incluye las clases C1, C2, etc.

TIPO DE INTERFAZ Interfaz Interna

REFERENCIA La Especificacin de esta interfaz se encuentra en el documento de Especificacin de Componentes La Especificacin de esta interfaz se encuentra en el documento de Especificacin de Componentes La Especificacin de esta interfaz se encuentra en el documento de Especificacin de Componentes La Especificacin de esta interfaz se encuentra en el documento de Especificacin de Componentes La Especificacin de esta interfaz se encuentra en el documento de Especificacin de Componentes

INT2

Interfaz Interna

INT3

Interfaz Interna

INT4

Interfaz Externa

INT5

Interfaz Externa

9.1.

Criterios de Integracin de Software


[Identifique los criterios que se debern considerar para la integracin de los componentes de software y sus interfaces. Ejemplo: Para la ptima integracin del Software se debern tener que cumplir, considerar y evaluar los siguientes criterios:

____________________________________________________________________________________
Reporte de Diseo de Software (RDS) Pgina 11 de 14

Antes de realizar la integracin todos los componentes debern haber pasado por pruebas unitarias. Antes de realizar la integracin, todas las incidencias, errores u otras no conformidades encontradas durante las pruebas unitarias debern estar cerradas. Se deber tener preparado los ambientes y entornos para la integracin (Entorno de Desarrollo o Entorno de Integracin). Deber haberse inicializado y migrado data consistente previa a la integracin. Otros Criterios que apoyen a que la integracin resulte un xito.]

9.2.

Secuencia de Integracin
[Defina la secuencia de integracin que componentes de software y sus interfaces. Ejemplo: Para que el Software se integre totalmente se seguir la siguiente secuencia de integracin: Realizar las pruebas unitarias a todos los componentes Levantar todos los errores e incidencias encontradas en las Realizar revisin de pares al cdigo fuente y levantar las no Asegurarse que todos los componentes del Sistema estn desarrollados (De todos los mdulos). pruebas unitarias (De todos los mdulos). conformidades. completamente corregidos (Realizacin de nuevas pruebas sobre los errores encontrados). Validar que el entorno de integracin este listo. Validar que la data haya sido migrada satisfactoriamente. Iniciar la integracin o Integrar Modulo 1 y Modulo 2 - Realizar pruebas de integracin entre ambos mdulos. o Integrar Modulo 1 y Modulo 2 y Modulo3 pruebas de integracin entre mdulos. o Integrar Modulo 1 y Modulo 2 y Modulo n - Realizar pruebas de integracin entre mdulos. Finalizada la Integracin entre mdulos, realizar la integracin con aplicativos externos al sistema en desarrollo. o Integrar Sistema en desarrollo con Sistema Externo1 (Aplicativo Externo) y Realizar Pruebas. o Integrar Sistema en desarrollo con Sistema Externo2 (Aplicativo Externo) y Realizar Pruebas. Finalmente realizar las pruebas del Sistema y luego de ellas
Pgina 12 de 14

se

aplicarn

los

Realizar

____________________________________________________________________________________
Reporte de Diseo de Software (RDS)

las Pruebas de Aceptacin con los Usuarios Finales.]

9.3.

Entorno Necesario para la Integracin


[En esta seccin se debern identificar y especificar los diversos entornos que se usarn o que estn involucrados en la integracin del Software.]

NOMBRE DEL SERVIDOR IP

Serv_Desa 1.1.15.50

DESCRIPCION Y OBJETIVO DEL SERVIDOR En este servidor se almacenar el cdigo fuente, en este entorno trabajaran los desarrolladores. Aqu se realizarn las pruebas unitarias. SERVICIOS NOMBRE DE APLICACIN FUNCIN INICIO USUARIO SERVICIO Por Ejemplo: Por ejemplo: Por ejemplo: Asynchronous AJAX Presentacin JavaScript + basada en Automtico Adminservice XML estndares usando XHTML y CSS <Servicio 1> <Aplicacin 1> <Funcin 1> Local System Automtico Account <Servicio 2> <Aplicacin 2> <Funcin 2> Local System Automtico Account <Servicio N> <Aplicacin N> <Funcin 1> Local System Automtico Account CONFIGURACIN DE HARDWARE Y SOFTWARE Nombre del Sistema Operativo Version Proveedor del Sistema Operativo Nombre del Sistema Proveedor del Sistema Modelo del Sistema Tipo del Sistema Procesador BIOS Version/Date SMBIOS Version Total de Memoria Fsica Promedio de Memoria Fsica Total de Memoria Virtual Promedio de Memoria Virtual Tipo de Adaptador
Reporte de Diseo de Software (RDS)

Microsoft ( R) Windows (R ) Server 200.Enterprise Edition 2.2.3790 Service Pack 2 Build 3790 Microsoft Corporation DEIPSBATCH IBM -[865811Y]X86 based PC x86 Family 6 Model 8 Stepping 3 Genuineintel 664 IBM ILKT44AUS, 20/09/2001 2.1 2,047.49 MB 1.37 GB 3.86 GB 3.47 GB Ethernet 802.3
Pgina 13 de 14

____________________________________________________________________________________

Tipo de Producto Nombre del Servicio Direccin IP Mscara de Sub Red IP Gateway IP DHCP Enabled DHCP Server MAC Address Memory Address SOFTWARE ADICIONAL USARIOS CON PERMISOS AL SERVIDOR RELACION CON OTROS SERVIDORES

IBM Netfinity Fault Tolerante PCI Adapter PCNet5 10.203.32.9 255.255.255.0 10.203.32.254 No Not Available 00:06:29:D5:38:0F 0XFEB7FC00-0XFEB7FC1F

10. Vista de Datos


[Se debe describir la perspectiva persistente del almacenaje de datos del sistema. Deber incluir el Modelo de Base de Datos Lgico y Fsico, as como el diccionario de datos.]

11. Tamao y Desempeo


[En esta seccin se pueden incluir descripciones de las principales caractersticas del dimensionamiento del software que afectan la arquitectura, as como las restricciones de desempeo. Si trabajo estas caractersticas en el RES haga referencia a dicho documento.]

____________________________________________________________________________________
Reporte de Diseo de Software (RDS) Pgina 14 de 14

You might also like