Vous êtes sur la page 1sur 19

UNIVERSIDAD PERUANA LOS ANDES

FACULTAD DE INGENIERA
CARRERA PROFESIONAL DE INGENIERIA DE SISTEMAS Y
COMPUTACION
FICHA DEL PLAN DE PRCTICAS PRE PROFESIONALES
1. TTULO DEL TRABAJO
Anlisis, Diseo y Desarrollo de un Sistema Informtico para el Registro y Control de
Asistencia de Personal para la empresa UMI CELL PHONE E.I.R.L.
2. DATOS GENERALES
2.1. DE LA EMPRESA
RUC
- Razn Social de la Institucin o
Empresa
- Actividad Econmica
- Oficina
- Gerencia General
- Resp. del Centro de Prcticas
- Fecha de inicio
- Fecha de trmino
- Nmero de semanas
ciclo)
- Nmero de horas semanales
- Nmero total de horas

: 20541501135
: UMI CELL PHONE E.I.R.L.
: Comunicaciones
: rea de Gestin UMI CELL PHONE
: Adm. ROMERO FLORES MARIA ISABEL
: Ulises Bonifacio Mucha
: 04/04/2016
: Indefinido
: 17 Semanas (segn la duracin del presente
: Min 13 horas
: 221

2.2. DEL CENTRO DE FORMACIN PROFESIONAL


- Centro de Formacin Profesional : Universidad Peruana los Andes
- Responsable Prcticas. Pre Prof. : Ing. Vladimir Pachas Huaytan.
2.3. DEL BENEFICIARIO
- Nombres y Apellidos
- Condiciones Pactadas

: Usias Chuquillanqui Chihuan


: Prcticas Pre Profesionales ( I I )

3. DESCRIPCIN DE LA SITUACIN ACTUAL


La empresa UMI CELL PHONE E.I.R.L. es comercializadora en el rubro de las
Telecomunicaciones, es un proveedor de los productos y servicios que la empresa CLARO
ofrece a nivel nacional.

La empresa cuenta ya con 6 sedes: Sede Huancayo (sede central) con 6 tiendas distribuidas
en diferentes partes de la ciudad, Sede Chupaca con una tienda, Sede Concepcin con una
tienda, Sede la Merced-Chanchamayo, Sede Satipo y Sede Pichanaki.
UMI CELL PHONE inicio sus operaciones el 07 de mayo del 2010, la Administracin de
Recursos Humanos en UMI CELL PHONE ha visto que en los ltimos meses se ha
incrementado personal que labora en la empresa, por lo cual el gerente se ha visto
proponer una solucin a los incidentes que ocurren en dichos puntos de venta.
Es imprescindible recordar que los empleados que cada vez que se inicien las labores en los
diferentes puntos de venta es importante la puntualidad y el desempeo de sus labores en
el tiempo y horario asignados.
Por tales motivos se hace necesario un control de asistencia eficiente que permita reportar
el desempeo de los empleados y personal administrativo de dentro de su jornada de
trabajo.
La Empresa UMI CELL PHONE se encuentra ubicada en la ciudad de Huancayo, est
constituida por 11 tiendas. UMI CELL PPHONE cuenta con un colectivo de trabajadores
distribuidos en las diferentes tiendas, los cuales estn calificados y entrenados para brindar
un servicio de calidad; pues la mxima de nuestra organizacin es alcanzar la satisfaccin
total, realizndose un trabajo de evaluacin sistemtica de los servicios que se brindan con
el objetivo de la mejora continua.
4. MARCO TERICO
4.1. Grupo Amrica Mvil
Amrica Mvil es el grupo lder en el sector de telecomunicaciones mviles de
Amrica Latina y el cuarto ms grande del mundo en trminos de suscriptores
proporcionales. Opera bajo la marca Claro en 16 pases del continente: Argentina,
Brasil, Chile, Colombia, Costa Rica, Ecuador, El Salvador, Guatemala, Honduras,
Nicaragua, Panam, Paraguay, Per, Puerto Rico, Repblica Dominicana y Uruguay.
Asimismo, como parte del Grupo Amrica Mvil, se encuentran las marcas Tracfone
en Estados Unidos y Telcel en Mxico.
Desde su formacin, en setiembre del 2000, la empresa mexicana ha expandido
con xito y solidez su presencia a 18 pases del continente americano. Ha
impulsado una fuerte aceleracin en el crecimiento de suscriptores y, por
consiguiente, de penetracin en casi todos los pases donde opera.
4.2. Claro
Claro es la marca comercial con la que Amrica Mvil opera en el Per. El 10 de
mayo de 2005 Amrica Mvil adquiri una licencia PCS de 1900 MHz para ofrecer
servicios de comunicaciones personales en el Per. El 10 de agosto del mismo ao,
Amrica Mvil anunci la adquisicin del 100% de TIM Per, y el 11 de octubre
lanz "Claro" la marca que identifica sus operaciones en el pas.

Claro es el operador mvil con mayor cobertura de redes GSM (transmisin de voz
y mensajes de texto) y GPRS/EDGE/UMTS/HSDPA (transmisin de datos a alta
velocidad) en Per.
Asimismo, con la adjudicacin de la frecuencia de 850 Mhz, ha construido una
moderna red de 3,5G HSDPA (High Speed downlink packet acces) lo que nos
convirti en el primer operador mvil en el Per en lanzar comercialmente esta
nueva tecnologa. Esto nos permite brindar servicios como Internet Claro y video
llamada de Claro a Claro con una gama de modernos terminales, colocando de esta
manera a Claro dentro de los ms altos estndares mundiales.
Esta tecnologa en actualizacin constante, permite ofrecer a los clientes servicios
de avanzada en telecomunicaciones con altos niveles de calidad y seguridad. Claro
cuenta con el slido respaldo institucional del Grupo Amrica Mvil y despliega sus
mayores esfuerzos en ofrecer una inversin eficiente en el Per, cobertura de alta
calidad, servicios innovadores y una atencin de primera a sus clientes.
4.3. UMI CELL PHONE
La empresa UMI CELL PHONE E.I.R.L. es comercializadora en el rubro de las
Telecomunicaciones, es un proveedor de los productos y servicios que la empresa
CLARO ofrece a nivel nacional.
VISION
Ser reconocidos como el principal proveedor de productos y servicios que
CLARO ofrece a nivel nacional, haciendo que nuestros clientes reciban y
obtengan servicios de calidad y a su medida y lo encuentren en UMI CELL
PHONE.
MISION
Somos una empresa comercializadora en el rubro de las
telecomunicaciones, buscando presencia en la mayor cantidad de
localidades a nivel nacional que cuente con un grupo humano con altos
estndares de calidad, vocacin de servicio, rapidez y eficiencia buscando la
satisfaccin total de nuestros clientes logrando la mayor rentabilidad en el
beneficio de todos los colaboradores de la empresa.
VALORES
RESPONSABILIDAD
COMPROMISO
HONESTIDAD
RESPETO
PUNTUALIDAD

4.4. La Huella Digital


4.4.1. Caractersticas de la huella dactilar y principios de reconocimiento
Los seres humanos tenemos en los dedos una superficie rugosa la cual nos permite
tomar con facilidad objetos para evitar que se resbalen. Estas rugosidades tienen
patrones que son nicos e irrepetibles, por esta caracterstica los sistemas de
seguridad utilizan estos patrones para evitar que la identidad de alguien ms se
pueda ser usada. La huella dactilar es la impresin visible que dejan estas
rugosidades sobre alguna superficie.
Las caractersticas de estos patrones de reconocimiento se clasifican en dos:
caractersticas globales y caractersticas locales.
Las caractersticas globales en las huellas dactilares son aquellas que se pueden
observar a simple vista, mientras que las caractersticas locales son llamadas puntos
de minucia.
4.4.2. Caractersticas globales
Estas caractersticas incluyen
rea patrn
Delta
El rea de patrn es la parte de la huella digital que contiene las caractersticas
globales. Las huellas digitales se leen y se clasifican de acuerdo a la informacin en
el rea de patrn. Ciertos puntos de minucia que se utilizan para el reconocimiento
final podran estar fuera del rea de patrn.

Figura 1 Ejemplo del rea patrn


La delta es un punto de bifurcacin abrupta o encuentro de lneas donde se pueden
formar puntos o fragmentos cortos de lnea.

Figura 2 Ejemplo de rea de patrn delta.

4.4.3. Caractersticas locales


Las caractersticas locales son conocidas como puntos de minucia. Son las
caractersticas de las crestas diminutas huellas dactilares. Su disposicin de dos
dimensiones es distintivo y se utiliza para el reconocimiento. Es posible que dos o
ms individuos para tener caractersticas globales similares, pero todava tienen
diferentes y distintivas huellas dactilares debido a las caractersticas locales, es
decir, la disposicin bidimensional de puntos de minucias, es diferente.
4.4.4. Patrn bsico de las huellas
El patrn bsico de las huellas es la forma que adoptan las lneas. Puede ser en
forma de bucle, arco o espiral.

Figura 3 Patrn de bucle

Figura 4 Patrn de arco

Figura 5 Patrn de espiral

4.5. La Huella digital electrnica


Cuando esta huella dactilar es convertida en una imagen digital entonces se dice
que se tiene una huella digital. As es como pueden almacenarse las huellas para
poder usarlas en sistemas de cmputo.
4.6. Manejador de Base de Datos SQL Server
El manejador de base de datos SQL Server es un sistema de cmputo producido por
la empresa Microsoft el cual permite el almacenamiento, modificacin y obtencin
de informacin dentro de una base de datos.
Se entiende por base de datos al conjunto de datos que pertenecen a un mismo
contexto y que estn almacenados de manera ordenada para su uso futuro.
4.7. Lenguaje de Programacin C#
C# es un lenguaje de programacin orientado a objetos. C# est basado en el
lenguaje C/C++. Permite los conceptos de herencia, encapsulado y polimorfismo. Al
igual que en C/C++ el punto de entrada o inicio del programa se da en el mtodo
Main.
Cuando se ejecuta un programa desarrollado con C# el ensamblado ser ledo con
el CLR (Commom Language Runtime o Lenguaje comn de tiempo de ejecucin). Si
cumple los requisitos del CLR entonces se realiza la compilacin justo a tiempo (JIT)
para convertir el lenguaje intermedio del CLR en cdigo mquina.

4.8. Entorno de Desarrollo Visual Studio 2013


Visual Studio es un entorno de desarrollo que proporciona Microsoft para poder
crear programas compatibles con Windows. Permite crear programas para
computadora e incluso pginas de internet bajo diferentes lenguajes como Visual
Basic, C#, J#, C++ o HTML.

4.9. Sistema Biomtrico


Un sistema biomtrico es un sistema de identificacin de personas que se sirve de
la biometra informtica para condicionar el acceso a un bien a un servicio. Los
mecanismos de control automticos de acceso a bienes o servicio incluyen, adems
base de datos y sistemas fsicos como puestas de acceso controladas
electrnicamente. Los aparatos de lectura de huellas dactilares o de anlisis de voz
son ejemplos comunes de sistemas biomtricos.
Un sistema biomtrico construye un modelo con la informacin capturada y un
modelo es una aproximacin a la realidad, las huellas dactilares de un individuo les
son nicas, pero su registro biomtrico podra coincidir con el de otra persona
debido a errores en la representacin numrica de la informacin, por ejemplo.
Adems, cuando los sistemas de seguridad estn conectados a redes de cmputo
se hace posible alterar la informacin por medio de programas dainos, lo que
vulnera la seguridad.
4.10. Identidad
La identidad, lo que permite distinguir a un individuo de los dems, resulta de una
combinacin de rasgos biolgicos y sociales que les son intrnsecos.
En trminos biolgicos una persona se diferencia de sus semejantes por su
fisiologa particular y por ciertos rasgos conductuales: las huellas dactilares, los
patrones de distribucin de los vasos sanguneos en las retinas, el espectro de
frecuencia de la voz, la conformacin de la dentadura, la informacin contenida
en el cido desoxirribonucleico (ADN) , la cadencia al escribir con una
computadora y la manera de escribir a mano son ejemplos tpicos de elementos
constituyentes de la identidad biolgica de una persona. La identidad social, en
cambio, la determinan caractersticas como la historia personal y las redes de
contactos de un individuo. Aunque en una persona se entremezclan lo biolgico y
lo social, para identificarla se prefiere la identidad biolgica, porque la identidad
social es menos confiable, mas subjetiva. Una persona por ejemplo, un espa
poda asumir la historia familiar de otra (o incluso crear una historia personal
completamente ficticia); en cambio no le sera muy fcil poseer la misma
informacin gentica o imitar de manera perfecta la voz de dicha persona. Los
rasgos conductuales son en gran parte resultado de la interaccin del individuo
con su medio y en cierta manera almacenan informacin sobre la naturaleza de
dicha interaccin.
4.11. Sistema de base de datos
Un sistema de base de datos es bsicamente un sistema computarizado para
llevar registros. Es posible considerar a la propia base de datos como una especie
de armario electrnico para archivar, es decir, es un depsito a contenedor de
una coleccin de archivos de datos computarizados. Los usuarios del sistema
pueden realizar una variedad de operaciones sobre dichos archivos.

5. METODOLOGIA DE SOLUCIN
El desarrollo del aplicativo se har mediante la metodologa xp, aplicando cada fase
segn sea conveniente.
1.
Metodologa gil
A principios de la dcada del 90, surgi un enfoque que fue bastante revolucionario
para su momento ya que iba en contra de toda creencia de que mediante procesos
altamente definidos se iba a lograr obtener software en tiempo, costo y con la
requerida calidad. El enfoque fue planteado por primera vez por Martin y se dio a
conocer en la comunidad de Ingeniera de Software con el nombre de RAD o Rapid
Application Development. RAD consista en un entorno de desarrollo altamente
productivo, en el que participaban grupos pequeos de programadores utilizando
herramientas que generaban cdigo en forma automtica tomando como entradas
sintaxis de alto nivel. En general, se considera que este fue uno de los primeros hitos
en pos de la agilidad en los procesos de desarrollo.
La historia de las Metodologas giles y su apreciacin como tales en la comunidad de
la Ingeniera de Software tiene sus inicios en la creacin de una de las metodologas
utilizada como arquetipo: XP - eXtreme Programming, que nace de la mente de Kent
Beck, tomando ideas recopiladas junto a Ward Cunningham.
Durante 1996, Beck es llamado por Chrysler como asesor del proyecto Chrysler
Comprehensive Compensation (C3) payroll system. Dada la poca calidad del sistema
que se estaba desarrollando, Beck decide tirar todo el cdigo y empezar de cero
utilizando las prcticas que l haba ido definiendo a lo largo del tiempo. El sistema,
que administra la liquidacin de aproximadamente 10.000 empleados, y consiste de
2.000 clases y 30.000 mtodos, es puesto en operacin en Mayo de 1997 casi
respetando el calendario propuesto. Como consecuencia del xito de dicho proyecto,
Kent Beck dio origen a XP iniciando el movimiento de metodologas giles al que se
anexaran otras metodologas surgidas mucho antes que el propio Beck fuera
convocado por Chrysler.
Es as como que este tipo de metodologas fueron inicialmente llamadas
metodologas livianas, sin embargo, an no contaban con una aprobacin pues se le
consideraba por muchos desarrolladores como meramente intuitiva. Luego, con el
pasar de los aos, en febrero de 2001, tras una reunin celebrada en Utah-EEUU, nace
formalmente el trmino gil aplicado al desarrollo de software. En esta misma
reunin participan un grupo de 17 expertos de la industria del software, incluyendo
algunos de los creadores o impulsores de metodologas de software con el objetivo de
esbozar los valores y principios que deberan permitir a los equipos desarrollar
software rpidamente y respondiendo a los cambios que puedan surgir a lo largo del
proyecto. Se pretenda ofrecer una alternativa a los procesos de desarrollo de software
tradicionales, caracterizados por ser rgidos y dirigidos por la documentacin que se
genera en cada una de las actividades desarrolladas.
Tras esta reunin se cre The Agile Alliance, una organizacin, sin nimo de lucro,
dedicada a promover los conceptos relacionados con el desarrollo gil de software y
ayudar a las organizaciones para que adopten dichos conceptos. El punto de partida
fue el Manifiesto gil, un documento que resume la filosofa gil.
2.
DIFERENCIAS ENTRE METODOLOGIAS AGILES Y NO AGILES
La Tabla N 1 recoge esquemticamente las principales diferencias de las metodologas
giles con respecto a las tradicionales (no giles). Estas diferencias que afectan no
slo al proceso en s, sino tambin al contexto del equipo as como a su organizacin.

Tener metodologas diferentes para aplicar de acuerdo con el proyecto que se


desarrolle resulta una idea interesante. Estas metodologas pueden involucrar
prcticas tanto de metodologas giles como de metodologas tradicionales. De esta
manera podramos tener una metodologa para cada proyecto, la problemtica sera
definir cada una de las prcticas, y en el momento preciso definir parmetros para
saber cul usar.
Es importante tener en cuenta que el uso de un mtodo gil no es para todos. Sin
embargo, una de las principales ventajas de los mtodos giles es su peso inicialmente
ligero y por eso las personas que no estn acostumbradas a seguir procesos
encuentran estas metodologas bastante agradables.

3.
XP- eXtreme Programming
XP es la primera metodologa gil y la que le dio conciencia al movimiento actual de
metodologas giles. De la mano de Kent Beck, XP ha conformado un extenso grupo de
seguidores en todo el mundo, disparando una gran cantidad de libros a los que dio
comienzo el mismo Beck en. Inclusive Addison-Wesley ha creado una serie de libros
denominada The XP Series.
La imagen mental de Beck al crear XP era la de perillas en un tablero de control. Cada
perilla representaba una prctica que de su experiencia saba que trabajaba bien.
Entonces, Beck decidi girar todas las perillas al mximo para ver que ocurra. As fue
como dio inicio a XP.
XP es una metodologa gil centrada en potenciar las relaciones interpersonales como
clave para el xito en el desarrollo de software, promoviendo el trabajo en equipo,
preocupndose por el aprendizaje de los desarrolladores, y propiciando un buen clima
de trabajo. XP se basa en realimentacin continua entre el cliente y el equipo de
desarrollo, comunicacin fluida entre todos los participantes, simplicidad en las
soluciones implementadas y coraje para enfrentar los cambios. XP se define como
especialmente adecuada para proyectos con requisitos imprecisos y muy cambiantes, y
donde existe un alto riesgo tcnico. A continuacin presentaremos las caractersticas
esenciales de XP organizadas en los tres apartados siguientes: historias de usuario,
roles, proceso y prcticas.

4.
Objetivos de XP
Los objetivos de XP son muy simples: la satisfaccin del cliente. Esta metodologa trata
de dar al cliente el software que l necesita y cuando lo necesita. Por tanto, debemos
responder muy rpido a las necesidades del cliente, incluso cuando los cambios sean al
final de ciclo de la programacin.
Potenciar al mximo el trabajo en grupo. Tanto los jefes de proyecto, los clientes y
desarrolladores, son parte del equipo y estn involucrados en el desarrollo del
software.
EstablecerlasmejoresprcticasdeIngenieradeSoftwareenlosdesarrollodeproyectos.
Mejorar la productividad de los proyectos.
Garantizarla Calidad del Software desarrollando, haciendo que este supere las
expectativas del cliente.
Asumir que con cierta planificacin, codificacin y pruebas se puede decidir si se est
siguiendo un camino correcto o equivocado, evitando retroceder cuando sea
demasiado tarde.
5.
La filosofa de XP
XP es una metodologa gil para pequeos y medianos equipos, desarrollando
software cuando los requerimientos son ambiguos o rpidamente cambiantes.
A diferencia de los procesos tradicionales para desarrollar software, XP asume el
cambio como algo natural, y que, indefectiblemente, en alguna etapa de un proyecto
sucede. En XP se realiza el software que el cliente solicita y necesita, en el momento
que lo precisa, alentando a los programadores a responder a los requerimientos
cambiantes que plantea el cliente en cualquier momento. Esto es posible porque est
diseado para adaptarse en forma inmediata a los cambios, con bajos costos
asociados, en cualquier etapa del ciclo de vida. En pocas palabras, XP abraza el
cambio.
6.
Valores en XP
Para poder implementar las prcticas que presenta XP hay que conocer cules son los
valores principales que hacen a esta mitologa. Estos valores son:
Comunicacin.
Simplicidad.
Feedback.
Coraje.
7.
Coste del Cambio
Una de las suposiciones establecidas en la industria del software es que el coste de los
cambios en un programa crece exponencialmente con el tiempo. XP propone que si el
sistema que empleas hace que el coste del software aumente con el tiempo debes de
actuar de forma diferente a cmo lo haces. XP propugna que esta curva ha perdido
validez y con una combinacin de buenas prcticas de programacin y tecnologa es
posible lograr que la curva sea la contraria, por tanto se pretende conseguir esto:
Si decidimos aceptar el cambio debemos de desarrollar para basarnos en dicha curva,
pero cmo se consigue dicha curva?, no existe una forma mgica desde luego hay
varias medidas que nos ayudan a conseguirla.

Disear lo ms sencillo que sea posible, para hacer slo lo imprescindible en un


momento dado, la simplicidad del cdigo y los test continuos hace que los cambios
sean posibles tan a menudo como sea necesario.
La programacin orientada a objetos es una tecnologa clave para el mantenimiento
del software, cada mensaje a un objeto es una oportunidad de cambio sin necesidad
de cambiar el cdigo existente, esto no quiere decir que no puedas tener flexibilidad
sin programar orientado al objeto y el caso contrario que haya programas orientados a
objetos que nadie quera tocar, slo se dice que el programar orientado a objetos
reduce el costo del cambio.
En vez de tomar grandes decisiones al principio y pocas posteriormente, podemos
idear una aproximacin para desarrollar software en la que se tomen decisiones
rpidamente, pero estas decisiones apoyadas por pruebas y que te preparan para
mejorar el diseo del software cuando aprendas una mejor manera de disearlo.
He odo a muchos programadores (entre los que me incluyo) decir: Hasta que no he
terminado el programa no lo he entendido ahora lo hara con esta jerarqua y que esta
clase herede de esta otra, dejemos pues abierta la puesta a esta posibilidad.

FACES DE LA METODOLOGIA XP
1. PLANEACIN
La planeacin es la etapa inicial de todo proyecto en XP. En este punto se comienza a
interactuar con el cliente y el resto del grupo de desarrollo para descubrir los
requerimientos del sistema. En este punto se identifican el nmero y tamao de
las iteraciones al igual que se plantean ajustes necesarios a la metodologa segn
las caractersticas del proyecto.
En este apartado se tendrn en cuenta ocho elementos, los cuales son los
siguientes:

Historias De Usuario.
Velocidad Del Proyecto.
Iteraciones.
Entregas Pequeas.
Reuniones.
Roles En XP.

Traslado Del Personal.


Ajuste A XP.
1.1. Historias de usuario
Las historias de usuario son utilizadas como herramienta para dar a conocer
los requerimientos del sistema al equipo de desarrollo. Son pequeos textos en
los que el cliente describe una actividad que realizar el sistema; la redaccin de los
mismos se realiza bajo la terminologa del cliente, no del desarrollador, de forma que
sea clara y sencilla, sin profundizar en detalles.
Las historias de usuario tambin son utilizadas para estimar el tiempo que el
equipo de desarrollo tomar para realizar las entregas. En una entrega se
puede desarrollar una o varias historias de usuario, esto depende del tiempo que
demore la implementacin de cada una de las mismas.
1.2. Velocidad del proyecto
Es una medida de la capacidad que tiene el equipo de desarrollo para evacuar las
historias de usuario en una determinada iteracin. Esta medida se calcula totalizando
el nmero de historias de usuario realizadas en una iteracin. Para la iteracin
siguiente se podr (tericamente) implementar el mismo nmero de historias
de usuario que en la iteracin anterior.
Cabe recordar que la velocidad del proyecto ayuda a determinar la cantidad de
historias que se pueden implementar en las siguientes iteraciones, aunque no
de manera exacta.
1.3. Iteraciones
Por lo general, los proyectos constan de ms de tres etapas, las cuales toman el
nombre de iteraciones, de all se obtiene el concepto de metodologa iterativa.
Para cada iteracin se define un mdulo o conjunto de historias que se van a
implementar. Al final de la iteracin se obtiene como resultado la entrega del mdulo
correspondiente, el cual debe haber superado las pruebas de aceptacin que
establece el cliente para la verificar el cumplimiento de los requisitos. Las tareas
que no se realicen en una iteracin son tomadas en cuenta para la prxima
iteracin, donde se define, junto al cliente, si se deben realizar o si deben ser
removidas de la planeacin del sistema.
1.4. Entregas pequeas
La duracin de una iteracin vara entre una y tres semanas, al final de la cual habr
una entrega de los avances del producto, los cuales debern ser
completamente funcionales. Estas entregas deben caracterizarse por ser frecuentes.
1.5. Reuniones
El planeamiento es esencial para cualquier tipo de metodologa, es por ello que XP
requiere de una revisin continua del plan de trabajo. A pesar de ser una
metodologa que evita la documentacin exagerada, es muy estricta en la
organizacin del trabajo.

1.6. Roles en XP
El jefe de proyecto tiene como responsabilidad la direccin y organizacin de las
reuniones que se realizan durante el proyecto.
El usuario o cliente determina qu se va a construir en el sistema,
adems de decidir el orden en que se entregarn cada segmento del proyecto.
En el grupo de los programadores se encuentran adems los diseadores y los
analistas. Los programadores son quienes construyen el sistema y realizan las
pruebas correspondientes a cada mdulo o unidad de cdigo.
El tester o quien realiza las pruebas, colabora en la realizacin de las pruebas de
aceptacin y es quien muestra los resultados de las mismas.
El rastreador (tracker) tiene como tarea observar la realizacin del
sistema. Varias veces por semana cuestiona a los integrantes del equipo
para anotar sus logros y avances.
1.7. Traslado del personal
Al mover el personal se evitan problemas relacionados con la prdida de
conocimiento y cuellos de botella. En la medida que todos los programadores
entienden todas las partes del programa se evita que unos tengan una carga de
trabajo muy alta mientras que otros no tengan mucho trabajo por hacer.
La programacin en parejas se convierte en una herramienta muy importante para
lograr el objetivo del traslado de personal sin que se pierda el rendimiento.

Figura 2: rotacin de parejas.

1.8. Ajuste a XP
Todos los proyectos tienen caractersticas especficas por lo cual XP puede ser
modificado para ajustarse bien al proyecto en cuestin. Al iniciar el proyecto se
debe aplicar XP tal como es, sin embargo no se debe dudar en modificar aquellos
aspectos en que no funcione. Eso no quiere decir que los desarrolladores pueden
hacer lo que se les antoje. Antes de implementarse un cambio, este debe ser
discutido y aprobado por el grupo.
2. DISEO
En XP solo se disean aquellas historias de usuario que el cliente ha seleccionado para la
iteracin actual por dos motivos: por un lado se considera que no es posible tener un
diseo completo del sistema y sin errores desde el principio. El segundo motivo es
que dada la naturaleza cambiante del proyecto, el hacer un diseo muy extenso en las

fases iniciales el proyecto para luego modificarlo, se considera un desperdicio de


tiempo.
Los aspectos que se tratarn a continuacin son:
Simplicidad En El Diseo.
Metfora Del Sistema.
Tarjetas Crc.
Spike Solution.
No Solucionar Antes De Tiempo.
Refactoring.
2.1. Simplicidad En El Diseo
Una de las partes ms importantes de la filosofa XP es la simplicidad en
todos los aspectos. Se considera que un diseo sencillo se logra ms rpido y
se implementa en menos tiempo, por lo cual esto es lo que se busca. La idea es
que se haga el diseo ms sencillo que cumpla con los requerimientos de las
historias de usuario.
2.2. Metfora Del Sistema
Es muy importante dentro del desarrollo de la metfora darle nombres adecuados a
todos los elementos del sistema constantemente, y que estos correspondan a
un sistema de nombres consistente. Esto ser de mucha utilidad en fases
posteriores del desarrollo para identificar aspectos importantes del sistema.
2.3. Tarjetas de clase, responsabilidad, colaboracin (CRC cards)
La principal funcionalidad que tienen estas, es ayudar a dejar el pensamiento
procedimental para incorporarse al enfoque orientado a objetos.
En el proceso de disear el sistema por medio de las tarjetas CRC como
mximo dos personas se ponen de pie adicionando o modificando las tarjetas,
prestando atencin a los mensajes que stas se transmiten mientras los dems
miembros del grupo que permanecen sentados, participan en la discusin
obteniendo as lo que puede considerarse un diagrama de clases preliminar.
2.4. Soluciones puntuales (Spike Solution)
Se trata de una pequea aplicacin completamente desconectada del proyecto con
la cual se intenta explorar el problema y propone una solucin potencial. Puede ser
burda y simple, siempre que brinde la informacin suficiente para enfrentar el
problema encontrado.
2.5. No Solucionar Antes De Tiempo
Los desarrolladores tienden a predecir las necesidades futuras e
implementarlas antes. Segn mediciones, esta es una prctica ineficiente,
concluyendo que tan solo el 10% de las soluciones para el futuro son utilizadas,
desperdiciando tiempo de desarrollo y complicando el diseo innecesariamente.

En XP slo se analiza lo que se desarrollar en la iteracin actual, olvidando por


completo cualquier necesidad que se pueda presentar en el futuro, lo que
supone uno de los preceptos ms radicales de la programacin extrema.
2.6. Refactorizacin (Refactoring)
La refactorizacin en el cdigo pretende conservarlo tan sencillo y fcil de
mantener como sea posible. En cada inspeccin que se encuentre alguna
redundancia, funcionalidad no necesaria o aspecto en general por corregir, se
debe rehacer esa seccin de cdigo con el fin de lograr las metas de sencillez
tanto en el cdigo en s mismo como en la lectura y mantenimiento.
3. DESARROLLO
El desarrollo es un proceso que se realiza en forma paralela con el diseo y la cual est
sujeta a varias observaciones por parte de XP consideradas controversiales por
algunos expertos tales como la rotacin de los programadores o la programacin en
parejas. A continuacin una descripcin de los siguientes temas:
Cliente Siempre Presente.
Codificar Primero La Prueba.
Integracin.
Secuencial.
Integraciones Frecuentes.
3.1. Cliente Siempre Presente
Uno de los requerimientos de XP es que el cliente est siempre disponible. No
solamente para solucionar las dudas del grupo de desarrollo, debera ser parte de
ste. En este sentido se convierte en gran ayuda al solucionar todas las dudas que
puedan surgir, especialmente cara a cara, para garantizar que lo implementado
cubre con las necesidades planteadas en las historias de usuario.
3.2. Codificar Primero La Prueba
Una de las ventajas de crear una prueba antes que el cdigo es que permite
identificar los requerimientos de dicho cdigo. En otras palabras, al escribir
primero las pruebas se encuentran de una forma ms sencilla y con mayor
claridad todos los casos especiales que debe considerar el cdigo a implementar.
De esta forma el desarrollador sabr con completa certeza en qu momento ha
terminado, ya que habrn pasado todas las pruebas.
3.3. Programacin En Parejas
Cuando se trabaja en parejas se obtiene un diseo de mejor calidad y un
cdigo ms organizado y con menores errores que si se trabajase solo,
adems de la ventaja que representa contar con un compaero que ayude a
solucionar inconvenientes en tiempo de codificacin, los cuales se presentan con
mucha frecuencia.
Se recomienda que mientras un miembro de la pareja se preocupa del mtodo que
se est escribiendo el otro se ocupe de cmo encaja ste en el resto de la clase.

3.4. Integracin Secuencial


Uno de los mayores inconvenientes presentados en proyectos de software tiene
que ver con la integracin, sobre todo si todos los programadores son dueos de
todo el cdigo. Para saldar este problema han surgido muchos mecanismos,
como darle propiedad de determinadas clases a algunos desarrolladores, los
cuales son los responsables de mantenerlas actualizadas y consistentes. Sin
embargo, sumado al hecho que esto va en contra de la propiedad colectiva del
cdigo no se solucionan los problemas presentados por la comunicacin entre
clases.
3.5. Integraciones Frecuentes
Se deben hacer integraciones cada pocas horas y siempre que sea posible no
debe transcurrir ms un da entre una integracin y otra. De esta forma se
garantiza surjan problemas como que un programador trabaje sobre versiones
obsoletas de alguna clase.
Es evidente que entre ms se tarde en encontrar un problema ms costoso ser
resolverlo y con la integracin frecuente se garantiza que dichos problemas se
encuentre ms rpido o an mejor, sean evitados por completo.
4. PRUEBAS
Del buen uso de las pruebas depende el xito de otras prcticas, tales como la
propiedad colectiva del cdigo y la refactorizacin. Cuando se tienen bien
implementadas las pruebas no habr temor de modificar el cdigo del otro programador
en el sentido que si se daa alguna seccin, las pruebas mostrarn el error y permitirn
encontrarlo. Uno de los elementos que podra obstaculizar que un programador
cambie una seccin de cdigo funcional es precisamente hacer que esta deje de
funcionar. Si se tiene un grupo de pruebas que garantice su buen funcionamiento, este
temor se mitiga en gran medida.
Segn XP se debe ser muy estricto con las pruebas. Slo se deber liberar una
nueva versin si esta ha pasado con el cien por ciento de la totalidad de las
pruebas. En caso contrario se emplear el resultado de estas para identificar el
error y solucionarlo con mecanismos ya definidos.
4.1. Pruebas Unitarias
Estas pruebas se aplican a todos los mtodos no triviales de todas las clases del
proyecto con la condicin que no se liberar ninguna clase que no tenga asociada
su correspondiente paquete de pruebas. Uno de los elementos ms
importantes en estas es que idealmente deben ser construidas antes que los
mtodos mismos, permitindole al programador tener mxima claridad sobre lo
que va a programar antes de hacerlo, as como conocer cada uno de los casos de
prueba que deber pasar, lo que optimizar su trabajo y su cdigo ser de mejor
calidad.

4.2. Pruebas de Aceptacin


Las pruebas de aceptacin, tambin llamadas pruebas funcionales son
supervisadas por el cliente basndose en los requerimientos tomados de las
historias de usuario. En todas las iteraciones, cada una de las historias de usuario
seleccionadas por el cliente deber tener una o ms pruebas de aceptacin, de las
cuales debern determinar los casos de prueba e identificar los errores que sern
corregidos.
Las pruebas de aceptacin son pruebas de caja negra, que representan un
resultado esperado de determinada transaccin con el sistema.
4.3. Cuando se Encuentra un Error
Al momento de encontrar un error debe escribirse una prueba antes de intentar
corregirlo. De esta forma tanto el cliente lograr tener completamente claro
cul fue y dnde se encontraba el mismo como el equipo de desarrollo podr
enfocar mejor sus esfuerzos para solucionarlo. Por otro lado se lograr evitar
volver a cometerlo.

6. CRONOGRAMA DE ACTIVIDADES
Diagrama en el MS Proyect

7. BIBLIOGRAFA
PRESSMAN, Roger. Ingeniera de Software: un enfoque prctico. Mexico: 2002.
PROYECT MANAGEMENT INSTITUTE (PMI). Guia de los fundamentos de la direccin de
Proyectos. Pensilvania: 2008.
8. WEB
http://technet.microsoft.com/es-es/library/ms143506(v=sql.105).aspx
www.mercadolibre.com.mx
www.digitalpersona.com
Manual de lector U4500 de digital persona

http://www.visualstudio.com/es-es/visual-studio-homepage-vs.aspx
Como programar C# segunda edicin. Deitel Deitel 2005.

__________________________
Usias Chuquillanqui Chihuan
Practicante

_____________________________
Ing. Vladimir Pachas Huaytan
Resp. Prcticas Pre Profesionales

__________________________
Ulises F. Bonifacio Mucha
Resp. Centro de Prcticas UMI CELL PHONE

Vous aimerez peut-être aussi