Llegamos a ustedes gracias a:



Reportajes y análisis

Primero visualice, después construya: Las ventajas de las herramientas de simulación

[05/07/2010] Cuando se le preguntó a Jan Scheetz que diera una lista de deseos de lo que quería en un sistema electrónico de órdenes para médicos para su uso en los regímenes de rehabilitación de pacientes, sabía lo que quería. De acuerdo a Scheetz, el sistema ideal debería generar una firma electrónica válida para el médico, lo cual es necesario para procesar los requerimientos de los seguros y de Medicare (programa de seguro social del gobierno) pero que generalmente es difícil de obtener.

Esto es algo con lo que hemos soñado por mucho tiempo, sostiene Scheetz, supervisor de pacientes ambulatorios del MD Anderson Cancer Center de Houston. Ahora tenemos consultas en línea pero no ofrecen órdenes firmadas y por tanto se requiere de un considerable trabajo manual para completarse. Sin embargo, un nuevo proceso permitiría al personal del hospital tratar las consultas en línea como una orden firmada válida generada por un médico.
Quizás lo mejor de todo es que Scheetz y sus colegas podrán ver como se verá el sistema incluso antes de que sea desarrollado.
El hospital usó una herramienta de software llamada iRise, que permite a las empresas simular y crear imágenes de cómo se verán las aplicaciones de software antes de que se produzca su desarrollo. No son prototipos de trabajo, sino que son aplicaciones que actúan con un look and feel acabado, sin código detrás de ellas.
Scheetz y otros en su departamento trabajaron con los analistas de negocios del MD Anderson. Todos ellos usaron iRise para discutir lo que querían en el sistema y luego, muchos meses después, Scheetz y sus colegas vieron la primera versión.
Los requerimientos importan
El desafío que los stakeholders de la empresa enfrentan al tratar de comunicar sus requerimientos a los desarrolladores de software no es un problema nuevo, señala Melinda-Carol Ballou, analista de IDC en Framingham, Massachusetts. Pero resolver ese problema se ha convertido en una tarea crítica con la aparición de la crisis económica.
Con la cada vez mayor escasez de recursos, no queda margen para el error. Así que si hay algún tipo de desconexión entre lo que uno crea y lo que realmente necesita la empresa, los costos por fallar son más pronunciados en este entorno económico, señala Ballou, añadiendo que este es el motivo por el que los productos están evolucionando para ocuparse específicamente de este tema.
Cuando uno visualiza los requerimientos y la apariencia en una pantalla, esto le da a los usuarios algo tangible de tal forma que pueden ver algo en términos físicos, sostiene.
Hay una gran necesidad de una mejor comunicación entre los stakeholders y los desarrolladores. La firma de investigación de TI de Boston, The Standish Group, reporta que hubo una reducción en las tasas de éxito de los proyectos del 2006 al 2008. (Standish conduce sus estudios de investigación cada dos años, y el 2008 es el año más reciente para el cual hay datos disponibles; los resultados de un nuevo estudio se encontrarán listos para inicios del próximo año). En el 2008, 32% de todos los proyectos tuvieron éxito, lo cual significa que fueron entregados a tiempo y dentro del presupuesto, con las características y funciones requeridas, de acuerdo a Standish. En comparación, el estudio del 2006 mostraba que el 35% de los proyectos tuvieron éxito.
Por otro lado, en el 2008, cerca del 44% de los proyectos se retrasaron, sobrepasaron su presupuesto y/o llegaron sin todas las características y funciones requeridas, y 24% fracasaron y fueron cancelados antes de su término o entregados y nunca usados, de acuerdo a Standish. En el 2006, la tasa de fracaso fue de 19%.
El ambiente de desarrollo se ha hecho tan desafiante recientemente porque la economía ha forzado a las personas a volver a evaluar los proyectos que estaban realizando, señala Jim Johnson, presidente de The Standish Group. Por ejemplo, algunos proyectos comenzaron, pero luego fueron cancelados porque se les consideró no alineados con las metas corporativas. Adicionalmente, creo que las personas han exagerado en la implementación de la gobernanza y el cumplimiento en sus proyectos, los cuales se han hecho tan sofisticados que no pueden entregarlos, sostuvo Johnson. No tenemos equilibrio en ese campo.
Tradicionalmente, desarrollar una aplicación de software para la evaluación beta puede demorar meses, incluso con los novedosos métodos de desarrollo Agile. Sin embargo, la visualización de la aplicación puede realizarse en horas para darle a los usuarios un panorama de cómo se verá el sistema y como funcionará. También permite detectar tempranamente si el desarrollador se ha desviado en términos de crear lo que el usuario desea.
Los departamentos de TI están plenamente concientes que el desarrollo de software es algo que tienen que manejar mejor, señala Tom Grant, analista de Forrester Research Inc. Cada vez hay más conciencia de que este es un problema que vale la pena investigar, porque las personas van a desperdiciar mucho tiempo en los ciclos de rediseño, sostiene Grant. Sin embargo, las herramientas para remediar la situación no se encuentran aún generalizadas, añade. No se encuentran disponibles, y las pocas que se encuentran en el mercado simplemente no se están usando.
Tanto Ballou como Grant afirman que las herramientas de visualización son solo parte de un mercado más grande de herramientas de requerimientos. El mercado de herramientas de requerimientos como un todo ha sido adoptado tardíamente, observa Grant. El mayor desafío que estos proveedores tienen, señala, es el tema cultural de intentar que las compañías dejen de usar aplicaciones como las hojas de cálculo y el PowerPoint para que los usuarios articulen sus requerimientos. Ambos analistas también afirman que es difícil señalar el tamaño del mercado de herramientas de visualización de aplicaciones, ya que se encuentra en estado de cambio y hay muchos diferentes problemas que las herramientas de requerimientos están intentando resolver.
El mercado de software de definición y administración de requerimientos tuvo ventas de 207 millones de dólares en el 2008, 7% por encima de los 194,2 millones de dólares del 2007. Ballou proyecta que a la luz del actual clima financiero, este mercado crecerá a 290,6 millones de dólares para el 2013. La creciente complejidad y criticidad de los sistemas y aplicaciones de software, y las incesantes presiones empresariales por la relevancia del software, su adaptabilidad, trazabilidad del cumplimiento y un menor time to market continuarán impulsando la demanda de soluciones interactivas de requerimientos, escribió en un reporte de análisis de mercado.
El desafío principal para iRise, afirma Ballou, es hacer que su software administre y reutilice todos los artefactos creados en sesiones iterativas de diseño de aplicaciones conjuntas para objetos comparables, aunque ella afirma que espera que futuras versiones de la aplicación se encarguen de ese tema.
Desde el inicio
La compañía de transporte de paquetes United Parcel Service Inc. (UPS) ha encontrado que trabajar con sus usuarios empresariales en requerimientos de sistemas tiene sus beneficios, señala Mark Hilbush, vicepresidente de Sistemas de Información. La idea es conseguir todo lo que se pueda y trabajar con los usuarios de la empresa de tal forma de que ellos puedan realmente entender qué estamos construyendo juntos, afirma. Ese enfoque ha producido beneficios que incluyen permitir a las personas que no hablan inglés ver el software y asegurarse de que no se hayan dejado de lado los requerimientos importantes, sostiene.
El grupo de Hilbush está construyendo una aplicación web que reemplazará a una aplicación mainframe de procesamiento de paquetes y será usada en las operaciones de UPS en todo el mundo. Usando la herramienta Studio de iRise, TI ha podido modelar diferentes aspectos de la interfase de usuario con paneles, entrada de datos, reportes y otras capacidades, señala.
Podíamos poner la visualización frente a los usuarios que se encuentran en todo Estados Unidos y Europa y la región Asia Pacífico, y [iRise] nos permitió que mucha más personas se involucraran en el proceso de requerimientos que los que normalmente se involucran, explica Hilbush.
No solo TI pudo descubrir requerimiento desde un inicio -que la gerencia no hubiera podido articular- sino que la herramienta le permitió al grupo de Hilbush tener un feedback directamente de las personas que iban a usar el sistema diariamente, para ver como satisfacía sus necesidades. Lo último que quieres es llegar a las evaluaciones alfa, beta o de usuario y darse cuenta que haz dejado de lado algunos requerimientos fundamentales, sostiene. Ese es el poder de la visualización, te permite hacer esto en el inicio del ciclo de vida.
La herramienta de iRise ha sido de mucha utilidad en términos de mejorar la calidad, ya que el inglés no es el idioma materno de todos los que dan input, señala Tony Baldassari, gerente senior de proyecto del Package Project Management (PPM) Group de UPS. Si tenía que solicitar comentarios de los usuarios internacionales en un documento de requerimientos, las cosas inevitablemente se hubieran podido perder en la traducción. Pero enviar un prototipo les permite a las personas visualizar cómo se ve el sistema y por tanto ayudar a asegurar que se haga bien desde un inicio, señala Baldassari.
Hay una mejora en el proceso desde ese punto de vista: no tenemos que tener un montón de correos electrónicos con comentarios y sostener llamadas en conferencia para revisarlos, explica. Pero la mayor de las mejoras es en la calidad del producto que sale en la versión 1.
La nueva aplicación de UPS, un sistema internacional de procesamiento de operaciones usado para revisar las cargas de país a país, ha sido examinada muchas veces. Las personas han podido ver todas las partes visuales, incluyendo las pantallas, enlaces, cómo navegarían a través de las páginas, y el verdadero look and feel, sostiene Baldassari.
Una vez que los usuarios emiten sus comentarios en iRise, su grupo reúne el feedback, lo consolida y vuelve a trabajar en el diseño antes de enviar otra ronda de pantallas para revisar. Nos permite realizar iteraciones muy rápido y obtener feedback y comentarios, si se requiere, una tercera ronda. Para cuando hemos hecho esto, estamos muy seguros que tenemos una muy buena aceptación de todos los usuarios, señala Baldassari. Finalizamos esto con TI, y ahorra tiempo en el ciclo de desarrollo.
El sistema va a salir en 12 fases, la mayoría de las cuales tienen interfases de usuario. Habrá dos o tres revisiones por fase, sostiene Hilbush. El proyecto comenzó a inicios del 2010 y la primera fase irá en vivo (go live) en el tercer trimestre de este año. La segunda fase irá en vivo en el cuarto trimestre de este año.
El mensaje fundamental que los miembros del equipo del proyecto recogieron fue que en algunos casos, hay pasos en los paneles que hubieran complicado las cosas a los usuarios y sería difícil que encajaran en sus procesos de negocios, afirma Hilbush. La meta de los paneles es darle al usuario empresarial una vista rápida del desempeño de sus operaciones, incluyendo gráficos de tendencias sobre el manejo, clasificación y movimiento/transporte de los paquetes.
UPS usa iRise como parte del proceso de reunión de los requerimientos tanto para los sistemas que serán usados dentro de las compañía como para las aplicaciones que los clientes de UPS usan vía la web. Funciona bien en casi cualquier tipo de sistema que tenga interfase de usuario, afirma, y en el 2009 fue usado en 43 proyectos de 47 que fueron identificados como candidatos potenciales para iRise. Nuestra filosofía es que si tienes una aplicación web o Windows -o una aplicación con una interfase de usuario- tienes que tener una muy buena razón para no usar la visualización en ese proyecto, sostiene Hilbush.
Aunque no ha dado detalles sobre el costo de implementar iRise, Hilbush señala que UPS ha tenido un retorno sobre su inversión en el software porque redujo el número de cambios generados durante el ciclo de vida del proyecto, y redujo el número de defectos posteriores en el desarrollo.
Un producto como iRise no reemplaza a la usual reunión de requerimientos funcional y otros pasos tradicionales que se toman durante el ciclo de desarrollo, añade Hilbush.
Lecciones aprendidas: si no se usa se olvida
En el MD Anderson Cancer Center, los trabajadores han estado usando iRise para desarrollar un sistema de registros médicos electrónicos (electronic medical records - EMR) llamado Clinic Station. Y ahora el hospital ha comenzado a utilizar la herramienta iRise dentro de varios departamentos para crear un mejor workflow en otros procesos, y permitir al personal que tenga más tiempo para trabajar con los pacientes.
Como hospital especializado en el tratamiento del cáncer, el MD Anderson encontró que los sistemas EMR con requerimientos pre definidos no satisfacían sus necesidades, porque estos paquetes están diseñados para centros específicos, señala Sherry Preston, gerente analista de negocios del equipo de desarrollo y soporte de EMR del MD Anderson. El hospital pasó unos ocho años intentando personalizar tres diferentes herramientas de EMR, pero ninguna funcionó. El monstruo es el workflow, señala.
Por tanto, la gerencia del hospital decidió desarrollar su propio y único sistema y capacitar a los médicos como ella -que entienden los matices de la enfermería, farmacia, laboratorios, rayos X, y registros médicos- para que se convirtieran en analistas de negocios y trabajaran con los usuarios finales para obtener input sobre los diferentes módulos que deseaban que interactúen con Clinic Station. Era importante porque teníamos que estar en capacidad de documentar y obtener los requerimientos y entender el workflow de cada rincón del hospital, explica Preston, que ha trabajado como enfermera en el MD Anderson por 26 años.
Como parte de este trabajo de EMR más amplio, a finales de la primavera [septentrional] de este año Preston comenzó a trabajar con el departamento de Scheetz para entender sus procesos de workflow y para aprender exactamente la forma en que el grupo da prioridad y maneja las órdenes de terapia física luego de que las órdenes son dadas por los médicos. Scheetz afirma que uno de los desafíos que enfrentan es que generalmente tienen que validar de que en realidad hay una orden firmada por un médico, y ese puede ser un proceso manual y laborioso. Se está desarrollando un nuevo sistema de órdenes médicas para automatizar ese proceso, y las visualizaciones en iRise indican que asegurará que hay una orden firmada.
Los funcionarios actualmente están esperando que el sistema de órdenes médicas sea integrado con Clinic Station, y Scheetz afirma que eso sucederá en los próximos meses. Cerca de 15 mil empleados tienen acceso a Clinic Station. El equipo de Preston usará iRise a continuación para añadir un sistema de ingreso de órdenes de recetas a Clinic Station.
Preston estima que el hospital gastó menos de 300 mil dólares para comprar iRise. Señala que hay poco en la herramienta que no le guste a los usuarios, además del hecho de que aprender cómo funciona lleva una significativa cantidad de tiempo y si no lo usas te olvidas, ya que la herramienta requiere de varios pasos. El hospital tiene cerca de 17 analistas de negocios que usan iRise frecuentemente.
Hay algunas otras cosas que hay que tomar en cuenta si está planeando usar herramientas de visualización de software. Preston señala que usar iRise requirió que el MD Andersen comprara más memoria para las laptops de los analistas de negocios. Y fue importante implementar iRise en las laptops porque los analistas generalmente usan el software de iRise en reuniones con los usuarios. La necesidad de más memoria nos tomó por sorpresa porque no lo planeamos por adelantado, explica Preston.
Por su parte, Hilbush de UPS señala que una lección fundamental que aprendimos es que necesitas hacer la simulación de iRise tan pronto como sea posible en el ciclo de desarrollo, y necesitas incluir tanto a los usuarios como a los desarrolladores; es el analista de negocios quien generalmente hace la simulación de iRise. Debido a que el analista de negocios es parte del equipo de desarrollo en UPS, los desarrolladores generalmente se encuentran involucrados, por tanto no se desperdicia su creatividad. Si se hace bien, el proceso es muy abierto y colaborativo, señala Hilbush.
MD Andersen ha reducido cerca del 25% de su tiempo de desarrollo total usando la simulación, señala el Dr. Lynn Vogel, vicepresidente y CIO, y añade: nuestro sueño sería que la simulación generara todo el código. Pero ese es un proceso muy difícil. Hacer el código es más arte que ciencia.
Esther Shein, Computerworld (US)