Proyecto Final Software

PROYECTO:
SISTEMA DE FACTURACION E INVENTARIO

(FACTINV)
DOCUMENTO GENERAL
Documento General 1
Contenido
INTRODUCCION............................................................................................................3
MOTIVACION.................................................................................................................4
OBJETIVO..................................................................................................................... 5
GLOSARIO DE TERMINOS..........................................................................................6
PRIMERA PARTE:.........................................................................................................
ADMINISTRACIN DEL PROYECTO...........................................................................7
Introducc!n...................................................................................................................."
O#$et%o...........................................................................................................................&
Gru'o de Tra#a$o............................................................................................................&
Modelo del Proce(o de So)t*are ...................................................................................&
Planeac!n.....................................................................................................................11
Re+uermento( de recur(o( de ,ard*are - So)t*are..............................................11
De)nc!n de Act%dade(.........................................................................................1.
Calendar/ac!n del Pro-ecto....................................................................................10
Admn(trac!n de Re(1o(...........................................................................................1&
SEGUNDA PARTE:.....................................................................................................!3
RE23ERIMIENTOS DEL SISTEMA.............................................................................4.
Introducc!n..................................................................................................................45
E(tudo de 6act#ldad.................................................................................................40
6act#ldad Econ!mca.............................................................................................40
6act#ldad O'erat%a...............................................................................................40
6act#ldad T7cnca..................................................................................................40
O#tenc!n - An8l(( de Re+uermento(......................................................................49
M7todo :ORD..........................................................................................................49
Documento General 4
INTRODUCCION
La simulacin asistida por computador consiste bsicamente en construir modelos
informticos que describen la parte esencial del comportamiento de un sistema de inters,
y proceder a experimentar con estos modelos, para extraer conclusiones de sus
resultados que permitan apoyar la toma de decisiones. La simulacin ha crecido como
una metodologa de experimentacin fundamental en campos tan diversos como la
Economa, la Estadstica, la nformtica o la !sica y con enormes aplicaciones
industriales y comerciales, como los simuladores de vuelo, los "uegos de simulacin, los
procesos industriales, o la prediccin burstil o meteorolgica. En lo que respecta al
mbito industrial la simulacin de procesos es una las herramientas ms utili#adas por la
ingeniera industrial, por lo general una ve# que se detecta que cierto sistema de inters
no opera en forma adecuada, se plantea al ingeniero la forma de me"orar el
funcionamiento del mismo, y para ello emplea la simulacin, ya que en la mayora de los
casos experimentar con el sistema real tomar mucho tiempo, ser costoso y adems
tendr que interrumpir el funcionamiento actual de las operaciones que e"ecuta el sistema
dentro de la empresa. El modelo debe permitir estudiar, predecir o explicar un fenmeno,
proceso o metodologa con un grado de precisin determinado. El grado de precisin del
modelo est asociado a factores como la definicin de las variables relevantes que
explican el sistema, la interrelacin de estas en el modelo y el nivel en que el modelo
representa el sistema real. En trminos generales, un modelo debe ser una
representacin aceptable de la realidad, es decir, debe existir una buena correlacin entre
lo que predice el modelo y lo que sucede en la realidad. $ara tener la certe#a de que se a
alcan#ado esta correlacin, resulta indispensable reali#ar un proceso de validacin. El
desarrollo del sistema de informacin propuesto, esta orientado a proporcionar un
ambiente de prueba, que permita validar modelos representados como ecuaciones
algebraicas diferenciales, capaces de representar en forma adecuada gran parte de los
procesos industriales actuales.
Este documento describe el proceso del soft%are seleccionado para &nali#ar, 'ise(ar,
codificar y $robar el desarrollo de un sistema de !acturacin e nventario )!&*+,-.. El
documento se encuentra dividido en cinco partes principales, como a continuacin se
describe/
. $rimera parte/ 'escripcin de la &dministracin del proyecto.
. 0egunda $arte/ 0e encuentra documentada la ngeniera de 1equisitos.
. +ercera $arte/ *ontiene el 'ise(o del proyecto.
-. *uarta $arte/ $resenta la -alidacin, -erificacin y $ruebas del proyecto.
Documento General .
MOTIVACION
$ara que todo proceso de simulacin sea 2til, es necesario que el modelo sea una
representacin aceptable de la realidad, es decir, debe existir una buena correlacin entre
lo que se simula y lo que sucede en la realidad, y para establecer adecuadamente esta
correlacin resulta indispensable reali#ar un proceso de validacin. La validacin de un
modelo es un problema, relativamente comple"o. 0i se dice que un modelo es correcto o
vlido, significa que est representando en forma adecuada el sistema real, pero es obvio
que nunca se puede estar absolutamente seguro y ning2n modelo, por ms sofisticado
que sea, puede representar exactamente la realidad, y siempre ser una aproximacin del
sistema real. $or lo tanto se considera que en el proceso de validacin de un modelo, se
trata de obtener el mayor grado de confian#a posible para su uso. En trminos generales
la validacin de un modelo est relacionada con la necesidad de efectuar un con"unto de
pruebas que permitan verificar que tan seguro es utili#ar el modelo propuesto, y esto
depender de lo aproximado que sea la salida real y la calculada mediante la simulacin,
sin pretender en ning2n momento que esta sea una representacin exacta de la realidad.
$or otro lado el con"unto de pruebas a reali#ar se puede generali#ar de forma tal que sean
independientes del modelo que se desea validar, lo que permitir aplicarlas a varios
modelos que pretenden simular diferentes procesos industriales de inters y mientras
menos sesgadas sean las pruebas reali#adas, ms fiable ser el proceso de validacin.
En vista de que es com2n que dentro de una empresa conver"an diferentes procesos
industriales, y que el proceso de validacin de un modelo es indispensable para que este
sea aplicado en forma segura, resulta sumamente interesante abstraer el proceso de
validacin, ganando as generalidad en dicho proceso, esto permitir reducir los costos de
prueba, ya que no hay que dise(ar un proceso de validacin para cada modelo, por otro
lado al hacer que el con"unto de pruebas a reali#ar, sean lo ms independientes posibles
del modelo, los resultados obtenidos sern mucho ms confiables, estas dos
caractersticas generalidad para reducir costos y confiabilidad en los resultados obtenidos,
constituyen sin duda alguna la motivacin principal para desarrollar el sistema de
informacin propuesto.
Documento General 5
OBJETIVO
El ob"etivo del presente proyecto es el desarrollo de un sistema de !acturacin e
nventario para un negocio dedicado a la compra y venta de hules industriales y
automotrices, el negocio desea llevar control y mantener actuali#ados sus
registros de adquisiciones, ventas, proveedores, clientes e inventario de productos
en bodega.
En la figura 3, se presenta el diagrama lgico del sistema.

Figura 1 Diagrama lgico del sistema de Facturacin e Inventario.
Documento General 0
*45$1&0
-E,+&0
,-E,+&14
*LE,+E0
$14-EE'41
E0
ADMINISTRACION DE
CLIENTES Y
PROVEEDORES
*45$1&0 6
-E,+&0
*4,+14L 'E
,-E,+&14
1E$41+E0
SISTEMA PRINCIPAL
GLOSARIO DE TERMINOS
Trmino De!ri"!i#n
!&*+,- 0istema de !acturacin e nventario
7' 7ase de 'atos
*&0E *omputer8&ided 0ystems Engineering, traduccin
ngeniera de 0istemas &sistida por *omputadora
1t0 1eal +ime 0tudio, traduccin Estudio en +iempo 1eal
970 9or: 7rea:do%n 0tructure
$40 $ro"ect 4vervie% 0tatement
,&4E nstituto ,acional de &strofsica, ;ptica y Electrnica
-41' 'efinicin de requerimientos orientados a puntos de vista
Documento General 9
PRIMERA PARTE:
ADMINISTRACIN DE !R"#ECT"
Documento General 7
In$ro%&!!i#n
La A%mini$r'!i#n %e Pro(e!$o es un mtodo y un con"unto de tcnicas
basadas en los principios aceptados de la &dministracin usados en la planeacin,
estimacin y control de actividades de traba"o para alcan#ar un resultado final
deseado en tiempo, dentro de un presupuesto asignado y acorde a una
especificacin.
La gestin de un proyecto de soft%are comien#a con un con"unto de actividades
que globalmente se denominan administracin o $laneacin del $ro%ecto.
&ntes de que el proyecto comience, el administrador y el grupo de traba"o deben
reali#ar una estimacin del traba"o a reali#ar, de los recursos necesarios y del
tiempo que transcurrir desde el comien#o hasta el final de su reali#acin.
0iempre que estimamos, lo hacemos mirando hacia el futuro y debemos aceptar
resignados cierto grado de incertidumbre. & pesar de que resulta sumamente
difcil estimar, existen un con"unto de tcnicas 2tiles para la estimacin del
esfuer#o y del tiempo. Las mtricas del proyecto y del proceso proporcionan una
perspectiva histrica y una potente introduccin para generar las estimaciones
cuantitativas, por otro lado la experiencia en proyectos anteriores, puede ayudar
en gran medida al desarrollo y revisin de las estimaciones. En resumen el
ob"etivo de la planificacin del proyecto es proporcionar un marco de traba"o que
permita al administrador hacer estimaciones ra#onables de sus recursos, estas
estimaciones se hacen dentro de un marco de tiempo limitado al comien#o del
proyecto, y en caso de ser necesario debern actuali#arse a medida que progresa
el proyecto. &dems las estimaciones deben definirse los escenarios del me"or y
peor caso de forma que los resultados del proyecto puedan limitarse. En esta
seccin se estudia cada una de las actividades asociadas a la administracin del
proyecto, partiendo desde la seleccin del modelo a seguir para desarrollar el
mismo, la definicin de las actividades a reali#ar, su calendari#acin, y el anlisis
de riesgos del proyecto propuesto.
Documento General "
O)*e$i+o
Esta seccin describe un panorama de la &dministracin del $royecto !&*+,-,
iniciando con la seleccin del 5odelo del $roceso del 0oft%are a seguir en el
desarrollo del presente proyecto y su "ustificacin, as como las actividades
asociadas a la administracin del proyecto, que comprenden los siguientes puntos/
3. $laneacin del $royecto
<. *alendari#acin de las actividades del $royecto.
.. &dministracin de los 1iesgos
Gr&"o %e Tr')'*o
El 1ru'o de tra#a$o 'ara el de(arrollo del 'ro-ecto e(ta )ormado 'or do( de(arrolladore(;
como a contnuac!n (e de(cr#e<
Nombre Puesto Especialista en
Admn(trador del
Pro-ecto
In1ener=a de So)t*are -
Pro1ramac!n
De(arrollador In1ener=a de So)t*are -
Pro1ramac!n
Mo%e,o %e, Pro!eo %e So-$.'re
*uando se traba"a para construir un producto o un sistema, es importante seguir
una serie de pasos predecibles 8un mapa de carreteras que le ayude a obtener el
resultado oportuno de calidad8. El mapa de carreteras a seguir en el desarrollo de
sistemas de soft%are es llamado, el =Pro!eo %e, So-$.'re>.
Los ingenieros de soft%are y sus gestores adaptan el proceso a sus necesidades y
entonces lo siguen. &dems las personas que han solicitado el soft%are tienen un
papel a desempe(ar en el proceso del soft%are.
Los procesos de soft%are tradicionales conocidos actualmente son comple"os y,
como en todo proceso intelectual, se basa en el "uicio humano. &unque existen
muchos procesos diferentes de soft%are, tienen actividades fundamentales que
son comunes para todos ellos. Estas son/ &nlisis, 'ise(o, mplementacin y
$ruebas.
La seleccin de un modelo de proceso para la ingeniera del soft%are, debe
hacerse de acuerdo a la naturale#a del proyecto, de la aplicacin, mtodos y
herramientas a utili#arse, y de los controles de entrega que se requieren. $ara el
Documento General &
desarrollo del sistema propuesto fue seleccionado el modelo Cascada o modelo
lineal secuencial, el cual sugiere un enfoque sistemtico y secuencial para el
desarrollo del soft%are, en este modelo los clientes piden lo que desean, por
medio de esos requerimientos se dise(a el sistema, despus el dise(o se codifica
y por ultimo se efect2an las pruebas que determinaban si el sistema funciona
correctamente de acuerdo a los requerimientos del cliente., tal como se muestra
en la figura <. & pesar de que el modelo original en cascada propuesto por
9inston 1oyce en 3?@A, hace provisiones para bucles de retroalimentacin, en la
gran mayora de los casos este modelo se aplica como si fuera estrictamente
lineal.
Figura & Modelo de !roceso de So't(are seleccionado. Modelo Cascada.

Documento General 1>
ngeniera de
1equerimiento
s
'ise(o del
0istema de
0oft%are
$rogramacin
-erificacin y
-alidacin
-erificacin y
-alidacin
-erificacin y
-alidacin
El modelo cascada es el paradigma ms antiguo y ms extensamente utili#ado en
la ingeniera de soft%are, sin embargo la crtica del paradigma en algunos casos a
puesto en duda su eficiencia, es por ello que a continuacin se describen las
causas que "ustificaron la seleccin de este modelo.
0e puede desarrollar con facilidad ya que sus etapas estn bien definidas.
El proyecto a desarrollar ya ha sido puesto en practica con xito en otros
lugares.
Los requerimientos del proyecto son comprendidos en su totalidad.
P,'ne'!i#n
La planeacin tiene como finalidad fi"ar los recursos disponibles, dividir el traba"o
del proyecto en actividades que puedan ser reali#adas por el grupo de desarrollo
en poco tiempo, crear un calendario de traba"o y un reali#ar un anlisis de riesgos.
Requerimientos de recursos de Hardware y Software
E(te 'unto de la 'laneac!n de(cr#e lo( re+uermento( de ?ard*are - (o)t*are +ue (e
utl/aran 'ara el de(arrollo del 'ro-ecto; como a contnuac!n (e ndcan<
Recursos de Hardware Cant Descripcin Justificacin
Com'utadora de e(crtoro 4
Proce(ador Intel Pentum@ 5
S(tema O'erat%o Mcro(o)t@
Ando*(@ BP Pro)e(onal
Cu( de S(tema ">> M,/.
Memora< 014MC PC.4>> DDR
5>>M,/ D4E409F
D(co Duro de "> GC mnmo.
D(co 'tco< CDGROM RAH D5"EF
3ndad de d(+uete de ..0 'ul1. -
1.55 MC.
Gr8)co( Inte1rado( Intel@ 3MA
AGP"E ?a(ta 95 MC de memora
com'artda.
Tar$eta de red 1>H1>> nte1rada.
M!dem Inte1rado de 09I IT3 :.&>.
Inter)a(e< 9 3SC4.>; Seral; 4PSH4;
:GA; Paralelo; RJ50H11;
Ranura( de eE'an(!n< 5 ranura( de
eE'an(!n D1 ocu'ada - .
d('on#le(F
Se re+ueren 'ara el
de(arrollo del ((tema
- al )nal/ar una de
la( com'utadora(
(er%r8 como
admn(trador de la
CD.
Documento General 11
Recursos de Software Cant Descripcin Justificacin
,erramenta de de(arrollo
CASE - lcenca
1 Puede (er Raconal Ro(e o
(mlar; actualmente en el
lu1ar donde (e de(arrolla el
((tema (e tene acce(o al
Art(am RtS.
Se re+ueren 'ara el
modelado - d(eKo del
((tema #a$o el
e(t8ndar de 3ML
Ca(e de Dato( - am#ente
de de(arrollo.
1 M-S2L 5.> o (u'eror E(te t'o de #a(e de
dato( e( de )8cl u(o -
e( (o)t*are l#re.
Am#ente de de(arrollo
:(ual CLL
1 Se re+uere la ultma
%er(!n; :(ual Studo.Net
Por (er el am#ente
+ue domna el 1ru'o
de de(arrollo.
Pa+uete de Tra#a$o O))ce 1 O))ce BP o 4>>. Ela#orar la
documentac!n del
Pro-ecto.
Definicin de Actiidades
$ara poder alcan#ar los ob"etivos o metas del proyecto, las tcnicas de divisin del
proyecto en actividades parece ser la ms acertada. En este proyecto, para la definicin
de las actividades se utili#o una tcnica denominada 9or: 7rea:do%n 0tructure )970.,
que es la divisin del proyecto en una "erarqua de actividades, teniendo como cabe#a de
la "erarqua al sistema !&*+,- completo y en niveles inferiores a las actividades que se
deben reali#ar para alcan#ar la construccin total del sistema !&*+,-. Las actividades
se subdividen a su ve# en actividades de menor nivel, esta divisin se detiene, cuando se
tengan actividades bien definidas, su e"ecucin lleve poco tiempo y su progreso pueda ser
medido. &l final de cada actividad se rinde un hito de esa actividad, que es un informe no
extenso que indica al administrador del proyecto que esa actividad ha sido concluida. Las
actividades en las que se ha dividido el desarrollo del sistema !&*+,- han sido
descritas en la tabla 3.
A!$i+i%'%e Pro(e!$o FACTINV A!$i+i%'%e Pro(e!$o FACTINV
/0 Ini!io %e, Pro(e!$o
+3.3 'efinicin del $royecto
+3.< 1eunin con sta:eholders
+3.B 'efinicin del problema a resolver
+3.C Deneracin del $40 )$ro"ect 4vervie%
0tatement.
/1 /i$o: Do!&men$o %e, POS
+< Estudio de factibilidad
+<.3 &nali#ar la factibilidad econmica.
+<.< &nali#ar la factibilidad operativa.
+<.B &nali#ar la factibilidad tcnica.
/2 /i$o: In-orme %e -'!$i)i,i%'%
+B &nlisis de 1equerimientos de Esuario a partir
del $40
+B.3 &nlisis del *ontexto del 0istema
+B.< Deneracin del 'iagrama de *ontexto
/3 /i$o: Di'4r'm' %e !on$e5$o %e, i$em'
+C &nlisis de Escenarios y *asos de Esos
+C.3 'efinir escenarios del sistema
+C.< 'efinir casos de uso del sistema
+C.B Deneracin de 'iagrama de *asos de Esos
/6 /i$o: Di'4r'm' %e C'o %e Uo
+F -erificacin y -alidacin con sta:eholders
/7 /i$o: In-orme %e +eri-i!'!i#n ( +',i%'!i#n %e,
8m)i$o %e, i$em'
+G 'efinicin de requerimientos de usuario
+G.3 1equerimientos !uncionales
+G.< 1equerimientos no funcionales
/9 /i$o: Do!&men$o %e %e-ini!i#n %e
re:&erimien$o en ,en4&'*e n'$&r',
+@ -erificacin y -alidacin con sta:eholders
/; /i$o: In-orme %e +eri-i!'!i#n ( +',i%'!i#n
re:&erimien$o %e &&'rio
+H 'efinicin de requerimientos del sistema
+H.3 1equerimientos !uncionales
+H.< 1equerimientos no funcionales
+H.B Especificacin de requerimientos
/< /i$o: Do!&men$o %e Re:&erimien$o
+? 'ise(o del 0istema
+?.3 'ise(o arquitectnico
+?.< Estructuracin del sistema
+?.B 5odelado de control
+?.C 'escomposicin modular
/= /i$o: Re"or$e T!ni!o %e, %ie>o Ar:&i$e!$#ni!o
+3A &nlisis y dise(o de 0ecuencia de 4b"etos
/10 /i$o: Di'4r'm' %e Se!&en!i' %e O)*e$o
+33 &nlisis y 'ise(o de *lases
/11 /i$o: Di'4r'm' %e C,'e
+3< &nlisis y 'ise(o de 7ase de 'atos
+3<.3 'ise(o de las tablas de la base de datos
/12 /i$o: Di'4r'm' %e, %ie>o %e )'e %e %'$o
+3B &nlisis, dise(o de interfaces Esuario del sistemaI
/13 /i$o: Di'4r'm' %e in$er-'!e &&'rio %e, i$em'
+3C -erificacin y validacin del dise(o
/16 /i$o: in-orme %e +eri-i!'!i#n ( +',i%'!i#n %e,
%ie>o
Documento General 1.
A!$i+i%'%e Pro(e!$o FACTINV
+3F 'ocumento de 'ise(o
/17 /i$o: Do!&men$o %e Die>o
+3G $rogramacin del 0istema
+3G.3 $rogramacin 5odulo de -entas
+3G.< $rogramacin 5odulo de *ompras
+3G.B $rogramacin 5odulo de &dministracin de nventario
+3G.C $rogramacin 5odulo de 1egistro de *lientes y $roveedores
+3G.F $rogramacin 5odulo de 1eportes
+3G.G $rogramacin de interfaces entre 5dulos y base de datos
+3G.@ $rogramacin 7ase de 'atos
+3G.@ $rogramacin de nterfaces de Esuario
/19 /i$o: C#%i4o %e, "ro4r'm'
+3@ I-erificacin, validacin y pruebas del cdigoI
/1; /i$o: In-orme %e "r&e)'
+3H 'ocumentacin del *digo
/1< /i$o: M'n&', %e, Pro4r'm'%or
+3? *apacitacin del usuario final
/1= /i$o: P,'n %e !'"'!i$'!i#n %e, &&'rio -in',
+<A Entrega del $royecto
/20 /i$o: Do!&men$'!i#n %e, Pro(e!$o
Ta)la 1 De'inicin de Actividades del !ro%ecto FACTIN*
Calendari!acin del Proyecto
En esta etapa del proyecto se estima el tiempo requerido para completar cada una de las
actividades previamente definidas, para ello se debe calendari#ar cada una de las
mismas, indicando su fecha de inicio, duracin y fecha de culminacin, adems se deben
establecer las dependencias que existen entre las diferentes actividades que conforman el
proyecto. Ena forma sencilla de representar la informacin del calendario del proyecto, es
a travs de un grfico de barras, llamado tambin grfico de Dantt. En la calendari#acin
solo el domingo se considero como dia no laborable y debido a que la "ornada laboral
diaria era irregular, se decidi estimarla semanalmente, a un promedio de CA horas
laborales a la semana.
ID De!ri"!i#n %e A!$i+i%'% D&r'!i#n
Fe!?' Ini!io
A!$i+i%'%
Fe!?' Termino
A!$i+i%'%
JA nicio
A das <CKAHK<AAC <CKAHK<AAC
+3.3'efinicion del $royecto
H das <CKAHK<AAC B3KAHK<AAC
+3.<1eunion con sta:eholders
3 da <CKAHK<AAC <CKAHK<AAC
+3.B'efinicin del problema a resolver
C das <FKAHK<AAC <HKAHK<AAC
+3.CDeneracin del $40 )$ro"ect 4vervie% 0tatement.
3 da BAKAHK<AAC BAKAHK<AAC
J3 Jito/ 'ocumento del $40 )J3.
A das BAKAHK<AAC BAKAHK<AAC

+< Estudio de factibilidad
B das <HKAHK<AAC B3KAHK<AAC
+<.3&nali#ar la factibilidad econmica.
+<.<&nali#ar la factibilidad operativa.
+<.B&nali#ar la factibilidad tcnica.
J< Jito/ nforme de factibilidad )J<.
A das B3KAHK<AAC B3KAHK<AAC

+B &nlisis de 1equerimientos de Esuario a partir del $40
H das A3KA?K<AAC AHKA?K<AAC
+B.3&nlisis del *ontexto del 0istema
G das A3KA?K<AAC AGKA?K<AAC
+B.<Deneracin del 'iagrama de *ontexto
< das A@KA?K<AAC AHKA?K<AAC
JB Jito/ 'iagrama de contexto del sistema )JB.
A das AHKA?K<AAC AHKA?K<AAC

+C &nlisis de Escenarios y *asos de Esos
33 das A?KA?K<AAC 3HKA?K<AAC
+C.3'efinir escenarios del sistema
G das A?KA?K<AAC 3CKA?K<AAC
+C.<'efinir casos de uso del sistema
B das 3FKA?K<AAC 3@KA?K<AAC
+C.BDeneracin de 'iagrama de *asos de Esos
< das 3@KA?K<AAC 3HKA?K<AAC
JC Jito/ 'iagrama de *asos de Esos )JC.
A das 3HKA?K<AAC 3HKA?K<AAC

+F -erificacin y -alidacin con sta:eholders
< das <AKA?K<AAC <3KA?K<AAC
JF Jito/ nforme de verificacin y validacin del mbito del sistema )JF.
A das <3KA?K<AAC <3KA?K<AAC
Fe!?' Ini!io
A!$i+i%'%
Fe!?' Termino
A!$i+i%'%
+G 'efinicin de requerimientos de usuario
C das <<KA?K<AAC <FKA?K<AAC
+G.3 1equerimientos !uncionales
B das <<KA?K<AAC <CKA?K<AAC
+G.< 1equerimientos no funcionales
B das <<KA?K<AAC <CKA?K<AAC
JG
Jito/ 'ocumento de definicin de requerimientos en lengua"e natural
)JG.
A das <FKA?K<AAC <FKA?K<AAC

+@ -erificacin y -alidacin con sta:eholders
3 da <@KA?K<AAC <@KA?K<AAC
J@
Jito/ nforme de verificacin y validacin requerimientos de usuario
)J@.
A das <@KA?K<AAC <@KA?K<AAC

+H 'efinicin de requerimientos del sistema
? das <HKA?K<AAC AGK3AK<AAC
+H.3 1equerimientos !uncionales
B das <HKA?K<AAC BAKA?K<AAC
+H.< 1equerimientos no funcionales
C das <?KA?K<AAC A<K3AK<AAC
+H.B Especificacin de requerimientos
B das ACK3AK<AAC AGK3AK<AAC
JH Jito/ 'ocumento de 1equerimientos )JH.
A das AGK3AK<AAC AGK3AK<AAC

+? 'ise(o del 0istema
BC das <3K3AK<AAC <CK33K<AAC
+?.3 'ise(o arquitectnico
G das A@K3AK<AAC 3<K3AK<AAC
+?.< Estructuracin del sistema
G das A?K3AK<AAC 3CK3AK<AAC
+?.B 5odelado de control
B das 3FK3AK<AAC 3HK3AK<AAC
+?.C 'escomposicin modular
G das 3FK3AK<AAC <AK3AK<AAC
J? Jito/ 1eporte +cnico del dise(o &rquitectnico )J?.
A das <AK3AK<AAC <AK3AK<AAC

+3A &nlisis y dise(o de 0ecuencia de 4b"etos
C das <3K3AK<AAC <FK3AK<AAC
J3A Jito/ 'iagrama de 0ecuencia de 4b"etos )J3A.
A das <FK3AK<AAC <FK3AK<AAC

+33 &nlisis y 'ise(o de *lases
@ das <GK3AK<AAC ABK33K<AAC
J33 Jito/ 'iagrama de *lases )J33.
A das ABK33K<AAC ABK33K<AAC

+3< &nlisis y 'ise(o de 7ase de 'atos
3C das <3K3AK<AAC AFK33K<AAC
+3<.3'ise(o de las tablas de la base de datos
3 da ACK33K<AAC ACK33K<AAC
J3< Jito/ 'iagrama del dise(o de base de datos )J3<.
A das AGK33K<AAC AGK33K<AAC

+3B &nlisis, dise(o y modelado de las interfaces Esuario del sistema
33 das AHK33K<AAC 3@K33K<AAC
J3B Jito/ 'iagramas de interfaces usuario del sistema )J3B.
A das 3@K33K<AAC 3@K33K<AAC

+3C -erificacin y validacin del dise(o
B das 3HK33K<AAC <AK33K<AAC
J3C Jito/ informe de verificacin y validacin del dise(o )J3C.
A das <AK33K<AAC <AK33K<AAC

+3F 'ocumento de 'ise(o
B das <<K33K<AAC <CK33K<AAC
J3F Jito/ 'ocumento de 'ise(o )J3F.
A das <CK33K<AAC <CK33K<AAC
Fe!?' Ini!io
A!$i+i%'%
Fe!?' Termino
A!$i+i%'%
+3G $rogramacin del 0istema
3@ das <GK33K<AAC 33K3<K<AAC
+3G.3$rogramacin 5odulo de -entas
C das <GK33K<AAC BAK33K<AAC
+3G.<$rogramacin 5odulo de *ompras
C das <GK33K<AAC BAK33K<AAC
+3G.B$rogramacin 5odulo de &dministracin de nventario
H das BAK33K<AAC A@K3<K<AAC
+3G.C$rogramacin 5odulo de 1egistro de *lientes y $roveedores
@ das <?K33K<AAC ACK3<K<AAC
+3G.F$rogramacin 5odulo de 1eportes
3A das <@K33K<AAC A@K3<K<AAC
+3G.G$rogramacin de interfaces entre 5dulos y base de datos
3B das <?K33K<AAC 3AK3<K<AAC
+3G.@$rogramacin 7ase de 'atos
3C das <@K33K<AAC 3AK3<K<AAC
+3G.@$rogramacin de nterfaces de Esuario
G das AGK3<K<AAC 3AK3<K<AAC
J3G Jito/ *digo del programa )J3G.
A das 33K3<K<AAC 33K3<K<AAC

+3@ -erificacin, validacin y pruebas del cdigo
<G das <GK33K<AAC <AK3<K<AAC
J3@ Jito/ nforme de pruebas )J3@.
A das <AK3<K<AAC <AK3<K<AAC

+3H 'ocumentacin del *digo
3@ das BAK33K<AAC 3FK3<K<AAC
J3H Jito/ 5anual del $rogramador )J3H.
A das 3FK3<K<AAC 3FK3<K<AAC

+<3 *apacitacin del usuario final
C das 3GK3<K<AAC <AK3<K<AAC
J<3 Jito/ $lan de capacitacin del usuario final )<<.
A das <AK3<K<AAC <AK3<K<AAC

+<< Entrega del $royecto
G das 3GK3<K<AAC <3K3<K<AAC
J<< Jito/ 'ocumentacin del $royecto )<B.
A das <<K3<K<AAC <<K3<K<AAC

Ta)la & Duracin de las Actividades del $ro%ecto FACTIN*.
Documento General 1"
Ini!io
T1@1
T1@2
T1@3
/1
T2@1
T2@2
T2@3
/2
T3@1
T3@2
T3@3
T3@6
T6@1
T6@2
T6@3
T6@6
T6@7
/3
T7@1
T7@2
/6
T9@1
T9@2
T9@3
T;@1
T;@2
T<@1
T<@2
T<@3
/7
T=@1
T=@2
T=@3
T=@6
/9
T10@1
T10@2
T10@3
T10@6
T10@7
/;
T11@1
T11@2
T11@3
T11@6
/<
T12@1
T12@2
T12@3
T12@6
Fin

AGOSTO SEPTIEMBRE OCTUBRE NOVIEMBRE DICIEMBRE ENERO
22 2= 07 12 1= 29 03 10 1; 26 31 0; 16 21 2< 07 12 1= 29 02 0= 19 23 30
Figura N + Diagrama de Actividades del !ro%ecto.
A%mini$r'!i#n %e Rie4o
& continuacin se presentan las tablas B, C, F y G, en donde se muestra en forma
resumida, la definicin, anlisis, estrategias de administracin y supervisin de los
principales riesgos asociados con el desarrollo del proyecto.
TIPO DE RIESGO RIESGOS POSIBLES
Te!no,o4A'
La 7ase de 'atos que se utili#ara es de cdigo abierto y podra
tener problemas de incompatibilidad con el lengua"e de
programacin seleccionado.
Peron'
El personal asignado al proyecto, no cuenta con la capacitacin
adecuada para desarrollar el sistema.
El personal esta comprometido con otros proyectos, que le
impiden atender plenamente el proyecto.
/err'mien$' Es ineficiente el cdigo generado por las herramientas *&0E
Las herramientas *&0E son de alto costo
Re:&erimien$o 0urgen nuevos requerimientos que requieren cambiar el dise(o.
Or4'niB'!ion',e
El personal del negocio se opone a los cambios, que representa
introducir !&*+,- en la organi#acin
E$im'!i#n
El tiempo requerido para la capacitacin adecuada del personal
esta subestimado
El tiempo requerido para desarrollar el sistema de soft%are esta
subestimado
El tama(o del soft%are esta subestimado
Ta)la + Clasi'icacin e Identi'icacin de Riesgos del !ro%ecto FACTIN*.
Documento General 1&
RIESGO PROBABILIDAD EFECTOS
El tiempo requerido para la capacitacin adecuada del
personal esta subestimado.
5edia *atastrfico
El personal esta comprometido con otros proyectos,
que le impiden atender plenamente el proyecto.
&lta 0erio
0urgen nuevos requerimientos que requieren cambiar
el dise(o. 5edia 0erio
El personal asignado al proyecto, no cuenta con la
capacitacin adecuada para desarrollar un sistema de
7ase de 'atos
&lta 0erio
El personal de la organi#acin donde se instalara el
sistema !&*+,-, se opone a los cambios
&lta +olerable
El tiempo requerido para desarrollar el sistema de
soft%are esta subestimado.
&lta +olerable
El lengua"e de programacin no cuenta con mtodos
previamente desarrollados, que permitan satisfacer
ciertos requerimientos del sistema.
5edia +olerable
Ta)la , An-lisis de Riesgos del $ro%ecto FACTIN*
RIESGO ESTRATEGIA
$roblemas con la 7ase de
'atos
nvestigar sobre otras aplicaciones similares, que se
hayan desarrollado con este tipo de 7ase de 'atos
seleccionado
$roblemas con la capacitacin
del personal de desarrollo
1eali#ar un diagnostico de las habilidades
individuales del personal en las reas relacionadas
con el desarrollo del sistema, y canali#ar los planes
de capacitacin de forma individuali#ada, para que se
puedan fortalecer estas habilidades en el menor
tiempo posible.
$roblemas relacionados con el
desarrollo de otros proyectos.
1eali#ar una clasificacin de los proyectos de
acuerdo al grado de dificultad que este represente
para el personal involucrado en su desarrollo.
'ise(ar un plan de traba"o que asigne tiempos de
atencin a cada proyecto, acorde con la clasificacin
previamente reali#ada.
$roblemas del personal del
negocio
1eali#ar un anlisis minucioso de las causas por la
cual se oponen a la implementacin del sistema y
tomar medidas radicales
Elaborar un buen plan de entrenamiento que muestre
al personal las bondades del sistema !&*+,-
*ambios de requerimientos
Etili#ar tcnicas de dise(o que limiten el impacto de
los cambios de requerimientos
+iempo de desarrollo
subestimado
&lertar al cliente de las dificultades de desarrollar el
sistema completo en el tiempo estimado.
Ta)la . Administracin de Riesgos del sistema FACTIN*.
TIPO DE RIESGO INDICADORES POTENCIALES
Te!no,o4A' 'ocumentacin excesiva de la 7ase de 'atos seleccionada hace
difcil la tarea de clasificar la informacin relevante a este proyecto
Peron' $reocupacin excesiva de personal por temor a no cumplir con los
proyectos asignados
5iembros del equipo con poco mpetu para resolver problemas y
aportar ideas al equipo de desarrollo
Re:&erimien$o 'ificultad de integrar los nuevos requerimientos en la fase de
codificacin.
/err'mien$' 'ificultad para conseguir una herramienta *&0E que cumpla con
las expectativas del proyecto
Or4'niB'!ion',e *omentarios dentro de la organi#acin referentes al ba"o
rendimiento presentado por el grupo traba"o asignado al proyecto
E$im'!i#n !racaso en el cumplimiento de los tiempos estimados en el plan
de administracin del proyecto.
Ta)la / Su$ervisin de Riesgos del $ro%ecto FACTIN*.
SEGUNDA PARTE:
RE01ERIMIENT"S DE SISTEMA
In$ro%&!!i#n
En esta segunda parte del documento general se establecen y documentan las tcnicas
de la ngeniera de 1equerimientos, facilitando con esto que se delimite el alcance del
sistema y se comprendan los requerimientos del cliente, llevndolos a un estado donde
cada uno de los requerimientos del cliente llegue a ser independiente, completo y sin
ambigLedades, negociando una solucin ra#onable, validando la especificacin y
administrando los requerimientos para que se transformen en un sistema operacional.
El proceso de ingeniera de requerimientos expuesto por este documento reali#a un
estudio de factibilidad del proyecto. &s mismo se usa una tcnica para el anlisis y
obtencin de requerimientos, que incluye las plantillas de punto de vista y de servicios
)mtodo -41'. y los diagramas de casos de uso y de secuencia, con los resultados
del mtodo -41' se definen los requerimientos en lengua"e natural para el usuario y
luego se especifican en lengua"e natural estructurado, siguiendo el mtodo -4L&1E,
finalmente se presenta una parte de validacin y administracin de los requerimientos
que incluye la matri# de de rastreo de requerimientos.
E$&%io %e F'!$i)i,i%'%
En el presente estudio se anali# la disponibilidad de los recursos necesarios para
alcan#ar los ob"etivos tra#ados, el mismo se apoy en anlisis de B aspectos bsicos/
Econmico
4perativo
+cnico
La decisin de continuar o no con el proyecto, fue determinada por el grado de
factibilidad presentado en cada uno de los tres aspectos anteriores.
"actibilidad Econmica
En el presente proyecto la factibilidad econmica se encuentra garanti#ada en su
totalidad, ya que todos los costos del proyecto sern absorbidos por el ,&4E, estos
incluyen/ costo de la tecnologa a utili#ar )hard%are y soft%are., del personal de
desarrollo, de la infraestructura )planta fsica y servicios. y del acceso al informacin.
"actibilidad #peratia
Esta depende de los recursos humanos que participen durante la operacin del
proyecto, de forma tal que se pueda garanti#ar el uso del sistema a desarrollar. La
factibilidad operativa es ba"a ya que/
3. El sistema ser administrado y usado por personal que no cuenta con
conocimientos en computadoras, sin embargo se le dar capacitacin para el
uso adecuado del sistema
<. El personal del rea administrativa y contable del negocio no acepta los cambios
0in embargo, para minimi#ar las consecuencias se atacaran durante el desarrollo del
proyecto los dos aspectos anteriores, tomndose las medidas necesarias para el xito
del proyecto de com2n acuerdo con el cliente.
"actibilidad $%cnica
La factibilidad tcnica anali#a los recursos de hard%are y soft%are necesarios para
desarrollar el sistema, as como tambin a los conocimientos, habilidades y experiencia
del personal que conforma el grupo de traba"o, para poder efectuar las actividades o
procesos que requiere el proyecto.
Jard%are/ El negocio como el grupo de desarrollo cuenta con el equipo de computo
necesario para la reali#acin y desarrollo del sistema.
0oft%are/ El equipo de desarrollo cuenta con el soft%are necesario para el desarrollo del
sistema proporcionado por el ,&4E.
$ersonal/ 0e pudo determinar que para el inicio del proyecto este no contaba con
ninguna experiencia en el desarrollo de sistemas de 7ase de 'atos, sin embargo se
estim que el mismo, poda adquirir los conocimientos y las habilidades necesarios para
culminar exitosamente el proyecto, ya que era factible acceder a la informacin
necesaria par su capacitacin.
O)$en!i#n ( An8,ii %e Re:&erimien$o
Esta etapa del proceso de ngeniera de 1equerimientos se encarga de la obtencin y
anlisis de requerimientos. En esta actividad el personal de desarrollo del soft%are
traba"o con los clientes y usuarios finales del sistema reali#ando visitas al negocio
determinando el dominio de la aplicacin y cuales son los servicios que debe proveer el
sistema, para la reali#acin de esta actividad se utili#o un mtodo de obtencin de
requerimientos orientado a puntos de vista, esta mtodo es me"or conocido como
mtodo -41', y es descrito a continuacin.
&%todo '#RD
Este mtodo se ha dise(ado como un marco de traba"o orientado a servicios, para
poder estructurar y organi#ar la obtencin y anlisis de requerimientos, el mismo esta
basado en el punto de vista de los usuarios finales del sistema, es por ello que se debe
definir el perfil de cada uno estos usuarios, para as poder anali#ar su perspectiva que
este tiene del sistema que se desea desarrollar. En este sentido es bueno recalcar que
el sistema propuesto no es una herramienta de propsito general, si no de uso
especfico, por lo tanto el usuario final debe ser un usuario especiali#ado, que debe
estar estrechamente familiari#ado, tanto con el proceso industrial real, como con el
modelo que pretende simular dicho proceso, ya que para poder reali#ar el proceso de
en forma adecuada, debe inferir conclusiones comparado el comportamiento de ambos.
$or todo lo expuesto anteriormente, slo se estudio el punto de vista de este tipo de
usuario, que puede estar representado por un ingeniero industrial, que intenta validar un
modelo, que probablemente haya sido dise(ado por el mismo. & continuacin se
muestran las plantillas de punto de vista y de servicio para este usuario final.
Re-eren!i' : ngeniero ndustrial
A$ri)&$o : $armetros del modelo.
4bservaciones de la prueba.
E+en$o: 0eleccionar modelo
ntroducir parmetros
0eleccionar mtodo
niciar simulacin
'etener simulacin
$erturbar simulacin
*ontinuar simulacin
1epetir simulacin
&notar 4bservaciones
!inali#ar simulacin
Ser+i!io: $robar modelo
mprimir resultados

Figura N . !lantilla de $unto de vista.
Figura N / !lantilla del Servicio2 !ro)ar Modelo.
Re-eren!i': $robar modelo.
F&n%'men$o: -alidar un modelo que simula un proceso
industrial de inters para la organi#acin.
E"e!i-i!'!i#n: El usuario selecciona un modelo, introduce los
parmetros necesarios, luego selecciona un mtodo
para calcular su solucin, despus inicia la
simulacin, durante la misma puede detener la

simulacin, repetir parte de esta, perturbar la
simulacin, continuar la simulacin, anotar los
resultados observados y finali#ar la simulacin.
P&n$o %e +i$': ngeniero ndustrial.
Re:&erimien$o La simulacin debe presentarse en colores que
no -&n!ion',e: contrasten con el fondo de la pantalla, para que
se pueda apreciar claramente el proceso que se
desea simular.

0e debe poder cambiar el intervalo de tiempo en
que se capturan las soluciones parciales, que se
deseen repetir.
Pro+ee%or : 5odulo de $rueba.

Re-eren!i': mprimir resultados.
F&n%'men$o: !acilitar el anlisis de la validacin del modelo,
de forma tal que el usuario pueda compartir y
discutir las observaciones de la prueba con el
resto de su equipo de traba"o.

E"e!i-i!'!i#n: El usuario selecciona el archivo que contiene
las observaciones de la prueba al modelo que
desea validar, y luego selecciona la opcin de
obtener reporte por impresora.
P&n$o %e +i$': ngeniero ndustrial.
Re:&erimien$o Los resultados a imprimir sern extrados de
no -&n!ion',e: un archivo de texto.

Pro+ee%or : 5odulo de 1eportes.

Figura N 3 !lantilla del Servicio2 Im$rimir Resultados.
Di'4r'm' %e C'o %e Uo
Esta es una tcnica basada en el uso de escenarios, en donde los usuarios dan
e"emplos de las acciones que desean reali#ar al momento de interactuar con el sistema,
lo que permite modelar su comportamiento, ya que se puede visuali#ar grficamente
cada una de estas interacciones, la relacin que existe entre ellas, y quien llevar a
cabo determinada interaccin, todo esto sin importar como ser implementada. En
resumen los diagramas de casos de uso nos ayudas a describir las funciones del
sistema y a complementar el enfoque basado en el punto de vista de los usuarios. $ara
el dise(o del diagrama de casos de uso mostrado en la figura , H se siguieron los
pasos indicados a continuacin.
P'o 1@ dentificar los actores que interactuar con el sistema.
P'o 2@ 0eleccionar un actor.
P'o 3@ MNue quiere hacer el actor con el sistemaO )caso de uso.
P'o 6@ $ara cada caso MNue pasaO )inclusiones.
P'o 7@ 'escribirlo textualmente.
P'o 9@ *onsiderar las alternativas para cada de uso )exclusiones..
P'o ;@ Encontrar casos comunes o generales )generali#aciones..
P'o <. 1epetir los pasos del < al @ con todos los actores.

*omo se menciono en el mtodo -41' solo se construyeron los casos de uso para
un solo actor, tal como se muestra en la siguiente futuro.

Documento General .>

Documento General .1
Pro)'r e, Mo%e,o 1
Gr'-i!'r So,&!i#n 7
Se,e!!ion'r M$o%o 6
Norm',iB'r 9 Ini!i'r ;
De$ener <
A,$er'r =

Con$in&'r 11
Re$ro!e%er 10
Gener'r Re"or$e 13

Ano$'r
O)er+'!ione 12
Se,e!!ion'r Mo%e,o 2
C'"$&r'r P'r8me$ro 3
Figura N 4 Diagrama de Casos de 1so.
Di'4r'm' %e Se!&en!i'
Esta es otra tcnica que se basa en escenarios y que permite agregar informacin a un
caso de uso. En este diagrama se muestran los actores que interact2an con el sistema
los ob"etos con que se puede interactuar y las operaciones asociadas con otros ob"etos.
0i el modelo que se piensa adoptar para el dise(o y desarrollo del sistema es orientado
a ob"etos, este diagrama resulta un buen punto de partida para identificar las futuras
clases a dise(ar.
Figura N 5 Diagrama de Secuencias.
Documento General ..
&notacin
0olicitar
&notacin
Enviar )1eporte.
1eporte
0olicitar )1eporte.
4bservacin &notar
!inali#ar
5odelo
0imulacin
0imulacin
*ontinuar
$erturbar
$arar
niciar
5odelo
Enviar)5odelo.
5odelo
$arametri#ar
0olicitar)5odelo.
nterfa# 5odelo 5todo
0olucin
0olucin
Libreta
Denerador
de
Drficos
Denerador
de
1eportes
De-ini!i#n %e Re:&erimien$o
En esta seccin se definen los requerimientos funcionales y no funcionales del usuario.
Estos requerimientos son presentados en lengua"e natural estructurado y se les ha
agregado el fundamento que soporta cada requerimiento.
Re:&erimien$o %e, U&'rio
F&n!ion',e
1@C E, i$em' %e)e "ermi$ir :&e e, &&'rio "r&e)e &n mo%e,o %e$ermin'%o@
F&n%'men$o: &ntes de que un modelo se pueda aplicar, necesariamente debe ser
probado, y el usuario es la persona ms indicada para hacerlo, ya que este debe
conocer el proceso real que se desea simular, lo que le permitir inferir conclusiones de
que tan seguro es utili#ar el modelo propuesto, a partir de la observacin de la solucin
del modelo y de la comparacin con la salida del sistema real.
1@1@C Pre"'r'r e, e!en'rio %e "r&e)'@
3.3.3.8 El sistema debe permitir que el usuario seleccione el modelo que
se desea probar.
3.3.<8 El sistema debe permitir ingresar los parmetros iniciales del
modelo seleccionado.
3.3.B.8 El sistema debe permitir el usuario seleccione un mtodo para
solucionar el modelo.
F&n%'men$o: 'ebido a que en la organi#acin pueden existir o surgir
varios procesos de inters que se desean simular, el usuario debe
adaptar el ambiente de prueba para el modelo que desea probar.
1@2@ Preen$'!i#n %e ,' o,&!i#n %e, mo%e,o
3.<.3.8 La solucin del modelo debe ser presentada grficamente.
3.<.3.8 El sistema debe permitir que el usuario visualice como se va
construyendo la solucin grfica.
3.<.<.8 El sistema debe permitir normali#ar la solucin grafica
F&n%'men$o: *onsiderando que la base de la prueba es comparar el
comportamiento del modelo con la salida del sistema real, la me"or forma
es representar la solucin del modelo grficamente.
1@3@ /err'mien$' "'r' "ro)'r e, Mo%e,o
3.B.3.8 El usuario puede iniciar la graficacin de la solucin.
3.B.<.8 El usuario puede detener la graficacin de la solucin.
3.B.B.8 El usuario puede cambiar los parmetros del modelo durante la
simulacin.
3.B.B.8 El sistema debe permitir tomar fotos de la graficacin de la
solucin.
3.B.C.8 El usuario puede retroceder a una solucin grafica previa.
3.B.F.8 El usuario puede reiniciar la graficacin de la solucin.
F&n%'men$o: *omo se menciono anteriormente la me"or forma de validar el
modelo es comparar la salida real y la calculada mediante la simulacin, es por
ello que el sistema debe proveer al usuario un con"unto de herramientas que
permitan que este visualice detalladamente el comportamiento del modelo, tanto
en condiciones normales, como perturbado, y as poder inferir conclusiones de
que tan seguro es aplicar el modelo probado.
2@C E, i$em' %e)e "ermi$ir :&e e o)$en4' &n re"or$e %e ,o re&,$'%o %e ,'
"r&e)'@
<.3.8 El sistema debe permitir que el usuario realice anotaciones durante la
prueba del modelo.
<.<.8 El sistema debe permitir que las observaciones sean guardadas.
<.B. El sistema debe permitir que el usuario modifique las anotaciones.
<.C. El sistema debe permitir que el usuario consulte anotaciones anteriores.
<.F. El sistema debe permitir obtener un reporte impreso de las anotaciones.
F&n%'men$o: 'urante la prueba del modelo el usuario infiere un con"unto de
observaciones que es recomendable anotar, una forma prctica de hacerlo es a
travs del mismo sistema, de forma que el usuario pueda revisar luego estas
anotaciones con ms calma y con el resto de su equipo de traba"o, a pesar de
que los mismos no hayan estado presentes en la prueba, una manera de hacer
esto es obteniendo un reporte impreso de dichas observaciones.
No F&n!ion',e
B.8 La solucin grfica debe ser presentada en colores que permitan visuali#ar
claramente la simulacin.

B.3.8 El sistema debe permitir que el usuario pueda cambiar estos colores.
F&n%'men$o: El xito de la prueba depende de el usuario pueda observar el
comportamiento del modelo de la forma ms clara posible, por lo tanto el es el
indicado para seleccionar los colores ms agradables a su vista, que lo provean
una me"or visuali#acin del comportamiento del modelo.
C.8 El usuario puede cambiar la escala en que ser presentada la solucin grfica.
F&n%'men$o: &l igual que en el fundamento anterior este requerimiento esta
orientado a proveer de acuerdo al criterio del usuario, una me"or visuali#acin
del comportamiento del modelo.
F.8 El tiempo en que se representa la solucin grfica no se considera una restriccin
del sistema.
F&n%'men$o: 'ebido a que la simulacin no esta orientada a representar un
sistema de tiempo real y que una de las motivaciones del desarrollo del sistema
es probar diferentes modelos observando su comportamiento, la rapide# con
que se muestra la solucin no representa una limitante.
G.8 El tiempo en que se toman las fotos que contienen parte de la solucin grfica
puede ser cambiado por el usuario.
F&n%'men$o: El usuario es quien debe establecer las pautas a seguir para
probar el modelo, por lo tanto el sistema le debe proveer las facilidades
necesarias que le permitan adaptar la prueba a sus necesidades.
@.8 El sistema debe ser desarrollado en un lengua"e de programacin que permita crear
programas e"ecutables.
F&n%'men$o: Esto le dar mayor portabilidad al sistema, ya que no lo ligara
con una herramienta de soft%are especfica, y le permitir probar modelos ms
comple"os que dependan de la capacidad del hard%are utili#ado y no de una
herramienta de soft%are especfica.
H.8 El usuario reali#ar las anotaciones de la prueba, en una ventana de texto.
H.38 El usuario podr abrir y cerrar esta ventana.
H.<.8 El usuario podr mover la ventana.
H.B.8 El usuario podr cambiar el tama(o de la ventana.
F&n%'men$o: 'ebido a que lo ideal es que el usuario realice sus observaciones
durante la prueba del modelo, es recomendable que este pueda cambiar el
entorno en donde va a anotar dichas observaciones.
?.8 Las observaciones de la prueba sern guardadas en un archivo de texto.
F&n%'men$o: Los archivos de texto son un estndar que puede ser editados
fcilmente por otros editores de texto, y este formato tambin facilita y hace
ms rpida la impresin del reporte.
3A.8 El sistema debe proveer ventanas de ayuda que faciliten el uso del sistema.
F&n%'men$o: El uso de todo nuevo sistema al principio puedes resultar
comple"o, es por ello que el sistema debe contar con los medios necesarios que
guen al usuario al operar el mismo.
E"e!i-i!'!i#n %e Re:&erimien$o
En esta seccin se presentan descripciones ms detalladas de los requerimientos del
usuario, y representan el punto de partida para la siguiente etapa que es el dise(o del
sistema. En el presente proyecto fue seleccionada la metodologa -4L&1E para
especificar los requerimientos del sistema. Esta se basa en especificaciones en
lengua"es estructurado presentadas en plantillas. La venta"a de este enfoque es que
mantiene mucha de la expresividad y comprensin del lengua"e natural y asegura que
cierto grado de uniformidad se imponga a la especificacin.
Re:&erimien$o F&n!ion',e
Re:&erimien$o: P 3 Ti"o %e
re:&erimien$o: ?
E+en$oD!'o %e &o E: 3
De!ri"!i#n: El sistema debe permitir probar un modelo de inters para el usuario.
R'B#n: &nali#ar que tan seguro es el modelo probado, para determinar si debe ser o no utili#ado.
F&en$e: *oordinador del $royecto
Cri$erio %e
me%i%':
La funcionalidad del modelo una ve# aprobado y utili#ado.
S'$i-'!!i#n %e, !,ien$e: F In'$i-'!!i#n %e, !,ien$e: F
De"en%en!i': Los modelos a probar deben estar
representados como ecuaciones algebraicas diferenciales.
Con-,i!$o: ,o existen conflictos
M'$eri',e %e '"o(o: 'iagrama de *asos de Eso
/i$ori': *reado el B3 de 4ctubre del <AAC
Re:&erimien$o: P 3.3 Ti"o %e
re:&erimien$o: ?
E+en$oD!'o %e &o E: 3,<
De!ri"!i#n: El sistema debe permitir que el usuario pruebe diferentes modelos.
R'B#n: &horrar costos en el desarrollo de diferentes sistemas para probar un modelo especifico.
Cri$erio %e
me%i%':
Nue el usuario pueda seleccionar el modelo que desea probar.
/i$ori': *reado el 3 de ,oviembre del <AAC
Documento General ."
Re:&erimien$o: P 3.< Ti"o %e
re:&erimien$o: ?
E+en$oD!'o %e &o E: 3,B
De!ri"!i#n: El sistema debe permitir que el usuario configure el modelo que desea probar.
R'B#n: $ermite ensayar un con"unto de casos a travs del mismo modelo
Cri$erio %e
me%i%':
Nue el usuario pueda parametri#ar el modelo que desea probar.
Re:&erimien$o: P 3.B Ti"o %e
re:&erimien$o: ?
E+en$oD!'o %e &o E: 3,C
De!ri"!i#n: El sistema debe permitir solucionar el modelo a travs de diferentes mtodos numricos.
R'B#n: Nue el usuario verifique cual es la solucin que representa me"or la salida real.
Cri$erio %e
me%i%':
Nue el usuario pueda seleccionar el mtodo numrico con que desea solucionar el
5odelo.
S'$i-'!!i#n %e, !,ien$e: C In'$i-'!!i#n %e, !,ien$e: C
De"en%en!i': Los mtodos numricos seleccionados deben
solucionar modelos representados como ecuaciones
algebraicas diferenciales.
M'$eri',e %e '"o(o: 'iagrama de *asos de Eso. 0eccin de !undamentos 7sicos
Re:&erimien$o: P 3.C Ti"o %e
re:&erimien$o: ?
E+en$oD!'o %e &o E: 3,F
De!ri"!i#n: La solucin del modelo debe representarse grficamente.
R'B#n: Es la me"or forma de observar el comportamiento del modelo.
Cri$erio %e
me%i%':
Nue se pueda visuali#ar la solucin grafica del modelo.
De"en%en!i': Nue la herramienta de desarrollo cuente con
libreras adecuadas para la representacin grfica.
Documento General .&
M'$eri',e %e '"o(o: 'iagrama de *asos de Eso.
/i$ori': *reado el < de ,oviembre del <AAC
Re:&erimien$o: P 3.F Ti"o %e
re:&erimien$o: ?
De!ri"!i#n: El sistema debe construir la solucin grafica en forma dinmica.
R'B#n: Nue el usuario pueda observar detalladamente el comportamiento del modelo.
Cri$erio %e
me%i%':
Nue el usuario pueda observar como se va construyendo grficamente la solucin del
5odelo.
libreras adecuadas para la representacin grfica.
Re:&erimien$o: P 3.G Ti"o %e
re:&erimien$o: ?
E+en$oD!'o %e &o E: 3,F,G
De!ri"!i#n: El sistema debe permitir normali#ar la solucin grafica del modelo.
R'B#n: Nue el usuario pueda visuali#ar la solucin grafica en una escala adecuada.
Cri$erio %e
me%i%':
Nue la solucin grafica se pueda mostrar completa en la pantalla.
S'$i-'!!i#n %e, !,ien$e: F In'$i-'!!i#n %e, !,ien$e: C
De"en%en!i': 'esarrollar las rutinas necesarias para
normali#ar la solucin del modelo antes de graficarla.
Re:&erimien$o: P 3.@ Ti"o %e
re:&erimien$o: ?
E+en$oD!'o %e &o E: 3,@,H,?,3A,33
De!ri"!i#n: El sistema debe proveer las funciones necesarias para probar el modelo.
R'B#n: 0in estas funciones el proceso de validacin no ser seguro.
Cri$erio %e
me%i%':
La cantidad y el tipo de funciones que ofrece el sistema para probar el modelo.
De"en%en!i': Nue las funciones propuestas puedan ser
desarrolladas con la herramienta de desarrollo seleccionada.
/i$ori': *reado el B de ,oviembre del <AAC
Re:&erimien$o: P 3.@.3 Ti"o %e
re:&erimien$o: ?
E+en$oD!'o %e &o E: 3,@
De!ri"!i#n: El sistema debe tener una funcin que permita iniciar la simulacin.
R'B#n: $oder controlar el proceso de simulacin.
Cri$erio %e
me%i%':
-erificar que la solucin inicial se corresponda con los parmetros iniciales.
De"en%en!i': Nue el modelo acepte un estado inicial de
partida.
Re:&erimien$o: P 3.@.< Ti"o %e
re:&erimien$o: ?
E+en$oD!'o %e &o E: 3,H
De!ri"!i#n: El sistema debe tener una funcin que permita detener la simulacin.
R'B#n: $oder controlar el proceso de simulacin.
Cri$erio %e
me%i%':
Nue la solucin grafica se detenga una ve# que se active esta funcin.
De"en%en!i': Nue el modelo se pueda resolver
parcialmente.
Re:&erimien$o: P 3.@.B Ti"o %e
re:&erimien$o: ?
E+en$oD!'o %e &o E: 3,?
De!ri"!i#n: El sistema debe tener una funcin que permita cambiar los parmetros del modelo durante
la simulacin
R'B#n: $oder controlar el proceso de simulacin y ver como responde ante nuevas condiciones
Cri$erio %e
me%i%':
-erificar que la solucin grafica se represente correctamente una ve# introducidos los
nuevos parmetros.
De"en%en!i': Nue el modelo se pueda resolver
correctamente a partir de los nuevos parmetros
Re:&erimien$o: P 3.@.C Ti"o %e
re:&erimien$o: ?
E+en$oD!'o %e &o E: 3,3A
De!ri"!i#n: El sistema debe permitir el fotografiado periodico de la solucin grfica.
R'B#n: *apturar soluciones graficas previas a las que el usuario pueda retroceder y observar
nuevamente, sin tener que graficar desde el inicio la solucin.
Cri$erio %e
me%i%':
-erificar si la foto tomada se corresponde con la solucin grafica presentada previamente
en tiempo de e"ecucin
De"en%en!i': Nue la herramienta de desarrollo provea las
libreras necesarias para llevar a cabo esta funcin.
/i$ori': *reado el C de ,oviembre del <AAC
Re:&erimien$o: P 3.@.F Ti"o %e
re:&erimien$o: ?
De!ri"!i#n: El sistema debe tener una funcin que permita retroceder a un estado anterior de la
simulacin.
R'B#n: $oder controlar el proceso de simulacin y visuali#ar nuevamente una parte de la misma.
Cri$erio %e
me%i%':
-erificar si a la etapa de la simulacin a donde se retrocedi, forma parte de la solucin
parcial del modelo.
De"en%en!i': Nue se pueda reali#ar el fotografiado
periodico.
Con-,i!$o: 1equerimiento 3.@.C
Re:&erimien$o: P 3.@.G Ti"o %e
re:&erimien$o: ?
E+en$oD!'o %e &o E: 3,33
De!ri"!i#n: El sistema debe tener una funcin que permita continuar la simulacin
R'B#n: $oder controlar el proceso de simulacin, y observar como se comporta el modelo despus de
haber sido detenida la simulacin.
Cri$erio %e
me%i%':
-erificar que la solucin grafica se construya a partir de donde se detuvo la simulacin.
De"en%en!i': Nue el modelo acepte un estado inicial de
partida.
Re:&erimien$o: P < Ti"o %e
re:&erimien$o: ?
E+en$oD!'o %e &o E: 3,3<,3B
De!ri"!i#n: El sistema debe permitir que se obtenga un reporte impreso de los resultados de la
prueba.
R'B#n: !acilitar el anlisis posterior a la prueba del modelo.
Cri$erio %e
me%i%':
4btener el reporte impreso, tal cual como se edito durante la prueba.
De"en%en!i': 'ebe existir un archivo en donde estn
almacenadas las observaciones que corresponden al reporte
que se desea imprimir.
Con-,i!$o: 1equerimientos <.<
/i$ori': *reado el F de ,oviembre del <AAC
Re:&erimien$o: P <.3 Ti"o %e
re:&erimien$o: ?
E+en$oD!'o %e &o E: 3,3<
De!ri"!i#n: El sistema debe proveer un medio para que el usuario pueda escribir las observaciones de
la prueba on8line durante la simulacin.
R'B#n: !acilitar el anlisis posterior a la prueba del modelo.
Cri$erio %e
me%i%':
Nue las observaciones anotadas, se correspondan con el reporte impreso.
S'$i-'!!i#n %e, !,ien$e: C In'$i-'!!i#n %e, !,ien$e: C
De"en%en!i': Nue se pueda detener la simulacin para
anotar estas observaciones.
Con-,i!$o: 1equerimiento 3.@.<
/i$ori': *reado el G de ,oviembre del <AAC
Re:&erimien$o: P <.< Ti"o %e
re:&erimien$o: ?
E+en$oD!'o %e &o E: 3,3<
De!ri"!i#n: El sistema debe permitir almacenar las observaciones en un medio de almacenamiento
secundario.
R'B#n: $roveer el medio necesario para extraer la informacin contendr el reporte impreso.
Cri$erio %e
me%i%':
-erificar que se haya creado el archivo correspondiente.
De"en%en!i': Nue se pueda importar la informacin
editada en memoria principal a memoria secundaria.
Re:&erimien$o: P <.B Ti"o %e
re:&erimien$o: ?
E+en$oD!'o %e &o E: 3,3<
De!ri"!i#n: El sistema debe permitir que se puedan modificar las observaciones.
R'B#n: *orregir observaciones previas.
Cri$erio %e
me%i%':
-erificar que el archivo contenga las 2ltimas modificaciones reali#adas
Con-,i!$o: 1equerimiento <.<
/i$ori': *reado el @ de ,oviembre del <AAC
Re:&erimien$o: P <.C Ti"o %e
re:&erimien$o: ?
E+en$oD!'o %e &o E: 3,3<
De!ri"!i#n: El sistema debe permitir que se consulten observaciones de pruebas reali#adas
anteriormente.
R'B#n: *orroborar si las observaciones anteriores se corresponden con los criterios actuales del
usuario.
Cri$erio %e
me%i%':
-erificar que el archivo contenga las 2ltimas modificaciones reali#adas
Con-,i!$o: 1equerimiento <.<
Re:&erimien$o No F&n!ion',e
Re:&erimien$o: P B Ti"o %e
re:&erimien$o: 3Aa
De!ri"!i#n: La interfa# grfica en la que se muestra la solucin del modelo, debe presentarse por
defecto en colores agradables a la vista del usuario, donde exista un claro contraste entre el fondo de la
pantalla y la solucin grafica.
R'B#n: Evitar producir cansancio en la vista del usuario, ya que esto podra dificultar la observacin
adecuada de la prueba del modelo.
Cri$erio %e
me%i%':
*onsultar al usuario con respecto al cansancio de su vista, tras varias sesiones de
prueba.
libreras adecuadas para modificar los colores de la
representacin grfica.

Re:&erimien$o: P B.3 Ti"o %e re:&erimien$o:
3Aa,33b
De!ri"!i#n: El usuario puede modificar los colores por defecto de la solucin grafica.
R'B#n: Nue el usuario pueda adecuar el ambiente de graficacin de la prueba de acuerdo a sus
preferencias, lo que lo har sentir ms a gusto al momento de reali#ar las pruebas del modelo.
Cri$erio %e
me%i%':
Nue el usuario pueda utili#ar los colores de su preferencia.
libreras adecuadas para modificar los colores de la
Re:&erimien$o: P C Ti"o %e re:&erimien$o:
3Aa,33b
De!ri"!i#n: El usuario puede modificar la escala en que se representa la solucin grafica del modelo.
R'B#n: Nue el usuario pueda adecuar el ambiente de graficacin de la prueba de acuerdo a sus
preferencias, y que de acuerdo pueda observar me"or el comportamiento del modelo.
Cri$erio %e
me%i%':
Nue el usuario pueda reali#ar los cambios deseados.
libreras adecuadas para modificar loa escala de la
Re:&erimien$o: P F Ti"o %e re:&erimien$o:
3<a
De!ri"!i#n: El tiempo en que se grafica la solucin del modelo no representa una limitante del
sistema.
R'B#n: La simulacin no esta orientada a representar un sistema de tiempo real, sino a estudiar el
detalladamente el comportamientos del modelo.
Cri$erio %e
me%i%':
-erificar que la salida del modelo sea graficada correctamente sin importar el tiempo en
que sea graficada.
libreras adecuadas para representar la solucin grfica del
modelo correctamente.
Re:&erimien$o: P G Ti"o %e re:&erimien$o:
33b
E+en$oD!'o %e &o E: 3,F,3A
De!ri"!i#n: Los intervalos de tiempo en que se reali#a el fotografiado periodico se pueden configurar.
R'B#n: &umentar el grado de precisin de la prueba.
Cri$erio %e
me%i%':
Nue la cantidad de estados capturados se corresponda con el intervalo de tiempo
0eleccionado y el tiempo de la prueba.
De"en%en!i': El mnimo intervalo de tiempo seleccionado,
debe ser mayor al tiempo en que se genera y muestra la
solucin grafica.
Re:&erimien$o: P @ Ti"o %e re:&erimien$o:
3Cd
De!ri"!i#n: Las fotos deben ser guardadas en archivos tipo "pg o gif.
R'B#n: La portabilidad que ofrece este tipo de formatos
Cri$erio %e
me%i%':
-erificar que los archivos creados puedan ser abiertos con herramientas orientadas a
procesar este tipo de archivos.
De"en%en!i': Nue la herramienta de desarrollo provea los
mecanismos necesarios para la creacin de archivos de este
tipo.
/i$ori': *reado el F de ,oviembre del <AAC
Re:&erimien$o: P H Ti"o %e re:&erimien$o:
3Cd, 3<f
E+en$oD!'o %e &o E:
De!ri"!i#n: El sistema debe ser desarrollado en un lengua"e de alto nivel y no en una herramienta
como 05EL,Q.
R'B#n: Nue el sistema pueda solucionar modelos comple"os, que no pueden ser resueltos con
herramientas como 05EL,Q.
Cri$erio %e
me%i%':
-erificar que el sistema resuelva correctamente modelos comple"os
De"en%en!i': Nue la herramienta de desarrollo permita
desarrollar rutinas eficientes para la aplicacin de los mtodos
numricos seleccionados.
M'$eri',e %e '"o(o:
Re:&erimien$o: P ? Ti"o %e re:&erimien$o:
3Aa
E+en$oD!'o %e &o E: 3<
De!ri"!i#n: El sistema debe permitir que se active una ventana de texto usuario puede escribir las
observaciones correspondientes a la prueba que esta reali#ando en ese momento.
R'B#n: $roveer un mecanismo prctico para que el usuario lleve a cabo esta operacin.
Cri$erio %e
me%i%':
-erificar que la ventana se pueda activar durante la prueba del modelo.
De"en%en!i': Nue la herramienta de desarrollo este
orientada a un ambiente visual
Re:&erimien$o: P ?.3 Ti"o %e re:&erimien$o:
3<g
De!ri"!i#n: La ventana de edicin debe permitir el scroll8bac:.
R'B#n: $rocesar el volumen del texto escrito por el usuario sin importar su tama(o.
Cri$erio %e
me%i%':
-erificar que el texto escrito se desplace correctamente a medida que se va llenando la
ventana.
orientada a un ambiente visual.
M'$eri',e %e '"o(o: 'iagrama de *asos de Eso. 0eccin de !undamentos 7sicos.
Re:&erimien$o: P ?.< Ti"o %e re:&erimien$o:
3Aa, 33a
De!ri"!i#n: El sistema debe permitir que el usuario active y desactive la ventana de edicin.
R'B#n: Jacer mas sencillo al usuario la utili#acin de esta herramienta.
Cri$erio %e
me%i%':
Nue la ventana apare#ca y desapare#ca cuando se activen los mecanismos adecuados
)clic: del ratn.
Re:&erimien$o: P ?.B Ti"o %e re:&erimien$o:
3Aa, 33a
De!ri"!i#n: El sistema debe permitir que el usuario mueva la ventana de edicin.
Cri$erio %e
me%i%':
Nue la ventana se mueva cuando se activen los mecanismos adecuados )arrastre a travs
del ratn.
Re:&erimien$o: P ?.C Ti"o %e re:&erimien$o:
3Aa, 33a, 33b
De!ri"!i#n: El sistema debe permitir que el usuario configure el tama(o de la ventana de edicin.
Cri$erio %e
me%i%':
Nue la ventana cambie de tama(o va cuando se activen los mecanismos adecuados
) a travs del ratn.
/i$ori': *reado el ? de ,oviembre del <AAC
Re:&erimien$o: P 3A Ti"o %e re:&erimien$o:
3<a, 3Cd
E+en$oD!'o %e &o E: 3<,3B
De!ri"!i#n: Las anotaciones de la ventana deben ser almacenadas en un archivo de texto.
R'B#n: La portabilidad que ofrece este tipo de formatos, y por la rapide# con que se pueden imprimir.
Cri$erio %e
me%i%':
-erificar que los archivos creados puedan ser abiertos con herramientas orientadas a
procesar este tipo de archivos.
De"en%en!i': Nue la herramienta de desarrollo provea los
mecanismos necesarios para la creacin de archivos de texto.
/i$ori': *reado el 3A de ,oviembre del <AAC
Re:&erimien$o: P 3A.3 Ti"o %e re:&erimien$o:
33a
De!ri"!i#n: Las archivos de texto almacenados deben guardar por defecto la fecha de creacin y un
n2mero que identifique el modelo que se esta probando en ese momento.
R'B#n: !acilidad para que el usuario pueda relacionar la informacin contenida en el archivo con el
modelo que desea anali#ar.
Cri$erio %e
me%i%':
-erificar que los archivos creados guarden esta informacin.
De"en%en!i': 'esarrollar la rutinas de programacin que
anexen automticamente esta informacin al archivo de texto.
/i$ori': *reado el 3A de ,oviembre del <AAC
Re:&erimien$o: P 3A.< Ti"o %e re:&erimien$o:
33a
De!ri"!i#n: El nombre con que se guarda el archivo de texto, se creara por defecto con el n2mero que
identifica el modelo que se esta probando, concatenado con la fecha de creacin.
R'B#n: !acilidad para ubicar el archivo e imprimirlo.
Cri$erio %e
me%i%':
-erificar que los archivos creados se guardan con estos parmetros.
De"en%en!i': 'esarrollar la rutinas de programacin que
permitan crear los archivos de esta forma .
Re:&erimien$o: P 33 Ti"o %e re:&erimien$o:
3<c
De!ri"!i#n: El sistema debe proveer una buena precisin en la graficacin de la solucin
R'B#n: El xito o fracaso de la prueba depende de la observacin del comportamiento de la prueba, por
lo tanto los resultados de la solucin del modelo deben graficarse con la mayor precisin posible.
Cri$erio %e
me%i%':
-erificar la graficacin de la solucin de modelos caractersticos, donde ya se conoce su
salida.
De"en%en!i': Nue la herramienta de desarrollo provea las
funciones adecuadas para calcular y graficar con precisin las
soluciones del modelo.
/i$ori': *reado el 3< de ,oviembre del <AAC
Re:&erimien$o: P 3< Ti"o %e re:&erimien$o:
33a
E+en$oD!'o %e &o E:
De!ri"!i#n: El sistema debe permitir que el usuario etiquete las entradas de las variables del modelo.
R'B#n: !acilidad para que el usuario pueda utili#ar el sistema, ya que las etiquetas de las variables
permiten relacionar me"or el modelo con el sistema real que se pretende simular.
Cri$erio %e
me%i%':
,inguno
M'$eri',e %e '"o(o:
/i$ori': *reado el 3B de ,oviembre del <AAC
Re:&erimien$o: P 3B Ti"o %e re:&erimien$o:
33a
E+en$oD!'o %e &o E:
De!ri"!i#n: El sistema debe proveer una ventana de ayuda al usuario, por cada uno de los mdulos
presentados.
R'B#n: !acilidad para que el usuario pueda utili#ar el sistema.
Cri$erio %e
me%i%':
-erificar que los la informacin contenida en cada ventana, se relaciones con el uso del
modulo en donde fueron activadas.
M'$eri',e %e '"o(o:
/i$ori': *reado el 3B de ,oviembre del <AAC
V',i%'!i#n ( A%mini$r'!i#n %e Re:&erimien$o
La validacin y administracin de los requerimientos se fundamento en determinar si los
requerimientos eran verificables, comprensibles, rasteables y adaptables. $ara ello se
establecieron reuniones entre los sta:eholders y el grupo de traba"o, y se reali#aron
presentaciones p2blicas de los avances del proyecto, donde participaron los
sta:eholders, el grupo de traba"o y desarrolladores de otros proyectos, en estas
presentaciones se atendieron las dudas y consultas tanto de los sta:eholder y de los
desarrolladores invitados, de igual forma de grupo traba"o asisti a las presentaciones
de otros proyectos, lo que sirvi como punto de comparacin y fuente para extraer
aspectos comunes de proyectos diferentes. 4tras de las estrategias utili#adas aparte de
las revisiones formales e informales reali#adas, fue la utili#acin de una matri# de
rastreo de requerimientos, la cual permiti vincular requerimientos con otros
requerimientos y establecer la dependencia existente entre los mismos. La notacin
utili#ada consisti en usar una =E> para establecer una relacin fuerte entre los
requerimientos, e indicar que el requerimiento de la fila utili#aba los requerimientos
se(alados en la columna. 5ientras que una =1> significaba exista una relacin dbil
entre los requerimientos. La aplicacin de este tipo de estrategia fue posible debido a
que el n2mero de requerimientos a administrar fue relativamente peque(o y por lo tanto
no hi#o falta capturar la informacin de rastreo en una base de datos de requerimientos.

En la tabla , @ se muestran los resultados de la revisin, que determinaron si los
requerimientos eran verificables, comprensibles y adaptables, mientras que en la tabla
, H se muestra la matri# de rastreo que permiti determinar si los requerimientos eran
rasteables y evaluar el impacto del cambio en los requerimientos de acuerdo a la
dependencia existente entre los mismos.
Re:&erimien$o
Veri-i!'),e
Si No
Com"reni),e
Si No
A%'"$'),e
Si No
3 F F F
3.3 F F F
3.< F F F
3.B F F F
3.C F F F
3.F F F F
3.G F F F
3.@ F F F
3.@.3 F F F
3.@.< F F F
3.@.B F F F
3.@.C F F F
3.@.F F F F
3.@.G F F F
< F F F
<.3 F F F
<.< F F F
<.B F F F
<.C F F F
B F F F
B.3 F F F
C F F F
F F F F
G F F F
@ F F F
H F F F
? F F F
?.3 F F F
?.< F F F
?.B F F F
?.C F F F
3A F F F
3A.3 F F F
3A.< F F F
33 F F F
3< F F F
3B F F F
Ta)la N 3 *alidacin de los Re6uerimientos.
R
e
+
.
1 1
.
1
1
.
4
1
.
.
1
.
5
1
.
0
1
.
9
1
.
7
1
.
7
.
1
1
.
7
.
.
4
1
.
7
.
.
.
1
.
7
.
5
1
.
7
.
.
0
1
.
7
.
.
9
4 4
.
1
4
.
4
4
.
.
4
.
5
. .
.
1
5 0 9 " & &
.
1
&
.
4
&
.
.
&
.
5
1
>
1
>
.
1
1
>
.
4
1
1
1
4
1
.
1
R ( ( R R
1
.
1
R
1
.
4
(
1
.
.
R
1
.
5
( R
1
.
0
R
1
.
9
R ( (
1
.
7
R R R R R R (
1
.
7
.
1
( (
1
.
7
.
4
( (
1
.
7
.
.
R
1
.
7
.
5
R (
1
.
7
.
0
( R
1
.
7
.
9
( (
4
R R
4
.
1
(
4
.
4
(
4
R R
.
.
4
.
5
R R
.
R (
.
.
1
R
5
R
0
(
9
R
7
R
"
R
&
(
&
.
1
R
&
.
4
R
&
.
.
R
&
.
5
R
1
>
R
1
>
.
1
R
1
>
.
4
R
1
1
R
1
4
(
1
.
(
Ta)la N 4 Matri7 de Rastreo de los Re6uerimientos.

Proyecto Final Software

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Proyecto Final Software

Uploaded by

Copyright:

Available Formats

PROYECTO:

SISTEMA DE FACTURACION E INVENTARIO

You might also like