documento tesis v1
TRANSCRIPT
-
7/30/2019 Documento Tesis v1
1/81
1
UNIVERSIDAD RICARDO PALMA
FACULTAD DE INGENIERA
ESCUELA PROFESIONAL DE INGENIERA INFORMTICA
WORKFLOW PARA ONG EN EL PER PARA LA GESTIN DE
ABASTECIMIENTO
PROYECTO DE TITULACIN POR EXPERIENCIA PROFESIONAL
PARA OPTAR EL TTULO PROFESIONAL DE INGENIERO
INFORMTICO
PRESENTADO POR
DIEGO ALONSO RAMOS LA TORRE
LIMAPER
2013
-
7/30/2019 Documento Tesis v1
2/81
2
Dedicatoria
Mi tesis la dedico principalmente a mis padres que me dieron la vida y han estado
conmigo en todo momento. Gracias por todo pap y mam por darme una carrera
para mi futuro y por creer en m, aunque hemos pasado momentos difciles
siempre han estado apoyndome y brindndome todo su amor, por todo esto les
agradezco de todo corazn el que estn siempre ah.
-
7/30/2019 Documento Tesis v1
3/81
3
Resumen
Las ONGs (Organizacin No Gubernamental) en el Per, en la actualidad cuentan
con sistemas informticos de administracin de procesos muy simples que solo
sirven para tener un registro de alguno de los procesos que ellas realizan. Dentro
de estos procesos se encuentra el de Gestin de Abastecimiento, en el que estn
involucradas varias reas de la ONG. Este proceso al ser realizado consume
tiempo innecesario (envo fsico de la documentacin a travs de las reas) y
gastos innecesarios en materiales de oficina (papel bond, papel carbn, tinta para
impresora) que son excesivos y que se podran eliminar o reducir.
El Presente estudio busca desarrollar una herramienta tecnolgica que facilite yautomatice el trabajo que realiza el personal relacionado con el proceso de
Gestin de Abastecimiento, as como el ahorro en compra de materiales de oficina
y tiempo de ejecucin del proceso. Se presentarn las principales caractersticas,
ventajas y aportes de la implantacin de la herramienta tecnologa en las
organizaciones, y como esta herramienta facilita a los usuarios su trabajo y a la
vez como agiliza el proceso de Gestin de Abastecimiento dando a la organizacin
un mejor uso de sus recursos materiales y humanos para un ptimo
funcionamiento.
El estudio ha sido realizado principalmente en 7 captulos: Marco Terico, Estado
del Arte, Viabilidad, Planteamiento del Problema y Objetivos, Solucin,
Implementacin y conclusiones las cuales son desarrolladas en el proyecto de
forma desagregada aplicando los conocimientos y practicas adquiridas durante la
carrera universitaria; finalmente se ha aadido las influencias bibliogrfica y los
anexos.
As mismo se ha credo conveniente anotar en este resumen las palabras claves
siguientes: Sistema de Informacin, Gestin de Abastecimiento, Automatizacin
de Procesos, Administrador de Flujo de Trabajo.
-
7/30/2019 Documento Tesis v1
4/81
4
ndice de Contenido
1. Marco Terico ............................................................................................................. 81.1. Glosario de Trminos ........................................................................................ 8
1.1.1. Baseline.......................................................................................................... 81.1.2. Requerimiento Compra .............................................................................. 81.1.3. Requerimiento de Servicio........................................................................ 81.1.4. Memorando ................................................................................................... 81.1.5. Orden de Compra ........................................................................................ 81.1.6. Orden de Servicio ........................................................................................ 81.1.7. Factura............................................................................................................ 91.1.8. Norma Jurdica ............................................................................................. 91.1.9. Decreto Supremo......................................................................................... 91.1.10. Ley................................................................................................................ 91.1.11. Sistema ....................................................................................................... 91.1.12. Emcriptar.................................................................................................... 91.1.13. Desemcriptar........................................................................................... 10
1.2. Introduccin a la Tecnologa ......................................................................... 101.2.1. Qu es WorkFlow?.................................................................................. 101.2.2. Qu es un Sistema WorkFlow? ........................................................... 101.2.3. Cules son los beneficios de un sistema WorkFlow? .................. 101.2.4. Tipos de WorkFlow ................................................................................... 111.2.5. Por qu Automatizar? ............................................................................ 111.2.6. Qu es HTTPS?........................................................................................ 12
1.3. Organizacin Receptora del Sistema no gubernamental ...................... 151.3.1. Nombre ......................................................................................................... 151.3.2. Introduccin ................................................................................................ 151.3.3.
Organigrama ............................................................................................... 16
1.3.4. Areas Involucradas ................................................................................... 16
1.4. Estrategias Metodolgicas............................................................................. 171.4.1. Observacin ................................................................................................ 171.4.2. Entrevista..................................................................................................... 181.4.3. Encuesta ...................................................................................................... 18
-
7/30/2019 Documento Tesis v1
5/81
5
1.4.4. Rational Unified Process (RUP) ............................................................. 201.4.5. Lenguaje UML ............................................................................................. 26
2. Estado del Arte ......................................................................................................... 262.1. Estudio................................................................................................................. 26
2.1.1. Algoritmos de Cifrado .............................................................................. 262.1.2. Metodologas para desarrollar software ............................................. 32
3. Viabilidad ................................................................................................................... 373.1. Viabilidad Econmica ...................................................................................... 383.2. Viabilidad Tcnica............................................................................................. 403.3. Viabilidad Poltica ............................................................................................. 40
4. Planteamiento del Problema................................................................................. 454.1. Antecedentes ..................................................................................................... 464.2. Formulacin del Problema ............................................................................. 464.3. Justificacin ....................................................................................................... 474.4. Objetivo General ............................................................................................... 47
4.4.1. Objetivos Especficos............................................................................... 475. Solucin ..................................................................................................................... 48
5.1. Requerimientos ................................................................................................. 485.1.1. Requerimientos Funcionales ................................................................. 485.1.2. Requerimientos No Funcionales ........................................................... 51
5.2. Estndares de Desarrollo ............................................................................... 535.2.1. Documentacin .......................................................................................... 535.2.2. Formato de Diseo .................................................................................... 545.2.3. Formato de Programacin ...................................................................... 555.2.4. Formato de Base de Datos...................................................................... 565.2.5. Formato de Anlisis .................................................................................. 575.2.6. Formatos de Interfaz ................................................................................. 58
5.3. Alcance ................................................................................................................ 615.4.
Modelado del Sistema ..................................................................................... 63
5.4.1. Diagrama de Actores del Sistema ......................................................... 635.4.2. Diagrama de Paquetes del Sistema ...................................................... 635.4.3. Diagrama de Casos de Uso del Sistema ............................................ 64
5.5. Diagrama Fsico de la Base de Datos.......................................................... 685.5.1. Modulo Seguridad, Administracin de Usuarios y Auditoria ........ 68
-
7/30/2019 Documento Tesis v1
6/81
6
5.5.2. Modulo Compras ....................................................................................... 695.5.3. Modulo Almacn ........................................................................................ 69
5.6. Arquitectura........................................................................................................ 705.6.1. Capa de Presentacin .............................................................................. 705.6.2. Capa de Negocio........................................................................................ 705.6.3. Capa de Datos ............................................................................................ 71
5.7. Soporte Tcnico ................................................................................................ 715.7.1. ASP.NET....................................................................................................... 715.7.2. Base de Datos............................................................................................. 735.7.3. Servidor de Aplicaciones ........................................................................ 745.7.4. Servidor de Base de Datos ..................................................................... 74
6. Implementacin........................................................................................................ 757. Conclusiones ............................................................................................................ 778. Referencias Bibliogrficas .................................................................................... 799. Anexo .......................................................................................................................... 81
-
7/30/2019 Documento Tesis v1
7/81
7
Indice de Figuras
1. Los Casos de Uso integran el trabajo..202. Trazabilidad a partir de los Casos de Uso.. 213. Evolucin de la arquitectura del sistema 224.
Una iteracin RUP
.
245. Esfuerzo en actividades segn fase del proyecto.25
-
7/30/2019 Documento Tesis v1
8/81
8
1. Marco Terico
En este captulo se ha tratado de resumir los principales aspectos del diseo
metodolgico del sistema, inclusive se ha insertado un glosario de trminos para
que haga ms fcil la comprensin del lector. Dentro de los aspectos ms
importantes podemos sealar introduccin a la tecnologa usada en el sistema;
introduccin a la organizacin que tiene que ver con la estructura organizativa de
la empresa y a donde apunta la mejora; estrategia metodolgica que tiene que ver
con la modalidades o polticas de la investigacin para la investigacin de la
informacin.
1.1. Glosario de Trminos
1.1.1. Baseline
Es una instantnea del estado de todos los artefactos del proyecto, registrada para
efectos de gestin de configuracin y control de cambios.
1.1.2. Requerimiento Compra
Es una necesidad que tiene un proyecto para la compra de materiales.
1.1.3. Requerimiento de Servicio
Es una necesidad que tiene un proyecto para contratar servicios.
1.1.4. Memorando
Documento por el cual se solicita el Requerimiento de Compra o Servicio.
1.1.5. Orden de Compra
Documento por el cual se acepta y ordena el Requerimiento de Compra.
1.1.6. Orden de Servicio
Documento por el cual se acepta y ordena el Requerimiento de Compra.
-
7/30/2019 Documento Tesis v1
9/81
9
1.1.7. Factura
Documento o recibo entregado por el vendedor al comprador como prueba de que
ste ha adquirido una mercanca o servicio determinado a un precio dado.
Representa un derecho de cobro a favor del vendedor. En la factura se especifican
los datos de ambos incluyendo los respectivos RUC, las caractersticas de los
productos y/o servicios, as como la fecha, el precio de compra y el impuesto
general a las ventas.
1.1.8. Norma Jurdica
Es una regla u ordenacin del comportamiento humano dictado por la autoridad
competente del caso, con un criterio de valor y cuyo incumplimiento trae aparejado
impone deberes y confiere derechos.
1.1.9. Decreto Supremo
Es un tipo de acto administrativo emanado habitualmente del poder ejecutivo y
que, generalmente, posee un contenido normativo reglamentario, por lo que su
rango es jerrquicamente inferior a las leyes.
1.1.10. Ley
Es una norma jurdica dictada por el legislador. Es decir, un precepto establecido
por la autoridad competente, en que se manda o prohbe algo en consonancia con
la justicia, y para el bien de los gobernados. Su incumplimiento trae aparejada una
sancin.
1.1.11. Sistema
Conjunto de elementos mutuamente relacionados que interactan. Incluye
entradas, procesos y resultados.
1.1.12. Emcriptar
Es la codificacin de los datos por razones de seguridad.
http://es.wikipedia.org/wiki/Derecho_subjetivohttp://es.wikipedia.org/wiki/Derecho_subjetivo -
7/30/2019 Documento Tesis v1
10/81
10
1.1.13. Desemcriptar
Es la decodificacin de los datos por razones de seguridad.
1.2. Introduccin a la Tecnologa
A continuacin se dar una introduccin a la tecnologa usada en el desarrollo de
la tesis, por ser la ms apropiada para tales efectos.
1.2.1. Qu es WorkFlow?
Es el estudio de los aspectos operacionales de una actividad de trabajo que
responde a las siguientes preguntas: cmo se estructuran las tareas?, cmo se
realizan?, cul es su orden correlativo?, cmo se sincronizan?, cmo fluye la
informacin que soporta las tareas? y cmo se le hace seguimiento alcumplimiento de las tareas?
1.2.2. Qu es un Sistema WorkFlow?
Es un sistema informtico que organiza y controla las tareas, los recursos y las
reglas, necesarias para completar el proceso de negocio.
1.2.3. Cules son los beneficios de un sistema WorkFlow?
La implantacin de un sistema de WorkFlow aporta numerosos beneficios
dependiendo de los procesos de negocio involucrados:
Ahorro de tiempo y mejora de la productividad.
Mejora del control de procesos.
Mejor atencin y servicio al usuario.
Establecimiento de mecanismos de continua mejora en los procesos.
Optimizacin de la circulacin de informacin interna y externa.
Integracin total de los procesos.
-
7/30/2019 Documento Tesis v1
11/81
11
1.2.4. Tipos de WorkFlow
Workflow se define tpicamente en tres amplias categoras que van desde las ms
complejas y estructuradas hasta los que usan E-Mail (correo electrnico), as
tenemos:
Workflow de Produccin:
El Workflow orientado a produccin o transacciones, es usado en
aplicaciones tradicionales gobernadas por una serie de normas y
procedimientos. Requieren personal para realizar tareas repetitivas en las
cuales los documentos pueden requerir ser accedidos por pedido (das,
meses o an aos despus). Adems, se requieren reglas para crear y
mantener un registro de auditora de cada documento. Ejemplos de este
tipo incluyen lneas de crdito, reclamos, etc. Workflow AD-HOC:
El workflow orientado a proyectos o AD-HOC incluye un indefinido grupo de
personas con fechas especficas para realizar tareas. Este tipo de workflow
implica una gran cantidad de tiempo para su coordinacin. Es tpicamente
de corta vida y desestructurado, variando mucho en su complejidad.
Ejemplos de este tipo son: desarrollo de planes estratgicos, diseo de
productos, evaluacin de un producto, etc. Workflow Administrativo:
Esta categora incluye tareas de rutina simples usando correo electrnico.
El intercambio de informacin tiene lugar en forma electrnica.
1.2.5. Por qu Automatizar?
Un vistazo a las razones para invertir en la automatizacin de procesos de negocio
o administrativos: Reduccin de costos, incremento de eficiencia, menores
oportunidades de errar, mejor control, calidad en beneficio de todos.
Por ser inherentes a la administracin de toda organizacin, los procesos se
consideran como si tuvieran "costo cero". Nada ms alejado de la realidad. Cuesta
el papel, el tiempo, el espacio, la administracin logstica y la oportunidad que sus
-
7/30/2019 Documento Tesis v1
12/81
12
colaboradores estratgicos se dediquen a mejores maneras de lograr sus
objetivos.
Las empresas que han automatizado sus procesos administrativos han
descubierto nuevas fuentes de ahorro y oportunidades de mejorar la calidad de su
gestin y la satisfaccin de las expectativas de calidad de sus clientes, gracias a
que han logrado:
Disminuir costos asociados al papel, produccin, almacenamiento y
transporte de formas, formularios y documentos.
Reducir el tiempo de procesamiento, ahorrando en horas hombre y
obteniendo resultados en menor tiempo. Disminuir las posibilidades de incumplimiento, error y fallas por prdida o
desaparicin de papeles.
Mejor la calidad y oportunidad de la informacin necesaria para la
realizacin de actividades fundamentales del negocio.
Permitir a la gerencia concentrase en lo que es realmente productivo para
la organizacin.
1.2.6. Qu es HTTPS?
HTTPS es la versin segura del protocolo HTTP. El sistema HTTPS utiliza un
cifrado basado en las Secure Socket Layers (SSL) para crear un canal cifrado
(cuyo nivel de cifrado depende del servidor remoto y del navegador utilizado por el
cliente) ms apropiado para el trfico de informacin sensible que el protocolo
HTTP.
El nivel de cifrado depende del navegador usado y del servidor remoto. Es
utilizado especialmente por sistemas que manejan dinero, transacciones
comerciales, datos personales o contraseas.
-
7/30/2019 Documento Tesis v1
13/81
13
1.2.6.1. Qu es SSL?
El SSL (Secure Socket Layer) es un protocolo de seguridad desarrollado por la
empresa Netscape Communications para lograr que la transmisin de datos a
travs de internet entre un servidor y un usuario, o viceversa, sea completamente
segura. El SSL es un protocolo abierto, por lo que puede ser empleado por
cualquier fabricante de aplicaciones para Internet, siendo una de sus grandes
ventajas el hecho de que se pueda utilizar con cualquiera de los servicios de
Internet (WWW, FTP, noticias, correo), aunque lo ms normal es que se utilice
para el trfico a travs de la WWW. El protocolo se basa en la utilizacin de un
sistema de cifrado que emplea algoritmos matemticos y un sistema de claves
que solamente conocen el usuario y el servidor. Estas claves permiten la
encriptacin de los datos para que nadie que no las tenga pueda leer sucontenido.
Esto significa que cualquier tipo de informacin que se transmita desde un
servidor seguro que utiliza un navegador con tecnologa SSL, viajar a travs de
Internet a salvo de miradas indiscretas.
Para utilizar el protocolo SSL es necesario que el servidor de Internet con soporte
SSL se encuentre en posesin del certificado digital de seguridad correspondiente
(otorgado por una agencia independiente debidamente autorizada, por ejemplo
Verisign o Thawte), y por parte del usuario, es preciso disponer de un visualizador
WWW que soporte el protocolo SSL (tanto Firefox como Internet Explorer lo
tienen).
El sistema de seguridad SSL se basa en el algoritmo (Clave pblica / Clave
privada) de la RSA (Rivest, Shamir y Adleman), que utiliza una clave de seguridad
de 40 128 bits de longitud. Esto implica que para romper esta clave y acceder a
la informacin que protege, sera necesario utilizar un ordenador personal durante
todo varios aos. El aumento en la potencia de clculo de los ordenadores
-
7/30/2019 Documento Tesis v1
14/81
14
personales reduce progresivamente el tiempo necesario para romper las claves de
cifrado, lo que se salva a su vez con el aumento en el nmero de bits utilizados.
Cuando se conecta a un servidor seguro (https://www...), los navegadores avisan
de esta circunstancia mediante un candado de color amarillo en la parte inferior y
adems permiten comprobar la informacin contenida en el certificado digital que
lo habilita como servidor seguro. SSL permite recoger en un entorno seguro datos
tales como, informacin de tarjetas de crdito, etc., puesto que la informacin
enviada a travs de un formulario seguro es transmitida al servidor de forma
emcriptada.
1.2.6.2. Qu es un Certificado SSL?
Un Certificado SSL se usa para asegurarle al visitante de una pgina/portal Web lo
siguiente: la autenticidad del servidor; el cifrado (encriptacin) de sus datos; y una
prueba de integridad en la comunicacin. As con un certificado SSL vlido, las
comunicaciones a travs de Internet se transmiten de forma cifrada (emcriptada).
Asimismo se puede confiar que la informacin que se enva ser recibida
privadamente y sin alteracin al servidor con el que se establece la conexin.
Los certificados digitales son una forma de agregar un tercer "rbitro" a la cadenade confianza de la comunicacin por SSL. Lo que un certificado digital hace es
agregar el "endoso" de un tercero que garantiza la integridad, y existencia de la
organizacin que enva los datos. Esto significa que una autoridad certificadora
avala que la empresa que es duea del sitio Web, por ejemplo, realmente existe.
El protocolo de seguridad SSL (Secure Sockets Layer) es la tecnologa de
seguridad estndar para emcriptar las comunicaciones entre el usuario de un
navegador y los servidores Web. SSL garantiza una transmisin de datosconfidencial y segura entre el navegador y el servidor web, manteniendo cualquier
dato a salvo de ser interceptado por terceras personas.
-
7/30/2019 Documento Tesis v1
15/81
15
1.3. Organizacin Receptora del Sistema no gubernamental
A continuacin se describe de forma sintetizada la organizacin en la que se va a
implementar el desarrollo de esta tesis.
1.3.1. Nombre
CEDRO - Centro de Informacin y Educacin para la Prevencin del Abuso de
Drogas
1.3.2. Introduccin
CEDRO es una organizacin peruana privada sin fines de lucro, nace en 1986
gracias a una iniciativa de peruanos y peruanas de diversas profesiones y
quehaceres. Desde su inicio la institucin es innovadora, ya que su actuacin nose circunscribe a la prevencin del uso de sustancias psicoactivas, si no que tiene
como objetivo fundamental crear conciencia sobre la cadena produccin-trfico-
consumo, a travs de estrategias directas y de comunicacin masiva.
Esta institucin mantiene un intercambio fluido a nivel nacional e internacional, con
varios actores y agentes de pases y entidades, lo que a su vez potencia las
acciones y polticas en el campo de las drogas, dentro de un panorama de respeto
a los derechos humanos, a la ecologa y a la libertad individual, sin perder de vista
un mundo globalizado e interdependiente. Ello permite que CEDRO fomente, entre
las diversas poblaciones, un liderazgo democrtico que mantiene un dilogo
permanente y a la vez renovado.
-
7/30/2019 Documento Tesis v1
16/81
16
1.3.3. Organigrama
1.3.4. Areas Involucradas
Aqu se describen las reas que estn encargadas del Proceso de Abastecimiento
de la organizacin.
1.3.4.1. Unidad Financiera
Esta rea est dividida en sub-reas las cuales son:
PROYECTO es la que hace la solicitud del requerimiento.
CONTABILIDAD, es la encargada de validar los documentos generados por
el proceso.
LOGISTICA, es la encargada de capturar los pedidos de requerimientos delos Proyectos y tramitar su compra (Cotizaciones y rdenes de Compra).
1.3.4.2. Centro de Computo
rea encargada de registrar y auditar el desarrollo del Sistema desde el inicio
hasta el final.
-
7/30/2019 Documento Tesis v1
17/81
17
1.4. Estrategias Metodolgicas
Aqu se describen las estrategias metodolgicas que se usaron para la recoleccin
de informacin.
1.4.1. Observacin
Es una tcnica que consiste en observar atentamente el fenmeno, hecho o caso,
tomar informacin y registrarla para su posterior anlisis.
La observacin es un elemento fundamental de todo proceso investigativo; en ella
se apoya el investigador para obtener el mayor numero de datos. Gran parte del
acervo de conocimientos que constituye la ciencia ha sido lograda mediante la
observacin.
Existen dos clases de observacin: la Observacin no cientfica y la observacincientfica. La diferencia bsica entre una y otra est en la intencionalidad: observar
cientficamente significa observar con un objetivo claro, definido y preciso: el
investigador sabe qu es lo que desea observar y para qu quiere hacerlo, lo cual
implica que debe preparar cuidadosamente la observacin. Observar no
cientficamente significa observar sin intencin, sin objetivo definido y por tanto, sin
preparacin previa.
Pasos que debe tener la observacin:
1. Determinar el objeto, situacin, caso, etc. (que se va a observar)
2. Determinar los objetivos de la observacin (para qu se va a observar)
3. Determinar la forma con que se van a registrar los datos
4. Observar cuidadosa y crticamente
5. Registrar los datos observados
6. Analizar e interpretar los datos
7. Elaborar conclusiones
8. Elaborar el informe de observacin (este paso puede omitirse si en la
investigacin se emplean tambin otras tcnicas, en cuyo caso el informe
incluye los resultados obtenidos en todo el proceso investigativo)
-
7/30/2019 Documento Tesis v1
18/81
18
1.4.2. Entrevista
Es una tcnica para obtener datos que consisten en un dilogo entre dos
personas: El entrevistador "investigador" y el entrevistado; se realiza con el fin de
obtener informacin de parte de este, que es, por lo general, una persona
entendida en la materia de la investigacin.
La entrevista es una tcnica antigua, pues ha sido utilizada desde hace mucho en
psicologa y, desde su notable desarrollo, en sociologa y en educacin. De hecho,
en estas ciencias, la entrevista constituye una tcnica indispensable porque
permite obtener datos que de otro modo seran muy difciles conseguir.
Empleo de lLa entrevista:
Cuando se considera necesario, que exista interaccin y dilogo entre el
investigador y la persona.
Cuando la poblacin o universo es pequeo y manejable.
Condiciones que debe reunir el entrevistador:
Debe demostrar seguridad en s mismo.
Debe ponerse a nivel del entrevistado; esto puede esto puede conseguirse
con una buena preparacin previa del entrevistado en el tema que va a
tratar con el entrevistado.
Debe ser sensible para captar los problemas que pudieren suscitarse.
Comprender los intereses del entrevistado.
Debe despojarse de prejuicios y, en lo posible de cualquier influencia
emptica.
1.4.3. Encuesta
La encuesta es una tcnica destinada a obtener datos de varias personas cuyas
opiniones impersonales interesan al investigador. Para ello, a diferencia de la
entrevista, se utiliza un listado de preguntas escritas que se entregan a los sujetos,
a fin de que las contesten igualmente por escrito. Ese listado se denomina
-
7/30/2019 Documento Tesis v1
19/81
19
cuestionario.
Es impersonal porque el cuestionario no lleva el nombre ni otra identificacin de la
persona que lo responde, ya que no interesan esos datos.
Es una tcnica que se puede aplicar a sectores ms amplios del universo, de
manera mucho ms econmica que mediante entrevistas.
Varios autores llaman cuestionario a la tcnica misma. Los mismos u otros, unen
en un mismo concepto a la entrevista y al cuestionario, denominndolo encuesta,
debido a que en los dos casos se trata de obtener datos de personas que tienen
alguna relacin con el problema que es materia de investigacin.
Tipos de preguntas que pueden plantearse:
El investigador debe seleccionar las preguntas ms convenientes, de acuerdo con
la naturaleza de la investigacin y, sobre todo, considerando el nivel de educacin
de las personas que se van a responder el cuestionario.
A. Clasificacin de acuerdo con su forma:
1. Preguntas abiertas
2. Preguntas cerradas
a. Preguntas dicotmicas
b. Preguntas de seleccin mltiple1. En abanico
2. De estimacin
B. Clasificacin de acuerdo con el fondo:
1. Preguntas de hecho
2. Preguntas de accin
3. Preguntas de intencin
4. Preguntas de opinin
5. Preguntas ndices o preguntas test
-
7/30/2019 Documento Tesis v1
20/81
20
1.4.4. Rational Unified Process (RUP)
Caractersticas Principales:
Los autores de RUP destacan que el proceso de software propuesto por RUP
tiene tres caractersticas esenciales: est dirigido por los Casos de Uso, est
centrado en la arquitectura, y es iterativo e incremental.
Proceso Dirigido Por Casos de Uso:
Los Casos de Uso son una tcnica de captura de requisitos, que exige fuerza a
pensar en trminos de importancia para el usuario y no slo en trminos de
funciones que es bueno contemplar. Se define un Caso de Uso como un
fragmento de funcionalidad del sistema que proporciona al usuario un valoraadido. Los Casos de Uso representan los requisitos funcionales del sistema.
En RUP los Casos de Uso no son slo una herramienta para especificar los
requisitos del sistema. Tambin guan su diseo, implementacin y prueba. Los
Casos de Uso constituyen un elemento integrador y una gua del trabajo como se
muestra en la figura 1.
Figura 1: Los Casos de Uso integran el trabajohttp://www.ibm.com/developerworks/rational/library/content/03July/1000/1251/1251_best
practices_TP026B.pdf
http://www.ibm.com/developerworks/rational/library/content/03July/1000/1251/1251_bestpractices_TP026B.pdfhttp://www.ibm.com/developerworks/rational/library/content/03July/1000/1251/1251_bestpractices_TP026B.pdfhttp://www.ibm.com/developerworks/rational/library/content/03July/1000/1251/1251_bestpractices_TP026B.pdfhttp://www.ibm.com/developerworks/rational/library/content/03July/1000/1251/1251_bestpractices_TP026B.pdfhttp://www.ibm.com/developerworks/rational/library/content/03July/1000/1251/1251_bestpractices_TP026B.pdf -
7/30/2019 Documento Tesis v1
21/81
21
Los Casos de Uso no slo inician el proceso de desarrollo sino que proporcionan
un hilo conductor, permitiendo establecer trazabilidad entre los artefactos que son
generados en las diferentes actividades del proceso de desarrollo.
Como se muestra en la Figura 2, basndose en los Casos de Uso se crean los
modelos de anlisis y diseo, luego la implementacin que los lleva a cabo, y se
verifica que efectivamente el producto implemente adecuadamente cada Caso de
Uso. Todos los modelos deben estar sincronizados con el modelo de Casos de
Uso.
Figura 2: Trazabilidad a partir de los Casos de Uso
http://www.ibm.com/developerworks/rational/library/content/03July/1000/1251/1251_best
practices_TP026B.pdf
Proceso Centrado en la Arquitectura:
La arquitectura de un sistema es la organizacin o estructura de sus partes ms
relevantes, lo que permite tener una visin comn entre todos los involucrados
(desarrolladores y usuarios) y una perspectiva clara del sistema completo,
necesaria para controlar el desarrollo.La arquitectura involucra los aspectos estticos y dinmicos ms significativos del
sistema, est relacionada con la toma de decisiones que indican cmo tiene que
ser construido el sistema y ayuda a determinar en qu orden. Adems la
definicin de la arquitectura debe tomar en consideracin elementos de calidad del
sistema, rendimiento, reutilizacin y capacidad de evolucin por lo que debe ser
http://www.ibm.com/developerworks/rational/library/content/03July/1000/1251/1251_bestpractices_TP026B.pdfhttp://www.ibm.com/developerworks/rational/library/content/03July/1000/1251/1251_bestpractices_TP026B.pdfhttp://www.ibm.com/developerworks/rational/library/content/03July/1000/1251/1251_bestpractices_TP026B.pdfhttp://www.ibm.com/developerworks/rational/library/content/03July/1000/1251/1251_bestpractices_TP026B.pdfhttp://www.ibm.com/developerworks/rational/library/content/03July/1000/1251/1251_bestpractices_TP026B.pdf -
7/30/2019 Documento Tesis v1
22/81
22
flexible durante todo el proceso de desarrollo. La arquitectura se ve influenciada
por la plataforma software, sistema operativo, gestor de bases de datos,
protocolos, consideraciones de desarrollo como sistemas heredados. Muchas de
estas restricciones constituyen requisitos no funcionales del sistema.
En el caso de RUP adems de utilizar los Casos de Uso para guiar el proceso se
presta especial atencin al establecimiento temprano de una buena arquitectura
que no se vea fuertemente impactada ante cambios posteriores durante la
construccin y el mantenimiento.
Cada producto tiene tanto una funcin como una forma. La funcin corresponde a
la funcionalidad reflejada en los Casos de Uso y la forma la proporciona la
arquitectura. Existe una interaccin entre los Casos de Uso y la arquitectura, losCasos de Uso deben encajar en la arquitectura cuando se llevan a cabo y la
arquitectura debe permitir el desarrollo de todos los Casos de Uso requeridos,
actualmente y en el futuro. Esto provoca que tanto arquitectura como Casos de
Uso deban evolucionar en paralelo durante todo el proceso de desarrollo de
software.
En la Figura 3 se ilustra la evolucin de la arquitectura durante las fases de RUP.
Se tiene una arquitectura ms robusta en las fases finales del proyecto. En las
fases inciales lo que se hace es ir consolidando la arquitectura por medio de
baselines y se va modificando dependiendo de las necesidades del proyecto.
Figura 3: Evolucin de la arquitectura del sistema
-
7/30/2019 Documento Tesis v1
23/81
23
http://www.ibm.com/developerworks/rational/library/content/03July/1000/1251/1251_bestpractices_TP026B.pdf
Es conveniente ver el sistema desde diferentes perspectivas para comprender
mejor el diseo por lo que la arquitectura se representa mediante varias vistas que
se centran en aspectos concretos del sistema, abstrayndose de los dems. Para
RUP, todas las vistas juntas forman el llamado modelo 4+1 de la arquitectura, el
cual recibe este nombre porque lo forman las vistas lgica, de implementacin, de
proceso y de despliegue, ms la de Casos de Uso que es la que da cohesin a
todas.
Proceso Iterativo e Incremental:
El equilibrio correcto entre los Casos de Uso y la arquitectura es algo muyparecido al equilibrio de la forma y la funcin en el desarrollo del producto, lo cual
se consigue con el tiempo. Para esto, la estrategia que se propone en RUP es
tener un proceso iterativo e incremental en donde el trabajo se divide en partes
ms pequeas o mini proyectos. Permitiendo que el equilibrio entre Casos de Uso
y arquitectura se vaya logrando durante cada mini proyecto, as durante todo el
proceso de desarrollo. Cada mini proyecto se puede ver como una iteracin (un
recorrido ms o menos completo a lo largo de todos los flujos de trabajo
fundamentales) del cual se obtiene un incremento que produce un crecimiento en
el producto.
Una iteracin puede realizarse por medio de una cascada como se muestra en la
Figura 4. Se pasa por los flujos fundamentales (Requisitos, Anlisis, Diseo,
Implementacin y Pruebas), tambin existe una planificacin de la iteracin, un
anlisis de la iteracin y algunas actividades especficas de la iteracin. Al
finalizar se realiza una integracin de los resultados con lo obtenido de las
iteraciones anteriores.
http://www.ibm.com/developerworks/rational/library/content/03July/1000/1251/1251_bestpractices_TP026B.pdfhttp://www.ibm.com/developerworks/rational/library/content/03July/1000/1251/1251_bestpractices_TP026B.pdfhttp://www.ibm.com/developerworks/rational/library/content/03July/1000/1251/1251_bestpractices_TP026B.pdfhttp://www.ibm.com/developerworks/rational/library/content/03July/1000/1251/1251_bestpractices_TP026B.pdfhttp://www.ibm.com/developerworks/rational/library/content/03July/1000/1251/1251_bestpractices_TP026B.pdf -
7/30/2019 Documento Tesis v1
24/81
24
Figura 4: Una iteracin RUP
http://www.ibm.com/developerworks/rational/library/content/03July/1000/1251/1251_best
practices_TP026B.pdf
El proceso iterativo e incremental consta de una secuencia de iteraciones. Cada
iteracin aborda una parte de la funcionalidad total, pasando por todos los flujos
de trabajo relevantes y refinando la arquitectura. Cada iteracin se analiza cuando
termina. Se puede determinar si han aparecido nuevos requisitos o han cambiado
los existentes, afectando a las iteraciones siguientes. Durante la planificacin de
los detalles de la siguiente iteracin, el equipo tambin examina cmo afectarn
los riesgos que an quedan al trabajo en curso. Toda la retroalimentacin de laiteracin pasada permite reajustar los objetivos para las siguientes iteraciones. Se
contina con esta dinmica hasta que se haya finalizado por completo con la
versin actual del producto.
RUP divide el proceso en cuatro fases, dentro de las cuales se realizan varias
iteraciones en nmero variable segn el proyecto y en las que se hace un mayor o
menor hincapi en los distintas actividades. En la Figura 5 se muestra cmo vara
el esfuerzo asociado a las disciplinas segn la fase en la que se encuentre el
proyecto RUP.
http://www.ibm.com/developerworks/rational/library/content/03July/1000/1251/1251_bestpractices_TP026B.pdfhttp://www.ibm.com/developerworks/rational/library/content/03July/1000/1251/1251_bestpractices_TP026B.pdfhttp://www.ibm.com/developerworks/rational/library/content/03July/1000/1251/1251_bestpractices_TP026B.pdfhttp://www.ibm.com/developerworks/rational/library/content/03July/1000/1251/1251_bestpractices_TP026B.pdfhttp://www.ibm.com/developerworks/rational/library/content/03July/1000/1251/1251_bestpractices_TP026B.pdf -
7/30/2019 Documento Tesis v1
25/81
25
Figura 5: Esfuerzo en actividades segn fase del proyecto
http://www.ibm.com/developerworks/rational/library/content/03July/1000/1251/1251_bestprac
tices_TP026B.pdf
Las primeras iteraciones (en las fases de Inicio y Elaboracin) se enfocan hacia la
comprensin del problema y la tecnologa, la delimitacin del mbito del proyecto,
la eliminacin de los riesgos crticos, y al establecimiento de una baseline de la
arquitectura.
Durante la fase de inicio las iteraciones hacen poner mayor nfasis en actividades
del modelado del negocio y de los requisitos.
En la fase de elaboracin, las iteraciones se orientan al desarrollo de la baseline
de la arquitectura, abarcan ms los flujos de trabajo de requerimientos, modelo de
negocios (refinamiento), anlisis, diseo y una parte de implementacin orientado
a la baseline de la arquitectura.
En la fase de construccin, se lleva a cabo la construccin del producto por medio
de una serie de iteraciones.
http://www.ibm.com/developerworks/rational/library/content/03July/1000/1251/1251_bestpractices_TP026B.pdfhttp://www.ibm.com/developerworks/rational/library/content/03July/1000/1251/1251_bestpractices_TP026B.pdfhttp://www.ibm.com/developerworks/rational/library/content/03July/1000/1251/1251_bestpractices_TP026B.pdfhttp://www.ibm.com/developerworks/rational/library/content/03July/1000/1251/1251_bestpractices_TP026B.pdfhttp://www.ibm.com/developerworks/rational/library/content/03July/1000/1251/1251_bestpractices_TP026B.pdf -
7/30/2019 Documento Tesis v1
26/81
26
Para cada iteracin se selecciona algunos Casos de Uso, se refina su anlisis y
diseo y se procede a su implementacin y pruebas. Se realiza una pequea
cascada para cada ciclo. Se realizan tantas iteraciones hasta que se termine la
implementacin de la nueva versin del producto.
En la fase de transicin se pretende garantizar que se tiene un producto preparado
para su entrega a la comunidad de usuarios.
Como se puede observar en cada fase participan todas las disciplinas, pero
dependiendo de la fase, el esfuerzo dedicado a una disciplina vara.
1.4.5. Lenguaje UMLUML es un lenguaje para visualizar, especificar, construir y documentar los
artefactos de un sistema software. Es un estndar de la OMG
(http://www.omg.org). Utilizar herramientas de modelado visual facilita la gestin
de dichos modelos, permitiendo ocultar o exponer detalles cuando sea necesario.
El modelado visual tambin ayuda a mantener la consistencia entre los artefactos
del sistema: requisitos, diseos e implementaciones. En resumen, el modelado
visual ayuda a mejorar la capacidad del equipo para gestionar la complejidad del
software.
2. Estado del Arte
2.1. Estudio
2.1.1. Algoritmos de Cifrado
Advanced Encryption Standard
(Wikipedia, Advanced Encryption Standard)Es un esquema de cifrado por bloques
adoptado como un estndar de cifrado por el gobierno de los Estados Unidos. Se
espera que sea usado en el mundo entero y analizado exhaustivamente, como fue
el caso de su predecesor, el Data Encryption Standard (DES). El AES fue
-
7/30/2019 Documento Tesis v1
27/81
27
anunciado por el Instituto Nacional de Estndares y Tecnologa (NIST) como FIPS
PUB 197 de los Estados Unidos (FIPS 197) el 26 de noviembre de 2001 despus
de un proceso de estandarizacin que dur 5 aos. Se transform en un estndar
efectivo el 26 de mayo de 2002. Desde 2006, el AES es uno de los algoritmos ms
populares usados en criptografa simtrica.
Descripcin del cifrado
AES aunque es conocido como Rijndael no es precisamente este (en la prctica
se los llama de manera indistinta) ya que Rijndael permite un mayor rango de
tamao de bloques y longitud de claves; AES tiene un tamao de bloque fijo de
128 bits y tamaos de llave de 128, 192 256 bits, mientras que Rijndael puede
ser especificado por una clave que sea mltiplo de 32 bits, con un mnimo de 128
bits y un mximo de 256 bits.
La clave de AES se expande usando el esquema de claves de Rijndael.
La mayora de los clculos del algoritmo AES se hacen en un campo finito
determinado.
AES opera en una matriz de 44 de bytes, llamada state (algunas versiones de
Rijndael con un tamao de bloque mayor tienen columnas adicionales en el state).
Para el cifrado, cada ronda de la aplicacin del algoritmo AES (excepto la ltima)
consiste en cuatro pasos:
1. SubBytes en este paso se realiza una sustitucin no lineal donde cada
byte es reemplazado con otro de acuerdo a una tabla de bsqueda.
2. ShiftRows en este paso se realiza un transposicin donde cada fila del
state es rotado de manera cclica un nmero determinado de veces.
3. MixColumns en este paso se realiza una operacin de mezclado, que
opera en las columnas del state, combinando los cuatro bytes en cada
columna usando una transformacin lineal.
http://es.wikipedia.org/wiki/Transformaci%C3%B3n_linealhttp://es.wikipedia.org/wiki/Transformaci%C3%B3n_lineal -
7/30/2019 Documento Tesis v1
28/81
28
4. AddRoundKey en este paso, cada byte del state es combinado con la
clave round; cada clave round se deriva de la clave de cifrado usando
una iteracin de la clave.
La ronda final reemplaza la fase MixColumns por otra instancia deAddRoundKey.
Sistema Criptogrfico con Clave Pblica RSA
(Wikipedia, RSA)Es un algoritmo asimtrico cifrador de bloques, que utiliza una
clave pblica, la cual se distribuye preferentemente en forma autenticada, y otra
privada, la cual es guardada en secreto por su propietario.
Una clave es un nmero de gran tamao, que una persona puede conceptualizarcomo un mensaje digital, como un archivo binario o como una cadena de bits o
bytes.
Cuando se quiere enviar un mensaje, el emisor busca la clave pblica de cifrado
del receptor, cifra su mensaje con esa clave, y una vez que el mensaje cifrado
llega al receptor, ste se ocupa de descifrarlo usando su clave oculta.
Los mensajes enviados usando el algoritmo RSA se representan mediante
nmeros y el funcionamiento se basa en el producto de dos nmeros primos
grandes (mayores que 10100) elegidos al azar para conformar la clave de
descifrado.
Emplea expresiones exponenciales en aritmtica modular.
La seguridad de este algoritmo radica en que no hay maneras rpidas conocidas
de factorizar un nmero grande en sus factores primos utilizando computadoras
tradicionales.
-
7/30/2019 Documento Tesis v1
29/81
29
Data Encryption Standard (DES)
(Wikipedia, Data Encryption Standard)Es un algoritmo de cifrado, es decir, un
mtodo para cifrar informacin, escogido como FIPS en los Estados Unidos en
1976, y cuyo uso se ha propagado ampliamente por todo el mundo. El algoritmofue controvertido al principio, con algunos elementos de diseo clasificados, una
longitud de clave relativamente corta, y las continuas sospechas sobre la
existencia de alguna puerta trasera para la National Security Agency (NSA).
Posteriormente DES fue sometido a un intenso anlisis acadmico y motiv el
concepto moderno del cifrado por bloques y su criptoanlisis.
Hoy en da, DES se considera inseguro para muchas aplicaciones. Esto se debe
principalmente a que el tamao de clave de 56 bits es corto; las claves de DES se
han roto en menos de 24 horas. Existen tambin resultados analticos que
demuestran debilidades tericas en su cifrado, aunque son inviables en la
prctica. Se cree que el algoritmo es seguro en la prctica en su variante de Triple
DES, aunque existan ataques tericos.
Desde hace algunos aos, el algoritmo ha sido sustituido por el nuevo AES
(Advanced Encryption Standard).
En algunas ocasiones, DES es denominado tambin DEA (Data Encryption
Algorithm).
Descripcin:
DES es el algoritmo prototipo del cifrado por bloques, un algoritmo que toma un
texto en claro de una longitud fija de bits y lo transforma, mediante una serie de
complicadas operaciones, en un texto cifrado de la misma longitud. En el caso de
DES el tamao del bloque es de 64 bits. DES utiliza tambin una clave
criptogrfica para modificar la transformacin, de modo que el descifrado slo
puede ser realizado por aquellos que conozcan la clave concreta utilizada en el
cifrado. La clave mide 64 bits, aunque en realidad, slo 56 de ellos son empleados
-
7/30/2019 Documento Tesis v1
30/81
30
por el algoritmo. Los ocho bits restantes se utilizan nicamente para comprobar la
paridad, y despus son descartados. Por tanto, la longitud de clave efectiva en
DES es de 56 bits, y as es como se suele especificar.
Al igual que otros cifrados de bloque, DES debe ser utilizado en el modo deoperacin de cifrado de bloque si se aplica a un mensaje mayor de 64 bits. FIPS-
81 especfica varios modos para el uso con DES, incluyendo uno para
autenticacin. Se pueden consultar ms documentos sobre el uso de DES en
FIPS-74.
Triple DES
Algoritmo que hace triple cifrado del DES. Tambin es conocido como TDES o
3DES, fue desarrollado por IBM en 1978.
Este hecho se basa en que DES tiene la caracterstica matemtica de no ser un
grupo, lo que implica que si se cifra el mismo bloque dos veces con dos claves
diferentes se aumenta el tamao efectivo de la clave.
La variante ms simple del Triple DES funciona de la siguiente manera:
Donde Mes el mensaje a cifrar y k1, k2 y k3 las respectivas claves DES.
International Data Encryption Algorithm o IDEA
Es un cifrador por bloques diseado por Xuejia Lai y James L. Massey de la
Escuela Politcnica Federal de Zrich y descrito por primera vez en 1991. Fue unalgoritmo propuesto como reemplazo del DES (Data Encryption Standard). IDEA
fue una revisin menor de PES (Proposed Encryption Standard, del ingls
Estndar de Cifrado Propuesto), un algoritmo de cifrado anterior. Originalmente
IDEA haba sido llamado IPES (Improved PES, del ingls PES Mejorado).
-
7/30/2019 Documento Tesis v1
31/81
31
IDEA fue diseado en contrato con la Fundacin Hasler, la cual se hizo parte de
Ascom-Tech AG. IDEA es libre para uso no comercial, aunque fue patentado y sus
patentes se vencern en 2010 y 2011. El nombre "IDEA" es una marca registrada
y est licenciado mundialmente por MediaCrypt.
IDEA fue utilizado como el cifrador simtrico en las primeras versiones de PGP
(PGP v2.0) y se lo incorpor luego de que el cifrador original usado en la v1.0
("Bass-O-Matic") se demostr insegura. Es un algoritmo ptimo en OpenPGP.
Funcionamiento
IDEA opera con bloques de 64 bits usando una clave de 128 bits y consiste de
ocho transformaciones idnticas (cada una llamada un ronda) y unatransformacin de salida (llamada media ronda). El proceso para cifrar y descifrar
es similar. Gran parte de la seguridad de IDEA deriva del intercalado de
operaciones de distintos grupos adicin y multiplicacin modular y O-exclusivo
(XOR) bit a bit que son algebraicamente "incompatibles" en cierta forma.
IDEA utiliza tres operaciones en su proceso con las cuales logra la confusin, se
realizan con grupos de 16 bits y son:
Operacin O-exclusiva (XOR) bit a bit (indicada con unazul)
Suma mdulo 216 (indicada con un verde)
Multiplicacin mdulo 216+1, donde la palabra nula (0x0000) se interpreta
como 216 (indicada con un rojo)
(216 = 65536; 216+1 = 65537, que es primo)
Despus de realizar 8 rondas completas se realiza la mitad, obteniendo elresultado en este paso de la ronda:
Este algoritmo presenta, a primera vista, diferencias notables con el DES, que lo
hacen ms atractivo:
http://es.wikipedia.org/wiki/Imagen:Odot.pnghttp://es.wikipedia.org/wiki/Imagen:Boxplus.pnghttp://es.wikipedia.org/wiki/Imagen:Odot.pnghttp://es.wikipedia.org/wiki/Imagen:Boxplus.png -
7/30/2019 Documento Tesis v1
32/81
32
El espacio de claves es mucho ms grande: 2128 3.4 x 1038
Todas las operaciones son algebraicas
No hay operaciones a nivel bit, facilitando su programacin en alto nivel
Es ms eficiente que los algoritmos de tipo Feistel, porque a cada vuelta se
modifican todos los bits de bloque y no solamente la mitad.
Se pueden utilizar todos los modos de operacin definidos para el DES
2.1.2. Metodologas para desarrollar software
Rational Unified Process (RUP)
La metodologa RUP, llamada as por sus siglas que en ingls significa Rational
Unified Process, divide en 4 fases el desarrollo del software:
Inicio, El Objetivo en esta etapa es determinar la visin del proyecto.
Elaboracin, En esta etapa el objetivo es determinar la arquitectura ptima.
Construccin, En esta etapa el objetivo es llevar a obtener la capacidad
operacional inicial.
Transmisin, El objetivo es llegar a obtener el release del proyecto.
Cada una de estas etapas es desarrollada mediante el ciclo de iteraciones, la cualconsiste en reproducir el ciclo de vida en cascada a menor escala. Los Objetivos
de una iteracin se establecen en funcin de la evaluacin de las iteraciones
precedentes.
Vale mencionar que el ciclo de vida que se desarrolla por cada iteracin, es
llevada bajo dos disciplinas:
http://es.wikipedia.org/wiki/Red_de_Feistelhttp://es.wikipedia.org/wiki/Red_de_Feistel -
7/30/2019 Documento Tesis v1
33/81
33
Disciplina de Desarrollo
Ingeniera de Negocios: Entendiendo las necesidades del negocio.
Requerimientos: Trasladando las necesidades del negocio a un sistemaautomatizado.
Anlisis y Diseo: Trasladando los requerimientos dentro de la arquitectura
de software.
Implementacin: Creando software que se ajuste a la arquitectura y que
tenga el comportamiento deseado.
Pruebas: Asegurndose que el comportamiento requerido es el correcto y
que todo lo solicitado est presente.
Disciplina de Soporte
Configuracin y administracin del cambio: Guardando todas las versiones
del proyecto.
Administrando el proyecto: Administrando horarios y recursos.
Ambiente: Administrando el ambiente de desarrollo.
Distribucin: Hacer todo lo necesario para la salida del proyecto
Es recomendable que a cada una de estas iteraciones se les clasifique y ordene
segn su prioridad, y que cada una se convierta luego en un entregable al cliente.
Esto trae como beneficio la retroalimentacin que se tendra en cada entregable o
en cada iteracin.
Los elementos del RUP son:
Actividades, Son los procesos que se llegan a determinar en cada
iteracin.
Trabajadores, Vienen hacer las personas o entes involucrados en cada
proceso.
-
7/30/2019 Documento Tesis v1
34/81
34
Artefactos, Un artefacto puede ser un documento, un modelo, o un
elemento de modelo.
Una particularidad de esta metodologa es que, en cada ciclo de iteracin, se hace
exigente el uso de artefactos, siendo por este motivo, una de las metodologasms importantes para alcanzar un grado de certificacin en el desarrollo del
software.
Extreme Programing (XP)
Es una de las metodologas de desarrollo de software ms exitosas en la
actualidad, utilizada para proyectos de corto plazo, pequeo equipo y cuyo plazode entrega es ipso facto. La metodologa consiste en una programacin
extremadamente rpida, cuya particularidad es tener como parte del equipo, al
usuario final, pues es uno de los requisitos para llegar al xito del proyecto.
Caractersticas de XP, la metodologa se basa en:
Pruebas Unitarias: se basa en las pruebas realizadas a los principales
procesos, de tal manera que adelantndonos en algo hacia el futuro,podamos chequear las fallas que pudieran ocurrir. Es como si nos
adelantramos a obtener los posibles errores.
Re fabricacin: se basa en la reutilizacin de cdigo, para lo cual se crean
patrones o modelos estndares, siendo ms flexible al cambio.
Programacin en pares: una particularidad de esta metodologa es que
propone la programacin en pares, la cual consiste en que dosdesarrolladores participen en un proyecto en una misma estacin de
trabajo. Cada miembro lleva a cabo la accin que el otro no est haciendo
en ese momento. Es como el chofer y el copiloto: mientras uno conduce, el
otro consulta el mapa.
-
7/30/2019 Documento Tesis v1
35/81
35
Qu es lo que propone XP?
Empieza en pequeo y aade funcionalidad con retroalimentacin continua
El manejo del cambio se convierte en parte sustantiva del proceso
El costo del cambio no depende de la fase o etapa No introduce funcionalidades antes que sean necesarias
El cliente o el usuario se convierte en miembro del equipo
Derechos del Cliente
Decidir que se implementa
Saber el estado real y el progreso del proyecto
Aadir, cambiar o quitar requerimientos en cualquier momento Obtener lo mximo de cada semana de trabajo
Obtener un sistema funcionando cada 3 o 4 meses
Derechos del Desarrollador
Decidir cmo se implementan los procesos
Crear el sistema con la mejor calidad posible
Pedir al cliente en cualquier momento aclaraciones de los requerimientos Estimar el esfuerzo para implementar el sistema
Cambiar los requerimientos en base a nuevos descubrimientos
Lo fundamental en este tipo de metodologa es:
La comunicacin, entre los usuarios y los desarrolladores
La simplicidad, al desarrollar y codificar los mdulos del sistema
La retroalimentacin, concreta y frecuente del equipo de desarrollo, elcliente y los usuarios finales
-
7/30/2019 Documento Tesis v1
36/81
36
Microsoft Solution Framework (MSF)
Esta es una metodologa flexible e interrelacionada con una serie de conceptos,
modelos y prcticas de uso, que controlan la planificacin, el desarrollo y la
gestin de proyectos tecnolgicos. MSF se centra en los modelos de proceso y deequipo dejando en un segundo plano las elecciones tecnolgicas.
MSF tiene las siguientes caractersticas:
Adaptable: es parecido a un comps, usado en cualquier parte como un
mapa, el cual su uso es dirigido a un especfico lugar.
Escalable: puede organizar equipos tan pequeos entre 3 o 4 personas,
as como tambin, proyectos que requieren 50 personas a ms. Flexible: es utilizada en el ambiente de desarrollo de cualquier cliente.
Tecnologa Agnstica: porque puede ser usada para desarrollar
soluciones basadas sobre cualquier tecnologa.
MSF se compone de seis modelos encargados de planificar las diferentes partes
implicadas en el desarrollo de un proyecto: Modelo de Arquitectura del Proyecto,
Modelo de Equipo, Modelo de Proceso, Modelo de Gestin del Riesgo, Modelo de
Diseo de Proceso y finalmente el Modelo de Aplicacin.
Modelo de Arquitectura del Proyecto: Diseado para acortar la planificacin
del ciclo de vida. Este modelo define las pautas para construir proyectos
empresariales a travs del lanzamiento de versiones.
Modelo de Equipo: Este modelo ha sido diseado para mejorar elrendimiento del equipo de desarrollo. Proporciona una estructura flexible
para organizar los equipos de un proyecto. Puede ser escalado
dependiendo del tamao del proyecto y del equipo de personas disponibles.
-
7/30/2019 Documento Tesis v1
37/81
37
Modelo de Proceso: Diseado para mejorar el control del proyecto,
minimizando el riesgo, y aumentar la calidad acortando el tiempo de
entrega. Proporciona una estructura de pautas a seguir en el ciclo de vida
del proyecto, describiendo las fases, las actividades, la liberacin de
versiones y explicando su relacin con el Modelo de equipo.
Modelo de Gestin del Riesgo: Diseado para ayudar al equipo a identificar
las prioridades, tomar las decisiones estratgicas correctas y controlar las
emergencias que puedan surgir. Este modelo proporciona un entorno
estructurado para la toma de decisiones y acciones valorando los riesgos
que pueden provocar.
Modelo de Diseo del Proceso: Diseado para distinguir entre los objetivos
empresariales y las necesidades del usuario. Proporciona un modelo
centrado en el usuario para obtener un diseo eficiente y flexible a travs
de un enfoque iterativo. Las fases de diseo conceptual, lgico y fsico
proveen tres perspectivas diferentes para los tres tipos de roles: los
usuarios, el equipo y los desarrolladores.
Modelo de Aplicacin: Diseado para mejorar el desarrollo, el mantenimiento y el
soporte, proporciona un modelo de tres niveles para disear y desarrollar
aplicaciones software. Los servicios utilizados en este modelo son escalables, y
pueden ser usados en un solo ordenador o incluso en varios servidores.
3. Viabilidad
El desarrollo de esta tesis es factible por los siguientes motivos econmicos y
tcnicos.
-
7/30/2019 Documento Tesis v1
38/81
38
3.1. Viabilidad Econmica
Los costos de este sistema se distribuyen de la siguiente manera:
El desarrollo del SW a Medida se desarrollara en 4 meses por un Analista-Diseador-Programador donde su costo mensual ser de S/. 2000.00
Nuevos Soles.
Debido a que las ONGs Nacionales e Internacionales pueden entrar al
programa NGO CONNECTION de Microsoft el costo de licencias del
sistema operativo Windows Server 2008, el IDS Visual Studio 2008.NET y
el Sistema de Base de datos SQL Server 2005 es de 0 Nuevos Soles.
El costo de un servidor de las siguientes caractersticas: 4 Procesadores,
500 GB de Memoria Fsica y 4GB de Memoria RAM. Tiene un costo de S/.
4500.00 Nuevos Soles.
El costo de los Certificados SSL de servidor Web es de S/. 750.00 Nuevos
Soles, el detalle de los costos se encuentra en el Anexo N 3
El adiestramiento ser realizado por el Analista-Diseador-Programador y
tendr una duracin de un mes, con un costo de S/. 2000.00 Nuevos Soles.
Descripcin Cantidad Costo Costo totalSW a Medida 1 S/. 8,000.00 S/. 8,000.00SoftwareWindows Server 2008 1 S/. -SQL2005 , 1 S/. -Visual Studio 2008 1 S/. - S/. -Servidor 1 S/. 4,500.00 S/. 4,500.00Certificados SSL deservidor Web
1 S/. 750.00 S/. 750.00
Adiestramiento 8hrs / 25
Trabajadores
S/. 2,000.00 S/. 2,000.00
TOTAL COSTO S/. 15,250.00
Beneficios
Los principales beneficios que brindara el sistema es el ahorro de tiempo en la
ejecucin del proceso (Reduciendo el 30% de error en la realizacin del proceso
-
7/30/2019 Documento Tesis v1
39/81
39
que se tiene actualmente segn los tcnicos que laboran actualmente), los gastos
en materiales de oficina o administrativos y la eliminacin de la prdida de los
requerimientos por realizar un proceso manual (esta prdida era del 27%).
Por la parte de ahorro en materiales de impresin se calculara el costo dedocumentario que genera 90 requerimientos (pedidos). Cada requerimiento
(pedido) se imprime 2 veces, este genera un cuadro comparativo que se
imprime 1 vez, y luego este requerimiento genera 1, 2 3 rdenes de
compra donde cada una es impresa 3 veces.
Con el sistema no se necesitara un asistente de compras.
El aumento en la productividad marginal del personal se detalla en el anexo
N8.
Anlisis costo benfico
Se ha calculado que la recuperacin de la inversin para la organizacin en 6
meses.
Numero de Requerimientos 90
Costo por papel 0.028
Ahorro o Ganancia de:
DocumentoCantidad de
Impresin
Total de
ImpresionesValor
1 Requerimiento (Pedido) 2 180S/. 5.04
1 Cuadro Comparativo 1 90 S/. 2.52
3 Ordenes de Compra 3 810 S/. 22.68
30 % Ciclo completo por Error 6 324 S/. 9.07
Ciclo de funcionamientoTotal de
Impresiones
Costo Por
ImpresinValor
Imprime hasta 6500 1404 0.021 S/. 29.16
Cantidad Costo Costo Total Valor
1 1200 1200 S/. 1,200.00
1329.55 1329.55 S/. 1,329.55
S/. 2,598.02
Asistente de
compras
Aumento en la productividad media del
personal
BENEFICIO RECURENTE
Ahorro de materiales administrativos
Papel Bond A4
TONER HP 3005
Aumento en la productividad marginal del personal
Gastos Ganancias
Implementar S/. 15,250.00 S/. 0.006 meses S/. 0.00 S/. 15,588.10
Total S/. 15,250.00 S/. 15,588.10
Diferencia S/. 338.10
-
7/30/2019 Documento Tesis v1
40/81
40
3.2. Viabilidad Tcnica
Las herramientas tecnolgicas y modelos que necesarios, son usados en la
actualidad dando muy buenos resultados.
Por lo tanto no se tiene un riesgo alto de tener un mal resultado al usarlas en la
realizacin de esta tesis.
Tambin se dispondr del software, hardware y recursos necesarios para la
elaboracin de esta tesis.
3.3. Viabilidad Poltica
Poltica de Gastos, Inversin y Adquisicin de Bienes y servicios
Las polticas especficas descritas, estn orientadas a establecer mecanismos de
control interno, por lo tanto ser responsabilidad de los funcionarios facultados
para autorizar gastos e inversiones, vigilar que se apliquen estrictamente los
lmites y polticas fijados en este documento.
Asimismo, para efectos de los gastos por compras debern considerarse los
dispositivos legales vigentes que sean de aplicacin.
Queda a cargo de las Unidades de Administracin y de Contabilidad, la
comprobacin del cumplimiento de estas polticas.
Los funcionarios responsables de las adquisiciones, pago y registro debern
informar a la Administracin de cualquier transgresin de esta norma que conlleve
a la presuncin o materializacin de un acto irregular en cualquiera de las etapas
del proceso de adquisiciones o correspondiente al pago de las mismas.
Para todo aquello que no estuviera contemplado en el presente documento, se
reitera la plena actualidad y vigencia de las normas y polticas que an no siendo
-
7/30/2019 Documento Tesis v1
41/81
41
escritas, se sustentan en el buen juicio individual, la filosofa y praxis que se
vienen aplicando tradicionalmente.
En ese sentido, el trmite de los gastos en que incurra CEDRO, en sus fases de
solicitud, comprobacin, autorizacin y ejecucin, deber mantener, en trminos
generales, en concordancia con las normas generales y polticas especficas
escritas y no escritas pero de conocimiento y aceptacin de los jefes
responsables.
Comprobacin de la necesidad del gasto/inversin
El responsable de cada Unidad deber justificar la necesidad del gasto, siendomuy importante efectuar previamente coordinaciones con la administracin, y con
el objeto de determinar la posibilidad de utilizar recursos disponibles.
La necesidad del gasto se relaciona con los requerimientos de las actividades de
los distintos programas y del funcionamiento general de CEDRO, para el logro de
los fines y objetivos de cada unidad y la de la institucin en su conjunto. Los fines
a tenerse presentes sern de orden de imagen institucional, de necesidad
operativa y de necesidades que se traducen en el presupuesto anual.
Factibilidad econmica y presupuestaria
Todo gasto, para que pueda ser autorizado y efectuado, debe contar con los
recursos econmicos suficientes. Es precisamente esta obvia constatacin la que
sustentar el enfoque que cada responsable deber dar al gasto.
Tambin de esta evidencia deriva la necesidad y conveniencia que el mayor
nmero y volumen de gastos sean previstos en el contexto del presupuesto anual
de CEDRO.
-
7/30/2019 Documento Tesis v1
42/81
42
Los pronsticos presupuestales as como su paulatina ejecucin, debern ser
conocidos por los responsables del gasto; a fin de que decisiones ya tomadas con
respecto a determinados gastos puedan ser revisadas y adecuadas a necesidades
vigentes.
Las Unidades Financieras (Administracin y de Contabilidad) tendrn la tarea de
apoyar y colaborar en las decisiones acerca de la factibilidad econmica de los
gastos e inversiones que se deban ejecutar.
Poltica de compras
La poltica de compras del Centro es la de adquirir equipos, materiales y serviciosal costo ms econmico y conveniente posible, teniendo en cuenta la calidad de
los mismos.
Para la adquisicin de artculos o servicios cuyo costo sea superior al equivalente
de US$ 500.00 (Quinientos y 00/100 Dlares Americanos) en Moneda Nacional,
deber obtenerse y analizarse ofertas de 3 proveedores distintos, salvo casos de
excepcin debidamente justificados.
El Director Ejecutivo es el encargado de aprobar las compras o adquisiciones en
Moneda Nacional hasta por encima de la cifra anterior.
Solicitud yaprobacin del gasto/inversin
La solicitud y aprobacin del gasto se tramitar en los formularios que disponen
CEDRO u otros documentos que por sus caractersticas se utilizan para tal fin, de
acuerdo a las siguientes normas.
-
7/30/2019 Documento Tesis v1
43/81
43
La aprobacin deber figurar en los mencionados formularios internos de solicitud
y en los presupuestos aprobados, presentados por proveedores, u otros
documentos similares.
Los lmites mximos de aprobacin slo podrn ser ejecutados por el Director
Ejecutivo y el Sub Director.
Slo podrn solicitar la aprobacin de gastos los responsables de cada unidad,
segn las categoras y lmites establecidos en este Manual
Los programas y/u oficinas que CEDRO establezca en provincias podrn aprobar
gastos en razn de su ubicacin geogrfica y evidente urgencia del requerimiento;sin embargo, de exceder el lmite asignado, debern previamente obtener la
aprobacin del Director Ejecutivo por la va de comunicacin mas apropiada,
aprobacin que registrarn en el comprobante de pago, regularizndose
posteriormente con el respectivo refrendo.
Una vez que los funcionarios facultados en este documento, autoricen la compra
mediante refrendo en los respectivos documentos sustentatorios, ya no ser
necesaria la autorizacin de dichos funcionarios en las facturas, notas contables u
otros documentos contables, al efectuarse el pago.
El Director Ejecutivo al autorizar el gasto lo har previo visto bueno del
responsable solicitante de la compra y de los niveles intermedios de autorizacin
(Administracin y Contabilidad).
El documento sustentatorio o la copia en la cual figure la aprobacin de la compra
deber acompaarse a la respectiva factura.
-
7/30/2019 Documento Tesis v1
44/81
44
Cuando el monto de las adquisiciones que se deba autorizar exceda los lmites
sealados para cada nivel, no podr efectuarse fraccionamiento, debiendo
requerirse en estos casos la autorizacin del nivel que corresponda.
Pago y registro contable
Las unidades responsables de efectuar pagos lo harn solamente con aquellos
documentos que contengan las autorizaciones del gasto en los niveles
correspondientes, las cuales habrn sido verificadas previamente por la unidad
que efecta la compra.
Las unidades que efectan adquisiciones, incluidas aquellas que las realizan porexcepcin, debern tramitar sus pagos a travs del rea de Contabilidad. En tal
sentido, los pagos a proveedores y/o compaas de servicios sern
exclusivamente canalizados a travs de dicha unidad.
En los casos de pago de facturas/recibos por servicios recibidos directamente (luz,
agua, telfono, etc.) la Unidad de Contabilidad obtendr en dichos documentos el
refrendo del nivel correspondiente segn el monto a desembolsar.
Para efectuar los pagos se verificar que figuren en los documentos sustentatorios
(formularios de solicitud, proformas, contratos, actas, etc.) las autorizaciones de
acuerdo a lmites, adjuntando copia de stas a las facturas correspondientes.
Las facturas y rdenes de compra originales sern archivadas conjuntamente.
Las adquisiciones que efecte CEDRO se realizarn, segn su naturaleza, a
travs de la Unidad Financiera (rea de Logstica). Excepcionalmente, y en razn
a sus especiales caractersticas, stas podrn ser efectuadas por los responsables
de cada unidad. En estos casos, an cuando los montos a desembolsar se
-
7/30/2019 Documento Tesis v1
45/81
45
encuentren dentro de lmites autorizados, se requerir la aprobacin previa del
Director Ejecutivo.
Las adquisiciones e inversiones sern adjudicadas preferentemente a los
proveedores y/o contratistas que figuren en el "Registro de Proveedores" de
CEDRO, de acuerdo con la poltica de adquisiciones establecidas.
Dicho Registro deber constituirse con la aprobacin del Director Ejecutivo y la
Administracin de CEDRO.
El "Registro de Proveedores" deber actualizarse anualmente, requirindose para
el ingreso o exclusin de proveedores en dicho Registro, el refrendo de cadaunidad operativa de CEDRO, previa evaluacin de la Administracin, para
determinar la calidad, cumplimiento, etc., de los proveedores registrados.
Para determinar la adjudicacin se requerir, en lo posible, por lo menos tres
cotizaciones presentadas por los proveedores que figuren en el "Registro" ya
mencionado, excepto cuando no, se presenten o no existan en el mercado; en
estos casos, las excepciones debern ser debidamente sustentadas ante la
Administracin para su debida autorizacin por el Director Ejecutivo.
Si por alguna razn no se produjera la compra dentro de los plazos previstos y/o
se presentaran variaciones en precios, caractersticas u otras condiciones que
varen de manera sustancial la oferta original, ser necesaria una nueva
autorizacin del gasto por el Director Ejecutivo.
4. Planteamiento del Problema
A continuacin se describir el problema que est atacando el proyecto, en el cual
se ejecutara la solucin planteada por esta tesis.
-
7/30/2019 Documento Tesis v1
46/81
46
4.1. Antecedentes
Hoy en da, las ONG en el Per, cuentan con sistemas informticos de
administracin de procesos muy simples, que les sirve solo para mantener un
registro de algunos procesos que ellas realizan, como la parte de gestin de
abastecimiento, donde estn involucradas varias reas de la organizacin, y aun
habiendo sistemas de informacin todava se usan los documentos, firmas y sellos
para la realizacin de este proceso en la entidad, como resultado se tiene un
excesivo gasto en materiales de oficina (papel bond, papel carbn, tinta para
impresora, tampones, resaltadores, etc.); personal innecesario (asistentes de
logstica); sobretiempos utilizados por las personal involucradas en el proceso de
las diferentes reas (asistentes de proyectos, coordinadores de proyectos,
personal de logstica, personal contable), gastos que se podran eliminar o reducirdrsticamente.
Ms aun vemos que, el envi de la documentacin a travs de las reas que
interactan para realizar dicho proceso, suele demorar por tres motivos, los
cuales son: Envi incompleto de la documentacin, perdida del documento por no
saber en qu fase del proceso se encuentra, y correcciones en la documentacin.
4.2. Formulacin del Problema
Entonces el gran problema en el Proceso de Gestin de Abastecimiento es el
trfico de los documentos entre las reas involucradas, lo que conlleva a prdidas
de documentos, personal innecesario, y retrasos en el proceso mismo, es decir,
gastos innecesarios de tiempo, personal y de impresin documentaria, ya que
como estos documentos son validados por varias reas, cada una de estas, si
encuentran algn error manda a corregir y as se forma un crculo vicioso donde
se imprime un nmero aproximado de 4 a 6 veces un documento hasta llegar al
documento final.
-
7/30/2019 Documento Tesis v1
47/81
47
4.3. Justificacin
La Justificacin Practica de esta tesis es desarrollar una herramienta tecnolgica
que facilite y automatice el trabajo que realizan los trabajadores relacionados con
el Proceso de Gestin de Abastecimiento, y como consecuencia de ello el ahorro
en tanto en los gastos en la compra de materiales para oficina, como en el tiempo
de ejecucin del proceso.
La Justificacin Acadmica de esta tesis es que tiene como misin el dar uso a
diferentes metodologas, herramientas tecnolgicas y algoritmos para el proceso
de gestin de requerimientos.
4.4. Objetivo General
Esta investigacin tiene como objetivo reducir de una manera significativa la
impresin documentaria, automatizando el Proceso de Gestin de Abastecimiento,
donde la validez de cada rea comprometida estar representada por un estado,
que podr ser cambiado por un rol especfico (persona responsable) dentro de la
organizacin y as disminuir en forma considerable el tiempo que dura este
proceso.
4.4.1. Objetivos Especficos
Reducir de una manera significativa el tiempo de ejecucin del proceso de
Gestin de Abastecimiento.
Reducir de una manera significativa el gasto en materiales de impresin en
el proceso de Gestin de Abastecimiento.
Eliminar el envi de informacin incompleta a travs de las reas
involucradas en el proceso de Gestin de Abastecimiento.
Facilitar la labor de los trabajadores involucrados y as optimizar el proceso
de Gestin de Abastecimiento.
-
7/30/2019 Documento Tesis v1
48/81
48
Conocer de parte de los trabajadores involucrados en qu fase y/o en que
rea se encuentra el proceso de Gestin de Abastecimiento.
5. Solucin
Aqu se describir la solucin planteada por esta tesis para poder solucionar elproblema ya descrito anteriormente.
5.1. Requerimientos
A continuacin se describen los requerimientos funcionales y no funcionales
tomados. Cuyos modelos se encuentran consignados en el anexo N6.
5.1.1. Requerimientos Funcionales
Administrar Artculos
Registrar, Modificar y Eliminar artculos.
Administrar Servicios
Registrar, Modificar y Eliminar servicios.
Administrar Proformas
Registrar, Modificar y Eliminar proformas.
Consultar Cuadro Comparativo
Consultar Cuadro Comparativo para la seleccin de los mejores precios y creacin
de las rdenes.
Consultar ProformasConsultar un listado de proformas de acuerdo con criterios de bsqueda.
Consultar rdenes de Compra
Consultar un listado de rdenes de Compra de acuerdo a criterios de bsqueda.
-
7/30/2019 Documento Tesis v1
49/81
49
Generar rdenes de Compra
Generar rdenes de compra de acuerdo a la seleccin de los artculos en el
cuadro comparativo.
Consultar rdenes de Servicio
Consultar un listado de rdenes de Servicio de acuerdo a criterios de bsqueda.
Generar rdenes de Servicio
Generar rdenes de Servicio de acuerdo a la seleccin de los Servicios en el
cuadro comparativo.
Registrar RequerimientosRegistrar, Modificar y Registrar Requerimientos de Materiales o Servicios.
Consultar Requerimientos
Consultar un listado de Requerimientos de acuerdo a criterios de bsqueda.
Administrar Gua Salida
Registrar, Modificar y Registrar Guas de Salida.
Administrar Gua Entrada
Registrar, Modificar y Registrar Guas de Salida.
Consultar Stock Total
Consultar un listado del Stock de los artculos totales de acuerdo a criterios de
bsqueda.
Reporte Gua Salida
Muestra el Formato de la Gua de Salida con los datos de la gua seleccionada.
-
7/30/2019 Documento Tesis v1
50/81
50
Reporte Gua Entrada
Muestra el Formato de la Gua de Entrada con los datos de la gua seleccionada.
Reporte Requerimiento
Muestra el Formato del Requerimiento con los datos del Requerimiento
seleccionado.
Reporte Orden Compra
Muestra el Formato de la Orden de Compra con los datos de la orden
seleccionada.
Reporte Orden de Servicio
Muestra el Formato de la Orden de Servicio con los datos de la orden
seleccionada.
Validar Requerimientos
Valida la autorizacin del Requerimiento como si se hubiera firmado fsicamente.
Validar rdenes de Compra
Validara la autorizacin de la Orden de Compra como si se hubiera firmado
fsicamente.
Se tendrn que manejar los siguientes estados por documentos:
Requisicin
Estados DescripcinPRE-PEDIDO Se da cuando se registra el requerimientoPEDIDO
AUTORIZADOSe da cuando el requerimiento es aceptado por elcoordinador del proyecto
COTIZANDO Se da cuando el encargado de logstica cotiza elrequerimiento
PRE-ORDENADO Se da cuando el encargado de logstica genera lasrdenes de compra para su aprobacin
-
7/30/2019 Documento Tesis v1
51/81
51
ORDENADO Se da cuando la orden de compra es aprobada por elrea de contabilidad
RECIBIDOPARCIAL
Se da cuando parte del requerimiento es recibido enalmacn
RECIBIDO
PARCIAL YENTREGADOPARCIAL
se da cuando parte del requerimiento esta recibido
parcial y se entrega parcial
RECIBIDOCOMPLETO
Se da cuando el requerimiento es recibido porcompleto en el almacn y no se a entregado nada aun
RECIBIDOCOMPLETO YENTREGADOPARCIAL
Se da cuando el requerimiento llego por completo alalmacn y se entreg parte de este
ENTREGADOCOMPLETO
Se da cuando el requerimiento llego por completo alalmacn y se entreg por completo
ANULADO Se da cuando se anula el requerimiento. Este nopuede ser anulado una vez que fue autorizadoCOMPRADO Y
ATENDIDO ENPROVINCIA
Se da cuando el requerimiento se dio en provincia ynunca paso por el almacn
ATENDIDODIRECTO
Se da cuando el requerimiento se compr en lima ynunca paso por almacn
SERVICIOTERMINADO
Se da cuando el requerimiento es de servicio y esteservicio a concluido
Orden de compra / Orden de ServicioCREDA Cuando el encargado de logstica genera la orden.
ACEPTADA Cuando la orden de compra est aprobada por el reade contabilidad
5.1.2. Requerimientos No Funcionales
Requerimientos de Usabilidad
Las interfaces del usuario deben poder ejecutarse en los diferentesnavegadores de Internet.
Se utilizarn estndares en la denominacin y uso de controles, lo cual
facilitar al usuario que maneje el sistema.
-
7/30/2019 Documento Tesis v1
52/81
52
El usuario debe estar informado en todo momento sobre posibles errores al
momento de interactuar con el sistema.
Requerimientos de Confiabilidad
El sistema debe estar disponible las 24 horas del da, los 7 das de la
semana
El sistema debe garantizar en todo momento la confiabilidad a travs del
uso de identificadores de usuario y contraseas para cada uno de estos, y
de forma confidencial.
El sistema debe soportar un mnimo de 100 usuarios concurrentes
(requerimiento mnimo).
Requerimientos de Desempeo
El sistema debe proporcionar acceso a las consultas y los registros con no
ms de 5 segundos de tiempo de espera, exceptuando este tiempo en
horas pico con lo cual se permitir un mximo de 20 segundos de espera.
Requerimientos de Capacidad de Soporte
Se absolvern todo tipo de consultas en caso de fallas del sistema.
Requerimientos de Diseo
Se utilizarn los diagramas UML que proporcionarn al desarrollador un
mayor entendimiento del sistema, permitindole hacer modificaciones de
ste en un futuro.
Requerimientos de Implementacin
El desarrollo del sistema debe ser efectuado con la interaccin entre un
lenguaje de programacin y una base de datos, que permitan desarrollar un
sistema eficiente.
Se debe garantizar que los datos almacenados en la base de datos no
sufrirn prdida o dao alguno.
-
7/30/2019 Documento Tesis v1
53/81
53
Requerimientos de Categora Primaria
El sistema debe predecir errores.
Efectuara la validacin de toda informacin en su registro, para no
ocasionar errores al momento de guarda los datos en la base de datos.
Requerimientos de Categora Secundaria
Los tiempos de respuesta en cualquier ambiente deben ser a lo mximo 4
segundos. (1 segundo ms del tiempo recomendado de respuesta).
Requerimientos de Seguridad y Auditoria
Se tendr que usar certificado digital.
Se tendr que tener un log para poder realizar restauraciones.
Se controlarn y registrarn los errores en el sistema.
Se emcriptarn los datos ms importantes en la base de datos.
Se tendr que manejar perfiles y permisos.
Se tendr que capturar el IP del usuario cliente.
Requerimientos de Mantenibilidad
El sistema contara con la facilidad de poder ser modificado, para corregir
fallos, mejorar su funcionamiento u otros atributos o adaptarse a cambios
en el entorno, para esto se ha realizado un plan de mantenimiento que seadjunta en el Anexo N9 el cual en algunas de sus partes, en funcin al
requerimiento del cliente, se realizara la estructuracin y desarrollo del
mantenimiento respectivo.
5.2. Estndares de Desarrollo
5.2.1. Documentacin
5.2.1.1. Formato de documentacin
Clasificacin Tipo de
Letra
Tamao Otros Interlineado
Contenido Times New
Roman
10 Cursiva Sencillo
-
7/30/2019 Documento Tesis v1
54/81
54
Ttulos Arial 18 Negrita Sencillo
Subttulos Arial 12 Negrita Sencillo
Encabezado
Principal
Arial 18 Negrita Sencillo
Encabezado y
Pie de pgina
Times New
Roman
10 Normal Sencillo
5.2.1.2. Nombre de documentos
Documentos del Negocio
SIGAP_.doc
Documentos del SistemaSIGAP _.doc
Documentos de Gerencia y otros
SIGAP _.doc
5.2.1.3. Diagramas de Diseo y Anlisis
SIGAP _.mdl5.2.2. Formato de Diseo
5.2.2.1. Etiquetas
Tipo de Letra: Verdana
Tamao de la Letra: 10
Color de la Letra: Negro
5.2.2.2. BotonesTipo de Letra: Verdana