Visin del Sistema

Visin es la capacidad de prever los detalles de un sistema o proceso desde antes del inicio del mismo. Cada persona relacionada con el proyecto puede tener una visin enteramente diferente sobre el mismo. Probablemente quienes tengan formacin en Administracin de Empresas, tendrn una visin operativa sobre el proyecto, preocupndose por temas de presupuesto y gestin contable. Quizs, aquellos que tengan una formacin en el rea de informtica y sistemas, tendern a verlo todo como una aplicacin de base de datos con un determino requisito de interfaz de usuario y generacin de reportes. Tambin es probable, que los usuarios del futuro sistema se preocupen por la facilidad de uso y por la conveniencia que el nuevo desarrollo les brindara en sus actividades diarias. Estas y todas las dems visiones del sistema son correctas. Claramente son diferentes, pero son todas ciertas y correctas al mismo tiempo, ya que el sistema a desarrollar debe responder a las necesidades y requisitos de cada uno de sus usuarios y grupos de decisin. Es de vital importancia que nuestro proceso de levantamiento de requisitos incluya la captura de estas visiones particulares. A partir de estas opiniones es que se dar forma a los requisitos del sistema y en definitiva, al sistema en si. Notemos que en este grupo de visiones debemos incluir la nuestra. Nosotros, que somos quienes guiamos el proceso y ejecutamos el desarrollo de lo solicitado, tenemos un visin sobre lo que se va a hacer, y es una opinin tan valida e interesante como la de aquel que ha firmado la orden de compra del proyecto. Todas estas visiones deben, si me permiten recapitular, ser recogidas en un documento, al que para no pecar de originales, llamaremos Visin del Sistema. Este es uno de los artefactos claves del Proceso Unificado de Desarrollo (UP), y una vez que le tengamos confianza y le conozcamos mejor le llamaremos simplemente Visin. El documento de Visin no se queda ah. Enumerar los puntos de vista de los grupos de decisin es en si algo muy importante, pero es que hay espacio para ejecutar algo mucho ms extenso. Desarrollaremos como parte del documento, la seguidilla de los siguientes puntos:

Enumeracin de los Grupos de Decisin. Identificando claramente quien es el representante de cada quien y cual es el rol o misin que este asumir dentro del proyecto. Declaracin de la visin de cada Grupo de Decisin identificado, incluyndonos a nosotros mismos como desarrolladores del sistema.

Enunciado de los problemas actuales y de las oportunidades que se perciben como posibles a la luz de lo prometido por el proyecto. Elaboracin de un listado de macro-caractersticas que atacan a los problemas observados. Elaboracin de un listado de caractersticas individuales que refinan lo dicho en las macro-caractersticas. Identificacin de los requisitos no funcionales ms importantes: tales como consideraciones sobre el entorno de explotacin, documentacin requerida o ideas sobre el impacto ambiental y social del proyecto.

Definimos Riesgo como

Entenderemos por riesgo cualquier situacin posible que de ocurrir perjudique al proyecto en alguna forma. Un riesgo puede ser desde que un avin se caiga hasta que las lneas de crdito del proyecto no sean aprobadas por el banco. Todo lo que pueda ocurrir, si es malo, es un riesgo. Riesgo hace referencia a toda situacin posible que de verificarse, hace dao al proyecto o incide negativamente sobre el desempeo del mismo. Cualquier administrador de proyectos hace bien en identificar una lista de riesgos y en evaluar si estos son ms o menos inminentes. Dicha revisin conviene hacerla en cada oportunidad que se tenga, sobre todo, en las reuniones de avance del proyecto. Es buena prctica mantener un documento que liste los riesgos identificados, junto con su probabilidad de aparecer, y el costo o magnitud del dao que haran en tal caso. En este caso, a la hora de identificar riesgos conviene trabajar un poco de ms y tener una enumeracin ms larga de la necesaria. Eso es mucho mejor que dejarse sorprender por una situacin negativa.

Como combatir los riesgos

Existen tres formas bsicas de combatir los riesgos: eliminacin, cobertura y diversificacin. Estas estrategias son sencillas y de aplicacin universal, en cuanto valen como posibles alternativas ante cualquier tipo de riesgo. Veremos si las podemos explicar con ayuda de un ejemplo deportivo. Digamos que hay dos equipos de ftbol en la liga, que tienen mucha competencia entre ellos. Nosotros estamos en posicin de apostar y como perder es algo que no queremos entonces estamos frente a nuestro riesgo ya definido: perder nuestra apuesta. Como tal, este riesgo tiene una probabilidad de ocurrencia del 50% estadstica que bien puede variar en funcin de los equipos en cuestin. Este porcentaje es la probabilidad de ocurrencia del evento. 50% significa que el asunto es como tirar una moneda: puede que se gane, puede que se pierda.

Vamos a trabajar este riesgo con la primera alternativa. La Eliminacin de Riesgos es el acto de tomar decisiones que los hacen imposibles de ocurrir. En nuestro caso: decidir no apostar. En cuanto a la segunda alternativa, si apostamos no a uno solo sino a los dos equipos pues uno de ellos necesariamente ganar cierto? A esta estrategia la llamamos Cobertura de Riesgos. Ante un riesgo dado, su cobertura ser un evento necesariamente opuesto que ocurre al presentarte el problema y que hemos dispuesto que nos compense por el dao recibido. Finalmente tenemos La Diversificacin de Riesgos. Esta es simplemente no apostar tan solo en el partido de nuestro ejemplo, sino que tambin vamos a atrevernos a apostar en otros. De esta forma, perderemos en algunos y ganaremos en otros. A la larga, una buena poltica de diversificacin puede hacernos ganar incluso si hemos perdido una fraccin importante de los encuentros. Los riesgos son parte de la vida as que hay que prepararse contra ellos y para cada uno escoger una de las polticas bsicas: Eliminacin, Cobertura y Diversificacin.

Requisitos vs. Requerimientos

Un caso de estas disputas son la pareja de palabras Requisitos y Requerimiento. En lo personal prefiero la primera, pues me parece una forma correcta, corta y suave de utilizar como sustantivo la idea de algo que es requerido. Si se requiere, es un requisito. As tenemos que el uso de requisito denota algo que se espera cumplir. Si lo que queremos es indicar que este hecho de requerir se ha dado, se ha transferido de manos, la gente espontneamente opta por utilizar la palabra Requerimiento. Por tanto, un requerimiento se da o se indica para que otro lo tenga como requisito. En tanto que si uno identifica algo que es necesario cumplir, lo anota como un requisito desde el principio.

Guiado por Requisitos y Riesgos

Poniendo esto en forma ms clara, tendramos dos puntos: Primero: UP es guiado por requisitos, lo cual quiere decir que es segn estos como se expresa tanto la divisin del proyecto en subproyectos, como la planificacin de las tareas a abarcar en una iteracin dada. Si tenemos un Paquete de Requisitos con una organizacin racional, veremos que UP recomienda basarse en esta divisin para ir cubriendo los requisitos en una forma ordenada y sistemtica, atendiendo sus dependencias y maximizando en todo momento el valor de negocio entregado por las actividades. Segundo: UP es guiado por riesgos, lo cual en forma anloga a la anterior, significa que en cada iteracin se incluirn actividades y tareas que busquen atacar los riesgos, segn orden el de importancia con que se registraron estos en el Plan de Riegos del proyecto.