Sei sulla pagina 1di 29

Universidad de San Martn de Porres Facultad de Ingeniera y Arquitectura, 2014

PROYECTO I
Tema : Sistema de Inventario de
Equipos y Registro de Incidencias
(SIERI)
Informe nro. : 01
Profesor : Ing. Manuel Cceres
amp!n

Integrantes : Corte" #sque"$ %o&re
'quic(e C(ircca )aniel
Seccin : *+ I
Fecha de Presentacin : 0, de Mayo
-011
SIERI .gina 1
Curso:
.royecto 1
Tema:
1er /vance 0 .lanteamiento del
.ro1lema
Profesor:
Manuel Cceres amp!n
Nombre:
Corte" #sque"$ %o&re
'quic(e C(ircca )aniel
Fecha de Entrega:
0+ de /1ril

-011
Universidad de San Martn de Porres Facultad de Ingeniera y Arquitectura, 2014
N!ICE
1.1 Situaci2n .ro1lemtica.............................................................,
1.- )e3nici2n del .ro1lema............................................................,
1., 415etivos...................................................................................,
1.,.1 415etivo 6eneral.................................................................,
1.,.- 415etivos Espec73cos...........................................................*
1.* 8usti3caci2n...............................................................................*
1.+ imitaciones..............................................................................+
1.9 #ia1ilidad..................................................................................+
1.9.1 #ia1ilidad :!cnica................................................................+
1.9.- #ia1ilidad 4perativa............................................................;
1.9., #ia1ilidad Econ2mica..........................................................<
1.9.* Evaluaci2n de /lternativas..................................................<
-.1 /ntecedentes............................................................................=
-.1.1 El tra1a5o de danielli aguilar 1eristain>................................=
-.1.- El tra1a5o de Eric? /l1ert(o Euan @aldestrand>................10
-.1., El tra1a5o de Ra&ael /ldrette Malacara>............................11
-.- Aases :e2ricas.........................................................................1,
-., )e3nici2n de :!rminos Asicos...............................................1=
,.1 Materiales...............................................................................-0
,.1.1 Bumanos>..........................................................................-0
,.1.- Equipos y So&tCare>...........................................................-0
,.- M!todos D R'. (Rational 'ni3ed .rocess)...............................-1
,.-.1 Caracter7sticas esenciales.................................................-1
,.-.- Eases.................................................................................--
,.-., )escripci2n de las Eases>..................................................-,
,.-.* #enta5as y )esventa5as.....................................................-9
SIERI .gina -
Universidad de San Martn de Porres Facultad de Ingeniera y Arquitectura, 2014
C"PIT#$O I: P$"NTE"%IENTO !E$ PRO&$E%"
1.1 Situacin Problemtica
a 'SM. D EI/ (Eacultad de Ingenier7a y /rquitectura) es una
Instituci2n prestigiosa$ que 1rinda Servicios de Educaci2n Superior$
en esta instituci2n se encuentran las diversas reas de
investigaci2n$ desarrollo y producci2n quienes con su la1or elevan
el reconocimiento de la Eacultad al pF1lico en general.
Internamente tiene diversos servicios como son la Ai1lioteca$
Aienestar 'niversitario$ Servicio M!dico$ Coordinaci2n /cad!mica$
'M/ ('nidad de Mesa de /yuda)$ entre otras.
En la actualidad en la EI/ en su a&n de preservar su alto nivel de
competitividad &rente a otras instituciones renueva
constantemente los equipos de todos sus la1oratorios$ reas de
investigaci2n y personal administrativo. Sin em1argo cada rea
(ace un registro independiente y por lo general manual de los
dispositivos que se les est entregando.
1.2 Defnicin del Problema
)e1ido a la &orma independiente y manual que cada rea tiene
para registrar sus equipos$ no se cuenta con una in&ormaci2n
precisa de la cantidad de equipos con los que cuenta la &acultad.
:ampoco se cuenta con un registro detallado delG (istorial de
incidencias de cada equipo$ lo cual ser7a de suma ayuda a las
reas responsa1les de su mantenimiento. :oda esta situaci2n
promueve la duplicidad de in&ormaci2n$ p!rdida de tiempo por
&alta de una metodolog7a Fnica para el registro de los equipos y
control tedioso de un importante recurso con que cuenta la
&acultad.
1.3 Objetivos
'.(.' Ob)eti*o +enera,
)esarrollar un sistema integrado$ 1asado en una tecnolog7a
cliente servidor$ Fnico y transparente que &acilite la gesti2n de
todos los equipos con los que cuenta la &aculta. 'na ve"
ingresados al sistema$ en el &uturo cuando originen incidencias$
estas se podrn registrar$ controlar y solucionar de una manera
ms e3ciente. El prop2sito de este proyecto es desarrollar un
SIERI .gina ,
Universidad de San Martn de Porres Facultad de Ingeniera y Arquitectura, 2014
sistema que automatice la gesti2n detallada de tola in&ormaci2n
que pueda generar los que equipos con que cuenta la Eacultad.
'.(.- Ob)eti*os Es.ec/0cos
Reducir los tiempos de atenci2n de incidencias por parte de
mesa de ayuda.
Reducir los tiempos del proceso de renovaci2n de equipos.
Elevar el nivel de satis&acci2n del usuario 3nal.
/gili"ar la resoluci2n de preguntas como HIu! anc(o de
1anda se necesita en un rea determinadaJ 4 HCuntos
equipos (an &allado en los que va del aKoJ$ etc.
Calcular el consumo de energ7a de los equipos.
1.4 Justifcacin
Boy en d7a en el que los requerimientos en los servicios son ms
eLigentes en la 3aDusmp$ se requiere contar un sistema que
disminuya el tiempo de atenci2n en cuanto a las incidencias de los
equipos de c2mputo$ que son atendidas por el rea de 'M/ de &7aD
data$ un sistema que lleve el control de inventarios de equipo $ se
de1e implementar este sistema para que apoye a uno de los
o15etivos importantes de la 3aDusmp que es la atenci2n de un
1uen servicio$ y me5orar el prestigio de la universidad.
Cuando se requiere la petici2n del servicio para la soluci2n de una
incidencia$ (ay demora en la atenci2n y a veces en la soluci2n
misma del pro1lema$ lo que genera incomodidad por parte del
cliente.
Cuando (ay alguna incidencia en los equipos$ pues si se tiene
algFn pro1lema solo se le avisa al encargado$ pero si dic(a
persona no anota las peticiones$ pasan por alto y no se atienden
(asta que se vuelve a reportar dic(o pro1lema$ y eso impide dar
una 1uena atenci2n a los clientes de dic(a instituci2n.
El sistema a crea nos permitir registran$ controlan y 1rindan la
opci2n de soluci2n a las incidencias ocurridas en la EI/.
levar un registro preciso y detallado de las Incidencias ocurridas
en un mesM actuali"ar y clasi3car las incidencias de los clientes.
levara un me5or control de los equipos de c2mputo$ esto es$ que
pueda sa1er en el momento que lo requiera Hcon cuntos equipos
cuentanJ HIu! equipos &uncionan correctamenteJ$ que permita a
los usuarios generar reportes de soluciones a &allas de los equipos
SIERI .gina *
Universidad de San Martn de Porres Facultad de Ingeniera y Arquitectura, 2014
de c2mputo$ y que se pueda acceder a ellos y darles seguimiento$
actuali"ando su in&ormaci2n con&orme vaya atendiendo dic(as
peticiones.
/l igual que permitir al encargado de dic(a rea$ generar reportes
de inventarios$ condiciones de los equipos de c2mputo o in&ormes
detallados de los componentes y u1icaci2n de dic(os equipos o
componentes. El encargado podr pu1licar$ datos importantes
so1re las condiciones de los equipos
1.5 imitaciones
El proyecto se encuentra en&ocado solo para las incidencias
ocurridas dentro de la usmpD&7a$ y que se puede dar en el pa1ell2n
de estudios generales$ especialidades$ &7aDdata$ mesa departes$
tesorer7a$ coordinaci2n acad!mica$ 1i1lioteca$ entrada$ entre otros.
1.! "iabilidad
'.1.' 2iabi,idad T3cnica
.ara la reali"aci2n del sistema de inventario de equipos y
registro de incidencias (SIERI) ser necesario contar con>
- .cNs de procesador Intel Core - )uo con ,61 de Ram y
-00 61 de disco duro
.ara levantar el servicio se necesitara un servidor
Empresaria IAM O,*00 M, el cual ya posee la &acultad.
SIERI .gina +
Universidad de San Martn de Porres Facultad de Ingeniera y Arquitectura, 2014
Aase de )atos>
SI Server -00< (Cantidad P 1)
.lata&ormas>
@indoCs Server -00< (Cantidad P 1)
@indoCs ; pro&esional Sp1 (Cantidad P -)
engua5e de .rogramaci2n>
.B.
Berramienta de programaci2n
Qote.adRR
Servidor @e1
O/M..
SIERI .gina 9
Universidad de San Martn de Porres Facultad de Ingeniera y Arquitectura, 2014
'.1.- 2
ia
bi,
id
ad
O.erati*a
El !Lito del proyecto depender inicialmente de la correcta
recolecci2n de requerimientos por parte de los principales
usuarios 3nales.
SIERI .gina ;
# Roles y Responsabilidades
Nro.
Recursos
1
Jefe de Proyecto
Lder de la Administracin del Proyecto
Presenta el Plan detallado del Proyecto al inicio
del mismo.
Responsabilidades de la Administracin del
Proyecto
Reportes de estado quincenales.
1
2
Analista Tcnico
specificaciones de la Arquitectura de la
solucin
!odelo "onceptual# $ise%o L&ico y $ise%o
'sico de la
(ase de $atos de la solucin
Lder en el dise%o de la solucin
An)lisis y control funcional sobre la
*erramienta de "R! +"ustomer
relations*ip mana&ement,.
1
-
Pro&ramador
Parametri.ar la structura /eneral
$esarrollo de "omponentes de la solucin
0nte&racin de componentes
$ise%o de estructura de datos de la solucin
1ecucin de confi&uraciones sobre la ($
"apacitador a ni2el administrati2o y tcnico
2
Universidad de San Martn de Porres Facultad de Ingeniera y Arquitectura, 2014
En conversaciones con algunos 5e&es de rea de la &acultad$ los
cuales tienen a su cargo una considera1le cantidad de equipos$
mani&estaron la necesidad que tiene la implementaci2n de un
sistema como este$ por lo cual concluimos que no
encontraremos rec(a"o del mismo.
a &acultad ya cuenta con un rea de in&ormtica que cuenta a
su ve" con su1 reas de desarrollo y producci2n (S:I Servicios
de :ecnolog7as de In&ormaci2n). S:I cuenta con el servidor y
licencias que necesitamos por tanto no se incurrir7a en el gasto
de compra de estos costosos equipos ni de las licencias (de la
1ase de datos).
Se necesitar7a que S:I nos otorgara una instancia virtual en uno
de los servidores que posee.
El proyecto puede ser implementado no s2lo en la &acultad sino
en toda la 'niversidad$ e incluso desarrollarse un producto 3nal
moldea1le a los requerimientos de cada organi"aci2n.
'.1.( 2iabi,idad Econmica
3ombre del Recurso 4oras 5emanales "osto
Analista6 $esarrollador+2, 274rs. 56.89:#::
$ocumentador
1:4rs.
56. 1;:#::
"osto Total Recursos 5emanal
56.111:#::
"osto Total Recursos !ensual 56. 7.77:#::
"osto Total de Recursos del Proyecto+9 meses, S/. 26.640,00
SIERI .gina <
Universidad de San Martn de Porres Facultad de Ingeniera y Arquitectura, 2014
'.1.4 E*a,uacin de ",ternati*as
.CS Inventario 1.0>
Esta (erramienta li1re no permite (acer un inventario de un
rea de tra1a5o$ pero tan solo puede instalarse en una .C$ por lo
cual solo una persona puede tener acceso a est. S2lo se
dedica a gestionar inventario ms no a incidencias.
Registro manual>
Es el mane5o actual que se da en la &acultad$ registrndose los
equipos en (o5as de clculo en ELcel y gestionndolo por
correo.
SIERI .gina =
Universidad de San Martn de Porres Facultad de Ingeniera y Arquitectura, 2014
C"PIT#$O II: %"RCO TE5RICO
2.1 #ntecedentes
-.'.' E, traba)o de danie,,i agui,ar beristain:
:esis pro&esional$ para la o1tenci2n del t7tulo de licenciada en
ciencias de la computaci2n so1re el proyecto de SSIS:EM/ )E
IQ#EQ:/RI4 ./R/ E /RE/ )E M/Q:EQIMIEQ:4 )E .C S.
1
Prob,ema
/ctualmente el mane5o de el rea de mantenimiento de .C$ se
lleva de una manera muy rudimentaria$ ya que por e5emplo$
cuando se le pide al encargado de dic(a rea$ un inventario
completo del equipo de c2mputo con el que se cuenta$ !ste se
reali"a de manera manual en ese instante$ ya que no se cuenta
con un sistema que permita &acilitar dic(a tarea. /l igual de que
se da el caso de que varios componentes de un equipo
simplemente se eLtrav7an o no se encuentran en el lugar
correspondiente pues no se sa1e en donde 1uscar
:am1i!n se tiene un grave pro1lema en la atenci2n constante
en la soluci2n a &allas de dic(os equipos$ pues si se tiene algFn
pro1lema solo se le avisa al encargado$ pero si dic(a persona no
anota las peticiones$ pasan por alto y no se atienden (asta que
se vuelve a reportar dic(o pro1lema$ y eso impide dar una
1uena atenci2n a los alumnos de dic(a instituci2n.
So,ucin
Se pretende crear un sistema que permita al encargado del rea
de mantenimiento de .C$ de una escuela de computaci2n$ tener
un me5or control de los equipos de c2mputo$ esto es$ que pueda
sa1er en el momento que el lo requiera Hcon cuntos equipos
cuentaJHIu! equipos &uncionan correctamenteJ$ que permita a
los usuarios generar reportes v7a @EA de las peticiones de
soluciones a &allas de los equipos de c2mputo$ y el encargado
pueda acceder a ellos y darles seguimiento$ actuali"ando su
in&ormaci2n con&orme vaya atendiendo dic(as peticiones.
/l igual que permitir al encargado de dic(a rea$ generar
reportes de inventarios$ condiciones de los equipos de c2mputo
o in&ormes detallados de los componentes y u1icaci2n de dic(os
equipos o componentes.
1
(ttp>TTperseo.cs.1uap.mLT1ellatriLTtesisT:ES*+0.pd&
SIERI .gina 10
Universidad de San Martn de Porres Facultad de Ingeniera y Arquitectura, 2014
El encargado podr pu1licar$ datos importantes so1re las
condiciones de los equipos$ as7 como tam1i!n podr pu1licar
que peticiones (a atendido
-.'.- E, traba)o de Eric6 ",bertho Euan 7a,destrand:
:esis pro&esional para la o1tenci2n del t7tulo de licenciada en
ciencias de la computaci2n so1re el .royecto SSIS:EM/ )E
RE6IS:R4 )E IQCI)EQCI/S C4M4 ./R:E )E SIS:EM/
IQ:E6R/ )E SE6'RI)/) 'QI#ERSI:/RI/U.
-
Prob,ema
a )irecci2n de .rotecci2n 'niversitaria almacena todos sus
reportes de las incidencias que ocurren cotidianamente en (o5as
de papel$ estas son llenadas por el personal encargado de
vigilar todas las "onas de ciudad universitaria$ al 3nali"ar el d7a
los reportes son entregados a la 8e&atura de Seguridad$ el
personal de la dependencia lee los reportes$ los captura en un
arc(ivo de ELcel y posteriormente las (o5as son guardadas en
arc(iveros. Esto ocasiona que se tenga una in&ormaci2n
desordenada$ que sea di&7cil eLtraer datos necesarios concisos
de algFn reporte determinado adems de que tendrn
montones de papel con&orme transcurra el tiempo.
as .ersonas encargadas de llevar el control (acen la captura
de la in&ormaci2n en un li1ro de eLcel asignndole a cada (o5a
un tipo de incidencia$ esto tiene limitantes$ cuando desean
reali"ar tareas como generar in&ormes$ consultar reportes$ (acer
1Fsquedas$ eLtraer datos concretos$ ela1oraci2n de gr3cos
que reVe5en en comportamiento de la in&ormaci2n etc.
a dependencia s2lo lleva el control de los reportes de
incidencias por nFmero en una (o5a de eLcel$ es decir
solamente tienen el numero de reportes de incidencias
ocurridas cada mes$ pero no pueden consultar su descripci2n$ si
quisieran consultar su descripci2n tendr7an que 1uscar en los
montones de papel acumulados durante el mes 2 cuatrimestre
segFn la &ec(a del reporte.
.onemos la tarea de ela1orar un in&orme mensual que son
entregados a la secretaria administrativa el cual consiste en
desglosar la descripci2n de la incidencia y la cantidad de veces
que ocurri2 en un determinado periodo de tiempo.
So,ucin
a soluci2n al pro1lema es crear un sistema que automatice el
proceso de almacenamiento de los reportes de incidencias en la
-
(ttp>TTperseo.cs.1uap.mLT1ellatriLTtesisT:ES10*+.pd&
SIERI .gina 11
Universidad de San Martn de Porres Facultad de Ingeniera y Arquitectura, 2014
direcci2n de protecci2n universitaria$ para ello registraremos
todas los reportes de incidencias ocurridas en una 1ase de
datos para despu!s generar los in&ormes y (acer las consultas
necesarias.
.ara resolver este pro1lema nos apoyaremos en conceptos y
estrategias que actualmente son aplicados en Aases de )atos$
la 1ase de datos a diseKar de1e almacenar in&ormaci2n
clasi3cada acerca de los di&erentes reportes de incidencias
ocurridas.
-.'.( E, traba)o de Rafae, ",drette %a,acara:
:esis pro&esional para la o1tenci2n del t7tulo de licenciada en
ciencias de la computaci2n so1re el .royecto de SSIS:EM/ )E
C4Q:R4 )E IQ#EQ:/RI4 % RE.4R:ES )E E//SU.

Prob,ema
a 'niversidad de las /m!ricas$ .ue1la (')/) cuenta con la
)irecci2n de Capacitaci2n y Servicio en Sistemas (C/SS)$ misma
que tiene a su cargo el )epartamento de /tenci2n a 'suarios$ el
cual entre otras actividades esta encargado de reali"ar el
inventario de todo el equipo de c2mputo$ adems de dar
servicio a los usuarios que tengan pro1lemas con estos. )ic(o
departamento cuenta con - sistemas para llevar aca1o estos
tareas$ pero am1os sistemas son muy anticuados y o1soletos$
ya que &ueron desarrollados en )C$ )/ y R/%.
a &uncionalidad de los sistemas de inventario y reportes de
&allas de equipo de c2mputo con los que cuenta /tenci2n a
'suarios parecen &uncionar para dos tareas independientes una
de la otra$ pero no es as7$ ya que las mquinas a las que se les
1rinda servicio$ son las mismas que se encuentran en el
inventario. Es importante o1servar que am1os sistemas
requieren de la misma in&ormaci2n para poder tra1a5ar
adecuadamente.
El sistema de Inventarios es el encargado de interactuar con un
mane5ador de 1ases de datos para poder reali"ar consultas
so1re el equipo eListente y reali"ar cam1ios$ altas o 1a5as.
El otro sistema es utili"ado para atender reportes de pro1lemas
con algFn equipo. Cuando se Wlevanta el reporteW se accesa al
sistema y Xe llena una &orma. .osteriormente$ un operador
consulta los reportes que est!n vigentes en el sistema$ los
atiende y una ve" que se (a solucionado el pro1lema$ se cierra el
,

(ttp>TTcatarina.udlap.mLTuYdlYaTtalesTdocumentosTlisTaldretteYmYrTcapituloY1.(tmlZ
SIERI .gina 1-
Universidad de San Martn de Porres Facultad de Ingeniera y Arquitectura, 2014
reporte.
El sistema utili"ado por /tenci2n a 'suarios para mane5ar el
inventario de todo el equipo que se tiene en la ')/ &ue
reali"ado (ace muc(os aKos y resulta o1soleto$ pues !ste$ es
dependiente de la plata&orma Macintos(. Esto limita al usuario
a (acer cam1ios o consultas de la 1ase de datos$ pues lo
anterior no puede ser reali"ado en computadoras que &uncionen
con otro sistema operativo.
Ob)eti*o +enera,
)esarrollar un sistema capa" de reali"ar por separado las
tareas de control de inventario y de mane5o de reportes de
&allas tomando en cuenta la relaci2n tan estrec(a que eListe
entre ellas. o anterior$ con el 3n de &acilitar el accionar diario
de las personas que constantemente tra1a5an con esa
in&ormaci2n
So,ucin
)e acuerdo a los requerimientos eLpresados por los usuarios$ la
me5or opci2n para moderni"ar los sistemas de inventario y
reportes que utili"a C/SS$ es desarrollar un sistema usando la
tecnolog7a de 8S.[s en el cual se mane5en por separado am1os
sistemas. EListir una relaci2n muy estrec(a entre am1os
sistemas$ ya que un reporte se levanta$ solo si la maquina
pertenece a la ')/$ por lo que de1e estar dado de alta en la
1ase de datos de inventario.
El utili"ar 8S.[s$ implica que la aplicaci2n ser e5ecutada v7a @e1$
por lo cual puede ser utili"ada en cualquier mquina capa" de
navegar en Internet. Se lograr la independencia de
plata&orma$ pero adems$ se propone la implementaci2n de un
mapa espacial para el rea de reportesM con lo cual se tendr la
venta5a de contar con una imagen del campus en la cual se
mostrar la u1icaci2n de la mquina a la cual se de1e acudir
para cu1rir el reporte. Con esas modi3caciones el sistema
tendr valores agregados que &acilitarn el desempeKo del
personal de /tenci2n a usuarios en sus la1ores cotidianas y se
reVe5ar en 1ene3cios tales como>
Mayor rapide" en la atenci2n a la
comunidad universitaria
Mayor organi"aci2n en los datos (ist2ricos
y de inventario
Mayor aprovec(amiento de las 1itcoras para la o1tenci2n
de tendencias que
SIERI .gina 1,
Universidad de San Martn de Porres Facultad de Ingeniera y Arquitectura, 2014
ayuden a la toma de decisiones del departamento.
Me5oramiento de la percepci2n del servicio por parte de los
usuarios
Questra investigaci2n tuvo como 1ase principal estos , proyectos$
en el cual (ay sistemas de inventario de equipos de c2mputo y
registro de incidencias. Este sistema aun presenta irregularidades
en su &uncionamiento$ pero nos dio una idea general para
desarrollar nuestro so&tCareM a continuaci2n detallaremos en &orma
general de que se trata este sistema en el punto -.-.
,
(ttp>TTcatarina.udlap.mLTuYdlYaTtalesTdocumentosTlisTaldretteYmYrTcapituloY1.(tmlZ
2.2 $ases %ericas
El Belp )es? o Mesa de /yuda es un servicio integral que$ a trav!s
de un punto de contacto$ 1rinda la soluci2n de incidencias y
atenci2n de requerimientos relacionados a la tecnolog7a de
In&ormaci2n$ como son> computadores$ laptops$ .)/\s$ peri&!ricos$
recursos in&ormticos$ aplicaciones y plata&ormas so1re las que
tra1a5a la mayor7a de compaK7as.
En las compaK7as de (oy en d7a$ cada usuario (cliente interno)
tiene un .C (.ersonal Computer o computador personal que puede
ser laptop o des?top) con el que tra1a5a y opera diariamente.
os usuarios estn &amiliari"ados con la tecnolog7a$ sin em1argo
se podr7a decir que nadie conoce a detalle c2mo &uncionan todas
las aplicaciones y para que sirve cada una de ellas$ por lo que se
perci1e que la &alta de capacitaci2n puede ser un pro1lema grave
en la organi"aci2n.
Cuando un usuario tiene algFn tipo de pro1lema re&erente a la
tecnolog7a que opera o requiere soporte tecnol2gico$ (ace una
llamada a una eLtensi2n tele&2nica o env7a un correo electr2nico a
trav!s de un 1u"2n de correo solicitando la ayuda necesaria. 'no
de los t!cnicos que se encuentra conectado al centro de soporte
reci1e la llamada y revisa constantemente el 1u"2n de correo.
Cuando un requerimiento ingresa a la Mesa de /yuda$ uno de los
t!cnicos del Belp )es? trata de resolver el caso inmediatamente$
remotamente guiando al usuario a corregir el pro1lema a trav!s
SIERI .gina 1*
Universidad de San Martn de Porres Facultad de Ingeniera y Arquitectura, 2014
del tel!&ono. Este tipo de soporte se conoce como soporte de
.rimer nivel$ dado que se reali"a al primer contacto.
En caso de resolver el pro1lema presencialmente$ se conoce como
soporte en sitio (4n site support)$ puesto que los casos no se
resuelven mediante la eLtensi2n tele&2nica sino que se requiere
de un apoyo presencial$ por regla general se trata de un caso
)ES]:4. (casos de Segundo nivel de soporte). )e cualquier modo$
el t!cnico que atiende el caso$ genera un tic?et de atenci2n y
soluci2n$ a trav!s de una 1ase de datos. / continuaci2n se
muestra un esquema completo del &uncionamiento de un Belp
)es? en la mayor7a de compaK7as (#er Eigura 1).
EListen tres niveles$ y comFnmente las llamadas son atendidas en
el primer contacto es decir en el primer nivel de soporte.
WEl segundo nivel de soporte consiste de analistas de Belp )es?
quienes se encuentran reali"ando otras actividades mientras
solucionan los pro1lemas$ usualmente se encuentran rotando
entre el primero y segundo nivel$ es decir que ellos tienen
eLperiencia en la soluci2n de pro1lemas y en entender los
pro1lemas que se generan en primer nivel.
El tercer nivel de soporte t7picamente involucra reas &uera del
Belp )es?$ como soporte t!cnico$ administraci2n de 1ases de
datos$ desarrollo de programas y administraci2n de redes.
W)ependiendo de los servicios de Belp )es? algunas de estas
reas pueden residir dentro del Belp )es? o a su ve"$ &uera de !l.
)e cualquier manera no eListen dos servicios de Belp )es? iguales
en el mundo$ por el tipo de actividades que se reali"an o por el
tipo de soporte que se presta.
SIERI .gina 1+
Flujo standard de un Help Desk
Universidad de San Martn de Porres Facultad de Ingeniera y Arquitectura, 2014
)escripci2n de los .ro1lemas en el Belp )es?.
a mesa de ayuda por regla general por tratarse de un rea de
servicio atraviesa por pro1lemas 1astante graves que daKan la
imagen de la compaK7a y del departamento de sistemas (I:). /
continuaci2n se descri1en algunos de los pro1lemas ms
comunes>
.ro1lemas>
Qo eListe un proceso de3nido ni un procedimiento de atenci2n
de requerimientos$ la mayor7a de casos se atienden con&orme
ingresan al Belp )es? por prioridad de llamada$ cuando un
t!cnico reci1e una llamada$ !ste se traslada directamente (acia
donde se encuentra el usuario para poder solucionar$ de5ando el
resto de llamadas en cola.
El Belp )es? carece de estndares y pol7ticas claras de atenci2n
de casos
a inadecuada distri1uci2n de los recursos (ace que un usuario
en ocasiones espere por tiempos prolongados
El volumen de llamadas que ingresan a la mesa de ayuda son
no controla1les
Como los usuarios no son atendidos se generan rellamados$ es
decir que por un mismo caso los usuarios llaman ms de una
ve".
Qo eListe un m!todo para evaluar a los t!cnicos ni un control
para organi"ar las la1ores de los mismos.
Qo eListen niveles de servicio$ contemplados en indicadores de
gesti2n o acuerdos de niveles de servicio que permitan (acer
mediciones so1re el proceso.
SIERI .gina 19
Universidad de San Martn de Porres Facultad de Ingeniera y Arquitectura, 2014
os t!cnicos que atienden las llamadas cada d7a tienen ms
carga de tra1a5o y su la1or se torna agotadora y desmotivante
por la de3ciente distri1uci2n de tra1a5o.
"r8uitectura C,iente9Ser*idor
a arquitectura clienteDservidor consiste 1sicamente en un cliente
que reali"a peticiones a otro programa (el servidor) que le da
respuesta. /unque esta idea se puede aplicar a programas que se
e5ecutan so1re una sola computadora es ms venta5osa en un sistema
operativo multiusuario distri1uido a trav!s de una red de
computadoras.
En esta arquitectura la capacidad de proceso est repartida entre los
clientes y los servidores$ aunque son ms importantes las venta5as de
tipo organi"ativo de1idas a la centrali"aci2n de la gesti2n de la
in&ormaci2n y la separaci2n de responsa1ilidades$ lo que &acilita y
clari3ca el diseKo del sistema.
a separaci2n entre cliente y servidor es una separaci2n de tipo
l2gico$ donde el servidor no se e5ecuta necesariamente so1re una sola
mquina ni es necesariamente un s2lo programa. os tipos
espec73cos de servidores incluyen los servidores Ce1$ los servidores
de arc(ivo$ los servidores del correo$ etc. Mientras que sus prop2sitos
SIERI .gina 1;
Universidad de San Martn de Porres Facultad de Ingeniera y Arquitectura, 2014
var7an de unos servicios a otros$ la arquitectura 1sica seguir siendo
la misma.
'na disposici2n muy comFn son los sistemas multicapa en los que el
servidor se descompone en di&erentes programas que pueden ser
e5ecutados por di&erentes computadoras aumentando as7 el grado de
distri1uci2n del sistema.
a arquitectura clienteDservidor sustituye a la arquitectura monol7tica
en la que no (ay distri1uci2n$ tanto a nivel &7sico como a nivel l2gico.
a red clienteDservidor es aquella red de comunicaciones en la que
todos los clientes estn conectados a un servidor$ en el que se
centrali"an los diversos recursos y aplicaciones con que se cuentaM y
que los pone a disposici2n de los clientes cada ve" que estos son
solicitados. Esto signi3ca que todas las gestiones que se reali"an se
concentran en el servidor$ de manera que en !l se disponen los
requerimientos provenientes de los clientes que tienen prioridad$ los
arc(ivos que son de uso pF1lico y los que son de uso restringido$ los
arc(ivos que son de s2lo lectura y los que$ por el contrario$ pueden
ser modi3cados$ etc. Este tipo de red puede utili"arse con5untamente
en caso de que se est! utili"ando en una red miLta.^
^ (ttp>TTes.Ci?ipedia.orgTCi?iTClienteDservidor
SIERI .gina 1<
Universidad de San Martn de Porres Facultad de Ingeniera y Arquitectura, 2014
P:P
.B. es un acr2nimo recursivo que signi3ca .B. ByperteLt .reD
processor (inicialmente .B. :ools$ o$ .ersonal Bome .age :ools). Eue
creado originalmente por Rasmus erdor& en 1==*M sin em1argo la
implementaci2n principal de .B. es producida a(ora por :(e .B.
6roup y sirve como el estndar de &acto para .B. al no (a1er una
especi3caci2n &ormal. .u1licado 1a5o la .B. icense$ la Eree So&tCare
Eoundation considera esta licencia como so&tCare li1re.
.uede ser desplegado en la mayor7a de los servidores Ce1 y en casi
todos los sistemas operativos y plata&ormas sin costo alguno. El
lengua5e .B. se encuentra instalado en ms de -0 millones de sitios
Ce1 y en un mill2n de servidores$ el nFmero de sitios en .B. (a
compartido algo de su preponderante sitio con otros nuevos lengua5es
no tan poderosos desde agosto de -00+. Este mismo sitio Ce1 de
@i?ipedia est desarrollado en .B.. Es tam1i!n el m2dulo /pac(e
ms popular entre las computadoras que utili"an /pac(e como
servidor Ce1.
El gran parecido que posee .B. con los lengua5es ms comunes de
programaci2n estructurada$ como C y .erl$ permiten a la mayor7a de
los programadores crear aplicaciones comple5as con una curva de
aprendi"a5e muy corta. :am1i!n les permite involucrarse con
aplicaciones de contenido dinmico sin tener que aprender todo un
nuevo grupo de &unciones.
/unque todo en su diseKo est orientado a &acilitar la creaci2n de
sitios Ce1s$ es posi1le crear aplicaciones con una inter&a" gr3ca para
el usuario$ utili"ando la eLtensi2n .B.DIt o .B.D6:]. :am1i!n puede
ser usado desde la l7nea de 2rdenes$ de la misma manera como .erl o
.yt(on pueden (acerloM a esta versi2n de .B. se la llama .B.DCI
(Command ine Inter&ace).
Cuando el cliente (ace una petici2n al servidor para que le env7e una
pgina Ce1$ el servidor e5ecuta el int!rprete de .B.. _ste procesa el
script solicitado que generar el contenido de manera dinmica (por
e5emplo o1teniendo in&ormaci2n de una 1ase de datos). El resultado
es enviado por el int!rprete al servidor$ quien a su ve" se lo env7a al
cliente. Mediante eLtensiones es tam1i!n posi1le la generaci2n de
arc(ivos .)E$ Elas($ as7 como imgenes en di&erentes &ormatos.
.ermite la coneLi2n a di&erentes tipos de servidores de 1ases de
datos tales como MySI$ .ostgreSI$ 4racle$ 4)AC$ )A-$ Microso&t
SI Server$ Eire1ird y SIite.
O/M.. es un servidor independiente de plata&orma$ so&tCare li1re$
que consiste principalmente en la 1ase de datos MySI$ el servidor
SIERI .gina 1=
Universidad de San Martn de Porres Facultad de Ingeniera y Arquitectura, 2014
@e1 /pac(e y los int!rpretes para lengua5es de script> .B. y .erl. El
nom1re proviene del acr2nimo de O (para cualquiera de los di&erentes
sistemas operativos)$ /pac(e$ MySI$ .B.$ .erl. El programa est
li1erado 1a5o la licencia 6Q' y actFa como un servidor @e1 li1re$ &cil
de usar y capa" de interpretar pginas dinmicas. /ctualmente
O/M.. esta disponi1le para Microso&t @indoCs$ 6Q'TinuL$ Solaris$ y
Mac4S O.
.B. tam1i!n tiene la capacidad de ser e5ecutado en la mayor7a de los
sistemas operativos$ tales como 'niL (y de ese tipo$ como inuL o
Mac 4S O) y Microso&t @indoCs$ y puede interactuar con los
servidores de Ce1 ms populares ya que eListe en versi2n C6I$
m2dulo para /pac(e$ e IS/.I.
.B. es una alternativa a las tecnolog7as de Microso&t /S. y /S..QE:
(que utili"a CZ y #isual Aasic .QE: como lengua5es)$ a ColdEusion de
la empresa /do1e$ a 8S.T8ava y a C6IT.erl. /unque su creaci2n y
desarrollo se da en el m1ito de los sistemas li1res$ 1a5o la licencia
6Q'$ eListe adems un entorno de desarrollo integrado comercial
llamado `end Studio. Recientemente$ Code6ear (la divisi2n de
lengua5es de programaci2n de Aorland) (a sacado al mercado un
entorno de desarrollo integrado para .B.$ denominado [)elp(i &or
.B.. :am1i!n eListen al menos un par de m2dulos para Eclipse$ uno
de los entornos ms popularesa
a(ttp>TTCCC.p(p.netT
2.3 Defnicin de %&rminos $sicos
Incidencia
Cualquier evento o suceso que no cumple dentro del
&uncionamiento estndar en los equipos de c2mputo

SIERI .gina -0
Universidad de San Martn de Porres Facultad de Ingeniera y Arquitectura, 2014
Equipo de computo
Maquinas electr2nicas que permiten el procesamiento de datos
'suario
'n usuario es un individuo que utili"a una computadora$
sistema operativo$ servicio o cualquier sistema in&ormtico. .or
lo general es una Fnica persona.Servidor
Servidor
Es un tipo de so&tCare que reali"a ciertas tareas en nom1re de
los usuarios
El t!rmino servidor a(ora tam1i!n se utili"a para re&erirse al
ordenador &7sico en el cual &unciona ese so&tCare$ una mquina
cuyo prop2sito es proveer datos de modo que otras mquinas
puedan utili"ar esos datos.
Inventario
Registro documental de los 1ienes y dems cosas
pertenecientes a una persona o comunidad$ (ec(o con orden y
precisi2n.
:ecnolog7a
Con5unto de conocimientos t!cnicos$ ordenados cient73camente$
que permiten diseKar y crear 1ienes y servicios que &acilitan la
adaptaci2n al medio am1iente y satis&acer tanto las
necesidades esenciales como los deseos de las personas.
SIERI .gina -1
Universidad de San Martn de Porres Facultad de Ingeniera y Arquitectura, 2014
C"PIT#$O III: %ETO!O$O+"
3.1 'ateriales
(.'.' :umanos:
.ara este proyecto necesitaremos tra1a5ar con el siguiente
personal>
- .cNs de procesador Intel Core - )uo con ,61 de Ram y
-00 61 de disco duro
.ara levantar el servicio se necesitara un servidor
Empresaria IAM O,*00 M, el cual ya posee la &acultad.
Aase de )atos>
SI Server -00< (Cantidad P 1)
.lata&ormas>
@indoCs Server -00< (Cantidad P 1)
@indoCs ; pro&esional Sp1 (Cantidad P -)
engua5e de .rogramaci2n>
.B.
Berramienta de programaci2n
Qote.adRR
Servidor @e1
O/M..
(.'.- E8ui.os ; Soft<are:
5e *esitar) un lu&ar en donde se pueda traba1ar as como equipos# los cuales se
detallan a continuacin<
SIERI .gina --
Universidad de San Martn de Porres Facultad de Ingeniera y Arquitectura, 2014
3.2 '&todos ( )*P +)ational *nifed Process,
Es un proceso de desarrollo de so&tCare y 5unto con el engua5e
'ni3cado de Modelado 'M$ constituye la metodolog7a estndar ms
utili"ada para el anlisis$ implementaci2n y documentaci2n de
sistemas orientados a o15etos.
El R'. no es un sistema con pasos 3rmemente esta1lecidos$ sino un
con5unto de metodolog7as adapta1les al conteLto y necesidades de
cada organi"aci2n.
.ara poder usar R'. antes (ay que adaptarlo a las caracter7sticas de
la empresa$ y medir de manera eLacta el tiempo$ costos y todos los
dems recursos involucrados en el proceso.
(.-.' Caracter/sticas esencia,es
R'. tiene tres caracter7sticas esenciales> est dirigido por los Casos
de 'so$ est centrado en la arquitectura$ y es iterativo e incremental.
Proceso dirigido .or Casos de #so
os Casos de 'so son una t!cnica de captura de requisitos que &uer"a
a pensaren t!rminos de importancia para el usuario y no solo en
terminos de &unciones que seria 1ueno contemplar. Se de3ne un Caso
de 'so como un &ragmento de &uncionalidad del sistema que
proporciona al usuario un valor aKadido. os Casos de 'so
representan los requisitos &uncionales del sistema. En R'. los Casos
de 'so no son solo una (erramienta para especi3car los requisitos del
sistema. :am1i!n gu7an su diseKo$ implementaci2n y prue1a. os
Casos de 'so constituyen un elemento integrador y una guia del
tra1a5o. os Casos de 'so no solo inician el proceso de desarrollo sino
que proporcionan un (ilo conductor$ permitiendo esta1lecer
tra"a1ilidad entre los arte&actos que son generados en las di&erentes
actividades del proceso de desarrollo.
Proceso centrado en ,a ar8uitectura
a arquitectura de un sistema es la organi"aci2n o estructura de sus
partes ms relevantes$ lo que permite tener una vision comFn entre
todos los involucraDdos (desarrolladores y usuarios) y una perspectiva
clara del sistema completo$ necesaria para controlar el desarrollo.
SIERI .gina -,
Universidad de San Martn de Porres Facultad de Ingeniera y Arquitectura, 2014
Iterati*o e Incrementa,
a arquitectura se va completando en sucesivos pasos que le aKaden
algo de &uncionalidad (asta la conclusi2n del desarrollo$ cuando la
arquitectura se (aya convertido en el sistema en s7.
(.-.- Fases
R'. se divide en 4 fases ; = disci.,inas$ dentro de las cuales se
reali"an varias iteraciones segFn el proyecto y en las que se (ace
mayor o menos es&uer"o en las distintas actividades.
En las iteraciones de cada &ase se (acen di&erentes es&uer"os en
di&erentes actividades>
Inicio (Inspecci2n y Concepci2n)
Se (ace un plan de &ases$ donde se identi3can los principales casos
de uso y se identi3can los riesgos. Se concreta la idea$ la visi2n del
producto$ como se enmarca en el negocio$ el alcance del proyecto.
E,aboracin>
Se reali"a el plan de proyecto$ donde se completan los casos de uso y
se mitigan los riesgos. .lani3car las actividades necesarias y los
recursos requeridos$ especi3cando las caracter7sticas y el diseKo de la
arquitectura.
SIERI .gina -*
Universidad de San Martn de Porres Facultad de Ingeniera y Arquitectura, 2014
Construccin:
Se 1asa en la ela1oraci2n de un producto totalmente operativo y en la
ela1oraci2n del manual de usuario. Construir el producto$ la
arquitectura y los planes$ (asta que el producto est listo para ser
enviado a la comunidad de usuarios.
Transicin:
Se reali"a la instalaci2n del producto en el cliente y se procede al
entrenamiento de los usuarios. Reali"ar la transici2n del producto a
los usuarios$ lo cual incluye> manu&actura$ env7o$ entrenamiento$
soporte y mantenimiento del producto$ (asta que el cliente quede
satis&ec(o$ por tanto en esta &ase suelen ocurrir cam1ios.
(.-.( !escri.cin de ,as Fases:
)ependiendo de la iteraci2n del proceso el equipo de desarrollo
puede reali"ar di&erentes tipos de actividades. #eamos de qu! trata
cada &ase.

Fase de Inicio:
)urante la &ase de inicio las iteraciones (acen poner mayor !n&asis en
acti*idades mode,ado de, negocio ; de re8uisitos.
En esta &ase se reali"an los siguientes pasos>
'n documento con la visi2n del proyecto.
El modelo de Casos de 'so con una lista de todos los Casos de
'so y los actores que puedan ser identi3cados.
'n glosario inicial del proyecto.
'n Caso de 'so inicial de Qegocio el cual incluye> conteLto del
negocio$ criterios de !Lito y plani3caci2n 3nanciera.
'n estudio inicial de riesgos.
'n plan del proyecto que muestre las &ases y las iteraciones.
El o15etivo de esta &ase$ y el esta1lecer el mode,o de negocio es
entender las &unciones de la organi"aci2n del cliente$ tanto en
estructura como en sus procesos. Su o15etivo es modelar &unciones y
roles que reali"a la organi"aci2n para reali"ar ms &cilmente la
reingenier7a de procesos o la implantaci2n del nuevo sistema.
:am1i!n se descri1e los re8uisitos$ lo que el sistema tendr7a que
reali"ar y permitir que los desarrolladores y el cliente est!n de
acuerdo con esta descripci2n.
.ara ello se reali"arn las siguientes su1&ases>
SIERI .gina -+
Universidad de San Martn de Porres Facultad de Ingeniera y Arquitectura, 2014
)escri1ir los requerimientos &uncionales y no &uncionales
(rendimiento esperado$ plata&ormas soportadas$ integraci2n con
sistemas eLternos$ etc.).
Capturar un glosario o voca1ulario del sistema o proyecto
(mediante documento y clases conceptuales).
Encontrar actores y casos de uso.
)escri1ir los casos de uso mediante su Vu5o principal$
variaciones y eLcepciones.
/signar prioridades a los casos de uso encontrados para poder
plani3car la iteraci2n en &orma de anlisis$ diseKo e
implementaci2n.
Modelar la inter&a" de usuario (diseKo l2gico).
.rototipo de la inter&a" de usuario (diseKo &7sico).

Fase de E,aboracin:
En esta &ase las iteraciones se orientan al desarrollo de la
arquitectura$ que incluye los Vu5os de tra1a5o de requerimientos
modelo de negocios (re3namiento)$ an>,isis? dise@o ; una .arte
de im.,ementacin orientado a ,a ar8uitectura.
En esta &ase se reali"an las siguientes su1&ases>
'n modelo de Casos de 'so con todos los actores identi3cados
y la mayor parte de las descripciones de Casos de 'so.
Requerimientos adicionales> no &uncionales o
pseudorequerimientos.
)escripci2n de la arquitectura del so&tCare.
.rototipo e5ecuta1le de arquitectura.
'na lista revisada de riesgos.
.lan del proyecto$ incluyendo iteraciones y criterios de
evaluaci2n para cada iteraci2n.
Manual preliminar de usuario.
En esta &ase se especi3can los requerimientos y se descri1en so1re
c2mo se van a implementar en el sistema> trans&ormar los requisitos
al diseKo del sistema$ desarrollar una arquitectura para el sistema$ y
adaptar el diseKo para que sea consistente con el entorno de
implementaci2n
Fase de Construccin:
Se im.,ementan las clases y o15etos en 3c(eros &uente$ 1inarios$
e5ecuta1les y dems. El resultado 3nal es un sistema e5ecuta1le.
.ara ello se reali"arn las siguientes su1&ases>
SIERI .gina -9
Universidad de San Martn de Porres Facultad de Ingeniera y Arquitectura, 2014
El producto de so&tCare integrado so1re la plata&orma
adecuada.
os manuales de usuario.
'na descripci2n de la versi2n actual.
.lani3car qu! su1sistemas de1en ser implementados y en qu!
orden de1en ser integrados$ &ormando el .lan de Integraci2n.
Cada implementador decide en qu! orden implementa los
elementos del su1sistema.
Si encuentra errores de diseKo$ los noti3ca.
Se integra el sistema siguiendo el plan.
En la parte de Pruebas se evalFa la calidad del producto$ pero no
para aceptar o rec(a"ar el producto al 3nal del proceso de desarrollo$
sino que de1e ir integrado en todo el ciclo de vida. Se de1en
encontrar y documentar de&ectos en la calidad del so&tCare.
6eneralmente asesora so1re la calidad del so&tCare perci1ida$ provee
la validaci2n de los supuestos reali"ados en el diseKo y especi3caci2n
de requisitos por medio de demostraciones concretas$ veri3car las
&unciones del producto de so&tCare segFn lo diseKado y que los
requisitos tengan su apropiada implementaci2n.
En la parte de des.,iegue se produce con !Lito distri1uciones del
producto y distri1uirlo a los usuarios. as actividades implicadas
incluyen>
.ro1ar el producto en su entorno de e5ecuci2n 3nal.
Empaquetar el so&tCare para su distri1uci2n.
)istri1uir el so&tCare.
Instalar el so&tCare.
.roveer asistencia y ayuda a los usuarios.
Eormar a los usuarios y al cuerpo de ventas.
Migrar el so&tCare eListente o convertir 1ases de datos.
)urante todo el proyecto se e5ecutan las &ases de gestin de,
.ro;ecto$ donde se vigila el cumplimiento de los o15etivos$ gesti2n
de riesgos y restricciones para desarrollar un producto que sea acorde
a los requisitos de los clientes y los usuarios. En la cual se reali"an las
tareas>
.roveer un marco de tra1a5o para la gesti2n de proyectos de
so&tCare intensivos.
.roveer gu7as prcticas reali"ar planeaci2n$ contratar personal$
e5ecutar y monitorear el proyecto.
.roveer un marco de tra1a5o para gestionar riesgos.
SIERI .gina -;
Universidad de San Martn de Porres Facultad de Ingeniera y Arquitectura, 2014
En la &ase de con0guracin ; contro, de cambios$ permite
mantener la integridad de todos que se crean en el proceso$ as7 como
de mantener in&ormaci2n del proceso evolutivo que (an seguido.
En la &ase del So.orte9Entorno$ la 3nalidad es dar soporte al
proyecto con las adecuadas (erramientas$ procesos y m!todos.
Arinda una especi3caci2n de las (erramientas que se van a necesitar
en cada momento$ as7 como de3nir la instancia concreta del proceso
que se va a seguir.
En concreto las responsa1ilidades de este Vu5o de tra1a5o incluyen>
Selecci2n y adquisici2n de (erramientas
Esta1lecer y con3gurar las (erramientas para que se a5usten a
la organi"aci2n.
Con3guraci2n del proceso.
Me5ora del proceso.
Servicios t!cnicos.
Transicin
a 3nalidad de la &ase de transici2n es poner el producto en manos de
los usuarios 3nales$ para lo que se requiere desarrollar nuevas
versiones actuali"adas del producto$ completar la documentaci2n$
entrenar al usuario en el mane5o del proDducto$ y en general tareas
relacionadas con el a5uste$ con3guracion$ instalaci2n &acilidad de uso
del producto. os o15etivos en esta &ase son>
Conseguir que el usuario se valga por si mismo.
'n producto 3nal que cumpla los requisitos esperados$ que
&uncione y satis&aga su3cientemente al usuario. os resultados
de1en ser>
.rototipo 4peracional
)ocumentos egales
Caso del Qegocio Completo
7nea de Aase del .roducto completa y corregida que incluye
todos los modelos del sistema
)escripci2n de la /rquitectura completa y corregida
as iteraciones de esta &ase irn dirigidas normalmente a
conseguir una nueva versi2n.
(.-.4 2enta)as ; !es*enta)as
#enta5as
Evaluaci2n en cada &ase que permite cam1ios de o15etivos
Eunciona 1ien en proyectos de innovaci2n.
Es sencillo$ ya que sigue los pasos intuitivos necesarios a la
(ora de desarrollar el so&tCare.
Seguimiento detallado en cada una de las &ases.
SIERI .gina -<
Universidad de San Martn de Porres Facultad de Ingeniera y Arquitectura, 2014
)esventa5as
a evaluaci2n de riesgos es comple5a
ELcesiva VeLi1ilidad para algunos proyectos
Estamos poniendo a nuestro cliente en una situaci2n que puede
ser muy inc2moda para !l.
Questro cliente de1er ser capa" de descri1ir y entender a un
gran nivel de detalle para poder acordar un alcance del
proyecto con !l.
SIERI .gina -=