UNIVERSIDAD TECNICA DE ORURO

FACULTAD NACIONAL DE INGENIERIA
CARRERA 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 – BOLIVIA
2014

AGRADECIMIENTOS

Gracias a Dios por este logro académico, aun a pesar de que mi memoria me presentara como un
ser injusto pues tal vez, involuntariamente se me escapen algunas personas quienes debería
nombrar, pero quiero agradecer a todos que me ayudaron a seguir en este camino y no me
abandonaron y más por el contrario siempre me empujaron para continuar.
A mi padres y hermanos quienes me apoyaron incondicionalmente y apoyándome continuamente.
A Kanito y archell_pollito quienes por la experiencia acumulada apoyaron bastante en la revisión
y búsqueda de errores que mejoren en el rendimiento del presente proyecto.
A mis docentes quienes a lo largo de muchos años, con sus inquietudes y sus dudas me han
enseñado más de lo que podrían haberme enseñado.
A mi querida carrera que me acogió dentro sus aulas como un segundo hogar lleno de alegrías y
experiencias que estarán siempre en mi recuerdo.

2

DEDICATORIA

A Dios por nunca abandonarme y estar
siempre conmigo.
A mis padres y hermanos por el apoyo
incondicional.
A mis pequeñas: Viviam y Mariam que
son la razón de mi existencia.
A la FNI por ser mi templo de formación.

3

Traspasos y Reportes. Baja.M. Asignación. 4 . para el modelamiento del sistema y que a su vez este modelamiento se lo realizo en UML (Lenguaje de Modelado Unificado).. La metodología adoptada para el desarrollo del software es SCRUM apoyada por AUP. con las que se pudo constatar que el sistema responde a los requerimientos institucionales. Transferencia. MAXAM – FANEXA realiza la mayoría de los procesos de gestión de activos fijos de manera manual. usando como respaldo la utilización de planillas echas en Excel. que a la vez al ser una empresa consolidada a nivel nacional maneja una gran cantidad de bienes denominados activos. posibilitando la reducción de tiempo y costos en la administración de activos fijos. en las distintas etapas que contempla estas metodologías.net y el gestor de base de datos SQL SERVER EXPRESS. Búsquedas. institución dedicada a la fabricación y comercialización de explosivos. RESUMEN El proyecto Sistema de Gestión de Activos Fijos. a fin de maximizar la eficiencia en la administración de la información de los activos fijos que cuenta la empresa. Los módulos principales de la aplicación son: Registro.A. además de la obtención de datos confiables. fue desarrollado para el área de Activos Fijos de MAXAM – FANEXA S. que con el ingreso de nuevos activos se vuelve más pesado el acceso a ello. razón por la cual se decidió optar la construcción de una aplicación web que aproveche la INTRANET que cuenta la empresa y además se pretende obtener información rápida y consistente. que ayuda a efectuar la representación de los modelos por medio de artefactos. Las herramientas utilizadas para la implementación son: el lenguaje de programación C# y Asp. Concluido el desarrollo del software se realizaron pruebas de funcionamiento.

INDICE 5 .

ambas empresas han conjugado experiencia nacional e internacional.M. traspaso. y la segunda Fábrica Nacional de Explosivos (FANEXA) fundada en el año 1977 como parte de La Corporación de las Fuerzas Armadas para el Desarrollo Nacional (COFADENA). de la construcción y exploración petrolera. MAXAM – FANEXA S. vista controlador para el almacenamiento de todos sus activos con sus respectivos requerimientos que se hizo para la elaboración de este proyecto (depreciaciones.). nace el año 1999 de la unión de dos empresas líderes en la fabricación de explosivos. SISTEMA DE GESTION DE LOS ACTIVOS FIJOS EN MAXAM – FANEXA S. Aportando al progreso del país.A.M. 1 . nuevas formas de gestión modernas y eficaces. sistemas de iniciación y servicios de voladura para las industrias mineras.A. revalorizaciones. MAXAM – FANEXA S. últimas tecnologías.M. cuenta con una gran cantidad de activos que necesita ser almacenada. Estos bienes tangibles que se utilizan para el desarrollo de sus actividades administrativas y cumplen una función se les denomina “Activos Fijos”. componentes que han aportado a cubrir gran porcentaje del mercado nacional de productos reconocidos todos por su alta seguridad y calidad.A. dar baja. para llevar a cabo sus actividades requieren de la utilización de ciertos bienes denominados activos. Cabe resaltar que entre las principales características de estos activos son la permanencia en la empresa. comercialización y distribución de productos. aprovechando la intranet que cuenta la empresa. 1. en una aplicación. es una compañía líder en la fabricación.1 INTRODUCCION. razón por la cual se propuso la aplicación del tipo modelo. generando utilidades hasta que dichos bienes dejen de ser útiles por el paso del tiempo y debido principalmente a la depreciación (pérdida del valor monetario que sufre el bien al transcurrir el tiempo). etc. Las instituciones públicas o privadas. la primera La Unión Española de Explosivos (UEE) de una larga tradición actualmente bajo el nombre de MAXAM consolidada como una empresa líder a nivel mundial. o bien hasta que la empresa decida darlos de baja.

garantizando la inversión pública y privada.1 DESCRIPCIÓN DE LA EMPRESA Constitución de la Sociedad Mediante D. para la instalación de una planta industrial de fabricación de explosivos y accesorios en Bolivia.2 ANTECEDENTES.1. productos para las industrias de defensa. garantiza la sostenibilidad de los proyectos en los que se involucra. El grupo UEE el 23 de septiembre de 2006 cambia de razón social como reflejo de los cambios de políticas corporativas y crecimiento de la empresa por el de MAXAM. el gobierno de Bolivia concede al Ministerio de Defensa Nacional la exclusividad de la fabricación de explosivos y accesorios en el país y con el D. además de materias primas claves para sus necesidades internas y de terceros.M. ASAHI CHEMICAL INDUSTRY CO. Como parte integrante de las FF. NISSHO IWAI CO.S. se autoriza a COFADENA.5% y NISSHO IWAI CO. se constituye la sociedad anónima mixta bajo la razón social de Fábrica Nacional de Explosivos y Accesorios S. COMIBOL 40%. 7. Con escritura pública N° 430 de 26 de abril de 1978. siendo su composición accionaria: COFADENA 50%. (FANEXA S. 1. agrícola y ganadera. líder en el desarrollo y comercialización de explosivos civiles y sistemas de iniciación para minería. tecnologías y asistencia técnica con las empresas japonesas ASAHI CHEMICAL INDUSTRY CO. LTDA.) con la aprobación de sus estatutos. suscribir contratos de provisión de maquinaria y equipos.AA..5%. COFADENA con más de veintiocho años de experiencia y decidida vocación de servicios al progreso de Bolivia. N° 10511 de septiembre de 1972. química. constituyendo así una sociedad anónima con la Corporación Minera de Bolivia (COMIBOL) y las empresas indicadas. N° 15348 de 10 de Marzo de 1978. 2.M. LTDA. coopera en el desarrollo de todas las industrias fundamentales como la minera. con experiencia en más de cuarenta países.2.S. Desde su creación como Sociedad Anónima Mixta en julio de 1999 la compañía ha progresado 2 . LTDA. LTDA.A.A.. además de contar con el apoyo decidido del estado en todos los proyectos en los que participa. canteras e infraestructura.

estandarizando formatos de actas e informes. desarrollado por James Williams Gutiérrez Flores [2005]. cuyo objetivo es el control de depreciación de sus activos fijos en la zona franca de Oruro.M. para un manejo más adecuado y eficiente. Facultad de Ciencias Puras y Naturales UMSS. Prevención de Riesgos y Medio Ambiente. ambas con maquinaria y tecnologías de fabricación de punta. Facultad Nacional de Ingeniería FNI. desarrollado por Mario Cancillo Zanga [2006]. MAXAM – FANEXA S. desarrollado por Evert Fernando Cortez Hino [2012].hasta convertirse en líder nacional de su rubro..  Sistema Automatizado de Control de Inventarios y Actividades Comerciales. cuenta con dos plantas de producción una en Cochabamba y otra en Oruro. Chile. Perú y otros. Enfatizando en la migración de la información de la base de datos del antiguo sistema. desarrollado por Leslie Elsa Montenegro [2010]. cuyo objetivo principal del proyecto es desarrollar e implementar un Sistema de Información automatizado para la administración.A.  Sistema de Información y control de Activos Fijos Ministerio de Gobierno. comercialización y distribución está certificada hace más de tres años bajo Norma Internacional ISO 9001:2000 constituyéndose en referente nacional en temas de Seguridad. sustentadas por toda la gran experiencia y calidad de MAXAM con sede en España. Trabajos que se tomó en cuenta tienen relación al proyecto propuesto:  Sistema de Control y Depreciación de Activos Fijos: Zona Franca Oruro S. Facultad de Ciencias y Tecnología UMSS. seguimiento y control de Activos Fijos del Ministerio de Gobierno. Facultad Nacional de Ingeniería FNI.. herramienta de software de apoyo en la administración. producción.UU. Cuyo objetivo principal es la organización mediante inventarios los activos que cuenta la institución para cual desarrolla esta actividad. Ecuador. habiéndose implementado en los últimos 5 años líneas de producción en productos que hoy cubren los mercados nacionales y extranjeros con la mayor calidad y seguridad.A.  Control y Seguimiento de Activos Fijos del Servicio Exterior vía web Ministerio de Relaciones exteriores y Cultos. llegando a exportar más del 25% de sus ventas a países como EE. que permite tener información actualizada y centralizada. La calidad de los procesos de diseño. 3 .

razón por la cual no se da la información necesaria del activo.  La codificación que cuenta es demasiada antigua. 1. causa problemas como errores de ingreso o copia de fórmulas al ingreso de nuevos activos.  Demora en la disponibilidad de información sobre depreciaciones para el cierre de balance de mes.  No se tiene cálculo exacto de las depreciaciones. seguimiento y control de activos fijos. a fin de maximizar la eficiencia en la administración de la información de los activos.M.A.3 CARACTERIZACION DEL PROBLEMA Y SITUACION PROBLEMATICA. ocasionando que a veces no se encuentre dicho activo en un lugar determinado y no coincida en la verificación. evidenciando errores en el redondeo. 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. desarrollado por Juan Carlos Quispe Limachi [2008].  No se tiene registro sobre quién es responsable de un activo. software que pretende obtener información rápida. 4 . confiable y oportuna. y en el uso del equipo en su rendimiento que hace que se vuelva más lento a medida que va creciendo la mencionada planilla. que permita en el caso de pérdida dar con el responsable la ubicación y a donde pertenece ese activo.  Crecimiento masivo de la planilla hecha en Excel. La empresa MAXAM – FANEXA S.  Sistema de Gestión y Seguimiento de Activos Fijos para el servicio departamental de Gestión Social. dentro lo que se refiere al manejo de sus activos se identificó los siguientes problemas:  No tiene buena organización ni clasificación de sus activos. ni la ubicación del activo de manera exacta. ocasionando que el contador haga nuevamente reajustes de precios y gastos cada cierre de mes. Facultad de Ciencias y Tecnología UMSS. Coadyuvando en forma eficiente y transparente la elaboración y obtención de información organizada.

Se constituye el proceso administrativo de seguimiento y control de activos en la empresa MAXAM – FANEXA S. para el área de Activos Fijos dependiente de Gerencia Financiera.6.M. para un adecuado control y seguimiento de sus activos en MAXAM – FANEXA S. operaciones y registros de los activos. 5 .1 OBJETIVO GENERAL. con los que iniciara el desarrollo de la aplicación.M. 1. en forma confiable.A. El presente proyecto se desarrolló en el área de la ingeniería de Sistemas.A. que permita obtener información consistente.4 OBJETO DE ESTUDIO. 1.  Establecer los requerimientos de manejo de información en el área de activos fijos.A.A.6 OBJETIVOS. 1. más propiamente en el desarrollo de Sistemas de Información Administrativa.M.2 OBJETIVOS ESPECIFICOS. 1.6. Específicamente se desarrolló en la empresa MAXAM – FANEXA S. “Desarrollar e implantar un Sistema de Gestión y Seguimiento de activos Fijos.5 CAMPO DE ACCION. para una distribución y organización adecuada contemplando las normas futuras que la empresa tiene planificado implantarlas.1 PLANTEAMIENTO DEL PROBLEMA.M.” 1.3.? 1.  No se cuenta con historial sobre traspaso y asignación de los activos. ocasiona la perdida de algunos activos y no cumplimiento del tiempo de vida previsto de sus activos fijos. que permita obtener información confiable en el control y seguimiento de sus activos en MAXAM – FANEXA S.  Desarrollar módulos que contemplen: privilegios. ¿Cómo se puede mejorar el movimiento de sus activos fijos.

un gestor de datos relacional. que se caracteriza porque ofrece servicios web. diseño y construcción están realizados de acuerdo a la metodología SCRUM. 1.7 CRITERIO DE VERIFICACION: Se realizara pruebas de los diferentes servicios de la aplicación web implementada en la intranet de la empresa. contrastando con los resultados obtenidos. independencia de la plataforma. Siendo el directo responsable el administrador de servidores que otorga ciertos privilegios a los usuarios que están dentro el dominio existente. de tal manera que sea lo más amigable posible para el usuario. 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 ubicación física real. 1. En el tema de seguridad de la información la aplicación estará en la intranet de la empresa. donde solo aquellos que necesiten la aplicación tendrán acceso. 1. El proyecto se justifica técnicamente puesto que el análisis. debiéndose obtener resultados exactos y en menor tiempo. el cual se apoya en el desarrollo ágil de sistemas UML ligero (Unified Languaje ) cuyo modelamiento ayudara en la comprensión del sistema y para este cometido se efectuara en un herramienta case.8 JUSTIFICACIONES. La programación del sistema será realizada en ASP.NET de visual web developer 2005 una herramienta de desarrollo gratuita.1 JUSTIFICACION TECNICA. El sistema trabaja sobre una Base de Datos centralizada. 6 .8. en una muestra de casos reales con resultados conocidos. la que se gestiona en Microsoft SQL Server 2005 EXPRESS.  Desarrollar una base de datos que permita almacenar todos los datos que genere el movimiento de los activos. y para cumplir este propósito se utilizara el estadístico de Fisher.NET.  Diseñar y desarrollar la interfaz que facilite el uso del sistema utilizando la tecnología . de forma que se logre almacenar información verídica y oportuna.

tener los reportes adecuados para cada área. El presente proyecto también controlara el registro. asignación. Con el presente proyecto se podrá tener datos muy confiables en el cálculo de las depreciaciones.9 ALCANCES. 1. depreciación. que estén disponibles en el momento que se requiera por dichas aéreas y que el cierre de mes sea más rápido evitando esperas al ingreso de nuevos activos a depreciar. baja. traspasos y restauraciones de los activos.1.8. 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.M. clasificados de acuerdo al siguiente TIPO:  Terrenos  Edificios  Muebles y Enseres  Maquinaria  Equipos e instalaciones  Vehículos  Herramientas  Equipos de computación  Equipos de laboratorio El sistema estará dispuesto para su acceso a través del navegador de Internet.2 JUSTIFICACION OPERATIVA.NET. Utilización del lenguaje de programación C# bajo plataforma . 7 . con el fin de mejorar la administración que se realiza a los activos fijos.A. El sistema trabajará sobre una base de datos centralizada.

Como este proyecto fue desarrollado específicamente para MAXAM – FANEXA S.10 LIMITACIONES.  La implementación de la aplicación web se lo efectuara con herramientas de la tecnología web. 8 .11 INGENIERIA DEL PROYECTO. Tabla 1. con los que iniciara auto – organizados. 1. apoyados del modelamiento de UML. el cual definirá todo el proceso de desarrollo de la aplicación web.1 – ingeniería del Proyecto OBJETIVOS ACTIVIDAD METODO / TECNICA Establecer los requerimientos de  Historias de Usuario manejo de información en el área Conformar equipos  Product Backlog.M. utilizando metodologías de la gestión de proyectos que son adaptables al desarrollo de software. lo que sí es posible podría adaptarse. modificar y añadir más operaciones en el cálculo de las depreciaciones. de activos fijos. La ingeniería del proyecto estará basada en estos elementos principales:  El método.En el ámbito académico el presente proyecto dará pautas que ayuden el desarrollo de software de manera ágil.A. Y por sus características se utilizara el de desarrollo de software mediante SCRUM + AUP. 1. cuyo servidor de páginas web será IIS (Internet Information Server 2003) y C# será como el lenguaje de implementación.  Release Plan  el desarrollo de la aplicación. no pretende ser una solución general a diferentes situaciones que otras empresas pueden tener.

9 .  Revisar el Product operaciones y registros de los  Planificación del Sprint Backlog.NET la tecnología . Diseñar y desarrollar la interfaz que  Búsqueda de facilite el uso del sistema utilizando plantillas. amigables. activos. oportuna.Desarrollar módulos que contemplen: privilegios.  Manejo de SQL SERVER 2005 que genere el movimiento de los  Actualización y EXPRESS activos. de tal manera  Observar  Hojas de estilo CSS que sea lo más amigable posible interfaces para el usuario. para una distribución y  Desarrollo de tareas para cada  Determinar con organización adecuada historia de usuario.NET. implantarlas Desarrollar una base de datos que  Diseñar la base de  Modelado de la Base de Datos permita almacenar todos los datos datos. cuantos sprint se contemplando las normas futuras  desarrollara el que la empresa tiene planificado proyecto. de forma que se logre consulta de la base almacenar información verídica y de datos.  Interfaz web ASP.

técnicos y administrativos que regula el manejo de bienes de propiedad de la institución.NET la cual es compatible con equipos Windows y Linux. limitándonos específicamente al grupo tangible. El término tangible se refiere a lo físico como es el caso de un terreno.En este capítulo se van a abordar diversas tecnologías que se integraran en el desarrollo del proyecto de software. se utilizara la tecnología ADO. pueden ser alquilados a terceros o para fines administrativos. y que en realidad prestan servicio a una institución en el desarrollo especifico de sus actividades. este grupo de activos es en su mayoría lo que la empresa cuenta. 2 ACTIVOS FIJOS. un edificio o una máquina. Dentro los activos fijos están separados en dos grupos: Tangibles e Intangible. 10 . que rige en nuestro país. el Área de Activos Fijos dependientes de Contabilidad trabaja en base a las normas básicas del Sistema de Administración de Bienes y Servicios. no se venden pero pueden ser utilizados en la producción o comercialización de bienes y servicios. constituyéndose un conjunto de elementos jurídicos. Se considera Activo Fijo a aquellos bienes que tienen una vida relativamente larga. físicamente tangible. El repositorio de información será una base de datos relacional implementada en un Sistema Gestor de Base de Datos Relacionales. La aplicación de métodos agiles en el desarrollo de software permitirá combinar la gestión de proyectos basados en SCRUM que es una metodología basada en la organización de trabajo. Con el objetivo de lograr la racionalidad en la distribución.1 ACTIVO TANGIBLE. tendrá una interfaz web ASP.NET la cual es ideal para ambientes desconectados en la web. uso y salvaguarda de los activos fijos de la empresa. que integrara diversas tecnologías con el objetivo de mejorar el movimiento de dichos activos. La aplicación será desarrollada sobre la plataforma . Para el acceso a los datos del repositorio de información desde la aplicación.NET. 2. La investigación está enfocada en el desarrollo de una aplicación web para la gestión de activos fijos.

y por esta razón se consideran no depreciables. distribuido durante su vida útil estimada con el fin de obtener los recursos necesarios para la reposición de los bienes.2 CLASIFICACION GENERAL. La depreciación es un reconocimiento racional y sistemático del costo de los bienes. El único activo que no se deprecia es el terreno.3 CLASIFICACION CONTABLE.Estos activos cuando se desgastan y a medida que va pasando el tiempo sufren una Depreciación que simplemente es la pérdida del valor monetario que sufre el bien al transcurrir el tiempo. 2. 2. b) ACTIVOS DEPRECIABLES. la perdida de utilidad comparativa respecto de nuevos equipos y procesos o simplemente el agotamiento de su contenido. la mayoría de los activos fijos tienen una vida útil limitada ya sea por el desgaste resultante del uso. La empresa para la clasificación de sus Activos y siguiendo la sugerencia de su socia MAXAM CORPORATION lo hizo de acuerdo a: TIPO. de manera que se conserve la capacidad operativa o productiva del ente público. Su 11 . Con excepción de los terrenos. el deterioro físico causado por terremotos. se clasifican particularmente en dos grupos: Activos No Depreciables y Activos 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. Entre los activos no depreciables tenemos los terrenos. GRUPO Y SUBGRUPO.3. La inmensa mayoría de los Activos Fijos de una empresa son depreciables. Para efectos contables los Activos Fijos. a) ACTIVOS NO DEPRECIABLES. La disminución de su valor causada por factores antes mencionados se carga a un gasto llamado Depreciación. 2. y son los que sufren desgaste o deterioro por el uso a que están sometidos o sólo por el transcurrir del tiempo. al menos contablemente. Esta es una teoría contable aceptada en todo el mundo. incendios u otros siniestros. siendo este tipo aquellos que no sufren desgaste por el uso a que son sometidos aun cuando el tiempo ya haya transcurrido.1 DEPRECIACION DE ACTIVOS FIJOS.

número de unidades producidas o número de horas de funcionamiento. La depreciación es simplemente parte del costo del activo que es enviado a gastos y no significa efectivo. Esto no quiere decir que el activo sea desechado o que ya no se use. La depreciación no es un proceso de valuación por el que se asigna a gastos el costo del activo de acuerdo con autoevalúo realizados al fin de cada periodo. la mayoría de veces. suma de los dígitos de los años. 2. a un mayor nivel de depreciación. La depreciación es una asignación del costo del activo a gastos de acuerdo con su costo original. incluyendo los costos de desinstalación y desmantelamiento si fueran necesarios. Por otro lado debe considerarse el valor residual o valor recuperable que será el que tendrá el bien cuando se discontinúe su empleo y se calcule deduciendo del precio de venta los gastos necesarios para su venta. Por lo tanto la depreciación afecta el nivel de utilidades y el pago de impuestos. que debe revelarse en las notas a los estados contables. las empresas continúan utilizando los activos totalmente depreciados con el fin de no pagar el IVA (impuesto al valor agregado) correspondiente de un activo en uso.distribución debe hacerse empleando los criterios de tiempo y productividad mediante uno de los siguientes métodos: línea recta. o cualquier otro reconocido valor técnico. La depreciación no significa que el negocio aparte efectivo para reemplazar los activos cuando lleguen a ser totalmente depreciados. saldos decrecientes. La depreciación 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.4 METODOLOGIAS AGILES. Otro factor de importancia para la actualización de los costos en la depreciación es la utilización de las UFVs (Unidades de Fomento a la Vivienda). Un activo totalmente depreciado solamente significa que ha alcanzado el final de su vida útil estimada. las utilidades son menores y los impuestos correspondientes también son menores. es decir que no registra más depreciación para el activo. 12 .

El mejor crear el equipo y que éste configure su propio entorno de desarrollo en base a sus necesidades. Estos documentos deben ser cortos y centrarse en lo fundamental. por encima del seguimiento de un plan. nace el término “Ágil” aplicado el desarrollo de software. previas al desarrollo de software. haciéndolo y ayudando a otros que lo hagan”.1 EL MANIFIESTO AGIL. 17 críticos de los modelos para el desarrollo de software basados en procesos. La regla a seguir es” no producir documentos a menos que sean necesarios de forma inmediata para tomar una decisión importante”. 1 Manifiesto Ágil. marzo de 2001 reunión convocada por Kent Beck para dar lineamientos sobre el nuevo desarrollo de Software 13 . [SCRUM-MANAGER- GESTION DE PROYECTOS]  A los individuos y su interacción.) determina también el éxito o fracaso del mismo. en la tecnología. Los integrantes de la reunión resumieron en cuatro postulados lo que ha quedado denominado como “Manifiesto Ágil” y que son los principios sobre los que se basan estos métodos. En la reunión se acuño el término “Métodos Agiles” para definir a los que estaban surgiendo como alternativa a los modelos formales (CMM-SW. por encima de los procesos y las herramientas. por encima del seguimiento de un plan. la planificación no debe ser estricta sino flexible. Por lo tanto. Muchas veces se comete el error de construir primero el entorno y esperar que el equipo se adapte automáticamente. por encima de la negociación contractual. La gente es el principal factor de éxito de un proyecto software. 2.  La colaboración con el cliente. Esta colaboración entre ambos será la que marque la marcha del proyecto y asegure su éxito. SPICE) 1que los consideraban excesivamente “pesados” y rígidos por su carácter normativo y fuerte dependencia de planificaciones detalladas. etc. La habilidad de responder a los cambios que puedan surgir a lo largo del proyecto (cambios en los requisitos. El manifiesto comienza de esta manera “Estamos poniendo al descubierto mejores métodos para desarrollar software.En marzo de 2001. PMI. convocados por Kent Beck y celebrado en Utah – EEUU.  La respuesta al cambio.  El software que funciona. en el equipo. Se propone que exista una interacción constante entre el cliente y el equipo de desarrollo. Es más importante construir un buen equipo que construir el entorno.4.

presento junto con Ken Schwaber. se puede usar también para la ejecución de equipos de mantenimiento de software o como un enfoque de gestión de programas. Aunque Scrum estaba previsto que fuera para la gestión de proyectos de desarrollo de software. de los estudios realizados por Hirotaka Takeuchi y Ikujijo Nonaka sobre nuevas prácticas de producción a mediados de 1980. Las practicas desarrolladas por Schwaber y Sutherland para gestionar el desarrollo de software están incluidas en la lista de modelos agiles de Agile Alliance. además de ser fácilmente combinable con otros métodos. Scrum es una forma de desarrollo de carácter adaptable más que predictivo. pero también se emplea en entornos que trabajan con requisitos inestables y que además requieren rapidez y flexibilidad. desarrollando cualquier producto o gestionar cualquier trabajo.  Es un modo de desarrollo adaptable.  Requiere de entregas de software terminado. Jeff Sutherland aplico el modelo Scrum al desarrollo de software en Easel Corporation (empresa que en los macro-juegos de compras y fusiones se integraría en VMARK. 1996). En un proyecto Scrum se consideran los siguientes aspectos:  Desarrollo de software en etapas incrementales. Scrum es un proceso ágil que se puede usar para gestionar y controlar desarrollos complejos de software y productos usando prácticas iterativas e incrementales. las características principales de este juego son el trabajo en equipo y la adaptación.5 SCRUM. luego en Informix y finalmente en Ascential Software Corporation).  Orientado a las personas antes que a los procesos. Scrum en el área de ingeniería de software es un Método Ágil para el desarrollo de proyectos. Scrum surgió como modelo para el desarrollo de productos tecnológicos. quienes basándose en el juego de Rugby Scrum. para gestión del desarrollo de software en OOPSLA 96(Schwaber & Sutherland. En 1996.  Emplea del desarrollo iterativo e incremental. estas situaciones son frecuentes en el desarrollo de determinados sistemas software. En 2001 formaron parte de los firmantes del Manifiesto Ágil. Toma su nombre así como los principios.2.  La implementación de Scrum es de bajo riesgo y costo. En 1993.  Se enriquece con la experiencia del equipo de trabajo. 14 . las prácticas que empleaba como proceso formal.

es donde empieza todo. Ágil Fuente: [Juan Palacios. tanto a nivel de producto en general (visión del producto) como del sprint en el que se está trabajando (objetivo del Sprint).6. va creciendo y evolucionando durante el desarrollo del proyecto. Fig. la pila del producto es básicamente una lista priorizada de requisitos o historias o funcionalidades. se sitúan en la zona de la “forma” y para que la implantación de Scrum alcance niveles de capacidad elevados tiene que responder una visión clara. 2008] 2. 2.  El responsable directo es el propietario del producto.1 Determinación de Requerimientos Tradicional vs. 15 .1 PRODUCT BACKLOG (PILA DEL PRODUCTO): lista de funcionalidades que necesita el cliente y se origina con la visión inicial del producto. las características principales de esta pila son:  Priorización de acuerdo a la importancia que le da el propietario del producto. llamamos a estas historias o a veces simplemente elementos de la pila.Para Scrum Management.6 ELEMENTOS DE UN PROYECTO SCRUM.  Todos pueden contribuir y aportar elementos. 2. conocida y compartida por todo equipo.1.6.  Debe ser accesible para todos los miembros del equipo del proyecto.1 COMO HACEMOS EL PRODUCT BACKLOG (PILA DEL PRODUCTO) La Pila del Producto es el corazón de Scrum. los requisitos y sus modelos de especificación: Product Backlog y Sprint Backlog. Los elementos centrales de un ciclo ágil Scrum son: 2. Cosas que el cliente quiere descritas usando la terminología del cliente.

Formato para el Product Backlog PRODUCT BACKLOG (PILA DEL PRODUCTO) ID NOMBRE O IMPORTANCIA O ESTIMACION COMO DESCRPCION PRIORIDAD INICIAL O ESTADO PROBARLO  ID: Identificador único auto incremental que permite no perder la pista a las historias cuando cambiamos su nombre.6.  ESTIMACION INICIAL: La valoración inicial del equipo acerca de cuanto trabajo es necesario para implementar la historia.1. comparado con otras historias.  Confirmation: Test funcionales para fijar detalles que serán relevantes e indicar cuál va ser el límite. también serán el resultado de la colaboración entre el cliente y el equipo. e irán evolucionando durante toda la vida del proyecto.  COMO PROBARLO: Una descripción de alto nivel de cómo se demostrara esta historia al final del Sprint.  IMPORTANCIA: El valor que se le asigna a la historia del usuario en la que el dueño el producto asigna un determinado valor para la prioridad. suficientemente claro como para el dueño del producto comprenda aproximadamente de que se está hablando y suficientemente clara como para distinguirla de las otras historias.  NOMBRE: Una descripción corta de la historia del usuario.2 HISTORIAS DE USUARIO Son las descripciones de las funcionalidades que va tener el software.1. 2. Tabla 2. y concretar el objetivo.  Conversation: Es una conversación que servirá para asegurarse de que se ha entendido bien todo. 16 . Las historias de usuario se componen de tres fases denominadas “Las 3C”:  Card: Sera una breve descripción escrita que servirá como recordatorio.

Fig. o S – Should. se debe completar este proyecto por todos los medios. o W – Would. pero a veces es inevitable. o M – Must.blogspot. Estas unidades representaran el tiempo teórico (desarrollo / hombre) que se haya estimado al comienzo del proyecto. se puede completar este requerimiento si sobra tiempo de desarrollo (o en futuras versiones del mismo)  DEPENDENCIAS: Una historia de usuario no debería ser dependiente de otra. 17 . Tomando en cuenta que la determinación de los requerimientos es el núcleo 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 más sobresalientes que servirán como requisito del sistema.com. pero el éxito del proyecto no depende el. se debería completar este requerimiento si su implementación no afecta la consecución de los objetivos principales del proyecto. otra aproximación a la priorización de las tareas se hace a través del método MoSCoW.2 – Historias de Usuario Fuente: http//devnettips.  PRIORIDAD: Prioridad en la implementación de la historia de usuario respecto al resto de las historias de usuario. se debe completar ese requerimiento para finalizar el proyecto.  ESTIMACION: Evaluación del coste de implementación en unidades de desarrollo.es  ID: Identificador de la historia de usuario  TITULO: Titulo descriptivo de la historia de usuario  DESCRIPCION: Descripción sintetizada de la historia de usuario. A mayor tiempo mayor prioridad. o C – Could.2.

6. La pila del Sprint es una lista de las tareas que debe realizar el equipo durante esta iteración para generar el incremento previsto. 2.  Se debe asignar tareas a los distintos miembros del equipo del proyecto.  El equipo debe estar comprometido a realizar dichas funcionalidades. El Sprint Backlog se sitúa en el área de especificación de los requisitos de software necesarios para dar respuesta a las funcionalidades esperadas por el cliente cuyas características principales son:  Debe contener las funcionalidades que se van a realizar durante el Sprint. idealmente en una pizarra o l espacio físico conveniente a donde trabaja el equipo. La siguiente figura solo muestra cómo debería realizarse en una hoja de cálculo como Excel un Sprint 18 .2.6.  Se debe hacer una estimación de cada funcionalidad  El tamaño de cada tarea esta en el rango de 4 a 16 horas de trabajo.2. El propósito de la planificación de Sprint es proporcionar al equipo suficiente información como para que puedan trabajar en paz y sin interrupciones durante unas pocas semanas y ofrecer al dueño del producto suficiente confianza. probablemente la más importante de Scrum.  Debe ser visible para todo el equipo.2 PILA DEL SPRINT (SPRINT BACKLOG): Se define “Sprint” como una iteración que dura alrededor de 30 días. una planificación de Sprint mal ejecutado puede arruinar por completo todo el Sprint.1 PLANIFICACION DEL SPRINT La planificación del Sprint es una reunión critica.

6. cuyas características principales son: 19 .2.3 - Ejemplo de Pila de Sprint con hoja de Cálculo Fuente: Gestión Técnica de Proyecto [Juan Palacios. una recomendación que da esta metodología es diseñar el formato más cómodo para todos incluyendo ciertos criterios:  Lista de tareas.3 INCREMENTO: Es el resultado de cada Sprint. y entre estas es elección del equipo cual es la mejor que se adecua a las características del proyecto. 2. 2013] La planificación del Sprint produce concretamente:  Una meta de Sprint  Una lista de miembros (y su nivel de dedicación en porcentaje)  Una pila de Sprint (Lista de historias incluidas en el Sprint) 2.  El medio y modelo elegido es la opción posible que más facilita la consulta y comunicación diaria y directa del equipo.  Solo incluye información estrictamente necesaria.2. persona responsable de cada una. Fig. hojas de cálculo o herramientas colaborativas.2 COMO HACEMOS EL SPRINT BACKLOG (PILA DEL SPRINT) Existe varios formatos para la elaboración del Sprint Backlog desde pizarras. estado en que se encuentra y tiempo restante que queda para completarlo.6.

y Scrum gestiona su evolución a través de reuniones breves de seguimiento en las que todo el equipo revisa el trabajo realizado desde la reunión anterior y el previsto hasta la reunión siguiente. El desarrollo se inicia desde la visión general del producto.  Orientado a las personas antes que a los procesos.  Es una funcionalidad. 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 días). Cada uno de los ciclos de desarrollo es una iteración (sprint) que produce un incremento terminado y operativo del producto. 2.  Es parte del producto desarrollado en un Sprint.  Debe estar en condiciones de ser usado. desarrollo de prototipos para probar la solvencia de la plataforma que se va a emplear. Sin embargo suele ser una excepción habitual el primer sprint. porque la gestión no se basa en el seguimiento de un plan. se refiere a funcionalidades entregables. Estas iteraciones son la base del desarrollo ágil.1 COTROL DE LA EVOLUCION DEL PROYECTO 20 .7. sino en la adaptación continua a las circunstancias de la evolución del proyecto.  Cada funcionalidad del product backlog. que requiere trabajo duro. Scrum es una metodología ágil:  Es un modo de desarrollo de carácter adaptable. Scrum es una metodología de desarrollo muy simple.  Emplea desarrollo ágil: iterativo e incremental. 2. e implican trabajos de diseño. en el que los objetivos del tipo “contrastar la plataforma y el diseño” pueden ser normales. etc.7 MODELO DE PROCESO SCRUM. no a trabajos internas del tipo “diseño de la base de datos”. Tomando en cuenta estas consideraciones el incremento resulta ser: parte del producto realizada en un sprint y potencialmente entregable: TERMINADA Y PROBADA.

tienen que permitir la evolución continua sin degradar la calidad de la arquitectura.7.7. el desarrollo incremental implica que al final de cada iteración se dispone de una parte del producto operativa que se puede inspeccionar y evaluar. La gestión predictiva confía la responsabilidad de su resolución al gestor de proyectos. con margen de decisión suficiente para tomar las decisiones que consideren oportunas.5 AUTO – ORGANIZACIÓN Durante el desarrollo de un proyecto surgen las circunstancias impredecibles en todas las áreas y niveles. que se ira generando durante el desarrollo del producto. 2.6 COLABORACION 21 . 2. intentar predecir en las fases iniciales cómo será el resultado final.Scrum controla de forma empírica y adaptable la evolución del proyecto.4 DESARROLLO EVOLUTIVO Como modelo ágil es muy útil en entornos con incertidumbre e inestabilidad de requisitos.7. en Scrum los equipos son auto – organizados. Scrum toma a la instabilidad como premisa y de esta manera es conveniente las prácticas de trabajo que se diseñen.7.3 DESARROLLO INCREMENTAL En el proyecto no se trabaja con diseños o abstracciones. 2.2 REVISION DE LAS ITERACIONES Al final de cada sprint o iteración. sobre dicha predicción desarrollar el diseño y la estructura del producto no es realista. con las siguientes prácticas de la gestión ágil: 2. 2.7. se realiza una revisión con todas las personas implicadas en el proyecto. porque las circunstancias obligaran a remodelar nuevamente en varias oportunidades. Este es el periodo máximo que se puede tardar en reconducir una desviación del proyecto o de las circunstancias del producto.

Esta reunión no debe tomarse como un “acontecimiento especial”.Las prácticas y el entorno de trabajo ágil facilitan la colaboración abierta entre todos según los conocimientos y capacidades de cada persona y no según su rol o puesto. 2. 2013] 2. Fig. sino como la presentación normal de los resultados.8 LOS ROLES O RESPONSABILIDADES El grado de funcionamiento de Scrum en la organización depende directamente de estas tres condiciones:  Características del entorno (organización del proyecto) adecuadas para el desarrollo ágil.7.4 – Desarrollo de Software Scrum Fuente: Gestión Técnica de Proyecto [Juan Palacios.  Conocimiento de la metodología de trabajo en todas las personas de la organización y las implicadas del cliente.  Asignación de responsabilidades o Del producto o Del desarrollo 22 .  Revisión de Sprint: Análisis y revisión del incremento generado.7. Los componentes y conceptos empleados en Scrum son: 2.7 LAS REUNIONES  Planificación 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 iteración.  Seguimiento del Sprint: Breve reunión diaria para dar repaso al avance de cada tarea y al trabajo previsto para la jornada.

9. PRACTICAS  Sprints  Sprints Planning Meeting  Daily Meetings  Sprint Review Meeting  Desing Review Meeting  Stabilization Sprint III. a este suele denominar como “propietario del producto”. o Del funcionamiento de la metodología Scrum 2. que a su vez tiene la responsabilidad de obtener el resultado de mayor valor posible para el usuario o cliente.9. es en este aspecto que Scrum no es una excepción. ROLES Y RESPONSABILIDADES 23 . y solo una capaz de conocer cómo funciona el entorno del cliente desde la visión del producto. Representa a todos los interesados del producto final y al mismo tiempo es responsable del Product Backlog.7. 2. Es una metodología que se garantiza integrando en el equipo una persona con el rol de Scrum Master.2 RESPONSABILIDAD DEL FUNCIONAMIENTO DE SCRUM La organización debe garantizar el funcionamiento de los procesos.10 PRINCIPALES ELEMENTOS DE LA METODOLOGIA I. metodologías que emplea.9 RESPONSABILIDAD DEL PRODUCTO: PROPIETARIO DEL PRODUCTO En el proyecto hay una persona.7.7.7. HERRAMIENTAS  Product Backlog  Sprint Backlog II. 2. incluido el propietario del producto conoce la metodología y son directamente los auténticos responsables del resultado. Es un equipo multidisciplinar que cubre todas las habilidades necesarias para generar el resultado. 2.1 RESPONSABILIDAD DEL DESARROLLO DEL EQUIPO Todo el equipo de desarrollo. Considerando que las realidades de unas y otras empresas pueden ser muy diferentes es muy adecuado el uso de la metodología Scrum que puede adaptarse a los cambios continuos en los requisitos.

8 FASES DE LA METODOLOGIA SCRUM El ciclo de vida Scrum está compuesto de tres fases: Pre – Game. Fig. reuniones y procesos de desarrollo de Scrum Fuente: William C. Wake 2.  Scrum Master  Product Owner  Scrum Team  Customer  Management La figura 2. Game y Post – Game. artefactos.[AISI.5 muestra a la metodología 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. 2. 2007] 24 .5 – Descripción de roles.

para esto se crea la lista Product Backlog a partir del conocimiento actual que se tiene del sistema.Investigar para complementar o copiar de 1 Figura 2.8.6 – Ciclo de Vida SCRUM Fuente: Carlos Reynoso UNIVERSIDAD DE BUENOS AIRES 2. En esta etapa también todos los miembros del equipo incluyendo el cliente contribuyen a la creación de una lista de características del sistema.1 PRE GAME: Fase en la cual se divide en otras dos sub fases: Planificación y Arquitectura.8. En ella se expresan los requerimientos priorizados y a partir de ella se estima el esfuerzo requerido.1 Planificación: Consiste en la definición del sistema que será construido.1. Dentro las tareas que debe efectuarse en esta primera etapa son: 25 . 2. que servirán en el análisis y la conceptualización del problema.

Desarrollo de Sprints: El trabajo generalmente se organiza en iteraciones de 30 días (sprints).  Definición de fechas de entrega del sprint y las funcionalidades que se requiere. diseño. también se realiza las estimaciones precisas y los cambios en la prioridad de los ítems que pueda existir. Selección de las herramientas y de la infraestructura del desarrollo. además de elegir las metas de la iteración. se lleva a cabo la elaboración del proyecto. En cada iteración del GAME se realiza las siguientes tareas: a.2 Arquitectura: El diseño 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.1. inconvenientes y esfuerzos del equipo. Cabe indicar también que la Lista del Product Backlog es actualizada constantemente con nuevos ítems y más detalles de los requerimientos.3 POST GAME 26 . ventajas. Planeación del Sprint: Antes de comenzar cada sprint o iteración se lleva a cabo dos reuniones consecutivas.2 GAME Una vez realizada la especificación correspondiente. esta fase provee la documentación del backlog del Sprint con las actividades realizada por los responsables y la duración de cada actividad. c. en la primera se refina y se prioriza nuevamente el backlog del producto.8. con un seguimiento continuo a cargo del mismo grupo de desarrollo. 2. las metas incluyendo la información de las funciones. donde se presenta la nueva funcionalidad del producto. 2.8. Es el desarrollo de la nueva funcionalidad para el producto. se identifican los cambios necesarios para implementar los elementos que aparecen en la lista Product Backlog y el impacto que pueden tener estos cambios. priorizados de acuerdo a una evaluación del cliente. En la segunda reunión se deben considerar como alcanzar los requerimientos y crear el backlog del sprint.  Análisis de riesgos y controles apropiados para los riesgos. Revisión del Sprint: Al final de cada iteración se lleva a cabo una reunión de revisión. b.8.  La recopilación de requerimientos para conformar el Product Backlog. 2.

Luego de haber culminado todas las iteraciones. se busca capturar esos nuevos requerimientos y darles la apropiada prioridad para no perjudicar el trabajo que pudo haber avanzado durante ese tiempo. Cierre: Es la última etapa donde se realiza la preparación operacional. También 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. El proceso unificado ágil (AUP) es una versión simplificada de RUP (Rational Unified Process) desarrollada por Scott Ambler. 2. desarrollo del software de aplicación de negocios usando técnicas agiles. Tomando en consideración lo descrito anteriormente. 2. se espera ir implementando por iteraciones una cierta cantidad de funcionalidades de manera que se puedan realizar pruebas y analizar si se están cumpliendo con los requisitos.1 EVOLUCIÓN DE REQUERIMIENTOS. denominada según esta metodología como cierre.9 METODOLOGIA AUP (Agile Unified Process). Esto a su vez conlleva a realizar cambios en los modelos de análisis y diseño para adecuarlos a los nuevos requerimientos. Describe un enfoque simple y fácil de entender. evolucionen o aparezcan otros de acuerdo a nuevas necesidades. 27 . resta la revisión final. Con esta característica. existen factores externos que ocasionan que dichos requerimientos cambien. A continuación se describen algunos principios del desarrollo ágil de software (Agile Development) que son apropiados para el desarrollo de la herramienta y que justifican la elección de AUP como la metodología de la solución. Si bien al inicio de todo desarrollo de software se busca capturar todos los requerimientos.9. a) Desarrollar el producto en pequeñas iteraciones y liberar versiones del producto en tiempos incrementales. a. incluyendo la documentación final necesaria para la presentación. AUP aplica técnicas agiles incluyendo desarrollo orientado a pruebas (TDD) modelado ágil (AM) gestión de cambios ágil y refactorización de bases de datos para mejorar la productividad y tener una documentación necesaria y suficientemente bueno para el entendimiento del problema y el desarrollo de la solución.

Ambler Agile UP 2. Como se mencionó anteriormente. el desarrollo ágil de software propone realizar pruebas a lo largo de todo el desarrollo mediante la implementación de unidades de pruebas que puedan ser reutilizadas. se explicara la derivación de su proceso mediante las fases y disciplinas que posee la metodología.1 FASE DE INCEPTION. los cuales serán descritos en cada fase de la metodología. A diferencia de metodologías tradicionales. 28 . la metodología para desarrollar la aplicación es AUP. Los artefactos de software necesarios para el entendimiento de la solución estarán basados en los diagramas UML correspondientes. cuyo ciclo de vida se muestra en la figura 2.7. asegurando de que todas las características están funcionando correctamente durante la liberación de pequeñas versiones y de la liberación del producto final. b) Realización de pruebas a lo largo del ciclo de desarrollo del software. Posteriormente. los cuales van a ser modelados en un diagrama de casos de uso y su correspondiente especificación.10. El objetivo de esta fase es la de establecer un alto nivel los requerimientos de la aplicación. Figura 2. 2.10 DESARROLLO DE LA METODOLOGIA.7 – Ciclo de vida de AUP Fuente: Scott W.

El principal objetivo de esta fase es elaborar y probar la arquitectura del sistema. Adicionalmente.2 FASE DE ELABORACIÓN. Con dicha información se pueden establecer las iteraciones de desarrollo para la fase de construcción. 29 . las funcionalidades implementadas pueden ser corroboradas y en caso de que sea necesario. precio a la codificación y las pruebas de calidad. de manera que una vez terminada una iteración. se hagan las correcciones pertinentes. En paralelo con la codificación. Esta fase corresponde al desarrollo en sí de la aplicación.10. Para ilustrar la arquitectura del sistema a través de distintas capas y cómo estas interactúan entre ellas.10.  Iteración Nº 3: comprende la codificación de las funcionalidades relacionadas y establecidas por el tercer y último Sprint del proyecto. 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.3 FASE DE CONSTRUCCIÓN. Para esta fase se han establecidos 3 iteraciones de acuerdo a lo establecido en la fase de incepción y a la planificación del proyecto:  Iteración Nº 1: Comprende la codificación de las funcionalidades relacionados a la conexión hacia las fuentes de datos origen y destino. Para llevar a cabo este trabajo. 2. se realizaran los siguientes tipos de pruebas:  Pruebas de aceptación. las cuales serán descritas posteriormente. Permitirán corroborar que los requerimientos han sido resueltos de manera satisfactoria. 2.  Iteración Nº 2: comprende la codificación de las funcionalidades relacionadas y establecidas por el segundo Sprint. se implementaran las pruebas necesarias para probar cada funcionalidad.Además durante esta fase inicial se realizaran las estimaciones de costo o programación de tareas (las cuales ya han sido establecidas con Scrum). dicha arquitectura deberá satisfacer los requerimientos ya definidos y servirá como basa para la fase de construcción.

Esto no solo incluye el seguimiento de las versiones de los artefactos sino también controlar y gestionar los cambios en ellos. En esta etapa.  Unidades de Prueba (Unit Test).4 FASE DE TRANSICIÓN. Estos tipos de pruebas suelen ser independientes de las funcionalidades pues verifican el código fuente. así como verificar que el diseño sea correcto.11. validar que el sistema funciona como fue diseñado y verificar que se cumplen los requisitos. 2. 2. 2.11.1 MODELADO: Entender el negocio de la organización. 2.10. mientras que las unidades de prueba verificaran que el código no contenga errores. se realizaran algunos arreglos a la codificación de acuerdo al resultado de las pruebas. 2. Esto incluye encontrar defectos. En caso de ser necesario. 30 . Estas pruebas verifican el comportamiento del sistema a un bajo nivel (nivel de código).11 DISCIPLINAS DEL AUP: AUP tiene siete disciplinas que describiremos a continuación: 2. se continuaran con el conjunto de pruebas definidos en las fases anteriores previo a la puesta en producción de la herramienta. 2. en particular pruebas unitarias.4 DESPLIEGUE: Planificar el despliegue del sistema y ejecutar el plan para poner el sistema a disposición de los usuarios finales.11.11.5 GESTIÓN DE CONFIGURACIÓN: Gestión de acceso a los artefactos del proyecto.3 PRUEBAS: Realizar una evaluación objetiva para asegurar calidad. La elección de ambos tipos de pruebas se justifica en el hecho de que son complementarias y necesarias. tratar el dominio del problema e identificar una solución viable para tratar el dominio del problema.2 IMPLEMENTACIÓN: Transformar el modelo en código ejecutable y realizar un nivel básico de pruebas.11. Las pruebas de aceptación permitirán verificar que los requerimientos se estén implementando. Son pruebas de caja blanca que verifican que el código para implementar una funcionalidad sea el correcto.

2. 2 Mono es el nombre de un proyecto de código abierto impulsado por Novell para crear un grupo de herramientas libres. se comienza con un panorama general del .2.6 GESTIÓN DE PROYECTO: Dirección de las actividades que tienen lugar dentro del proyecto. basadas en GNU/Linux compatibles con .12 . hardware…) adecuadas están disponibles para el equipo cuando son necesarias.NET. El . NET.NET Framework desde su surgimiento. 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. Esto incluye gestionar riesgos.1 PLATAFORMA.NET es una de las múltiples tecnologías que forman parte del . sus principales componentes hasta su implementación para entornos libres mediante el proyecto MONO2.7 ENTORNO: Soporte del resto del esfuerzo asegurando que el proceso. para después centrarse en ASP.NET Framework representa un cambio importante en el modo de generar y ejecutar las aplicaciones web.NET FRAMEWORK. 2.11. Es importante recalcar que ASP. Para describir los principales conceptos con la plataforma de desarrollo escogida para esta investigación. la orientación (estándares y guías) y las herramientas (software.NET Framework.11.NET 31 .12. Toda la información contenida en este apartado está basada en el documento publicado por Microsoft. 2.NET que es su módulo para el desarrollo web y terminar con la descripción de su modelo de conexión a datos desconectado llamado ADO.

NET.NET es un marco de programación basado en el . 2001 32 . Microsoft asegura que . ASP. que proporcionan los bloques básicos para construir aplicaciones distribuidas basadas en la web. proporcionan un modo fácil de generar sitios Web dinámicos. Los formularios Web Forms ASP.2 ASP.NET de Microsoft es simplificar del desarrollo web.NET es una plataforma que puede utilizarse para generar y ejecutar la siguiente generación de aplicaciones de escritorio y aplicaciones web.NET. que forman parte de una aplicación Web ASP. Figura 2.NET Framework es la infraestructura básica subyacente de .NET Framework que se utiliza para generar aplicaciones Web.NET Fuente: Microsoft. 2.Microsoft define a .NET. y que hace que los datos estén disponibles a través de internet.9 – Elementos de una aplicación ASP. Por lo consiguiente.NET. ASP. El objetivo de la plataforma .12.NET fue implementado desde un principio pensado en una arquitectura abierta .NET también incluyen la tecnología necesaria para generar servicios Web XML. el .NET como un modelo de desarrollo que hace que el software sea independiente de la plataforma y de los dispositivos.

10 ) 33 . Cualquier proceso de software basado en UML debe contar con las siguientes características principales:  Debe ser iterativo e incremental.2. visualizar. guardando la consistencia del desarrollo del sistema. 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. facilitando la gestión de modelos. rendimiento de la aplicación y del sistema.  La notación de modelado debe ser visual.  Debe existir un control de cambios de software para evitar un caos.13 LENGUAJE UNIFICADO DE MODELADO UML es un lenguaje de modelado visual que permite especificar. utilizando conjuntos separados de vistas.  Debe poderse evaluar continuamente la calidad de un sistema de software con respecto a su funcionalidad.  Tener un enfoque industrial para la producción de software “capacidad de producir productos de alta calidad a bajo costo”. 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. Una vista es un conjunto de notación UML que modela construcciones que representa un aspecto de un sistema de distintas perspectivas con distintos diagramas. centrándose en los aspectos críticos en las primeras iteraciones para minimizar riesgos para el futuro. fiabilidad. 2.  La arquitectura debe estar basada en componentes. especialmente en la comunicación entre los equipos de desarrollo.13.  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.1 VISTAS UML. construir y documentar componentes que forman parte de un sistema de software orientado a objetos.

es decir los comportamientos que lo integran. utilizando el diagrama de secuencia. Esta vista es aplicada durante la fase de diseño y desarrollo del sistema. b) Vista Diseño Muestra el diseño del sistema con dos aspectos esenciales.10 . Figura: 2. para lo cual utiliza los diagramas de clases. El segundo aspecto es el comportamiento del sistema es la dinámica de interacción de dichos componentes. c) Vista de Procesos Muestra la organización del código y demás archivos parte del sistema.modelo de la arquitectura de un sistema mediante vistas Fuente: [ALARCON. 34 . con los diagramas de casos de uso que muestra la funcionalidad del sistema. archivos desarrollados o adquiridos y la dependencia entre ellos. el primer aspecto es la estructura. utilizando para ello los diagramas de componentes. describiendo el comportamiento. 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.

Las otras vistas no se utilizaran porque Scrum se basa más en el desarrollo del proyecto que en la documentación. con los estándares de desarrollo y con las características implícitas que se espera de todo desarrollo 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. y como no puede ser medida directamente.1 FUNCIONALIDAD Se trata de identificar la capacidad que el producto software tiene para proporcionar funcionalidades que satisfagan las necesidades especificadas. El estándar ISO 9126 ha sido desarrollado en un intento de identificar los 6 atributos clave de calidad para el software: Funcionalidad de mantenimiento. 35 .14 APLICACIONES WEB. 2.01∗∑ Fi ] Cuentatotal :Suma de todas las entradas 0. debe ser medido indirectamente de otras medidas directas como ser el punto función propuesto por Albretch.15 METRICAS DE CALIDAD La calidad de software es la concordancia con los requisitos funcionales y de rendimiento explícitamente establecidos. [Pressman. confiabilidad y eficiencia. 2005].65+ 0. Para el cálculo de esta métrica se determina los valores de las cinco características de dominio de información que asocia a estos dominios un valor de complejidad en función a la siguiente relación: PF=Cuenta total∗[0. además de que deben tener una evolución continua.15. Las aplicaciones basadas en la web son muy diferentes de las otras categorías de software. 2. 2.65: valor de ajuste de complejidad mínimo. portabilidad.

O podríamos decir que es lo que se puede esperar de un programa lleve a cabo su función con exactitud requerida.2 CONFIABILIDAD Es la probabilidad de operación libre de fallos de un programa en un entorno determinado y durante un tiempo específico.15.01: factor de conversión con un error de 1% 2.0. Estadísticamente es la probabilidad de operación libre de fallos de un programa de computadora en un entorno determinado y un tiempo específico. se utiliza la función λt exponencial dada por: F ( t )=f∗e En donde f : Funcionalidad del sistema λ : probabilidad de fallo en un periodo de tiempo t :tiempo total en el que se hace el calculo de fallo 36 . Para el cálculo de la confiabilidad del sistema se utiliza la siguiente ecuación: P (T ≥t )=1−F (t ) Dónde: F ( t ) : Probabilidad de ejecucion con fallas t :representa el periodo de tiempoen que se pone a prueba el sistema 1−F ( t ) : Probabilidad de ejcucion sin fallas Para hallar la probabilidad de falla del sistema F(t) en el periodo t .

15. El grado de portabilidad del sistema está dado por la siguiente ecuación: 37 .5 PORTABILIDAD Es el esfuerzo necesario para transferir el programa de un entorno de sistema hardware y/o software a otro. Calculamos el índice de madurez de software con la siguiente relación: IMS=[ M t −( F c + F a+ F d ) ] / M t Dónde: M t :número de modulos en laversion actual Fc :números de modulos en la version actual que se han cambiado Fa :números de modulos enla version actual que se han añadido Fd : números de modulos en la version anterior que se han eliminado en la version actual A medida que el IMS se aproxima a 1. facilidad de cambio establecido y facilidad de prueba.4 USABILIDAD Grado en el que el software es fácil de usar. el producto se empieza a estabilizar. 2. se mide a través del esfuerzo necesario para aprender a utilizar el sistema.2.15. ya sea según su interfaz o manual de usuario. Este Factor de calidad viene dado según el estándar IEEE 982 1998 y por la métrica del índice de madurez del software (IMS) que proporciona una indicación de la estabilidad del producto software.15. Se lo calcula mediante el porcentaje de una encuesta elaborada a un cierto número de clientes 2. basada en el cambio que ocurre en cada versión del producto.3 MANTENIBILIDAD La facilidad de realizar una modificación. indicada por los siguientes sub atributos: facilidad de análisis.

16. Redesarrollar el sistema es mas rentable que transportalo 2.. Costo de Transportar GP=1−( ) Costo de Redesarrollar Dónde: GP :Grado de Portabilidad GP> 0. debido a esto se propone el uso de las siguientes medidas que servirán para la definición de métricas orientadas a aplicaciones web [Pressman.Las páginas web dinámicas son aquellas en las que las acciones del usuario generan contenido personalizado. Portabilidad del sistema es mas rentable que el redesarrollo GP=1. Estas dos medidas proporcionan un indicio del tamaño global de la aplicación y el esfuerzo necesario para desarrollarla. 2. 2006]: 2.Las páginas web estáticas son aquellas en las que el usuario no controla el contenido de la página de la página. 38 .. Esta medida proporciona un indicio del grado de acoplamiento arquitectónico dentro de la aplicación web.3 Número de vínculos internos de la página (NVI).16. Estas páginas representan una complejidad relativamente baja y por lo general requieren de menos esfuerzo al construirlas.16 METRICAS PARA APLICACIONES WEB Las métricas que se emplean en los sistemas de información tradicionales son difíciles de aplicar directamente en aplicaciones web. 2.Los vínculos internos de la página son hipervínculos que ofrecen un enlace hacia otra página dentro la aplicación web.1 Número de páginas web estáticas (NPE).. Portabilidad Perfecta GP<1.2 Número de páginas web dinámicas (NDP).16. Estas páginas representan una mayor complejidad y requieren más esfuerzo que las páginas estáticas.

2. 2005]: 39 .2. pues existirán más páginas web que actuaran sobre los objetos persistentes. El grado de complejidad crece si es mayor a 1. plataformas de hardware.4 Número de objetos de datos persistentes (NOP). Dado que las aplicaciones web residen en una red inter operan con muchos sistemas operativos diferentes navegadores.Una aplicación web puede tener acceso a uno o más objetos de datos persistentes como bases de datos o archivos.17 PRUEBAS PARA APLICACIONES WEB Se realizan pruebas a un producto software con el propósito de encontrar errores y finalmente corregirlos. Grado de acoplamiento=NVI /(NPE+ NDP) El grado de acoplamiento indica cuan relacionadas están las páginas de la aplicación web. Las etapas que se debe seguir para la prueba de aplicación son las siguientes [Pressman. Si el valor obtenido es cero significa que no existe acoplamiento entre las páginas de la aplicación web. si este valor es 1 significa que en promedio cada página contiene un hipervínculo hacia alguna otra página de la aplicación web.16.. Esta medida proporciona un indicio de la complejidad de la aplicación web. Si el grado es menor a 1 la complejidad no es mucha pues el número de páginas web es inferior al número de objetos persistentes. y así sucesivamente dependiendo del número de vínculos que se tengan en la aplicación web. Grado de Complejidad=( NPE+ NDP) /NOP El grado de complejidad indica cuan compleja es la aplicación web. la búsqueda de errores es todo un reto para los desarrolladores. protocolos de comunicación. En base a estas medidas se pueden definir las siguientes métricas: indice de personalizacion del usuario=NDP/(NPE+ NDP) Este índice varía entre cero y uno dependiendo del grado de personalización que la aplicación web ofrece al usuario.

luego se evalúan los resultados de su integración con el sistema. 6. 7.1. 40 . Las pruebas de unidad se encargan de verificar la menor unidad de diseño de software. Se pueden usar diferentes sistemas operativos. 3. Dado que las aplicaciones web están en constante evolución. que consiste en hallar la complejidad ciclomatica del programa..El modelo de contenido de la aplicación web es revisado para descubrir errores. Luego de ensamblar la aplicación web se realizan las pruebas de seguridad tomando en cuenta los criterios de seguridad observados. en este caso una página web. este valor representa el número de caminos de ejecución y el límite superior para el número de pruebas que se debe realizar. Una de estas técnicas es la del camino básico. Se aplican pruebas de unidad a los componentes de proceso. Se construye la arquitectura y se realizan las pruebas de integración. 2. La aplicación web se prueba con una población de usuarios finales controlada y monitorizada. el proceso de comprobación es una actividad continua. 5. 4.El modelo de diseño de la aplicación web es revisado para descubrir errores de navegación.. los enlaces de navegación son revisados para verificar su correspondencia. La aplicación web se implementa en una variedad de configuraciones de diferentes entornos. para así comprobar su compatibilidad con cada configuración. para esto se debe revisar las páginas en busca de errores tipográficos y gramaticales. Para esto se comprueban los procesos encapsulados en la página utilizando una técnica de prueba de software. para esto se pueden usar casos de pruebas basados en los casos de uso. navegadores y plataformas de hardware.

En este capítulo se va abordar la utilización de las fases en lo que compete la Determinación de Requerimientos del sistema y la Planificación del proyecto por medio de Scrum en su fase Pre – Game.1. 1 FASE PRE – GAME (SCRUM) – FASE INCEPTION (AUP) Scrum por definición no requiere documentación con diagramas de casos de uso ni diagramas de secuencia.1. lo que es la fase Inicial de AUP también comprende la modelación de los requerimientos por medio de diagrama de Casos de Uso. y en esta fase para la representación y comprensión de los requerimientos utilizaremos los Diagramas de Casos de Uso 3. definir los riesgos.2 COMPROMETIDOS CON EL PROYECTO. 41 . 3. así mismo se definirá el alcance del Proyecto. y que la implementacion debe considerar el tiempo minimo para su implementacion. la arquitectura del sistema. 3. Con AUP para una mejor comprensión del sistema utiliza de acuerdo a lo que sea conveniente al proyecto los diagramas más representativo de UML nivel 1.1 OBJETIVOS DEL PROYECTO El objetivo principal del presente proyecto es la implementacion de un software que reemplace a la planilla de excel que se tiene actuamente. pero asume la existencia de Diseño y código Orientado a Objetos basado en librerías y clases.

 StakeHolders (Clientes. se asignó lo que son los roles de Scrum con el siguiente equipo: Product Owner Gerencia Financiera Ing. también es el que escribe todas las historias de usuario. 3. Hugo Arzabe Ascarrunz MAXAM – FANEXA S. Álvarez Daza. Representa la voz del cliente. Alejandro Alvarado Foronda 42 . asegurando que el equipo trabaje de forma adecuada desde la perspectiva del negocio. Inversores). pero como en nuestro caso es una empresa y específicamente una aplicación para el Área de Activos Fijos dependiente de Contabilidad General y Gerencia Administrativa y Gerencia Financiera. las prioriza y las coloca en el Producto Backlog. Para la conformación de los equipos de trabajo se trató de seguir lo que Scrum necesita como mínimo para concluir el proyecto. Scrum Master: Jair Samuel Ventura Tovar Equipo: Jair Samuel Ventura Tovar Jefe de Sistemas: Ing.2 CONFORMACION DE LOS EQUIPOS. Es el destinatario final del producto.  Equipo.  Usuarios. Marco A.A.  Managers. asegurándose que el proceso Scrum se utilice como es debido. Su trabajo es eliminar los obstáculos que impiden que el equipo alcance el objetivo del Sprint. Es la gente que establece el ambiente para el desarrollo del producto.Para el desarrollo de la aplicación y siguiendo la forma de organización de Scrum se conformó un equipo de trabajo de acuerdo a los siguientes roles:  Producto Owner. Tiene la responsabilidad de entregar el producto cuyas habilidades transversales serán necesarias para realizar el trabajo. Proveedores.M Gerencia Administrativa: Tcnl. Se refiere a los que hacen posible el proyecto y para quienes va producir el beneficio acordado.  Scrum Master o Facilitador.

Jefe de Sistemas Planta Santivañez: Ing. Tabla 3. Rodrigo Rojas Romero Contador General: Lic. Prioridad: Alta Dependencia: ----- 43 . identifique con una cuenta y clave  Debe considerar que solo debe existir las especifica. contador. (Gallinas) Responsable de Activos Fijos: Lic. Álvarez Daza. Griselda Ortiz Cossio Gerencia Financiera: Ing.1 – Historias de Usuario del Proyecto Historia de Usuario: H1  Cuando se introduzca una cuenta que no 1 Ingresar al Sistema corresponda a la que se le dio  Como Gerente Financiero quiero que automáticamente el programa debe cada usuario que acceda al sistema se considerarlo como invitado. Nohelia Vazquez Daza Contabilidad de Costos: Lic. y encargado. Ernesto Barrientos Lic. Oscar Herbas Auditor Interno: Lic.  La cuenta de contador debe ser la única que Estimación: 1 dia pueda dar de baja un activo. Marco A. 3. cuentas de administrador. Hugo Arzabe Ascarrunz Gerencia Administrativa: Tcnl. Tagmina Thames Sandoval Usuarios.3 DETERMINACION DE LOS REQUERIMIENTOS La Determinación de los Requerimientos en las metodologías clásicas 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 recopilación 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.

44 . debe seguirse y tomar en cuenta el acceso de Estimación: 5 dias la UFV’s. “Encargado”.  Cada usuario de esta lista solo debe poder hacer Estimación: 1 dia ciertas operaciones.  Como Gerente Financiero quiero que cada  Las cuentas permitidas para esta aplicación solo usuario que manipule el sistema sea deben ser “Administrador”. registrado previamente para un mejor “Contador” e “Invitado”. Prioridad: Alta Dependencia: --- Historia de Usuario: H4 4 Asignación de Activos  Cuando se haga la búsqueda de un activo específico debe mostrarse la información  Como Gerente Administrativo quiero que correspondiente. clasificación: “Tipo. activos y por horas trabajada a  Cuando se realice el cálculo de la depreciación maquinaria.  Al realizar las diversas operaciones también Estimación: 3 dias debe mostrarse quien tiene el activo.  Se debe dejar la posibilidad de cambiar a futuro Prioridad: Alta Dependencia: H6 a otros métodos de depreciación.  Al ingresar una búsqueda por la codificación asignada no debe repetirse ni existir Estimación: 3 dias coincidencia. cada activo asignado se especifique a  Cada activo nuevo que se ingresa debe contener quien se lo entrega y en donde se en qué lugar se encuentra este activo. depreciaciones se lo realice por el método  Las formulas deben ser elaboradas por la parte de línea recta para la mayoría de los contable y auditoria. Grupo y Sub - Grupo”. Historia de Usuario: H2 2 Registro de Usuario  Que al acceder al programa no muestre otras cuentas que no sean la que estén permitidas. encuentra. Prioridad: Media Dependencia: H1 Historia de Usuario: H3 3 Generación de Código  Cada activo debe diferenciarse plenamente con esta nueva clasificación. Prioridad: Alta Dependencia: H15 Historia de Usuario H5 5 Calcular Depreciación  Al realizar esta operación debe ser idéntica a la  Como Gerente Financiero quiero que las planilla echa en Excel. control.  Como Gerente Financiero quiero la  También por el tema de crecimiento de activos codificación este en función a la siguiente debe contener otros 4 dígitos más.

Tipo: xx----Grupo: xx---Subgrupo: xx y el numero correlativo: xxxx  Cuando los activos se revalorizan los activos debe diferenciarse del resto de los activos Estimación: añadiendo una letra “R” al final. Estimación:  La planilla echa debe servir de base para la Prioridad: Alta Dependencia: ---.  Para el ingreso de estos valores para las plantas debe ingresar también los porcentajes para la Estimación: depreciación. Historia de Usuario: H6 6 Ingresar Tipo de Cambio  Al momento de ingresar los datos al sistema  Como Gerente Financiero quiero que el tipo cada activo debe contar con su UFV inicial y de cambio este en función a las UFV’s del su UFV final. Prioridad: Alta Dependencia: H3 Historia de Usuario: H8 8 Almacenamiento de los Datos  Debe almacenarse la información de cada operación y centros de costo. libre. construcción y diseño de la base de datos. Historia de Usuario: H9 9 Mostrar Reportes  Los reportes deben ser idénticos a la planilla que utilizan cada unidad. texto y pdf.  Como Jefe de Sistemas quiero que se  La construcción de la base de datos debe construya una base de datos relacional contemplar las normalizaciones respectivas.  Como Gerente Administrativo quiero que  Los reportes deben tener la posibilidad de los reportes sean construidos en función a migrar sus datos a Excel. Prioridad: Media Dependencia: H5 Historia de Usuario: H7 7 Clasificar Activo  Como Jefe de Sistemas quiero que la  La clasificación debe mostrar diez dígitos para clasificación siga el siguiente formato: cada activo. Prioridad: Alta Dependencia: H5. para el almacenamiento de la información  El almacenamiento debe realizarse un gestor generada durante la implementación. día de compra y del momento en que se realiza la operación de depreciar. las unidades dependientes. H6 45 . Estimación:  Debe mostrarse reportes de activos deducibles y no deducibles.  Cada reporte debe mostrarse de forma mensual y anual.

empresa y el desarrollo sea con herramientas libres de pago.  Que las operaciones que se realicen ayuden y Estimación: sean mas cortas. su valor residual permanezca en “1”. internet. Estimación:  También debe buscarse por medio del C.I quien Prioridad: Media Dependencia: H4 esta a cargo o a quien se lo asignara. Historia de Usuario: H12 12 Interfaz de Usuario  Que al momento de ingresar sea lo mas idéntico a la planilla echa en Excel para asi  Como Jefe de Sistemas quiero que el evitarse contratiempos en el manipuleo. Historia de Usuario 10 10 Revalorizar Activos  Como Gerente Financiero quiero que exista la posibilidad de revalorizar un activo que  Que cuando un activo termine su tiempo de ya haya terminado su tiempo de vida y vida. H12 Historia de Usuario H14 46 . Prioridad: Alta Dependencia: Historia de Usuario: H13 13 Plataforma Tecnológica  Que al momento de subir al servidor esta  Como jefe de Sistemas quiero que se aplicación debe poder verse en cualquier aproveche los servidores que cuenta la Centro de Costo dependientes de Maxam. aun esté en condiciones  La revalorización o restauración debe realizarlo Estimación: la parte contable. H7  Historia de Usuario: H11 11 Traspaso de Activos  Que exista la posibilidad de buscar por medio del código o nombre del activo.  Se debe realizar una evaluación y adecuarse a la plataforma que se cuenta en la empresa. Estimación: Prioridad: Media Dependencia: H8. interfaz sea lo mas amigable posible y en  Que contenga los mismos campos para el lo posible utilizar templates existentes en llenado de datos. Prioridad: Alta Dependencia: H3.  Como Gerente Financiero quiero que esta  Debe existir la posibilidad de ver la regional operación se realice juntamente con la juntamente su unidad de negocio y su centro asignación de cada activo. de costo.

Prioridad: Alta Dependencia: H2. hacer una baja. Unidades de Negocio. 47 .  La operación debe estar limitada simplemente  Como Gerente Administrativo quiero que para el encargado de activos fijos. Estimación 3 dias  Se debe crear una tabla en la base de datos para Prioridad: Alta Dependencia: H2 esta información. y como se mencionó este product backlog no es una lista fija e invariable de requisitos funcionales del sistema. la aplicación no se lo permita. Historia de Usuario H15 15 Registrar Responsable  Que al tratar de ingresar con otras cuentas la aplicación se desconecte automáticamente. esta operación lo realice el encargado de manejar ls activos fijos.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.  El registro de los responsables es para conocer quienes están a cargo o manejando los Estimación: 4 dia activos.  La baja de un activo debe realizarse solo cuando Estimación 4 dias el activo haya concluido su tiempo de vida. la modulo o menú para ingresar datos a la aplicación automáticamente se desconecte. sino que esta lista es un documento sigue para recibir más requerimientos en el desarrollo del sistema.H5. Prioridad: Media Dependencia: H2 Historia de Usuario: H16 16 Baja de un Activo  Como Gerente Financiero quiero que esta posibilidad solo sea posible para el contador  Cuando el encargado o el administrador quiera en el menú de activos.H10 3. Centros  Solo la cuenta de administrador debe poder de Costos y plantas que puedan contar y hacer las operaciones de registrar. modificar y se almacenen en la base de datos. Regional. eliminar estos datos. 14 Registrar Regional  Al momento de ingresar con cualquier cuenta  Como Jefe de Sistemas quiero que exista un que sea distinta a la del administrador.

Tabla 3.2 – Product Backlog del Proyecto Estimación del Como Probarlo Id Prioridad Estado Descripción Esfuerzo [días] H1 Alta Terminado Acceso de Usuarios 3 H2 Media Terminado Registro de Usuarios 2 H3 Alta Terminado Generación de Código 3 H4 Alta Terminado Asignación de Activo 2 H5 Alta Terminado Calcular depreciación 10 H6 Media Terminado Ingresar tipo de cambio 5 H7 Alta Terminado Clasificar Activos 5 H8 Alta Terminado Almacenar datos 5 H9 Alta Terminado Mostrar Reportes 5 H10 Alta Terminado Restaurar Activos 5 H11 Alta Terminado Traspaso de Activos 5 H12 Alta Terminado Interfaz de Usuario 3 H13 Media Terminado Plataforma tecnológica 5 H14 Media Terminado Registrar Regional 5 H15 Media Terminado Registrar Responsable 2 H16 Alta Terminado Baja de Activos 5 48 .

49 . Sprint H6: Ingresar Tipo de Cambio 4 semanas H7: Clasificar Activo H11: Traspaso de Activo H5: Calcular Depreciación H14: Registrar Regional 3er. Sprint H10: Restaurar Activo 5 semanas H16: Baja de Activo H9: Mostrar Reportes Esta planificación es el Sprint 0 para dar comienzo a las iteraciones que se desarrollara en la fase Game del siguiente capítulo.3 – Release Plan del Proyecto Tiempo Iteración Historia de Usuario Estimado H13: Plataforma Tecnología H1: Acceso al Sistema H2: Registro d Usuario 1er. Sprint 4 semanas H12: Interfaz de Usuario H8: Base de datos H15: Registrar Responsable H4: Asignación de Activos H3: Generación de Código 2do.3.5 RELEASE PLAN: Tabla 3.

se describen a continuación así como las estrategias que se propusieron para hacerlo frente. 3. Que afectan a la calendarización o recursos del proyecto. Que afectan a la calidad o rendimiento del software que se está desarrollando.7.6 ALCANCE DEL PROYECTO Con el presente proyecto se pretende obtener y contar con una herramienta que ayude en el cálculo de la Depreciación que se realiza actualmente con un planilla echa en Excel lo cual también sirve para realizar los cierres respectivos de cada mes en contabilidad y las respectivas unidades que requieran de los informes que se genera. 3. El presente proyecto como cualquier otro proyecto no está libre de varios riesgos o dificultades que podría atravesar en el transcurso de su desarrollo. 1 Riesgo del Proyecto. 3.7 ANÁLISIS DE RIESGO. que se detallara en el anexo A.7. de los cuales describiremos a continuación: 3. retrasos.7. Cambio Proyecto.3 Riesgo del Negocio. se cumplan a considere los cabalidad. 3. Tabla 3. en cuanto se tenga los casos de uso del sistema que para la estimación de los costos utilizaremos los puntos por casos de uso.1 ESTIMACION DE COSTOS: La estimación de los costos lo dejaremos para más adelante.6 . Un riesgo es la probabilidad que exista algo adverso a lo planificado.2 Riesgo del Producto.3.4 – Análisis de Riesgos Riesgo Tipo Descripción Probabilidad Efecto Estrategia No se cumple Proyecto Probablemente las Alta Tolerable Diseñar un con las fechas fechas previstas en cronograma establecidas en el cronograma no flexible que el cronograma. Punto primordial Media Tolerable Realizar una continuo en los producto de la metodología revisión constante 50 . Afecta a la organización que desarrolla o suministra el software.

No se cumple Producto El plazo límite de Moderada Serio Agilizar los con el plazo de entrega del procesos de entrega del producto fue en el desarrollo. no afecte en el desempeño de los demás No existen los El Maxam – Fanexa Alto Tolerable Solicitar a equipos constante por el uso masivo Gerencia necesarios para cambio de de equipos y Financiera que se la equipos distribución a sus otorgue un equipo implementación hace que centros es limitante para el desarrollo del sistema. entrega. Realizar correcta pero por cierre de planificación de gestión y vacación tiempos colectiva abra un considerando los retraso en la ingresos a planta. mes de diciembre. 3. producto. continuamente a requerimientos.requerimientos para adaptarse de los del cliente. No se concluya Producto Por el gran número Alto Tolerable Separar los con algunos de de requerimientos módulos en el los y el poco tiempo sistema de tal requerimientos. sea el acceso a uno de dificultoso ellos. cliente.8 IDENTIFICACIÓN DE LOS ACTORES DEL SISTEMA. desarrollar. los cambios que Programar pueda darse en el reuniones transcurso del constantes con el proyecto. de desarrollo no se forma que la cumpla alguno de ausencia de uno ellos. 51 .

5 – Descripción de Actores Actor Proceso Administrador del Sistema  Administración de Usuarios  Registro y Modificación de perfiles de acceso. Encargado de Activo  Registro de activos fijos  Registro y modificación de parámetros. Es cualquier otra persona de la empresa que solicite ver simplemente reportes para su uso en cada cierre de mes o gestión.  Reportes. pero no puede dar baja ningún activo. Es el encargado de la administración de la aplicación quien al mismo tiempo realiza operaciones de: registro de nuevos usuarios.  Registro y Modificación de Regiones. Contador  Dar baja a los activos fijos  Demás otras operaciones de encargado. Es el usuario del manejo de la aplicación por lo tanto tiene acceso a todas las opciones de la aplicación a excepción de ingreso de nuevos usuarios y dar de baja algún activo. control y seguimiento de los activos fijos (búsquedas.  Registro y generación de reportes de inventario Usuario de Reporte (Invitado)  Solicitar y generar reportes 3.Dentro los actores del sistema tenemos a los siguientes casi independientes de los otros: Administrador.  Reportes. Descripción de los Actores. esto según requerimiento del cliente. Invitado. también puede hacer las otras operaciones que los demás a excepción de crear nuevos usuarios.  Búsquedas. Contador. reportes). Tabla 3.9 ENTORNO PARA EL DESARROLLO DEL PROYECTO 52 .  Búsquedas. Es el encargado de hacer específicamente las bajas de los activos que ya terminaron su tiempo de vida. Encargado de Activos Fijos.

la metodología AUP para esta fase como en las anteriores apoyara en la 53 . 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 país.0  Tener un navegador (internet Explorer 6 o superior. Como requerimientos mínimos de hardware y software que debe considerarse para implementar esta aplicación se debe tomar lo siguiente:  1 PC Pentium IV o superior  Memoria RAM 512 MB.Para el desarrollo del presente proyecto se hizo el siguiente requerimiento de software y verificación de lo que contaba la empresa respecto a la arquitectura disponible para el desarrollo de la presente aplicación: 3. lo recomendable navegador mozilla firefox 3.x. En este capítulo se desarrollara la construcción de los sprint para cada iteración planificada en el Reléase Plan.(recomendable 1GB para un buen rendimiento)  Sistema Operativo Windows XP profesional  Tener configurado el servicio de Internet del servidor IIS.1 ESPECIFICACIÓN DE HARDWARE El sistema trabaja bajo un entorno web (cliente – servidor).9.  Framework 2.x).  Tener activado flash player 9_2_p2_32bit_plugin_111710 o superior Estos requerimientos vienen a ser parte de los requerimientos no funcionales del sistema.

1.1 FASE GAME (SCRUM) – FASE ELABORATION Y FASE CONSTRUCTION (AUP) Como parte de la fase de construcción del modelo AUP se desarrollara la implementación de las respectivas iteraciones más las pruebas exigidas en esta fase. 4. 4. la Pila del Sprint.representación del sistema por medio de artefactos basados en UML. La planificación del Sprint dará como resultado: el objetivo del Sprint.1.1 PLANIFICACION DEL SPRINT La planificación 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 iteración. Para el presente trabajo se detalla a continuación 4.2 OBJETIVO DEL SPRINT 54 .1.1 PRIMER SPRINT 4.1. la duración del Sprint. lo cual hará más comprensible al presente proyecto.1. Esta planificación se lo realiza mediante dos reuniones divididas en dos partes: 1ra Parte: Se realiza la estimación 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 realizar Cosas que puede necesitar o impedimentos que debe suprimirse para realizar el trabajo.

La tabla 4.1 muestra al primer Sprint 55 .El objetivo del primer sprint es mostrar la página principal con toda la estructura que se agregara en los siguientes Sprint como ser: acceso al sistema. la interfaz que se mostrara y comienzo de la base de datos que se tendrá. registro de usuario.

Donde las funcionalidades correspondientes al incremento de la iteración son: 56 .

 Base de Datos independiente de los otros sistemas existentes.2 – Descripción del Caso de Uso Acceder al Sistema 57 . 4.  Página de ingreso con control de acceso a los usuarios  Asignación de responsables DIAGRAMAS DE CASOS DE USO DEL SPRINT uc Use Case Model Acceder al Sistema Usuario Gestion Usuario Gestion Responsable Gestion: Adicionar Modificar Eliminar Administrador Inv itado Encargado Gestion Unidad de Negocio «include» «extend» «include» «extend» «include» «extend» Registrar Unidad de Registar Regional Registrar Centro de Contador Negocio Costo Fig.1 – Diagrama de Casos de Uso del Sprint 1 ESPECIFICACION DE LOS CASOS DE USO Tabla 4.

Pre condiciones: El usuario debe estar registrado en el sistema con anterioridad. se abre la pantalla principal de la aplicación dependiendo al rol del usuario (Administrador. 6. y puede utilizar el sistema. Flujo Normal: 1. El actor ingresa su cuenta y password. Una vez verificada la cuenta del usuario. Post condiciones: El usuario ha sido autenticado. Puede ver el listado de quienes están como usuarios. Si el ingreso de la cuenta y pasword son incorrectos la Excepciones aplicación mostrara un mensaje de error 58 . para que pueda Descripción: ingresar y utilizar el sistema. Tabla 4. El usuario ingresa sus datos personales. termina la ejecución de la aplicación Flujo Alternativo: 2A. El administrador se encarga de realizar el manejo de usuarios Resumen desde la creación a la eliminación. 4. Que el usuario a utilizar sea parte de la empresa o que cuente Precondiciones con la autorización del encargado de sistemas. Operador. 4. o Director Ejecutivo). El usuario asigna que tipo de rol será el nuevo usuario. El sistema busca la cuenta y el password en la base de datos y lo valida en el sistema. el sistema muestra un mensaje de Error. El usuario ingresa al módulo de registro 3. 2. Director Académico. Si el actor presiona el botón Cancelar.3 – Descripción Caso de Uso Gestión Usuario Caso de Uso Gestión Usuario Actores Administrador Tipo Básico.Nombre: Acceder al Sistema Actores: Usuario Windows Tipo: Básico Valida al usuario mediante una cuenta y password. Toda la información es almacenada en la base de datos de la aplicación. 3. El usuario ingresa a la página de la aplicación 2. 1. Flujo Principal 5. y presiona el botón Aceptar. Si la cuenta o el password no se validó correctamente.

Subflujos 2. 9. Excepciones Si el ingreso es con otra cuenta no podrá acceder a esta opción que es privilegio solamente para el administrador de la aplicación o el Depto de Sistema de la Empresa. El usuario administrador debe presionar el botón registrar o cancelar cuando haya terminado este proceso. Si el administrador selecciona “Registrar Unidad de Negocio” tendrá una pantalla casi parecida a la anterior. 8. Si el administrador selecciona “Registrar Regional” contara con las siguientes opciones: 4.Descripción Caso de Uso Gestión Unidad de Negocio Caso de Uso Gestión Unidad de Negocio Actores Administrador Tipo Básico.4 . Ingresar el nombre del departamento o región importante que se considere. Flujo Principal 1. El sistema muestra el menú de “Uni Neg” con las siguientes opciones: Registrar Regional. 6. Para la creación de nuevas regionales debe asignarse un identificador numeral de dos dígitos y que identificara a cada departamento del país. 7. Registrar Unidad de Negocio y Registrar Centro de Costo. Tabla 4. solo que antes debe seleccionar la región en donde va registrar la nueva Unidad de Negocio. Si el administrador selecciona la opción 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.5 – Descripción Caso de Uso Gestion Responsable 59 . El usuario administrador una vez hecha la operación puede ver el listado y si hay algo que modificar tiene la opción de editar o eliminar directamente. 3. El administrador ingresa al módulo de “Unidad de Negocio” y dependiendo de las opciones seleccionadas por el usuario se continuara con los diversos subflujos. Tabla 4. Precondiciones Que el administrador solo es capaz de crear nuevas Regionales en caso de que la empresa se extienda a nivel nacional y bajo autorización directa de Gerencia General de la empresa. 5.

1 PLANIFICACION DEL SPRINT La siguiente tabla 4. Si el usuario elige la opción Nuevo Responsable muestra su propia pantalla en donde el usuario debe llenar todo los campos correspondientes a datos personales. traspaso del activo. 60 . Subflujos 1. 4. el tipo de cambio. 4.I y Nombres y se mostrara una tabla en donde se podrá modificar y eliminar al responsable. Si el usuario elige la opción Ver Listado. 5.6 muestra el desarrollo del segundo Sprint. El sistema muestra el menú Responsable con las siguientes opciones: “Nuevo Responsable. El caso de uso comienza cuando el usuario elige la opción del módulo Responsable de la pantalla principal.I y Nombres y luego vera una tabla mostrando la información de los responsables ingresados. tendrá la opción de buscar al responsable mediante el campo C.2 OBJETIVO DEL SEGUNDO SPRINT: Es desglosar y aumentar las operaciones como asignación del activo. Editar eliminar y Ver listado”. Tipo Básico.2 SEGUNDO SPRINT 4. puede efectuar las siguientes operaciones: buscar al encargado por los campos C.1.2.2. 3. 2. Precondiciones Que el usuario sea ya parte del sistema Flujo Principal El usuario ingresa al módulo Responsable y dependiendo de las opciones seleccionadas por el usuario se continuara con los diversos subflujos.1. Excepciones Si no se conoce el código que es en la mayoría de las búsquedas el parámetro de búsqueda debe escribir el carácter “%” 4. Caso de Uso Gestion Responsable Actores Encargado y Contador.1. Si el usuario elige la opción Editar y Eliminar.

61 .

2 – Casos de Uso del Segundo Sprint ESPECIFICACION DE LOS CASOS DE USO Tabla 4.7– Descripción Caso de Uso Gestión Activo 62 . 4.DIAGRAMAS DE CASOS DE USO DEL SEGUNDO SPRINT uc Use Case Model Acceder al Sistema Gestion Tipo Activ o Gestion: Adicionar Traspasar Activ o Modificar Eliminar Usuario Gestion Usuario Asignar Activ o Registrar Tipo de Cambio Administrador Encargado Inv itado Gestion Unidad de Negocio Gestion Responsable «extend» «extend» «extend» Registar Regional Registrar Unidad de Contador Negocio Registrar Centro de Costo Fig.

y también se desplegara la ventana para registrar los valores de las depreciaciones correspondientes al último mes depreciado. GRUPO.8 – Descripción Caso de Uso Asignar Activo 63 . descripción. 3. El usuario al ingresar los datos del activo tiene la posibilidad de registrar desde el nombre. El usuario puede notar que automáticamente va generándose un código de acuerdo a los requerimientos hechos. contador Tipo Básico Precondicione Que el usuario a utilizar sea parte de la empresa o que cuente con la cuenta s de Encargado o Contador para poder utilizarlo libremente. Tabla 4. 1. cantidad.Caso de Uso Gestión Activo Actores Encargado. Asignar Activo. y en el caso que sea un activo existente debe presionarse el botón Llenar Depreciación del último mes. Una vez concluida el usuario tiene las opciones de aceptar o cancelar la operación. 6. puede seguir efectuando esta operación si existiesen más activos solo presionar el botón nuevo. 5. El usuario accede a la opción Nuevo Activo puede registrar un nuevo activo con las posibilidades de agregar un nuevo: TIPO. El usuario una vez terminado el registro también cuenta con la posibilidad de ver los reportes o efectuar la asignación Excepciones El ingreso a la aplicación es netamente para usuarios que tengan el permiso por el departamento de sistemas. Flujo El usuario ingresa al módulo de “Activos” y dependiendo de las opciones Principal seleccionadas por el usuario podrá operar las pestañas libremente. 2. UFV inicial y si es deducible o no. Una vez que el usuario termine debe presionar Registrar si el caso fuera nuevo activo que se incorpore. costo. y SUBGRUPO que servirán para ingresar los nuevos datos del nuevo activo. Baja de Activo. Depreciación y Tipo de Cambio. Subflujos La aplicación muestra el menú de “Activos” con las siguientes opciones: Nuevo Activo. 4.

2. y verificar si está correctamente y aceptarlo o rechazarlo en caso contrario. la tabla nos mostrara en qué estado se encuentra. El usuario puede realizar el traspaso o la asignación dependiendo del estado que se encuentra el activo. El usuario una vez que este efectuando una de las operaciones en cuestión deberá seleccionar la Región. 7. El usuario encargado de efectuar este proceso al acceder al módulo activo puede observar esta opción. Unidad de Negocio y el centro de costo donde será el destino de o los activos. 6. Flujo Principal 1. Para terminar el usuario podrá observar un resumen de todas las selecciones que realizo. 4.Caso de Uso Asignar Activo Actores Encargado. 5. El usuario una vez que termine la anterior operación debe buscar al responsable por los campos CI o nombres. contador Tipo Básico Precondiciones Que el usuario a utilizar sea parte de la empresa o que cuente con la cuenta de Encargado o Contador para poder utilizarlo libremente. Excepciones El ingreso a la aplicación es netamente para usuarios con cuenta de encargado Contador. Si el estado del activo es “No Asignado” entonces se efectuara la asignación. Tabla 4. 3. Si el estado es “Asignado” entonces se efectuara traspaso de un lugar a otro o de un responsable a otro. El usuario una vez que accede a esta opción lo primero que efectúa es buscar al activo por el código o por el nombre. 8.9 – Descripción Registrar Tipo de Activo 64 . y seleccionar a quien se le otorgara la responsabilidad.

y SUBGRUPO que servirán para ingresar los nuevos datos del nuevo activo. contador Tipo Basico Precondiciones Que el usuario a utilizar sea parte de la empresa o que cuente con la cuenta de Encargado o Contador para poder utilizarlo libremente. El usuario al ingresar los datos del activo tiene la posibilidad de registrar desde el nombre. 6. También puede editar o eliminar el activo que no haya sido registrado adecuadamente. 4. El usuario puede notar que automáticamente va generándose un código de acuerdo a los requerimientos hechos.1 PLANIFICACION DEL SPRINT 65 . 3. y en el caso que sea un activo existente debe presionarse el botón Llenar Depreciación del último mes. y también se desplegara la ventana para registrar los valores de las depreciaciones correspondientes al último mes depreciado. Excepciones El ingreso a la aplicación es netamente para usuarios que tengan el permiso por el departamento de sistemas. 7.1. UFV inicial y si es deducible o no. cantidad. 5.1. 2.3 TERCER SPRINT 4. descripción. costo. Una vez concluida el usuario tiene las opciones de aceptar o cancelar la operación. El usuario accede a la opción Nuevo Activo puede registrar un nuevo activo con las posibilidades de agregar un nuevo: TIPO. puede seguir efectuando esta operación si existiesen más activos solo presionar el botón nuevo. Subflujos 1. GRUPO. Una vez que el usuario termine debe presionar Registrar si el caso fuera nuevo activo que se incorpore.3. El usuario una vez terminado el registro también cuenta con la posibilidad de ver los reportes o efectuar la asignación. 4. Caso de Uso Registrar Tipo de Activo Actores Encargado. Flujo Principal El usuario ingresa al módulo de “Activos” y directamente muestra la pantalla de la opción “Nuevo Activo” con todas las características.

Restaurar los activos.2 OBJETIVO DEL 3ER SPRINT: Mejorar la apariencia de la interfaz. Calcular la Depreciación. elaborar reportes y dar de baja al activo que ya no esté disponible.3.1.La tabla 4. Restringir operaciones de acuerdo a roles asignados. 66 .10 muestra los detalles del tercer sprint 4.

uc Use Case Model Gestion Tipo Activ o Registrar Tipo de Cambio «extend» Gestion Activ o «include» Acceder al Sistema Asignar y Traspasar Depreciacion Activ o Usuario Gestion Responsable Gestion Usuario Reestablecer Activ o Encargado Gestion: Administrador Adicionar Modificar Inv itado Contador Baj a Activ o Eliminar Gestion Unidad de Negocio Nuev o Activ o «include» ESPECIFICACION DE LOS CASOS DE USO 67 «include» Reportes «include» Busquedas «include» «include» Registar Regional Registrar Unidad de «include» Activ os Negocio «include» Registrar Centro de «include» Costo Depreciacion Unidad de Negocio Baj as Tabla 4.3 – Clases del Tercer Sprint Diagrama de .11 – Descripción Caso de Uso Registrar Tipo de Cambio Fig. 4.

1. 2. Tabla 4. y debe almacenar para su posterior depreciación. 4. Subflujos La aplicación mostrara la ventana principal de esta opcion en la cual deberá llenar la información requerida.12 – Descripcion Caso de Uso Depreciar Activo 68 . El usuario una vez terminado el almacenamiento tiene la opcion de modificar los datos antes de realizar la operación de “Depreciacion”. El usuario debe seleccionar al tipo de activo con el método a depreciar. Flujo Principal El usuario ingresa al módulo de “Activos” y directamente muestra la pantalla principal en la cual debe escoger la opción “Tipo de Cambio” en la cual se mostrara su pantalla principal.Caso de Uso Registrar Tipo de Cambio Actores Encargado Tipo Include Precondiciones Que el usuario a utilizar sea parte de la empresa o que cuente con la cuenta de Encargado para poder utilizarlo libremente. 3. Excepciones El ingreso a la aplicación es netamente para usuarios que tengan el permiso por el departamento de sistemas. El usuario debe ingresar los porcentajes para cada planta que cuenta las maquinarias de la empresa. El encargado debe Escoger el mes y el año para posteriormente llenar los campos de las UFV inicial como final. 5. El encargado debe verificar los datos ingresados en la tabla que se muestra y en caso de que se equivoque debe registrar nuevamente.

Excepciones El ingreso a la aplicación es netamente para usuarios que tengan el permiso por el departamento de sistemas. 3. La pantalla principal de esta opcion mostrara la opcion del botón “Depreciar Activo” el cual una vez ingresado los datos requeridos en el tipo de cambio podrá realizar esta operación. 2. El usuario puede realizar modificaciones a la información errónea que exista para su respectiva modificación. Subflujos 1. El usuario encargado puede buscar a los activos recién ingresados y verificar la información que contiene.13 – Descripcion Caso de Uso Dar Baja de Activo 69 . 4. El usuario encargado debe verificar el mes y el año a depreciar. Flujo Principal El usuario ingresa al módulo de “Activos” y directamente muestra la pantalla de la opción “Depreciacion” con las opciones a desarrollar.Caso de Uso Depreciar Activo Actores Encargado Tipo Basico Precondiciones Que el usuario a utilizar sea parte de la empresa o que cuente con la cuenta de Encargado o Contador para poder utilizarlo libremente. 4.

Excepciones El ingreso a la aplicación es netamente para usuarios que tengan el permiso por el departamento de sistemas. Una vez concluida el usuario tiene las opciones de aceptar o cancelar la operación. y SUBGRUPO que servirán para ingresar los nuevos datos del nuevo activo. UFV inicial y si es deducible o no. Baja de Activo.Caso de Uso Dar Baja Activo Actores Contador Tipo Basico Precondiciones Que el usuario a utilizar sea parte de la empresa o que cuente con la cuenta de Encargado o Contador para poder utilizarlo libremente.14 – Descripcion Caso de Uso Restaurar Activo 70 . Flujo Principal El usuario ingresa al módulo de “Activos” y directamente muestra la pantalla de la opción “Nuevo Activo” con todas las características. Tabla 4. Subflujos La aplicación mostrara el menú de “Activos” con las siguientes opciones: Nuevo Activo. 1. También puede editar o eliminar el activo que no haya sido registrado adecuadamente. 6. 2. descripción. Asignar Activo. y en el caso que sea un activo existente debe presionarse el botón Llenar Depreciación del último mes. Depreciación y Tipo de Cambio. El usuario al ingresar los datos del activo tiene la posibilidad de registrar desde el nombre. y también se desplegara la ventana para registrar los valores de las depreciaciones correspondientes al último mes depreciado. El usuario puede notar que automáticamente va generándose un código de acuerdo a los requerimientos hechos. cantidad. puede seguir efectuando esta operación si existiesen más activos solo presionar el botón nuevo. costo. Una vez que el usuario termine debe presionar Registrar si el caso fuera nuevo activo que se incorpore. 3. GRUPO. pero que cada uno es un diferente caso de uso. El usuario una vez terminado el registro también cuenta con la posibilidad de ver los reportes o efectuar la asignación. 5. El usuario accede a la opción Nuevo Activo puede registrar un nuevo activo con las posibilidades de agregar un nuevo: TIPO. 4.

Precondiciones Que el usuario a utilizar sea parte de la empresa o que cuente con la autorización del encargado de sistemas. contador e invitado Tipo Básico. El usuario ingresa a la página de la aplicación 2. . 3. Una vez que el usuario termine podrá pasar a la parte de la restauración en curso tomando al activo en cuestión mediante el código y luego asignarle nuevo valor monetario al activo y nuevo tiempo de vida. El usuario contador tiene la opción de Restaurar al activo en cuestión. Todos los usuarios que cuenten con acceso a la aplicación pueden ver la información referida a activos fijos. Excepciones Si no se conoce el código que es en la mayoría de las búsquedas el parámetro de búsqueda debe escribir el carácter “%” Tabla 4. Excepciones El ingreso a la aplicación es netamente para usuarios que tengan 71 el permiso por el departamento de sistemas. 4. El usuario contador puede buscar por el nombre o por el código a los activos en cuestión y se le mostrara la información del o los activos que ya hayan concluido el tiempo de vida o su valor residual sea igual a 1. Precondiciones Que el rol del usuario asignado sea “Contador” Flujo Principal El usuario Contador ingresa al módulo “Activos” y al menú “Restauración de Activo” se le presentara la pantalla de dicha opción con las siguientes alternativas: 1.15 – Descripcion Caso de Uso Reportes Caso de Uso Reporte Actores Administrador. Es la parte estatica de la aplicación en donde el usuario no puede modificar ni tocar simplemente puede observar e imprimir lo que le sea necesario. También el usuario podrá ver el seguimiento del activo y ver la información. 4. y para eso deberá seleccionarlo previamente. Flujo Principal 1. 2. Tipo Básico.Caso de Uso Restauración Activo Actores Contador. El usuario ingresa sus datos personales. pero que sea correspondiente al tipo de activo ya definido por la empresa. 3. encargado.

16 – Descripción de Caso de Uso Búsquedas 72 .Tabla 4.

6. El usuario debe ingresar el código del activo.1 El usuario puede elegir la región en donde se encuentra.Caso de Uso Búsquedas Actores Administrador. Si el usuario elige Ubicación se abre otras opciones de busque como: 4. 73 Excepciones Si no se conoce el código que es en la mayoría de las búsquedas el parámetro de búsqueda debe escribir el carácter “%” . 3. El usuario puede observar la información de todos los activos que busca y la cantidad de los mismos.2 El usuario puede elegir la unidad de negocio. 3.2 El usuario debe seleccionar el tipo de activo para ver la información sobre la depreciación. contador e invitado Tipo Básico.1 El usuario tiene un campo para ingresar C. 5. Si el usuario elige Busquedas de activos se muestra la pantalla de dicha opción que el usuario debe seguir lo siguiente: 3. El sistema muestra el menú búsquedas con las siguientes opciones: “Búsquedas de activos”. y mediante este parámetro es posible comenzar la búsqueda que luego el usuario debe seleccionar y luego vera la información de todos los posibles activos que está a su cargo. 4.I. Subflujos 1.”ubicación”.”Responsable” y ”Activos Dados de Baja”. 4. el centro de costo y presionar el botón buscar. Precondiciones Que el usuario sea ya parte del sistema Flujo Principal El usuario ingresa al módulo de búsqueda y dependiendo de las opciones seleccionadas por el usuario se continuara con los diversos subflujos. El usuario elige la opción Activos Dados de Baja se encontrara con lo siguiente: 8. El caso de uso comienza cuando el usuario elige la opción de modulo búsqueda la pantalla principal (P – x ) 2. y aparecerá con la opción de restablecer acompañado de un mensaje de si desea restablecer o no? y el usuario debe aceptar para restablecer. El usuario elige la opción Búsqueda por Responsable se presenta los siguientes caso: 6. 7.1 El usuario puede ingresar el código o un carácter (%) especial para obtener en forma global información sobre la depreciación de los activos buscados. encargado.

Deducible: boolean . Gas_Dep: float .Regional: string . Fecha_Activacion: date 1 + eliminar() : void . Tiempo_Vida: int . 4.Unidad: string . Fecha_Incorporacion: date . Nombre: string .CentroCostos: string DEPRECIACION . Act_Dep_Acum: float . Dep_Acum: float . Fecha_asig: string NO_DEDUCIBLE . Ubicacion: string . Mes: string . Provincia: string .* 1 ACTIVO . Fecha: date . Valor: float . Costo: float . Porcentaje: float . Email: string . string) : long + modificar() : void + eliminar() : void + registrar() : void + modificar() : void + registrar() : void 10. Apellido: string .* .* . Act_Mes: float . Acum_Act: float . Vida: float . Valor_Recidual: float + eliminar() : void + modificar() : void RESPONSABLE + calcular_depreciacion(string) : void + reestablecer(string) : void + registrar() : void . UFV_Final: float 1. Localidad: string DEDUCIBLE . Cantidad: int UNIDAD_DE_NEGOCIO 1 . Descripcion: string . Valor_DI: float + generar_codigo(string. UfvInicial: float + eliminar() : void . string) : void . Valor: float + baja(string. Vida_Util: float . Valor_Actu: float + buscar(string.. Fecha: date . Cargo: string + Cuenta: string .DIAGRAMAS DE CLASES PERSISTENTE class Class Model TIPOACTIVO .* . Nombre: string + reestablecer_activo(string) : void .Impuesto: float 1 + buscar() : void + llenar_datos() : void + editar() : void USUARIO + eliminar() : void . Cargo: string 0. Ufv_Final: float 0.. Año: int . Dep_A: float .. Gestion: int 1 . Baja: boolean . Nombre: string + Password: string + Rol: string + buscar(string) : void + eliminar() : void + modificar() : void + registrar() : void FIg.4 – Diagrama de Clases Persistentes 74 . Sub_Grupo: string . Responsable: string . Tipo_Depreciar: string . Estado: string .. Ufv_Ini: float + asignar(string. string) : void . Af_Acum_Ant: float + modificar() : void . string. Apellidos: string + registrar() : void . Grupo: string . UFV_Inicial: float . Unidad: string . Porcentaje: float . UfvFinal: float + buscar(string) : void . Fecha_Compra: date . string) : void . Planta_DI: string . Mes: string . Departamento: string 1 . Af_Mes: float + registrar() : void . Tipo_Moneda: string * . Descripcion: string TIPO_CAMBIO .

4.DIAGRAMA DE COMPONENTES deployment despliegue SERVIDOR SERVIDOR IIS Cliente CrystalReports HTTP Serv idorBdD SQL-SERVER «TCP/IP» «TCP/IP» «library» «executable» plugin Flash Nav egador web «use» Framework .5 – Diagrama de Componentes del Sistema MODELO RELACIONAL DE LA BASE DE DATOS 75 .0 Fig.NET 2.

. class Schema1 USUARIO TIPODEPRECIAR PLANTASDI «colum n» TCAMBIO *PK CUENT A: nvarchar(50) «colum n» «colum n» * PASWORD: nvarchar(50) *PK i d: i nt «col um n» *PK i d: i nt * NOM BRE: nvarchar(50) * T IPOACT IVO: nvarchar(50) *PK id: int * di : nvarchar(500) * T IPODEPRECIAR: nvarchar(50) +PK_T CAM BIO * APELLIDOS: nvarchar(50) * UFVINI: float +FK_PLANT ASDI_T CAMBIO * produccion: fl oat EMAIL: nvarchar(50) * M ES: i nt * UFVFINAL: float +PK_T CAM BIO * m es: int (IDT CAMBIO = i d) * FECHA: dateti me * ANIO: i nt * MES: nvarchar(50) * ani o: i nt CARGO: nvarchar(50) * M ESNOM BRE: nvarchar(50) 0.....* 1 (DOC = RESPONSABLE) * VALACT FIJO: fl oat FK UBICACION: i nt «colum n» * ACT PRESM ES: float (IDA = CODA) *PK DOC: nvarchar(50) DEDUCIBLE: nvarchar(30) * VALACT : fl oat VFINICIAL: fl oat +PK_RESPONSABLE * NOM BRE: nvarchar(80) * DEPAFM ES: float +FK_DEPRECIACION_ACT IVO VFFINAL: float * APELLIDOS: nvarchar(100) 1 * DEPAFACANT : fl oat *FK CODT A: nvarchar(10) * CARGO: nvarchar(100) * ACT DEPACUM: fl oat 0.* +FK_CODA 0.* *pfK CODA: nvarchar(10) +PK_REGIONAL 1 SG * DESCRIPCION: nvarchar(200) * VIDA: float REGIONAL VIDAM ESES: fl oat «col um n» * VALOR: fl oat «colum n» *PK ID: int +FK_CODA DEPAA: float *PK IDR: i nt *FK CODSG: nvarchar(10) * NOMBRE: nvarchar(500) +PK_SG GASDEP: fl oat * REGIONAL: nvarchar(100) 0.* * CANT IDAD: i nt (IDACT =CODA) «PK» * UNIDAD: nvarchar(50) + PK_BAJA(i nt) * COST O: fl oat T M ONEDA: nvarchar(10) «FK» 76 * FECHACOMPRA: dateti m e +PK_ACT IVO + FK_IDACT () * FECHAACT IVACION: dateti me DEPRECIACION M ESEST RANSCURRIDOS: float 1 * VIDAUT ILBIEN: fl oat «col um n» VIDAUT ILBIENMESES: float *PK IDD: i nt * EST ADO: nvarchar(50) +RESPONSABLE * PORCENT AJE: fl oat +PK_ACT IVO BAJA: nvarchar(10) RESPONSABLE * INCORPORACION: dateti me *FK RESPONSABLE: nvarchar(50) 0.* FK idtcam bio: int * ROL: nvarchar(50) *FK IDT CAM BIO: i nt * FECHA: datetim e * m esnom bre: nvarchar(50) +FK_T IPODEPRECIAR_T CAMBIO * CODA: int «PK» «PK» «PK» + PK_USUARIO(nvarchar) + PK_T IPODEPRECIAR(int) «PK» + PK_PLANT ASDI(i nt) «FK» + PK_T CAM BIO(i nt) «FK» + FK_T IPODEPRECIAR_T CAMBIO(int) + FK_PLANT ASDI_T CAM BIO(i nt) +PK_T IPODEPRECIAR 1 GR «col um n» *PK COD: int CENTROCOSTO * CODG: nvarchar(10) UNIDADNEGOCIO * NOMBRE: nvarchar(500) «col um n» * CODA: nvarchar(10) «colum n» *PK IDC: i nt (T IPOACT IVO = *PK IDU: i nt * NRO: i nt «PK» CODA)(CODA = i d) * NOM BRE: nvarchar(150) +PK_UNIDADNEGOCIO * NOM BRE: nvarchar(250) + PK_GR(int) *FK IDR: i nt PLANT A: nvarchar(50) 1 (IDU = IDU) 0....* CODACT IVOAUX: nvarchar(10) +FK_BAJA NOMBRERES: nvarchar(50) * NOM BRE: nvarchar(500) APELLIDOS: nvarchar(100) * DESCRIPCION: nvarchar(1000) 0..* DESCRIPCION: nvarchar(100) * FECHABAJA: dateti me ACTIVO REGION: nvarchar(100) UNIDADNEGOCIO: nvarchar(100) +FK_ACT IVO_T ACT IVO «colum n» CENT ROCONT ROL: nvarchar(100) *PK CODA: nvarchar(20) CIR: nvarchar(50) 0.* TACTIVO (IDR = IDR) «colum n» +FK_CODGR 0.6 – Modelo .* *FK IDU: i nt +PK_GR 1 «PK» +FK_CENT ROCOST O_UNIDADNEGOCIO + PK_UNIDADNEGOCIO(int) «PK» «FK» + PK_CENT ROCOST O_1(i nt) + FK_UNIDADNEGOCIO_REGIONAL(int) «FK» + FK_CENT ROCOST O_UNIDADNEGOCIO(int) (COD = CODGR)(CODGR = COD) +FK_UNIDADNEGOCIO_REGIONAL 0....* 1 * ANIO: int 1 (idtcam bio = i d) 0. 4.* FECHAASIG: datetim e DEPACUM ACT : float DEPART AM ENT O: nvarchar(80) «FK» * DEPACUM : fl oat PROVINCIA: nvarchar(80) + FK_RESPONSABLE(nvarchar) * VALORRECIDUAL: float LOCALIDAD: nvarchar(100) + FK_UBICACION(i nt) * T IEM POVIDA: float + FK_ACT IVO_T ACT IVO(nvarchar) M ES: nvarchar(50) «PK» ANIO: i nt «PK» + PK_RESPONSABLE(nvarchar) * UFVINICIAL: fl oat + PK_ACT IVO(nvarchar) * UFVFINAL: float *FK IDA: nvarchar(20) «PK» + PK_DEPRECIACION(i nt) «FK» + FK_DEPRECIACION_ACT IVO(nvarchar) Base de Datos Relacional de la Fig.* * CODACT IVO: nvarchar(10) PORCENT AJE: fl oat 1 (CODSG = CODA)(CODA = ID) *FK CODGR: nvarchar(10) «PK» «FK» + PK_REGIONAL(int) + FK_CODA(nvarchar) «FK» +PK_REGIONAL 1 BAJA + FK_CODGR(nvarchar) «PK» + FK_CODSG(nvarchar) + PK_T ACT IVO(nvarchar) (IDR = «col um n» «PK» +PK_T ACT IVO 1 UBICACION)(UBICACION *PK IDB: i nt + PK_SG(int) = IDR) * IDACT : nvarchar(50) * NOMBRE: nvarchar(100) (CODT A = CODA) +FK_UBICACION 0.

1 PRIMER SPRINT Con el objetivo de mejorar de manera continua su productividad y la calidad del producto que se está desarrollando. el equipo analiza cómo ha sido su manera de trabajar durante la iteración. 5.En esta última etapa de las fases Post Game y Transition nos centraremos en las pruebas correspondientes a los casos de uso vistos anteriormente.1 PANTALLA DEL SISTEMA Fig. por qué está consiguiendo o no los objetivos a que se comprometió al inicio de la iteración y por qué el incremento de producto que acaba de demostrar al cliente era lo que él esperaba o no 5. 5. también la implementación de las diversas capturas de pantalla ayudaran en mostrar la evolución que tuvo el presente proyecto desde su comienzo.1 – Pantalla de Identificación 77 .1.

2 PRUEBAS DE CAJA NEGRA 78 . 5.1.2 – Pantalla de Registro de Usuario Fig. Fig.3 – Interfaz de Usuario 5. 5.

Este tipo de prueba permite encontrar errores de las siguientes categorías:  Funciones Incorrectas o ausentes  Errores de Interfaz  Errores de Rendimiento  Errores de Inicialización y/o terminación Es un enfoque que intenta descubrir diferentes tipos de errores. también demuestra la funcionalidad operativa del sistema.  Gestión de Usuario Tabla 5. verificando el funcionamiento correcto de cada uno de los módulos del sistema.1 – Diseño de Prueba Gestión de Usuario Clases de Equivalencia Interfaz de Usuario Entrada Validas No Validas d) Mayor a 10 a) 7 a 10 digitos.com formato ) correcto Cargo z) Letras y dígitos aa) vacio 79 . realizando pruebas de ejecución del programa. digitos Nombre de b) Letras y dígitos e) Menor a 8 digitos Usuario c) requerido f) Vacio Contraseña g) Letras y dígitos h) vacio k) Mayor a 10 digitos l) Menor a 8 Confirmar digitos Contraseña i)Letras y dígitos m) Vacio j)7 a 10 dígitos p) Dígitos n) Letras Nombre q) Vacío o) Requerido r) Símbolos especiales u) Dígitos s) Letras v) Vacio t) Requerido w) Símbolos Apellidos especiales x) Formato de email y) No colocar el Email (juan_fni@ya.

t Ok Email x Ok Cargo z ok Rol bb Ok 1. o Ok Apellidos s.1 5.2 – Caso de Prueba Gestión de Usuario Interfaz de Usuario Entrada Clases de Salida Equivalenci a Nombre de Mensaje f) Usuario: Contraseña: h) Mensaje Nombres n. Rol bb) Seleccionable  Caso de Prueba Tabla 5.1.3 GRAFICO BURN DOWN DEL PRIMER SPRINT 80 .1.

2 SEGUNDO SPRINT 5.Grafico Burn down del primer sprint 5. 200 180 160 140 120 100 80 60 40 20 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 Fig.4 .5.2.1 PANTALLAS DEL SISTEMA DEL SEGUNDO SPRINT 81 .

5.6 – Tipo de Cambio Fig. 5.7 – Pantalla Registrar Nuevo Activo 82 .Fig. 5.5 – Asignar Activo Fig.

5.2.2 PRUEBAS DE CAJA NEGRA 2DO SPRINT

 Registrar Activo

Tabla 5.3 – Casos de Prueba Registrar Activo

Clases de Equivalencia
Interfaz de Usuario Entrada
Valida No Valida

Tipo de a) Seleccionable
Activo

83

Nombre de b) Seleccionable
Grupo

Nombre c) Seleccionable
Sub –
Grupo

Nombre d) Letras y g) Menor
Dígitos a7
e) 7 a 15 caracter
caracteres es
f) Requerido h) Vacío

Descripción i) Letras y l) Vacío
dígitos
j) 200 caracteres
k) Requerido

Años de m) Seleccionable
Vida

Cantidad n) Dígitos q) Mayor
o) 7 a 10 dígitos a 11
p) requerido dígitos
r) vacío

Unidad s) Seleccionable

Costo t) Dígitos Reales v) Vacío
u) Requerido

Tipo de w) Seleccionable
Moneda

Fecha de x) Seleccionable
Compra

Fecha de y) Seleccionable
Activacion

UFV inicial z) Digitos Reales aa) Vacio

Deducible ab) Seleccionable

Caso de Prueba

Tabla 5.4 – Casos de Prueba – Registrar Nuevo Activo

Interfaz de Usuario Entrada Clases de Salida

84

Equivalenci
a

Tipo de Activo: Muebles
a Ok
y Enseres

Nombre de Grupo:
b Ok
Balanza

Nombre Sub – Grupo:
c Ok
balanza de messa

Nombre: Balanza de
d, f Ok
Mesa

Descripción: balanza de
i, k Ok
mesa para miligramos

Años de Vida: 10 m Ok

Cantidad: www o, p Solo digitos

Unidad: EQUIP Ok

Costo: v Error

Tipo de Moneda: Bs. w Ok

Fecha de Compra:
x Ok
06/01/2012

Fecha de Activación:
y Ok
06/01/2014

Solo
UFV inicial: qedq z
números

Deducible: Si bb Ok

5.2.3 GRAFICO BURN DOWN DEL SEGUNDO SPRINT

85

Grafico Burn down del primer sprint 5.8 .11 – Pantalla Dar Baja de Activo 5. 180 160 140 120 100 80 60 40 20 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 Fig. 5.3.5 – Casos de Prueba – Registrar Regional Interfaz de Usuario Entrada Clases de Equivalencia 86 .5.10 – Pantalla Restaurar Activo Fig.9 – Pantalla Depreciar Activo Fig. 5. 5.1 PANTALLAS DEL SISTEMA Fig.3.3 TERCER SPRINT 5.2 PRUEBAS DE CAJA NEGRA 3ER SPRINT Tabla 5.

6 – Casos de Prueba – Registrar Centro de Costo Interfaz de Usuario Entrada Clases de Equivalencia Validas No Valida Regional a) Seleccionable b) Vacío Unidad de c) Seleccionable d) Vacío Negocio 87 . Validas No Valida Numero a) Dígitos d) vacio b) 3 a 5 digitos c) Requerido Regional e) letras h) vacio f) 10 digitos g) Requerido Tabla 5.

3 GRAFICO BURN DOWN DEL TERCER SPRINT 88 .7 – Casos de Prueba Registrar Centro de Costo Interfaz de Ususario Entrada Clases de Salida Equivalencia Regional: ORURO A Ok Unidad de Negocio: Ok PLANTA ORURO C Numero: qwerw G Solo números Planta: 134523 Solo letras I Nombre: 12412 Solo letras L 5.3. Numero e) Dígitos h) Vacío f) 3 a 5 dígitos g) Requerido Planta i) Letras k) Vacío j) Requerido Nombre l) 10 a 15 letras n) Vacío m) Requerido Tabla 5.

y podemos detallar lo siguiente:  La implementación del sistema mejora el desempeño de los funcionarios que están encargados o que usaran la aplicación. reduce la carga de trabajo a los mismos y ofrece la confiabilidad en el manejo de la información correspondiente a procesos de gestión de Activos Fijos. detallados en el Product Backlog que formo parte de la fase de inicio. El sistema de Gestión de los Activos Fijos para la empresa MAXAM – FANEXA S. esta verificación se logró gracias a los datos antiguos que contaba en la planilla de Excel que evidentemente logro corroborar los datos son precisos y que además esta aplicación también logro evidenciar en dicha planilla hay errores que arrojaron otros valores a los calculados y por verificación de la 89 .12 – Grafico Burn Down del Tercer Sprint CONCLUSIONES. se logró verificar si los datos calculados estaban en el margen permitido por contabilidad general. cumpliendo con todos los requisitos exigidos por la empresa.M.. 300 250 200 150 100 50 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 Fig.A. 5. llego a su conclusión de una manera satisfactoria. cumpliendo su objetivo principal.  Al finalizar el desarrollo de la aplicación.

este podría ser utilizado vía web. asi permitiendo la optimización de uso.  Se recomienda ampliar el estudio con la adición de un subsistema de contabilidad.M.A.  MAXAM – FANEXA S. la institución debe mantener actualizada la base de datos con la información necesaria.  La presente aplicación como fue desarrollado para la empresa MAXAM – FANEXA S. auditora se comprobó el error es de la planilla y no de la aplicación. la rigurosidad con que el equipo de trabajo sometió a la aplicación supero las expectativas previstas. se recomienda al departamento de sistemas encargado de esta trabajo mantener la estructura empleada en la implementación del mismo.M.A. RECOMENDACIONES. también para cuidar la seguridad de acceso al sistema manteniendo en secreto el nombre de usuario y contraseña asignado a cada usuario. debe tomarse consideraciones de seguridad. esta estrictamente diseñada y construida de acuerdo a los requerimientos que el equipo conformado para el desarrollo solicito.  Si bien el sistema fue desarrollado para su utilización en la red interna de la institución.  En caso de realizar actualizaciones o modificaciones al sistema. 90 .  Para el adecuado funcionamiento del sistema. debe establecer políticas para la obtención de copias de seguridad de la base de datos del sistema.

2001. http://www.J. [PJ. sexta edición. cuarta edición.net 91 . [SA. 2006] Roger S Pressman. Claudia Ruata. 2011] Juan Palacion. séptima edición. séptima edición. Carlos Fernandez Collado. RC. Korth. 2001] C. McGraw – Hill. 2005. Pretince Hall. Fundamentos de Bases de Datos. Scrum Manager Gestion de Proyectos.FCC. 2006] Roberto Hernadez Sampieri. 2005] Ian Sommerville. cuarta edición. 2006. edicion enero de 2011. BIBLIOGRAFIA [PRS.scrummanager. Introduccion a los Sistemas de Bases de Datos. [HSR. Date. SafeCreative. Pearson Educacion. Ingenieria del Software. McGraw – Hill. Henry F. KHF. Ingenieria del Software. 2002. McGraw – Hill. Metodología de la Investigacion. [SI. [DCJ. 2002] Abraham Silberschatz .

[JR.[PJ.agilealliance. I. Agile Spain: www. Analisis y Diseño de Sistemas 1. El Proceso Unificado de Desarrollo. “Diseño y Construccion de Aplicaciones Agiles con el Metodo Scrum”.org 92 .net [KH. “Ingenieria de Software” 5º Edicion. 2007] Asociacion de Investigacion en Software Inteligente. España: PEARSON Addison Wesley. http://www. 2005. [AISI. [Pressman. 2007] Henrik Kniberg. 2011] Manuel Trigas Gallego. 2007] Juan Palacion. Madrid. edición y revisión agosto 2013. Scrum y XP desde las Trincheras.com y http://www. 2007] Rumbaugh.com Portal de la Alianza ágil: www. edición octubre de 2007. [GTP.. Microdoft. Pressman.scrumalliance. 2007. & Booch. InfoQ.agile-spain. Fuentes de refencia: Comunidad. Mayo de 2007. [USCG. (2007). Jacobson. 2005] Jose Manuel Alarcon Aguin.agilemanifesto. [MTG.navegapolis. version online. 2005. 2013] Juan Palacios “Gestion Tecnica de Proyectos con Scrum”. G. 2007. 2005] Universidad de San Carlos de Guatemala. Flexibilidad con Scrum. 2006] Roger S. Gestion de Proyectos Informaticos [AAJM.org/ Contenido del Manifiesto ágil: www. Editorial McGraw – Hill. 2011.org Portal de la Alianza de Scrum: http://www.. SafeCreative. Manual de Introduccion a Visual Web Developer 2005. primera edición. IJ. primera edición.lulu. J.

Estimar del Esfuerzo (persona – mes). Estimar el plan (meses). Una vez que se ha estimado el tamaño y el esfuerzo. pero una estimación efectiva necesita estimar primero el tamaño del software para poder construirlo. Este paso es sin duda el más difícil intelectualmente. estimar la duración del plan resulta casi trivial. Este proceso de estimación se realiza a partir del diagrama de casos de Usos del Tercer Sprint ya que ahí están bien definidos los casos de uso de la aplicación. Se tiene una estimación exacta del tamaño y los datos previos de la organización en proyectos similares. 93 .A1 PROCESO DE ESTIMACION. es fácil realizar la estimación del esfuerzo. Algunos proyectos saltan directamente a estimar el plan. El proceso para crear una planificación de desarrollo exacta consta de tres pasos: Estimar el tamaño del Producto (Número de Líneas de Código fuente o puntos de función).

no se lo realizara porque como es una metodología que no se basa en la documentación. un metadato. Es usado para obtener una idea del número de horas-hombre para un proyecto. El método utiliza los actores y casos de uso relevados para calcular el esfuerzo que significara desarrollarlos. Ha sido analizado posteriormente en otros estudios. Puntos de Caso sin Ajustar UUCP=UAW+UUCW a) Factor de Peso de los Actores (UAW) 94 . A3 CACULAR LOS PUNTOS CASOS DE USO NO AJUSTADOS Pesar los actores es considerar la complejidad de los actores determinando si cada actor es una persona u otro sistema y la forma en que interactúa con el sistema a desarrollar.Para lo cual dentro estos tres métodos que podría englobarse dentro un paso más general. como la tesis de Kirsten Ribu (Universidad de Oslo) en 2001. Tabla A1 – Calculo de Puntos de Caso de Uso No Ajustado Tipo de Descripción Factor Actor Simple Otro sistema con una API (Aplication Programming 1 Interface)definida Promedio Otro sistema interactuando a través de un protocolo TCP/IP o una 2 persona interactuando a través de una interfaz en modo texto. mientras que a los actores se les asigna una complejidad basada en su tipo. es decir si son interfaces con usuarios u otros sistemas. entendidas como una interacción ente el usuario y el sistema. fue supervisado por Ivar Jacobson. También se utilizan factores de entorno y de complejidad técnica para ajustar el resultado. basándose en el método de Punto función. Fue desarrollado por Gustav Karner en 1993. A los casos de uso se les asigna una complejidad basada en transacciones. solo se realizara la estimación del Esfuerzo mediante el Estimador de Punto de Caso de Uso. Complejo Una persona interactuando a través de una interface gráfica de 3 usuario. A2 ESTIMADOR DE PUNTO CASO DE USO. Es un método de estimación de esfuerzo para proyectos de software. a partir de sus casos de uso.

Tabla A2 – Factor de Peso de los Actores UAW ACTOR TIPO FACTOR Administrador Promedio 2 Encargado Promedio 2 Contador Promedio 2 Invitado Promedio 2 Σ 8 UAW= Σ(FACTOR) UAW= 8 12 b) Factor Peso de los Casos de Uso sin Ajustar (UUCW) Tabla A3 – factor de Peso de los Casos de Uso UUCW CASO DE USO TIPO FACTOR CLASES DE ANALISIS Acceso al Sistema Simple 5 2 Gestion Usuario Simple 5 2 Gestion Unidad de Negocio Promedio 10 4 Registrar Unidad de Negocio Simple 5 2 Registrar Centro de Costo Simple 5 2 Regitrar Regional Simple 5 2 Asignar y Traspasar Activo Promedio 10 4 Gestion Responsable Simple 5 2 Gestion Activo Promedio 10 4 Gestion Tipo de Activo Simple 5 4 Depreciacion Simple 5 2 Registrar Tipo de Cambio Simple 5 2 95 .

5 5 2. Restablecer Activo Complejo 10 4 Dar baja Activo Complejo 10 8 Búsquedas Promedio 10 4 Reportes Promedio 10 4 Σ 115 UUCW= Σ (FACTOR) UUCW=125 Entoncecs : UUCP=UAW¨+UUCW UUCP= 8+115 UUCP= 123 PUNTOS CASOS DE USO AJUSTADOS (UCP) UCP=UUCP*TCF*EF a) Factores de Complejidad Tecnica TCF Tabla A4 – Factor de Complejidad Tecnica TCF Facto Descripción Peso Valor Factor r Calculad o T1 Sistema distribuido 2 0 0 T2 Objetivos de performance o tiempo de respuesta 1 5 5 T3 Eficiencia del usuario final 1 5 5 T4 Procesamiento interno complejo 1 3 3 T5 El código debe ser reutilizable 1 2 2 T6 Facilidad de instalación 0.5 5 2.5 T8 Portabilidad 2 1 2 T9 Facilidad de cambio 1 5 5 T10 Concurrencia 1 4 4 T11 Incluye objetivos especiales de seguridad 1 5 5 T12 Provee acceso directo a terceras partes 1 3 3 T13 Se requiere facilidades especiales de 1 0 0 entrenamiento de usuarios Factor Total Tecnico Σ 39 96 .5 T7 Factibilidad de uso 0.

03*17) EF=0.6+(0.TFACTOR= ΣValor*Peso TFACTOR= 39 TCF= 0.5 E5 Experiencia en orientación a objetos 1 4 4 E6 Motivación 1 3 3 E7 Dificultad del lenguaje de programación -1 2 -2 E8 Estabilidad de los requerimientos 2 3 6 Factor Ambiental Total Σ 17 EFACTOR= Σ Valor*Peso EFACTOR= 17 EF= 1.01*39) TCF=0.4+(-0.5 4 2 E4 Experiencia en la aplicación 0.89 Entonces: UCP=UUCP*TCF*EF UCP= 123*0.5 E2 Personal tiempo parcial -1 2 -2 E3 Capacidad del analista líder 0.03*EFACTOR) EF= 1.6+(0.5 3 4.5 3 1.99*0.99 b) Factores Ambientales (EF) Tabla A5 – Factores Ambientales EF Factor Descripción del Factor Peso Valor Factor Calculado E1 Familiaridad con el modelo utilizado 1.89 97 .4+(-0.01*TFACTOR) TCF= 0.

Sin embargo tomando en cuenta que el equipo esta conformado por 2 personas se tiene lo siguiente: 6. UCP= 108.32 2 0 [ dias ] E= 6.50 [ mes−persona ] T= 2 [ persona ] meses T ≅ 3.36*12[horas – persona] E=1300 [horas – persona] Asumiendo que se trabaja al dia 10 horas y 20 dias al mes tiene: [ horas – persona ]∗1 [ dia ] ∗1 [ mes ] 10 [ horas ] E=1300.50 [mes – persona] Lo que significa que se requiere alrededor de 6 meses para que una persona desarrolle esta aplicación.25¿ ] 98 .36 A4 ESFUERZO (E) El esfuerzo en horas – persona viene dado por la siguiente formula: E= UCP*CF[horas – persona] Se estima que cada caso de uso requiere 12 horas de trabajo para ser desarrollado CF=12[horas – persona] Entonces E=108.

las cuales proporcionan una referencia de la calidad de algún producto software.01∗∑ Fi ] Cuentatotal :Suma de todas las entradas 0. 0. y como no puede ser medida directamente. Para valorar la calidad de los productos software o los sistemas que se desarrolla. Entre las varias técnicas para medir la calidad de software se encuentra el estándar ISO 9126. siendo una métrica que identifica los siguientes atributos clave de calidad para el software  Funcionalidad  Confiabilidad  Facilidad de mantenimiento  Usabilidad  Portabilidad A5. se proporciona la información adecuada sobre los datos necesarios referentes a la calidad del producto.65+ 0.01: factor de conversión con un error de 1% 99 . permitiendo una visión profunda sobre el cumplimiento de los objetivos del proyecto. debe ser medido indirectamente de otras medidas directas como ser el punto función propuesto por Albretch que asocia a estos dominios un valor de complejidad en función a la siguiente relación: PF=Cuenta total∗[0. A5 CALIDAD DEL SOFTWARE: A diferencia de otras disciplinas.Por lo tanto el equipo necesita alrededor de 3 meses para desarrollar el producto para MAXAM – FANEXA.1 FUNCIONALIDAD Se trata de identificar la capacidad que el producto software tiene para proporcionar funcionalidades que satisfagan las necesidades especificadas.65: valor de ajuste de complejidad mínimo. en su lugar se hace uso de un conjunto de medidas indirectas conocidas como métricas. la ingeniería de software no está basada en leyes cuantitativas básicas.

14).  Interfaces Externas: Interfaces legibles por el ordenador.  Archivos: Representa a cada archivo parte de la base de datos o a un archivo independiente.  Consultas de Usuario: Representa a cada combinación única existente de entrada – salida. valorándolo mediante una medida de funcionalidad denominada punto función.Una vez que cuantificamos el tamaño y la complejidad del sistema en términos de las funciones de usuario. Tabla A7 .  Salidas de Usuario: Representa cada salida de información referente a la aplicación (informes. que son utilizados para transmitir la información a otro sistema. donde una entrada genera una salida. pantallas. La siguiente tabla muestra las cinco características con factor de ponderación medio para el cálculo del punto función. Tabla A& – Calculo de Punto Funcion Factor de Ponderación Total Parametro de Medida Cuenta Simple Medio Complejo Nº de Entradas de Usuario 73 3 4 6 219 Nº de Salidas de Usuario 137 4 5 7 548 Nº de Consultas de Usuario 73 3 4 6 219 Nº de Archivos 30 7 10 15 210 Nº de Interfaces Externas 2 5 7 10 10 CUENTA TOTAL 1206. se determinara las cinco características de dominio de información:  Entradas de Usuario: Representamos las entradas de control del usuario que proporciona diferentes datos a la aplicación.60 La tabla muestra los valores de ajuste de complejidad de Fi (i=1. calculados en función a la importancia de las características ambientales del sistema y necesarios para el cálculo del punto función.…. mensajes de error).Características Ambientales i Características del Sistema Valor 1 ¿Se ha diseñado el sistema para soportar múltiples instalaciones en 4 diferentes organizaciones? 2 ¿Se ha diseñado el código para ser reutilizable? 4 3 ¿Existen funciones de procesamiento distribuido? 0 4 ¿Se ejecutara el sistema en un entorno operativo existente o fuertemente 4 utilizado? 5 ¿Requiere el sistema entrada de datos interactivos? 3 100 .

que las transacciones de 3 entrada de datos se lleven a cabo sobre múltiples pantallas y operaciones? 7 ¿Es crítico el mantenimiento? 2 8 ¿Se utilizan los archivos maestros de forma interactivos? 3 9 ¿Son complejos las entradas.01∗70] PF MAX=1628.65+0. A5.65+ 0. tiene una capacidad para proporcionar funcionalidades que satisfagan las necesidades específicas.91 La funcionalidad real es: FUNCIONALIDAD=( PF/ PF MAX )∗100 FUNCIONALIDAD=(1206.60/1628.01∗∑ Fi ] PF=1206. salidas.60∗[0.M.65+ 0.91)∗100 = 85. 6 ¿Se requiere que la entrada de datos interactivo.19% Por lo tanto la funcionalidad de la aplicación para MAXAM – FANEXA S.60 Hallamos el punto de función máximo para comparar los valores de funcionalidad del sistema: PF MAX=1206.01∗50] PF=1206.2 CONFIABILIDAD 101 .A.60∗[0. archivos o las peticiones? 5 10 ¿Es complejo el procesamiento interno? 4 11 ¿Se requiere comunicación de datos? 4 12 ¿Están incluidas en el diseño la conversación y la instalación? 4 13 ¿Requiere el sistema copias de seguridad? 5 14 ¿Se han diseñado las aplicaciones para facilitar los cambios y para ser 5 fácilmente utilizada por el usuario? FACTOR DE AJUSTE DE COMPLEJIDAD ( ∑ Fi ) 50 Calculamos el Punto Funcion: PF=Cuenta total∗[0.

Es la probabilidad de operación libre de fallos de un programa en un entorno determinado y durante un tiempo específico. Estadísticamente es la probabilidad de operación libre de fallos de un programa de computadora en un entorno determinado y un tiempo específico. O podríamos decir que es lo que se puede esperar de un programa lleve a cabo su función con exactitud requerida. Para el cálculo de la confiabilidad del sistema se utiliza la siguiente ecuación: P (T ≥t )=1−F (t ) Donde: F ( t ) : Probabilidad de ejecucion con fallas t :representa el periodo de tiempoen que se pone a prueba el sistema 1−F ( t ) : Probabilidad de ejcucion sin fallas Para hallar la probabilidad de falla del sistema F(t) en el periodo t . se utiliza la función exponencial dada por: F ( t )=f∗e λt En donde f : Funcionalidad del sistema λ : probabilidad de fallo en un periodo de tiempo t :tiempo total en el que se hace el calculo de fallo 102 .

18 P (T >t )=0. en una función exponencial cuya relación es la siguiente: Probabilidad de hallar una falla: P (T ≤t )=F (t) Probabilidad de no hallar una falla: P (T >t )=1−F (t) λ ( ∗12) Con F ( t )=Fc∗( e 7 ) Donde : Fc=0. hallamos la probabilidad de falla con una variable aleatoria continua T.82 103 .Observamos el trabajo hasta que se produzca un fallo en el instante t.18 La probabilidad de hallar una falla es de un 18% en los próximos 12 meses.85∗(e ) F ( t )=0.85: Funcionalidad del Sistema λ=1:Tasa de fallas en 7 ejecuciones dentro de un mes Se realiza el calculo para la confiabilidad durante los próximos 12 meses: F ( t )=F ∗( e 7 ( −λ )∗12) c (−17 )∗12 F ( t )=0. P (T >t )=1−F ( t ) P (T >t )=1−0.

Donde la probabilidad de no hallar falla durante los siguientes 12 meses es del 82%. el producto se empieza a estabilizar.4 PORTABILIDAD Es el esfuerzo necesario para transferir el programa de un entorno de sistema hardware y/o software a otro. facilidad de cambio establecido y facilidad de prueba. A5.3 MANTENIBILIDAD La facilidad de realizar una modificación. para lo cual se afirma que es una probabilidad aceptable y confiable para la utilización de la aplicación. basada en el cambio que ocurre en cada versión del producto. Este Factor de calidad viene dado según el estándar IEEE 982 1998 y por la métrica del índice de madurez del software (IMS) que proporciona una indicación de la estabilidad del producto software. indicada por los siguientes sub atributos: facilidad de análisis. A5. Calculamos el índice de madurez de software con la siguiente relación: IMS=[ M t −( F c + F a+ F d ) ] / M t Donde: M t :número de modulos en laversion actual Fc :números de modulos en la version actual que se han cambiado Fa :números de modulos enla version actual que se han añadido Fd : números de modulos en la version anterior que se han eliminado en la version actual A medida que el IMS se aproxima a 1. El grado de portabilidad del sistema está dado por la siguiente ecuación: 104 .

5 USABILIDAD Es el esfuerzo necesario para aprender a utilizar la aplicación. donde el volumen de la aplicación no sobrepasa los 10 Mb y se puede subir o colgar en servidores Windows o Linux. por lo que el producto es fácilmente portable y gracias a crystal reports se puede migrar fácilmente a Excel. 105 . Como la aplicación cuenta con un interfaz amigable e intuitiva hace fácil su utilización. Costo de Transportar GP=1−( ) Costo de Redesar rollar Donde: GP :Grado de Portabilidad GP> 0. Pdf.  Disco Duro 10 GB.8 GHz) o superior. Portabilidad Perfecta GP<1.  RAM: 512 MB.  Monitor: SVGA  Teclado  Mouse A5. Rede sarrollar el sistema es mas rentable que transportalo La portabilidad de la aplicación se presenta en los siguientes niveles: a) Nivel Software: La aplicación puede distribuirse en cualquier medio de almacenamiento. Se realizaron encuestas a todos lo que posiblemente sean los usuarios finales sobre el manejo de la aplicación para medir la usabilidad (ver tabla A8). ya sea según su interfaz o manual de usuario y se lo calcula en función al porcentaje de una encuesta realizada a cierto número de usuarios finales. Word. SQL. b) Nivel Hardware: La aplicación es portable cuando se cumpla los siguientes requerimientos mínimos de hardware:  CPU Pentium IV (2. Portabilidad del sistema es mas rentable que el redesarrollo GP=1.

sobre el manejo del sistema para medir la usabilidad (ver tabla A8) Tabla A8 – Encuesta de Usabilidad de la Aplicación Respuestas Pregunta Si No Porcentaje ¿Son complicadas las respuestas de la 0 5 100 % aplicación? ¿Es difícil aprender a manejar la aplicación? 1 4 80 % ¿Los resultados que le proporcionan la 5 0 100 % aplicación le facilitan su trabajo? ¿Son complicadas las funciones del sistema? 3 2 60 % ¿Son satisfactorias las respuestas de la 5 0 100 % aplicación? ¿La aplicación tiene interfaces dinámicas y 4 1 80 % agradables a la vista? ¿Entiende y contrala las peticiones que el 4 1 80 % sistema solicita? ¿Utiliza la aplicación con facilidad? 5 0 80 % Promedio 85 % Por lo tanto se concluye que la aplicación tiene un grado de usabilidad de 85 % 106 . Se realizaron encuestas a 5 usuarios finales.