79 Con base en la información referente a los modelos incluidos en el capítulo II de este trabajo, se observa que los modelos revisados tienen como tronco común la identificación de actividades generales que deben llevarse a cabo en cualquier desarrollo de software:
Inicio de la Implementación de Software.
Análisis de Requisitos del Software.
Arquitectura y Diseño Detallado del Software.
Construcción del Software.
Integración y Pruebas del Software.
Entrega del Producto.
Asignando éstos a diversos responsables a través de un prototipo de perfil especializado (analista, ejecutor de pruebas, líder técnico, etc.), y finalmente asociándolo al concepto de una estimación de esfuerzo en el transcurso del tiempo.
Cada modelo de trabajo dicta diversos alcances para cubrir la administración de las actividades durante el ciclo del desarrollo de software. Este alcance se clasifica a través de niveles. Cada nivel sugiere la cantidad de actividades a realizar, la documentación a completar ante cada requerimiento y la logística a seguir para alcanzar el cumplimiento del requerimiento en las fechas comprometidas; también este nivel indica una calificación de madurez en la atención de procesos en la empresa.
Las actividades sugeridas apoyan a una buena administración de los compromisos del equipo y facilita el trabajo ante un requerimiento de software entregado por el Cliente.
Una coincidencia más es cuando cada modelo de trabajo describe una metodología general donde se observan las actividades particulares que permite alcanzar el objetivo de forma ordenada, planeada y estructurada, habilidades que ayuda en gran medida a los equipos de trabajo con perfil técnico. Alcanzando el objetivo a través de diversas tareas recomendadas, medidas, técnicas, plantillas, roles y sub-modelos, entre otros.
Es necesario señalar que los modelos de trabajo sirven para atender dos tipos de requerimientos:
Los requerimiento del día a día (también conocidos como requerimientos BAU* por sus siglas en inglés) que son solicitados por los equipos de trabajo operativos, generalmente son paquetes de trabajo pequeños ya que se trata de modificaciones a piezas de software existentes, de poca complejidad y que demandan poco tiempo para realizar los cambios,
Existen también, los requerimientos estratégicos que generalmente son sistemas de módulos completos o de un producto completo, aquí el tamaño del alcance y la complejidad es mayor, y por lo tanto la inversión en tiempo también es significativa.
80 Entonces, dependiendo del tipo de requerimiento que el cliente entregue, será la cantidad de integrantes del equipo de trabajo durante el trabajo completo o en las diferentes etapas que demandará el desarrollo de software.
Otra peculiaridad importante es que cualquier modelo de trabajo enfocado al desarrollo de software puede ser utilizado para construir cualquier sistema informático sin que necesariamente se tenga que hacer uso de algún lenguaje de programación específico o tecnología particular (Mainframe, UNISyS, IBM, cliente/servidor), haciendo uso solo de las técnicas estratégicas para alcanzar el objetivo.
Pero existen algunas otras características que se identificaron en las certificaciones de los modelos estudiados en este trabajo, las cuales se comentarán en este capítulo.
3.1. Contenido metodológico de las Certificaciones.
Hoy en día, los modelos de trabajo se han enfocado a manejar sus sugerencias con base a la atención a través de proyectos, el cual consiste en equipos de trabajo temporales asignados y enfocados todos a alcanzar un objetivo requerido en una empresa.
Los modelos de trabajo para desarrollo de software se perfilaron a administrar las actividades de un proyecto bajo su propia metodología, enfocándose en las principales acciones que se deben llevar a cabo, sugiriendo buenas practicas que permitan controlar la ejecución exitosa de las actividades; pero todo perfilado a lo que el desarrollo de software requiere para construir un sistema informático de calidad.
Lo importante de administrar un producto de software a través de un modelo de trabajo de proyectos radica principalmente en la forma de conducir las actividades, el equipo de trabajo y los resultados parciales desde el comienzo hasta un final satisfactorio, involucrándose y cubriendo la parte técnica, administrativa y financiera.
La administración de proyectos de software es el primer nivel del proceso de Ingeniería de software, que permite hacer frente a problemas como: requerimientos incorrectos e incompletos, planificaciones que no se llevan a cabo, por una creencia equivocada de que es una pérdida de tiempo y los planes cambiarán de todos modos, y dificultades para estimar el tamaño y complejidad del proyecto de software.
Entonces se define un proyecto como: un conjunto de acciones que se planean a fin de conseguir una meta previamente establecida, para lo que se cuenta con una cantidad limitada de recursos (económicos, humanos, tiempo).
Todo proyecto, ya sea que tenga fines personales, profesionales o de investigación, posee una estructura dividida en fases o etapas que permitan alcanzar la meta u objetivo establecido.
81 Existen diversas etapas o fases por las que pasan los proyectos, pero los modelos de trabajo para desarrollo de software consideran principalmente las siguientes:
Inicio.- Consiste en realizar un diseño general, especificando completamente todo el funcionamiento del programa, tras lo cual la codificación (programación propiamente dicha) debería resultar inmediata.
Planeación.- Esta etapa se caracteriza por ser un período en el que establecen los objetivos a seguir y el modo en cómo se llevarán a cabo las acciones para lograr cumplirlos. En caso de que en el proyecto participen varias personas, es en esta etapa en donde deberán establecerse los roles de cada uno, así como también todo lo relacionado con los recursos con los que se dispone y la manera en que éstos serán utilizados.
Análisis de Requisitos del Software.- Debe quedar claro cómo debe realizar el programa las cosas que debe hacer. Las pruebas que comprueben la validez del programa se pueden especificar en esta fase.
Arquitectura y Diseño Detallado del Software.- Se debe descomponer el programa en partes de complejidad abordable y definición precisa de cada subconjunto que conformará la aplicación.
Ejecución.- Es aquella en que se realizan las acciones y tareas planeadas, y que representan la ejecución misma del proyecto. Se refiere a la ejecución de todo aquello que se organizó durante la fase previa de planificación.
Construcción del Software.- Es la implementación en un lenguaje de programación de las funciones definidas durante la etapa de diseño.
Integración y Pruebas del Software.- Es la prueba individual de cada subconjunto de la aplicación para garantizar que el software cumple con las especificaciones originales y para garantizar que los diferentes módulos que los conforman se integren.
Entrega o Puesta en marcha.- Es la fecha que deberá cumplirse en el tiempo que se estipuló en la etapa de planificación. De este modo, en ciertos casos se concretará con la entrega de la obra a un determinado cliente o la puesta en marcha de algún sistema que se ha desarrollado, respondiendo a las condiciones previamente acordadas.Además de todas las fases mencionadas, a fin de llevar por el camino del éxito a un proyecto, quien se encuentre a cargo podría implementar algún sistema de control, es decir, algún modelo de trabajo con el que a lo largo de todas las etapas pueda ir monitoreando los avances
82 del proyecto de acuerdo a lo planeado, y así, poder realizar a tiempo las modificaciones que sean necesarias para lograr los mejores resultados y el logro de los objetivos.
3.2. Las Certificaciones orientadas a personas o empresas.
Las Certificaciones a Empresas consisten en revisar, validar y aprobar los procesos que realizan los equipos de trabajo dentro de las organizaciones, para alcanzar la calidad necesaria en las características del producto que será entregado al cliente.
Las Certificaciones a Personas consiste en preparar a cada uno de los integrantes del equipo de trabajo con los conocimientos necesarios en cada una de las actividades que el modelo sugiere realizar para alcanzar el objetivo trazado.
Las empresas desarrolladoras de software pueden certificarse directamente en un modelo de trabajo específico por las actividades que realiza, la documentación que genera y el proceso que ejecuta para alcanzar la calidad necesaria en la funcionalidad del software que le entrega al cliente; pero también puede certificar a los empleados que participan directa y/o parcialmente en cada una de las actividades que los modelos de trabajo sugieren llevar a cabo.
Para desarrollar esta tesis se tomaron certificaciones de ambos tipos, en la tabla 3.0.2. siguiente se indica el modelo de trabajo y el tipo de certificación:
ISO/IEC 29110 MoProSoft CMMI-DEV SCRUM ITIL
Personal
Empresas
Tabla 3.2.1. Orientación de las Certificaciones
Y aunque no es posible certificar una empresa o unidad de negocio “Conforme a ITIL”, si es posible que una organización que haya implementado las guías de ITIL sobre Gestión de los Servicios de TI puede lograr certificarse bajo la ISO/IEC 20000.
En caso contrario a ITIL, SRUM no logra alcanzar una certificación como empresa, es totalmente personal.
83 3.3. Certificaciones por tipo de modelo.
En los modelos de evaluación y mejora de la calidad de los procesos software se pueden encontrar dos maneras de hacer las evaluaciones: por niveles de madurez, donde se obtiene
una “puntuación” cuyo alcance es la empresa; y, por niveles de capacidad, o de manera
continua, donde la organización obtiene “puntuación” para un proceso concreto (gestión de requisitos, planificación de proyectos, gestión de la configuración, etc.)
La mayor parte de los modelos de trabajo certifican en los niveles básicos, intermedio y avanzado, sin embargo cuando más evolucionado y antigüedad tiene el modelo, entonces forman nuevos niveles con los que se apoyan para transferir a las empresas nuevos procesos que ayudan a estructurar el trabajo en sus actividades; tal es el caso de CMMI-DEV e ITIL. En la siguiente tabla 3.0.3. se observa qué nivel de certificación puede alcanzarse en cada uno de los modelos que se han considerado en este trabajo de tesis.
ISO/IEC
29110 MoProSoft CMMI – DEV SCRUM ITIL
N. Madurez N. Capacidad
Nivel 0 Incompleto
Básico Realizado Nivel 1 Inicial Realizado En Desarrollo Fundamentos Intermedio Gestionado Administrado Nivel 2 Administrado Master Intermedio
Avanzado Establecido Definido Nivel 3 Definido Dueño del producto Master Nivel 4 Predecible Administrado Cuantitativamente Experto Nivel 5 Optimizado En Optimización
Tabla 3.3.1. Niveles disponibles en los modelos de trabajo
Partiendo del hecho que entre menos complejo sea el requerimiento de software es mucho más fácil de adaptarse a cualquier modelo de trabajo; entonces cuando la complejidad es mayor en el requerimiento, por consecuencia el equipo de trabajo es extenso en número de integrantes y el modelo elegido debe también considerar un “nivel” de madurez mayor de la empresa y la experiencia en los integrantes del grupo de trabajo.
Scrum es recomendado principalmente para atender requerimientos sencillos, es un modelo de trabajo ágil que permite actuar en poco tiempo, por lo tanto los resultados también se ven en corto tiempo. Cuando los requerimientos son complejos y el equipo de trabajo utiliza Scrum, entonces el requerimiento se descompone en requerimientos pequeños, tantos como sean necesarios, y se van atendiendo estructuralmente. En esta estrategia la etapa de planeación es breve y nada compleja.
84 CMMI está perfilado principalmente para atender requerimientos complejos, entregando como resultado una incorporación integral en los procesos de las empresas, tal es la aceptación de este modelo que se ha convertido mundialmente en un requisito para acceder a la exportación de servicios de software.
ITIL es uno de los modelos de trabajo más socorridos, por incluir directamente en las buenas prácticas temas específicos para tratar la administración del software en diferentes momentos de su periodo de vida: cuando éste se encuentra en proceso de construcción, una vez que se encuentra implementado en producción y en el futuro, cuando surgen nuevas versiones. En el modelo se considera buenas prácticas para atender requerimientos sencillos pero también complejos. Sin embargo, una deficiencia de este modelo es que dicta los procesos que deben llevarse a cabo pero no indica cómo deben realizarse.
Una situación muy común es, cuando el trabajo del día a día de las empresas las orilla a elegir un modelo de trabajo, estas generalmente lo hacen con base a la fama que algún modelo y certificación tenga en ese momento en el ámbito, difícilmente se detienen a realizar un análisis de conveniencia y factibilidad.
Otra disyuntiva a la que las empresas se enfrentan es cuando revisan los procesos y las buenas prácticas que sugieren los modelos de trabajo y se ven convencidas por más de uno, entonces las empresas pueden decidir implementar más de un modelo de trabajo en el área de desarrollo de software, dependiendo de los tipos de requerimientos que la empresa atienda y el tamaño de ésta misma.
Es muy común que en las pequeñas y medianas empresas se adopte el modelo de trabajo que uno de sus empleados, generalmente el responsable del área, conoce y le ha dado algún resultado efectivo en el ámbito del desarrollo de software.
ITIL es uno de los modelos más veteranos y con mayor demanda para adquirir la certificación, tan solo en el 2010 y a nivel mundial se tiene registrados 274,507 exámenes de todos los niveles. Y desde el 2008 a la fecha se tiene registrado alrededor de 894 mil exámenes a nivel mundial.
CMMI es uno de los más estrictos con respecto a su implementación, y para Julio de 2012 se tiene registradas solo 4,031 de certificaciones alrededor del mundo, de las cuales 94 corresponden a México y solo 8 certificaciones del nivel 5. De las 94 certificaciones en México, cuatro son compartidas con empresas en ubicadas en Colombia, Estados Unidos y la India. En Septiembre del 2007, la empresa Kernel Technologies Group S.A. de C.V. fue la primera empresa mexicana en alcanzar el nivel 2 de CMMI bajo la nueva versión del modelo para desarrollo de software versión 1.2.
MoProSoft tan solo tiene registradas 377 certificaciones a empresas mexicanas desde el 2003, teniendo cerca del 70% de las empresas en el nivel 2.
85 Desde su lanzamiento a mitad del 2012, ISO/IEC 29110 no tiene registrada ninguna empresa certificada y sólo unas cuantas se encuentran en proceso de implementación en México. Vale la pena comentar que la certificación ISO/IEC 29110 y MoProSoft se encuentran basadas en el mismo modelo de trabajo, la diferencia entre ellas es que MoProSoft únicamente es reconocida en México, pero ISO/IEC 29110 tiene validez internacional.
3.4. Facilidades de Aplicación
La facilidad de implementar el modelo depende de muchos factores, pero específicamente los que se involucran para alcanzar una certificación en la adopción de un modelo de trabajo son:
La complejidad de desarrollos de software que atiende la empresa,
La cantidad de empleados que deben involucrarse para implementar la nueva técnica de trabajo,
El nivel que la empresa quiere alcanzar del modelo de trabajo seleccionado.
Pero las empresas siempre buscaran cuidar que el modelo de trabajo en el que se certifiquen cumpla con lo siguiente:
1. Evitar distraer el esfuerzo del grupo de trabajo del objetivo principal por aplicar la logística recomendada por el modelo, y
2. Evitar que el tiempo para generar documentación esté por encima del tiempo de atención hacia el requerimiento del Cliente.
Entonces primeramente, la empresa identifica el mercado al que se orienta y atiende, revisa cuál es el Modelo o Norma de Calidad más adecuado y el más solicitado por sus clientes. Posteriormente la empresa evalúa la situación interna actual de los procesos que se realizan y elabora una comparación con las exigencias del modelo de trabajo elegido. En muchos casos esta etapa es denominada “Gap Analysis” (Detección de brecha existente).
El resultado de este análisis ayudará a detectar las vulnerabilidades y los temas en los que se debe trabajar y/o afinar de los procesos internos, entonces se genera una planeación de un proyecto que permita corregir estas debilidades en los procesos, todo esto alineado al marco de referencia del modelo elegido.
Se debe tener presente que los procesos de los modelos de trabajo requieren de varios roles y perfiles. En el caso de las empresas pequeñas y con pocos integrantes, cada uno de estos integrantes deberán ejercer varios roles. En algunos casos se requiere que haya algún control cruzado de roles y tendrán que ser ejercidos por el pequeño grupo de trabajo.
Generalmente se contrata consultoría externa para implementar las mejoras requeridas por los modelos de trabajo, aunque podría sustituirse esta contratación por recursos internos de la empresa especializados y conocedores en el marco de referencia del modelo o norma elegida,
86 pero sobretodo con amplia dedicación en las actividades a ejecutar para implementar la mejora en los procesos internos, ya que estos servicios de conocimiento y dedicación son los que ofrecen las consultoras.
La contratación que no puede evitarse es la de la organización certificadora, que será la encargada de auditar los procesos de la empresa interesada, emitir el resultado de la evaluación y la certificación del modelo o norma elegida con una calificación resultante.
Otro factor que puede tener gran grado de influencia es la experiencia de la empresa interesada en la certificación, ya que eso determina el nivel de madurez de sus procesos y la organización de sus equipos de trabajo internos, así cuando se aplique la evaluación el Gap Analysis no arrojará demasiados cambios en los procesos y las correcciones a aplicarse serán breves, obteniendo fácilmente la certificación.
Con base al contenido de los procesos clasificados por cada nivel y que son señalados en el marco de referencia para los Modelos MoProSoft y CMMI-DEV, la empresa interesada en la certificación elige el nivel o la calificación que requiere alcanzar, cumple con los procesos que exige dicho nivel y se audita por parte de la entidad certificadora.
Para facilitar la implementación del modelo, se sugiere que entre menor experiencia se tenga en la administración de los procesos de la empresa también sea el nivel más bajo de certificación que se requiere alcanzar, de esta forma, el tiempo que demande a los recursos asignados para invertir en los ajustes a los procesos de implementación al modelo será breve y fácilmente de alcanzar una primer certificación.
Niv el d e Ce rt ifi ca ci ón 5 4 3 2 1 0 menos Experiencia más
Figura 3.4.1. Gráfica de esfuerzo para aplicar un modelo de trabajo con base a Experiencia de la Empresa vs. Nivel de Certificación del modelo de trabajo
La formalización de los procesos internos con respecto a los que demanda el modelo requiere trabajo adicional, el cual es inevitable. De todos modos el esfuerzo debería ser mayor al inicio, debido a que todo nuevo proceso requiere de una curva de aprendizaje y después tiende a
87 normalizarse, aunque dependerá en gran medida de la cultura y la urgencia de la empresa, la agilidad con la que logra la implementación y la certificación.
Para el caso del modelo SCRUM, que se encuentra enfilado a certificar personas y no organizaciones completas, esto se traduce en una fácil implementación del modelo de trabajo dentro de la organización y en los departamentos, ya que se puede permear poco a poco y a través de grupos de trabajo pequeños y por cada uno de los proyectos que se vayan ejecutando. El modelo resulta sencillo de usar ante requerimientos poco complejos, de ahí que se considere una administración ágil, entonces pudiera comenzase a adoptar primeramente en los requerimientos de tipo BAU. Empezando la preparación del modelo con un grupo pequeño de personas, asistencia a capacitación y cumpliendo con las certificaciones personales, para ir alcanzando resultados laborales en poco tiempo.
Por el contrario, ITIL sugiere una mayor cantidad de procesos para alcanzar las buenas