Tích Hợp ATAM-CBAM Trong Đánh Giá Kiến Trúc Phần Mềm Và Ứng Dụng Cho Dự Án Vanco-NetDirect Tại FSoft

Luận văn thạc sĩ nghiên cứu vnu uet tích hợp atam cbam trong đánh giá kiến trúc phần mềm và áp dụng cho dự án vanco netdirect, đánh giá hiện trạng, phân tích vấn đề, đề xuất biện

Chuyên ngành

Công Nghệ Thông Tin

Người đăng

Ẩn danh

Thể loại

Luận Văn Thạc Sỹ

2008

80
1
0

Phí lưu trữ

30 Point

Mục lục chi tiết

LỜI CẢM ƠN

DANH MỤC CÁC HÌNH

DANH MỤC CÁC BẢNG

Mục tiêu của luận văn

Cấu trúc và nội dung của luận văn

1. CHƯƠNG 1: TỔNG QUAN VỀ PHƢƠNG PHÁP ĐÁNH GIÁ KIẾN TRÚC PHẦN MỀM – SOFTWARE EVALUATION

1.1. Một số định nghĩa về kiến trúc phần mềm

1.2. Tầm quan trọng của kiến trúc phần mềm

1.3. Kiến trúc và khung nhìn kiến trúc

1.4. Lý do cần phải đánh giá một kiến trúc

1.5. Khi nào thì đánh giá kiến trúc

1.6. Những thành phần tham gia đánh giá kiến trúc

1.7. Kết quả của phiên đánh giá kiến trúc

1.8. Thuộc tính chất lượng nào trong kiến trúc cần phải đánh giá

1.9. Lợi ích và chi phí của việc đánh giá kiến trúc

1.10. Phong cách kiến trúc & Mẫu kiến trúc (Architecture Styles & Pattern)

1.11. Các quyết định kiến trúc – Architecture Decisions

1.2. Thuộc tính chất lƣợng

1.3. Một số thuật ngữ thông dụng

2. CHƢƠNG 2: MỘT SỐ PHƢƠNG PHÁP ĐÁNH GIÁ KIẾN TRÚC PHẦN MỀM DỰA TRÊN SCENARIO

2.1. Phƣơng pháp phân tích kiến trúc phần mềm – SAAM (Software Architecture Analysis Method)

2.1. Ngữ cảnh sử dụng SAAM

2.2. Mục tiêu của SAAM

2.3. Các yếu tố dẫn đến sự hình thành của SAAM

2.4. Các yêu cầu và đầu vào của SAAM

2.5. Các bước thực hiện trong phiên đánh giá SAAM

2.6. Các đối tượng tham gia phiên đánh giá SAAM

2.7. Ước lượng chi phí áp dụng SAAM

2.8. Công cụ hỗ trợ SAAM

2.9. Các phương pháp thay thế SAAM

2.10. Điểm mạnh và đầu ra của SAAM

2.11. Một số lưu ý về SAAM

2.2. Phƣơng pháp ALMA – Architecture Level Modifiability Analysis

2.1. Ngữ cảnh sử dụng ALMA

2.2. Mục tiêu của ALMA

2.3. Các yếu tố dẫn đến sự hình thành của ALMA

2.4. Các yêu cầu và đầu vào của ALMA

2.5. Các bước thực hiện phiên đánh giá ALMA

2.6. Các đối tượng/ vai trò tham gia trong ALMA

2.7. Ước lượng chi phí khi áp dụng ALMA

2.8. Công cụ hỗ trợ ALMA

2.9. Các phương pháp thay thế cho ALMA

2.10. Những ưu điểm và đầu ra của ALMA

2.11. Một số lưu ý về ALMA

2.3. Phƣơng pháp đánh giá kiến trúc FAAM (Family-Architecture Assessment Method)

2.1. Ngữ cảnh sử dụng FAAM

2.2. Mục tiêu của FAAM

2.3. Những yếu tố dẫn đến sự hình thành của FAAM

2.4. Các yêu cầu và đầu vào của FAAM

2.5. Các bước trong một phiên đánh giá FAAM

2.6. Các đối tượng tham gia phiên đánh giá FAAM

2.7. Ước lượng chi phí khi áp dụng FAAM

2.8. Công cụ hỗ trợ FAAM

2.9. Các thay thế cho FAAM

2.10. Các ưu điểm và đầu ra của FAAM

2.4. Phƣơng pháp phân tích cân bằng kiến trúc-ATAM (Architecture Tradeoff Analysis Method)

2.1. Giới thiệu phương pháp

2.2. Mô tả thuộc tính chất lượng

2.4. Đầu ra của ATAM

2.5. Chi tiết các bước thực hiện phiên đánh giá ATAM

2.6. Đối tượng tham gia phiên đánh giá ATAM

2.7. Ước lượng chi phí khi áp dụng phương pháp ATAM

2.8. Công cụ hỗ trợ ATAM

2.9. Các phương pháp thay thế cho ATAM

2.10. Đầu ra và điểm mạnh của ATAM

2.11. Lịch biểu thực hiện một phiên đánh giá ATAM điển hình

2.5. Phƣơng pháp đánh giá kiến trúc phần mềm CBAM (Cost-Benefit Analysis Method)

2.1. Bối cảnh hình thành phương pháp CBAM

2.2. Mục tiêu của CBAM

2.3. Các yếu tố dẫn đến sự phát triển CBAM

2.4. Yêu cầu và đầu vào của CBAM

2.5. Các bước thực hiện phiên đánh giá CBAM

2.6. Các đối tượng tham gia trong CABM

2.7. Ước lượng chi phí khi áp dụng CBAM

2.8. Công cụ hỗ trợ CBAM

2.9. Các phương pháp thay thế CBAM

2.10. Mục tiêu và ưu điểm của CBAM

2.6. So sánh một số đặc điểm của các phƣơng pháp đánh giá kiến trúc

3. Chƣơng 3: TÍCH HỢP ATAM-CBAM VÀ ĐỀ XUẤT QUI TRÌNH ĐÁNH GIÁ

3.1. Hƣớng tiếp cận tích hợp ATAM và CBAM

3.2. Cải tiến ATAM

3.3. Cải tiến CBAM

3.4. Đề xuất qui trình

4. Chƣơng 4: ÁP DỤNG QUI TRÌNH TÍCH HỢP ATAM-CBAM PHÂN TÍCH KIẾN TRÚC CHO DỰ ÁN VANCO-NETDIRECT

4.1. Mô tả dự án Vanco-NetDirect

4.1. Thông tin sơ bộ

4.2. Mô tả các Business drivers

4.1. Mục tiêu doanh nghiệp (Business goals)

4.2. Các yêu cầu chính (Yêu cầu về chất lượng)

4.3. Bối cảnh doanh nghiệp

4.3. Vận dụng ATAM-CBAM đánh giá kiến trúc

4.1. Phát triển các scenario

4.2. Gán mức ưu tiên cho các scenario

4.3. Xác định các tiếp cận kiến trúc

4.5. Đánh giá kết quả

PHỤ LỤC 1

Vanco-NetDirect Software Requirement Specification

Functional requirements Overview

Non-Functional core requirements

PHỤ LỤC 2 DANH MỤC CÁC TỪ VIẾT TẮT

TÀI LIỆU THAM KHẢO

Tóm tắt

I. Tổng quan về Tích Hợp ATAM CBAM Trong Đánh Giá Kiến Trúc Phần Mềm

Tích hợp ATAM và CBAM là một phương pháp đánh giá kiến trúc phần mềm hiệu quả, giúp các nhà phát triển và quản lý dự án tối ưu hóa quy trình phát triển phần mềm. Việc áp dụng hai phương pháp này không chỉ giúp đánh giá chất lượng kiến trúc mà còn giảm thiểu rủi ro trong quá trình phát triển. Bài viết này sẽ đi sâu vào các khía cạnh quan trọng của việc tích hợp ATAM-CBAM trong dự án Vanco-NetDirect.

1.1. Khái niệm về ATAM và CBAM trong Đánh Giá Kiến Trúc

ATAM (Architecture Tradeoff Analysis Method) và CBAM (Cost-Benefit Analysis Method) là hai phương pháp phổ biến trong đánh giá kiến trúc phần mềm. ATAM tập trung vào phân tích các quyết định kiến trúc và các thuộc tính chất lượng, trong khi CBAM đánh giá chi phí và lợi ích của các quyết định đó.

1.2. Tại sao cần Tích Hợp ATAM và CBAM

Việc tích hợp ATAM và CBAM giúp tối ưu hóa quy trình đánh giá kiến trúc, cho phép các nhà phát triển có cái nhìn toàn diện hơn về các quyết định kiến trúc. Điều này không chỉ giúp cải thiện chất lượng phần mềm mà còn giảm thiểu chi phí và thời gian phát triển.

II. Vấn Đề và Thách Thức Trong Đánh Giá Kiến Trúc Phần Mềm

Đánh giá kiến trúc phần mềm thường gặp nhiều thách thức, từ việc xác định các yêu cầu chất lượng đến việc phân tích các quyết định kiến trúc. Những vấn đề này có thể dẫn đến việc lựa chọn kiến trúc không phù hợp, gây ra rủi ro lớn cho dự án.

2.1. Các Vấn Đề Thường Gặp Trong Đánh Giá Kiến Trúc

Một số vấn đề phổ biến bao gồm việc thiếu thông tin về yêu cầu, sự không đồng nhất trong quan điểm của các bên liên quan, và khó khăn trong việc đánh giá các thuộc tính chất lượng. Những vấn đề này có thể ảnh hưởng đến quyết định cuối cùng về kiến trúc.

2.2. Thách Thức Trong Việc Áp Dụng ATAM và CBAM

Khi áp dụng ATAM và CBAM, các nhà phát triển có thể gặp khó khăn trong việc thu thập dữ liệu cần thiết và phân tích các kịch bản khác nhau. Điều này đòi hỏi sự hợp tác chặt chẽ giữa các bên liên quan để đảm bảo rằng tất cả các yếu tố được xem xét.

III. Phương Pháp Tích Hợp ATAM CBAM Để Đánh Giá Kiến Trúc

Phương pháp tích hợp ATAM và CBAM bao gồm các bước cụ thể để đánh giá kiến trúc phần mềm một cách hiệu quả. Quy trình này giúp các nhà phát triển có thể đưa ra quyết định chính xác hơn về kiến trúc của dự án.

3.1. Các Bước Trong Quy Trình Tích Hợp

Quy trình tích hợp bao gồm việc xác định các kịch bản, đánh giá các thuộc tính chất lượng, và phân tích chi phí-lợi ích. Mỗi bước đều quan trọng để đảm bảo rằng kiến trúc được đánh giá một cách toàn diện.

3.2. Lợi Ích Của Việc Tích Hợp ATAM CBAM

Việc tích hợp này không chỉ giúp cải thiện chất lượng kiến trúc mà còn giúp giảm thiểu rủi ro và chi phí phát triển. Nó cũng tạo ra một quy trình đánh giá rõ ràng và có hệ thống hơn.

IV. Ứng Dụng Tích Hợp ATAM CBAM Trong Dự Án Vanco NetDirect

Dự án Vanco-NetDirect là một ví dụ điển hình cho việc áp dụng tích hợp ATAM-CBAM trong đánh giá kiến trúc phần mềm. Việc áp dụng này đã mang lại nhiều kết quả tích cực cho dự án.

4.1. Mô Tả Dự Án Vanco NetDirect

Dự án Vanco-NetDirect tập trung vào việc phát triển một hệ thống phần mềm đáp ứng các yêu cầu chất lượng cao. Việc áp dụng ATAM-CBAM đã giúp xác định rõ các yêu cầu và quyết định kiến trúc.

4.2. Kết Quả Đánh Giá Kiến Trúc Dự Án

Kết quả từ việc áp dụng tích hợp ATAM-CBAM cho thấy rằng kiến trúc phần mềm của dự án đã được cải thiện đáng kể, với các thuộc tính chất lượng được nâng cao và rủi ro được giảm thiểu.

V. Kết Luận và Tương Lai Của Tích Hợp ATAM CBAM

Tích hợp ATAM và CBAM trong đánh giá kiến trúc phần mềm là một bước tiến quan trọng trong việc nâng cao chất lượng phần mềm. Tương lai của phương pháp này hứa hẹn sẽ mang lại nhiều cải tiến cho quy trình phát triển phần mềm.

5.1. Tương Lai Của Đánh Giá Kiến Trúc Phần Mềm

Với sự phát triển không ngừng của công nghệ, việc áp dụng các phương pháp đánh giá kiến trúc như ATAM và CBAM sẽ ngày càng trở nên quan trọng hơn. Các nhà phát triển cần tiếp tục nghiên cứu và cải tiến quy trình này.

5.2. Khuyến Nghị Cho Các Dự Án Tương Lai

Các dự án trong tương lai nên xem xét việc áp dụng tích hợp ATAM-CBAM để đảm bảo rằng kiến trúc phần mềm được đánh giá một cách toàn diện và hiệu quả. Điều này sẽ giúp giảm thiểu rủi ro và nâng cao chất lượng sản phẩm cuối cùng.

22/07/2025
Luận văn thạc sĩ vnu uet tích hợp atam cbam trong đánh giá kiến trúc phần mềm và áp dụng cho dự án vanco netdirect tại công ty phần mềm fsoft

Trích đoạn nội dung tài liệu

Chương 1: Tổng quan về phƣơng pháp đánh giá kiến trúc phần mềm. Chương này chủ yếu giới thiệu về các định nghĩa, khái niệm cơ bản liên quan đến kiến trúc phần mềm, đồng thời cũng cho biết vị trí, vai trò và tầm quan trọng của kiến trúc phần mềm trong thiết kế phần mềm – đặc biệt là các phần mềm đòi hỏi chất lượng cao. Chương 2: Một số phƣơng pháp đánh giá kiến trúc phần mềm dựa trên scenario. Chương này giới thiệu và phân tích 5 phương pháp đánh giá kiến trúc phần mềm dựa trên scenario đang được sử dụng rộng rãi hiện nay là: SAAM (Software Architecture Analysis Method), ALMA (Architecture Level Modifiability Analysis), FAAM (Family Architecture Analysis Method), ATAM (Architecture Tradeoff Analysis Method) và CBAM (Cost-Benefit Analysis Method).

Trong đó hai phương pháp ATAM và CBAM được mô tả chi tiết hơn. Ngoài ra, chương này cũng thực hiện việc so sánh 5 phương pháp này ở một số khía cạnh, cho biết rõ hơn về những điểm mạnh, yếu và phạm vi áp dụng của từng phương pháp. Chương 3: Tích hợp ATAM –CBAM và đề xuất qui trình đánh giá. Chương này phân tích một số đặc điểm của phương pháp ATAM và CBAM, cải tiến và bổ sung một số hoạt động bên trong để có một phương pháp phân tích mới, tốt hơn và tối ưu hơn (nhưng vẫn trên nền 2 phương pháp đó).

Trên cơ sở tích hợp này, đề xuất ra một qui trình đánh giá tương ứng. Qui trình này sẽ được dùng để đánh giá kiến trúc cho một dự án phần mềm thực tế tại FSoft, đó là : Vanco-NetDirect. Chương 4: Áp dụng ATAM – CBAM vào đánh giá kiến trúc cho hệ thống phần mềm Vanco-NetDirect tại công ty cổ phần phần mềm FSoft. Nội dung của chương này tập trung chủ yếu vào việc đánh giá kiến trúc phần mềm cho dự án thực tế (Vanco-NetDirect) của công ty phần mềm FSoft bằng chính hai phương pháp ATAM và CBAM và qui trình đã xây dựng được ở chương 3.

-8- LUAN VAN CHAT LUONG download : add luanvanchat@agmail.com CHƢƠNG 1: TỔNG QUAN VỀ PHƢƠNG PHÁP ĐÁNH GIÁ KIẾN TRÚC PHẦN MỀM – SOFTWARE EVALUATION 1.1 Một số định nghĩa về kiến trúc phần mềm Kiến trúc phần mềm tuy là lĩnh vực mới nhưng đang phát triển rất nhanh chóng, vì vậy sẽ không có một định nghĩa duy nhất được chấp nhận. Hay nói theo cách khác là có vô số những định nghĩa liên quan đến khái niệm này. Tuy vậy, trong các định nghĩa đó đều có những đặc điểm chung là đề cập đến các khái niệm như Cấu trúc, phần tử và kết nối giữa các phần tử [2]. Hiện nay, SEI (Software Engineering Insitute) đang duy trì một danh sách các định nghĩa về kiến trúc phần mềm.

Sở dĩ có nhiều các định nghĩa như vậy là bởi trong các hoạt động thiết kế, tùy theo từng giai đoạn thiết kế khác nhau, quan điểm nhìn khác nhau và ngữ cảnh khác nhau mà người ta cần trừu tượng hóa hệ thống theo những cách thích hợp, chẳng hạn về các khía cạnh như hoạt động của hệ thống, sự truyền thông giữa các thành phần, các phương pháp tiếp cận, các kết quả, v.v… Dưới đây là một số trong rất nhiều các định nghĩa về kiến trúc phần mềm: Kiến trúc là bản thiết kế hệ thống ở mức cao (high-level). Kiến trúc là cấu trúc tổng thể của hệ thống. Kiến trúc là cấu trúc các thành phần của một chương trình hay hệ thống, các nguyên tắc quản lý thiết kế theo thời gian. Đây là định nghĩa lấy tiến trình làm trung tâm.

Kiến trúc là các thành phần và các kết nối. Các kết nối ở đây là cơ chế truyền điều khiển và dữ liệu trong khi chạy. Vì vậy định nghĩa này tập trung vào các cấu trúc thuộc kiến trúc lúc runtime. Kiến trúc là sự mô tả trừu tượng nhất về hệ thống mà ở đó nó cho phép ta có thể suy đoán về các yêu cầu có ý nghĩa quyết định đến chất lượng phần mềm.

Tuy nhiên, một điều phải nói ở đây là cần phải phân biệt rõ thế nào thì được coi là kiến trúc và thế nào thì không coi là kiến trúc. Vì theo một số định nghĩa thì kiến trúc là cấu trúc của một số thành phần, các kết nối và mối quan hệ giữa các thành phần, nhưng điều ngược lại thì không phải lúc nào cũng đúng. Xin lấy ra một ví dụ sau đây để thấy rõ hơn về khái niệm này [2]. Giả sử ta đưa ra một biểu đồ như sau: Control Process MODP MODR MODN Hình 1 - Ví dụ mô tả kiến trúc điển hình nhưng không đem lại thông tin -9- LUAN VAN CHAT LUONG download : add luanvanchat@agmail.com Với biểu đồ này, chúng ta có 4 phần tử, trong đó có 3 phần tử cùng mức với nhau và chúng có một loại quan hệ nào đó (vì chúng hoàn toàn được kết nối với nhau).

Câu hỏi là liệu đây có phải là kiến trúc không?. Rõ ràng nếu nếu chúng ta coi kiến trúc là một tập các thành phần/phần tử (ở đây có 4), tập các kết nối (đã có như trong hình vẽ) và tập các quan hệ giữa chúng thì rõ ràng có vẻ như đây là kiến trúc của một hệ thống nào đó. Nhưng ngay cả khi chúng ta chấp nhận thì một loạt những câu hỏi cần đặt ra cho Diagram này:  Các phần tử đó thuộc loại gì? Ý nghĩa của sự phân cấp đó? Các phần tử có bao gồm các tiến trình, chương trình hay cả hai? Chúng có miêu tả các cách thức để từ đó phân chia dự án không? Chúng là các đối tượng, chức năng, tiến trình, chương trình phân tán hay một thứ nào khác? Vai trò của các phần tử? Chúng làm việc gì? Chức năng của chúng trong hệ thống ra sao? Ý nghĩa của các kết nối? Các kết nối có nói lên rằng các phần tử giao tiếp, điều khiển, gửi dữ liệu, sử dụng lẫn nhau, triệu gọi lẫn nhau hay đồng bộ với nhau hay không? Các cơ chế để truyền thông là gì? Luồng thông tin đi cùng với các cơ chế đó (nếu có) là gì? Ý nghĩa của việc bố trí (Layout) sơ đồ đó là gì? Tại sao CP lại ở mức riêng biệt (trên cùng)? Nó có gọi đến 3 thành phần kia hay không hay 3 thành phần đó có được phép gọi CP hay không?. Như vậy, rõ ràng một kiến trúc không chỉ đơn thuần là các thành phần, kết nối mà quan trọng hơn các kết nối này phải có ý nghĩa (Tức mối quan hệ phải có tính logic), và chúng phải thể hiện một khung nhìn nào đó về hệ thống đồng thời chúng phải cộng tác để đạt được một mục tiêu nhất định.2 Tầm quan trọng của kiến trúc phần mềm Kiến trúc phần mềm là công cụ đầu tiên chúng ta dựa vào để xây dựng hệ thống, nó là nền tảng cơ sở cho các pha tiếp theo.

Tầm quan trọng của nó thể hiện qua ba điểm: 1. Là công cụ để giao tiếp giữa những người có liên quan đến hệ thống. Kiến trúc phần mềm là sự mô tả chung nhất bản nhất của hệ thống mà hầu hết những người liên quan đều có thể hiểu được và sẽ sử dụng nó để đàm phán, thảo luận, biểu quyết cũng như để hiểu rõ hơn về hệ thống. Là quyết định thiết kế (design decisions) sớm nhất.

Kiến trúc phần mềm thể hiện sớm nhất một cách rõ ràng các quyết định về hệ thống và điều này ảnh hưởng đến toàn bộ phần phát triển và bảo trì hệ thống còn lại. Nó cũng là thời điểm sớm nhất mà tại đó các quyết định thiết kế có thể được phân tích. Truyền tải các ý tưởng cơ bản về hệ thống. Kiến trúc phần mềm Software là một mô hình để từ đó ta có thể hiểu được cấu trúc của một hệ thống, cách thức các phần tử làm việc cùng với nhau và có thể áp dụng cho các hệ thống khác với các yêu cầu chức năng, các thuộc tính chất lượng tương tự nhau.

-10- LUAN VAN CHAT LUONG download : add luanvanchat@agmail.com Để thấy rõ được tầm quan trọng của kiến trúc, sau đây xin được phân tích một cách chi tiết. Kiến trúc là công cụ truyền tải giữa những ngƣời liên quan đến hệ thống. Mỗi người liên quan đến hệ thống – như khách hàng, người dùng, quản lý dự án, lập trình, kiểm thử viên, v. – đều liên quan đến mặt nào đó của hệ thống và các mặt này đều có bị tác động bởi kiến trúc của chính hệ thống đó.

Ví dụ, người dùng thì liên quan đến độ tin cậy và tính sẵn sàng; khách hàng thì liên quan đến việc kiến trúc phải được áp dụng trong khoảng thời gian và ngân sách giới hạn; người quản lý dự án không chỉ quan tâm đến tiến độ và ngân sách mà còn quan tâm xem kiến trúc đó phải cho phép nhóm làm việc độc lập hơn, có sự tương tác dưới sự kiểm soát nào đó; nhà kiến trúc thì lại quan tâm đến các chiến lược để đạt được tất cả các mục tiêu đó. Kiến trúc cung cấp cho chúng ta một ngôn ngữ chung mà ở đó các vấn đề liên quan có thể được mô tả, được thảo luận và được giải quyết ngay cả đối với các hệ thống lớn và phức tạp. Nếu không có một ngôn ngữ như vậy thì sẽ rất khó khăn để có thể hiểu đầy đủ về hệ thống có qui mô lớn, để từ đó đưa ra các quyết định sớm hơn, tác động đến cả tính hữu dụng và chất lượng phần mềm. Công cụ giao tiếp này sẽ làm cơ sở cho việc phân tích các kiến trúc về sau.3 Kiến trúc và khung nhìn kiến trúc Đối với những dự án lớn và phức tạp, chúng ta cần có rất nhiều những khung nhìn (cách nhìn) liên quan đến kiến trúc của hệ thống đó.

Một khung nhìn (View) là sự mô tả một số phần tử của hệ thống và mối quan hệ đi cùng với chúng. Các khung nhìn sẽ giúp ta hiểu rõ từng thành phần liên quan thông qua hệ thống khái niệm trừu tượng. Các khung nhìn khác nhau đáp ứng cho những người dùng khác nhau – ở đây là những người quan tâm đến kiến trúc. Những khung nhìn nào liên quan đến nhau còn tùy vào đối tượng người tham gia và các thuộc tính hệ thống mà họ quan tâm.

Chúng ta có thể lấy kiến trúc của một tòa nhà làm ví dụ, sẽ có rất nhiều người liên quan đến xây dựng tòa nhà đó (kỹ sư xây dựng, thợ ống nước, thợ điện…) đều quan tâm đến việc toàn nhà được xây dựng như thế nào.

Nội dung được bảo vệ bản quyền — Tải xuống đầy đủ