Top 5 : Riesgos del desarrollo web


Los riesgos son parte cualquier proyecto. Riesgos podrían estar asociados con la calidad del producto, costos ocultos y la ampliación de los plazos, por nombrar algunos. No hace falta que uses una tecnología "Open Source" como Drupal para experimentar estos riesgos.
Si vas a gestionar un proyecto web o vas a contratar a alguien que lo haga por vos, debes saber cómo mitigar estos riesgos y conocer cuáles son los riesgos característicos de proyectos "Open Source".

 

1. Consiguiendo el "soporte"

A diferencia de las aplicaciones propietarias, el "soporte" en una comunidad de código abierto no es una persona sen-tado en un servicio de asistencia virtual, esperando su llamada de chat o correo electrónico.
¿Qué hacer cuando no se puede encontrar un voluntario experto en la comunidad dispuesto a ayudarte?

  • Aumente su conocimiento propio de modo que no tengas que depender de otros para las cosas pequeñas.
  • Ofrecer en la comunidad, pagar a cambio del soporte, de modo que no tiengas que esperar a que un voluntario lo haga grátis.
  • Acordar con una empresa de servicios con experiencia en Drupal para el desarrollo y soporte de mantenimiento de tu proyecto.

 

2. Cancelación de una comunidad "Open Source"

¿Qué pasa si Drupal desaparece? Drupal se creó en 2001 y ha estado creciendo constantemente desde entonces. En mi humilde opinión, la probabilidad de que la comunidad se fuera de Drupal después de su gran aceptación en todo el mundo es muy baja.
¿Cómo evitar este problema? Técnicamente, no es posible, estará ahí todo el tiempo en cada aplicación que utilice.
Sólo tienes que mirar la situación y juzgar si se siente suficiente interés por la comunidad y la inversión existe para mantener a la comunidad por el tiempo que se tiene una necesidad de la comunidad.

Garantizar la seguridad
La seguridad en las aplicaciones de software siempre será un problema.
Algunos opinan que las aplicaciones de código abierto son menos seguras que las aplicaciones propietarias. En algunos casos, esto es cierto pero en otros no. Esto depende de muchos factores como los niveles de control del código, los mecanismos de funcionamiento de la comunidad, etc.
La comunidad de Drupal, tiene una buena seguridad monitoreo y la actualización de las prácticas.
Para mitigar este riesgo considera las siguiente opciones:

  • Asegúrese de que su instalación de Drupal está conectada a la comunidad y su sitio está siempre monitoreando las actualizaciones y cambios de código de la comunidad.
  • Aplicar las actualizaciones de seguridad para núcleo de Drupal y los módulos aportados cuando estén disponibles.
  • Investigar un módulo contribuido antes de usarlo. Ver si alguien ha encontrado ningún problema y si una resolución está disponible.
  • Si surge un problema de seguridad, evaluar su aplicabilidad al uso, para determinar su nivel de riesgo. Trabajar con el desarrollador del módulo para solucionar el problema de seguridad.

Recuerde, no hay ningún código perfecto. El número de piratas informáticos sigue creciendo.
Incluso si usted construye su sitio desde cero, tiene el riesgo de imprevistos seguridad internacionales.
Evaluar la tolerancia al riesgo de cada proyecto y proceder en consecuencia es la mejor práctica.

 

3. Falta de fechas de entrega

Otro de los potenciales riesgos está asociado a la agenda de trabajo.
Las agendas y tiempos de entrega son complejas de prever en los proyectos de desarrollo web. A menos que usted tenga su propio equipo de codificación y recursos, es aconsejable partir su proyecto en fases.
Recoger los requisitos del sitio y evaluar cómo se lo puede construir con los módulos existentes, en vez de trabajos a medida, y luego crear una agenda o gantt.
¿Cuántos clientes quieren pasar por este proceso? Algunos estarán dispuestos y en otros no, pero es una opción.

 

4. No hacer reuniones de requerimientos

Un entregable definido de forma incompleta es siempre un gran riesgo. Por supuesto, si los resultados están o no incompletos podría ser una cuestión de opinión y punto de vista. Lo que los clientes tienen en mente y lo que piden, pueden ser dos cosas diferentes.

Si usted es el desarrollador, la investigación más allá de "yo quiero un blog" y las declaraciones de los clientes para aprender más sobre lo que estamos tratando de hacer es su mejor aliado.

Si usted es el propietario del sitio y toma de decisiones, deberá ser lo más descriptivo posible. No asuma que su comprensión de algo es igual a la del desarrollador.

  • Describa el proceso o tarea que espera que el website soporte o haga
  • Evite el uso de términos como blog, wiki, timeline, etc como su única descripción de lo que quiere hacer.
  • Apresuradamente evaluar la probabilidad de que un requisito requiere de un trabajo personalizado o standard y planificar en consecuencia.
  • Elije a tu proveedor de desarrollo basándote en que tenga experiencia previa construyendo lo que buscas.

 

5. Trabajar con proveedores

Si usted contrata proveedores para ayudarle a construir su sitio, se corre el riesgo de que no se entreguen de la forma que lo prometieron, o que invierta el dinero y que finalmente no tenga el sitio que quería.
La demanda de más sofisticados sitios va en aumento. Cada vez más se busca a los desarrolladores de Drupal y muchos están haciendo promesas que no puede cumplir. Para mitigar este riesgo, considera lo siguiente:

  • Solicitar y verificar las referencias. Las cuestiones con proveedores no son exclusivas de las aplicaciones de código abierto, pero la comprobación de referencias puede ayudar a revelar los problemas obvios.
  • Establecer una relación con los proveedores formando un equipo integrado, Esto le permitirá estar al tanto de lo que están haciendo y lo bien que están avanzando.
  • Has un esfuerzo para aprender todo lo que puedas sobre la configuración de Drupal. Numerosos videos, libros y cursos de capacitación están disponibles para ayudarle a aprender lo suficiente para saber si un vendedor te está tratando de engañar.
  • Contratar a un consultor analísta web para que opere entre usted y el proveedor de desarrollo. En el caso de que no pueda hacerlo, elija un proveedor que disponga de un analista web en el equipo y trabaje con él en la definición de requerimientos.
  • En algunos casos puede contratar a su propio equipo de desarrollo y crear su propio departamento web.
  • Nunca sea vago cuando comunica lo que quiere hacer. Incluso el mejor proveedor es probable que no entienda lo que usted desea, cuando usted ahorra tiempo y dedicación para comunicar su idea.

 


Añadir nuevo comentario

Plain text

  • No se permiten etiquetas HTML.
  • Las direcciones de las páginas web y las de correo se convierten en enlaces automáticamente.
  • Saltos automáticos de líneas y de párrafos.
Image CAPTCHA