1. CAPITULO I.

ASPECTOS GENERALES

1.1. INTRODUCCI�N.

El control de nivel de l�quido es un problema b�sico y general que se presentan en

los procesos industriales ya que com�nmente se lo realiza de forma anal�gica, es
decir de manera manual como: el control de llenado de tanque, verificaci�n de los
estados de los tanques, abrir y cerrar las llaves. Debido a que la mayor�a de los
procesos industriales requieren el control de flujos de l�quidos para que sean
procesados autom�ticamente con poca intervenci�n externa o humana, teniendo en
cuenta las pol�ticas mundiales de la de preservar el agua como un elemento de
fundamental vitalidad ya sea para industrias o uso dom�stico, es por esto que se
precisa un sistema que sea capaz de cubrir las necesidades b�sicas en el hogar como
en las industrias.

Es por eso que nuestro sistema de control de l�quido est� orientado a solucionar
esos problemas b�sicos que tienen las plantas de tratamiento de agua, realizando
los diferentes procesos como de llenado, vaciado, verificaci�n de estado de los
tanques y el abierto y cerrado de los grifos de forma �automatizada�. Por ello, en
el caso de nuestro sistema actual, este se presenta como un Control de Nivel
L�quido manual, se podr�a decir anal�gico.

Es importante entender y tomar cuenta de c�mo trabajan estos sistemas en su entorno

actual, para poder construir ideas y desarrollar un sistema que cumpla con los
requerimientos del proceso, dando lugar a un Sistema de Informaci�n capaz de
controlar dichos procesos de sistema ,claro que siempre con la intervenci�n del
hombre, por lo menos para monitorizar el sistema.

Para poder, nosotros como desarrolladores de sistemas autom�ticos del sistema,

realizar este trabajo necesariamente haremos uso de materiales para poder construir
el sistema, donde podemos citar aspectos como la parte l�gica que tranquilamente la
podr�amos llamar �parte de mando� y la parte f�sica que tambi�n la podemos llamar
�parte operativa�, ambos aspectos, una vez trabajados, llegaran a constituir el
sistema de informaci�n con los requerimientos que demande el sistema.

1.2. ANTECEDENTES.
Las siguientes caracter�sticas de equipos de control aut�matas est�n basados en
sistemas relacionados con el sistema de control l�quido y las ventajas que ofrecen
con respecto al control de nivel del mismo.

UNICONTROL
Los controles de nivel de UniControl, son utilizados para medir y controlar niveles
en todo tipo de recipientes contenedores de l�quidos, cerrados o abiertos, est�n o
no sometidos a presi�n y/o temperatura. Las caracter�sticas nobles de los elementos
constitutivos del transmisor en contacto con el l�quido ampl�an las posibilidades
de utilizaci�n con productos agresivos.
Estos controles se emplean principalmente en instalaciones frigor�ficas
industriales terrestres o a bordo de embarcaciones para medir niveles de
refrigerantes. En una instalaci�n frigor�fica convencional, una salida es
configurada para operar como alarma de bajo nivel, otra opera la solenoide de
l�quidos y la tercera act�a como protecci�n de nivel alto o rebalse.
Tambi�n son empleados para medir en tanques de agua limpia o tanques compensadores
de motores donde el agua se encuentra a temperaturas cercanas a los 80 �C y en
general, para cualquier l�quido limpio. Cuando se trata de efluentes o l�quidos con
s�lidos en suspensi�n, se realizan construcciones especiales de la vaina exterior
para evitar la acumulaci�n de residuos que obstruyan el libre flujo del l�quido.
Caracter�sticas constructivas
Este control de nivel ha sido dise�ado para usos m�ltiples. Las caracter�sticas de
dise�o y constructivas de la unidad de control y del transmisor, permite su
utilizaci�n en una muy variada gama de aplicaciones industriales.
La unidad de control, se encuentra alojada en un gabinete estanco IP 65 con tapa
frontal de policarbonato transparente. El panel de control est� integrado por un
indicador digital porcentual de dos d�gitos de gran tama�o ( 13,5 mm) visibles a
distancia, dos potenci�metros de ajuste por cada rel� de salida, el primero ajusta
el nivel de disparo y el segundo el diferencial (span), y un led indicador del
estado del rel�. La unidad cuenta adem�s con un simulador incorporado, que
posibilita una verificaci�n r�pida y eficaz de los niveles de disparo y reconexi�n.
Un led indicador adicional se�aliza posibles fallas internas de la unidad de
control y la rotura o desconexi�n del transmisor de nivel.
El transmisor de nivel presenta una construcci�n s�lida y sencilla. Est�
constituido por un sensor capacitivo que se sumerge en el l�quido a medir, y un
transmisor electr�nico alojado en el cabezal. El sensor es un electrodo envainado
en PTFE y una cubierta exterior, ambos construidos en acero inoxidable, lo que
permite su empleo con diversos productos, incluso l�quidos agresivos.
Adicionalmente, la ausencia de partes m�viles o circulaci�n de corriente el�ctrica
por el electrodo, garantiza un funcionamiento seguro y libre de fallas. En el
cabezal, tambi�n de acero inoxidable, se aloja un transmisor electr�nico montado en
un encapsulante flexible que lo protege de vibraciones y humedad. Como la se�al de
salida es de corriente (4...20mA), la unidad de control puede instalarse distante
de la ubicaci�n del transmisor, si las caracter�sticas de la instalaci�n as� lo
requieren, facilitando el monitoreo de niveles en tanques de dif�cil acceso.
Gen�ricamente se define como transmisor de nivel al conjunto formado por el sensor
capacitivo y el transmisor electr�nico.
Los transmisores de nivel son ensayados individualmente a una presi�n de prueba de
25 bar, mientras que la vaina de PTFE admite un rango de temperaturas entre �260 y
+ 260 �C. Cualquiera sea la temperatura a la que est� expuesto el electrodo, debe
tenerse en cuenta que el cabezal electr�nico est� limitado a una temperatura de
funcionamiento entre �10 y 70 �C.

Transmisor
partes met�licas: AISI 304
cubierta electrodo: PTFE
dimensiones: ver plano
fijaci�n: � � NPT
largo: 600/900/1200/1500/largos especiales
presi�n m�x de trabajo:
temp m�x de operaci�n del sensor: 200 �C
rango de temp. del transmisor: -10 / 70 �C
salida: 4.....20 mA
largo de cable: 3 mts

Datos t�cnicos
Unidad de Control
gabinete: policarbonato de tapa transparente
dimensiones: 270 x 180 x 107 mm
protecci�n: IP-65
alimentaci�n: 220 Vca - 50/60 Hz
(a pedido 24 Vcc)
display: dos d�gitos ��
se�al de entrada: 4....20 mA
salidas: tres rel�s Inv 10 Amp
temp amb de operaci�n: 0/50 �C

Ajuste de niveles y diferenciales

El ajuste de los niveles de actuaci�n de cada rel� se realiza de forma r�pida y
sencilla.
El frente del panel cuenta con tres pares de perillas cada uno y un pulsador,
dispuestas a tal fin.
Al oprimir el pulsador se observa el valor de ajuste efectivo de la salida
correspondiente.
Para ajustar el nivel de actuaci�n, Mantener oprimido el pulsador y mover la
perilla superior hasta
visualizar en el display el valor deseado. Luego, sin oprimir el pulsador ajustar
el diferencial con la perilla
inferior. Repetir la operaci�n para cada rel�.
Tener en cuenta que la escala de la perilla superior es de 0 a 100 %, mientras que
la inferior es
de 0 a 20 % del largo total �til del sensor.
Una vez ajustados los niveles y diferenciales se procede a la verificaci�n, que se
realiza
oprimiendo el pulsador de prueba y moviendo la perilla de prueba de 0 a 100 %. En
el display se
observar� la simulaci�n de nivel y las salidas operar�n a los niveles previamente
fijados.

Lectura del indicador

La indicaci�n del instrumento es porcentual, y por lo tanto referida al largo �til
del sensor. El largo
�til es la distancia entre los orificos de entrada y salida de l�quido en la
cubierta exterior del mismo. Esta
gcota est� indicada en la etiqueta del transmisor.
Cuando en el display aparece un punto decimal a continuaci�n del primer d�gito de
la izquierda,
significa que el nivel medido est� por debajo del cero ajustado en el sensor.
Cuando el punto aparece a continuaci�n del segundo d�gito, indica que el valor
medido est� por encima del 100 % del rango del sensor.
Cuando el instrumento detecta que la se�al recibida del sensor est� fuera del rango
de seguridad, pasa a indicar 2.4 %, equivalente a sensor roto.

CN5R

FUNCION
Mantener lleno o vac�o un tanque de agua.
Alarma de alto y bajo nivel.
Detecta los niveles de l�quido utilizando un juego de electrodos y la conductividad
del l�quido.
OPERACION
El rel� de salida es activado cuando el l�quido no moja el electrodo inferior y es
desactivado cuando el l�quido moja los electrodos inferior y superior.
OPCIONALES
Se puede emplear en l�quidos no conductores empleando sensores con flotadores.
Existen modelos para alimentaci�n en tensi�n continua.
Existen modelos con diferente sensibilidad, (menor sensibilidad tanques de leche,
mayor sensibilidad l�quidos menos conductores.
ENTRADAS
Sensores: electrodos/ flotadores.
Tensi�n: 17 Vca, aislados.
Bornes: inf, sup y masa Sensibilidad: acciona cuando la resistencia entre
electrodos es de 12.000 ohms aprox.
Distancia m�xima control-electrodos: 50m.
SALIDAS
Rel� inversor, bornes: NA, C, NC.
Capacidad de los contactos: 5A @ 220Vca.
ALIMENTACION
Tensi�n: 220 VCA +/-15%, 50/60 Hz.
Consumo: 3 VA
Bornes: 220V, 220V.

2.3 CN6_control_de transiego

FUNCION
Controla el trasiego de agua entre dos tanques.
El control de Trasiego de Tanques CN6 detecta los niveles de l�quido en dos
tanques, utilizando dos juegos de electrodos y la conductividad del l�quido.
El circuito de control es de estado s�lido , controla el funcionamiento de la bomba
de trasiego mediante un rel� de salida.
Utiliza bajas tensiones en los electrodos (17 Vca aislados de red) haciendo
inofensivo su manejo.
OPERACION
El rel� de salida es activado cuando el tanque de arriba pide agua, ( ambos
electrodes descubiertos) y el tanque de abajo tiene agua, (ambos electrodos
cubiertos)
APLICACIONES TIPICAS
- Trasiego de agua entre un tanque inferior y un tanque superior, (Edificios con
tanques en subsuelo y azotea).
- Llenado de tanque a partir de un pozo.

1.3. PLANTEAMIENTO DEL PROBLEMA.

Un hecho fundamental que ha llegado a tomar cuerpo de forma trascendental, tanto en

las politicas de gobiernos como en tratados de medio ambiente es el tratamiento
del agua y de c�mo esta puede ser llevada a un control estricto debido a su escases
y falta de conciencia en las poblaciones e incluso del como preservar tan preciado
elemento de fundamental uso, ya sea en ndustrias o uso domestico, este sistema de
control de nivel liquido en plantas de tratamiento ayudara a un control mas
estricto y dinamico colaborando de esta manera a politicas de gobierno, tratados
internacionales de politicas de medioambiente, permitiendo el uso limitado y
requerido en funcion a la necesidad por parte del usuario ahorrando e incrementando
el lapso de vida de tan preciado elemento, el sistema tambien sera un paso mas para
el desarrollo de nuevas aplicaciones y/o prototipos abarcando politicas de
medioambiente lo que hara posible nuevas plantas de tratamiento encargadas para
distsintas aplicaciones o usos que se le pueda dar, lo que impulsara desde un
aspecto social a la valoracion y educacion acerca del uso y sus aplicaciones

1.3.1. �RBOL DE PROBLEMAS

1.4. OBJETIVOS.

1.4.1. OBJETIVO GENERAL.

Dise�ar un sistema de informaci�n con interfaz de control de nivel l�quido para
garantizar, la correcta operaci�n de llenado de recipientes (tanques) en las
plantas de tratamiento, para mejorar la cantidad y la calidad en el rendimiento de
la entrega del producto final a requerimiento del usuario final.

1.4.2. OBJETIVOS ESPEC�FICOS.

Lograr abastecer las demandas mediante las plantas de tratamiento de aguas a las
diferentes empresas, zonas, familias de la poblaci�n.

Disminuir la escases de agua y contribuir a las pol�ticas mundiales sobre el medio

ambiente en la prevenci�n y derroche del agua.

Dise�ar e implementar un prototipo de interfaz electr�nica autom�tica con interfaz

con el computador mediante el protocolo de comunicaci�n usb.

Desarrollar un sistema analizador de control de nivel en tiempo real.

Controlar mediante Pantalla el control de niveles de los envases llenados con nivel
l�quido.

Generar Reportes Entrantes como salientes de los niveles l�quidos.

Controlar un motor AC con modulador de ancho de pulso (PWM).

Controlar el tiempo de llenado de cada recipiente.

1.4.3. �RBOL DE OBJETIVOS

1.5. JUSTIFICACIONES.

Debido a la falta de conciencia por parte de la poblacion, el malgasto, hasta el

uso desmedido del elemento, por parte de las empresas se realiza la implementacion
del prototipo que tendra por funcion controlar el elemento vida (agua) de manera
limitada en cuesti�n de uso en distintas �reas, trat�ndose en un promedio de uso
diario o semanal seg�n convenga en cuestiones de estudios previos ya que el sistema
estar� dise�ado de forma sensible para el control de cambios de nivel, llegando de
esta a manera a distintas areas de la poblacion, solo con la cantidad requerida por
familia o empresa para el NO derroche del agua en su uso diario, llegando a
familias en recipientes de uso domestico(tanques) para el uso de comidas y
alimentos(limitado),de otra manera para el uso de lavander�a u aseo se deber�
omitir el uso de agua potable, usando de esta manera el agua de mar previamente
tratada por parte de las empresas encargadas en tratamiento de aguas para usos no
alimenticios.

1.5.1. JUSTIFICACI�N T�CNICA.

Debido a la falta de tecnolog�a de punta en el tratamiento del agua, el prototipo

est� orientado a ser base de mejoras y de acceso al conjunto que forma los
procesos de tratamiento del agua, aplic�ndolo en distintas �reas.

1.5.2. JUSTIFICACI�N ECON�MICA.

Incrementar� el uso desmedido del agua y reducir� las tarifas de pago del servicio
b�sico en la poblaci�n.
1.5.3. JUSTIFICACI�N CIENT�FICA.

El impulso e incentivo a la exploraci�n de nuevas formas de tratamiento del agua

tanto en el �rea industrial como ecologista.

1.6. ALCANCES Y LIMITES.

1.6.1. LIMITES.

� Cumplir con todos los objetivos planteados para la implementaci�n del

proyecto as� como los requerimientos para el desarrollo del sistema.

Obtenci�n de resultados al ocurrir errores al transcurso del proceso. Determinar

Efectividad de respuesta en tiempo real. Evaluaci�n del sistema al transcurso
De cada causa que se suscite. Monitorizaci�n acorde al dise�o como al material
empleado

1.6.2. ALCANCES.

Fabricar el modelo electr�nico y mec�nico para que realice los cortes programados
analizando los costos que requerir� esta herramienta ser� capaz lograr un ingreso
al mercado de la tecnolog�a como al campo de tratamiento de aguas y la seguridad
en el �mbito industrial.
Determinar la infraestructura del sistema con un modelo control sistematizado con
una computadora interactuando con la maquinaria mediante dise�os de circuitos.
2. CAPITULO II.

FUNDAMENTO TE�RICO

2.1. INGENIER�A DE SOFTWARE.

El desarrollo de sistemas de software complejos no es una actividad trivial, que

pueda abordarse sin una preparaci�n previa. El considerar que un proyecto de
desarrollo de software pod�a abordarse como cualquier otro ha llevado a una serie
de problemas que limitan nuestra capacidad de aprovechar los recursos que el
hardware pone a nuestra disposici�n.
Los problemas tradicionales en el desarrollo de software no van a desaparecer de la
noche a la ma�ana, pero identificarlos y conocer sus causas es el �nico m�todo que
nos puede llevar hacia su soluci�n.
No existe una f�rmula m�gica para solucionar estos problemas, pero combinando
m�todos aplicables a cada una de las fases del desarrollo de software, construyendo
herramientas para automatizar estos m�todos, utilizando t�cnicas para garantizar la
calidad de los productos desarrollados y coordinando todas las personas
involucradas en el desarrollo de un proyecto, podremos avanzar mucho en la soluci�n
de estos problemas. De ello se encarga la disciplina llamada Ingenier�a del
Software.

Una de las primeras definiciones que se dio de la ingenier�a del software es la

siguiente:

Definici�n 1. El establecimiento y uso de principios de ingenier�a robustos,

orientados a obtener software econ�mico, que sea fiable y funcione de manera
eficiente sobre m�quinas reales.

Definici�n 2. [Ingenier�a de Software es] el establecimiento y uso de principios de

ingenier�a adecuados para obtener econ�micamente software que sea confiable y
trabaje eficientemente en m�quinas reales.[Fritz Bauer]
Definici�n 3. Es la disciplina tecnol�gica y administrativa dedicada a la
producci�n sistem�tica de productos de Software, que son desarrollados y
modificados a tiempo y dentro de un presupuesto definido (Fairley).
Es el enfoque sistem�tico para el desarrollo, operaci�n, mantenimiento y
eliminaci�n del Software.
Objetivo de las organizaciones fabricantes de software: producir software de buena
calidad de una manera sistem�tica y previsible.
La ingenier�a del software abarca un conjunto de tres elementos clave: m�todos,
herramientas y procedimientos, que faciliten al gestor el control el proceso de
desarrollo y suministren a los implementadores bases para construir de forma
productiva software de alta calidad.

Los m�todos indican c�mo construir t�cnicamente el software, y abarcan una amplia
serie de tareas que incluyen la planificaci�n y estimaci�n de proyectos, el
an�lisis de requisitos, el dise�o de estructuras de datos, programas y
procedimientos, la codificaci�n, las pruebas y el mantenimiento. Los m�todos
introducen frecuentemente una notaci�n espec�fica para la tarea en cuesti�n y una
serie de criterios de calidad.

Las herramientas proporcionan un soporte autom�tico o semiautom�tico para utilizar

los m�todos. Existen herramientas automatizadas para cada una de las fases vistas
anteriormente, y sistemas que integran las herramientas de cada fase de forma que
sirven para todo el proceso de desarrollo. Estas herramientas se denominan CASE
(Computer Assisted Software Engineering).
Los procedimientos definen la secuencia en que se aplican los m�todos, los
documentos que se requieren, los controles que permiten asegurar la calidad y las
directrices que permiten a los gestores evaluar los progresos.

2.1.1. APLICACIONES DEL SOFTWARE.

El software puede aplicarse a numerosas situaciones del mundo real. En primer

lugar, a todos aquellos problemas para los que se haya establecido un conjunto
espec�fico de acciones que lleven a su resoluci�n (esto es, un algoritmo). En estos
casos, utilizaremos lenguajes de programaci�n procedimentales para implementar
estos algoritmos. Tambi�n puede aplicarse a situaciones en las que el problema
puede describirse formalmente, por lo general en forma recursiva. En estos casos no
necesitamos describir el m�todo de resoluci�n, es decir c�mo se resuelve el
problema, sino que bastar� con describir en problema en s�, indicando cu�l es la
soluci�n deseada, y utilizaremos lenguajes declarativos para ello. Tambi�n puede
aplicarse a problemas que los humanos resolvemos utilizando multitud de reglas
heur�sticas posiblemente contradictorias, para lo cual utilizaremos un sistema
experto e incluso para problemas de los cuales no tenemos una idea clara de c�mo se
resuelven, pero de los que conocemos cu�l es la soluci�n apropiada para algunos
ejemplos de los datos de entrada. En este caso utilizaremos redes neuronales.
En cualquier caso, es dif�cil establecer categor�as gen�ricas significativas para
las aplicaciones del software. Conforme aumenta la complejidad del mismo se hace
m�s complicado establecer compartimentos n�tidamente separados. No obstante la
siguiente clasificaci�n ha venido acept�ndose tradicionalmente:
Software de sistemas.
Est� formado por todos aquellos programas cuya finalidad es servir al desarrollo o
al funcionamiento de otros programas. Estos programas son muy variados: editores,
compiladores, sistemas operativos, entornos gr�ficos, programas de
telecomunicaciones, etc. pero se caracterizan por estar muy pr�ximos al hardware,
por ser utilizados concurrentemente por numerosos usuarios y por tratarse de
programas de amplia difusi�n, no estando dise�ados normalmente a medida. Esto
permite un mayor esfuerzo en su dise�o y optimizaci�n, pero tambi�n les obliga a
ser muy fiables, cumpliendo estrictamente las especificaciones para las que fueron
creados.
Software de tiempo real.
Est� formado por todos aquellos programas que miden, analizan y controlan los
sucesos del mundo real a medida que ocurren, debiendo reaccionar de forma correcta
a los est�mulos de entrada en un tiempo m�ximo prefijado. Deben, por tanto, cumplir
unos requisitos temporales muy estrictos y, dado que los procesos que controlan
pueden ser potencialmente peligrosos, tienen que ser fiables y tolerantes a fallos.
Por otro lado, no suelen ser muy complejos y precisan de poca interacci�n con el
usuario.
Software de gesti�n.
El procesamiento de informaci�n de gesti�n constituye, casi desde los inicios de la
inform�tica la mayor de las �reas de aplicaci�n de los ordenadores. Estos programas
utilizan grandes cantidades de informaci�n almacenadas en bases de datos con objeto
de facilitar las transacciones comerciales o la toma de decisiones. Adem�s de las
tareas convencionales de procesamiento de datos, en las que el tiempo de
procesamiento no es cr�tico y los errores pueden ser corregidos a posteriori,
incluyen programas interactivos que sirven de soporte a transacciones comerciales.
Software cient�fico y de ingenier�a.
Otro de los campos cl�sicos de aplicaci�n de la inform�tica. Se encarga de realizar
complejos c�lculos sobre datos num�ricos de todo tipo. En este caso la correcci�n y
exactitud de las operaciones que realizan es uno de los requisitos b�sicos que
deben de cumplir.
El campo del software cient�fico y de ingenier�a se ha visto ampliado �ltimamente
con el desarrollo de los sistemas de dise�o, ingenier�a y fabricaci�n asistida por
ordenador (CAD, CAE y CAM), los simuladores gr�ficos y otras aplicaciones
interactivas que lo acercan m�s al software de tiempo real e incluso al software de
sistemas.
Software de ordenadores personales.
El uso de ordenadores personales y de uso dom�stico se ha generalizado a lo largo
de la pasada d�cada. Aplicaciones t�picas son los procesadores de textos, las hojas
de c�lculo, bases de datos, aplicaciones gr�ficas, juegos, etc. Son productos de
amplia difusi�n orientados a usuarios no profesionales, por lo que entre sus
requisitos se encuentran la facilidad de uso y el bajo coste.
Software empotrado.
Software empotrado es aquel que va instalado en otros productos industriales, como
por ejemplo la electr�nica de consumo, dotando a estos productos de un grado de
inteligencia cada vez mayor. Se aplica a todo tipo de productos, desde un v�deo
dom�stico hasta un misil con cabeza at�mica, pasando por algunos sistemas de
control de los autom�viles, y realiza funciones muy diversas, que pueden ir desde
complicados c�lculos en tiempo real a sencillas interacciones con el usuario
facilitando el manejo del aparato que los incorpora. Comparten caracter�sticas con
el software de sistemas, el software de tiempo real, el software de ingenier�a y
cient�fico y el software de ordenadores personales.
Software de inteligencia artificial.
El software basado en lenguajes procedimentales es �til para realizar de forma
r�pida y fiable operaciones que para el ser humano son tediosas e incluso
inabordables. Sin embargo, es dif�cilmente aplicable a problemas que requieran la
aplicaci�n de funciones intelectuales m�s elevadas, por triviales que nos puedan
parecer. El software de inteligencia artificial trata de dar respuesta a estas
deficiencias, bas�ndose en el uso de lenguajes declarativos, sistemas expertos y
redes neuronales.

2.2. METODOLOG�A XP (Programaci�n Extrema).

XP (eXtreme Programing) nace como nueva disciplina de desarrollo de software hace

aproximadamente unos seis a�os, y ha causado un gran revuelo entre el
colectivo de programadores del mundo. Kent Beck, su autor, es un
programador que ha trabajado en m�ltiples empresas y que actualmente lo
hace como programador en la conocida empresa automovil�stica DaimlerChrysler.
Con sus teor�as ha conseguido el respaldo de gran parte de la industria del
software y el rechazo de otra parte.

La programaci�n extrema se basa en la simplicidad, la comunicaci�n y el

reciclado continuo de c�digo, para algunos no es m�s que aplicar una pura l�gica.

XP es una metodolog�a �gil centrada en potenciar las relaciones

interpersonales como clave para el �xito en desarrollo de software, promoviendo el
trabajo en equipo, preocup�ndose por el aprendizaje de los desarrolladores, y
propiciando un buen clima de trabajo. XP se basa en realimentaci�n continua
entre el cliente y el equipo de
desarrollo, comunicaci�n 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 t�cnico.

Los principios y pr�cticas son de sentido com�n pero llevadas al

extremo, de ah� proviene su nombre. Kent Beck, el padre de XP, describe la
filosof�a de XP en sin
cubrir los detalles t�cnicos y de implantaci�n de las pr�cticas.
Posteriormente, otras publicaciones de experiencias se han encargado de
dicha tarea. A continuaci�n
presentaremos las caracter�sticas esenciales de XP organizadas en los tres
apartados siguientes: historias de usuario, roles, proceso y pr�cticas.

Roles XP.

Aunque en otras fuentes de informaci�n aparecen algunas variaciones y extensiones

de roles XP, en este apartado describiremos los roles de acuerdo con la propuesta
original de Beck.

Programador

El programador escribe las pruebas unitarias y produce el c�digo del

sistema. Debe existir una comunicaci�n y coordinaci�n adecuada entre los
programadores y otros miembros del equipo.

Cliente

El cliente escribe las historias de usuario y las pruebas funcionales

para validar su implementaci�n. Adem�s, asigna la prioridad a las historias de
usuario y decide cu�les se implementan en cada iteraci�n centr�ndose en
aportar mayor valor al negocio. El cliente es s�lo uno dentro del proyecto
pero puede corresponder a un interlocutor que est� representando a varias personas
que se ver�n afectadas por el sistema.

Encargado de pruebas (Tester)

El encargado de pruebas ayuda al cliente a escribir las pruebas funcionales.

Ejecuta las
pruebas regularmente, difunde los resultados en el equipo y es
responsable de las herramientas de soporte para pruebas.

Encargado de seguimiento (Tracker)

El encargado de seguimiento proporciona realimentaci�n al equipo en el proceso XP.

Su
responsabilidad es verificar el grado de acierto entre las estimaciones
realizadas y el tiempo real dedicado, comunicando los resultados para
mejorar futuras estimaciones.

Tambi�n realiza el seguimiento del progreso de cada iteraci�n y eval�a si los

objetivos son alcanzables con las restricciones de tiempo y recursos presentes.
Determina cu�ndo es necesario realizar alg�n cambio para lograr los objetivos de
cada iteraci�n.

Entrenador (Coach)
Es responsable del proceso global. Es necesario que conozca a fondo el proceso XP
para proveer gu�as a los miembros del equipo de forma que se apliquen las pr�cticas
XP y se siga el proceso correctamente.

Consultor

Es un miembro externo del equipo con un conocimiento espec�fico en alg�n

tema necesario para el proyecto. Gu�a al equipo para resolver un problema
espec�fico.
Gestor (Big boss)
Es el v�nculo entre clientes y programadores, ayuda a que el
equipo trabaje efectivamente creando las condiciones adecuadas. Su labor esencial
es de coordinaci�n.

2.2.1. MODELO XP.

La metodolog�a XP define cuatro variables para cualquier proyecto de

software: costo, tiempo, calidad y alcance. Adem�s, se especifica que, de
estas cuatro variables, s�lo tres de ellas podr�n ser fijadas arbitrariamente por
actores externos al grupo de desarrolladores (clientes y jefes de proyecto). El
valor de la variable restante podr� ser establecido por el equipo de
desarrollo, en funci�n de los valores de las otras tres. Este mecanismo
indica que, por ejemplo, si el cliente
establece el alcance y la calidad, y el jefe de proyecto el precio, el
grupo de desarrollo tendr� libertad para determinar el tiempo que durar� el
proyecto. Este modelo es analizado por Kent Beck, en [9], donde propone
las ventajas de un contrato con alcances opcionales.

Como se detall� en los apartados anteriores, los ciclos de vida

�tradicionales� proponen una clara distinci�n entre las etapas del proyecto de
software, y tienen un plan bien preestablecido acerca del proceso de desarrollo.
Asimismo, en todos ellos se parte de especificaciones claras, si no del total del
proyecto, por lo menos de una buena parte inicial.

El ciclo de vida de un proyecto XP incluye, al igual que las otras

metodolog�as, entender lo que el cliente necesita, estimar el esfuerzo, crear la
soluci�n y entregar el producto final al cliente. Sin embargo, XP propone
un ciclo de vida din�mico, donde se admite expresamente que, en muchos
casos, los clientes no son capaces de especificar sus requerimientos al
comienzo de un proyecto.

Por esto, se trata de realizar ciclos de desarrollo cortos (llamados iteraciones),

con entregables funcionales al finalizar cada ciclo. En cada iteraci�n se realiza
un ciclo completo de an�lisis, dise�o, desarrollo y pruebas, pero utilizando un
conjunto de reglas y pr�cticas que caracterizan a XP (y que ser�n detalladas m�s
adelante).

T�picamente un proyecto con XP lleva 10 a 15 ciclos o iteraciones. La

siguiente figura [10] esquematiza los ciclos de desarrollo en
cascada e iterativos tradicionales (por ejemplo, incremental o espiral),
comparados con el de XP.

2.2.2. CICLO DE VIDA DE UN PROYECTO XP.

Las fases que define eXtreme Programming pueden verse en la Figura 5.1, �Fases de
un proyecto en eXtreme Programming�.

Figura 5.1. Fases de un proyecto en eXtreme Programming

El ciclo de vida ideal de XP consiste de seis fases:

Exploraci�n
En esta fase, los clientes plantean a grandes rasgos las historias de usuario que
son de inter�s para la primera entrega del producto. Al mismo tiempo el equipo de
desarrollo se familiariza con las herramientas, tecnolog�as y pr�cticas que se
utilizar�n en el proyecto. Se prueba la tecnolog�a y se exploran las posibilidades
de la arquitectura del sistema construyendo un prototipo. La fase de exploraci�n
toma de pocas semanas a pocos meses, dependiendo del tama�o y familiaridad que
tengan los programadores con la tecnolog�a.

Planificaci�n de la Entrega (Release)

En esta fase el cliente establece la prioridad de cada historia de usuario, y

correspondientemente, los programadores realizan una estimaci�n del esfuerzo
necesario de cada una de ellas. Se toman acuerdos sobre el contenido de la primera
entrega y se determina un cronograma en conjunto con el cliente. Una entrega
deber�a obtenerse en no m�s de tres meses. Esta fase dura unos pocos d�as. Las
estimaciones de esfuerzo asociado a la implementaci�n de las historias la
establecen los programadores utilizando como medida el punto. Un punto, equivale a
una semana ideal de programaci�n. Las historias generalmente valen de 1 a 3 puntos.
Por otra parte, el equipo de desarrollo mantiene un registro de la �velocidad� de
desarrollo, establecida en puntos por iteraci�n, bas�ndose principalmente en la
suma de puntos correspondientes a las historias de usuario que fueron terminadas en
la �ltima iteraci�n. La planificaci�n se puede realizar bas�ndose en el tiempo o el
alcance. La velocidad del proyecto es utilizada para establecer cu�ntas historias
se pueden implementar antes de una fecha determinada o cu�nto tiempo tomar�
implementar un conjunto de historias. Al planificar por tiempo, se multiplica el
n�mero de iteraciones por la velocidad del proyecto, determin�ndose cu�ntos puntos
se pueden completar. Al planificar seg�n alcance del sistema, se divide la suma de
puntos de las historias de usuario seleccionadas entre la velocidad del proyecto,
obteniendo el n�mero de iteraciones necesarias para su implementaci�n.

Iteraciones

Esta fase incluye varias iteraciones sobre el sistema antes de ser entregado. El
Plan de Entrega est� compuesto por iteraciones de no m�s de tres semanas. En la
primera iteraci�n se puede intentar establecer una arquitectura del sistema que
pueda ser utilizada durante el resto del proyecto. Esto se logra escogiendo las
historias que fuercen la creaci�n de esta arquitectura, sin embargo, esto no
siempre es posible ya que es el cliente quien decide qu� historias se implementar�n
en cada iteraci�n (para maximizar el valor de negocio). Al final de la �ltima
iteraci�n el sistema estar� listo para entrar en producci�n. Los elementos que
deben tomarse en cuenta durante la elaboraci�n del Plan de la Iteraci�n son:
historias de usuario no abordadas, velocidad del proyecto, pruebas de aceptaci�n no
superadas en la iteraci�n anterior y tareas no terminadas en la iteraci�n anterior.
Todo el trabajo de la iteraci�n es expresado en tareas de programaci�n, cada una de
ellas es asignada a un programador como responsable, pero llevadas a cabo por
parejas de programadores.

Producci�n

La fase de producci�n requiere de pruebas adicionales y revisiones de rendimiento

antes de que el sistema sea trasladado al entorno del cliente. Al mismo tiempo, se
deben tomar decisiones sobre la inclusi�n de nuevas caracter�sticas a la versi�n
actual, debido a cambios durante esta fase. Es posible que se rebaje el tiempo que
toma cada iteraci�n, de tres a una semana. Las ideas que han sido propuestas y las
sugerencias son documentadas para su posterior implementaci�n (por ejemplo, durante
la fase de mantenimiento).

Mantenimiento
Mientras la primera versi�n se encuentra en producci�n, el proyecto XP debe
mantener el sistema en funcionamiento al mismo tiempo que desarrolla nuevas
iteraciones. Para realizar esto se requiere de tareas de soporte para el cliente.
De esta forma, la velocidad de desarrollo puede bajar despu�s de la puesta del
sistema en producci�n. La fase de mantenimiento puede requerir nuevo personal
dentro del equipo y cambios en su estructura.

Muerte del Proyecto

Es cuando el cliente no tiene m�s historias para ser incluidas en el sistema. Esto
requiere que se satisfagan las necesidades del cliente en otros aspectos como
rendimiento y confiabilidad del sistema. Se genera la documentaci�n final del
sistema y no se realizan m�s cambios en la arquitectura. La muerte del proyecto
tambi�n ocurre cuando el sistema no genera los beneficios esperados por el cliente
o cuando no hay presupuesto para mantenerlo.

Figura 5.2. Ciclos en eXtreme Programming

2.3. UML (Lenguaje de Modelado Unificado).

UML (Unified Modeling Language) es un lenguaje que permite modelar, construir y

documentar los elementos que forman un sistema software orientado a objetos. Se ha
convertido en el est�ndar de facto de la industria, debido a que ha sido impulsado
por los autores de los tres m�todos m�s usados de orientaci�n a objetos: Grady
Booch, Ivar Jacobson y Jim Rumbaugh. Estos autores fueron contratados por la
empresa Rational Software Co. para crear una notaci�n unificada en la que basar la
construcci�n de sus herramientas CASE. En el proceso de creaci�n de UML han
participado, no obstante, otras empresas de gran peso en la industria como
Microsoft, Hewlett-Packard, Oracle o IBM, as� como grupos de analistas y
desarrolladores.

Esta notaci�n ha sido ampliamente aceptada debido al prestigio de sus creadores y

debido a que incorpora las principales ventajas de cada uno de los m�todos
particulares en los que se basa (principalmente Booch, OMT y OOSE). UML ha puesto
fin a las llamadas �guerras de m�todos� que se han mantenido a lo largo de los 90,
en las que los principales m�todos sacaban nuevas versiones que incorporaban las
t�cnicas de los dem�s. Con UML se fusiona la notaci�n de estas t�cnicas para formar
una herramienta compartida entre todos los ingenieros software que trabajan en el
desarrollo orientado a objetos.

Uno de los objetivos principales de la creaci�n de UML era posibilitar el

intercambio demodelos entre las distintas herramientas CASE orientadas a objetos
del mercado. Para ello era necesario definir una notaci�n y sem�ntica com�n. En la
Figura 2 se puede ver cu�l ha sido la evoluci�n de UML hasta la creaci�n de UML
1.3, en el que se basa este documento. Hay que tener en cuenta que el est�ndar UML
no define un proceso de desarrollo espec�fico, tan solo se trata de una notaci�n.
En este curso se sigue el m�todo propuesto por Craig Larman que se ajusta a un
ciclo de vida iterativo e incremental dirigido por casos de uso.

2.3.1. MODELOS.

Un modelo representa a un sistema software desde una perspectiva espec�fica. Al

igual que la planta y el alzado de una figura en dibujo t�cnico nos muestran la
misma figura vista desde distintos �ngulos, cada modelo nos permite fijarnos en un
aspecto distinto del sistema.
Notas

Una nota sirve para a�adir cualquier tipo de comentario a un diagrama o a un

elemento de un diagrama. Es un modo de indicar informaci�n en un formato libre,
cuando la notaci�n del diagrama en cuesti�n no nos permite expresar dicha
informaci�n de manera adecuada. Una nota se representa como un rect�ngulo con una
esquina doblada con texto en su interior. Puede aparecer en un diagrama tanto sola
como unida a un elemento por medio de una l�nea discontinua. Puede contener
restricciones, comentarios, el cuerpo de un procedimiento, etc.

Dependencias

La relaci�n de dependencia entre dos elementos de un diagrama significa que un

cambio en el elemento destino puede implicar un cambio en el elemento origen (por
tanto, si cambia el elemento destino habr�a que revisar el elemento origen). Una
dependencia se representa por medio de una l�nea de trazo discontinuo entre los dos
elementos con una flecha en su extremo. El elemento dependiente es el origen de la
flecha y el elemento del que depende es el destino (junto a �l est� la flecha).

2.3.2. DIAGRAMAS DE ESTRUCTURA EST�TICA.

Los Diagramas de Estructura Est�tica de UML se van a utilizar para representar

tanto Modelos Conceptuales (ver secci�n IV.3.2) como Diagramas de Clases de Dise�o
(ver secci�n IV.4.4). Ambos usos son distintos conceptualmente, mientras los
primeros modelan elementos del dominio los segundos presentan los elementos de la
soluci�n software. Ambos tipos de diagramas comparten una parte de la notaci�n para
los elementos que los forman (clases y objetos) y las relaciones que existen entre
los mismos (asociaciones). Sin embargo, hay otros elementos de notaci�n que ser�n
exclusivos de uno u otro tipo de diagrama.

2.3.2.1. Clases.

Una clase se representa mediante una caja subdividida en tres partes: En la

superior se muestra el nombre de la clase, en la media los atributos y en la
inferior las operaciones. Una clase puede representarse de forma esquem�tica, con
los atributos y operaciones suprimidos, siendo entonces tan solo un rect�ngulo con
el nombre de la clase. En la Figura 5 se ve c�mo una misma clase puede
representarse a distinto nivel de detalle seg�n interese, y seg�n la fase en la que
se est�.

2.3.2.2. Objetos.

Un objeto se representa de la misma forma que una clase. En el compartimento

superior aparecen el nombre del objeto junto con el nombre de la clase subrayados,
seg�n la siguiente sintaxis: nombre_del_objeto: nombre_de_la_clase Puede
representarse un objeto sin un nombre espec�fico, entonces s�lo aparece el nombre
de la clase.

2.3.2.3. Asociaciones.

Las asociaciones entre dos clases se representan mediante una l�nea que las une. La
l�nea puede tener una serie de elementos gr�ficos que expresan caracter�sticas
particulares de la asociaci�n. A continuaci�n se ver�n los m�s importantes de entre
dichos elementos gr�ficos.

2.3.2.3.1. Nombre de la Asociaci�n y Direcci�n.

El nombre de la asociaci�n es opcional y se muestra como un texto que est� pr�ximo

a la l�nea. Se puede a�adir un peque�o tri�ngulo negro s�lido que indique la
direcci�n en la cual leer el nombre de la asociaci�n. En el ejemplo de la Figura 7
se puede leer la asociaci�n como �Director manda sobre Empleado�.

Los nombres de las asociaciones normalmente se incluyen en los modelos para

aumentar la legibilidad. Sin embargo, en ocasiones pueden hacer demasiado abundante
la informaci�n que se presenta, con el consiguiente riesgo de saturaci�n. En ese
caso se puede suprimir el nombre de las asociaciones consideradas como
suficientemente conocidas. En las asociaciones de tipo agregaci�n y de herencia no
se suele poner el nombre.

2.3.2.3.2. Multiplicidad.

La multiplicidad es una restricci�n que se pone a una asociaci�n, que limita el

n�mero de instancias de una clase que pueden tener esa asociaci�n con una instancia
de la otra clase. Puede expresarse de las siguientes formas:
� Con un n�mero fijo: 1.
� Con un intervalo de valores: 2..5.
� Con un rango en el cual uno de los extremos es un asterisco. Significa que es un
intervalo abierto. Por ejemplo, 2..* significa 2 o m�s.
� Con una combinaci�n de elementos como los anteriores separados por comas: 1,
3..5, 7, 15..*.
� Con un asterisco: *. En este caso indica que puede tomar cualquier valor (cero o
m�s).

2.3.2.3.3. Roles.

Para indicar el papel que juega una clase en una asociaci�n se puede especificar un
nombre de rol.

Se representa en el extremo de la asociaci�n junto a la clase que desempe�a dicho

rol.

2.3.2.3.4. Agregaci�n.

El s�mbolo de agregaci�n es un diamante colocado en el extremo en el que est� la

clase que representa el �todo�.
2.3.2.4. Herencia.

La relaci�n de herencia se representa mediante un tri�ngulo en el extremo de la

relaci�n que corresponde a la clase m�s general o clase �padre�.

Si se tiene una relaci�n de herencia con varias clases subordinadas, pero en un

diagrama concreto no se quieren poner todas, esto se representa mediante puntos
suspensivos. En el ejemplo de la Figura 13, s�lo aparecen en el diagrama 3 tipos de
departamentos, pero con los puntos suspensivos se indica que en el modelo completo
(el formado por todos los diagramas) la clase �Departamento� tiene subclases
adicionales, como podr�an ser �Recursos Humanos� y �Producci�n�.

2.3.2.5. Elementos Derivados.

Un elemento derivado es aquel cuyo valor se puede calcular a partir de otros

elementos presentes en el modelo, pero que se incluye en el modelo por motivos de
claridad o como decisi�n de dise�o. Se representa con una barra �/� precediendo al
nombre del elemento derivado.

2.3.3. DIAGRAMA DE CASOS DE USO.

Un Diagrama de Casos de Uso muestra la relaci�n entre los actores y los casos de
uso del sistema. Representa la funcionalidad que ofrece el sistema en lo que se
refiere a su interacci�n externa. En el diagrama de casos de uso se representa
tambi�n el sistema como una caja rectangular con el nombre en su interior. Los
casos de uso est�n en el interior de la caja del sistema, y los actores fuera, y
cada actor est� unido a los casos de uso en los que participa mediante una l�nea.
En la Figura 15 se muestra un ejemplo de Diagrama de Casos de Uso para un cajero
autom�tico.

2.3.3.1. Elementos.

Los elementos que pueden aparecer en un Diagrama de Casos de Uso son: actores,
casos de uso y relaciones entre casos de uso.

2.3.3.2. Actores.

Un actor es algo con comportamiento, como una persona (identificada por un rol), un
sistema informatizado u organizaci�n, y que realiza alg�n tipo de interacci�n con
el sistema.. Se representa mediante una figura humana dibujada con palotes. Esta
representaci�n sirve tanto para actores que son personas como para otro tipo de
actores.
2.3.3.3. Casos de Uso.

Un caso de uso es una descripci�n de la secuencia de interacciones que se producen

entre un actor y el sistema, cuando el actor usa el sistema para llevar a cabo una
tarea espec�fica. Expresa una unidad coherente de funcionalidad, y se representa en
el Diagrama de Casos de Uso mediante una elipse con el nombre del caso de uso en su
interior. El nombre del caso de uso debe reflejar la tarea espec�fica que el actor
desea llevar a cabo usando el sistema.
2.3.3.4. Relaciones entre Casos de Uso

Un caso de uso, en principio, deber�a describir una tarea que tiene un sentido
completo para el usuario. Sin embargo, hay ocasiones en las que es �til describir
una interacci�n con un alcance menor como caso de uso. La raz�n para utilizar estos
casos de uso no completos en algunos casos, es mejorar la comunicaci�n en el equipo
de desarrollo, el manejo de la documentaci�n de casos de uso. Para el caso de que
queramos utilizar estos casos de uso m�s peque�os, las relaciones entre estos y los
casos de uso ordinarios pueden ser de los siguientes tres tipos: � Incluye (<>): Un
caso de uso base incorpora expl�citamente a otro caso de uso en un lugar
especificado en dicho caso base. Se suele utilizar para encapsular un
comportamiento parcial com�n a varios casos de uso. En la Figura 16 se muestra c�mo
el caso de uso Realizar Reintegro puede incluir el comportamiento del caso de uso
Autorizaci�n.

Figura 16 - Ejemplo de Relaci�n <> � Extiende (<>): Cuando un caso de uso base
tiene ciertos puntos (puntos de extensi�n) en los cuales, dependiendo de ciertos
criterios, se va a realizar una interacci�n adicional. El caso de uso que extiende
describe un comportamiento opcional del sistema (a diferencia de la relaci�n
incluye que se da siempre que se realiza la interacci�n descrita) En la Figura 17
se muestra como el caso de uso Comprar Producto permite explicitamente extensiones
en el siguiente punto de extensi�n: info regalo. La interacci�n correspondiente a
establecer los detalles sobre un producto que se env�a como regalo est�n descritos
en el caso de uso Detalles Regalo.

Figura 17 - Ejemplo de Relaci�n <>

Ambos tipos de relaci�n se representan como una dependencia etiquetada con el
estereotipo correspondiente (<> o <>), de tal forma que la flecha indique el
sentido en el que debe leerse la etiqueta. Junto a la etiqueta <> se puede detallar
el/los puntos de extensi�n del caso de uso base en los que se aplica la extensi�n.
� Generalizaci�n ( ): Cuando un caso de uso definido de forma abstracta se
particulariza por medio de otro caso de uso m�s espec�fico. Se representa por una
l�nea continua entre los dos casos de uso, con el tri�ngulo que simboliza
generalizaci�n en UML (usado tambi�n para denotar la herencia entre clases) pegado
al extremo del caso de uso m�s general. Al igual que en la herencia entre clases,
el caso de uso hijo hereda las asociaciones y caracter�sticas del caso de uso
padre. El caso de uso padre se trata de un caso de uso abstracto, que no est�
definido completamente. Este tipo de relaci�n se utiliza mucho menos que las dos
anteriores.

2.3.4. DIAGRAMAS DE INTERACCI�N.

En los diagramas de interacci�n se muestra un patr�n de interacci�n entre objetos.

Hay dos tipos de diagrama de interacci�n, ambos basados en la misma informaci�n,
pero cada uno enfatizando un aspecto particular: Diagramas de Secuencia y Diagramas
de Colaboraci�n.

2.3.4.1. Diagrama de Secuencia.

Un diagrama de Secuencia muestra una interacci�n ordenada seg�n la secuencia

temporal de eventos. En particular, muestra los objetos participantes en la
interacci�n y los mensajes que intercambian ordenados seg�n su secuencia en el
tiempo. El eje vertical representa el tiempo, y en el eje horizontal se colocan los
objetos y actores participantes en la interacci�n, sin un orden prefijado. Cada
objeto o actor tiene una l�nea vertical, y los mensajes se representan mediante
flechas entre los distintos objetos. El tiempo fluye de arriba abajo. Se pueden
colocar etiquetas (como restricciones de tiempo, descripciones de acciones, etc.)
bien en el margen izquierdo o bien junto a las transiciones o activaciones a las
que se refieren.

Figura 18 Diagrama de Secuencia

2.3.4.2. Diagrama de Colaboraci�n.

Un Diagrama de Colaboraci�n muestra una interacci�n organizada bas�ndose en los

objetos que toman parte en la interacci�n y los enlaces entre los mismos (en cuanto
a la interacci�n se refiere). A diferencia de los Diagramas de Secuencia, los
Diagramas de Colaboraci�n muestran las relaciones entre los roles de los objetos.
La secuencia de los mensajes y los flujos de ejecuci�n concurrentes deben
determinarse expl�citamente mediante n�meros de secuencia.

En cuanto a la representaci�n, un Diagrama de Colaboraci�n muestra a una serie de

objetos con los enlaces entre los mismos, y con los mensajes que se intercambian
dichos objetos. Los mensajes son flechas que van junto al enlace por el que
�circulan�, y con el nombre del mensaje y los par�metros (si los tiene) entre
par�ntesis. Cada mensaje lleva un n�mero de secuencia que denota cu�l es el mensaje
que le precede, excepto el mensaje que inicia el diagrama, que no lleva n�mero de
secuencia. Se pueden indicar alternativas con condiciones entre corchetes (por
ejemplo 3 [condici�n_de_test] : nombre_de_m�todo() ), tal y como aparece en el
ejemplo de la Figura 19. Tambi�n se puede mostrar el anidamiento de mensajes con
n�meros de secuencia como 2.1, que significa que el mensaje con n�mero de secuencia
2 no acaba de ejecutarse hasta que no se han ejecutado todos los 2. x .

2.3.5. DIAGRAMA DE ESTADOS.

Un Diagrama de Estados muestra la secuencia de estados por los que pasa bien un
caso de uso, bien un objeto a lo largo de su vida, o bien todo el sistema. En �l se
indican qu� eventos hacen que se pase de un estado a otro y cu�les son las
respuestas y acciones que genera.
En cuanto a la representaci�n, un diagrama de estados es un grafo cuyos nodos son
estados y cuyos arcos dirigidos son transiciones etiquetadas con los nombres de los
eventos.
Un estado se representa como una caja redondeada con el nombre del estado en su
interior. Una transici�n se representa como una flecha desde el estado origen al
estado destino.
La caja de un estado puede tener 1 o 2 compartimentos. En el primer compartimento
aparece el nombre del estado. El segundo compartimento es opcional, y en �l pueden
aparecer acciones de entrada, de salida y acciones internas.
Una acci�n de entrada aparece en la forma entrada/acci�n_asociada donde
acci�n_asociada es el nombre de la acci�n que se realiza al entrar en ese estado.
Cada vez que se entra al estado por medio de una transici�n la acci�n de entrada se
ejecuta.
Una acci�n de salida aparece en la forma salida/acci�n_asociada. Cada vez que se
sale del estado por una transici�n de salida la acci�n de salida se ejecuta.
Una acci�n interna es una acci�n que se ejecuta cuando se recibe un determinado
evento en ese estado, pero que no causa una transici�n a otro estado. Se indica en
la forma nombre_de_evento/acci�n_asociada.
Un diagrama de estados puede representar ciclos continuos o bien una vida finita,
en la que hay un estado inicial de creaci�n y un estado final de destrucci�n
(finalizaci�n del caso de uso o destrucci�n del objeto). El estado inicial se
muestra como un c�rculo s�lido y el estado final como un c�rculo s�lido rodeado de
otro c�rculo. En realidad, los estados inicial y final son pseudoestados, pues un
objeto no puede �estar� en esos estados, pero nos sirven para saber cu�les son las
transiciones inicial y final(es).

2.4. SISTEMAS DE CONTROL.

Desde el punto de vista de la teor�a de control, un sistema o proceso est� formado

por un conjunto de elementos relacionados entre s� que ofrecen se�ales de salida en
funci�n de se�ales o datos de entrada.

Es importante resaltar el hecho de que no es necesario conocer el

funcionamiento interno, o c�mo act�an entre s� los diversos elementos, para
caracterizar el sistema. Para ello, s�lo se precisa conocer la relaci�n que existe
entre la entrada y la salida del proceso que realiza el mismo (principio de caja
negra). El aspecto m�s importante de un sistema es el conocimiento de su din�mica,
es decir, c�mo se comporta la se�al de salida frente a una variaci�n de la se�al de
entrada. Un conocimiento preciso de la relaci�n entrada/salida permite predecir la
respuesta del sistema y seleccionar la acci�n de control adecuada para mejorarla.
De esta manera, el dise�ador, conociendo cu�l es la din�mica deseada,
ajustar� la acci�n de control para conseguir el objetivo final.

En vista de todo lo expuesto, se puede definir un sistema de control como el

conjunto de elementos que interact�an para conseguir que la salida de un proceso se
comporte tal y como se desea, mediante una acci�n de control.

Sistemas combinacionales y secuenciales

Los sistemas combinacionales y secuenciales pueden clasificarse como sistemas de
control basados en instrucciones l�gicas. Los datos de entrada y salida al sistema
son binarios e indican que los sensores tienen dos estados o valores (por ejemplo:
v�lvula abierta o cerrada, un indicador activado o no, o un interruptor pulsado o
no). Las decisiones tomadas por el sistema de control son del tipo on/off y se
basan en las condiciones de los datos de entrada.

Sistemas de control din�mico. Sistemas en lazo abierto y sistemas en lazo cerrado.

Dependiendo del tratamiento que el sistema de control realiza con la

se�al de salida, pueden distinguirse dos topolog�as de control generales:
sistemas en lazo abierto y sistemas en lazo cerrado.

Sistemas en lazo abierto

En este tipo de sistemas, la salida no tiene efecto alguno sobre la acci�n de

control.

En un sistema en lazo abierto, la salida no se compara con la entrada

de referencia, por ello cada entrada corresponder� a una operaci�n prefijada
sobre la se�al de salida. Se puede asegurar entonces que la exactitud del
sistema depende en gran manera de la calibraci�n del mismo y, por
tanto, la presencia de perturbaciones en la cadena (se�ales indeseadas) provocar�
que �ste no cumpla la funci�n asignada.
Para poder considerar una topolog�a en lazo abierto, es necesario conocer la
relaci�n entrada/salida y garantizar la inexistencia de perturbaciones externas o
de variaciones de los par�metros internos del sistema. Esto es, en general,
dif�cil de cumplir en la pr�ctica, y su realizaci�n implica sistemas
excesivamente caros.

Sistemas en lazo cerrado

En los sistemas de control en lazo cerrado, la se�al de salida tiene efecto sobre
la acci�n de control. A este efecto se le denomina realimentaci�n.

La se�al controlada debe realimentarse y compararse con la entrada de referencia,

tras lo cual se env�a a trav�s del sistema una se�al de control, que ser�
proporcional a la diferencia encontrada entre la se�al de entrada y la se�al
medida a la salida, con el objetivo de corregir el error o desviaci�n que pudiera
existir.

La principal ventaja de los sistemas de control en lazo cerrado es que el uso de la

realimentaci�n hace al conjunto menos sensible a las perturbaciones externas y a
las variaciones de los par�metros internos que los sistemas en lazo abierto.

2.5. SISTEMAS EN TIEMPO REAL.

Muchas aplicaciones de software son dependientes del tiempo y procesan m�s

informaci�n orientada al control de datos. Un sistema de tiempo real debe
interactuar con el mundo real en marcos temporales que vienen dados por el mundo
real. El control de naves o de procesos de fabricaci�n, los productos de consumo y
la instrumentaci�n industrial son algunas de entre cientos de aplicaciones del
software de tiempo real.

Para que resulte adecuado el an�lisis del software de tiempo real, se han propuesto
varias ampliaciones para la notaci�n b�sica del an�lisis estructurado.

Prueba de rendimiento

Para sistemas de tiempo real y sistemas empotrados, es inaceptable el software que

proporciona las funciones requeridas pero no se ajusta a los requisitos de
rendimiento. La prueba de rendimiento est� dise�ada para probar el rendimiento del
software en tiempo de ejecuci�n dentro del contexto de un sistema integrado. La
prueba de rendimiento se da durante todos los pasos del proceso de la prueba.
Incluso al nivel de unidad, se debe asegurar el rendimiento de los m�dulos
individuales a medida que se llevan a cabo las pruebas de caja blanca. Sin
embargo, hasta que no est�n completamente integrados todos los elementos del
sistema no se puede asegurar realmente el rendimiento del sistema.

Las pruebas de rendimiento, a menudo, van emparejadas con las pruebas de

resistencia y, frecuentemente, requieren instrumentaci�n tanto de software como
de hardware. Es decir, muchas veces es necesario medir la utilizaci�n de recursos
(por ejemplo, ciclos de procesador), de un modo exacto. La instrumentaci�n externa
puede monitorizar los intervalos de ejecuci�n, los sucesos ocurridos (por ejemplo,
interrupciones) y muestras de los estados de la m�quina en un funcionamiento
normal. Instrumentando un sistema, el encargado de la prueba puede descubrir
situaciones que lleven a degradaciones y posibles fallos del sistema.

2.6. METODOLOG�A DE DESARROLLO DEL SISTEMA DE CONTROL.

2.6.1. INTERFAZ DE HARDWARE.

2.6.1.1. HERRAMIENTAS CAD.

La metodolog�a de dise�o asistida por computadora (Computer Aided Design,

CAD), emplea t�cnicas gr�ficas para soportar el proceso de dise�o. La introducci�n
de dichas t�cnicas en el proceso de dise�o de circuitos electr�nicos es
fundamental, ya que m�s all� de proveer interfaces gr�ficas para asistir el
proceso, brinda la posibilidad de simular y verificar la descripci�n antes de
llevar a cabo su implementaci�n, minimizando el costo de elaborar
circuitos potencialmente defectuosos y acelerando el dise�o global.

El dise�o de hardware tiene un problema fundamental, que no existe en

el dise�o de software. Este problema es el alto costo del ciclo de dise�o �
prototipaci�n -verificaci�n, ya que el costo del prototipo por lo general es
bastante elevado.

En el ciclo de dise�o hardware las herramientas CAD est�n presentes en todos los
pasos. En primer lugar en la fase de descripci�n de la idea, que ser�
un sistema el�ctrico, un diagrama en bloques, etc. Luego en la fase de
simulaci�n y verificaci�n en donde las diversas herramientas permiten
realizar simulaci�n por eventos, funcional, digital o el�ctrica
considerando el nivel de simulaci�n requerido. La �ltima etapa es
comprendida por herramientas especializadas en la
fabricaci�n del circuito propiamente dicho y se orientan a la fabricaci�n
de circuitos impresos o Circuitos Integrados de Aplicaci�n Espec�fica
(Application Specific Integrated Circuits, ASIC).

Estas herramientas permiten realizar microcircuitos as� como la programaci�n

de dispositivos que as� lo requieran.

2.6.1.2. DISE�O TOP � DOWN.

La metodolog�a de dise�o Top-Down consiste en capturar una idea con un

alto nivel de abstracci�n, implementarla partiendo de la misma, e
incrementar el nivel de detalle seg�n sea necesario. El sistema inicial
se va subdividiendo en m�dulos, estableciendo una jerarqu�a. Cada m�dulo
se subdivide cuantas veces sea necesario hasta llegar a los componentes
primarios del dise�o como muestra el esquema de la figura.

La metodolog�a Top-Down evita los problemas en el dise�o inicial que es

subdividido en subdise�os que a su vez se pueden seguir subdividiendo
hasta llegar a dise�os mucho menores y m�s sencillos de tratar. En el caso del
dise�o de hardware, esto se traducir�a en subdividir el dise�o inicial en
m�dulos hasta llegar a los componentes primarios o primitivas.

Las herramientas actuales permiten utilizar en forma autom�tica la metodolog�a Top-

Down, lo que permite a las herramientas de s�ntesis sofisticadas llevar a
cabo la implementaci�n de un circuito final, partiendo de una idea abstracta y
sin necesidad de que el dise�ador deba descomponer su idea inicial en componentes
concretos.
En el proceso de dise�o se utilizan tecnolog�as gen�ricas, lo que posibilita que la
tecnolog�a de implementaci�n no se fije hasta los �ltimos pasos del
proceso. De �sta manera se pueden reutilizar los datos del dise�o �nicamente
cambiando la tecnolog�a de implementaci�n.

La descripci�n del circuito a distintos niveles de detalle, as� como la

verificaci�n y simulaci�n del mismo, permiten reducir la posibilidad de incluir
errores.

Dise�o modular: El dise�o Top-Down ofrece como ventaja que la informaci�n

se estructura en forma modular. Como el dise�o se realiza a partir del sistema
completo y se subdivide en m�dulos, permite que las subdivisiones se
realicen de forma que los mismos sean funcionalmente independientes.

Dise�o jer�rquico: En un dise�o electr�nico entran en juego una cantidad

considerable de componentes. Estos dise�os deben organizarse de tal forma que
resulte f�cil su comprensi�n. Una forma de organizar el dise�o es la creaci�n de un
dise�o modular jer�rquico. Un dise�o jer�rquico est� constituido por niveles en
donde cada uno es una especializaci�n del nivel superior. La organizaci�n
jer�rquica es una consecuencia directa de aplicar la metodolog�a Top-Down.

Luego de concebir la idea del circuito que se pretende dise�ar, se debe

realizar la descripci�n del mismo.

B�sicamente, las herramientas actuales permiten dos tipos de descripciones:

Descripci�n comportamental: Se describe el comportamiento del circuito, sin poner

�nfasis en su arquitectura. Dicha descripci�n se realiza mediante un
lenguaje de hardware espec�fico. No se especifican se�ales ni elementos de
bajo nivel.

Descripci�n estructural: Consiste en enumerar los componentes de un

circuito y sus interconexiones. Se puede llevar a cabo mediante esquemas, en
cuyo caso se realiza una descripci�n gr�fica de los componentes del circuito, o
bien mediante un lenguaje, en cuyo caso se enumeran los componentes del circuito y
sus interconexiones.

2.6.2. DISPOSITIVOS DE HARDWARE.

2.6.2.1. MICROCONTROLADORES PIC.

Un microcontrolador es un circuito integrado o chip que incluye en su interior las

tres unidades funcionales de una computadora: unidad central de procesamiento,
memoria y unidades de E/S (entrada/salida).

2.6.2.1.1. ARQUITECTURA.

Los PIC siguen la arquitectura Hardvard (Mark I)

- memoria de datos separada de la memoria de programas
o dos tama�os de palabra:
? Palabra de datos
? Palabra de instrucci�n
- Conjunto reducido de instrucciones (RISC)

- Palabra de instrucci�n larga:

o formato que permite incorporar en una �nica instrucci�n todos los campos
necesarios (importante: suficiente espacio para los bits de direcci�n)
- Una �nica palabra por instrucci�n.
o Decodificaci�n m�s sencilla. (un �nico ciclo)
- Pipeline de ejecuci�n.(2 etapas)
o Solapa la b�squeda de instrucci�n con la ejecuci�n
? Salvo en las instrucciones de salto.
- Conjunto de instrucciones reducido.
- Arquitectura de registros. Conjunto de instrucciones ortogonal.

2.6.2.2. PIC 18F4550.

- Caracter�sticas principales:

Nota n� 1: Soporta solo Full Speed y Low Speed * 1

Nota n� 2: Soporta modos interruptivo, is�crono y bulk transfer.
Nota n� 3: Al tener una arquitectura optimizada para C utilizaremos un compilador
de C como puede ser C de CCS para nuestros programas.

- Distribuci�n de pines del PIC 18F4550:

Al protocolo USB tambi�n lo llaman la pila USB: en las capas superiores tenemos las
funciones b�sicas que el usuario puede realizar (comunicaci�n l�gica). esto a su
vez va a parar a la segunda capa y luego a la tercera capa (comunicaci�n f�sica)
que involucra el aspecto el�ctrico. En nuestro caso estar�amos directamente metidos
en la capa superior, pero algunas veces entrando en las otras dos:

2.6.2.3. CONFIGURACI�N DEL OSCILADOR.

El m�dulo oscilador del PIC18F4550 viene dado de la siguiente manera:

El oscilador tiene varias configuraciones seg�n el cristal usado y que dispositivos

utilizar�n el oscilador.

Las configuraciones para los diferentes cristales se detallan en la pr�xima imagen.

2.6.2.4. MOTOR DE CORRIENTE CONTINUA.

Los Motores de Corriente Directa (CD) o Corriente Continua (CC) se utilizan en

casos en los que es importante el poder regular continuamente la velocidad del
motor, adem�s, se utilizan en aquellos casos en los que es imprescindible utilizar
corriente directa, como es el caso de motores accionados por pilas o bater�as. Este
tipo de motores debe de tener en el rotor y el estator el mismo n�mero de polos y
el mismo numero de carbones. Los motores de corriente directa pueden ser de tres
tipos:
� Serie
� Paralelo
� Mixto

Como su nombre lo indica, un motor el�ctrico de corriente continua, funciona con

corriente continua. En estos motores, el inductor es el estator y el inducido es el
rotor. Fueron los primeros en utilizarse en veh�culos el�ctricos por sus buenas
caracter�sticas en tracci�n y por la simplicidad de los sistemas de control de la
electricidad desde las bater�as. Presentan desventajas en cuanto al mantenimiento
de algunas de sus piezas (escobillas y colectores) y a que deben ser motores
grandes si se buscan potencias elevadas, pues su estructura (y en concreto el
rozamiento entre piezas) condiciona el l�mite de velocidad de rotaci�n m�xima.

Esquema de un motor de corriente continua

Constituci�n:

Est�n formados generalmente por las siguientes partes:

� Inductor o estator (Arrollamiento de excitaci�n): Es un

electroim�n formado por un n�mero par de polos. Las bobinas que los
arrollan son las encargadas de producir el campo inductor al circular por ellas la
corriente de excitaci�n.

� Inducido o rotor (Arrollamiento de inducido): Es una

pieza giratoria formada por un n�cleo magn�tico alrededor del cual va el
devanado de inducido, sobre el que act�a el campo magn�tico.

� Colector de delgas: Es un anillo de l�minas de cobre llamadas delgas,

dispuesto sobre el eje del rotor que sirve para conectar las bobinas del inducido
con el circuito exterior a trav�s de las escobillas. +

� Escobillas: Son unas piezas de grafito que se colocan sobre el

colector de delgas, permitiendo la uni�n el�ctrica de las delgas con los bornes
de conexi�n del inducido.

Al girar el rotor, las escobillas van rozando con las delgas, conectando
la bobina de inducido correspondiente a cada par de delgas con el circuito
exterior.

Par�metros caracter�sticos

Clase
NEMA Par de arranque Corriente de
Arranque Regulaci�n de
Velocidad (%) Nombre de clase
Del motor
A
B
C
D
F 1.5-1.75
1.4-1.6
2-2.5
2.5-3.0
1.25 5-7
4.5-5
3.5-5
3-8
2-4 2-4
3.5
4-5
5-8 , 8-13
mayor de 5 Normal
De prop�sito general
De doble jaula alto par
De alto par alta resistencia
De doble jaula.

- Clasificaci�n Motores de Corriente Continua

Motores de corriente continua de im�n permanente:

Existen motores de im�n permanente (PM, permanent magnet), en tama�os de fracciones

de caballo y de n�meros peque�os enteros de caballos. Tienen varias ventajas
respecto a los del tipo de campo devanado. No se necesitan las alimentaciones de
energ�a el�ctrica para excitaci�n ni el devanado asociado. Se mejora la
confiabilidad, ya que no existen bobinas excitadoras del campo que fallen y no hay
probabilidad de que se presente una sobrevelocidad debida a p�rdida del campo. Se
mejoran la eficiencia y el enfriamiento por la eliminaci�n de p�rdida de potencia
en un campo excitador. As� mismo, la caracter�stica par contra corriente se
aproxima m�s a lo lineal. Un motor de im�n permanente (PM) se puede usar en donde
se requiere un motor por completo encerrado para un ciclo de servicio de excitaci�n
continua.

Excitaci�n Independiente:

Los motores de excitaci�n independiente tienen como aplicaciones industriales el

torneado y taladrado de materiales, extrusi�n de materiales pl�sticos y goma,
ventilaci�n de horno, retroceso r�pido en vac�o de ganchos de gr�as, desenrollado
de bobinas y retroceso de �tiles para serrar. El motor de excitaci�n independiente
es el m�s adecuado para cualquier tipo de regulaci�n, por la independencia entre el
control por el inductor y el control por el inducido. El sistema de excitaci�n m�s
f�cil de entender es el que supone una fuente exterior de alimentaci�n para el
arrollamiento inductor. En la siguiente figura, se representa el inducido por un
c�rculo; la flecha recta interior representa el sentido de la corriente principal y
la flecha curva, el sentido de giro del inducido; el arrollamiento inductor o de
excitaci�n, se representa esquem�ticamente, y el sentido de la corriente de
excitaci�n, por medio de una flecha similar.

Autoexcitaci�n:

El sistema de excitaci�n independiente, solamente se emplea en la pr�ctica en casos

especiales debido, sobre todo, al inconveniente de necesitar una fuente
independiente de energ�a el�ctrica. Este inconveniente puede eliminarse con el
denominado principio dinamoel�ctrico o principio de autoexcitaci�n, que ha hecho
posible el gran desarrollo alcanzado por las m�quinas el�ctricas de corriente
continua en el presente siglo.

2.6.2.5. CIRCUITO INTEGRADO.

Un circuito integrado (CI), tambi�n conocido como chip o microchip, es una pastilla
peque�a de material semiconductor, de algunos mil�metros cuadrados de �rea, sobre
la que se fabrican circuitos electr�nicos generalmente mediante fotolitograf�a y
que est� protegida dentro de un encapsulado de pl�stico o cer�mica. El encapsulado
posee conductores met�licos apropiados para hacer conexi�n entre la pastilla y un
circuito impreso.

2.6.2.5.1. TIPOS

Existen tres tipos de circuitos integrados:

Circuitos monol�ticos: Est�n fabricados en un solo monocristal, habitualmente de

silicio, pero tambi�n existen en germanio, arseniuro de galio, silicio-germanio,
etc.

Circuitos h�bridos de capa fina: Son muy similares a los circuitos monol�ticos,
pero, adem�s, contienen componentes dif�ciles de fabricar con tecnolog�a
monol�tica. Muchos conversores A/D y conversores D/A se fabricaron en tecnolog�a
h�brida hasta que los progresos en la tecnolog�a permitieron fabricar resistencias
precisas.

Circuitos h�bridos de capa gruesa: Se apartan bastante de los circuitos

monol�ticos. De hecho suelen contener circuitos monol�ticos sin c�psula (dices),
transistores, diodos, etc, sobre un sustrato diel�ctrico, interconectados con
pistas conductoras. Las resistencias se depositan por serigraf�a y se ajustan
haci�ndoles cortes con l�ser. Todo ello se encapsula, tanto en c�psulas pl�sticas
como met�licas, dependiendo de la disipaci�n de potencia que necesiten. En muchos
casos, la c�psula no est� "moldeada", sino que simplemente consiste en una resina
epoxi que protege el circuito. En el mercado se encuentran circuitos h�bridos para
m�dulos de RF, fuentes de alimentaci�n, circuitos de encendido para autom�vil, etc.

2.6.2.5.2. CLASIFICACI�N.

Atendiendo al nivel de integraci�n - n�mero de componentes - los circuitos

integrados se clasifican en:

SSI (Small Scale Integration) peque�o nivel: de 10 a 100 transistores

MSI (Medium Scale Integration) medio: 101 a 1.000 transistores
LSI (Large Scale Integration) grande: 1.001 a 10.000 transistores
VLSI (Very Large Scale Integration) muy grande: 10.001 a 100.000 transistores
ULSI (Ultra Large Scale Integration) ultra grande: 100.001 a 1.000.000 transistores
GLSI (Giga Large Scale Integration) giga grande: m�s de un mill�n de transistores

En cuanto a las funciones integradas, los circuitos se clasifican en dos grandes

grupos:

o Circuitos integrados anal�gicos.

Pueden constar desde simples transistores encapsulados juntos, sin uni�n entre
ellos, hasta dispositivos completos como amplificadores, osciladores o incluso
receptores de radio completos.

o Circuitos integrados digitales.

Pueden ser desde b�sicas puertas l�gicas (Y, O, NO) hasta los m�s complicados
microprocesadores o microcontroladores.

�stos son dise�ados y fabricados para cumplir una funci�n espec�fica dentro de un
sistema. En general, la fabricaci�n de los CI es compleja ya que tienen una alta
integraci�n de componentes en un espacio muy reducido de forma que llegan a ser
microsc�picos. Sin embargo, permiten grandes simplificaciones con respecto los
antiguos circuitos, adem�s de un montaje m�s r�pido.

2.6.2.6. CONDENSADOR.

B�sicamente un condensador es un dispositivo capaz de almacenar energ�a en forma de

campo el�ctrico. Est� formado por dos armaduras met�licas paralelas (generalmente
de aluminio) separadas por un material diel�ctrico.

Va a tener una serie de caracter�sticas tales como capacidad, tensi�n de trabajo,

tolerancia y polaridad, que deberemos aprender a distinguir

En la imagen se ve esquematizado un condensador, con las dos l�minas = placas =

armaduras, y el diel�ctrico entre ellas. En la versi�n m�s sencilla del
condensador, no se pone nada entre las armaduras y se las deja con una cierta
separaci�n, en cuyo caso se dice que el diel�ctrico es el aire.

Capacidad: Se mide en Faradios (F), aunque esta unidad resulta tan grande que se
suelen utilizar varios de los subm�ltiplos, tales como microfaradios (�F=10-6 F ),
nanofaradios (nF=10-9 F) y picofaradios (pF=10-12 F).

Tensi�n de trabajo: Es la m�xima tensi�n que puede aguantar un condensador, que

depende del tipo y grososr del diel�ctrico con que est� fabricado. Si se supera
dicha tensi�n, el condensador puede perforarse (quedar cortocircuitado) y/o
explotar. En este sentido hay que tener cuidado al elegir un condensador, de forma
que nunca trabaje a una tensi�n superior a la m�xima.

Tolerancia: Igual que en las resistencias, se refiere al error m�ximo que puede
existir entre la capacidad real del condensador y la capacidad indicada sobre su
cuerpo.

Polaridad: Los condensadores electrol�ticos y en general los de capacidad superior

a 1 �F tienen polaridad, eso es, que se les debe aplicar la tensi�n prestando
atenci�n a sus terminales positivo y negativo. Al contrario que los inferiores a
1�F, a los que se puede aplicar tensi�n en cualquier sentido, los que tienen
polaridad pueden explotar en caso de ser �sta la incorrecta.

2.6.2.7. RESISTENCIA.

Las resistencias son unos elementos el�ctricos cuya misi�n es dificultar el paso de
la corriente el�ctrica a trav�s de ellas. Su caracter�stica principal es su
resistencia �hmica aunque tienen otra no menos importante que es la potencia m�xima
que pueden disipar. �sta �ltima depende principalmente de la construcci�n f�sica
del elemento.

La resistencia �hmica de una resistencia se mide en ohmios, valgan las

redundancias. Se suele utilizar esa misma unidad, as� como dos de sus m�ltiplos: el
Kilo-Ohmio (1KO) y el Mega-Ohmio (1MO=106O).

El valor resistivo puede ser fijo o variable. En el primer caso hablamos de

resistencias comunes o fijas y en el segundo de resistencias variables, ajustables,
potenci�metros y re�statos. No centraremos en el primer tipo, las fijas.

Las resistencias fijas pueden clasificarse en dos grupos, de acuerdo con el

material con el que est�n constituidas: "resistencias de hilo", s�lamente para
disipaciones superiores a 2 W, y "resistencias qu�micas" para, en general,
potencias inferiores a 2 W.

2.6.2.8. TRANSISTOR.

Los transistores son unos elementos que han facilitado, en gran medida, el dise�o
de circuitos electr�nicos de reducido tama�o, gran versatilidad y facilidad de
control.

Los transistores tienen multitud de aplicaciones, entre las que se encuentran:

Amplificaci�n de todo tipo (radio, televisi�n, instrumentaci�n)
Generaci�n de se�al (osciladores, generadores de ondas, emisi�n de radiofrecuencia)
Conmutaci�n, actuando de interruptores (control de rel�s, fuentes de alimentaci�n
conmutadas, control de l�mparas, modulaci�n por anchura de impulsos PWM)
Detecci�n de radiaci�n luminosa (fototransistores)

Los transistores de uni�n (uno de los tipos m�s b�sicos) tienen 3 terminales
llamados Base, Colector y Emisor, que dependiendo del encapsulado que tenga el
transistor pueden estar distribuidos de varias formas.

Por otro lado, los Transistores de Efecto de Campo (FET) tienen tambi�n 3
terminales, que son Puerta (Gate), Drenador (Drain) y Sumidero (Sink), que
igualmente dependiendo del encapsulado que tenga el transistor pueden estar
distribuidos de varias formas.

Tipos de transistores. Simbolog�a

Existen varios tipos que dependen de su proceso de construcci�n y de las

aplicaciones a las que se destinan. Aqu� abajo mostramos una tabla con los tipos de
uso m�s frecuente y su simbolog�a:

2.6.2.9. FINAL DE CARRERA.

Dentro de los componentes electr�nicos, se encuentra el final de carrera o sensor

de contacto (tambi�n conocido como "interruptor de l�mite") o limit switch, son
dispositivos el�ctricos, neum�ticos o mec�nicos situados al final del recorrido de
un elemento m�vil, como por ejemplo una cinta transportadora, con el objetivo de
enviar se�ales que puedan modificar el estado de un circuito. Internamente pueden
contener interruptores normalmente abiertos (NA o NO en ingl�s), cerrados (NC) o
conmutadores dependiendo de la operaci�n que cumplan al ser accionados, de ah� la
gran variedad de finales de carrera que existen en mercado.

Generalmente estos sensores est�n compuestos por dos partes: un cuerpo donde se
encuentran los contactos y una cabeza que detecta el movimiento. Su uso es muy
diverso, emple�ndose, en general, en todas las m�quinas que tengan un movimiento
rectil�neo de ida y vuelta o sigan una trayectoria fija, es decir, aquellas que
realicen una carrera o recorrido fijo, como por ejemplo ascensores, montacargas,
robots, etc.

Los finales de carrera est�n fabricados en diferentes materiales tales como metal,
pl�stico o fibra de vidrio.

Modelos
Dentro de los dispositivos sensores de final de carrera existen varios modelos:

Honeywell de seguridad: Este final de carrera est� incorporado dentro de la gama

GLS de la empresa Honeywell y se fabrica tambi�n en miniatura, tanto en metal como
en pl�stico y madera,con tres conducciones met�licas muy compactas..
Fin de carrera para entornos peligrosos: Se trata en concreto de un
microinterruptor conmutador monopolar con una robusta carcasa de aluminio. Esta
cubierta ha sido dise�ada para poder soportar explosiones internas y para poder
enfriar los gases que la explosi�n genera en su interior. Este interruptor se
acciona mediante un actuador de la palanca externo de rodillo que permite un ajuste
de 360�.
Set crews: Estos tipos de finales de carrera se utilizan para prevenir da�os en el
sensor provocados por el objeto sensado. Est�n compuestos por un cilindro roscado
conteniendo un resorte con un objetivo de metal el cual es detectado por el sensor
inductivo por lo que puede soportar impactos de hasta 20 N sin sufrir da�os.

2.6.3. INTERFAZ DE SOFTWARE.

2.6.3.1. DELPHI (LENGUAJE DE PROGRAMACI�N).

Delphi es un entorno de desarrollo de software dise�ado para la programaci�n de

prop�sito general con �nfasis en la programaci�n visual. En Delphi se utiliza como
lenguaje de programaci�n una versi�n moderna de Pascal llamada Object Pascal.

Delphi est� basado en una versi�n de Pascal denominada Object Pascal. Borland en
los �ltimos a�os defend�a que el nombre correcto del lenguaje es tambi�n Delphi,
posiblemente debido a pretensiones de marca, aunque en sus mismos manuales el
nombre del lenguaje aparec�a como Object Pascal, por lo que la comunidad de
programadores no ha adoptado mayoritariamente este cambio (supuesta aclaraci�n,
seg�n Borland). Object Pascal expande las funcionalidades del Pascal est�ndar:

Soporte para la programaci�n orientada a objetos (habitualmente llamada POO)

tambi�n existente desde Turbo Pascal 5.5, pero m�s evolucionada en cuanto a:

Encapsulaci�n: declarando partes privadas, protegidas, p�blicas y publicadas de las

clases, Propiedades: concepto nuevo que luego han adaptado muchos otros lenguajes.
Las propiedades permiten usar la sintaxis de asignaci�n para setters y getters y
simplificaci�n de la sintaxis de referencias a clases y punteros.

Soporte para manejo estructurado de excepciones, mejorando sensiblemente el control

de errores de usuario y del sistema.

Programaci�n activada por eventos (event-driven), posible gracias a la t�cnica de

delegaci�n de eventos. Esta t�cnica permite asignar el m�todo de un objeto para
responder a un evento lanzado sobre otro objeto. Fue adoptada por Niklaus Wirth,
autor del Pascal Original, e incorporada a otros de sus lenguajes como Component
Pascal.

2.6.3.2. SQL SERVER (DBMS).

Microsoft SQL Server es un sistema para la gesti�n de bases de datos producido por
Microsoft basado en el modelo relacional. Sus lenguajes para consultas son T-SQL y
ANSI SQL. Microsoft SQL Server constituye la alternativa de Microsoft a otros
potentes sistemas gestores de bases de datos como son Oracle o MySQL.

2.6.3.2.1. SERVIDOR SQL.

Un servidor de SQL es el software que permite una administraci�n y desarrollo de

bases de datos. El cual consta de las siguientes bondades:

- Soporte de transacciones.
- Escalablidad, estabilidad y seguridad.
- Soporta procedimientos almacenados.
- Incluye tambi�n un potente entorno gr�fico de administraci�n, que permite el
uso de comandos DDL y DML gr�ficamente.
- Permite trabajar en modo cliente-servidor, donde la informaci�n y datos se
alojan en el servidor y los terminales o clientes de la red s�lo acceden a la
informaci�n.
- Adem�s permite administrar informaci�n de otros servidores de datos.
- Este sistema incluye una versi�n reducida, llamada MSDE con el mismo motor de
base de datos pero orientado a proyectos m�s peque�os, que en sus versi�nes 2005 y
2008 pasa a ser el SQL Express Edition, que se distribuye en forma gratuita.

PIC BASIC PRO.

PicBasic Pro de Micro Engineering Labs Inc. es un software compilador Basic para
programar Pic�s de los m�s conocidos. Este poderoso compilador pone al alcance
potentes instrucciones para comunicaci�n USB, serie, matem�tica de 16 bits,
mediciones de sensores anal�gicos, PWM, sonido, y much�simas m�s.

Adem�s de general los files �hex� y tambi�n es capaz de generar los files �asm�.
De tal manera que s� se pueden hacer modificaciones de bajo nivel.

Otra magn�fica caracter�stica de este compilador es que adem�s de soportar al

PIC16F84 tambi�n soporta a muchos otros de la gran familia de MICROCHIP. Por
ejemplo los micros Flash PIC16F628, 16F876, 16F877, 18F2550, 18F4550.

2.6.4. INTERFAZ DE CONTROL.

2.6.4.1. USB.

USB es una especificaci�n de las empresas Compaq, Intel, Microsoft y NEC, que
describe un canal serie que soporta una gran variedad de perif�ricos de media y
baja velocidad, con soporte integral para transferencias en tiempo real (is�cronas)
como voz, audio y v�deo comprimido, y que permite mezclar dispositivos y
aplicaciones is�cronas y as�ncronas.

La versi�n 1.1 (La que soporta el PIC18F4550) establece:

� Un acceso al bus gestionado directamente por el Controlador USB, para

permitir transferencias is�cronas y eliminar los tiempos de arbitraci�n.
� Una velocidad de 12 Mbps (Full Speed o FS) y un subcanal de 1,5 Mbps (Low
Speed o LS) para los dispositivos m�s lentos, como ratones y joysticks. La
coexistencia en un mismo sistema de dispositivos FS y LS se maneja mediante
conmutaci�n autom�tica y din�mica de velocidad entre unas transferencias y otras.
� Una conectividad excepcional, ya que puede manejar hasta 127 dispositivos
simult�neamente que se pueden conectar y desconectar en caliente, sin tener que
reiniciar el sistema.
� Una configuraci�n autom�tica de dispositivos, que elimina la necesidad de
realizar configuraciones manuales por medio de puentes o conmutadores.
� La coexistencia de dispositivos is�cronos y as�ncronos. Los dispositivos
is�cronos se atienden en funci�n del ancho de banda y latencia requeridos, y los
as�ncronos se atienden durante el tiempo restante no consumido por los dispositivos
is�cronos.
� Una distribuci�n de alimentaci�n desde el Controlador USB, que permite la
conexi�n tanto de dispositivos alimentados desde el bus como autoalimentados.
� Una arquitectura f�cilmente escalable para permitir la existencia de varios
Controladores USB en un sistema.
� La versi�n 1.1 es soportada por los siguientes sistemas operativos: Windows
98\Windows 2000\Windows XP\Windows Vista\Windows 7 y adem�s los siguientes OS
ajenos a windows: Linux\Mac OS.

2.6.4.1.1. NIVEL F�SICO.

A nivel f�sico, USB utiliza un cable de 4 conductores para transmitir una se�al
diferencial (D+ y D-) y alimentaci�n (VBus = 5V y GND) por medio de conexiones
punto a punto. Los dispositivos LS van obligatoriamente equipados con un cable de
longitud adecuada (hasta unos 3m, dependiendo de sus caracter�sticas el�ctricas),
mientras que los FS pueden ir equipados con un cable o utilizar cables
independientes de hasta 5m (tambi�n dependiendo de sus caracter�sticas el�ctricas).

La comunicaci�n es bidireccional y semi-d�plex, y utiliza codificaci�n auto reloj

NRZI (la l�nea cambia de nivel si se transmite un 0 y no cambia si transmite un 1)
con "bit stuffing" (inserci�n de un cero tras la transmisi�n de 6 unos, para
asegurar transiciones en la l�nea y permitir que la PLL del receptor se mantenga
sincronizada). Los dispositivos disponen de un transmisor diferencial, receptores
diferencial y S/E y resistencias de terminaci�n con los que pueden transmitir y
detectar varios estados el�ctricos distintos en la l�nea:

� Transmisi�n/Recepci�n diferencial de bits: Estados DIFF0 y DIFF1, denominados

tambi�n estados J y K.
� SE0 (Single-Ended 0): Ambas se�ales D+ y D- a 0V. Se utiliza para detectar la
conexi�n/desconexi�n de dispositivos, para indicar el EOP (fin de paquete) y para
generar reset.
� IDLE: reposo o l�nea en alta impedancia, necesario para permitir
transferencias semi-d�plex, detectar la conexi�n y desconexi�n de dispositivos y
discriminar entre dispositivos FS y LS.
� El SOP (principio de paquete) se indica mediante una transici�n IDLE a K.
� El EOP (fin de paquete) se indica mediante una secuencia SE0 (2 bits) + J (1
bit) + IDLE.
� Detecci�n de dispositivo y discriminaci�n FS/LS: cuando el transmisor deja la
l�nea en IDLE, si hay un dispositivo conectado su polarizaci�n fuerza un estado J
(DIFF0 si LS � DIFF1 si FS), y si no lo hay, la polarizaci�n del transmisor fuerza
un estado SE0.
� Reset: transmisi�n de SE0 durante >= 10 ms.

2.6.4.1.2. PROTOCOLOS DE COMUNICACI�N USB.

El protocolo de nivel f�sico se basa en tokens (testigos). El controlador USB

transmite tokens que incluyen la direcci�n del dispositivo destino, y el
dispositivo que detecta su direcci�n en el Token responde y lleva a cabo la
transferencia de datos con el controlador. De esta manera, el Controlador USB
maneja la parte m�s compleja del protocolo, generando los tokens de transferencias
de datos a 12 Mbps o a 1,5 Mbps, y controlando la conexi�n l�gica entre el sistema
y las funciones internas de cada dispositivo. El controlador USB tambi�n maneja el
consumo en el bus a trav�s de las funciones Suspender/Continuar, por medio de las
cuales controla los modos
Reposo/Activo de los dispositivos. Esta arquitectura permite el dise�o de
dispositivos extremadamente simples y de bajo coste.

USB divide el tiempo en espacios de 1ms denominados Tramas, durante las cuales se
llevan a cabo las comunicaciones a trav�s de Transacciones, las cuales se componen
a su vez de Paquetes. Las transacciones se componen de 3 fases:
Token, Dato y Validaci�n (Handshake):
� La fase de Token se compone de un paquete de Token enviado por el Controlador
USB, y siempre est� presente en toda transacci�n. El paquete contiene los campos:
� PID (identifica el tipo de paquete). Todos los PIDs van protegidos por bits
redundantes,
� Direcci�n del elemento destino (7 bits de dispositivo + 4 bits de elemento
interno al dispositivo), y CRC5.
� La fase de Datos (opcional) se compone de los paquetes de datos que se
transfieren entre el Controlador USB y el dispositivo. Cada paquete se compone de
los campos PID, Datos, y CRC16.
� La fase de Validaci�n (opcional) se usa para indicar el resultado de la
transacci�n. Se compone s�lo de un campo PID.

Adicionalmente, el Controlador USB indica el principio de cada Trama y la

transmisi�n hacia dispositivos LS mediante tokens especiales.

2.6.4.1.3. TRANSFERENCIA DE DATOS.

USB soporta 4 tipos de transferencias de datos:

� Control, para configuraci�n y control de dispositivos y para manejo del bus.

� Is�crono, para transmisi�n de informaci�n con ancho de banda y latencia

garantizadas, necesario para aplicaciones como audio, telefon�a y v�deo. Permite
una comunicaci�n peri�dica y continua entre el sistema y el dispositivo.

� Interrupci�n, para transferencias de pocos datos, no peri�dicas, de baja

frecuencia pero con unos ciertos l�mites de latencia.

� Bulk, para transferencias de grandes cantidades de datos con dispositivos

as�ncronos, como impresoras, esc�neres, c�maras de fotos (foto fija), etc.

El PIC18F4550 soporta la trasferencia interruptiva (Mouse, teclado y cualquier

dispositivo HID) y transferencias tipo Bulk (Paquetes) en dispositivos como por
ejemplo osciloscopios USB.

TRANSFERENCIA DE CONTROL

� Se desarrollan en 3 Transacciones:
� Transacci�n de Configuraci�n (Setup), en la que se env�a al dispositivo un
paquete que especifica la operaci�n a ejecutar. Ocupa 8 bytes.
� Cero o m�s Transacciones de Datos, en las que se transfieren los paquetes de
datos en el sentido indicado por la Transacci�n de Configuraci�n. La informaci�n
�til por paquete puede ser de 8, 16, 32 � 64 bytes para Endpoints FS, y de 8 bytes
para Endpoints LS.
� Transacci�n de Estado, en la que el receptor informa del estado final de la
operaci�n.
� Se procesan por medio de un mecanismo "best effort", seg�n el cual el
Controlador USB las va procesando en funci�n del tiempo disponible en cada Trama.
Como m�nimo se reserva el 10% del tiempo de Trama, y se puede utilizar tiempo
adicional siempre que las necesidades de los tr�ficos is�crono y de interrupci�n lo
permitan.
� Incorporan mecanismos de detecci�n de errores (CRC) y de
recuperaci�n/retransmisi�n de datos.

TRANSFERENCIAS DE INTERRUPCI�N

� Aseguran una transacci�n (paquete) dentro de un periodo m�ximo (los

dispositivos FS pueden solicitar entre 1 y 255ms, y los LS entre 10 y 255ms de
periodo m�ximo de servicio).

� Incorpora detecci�n de errores y retransmisi�n de datos.

� La informaci�n �til por paquete puede oscilar entre 1 y 64 bytes para

dispositivos FS y entre 1 y 8 bytes para dispositivos LS.

� El sistema puede asignar como m�ximo el 90% del tiempo de Trama para
transferencias is�cronas y de interrupci�n. Si el sistema no puede garantizar
tiempo suficiente como para manejar una nueva conexi�n de interrupci�n (transmitir
un nuevo paquete dentro del periodo m�ximo requerido), simplemente no se establece
la conexi�n.

TRANSFERENCIAS BULK

� S�lo son utilizables por dispositivos FS.

� Se procesan por medio de un mecanismo "good effort", en el que el sistema
aprovecha cualquier ancho de banda disponible y en el momento en que est�
disponible (en otras palabras, no se garantiza una latencia ni un ancho de banda
m�nimos). Se puede utilizar el tiempo de Trama reservado y no consumido por
transferencias de Control (10%).
� Incorporan mecanismos de control de errores para garantizar la entrega de
datos.
� La informaci�n �til por paquete puede ser de 8, 16, 32 � 64 bytes.

Estos 4 tipos de transferencias est�n disponibles como interfaces software que el

sistema pone a disposici�n de los manejadores de dispositivo, estando los
manejadores obligados a comunicarse con los dispositivos �nica y exclusivamente a
trav�s de estos 4 interfaces de programaci�n. Esto viene a significar que un
manejador de dispositivo USB jam�s accede directamente al hardware del dispositivo,
y por otro lado significa que todos los dispositivos USB deben cumplir
necesariamente unas especificaciones b�sicas comunes, ya que deben gestionar
adecuadamente los tipos de transferencias que soportan.
Adicionalmente, los dispositivos USB se agrupan en Clases, de forma que todos los
dispositivos de una misma Clase cumplen adem�s con las especificaciones de dicha
Clase, ya que la Clase incide directamente en la manera en que el software
interact�a con el dispositivo.

2.6.4.2. DRIVER (MCHID.DLL).

Es un programa que habilita aplicaciones para poderse comunicar con el dispositivo.

Cada dispositivo sobre el bus debe tener un driver, algunos perif�ricos utilizan
los drivers que trae Windows

3. CAPITULO III

FACTIBILIDAD DEL PROYECTO

3.1. INTRODUCCION

Factibilidad se refiere a la disponibilidad de los recursos necesarios para llevar

a cabo los objetivos o metas se�alados. Generalmente la factibilidad se determina
sobre un proyecto.

3.2. FACTIBILIDAD

3.2.1 FACTIBILIDAD TECNICA

Desde el punto de vista t�cnico, para la realizaci�n del proyecto son necesarios
algunos recursos tecnol�gicos que no son pertinentes de desarrollar, pues el
mercado -tanto nacional como internacional- los ofrece a costos razonables y de
buena calidad.
Para el desarrollo del proyecto -desde el punto de vista t�cnico- existen a lo
menos varias alternativas pero la que ha de ser implementado, es la siguiente
- Para que el sistema logre ser desarrollado y el hardware construido se tendr�
que establecer factores expl�citamente de investigaci�n tanto as� en la parte de
software como la de hardware ya que ambas tendr�n que ir a la par
- Tambi�n para la parte de construcci�n del hardware se tomara muy en cuenta la
parte del dise�o del graficador plotter basado en predise�os ya establecidos para
su construcci�n bajo las normas establecidas de construcci�n
- En la parte de software se tendr� que establecer el hecho de poder guardar
los dise�os realizados con los mismos en un formato que pueda ser reconocido por el
mismo cuando se guarde uno de estos dise�os
- El sistema en si puede seguir mejorando en cuanto a su construcci�n y dise�o
pero no tanto as� su arquitectura ya que esta est� definida ya en el documento
presente

3.2.2. FACTIBILIDAD ECONOMICA

En cuanto a la factibilidad econ�mica del proyecto se pudo determinar los

siguientes aspectos generales:
- El costo de adquisici�n del hardware espec�ficamente es econ�mico comparado
con otros dispositivos de control de nivel liquido ya que todo el proceso l�gico-
operativo consta de realizaci�n propia
- El software en su conjunto est� valuado en una proporci�n espec�fica a la del
desarrollo del mismo ya que el lenguaje de programaci�n en el que se ha de
desarrollar esta accesible en todas partes

3.2.3. FACTIBILIDAD OPERATIVA

Para determinar la factibilidad operativa del proyecto se determin� los siguientes

puntos para el desarrollo del proyecto:
- La construcci�n del control de nivel liquido as� como del software son
posibles de realizar dado que ya existen modelos, de los cuales espec�ficamente
solo se ha de abstraer la l�gica de dise�o y construcci�n
- Tambi�n se vio factible que para iniciar el proyecto se tendr�a que adquirir
piezas de movimiento precisas, dado que en el mercado actualmente existen un mont�n
de piezas de computadora en desuso(por lo general piezas de impresoras en desuso)
se podr� optar por utilizar dichas piezas para la construcci�n del prototipo.
- En la parte de desarrollo del software se pudo apreciar que la construcci�n
del controlador de presencia y llenado de l�quido es posible dado que la
tecnolog�a del lenguaje de programaci�n lo permite

3.3 COSTO DEL SOFTWARE

3.3.1. Estimaci�n del costo del software mediante puntos de funci�n

Lista de Pantallas en el sistema de control de productos

1. Pantalla de Ingreso al sistema (Entrada de datos)
2. Pantalla de monitoreo de control de nivel (Entrada Salida de Datos)
3. Pantalla de configuraci�n de puerto USB (Entrada de Datos)
4. Pantalla de control de verificaci�n de recipientes(Entrada de datos)
5. Pantalla de monitoreo SCADA (Entrada Salida de datos)
6. Pantalla MDI para el men� principal(Entrada Salida de Datos)
7. Pantalla del sistema de Informaci�n de proyectos(Salida de Datos)
8. Pantalla de Registros a solicitud(Salida de Datos)

- Entradas desde el exterior del sistema

Flujos de datos procedentes del exterior de la aplicaci�n.
Ejemplo:
Pantallas de entrada de datos y otros tipos de entradas a trav�s de perif�ricos.
Se evaluar�n los procesos que tienen datos que entran desde el exterior y como
consecuencia actualizan alg�n fichero l�gico, el proceso es completo y exclusivo de
entradas
Para establecer las pantallas de donde la entrada de datos sea desde el exterior se
tienen las siguientes pantallas de entrada de datos
DIFICULTAD Numero de Campos o Atributos de la Entrada.
ENTRADAS 1-4 Atributos. 5-15 Atributos 16 o m�s Atributos
0 o 1 Ficheros accedidos Baja 3 Baja 3 Media 6
2 Ficheros accedidos Baja 3 Media 6 Alta 9
3 o + Ficheros accedidos Media 6 Alta 9 Alta 9

- Salidas al exterior del sistema.

Flujos de datos procedentes de procesos que transmiten informaci�n al usuario o a
otra aplicaci�n.
Ejemplo:
Pantallas de introducci�n de informaci�n, listados y comunicaci�n con otras
aplicaciones.
Se evaluar�n los procesos que env�an datos al exterior, el proceso es completo y
es exclusivo de salida.
DIFICULTAD Numero de Campos o Atributos de la Salida.
SALIDAS 1-5 Atributos. 6-19 Atributos 20 o m�s Atributos
0 o 1 Ficheros accedidos Baja 4 Baja 4 Media 5
2 o 3 Ficheros accedidos Baja 4 Media 5 Alta 7
4 o + Ficheros accedidos Media 5 Alta 7 Alta 7

- Consultas
Las consultas son procesos que combinan flujos de datos procedentes de entrada y
salida. Los procesos no modifican la informaci�n del sistema
Ejemplo:
Pantallas de consulta de informaci�n.
Se evaluaran los procesos que reciben una petici�n del exterior y como consecuencia
se env�an datos al exterior, no se recuperan datos, no se calculan datos derivados
y el proceso no actualiza ficheros internos.
DIFICULTAD Numero de Campos o Atributos de la Salida.
SALIDAS 1-5 Atributos. 6-19 Atributos 20 o m�s Atributos
0 o 1 Ficheros accedidos Baja 4 Baja 4 Media 5
2 o 3 Ficheros accedidos Baja 4 Media 5 Alta 7
4 o + Ficheros accedidos Media 5 Alta 7 Alta 7

- Ficheros l�gicos internos

Los Ficheros L�gicos Internos son agrupaciones de datos tal y como los ve el
usuario (pantallas de ingreso de datos).
Ejemplo:
Clientes, Art�culos, Facturas.
Los ficheros se cuentas una sola vez independientemente del n�mero de procesos. Se
contaran los ficheros que son una agrupaci�n l�gica de datos identificable por el
usuario, los datos que son mantenidos por nuestra aplicaci�n y la agrupaci�n de
datos que no ha sido contada como un fichero de interfaz externo.
DIFICULTAD Numero de Campos o Atributos de la Salida.
LOGICOS 1-19 Atributos. 20-50 Atributos 51 o m�s Atributos
1 Entidad Baja 7 Baja 7 Media 10
Reg. L�gico
2-5 Entidad Baja 7 Media 10 Alta 15
Reg. L�gico
6 +Entidad Media 10 Alta 15 Alta 15
Reg. L�gico

- Ficheros l�gicos externos

Los Ficheros L�gicos Externos son agrupaciones de datos tal y como los ve el
usuario pero que no est�n mantenidos por esta aplicaci�n.
Ejemplo:
Ficheros de C�digos Postales o informaci�n de ficheros que se utilizan solo para
consultas.
Contaremos los ficheros que son una agrupaci�n l�gica de datos identificable por el
usuario, los datos son mantenidos por otra aplicaci�n y la agrupaci�n de datos no
ha sido contada como un fichero de interfaz interno.
DIFICULTAD Numero de Campos o Atributos de la Salida.
DE INTERFAZ 1-19 Atributos. 20-50 Atributos 51 o m�s Atributos
1 Entidad Baja 5 Baja 5 Media 7
Reg. L�gico
2-5 Entidad Baja 5 Media 7 Alta 10
Reg. L�gico
6 + Entidad Media 7 Alta 10 Alta 10
Reg. L�gico

- Elementos de la funci�n
Tipo De Elemento Dificultad Peso Cantidad Total Puntos Total Elemento
Entradas Simple 3 3 9
Media 4 1 4
Compleja 6 0
Total Puntos de Funci�n Entradas: 13
Salidas Simple 4 2 8
Media 5 3 15
Compleja 7 1 7
Total Puntos de Funci�n Salidas: 30
Consultas Sal Simple 4 1 4
Ent Media 4 4 16
Sal Media 5 0
Ent Compleja 6 0
Sal Compleja 7 0
Total Puntos de Funci�n Consultas: 20
Fich. Internos Simple 7 3 21
Media 10 0 0
Compleja 15 0
Total Puntos de Funci�n Ficheros Internos: 21
Fich. Interfaces Simple 5
Media 7
Compleja 10
Total Puntos de Funci�n Ficheros Interfaces: 0
Total Puntos de Funci�n sin ajustar 84

- Factores de complejidad
En esta fase se medir� las caracter�sticas externas de la aplicaci�n bas�ndose en
el entorno donde la aplicaci�n se implantar�, se valorar� una serie de factores de
complejidad (14 en total) evalu�ndolos en una escala de 0 al 5, de menor a mayor
complejidad.

Nro Factor de Complejidad Descripci�n del Valor Valor

1 Comunicaci�n de Datos Sistema Aislado 0
2 Proceso Distribuido Sistema Totalmente Centralizado 2
3 Rendimiento Rendimiento estudiado durante el dise�o, pero sin especiales
requerimientos 4
4 Configuraci�n Operacional Compartida Existen las restricciones usuales
1
5 Ratio de Transacciones Se prev�n horas puntas diarias 3
6 Entrada de Datos EN-LINEA Las entradas de datos interactivas superan el
30 % 4
7 Eficiencia con el Usuario Final Seis o m�s factores 3
8 Actualizaciones en L�nea Actualizaci�n en l�nea de ficheros l�gicos
importantes 3
9 Complejidad del Proceso Interno La aplicaci�n llevar� incorporados
sistemas de seguridad y control 1
10 Reusabilidad del C�digo Se pretende reutilizar entre 40% y el 50 % 0
11 Contempla la Conversi�n de e Instalaci�n Se ha solicitado Facilidad de
instalaci�n 1
12 Facilidad de Operaci�n Se proveer� de procesos de arranque, back-up y
recuperaci�n, pero con operador 1
13 Instalaciones M�ltiples Un solo lugar 0
14 Facilidad de Cambios El Sistema puede tener cambios medios 3
Factor De Complejidad Total 26
- Puntos de funci�n ajustados

- Estimaci�n de esfuerzo requerido por la aplicaci�n

En esta fase de la planificaci�n temporal se realizar� una aproximaci�n de la
cantidad de horas de trabajo necesarias para realizar este proyecto. En base a las
estad�sticas de producci�n de la empresa se obtiene una media de las horas de
trabajo necesarias para cada punto de funci�n, esta aproximaci�n depender� de
varios factores como el lenguaje de programaci�n y la experiencia de los
trabajadores.
Entorno Lenguaje Horas / Punto Funci�n L�neas C�digo/PuntoFunci�n
Ensamblador 20 a 30 300
Cobol 10 a 20 100
Lenguajes 4GL 5 a 10 20
C 10 a 15
Visual Basic 5 a 10 ( aprox )
Delphi 4 a 8 ( aprox )

- Calculo del esfuerzo

La f�rmula para el c�lculo del esfuerzo ser�:
Esfuerzo = PFA * Promedio Organizaci�n (Lenguaje)

Aplicando al ejemplo pr�ctico y considerando como herramienta para el desarrollo el

lenguaje Delphi, en esta planificaci�n realizaremos una aproximaci�n de 5
Horas/Punto Funci�n.

Aplicando la formula anterior el c�lculo del esfuerzo ser�:

Esfuerzo = 76,44 * 5 ( P .F * Horas d�a) = 382.2 Horas

Esfuerzo = 382.2 / 8 (Horas / Horas D�a) = 47 D�as
Esfuerzo = 47 / 20 ( D�as / D�as Mes ) = 2,3 Meses (aprox.)
- Descomposici�n de esfuerzos por fase

Planificaci�n del sistema 4%

An�lisis y especificaci�n de requisitos 10%
Medici�n y estimaci�n 10%
Adaptaci�n de nuevos entornos y aprendizaje 10%
Dise�o 30%
Implementaci�n 25%
Pruebas 5%
Documentaci�n 3%
Formaci�n Usuario Final 3%
100%

- Presupuesto para la aplicaci�n

El costo de la aplicaci�n a desarrollar se calcula en funci�n de las horas
dedicadas en su implementaci�n obtenidas de la planificaci�n estimada, este c�lculo
proporcionar� el costo del software, la aplicaci�n se instala incluyendo como
hardware un servidor central multiusuario.

Para el c�lculo del costo de Software, se realizar� aplicando el costo de la mano

de obra en funci�n de los diferentes salarios para: analistas, programadores, etc.

- Presupuesto del software

APLICACIONES Porcentaje de tiempo empleado Tiempo en horas por
aplicaci�n Costo de mano de obra hora Costo total mano de obras por aplicaci�n
Planificaci�n elemental de sistemas 4 10 50 500
An�lisis y especificaci�n de requisitos 10 100 50 5000
Medici�n y estimaci�n 10 24 50 1200
Adaptaci�n a nuevos entornos y aprendizaje 10 38 50 1900
Dise�o 30 120 50 6000
Implementaron 25 40 40 1600
Pruebas 5 20 35 700
Documentaci�n 3 20 35 700
Formaci�n usuario final 3 10 30 300
Costo total en Bs. 17900
Costo total en D�lares (7.06) 2535,4108

- Presupuesto del hardware

Procesador Intel Pentium i5 2600 MHz
Memoria 2 GB DDRIII BUS 1024 KINGSTON
Disco duro 500 GB HITACHI
Tarjeta de sonido SoundBlaster 128
Tarjeta gr�fica GFORCE GTX 260 XTREME
Tarjeta Madre DP55KG Extreme Series
Lector y grabadora CD-ROM 8x 4x 32x
DVD 8x 4x
M�dem interno Fax-M�dem interno 56K
Altavoces Dolby Surround
Monitor 17'� panor�mico HD Samsung
Micr�fono De sobremesa
Teclado Multimedia
Rat�n Intellimouse de Microsoft
Impresora L�ser HP
Scanner HP
Lector de c�digo de barras Microsoft
Software Microsoft Windows XP Licencia Original comp.2600

Costo en Bolivianos Bs. 21.550.00

Costo en d�lares $ 2.773.50

- Oferta al cliente
Bs. $us
Costo total de Software 17.900,00 3,535
Costo total de Hardware 21.550,00 2.773
Costo total del Proyecto 44.534,00 6,308

4. CAPITULO IV.
DISE�O Y DESARROLLO DEL PROYECTO
4.1. DESCRIPCI�N GENERAL.
4.1.1. SISTEMA UMA SYSTEM V2

El sistema de informaci�n lleva el nombre de �UMA SYSTEM V2� cuyo nombre significa
Sistema de Aguas automatizado para el llenado de recipientes de agua.

4.1.2. DESCRIPCI�N DEL SISTEMA.

El sistema ofrece la supervisi�n de llenado de recipientes de agua mediante un

sistema de control automatizado as� como la incorporaci�n de varias funciones y
herramientas que ofrecen al usuario final en cuanto a los requerimientos y
solicitudes para el producto final.
4.1.3. HERRAMIENTAS EMPLEADAS.

Se opt� por seleccionar herramientas capaces de interactuar con la interfaz USB

para el desarrollo de la aplicaci�n.

Por un lado se emple� Delphi como herramienta de desarrollo mientras que como motor
de base de datos se decidi� por SQL Server. A continuaci�n se detalla cada una de
estas planteando motivos por los cuales fueron seleccionadas.

4.1.3.1. DELPHI.

Delphi es un entorno de desarrollo de software dise�ado para la programaci�n de

prop�sito general con �nfasis en la programaci�n visual tanto en la programaci�n
orientada a objetos como a la programaci�n orientada a eventos y el manejo de base
de datos a nivel cliente - servidor.

El primer motivo por lo que se seleccion� Delphi como herramienta de desarrollo, es

el amplio conocimiento que se tiene del lenguaje. En segundo lugar Delphi tiene la
capacidad de manejar e interactuar con el puerto USB a trav�s de la DLL mchid.dll
especialmente para proyectos electromec�nicos.

4.1.3.2. SQL SERVER

Es el motor de base de datos empleado para el proyecto. Se caracteriza por ser uno
de los servidores de base de datos m�s robustos raz�n por la cual motivaron su
selecci�n.

4.1.4. DESCRIPCI�N DEL NEGOCIO.

Se trata de una planta encargada de control de nivel l�quido a nivel industrial el

cual solo contaba con medidas est�ndares para el control sin que se cuente con un
registro exacto tanto de ingreso como las salidas del l�quido a lo cual se qued� de
acuerdo en desarrollar e implementar un software de control adem�s de automatizar
las etapas cumpliendo as� con los requerimientos espec�ficos.

4.1.5. DESCRIPCI�N DEL CLIENTE Y USUARIO.

Para este proyecto se cuenta con tres usuarios de los cuales uno es el cliente.

Uno.- El usuario con el que se cuenta es el cliente, una persona con los
conocimientos b�sicos acerca del manejo del computador y de paquetes software,
quien a la vez ya lleva bastante interacci�n con la planta quien nos facilitara
acerca de los requerimientos que precise el sistema.

Dos.- Una persona que lleva en su curr�culo formaci�n acad�mica con conocimientos
en inform�tica o ingenier�a de software ya sea a nivel t�cnico superior o
ingenier�a capaz de manejar y supervisar el sistema de informaci�n a trav�s de un
ordenador.

Tres.- Una persona que cuenta con conocimientos de inform�tica como tambi�n de
electromec�nica capaz de realizar la supervisi�n de los dispositivos en la planta.

4.2. DISE�O DEL SISTEMA DE INFORMACI�N.

4.2.1. ESPECIFICACI�N DE REQUERIMIENTOS.

4.2.1.1. REQUERIMIENTOS FUNCIONALES.

C�digo de requerimiento

Descripci�n

CNL � RF001 Registrar el nivel actual (Cantidad de l�quido)

CNL � RF002 Realizar registros de control de acuerdo a par�metros en solicitud por
el usuario.
CNL � RF003 Capturar informaci�n acerca de los sensores y/o motores
(si est� activo o no)
CNL � RF004 Emitir Reportes Con los niveles l�quidos m�nimos y m�ximos
CNL � RF005 Tener un ID de acceso (Gerente, administrador, empleado)
CNL � RF006 Registrar usuarios con los datos necesarios
CNL � RF007 Elaborar informes de control de recipientes completados con rangos de
fecha establecidos en por el usuario.
CNL � RF008 Tener un sistema autom�tico de Control de recipientes de nivel liquido.

CNL � RF009 Verificar el estado de las electrov�vulas.

4.2.1.2. REQUERIMIENTOS NO FUNCIONALES.

C�digo de requerimiento

Descripci�n

CNL � RNF001

Utilizar cualquier tipo de liquido

CNL � RNF002

Tipo de recipiente a ser empleado

CNL � RNF003

La electrov�lvula para el cierre autom�tico

CNL � RNF004
Estado de los recipientes a ser llenados

CNL � RNF006
Estado del motor pasa banda.

4.2.1.2.1. REQUERIMIENTOS DE USUARIO.

C�digo de requerimiento

Descripci�n

CNL- RU001
El administrador tendr� acceso total al sistema
CNL-RU002
El administrador podr� dar privilegios a otros sin desmerecer al mismo
CNL-RU003
El administrador tendr� acceso a todos los reportes.

4.2.1.2.2. REQUERIMIENTOS DE HARDWARE.

C�digo de requerimiento

Descripci�n

CNL-RH001
Memoria RAM m�nimo de 1 GB o superior a condiciones previas de optimizaci�n.
CNL-RH002
Microprocesador m�nimo de 2.3 GHz Pentium D o superior.

CNL-RH003
El ordenador deber� contar con un puerto USB esto por motivo de la interfaz

CN�-RH004
Teclado, Mouse, Impresora, Monitor perif�ricos b�sicos para el funcionamiento
del sistema

CNL-RH005
Prototipo de la planta (maqueta)
CNL-RH006
Microcontrolador 18F45550 para la comunicaci�n USB
CNL-RH007
Sensores y actuadores necesarios para el control
CNL-RH008
Componentes el�ctricos necesarios para la funcionalidad

4.2.1.2.3. REQUERIMIENTOS DE SOFTWARE.

C�digo de requerimiento

Descripci�n

CNL � RS002
Sistema Operativo Windows XP SP2 o SP3

CNL �RS003
Motor de Base de Datos SQL SERVER
CNL - RS004
Proteus 7.6 SP0 para la simulaci�n de circuitos electr�nicos

CNL � RS005
Delphi 7 para el desarrollo del sistema
CNL � RS006
Pic Basic Pro 2.5b + MicroCode Studio 3.0 para programaci�n de
microcontroladores PIC y compilador de archivos .HEX

CNL � RS007
Crystal Reports 8.0 para la generaci�n de reportes
CNL � RS008
 Microsoft Visio para el dise�o de la base de datos
CNL � RS009
Entrenador y Drivers para la comunicaci�n USB

4.2.2. IDENTIFICACI�N DE CASOS DE USO.

- Caso de uso 1.- Autenticaci�n de Usuario

- Caso de uso 2.- Verificaci�n de los dispositivos
- Caso de uso 3.- Detecci�n de nivel m�ximo
- Caso de uso 4.- Verificaci�n de nivel de los recipientes llenados
- Caso de uso 5.- Registro de llenado
- Caso de uso 6.- Solicitud de reportes.
- Caso de uso 7.- ABC de usuarios.
- Caso de uso 8.- Registro de recipientes completados.
- Caso de uso 9.- Presencia de Recipientes.

CNL - CU001 AUTENTICACI�N DE USUARIO

El usuario deber� autenticarse, su ID como el password deber� estar almacenado en

la base de datos de UMA SYSTEM.

CNL-CU002 VERIFICACION DE DISPOSITIVOS

En primera instancia se deber� solicitar al sistema un reporte acerca del estado de

los dispositivos.

CNL-CU003 DETECCION DE NIVEL M�XIMO

El sistema verificara si los sensores est�n en condiciones de lectura correcta

tanto en el nivel m�ximo como el sensor de emergencia.

CNL � CU004 REGISTRO DE LLENADO

El registro de nivel deber� ser establecido en los intervalos de guardado seg�n el

administrador.

CNL � CU005 SOLICITUD DE REPORTES

La solicitud de reportes estar� de acuerdo a cada usuario y los privilegios con los
que este cuente.

CNL � CU006 ABC DE USUARIOS

Las Altas, Bajas y Cambios (ABC) de los usuarios estar� acorde de privilegios
establecidos por el administrador.

CNL � CU007 REGISTRO DE RECIPIENTES COMPLETADOS

El sistema contara con un registro de cada recipiente completado (llenado) que el

sistema despache.

CNL � CU008 PRESENCIA DE RECIPIENTE

El sistema contara con un dispositivo de verificaci�n de presencia (final de

carrera), encargado de detectar la presencia del recipiente en el punto de llenado.
4.2.3. IDENTIFICACI�N DE ACTORES

4.2.4. DESCRIPCI�N DE CASOS DE USO.

CNL � CU001 : AUTENTIFICACI�N DE USUARIO

Caso de Uso: Autentificaci�n de usuario.
Actores: Usuario, Personal Involucrado e intereses:
Pasos:
Acci�n de los actores Respuesta del sistema
1. Usuario quiere ingresar el sistema para su manejo y adquisici�n del mismo
2. Solicita ID y password de usuario
3. Usuario accede al sistema 4. Devuelve un resultado al usuario para ver
si este cuenta con permisos o no a ingresar al sistema.
5. Deber� Registrar la hora de ingreso y salida del usuario conectado,
caso contrario deber� almacenar la hora de intento de ingreso al sistema.

CNL � CU002 VERIFICACION DE DISPOSITIVOS

Caso de Uso: Verificaci�n de Dispositivos
Actores: Usuario personal Involucrado e intereses.
Pre- condici�n: Los dispositivos verifican los estados de control.
Pasos.
Acci�n de Actores Respuesta del Sistema
1. Usuario Solicita estado de Dispositivos. 2. Sistema Verifica si esta
autorizado o no.
3. De ser aceptado el sistema devuelve la respuesta de estado de dispositivos.
4. Usuario Recepciona resultados en pantalla. 5. Ejecuta las medidas de
seguridad y detiene el sistema.

CNL � CU003 DETECCION DE NIVEL MAXIMO

Caso de Uso: Verificaci�n de Dispositivos
Actores: Usuario, personal involucrado, Sensor Aislador.
Pre- condici�n: El sensor aislador deber� encontrarse en buen estado.
Acci�n de Actores Respuesta del Sistema
1. Sensor Captura el nivel m�ximo en datos del nivel m�ximo del liquido. 2.
Detiene todo el proceso hasta la verificaci�n de Rearme por parte del
usuario.
3. El Usuario realiza la verificaci�n y la reparaci�n seguida si es necesario, y
pulse la activaci�n de Rearme. 4. Cuando Rearme este activo el sistema
iniciara nuevamente sus actividades.
CNL � CU004 REGISTRO DE LLENADO
Caso de Uso: Registro de Llenado
Actores: Final de Carrera.
Pre- Condici�n.- El Final de Carrera se deber� encontrar en perfectas condiciones.
Pasos:
Acci�n de Actores Respuesta del Sistema
1. Final de Carrera captura el pulso de presencia de Recipiente. 2.
Registra el n�mero de envase por c�digos una vez verificado el estado.
3. Final de carrera deja de enviar pulso. 4. Sistema espera nuevo envase.

CNL � CU005 SOLICITUD DE REPORTES.

Caso de Uso: Solicitud de Reportes
Actores: Usuario, empleados involucrados.
Pre � Condici�n: El usuario deber� tener los privilegios necesarios patra la
solicitud.
Pasos:
Acci�n de Actores Respuesta del Sistema
1. El usuario Solicita los reportes (usuario, recipientes, acceso) 2.
Sistema genera la solicitud del usuario de acuerdo a precondiciones de
codificaci�n.
3. El usuario visualiza en pantalla el reporte y advierte la posibilidad de
imprimir 4. El sistema realiza un backup, registra el reporte de solicitud
por parte del usuario.

CNL � CU006 ABC DE USUARIOS

Caso de Uso: Altas, Bajas y Cambios (ABC) de usuarios
Actores: Usuario, empleados involucrados
Pre � Condici�n: EL usuario deber� contar con los privilegios necesarios para tal
acci�n.
Pasos:
Acci�n de Actores Respuesta del Sistema
1. El usuario ingresa hacia el �rea de administraci�n de usuarios 2.
Verifica si el usuario est� o no autorizado para la administraci�n en caso
contrario es enviado a la pantalla de autenticaci�n.
3. El usuario visualiza en pantalla la lista de usuarios. 4. Da al
usuario la alternativa de A�adir, Borrar, Cambiar privilegios de usuarios.

CNL � CU007 REGISTRO DE RECIPIENTES COMPLETADOS.

Caso de Uso: Registro de Recipientes Completados
Actores: Final de Carrera (Dispositivo de Pulso)
Pre � Condicion: El dispositivo se deber� encontrar en �ptimas condiciones.
Pasos:
Acci�n de Actores Respuesta del Sistema
1. El final de carrera detecta la presencia del recipiente mediante un pulso.
2. El sistema detecta el pulso y registra el n�mero de recipiente, fecha y
hora en que fue emitido el dato.
3. El pulso por parte del final de carrera es desactivado. 4. El sistema
est� en espera de un nuevo registro.

CNL � CU008 PRESENCIA DE RECIPIENTE

Actores: Final de Carrera (Dispositivo de Pulso)
Pre � Condici�n: El dispositivo se deber� encontrar en �ptimas condiciones.
Pasos:
Acciones del Actor Respuesta del Sistema
1. El dispositivo emite un pulso de accionamiento 2. El sistema lo interpreta
como un dato.
3. El pulso activa la v�lvula de llenado de recipientes. 4. El sistema
detiene el avance recipientes.

4.2.5. DIAGRAMA DE SECUENCIAS.

4.2.6. DIAGRAMA DE ACTIVIDADES.
Iniciar Sesi�n en el Sistema

Iniciar el proceso de llenado

Iniciar la aplicaci�n de conteo de recipientes completados

4.2.7. IDENTIFICACI�N DE CLASES.

- Usuario
- Sensor de Presencia (final de carrera)
- Tanque Contenedor de Liquido
- Bomba de L�quido
- Sensor Aislador
- Acceso al Sistema
- Control de Recipientes llenados

4.2.8. AN�LISIS DE CLASES.

- CNL� IDC001 USUARIO. Es el encargado de Operar, Supervisar el sistema.

- CNL- IDC002 SENSOR DE PRESENCIA (FINAL DE CARRERA). Es el encargado de afirmar o
negar la presencia de un recipiente en el punto de llenado.

- CNL- IDC003 TANQUE CONTENEDOR DE L�QUIDO. Contenedor encargado de proveer l�quido

a los recipientes.

- CNL- IDC004 BOMBA DE L�QUIDO. Encargado de fluido del l�quido del ducto del
tanque.

- CNL- IDC005 SENSOR AISLADOR. cumple una funci�n de seguridad en caso de

desbordamiento de l�quido cuando el sensor de nivel no logra detectar el nivel
m�ximo del tanque.

- CNL- IDC006 CONTROL DE RECIPIENTES LLENADOS. Contiene los par�metros para el

llenado de recipientes establecidos previamente.

4.2.9. DIAGRAMA DE CLASES.

4.2.10. RELACIONES ENTRE CLASES.

4.2.11. DISE�O DE LA BASE DE DATOS.

4.2.11.1. MODELO L�GICO DE DATOS.

4.2.11.1.1. IDENTIFICACI�N DE ATRIBUTOS.

4.2.11.1.2. IDENTIFICACI�N DE OPERACIONES.

4.2.11.2. MODELO F�SICO DE DATOS.

4.2.11.3. APLICACI�N DEL PSP.

Todo profesional software deber�a conocer su propio rendimiento.

Deber�a medir, seguir/controlar y analizar su trabajo.
Deber�a aprender de las variaciones de su rendimiento.
Deber�a incorporar esas lecciones a su manera personal de hacer las cosas.
Un PSP estable permite
? estimar y planificar el trabajo
? cumplir los compromisos
? resistir a presiones de compromiso no razonables

Con un PSP estable, tambi�n se podr�

? comprender nuestras capacidades
? estar m�s posibilitado para mejorar
Un PSP tambi�n proporciona
? Una base probada para desarrollo y pr�ctica de las disciplinas personales de
la industria.

? Una disciplina que muestra como mejorar el proceso personal.

? Los datos para mejorar de manera continua la productividad, calidad, y el

grado de predicci�n de trabajo
Un PSP es un proceso personal para desarrollar software.
? pasos definidos
? formularios
? est�ndares

Un PSP es un marco de trabajo de medici�n y an�lisis que nos ayuda a caracterizar

nuestro proceso.

Es tambi�n un procedimiento definido para ayudar a mejorar nuestro rendimiento.

- Control de tiempo de tareas
Tabla de control de Tareas por fecha ejemplo

Estudiante fecha
Instructor Nro Programa

fecha Inicio Parada Tiempo Interrupci�n Fecha delta Paso Comentario

01-oct 8:00 10:00 30 90 an�lisis
04-oct 10:00 12:00 0 120 dise�o
05-oct 7:00 10:00 60 120 programaci�n
08-oct 14:00 15:00 10 50 prueba
09-oct 7:00 8:00 0 60 Implementaci�n

- Gu�a de procesos

- Resumen Plan PSP

? Defect - To Date - indica el total de defectos inyectados y eliminados en
cada fase hasta hoy. Para el programa 1A, son los defectos inyectados y eliminados
en el programa 1A.

? Defect - To Date % - indicar el porcentaje sobre el total defectos

inyectados y eliminados hasta hoy en cada fase.
Log de registro de tiempos del PSP0

Table C14 PSP0 Project Plan Summary

Estudiantes Mamani Gutierrez Miguel

Mendoza Quispe Rodrigo

Portocarrero Ulloa Ronald Date 21/09/2010

Programa Control de Nivel Liquido Programa # 2
Instructor Ing. Adrian Quisbert Language Borland Delphi

Time in Phase (min.) Plan Actual Ha fecha To Date %

Planificaci�n 120 120 28,92%
Dise�o 120 240 51,57%
C�digo 50 290 69,88%
Compilaci�n 60 350 70/83
Testeo 60 410 98,80%
Inicio prematuro 5 415 100,00%
Total 500 415

Defectos detectados Actual Ha fecha To Date %

Planificaci�n 0 0 0,00%
Dise�o 0 0
C�digo 11 11
Compilaci�n 1 12
Prueba 39 50
Total Desarrollo 50

Defectos Removidos Actual Ha fecha To Date %

Planificaci�n 0 0 0,00%
Dise�o 0 0
Codificaci�n 12 12
Compilaci�n 1 13
Prueba 39 52
Total Desarrollo 52
After Development

5. CAPITULO V

PRUEBAS Y CALIDAD DEL SOFTWARE

5.1 INTRODUCCION
La calidad del producto software se diferencia de la calidad de otros productos de
fabricaci�n industrial, ya que el software tiene ciertas caracter�sticas
especiales:
? El software es un producto mental, no restringido por las leyes de la F�sica
o por los l�mites de los procesos de fabricaci�n. Es algo abstracto, y su calidad
tambi�n lo es.
? Se desarrolla, no se fabrica. El coste est� fundamentalmente en el proceso de
dise�o, no en la producci�n. Y los errores se introducen tambi�n en el dise�o, no
en la producci�n.
? El software no se deteriora con el tiempo. No es susceptible a los efectos
del entorno, y su curva de fallos es muy diferente de la del hardware. Todos los
problemas que surjan durante el mantenimiento estaban all� desde el principio, y
afectan a todas las copias del mismo; no se generan nuevos errores.
? Es artesanal en gran medida. El software, en su mayor�a, se construye a
medida, en vez de ser construido ensamblando componentes existentes y ya probados,
lo que dificulta a�n m�s el control de su calidad. Aunque se ha escrito mucho sobre
la reutilizaci�n del software, hasta ahora se han conseguido pocos �xitos
tangibles.
? El mantenimiento del software es mucho m�s complejo que el mantenimiento del
hardware. Cuando un componente hardware se deteriora se sustituye por una pieza de
repuesto, pero cada fallo en el software implica un error en el dise�o o en el
proceso mediante el cual se tradujo el dise�o en c�digo m�quina ejecutable.
? Es enga�osamente f�cil realizar cambios sobre un producto software, pero los
efectos de estos cambios se pueden propagar de forma explosiva e incontrolada.
? Como disciplina, el desarrollo de software es a�n muy joven, por lo que las
t�cnicas de las que disponemos a�n no son totalmente efectivas o no est�n
totalmente calibradas.
? El software con errores no se rechaza. Se asume que es inevitable que el
software presente errores.

5.2 PRUEBA DE LA CAJA NEGRA

DEFINICI�N DE CALIDAD DEL SOFTWARE

� La calidad est� de moda, en todos los aspectos, pero especialmente en el

desarrollo de software. El inter�s por la calidad crece de forma continua, a medida
que los clientes se vuelven m�s selectivos y comienzan a rechazar los productos
poco fiables o que realmente no dan respuesta a sus necesidades. Ahora bien, �qu�
es la calidad del software?
� Seg�n Denomina, calidad es �Conformidad con los requisitos y confianza en el
funcionamiento�
� Seg�n Juran, calidad es �Adecuaci�n para su uso�
� Crosby pone m�s �nfasis en la prevenci�n: �hacerlo bien a la primera�
� Veamos otras definiciones de calidad extra�das de est�ndares internacionales:
� �La calidad es la suma de todos aquellos aspectos o caracter�sticas de un
producto o servicio que influyen en su capacidad para satisfacer las necesidades,
expresadas o impl�citas� (ISO 8402)
� �Grado con el cual el cliente o usuario percibe que el software satisface sus
expectativas� (IEEE 729-83)
� �Capacidad del producto software para satisfacer los requisitos establecidos�
(DoD 2168)
�
a. CASOS DE PRUEBAS

Para la aplicaci�n de casos de prueba se pudo evidenciar que la aplicaci�n de

dise�o espec�ficamente puede ser establecida con algunos errores de captura de
datos hacia la base de datos
Tambi�n se estableci� que los errores se dan com�nmente en tiempo de ejecuci�n
dando lugar a pruebas de establecimiento que pueden generarse al abrir una nueva
aplicaci�n dada.

5.3 PRUEBA DE LA CAJA BLANCA

- Para el establecimiento de la pruebas de caja blanca se dio oportuno probar
cada m�dulo del sistema
- Oportunamente se vio que los errores fueron aprendidos en los siguientes
m�dulos

o Pantalla de control de llenado de Recipientes.

? Errores de compilaci�n
? Errores de envi� de informaci�n a la base de datos
? Errores de conexi�n con interfaz usb
? Errores de configuraci�n puerto usb

* Pantalla de sistema de informaci�n de proyectos

- Errores de captura de imagen de cada proyecto
- Errores de captura de datos de la base de datos
- Errores de compilaci�n de c�digo

- En las otras pantallas se dio los errores comunes de compilaci�n de c�digo as�
como el establecimiento de par�metros de entrada y salida de datos hacia el sistema
de control l�quido.

6. CAPITULO VI

ARQUITECTURA DEL SOFTWARE Y MANTENIMIENTO

6.1 IMPLEMENTACION

6.1.1.1 PANTALLAS DEL SISTEMA

PANTALLA DE CARGA DE APLICACIONES DEL SISTEMA.

PANTALLA DE ATENTICACION DE USUARIO

PANTALLA DE ADMINISTRACION DE USUARIOS

PANTALLA DE BUSQUEDA DE DATOS DE CONTROL.

PANTALLA DE REGISTRO DE CONTROL

PANTALLA DE MONITORIZACION DEL SISTEMA.

7. CAPITULO VII
CONCLUSIONES
7.1 CONCLUSIONES

Se pudo evidenciar que la aplicaci�n y dise�o de sistema de control en el prototipo

se hace complicado a medida que el proyecto va creciendo en cuanto al an�lisis de
sus requerimientos dado que el simple hecho de aumentar un simple acci�n al
hardware a controlar, implica muchas modificaciones de dise�o.

Por otra parte se pudo destacar las facilidades que ofrece el lenguaje de
programaci�n Delphi el cual cuenta con la l�gica de paquetes que cumplen funciones
espec�ficas de dise�o y construcci�n en modulo determinado del proyecto claro
ejemplo: el dise�o de sistema SCADA se lo realizo con un componente ya creado en el
lenguaje LAVIEW, as� como un componente que efect�a la transferencia de datos por
puerto USB.

Otra fase que paso la construcci�n y dise�o del sistema fue la parte de
construcci�n de la transportadora de recipientes el cual tendr�a que contar con
especificaciones de movimiento de rotaci�n izquierda para ejecutar el traslado y
movimiento de los recipientes.

En otra fase de construcci�n se pudo ver que la aplicaci�n de dise�o de

activaci�n de pulsos el cual pudo ser construidos con algoritmos de determinaci�n
de control condicionales el cual se encargaba de enviar como de recibir datos en
intervalos porcentuales.