COMPUTERWORLD - Octubre 2010ESPECIAL SOFTWARE18El encuentro comercial de software y servicios de tecnología deinformación reunió a 34 compradores internacionales de nueve países y64 exportadores colombianos. Un evento organizado por Fedesoft,Proexport y la Cámara de Comercio de Bogotá.Según Proexport se realizaron 715 citas con un promedio de 10 agendascomerciales por cada uno de los empresarios nacionales, que llegaronde Bogotá, Medellín, Cali, Barranquilla, Bucaramanga, Manizales yPereira.Actualmente, el sector cuenta con alrededor de 700 empresas de lascuales el 48% se enfocan en desarrollo de software y servicios. Encuanto al tamaño, 59% corresponde a microempresas, 33% a pequeñasempresas, 7% a medianas y tan solo 1% son grandes.Las exportaciones de software crecieron durante el último año el 6%,alcanzando los 35 millones de dólares y los mercados con mayordemanda fueron: Ecuador, Estados Unidos, Costa Rica, Venezuela,Perú, Puerto Rico, Chile, México y Guatemala.Medellín, sede de SEPGProfesionales y expertos de la ingeniería del software y sistemas degestión de procesos, se concentrarán en Medellín, entre el 10 y 12 denoviembre, para participar en la conferencia “SEPG 2010”, en la cual seevaluarán nuevas estrategias que permitan mejorar la competitividad dela industria y el crecimiento de los negocios.El ministro de Comercio, Industria y Turismo, Sergio Díaz-Granados,destacó que es una conferencia de trascendencia para <strong>Colombia</strong>, debidoa que en la actualidad el desarrollo empresarial hoy se enfoca en lamejora de procesos en tecnologías de la información y en la definición deplanes de trabajo que garanticen la llegada de más inversión.Un Modelo para el Desarrolloy Soporte de Aplicaciones Hechas a la MedidaRoberto Sanz de Santamaría*Todas las organizaciones se enfrentan tarde que temprano a la decisión mejores prácticas se garantiza la correcta y completa documentación dede comprar o desarrollar alguna aplicación (software) para satisfacer sus los desarrollos así como un control estadístico de los procesos quenecesidades de negocio. Con frecuencia se inclinan hacia el desarrollo a permite analizar y subsanar causales de variación así como predecir ella medida argumentando que los requerimientos propios son demasiado comportamiento futuro de los procesos. Esto no es nada diferente deespecializados y que, por tanto, no existe ningún aplicativo estándar que poder estimar en forma precisa tiempos y esfuerzo de desarrollo.les sirva.Las compañías interesadas en hacer un desarrollo a la medida,Lo que desconocen o ignoran es que esos aplicativos estándares como llamémoslas compañías usuarias, pueden clasificarse en tres grupos:pueden ser SAP, Peoplesoft, JD Edwards, y Siebel, entre muchos otros,modelan procesos de negocio siguiendo buenas prácticas que han 1. Compañías sin capacidad técnica para adelantar o dar soporte a unresultado exitosas en miles de compañías y en cientos de países desarrollo. Es de esperarse que no cuenten con áreas oalrededor del mundo. Por tanto, la compra de un aplicativo de estos no departamentos de tecnología y que, por el contrario, dependan desolamente podría llegar a ser una solución para las necesidades personas o compañías externas que les prestan servicios deorganizacionales, sino incluso, una oportunidad de mejora para la misma administración de los sistemas y soporte.compañía.2. Compañías con capacidad mínima para desarrollar o dar soporte aun desarrollo. Típicamente tienen, 1 o 2 desarrolladores que hacenSin embargo, a pesar de la advertencia generalizada de evitar los parte de un área o departamento de tecnología de no más de 5desarrollos a la medida, en ocasiones no es posible hacerlo. El propósito personas.de este análisis es proponer un marco de desarrollo y soporte que 3. Compañías con capacidad suficiente para asimilar metodologíasminimice el principal riesgo asociado a los desarrollos a la medida: la formales de desarrollo y para mantener los ambientes mínimos dedependencia en el programador a través de todo el ciclo de vida de la desarrollo y pruebas. Para efectos prácticos estas compañíasaplicación.cuentan, o podrían llegar a contar, con una unidad desarrolladoraformal propia. Estas compañías no entran dentro del alcance de esteLos principales mitigadores del riesgo de dependencia en el documento.programador es la contratación con un proveedor sólido, serio ycompetente, y tener la custodia de las fuentes junto con una adecuada Si bien se esperaría que las compañías con capacidad técnica mínimadocumentación del desarrollo. La primera medida minimiza el riesgo de tengan una ventaja sobre las compañías que no la tienen, la existenciaenfrentarse al a necesidad de cambiar de proveedor, y la segunda, de dicha capacidad puede ser contraproducente si está mal orientada opermite la sustitución del proveedor con un mínimo de traumatismos. si obedece a agendas ocultas: la mejor manera de asegurar lapermanencia en el puesto es generar la dependencia en el programadorAdemás de este riesgo, que es el interés central de este documento, por un desarrollo mal documentado.existen otros costos ocultos que incluyen especificaciones deficientes,funcionalidad que no se ajusta a las necesidades, demoras en la entregadel desarrollo, altos niveles de defectos y documentación deficiente.Hoy en día se pueden minimizar todos los riesgos con metodologías1formales de desarrollo, tales como RUP (Rational Unified Process) y2modelos de madurez que definen mejores prácticas como CMMI(Capability Maturity Model Integration). Siguiendo estas metodologías yque las posibilidades para volver a <strong>Colombia</strong> atractiva como destino delITO (IT services), son evidentes.En el marco de la conferencia SEPG 2010, explicó Díaz-Granados, sehará énfasis en cómo la adopción de modelos de buenas prácticas en elsector de tecnologías de información es una realidad en muchas partesdel mundo y también de Latinoamérica, siendo éste uno de los mercadosen los que se observa un mayor crecimiento de compañías quesustentan su dinámica en la adopción de modelos de tecnologíasmodernas.SEPG 2010 está dirigida a profesionales dedicados a labores de mejorasistemática de personas, procesos y tecnologías en organizaciones enlas que el software es un elemento clave para lograr el éxito empresarial,resaltó el ministro.Durante la conferencia se abordarán, entre otros, temas como lacompetitividad y supervivencia en un mercado globalizado, la iniciaciónen la mejora de procesos, herramientas técnicas y conocimientos sobreel sector, y seguridad en ingeniería de software.SEPG es la principal serie de conferencias mundiales en software ysistemas de gestión de procesos, la cual también establece el punto dereferencia para la excelencia en las áreas de adquisición, desarrollo,mantenimiento, seguridad y servicios.La versión de este año también ofrecerá desarrollo profesional básico enla mejora de procesos a través de sesiones técnicas enfocadas entecnologías como CMMI, PSP y TSP, entre otras.Para alcanzar un mayor crecimiento del sector, el ministro dijo queespera lograr pronto la aprobación en el Congreso de la Ley deprotección de datos, la cual ya fue aprobada en un primer debate. “Estonos ayudará a aumentar las inversiones en el sector de BPO&O y en susegmento ITO.El alto funcionario destacó la demanda de servicios de procesos adistancia (BPO&O), segmento en el que se adelanta un plan de trabajo · Fuente Fedesoft: http://softwareytiencolombia.blogspot.com/en el marco del Programa de Transformación Productiva, y dijo también1El Proceso Unificado Racional (Rational Unified Process en inglés,habitualmente resumido como RUP) es un proceso de desarrollo de software yjunto con el Lenguaje Unificado de Modelado UML, constituye la metodologíaestándar más utilizada para el análisis, implementación y documentación desistemas orientados a objetos. (Wikipedia)2Integración de Modelos de Madurez de Capacidades o Capability Maturity ModelIntegration (CMMI) es un modelo para la mejora y evaluación de procesos para eldesarrollo, mantenimiento y operación de sistemas de software. (Wikipedia)
Los desarrolladores, independiente que sean un proveedor interno o Es claro que si el propósito es disminuir el riesgo de dependencia en elexterno, también se pueden clasificar en tres:programador para las compañías usuarias tipo 1 y 2, se debe situar en el1. Compañías unipersonales o empleados con un nivel técnico básico cuadrante superior derecho, unificando el desarrollo y soporte de losque desarrollan aplicaciones sencillas, con frecuencia utilizando desarrollos en una fábrica de software, es decir un desarrollador delmacros de Excel o Visual Basic for Applications y Excel o Access grupo 3. La compañía en esta situación ideal es la compañía G.como base de datos.2. Compañías de desarrollo pequeñas o programadores del área de Sin embargo, si esta fuera la situación ideal, porque ninguna de lastecnología, con máximo 5 desarrolladores. Con frecuencia presentan compañías estudiadas tienen el esquema mencionado? De hecho, poralta rotación de personal.qué no es un esquema común?3. Compañías desarrolladoras profesionales, o fábricas de software,típicamente con más de 10 años en el mercado, y más de 50 Típicamente un contrato de desarrollo y soporte requiere de un númeroprogramadores en múltiples proyectos de desarrollos de gran escala mínimo de horas para hacer rentable la permanencia del conocimientoutilizando metodologías formales de desarrollo.en la organización del proveedor.Lo que distingue a las compañías de desarrollo pequeñas de las fábricasde software, es que las segundas tienen economías de escala que lespermite invertir en la capacitación e infraestructura requeridas por lasmetodologías. Es la misma diferencia entre un taller artesanal y unafábrica automatizada en donde, si bien la segunda se beneficia deeconomías de escala, estandarización y mayores niveles deproductividad, también cuenta con unos costos fijos que la primera notiene.Por facilidad de administración de recursos, una fábrica de softwareusualmente evita repartir un recurso de desarrollo entre varios proyectospor lo que el número de horas mínimo para poder constituir el proyecto esde 160 horas mensuales.Un desarrollador pequeño, con una estructura de producción y de costosmás flexible requiere de un menor número de horas para hacer rentableel proyecto.Existen tres tipos de aplicaciones:La siguiente gráfica muestra los casos de un desarrollador pequeño1. Herramientas y utilidades. Se utilizan para el desarrollo de tareas comparado con una fábrica de software, en donde en el eje x se muestrabásicas o para agilizar y optimizarlas. Normalmente existen múltiples el número de horas efectivamente requeridas y en el eje y el costoalternativas disponibles. Windows, por ejemplo, trae dos aplicaciones mensual correspondiente. Esta gráfica se basa en datos reales.que sirven para la edición básica de texto: Bloc de notas y WordPad.2. Aplicativos de soporte. Son aplicativos de mayor complejidad que los Como la fábrica de software tiene una estructura de costos fijos mayor,anteriores, que no pueden ser reemplazados tan fácilmente, pero que resultará excesivamente costosa mientras las horas mensualessu interrupción no afecta procesos críticos de la compañía. Ejemplos requeridas no alcance el mínimo requerido, en el ejemplo, 120 horasson las aplicaciones de mesa de ayuda, control de horario de entrada mensuales. Sin embargo en la medida en que se acerca a las 120 horas,y salida, etc.la diferencia entre los dos esquemas disminuye.3. Aplicativos críticos. Su interrupción tiene un impacto importante enlos procesos críticos del negocio. La caída del sistema de un bancopor más de un día puede poner en peligro la existencia misma delbanco.Claramente la tolerancia al riesgo de dependencia en el programadorestá determinada por el tipo de aplicación, siendo los de mínimatolerancia los aplicativos críticos.Se hizo un estudio sobre 6 compañías usuarias pequeñas y medianas(grupo 2) del sector financiero. Las 6 compañías tienen uno o variosdesarrollos a la medida que requieren de soporte. La gráfica siguientemuestra la relación entre desarrollador y soporte encontrándose lamayor dependencia en la intersección de los ejes.Las compañías que se encuentran hacia el centro tienen uno o variosaplicativos desarrollados y soportados por desarrolladores pequeños. Lade mayor éxito es la compañía E que describe su experiencia así:“funciona medianamente bien en la medida en que tenemos soporte yniveles de servicio con costos controlados”. Se resalta la palabra“medianamente” indicando que la experiencia no es de satisfacción total.La compañía F tiene tres desarrollos. El proveedor de uno quebró yactualmente no tiene soporte. El del segundo reestructuró, disminuyó depersonal y sufrió un detrimento en la calidad de su servicio. El servicio deltercero nunca fue bueno.Las compañías C y D comparten el mismo proveedor de la página web.Dicho proveedor quebró hace dos años por lo que el manejador decontenido de la página no se volvió a actualizar. Las vulnerabilidades deseguridad permitieron que un hacker cambiara el contenido de la páginade uno. El otro aún está expuesto a la misma vulnerabilidad.La compañía A combinó desarrollo interno con múltiples proveedorespara, en sus palabras, “disminuir la dependencia en uno solo”. Es posibleque se logre la disminución esperada en la dependencia si elprogramador interno sirve de redundancia para las compañías. Pero almismo tiempo aumenta la dependencia en ese programador. Aparte deeso, no es una solución muy diferente a las de las compañías E y F.Finalmente la compañía B contrató a una fábrica de software para hacertres desarrollos importantes pero con la intención de darles soporteinterno. Para ese efecto ya contrató 4 programadores adicionales a los 2que se tenían para un total de 6. A pesar de que los programadores sonempleados de la compañía, por su número se asimilan a una compañíadesarrolladora pequeña. Por eso se sitúa cerca de la mitad de la gráficaen el eje Y.El reto para la compañía B, que no es una empresa desarrolladora desoftware, es alcanzar los niveles de eficiencia que podría alcanzar unacompañía especializada.En todos los casos en que se manejan múltiples proveedores,compañías A, E y F, hay un costo adicional correspondiente al desgasteen la administración de múltiples proveedores.A partir de las 120 horas, si la tarifa del desarrollador pequeño (línea azul)es inferior a la de la fábrica de software (línea roja), la brecha se vuelve aampliar a favor del desarrollador pequeño. Lo contrario sucede si la tarifade la fábrica de software es inferior a la del desarrollador pequeñopudiendo llegar a resultar más barata (línea roja punteada).Se encontraron casos en el mercado en que la tarifa horaria de la fábricade software es inferior a la del desarrollador pequeño.La dificultad es que una compañía usuaria del grupo 1 o 2, pequeña omediana, pueda acumular suficientes horas para superar el mínimorequerido por una fábrica de software. Para ello puede:· Concentrar la totalidad de desarrollo y soporte en un solo proveedor.· Unificar tecnologías y definir estándares para homogenizar losdesarrollos con el fin de minimizar los requerimientos del personalrequerido.· Programar los desarrollos de manera que se distribuyanuniformemente durante la vigencia del contrato.· Aprovechar la capacidad disponible para instaurar un proceso demejora continua de las aplicaciones.En la medida en que logre acumular las horas mínimas requeridas, sepuede contratar con un solo proveedor del grupo 3, o fábricas desoftware.El esquema propuesto indudablemente genera una concentración deriesgo en la fábrica de software por lo que el proceso de evaluación ycontratación debe ser muy cuidadoso. Adicionalmente deben contarsecon herramientas que permitan el desarrollo de una relacióntransparente y de confianza. Estas incluyen un contrato detalladodefiniendo claramente responsabilidades y expectativas así como elderecho a auditoría de los procesos y su documentación.De esta manera se alcanza el objetivo principal del ejercicio: ladisminución en la dependencia en el programador. Pero adicionalmentese logra:1. Mayor eficiencia / menores costos de desarrollo y soporte.2. Disminución en desfases de costos y cronogramas.3. Mejor calidad del producto.4. Mejoramiento continuo del producto.5. Centralización del soporte de las aplicaciones.6. Respaldo sólido para aplicaciones críticas.7. Optimización en la administración de proveedores.Desde el punto de vista de las fábricas de software, este enfoque abrenuevas oportunidades en el segmento de compañías usuarias pequeñasy medianas al tiempo que plantea nuevos retos. El principal reto es definirun marco de trabajo que le permita atender a un cliente cuyasnecesidades no alcancen el tiempo completo de un recurso. En nuestroejemplo, el cliente requiere 120 horas mensuales mientras que el númerode horas de un recurso de desarrollo por mes es de 160 horas.* Director de Tecnología, Titularizadora <strong>Colombia</strong>naCOMPUTERWORLD - Octubre 2010ESPECIAL SOFTWARE19