UNIVERSIDAD TECNICA DE ORUROFACULTAD NACIONAL DE INGENIERIACARRERA DE INGENIERIA DE SISTEMAS

PROYECTO DE GRADO

SISTEMA DE GESTION DE ACTIVOS FIJOS PARA MAXAM FANEXA S.A.M.

PARA OPTAR AL TITULO DE LICENCIATURA EN INGENIERIA DE SISTEMAS

POSTULANTE: JAIR SAMUEL VENTURA TOVAR

ORURO BOLIVIA2014

AGRADECIMIENTOS

Gracias a Dios por este logro acadmico, aun a pesar de que mi memoria me presentara como un ser injusto pues tal vez, involuntariamente se me escapen algunas personas quienes debera nombrar, pero quiero agradecer a todos que me ayudaron a seguir en este camino y no me abandonaron y ms por el contrario siempre me empujaron para continuar.A mi padres y hermanos quienes me apoyaron incondicionalmente y apoyndome continuamente.A Kanito y archell_pollito quienes por la experiencia acumulada apoyaron bastante en la revisin y bsqueda de errores que mejoren en el rendimiento del presente proyecto.A mis docentes quienes a lo largo de muchos aos, con sus inquietudes y sus dudas me han enseado ms de lo que podran haberme enseado.A mi querida carrera que me acogi dentro sus aulas como un segundo hogar lleno de alegras y experiencias que estarn siempre en mi recuerdo.

DEDICATORIAA Dios por nunca abandonarme y estar siempre conmigo.A mis padres y hermanos por el apoyo incondicional.A mis pequeas: Viviam y Mariam que son la razn de mi existencia.A la FNI por ser mi templo de formacin.

RESUMEN

El proyecto Sistema de Gestin de Activos Fijos, fue desarrollado para el rea de Activos Fijos de MAXAM FANEXA S.A.M., institucin dedicada a la fabricacin y comercializacin de explosivos, que a la vez al ser una empresa consolidada a nivel nacional maneja una gran cantidad de bienes denominados activos.MAXAM FANEXA realiza la mayora de los procesos de gestin de activos fijos de manera manual, usando como respaldo la utilizacin de planillas echas en Excel, que con el ingreso de nuevos activos se vuelve ms pesado el acceso a ello, razn por la cual se decidi optar la construccin de una aplicacin web que aproveche la INTRANET que cuenta la empresa y adems se pretende obtener informacin rpida y consistente, a fin de maximizar la eficiencia en la administracin de la informacin de los activos fijos que cuenta la empresa. La metodologa adoptada para el desarrollo del software es SCRUM apoyada por AUP, para el modelamiento del sistema y que a su vez este modelamiento se lo realizo en UML (Lenguaje de Modelado Unificado), que ayuda a efectuar la representacin de los modelos por medio de artefactos, en las distintas etapas que contempla estas metodologas.Las herramientas utilizadas para la implementacin son: el lenguaje de programacin C# y Asp.net y el gestor de base de datos SQL SERVER EXPRESS.Los mdulos principales de la aplicacin son: Registro, Asignacin, Transferencia, Baja, Bsquedas, Traspasos y Reportes.Concluido el desarrollo del software se realizaron pruebas de funcionamiento, con las que se pudo constatar que el sistema responde a los requerimientos institucionales, posibilitando la reduccin de tiempo y costos en la administracin de activos fijos, adems de la obtencin de datos confiables.

INDICE

44

SISTEMA DE GESTION DE LOS ACTIVOS FIJOSEN MAXAM FANEXA S.A.M.

1.1 INTRODUCCION.Las instituciones pblicas o privadas, para llevar a cabo sus actividades requieren de la utilizacin de ciertos bienes denominados activos. Estos bienes tangibles que se utilizan para el desarrollo de sus actividades administrativas y cumplen una funcin se les denomina Activos Fijos. Cabe resaltar que entre las principales caractersticas de estos activos son la permanencia en la empresa, generando utilidades hasta que dichos bienes dejen de ser tiles por el paso del tiempo y debido principalmente a la depreciacin (prdida del valor monetario que sufre el bien al transcurrir el tiempo), o bien hasta que la empresa decida darlos de baja.MAXAM FANEXA S.A.M. es una compaa lder en la fabricacin, comercializacin y distribucin de productos, sistemas de iniciacin y servicios de voladura para las industrias mineras, de la construccin y exploracin petrolera; nace el ao 1999 de la unin de dos empresas lderes en la fabricacin de explosivos, la primera La Unin Espaola de Explosivos (UEE) de una larga tradicin actualmente bajo el nombre de MAXAM consolidada como una empresa lder a nivel mundial; y la segunda Fbrica Nacional de Explosivos (FANEXA) fundada en el ao 1977 como parte de La Corporacin de las Fuerzas Armadas para el Desarrollo Nacional (COFADENA), ambas empresas han conjugado experiencia nacional e internacional, ltimas tecnologas, nuevas formas de gestin modernas y eficaces. Aportando al progreso del pas; componentes que han aportado a cubrir gran porcentaje del mercado nacional de productos reconocidos todos por su alta seguridad y calidad.MAXAM FANEXA S.A.M. cuenta con una gran cantidad de activos que necesita ser almacenada, en una aplicacin, razn por la cual se propuso la aplicacin del tipo modelo, vista controlador para el almacenamiento de todos sus activos con sus respectivos requerimientos que se hizo para la elaboracin de este proyecto (depreciaciones, revalorizaciones, dar baja, traspaso, etc.), aprovechando la intranet que cuenta la empresa. 1.2 ANTECEDENTES.1.2.1 DESCRIPCIN DE LA EMPRESAConstitucin de la SociedadMediante D.S. N 10511 de septiembre de 1972, el gobierno de Bolivia concede al Ministerio de Defensa Nacional la exclusividad de la fabricacin de explosivos y accesorios en el pas y con el D.S. N 15348 de 10 de Marzo de 1978, se autoriza a COFADENA, suscribir contratos de provisin de maquinaria y equipos, tecnologas y asistencia tcnica con las empresas japonesas ASAHI CHEMICAL INDUSTRY CO. LTDA., NISSHO IWAI CO. LTDA., para la instalacin de una planta industrial de fabricacin de explosivos y accesorios en Bolivia, constituyendo as una sociedad annima con la Corporacin Minera de Bolivia (COMIBOL) y las empresas indicadas.Con escritura pblica N 430 de 26 de abril de 1978, se constituye la sociedad annima mixta bajo la razn social de Fbrica Nacional de Explosivos y Accesorios S.A.M. (FANEXA S.A.M.) con la aprobacin de sus estatutos, siendo su composicin accionaria: COFADENA 50%, COMIBOL 40%, ASAHI CHEMICAL INDUSTRY CO. LTDA. 7.5% y NISSHO IWAI CO. LTDA. 2.5%. El grupo UEE el 23 de septiembre de 2006 cambia de razn social como reflejo de los cambios de polticas corporativas y crecimiento de la empresa por el de MAXAM, con experiencia en ms de cuarenta pases, lder en el desarrollo y comercializacin de explosivos civiles y sistemas de iniciacin para minera, canteras e infraestructura; productos para las industrias de defensa, adems de materias primas claves para sus necesidades internas y de terceros.COFADENA con ms de veintiocho aos de experiencia y decidida vocacin de servicios al progreso de Bolivia, coopera en el desarrollo de todas las industrias fundamentales como la minera, qumica, agrcola y ganadera. Como parte integrante de las FF.AA. garantiza la sostenibilidad de los proyectos en los que se involucra, adems de contar con el apoyo decidido del estado en todos los proyectos en los que participa, garantizando la inversin pblica y privada.

Desde su creacin como Sociedad Annima Mixta en julio de 1999 la compaa ha progresado hasta convertirse en lder nacional de su rubro, llegando a exportar ms del 25% de sus ventas a pases como EE.UU., Chile, Ecuador, Per y otros, habindose implementado en los ltimos 5 aos lneas de produccin en productos que hoy cubren los mercados nacionales y extranjeros con la mayor calidad y seguridad. La calidad de los procesos de diseo, produccin, comercializacin y distribucin est certificada hace ms de tres aos bajo Norma Internacional ISO 9001:2000 constituyndose en referente nacional en temas de Seguridad, Prevencin de Riesgos y Medio Ambiente.MAXAM FANEXA S.A.M. cuenta con dos plantas de produccin una en Cochabamba y otra en Oruro, ambas con maquinaria y tecnologas de fabricacin de punta, sustentadas por toda la gran experiencia y calidad de MAXAM con sede en Espaa.Trabajos que se tom en cuenta tienen relacin al proyecto propuesto: Sistema de Control y Depreciacin de Activos Fijos: Zona Franca Oruro S.A., desarrollado por Evert Fernando Cortez Hino [2012], Facultad Nacional de Ingeniera FNI, cuyo objetivo es el control de depreciacin de sus activos fijos en la zona franca de Oruro, para un manejo ms adecuado y eficiente. Sistema Automatizado de Control de Inventarios y Actividades Comerciales, desarrollado por Leslie Elsa Montenegro [2010], Facultad Nacional de Ingeniera FNI. Cuyo objetivo principal es la organizacin mediante inventarios los activos que cuenta la institucin para cual desarrolla esta actividad. Sistema de Informacin y control de Activos Fijos Ministerio de Gobierno, desarrollado por James Williams Gutirrez Flores [2005], Facultad de Ciencias Puras y Naturales UMSS. cuyo objetivo principal del proyecto es desarrollar e implementar un Sistema de Informacin automatizado para la administracin, seguimiento y control de Activos Fijos del Ministerio de Gobierno, que permite tener informacin actualizada y centralizada. Enfatizando en la migracin de la informacin de la base de datos del antiguo sistema, estandarizando formatos de actas e informes. Control y Seguimiento de Activos Fijos del Servicio Exterior va web Ministerio de Relaciones exteriores y Cultos, desarrollado por Mario Cancillo Zanga [2006], Facultad de Ciencias y Tecnologa UMSS, herramienta de software de apoyo en la administracin, seguimiento y control de activos fijos. Coadyuvando en forma eficiente y transparente la elaboracin y obtencin de informacin organizada, confiable y oportuna. Sistema de Gestin y Seguimiento de Activos Fijos para el servicio departamental de Gestin Social, desarrollado por Juan Carlos Quispe Limachi [2008], Facultad de Ciencias y Tecnologa UMSS, software que pretende obtener informacin rpida, a fin de maximizar la eficiencia en la administracin de la informacin de los activos.1.3 CARACTERIZACION DEL PROBLEMA Y SITUACION PROBLEMATICA.La empresa MAXAM FANEXA S.A.M. dentro lo que se refiere al manejo de sus activos se identific los siguientes problemas: No tiene buena organizacin ni clasificacin de sus activos, razn por la cual no se da la informacin necesaria del activo. La codificacin que cuenta es demasiada antigua, ocasionando que a veces no se encuentre dicho activo en un lugar determinado y no coincida en la verificacin. No se tiene registro sobre quin es responsable de un activo, ni la ubicacin del activo de manera exacta, que permita en el caso de prdida dar con el responsable la ubicacin y a donde pertenece ese activo. No se tiene clculo exacto de las depreciaciones, evidenciando errores en el redondeo, ocasionando que el contador haga nuevamente reajustes de precios y gastos cada cierre de mes. Crecimiento masivo de la planilla hecha en Excel, causa problemas como errores de ingreso o copia de frmulas al ingreso de nuevos activos, y en el uso del equipo en su rendimiento que hace que se vuelva ms lento a medida que va creciendo la mencionada planilla. Demora en la disponibilidad de informacin sobre depreciaciones para el cierre de balance de mes, ocasiona que el cierre de mes de alargue hasta altas horas de la noche y a veces se pida plazo a impuestos nacionales en la entrega de informes. No se cuenta con historial sobre traspaso y asignacin de los activos, ocasiona la perdida de algunos activos y no cumplimiento del tiempo de vida previsto de sus activos fijos.1.3.1 PLANTEAMIENTO DEL PROBLEMA.Cmo se puede mejorar el movimiento de sus activos fijos, en forma confiable, que permita obtener informacin consistente, para un adecuado control y seguimiento de sus activos en MAXAM FANEXA S.A.M.?1.4 OBJETO DE ESTUDIO.Se constituye el proceso administrativo de seguimiento y control de activos en la empresa MAXAM FANEXA S.A.M.1.5 CAMPO DE ACCION.El presente proyecto se desarroll en el rea de la ingeniera de Sistemas, ms propiamente en el desarrollo de Sistemas de Informacin Administrativa. Especficamente se desarroll en la empresa MAXAM FANEXA S.A.M. para el rea de Activos Fijos dependiente de Gerencia Financiera. 1.6 OBJETIVOS.1.6.1 OBJETIVO GENERAL.Desarrollar e implantar un Sistema de Gestin y Seguimiento de activos Fijos, que permita obtener informacin confiable en el control y seguimiento de sus activos en MAXAM FANEXA S.A.M.1.6.2 OBJETIVOS ESPECIFICOS. Establecer los requerimientos de manejo de informacin en el rea de activos fijos, con los que iniciara el desarrollo de la aplicacin. Desarrollar mdulos que contemplen: privilegios, operaciones y registros de los activos, para una distribucin y organizacin adecuada contemplando las normas futuras que la empresa tiene planificado implantarlas. Desarrollar una base de datos que permita almacenar todos los datos que genere el movimiento de los activos, de forma que se logre almacenar informacin verdica y oportuna. Disear y desarrollar la interfaz que facilite el uso del sistema utilizando la tecnologa .NET, de tal manera que sea lo ms amigable posible para el usuario. 1.7 CRITERIO DE VERIFICACION:Se realizara pruebas de los diferentes servicios de la aplicacin web implementada en la intranet de la empresa, en una muestra de casos reales con resultados conocidos, contrastando con los resultados obtenidos, debindose obtener resultados exactos y en menor tiempo, y para cumplir este propsito se utilizara el estadstico de Fisher.1.8 JUSTIFICACIONES.1.8.1 JUSTIFICACION TECNICA.El proyecto se justifica tcnicamente puesto que el anlisis, diseo y construccin estn realizados de acuerdo a la metodologa SCRUM, el cual se apoya en el desarrollo gil de sistemas UML ligero (Unified Languaje ) cuyo modelamiento ayudara en la comprensin del sistema y para este cometido se efectuara en un herramienta case.La programacin del sistema ser realizada en ASP.NET de visual web developer 2005 una herramienta de desarrollo gratuita, que se caracteriza porque ofrece servicios web, independencia de la plataforma.Los servicios web son un novedoso tipo de componentes de software que se caracterizan a la hora de trabajar por su total independencia respecto a su ubicacin fsica real.El sistema trabaja sobre una Base de Datos centralizada, la que se gestiona en Microsoft SQL Server 2005 EXPRESS, un gestor de datos relacional.En el tema de seguridad de la informacin la aplicacin estar en la intranet de la empresa, donde solo aquellos que necesiten la aplicacin tendrn acceso. Siendo el directo responsable el administrador de servidores que otorga ciertos privilegios a los usuarios que estn dentro el dominio existente.1.8.2 JUSTIFICACION OPERATIVA.Con el presente proyecto se pretende contribuir de alguna manera en las actividades que se realiza en el rea de Activos Fijos de la empresa MAXAM FANEXA S.A.M. con el fin de mejorar la administracin que se realiza a los activos fijos.1.9 ALCANCES.Con el presente proyecto se podr tener datos muy confiables en el clculo de las depreciaciones, tener los reportes adecuados para cada rea, que estn disponibles en el momento que se requiera por dichas areas y que el cierre de mes sea ms rpido evitando esperas al ingreso de nuevos activos a depreciar.El presente proyecto tambin controlara el registro, asignacin, depreciacin, baja, traspasos y restauraciones de los activos, clasificados de acuerdo al siguiente TIPO: Terrenos Edificios Muebles y Enseres Maquinaria Equipos e instalaciones Vehculos Herramientas Equipos de computacin Equipos de laboratorioEl sistema estar dispuesto para su acceso a travs del navegador de Internet. El sistema trabajar sobre una base de datos centralizada. Utilizacin del lenguaje de programacin C# bajo plataforma .NET.

En el mbito acadmico el presente proyecto dar pautas que ayuden el desarrollo de software de manera gil, utilizando metodologas de la gestin de proyectos que son adaptables al desarrollo de software, apoyados del modelamiento de UML. 1.10 LIMITACIONES.Como este proyecto fue desarrollado especficamente para MAXAM FANEXA S.A.M. no pretende ser una solucin general a diferentes situaciones que otras empresas pueden tener, lo que s es posible podra adaptarse, modificar y aadir ms operaciones en el clculo de las depreciaciones. 1.11 INGENIERIA DEL PROYECTO. La ingeniera del proyecto estar basada en estos elementos principales: El mtodo, el cual definir todo el proceso de desarrollo de la aplicacin web. Y por sus caractersticas se utilizara el de desarrollo de software mediante SCRUM + AUP. La implementacin de la aplicacin web se lo efectuara con herramientas de la tecnologa web, cuyo servidor de pginas web ser IIS (Internet Information Server 2003) y C# ser como el lenguaje de implementacin.

Tabla 1.1 ingeniera del Proyecto

OBJETIVOSACTIVIDADMETODO / TECNICA

Establecer los requerimientos de manejo de informacin en el rea de activos fijos, con los que iniciara el desarrollo de la aplicacin.Conformar equipos auto organizados. Historias de Usuario Product Backlog. Release Plan

Desarrollar mdulos que contemplen: privilegios, operaciones y registros de los activos, para una distribucin y organizacin adecuada contemplando las normas futuras que la empresa tiene planificado implantarlas Revisar el Product Backlog. Determinar con cuantos sprint se desarrollara el proyecto. Planificacin del Sprint Desarrollo de tareas para cada historia de usuario.

Desarrollar una base de datos que permita almacenar todos los datos que genere el movimiento de los activos, de forma que se logre almacenar informacin verdica y oportuna. Disear la base de datos, Actualizacin y consulta de la base de datos. Modelado de la Base de Datos Manejo de SQL SERVER 2005 EXPRESS

Disear y desarrollar la interfaz que facilite el uso del sistema utilizando la tecnologa .NET, de tal manera que sea lo ms amigable posible para el usuario.

Bsqueda de plantillas. Observar interfaces amigables. Interfaz web ASP.NET Hojas de estilo CSS

En este captulo se van a abordar diversas tecnologas que se integraran en el desarrollo del proyecto de software. La investigacin est enfocada en el desarrollo de una aplicacin web para la gestin de activos fijos, que integrara diversas tecnologas con el objetivo de mejorar el movimiento de dichos activos. La aplicacin de mtodos agiles en el desarrollo de software permitir combinar la gestin de proyectos basados en SCRUM que es una metodologa basada en la organizacin de trabajo. La aplicacin ser desarrollada sobre la plataforma .NET la cual es compatible con equipos Windows y Linux, tendr una interfaz web ASP.NET.Para el acceso a los datos del repositorio de informacin desde la aplicacin, se utilizara la tecnologa ADO.NET la cual es ideal para ambientes desconectados en la web. El repositorio de informacin ser una base de datos relacional implementada en un Sistema Gestor de Base de Datos Relacionales.2 ACTIVOS FIJOS.Se considera Activo Fijo a aquellos bienes que tienen una vida relativamente larga, fsicamente tangible, no se venden pero pueden ser utilizados en la produccin o comercializacin de bienes y servicios, pueden ser alquilados a terceros o para fines administrativos, y que en realidad prestan servicio a una institucin en el desarrollo especifico de sus actividades.Con el objetivo de lograr la racionalidad en la distribucin, uso y salvaguarda de los activos fijos de la empresa, el rea de Activos Fijos dependientes de Contabilidad trabaja en base a las normas bsicas del Sistema de Administracin de Bienes y Servicios, que rige en nuestro pas, constituyndose un conjunto de elementos jurdicos, tcnicos y administrativos que regula el manejo de bienes de propiedad de la institucin. Dentro los activos fijos estn separados en dos grupos: Tangibles e Intangible, limitndonos especficamente al grupo tangible.2.1 ACTIVO TANGIBLE.El trmino tangible se refiere a lo fsico como es el caso de un terreno, un edificio o una mquina, este grupo de activos es en su mayora lo que la empresa cuenta.Estos activos cuando se desgastan y a medida que va pasando el tiempo sufren una Depreciacin que simplemente es la prdida del valor monetario que sufre el bien al transcurrir el tiempo. El nico activo que no se deprecia es el terreno.2.2 CLASIFICACION GENERAL.La empresa para la clasificacin de sus Activos y siguiendo la sugerencia de su socia MAXAM CORPORATION lo hizo de acuerdo a: TIPO, GRUPO Y SUBGRUPO.2.3 CLASIFICACION CONTABLE.Para efectos contables los Activos Fijos, se clasifican particularmente en dos grupos: Activos No Depreciables y Activos Depreciables.a) ACTIVOS NO DEPRECIABLES.Los activos no depreciables son aquellos que no sufren desgaste o demerito por el uso a que son sometidos y que por tanto no pierde un precio, al menos contablemente. Entre los activos no depreciables tenemos los terrenos, siendo este tipo aquellos que no sufren desgaste por el uso a que son sometidos aun cuando el tiempo ya haya transcurrido, y por esta razn se consideran no depreciables. Esta es una teora contable aceptada en todo el mundo. b) ACTIVOS DEPRECIABLES.La inmensa mayora de los Activos Fijos de una empresa son depreciables, y son los que sufren desgaste o deterioro por el uso a que estn sometidos o slo por el transcurrir del tiempo.2.3.1 DEPRECIACION DE ACTIVOS FIJOS.Con excepcin de los terrenos, la mayora de los activos fijos tienen una vida til limitada ya sea por el desgaste resultante del uso, el deterioro fsico causado por terremotos, incendios u otros siniestros; la perdida de utilidad comparativa respecto de nuevos equipos y procesos o simplemente el agotamiento de su contenido. La disminucin de su valor causada por factores antes mencionados se carga a un gasto llamado Depreciacin.La depreciacin es un reconocimiento racional y sistemtico del costo de los bienes, distribuido durante su vida til estimada con el fin de obtener los recursos necesarios para la reposicin de los bienes, de manera que se conserve la capacidad operativa o productiva del ente pblico. Su distribucin debe hacerse empleando los criterios de tiempo y productividad mediante uno de los siguientes mtodos: lnea recta, suma de los dgitos de los aos, saldos decrecientes, nmero de unidades producidas o nmero de horas de funcionamiento, o cualquier otro reconocido valor tcnico, que debe revelarse en las notas a los estados contables.La depreciacin no es un proceso de valuacin por el que se asigna a gastos el costo del activo de acuerdo con autoevalo realizados al fin de cada periodo. La depreciacin es una asignacin del costo del activo a gastos de acuerdo con su costo original. Un activo totalmente depreciado solamente significa que ha alcanzado el final de su vida til estimada, es decir que no registra ms depreciacin para el activo. Esto no quiere decir que el activo sea desechado o que ya no se use, la mayora de veces, las empresas continan utilizando los activos totalmente depreciados con el fin de no pagar el IVA (impuesto al valor agregado) correspondiente de un activo en uso.La depreciacin no significa que el negocio aparte efectivo para reemplazar los activos cuando lleguen a ser totalmente depreciados. La depreciacin es simplemente parte del costo del activo que es enviado a gastos y no significa efectivo. La depreciacin no implica un movimiento de efectivo pero si afecta al monto de un negocio en el sentido de que constituye un gasto deducible para fines impositivos.Por lo tanto la depreciacin afecta el nivel de utilidades y el pago de impuestos, a un mayor nivel de depreciacin, las utilidades son menores y los impuestos correspondientes tambin son menores.Por otro lado debe considerarse el valor residual o valor recuperable que ser el que tendr el bien cuando se discontine su empleo y se calcule deduciendo del precio de venta los gastos necesarios para su venta, incluyendo los costos de desinstalacin y desmantelamiento si fueran necesarios.Otro factor de importancia para la actualizacin de los costos en la depreciacin es la utilizacin de las UFVs (Unidades de Fomento a la Vivienda).

2.4 METODOLOGIAS AGILES.En marzo de 2001, 17 crticos de los modelos para el desarrollo de software basados en procesos, convocados por Kent Beck y celebrado en Utah EEUU, nace el trmino gil aplicado el desarrollo de software. En la reunin se acuo el trmino Mtodos Agiles para definir a los que estaban surgiendo como alternativa a los modelos formales (CMM-SW, PMI, SPICE) [footnoteRef:1]que los consideraban excesivamente pesados y rgidos por su carcter normativo y fuerte dependencia de planificaciones detalladas, previas al desarrollo de software. Los integrantes de la reunin resumieron en cuatro postulados lo que ha quedado denominado como Manifiesto gil y que son los principios sobre los que se basan estos mtodos. [1: Manifiesto gil, marzo de 2001 reunin convocada por Kent Beck para dar lineamientos sobre el nuevo desarrollo de Software ]

2.4.1 EL MANIFIESTO AGIL.El manifiesto comienza de esta manera Estamos poniendo al descubierto mejores mtodos para desarrollar software, hacindolo y ayudando a otros que lo hagan. [SCRUM-MANAGER-GESTION DE PROYECTOS] A los individuos y su interaccin, por encima del seguimiento de un plan. La gente es el principal factor de xito de un proyecto software. Es ms importante construir un buen equipo que construir el entorno. Muchas veces se comete el error de construir primero el entorno y esperar que el equipo se adapte automticamente. El mejor crear el equipo y que ste configure su propio entorno de desarrollo en base a sus necesidades. El software que funciona, por encima de los procesos y las herramientas.La regla a seguir es no producir documentos a menos que sean necesarios de forma inmediata para tomar una decisin importante. Estos documentos deben ser cortos y centrarse en lo fundamental. La colaboracin con el cliente, por encima de la negociacin contractual.Se propone que exista una interaccin constante entre el cliente y el equipo de desarrollo. Esta colaboracin entre ambos ser la que marque la marcha del proyecto y asegure su xito. La respuesta al cambio, por encima del seguimiento de un plan.La habilidad de responder a los cambios que puedan surgir a lo largo del proyecto (cambios en los requisitos, en la tecnologa, en el equipo, etc.) determina tambin el xito o fracaso del mismo. Por lo tanto, la planificacin no debe ser estricta sino flexible. 2.5 SCRUM.En 1993, Jeff Sutherland aplico el modelo Scrum al desarrollo de software en Easel Corporation (empresa que en los macro-juegos de compras y fusiones se integrara en VMARK, luego en Informix y finalmente en Ascential Software Corporation). En 1996, presento junto con Ken Schwaber, las prcticas que empleaba como proceso formal, para gestin del desarrollo de software en OOPSLA 96(Schwaber & Sutherland, 1996). En 2001 formaron parte de los firmantes del Manifiesto gil. Las practicas desarrolladas por Schwaber y Sutherland para gestionar el desarrollo de software estn incluidas en la lista de modelos agiles de Agile Alliance. Scrum es un proceso gil que se puede usar para gestionar y controlar desarrollos complejos de software y productos usando prcticas iterativas e incrementales, desarrollando cualquier producto o gestionar cualquier trabajo. Aunque Scrum estaba previsto que fuera para la gestin de proyectos de desarrollo de software, se puede usar tambin para la ejecucin de equipos de mantenimiento de software o como un enfoque de gestin de programas.Scrum en el rea de ingeniera de software es un Mtodo gil para el desarrollo de proyectos. Toma su nombre as como los principios, de los estudios realizados por Hirotaka Takeuchi y Ikujijo Nonaka sobre nuevas prcticas de produccin a mediados de 1980, quienes basndose en el juego de Rugby Scrum, las caractersticas principales de este juego son el trabajo en equipo y la adaptacin. Scrum surgi como modelo para el desarrollo de productos tecnolgicos, pero tambin se emplea en entornos que trabajan con requisitos inestables y que adems requieren rapidez y flexibilidad, estas situaciones son frecuentes en el desarrollo de determinados sistemas software. Scrum es una forma de desarrollo de carcter adaptable ms que predictivo, adems de ser fcilmente combinable con otros mtodos. En un proyecto Scrum se consideran los siguientes aspectos: Desarrollo de software en etapas incrementales. Es un modo de desarrollo adaptable. Orientado a las personas antes que a los procesos. Emplea del desarrollo iterativo e incremental. Requiere de entregas de software terminado. Se enriquece con la experiencia del equipo de trabajo. La implementacin de Scrum es de bajo riesgo y costo.Para Scrum Management, los requisitos y sus modelos de especificacin: Product Backlog y Sprint Backlog, se sitan en la zona de la forma y para que la implantacin de Scrum alcance niveles de capacidad elevados tiene que responder una visin clara, conocida y compartida por todo equipo, tanto a nivel de producto en general (visin del producto) como del sprint en el que se est trabajando (objetivo del Sprint).

Fig. 2.1 Determinacin de Requerimientos Tradicional vs. gil Fuente: [Juan Palacios, 2008]2.6 ELEMENTOS DE UN PROYECTO SCRUM.Los elementos centrales de un ciclo gil Scrum son:2.6.1 PRODUCT BACKLOG (PILA DEL PRODUCTO): lista de funcionalidades que necesita el cliente y se origina con la visin inicial del producto, va creciendo y evolucionando durante el desarrollo del proyecto, las caractersticas principales de esta pila son: Priorizacin de acuerdo a la importancia que le da el propietario del producto. Debe ser accesible para todos los miembros del equipo del proyecto. Todos pueden contribuir y aportar elementos. El responsable directo es el propietario del producto.2.6.1.1 COMO HACEMOS EL PRODUCT BACKLOG (PILA DEL PRODUCTO)La Pila del Producto es el corazn de Scrum, es donde empieza todo, la pila del producto es bsicamente una lista priorizada de requisitos o historias o funcionalidades. Cosas que el cliente quiere descritas usando la terminologa del cliente, llamamos a estas historias o a veces simplemente elementos de la pila.Tabla 2.1- Formato para el Product BacklogPRODUCT BACKLOG (PILA DEL PRODUCTO)

IDNOMBRE O DESCRPCIONIMPORTANCIA O PRIORIDADESTIMACION INICIAL O ESTADOCOMO PROBARLO

ID: Identificador nico auto incremental que permite no perder la pista a las historias cuando cambiamos su nombre. NOMBRE: Una descripcin corta de la historia del usuario, suficientemente claro como para el dueo del producto comprenda aproximadamente de que se est hablando y suficientemente clara como para distinguirla de las otras historias. IMPORTANCIA: El valor que se le asigna a la historia del usuario en la que el dueo el producto asigna un determinado valor para la prioridad. ESTIMACION INICIAL: La valoracin inicial del equipo acerca de cuanto trabajo es necesario para implementar la historia, comparado con otras historias. COMO PROBARLO: Una descripcin de alto nivel de cmo se demostrara esta historia al final del Sprint. 2.6.1.2 HISTORIAS DE USUARIOSon las descripciones de las funcionalidades que va tener el software, tambin sern el resultado de la colaboracin entre el cliente y el equipo, e irn evolucionando durante toda la vida del proyecto.Las historias de usuario se componen de tres fases denominadas Las 3C: Card: Sera una breve descripcin escrita que servir como recordatorio. Conversation: Es una conversacin que servir para asegurarse de que se ha entendido bien todo, y concretar el objetivo. Confirmation: Test funcionales para fijar detalles que sern relevantes e indicar cul va ser el lmite.

Fig.2.2 Historias de UsuarioFuente: http//devnettips.blogspot.com.es ID: Identificador de la historia de usuario TITULO: Titulo descriptivo de la historia de usuario DESCRIPCION: Descripcin sintetizada de la historia de usuario. ESTIMACION: Evaluacin del coste de implementacin en unidades de desarrollo. Estas unidades representaran el tiempo terico (desarrollo / hombre) que se haya estimado al comienzo del proyecto. PRIORIDAD: Prioridad en la implementacin de la historia de usuario respecto al resto de las historias de usuario. A mayor tiempo mayor prioridad, otra aproximacin a la priorizacin de las tareas se hace a travs del mtodo MoSCoW. M Must, se debe completar ese requerimiento para finalizar el proyecto. S Should, se debe completar este proyecto por todos los medios, pero el xito del proyecto no depende el. C Could, se debera completar este requerimiento si su implementacin no afecta la consecucin de los objetivos principales del proyecto. W Would, se puede completar este requerimiento si sobra tiempo de desarrollo (o en futuras versiones del mismo) DEPENDENCIAS: Una historia de usuario no debera ser dependiente de otra, pero a veces es inevitable. Tomando en cuenta que la determinacin de los requerimientos es el ncleo para el desarrollo de un proyecto y es precisamente el Product Backlog que recurre a las historias de usuario se detallara las historias de usuario ms sobresalientes que servirn como requisito del sistema.2.6.2 PILA DEL SPRINT (SPRINT BACKLOG): Se define Sprint como una iteracin que dura alrededor de 30 das. La pila del Sprint es una lista de las tareas que debe realizar el equipo durante esta iteracin para generar el incremento previsto. El Sprint Backlog se sita en el rea de especificacin de los requisitos de software necesarios para dar respuesta a las funcionalidades esperadas por el cliente cuyas caractersticas principales son: Debe contener las funcionalidades que se van a realizar durante el Sprint. El equipo debe estar comprometido a realizar dichas funcionalidades. Se debe asignar tareas a los distintos miembros del equipo del proyecto. Se debe hacer una estimacin de cada funcionalidad El tamao de cada tarea esta en el rango de 4 a 16 horas de trabajo. Debe ser visible para todo el equipo, idealmente en una pizarra o l espacio fsico conveniente a donde trabaja el equipo.2.6.2.1 PLANIFICACION DEL SPRINTLa planificacin del Sprint es una reunin critica, probablemente la ms importante de Scrum, una planificacin de Sprint mal ejecutado puede arruinar por completo todo el Sprint.El propsito de la planificacin de Sprint es proporcionar al equipo suficiente informacin como para que puedan trabajar en paz y sin interrupciones durante unas pocas semanas y ofrecer al dueo del producto suficiente confianza. La siguiente figura solo muestra cmo debera realizarse en una hoja de clculo como Excel un Sprint

Fig.2.3 - Ejemplo de Pila de Sprint con hoja de ClculoFuente: Gestin Tcnica de Proyecto [Juan Palacios, 2013]La planificacin del Sprint produce concretamente: Una meta de Sprint Una lista de miembros (y su nivel de dedicacin en porcentaje) Una pila de Sprint (Lista de historias incluidas en el Sprint)2.6.2.2 COMO HACEMOS EL SPRINT BACKLOG (PILA DEL SPRINT)Existe varios formatos para la elaboracin del Sprint Backlog desde pizarras, hojas de clculo o herramientas colaborativas; y entre estas es eleccin del equipo cual es la mejor que se adecua a las caractersticas del proyecto, una recomendacin que da esta metodologa es disear el formato ms cmodo para todos incluyendo ciertos criterios: Lista de tareas, persona responsable de cada una, estado en que se encuentra y tiempo restante que queda para completarlo. Solo incluye informacin estrictamente necesaria. El medio y modelo elegido es la opcin posible que ms facilita la consulta y comunicacin diaria y directa del equipo.2.6.3 INCREMENTO: Es el resultado de cada Sprint, cuyas caractersticas principales son: Es parte del producto desarrollado en un Sprint. Debe estar en condiciones de ser usado. Es una funcionalidad.2.7 MODELO DE PROCESO SCRUM.Scrum es una metodologa de desarrollo muy simple, que requiere trabajo duro, porque la gestin no se basa en el seguimiento de un plan, sino en la adaptacin continua a las circunstancias de la evolucin del proyecto.Scrum es una metodologa gil: Es un modo de desarrollo de carcter adaptable. Orientado a las personas antes que a los procesos. Cada funcionalidad del product backlog, se refiere a funcionalidades entregables, no a trabajos internas del tipo diseo de la base de datos. Emplea desarrollo gil: iterativo e incremental.El desarrollo se inicia desde la visin general del producto, dando detalle solo a las funcionalidades que son de mayor prioridad para el negocio que van a ser desarrollada en primera instancia dentro un periodo de tiempo breve (entre 15 y 60 das).Cada uno de los ciclos de desarrollo es una iteracin (sprint) que produce un incremento terminado y operativo del producto. Estas iteraciones son la base del desarrollo gil, y Scrum gestiona su evolucin a travs de reuniones breves de seguimiento en las que todo el equipo revisa el trabajo realizado desde la reunin anterior y el previsto hasta la reunin siguiente.Sin embargo suele ser una excepcin habitual el primer sprint, en el que los objetivos del tipo contrastar la plataforma y el diseo pueden ser normales, e implican trabajos de diseo, desarrollo de prototipos para probar la solvencia de la plataforma que se va a emplear, etc.Tomando en cuenta estas consideraciones el incremento resulta ser: parte del producto realizada en un sprint y potencialmente entregable: TERMINADA Y PROBADA.

2.7.1 COTROL DE LA EVOLUCION DEL PROYECTOScrum controla de forma emprica y adaptable la evolucin del proyecto, con las siguientes prcticas de la gestin gil:2.7.2 REVISION DE LAS ITERACIONESAl final de cada sprint o iteracin, se realiza una revisin con todas las personas implicadas en el proyecto. Este es el periodo mximo que se puede tardar en reconducir una desviacin del proyecto o de las circunstancias del producto.2.7.3 DESARROLLO INCREMENTALEn el proyecto no se trabaja con diseos o abstracciones, el desarrollo incremental implica que al final de cada iteracin se dispone de una parte del producto operativa que se puede inspeccionar y evaluar.2.7.4 DESARROLLO EVOLUTIVOComo modelo gil es muy til en entornos con incertidumbre e inestabilidad de requisitos; intentar predecir en las fases iniciales cmo ser el resultado final, sobre dicha prediccin desarrollar el diseo y la estructura del producto no es realista, porque las circunstancias obligaran a remodelar nuevamente en varias oportunidades. Scrum toma a la instabilidad como premisa y de esta manera es conveniente las prcticas de trabajo que se diseen, tienen que permitir la evolucin continua sin degradar la calidad de la arquitectura, que se ira generando durante el desarrollo del producto.2.7.5 AUTO ORGANIZACINDurante el desarrollo de un proyecto surgen las circunstancias impredecibles en todas las reas y niveles. La gestin predictiva confa la responsabilidad de su resolucin al gestor de proyectos, en Scrum los equipos son auto organizados, con margen de decisin suficiente para tomar las decisiones que consideren oportunas.

2.7.6 COLABORACIONLas prcticas y el entorno de trabajo gil facilitan la colaboracin abierta entre todos segn los conocimientos y capacidades de cada persona y no segn su rol o puesto. Los componentes y conceptos empleados en Scrum son:2.7.7 LAS REUNIONES Planificacin del Sprint: Jornada de trabajo previo al inicio a cada sprint en la que se determina cual es el trabajo y los objetivos que se deben cubrir con esa iteracin. Seguimiento del Sprint: Breve reunin diaria para dar repaso al avance de cada tarea y al trabajo previsto para la jornada. Revisin de Sprint: Anlisis y revisin del incremento generado. Esta reunin no debe tomarse como un acontecimiento especial, sino como la presentacin normal de los resultados.

Fig. 2.4 Desarrollo de Software ScrumFuente: Gestin Tcnica de Proyecto [Juan Palacios, 2013]2.7.8 LOS ROLES O RESPONSABILIDADESEl grado de funcionamiento de Scrum en la organizacin depende directamente de estas tres condiciones: Caractersticas del entorno (organizacin del proyecto) adecuadas para el desarrollo gil. Conocimiento de la metodologa de trabajo en todas las personas de la organizacin y las implicadas del cliente. Asignacin de responsabilidades Del producto Del desarrollo Del funcionamiento de la metodologa Scrum2.7.9 RESPONSABILIDAD DEL PRODUCTO: PROPIETARIO DEL PRODUCTOEn el proyecto hay una persona, y solo una capaz de conocer cmo funciona el entorno del cliente desde la visin del producto. Representa a todos los interesados del producto final y al mismo tiempo es responsable del Product Backlog, a este suele denominar como propietario del producto; que a su vez tiene la responsabilidad de obtener el resultado de mayor valor posible para el usuario o cliente.2.7.9.1 RESPONSABILIDAD DEL DESARROLLO DEL EQUIPOTodo el equipo de desarrollo, incluido el propietario del producto conoce la metodologa y son directamente los autnticos responsables del resultado. Es un equipo multidisciplinar que cubre todas las habilidades necesarias para generar el resultado.2.7.9.2 RESPONSABILIDAD DEL FUNCIONAMIENTO DE SCRUMLa organizacin debe garantizar el funcionamiento de los procesos, metodologas que emplea, es en este aspecto que Scrum no es una excepcin. Es una metodologa que se garantiza integrando en el equipo una persona con el rol de Scrum Master.Considerando que las realidades de unas y otras empresas pueden ser muy diferentes es muy adecuado el uso de la metodologa Scrum que puede adaptarse a los cambios continuos en los requisitos.2.7.10 PRINCIPALES ELEMENTOS DE LA METODOLOGIAI. HERRAMIENTAS Product Backlog Sprint BacklogII. PRACTICAS Sprints Sprints Planning Meeting Daily Meetings Sprint Review Meeting Desing Review Meeting Stabilization SprintIII. ROLES Y RESPONSABILIDADES Scrum Master Product Owner Scrum Team Customer ManagementLa figura 2.5 muestra a la metodologa como un resultado sencillo al definir algunos roles y artefactos que contribuyen a tener un proceso que maximiza el feedback que sirva para mitigar cualquier riesgo que puede presentarse.

Fig. 2.5 Descripcin de roles, artefactos, reuniones y procesos de desarrollo de ScrumFuente: William C. Wake

2.8 FASES DE LA METODOLOGIA SCRUMEl ciclo de vida Scrum est compuesto de tres fases: Pre Game, Game y Post Game.[AISI, 2007]

Investigar para complementar o copiar de 1

Figura 2.6 Ciclo de Vida SCRUMFuente: Carlos Reynoso UNIVERSIDAD DE BUENOS AIRES2.8.1 PRE GAME: Fase en la cual se divide en otras dos sub fases: Planificacin y Arquitectura.2.8.1.1 Planificacin:Consiste en la definicin del sistema que ser construido, para esto se crea la lista Product Backlog a partir del conocimiento actual que se tiene del sistema. En ella se expresan los requerimientos priorizados y a partir de ella se estima el esfuerzo requerido.En esta etapa tambin todos los miembros del equipo incluyendo el cliente contribuyen a la creacin de una lista de caractersticas del sistema, que servirn en el anlisis y la conceptualizacin del problema.Dentro las tareas que debe efectuarse en esta primera etapa son: La recopilacin de requerimientos para conformar el Product Backlog, priorizados de acuerdo a una evaluacin del cliente. Definicin de fechas de entrega del sprint y las funcionalidades que se requiere. Anlisis de riesgos y controles apropiados para los riesgos.Seleccin de las herramientas y de la infraestructura del desarrollo. Cabe indicar tambin que la Lista del Product Backlog es actualizada constantemente con nuevos tems y ms detalles de los requerimientos, tambin se realiza las estimaciones precisas y los cambios en la prioridad de los tems que pueda existir.2.8.1.2 Arquitectura:El diseo de alto nivel del sistema se planifica a partir de los elementos existentes en la lista del Product Backlog. En caso de que el producto a construir sea una mejora a un sistema ya existente, se identifican los cambios necesarios para implementar los elementos que aparecen en la lista Product Backlog y el impacto que pueden tener estos cambios.2.8.2 GAMEUna vez realizada la especificacin correspondiente, se lleva a cabo la elaboracin del proyecto, con un seguimiento continuo a cargo del mismo grupo de desarrollo. En cada iteracin del GAME se realiza las siguientes tareas:a. Planeacin del Sprint: Antes de comenzar cada sprint o iteracin se lleva a cabo dos reuniones consecutivas, en la primera se refina y se prioriza nuevamente el backlog del producto, adems de elegir las metas de la iteracin. En la segunda reunin se deben considerar como alcanzar los requerimientos y crear el backlog del sprint.b. Desarrollo de Sprints: El trabajo generalmente se organiza en iteraciones de 30 das (sprints). Es el desarrollo de la nueva funcionalidad para el producto, esta fase provee la documentacin del backlog del Sprint con las actividades realizada por los responsables y la duracin de cada actividad.c. Revisin del Sprint: Al final de cada iteracin se lleva a cabo una reunin de revisin, donde se presenta la nueva funcionalidad del producto, las metas incluyendo la informacin de las funciones, diseo, ventajas, inconvenientes y esfuerzos del equipo.2.8.3 POST GAMELuego de haber culminado todas las iteraciones, resta la revisin final, denominada segn esta metodologa como cierre.a. Cierre: Es la ltima etapa donde se realiza la preparacin operacional, incluyendo la documentacin final necesaria para la presentacin. Tambin en esta fase se debe realizar dependiendo del tipo de producto ya sea el entrenamiento del personal (usuarios) o el marketing para la venta del nuevo producto.2.9 METODOLOGIA AUP (Agile Unified Process).El proceso unificado gil (AUP) es una versin simplificada de RUP (Rational Unified Process) desarrollada por Scott Ambler. Describe un enfoque simple y fcil de entender, desarrollo del software de aplicacin de negocios usando tcnicas agiles. AUP aplica tcnicas agiles incluyendo desarrollo orientado a pruebas (TDD) modelado gil (AM) gestin de cambios gil y refactorizacin de bases de datos para mejorar la productividad y tener una documentacin necesaria y suficientemente bueno para el entendimiento del problema y el desarrollo de la solucin. A continuacin se describen algunos principios del desarrollo gil de software (Agile Development) que son apropiados para el desarrollo de la herramienta y que justifican la eleccin de AUP como la metodologa de la solucin.2.9.1 EVOLUCIN DE REQUERIMIENTOS.Si bien al inicio de todo desarrollo de software se busca capturar todos los requerimientos, existen factores externos que ocasionan que dichos requerimientos cambien, evolucionen o aparezcan otros de acuerdo a nuevas necesidades. Esto a su vez conlleva a realizar cambios en los modelos de anlisis y diseo para adecuarlos a los nuevos requerimientos. Tomando en consideracin lo descrito anteriormente, se busca capturar esos nuevos requerimientos y darles la apropiada prioridad para no perjudicar el trabajo que pudo haber avanzado durante ese tiempo.a) Desarrollar el producto en pequeas iteraciones y liberar versiones del producto en tiempos incrementales.Con esta caracterstica, se espera ir implementando por iteraciones una cierta cantidad de funcionalidades de manera que se puedan realizar pruebas y analizar si se estn cumpliendo con los requisitos.b) Realizacin de pruebas a lo largo del ciclo de desarrollo del software.A diferencia de metodologas tradicionales, el desarrollo gil de software propone realizar pruebas a lo largo de todo el desarrollo mediante la implementacin de unidades de pruebas que puedan ser reutilizadas, asegurando de que todas las caractersticas estn funcionando correctamente durante la liberacin de pequeas versiones y de la liberacin del producto final.Los artefactos de software necesarios para el entendimiento de la solucin estarn basados en los diagramas UML correspondientes, los cuales sern descritos en cada fase de la metodologa.2.10 DESARROLLO DE LA METODOLOGIA.Como se mencion anteriormente, la metodologa para desarrollar la aplicacin es AUP, cuyo ciclo de vida se muestra en la figura 2.7. Posteriormente, se explicara la derivacin de su proceso mediante las fases y disciplinas que posee la metodologa.

Figura 2.7 Ciclo de vida de AUP Fuente: Scott W. Ambler Agile UP2.10.1 FASE DE INCEPTION.El objetivo de esta fase es la de establecer un alto nivel los requerimientos de la aplicacin, los cuales van a ser modelados en un diagrama de casos de uso y su correspondiente especificacin.Adems durante esta fase inicial se realizaran las estimaciones de costo o programacin de tareas (las cuales ya han sido establecidas con Scrum). Con dicha informacin se pueden establecer las iteraciones de desarrollo para la fase de construccin, las cuales sern descritas posteriormente.Adicionalmente, se deber establecer una lista de los riesgos del proyecto ordenados por prioridad de tal manera que los riesgos de alta prioridad sean mitigados durante las primeras iteraciones y evitar obstaculizar el desarrollo del producto durante las fases posteriores. 2.10.2 FASE DE ELABORACIN.El principal objetivo de esta fase es elaborar y probar la arquitectura del sistema, dicha arquitectura deber satisfacer los requerimientos ya definidos y servir como basa para la fase de construccin. Para ilustrar la arquitectura del sistema a travs de distintas capas y cmo estas interactan entre ellas.2.10.3 FASE DE CONSTRUCCIN.Esta fase corresponde al desarrollo en s de la aplicacin, precio a la codificacin y las pruebas de calidad. Para esta fase se han establecidos 3 iteraciones de acuerdo a lo establecido en la fase de incepcin y a la planificacin del proyecto: Iteracin N 1: Comprende la codificacin de las funcionalidades relacionados a la conexin hacia las fuentes de datos origen y destino. Iteracin N 2: comprende la codificacin de las funcionalidades relacionadas y establecidas por el segundo Sprint. Iteracin N 3: comprende la codificacin de las funcionalidades relacionadas y establecidas por el tercer y ltimo Sprint del proyecto.En paralelo con la codificacin, se implementaran las pruebas necesarias para probar cada funcionalidad, de manera que una vez terminada una iteracin, las funcionalidades implementadas pueden ser corroboradas y en caso de que sea necesario, se hagan las correcciones pertinentes. Para llevar a cabo este trabajo, se realizaran los siguientes tipos de pruebas: Pruebas de aceptacin. Permitirn corroborar que los requerimientos han sido resueltos de manera satisfactoria. Unidades de Prueba (Unit Test). Son pruebas de caja blanca que verifican que el cdigo para implementar una funcionalidad sea el correcto. Estas pruebas verifican el comportamiento del sistema a un bajo nivel (nivel de cdigo), as como verificar que el diseo sea correcto. Estos tipos de pruebas suelen ser independientes de las funcionalidades pues verifican el cdigo fuente.La eleccin de ambos tipos de pruebas se justifica en el hecho de que son complementarias y necesarias. Las pruebas de aceptacin permitirn verificar que los requerimientos se estn implementando, mientras que las unidades de prueba verificaran que el cdigo no contenga errores.2.10.4 FASE DE TRANSICIN.En esta etapa, se continuaran con el conjunto de pruebas definidos en las fases anteriores previo a la puesta en produccin de la herramienta. En caso de ser necesario, se realizaran algunos arreglos a la codificacin de acuerdo al resultado de las pruebas.2.11 DISCIPLINAS DEL AUP: AUP tiene siete disciplinas que describiremos a continuacin: 2.11.1 MODELADO: Entender el negocio de la organizacin, tratar el dominio del problema e identificar una solucin viable para tratar el dominio del problema.2.11.2 IMPLEMENTACIN: Transformar el modelo en cdigo ejecutable y realizar un nivel bsico de pruebas, en particular pruebas unitarias.2.11.3 PRUEBAS: Realizar una evaluacin objetiva para asegurar calidad. Esto incluye encontrar defectos, validar que el sistema funciona como fue diseado y verificar que se cumplen los requisitos.2.11.4 DESPLIEGUE: Planificar el despliegue del sistema y ejecutar el plan para poner el sistema a disposicin de los usuarios finales.2.11.5 GESTIN DE CONFIGURACIN: Gestin de acceso a los artefactos del proyecto. Esto no solo incluye el seguimiento de las versiones de los artefactos sino tambin controlar y gestionar los cambios en ellos.2.11.6 GESTIN DE PROYECTO: Direccin de las actividades que tienen lugar dentro del proyecto. Esto incluye gestionar riesgos, dirigir a las personas y coordinar las personas y sistemas fuera del alcance del proyecto para asegurar que se entrega a tiempo y dentro del presupuesto.2.11.7 ENTORNO: Soporte del resto del esfuerzo asegurando que el proceso, la orientacin (estndares y guas) y las herramientas (software, hardware) adecuadas estn disponibles para el equipo cuando son necesarias.2.12 .NET FRAMEWORK.Para describir los principales conceptos con la plataforma de desarrollo escogida para esta investigacin, se comienza con un panorama general del .NET Framework desde su surgimiento, sus principales componentes hasta su implementacin para entornos libres mediante el proyecto MONO[footnoteRef:2], para despus centrarse en ASP.NET que es su mdulo para el desarrollo web y terminar con la descripcin de su modelo de conexin a datos desconectado llamado ADO.NET. [2: Mono es el nombre de un proyecto de cdigo abierto impulsado por Novell para crear un grupo de herramientas libres, basadas en GNU/Linux compatibles con .NET]

2.12.1 PLATAFORMA. NET.El .NET Framework representa un cambio importante en el modo de generar y ejecutar las aplicaciones web. Es importante recalcar que ASP.NET es una de las mltiples tecnologas que forman parte del .NET Framework. Toda la informacin contenida en este apartado est basada en el documento publicado por Microsoft.

Microsoft define a .NET como un modelo de desarrollo que hace que el software sea independiente de la plataforma y de los dispositivos, y que hace que los datos estn disponibles a travs de internet. Por lo consiguiente, el .NET Framework es la infraestructura bsica subyacente de .NET.Microsoft asegura que .NET fue implementado desde un principio pensado en una arquitectura abierta .NET es una plataforma que puede utilizarse para generar y ejecutar la siguiente generacin de aplicaciones de escritorio y aplicaciones web. El objetivo de la plataforma .NET de Microsoft es simplificar del desarrollo web.2.12.2 ASP.NET.ASP.NET es un marco de programacin basado en el .NET Framework que se utiliza para generar aplicaciones Web. Los formularios Web Forms ASP.NET, que forman parte de una aplicacin Web ASP.NET, proporcionan un modo fcil de generar sitios Web dinmicos. ASP.NET tambin incluyen la tecnologa necesaria para generar servicios Web XML, que proporcionan los bloques bsicos para construir aplicaciones distribuidas basadas en la web.

Figura 2.9 Elementos de una aplicacin ASP.NETFuente: Microsoft, 2001

2.13 LENGUAJE UNIFICADO DE MODELADOUML es un lenguaje de modelado visual que permite especificar, visualizar, construir y documentar componentes que forman parte de un sistema de software orientado a objetos. Cualquier proceso de software basado en UML debe contar con las siguientes caractersticas principales: Debe ser iterativo e incremental, centrndose en los aspectos crticos en las primeras iteraciones para minimizar riesgos para el futuro. Debe ser guiado por los requisitos (casos de uso) y preparado para identificar nuevos o modificar requisitos a lo largo de todo el ciclo de vida. Tener un enfoque industrial para la produccin de software capacidad de producir productos de alta calidad a bajo costo. La arquitectura debe estar basada en componentes. La notacin de modelado debe ser visual, facilitando la gestin de modelos, ayudando a mantener la consistencia entre los elementos del sistema y colaborando a mejorar la habilidad del equipo de desarrollo para manejar la complejidad del software. Debe existir un control de cambios de software para evitar un caos, especialmente en la comunicacin entre los equipos de desarrollo, guardando la consistencia del desarrollo del sistema. Debe poderse evaluar continuamente la calidad de un sistema de software con respecto a su funcionalidad, fiabilidad, rendimiento de la aplicacin y del sistema. 2.13.1 VISTAS UML.Una vista es un conjunto de notacin UML que modela construcciones que representa un aspecto de un sistema de distintas perspectivas con distintos diagramas, utilizando conjuntos separados de vistas, para representar proyecciones del sistema relacionados con aspectos particulares funcionales y no funcionales para el modelado de la arquitectura de un sistema (ver figura 2.10 )

Figura: 2.10 - modelo de la arquitectura de un sistema mediante vistasFuente: [ALARCON, 2000]Los conjuntos de Vista para modelar un sistema son:a) Vista de Casos de Uso Es el hilo conductor de todo el proceso de desarrollo, describiendo el comportamiento, con los diagramas de casos de uso que muestra la funcionalidad del sistema.b) Vista Diseo Muestra el diseo del sistema con dos aspectos esenciales; el primer aspecto es la estructura, es decir los comportamientos que lo integran, para lo cual utiliza los diagramas de clases. El segundo aspecto es el comportamiento del sistema es la dinmica de interaccin de dichos componentes, utilizando el diagrama de secuencia. Esta vista es aplicada durante la fase de diseo y desarrollo del sistema.c) Vista de ProcesosMuestra la organizacin del cdigo y dems archivos parte del sistema, archivos desarrollados o adquiridos y la dependencia entre ellos, utilizando para ello los diagramas de componentes.Las otras vistas no se utilizaran porque Scrum se basa ms en el desarrollo del proyecto que en la documentacin.2.14 APLICACIONES WEB.Las aplicaciones basadas en la web son muy diferentes de las otras categoras de software, pues estas se caracterizan por residir en una red (sea intranet o extranet) y deben dar servicio a una comunidad diversa de clientes, adems de que deben tener una evolucin continua. [Pressman, 2005].2.15 METRICAS DE CALIDADLa calidad de software es la concordancia con los requisitos funcionales y de rendimiento explcitamente establecidos, con los estndares de desarrollo y con las caractersticas implcitas que se espera de todo desarrollo de software.El estndar ISO 9126 ha sido desarrollado en un intento de identificar los 6 atributos clave de calidad para el software: Funcionalidad de mantenimiento, portabilidad, confiabilidad y eficiencia.2.15.1 FUNCIONALIDADSe trata de identificar la capacidad que el producto software tiene para proporcionar funcionalidades que satisfagan las necesidades especificadas; y como no puede ser medida directamente, debe ser medido indirectamente de otras medidas directas como ser el punto funcin propuesto por Albretch.Para el clculo de esta mtrica se determina los valores de las cinco caractersticas de dominio de informacin que asocia a estos dominios un valor de complejidad en funcin a la siguiente relacin:

0.65: valor de ajuste de complejidad mnimo.0.01: factor de conversin con un error de 1%2.15.2 CONFIABILIDADEs la probabilidad de operacin libre de fallos de un programa en un entorno determinado y durante un tiempo especfico.O podramos decir que es lo que se puede esperar de un programa lleve a cabo su funcin con exactitud requerida. Estadsticamente es la probabilidad de operacin libre de fallos de un programa de computadora en un entorno determinado y un tiempo especfico.Para el clculo de la confiabilidad del sistema se utiliza la siguiente ecuacin:

Dnde:

Para hallar la probabilidad de falla del sistema en el periodo, se utiliza la funcin exponencial dada por: En donde

2.15.3 MANTENIBILIDADLa facilidad de realizar una modificacin, indicada por los siguientes sub atributos: facilidad de anlisis, facilidad de cambio establecido y facilidad de prueba.Este Factor de calidad viene dado segn el estndar IEEE 982 1998 y por la mtrica del ndice de madurez del software (IMS) que proporciona una indicacin de la estabilidad del producto software, basada en el cambio que ocurre en cada versin del producto. Calculamos el ndice de madurez de software con la siguiente relacin:

Dnde:

A medida que el IMS se aproxima a 1, el producto se empieza a estabilizar.2.15.4 USABILIDADGrado en el que el software es fcil de usar, se mide a travs del esfuerzo necesario para aprender a utilizar el sistema, ya sea segn su interfaz o manual de usuario. Se lo calcula mediante el porcentaje de una encuesta elaborada a un cierto nmero de clientes2.15.5 PORTABILIDADEs el esfuerzo necesario para transferir el programa de un entorno de sistema hardware y/o software a otro.El grado de portabilidad del sistema est dado por la siguiente ecuacin:

Dnde:

2.16 METRICAS PARA APLICACIONES WEBLas mtricas que se emplean en los sistemas de informacin tradicionales son difciles de aplicar directamente en aplicaciones web, debido a esto se propone el uso de las siguientes medidas que servirn para la definicin de mtricas orientadas a aplicaciones web [Pressman, 2006]:2.16.1 Nmero de pginas web estticas (NPE).- Las pginas web estticas son aquellas en las que el usuario no controla el contenido de la pgina de la pgina. Estas pginas representan una complejidad relativamente baja y por lo general requieren de menos esfuerzo al construirlas.2.16.2 Nmero de pginas web dinmicas (NDP).- Las pginas web dinmicas son aquellas en las que las acciones del usuario generan contenido personalizado. Estas pginas representan una mayor complejidad y requieren ms esfuerzo que las pginas estticas. Estas dos medidas proporcionan un indicio del tamao global de la aplicacin y el esfuerzo necesario para desarrollarla.2.16.3 Nmero de vnculos internos de la pgina (NVI).- Los vnculos internos de la pgina son hipervnculos que ofrecen un enlace hacia otra pgina dentro la aplicacin web. Esta medida proporciona un indicio del grado de acoplamiento arquitectnico dentro de la aplicacin web.2.16.4 Nmero de objetos de datos persistentes (NOP).- Una aplicacin web puede tener acceso a uno o ms objetos de datos persistentes como bases de datos o archivos. Esta medida proporciona un indicio de la complejidad de la aplicacin web. En base a estas medidas se pueden definir las siguientes mtricas:

Este ndice vara entre cero y uno dependiendo del grado de personalizacin que la aplicacin web ofrece al usuario.

El grado de acoplamiento indica cuan relacionadas estn las pginas de la aplicacin web. Si el valor obtenido es cero significa que no existe acoplamiento entre las pginas de la aplicacin web, si este valor es 1 significa que en promedio cada pgina contiene un hipervnculo hacia alguna otra pgina de la aplicacin web, y as sucesivamente dependiendo del nmero de vnculos que se tengan en la aplicacin web.

El grado de complejidad indica cuan compleja es la aplicacin web. Si el grado es menor a 1 la complejidad no es mucha pues el nmero de pginas web es inferior al nmero de objetos persistentes. El grado de complejidad crece si es mayor a 1, pues existirn ms pginas web que actuaran sobre los objetos persistentes.2.17 PRUEBAS PARA APLICACIONES WEBSe realizan pruebas a un producto software con el propsito de encontrar errores y finalmente corregirlos. Dado que las aplicaciones web residen en una red inter operan con muchos sistemas operativos diferentes navegadores, plataformas de hardware, protocolos de comunicacin, la bsqueda de errores es todo un reto para los desarrolladores. Las etapas que se debe seguir para la prueba de aplicacin son las siguientes [Pressman, 2005]:1.- El modelo de contenido de la aplicacin web es revisado para descubrir errores, para esto se debe revisar las pginas en busca de errores tipogrficos y gramaticales.2.- El modelo de diseo de la aplicacin web es revisado para descubrir errores de navegacin, los enlaces de navegacin son revisados para verificar su correspondencia.3. Se aplican pruebas de unidad a los componentes de proceso. Las pruebas de unidad se encargan de verificar la menor unidad de diseo de software, en este caso una pgina web. Para esto se comprueban los procesos encapsulados en la pgina utilizando una tcnica de prueba de software. Una de estas tcnicas es la del camino bsico, que consiste en hallar la complejidad ciclomatica del programa, este valor representa el nmero de caminos de ejecucin y el lmite superior para el nmero de pruebas que se debe realizar.4. Se construye la arquitectura y se realizan las pruebas de integracin, para esto se pueden usar casos de pruebas basados en los casos de uso.5. Luego de ensamblar la aplicacin web se realizan las pruebas de seguridad tomando en cuenta los criterios de seguridad observados.6. La aplicacin web se implementa en una variedad de configuraciones de diferentes entornos, para as comprobar su compatibilidad con cada configuracin. Se pueden usar diferentes sistemas operativos, navegadores y plataformas de hardware.7. La aplicacin web se prueba con una poblacin de usuarios finales controlada y monitorizada, luego se evalan los resultados de su integracin con el sistema. Dado que las aplicaciones web estn en constante evolucin, el proceso de comprobacin es una actividad continua.

En este captulo se va abordar la utilizacin de las fases en lo que compete la Determinacin de Requerimientos del sistema y la Planificacin del proyecto por medio de Scrum en su fase Pre Game, as mismo se definir el alcance del Proyecto, definir los riesgos, la arquitectura del sistema, lo que es la fase Inicial de AUP tambin comprende la modelacin de los requerimientos por medio de diagrama de Casos de Uso.3. 1 FASE PRE GAME (SCRUM) FASE INCEPTION (AUP)Scrum por definicin no requiere documentacin con diagramas de casos de uso ni diagramas de secuencia, pero asume la existencia de Diseo y cdigo Orientado a Objetos basado en libreras y clases.Con AUP para una mejor comprensin del sistema utiliza de acuerdo a lo que sea conveniente al proyecto los diagramas ms representativo de UML nivel 1, y en esta fase para la representacin y comprensin de los requerimientos utilizaremos los Diagramas de Casos de Uso3.1.1 OBJETIVOS DEL PROYECTOEl objetivo principal del presente proyecto es la implementacion de un software que reemplace a la planilla de excel que se tiene actuamente, y que la implementacion debe considerar el tiempo minimo para su implementacion.3.1.2 COMPROMETIDOS CON EL PROYECTO.Para el desarrollo de la aplicacin y siguiendo la forma de organizacin de Scrum se conform un equipo de trabajo de acuerdo a los siguientes roles: Producto Owner. Representa la voz del cliente, asegurando que el equipo trabaje de forma adecuada desde la perspectiva del negocio, tambin es el que escribe todas las historias de usuario, las prioriza y las coloca en el Producto Backlog. Scrum Master o Facilitador. Su trabajo es eliminar los obstculos que impiden que el equipo alcance el objetivo del Sprint, asegurndose que el proceso Scrum se utilice como es debido. Equipo. Tiene la responsabilidad de entregar el producto cuyas habilidades transversales sern necesarias para realizar el trabajo. Usuarios. Es el destinatario final del producto. StakeHolders (Clientes, Proveedores, Inversores). Se refiere a los que hacen posible el proyecto y para quienes va producir el beneficio acordado. Managers. Es la gente que establece el ambiente para el desarrollo del producto.3.2 CONFORMACION DE LOS EQUIPOS.Para la conformacin de los equipos de trabajo se trat de seguir lo que Scrum necesita como mnimo para concluir el proyecto, pero como en nuestro caso es una empresa y especficamente una aplicacin para el rea de Activos Fijos dependiente de Contabilidad General y Gerencia Administrativa y Gerencia Financiera, se asign lo que son los roles de Scrum con el siguiente equipo:Product Owner Gerencia Financiera Ing. Hugo Arzabe AscarrunzMAXAM FANEXA S.A.M Gerencia Administrativa: Tcnl. Marco A. lvarez Daza.Scrum Master: Jair Samuel Ventura TovarEquipo: Jair Samuel Ventura Tovar Jefe de Sistemas: Ing. Alejandro Alvarado Foronda Jefe de Sistemas Planta Santivaez: Ing. Rodrigo Rojas Romero Contador General: Lic. Oscar Herbas Auditor Interno: Lic. Tagmina Thames SandovalUsuarios. (Gallinas)Responsable de Activos Fijos: Lic. Nohelia Vazquez DazaContabilidad de Costos: Lic. Ernesto Barrientos Lic. Griselda Ortiz CossioGerencia Financiera: Ing. Hugo Arzabe AscarrunzGerencia Administrativa: Tcnl. Marco A. lvarez Daza.3.3 DETERMINACION DE LOS REQUERIMIENTOSLa Determinacin de los Requerimientos en las metodologas clsicas de desarrollo de software vienen determinadas por una seria de documentos modelos que escapan a la esencia misma de Scrum que simplemente se basa en la recopilacin de estos requerimientos mediante la herramienta Historias de usuario que luego de las 2 reuniones que se tuvo con el equipo se determin realizar las siguientes historias de usuario.Tabla 3.1 Historias de Usuario del ProyectoHistoria de Usuario: H11Ingresar al Sistema

Como Gerente Financiero quiero que cada usuario que acceda al sistema se identifique con una cuenta y clave especifica.

Estimacin: 1 dia

Prioridad: AltaDependencia: -----

Cuando se introduzca una cuenta que no corresponda a la que se le dio automticamente el programa debe considerarlo como invitado. Debe considerar que solo debe existir las cuentas de administrador, contador, y encargado. La cuenta de contador debe ser la nica que pueda dar de baja un activo.

Historia de Usuario: H22Registro de Usuario Que al acceder al programa no muestre otras cuentas que no sean la que estn permitidas. Las cuentas permitidas para esta aplicacin solo deben ser Administrador, Encargado, Contador e Invitado. Cada usuario de esta lista solo debe poder hacer ciertas operaciones.

Como Gerente Financiero quiero que cada usuario que manipule el sistema sea registrado previamente para un mejor control.

Estimacin: 1 dia

Prioridad: MediaDependencia: H1

Historia de Usuario: H3

3Generacin de Cdigo Cada activo debe diferenciarse plenamente con esta nueva clasificacin. Tambin por el tema de crecimiento de activos debe contener otros 4 dgitos ms. Al ingresar una bsqueda por la codificacin asignada no debe repetirse ni existir coincidencia.

Como Gerente Financiero quiero la codificacin este en funcin a la siguiente clasificacin: Tipo. Grupo y Sub - Grupo.

Estimacin: 3 dias

Prioridad: AltaDependencia: ---

Historia de Usuario: H44Asignacin de Activos Cuando se haga la bsqueda de un activo especfico debe mostrarse la informacin correspondiente. Cada activo nuevo que se ingresa debe contener en qu lugar se encuentra este activo. Al realizar las diversas operaciones tambin debe mostrarse quien tiene el activo.

Como Gerente Administrativo quiero que cada activo asignado se especifique a quien se lo entrega y en donde se encuentra.

Estimacin: 3 dias

Prioridad: AltaDependencia: H15

Historia de Usuario H55Calcular Depreciacin Al realizar esta operacin debe ser idntica a la planilla echa en Excel. Las formulas deben ser elaboradas por la parte contable y auditoria. Cuando se realice el clculo de la depreciacin debe seguirse y tomar en cuenta el acceso de la UFVs. Se debe dejar la posibilidad de cambiar a futuro a otros mtodos de depreciacin.

Como Gerente Financiero quiero que las depreciaciones se lo realice por el mtodo de lnea recta para la mayora de los activos y por horas trabajada a maquinaria.

Estimacin: 5 dias

Prioridad: AltaDependencia: H6

Historia de Usuario: H66Ingresar Tipo de Cambio Al momento de ingresar los datos al sistema cada activo debe contar con su UFV inicial y su UFV final. Para el ingreso de estos valores para las plantas debe ingresar tambin los porcentajes para la depreciacin.

Como Gerente Financiero quiero que el tipo de cambio este en funcin a las UFVs del da de compra y del momento en que se realiza la operacin de depreciar.

Estimacin:

Prioridad: MediaDependencia: H5

Historia de Usuario: H77Clasificar Activo La clasificacin debe mostrar diez dgitos para cada activo. Cuando los activos se revalorizan los activos debe diferenciarse del resto de los activos aadiendo una letra R al final.

Como Jefe de Sistemas quiero que la clasificacin siga el siguiente formato:Tipo: xx----Grupo: xx---Subgrupo: xx y el numero correlativo: xxxx

Estimacin:

Prioridad: AltaDependencia: H3

Historia de Usuario: H88Almacenamiento de los Datos Debe almacenarse la informacin de cada operacin y centros de costo. La construccin de la base de datos debe contemplar las normalizaciones respectivas. El almacenamiento debe realizarse un gestor libre. La planilla echa debe servir de base para la construccin y diseo de la base de datos.

Como Jefe de Sistemas quiero que se construya una base de datos relacional para el almacenamiento de la informacin generada durante la implementacin.

Estimacin:

Prioridad: AltaDependencia: ----

Historia de Usuario: H99Mostrar Reportes Los reportes deben ser idnticos a la planilla que utilizan cada unidad. Los reportes deben tener la posibilidad de migrar sus datos a Excel, texto y pdf. Cada reporte debe mostrarse de forma mensual y anual. Debe mostrarse reportes de activos deducibles y no deducibles.

Como Gerente Administrativo quiero que los reportes sean construidos en funcin a las unidades dependientes.

Estimacin:

Prioridad: AltaDependencia: H5, H6

Historia de Usuario 1010Revalorizar Activos Que cuando un activo termine su tiempo de vida, su valor residual permanezca en 1. La revalorizacin o restauracin debe realizarlo la parte contable.

Como Gerente Financiero quiero que exista la posibilidad de revalorizar un activo que ya haya terminado su tiempo de vida y aun est en condiciones

Estimacin:

Prioridad: AltaDependencia: H3, H7

Historia de Usuario: H1111Traspaso de Activos Que exista la posibilidad de buscar por medio del cdigo o nombre del activo. Debe existir la posibilidad de ver la regional juntamente su unidad de negocio y su centro de costo. Tambin debe buscarse por medio del C.I quien esta a cargo o a quien se lo asignara.

Como Gerente Financiero quiero que esta operacin se realice juntamente con la asignacin de cada activo.

Estimacin:

Prioridad: MediaDependencia: H4

Historia de Usuario: H1212Interfaz de Usuario Que al momento de ingresar sea lo mas idntico a la planilla echa en Excel para asi evitarse contratiempos en el manipuleo. Que contenga los mismos campos para el llenado de datos. Que las operaciones que se realicen ayuden y sean mas cortas.

Como Jefe de Sistemas quiero que el interfaz sea lo mas amigable posible y en lo posible utilizar templates existentes en internet.

Estimacin:

Prioridad: AltaDependencia:

Historia de Usuario: H1313Plataforma Tecnolgica Que al momento de subir al servidor esta aplicacin debe poder verse en cualquier Centro de Costo dependientes de Maxam. Se debe realizar una evaluacin y adecuarse a la plataforma que se cuenta en la empresa.

Como jefe de Sistemas quiero que se aproveche los servidores que cuenta la empresa y el desarrollo sea con herramientas libres de pago.

Estimacin:

Prioridad: MediaDependencia: H8, H12

Historia de Usuario H1414Registrar Regional Al momento de ingresar con cualquier cuenta que sea distinta a la del administrador, la aplicacin automticamente se desconecte. Solo la cuenta de administrador debe poder hacer las operaciones de registrar, modificar y eliminar estos datos. Se debe crear una tabla en la base de datos para esta informacin.

Como Jefe de Sistemas quiero que exista un modulo o men para ingresar datos a la Regional, Unidades de Negocio, Centros de Costos y plantas que puedan contar y se almacenen en la base de datos.

Estimacin 3 dias

Prioridad: AltaDependencia: H2

Historia de Usuario H1515Registrar Responsable Que al tratar de ingresar con otras cuentas la aplicacin se desconecte automticamente. La operacin debe estar limitada simplemente para el encargado de activos fijos. El registro de los responsables es para conocer quienes estn a cargo o manejando los activos.

Como Gerente Administrativo quiero que esta operacin lo realice el encargado de manejar ls activos fijos.

Estimacin: 4 dia

Prioridad: MediaDependencia: H2

Historia de Usuario: H1616Baja de un Activo Cuando el encargado o el administrador quiera hacer una baja, la aplicacin no se lo permita. La baja de un activo debe realizarse solo cuando el activo haya concluido su tiempo de vida.

Como Gerente Financiero quiero que esta posibilidad solo sea posible para el contador en el men de activos.

Estimacin 4 dias

Prioridad: AltaDependencia: H2,H5,H10

3.4 PRODUCT BACKLOG (PILA DEL PRODUCTO)La siguiente tabla contiene el product backlog resultante de las Historias de Usuarios que se rescat de los interesados, y como se mencion este product backlog no es una lista fija e invariable de requisitos funcionales del sistema, sino que esta lista es un documento sigue para recibir ms requerimientos en el desarrollo del sistema.

Tabla 3.2 Product Backlog del ProyectoIdPrioridadEstadoDescripcinEstimacin delEsfuerzo [das]Como Probarlo

H1AltaTerminadoAcceso de Usuarios3

H2MediaTerminadoRegistro de Usuarios2

H3AltaTerminadoGeneracin de Cdigo3

H4AltaTerminadoAsignacin de Activo2

H5AltaTerminadoCalcular depreciacin10

H6MediaTerminadoIngresar tipo de cambio5

H7AltaTerminadoClasificar Activos5

H8AltaTerminadoAlmacenar datos5

H9AltaTerminadoMostrar Reportes5

H10AltaTerminadoRestaurar Activos5

H11AltaTerminadoTraspaso de Activos5

H12AltaTerminadoInterfaz de Usuario3

H13MediaTerminadoPlataforma tecnolgica5

H14MediaTerminadoRegistrar Regional5

H15MediaTerminadoRegistrar Responsable2

H16AltaTerminadoBaja de Activos5

3.5 RELEASE PLAN: Tabla 3.3 Release Plan del ProyectoIteracinHistoria de UsuarioTiempo Estimado

1er. SprintH13: Plataforma Tecnologa4 semanas

H1: Acceso al Sistema

H2: Registro d Usuario

H12: Interfaz de Usuario

H8: Base de datos

H15: Registrar Responsable

2do. SprintH4: Asignacin de Activos4 semanas

H3: Generacin de Cdigo

H6: Ingresar Tipo de Cambio

H7: Clasificar Activo

H11: Traspaso de Activo

3er. SprintH5: Calcular Depreciacin5 semanas

H14: Registrar Regional

H10: Restaurar Activo

H16: Baja de Activo

H9: Mostrar Reportes

Esta planificacin es el Sprint 0 para dar comienzo a las iteraciones que se desarrollara en la fase Game del siguiente captulo.

3.6 ALCANCE DEL PROYECTOCon el presente proyecto se pretende obtener y contar con una herramienta que ayude en el clculo de la Depreciacin que se realiza actualmente con un planilla echa en Excel lo cual tambin sirve para realizar los cierres respectivos de cada mes en contabilidad y las respectivas unidades que requieran de los informes que se genera.3.6 .1 ESTIMACION DE COSTOS:La estimacin de los costos lo dejaremos para ms adelante, en cuanto se tenga los casos de uso del sistema que para la estimacin de los costos utilizaremos los puntos por casos de uso, que se detallara en el anexo A.3.7 ANLISIS DE RIESGO.Un riesgo es la probabilidad que exista algo adverso a lo planificado, de los cuales describiremos a continuacin:3.7. 1 Riesgo del Proyecto. Que afectan a la calendarizacin o recursos del proyecto.3.7.2 Riesgo del Producto. Que afectan a la calidad o rendimiento del software que se est desarrollando.3.7.3 Riesgo del Negocio. Afecta a la organizacin que desarrolla o suministra el software.El presente proyecto como cualquier otro proyecto no est libre de varios riesgos o dificultades que podra atravesar en el transcurso de su desarrollo, se describen a continuacin as como las estrategias que se propusieron para hacerlo frente.Tabla 3.4 Anlisis de RiesgosRiesgo TipoDescripcinProbabilidadEfectoEstrategia

No se cumple con las fechas establecidas en el cronograma.ProyectoProbablemente las fechas previstas en el cronograma no se cumplan a cabalidad.AltaTolerable Disear un cronograma flexible que considere los retrasos.

Cambio continuo en los requerimientos del cliente.Proyecto, productoPunto primordial de la metodologa para adaptarse continuamente a los cambios que pueda darse en el transcurso del proyecto.MediaTolerableRealizar una revisin constante de los requerimientos.Programar reuniones constantes con el cliente.

No se concluya con algunos de los requerimientos.ProductoPor el gran nmero de requerimientos y el poco tiempo de desarrollo no se cumpla alguno de ellos.Alto Tolerable Separar los mdulos en el sistema de tal forma que la ausencia de uno no afecte en el desempeo de los dems

No existen los equipos necesarios para la implementacin del sistema.El constante cambio de equipos hace que sea dificultoso desarrollar.Maxam Fanexa por el uso masivo de equipos y distribucin a sus centros es limitante el acceso a uno de ellos.Alto TolerableSolicitar a Gerencia Financiera que se otorgue un equipo para el desarrollo

No se cumple con el plazo de entrega del producto.ProductoEl plazo lmite de entrega del producto fue en el mes de diciembre, pero por cierre de gestin y vacacin colectiva abra un retraso en la entrega. Moderada Serio Agilizar los procesos de desarrollo.Realizar correcta planificacin de tiempos considerando los ingresos a planta.

3.8 IDENTIFICACIN DE LOS ACTORES DEL SISTEMA.Dentro los actores del sistema tenemos a los siguientes casi independientes de los otros:Administrador. Es el encargado de la administracin de la aplicacin quien al mismo tiempo realiza operaciones de: registro de nuevos usuarios, control y seguimiento de los activos fijos (bsquedas, reportes), pero no puede dar baja ningn activo, esto segn requerimiento del cliente.Encargado de Activos Fijos. Es el usuario del manejo de la aplicacin por lo tanto tiene acceso a todas las opciones de la aplicacin a excepcin de ingreso de nuevos usuarios y dar de baja algn activo.Contador. Es el encargado de hacer especficamente las bajas de los activos que ya terminaron su tiempo de vida, tambin puede hacer las otras operaciones que los dems a excepcin de crear nuevos usuarios.Invitado. Es cualquier otra persona de la empresa que solicite ver simplemente reportes para su uso en cada cierre de mes o gestin.Descripcin de los Actores.Tabla 3.5 Descripcin de Actores

ActorProceso

Administrador del Sistema Administracin de Usuarios Registro y Modificacin de perfiles de acceso. Bsquedas. Reportes. Registro y Modificacin de Regiones.

Contador Dar baja a los activos fijos Dems otras operaciones de encargado. Bsquedas. Reportes.

Encargado de Activo Registro de activos fijos Registro y modificacin de parmetros. Registro y generacin de reportes de inventario

Usuario de Reporte (Invitado) Solicitar y generar reportes

3.9 ENTORNO PARA EL DESARROLLO DEL PROYECTOPara el desarrollo del presente proyecto se hizo el siguiente requerimiento de software y verificacin de lo que contaba la empresa respecto a la arquitectura disponible para el desarrollo de la presente aplicacin:3.9.1 ESPECIFICACIN DE HARDWAREEl sistema trabaja bajo un entorno web (cliente servidor), mas propiamente esto funcionara en la INTRANET que cuenta la empresa al cual puede accederse desde cualquier Centro de Costo localizados en diferentes lugares del pas.Como requerimientos mnimos de hardware y software que debe considerarse para implementar esta aplicacin se debe tomar lo siguiente: 1 PC Pentium IV o superior Memoria RAM 512 MB.(recomendable 1GB para un buen rendimiento) Sistema Operativo Windows XP profesional Tener configurado el servicio de Internet del servidor IIS. Framework 2.0 Tener un navegador (internet Explorer 6 o superior, lo recomendable navegador mozilla firefox 3.x.x). Tener activado flash player 9_2_p2_32bit_plugin_111710 o superiorEstos requerimientos vienen a ser parte de los requerimientos no funcionales del sistema.

En este captulo se desarrollara la construccin de los sprint para cada iteracin planificada en el Relase Plan, la metodologa AUP para esta fase como en las anteriores apoyara en la representacin del sistema por medio de artefactos basados en UML, lo cual har ms comprensible al presente proyecto.4.1 FASE GAME (SCRUM) FASE ELABORATION Y FASE CONSTRUCTION (AUP)Como parte de la fase de construccin del modelo AUP se desarrollara la implementacin de las respectivas iteraciones ms las pruebas exigidas en esta fase.4.1.1 PRIMER SPRINT4.1.1.1 PLANIFICACION DEL SPRINTLa planificacin del Sprint es la jornada de trabajo previo al inicio de cada Sprint en la cual se determina que trabajo y objetivos que se debe conseguir en cada iteracin. La planificacin del Sprint dar como resultado: el objetivo del Sprint, la Pila del Sprint, la duracin del Sprint.Esta planificacin se lo realiza mediante dos reuniones divididas en dos partes:1ra Parte: Se realiza la estimacin de las funcionalidades que tengan mayor prioridad durante el Sprint.2da parte: Desglosar las funcionalidades en tareas con tiempos estimados Al mismo tiempo dispone de reuniones diarias de aproximadamente 10 minutos en la cual se formula las siguientes preguntas:Trabajo que se realiz el dia anterior?Trabajo que se tiene previsto realizarCosas que puede necesitar o impedimentos que debe suprimirse para realizar el trabajo.Para el presente trabajo se detalla a continuacin

4.1.1.2 OBJETIVO DEL SPRINTEl objetivo del primer sprint es mostrar la pgina principal con toda la estructura que se agregara en los siguientes Sprint como ser: acceso al sistema, registro de usuario, la interfaz que se mostrara y comienzo de la base de datos que se tendr. La tabla 4.1 muestra al primer Sprint

Donde las funcionalidades correspondientes al incremento de la iteracin son: Base de Datos independiente de los otros sistemas existentes. Pgina de ingreso con control de acceso a los usuarios Asignacin de responsablesDIAGRAMAS DE CASOS DE USO DEL SPRINTFig. 4.1 Diagrama de Casos de Uso del Sprint 1

ESPECIFICACION DE LOS CASOS DE USOTabla 4.2 Descripcin del Caso de Uso Acceder al SistemaNombre:Acceder al Sistema

Actores:Usuario Windows

Tipo:Bsico

Descripcin:Valida al usuario mediante una cuenta y password, para que pueda ingresar y utilizar el sistema.

Pre condiciones:El usuario debe estar registrado en el sistema con anterioridad.

Flujo Normal:1. El actor ingresa su cuenta y password, y presiona el botn Aceptar.2. El sistema busca la cuenta y el password en la base de datos y lo valida en el sistema.3. Una vez verificada la cuenta del usuario, se abre la pantalla principal de la aplicacin dependiendo al rol del usuario (Administrador, Operador, Director Acadmico, o Director Ejecutivo).4. Si el actor presiona el botn Cancelar, termina la ejecucin de la aplicacin

Flujo Alternativo:2A. Si la cuenta o el password no se valid correctamente, el sistema muestra un mensaje de Error.

Post condiciones:El usuario ha sido autenticado, y puede utilizar el sistema.

Tabla 4.3 Descripcin Caso de Uso Gestin Usuario Caso de UsoGestin Usuario

ActoresAdministrador

TipoBsico.

ResumenEl administrador se encarga de realizar el manejo de usuarios desde la creacin a la eliminacin.

PrecondicionesQue el usuario a utilizar sea parte de la empresa o que cuente con la autorizacin del encargado de sistemas.

Flujo Principal1. El usuario ingresa a la pgina de la aplicacin2. El usuario ingresa al mdulo de registro3. El usuario ingresa sus datos personales.4. El usuario asigna que tipo de rol ser el nuevo usuario.5. Toda la informacin es almacenada en la base de datos de la aplicacin.6. Puede ver el listado de quienes estn como usuarios.

ExcepcionesSi el ingreso de la cuenta y pasword son incorrectos la aplicacin mostrara un mensaje de error

Tabla 4.4 - Descripcin Caso de Uso Gestin Unidad de NegocioCaso de UsoGestin Unidad de Negocio

ActoresAdministrador

TipoBsico.

PrecondicionesQue el administrador solo es capaz de crear nuevas Regionales en caso de que la empresa se extienda a nivel nacional y bajo autorizacin directa de Gerencia General de la empresa.

Flujo Principal1. El administrador ingresa al mdulo de Unidad de Negocio y dependiendo de las opciones seleccionadas por el usuario se continuara con los diversos subflujos.

Subflujos2. El sistema muestra el men de Uni Neg con las siguientes opciones: Registrar Regional, Registrar Unidad de Negocio y Registrar Centro de Costo.3. Si el administrador selecciona Registrar Regional contara con las siguientes opciones:4. Para la creacin de nuevas regionales debe asignarse un identificador numeral de dos dgitos y que identificara a cada departamento del pas.5. Ingresar el nombre del departamento o regin importante que se considere.6. El usuario administrador debe presionar el botn registrar o cancelar cuando haya terminado este proceso.7. El usuario administrador una vez hecha la operacin puede ver el listado y si hay algo que modificar tiene la opcin de editar o eliminar directamente.8. Si el administrador selecciona Registrar Unidad de Negocio tendr una pantalla casi parecida a la anterior, solo que antes debe seleccionar la regin en donde va registrar la nueva Unidad de Negocio.9. Si el administrador selecciona la opcin de Centro de Costos de la misma manera antes previamente el usuario administrador debe seleccionar: Region y Unidad de Negocio para poder crear el lugar donde asignar el nuevo Centro de Costo.

ExcepcionesSi e