MODELO DE CALIDAD

El modelo de calidad que utilizaremos en la realizacin de nuestro proyecto va a ser de

COMPETISOFT que es basado en CMMI
CMMI
CMMI (Capability Maturity Model Integration) es un marco de referencia desarrollado por el SEI
(Software Engineering Institute) para determinar el nivel de madurez que han alcanzado las
organizaciones en funcin del nivel de capacidad de sus procesos involucrados en el desarrollo de
software. La estructura de CMMI se compone de 22 reas de Procesos agrupadas en 4 categoras.
CMMI dispone de dos representaciones [SEI, 2006]:
Representacin Continua, permite seleccionar los procesos a ser mejorados y otorga un
nivel de capacidad individual por cada rea de Proceso. La decisin acerca del proceso a
mejorar obedece a las necesidades de la organizacin.
Representacin por Etapas, permite elegir un grupo de reas de Proceso, predefinidas por
el modelo, sobre las cuales la organizacin centrar sus esfuerzos y una vez que se cubran
todas las reas de proceso de un nivel n se podr afirmar que la organizacin ha
alcanzado el nivel de madurez n.
El modelo CMMI define cinco niveles de madurez para las organizaciones, los cuales se alcanzarn
en la representacin por etapas mientras que para los procesos, define seis niveles de
capacidad, los cuales se alcanzarn en la representacin continua.
El cumplimiento de lo definido por CMMI se concretiza a travs de prcticas agrupadas en 22
reas de Proceso y stas a su vez estn agrupadas en cuatro categoras (Gestin de Proyectos,
Ingeniera, Soporte, Gestin de Procesos) [SEI, 2006].
A continuacin, se muestran los niveles de madurez de la organizacin segn CMMI.




En la siguiente tabla se muestran los niveles de capacidad de procesos.







COMPETISOFT nace como otra alternativa a los grandes marcos metodolgicos para el
mejoramiento de los procesos, constituyndose como una opcin atractiva para las PYME, pues
fue pensado para stas y su adopcin considera esfuerzo y despliegue de recursos proporcionales
a sus posibilidades. COMPETISOFT es un proyecto creado para incrementar el nivel de
competitividad de las PYME Iberoamericanas dedicadas al desarrollo de software. COMPETISOFT
se compone de un modelo de referencia, un modelo de evaluacin y un modelo de mejora, los
cuales se articulan ofreciendo una solucin integral para la ejecucin de un proyecto de mejora de
procesos software, sin que esto signifique que sea opuesto a los grandes marcos metodolgicos,
sino ms bien se presenta como un modelo con muchos puntos en comn, lo cual lo hace
totalmente compatible.
ENFOQUE BASADO EN PROCESOS
El desarrollo y mantenimiento de software se lleva a cabo a travs de una serie de actividades
realizadas por equipos de trabajo. La Ingeniera de Software se ha dedicado a identificar las
mejores prcticas para realizar estas actividades recopilando las experiencias exitosas de la
industria de software a nivel mundial. Estas prcticas se han organizado por reas de aplicacin, y
se han dado a conocer como reas clave de procesos, en caso de CMM, o como procesos de
software en ISO/IEC 15504.
El modelo que se propone est enfocado en procesos y considera los tres niveles bsicos de la
estructura de una organizacin que son: la Alta Direccin, Gestin y Operacin. El modelo
pretende apoyar a las organizaciones en la estandarizacin de sus prcticas, en la evaluacin de su
efectividad y en la integracin de la mejora continua.
Este proceso de calidad se aplicara en nuestro proyecto (Barman Optimizer) inicialmente se
tiene pensado su aplicacin en empresas (bares), se han considerado establecimientos que
pueden poseer slo una sede central o varios centros de distribucin.
Posteriormente se tiene la expectativa, que el sistema pueda ser aplicado junto con un sistema de
bases de datos que soporte la totalidad del inventario de la empresa ya sea que se aprovisione
localmente o desde proveedores en el exterior para sus operaciones de distribucin.
A continuacin se esquematiza la distribucin de los procesos para cada categora
Alta direccin (DIR)
Gestin de Negocio
Gerencia (GER)
Gestin de Procesos
Gestin de Proyectos
Gestin de Recursos Humanos
Gestin de Bienes, Recursos e Infraestructura
Gestin del Conocimiento
Operaciones (OPE)
Administracin de un Proyecto Especfico
Desarrollo de Software
Mantenimiento de Software
Para cada proceso se tienen definidos los roles para su ejecucin, los cuales son asignados al
personal de la organizacin segn sus capacidades.
Para la utilizacin del modelo de procesos en una organizacin, es necesario considerar dos
opciones: que la organizacin no cuente con procesos establecidos o que la organizacin s cuente
con procesos establecidos.
En caso la organizacin no cuente con los procesos establecidos ni documentados, pueden usar el
modelo ajustndolo de acuerdo a sus necesidades. Si la organizacin cuenta con procesos
establecidos, se debe establecer la correspondencia entre estos procesos y el modelo
COMPETISOFT de tal forma que se pueda identificar las coincidencias y discrepancias.
EVALUACIN INICIAL
Como paso previo a la elaboracin del Plan de Mejora de Procesos para el desarrollo de nuestro
proyecto, se determina la capacidad actual de los procesos mediante una evaluacin de tipo
ligera, basada en el estndar EvalProSoft (ISO/IEC 15504 2).
La evaluacin de cada proceso se ha realizado considerando que est:
Completamente alcanzado (C) si el porcentaje de cumplimiento est entre 85% y 100%.
Ampliamente alcanzado (A) si est entre 50% y 85%.
Parcialmente alcanzado (P) si est entre 15% y 50%.
No alcanzado (N) si est entre 0% y 15%.
Como niveles de referencia se tomaron los siguientes:
Nivel 0: Proceso Incompleto. El proceso no est implantado o falla en alcanzar el propsito del
proceso.
Nivel 1: Proceso Realizado. El proceso implantado logra su propsito.

STAKEHOLDERS
Gerencia
Se refiere a los proponentes del proyecto, es decir quienes contratan y financian el desarrollo del
mismo.
Usuarios
Son quienes actan directamente con el sistema.
Grupo de Desarrollo
Son los encargados del desarrollo de todo el sistema y su puesta en funcionamiento, incluye
diseadores y programadores.
Debe reflejar las necesidades del cliente, sin descuidar las restricciones de negocio y tecnolgicas
Tester
Incluye seguridad, confiabilidad y desempeo.
Debe ser capaz de verificar el estado del software, en cuanto a funcionalidad, seguridad,
disponibilidad y eficiencia.
Divisin de Ventas
Se espera un sistema confiable, que permita escalar en nmero de usuarios dependiendo de la
escalabilidad propia del negocio, sin incurrir en sobrecostos.
Gerencia
Est ligada al xito financiero de la compaa. Se espera que este sistema resulte atractivo para los
clientes y esto se vea representado en mayores utilidades para la empresa. De esta manera se
espera un sistema confiable, seguro que mejore la imagen y la eficiencia del negocio a travs de la
satisfaccin de los clientes.
Constructor
Hace referencia a los encargados de la instalacin y adecuacin del software directamente para la
utilizacin del sistema.
GESTIN DE NEGOCIO (GNEG)
Los objetivos de este proceso, segn el modelo de referencia MoProSoft, son:
Lograr una planificacin estratgica exitosa mediante la elaboracin y cumplimiento del Plan
Estratgico.
Lograr que la organizacin trabaje en funcin del Plan Estratgico mediante la correcta
comunicacin e implantacin del mismo.
Mejorar el Plan Estratgico mediante la implementacin de la Propuesta de Mejoras.
La aproximacin ms cercana al Plan Estratgico la constituye un Mapa Estratgico, el cual no
establece las correspondencias entre los objetivos y las estrategias del negocio, no integra, ni da
sentido a los mecanismos de comunicacin con el cliente, entre otros.
GESTIN DE PROCESOS (GPROC)
Los objetivos de este proceso, segn el modelo de referencia MoProSoft, son:
Planificar las actividades de definicin, implantacin y mejora de los procesos en funcin del Plan
Estratgico.
Dar seguimiento a las actividades de definicin, implantacin y mejora de los procesos mediante
el cumplimiento del Plan de Procesos.
Mejorar el desempeo de los procesos mediante el cumplimiento del Plan de Mejora de
procesos.
Mantener informado a Gestin de Negocio sobre el desempeo de los procesos mediante el
Reporte Cuantitativo y Cualitativo

MEJORA DEL PROCESO
Luego de la etapa de induccin, evaluacin de capacidades y anlisis de la situacin actual de los
procesos, corresponde ejecutar el Proceso de mejora en la organizacin participante, tal ejecucin
implica la presentacin, ante la alta direccin, de la propuesta de procesos a mejorar en un primer
ciclo y los procesos que sern mejorados en los prximos ciclos hasta que se logre elevar la
capacidad de todos los procesos al nivel 5.
Para poder llevar a cabo una mejora de procesos en la organizacin, y que esta mejora no
implique un esfuerzo desproporcionado, se debe tomar en cuenta la existencia de prcticas (estn
documentadas o no) para la realizacin de las actividades del negocio, estas prcticas debern ser
comparadas contra lo que propone el modelo de referencia, para luego adaptar lo que propone el
modelo a la realidad de la organizacin participante del proyecto COMPETISOFT. El logro de este
objetivo implica coordinacin estrecha entre los responsables de los procesos de la organizacin,
el equipo de mejora y el practicante COMPETISOFT.

REPRESENTACIN DE LA ARQUITECTURA
La arquitectura utiliza el siguiente conjunto de vistas:
Vista de Casos de Uso: lista los casos de uso o escenarios del modelo de casos de uso que
representen funcionalidades centrales del sistema final, que requieran una gran cobertura
arquitectnica o aquellos que impliquen algn punto especialmente delicado de la arquitectura.
Vista Lgica: describe las partes arquitectnicamente significativas del modelo de diseo, como
ser la descomposicin en capas, subsistemas o paquetes. Una vez presentadas estas unidades
lgicas principales, se profundiza en ellas hasta el nivel que se considere adecuado.
Vista de Procesos: describe la descomposicin del sistema en threads y procesos pesados. Indica
que procesos o grupos de procesos se comunican o interactan entre s y los modos en que estos
se comunican.
Vista de Deployment: describe uno o ms escenarios de distribucin fsica del sistema sobre los
cuales se ejecutar y har el deploy del mismo. Muestra la comunicacin entre los diferentes
nodos que componen los escenarios antes mencionados, as como el mapeo de los elementos de
la Vista de Procesos en dichos nodos.
Vista de Implementacin: describe la estructura general del Modelo de Implementacin y el
mapeo de los subsistemas, paquetes y clases de la Vista Lgica a subsistemas y componentes de
implementacin.
Vista de Datos: describe los elementos principales del Modelo de Datos, brindando un panorama
general de dicho modelo en trminos de tablas, vistas, ndices, etc.







Requerimientos Especiales
Interoperabilidad:
El framework debe soportar la capacidad de inter-operar con sistemas externos a nivel de datos.













MARCO TEORICO CONCEPTUAL
BLUETOOTH
En primer lugar, deberamos definir la tecnologa Bluetooth, ya que es el centro de nuestra
aplicacin.
Bluetooth es una especificacin industrial para Redes Inalmbricas de rea Personal (WPAN
Wireless Personal Area Network), que posibilita la transmisin de datos entre diferentes
dispositivos utilizando el aire como canal. Est diseado para dispositivos donde se necesite un
bajo consumo, una distancia pequea de cobertura, y unos costes reducidos.
Opera en una frecuencia en el rango entre 2.4 y 2.48 Ghz de la banda ISM
(Industrial, Scientific and Medical), la cual est disponible sin licencia a nivel mundial. Para evitar
interferencias con otros protocolos y entre dispositivos, se emplea una tcnica de saltos de
frecuencia de espectro ensanchado, que consiste en dividir la banda en 79 canales (23 en Espaa,
Francia y Japn) de 1Mhz de longitud, y realizar entre estos canales 1600 saltos por segundo.
Las caractersticas originales son:
Separacin de la banda de frecuencia en saltos. En una conexin se va saltando de un canal a otro,
mejorando de esta manera la seguridad.
Piconet3de hasta ocho dispositivos.
La seal puede atravesar incluso paredes.
Los dispositivos no tienen por qu estar uno enfrente del otro, ya que las seales son
omnidireccionales.
Posibilidad de usar aplicaciones sncronas y asncronas:
Enlace asncrono sin conexin (ACL):
Conexiones simtricas o asimtricas multipunto entre maestro y esclavo.
Conexin utilizada para trfico de datos.
Sin garanta de entrega.
Mxima velocidad de envo en una direccin: 721kbps, y de 57.6kbps en la otra.
Enlace sncrono orientado a conexin (SCO):
Conexiones simtricas punto a punto entre maestro y esclavo.
Voz en tiempo real y trfico multimedia.
Velocidad de transmisin: 64kbps.
Segn [Wireless2000], las especificaciones fueron establecidas formalmente en 1998 por el
Bluetooth Special Interest Group (SIG), que fue creado por Ericsson, IBM, Intel, Toshiba y Nokia,
aunque posteriormente se sumaron ms compaas.
Las diferentes versiones de los estndares estn diseadas para mantener la compatibilidad hacia
atrs y, hasta la fecha, son las siguientes:
Bluetooth v1.0 y v1.0B:
Los dispositivos que implementaban esta versin, tenan dificultades para conseguir
compatibilidad hacia otros dispositivos de diferente fabricante.
Utilizacin de canales encriptados.
Bluetooth v1.1: Ratificado como estndar IEEE 802.15.1-2002.
Correccin de erratas en la especificacin v1.0b.
Soporte para canales no encriptados.
Indicador de calidad de seal recibida (RSSI).
Bluetooth v1.2: Es la primera versin compatible con USB 1.1.
Se aadi el Discovery, AFH (Salto de frecuencia adaptable de espectro ensanchado) mejorando
la resistencia a interferencias.
Velocidad de transmisin hasta los 721 kbit/s.
Tipo de enlace para aplicaciones de audio ESCO (Conexiones Sncronas Extendidas), mejorando
la calidad de voz.
Mejoras en el HCI (Host Controller Interface), permitiendo una sincronizacin ms rpida de las
comunicaciones.
Control de flujo y modo de retransmisin L2CAP.
Estndar IEEE 802.15.1-2005.
Bluetooth v2.0:
Incorporacin de la tecnologa EDR (Enhanced data Rate): Incremento de las velocidades hasta
3Mbps de manera ideal.
Reduccin del consumo de energa.
Bluetooth v2.1:
SSP (Secure Simple Pairing) : Conexin inicial entre pares simplificada.
EIR (Respuesta amplia de de Investigacin): Mejor filtrado de los dispositivos a los que
conectarse.
Posibilidad de utilizar otras formas de emparejado: NFC (Near Field Communication)
Reduccin de energa en el modo de bajo consumo.
Bluetooth v3.0 + HS:
AMP (alternate MAC/PHY),
Unicast de datos sin conexin
802.11 Protocol Adaptation Layer (PAL): Transferencia de datos inalmbrica de hasta 24 Mb/s
mediante el protocolo WiFi.
Control de energa mejorado.
Bluetooth v4.0
Alcance mayor (+100m).
Encriptacin AES-128.
Baja latencia (3ms).
Interoperabilidad multi-vendor.
Mejora en el consumo.
Los dispositivos que implementen este protocolo, pueden pertenecer a diferentes clases segn su
potencia y alcance:
Clase 1: 100mW de potencia mxima, cobertura de ~100m.
Clase 2: 2,5 mW de potencia mxima, cobertura de ~10m.
Clase 3: 1 mW de potencia mxima, cobertura de ~1m.
Las aplicaciones deben implementar una serie de perfiles de Bluetooth, es decir, una serie de
interfaces de alto nivel para estandarizar un cierto mbito de aplicacin de la tecnologa. Una
especificacin de un perfil debe cubrir dependencias con otros perfiles, formatos recomendados
para la interfaz con el usuario, y partes concretas de la pila Bluetooth que se utilizan.
ANDROID
Por lo que respecta al sistema operativo que vamos a utilizar, Android, debemos definir sus
conceptos bsicos.
Definicin
Android es una pila de software para dispositivos mviles, la cual incluye sistema operativo,
middleware 4 y aplicaciones clave. El SDK de Android, ofrece las herramientas y APIs necesarias
para comenzar a desarrollar aplicaciones para la plataforma usando el lenguaje de programacin
Java.
Algunas caractersticas del sistema Android son:
Framework de aplicacin basado en la reutilizacin y reemplazo de componentes.
Mquina virtual Dalvik, la cual no es una mquina virtual de Java estrictamente hablando. Est
optimizada para un consumo reducido de memoria y est diseada para ejecutar varias instancias
simultneamente, de manera que es el sistema operativo el que se encarga del aislamiento de
procesos, gestin de memoria e hilos. Aunque las aplicaciones
Android se programen en Java, el cdigo intermedio que interpreta
Dalvik no es bytecode de Java, aunque la herramienta Dx incluida en el SDK permite la conversin
de archivos .class al formato de archivo de Dalvik (.dex).
Navegador integrado, basado en el motor Webkit.
Grficos con libreras propias para 2D , y grficos en 3D basado en la especificacin de OpenGl ES
1.0 (Con aceleracin hardware opcional).
Sistema de gestin de base de datos SQLite.
Soporte multimedia para audio y vdeo en diversos formatos: (MPEG4, H.264, MP3, AAC, AMR,
JPG, PNG, GIF).
Telefona GSM (Dependiente del hardware). Bluetooth, EDGE, 3G, y WIFI(Dependiente del
hardware).
Aunque inicialmente fue desarrollado por Android Inc. (firma comprada por Google en el ao
2005), actualmente est siendo desarrollado por la Open Handset Alliance (Liderada por Google),
un conglomerado de fabricantes y desarrolladores de hardware, software y operadores de
servicio. Est basado en el kernel de Linux, y actualmente la gran mayora del cdigo de Android
est liberado bajo licencia Apache.
Arquitectura
Android est formado por varias capas que facilitan al desarrollador la creacin de aplicaciones. La
distribucin en capas permite acceder a capas ms bajas mediante el uso de libreras, evitando la
programacin a bajo nivel por parte del desarrollador.
Cada una de las capas utiliza elementos de la capa inferior para realizar sus funciones, formando
una pila:
Kernel Linux: El ncleo del sistema operativo Android est basado en el kernel 2.6 de Linux, similar
al que se puede utilizar en distribuciones de Linux, pero con ciertas modificacioens, como
optimizacin para un mayor rendimiento.
El programador no accede al kernel directamente, sino que debe utilizar libreras disponibles en
capas superiores. Se encarga de gestionar los recursos del dispositivo (energa, memoria...) y del
sistema operativo en s (Procesos, comunicacin, red... etc). Tambin estn incluidos los drivers de
los componentes que tenga el dispositivo mvil.
Libreras: Son las bibliotecas nativas de Android. Estn escritas en C/C++ y compiladas para la
arquitectura hardware especfica del dispositivo.
Estn hechas normalmente por el fabricante, el cual se encarga de que estn presentes en el
dispositivo antes de su venta. Las libreras proporcionan funcionalidad a las aplicaciones para
tareas repetidas con frecuencia, evitando tener que codificarlas cada vez y garantizando que se
realicen de manera eficiente.
Entre las libreras incluidas habitualmente se encuentran: OpenGL, bibliotecas multimedia (audio,
video, e imagen),Webkit, SSL, FreeType, SQLite...
Entorno de ejecucin (Runtime): Es una sub-capa formada por libreras.
El componente principal es la mquina virtual Dalvik, ya mencionada anteriormente.
Framework de aplicaciones: Formada por las clases y servicios que utilizan directamente las
aplicaciones para realizar sus funciones. La mayora de los componentes de esta capa son libreras
Java que acceden a recursos de las capas inferiores a travs de Dalvik. Las ms importantes son:
Activity Manager: Se encarga de administrar la pila de actividades de nuestra aplicacin y su ciclo
de vida. Una actividad es lo que equivaldra a una ventana en un sistema operativo convencional
para PC como Windows, o Linux con escritorio grfico (Gnome, KDE, XFCE, LXDE... etc), con la
descripcin del entorno particularidad de ocupar la pantalla entera y ser apilable, pudiendose as
mostrar otras actividades relacionadas (o no) posicionndose encima.
Windows Manager: Se encarga de organizar lo que se mostrar en pantalla.
Bsicamente, crea superficies en la pantalla que posteriormente pasarn a ser utilizadas por las
actividades.
Content Provider: Es la librera que encapsula los datos que se compartirn entre las aplicaciones,
de manera que tiene el control sobre el acceso a la informacin.
Views: Una vista es un elemento bsico del cual parten todos los elementos bsicos que mostrarn
las actividades: Botones, cuadros de texto, listas...
Notification Manager: Engloba los servicios para notificar al usuario cuando algo requiera su
atencin mostrando alertas en la barra de estado.
Esta librera tambin permite la utilizacin de sonidos, activar la vibracin del dispositivo, o utilizar
leds en caso de existir.
Package Manager: Permite obtener informacin sobre los paquetes instalados en el dispositivo
Android, y tambin se encarga de la instalacin de nuevos paquetes. Los paquetes de Android
tienen la extensin .apk, y contienen los binarios .dex y todos los recursos dependientes de
ste.
Telephony Manager: Esta librera permite realizar llamadas o enviar y recibir SMS/MMS, aunque
no puede reemplazar o eliminar la actividad que se muestra cuando una llamada est en curso.
Resource Manager: Permite la gestin de todos los elementos que estn incluidos en la aplicacin
pero fuera del cdigo.
Location Manager: Permite determinar la posicin geogrfica del dispositivo
Android mediante GPS o redes disponibles y trabajar con mapas.
Sensor Manager: Permite manipular los elementos de hardware del telfono tales como
acelermetro, giroscopio, sensor de luminosidad, sensor de campo magntico, brjula, sensor de
presin, sensor de proximidad, sensor de temperatura...
Cmara: Esta librera proporciona la posibilidad de utilizar las cmaras del dispositivo para tomar
fotografas o vdeo.
Multimedia: Permite reproducir y visualizar vdeo, imgenes y audio.
Aplicaciones: Es la capa de ms alto nivel. En ella se incluyen todas las aplicaciones del dispositivo,
tanto las que tienen interfaz grfica de usuario como las que no, las nativas (programadas en
C/C++) y las administradas (En Java). Tambin se encuentra la aplicacin principal del sistema: el
Home o Launcher, que es la que permite ejecutar otras aplicaciones mostrndolas en forma de
lista, y proporcionando al usuario una serie de escritorios donde colocar accesos directos, Widgets
de escritorio...


Arquitectura del sistema Android


Anatoma de las aplicaciones Android
Componentes de una aplicacin
Una aplicacin Android, est compuesta por los siguientes elementos:
Activity (Actividad): Segn su definicin en Android Developers, es un componente de aplicacin
que provee una pantalla sobre la cul el usuario puede interactuar para conseguir un objetivo (por
ejemplo, llamar por telfono, hacer una fotografa, enviar un correo electrnico, ver un mapa...
etctera). Cada actividad proporciona una ventana en la cual dibuja su interfaz de usuario. La
ventana, normalmente se adapta a la totalidad de la pantalla.
Una aplicacin se compone, normalmente, de mltiples actividades interrelacionadas entre ellas.
Lo comn es que exista una actividad principal que se abra en cuanto se ejecute la aplicacin.
Cada Activity puede iniciar otras actividades si la lgica del programa lo requiere. Cada vez que
una actividad se inicia, la anterior Activity se para (pasa al estado stopped visto ms adelante),
pero la preserva dentro de la pila de actividades, por debajo de la nueva. Sin embargo, si el
usuario pulsa el botn atrs del dispositivo Android, la Activity que estaba en pantalla se desapila,
mostrando la que haba anteriormente.