Bài giảng Công nghệ phần mềm - Đinh Thị Lương

326 trang huongle 8570

Download

Bạn đang xem 20 trang mẫu của tài liệu "Bài giảng Công nghệ phần mềm - Đinh Thị Lương", để tải tài liệu gốc về máy bạn click vào nút DOWNLOAD ở trên

Tài liệu đính kèm:

bai_giang_cong_nghe_phan_mem_dinh_thi_luong.ppt

Nội dung text: Bài giảng Công nghệ phần mềm - Đinh Thị Lương

CÔNG NGHỆ PHẦN MỀM ThS. Đinh Thị Lương dt.luong@hutech.edu.vn 5/23/2021 1
Giới thiệu · Số tiết: 45 · Điểm tổng kết ü Semina giữa kỳ: 30% ü Thi cuối kỳ: 70% 5/23/2021 2
Tài liệu tham khảo · R. Pressman, "Software Engineering A Practitioner's Approach", 2001 · Ian Sommerville’s , “Software Engineering 7th Ed.”, 2005 · Các giáo trình, bài giảng môn Công nghệ Phần mềm của Khoa Công nghệ Thông tin của các trường Đại học trên thế giới. 5/23/2021 3
Tài liệu tham khảo · R. Pressman, "Software Engineering A Practitioner's Approach", 2001 · Ian Sommerville’s , “Software Engineering 7th Ed.”, 2005 · Các giáo trình, bài giảng môn Công nghệ Phần mềm của Khoa Công nghệ Thông tin của các trường Đại học trên thế giới. 5/23/2021 4
Các vấn đề liên quan · Điều kiện tiên quyết: ü Có kiến thức về ngôn ngữ lập trình và đã từng lập trình các ứng dụng cơ bản ü Có khả năng áp dụng những cấu trúc dữ liệu và giải thuật. ü Có hiểu biết về kiến trúc máy tính, mạng máy tính. 5
Các vấn đề liên quan (tt1) · Mục tiêu môn học: giúp sinh viên ü Hiểu và giải thích được quy trình phát triển phần mềm ü Phân tích được các yêu cầu của người sử dụng ü Lựa chọn một mô hình quy trình phát triển phần mềm thích hợp cho một sản phẩm cụ thể. ü Giải thích tầm quan trọng của các hoạt động đánh giá chất lượng phần mềm. ü Biết được phải tạo ra những kết quả gì trong từng giai đoạn của quy trình phát triển phần mềm. ü Áp dụng các mô hình thiết kế hệ thống thích hợp cho từng sản phẩm cụ thể. ü Sử dụng các CASE Tool để hỗ trợ quá trình phát triển phần mềm. 5/23/2021 6
Nội dung chương trình · Chương 1 Tổng quan về công nghệ phần mềm ü Giới thiệu về một số khái niệm cơ bản ü Thế nào là một phần mềm tốt? - Thách thức đối với công nghệ phần mềm? ü Vấn đề về tính chuyên nghiệp và đúng quy tắc ü Bài tập 5/23/2021 7
Nội dung chương trình (tt1) · Chương 2 Quy trình xây dựng phần mềm ü Một số mô hình phát triển phần mềm ü Các hoạt động trong quy trình phần mềm ü Bài tập 5/23/2021 8
Nội dung chương trình (tt2) · Chương 3 Yêu cầu hệ thống ü Yêu cầu hệ thống ü Yêu cầu của người sử dụng ü Tài liệu đặc tả yêu cầu ü Bài tập 5/23/2021 9
Nội dung chương trình (tt3) · Chương 4 Quy trình xác định yêu cầu ü Phân tích khả thi ü Phát hiện và phân tích yêu cầu ü Đánh giá yêu cầu ü Lập kế hoạch quản lý yêu cầu ü Bài tập 5/23/2021 10
Nội dung chương trình (tt5) · Chương 5 Các mô hình hệ thống ü Mô hình ngữ cảnh ü Mô hình ứng xử ü Mô hình dữ liệu ü Mô hình đối tượng ü Phương pháp hướng cấu trúc ü Bài tập 5/23/2021 11
Nội dung chương trình (tt6) · Chương 6 Thiết kế kiến trúc ü Thiết kế kiến trúc là gì? ü Tổ chức hệ thống ü Phân rã hệ thống ü Các chiến lược điều khiển ü Các kiến trúc tham chiếu ü Bài tập 5/23/2021 12
Nội dung chương trình (tt7) · Chương 7 Thiết kế giao diện người dùng ü Giao diện người dùng ü Quy trình thiết kế giao diện người dùng ü Bài tập 5/23/2021 13
Nội dung chương trình (tt8) · Chương 8 Cải tiến phần mềm ü Bảo trì phần mềm ü Các quy trình cải tiến phần mềm ü Tái kỹ nghệ hệ thống ü Bài tập 5/23/2021 14
Nội dung chương trình (tt9) · Chương 9 Kiểm thử phần mềm ü Quy trình kiểm thử ü Kiểm thử hệ thống ü Bài tập 5/23/2021 15
Nội dung chương trình (tt10) · Chương 10 Quản lý dự án ü Định nghĩa về quản lý dự án ü Các hoạt động quản lý ü Lập kế hoạch dự án ü Lịch biểu của dự án ü Quản lý rủi ro ü Bài tập 5/23/2021 16
Nội dung chương trình (tt11) · Chương 11 Chuẩn và các quy trình hoạt động trong công nghiệp phần mềm ü Các quy trình hoạt động ü Các vai trò trong hoạt động sản xuất phần mềm - Khái niệm vai trò - Các vai trò ü Hệ thống chuẩn trong công nghiệp phần mềm 5/23/2021 17
Chương 1 Tổng quan về công nghệ phần mềm
Giới thiệu · Ngày nay, tất cả các nước phát triển đều phụ thuộc chủ yếu vào các hệ thống phần mềm. Và càng ngày càng có nhiều hệ thống được kiểm soát bởi phần mềm. Do đó, việc xây dựng và bảo trì hệ thống phần mềm một cách hiệu quả là yêu cầu cần thiết đối với nền kinh tế toàn cầu và của từng quốc gia. · Khái niệm về công nghệ phần mềm được đưa ra lần đầu tiên vào năm 1968 tại hội nghị thảo luận về khủng hoảng phần mềm. Công nghệ phần mềm đề cập tới các lý thuyết, phương thức và công cụ để xây dựng phần mềm chuyên nghiệp, mang lại lợi nhuận cao. 5/23/2021 19
Giới thiệu (tt1) · Trong chương đầu tiên, chúng ta sẽ tìm hiểu về một số khái niệm cơ bản có liên quan tới phần mềm và công nghệ phần mềm. Để từ đó, chúng ta có những hiểu biết cơ bản để tiếp tục nghiên cứu các chương tiếp theo. · Ngoài ra, quy trình xây dựng phần mềm đòi hỏi phải tuân thủ các nguyên tắc vô cùng chặt chẽ. Do đó, trong phần cuối chương này, chúng ta sẽ tìm hiểu về những yêu cầu căn bản đối với một kỹ sư phần mềm. 5/23/2021 20
Mục tiêu · Hiểu rõ các khái niệm liên quan đến phần mềm và công nghệ phần mềm được trình bày trong phần 1. · Biết được một số nguyên tắc cơ bản về tính chuyên nghiệp và đúng nguyên tắc đối với kỹ sư phần mềm. · Có thể tham khảo thêm về một số nguyên tắc của “Code of Ethics” để hiểu rõ hơn về các nguyên tắc đối với một kỹ sư phần mềm. 5/23/2021 21
Một số khái niệm cơ bản · Khi tìm hiểu về công nghệ phần mềm, chúng ta thường đặt ra một số câu hỏi sau: ü Phần mềm là gì? ü Công nghệ phần mềm là gì? ü Sự khác biệt giữa công nghệ phần mềm và khoa học máy tính? ü Sự khác biệt giữa công nghệ phần mềm và công nghệ hệ thống? ü Quy trình phần mềm là gì? ü Mô hình quy trình phát triển phần mềm là gì? ü Chi phí của công nghệ phần mềm bao gồm những gì? ü Các phương pháp công nghệ phần mềm là gì? ü CASE (Computer-Aided Software Engineering) là gì? ü Thế nào là một phần mềm tốt? ü Những thách thức chính đối với công nghệ phần mềm? 5/23/2021 22
Một số khái niệm cơ bản (tt1) · Phần mềm là gì? ü Phần mềm là các chương trình máy tính và những tài liệu liên quan đến nó như: các yêu cầu, mô hình thiết kế, tài liệu hướng dẫn sử dụng Do đó, chúng ta thấy rằng đặc điểm của phần mềm là trừu tượng và vô hình. ü Các sản phẩm phần mềm được chia thành 2 loại: - Sản phẩm đại trà (Generic Product): * được phát triển để bán ra ngoài thị trường, đối tượng người sử dụng là tương đối đa dạng và phong phú. Những sản phẩm phần mềm thuộc loại này thường là những phần mềm dành cho máy PC. - Sản phầm theo đơn đặt hàng (Bespoke Product hoặc Customised Product): * được phát triển cho một khách hàng riêng lẻ theo yêu cầu. Ví dụ: Những hệ thống phần mềm chuyên dụng, hỗ trợ nghiệp vụ cho một doanh nghiệp riêng lẻ 5/23/2021 23
Một số khái niệm cơ bản (tt2) · Công nghệ phần mềm là gì? ü Công nghệ phần mềm là những quy tắc công nghệ (engineering discipline) có liên quan đến tất cả các khía cạnh của quá trình sản xuất phần mềm. ü Các kỹ sư phần mềm nên tuân theo một phương pháp luận có hệ thống và có tổ chức trong công việc của họ. Đồng thời, họ nên sử dụng các công cụ và kỹ thuật thích hợp với vấn đề cần giải quyết, các ràng buộc và tài nguyên sẵn có. 5/23/2021 24
Một số khái niệm cơ bản (tt3) · Sự khác biệt giữa công nghệ phần mềm và khoa học máy tính? ü Khoa học máy tính đề cấp tới lý thuyết và những vấn đề cơ bản; còn công nghệ phần mềm đề cập tới các hoạt động xây dựng và đưa ra một phần mềm hữu ích. ü Khi sự phát triển của phần mềm trở lên mạnh mẽ thì các lý thuyết của khoa học máy tính vẫn không đủ để đóng vai trò là nền tảng hoàn thiện cho công nghệ phần mềm. 5/23/2021 25
Một số khái niệm cơ bản (tt4) · Sự khác biệt giữa công nghệ phần mềm và công nghệ hệ thống? ü Công nghệ hệ thống (hay còn gọi là kỹ nghệ hệ thống) liên quan tới tất cả các khía cạnh của quá trình phát triển hệ thống dựa máy tính bao gồm: phần cứng, phần mềm, và công nghệ xử lý. - Công nghệ phần mềm chỉ là một phần của quy trình này, nó có liên quan tới việc phát triển hạ tầng phần mềm (software infrastructure), điều khiển, các ứng dụng và cơ sở dữ liệu trong hệ thống. ü Kỹ sư hệ thống phải thực hiện việc đặc tả hệ thống, thiết kế kiến trúc hệ thống, tích hợp và triển khai. 5/23/2021 26
Một số khái niệm cơ bản (tt5) · Quy trình phần mềm là gì? ü Quy trình phần mềm là một tập hợp các hành động mà mục đích của nó là xây dựng và phát triển phần mềm. Những hành động thường được thực hiện trong các quy trình phần mềm bao gồm - Đặc tả: đặc tả những gì hệ thống phải làm và các ràng buộc trong quá trình xây dựng hệ thống. - Phát triển: xây dựng hệ thống phần mềm. - Kiểm thử: kiểm tra xem liệu phần mềm đã thoả mãn yêu cầu của khách hàng. - Mở rộng: điều chỉnh và thay đổi phần mềm tương ứng với sự thay đổi yêu cầu. ü Những loại hệ thống khác nhau sẽ cần những quy trình phát triển khác nhau. Ví dụ, hệ thống thời gian thực yêu cầu phải hoàn thành đặc tả hệ thống trước khi chuyển sang giai đoạn xây dựng nó. Nhưng với hệ thống thương mại điện tử, chúng ta có thể vừa đặc tả vừa xây dựng chương trình một cách đồng thời. 5/23/2021 27
Một số khái niệm cơ bản (tt6) · Mô hình quy trình phát triển phần mềm là gì? ü Mô hình quy trình phát triển phần mềm là một thể hiện đơn giản của một quy trình phần mềm, và nó được biểu diễn từ một góc độ cụ thể. ü Sau đây là một số ví dụ về mô hình quy trình phát triển phần mềm: - Mô hình luồng công việc (workflow): mô tả một chuỗi các hành động cần phải thực hiện. - Mô hình luồng dữ liệu (data-flow): mô tả luồng thông tin. - Mô hình Vai trò/Hành động (Role/action): chỉ ra vai trò của những người liên quan trong quy trình phần mềm và nhiệm vụ của từng người. ü Ngoài ra, còn có một số mô hình quy trình chung cũng được đễ xuất như: - Mô hình thác nước (waterfall) - Mô hình phát triển lặp lại (Iterative development) - Mô hình công nghệ phần mềm dựa thành phần (Component- based software engineering). 5/23/2021 28
Một số khái niệm cơ bản (tt7) · Các chi phí trong công nghệ phần mềm ü Để xây dựng một hệ thống phần mềm, chúng ta thường phải đầu tư một khoản ngân sách khá lớn. - Theo thống kê cho thấy, chi phí cho việc xây dựng phần mềm chiếm một phần đáng kể của GNP ở tất cả các nước phát triển. ü Chi phí phần mềm thường chiếm phần lớn chi phí của cả hệ thống máy tính. - Chi phí phần mềm trên máy PC thường lớn hơn chi phí phần cứng. - Chi phí phần mềm dành cho việc bảo trì phần mềm thường lớn hơn chi phí xây dựng phần mềm. - Đối với những hệ thống hoạt động trong thời gian dài, thì chi phí bảo trì thường lớn gấp nhiều lần so với chi phí xây dựng. 5/23/2021 29
Một số khái niệm cơ bản (tt8) · Các chi phí trong công nghệ phần mềm (tt1) ü Xấp xỉ 60% chi phí là chi phí xây dựng và 40% là chi phí kiểm thử. - Đối với những phần mềm làm theo yêu cầu của khách hàng, chi phí mở rộng thường vượt quá chi phí xây dựng. ü Chi phí biến đổi tuỳ thuộc vào từng loại hệ thống được xây dựng và các yêu cầu về đặc điểm của hệ thống như: hiệu năng và độ tin cậy của hệ thống. 5/23/2021 30
Một số khái niệm cơ bản (tt9) · Các chi phí trong công nghệ phần mềm (tt2) ü Việc phân bổ chi phí cũng phụ thuộc vào mô hình phát triển hệ thống được sử dụng. ü Sau đây là bảng so sánh chi phí của 3 mô hình phổ biến nhất, thường được sử dụng: - Mô hình thác nước: * Chi phí của các pha đặc tả, thiết kế, cài đặt, tích hợp và kiểm thử được xác định một cách riêng rẽ. 5/23/2021 31
Một số khái niệm cơ bản (tt10) · Các chi phí trong công nghệ phần mềm (tt3) - Mô hình phát triển lặp lại: * Không thể phân biệt rõ chi phí cho từng pha trong quy trình. * Chi phí đặc tả giảm vì đây là đặc tả ở bậc cao. * Tại mỗi bước lặp, các pha trong quy trình xây dựng hệ thống được thực hiện lại nhằm thực hiện các yêu cầu hệ thống khác nhau ở từng bước lặp. * Sau khi đã thực hiện hết các bước lặp, phải có chi phí kiểm thử toàn bộ hệ thống. 5/23/2021 32
Một số khái niệm cơ bản (tt11) · Các chi phí trong công nghệ phần mềm (tt4) - Mô hình công nghệ phần mềm hướng thành phần: * Chi phí phụ thuộc nhiều vào việc tích hợp và kiểm thử hệ thống. - Ngoài chi phí xây dựng, chúng ta còn phải để một phần lớn chi phí phục vụ cho việc thay đổi phần mềm sau khi nó đã được đưa vào sử dụng. Chi phí cải tiến phần mềm thay đổi phụ thuộc vào từng loại phần mềm. 5/23/2021 33
Một số khái niệm cơ bản (tt12) · Các phương pháp công nghệ phần mềm là gì? ü Phương pháp công nghệ phần mềm bao gồm các mô hình hệ thống, các ký pháp, quy tắc, hướng dẫn thiết kế và quy trình để xây dựng phần mềm một cách dễ dàng, đảm bảo chất lượng cao và chi phí hiệu quả. ü Một số phương pháp công nghệ phần mềm đã được đề xuất như: Phân tích hướng cấu trúc tập trung vào việc xác định các chức năng cơ bản của hệ thống; phương pháp hướng đối tượng tập trung vào việc định nghĩa các đối tượng và sự cộng tác giữa chúng 5/23/2021 34
CASE · CASE=(Computer-Aided Software Engineering) · Các phương pháp công nghệ phần mềm là gì? ü Các hệ thống CASE thường được sử dụng để hỗ trợ các hoạt động trong quy trình xây dựng phần mềm. Có hai loại CASE: - Upper-CASE: công cụ để hỗ trợ các hoạt động đầu tiên như đặc tả yêu cầu và thiết kế. - Lower-CASE: công cụ để hỗ trợ các hoạt động sau như lập trình, gỡ lỗi và kiểm thử. 5/23/2021 35
Phần mềm tốt? · Phần mềm phải đáp ứng các chức năng theo yêu cầu, có hiệu năng tốt, có khả năng bảo trì, đáng tin cậy, và được người sử dụng chấp nhận. ü Khả năng bảo trì: - phần mềm phải được điều chỉnh và mở rộng để thoả mãn những yêu cầu thay đổi. ü Mức độ tin cậy: - phần mềm phải được tin cậy, bảo mật và chính xác. ü Hiệu quả: - phần mềm không nên sử dụng lãng phí tài nguyên của hệ thống. ü Khả năng được chấp nhận: - người sử dụng phải chấp nhận phần mềm. Điều đó có nghĩa là nó phải dễ hiểu, sử dụng được và tương thích với các hệ thống khác. 5/23/2021 36
Phần mềm tốt? (tt1) · Thách thức đối với công nghệ phần mềm? ü Công nghệ phần mềm trong thế kỷ 21 phải đối mặt với rất nhiều thách thức to lớn. Với mỗi thách thức này, chúng ta phải có những giải pháp cụ thể. - Không đồng nhất: * phát triển các kỹ thuật xây dựng phần mềm để giải quyết sự không đồng nhất về môi trường thực hiện và nền tảng hạ tầng. - Chuyển giao: * phát triển các kỹ thuật nhằm dẫn tới việc chuyển giao phần mềm tới người sử dụng nhanh hơn. - Độ tin cậy: * phát triển các kỹ thuật để chứng minh rằng phần mềm được người sử dụng nó tin tưởng. 5/23/2021 37
Chuyên nghiệp, đúng quy tắc · Quy trình xây dựng phần mềm được thực hiện trong một môi trường chuyên nghiệp và đòi hỏi tuân thủ các nguyên tắc một cách chính xác. ü Những kỹ sư phần mềm phải coi công việc của họ là trách nhiệm to lớn, chứ không đơn thuần chỉ là việc ứng dụng kỹ thuật. 5/23/2021 38
Chuyên nghiệp, đúng quy tắc (tt1) · Kỹ sư phần mềm phải ứng xử trung thực và cách làm của họ phải rất chuyên nghiệp và đúng quy tắc. · Một số nguyên tắc cần thiết mà một kỹ sư phần mềm phải thực hiện. ü Sự tin cẩn: kỹ sư phần mềm phải tạo được sự tin cẩn từ phía nhân viên và khách hàng. ü Năng lực: kỹ sư phần mềm không nên trình bày sai khả năng của mình, không nên nhận những công việc vượt quá khả năng của mình. ü Các quyền về tài sản trí tuệ: kỹ sư phần mềm nên quan tâm về các tài sản trí tuệ được bảo hộ như: bằng sáng chế, quyền tác giả để đảm bảo rằng tất cả tài sản trí tuệ của nhân viên và khách hàng đều được bảo hộ. ü Lạm dụng máy tính: kỹ sư phần mềm không nên sử dụng các kỹ năng của mình để gây ảnh hưởng tới người khác. Lạm dụng máy tính có thể được hiểu là những việc tầm thường (Ví dụ: chơi điện tử trên máy tính của người khác) đến những vấn đề nghiêm trọng (Ví dụ: phát tán virus). 5/23/2021 39
Chuyên nghiệp, đúng quy tắc (tt2) · Vấn đề về tính chuyên nghiệp và đúng quy tắc đối với kỹ sư phần mềm quan trọng tới mức một số tổ chức ở Mỹ đã hợp tác để phát triển bản Code of Ethics gồm 8 quy tắc liên quan đến ứng xử và cách ra quyết định của các kỹ sư phần mềm chuyên nghiệp. 5/23/2021 40
Chương 2 Quy trình xây dựng phần mềm
Mở đầu · Giới thiệu: ü Quy trình xây dựng phần mềm (còn gọi tắt là quy trình phần mềm) là một tập hợp các hành động phải được thực hiện trong quá trình xây dựng một hệ thống phần mềm. ü Trong chương này, chúng ta sẽ tìm hiểu một số mô hình phát triển phần mềm thường được ứng dụng và đánh giá ưu và nhược điểm của chúng. Sau đó, chúng ta sẽ nghiên cứu chi tiết những công việc phải làm trong quá trình xây dựng một phần mềm và cách thực hiện chúng. · Mục tiêu: ü Hiểu rõ quy trình phần mềm ü Nắm được một số mô hình phát triển phần mềm ü Xác định chi tiết những công việc phải làm trong quy trình phần mềm và cách thực hiện chúng. ü Có thể ứng dụng những mô hình phát triển phần mềm đã nghiên cứu trên những hệ thống phần mềm cụ thể. 5/23/2021 42
Một số mô hình · Giới thiệu: ü Mô hình phát triển phần mềm là một thể hiện trừu tượng của quy trình phần mềm. Nó biểu diễn các đặc tả về quy trình từ những khía cạnh cụ thể; do đó, nó chỉ cung cấp một phần thông tin về quy trình phần mềm. ü Phần sau đây sẽ trình bày năm mô hình phát triển phần mềm phổ biến thường được sử dụng: - Mô hình thác nước - Mô hình xây dựng tiến triển - Công nghệ phần mềm dựa thành phần - Mô hình phát triển lặp lại, tăng thêm - Mô hình xoắn ốc 5/23/2021 43
Một số mô hình (tt1) · Mục tiêu: ü Phải hiểu rõ năm mô hình phát triển phần mềm cơ bản. ü Phân biệt được sự khác nhau giữa các mô hình; ưu và nhược điểm của từng mô hình. ü Biết rõ đối với loại hệ thống nào thì nên áp dụng mô hình phát triển nào cho phù hợp. 5/23/2021 44
Một số mô hình (tt2) · Mô hình thác nước: ü Các pha của mô hình thác nước bao gồm: - Phân tích và xác định các yêu cầu - Thiết kế hệ thống và phần mềm - Cài đặt và kiểm thử đơn vị - Tích hợp và kiểm thử hệ thống - Vận hành và bảo trì. ü Trong mô hình thác nước, năm pha trên phải được thực hiện một cách tuần tự; kết thúc pha trước, rồi mới được thực hiện pha tiếp theo. Do đó, nhược điểm chính của mô hình thác nước là rất khó khăn trong việc thay đổi các pha đã được thực hiện. 5/23/2021 45
Một số mô hình (tt3) · Mô hình thác nước (tt1): ü Cho nên, mô hình này chỉ thích hợp khi các yêu cầu đã được tìm hiểu rõ ràng và những thay đổi sẽ được giới hạn một cách rõ ràng trong suốt quá trình thiết kế. 5/23/2021 46
Một số mô hình (tt4) · Mô hình xây dựng tiến triển: ü Mô hình xây dựng tiến triển dựa trên ý tưởng xây dựng một mẫu thử ban đầu và đưa cho người sử dụng xem xét; sau đó, tinh chỉnh mẫu thử qua nhiều phiên bản cho đến khi thoả mãn yêu cầu của người sử dụng thì dừng lại. 5/23/2021 47
Một số mô hình (tt5) · Mô hình xây dựng tiến triển (tt1): ü Có hai phương pháp để thực hiện mô hình này: - Phát triển thăm dò: * mục đích của nó là để làm việc với khách hàng và để đưa ra hệ thống cuối cùng từ những đặc tả sơ bộ ban đầu. Phương pháp này thường bắt đầu thực hiện với những yêu cầu được tìm hiểu rõ ràng và sau đó, bổ sung những đặc điểm mới được đề xuất bởi khách hàng. Cuối cùng, khi các yêu cầu của người sử dụng được thoả mãn thì cũng là lúc chúng ta đã xây dựng xong hệ thống. - Loại bỏ mẫu thử: * mục đích là để tìm hiểu các yêu cầu của hệ thống. Phương pháp này thường bắt đầu với những yêu cầu không rõ ràng và ít thông tin. Các mẫu thử sẽ được xây dựng và chuyển giao tới cho người sử dụng. Từ đó, ta có thể phân loại những yêu cầu nào là thực sự cần thiết và lúc này mẫu thử không còn cần thiết nữa. Như vậy, mẫu thử chỉ có tác dụng để làm sáng tỏ yêu cầu của người sử dụng. 5/23/2021 48
Một số mô hình (tt6) · Mô hình xây dựng tiến triển (tt2): ü Tuy nhiên, nhược điểm của mô hình xây dựng tiến triển là: thiếu tầm nhìn của cả quy trình; các hệ thống thường hướng cấu trúc nghèo nàn; yêu cầu các kỹ năng đặc biệt. ü Mô hình xây dựng tiến triển chỉ nên áp dụng với những hệ thống có tương tác ở mức độ nhỏ hoặc vừa; trên một phần của những hệ thống lớn; hoặc những hệ thống có thời gian chu kỳ tồn tại ngắn. 5/23/2021 49
Một số mô hình (tt7) · Mô hình xây dựng tiến triển (tt3): 5/23/2021 50
Một số mô hình (tt7) · CNPM dựa thành phần: ü Mô hình này dựa trên kỹ thuật tái sử dụng một cách có hệ thống; trong đó hệ thống được tích hợp từ nhiều thành phần đang tồn tại hoặc các thành phần thương mại COTS (Commercial-off-the-shelf). 5/23/2021 51
Một số mô hình (tt8) · CNPM dựa thành phần (tt1): ü Các trạng thái chính của quy trình bao gồm: - Phân tích thành phần sẵn có - Điều chỉnh yêu cầu - Thiết kế hệ thống với kỹ thuật tái sử dụng - Xây dựng và tích hợp hệ thống 5/23/2021 52
Một số mô hình (tt9) · Mô hình phát triển lặp lại, tăng thêm: ü Mô hình này được đề xuất dựa trên ý tưởng thay vì phải xây dựng và chuyển giao hệ thống một lần thì sẽ được chia thành nhiều vòng, tăng dần. Mỗi vòng là một phần kết quả của một chức năng được yêu cầu. ü Các yêu cầu của người sử dụng được đánh thứ tự ưu tiên. Yêu cầu nào có thứ tự ưu tiên càng cao thì càng ở trong những vòng phát triển sớm hơn. 5/23/2021 53
Một số mô hình (tt10) · Mô hình phát triển lặp lại, tăng thêm (tt1): ü Từ đó, chúng ta có thể thấy rõ một số ưu điểm của mô hình phát triển tăng vòng: - Sau mỗi lần tăng vòng thì có thể chuyển giao kết quả thực hiện được cho khách hành nên các chức năng của hệ thống có thể nhìn thấy sớm hơn. - Các vòng trước đóng vai trò là mẫu thử để giúp tìm hiểu thêm các yêu cầu ở những vòng tiếp theo. - Những chức năng của hệ thống có thứ tự ưu tiên càng cao thì sẽ được kiểm thử càng kỹ. 5/23/2021 54
Một số mô hình (tt11) · Mô hình phát triển lặp lại, tăng thêm (tt2): 5/23/2021 55
Một số mô hình (tt12) · Mô hình xoắn ốc: ü Trong mô hình xoắn ốc, quy trình phát triển phần mềm được biểu diễn như một vòng xoắn ốc. Các pha trong quy trình phát triển xoắn ốc bao gồm: - Thiết lập mục tiêu: xác định mục tiêu cho từng pha của dự án. - Đánh giá và giảm thiểu rủi ro: rủi ro được đánh giá và thực hiện các hành động để giảm thiểu rủi ro. - Phát triển và đánh giá: sau khi đánh giá rủi ro, một mô hình xây dựng hệ thống sẽ được lựa chọn từ những mô hình chung. - Lập kế hoạch: đánh giá dự án và pha tiếp theo của mô hình xoắn ốc sẽ được lập kế hoạch. 5/23/2021 56
Một số mô hình (tt13) · Mô hình xoắn ốc (tt1): 5/23/2021 57
Các hoạt động trong quy trình PM · Giới thiệu: ü Trong quy trình phần mềm gồm 4 hoạt động cơ bản. Những hoạt động này bao gồm: - Đặc tả: các chức năng của hệ thống và những ràng buộc khi vận hành hệ thống cần phải được xác định một cách đầy đủ và chi tiết. - Thiết kế và cài đặt: phần mềm được xây dựng phải thoả mãn đặc tả của nó. - Đánh giá: phần mềm phải được đánh giá và thẩm định để đảm bảo rằng nó đã thoả mãn tất cả các yêu cầu. - Cải tiến: phần mềm cần phải cải tiến và điều chỉnh để phù hợp với những thay đổi về yêu cầu hệ thống. ü Với mỗi mô hình khác nhau thì các hoạt động này cũng được tổ chức theo các cách khác nhau. Ví dụ, trong mô hình thác nước, chúng được tổ chức một cách tuần tự. Trong mô hình tiến triển, các hoạt động này có thể gối lên nhau. Trong các phần tiếp sau đây, chúng ta sẽ nghiên cứu cụ thể từng hoạt động. 5/23/2021 58
Các hoạt động (tt1) · Mục tiêu: ü Xác định rõ những công việc nào cần phải làm trong quy trình phát triển phần mềm. ü Từng công việc đó được thực hiện cụ thể ra sao ü Phải nhớ một điều rằng: khi xây dựng bất kỳ phần mềm nào, chúng ta đều phải thực hiện bốn công việc trên. Tuy nhiên, với việc sử dụng các mô hình phát triển phần mềm khác nhau thì trình tự thực hiện các công việc trên cũng khác nhau. 5/23/2021 59
Các hoạt động (tt2) · Đặc tả phần mềm ü Đặc tả phần mềm (hay còn gọi là kỹ thuật xác định yêu cầu) là quy trình tìm hiểu và định nghĩa những dịch vụ nào được yêu cầu và các ràng buộc trong quá trình vận hành và xây dựng hệ thống. 5/23/2021 60
Các hoạt động (tt3) · Đặc tả phần mềm (tt1) ü Quy trình xác định yêu cầu bao gồm bốn pha chính: - Nghiên cứu khả thi: Nghiên cứu khả thi giúp xác định những yêu cầu của người sử dụng có thoả mãn những công nghệ hiện tại hay không. Về góc độ kinh doanh, nghiên cứu khả thi nhằm xác định hệ thống đưa ra có mang lại lợi nhuận không. Việc nghiên cứu khả thi nên được thực hiện một cách nhanh chóng và không quá tốn kém. Kết quả của việc nghiên cứu khả thi sẽ xác định có nên tiếp tục xây dựng hệ thống nữa hay không. - Phân tích và rút ra các yêu cầu: đây là quy trình đưa ra các yêu cầu hệ thống thông qua một số phương pháp như: quan sát hệ thống hiện tại, phỏng vấn và thảo luận với người sử dụng, phân tích nhiệm vụ, phân tích tài liệu hoặc hệ thống cũ Trong pha này, chúng ta có thể phải xây dựng một hoặc nhiều mô hình hệ thống và các mẫu thử. 5/23/2021 61
Các hoạt động (tt4) · Đặc tả phần mềm (tt3) ü Quy trình xác định yêu cầu bao gồm bốn pha chính: - Đặc tả yêu cầu: Pha này sẽ tư liệu hoá những thông tin thu thập được. Có hai loại yêu cầu cần được xác định: * Yêu cầu của người sử dụng: là những yêu cầu bằng ngôn ngữ tự nhiên bổ sung thêm cho các biểu đồ của các dịch vụ mà hệ thống cung cấp và các ràng buộc vận hành của nó. Kiểu yêu cầu này được viết bởi người sử dụng. * Yêu cầu hệ thống: là những tài liệu có cấu trúc mô tả chi tiết về các chức năng, dịch vụ và các ràng buộc vận hành của hệ thống. Yêu cầu hệ thống sẽ định nghĩa những gì cần phải xây dựng, cho nên nó có thể trở thành bản hợp đồng giữa khách hàng và nhà thầu. - Đánh giá yêu cầu: pha này sẽ kiểm tra lại các yêu cầu xem chúng có đúng thực tế hay không, có thống nhất không, có đầy đủ không. Nếu phát hiện ra lỗi thì ta phải chỉnh sửa các lỗi này. 5/23/2021 62
Các hoạt động (tt5) · Đặc tả phần mềm (tt4) 5/23/2021 63
Các hoạt động (tt6) · Thiết kế phần mềm và cài đặt ü Thiết kế phần mềm là quá trình thiết kế cấu trúc phần mềm dựa trên những tài liệu đặc tả. Hoạt động thiết kế bao gồm những công việc chính sau: - Thiết kế kiến trúc: Các hệ thống con cấu thành lên hệ thống cần xây dựng và mối quan hệ giữa chúng được xác định và tư liệu hoá. - Đặc tả trừu tượng: với mỗi hệ thống con, phải có một bản đặc tả về các dịch vụ của nó và những ràng buộc khi nó vận hành. - Thiết kế giao diện: với mỗi hệ thống con, các giao diện của nó với những hệ thống con khác phải được thiết kế và tư liệu hoá. - Thiết kế thành phần: các dịch vụ cung cấp cho các thành phần khác và các giao diện tương tác với chúng phải được thiết kế. - Thiết kế cấu trúc dữ liệu: cấu trúc dữ liệu được sử dụng để cài đặt hệ thống phải được thiết kế một cách chi tiết và cụ thể. - Thiết kế thuật toán: Các thuật toán được sử dụng để cung cấp các dịch vụ phải được thiết kế chi tiết và chính xác. 5/23/2021 64
Các hoạt động (tt7) · Thiết kế phần mềm và cài đặt (tt1) 5/23/2021 65
Các hoạt động (tt8) · Thiết kế phần mềm và cài đặt (tt2) ü Cài đặt là quy trình chuyển đổi từ tài liệu đặc tả hệ thống thành một hệ thống thực, có thể vận hành được và phải loại bỏ các lỗi của chương trình. ü Lập trình là một hành động cá nhân, không có quy trình lập trình chung. Người lập trình phải thực hiện một số kiểm thử để phát hiện ra lỗi trong chương trình và loại bỏ nó trong quy trình gỡ lỗi. 5/23/2021 66
Các hoạt động (tt9) · Đánh giá phần mềm ü Đánh giá phần mềm hay còn gọi là thẩm tra và đánh giá (V&V Verification and validation) được sử dụng để chỉ ra rằng hệ thống đã thực hiện theo đúng các đặc tả và thoả mãn mọi yêu cầu của khách hàng. ü Đánh giá phần mềm bao gồm các công đoạn: kiểm tra, xem xét lại, và kiểm thử hệ thống. Kiểm thử hệ thống tức là cho hệ thống thực hiện trên những trường hợp có dữ liệu thật được lấy từ tài liệu đặc tả hệ thống. Quy trình kiểm thử gồm các pha sau: - Kiểm thử thành phần (đơn vị): các thành phần được kiểm thử một cách độc lập, thành phần có thể là một chức năng hoặc một đối tượng hoặc một nhóm các thực thể gắn kết với nhau. - Kiểm thử hệ thống: kiểm thử toàn bộ hệ thống. - Kiểm thử chấp thuận: kiểm thử trên dữ liệu của khách hàng để kiểm tra hệ thống có đáp ứng tất cả các yêu cầu của khách hàng hay không. 5/23/2021 67
Các hoạt động (tt10) · Đánh giá phần mềm (tt1) ü Khi chuyển giao hệ thống cho khách hàng thì quy trình kiểm thử beta sẽ được thực hiện. Khách hàng sẽ thông báo các lỗi cho đội dự án. Những lỗi này sẽ được chỉnh sửa và tiếp tục kiểm thử beta hoặc chuyển giao thực sự cho khách hàng. 5/23/2021 68
Các hoạt động (tt10) · Cải tiến phần mềm ü Khi các yêu cầu hệ thống thay đổi theo sự thay đổi của các yêu cầu nghiệp vụ thì phần mềm phải cải tiến và thay đổi để hỗ trợ khách hàng. Thông thường chi phí để bảo trì và cải tiến thường đắt hơn nhiều so với chi phí xây dựng phần mềm. 5/23/2021 69
Bài tập Chương 2 · Câu 1: ü Giải thích tại sao các hệ thống được xây dựng dựa trên mô hình phát triển tiến triển thường khó bảo trì? · Câu 2: ü Cho biết cách phối hợp mô hình thác nước, mô hình mẫu thử và mô hình xoắn ốc. · Câu 3: ü Phân biệt sự khác nhau giữa yêu cầu hệ thống và yêu cầu của người sử dụng. · Câu 4: ü Tài liệu nào sau đây sẽ được tạo ra trong pha thiết kế hệ thống? - Mã lệnh - Thiết kế chi tiết - Lập kế hoạch - Kế hoạch kiểm thử 5/23/2021 70
Bài tập Chương 2 (tt1) · Câu 5: ü Sắp xếp thứ tự của những nhiệm vụ sau: - 1. Lập kế hoạch, ước lượng chi phí, xác định yêu cầu. - 2. Thiết kế ở mức cao - 3. Thiết kế ở mức thấp - 4. Cài đặt - 5. Kiểm thử đơn vị - 6. Kiểm thử hệ thống - 7. Kiểm thử chấp thuận - 8. Đánh giá yêu cầu · Câu 6: ü Chọn 5 hoạt động chính, tổng quát trong quá trình xây dựng phần mềm. - Phân tích, Thiết kế, Lập trình, Gỡ lỗi,, Bảo trì - Giao tiếp, Quản lý rủi ro, Ước lượng, Sản xuất, Kiểm tra lại - Giao tiếp, Lập kế hoạch, Mô hình hoá, Xây dựng, Triển khai - Phân tích, Lập kế hoạch, Thiết kế, Lập trình, Kiểm thử 5/23/2021 71
Bài tập Chương 2 (tt2) · Câu 7: ü Mô hình phát triển phần mềm dựa trên mẫu thử là - Một phương pháp thích hợp được sử dụng khi các yêu cầu đã được xác định rõ ràng - Phương pháp tốt nhất được sử dụng trong các dự án có nhiều thành viên - Một mô hình rất rủi ro, rất khó có thể đưa ra một sản phẩm tốt - Một phương pháp hữu ích khi khách hàng không thể định nghĩa các yêu cầu một cách rõ ràng · Câu 8: ü Mô hình xoắn ốc trong quá trình phát triển phần mềm. - Kết thúc với một sản phẩm được chuyển giao - Phức tạp và lộn xộn hơn mô hình lặp lại, tăng thêm - Phải đánh giá rủi ro của dự án trong từng bước lặp xoắn ốc - Tất cả các khẳng định trên 5/23/2021 72
Bài tập Chương 2 (tt3) · Câu 9: ü Mô hình tăng vòng trong quá trình phát triển phần mềm - Là một phương pháp thích hợp khi các yêu cầu đã được xác định rõ ràng - Là phương pháp tốt nhất được sử dụng khi dự án có quá nhiều thành viên tham dự - Là một mô hình mang tính cách mạng, nhưng không được sử dụng với các sản phẩm thương mại - Là một phương pháp tôt để tạo ra phần cốt lõi của sản phẩm một cách nhanh chóng 5/23/2021 73
Chương 3 Yêu cầu hệ thống
Yêu cầu hệ thống · Các yêu cầu của hệ thống phần mềm thường được chia thành ba loại: ü yêu cầu chức năng ü yêu cầu phi chức năng ü yêu cầu miền ứng dụng. · Tuy nhiên, trong thực tế chúng ta rất khó phân biết ba loại yêu cầu này một cách rõ ràng. · Trong chương này, chúng ta sẽ sử dụng một ví dụ về hệ thống thư viện để xác định các loại yêu cầu. ü Hệ thống thư viện (LIBSYS) cung cấp một giao diện đơn giản để lưu CSDL về các bài báo trên các thư viện khác nhau. Người sử dụng có thể tìm kiếm, download và in những tài liệu này. 5/23/2021 75
Yêu cầu (tt1) · Yêu cầu chức năng ü Yêu cầu chức năng mô tả hệ thống sẽ làm gì. Nó mô tả các chức năng hoặc các dịch vụ của hệ thống một cách chi tiết. ü Đặc điểm của yêu cầu chức năng: - Tính mập mờ, không rõ ràng của các yêu cầu: * Vấn đề này xảy ra khi các yêu cầu không được xác định một cách cẩn thận. Các yêu cầu mập mờ có thể được người xây dựng và người sử dụng hiểu theo nhiều cách khác nhau. - Tính hoàn thiện và nhất quán: * Về nguyên tắc, yêu cầu phải chứa tất cả các mô tả chi tiết và không có sự xung đột hoặc đối ngược giữa các yêu cầu. Tuy nhiên, trong thực tế rất khó có thể đạt được điều này. 5/23/2021 76
Yêu cầu (tt2) · Yêu cầu chức năng (tt1) ü Xác định các yêu cầu chức năng của LYBSYS - Người sử dụng có thể tìm kiếm tất cả CSDL hoặc một tập con của CSDL. - Hệ thống sẽ cung cấp những giao diện thích hợp để người sử dụng đọc tài liệu. - Tất cả những hoá đơn mà người sử dụng đăng ký để in sao tài liệu có một mã duy nhất. 5/23/2021 77
Yêu cầu (tt3) · Yêu cầu phi chức năng ü Yêu cầu phi chức năng không đề cập trực tiếp tới các chức năng cụ thể của hệ thống. - Yêu cầu phi chức năng thường định nghĩa các thuộc tính như: độ tin cậy, thời gian đáp ứng, các yêu cầu về lưu trữ và các ràng buộc của hệ thống như: khả năng của thiết bị vào/ra, giao diện ü Một số yêu cầu phi chức năng còn có liên quan đến quy trình xây dựng hệ thống. - Ví dụ: các chuẩn được sử dụng, các công cụ CASE, ngôn ngữ lập trình ü Các yêu cầu phi chức năng có thể là hạn chế hơn những yêu cầu chức năng. - Nhưng nếu nó không được thoả mãn thì hệ thống sẽ không sử dụng được. 5/23/2021 78
Yêu cầu (tt4) · Yêu cầu phi chức năng (tt1) ü Các yêu cầu phi chức năng xuất hiện là do yêu cầu của người sử dụng, ràng buộc về ngân sách, các chính sách của tổ chức sử dụng hệ thống, yêu cầu tương thích giữa phần cứng và phần mềm và các tác nhân ngoài khác. ü Phân loại các yêu cầu phi chức năng như sau: - Các yêu cầu về sản phẩm xác định ứng xử của sản phẩm như: hiệu năng, khả năng sử dụng, độ tin cậy của sản phẩm - Các yêu cầu về tổ chức: các yêu cầu này được lấy từ những chính sách và quy tắc của khách hàng hoặc tổ chức sử dụng hệ thống. - Các yêu cầu ngoài: được xác định từ các tác nhân ngoài của hệ thống. 5/23/2021 79
Yêu cầu (tt5) · Yêu cầu phi chức năng (tt2) 5/23/2021 80
Yêu cầu (tt6) · Yêu cầu phi chức năng (tt3) ü Xác định các yêu cầu phi chức năng của LIBSYS - Yêu cầu về sản phẩm: LIBSYS phải được cài đặt bằng HTML mà không có frame hoặc Java applets. - Yêu cầu về mặt tổ chức: Quy trình xây dựng hệ thống và các tài liệu chuyển giao phải thoả mãn các quy tắc đã được định nghĩa trong XYZCo-SP-STAN-95. - Yêu cầu ngoài: Hệ thống không được để lộ các thông tin cá nhân của khách hàng. 5/23/2021 81
Yêu cầu (tt7) · Yêu cầu phi chức năng (tt4) ü Nói chung, chúng ta rất khó xác định chính xác và rất khó thẩm tra những yêu cầu phi chức năng mập mờ. Do đó, trong tài liệu đặc tả yêu cầu, người ta thường bổ sung các mục tiêu. Mục tiêu rất hữu ích đối với người phát triển hệ thống khi nó truyền tải được những mong muốn của người sử dụng hệ thống. Còn với những yêu cầu phi chức năng có thể thẩm định được là những yêu cầu có thể kiểm thử một cách khách quan. ü Tuy nhiên, trong nhiều trường hợp thường xảy ra xung đột giữa các yêu cầu phi chức năng đối với những hệ thống phức tạp. 5/23/2021 82
Yêu cầu (tt8) · Yêu cầu phi chức năng (tt5) ü Các mục tiêu và yêu cầu phi chức năng có thể thẩm định được của LIBSYS - Mục tiêu của hệ thống là dễ sử dụng đối với những người sử dụng có kinh nghiệm và được tổ chức để sao cho tối thiểu hoá được lỗi. - Các yêu cầu phi chức năng có thể thẩm định được: Những người sử dụng có kinh nghiệm có thể sử dụng được tất cả các chức năng của hệ thống chỉ sau hai tiếng tập huấn. Sau khoá huấn luyện này, số lỗi chương trình gây ra bởi người sử dụng là không quá hai lỗi một ngày. 5/23/2021 83
Yêu cầu (tt9) · Yêu cầu miền ứng dụng ü Yêu cầu miền ứng dụng được xác định từ miền ứng dụng của hệ thống và phản ánh các thuộc tính và ràng buộc của miền ứng dụng. - Có thể là yêu cầu chức năng hoặc phi chức năng. ü Nếu yêu cầu miền ứng dụng không được thoả mãn thì có thể hệ thống sẽ không làm việc được. 5/23/2021 84
Yêu cầu (tt10) · Yêu cầu miền ứng dụng (tt1) ü Một số vấn đề liên quan đến yêu cầu miền ứng dụng: - Khả năng có thể hiểu được: các yêu cầu được biểu diễn dưới ngôn ngữ của lĩnh vực ứng dụng. - Ẩn ý: Các chuyên gia có hiểu biết về lĩnh vực của họ nhưng họ không biết cách xây dựng những yêu cầu miền ứng dụng một cách rõ ràng, mang tính kỹ thuật. 5/23/2021 85
Yêu cầu (tt11) · Yêu cầu miền ứng dụng (tt2) ü Yêu cầu về miền ứng dụng của LIBSYS - Giao diện người dùng chuẩn cho tất cả các CSDL đều dựa trên chuẩn Z39.50. - Vì vấn đề bản quyền nên một số tài liệu phải xoá ngay khi vừa chuyển đến. - Phụ thuộc vào yêu cầu của người sử dụng, những tài liệu đó có thể được in ngay trên server và chuyển đến cho người sử dụng hoặc gửi đến cho máy in mạng. 5/23/2021 86
Yêu cầu (tt12) · Một số kỹ thuật đặc tả yêu cầu hệ thống ü Nói chung, ngôn ngữ tự nhiên thường được sử dụng để viết đặc tả yêu cầu hệ thống cũng như yêu cầu của người sử dụng. Tuy nhiên, yêu cầu hệ thống thường chi tiết hơn yêu cầu của người sử dụng nên đặc tả bằng ngôn ngữ tự nhiên thường gặp một số vấn đề sau: - Không rõ ràng: * Người đọc và người viết yêu cầu phải giải thích các từ theo cùng một nghĩa. Ngôn ngữ tự nhiên có bản chất là mập mờ nên để đạt được yêu cầu trên là rất khó khăn. - Quá mềm dẻo: * với cùng một vấn đề nhưng có nhiều cách khác nhau để đặc tả. - Thiếu khả năng mô-đun hoá: * cấu trúc của ngôn ngữ tự nhiên không tương xứng với cấu trúc của các yêu cầu hệ thống. ü Vì những lý do này mà đặc tả bằng ngôn ngữ tự nhiên thường gây khó hiểu. Do đó, có thể sử dụng một số phương pháp được trình bày trong các phần sau để đặc tả yêu cầu. 5/23/2021 87
Yêu cầu (tt13) · Một số kỹ thuật đặc tả yêu cầu hệ thống (tt1) ü Đặc tả bằng ngôn ngữ hướng cấu trúc - Sử dụng ngôn ngữ hướng cấu trúc sẽ yêu cầu người viết đặc tả tuân theo những mẫu được định nghĩa trước. Tất cả các yêu cầu đều được viết theo chuẩn và các thuật ngữ được sử dụng có thể bị hạn chế. - Ưu điểm của phương pháp này là đạt được mức độ diễn tả cao nhất của ngôn ngữ tự nhiên nhưng mức độ đồng nhất lại bị lạm dụng trong các đặc tả. 5/23/2021 88
Yêu cầu (tt14) · Một số kỹ thuật đặc tả yêu cầu hệ thống (tt2) ü Đặc tả dựa biểu mẫu (Form-based) - Đặc tả dựa biểu mẫu định nghĩa các chức năng hoặc thực thể, mô tả đầu vào và nơi xuất phát của nó, mô tả đầu ra và nơi nó sẽ đến. Đặc tả dựa biểu mẫu chỉ rõ những thực thể cần thiết, các điều kiện trước và sau (nếu thích hợp), các ảnh hưởng của chức năng. ü Biểu đồ trình tự - Biểu đồ trình tự biểu diễn trình tự các sự kiện xảy ra khi người sử dụng tương tác với hệ thống. Nếu ta đọc biểu đồ này từ đầu đến cuối thì ta sẽ thấy được thứ tự của các hành động được thực hiện. 5/23/2021 89
Yêu cầu của người sử dụng · Yêu cầu của người sử dụng nên mô tả những yêu cầu chức năng và phi chức năng để người sử dụng có thể hiểu được chúng mà không cần phải có những kiến thức về công nghệ một cách chi tiết. · Yêu cầu của người sử dụng được định nghĩa bằng cách sử dụng ngôn ngữ tự nhiên, bảng hoặc biểu đồ đơn giản. Tuy nhiên, chúng ta sẽ gặp phải một số khó khăn khi sử dụng ngôn ngữ tự nhiên: ü Không rõ ràng: Tính chính xác rất khó đạt được nếu tài liệu khó đọc. ü Yêu cầu lộn xộn: các yêu cầu chức năng và phi chức năng không rõ ràng. ü Lẫn lộn giữa các yêu cầu: các yêu cầu khác nhau có thể được diễn tả cùng với nhau. 5/23/2021 90
Yêu cầu của người sử dụng (tt1) · Do đó, để viết yêu cầu của người sử dụng ta nên áp dụng một số quy tắc sau: ü Đưa ra một định dạng chuẩn và áp dụng nó cho tất cả các yêu cầu. ü Bắt buộc sử dụng ngôn ngữ một cách thống nhất ü Đánh dấu những phần quan trọng trong các yêu cầu. ü Tránh sử dụng những từ ngữ mang tính chuyên môn, kỹ thuật. 5/23/2021 91
Tài liệu đặc tả yêu cầu · Tài liệu đặc tả yêu cầu là những yêu cầu chính thức về những gì cần phải thực hiện bởi đội phát triển hệ thống. · Tài liệu đặc tả yêu cầu nên bao gồm cả các định nghĩa về yêu cầu của người sử dụng và đặc tả yêu cầu hệ thống. · Tài liệu đặc tả yêu cầu không phải là tài liệu thiết kế hệ thống. Nó chỉ thiết lập những gì hệ thống phải làm, chứ không phải mô tả rõ làm như thế nào. 5/23/2021 92
Tài liệu đặc tả yêu cầu (tt1) · Tài liệu đặc tả yêu cầu dựa theo chuẩn IEEE ü 1. Giới thiệu - 1.1. Mục đích của tài liệu yêu cầu - 1.2. Phạm vi của sản phẩm - 1.3. Các định nghĩa, từ viết tắt - 1.4. Các tham chiếu - 1.5. Tổng quan về tài liệu yêu cầu ü 2. Mô tả chung - 2.1. Giới thiệu chung về sản phẩm - 2.2. Các chức năng của sản phẩm - 2.3. Đặc điểm của người sử dụng - 2.4. Các ràng buộc - 2.5. Giả thiết và các phụ thuộc ü 3. Đặc tả yêu cầu: bao gồm các yêu cầu chức năng, phi chức năng, miền ứng dụng và giao diện. ü 4. Phụ lục ü 5. Chỉ mục 5/23/2021 93
Bài tập Chương 3 · Câu 1: ü Xác định yêu cầu hệ thống giúp trả lời những câu hỏi nào? · Câu 2: ü Đánh giá việc sử dụng ngôn ngữ tự nhiên để định nghĩa các yêu cầu hệ thống và yêu cầu của người sử dụng. 5/23/2021 94
Bài tập Chương 3 (tt1) · Câu 3: Mô tả hệ thống bán vé tàu tự động như sau: ü Người sử dụng chọn đích đến và đưa thẻ thanh toán vào máy, rồi nhập số PIN. Vé được in ra và tài khoản của người sử dụng bị thay đổi. - 1. Phát hiện những nhập nhằng trong đoạn tài liệu đặc tả yêu cầu trên và sửa chúng.Khi người sử dụng nhấn nút Start, menu sẽ hiển thị những đích đến có thể, và người sử dụng chọn một đích đến trong số đó. Khi đích đến đã được lựa chọn, hệ thống yêu cầu người sử dụng đưa thẻ thanh toán vào máy. Thẻ sẽ được kiểm tra và người sử dụng phải nhập số PIN. Khi giao dịch liên quan đến thẻ thanh toán kết thúc hợp lệ thì vé sẽ được in ra. - 2. Bổ sung thêm các yêu cầu phi chức năng của hệ thống trên * Giao diện thân thiện, dễ sử dụng * Tốc độ xử lý nhanh (đặc biệt ở các tiến trình kiểm tra thẻ, in vé ) * Thông báo lỗi thích hợp và có chỉ dẫn sai sót - 3. Vẽ biểu đồ trình tự mô tả các hành động của hệ thống trên 5/23/2021 95
Chương 4 Quy trình xác định yêu cầu
Giới thiệu · Mục tiêu của quy trình xác định yêu cầu là đưa ra các tài liệu yêu cầu của hệ thống. Quy trình xác định yêu cầu biến đổi phụ thuộc vào miền ứng dụng, con người và tổ chức xây dựng yêu cầu. · Tuy nhiên, những quy trình này vẫn có chung một số hoạt động sau: phát hiện yêu cầu, phân tích yêu cầu, đánh giá yêu cầu và quản lý yêu cầu. · Trong thực tế, các yêu cầu luôn luôn thay đổi, thậm chí ngay cả khi đang xây dựng hệ thống. Vì vậy, người ta thường sử dụng mô hình xoắn ốc để xác định các yêu cầu. Mô hình này cho phép việc xác định yêu cầu và cài đặt hệ thống được thực hiện cùng lúc. 5/23/2021 97
Giới thiệu (tt1) 5/23/2021 98
Giới thiệu (tt2) 5/23/2021 99
Phân tích khả thi · Đối với tất cả các hệ thống mới, quy trình xác định yêu cầu thường bắt đầu bằng việc phân tích khả thi. Thông tin đầu vào để phân tích khả thi là các yêu cầu nghiệp vụ, mô tả sơ bộ về hệ thống, cách thức hệ thống hỗ trợ các yêu cầu nghiệp vụ. Kết quả của việc phân tích khả thi là một báo cáo để quyết định có nên xây dựng hệ thống đề xuất hay không. · Phân tích khả thi thường tập trung vào: ü Xác định hệ thống có đóng góp vào mục tiêu của tổ chức hay không ü Kiểm tra xem hệ thống có thể được xây dựng bằng cách sử dụng công nghệ hiện tại và ngân sách cho phép. ü Kiểm tra xem liệu hệ thống có được tích hợp với các hệ thống khác đang sử dụng hay không. 5/23/2021 100
Phân tích khả thi (tt1) · Thực hiện phân tích khả thi dựa trên việc đánh giá thông tin, lựa chọn thông tin và viết báo cáo. · Những câu hỏi thường được đặt ra để phân tích khả thi: ü Nếu hệ thống không được cài đặt thì sao? ü Vấn đề xử lý hiện tại như thế nào? ü Hệ thống đề xuất giúp đỡ được gì? ü Vấn đề về tích hợp là gì? ü Công nghệ mới cần dùng là gì? Cần có những kỹ năng gì? ü Những lợi ích mà hệ thống mang lại? 5/23/2021 101
Phát hiện và phân tích yêu cầu · Trong pha phát hiện và phân tích yêu cầu, nhân viên kỹ thuật và khách hàng cùng hợp tác để xác định miền ứng dụng, các dịch vụ mà hệ thống cung cấp, hiệu năng của hệ thống, các ràng buộc vận hành của hệ thống · Ở đây, chúng ta có một khái niệm mới là stakeholder. Stakeholder là những người tham dự vào dự án xây dựng hệ thống: người sử dụng cuối, người quản lý, kỹ sư, chuyên gia lĩnh vực, ü Ví dụ, trong hệ thống ATM gồm các Stakeholder sau: khách hàng của ngân hàng, đại diện của các ngân hàng khác, người quản lý ngân hầng, nhân viên ngân hàng, quản trị CSDL, quản lý bảo mật, phòng marketing, kỹ sư bảo trì phần cứng và phần mềm, người điều hành ngân hàng. 5/23/2021 102
Phát hiện và phân tích (tt1) · Tuy nhiên, việc phát hiện và tìm hiểu yêu cầu của stakeholder, chúng ta thường gặp khó khăn vì những nguyên nhân sau: ü Stakeholder không biết những gì mà họ thật sự mong muốn. ü Stakeholder mô tả các yêu cầu theo thuật ngữ của họ. ü Những stakeholder khác nhau có thể có các yêu cầu xung đột nhau ü Những yếu tố tổ chức và quyền lực có thể ảnh hưởng tới các yêu cầu hệ thống. ü Các yêu cầu có thể thay đổi trong suốt quá trình phân tích. Những stakeholder mới có thể xuất hiện và môi trường nghiệp vụ có thể thay đổi. · Do đó, người ta thường sử dụng mô hình xoắn ốc trong quy trình phát hiện và phân tích yêu cầu. 5/23/2021 103
Phát hiện và phân tích (tt2) 5/23/2021 104
Phát hiện và phân tích (tt3) · Trong quy trình này bao gồm các hoạt động sau: ü Phát hiện yêu cầu: tiếp xúc với các stakeholder để phát hiện ra các yêu cầu của họ. Các yêu cầu miền ứng dụng cũng được phát hiện ở bước này. ü Phân loại và sắp xếp yêu cầu: nhóm các yêu cầu có liên quan lẫn nhau và tổ chức chúng thành những nhóm gắn kết với nhau. ü Sắp thứ tự ưu tiên và điều chỉnh các yêu cầu xung đột: khi có nhiều stakeholder thì các yêu cầu của họ càng có nhiều xung đột. Hoạt động này nhằm đánh thứ tự ưu tiên của các yêu cầu, phát hiện và giải quyết xung đột giữa các yêu cầu. ü Tư liệu hóa yêu cầu: yêu cầu được tư liệu hoá và là đầu vào của vòng kế tiếp trong mô hình xoắn ốc. 5/23/2021 105
Phát hiện và phân tích (tt4) · Phát hiện yêu cầu là quy trình thu thập những thông tin về hệ thống được đề xuất và hệ thống đang tồn tại để xác định các yêu cầu hệ thống và yêu cầu của người sử dụng. Ta có thể lấy thông tin này từ các tư liệu, stakeholder, và bản đặc tả của những hệ thống tương tự. Chúng ta giao tiếp với stakeholder thông qua phỏng vấn hoặc quan sát và có thể sử dụng kịch bản và mẫu thử để giúp phát hiện yêu cầu. 5/23/2021 106
Phát hiện và phân tích (tt5) · Khung nhìn (Viewpoint) ü Khung nhìn là cách xây dựng yêu cầu để trình bày với từng stakeholder khác nhau. Ta có thể phân loại Stakeholder theo nhiều khung nhìn khác nhau. ü Phân tích dựa trên khung nhìn cho phép phát hiện nhiều khía cạnh khác nhau của một vấn đề và giúp phát hiện ra sự xung đột giữa các yêu cầu. 5/23/2021 107
Phát hiện và phân tích (tt6) · Khung nhìn (Viewpoint) (tt1) ü Khung nhìn được chia thành 3 loại chính và mỗi loại sẽ cung cấp các yêu cầu khác nhau. - Khung nhìn tương tác: là những người hoặc hệ thống khác tương tác với hệ thống. Trong hệ thống ATM, khách hàng và CSDL tài khoản là những khung nhìn tương tác - Khung nhìn gián tiếp: là những stakeholder không sử dụng hệ thống trực tiếp nhưng có ảnh hưởng tới hệ thống. Trong hệ thống ATM, nhân viên quản lý và bảo mật là những khung nhìn gián tiếp. - Khung nhìn miền ứng dụng: là những đặc điểm và ràng buộc của miền ứng dụng, có ảnh hưởng tới các yêu cầu. Trong hệ thống ATM, các chuẩn để giao tiếp giữa nhiều ngân hàng là một ví dụ. 5/23/2021 108
Phát hiện và phân tích (tt7) · Khung nhìn (Viewpoint) (tt2) ü Khung nhìn phân cấp của LIBSYS: 5/23/2021 109
Phát hiện và phân tích (tt8) · Phỏng vấn ü Phỏng vấn hình thức hoặc phi hình thức là một trong những phần quan trọng nhất của quy trình xác định yêu cầu. Trong quá trình phỏng vấn, những người xác định yêu cầu sẽ đặt ra các câu hỏi cho stakeholder về hệ thống hiện tại họ đang sử dụng và hệ thống sẽ được xây dựng. Và các yêu cầu sẽ được lấy ra từ những câu trả lời của stakeholder. ü Phỏng vấn được chia thành hai loại: - Phỏng vấn đóng: tập các câu hỏi đã được định nghĩa trước và có nhiều đáp án để stakeholder lựa chọn trả lời. - Phỏng vấn mở: tất cả các vấn đề không được xác định trước và stakeholder phải tự giải thích và phát biểu theo quan điểm của mình. ü Trong thực tế, chúng ta thường trộn lẫn phỏng vấn đóng và mở. 5/23/2021 110
Phát hiện và phân tích (tt9) · Phỏng vấn (tt1) ü Phỏng vấn hình thức hoặc phi hình thức là một trong những phần quan trọng nhất của quy trình xác định yêu cầu. Trong quá trình phỏng vấn, những người xác định yêu cầu sẽ đặt ra các câu hỏi cho stakeholder về hệ thống hiện tại họ đang sử dụng và hệ thống sẽ được xây dựng. Và các yêu cầu sẽ được lấy ra từ những câu trả lời của stakeholder. ü Phỏng vấn được chia thành hai loại: - Phỏng vấn đóng: tập các câu hỏi đã được định nghĩa trước và có nhiều đáp án để stakeholder lựa chọn trả lời. - Phỏng vấn mở: tất cả các vấn đề không được xác định trước và stakeholder phải tự giải thích và phát biểu theo quan điểm của mình. ü Trong thực tế, chúng ta thường trộn lẫn phỏng vấn đóng và mở. 5/23/2021 111
Phát hiện và phân tích (tt10) · Kịch bản ü Chúng ta thường hiểu một vấn đề thông qua các ví dụ thực tế dễ dàng hơn là thông qua những mô tả trừu tượng về nó. ü Do đó, chúng ta có thể sử dụng kịch bản để phát hiện ra các yêu cầu hệ thống. Kịch bản là những ví dụ thực tế về cách sử dụng hệ thống. Chúng bao gồm: - Mô tả trạng thái khởi động - Mô tả luồng sự kiện thông thường - Mô tả những gì có thể đi tới lỗi - Thông tin về các hành động đồng thời khác - Mô tả trạng thái khi kịch bản hoàn thành 5/23/2021 112
Phát hiện và phân tích (tt11) · Ca sử dụng ü Ca sử dụng là kịch bản được xây dựng dựa trên kỹ thuật của UML để xác định các tác nhân trong một tương tác và mô tả chính tương tác đó. Một tập hợp các ca sử dụng sẽ mô tả tất cả các tương tác có thể trong hệ thống. ü Ngoài ra, chúng ta có thể sử dụng biểu đồ trình tự để bổ sung các thông tin chi tiết cho ca sử dụng bằng cách biểu diễn trình tự các sự kiện được xử lý trong hệ thống. 5/23/2021 113
Phát hiện và phân tích (tt12) · Ca sử dụng (tt1) ü Các ca sử dụng trong LIBSYS 5/23/2021 114
Đánh giá yêu cầu · Đánh giá yêu cầu có liên quan đến việc giải thích các yêu cầu đã được định nghĩa trong hệ thống. Vì chi phí cho việc giải quyết các lỗi có liên quan tới yêu cầu sẽ rất cao cho nên việc đánh giá yêu cầu là vô cùng quan trọng. · Trong quá trình đánh giá yêu cầu, chúng ta phải kiểm tra các yêu cầu ở những khía cạnh sau: ü Hợp lệ: Hệ thống có cung cấp các chức năng mà hỗ trợ tốt nhất cho các yêu cầu của người sử dụng hay không? ü Nhất quán: có yêu cầu nào xung đột nhau hay không? ü Hoàn thiện: tất cả các yêu cầu của khách hàng đã được xác định đầy đủ chưa? ü Hiện thực: các yêu cầu có thể được cài đặt với một ngân sách và công nghệ cho trước? ü Xác thực: các yêu cầu có thể được kiểm tra hay không? 5/23/2021 115
Đánh giá yêu cầu (tt1) · Các kỹ thuật đánh giá yêu cầu sau đây có thể được sử dụng đơn lẻ hoặc hỗn hợp: ü Xem xét lại các yêu cầu: phân tích các yêu cầu một cách hệ thống. ü Mẫu thử: Sử dụng các mô hình hệ thống để kiểm tra các yêu cầu ü Tạo ra các trường hợp kiểm thử 5/23/2021 116
Lập kế hoạch quản lý yêu cầu · Quản lý yêu cầu là quy trình quản lý sự thay đổi của các yêu cầu trong quá trình phát hiện yêu cầu và phát triển hệ thống. · Các yêu cầu thường không đầy đủ và không đồng nhất. Đó là do một số nguyên nhân sau: ü Những yêu cầu mới xuất hiện trong quy trình khi các yêu cầu nghiệp vụ thay đổi và khi chúng ta có hiểu biết sâu hơn về hệ thống sẽ xây dựng. ü Ở các khung nhìn khác nhau sẽ có các yêu cầu khác nhau và do đó thường xuất hiện các mâu thuẫn. ü Thứ tự ưu tiên từ các khung nhìn khác nhau cung thay đổi trong suốt quá trình phát triển hệ thống. ü Môi trường nghiệp vụ và môi trương kỹ thuật của hệ thống cũng thay đổi trong có trình xây dựng. 5/23/2021 117
Lập kế hoạch quản lý (tt1) · Các yêu cầu lâu dài là những yêu cầu ổn định kế thừa từ những hành động chính của khách hàng. Và nó có thể kế thừa từ nhiều mô hình miền ứng dụng khác. · Các yêu cầu thay đổi là những yêu cầu dễ bị thay đổi trong quá trình xây dựng hoặc khi hệ thống được đưa vào sử dụng. 5/23/2021 118
Lập kế hoạch quản lý (tt2) · Quy trình lập kế hoạch quản lý yêu cầu: ü Xác định yêu cầu: cách xác định từng yêu cầu ü Quản lý thay đổi: xác định các hoạt động tiếp theo khi yêu cầu thay đổi. ü Các chính sách tìm vết: lượng thông tin về mối quan hệ giữa các yêu cầu cần phải được lưu giữ. Thông thường, nó đề cập tới quan hệ giữa tài nguyên và bản thiết kế hệ thống. - Tìm vết nguồn: là những liên kết từ các yêu cầu tới stakeholder đưa ra những yêu cầu đó. - Tìm vết yêu cầu: là mối liên hệ giữa các yêu cầu độc lập nhau. - Tìm vết thiết kế: là những liên kết từ yêu cầu cho tới thiết kế. 5/23/2021 119
Lập kế hoạch quản lý (tt3) · Quy trình lập kế hoạch quản lý yêu cầu (tt1): ü Hỗ trợ CASE tool: sử dụng các công cụ để hỗ trợ quản lý yêu cầu thay đổi. CASE tool thường hỗ trợ những chức năng như: - Lưu trữ yêu cầu: các yêu cầu được quản lý một cách bảo mật và được lưu trong kho dữ liệu. - Quản lý thay đổi: quy trình quản lý thay đổi là quy trình luồng công việc mà các trạng thái có thể được định nghĩa và luồng thông tin giữa các trạng thái là tự động. - Quản lý vết tự động tìm kiếm mối liên kết giữa các yêu cầu. 5/23/2021 120
Lập kế hoạch quản lý (tt4) · Chúng ta nên áp dụng tất cả các khả năng thay đổi có thể cho tất cả các yêu cầu. Các pha chính của hoạt động này bao gồm: ü Phân tích vấn đề và đặc tả thay đổi: thảo luận về các vấn đề yêu cầu và những thay đổi có thể xảy ra. ü Phân tích thay đổi và chi phí: Đánh giá ảnh hưởng của sự thay đổi trên các yêu cầu khác. ü Cài đặt thay đổi: Điều chỉnh tài liệu của các yêu cầu và những tài liệu khác để phản ánh sự thay đổi đó. 5/23/2021 121
Bài tập · Câu 1: ü Xác định những stakeholder có thể có của hệ thống Quản lý sinh viên · Câu 2: ü Dựa trên hiểu biết của mình về hệ thống ATM, hãy xây dựng khung nhìn phân cấp của hệ thống đó. · Câu 3: ü Việc phân tích khả thi cho thấy xây dựng hệ thống sẽ gặp khó khăn và có thể không thực hiện được. Hãy đề xuất giải pháp khi gặp phải trình trạng này. · Câu 4: ü Hãy xây dựng một quy trình để quản lý yêu cầu một cách dễ dàng và hợp lý. 5/23/2021 122
Chương 5 Các mô hình hệ thống
Giới thiệu · Các yêu cầu của người sử dụng thường được viết bằng ngôn ngữ tự nhiên để những người không có kiến thức về mặt kỹ thuật có thể hiểu được nó. Tuy nhiên, những yêu cầu hệ thống chi tiết phải được mô hình hoá. Mô hình hoá hệ thống giúp cho người phân tích hiểu rõ các chức năng của hệ thống. · Ta có thể sử dụng các mô hình khác nhau để biểu diễn hệ thống từ nhiều khía cạnh khác nhau. 5/23/2021 124
Mô hình ngữ cảnh · Trong quá trình phát hiện và phân tích yêu cầu, chúng ta nên xác định phạm vi hệ thống, tức là phân biệt cái gì là hệ thống và cái gì là môi trường của hệ thống. Điều này sẽ giúp giảm chi phí và thời gian phân tích. · Khi đã xác định phạm vi của hệ thống, hoạt động tiếp theo của quy trình phân tích là định nghĩa ngữ cảnh của hệ thống và sự phụ thuộc giữa hệ thống với môi trường của nó. · Thông thường, mô hình kiến trúc đơn giản của hệ thống sẽ được tạo ra trong bước này. 5/23/2021 125
Mô hình ngữ cảnh (tt1) · Ví dụ: ü mô hình ngữ cảnh của hệ thống ATM 5/23/2021 126
Mô hình ngữ cảnh (tt2) · Mô hình kiến trúc mô tả môi trường của hệ thống, nhưng không chỉ ra quan hệ giữa các hệ thống khác nhau trong một môi trường. Vì vậy, người ta thường sử dụng thêm mô hình tiến trình hoặc mô hình luồng dữ liệu để bổ trợ cho nó. · Mô hình tiến trình biểu diễn tất cả các tiến trình được hệ thống hỗ trợ. Mô hình luồng dữ liệu có thể được sử dụng để biểu diễn các tiến trình và luồng thông tin đi từ tiến trình này tới tiến trình khác. 5/23/2021 127
Mô hình ứng xử · Mô hình ứng xử được sử dụng để mô tả toàn bộ ứng xử của hệ thống. Có hai kiểu mô hình ứng xử là: ü Mô hình luồng dữ liệu: biểu diễn cách xử lý dữ liệu trong hệ thống ü Mô hình máy trạng thái: biểu diễn cách đáp ứng của hệ thống với các sự kiện xảy ra. · Hai mô hình này biểu diễn những góc nhìn khác nhau, nhưng cả hai đều cần thiết để mô tả ứng xử của hệ thống. 5/23/2021 128
Mô hình ứng xử (tt1) · Mô hình luồng dữ liệu ü Mô hình luồng dữ liệu được sử dụng để mô hình hoá quy trình xử lý dữ liệu của hệ thống. Mô hình này sẽ biểu diễn các bước mà luồng dữ liệu phải trải qua trong hệ thống từ điểm đầu tới điểm cuối. ü Mô hình luồng dữ liệu mô hình hoá hệ thống từ góc độ một chức năng. Việc tìm vết và tư liệu hoá quan hệ giữa dữ liệu với một quy trình rất có ích đối với việc tìm hiểu toàn bộ hệ thống. ü Mô hình luồng dữ liệu là phần cốt lõi của rất nhiều phương pháp phân tích. Nó chứa các ký pháp rất dễ hiểu đối với khách hàng. 5/23/2021 129
Mô hình ứng xử (tt2) · Mô hình luồng dữ liệu (tt1) ü Ví dụ: Mô hình luồng dữ liệu của chức năng xử lý đơn hàng 5/23/2021 130
Mô hình ứng xử (tt3) · Mô hình máy trạng thái ü Mô hình máy trạng thái mô tả đáp ứng của hệ thống với các sự kiện bên trong và bên ngoài của nó. Mô hình máy trạng thái biểu diễn các trạng thái của hệ thống và các sự kiện gây ra sự dịch chuyển trạng thái. ü Mô hình máy trạng thái biểu diễn các trạng thái của hệ thống là các nút và sự kiện là các cung nối giữa các nút đó. Khi có một sự kiện xảy ra, hệ thống sẽ dịch chuyển từ trạng thái này sang trạng thái khác. ü Biểu đồ trạng thái là một biểu đồ trong UML và được sử dụng để biểu diễn mô hình máy trạng thái. Biểu đồ trạng thái cho phép phân tích một mô hình thành nhiều mô hình con và mô tả ngắn gọn về các hành động cần thực hiện tại mỗi trạng thái. Ta có thể vẽ các bảng để mô tả mối quan hệ giữa trạng thái và tác nhân kích hoạt. 5/23/2021 131
Mô hình dữ liệu · Giới thiệu: ü Mô hình dữ liệu được sử dụng để mô tả cấu trúc logic của dữ liệu được xử lý bởi hệ thống. ü Thông thường, chúng ta hay sử dụng mô hình thực thể quan hệ thuộc tính (ERA) thiết lập các thực thể của hệ thống, quan hệ giữa các thực thể và thuộc tính của các thực thể. Mô hình này được sử dụng trong thiết kế CSDL và thường được cài đặt trong các CSDL quan hệ. 5/23/2021 132
Mô hình dữ liệu (tt1) · Giới thiệu (tt1): ü Ví dụ mô hình dữ liệu của LIBSYS 5/23/2021 133
Mô hình dữ liệu (tt2) · Giới thiệu (tt2): ü Tuy nhiên, mô hình dữ liệu thường không chi tiết. Cho nên, chúng ta có thể sử dụng từ điển dữ liệu làm công cụ bổ trợ. Từ điển dữ liệu là danh sách tất cả các tên gọi được sử dụng trong các mô hình hệ thống. Đó có thể là các thực thể, quan hệ và các thuộc tính ü Ưu điểm của từ điển dữ liệu là: hỗ trợ quản lý tên và tránh trùng lặp tên, lưu trữ kiến thức một cách có tổ chức kết nối pha phân tích, thiết kế và cài đặt. 5/23/2021 134
Mô hình dữ liệu (tt3) · Giới thiệu (tt3): ü Ví dụ: từ điển dữ liệu của LIBSYS 5/23/2021 135
Mô hình đối tượng · Giới thiệu: ü Sử dụng mô hình ứng xử hay mô hình dữ liệu thường rất khó mô tả các vấn đề có liên quan đến thế giới thực. Mô hình đối tượng đã giải quyết được vấn đề này bằng cách kết hợp ứng xử và dữ liệu thành đối tượng. ü Mô hình đối tượng được sử dụng để biểu diễn cả dữ liệu và quy trình xử lý của hệ thống. Nó mô tả hệ thống dựa theo thuật ngữ các lớp đối tượng và các quan hệ của nó. Một lớp đối tượng là sự trừu tượng hoá trên một tập các đối tượng có thuộc tính và phương thức chung. ü Mô hình đối tượng phản ánh các thực thể trong thế giới thực được vận dụng trong hệ thống. Nếu ta càng có nhiều thực thể trừu tượng thì việc mô hình hoá càng khó khăn. 5/23/2021 136
Mô hình đối tượng (tt1) · Giới thiệu (tt1): ü Phát hiện các lớp đối tượng là một quy trình rất khó khăn khi tìm hiểu sâu về lĩnh vực của ứng dụng. Các lớp đối tượng thường phản ảnh các thực thể liên quan tới miền ứng dụng của hệ thống. ü Các mô hình đối tượng bao gồm: mô hình thừa kế, mô hình kết hợp và mô hình ứng xử. Trong phần tiếp theo, chúng ta sẽ tìm hiểu từng loại mô hình này. 5/23/2021 137
Mô hình đối tượng (tt2) · Mô hình thừa kế ü Mô hình thừa kế tổ chức các lớp đối tượng theo một cấu trúc phân cấp. Các lớp ở đỉnh của cấu trúc phân cấp phản ánh những đặc trưng chung của tất cả các lớp. Các lớp đối tượng thừa kế những thuộc tính và phương thức của các lớp cha của nó nó có thể bổ sung những đặc điểm của riêng nó. ü Thiết kế lớp phân cấp là một quy trình khá phức tạp, ta nên loại bỏ sự trùng lặp giữa các nhánh khác nhau. 5/23/2021 138
Mô hình đối tượng (tt3) · Mô hình thừa kế (tt1) ü Ví dụ: cấu trúc phân cấp của lớp Library trong LIBSYS 5/23/2021 139
Mô hình đối tượng (tt4) · Mô hình thừa kế (tt2) ü Ví dụ: cấu trúc phân cấp của lớp User trong LIBSYS 5/23/2021 140
Mô hình đối tượng (tt5) · Mô hình thừa kế (tt3) ü Cấu trúc đa thừa kế: lớp đối tượng có thể thừa kế từ một hoặc nhiều lớp cha. Tuy nhiên, điều này có thể dẫn tới sự xung đột về ngữ nghĩa khi các thuộc tính/phương thức trùng tên ở các lớp cha khác nhau có ngữ nghĩa khác nhau. 5/23/2021 141
Mô hình đối tượng (tt6) · Mô hình thừa kế (tt4) ü Ví dụ: lớp Talking book thừa kế từ hai lớp Book và Voice recording. 5/23/2021 142
Mô hình đối tượng (tt7) · Mô hình kết hợp ü Mô hình kết hợp biểu diễn cách cấu tạo của một lớp từ các lớp khác. Mô hình kết hợp tương tự như quan hệ hợp thành (part-of). ü Ví dụ: Mô hình kết hợp ü Đối tượng ô tô được tạo thành từ nhiều đối tượng khác như: cửa, bánh xe 5/23/2021 143
Mô hình đối tượng (tt8) · Mô hình ứng xử ü Mô hình ứng xử mô tả tương tác giữa các đối tượng nhằm tạo ra một số ứng xử cụ thể của hệ thống mà đã được xác định như là một ca sử dụng. ü Biểu đồ trình tự hoặc biểu đồ cộng tác trong UML được sử dụng để mô hình hoá tương tác giữa các đối tượng. ü Ví dụ: Mô tả ca sử dụng Rút tiền của hệ thống ATM. 5/23/2021 144
5/23/2021 145
Phương pháp hướng cấu trúc · Ngày nay, phương pháp hướng cấu trúc rất ít khi được sử dụng do không còn phù hợp với các hệ thống lớn. Tuy nhiên, trong giáo trình này, chúng tôi vẫn trình bày phần này để học viên có cái nhìn mang tính tổng quan về vấn đề này. · Các phương pháp hướng cấu trúc đều cung cấp framework để mô hình hoá hệ thống một cách chi tiết. Chúng thường có một tập hợp các mô hình đã được định nghĩa trước, quy trình để đưa ra các mô hình đó và các quy tắc, hướng dẫn có thể áp dụng cho các mô hình. 5/23/2021 146
Phương pháp (tt1) · Tuy nhiên, các phương pháp hướng cấu trúc thường có một số nhược điểm sau: ü Không mô hình hoá được các yêu cầu hệ thống phi chức năng ü Không chứa những thông tin để xác định liệu một phương thức có thích hợp với một vấn đề đưa ra hay không. ü Tạo ra quá nhiều tài liệu ü Mô hình hoá hệ thống quá chi tiết và khó hiểu đối với người sử dụng. 5/23/2021 147
Phương pháp (tt2) · CASE workbenches là tập hợp các công cụ được thiết kế để hỗ trợ các quy trình xây dựng hệ thống phần mềm như phân tích, thiết kế và kiểm thử. · CASE tools hỗ trợ mô hình hoá hệ thống là một công cụ quan trọng của phương pháp hướng cấu trúc. · Một số CASE tool thường được sử dụng: ü Soạn thảo biểu đồ ü Công cụ phân tích mô hình và kiểm tra ü Ngôn ngữ truy vấn ü Từ điển dữ liệu ü Công cụ tạo và định nghĩa báo cáo ü Công cụ định nghĩa form ü Bộ dịch ü Công cụ tạo mã lệnh tự động 5/23/2021 148
Bài tập · Câu 1: ü Chọn định nghĩa đúng về biểu đồ ngữ cảnh. - Được tạo ra để thiết lập phạm vi của hệ thống với môi trường bên ngoài - Mô tả cách tương tác giữa tác nhân ngoài và hệ thống - Được sử dụng để mô tả cấu trúc tĩnh của toàn bộ hệ thống - Mô tả quan hệ giữa các đối tượng · Câu 2: ü Những biểu đồ UML nào sau đây được sử dụng để mô hình hoá hệ thống? - Biểu đồ ca sử dụng - Biểu đồ trình tự - Biểu đồ trạng thái - Tất cả các biểu đồ trên · Câu 3: ü Vẽ biểu đồ ngữ cảnh của hệ thống quản lý sinh viên. 5/23/2021 149
Bài tập (tt1) · Câu 4: ü Vẽ biểu đồ luồng dữ liệu của chức năng rút tiền của hệ thống ATM. · Câu 5: ü Vẽ máy trạng thái của máy giặt có nhiều chế độ giặt · Câu 6: ü Vẽ biểu đồ trình tự mô tả tương tác khi giáo viên nhập điểm theo môn cho từng lớp. 5/23/2021 150
Bài tập (tt2) · Câu 7: ü Hệ thống ngân hàng trực tuyến cho phép khách hàng quản lý tài khoản của mình. Mỗi tài khoản có một số dư. Khách hàng có thể gửi tiền hoặc rút tiền từ tài khoản của mình. Mỗi lần rút hoặc gửi tiền được gọi là một phiên giao dịch. Phiên giao dịch luôn có giá trị và ngày tháng. Tại bất kỳ thời điểm nào khách hàng cũng có thể yêu cầu kiểm tra các giao dịch đã thực hiện. ü Hãy hoàn thành biểu đồ lớp sau. ü Hình của Câu 7: 5/23/2021 151
5/23/2021 152
Bài tập (tt3) · Câu 8: ü Hệ thống quản lý trường đại học như sau: Mỗi trường đều có một hoặc nhiều trường đại học con. Mỗi trường này lại có nhiều khoa. Mỗi khoa có cán bộ giảng dạy (bắt buộc phải thuộc về khoa), cán bộ phụ tá hoặc cán bộ hành chính. Các môn học phải được trường đại học chấp nhận. Một môn học có thể được một hoặc nhiều khoa giảng dạy. Sinh viên phải đăng ký từng môn học. ü Hãy vẽ biểu đồ lớp để mô tả các lớp và quan hệ giữa chúng. (Không cần phải liệt kê thuộc tính và phương thức). · Câu 9: ü Giả sử bạn đang phải xác định yêu cầu cho hệ thống bán hàng trực tuyến. Để đặt hàng, người sử dụng phải kết nối với hệ thống, tìm kiếm các mặt hàng cần mua và lựa chọn ra một hoặc nhiều mặt hàng cần mua. Sau đó, cung cấp các thông tin liên quan đến thẻ tín dụng để thanh toán. ü Hãy xây dựng kịch bản cho trường hợp trên. 5/23/2021 153
Chương 6 Thiết kế kiến trúc
Giới thiệu · Sau khi xác định và phân tích yêu cầu hệ thống, chúng ta chuyển sang pha thiết kế và cài đặt hệ thống. Thiết kế kiến trúc hệ thống là giai đoạn sớm nhất trong quy trình thiết kế hệ thống. Thiết kế kiến trúc cung cấp cho chúng ta bản đặc tả về kiến trúc hệ thống, bao gồm những hệ thống con nào, tương tác với nhau ra sao, framework hỗ trợ điều khiển tương tác giữa các hệ thống con như thế nào 5/23/2021 155
Thiết kế kiến trúc là gì? · Quy trình thiết kế nhằm xác định các hệ thống con cấu tạo lên hệ thống đề xuất và framework giúp điều khiển các hệ thống con và giao tiếp giữa chúng được gọi là quy trình thiết kế kiến trúc. Kết quả của quy trình thiết kế này là bản đặc tả về kiến trúc phần mềm. · Thiết kế kiến trúc là pha sớm nhất trong quy trình thiết kế hệ thống. Thiết kế kiến trúc thường được thực hiện song song với một số hành động đặc tả. Nó bao gồm có việc phát hiện các thành phần chính của hệ thống và giao tiếp giữa chúng. 5/23/2021 156
Thiết kế kiến trúc là gì? (tt1) · Nếu chúng ta có được bản thiết kế kiến trúc rõ ràng thì ta sẽ thấy được các ưu điểm của nó trong những hoạt động sau: ü Giao tiếp giữa các stakeholder: - kiến trúc hệ thống thường được sử dụng làm tâm điểm của các buổi thảo luận giữa các stakeholder. ü Phân tích hệ thống: - tức là phân tích để xác định liệu hệ thống có thoả mãn các yêu cầu phi chức năng của nó hay không. ü Tái sử dụng với quy mô lớn: - kiến trúc có thể được tái sử dụng trong nhiều hệ thống. 5/23/2021 157
Thiết kế kiến trúc là gì? (tt2) · Các đặc điểm của kiến trúc hệ thống: ü Hiệu năng: hạn chế các thao tác phức tạp và tối thiểu hoá giao tiếp. ü Bảo mật: sử dụng kiến trúc phân lớp với nhiều kiểm soát chặt chẽ ở các lớp sâu hơn. ü An toàn. ü Sẵn dùng. ü Có khả năng bảo trì. 5/23/2021 158
Thiết kế kiến trúc là gì? (tt3) · Tuy nhiên, trong quá trình thiết kế kiến trúc có thể xảy ra các xung đột về mặt kiến trúc như sau: ü Sử dụng nhiều thành phần lớn sẽ tăng hiệu năng nhưng giảm khả năng bảo trì. ü Nếu dữ liệu bị dư thừa thì sẽ cải thiện tính sẵn dùng nhưng làm cho việc bảo mật khó khăn hơn. ü Hạn chế các thuộc tính có liên quan đến tính an toàn có nghĩa là nếu có nhiều giao tiếp thì sẽ làm giảm hiệu năng. 5/23/2021 159
Thiết kế kiến trúc là gì? (tt4) · Thiết kế kiến trúc là một quy trình sáng tạo cho nên sự khác biệt của quy trình này phụ thuộc vào từng loại hệ thống được xây dựng. Tuy nhiên, các quy trình thiết kế đều dựa trên những quyết định sau: ü Kiến trúc ứng dụng chung có được sử dụng lại hay không? ü Hệ thống sẽ được phân tán như thế nào? ü Những phong cách kiến trúc nào là thích hợp? ü Hệ thống sẽ được phân rã thành những mô-đun nào? ü Chiến lược điều khiển nào sẽ được sử dụng? ü Cách đánh giá thiết kế kiến trúc ü Kiến trúc sẽ được tư liệu hoá như thế nào? 5/23/2021 160
Thiết kế kiến trúc là gì? (tt5) · Hơn nữa, cũng cần phải chú ý rằng các hệ thống có cùng miền ứng dụng có thể có các kiến trúc chung để phản ánh những khái niệm liên quan đến miền ứng dụng đó. Đồng thời, các dây chuyền sản xuất phần mềm được xây dựng quanh kiến trúc nền tảng cùng với các biến đổi tuỳ thuộc vào yêu cầu của khách hàng. Do đó, khả năng tái sử dụng lại kiến trúc hệ thống là rất cao. 5/23/2021 161
Thiết kế kiến trúc là gì? (tt6) · Các mô hình kiến trúc cơ bản: ü Mô hình cấu trúc tĩnh: mô tả các thành phần hệ thống chính. ü Mô hình quy trình động: biểu diễn quy trình cấu trúc của hệ thống. ü Mô hình giao diện: định nghĩa tập hợp các giao diện của hệ thống con ü Mô hình quan hệ: biểu diễn quan hệ giữa các hệ thống con. ü Mô hình phân tán: biểu diễn cách cài đặt các hệ thống con trên máy tính. 5/23/2021 162
Tổ chức hệ thống · Tổ chức hệ thống phản ánh chiến lược cơ bản được sử dụng để cấu trúc hệ thống. Trong quá trình thiết kế kiến trúc hệ thống, hoạt động đầu tiên phải thực hiện là xây dựng mô hình tổ chức hệ thống. · Có 3 phương pháp tổ chức hệ thống thường được sử dụng: ü Kho dữ liệu dùng chung ü Server và các dịch vụ dùng chung (client-server) ü Phân lớp hoặc máy trừu tượng · Ở các phần tiếp theo, chúng ta sẽ tìm hiểu chi tiết ba phương pháp tổ chức hệ thống này. 5/23/2021 163
Tổ chức hệ thống (tt1) · Kho dữ liệu dùng chung ü Các hệ thống con phải trao đổi dữ liệu và làm việc với nhau một cách hiệu quả. Việc trao đổi dữ liệu được thực hiện theo hai cách: - Dữ liệu chia sẻ được lưu ở CSDL trung tâm hoặc kho dữ liệu và được tất cả các hệ thống con truy nhập. - Mỗi hệ thống con bảo trì CSDL của chính nó và truyền dữ liệu một cách tường minh cho các hệ thống con khác. ü Nếu số lượng dữ liệu dùng chung rất lớn thì mô hình kho dữ liệu dùng chung thường được sử dụng phổ biến nhất. Ưu điểm của mô hình này là: - Đây là phương pháp hiệu quả để chia sẻ số lượng lớn dữ liệu. - Các hệ thống con không cần quan tâm tới những hoạt động liên quan đến dữ liệu như: sao lưu, bảo mật, vì đã có bộ quản lý trung tâm thực hiện nhiệm vụ này. 5/23/2021 164
Tổ chức hệ thống (tt2) · Kho dữ liệu dùng chung (tt1) ü Tuy nhiên, việc sử dụng kho dữ liệu dùng chung cũng có một số nhược điểm sau: - Tất cả các hệ thống con phải chấp nhận mô hình kho dữ liệu. - Việc cải tiến dữ liệu rất phức tạp và tốn kém - Khó phân tán một cách hiệu quả - Không có giới hạn cho các chính sách quản lý cụ thể. 5/23/2021 165
Tổ chức hệ thống (tt3) · Mô hình client – server ü Mô hình kiến trúc client-server là một mô hình hệ thống trong đó hệ thống bao gồm một tập hợp các server cung cấp dịch vụ và các client truy nhập và sử dụng các dịch vụ đó. Các thành phần chính của mô hình này bao gồm: - Tập hợp các server sẽ cung cấp những dịch vụ cụ thể như: in ấn, quản lý dữ liệu - Tập hợp các client truy nhập đến server để yêu cầu cung cấp dịch vụ. - Hệ thống mạng cho phép client truy cập tới dịch vụ mà server cung cấp. ü Client phải biết tên của server và các dịch vụ mà server cung cấp. Nhưng server thì không cần xác định rõ client và hiện tại có bao nhiêu client. Client tạo ra một yêu cầu tới server và chờ server trả lời. 5/23/2021 166
Tổ chức hệ thống (tt4) · Mô hình client – server (tt1) ü Ưu điểm của mô hình client server là: - Phân tán dữ liệu rõ ràng - Sử dụng các hệ thống được kết nối mạng một cách hiệu quả và chi phí dành cho phần cứng có thể rẻ hơn. - Dễ dàng bổ sung hoặc nâng cấp server ü Nhược điểm của mô hình client server là: - Không phải là mô hình dữ liệu dùng chung nên các hệ thống con có thể sử dụng các tổ chức dữ liệu khác nhau. Do đó, việc trao đổi dữ liệu có thể không hiệu quả. - Quản lý mỗi server không thống nhất, dư thừa. - Không đăng ký tên và dịch vụ tập trung. Điều này làm cho việc tìm kiếm server hoặc các dịch vụ rất khó khăn. 5/23/2021 167
Tổ chức hệ thống (tt5) · Mô hình client – server (tt1) 5/23/2021 168
Tổ chức hệ thống (tt6) · Phân rã hệ thống ü Sau khi cấu trúc hệ thống đã được lựa chọn, ta cần phải xác định phương pháp phân rã các hệ thống con thành các mô- đun. ü Hệ thống con là một hệ thống có thể vận hành một cách độc lập, có thể sử dụng một số dịch vụ được cung cấp bởi các hệ thống con khác hoặc cung cấp dịch vụ cho các hệ thống con khác sử dụng. ü Mô-đun là một thành phần hệ thống cung cấp các dịch vụ cho các thành phần khác, nhưng nó thường không được coi như là một hệ thống riêng rẽ, độc lập. ü Có hai cách để phân rã các hệ thống con thành các mô-đun: - Phân rã hướng đối tượng: hệ thống được phân rã thành các đối tượng tương tác với nhau. - Pipeline hướng chức năng hoặc luồng dữ liệu: hệ thống được phân rã thành các mô-đun chức năng chịu trách nhiệm chuyển đổi thông tin đầu vào thành kết quả đầu ra. 5/23/2021 169
Tổ chức hệ thống (tt7) · Phân rã hướng đối tượng ü Mô hình kiến trúc hướng đối tượng cấu trúc hệ thống thành một tập hợp các đối tượng gắn kết lỏng dựa trên các giao diện đã được định nghĩa. ü Phân rã hướng đối tượng liên quan tới việc xác định lớp đối tượng, các thuộc tính và phương thức của nó. Khi cài đặt lớp, các đối tượng sẽ được tạo ra từ các lớp này và có một số mô hình điều khiển được sử dụng để kết hợp các phương thức của đối tượng. ü Ưu điểm của mô hình hướng đối tượng: - Đối tượng được gắn kết lỏng nên khi thay đổi cách cài đặt chúng có thể không ảnh hưởng tới các đối tượng khác. - Đối tượng phản ánh thực thể trong thế giới thực. - Các ngôn ngữ lập trình hướng đối tượng được sử dụng rộng rãi. 5/23/2021 170
Tổ chức hệ thống (tt8) · Phân rã hướng đối tượng (tt1) ü Tuy nhiên, khi giao diện của đối tượng thay đổi có thể gây ra những vấn đề hết sức khó khăn và rất khó biểu diễn các thực thể phức tạp trong thế giới thực như là các đối tượng. ü Ví dụ: các đối tượng trong hệ thống xử lý hoá đơn 5/23/2021 171
Tổ chức hệ thống (tt9) · Pipeline hướng chức năng ü Mô hình pipeline hướng chức năng hoặc mô hình luồng dữ liệu là quy trình chuyển đổi thông tin đầu vào thành kết quả đầu ra. Việc chuyển đổi thông tin đầu vào thành kết quả đầu ra có thể được thực hiện tuần tự hoặc song song. Dữ liệu được xử lý trong quy trình có thể là riêng lẻ hoặc theo lô. ü Ưu điểm của mô hình: - Hỗ trợ tái sử dụng quy trình chuyển đổi - Cung cấp tài liệu để giao tiếp với stakeholder - Dễ dàng bổ sung thêm quy trình chuyển đổi mới. - Dễ dàng thực hiện, kể cả với hệ thống tuần tự hoặc song song. ü Tuy nhiên, mô hình này yêu cầu phải có định dạng dữ liệu chung để truyền qua các pipeline và rất khó hỗ trợ cho các tương tác hướng sự kiện. 5/23/2021 172
Tổ chức hệ thống (tt10) · Pipeline hướng chức năng (tt1) ü Ví dụ: Mô hình luồng dữ liệu của hệ thống xử lý hoá đơn 5/23/2021 173
Các chiến lược điều khiển · Giới thiệu ü Các mô hình cấu trúc hệ thống có liên quan tới cách phân rã hệ thống thành nhiều hệ thống con. Để hệ thống làm việc tốt, ta phải điều khiển được các hệ thống con; cho nên, các dịch vụ của chúng phải được thực hiện đúng chỗ và đúng thời điểm. ü Có 2 loại chiến lược điều khiển: - Điều khiển tập trung: một hệ thống con chịu trách nhiệm kiểm soát, khởi tạo hoặc dừng các hệ thống con khác. - Điều khiển hướng sự kiện: mỗi hệ thống đáp ứng với các sự kiện xảy ra từ các hệ thống con khác hoặc từ môi trường của hệ thống. 5/23/2021 174
Các chiến lược điều khiển (tt1) · Điều khiển tập trung ü Hệ thống con điều khiển chịu trách nhiệm quản lý việc thực hiện của các hệ thống con khác. ü Chiến lược điều khiển tập trung gồm 2 loại mô hình: ü Mô hình gọi trả lời (call-return) - Gồm các thủ tục con được sắp xếp phân cấp, thủ tục điều khiển nằm ở đỉnh của cấu trúc phân cấp và di chuyển dần xuống dưới. Mô hình này thường được áp dụng cho các hệ thống tuần tự. 5/23/2021 175
Các chiến lược điều khiển (tt2) · Điều khiển tập trung (tt1) ü Mô hình gọi trả lời (call-return) (tt1) 5/23/2021 176
Các chiến lược điều khiển (tt3) · Điều khiển hướng sự kiện ü Mô hình lan truyền (Broadcast) - Trong mô hình lan truyền, sự kiện được lan truyền tới tất cả các hệ thống con. Bất kỳ hệ thống nào nếu có thể bắt được sự kiện này thì sẽ xử lý nó. - Mô hình này có hiệu quả đối với việc tích hợp các hệ thống con trên nhiều máy tính khác nhau trong cùng một mạng. - Các hệ thống con phải đăng ký những sự kiện mà nó có thể bắt. Khi những sự kiện này xảy ra, điều khiển sẽ được truyền cho hệ thống con có thể bắt được sự kiện đó. Những quy tăc điều khiển không được gắn với sự kiện và bộ bắt sự kiện. Các hệ thống phải quyết định sự kiện nào là sự kiện mà nó đã đăng ký. Nhưng nó không cần phải biết khi nào sự kiện sẽ được bắt. 5/23/2021 177
Các chiến lược điều khiển (tt4) · Điều khiển hướng sự kiện (tt1) ü Mô hình lan truyền (Broadcast) (tt1) 5/23/2021 178
Các chiến lược điều khiển (tt5) · Điều khiển hướng sự kiện (tt2) ü Mô hình hướng ngắt (Interrupt-driven) - Mô hình hướng ngắt được sử dụng trong các hệ thống thời gian thực trong đó các ngắt được phát hiện bởi bộ bắt ngắt (interrupt handler) và được truyền cho một số các thành phần khác để xử lý. - Các kiểu ngắt và bộ bắt tương ứng được định nghĩa trước. Mỗi kiểu ngắt được gắn với một vị trí nhớ và một bộ chuyển mạch để đưa ngắt tới bộ bắt tương ứng của nó. - Mô hình này cho phép đáp ứng rất nhanh, nhưng lập trình khá phức tạp và khó đánh giá. 5/23/2021 179
Các chiến lược điều khiển (tt6) · Điều khiển hướng sự kiện (tt3) ü Mô hình hướng ngắt (Interrupt-driven) (tt1) 5/23/2021 180
Các kiến trúc tham chiếu · Các kiến trúc tham chiếu ü Mặc dù các hệ thống có cùng một miền ứng dụng có khác nhau về chi tiết nhưng kiến trúc chung của nó khá giống nhau. Do đó, khi xây dựng một hệ thống mới, ta có thể sử dụng lại kiến trúc của hệ thống tương tự đã tồn tại. ü Có 2 loại mô hình kiến trúc cho một miền ứng dụng cụ thể: - Mô hình chung: là sự trừu tượng hoá từ một số các hệ thống thực và bao hàm các thuộc tính quan trọng của các hệ thống này. Mô hình chung là mô hình bottom-up. - Mô hình tham chiếu: là mô hình trừu tượng hoá và lý tưởng. Các mô hình tham chiếu thường kế thừa từ những nghiên cứu về miền ứng dụng hơn là từ các hệ thống đang tồn tại. Mô hình tham chiếu là mô hình top-down. Mô hình tham chiếu được sử dụng như một phần cơ bản để cài đặt hệ thống hoặc để so sánh với các hệ thống khác. Nó đóng vai trò là một mô hình chuẩn để đánh giá các hệ thống khác. 5/23/2021 181
Bài tập · Câu 1: ü Vấn đề nào sau đây liên quan đến pha thiết kế? - Kiến trúc - Dữ liệu - Phạm vi dự án - Giao diên · Câu 2: ü Đặc điểm nào sau đây được sử dụng để đánh giá một bản thiết kế tốt? - Mô tả được sự gắn kết giữa các mô-đun - Thể hiện tất cả các yêu cầu trong pha phân tích - Chứa cả các trường hợp kiểm thử của tất cả các thành phần - Cung cấp một mô tả hoàn thiện về phần mềm · Câu 3: ü Giải thích tại sao cần phải thiết kế kiến trúc trước khi viết đặc tả? 5/23/2021 182
Bài tập (tt1) · Câu 4: ü Giải thích tại sao xung đột lại xảy ra khi thiết kế kiến trúc yêu cầu phải đảm bảo tính sẵn dùng và tính bảo mật? · Câu 5: ü Hãy đề xuất một mô hình cấu trúc thích hợp và thiết kế kiến trúc cho các hệ thống dưới đây - 1. Hệ thống bán vé tàu hoả tự động - 2. Hệ thống hội nghị trực tuyến, cho phép các dạng dữ liệu như âm thanh, hình ảnh, văn bản có thể được truyền tới người sử dụng một cách đồng thời. 5/23/2021 183
Bài tập (tt2) · Câu 6: ü Hãy đề xuất một mô hình điều khiển thích hợp cho các hệ thống sau: - 1. Bộ điều khiển của tivi có thể nhận tín hiệu từ một đơn vị điều khiển từ xa - 2. Hệ thống thanh toán lương, xử lý theo lô. Lấy thông tin về thời gian làm việc, hệ số lương; in ra bảng lương và chuyển thông tin vào tài khoản ngân hàng. 5/23/2021 184
Chương 7 Thiết kế giao diện người dùng
Giới thiệu · Nguyên tắc quan trọng khi xây dựng một hệ thống phần mềm, đó là: ü Người sử dụng không quan tâm đến cấu trúc bên trong của hệ thống, đơn giản hay phức tạp; cái mà họ có thể đánh giá được và cảm nhận được chính là giao diện tương tác giữa hệ thống và người sử dụng. ü Nếu người sử dụng cảm thấy giao diện không thích hợp, khó sử dụng thì rất có thể họ sẽ không sử dụng cả hệ thống; cho dù hệ thống đó có đáp ứng tất cả các chức năng nghiệp vụ mà họ muốn. Và như vậy, dự án của chúng ta sẽ thất bại. · Vì tầm quan trọng của giao diện người dùng, nên chúng ta có cả một chương để nói về chúng. Trong chương này, chúng ta sẽ nghiên cứu những vấn đề sau: ü Các yếu tố liên quan đến giao diện người dùng ü Quy trình xây dựng giao diện người dùng 5/23/2021 186
Giao diện người dùng · Tổng quan: ü Giao diện người dùng cần phải được thiết kế sao cho phù hợp với kỹ năng, kinh nghiệm và sự trông đợi của người sử dụng nó. ü Người sử dụng hệ thống thường đánh giá hệ thống thông qua giao diện hơn là chức năng của nó. Giao diện của hệ thống nghèo nàn có thể khiến người sử dụng tạo ra các lỗi hết sức nghiêm trọng. Đó là lý do tại sao nhiều hệ thống phần mềm không bao giờ được sử dụng. · Mục tiêu: ü Nắm được sự ảnh hưởng của người sử dụng tới giao diện ü Một số nguyên tắc khi thiết kế giao diện người dùng ü Phân loại các khả năng tương tác giữa người và máy để thiết kế giao diện cho phù hợp ü Biết cách biểu diễn thông tin cho phù hợp với người sử dụng 5/23/2021 187
Giao diện người dùng (tt1) · Tác nhân con người trong thiết kế giao diện: ü Một nhân tố quan trọng ảnh hưởng tới quá trình thiết kế giao diện đó chính là người sử dụng hệ thống. Do đó, chúng ta phải tìm hiểu một số đặc điểm của người sử dụng có liên quan đến giao diện hệ thống: - Khả năng nhớ tức thời của con người bị hạn chế: con người chỉ có thể nhớ ngay khoảng 7 loại thông tin. Nếu ta biểu diễn nhiều hơn 7 loại, thì có thể khiến người sử dụng không nhớ hết và gây ra các lỗi. - Người sử dụng có thể gây ra lỗi: khi người sử dụng gây ra lỗi khiến hệ thống sẽ hoạt động sai, những thông báo không thích hợp có thể làm tăng áp lực lên người sử dụng và do đó, càng xảy ra nhiều lỗi hơn. - Người sử dụng là khác nhau: con người có những khả năng khác nhau. Những người thiết kế không nên chỉ thiết kế giao diện phù hợp với những khả năng của chính họ. - Người sử dụng thích các loại tương tác khác nhau: một số người thích hình ảnh, văn bản, âm thanh 5/23/2021 188
Giao diện người dùng (tt2) · Các nguyên tắc thiết kế giao diện: ü Thiết kế giao diện phải phụ thuộc vào yêu cầu, kinh nghiệm và khả năng của người sử dụng hệ thống. ü Người thiết kế cũng nên quan tâm đến những giới hạn vật lý và tinh thần của con người và nên nhận ra rằng con người luôn có thể gây ra lỗi. ü Không phải tất cả các nguyên tắc thiết kế giao diện đều có thể được áp dụng cho tất cả các giao diện. 5/23/2021 189
Giao diện người dùng (tt3) · Các nguyên tắc thiết kế giao diện (tt1): ü Sau đây là các nguyên tắc thiết kế giao diện: - Sự quen thuộc của người sử dụng: giao diện phải được xây dựng dựa trên các thuật ngữ và các khái niệm mà người sử dụng có thể hiểu được hơn là những khái niệm liên quan đến máy tính. * Ví dụ: hệ thống văn phòng nên sử dụng các khái niệm như thư, tài liệu, cặp giấy mà không nên sử dụng những khái niệm như thư mục, danh mục - Thống nhất: hệ thống nên hiển thị ở mức thống nhất thích hợp. * Ví dụ: các câu lệnh và menu nên có cùng định dạng - Tối thiểu hoá sự bất ngờ: nếu một yêu cầu được xử lý theo cách đã biết trước thì người sử dụng có thể dự đoán các thao tác của những yêu cầu tương tư. 5/23/2021 190
Giao diện người dùng (tt4) · Các nguyên tắc thiết kế giao diện (tt2): ü Sau đây là các nguyên tắc thiết kế giao diện (tt1): - Khả năng phục hồi: hệ thống nên cung cấp một số khả năng phục hồi từ lỗi của người sử dụng và cho phép người sử dụng khôi phục lại từ chỗ bị lỗi. Khả năng này bao gồm cho phép làm lại, hỏi lại những hành động như xoá, huỷ - Hướng dẫn người sử dụng: như hệ thống trợ giúp, hướng dẫn trực tuyến - Tính đa dạng: hỗ trợ nhiều loại tương tác cho nhiều loại người sử dung khác nhau. * Ví dụ: nên hiển thị phông chữ lớn với những người cận thị. 5/23/2021 191
Giao diện người dùng (tt5) · Các nguyên tắc thiết kế giao diện (tt3): ü Sau đây là các nguyên tắc thiết kế giao diện (tt2): - Tương tác giữa người sử dụng và hệ thống được chia thành 5 loại sau: * Vận hành trực tiếp * Lựa chọn menu * Điền vào biểu mẫu (Form) * Ngôn ngữ ra lệnh * Ngôn ngữ tự nhiên 5/23/2021 192
Giao diện người dùng (tt6) · Biểu diễn thông tin ü Biểu diễn thông tin có liên quan tới việc hiển thị các thông tin trong hệ thống tới người sử dụng. Thông tin có thể được biểu diễn một cách trực tiếp hoặc có thể được chuyển thành nhiều dạng hiển thị khác như: dạng đồ hoạ, âm thanh ü Thông tin cần biểu diễn được chia thành hai loại: - Thông tin tĩnh: được khởi tạo ở đầu của mỗi phiên. Nó không thay đổi trong suốt phiên đó và có thể là ở dạng số hoặc dạng văn bản. - Thông tin động: thay đổi trong cả phiên sử dụng và sự thay đổi này phải được người sử dụng quan sát. - Biểu diễn digital hay analogue? 5/23/2021 193
Giao diện người dùng (tt7) · Biểu diễn thông tin (tt1) ü Các nhân tố ảnh hưởng tới việc hiển thị thông tin: - Người sử dụng thích hiển thị một phần thông tin hay quan hệ dữ liệu? - Giá trị của thông tin thay đổi nhanh như thế nào? Sự thay đổi đó có cần phải thể hiện ngay lập tức hay không? - Người sử dụng có phải thực hiện các hành động để đáp ứng với sự thay đổi không? - Có phải là giao diện vận hành trực tiếp không? - Thông tin ở dạng văn bản hay dạng số? Các giá trị quan hệ có quan trọng không? - Biểu diễn digital hay analogue? 5/23/2021 194
Giao diện người dùng (tt8) · Biểu diễn thông tin (tt2) ü Nếu chúng ta cần hiển thị số lượng lớn thông tin thì nên trực quan hoá dữ liệu. Trực quan hoá có thể phát hiện ra mối quan hệ giữa các thực thể và các xu hướng trong dữ liệu. - Ví dụ: thông tin về thời tiết được hiển thị dưới dạng biểu đồ, trạng thái của mạng điện thoại nên được hiển thị bởi các nút có liên kết với nhau. ü Chúng ta thường sử dụng màu trong khi thiết kế giao diện. Màu bổ sung thêm một chiều nữa cho giao diện và giúp cho người sử dụng hiểu được những cấu trúc thông tin phức tạp. Màu có thể được sử dụng để đánh dấu những sự kiện ngoại lệ. 5/23/2021 195
Giao diện người dùng (tt9) · Biểu diễn thông tin (tt3) ü Tuy nhiên, khi sử dụng màu để thiết kế giao diện có thể gây phản tác dụng. Do đó, chúng ta nên quan tâm tới một số hướng dẫn sau: - Giới hạn số lượng màu được sử dụng và không nên lạm dụng việc sử dụng màu. - Thay đổi màu khi thay đổi trạng thái của hệ thống - Sử dụng màu để hỗ trợ cho những nhiệm vụ mà người sử dụng đang cố gắng thực hiện. - Sử dụng màu một cách thống nhất và cẩn thận. - Cẩn thận khi sử dụng các cặp màu. 5/23/2021 196
Giao diện người dùng (tt10) · Biểu diễn thông tin (tt4) ü Khi người sử dụng tương tác với hệ thống, rất có thể xảy ra lỗi và hệ thống phải thông báo cho người sử dụng biết lỗi gì đã xảy ra hoặc đã có chuyện gì xảy ra với hệ thống. Do đó, thiết kế thông báo lỗi vô cùng quan trọng. Nếu thông báo lỗi nghèo nàn có thể làm cho người sử dụng từ chối hơn là chấp nhận hệ thống. ü Vì vậy, thông báo lỗi nên ngắn gọn, xúc tích, thống nhất và có cấu trúc. Việc thiết kế thông báo lỗi nên dựa vào kỹ năng và kinh nghiệm của người sử dụng. - Ví dụ: Giao diện thông báo lỗi trong hệ thống quản lý bệnh viện, y tá phải nhập hồ sơ bệnh nhân. Trong khi nhập, y tá quên tên bệnh nhân. * Thiết kế giao diện thống báo lỗi. * Cho biết các tiêu chuẩn đánh giá một giao diện tốt? 5/23/2021 197
Quy trình thiết kế UI · Giới thiệu: ü Thiết kế giao diện người dùng là một quy trình lặp lại bao gồm sự cộng tác giữa người sử dụng và người thiết kế. ü Trong quy trình này gồm 3 hoạt động cơ bản: - Phân tích người sử dụng: tìm hiểu những gì người sử dụng sẽ làm với hệ thống. - Lập mẫu thử hệ thống: xây dựng một tập các mẫu thử để thử nghiệm - Đánh giá giao diện: thử nghiệm các mẫu thử cùng với người sử dụng. 5/23/2021 198
Quy trình thiết kế UI (tt1) 5/23/2021 199
Quy trình thiết kế UI (tt2) · Mục tiêu: ü Hiểu được quy trình thiết kế giao diện người dùng ü Nắm được chi tiết từng hoạt động trong quy trình thiết kế giao diện người dùng ü Với mỗi hoạt động, chúng ta có rất nhiều cách để thực hiện. Do đó, phải có khả năng lựa chọn phương pháp nào là thích hợp nhất cho từng hoàn cảnh cụ thể. 5/23/2021 200
Quy trình thiết kế UI (tt3) · Phân tích người sử dụng ü Nếu ta không hiểu rõ những gì người sử dụng muốn làm với hệ thống, thì ta sẽ không thể thiết kế được một giao diện hiệu quả. ü Phân tích người sử dụng phải được mô tả theo những thuật ngữ để người sử dụng và những người thiết kế khác có thể hiểu được. ü Các ngữ cảnh mà ta mô tả thao tác ở trong đó là một trong những cách mô tả phân tích người dùng. Ta có thể lấy được rất nhiều yêu cầu của người sử dụng từ đó. 5/23/2021 201
Quy trình thiết kế UI (tt4) · Phân tích người sử dụng (tt1) ü Các kỹ thuật phân tích: - Phân tích nhiệm vụ: * mô hình hoá các bước cần thực hiện để hoàn thành một nhiệm vụ. - Phân tích nhiệm vụ phân cấp. - Phỏng vấn và trắc nghiệm: * hỏi người sử dụng về những gì mà họ làm. Khi phỏng vấn, chúng ta nên dựa trên những câu hỏi có kết thúc mở. Sau đó, người sử dụng cung cấp những thông tin mà họ nghĩ rằng nó là cần thiết; nhưng không phải tất cả các thông tin đó là có thể được sử dụng. * Ngoài ra, chúng ta có thể thực hiện phỏng vấn với cả nhóm người sử dụng, điều đó cho phép người sử dụng thảo luận với nhau về những gì họ làm. - Mô tả: * quan sát người sử dụng làm việc và hỏi họ về những cách mà không được biết tới. Nên nhớ rằng có nhiều nhiệm vụ của người sử dụng thuộc về trực giác và rất khó để mô tả và giải thích chúng. Dựa trên kỹ thuật này ta có thể hiểu thêm về các ảnh hưởng xã hội và tổ chức tác động tới công việc đó. 5/23/2021 202
5/23/2021 203
Quy trình thiết kế UI (tt5) · Lập mẫu thử giao diện người dùng ü Mẫu thử cho phép người sử dụng có được những kinh nghiệm trực tiếp với giao diện. Nếu không có những kinh nghiệm trực tiếp như vậy thì không thể đánh giá được khả năng có thể sử dụng được của giao diện. ü Lập mẫu thử là một quy trình gồm 2 trạng thái: - Lập các mẫu thử trên giấy. - Tinh chỉnh mẫu thử và xây dựng chúng ü Các kỹ thuật lập mẫu thử: - Mẫu thử hướng nguyên mẫu: * sử dụng công cụ như Macromedia Director để xây dựng một tập hợp các nguyên mẫu và màn hình. Khi người sử dụng tương tác với chúng thì màn hình sẽ thay đổi để hiển thị trạng thái kế tiếp. - Lập trình trực quan: * sử dụng các ngôn ngữ được thiết kế cho việc phát triển nhanh như Visual Basic. - Mẫu thử dựa Internet: * sử dụng web browser và script. 5/23/2021 204
Quy trình thiết kế UI (tt6) · Đánh giá giao diện người dùng ü Ta nên đánh giá bản thiết kế giao diện người dùng để xác định khả năng phù hợp của nó. Tuy nhiên, việc đánh giá trên phạm vi rộng tốn nhiều chi phí và không thể thực hiện được đối với hầu hết các hệ thống. ü Các kỹ thuật đánh giá đơn giản: - Trắc nghiệm lại các phản hồi của người sử dụng - Ghi lại quá trình sử dụng mẫu thử của hệ thống và đánh giá nó. - Lựa chọn những thông tin về việc sử dụng dễ dàng và các lỗi của người sử dụng. - Cung cấp mã lệnh trong phần mềm để thu thập những phản hồi của người sử dụng một cách trực tuyến. 5/23/2021 205
5/23/2021 206
5/23/2021 207
5/23/2021 208
5/23/2021 209
5/23/2021 210
5/23/2021 211
5/23/2021 212
5/23/2021 213
Bài tập · Câu 1: ü Nêu một số trường hợp không thể cung cấp giao diện người dùng một cách nhất quán · Câu 2: ü Hãy đề xuất một vài giao diện người dùng thích hợp cho hệ thống bán sách trực tuyến, dành cho những khách hàng là người khuyết tật. · Câu 3: ü Cho biết những ưu điểm của việc hiển thị thông tin một cách trực quan. Lấy ví dụ để minh hoạ cho tính vượt trội của việc hiển thị thông tin trực quan so với các thông tin thống kế như văn bản, số liệu. 5/23/2021 214
Bài tập (tt1) · Câu 4: ü Nêu những chú ý khi sử dụng màu để thiết kế giao diện · Câu 5: ü Viết kịch bản tương tác của hệ thống dịch vụ đặt mua vé trước và thực hiện thanh toán bằng thẻ tín dụng. 5/23/2021 215
Chương 8 Cải tiến phần mềm
Giới thiệu · Thay đổi phần mềm là một điều không thể tránh khỏi vì những lí do sau: ü Những yêu cầu mới sẽ xuất hiện khi sử dụng phần mềm ü Môi trường nghiệp vụ thay đổi ü Các lỗi phần mềm cần phải sửa chữa ü Máy tính và các thiết bị mới được bổ sung vào hệ thống ü Hiệu năng hoặc độ tin cậy của hệ thống phải được cải thiện. 5/23/2021 217
5/23/2021 218
5/23/2021 219
Giới thiệu (tt1) · Tuy nhiên, vấn đề quan trọng là chúng ta phải thực hiện và quản lý các thay đổi đối với hệ thống phần mềm đã tồn tại. Và chúng ta phải thấy được tầm quan trọng của việc cải tiến phần mềm: ü Các tổ chức thường đầu tư một lượng vốn khá lớn vào các hệ thống phần mềm của họ. Cho nên họ có quyền đòi hỏi phải sở hữu một hệ thống hoàn hảo. ü Để bảo trì giá trị sở hữu của tổ chức, họ phải thay đổi và cải tiến hệ thống. ü Ngân sách phần mềm chính trong các công ty lớn thường dùng cho việc cải tiến các hệ thống đã tồn tại hơn là phát triển một hệ thống mới. 5/23/2021 220
Giới thiệu (tt2) 5/23/2021 221
Bảo trì phần mềm · Bảo trì phần mềm chính là hoạt động chỉnh sửa chương trình sau khi nó đã được đưa vào sử dụng. · Bảo trì thường không bao gồm những thay đổi chính liên quan tới kiến trúc của hệ thống. Những thay đổi trong hệ thống thường được cài đặt bằng cách điều chỉnh những thành phần đang tồn tại và bổ sung những thành phần mới cho hệ thống. 5/23/2021 222
Bảo trì phần mềm (tt1) · Bảo trì là không thể tránh khỏi vì: ü Các yêu cầu hệ thống thường thay đổi khi hệ thống đang được xây dựng vì môi trường thay đổi. Vì vậy, hệ thống được chuyển giao có thể không thoả mãn các yêu cầu của nó. ü Các hệ thống có gắn kết chặt chẽ với môi trường của nó. Khi hệ thống được cài đặt trong một môi trường nhất định nó sẽ làm thay đổi môi trường đó và vì vậy sẽ thay đổi các yêu cầu của hệ thống. ü Các hệ thống phải được bảo trì nếu chúng muốn là những phần hữu ích trong môi trường nghiệp vụ. 5/23/2021 223
Bảo trì phần mềm (tt2) · Phân loại các kiểu bảo trì: ü Bảo trì sửa lỗi: thay đổi hệ thống để sửa lại những khiếm khuyết nhằm thoả mãn yêu cầu hệ thống. ü Bảo trì tích hợp hệ thống vào một môi trường vận hành khác ü Bảo trì để bổ sung hoặc chỉnh sửa các yêu cầu chức năng của hệ thống: chỉnh sửa hệ thống sao cho thoả mãn các yêu cầu mới. · Chi phí bảo trì thường lớn hơn chi phí xây dựng gấp từ 2 đến 100 lần phụ thuộc vào từng ứng dụng. Chi phí bảo trì bị ảnh hưởng bởi cả tác nhân kỹ thuật và phi kỹ thuật. · Nếu bảo trì càng nhiều, sẽ càng làm thay đổi cấu trúc phần mềm và do đó sẽ làm cho việc bảo trì càng trở lên khó khăn hơn. Phần mềm có tuổi thọ càng cao thì càng phải cần chi phí cao hơn (vì sử dụng các ngôn và chương trình dịch cũ ) 5/23/2021 224
Bảo trì phần mềm (tt3) 5/23/2021 225
Bảo trì phần mềm (tt4) · Các nhân tố ảnh hưởng đến chi phí bảo trì: ü Sự ổn định của đội dự án: chi phí bảo trì sẽ giảm nếu nhân viên trong đội dự án không thay đổi. ü Những trách nhiệm đã cam kết: người xây dựng hệ thống có thể không cam kết trách nhiệm bảo trì cho nên không có gì để bắt buộc họ phải thiết kế lại cho các thay đổi trong tương lai. ü Kỹ năng của nhân viên: nhân viên bảo trì thường không có kinh nghiệm và hiểu biết về miền ứng dụng của họ bị hạn chế. ü Tuổi thọ và cấu trúc chương trình: khi tuổi thọ và cấu trúc chương trình bị xuống cấp thì chúng càng trở lên khó hiểu và thay đổi nhiều. 5/23/2021 226
Bảo trì phần mềm (tt5) · Dự đoán bảo trì ü Dự đoán bảo trì có liên quan tới việc đánh giá những phần nào của hệ thống có thể gây ra lỗi và cần nhiều chi phí để bảo trì. ü Khả năng chịu được sự thay đổi phụ thuộc vào khả năng bảo trì của các thành phần bị ảnh hưởng bởi sự thay đổi đó. Thực hiện các thay đổi có thể làm hỏng hệ thống và giảm khả năng bảo trì của nó. ü Chi phí bảo trì phụ thuộc vào số lượng các thay đổi và chi phí thay đổi phụ thuộc vào khả năng bảo trì. 5/23/2021 227
Bảo trì phần mềm (tt6) · Dự đoán thay đổi ü Dự đoán số lượng các thay đổi có thể xảy ra và tìm hiểu mối quan hệ giữa hệ thống và môi trường của nó. ü Sự thay đổi yêu cầu hệ thống có liên quan chặt chẽ tới sự thay đổi của môi trường. Trong đó, các nhân tố ảnh hưởng tới mối quan hệ này bao gồm: - Số lượng và độ phức tạp của các giao diện hệ thống - Số lượng các yêu cầu bất ổn định có tính phân cấp - Các quy trình nghiệp vụ của hệ thống. 5/23/2021 228
Các quy trình cải tiến phần mềm · Các quy trình cải tiến phần mềm phụ thuộc vào: ü Kiểu phần mềm cần bảo trì ü Quy trình phát triển phần mềm đã được sử dụng ü Kỹ năng và kinh nghiệm của các stakeholder. · Các đề xuất thay đổi là định hướng để cải tiến hệ thống. Phát hiện thay đổi và cải tiến được thực hiện trong vòng đời hệ thống. Các hình vẽ sau đây thể hiện một cách khái quát các quy trình cải tiến hệ thống. 5/23/2021 229