Lectura Fundamental Anterior: “RUP: Fase de Concepción”Lectura # 9
RUP: Fase de Concepción, Parte 2
“¿De dónde viene esto? Esta búsqueda, esta necesidad de solventar los misterios de la vida..., cuando las más simples preguntas nunca han sido contestadas.
¿Por qué estamos aquí? ¿Qué es el alma? ¿Por qué soñamos? Puede que sea mucho mejor si dejáramos de buscarlas. Sin investigar, sin anhelar. Esa no es la naturaleza humana. No está en el corazón humano.
¡Ése no es el motivo por el que estamos aquí!”
Héroes (Capítulo 1, “Génesis”)
Según las creencias de algunas tribus primitivas de la India, la Tierra era una enorme bandeja de té que descansaba sobre tres enormes elefantes, los que a su vez estaban sobre la caparazón de una tortuga corpulenta. En otra geografía, los antiguos egipcios mitificaron el cielo como una versión etérea del rio Nilo, a través del cual el dios Ra (el Sol) navegaba de Oriente a Occidente cada día, regresando a su sitio de partida por los abismos subterráneos donde residen los muertos; para ellos, los eclipses eran inducidos por ataques de una serpiente a la embarcación de Ra.
Así comienzan los proyectos de software: con usa serie de afirmaciones que a veces distan mucho de la realidad. Hacer que la Tierra efectivamente sea redonda, que el cielo sea un reflejo fantástico de las cosas en el cerebro humano y que los eclipses realmente se provoquen a medida que la luz procedente de un cuerpo celeste es bloqueada por otro, es una tarea ardua que requiere de tiempo, de foco, de actitud. Es la faena del Analista del Software.
En términos simples, en la Concepción buscamos un acuerdo con los usuarios sobre lo que hará el sistema. Durante esta fase atendemos cuidadosamente cada palabra de los usuarios, indagamos por el problema y el problema detrás del problema, nos movemos precisamente en el espacio del problema y desde ningún punto de vista pensamos en la solución. Bueno, hasta cierto grado. Una vez que hayamos entendido y acordado esa cuestión, resumida con diligencia en el documento de Visión y Alcance y tengamos claridad sobre el impacto, sobre los afectados y sobre lo que podrían ser los beneficios de una posible solución, entonces nos movemos al espacio de ésta, donde consideramos las características mayores del software a producir.
Estas características están en el nivel intermedio entre las necesidades de los usuarios y los requisitos detallados de la solución, de tal manera que constituyen un puente estructural entre las unas y los otros y definen la organización del sistema.
Hacer la transición entre lo que es y lo que será, enfrentarse a la ambiciosa tarea de prever el futuro cercano (¡a veces incierto!) de un proyecto de tecnología informática, con la profundidad y el rigor necesarios para calcar en palabras e imágenes las ideas y los sueños de docenas, quizás de cientos de usuarios, es algo que sólo la perspicacia y la sabiduría del Analista del Sistema es capaz de lograr.
El Analista de RequisitosGran parte de la responsabilidad del éxito de la fase de Concepción de un proyecto depende del Ingeniero de Requisitos, Analista del Software o Analista de Requisitos.
Analizar el problema de los usuarios comienza con la búsqueda y concertación de un vocabulario común, un glosario que sirva de referencia para todos los interesados en el proyecto, desde los mismos usuarios, los administradores del proyecto, los diseñadores y arquitectos, los programadores, los probadores y cualquier otra persona que requiera información sobre el proyecto y el producto a construir. En paralelo, el Analista busca actores y casos de uso (el mecanismo último para elicitar, especificar y administrar los requisitos del software), es decir, quién hará qué en el sistema (no puedo pasar por aquí sin permitirme remitirlos a mis cinco primeras Lecturas Fundamentales, donde abordé ampliamente este asunto de los casos de uso). Aquí el orden altera el resultado, por eso resalto que primero debemos conocer a los actores que jugarán un papel en el sistema y que luego ubiquemos sus necesidades como organismos primarios de funcionalidad en el software por desarrollar. Uno de los grandes motivos de fracaso en proyectos de software es que al final se encuentran en ellos funciones o módulos completos que nadie solicitó, que nadie necesitaba; también, funcionalidad equivocada. Eso se debe a que no anticipamos con quien o quienes iba a interactuar nuestro sistema.
El espiral de actividades del Analista se complementa con el desarrollo de la
Visión del proyecto, condición sine qua non para terminar la fase de Concepción. Pero durante ese desarrollo, los Analistas nos enfrentamos a demasiadas posibilidades y muchas de nuestras aseveraciones (a manera de especificaciones) pueden vacilar porque reflejan puntos de vista coartados y hasta extravagantes de una sola persona o de muchas personas que no se ponen de acuerdo entre ellas. Es labor nuestra encontrar a los individuos adecuados, a los representantes apropiados de los usuarios, ojalá con distintos puntos de vista, conocimiento y experiencia, y entrevistarlos para así poder delinear un marco conceptual y temporal en el que esa Visión se lleve a cabo antes de terminar con el presupuesto del proyecto.
Los Analistas pasamos (o deberíamos pasar) de transeúntes pasivos en materia del conocimiento del negocio que nos ocupa a ser coreógrafos activos del proceso previamente expuesto por los usuarios. En un sentido limitado esto quiere decir que primero debemos escuchar. Un Analista que hable mucho en las primeras de cambio con los usuarios corre el riesgo de caer en el conductivismo, o sea, llevar al usuario por donde cree que debería ir, cuando en realidad debe ser él (o ella) quien conduzca su propio destino. Si ya tenemos experiencia en el negocio debemos incluso estar más atentos porque entonces caemos en el
síndrome de la copa medio llena, cuando en realidad está medio vacía; esto es, el conocimiento previo evita que escuchemos como ávidos observadores las recién descubiertas necesidades de nuestro interlocutor.
Después, cuando haya suficientes exposiciones de los usuarios, finalmente empezaremos a descodificar sus palabras, sus ideas, sus verdades, mediante un proceso de ingeniería que las convierta en expresiones que se puedan ejecutar en un computador, que sean factibles de automatizar. Eso significa entonces que nos hemos convertido en conocedores de ese negocio (o de esa parte específica del negocio), con lo que bien podríamos contribuir al mejoramiento del mismo poniendo de manifiesto las tareas repetitivas, las posibles ambigüedades, las actividades imposibles y las faltantes en el proceso de la organización para la cual desarrollamos el sistema. Eso simboliza ser “coreógrafos activos.”
Al definir la visión, es fundamental comprender el marco temporal que tenemos para hacerla realidad. Nos enfrentaremos a diferentes tecnologías, condiciones y personas. Es importante que quede claro qué hará el producto de software, qué no hará y con qué se hará, lo mismo que los riesgos preexistentes.
En la parte final de la Concepción, aceleramos el proceso y disponemos las estrategias y las herramientas para la próxima fase: Elaboración. Nuestro trabajo tendrá grandes repercusiones sobre el resto del proyecto y de las personas involucradas en el. Entrarán el Arquitecto y el Diseñador, lo mismo que el Programador y el Probador, se crearán las clases y los componentes, se integrarán las partes y finalmente se ensamblará un producto que se pondrá a disposición del usuario que lo concibió.
Pero todo comienza aquí, en la Concepción; en consecuencia, el futuro del proyecto está fijado por la mayor disposición, el mayor y mejor esfuerzo y de la calidad del tiempo y del proceso que usemos en esta fase los Analistas del Software.
De Artefactos y Otros Menesteres Durante la ConcepciónEl resultado del proceso siempre debe documentarse para que quede una prueba fehaciente y toda la fundamentación de lo que será. RUP proporciona algunas herramientas a manera de plantillas, agrupadas en Dominios de Productos de Trabajo, relacionadas unos con otros sobre la base de recursos, temporalidad o interrelación entre ellos, para que podamos concluir nuestro trabajo. En el caso del subdominio de los Requisitos, encontramos:
La Visión y el Alcance. Este artefacto define la vista de los interesados sobre el producto a ser desarrollado, especificado en términos de las necesidades clave de esos interesados y de las características del software. Contiene un perfil o resumen de los requisitos centrales visionados (el corazón o núcleo del sistema) y de esta forma suministra la base contractual para los requisitos técnicos más detallados. En breve, el documento de Visión captura la esencia de la solución imaginada en forma de requisitos de alto nivel y restricciones de diseño que dan al lector una visión del sistema a ser desarrollado desde una perspectiva de requisitos comportacionales. Además, facilita una entrada al proceso de aprobación del proyecto y está, de esta forma, íntimamente relacionado con el Caso del Negocio (del que hablaré en otra oportunidad). El documento de Visión comunica también el “por qué y qué” fundamental del proyecto y es un indicador contra el cual todas las decisiones futuras deberían ser validadas. Otro nombre usado para este artefacto es el
Documento de Requisitos del Producto.
En general, este documento está escrito usando un léxico del dominio de los usuarios líderes y finales del sistema y son ellos quienes en última instancia establecen la completitud y la exactitud del artefacto.
El responsable directo, el hacedor de este documento es el Analista del Software.
La Especificación de Requisitos del Software. Por su parte, este artefacto captura los requisitos del software para todo el sistema o para una porción de el. Se enfoca en la recolección y organización de todos los requisitos alrededor del proyecto, tanto funcionales (lo que hace el sistema) como los no funcionales (aquellos aspectos de usabilidad, confiabilidad, desempeño, escalabilidad y restricciones de diseño, implementación y despliegue del software que afectan el producto). Cuando no se usa la técnica de los casos de uso, es en este documento donde consignamos el semblante funcional del sistema tal cual será implementado posteriormente. Si usamos casos de uso, en cambio, dejamos aquí el detalle de aquellos requisitos transversales y reusables del software, aquellos que se usan en distintos ámbitos del producto. En cualquier caso, los requisitos no funcionales encuentran aquí su repositorio absoluto, aunque en ocasiones estos requisitos son expuestos en un Documento de Especificaciones Suplementarias, que también puede incluir requisitos legales y regulatorios, lo mismo que el uso estándares de distinto tipo.
Como antes, el garante inmediato, el productor de este documento es el Analista del Software.
Sin embargo, muchas personas en el equipo del proyecto usan la Especificación de Requisitos del Software:
- Los diseñadores lo usan como referencia al definir responsabilidades, operaciones y atributos en las clases y cuando ajustan las clases al entorno de implementación.
- Los programadores referencian el documento buscando insumos para la implementación de clases.
- El gerente del proyecto lo usa para planear las iteraciones.
- Los probadores lo usan para definir las pruebas que serán requeridas.
La Especificación del Caso de Uso. No me extenderé en este apartado. Las cinco Lecturas Fundamentales iníciales describen ampliamente esto del Caso de Uso. Habrá más, pronto.
Algunos otros artefactos importantes durante la Concepción y el resto del proyecto, que bien podrían hacer parte de uno de los anteriores o simplemente poseer su propio repositorio, son:
El Glosario, que define términos importantes usados en el proyecto; constituye el carácter léxico-gráfico del proyecto y del producto. Los Atributos de los Requisitos, que describe los atributos de y dependencias (trazabilidad) entre los requisitos, importantes a la hora de administrar los cambios desde la perspectiva de los requisitos. El Plan de Manejo de Requisitos, que describe los artefactos de requisitos usados en el proyecto, los tipos de requisitos y sus atributos respectivos, especificando la información a recolectar y los mecanismos de control a ser usados para medir, reportar y controlar los cambios a los requisitos del producto.
Por último, pero no menos importante, está el Modelo de Casos de Uso, que sirve como un medio de comunicación y como un contrato entre el usuario líder, los usuarios finales y los desarrolladores (y estoy usando el término desarrolladores en un sentido amplio con el que denoto realmente a todos los miembros del equipo del proyecto) sobre la funcionalidad del sistema. El modelo de casos de uso permite que los usuarios validen que el sistema será lo que ellos esperan y que los desarrolladores construyan lo que se espera del producto. Este modelo está compuesto de casos de uso y de actores y de las relaciones entre ellos. Por supuesto, va más allá de un simple diagrama.
Y ya desde la
Lectura Fundamental 7 he mencionado artefactos como la Lista de Riesgos, el Plan de Desarrollo de Software (que incluye como mínimo el Plan Maestro de Iteraciones y la Agenda del proyecto) y el Plan de Pruebas cuya responsabilidad recae más sobre el Gerente del Proyecto u otros integrantes del equipo de desarrollo.
Quiero aclarar que el hecho de que no haga el mismo énfasis en estos últimos artefactos que en los primeros no quiere decir que estos sean menos relevantes que aquellos. Es una mera cuestión de espacio y de tiempo. Quizás en otra ocasión, en otra Lectura, aborde con más detalle algunos de estos documentos. Lo que sí es importante tener en cuenta es que la elaboración de uno o más de estos documentos (de todos los que he expuesto) depende del tipo de proyecto: si el proyecto es grande, requiere de más rigor documental y de más contratos y puesto que más personas estarán interesadas, la necesidad de usar cada artefacto por separado es mayor. En proyectos pequeños, de menos carácter ceremonial, varios de estos artefactos se pueden combinar en uno solo pero a la postre el resultado será el mismo.
Sobre la Arquitectura PreliminarNinguna disertación sobre el Inicio de un proyecto estará completa sin hablar de la Arquitectura Candidata. Por allá en la segunda mitad de la fase, el Arquitecto del Software recibe del Analista los insumos necesarios para abordar la Solución. Esta se expresa en términos de vistas o perspectivas, empezando por la vista funcional, arquitectura funcional o vista de casos de uso; ésta es un compendio de los casos de uso que precisamente “definen” la arquitectura, o son los más complejos arquitectónicamente (y la
complejidad es un asunto espinoso sobre el que únicamente el arquitecto tiene potestad). El arquitecto incluso puede desviar la atención del analista hacia un grupo distinto de casos de uso y solicitar el detalle de estos para validar efectivamente dicha complejidad. También puede requerir el diseño e implementación de una o más pruebas de concepto arquitectónicas con el ánimo de comprobar la factibilidad técnico-científica de implementar una parte del software que se prevé problemática o en la que no se tiene experiencia anterior.
En un mundo ideal, es deseable que el arquitecto proponga más de una arquitectura candidata y que sea un comité (de arquitectos o de varios miembros del equipo desarrollador) el que decida más adelante (durante la Elaboración) cuál es la mejor alternativa para las necesidades actuales.
En el FinalCuando un proyecto de Tecnología Informática comienza
no damos cuenta del abismo colosal de realidad inexplorada que se expande ante nuestras mentes. La búsqueda inicia aquí y es nuestro compromiso revelar esas ambiciones y estrechar las contingencias de los usuarios, concebir la solución, pasar de observadores pasivos de una organización a ser coreógrafos activos de su proceso o, al menos, de parte de el. A medida que nuestro conocimiento de ese proceso aumenta, se abre la posibilidad de construir mejores artilugios de cómputo para los usuarios. Y salvo que se produzca una catástrofe natural (que en este contexto quiere decir que se
desborden los sueños de los usuarios, o que dejemos que esa visión rebase la capacidad técnica y presupuestal del proyecto), o un colapso ocasionado por factores que van más allá de lo técnico y caen en lo legal o regulatorio, estamos en camino de alcanzar, en un marco de tiempo más o menos previsible (¡estimable!), la implantación de un producto de software de alta calidad que satisfaga o resuelva las necesidades elementales de nuestros usuarios.
Y lo que hará que esto sea posible es la configuración y el seguimiento de un proceso de Ingeniería maduro para las características específicas de ese proyecto en particular. En última instancia, haremos que sea permisible plasmar nuestra meta si disponemos de las herramientas y técnicas más o menos como lo he expuesto en estas Lecturas Fundamentales. El aprovechamiento de ellas (de las herramientas y de las Lecturas) es el primer paso para convertirnos en mejores profesionales de la Ingeniería del Software.
ReferenciasAlgunas de las características y conceptos expuestos aquí se basan en la documentación de
IBM Rational Unified Process.
Lectura Fundamental Siguiente: “Realización de Casos de Uso: De los Objetos y sus Interacciones” lucho.salazar@gmail.com
