domingo, 25 de abril de 2010
Respecto a la metodología MeRinde...
Leyendo algunos artículos de la metodología MeRinde me parece que es interesante, pero no he tenido la oportunidad de trabajar con ella y no la conozco muy bien, únicamente lo que sé ha sido porque me he documentado en Internet y por los aportes que he tenido la oportunidad de intercambiar con un grupo de compañeros que tienen los mismos intereses que yo en cuanto a la comunidad de Software Libre, pero menciono este tema, ya que me gustaría conocer experiencias de personas que han tenido la oportunidad de trabajar con ella, saber la opinión en cuanto a la metodología RUP y esta, ya que poseen mucha similitud. Estoy haciendo un estudio de dichas metodologías a ver que beneficios me aporta cada una de ellas y me gustaría saber tu opinión práctica al respecto.
Diferencias y similitudes entre enfoques metodológicos de hoy y del ayer..
Las diferencias observadas en los nuevos enfoques metodológico son varias, entre ellas se encuentran que actualmente: Se busca minimizar errores desde las etapas iniciales, en vez de esperar a que ocurran en la implantación y arreglarlos, se busca la manera de mantener documentado lo que se va realizando para facilitar su comprensión y posterior funcionamiento o mantenimiento. Se realiza un análisis completo de todo el proceso, estimando lo que pudiese existir a futuro e ideando posibles escenarios para prevenir cualquier inconveniente. Reduce costos en base a lo que necesita obtener, los recursos que maneja y los análisis previamente descritos. Por lo general, se mantiene mayor interacción con el cliente durante todo el proceso. En los enfoques metodológicos, cada vez más se hace presencia como algo indispensable el control de la calidad para cada uno de los proyectos que se lleven a cabo.
En cuanto a las similitudes, pues noto que aún se mantiene la razón de ser del enfoque metodológico, que es seguir una serie de pasos, de etapas sistemáticas para obtener un producto final adaptado a lo que se necesita, actualmente va más allá de lo que el cliente necesita, sino que se trata de abarcar todo el área que abarca la competencia en relación a este criterio en particular que se está trabajando.
En cuanto a las similitudes, pues noto que aún se mantiene la razón de ser del enfoque metodológico, que es seguir una serie de pasos, de etapas sistemáticas para obtener un producto final adaptado a lo que se necesita, actualmente va más allá de lo que el cliente necesita, sino que se trata de abarcar todo el área que abarca la competencia en relación a este criterio en particular que se está trabajando.
Riesgos de la implementación de un SI basado en SL
Entre algunos de los riesgos que veo en la implementación de un sistema de información basado en Software Libre es que pudiese existir escasez de soporte o por lo contrario a un alto costo, ya que esto por lo general no es un acuerdo que se realiza antes de la adquisición del Software Libre. Existe un tema muy importante también que es la seguridad de la información y dependiendo de cómo estén establecidas las cualidades mínimas de seguridad de esto y de cómo se involucra el control de la información del usuario por parte del proveedor, podría llegar a ser un riesgo o no. Por otra parte, está el tema de la calidad del producto, esto no necesariamente es un riesgo, ya que con la existencia de tantas metodologías, formas de trabajo, teorías de calidad, desarrollos libres que incorporan calidad este riesgo es minimizado, ya que por lo general, todo producto terminado en la actualidad posee un alto índice de calidad y esto es necesario para poder competir en este mundo de oportunidades tecnológicas que día a día nos invaden con excelentes innovaciones.
Selección de metodología en una gestión de proyecto
Al momento de gestionar un proyecto, lo primero que debe hacer la empresa, la persona, el comité o la comunidad que esté desarrollando el proyecto, es analizar sus condiciones y preguntarse que desea obtener, cuando lo desea obtener, a que costo, con que recursos cuenta para lograr lo propuesto, entre otros detalles lo que le harán decidir que metodología emplear para sus desarrollos de software internos, bien sea una existente (ya que hay una gran gama hasta la fecha) o una mezcla de metodologías del mercado con alguna variación propia para adaptarlo a sus necesidades. Es importante que se tome muy en cuenta este análisis ya que en gran parte dependerá del éxito o fracaso del producto obtenido.
Por otra parte, pienso que en una organización pudiesen existir diferentes tipos de metodologías para el desarrollo de sus software ya que este debe adaptarse a las especificaciones de cada uno de los proyectos que se llevan a cabo, quizás uno de ellos necesita mayores recursos porque debe salir en el menor tiempo posible, mientras que otros requieren de una metodología más analítica y no necesita ser entregado a corto plazo, entre otros detalles que marcan la selección correcta de la metodología a implementar.
Por otra parte, pienso que en una organización pudiesen existir diferentes tipos de metodologías para el desarrollo de sus software ya que este debe adaptarse a las especificaciones de cada uno de los proyectos que se llevan a cabo, quizás uno de ellos necesita mayores recursos porque debe salir en el menor tiempo posible, mientras que otros requieren de una metodología más analítica y no necesita ser entregado a corto plazo, entre otros detalles que marcan la selección correcta de la metodología a implementar.
Experiencias propias en metodologías de desarrollo de software
En cuanto a las metodologías de desarrollo de software, he tenido la oportunidad de llevar a la práctica dos de ellas. La metodología XP la utilicé en mi tesis mezclada con otra en donde nos facilitó la culminación de dicho trabajo de grado, ya que se contaba con poco tiempo y se necesita obtener el producto con ciertas funcionalidades como requisitos mínimos del cliente en una primera etapa, y esto nos conlleva a buscar la manera de minimizar la taza de defectos y los retrasos en la planificación, así como la participación de todos los involucrados en el proyecto. Dentro de mi experiencia como programador, me parece indispensable que exista la retroalimentación continua entre el cliente, los usuarios y los desarrolladores del software, ya que esto permite aclarar las especificaciones y a medida que avanza el proyecto permite ver las cosas con mayor claridad en ambos lados del proyecto.
Por otra parte, he tenido la oportunidad de trabajar con SCRUM en desarrollos dentro del trabajo, aunque muy poco, pero dentro de mi experiencia, esta metodología es muy productiva ya que se inicialmente se realiza una programación basado en todos los puntos de vista del producto (lo que desea el cliente, en el tiempo que lo quisiera el cliente, lo que pueden lograr los desarrolladores y lo que piensa el gestor del proyecto analizando todos estos puntos), posteriormente, esa planificación es chequeada continuamente ya que se deben realizar reuniones diarias donde se mencione que se ha logrado hasta el momento.
Esta última metodología se pudiese aplicar para cuando se tiene mayor tiempo para desarrollar mientras que la otra es para corto plazo generalmente, ya que quizás las reuniones diarias para un proyecto tan corto no son beneficiosas. Pero existen muchísimas metodologías y todas tienen sus ventajas y desventajas, todo depende de lo que se desee desarrollar, como, en cuanto tiempo, etc, etc.
Por otra parte, he tenido la oportunidad de trabajar con SCRUM en desarrollos dentro del trabajo, aunque muy poco, pero dentro de mi experiencia, esta metodología es muy productiva ya que se inicialmente se realiza una programación basado en todos los puntos de vista del producto (lo que desea el cliente, en el tiempo que lo quisiera el cliente, lo que pueden lograr los desarrolladores y lo que piensa el gestor del proyecto analizando todos estos puntos), posteriormente, esa planificación es chequeada continuamente ya que se deben realizar reuniones diarias donde se mencione que se ha logrado hasta el momento.
Esta última metodología se pudiese aplicar para cuando se tiene mayor tiempo para desarrollar mientras que la otra es para corto plazo generalmente, ya que quizás las reuniones diarias para un proyecto tan corto no son beneficiosas. Pero existen muchísimas metodologías y todas tienen sus ventajas y desventajas, todo depende de lo que se desee desarrollar, como, en cuanto tiempo, etc, etc.
Sistema de Control de Incidencias - Mantis BT

En mi experiencia práctica utilizo un sistema de control de incidencias, el cual los invito a indagar más sobre el a ver si les parece interesante.
Hablo de sistema MBT, que significa Mantis Bug Tracker por sus siglas en inglés, que como mencioné anteriormente, es un sistema para el control de incidencia, este sistema es libre, puede descargarse gratuitamente desde la página http://www.mantisbt.org/ y es completo. Funciona bajo casi cualquier navegador web, y trabaja con tres base de datos distintas: MySQL, MS SQL y PostgreSQL. Este software web, lo he utilizado por dos años y permite hacer seguimiento de las incidencias presentas, tanto por los desarrolladores como por el líder, te envía toda modificación realizada vía correo electrónico de todas las modificaciones ocurridas en todos los proyectos en los cuales se están incluido, bien sea como espectador, como desarrollador, como QA o como líder del proyecto. Dentro de mi experiencia, de verdad se los recomiendo.
¿Qué técnicas nos ayudan a estimar el desarrollo del SL?
La técnica que conozco y he utilizando para la estimación de un desarrollo es la NUCP que es un modelo estadístico formal basado en el concepto de puntos normalizados de casos de uso. Este modelo permite, de manera muy sencilla, realizar una estimación inicial del esfuerzo asociado a un proyecto a partir de los requisitos funcionales del mismo (los casos de uso), así como realizar ajustes consensuados en cuanto sea necesario. Esto es importante ya que en estos casos de uso se detalla la información de los actores involucrados en los procesos así como la funcionalidad del sistema y el tipo de interacción entre cada uno (participación de un actor en el caso de uso, inclusión del comportamiento de un escenario en otro, relación de dependencia, entre otros).
Suscribirse a:
Entradas (Atom)
