UNIVERSIDAD TECNICA DE ORUROFACULTAD NACIONAL DE
INGENIERIACARRERA DE INGENIERIA DE SISTEMAS
PROYECTO DE GRADO
SISTEMA DE GESTION DE ACTIVOS FIJOS PARA MAXAM FANEXA S.A.M.
PARA OPTAR AL TITULO DE LICENCIATURA EN INGENIERIA DE
SISTEMAS
POSTULANTE: JAIR SAMUEL VENTURA TOVAR
ORURO BOLIVIA2014
AGRADECIMIENTOS
Gracias a Dios por este logro acadmico, aun a pesar de que mi
memoria me presentara como un ser injusto pues tal vez,
involuntariamente se me escapen algunas personas quienes debera
nombrar, pero quiero agradecer a todos que me ayudaron a seguir en
este camino y no me abandonaron y ms por el contrario siempre me
empujaron para continuar.A mi padres y hermanos quienes me apoyaron
incondicionalmente y apoyndome continuamente.A Kanito y
archell_pollito quienes por la experiencia acumulada apoyaron
bastante en la revisin y bsqueda de errores que mejoren en el
rendimiento del presente proyecto.A mis docentes quienes a lo largo
de muchos aos, con sus inquietudes y sus dudas me han enseado ms de
lo que podran haberme enseado.A mi querida carrera que me acogi
dentro sus aulas como un segundo hogar lleno de alegras y
experiencias que estarn siempre en mi recuerdo.
DEDICATORIAA Dios por nunca abandonarme y estar siempre
conmigo.A mis padres y hermanos por el apoyo incondicional.A mis
pequeas: Viviam y Mariam que son la razn de mi existencia.A la FNI
por ser mi templo de formacin.
RESUMEN
El proyecto Sistema de Gestin de Activos Fijos, fue desarrollado
para el rea de Activos Fijos de MAXAM FANEXA S.A.M., institucin
dedicada a la fabricacin y comercializacin de explosivos, que a la
vez al ser una empresa consolidada a nivel nacional maneja una gran
cantidad de bienes denominados activos.MAXAM FANEXA realiza la
mayora de los procesos de gestin de activos fijos de manera manual,
usando como respaldo la utilizacin de planillas echas en Excel, que
con el ingreso de nuevos activos se vuelve ms pesado el acceso a
ello, razn por la cual se decidi optar la construccin de una
aplicacin web que aproveche la INTRANET que cuenta la empresa y
adems se pretende obtener informacin rpida y consistente, a fin de
maximizar la eficiencia en la administracin de la informacin de los
activos fijos que cuenta la empresa. La metodologa adoptada para el
desarrollo del software es SCRUM apoyada por AUP, para el
modelamiento del sistema y que a su vez este modelamiento se lo
realizo en UML (Lenguaje de Modelado Unificado), que ayuda a
efectuar la representacin de los modelos por medio de artefactos,
en las distintas etapas que contempla estas metodologas.Las
herramientas utilizadas para la implementacin son: el lenguaje de
programacin C# y Asp.net y el gestor de base de datos SQL SERVER
EXPRESS.Los mdulos principales de la aplicacin son: Registro,
Asignacin, Transferencia, Baja, Bsquedas, Traspasos y
Reportes.Concluido el desarrollo del software se realizaron pruebas
de funcionamiento, con las que se pudo constatar que el sistema
responde a los requerimientos institucionales, posibilitando la
reduccin de tiempo y costos en la administracin de activos fijos,
adems de la obtencin de datos confiables.
INDICE
44
SISTEMA DE GESTION DE LOS ACTIVOS FIJOSEN MAXAM FANEXA
S.A.M.
1.1 INTRODUCCION.Las instituciones pblicas o privadas, para
llevar a cabo sus actividades requieren de la utilizacin de ciertos
bienes denominados activos. Estos bienes tangibles que se utilizan
para el desarrollo de sus actividades administrativas y cumplen una
funcin se les denomina Activos Fijos. Cabe resaltar que entre las
principales caractersticas de estos activos son la permanencia en
la empresa, generando utilidades hasta que dichos bienes dejen de
ser tiles por el paso del tiempo y debido principalmente a la
depreciacin (prdida del valor monetario que sufre el bien al
transcurrir el tiempo), o bien hasta que la empresa decida darlos
de baja.MAXAM FANEXA S.A.M. es una compaa lder en la fabricacin,
comercializacin y distribucin de productos, sistemas de iniciacin y
servicios de voladura para las industrias mineras, de la
construccin y exploracin petrolera; nace el ao 1999 de la unin de
dos empresas lderes en la fabricacin de explosivos, la primera La
Unin Espaola de Explosivos (UEE) de una larga tradicin actualmente
bajo el nombre de MAXAM consolidada como una empresa lder a nivel
mundial; y la segunda Fbrica Nacional de Explosivos (FANEXA)
fundada en el ao 1977 como parte de La Corporacin de las Fuerzas
Armadas para el Desarrollo Nacional (COFADENA), ambas empresas han
conjugado experiencia nacional e internacional, ltimas tecnologas,
nuevas formas de gestin modernas y eficaces. Aportando al progreso
del pas; componentes que han aportado a cubrir gran porcentaje del
mercado nacional de productos reconocidos todos por su alta
seguridad y calidad.MAXAM FANEXA S.A.M. cuenta con una gran
cantidad de activos que necesita ser almacenada, en una aplicacin,
razn por la cual se propuso la aplicacin del tipo modelo, vista
controlador para el almacenamiento de todos sus activos con sus
respectivos requerimientos que se hizo para la elaboracin de este
proyecto (depreciaciones, revalorizaciones, dar baja, traspaso,
etc.), aprovechando la intranet que cuenta la empresa. 1.2
ANTECEDENTES.1.2.1 DESCRIPCIN DE LA EMPRESAConstitucin de la
SociedadMediante D.S. N 10511 de septiembre de 1972, el gobierno de
Bolivia concede al Ministerio de Defensa Nacional la exclusividad
de la fabricacin de explosivos y accesorios en el pas y con el D.S.
N 15348 de 10 de Marzo de 1978, se autoriza a COFADENA, suscribir
contratos de provisin de maquinaria y equipos, tecnologas y
asistencia tcnica con las empresas japonesas ASAHI CHEMICAL
INDUSTRY CO. LTDA., NISSHO IWAI CO. LTDA., para la instalacin de
una planta industrial de fabricacin de explosivos y accesorios en
Bolivia, constituyendo as una sociedad annima con la Corporacin
Minera de Bolivia (COMIBOL) y las empresas indicadas.Con escritura
pblica N 430 de 26 de abril de 1978, se constituye la sociedad
annima mixta bajo la razn social de Fbrica Nacional de Explosivos y
Accesorios S.A.M. (FANEXA S.A.M.) con la aprobacin de sus
estatutos, siendo su composicin accionaria: COFADENA 50%, COMIBOL
40%, ASAHI CHEMICAL INDUSTRY CO. LTDA. 7.5% y NISSHO IWAI CO. LTDA.
2.5%. El grupo UEE el 23 de septiembre de 2006 cambia de razn
social como reflejo de los cambios de polticas corporativas y
crecimiento de la empresa por el de MAXAM, con experiencia en ms de
cuarenta pases, lder en el desarrollo y comercializacin de
explosivos civiles y sistemas de iniciacin para minera, canteras e
infraestructura; productos para las industrias de defensa, adems de
materias primas claves para sus necesidades internas y de
terceros.COFADENA con ms de veintiocho aos de experiencia y
decidida vocacin de servicios al progreso de Bolivia, coopera en el
desarrollo de todas las industrias fundamentales como la minera,
qumica, agrcola y ganadera. Como parte integrante de las FF.AA.
garantiza la sostenibilidad de los proyectos en los que se
involucra, adems de contar con el apoyo decidido del estado en
todos los proyectos en los que participa, garantizando la inversin
pblica y privada.
Desde su creacin como Sociedad Annima Mixta en julio de 1999 la
compaa ha progresado hasta convertirse en lder nacional de su
rubro, llegando a exportar ms del 25% de sus ventas a pases como
EE.UU., Chile, Ecuador, Per y otros, habindose implementado en los
ltimos 5 aos lneas de produccin en productos que hoy cubren los
mercados nacionales y extranjeros con la mayor calidad y seguridad.
La calidad de los procesos de diseo, produccin, comercializacin y
distribucin est certificada hace ms de tres aos bajo Norma
Internacional ISO 9001:2000 constituyndose en referente nacional en
temas de Seguridad, Prevencin de Riesgos y Medio Ambiente.MAXAM
FANEXA S.A.M. cuenta con dos plantas de produccin una en Cochabamba
y otra en Oruro, ambas con maquinaria y tecnologas de fabricacin de
punta, sustentadas por toda la gran experiencia y calidad de MAXAM
con sede en Espaa.Trabajos que se tom en cuenta tienen relacin al
proyecto propuesto: Sistema de Control y Depreciacin de Activos
Fijos: Zona Franca Oruro S.A., desarrollado por Evert Fernando
Cortez Hino [2012], Facultad Nacional de Ingeniera FNI, cuyo
objetivo es el control de depreciacin de sus activos fijos en la
zona franca de Oruro, para un manejo ms adecuado y eficiente.
Sistema Automatizado de Control de Inventarios y Actividades
Comerciales, desarrollado por Leslie Elsa Montenegro [2010],
Facultad Nacional de Ingeniera FNI. Cuyo objetivo principal es la
organizacin mediante inventarios los activos que cuenta la
institucin para cual desarrolla esta actividad. Sistema de
Informacin y control de Activos Fijos Ministerio de Gobierno,
desarrollado por James Williams Gutirrez Flores [2005], Facultad de
Ciencias Puras y Naturales UMSS. cuyo objetivo principal del
proyecto es desarrollar e implementar un Sistema de Informacin
automatizado para la administracin, seguimiento y control de
Activos Fijos del Ministerio de Gobierno, que permite tener
informacin actualizada y centralizada. Enfatizando en la migracin
de la informacin de la base de datos del antiguo sistema,
estandarizando formatos de actas e informes. Control y Seguimiento
de Activos Fijos del Servicio Exterior va web Ministerio de
Relaciones exteriores y Cultos, desarrollado por Mario Cancillo
Zanga [2006], Facultad de Ciencias y Tecnologa UMSS, herramienta de
software de apoyo en la administracin, seguimiento y control de
activos fijos. Coadyuvando en forma eficiente y transparente la
elaboracin y obtencin de informacin organizada, confiable y
oportuna. Sistema de Gestin y Seguimiento de Activos Fijos para el
servicio departamental de Gestin Social, desarrollado por Juan
Carlos Quispe Limachi [2008], Facultad de Ciencias y Tecnologa
UMSS, software que pretende obtener informacin rpida, a fin de
maximizar la eficiencia en la administracin de la informacin de los
activos.1.3 CARACTERIZACION DEL PROBLEMA Y SITUACION
PROBLEMATICA.La empresa MAXAM FANEXA S.A.M. dentro lo que se
refiere al manejo de sus activos se identific los siguientes
problemas: No tiene buena organizacin ni clasificacin de sus
activos, razn por la cual no se da la informacin necesaria del
activo. La codificacin que cuenta es demasiada antigua, ocasionando
que a veces no se encuentre dicho activo en un lugar determinado y
no coincida en la verificacin. No se tiene registro sobre quin es
responsable de un activo, ni la ubicacin del activo de manera
exacta, que permita en el caso de prdida dar con el responsable la
ubicacin y a donde pertenece ese activo. No se tiene clculo exacto
de las depreciaciones, evidenciando errores en el redondeo,
ocasionando que el contador haga nuevamente reajustes de precios y
gastos cada cierre de mes. Crecimiento masivo de la planilla hecha
en Excel, causa problemas como errores de ingreso o copia de
frmulas al ingreso de nuevos activos, y en el uso del equipo en su
rendimiento que hace que se vuelva ms lento a medida que va
creciendo la mencionada planilla. Demora en la disponibilidad de
informacin sobre depreciaciones para el cierre de balance de mes,
ocasiona que el cierre de mes de alargue hasta altas horas de la
noche y a veces se pida plazo a impuestos nacionales en la entrega
de informes. No se cuenta con historial sobre traspaso y asignacin
de los activos, ocasiona la perdida de algunos activos y no
cumplimiento del tiempo de vida previsto de sus activos fijos.1.3.1
PLANTEAMIENTO DEL PROBLEMA.Cmo se puede mejorar el movimiento de
sus activos fijos, en forma confiable, que permita obtener
informacin consistente, para un adecuado control y seguimiento de
sus activos en MAXAM FANEXA S.A.M.?1.4 OBJETO DE ESTUDIO.Se
constituye el proceso administrativo de seguimiento y control de
activos en la empresa MAXAM FANEXA S.A.M.1.5 CAMPO DE ACCION.El
presente proyecto se desarroll en el rea de la ingeniera de
Sistemas, ms propiamente en el desarrollo de Sistemas de Informacin
Administrativa. Especficamente se desarroll en la empresa MAXAM
FANEXA S.A.M. para el rea de Activos Fijos dependiente de Gerencia
Financiera. 1.6 OBJETIVOS.1.6.1 OBJETIVO GENERAL.Desarrollar e
implantar un Sistema de Gestin y Seguimiento de activos Fijos, que
permita obtener informacin confiable en el control y seguimiento de
sus activos en MAXAM FANEXA S.A.M.1.6.2 OBJETIVOS ESPECIFICOS.
Establecer los requerimientos de manejo de informacin en el rea de
activos fijos, con los que iniciara el desarrollo de la aplicacin.
Desarrollar mdulos que contemplen: privilegios, operaciones y
registros de los activos, para una distribucin y organizacin
adecuada contemplando las normas futuras que la empresa tiene
planificado implantarlas. Desarrollar una base de datos que permita
almacenar todos los datos que genere el movimiento de los activos,
de forma que se logre almacenar informacin verdica y oportuna.
Disear y desarrollar la interfaz que facilite el uso del sistema
utilizando la tecnologa .NET, de tal manera que sea lo ms amigable
posible para el usuario. 1.7 CRITERIO DE VERIFICACION:Se realizara
pruebas de los diferentes servicios de la aplicacin web
implementada en la intranet de la empresa, en una muestra de casos
reales con resultados conocidos, contrastando con los resultados
obtenidos, debindose obtener resultados exactos y en menor tiempo,
y para cumplir este propsito se utilizara el estadstico de
Fisher.1.8 JUSTIFICACIONES.1.8.1 JUSTIFICACION TECNICA.El proyecto
se justifica tcnicamente puesto que el anlisis, diseo y construccin
estn realizados de acuerdo a la metodologa SCRUM, el cual se apoya
en el desarrollo gil de sistemas UML ligero (Unified Languaje )
cuyo modelamiento ayudara en la comprensin del sistema y para este
cometido se efectuara en un herramienta case.La programacin del
sistema ser realizada en ASP.NET de visual web developer 2005 una
herramienta de desarrollo gratuita, que se caracteriza porque
ofrece servicios web, independencia de la plataforma.Los servicios
web son un novedoso tipo de componentes de software que se
caracterizan a la hora de trabajar por su total independencia
respecto a su ubicacin fsica real.El sistema trabaja sobre una Base
de Datos centralizada, la que se gestiona en Microsoft SQL Server
2005 EXPRESS, un gestor de datos relacional.En el tema de seguridad
de la informacin la aplicacin estar en la intranet de la empresa,
donde solo aquellos que necesiten la aplicacin tendrn acceso.
Siendo el directo responsable el administrador de servidores que
otorga ciertos privilegios a los usuarios que estn dentro el
dominio existente.1.8.2 JUSTIFICACION OPERATIVA.Con el presente
proyecto se pretende contribuir de alguna manera en las actividades
que se realiza en el rea de Activos Fijos de la empresa MAXAM
FANEXA S.A.M. con el fin de mejorar la administracin que se realiza
a los activos fijos.1.9 ALCANCES.Con el presente proyecto se podr
tener datos muy confiables en el clculo de las depreciaciones,
tener los reportes adecuados para cada rea, que estn disponibles en
el momento que se requiera por dichas areas y que el cierre de mes
sea ms rpido evitando esperas al ingreso de nuevos activos a
depreciar.El presente proyecto tambin controlara el registro,
asignacin, depreciacin, baja, traspasos y restauraciones de los
activos, clasificados de acuerdo al siguiente TIPO: Terrenos
Edificios Muebles y Enseres Maquinaria Equipos e instalaciones
Vehculos Herramientas Equipos de computacin Equipos de
laboratorioEl sistema estar dispuesto para su acceso a travs del
navegador de Internet. El sistema trabajar sobre una base de datos
centralizada. Utilizacin del lenguaje de programacin C# bajo
plataforma .NET.
En el mbito acadmico el presente proyecto dar pautas que ayuden
el desarrollo de software de manera gil, utilizando metodologas de
la gestin de proyectos que son adaptables al desarrollo de
software, apoyados del modelamiento de UML. 1.10 LIMITACIONES.Como
este proyecto fue desarrollado especficamente para MAXAM FANEXA
S.A.M. no pretende ser una solucin general a diferentes situaciones
que otras empresas pueden tener, lo que s es posible podra
adaptarse, modificar y aadir ms operaciones en el clculo de las
depreciaciones. 1.11 INGENIERIA DEL PROYECTO. La ingeniera del
proyecto estar basada en estos elementos principales: El mtodo, el
cual definir todo el proceso de desarrollo de la aplicacin web. Y
por sus caractersticas se utilizara el de desarrollo de software
mediante SCRUM + AUP. La implementacin de la aplicacin web se lo
efectuara con herramientas de la tecnologa web, cuyo servidor de
pginas web ser IIS (Internet Information Server 2003) y C# ser como
el lenguaje de implementacin.
Tabla 1.1 ingeniera del Proyecto
OBJETIVOSACTIVIDADMETODO / TECNICA
Establecer los requerimientos de manejo de informacin en el rea
de activos fijos, con los que iniciara el desarrollo de la
aplicacin.Conformar equipos auto organizados. Historias de Usuario
Product Backlog. Release Plan
Desarrollar mdulos que contemplen: privilegios, operaciones y
registros de los activos, para una distribucin y organizacin
adecuada contemplando las normas futuras que la empresa tiene
planificado implantarlas Revisar el Product Backlog. Determinar con
cuantos sprint se desarrollara el proyecto. Planificacin del Sprint
Desarrollo de tareas para cada historia de usuario.
Desarrollar una base de datos que permita almacenar todos los
datos que genere el movimiento de los activos, de forma que se
logre almacenar informacin verdica y oportuna. Disear la base de
datos, Actualizacin y consulta de la base de datos. Modelado de la
Base de Datos Manejo de SQL SERVER 2005 EXPRESS
Disear y desarrollar la interfaz que facilite el uso del sistema
utilizando la tecnologa .NET, de tal manera que sea lo ms amigable
posible para el usuario.
Bsqueda de plantillas. Observar interfaces amigables. Interfaz
web ASP.NET Hojas de estilo CSS
En este captulo se van a abordar diversas tecnologas que se
integraran en el desarrollo del proyecto de software. La
investigacin est enfocada en el desarrollo de una aplicacin web
para la gestin de activos fijos, que integrara diversas tecnologas
con el objetivo de mejorar el movimiento de dichos activos. La
aplicacin de mtodos agiles en el desarrollo de software permitir
combinar la gestin de proyectos basados en SCRUM que es una
metodologa basada en la organizacin de trabajo. La aplicacin ser
desarrollada sobre la plataforma .NET la cual es compatible con
equipos Windows y Linux, tendr una interfaz web ASP.NET.Para el
acceso a los datos del repositorio de informacin desde la
aplicacin, se utilizara la tecnologa ADO.NET la cual es ideal para
ambientes desconectados en la web. El repositorio de informacin ser
una base de datos relacional implementada en un Sistema Gestor de
Base de Datos Relacionales.2 ACTIVOS FIJOS.Se considera Activo Fijo
a aquellos bienes que tienen una vida relativamente larga,
fsicamente tangible, no se venden pero pueden ser utilizados en la
produccin o comercializacin de bienes y servicios, pueden ser
alquilados a terceros o para fines administrativos, y que en
realidad prestan servicio a una institucin en el desarrollo
especifico de sus actividades.Con el objetivo de lograr la
racionalidad en la distribucin, uso y salvaguarda de los activos
fijos de la empresa, el rea de Activos Fijos dependientes de
Contabilidad trabaja en base a las normas bsicas del Sistema de
Administracin de Bienes y Servicios, que rige en nuestro pas,
constituyndose un conjunto de elementos jurdicos, tcnicos y
administrativos que regula el manejo de bienes de propiedad de la
institucin. Dentro los activos fijos estn separados en dos grupos:
Tangibles e Intangible, limitndonos especficamente al grupo
tangible.2.1 ACTIVO TANGIBLE.El trmino tangible se refiere a lo
fsico como es el caso de un terreno, un edificio o una mquina, este
grupo de activos es en su mayora lo que la empresa cuenta.Estos
activos cuando se desgastan y a medida que va pasando el tiempo
sufren una Depreciacin que simplemente es la prdida del valor
monetario que sufre el bien al transcurrir el tiempo. El nico
activo que no se deprecia es el terreno.2.2 CLASIFICACION
GENERAL.La empresa para la clasificacin de sus Activos y siguiendo
la sugerencia de su socia MAXAM CORPORATION lo hizo de acuerdo a:
TIPO, GRUPO Y SUBGRUPO.2.3 CLASIFICACION CONTABLE.Para efectos
contables los Activos Fijos, se clasifican particularmente en dos
grupos: Activos No Depreciables y Activos Depreciables.a) ACTIVOS
NO DEPRECIABLES.Los activos no depreciables son aquellos que no
sufren desgaste o demerito por el uso a que son sometidos y que por
tanto no pierde un precio, al menos contablemente. Entre los
activos no depreciables tenemos los terrenos, siendo este tipo
aquellos que no sufren desgaste por el uso a que son sometidos aun
cuando el tiempo ya haya transcurrido, y por esta razn se
consideran no depreciables. Esta es una teora contable aceptada en
todo el mundo. b) ACTIVOS DEPRECIABLES.La inmensa mayora de los
Activos Fijos de una empresa son depreciables, y son los que sufren
desgaste o deterioro por el uso a que estn sometidos o slo por el
transcurrir del tiempo.2.3.1 DEPRECIACION DE ACTIVOS FIJOS.Con
excepcin de los terrenos, la mayora de los activos fijos tienen una
vida til limitada ya sea por el desgaste resultante del uso, el
deterioro fsico causado por terremotos, incendios u otros
siniestros; la perdida de utilidad comparativa respecto de nuevos
equipos y procesos o simplemente el agotamiento de su contenido. La
disminucin de su valor causada por factores antes mencionados se
carga a un gasto llamado Depreciacin.La depreciacin es un
reconocimiento racional y sistemtico del costo de los bienes,
distribuido durante su vida til estimada con el fin de obtener los
recursos necesarios para la reposicin de los bienes, de manera que
se conserve la capacidad operativa o productiva del ente pblico. Su
distribucin debe hacerse empleando los criterios de tiempo y
productividad mediante uno de los siguientes mtodos: lnea recta,
suma de los dgitos de los aos, saldos decrecientes, nmero de
unidades producidas o nmero de horas de funcionamiento, o cualquier
otro reconocido valor tcnico, que debe revelarse en las notas a los
estados contables.La depreciacin no es un proceso de valuacin por
el que se asigna a gastos el costo del activo de acuerdo con
autoevalo realizados al fin de cada periodo. La depreciacin es una
asignacin del costo del activo a gastos de acuerdo con su costo
original. Un activo totalmente depreciado solamente significa que
ha alcanzado el final de su vida til estimada, es decir que no
registra ms depreciacin para el activo. Esto no quiere decir que el
activo sea desechado o que ya no se use, la mayora de veces, las
empresas continan utilizando los activos totalmente depreciados con
el fin de no pagar el IVA (impuesto al valor agregado)
correspondiente de un activo en uso.La depreciacin no significa que
el negocio aparte efectivo para reemplazar los activos cuando
lleguen a ser totalmente depreciados. La depreciacin es simplemente
parte del costo del activo que es enviado a gastos y no significa
efectivo. La depreciacin no implica un movimiento de efectivo pero
si afecta al monto de un negocio en el sentido de que constituye un
gasto deducible para fines impositivos.Por lo tanto la depreciacin
afecta el nivel de utilidades y el pago de impuestos, a un mayor
nivel de depreciacin, las utilidades son menores y los impuestos
correspondientes tambin son menores.Por otro lado debe considerarse
el valor residual o valor recuperable que ser el que tendr el bien
cuando se discontine su empleo y se calcule deduciendo del precio
de venta los gastos necesarios para su venta, incluyendo los costos
de desinstalacin y desmantelamiento si fueran necesarios.Otro
factor de importancia para la actualizacin de los costos en la
depreciacin es la utilizacin de las UFVs (Unidades de Fomento a la
Vivienda).
2.4 METODOLOGIAS AGILES.En marzo de 2001, 17 crticos de los
modelos para el desarrollo de software basados en procesos,
convocados por Kent Beck y celebrado en Utah EEUU, nace el trmino
gil aplicado el desarrollo de software. En la reunin se acuo el
trmino Mtodos Agiles para definir a los que estaban surgiendo como
alternativa a los modelos formales (CMM-SW, PMI, SPICE)
[footnoteRef:1]que los consideraban excesivamente pesados y rgidos
por su carcter normativo y fuerte dependencia de planificaciones
detalladas, previas al desarrollo de software. Los integrantes de
la reunin resumieron en cuatro postulados lo que ha quedado
denominado como Manifiesto gil y que son los principios sobre los
que se basan estos mtodos. [1: Manifiesto gil, marzo de 2001 reunin
convocada por Kent Beck para dar lineamientos sobre el nuevo
desarrollo de Software ]
2.4.1 EL MANIFIESTO AGIL.El manifiesto comienza de esta manera
Estamos poniendo al descubierto mejores mtodos para desarrollar
software, hacindolo y ayudando a otros que lo hagan.
[SCRUM-MANAGER-GESTION DE PROYECTOS] A los individuos y su
interaccin, por encima del seguimiento de un plan. La gente es el
principal factor de xito de un proyecto software. Es ms importante
construir un buen equipo que construir el entorno. Muchas veces se
comete el error de construir primero el entorno y esperar que el
equipo se adapte automticamente. El mejor crear el equipo y que ste
configure su propio entorno de desarrollo en base a sus
necesidades. El software que funciona, por encima de los procesos y
las herramientas.La regla a seguir es no producir documentos a
menos que sean necesarios de forma inmediata para tomar una decisin
importante. Estos documentos deben ser cortos y centrarse en lo
fundamental. La colaboracin con el cliente, por encima de la
negociacin contractual.Se propone que exista una interaccin
constante entre el cliente y el equipo de desarrollo. Esta
colaboracin entre ambos ser la que marque la marcha del proyecto y
asegure su xito. La respuesta al cambio, por encima del seguimiento
de un plan.La habilidad de responder a los cambios que puedan
surgir a lo largo del proyecto (cambios en los requisitos, en la
tecnologa, en el equipo, etc.) determina tambin el xito o fracaso
del mismo. Por lo tanto, la planificacin no debe ser estricta sino
flexible. 2.5 SCRUM.En 1993, Jeff Sutherland aplico el modelo Scrum
al desarrollo de software en Easel Corporation (empresa que en los
macro-juegos de compras y fusiones se integrara en VMARK, luego en
Informix y finalmente en Ascential Software Corporation). En 1996,
presento junto con Ken Schwaber, las prcticas que empleaba como
proceso formal, para gestin del desarrollo de software en OOPSLA
96(Schwaber & Sutherland, 1996). En 2001 formaron parte de los
firmantes del Manifiesto gil. Las practicas desarrolladas por
Schwaber y Sutherland para gestionar el desarrollo de software estn
incluidas en la lista de modelos agiles de Agile Alliance. Scrum es
un proceso gil que se puede usar para gestionar y controlar
desarrollos complejos de software y productos usando prcticas
iterativas e incrementales, desarrollando cualquier producto o
gestionar cualquier trabajo. Aunque Scrum estaba previsto que fuera
para la gestin de proyectos de desarrollo de software, se puede
usar tambin para la ejecucin de equipos de mantenimiento de
software o como un enfoque de gestin de programas.Scrum en el rea
de ingeniera de software es un Mtodo gil para el desarrollo de
proyectos. Toma su nombre as como los principios, de los estudios
realizados por Hirotaka Takeuchi y Ikujijo Nonaka sobre nuevas
prcticas de produccin a mediados de 1980, quienes basndose en el
juego de Rugby Scrum, las caractersticas principales de este juego
son el trabajo en equipo y la adaptacin. Scrum surgi como modelo
para el desarrollo de productos tecnolgicos, pero tambin se emplea
en entornos que trabajan con requisitos inestables y que adems
requieren rapidez y flexibilidad, estas situaciones son frecuentes
en el desarrollo de determinados sistemas software. Scrum es una
forma de desarrollo de carcter adaptable ms que predictivo, adems
de ser fcilmente combinable con otros mtodos. En un proyecto Scrum
se consideran los siguientes aspectos: Desarrollo de software en
etapas incrementales. Es un modo de desarrollo adaptable. Orientado
a las personas antes que a los procesos. Emplea del desarrollo
iterativo e incremental. Requiere de entregas de software
terminado. Se enriquece con la experiencia del equipo de trabajo.
La implementacin de Scrum es de bajo riesgo y costo.Para Scrum
Management, los requisitos y sus modelos de especificacin: Product
Backlog y Sprint Backlog, se sitan en la zona de la forma y para
que la implantacin de Scrum alcance niveles de capacidad elevados
tiene que responder una visin clara, conocida y compartida por todo
equipo, tanto a nivel de producto en general (visin del producto)
como del sprint en el que se est trabajando (objetivo del
Sprint).
Fig. 2.1 Determinacin de Requerimientos Tradicional vs. gil
Fuente: [Juan Palacios, 2008]2.6 ELEMENTOS DE UN PROYECTO SCRUM.Los
elementos centrales de un ciclo gil Scrum son:2.6.1 PRODUCT BACKLOG
(PILA DEL PRODUCTO): lista de funcionalidades que necesita el
cliente y se origina con la visin inicial del producto, va
creciendo y evolucionando durante el desarrollo del proyecto, las
caractersticas principales de esta pila son: Priorizacin de acuerdo
a la importancia que le da el propietario del producto. Debe ser
accesible para todos los miembros del equipo del proyecto. Todos
pueden contribuir y aportar elementos. El responsable directo es el
propietario del producto.2.6.1.1 COMO HACEMOS EL PRODUCT BACKLOG
(PILA DEL PRODUCTO)La Pila del Producto es el corazn de Scrum, es
donde empieza todo, la pila del producto es bsicamente una lista
priorizada de requisitos o historias o funcionalidades. Cosas que
el cliente quiere descritas usando la terminologa del cliente,
llamamos a estas historias o a veces simplemente elementos de la
pila.Tabla 2.1- Formato para el Product BacklogPRODUCT BACKLOG
(PILA DEL PRODUCTO)
IDNOMBRE O DESCRPCIONIMPORTANCIA O PRIORIDADESTIMACION INICIAL O
ESTADOCOMO PROBARLO
ID: Identificador nico auto incremental que permite no perder la
pista a las historias cuando cambiamos su nombre. NOMBRE: Una
descripcin corta de la historia del usuario, suficientemente claro
como para el dueo del producto comprenda aproximadamente de que se
est hablando y suficientemente clara como para distinguirla de las
otras historias. IMPORTANCIA: El valor que se le asigna a la
historia del usuario en la que el dueo el producto asigna un
determinado valor para la prioridad. ESTIMACION INICIAL: La
valoracin inicial del equipo acerca de cuanto trabajo es necesario
para implementar la historia, comparado con otras historias. COMO
PROBARLO: Una descripcin de alto nivel de cmo se demostrara esta
historia al final del Sprint. 2.6.1.2 HISTORIAS DE USUARIOSon las
descripciones de las funcionalidades que va tener el software,
tambin sern el resultado de la colaboracin entre el cliente y el
equipo, e irn evolucionando durante toda la vida del proyecto.Las
historias de usuario se componen de tres fases denominadas Las 3C:
Card: Sera una breve descripcin escrita que servir como
recordatorio. Conversation: Es una conversacin que servir para
asegurarse de que se ha entendido bien todo, y concretar el
objetivo. Confirmation: Test funcionales para fijar detalles que
sern relevantes e indicar cul va ser el lmite.
Fig.2.2 Historias de UsuarioFuente:
http//devnettips.blogspot.com.es ID: Identificador de la historia
de usuario TITULO: Titulo descriptivo de la historia de usuario
DESCRIPCION: Descripcin sintetizada de la historia de usuario.
ESTIMACION: Evaluacin del coste de implementacin en unidades de
desarrollo. Estas unidades representaran el tiempo terico
(desarrollo / hombre) que se haya estimado al comienzo del
proyecto. PRIORIDAD: Prioridad en la implementacin de la historia
de usuario respecto al resto de las historias de usuario. A mayor
tiempo mayor prioridad, otra aproximacin a la priorizacin de las
tareas se hace a travs del mtodo MoSCoW. M Must, se debe completar
ese requerimiento para finalizar el proyecto. S Should, se debe
completar este proyecto por todos los medios, pero el xito del
proyecto no depende el. C Could, se debera completar este
requerimiento si su implementacin no afecta la consecucin de los
objetivos principales del proyecto. W Would, se puede completar
este requerimiento si sobra tiempo de desarrollo (o en futuras
versiones del mismo) DEPENDENCIAS: Una historia de usuario no
debera ser dependiente de otra, pero a veces es inevitable. Tomando
en cuenta que la determinacin de los requerimientos es el ncleo
para el desarrollo de un proyecto y es precisamente el Product
Backlog que recurre a las historias de usuario se detallara las
historias de usuario ms sobresalientes que servirn como requisito
del sistema.2.6.2 PILA DEL SPRINT (SPRINT BACKLOG): Se define
Sprint como una iteracin que dura alrededor de 30 das. La pila del
Sprint es una lista de las tareas que debe realizar el equipo
durante esta iteracin para generar el incremento previsto. El
Sprint Backlog se sita en el rea de especificacin de los requisitos
de software necesarios para dar respuesta a las funcionalidades
esperadas por el cliente cuyas caractersticas principales son: Debe
contener las funcionalidades que se van a realizar durante el
Sprint. El equipo debe estar comprometido a realizar dichas
funcionalidades. Se debe asignar tareas a los distintos miembros
del equipo del proyecto. Se debe hacer una estimacin de cada
funcionalidad El tamao de cada tarea esta en el rango de 4 a 16
horas de trabajo. Debe ser visible para todo el equipo, idealmente
en una pizarra o l espacio fsico conveniente a donde trabaja el
equipo.2.6.2.1 PLANIFICACION DEL SPRINTLa planificacin del Sprint
es una reunin critica, probablemente la ms importante de Scrum, una
planificacin de Sprint mal ejecutado puede arruinar por completo
todo el Sprint.El propsito de la planificacin de Sprint es
proporcionar al equipo suficiente informacin como para que puedan
trabajar en paz y sin interrupciones durante unas pocas semanas y
ofrecer al dueo del producto suficiente confianza. La siguiente
figura solo muestra cmo debera realizarse en una hoja de clculo
como Excel un Sprint
Fig.2.3 - Ejemplo de Pila de Sprint con hoja de ClculoFuente:
Gestin Tcnica de Proyecto [Juan Palacios, 2013]La planificacin del
Sprint produce concretamente: Una meta de Sprint Una lista de
miembros (y su nivel de dedicacin en porcentaje) Una pila de Sprint
(Lista de historias incluidas en el Sprint)2.6.2.2 COMO HACEMOS EL
SPRINT BACKLOG (PILA DEL SPRINT)Existe varios formatos para la
elaboracin del Sprint Backlog desde pizarras, hojas de clculo o
herramientas colaborativas; y entre estas es eleccin del equipo
cual es la mejor que se adecua a las caractersticas del proyecto,
una recomendacin que da esta metodologa es disear el formato ms
cmodo para todos incluyendo ciertos criterios: Lista de tareas,
persona responsable de cada una, estado en que se encuentra y
tiempo restante que queda para completarlo. Solo incluye informacin
estrictamente necesaria. El medio y modelo elegido es la opcin
posible que ms facilita la consulta y comunicacin diaria y directa
del equipo.2.6.3 INCREMENTO: Es el resultado de cada Sprint, cuyas
caractersticas principales son: Es parte del producto desarrollado
en un Sprint. Debe estar en condiciones de ser usado. Es una
funcionalidad.2.7 MODELO DE PROCESO SCRUM.Scrum es una metodologa
de desarrollo muy simple, que requiere trabajo duro, porque la
gestin no se basa en el seguimiento de un plan, sino en la
adaptacin continua a las circunstancias de la evolucin del
proyecto.Scrum es una metodologa gil: Es un modo de desarrollo de
carcter adaptable. Orientado a las personas antes que a los
procesos. Cada funcionalidad del product backlog, se refiere a
funcionalidades entregables, no a trabajos internas del tipo diseo
de la base de datos. Emplea desarrollo gil: iterativo e
incremental.El desarrollo se inicia desde la visin general del
producto, dando detalle solo a las funcionalidades que son de mayor
prioridad para el negocio que van a ser desarrollada en primera
instancia dentro un periodo de tiempo breve (entre 15 y 60
das).Cada uno de los ciclos de desarrollo es una iteracin (sprint)
que produce un incremento terminado y operativo del producto. Estas
iteraciones son la base del desarrollo gil, y Scrum gestiona su
evolucin a travs de reuniones breves de seguimiento en las que todo
el equipo revisa el trabajo realizado desde la reunin anterior y el
previsto hasta la reunin siguiente.Sin embargo suele ser una
excepcin habitual el primer sprint, en el que los objetivos del
tipo contrastar la plataforma y el diseo pueden ser normales, e
implican trabajos de diseo, desarrollo de prototipos para probar la
solvencia de la plataforma que se va a emplear, etc.Tomando en
cuenta estas consideraciones el incremento resulta ser: parte del
producto realizada en un sprint y potencialmente entregable:
TERMINADA Y PROBADA.
2.7.1 COTROL DE LA EVOLUCION DEL PROYECTOScrum controla de forma
emprica y adaptable la evolucin del proyecto, con las siguientes
prcticas de la gestin gil:2.7.2 REVISION DE LAS ITERACIONESAl final
de cada sprint o iteracin, se realiza una revisin con todas las
personas implicadas en el proyecto. Este es el periodo mximo que se
puede tardar en reconducir una desviacin del proyecto o de las
circunstancias del producto.2.7.3 DESARROLLO INCREMENTALEn el
proyecto no se trabaja con diseos o abstracciones, el desarrollo
incremental implica que al final de cada iteracin se dispone de una
parte del producto operativa que se puede inspeccionar y
evaluar.2.7.4 DESARROLLO EVOLUTIVOComo modelo gil es muy til en
entornos con incertidumbre e inestabilidad de requisitos; intentar
predecir en las fases iniciales cmo ser el resultado final, sobre
dicha prediccin desarrollar el diseo y la estructura del producto
no es realista, porque las circunstancias obligaran a remodelar
nuevamente en varias oportunidades. Scrum toma a la instabilidad
como premisa y de esta manera es conveniente las prcticas de
trabajo que se diseen, tienen que permitir la evolucin continua sin
degradar la calidad de la arquitectura, que se ira generando
durante el desarrollo del producto.2.7.5 AUTO ORGANIZACINDurante el
desarrollo de un proyecto surgen las circunstancias impredecibles
en todas las reas y niveles. La gestin predictiva confa la
responsabilidad de su resolucin al gestor de proyectos, en Scrum
los equipos son auto organizados, con margen de decisin suficiente
para tomar las decisiones que consideren oportunas.
2.7.6 COLABORACIONLas prcticas y el entorno de trabajo gil
facilitan la colaboracin abierta entre todos segn los conocimientos
y capacidades de cada persona y no segn su rol o puesto. Los
componentes y conceptos empleados en Scrum son:2.7.7 LAS REUNIONES
Planificacin del Sprint: Jornada de trabajo previo al inicio a cada
sprint en la que se determina cual es el trabajo y los objetivos
que se deben cubrir con esa iteracin. Seguimiento del Sprint: Breve
reunin diaria para dar repaso al avance de cada tarea y al trabajo
previsto para la jornada. Revisin de Sprint: Anlisis y revisin del
incremento generado. Esta reunin no debe tomarse como un
acontecimiento especial, sino como la presentacin normal de los
resultados.
Fig. 2.4 Desarrollo de Software ScrumFuente: Gestin Tcnica de
Proyecto [Juan Palacios, 2013]2.7.8 LOS ROLES O RESPONSABILIDADESEl
grado de funcionamiento de Scrum en la organizacin depende
directamente de estas tres condiciones: Caractersticas del entorno
(organizacin del proyecto) adecuadas para el desarrollo gil.
Conocimiento de la metodologa de trabajo en todas las personas de
la organizacin y las implicadas del cliente. Asignacin de
responsabilidades Del producto Del desarrollo Del funcionamiento de
la metodologa Scrum2.7.9 RESPONSABILIDAD DEL PRODUCTO: PROPIETARIO
DEL PRODUCTOEn el proyecto hay una persona, y solo una capaz de
conocer cmo funciona el entorno del cliente desde la visin del
producto. Representa a todos los interesados del producto final y
al mismo tiempo es responsable del Product Backlog, a este suele
denominar como propietario del producto; que a su vez tiene la
responsabilidad de obtener el resultado de mayor valor posible para
el usuario o cliente.2.7.9.1 RESPONSABILIDAD DEL DESARROLLO DEL
EQUIPOTodo el equipo de desarrollo, incluido el propietario del
producto conoce la metodologa y son directamente los autnticos
responsables del resultado. Es un equipo multidisciplinar que cubre
todas las habilidades necesarias para generar el resultado.2.7.9.2
RESPONSABILIDAD DEL FUNCIONAMIENTO DE SCRUMLa organizacin debe
garantizar el funcionamiento de los procesos, metodologas que
emplea, es en este aspecto que Scrum no es una excepcin. Es una
metodologa que se garantiza integrando en el equipo una persona con
el rol de Scrum Master.Considerando que las realidades de unas y
otras empresas pueden ser muy diferentes es muy adecuado el uso de
la metodologa Scrum que puede adaptarse a los cambios continuos en
los requisitos.2.7.10 PRINCIPALES ELEMENTOS DE LA METODOLOGIAI.
HERRAMIENTAS Product Backlog Sprint BacklogII. PRACTICAS Sprints
Sprints Planning Meeting Daily Meetings Sprint Review Meeting
Desing Review Meeting Stabilization SprintIII. ROLES Y
RESPONSABILIDADES Scrum Master Product Owner Scrum Team Customer
ManagementLa figura 2.5 muestra a la metodologa como un resultado
sencillo al definir algunos roles y artefactos que contribuyen a
tener un proceso que maximiza el feedback que sirva para mitigar
cualquier riesgo que puede presentarse.
Fig. 2.5 Descripcin de roles, artefactos, reuniones y procesos
de desarrollo de ScrumFuente: William C. Wake
2.8 FASES DE LA METODOLOGIA SCRUMEl ciclo de vida Scrum est
compuesto de tres fases: Pre Game, Game y Post Game.[AISI,
2007]
Investigar para complementar o copiar de 1
Figura 2.6 Ciclo de Vida SCRUMFuente: Carlos Reynoso UNIVERSIDAD
DE BUENOS AIRES2.8.1 PRE GAME: Fase en la cual se divide en otras
dos sub fases: Planificacin y Arquitectura.2.8.1.1
Planificacin:Consiste en la definicin del sistema que ser
construido, para esto se crea la lista Product Backlog a partir del
conocimiento actual que se tiene del sistema. En ella se expresan
los requerimientos priorizados y a partir de ella se estima el
esfuerzo requerido.En esta etapa tambin todos los miembros del
equipo incluyendo el cliente contribuyen a la creacin de una lista
de caractersticas del sistema, que servirn en el anlisis y la
conceptualizacin del problema.Dentro las tareas que debe efectuarse
en esta primera etapa son: La recopilacin de requerimientos para
conformar el Product Backlog, priorizados de acuerdo a una
evaluacin del cliente. Definicin de fechas de entrega del sprint y
las funcionalidades que se requiere. Anlisis de riesgos y controles
apropiados para los riesgos.Seleccin de las herramientas y de la
infraestructura del desarrollo. Cabe indicar tambin que la Lista
del Product Backlog es actualizada constantemente con nuevos tems y
ms detalles de los requerimientos, tambin se realiza las
estimaciones precisas y los cambios en la prioridad de los tems que
pueda existir.2.8.1.2 Arquitectura:El diseo de alto nivel del
sistema se planifica a partir de los elementos existentes en la
lista del Product Backlog. En caso de que el producto a construir
sea una mejora a un sistema ya existente, se identifican los
cambios necesarios para implementar los elementos que aparecen en
la lista Product Backlog y el impacto que pueden tener estos
cambios.2.8.2 GAMEUna vez realizada la especificacin
correspondiente, se lleva a cabo la elaboracin del proyecto, con un
seguimiento continuo a cargo del mismo grupo de desarrollo. En cada
iteracin del GAME se realiza las siguientes tareas:a. Planeacin del
Sprint: Antes de comenzar cada sprint o iteracin se lleva a cabo
dos reuniones consecutivas, en la primera se refina y se prioriza
nuevamente el backlog del producto, adems de elegir las metas de la
iteracin. En la segunda reunin se deben considerar como alcanzar
los requerimientos y crear el backlog del sprint.b. Desarrollo de
Sprints: El trabajo generalmente se organiza en iteraciones de 30
das (sprints). Es el desarrollo de la nueva funcionalidad para el
producto, esta fase provee la documentacin del backlog del Sprint
con las actividades realizada por los responsables y la duracin de
cada actividad.c. Revisin del Sprint: Al final de cada iteracin se
lleva a cabo una reunin de revisin, donde se presenta la nueva
funcionalidad del producto, las metas incluyendo la informacin de
las funciones, diseo, ventajas, inconvenientes y esfuerzos del
equipo.2.8.3 POST GAMELuego de haber culminado todas las
iteraciones, resta la revisin final, denominada segn esta
metodologa como cierre.a. Cierre: Es la ltima etapa donde se
realiza la preparacin operacional, incluyendo la documentacin final
necesaria para la presentacin. Tambin en esta fase se debe realizar
dependiendo del tipo de producto ya sea el entrenamiento del
personal (usuarios) o el marketing para la venta del nuevo
producto.2.9 METODOLOGIA AUP (Agile Unified Process).El proceso
unificado gil (AUP) es una versin simplificada de RUP (Rational
Unified Process) desarrollada por Scott Ambler. Describe un enfoque
simple y fcil de entender, desarrollo del software de aplicacin de
negocios usando tcnicas agiles. AUP aplica tcnicas agiles
incluyendo desarrollo orientado a pruebas (TDD) modelado gil (AM)
gestin de cambios gil y refactorizacin de bases de datos para
mejorar la productividad y tener una documentacin necesaria y
suficientemente bueno para el entendimiento del problema y el
desarrollo de la solucin. A continuacin se describen algunos
principios del desarrollo gil de software (Agile Development) que
son apropiados para el desarrollo de la herramienta y que
justifican la eleccin de AUP como la metodologa de la solucin.2.9.1
EVOLUCIN DE REQUERIMIENTOS.Si bien al inicio de todo desarrollo de
software se busca capturar todos los requerimientos, existen
factores externos que ocasionan que dichos requerimientos cambien,
evolucionen o aparezcan otros de acuerdo a nuevas necesidades. Esto
a su vez conlleva a realizar cambios en los modelos de anlisis y
diseo para adecuarlos a los nuevos requerimientos. Tomando en
consideracin lo descrito anteriormente, se busca capturar esos
nuevos requerimientos y darles la apropiada prioridad para no
perjudicar el trabajo que pudo haber avanzado durante ese tiempo.a)
Desarrollar el producto en pequeas iteraciones y liberar versiones
del producto en tiempos incrementales.Con esta caracterstica, se
espera ir implementando por iteraciones una cierta cantidad de
funcionalidades de manera que se puedan realizar pruebas y analizar
si se estn cumpliendo con los requisitos.b) Realizacin de pruebas a
lo largo del ciclo de desarrollo del software.A diferencia de
metodologas tradicionales, el desarrollo gil de software propone
realizar pruebas a lo largo de todo el desarrollo mediante la
implementacin de unidades de pruebas que puedan ser reutilizadas,
asegurando de que todas las caractersticas estn funcionando
correctamente durante la liberacin de pequeas versiones y de la
liberacin del producto final.Los artefactos de software necesarios
para el entendimiento de la solucin estarn basados en los diagramas
UML correspondientes, los cuales sern descritos en cada fase de la
metodologa.2.10 DESARROLLO DE LA METODOLOGIA.Como se mencion
anteriormente, la metodologa para desarrollar la aplicacin es AUP,
cuyo ciclo de vida se muestra en la figura 2.7. Posteriormente, se
explicara la derivacin de su proceso mediante las fases y
disciplinas que posee la metodologa.
Figura 2.7 Ciclo de vida de AUP Fuente: Scott W. Ambler Agile
UP2.10.1 FASE DE INCEPTION.El objetivo de esta fase es la de
establecer un alto nivel los requerimientos de la aplicacin, los
cuales van a ser modelados en un diagrama de casos de uso y su
correspondiente especificacin.Adems durante esta fase inicial se
realizaran las estimaciones de costo o programacin de tareas (las
cuales ya han sido establecidas con Scrum). Con dicha informacin se
pueden establecer las iteraciones de desarrollo para la fase de
construccin, las cuales sern descritas
posteriormente.Adicionalmente, se deber establecer una lista de los
riesgos del proyecto ordenados por prioridad de tal manera que los
riesgos de alta prioridad sean mitigados durante las primeras
iteraciones y evitar obstaculizar el desarrollo del producto
durante las fases posteriores. 2.10.2 FASE DE ELABORACIN.El
principal objetivo de esta fase es elaborar y probar la
arquitectura del sistema, dicha arquitectura deber satisfacer los
requerimientos ya definidos y servir como basa para la fase de
construccin. Para ilustrar la arquitectura del sistema a travs de
distintas capas y cmo estas interactan entre ellas.2.10.3 FASE DE
CONSTRUCCIN.Esta fase corresponde al desarrollo en s de la
aplicacin, precio a la codificacin y las pruebas de calidad. Para
esta fase se han establecidos 3 iteraciones de acuerdo a lo
establecido en la fase de incepcin y a la planificacin del
proyecto: Iteracin N 1: Comprende la codificacin de las
funcionalidades relacionados a la conexin hacia las fuentes de
datos origen y destino. Iteracin N 2: comprende la codificacin de
las funcionalidades relacionadas y establecidas por el segundo
Sprint. Iteracin N 3: comprende la codificacin de las
funcionalidades relacionadas y establecidas por el tercer y ltimo
Sprint del proyecto.En paralelo con la codificacin, se
implementaran las pruebas necesarias para probar cada
funcionalidad, de manera que una vez terminada una iteracin, las
funcionalidades implementadas pueden ser corroboradas y en caso de
que sea necesario, se hagan las correcciones pertinentes. Para
llevar a cabo este trabajo, se realizaran los siguientes tipos de
pruebas: Pruebas de aceptacin. Permitirn corroborar que los
requerimientos han sido resueltos de manera satisfactoria. Unidades
de Prueba (Unit Test). Son pruebas de caja blanca que verifican que
el cdigo para implementar una funcionalidad sea el correcto. Estas
pruebas verifican el comportamiento del sistema a un bajo nivel
(nivel de cdigo), as como verificar que el diseo sea correcto.
Estos tipos de pruebas suelen ser independientes de las
funcionalidades pues verifican el cdigo fuente.La eleccin de ambos
tipos de pruebas se justifica en el hecho de que son
complementarias y necesarias. Las pruebas de aceptacin permitirn
verificar que los requerimientos se estn implementando, mientras
que las unidades de prueba verificaran que el cdigo no contenga
errores.2.10.4 FASE DE TRANSICIN.En esta etapa, se continuaran con
el conjunto de pruebas definidos en las fases anteriores previo a
la puesta en produccin de la herramienta. En caso de ser necesario,
se realizaran algunos arreglos a la codificacin de acuerdo al
resultado de las pruebas.2.11 DISCIPLINAS DEL AUP: AUP tiene siete
disciplinas que describiremos a continuacin: 2.11.1 MODELADO:
Entender el negocio de la organizacin, tratar el dominio del
problema e identificar una solucin viable para tratar el dominio
del problema.2.11.2 IMPLEMENTACIN: Transformar el modelo en cdigo
ejecutable y realizar un nivel bsico de pruebas, en particular
pruebas unitarias.2.11.3 PRUEBAS: Realizar una evaluacin objetiva
para asegurar calidad. Esto incluye encontrar defectos, validar que
el sistema funciona como fue diseado y verificar que se cumplen los
requisitos.2.11.4 DESPLIEGUE: Planificar el despliegue del sistema
y ejecutar el plan para poner el sistema a disposicin de los
usuarios finales.2.11.5 GESTIN DE CONFIGURACIN: Gestin de acceso a
los artefactos del proyecto. Esto no solo incluye el seguimiento de
las versiones de los artefactos sino tambin controlar y gestionar
los cambios en ellos.2.11.6 GESTIN DE PROYECTO: Direccin de las
actividades que tienen lugar dentro del proyecto. Esto incluye
gestionar riesgos, dirigir a las personas y coordinar las personas
y sistemas fuera del alcance del proyecto para asegurar que se
entrega a tiempo y dentro del presupuesto.2.11.7 ENTORNO: Soporte
del resto del esfuerzo asegurando que el proceso, la orientacin
(estndares y guas) y las herramientas (software, hardware)
adecuadas estn disponibles para el equipo cuando son
necesarias.2.12 .NET FRAMEWORK.Para describir los principales
conceptos con la plataforma de desarrollo escogida para esta
investigacin, se comienza con un panorama general del .NET
Framework desde su surgimiento, sus principales componentes hasta
su implementacin para entornos libres mediante el proyecto
MONO[footnoteRef:2], para despus centrarse en ASP.NET que es su
mdulo para el desarrollo web y terminar con la descripcin de su
modelo de conexin a datos desconectado llamado ADO.NET. [2: Mono es
el nombre de un proyecto de cdigo abierto impulsado por Novell para
crear un grupo de herramientas libres, basadas en GNU/Linux
compatibles con .NET]
2.12.1 PLATAFORMA. NET.El .NET Framework representa un cambio
importante en el modo de generar y ejecutar las aplicaciones web.
Es importante recalcar que ASP.NET es una de las mltiples
tecnologas que forman parte del .NET Framework. Toda la informacin
contenida en este apartado est basada en el documento publicado por
Microsoft.
Microsoft define a .NET como un modelo de desarrollo que hace
que el software sea independiente de la plataforma y de los
dispositivos, y que hace que los datos estn disponibles a travs de
internet. Por lo consiguiente, el .NET Framework es la
infraestructura bsica subyacente de .NET.Microsoft asegura que .NET
fue implementado desde un principio pensado en una arquitectura
abierta .NET es una plataforma que puede utilizarse para generar y
ejecutar la siguiente generacin de aplicaciones de escritorio y
aplicaciones web. El objetivo de la plataforma .NET de Microsoft es
simplificar del desarrollo web.2.12.2 ASP.NET.ASP.NET es un marco
de programacin basado en el .NET Framework que se utiliza para
generar aplicaciones Web. Los formularios Web Forms ASP.NET, que
forman parte de una aplicacin Web ASP.NET, proporcionan un modo
fcil de generar sitios Web dinmicos. ASP.NET tambin incluyen la
tecnologa necesaria para generar servicios Web XML, que
proporcionan los bloques bsicos para construir aplicaciones
distribuidas basadas en la web.
Figura 2.9 Elementos de una aplicacin ASP.NETFuente: Microsoft,
2001
2.13 LENGUAJE UNIFICADO DE MODELADOUML es un lenguaje de
modelado visual que permite especificar, visualizar, construir y
documentar componentes que forman parte de un sistema de software
orientado a objetos. Cualquier proceso de software basado en UML
debe contar con las siguientes caractersticas principales: Debe ser
iterativo e incremental, centrndose en los aspectos crticos en las
primeras iteraciones para minimizar riesgos para el futuro. Debe
ser guiado por los requisitos (casos de uso) y preparado para
identificar nuevos o modificar requisitos a lo largo de todo el
ciclo de vida. Tener un enfoque industrial para la produccin de
software capacidad de producir productos de alta calidad a bajo
costo. La arquitectura debe estar basada en componentes. La notacin
de modelado debe ser visual, facilitando la gestin de modelos,
ayudando a mantener la consistencia entre los elementos del sistema
y colaborando a mejorar la habilidad del equipo de desarrollo para
manejar la complejidad del software. Debe existir un control de
cambios de software para evitar un caos, especialmente en la
comunicacin entre los equipos de desarrollo, guardando la
consistencia del desarrollo del sistema. Debe poderse evaluar
continuamente la calidad de un sistema de software con respecto a
su funcionalidad, fiabilidad, rendimiento de la aplicacin y del
sistema. 2.13.1 VISTAS UML.Una vista es un conjunto de notacin UML
que modela construcciones que representa un aspecto de un sistema
de distintas perspectivas con distintos diagramas, utilizando
conjuntos separados de vistas, para representar proyecciones del
sistema relacionados con aspectos particulares funcionales y no
funcionales para el modelado de la arquitectura de un sistema (ver
figura 2.10 )
Figura: 2.10 - modelo de la arquitectura de un sistema mediante
vistasFuente: [ALARCON, 2000]Los conjuntos de Vista para modelar un
sistema son:a) Vista de Casos de Uso Es el hilo conductor de todo
el proceso de desarrollo, describiendo el comportamiento, con los
diagramas de casos de uso que muestra la funcionalidad del
sistema.b) Vista Diseo Muestra el diseo del sistema con dos
aspectos esenciales; el primer aspecto es la estructura, es decir
los comportamientos que lo integran, para lo cual utiliza los
diagramas de clases. El segundo aspecto es el comportamiento del
sistema es la dinmica de interaccin de dichos componentes,
utilizando el diagrama de secuencia. Esta vista es aplicada durante
la fase de diseo y desarrollo del sistema.c) Vista de
ProcesosMuestra la organizacin del cdigo y dems archivos parte del
sistema, archivos desarrollados o adquiridos y la dependencia entre
ellos, utilizando para ello los diagramas de componentes.Las otras
vistas no se utilizaran porque Scrum se basa ms en el desarrollo
del proyecto que en la documentacin.2.14 APLICACIONES WEB.Las
aplicaciones basadas en la web son muy diferentes de las otras
categoras de software, pues estas se caracterizan por residir en
una red (sea intranet o extranet) y deben dar servicio a una
comunidad diversa de clientes, adems de que deben tener una
evolucin continua. [Pressman, 2005].2.15 METRICAS DE CALIDADLa
calidad de software es la concordancia con los requisitos
funcionales y de rendimiento explcitamente establecidos, con los
estndares de desarrollo y con las caractersticas implcitas que se
espera de todo desarrollo de software.El estndar ISO 9126 ha sido
desarrollado en un intento de identificar los 6 atributos clave de
calidad para el software: Funcionalidad de mantenimiento,
portabilidad, confiabilidad y eficiencia.2.15.1 FUNCIONALIDADSe
trata de identificar la capacidad que el producto software tiene
para proporcionar funcionalidades que satisfagan las necesidades
especificadas; y como no puede ser medida directamente, debe ser
medido indirectamente de otras medidas directas como ser el punto
funcin propuesto por Albretch.Para el clculo de esta mtrica se
determina los valores de las cinco caractersticas de dominio de
informacin que asocia a estos dominios un valor de complejidad en
funcin a la siguiente relacin:
0.65: valor de ajuste de complejidad mnimo.0.01: factor de
conversin con un error de 1%2.15.2 CONFIABILIDADEs la probabilidad
de operacin libre de fallos de un programa en un entorno
determinado y durante un tiempo especfico.O podramos decir que es
lo que se puede esperar de un programa lleve a cabo su funcin con
exactitud requerida. Estadsticamente es la probabilidad de operacin
libre de fallos de un programa de computadora en un entorno
determinado y un tiempo especfico.Para el clculo de la
confiabilidad del sistema se utiliza la siguiente ecuacin:
Dnde:
Para hallar la probabilidad de falla del sistema en el periodo,
se utiliza la funcin exponencial dada por: En donde
2.15.3 MANTENIBILIDADLa facilidad de realizar una modificacin,
indicada por los siguientes sub atributos: facilidad de anlisis,
facilidad de cambio establecido y facilidad de prueba.Este Factor
de calidad viene dado segn el estndar IEEE 982 1998 y por la mtrica
del ndice de madurez del software (IMS) que proporciona una
indicacin de la estabilidad del producto software, basada en el
cambio que ocurre en cada versin del producto. Calculamos el ndice
de madurez de software con la siguiente relacin:
Dnde:
A medida que el IMS se aproxima a 1, el producto se empieza a
estabilizar.2.15.4 USABILIDADGrado en el que el software es fcil de
usar, se mide a travs del esfuerzo necesario para aprender a
utilizar el sistema, ya sea segn su interfaz o manual de usuario.
Se lo calcula mediante el porcentaje de una encuesta elaborada a un
cierto nmero de clientes2.15.5 PORTABILIDADEs el esfuerzo necesario
para transferir el programa de un entorno de sistema hardware y/o
software a otro.El grado de portabilidad del sistema est dado por
la siguiente ecuacin:
Dnde:
2.16 METRICAS PARA APLICACIONES WEBLas mtricas que se emplean en
los sistemas de informacin tradicionales son difciles de aplicar
directamente en aplicaciones web, debido a esto se propone el uso
de las siguientes medidas que servirn para la definicin de mtricas
orientadas a aplicaciones web [Pressman, 2006]:2.16.1 Nmero de
pginas web estticas (NPE).- Las pginas web estticas son aquellas en
las que el usuario no controla el contenido de la pgina de la
pgina. Estas pginas representan una complejidad relativamente baja
y por lo general requieren de menos esfuerzo al construirlas.2.16.2
Nmero de pginas web dinmicas (NDP).- Las pginas web dinmicas son
aquellas en las que las acciones del usuario generan contenido
personalizado. Estas pginas representan una mayor complejidad y
requieren ms esfuerzo que las pginas estticas. Estas dos medidas
proporcionan un indicio del tamao global de la aplicacin y el
esfuerzo necesario para desarrollarla.2.16.3 Nmero de vnculos
internos de la pgina (NVI).- Los vnculos internos de la pgina son
hipervnculos que ofrecen un enlace hacia otra pgina dentro la
aplicacin web. Esta medida proporciona un indicio del grado de
acoplamiento arquitectnico dentro de la aplicacin web.2.16.4 Nmero
de objetos de datos persistentes (NOP).- Una aplicacin web puede
tener acceso a uno o ms objetos de datos persistentes como bases de
datos o archivos. Esta medida proporciona un indicio de la
complejidad de la aplicacin web. En base a estas medidas se pueden
definir las siguientes mtricas:
Este ndice vara entre cero y uno dependiendo del grado de
personalizacin que la aplicacin web ofrece al usuario.
El grado de acoplamiento indica cuan relacionadas estn las
pginas de la aplicacin web. Si el valor obtenido es cero significa
que no existe acoplamiento entre las pginas de la aplicacin web, si
este valor es 1 significa que en promedio cada pgina contiene un
hipervnculo hacia alguna otra pgina de la aplicacin web, y as
sucesivamente dependiendo del nmero de vnculos que se tengan en la
aplicacin web.
El grado de complejidad indica cuan compleja es la aplicacin
web. Si el grado es menor a 1 la complejidad no es mucha pues el
nmero de pginas web es inferior al nmero de objetos persistentes.
El grado de complejidad crece si es mayor a 1, pues existirn ms
pginas web que actuaran sobre los objetos persistentes.2.17 PRUEBAS
PARA APLICACIONES WEBSe realizan pruebas a un producto software con
el propsito de encontrar errores y finalmente corregirlos. Dado que
las aplicaciones web residen en una red inter operan con muchos
sistemas operativos diferentes navegadores, plataformas de
hardware, protocolos de comunicacin, la bsqueda de errores es todo
un reto para los desarrolladores. Las etapas que se debe seguir
para la prueba de aplicacin son las siguientes [Pressman, 2005]:1.-
El modelo de contenido de la aplicacin web es revisado para
descubrir errores, para esto se debe revisar las pginas en busca de
errores tipogrficos y gramaticales.2.- El modelo de diseo de la
aplicacin web es revisado para descubrir errores de navegacin, los
enlaces de navegacin son revisados para verificar su
correspondencia.3. Se aplican pruebas de unidad a los componentes
de proceso. Las pruebas de unidad se encargan de verificar la menor
unidad de diseo de software, en este caso una pgina web. Para esto
se comprueban los procesos encapsulados en la pgina utilizando una
tcnica de prueba de software. Una de estas tcnicas es la del camino
bsico, que consiste en hallar la complejidad ciclomatica del
programa, este valor representa el nmero de caminos de ejecucin y
el lmite superior para el nmero de pruebas que se debe realizar.4.
Se construye la arquitectura y se realizan las pruebas de
integracin, para esto se pueden usar casos de pruebas basados en
los casos de uso.5. Luego de ensamblar la aplicacin web se realizan
las pruebas de seguridad tomando en cuenta los criterios de
seguridad observados.6. La aplicacin web se implementa en una
variedad de configuraciones de diferentes entornos, para as
comprobar su compatibilidad con cada configuracin. Se pueden usar
diferentes sistemas operativos, navegadores y plataformas de
hardware.7. La aplicacin web se prueba con una poblacin de usuarios
finales controlada y monitorizada, luego se evalan los resultados
de su integracin con el sistema. Dado que las aplicaciones web estn
en constante evolucin, el proceso de comprobacin es una actividad
continua.
En este captulo se va abordar la utilizacin de las fases en lo
que compete la Determinacin de Requerimientos del sistema y la
Planificacin del proyecto por medio de Scrum en su fase Pre Game,
as mismo se definir el alcance del Proyecto, definir los riesgos,
la arquitectura del sistema, lo que es la fase Inicial de AUP
tambin comprende la modelacin de los requerimientos por medio de
diagrama de Casos de Uso.3. 1 FASE PRE GAME (SCRUM) FASE INCEPTION
(AUP)Scrum por definicin no requiere documentacin con diagramas de
casos de uso ni diagramas de secuencia, pero asume la existencia de
Diseo y cdigo Orientado a Objetos basado en libreras y clases.Con
AUP para una mejor comprensin del sistema utiliza de acuerdo a lo
que sea conveniente al proyecto los diagramas ms representativo de
UML nivel 1, y en esta fase para la representacin y comprensin de
los requerimientos utilizaremos los Diagramas de Casos de Uso3.1.1
OBJETIVOS DEL PROYECTOEl objetivo principal del presente proyecto
es la implementacion de un software que reemplace a la planilla de
excel que se tiene actuamente, y que la implementacion debe
considerar el tiempo minimo para su implementacion.3.1.2
COMPROMETIDOS CON EL PROYECTO.Para el desarrollo de la aplicacin y
siguiendo la forma de organizacin de Scrum se conform un equipo de
trabajo de acuerdo a los siguientes roles: Producto Owner.
Representa la voz del cliente, asegurando que el equipo trabaje de
forma adecuada desde la perspectiva del negocio, tambin es el que
escribe todas las historias de usuario, las prioriza y las coloca
en el Producto Backlog. Scrum Master o Facilitador. Su trabajo es
eliminar los obstculos que impiden que el equipo alcance el
objetivo del Sprint, asegurndose que el proceso Scrum se utilice
como es debido. Equipo. Tiene la responsabilidad de entregar el
producto cuyas habilidades transversales sern necesarias para
realizar el trabajo. Usuarios. Es el destinatario final del
producto. StakeHolders (Clientes, Proveedores, Inversores). Se
refiere a los que hacen posible el proyecto y para quienes va
producir el beneficio acordado. Managers. Es la gente que establece
el ambiente para el desarrollo del producto.3.2 CONFORMACION DE LOS
EQUIPOS.Para la conformacin de los equipos de trabajo se trat de
seguir lo que Scrum necesita como mnimo para concluir el proyecto,
pero como en nuestro caso es una empresa y especficamente una
aplicacin para el rea de Activos Fijos dependiente de Contabilidad
General y Gerencia Administrativa y Gerencia Financiera, se asign
lo que son los roles de Scrum con el siguiente equipo:Product Owner
Gerencia Financiera Ing. Hugo Arzabe AscarrunzMAXAM FANEXA S.A.M
Gerencia Administrativa: Tcnl. Marco A. lvarez Daza.Scrum Master:
Jair Samuel Ventura TovarEquipo: Jair Samuel Ventura Tovar Jefe de
Sistemas: Ing. Alejandro Alvarado Foronda Jefe de Sistemas Planta
Santivaez: Ing. Rodrigo Rojas Romero Contador General: Lic. Oscar
Herbas Auditor Interno: Lic. Tagmina Thames SandovalUsuarios.
(Gallinas)Responsable de Activos Fijos: Lic. Nohelia Vazquez
DazaContabilidad de Costos: Lic. Ernesto Barrientos Lic. Griselda
Ortiz CossioGerencia Financiera: Ing. Hugo Arzabe AscarrunzGerencia
Administrativa: Tcnl. Marco A. lvarez Daza.3.3 DETERMINACION DE LOS
REQUERIMIENTOSLa Determinacin de los Requerimientos en las
metodologas clsicas de desarrollo de software vienen determinadas
por una seria de documentos modelos que escapan a la esencia misma
de Scrum que simplemente se basa en la recopilacin de estos
requerimientos mediante la herramienta Historias de usuario que
luego de las 2 reuniones que se tuvo con el equipo se determin
realizar las siguientes historias de usuario.Tabla 3.1 Historias de
Usuario del ProyectoHistoria de Usuario: H11Ingresar al Sistema
Como Gerente Financiero quiero que cada usuario que acceda al
sistema se identifique con una cuenta y clave especifica.
Estimacin: 1 dia
Prioridad: AltaDependencia: -----
Cuando se introduzca una cuenta que no corresponda a la que se
le dio automticamente el programa debe considerarlo como invitado.
Debe considerar que solo debe existir las cuentas de administrador,
contador, y encargado. La cuenta de contador debe ser la nica que
pueda dar de baja un activo.
Historia de Usuario: H22Registro de Usuario Que al acceder al
programa no muestre otras cuentas que no sean la que estn
permitidas. Las cuentas permitidas para esta aplicacin solo deben
ser Administrador, Encargado, Contador e Invitado. Cada usuario de
esta lista solo debe poder hacer ciertas operaciones.
Como Gerente Financiero quiero que cada usuario que manipule el
sistema sea registrado previamente para un mejor control.
Estimacin: 1 dia
Prioridad: MediaDependencia: H1
Historia de Usuario: H3
3Generacin de Cdigo Cada activo debe diferenciarse plenamente
con esta nueva clasificacin. Tambin por el tema de crecimiento de
activos debe contener otros 4 dgitos ms. Al ingresar una bsqueda
por la codificacin asignada no debe repetirse ni existir
coincidencia.
Como Gerente Financiero quiero la codificacin este en funcin a
la siguiente clasificacin: Tipo. Grupo y Sub - Grupo.
Estimacin: 3 dias
Prioridad: AltaDependencia: ---
Historia de Usuario: H44Asignacin de Activos Cuando se haga la
bsqueda de un activo especfico debe mostrarse la informacin
correspondiente. Cada activo nuevo que se ingresa debe contener en
qu lugar se encuentra este activo. Al realizar las diversas
operaciones tambin debe mostrarse quien tiene el activo.
Como Gerente Administrativo quiero que cada activo asignado se
especifique a quien se lo entrega y en donde se encuentra.
Estimacin: 3 dias
Prioridad: AltaDependencia: H15
Historia de Usuario H55Calcular Depreciacin Al realizar esta
operacin debe ser idntica a la planilla echa en Excel. Las formulas
deben ser elaboradas por la parte contable y auditoria. Cuando se
realice el clculo de la depreciacin debe seguirse y tomar en cuenta
el acceso de la UFVs. Se debe dejar la posibilidad de cambiar a
futuro a otros mtodos de depreciacin.
Como Gerente Financiero quiero que las depreciaciones se lo
realice por el mtodo de lnea recta para la mayora de los activos y
por horas trabajada a maquinaria.
Estimacin: 5 dias
Prioridad: AltaDependencia: H6
Historia de Usuario: H66Ingresar Tipo de Cambio Al momento de
ingresar los datos al sistema cada activo debe contar con su UFV
inicial y su UFV final. Para el ingreso de estos valores para las
plantas debe ingresar tambin los porcentajes para la
depreciacin.
Como Gerente Financiero quiero que el tipo de cambio este en
funcin a las UFVs del da de compra y del momento en que se realiza
la operacin de depreciar.
Estimacin:
Prioridad: MediaDependencia: H5
Historia de Usuario: H77Clasificar Activo La clasificacin debe
mostrar diez dgitos para cada activo. Cuando los activos se
revalorizan los activos debe diferenciarse del resto de los activos
aadiendo una letra R al final.
Como Jefe de Sistemas quiero que la clasificacin siga el
siguiente formato:Tipo: xx----Grupo: xx---Subgrupo: xx y el numero
correlativo: xxxx
Estimacin:
Prioridad: AltaDependencia: H3
Historia de Usuario: H88Almacenamiento de los Datos Debe
almacenarse la informacin de cada operacin y centros de costo. La
construccin de la base de datos debe contemplar las normalizaciones
respectivas. El almacenamiento debe realizarse un gestor libre. La
planilla echa debe servir de base para la construccin y diseo de la
base de datos.
Como Jefe de Sistemas quiero que se construya una base de datos
relacional para el almacenamiento de la informacin generada durante
la implementacin.
Estimacin:
Prioridad: AltaDependencia: ----
Historia de Usuario: H99Mostrar Reportes Los reportes deben ser
idnticos a la planilla que utilizan cada unidad. Los reportes deben
tener la posibilidad de migrar sus datos a Excel, texto y pdf. Cada
reporte debe mostrarse de forma mensual y anual. Debe mostrarse
reportes de activos deducibles y no deducibles.
Como Gerente Administrativo quiero que los reportes sean
construidos en funcin a las unidades dependientes.
Estimacin:
Prioridad: AltaDependencia: H5, H6
Historia de Usuario 1010Revalorizar Activos Que cuando un activo
termine su tiempo de vida, su valor residual permanezca en 1. La
revalorizacin o restauracin debe realizarlo la parte contable.
Como Gerente Financiero quiero que exista la posibilidad de
revalorizar un activo que ya haya terminado su tiempo de vida y aun
est en condiciones
Estimacin:
Prioridad: AltaDependencia: H3, H7
Historia de Usuario: H1111Traspaso de Activos Que exista la
posibilidad de buscar por medio del cdigo o nombre del activo. Debe
existir la posibilidad de ver la regional juntamente su unidad de
negocio y su centro de costo. Tambin debe buscarse por medio del
C.I quien esta a cargo o a quien se lo asignara.
Como Gerente Financiero quiero que esta operacin se realice
juntamente con la asignacin de cada activo.
Estimacin:
Prioridad: MediaDependencia: H4
Historia de Usuario: H1212Interfaz de Usuario Que al momento de
ingresar sea lo mas idntico a la planilla echa en Excel para asi
evitarse contratiempos en el manipuleo. Que contenga los mismos
campos para el llenado de datos. Que las operaciones que se
realicen ayuden y sean mas cortas.
Como Jefe de Sistemas quiero que el interfaz sea lo mas amigable
posible y en lo posible utilizar templates existentes en
internet.
Estimacin:
Prioridad: AltaDependencia:
Historia de Usuario: H1313Plataforma Tecnolgica Que al momento
de subir al servidor esta aplicacin debe poder verse en cualquier
Centro de Costo dependientes de Maxam. Se debe realizar una
evaluacin y adecuarse a la plataforma que se cuenta en la
empresa.
Como jefe de Sistemas quiero que se aproveche los servidores que
cuenta la empresa y el desarrollo sea con herramientas libres de
pago.
Estimacin:
Prioridad: MediaDependencia: H8, H12
Historia de Usuario H1414Registrar Regional Al momento de
ingresar con cualquier cuenta que sea distinta a la del
administrador, la aplicacin automticamente se desconecte. Solo la
cuenta de administrador debe poder hacer las operaciones de
registrar, modificar y eliminar estos datos. Se debe crear una
tabla en la base de datos para esta informacin.
Como Jefe de Sistemas quiero que exista un modulo o men para
ingresar datos a la Regional, Unidades de Negocio, Centros de
Costos y plantas que puedan contar y se almacenen en la base de
datos.
Estimacin 3 dias
Prioridad: AltaDependencia: H2
Historia de Usuario H1515Registrar Responsable Que al tratar de
ingresar con otras cuentas la aplicacin se desconecte
automticamente. La operacin debe estar limitada simplemente para el
encargado de activos fijos. El registro de los responsables es para
conocer quienes estn a cargo o manejando los activos.
Como Gerente Administrativo quiero que esta operacin lo realice
el encargado de manejar ls activos fijos.
Estimacin: 4 dia
Prioridad: MediaDependencia: H2
Historia de Usuario: H1616Baja de un Activo Cuando el encargado
o el administrador quiera hacer una baja, la aplicacin no se lo
permita. La baja de un activo debe realizarse solo cuando el activo
haya concluido su tiempo de vida.
Como Gerente Financiero quiero que esta posibilidad solo sea
posible para el contador en el men de activos.
Estimacin 4 dias
Prioridad: AltaDependencia: H2,H5,H10
3.4 PRODUCT BACKLOG (PILA DEL PRODUCTO)La siguiente tabla
contiene el product backlog resultante de las Historias de Usuarios
que se rescat de los interesados, y como se mencion este product
backlog no es una lista fija e invariable de requisitos funcionales
del sistema, sino que esta lista es un documento sigue para recibir
ms requerimientos en el desarrollo del sistema.
Tabla 3.2 Product Backlog del
ProyectoIdPrioridadEstadoDescripcinEstimacin delEsfuerzo [das]Como
Probarlo
H1AltaTerminadoAcceso de Usuarios3
H2MediaTerminadoRegistro de Usuarios2
H3AltaTerminadoGeneracin de Cdigo3
H4AltaTerminadoAsignacin de Activo2
H5AltaTerminadoCalcular depreciacin10
H6MediaTerminadoIngresar tipo de cambio5
H7AltaTerminadoClasificar Activos5
H8AltaTerminadoAlmacenar datos5
H9AltaTerminadoMostrar Reportes5
H10AltaTerminadoRestaurar Activos5
H11AltaTerminadoTraspaso de Activos5
H12AltaTerminadoInterfaz de Usuario3
H13MediaTerminadoPlataforma tecnolgica5
H14MediaTerminadoRegistrar Regional5
H15MediaTerminadoRegistrar Responsable2
H16AltaTerminadoBaja de Activos5
3.5 RELEASE PLAN: Tabla 3.3 Release Plan del
ProyectoIteracinHistoria de UsuarioTiempo Estimado
1er. SprintH13: Plataforma Tecnologa4 semanas
H1: Acceso al Sistema
H2: Registro d Usuario
H12: Interfaz de Usuario
H8: Base de datos
H15: Registrar Responsable
2do. SprintH4: Asignacin de Activos4 semanas
H3: Generacin de Cdigo
H6: Ingresar Tipo de Cambio
H7: Clasificar Activo
H11: Traspaso de Activo
3er. SprintH5: Calcular Depreciacin5 semanas
H14: Registrar Regional
H10: Restaurar Activo
H16: Baja de Activo
H9: Mostrar Reportes
Esta planificacin es el Sprint 0 para dar comienzo a las
iteraciones que se desarrollara en la fase Game del siguiente
captulo.
3.6 ALCANCE DEL PROYECTOCon el presente proyecto se pretende
obtener y contar con una herramienta que ayude en el clculo de la
Depreciacin que se realiza actualmente con un planilla echa en
Excel lo cual tambin sirve para realizar los cierres respectivos de
cada mes en contabilidad y las respectivas unidades que requieran
de los informes que se genera.3.6 .1 ESTIMACION DE COSTOS:La
estimacin de los costos lo dejaremos para ms adelante, en cuanto se
tenga los casos de uso del sistema que para la estimacin de los
costos utilizaremos los puntos por casos de uso, que se detallara
en el anexo A.3.7 ANLISIS DE RIESGO.Un riesgo es la probabilidad
que exista algo adverso a lo planificado, de los cuales
describiremos a continuacin:3.7. 1 Riesgo del Proyecto. Que afectan
a la calendarizacin o recursos del proyecto.3.7.2 Riesgo del
Producto. Que afectan a la calidad o rendimiento del software que
se est desarrollando.3.7.3 Riesgo del Negocio. Afecta a la
organizacin que desarrolla o suministra el software.El presente
proyecto como cualquier otro proyecto no est libre de varios
riesgos o dificultades que podra atravesar en el transcurso de su
desarrollo, se describen a continuacin as como las estrategias que
se propusieron para hacerlo frente.Tabla 3.4 Anlisis de
RiesgosRiesgo TipoDescripcinProbabilidadEfectoEstrategia
No se cumple con las fechas establecidas en el
cronograma.ProyectoProbablemente las fechas previstas en el
cronograma no se cumplan a cabalidad.AltaTolerable Disear un
cronograma flexible que considere los retrasos.
Cambio continuo en los requerimientos del cliente.Proyecto,
productoPunto primordial de la metodologa para adaptarse
continuamente a los cambios que pueda darse en el transcurso del
proyecto.MediaTolerableRealizar una revisin constante de los
requerimientos.Programar reuniones constantes con el cliente.
No se concluya con algunos de los requerimientos.ProductoPor el
gran nmero de requerimientos y el poco tiempo de desarrollo no se
cumpla alguno de ellos.Alto Tolerable Separar los mdulos en el
sistema de tal forma que la ausencia de uno no afecte en el
desempeo de los dems
No existen los equipos necesarios para la implementacin del
sistema.El constante cambio de equipos hace que sea dificultoso
desarrollar.Maxam Fanexa por el uso masivo de equipos y distribucin
a sus centros es limitante el acceso a uno de ellos.Alto
TolerableSolicitar a Gerencia Financiera que se otorgue un equipo
para el desarrollo
No se cumple con el plazo de entrega del producto.ProductoEl
plazo lmite de entrega del producto fue en el mes de diciembre,
pero por cierre de gestin y vacacin colectiva abra un retraso en la
entrega. Moderada Serio Agilizar los procesos de
desarrollo.Realizar correcta planificacin de tiempos considerando
los ingresos a planta.
3.8 IDENTIFICACIN DE LOS ACTORES DEL SISTEMA.Dentro los actores
del sistema tenemos a los siguientes casi independientes de los
otros:Administrador. Es el encargado de la administracin de la
aplicacin quien al mismo tiempo realiza operaciones de: registro de
nuevos usuarios, control y seguimiento de los activos fijos
(bsquedas, reportes), pero no puede dar baja ningn activo, esto
segn requerimiento del cliente.Encargado de Activos Fijos. Es el
usuario del manejo de la aplicacin por lo tanto tiene acceso a
todas las opciones de la aplicacin a excepcin de ingreso de nuevos
usuarios y dar de baja algn activo.Contador. Es el encargado de
hacer especficamente las bajas de los activos que ya terminaron su
tiempo de vida, tambin puede hacer las otras operaciones que los
dems a excepcin de crear nuevos usuarios.Invitado. Es cualquier
otra persona de la empresa que solicite ver simplemente reportes
para su uso en cada cierre de mes o gestin.Descripcin de los
Actores.Tabla 3.5 Descripcin de Actores
ActorProceso
Administrador del Sistema Administracin de Usuarios Registro y
Modificacin de perfiles de acceso. Bsquedas. Reportes. Registro y
Modificacin de Regiones.
Contador Dar baja a los activos fijos Dems otras operaciones de
encargado. Bsquedas. Reportes.
Encargado de Activo Registro de activos fijos Registro y
modificacin de parmetros. Registro y generacin de reportes de
inventario
Usuario de Reporte (Invitado) Solicitar y generar reportes
3.9 ENTORNO PARA EL DESARROLLO DEL PROYECTOPara el desarrollo
del presente proyecto se hizo el siguiente requerimiento de
software y verificacin de lo que contaba la empresa respecto a la
arquitectura disponible para el desarrollo de la presente
aplicacin:3.9.1 ESPECIFICACIN DE HARDWAREEl sistema trabaja bajo un
entorno web (cliente servidor), mas propiamente esto funcionara en
la INTRANET que cuenta la empresa al cual puede accederse desde
cualquier Centro de Costo localizados en diferentes lugares del
pas.Como requerimientos mnimos de hardware y software que debe
considerarse para implementar esta aplicacin se debe tomar lo
siguiente: 1 PC Pentium IV o superior Memoria RAM 512
MB.(recomendable 1GB para un buen rendimiento) Sistema Operativo
Windows XP profesional Tener configurado el servicio de Internet
del servidor IIS. Framework 2.0 Tener un navegador (internet
Explorer 6 o superior, lo recomendable navegador mozilla firefox
3.x.x). Tener activado flash player 9_2_p2_32bit_plugin_111710 o
superiorEstos requerimientos vienen a ser parte de los
requerimientos no funcionales del sistema.
En este captulo se desarrollara la construccin de los sprint
para cada iteracin planificada en el Relase Plan, la metodologa AUP
para esta fase como en las anteriores apoyara en la representacin
del sistema por medio de artefactos basados en UML, lo cual har ms
comprensible al presente proyecto.4.1 FASE GAME (SCRUM) FASE
ELABORATION Y FASE CONSTRUCTION (AUP)Como parte de la fase de
construccin del modelo AUP se desarrollara la implementacin de las
respectivas iteraciones ms las pruebas exigidas en esta fase.4.1.1
PRIMER SPRINT4.1.1.1 PLANIFICACION DEL SPRINTLa planificacin del
Sprint es la jornada de trabajo previo al inicio de cada Sprint en
la cual se determina que trabajo y objetivos que se debe conseguir
en cada iteracin. La planificacin del Sprint dar como resultado: el
objetivo del Sprint, la Pila del Sprint, la duracin del Sprint.Esta
planificacin se lo realiza mediante dos reuniones divididas en dos
partes:1ra Parte: Se realiza la estimacin de las funcionalidades
que tengan mayor prioridad durante el Sprint.2da parte: Desglosar
las funcionalidades en tareas con tiempos estimados Al mismo tiempo
dispone de reuniones diarias de aproximadamente 10 minutos en la
cual se formula las siguientes preguntas:Trabajo que se realiz el
dia anterior?Trabajo que se tiene previsto realizarCosas que puede
necesitar o impedimentos que debe suprimirse para realizar el
trabajo.Para el presente trabajo se detalla a continuacin
4.1.1.2 OBJETIVO DEL SPRINTEl objetivo del primer sprint es
mostrar la pgina principal con toda la estructura que se agregara
en los siguientes Sprint como ser: acceso al sistema, registro de
usuario, la interfaz que se mostrara y comienzo de la base de datos
que se tendr. La tabla 4.1 muestra al primer Sprint
Donde las funcionalidades correspondientes al incremento de la
iteracin son: Base de Datos independiente de los otros sistemas
existentes. Pgina de ingreso con control de acceso a los usuarios
Asignacin de responsablesDIAGRAMAS DE CASOS DE USO DEL SPRINTFig.
4.1 Diagrama de Casos de Uso del Sprint 1
ESPECIFICACION DE LOS CASOS DE USOTabla 4.2 Descripcin del Caso
de Uso Acceder al SistemaNombre:Acceder al Sistema
Actores:Usuario Windows
Tipo:Bsico
Descripcin:Valida al usuario mediante una cuenta y password,
para que pueda ingresar y utilizar el sistema.
Pre condiciones:El usuario debe estar registrado en el sistema
con anterioridad.
Flujo Normal:1. El actor ingresa su cuenta y password, y
presiona el botn Aceptar.2. El sistema busca la cuenta y el
password en la base de datos y lo valida en el sistema.3. Una vez
verificada la cuenta del usuario, se abre la pantalla principal de
la aplicacin dependiendo al rol del usuario (Administrador,
Operador, Director Acadmico, o Director Ejecutivo).4. Si el actor
presiona el botn Cancelar, termina la ejecucin de la aplicacin
Flujo Alternativo:2A. Si la cuenta o el password no se valid
correctamente, el sistema muestra un mensaje de Error.
Post condiciones:El usuario ha sido autenticado, y puede
utilizar el sistema.
Tabla 4.3 Descripcin Caso de Uso Gestin Usuario Caso de
UsoGestin Usuario
ActoresAdministrador
TipoBsico.
ResumenEl administrador se encarga de realizar el manejo de
usuarios desde la creacin a la eliminacin.
PrecondicionesQue el usuario a utilizar sea parte de la empresa
o que cuente con la autorizacin del encargado de sistemas.
Flujo Principal1. El usuario ingresa a la pgina de la
aplicacin2. El usuario ingresa al mdulo de registro3. El usuario
ingresa sus datos personales.4. El usuario asigna que tipo de rol
ser el nuevo usuario.5. Toda la informacin es almacenada en la base
de datos de la aplicacin.6. Puede ver el listado de quienes estn
como usuarios.
ExcepcionesSi el ingreso de la cuenta y pasword son incorrectos
la aplicacin mostrara un mensaje de error
Tabla 4.4 - Descripcin Caso de Uso Gestin Unidad de NegocioCaso
de UsoGestin Unidad de Negocio
ActoresAdministrador
TipoBsico.
PrecondicionesQue el administrador solo es capaz de crear nuevas
Regionales en caso de que la empresa se extienda a nivel nacional y
bajo autorizacin directa de Gerencia General de la empresa.
Flujo Principal1. El administrador ingresa al mdulo de Unidad de
Negocio y dependiendo de las opciones seleccionadas por el usuario
se continuara con los diversos subflujos.
Subflujos2. El sistema muestra el men de Uni Neg con las
siguientes opciones: Registrar Regional, Registrar Unidad de
Negocio y Registrar Centro de Costo.3. Si el administrador
selecciona Registrar Regional contara con las siguientes
opciones:4. Para la creacin de nuevas regionales debe asignarse un
identificador numeral de dos dgitos y que identificara a cada
departamento del pas.5. Ingresar el nombre del departamento o regin
importante que se considere.6. El usuario administrador debe
presionar el botn registrar o cancelar cuando haya terminado este
proceso.7. El usuario administrador una vez hecha la operacin puede
ver el listado y si hay algo que modificar tiene la opcin de editar
o eliminar directamente.8. Si el administrador selecciona Registrar
Unidad de Negocio tendr una pantalla casi parecida a la anterior,
solo que antes debe seleccionar la regin en donde va registrar la
nueva Unidad de Negocio.9. Si el administrador selecciona la opcin
de Centro de Costos de la misma manera antes previamente el usuario
administrador debe seleccionar: Region y Unidad de Negocio para
poder crear el lugar donde asignar el nuevo Centro de Costo.
ExcepcionesSi e