El proyecto Kentana tiene como objetivo optimizar el desarrollo de software empresarial. Adicionalmente apoyar a los emprendedores y pequeños empresarios a convertir sus sueños en software. Para lograr tal objetivo he desarrollado un software que sirva como base para cada software nuevo. La primera versión ha sido un PMV que ahora pasaré a analizar detalladamente desde la perspectiva DOFA. De esta manera se pueden plantear las estrategias correctas para mejorar el producto.
Identificación de los fallos y debilidades de la primera versión
En esta ocasión hablaremos de las debilidades que presenta y que están pendientes de mejora. Esto se ha podido detectar tras las pruebas realizadas por parte mía y de los betatesters interesados. Adicionalmente por medio del desarrollo de algunos sistemas para los clientes que han salido para esta temporada. Hay que tener en cuenta que si bien es un PMV presenta muchas oportunidades de mejora. A continuación, se muestra el listado de las que he podido detectar y una pequeña explicación de cada una:
-
Reutilización ineficiente de código
Ya sea por falta de experiencia en el uso de CodeIgniter se implementó el sistema basado en el tutorial inicial y luego se reutilizaron los códigos en vez de enviarlos a librerías de forma adecuada.
-
Mal uso de las vistas
En sincronía con el problema anterior las vistas se usaron varias veces en cada controlador lo cual es un error y obliga a utilizar el código de las vistas en diferentes archivos.
-
Enfoque erróneo de objetos
Debido a que vengo de un ambiente de desarrollo que no está enfocado a objetos se usó formularios y el concepto de CRUD en cada controlador. Esto no es una gran debilidad, pero se podría decir que no corresponde al desarrollo de PHP y el enfoque MVC.
-
Poca integración con CodeIgniter
Es una debilidad “controlada” ya que de mi parte quería tener la menor dependencia de esta herramienta. La razón es que, si debía migrar a otra plataforma o framework, que la migración no fuera tan difícil.
-
Dificultad para el desarrollo de herramientas y expansiones
Si bien la instalación es sencilla, el desarrollo de estos conceptos requería experiencia de uso con el Core. esto hace que la barrera de entrada sea grande para nuevos desarrolladores interesados.
-
Necesidad de un ambiente de desarrollo en un PC Físico
Para poder usar Kentana Core se necesita instalar WAMP o LAMP en el computador del desarrollador. Para poder hacer pruebas de contacto esto hace que muchos desistan a probar el software.
-
Gestión confusa de permisos y roles
Si bien trate de separar permisos y usuarios administrativos y usuarios comunes en realidad la gestión se complica con la instalación de nuevos programas.
-
Perfil root sin acceso a algunas funcionalidades
Inicialmente me pareció una buena idea que el perfil root solo tuviera acceso a configuraciones del sistema. Pero con el tiempo me di cuenta que hace falta que un súper usuario tenga acceso a otras funcionalidades que tiene el administrador.
-
El desarrollo de prototipos requiere trabajo extra
El desarrollo de un prototipo debería poderse usar o exportar para el nuevo sistema que se va a desarrollar. Por el momento el código y configuraciones de los prototipos son independientes al producto final.
-
Uso complejo en pantallas de registro
Las pantallas de registro normalmente usan muchos modelos y objetos. Como el sistema no se enfocó a los objetos pues hace que el uso de esta metodología sea muy complejo.
-
El concepto de Core
Los clientes de desarrollos a medida no entienden muy bien que obtendrán un software base sin costo, pero que pagarán por el desarrollo de una expansión.
-
Adaptación responsive
De las tres implementaciones esperadas para la primera versión, quedó pendiente la adaptación del sistema web a diferentes dispositivos de forma visible.
