Este es mi punto de vista sobre las Tecnologías de la Información, Software y Pensamiento Ágil. Especialmente en lo que respecta a procesos y métodos, modelos y sistemas, marcos de trabajo y prácticas ágiles, experiencia en la industria, transformación organizacional, cultura, generación de Valor, trabajo colaborativo, Inspección y adaptación y mejoramiento continuo. Propuestas y experimentos, mejores prácticas y calidad de los productos (de software) y servicios.
Buscar en Gazafatonario IT
miércoles, septiembre 05, 2012
Casos de Abuso, Parte 2: El caso de uso es la única documentación necesaria para construir el software
martes, septiembre 04, 2012
Casos de Abuso, Parte 1: El caso de uso se usa en todos los casos
viernes, julio 20, 2012
Ventajas y Desventajas del Uso de Prototipos
miércoles, julio 18, 2012
El uso de prototipos en el ciclo de vida de construcción del software
Los prototipos son muy útiles para refinar la especificación de requisitos funcionales del software, específicamente en todo lo que tiene que ver con la descripción de pantallas o formularios de entrada de datos, formulario de salida de datos (consultas), reportes, las opciones de navegación y, en general, toda la carta de navegación del usuario a través del software.
Existen prototipos rápidos y prototipos evolutivos. Los primeros son aquellos que se realizan en las primeras etapas del ciclo de vida y son usados para solucionar inquietudes iniciales relacionadas con la interfaz de usuario que no están claras o precisas en la documentación textual de los requisitos. Estos prototipos pueden ser elaborados en papel o en herramientas básicas como MS-Office (Word, Power Point, Excel, Visio).
Los prototipos evolutivos son artefactos más elaborados que se construyen durante la fase de diseño del software como complemento a la especificación de requisitos (y casos de uso) y que están muy cercanos al diseño final de la solución. Normalmente son hechos con las mismas herramientas con las que será construido el software o con alguna herramienta de automatización que permita generación de código fuente o algo parecido.
Hay distintos aspectos a tener en cuenta durante el uso de prototipos:
- Tipo de problema a resolver: si el problema es no-estructurado, novedoso, complejo o de manejo de información con un alto grado de personalización para un usuario o un grupo de usuario, entonces la técnica es muy útil.
- Conocimiento de los requisitos: si se desconocen los detalles de los requisitos del software, si existe poca información al respecto, los prototipos son útiles.
- Necesidad de revisar, evaluar y aprobar los requisitos: si los procedimientos o controles exigen que los requisitos del software sean revisados, evaluados y aprobados por usuarios y otro tipo de personas, los prototipos serán de gran ayuda a la hora de tomar decisiones.
- Este aspecto es crucial en muchas compañías ya que el alto grado de formalidad que exigimos para la especificación de requisitos, que tiene carácter contractual, exige que no solo los usuarios revisen y aprueben los requisitos y casos de uso, sino que estos deben ser revisados y valorados en distinto grado por personas de distintas áreas.
Otros aspectos a tener en cuenta en el uso de prototipos son: la cantidad y calidad de los riesgos del proyecto/requerimiento, no disponibilidad de los usuarios para revisiones y aprobaciones, uso de nuevas tecnologías o la falta de experiencia en el uso de esas tecnologías, entre otros.
- Permiten el desarrollo de un sistema a partir de requisitos poco claros o cambiantes. Esto ocurre con cierta frecuencia en muchos proyectos de software.
- Como información complementaria a los requisitos (y casos de uso) constituyen un gran apoyo a las estimaciones de esfuerzo de todas las áreas, incluyendo proveedores.
- Son más fáciles de abordar con los usuarios finales.
- Precisamente, el usuario participa más activamente en la construcción del producto de software (La Solución), ya que “lo puede ver” y, dependiendo del tipo de prototipo, “utilizar” desde el primer momento.
- Se reduce el riesgo o la incertidumbre sobre la implementación del software.
- En general, el uso de prototipos redunda en una mayor satisfacción del usuario con el producto final, ya que él o ella han participado activamente de su diseño.
- Proporciona al usuario un mayor conocimiento del sistema con una curva menor de aprendizaje.
- Permite a todos los involucrados (usuarios y equipo de trabajo, incluyendo proveedores) entender bien y mejor el problema antes de la implementación final.
- En general, encontramos que el usuario quiere empezar a trabajar desde el primer momento con el prototipo para solucionar su problema particular, cuando el prototipo es solo un modelo de lo que será el producto.
- Los prototipos generan o pueden generar otro tipo de problemas si su presentación y discusión con los usuarios no es controlada: puesto que son modelos inconclusos, los usuarios suelen enfocarse en aspectos “superficiales” del prototipo que los pueden dejar inconformes luego de verlos por primera vez. También es posible que se pierda mucho tiempo, innecesariamente, tratando de hacer entender al usuario la finalidad real de los prototipos.
- Requiere participación activa del usuario, al menos, para evaluar el prototipo. Y mucho más involucramiento si queremos que participe en su creación.
- Una desventaja importante a tener en cuenta es la falta de experiencia que tienen muchos Analistas Funcionales en programación y en actividades de diseño de interfaces de usuario.
Revisar/Aprobar Prototipos en Vez de Requisitos/Casos de Uso
Tanto los primeros como estos últimos prototipos deben incluir el diseño de formularios de captura o ingreso de datos, formularios de consulta, reportes, opciones de navegación (menú), mensajes de usuario, ayudas en línea, entre otros aspectos. La única diferencia entre unos y otros prototipos debería ser la herramienta usada en la construcción de los prototipos y la precisión (menor en Visión, mayor en Planeación) de tales prototipos.
La otra parte de la tarea, aunque igualmente importante, es que entonces será el Analista Funcional el encargado de verificar que la descripción de los prototipos corresponda a la especificación de los requisitos en su totalidad. Las cosas así, es evidente que se incrementa el esfuerzo de los Analistas, sobre todo en la etapa de Visión y Alcance del proyecto. No obstante, el proceso de construcción de software puede mejorarse con la inclusión de guías para la elaboración de prototipos en las distintas plataformas.
viernes, abril 13, 2012
Sobre el Papel del Analista Funcional y la Reunión de Presentación de Casos de Uso
lunes, abril 09, 2012
Casos de Uso 2.0 y Métodos Ágiles
El concepto de “incrementos” y de “historias de usuario”, generalizado en toda la práctica, es inherente a los métodos ágiles como Scrum. De hecho Casos de Uso 2.0 hace referencia a técnicas como el de “Backlog del producto” también usada en los Sprints o iteraciones de Scrum. el backlog (Product Backlog en Scrum) se crea con casos de uso, historias de usuario y porciones de casos de uso, o una combinación de todas estas.
Pero también es importante aclarar que esta técnica no es una franquicia solo para estrategias ágiles. También puede ser usada con otros métodos o procesos como RUP o MSF. La práctica “no es solo aplicable a pequeños equipos ágiles ubicados en una misma oficina, sino que también es para grandes equipos distribuidos que desarrollan de multi-sistemas complejos.”
Para precisar mi punto quiero referirme al “principio 5: Entregar el sistema en incrementos”, del que habla la guía en el primer capítulo.
En este apartado, los metodólogos enfatizan que “la mayoría de los sistemas de software evolucionan a través de muchas generaciones. Estos no son producidos de una sola vez, sino que son construidos como una serie de versiones, cada una de las cuales es implementada sobre la anterior. Aun las versiones mismas no son producidas de un solo tirón, sino que evolucionan a través de una serie de incrementos. Cada incremento arroja una versión demostrable o usable del sistema. Cada incremento se construye sobre el incremento previo para adicionar más funcionalidad o mejorar la calidad de lo que se ha hecho antes. Esta es la forma en que todos los sistemas deberían ser producidos.”
Más adelante remarcan: “Las porciones de casos de uso son una herramienta fabulosa para construir incrementos más pequeños en forma de una versión completa. Esta herramienta permite apuntar independientemente a porciones implementables y verificables de los incrementos, asegurando que cada incremento sea más grande que, y esté construido sobre, el anterior.” El concepto es a todas luces aplicable tanto a los métodos ágiles como a los no ágiles.
PD. Para quienes entran tarde a la sintonía, estoy extendiendo el tema de Casos de Uso 2.0, que inicié hace algunos días en otra entrada. Lo pueden encontrar en http://gazafatonarioit.blogspot.com/2012/04/casos-de-uso-20.html
lunes, junio 25, 2007
Lecturas Fundamentales 9
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í!”
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 Requisitos
Gran 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ón
El 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.
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 Preliminar
Ninguna 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 Final
Cuando 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.
Referencias
Algunas 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”
jueves, marzo 08, 2007
Lecturas Fundamentales 8
Lectura # 8
RUP: Fase de Concepción
“No hay nada más difícil de emprender, ni más dudoso de hacer triunfar, ni más peligroso de manejar, que el introducir nuevas leyes.”
Nicolás Maquiavelo (El Príncipe, 1513)
“In principio creavit…”
Génesis 1 {1:1}
Inicio o Concepción es la primera fase de RUP. El nombre no es importante, solo la meta es importante. Lo realmente trascendental es el objetivo que buscamos durante este período de gestación del proyecto: complementando lo que dije en la lectura fundamental # 7, la finalidad cardinal de esta fase es establecer la visión y el alcance del proyecto y del sistema, lo que se hará y no se hará dentro del proyecto y más aún, lo que hará y lo que no hará el producto a construir.
Para ello, RUP nos proporciona herramientas, a manera de mecanismos y maniobras, que bien usadas nos llevan de la mano hacia la consecución del objeto primario que nos ocupa: obtener un acuerdo con todos los involucrados sobre los objetivos del ciclo de vida para el proyecto.
Pero antes de abordar detalladamente la fase de Concepción como la explica RUP, quiero referirme al significado de las características del proceso durante la misma.
RUP es Dirigido por Casos de Uso y es Centrado en la Arquitectura
Esto significa que los casos de uso son la base para el resto del proceso de desarrollo. Durante la fase de Inicio, cuantificamos y cualificamos los requisitos funcionales del sistema en términos de casos de uso. Estos se convierten en el insumo para:
- Crear y validar el modelo de diseño de la solución
- Diseñar la arquitectura del sistema
- Definir los casos y procedimientos de prueba en el modelo de pruebas
- Planear las iteraciones
- Elaborar la documentación de usuario
- Hacer el despliegue del sistema
- Sincronizar el contenido de los diferentes modelos que forman el sistema
Los casos de uso también son usados para modelar el negocio, actividad que pocas veces es tenida en cuenta a la hora de entender el comportamiento sistemático de una organización.
Cualificar los casos de uso quiere decir en el contexto del proceso que el Arquitecto del software debe hacer una priorización de los mismos desde el punto de vista arquitectónico. Es decir, establecer cuales son los casos de uso que definen la arquitectura o que tienen un impacto mayor en la misma. Para ello, los Arquitectos ponemos de manifiesto nuestra experiencia en proyectos anteriores y similares, si es posible, para reconocer los casos de uso arquitecturales: El ciclo de vida del caso de uso, el número y la calidad de los elementos estructurales (tanto de arquitectura como de diseño como de implementación) que se requieren para implementar el comportamiento del caso de uso en el sistema, requisitos de desempeño, confiabilidad, soportabilidad, concurrencia y restriccio-nes de diseño, la complejidad algorítmica asociada al caso de uso, el número de escenarios del caso de uso, el ranking del caso de uso desde el punto de vista de su criticidad (esto es, si el caso de uso es requerido u obligatorio, o importante, o adicional –normalmente los casos de uso arquitectónicos se cuentan entre los dos primeros), el grado de novedad de la tecnología y las estrategias disponibles para implementar el caso de uso o, en otras palabras, la experiencia del equipo de desarrollo en el uso de tal o cual tecnología o conjunto de técnicas para resolver un problema dado, son todas variables relevantes a la hora de catalogar o evaluar los casos de uso desde una perspectiva de arquitectura.
La fase de inicio es exploratoria, los casos de uso, todavía en estado primitivo, corren por un río de aguas diáfanas que se precipitan desde la mente de los usuarios como huevos prehistóricos. Encontrarlos, darles un lugar en el sistema, clasificarlos, esbozarlos, modelarlos y finalmente presentarlos, es lo que hacemos como analistas durante este período del proyecto. Una vez aprobado el modelo, los casos de uso rigen los designios a veces insondables a veces meta-humanos de todo el proyecto. A los casos de uso no se les puede poner limitantes técnicas y el equipo de desarrollo debe mantenerlos como un libro abierto de referencia para decidir siempre el siguiente paso. Eso significa “dirigido por casos de uso.”
La arquitectura del software, por su parte, asoma tímida durante la concepción, a manera de arquitectura candidata o preliminar y debería contemplar más de una posible solución, un conjunto pequeño de alternativas de cómo se va a implementar el software y la estrategia que usaremos para abordar el tratamiento de los requisitos suplementarios o no funcionales: la vista de casos de uso o funcional, subconjunto propio del modelo de casos de uso, una vista lógica de alto nivel y quizás una perspectiva del despliegue de la aplicación, surgen de la mente creativa del arquitecto, cual visión futurista de lo que será, de cómo lucirán las entrañas del sistema una vez esté construido. Y sea cual fuere la decisión, la elección que tomemos en la siguiente fase del proyecto, la arquitectura es desde todo punto de vista restrictiva, circunscribe el diseño y, consecuentemente, la implementación y el despliegue de la solución software que se conciba. Pero a partir de ella se abordan y mitigan los riesgos técnicos del proyecto, durante las primeras iteraciones del mismo; también se construyen las bases o cimientos del sistema, unas en las que todos los requisitos conocidos y algunos de los no conocidos tengan cabida; por supuesto, la arquitectura es el eje medular alrededor del cual se construye la solución, se planea y se controla el proyecto y también, en torno al cual se asegura la calidad del producto. Eso significa “centrado en la arquitectura.”
Para el Gazafatonario IT
A manera de inventario, y puesto que esto no es más que un Gazafatonario, la palabra Conceptualización[1], aunque aparece en algún diccionario de la lengua española definida simplemente como: “f. Elaboración detallada y organizada de un concepto a partir de datos concretos o reales” no es aceptada por la Real Academia de la Lengua Española. Así que seguiremos usando Inicio o Concepción para referirnos a la primera fase del ciclo de vida de acuerdo a RUP.
Roles y Responsabilidades Durante Concepción
Un Ingeniero de Procesos, un Gerente de Proyectos, al menos un Analista de Requisitos, un Analista del Negocio y un Administrador de la Configuración y el Versionamiento son los responsables de iniciar el proyecto. Con ellos, los usuarios, clasificados en Usuarios Líderes, Usuarios Finales y otros Involucrados (stakeholders es el término que nos llega del inglés) son los encargados de dictar el problema (y el problema detrás del problema, la causa raíz), sus necesidades, y hasta sus ambiciones, sus sueños y sus esperanzas. Más adelante, un Especificador de Requisitos (realmente un escritor técnico de casos de uso que bien podría ser el mismo analista de requisitos –de hecho casi siempre lo es) y un Arquitecto del Software, se unen a los anteriores para establecer las características (de alto nivel) del software, los primeros requisitos funcionales (a manera de casos de uso) detallados, los requisitos no funcionales y la misma solución de software expresada en términos arquitectónicos y de diseño.
Vamos por partes.
El Ingeniero de Procesos
Sí, RUP es un proceso configurable y adaptable a cada proyecto. Es así como lo leen, a cada proyecto. La primera conclusión que viene a mi mente, aunque reiterativa, tiene que ver con la forma de abordar el proceso. Recordemos que el proceso expone prácticas que han funcionado alguna vez, pero que no deberíamos seguir al pie de la letra, cual ensayo de laboratorio.
Un proyecto tiene condiciones muy particulares: el tipo de organización, más exactamente, el contexto del negocio, el tamaño del esfuerzo de desarrollo del software, el grado de novedad, el tipo de aplicación, el proceso actual de desarrollo, los problemas actuales y sus causas primarias, los factores organizacionales, las actitudes y la complejidad técnica y de gestión son algunos discriminantes que el así llamado Ingeniero de Procesos debe tener en cuenta al momento de decidir el mejor de los caminos posibles del proceso para ese proyecto.
Previo a ello, debemos tener claridad sobre las influencias del proceso de desarrollo: factores del dominio, por ejemplo, entre los que se cuentan factores del dominio de la aplicación, del proceso de negocio a soportar, de la comunidad de usuarios y de las ofertas disponibles de los competidores; factores del ciclo de vida como el tiempo de salida al mercado, la vida esperada del software y las versiones futuras planeadas son igualmente importantes; factores técnicos, ni más faltaba, como los lenguajes de programación a usar, las herramientas de desarrollo, las bases de datos, los frameworks de componentes y los sistemas de software existentes, constituyen influjos de peso que actúan sobre el proceso de desarrollo, junto con otros factores organizacionales cuyo nombramiento, al menos, se escapa del alcance de esta lectura fundamental.
Sobre el tamaño del esfuerzo del proceso de desarrollo, tenemos en cuenta aspectos medibles como el número de líneas de código entregadas, el número de casos de uso, el número de personas por mes o por alguna otra unidad de tiempo, el número de clases y de componentes, el número de tablas y de procedimientos almacenados en la base de datos, entre otros, para cuantificar la influencia en el desarrollo: a mayor tamaño de proyecto, mayor tamaño de equipo de desarrollo, el contexto del negocio pierde importancia en favor de más formalidad y más visibilidad en los requisitos, en las interfaces y en los indicadores de progreso del proyecto. Adicionalmente, para equipos geográfi-camente dispersos, incluso transoceánicos, tenemos en cuenta aspectos cruciales de comunicación y el cambio del huso horario.
El grado de novedad es otra condición influyente que tengo en cuenta como ingeniero de procesos. Este grado de novedad es relativo al equipo de desarrollo y a la organización que lo envuelve: factores como la madurez de la organización y del proceso de desarrollo (medido vía CMMi o algún otro modelo similar), los activos del proceso, las habilidades actuales del personal, la composición y el entrenamiento del equipo y la adquisición de herramientas y otros recursos para el proyecto, son definitivos a la hora de configurar el proceso: si se trata de un sistema nuevo, establezco fases de concepción y de elaboración más largas y más iteraciones en esta última; también hago más énfasis en la captura y administración de requisitos, el modelo de casos de uso, la arquitectura y en la mitigación de riesgos. Entre tanto, para un sistema en evolución, enfatizo en la gestión de cambios y en la incorporación o no de código legado.
En breve, durante la concepción, el ingeniero de procesos además elabora el caso de desarrollo, prepara las plantillas y las guías para el proyecto y, con un especialista en herramientas, selecciona las herramientas más adecuadas para el proyecto. Son materias que tienen tanto extensión como profundidad y abordarlas bien podría ser objeto de futuras Lecturas Fundamentales.
Lo que sí tengo que decir antes de cerrar esta puerta es que el ingeniero de procesos es al proceso lo que el arquitecto es al sistema y recuerden: la calidad de un producto está determinada en gran medida por la calidad del proceso que se usa para desarrollarlo y mantenerlo[2].
El Analista de Procesos del Negocio
Hablo de procesos distintos. En el apartado anterior me refería al proceso de desarrollo de software, mientras que en este me refiero al conjunto de procesos mediante los cuales una compañía organiza su actividad para conseguir sus objetivos. Cada proceso del negocio se identifica por un repertorio de datos que son elaborados y operados mediante un conjunto de quehaceres, en los que ciertos agentes (trabajadores, proveedores, departamentos, entre otros) interactúan de acuerdo a un flujo de trabajo determinado. Además, estos procesos dependen de un conjunto de reglas de negocio que fijan las políticas y la arquitectura de la información de la empresa.
El analista de procesos del negocio o simplemente analista del negocio es el responsable de definir la arquitectura del negocio y los actores y casos de uso del negocio, lo mismo que la interacción entre ellos. El modelo producido por este analista delimita la organización desde el punto de vista del sistema a desarrollar.
Entender la organización es un aspecto clave en todo desarrollo de software: enterarse de los procesos de negocio, quienes intervienen en su ejecución, sus entradas y sus resultados, como se manejan las excepciones, como se mantiene la integridad de la información y la consistencia entre procesos; también, conocer hacía donde va la organización, las expectativas de los usuarios, la visión que ellos tienen sobre lo que será y no será el negocio en el futuro, al menos, durante el ciclo de vida esperado del sistema.
Ahora bien, idealmente, la construcción de sistemas de software es uno de esos buenos momentos para cambiar procesos de negocio, no porque el negocio tenga que adaptarse al nuevo sistema, sino porque el esfuerzo de revisión de tales procesos puede llegar a ser tan significativo, tan profundo, que se encuentren oportunidades de mejora. Esto, por supuesto, es completa responsabilidad de la organización para la cual se construye el sistema y el área de TI, como buena conocedora de estos procesos, debe apoyar el diseño y la implantación del nuevo modelo y de paso quedar con el nuevo conocimiento para futuros ejercicios de esta índole.
Por supuesto, este trabajo implica un tiempo y recursos adicionales considerables que casi nunca son estimados a la hora de emprender un proyecto de tecnología informática, de tal forma que la cautela y el tratamiento efectivo de las expectativas de nuestros clientes son recomendables.
El Gerente de Proyectos
Planea, maneja y asigna recursos, determina prioridades, coordina las interaccio-nes con los usuarios y mantiene el foco del equipo del proyecto. También establece un conjunto de prácticas para asegurar la integridad y la calidad de los entregables del proyecto. Es un orquestador, articula y coordina los movimientos que se den en el proyecto.
Es el gerente quien precisamente concibe el proyecto mediante la transformación de una idea inicial a un estado en el que, soportado en razones de peso, pueda tomar una decisión sobre continuarlo o abandonarlo. Para lo que nos ocupa la mayor parte del tiempo, este “abandonarlo” más bien se convierte en un “ajustar” algunas condiciones críticas del proyecto, como el tiempo, el talento humano necesario para llevarlo a cabo y, por consiguiente, el presupuesto y la estrategia para alcanzar el éxito.
Durante la concepción, el gerente del proyecto identifica y evalúa los riesgos, elabora un caso de negocio e inicia el proyecto. Más adelante, en la misma concepción, planea el proyecto, teniendo en cuenta las métricas, los riesgos, los criterios de aceptación del producto, las tácticas para la resolución de problemas, el proceso de aseguramiento de la calidad, la organización del equipo de desarrollo, los modos de monitoreo y control del proyecto y las fases e iteraciones del mismo. Para ello se alimenta de toda la materia prima que los demás responsables de la concepción le transmitan. Es el gerente quien también decide si se han alcanzado los objetivos de la fase de concepción y si es viable empezar la fase de Elaboración.
Tanto en Concepción, como en el resto del proyecto, el gerente tiene una perspectiva de mediana profundidad para poder izar los hilos del proyecto con mayor propiedad y asegurar, casi como un dogma, que se pueda hacer una entrega, que se pueda avanzar o, si por el contrario, que se deba replantear la técnica y reorientar el enfoque (corregir el rumbo). Y el final de la fase de concepción es buen momento para asegurarnos de la idoneidad (en cuanto talento, competitividad, aptitud) del equipo de desarrollo, de indagar si los miembros del equipo tienen las habilidades y destrezas suficientes, comparten todos la misma visión de lo que vendrá, soportarán la presión, están dispuestos a dar ese “delta de t” (y otros deltas) necesarios para triunfar en todo proyecto. Desde este punto de vista, el destino del proyecto, incierto hasta este punto, depende enteramente de su gerente.
Bueno, esto no lo dice ningún proceso, no está escrito en ningún lado, simplemente es y con eso basta.
Continuará…
Hace poco uno de mis revisores de cabecera me dijo que estas lecturas fundamentales estaban quedando muy largas. Yo les reenvío la inquietud, ¿ustedes qué piensan? En cualquier caso, les he dado suficiente tiempo, creo, para que hagan la mejor de las lecturas. Estoy atento, los escucho.
De todas formas, es evidente que esta lectura amerita otra parte, donde concluiremos con los aspectos más importantes de la fase de concepción. Hasta la próxima entonces.
Referencias
Algunas de las características y conceptos expuestos aquí se basan en la documentación de IBM Rational Unified Process.
1. Diccionario de la lengua española © 2005 Espasa-Calpe S.A., Madrid:
Conceptualización
f. Elaboración detallada y organizada de un concepto a partir de datos concretos o reales.
2. Basado en principios de Administración Total de la Calidad enseñados por Shewhart, Juran, Deming y Humphrey.
Lectura Fundamental Siguiente: “RUP: Fase de Concepción. Parte 2.”