.jpg "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:
