documento tesis v1

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


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.


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.


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


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


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/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


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.


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


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.


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


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.


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


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.


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.


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.


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)


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


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


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


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


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


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


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.


24/81

24

Figura 4: Una iteracin RUP

http://www.ibm.com/developerworks/rational/library/content/03July/1000/1251/1251_best


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.


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.


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


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


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.


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


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).


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


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


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.


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.


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


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.


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.


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


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


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


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.


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.


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.


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


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.


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.


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.


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.


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.


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


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.


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.


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


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

documento tesis v1

Documents