Published 14 years ago
(updated 12 years ago)
Una de las preguntas más importantes en el análisis y diseño de sistemas es: ¿Cuáles diagramas debemos hacer, y qué tanto tiempo debemos invertir en la diagramación? Un punto de vista rigorista y dogmático sobre el análisis y diseño de sistemas nos podría inducir a la ciega creencia de que invariablemente hay que modelar todo, extensamente y a profundidad, porque así lo marcan los cánones. De ahí que proyectos realizados de acuerdo a lo que se piensa que son las “mejores prácticas” caigan en el síndrome de la parálisis por análisis: los equipos de análisis y diseño producen un diagrama tras otro, y se la pasan perfeccionando sus modelos de manera obsesiva, al grado en que no llegan a producir los sistemas para los cuales fueron contratados.El anecdotario de la ingeniería de software tiene, en abundancia, no sólo historias de proyectos fracasados debido a la carencia de análisis y diseño adecuados, sino también de instancias de lo que
podríamos llamar el lado obscuro de las así conocidas “metodologías”: para cumplir con todas y cada una de las exigencias del proceso, tal o cual proyecto se quedaron estancados en la producción
de modelos de papel, en lugar de avanzar hacia el desarrollo de un sistema que cubriera los requisitos de los clientes y los usuarios.
El Proceso Unificado y UML cuentan con una buena variedad de disciplinas y artefactos, y nos podríamos pasar la vida tratando de plasmar en todo tipo de diagramas el análisis y el diseño de una solución. ¿Cómo aprovecharlos de manera sensata, de tal suerte que realmente ayuden a nuestros proyectos, sin caer en costos o en tiempos excesivos? La respuesta es relativamente simple: sólo debemos producir aquellos modelos que añadan valor suficiente a cada proyecto particular; sin embargo, para determinar qué es lo que consideramos “valor suficiente”, debemos considerar varios parámetros.
¿Para qué estamos modelando?
Tanto la extensión como la profundidad del modelado pueden variar conforme a las razones y exigencias por las que estamos modelando. Los proyectos de software pueden ser muy diferentes
tanto en magnitud como en distintos aspectos de su ambiente: hay equipos y analistas muy fogueados en el modelado, y también hay multitud de instituciones y empresas que apenas comienzan a utilizar procesos formales de desarrollo. Existen, asimismo, equipos de trabajo relativamente pequeños cuyos elementos participan durante todo el ciclo de vida de sus proyectos, y por otro lado existen organizaciones especializadas en análisis y diseño, que entregan sus modelos a terceros que se encargarán del desarrollo.
Supongamos que voy a realizar un desarrollo relativamente sencillo, y que yo mismo lo voy a programar. Mi enfoque, en este caso, puede consistir en realizar diagramas básicos de los casos de uso, con la intención de entender qué es lo que voy a resolver, y para generar documentación suficiente para acordar los alcances del desarrollo con mi cliente. En este caso, me conviene bosquejar las secuencias básicas de estos casos de uso, y por lo menos detectar las secuencias alternas. Si tengo experiencia
con la herramienta de modelado, me conviene hacer un modelo conceptual, mismo que es indispensable para realizar los diagramas de secuencia más esenciales, y que va a devenir en el modelo de clases y el modelo de datos. Este modelo de diseño me va a resultar sumamente útil en entender cómo voy a resolver el desarrollo, y me va a ahorrar mucho tiempo de mi proyecto, dado que es más fácil corregir un diagrama que realizar correcciones extensivas al código. Pudiera apoyar mis
decisiones de diseño con artefactos tales como diagramas de estado, pero usaría éstos sólo en los casos en que resultaran muy necesarios.
Ahora, imaginemos el caso de que no tengo experiencia en realizar modelos conceptuales, y mucho menos en diagramar secuencias, clases y modelos de datos. Más aún, supongamos que no tengo
tiempo de experimentar con modelos conceptuales o diagramas de secuencia, pero tengo una idea muy clara de cómo convertir los casos de uso a pantallas, diálogos y código. Al igual que en el caso anterior,
sería altamente recomendable crear el modelo de casos de uso para entender el problema, y también para poder acordar los alcances con el cliente y los usuarios. Muy probablemente, en toda esta variedad de casos, me apoyaría en bosquejos de pantallas y diálogos, o en prototipos con funcionalidad
limitada, para lograr una mejor comprensión de lo que el usuario y el cliente desean.
El caso extremo, en contraste con los anteriores, sería el de una organización especializada
en análisis y diseño, que genera modelos para que otra organización especializada realice la programación. En este caso, las secuencias básicas y alternas de los casos de uso resultan indispensables, así como la elaboración de diagramas de secuencia detallados que apoyen claramente los modelos de clases y de datos. Los modelos, en ese caso, no servirían sólo para entender el qué y el cómo, sino que representan las especificaciones para los programadores.
Tanto la extensión como la profundidad del modelado deben, entonces, ser en primer lugar
consecuencia de la pregunta: ¿para qué estamos modelando?
¿Qué tan crítico es el producto a desarrollar?
No es lo mismo desarrollar un sistema de consulta encaminado simplemente a facilitar el trabajo de un usuario, que un sistema de misión crítica, o un sistema del cual dependan las vidas de las personas. La “criticalidad” (por llamarle de alguna forma) del proyecto es, pues, otra consideración primaria para determinar la extensión y la profundidad del análisis y el diseño: un sistema de misión crítica requiere de una considerable inversión en el diseño, ya que la operación de una empresa, o la vida de personas, están en juego. La experiencia ha demostrado, invariablemente, que los sistemas con un alto grado de diseño son los más estables, y que requieren menor grado de correcciones y de mantenimiento.
¿Qué tan visible y sujeto a ser auditado es este proyecto?
Existe también el caso de proyectos con determinado grado de visibilidad (ya sea en el ámbito de las instituciones gubernamentales, como en el de los negocios), para los cuales existen exigencias específicas en cuanto a la documentación que deben producir, así como el hecho de que pueden
estar sujetos a procesos de auditoría informática. Para estos casos, un análisis y un diseño adecuados son indispensables, y resulta obligatorio contar con personal experto para producir los modelos y la documentación requeridos.
Lo que debemos producir en un sistema funcional
Finalmente, la consideración suprema para determinar tanto la extensión como la profundidad
del análisis y el diseño consiste en tener claro que lo que vamos a producir es una solución o un producto, que debe estar correctamente alineado con los objetivos primarios de la institución o empresa
que lo han solicitado. El análisis y el diseño no son objetivos en si mismos, sino que son tan sólo escalones para llegar a producir la solución.
Acerca del Autor
Jaime González es PMP y experto en UML. Es consultor master e instructor senior en Milestone Consulting, la primer empresa mexicana miembro de la OMG, especializada en la capacitación práctica y consultoría en modelado y buenas prácticas de software. Jaime participó en la traducción al español del libro UML Distilled.
info@milestone.com.mx www.milestone.com.mx
podríamos llamar el lado obscuro de las así conocidas “metodologías”: para cumplir con todas y cada una de las exigencias del proceso, tal o cual proyecto se quedaron estancados en la producción
de modelos de papel, en lugar de avanzar hacia el desarrollo de un sistema que cubriera los requisitos de los clientes y los usuarios.
El Proceso Unificado y UML cuentan con una buena variedad de disciplinas y artefactos, y nos podríamos pasar la vida tratando de plasmar en todo tipo de diagramas el análisis y el diseño de una solución. ¿Cómo aprovecharlos de manera sensata, de tal suerte que realmente ayuden a nuestros proyectos, sin caer en costos o en tiempos excesivos? La respuesta es relativamente simple: sólo debemos producir aquellos modelos que añadan valor suficiente a cada proyecto particular; sin embargo, para determinar qué es lo que consideramos “valor suficiente”, debemos considerar varios parámetros.
¿Para qué estamos modelando?
Tanto la extensión como la profundidad del modelado pueden variar conforme a las razones y exigencias por las que estamos modelando. Los proyectos de software pueden ser muy diferentes
tanto en magnitud como en distintos aspectos de su ambiente: hay equipos y analistas muy fogueados en el modelado, y también hay multitud de instituciones y empresas que apenas comienzan a utilizar procesos formales de desarrollo. Existen, asimismo, equipos de trabajo relativamente pequeños cuyos elementos participan durante todo el ciclo de vida de sus proyectos, y por otro lado existen organizaciones especializadas en análisis y diseño, que entregan sus modelos a terceros que se encargarán del desarrollo.
Supongamos que voy a realizar un desarrollo relativamente sencillo, y que yo mismo lo voy a programar. Mi enfoque, en este caso, puede consistir en realizar diagramas básicos de los casos de uso, con la intención de entender qué es lo que voy a resolver, y para generar documentación suficiente para acordar los alcances del desarrollo con mi cliente. En este caso, me conviene bosquejar las secuencias básicas de estos casos de uso, y por lo menos detectar las secuencias alternas. Si tengo experiencia
con la herramienta de modelado, me conviene hacer un modelo conceptual, mismo que es indispensable para realizar los diagramas de secuencia más esenciales, y que va a devenir en el modelo de clases y el modelo de datos. Este modelo de diseño me va a resultar sumamente útil en entender cómo voy a resolver el desarrollo, y me va a ahorrar mucho tiempo de mi proyecto, dado que es más fácil corregir un diagrama que realizar correcciones extensivas al código. Pudiera apoyar mis
decisiones de diseño con artefactos tales como diagramas de estado, pero usaría éstos sólo en los casos en que resultaran muy necesarios.
Ahora, imaginemos el caso de que no tengo experiencia en realizar modelos conceptuales, y mucho menos en diagramar secuencias, clases y modelos de datos. Más aún, supongamos que no tengo
tiempo de experimentar con modelos conceptuales o diagramas de secuencia, pero tengo una idea muy clara de cómo convertir los casos de uso a pantallas, diálogos y código. Al igual que en el caso anterior,
sería altamente recomendable crear el modelo de casos de uso para entender el problema, y también para poder acordar los alcances con el cliente y los usuarios. Muy probablemente, en toda esta variedad de casos, me apoyaría en bosquejos de pantallas y diálogos, o en prototipos con funcionalidad
limitada, para lograr una mejor comprensión de lo que el usuario y el cliente desean.
El caso extremo, en contraste con los anteriores, sería el de una organización especializada
en análisis y diseño, que genera modelos para que otra organización especializada realice la programación. En este caso, las secuencias básicas y alternas de los casos de uso resultan indispensables, así como la elaboración de diagramas de secuencia detallados que apoyen claramente los modelos de clases y de datos. Los modelos, en ese caso, no servirían sólo para entender el qué y el cómo, sino que representan las especificaciones para los programadores.
Tanto la extensión como la profundidad del modelado deben, entonces, ser en primer lugar
consecuencia de la pregunta: ¿para qué estamos modelando?
¿Qué tan crítico es el producto a desarrollar?
No es lo mismo desarrollar un sistema de consulta encaminado simplemente a facilitar el trabajo de un usuario, que un sistema de misión crítica, o un sistema del cual dependan las vidas de las personas. La “criticalidad” (por llamarle de alguna forma) del proyecto es, pues, otra consideración primaria para determinar la extensión y la profundidad del análisis y el diseño: un sistema de misión crítica requiere de una considerable inversión en el diseño, ya que la operación de una empresa, o la vida de personas, están en juego. La experiencia ha demostrado, invariablemente, que los sistemas con un alto grado de diseño son los más estables, y que requieren menor grado de correcciones y de mantenimiento.
¿Qué tan visible y sujeto a ser auditado es este proyecto?
Existe también el caso de proyectos con determinado grado de visibilidad (ya sea en el ámbito de las instituciones gubernamentales, como en el de los negocios), para los cuales existen exigencias específicas en cuanto a la documentación que deben producir, así como el hecho de que pueden
estar sujetos a procesos de auditoría informática. Para estos casos, un análisis y un diseño adecuados son indispensables, y resulta obligatorio contar con personal experto para producir los modelos y la documentación requeridos.
Lo que debemos producir en un sistema funcional
Finalmente, la consideración suprema para determinar tanto la extensión como la profundidad
del análisis y el diseño consiste en tener claro que lo que vamos a producir es una solución o un producto, que debe estar correctamente alineado con los objetivos primarios de la institución o empresa
que lo han solicitado. El análisis y el diseño no son objetivos en si mismos, sino que son tan sólo escalones para llegar a producir la solución.
Acerca del Autor
Jaime González es PMP y experto en UML. Es consultor master e instructor senior en Milestone Consulting, la primer empresa mexicana miembro de la OMG, especializada en la capacitación práctica y consultoría en modelado y buenas prácticas de software. Jaime participó en la traducción al español del libro UML Distilled.
info@milestone.com.mx www.milestone.com.mx
- Log in to post comments