2.

3 DESCRIPCION DE LA METODOLOGIA DE DESARROLLO

2.3.1 REQUERIMIENTOS
Este workflow es desarrollado principalmente durante las fases de concepcin
y elaboracin
Requerimiento: es una condicin o capacidad a la cual el sistema debe
satisfacer.
2.3.1.1 DESCRIPCIN DE LA ORGANIZACIN.
Comprende informacin respecto a la organizacin donde se
desarrolla el proyecto antecedentes histricos, isin, misin y
ob!etios de la organizacin.
1. IDENTIFICACIN DEL PROBLEMA INICIAL.
"ermite conocer los problemas m#s frecuentes que afronta la
organizacin.
2.3.1.2 IDENTIFICACIN DE LOS ACTORES Y ENTIDADES DE LA
ORGANIZACIN.
$e identifican los diferentes actores y entidades a fin de conocer los
roles que desempe%an cada uno de ellos en la organizacin.
1. CREACIN DE UNA TABLA DE EVENTOS DEL SISTEMA.
&a tabla de eentos permite esquematizar los eentos principales
reconocidos por el sistema como producto de la interrelacin con los
actores e'ternos (er tabla )* +,-.
Eento: es cualquier ocurrencia significatia en una aplicacin que es
iniciada por el usuario o por la misma aplicacin.
Tabla N 1! ELEMENTOS DE LA TABLA DE EVENTOS
SU"ETO VERBO OB"ETO RESPUESTA
Es un actor
definido
inicialmente en
la
organizacin.
Es la accin
realizada por el
su!eto.
Es el elemento
que recibe la
accin definida
en el erbo.
Es el resultado
producido por
la accin
realizada entre
el erbo y el
ob!eto.
2.3.1.3 MODELO DEL NEGOCIO #OPCIONAL$
.escribe y representa esquem#ticamente el proceso de negocios de la
organizacin tal cual se da en la realidad, en t/rminos de clases y actores de
negocios. "ueden generarse algunas clases iniciales que no est#n presentes
a0n en la organizacin, dependiendo de la capacidad de abstraccin del
desarrollador (er tabla )* +1-.
Tabla N 2! ELEMENTOS DEL MODELO DEL NEGOCIO
CLASE DESCRIPCIN ESTEREOTIPO
A%&'(
Es un agente e'terno (personas,
software, dispositios de hardware-
que interact0a directamente con el
sistema.

)'(*+(
Es el agente responsable de realizar
una o m#s tareas dentro del sistema,
producto de la interaccin con el actor.

E,&-.a.
Representa una entidad del mundo
real que encapsulan datos y que es
manipulada directamente por el woker
para la consecucin de tareas
espec2ficas.

2.3.1./ MODELO DEL DOMINIO #OPCIONAL$
Representa las clases (entidades- m#s importantes encontradas en el
diagrama del modelo de negocios de manera relacional (er tabla )* +3-.
Tabla N 3! TIPO DE RELACIONES ENTRE CLASES
TIPO DE
MULTIPLICIDAD DESCRIPCIN
U,' 0 U,' Representada por: ,
C+(' 0 U,' Representada por: + .. ,
U,' 0 M1%2'3 Representada por: , .. 4
C+(' 0 M1%2'3 Representada por: (4-
M1%2'3 0 M1%2'3 Representada por: m 5 n
1. MODELO DE CASOS DE USO
El modelo de Casos de 6so, especifica una secuencia de acciones que son
iniciadas por un actor desencadenado interacciones entre el actor y el
sistema, siendo completa luego de retornar un alor al actor (er tabla )*
+7-.
Tabla N /! ELEMENTOS DEL USE CASE
CLASE DESCRIPCIN ESTEREOTIPO
A%&'(
Es un agente e'terno (personas,
software, dispositios de hardware-
que interact0a directamente con el
sistema.

U3+
Ca3+
Corresponde a un agregado de
funcionalidad o sericios proe2dos
por un sistema a los usuarios.

2.3.1.4.1 RELACIN ENTRE ELEMENTOS DE UN CASO DE USO.
ASOCIACIN! Es el tipo de relacin e'istente entre 8ctores, Casos de 6so o
ambos, pueden ser:
2.3.1.4.1.1 CASO DE USO 0 CASO DE USO
ASOCIACIN 55-,%l1.+66
<<include>>
UseCaseA UseCaseB
9r#fico ): +7: 8sociacin ;;6ses<< entre 6se Case.
9r#fico ): +=: 8sociacin ;;E'tend<< entre 6se Case.
9r#fico ): +>: ?erencia entre 6se Case.
El Caso de 6so 8 utiliza todos los sericios
proe2dos por el Caso de 6so @
ASOCIACIN 55+7&+,.66
<<extend>>
UseCaseB UseCaseA
El Caso de 6so @ (Caso de 6so E'tendido- ser# e!ecutado
cuando al ser e!ecutado el Caso de 6so 8 (Caso de
6so @ase-, se den las condiciones que actien al Caso
de 6so @
GENERALIZACIN
6seCase 8
6seCase @
El Caso de 6so @ es una especializacin del Caso de 6so 8,
esto es @ hereda la funcionalidad de 8, pero adem#s
contiene otras funcionalidades que lo diferencian. El
Caso de 6so @ puede remplazar a 8
9r#fico ): +A: 8sociacin 8ctor B 6se Case.
2.3.1.4.1.2 ACTOR 0 CASO DE USO. Conocidos tambi/n como
relaciones de actiacin, es de tipo unilateral (er gr#fico )* +A-.
ACTOR 0 USE CASE 55%'81,-%a&+366
Actor
UseCase
<<Comunicates>>
1. ACTOR 0 ACTOR. Conocidas tambi/n como relaciones de flu!o de
informacin. Este tipo de relacin puede ser: unilateral o bilateral (er
gr#fico )* +C-.
ACTOR 0 ACTOR
8ctor 8
8ctor @ 8ctor C
El 8ctor @ es una especializacin del 8ctor 8, esto es @
hereda el comportamiento de 8, pero adem#s posee otras
caracter2sticas que lo diferencian de 8, y que le permiten
tener un comportamiento mas especializado. @ puede
eentualmente reemplazar a 8 (lo mismo para C-.
9r#fico ): +C: 8sociacin entre 8ctores.
2.3.1.9 ARQUITECTURA PRELIMINAR DEL SISTEMA.
$e establece una arquitectura inicial del sistema en funcin a los
requerimientos m2nimos de hardware y software.
1. ESTUDIO DE FACTIBILIDAD.
$e determina si es posible realizar o no el proyecto en t/rminos t/cnico,
operatio y econmico.
2.3.1.: PROTOTIPO INICIAL
$e dise%an las interfaces de usuarios que permiten representar los 6se Case de
manera efectia y clara.
2.3.2 ANALISIS.
Este workflow es desarrollado principalmente durante la fase de elaboracin y
parte de la fase de concepcin.
2.3.2.1 SELECCIN DE LA ;ERRAMIENTA CASE.
"ermite seleccionar el me!or C8$E (Dngenier2a de $oftware 8sistido por
Computadora- para el modelamiento del sistema inform#tico ha desarrollarse, el
cual debe cumplir con los est#ndares internacionales m#s utilizados.
1. IDENTIFICACIN Y EVALUACIN DE LOS RIESGOS CR<TICOS.
"ermite la identificacin de los riesgos cr2ticos por el cual puede atraesar el
proyecto en su proceso de desarrollo, as2 como las consecuencias que conllean
dichos riesgosE por tal motio se describen los posibles riesgos y se realizan los
planes de contingencia (er tabla ): +=-.
RIESGO! Es un suceso inesperado que podr2a presentarse en cualquier momento
durante el desarrollo del proyecto. .ado que los riesgos afectan al proyecto de
manera significatia se deben identificar una lista de riesgos cr2ticos para el
proyecto.
Tabla N =! ELEMENTOS DE EVALUACIN DE RIESGOS
CR<TICOS
EVALUACIN DESCRIPCIN
D+3%(->%-?,
Es una bree descripcin de los riesgos iniciales
que podr2an incrementarse durante el
desarrollo del proyecto.
P(-'(-.a.
Corresponde a los alores de prioridad
asignados a cada riesgo de acuerdo al impacto
que tiene sobre el proyecto.
"uede tomar los siguientes alores: critico,
significante y rutina.
I8>a%&'
Corresponde a las partes del proyecto o
software que son afectados por el riesgo.
M',-&'(
$on las personas responsables de realizar un
seguimiento al riesgo.
R+3>',3ab-l-.a.
$on las personas u organizaciones
responsables para corregir el riesgo.
9r#fico ): +F: 6se Case de Realizacin del 8n#lisis.
C',&-,@+,%-a
$on las consecuencias que podr2an presentarse
si los riesgos son materializados.
2. MODELO DEL ANALISIS.
6n modelo de ob!eto con el propsito de describir los requerimientos en forma
m#s precisa, de tal manera que facilite su entendimiento y funcione como punto de
entrada en el dise%o y la implementacin.
1. CASO DE USO DE REALIZACIN DEL ANALISIS.
Es elaborado directamente (Grace- del modelo 6se Case en t/rminos de clases e
interacciones entre los ob!etos del an#lisis. (er gr#fico )* +F-
Giene una descripcin te'tual del flu!o particular o escenario de 6se Case en
t/rminos de interacciones de los ob!etos del an#lisis (requerimientos funcionales-.
CLASE! Es una descripcin de un con!unto de ob!etos que comparten los mismos
atributos, operaciones, relaciones y sem#ntica.
2. DIAGRAMA DE CLASES.
Representa abstracciones de clases y sus relaciones. Huestra los roles comunes
y las responsabilidades de las entidades que proporcionan el comportamiento del
6seCase Realizacion del 8n#lisis
6seCase
Hodelo 6se Case Hodelo del 8n#lisis
sistema. El diagrama de clases utiliza los siguientes elementos o clases: (er tabla
)* +>-.
Tabla N B! ELEMENTOS DEL DIAGRAMA DE CLASES
CLASE DESCRIPCIN ESTEREOTIPO
I,&+(Ca%+
Representa la interaccin entre
actor y el sistema.

C',&('l
Representa una restriccin o
regla de negocio del sistema.

E,&-.a.
$e usa para modelar
informacin persistente.

2.3.2.2 DIAGRAMA DE COLABORACIONES.
Es un diagrama de clases, e'cepto que posee enlaces que representan
operaciones entre ob!etos as2 como el sentido de las mismas. Godo diagrama de
colaboraciones debe tener flu!o de eentos.
1. PAQUETE.
Es un mecanismo de propsito general para organizar los elementos en grupo.
2.3.2.4.1 PAQUETE DEL ANALISIS.
8grupan un con!unto de clases y sus asociaciones de acuerdo a su funcionalidad
y dominio del problema.
1. PAQUETE DE SERVICIO.
6n sericio representa un con!unto coherente de funcionalidad relacionado a
accionesE es decir un paquete de funcionalidad que es empleado en diersos 6se
Case.
8lgunas eces los paquetes de sericio pueden proeer funcionalidad alternatia
relacionada a un mismo sericio.
2.3.3 DISEDO.
Este workflow es desarrollado principalmente durante la fase de elaboracin y
parte de la fase de construccin.
2.3.3.1 SELECCIN DEL LENGUA"E DE PROGRAMACIN.
"ermite seleccionar el me!or lengua!e de programacin orientada al ob!eto para el
desarrollo del sistema inform#tico ha implementarse, el cual debe cumplir con los
est#ndares internacionales m#s utilizados.
1. SELECCIN DEL MANE"ADOR DE BASE DE DATOS.
9r#fico ): ,+: 6se Case de Realizacin del .ise%o.
"ermite seleccionar el sistema de gestin de la base de datos de gran
energadura, las cuales ofrezcan enta!as y desenta!as relatias respecto a
otras.
2. MODELO DEL DISEDO.
6n modelo de ob!eto que describe la realizacin f2sica de un 6se Case y enfoca
cmo los requerimientos funcionales y no funcionales as2 como otras restricciones
relacionadas a la implementacin impacta el sistema.
2.3.3.3.1 CASO DE USO DE REALIZACIN DEL DISEDO.
6n 6se Case realizacin del dise%o es una colaboracin con el modelo del dise%o
que describe como un 6se Case especifico es realizado y presentado en t/rminos
de clase de dise%o y sus ob!etos. "roee un enlace directo hacia el 6se Case
realizacin del an#lisis (er gr#fico )* ,+-.
1. DIAGRAMA DE CLASES.
Contiene los iconos que representan clases, interfaces y sus relaciones en el
dise%o lgico de un sistema. 8s2 mismo captura la estructura de las clases que
forman parte de la arquitectura del sistema (er gr#fico )* ,,-.
6seCase Realizacion del .ise%o 6seCase Realizacin del 8n#lisis
Hodelo del 8n#lisis Hodelo del .ise%o
9r#fico ): ,,: Representacin de las Clases del .ise%o.
&as clases del dise%o ser#n implementadas por componentes que contienen el
cdigo fuente.
ClaseA
AtributoA
AtributoB
OperacionA()
OperacionB()
SUBSISTEMA! Es una agrupacin de elementos que constituye una
especificacin del comportamiento dado por los elementos contenidos.
2. DIAGRAMA DE SUBSISTEMAS DEL DISEDO.
&uego de realizar una apropiada descomposicin de los paquetes del an#lisis, se
utilizan los paquetes para identificar los correspondientes subsistemas con el
modelo de dise%o. $in embargo, est# identificacin general es refinada en el
dise%o para mane!ar aspectos relacionados al dise%o, implementacin y
despliegue del sistema.
.urante la elaboracin de los subsistemas de dise%o se pueden encontrar nueos
sericios que en el futuro el sistema debe proeer, para ello se debe crear un
nueo subsistema de sericio que soporte dicha funcionalidad para ser reutilizado
por otros subsistemas del dise%o.
3. DIAGRAMA DE COLABORACIONES.
Huestra una secuencia de mensa!es que implementan una operacin o una
transicin, es decir los ob!etos, enlaces y mensa!es.
/. DIAGRAMA DE SECUENCIA.
Huestra el orden cronolgico de la transicin de mensa!es entre los ob!etos. 6n
ob!eto se representa por un rect#ngulo con una l2nea ertical deba!o de /l, la l2nea
permite crear los mensa!es entre los ob!etos.
2.3./ IMPLEMENTACIN.
Este workflow es desarrollado principalmente durante las fases de construccin,
transicin y parte de la fase de concepcin y elaboracin.
El ob!etio principal de la implementacin es unir la arquitectura y el
sistema como un todo.
2.3./.1 DISEDO FISICO DE LA BASE DE DATOS.
Comprende la creacin de la base de datos completa en un $istema de 9estin
de @ase de .atos. (.@H$-
2.3./.1.1 MAPEO DE CLASES A TABLAS
En un $istema de 9estin de @ase de .atos Relacional (R.@H$- las clases
persistentes pueden ser mapeadas a tablas relacionales, seg0n se indica a
continuacin.
1. MAPEO DE ATRIBUTOS A COLUMNAS.
&os atributos de las clases, persistentes pueden ser mapeados a columnas de una
tabla. 8unque a muchos proeedores de R.@H$ implementan o cambian los
tipos de datos est#ndares definidos en $I&BF1.
2. MAPEO DE LA ASOCIACIN.
Es un modelo de clases de datos persistentes se debe considerar lo siguiente (er
tabla )* +A-.
Tabla N 4! DESCRIPCIN DE LOS TIPOS DE RELACIN
TIPO DE RELACION DESCRIPCIN
U,' 0 U,'
$i la relacin es opcional, se implementa la
asociacin como dos tablas separadas. &a
clae primaria de la tabla principal es clae
for#nea de la tabla secundaria.
U,' 0 M1%2'3
Crear una tabla para cada clase tabla 8 y @.
&a clae primaria de la tabla en el lado de
uno de la asociacin (tabla 8- es una tabla
for#nea en el lado de muchos de la
asociacin (tabla @-.
M1%2'3 0 M1%2'3
Crear una tabla para cada clase tablas 8 y @,
adem#s de una tabla de interseccin
adicional tabla C. &as claes primarias de las
tablas 8 y @, son definidas como clae
for#neas en la tabla C.
&a clae primaria de la tabla interseccin
podr2a ser una columna separada, 0nica
(clae primaria substituta, la cual es
generada-. J podr2a ser compuesta de las
dos claes for#neas de las tablas 8 y @.
3. MAPEO DE LA AGREGACIN Y COMPOSICIN.
Es frecuentemente este tipo de relacin que inolucra la creacin de dos tablas
con relacin de 6no 5 6no.
/. MAPEO DE LA GENERALIZACIN.
&a generalizacin especifica una relacin K6n tipo deL entre dos tablas. El modelo
de datos correspondiente especifica dos tablas y una relacin de identificacin, en
donde la clae primaria de la tabla base migra a la tabla especializada como clae
primaria y for#nea a la ez.
2.3./.2 GENERACIN DEL LENGUA"E DE DEFINICIN DE DATOS. #DDL$
E'isten actualmente en el mercado herramientas C8$E que permite la generacin
del &engua!e de .efinicin de .atos a partir de la clase de dise%o.
1. GENERACIN DEL LENGUA"E DE MANIPULACIN DE DATOS.
#DML$
El &engua!e de Hanipulacin de .atos fue construido para garantizar la integridad
en los datos y soportar las reglas de negocios de la aplicacin.
2.3./.3 CONSTRUCCIN DE LAS GUI DE LA APLICACIN.
"ara desarrollar o redefinir interfaces de usuario se deben tener en cuenta ciertos
principios en cuanto a funcionalidad y est#ndares de dise%o. En general las
interfaces de usuario refle!an dos aspectos importantes:
- .eben ser capaces de proeer al usuario todos los datos que necesita
suministrar y toda la informacin que necesita obtener sobre algo en particular.
- .eben contener est#ndares internacionales y detalles espec2ficos, de tal manera
que las interfaces sean totalmente consistentes (er tabla )* +C-.
8 continuacin presentamos una tabla con algunos est#ndares internacionales
de programacin:
Tabla N 9! ESTANDARES PARA LA CONSTRUCCIN DEL GUI
CRITERIOS DESCRIPCIN
L'%al-Ea%-?, .+ l'3
B'&',+3
E3&F,.a(+3
Godos los botones son localizados en la
parte derecha. El primer botn de
la derecha deber# ser cancelar.
E3>+%-C-%a%-',+3 .+
F1+,&+3
Godos los di#logos deben utilizar el tipo 8rial
con tama%o ,+.
P'3-%-?, .+ la3 V+,&a,a3
.+ D-al'@'
Godos los di#logos deben estar centrados en
el #rea del cliente del programa.
I,C'(8a%-?, .+ A%1+(.' al
C'l'(
Godos los elementos de los di#logos
est#ndares deben utilizar colores del
sistema definidos por el usuario.
O(.+, .+l Tab
El orden de tabulacin debe ser de izquierda
a derecha y de arriba hacia aba!o.
2.3.= PRUEBA.
&a prueba se realiza durante todo el ciclo de desarrollo del software enfatizando
en la parte de construccin y fase de transicin.
2.3.=.1 MODELO DE PRUEBA.
6n modelo que describe como los componentes e!ecutables en el modelo de la
implementacin son probados por las pruebas de integracin y del sistema.
$e erifica el resultado de la implementacin probando cada construccin, as2
como las ersiones finales del sistema.
2.3.=.1.1 CASOS DE PRUEBA.
.escribe una manera de probar el sistema utilizando entradas, salidas y ciertas
condiciones de prueba para cada 6se Case. Esta prueba comprende dos
aspectos:
2.3.=.1.1.1 PRUEBA DE CA"A NEGRA.
Especifica como probar un 6se Case o un Escenario Especifico de un 6se Case.
Esta prueba es realizada para probar el comportamiento obserable e'terno del
sistema.
1. PRUEBA DE CA"A BLANCA.
Especifica como probar una realizacin de un 6se Case del dise%o o un escenario
especifico del mismo. Gal prueba puede incluir la erificacin de la interaccin
interna entre los componentes del sistema.
2.3.=.1.1.2 OTRAS PRUEBAS.
$on realizadas para probar el sistema en su totalidad.
- "rueba de Dnstalacin. Merifica que el sistema funcione correctamente cuando
est# instalado.
- "rueba de Configuracin. Merifica que el sistema funcione correctamente en
diersas configuraciones, tal como configuraciones del equipo o red.
- "rueba de Estr/s. Ddentifica los problemas en el sistema cuando e'isten
recursos insuficientes.
- "rueba de Error. Grata de proocar errores cr2ticos al sistema para encontrar
sus deficiencias.
1. PROCEDIMIENTOS DE PRUEBA.
.escribe cmo se presenta una o m#s pruebas de casos o partes de ellas.
Como presentar una prueba de casos podr2a ser especificado por una
prueba de procedimientos o iceersa.