Android (primera parte)

Google en su continua expansión como empresa, sigue dotando al mercado de una gran gama de aplicaciones sobre las que sustentar su negocio base, el de la publicidad. En un entorno en el que se presenta un emergente acceso a Internet desde dispositivos móviles, mayoritariamente los teléfonos, Google se nomina como participante en esta carrera para conquistar a millones de usuarios potenciales con Android.

Naturalmente Google no se puede presentar a la carrera solo y para ello ha levantado una Alianza lo que llama Open HandSet Alliance involucrando a operadores, fabricantes, empresas de sw, distribuidores, etc.. Y la verdad tiene buena pinta, pero creo que aún les quedan aliados por conquistar o atraer. . Por cierto Telefónica está en la lista..

Las premisas en las que se ha basado Google para construir Android son las siguientes:

• Open: El sistema debe ser abierto y las aplicaciones pueden usar todos los recursos del HW (camara, BT, llmadas, etc) además el sistema puede ser extendido por los desarrolladores.

• Aplicaciones iguales: Todas las aplicaciones pueden ser creadas del mismo modo, no existen ventajas, ni diferencias para aplicaciones creadas por el fabricante o por empresas terceras.

• Aplicaciones sin barreras: No poner ningun limite a la inovacion, pudiendo combinar recursos del dispositivo móvil, aplicaciones web, datos del usuario.. Sin limites para innovar.

• Desarrollo Fácil y Rápido. Ofrece una serie de aplicaciones y herramientas que permiten poder desarrollar aplicaciones rápidas y dotadas de gran funcionalidad.
  

Android se presenta como una plataforma para dispositivos móviles, ya que pretende ir más allá de ser un sistema operativo para móviles aportando middleware y aplicaciones. A estas aplicaciones las llama clave, que son aquellas que todos esperamos que nos traiga de base el móvil cuando lo compramos, y el Middleware son todas las aportaciones a nivel de SDK, que nos permitan construir aplicativos que doten al movil de mayores prestaciones funcionales.

Si inspeccionamos la wikipedia podemos encontrar más acerca de Android pero en el momento de escritura de este articulo, no deja casi de ser una traducción de la web oficial de Android ( What is Android?), en la cual podremos leer mucho más..

Desde el punto de vista tecnico tenemos las siguientes características, extraidas literalmente:

• Application framework enabling reuse and replacement of components

• Dalvik virtual machine optimized for mobile devices

• Integrated browser based on the open source WebKit engine

• Optimized graphics powered by a custom 2D graphics library; 3D graphics based on the OpenGL ES 1.0 specification (hardware acceleration optional)

• SQLite for structured data storage

• Media support for common audio, video, and still image formats (MPEG4, H.264, MP3, AAC, AMR, JPG, PNG, GIF)

• GSM Telephony (hardware dependent)

• Bluetooth, EDGE, 3G, and WiFi (hardware dependent)

• Camera, GPS, compass, and accelerometer (hardware dependent)

• Rich development environment including a device emulator, tools for debugging, memory and performance profiling, and a plugin for the Eclipse IDE

Sobre todo me quedo con que el núcleo (Kernel) del Sistema Operativo está basado en Linux, lo que nos da unas garantias de seguridad, una eficiente gestión de memoria y HW. El navegador se basa en Safari, y naturalmente supongo que será uno de los aspectos más cuidados. Otro detalle es que han desarrollado una Maquina Virtual (Dalvik) a medida del sistema. Me ha encantado también que traiga una BBDD SQLite, que permite poder desarrollar aplicaciones de peso. Desde luego si sumamos todo, tenemos una plataforma ideal para el desarrollo de aplicaciones Java..

Desde luego a día de hoy la apuesta de Google respecto a Android es llegar a los desarrolladores, puedo suponer que en dos sentidos, uno como testers de la nueva plataforma y otro sabiendo que cuanto mas desarrolladores, más aplicaciones en el mercado, más competitiva es la plataforma y puede competir con Symbian y Windows Mobile .

No hay nada como organizar una competición entre desarrolladores para conseguirlos, y por ello Google lanzó el Android Developer Challenge, cuyas normas, reglas y objetivos podemos leer aquí. Básicamente busca aplicaciones para Android, premiando la originalidad, el uso del sistema, y la funcionalidad que desarrollan..

De esto hablaré en la segunda parte..

Lineas de Producto Software

Hasta este momento había comentado los Modelos de Software Factory ( I , II , III ) en una serie de artículos que aún esta pendiente de cerrarse, en ellos nos centramos en como presentar el modelo al cliente y como gestionar la producción interna así como los éxitos y beneficios de cada uno.

En este artículo vamos a centrarnos en como organizar nuestra producción desde el punto de vista Metodológico y Técnico con dos claros objetivos:

• Ahorro de costes.
• Mejora del Time to Market.
• Alta calidad del producto.
  

Evidentemente el que encuentre la manera de conseguir este trinomio y mantenerlo en el tiempo ha conseguido encontrar el Santo Grial del Software. No va a ser tan fácil de conseguir como muchos autores promulgan, pero sin duda las Líneas de Productos Software es el camino.

En general los dos sistemas de reutilización más usados, son el Individual que se basa en el Copy & Paste del programador y el Oportunista que ocurre cuando un componente se parece a otro que hicimos en el pasado y lo encajamos con calzador.

Siempre lo que debemos buscar es una reutilización gestionada, basada en una planificación y en la que pensemos desde el principio de los desarrollos.

Las Líneas de Producto Software (LPS) o Software Product Lines (SPL), para el que prefiera documentarse en inglés, proponen un sistema de producción basado en la reutilización de componentes en un determinado dominio. Si nos fijamos en otra industria como puede ser la del automóvil, podemos ver como una misma cadena puede producir hasta automóviles con 1000 diferencias entre si, aplicando este sistema podemos tener un linea de producción capaz de generar multitud de variantes en una tipologia de SW.


Evidentemente montar este sistema no es cosa de un día, ya que tenemos que tener una metodología de desarrollo que nos permita generar activos sw o piezas de la configuración, almacenarlas en un repositorio, para a posteriori poder ensamblarlas para componer otro producto de diferentes requerimientos.

Naturalmente otra necesidad es saber construir una Arquitectura a medida de este paradigma de producción, ya que no tiene sentido tener un repositorio de activos sw, si el coste de ensamblaje de los mismos es más alto que el de construcción..

Queda mucho trabajo por hacer.. y mucho por leer, por eso empecemos cuanto antes..

Bibliografía

http://www.softwareproductlines.com/
http://bradapp.blogspot.com/2008/03/software-product-line-architecture-and.html
http://www.ieee.org.ar/downloads/2006-montilva-productos.pdf
http://www.sei.cmu.edu/productlines/spl_factory.html
http://worldofreuse.blogspot.com/

Arquitectura: Marca de Software Factory

Voy a empezar una serie de artículos que tienen que ver con las Arquitecturas, estando más cerca de los conceptos de metodología de desarrollo, arquitecturas empresariales y lineas de productos software, que cerca de la tecnología de implementación de las mismas. Evidentemente al hablar de desarrollo de arquitecturas todo el mundo vuelve la cabeza para mirar Java y .net principalmente.

Hace unos días me comentaba un amigo que se encontraba trabajando en la nueva versión de la arquitectura y que iban a pasar a la versión 4.2, en ese momento le pregunté ¿y porque no la 5?, a lo que me respondió con una serie de argumentos técnicos (todos muy acertados), que justificaban claramente el porque solo un crecimiento en el digito de menos peso.

Muy probablemente en su empresa siguen criterios cercanos a los de Apache http://apr.apache.org/versioning.html , que desde luego me parece un gran acierto y un planteamiento más que respetable.

En resumen lo que dice Apache respecto a su versionado, siendo esto una política muy extendida. Se basa en tres niveles separados por puntos, MAJOR.MINOR.PATCH, aplicando a cada uno criterios diferentes:



* PATCH VERSION: Solo se realizan correcciones, que no cambian el comportamiento de la aplicación, no cambian los parámetros y llamadas. Por tanto al instalar la versión la aplicación no cambia.

* MINOR VERSION: Introduce nuevas funciones, o cambia y modifica el comportamiento de las existentes pero no rompe la compatibilidad con otras Minor Versions.

* MAJOR VERSION: Cualquier tipo de cambio son aplicables a Major Version y no tiene porque guardar compatibilidad con minor versions. Normalmente se aplica cuando se introducen importantes grupos de nuevas funcionalidades.

La verdad es que se trata de un criterio de versionado robusto, pero no olvidemos que normalmente una arquitectura debe ser proporcionada a un usuario de la misma, bien interno (linea de productos sw, departamentos de la compañia, etc) o externo cara a la venta de un proyecto o venta de una arquitectura empresarial o sectorial, a un determinado cliente.

Desde el punto de vista anterior y teniendo en cuenta que un equipo de desarrollo de Arquitectura no lo hace para si mismo, para un agente externo aparenta más solvencia otra manera de presentar versiones. Pensemos que a todos nos da más garantías un producto que se encuentra en la versión 2.2, que uno que está en la versión 1.3... Aunque ambos pueden tener el mismo número de mejoras y correcciones, solo que aplican criterios diferentes.

Si algún lector no me cree, solo tiene que hacer la prueba, muestre dos productos diferentes que tengan funcionalidad similares, apuesten a que en la mayoría de los casos el cliente o usuario se decantara por el de la versión más alta.

¿Por qué? Porque piensa que lleva más tiempo en el mercado, porque piensa que se ha invertido mucho esfuerzo en él, porque si ha llegado a 7 versiones es que será bueno, etc.. La mayoría de estas valoraciones aveces serán acertadas y aveces erróneas.. pero en cualquier caso se basan en un criterio de apariencia.

Por tanto desde este punto de vista, es más fácil vender, justificar presupuesto, etc , aplicando un criterios de versionado ágiles. ¿Es un engaño? No, es Marketing Tecnológico.

Evidentemente no se puede caer en el abuso, y de repente encontrarnos en la versión 23 de un producto. Hay que poner todo en la balanza y aplicar tanto criterios técnicos como marketinianos.

Cara a introducir un nuevo enfoque voy a contar una anécdota empresarial:

Hoy en día, todo el mundo, o gran parte de el, conoce a una empresa como Nokia. Por increíble que parezca Nokia en sus orígenes fabricaba botas de goma para pescadores, y el nombre proviene de un río existente en Finlandia el Nokia.

Sin embargo el mayor acierto de Nokia en su historia, probablemente no ha sido realizar teléfonos móviles, sino ser pionera en el branding, de este modo su marca siempre aparece en todos sus productos, incluso cuando hacía botas

Supongo, que ya vais viendo a donde quiero llegar..

Si tenemos en cuanta las 100 marcas más conocidas en el mundo encontraremos muchas tecnológicas y bastantes dedicadas a los Sistemas de Información.. La primera es Google (¿quién la conocia hace 10 años?), y entre las diez primeras Mocrosoft, IBM , Apple y Nokia . Nadie duda que la marca les ayuda a vender..

¿Por qué no aprovecharnos de este concepto y que nuestra arquitectura tenga marca?

Sin duda, nos costará poco y ganaremos mucho. Algo que tiene nombre existe y es importante...

¿Que necesitamos?

Un nombre y un logo. (por supuesto nada que pise otras marcas)

¿Como lo usamos?

Poniéndolo en toda la documentación, presentaciones, etc.

En mi antigua y querida empresa nadie se dio por enterado que teníamos una arquitectura hasta que le pusimos nombre y logo. En ese momento todo cambió, parecía que las horas no se gastaban sino que se invertían, que teníamos un producto que vender, que ahorrábamos costes empleándola, etc.. Pero ella era la misma, con sus defectos y virtudes..

Eso si, bautizada.