El objetivo de este art\u00edculo no es tanto la descripci\u00f3n de las diferentes metodolog\u00edas, como mostrar cu\u00e1les son sus \u00abprincipios activos\u00bb, porque al ser \u00e9stos\u00a0pocos y conceptualmente simples, conocerlos disipa la aparente complejidad y facilita su comprensi\u00f3n.\u00a0
<\/p>\n\n\n\n
Amenaza u oportunidad<\/h3>\n\n\n\n
Las empresas quieren producir m\u00e1s r\u00e1pido, mejor y con menor coste y el sector de las Tecnolog\u00edas de la Informaci\u00f3n y la Comunicaci\u00f3n tiene un especial atractivo para las iniciativas ambiciosas, pero hay que tener cuidado porque encierra riesgos importantes y es la forma de gestionar el desarrollo de los productos lo que hace del software una materia prima ingestionable, de resultados impredecibles o\u00a0una fuente de oportunidades.
La evoluci\u00f3n hacia entornos de ingenier\u00eda del software adecuados a la empresa puede generar tensiones con la cultura de la organizaci\u00f3n, adem\u00e1s del convencimiento, implicaci\u00f3n y empuje de la gerencia. Los mejores resultados se alcanzan con un modelo propio capaz de aprovechar las caracter\u00edsticas propias\u00a0de la organizaci\u00f3n y responder en la forma adecuada a las particularidades de su negocio.<\/p>\n\n\n\n
Gesti\u00f3n basada en procesos<\/h3>\n\n\n\n
Trabajar sin un m\u00e9todo fue la forma empleada por los primeros programadores cuando aparecieron los primeros ordenadores en la segunda mitad del siglo pasado. Los pioneros, atra\u00eddos por el encanto de dise\u00f1ar y construir artefactos \u00fatiles y verlos funcionar, fueron los primeros en sentarse frente al teclado y decir ilusionados: \u00aben un par de meses esto estar\u00e1 funcionando\u00bb.
Fueron tambi\u00e9n los primeros en pasar noches en vela programando, enga\u00f1\u00e1ndose una y otra vez con que \u00abtan s\u00f3lo es cuesti\u00f3n de un par de d\u00edas m\u00e1s\u00bb, demostrando finalmente que al programar sin un\u00a0 m\u00e9todo la probabilidad de obtener resultados de calidad en tiempos predecibles es escasa.
SEI, (Software Engineering Institute) denomina \u00abpoco maduras\u00bb a las organizaciones que desarrollan software sin un m\u00e9todo institucionalizado. Emplea una\u00a0escala de 1 a 5 para determinar el grado de\u00a0madurez y en consecuencia el nivel de garant\u00eda que se ofrece en cuanto a calidad, predictibilidad y eficiencia en el desarrollo de software.
Las organizaciones que trabajan sin m\u00e9todo tienen un nivel de madurez 1, que no quiere decir necesariamente que vayan a producir mal software, de forma ineficiente y con retraso, sino que la probabilidad de \u00e9xito es baja. Hay equipos que lo consiguen, pero son pocos. La raz\u00f3n es sencilla: los resultados en estos casos son tan buenos como las personas que los producen y, los buenos programadores escasean.
En este modo de trabajo la calidad del resultado se debe al \u00absaber hacer\u00bb de los programadores.\u00a0El \u00e9xito o fracaso de las organizaciones que trabajan sin una metodolog\u00eda depende del conocimiento t\u00e1cito de su personal. Es el modelo \u00abstart-up\u00bb: un equipo de emprendedores con talento, capaces de construir sistemas de software. El resultado ser\u00e1 tan bueno como ellos lo sepan hacer. El cumplimiento de agendas depender\u00e1 de su capacidad de previsi\u00f3n y organizaci\u00f3n. Pero no hay que enga\u00f1arse, en este caso no se trata de empresas que saben hacer software, sino de personas que saben hacer software.
Este es el guion habitual de las peque\u00f1as empresas de desarrollo que surgen impulsadas por el empuje de sus emprendedores: pueden llegar tan lejos como la combinaci\u00f3n de talento, capacidad relacional y de\u00a0 marketing de sus creadores les permitan. Esto es, acabar\u00e1n cerrando o alcanzar\u00e1n el nivel de mediocridad o \u00e9xito que puedan lograr combinando esos elementos, y el crecimiento m\u00e1s all\u00e1 de ese punto supondr\u00e1\u00a0 un reto importante:\u00a0 pasar de personas que saben hacer software a empresa que sabe hacer software, porque para ir m\u00e1s all\u00e1, no tienen que ser ellos, sino la organizaci\u00f3n la que\u00a0sepa producir\u00a0 con eficiencia y calidad en todos los proyectos.
Los objetivos de la gesti\u00f3n basada en procesos son:\u00a0<\/p>\n\n\n\n
- Repetibilidad<\/strong>. La calidad del resultado depende de la calidad del proceso, de forma que al aplicar el mismo proceso se obtiene el mismo resultado. <\/li>
- Escalabilidad<\/strong>. Es una consecuencia de la repetibilidad. Los resultados de calidad los obtienen todos los equipos que aplican los procesos.<\/li>
- Mejora continua<\/strong>. Introduciendo ingenier\u00eda de procesos se institucionaliza la mejora continua del sistema y por tanto de los resultados.<\/li>
- Know-how propio<\/strong>. Los procesos de la empresa son los que contienen el \u00absabe hacer\u00bb. El modelo de procesos es un activo valioso de la organizaci\u00f3n: la clave para hacer las cosas con eficiencia y calidad homog\u00e9nea.<\/li><\/ul>\n\n\n\n
Procesos<\/h3>\n\n\n\n
Los procesos marcan pautas de trabajo, pero se necesitan adem\u00e1s agentes activos: tecnolog\u00eda y\/o personas para producir los resultados.
Un ejemplo de las diferencias entre distintos sistemas de producci\u00f3n es el montaje de un mueble en\u00a0kit<\/em>. Es un trabajo que requiere personas y herramientas o tecnolog\u00eda:\u00a0destornillador (manual o el\u00e9ctrico),\u00a0tornillos, pasadores, cola de montaje, etc. Si realizamos el trabajo s\u00f3lo con estos dos componentes, sin seguir un proceso determinado \u2014sin seguir el manual de instrucciones\u2014 lo haremos en un sistema propio de artesanos o art\u00edfices: personas + tecnolog\u00eda, que no puede garantizar productividad y calidad homog\u00e9neas, porque dependen de las personas y, hay quien es capaz de ensamblar el mueble en cuesti\u00f3n de minutos y quien necesita toda una tarde. Habr\u00e1 quien montar\u00e1 muebles robustos y otros terminar\u00e1n con peor fortuna, afirmando que el montaje est\u00e1 bien hecho pero que las piezas ven\u00edan mal cortadas de f\u00e1brica, que quien lo\u00a0dise\u00f1\u00f3 era un perfecto in\u00fatil o que los tornillos son de mala calidad y en ocasiones sin percatarse de los fallos que ha cometido.\u00a0<\/p>\n\n\n\n![\"Diferentes](\"https:\/\/navegapolis.com\/website\/wp-content\/uploads\/sistemas_de_produccion.png\")
<\/figure>\n\n\n\n\u00abPersonas + tecnolog\u00eda\u00bb es una combinaci\u00f3n que produce resultados y puede resultar m\u00e1s o menos apropiada para un taller de carpinter\u00eda, pero una empresa de\u00a0carpinter\u00eda industrial necesita optar por una de estas estrategias para obtener resultados de calidad:<\/p>\n\n\n\n
- Introducir un tercer elemento en el sistema de producci\u00f3n: los procesos.<\/li>
- Emplear s\u00f3lo a buenos carpinteros, proporcion\u00e1ndoles las mejores herramientas.<\/li><\/ul>\n\n\n\n
Parece l\u00f3gico pensar en la primera: implementar un sistema de producci\u00f3n basado en procesos; normalmente la estrategia empleada en\u00a0 la manufactura industrial, aunque hay que tener en cuenta que no responde con la misma solvencia en\u00a0todos los trabajos, porque la gesti\u00f3n basada en procesos tiene su kryptonita: las tareas que requieren un conocimiento aprehensible por las personas pero que resulta dif\u00edcil explicitar en procesos o tecnolog\u00eda.<\/p>\n\n\n\n
Capital estructural y capital humano<\/h3>\n\n\n\n
El capital estructural lo forman\u00a0los bienes que quedan en la empresa cuando las personas est\u00e1n en sus casas: patentes, licencias, cartera de clientes, equipos, maquinaria, veh\u00edculos, etc.
El capital humano es el valor de la empresa, que resulta inseparable de las personas. Todas las organizaciones emplean ambos y la proporci\u00f3n en\u00a0la que cada uno condiciona la calidad del resultado es distinta en cada caso.
Normalmente el capital estructural es el factor m\u00e1s relevante\u00a0en las empresas industriales, pero cu\u00e1l tiene mayor peso en la calidad de la producci\u00f3n no depende s\u00f3lo del sector o tipo de industria.
En un mismo sector, distintas empresas pueden tener modelos de producci\u00f3n diferentes. Por ejemplo, dos restaurantes. Uno de ellos de alta cocina y por el otro un franquiciado de \u00abPhonoPizza\u00bb. Sin entrar en consideraciones gastron\u00f3micas, ambos negocios tienen perfectamente definida su identidad, personalidad y segmento; ambos tienen tambi\u00e9n su propio patr\u00f3n\u00a0de calidad. La pizzer\u00eda emplea una serie de procedimientos para garantizar de forma continua la calidad de su producto, de forma que depende muy poco del conocimiento t\u00e1cito de los cocineros. En su mayor parte se debe a los procesos y la tecnolog\u00eda empleada. Los hornos regulan autom\u00e1ticamente el tiempo y la temperatura. Los ingredientes se han producido y embolsado en las cantidades adecuadas para cada pizza y se distribuyen a todos los establecimientos estuchados, en ambientes frigor\u00edficos en base a los procesos que son los principales responsables de los resultados.\u00a0 Por esta raz\u00f3n es menos cr\u00edtico el personal de cocina de un establecimiento de PhonoPizza que el de un restaurante de alta cocina.<\/p>\n\n\n\n![\"componente](\"https:\/\/navegapolis.com\/website\/wp-content\/uploads\/capital_estructural_humano-1024x635.png\")
<\/figure>\n\n\n\nOptimizar el sistema de procesos, tecnolog\u00eda y personas no es f\u00e1cil. El objetivo es conseguir que cada factor aporte valor hasta el l\u00edmite de la mejor relaci\u00f3n eficiencia \/ calidad. La revisi\u00f3n permite mejorar de forma continua el sistema e\u00a0ir consiguiendo nuevos equilibrios con mejores par\u00e1metros de eficiencia y calidad en el sistema. En esta l\u00ednea es aconsejable comenzar analizando si, por las caracter\u00edsticas de los proyectos de nuestra empresa resulta m\u00e1s aconsejable un modelo basado en\u00a0 procesos o en personas (\u00e1gil) y comenzar con un marco est\u00e1ndar de una u otra l\u00ednea, por ejemplo CMMI como modelo de procesos, o scrum como marco \u00e1gil, pero es aconsejable ir m\u00e1s all\u00e1 de la simple implantaci\u00f3n de los procesos o pr\u00e1cticas est\u00e1ndar.
Los modelos de procesos incluyen procedimientos de revisi\u00f3n y\u00a0mejora continua, de forma que una vez lograda su institucionalizaci\u00f3n, los resultados mejoran de forma constante.
Si se trata de la incorporaci\u00f3n de un marco \u00e1gil, no debe hacerse de forma metodista. Las pr\u00e1cticas est\u00e1ndar deben ir cuestion\u00e1ndose y revisando para mejorar tambi\u00e9n de forma constante la fluidez de la organizaci\u00f3n.\u00a0<\/p>\n\n\n\nIndustria del software<\/h3>\n\n\n\n
Los modelos de procesos o calidad y las metodolog\u00edas de trabajo se resisten a funcionar en la ingenier\u00eda del software con la misma solvencia que en las ingenier\u00edas industriales, por un lado por la relativa juventud del software que anda a\u00fan dando las primeras vueltas de su espiral de evoluci\u00f3n del conocimiento y por otro, porque el conocimiento para garantizar la calidad del resultado en muchas dimensiones resulta dif\u00edcil de explicitar en los procesos y la tecnolog\u00eda del sistema de desarrollo.\u00a0
El siguiente texto extra\u00eddo del art\u00edculo \u201cCriticism of software engineering\u201d de wikipedia expone la situaci\u00f3n actual:
\u201cEn la ingenier\u00eda tradicional hay un claro consenso de c\u00f3mo deben construirse las cosas, cu\u00e1les son los est\u00e1ndares que deben seguirse y qu\u00e9 riesgos deben tratarse: si un ingeniero no sigue estas pr\u00e1cticas y algo falla, puede ser demandado. Sin embargo no hay un consenso similar en la ingenier\u00eda del software. Cada uno promueve sus propios m\u00e9todos, proclamando grandes beneficios en la productividad, que generalmente no respalda con evidencias cient\u00edficas imparciales.<\/em>\u201d
El problema en este momento no es la falta de est\u00e1ndares, modelos o t\u00e9cnicas, sino la abundancia de ellos, por lo que resulta aconsejable tomar un apunte del plano general para saber por d\u00f3nde nos movemos.<\/p>\n\n\n\n![\"Modelos](\"https:\/\/navegapolis.com\/website\/wp-content\/uploads\/modelos_y_estandares-1024x446.png\")
<\/figure>\n\n\n\nLa figura anterior representa la evoluci\u00f3n y estado actual de los principales modelos de procesos de referencia para las organizaciones de software.<\/p>\n\n\n\n
La norma considerada como punto de arranque de los posteriores est\u00e1ndares y modelos que se han extendido a todas las industrias es la desarrollada por EE.UU. en 1959: \u201cQuality Program Requirements\u201d MIL-Q-9858, dise\u00f1ada para el \u00e1mbito militar que estableci\u00f3 un esquema auditable (a trav\u00e9s de la norma de inspecci\u00f3n MIL-I.45208) de los requisitos que los proveedores deb\u00edan cumplir.<\/p>\n\n\n\n
El uso de esta norma se fue generalizando, mientras en paralelo diferentes organizaciones comenzaron a desarrollar las suyas propias. As\u00ed por ejemplo la OTAN en 1968 adopt\u00f3 las especificaciones AQAP \u201cAllied Quality Assurance Procedures\u201d.<\/p>\n\n\n\n
El est\u00e1ndar brit\u00e1nico BS5750, adoptado en el Reino Unido en 1979 fue el siguiente hito relevante en el camino de las normalizaciones, al lograr gran reconocimiento en varios pa\u00edses. Esta normativa fue la precursora de ISO 9000. Los est\u00e1ndares que fueron surgiendo de los 60 a los 90 dieron respuesta a las garant\u00edas de homogeneidad, calidad y predictibilidad de los entornos de fabricaci\u00f3n y especialmente en el desarrollo de sistemas complejos que comprend\u00edan tecnolog\u00edas e ingenier\u00edas diferentes: mec\u00e1nica, aeroespacial, naval, at\u00f3mica etc.<\/p>\n\n\n\n
Estos sistemas comenzaban a integrar una tecnolog\u00eda reci\u00e9n nacida: el software que a\u00fan no dispon\u00eda de una base de conocimiento asentada y consensuada. Algunos de los fiascos que se produjeron en determinados sistemas por introducci\u00f3n del software sin la madurez suficiente, pusieron de manifiesto la necesidad de desarrollar una ingenier\u00eda del software que pudiera ofrecer\u00a0la nueva tecnolog\u00eda con las garant\u00edas necesarias.\u00a0<\/p>\n\n\n\n
En las \u00faltimas d\u00e9cadas la industria del software ha desarrollado: <\/p>\n\n\n\n
- Modelos de procesos para garantizar calidad y eficiencia.<\/li>
- Conocimientos t\u00e9cnicos. <\/li><\/ul>\n\n\n\n
En este punto es interesante diferenciar entre unos y otros. Los primeros, los procesos, tienen como objetivo fijar \u00abqu\u00e9<\/strong>\u00bb hay que hacer para ofrecer garant\u00edas en los proyectos y los segundos\u00a0c\u00f3mo<\/strong>\u00a0debe realizarse. Un marco de procesos determinar\u00e1, por ejemplo, la necesidad de gestionar adecuadamente las modificaciones de requisitos o de realizar un dise\u00f1o detallado antes de comenzar la codificaci\u00f3n. El valor de los modelos de procesos radica en el conocimiento que aportan al identificar las actividades cuya omisi\u00f3n incrementa las posibilidades de fracaso en los proyectos.<\/p>\n\n\n\nSin embargo un marco de procesos no establece si el dise\u00f1o, por ejemplo, debe realizarse con diagramas IDEF o UML. Este es el campo de la t\u00e9cnica de la ingenier\u00eda del software. En la l\u00ednea de los modelos de procesos (qu\u00e9<\/strong> cosas hay que hacer) a partir de finales de los 80 se comenzaron a desarrollar marcos espec\u00edficos para el software, para cubrir a las particularidades de este producto, en el que las normas generales se quedaban cortas. En esta l\u00ednea ISO 9000 desarroll\u00f3 una norma espec\u00edfica para el software: ISO 9000-3 y la BSI (British Standards Institution) hizo lo propio desarrollando TickIT.<\/p>\n\n\n\n
En esta primera aparici\u00f3n de est\u00e1ndares surgieron tambi\u00e9n, aunque con menor repercusi\u00f3n: Trillium y Bootstrap. El primero desarrollado por la empresa Bell Canad\u00e1, que liber\u00f3 sus derechos haci\u00e9ndolo de dominio p\u00fablico. Bootstrap es una metodolog\u00eda para la evaluaci\u00f3n, medici\u00f3n y mejora de los procesos de software. Su desarrollo lo llev\u00f3 a cabo una comisi\u00f3n del ESPRIT (European Strategic Program for Research). Sin embargo las dos l\u00edneas que surgieron a principios de los 90 y que contin\u00faan como referentes en la actualidad son. CMMI y las normalizaciones de ISO 12207 y 15504.<\/p>\n\n\n\n
CMM \/ CMMI<\/h3>\n\n\n\n
SEI (Software Engineering Institute), un peso pesado en la normalizaci\u00f3n de los procesos del software, desarroll\u00f3 una l\u00ednea de trabajo sobre el concepto de la \u201cmadurez\u201d de las organizaciones para producir software.<\/p>\n\n\n\n
Por madurez se entiende el nivel de garant\u00eda de la organizaci\u00f3n para asegurar la calidad de sus proyectos (fecha, coste y funcionalidad), la homogeneidad (siempre y en todos los desarrollos) y la capacidad de aprendizaje de la propia experiencia y su aplicaci\u00f3n en la mejora continua.<\/p>\n\n\n\n
Como resultado de estas l\u00edneas de trabajo en 1990 public\u00f3 el modelo de madurez de la capacidad para el desarrollo de software (CMM-SW) que tras m\u00e1s de una d\u00e9cada de existencia demostr\u00f3 eficacia en muchas organizaciones.
Este modelo emplea una escala de cinco niveles para determinar la madurez de una organizaci\u00f3n.<\/p>\n\n\n\nNivel 1.- INICIAL: Pertenecen a \u00e9l las empresas que no siguen procesos definidos ni aplican t\u00e9cnicas de gesti\u00f3n de proyectos. Son talleres de producci\u00f3n de resultados no predecibles que dependen exclusivamente de la val\u00eda de las personas.<\/p>\n\n\n\n
Nivel 2.- REPETIBLE: Define a las organizaciones que aplican t\u00e9cnicas de gesti\u00f3n de proyectos, aunque no dispongan de procesos definidos.<\/p>\n\n\n\n
Nivel 3.- DEFINIDO: Pertenecen a \u00e9l las organizaciones que disponen de procesos definidos con precisi\u00f3n y ejecutados de forma regular. Las empresas con este nivel de madurez examinan la experiencia de los proyectos que realizan y emplean las lecciones aprendidas para mejorar sus procesos.<\/p>\n\n\n\n
Nivel 4.- GESTIONADO: En el cuarto nivel de madurez se sit\u00faan las organizaciones que han depurado el an\u00e1lisis de los proyectos realizados, hasta institucionalizarlo como procesos que miden cuantitativamente, de forma que pueden predecir cuantificablemente los resultados y evaluar las mejoras con mediciones objetivas.<\/p>\n\n\n\n
Nivel 5.- OPTIMIZADO: Las organizaciones con un nivel 5 de madurez tienen definidos y practican de forma institucionalizada, procesos de mejora continua que se nutren con la informaci\u00f3n cuantificada de los procesos del nivel 4.<\/p>\n\n\n\n
Tras el desarrollo del modelo SW-CMM, SEI desarroll\u00f3 otros para la medici\u00f3n y mejora de la capacidad de los procesos, todos relacionados con el foco original del SW-CMM: el desarrollo de software:<\/p>\n\n\n\n
- Systems Engineering Capability Maturity Model (SE-CMM).<\/li>
- Integrated Product Development Capability Maturity Model (IPD-CMM).<\/li>
- People Capability Maturity Model (P-CMM).<\/li>
- Software Acquisition Capability Maturity Model (SA-CMM).<\/li><\/ul>\n\n\n\n
En 2000 se desarroll\u00f3 una versi\u00f3n de SW-CMM que integraba algunos de estos modelos (SE-CMM o IPD-CMM). El resultado fue un nuevo modelo que relev\u00f3 al original SW-CMM: CMMI (Capability Maturity Model Integration).
En la actualidad hay varios modelos CMMI, en funci\u00f3n de las \u00e1reas que integran<\/p>\n\n\n\n- CMMI-SE\/SW\/IPPD\/SS (Systems Engineering, Software Engineering, Integrated Product and Process Development, Supplier Sourcing).<\/li>
- CMMI-SE\/SW\/IPPD (Systems Engineering, Software Engineering, Integrated Product and Process Development).<\/li>
- CMMI-SE\/SE (Systems Engineering, Software Engineering).<\/li><\/ul>\n\n\n\n
Adem\u00e1s de la integraci\u00f3n de varias disciplinas, los modelos CMMI introdujeron otra novedad que afectaba a su implantaci\u00f3n: dos formas posibles de llevara a cabo: escalonada o continua. La versi\u00f3n escalonada prescribe a la organizaci\u00f3n en qu\u00e9 orden debe abordar las diferentes\u00a0\u00e1reas de procesos, las pr\u00e1cticas que debe implantar y los objetivos que debe alcanzar para ir consiguiendo los sucesivos niveles de madurez. La versi\u00f3n continua permite cierta libertad a la organizaci\u00f3n sobre las \u00e1reas de proceso que desea mejorar y le orienta para ir mejorando el nivel de capacidad en esas \u00e1reas.
CMMI al igual que su predecesor CMM, tiene dos utilidades: puede servir como gu\u00eda para la mejora en una organizaci\u00f3n o como criterio para evaluaci\u00f3n, pero mientras CMM centraba estas dos finalidades en la dimensi\u00f3n de la\u00a0madurez<\/strong>\u00a0de la organizaci\u00f3n, CMMI introduce una segunda dimensi\u00f3n, tambi\u00e9n v\u00e1lida para guiar las actividades de mejora y para evaluar a las organizaciones: la\u00a0capacidad<\/strong>\u00a0de los procesos.
CMMI establece 6 niveles para determinar la capacidad de un proceso:<\/p>\n\n\n\n- Nivel 0.- INCOMPLETO: El proceso no se realiza.<\/li>
- Nivel 1.- REALIZADO: Se lleva a cabo el proceso, consiguiendo transformar elementos de entrada identificados, en productos de salida.<\/li>
- Nivel 2.- GESTIONADO: El proceso se ejecuta siempre de la misma manera, de una forma gestionada.<\/li>
- Nivel 3.- DEFINIDO: El proceso est\u00e1 definido en la organizaci\u00f3n y se ejecuta siempre.<\/li>
- Nivel 4.- CUANTIFICADAMENTE GESTIONADO: La ejecuci\u00f3n del proceso tiene institucionalizado en la organizaci\u00f3n un sistema de medici\u00f3n objetivo y cuantificable de su capacidad.<\/li>
- Nivel 5.- OPTIMIZADO: El proceso, que se ejecuta siempre, est\u00e1 definido en la organizaci\u00f3n, se mide y est\u00e1 integrado en un plan tambi\u00e9n institucionalizado de mejora continua, basada en mediciones de par\u00e1metros del mismo objetivamente cuantificables.<\/li><\/ul>\n\n\n\n
De esta forma los modelos CMMI presentan 2 versiones:<\/p>\n\n\n\n- Versi\u00f3n escalonada. Gu\u00eda a la organizaci\u00f3n acerca de las \u00e1reas de procesos que debe ir abordando, las pr\u00e1cticas que debe implantar y los objetivos que debe alcanzar para ir consiguiendo los sucesivos niveles de madurez.<\/li>
- Versi\u00f3n continua. Permite cierta libertad a la organizaci\u00f3n sobre las \u00e1reas de proceso que desea mejorar y le orienta para ir elevando el nivel de capacidad de las mismas. <\/li><\/ul>\n\n\n\n
Consecuentemente al evaluar a una organizaci\u00f3n se puede hacer sobre la dimensi\u00f3n de su madurez, estableciendo cu\u00e1l es el nivel que ha alcanzado o sobre la dimensi\u00f3n de la capacidad, reflejando cu\u00e1l es el nivel de \u00e9sta en las diferentes \u00e1reas de procesos.
Mientras SEI publicaba y comenzaba a definir su modelo CMM, ISO emprend\u00eda los otros dos proyectos que hoy forman los principales puntos de referencia en el \u00e1mbito de la calidad para nuestra industria: ISO 12207 e ISO 15504.<\/p>\n\n\n\nISO\/IEC 12207<\/h3>\n\n\n\n
Es un est\u00e1ndar internacional referente para la normalizaci\u00f3n de los procesos que constituyen el ciclo de vida de un proyecto de software, y las tareas que intervienen en cada una de sus fases.<\/p>\n\n\n\n
![\"ISO](\"https:\/\/navegapolis.com\/website\/wp-content\/uploads\/12207.png\")
<\/figure>\n\n\n\nEl est\u00e1ndar 12207 considera que el ciclo de vida de un sistema de software comienza en el momento que se concibe su idea o necesidad, momento desde el que es necesario comenzar a actuar de manera normalizada para describir el \u00e1mbito del problema, las soluciones posibles, etc. El ciclo se extiende desde ese momento, cubriendo el desarrollo, mantenimiento y operaci\u00f3n, y no concluye hasta que el sistema deja de utilizarse y es definitivamente retirado.<\/p>\n\n\n\n
SPICE \u2013 ISO\/IEC STD. 15504.<\/h3>\n\n\n\n
En enero de 1993 la comisi\u00f3n ISO\/IEC JTC1 aprob\u00f3 un programa de trabajo para el desarrollo de un modelo que fuera la base de un futuro est\u00e1ndar internacional para la evaluaci\u00f3n de los procesos del ciclo de vida del software. Este trabajo recibi\u00f3 el nombre de proyecto SPICE (Software Process Improvement and Capability dEtermination) y en junio de 1995, con la publicaci\u00f3n de su primer borrador, desde ISO fueron invitadas diferentes organizaciones para aplicarlo y valorar sus resultados.
En 1998, pasada la fase de proyecto y tras las primeras evaluaciones, el trabajo pas\u00f3 a la fase de informe t\u00e9cnico con la denominaci\u00f3n ISO\/IEC TR 15504.
La instrucci\u00f3n t\u00e9cnica consta de 9 apartados, recogidos en vol\u00famenes independientes, que se han ido publicando como redacci\u00f3n definitiva del est\u00e1ndar internacional ISO\/IEC 15504 durante el periodo 2003-2005.
Aunque ISO comenz\u00f3 con el proyecto SPICE algo m\u00e1s tarde que SEI con el modelo CMM, durante su evoluci\u00f3n han ido convergiendo y ambas instituciones vienen trabajando de forma conjunta desde 1998 para lograr la compatibilidad que finalmente han garantizado entre el modelo CMMI y el est\u00e1ndar 15504, de forma que la conformidad con uno de ellos implica la tambi\u00e9n conformidad con el otro.
El est\u00e1ndar est\u00e1 recogido en 9 documentos:
1.- (informativo) Conceptos y gu\u00eda de introducci\u00f3n.
2.- (normativo) Modelo de referencia de los procesos y de su capacidad.
3.- (normativo) Ejecuci\u00f3n de las auditor\u00edas.
4.- (informativo) Gu\u00eda para la realizaci\u00f3n de auditor\u00edas.
5.- (informativo) Modelo de asesor\u00eda e indicadores.
6.- (informativo) Gu\u00eda de formaci\u00f3n de consultores.
7.- (informativo) Gu\u00eda para usar en los procesos de mejora.
8.- (informativo) Gu\u00eda para determinar la capacidad de los procesos del proveedor.
9.- (normativo) Vocabulario.
ISO\/IEC 15504, al igual que CMMI es un modelo para evaluar los procesos de la organizaci\u00f3n y determinar si resultan efectivos para conseguir los objetivos. Tambi\u00e9n es un modelo para guiar las acciones de mejora de los procesos.
15504 tiene gran similitud con la representaci\u00f3n continua de CMMI. Al igual que este \u00faltimo centra el foco en la capacidad de los procesos y permite trabajar s\u00f3lo con una parte de ellos en lugar de hacerlo con todos los de la organizaci\u00f3n.
ISO 15504 agrupa los procesos de las organizaciones de software en cinco categor\u00edas:<\/p>\n\n\n\n- Cliente \u2013 proveedor.<\/li>
- Ingenier\u00eda.<\/li>
- Soporte.<\/li>
- Gesti\u00f3n.<\/li>
- Organizaci\u00f3n.<\/li><\/ul>\n\n\n\n
Y para la medici\u00f3n de la capacidad de cada proceso define una escala de 6 niveles<\/p>\n\n\n\n
- 0 Proceso incompleto.<\/li>
- 1 Proceso realizado.<\/li>
- 2 Proceso gestionado.<\/li>
- 3 Proceso establecido.<\/li>
- 4 Proceso predecible.<\/li>
- 5 Proceso optimizado.<\/li><\/ul>\n\n\n\n
ISO 15504 y CMMI son los referentes de las metodolog\u00edas formales. Para ambos el centro de su desarrollo son los procesos, no s\u00f3lo para el desarrollo, mantenimiento y operaci\u00f3n de los sistemas de software, sino tambi\u00e9n para mejorar la capacidad de los propios procesos y la madurez de las organizaciones.<\/strong><\/p>\n\n\n\n
SWEBOK<\/h3>\n\n\n\n
Aplicar gesti\u00f3n basada en procesos para asegurar un nivel de calidad homog\u00e9neo en los resultados es una estrategia adecuada para sistemas de producci\u00f3n en cadena o de manufactura industrial en industrias con una base de conocimiento profesional maduro.
La industria del software sin embargo emplea un conocimiento profesional relativamente joven y quiz\u00e1 no lo suficientemente asentado, por lo que la aparici\u00f3n de marcos y modelos de calidad se encuentra con un movimiento paralelo de propuestas sobre cu\u00e1l debe ser el curr\u00edculo profesional de un ingeniero de software.
La profesionalizaci\u00f3n exige:<\/p>\n\n\n\n- Disponer de una base de conocimiento, desarrollada con metodolog\u00eda cient\u00edfica y contrastada con la experiencia.<\/li>
- Consenso y aceptaci\u00f3n por la comunidad que ejerce la profesi\u00f3n.<\/li>
- Desarrollo de de curr\u00edculos profesionales, que gracias al consenso resulten homog\u00e9neos sobre centros de formaci\u00f3n, universidades y pa\u00edses diferentes.<\/li>
- Desarrollo de las organizaciones acad\u00e9micas y profesionales de autorregulaci\u00f3n.<\/li><\/ul>\n\n\n\n
Este es el esquema que han seguido muchas disciplinas para alcanzar un nivel de solvencia profesional socialmente reconocido. <\/p>\n\n\n\n
- Escalabilidad<\/strong>. Es una consecuencia de la repetibilidad. Los resultados de calidad los obtienen todos los equipos que aplican los procesos.<\/li>
![\"Modelos](\"https:\/\/navegapolis.com\/website\/wp-content\/uploads\/modelos_y_practicas_agiles-1024x756.png\")
<\/figure>\n\n\n\n![\"personas](\"https:\/\/navegapolis.com\/website\/wp-content\/uploads\/personas_procesos_tecnologia.png\")
<\/figure>\n\n\n\n