Sqa (pruebas de software) 5 reglas

La Garantía de Calidad del Software (SQA) es el establecimiento de un enfoque planificado y sistemático para asegurar a la dirección que los estándares, procedimientos, prácticas y métodos propuestos pueden ser adoptados correctamente en todos los proyectos.

El propósito del aseguramiento de la calidad del software es hacer que el proceso del software sea visible para los gerentes. Verifica que el software cumpla con los estándares mediante revisiones y auditorías de productos y actividades de software. El grupo de Garantía de Calidad del Software trabaja en conjunto al comienzo del proyecto para establecer planes, estándares y procesos. Estos permitirán que el proyecto de software cumpla con los requisitos de las políticas institucionales.

1. Objetivos Básicos

Objetivo 1: El trabajo de aseguramiento de la calidad del software se realiza de forma planificada.

Objetivo 2: Verificar objetivamente que los productos y el trabajo del proyecto de software siguen los estándares, procedimientos y requisitos adecuados.

Objetivo 3: Informar a grupos e individuos relevantes sobre los esfuerzos y resultados de aseguramiento de la calidad del software.

Objetivo 4: La alta dirección está expuesta a problemas de no conformidad que no pueden resolverse dentro del proyecto.

2. El origen del control de calidad

Sabemos que en muchas grandes empresas extranjeras, la responsabilidad del control de calidad son las pruebas (principalmente pruebas de sistemas), como IBM, CA, PeopleSoft, etc. De hecho, al principio casi todas las empresas eran así. Más tarde, debido a la falta de una planificación y gestión de proyectos efectivas, quedaba muy poco tiempo para las pruebas del sistema (nota: en un proyecto en el que trabajé antes, el gerente del proyecto me dijo claramente que las pruebas del sistema solo durarían un día). , sin negociación). Además, los requisitos cambian demasiado rápido. Sin una documentación completa de los requisitos, los evaluadores sólo pueden realizar pruebas basándose en su propia imaginación. Como resultado, es difícil garantizar la calidad del producto mediante pruebas, y surge la función de control de calidad de las medidas preventivas.

La prevención previa se basa en realidad en la idea de TQM y también está en línea con el principio de la ingeniería de software de que "cuanto antes se descubran los defectos, cuanto antes se modifiquen, más económicos que son." El origen de estas ideas también se remonta a antiguas alusiones chinas, como la migración de Qu Tu a Xin, la discusión de Bian Que sobre las habilidades médicas, etc. En particular, vi accidentalmente la alusión a la discusión de Bian Que sobre las habilidades médicas en un artículo en el extranjero (y más tarde también la vi en el artículo de Lin Rui). A menudo lamenté que nuestro pueblo chino casi haya perdido la herencia ideológica y cultural de nuestros antepasados.

3. La situación actual del QA

Actualmente, cada vez más empresas están implementando CMM. El modelo CMM requiere el establecimiento de roles de control de calidad. El control de calidad aquí es similar a la policía de procesos. Su principal responsabilidad es verificar si las actividades de desarrollo y gestión son consistentes con las estrategias, estándares y procedimientos de proceso establecidos, y verificar si los productos del trabajo siguen el contenido y el formato especificado por la plantilla. En estas empresas, generalmente se requiere que el control de calidad sea independiente del equipo del proyecto para garantizar la objetividad de la evaluación. Desde una perspectiva nacional, la mayoría del personal de control de calidad no tiene experiencia técnica y la mayoría de las desviaciones que detectan son triviales. Además, no tienen una experiencia convincente y sus líderes no los apoyan. hazlo.

La falta de confianza y apoyo es solo un aspecto, el trabajo de control de calidad en sí es un gran desafío. Requiere que el control de calidad tenga conocimientos de ingeniería de software, desarrollo de software, experiencia en la industria, estadística matemática, gestión de proyectos, gestión de calidad, etc.

A menudo nos encontramos con este tipo de problemas. Es difícil superarlo después de que la mejora alcanza cierto nivel. Sentimos que tenemos energía más que suficiente pero no suficiente y comenzamos a sentirnos deprimidos. Más tarde, a través del aprendizaje, el entrenamiento y la comunicación, mis pensamientos y habilidades se sublimaron y descubrí la pieza más corta del barril. Luego comencé a mejorar nuevamente, y luego me encontré con el techo de cristal nuevamente, y luego... estaba. en un ciclo deprimente.

Si dominamos todos los conocimientos y podemos superar todos los techos de cristal, ¿podrá el control de calidad navegar sin problemas? La respuesta es no. La propia definición del rol de control de calidad tiene limitaciones importantes. QA desempeña el papel de policía del proceso. Independientemente de si tiene sentido o no, impone tiránicamente la ejecución del proceso, lo que fácilmente puede crear una relación hostil en el equipo del proyecto y conducir a la exclusión. Además, la actitud de este policía también destruye. el espíritu de equipo. De esta manera, el trabajo de control de calidad también requiere habilidades interpersonales, como escribí antes sobre "Balance de calidad" y "¿Debería el control de calidad ser independiente del equipo del proyecto?" 》Lo mismo, maneja esta relación artísticamente.

4. El futuro del control de calidad

Hasta cierto punto, el mecanismo de revisión de control de calidad independiente es producto del modelo en cascada.

Con la evolución de la tecnología moderna de desarrollo de software y el surgimiento de los modelos en espiral y los modelos iterativos, los mecanismos de control de calidad están cambiando silenciosamente. Este cambio es la evolución de un control de calidad independiente a tiempo completo a un control de calidad a tiempo parcial durante todo el proceso. En el modelo CMMI, este tipo de control de calidad a tiempo parcial también está permitido. ¿Por qué ocurrió este cambio? Ya sea XP, RUP u otras metodologías avanzadas, la arquitectura se genera primero y luego se desarrolla de forma incremental hasta su finalización. En este modelo, los requisitos y defectos de diseño se descubren y reparan lo antes posible en cada ciclo de iteración, la calidad se integra en la arquitectura y el proceso, y el costo y el cronograma del proyecto también están garantizados.

Para entonces, ¿dejará de existir el control de calidad independiente? Algunas empresas con menor madurez todavía lo necesitan, principalmente para asegurar la efectividad de la ejecución de los procesos y la objetividad de la evaluación.

5. Exploración teórica del SQA

1. Comprensión del proceso

Todos sabemos que los contenidos principales de un proyecto son: costo, cronograma, calidad. Una buena gestión de proyectos consiste en integrar los tres factores, equilibrar los objetivos de los tres aspectos y finalmente completar la tarea de acuerdo con los objetivos. Estos tres aspectos del proyecto se restringen e influyen entre sí. A veces, la estrategia de equilibrio de estos tres aspectos incluso se convierte en un requisito a nivel empresarial, lo que determina el comportamiento de la empresa. Sabemos que el software de IBM toma la calidad como el objetivo más importante. La estrategia de "software suficientemente bueno" de Microsoft es aún más familiar. Estos objetivos de calidad en realidad se basan en los objetivos estratégicos de la empresa. Por lo tanto, el trabajo de SQA utilizado para el aseguramiento de la calidad también debe basarse en los objetivos estratégicos de la empresa. Piense en SQA desde esta perspectiva y forme una comprensión teórica de SQA.

La industria del software ha llegado a un consenso de que los factores que afectan el progreso, el costo y la calidad de los proyectos de software son principalmente "las personas, los procesos y la tecnología". Lo primero que hay que dejar claro es que entre estos tres factores, las personas son lo primero.

Hoy en día, muchas personas que implementan CMM son adictas a la teoría de CMM y ponen demasiado énfasis en el "proceso". Esta es una tendencia muy peligrosa. Esta tendencia ideológica ha sido duramente criticada en el extranjero. En cierto sentido, la propuesta de varios métodos de proceso ágiles es un reflejo del énfasis en el proceso. Una de las ideas de "XP" es que vale la pena pensar en "las personas son más importantes que el proceso". Mi opinión personal es adherirse a una mejora de procesos "orientada a las personas" y enfatizar la armonía entre el proceso y las personas.

Según una encuesta de muchos proyectos fallidos realizada por Modern Software Engineering, se descubrió que la gestión es la principal razón del fracaso del proyecto. La importancia de este hecho es que ilustra "Para garantizar que el proyecto no fracase, debemos prestar más atención a la gestión". Tenga en cuenta que este hecho no ilustra otra cuestión: "Una buena gestión puede garantizar el éxito del proyecto". Hoy en día, mucha gente saca esta conclusión a partir de un hecho basado en una lógica aproximada, que es lógicamente errónea. Este error conduce a un enfoque aún más erróneo. Esto se refleja en la comprensión de SQA.

Si examinamos la evolución histórica, debería ser más fácil entender la esencia de CMM. CMM apareció por primera vez como un "estándar de evaluación", que evaluaba principalmente la capacidad de los proveedores del Departamento de Defensa de EE. UU. para garantizar la calidad. La producción de software en la que se centra CMM tiene las siguientes características:

(1) La calidad es importante

(2) Gran escala

Esta es la razón de la aparición de la CMM. Introduce la idea de "gestión de la calidad total", se centra especialmente en el "método de proceso" en la "gestión de la calidad total" e introduce el método de "control estadístico de procesos". Se puede decir que estas dos ideas son la base de CMM.

El contenido anterior forma mi comprensión básica del estado y el valor del proceso de software; sobre esta base podemos ampliar la discusión sobre SQA.

2. La metáfora de la línea de producción

Si comparas una producción de software con la producción de una fábrica. Entonces, la línea de producción es el proceso y los productos se producen de acuerdo con el proceso especificado de la línea de producción. La responsabilidad de SQA es asegurar la ejecución del proceso, es decir, asegurar la normal ejecución de la línea de producción.

El modelo del sistema de gestión se resume de la siguiente manera. Este modelo ilustra que un sistema de procesos debe contener al menos tres aspectos importantes: "toma de decisiones, ejecución y retroalimentación".

La responsabilidad de QA es asegurar la ejecución efectiva del proceso y supervisar las actividades del proyecto de acuerdo al proceso; no es responsable de supervisar la calidad del producto, proporcionando el estado del proyecto a la gerencia; y gestionar en nombre de la dirección, representando únicamente a la dirección para asegurar la ejecución del proceso.

3. Combinación de SQA y otros trabajos

En muchas empresas, el trabajo de SQA se mezcla con el trabajo de QC, SEPG y gerentes de proyectos a nivel organizacional. prestar más atención a otros aspectos del trabajo en lugar de hacer su propio trabajo como SQA.

Según la opinión de hjhza, "China ahora tiene básicamente tres tipos de control de calidad (divididos según diferentes prioridades de trabajo): uno es del tipo de mejora de procesos, uno es del tipo de gestión de configuración y el otro es del tipo de prueba". Personalmente creo que es porque el trabajo de SQA se combina con otros trabajos diferentes.

La siguiente es una explicación de la relación entre ellos basada en mi experiencia.

4. QA y QC

Responsabilidades básicas de ambos

QC: Inspeccionar la calidad de los productos y garantizar que los productos satisfagan las necesidades del cliente; inspector;

QA: audita la calidad del proceso, asegurando que el proceso se ejecute correctamente; es el auditor de calidad del proceso

Preste atención a la diferencia entre inspección y auditoría<; /p>

Inspección: es decir, lo que solemos decir es encontrar fallas.

Auditoría: para confirmar la evidencia de que el proyecto se está llevando a cabo según lo requerido, observe más de cerca los términos utilizados en; la inspección SQA de cada KPA en CMM utiliza mucha "confirmación". El contenido de la auditoría está principalmente relacionado con el proceso; compara el contenido de la revisión de los gerentes de proyecto y altos directivos con CMM, y prestan más atención al contenido específico. .

En comparación con el modelo de sistema de gestión anterior, el control de calidad realiza el control de calidad y devuelve información de calidad a la dirección; el control de calidad garantiza que el control de calidad lleve a cabo actividades de control de calidad de acuerdo con el proceso e informe los resultados de la inspección a la dirección de acuerdo con él. al proceso. Ésta es la relación entre el trabajo de control de calidad y control de calidad.

Bajo este principio de división del trabajo, QA solo necesita verificar si el proyecto ha realizado ciertas actividades de acuerdo con el proceso y si se ha producido un determinado producto mientras que QC verifica si el producto cumple con la calidad; requisitos.

Si la empresa originalmente tiene personal de control de calidad y personal de control de calidad insuficiente, primero puede determinar que el control de calidad también se hará cargo del trabajo de control de calidad. Pero sólo puede ser temporal y debe haber personal de control de calidad independiente disponible, porque el trabajo de control de calidad también debe seguir los requisitos del proceso y ser auditado. Esta situación mixta hace difícil garantizar la calidad del proceso del trabajo de control de calidad.

5. QA y SEPG

Responsabilidades básicas de ambos

SEPG: Desarrollar procesos e implementar mejoras de procesos

QA: Asegurar el proceso; Ser ejecutado correctamente

SEPG debe proporcionar orientación sobre el proceso para ayudar al equipo del proyecto a formular el proceso del proyecto y ayudar al equipo del proyecto a planificar, ayudando así al equipo del proyecto a trabajar y ejecutar el proceso de manera efectiva; Si hay una disputa entre el proyecto y la comprensión del proceso por parte de QA, SEPG actúa como árbitro final. Para realizar mejoras efectivas en los procesos, la SEPG debe analizar los datos del proyecto.

Los libros de control de calidad también deben llevar a cabo la estandarización de procesos, por lo que el control de calidad más experimentado y capaz entre todos los controles de calidad puede participar en SEPG, pero preste atención a la diferencia entre los dos.

Si el personal de SEPG de la empresa tiene una experiencia de desarrollo relativamente profunda, también puede asumir el trabajo de SQA, lo que favorece la mejora continua del proceso; sin embargo, debido a la integración de la legislación y la aplicación de la ley; Es fácil que SQA sea demasiado fuerte y afecte la independencia del proyecto.

Para las empresas con procesos de gestión relativamente maduros, debido a que la cultura y el mecanismo de gestión de la empresa han mejorado, hay menos trabajo dentro del alcance de las responsabilidades de SQA y, a menudo, simplemente formulan planes de SQA con prioridades claras para proyectos específicos. , de modo que el trabajo de auditoría SQA se reducirá considerablemente para que se puedan auditar más proyectos al mismo tiempo.

Por otro lado, debido a la detallada división del trabajo y la complejidad del sistema de gestión, a menudo se requiere personal de SEPG a tiempo completo. Este personal debe comprender todos los procesos y operaciones de gestión de la empresa. empresa, y sobre esta base pueden coordinar la situación general para llevar a cabo la mejora del proceso, el personal de SQA que comprende la situación general es el principal candidato para SEPG de tiempo completo. Este personal de SQA se transformará gradualmente en personal de SEPG y tendrá una mejor comprensión. de conocimientos de gestión, y el trabajo de SQA se convertirá gradualmente en su trabajo a tiempo parcial.

Esta situación es común en muchas empresas de CMM5. El personal de SQA suele ser invisible o rara vez aparece en el equipo del proyecto. Esta integración de SEPG y SQA es particularmente beneficiosa para el trabajo de mejora de procesos de la organización. SEPG determina el contenido de mejora del proceso y el plan SQA se centra en reflejar este contenido de mejora para garantizar una mejora efectiva, lo que es especialmente propicio para cumplir con los requisitos de CMM5. Desde esta perspectiva, no es difícil entender por qué el personal extranjero de SQA está bien remunerado, lo que también determina la razón por la que actualmente se menosprecia al personal chino de SQA porque el proceso de gestión no es perfecto y nuestro personal de SQA aún no ha producido tan bien; ¡valor!

6. Control de calidad y supervisión y gestión a nivel organizacional

Para poder supervisar y gestionar mejor los proyectos, algunas empresas han establecido un rol, al que denominé "gerente de supervisión a nivel de organización". ”, su responsabilidad es realizar un seguimiento unificado, supervisión y gestión adecuada de todos los proyectos para garantizar la visibilidad y manejabilidad de la gestión de todos los proyectos.

Para gestionar proyectos de forma eficaz, los "gerentes de supervisión organizacional" deben analizar los datos del proyecto.

Su responsabilidad es realizar la función de "feedback" según el modelo anterior.

El control de calidad en sí no proporciona retroalimentación, solo proporciona retroalimentación sobre la información de ejecución del proceso.

El personal de SQA es bastante cauteloso.

Si se establece un mejor proceso de gestión, se mejorará la visibilidad del proyecto, asegurando así una mejor gestión de todos los proyectos por parte de la empresa y el control de calidad garantizará el funcionamiento de este proceso de gestión;

5. Contenido del trabajo de SQA y métodos de trabajo

1. Planificar

Desarrollar planes de SQA para proyectos específicos para garantizar que el equipo del proyecto ejecute el proceso correctamente. Al formular un plan SQA, debe prestar atención a los siguientes puntos:

Enfocado: determine el enfoque de la auditoría en función de los objetivos corporativos y las condiciones del proyecto

Contenido claro de la auditoría: aclare cuáles las actividades y los productos se auditan

Aclarar el método de auditoría: determinar cómo realizar la auditoría

Aclarar las reglas para informar los resultados de la auditoría: a quién se informan los resultados de la auditoría

2. Auditoría/confirmación

Llevar a cabo el trabajo de auditoría SQA de acuerdo con el plan SQA y emitir informes de resultados de auditoría de acuerdo con las reglas.

Tenga en cuenta que la auditoría debe ir acompañada de miembros del equipo del proyecto y no se permiten ataques sorpresa. Ambas partes deben ser abiertas y honestas entre sí.

Contenido de la auditoría: Si las actividades correspondientes se realizaron de acuerdo con los requisitos del proceso y si los productos correspondientes se produjeron de acuerdo con los requisitos del proceso.

3. Seguimiento de problemas

Solicitar al equipo del proyecto que mejore los problemas descubiertos durante la auditoría y realizar un seguimiento hasta que se resuelvan.

6. Calidad del SQA

Centrado en el proceso: Los temas deben considerarse desde la perspectiva del proceso Mientras el proceso esté garantizado, el QA habrá cumplido con sus responsabilidades.

Espíritu de servicio: servir al equipo del proyecto y ayudar al equipo del proyecto a garantizar la correcta ejecución del proceso

Entender el proceso: tener un conocimiento profundo de la ingeniería de la empresa y tener ciertos conocimientos teóricos de gestión de procesos

Comprender el desarrollo: comprender la situación básica del trabajo de desarrollo y ser capaz de comprender las actividades del proyecto

Habilidades de comunicación: ser bueno en la comunicación y ser capaz de crear una buena atmósfera y evitar que las actividades de auditoría se conviertan en una actividad de búsqueda de fallas.

7. Actividades SQA

El Aseguramiento de la Calidad del Software (SQA) es una actividad aplicada a todo el proceso del software. Incluye:

1. Un tipo de calidad. Métodos de gestión

2. Técnicas efectivas de ingeniería de software (métodos y herramientas)

3. Revisiones técnicas formales utilizadas durante todo el proceso del software

4. 1. Un multi Estrategia de pruebas a nivel

5. Control de documentos y modificaciones de software

6. Asegurar que el software cumple con los estándares de desarrollo de software

7. Mecanismo de medición y presentación de informes

SQA está relacionado con dos participantes diferentes: los ingenieros de software que realizan el trabajo técnico y el equipo de SQA que es responsable de la planificación, supervisión, registro, análisis e informes del control de calidad.

Los ingenieros de software consideran los problemas de calidad empleando métodos y medidas técnicas confiables, realizando revisiones técnicas formales, realizando pruebas de software bien planificadas y completando actividades de control y garantía de calidad del software.

La responsabilidad del equipo SQA es ayudar al equipo de ingeniería de software a obtener productos finales de alta calidad. El equipo de SQA completó:

(1) Preparar el plan de SQA para el proyecto. Este plan se establece durante el desarrollo del plan prescrito del proyecto y es revisado por todas las partes interesadas.

·Auditorías y revisiones requeridas;

·Estándares que puede adoptar el proyecto;

·Procedimientos de seguimiento y notificación de errores;

·Documentos producidos por el equipo de SQA;

·Cantidad de comentarios proporcionados al equipo del proyecto de software.

(2) Descripción del proceso de software involucrado en el proyecto de desarrollo. Revise la descripción del proceso para garantizar que el proceso sea coherente con las políticas organizacionales, los estándares internos de software, los estándares externos y otras partes del plan del proyecto.

(3) Revisar diversas actividades de ingeniería de software y verificar si cumplen con el proceso de software definido. Documentar y realizar un seguimiento de las desviaciones del proceso.

(4) Auditar los productos de trabajo de software designados y verificar si cumplen con los requisitos predefinidos. Revisar los productos, identificar, registrar y realizar un seguimiento de las desviaciones; verificar si se han corregido; informar periódicamente los resultados del trabajo al director del proyecto.

(5) Garantizar que las desviaciones en el trabajo y los productos del software se documenten y se manejen de acuerdo con procedimientos predeterminados.

(6) Registrar todas las no conformidades e informar a los líderes superiores.

8. Revisión técnica formal (FTR)

La revisión técnica formal es una actividad de control de calidad del software realizada por ingenieros de software y otros.

1. Objetivos:

(1) Encontrar errores funcionales, lógicos o de implementación.

(2) Confirmar que el software revisado efectivamente cumple con los requisitos

(3) Garantizar que la representación del software se ajuste a los estándares predefinidos

(4) Lograr que el software se desarrolle de forma coherente

(5) Hacer que los proyectos sean más fáciles de gestionar

2. Reunión de revisión

3-5 personas, no más de 2 horas, a las que asisten el presidente de revisión, los revisores y los productores, deben tomar una de las siguientes decisiones:

(1) Si el producto de trabajo puede aceptarse sin modificaciones;

(2) Rechazo del producto de trabajo debido a errores graves;

(3) Aceptación temporal del producto de trabajo.

3. Revisar el informe resumido y las respuestas

¿Qué se está revisando? ¿Revisado por quién? ¿Cuál es la conclusión?

El informe resumido de la revisión es parte del historial del proyecto, identifica áreas problemáticas en el producto y sirve como una lista de verificación administrativa para guiar al productor en la realización de correcciones.

4. Pautas para la revisión

(1) Revisar el producto, no el productor. Tenga cuidado de señalar los errores cortésmente y mantenga el ambiente relajado.

(2) No te salgas del tema y limites el debate. Las cuestiones desagradables no deben discutirse sino documentarse.

(3) Expresar opiniones sobre diversos temas. La resolución del problema debe posponerse hasta después de la reunión de revisión.

(4) Cree una lista de verificación para cada producto de trabajo a revisar. Se deben establecer listas de verificación para el análisis, diseño, codificación y documentación de prueba.

(5) Asignar recursos y tiempo. Las revisiones deben programarse como una tarea de ingeniería de software.

(6) Revisar revisiones anteriores

9. Garantía estadística de calidad del software

1 Clasificar y contar todos los errores

La especificación IES es incompleta o la especificación es incorrecta

MCC no comprende la intención del usuario

IDS se desvía deliberadamente de la especificación

VPS viola los estándares de programación

Datos EDR la representación es incorrecta

La interfaz del componente ICI es inconsistente

La lógica de diseño de EDL es incorrecta

La prueba IET está incompleta o es incorrecta

IID Inexacto o documentación incompleta

Errores de traducción del lenguaje de programación diseñado por PLT

HCI Interfaz hombre-máquina poco clara o inconsistente

MIS Errores varios

Estadísticas sobre el porcentaje del número de diversos tipos de errores según niveles graves, normales y menores, así como el número y porcentaje de todos los errores. Por ejemplo, cree una tabla similar a la siguiente.

Luego considere los "pocos indicadores de error importantes" y proponga mejoras.

2. Calcular indicadores de error en función de cada paso del proceso del software.

Ei = Número total de errores encontrados en el i

Si = Número de errores graves

Mi = Número de errores normales

Ti = Número de errores menores

PS = escala del producto del paso i (LOC, declaración de diseño, número de páginas del documento)

Ws, Wm y Wt son los factores de ponderación de errores graves, errores normales y menores respectivamente, valores recomendados, Ws=10, Wm=3, Wt=1

En cada paso del proceso de ingeniería de software, se calculan los indicadores de etapa de cada etapa

Índice de error

Ei= ∑ (i×PIi)/PS

= (PI1 + 2PI2 + 3PI3 +… + i*PIi) / PS

Las métricas de error combinadas con la información recopilada en la tabla anterior producen métricas generales de mejora de la calidad del software. 7. Control de calidad e inspección

Para garantizar la calidad de cada proceso de desarrollo y evitar la propagación de errores de software al siguiente proceso, por lo tanto, el propósito de la inspección es doble:

1 . Gestione eficazmente la etapa de desarrollo y verifique el aseguramiento de la calidad en cada etapa de desarrollo.

2． Evite que los errores de software causen pérdidas a los usuarios.

Los tipos de inspecciones son:

1. Inspección de suministro: Inspección de los componentes, especificaciones, productos semiacabados o productos que constituyen el producto de software que se encomiendan a una unidad externa para realizar el trabajo de desarrollo y luego se compran o transfieren.

2． El propósito de la inspección intermedia/revisión de etapa

es determinar si se puede pasar a la siguiente etapa para el desarrollo posterior y evitar la propagación de errores al trabajo posterior.

3. Inspección de aceptación:

Confirma si el producto ha alcanzado los requisitos de calidad para la inspección del producto.

4． Inspección de productos:

Determine si los productos de software proporcionados a los usuarios son satisfactorios

Puede echar un vistazo a estos...