Buscar en Gazafatonario IT

Mostrando las entradas con la etiqueta RUP. Mostrar todas las entradas
Mostrando las entradas con la etiqueta RUP. Mostrar todas las entradas

domingo, junio 22, 2014

Ecos del SEPG Latino América 2014

Manizales, en los alrededores de la sede de la SEPG LA
Para quienes no están familiarizados, SEPG es la serie de conferencias premier en gestión de procesos de software y sistemas. Cada conferencia brinda desarrollo profesional en mejoramiento de procesos a través de sesiones técnicas enfocadas en tecnologías como CMMI, People CMM, PSP, TSP, Agile, ISO y Six Sigma; también aborda los enfoques para implementar alta madurez, técnicas efectivas de adquisición, desarrollo y entrega de servicios, entre otros temas de relevancia para la industria.
En Latinoamérica este año la edición de la conferencia, SEPG LA, se llevó a cabo en Manizales, en un ambiente natural, rodeado de montañas y termales de aguas que provienen directamente de las entrañas de la tierra, nos reunimos 2 o 3 centenares de personas que llegamos de latitudes tan diversas como España, USA, Chile, México y Colombia. Como era de esperarse, el programa de la Conferencia se combinó con un ambiente de networking entre los asistentes, condición sine qua non el evento no hubiese colmado las expectativas de quienes acudimos a la cita.
El Programa
Cuando me enteré que el llamado de artículos incluía entre sus temas principales la combinación de disciplina con métodos ágiles pensé que era una forma peyorativa de nombrar los métodos y prácticas con enfoque ágil. Eso me motivó a participar. Involucrado como he estado en los últimos años con la agilidad y lo que yo llamo la Cultura Ágil, liderando el proceso de transformación de una compañía con un alto nivel de madurez, he aprendido que los dos ecosistemas, el de procesos prescriptivos tipo CMMI, y el de procesos generativos tipo Scrum, se pueden “aprovechar” uno del otro. Con ello en mente, preparé mi ponencia “Ágil es algo que eres, CMMI es algo que usas”, pero eso es algo a lo que llegaré más adelante.
  • El resto del programa incluía temas como:
  • Competitividad y supervivencia en un mercado globalizado (Visión estratégica del sector TI)
  • Mejora de procesos en entornos diversos (pequeños, pymes y grandes empresas)
  • Alcanzando y trabajando en entornos de alta madurez
  • Mejorando la capacidad de la prestación de servicios TI
  • Industrializando la producción de Software
  • Retos en las arquitecturas y nuevos modelos de negocio TI (Arquitectura Empresarial, Cloud, Big Data, Movilidad, Seguridad, entre otros), y
  • Marca y normatividad sectorial de Software
El plato estaba servido, mi artículo había sido aceptado en la Conferencia, así es que viajamos a Manizales en compañía de algunos colegas y amigos de la industria. Al ver la fascinación que representaban las cordilleras colombianas, mientras repasaba lo que había escrito para la ponencia sobre lo que significa ser ágil, recordé a uno grande de la industria, Steve Jobs, diciendo que ese precisamente había sido uno de sus mantras – foco y simplicidad.
Tenía razón Jobs, lo simple puede ser más difícil que lo complejo. Tienes que trabajar duro para lograr que tus pensamientos sean limpios y poder alcanzar así la simplicidad. Pero vale la pena, porque una vez allí, puedes mover montañas. En ágil, la simplicidad el arte de maximizar el trabajo no realizado, es esencial. O así lo invoca el Manifiesto Ágil.
El Evento
El Ministro TIC de Colombia, Dr. Diego Molano Vega
El inicio del evento supuso un acto protocolario algo extenso para mi gusto – qué le vamos a hacer, ¡tenía que decirlo! –, que incluyó al Ministro de las TIC en Colombia, Dr. Diego Molano, y al alcalde de Manizales, con presentaciones bastante enérgicas, lo mismo que a la Dra. Elena Schaeidt Ayarza, Directora de Desarrollo Corporativo e Internacional de TECNALIA y al Dr. Albeiro Cuesta Mesa, Director de Políticas y Desarrollo TI hablando sobre cómo se está transformando la industria TI en Colombia.
A continuación, el Dr. Kirk Botula, CEO del CMMI Institute, rama recién desprendida del SEI, nos habló de cómo hacer para que la industria de TI latinoamericana trabaje mejor. En su presentación, el Dr. Botula hablaba de como la misión del CMMI Institute era hacer que el mundo trabaje mejor, hacer que el mundo del trabajo, funcione mejor. La razón por la que la gente adopta CMMI, decía Botula, o de preocuparse por esos marcos de trabajo o las evaluaciones CMMI o el entrenamiento en esas áreas, es debido a los buenos resultados que todo eso lleva a las organizaciones e instituciones que lo usan.
Pero el Dr. Botula también le abrió las puertas a la filosofía ágil. Afirmó que con técnicas ágiles ganamos el 5% más de velocidad que con CMMI y 2% más que con TSP, aunque dijo también que los costos de desarrollo son los mismos. ¿Qué si ágil es la dirección correcta? No, según Botula todavía no, pero igual pensé que el haberlo mencionado ya era un hito.
Al día siguiente, la contraparte de Botula, el Dr. Paul Nielsen, CEO del SEI, habló de la calidad del software y de su impacto en la ciberseguridad. Mostró datos nada nuevos para quienes estamos involucrados en el tema: que el 70% de los defectos del software se introducen en las primeras etapas del desarrollo y que solo se encuentran el 3,5% de los errores en esas mismas etapas (requisitos, diseño, arquitectura y diseño de componentes). El mensaje de Nielsen es que sigamos adoptando un enfoque centrado en la arquitectura, nada que no hayamos estado haciendo hará ya una década y media con la guía de procesos como el Unified Process.
Además hubo una mesa redonda moderada por la Viceministra de TI de Colombia, la señora María Isabel Mejía, con un panel compuesto por los directores de los clusters de empresas de TI en Colombia, como Lina Taborda, Directora de Intersoftware, y María Victoria Gara, Directora de CaribeTIC, entre otras personas. El panel versó sobre la oferta y la demanda de las TIC en Colombia en el que se dijo que necesitamos más talento calificado, más programas específicos de desarrollo de las TIC para las regiones, etcétera.
La Viceministra de TI, María Isabel Mejía
A propósito de la Viceministra, tuve la oportunidad de almorzar con ella y con Lina Taborda de Intersoftware (por invitación de esta última). El objetivo inicial era presentarle las VII Jornadas Latinoamericanas de Metodologías Ágiles que serán en octubre en la ciudad de Medellín y de cuyo equipo organizador hago parte, pero el almuerzo se extendió gratamente y tuvimos la oportunidad de hablar largamente de métodos y prácticas ágiles y de la presentación que yo haría un par de horas más tarde sobre la cultura ágil, al cierre del evento.
Las Conferencias
El resto de ponencias transcurrieron en un ambiente ponderado. Algunas de buena calidad, otras no tanto o, al menos, esas fueron las notan predominantes durante los 2 días del evento. La lista de conferencias la encuentran en:
http://www.sepgla.com.co/programa/
Y finalmente, al cierre, mi presentación, “Ágil es algo que eres, CMMI es algo que usas”. Pero antes de ir a ese punto específico, quisiera hacer mención de una de las conferencias, no porque las demás no lo merezcan, sino porque no hay espacio para mucho más. Me llamó la atención el tema que presentó Luz Adriana Sepúlveda sobre los significados acerca del proceso de implementación de un modelo de mejoramiento de procesos.
Luz Adriana nos habló de los resultados obtenidos durante una investigación que condujo. Algunos de sus planteamientos vienen de Deming y de Crosby, entre otros. Dejó asomar lemas como el de Tomas Gilb que señalan que el personal que no está motivado no avanza, ofrece resistencia y niega el cambio. Algunos datos interesantes como que más de la mitad de 100 esfuerzos de transformación corporativa no sobrevivieron el arranque inicial, o así se desprende de un estudio de John Kotter de Harvard. Sepúlveda nos mostró algunas de las causas de todo esto:
  • Falta de compromiso de la Alta Dirección
  • Falta de continuidad por no contar con estructura de soporte
  • No tomar en cuenta las limitantes que pueden afectar el proceso.
  • Cambio en los sistemas sin cambio en el operador (no existe cambio en la manera de pensar)
Sobre su estudio, Luz Adriana enfatiza en los factores motivantes de rechazo a un Sistema de Gestión de Calidad:
  • Miedo a lo desconocido
  • Resistencia a experimentar
  • Aumento /Disminución de las responsabilidades laborales
  • Falta de información – Desinformación
  • Amenazas al pago y otros beneficios
  • Factores históricos
  • Amenazas al estatus
  • Miedo al fracaso
  • Temor a no poder aprender las nuevas destrezas requeridas
Y señala algunos elementos que contrarrestan esas aprehensiones:
  • Sensibilización/Capacitación/Información
  • Participación en el proceso
  • Construcción colectiva del sistema
  • Experiencia adquirida
  • Acompañamiento por parte de los líderes
  • Planeación del proceso
  • Conceder tiempo al personal para participar activamente en el sistema.
Los dejo con los datos de Luz Adriana por si quieren contactarla. 
Ágil es algo que eres, CMMI es algo que usas
Algunos momentos de mi conferencia. Foto de María Clara López.
En este SEPG LA Se habló mucho de calidad, pero no se habló de las personas. Y mucho menos de sus interacciones. Pensé entonces que el enfoque de mi discurso era precisamente el que quería. Mi asunto principal era que los métodos ágiles no tienen por qué entrar en conflicto con otros modelos o enfoques de construcción de software, no es la idea de ser ágil o, al menos, no está en el flujo de un proceso de transformación a ágil echar tierra a las prácticas existentes en una organización. Los líderes de los procesos actuales deberían trabajar en conjunto con los nuevos líderes para que estos últimos obtengan los beneficios de ambos universos y aprovechar esa sinergia para mejorar dramáticamente el rendimiento del negocio.

Para apoyar este concepto, expliqué que los modelos como CMMI, PMI e ISO nos dan una idea de cuales procesos son necesarios para mantener una organización madura y disciplinada, capaz de predecir y mejorar el desempeño de la organización misma y de los proyectos. Entre tanto, las técnicas ágiles proporcionan guías para un manejo eficiente de los proyectos de una manera que permite alta flexibilidad y adaptabilidad. Al mezclar los dos enfoques, la filosofía ágil asegura que los procesos se implementen eficientemente a la vez que aceptan los cambios; y los modelos tradicionales aseguran que se consideren todos los procesos relevantes.

Pero de inmediato fui al centro de mi exposición: una de las grandes diferencias, radicales por demás, entre los métodos tradicionales y los ágiles es que estos últimos son generativos, no prescriptivos. Los procesos necesitan evolucionar según las necesidades, no prescritos con anticipación. Un enfoque prescriptivo genera procesos complejos y complicados, mientras que un enfoque generativo comienza con un conjunto de procesos simples y adiciona otros a medida que se requieren.

La filosofía ágil reconoce que los procesos de software más efectivos no pueden definirse por adelantado; es un proceso continuo. Los métodos tradicionales se enfocan en definir y reforzar procesos y gastan muy poco tiempo en identificar y entregar lo que los usuarios necesitan. Aunque su propósito es mejorar la consistencia y la calidad, esto muchas veces se consigue a expensas de la productividad y la entrega. El enfoque tradicional de procesos tipo CMMI también usa herramientas monolíticas y pesadas que causan construcciones frágiles y traspasos inefectivos entre desarrollo, pruebas, despliegue y operaciones.

A esta altura de mi coloquio, la suerte estaba echada. Decir eso en una Conferencia dedicada a adorar a los procesos y a modelos tipo CMMI podría tomarse como sacrilegio. Lo que siguió fue enfatizar en lo que significa ser ágil: específicamente, la interiorización y la práctica de los Valores y Principios del Manifiesto Ágil, nada de lo que no haya hablado en algunos de mis artículos citados más abajo en las referencias.

Pero contrario a mi desazón, la reacción de mis oyentes fue bastante positiva. Era el final del evento, todos estábamos cansados, pero muchos quisieron ir más allá y tuve la oportunidad de compartir experiencias luego de mi charla con muchos de los presentes. La misión, la mía, estaba cumplida: sembrar una semilla, una llama que motive a los colegas a mirar en otra dirección. Por supuesto que dije que ágil no era la solución, pero sí una muy buena alternativa, una que nos está permitiendo volver a amar la profesión, volver a querer que sea lunes en el trabajo, para seguir innovando con cada interacción.

Referencias

Las diapositivas de la conferencia la pueden descargar de:


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.

martes, octubre 02, 2012

Casos de Abuso, Parte 11: Cada caso de uso se diseña e implementa de manera independiente


El diseñador y el desarrollador sólo ven el caso de uso en desarrollo sin importarles el sistema como un todo.  Cuando esto se hace así, y no por paquetes relacionados, corremos el riesgo de no armar el “rompecabezas” con facilidad al final de la operación.
Y lo que es peor, muchas veces durante el diseño e implementación del caso de uso no tenemos en cuenta los lineamientos arquitectónicos impuestos a la solución. El producto termina siendo una colcha de retazos mal cosidos. Esta situación convierte los hitos de integración del producto, iteración tras iteración, fase tras fase, en un serio dolor de cabeza para el arquitecto, los diseñadores y los mismos programadores. Entonces surgen los reprocesos, el desperdicio de código, rediseños, y el resultado final: un producto de mala calidad.
El tratamiento: la arquitectura del software. Una que sirva como una gran lista de chequeo para los diseñadores y para los implementadores del producto. La arquitectura de software es la organización fundamental de un sistema, formado por sus componentes, las relaciones entre ellos mismos y con el entorno, y los principios que gobiernan su diseño y evolución (IEEE 1471-2000). Según Booch, Kruchten y otros, la Arquitectura de Software incluye decisiones acerca de la organización de un sistema de software como:
·         La selección de los elementos estructurales que componen el sistema y sus interfaces
·         El comportamiento del sistema, especificado en las colaboraciones entre esos elementos
·         La composición de estos elementos estructurales y comportacionales en subsistemas más grandes
·         El estilo arquitectónico que guía esta organización
Toda arquitectura de software comienza por una arquitectura funcional o vista de casos de uso, un subconjunto del modelo de casos de uso del sistema, compuesto a su vez por los así llamados casos de uso o requisitos arquitectónicos. Después están la vista lógica, que le habla a los analistas y diseñadores sobre la estructura del software. La vista de implementación, que les cuenta a los programadores detalles sobre el manejo del software. Por su parte, la vista de procesos habla de desempeño, escalabilidad y puesta en marcha a los integradores del sistema. Y también está la vista de despliegue que nos explica de manera lacónica la topología del sistema, aspectos de la entrega del mismo, de instalación y de comunicación subyacentes.
El diseño y la implementación de todo el producto de software debe obedecer a estas restricciones, casi leyes, impuestas por la arquitectura así descrita. Es lo que hace posible que los casos de uso se diseñen en grupos heterogéneos de paquetes o subsistemas diferentes.
Impacto en la calidad: Alto.

PD. Para saber sobre Arquitectura de Software, específicamente sobre el modelo de las 4 + 1 vistas expuesto por Krutchen, pueden tener en cuenta la siguiente referencia:
P.B. Kruchten, “The 4 + 1 View Model of Architecture,” IEEE Software, pp. 42–50, Nov. 1995. http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?tp=&arnumber=469759&isnumber=9910
También la encuentran en:
Además, sobre análisis y diseño de casos de uso, en particular, sobre realización de casos de uso, pueden visitar mi Lectura Fundamental 10:
Y sobre programación orientada a objetos, pueden leer mi Lectura Fundamental 11: Orientación a Objetos: Un Enfoque Teórico Moderno (Actualizado)

domingo, septiembre 30, 2012

Casos de Abuso, Parte 10: Los flujos de eventos en los casos de uso son escritos en pseudocódigo


Este es el que yo llamo “síndrome del programador que se volvió analista”, algo así como el hombre-lobo del proceso de desarrollo de software. Creo que todos los que hemos recorrido este largo pero tortuoso laberinto que significa el ciclo de vida del desarrollo de software hemos experimentado, al menos, una o más de esas manifestaciones “fenomenoides” del universo informático. Además, este abuso es primo del abuso 5, donde usamos detalles técnicos en la documentación del caso de uso.
El antídoto es sencillo: un caso de uso siempre, sin ninguna excepción, se escribe en terminología del negocio, con las palabras que usa el usuario en sus actividades diarias. Si esto no es posible, quizás no estamos ante un caso de uso.
Nada de incluir expresiones como: “si ocurre esto entonces hacer aquello”, en cambio usar distintas secuencias o flujos alternos; o “mientras se cumpla una condición, realizar estas acciones”, en vez de ello, describir el conjunto de acciones para un elemento-sujeto de la condición y en los requisitos especiales del caso de uso dejar de manifiesto que puede haber uno o más elementos para esa condición. Y mucho menos usar nombres de “variables”, ciclos for o while o selección múltiple. Lo único que lograremos con ello es confundir a los usuarios.
Veamos con un caso de uso algo escueto un ejemplo típico:
Caso de uso: Retirar fondos
Actor: Cliente
Secuencia Básica:
1.    El caso de uso inicia cuando el cliente decide retirar dinero en efectivo de un cajero automático
2.    El sistema solicita la cantidad de dinero a retirar
3.    El Cliente ingresa la cantidad de dinero a retirar
4.    El sistema verifica el saldo del Cliente
5.    Si el Saldo del Cliente es mayor que o igual a la cantidad a retirar, el cajero entrega el dinero. De lo contrario, muestra el mensaje “Fondos insuficientes”
6.    El caso de uso termina
Los pasos 4 y 5 de este caso de uso son una muestra de lo que no se debe hacer al documentar requisitos. En cambio, podríamos decir:
4.    El sistema verifica que el Cliente tiene saldo suficiente en su cuenta y entrega el dinero.
5.    El caso de uso termina
Para el caso de falta de fondos, escribimos una secuencia alternativa. Esta estrategia además posibilita una implementación más rápida y “limpia” del caso de uso y permite al equipo de pruebas tener mayor visibilidad de los escenarios para verificar el software.
Impacto en la calidad: Alto.

PD. Para saber más de sobre casos de uso, abecés, anatomía, prácticas y requisitos en general, puedes visitar mi Sección Lecturas Fundamentales en mi Gazafatonario IT.

miércoles, septiembre 26, 2012

Casos de Abuso, Parte 9: Todos los requisitos funcionales se documentan en casos de uso


El que un proceso sea dirigido por casos de uso no quiere decir que toda la funcionalidad del software debe estar documentada en casos de uso. Hay requisitos que son transversales al producto, es decir, aplican en varias partes del sistema; también hay requisitos funcionales que se expresan mejor en prosa, siempre en términos del usuario, pero en narrativa; hay otras funcionalidades cuya complejidad amerita el uso de diagramas de actividad o de otro tipo de elementos gráficos o visuales para entenderse. En este último caso, siempre recomiendo el uso formal de UML como mecanismo de comunicación para no dar pie a malos entendidos o a concentración de ambigüedades.
Ya lo he expresado antes, los casos de uso apenas son uno de los mecanismos para identificar, organizar, documentar y administrar requisitos o, en el orden de ideas que estoy formulando, un receptáculo de requisitos, un depósito, un bote, una funda, un artilugio. De hecho, los casos de uso constituyen la práctica industrial más ampliamente usada en materia de requisitos de sistemas de información.
Lo digo de esta manera porque he notado que es muy fácil para las personas extraviar la noción y la práctica correcta de la Ingeniería de Requisitos y volverse “caso-de-uso-dependientes” y en ocasiones crean una especie de religión donde el acto de fe por los casos de uso toma tintes de devoción.
Como cualquier adicción, esta también va a ser difícil de desarraigar de nuestros modelos mentales. Sin embargo, vamos a intentarlo. Pero antes de eso, quiero reiterarles que soy entusiasta de los casos de uso, quienes han seguido mi Gazafatonario IT conocen las Lecturas Fundamentales, un esfuerzo medio modesto medio imponente por transmitir mi experiencia en el tema y que fueron la base de mi próximo libro, actualmente en etapa de edición.
En los últimos meses también he estado publicando sobre casos de uso 2.0, una estrategia que reúne las mejores prácticas tradicionales y ágiles para la documentación de requisitos de software, expuesta recientemente por el Dr. Ivar Jacobson y su equipo. Sobre este tema volveremos más adelante, cuando hayamos entendido, o hayamos vuelto a entender, el verdadero sentido del uso y el abuso de los casos de uso.
Este ha sido el principal objetivo de esta serie así llamada “Casos de Abuso”. En el capítulo 4 de la misma expongo las distintas formas y colores que pueden tomar los requisitos del software:
Impacto en la calidad: Bajo.
PD. Para saber más de ingeniería de requisitos, análisis de requisitos y el papel del Analista de Requisitos y de otros aspectos relacionados, pueden leer mi Lectura Fundamental 9:RUP: Fase de Concepción, Parte 2”, en mi Gazafatonario IT:

martes, septiembre 25, 2012

Casos de Abuso, Parte 8: Precondiciones vs. Validaciones y Poscondiciones vs. Resultados


A este caso de abuso originalmente lo titulé:
Las precondiciones son validaciones que hace el caso de uso al comienzo del mismo o en algún paso siguiente. Las poscondiciones y el resultado del caso de uso son una misma cosa.
Este es quizás el mayor de los abusos. Las precondiciones no ocurren dentro del caso de uso, es justamente lo contrario. Las precondiciones representan el estado en el que debe estar el sistema para que se ejecute el caso de uso a la que pertenecen. Son acciones que ocurren antes, en algún momento del tiempo, de la ejecución (o de la necesidad de ejecución) del caso de uso. Y cuando digo “en algún momento del tiempo” no me refiero a que tiene que ser inmediatamente antes del caso de uso, puede ser en cualquier instante, mientras sea antes de la ejecución del caso de uso. Para usar términos bastante reconocidos por nosotros, si un caso de uso tiene precondiciones, se encuentra deshabilitado hasta tanto todas las precondiciones no se hayan ejecutado y hayan producido los resultados necesarios para que el caso de uso se habilite y pueda ejecutarse.
Figura 2: Representación Visual de las Precondiciones y las poscondiciones de un caso de uso. Fuente: Adaptado de IBM Rational Unified Process
El error más común ocurre cuando confundimos una precondición con la validación a un elemento específico del negocio, por ejemplo, que el Cliente debe tener una cuenta corriente para solicitar aumento de cupo de sobregiro. Esta, a todas luces, es una verificación que debe ocurrir en el caso de uso “solicitar aumento de cupo de sobregiro” después de que el cliente se haya identificado, antes no es posible.
Un análisis similar puede hacerse para las poscondiciones, confundidas casi siempre con los resultados del caso de uso. Por ejemplo, es frecuente leer en la especificación de un caso de uso: “el sistema almacena los datos de la solicitud.”, “el sistema muestra el mensaje ‘no se pudo realizar la operación’.”, “el sistema cancela la ejecución del proceso.” Todas estos detalles corresponden a eventos que ocurren (deben ocurrir) dentro del caso de uso, no después de su ejecución, que es el terreno donde se mueven las poscondiciones.
Una poscondición típica puede ser: “el cliente puede consultar el estado de sus facturas.” Otra puede ser: “la cuenta del usuario queda deshabilitada.” Una más: “el cliente VIP puede modificar el estado de su reserva.” Todas estas son acciones que los usuarios pueden hacer después de que un determinado caso de uso se haya ejecutado, satisfactoriamente o no. El momento en el que se haga tampoco tiene que ser inmediatamente después, casi siempre depende de las necesidades de los usuarios particulares de cada funcionalidad.
Una situación adicional que ocurre en muchas oportunidades es que nos quedamos buscando precondiciones y poscondiciones del caso de uso durante un tiempo considerablemente extenso. Siempre recomiendo a los neófitos que si no las encuentran en las primeras de cambio pueden estar sucediendo dos cosas importantes:
  • No tenemos información suficiente del caso de uso (o no lo hemos entendido bien)

O
  • No tenemos la experiencia práctica o el conocimiento teórico suficiente para lidiar con estos dos aspectos de los casos de uso.

En el primer caso, debemos siempre buscar la información que nos hace falta con las personas involucradas, los usuarios; en el segundo caso es un poco más difícil, pero mientras este tema se nos vuelve una costumbre, recomiendo no quedarnos mucho tiempo paralizados por ello y seguir adelante. Las precondiciones y las poscondiciones son aspecto importantes para el diseño y la implementación del caso de uso, pero si no las encontramos, existen otras formas de llegar a la misma solución, quizás tome un poco más de tiempo a los diseñadores, pero este será mucho menos que si los analistas se quedan horas o días buscando algo que no conocen.
Otra cosa más, tanto las precondiciones como las poscondiciones son opcionales: no siempre son un elemento adherido al caso de uso. Es posible que haya casos de uso que no tengan unas o las otras, o ambas.
Impacto en la calidad: Alto.
PD. Para saber más de precondiciones y poscondiciones y de otras características de los casos de uso pueden leer mi Lectura Fundamental 3: “Casos de Uso: del todo y de sus partes”, en mi Gazafatonario IT:

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.