Cómo fortalecer la gestión de requisitos de software y mejorar la calidad del software

1. ¿Qué es la calidad? Como vendedores, comercializadores o mantenedores de productos de software, a menudo reciben acusaciones o quejas de los clientes: la calidad de su producto es demasiado mala, inestable, etc. ¿Qué es entonces la calidad? ¿Cómo medimos la calidad? La calidad tiene tres dimensiones: ? Adecuación al propósito. Los objetivos los definen los clientes. Cumplirlos significa que podemos juzgar si estamos haciendo lo que hay que hacer. ? Satisfacer las necesidades. Es decir, si el producto está haciendo lo que se le dice que haga. ? Satisfacer las necesidades reales. Los requisitos reales incluyen los requisitos explícitos e implícitos de los usuarios. La definición de calidad de ISO es la siguiente: "Todas las características de una entidad (producto o servicio) en función de las cuales se pueden satisfacer necesidades explícitas o implícitas". Tenga en cuenta que esta definición incluye tanto las necesidades explícitas como las implícitas. Y muchas veces ignoramos las necesidades implícitas. Por tanto, en el proceso de control de la calidad de un producto, debemos prestar atención a estos requisitos implícitos y darles la debida verificación. Por otro lado, debido a que nuestros productos brindan servicios a los clientes, consideramos que cualquier cosa que no satisfaga las necesidades del cliente es un fracaso. Por lo tanto, nuestros productos siempre deben desarrollarse y validarse en función de las necesidades del cliente. Aquí hablamos de clientes. De hecho, durante el proceso de recopilación de requisitos de un software, debemos prestar atención a los clientes y usuarios. Y muchas veces pasamos por alto la diferencia entre clientes y usuarios. ¿Quiénes son entonces los clientes? ¿Quiénes son los usuarios? En pocas palabras, los clientes son las personas que realmente pueden decidir si compran su software, mientras que los usuarios son las personas que realmente utilizan el software. Comprender esta diferencia puede ser una referencia para usted a la hora de analizar la importancia de los requisitos. Al mismo tiempo, también se pueden hacer diferentes concesiones al verificar la calidad del producto. Por otro lado, cuando consideramos las necesidades de nuestros usuarios, a menudo solo consideramos a las personas que realmente usan el software e ignoramos los requisitos de otras personas para el software o la competencia potencial por el software, incluidos los requisitos del personal de mantenimiento. y los requisitos de los administradores del sistema, los requisitos del personal ascendente y descendente del software, el estado de las versiones anteriores, el estado del software de los competidores en el mercado, etc. Cuando todos mencionan la calidad, a menudo se encuentran con las siguientes contradicciones, que implican un compromiso con la calidad 5: ? La calidad requiere un compromiso, especialmente el compromiso de los altos directivos. Pero para lograr calidad, los altos directivos deben trabajar en estrecha colaboración con las personas que emplean; mucha gente cree que los productos y servicios libres de defectos son imposibles. Sin embargo, es normal y aceptable controlar el número de defectos hasta cierto nivel; la calidad suele estar estrechamente relacionada con el coste, y un producto de alta calidad también implica una gran inversión. Ésta es una contradicción entre la calidad del diseño y la calidad de la coherencia. Un requisito de alta calidad requiere especificaciones que sean suficientemente detalladas para que el producto pueda analizarse cuantitativamente con respecto a esas especificaciones. Sin embargo, muchas organizaciones no pueden o no quieren producir especificaciones con este nivel de detalle; el personal técnico a menudo cree que las especificaciones y los estándares limitan su creatividad y, por lo tanto, no siguen los estándares. Sin embargo, si desea obtener un producto de alta calidad, debe seguir estándares y procesos bien definidos. 2. La contribución de los procesos a la calidad. Ahora que hemos entendido qué es la calidad, ¿cómo podemos mejorar la calidad de los productos de software? Desde la perspectiva del desarrollo a largo plazo de una empresa, primero debemos comenzar con el proceso y estandarizar el proceso de desarrollo de productos de software. Esta es la única manera para que una empresa de software pase de un método de producción de pequeño taller a una gran empresa integrada y estandarizada. También es un medio clave para resolver fundamentalmente problemas de calidad y mejorar la eficiencia del trabajo. El desarrollo de productos de software tiene las mismas características que la producción de otros productos (como los automóviles), es decir, debe producirse de acuerdo con un proceso determinado. En el mundo industrial, el método de producción en línea de montaje ha demostrado ser una forma eficiente y relativamente estable de garantizar la calidad del producto. De esta manera, diferentes personas se organizan en diferentes posiciones en el proceso y, en última instancia, trabajan juntas para lograr un objetivo. Esto puede evitar la fricción interna en la sala de trabajo del personal y mejorar en gran medida la eficiencia del trabajo. Y debido a que su proceso se deriva de ejemplos exitosos, la calidad del producto final puede cumplir con los requisitos de alcance establecidos por el proceso. La ingeniería de software ha aprendido esta experiencia en el proceso de desarrollo de software y la ha aplicado al desarrollo de software. Esto forma el proceso de ingeniería de software, que es simplemente el proceso de desarrollo. No importa lo que haga, existe un proceso paso a paso, desde la planificación hasta la estrategia y la implementación.

El proceso de software define el proceso de desarrollo basándose en este tipo de pensamiento. Define un conjunto completo de procesos desde los requisitos hasta la entrega del producto final en función de diferentes características del producto y experiencias exitosas pasadas. El proceso nos indica cómo implementar el producto paso a paso, qué riesgos puede haber, cómo evitar riesgos, etc. Dado que el proceso proviene de una experiencia exitosa, desarrollarlo de acuerdo con el proceso puede ayudarnos a evitar desvíos y mejorar efectivamente la calidad del producto y la satisfacción del usuario. Actualmente existen muchos métodos de proceso populares y diferentes modelos de proceso son adecuados para diferentes tipos de proyectos. El modelo en cascada es el modelo más utilizado y el más fácil de entender y dominar. Sin embargo, sus defectos también son obvios. Los requisitos faltantes o los requisitos cambiantes pueden confundir el modelo. Sin embargo, para proyectos que son fáciles de entender pero complejos, un modelo en cascada sería más apropiado porque puede abordar problemas complejos paso a paso. Este modelo funciona particularmente bien cuando los requisitos de calidad son mayores que los requisitos de costo y cronograma. El modelo espiral es un modelo clásico que se centra en identificar y reducir los riesgos del proyecto 8 . Los proyectos en espiral comienzan a pequeña escala, luego detectan riesgos, formulan un plan de control de riesgos, luego determinan si el proyecto debe continuar en el siguiente paso y luego iteran hacia la siguiente espiral. La mayor ventaja de este modelo es que a medida que aumentan los costos, el nivel de riesgo disminuye. Sin embargo, la desventaja del modelo en espiral es que es más complejo y requiere que los gerentes sean responsables, enfocados y experimentados en la gestión. RUP (Rational Unified Process) es un conjunto de modelos de procesos de desarrollo propuestos por Rational Corporation. Es un proceso de negocios común para la ingeniería de software orientada a objetos 9. Describe una serie de procesos de ingeniería de software relacionados que tienen la misma estructura, es decir, la misma arquitectura de proceso. RUP proporciona un método estandarizado para asignar tareas y responsabilidades dentro de una organización de desarrollo, con el objetivo de garantizar que el software de alta calidad que satisfaga las necesidades del usuario final se desarrolle dentro de un cronograma y presupuesto predecibles. RUP tiene dos ejes, uno es la línea de tiempo, que es dinámico. El otro es el eje del flujo de trabajo, que es estático. En el cronograma, RUP se divide en cuatro fases: fase inicial, fase de refinamiento, fase de construcción y fase de lanzamiento. El concepto de iteración se utiliza en cada etapa. En el eje del flujo de trabajo, RUP ha diseñado seis flujos de trabajo principales y tres flujos de trabajo de soporte principales. El eje del flujo de trabajo principal incluye: flujo de trabajo de modelado de negocios, flujo de trabajo de requisitos, flujo de trabajo de análisis y diseño, flujo de trabajo de implementación y flujo de trabajo de prueba y flujo de trabajo de publicación. Los flujos de trabajo de soporte principales incluyen: flujo de trabajo del entorno, flujo de trabajo de gestión de proyectos y flujo de trabajo de gestión de cambios y configuración. Consulte la Figura 1 para obtener más detalles. RUP reúne las mejores prácticas en el desarrollo de software moderno y proporciona un formato flexible para adaptarse a las necesidades de diversos proyectos y organizaciones. Como modelo de negocio, tiene plantillas y guías de procesos muy detalladas. Sin embargo, debido a que el modelo es relativamente complejo, se requiere un costo relativamente alto para dominarlo. En particular, impone exigencias relativamente altas a los directores de proyectos. Figura 1 Diagrama de flujo de trabajo de RUP El proceso IPD (Desarrollo integrado de productos) es un conjunto de procesos integrados de desarrollo de productos propuestos por IBM. Es muy adecuado para proyectos de desarrollo complejos a gran escala, especialmente proyectos que involucran la combinación de software y hardware. IPD comienza desde la perspectiva de todo el producto, y el proceso considera de manera integral todos los procesos desde la ingeniería de sistemas, la investigación y el desarrollo (hardware, software, diseño industrial estructural, pruebas, desarrollo de datos, etc.), fabricación, finanzas hasta marketing, adquisiciones, soporte técnico, etcétera. Es un proceso de principio a fin. El proceso IPD se divide en seis etapas (etapa de concepto, etapa de planificación, etapa de desarrollo, etapa de verificación, etapa de lanzamiento y etapa de ciclo de vida) y cuatro puntos de revisión de decisiones (punto de revisión de decisiones de la etapa de concepto, punto de revisión de decisiones de la etapa de planificación, puntos de revisión de decisiones de disponibilidad y puntos de revisión de decisiones al final de la vida útil) y seis puntos de revisión técnica; consulte la Figura 2 para obtener más detalles. El proceso IPD es un modelo por etapas con sombras del modelo en cascada. Este modelo descompone un sistema grande y complejo y reduce los riesgos mediante el uso de procesos integrales y complejos. Hasta cierto punto, este modelo utiliza los costos de proceso para mejorar la calidad de todo el producto y ganar participación de mercado. Dado que este proceso no define un mecanismo para la reversión del proceso, este proceso no es adecuado para proyectos con requisitos que cambian con frecuencia.

Y para algunos proyectos pequeños, este proceso no es muy adecuado. Figura 2 Diagrama de proceso IPD 3. Proceso y tecnología Proceso y éxito no son equivalentes. El éxito sin un proceso es imposible de garantizar, pero tener un proceso no significa que el éxito esté garantizado. Probablemente esto sea inaceptable para muchas personas que son supersticiosas con respecto a los procesos. Pero es verdad. Recuerdo que un experto en análisis de necesidades que lo ha estado haciendo durante casi 30 años dijo: Incluso una empresa que haya alcanzado el nivel CMM4 puede no ser capaz de hacer un buen trabajo en el análisis de necesidades. ¿Por qué? La tecnología, la tecnología es otra condición necesaria para el éxito. Al igual que ahora quiere ir de Shanghai a Beijing. El proceso le indica el camino más corto y la tecnología le proporciona el medio de transporte más rápido. La combinación de los dos es perfecta. Para el desarrollo de software, para garantizar la calidad del software, es necesario dominar muchos aspectos de la tecnología, incluida la tecnología de análisis, la tecnología de diseño, la tecnología de codificación, la tecnología de prueba, etc. Hay un fenómeno anormal común en China, es decir, la gente piensa que sólo la capacidad de programación es la verdadera habilidad para jugar con las computadoras. Al igual que construir una casa, nada más importa, siempre y cuando el albañil tenga excelentes habilidades. Aunque esta analogía apagará el ego de muchos programadores, de hecho es un hecho. Carecemos de ingenieros a nivel de sistemas y nuestro trabajo en análisis y diseño no es sólido. Los requisitos son el alma de un proyecto. La consecuencia inevitable de requisitos ambiguos es la reelaboración: rehacer algo que creía haber hecho bien. El retrabajo costará el 40% del costo total de desarrollo, y entre el 70% y el 85% del retrabajo se debe a errores de requisitos (leffingwell 1 9 9 7) 10. ¿Imagínese si pudiera reducir su retrabajo a la mitad? Puede desarrollar productos más rápido, desarrollar más y mejores productos en la misma cantidad de tiempo e incluso llegar a casa y tomar un descanso de vez en cuando. El libro "Requisitos de software" ofrece una introducción relativamente detallada sobre cómo realizar el análisis de requisitos 7 y la orientación sobre los requisitos en RUP también es muy práctica. El diseño es el eslabón que mejor refleja la capacidad y el nivel de un ingeniero. Un buen diseño determina básicamente la calidad final del producto. El diseño es un paso clave para convertir los requisitos en un sistema. Requiere encontrar la unidad básica de diseño a partir de los requisitos descritos en lenguaje natural y construir la arquitectura de todo el sistema. El posicionamiento de los arquitectos y diseñadores de sistemas en RUP es bastante alto. Las habilidades de diseño van desde el diseño estructurado tradicional hasta el diseño orientado a objetos. Los diseñadores necesitan dominar ciertas técnicas de modelado. UML es un lenguaje de modelado relativamente popular en el mundo 11 . En el lado integrado, SDL también es una muy buena opción. "Design Patterns" es un excelente libro 6 que resume el pensamiento de diseño. Como diseñador (especialmente un diseñador orientado a objetos), debes estudiarlo detenidamente. Sin embargo, la aplicación de estos patrones debe prestar atención a una aplicación natural. Nunca diseñe un patrón debido al patrón, de lo contrario será contraproducente. Los programadores de hoy están interesados ​​en dominar múltiples lenguajes de programación o prestar atención a las habilidades técnicas excesivas en los lenguajes, pero a menudo ignoran la estandarización de los lenguajes de programación. La aplicación irregular del lenguaje causa un gran daño a la comprensibilidad, mantenibilidad y capacidad de prueba del programa, dañando así la calidad del producto. Una vez, una empresa realizó una prueba con programadores chinos y programadores indios. Esta prueba requirió que los participantes ordenaran un conjunto de números. Los resultados de la prueba encontraron que el algoritmo utilizado por el programa diseñado por los programadores indios no era óptimo, pero era el menos propenso a errores y los códigos escritos por varios programadores eran exactamente iguales. Algunos de los códigos escritos por varios programadores chinos son muy hermosos, muy concisos y muy eficientes; algunos son muy complicados y contienen errores; Si está realizando proyectos de investigación o proyectos puramente de interés, entonces no hay nada de malo en aprovechar al máximo su genio de la programación. Sin embargo, para una empresa de software, el producto debe finalmente entregarse al usuario y lo que se debe seguir es un proyecto de desarrollo de producto de software. Por lo tanto, el desarrollo de este tipo de software debe seguir ciertos estándares de programación. Después de todo, el software desarrollado no es para uso propio, sino que también debe integrarse con otros y debe reutilizarse y mantenerse para futuras versiones. Las técnicas de prueba se explicarán en la Sección 5. En resumen, el proceso es crucial y la tecnología también es muy importante. Mi punto de vista es: no puedes quedarte con el pastel y comértelo también.

4. Gestión de la calidad total Desde que los principios de la Gestión de la calidad total (TQM) de Deming lograron un gran éxito en la industria japonesa, este principio se ha extendido rápidamente a todas partes del mundo. De manera similar, los principios de la Gestión de la calidad total también se han aplicado al desarrollo de software. Como se mencionó anteriormente, el desarrollo de software también es un trabajo de ingeniería, por lo que se debe mejorar la calidad de todo el proyecto. Numerosos estudios en la industria (TRW, Nippon Electric y Mitre Corp., entre otros) indican que los errores introducidos por las actividades de diseño representan del 50 al 65 por ciento de todos los errores (y en última instancia, defectos) que ocurren en el proceso del software. Según la investigación de IBM, suponiendo que el costo de corrección de un error encontrado durante la fase de análisis es de 1 unidad, entonces el costo de corrección de un error descubierto antes de la prueba (fase de diseño y codificación) es de aproximadamente 6,5 unidades monetarias durante la prueba (prueba de integración). , pruebas del sistema y pruebas de aceptación), el costo de modificar un error encontrado es de aproximadamente 15 unidades monetarias, mientras que el costo de modificar un error encontrado después del lanzamiento (ya en manos de los usuarios) es de aproximadamente 60 a 100 unidades monetarias. La misma proporción se aplica al tiempo que lleva encontrar un error. Podemos observar las dos curvas siguientes: Figura 3 Curva de costos de defectos Para mejorar la calidad del producto, acortar el progreso del desarrollo del producto y ahorrar costos de desarrollo del producto, el control de calidad del producto debe realizarse lo antes posible. El control de calidad total requiere actividades rigurosas de verificación y validación en cada etapa y paso del proceso. ¿Qué es la verificación? La verificación consiste en utilizar datos para demostrar si estamos fabricando el producto correctamente. Tenga en cuenta que el énfasis aquí está en la línea correcta del procedimiento 12. ¿Qué es la confirmación? La confirmación consiste en utilizar datos para demostrar si hemos fabricado el producto correcto. Tenga en cuenta que el énfasis aquí está en la exactitud de los resultados. El proceso de verificación y validación dado por IEEE se puede representar en la siguiente figura. La verificación y validación es un concepto amplio y los lectores interesados ​​pueden consultar la norma IEEE Std 1012-1998.

Figura 4 Modelo de Verificación y Validación 5. Enfoque en las pruebas Las pruebas de software son una actividad clave en el control de calidad del software. Las estadísticas de la industria muestran que el costo de las pruebas representa aproximadamente el 50% del costo total del desarrollo de software. El propósito de las pruebas de software es encontrar errores en el software. Una buena prueba es encontrar errores que no hayan sido detectados hasta ahora. Las pruebas de software tradicionales se centran en categorías de pruebas dinámicas, como pruebas unitarias, pruebas de integración y pruebas de sistemas. El desarrollo de la ingeniería de pruebas ha entrado en todo el proceso de pruebas, incluidas las pruebas estáticas en la etapa inicial del proceso de desarrollo. Generalmente podemos dividir las pruebas en pruebas de caja blanca y pruebas de caja negra. Pruebas de caja blanca: como sugiere el nombre, las pruebas de caja blanca deben ser transparentes. De hecho, este tipo de prueba se basa en la estructura lógica interna del código del programa para diseñar casos de prueba para las pruebas. Entonces, ¿qué son los casos de prueba? Un caso de prueba es un documento que describe la entrada, la acción o el momento y un resultado esperado, cuyo propósito es determinar si una característica de la aplicación está funcionando correctamente. Pruebas de caja negra: después de leer la explicación de las pruebas de caja blanca, creo que puedes adivinar rápidamente que las pruebas de caja negra no consideran la estructura interna del programa. De hecho, esto también es cierto. Las pruebas de caja negra son pruebas basadas en especificaciones. Las especificaciones registran las necesidades del usuario. Por ejemplo, si un usuario desea agregar una función de búsqueda al editor, escribimos el requisito en la especificación y, según el requisito, llamamos directamente a la función de la aplicación para realizar pruebas, independientemente del algoritmo que se utilice para implementarla. internamente. Los dos tipos de pruebas, caja blanca y caja negra, parten de puntos de partida completamente diferentes y son dos puntos completamente opuestos, lo que refleja los dos extremos de las cosas. Los dos métodos tienen su propio énfasis y no pueden reemplazarse. Sin embargo, en los conceptos de prueba modernos, estas dos pruebas a menudo no están completamente separadas. Generalmente, el método de prueba de caja negra se usa de manera transversal en las pruebas de caja blanca y el método de prueba de caja blanca se usa de manera transversal en las pruebas de caja negra. Una prueba de caja blanca común es la prueba unitaria. La prueba unitaria es la unidad de prueba más pequeña. En resumen, se trata de tomar una función, agregar un módulo controlador y un módulo auxiliar para ejecutarla y luego diseñar algunos casos de uso para probar sus puntos de control internos (como puntos de juicio condicionales, puntos de bucle, puntos de ramificación seleccionados, etc.). .) . El módulo controlador es una función que simula llamar a la función bajo prueba. La función stub es una función que simula la función llamada por la función de prueba actual. Las pruebas de caja negra comunes incluyen: pruebas de integración y pruebas de sistemas.

Las pruebas de integración se basan en pruebas unitarias, ensamblando todos los módulos en subsistemas o sistemas de acuerdo con los requisitos de diseño (como según el diagrama de estructura) para las pruebas de integración. La práctica demuestra que, aunque algunos módulos pueden funcionar de forma independiente, no hay garantía de que funcionen correctamente cuando estén conectados. Es probable que los problemas que no se puedan reflejar en algunas partes del programa queden expuestos globalmente y afecten la realización de funciones. El propósito de las pruebas del sistema es descubrir dónde el software no se ajusta o contradice la definición del sistema comparándolo con la definición de requisitos del sistema. Los casos de prueba para las pruebas del sistema deben diseñarse de acuerdo con las especificaciones del análisis de requisitos y ejecutarse en el entorno de uso real. El contenido de las pruebas del sistema es extremadamente extenso e incluye pruebas funcionales, pruebas de protocolo, pruebas de rendimiento, pruebas de estrés, pruebas de capacidad, etc. Para obtener más información sobre conceptos de prueba, consulte mi "Introducción a la tecnología de prueba de software" publicada. Las pruebas de software son la última línea de defensa antes de que el producto llegue finalmente a los usuarios y desempeñan un papel decisivo. Sin embargo, no es fácil hacer un buen trabajo en las pruebas de software. Por un lado, es necesario dominar tanto las habilidades de desarrollo de software como las de prueba de software; por otro, el producto debe proporcionar suficiente independencia y garantía de recursos para las pruebas; 6. El Triángulo de Hierro del Éxito En una empresa de software, si puede desarrollarse sanamente, debe prestar atención a la relación entre organización, proceso y personas. La organización es la garantía para la implementación exitosa del proceso. Una buena estructura organizacional puede promover efectivamente la implementación del proceso; el proceso juega un papel clave en el éxito del producto. Un proceso adecuado a las características de la organización y las características. del producto puede mejorar en gran medida la eficiencia y eficacia del desarrollo del producto; de lo contrario, retrasará el progreso del desarrollo del producto y no se puede garantizar la calidad para las empresas, las personas son la riqueza más preciada y son portadoras de tecnología; Para una empresa de software, tanto los desarrolladores como los evaluadores están muy preocupados por su camino de desarrollo futuro. Si existe una línea de desarrollo técnico clara que indique la dirección del desarrollo profesional futuro, esto puede estimular enormemente la moral y la motivación laboral. Además, la dirección del desarrollo tecnológico debe combinarse con los procesos y especificaciones de desarrollo actuales, lo que favorece la mejora de las habilidades profesionales. En resumen, la organización, los procesos y las personas son el triángulo de hierro del éxito de una empresa. Idealmente, se promueven mutuamente y, en malas circunstancias, se restringen mutuamente. 7. Estándares de calidad internacionalmente populares Los primeros estándares de calidad que ingresaron al país fueron la serie ISO. En términos de software, se utiliza principalmente la serie de estándares ISO9000. ISO9000 es una norma muy completa y define todos los elementos necesarios para que un proveedor pueda diseñar y entregar un producto de calidad. ISO9002 cubre estándares de calidad considerados importantes para que los proveedores controlen las actividades de diseño y desarrollo. ISO9003 se utiliza para demostrar la capacidad de un proveedor para detectar y controlar inconsistencias en los productos durante la inspección y las pruebas. ISO9004 describe los estándares de calidad relacionados con ISO9001, ISO9002 e ISO9003 y proporciona una lista de verificación de calidad completa. El modelo de madurez de la capacidad del software es un estándar de calidad muy popular entre las empresas de software nacionales. Y el estándar se ha convertido en un estándar de facto en la industria. El CMM proporciona un marco de gestión rector para las organizaciones de software. Bajo la guía de este marco: ? Las organizaciones de software pueden obtener control sobre sus procesos de desarrollo y mantenimiento de software. ? Las organizaciones de software pueden promover que su ingeniería de software sea más científica y que su gestión de procesos de software sea más excelente. ? CMM puede guiar a las organizaciones de software para elegir la estrategia correcta de mejora de procesos de software determinando la madurez de la gestión de procesos de software actual e identificando cuestiones clave y críticas en la calidad del software y la mejora de procesos. ? CMM centra su atención en una serie de actividades de procesos de software específicas y logra estas actividades de manera agresiva. Una organización de software puede mejorar de manera constante y continua todo su proceso de organización de software, de modo que sus capacidades de gestión de procesos de software puedan lograr una mejora continua y duradera. En CMM, la fábrica de software se divide en cinco niveles: nivel inicial, nivel repetible, nivel definido, nivel de gestión y nivel de optimización. Entre ellos: Nivel inicial: el proceso del software es un proceso aleatorio indefinido y la ejecución del proyecto es aleatoria o incluso caótica. Quizás algunas empresas hayan desarrollado algunas especificaciones de ingeniería de software, pero si estas especificaciones no cubren los requisitos básicos del proceso clave y su implementación no está garantizada por políticas, recursos, etc., entonces todavía se considera un nivel inicial.

Nivel repetible: basándose en años de experiencia y lecciones, la gente ha llegado a la conclusión de que el problema principal en el desarrollo de software no es un problema técnico sino un problema de gestión. Por lo tanto, el enfoque de segundo nivel está en el proceso de gestión del software. Un proceso manejable es un proceso repetible, y sólo un proceso repetible puede mejorar y madurar gradualmente. El proceso de gestión repetible incluye cinco aspectos: gestión de la demanda, gestión de proyectos, gestión de calidad, gestión de configuración y gestión de subcontratos. El proceso de gestión de proyectos se divide en proceso de planificación y proceso de seguimiento y seguimiento; Al implementar estos procesos, una perspectiva de gestión puede ver un proceso de desarrollo de software que se ejecuta según lo planeado y tiene etapas controlables. Nivel definido: Requiere el desarrollo de estándares de ingeniería para toda la empresa y la integración de estos estándares en el proceso de estándares de desarrollo de software empresarial. Todos los proyectos desarrollados deben adaptar un proceso apropiado al proyecto basado en este proceso estándar y ejecutarlo de acuerdo con el proceso. La adaptación del proceso no es arbitraria y debe ser aprobada por el personal pertinente de la empresa antes de su uso. Nivel de gestión: todos los procesos deben establecer métodos de medición correspondientes, y la calidad de todos los productos (incluidos los productos de trabajo y los productos finales enviados a los usuarios) debe tener indicadores de medición claros. Estas medidas deben ser exhaustivas y pueden utilizarse para comprender y controlar el proceso y el producto del software. El control cuantitativo hará que el desarrollo de software sea verdaderamente una actividad de producción industrial. Nivel de optimización: El objetivo es alcanzar un estado de mejora continua. La llamada mejora continua significa que el siguiente paso de ejecución se puede mejorar en función de la información de retroalimentación de la ejecución del proceso, es decir, optimizando los pasos de ejecución. Si una empresa alcanza el quinto nivel, significa que puede ajustar continuamente el proceso de producción de software para lograr el mejor rendimiento en función de la naturaleza, la tecnología y otros factores reales del proyecto. El Departamento de Defensa de EE. UU. estipula que el software con un alto nivel de importancia debe ser realizado por empresas con un alto nivel de calidad. La calidad del software presentado por diferentes niveles de empresas de software también varía mucho. Los datos estadísticos extranjeros son los siguientes: Tabla 1. Relación entre el nivel de CMM y la calidad del software.

Nivel de madurez del proceso de software

Porcentaje de software entregado a tiempo

Líneas de programa producidas por persona por mes

Porcentaje de software que requiere reelaboración

Tiempo medio de fallo de software (aproximado)

Mayor a 10

Nivel inicial

<=50

Z

>=45

De 2 a 60 minutos

Menos de 10

Nivel repetible

90

1,5 Z

20

1-160 horas

Menos de 1

Nivel definido

99

2.5Z

10

Incierto

Menos de 0.1

Nivel de gestión

Reducir Tiempo de desarrollo hasta 1/2

5 Z

5

Incierto

Menos de 0,01

Nivel de optimización

Reduce el tiempo de desarrollo a 1/4

10Z

<=2

Aproximadamente completamente confiable

Para Para muchas empresas que han implementado o se están preparando para implementar CMM, es difícil comenzar con CMM, por lo que Humphrey también propuso PSP (Person Software Process) y TSP (Team Software Process) 2 3. CMM es el primer paso en la mejora de procesos. Proporciona un método de gestión para evaluar las capacidades de la organización, identificar necesidades de mejora prioritarias y realizar un seguimiento del progreso de las mejoras 1 . Sólo después de que las empresas comiencen a mejorar CMM podrán aceptar el hecho de que se necesita planificación, darse cuenta de la importancia de la calidad, centrarse en la capacitación frecuente de los empleados, asignar razonablemente el personal del proyecto y establecer equipos de proyecto eficaces. Sin embargo, su éxito es inseparable de la participación activa y las actividades creativas del personal relevante dentro de la organización. PSP puede guiar a los ingenieros de software sobre cómo garantizar la calidad de su propio trabajo, estimar y planificar su propio trabajo, medir y rastrear el desempeño personal y administrar su propio proceso de software y la calidad del producto.

Después de una capacitación formal en el aprendizaje y la práctica de PSP, los ingenieros de software pueden utilizar completamente PSP en el trabajo del proyecto en el que participan, contribuyendo así a la realización de los objetivos de CMM. TSP combina los métodos de gestión de CMM y las habilidades de ingeniería de PSP, diciéndoles a los ingenieros de software cómo combinar procesos individuales en procesos de software grupales y vincular estos últimos con la organización y luego con todo el sistema de gestión diciéndole a la gerencia cómo respaldar y autorizar; El equipo del proyecto, insiste en el trabajo de alta calidad y gestiona proyectos basados ​​en datos, mostrando a las organizaciones cómo aplicar los principios de CMM y las habilidades de PSP para producir productos de alta calidad. Existen grandes cambios y diferencias en el proceso de producción de software y muchos otros subprocesos, desarrolladores y usuarios de software y uso del sistema. Para que un proceso de software sea realmente útil para mejorar la producción de software, su marco debe ser un sistema completo compuesto por CMM. TSP y PSP, que brinda orientación y soporte para buenas prácticas de ingeniería y gestión de software en tres niveles: organizacional, grupal e individual. En definitiva, la simple implementación de CMM nunca puede realmente mejorar la madurez de la capacidad. Sólo combinando orgánicamente la implementación de CMM con la implementación de PSP y TSP se puede lograr la mayor efectividad. 8. ¿Cómo empezar? La mejora de la calidad cuesta dinero, por lo que la forma de mejorarla debe considerarse de manera integral en función del tamaño, el negocio, el estado financiero, el personal y el nivel técnico de las diferentes empresas y otros aspectos. Generalmente se recomienda que las empresas de software más grandes, de tamaño mediano o superior, implementen un sistema CMM. Para algunas pequeñas empresas de software, pueden adoptar aspectos más prácticos, de costo relativamente bajo y fáciles de operar. Estos aspectos son aproximadamente los siguientes: implementar un sistema de proceso de desarrollo simple y elegir el modelo en cascada, el modelo iterativo, etc. a diferentes características comerciales, y realizar los cambios apropiados en estos modelos para adaptarse a las características del desarrollo de productos corto, plano y rápido. ? Mejorar el análisis de requisitos y las tecnologías de diseño, tales como: tecnología de creación de prototipos, patrones de análisis, patrones de diseño, diseño orientado a objetos, UML, etc.; La documentación es la retención de experiencia. Para que una empresa logre un desarrollo a largo plazo, debe fortalecer el trabajo de documentación; ? Fortalecer el trabajo de estandarización de la programación; se recomienda realizar pruebas unitarias y de sistemas; fortalecer el control de versiones; ? Llevar a cabo actividades de lectura, revisión e inspección, especialmente lectura de código, y se recomienda realizar actividades de lectura cruzada diarias; ? Realizar análisis métricos simples y obtener;