Buscar en Gazafatonario IT

Mostrando las entradas con la etiqueta Ingeniero de Procesos. Mostrar todas las entradas
Mostrando las entradas con la etiqueta Ingeniero de Procesos. Mostrar todas las entradas

lunes, junio 02, 2014

Libro: Asuntos de la Ingeniería del Software- volumen II

Portada del libro
Portada del libro
Este no es el primer libro sobre temas de la Ingeniería de Software y está lejos de ser el último; acaso sea el primero en español escrito sobre las bases de nuestra propia práctica de campo, en nuestra propia economía, con nuestra propia idiosincrasia, aunque con el suficiente equipaje teórico proveniente de la academia y de los expertos en los temas citados.
Escribí el libro originalmente como una serie de artículos en mi Gazafatonario IT y cada artículo siempre tuvo su fuente precisamente en tres aspectos primordiales: la industria del software (y por Industria quiero decir Intergrupo), la academia (léase la Universidad) y los especialistas en distintas áreas de la ingeniería de software.
El libro cubre algunos de los temas fundamentales que sirven de base al trabajo diario de los profesionales del software y que son de vital importancia para los desarrolladores actuales: el lenguaje de modelado unificado o UML, los procesos de software, la orientación a objetos y la ingeniería de requisitos con casos de uso, principalmente.
Los conceptos de ingeniería provienen necesariamente de la teoría formal de los lenguajes de modelado de sistemas, las técnicas orientadas a objetos de modelado de software, los métodos de construcción de software y la identificación, especificación y administración de requisitos de software con casos de uso, entre algunos otros. Desarrollé esos conceptos a través de cada capítulo en un estilo riguroso pero informal, más bien práctico, siempre pensando en poner de manifiesto lo que me ha funcionado a mí y a mis colegas, principalmente de Intergrupo, pero también de otras compañías del medio.
Parte 1 – Algunos Aspectos Esenciales de la Ingeniería de Software
El libro está dividido en dos secciones mayores. La primera parte del libro la dedico a explicar algunos de los asuntos que acusan recibo en la comunidad de ingenieros de software: UML, la notación estándar para modelar sistemas de software y otros sistemas que no son software; En lo que se constituye como los prolegómenos del libro, de manera sucinta describo la gran mayoría de los diagramas del lenguaje, con ejemplos breves pero suficientemente explicativos y desmitifico algunas de las creencias sobre la herramienta.
En el capítulo 2, hago una presentación general de los procesos de software y de cómo estos son usados por los practicantes de la industria, es decir, nosotros. Aquí empiezo a develar las prácticas más recurrentes para adoptar y adaptar procesos de software en una organización, tal y como lo hicimos en Intergrupo en una serie de incrementos que llevaron a convertirnos en una compañía CMMI nivel 5.
En los capítulos 3, 4 y 5 del libro, hago una vasta exposición del Proceso Unificado de Software, desde su marco general en el capítulo 3, hasta los detalles de la fase de Inicio o Concepción en los capítulos 4 y 5. En el primero de los apartados presento los conceptos inherentes al proceso y sus características: las fases y las disciplinas, las iteraciones, los roles y responsabilidades, las actividades y los artefactos. En los dos capítulos restantes, ya con miras a la segunda parte del libro, hablo profusamente de la etapa de inicio del proceso, sus principales hitos y el resultado esperado. Es aquí donde comienzo a hablar de la disciplina de ingeniería de requisitos y de casos de uso, asuntos que ocupan toda la segunda sección del libro.
Luego, en el capítulo 6, concluyo este primer segmento del libro con un tema que verdaderamente me apasiona, la orientación a objetos. Tardé muchos años en encontrar el enfoque justo para esta pieza, teórico-práctico, pero actualizado a las necesidades incesantes de los desarrolladores profesionales de este siglo 21. El capítulo contiene una serie extensa de conceptos aplicables al análisis, diseño y desarrollo de sistemas de software, incluso me atrevo a hacer una analogía en lo que he dado en llamar la Biología Informática, para que todos entendamos mejor y de una vez por todas y para siempre lo que es una clase (objetualmente hablando) y su enorme utilidad durante el ciclo de vida de construcción de software. Sobre objetos, siempre recuerdo lo que decía Edward Yourdon sobre ello: “las metodologías de la ingeniería de software orientada a objetos son la cosa más grande desde el pan tajado. En términos relacionados con computación, las técnicas orientadas a objetos son el desarrollo más importante desde la invención de las técnicas estructuradas durante las décadas de 1970 y 1980.”[1] Hoy lo siguen siendo.
Parte 2 – Ingeniería de Requisitos con Casos de Uso: Volumen 1
La segunda parte está dedicada completamente al asunto de los casos de uso como mecanismo de primera categoría para identificar, capturar, organizar, documentar y gestionar requisitos de sistemas de software. En el capítulo 7 hago una presentación concisa del tema, defino qué es un caso de uso y además establezco las diferencias sutiles que existen con los escenarios de uso de un sistema; también explico de qué se tratan los así llamados casos de uso esenciales como noción capital en la especificación de requisitos y también los distingo de los casos de uso descompuestos funcionalmente. El capítulo finaliza con el ejemplo de caso de uso más simple de todo, el caso de uso “¡Hola, Mundo!”.
En el capítulo 8 abordo el tema de los casos de uso del negocio y sus actores del negocio relacionados. También hablo de la fuente de los casos de uso, de donde provienen y hacia donde van a lo largo del ciclo de vida del software, para terminar con un ejemplo del cual luego hago un análisis exhaustivo.
En el capítulo 9 hago una descomposición de la estructura de un caso de uso y exhibo cada una de sus partes principales: la descripción breve, las precondiciones y poscondiciones del caso de uso, la secuencia básica y las alternativas y los requisitos especiales. Ya en los capítulos previos había tratado el tema del nombre y el actor del caso de uso.
Más adelante, en el capítulo 10, bajo el manto de un ejemplo representativo, enuncio mi Ley de la Terminación de un Caso de Uso, que me sirve para explicar uno por uno los puntos de una lista de verificación para saber si un caso de uso cuenta con los atributos mínimos requeridos para ser considerado un buen caso de uso. Las listas de verificación deben verse como instrumentos o herramientas de apoyo en el proceso de administración de la calidad de los productos que construimos, nunca como un documento que se debe “diligenciar”. También sirven para disminuir el nivel de subjetividad con que se revisa un producto de software o parte de este, o un artefacto relacionado con el software. Al menos, este es el mensaje que llevo implícito en esta sección del libro.
El capítulo 10 sirve como entrada al tema que abordo en el capítulo 11, este del análisis y diseño de los casos de uso, mejor conocido en el ámbito de los diseñadores de software como realización de casos de uso. Aquí evidencio la necesidad de contar con el conocimiento de conceptos tan importantes como las técnicas orientadas a objeto, que trato al final de la primera parte del libro, y donde hago un uso extenso del lenguaje de modelado unificado que trato en detalle en los prolegómenos del libro (capítulo 1). En este capítulo empiezo con una disertación sobre los problemas de comunicación existentes entre los miembros de un equipo de desarrollo de software y que son inherentes a la naturaleza humana. A continuación, con un ejemplo característico y práctico, hago una exposición detallada de los diagramas de interacción de UML, en general, y de los diagramas de secuencia, en particular, que sirven como mecanismos fundamentales para llevar a cabo estas realizaciones de casos de uso.
En el capítulo 12 cierro uno de los ciclos del libro sobre modelado de casos de uso y presento el no menos espinoso asunto de las relaciones entre actores y casos de uso y entre casos de uso. La generalización entre actores, una práctica poco usada entre los analistas de software, o muchas veces mal usadas, inicia este apartado. Luego continúo con la típica relación de inclusión de casos de uso, donde hablo de factorización de requisitos y de reusabilidad de requisitos; más adelante hago una disertación sobre la relación de extensión y sus diferencias principales con la anterior. Al final también hablo de la generalización entre casos de uso, aunque no la recomiendo mucho. Este capítulo aporta el enfoque sistémico de toda la segunda parte del libro y hace énfasis en cuando debemos usar una u otra relación, o todas ellas.
El capítulo 13 entra en el terreno de las buenas prácticas mostrando los errores más comunes que se cometen a la hora de usar casos de uso, algo que he dado en llamar “los casos de abuso”, es un juego de palabras pero ilustra a la perfección el punto al que quiero llegar. Enumero y explico una serie de dieciséis casos frecuentes de mal uso de los casos de uso, desde la mala práctica de usarlos en todo momento y en cualquier contexto, pasando por los errores habituales de documentar detalles técnicos o de la interfaz de usuario en el caso de uso, hasta la costumbre perfeccionista de solo presentar el caso de uso cuando está “felizmente” terminado, solo cuando contiene todos los detalles que se han acordado con el usuario. ¿Quién diría que lo perfecto siempre es mejor que lo bueno? Pues bien, aquí sucede exactamente lo contrario: lo acabado, lo ideal, lo absoluto es enemigo acérrimo de lo bueno, de lo que proporciona valor. Es una de las conclusiones que obtendremos al final del capítulo. Incluso muchos de nosotros hemos llegado a pensar que el analista de requisitos y otros miembros del equipo de desarrollo son síquicos y que pueden leer nuestros pensamientos y saber lo que queremos sin habérselos dicho. De todo esto se trata este estudio al que clasifico de patológico y de forense, fueron situaciones que discutí mucho con algunos de mis colegas en Intergrupo.
El último capítulo del libro fue otro de los que siempre quise escribir en mi Gazafatonario: se trata de diez más uno consejos útiles y simples para escribir efectivamente casos de uso efectivos. La aliteración en el título me sirve para abordar dos asuntos importantes: el problema de la comunicación efectiva entre las personas y el problema de la calidad y utilidad de los artefactos de software, en este caso, de los casos de uso. Me parecía razonable, después de la descripción sintomática que hago en el capítulo anterior, sobre los errores más pronunciados que cometemos a la hora de modelar sistemas de software con casos de uso, traerles algunas propuestas para remediar nuestro trabajo, hacerlo más productivo y de mejor calidad. De eso se tratan estos consejos.
Dónde conseguir el libro
El libro lo pueden conseguir en:



[1] Yourdon, Edward. Object-Oriented System Design, an integrated approach. Prentice Hall. 1994.

viernes, noviembre 02, 2012

Ecos del Simposio Latinoamericano de Ingeniería de Software



Aunque ya pasó algún tiempo desde que escribí este artículo, el tema de Semat está cobrando vida y afectará el futuro de la Ingeniería de Software como la conocemos hoy. Por consiguiente, impactará en la manera cómo hacemos Ingeniería de Requisitos, en particular, y el universo de los métodos de software en general.

Este es un brevísimo resumen de lo que pasó durante los dos días del simposio: los temas expuestos, la presencia del experto internacional Ivar Jacobson, la creación del capítulo para Latinoamérica de la iniciativa SEMAT, una revolucionaria propuesta que el mismo Jacobson apoya junto a otros prominentes miembros de la industria del software y que busca refundar la ingeniería de software con una teoría sólida, principios probados y mejores prácticas refinadas.

El artículo completo lo pueden descargar en:



https://docs.google.com/file/d/0B5SNac-eZKMMdGY2V2xZVnFtQXc/edit?usp=sharing

El sitio de Semat Central es: http://www.semat.org.

domingo, julio 22, 2012

¿Es maduro tu proceso de Ingeniería de Requisitos?


Hace algún tiempo, cuando me involucré en las iniciativas de mejoramiento de procesos de Intergrupo, las que finalmente condujeron a alcanzar el nivel CMMI 5, entendí que la cultura orgánica tiene su propio proceso natural de supervivencia y éxito y que siempre debía medir cuidadosamente lo que es adicionado y es removido de mi entorno. Por supuesto, siempre he tenido claro cuando ser “interno” o “externo” al proceso.
Fue una época en que puse en práctica algunos de los principios memorables de Deming en Administración: “La mejora de procesos debe ser realizada para mejorar el negocio – No como un objetivo en sí misma”. Y empezaba a pregonar que un proceso debe usar prácticas probadas en la industria, no solo la última moda, lo que escuchamos en la conferencia del día anterior o lo que leímos en el último artículo de la IEEE.
Y lo más importante, difundía a mil voces que debemos ser prácticos, que debemos entregar la información que se necesita, cuando se requiere y en un formato que se pueda usar. Con todo esto en mente, usamos un modelo de madurez típico como CMMI para mejorar nuestros procesos. Y uno de los primeros procesos que optimizamos fue este de la Ingeniería de Requisitos.
Pero ¿cómo saber si tu proceso es lo suficientemente maduro? ¿En la práctica qué significa identificar, documentar y administrar requisitos de software de una manera formal y razonable? Según el SEI (siglas en inglés del Instituto de Ingeniería de Software), autor del modelo CMMI, “los requisitos son manejados y las inconsistencias con los planes de proyecto y los productos de trabajo son identificadas”.
Lo que no dice el SEI en su área de proceso de RM (siglas en inglés de Administración de Requisitos), es que esas inconsistencias deben detectarse a tiempo porque cualquier cambio que involucre requisitos es altamente costoso para el proyecto y para los participantes en el mismo.
Para manejar los requisitos, el SEI recomienda:
·         Entender los requisitos
·         Acordar los requisitos con todos los involucrados
·         Administrar los cambios a los requisitos
·         Mantener una rastreabilidad bidireccional de los requisitos
·         Identificar las inconsistencias entre el trabajo del proyecto y los requisitos
Parece sencillo pero quienes hemos trasegado por los vericuetos de la Ingeniería de Requisitos con casos de uso sabemos que es más fácil decirlo que hacerlo y, sobre todo, hacerlo bien. Por ejemplo, sin duda es más simple entender y acordar requisitos entre las personas que están más involucradas en el proyecto, como los Analistas y los usuarios que quienes empiezan a llegar a medida que avanza el ciclo de vida, como los programadores o los certificadores.
Manejar los cambios, naturales por demás en un proyecto típico de software, es muchas veces otro dolor de cabeza para los participantes. Hay quienes creen que una solicitud de cambio es algo de menor valía, cuando la experiencia nos ha enseñado que sea cual fuere el momento y la fuente de la solicitud, siempre hay un impacto significativo y hay costos ocultos que solo los experimentados son capaces de descubrir a tiempo.
Por su parte, mantener una trazabilidad adecuada de los requisitos en ambas direcciones, lo que significa tener un mapa desde las necesidades del usuario y características del software, hasta el código ejecutable, pasando por los casos de prueba y otros artefactos importantes, es algo que solo se puede lograr adecuadamente con el uso de herramientas especializadas. En proyectos pequeños es posible que un Excel sirva, pero en algo más elaborado necesitamos de los instrumentos apropiados.
En cualquier caso, estas prácticas recomendadas (y esta es la palabra clave: “recomendadas”), son apenas un primer escaño para alcanzar la tan ansiada madurez en nuestros procesos de Ingeniería de Requisitos. Volveremos sobre ello más adelante.

jueves, marzo 08, 2007

Lecturas Fundamentales 8

Lectura Fundamental Anterior: “RUP o Todo lo que quisiste saber alguna vez de RUP y no te atreviste a preguntar…”

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.”

lucho.salazar@gmail.com