Soy de la “vieja escuela” del desarrollo de aplicaciones comerciales, antes del amanecer de las computadoras personales. He escrito e implementado sistemas personalizados completos para los equivalentes privados de Fortune 500’s, tengo varias patentes estadounidenses a mi nombre (que son utilizadas ampliamente por Fortune 100) e (irónicamente, ahora que estoy retirado) tengo – fundó una compañía de software de diagnóstico médico que utiliza exclusivamente tabletas Android y soluciones HTML5 basadas en web.
Quiero dejar perfectamente claro que, con respecto a cualquier declaración que haga (incluida la anterior), no estoy ofreciendo ni sugiriendo que tengo la respuesta correcta, o la única solución. De hecho, ni siquiera estoy sugiriendo que estoy calificado para responder a su pregunta … Trabajo usando una mentalidad metódica de dinosaurios, con pocas herramientas modernas, que la mayoría de los programadores modernos encontrarían arcaico. Al mismo tiempo, tanto los clientes como los colegas se han sorprendido de cómo mi código se ejecuta correctamente en el momento de la implementación y de cómo tomo en cuenta las contingencias que nunca consideraron. En una organización cuyo objetivo es poner en marcha el software lo antes posible y ganar cuota de mercado, utilizando su base de clientes como herramientas de depuración, sería un fracaso lamentable.
La metodología para desarrollar una aplicación de teléfono móvil es la misma que para desarrollar software en general. Debe lograr una comprensión sólida de los requisitos del cliente, a través de reuniones en curso. En primer lugar, obtiene una comprensión general de lo que el software está diseñado para lograr, cómo lo logrará y cómo el cliente espera que esto los beneficie (esto último es importante, por razones que no mencionaré aquí).
- ¿Qué tan complejo es la construcción de aplicaciones móviles sociales? ¿Qué son los requerimientos?
- Propuesta para el desarrollo de aplicaciones móviles: ¿qué es eso?
- Le estoy pagando a un desarrollador para que cree una aplicación móvil, ¿debo crear una compañía tenedora para pagar los costos de desarrollo?
- Cómo simular múltiples usuarios usando la aplicación móvil
- ¿Qué factores se deben considerar antes de elegir un proveedor de Servicios de desarrollo de aplicaciones móviles?
Una vez que comprenda, en términos generales, lo que se supone que debe hacer realmente el software, puede centrarse en sus características y presentación (UI). Si el cliente tiene un proceso comercial continuo, intervenga y obsérvelo … haga preguntas a sus empleados sobre las cosas que encuentran inconvenientes, repetitivas o que consumen mucho tiempo en el proceso actual. Sobre todo, obsérvelos haciendo su trabajo … muchas veces, los empleados están tan perdidos en la “rutina” de lo que hacen, nunca se les ocurre que hay una manera más sencilla de hacerlo.
Comience los primeros borradores de la capa de presentación (IU). Piense en ello como una tira de dibujos animados … una serie de maquetas de pantallas de Android, que muestran cómo funcionará la aplicación. Para esto, personalmente uso Balsamiq Mockups, pero en realidad estaba considerando usar recortes de cartón en los casos en que soy el cliente (así de arcaico soy). Revise esto con el cliente e repita … use lo que aprendió sobre las características y objetivos del software para revisar metódicamente cada entrada y salida, comparándolas con los datos que están realmente disponibles y necesarios, para asegurarse de que realmente está capturando todo lo necesario.
Un motivo favorito: no todos son ustedes; aprenda a considerar las posibles necesidades personales de la base de clientes de su cliente. Caso en punto; Después de muchos años de no poder leer libros PDF en mi tableta Google Nexus 7 “, finalmente compré una tableta Lenovo Yoga HD + 10” el mes pasado. La fuente era simplemente demasiado pequeña, y las soluciones no eran prácticas (hacer zoom, luego desplazarse a izquierda y derecha para leer la página, poco práctico en la cama, e incluso más arcaico que mis métodos de desarrollo). Al implementar aplicaciones para pacientes, una de las primeras cosas que hago es presentar una serie de oraciones (seis en total), cada una en una fuente de tamaño diferente, pidiéndoles que elijan la más pequeña que puedan leer CÓMODAMENTE. Su elección se almacena en su perfil de paciente, y todos los datos presentados en el futuro tienen un tamaño no menor que eso, utilizando técnicas dinámicas “inteligentes” para paginación y agrupación de datos. La capa de presentación es lo que todo el mundo tendrá que usar para interactuar con su aplicación: NO LA DESCONOCE.
Una vez que haya completado estos procesos, los datos que necesitan capturarse (como en la base de datos, archivo plano o lo que sea) se harán evidentes. Averigüe cómo normalizar los datos (google si el término no está claro) solo en la medida en que sea necesario para obtener el rendimiento. A muchos “puristas” les lavaron el cerebro en la escuela que los datos deberían normalizarse o que cada campo consultado debería tener una clave secundaria. En su lugar, concéntrese en el rendimiento … repetir un nombre de cliente en un campo de encabezado de pedido (en lugar de buscar el nombre en el maestro de clientes), si obvia la necesidad de buscar el registro maestro de clientes en casos sustanciales, es preferible. Equilibre eso tomándose el tiempo para pensar en instancias en las que este campo podría necesitar actualización, y pregúntese si realmente vale la pena (en algunos casos, lo es). Haga lo mismo con las claves de índice … cree claves secundarias solo cuando pueda justificar su uso. Si un archivo dado solo contiene unos pocos cientos de registros o menos, una clave secundaria puede no ser de mucho valor (especialmente si el DB en sí tiene caché ajustable); pero no haga lo que digo como regla general: hay muchas excepciones que miro, como la cantidad de teclas alternativas, su tamaño, el tamaño total de la base de datos, el impacto general frente a la conveniencia, etc. Trabajo de la manera más difícil. agregando donde se justifica, en lugar de incluir todo desde el principio.
Ahora trabaje en el flujo de la aplicación, y el acceso a la base de datos comenzará a destacarse … verá dónde necesita introducir datos en el flujo, hacer algo con él (mostrar, calcular, actualizar, etc.) y continuar con la lógica. Debes usar herramientas diseñadas para ayudarte con esto. Escribo el flujo usando oraciones y párrafos, porque soy arcaico y he encontrado que las herramientas modernas están mal documentadas (rara vez existe una guía paso a paso incremental), para tener demasiadas “características” que difuminan el producto y no produce aumento de productividad, o simplemente no funciona mejor que mi método arcaico prehistórico. Al menos, hace veinte años, dejé de dibujar diagramas de flujo con una plantilla y papel. He recibido comentarios de programadores por contrato que he usado de vez en cuando, sobre cuán minuciosa y fácil de seguir fue la descripción de mi “flujo” del programa.
Le sugiero encarecidamente que utilice los métodos modernos de hacer lo anterior, si actualmente no tiene un método que funcione para usted. Los resultados son lo que cuenta, y la eficiencia es parte del conjunto de resultados. Soy eficiente en lo que hago, usando las herramientas que uso. Sea eficiente / competente en cualquier herramienta que elija usar … sea un experto en sus herramientas, así como yo soy un experto en vi.
Ahora, comience a modularizar la aplicación (llamada OOP), sin volverse loco. He visto fábricas y procedimientos creados simplemente porque “esa es la forma en que nos enseñaron en la escuela” por programadores recién creados que no se dan cuenta de que el propósito de tal repetición en la escuela era enseñarles a ser buenos en esas cosas, no enseñarles ser innecesariamente repetitivo y micro fragmentado en el mundo real. Si se trata de un gran proyecto, cree un sistema básico con características básicas, dejando ganchos para todo lo que se necesitará. De esta manera, puede probar un sistema real en lugar de fragmentos. Bueno, lo que quiero decir es que tendrá un sistema real para probar fragmentos, en lugar de tener un montón de fragmentos que se prueban individualmente sin ninguna prueba de integración significativa. Así es como lo hago, y nuevamente, le insto a que considere los métodos modernos para hacerlo.
Probablemente estoy haciendo todo mal, y estaría de acuerdo con los puristas de hoy en día en que soy un aficionado cuando se trata de codificación (según sus reglas). Al mismo tiempo, tengo un historial de producción de aplicaciones a prueba de balas que siguen funcionando. Una aplicación basada en la web ha estado funcionando continuamente durante más de diez años, sin reiniciar (en FreeBSD, mi sistema operativo de elección), según el seguimiento de Alexa. Está a punto de dormir permanentemente el 1 de enero de 2015, a medida que la compañía pasa a un nuevo software y una infraestructura moderna (ahorrándolos un 70% en el proceso).
Espero que lo anterior te dé un comienzo. Históricamente, lo que he encontrado es que una aplicación es una aplicación (en cuanto a la planificación de requisitos), independientemente de la plataforma. La plataforma simplemente determina los detalles de implementación. En otras palabras, nada ha cambiado realmente, aunque parece que sí.
Una cosa que ayuda mucho, que me llevó una década dominar, es examinar (algunos dirían preguntas) todo lo que haces. Es fácil agregar todo tipo de características al software; a menos que sea un proyecto personal por diversión, no lo hagas. Si no hay un caso comercial convincente para agregar una función, no lo haga. Pregúntese, “¿cómo se agregará esta característica a las ganancias, la conveniencia o la retención?” Si no puede encontrar una respuesta legítima, hacerlo no sería objetivo.
Debido a que estoy más enfocado en la ingeniería de software, el desarrollo paralelo, la infraestructura de hardware y la expansión de nuestras ofertas, por necesidad tengo que contratar la programación y el desarrollo HTML5. Me sorprende lo que algunos programadores consideran un código aceptable, en términos de errores evidentes y falta de revisión de código (flujo). Me estremezco ante la idea de que una empresa de análisis de inversiones esté compuesta en su totalidad por programadores que trabajan a este nivel, y los estragos que deben causar en sus clientes institucionales. Pero, ese es el nuevo mundo valiente, supongo.
