Your SlideShare is downloading. ×
0
Chuong 2. cnpm
Chuong 2. cnpm
Chuong 2. cnpm
Chuong 2. cnpm
Chuong 2. cnpm
Chuong 2. cnpm
Chuong 2. cnpm
Chuong 2. cnpm
Chuong 2. cnpm
Chuong 2. cnpm
Chuong 2. cnpm
Chuong 2. cnpm
Chuong 2. cnpm
Chuong 2. cnpm
Chuong 2. cnpm
Chuong 2. cnpm
Chuong 2. cnpm
Chuong 2. cnpm
Chuong 2. cnpm
Chuong 2. cnpm
Chuong 2. cnpm
Chuong 2. cnpm
Chuong 2. cnpm
Chuong 2. cnpm
Chuong 2. cnpm
Chuong 2. cnpm
Chuong 2. cnpm
Chuong 2. cnpm
Chuong 2. cnpm
Chuong 2. cnpm
Chuong 2. cnpm
Chuong 2. cnpm
Chuong 2. cnpm
Chuong 2. cnpm
Chuong 2. cnpm
Chuong 2. cnpm
Chuong 2. cnpm
Chuong 2. cnpm
Chuong 2. cnpm
Chuong 2. cnpm
Chuong 2. cnpm
Chuong 2. cnpm
Chuong 2. cnpm
Chuong 2. cnpm
Chuong 2. cnpm
Chuong 2. cnpm
Chuong 2. cnpm
Chuong 2. cnpm
Chuong 2. cnpm
Chuong 2. cnpm
Chuong 2. cnpm
Chuong 2. cnpm
Chuong 2. cnpm
Chuong 2. cnpm
Chuong 2. cnpm
Chuong 2. cnpm
Chuong 2. cnpm
Chuong 2. cnpm
Chuong 2. cnpm
Chuong 2. cnpm
Chuong 2. cnpm
Chuong 2. cnpm
Chuong 2. cnpm
Chuong 2. cnpm
Chuong 2. cnpm
Chuong 2. cnpm
Chuong 2. cnpm
Chuong 2. cnpm
Chuong 2. cnpm
Chuong 2. cnpm
Chuong 2. cnpm
Chuong 2. cnpm
Chuong 2. cnpm
Chuong 2. cnpm
Chuong 2. cnpm
Chuong 2. cnpm
Chuong 2. cnpm
Chuong 2. cnpm
Chuong 2. cnpm
Chuong 2. cnpm
Chuong 2. cnpm
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Chuong 2. cnpm

4,117

Published on

gdfgsdgsdf

gdfgsdgsdf

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
4,117
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
191
Comments
0
Likes
1
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. CHƯƠNG 2. CÁC MÔ HÌNH PHÁT TRIỂN PHẦN MỀM Bộ môn Công nghệ thông tin Trường Đại học Thương mại 1
  • 2. Nội dung2.1. Vòng đời phát triển phần mềm2.2. Các hoạt động phát triển phần mềm2.3. Các mô hình phát triển phần mềm 2.3.1. Mô hình thác nước (Water Fall Model) 2.3.2. Mô hình V 2.3.3. Mô hình bản mẫu 2.3.4. Mô hình phát triển ứng dụng nhanh 2.3.5. Các mô hình tiến hóa 2.3.5.1. Mô hình gia tăng 2.3.5.2. Mô hình xoắn ốc 2.3.5.3. Mô hình xoắn ốc WINWIN 2.3.6. Mô hình phát triển đồng thời 2.3.7. Mô hình hướng thành phần 2.3.7. Mô hình hướng sử dụng lại 2.3.8. Mô hình hợp nhất2.4. Một số lưu ý 2
  • 3. 2.1. Vòng đời phát triển PM Là khoảng thời gian tính từ khi phần mềm được đề xuất cho đến khi bỏ đi: cụ thể là từ khi được đặt hàng, phát triển, sử dụng đến khi bị loại bỏ. Vòng đời phần mềm được phân chia thành các pha chính như xác định yêu cầu, triển khai, kiểm thử, bảo trì (vận hành)... Phạm vi, thứ tự các pha khác nhau tùy theo từng mô hình, dự án cụ thể 3
  • 4. 2.1. Vòng đời phát triển PM(2) Tùy mô hình áp dụng mà việc phân chia các pha, các bước có thể có sự khác nhau: từ 3 đến 20 pha. Xác định yêu cầu Triển khai Kiểm thử (VËn hµnh) Bảo trì Vòng đời phần mềm 4
  • 5. 2.2. Các hoạt động phát triển PM Phân tích tính khả thi Phân tích và đặc tả yêu cầu Thiết kế Mã hóa Kiểm thử Bảo trì 5
  • 6. Phân tích tính khả thi Phân tích tính khả thi – Xác định vấn đề cần giải quyết – Xem xét các giải pháp và kỹ thuật khác nhau (đánh giá ưu nhược điểm của từng giải pháp) – Đánh giá về thời gian, giá thành, nguồn tài nguyên cần thiết – Sản phẩm: tài liệu phân tích 6
  • 7. Phân tích và đặc tả yêu cầu Phân tích và đặc tả yêu cầu 7
  • 8. Phân tích và đặc tả yêu cầu Đặc tả yêu cầu (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. Quy trình xác định yêu cầu bao gồm bốn pha chính: 1. 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. 2. 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ử. 8
  • 9. 3. Đặ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.4. Đá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. 9
  • 10. Phân tích và đặc tả yêu cầu Phân tích và đặc tả yêu cầu – Xác định nhu cầu của khách hàng/người sử dụng Xác định bài toán, chứ không phải là giải pháp – Khó khăn Khách hàng không biết rõ cái họ cần Khách hàng không trình bày rõ cái họ muốn thay đổi – Sản phẩm: tài liệu đặc tả yêu cầu 10
  • 11. Phân tích và đặc tả yêu cầu Phân tích và đặc tả yêu cầu 11
  • 12. Thiết kế phần mềm 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. 12
  • 13. Thiết kế phần mềm Các công việc trong thiết kế phần mềm 13
  • 14. Thiết kế phần mềm Các phương pháp thiết kế Hướng chức năng Hướng đối tượng 14
  • 15. Mã hóa và gỡ rối Mã hóa và gỡ rối – Mã hóa: cài đặt các thiết kế bằng ngôn ngữ lập trình không đơn thuần chỉ là lập trình Viết tài liệu Chuẩn lập trình Lập trình theo cấp Công cụ Quản lý phiên bản – Gỡ rối: phát hiện các lỗi trong quá trình lập trình – Sản phẩm: chương trình 15
  • 16. Kiểm thử Kiểm thử - Đá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. Kiểm thử 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: 16
  • 17. – 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. 17
  • 18. Kiểm thử – 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. – Các công việc cần làm trong quá trình kiểm thử Phát hiện lỗi trong chương trình Lập kế hoạch thực hiện kiểm thử – Tạo các trường hợp kiểm thử – Tiêu chuẩn kiểm thử – Nguồn tài nguyên kiểm thử Mã nguồn được kiểm thử theo tài liệu thiết kế Sản phẩm: báo cáo kiểm thử 18
  • 19. Kiểm thử Các phương pháp kiểm thử – Kiểm thử tĩnh – Kiểm thử động Kiểm thử hộp đen Kiểm thử hộp trắng 19
  • 20. Bảo trì hệ thống Bảo trì hệ thống: – Bảo đảm chương trình vận hành tốt – Cài đặt các thay đổi – Cài đặt các yêu cầu mới – Xử lý các lỗi khi vận hành – Sản phẩm: chương trình 20
  • 21. Cải tiến phần mềm 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. 21
  • 22. 2.3. Các mô hình phát triển PM Hiện nay có rất nhiều mô hình phát triển phần mềm, và thường được phân thành 2 loại: mô hình tuyến tính và mô hình lặp. – Mô hình tuyến tính: các bước được thực hiện tuần tự, không lặp lại. Mô hình thác nước Mô hình V… – Mô hình lặp: các bước có thể thực hiện song song, có thể lặp lại một số bước. Mô hình tiến hóa Mô hình xoắn ốc Mô hình hợp nhất… 22
  • 23. 2.3.2. Mô hình Thác nước Mô hình thác nước (Water Fall Model) 23
  • 24. 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ì. 24
  • 25. 2.3.1. Mô hình Thác nước Là mô hình cổ điển Phương pháp áp dụng 1 lần Điều khiển hiệu quả Phạm vi giới hạn của vòng lặp Vòng đời dài Không thích hợp với các hệ thống không rõ ràng 25
  • 26. Trong mô hình thác nước, năm pha trên phải đượcthực hiện một cách tuần tự; kết thúc pha trước, rồimớ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ăntrong việc thay đổi các pha đã được thực hiện. Giảsử, pha phân tích và xác định yêu cầu đã hoàn tất vàchuyển sang pha kế tiếp, nhưng lúc này lại có sự thayđổi yêu cầu của người sử dụng; thì chỉ còn cách làphải thực hiện lại từ đầu.Mô hình này chỉ thích hợp khi các yêu cầu đã đượctìm hiểu rõ ràng và những thay đổi sẽ được giới hạnmột cách rõ ràng trong suốt quá trình thiết kế. Tuynhiên, trong thực tế có rất ít những hệ thống nghiệpvụ có các yêu cầu ổn định. 26
  • 27. Ưu điểm:– Chỉ phù hợp với các dự án nhỏ hoặc– Yêu cầu xác địnhNhược điểm:– Không phù hợp với dự án lớn– Thời gian thực hiện lâu 27
  • 28. 2.3.2. Mô hình V Bảo trì Phân tích yêu Kiểm thử chấp cầu nhận Thiết kế hệ Kiểm thử hệ thống thống Thiết kế Kiểm thử đơn vị và chương trình tích hợp Lập trình 28
  • 29. 2.3.2. Mô hình V Trong mô hình V: – Các tiến trình kiểm thử được thêm vào – Kết nối kiểm thử với phân tích và thiết kế – Thích hợp với những trường hợp bài toán không nhất quán 29
  • 30. 2.3.3. Mô hình bản mẫu Nghe Khách Tạo / sửa trình bày bản mẫu Khách kiểm tra bản mẫu Mô hình bản mẫu (Prototyping model) 30
  • 31. 2.3.3. Mô hình bản mẫu Mục đích – Xem xét yêu cầu người sử dụng ở giai đoạn ban đầu – Giảm bớt rủi ro và không chắc chắn – Kiểm chứng thiết kế và thực thi Nên thường xuyên trả lời các câu hỏi chuyên biệt; mục đích phải được xác định 31
  • 32. Lợi ích của bản mẫu Học bằng cách làm việc Tăng cường giao tiếp Tăng sự tham gia của người dùng vào dự án Làm rõ các yêu cầu chỉ biết một phần 32
  • 33. Tuần tự làm bản mẫu Tập hợp yêu cầu Thiết kế nhanh Xây dựng bản mẫu Đánh giá của khách hàng Làm mịn Quay lại thiết kế nhanh để điều chỉnh Xây dựng sản phẩm 33
  • 34. Ưu điểm: phù hợp với– Hệ thống rủi ro cao– Yêu cầu không chắc chắn– Giao diện chưa rõ ràng– Chiến lược cài đặt chưa rõ ràng 34
  • 35. Hạn chế:– Khách hàng có thể cho rằng nguyên mẫu là hệ thống thực Mong đợi không thực tế về tiến triển của dự án– Người phát triển có sự chọn lựa không tốt Phù hợp cho nguyên mẫu, nhưng không phù hợp cho hệ thống thực– Nguyên mẫu không giống hoàn toàn hệ thống cuối cùng Khách hàng sẽ có các phản ứng khác nhau 35
  • 36. 2.3.3. Mô hình bản mẫu Mô hình bản mẫu thường được sử dụng khi: – Khi mới rõ mục đích chung chung của phần mềm, chưa rõ chi tiết đầu vào hay xử lý ra sao hoặc chưa rõ yêu cầu đầu ra – Dùng như “Hệ sơ khai” để thu thập yêu cầu người dùng qua các thiết kế nhanh – Các giải thuật, kỹ thuật dùng làm bản mẫu có thể chưa nhanh, chưa tốt, miễn là có mẫu để thảo luận gợi yêu cầu của người dùng 36
  • 37. 2.3.4. Mô hình phát triển ứng dụng nhanh Mô hình phát triển ứng dụng nhanh (Rapid Application Development: RAD) là mô hình phát triển phần mềm gia tăng, tăng dần từng bước (Incrimental software development) với mỗi chu trình phát triển rất ngắn (60- 90 ngày) Xây dựng dựa trên hướng thành phần (Component- based construction) với khả năng tái sử dụng (reuse) Gồm một số nhóm (teams), mỗi nhóm làm 1 RAD theo các pha: Mô hình nghiệp vụ, Mô hình dữ liệu, Mô hình xử lý, Tạo ứng dụng, Kiểm thử và đánh giá (Business, Data, Process, Appl. Generation, Test) 37
  • 38. 2.3.4. Mô hình phát triển ứng dụng nhanh Team #3 Business Business Modeling Modeling Team #2 Data Data Modeling Modeling Business Business Process Process Modeling Modeling Modeling Modeling Team #1 Data Data Application Application Modeling Generation Generation Business Modeling Business Process Process Testing & Testing & Turnover Modeling Modeling Modeling Modeling Turnover Data Application Application Data Generation Modeling Modeling Generation Testing & Testing & Process Process Turnover Turnover Modeling Modeling Application Application Generation Generation Testing & Testing & Turnover Turnover 60 - 90 days 38
  • 39. RAD: Mô hình nghiệp vụLuồng thông tin được mô hình hóa để trả lời các câuhỏi: – Thông tin nào điều khiển xử lý nghiệp vụ ? – Thông tin gì được sinh ra? – Ai sinh ra nó ? – Thông tin đi đến đâu ? – Ai xử lý chúng ? 39
  • 40. RAD: Mô hình tiến trình và dữ liệu Data modeling: các đối tượng dữ liệu cần để hỗ trợ nghiệp vụ (business). Định nghĩa các thuộc tính của từng đối tượng và xác lập quan hệ giữa các đối tượng Process modeling: Các đối tượng dữ liệu được chuyển sang luồng thông tin thực hiện chức năng nghiệp vụ. Tạo mô tả xử lý đễ cập nhật (thêm, sửa, xóa, khôi phục) từng đối tượng dữ liệu 40
  • 41. RAD: Tự sinh ứng dụng và kiểm thử Application Generation: Dùng các kỹ thuật thế hệ 4 để tạo phần mềm từ các thành phần có sẵn hoặc tạo ra các thành phần có thể tái dụng lại sau này. Dùng các công cụ tự động để xây dựng phần mềm Testing and Turnover: Kiểm thử các thành phần mới và kiểm chứng mọi giao diện (các thành phần cũ đã được kiểm thử và dùng lại) 41
  • 42. RAD: Hạn chế ? Cần nguồn nhân lực dồi dào để tạo các nhóm cho các chức năng chính Yêu cầu hai bên giao kèo trong thời gian ngắn phải có phần mềm hoàn chỉnh, thiếu trách nhiệm của một bên dễ làm dự án đổ vỡ RAD không phải tốt cho mọi ứng dụng, nhất là với ứng dụng không thể môđun hóa hoặc đòi hỏi tính năng cao Mạo hiểm kỹ thuật cao thì không nên dùng RAD 42
  • 43. 2.3.5. Mô hình tiến hóa Phần lớn các hệ phần mềm phức tạp đều tiến hóa theo thời gian: môi trường thay đổi, yêu cầu phát sinh thêm, hoàn thiện thêm chức năng, tính năng Các mô hình tiến hóa (evolutionary models) có tính lặp lại. Kỹ sư phần mềm tạo ra các phiên bản (versions) ngày càng hoàn thiện hơn, phức tạp hơn Các mô hình: gia tăng (incremental), xoắn ốc (spiral), xoắn WINWIN (WINWIN spiral) mô hình phát triển đồng thời (concurrent development model) 43
  • 44. Mô hình tiến hóa 44
  • 45. 2.3.5. Mô hình tiến hóa Ưu điểm: phù hợp với – Dự án vừa và nhỏ – Các phần của dự án phức tạp – Các hệ thống có thời gian sống ngắn Hạn chế – Cấu trúc hệ thống tồi – Tiến trình không rõ ràng 45
  • 46. 2.3.5.1. Mô hình gia tăng Mô hình gia tăng (The incremental model): Kết hợp mô hình tuần tự và ý tưởng lặp lại của chế bản mẫu Sản phẩm lõi với những yêu cầu cơ bản nhất của hệ thống được phát triển Các chức năng với những yêu cầu khác được phát triển thêm sau (gia tăng) Lặp lại quy trình để hoàn thiện dần 46
  • 47. 2.3.5.1. Mô hình gia tăng Gia tăng 1Ph©n tÝch ThiÕt kÕ LËp tr×nh KiÓm thö Xuất xưởng 1 System/info. Engineering Gia tăng 2 Ph©n tÝch ThiÕt kÕ LËp tr×nh KiÓm thö Xuất xưởng 2 Gia tăng 3 Ph©n tÝch ThiÕt kÕ LËp tr×nh KiÓm thö Xuất xưởng 3 Gia tăng 4 Ph©n tÝch ThiÕt kÕ LËp tr×nh KiÓm thö XX 4 Calendar time 47
  • 48. Mô hình này được đề xuất dựa trên ý tưởngthay 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ềugiai đoạn, tăng dần. Mỗi giai đoạn là một phầnkế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 đánhthứ tự ưu tiên. Yêu cầu nào có thứ tự ưu tiêncàng cao thì càng ở trong những giai đoạnphát triển sớm hơn. 48
  • 49. Mô hình gia tăng 49
  • 50. Ưu điểm của mô hình phát triển gia tă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ỹ. 50
  • 51. 2.3.5.2. Mô hình xoắn ốc Lập kế hoạch Phân tích rủi ro Giao tiếp khách hàng Khái niệm Thiết kế Làm mới Nâng cấp Khách hàng Xây dựng & đánh giá Xuất xưởng Bảo trì Mô hình xoắn ốc (spiral) 51
  • 52. 2.3.5.2. Mô hình xoắn ốc (Boehm 1987) Chi phí tăng thêmXác định mục đích, Đánh giá lựa chọn;lựa chọn và ràng Phân tích xác định và giảibuộc rủi ro quyết rủi ro Phân tích rủi ro Phân tích rủi ro Bản mẫu Bản mẫu Bản mẫu Lập kế hoạch Chức năng Yêu cầu phần Thiết kế Thiết kế yêu cầu mềm hệ chi tiết thống Lập kế hoạch Kiểm thử yêu phát triển cầu Lập Kế hoạch kiểm trình thử và tích hợp Kiểm thử thiết kế Kiểm thử Phát triển và kiểmKế hoạch cho giai đoạn tiếp Tích hợp và đơn vị chứng sản phẩm Kiểm thử kiểm thử chấp nhận mức tiếp theo 52
  • 53. Trong mô hình xoắn ốc, quy trình phát triển phầnmềm được biểu diễn như một vòng xoắn ốc. Các phatrong 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. 53
  • 54. 2.3.5.2. Mô hình xoắn ốc Nhấn mạnh việc đánh giá các rủi ro Phần mềm được xây dựng theo nhiều chu kỳ. Mỗi chu kỳ tương ứng với một sản phẩm của 1 giai đọan phát triển – Xác định các mục tiêu, giải pháp, ràng buộc – Đánh giá các giải pháp, xác định các nguy cơ và tìm cách giải quyết chúng – Phát triển và kiểm thử sản phẩm của chu kỳ này – Lập kế hoạch cho chu kỳ tiếp theo 54
  • 55. 2.3.5.2. Mô hình xoắn ốc (tiếp) Giao tiếp khách hàng: giữa người phát triển và khách hàng để tìm hiểu yêu cầu, ý kiến Lập kế hoạch: Xác lập tài nguyên, thời hạn và những thông tin khác Phân tích rủi ro: Xem xét mạo hiểm kỹ thuật và mạo hiểm quản lý Thiết kế: Xây dựng một hay một số biểu diễn của ứng dụng 55
  • 56. 2.3.5.2. Mô hình xoắn ốc (tiếp) Xây dựng và xuất xưởng: xây dựng, kiểm thử, cài đặt và cung cấp hỗ trợ người dùng (tư liệu, huấn luyện, . . .) Đánh giá của khách hàng: Nhận các phản hồi của người sử dụng về biểu diễn phần mềm trong giai đoạn kỹ nghệ và cài đặt 56
  • 57. 2.3.5.2. Mô hình xoắn ốc (tiếp) Ưu điểm – Hạn chế rủi ro sớm – Nhận được phản hồi (feedbacks) từ khách hàng sớm – Dễ kiểm soát các mạo hiểm ở từng mức tiến hóa Hạn chế – Khó thuyết phục khách hàng là phương pháp tiến hóa xoắn ốc có thể kiểm soát được – Chưa được dùng rộng rãi như các mô hình tuyến tính hoặc chế thử. 57
  • 58. 2.3.5.2. Mô hình xoắn ốc Mô hình xoắn ốc phù hợp với – Các hệ phần mềm quy mô lớn, các dự án lớn, phức tạp – Hệ thống cần phát triển nhiều phiên bản – Các hệ thống có yêu cầu chưa xác định rõ ràng 58
  • 59. 2.3.5.3. Mô hình xoắn ốc WINWIN Là mô hình xoắn ốc nhằm thỏa hiệp giữa người phát triển và khách hàng, cả hai cùng “Thắng” (win-win) – Khách thì có phần mềm thỏa mãn yêu cầu chính – Người phát triển thì có kinh phí thỏa đáng và thời gian hợp lý Các hoạt động chính trong việc xác định hệ thống: – Xác định cổ đông (stakeholders) – Xác định điều kiện thắng của cổ đông – Thỏa hiệp điều kiện thắng của các bên liên quan 59
  • 60. 2.3.5.3. Mô hình xoắn ốc WINWIN 2. Xác định điều kiện 3a. Hòa hợp điều kiện thắng thắng của cổ đông 3b. Thiết lập mục tiêu mức tiếp và các ràng buộc, dự kiến 1. Xác định mức tiếp của cổ đông 4. Đánh giá tiến trình và dự kiến sản phẩm, giải quyết rủi ro 7. Xét duyệt và đánh giá 6. Kiểm định sản phẩm 5. Xác định mức tiếp của và quy trình sản phâm và quy trình, kể cả phân chia nhỏ 60
  • 61. 2.3.6. Mô hình phát triển đồng thời Mô hình phát triển đồng thời (The concurrent development model): – Xác định mạng lưới những hoạt động đồng thời (Network of concurrent activities) – Các sự kiện (events) xuất hiện theo điều kiện vận động trạng thái trong từng hoạt động – Dùng cho mọi loại ứng dụng và cho hình ảnh khá chính xác về trạng thái hiện trạng của dự án – Thường dùng trong phát triển các ứng dụng khách/chủ (client/server applications): hệ thống và các thành phần (componets) trong hệ thống được phát triển đồng thời. 61
  • 62. 2.3.7. Mô hình hướng thành phầnMô hình hướng thành phần (Component-based model):Gắn với những công nghệ hướng đối tượng (Object-oriented technologies) qua việc tạo các lớp (classes) cóchứa cả dữ liệu và giải thuật xử lý dữ liệuCó nhiều tương đồng với mô hình xoắn ốcVới ưu điểm tái sử dụng các thành phần qua Thư viện /kho các lớp: tiết kiệm 70% thời gian, 80% giá thành.Mô hình hướng thành phần sử dụng UML như mộtchuẩn công nghiệp 62
  • 63. 2.3.7. Mô hình hướng thành phần Lập kế hoạch Phân tích rủi ro Xác định thành phần ứng viênGiao tiếpkhách hàng Xây dựng Tìm bước lặp thứ n thành phần của hệ thống từ thư viện Đặt Lấy thành phần thành phần vào thư viện nếu có Kỹ nghệ Khách hàng Xây dựng & Xây dựng đánh giá Xuất xưởng thành phần nếu kh.có 63
  • 64. 2.3.7. Mô hình hướng sử dụng lại Mô hình này phát triển định hướng sử dụng lại (Reuse) Hệ thống được tích hợp từ các thành phần đã tồn tại hay hệ thống phi thương mại Các giai đoạn của tiến trình – Phân tích thành phần – Cải biến các yêu cầu – Thiết kế hệ thống hướng sử dụng lại – Phát triển và tích hợp 64
  • 65. 2.3.7. Mô hình hướng sử dụng lại Phát triển định hướng sử dụng lại (2)Đặc tả yêu Phân tích Thay đổi Thiết kế HT thành phần yêu cầu dùng lại cầu Phát triển và Thẩm định tích hợp hệ thống Hướng phát triển này rất quan trọng nhưng kinh nghiệm và công cụ còn hạn chế 65
  • 66. 2.3.8. Mô hình hợp nhất Mô hình hợp nhất sử dụng Các kỹ thuật thế hệ 4 (Fourth generation techniques): Tập hợp các công cụ cho phép xác định đặc tính phần mềm ở mức cao, sau đó tự động sinh mã nguồn dựa theo đặc tả đó. Các công cụ 4GT điển hình: ngôn ngữ phi thủ tục cho truy vấn CSDL, tạo báo cáo, xử lý dữ liệu, tương tác màn hình, tạo mã nguồn, khả năng đồ họa bậc cao, khả năng bảng tính, khả năng giao diện Web. Từ thu thập yêu cầu cho đến sản phẩm: đối thoại giữa khách và người phát triển là quan trọng. Không nên bỏ qua khâu thiết kế: 4GT chỉ áp dụng để triển khai thiết kế qua 4GL 66
  • 67. 2.3.8. Mô hình hợp nhất Tiến trình hợp nhất có thể được nhìn dưới hai góc nhìn khác nhau – Góc nhìn quả lý: quan tâm đến lĩnh vực kinh tế, chiến thuật, con người. Tiến trình gồm 4 giai đoạn. – Góc nhìn kỹ thuật: quan tâm đến công nghệ, kiểm tra chất lượng, phương pháp. Tiến trình gồm nhiều bước lặp. 67
  • 68. 2.3.8. Mô hình hợp nhất Góc nhìn quản lý 68
  • 69. 2.3.8. Mô hình hợp nhất Góc nhìn kỹ thuật: các bước lặp – Mỗi bước lặp gồm các hoạt động Đặc tả Phân tích Thiết kế Mã hóa Kiểm thử Cài đặt – Mỗi bước lặp là một tiến trình thác đổ 69
  • 70. 2.3.8. Mô hình hợp nhất Góc nhìn kỹ thuật 70
  • 71. 2.3.8. Mô hình hợp nhất Kết hợp hai góc nhìn 71
  • 72. 2.3.8. Mô hình hợp nhất Mô hình hợp nhất và UML 72
  • 73. 2.3.8. Mô hình hợp nhất Ưu điểm: giảm thời gian phát triển và tăng năng suất lao động. Nhược điểm: 4GT khó dùng hơn ngôn ngữ lập trình, mã khó tối ưu và khó bảo trì cho hệ thống lớn ⇒ cần kỹ năng của kỹ sư phần mềm Trong tương lai: kết hợp 4GT với mô hình hướng thành phần. 73
  • 74. Kết luận Trong thực tế, người ta thường kết hợp nhiều mô hình cho một dự án – Đối với Hệ thống phức tạp, cần chia dự án thành các hệ thống con – Áp dụng mô hình xoắn ốc hay mô hình hợp nhất cho toàn bộ dự án. – Mỗi hệ thống con có thể áp dụng một mô hình khác nhau Áp dụng mô hình nguyên mẫu cho các hệ thống con phức tạp Áp dụng mô hình thác nước cho các hệ thống con khác 74
  • 75. 2.4. Một số lưu ý Lựa chọn mô hình Phụ thuộc vào bài toán, vào môi trường cụ thể Yêu cầu rõ ràng: => Mô hình thác nước Yêu cầu chưa rõ ràng, độ phức tạp cao Yêu cầu có khả năng thay đổi Không chắc chắn về tính hiệu quả, tính khả thi => Làm bản mẫu, mô hình xoắn ốc 75
  • 76. 2.4. Một số lưu ý Tổ hợp các mô hình:Có thể tổ hợp các mô hình để đem lại hiệu quả 76
  • 77. 2.4. Một số lưu ý Lặp tiến trình: Mỗi phần của tiến trình được lặp theo 2 cách tiếp cận • Phát triển tăng • Phát triển xoắn ốc 77
  • 78. 2.4. Một số lưu ý Chuẩn hóa tiến trình: Tăng năng lực của tổ chức phát triển phần mềm ISO 9000-03 (International Standards Organization ) • CMM (Software Engineering Institute) 78
  • 79. 2.4. Một số lưu ý Giảm chi phí phát triển:Sử dụng các phương pháp, công cụ tiên tiến• tái sử dụng: thư viện thương mại,...• tự sinh mã: công cụ tạo giao diện,...• hướng đối tượng: kế thừa, bảo trì• ngôn ngữ bậc cao: năng lực biểu diễn cao 79
  • 80. 2.4. Một số lưu ýThực hiện các pha phát triển: Pha xác định yêu cầu và thiết kế có vai trò quyết định đến chất lượng phần mềm, chiếm phần lớn công sức so với mã hóa, kiểm thử Khi chuyển tiếp giữa các pha phát triển phải thẩm định để đảm bảo lỗi không ảnh hưởng đến pha sau Tài liệu tạo ra ở mỗi pha không chỉ dùng cho pha kế tiếp mà còn dùng để đảm bảo chất lượng của phần mềm và dùng trong khâu bảo trì Cần chuẩn hóa mẫu biểu, cách thức ghi chép, tạo tài liệu nhằm đảm bảo chất lượng phần mềm. 80
  • 81. CÂU HỎI ÔN TẬP1. Phân biệt các mô hình tiến trình2. Khi có yêu cầu phát triển một hệ thống: – Cần lưu ý gì trong việc lựa chọn mô hình tiến trình – Lựa chọn mô hình phù hợp bằng cách nào – Có những chỉ dẫn gì trong việc lựa chọn mô hình3. Xác định tiến trình phát triển như thế nào?4. Vấn đề chuẩn hóa tiến trình – Tìm hiểu và viết báo cáo, trình bày về mô hình phát triển phần mềm (mỗi nhóm 1 mô hình) 81

×