2010

UNIVERSIDAD AUTONOMA GABRIEL RENE MORENO

FACULTAD DE CIENCIAS EXACTA Y TECNOLOGIA
INGENIERIA INFORMATICA

COMPONENTE PARA LA GESTION DE USUARIO,

ASIGNACION DE PRIVILEGIOS Y BITACORA

ALUMNO:

Miguel Angel Ardaya Cabello

REGISTRO: 200609394
MATERIA: Ingeniera de Software I
TUTOR:

Ing. Martnez

SANTA CRUZ-BOLIVIA

TABLA DE CONTENIDO
1.

OBJETIVOS................................................................................................................................... 4
1.1.

OBJETIVO GENERAL ............................................................................................................ 4

1.2.
2.

OBJETIVO ESPECIFICO ..................................................................................................... 4

MARCO TEORICO ........................................................................................................................ 5

2.1.

DESARROLLO DE SOFTWARE BASADO EN COMPONENTES (DSBC) .................................. 5

2.2.

MODELO XP (XTREME PROGRAMMING) PARA DESARROLLO DE PROYECTO .................. 8

3.

2.2.1.

INTRODUCCIN .......................................................................................................... 8

2.2.2.

HISTORIA ..................................................................................................................... 8

2.2.3.

CARACTERISTICAS DE XP ............................................................................................ 9

2.2.4.

GESTIN DE REQUISITOS EN EL DESARROLLO DE SOFTWARE ................................ 10

2.2.5.

ROLES Y RESPONSABILIDADES EN XP....................................................................... 10

2.2.6.

CICLO DE VIDA........................................................................................................... 11

2.2.7.

VALORES EN XP ......................................................................................................... 12

2.2.8.

DIFERENCIAS FUNDAMENTALES DE EXTREME PROGRAMMING ............................ 12

PLANIFICACION ......................................................................................................................... 13
3.1.

AMBITO ............................................................................................................................. 13

3.2.

PRIORIDAD ........................................................................................................................ 13

3.3.

METAFORA ........................................................................................................................ 13

3.4.

HISTORIAS DE USUARIO ................................................................................................... 14

4.

DISEO SIMPLE ......................................................................................................................... 15

4.1.

MODELO DE CLASE ............................................................................................................... 15

4.1.1.

Gestion de Usuario ........................................................................................................... 15

4.1.2.

Bitacora ............................................................................................................................. 16

4.2.

MODELO DE DATO ................................................................................................................ 17

4.2.1.

Gestion de Usuarios.......................................................................................................... 17

4.2.2.

Bitacora ............................................................................................................................. 17

5.

DESARROLLO ............................................................................................................................. 18

6.

PRUEBAS ................................................................................................................................... 19

7.

CONCLUSION............................................................................................................................. 21

8.

RECOMENDACIONES ................................................................................................................ 21

9.

BIBLIOGRAFIA ........................................................................................................................... 21

10.

ANEXOS ................................................................................................................................. 22

Anexo 1 ......................................................................................................................................... 22
Anexo 2 ......................................................................................................................................... 23

INTRODUCCION
A pesar de la aparente evolucin que ha sufrido la programacin a lo largo de los ltimos
40 aos, el desarrollo de una aplicacin contina siendo una actividad costosa en tiempo y
dinero, y los errores en el producto final son frecuentes. El problema es que el nivel de
reutilizacin sigue siendo muy escaso.
En cambio, en otras ingenieras como la electrnica el grado de reutilizacin es altsimo. En
este mbito, la construccin de un dispositivo electrnico se reduce a la integracin de la
manera adecuada de distintos componentes comerciales. Existe fabricantes especializados
en la fabricacin de componentes y otros en la de dispositivos finales .El producto final
obtenido es de calidad y se realiza en un tiempo relativamente corto
La solucin a la crisis del software pasa por cambiar el modelo de desarrollo a un desarrollo
orientado a componentes. El cual se basa en la construccin de una aplicacin a partir de
componentes software comerciales o gratuitos ya existentes, limitando al mnimo necesario
el desarrollo de cdigo nuevo.
Para que este cambio se produzca es necesaria la creacin de un mercado amplio de
componentes software de calidad y con un mbito de aplicacin general. Tambin ser
necesaria la adopcin de una arquitectura estandarizada que garantice la interoperabilidad
de los componentes en distintas plataformas, lenguajes de programacin y entornos de
desarrollo
Las metodologas giles de desarrollo de Software, en particular Extreme Programming
(XP), es una de las tendencias de mayor impacto en la industria del desarrollo de Software,
es una metodologa reciente (tiene alrededor de 9 aos). La filosofa de XP es satisfacer al
completo las necesidades del cliente, por eso lo integran como una parte ms del equipo de
desarrollo.
1. OBJETIVOS
1.1. OBJETIVO GENERAL
Contribuir a mejorar la calidad de un producto de Software, en base a componentes ya que
el desarrollo ser mucho ms sencillo y en un tiempo y con un costo menor. Y la
posibilidad de errores es mnima ya que los componentes son sometidos a un riguroso
control de calidad antes de ser comercializados.

1.2. OBJETIVO ESPECIFICO

Construir un componente que ayude al programador al momento de crear sistemas de
informacin, facilitndole los sub-paquetes de gestin de usuario, asignacin de usuario y
bitcora, de tal manera mejorar su productividad y la calidad del software.

2. MARCO TEORICO
2.1. DESARROLLO DE SOFTWARE BASADO EN COMPONENTES (DSBC)
Hoy en da podemos decir que existe un consenso al considerar el desarrollo basado en
componentes como un avance significativo hacia la construccin de sistemas mediante
el ensamblado de componentes prefabricados. El DSBC trata de sentar las bases para el
diseo y desarrollo de aplicaciones distribuidas basadas en componentes software
reutilizables. Dicha disciplina cuenta actualmente con un creciente inters, tanto desde
el punto de vista acadmico como desde la industria, en donde la demanda de
mecanismos y herramientas de desarrollo basados en componentes es cada da mayor.
En general, el desarrollo de software basado en componentes puede verse como una
extensin natural de la programacin orienta a objetos dentro del mbito de los sistemas
abiertos y distribuidos.
Este paradigma se basa en el uso de los componentes software como entidades bsicas
del modelo, entendiendo por componente una unidad de composicin de aplicaciones
software que posee un conjunto de requisitos, y que ha de poder ser desarrollado,
adquirido, incorporado al sistema y compuesto con otros componentes, de forma
independiente en tiempo y espacio [Szyperski, 1998]. Numerosas son las
caractersticas que aporta la programacin orientada a componentes frente a la
programacin orientada a objetos tradicional. Entre ellas, el desarrollo de los
componentes de forma independiente del contexto en donde sern ejecutados, la
reutilizacin por composicin (frente a herencia, al tratarse de entidades binarias o
cajas negras), la introspeccin (facilidad para interrogar al componente sobre sus
propiedades y mtodos de forma dinmica, normalmente mediante el uso de reflexin),
nuevas formas de comunicacin (como los eventos y las comunicaciones asncronas
frente a los rudimentarios mecanismos de los objetos), el enlazado dinmico y
composicin tarda, la extensin de las IDLs tradicionales, etc. [Szyperski, 1998].
Una de las principales ventajas del desarrollo de software basado en componentes se
basa en la reutilizacin de los mismos. De esta forma, los componentes se disean y
desarrollan con el objetivo de poder ser reutilizados en otras aplicaciones, reduciendo el
tiempo de desarrollo, mejorando la fiabilidad del producto final (al usar componentes
ya probados previamente), y siendo ms competitivos en costes. Aunque hasta ahora la
reutilizacin suele suceder principalmente a nivel interno dentro de las organizaciones,
el uso de los componentes comerciales comienza a extenderse. De esta forma se habla
de componentes COTS (Commercial-Off-The-Shelf), que han sido definidos como una
clase especial de componentes software, normalmente de grano grueso, que presentan
las siguientes caractersticas [Bass et al., 1999]:
Son vendidos o licenciados al pblico en general
Los mantiene y actualiza el propio vendedor, quien conserva los derechos de la
propiedad intelectual
Estn disponibles en forma de mltiples copias, todas idnticas entre s
Su cdigo no puede ser modificado por el usuario

La cada vez mayor disponibilidad y uso de este tipo de componentes est impulsando
notablemente la creacin de un mercado global de componentes COTS, que est
pasando de ser la utopa de hace unos aos a una realidad cada vez ms cercana. La
tecnologa bsica de componentes comienza a estar los suficientemente madura (a
travs de plataformas de objetos distribuidos como EJB, CORBA o .NET) como para
que numerosas empresas la adopten en sus nuevos desarrollos y sistemas de
nformacin. Incluso el gobierno y el ejrcito norteamericano han anunciado su uso, y
han empezado a apostar por la utilizacin de componentes comerciales como nica va
de mantener sus costes de desarrollo y mantenimiento de software bajo control
[Sweeney et al., 2001]. Asimismo, estn empezando a proliferar las empresas que
venden con xito componentes software al mercado general, como pueden ser
componentsource, flashline, wrldcomp, etc. [Seppanen y Helander, 2001].
Por supuesto, el uso de este tipo de componentes precisa de ciertas modificaciones en
los procesos tradicionales de desarrollo de aplicaciones. En particular, los conocidos
enfoques top-down o bottom-up estn dejando paso a procesos en espiral [Nuseibeh,
2001] en donde existe una retroalimentacin continua entre los requisitos del cliente, el
diseo arquitectnico de la aplicacin, y los componentes COTS disponibles [Ncube y
Maiden, 2001].
En el DSBC, pueden identificarse varias tareas especficas para la construccin de
aplicaciones utilizando componentes COTS [Dean y Vigser, 1997]:

La bsqueda (trading) de componentes que satisfagan los requisitos impuestos

tanto por el cliente como por la arquitectura de la aplicacin
La evaluacin de los componentes candidatos para seleccionar los ms idneos;
La adaptacin y/o extensin de los componentes seleccionados para que se
ajusten a los requisitos anteriores; y
La integracin, configuracin e interconexin de dichos componentes para
construir la aplicacin final.

Es importante sealar que un factor imprescindible en todas esas tareas es la

documentacin de los componentes, pues es preciso contar con especificaciones
completas, concisas y precisas de los componentes para poder llevarlas a cabo. La
mayora de las propuestas existentes para documentar componentes se basan en el uso
de interfaces, los cuales proporcionan un mecanismo para describir la funcionalidad de
los componentes. Sin embargo, los lenguajes de descripcin de interfaces (IDLs)
existentes permiten documentar slo los aspectos sintcticos (o estticos) de dicha
funcionalidad, sin tratar otros aspectos de vital importancia como son los protocolos de
acceso a los servicios, el comportamiento de los mtodos, o la semntica de las
operaciones de los componentes [Vallecillo et al., 1999].
Por supuesto, dichos IDLs tampoco permiten tratar los aspectos extra-funcionales de
los componentes, como la fiabilidad, la seguridad, o las prestaciones [Chung et al.,
2000; Rosa et al., 2001].
Respecto a los problemas de trading, lo que nos encontramos es que solo existen
propuestas para la bsqueda de objetos dentro de ciertos modelos (como RM-ODP) o

plataformas (CORBA). Sin embargo, son demasiado bsicas y simplistas como para
poder ser utilizadas a nivel de componentes COTS (una descripcin detallada de los
problemas que plantean las propuestas tradicionales puede encontrarse en [Iribarne et
al., 2001a]). En este sentido, comienzan a aparecer traders especficos de componentes,
como por ejemplo el denominado COTStrader (www.cotstrader.com). Dicho trader
permite buscar y seleccionar componentes partir de la definicin en plantillas XML de
su funcionalidad y otras propiedades de calidad [Iribarne et al., 2001a; Iribarne et al.,
2001b].
La segunda tarea se centra en los procesos y herramientas para la evaluacin y seleccin
de componentes COTS. Aparte de tener en cuenta los requisitos funcionales de la
aplicacin, es necesario considerar otros factores que tambin intervienen a la hora de
seleccionar componentes. El problema es que este tipo de requisitos, denominados
extra-funcionales son difciles de evaluar, aunque todos somos conscientes de la
importancia que representan.
Este tipo de factores priman muchas veces incluso ms que los funcionales, pues un
diseador hasta es capaz de adaptar la arquitectura de un sistema para poder incluir un
componente que se desea que est, o bien para evitar la presencia de un componente de
un fabricante en el cual 5 no se confa. En la introduccin ya mencionamos algunas de
las causas que intervienen en esa omisin de la valoracin en los requisitos extrafuncionales: la no existencia de una definicin consensuada de las caractersticas o
atributos de calidad que hay que medir, la situacin de revisin actual de los estndares
internacionales relativos a la calidad del producto software (fundamentalmente las
normas ISO-9126 e ISO-14598), y la ausencia casi total de mtricas que pudieran dar
una estimacin ms objetiva de estos atributos [Sedigh et al., 2001].
Adems, es importante sealar que los estndares internacionales proporcionan guas y
modelos de calidad para temas muy generales, pero no suelen estar pensados para
ofrecer soluciones en temas muy concretos. Igual les sucede a los procesos de seleccin
de productos software, que suelen ser demasiado genricos para tratar de forma efectiva
con la problemtica particular de los componentes COTS [Lawlis et al., 2001].
Una vez seleccionados los componentes candidatos, normalmente es preciso realizar
una adaptacin y/o extensin de los mismos a la hora de integrarlos. En general, al
tratar de combinar los componentes suelen aparecer tres tipos de problemas tpicos de
los ambientes COTS: las lagunas (gaps), los solapamientos (overlappings), y la
incompatibilidad de interfaces (mismatches). Los dos primeros aparecen al unir todos
los componentes, pues podemos descubrir que alguno de los servicios requeridos por la
arquitectura de la aplicacin no est cubierto por ninguno de los componentes
seleccionados, o bien que algunos componentes ofrecen servicios que se solapan
parcialmente. El problema del emparejamiento es de naturaleza distinta, pues surge al
tratar de emparejar o conectar componentes cuyas interfaces no son compatibles, y que
por tanto deben ser adaptadas como paso previo a su conexin [Garlan et al., 1995].
A pesar de estos problemas, los beneficios que proporciona el DSBC est extendiendo
su uso en entornos industriales de desarrollo de software, sobre todo en cuanto a

reduccin de esfuerzos y costes de desarrollo y mantenimiento, y a la mejora de la

calidad final de los productos y sistemas construidos. Esta extensin de su uso est
favoreciendo la aparicin de numerosas metodologas y herramientas de desarrollo para
realizar un efectivo DSBC. Sin embargo, esta disciplina dista an de ser una verdadera
ingeniera, pues an no se dispone ni de mtricas adecuadas, ni de procesos precisos,
ni de normativa internacional que la regule.
En este sentido, la definicin de mtricas de calidad para componentes y aplicaciones
software, especialmente las desarrolladas en base a componentes COTS, aparece como
una necesidad imperiosa.
2.2. MODELO XP (XTREME PROGRAMMING) PARA DESARROLLO DE
PROYECTO
2.2.1. INTRODUCCIN
Los mtodos giles surgen en un momento o contexto definido en donde es necesario
una renovacin metodolgica que busca satisfacer la necesidad de realizar los proyectos
de una forma rpida sin disminuir la calidad del mismo, pero, s reducir la
documentacin, pasos, procesos y tiempo.
Las metodologas giles son sin duda uno de los temas recientes en Ingeniera de
Software que estn acaparando gran inters.
2.2.2. HISTORIA
En 1989, Cunningham form un equipo que usaba los principios y muchas de las
prcticas que despus adoptara XP, mientras trabajaba para la compaa Wyatt
Software [Fowler 2000].Sin embargo, se reconoce a Kent Beck como el que articul
esta propuesta y le dio nombre propio.
Posteriormente, la consolidacin de XP se logra con la publicacin del libro Extreme
Programming Explained: embrace change en el ao 1999, donde Beck resume su
propia experiencia y le da forma y nombre a la entonces nueva metodologa de
desarrollo de software, la cual le vali el premio: Software Development Jolt Product
Excellence.
Las cuatro variables de Gestin de proyecto ver Anexo 1

Chrysler Corporation haca tiempo que estaba desarrollando una aplicacin de nminas,
pero sin demasiado xito por parte de la gente que tena en el proyecto. El verano de
1996, Beck entr en nmina en la compaa y se le pidi de hacer esta aplicacin como
trabajo. Es en esta aplicacin cuando nace la Programacin Extrema como tal.

Las ideas primordiales de su sistema las comunic en la revista C++ Magazine en una
entrevista que sta le hizo el ao 1999. En sta deca que l estaba convencido que la
mejor metodologa era un proceso:

Que enfatizase la comunicacin del equipo.

Que la implementacin fuera sencilla.
Que el usuario tena que estar muy informado e implicado.
Que la toma de decisiones tena que ser muy rpida y efectiva.

Los autores de la Programacin Extrema, crearon el sitio web Portland Pattern

Repository y empezaron a hablar de ella y promocionarla, de lo que era y cmo
realizarla. Estos propulsores de la XP hablaban de ella en cada ocasin que tenan y en
cada pgina que, poco o mucho hablara de temas de programacin.

2.2.3. CARACTERISTICAS DE XP
En XP se trabaja estrechamente con el cliente, se hace pequeas iteraciones cada dos
semanas, donde no existe ms documentacin que el cdigo en s; cada versin contiene
las modificaciones necesarias segn como el cliente vaya retroalimentando al sistema,
por eso es necesaria la disponibilidad del cliente durante el desarrollo.
XP utiliza Historias de Usuarios, es una frase que representa a una funcin que realizar
el sistema. Cada Historia de Usuario no puede demorar en desarrollarse ms de una
semana, si as lo requiere, debe de segmentarse.
Tambin es un requisito en XP definir un Estndar en el Tipo de Codificacin, lo cual
le permite a los programadores tener definido un slo estilo al momento de programar.
Los programadores trabajan en parejas intercambindose en el tipeo, esta forma de
trabajo tiene ventajas como:

Detecta fcilmente los errores de programacin, uno de los programador que est
visualizando controla al que tipea
El programador poco experimentado aprende del que ms lo est.
El Testing en cada iteracin se realiza para corregir mientras se programa. De esta
forma se va cubriendo las deficiencias que cada versin padezca.
El cdigo existente puede ser manipulado por todo el equipo de trabajo, de esta
manera los programadores en parejas pueden mejorar cada seccin de cdigo que
utilicen, esto requiere de un Testing (Pruebas) del mismo y la re-implementacin en
el sistema general.
Cada dos semanas se le entrega al cliente una versin, el cual lo verifica, realiza el
Feedback (realimentacin) y se contina con el desarrollo, este ciclo contina hasta
que el sistema cumpla con las expectativas del cliente, acto que concluir el
proyecto

2.2.4. GESTIN DE REQUISITOS EN EL DESARROLLO DE SOFTWARE

La metodologa Xtreme Programming (XP) pretende que el desarrollo de un proyecto
de software sea un desarrollo gil, disciplinado y aporte soluciones sencillas.
Tiene un enfoque adaptativo en el que la planificacin del proyecto progresa a medida
que surgen cambios. Los principios de actuacin claves alrededor de los cuales se
fundamenta la metodologa XP consiste en:

Acortar los ciclos de desarrollo

Involucrar al cliente desde el principio hasta el final de cada ciclo
Las tcnicas de trabajo que proporciona XP consiguen minimizar el impacto que los
cambios suponen en un proyecto de desarrollo de Software.
Acortar los ciclos de desarrollo y reforzar la comunicacin con el cliente permiten:
Centrarse cada vez en un problema muy concreto y en el momento justo
Solucionarlo de manera consensuada, inmediata y no arrastrarlo a lo largo del
proyecto
Comenzar cada nuevo ciclo de desarrollo sobre una versin intermedia contrastada,
verificada y aceptada por el cliente

2.2.5. ROLES Y RESPONSABILIDADES EN XP

Existen diferentes roles (actores) y responsabilidades en XP para diferentes tareas y

propsitos durante el proceso:

Programador (Programmer)
Responsable de decisiones tcnicas
Responsable de construir el sistema
Sin distincin entre analista, diseadores o codificadores
En XP los programadores disean, programan y realizan las pruebas

Cliente (Customer)
Es parte del equipo
Determina que construir y cundo
Escribe test funcionales para determinar cundo est completo un determinado
aspecto

Entrenador (Coach)
El lder del equipo toma las decisiones importantes
Principal responsable del proceso
Tiende a estar en un segundo plano a medida que el equipo madura

Rastreador (Tracker)
Metric Man
Observar sin molestar
Conserva datos histricos

Probador (Tester)
Ayuda al cliente con las pruebas funcionales
Se asegura de que los test funcionales se ejecutan

2.2.6. CICLO DE VIDA

El ciclo de vida de XP segn una iteracin de desarrollo es el tiempo en el que se
realiza un conjunto de funciones determinadas que en XP corresponden a un
conjunto de Historias de Usuarios.
Las iteraciones son cortas ya que entre mas rpido se le entreguen los desarrollos al
cliente mucha mas retroalimentacin se va a obtener, lo cual significa una mejor
calidad del producto a largo plazo. Existe un nivel de anlisis inicial orientado a
programar las iteraciones de desarrollo y cada iteracin incluye, diseo, codificacin
y pruebas.
Fase que se subdivide el ciclo de vida de XP ver Anexo 2

Fase de Exploracin.-en esta fase la Historia de Usuarios es de gran inters para la

primera entrega del producto, lo que permite al equipo de desarrollo familiarizarse
con las herramientas, tecnologas y prcticas que se utilizara en el proyecto.
Se construye un prototipo que pruebe las tecnologas y explore las posibilidades de
la arquitectura del sistema. La fase de exploracin se toma semanas o meses
dependiendo del tamao y familiaridad que tengan los programadores con la
tecnologa.

Fase de Planeamiento.-los programadores consideran el esfuerzo que requiere cada

historia y a partir de all se define el cronograma. Para el primer release (liberacin),
la duracin del cronograma no excede ms de dos meses, se toma en cuenta varias
iteraciones para lograr un release. La primera iteracin crea un sistema con la
arquitectura del sistema completo, esto se har seleccionando las historias que harn
cumplir la construccin de la estructura para el sistema completo. Las historias
sern seleccionadas por el cliente para cada iteracin, al final de la ltima iteracin
el sistema estar listo para la produccin.

Fase de Produccin.-requiere prueba y comprobacin extra del funcionamiento del

sistema antes de que esta pueda liberar al cliente. Durante esta fase, las iteraciones
pueden ser aceleradas de una a tres semanas, las ideas y las sugerencias que se
pospongan se documentan para una puesta en prctica posterior, por ejemplo en la
fase de mantenimiento.

Fase de Mantenimiento.-requiere de un mayor esfuerzo para satisfacer las tareas

del cliente. As la velocidad del desarrollo puede desacelerar despus de que el

sistema est en la produccin. La fase de mantenimiento puede requerir la

incorporacin de nueva gente y cambiar la estructura del equipo.

2.2.7. VALORES EN XP

XP se basa en cuatro valores, que deben estar presentes en el equipo de desarrollo para
que el proyecto tenga xito

Comunicacin.-uno de los problemas que existen en los proyectos de software es la

falta de comunicacin entre los miembros del equipo, la comunicacin es
fundamental dentro del equipo ya que la documentacin es escasa y siempre va ha
prevalecer un dilogo frontal, cara a cara entre desarrolladores, gerentes y cliente
los cuales son los medios bsicos de comunicacin, y para desarrollar un producto
de manera eficiente y satisfactoria es necesario que exista un alto nivel de
comunicacin entre los miembros del equipo.

Retroalimentacin.-el cliente brinda retroalimentacin a las funciones

desarrolladas e incluyen sus comentarios en la prxima iteracin para una mejor
comprensin de sus necesidades, la retroalimentacin constante y el
involucramiento por parte del cliente garantizan un alto grado de satisfaccin en el
cliente.

Simplicidad.-siempre se debe mantener las cosas ms simples mientras nos

apegamos al proceso que nos lleva a cumplir con los requerimientos del sistema que
se esta construyendo.

Coraje.- los desarrolladores involucrados deben de tener la actitud necesaria para

lograr un cambio y alcanzar resultados de alta calidad, sin importar cuanto tiempo
se ha invertido previamente en el mismo.

2.2.8. DIFERENCIAS
PROGRAMMING

FUNDAMENTALES

DE

EXTREME

No hay requisitos explcitos sino que el cliente participa en el desarrollo

Se empieza por automatizar las pruebas
Se desarrolla siempre la versin ms simple posible que resuelva el problema
Se ejecutan todas las pruebas todos los das
Se cambia el diseo (aunque sea radicalmente) siempre que haga falta

3. PLANIFICACION
Planificacin de la entrega de proyecto ver Anexo 3

3.1. AMBITO

El siguiente software trata de resolver un problema muy frecuente en el mbito de la

informtica, el cual es la reutilizacin de cdigo para el desarrollo rpido de
aplicaciones, observando dicho comportamiento vemos la utilidad de crear un
componente para la realizacin de gestin de usuario, asignacin de privilegios y
bitcora, para un sistema de informacin.

3.2. PRIORIDAD

Primeramente debemos realizar el componente partiendo de subcomponentes, los cuales

serian la gestin de usuario, asignacin de privilegio y despus la bitcora.
Gestin de usuario.- Para este componente se necesita cargar los usuarios y los
grupos adems de crear un sper-usuario que se encuentra por default.
Bitcora.- Para este componente necesitamos capturar los eventos de ciertos
elementos y gurdalos.
Asignacin de Privilegios.- Para este componente primero tengo que ver la forma de
cargar los componentes de los formularios del Sistema de Informacin y
descomponer en los elementos que contengan y asociarlos con un grupo de usuarios
especficos para asignar privilegios de cada elementos.

3.3. METAFORA

En los programas hay funciones que se repiten, y la empresa trata de reutilizar

cdigos para la mejora de la productividad, la empresa para este propsito
identifica componentes que hacen tareas comunes en un Sistema de Informacin
que por lo general es la gestin de usuario, la asignacin de privilegios, y el
registro de los procesos que realiza un usuario en el sistema (Bitcora).
Con el manejo de este componente los paquetes de gestin de usuario asignacin
de privilegios y bitcora, ya estaran implementados y simplemente el programador
llamaran a los mtodos de la librera que vamos a implementar.

3.4. HISTORIAS DE USUARIO

Historia de Usuario

Nmero: 1

Nombre: Gestin de Usuario

Usuario: Autor Miguel Angel Ardaya Cabello

Modificacin de Historia Nmero: --

Iteracin Asignada: 1

Prioridad en Negocio: Alta

(Alta / Media / Baja)

Puntos Estimados: --

Riesgo en Desarrollo: Medio

(Alto / Medio / Bajo)

Puntos Reales: --

Descripcin:
Se introduce los datos para la creacin de grupos (Cdigo, Descripcin), ya que los usuarios se
encuentran ordenados por grupos del usuario. Seguidamente se procede a crear usuarios introduciendo
los datos correspondientes (Login, Pasword, Grupo).

Observaciones:
La informacin que administra el componente solo debe ser reconocida por el, y nicamente
puede ser vista por el componente.

Historia de Usuario

Nmero: 2

Nombre: Bitacora

Usuario: Autor Miguel Angel Ardaya Cabello

Modificacin de Historia Nmero: --

Iteracin Asignada: 1

Prioridad en Negocio: Alta

(Alta / Media / Baja)

Puntos Estimados: --

Riesgo en Desarrollo: Medio

(Alto / Medio / Bajo)

Puntos Reales: --

Descripcin:
El componente tiene que tener la capacidad de almacenar un registro de las acciones del usuario sobre el
sistema, adems de devolver los datos q han sido guardados.
Observaciones:
La informacin que administra el componente solo debe ser reconocida por el, y nicamente
puede ser vista por el componente.

4. DISEO SIMPLE
4.1. MODELO DE CLASE
4.1.1. Gestion de Usuario

class Gest. Usuario

interface
SQLQuery

DBConnection
JFrame
ActionListener

connection: Connection = null

statement: Statement = null
url: String = ""

+
+
+
+
+
+
+
+
+

close() : void
DBConnection(String)
delete(SQLPersist) : int
getAll(SQLQuery) : ResultSet
getByID(SQLQuery) : ResultSet
insert(SQLPersist) : int
main(String[]) : void
open() : void
update(SQLPersist) : int

interface
SQLPersist

+ toGetAll() : String
+ toGetByID() : String

+ toDelete() : String
+ toInsert() : String
+ toUpdate() : String

JUserGroupFrame
-

btDelete: JButton
btFirst: JButton
btInsert: JButton
btLast: JButton
btList: JButton
btNext: JButton
btPrevious: JButton
btReset: JButton
btUpdate: JButton
lbCode: JLabel
lbDescription: JLabel
pnFields: JPanel
pnNavigation: JPanel
pnOperations: JPanel
serialVersionUID: long = 1L {readOnly}
tfCode: JTextField
tfDescription: JTextField
-userGroup
ugVector: Vector<DUserGroup> = null
ugVectorCursor: int = 0
userGroup: BUserGroup = null
-

+
+
+
-

actionPerformed(ActionEvent) : void
JUserGroupFrame()
loadComponents(Container) : void
main(String[]) : void
prepareFieldsPanel() : void
prepareNavigationPanel() : void
prepareOperationsPanel() : void
prepareUI() : void

+
+
+
+
+
+
+

DUser

+connection

BUserGroup
connection: DBConnection = new DBConnectio...
BUserGroup()
deleteUserGroup(DUserGroup) : void
getUserGroupAllToVector(DUserGroup) : Vector<DUserGroup>
getUserGroupByIDToObject(DUserGroup) : DUserGroup
insertUserGroup(DUserGroup) : void
main(String[]) : void
updateUserGroup(DUserGroup) : void

codGroup: String
login: String
password: String

+
+
+
+
+
+
+
+
+
+
+
+
+

DUser(String, String, String)

getCodGroup() : String
getLogin() : String
getPassword() : String
main(String[]) : void
setCodGroup(String) : void
setLogin(String) : void
setPassword(String) : void
toDelete() : String
toGetAll() : String
toGetByID() : String
toInsert() : String
toUpdate() : String

DUserGroup
-

code: String
description: String

+
+
+
+
+
+
+
+
+
+
+

DUserGroup(String, String)
getCode() : String
getDescription() : String
main(String[]) : void
setCode(String) : void
setDescription(String) : void
toDelete() : String
toGetAll() : String
toGetByID() : String
toInsert() : String
toUpdate() : String

4.1.2. Bitacora

class Bitacora
JFrame
PBitacora
CConexion
-

cnx: Connection = null

sta: Statement = null
url: String = ""

+
+
+
+
+
+
+
+
+
+

CConexion(String)
close() : void
delete(SQLPersist) : int
getAll(SQLQuery) : ResultSet
getByTabla(SQLQuery) : ResultSet
getByTipo(SQLQuery) : ResultSet
insert(SQLPersist) : int
main(String[]) : void
open() : void
update(SQLPersist) : int

interface
SQLPersist

interface
SQLQuery

+ toDelete() : String
+ toInsert() : String
+ toUpdate() : String

+ toGetAll() : String
+ toGetByTabla() : String
+ toGetByTipo() : String

-cnx

SQLQuery
DBitacora
-

descModificacion: String
fecha: Date
nombreTabla: String
tipoModificacion: String
usuario: String

GBitacora
+bitacora +
+
+
+
+
GBitacora()
+
getAllBitacora() : LinkedList<Vector>
+
getBitacora() : GBitacora
+
getBitacoraXusuario(String) : LinkedList<Vector>
+
getUserGroupAllToVector(DBitacora) : Vector<DBitacora>
+
getUsuario() : String
+
guardarBitacora(String, String, String) : void
+
main(String[]) : void
+
setUsuario(String) : void
+
+
+
+
+
+
+
+

+ bitacora: GBitacora = new GBitacora()

- cnx: CConexion = new CConexion("...
- usuario: String
+
+
+
+
+
+
+
+

DBitacora()
DBitacora(String)
DBitacora(String, String, String, String)
DBitacora(String, String, String, String, Date)
getDescModificacion() : String
getFecha() : Date
getNombreTabla() : String
getTipoModificacion() : String
getUsuario() : String
main(String[]) : void
setDescModificacion(String) : void
setFecha(Date) : void
setNombreTabla(String) : void
setTipoModificacion(String) : void
setUsuario(String) : void
toDelete() : String
toGetAll() : String
toGetByTabla() : String
toGetByTipo() : String
toInsert() : String
toUpdate() : String

btnMostrar: JButton = new JButton()

btnSalir: JButton = new JButton()
ftfAccion: JFormattedTextField = new JFormattedT...
ftfUsuario: JFormattedTextField = new JFormattedT...
jLabel1: JLabel = new JLabel()
jLabel3: JLabel = new JLabel()
jLabel4: JLabel = new JLabel()
jPanel1: JPanel = new JPanel()
jScrollPane1: JScrollPane = new JScrollPane()
jSeparator1: JSeparator = new JSeparator()
jTable1: JTable = new JTable()

+
+
-

btnMostrar_actionPerformed(ActionEvent) : void
btnSalir_actionPerformed(ActionEvent) : void
jbInit() : void
main(String[]) : void
PBitacora()
this_windowClosing(WindowEvent) : void

4.2. MODELO DE DATO

4.2.1. Gestion de Usuarios

4.2.2. Bitacora

5. DESARROLLO

Tarea

Nmero tarea: 1

Nmero historia: 1

Nombre tarea: Gestion de usuario.

Tipo de tarea : Desarrollo

Desarrollo / Correccin / Mejora / Otra

Puntos estimados: --

Fecha inicio:

Fecha fin:

10/09/10

17/09/10

Programador responsable: Miguel Angel Ardaya Cabello

Descripcin:

Todo sistema es usado por n usuarios a la vez, sea por usuarios y clientes.
Cada usuario es responsable de su Login y Pasword.
Nadie debe conocer el Pasword de un usuario a parte de el mismo
El software no conoce la jerarqua de usuarios del sistema.

Tarea

Nmero tarea: 2

Nmero historia: 2

Nombre tarea: Registro de procesos realizados por un usuario en el sistema.

Tipo de tarea : Desarrollo

Desarrollo / Correccin / Mejora / Otra

Puntos estimados: --

Fecha inicio:

Fecha fin:

03/09/10

17/09/10

Programador responsable: Miguel Angel Ardaya Cabello

Descripcin:
Almacenar las acciones de los usuarios en el sistema
Obtener la informacin de las acciones registradas del usuario.

6. PRUEBAS
Caso de Prueba
Nmero Caso de Prueba: 1
Nombre Caso de Prueba: Gestin de Usuario

Descripcin:

Condiciones de ejecucin:

Nmero Historia de Usuario: 2

Entradas:

Resultado esperado:
Evaluacin: 8/10

Caso de Prueba
Nmero Caso de Prueba: 2

Nmero Historia de Usuario: 2

Nombre Caso de Prueba: Registro de procesos realizados por un usuario en el sistema.

Descripcin:

Condiciones de ejecucin:

Entradas:

Resultado esperado:
Evaluacin: 8/10

7. CONCLUSION

La programacin extrema es una forma ligera, eficiente, flexible, predecible,

cientfica y divertida de generar software.
La programacin extrema se beneficia de la existencia de un gran nmero de
herramientas de software libre que permiten aplicarla con gran productividad.
El software libre se inspira en algunas de las prcticas de la XP.
Aprovecha el tiempo de los clientes y ayuda a que un cliente se sienta integrado,
evitando que se desmoralice por no sabe como preparar pruebas de aceptacin.
El proceso de desarrollo de las pruebas ayuda al cliente a clarificar y concretar la
funcionalidad de la historia de uso y favorece la comunicacin entre el cliente y el
equipo de desarrollo.
El desarrollo de pruebas ayuda identificar y corregir fallos u omisiones en las
historias de uso.
Permite corregir errores en las ideas del cliente, por ejemplo encontrando resultados
que el cliente espera encontrar en la implementacin.
Permite identificar historias adicionales que no fueran obvias para el cliente o en las
que cliente no hubiese pensado de no enfrentarse a dicha situacin.
Garantiza la cobertura de la funcionalidad de las pruebas de aceptacin,
garantizando que no se deja ningn punto importante de la funcionalidad de una
historia de uso sin probar.

8. RECOMENDACIONES

Algunas prcticas podrn ser controversiales y hasta contraproducentes fuera de un

dominio especfico. Las metodologas giles se recomiendan. Para proyectos y
equipos pequeos.
Requerimientos cambiantes (enfoque evolutivo).
Equipo de desarrollo competente.
Cliente dispuesto a participar con el equipo.
El proceso como una manera de agilizar el Proceso Unificado, combinndolo con la
XP.

9. BIBLIOGRAFIA

http://elezeta.net/2004/08/27/extreme-programming-xp/
http://www.monografas.com/trabajos51/programacion-extrema/programacionextrema.shtml
http://www.willydev.net/descargas/masyxp.pdf
http://iie.fing.edu.uy/~josej/docs/XP%20-%20Jose%20JosKowicz.pdf
Libro Extreme Programming [ Novatec Editora - Ao 2004 ]
http://audiemangt.blogspot.com/2010/05/metodologia-agil-extreme-programming-xp.html
http://www.malvarezonline.com/serendipity/index.php?/archives/12-eXtremeProgramming.html
http://www.planetacodigo.com/wiki/glosario:extreme_programming

10. ANEXOS
Anexo 1
Interaccin entre Las cuatro variables de Gestin de proyecto

Variable

Si aumenta en exceso...

Si se reduce...

Alcance

Permite mejorar la calidad, siempre que

resuelva el problema bsico del cliente.
Tambien permite reducir plazo y coste.
La herramienta ms potente de gestin
(*)

Tiempo

Ms puede mejorar calidad y alcance, Si poco, sufrir la calidad e

pero en exceso puede daar, pues la inmediatamente detrs el alcance, el
mejor realimentacin viene del sistema tiempo y el coste.
en produccin.

Coste

Ms dinero puede engrasar el sistema, Con poco dinero ser imposible resolver
pero en exceso puede crear ms los problemas del cliente.
problemas que los que resuelve.

Calidad

Insistir en mayor calidad permite

conseguir plazos menores o hacer ms en
un tiempo dado. Efecto humano: se
trabaja mejor si se siente que se hace
un buen trabajo.

Variable terrible de control. Se puede

sacrificar para obtener ganancias a
corto, pero los costes posteriores son
enormes (humanos, de negocio y
tcnicos).

Anexo 2
Descripcin de cada fase en las que se subdivide el ciclo de vida de Extreme Programming

Anexo 3
Planificacin de la Entrega