UNIVERSIDAD AMAZNICA DE PANDOREA DE CIENCIAS Y TECNOLOGACARRERA DE INGENIERA INFORMTICA

PROYECTO DE GRADOSISTEMA DE REGISTRO Y CONTROL DE DOCUMENTOS PARA LA UNIDAD DE ARCHIVO CENTRAL DEL GOBIERNO MUNICIPAL DE COBIJA

Postulante: Julia Lima HuancaTutor: Msc. Lic. Humberto Fernndez CalleAsesor: Msc. Lic. Juan Carlos Huanca Guanca

Cobija - Pando - Bolivia2013AGRADECIMIENTOS DEDICATORIO RESUMEN

NDICE 1.CAPITULO I61.1.INTRODUCCIN61.2.ANTECEDENTES71.3.PLANTEAMIENTO DEL PROBLEMA91.4.OBJETIVOS91.4.1.OBJETIVO GENERAL91.4.2.OBJETIVOS ESPECFICOS101.5.JUSTIFICACIN101.5.1.JUSTIFICACIN ECONMICA101.5.2.JUSTIFICACIN SOCIAL101.5.3.JUSTIFICACIN TECNICA111.6.METODOLOGA111.7.APORTES121.8.ALCANCES131.9.ORGANIZACIN DEL DOCUMENTO132.CAPITULO II162.1.ANTECEDENTES DE LA DOCUMENTACIN162.1.1.DEFINICIN DE ARCHIVO172.1.2.DEFINICIN DE DOCUMENTO182.1.2.1.CICLO DE VIDA DE LOS DOCUMENTOS.192.1.2.2.DEFINICIONES BSICAS DE ARCHIVOS202.1.2.3.TRATAMIENTO ARCHIVSTICO21a)IDENTIFICAR21b)CLASIFICAR22c)ARCHIVAR22d)ORDENAR22e)INSTALAR23f)DESCRIBIR24g)MARBETES24h)INVENTARIO24I)TRANSFERENCIA DE DOCUMENTOS25j)PRSTAMO DE DOCUMENTACIN25k)MANIPULACIN26l)ALMACENAMIENTO27m)CONSERVACIN27n)MONITOREO282.2.BASES LEGALES282.2.3.CONSTITUCIN POLTICA DEL ESTADO282.2.4.LEY DE TRANSPARENCIA Y ACCESO A LA INFORMACIN PBLICA292.2.5.DECRETO SUPREMO 23318-A REGLAMENTO DE LA RESPONSABILIDAD POR LA FUNCIN PBLICA.303.CAPITULO III323.1.METODOLOGA R.U.P. (PROCESO UNIFICADO DE RATIONAL).323.1.1.DIMENSIONES DEL RUP333.1.2.CARACTERSTICAS PRINCIPALES DEL RUP343.1.2.1.DIRIGIDO A CASOS DE USO343.1.2.2.CENTRADO EN LA ARQUITECTURA353.1.2.3.ITERATIVO INCREMENTAL363.1.3.FASES DEL RUP383.1.3.1.INICIO383.1.3.2.ELABORACIN393.1.3.3.CONSTRUCCIN403.1.3.4.TRANSICIN403.1.4.FLUJOS DE TRABAJO403.1.4.1.FLUJOS DE TRABAJO DE INGENIERA413.1.4.1.1.MODELADO DE NEGOCIO413.1.4.1.2.REQUISITOS423.1.4.1.3.ANLISIS Y DISEO433.1.4.1.4.IMPLEMENTACIN433.1.4.1.5.PRUEBA443.1.4.1.6.DESPLIEGUE453.1.4.2.FLUJOS DE TRABAJO DE APOYO463.1.4.2.1.ADMINISTRACIN DE PROYECTOS463.1.4.2.2.CONFIGURACIN Y CONTROL DE CAMBIOS463.1.4.2.3.ENTORNO463.2.HERRAMIENTAS PARA EL DESARROLLO DEL PROYECTO473.2.1.UML (LENGUAJE UNIFICADO DE MODELADO)473.2.1.1.BLOQUES DE CONSTRUCCIN DE UML47a)ELEMENTOS ESTRUCTURALES48b)ELEMENTOS DE COMPORTAMIENTO49c)ELEMENTOS DE AGRUPACIN49d)ELEMENTOS DE ANOTACIN50e)RELACIONES EN UML503.2.1.2.DIAGRAMAS UML51a)DIAGRAMA DE CLASES51b)DIAGRAMA DE OBJETOS52c)DIAGRAMA DE CASOS DE USO52d)DIAGRAMA DE SECUENCIA Y DE COLABORACIN52e)DIAGRAMA DE ESTADOS52f)DIAGRAMA DE ACTIVIDADES52g)DIAGRAMA DE COMPONENTES53h)DIAGRAMA DE DESPLIEGUE533.2.2.LENGUAJES DE PROGRAMACIN533.2.2.1.HTML (HIPER TEXT MARKUP LANGUAGE)533.2.2.1.1.ESTRUCTURA DE UN DOCUMENTO HTML543.2.2.2.PHP (HYPERTEXT PREPROCESSOR)543.2.2.2.1.CARACTERSTICAS DE PHP553.2.2.3.JAVA SCRIPT553.2.3.HOJA DE ESTILO563.2.4.SERVIDOR WEB563.2.4.1.XAMP573.2.5.GESTOR DE BASE DE DATOS573.2.5.1.MYSQL573.2.5.1.1.CARACTERSTICAS573.2.6.ISO/IEC 9126 (CALIDAD DE SOFTWARE).583.2.6.1.FUNCIONALIDAD583.2.6.2.FIABILIDAD583.2.6.3.FACILIDAD DE USO583.2.6.4.EFICIENCIA593.2.6.5.FACILIDAD DE MANTENIMIENTO593.2.6.6.PORTABILIDAD594.CAPITULO IV615.CAPITULO V63BIBLIOGRAFA64

CAPITULO IINTRODUCCION

1. CAPITULO IEn este primer captulo se describe en forma general el proyecto de grado, conteniendo la parte de introduccin, antecedentes, los objetivos trazados en base a los problemas identificados de la unidad de archivo central del Gobierno Autnomo Municipal de Cobija, as como los alcances del proyecto y la a metodologa de desarrollo del software.1.1. INTRODUCCIN En un mundo de crecientes avances tecnolgicos, las organizaciones deben estar preparadas y adaptarse a la incorporacin de nuevas tecnologas. Sin duda alguna es una tarea difcil, pero a la vez una situacin que todas las empresas deben asumir y prepararse, de lo contrario corren el riesgo de volverse obsoletas.Los sistemas de informacin representan hoy en da una de las mejores vas por las cules se guan los analistas para innovar y tienen el propsito de optimizar la gestin mediante una adecuada toma de decisiones, usan la informacin y buscan que todos los datos mesurables sean organizados de manera que sea fcil registrarlos, almacenarlos, procesarlos, recuperarlos y comunicarlos, dependiendo de las necesidades requeridas por los usuarios que operan con ellos, obteniendo as un sistema funcional que satisfaga las necesidades que en un determinado momento se requieran.La Unidad de Archivo Central que pertenece al Gobierno Autnomo Municipal de Cobija, debido a la Deficiencia en los servicios de informacin y acceso a la documentacin requerida en la Unidad de Archivo y en busca de inmiscuirse en el mbito tecnolgico y manejar la informacin de manera eficiente y segura se ve en la necesidad de automatizar los procedimientos que se llevan a cabo en esta Unidad. En este sentido el proyecto de grado tiene como objetivo. Desarrollo de un Sistema Informtico de registro y control de documentos, para mejorar los servicios de informacin y acceso a la documentacin resguardada en la Unidad de Archivo Central del Gobierno Autnomo Municipal de Cobija.Sin duda alguna para desarrollar un buen sistema se requiere elegir una metodologa adecuada, ya que estas juegan un papel preponderante en el xito de un proyecto. Para el desarrollo del nuevo sistema propuesto se utiliza como metodologa de desarrollo R.U.P. (Rational Unified Process), cuya traduccin al espaol significa Proceso Unificado de Rational.1.2. ANTECEDENTES El Archivo Central es la unidad responsable de la gestin de documentos cuya consulta es ocasional por parte de las unidades administrativas, y que permanecen en l hasta su destino final, es la encargada de establecer los lineamientos y procedimientos, asegurar su correcto funcionamiento de los documentos en funcin a los requisitos de la propia institucin, en el cual existe un responsable de la Unidad de Archivos, que es el encargado de asentar las polticas y procedimientos para la mejor organizacin de los archivos al interior de la institucin, el mismo depende de la institucin cuenta con un equipo de trabajo de dos personas. (Reglamento de Archivos, 2004).Esta Unidad administra la documentacin en base al reglamento de archivo (Sistema de administracin y control de manipulacin ordenamiento, transferencia y control de documentos), en su versin 1, aprobada por resolucin administrativa N48/2004 del Gobierno Autnomo Municipal de Cobija, la misma establece la estructura organizacional de los archivos del Gobierno Autnomo Municipal de Cobija, las definiciones bsicas y generales para la manipulacin, ordenamiento, la conservacin, transferencia y control de los documentos producidos y recibidos por la municipalidad. Segn registros encontrados en la Unidad de Archivos, Las diferentes direcciones y unidades pertenecientes al Gobierno Autnomo Municipal de Cobija, generan gran cantidad de documentacin la cual transfirieren a la Unidad de Archivo Central. El responsable de esta unidad debe asegurar que se tienen en cuenta los requisitos necesarios para su conservacin a largo plazo.Sin embargo la unidad de archivos, no cuenta con un sistema de informacin que se ocupe del registro y control de la documentacin, se verifica que no cuenta con un registro real de los archivos existentes, el manejo de la documentacin resguardada en esta unidad se realiza de manera manual, entre ellas el registro, bsquedas y control de la documentacin donde el responsable de esta unidad se encuentra con grandes dificultades relacionadas con el manejo, control y bsqueda de un archivo especfico. Se ha visto necesario en la unidad de archivos, debe contar con un sistema de registro y control de documentos, que mejore los servicios de informacin y acceso a la documentacin resguardada en esta Unidad.De acuerdo a la investigacin realizada sobre trabajos similares se puede mencionar los siguientes proyectos: Como por ejemplo tenemos al pas del Per a travs del Ministerio de Educacin con el: Sistema de Informacin de Apoyo a la Administracin Documental y de Archivo SINAD. Este proyecto tiene como objetivo principal: Apoyar a la gestin documental del Ministerio de Educacin y sus dependencias donde sea implementando, permitiendo acceder a la informacin de tiempo real para usuarios y el pblico a travs de un portal web, (Ministerio de Educacion, 2011).La Facultad de Ciencias de la Informtica perteneciente a la Universidad Nueva Esparta de la Repblica Bolivariana de Venezuela Caracas con el: Sistema automatizado para optimizar el registro y control de prstamo de Expedientes en el Archivo del Departamento Legal de la corporacin Palmar, S.A. (CORPALMAR), (Rivas, 2010). La Facultad de Ingeniera de Sistemas perteneciente a la Universidad de Oriente de la Republica de Bolivariana Venezuela Nonagas con el: Sistema Administrativo para la Gestin de Documentos para la GMD de PDVSA Exploracin y Produccin Divisin Oriente bajo plataforma de Software Libre, (Rendon P., 2011).Las investigaciones antes mencionadas son de utilidad al momento de aportar ideas y conceptos con relacin a la administracin de la documentacin.1.3. PLANTEAMIENTO DEL PROBLEMASegn registros y entrevistas orales realizadas al personal de la Unidad de Archivo Central se pudo verificar que: la unidad de archivos no cuenta con una persona especializada en archivos, al finalizar cada gestin las diferentes unidades y direcciones del Gobierno Autnomo Municipal de Cobija realizan la entrega de la documentacin a la unidad de archivo central y esta no cuenta con informes de respaldo de dicha documentacin, no se encontr una lista de chequeo de la documentacin que solicitan, as tambin el libro de registro con el que cuentan no se encontr un inventario real de la documentacin resguardada. De acuerdo al anlisis realizado previamente se define el problema central:Deficiencia en los servicios de informacin y acceso a la documentacin reguardada en la Unidad de Archivo Central del Gobierno Autnomo Municipal de Cobija.Ocasionando de esta manera los siguientes efectos: limitaciones por parte del personal en el acceso a la informacin de la documentacin, retrasos en la elaboracin de informes y reportes, demora en la bsqueda y entrega de la documentacin solicitada, provocando as deficiencia en el control y manejo de informacin de la documentacin reguardada en la Unidad de Archivo Central.1.4. OBJETIVOS1.4.1. OBJETIVO GENERALDesarrollar un Sistema Informtico de registro y control de documentos para la Unidad de Archivo Central del Gobierno Autnomo Municipal de Cobija, aplicando la metodologa R.U.P. (Proceso Unificado de Rational).1.4.2. OBJETIVOS ESPECFICOS Realizar la captura de requerimientos, acumulando la informacin necesaria para hacer realizable el modelado de negocio del sistema mediante diagramas de casos de uso. Definir la arquitectura base del sistema informtico a partir del anlisis de los requerimientos usando la herramienta de UML (Lenguaje Unificado de Modelado) Desarrollar los mdulos del sistema a partir de las especificaciones del modelo de diseo usando el lenguaje de PHP, HTML y Hoja de estilos Css. Realizar las pruebas al sistema para determinar la calidad de software en base a la norma estndar ISO/IEC 9126 (Calidad de Software).1.5. METODOLOGAPara el desarrollo del proyecto de grado se utiliza la metodologa R.U.P., en ingles significa (Rational Unified Process) Proceso Unificado de Racional, el R.U.P. es un producto del proceso de ingeniera de software que proporciona un enfoque disciplinado para asignar tareas y responsabilidades dentro de una organizacin del desarrollo. Su meta es asegurar la produccin del software de alta calidad que resuelve las necesidades de los usuarios dentro de un presupuesto y tiempo establecidos. A continuacin vamos a ver un resumen de las fases de la Metodologa R.U.P., de sus objetivos y de los productos que resultan al aplicar cada una de ellas.FASESDESCRIPCINTECNICAS O HERRAMIENTASPRODUCTOS

INICIOdefinir y acordar el alcance del proyecto con el encargado de la Unidad se propone una visin general de la arquitectura de software Entrevistas con los usuarios. Notacin de U.M.L. Modelado de negocio. Requerimiento de usuario. Identificacin de usuario que interactan con el sistema

ELABORACINSeleccionan los casos de uso que permiten definir la arquitectura base del sistema y se planifica el proyecto considerando recursos disponibles. Notacin de U.M.L. Diagramas de caso de uso. Diagramas de clases, Diagrama de secuencia, Diagrama de paquetes.

CONSTRUCCIN Completar la funcionalidad del sistema y proporcionar un producto construido junto con la documentacin.

El diseo de las clase con el lenguaje PHP5 Las interfaces desarrollados con HTML y Hoja de estilos Css. El diseo de la base de datos MYSQL Modelos Completos (diagramas de Anlisis, Diseo. El desarrollo del software completo Capturar la arquitectura cliente servidor

TRANSICINAsegurar que el software est disponible para los usuarios finales, ajustar los errores y defectos encontrados en las pruebas de aceptacin, capacitar a los usuarios Har el uso del estndar ISO/IEC 9126 (Calidad de Software). Pruebas finales de aceptacin Entrega de software a las institucin Capacitacin a los usuarios finales para la correcta manipulacin del sistema Descripcin de calidad de software

TABLA 1.1: Metodologa R.U.P.FUENTE: Elaboracin Propia

1.6. APORTESEl desarrollo del presente proyecto de grado es importante porque beneficia a la unidad de archivo central, en el acceso y manipulacin de la documentacin que ah se resguarda. Es as el aporte ms importante para esta unidad es la implementacin de un sistema que satisfaga sus necesidades y requerimientos.El proyecto cuenta con un componente adicional de ser un desarrollo que brinda solucin a un problema particular de la Unidad de Archivo Central, de minimizar riesgos referentes al manejo de informacin confidencial ya que se estar asesorado directamente por personal vinculado con la institucin, quedando todo bajo el cuidado de los mismos y asegurando resultados tiles y herramientas acordes a las necesidades existentes.1.7. ALCANCESPara este objeto se pretende conseguir los siguientes alcances: El sistema funcionara en red interna LAN, Tomando en cuenta los requerimientos mnimos de hardware para un buen rendimiento y funcionamiento del sistema se requiere mnimamente una PC Pentium IV, RAM de 512 y Disco Duro 500 GB. El sistema ser compatible con los sistemas operativos Windows XP 32/64 bits o versin superior, GNU Linux, cuenten navegador web Mozilla Firefox o Internet Explorer, Adobe Reader.Para el presente proyecto de grado se tomaron en cuenta aquellas unidades contempladas en el Reglamento de Archivos del Gobierno Autnomo Municipal de Cobija. El sistema de registro y control de documentos para la unidad de archivos, procesara informacin de manera automatizada y digitalizada alcanzando la eficiencia en el manejo de la informacin, comprender los siguientes mdulos funcionales dependiendo del tipo de usuario: Mdulo de Archivo Central: Permitir gestionar las solicitudes sobre registro, lectura, bsqueda o copia de resoluciones y/o antecedentes al rea del Archivo Central. Mdulo de Consultas y Bsquedas: Permitir obtener la informacin del documento consultado. Mdulo De Administracin: Este mdulo permite la configuracin de usuarios, permisos, roles, privilegios. 1.8. ORGANIZACIN DEL DOCUMENTOEl documento se encuentra organizado en cuatro captulos, ninguno de los captulos ha sido desarrollado como un documento independiente. De este modo, se recomienda realizar una lectura secuencial del mismoEn el CAPTULO I (MARCO REFERENCIAL), se exponen las causas por las cuales surge la inquietud de trabajar en el proyecto de grado que tiene como tema SISTEMA DE REGISTRO Y CONTROL DE DOCUMENTOS PARA LA UNIDAD DE ARCHIVO CENTRAL DEL GOBIERNO MUNICIPAL DE COBIJA. As como conocer que es lo que se pretende hacer para llevar a cabo la misma, analizando todo lo relacionado con los problemas y las soluciones propuestas, llegando a establecer objetivos generales y especficos. En el CAPITULO II, se forma el MARCO TERICO, en el mismo expone las bases tericas con las que se sustenta el presente proyecto de grado.En el CAPITULO III, se forma el MARCO METODOLGICO, en el mismo se exponen la metodologa y las herramientas que se usaran para el desarrollo del proyecto de grado.En el CAPITULO IV, es el MARCO APLICATIVO en el cual se describe el desarrollo del proyecto, aplicando cada uno de los procesos definidos en la metodologa. Y por ltimo el CAPITULO V, hace referencia a las CONCLUCIONES Y RECOMENDACIONES, determinada durante el proceso del desarrollo del proyecto.

CAPITULO IIFUNDAMENTOS TEORICOS

2. CAPITULO IIEste captulo contiene fundamentos tericos para investigacin del proyecto de grado, describe diversos antecedentes que suministran aportes de informacin y orientacin acerca definicin sobre la ciencia de la Documentacin, as como las bases legales que respaldan este proyecto.2.1. ANTECEDENTES DE LA DOCUMENTACIN Segn (Rendn Rojas, 2011, pp. 69-80), el trmino Documentacin se refiere a una disciplina acadmica que ha sido objeto de anlisis lingsticos para clarificar su pertinencia e importancia en el campo cientfico.La palabra documento se us por primera vez a finales del siglo XIV, con el significado de ensennamiento o consejo moral. Este significado mantiene su contenido semntico durante los siglos XVI y XVII y es el nico que rescata el Diccionario de Autoridades a comienzos del XVIII. Una centuria ms tarde se agrega una segunda acepcin en el Diccionario de la Real Academia que establece que es [...] la escritura o instrumento en que se prueba o confirma alguna cosa.En publicaciones posteriores (1844) aparecieron las voces derivadas: documentalmente, documentar y documentacin, sin embargo, fue hasta 1914, cuando se otorg a la palabra documentacin un doble sentido: accin y efecto de documentar y conjunto de documentos que sirven para este fin, con esto se legitim el trmino, pero no se le otorg un carcter de disciplina cientfica en los diccionarios, ms bien el de un neologismo, resultado de la traduccin del trmino francs documentation, acuado por Paul Otlet en 1903, quien s le concede el carcter de ciencia y as lo consignan los autores del Webster Dictionary.As, de acuerdo con los acadmicos hispanos, la Documentacin es una ciencia general cuyo objeto es el documento en todas sus facetas y propiedades y que, como la lgica o la lingstica, es tambin auxiliar de otras disciplinas, las cuales deben acatar sus normas en las formas documentales. De acuerdo con Marlery Snchez Daz y Juan Carlos Vega Valds, la documentacin posee un cuerpo sistemtico de conocimientos como: a) ciencia y doctrina; b) tcnica; y c) organizacin. Como ciencia estudia de todos los aspectos del documento, Como tcnica estudia todas las reglas y la instrumentacin relativa a las operaciones de produccin, circulacin, conservacin y uso de los documentos. Finalmente como organizacin estudia la del trabajo individual, institucional y cooperativo relativo al documento en todos los campos.Desde el punto de vista epistemolgico slo la corriente espaola le ha otorgado un carcter de ciencia; Para el caso de las ciencias de la informacin documental resulta pertinente el trmino cobijado bajo la perspectiva espaola de ciencias de la documentacin, en el sentido de que todo documento (libros, revistas, impresas y digitales) constituyen en s un documento y lo nico que las diferencia son las particularidades de sus procesos documentales, pero que, en esencia, coinciden en tres funciones bsicas: el resguardo, el tratamiento y la recuperacin. 2.1.1. CONCEPTUALIZACIN ARCHIVO Una de las teoras sobre la evolucin de la palabra archivo establece su origen en el vocablo latino vulgar archivium que derivara, a su vez, del griego arkein (residencia del arconte) y que designaban, tanto el lugar donde se custodian los documentos como el conjunto de documentos all conservados. Como vemos, ya desde un principio, la idea de "archivo" va ligada a la de Administracin. Las definiciones presentes que se ha seleccionado a continuacin, aunque ms detalladas y ms amplias, vienen a decir prcticamente lo mismo. De entre las definiciones tcnicas, cabe destacar las definiciones dadas por algunas archivistas espaolas. As, Mara Antonia Heredia Herrera los define como ... uno o ms conjuntos de documentos, sea cual sea su fecha, su forma, soporte material, acumulados en un proceso natural por una persona o institucin pblica o privada en el transcurso de su gestin, conservados, respetando aquel orden, para servir como testimonio e informacin para la persona o institucin que los produce, para los ciudadanos o para servir de fuente para la Historia[footnoteRef:1] y Vicenta Corts Alonso define los archivos como ... el conjunto de documentos acumulados en un proceso natural por una persona o institucin pblica o privada, en el transcurso de la gestin de asuntos de cualquier ndole, los producidos y los recibidos, de cualquier fecha, que se conserven y custodien para servir de referencia, como testimonio e informacin, por las personas responsables de tales asuntos y sus sucesores.[footnoteRef:2] [1: HEREDIA HERRERA, Antonia: Archivstica General: teora y prctica. Sevilla: Diputacin Provincial, 1989.] [2: CORTS ALONSO, Vicenta: Manual de archivos municipales. Madrid: ANABAD, 1989]

La Resolucin Municipal del Municipio de Cobija Numero 48/2004, del 15 de Septiembre, del Reglamento de archivos, en su artculo 3.a define al archivo o Deposito Archivstico Es el ambiente fsico donde se concentran los documentos o archivos, por un determinado periodo de tiempo. El Gobierno Municipal de Cobija tiene los depsitos archivsticos de: archivo central y archivo de oficina[footnoteRef:3]. [3: Reglamento de Archivos, 48/2004 (Gobierno Autonomo Municipal de Cobija 15 de Septiembre de 2004).]

Tambin especifica en el artculo 4. La (Estructura orgnica del sistema de archivo del Gobierno Municipal de Cobija). El sistema de archivos del gobierno Municipal de Cobija estar constituido por: los archivos de oficina, los mismos que se ubican en las unidades productoras bsicas de administracin y por el Archivo Central. a) Archivo de oficina: Es el que se forma en la unidad productora de los documentos y corresponde a la primera etapa de los mismos. Su organizacin consiste en respetar la formacin de series documentales en trmite y de frecuente consulta administrativa. La permanencia de estos documentos ser de uno a cinco aos dependiendo del espacio disponible y/o de la tabla de retencin documental o temporalidad. b) Archivo central: El archivo central conservara la documentacin transferida de los archivos de oficina. Los documentos que se conserve en este archivo no excedern de los treinta aos a partir de la produccin de los mismos.2.1.2. CONCEPTUALIZACIN DE DOCUMENTO De una forma genrica se pueden definir un documento como informacin fijada en un soporte. Esta definicin, aunque muy general, incluye los dos elementos constitutivos de cualquier documento: uno interno, la informacin, el contenido del documento, y el otro, el soporte, el medio por el que se transmite y fija ese contenido.No todo documento es documento de archivo o documento administrativo. La Ley de Patrimonio Histrico Espaol define los documentos de archivo como toda expresin en lenguaje natural o convencional y cualquier otra expresin grfica, sonora o en imagen, recogidas en cualquier tipo de soporte material, incluso los informticos. Se excluyen los ejemplares no originales de ediciones. Esta definicin debe ponerse en relacin con la definicin de archivo que vimos anteriormente. No son exactamente toda expresin en lenguaje natural o convencional, etctera, sino esas expresiones en cualquier tipo de soporte reunidas por las personas jurdicas, pblicas o privadas, en el ejercicio de sus actividades. Segn Resolucin Municipal de Cobija 48/2004, de 15 de Septiembre, del Reglamento de archivos, en su artculo 3.a define Documento o Documento Pblico Es el producido o tramitado por el funcionario pblico en el ejercicio de sus funciones. 2.1.2.1. CICLO DE VIDA DE LOS DOCUMENTOS. Segn (Solar Agero, 2011). El ciclo de vida de los documentos es uno de los fundamentos tericos de la archivstica, el cual plantea que los documentos pasan por etapas de vida administrativa que a su vez dan lugar a diferentes niveles de archivo: PRIMERA ETAPA O EDAD: Durante esta etapa el documento es de circulacin y tramitacin por los canales regulares, en busca de respuesta y solucin al asunto o trmite que le ha dado origen y adems hay un manejo frecuente de parte del funcionario responsable de su tramitacin. Esta documentacin forma parte del ARCHIVO LOCAL[footnoteRef:4] y es el archivo de la oficina que rene su documentacin en trmite o sometida a continua utilizacin y consulta administrativa por las mismas oficinas. [4: Denominado tambin en la literatura archivstica como ARCHIVO DE OFICINA, ARCHIVO DE GESTIN o ARCHIVO DE TRAMITACIN.]

SEGUNDA ETAPA O EDAD: Una vez recibida la respuesta o solucin al asunto iniciado, el documento que la sustenta ha de seguir siendo guardado. En este perodo formar parte del ARCHIVO CENTRAL[footnoteRef:5], el cual coordina y controla el funcionamiento de los distintos archivos de gestin, define y entrega los lineamientos de operacin y rene los documentos transferidos por los mismos, una vez finalizado su trmite, y cuando su consulta no es constante. [5: Denominado tambin en la literatura archivstica como ARCHIVO INTERMEDIO o ARCHIVO CENTRAL.]

TERCERA ETAPA O EDAD: Finalmente, en esta etapa el documento adquiere un valor permanente o histrico, restringindose su consulta a su carcter cultural e informativo, principalmente con fines de investigacin. Su almacenamiento y conservacin ser definitivo en el ARCHIVO HISTRICO. 2.1.2.2. DEFINICIONES BSICAS DE ARCHIVOSComment by MFP: Las definiciones bsicas son: Fondo: Conjunto de series documentales pertenecientes a una sola entidad. Seccin: Es la unidad administrativa que en el desarrollo de sus funciones produce un conjunto orgnico de series documentales (ejemplo: despacho de alcalde, oficiala mayor administrativa y financiera oficiala mayor tcnica, direccin administrativa y financiera, etc.). Serie documental: Se denomina as al conjunto de unidades documentales de una institucin o de una unidad de esta, de estructura y contenidos homogneos, emanados de un mismo rgano o sujeto productor como consecuencia del ejercicio de sus especficas funciones (ejemplo: informes, proyectos, carpetas de contratos, etc.). Soporte documental: Material fsico en el que se registra la informacin (ejemplo: papel, medio magntico, etc.). Gestin: Se considera gestin al periodo de doce meses, del 1 de enero al 31 de diciembre de cada ao. Tabla de retencin documental (o de temporalidad): Listado de series, por secciones, en las que se asigna un tiempo de permaneca de los documentos en todas y cada una de las fases de ciclo vital del documento. Estn podrn ser modificadas pero dejando constancia de los motivos adjunto al plan de la unidad de archivo. Tipos documentales: Son las distintas formas de redactar un documento. Por ejemplo son tipos documentales: memorndum, informe, carta, oficio, carpetas de proyectos, etc. Unidad documental: Elemento bsico de una serie documental que puede estar constituido por un solo documento o por varios que formen un expediente (ejemplo: una comunicacin interna o un proyecto). Unidad de instalacin: Material fsico que contiene el documento (cubierta o contenedor) destinado a la colocacin o instalacin de los mismos (ejemplo: archivador de palanca, caja porta documentos, etc.).2.1.2.3. TRATAMIENTO ARCHIVSTICO Es el Conjunto de fases que se deben seguir en forma ordenada y secuencial para la conservacin de un documento a lo largo de su ciclo vital (identificacin, clasificacin, archivar, ordenacin, instalacin, descripcin, inventariar, transferencia, prstamo, manipulacin, almacenamiento, conservacin y monitoreo).a) IDENTIFICAR Es la actividad intelectual a travs del cual se identifica al rgano productor del documento (entidad externa o unidad funcional interna), determinando su estructura administrativa, su funcin y el tipo documental. (Ejemplo: Documento; Carpeta de Proyectos Construccin Poli Funcional La Cruz. Estructura administrativa; Oficiala Mayor Administrativa y Financiera OMAF. Tipo documental: carpeta de proyecto).b) CLASIFICAR Una vez efectuada pertinentemente la identificacin se procede a la clasificacin que consiste en la separacin de los documentos formando series documentales, considerando la estructura organizacional y jerrquica del gobierno municipal de cobija.(Ejemplo: Documento; carpeta de proyecto). El informe se separa dela correspondencia, hojas de ruta y otros documentos formando la serie documental carpeta de proyectos.c) ARCHIVAR Clasificados los documentos, se proceder a archivar los mismos, actividad que consista en ubicar cada documento en el deposito archivstico que corresponda. En archivo de oficina y en archivo central se deber verificar que solo existan documentos, de acuerdo a los programas de transferencia correspondiente y consideracin los plazos de permeancia contemplados en la tabla de retencin documental o de temporalidad. (Ejemplo: Documento; carpeta de proyecto). Siendo que el proyecto ha sido ejecutado en la gestin 2003, corresponde conservarlo en el archivo de oficina segn corresponda y no en archivo central.d) ORDENAR Ya ubicados los documentos en cada archivo (deposito archivstico), se proceden a ordenar, actividad que consiste en insertar cada documento dentro de una serie documental, de acuerdo a un orden convenido segn el criterio que resulte mas cmodo para la localizacin y recuperacin de los documentos, que podr ser cualquiera de los siguientes. Orden geogrfico: Por departamento, provincia, etc. Orden cronolgico: por fecha del documento, pudiendo considerarse el da, mes y ao, el mes y ao o solo el ao, debiendo archivarse lo ms antiguos atrs y los ms recientes adelante Orden alfabtico-institucional: considerando el nombre de la institucin. Orden correlativo: de acuerdo al cdigo del documentoe) INSTALAR La ubicacin fsica o estante de las series de informes, carpeta de proyectos, comprobantes contables, etc., garantiza la conservacin, el orden y control de los documentos que genera el Gobierno Municipal de Cobija y busca facilitar la ubicacin y el prstamo oportuno.Existirn dos formas de instalacin que se aplicara de acuerdo a las necesidades de cada archivo y estas son: Los documentos se instalaran de izquierda a derecha, ubicando los documentos de gestiones anteriores en las filas superiores, y los documentos de gestiones ms recientes en filas inferiores, o viceversa, buscando la comodidad y facilidad de ubicacin. Los documentos se instalaras de arriba hacia abajo, empezando de las gestiones ms antiguas y acabando en las ms recientes. Se llenaran por filas de izquierda a derecha, por columnas de izquierda a derecha y por estantes.La identificacin de la estantera ser la siguiente:Estantes: 1, 2, 3, etc.Columnas: A, B, C, etc. En la gaveta solo existe una columna.Filas: 1, 2, 3, etc.Ejemplo: Ubicacin: Estante/Columna /Fila (1/A/1).

Estante N 1Columna AColumna BColumna c Columna D

Fila 11/A/11/B/11/C/11/D/1

Fila 21/A/21/B/21/C/2

Fila 31/A/31/B/3

Fila 41/A/41/B/4

Fila 51/A/51/B/5

Fila 61/A/61/B/6

f) DESCRIBIR Se deber elaborar los instrumentos de referencia e informacin para facilitar el conocimiento, control y consulta de los documentos. La descripcin de los documentos. La descripcin de los documentos contempla una serie de actividades que se inicia con la descripcin del contenido de las cajas o archivadores de palancas en marbetes prediseados, en inventarios y solo para el archivo central (Una vez, concluida su organizacin) guas de descripcin.g) MARBETES Los marbetes se aplicaran a las cajas porta documentos, a los archivadores de palanca y otros contenedores, para tener una referencia sobre los documentos contenidos en ellos, y se especificara claramente el fondo, la seccin, la serie y la gestin segn la pertinencia de los documentos contenidos en ellos y se especificara claramente el fondo, la seccin, las series y la gestin segn la pertenencia de los documentos (Ejemplo: fondo; GAMC[footnoteRef:6] secciones; despacho de alcalde, OMAF[footnoteRef:7], OMT[footnoteRef:8], DAF[footnoteRef:9], etc., series; informes, correspondencia, carpeta de proyectos, etc. ; la gestin 2002, 2003, etc. ). Adems se podr registrar otra informacin que sea de utilidad para la fcil ubicacin de los documentos. [6: G.A.M.C.: Gobierno Autnomo Municipal De Cobija.] [7: O.M.A.F.: Oficiala Mayor De Desarrollo Humano del Gobierno Autnomo Municipal de Cobija.] [8: O.M.T.: Oficiala Mayor Tcnica del Gobierno Autnomo Municipal de Cobija.] [9: D.A.F.: Direccin Administrativa Y Financiera del Gobierno Autnomo Municipal de Cobija.]

h) INVENTARIO Es una relacin o ms o menos detallada, en la que se describen todos los documentos que conserva cada archivo, siguiendo su organizacin en series documentales (Ejemplo: correspondencia y su detalle, informes y su detalle, carpeta de proyectos y su detalle, etc.) utilizando para este efecto el formato otros datos que las unidades consideren necesario. Solo se elaboran los inventarios en el archivo central y de oficina.I) TRANSFERENCIA DE DOCUMENTOS Es el procedimiento habitual de ingreso y salida documental de y hacia los diferentes depsitos archivsticos, debido al cumplimiento de los plazos de retencin o por criterios de mejor aprovechamiento de espacio de los depsitos archivsticos. En este contexto se tienen las transferencias internas que son: primero, aquellas en la que trasfieren documentos de los archivos de oficina al central.Anualmente las unidades de archivo, en coordinacin con O.M.A.F.[footnoteRef:10] elaboraran un cronograma de transferencias internas que figuran en el plan nacional de organizacin y archivo de la unidad de archivo respectivo, estas transferencias estarn programadas para llevarse a cabo en el primer semestre de cada ao. [10: O.M.A.F.: Oficiala Mayor Financiera y Administrativa del Gobierno Autnomo Municipal de Cobija.]

En el proceso de transferencia, el responsable de archivo remitente, deber entregar los documentos bajo dos criterios: a) que hayan cumplido los plazos de permaneca y/o b) por criterios de falta o mejor aprovechamiento del espacio. El responsable de archivo remitente deber acompaar a los documentos entregados el formulario de transferencia debidamente registrado. Formulario F-RA-002.El responsable del archivo receptor deber asegurar el espacio necesario de almacenamiento y verificar que el registro de transferencias este conforme a los documentos recibidos.Una vez que el archivo receptor confirma la aceptacin del ingreso de los documentos. El archivo remitente quedara eximido de la responsabilidad de los mismos.j) PRSTAMO DE DOCUMENTACINEs el movimiento interno y de salida temporal de los documentos con fines administrativos. Solo los funcionarios de la institucin accedern al prstamo y, para tal efecto, cumplirn los siguientes requisitos:Los funcionarios responsables de los archivos de oficina y central efectuaran: El llenado del formulario F-RA-003. La verificacin de la firma del solicitante en el momento del prstamo. Verificar, en general, las condiciones del o de los documentos antes y despus de cada prstamo. Sellar con el rotulo de devuelto, a la devolucin del mismo. Los responsables de archivo central y de oficina, elaboraran adems una lista mensual del control de todos los prstamos pendientes, requiriendo la devolucin de los mismos. En caso de no ser posible aun la devolucin esta quedara pendiente hasta el prximo mes.Los funcionarios que accedan a los documentos estn obligados a: Firmar como constancia la recepcin del documento solicitado en prstamo. Cumplir con todas la exigencias del presente reglamento referidas a la manipulacin de documentos. Responder por el buen tratamiento de los documentos y dems materiales que se le suministre.Los archivos de gestin podrn no sujetarse al formato del formulario F-RA-003. En caso de no hacerlo, deberan al menos llevar un registro en el que conste al menos de: Datos del solicitante Fecha de prstamo Firma de recepcink) MANIPULACIN La manipulacin o manejo de los documentos en los diferentes archivos del Gobierno Municipal de Cobija, se realiza desde el momento del ingreso de estos, hasta su almacenamiento, pasando por las fases de clasificacin, archivo, ordenacin, trasferencia y prstamo.Para manipular los documentos en el gobierno municipal de cobija deben seguirse las siguientes reglas: Deben mantenerse completo, vale decir que no se separan las hojas, y en su caso si adjunta anexos, estos deben mantenerse unidos, respetando el principio de unidad. No se efectuaran anotaciones, no borrones que puedan alterar el contenido del mismo. No se remplazar el original por fotocopias No se adjuntara documentos que no correspondan al documento.En las transferencias, una vez que el archivo receptor confirma la aceptacin del ingreso de los documentos, el archivo remitente queda eximido dela responsabilidad de los mismos.Durante el prstamo, la responsabilidad por el documento se transfiere momentneamente al solicitante del prstamo y al usuario del documento, mientras lo conserve en su poder.l) ALMACENAMIENTO Es la actividad de reunir y conservar los documentos en un depsito archivstico determinado, bajo las condiciones adecuadas y en la forma establecida en las fases de identificacin, clasificacin, ordenacin y archivo del tratamiento archivstico.El almacenamiento de los documentos del Gobierno Municipal de Cobija se efectuara considerando los plazos de permanencia en cada uno de ellos y el ordenamiento que ms se adecue a la estructura administrativa de la unidad. m) CONSERVACINEs el conjunto de actividades infraestructurales establecidos con el fin de asegurar la preservacin de los documentos en buenas condiciones fsicas.Los depsitos de los archivos cumplirn en lo posible con las siguientes caractersticas:Los ambientes sern seguros y contaran con puertas y ventanas que garanticen en lo mnimo la seguridad de los documentos frente a riesgos externos, como el ingreso de personas no autorizadas (para evitar hurto), y el ingreso de insectos y roedores (para evitar los destrozos de los documentos).Se instalara estantera metlica y/o de madera y pondrn especial cuidado en el orden y el control del espacio tomando en cuenta la capacidad, iluminacin, ventilacin y facilidad de movimiento.El archivo central contara con un extinguidor de fuego en el ambiente donde funcione.n) MONITOREO Semestralmente los responsables del archivo central y de oficina, efectuaran una inspeccin para verificar que los documentos se encuentran en buen estado y no hayan sufrido daos o deterioros y tomar las acciones correctivas de la documentacin daada.2.2. BASES LEGALES2.2.3. CONSTITUCIN POLTICA DEL ESTADOSegn el Artculo 237. Son obligaciones para el ejercicio de la funcin pblica: 1. Inventariar y custodiar en oficinas pblicas los documentos propios de la funcin pblica, sin que puedan sustraerlos ni destruirlos. La ley regular el manejo de los archivos y las condiciones de destruccin de los documentos pblicos.Segn el Artculo 130. Toda persona individual o colectiva que crea estar indebida o ilegalmente impedida de conocer, objetar u obtener la eliminacin o rectificacin de los datos registrados por cualquier medio fsico, electrnico, magntico o informtico, en archivos o bancos de datos pblicos o privados, o que afecten a su derecho fundamental a la intimidad y privacidad personal o familiar, o a su propia imagen, honra y reputacin, podr interponer la Accin de Proteccin de Privacidad.2.2.4. LEY DE TRANSPARENCIA Y ACCESO A LA INFORMACIN PBLICASegn el Artculo 1. (Objeto). La presente Ley tiene por objeto: a) Regular el derecho de toda persona de acceder a la informacin pblica, as como los mecanismos para hacer efectivo su ejercicio.b) Garantizar a toda persona el acceso a la informacin generada en los poderes del Estado y las instituciones o entidades de su dependencia, as como las personas comprendidas en el mbito de aplicacin de esta Ley.c) Establecer normas de proteccin de los datos personales en posesin de las entidades del sector pblico. d) Determinar los procedimientos ante la administracin pblica, para el acceso a la informacin que curse en su poder.Segn el Artculo 3.- (Obligacin de informar).Toda informacin generada o conservada en cualquier institucin del sector pblico, adquiere la calidad de pblica con alcance a las entidades a las que hace referencia el artculo 2; consecuentemente, los responsables de la informacin, tienen la obligacin de informar a las personas peticionarias, conforme las disposiciones de esta Ley.Segn el Artculo 4.- (Legitimacin). Toda persona natural o jurdica, pblica o privada, tiene derecho a solicitar y recibir la informacin de las personas comprendidas en el mbito de aplicacin de la presente Ley.Segn el Artculo 12.- (Derecho de acceso a la informacin). El acceso a la informacin constituye un derecho de toda persona natural o jurdica, a cuyo fin las personas comprendidas en el mbito de aplicacin de la presente Ley debern otorgar facilidades para la atencin oportuna, eficiente y eficaz.2.2.5. DECRETO SUPREMO 23318-A REGLAMENTO DE LA RESPONSABILIDAD POR LA FUNCIN PBLICA.Segn el Artculo 5 (Transparencia). El desempeo transparente de funciones por los servidores pblicos, base de la credibilidad de sus actos, involucra: a) Preservar y permitir en todo momento el acceso a esta informacin a sus superiores jerrquicos y a las personas encargadas tanto de realizar el control interno o externo posterior, como de verificar la eficacia y confiabilidad del sistema de informacinb) Proporcionar informacin ya procesada a toda persona individual o colectiva que la solicite y demuestre un legtimo inters.

CAPITULO IIIMARCO METODOLOGICO

3. CAPITULO IIIEste captulo hace referencia a la Metodologa RUP utilizado para el anlisis y diseo del sistema, tambin se menciona las herramientas a utilizar para el desarrollo tales como UML (Lenguaje de Modelado Unificado), otras herramientas tecnolgicas como el lenguaje de programacin en PHP, HTML, estilos, JavaScript y otros. 3.1. METODOLOGA R.U.P. (PROCESO UNIFICADO DE RATIONAL).Las metodologas y estndares utilizados en un desarrollo de software nos proporcionan las guas para poder conocer todo el camino a recorrer desde antes de empezar la implementacin, con lo cual se asegura la calidad del producto final, as como tambin el cumplimiento en la entrega del mismo en un tiempo estipulado.La metodologa RUP nos proporciona disciplinas en las cuales se encuentran artefactos con lo cual se podr contar con guas para poder documentar e implementar de una manera fcil y eficiente, todas las guas para un buen desarrollo, todo esto dentro de las respectivas fases con las cuales cuenta.Las siglas RUP en ingles significa Rational Unified Process (Proceso Unificado de Racional) es un producto del proceso de ingeniera de software que proporciona un enfoque disciplinado para asignar tareas y responsabilidades dentro de una organizacin del desarrollo. Su meta es asegurar la produccin del software de alta calidad que resuelve las necesidades de los usuarios dentro de un presupuesto y tiempo establecidos. Segn (Grady , Rumbaugh, & Jacobson, 2000), El nombre Proceso Unificado se usa para describir el proceso genrico que incluye aquellos elementos que son comunes a la mayora de los refinamientos existentes. Tambin permite evitar problemas legales ya que Proceso Unificado de Rational o RUP son marcas registradas por IBM (desde su compra de Rational Software Corporation en 2003).Segn Grady Booch (2000)[footnoteRef:11] un reflejo de lo que hemos visto en el trabajo con literalmente decenas de miles de proyectos en los ltimos 20 aos, la codificacin de lo que funciona en las organizaciones exitosas y lo que est notablemente ausente en los fallidos. [11: Grady Booch, diseador de software, un metodologista de software y entusiasta de diseo de patrones. Es director cientfico de Rational Software (ahora parte de IBM) y editor de una serie de Benjamin/Cummings.]

3.1.1. DIMENSIONES DEL RUPLa metodologa R.U.P. tiene dos dimensiones:Eje horizontal: Representa tiempo, demuestra los aspectos dinmicos del ciclo de vida del proceso y se expresa en trminos de fases, de iteraciones, y la finalizacin de las fases.Eje vertical: Representa el aspecto esttico del proceso: cmo se describe en trminos de componentes de proceso, las disciplinas, las actividades, los flujos de trabajo, los artefactos, y los roles.En la figura 3.1 se puede observar como vara el nfasis de cada disciplina en un cierto plazo en el tiempo, y durante cada una de las fases. Por ejemplo, en iteraciones tempranas, pasamos ms tiempo en requerimientos, y en las ltimas iteraciones pasamos ms tiempo en poner en prctica la realizacin del proyecto en s.Figura 3.1 : Disciplinas, fases, iteraciones del RUP FUENTE: (Quispe Carita, 2011).

3.1.2. CARACTERSTICAS PRINCIPALES DEL RUP 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.3.1.2.1. DIRIGIDO A CASOS DE USOLas actividades de desarrollo bajo el Proceso Unificado de Rational estn dirigidas por los casos de uso. El Proceso Unificado de Rational pone un gran nfasis en la construccin de sistemas basadas en una amplia comprensin de cmo se utilizara el sistema que se entregue. Las nociones de los casos de uso y los escenarios se utilizan para guiar el flujo de procesos desde la captura de los requisitos hasta las pruebas, y para proporcionar caminos que se puedan reproducir durante el desarrollo del sistema.Segn Kruchten, P. (2000), los Casos de Uso son una tcnica de captura de requisitos que fuerza a pensar en trminos de importancia para el usuario y no slo en trminos de funciones que sera bueno contemplar. Se define un Caso de Uso como un fragmento de funcionalidad del sistema que proporciona al usuario un valor aadido. 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 3.2.figura 3.2 : Los Casos de Uso integran el trabajoFUENTE: (Quispe Carita, 2011)

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 3.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.3.1.2.2. CENTRADO EN LA ARQUITECTURAEl desarrollo bajo el proceso unificado de Rational est centrado en la arquitectura. El proceso se centra en establecer al principio una arquitectura software que gua el desarrollo del sistema. Tener una arquitectura robusta facilita el desarrollo en paralelo, minimiza la repeticin de trabajos e incrementa la probabilidad de reutilizacin de componentes y el mantenimiento posterior del sistema. Este sistema arquitectnico sirve como una slida base sobre la cual se puede planificar y manejar el desarrollo de software basado en componentes.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 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, los Casos 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.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 iniciales 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.3 : Evolucin de la Arquitectura del SistemaFUENTE: (Quispe Carita, 2011)

3.1.2.3. ITERATIVO INCREMENTAL Segn (Grady , Rumbaugh, & Jacobson, El Proceso Unificado de Desarrollo de Software, 2000), el equilibrio correcto entre los Casos de Uso y la arquitectura es algo muy parecido 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 3.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.figura 3.4 : Una iteracin RUPFUENTE: (Quispe Carita, 2011)

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 la iteracin 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.3.1.3. FASES DEL RUP El ciclo de vida del software del RUP se descompone en cuatro fases secuenciales (figura 3.5). En cada extremo de una fase se realiza una evaluacin (actividad: Revisin del ciclo de vida de la finalizacin de fase) para determinar si los objetivos de la fase se han cumplido. Una evaluacin satisfactoria permite que el proyecto se mueva a la prxima fase.Figura 3.5: Fases del R.U.P.FUENTE: (Quispe Carita, 2011)

El ciclo de vida consiste en una serie de ciclos, cada uno de los cuales produce una nueva versin del producto, cada ciclo est compuesto por fases y cada una de estas fases est compuesta por un nmero de iteraciones, estas fases son:3.1.3.1. INICIO Durante la fase de inicio, se desarrolla una descripcin del producto final a partir de una buena idea y se presenta el anlisis de negocio para el producto. Esencialmente esta fase responde a las siguientes preguntas: Cules son las principales funciones del sistema para sus usuarios ms importantes? , Cmo podra ser la arquitectura del sistema? y Cul es el plan del proyecto y cuanto costara desarrollar el producto? La respuesta a la primera pregunta se encuentra en un modelado de casos de uso simplificado que contenga los casos de uso ms crticos. Cuando lo tengamos, la arquitectura es provisional, y consiste tpicamente en un diseo que muestra los subsistemas ms importantes. En esta fase, se identifican y priorizan los riesgos ms importantes, se planifica en detalle la fase de elaboracin, y se estima el proyecto de manera aproximada.3.1.3.2. ELABORACIN Durante la fase de elaboracin, se especifican en detalle la mayora de los casos de uso del producto y se disea la arquitectura del sistema. La relacin entre la arquitectura del sistema y el propio sistema es primordial. Una manera simple de expresarlo es decir que la arquitectura es anloga al esqueleto cubierto por la piel pero con muy poco musculo (el software) entre los huesos y la piel solo el necesario para permitir que el esqueleto haga movimiento bsico. El sistema es el cuerpo entero con esqueleto, piel, y msculos.Por tanto, la arquitectura se expresa en forma de vistas de todo los modelos del sistema, los cuales conjunto representan al sistema entero. Esto implica que hay vistas arquitectnicas del modelo de casos de uso, del modelo de anlisis, del modelo de diseo, del modelo de implementacin y modelo de despliegue. La vista del modelo de implementacin incluye componente para probar que la arquitectura es ejecutable. Durante esta fase del desarrollo, se realizan los casos de uso ms crticos que se identificaron en la fase de comienzo. El resultado de esta fase es una lnea base de la arquitectura.Al final de la fase de elaboracin, el director de proyecto est en disposicin de planificar las actividades y estimar los recursos necesarios para terminar el proyecto. Aqu la cuestin fundamental es: son suficientemente estables los casos de uso, la arquitectura y el plan, y estn los riegos suficientemente controlados como para que seamos capaces de comprometernos al desarrollo entero mediante un contrato? 3.1.3.3. CONSTRUCCIN Durante la fase de construccin se crea el producto, se aaden los productos (software terminado) al esqueleto (la arquitectura). En esta fase, la lnea base de la arquitectura crece hasta convertirse en el sistema completo. La descripcin evolucionada hasta convertirse en un producto preparado para ser entregado a la comunidad de usuarios. El grueso de los recursos requeridos se emplea durante esta fase del desarrollo. Sin embargo, la arquitectura del sistema es estable aunque los desarrolladores pueden descubrir formas mejores de estructurar el sistema. Ya que los arquitectos recibirn sugerencia de cambio arquitectnico de menor importancia. Al final de esta fase el producto contiene todos los casos de uso que la direccin y el cliente han acordado para el desarrollo de esta versin. Sin embargo puede que no est completamente libre de defectos. Muchos de estos defectos se descubrirn y solucionaran durante la fase de transicin. La pregunta decisiva es: cubre el producto las necesidades de algunos usuarios de manera suficiente como para hacer una primera entrega?.3.1.3.4. TRANSICIN La fase de transicin cubre el periodo durante el cual el producto se convierte en versin beta. En la versin beta un nmero reducido de usuarios con experiencia prueba el producto e informa de defectos y deficiencias. Los desarrolladores corrigen los problemas e incorporan algunas de las mejoras sugeridas en una versin general dirigida a la totalidad de la comunidad de usuarios. La fase de transicin conlleva actividades como la fabricacin, formacin del cliente, el proporcionar una lnea de ayuda y asistencia, y la correccin de los defectos que se encuentren tras la entrega. El equipo de mantenimiento suele dividir esos defectos en dos categoras: los que tienen suficiente impacto en la operacin para justificar una versin incrementada (versin delta) y los que pueden corregirse en la siguiente versin normal. 3.1.4. FLUJOS DE TRABAJO Las disciplinas conllevan los flujos de trabajo, los cuales son una secuencia de pasos para la culminacin de cada disciplina, estas disciplinas se dividen en dos grupos: las primarias y las de apoyo. Las primarias son las necesarias para la realizacin de un proyecto de software, aunque para proyectos no muy grandes se pueden omitir algunas; entre ellas se tienen: Modelado del Negocio, Requerimientos, Anlisis y Diseo, Implementacin, Pruebas, Despliegue. Las de apoyo son las que como su nombre lo indica sirven de apoyo a las primarias y especifican otras caractersticas en la realizacin de un proyecto de software; entre estas se tienen: Entorno, Gestin del Proyecto, Gestin de Configuracin y Cambios. A continuacin se describe rpidamente cada una de estas disciplinas.3.1.4.1. FLUJOS DE TRABAJO DE INGENIERA3.1.4.1.1. MODELADO DE NEGOCIOCon este flujo de trabajo pretendemos llegar a un mejor entendimiento de la organizacin donde se va a implantar el producto.Los objetivos del modelado de negocio son: Entender la estructura y la dinmica de la organizacin para la cual el sistema va ser desarrollado (organizacin objetivo). Entender el problema actual en la organizacin objetivo e identificar potenciales mejoras. Asegurar que clientes, usuarios finales y desarrolladores tengan un entendimiento comn de la organizacin objetivo. Derivar los requisitos del sistema necesarios para apoyar a la organizacin objetivo.Para lograr estos objetivos, el modelo de negocio describe como desarrollar una visin de la nueva organizacin, basado en esta visin se definen procesos, roles y responsabilidades de la organizacin por medio de un modelo de Casos de Uso del negocio y un Modelo de Objetos del Negocio. Complementario a estos modelos, se desarrollan otras especificaciones tales como un Glosario.3.1.4.1.2. REQUISITOS Este es uno de los flujos de trabajo ms importantes, porque en l se establece qutiene que hacer exactamente el sistema que construyamos. En esta lnea los requisitos son el contrato que se debe cumplir, de modo que los usuarios finales tienen que comprender y aceptar los requisitos que especifiquemos.Los objetivos del flujo de datos Requisitos son: Establecer y mantener un acuerdo entre clientes sobre lo que el sistema podra hacer. Proveer a los desarrolladores un mejor entendimiento de los requisitos del sistema. Definir el mbito del sistema. Proveer una base para la planeacin de los contenidos tcnicos de las iteraciones. Proveer una base para estimar costos y tiempo de desarrollo del sistema. Definir una interfaz de usuarios para el sistema, enfocada a las necesidades y metas del usuario.Los requisitos se dividen en dos grupos. Los requisitos funcionales representan la funcionalidad del sistema. Se modelan mediante diagramas de Casos de Uso. Los requisitos no funcionales representan aquellos atributos que debe exhibir el sistema, pero que no son una funcionalidad especfica. Por ejemplo requisitos de facilidad de uso, fiabilidad, eficiencia, portabilidad, etc.Para capturar los requisitos es preciso entrevistar a todos los interesados en el proyecto, no slo a los usuarios finales, y anotar todas sus peticiones. A partir de ellas hay que descubrir lo que necesitan y expresarlo en forma de requisitos.En este flujo de trabajo, y como parte de los requisitos de facilidad de uso, se disea la interfaz grfica de usuario. Para ello habitualmente se construyen prototipos de la interfaz grfica de usuario que se contrastan con el usuario final.3.1.4.1.3. ANLISIS Y DISEOEl objetivo de este flujo de trabajo es traducir los requisitos a una especificacin que describe cmo implementar el sistema.Los objetivos del anlisis y diseo son: Transformar los requisitos al diseo del futuro sistema. Desarrollar una arquitectura para el sistema. Adaptar el diseo para que sea consistente con el entorno de implementacin, diseando para el rendimiento.El anlisis consiste en obtener una visin del sistema que se preocupa de ver qu hace, de modo que slo se interesa por los requisitos funcionales. Por otro lado el diseo es un refinamiento del anlisis que tiene en cuenta los requisitos no funcionales, en definitiva cmo cumple el sistema sus objetivos.Al principio de la fase de elaboracin hay que definir una arquitectura candidata: crear un esquema inicial de la arquitectura del sistema, identificar clases de anlisis y actualizar las realizaciones de los Casos de Uso con las interacciones de las clases de anlisis. Durante la fase de elaboracin se va refinando esta arquitectura hasta llegar a su forma definitiva. En cada iteracin hay que analizar el comportamiento para disear componentes. Adems si el sistema usar una base de datos, habr que disearla tambin, obteniendo un modelo de datos.El resultado final ms importante de este flujo de trabajo ser el modelo de diseo. Consiste en colaboraciones de clases, que pueden ser agregadas en paquetes y subsistemas.Otro producto importante de este flujo es la documentacin de la arquitectura de software, que captura varias vistas arquitectnicas del sistema.3.1.4.1.4. IMPLEMENTACIN En este flujo de trabajo se implementan las clases y objetos en ficheros fuente, binarios, ejecutables y dems. Adems se deben hacer las pruebas de unidad: cada implementador es responsable de probar las unidades que produzca. El resultado final de este flujo de trabajo es un sistema ejecutable.En cada iteracin habr que hacer lo siguiente: Planificar qu subsistemas deben ser implementados y en qu orden deben ser integrados, formando el Plan de Integracin. Cada implementador decide en qu orden implementa los elementos del subsistema. Si encuentra errores de diseo, los notifica. Se prueban los subsistemas individualmente. Se integra el sistema siguiendo el plan.La estructura de todos los elementos implementados forma el modelo de implementacin. La integracin debe ser incremental, es decir, en cada momento slo se aade un elemento. De este modo es ms fcil localizar fallos y los componentes se prueban ms a fondo. En fases tempranas del proceso se pueden implementar prototipos para reducir el riesgo. Su utilidad puede ir desde ver si el sistema es viable desde el principio, probar tecnologas o disear la interfaz de usuario. Los prototipos pueden ser exploratorios (desechables) o evolutivos. Estos ltimos llegan a transformarse en el sistema final.3.1.4.1.5. PRUEBAEste flujo de trabajo es el encargado de evaluar la calidad del producto que estamos desarrollando, pero no para aceptar o rechazar el producto al final del proceso de desarrollo, sino que debe ir integrado en todo el ciclo de vida.Esta disciplina brinda soporte a las otras disciplinas. Sus objetivos son: Encontrar y documentar defectos en la calidad del software. Generalmente asesora sobre la calidad del software percibida. Provee la validacin de los supuestos realizados en el diseo y especificacin de requisitos por medio de demostraciones concretas. Verificar las funciones del producto de software segn lo diseado. Verificar que los requisitos tengan su apropiada implementacin.Las actividades de este flujo comienzan pronto en el proyecto con el plan de prueba (el cual contiene informacin sobre los objetivos generales y especficos de las prueba en el proyecto, as como las estrategias y recursos con que se dotar a esta tarea), o incluso antes con alguna evaluacin durante la fase de inicio, y continuar durante todo el proyecto.El desarrollo del flujo de trabajo consistir en planificar que es lo que hay que probar, disear cmo se va a hacer, implementar lo necesario para llevarlos a cabo, ejecutarlos en los niveles necesarios y obtener los resultados, de forma que la informacin obtenida nos sirva para ir refinando el producto a desarrollar.3.1.4.1.6. DESPLIEGUE El objetivo de este flujo de trabajo es producir con xito distribuciones del producto y distribuirlo a los usuarios. Las actividades implicadas incluyen: Probar el producto en su entorno de ejecucin final. Empaquetar el software para su distribucin. Distribuir el software. Instalar el software. Proveer asistencia y ayuda a los usuarios. Formar a los usuarios y al cuerpo de ventas. Migrar el software existente o convertir bases de datos.Este flujo de trabajo se desarrolla con mayor intensidad en la fase de transicin, ya que el propsito del flujoes asegurar una aceptacin y adaptacin sin complicaciones del software por parte de los usuarios. Su ejecucin inicia en fases anteriores, para preparar el camino, sobre todo con actividades de planificacin, en la elaboracin del manual de usuario y tutoriales.3.1.4.2. FLUJOS DE TRABAJO DE APOYO 3.1.4.2.1. ADMINISTRACIN DE PROYECTOS La Gestin del proyecto es el arte de lograr un balance al gestionar objetivos, riesgos y restricciones para desarrollar un producto que sea acorde a los requisitos de los clientes y los usuarios.Los objetivos de este flujo de trabajo son: Proveer un marco de trabajo para la gestin de proyectos de software intensivos. Proveer guas prcticas realizar planeacin, contratar personal, ejecutar y monitorear el proyecto. Proveer un marco de trabajo para gestionar riesgos.La planeacin de un proyecto posee dos niveles de abstraccin: un plan para las fases y un plan para cada iteracin.3.1.4.2.2. CONFIGURACIN Y CONTROL DE CAMBIOS La finalidad de este flujo de trabajo es mantener la integridad de todos los artefactos que se crean en el proceso, as como de mantener informacin del proceso evolutivo que han seguido.3.1.4.2.3. ENTORNO La finalidad de este flujo de trabajo es dar soporte al proyecto con las adecuadas herramientas, procesos y mtodos. Brinda una especificacin de las herramientas que se van a necesitar en cada momento, as como definir la instancia concreta del procesoque se va a seguir.En concreto las responsabilidades de este flujo de trabajo incluyen: Seleccin y adquisicin de herramientas Establecer y configurar las herramientas para que se ajusten a la organizacin. Configuracin del proceso. Mejora del proceso. Servicios tcnicos.El principal artefacto que se usa en este flujo de trabajo es elcaso de desarrolloque especfica para el proyecto actual en concreto, como se aplicar el proceso, que productos se van a utilizar y cmo van a ser utilizados. Adems se tendrn que definir lasguas para los distintos aspectos del proceso, como pueden ser el modelado del negocio y los Casos de Uso, para la interfaz de usuario, el diseo, la programacin, el manual de usuario.3.2. HERRAMIENTAS PARA EL DESARROLLO DEL PROYECTO3.2.1. UML (LENGUAJE UNIFICADO DE MODELADO)Segn (Grady, Rumbaugh, & Jacobson, 2006) , E Lenguaje de Modelado unificado (Unifed Modeling Language) es un lenguaje estndar para escribir planos de software. UML puede utilizarse para visualizar, especificar, construir y documentar los artefactos de un sistema que involucre una gran cantidad de software. Visualizar: permite expresar de una forma grfica un sistema de forma que otro le pueda entender. Especificar: permite especificar cules son las caractersticas de un sistema antes de su construccin. Construir: a partir de los modelos especificados se pueden construir los sistemas diseados. Documentar: los propios elementos grficos sirven como documentacin del sistema desarrollado que pueden servir para su futura revisin.3.2.1.1. BLOQUES DE CONSTRUCCIN DE UML A continuacin se van a describir todos los elementos que componen los bloques estructurales de UML, as como su notacin, para que nos sirva de introduccin y se vaya generando un esquema conceptual sobre UML. Existen cuatro tipos de bloques a los que llamaremos elementos: elementos estructurales, elementos de comportamiento, elementos de agrupacin, elementos de anotacin. a) ELEMENTOS ESTRUCTURALESLos elementos estructurales son los nombres los nombres de los modelos UML. En su mayora son la parte esttica de un modelo, y representan conceptos o cosas materiales y se denominan clasificadores.ELEMENTODESCRIPCINREPRESENTACIN GRAFICA

ClaseEs una descripcin de un conjunto de objetos que comparten los mismos atributos, operaciones, relaciones y semntica. Una clase implementa una o ms interfaces y se representa con un rectngulo que incluye su nombre, sus atributos y sus operaciones

Interfaz Es una coleccin de operaciones que especifican un servicio de una determinada clase o componente, describe el comportamiento visible externamente de ese elemento y se representa con in crculo.

Colaboracin Define una interaccin y es una sociedad de roles y otros elementos que colaboran para proporcionar un comportamiento cooperativo mayor que la suma de los comportamientos de sus elementos y se representa mediante una elipse con borde discontinuo.

Caso de uso Es la descripcin de un conjunto de acciones que un sistema ejecuta y que produce un determinado resultado que es de inters para un actor particular, tambin se utiliza para organizar los aspectos del comportamiento en un modelo.

Componente Es una parte fsica y reemplazable de un sistema que conforma con un conjunto de interfaces y proporciona la implementacin de dicho conjunto, representa el equipamiento fsico de diferentes elementos lgicos, como clases, interfaces y colaboraciones.

Nodo Es un elemento fsico que existe en tiempo de ejecucin y representa un recurso computacional que por lo general dispone de algo de memoria y con frecuencia de capacidad de procesamiento. Un conjunto de componentes puede residir un nodo.

TABLA 3.1: Elementos EstructuralesFUENTE: Elaboracin Propia

b) ELEMENTOS DE COMPORTAMIENTOLos elementos de comportamiento son las partes dinmicas de un modelo. Se podra decir que son los verbos de un modelo y representan el comportamiento en el tiempo y espacio. Los principales elementos son los dos que siguen.ELEMENTODESCRIPCINREPRESENTACIN GRAFICA

Interaccin Es un comportamiento que comprende un conjunto de mensajes intercambiados entre un conjunto de objetos, dentro de un contexto particular, para alcanzar un propsito especfico.

Mquina de estado Es un comportamiento que especifica las secuencias de estados por las que pasa un objeto o una interaccin durante su vida en respuesta a eventos, junto con sus reacciones a estos eventos.

TABLA 3.2: Elementos de ComportamientoFUENTE: Elaboracin Propia

c) ELEMENTOS DE AGRUPACIN Forman la parte organizativa de los modelos UML. El principal elemento de agrupacin es el paquete.ELEMENTODESCRIPCINREPRESENTACIN GRAFICA

Paquete Es un mecanismo de propsito general para organizar elementos en grupos. Los elementos estructurales, los elementos de comportamiento, incluso otros elementos de agrupacin pueden incluirse en un paquete y se representa como una carpeta conteniendo normalmente su nombre y a veces su contenido.

TABLA 3.3: Elementos de Agrupacin FUENTE: Elaboracin Propia

d) ELEMENTOS DE ANOTACIN Los elementos de anotacin son las partes explicativas de los modelos UML. Son comentarios que se pueden aplicar para describir, clasificar y hacer observaciones sobre cualquier elemento de un modelo. ELEMENTODESCRIPCINREPRESENTACIN GRAFICA

Nota Es simplemente un smbolo para mostrar restricciones y comentarios junto a un elemento o una coleccin de elementos.

TABLA 3.4: Elemento de Anotacin FUENTE: Elaboracin Propia

e) RELACIONES EN UML Existen cuatro tipos de relaciones entre los elementos de un modelo UML. Dependencia, asociacin, generalizacin y realizacin, estas se describen a continuacin ELEMENTODESCRIPCINREPRESENTACIN GRAFICA

Dependencia Es una relacin semntica entre dos elementos, en la cual un cambio a un elemento (llamado elemento independiente) puede afectar a la semntica del otro elemento (elemento dependiente) y se representa con una lnea discontinua.

Asociacin Es una relacin estructural que describe un conjunto de enlaces, los cuales son conexiones entre objetos y se representa con una lnea continua

Generalizacin Es una relacin de especializacin / generalizacin en la que los objetos del elemento especializado (hijo) puede sustituir a los objetos del elemento general (padre). De esta forma , el hijo comparte el comportamiento y la estructura del padre y se representa con un lnea con punta de flecha vaca.

Relacin Es una relacin semntica entre clasificadores, en donde un clasificador especifica un contrato que otro clasificador garantiza que cumplir y se representa con una lnea discontinua con una punta de flecha vaca.

TABLA 3.5: Relaciones FUENTE: Elaboracin Propia

3.2.1.2. DIAGRAMAS UMLLos diagramas de se utilizan para representar diferentes perspectivas de un sistema de forma que un diagrama es una proyeccin del mismo. UML proporciona un amplio conjunto de diagramas que normalmente se usan en pequeos subconjuntos para poder representar las cinco vistas principales de la arquitectura del sistema.a) DIAGRAMA DE CLASES Muestran un conjunto de clases, interfaces y colaboraciones, as como sus relaciones. Estos diagramas son los ms comunes del modelado de sistemas orientado a objetos y cubren la vista de diseo esttica.b) DIAGRAMA DE OBJETOSMuestran un conjunto de objetos y sus relaciones, son como fotos instantneas de los diagramas de clases y cubren la vista de diseo esttica desde la perspectiva de casos reales o prototipos. c) DIAGRAMA DE CASOS DE USO Muestran un conjunto de casos de uso y actores (tipo especial de clases) y sus relaciones. Cubren la vista esttica de los casos de uso y son especialmente importantes para el modelado y la organizacin de comportamiento. d) DIAGRAMA DE SECUENCIA Y DE COLABORACIN Tanto los diagramas de secuencia como los dioramas de colaboracin son un tipo de dioramas de interaccin. Constan de un conjunto de objetos y sus relaciones, incluyendo los mensajes que se pueden enviar unos objetos a otros. Cubren la vista dinmica del sistema. Los diagramas de secuencia enfatizan el ordenamiento temporal de los mensajes mientras que los diagramas de colaboracin muestran la organizacin estructural de los objetos que envan y reciben mensajes. Los diagramas de secuencia se pueden convertir en diagramas de colaboracin sin prdida de informacin, lo mismo ocurre en sentido opuesto.e) DIAGRAMA DE ESTADOS Muestran una mquina de estados compuesta por estados, transiciones, eventos y actividades. Estos diagramas cubren la vista dinmica de un sistema y son muy importantes a la hora de modelar el comportamiento de una interfaz, clase o colaboracin.f) DIAGRAMA DE ACTIVIDADES Son un tipo especial de diagramas de estados que se centra en mostrar el flujo de actividades dentro de un sistema. Los diagramas de actividades cubren la parte dinmica de un sistema y se utilizan para modelar el funcionamiento de un sistema resaltando el flujo de control entre objetos.g) DIAGRAMA DE COMPONENTES Muestra la organizacin y las dependencias entre un conjunto de componentes. Cubren la vista de la implementacin esttica y se relacionan con los dioramas de clases ya que es un componente suele tener una o ms clases, interfaces o colaboraciones. h) DIAGRAMA DE DESPLIEGUE Representan la configuracin de los nodos de procesamiento en tiempo de ejecucin y los componentes que residen en ellos. Muestran la vista de despliegue esttica de una arquitectura y se relacionan con los componentes ya que, por lo comn, los nodos contienen uno o ms componentes. 3.2.2. LENGUAJES DE PROGRAMACIN3.2.2.1. HTML (HIPER TEXT MARKUP LANGUAGE)HTML, siglas de Hyper Text Markup Language (lenguaje de marcado hipertextual), hace referencia al lenguaje de marcado predominante para la elaboracin de pginas web que se utiliza para describir y traducir la estructura y la informacin en forma de texto, as como para complementar el texto con objetos tales como imgenes.[footnoteRef:12] [12: Wikipedia. (15 de Julio de 2013). Wikipedia La Enciclopedia Libre. Recuperado el 16 de Julio de 2013, de Wikipedia La Enciclopedia Libre: http://es.wikipedia.org/wiki/HTML]

Este es un lenguaje muy sencillo que se basa en el uso de etiquetas, consistentes en un texto ASCII encerrado dentro de un par de parntesis angulares(). Las etiquetas podrn incluir una serie de atributos o parmetros, en su mayora opcionales, que nos permitirn definir diferentes posibilidades o caractersticas de la misma. Estos atributos quedarn definidos por su nombre (que ser explicativo de su utilidad) y el valor que toman separados por un signo de igual. En el caso de que el valor que tome el atributo tenga ms de una palabra deber expresarse entre comillas, en caso contrario no ser necesario. Entre otras cosas, el manejo de estas etiquetas nos permitir: Definir la estructura lgica del documento HTML. Aplicar distintos estilos al texto (negrita, cursiva, etc). La inclusin de hiperenlaces, que nos permitirn acceder a otros documentos relacionados con el actual. La inclusin de imgenes y ficheros multimedia (grficos, vdeo, audio).3.2.2.1.1. ESTRUCTURA DE UN DOCUMENTO HTMLLa estructura bsica de un documento HTML es la siguiente: Indica el inicio del documento Indica el inicio de la cabecera Inicio del ttulo del documento Final del ttulo del documento Final de la cabecera Inicio del cuerpo del documentoInstrucciones HTML Final del cuerpo del documento Final del documento

Figura 3.6: Estructura Bsica de un documento HTMLFUENTE: Elaboracin Propia

Ninguno de estos elementos es obligatorio, pudiendo crear documentos HTML sin incluir estas etiquetas de identificacin. No obstante es altamente recomendable la construccin de pginas HTML siguiendo esta estructura, para una buena estructuracin y legibilidad del cdigo.3.2.2.2. PHP (HYPERTEXT PREPROCESSOR)PHP (acrnimo recursivo de PHP: Hypertext Preprocessor) es un lenguaje de cdigo abierto (open source) Se caracteriza por su potencia, versatilidad, robustez y modularidad, muy popular especialmente adecuado para el desarrollo web y que puede ser incrustado en HTML.[footnoteRef:13] [13: The PHP Group. (JULIO de 2012). PHP MANUAL. Recuperado el 12 de JULIO de 2013, de PHP MANUAL: http://www.php.net/manual/es/intro-whatis.php]

3.2.2.2.1. CARACTERSTICAS DE PHP Orientado al desarrollo de aplicaciones web dinmicas con acceso a informacin almacenada en una base de datos. Capacidad de conexin con la mayora de los motores de base de datos que se utilizan en la actualidad, destaca su conectividad con MySQL y PostgreSQL. Es libre, por lo que se presenta como una alternativa de fcil acceso para todos. Debido a su flexibilidad ha tenido una gran acogida como lenguaje base para las aplicaciones WEB de manejo de contenido, y es su uso principal. Est disponible para muchos sistemas (GNU/Linux, Windows, UNIX, etc). Al ejecutarse en el servidor, los programas PHP lo pueden usar todo tipo de mquinas con todo tipo de sistemas operativos.3.2.2.3. JAVA SCRIPTJavaScript es un lenguaje de programacin que se utiliza principalmente para crear pginas web dinmicas. [footnoteRef:14] [14: Eguluz Prez, J. (s.f.). Libros Web. Recuperado el 16 de Julio de 2013, de Libros Web: http://www.jesusda.com/docs/ebooks/introduccion_javascript.pdf]

Una pgina web dinmica es aquella que incorpora efectos como texto que aparece y desaparece, animaciones, acciones que se activan al pulsar botones y ventanas con mensajes de aviso al usuario.Tcnicamente, JavaScript es un lenguaje de programacin interpretado, por lo que no es necesario compilar los programas para ejecutarlos. En otras palabras, los programas escritos con JavaScript se pueden probar directamente en cualquier navegador sin necesidad de procesos intermedios.3.2.3. HOJA DE ESTILO Una hoja de estilos o CSS ("Cascade Style Sheet"), es un conjunto de reglas y caractersticas que, aplicadas a una pgina Web o a un conjunto de ellas, pueden modificar su apariencia. De esta forma, podemos separar en cierta forma el diseo de la pgina de su contenido.[footnoteRef:15] [15: Ruiz Palmero, J. (s.f.). Tecnologia Educativa Universidad de Malaga. Recuperado el 09 de Julio de 2013, de Tecnologia Educativa Universidad de Malaga: http://tecnologiaedu.uma.es/materiales/nvu/archivos/cap5_Hojas_de_estilo.pdf]

Gracias a las hojas de estilos podemos de alguna manera homogeneizar y automatizar el trabajo que supone el diseo de una Web. Podemos definir un estilo para los ttulos y otro para el texto, de forma que no tengamos que modificar cada vez el texto y los ttulos para que tengan la apariencia que queramos.Una hoja de estilos puede estar contenida en la misma pgina donde se utiliza o puede estar definida en un archivo aparte. De la segunda forma, podemos definir estilos para todo el sitio Web, mientras que de la primera tendremos que escribir el mismo cdigo en cada pgina cada vez que lo necesitemos. Por eso la primera se utiliza cuando se quiere aplicar algn efecto en particular y la segunda cuando ese efecto es el mismo para todas las pginas. Existe una tercera posibilidad, y es especificar el estilo en la propia etiqueta HTML dnde queramos usarlo, con lo que el efecto slo se producir en ese lugar.3.2.4. SERVIDOR WEB Un servidor web es un programa que se ejecuta continuamente en un computador, mantenindose a la espera de peticiones de ejecucin que le har un cliente. El servidor web se encarga de contestar a estas peticiones de forma adecuada, entregando como resultado una pgina web o informacin de todo tipo de acuerdo a los comandos solicitados.3.2.4.1. XAMP 3.2.5. GESTOR DE BASE DE DATOS Un Sistema de Gestin de Bases de Datos (SGBD) es un conjunto de programas que permiten el almacenamiento, modificacin y extraccin de la informacin en una base de datos, adems de proporcionar herramientas para aadir, borrar, modificar y analizar los datos. Los usuarios pueden acceder a la informacin usando herramientas especficas de interrogacin y de generacin de informes, o bien mediante aplicaciones al efecto.3.2.5.1. MYSQL MySQL es un sistema de gestin de base de datos. Es decir, una base es una coleccin estructurada de datos y el usuario necesita un administrador para poder agregar, acceder o procesar esta informacin guardada en el ordenador.MySQL es un sistema de administracin de bases de datos. Una base de datos es una coleccin estructurada de tablas que contienen datos. Esta puede ser desde una simple lista de compras a una galera de pinturas o el vasto volumen de informacin en una red corporativa. Para agregar, acceder a y procesar datos guardados en un computador, usted necesita un administrador como MySQL Server. Dado que los computadores son muy buenos manejando grandes cantidades de informacin, los administradores de bases de datos juegan un papel central en computacin, como aplicaciones independientes o como parte de otras aplicaciones.MySQL es un sistema de administracin relacional de bases de datos. Una base de datos relacional archiva datos en tablas separadas en vez de colocar todos los datos en un gran archivo. Esto permite velocidad y flexibilidad. Las tablas estn conectadas por relaciones definidas que hacen posible combinar datos de diferentes tablas sobre pedido. CARACTERSTICAS Entre las caractersticas disponibles en las ltimas versiones se puede destacar: Amplio subconjunto del lenguaje SQL. Algunas extensiones son incluidas igualmente. Disponibilidad en gran cantidad de plataformas y sistemas. Posibilidad de seleccin de mecanismos de almacenamiento que ofrecen diferente velocidad de operacin, soporte fsico, capacidad, distribucin geogrfica, transacciones... Transacciones y claves forneas. Conectividad segura. Replicacin. Bsqueda e indexacin de campos de texto.3.2.6. ISO/IEC 9126 (CALIDAD DE SOFTWARE).Segn (Pressman , 2005), el estndar ISO-9126 se desarroll como un intento por identificar los atributos de calidad para el software de computadora. El estndar identifica seis atributos clave de la calidad. 3.2.6.1. FUNCIONALIDADEs el grado en que el software satisface las necesidades que indican los siguientes subatributos: idoneidad, exactitud, interoperabilidad, cumplimiento y seguridad. 3.2.6.2. FIABILIDADEs la cantidad de tiempo en que el software est disponible para usarlo segn los siguientes subatributos: madurez, tolerancia a fallas y facilidad de recuperacin. 3.2.6.3. FACILIDAD DE USO Es la facilidad con la que se usa el software de acuerdo con los siguientes subatributos: facilidad de comprensin, facilidad de aprendizaje, y operabilidad. 3.2.6.4. EFICIENCIAEs el grado en que el software emplea en forma ptima los recursos de sistema, como lo indican los siguientes subatributos: comportamiento en el tiempo, comportamiento de los recursos.3.2.6.5. FACILIDAD DE MANTENIMIENTO Es la facilidad con que se repara el software de acuerdo con los siguientes subatributos: facilidad de anlisis, facilidad de cambio, estabilidad y facilidad de prueba.3.2.6.6. PORTABILIDADEs la facilidad con que se lleva el software de un entorno a otro segn los siguientes subatributos: adaptabilidad, facilidad para instalarse, cumplimiento, facilidad para reemplazarse.

CAPITULO IVMARCO APLICATIVO

4. CAPITULO IV4.1. MBITO DEL SISTEMAEn las instalaciones del Gobierno Autnomo Municipal de Cobija ubicado en la ciudad de cobija, se encuentra la unidad de archivos, lugar donde se encuentran almacenados todos los documentos generados por la Municipalidad.4.2. DESARROLLO DEL SISTEMA

CAPITULO IVMARCO APLICATIVO

5. CAPITULO V

BIBLIOGRAFAReglamento de Archivos, 48/2004 (Gobierno Autonomo Municipal de Cobija 15 de Septiembre de 2004).Aguilar, J. O., & Ramirez, Y. (2012). Plan de negocio de gestion documental para las PYMES en Colombia. Bogota, D.C.: Universidad EAN Facultad de Postgrados Gestion de portafolios de inversion y valoracion de empresas.Burgos Cardemil, M. (2011). Clasificacin de los Sistemas de Informacin. chile: Universidad Austral de Chile, Escuela de Ingeniera Comercial.Contreras, F. (2005). Diseo de un modelo para la implementacin de un sistema de gestin documental en reas u organizaciones jurdicas. Bogota: Pontificia Universidad Javeriana.Eguluz Prez, J. (s.f.). Libros Web. Recuperado el 16 de Julio de 2013, de Libros Web: http://www.jesusda.com/docs/ebooks/introduccion_javascript.pdfGrady , B., Rumbaugh, J., & Jacobson, I. (2000). El Proceso Unificado de Desarrollo de Software. Madrid: PEARSON EDUCACION, S. A. .Grady, B., Rumbaugh, J., & Jacobson, I. (2006). El Lenguaje Unificado de Modelado. MADRID: PEARSON EDUCACION S. A. .Ivar J.,Grady B.,James R. (2000). EL LENGUAJE UNIFICADO DEL MODELADO. ESPAA: ADISON WESLEY.Jaramillo Arce, J. (2009). Sistema de Gestin Documental para el Departamento de prcticas profesionales de la Universidad Catlica Popular del Risaralda. Risaralda: Universidad Catlica Popular del Risaralda.Mamani Villavicencio, M. (2007). Refinamiento del mtodo de diseo de hipermedia orientado a objetos (OOHDM). La Paz: Universidad Mayor de San Andrs de Bolivia, Facultad de Ciencia Puras y Naturales.Ministerio de Educacion. (2011). Sistema de Informacin de Apoyo a la Administracin Documental y de Archivo. Republica del Peru: Ministerio de Educacion.Navarro Mora, D. (2009). Software para la Organizacin, Registro, Control y Bsqueda de documentos en la Empresa INFOGESTION LTDA. Cartagena - Indias: Fundacin Universitaria Tecnolgico COMFENALCO.Pressman , R. (2005). Ingenieria de Software un Enfoque Practico. Mexico: McGRAW-HILL/INTERAMERICANA EDITORES S.A.Rendon P., R. (2011). Sistema Administrativo para la Gestin de Documentos para la GMD de PDVSA Exploracin y Produccin Divisin Oriente bajo plataforma de Software Libre. Republica de Venezuela - Nonagas: Universidad de Oriente - Ingenieria de Sistemas.Rendn Rojas, M. . (2011). El Objeto de Estudio de la Documentacion. En M. . Rendn Rojas, Bibliotecologa, archivstica, documentacin: intradisciplina, interdisciplina o transdisciplinariedad (Vol. Primera Edicin 2011, pgs. 69-80). Mxico D.F.: UNIVERSIDAD NACIONAL AUTNOMA DE MXICO.Rivas, J. (2010). Sistema automatizado para optimizar el registro y control de prstamo de Expedientes en el Archivo del Departamento Legal de la corporacin Palmar, S.A. (CORPALMAR). Republica Bolivariana de Venezuela - Caracas: Universidad Nueva Esparta - Facultad de Ciencias de la Informatica.Ruiz Palmero, J. (s.f.). Tecnologia Educativa Universidad de Malaga. Recuperado el 09 de Julio de 2013, de Tecnologia Educativa Universidad de Malaga: http://tecnologiaedu.uma.es/materiales/nvu/archivos/cap5_Hojas_de_estilo.pdfSierra Cuervo, S. (2009). Diseo e Implementacin de un modelo de Gestin Documental para la serie historias laborales del rea de talento humano para la Empresa COLGRABAR. Bogota: Pontificia Universidad Javeriana (Ciencia de da Informacin Bibliotecologa).Sistemas Integrales de Formacion Tecnica.