Đảm bảo chất lượng trong giai đoạn thiết kế?

Question

Đảm bảo chất lượng phù hợp với giai đoạn thiết kế phát triển phần mềm như thế nào?

Hoạt động đảm bảo chất lượng (nếu có) được thực hiện trong giai đoạn thiết kế?

Answer 1

Thiết kế tốt là thiết kế có thể kiểm tra. IMO, người ta cần phải luôn luôn suy nghĩ về cách người ta sẽ kiểm tra phần mềm ngay cả trong giai đoạn thiết kế. Tất nhiên, mức độ chú ý bắt buộc sẽ phụ thuộc vào việc bạn đang thiết kế chi tiết hay kiến ​​trúc cấp cao. Sử dụng một phương pháp, chẳng hạn như TDD, sẽ buộc tập trung vào tầm quan trọng của thử nghiệm trong quá trình thiết kế. Tất nhiên, người ta không nên bỏ qua các khía cạnh khác của QA như kiểm tra khả năng sử dụng, kiểm tra hiệu suất, vv Đây cũng là những yếu tố quan trọng cần cân nhắc trong quá trình thiết kế - cả cách đạt được mục tiêu của bạn và cách đánh giá xem các mục tiêu có đạt được hay không.

Answer 2

Điều hữu ích nhất mà QA có thể thực hiện trong giai đoạn thiết kế là đảm bảo rằng thông số kỹ thuật được cung cấp có một bộ mục tiêu rõ ràng, có thể kiểm tra. Và sử dụng những mục tiêu đó để đưa ra một kế hoạch thử nghiệm.

Điều này là để họ có thể trả lời hai câu hỏi rất quan trọng: "thể này được kiểm tra" và "bao lâu nó sẽ mất để kiểm tra". Việc đầu tiên là quan trọng để đảm bảo rằng mọi người đều biết các tiêu chí để hoàn thành dự án. Và thứ hai là cần thiết vì nó tạo thành một phần của tổng chi phí thực hiện.

Answer 3

Đảm bảo chất lượng không thực sự phù hợp với giai đoạn thiết kế. QA là về sửa chữa các khuyết tật sau khi chúng xảy ra, một cái gì đó đã được thực hành phổ biến trong các millenium cuối cùng. Tất nhiên có thể có khuyết tật trong các tài liệu đặc tả được sản xuất trong quá trình desing, nhưng ngoài những tài liệu bạn chưa có sản phẩm, do đó không có khuyết tật để tìm.

Quản lý chất lượng mặt khác là cách để đi vào thế kỷ 21. Đây là phương pháp tích hợp để ngăn chặn việc ngăn chặn ngăn chặn. Nó là rất quan trọng để tích hợp nó vào dự án của bạn ngay từ đầu, vì vậy nó chắc chắn phải phù hợp với thiết kế.

Hiện có hàng ngàn cuốn sách và các trang web về chủ đề này, nhưng IMO những điều quan trọng nhất là:

1. Tìm hiểu từ những sai lầm trước đó. Phân tích các dự án tương tự và xem những sai lầm lớn nhất được thực hiện ở đó là gì. Cố gắng tránh chúng trong dự án của bạn.
2. Sau khi hoàn thành dự án, thực hiện đánh giá sau khi hành động để tìm hiểu những gì đã bị bỏ lỡ ở bước 1 ở trên. Sử dụng thông tin đó trên dự án tương tự tiếp theo.

Answer 4

Có giai đoạn thiết kế kiến ​​trúc khó khăn và giai đoạn thiết kế chi tiết.

hoạt động QA trong những giai đoạn có thể bao gồm:

• Đảm bảo rằng các kiến ​​trúc hỗ trợ tất cả các (không) yêu cầu -functional
• Đảm bảo rằng tất cả các module quan trọng được bảo hiểm và chính xác thiết kế theo thiết kế chi tiết
• Đảm bảo rằng các tài liệu thiết kế đang được quản lý cấu hình (thay đổi)
• Thực hiện các đánh giá (chính thức) để xem lại kiến ​​trúc và tài liệu của nó
• Đảm bảo rằng các tiêu chuẩn thiết kế được xác định trước được tuân theo

Điều này đôi khi được gọi là 'Nhận xét thiết kế phê bình về phần mềm'. Bạn có thể xem danh sách kiểm tra mẫu here.

Answer 5

Để hiểu nó như thế nào phù hợp trong quá trình phát triển cụ thể của bạn, bạn phải xem xét:

• Chất lượng của sản phẩm là trách nhiệm của toàn đội. Mỗi nhóm vai trò phải mang lại giá trị tương ứng của họ cho dự án (mang lại trợ giúp cho dự án nếu bạn cảm thấy một số kỹ năng bị thiếu). Không có nhóm chất lượng thực hiện các hoạt động/nên là đánh giá ngang hàng tức là kiến ​​trúc/đánh giá thiết kế.
• QA không phải là nơi bạn vứt bỏ bất kỳ trách nhiệm nào trong dự án, tức là quản lý dự án phải quan tâm đến ngân sách, rủi ro, v.v. Trách nhiệm của vai trò này là đảm bảo tất cả những điều đó được thực hiện. Ngoài ra, bạn sử dụng kiểm toán + tư vấn để giúp mọi thành viên trong nhóm hoàn thành vai trò của họ.
• QA không góp phần vào kiến ​​trúc/thiết kế dựa trên quan điểm của họ rằng nó phải có thể kiểm chứng. Họ chủ động xem xét/lập kế hoạch/thiết kế cách họ sẽ kiểm tra kiến ​​trúc/thiết kế đã nói, đó là một yếu tố quan trọng để có một nỗ lực thử nghiệm hiệu quả/thành công.
• QA đóng góp cho nhiều hiện vật, giống như bên phát triển. Luôn luôn tập trung vào cách nó liên quan đến mục tiêu mà họ muốn đạt được.
• QA cần chuẩn bị để bắt đầu tự động hóa thử nghiệm ngay từ khi bắt đầu phát triển. Điều này cũng liên quan đến một sự phối hợp quan trọng với các nhà phát triển và kế hoạch để sử dụng một cách tiếp cận phát triển mà sẽ cho phép đội qa liên tục/dần dần thực hiện tự động kiểm tra.
• Giống như các hoạt động phát triển được sắp xếp/ưu tiên, nhóm qa phải làm như vậy. Có rất nhiều biến thể của thử nghiệm có thể được thực hiện trong một dự án mà nó là không thể thực sự làm tất cả với phạm vi bảo hiểm đầy đủ. Điều này sẽ ảnh hưởng đến nỗ lực của qa trong dự án, và cũng có thể giúp làm rõ những gì còn lại nằm ngoài phạm vi nhóm qa (các biện pháp khác có thể được áp dụng để giải quyết nó từ các vai trò khác).
• Làm thế nào/khi các hoạt động được thực hiện có mối quan hệ chặt chẽ với các quy trình và thực tiễn được sử dụng. Một sự đơn giản hóa sẽ là: nếu bạn liên quan đến các hoạt động/nỗ lực phát triển, có một điều gì đó có ý nghĩa đối với nỗ lực của qa cần được tiến hành.
• Hầu hết các vai trò và hoạt động trong các phương pháp khác nhau đều có để thêm vào các khía cạnh khác nhau về chất lượng của dự án và (các) sản phẩm có liên quan.

Answer 6

Giai đoạn thiết kế: Việc thiếu chất lượng trong quy trình thiết kế có thể làm mất hiệu lực đặc điểm yêu cầu tốt và có thể thực hiện chính xác không thể. Thực tiễn trong ngành cho thấy việc sử dụng danh sách kiểm tra trong khi thiết kế giúp cải thiện chất lượng thiết kế

Chúng tôi đã giải quyết tất cả các yêu cầu được đề cập trong SRS chưa? SRS có được đặt dưới sự kiểm soát tài liệu không? Có các yêu cầu liên quan đến các tính năng sau đã được giải quyết trong khi thiết kế không? Hiệu suất, bảo mật, đồng thời, khả năng sử dụng, tính di động, khả năng sử dụng, ngôn ngữ/DB/OS/yêu cầu phần cứng, môi trường phát triển, khả năng tương thích, tuân thủ các tiêu chuẩn ngành, khả năng mở rộng, xử lý ngoại lệ

Phương pháp thiết kế được chọn phù hợp với loại dự án phần mềm được phát triển. Độ rõ ràng: Tài liệu thiết kế có rõ ràng/rõ ràng không? Thiết kế này có thể được chứng minh về mặt kỹ thuật Khả năng tương thích với Phần mềm hiện tại Hiệu ứng của thiết kế này trên phần mềm hiện có đã được xác định là Chúng tôi đã thực hiện phân tích tác động Thiết kế này có phụ thuộc vào các tác dụng phụ của phần mềm khác không? Thiết kế này có phụ thuộc vào bất kỳ thiết kế liên quan nào khác không?

Cấp thành phần: Giao diện có được xác định rõ không? Các cấu trúc dữ liệu chính được xác định Các thuật toán chính được xác định Luồng dữ liệu/kiểm soát có được định nghĩa là Cấu trúc và thuật toán dữ liệu hay không Các cấu trúc dữ liệu được xác định là Các phương pháp truy cập vào cấu trúc dữ liệu được xác định? Các thuật toán được xác định? Cấu trúc dữ liệu và thuật toán có giải quyết được sự cố

Xử lý lỗi/ngoại lệ Lỗi loại dữ liệu được xử lý? Phần mềm có hợp lệ hóa đầu vào của người dùng không? Phần mềm có cung cấp thông báo rõ ràng, không đe doạ nếu xảy ra lỗi không? (Chất lượng của thông báo lỗi). Phần mềm có thể được khởi động lại từ bất kỳ thời điểm nào sau khi có lỗi không? Phần mềm có xử lý các điều kiện ngoại lệ một cách duyên dáng như vi phạm truy cập và lỗi dấu phẩy động hay không.

Giao diện thủ tục Số tham số thực tế có khớp với số tham số chính thức không? Loại và kích thước của thông số thực tế có phù hợp với loại và kích thước của các thông số chính thức không? Chúng tôi đã chỉ định chính xác các chức năng cục bộ và toàn cầu? Các biến toàn cầu có được xác định và sử dụng nhất quán trên các mô-đun không? Tất cả tài liệu truyền thông có được ghi chép (tức là thông số và dữ liệu được chia sẻ) không?

Thủ tục Cấp Quy trình có làm điều gì đó rất giống với quy trình hiện tại không? Có quy trình thư viện nào cũng sẽ thực hiện tương tự không? Quy trình có quá phức tạp không Quy trình có thể được chia thành các phần riêng biệt, hợp lý hơn không. Quy trình có thể chấp nhận được không?

Quy trình có chỉ thực hiện một điều hợp lý không? Quy trình có dựa trên biến tĩnh phạm vi thủ tục không? Quy trình có được duy trì dễ dàng và được tham chiếu bằng cocrrectly không? Thủ tục có thể được kiểm tra dễ dàng không? Phản ứng phụ có được mô tả không?

Chất lượng Mục tiêu của thiết kế đã nêu (độ tin cậy, tính linh hoạt, tính bảo trì, hiệu suất, v.v ...)? Thiết kế có thỏa mãn các mục tiêu đã nêu không? (Truy xuất nguồn gốc theo yêu cầu) Có bằng chứng nào cho thấy có nhiều hơn một lựa chọn thiết kế được xem xét không? Có một số tùy chọn thiết kế được liệt kê cùng với lý do chấp nhận hoặc từ chối của họ không? Các giả định thiết kế có được nêu rõ là Các thiết bị cân bằng thiết kế có được nêu rõ là Thiết kế có hiệu quả không? Thiết kế có thể bảo trì không? Thiết kế có xách tay không? Thiết kế có thể xử lý các thay đổi đối với môi trường bên ngoài với các sửa đổi tối thiểu không? Tham số thiết kế được điều khiển hay là các giá trị được mã hóa cứng trong các chương trình.

Yêu cầu Thiết kế có đáp ứng mọi yêu cầu không? Có khả năng truy tìm nguồn gốc giữa thiết kế và thông số kỹ thuật của hệ thống không? Thiết kế có đáp ứng được các yêu cầu chi phí phát triển không? Có thể hoàn thành trong khung thời gian nhất định không? Thiết kế có nằm trong giới hạn bộ nhớ yêu cầu Thiết kế có nằm trong giới hạn sử dụng đĩa bắt buộc Thiết kế có đáp ứng các yêu cầu về thời gian phản hồi không? Thiết kế có xử lý tỷ lệ giao dịch dự kiến ​​không? Thiết kế có xử lý khối lượng lưu lượng dữ liệu dự kiến ​​không?