Espacios. Vol. 32 (2) 2011

Carlos Antonio Tonini*, Mauro de Mesquita Spinola** y José Manuel Cárdenas Medina***

Contenido

1. Introducción

Gran parte de las actividades humanas depende de aplicaciones de Tecnología de Información (TI), obligando a que los software sean desarrollados cada vez más rápido, de forma eficaz y a bajo costo. El cliente desea que el software funcione siempre y de forma correcta y, en caso de falla, espera que el desarrollador rápidamente corrija el error, independiente del grado de dificultad del motivo de la falla (Fenton y Pfleeger, 1997).

Paralelamente, la cantidad de desarrolladores creció considerablemente, estimulada por altos retornos de negocio y una demanda creciente. Consecuentemente, la competencia se incrementó y sofisticó, independientemente del tamaño de la organización o del volumen de sus negocios. Por otro lado, la estrategia de diferenciación, que predominó en la década de 90, da lugar a cuestiones de calidad, costo y atendimiento, como elementos decisivos para la sobrevivencia. La competitividad en el mercado de software se tornó dependiente de mecanismos que conduzcan a un nivel, más alto, de calidad y productividad. De modo que, los desarrolladores tienen que buscar mejoras en sus procesos de trabajo, traducidas en menores costos percibidas, como tal, por los clientes (Fernandes y Abreu, 2006).

Los modelos de planeamiento estratégico empresarial realzan la necesidad de un dinamismo en la interacción proceso-mercado y consideran que la capacidad creativa del staff es el elemento clave para la mejora continua en los procesos y para a sobrevivencia empresarial, una vez que es necesario que la propia organización descubra sus propias fuerzas y debilidades para generar ideas y conocimientos necesarios (Mintzberg y Quinn, 2001).

Los principales modelos de referencia de gobernanza de TI presentan vías para que los desarrolladores de software, partiendo muchas veces de una situación de extrema falta de control alcancen la plena madurez en los sus procesos. Estos modelos enfatizan los principios de Ingeniería de Software y de Calidad, destacando como factor crítico el establecimiento y el cumplimiento estricto de un método de desarrollo, aunque este acepte cierto grado de flexibilidad (Chrissis et al, 2003). En otras palabras, la organización necesita poseer un fuerte control a través del ciclo de vida del desarrollo de software, procurando mitigar los riesgos y evitar que eventos inesperados interfieran en el éxito del proyecto. Gerenciar riesgos es una actividad primordial para el éxito de los proyectos y los procesos de trabajo deben ser lo más simples posible, en termos de principios, técnicas, métodos y herramientas. La ausencia de simplicidad crea barreras que inhiben sus aplicaciones, haciendo difícil la identificación de las estructuras más importantes y desestimulando cualquier esfuerzo de mejora.

Diversas investigaciones muestran que la mayoría de los proyectos de implementación de los modelos de mejora en los procesos ha fallado por una serie de razones, tales como: estrategias no definidas claramente, falta de compromiso de las personas, desalineamento estratégico, falta de persistencia, desorganización y falta de creatividad en adaptar el modelo a las características de la empresa. Por otro lado, mismo que una organización adopte un modelo de mejoría de procesos, esta debe considerar que los modelos son apenas simplificaciones de la realidad y, por esta razón, son apenas descriptivos, esto es, presentan un conjunto de ideas que canalizan la creatividad empresarial, sin necesariamente que esto sea una “receta” para el éxito. Si fuese así, todas las organizaciones que atendiesen el modelo, alcanzarían el éxito igualmente (Card, 2002).

La cuestión colocada por este trabajo es la de investigar si existe alguna relación entre el control de los procesos de desarrollo de software y los esfuerzos de innovación de la empresa. Para esto, fue montado un cuadro teórico de referencia tomando como base el concepto de innovación, las características del proceso de desarrollo de software y las recomendaciones de los modelos de madurez. Con esto es definido claramente el problema de pesquisa y formulada la proposición de que la innovación es condición básica para que la organización alcance madurez en el desarrollo de software.

El artículo presenta también los resultados de una investigación de campo, realizada en forma de un Estudio de Casos Múltiples involucrando dos organizaciones desarrolladoras de software con características diferentes. Mientras una de ellas atiende un cliente único y prioriza la estabilidad de sus procesos, la otra atiende el mercado en general y mantiene diversas líneas de productos para arquitecturas distintas.

El estudio muestra que en los casos analizados, la creatividad es una de las aptitudes necesarias del gestor, de forma que este pueda conducir innovaciones tanto en proceso de desarrollo de software como dentro del producto software, disponible para el mercado.

2. Fundamentación teórica

Desde que la General Electric (GE) en la década de 90 atribuyó sus altos lucros a la adopción de la filosofía Seis Sigma para el control de sus procesos de trabajo, diversos autores han discutido la cuestión de si existe conflicto entre eficiencia y creatividad (Hunter y Schmidt, 1999) (Marash, 2000).

Para algunos, una estrategia gerencial disciplinada y cuantitativa, que busca aumentar significativamente el lucro de las organizaciones, a través de la optimización y estandarización del proceso de producción, garantizando una alta calidad de los productos antes que direccionar esfuerzos para crear nuevos productos e innovar los procesos productivos (Blakeslee, 1999). Para otros, los esfuerzos de mejora deben tener la función de satisfacer completamente, y con lucro, las necesidades de los clientes, lo que se traduce en acertar “el blanco” establecido por ellos mismos, con mínima variación y desperdicio y, para esto, todos los procesos pueden ser mejorados (Allway y Corbett, 2002).

2.1. Proceso de innovación

El hecho de atender las necesidades de los clientes es una estrategia vital para la continuidad de cualquier negocio. La formulación de estrategias debe estar basada en las competencias esenciales, que son los aprendizajes colectivos de la organización relacionados con la coordinación y uso de las diversas herramientas de producción y, la ejecución de los procesos de trabajo, aprovechando e integrando las múltiples corrientes tecnológicas disponibles en su ramo de actuación (Prahalad y Hamel, 1990).

La competitividad que tiene efecto positivo es aquella que sabe como determinar racionalmente la capacidad de competir haciendo converger de forma efectiva la capacidad y habilidad empresariales (puntos fuertes y débiles de la organización) con las oportunidades señalizadas por el mercado (Zairi, 1997).

Esto significa que todo y cualquier cambio en la relación empresa–cliente o también obtención de ventajas competitivas debe ser realizado de forma planeada y basada en hechos, exigencias, sugerencias o desafíos de mejora. Este principio llama la atención para la racionalidad de todo y cualquier cambio, la cual está directamente vínculada a la capacidad de competitividad de la empresa (Ansoff y McDonnell, 1984).

Consecuentemente, innovar consiste en la transformación de una idea o de una oportunidad en un conjunto de acciones internas (proceso productivo) produciendo algo nuevo y diferente (innovación en el producto) o modificando total o parcialmente la forma de hacer (innovación en el proceso). Las innovaciones radicales provocan cambios en la organización, en los clientes y en la relación entre ambos; las innovaciones incrementales son inherentes al proceso y continuas a lo largo del tiempo (Dodgson y Griffiths, 2004).

Los factores que más influyen en la intensidad de la innovación son: la urgencia y la importancia que esta representa para el cliente interesado, el grado de complejidad tecnológica involucrada para transformar la idea en realidad y el retorno que esta proporciona para la organización que la implementa (Goffin y Pfeiffer, 2001).

La innovación de un producto o servicio debe ser entendida también como un proceso, pues se fundamenta en una base de conocimiento, experiencia y usos ya existentes. Las principales fases del proceso de innovación son las siguientes (Tidd et al., 2005):

Muchas veces, los términos creatividad e innovación son tratados como si fuesen sinónimos. Esto se debe al hecho de que la creatividad es una de las aptitudes más importantes que el empresario de software tiene a su disposición para innovar tanto en el producto ofrecido, como en el proceso de desarrollo. De esta manera, es bastante probable que el “espíritu innovador” sea lo que distingue una empresa común de una emprendedora. El “ser emprendedor” exige que la empresa se oriente por la observación incansable de otros negocios, asociación de ideas, éxitos y fracasos (Bresnahan y Malerba, 1999) (Brisolla, 2001).

Bajo la óptica financiera, las actividades de innovación forman dos ciclos – lanzamiento y producción – siendo que cada cual contiene una carga inevitable de costo. Estos ciclos, conforme muestra la figura 2, están marcados y delimitados por los siguientes eventos:

1 – oportunidad, 2 – percepción, 3 – investigación, 4 – definición, 5 – entrega, 6 – aprobación y 7 – extinción (Patterson, 1998).

La innovación en el desarrollo de software sucede de dos formas básicas. Para expandirse en el mercado de forma horizontal, la empresa debe promover innovaciones radicales en su producto de software o sino, innovaciones incrementales caso posea un monopolio bastante consolidado. Por otro lado, una innovación puede aparecer en el mercado, de forma vertical, pero en este caso, la innovación está más posiblemente ligada con una forma incremental (Frick y Nunes, 1996).

De forma general, la investigación aplicada y el desarrollo de tecnología son financiados y realizados, en su mayoría, por las empresas, cabiendo a la universidad, con el apoyo del gobierno, apenas una pequeña parte y responsabilidad con el desarrollo de la pesquisa básica. Esta división de tareas no es una idea nueva. Francis Bacon (1561-1626), en la creencia de que la ciencia llevaría al desarrollo de tecnología y a la producción de riqueza, propuso que el apoyo del Estado a las actividades de investigación académica era fundamental. Esta idea fue desarrollada mas tarde dando origen al conocido Triángulo de Sábato y la Hélice Triple de Relaciones Universidad-Industria-Gobierno (Plonski, 2005).

En la práctica, el gobierno brasilero ha estimulado la mejoría de la calidad de los procesos de software, principalmente a través del programa de Mejoría de Proceso de Software (MPS.BR), que se ha convertido en una guía de referencia y requisitos para que las organizaciones alcancen altos niveles de calidad y madurez en sus procesos. Cada nivel de madurez es una conjunción de procesos y capacidad de estos, o sea, está compuesto por un conjunto de procesos en un determinado nivel de capacidad. Los procesos y las capacidades de estos están descritos según las normas ISO/IEC 12207, y sus enmiendas 1 y 2, e ISO/IEC 15504-5. El progreso y el atendimento del nivel de madurez se obtienen cuando son atendidos todos los resultados y propósito del proceso; y los atributos de proceso relacionados a ese nivel. Los niveles de madurez establecen estadios de evolución de procesos, caracterizando escalas de mejoría de implementación de procesos en la organización. El MR-MPS define siete niveles de madurez: A (En Optimización), B (Gerenciado Cuantitativamente), C (Definido), D (Ampliamente Definido), E (Parcialmente Definido), F (Gerenciado) y G (Parcialmente Gerenciado). El nivel G es el inicial, indicando que este es más inmaduro que los demás niveles, y el nivel A es el más maduro. Los niveles de madurez del MR-MPS tienen un paralelo con los cuatro niveles de madurez de la representación por escala del CMMI (niveles 2 a 5), siendo los niveles F, C, B y A del MR-MPS correspondientes respectivamente a los niveles 2, 3, 4 y 5 del CMMI. El nivel G es un nivel intermedio entre los niveles 1 y 2 del CMMI y los niveles E y D son dos niveles intermedios entre los niveles 2 y 3 del CMMI (Chrissis et al, 2003).

2.2. Procesos de desarrollo de software

Los productos de software forman actualmente los mayores componentes del presupuesto de muchas organizaciones, lo que las lleva a exigir un alto nivel de calidad y capacidad para absorber mayores funcionalidades.

Sin embargo, los Informes del Standish Group (Chaos, 2000) demuestran que la producción de software en el mundo aun tiene mucho espacio para mejorar tanto en términos de proceso cuanto en términos de calidad, pudiendo ofrecer productos a costos mucho mas atrayentes. La tabla 1, muestra que aun cerca de un cuarto de los proyectos no son concluidos y que, aproximadamente la mitad es entregada con fallas.

Resultado de Projetos	1994	1996	1998	2000
Entregados con éxito	16 %	27 %	26 %	28 %
No entregados por falla	31 %	40 %	28 %	23 %
Entregados con falla	53 %	33 %	46 %	49 %
Fuente: Standish Group - Chaos (2000)

Tabla 1 – Distribución porcentual de proyectos de desarrollo de software

Según Pressman (2004), las principales fallas están relacionadas con el no entendimiento de requisitos (el software hace lo que no debe o no hace lo que debe hacer), con el costo encima de lo presupuestado y con atrasos en la entrega. Estos datos traducen también, en grande parte, la falta de madurez de las organizaciones. En este sentido, la tabla 2 muestra las principales características de los dos tipos extremos de procesos de desarrollo de software (Paulk et al., 1997).

Proceso Inmaduro	Proceso maduro
No es rigurosamente seguido	Consistente con la manera en que el trabajo es realmente ejecutado
El cumplimiento no es controlado	Definido, documentado, comprendido, utilizado, vivo y activo.
Baja visión del progreso	Tiene el apoyo visible de la alta administración y otras gerencias
Baja visión de la calidad del producto	Bien controlado – fidelidad al proceso es objeto de auditoría y de control
La calidad y las funcionalidades pueden quedar mas cerca de lo negociado para cumplir el plazo	Uso disciplinado de tecnología
Es arriesgado, si hubiera cambios en la tecnología	El proceso y el producto son medidos regularmente
Proceso improvisado por profesionales y gerentes	La cultura organizacional transmite el proceso
Elevados costos de manutención	Procesos institucionalizados permanecen, mismo después que las personas que lo definieron, dejan la organización.
Fuente: Paulk et al. (1997)

Tabla 2 – Características de los dos tipos extremos de procesos

El paradigma tradicional de desarrollo de software, conocido como “ciclo de vida”, fue concebido de forma a mostrar la secuencia de realización de las actividades (entendimiento de los requisitos, modelaje, codificación y pruebas). Las actividades son organizadas en etapas que deben ser ejecutadas en el orden previsto y asocian los métodos, las herramientas y los procedimientos necesarios para la ejecución. Los modelos especifican o una estructura de alto nivel apenas (modelos estructurales) o detallan mas pormenorizadamente los procedimientos (modelos procesales). La elección del modelo más adecuado depende de la naturaleza del proyecto, de los métodos adoptados, de las herramientas a ser utilizadas, de los controles y de los productos deseados y de la infraestructura computacional (Pressman, 2004).

Este paradigma obliga a los desarrolladores a respetar las fases de desarrollo sin rutas alternativas. Como el insumo para la próxima fase depende del resultado de la fase anterior y, así sucesivamente hasta el producto estar concluido y, existe la posibilidad de haber mas de una persona involucrada, es necesario un rigor mayor en la documentación del trabajo ejecutado además del propio trabajo realizado.

La popularización del uso de los recursos de TI, las facilidades ofrecidas por el ambiente WEB y la difusión del sistema operacional Linux con la permisividad de uso y implementación de nuevos componentes estimularon el crecimiento de la cantidad de software escrito sin cualquier formalidad o rigor (Poppendieck, 2001). Paralelamente, es lanzado el “manifiesto ágil” proponiendo una nueva metodología para desarrollo de software, realzando la importancia de los individuos y de las interacciones sobre los procesos y herramientas, del funcionamiento del software sobre la documentación completa y detallada, de la colaboración con el cliente sobre a negociación contractual y la adaptación a los cambios sobre el plan original de trabajo (Cohn y Ford, 2003).

La elección de una representación afecta directamente la forma como un equipo de desarrollo es estructurado, cuando y como los miembros de este equipo interactúan, quien tiene autoridad y quien es responsable por cada parte (Costa, 2003).

2.3. Modelos de madurez

Si la globalización en la industria de software es una realidad, la estrategia de garantizar la satisfacción del cliente, cumpliendo el objetivo, plazo y costo, es bastante razonable. Por esta razón, obtener un certificado de calidad ayuda a demostrar la calidad al cliente. el certificado es una manera de seleccionar proveedores y, muchas veces, es un pre-requisito para el comienzo de un nuevo negocio. Tener el certificado no es garantía de buena calidad, pero no tenerlo, es una desventaja competitiva (Card, 2002).

Según este raciocínio, en la década de 90 surgió un consideráble número de modelos, normas y mejores prácticas en el campo de TI. Entre estos, el más notorio y de mayor utilización mundial, es conocido como “Modelo de Madurez de la Capacidad” o simplemente CMM (Capability Maturity Model). Este modelo fue originado a partir de un framework idealizado por Watts Humphrey en los años 80 para que el Software Engineering Institute (SEI) pudiese seleccionar proveedores de software cada vez mas calificados y capazes de cumplir sus contratos junto al Departamento de Defesa Norte-americano (US DoD), uno de los mayores compradores de software del mundo (Fenton y Pfleeger, 1997).

La calidad de un software es altamente influenciada por la calidad del proceso utilizado en su producción y manutención. De esta forma, un proceso bien controlado y maduro evita sorpresas y minimiza los riesgos relacionados con la calidad, costo y plazo, lo vuelve robusto para verificación por parte de terceros (Sarker, Sarker, 2009). La importancia de la calidad del proceso de producción ganó un gran destaque en el mundo entero, suscitando la elaboración de un modelo de referencia, el CMMI - Capability Maturity Model Integration, que clasifica las organizaciones en determinados estadios de madurez (Fernandes y Teixeira, 2004) (Santana et al., 2009).

Aunque ninguno de los conceptos fuese nuevo, la idea en si era original y única: integrar la disciplina de software junto con las mejores prácticas de la calidad total dentro de una escala evolutiva de maduración, como muestra la figura 2(a), que pudiese no sólo distribuir el esfuerzo de mejora en etapas, como también servir para direccionar inicialmente los puntos más críticos (barreras) de los programas de mejora.

El Capability Maturity Model Integration (CMMI), actualmente en su versión v1.2, es resultado de la evolución de la família CMM, para la cual, la capacidad describe los resultados esperados después de la aplicación de un proceso de software en la organización y la madurez representa el potencial de crecimiento de la capacidad, bien como indica la riqueza del proceso de software y la consistencia del mismo cuando replicado para otros proyectos. El modelo clasifica la madurez en cinco niveles, considerando un número posible, finito y conocido; para enfrentarse con un número posíble, finito y tangíble de problemas típicos suscitados por la ingeniería de software, dando así oportunidad a las organizaciones de crecer (madurar) sus capacidades de forma incremental, alcanzando niveles sucesivos de mejora cada vez mas sofisticados, conforme demuestra la figura 2(b).

Figura 2 – Concepción del modelo de la família CMM (adaptado de Fenton y Pfleeger, 1997)

El modelo CMMI trata la cuestión de la innovación de forma explícita solamente en el nivel 5, a través de acciones específicas de mejora continua con base en el entendimiento estadístico de los resultados del conjunto de procesos de la organización o mismo del proyecto específico. Los objetivos de mejora de la organización son establecidos cuantitativamente y, continuamente monitoreados y revisados, de suerte a reflejar todos los cambios en los objetivos del negocio. Esto significa seleccionar y colocar en utilización solamente las mejoras incrementales e innovadoras, que de forma mensurable mejoren los procesos y tecnología de la organización. Las mejoras deben soportar los objetivos de calidad y desempeño de procesos de la organización, desde que sean derivados de los objetivos de negocio. O, en otras palabras, mejorar de forma consistente, gradual y con visibilidad para los negocios (Chrissis et al., 2003).

2.4. Cuadro de referencia

La innovación puede ser contraria a los hábitos, maneras y ritos establecidos por los procesos de trabajo, mismo porque las personas son resistentes a cualquier tipo de cambio. A pesar de aparentemente conflictivos, en verdad innovar y ser eficiente son acciones complementarias y sinérgicas, siendo que ambas son necesarias para el éxito sustentable de las organizaciones. La mejoría de la productividad, así como la manutención de la fidelidad del cliente, aumenta el lucro; las acciones de innovación mejoran la relación con el cliente, contribuyendo positivamente a conseguir fidelidad del mismo. La gestión de los negocios pasa a ser, entonces, la responsable por adecuar y alinear los esfuerzos en la mejoría de la productividad y acciones de innovación (Ansoff y McDonnell, 1984).

Para hacer realidad una idea innovadora, la empresa necesita creer e invertir en la idea, superando los obstáculos, enfrentando los riesgos y, una fuerte posibilidad de fracasar. (Tidd et al., 2005). Los esfuerzos de mejoría de la productividad no pueden ser implementados sin que sean adaptados a la realidad y a las características particulares de la organización y tampoco se aplican a todas las actividades. Los esfuerzos de mejoría en la productividad se aplican eficazmente en los procesos internos de características repetitivas. Para las actividades creativas, se debe preparar un ambiente propicio al florecimiento y considerar un margen de libertad adecuado (Ansoff y McDonnell, 1984).

El software es el resultado de una interacción, iteración y acuerdo intelectual entre usuarios y desarrolladores (Pressman, 2004) exigiendo de ambos creatividad para buscar la solución más adecuada. Como observado encima, el desarrollo de software, después de la idea formada, pasa a ser algo repetitivo y que prescriba las acciones siguientes.

Analizando los procesos de desarrollo de software (paradigma tradicional y nuevas tendencias) bien como las proposiciones del modelo de referencia CMMI, se puede admitir la proposición de que la innovación (lado creativo del software) es una condición básica para alcanzar mayores niveles de madurez. Debe haber una predisposición de la empresa para organizarse; independientemente del paradigma adoptado para su proceso productivo de software.

Madurez e Innovación en el desarrollo de software: convergencia o conflicto