Feed de Edgaragg

Artículos relacionados

Facebook Share

Share on facebook

Designed by:
SiteGround web hosting Joomla Templates
¿Por qué fracasan los proyectos de software? Parte II PDF Imprimir E-mail
Escrito por edgaragg   
Domingo, 22 de Febrero de 2009 15:29

En esta ocasión vamos a dedicarnos un poco a hablar sobre el diseño y construcción de un proyecto de software tomando como base los requerimientos no funcionales, sobre los cuales ya he hablado en la primera parte.

Como ya se dijo en la primera parte, estos requerimientos no funcionales son sumamente importantes porque definen las características operativas de un sistema. Así que no importa cuáles sean los requerimientos funcionales de un software, serán estos requerimientos no funcionales los que van a garantizar que pueda ofrecer las funciones para las que fue diseñado.

Los requerimientos no funcionales de un proyecto de software incluyen disponibilidad, seguridad y administración del sistema. También incluyen otros requerimientos que van más allá de la ejecución del software como escalabilidad, portabilidad y mantenibilidad.

Los requerimientos no funcionales tienen la característica de ser expresados en términos demasiados técnicos para ser entendido por ejecutivos del negocio (usualmente los clientes y/o usuarios), así que nos encontramos con que estos requerimientos escapan de la zona de confort de dichos ejecutivos (ya que les resultan difíciles de entender). Por esta razón esas pequeñas decisiones técnicas que se hacen continuamente durante el desarrollo del proyecto (que pueden ser cientos de ella cada semana y están asociadas directamente a requerimientos no funcionales) deben ser tomadas por los arquitectos del software. Y dichas decisiones tendrán un impacto mayor una vez que el software este en producción.

Es importante tomar en cuenta siempre estos requerimientos no funcionales en cada toma de decisiones, y tomar en cuenta como esta decisión puede afectar el desarrollo del proyecto en ese momento y en un futuro. Una decisión mal tomada puede afectar el desarrollo de una forma tal que el proyecto puede terminar en un fracaso. Por esa razón es que todas las decisiones deben ser tomadas en cuenta cómo afecta a los requerimientos no funcionales y como podría afectarlos en un futuro.

Muchas veces como desarrolladores tomamos decisiones que pueden comprometer o violar los requerimientos no funcionales de un sistema. Para dar un ejemplo concreto es una buena práctica validar todos los datos de entrada de una aplicación (más aún cuando hablamos de una aplicación web), obviar dicha validación o hacerla pobremente abre las puertas a una diversidad de ataques (por ejemplo de tipo buffer overrun) que puede comprometer la seguridad de la aplicación. Si en el software que estamos desarrollando la seguridad no tiene una importancia vital, podríamos hacer una validación simple de los datos de entrada. Pero si la seguridad es de vital importancia, hay que asegurarse que la data que ingresa esta en el formato correcto y sea consistente para evitar (o por lo menos dificultar) cualquier ataque.

Muchas veces nos encontramos con el problema de que cumplir con los requerimientos no funcionales implica un mayor tiempo de desarrollo y en muchos de los casos (por no decir la mayoría) los proyectos deben ser terminados en una fecha específica, y conociendo que ya de por sí los requerimientos tienden a cambiar y la fecha de entrega se va tornando poco a poco inalcanzable lo primero que se sacrifica son los requerimientos no funcionales. Para dar un ejemplo como hay que entregar cierta parte del sistema en una fecha dada para cumplir con el cronograma, no se incluyen las validaciones de la data (para seguir con el ejemplo anterior) y como consecuencia dicho sección de código puede comprometer la seguridad del sistema. Pudiendo ser atacada una vez que este en producción y costando al cliente una gran cantidad de dinero para arreglar el fallo y eso sin tomar en cuenta la mala reputación que da a los clientes el tener una aplicación insegura, los cuales son costos intangibles ya que son muy difíciles de cuantificar.

Otro ejemplo que ocurre comúnmente es que por la necesidad de entregar un código en la fecha estipulada se escribe el código de una forma que no necesariamente es el más eficiente. Se termina de escribir el código se hacen ciertas pruebas y no se dedica nada de tiempo a optimizar y refactorizar el código. Esto conlleva a tener un código ineficiente y en ocasiones difícil de entender (situación que se empeora porque no se documenta el código). Un código ineficiente tiende a hacer que el sistema sea lento y la lentitud en una aplicación se magnifica cuando el sistema es multi-usuario y hay una gran cantidad de usuarios usando la aplicación al mismo tiempo y si la aplicación es web puede causar el abandono por parte de los usuarios y por lo tanto la pérdida de un cliente.

Como conclusión, los proyectos de software pueden ser severamente comprometidos durante la fase de análisis, diseño y construcción de dicho software. Muchas veces lo podemos hacer de forma inconsciente. Y ese impacto puede que no lo veamos sino hasta cierto tiempo después de que la aplicación esta en producción y operativa, incluso pueden pasar años antes de darnos cuenta. Por esta razón, los arquitectos de software tienen que asegurarse de que se preste la atención suficiente a los requerimientos no funcionales del software.

En muchas ocasiones los requerimientos no funcionales son sacrificados porque no se les presta la atención suficiente y en parte eso sucede porque los arquitectos no transmiten la importancia que estos tienen a los encargados del negocio (los clientes) los líderes del proyecto o quien sea que tenga capacidad de decisión en el proyecto.

Actualizado ( Jueves, 16 de Abril de 2009 14:13 )