[Software Factories] Introducción (Parte 4)

Esta entrada es parte de la serie «Introducción a los conceptos de Software Factory» que hasta el momento se compone de las entradas anteriores:

En esta entrada voy a trara sobre el punto central al que aplica el concepto de SF, la linea de productos. Antes de esto debo aclarar que existe una clasificación de los SF la cual distingue entre SF horizontales, aquellos relacionados a una tecnología, plataforma, arquitectura, que pueden ser comunes tanto a un CRM, ERP, DMS como a cualquier otro (como son por ejemplo los casos de SCSF, WSSF, MCSF, etc.) y los verticales que son aquellos que se utilizan para la construcción de una familia de productos estrechamente relacionadas a un tipo de negocio como CRMs, ERPs, etc. Hoy contamos, gracias a Microsoft de SF horizontales pero a los SF verticales deberemos construirlos nosotros. A menos que alguien conozca una especie de Customer Relationships/Service Software factory 🙂

Volviendo al tema, una linea de productos se refiere a un tipo de aplicación que puede agruparse o identificarse como perteneciente a una familia de productos, como por ejemplo sistemas de CRM, software de seguros, software para entidades bancarias, de control aereo y cualquier otro. Es decir, pueden agruparse de distintas maneras, por segmento de negocios, tipo de soluciones, plataforma, etc. Lo importante es poder identificar aquellas características comunes, lo que mediante la reutilización de ciertos assets de alto nivel de granularidad, nos proporcionará la tan buscada economía de alcances.

Tanto los SF horizontales como verticales cumplen con el cometido de mejorar la calidad, productividad y tiempos de entrega, pero son los verticales los que pueden aportar «el gran salto» que una empresa necesita en estos sentidos.

Los pasos

Alcances: El primer aspecto importantes es analizar los alcances del SF a construir, es decir, que tipos de aplicaciones podremos crear con él. Este es sin dudas un tema esencial y dificil por cuanto mientras más tipos de aplicaciones querramos abarcar, mayor esfurzo requerirá en sus otros dos ejes (variabilidad y extensibilidad).

Supongamos que tenemos bien definido el alcance de nuestro SF. Algo así como:
«DMSSF (Document Manager System Software Factory) es un SF para la construcción de aplicaciones de uso de documentos como, expedientes, procedimientos, reclamos, comunicados, Bases de conocimientos, publicaciones en linea, reporte de errores y otros similares».
Bueno, debería ser mejor pero este es solo un blog :). Ahora, todos estos sistemas tienen características similares o al menos una muy evidente, son todo sistemas documentales.

En el libro «Practical Software Factories in .NET From Theory to Practice—A Primer, Reference, and Case Study«, que es el que estoy leyendo ahora, dice que el primer paso es redactar y comunicar la visión del SF y da el siguiente ejemplo para la empresa ficticia ISpySoft:
«Develop a Software Factory that enables efficient development and maintenance of
high-quality, modular, extensible applications for private investigator offices and field
agents, and that allows ISpySoft to also offer new services to its customers.
»

<opinion>La verdad es que a mi entender, estas declaraciones no sirven para nada y ponen a mucha gente a perder tiempo valioso en discuciones improductivas. Además suenan todas iguales.</opinion>

Variabilidad y extensibilidad: Una vez analizadas las similitudes (y extraerlas y documentarlas) debemos concentrarnos en las diferencia. Las diferencias podrian ser:

  • para expedientes y reclamos tenemos clientes mientras que para el resto no.
  • para expedientes, procedimientos, reclamos y reporte de errores tenemos un workflow mientras que para el resto no.
  • Algunos documentos necesitan un control de versiones y otros no.
  • Algunos pueden necesitar si o si de digitalización de documentos en papel y otros no.
  • Algunos necesitan autentificación, envios de emails, trabajo desconectado, integración con outlook, logueo en db, etc.

Aquí también deberian ser mejores.

Estas diferencias hacen al concepto de variabilidad y extensibilidad. Muchas veces se piensa que esto es una cuestión de configuración o parametrización de un producto complejo al que mediante opciones de parametrización se le pueda dar la funcionalidad requerida, algo así como configurar un sistema de control de transporte para que se comporte como un control de tráfico aereo o uno de tracking de ganado. Esta es la clásica visión de producto configurable que no se corresponde con la idea de software factory. Esto es parte del paradigma anterior 🙂

En la entrada [Software Factories] Introducción (Parte 2) explico estos dos conceptos así que no los repetiré aquí. Pero cual es la diferencia entre variabilidad y extensibilidad? (<include> o <extend>) La variabilidad se refiere a aquellas características o alcances que tenemos plenamente identificados y que por lo tanto están ya en el total conocimiento de quienes conocen el dominio. Estas son candidatas a ser fácilmente configurables por nuestras herramientas por ejemplo: usuarios integrados con LDAP u otro sistema nuestro, tenemos integración de clientes con otros sistemas o no, etc.

La extensibilidad, en cambio, hace a todos los aspectos que pueden pertenecer (tal vez no) a la penumbra de los requerimientos del cliente y que por lo tanto deben predecirse para dejar esas puertas abiertas.

Pasar de la visión de producto a la visión de linea de productos

Este es un tema muy dificil, sobre todo porque no encontré nada al respecto así que acá va un intento:

  • Convencer al concejo de ansianos (o al gran jefe) de las bondades del cambio. El concejo no entiende de c# ni Biztalk y dado que esta iniciativa se gestará en los niveles medios o administrativos, es primordial contar con el apoyo de la alta gerencia.
  • Converzar con todos los involucrados sobre la nueva manera de pensar y hacer software. Estos cambios siempre despiertan curiosidad y motivación en la gente por lo que abre las puestas para que se los involucre en las nuevas tareas. Además todo el mundo tendrá preguntas y sugerencias.
  • Reunir al equipo que desarrollará el SF. Este equipo ya está preseleccionado de antemano, todos saben quienes son, los mejores desarrolladores, el product manager, la gente de QA, los implementadores con mayor conocimiento del dominio del negocio y las necesidades habituales de los clientes, etc.
  • Armar el Software Factory Schema (introducción parte dos). Y factorizar el o los productos existentes y matchear los factores (producto de la factorización) con los viewpoints del SFS.
  • Comenzar a tailorizar EL proceso. Ya no tendremos UN proceso de desarrollo DE SOFTWARE sino un proceso de desarrollo de aplicaciones de administración de documentos web enabled.
  • Manos a la obra!
  • Hacer un piloto y cargar el feedback para mejorar el SF.

Indudablemente esto es mucho mas complejo y por cada item existen muchos aspectos que escapan al sentido original de esta entrada como «Análisis y diseño de SF».

Assets existentes

Para finalizar, tanto el resultado de la factorización de los productos (si los hubiera) como los assets existentes deben integrarse y acoplarse mediante, el proceso de desarrollo y el IDE de desarrollo.

Continuará…

Lucas Ontivero

Sin categoría

2 thoughts on “[Software Factories] Introducción (Parte 4)

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *