Đánh giá ƣu nhƣợc điểm của SAD

Một phần của tài liệu (LUẬN văn THẠC sĩ) nghiên cứu và thiết kế kiến trúc phần mềm cho các hệ thống lớn và phức tạp (Trang 28 - 30)

CHƢƠNG 2 : TỔNG QUAN VỀ THIẾT KẾ KIẾN TRÚC PHẦN MỀM

2.5 Đánh giá ƣu nhƣợc điểm của SAD

Ưu điểm

SAD giúp chúng ta hiểu biết về hệ thống, thấy đƣợc cấu trúc, các thành phần chính của hệ thống, các ràng buộc liên quan. Ngoài ra giúp hiểu rõ hơn về các kịch bản quan trọng của hệ thống.

SAD giúp ta có lựa chọn tối ƣu cho hệ thống, cho chúng ta góc nhìn rộng hơn, bao quát hơn, thông qua việc phản ánh các kết quả của quá trình phân tích, thiết kế thƣờng xác định cho ta nhiều hƣớng đi, nhiều cách giải quyết trên cùng một bài tóan, từ đó cho phép chúng ta chọn đƣợc cách thức tốt nhất và con đƣờng ngắn nhất để đi tới đích. Mặt khác cho phép ta tham khảo, kế thừa, phát huy những ƣu điểm của những gì đã có trƣớc đó, phát hiện sớm và hạn chế các rủi ro cho phần mềm.

Dựa vào mô hình chữ V (V-model) ta thấy SAD là chuyển tiếp của giai đoạn khảo sát, phân tích và là bƣớc chuẩn bị trƣớc khi ta thiết kế chi tiết và xây dựng phần mềm. Sau khi tìm hiểu, phân tích yêu cầu các kiến trúc sƣ sẽ mô hình hóa các yêu cầu đó lên thành các bản vẽ, phác thảo thành các bản vẽ từ tổng quát tới chi tiết. Các bản vẽ đó sẽ làm cho ngƣời thiết kế chi tiết và ngƣời phát triển lập trình sẽ hình dung ra phần mềm mà họ phải thiết kế chi tiết và phát triển. Ngoài ra đây cũng là tài liệu quan trọng, hữu ích cho quá trình tạo các ca kiểm thử và thực hiện các ca kiểm thử đó.

SAD là nơi mà ta có thể trả lời câu hỏi: “Liệu phần mềm này có thể chạy đƣợc không?”, “Phần mềm có thể đáp ứng đƣợc các yêu cầu của khách hàng hay không?” mà không cần phải đợi tới công đoạn phát triển. Khi thiết kế SAD tốt chúng ta có thể đánh giá sớm tính khả thi của phần mềm.

Giai đoạn khảo sát phân tích thƣờng dựa trên đặc tả yêu cầu ngƣời dùng, chỉ hiểu các chức năng chính và ràng buộc dƣới góc độ ngƣời dùng. SAD sẽ phân tích sâu hơn về các ràng buộc, yêu cầu của hệ thống.

Có SAD quá trình nâng cấp, bảo trì sẽ dễ dàng hơn. Nếu không có thiết kế, chúng ta phải làm lại một chƣơng trình hoàn toàn mới hoặc phải nghiên cứu lại toàn bộ mã nguồn, điều này đồng nghĩa với việc sẽ tiêu tốn của chúng ta khá nhiều thời gian và tiền bạc.

Hỗ trợ đắc lực cho quá trình quản lý, giúp ngƣời quản lý xem xét quá trình phát triển của hệ thống, đánh giá đƣợc mức độ phức tạp của hệ thống sẽ nằm ở đâu, phần rủi ro sẽ nằm ở đâu, từ đó có các giải pháp xử lý, kế hoạch phát triển cho phù hợp.

Nhược điểm

Khó nhìn thấy đƣợc ngay: Các bản thiết kế kiến trúc sau khi hoàn thiện chỉ đƣợc thể hiện trên tài liệu, các mô hình (nếu có), chƣa đƣợc thể hiện bằng chƣơng trình nên mức độ hình dung về chƣơng trình sau này bị hạn chế. Việc này dẫn tới có thể hiểu sai về cách thức thiết kế sẽ đƣợc thể hiện vào chƣơng trình.

Không có quy trình thiết kế chuẩn, chi tiết: Thiết kế kiến trúc phần mềm chỉ có một số quy tắc, tiêu chí chung chung mà không có một quy tắc cơ bản chi tiết hay thống nhất nào, hầu nhƣ tất cả đều phụ thuộc vào cách suy nghĩ không cố định của từng nhà thiết kế. Trên thực tế mỗi công ty khi phát triển các sản phẩm của mình, họ phân tích, tìm hiểu rồi đƣa ra một quy trình thiết kế phù hợp cho riêng mình.

Phụ thuộc vào khả năng của ngƣời thiết kế: Thiết kế kiến trúc đòi hỏi ngƣời thiết kế phải có kiến thức, hiểu biết sâu rộng về nhiều lĩnh vực trong tin học. Phải có kinh nghiệm thức tế lâu năm, hiểu biết về nghiệp vụ, môi trƣờng triển khai, các công nghệ cũ và mới, so sánh, đánh giá ƣu nhƣợc điểm sau đó đƣa ra quyết định phù hợp, chính xác… Ngƣời thiết kế mà khả năng bao quát vấn đề không tốt, không có nhiều kinh nghiệm sẽ đƣa ra bản thiết kế có thể không phù hợp, không tối ƣu, rất khó cho quá trình bảo trì và nâng cấp, khi đƣa vào giai đoạn phát triển mới phát hiện ra vấn đề không phù hợp, khi đó phải làm lại rất nhiều, thậm chí phải bỏ cả hệ thống đi làm lại. Trên thực tế các công ty phần mềm, số lƣợng lập trình viên rất lớn, nhƣng số ngƣời có khả năng thiết kế kiến trúc rất ít, thậm chí là không có.

Khó kiểm chứng, đánh giá sự đúng đắn: Rất khó có thể đƣa ra một cách kiểm chứng đánh giá sự đúng đắn của kiến trúc phần mềm sau khi đƣợc hoàn thành. Việc này thƣờng dựa vào kinh nghiệm của các nhà thiết kế. Ngƣời có kinh nghiệm khi xem xét, rà soát thiết kế kiến trúc của ngƣời khác sẽ tìm ra những vấn đề không phù hợp.

CHƢƠNG3:TỔNGQUANVỀHỆTHỐNGQUẢNLÝ,XỬLÝẢNH

TRONGYTẾ

Một phần của tài liệu (LUẬN văn THẠC sĩ) nghiên cứu và thiết kế kiến trúc phần mềm cho các hệ thống lớn và phức tạp (Trang 28 - 30)

Tải bản đầy đủ (PDF)

(57 trang)