Mejoramiento del Proceso de Software PDF

CAPÍTULO 30 MEJORAMIENTO DE SOFTWARE DEL PROCESO CONCEPTOS ucho antes de...

CAPÍTULO 30 MEJORAMIENTO DE SOFTWARE DEL PROCESO CONCEPTOS ucho antes de que se usara ampliamente la frase “mejoramiento del proceso de soft- M CLAVE CMM de personal........ 688 ware”, el autor trabajó con grandes corporaciones con la intención de mejorar el es- CMMI................. 685 tado de sus prácticas de ingeniería del software. Como consecuencia de sus experien- educación y capacitación... 682 cias, el autor escribió un libro titulado Making Software Engineering Happen [Pre88]. En el evaluación............. 683 prefacio de dicho libro hizo el siguiente comentario: factores de éxito cruciales.. 685 Durante los pasados diez años, he tenido la oportunidad de ayudar a algunas compañías grandes a gestión del riesgo........ 684 implementar prácticas de ingeniería del software. La tarea es difícil y rara vez pasa tan suavemente instalación/migración..... 683 como uno quisiera; pero cuando triunfa, los resultados son profundos: los proyectos de software tie- justificación............. 682 nen más probabilidad de completarse con el tiempo, mejora la comunicación entre todos los consti- mejoramiento del proceso tuyentes involucrados en el desarrollo de software, el nivel de confusión y caos que con frecuencia de software (MPS)....... 677 prevalece para grandes proyectos de software se reduce de manera sustancial, el número de errores aplicabilidad........... 679 marcos conceptuales..... 677 que encuentra el cliente disminuye sustancialmente, la credibilidad de la organización de software proceso.............. 680 aumenta y la administración tiene un problema menos por el cual preocuparse. modelos de madurez...... 679 Pero no todo es dulzura y luz. Muchas compañías intentan implementar prácticas de ingeniería del rendimiento sobre inversión. 691 software y caen en la frustración. Otras llegan a medio camino y nunca ven los beneficios anotados selección............... 682 anteriormente. Otras más lo hacen en forma tan ruda que da como resultado rebelión abierta entre el valoración.............. 681 personal técnico y los administradores, con la posterior pérdida de moral. Aunque tales palabras se escribieron hace más de 20 años, siguen siendo igualmente ciertas el día de hoy. Conforme se avanza hacia la segunda década del siglo XXI, la mayoría de las principales or- ganizaciones de ingeniería del software intentaron “hacer posible la ingeniería del software”. Algunas implementaron prácticas individuales que ayudaron a mejorar la calidad del producto que construían y la oportunidad de su entrega. Otras establecieron un proceso de software “ma- duro” que guía las actividades técnicas y administrativas del proyecto. Pero otras continúan luchando. Sus prácticas son acierto y error, y su proceso es ad hoc. Ocasionalmente, su trabajo UNA MIRADA ¿Qué es? El mejoramiento del proceso de del proceso de software actual, 2) educación y capaci- RÁPIDA software abarca un conjunto de actividades que tación de profesionales y gerentes, 3) selección y justifica- conducirán a un mejor proceso de software y, ción de elementos de proceso, métodos de ingeniería del en consecuencia, a software de mayor calidad software y herramientas, 4) implementación del plan MPS y a su entrega en forma más oportuna. y 5) evaluación y afinación con base en los resultados del ¿Quién lo hace? El personal que impulsa el MPS (mejora- plan. miento de proceso de software) proviene de tres grupos: ¿Cuál es el producto final? Aunque existen muchos gerentes técnicos, ingenieros de software e individuos que productos operativos MPS intermedios, el resultado final es tienen responsabilidad en el aseguramiento de la calidad. un proceso de software mejorado que conduce a software ¿Por qué es importante? Algunas organizaciones de de mayor calidad. software tienen poco más que un proceso de software ad ¿Cómo me aseguro de que lo hice bien? El software hoc. Conforme trabajan para mejorar sus prácticas de que produce su organización se entregará con menos ingeniería del software, deben abordar las debilidades en defectos, se reducirá la repetición del trabajo en cada sus procesos existentes e intentar mejorar su enfoque para etapa del proceso de software y la entrega oportuna será el trabajo de software. mucho más probable. ¿Cuáles son los pasos? El enfoque del MPS es iterativo y continuo, pero puede verse en cinco pasos: 1) valoración 676 www.FreeLibros.me 30Pressman(675-694).indd 676 26/1/10 17:34:11  C AP Í T UL O 30 MEJORAMIENT O DEL PROCESO DE SOFT WARE 677 es espectacular, pero, en promedio, cada proyecto es una aventura, y nadie sabe si terminará mal o bien. Así que, ¿cuál de estas cohortes necesita mejoramiento del proceso de software? La res- puesta (que puede sorprenderle) es ambas. Las que triunfaron en hacer posible la ingeniería del software no pueden volverse complacientes. Deben trabajar de manera continua para mejorar su enfoque de la ingeniería del software. Y las que luchan deben comenzar su viaje por el ca- mino hacia el mejoramiento. 30. 1 ¿QUÉ ES MPS? PU El término mejoramiento del proceso de software (MPS) implica muchas cosas. Primero, que los NT O elementos de un proceso de software efectivo pueden definirse en forma efectiva; segundo, que CLAVE un enfoque organizacional existente sobre el desarrollo del software puede valorarse en con- MPS implica un proceso de software traste con dichos elementos; y tercero, que es posible definir una estrategia de mejoramiento definido, un enfoque organizacional significativa. La estrategia MPS transforma el enfoque existente sobre el desarrollo del software y una estrategia para el mejoramiento. en algo que es más enfocado, más repetible y más confiable (en términos de la calidad del pro- ducto producido y de la oportunidad de la entrega). Puesto que el MPS no es gratuito, debe entregar un rendimiento sobre la inversión. El es- fuerzo y el tiempo que se requieren para implementar una estrategia MPS deben pagar por sí mismos en alguna forma mensurable. Para hacer esto, los resultados del proceso y la práctica mejorados deben conducir a una reducción en los “problemas” del software que cuestan tiempo y dinero. Debe reducir el número de defectos que se entregan a los usuarios finales, la cantidad de repetición de proceso debida a problemas de calidad, los costos asociados con el manteni- miento y el soporte del software (capítulo 29) y los costos indirectos que ocurren cuando el software se entrega tarde. 30.1.1 Enfoques del MPS Aunque una organización puede elegir un enfoque relativamente informal del MPS, la gran ma- Cita: yoría elige uno de los marcos conceptuales MPS. Un marco conceptual MPS define: 1) un conjunto de características que deben presentarse si quiere lograrse un proceso de software efectivo, 2) un “Mucha de la crisis del software es autoinfligida, como cuando método para valorar si dichas características están presentes, 3) un mecanismo para resumir los un presidente del área de infor- resultados de cualquier valoración y 4) una estrategia para auxiliar a una organización de soft- mática en ejercicio dice: ware a implementar aquellas características del proceso que sean débiles o que hagan falta. ‘Prefiero que salga mal antes Un marco conceptual MPS valora la “madurez” del proceso de una organización y propor- que entregarlo tarde. Siempre ciona un indicio cualitativo de su nivel de madurez. De hecho, con frecuencia se aplica el tér- podremos repararlo después’.” mino “modelo de madurez” (sección 30.1.2). En esencia, el marco conceptual MPS abarca un Mark Paulk modelo de madurez que a su vez incorpora un conjunto de indicadores de calidad de proceso que ofrecen una medida global de la calidad del proceso que llevará a la calidad del producto. La figura 30.1 proporciona un panorama de un marco conceptual MPS típico. Se muestran los elementos clave del marco conceptual y su relación mutua. Debe observarse que no existe un marco conceptual MPS universal. De hecho, el marco con- ? ¿Qué grupos impulsan un esfuerzo MPS? ceptual MPS que elige una organización refleja las áreas que impulsan el esfuerzo MPS. Conradi [Con96] define seis diferentes grupos de apoyo al MPS: Certificadores de calidad. Los esfuerzos de mejoramiento de proceso que impulsa este grupo se enfocan en la siguiente relación: Calidad (Proceso) ⇒ Calidad (Producto) Su enfoque consiste en enfatizar los métodos de valoración y examinar un conjunto bien definido de características que le permiten determinar si el proceso muestra calidad. Es www.FreeLibros.me 30Pressman(675-694).indd 677 26/1/10 17:34:12  678 PAR T E C I N C O TE MAS AVANZADOS FIGURA 30.1 Elementos de un marco conceptual Proceso MPS de software Fuente: Adaptado de [Rou02]. Lo Identifica cambios a examina Identifica capacidades, fortalezas y debilidades de Sugiere enfoque Identifica madurez de de mejoramiento para Valoración Conduce a Conduce a Estrategia de Determinación mejoramiento de capacidad Está basada para más probable que adopten un marco conceptual de proceso, como CMM, SPICE, TickIT o Bootstrap.1 Formalistas. Este grupo quiere entender (y cuando es posible, optimizar) el flujo de tra- bajo del proceso. Para lograrlo, usa lenguajes de modelado de proceso (PML) a fin de crear un modelo del proceso existente y luego diseñar extensiones o modificaciones que harán más efectivo el proceso. Defensores de las herramientas. Este grupo insiste en un enfoque del MPS asistido por ? ¿Cuáles son los diferentes grupos que herramientas que modelan el flujo de trabajo y otras características del proceso de manera apoyan el MPS? que pueda analizarse para su mejoramiento. Profesionales. Este grupo usa un enfoque pragmático, “que enfatiza la administración tradicional de proyecto, calidad y producto, y aplica planificación y métricas en el nivel de proyecto, pero con poco modelado de proceso formal o pronunciamiento de apoyo” [Con96]. Reformadores. La meta de este grupo es el cambio organizacional que pueda conducir a un mejor proceso de software. Tienden a enfocarse más en los temas humanos (sección 30.5) y enfatizan medidas de capacidad humana y estructura. Ideólogos. Este grupo se enfoca en lo adecuado de un modelo de proceso particular para un dominio de aplicación específico o estructura organizativa. En lugar de los modelos de proceso de software típicos (por ejemplo, modelos iterativos), los ideólogos tendrían mayor interés en un proceso que, por ejemplo, apoyara el reuso o la reingeniería. Conforme se aplica un marco conceptual MPS, el grupo impulsor (sin importar su enfoque glo- bal) debe establecer mecanismos para: 1) apoyar la transición tecnológica, 2) determinar el grado en el que una organización está lista para absorber los cambios de proceso que se pro- pongan y 3) medir el grado en el que se adoptaron los cambios. 1 Cada uno de estos marcos conceptuales MPS se estudia más adelante, en este capítulo. www.FreeLibros.me 30Pressman(675-694).indd 678 26/1/10 17:34:12  C AP Í T UL O 30 MEJORAMIENT O DEL PROCESO DE SOFT WARE 679 30.1.2 Modelos de madurez Un modelo de madurez se aplica dentro del contexto de un marco conceptual MPS. La intención del modelo de madurez es proporcionar un indicio global de la “madurez del proceso” que muestra una organización de software, es decir, un indicio de la calidad del proceso de software, el grado en el que los profesionales entienden y aplican el proceso, y el estado general de la práctica de ingeniería del software. Esto se logra usando algún tipo de escala ordinal. Por ejemplo, el modelo de madurez de capacidad (sección 30.4) del Software Engineering Institute sugiere cinco niveles de madurez [Sch96]: PU Nivel 5, optimizado. La organización tiene sistemas de realimentación cuantitativa en su lugar para NT O identificar las debilidades del proceso y fortalecer esos puntos de manera proactiva. Los equipos de CLAVE proyecto analizan defectos para determinar sus causas; los procesos de software se evalúan y actua- Un modelo de madurez define lizan para evitar que recurran tipos conocidos de defectos. niveles de competencia e implementación de proceso de Nivel 4, gestionado. Métricas de proceso de software y de calidad de producto detalladas estable- software. cen el cimiento de evaluación cuantitativa. Las variaciones significativas en el desempeño del proceso pueden distinguirse del ruido aleatorio, y pueden predecirse las tendencias en las cualidades del pro- ceso y el producto. Nivel 3, definido. Los procesos para administración e ingeniería se documentan, estandarizan e integran en un proceso de software estándar para la organización. Todos los proyectos usan una ver- sión aprobada y a la medida del proceso de software estándar de la organización para desarrollo de software. Nivel 2, repetible. Se establecen procesos de administración de proyecto básicos para rastrear costo, calendario y funcionalidad. La planificación y administración de nuevos productos se basa en la experiencia con proyectos similares. Nivel 1, inicial. Pocos procesos definidos, y el éxito depende más del esfuerzo heroico individual que de seguir un proceso y usar un esfuerzo sinérgico de equipo. La escala de madurez CMM va más allá, pero la experiencia indica que muchas organizaciones muestran niveles de “inmadurez de proceso” [Sch96] que minan cualquier intento racional por mejorar las prácticas de ingeniería de software. Schorsch [Sch06] sugiere cuatro niveles de inmadurez que se encuentran frecuentemente en el mundo real de las organizaciones de desa- rrollo del software: ? ¿Cómo se reconoce a una organización que Nivel 0, negligente. Fracaso para permitir que tenga éxito un proceso de desarrollo exitoso. Todos los problemas se perciben como problemas técnicos. Las actividades administrativas y de aseguramiento resistirá los esfuerzos de la calidad están condenadas a situarse por encima y ser superfluas en relación con las tareas del MPS? proceso de desarrollo del software. Se confía en las balas de plata. Nivel 1, obstructivo. Se imponen procesos contraproducentes. Los procesos se definen rígidamente y se adhieren a la forma que subrayan. Abundan las ceremonias rituales. La administración colectiva impide la asignación de responsabilidad. Status quo über alles (sobre todo). Nivel 2, despreciador. No se preocupa por la buena ingeniería de software institucionalizada. Hay desunión completa entre actividades de desarrollo de software y actividades de mejoramiento del proceso de software y falta completa de programas de capacitación. Nivel 3, socavación. Desprecio total por la propia organización, descrédito consciente de los esfuer- zos de mejoramiento del proceso de software de los pares de la organización. Recompensa al fracaso y al pobre desempeño. Los niveles de inmadurez de Schorsch son tóxicos para cualquier organización de software. Si usted encuentra alguno de ellos, los intentos por MPS están condenados al fracaso. La pregunta decisiva es si las escalas de madurez, como las que se proponen como parte del CMM, proporcionan algún beneficio real. El autor cree que lo tienen. Una escala de madurez www.FreeLibros.me 30Pressman(675-694).indd 679 26/1/10 17:34:12  680 PAR T E C I N C O TE MAS AVANZADOS proporciona una instantánea fácilmente comprensible de la calidad del proceso que pueden emplear los profesionales y administradores como hito desde el cual puedan planificar estrate- gias de mejoramiento. 30.1.3 ¿El MPS es para todos? Durante muchos años, el MPS se vio como una actividad “corporativa”, un eufemismo para algo que sólo realizan las grandes compañías. Pero hoy, un porcentaje significativo de todo el desa- rrollo de software lo realizan compañías que emplean menos de 100 personas. ¿Una compañía pequeña puede iniciar actividades MPS y realizarlas con éxito? Existen sustanciales diferencias culturales entre grandes y pequeñas organizaciones de de- CONSEJO sarrollo de software. No debe sorprender que las organizaciones pequeñas sean más informa- Si un modelo de proceso específico o les, apliquen menos prácticas estándar y tiendan a la autoorganización. También tienden a enfoque MPS se percibe como enorgullecerse por la “creatividad” de los miembros individuales de la organización de software, excesivo en su organización, e inicialmente ven un marco conceptual MPS como excesivamente burocrático y pesado. Sin probablemente lo es. embargo, el mejoramiento de los procesos es tan importante para una organización pequeña como para una grande. Dentro de las organizaciones pequeñas, la implementación de un marco conceptual MPS requiere recursos que pueden tener un suministro reducido. Los administradores deben asignar personal y dinero para lograr que ocurra la ingeniería del software. Por tanto, sin importar el tamaño de la organización del software, es razonable considerar la motivación empresarial para el MPS. Éste se aprobará e implementará sólo después de que sus proponentes demuestren apalan- camiento financiero [Bir98], que se demuestra al examinar los beneficios técnicos (por ejemplo, menos defectos entregados al campo, reelaboración reducida, menores costos de manteni- miento o tiempo de llegada al mercado más rápido) y traducirlos en dinero. En esencia, deben demostrar un rendimiento realista sobre la inversión (sección 30.7) para los costos MPS. 30. 2 EL PROCESO MPS La parte dura del MPS no es establecer las características que definen un proceso de software de alta calidad o la creación de un modelo de madurez de proceso. Ésas son relativamente sen- cillas. La parte dura es establecer un consenso para iniciar MPS y definir una estrategia continua a fin de implementarla a través de una organización de software. El Software Engineering Institute desarrolló IDEAL, “un modelo de mejoramiento organiza- cional que funciona como mapa de caminos para iniciar, planificar e implementar acciones de mejoramiento” [SEI08]. IDEAL es representativo de muchos modelos de proceso para MPS y define cinco actividades distintas: inicio, diagnóstico, establecimiento, acción y aprendizaje, que guían a una organización a través de las actividades MPS. En este libro se presenta un mapa de caminos un tanto diferente para MPS, con base en el modelo de proceso para MPS originalmente propuesto en [Pre88]. Aplica una filosofía de sentido común que requiere que una organización 1) se observe en el espejo, 2) se vuelva más astuta para tomar elecciones inteligentes, 3) seleccione el modelo de proceso (y los elementos tecno- lógicos relacionados) que satisfagan mejor sus necesidades, 4) ejemplifique el modelo en su entorno operativo y su cultura y 5) evalúe lo que se hizo. Estas cinco actividades (analizadas en las subsecciones2 que siguen) se aplican en forma iterativa (cíclica) con la intención de fomentar el mejoramiento de proceso continuo. 2 Algunos de los contenidos de estas secciones han sido adaptados de [Pre88] con autorización. www.FreeLibros.me 30Pressman(675-694).indd 680 26/1/10 17:34:13  C AP Í T UL O 30 MEJORAMIENT O DEL PROCESO DE SOFT WARE 681 30.2.1 Valoración y análisis de la desviación Cualquier intento por mejorar un proceso de software existente sin primero valorar la eficacia de las actividades del marco conceptual y las prácticas de ingeniería del software asociadas sería como iniciar un largo viaje hacia una nueva localidad sin idea de dónde se comienza. Se parte con gran movimiento y se vaga por ahí intentando conseguir un rumbo, se emplea mucha energía y se padece de grandes dosis de frustración y, probablemente, se decide que en realidad no se quiere viajar de cualquier forma. Dicho de manera simple, antes de comenzar cualquier viaje, es buena idea saber precisamente dónde se está. La primera actividad del mapa de caminos, llamada valoración, le permite adquirir rumbo. La CONSEJO intención de la valoración es descubrir las fortalezas y las debilidades en la forma en la que su Asegúrese de entender sus fortalezas organización aplica el proceso de software existente y las prácticas de ingeniería del software así como sus debilidades. Si es que pueblan el proceso. inteligente, construirá sobre la base La valoración examina un amplio rango de acciones y tareas que conducirán a un proceso de las fortalezas. de alta calidad. Por ejemplo, sin importar el modelo de proceso que elija, la organización de software debe establecer mecanismos genéricos como: enfoques definidos para comunicación con el cliente; establecimiento de métodos para representar requisitos de usuarios; definición de un marco conceptual de gestión del proyecto que incluya definición del ámbito, estimación, calendarización y rastreo del proyecto; métodos de análisis de riesgos; cambio de procedimien- tos administrativos; actividades de aseguramiento y control de la calidad que incluyan revisio- nes y muchas otras. Cada una se considera dentro del contexto del marco conceptual y las ac- tividades sombrilla (capítulo 2) que se establecieron y valoraron para determinar si se responden las siguientes preguntas: ¿El objetivo de la acción está claramente definido? ¿Los productos operativos requeridos como entrada y producidos como salida se identi- fican y describen? ¿Las tareas de trabajo por realizar se describen claramente? ¿Las personas que deben realizar la acción se identifican por rol? ¿Se establecieron criterios de entrada y salida? ¿Se establecieron métricas para la acción? ¿Hay herramientas disponibles para apoyar la acción? ¿Existe algún programa de capacitación explícito que aborde la acción? ¿La acción se realiza de manera uniforme para todos los proyectos? Aunque las preguntas anotadas implican una respuesta de sí o no, el papel de la valoración es mirar detrás de la respuesta para determinar si la acción en cuestión se realiza con las mejores prácticas. Conforme se realiza el proceso de valoración, usted (o quienes se contraten para realizar la valoración) también deben enfocarse en los siguientes atributos: Consistencia. ¿Las actividades, acciones y tareas importantes se aplican de manera consis- ? ¿Qué atributos genéricos se observan tente a través de todos los proyectos de software y por todos los equipos de software? durante la valoración? Sofisticación. ¿Las acciones administrativas y técnicas se realizan con un nivel de sofistica- ción que implica una comprensión profunda de las mejores prácticas? Aceptación. ¿El proceso de software y la práctica de ingeniería del software se aceptan am- pliamente por parte del personal administrativo y técnico? Compromiso. ¿La administración comprometió los recursos requeridos para lograr consis- tencia, sofisticación y aceptación? www.FreeLibros.me 30Pressman(675-694).indd 681 26/1/10 17:34:13  682 PAR T E C I N C O TE MAS AVANZADOS La diferencia entre aplicación local y mejores prácticas representa una “brecha” que ofrece oportunidades para el mejoramiento. El grado en el cual se logren consistencia, sofisticación, aceptación y compromiso indica la cantidad de cambio cultural que se requerirá para lograr mejoría significativa. 30.2.2 Educación y capacitación Aunque pocas personas de software cuestionan los beneficios de un proceso de software orga- nizado y ágil o las prácticas sólidas de ingeniería del software, muchos profesionales y adminis- tradores no conocen lo suficiente acerca de alguno de los temas.3 Como consecuencia, percep- ciones imprecisas de los procesos y de las prácticas conducen a decisiones inadecuadas cuando se introduce un marco conceptual MPS. Se concluye entonces que un elemento clave de cual- quier estrategia MPS es la educación y capacitación de los profesionales, gerentes técnicos y gerentes ejecutivos que tengan contacto directo con la organización de software. Con ese fin, deben realizarse tres tipos de educación y capacitación: Conceptos y métodos genéricos. Dirigida tanto a gerentes como a profesionales, esta CONSEJO categoría subraya tanto procesos como práctica. La intención es proporcionar a los profe- Intente proporcionar capacitación sionales las herramientas intelectuales necesarias para aplicar el proceso de software de “justo a tiempo” dirigida a las manera efectiva y la toma de decisiones racionales acerca de las mejorías del proceso. necesidades reales de un equipo de Tecnología y herramientas específicas. Dirigida principalmente a profesionales, esta software. categoría subraya las tecnologías y herramientas que se adoptaron para el uso local. Por ejemplo, si se eligió UML para modelado de análisis y diseño, se establece un programa de estudios de capacitación para ingeniería del software usando UML. Comunicación empresarial y temas relacionados con la calidad. Dirigida a todos los participantes, esta categoría se enfoca en los temas “blandos” que ayudan a una mejor co- municación entre los participantes y fomentan un mayor foco de calidad. En un contexto moderno, educación y capacitación pueden entregarse en varias formas dis- tintas. Todo puede ofrecerse como parte de una estrategia MPS, desde podcast hasta capacita- ción basada en internet (por ejemplo, [QAI08]), pasando por DVD y cursos en aulas. 30.2.3 Selección y justificación Una vez completada la actividad de valoración inicial4 e iniciada la educación, una organización CONSEJO de software debe comenzar a elegir, lo que ocurre durante una actividad de selección y justifica- Conforme elija, asegúrese de ción en la que se eligen características del proceso y se especifican métodos de ingeniería del considerar la cultura de su software determinados para poblar el proceso de software. organización y el nivel de aceptación Primero, debe elegir el modelo de proceso (capítulos 2 y 3) que se ajuste mejor a su organi- que cada elección probablemente zación, a sus participantes y al software que construirán. Debe decidir cuáles de las actividades provocará. del conjunto del marco conceptual se aplicarán, los principales productos operativos que se producirán y los puntos de verificación de aseguramiento de la calidad que permitirán a su equipo valorar el progreso. Si la actividad de valoración MPS indica debilidades específicas (por ejemplo, no hay funciones SQA formales), debe enfocar su atención en las características del proceso que abordarán directamente dichas debilidades. A continuación, desarrolle un trabajo innovador para cada actividad de marco conceptual (por ejemplo, modelado) y defina el conjunto de tareas que se aplicarán para un proyecto típico. También debe considerar los métodos de ingeniería del software que pueden aplicarse para 3 Si ha invertido tiempo en la lectura de este libro, ¡no será uno de ellos! 4 En realidad, la valoración es una actividad continua. Se realiza de manera periódica con la intención de deter- minar si la estrategia MPS logró sus metas inmediatas y si se establece el escenario para una futura mejoría. www.FreeLibros.me 30Pressman(675-694).indd 682 26/1/10 17:34:13  C AP Í T UL O 30 MEJORAMIENT O DEL PROCESO DE SOFT WARE 683 lograr dichas tareas. Conforme se hagan estas elecciones, educación y capacitación deben coordinarse para garantizar el reforzamiento de la comprensión. De manera ideal, todos trabajan en conjunto para seleccionar varios procesos y elementos tecnológicos y para moverse suavemente hacia la actividad de instalación o migración (sección 30.2.4). En realidad, la selección puede ser un camino empedrado. Con frecuencia es difícil lo- grar consenso entre diferentes grupos. Si un comité establece los criterios para la selección, las personas pueden discutir sin fin acerca de si los criterios son adecuados y si una elección real- mente satisface los criterios que se establecieron. Es cierto que una mala elección puede hacer más daño que bien, pero “parálisis por análisis” significa que ocurre poco progreso, tal vez, y que persisten los problemas del proceso. En tanto las características del proceso o los elementos tecnológicos tengan buena posibilidad de satis- facer las necesidades de una organización, a veces es mejor jalar el gatillo y hacer la selección, en lugar de esperar la solución óptima. Una vez hecha la elección, deben emplearse tiempo y dinero para demostrarla dentro de una organización, y dichos gastos de recursos deben justificarse. En la sección 30.7 se presenta un análisis acerca de la justificación del costo y el rendimiento sobre la inversión para el MPS. 30.2.4 Instalación/migración La instalación es el primer punto donde una organización de software siente los efectos de los cambios implementados como consecuencia del mapa de caminos MPS. En algunos casos, se recomienda un proceso completamente nuevo para una organización. Las actividades de marco conceptual, acciones de ingeniería del software y tareas de trabajo individuales deben definirse e instalarse como parte de una nueva cultura de ingeniería del software. Tales cambios repre- sentan una transición organizativa y tecnológica sustancial, y deben administrarse con mucho cuidado. En otros casos, los cambios asociados con MPS son relativamente menores, lo que repre- senta pequeñas modificaciones, pero significativas, a un modelo de proceso existente. A tales cambios con frecuencia se les conoce como migración de proceso. En la actualidad, muchas organizaciones de software tienen un “proceso” en su lugar. El problema es que no funciona de forma efectiva. Por tanto, una estrategia más efectiva es una migración incremental de un pro- ceso (que no funciona tan bien como se desea) a otro proceso. Instalación y migración en realidad son actividades de rediseño de proceso de software (RPS). Scacchi [Sca00] afirma que “el RPS se preocupa por la identificación, aplicación y refinamiento de nuevas formas de mejorar dramáticamente y de transformar los procesos de software”. Cuando se inicia un proceso formal de RPS se consideran tres modelos de proceso diferentes: 1) el proceso existente (“como es”), 2) un proceso transicional (“de aquí a allá”) y 3) el proceso meta (“por ser”). Si este último es significativamente diferente del proceso existente, el único enfoque racional de la instalación es una estrategia incremental en la que el proceso transicio- nal se implemente en pasos. El proceso transicional ofrece una serie de puntos que permiten que la cultura de la organización de software se adapte a pequeños cambios a lo largo de un periodo. 30.2.5 Evaluación Aunque se menciona como la última actividad en el mapa de caminos MPS, la evaluación ocurre a lo largo del MPS. La actividad de evaluación valora el grado en el cual los cambios se demos- traron y adoptaron, el grado en el que tales cambios dan como resultado mejor calidad de soft- ware u otros beneficios tangibles de proceso y el estado global del proceso y de la cultura de la organización conforme avanzan las actividades MPS. Durante la actividad de evaluación se consideran tanto factores cualitativos como métricas cuantitativas. Desde un punto de vista cualitativo, las actitudes anteriores de administradores y www.FreeLibros.me 30Pressman(675-694).indd 683 26/1/10 17:34:14  684 PAR T E C I N C O TE MAS AVANZADOS profesionales acerca del proceso de software pueden compararse con las que tienen después de la instalación de los cambios del proceso. Las métricas cuantitativas (capítulo 25) se recopilan de proyectos que usaron el proceso transicional o del proceso “por ser” y se comparan con mé- tricas similares que se recopilan para proyectos que se realizaron bajo el proceso “como es”. 30.2.6 Gestión del riesgo para MPS PU El MPS es una empresa riesgosa. De hecho, más de la mitad de todos los esfuerzos MPS terminan NT O en fracaso. Las razones del fracaso varían enormemente y son específicas de la organización. CLAVE Entre los riesgos más comunes están: falta de apoyo administrativo, resistencia cultural por parte El MPS con frecuencia fracasa porque del personal técnico, una estrategia MPS pobremente planeada, un enfoque excesivamente for- los riesgos no se consideraron mal del MPS, selección de un proceso inadecuado, falta de “adquisición” por parte de participan- adecuadamente y no se tuvo un plan de contingencia. tes clave, un presupuesto inadecuado, falta de capacitación de personal, inestabilidad de la or- ganización, entre muchos otros factores. El papel de quienes tienen la responsabilidad del MPS es analizar los riesgos probables y desarrollar una estrategia interna para mitigarlos. Una organización de software debe gestionar el riesgo en tres puntos clave en el proceso MPS [Sta97b]: antes del inicio del mapa de caminos MPS, durante la ejecución de las activida- des MPS (valoración, educación, selección, instalación) y durante la actividad de evaluación que sigue a la ejemplificación de algunas características del proceso. En general, pueden iden- tificarse las siguientes categorías [Sta97b] para factores de riesgo MPS: presupuesto y costo, contenido y entregables, cultura, mantenimiento de entregables MPS, misión y metas, adminis- tración de la organización, estabilidad de la organización, participantes en el proceso, calenda- rio de desarrollo MPS, entorno de desarrollo MPS, proceso de desarrollo MPS, administración del proyecto MPS y personal MPS. Dentro de cada categoría pueden identificarse algunos factores de riesgo genéricos. Por ejemplo, la cultura organizacional tiene un fuerte vínculo con el riesgo. Para la categoría cultura, pueden definirse los siguientes factores de riesgo genéricos5 [Sta97b]: Actitud hacia el cambio, con base en esfuerzos previos por cambiar Experiencia con programas de calidad, nivel de éxito Orientación de la acción para resolver problemas frente a luchas políticas Uso de hechos para gestionar la organización y los negocios Paciencia con el cambio; habilidad para pasar tiempo socializando Orientación de las herramientas: esperanza de que las herramientas puedan resolver los problemas Nivel de “planificación”: habilidad de la organización para planificar Habilidad de los miembros de la organización para participar abiertamente en las reuniones con varios niveles de la organización Habilidad de los miembros de la organización para administrar las reuniones de manera eficaz Nivel de experiencia en la organización con procesos definidos Al usar los factores de riesgo y los atributos genéricos como guía, es posible calcular la exposi- ción al riesgo en la forma siguiente: Exposición ⫽ (probabilidad de riesgo) ⫻ (pérdida estimada) Puede desarrollar una tabla de riesgo (capítulo 28) para aislar aquellos riesgos que garanticen mayor atención de la administración. 5 Factores de riesgo para cada una de las categorías de riesgo anotadas en esta sección pueden encontrarse en [Sta97b]. www.FreeLibros.me 30Pressman(675-694).indd 684 26/1/10 17:34:14  C AP Í T UL O 30 MEJORAMIENT O DEL PROCESO DE SOFT WARE 685 30.2.7 Factores de éxito cruciales En la sección 30.2.6 se observó que el MPS es una empresa riesgosa y que la tasa de fracaso para las compañías que intentan mejorar su proceso es angustiosamente elevada. Los riesgos de la organización, del personal y de la administración de proyecto presentan retos para quienes dirigen cualquier esfuerzo MPS. Aunque la gestión del riesgo es importante, lo es igualmente reconocer aquellos factores cruciales que conducen al éxito. Después de examinar 56 organizaciones de software y sus esfuerzos MPS, Stelzer y Mellis [Ste99] identifican un conjunto de factores de éxito cruciales (FEC) que deben presentarse si ha de triunfar el MPS. En esta sección se presentan los cinco principales FEC. Compromiso y apoyo de la administración. Como la mayoría de las actividades que ? ¿Qué factores de éxito cruciales son vitales precipitan el cambio organizativo y cultural, el MPS triunfará sólo si la administración se para el éxito del MPS? involucra de manera activa. Los gerentes ejecutivos deben reconocer la importancia del software para sus compañías y ser patrocinadores activos del esfuerzo MPS. Los gerentes técnicos deben involucrarse enormemente en el desarrollo de la estrategia MPS local. Como anotan los autores del estudio: “el mejoramiento del proceso de software no es facti- ble sin investigar tiempo, dinero y esfuerzo” [Ste99]. El compromiso y el apoyo administra- tivo son esenciales para sostener dicha inversión. Involucramiento del personal. El MPS no puede imponerse de manera descendente ni desde el exterior. Si los esfuerzos MPS han de triunfar, el mejoramiento debe ser or- gánico, patrocinado por gerentes técnicos y técnicos ejecutivos, y adoptado por profesio- nales locales. Integración y comprensión del proceso. El proceso de software no existe en un vacío organizativo. Debe integrarse con otros procesos y requisitos empresariales. Para lograr esto, los responsables del esfuerzo MPS deben tener un conocimiento íntimo de los otros procesos empresariales. Además, deben entender el proceso de software “como es” y valo- rar cuánto cambio transicional es tolerable dentro de la cultura local. Una estrategia MPS a la medida. No hay una receta para la estrategia MPS. Como se anotó anteriormente, en este capítulo, el mapa de caminos MPS debe adaptarse al entorno local: deben considerarse cultura de equipo, mezcla de producto, y fortalezas y debilidades locales. Administración sólida del proyecto MPS. El MPS es un proyecto como cualquier otro. Involucra coordinación, calendarización, tareas paralelas, productos entregables, adapta- ción (cuando el riesgo se convierte en realidad), políticas, control presupuestal y mucho más. Sin administración activa y efectiva, un proyecto MPS está condenado al fracaso. 30. 3 E L CMMI WebRef El CMM original se desarrolló y actualizó por parte del Software Engineering Institute a lo largo Para obtener información más de los años de 1990 como un marco conceptual MPS completo. Más adelante, evolucionó en la completa acerca del CMMI, dirigirse a Integración del Modelo de Madurez de Capacidades (CMMI) [CMM07], un metamodelo de proceso www.sei.cmu.edu/cmmi/ exhaustivo que se impulsa en un conjunto de sistemas y capacidades de ingeniería del software que deben presentarse conforme las organizaciones alcanzan diferentes niveles de capacidad y madurez del proceso. El CMMI representa un metamodelo de proceso en dos formas diferentes: 1) como un modelo “continuo” y 2) como un modelo “en etapas”. El metamodelo CMMI continuo describe un pro- ceso en dos dimensiones, como se ilustra en la figura 30.2. Cada área de proceso (por ejemplo, planificación de proyecto o gestión de requisitos) se valora formalmente contra metas y prácti- cas específicas y se clasifica de acuerdo con los siguientes niveles de capacidad: www.FreeLibros.me 30Pressman(675-694).indd 685 26/1/10 17:34:14  686 PAR T E C I N C O TE MAS AVANZADOS FIGURA 30.2 Perfil de PP Planificación de proyecto capacidad de REQM Gestión de requisitos MA Medición y análisis área de proceso 5 CM Gestión de configuración CMMI PPQA Proceso y producto QA Fuente: [Phi02]. Nivel de capacidad 4 3 2 1 0 PP REQM MA CM PPQA otros Área de proceso Nivel 0: Incompleto: el área del proceso (por ejemplo, gestión de requisitos) no se realiza o no logra todas las metas y objetivos definidos por la CMMI para la capacidad nivel 1 del área de proceso. Nivel 1: Realizado: todas las metas específicas del área de proceso (como se define me- diante la CMMI) están satisfechas. Se realizan las tareas de trabajo requeridas para produ- cir productos operativos definidos. Nivel 2: Administrado: se satisfacen todos los criterios del nivel 1 de capacidad. Además, CONSEJO todo el trabajo asociado con el área de proceso se encuentra acorde con una política defi- Cada organización debe esforzarse nida de manera organizacional; todo el personal que realiza el trabajo tiene acceso a recur- por lograr el objetivo de la CMMI. sos adecuados para tener listo el trabajo; los participantes se involucran de manera activa Sin embargo, la aplicación de todos en el área de proceso según se requiera; todas las tareas del trabajo y los productos opera- los aspectos del modelo puede ser tivos se “monitorean, controlan y revisan, y se evalúan para su adhesión a la descripción exagerado. del proceso” [CMM07]. Nivel 3: Definido: se logran todos los criterios del nivel 2 de capacidad. Además, el proceso se “hace a la medida, a partir del conjunto de procesos estándar y de acuerdo con los linea- mientos de producción de la organización; contribuye con productos operativos, medidas y otra información para mejorar los procesos activos del proceso organizacional” [CMM07]. Nivel 4: Administrado cuantitativamente: se logran todos los criterios del nivel 3 de capaci- dad. Además, el área de proceso se controla y mejora, usando medición y valoración cuan- titativa. “Los objetivos cuantitativos para el rendimiento cualitativo y de proceso se estable- cen y usan como criterios para gestionar el proceso” [CMM07]. Nivel 5: Optimizado: se logran todos los criterios del nivel 4 de capacidad. Además, el área de proceso se adapta y optimiza, usando medios cuantitativos (estadísticos) para satisfacer las necesidades cambiantes del cliente y para mejorar continuamente la eficacia del área de proceso bajo consideración. La CMMI define cada área de proceso en términos de “metas específicas”, y de “prácticas espe- cíficas” requeridas para lograr dichas metas. Las metas específicas establecen las característi- cas que deben existir si las actividades implicadas por un área de proceso han de ser efectivas. Las prácticas específicas desglosan una meta en un conjunto de actividades relacionadas con el proceso. www.FreeLibros.me 30Pressman(675-694).indd 686 26/1/10 17:34:14  C AP Í T UL O 30 MEJORAMIENT O DEL PROCESO DE SOFT WARE 687 Por ejemplo, la planificación del proyecto es una de las ocho áreas de proceso definidas por la CMMI para la categoría “gestión de proyecto”.6 Las metas específicas (ME) y las prácti- cas específicas (PE) asociadas definidas para planificación de proyecto son [CMM07]: ME 1 Establecimiento de estimaciones PE 1.1-1 Estimación del ámbito del proyecto WebRef En www.sei.cmu.edu/CMMI/ PE 1.2-1 Establecimiento de estimaciones de producto operativo y atributos de tarea puede obtenerse información completa PE 1.3-1 Definición de ciclo de vida del proyecto además de una versión descargable de la CMMI PE 1.4-1 Determinación de estimaciones de esfuerzo y costo ME 2 Desarrollo de un plan de proyecto PE 2.1-1 Establecimiento del presupuesto y calendario PE 2.2-1 Identificación de riesgos del proyecto PE 2.3-1 Plan para gestión de datos PE 2.4-1 Plan para recursos del proyecto PE 2.5-1 Plan para conocimiento y habilidades necesarias PE 2.6-1 Plan de involucramiento de participantes PE 2.7-1 Establecimiento del plan del proyecto ME 3 Obtención de compromiso del plan PE 3.1-1 Revisión de planes que afectan el proyecto PE 3.2-1 Reconciliación de niveles de trabajo y recursos PE 3.3-1 Obtención de compromiso del plan Además de las metas y prácticas específicas, la CMMI también define un conjunto de cinco metas genéricas y prácticas relacionadas para cada área de proceso. Cada una de las cinco me- tas genéricas corresponde a uno de los cinco niveles de capacidad. Por tanto, para lograr un nivel de capacidad particular deben lograrse la meta genérica para dicho nivel y las prácticas genéricas que correspondan a dicha meta. Para ilustrar, las metas genéricas (MG) y las prácti- cas genéricas (PG) para el área de proceso planificación del proyecto son [CMM07]: MG 1 Logro de metas específicas PG 1.1 Realización de prácticas base MG 2 Institucionalización de un proceso administrado PG 2.1 Establecimiento de una política organizacional PG 2.2 Plan del proceso PG 2.3 Provisión de recursos PG 2.4 Asignación de responsabilidad PG 2.5 Capacitación de personal PG 2.6 Gestión de configuraciones PG 2.7 Identificación e involucramiento de participantes relevantes PG 2.8 Monitoreo y control del proceso PG 2.9 Evaluación objetiva de la adhesión PG 2.10 Revisión de estatus con administración de nivel superior 6 Otras áreas de proceso definidas para “gestión de proyecto” incluyen: monitoreo y control del proyecto, adminis- tración de acuerdo con proveedores, administración de proyecto integrado para IPPD, gestión del riesgo, forma- ción de equipo integrado, gestión de proveedor integrado y gestión de proyecto cuantitativo. www.FreeLibros.me 30Pressman(675-694).indd 687 26/1/10 17:34:15  688 PAR T E C I N C O TE MAS AVANZADOS MG 3 Institucionalización de un proceso definido PG 3.1 Establecimiento de un proceso definido PG 3.2 Recopilación de información de mejoría MG 4 Institucionalización de un proceso administrado cuantitativamente PG 4.1 Establecimiento de objetivos cuantitativos para el proceso PG 4.2 Estabilización de desempeño de subprocesos MG 5 Institucionalización de un proceso de optimización PG 5.1 Aseguramiento del mejoramiento de proceso continuo PG 5.2 Corrección de causas originales de problemas El modelo CMMI por etapas define las mismas áreas de proceso, metas y prácticas que el modelo continuo. La diferencia principal es que el modelo por etapas define cinco niveles de madurez, en lugar de cinco niveles de capacidad. Para lograr un nivel de madurez deben lo- grarse las metas y prácticas específicas asociadas con un conjunto de áreas de proceso. La re- lación entre niveles de madurez y áreas de proceso se muestra en la figura 30.3. I NFOR MACIÓN La CMMI: ¿Se debe o no se debe? La CMMI es un metamodelo de proceso. Define (en más involucran decenas o cientos de personas a lo largo de varios meses de 700 páginas) las características de proceso que deben o años. Puede ser que la CMMI sea “correcta” en tales situaciones si existir si una organización quiere establecer un proceso de software la cultura de la organización es sensible a modelos de proceso están- que sea completo. La pregunta que se ha debatido durante más de dar y si la administración se compromete para convertirlo en éxito. una década es: ¿es excesiva la CMMI? Como la mayoría de las cosas Sin embargo, en otras situaciones, la CMMI simplemente puede ser en la vida (y en el software), la respuesta no es un simple “sí” o “no”. demasiado para que una organización lo asimile con éxito. ¿Esto sig- El espíritu de la CMMI siempre debe adoptarse. Con riesgo de nifica que la CMMI es “mala” o “excesivamente burocrática” o “anti- sobresimplifiación, se argumenta que el desarrollo del software debe cuada”? No..., no lo es. Simplemente significa que lo que es correcto tomarse con seriedad: planificarse a profundidad, controlarse de para una cultura organizacional puede no serlo para otra. manera uniforme, rastrearse con precisión y llevarse a cabo con pro- La CMMI es un logro significativo en ingeniería del software. fesionalismo. Debe enfocarse en las necesidades de los participantes Proporciona un análisis amplio de las actividades y acciones que en el proyecto, en las habilidades de los ingenieros del software y en deben presentarse cuando una organización construye software de la calidad del producto final. Nadie estaría en desacuerdo con estas computadora. Incluso si una organización de software elige no adop- ideas. tar sus detalles, todo equipo de software debe abrazar su espíritu y Los requisitos detallados de la CMMI deben considerarse seria- ganar comprensión de su análisis del proceso y de la práctica de la mente si una organización construye grandes sistemas complejos que ingeniería del software. 30. 4 E L CMM DE PERSONAL PU Un proceso de software, sin importar cuán bien se conciba, no triunfará sin personal de software NT O talentoso y motivado. El Modelo de Madurez de Capacidad de Personal “es un mapa de caminos CLAVE para implementar prácticas que mejoran de manera continua la capacidad de la fuerza de tra- El CMM de personal sugiere prácticas bajo de una organización” [Cur02]. Desarrollado a mediado de los años de 1990 y refinado du- que mejoran la competencia y rante los años siguientes, la meta del CMM de personal es alentar el mejoramiento continuo del cultura de la fuerza laboral. conocimiento de la fuerza laboral genérica (llamadas “competencias centrales”), de las habili- dades específicas de los ingenieros del software y de la administración del proyecto (llamadas “competencias de la fuerza laboral”) y de las habilidades relacionadas con el proceso. Como el CMM, la CMMI y los marcos conceptuales MPS relacionados, el CMM de personal define un conjunto de cinco niveles de madurez organizativa que proporcionan un indicio de la sofisticación relativa de las prácticas y procesos de la fuerza laboral. Dichos niveles de madurez www.FreeLibros.me 30Pressman(675-694).indd 688 26/1/10 17:34:15  C AP Í T UL O 30 MEJORAMIENT O DEL PROCESO DE SOFT WARE 689 FIGURA 30.3 Nivel Enfoque Áreas de proceso Áreas de proceso requeridas para Mejora lograr un nivel de Optimización de proceso Innovación y despliegue organizacional madurez continua Análisis causal y resolución Fuente: [Phi02]. Administrado Administración Desempeño de proceso organizacional cuantitativamente cuantitativa Administración de proyecto cuantitativa Desarrollo de requisitos Solución técnica Integración de producto Verificación Validación Enfoque en proceso organizacional Estandarización Definido Definición de proceso organizacional de proceso Capacitación organizacional Administración de proyecto integrada Administración de proveedor integrada Gestión del riesgo Análisis de decisión y resolución Entorno organizacional para integración Formación de equipo integrado Gestión de requisitos Planificación de proyecto Administración Monitoreo y control del proyecto Administrado básica Administración de acuerdo con proveedor de proyecto Medición y análisis Aseguramiento de calidad de proceso y producto Administración de configuración Realizado [CMM08] se ligan a la existencia (dentro de una organización) de un conjunto de áreas de pro- ceso clave (APC). En la figura 30.4 se muestra un panorama de los niveles organizativos y las APC relacionadas. El CMM de personal complementa cualquier marco conceptual MPS al alentar a una organi- zación a nutrir y mejorar su activo más importante: su personal. Tan importante, que establece una atmósfera de fuerza de trabajo que permite a una organización de software “atraer, desa- rrollar y conservar talento sobresaliente” [CMM08]. 30. 5 OTROS MARCOS CONCEPTUALES M PS Aunque los CMM y CMMI del SEI son los marcos conceptuales MPS de mayor aplicación, se han propuesto algunas alternativas7 que están en uso. Entre las más ampliamente utilizadas se en- cuentran: SPICE: una iniciativa internacional para dar apoyo a la valoración de proceso ISO y a estándares de proceso de ciclo de vida [SPI99] ISO/IEC 15504 para Valoración de Proceso (de Software) [ISO08] Bootstrap: un marco conceptual MPS para organizaciones pequeñas y medianas que se adecua a SPICE [Boo06] 7 Es razonable argumentar que algunos de estos marcos conceptuales no son tanto “alternativas” como enfoques complementarios del MPS. Una tabla exhaustiva de muchos más marcos conceptuales MPS puede encontrarse en www.geocities.com/lbu_measure/spi/spi.htm#p2 www.FreeLibros.me 30Pressman(675-694).indd 689 26/1/10 17:34:15  690 PAR T E C I N C O TE MAS AVANZADOS FIGURA 30.4 Áreas de proceso Nivel Enfoque Áreas de proceso para el CMM de personal Innovación continua de la fuerza laboral Mejoramiento Optimizado Alineación del desempeño organizativo continuo Mejoramiento de capacidad continuo Tutelaje Cuantifica Administración de capacidad organizativa y gestiona Administración de desempeño cuantitativo Predecible conocimiento, Activos basados en competencia capacidades Grupos de trabajo fortalecidos y habilidades Integración de competencia Cultura de participación Identifica y Desarrollo de grupos de trabajo desarrolla Prácticas basadas en competencia Definido conocimiento, Desarrollo profesional capacidades Desarrollo de competencias y habilidades Planificación de fuerza de trabajo Análisis de competencia Compensación Prácticas de Capacitación y desarrollo administración Administración del desempeño Administrado de personal Entorno laboral básicas, repetibles Comunicación y coordinación Dotación de personal Prácticas Inicial inconsistentes PSP y TSP: marcos conceptuales MPS individuales y específicos de equipo ([Hum97], [Hum00]) que se enfocan en procesos micro, un enfoque más riguroso del desarrollo de software acoplado con medición TickIT: método de auditoría [Tic05] que valora el cumplimiento de una organización al Estándar ISO 9001:2000 En los siguientes párrafos se presenta un breve panorama de cada uno de estos marcos concep- tuales MPS. Si tiene más interés está disponible una gran variedad de recursos tanto impresos como en la web. SPICE. El modelo SPICE (Software Process Improvement and Capability dEtermination: determi- ? Además del CMM, ¿existen otros marcos nación de mejoramiento y capacidad del proceso de software) proporciona un marco conceptual conceptuales MPS que de valoración MPS que cumple con ISO 15504:2003 e ISO 12207. La suite de documentos SPICE puedan considerarse? [SDS08] presenta un marco conceptual MPS completo, que incluye un modelo para gestión de proceso, lineamientos para realizar una valoración y clasificación del proceso bajo considera- ción, construcción, selección y uso de instrumentos y herramientas de valoración y capacitación para asesores. Bootstrap. El marco conceptual MPS Bootstrap “se desarrolló para asegurar conformidad con el estándar ISO emergente para valoración y mejoramiento del proceso de software (SPICE) y para alinear la metodología con ISO 12207” [Boo06]. El objetivo de Bootstrap es evaluar un proceso de software, usando un conjunto de mejores prácticas de ingeniería del software como base para la valoración. Como el CMMI, Bootstrap proporciona un nivel de madurez de proceso, empleando los resultados de cuestionarios que recopilan información acerca del proceso de www.FreeLibros.me 30Pressman(675-694).indd 690 26/1/10 17:34:15  C AP Í T UL O 30 MEJORAMIENT O DEL PROCESO DE SOFT WARE 691 software “como es” y proyectos de software. Los lineamientos MPS se basan en nivel de madu- rez y metas organizativas. PSP y TSP. Aunque MPS generalmente se caracteriza como una actividad organizativa, no hay razón por la que el mejoramiento del proceso no pueda realizarse en un nivel individual o de equipo. Tanto PSP como TSP (capítulo 2) enfatizan la necesidad de recopilar datos continua- mente acerca del trabajo que se realiza y de usar dichos datos para desarrollar estrategias para su mejoramiento. Watts Humphrey [Hum97], el desarrollador de ambos métodos, comenta: El PSP [y TSP] le mostrará cómo planificar y rastrear su trabajo y cómo producir software de alta cali- Cita: dad de manera consistente. Al usar PSP [y TSP], contará con los datos que muestran la efectividad de su trabajo y que identifican sus fortalezas y debilidades [...] Para tener una carrera exitosa y gratifi- “Las organizaciones de software cante, necesita conocer sus capacidades y habilidades, luchar por mejorarlas y capitalizar sus talentos muestran limitaciones significa- únicos en el trabajo que realice. tivas en su habilidad para capitalizar las experiencias TickIT. El método de auditoría Ticket garantiza cumplimiento con ISO 9001:200 para software: obtenidas de los proyectos com- pletados.” un estándar genérico que se aplica a cualquier organización que quiera mejorar la calidad global de los productos, sistemas o servicios que ofrece. Por tanto, el estándar es directamente aplica- NASA ble a organizaciones y compañías de software. La estrategia subyacente sugerida por ISO 9001:2000 se describe de la forma siguiente [ISO01]: ISO 9001:2000 subraya la importancia para una organización de identificar, implementar, gestionar y mejorar continuamente la efectividad de los procesos que son necesarios para el sistema de gestión de la calidad, y de administrar las interacciones de dichos procesos con la finalidad de lograr los ob- jetivos de la organización [...] La efectividad y eficiencia del proceso pueden valorarse a través de procesos de revisión interna o externa y evaluarse sobre una escala de madurez. WebRef ISO 9001:2000 adoptó un ciclo de “planificar-hacer-verificar-actuar” que se aplica a los elemen- Un excelente resumen de ISO tos de gestión de la calidad de un proyecto de software. Dentro de un contexto de software, 9001:2000 puede encontrarse en “planificar” establece los objetivos, actividades y tareas del proceso, necesarios para lograr soft- http://praxiom.com/iso- ware de alta calidad y la resultante satisfacción del cliente. “Hacer” implementa el proceso de 9001.htm software (incluidas tanto actividades de marco conceptual como sombrilla). La “verificación” monitorea y mide el proceso para asegurar que se lograron todos los requisitos establecidos para gestión de la calidad. Al “actuar”, se inician las actividades de mejoramiento del proceso de software que trabajan continuamente para mejorar el proceso. TickIt puede usarse a través del ciclo “planificar-hacer-verificar-actuar” a fin de garantizar que el proceso MPS avanza. Los auditores TickIT valoran la aplicación del ciclo como un precursor de la certificación ISO 9001:2000. Para un análisis detallado de ISO 9001:2000 y TickIT debe examinar [Ant06], [Tri05] o [Sch03]. 30. 6 RENDIMIENTO SOBRE INVERSIÓN DE M PS El MPS representa un trabajo duro y requiere inversión sustancial de dinero y de personal. Los administradores que aprueben el presupuesto y los recursos para MPS invariablemente plantea- rán la pregunta: ¿cómo sé que lograremos un rendimiento razonable por el dinero que gaste- mos? Cualitativamente, quienes impulsan MPS arguyen que un proceso de software mejorado conducirá a calidad de software mejorada. Afirman que el proceso mejorado dará como resul- tado la