Enfoque tecnológico en desarrollos web a medida

Las Webs Transaccionales

Todo proyecto web de tipo "transaccional" debe desarrollarse y plantearse como un sistema de software de ámbito web, no como un mero sitio web con algunas "funcionalidades" y herramientas para el usuario.

Lo primero, constituye un sistema con una estructura lógica completamente integrada, dotada de funciones que trabajan sincronizada y conjuntamente, lo segundo es un rejunte de aplicaciones y unidades funcionales inconexas e incomunicadas.

Muchas veces cuando se crean webs transaccionales, luego a lo largo del tiempo, se le van incluyendo nuevas funcionalidades y módulos sin seguir un plan de escalabilidad correctamente planeado. Más aún cuando por una aplicación web "pasan" varios programadores.

Para poder desarrollar un sistema de sofware es preciso seguir una metodología estándar de desarrollo, que es competencia de la disciplina ingeniería del software.

Desde el punto de vista práctico no es absolutamente necesario seguir al pié de la letra la metodología mencionada, pero sí es preciso conocer muy bien sus puntos fundamentales para garantizar el éxito del proyecto que se va a desarrollar. A continuación detallo esta metodología.

1- Ciclo de vida del software

Básicamente las etapas de desarrollo de software (ciclo de vida de un sistema) pueden resumirse en:

1. Especificación de requisitos de software (análisis)
2. Modelado e Implementación (diseño y desarrollo)
3. Debugging y puesta en marcha
4. Mantenimiento y escalabilidad

Cada una de estas etapas de desarrollo de software deben estar correctamente documentadas y previamente planificadas, porque en caso de no hacerlo pueden omitirse pasos importantes en los que luego no se puede volver atrás (o es muy difícil y costoso hacerlo).

Por ejemplo, si se omitió un requerimiento funcional importante en la primer etapa, luego cuando nos encontremos en la tercer etapa de desarrollo será muy difícil poder implementar o reparar lo que se ha omitido.

En casos extremos, una omisión importante puede implicar la necesidad de un replanteo completo del sistema, una vez que ya se ha desarrollado.

¿Qué es lo que se hace en cada etapa del desarrollo?

Especificación de requisitos de software o SRS (ver más abajo)

Modelado e Implementación

Esta etapa tiene dos fases, la primera es modelado y diseño.

Lo más adecuado para modelar un sistema web es utilizando el Lenguaje Estándar de Modelado de software (UML o Unified Modeling Language).

UML es un lenguaje visual que utiliza diagramas. Básicamente los diagramas utilizados en UML son:

• Diagramas de casos de uso (realizados en la etapa anterior de SRS)
• Diagramas de objetos y clases
• Diagramas de componentes
• Diagramas de despliegue y secuencia

¿por qué se usa UML en proyectos profesionales?

Porque estadísticamente el 80% de los proyectos de software fallan: se sobrepasa excesivamente los presupuestos y/o tiempos de desarrollo, los programas no proporcionan las características que los clientes necesitan o desean, quedan obsoletos antes de tiempo, es imposible añadirle nuevas funcionalidades y escalabilidad, más allá de cierto volumen de datos se vuelven inestables, y otras cuestiones más de gravedad crítica.

UML proporciona un método formal para el análisis y el diseño de un sistema, antes de su implementación. El hecho de seguir normas y reglas estrictas (adoptadas por convención en un lenguaje estandar) al momento de crear modelos, minimiza problemas, evita errores, y advierte omisiones que pudiesen aparececer en etapas más avanzadas (p. ej. en la codificación)

UML hace hincapié en que es estríctamente necesario invertir más tiempo en el análisis previo del software y su documentación, como primer medida.

La segunda fase de esta etapa del desarrollo de software es de Implementación y Pruebas, en las cuales se realizan los siguientes trabajos:

• Diseño, creación, y normalización de la base de datos,
• Creación y programación de algoritmos, métodos y funciones,
• Codificación de scripts de CRUDs (o ABMCs) y librerías de clases
• Diseño de interfaces de usuario -layouts y menues de navegación-, para cada tipo de usuario (usuario final, administrador, usuario especial, etc)
• Creación de formularios de captura de datos y filtrado
• Definición de la modularización de la aplicación siguiendo el modelo MVC (Modelo Vista Controlador)
• Carga de datos de ejemplo y pruebas de validación (testing),
• Depuración (debugging) -pruebas alfa-

Puesta en marcha

La puesta en marcha en un entorno de producción (publicación de la aplicación web) se lanza como una versión "beta" del software desarrollado.

2- Atributos de calidad de software

Los atributos de calidad de software deberían ser considerados antes de encarar el desarrollo web, porque de esta manera sabremos qué estándares de calidad deberá respetar la aplicación.

Estos son un conjunto de características que deben cumplir los sistemas informáticos para ser considerados de calidad.

Los atributos mínimos calidad esperada en este tipo de sistema web son:

1. Correctitud (que el software funcione bien y haga lo que se espera que debe hacer)
2. Usabilidad (que el software sea navegable, intuitivo, sencillo, entendible, de fácil recuperabilidad de información, y estéticamente agradable)
3. Funcionalidad (que haga todo lo que el usuario necesita para resolverle un determinado problema)
4. Eficiencia (que no se vuelva lento o inoperable en determinadas circunstancias -ej: alto volumen de datos, transacciones complejas-)
5. Seguridad (en el ámbito web, que el sitio no sea "hackeable" y que disponga de un buen sistema de back up y restauración)
6. Mantenibilidad (que sea fácilmente administrable y mantenible desde el punto de vista técnico, y que esto no sea exesivamente caro)
7. Escalabilidad (que pueda crecer, es decir implementar nuevas funcionalidades a futuro)
8. Reusabilidad (que el código fuente pueda reutilizarse en diversos módulos -uso de librerías comunes-)
9. Economía y Oportunidad (que el software pueda desarrollarse y entregarse en tiempo y forma sin gastar recursos económicos excesivos -presupuesto-)

De los 16 atributos de calidad existentes, un proyecto web por lo menos debería cumplir con los 9 arriba mencionados.

Eficiencia, seguridad y respaldo

Es muy importante que se atienda bien este punto de los atributos de calidad, más aún cuando en la aplicación web que se planea desarrollar van a interactuar decenas o cientos de miles de usuarios, van a cargar datos, navegarla, ejecutar acciones en ella, etc.

El desempeño tecnológico por ende, es un punto fundamental.

Es preciso entonces que el desarrollador web:

• entienda (o aprenda) y asimile los atributos de calidad de un software web, y que
• comprenda qué métodos de desarrollo, técnicas y estándares deben seguirse para lograr un producto que cumpla con los atributos de calidad esperados

Por ejemplo, el hecho de omitir el atributo de calidad "eficiencia", podría provocar que el sistema, más allá de un volumen crítico de datos se vuelva demasiado lento e incluso se produzcan errores graves de ejecución, y hasta timeouts o excepciones irrecuperables (tiempo de espera agotado para la solicitud de las páginas web que devuelve el típico error "no se puede mostrar la página").

En este sentido también deberá atenderse a los recursos de servidor necesarios para que la aplicación web se ejecute correctamente.

Otro ejemplo podría ser el siguiente: supongamos que omitimos el factor "seguridad". Con una omisión así, luego un hacker podría lograr introducirse en el sistema y a través de inyección sql o backdoors, podría eliminar completamente la base de datos con toda la información (de los usuarios) y los recursos/textos del sitio.

De ahí también la importancia de un buen sistema de back ups sistematizado y programable temporalmente, que sea capaz de backupear la aplicación completa por ejemplo dos veces a la semana, o más frecuentemente, si es necesario.

3- Plataforma de desarrollo y soporte tecnológico

Uno de los aspectos fundamentales al iniciar un proyecto web es definir la plataforma tecnológica del servidor sobre la cual se trabajará, y en la cual funcionará el sistema desarrollado. Esto es así porque:

• Se debe comprender los beneficios y debilidades de cada plataforma o entorno de servidor
• Se necesita contratar programadores especializados en un entorno específico (de aquellos quienes dicen dominar varias plataformas, hay que desconfiar porque saben tan solo un poco de cada una, dada la alta complejidad y el tiempo necesario que supone entender, comprender y tener experiencia en cada entorno de servidor)
• Se necesita disponer de un servidor web que funcione en esa plataforma
• En un futuro puede necesitarse un administrador de sistemas (hostmaster) especialista en el entorno
• Se necesita conocer las implicancias del uso de cada tecnología y sus licencias de software
• Para el mantenimiento, o escalabilidad futuras se requerirán profesionales especializados

Tecnología de servidor

LAMP - Linux/Apache/Mysql/PHP

Nosotros hemos elegido (cuando comenzamos a estudiar programación en 2003) la plataforma de servidor LAMP y en ella nos hemos especializado. Sin embargo las aplicaciones de servidor en las cuales se apoyan estos sistemas son PHP y Mysql, estos pueden funcionar también en otros entornos de servidor (No necesariamente Linux y Apache), aunque se recomienda que así sea para lograr una compatibilidad plena.

El motor de Base de datos

Una aplicación web de envergadura debe imperativamente basar su desarrollo en un sistema gestor de base de datos (SGBD).

Esto es así porque a futuro un sistema de almacenamiento de datos basado en archivos de textos no sería soportable y traerá aparejado infinidad de problemas, incluso puede acarrear la imposibilidad de la aplicación de permanecer online. Los datos almacenados en archivos son recomendables únicamente para sitios web muy básicos y pequeños.

Esto es así porque:

• La normalización de datos (en una bd) permite mimimizar la redundancia de datos,
• Se agiliza la actualización y lectura (rapidez de transacciones),
• Se evita la inconsistencia de datos
• Se garantiza la integridad de los datos
• Se garantiza la seguridad de ellos
• Se diferencian los accesos según permisos de distintos tipos de usuarios, lo que permite el desarrollo de APIs y sistemas para compartir o brindar servicios externos a otros websites o hacia aplicaciones externas
• Se facilita la modificación de datos
• Se ahorra código fuente a nivel de controlador (procesador de aplicaciones, que en nuestro caso es PHP)

El sistema gestor de bases de datos más compatible e integrado con PHP es Mysql, por esa razón Mysql es el sistema de base de datos en la cual nos especializamos y hacemos nuestros desarrollos.

Más info sobre Mysql aquí

Características de servidor web

Hosting o Housing, esa es la cuestión. A menos que se trate de un desarrollo con un volumen grande de usuarios y transacciones yo recomiendo comenzar con un hosting contratado (puede ser un plan shared o un dedicado). Cuando se plantea realizar un sistema de gestión empresarial, lo mejor es el housing.

En caso de elegirse la misma plataforma de desarrollo LAMP, yo recomiendo (al momento de escribir este artículo) contratar un servicio de hosting web con las siguientes características:

• Sistema Operativo: Linux
• HTTP Server: Apache version: 1.3. +
• PHP version: 5 +
• MySQL version: 5 +

Herramientas de servidor web

Es importante también, no solo tener en cuenta la tecnología del servidor, sino sus herramientas y servicios disponibles. Esto marca la diferencia entre un servicio u otro. Básicamente el servicio debería contar con:

• panel de control con interfaz web (yo recomiendo cPanel)
• acceso por SSH

El panel de control web cuanto más completo es mejor, puesto que de esta manera la cuenta creada en el servidor web puede administrarse con mayor independencia del personal de soporte técnico de la empresa proveedora.

Un buen panel de control web debería contar con:

• Sistema de Back up y restauración de ficheros y bases de datos (sencilla y rápida)
• Administrador de ficheros por HTTP (con compresión y descompresión remota de archivos y directorios)
• Administración completa de cuentas de email y opciones de e-mailing
• Acceso a Webmail
• Administrador de access-logs y estadísticas
• Administrador de bases de datos Mysql
• Gestor de interfaz web de bases de datos PHPmyadmin
• Administrador de Cron Jobs
• Administrador de dominios: parkeos, redireccionamientos y subdominios
• Administrador de accesos HTTP (redirecciones, protección de directorios, protección de hotlinking, denegación de IP)
• Administrador de accesos FTP

Shared hosting o Dedicated host

Si la aplicación web es exitosa lo más probable es que en un futuro no muy lejano necesite un servidor dedicado (exclusivo), puesto que es posible que en el corto/mediano plazo, un servidor compartido (shared hosting) no soporte los requerimientos de tráfico (transferencia), espacio en disco, carga del CPU, o carga de ciertas aplicaciones (ej: sistema de base de datos, servidor de email)

De momento y para empezar, un servidor compartido puede andar bien, y para facilitar las cosas en un futuro (migración de un servidor a otro) deberíamos asegurarnos que el proveedor de cuentas shared también tenga en su servicio servidores dedicados.

4- Patrones de diseño y paradigmas de desarrollo

El Modelo Vista Controlador

En el mundo de las aplicaciones web más modernas y actuales se impone cada vez más un patrón ideal de desarrollo que parece ser el más adecuado y además es el adoptado por los programadores más expertos del mundo, para las aplicaciones más grandes y potentes.

Este patrón es el Modelo Vista Controlador (MVC), el cual separa en tres componentes fundamentales y distintos:

• los datos de una aplicación (modelo)
• la interfaz de usuario (vista)
• la lógica de control (controlador)

En el patrón MVC:

• Los modelos son representaciones de tablas de una base de datos (Mysql por ej.) y se encargan de conectarlas o de ligarlas a una aplicación
• Los controladores contienen la lógica de la aplicación (reglas de negocio). A partir de aquí es posible recuperar la información desde una base de datos a través de la capa modelo, en la práctica estos son los archivos PHP y JS organizados en directorios dentro del sistema de archivos del servidor web.
• Las vistas contienen la presentación de las páginas y el código necesario para mostrar la información (HTML). La interacción entre los modelos y las vistas se da a través de los controladores

Programación Web de última generación

MVC está estréchamente asociado a la metodología de Programación Orientada a Objetos (Ver más info aquí). Esta metodología de programación es la más aceptada en la comunidad de los mejores desarrolladores de software de la actualidad, y también es la que ha dado origen al Lenguaje Unificado de modelado UML.

Siguiendo una metodología POO (orientada a objetos) se logra ingresar en un círculo "virtuoso" que permite optimizar simultáneamente la mayoría de los atributos de calidad de software: eficiencia, reutilizabilidad del código fuente, modularidad, independencia de componentes, mantenibilidad más barata, escalabilidad más flexible (hacer crecer el programa sin un costo significativo), etc.

En la práctica de la programación actual más moderna se utilizan Frameworks MVC (cada lenguaje de programación tiene sus propios frameworks), los cuales hacen uso de sistemas de templates y caché para las vistas.

A la capa "controlador" se ha incorporado recientemente la tecnología AJAX (Asynchronous JavaScript And XML), y en nuestra plataforma de desarrollo preferida (LAMP) actualmente ya se programa con métodos y sintaxis de PHP 5 y Mysql 5

Las aplicaciones en AJAX se ejecutan en el lado del cliente (en el navegador de los usuarios) mientras se mantiene la comunicación asíncrona con el servidor en segundo plano. De esta forma es posible realizar cambios sobre las páginas sin necesidad de recargarlas, lo que significa aumentar la interactividad, velocidad y usabilidad en las aplicaciones.

Es importante aclarar también que en la capa "Vistas" debe haber una separación entre contenidos y presentación.

• Los contenidos deben formatearse en HTML puro
• La presentación se define en hojas de estilo en cascada (archivos CSS)

A su vez, las normas y estándares del marcado HTML/CSS están fijados y definidos por W3C (World Wide Web Consortium)

Ejemplo estructura de template:

No necesariamente debe utilizarse un solo template, dependiendo de las necesidades del proyecto es probable que se requiera:

• Un template para la homepage
• Un template para cada módulo diferente dentro de la aplicación

Consejos:

Más allá de adoptar al 100% el patrón MVC (puesto que es bastante novedoso y muchos programadores aún utilizamos prácticas en las cuales no logramos implementarlo en su totalidad), es importante que la aplicación se base en un sistema de templates que separe lo más posible el código de la aplicación de servidor (PHP por ejemplo) de la generación de código HTML, y además que el sistema de templates se encuentre en un solo directorio de archivos, para facilitar posteriores modificaciones en la estética o presentación.

Por ejemplo, si el sitio tiene 9000 páginas web, que para hacer un cambio de diseño no haya que modificar los 9000 archivos PHP o HTML sino que esta tarea debería poder hacerse en un solo fichero donde se cargan todos los elementos comunes a las páginas web, o en pocos ficheros individuales con los distintos sectores del template: (sidebars, header, footer, maincontent, etc)

Recomiendo también que se respeten al máximo los estándares de marcado HTML propuestos por W3C, puesto que la calidad del código HTML define cuán recuperables/indexables son los documentos por parte de los motores de búsqueda, y además facilitan el cross browsing (renderización óptima por parte de cualquier navegador web), aceleran la descarga de páginas, etc.

Dentro de ningún documento web HTML (ya sea de extensión .htm/.html o .php) debería haber fragmentos de código CSS o funciones Javascript, estos deben ser externalizados en archivos independientes (ej: estilos.css, y funciones.js)

5- Especificación de requisitos de software (SRS -Software Requirements Specifications-)

Una especificación de requisitos del software es una descripción completa del comportamiento del sistema a desarrollar. En ingeniería de sistemas existen tres tipos de requerimientos:

· Requerimientos funcionales: puede ser una descripción de lo que un sistema debe hacer. Este tipo de requerimiento especifica algo que el sistema entregado debe ser capaz de realizar. Esto se trata exhaustivamente en los casos de uso.
· Requerimientos no funcionales: son los requerimientos de rendimiento, de calidad, etc; especifica algo sobre el propio sistema (plataforma de desarrollo, tecnología empleada), y cómo debe realizar sus funciones. Algunos ejemplos de aspectos solicitables son la disponibilidad, el testeo, el mantenimiento, la facilidad de uso (usabilidad), etc.
· Otros tipos de limitaciones externas: que afectan en una forma indirecta al producto. Estas pueden ir desde la compatibilidad con cierto sistema operativo hasta la adecuación a leyes o regulaciones aplicables al producto, la licencia del software, responsabilidad por uso o almacenamiento de datos, etc.

Las estrategias recomendadas para la especificación de los requisitos del software están descritas por la norma IEEE 830-1998. Este estándar describe las estructuras posibles, contenido deseable, y calidades de una especificación de requisitos del software.

Debe tenerse en cuenta que una colección de requerimientos describe las características o atributos del sistema deseado pero se omite el cómo debe lograrse su implementación, ya que esto debe ser decidido en la etapa de diseño por los desarrolladores del sistema.

Casos de Uso

En ingeniería del software, un caso de uso es una técnica para la captura de requisitos potenciales de un nuevo sistema o una actualización de software. Cada caso de uso proporciona uno o más escenarios que indican cómo debería interactuar el sistema con el usuario o con otro sistema para conseguir un objetivo específico.

Los diagramas de casos de uso sirven para especificar la comunicación y el comportamiento de un sistema mediante su interacción con los usuarios y/u otros sistemas. Una relación es una conexión entre los elementos del modelo, por ejemplo la especialización y la generalización son relaciones. Los diagramas de casos de uso se utilizan para ilustrar los requerimientos del sistema al mostrar cómo reacciona una respuesta a eventos que se producen en el mismo.

Para definir y armar los casos de uso este es un cuestionario que yo utilizo:

1- ¿quién es el experto de dominio? (persona con la máxima experiencia y responsabilidad en el area de negocios donde se usará el sistema)
2- ¿quiénes son los actores del sistema? (usuarios que utilizan el sistema para diferentes propósitos e interactúan entre si, también son actores otros sistemas con los que interactúa nuestro sistema)
[las siguientes preguntas deben hacerse para cada actor del sistema]
3- ¿para qué va a usar el actor el sistema?
4- ¿qué acciones podemos asignarle dentro del mismo? (si se trata de acciones complejas, desmenuzalas en otras acciones más simples que sean dependientes entre sí, o que para hacer una acción compleja, antes deba hacer una sucesión de acciones simples)
5- ¿qué debe hacer el actor para usar el sistema?
6- ¿qué está pasando para que el actor esté usando AHORA el sistema? (esto describe todas las situaciones en las cuales el usuario "necesita" ingresar al sistema para usarlo)
7- ¿qué resultados posibles entregará el sistema al actor en cada caso o acción ejecutada por este?
8- ¿qué acciones posibles debe ejecutar el sistema ante cada acción del actor dentro del mismo?
9- ¿qué condiciones deben darse para que cada acción de usuario sea posible dentro del sistema? (reglas de negocio) y ¿qué sucede si esas condiciones no se cumplen?

Ejemplos de diagramas de casos de uso

Ejemplo 1:

Ejemplo 2:

6- Ingeniería Inversa de Software (una alternativa económica al modelado)

La ingeniería inversa es un método de resolución. Su objetivo es obtener información a partir de un producto de software accesible al público (de-construcción), con el fin de determinar cómo está hecho, qué lo hace funcionar, y qué tareas o actividades lleva a cabo.

La ingeniería inversa es una alternativa económica a la planificación y documentación de un desarrollo desde cero. Realizando este proceso de manera ordenada y metódica podemos evitarnos hacer:

1. Especificación de requisitos de software o SRS (y casos de uso)
2. Modelado (UML)

7- Consejos sobre el enfoque tecnológico de desarrollo en aplicaciones web transaccionales

Hay que considerar que no todos los programadores conocen los métodos formales de desarrollo de aplicaciones que he detallado en este apartado, ni tampoco todos tienen idea que deben emplear técnicas y procedimientos que respeten ciertos estándares.

El alcance práctico de este apartado es el de ofrecer lineas directrices que permitan evaluar la competencia del/los programador/es que trabajará/n en el proyecto. La buena voluntad y predisposición aquí son insuficientes: hay que "saber hacer" y tener cierta experiencia en desarrollo de aplicaciones web transaccionales para lograr un proyecto exitoso.

El desarrollo de software realizado de manera eficiente, profesional, y acorde a las últimas tendencias tecnológicas es un proceso complejo, lleva mucho tiempo, y tiene un costo considerable.

8- Resumen de desarrollo:

8.1- Diseñar el sistema (base de datos -modelo- y controlador)

Es importante documentar el proceso para luego poder ordenarlo, comprenderlo, controlarlo y perfeccionarlo. En el desarrollo de Software bajo métodos formales, para realizar este proceso se utilizan "Diagramas de objetos y clases", y "Diagramas de componentes".

Al diseñar y crear la base de datos, es muy útil cargarla con varios datos de ejemplo para detectar redundancia de datos, relaciones mal establecidas, o posibles problemas de integridad referencial

8.2- Diseñar las Interfaces de usuario (vistas)

Hay que determinar tipos de usuarios tendrán acceso al sistema y deben definirse sus roles / facultades, y permisos dentro del mismo, para poder generar distintas interfaces de usuario. Por ej:

Interfaz pública:

• usuario visitante (anónimo)
• usuario registrado

Interfaz administrativa:

• usuario administrador
• otros (colaboradores, editores de contenidos, nutricionistas, etc)

Para cada capa o nivel de acceso es preciso definir y determinar la granularidad de los permisos, es decir, deben definirse los roles de usuarios, y el sistema debe limitar el accionar de cada tipo de usuarios (¿qué puede y qué no puede hacer cada tipo de usuario en el sistema? ¿qué tipo de información o recursos puede ver el usuario y a cuáles no tiene acceso ni siquiera a su lectura?).

Para definir y organizar esta tarea debería tomarse como referencia lo explicado en el punto de Casos de uso

8.3 - Contratar servidor web

8.4- Respetar los estándares de desarrollo

También deben respetarse al máximo las recomendaciones más importantes:

• separar muy bien la presentación de los contenidos (MVC)
• desarrollar un sistema de templates independiente de la aplicación
• separar HTML y estilos con CSS externos
• utilizar AJAX (si es posible, para agilizar la interactividad)
• respetar los estándares W3C
• programar utilizando clases de objetos (siguiendo la metodología OOP)

8.5- buscar soluciones para la implementación de herramientas secundarias

Básicamente hay tres formas de "agregar funcionalidades" y servicios a una aplicación web realizada:

1. programando a medida e integrando las herramientas al core del sistema
2. buscando soluciones enlatadas (programas opensource, por ejemplo) e instalarlas en el servidor como sistemas "satélite" a la aplicación principal y comunicadas entre sí a través de bridges
3. utilizando un sistema gestor de contenidos potente (CMS) al cual puedan instalarse fácilmente estas herramientas secundarias, y luego programar sobre esa plataforma del CMS las aplicaciones principales del sitio web

La primer opción es mucho más costosa pero tiene sus ventajas:

• logra centralizar toda la administración de la web en un solo lugar,
• unifica la base de datos con lo que se logra una correcta comunicación, sincronización y funcionamiento conjunto entre las distintas herramientas de la aplicación
• es más amigable a los usuarios

La segunda opción es mucho más económica pero se pierden todas las ventajas anunciadas para la opción anterior.

La tercera opción podría ser recomendable pero tiene una fuerte desventaja: existen pocos programadores especializados en estas plataformas, y si se adopta esta opción de trabajo, el proyecto pasa a depender exclusivamente de ellos, y ante algún problema que surja será muy difícil y costoso seguir adelante con otro programador.

[NOTA: Algunas definiciones utilizadas en la elaboración de este artículo fueron extraidas de la Wikipedia]