Lập trình web - Chương 2: Các mô hình phát triển hệ thống

Nội dung text: Lập trình web - Chương 2: Các mô hình phát triển hệ thống

1. Chương 2 Các Mô hình Phát triển Hệ thống BM HTTT – Khoa CNTT – ĐHCN tpHCM - 2009 1
2. Nội dung • Chu kỳ phát triển phần mềm (SDLC) • Các mô hình thông dụng BM HTTT – Khoa CNTT – ĐHCN tpHCM - 2009 2
3. Quy trình phần mềm là gì? (Software Process) • CNPM là công nghệ theo lớp (layered technology) • Nền tảng của CNPM chính là lớp Process, nó là chất kết dính công nghệ và cho phép phát triển các phần mềm hiệu quả và đúng thời hạn BM HTTT – Khoa CNTT – ĐHCN tpHCM - 2009
4. Methods – Các phương pháp BM HTTT – Khoa CNTT – ĐHCN tpHCM - 2009 4
5. Tools – Các công cụ BM HTTT – Khoa CNTT – ĐHCN tpHCM - 2009 5
6. Quy trình phát triển phần mềm (Software development – SEP) • Qui trình có thể hiểu là phương pháp thực hiện hoặc sản xuất ra sản phẩm. Tương tự như vậy, SEP chính là phương pháp phát triển hay sản xuất ra sản phẩm phần mềm. • Thông thường một qui trình bao gồm những yếu tố cơ bản sau: – Thủ tục (Procedures) – Hướng dẫn công việc (Activity Guidelines) – Biểu mẫu (Forms/templates) – Danh sách kiểm định (Checklists) – Công cụ hỗ trợ (Tools) BM HTTT – Khoa CNTT – ĐHCN tpHCM - 2009 6
7. Quy trình phát triển phần mềm (Software development – SEP) BM HTTT – Khoa CNTT – ĐHCN tpHCM - 2009 7
8. Chi phí của công nghệ phần mềm BM HTTT – Khoa CNTT – ĐHCN tpHCM - 2009 8
9. Chi phí của công nghệ phần mềm BM HTTT – Khoa CNTT – ĐHCN tpHCM - 2009 9
10. Chu kỳ phát triển phần mềm (Software Development Life Cycle - SDLC) • Chu kỳ phần mềm (Software life cycle) là gì? “ Là khoảng thời gian từ lúc phần mềm bắt đầu hình thành cho đến lúc nó không còn dùng được nữa” • Chu kỳ phần mềm thường trải qua các giai đoạn (phase) sau: – Requirement – Design – Implementation – Test – Maintenance • Chu kỳ phần mềm còn được gọi là chu kỳ phát triển phần mềm (SDLC) BM HTTT – Khoa CNTT – ĐHCN tpHCM - 2009 10
11. Chu kỳ phát triển phần mềm (Software Development Life Cycle - SDLC) BM HTTT – Khoa CNTT – ĐHCN tpHCM - 2009 11
12. Các mô hình SDLC • Mô hình thác nước (waterfall) • Mô hình prototype • Mô hình RAD (rapid application development) • Mô hình tăng tiến (incremental model) • Mô hình xoắn ốc (spiral model) • Mô hình dựa vào thành phần (Component-Based Model) Tùy theo mô hình áp dụng mà các bước trong mỗi giai đoạn sẽ khác nhau: có thể từ 3 đến 30 bước BM HTTT – Khoa CNTT – ĐHCN tpHCM - 2009 12
13. Mô hình thác nước • Còn gọi là mô hình cổ điển (classic) hay mô hình tuần tự tuyến tính (linear sequencial model) • Các giai đoạn được thực hiện tuần tự BM HTTT – Khoa CNTT – ĐHCN tpHCM - 2009 13
14. Mô hình waterfall BM HTTT – Khoa CNTT – ĐHCN tpHCM - 2009 14
15. Giai đoạn 1 Phân tích yêu cầu và tài liệu đặc tả (Requirements and Specifications) • Là giai đoạn xác định những “đòi hỏi” (“What”) liên quan đến chức năng và phi chức năng mà hệ thống phần mềm cần có. Giai đoạn này cần sự tham gia tích cực của khách hàng và kết thúc bằng một tài liệu được gọi là “Bản đặc tả yêu cầu phần mềm” hay SRS (software requirement specification) chứa các yêu cầu đã được duyệt (reviewed) và nghiệm thu (approved) bởi những người có trách nhiệm đối với dự án (từ phía khách hàng). • SRS chính là nền tảng cho các hoạt động tiếp theo cho đến cuối dự án. BM HTTT – Khoa CNTT – ĐHCN tpHCM - 2009 15
16. Giai đoạn 2 Phân tích hệ thống và thiết kế hệ thống (System Analysis and Design): • là giai đoạn định ra “làm thế nào” (“How”) để hệ thống phần mềm đáp ứng được những “đòi hỏi” (“What”) mà khách hàng yêu cầu trong SRS. Đây là chính là cầu nối giữa “đòi hỏi” (“What”) và mã (Code) được hiện thực để đáp ứng yêu cầu đó BM HTTT – Khoa CNTT – ĐHCN tpHCM - 2009 16
17. Giai đoạn 3: Mã hóa và kiểm thử đơn vị (Coding and Unit Test) • Là giai đoạn hiện thực “làm thế nào” (“How”) được chỉ ra trong giai đoạn “Phân tích hệ thống và thiết kế”. BM HTTT – Khoa CNTT – ĐHCN tpHCM - 2009 17
18. Giai đoạn 4 Kiểm thử tích hợp và hệ thống (Integration and System Testing) • Giai đoạn này sẽ tiến hành kiểm thử mã (code) đã được hiện thực, bao gồm kiểm thử tích hợp cho nhóm các thành phần và kiểm thử toàn hệ thống (system test). • Một khâu kiểm thử cuối cùng thường được thực hiện là nghiệm thu (acceptance test), với sự tham gia của khách hàng trong vai trò chính để xác định hệ thống phần mềm có đáp ứng yêu cầu của họ hay không. BM HTTT – Khoa CNTT – ĐHCN tpHCM - 2009 18
19. Giai đoạn 5 Vân hành và bảo trì (Deployment and Maintenance): • Là giai đoạn cài đặt, cấu hình và huấn luyện khách hàng, sửa chữa những lỗi của phần mềm (nếu có) và phát triển những thay đổi mới được khách hàng yêu cầu (như sửa đổi, thêm hay bớt chức năng/đặc điểm của hệ thống). BM HTTT – Khoa CNTT – ĐHCN tpHCM - 2009 19
20. Bất lợi của mô hình waterfall • Các dự án thực tế ít khi tuân theo 1 cách tuần tự như mô hình. Mặc dù mô hình có thể lặp nhưng không cụ thể, rõ ràng. Các thay đổi do lặp lại có thể gây nhầm lẫn cho thành viên của đội dự án. • Thường khách hàng khó mà phát biểu tất cả các yêu cầu 1 cách tường minh ngay lúc đầu được nhưng mô hình waterfall thì đòi hỏi phải thu thập đầy đủ yêu cầu của khách trước khi sang bước kế tiếp. • Khách hàng cần phải kiên nhẫn đợi sản phẩm cho đến khi dự án kết thúc. Nhiều lúc một lỗi nào đó của phần mềm sẽ không được phát hiện cho đến khi chương trình chính thức được duyệt. BM HTTT – Khoa CNTT – ĐHCN tpHCM - 2009 20
21. Vai trò của mô hình waterfall • Mô hình phản ảnh thực tế công nghệ. • Là mô hình cơ sở cho đa số các hệ thống phát triển phần mềm - phần cứng. BM HTTT – Khoa CNTT – ĐHCN tpHCM - 2009 21
22. Mô hình chữ V BM HTTT – Khoa CNTT – ĐHCN tpHCM - 2009 22
23. Mô hình chữ V • Toàn bộ qui trình được chia thành hai nhóm giai đoạn tương ứng nhau: nhóm phát triển và nhóm kiểm thử. Mỗi giai đoạn phát triển sẽ kết hợp với một giai đoạn kiểm thử tương ứng • Các hoạt động kiểm thử phải được tiến hành song song (theo khả năng có thể) ngay từ đầu chu trình cùng với các hoạt động phát triển. • Ví dụ, các hoạt động cho việc lập kế hoạch kiểm thử toàn hệ thống có thể được thực hiện song song với các hoạt động phân tích và thiết kế hệ thống BM HTTT – Khoa CNTT – ĐHCN tpHCM - 2009 23
24. Mô hình prototype (Mô hình làm bản mẫu) BM HTTT – Khoa CNTT – ĐHCN tpHCM - 2009 24
25. Mô hình prototype nên dùng khi nào? • Khi khách hàng đưa ra các mục tiêu chính của phần mềm nhưng không xác định đuợc các yêu cầu cụ thể như thế nào. • Khi nhà phát triển không bảo đảm là giải thuật có thật sự hiệu quả hay không, khả năng đáp ứng của hệ thống thế nào, tương tác giữa người và máy nên xây dựng thế nào. BM HTTT – Khoa CNTT – ĐHCN tpHCM - 2009 25
26. Mô hình prototype • Bắt đầu bằng việc thu thập yêu cầu với sự có mặt của đại diện của cả hai phía nhằm định ra mục tiêu tổng thể của hệ thống đồng thời ghi nhận tất cả những yêu cầu có thể biết được và sơ luợc những nhóm yêu cầu nào cần phải được làm rõ. • Sau đó, thực hiện thiết kế nhanh tập trung chuyển tải những khía cạnh thông qua prototype để khách hàng có thể hình dung, đánh giá giúp hoàn chỉnh yêu cầu cho toàn hệ thống ➔ giúp tinh chỉnh yêu cầu, và giúp đội ngũ phát triển thông hiểu hơn những gì cần được phát triển. • Tiếp theo có thể là một chu trình theo mô hình waterfall hay cũng có thể là mô hình khác. BM HTTT – Khoa CNTT – ĐHCN tpHCM - 2009 26
27. Bất lợi của mô hình prototype • Prototype thường được làm thật nhanh trong thời gian ngắn nên không được xây dựng trên cùng môi trường và công cụ phát triển của giai đoạn xây dựng phần mềm thực sự sau này. Prototype không đặt ra mục tiêu tái sử dụng cho giai đoạn phát triển thực sự sau đó. BM HTTT – Khoa CNTT – ĐHCN tpHCM - 2009 27
28. Mô hình tiến hóa (Evolutionary) • Cũng là một dạng mô hình mẫu (prototype), tuy nhiên có sự khác biệt: – Mô hình tiến hóa xây dựng nhiều phiên bản prototype liên tiếp nhau. – Những phiên bản prototype trước sẽ được xây dựng với mục tiêu có thể tái sử dụng trong những phiên bản sau. BM HTTT – Khoa CNTT – ĐHCN tpHCM - 2009 28
29. Mô hình tiến hóa (Evolutionary) BM HTTT – Khoa CNTT – ĐHCN tpHCM - 2009 29
30. Khuyết điểm của mô hình tiến hóa • Quá trình thì không nhìn thấy rõ được: Các nhà quản lý cần phân phối thường xuyên các phiên bản để đo lường sự tiến bộ. Nó không kinh tế trong việc làm ra các hồ sơ cho phần mềm. • Phần mềm thường dược cấu trúc nghèo nàn: Sự thay đổi liên tục dễ làm đổ vỡ cấu trúc của phần mềm, tạo ra sự khó khăn và tốn phí. • Thường đòi hỏi những kỹ năng đặc biệt: chỉ có thể được tiến hành bởi các nhóm nhỏ có kỹ năng cao cũng như các cá nhân phải năng động. BM HTTT – Khoa CNTT – ĐHCN tpHCM - 2009 30
31. Mô hình tăng trưởng và lặp (Incremental and iterative model) • Mô hình tăng dần (Incremental): thêm chức năng vào sản phẩm • Mô hình lặp (Iterative): thay đổi sản phẩm BM HTTT – Khoa CNTT – ĐHCN tpHCM - 2009 31
32. Mô hình tăng trưởng Incremental Model BM HTTT – Khoa CNTT – ĐHCN tpHCM - 2009 32
33. Mô hình tăng trưởng • Mô hình tăng dần kết hợp những ưu điểm của mô hình thác nước và mô hình tiến hóa. • Ý tưởng của mô hình này là phân chia phần mềm thành những phần tăng trưởng (increments) và phát triển, bàn giao chúng lần lượt cho khách hàng theo mức độ quan trọng. • Phần tăng trưởng nào đến lượt được phát triển thì những yêu cầu tương ứng sẽ được phân tích. Chỉ những thay đổi từ phía khách hàng cho những phần chưa được phát triển mới được chấp nhận. BM HTTT – Khoa CNTT – ĐHCN tpHCM - 2009 33
34. Ưu điểm của mô hình tăng trưởng • Rút ngắn thời gian chờ đợi của khách hàng. Khách hàng không phải đợi đến khi toàn bộ hệ thống hoàn thành. Những thành phần quan trọng nhất được bàn giao sớm và mang lại lợi ích sớm hơn cho khách hàng. • Tăng chất lượng phần mềm.Thành phần quan trọng nhất thì được phát triển và hoạt động sớm nhất, bởi vậy nó được test nhiều nhất. Ý kiến của khách hàng và kinh nghiệm phát triển các thành phần trước sẽ được áp dụng ngay lập tức cho các thành phần sau. BM HTTT – Khoa CNTT – ĐHCN tpHCM - 2009 34
35. Ưu điểm của mô hình tăng trưởng • Giảm bớt những yêu cầu không cần thiết từ khách hàng. Khi một tính năng chưa có mặt trong hệ thống, họ sẽ nghĩ rằng nó sẽ được tích hợp vào ở những lần bàn giao tiếp theo! • Tăng năng suất lao động. Nhiều lập trình viên làm việc tốt hơn trong các dự án nhỏ mà họ sớm nhìn thấy thành quả lao động của mình. BM HTTT – Khoa CNTT – ĐHCN tpHCM - 2009 35
36. Khuyết điểm của mô hình tăng trưởng • Không phải dự án nào cũng có thể được phân chia thành các phần tăng trưởng nhỏ để phát triển và bàn giao tuần tự. BM HTTT – Khoa CNTT – ĐHCN tpHCM - 2009 36
37. Mô hình RAD (Rapid Application Development) BM HTTT – Khoa CNTT – ĐHCN tpHCM - 2009 37
38. Mô hình RAD (Rapid Application Development) • Chính là mô hình tăng trưởng với chu kỳ phát triển cực ngắn. • Để đạt được mục tiêu này, RAD dựa trên phương pháp phát triển trên cơ sở thành phần hóa hệ thống cùng với việc tái sử dụng các thành phần thích hợp. • RAD thích hợp cho những hệ thống quản lý thông tin. BM HTTT – Khoa CNTT – ĐHCN tpHCM - 2009 38
39. Mô hình xoắn ốc (Spiral model) BM HTTT – Khoa CNTT – ĐHCN tpHCM - 2009 39
40. Mô hình xoắn ốc (Spiral model) • Phát triển từ mô hình thác nước cho thấy mức độ tổng quát hơn của các pha sản xuất của một sản phẩm. • Đặt trọng tâm phân tích rủi ro và xem xét kế hoạch để giải quyết chúng, thông qua nhiều chu kỳ con nối tiếp được lặp liên tiếp dựa trên bản chất của mô hình lặp. • Mỗi vòng lặp đại diện cho một pha của quá trình phần mềm. Vòng trong cùng tập trung về tính khả thi, vòng kế về định nghĩa yêu cầu, kế đến là thiết kế, • Không có một pha nào được xem là cố định trong vòng xoắn. Mỗi vòng có đủ 4 giai đoạn của chu kỳ phần mềm. BM HTTT – Khoa CNTT – ĐHCN tpHCM - 2009 40
41. Mô hình dựa vào thành phần (Component-Based Model) BM HTTT – Khoa CNTT – ĐHCN tpHCM - 2009 41
42. Case studies • Case study 1: page 33 • Case study 2: page 36 BM HTTT – Khoa CNTT – ĐHCN tpHCM - 2009 42