Aseguramiento de la calidad en la fase de diseño?

Question

¿Cómo encaja la garantía de calidad en la fase de diseño del desarrollo de software?

¿Qué actividades de garantía de calidad (si las hay) se realizan en la fase de diseño?

Answer 1

Un buen diseño es un diseño comprobable. OMI, uno siempre debe estar pensando en cómo se probaría el software, incluso durante la fase de diseño. Por supuesto, el nivel de atención requerido dependerá de si está haciendo un diseño detallado o una arquitectura de alto nivel. El uso de una metodología, como TDD, obligará a enfocarse en la importancia de las pruebas durante el diseño. Por supuesto, uno no debe pasar por alto otros aspectos de la garantía de calidad, como las pruebas de usabilidad, las pruebas de rendimiento, etc. Estos también son factores importantes a considerar durante el diseño: cómo lograr sus objetivos y cómo evaluar si se logran los objetivos.

Answer 2

Lo más útil que QA puede hacer durante la fase de diseño es asegurarse de que la especificación suministrada tenga un conjunto de objetivos claros y comprobables. Y use esos objetivos para elaborar un plan de prueba.

Esto es para que puedan responder a dos preguntas muy importantes: "Puede esto ser probado" y "¿Cuánto tiempo se tarda en probar". El primero es importante para garantizar que todos conozcan los criterios para la finalización del proyecto. Y el segundo es necesario, ya que forma parte del costo general de la implementación.

Answer 3

La garantía de calidad no encaja realmente en la fase de diseño. La garantía de calidad consiste en reparar los defectos después de que ocurrieron, algo que era una práctica común en el último milenio. Por supuesto, puede haber defectos en los documentos de especificación producidos durante el diseño, pero aparte de los que aún no tiene ningún producto, no hay defectos que encontrar.

La gestión de la calidad, por otro lado, es el camino a seguir en el siglo XXI. Es un enfoque integrado para el defecto prevención. Es crucial integrarlo en su proyecto desde el principio, por lo que definitivamente debe encajar en el diseño.

hay miles de libros y páginas web sobre este tema, pero la OMI las cosas más importantes son:

1. aprender de los errores anteriores. Analice proyectos similares y vea cuáles fueron los mayores errores cometidos allí. Intenta evitarlos en tu proyecto.
2. Después de que se complete el proyecto, haga una revisión después de la acción para descubrir lo que se perdió en el paso 1 anterior. Use esa información en el próximo proyecto similar.

Answer 4

Hay una fase de diseño arquitectónico y una fase de diseño detallado.

actividades de GC durante estas fases pueden incluir:

• Asegurando que la arquitectura soporta todos los (no) requisitos -Funcional
• Asegurando que todos los módulos importantes están cubiertos y diseñados en los diseños detallados correctamente
• Asegurarse de que los documentos de diseño están bajo gestión de configuración (cambio)
• Hacer revisiones (formales) para revisar la arquitectura y su documentación
• Asegurarse de que se sigan los estándares de diseño predefinidos

Esto a veces se denomina 'Revisiones críticas de diseño de software'. Puede ver una lista de verificación de ejemplo here.

Answer 5

Para comprender cómo encaja en su proceso de desarrollo en particular, usted tiene que considerar:

• La calidad del producto es responsabilidad de todo el equipo. Cada grupo de roles debe aportar su valor correspondiente al proyecto (traiga ayuda al proyecto si cree que faltan algunas habilidades). No haga que el equipo de calidad realice actividades que sean/deberían ser revisiones por pares, es decir, revisiones de arquitectura/diseño.
• QA no es el lugar donde desecha cualquier responsabilidad faltante en el proyecto, es decir, la administración del proyecto debe preocuparse por el presupuesto, riesgos, etc. Es responsabilidad de este rol asegurarse de que todos estén en su lugar. Además, utiliza auditorías + tutorías para ayudar a cada miembro del equipo a cumplir sus roles.
• QA contribuye a la arquitectura/diseño según su opinión de que debe poderse probar. Consideran/planifican/diseñan activamente cómo probarán dicha arquitectura/diseño, que es un factor importante para tener un esfuerzo de prueba efectivo/exitoso.
• QA contribuye a una variedad de artefactos, al igual que el lado de desarrollo. Siempre centrado en cómo se relaciona con los objetivos que quieren lograr.
• QA necesita estar preparado para comenzar la automatización de pruebas desde el inicio del desarrollo. Esto también implica una coordinación importante con los desarrolladores y el plan con el fin de utilizar un enfoque de desarrollo que permita al equipo qa realizar la automatización de prueba de manera continua/gradual.
• Al igual que las actividades de desarrollo tienen un alcance/prioridad, el equipo de qa debe hacer lo mismo. Hay tantas variaciones de pruebas que se pueden hacer en un proyecto que es imposible hacerlo todo con una cobertura completa. Esto impactará el esfuerzo de qa en el proyecto, y también puede ayudar a dejar en claro lo que queda fuera del alcance en el lado del equipo qa (otras medidas podrían estar en su lugar para abordarlo desde otros roles).
• Cómo y cuándo se realizan las actividades tiene una estrecha relación con los procesos y las prácticas utilizadas. Una simplificación sería: si está involucrando actividades de desarrollo/esfuerzo, también hay algo significativo en el esfuerzo qa que debería estar sucediendo.
• La mayoría de los roles y actividades en las diferentes metodologías están ahí para agregar a diferentes aspectos de la calidad del proyecto y los productos relacionados.

Answer 6

Fase de diseño: La falta de calidad en el proceso de diseño puede invalidar las buenas especificaciones de los requisitos y puede hacer que la implementación correcta sea imposible. La práctica de la industria muestra que el uso de la lista de verificación durante el diseño ayuda a mejorar la calidad del diseño

¿Hemos atendido todos los requisitos mencionados en el SRS? ¿Se ha puesto el SRS bajo control de documento? ¿Se han tratado los requisitos relacionados con las siguientes características durante el diseño? rendimiento, seguridad, concurrencia, facilidad de uso, portabilidad, capacidad de prueba, los requisitos de idioma/DB/OS/hardware, entorno de desarrollo, la compatibilidad, la adherencia a los estándares de la industria, la escalabilidad, la manipulación

excepción es la metodología de diseño elegido apropiado para el tipo de proyecto de software a desarrollar. Claridad: ¿La documentación de diseño es clara/no ambigua? ¿Puede el diseño justificarse técnicamente? Compatibilidad con el software existente Identificar el efecto de este diseño en software existente ¿Hemos realizado el análisis de impacto ¿Este diseño depende de los efectos secundarios de otro software? ¿Este diseño tiene alguna dependencia en cualquier otro diseño relacionado?

Nivel de componente: ¿Están las interfaces bien definidas? son las principales estructuras de datos definidas son los principales algoritmos definidos es el flujo de datos/control definido Estructura de Datos y Algoritmos son las estructuras de datos definidas Son los métodos de acceso a las estructuras de datos definidas? ¿Están definidos los algoritmos? ¿Las estructuras de datos y los algoritmos resuelven los problemas?

Error/Exception Handling ¿Se manejan los errores de tipo de datos? ¿El software valida la entrada del usuario? ¿El software da mensajes explícitos y no amenazantes si ocurre un error? (Calidad de los mensajes de error). ¿Se puede reiniciar el software desde cualquier punto después de un error? ¿El software maneja con gracia las condiciones de excepción, como infracciones de acceso y errores de coma flotante?

Interfaces de procedimiento ¿El número de parámetros reales coincide con el número de parámetros formales? ¿El tipo y el tamaño de los parámetros reales concuerdan con el tipo y tamaño de los parámetros formales? ¿Hemos especificado las funciones locales y globales correctamente? ¿Las variables globales están definidas y se usan de manera consistente en todos los módulos? ¿Está documentada toda la comunicación (es decir, parámetros y datos compartidos)?

Nivel de procedimiento ¿El procedimiento hace algo muy similar a un procedimiento existente? ¿Hay algún procedimiento de biblioteca que haga lo mismo? Es el procedimiento excesivamente complejo Podría dividirse el procedimiento en partes separadas y más lógicas. ¿El procedimiento es de tamaño aceptable?

¿El procedimiento hace una sola cosa lógica? ¿El procedimiento se basa en la variable estática del alcance del procedimiento? ¿El procedimiento se mantiene fácilmente y se hace referencia de forma conjunta? ¿Se puede probar fácilmente el procedimiento? ¿Se describe el efecto secundario?

Calidad ¿Se han establecido los objetivos del diseño (fiabilidad, flexibilidad, mantenimiento, rendimiento, etc.)? ¿El diseño satisface sus objetivos establecidos? (Trazabilidad a los requisitos) ¿Hay evidencia de que se consideró más de una opción de diseño? ¿Se enumeran varias opciones de diseño junto con el motivo de su adopción o rechazo? ¿Se declaran las suposiciones de diseño ¿Se declaran las concesiones de diseño ¿Es eficiente el diseño? ¿El diseño es mantenible? ¿El diseño es portátil? ¿El mango de diseño puede cambiar al entorno externo con modificaciones mínimas? El parámetro de diseño está controlado o los valores están codificados de forma rígida en los programas.

Requisitos ¿El diseño satisface todos los requisitos? ¿Hay trazabilidad entre el diseño y las especificaciones del sistema? ¿Puede el diseño cumplir con los requisitos de costo de desarrollo? ¿Se puede completar en el marco de tiempo dado? ¿El diseño se mantiene dentro de las restricciones de memoria de requisitos? ¿El diseño se mantiene dentro de las restricciones de uso de disco requeridas? ¿Satisface el diseño los requisitos de tiempo de respuesta? ¿El diseño manejará la tasa esperada de transacciones? ¿El diseño manejará los volúmenes de flujo de datos esperados?