Bài giảng Nhập môn Công nghệ phần mềm - Chương 2: Quy trình phần mềm - Nguyễn Thị Minh Tuyền

pdf 61 trang ngocly 1910
Bạn đang xem 20 trang mẫu của tài liệu "Bài giảng Nhập môn Công nghệ phần mềm - Chương 2: Quy trình phần mềm - Nguyễn Thị Minh Tuyền", để 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:

  • pdfbai_giang_nhap_mon_cong_nghe_phan_mem_chuong_2_quy_trinh_pha.pdf

Nội dung text: Bài giảng Nhập môn Công nghệ phần mềm - Chương 2: Quy trình phần mềm - Nguyễn Thị Minh Tuyền

  1. Quy trình phần mềm Nguyễn Thị Minh Tuyền Nội dung của slide này dựa vào các slide của Ian Sommerville
  2. Nội dung Mô hình quy trình phần mềm Các hoạt động của quy trình Thích nghi với sự thay đổi Quy trình RUP Nguyễn Thị Minh Tuyền Nhập môn CNPM
  3. Nội dung Mô hình quy trình phần mềm Các hoạt động của quy trình Thích nghi với sự thay đổi Quy trình RUP Nguyễn Thị Minh Tuyền Nhập môn CNPM
  4. Quy trình phần mềm v Quy trình phần mềm (software process) là một tập có cấu trúc các hoạt động cần thiết để phát triển một hệ thống phần mềm. v Có nhiều quy trình phần mềm khác nhau. Tuy nhiên, tất cả đều bao gồm những hoạt động: § Đặc tả - Định nghĩa hệ thống làm gì; § Thiết kế và cài đặt – Định nghĩa tổ chức của hệ thống và cài đặt hệ thống; § Kiểm định – Kiểm tra rằng hệ thống đáp ứng được mong muốn của người dùng; § Cải tiến – thay đổi hệ thống để đáp ứng sự thay đổi yêu cầu người dùng. v Mô hình quy trình phần mềm (software process model) là biểu diễn trừu tượng của một quy trình. Nó biểu diễn mô tả của quy trình từ một góc nhìn nào đó. Nguyễn Thị Minh Tuyền 4 Nhập môn CNPM
  5. Mô tả quy trình phần mềm v Khi mô tả về quy trình, ta thường nói về § các hoạt động trong những quy trình này. Ví dụ, đặc tả mô hình dữ liệu, thiết kế giao diện người dùng, ; § và thứ tự của các hoạt động này. v Các mô tả quy trình có thể gồm: § Sản phẩm, kết quả đầu ra của một hoạt động; § Vai trò, phản ánh trách nhiệm của những người tham gia vào quy trình; § Điều kiện trước và điều kiện sau (Pre- and post-conditions), là những điều kiện phải đảm bảo trước và sau khi một hoạt động được thực hiện hay một sản phẩm được tạo ra. Nguyễn Thị Minh Tuyền 5 Nhập môn CNPM
  6. Quy trình hoạch định sẵn và quy trình linh hoạt v Các quy trình hoạch định sẵn (plan-driven process) là các quy trình mà trong đó tất cả các hoạt động được lên kế hoạch trước và tiến độ thực hiện được đánh giá dựa vào kế hoạch này. v Trong các quy trình linh hoạt (agile process), kế hoạch được phát triển dần dần và dễ dàng thay đổi quy trình để đáp ứng sự thay đổi yêu cầu của khách hàng. v Hầu hết các quy trình thực tế đều gồm những phần tử của cả hai phương pháp này. v Không có quy trình phần mềm đúng hay sai! Nguyễn Thị Minh Tuyền 6 Nhập môn CNPM
  7. Các mô hình quy trình phần mềm v Mô hình thác nước (waterfall model) § Mô hình hoạch định sẵn. Các pha đặc tả và phát triển phân biệt và tách rời nhau. v Mô hình phát triển dần dần (incremental development) § Các pha đặc tả, phát triển và thẩm định đan xen nhau. Có thể là mô hình hoạch định sẵn, có thể là mô hình linh hoạt. v CNPM theo hướng tái sử dụng (reuse-oriented software engineering) § Hệ thống được xây dựng từ những component có sẵn. Có thể là hoạch định sẵn, có thể là linh hoạt. v Thực tế, những hệ thống lớn được phát triển bằng cách sử dụng quy trình mà nó kết hợp các phần tử từ những mô hình này. Nguyễn Thị Minh Tuyền 7 Nhập môn CNPM
  8. Mô hình thác nước Requirements definition System and software design Implementation and unit testing Integration and system testing Operation and maintenance Nguyễn Thị Minh Tuyền 8 Nhập môn CNPM
  9. Các pha trong mô hình thác nước v Mô hình thác nước có các pha sau: § Phân tích và định nghĩa yêu cầu § Thiết kế hệ thống và phần mềm § Cài đặt và kiểm thử đơn vị (unit testing) § Kiểm thử tích hợp và kiểm thử toàn hệ thống § Vận hành và bảo trì v Nhược điểm: § khó khăn trong việc thích nghi với sự thay đổi sau khi quy trình đã vào guồng. Về nguyên tắc, pha này phải hoàn thành trước khi bắt đầu pha tiếp theo. Nguyễn Thị Minh Tuyền 9 Nhập môn CNPM
  10. Các vấn đề của mô hình thác nước v Sự phân chia không linh động dự án thành những giai đoạn tách biệt gây khó khăn trong việc đáp ứng sự thay đổi yêu cầu người dùng § Vì vậy, mô hình này chỉ hợp lý khi yêu cầu được hiểu rõ và sự thay đổi khá hạn chế trong suốt quá trình phát triển; § Rất ít những hệ thống thương mại có yêu cầu ổn định. v Mô hình này được sử dụng trong các hệ thống lớn trong đó hệ thống được phát triển tại nhiều địa điểm khác nhau § Bản chất của quy trình hoạch định sẵn của mô hình thác nước giúp cho việc phối hợp trong công việc dễ dàng hơn. Nguyễn Thị Minh Tuyền 10 Nhập môn CNPM
  11. v Một biến thể của mô hình thác nước là phát triển hệ thống theo kiểu hình thức § Sử dụng mô hình toán học để đặc tả hệ thống. § Sử dụng các chuyển đổi toán học để chuyển các đặc tả thành chương trình chạy được sao cho vẫn đảm bảo được tính nhất quán. § Do sử dụng chuyển đổi toán học => đây là một lý do thuyết phục để đảm bảo rằng một chương trình được phát sinh theo cách này nhất quán với đặc tả đưa ra. v Những quy trình phát triển hình thức (sử dụng B-method chẳng hạn) phù hợp với việc phát triển hệ thống có độ tin cậy cao, độ an toàn cao và tính bảo mật cao. § Ví dụ: đường metro 14 ở Paris, hệ thống tàu tự động ở sân bay CDG, Paris, etc. Nguyễn Thị Minh Tuyền 11 Nhập môn CNPM
  12. Phát triển dần dần Concurrent activities Initial Specification version Outline Intermediate description Development versions Final Validation version Nguyễn Thị Minh Tuyền 12 Nhập môn CNPM
  13. Lợi ích của phát triển dần dần v Giảm được chi phí khi đáp ứng sự thay đổi yêu cầu khách hàng § Lượng phân tích và tài liệu phải làm lại được giảm đi nhiều so với mô hình thác nước. v Dễ dàng trong việc lấy phản hồi từ khách hàng. § Khách hàng có thể đưa ra ý kiến dựa trên demo phần mềm và thấy được phần mềm đã được cài đặt đến đâu rồi. v Phân phối và triển khai phần mềm đến khách hàng nhanh hơn. § Khách hàng có thể sử dụng phần mềm sớm hơn so với quy trình thác nước. Nguyễn Thị Minh Tuyền 13 Nhập môn CNPM
  14. Những vấn đề của phát triển dần dần v Quy trình không rõ ràng. v Cấu trúc hệ thống có xu hướng bị giảm đi vì những phần mới của hệ thống được thêm vào § Trừ phi có thêm thời gian và tiền bạc vào để cải thiện hệ thống, nếu không sự thay đổi thường xuyên sẽ phá vỡ cấu trúc của hệ thống. Đáp ứng những thay đổi phần mềm sẽ trở nên khó khăn và tốn kém hơn. Nguyễn Thị Minh Tuyền 14 Nhập môn CNPM
  15. CNPM theo hướng tái sử dụng v Dựa vào việc tái sử dụng một cách có hệ thống § các hệ thống được tích hợp từ những thành phần có sẵn hoặc từ các hệ thống COTS (Commercial-off-the-shelf). v Các giai đoạn của quy trình § Phân tích component; § Bổ sung yêu cầu; § Thiết kế hệ thống với việc tái sử dụng; § Phát triển và tích hợp. v Hiện nay, việc tái sử dụng là phương pháp chuẩn cho việc xây dựng nhiều loại hệ thống thương mại. Nguyễn Thị Minh Tuyền 15 Nhập môn CNPM
  16. CNPM theo hướng tái sử dụng Requirements Component Requirements System design specification analysis modification with reuse Development System and integration validation Nguyễn Thị Minh Tuyền 16 Nhập môn CNPM
  17. Các loại component v Các dịch vụ Web (Web service): được phát triển theo các chuẩn dịch vụ và có sẵn để triệu gọi từ xa. v Các tập các đối tượng được phát triển như một gói (package) tích hợp trong các framework như .NET hay J2EE. v Những hệ thống phần mềm độc lập (COTS): được cấu hình để sử dụng cho một môi trường cụ thể. Nguyễn Thị Minh Tuyền 17 Nhập môn CNPM
  18. Nội dung Mô hình quy trình phần mềm Các hoạt động của quy trình Thích nghi với sự thay đổi Quy trình RUP Nguyễn Thị Minh Tuyền Nhập môn CNPM
  19. Các hoạt động của quy trình v 4 hoạt động quy trình cơ bản - đặc tả, phát triển, thẩm định và cải tiến - được tổ chức khác nhau trong các quy trình phát triển khác nhau § Trong mô hình thác nước, chúng được tổ chức tuần tự. § Trong mô hình phát triển dần dần, chúng được tổ chức đan xen nhau. Nguyễn Thị Minh Tuyền 19 Nhập môn CNPM
  20. Đặc tả phần mềm v Là quy trình thiết lập danh sách các dịch vụ được yêu cầu và các ràng buộc đối với hoạt động của hệ thống và việc phát triển hệ thống. v Quy trình công nghệ yêu cầu (requirements engineering process) § Nghiên cứu khả thi (Feasibility study): Ước lượng xem những yêu cầu của người dùng có khả thi về mặt kỹ thuật và tài chính để xây dựng nên hệ thống hay không. § Thu thập và phân tích yêu cầu (Requirements elicitation and analysis): Các stackholder hệ thống yêu cầu và mong muốn gì từ hệ thống? § Đặc tả yêu cầu (Requirements specification): Định nghĩa chi tiết các yêu cầu. § Requirements validation: Kiểm tra tính hợp lệ của yêu cầu. Nguyễn Thị Minh Tuyền 20 Nhập môn CNPM
  21. Quy trình công nghệ yêu cầu Requirements Feasibility elicitation and study analysis Requirements specification Feasibility Requirements report validation System models User and system requirements Requirements document Nguyễn Thị Minh Tuyền 21 Nhập môn CNPM
  22. Thiết kế và cài đặt phần mềm v Là quy trình chuyển đổi các đặc tả thành hệ thống thực thi được. v Thiết kế phần mềm (software design) § Thiết kế một cấu trúc phần mềm để hiện thực hóa đặc tả; v Cài đặt (implementation) § Dịch cấu trúc đó thành chương trình thực thi được. v Các hoạt động của pha thiết kế và cài đặt thường liên quan đến nhau hoặc có thể đan xen nhau. Nguyễn Thị Minh Tuyền 22 Nhập môn CNPM
  23. Một mô hình chung của quy trình thiết kế Design inputs Platform Requirements Data information specification description Design activities Architectural Interface Component design design design Database design Design outputs System Database Interface Component architecture specification specification specification Nguyễn Thị Minh Tuyền 23 Nhập môn CNPM
  24. Các hoạt động thiết kế v Thiết kế kiến trúc (Architectural design) § Nhận diện cấu trúc toàn hệ thống, những component chính, mối quan hệ giữa các component và chúng được phân tán thế nào. v Thiết kế giao diện (Interface design) § Định nghĩa giao diện giữa các component hệ thống. v Thiết kế component (Component design) § Xem xét từng component hệ thống và thiết kế xem nó hoạt động thế nào. v Thiết kế CSDL (Database design) § Thiết kế các cấu trúc dữ liệu hệ thống và cách chúng được biểu diễn trong CSDL. Nguyễn Thị Minh Tuyền 24 Nhập môn CNPM
  25. Thẩm định phần mềm v Kiểm định (verification) và thẩm định (validation) (V & V) nhằm mục đích chỉ ra rằng § Một hệ thống tuân theo đặc tả của nó; § Thỏa mãn yêu cầu của khách hàng hệ thống. v Bao gồm các quy trình kiểm tra, review và kiểm thử hệ thống (system testing). v Kiểm thử hệ thống bao gồm việc chạy hệ thống sử dụng các test case được viết ra dựa vào đặc tả. v Kiểm thử là hoạt động V&V thường được sử dụng nhất. Nguyễn Thị Minh Tuyền 25 Nhập môn CNPM
  26. Các giai đoạn kiểm thử phần mềm Component Acceptance System testing testing testing Nguyễn Thị Minh Tuyền 26 Nhập môn CNPM
  27. Các giai đoạn kiểm thử phần mềm v Kiểm thử component (Development or component testing) § Các component được kiểm thử một cách độc lập; § Các component có thể là hàm hoặc đối tượng hoặc nhóm đồng nhất các thực thể. v Kiểm thử hệ thống § Kiểm thử toàn bộ hệ thống. v Acceptance testing § Kiểm thử với dữ liệu của khách hàng để kiểm tra rằng hệ thống đáp ứng được yêu cầu của khách hàng. Nguyễn Thị Minh Tuyền 27 Nhập môn CNPM
  28. Các pha kiểm thử trong quy trình hoạch định sẵn Requirements System System Detailed specification specification design design System Sub-system Module and Acceptance integration integration unit code test plan test plan test plan and test Acceptance System Sub-system Service test integration test integration test Nguyễn Thị Minh Tuyền 28 Nhập môn CNPM
  29. Cải tiến phần mềm v Phần mềm vốn dĩ linh hoạt và có thể thay đổi. v Vì yêu cầu thay đổi do môi trường kinh doanh thay đổi, phần mềm hỗ trợ kinh doanh cũng phải cải tiến và thay đổi. v Ranh giới giữa phát triển phần mềm và cải tiến phần mềm ngày càng mờ nhạt đi. Ngày càng ít phần mềm được phát triển hoàn toàn mới. Nguyễn Thị Minh Tuyền 29 Nhập môn CNPM
  30. Cải tiến phần mềm Define system Assess existing Propose system Modify requirements systems changes systems Existing New systems system Nguyễn Thị Minh Tuyền 30 Nhập môn CNPM
  31. Tổng kết v Quy trình phần mềm là một tập có cấu trúc các hoạt động cần thiết để phát triển một hệ thống phần mềm. v Mô hình quy trình phần mềm là biểu diễn trừu tượng của một quy trình. v Các mô hình quy trình tổng quát mô tả tổ chức của các quy trình phần mềm. § Ví dụ: Mô hình thác nước, mô hình phát triển tiến hóa, mô hình phát triển theo hướng tái sử dụng. Nguyễn Thị Minh Tuyền 31 Nhập môn CNPM
  32. Tổng kết v Công nghệ yêu cầu là quy trình phát triển đặc tả phần mềm. v Quy trình thiết kế và cài đặt liên quan đến việc chuyển đổi một đặc tả yêu cầu thành hệ thống phần mềm chạy được. v Thẩm định phần mềm là quy trình kiểm tra rằng hệ thống thỏa mãn đặc tả và đáp ứng được nhu cầu thực của người sử dụng hệ thống. v Cải tiến phần mềm xảy ra khi bạn thay đổi hệ thống phần mềm có sẵn để đáp ứng các yêu cầu mới. Nguyễn Thị Minh Tuyền 32 Nhập môn CNPM
  33. Nội dung Mô hình quy trình phần mềm Các hoạt động của quy trình Thích nghi với sự thay đổi Quy trình RUP Nguyễn Thị Minh Tuyền 33 Nhập môn CNPM
  34. Thích nghi với sự thay đổi v Sự thay đổi là điều hiển nhiên trong những dự án phần mềm lớn § Những thay đổi thương mại dẫn đến việc thay đổi yêu cầu hoặc phát sinh những yêu cầu mới. § Công nghệ mới mở ra khả năng cải thiện việc cài đặt. § Thay đổi platform đòi hỏi thay đổi ứng dụng. v Thay đổi dẫn đến việc làm lại § vì vậy chi phí của việc thay đổi gồm cả chi phí làm lại và chi phí cài đặt tính năng mới. Nguyễn Thị Minh Tuyền 34 Nhập môn CNPM
  35. Giảm thiểu chi phí làm lại v Tránh thay đổi (change avoidance) § Quy trình phần mềm gồm các hoạt động mà nó có thể dự đoán trước những thay đổi có thể xảy ra khi việc làm lại được yêu cầu. § Ví dụ: hệ thống nguyên mẫu (prototype system) có thể dùng để cho khách hàng xem những tính năng chính của hệ thống. v Chấp nhận thay đổi (change tolerance) § Quy trình được thiết kế sao cho thay đổi được thực hiện với chi phí khá thấp. § Thường sử dụng mô hình phát triển dần dần. Nguyễn Thị Minh Tuyền 35 Nhập môn CNPM
  36. Nguyên bản phần mềm v Một nguyên bản (prototype) là phiên bản đầu tiên của một hệ thống được dùng để demo những khái niệm và thử các tùy chọn thiết kế. v Một nguyên bản có thể được sử dụng trong các trường hợp sau: § Trong quy trình công nghệ yêu cầu để giúp cho quá trình thu thập yêu cầu và thẩm định yêu cầu; § Trong quy trình thiết kế để tìm ra các tùy chọn và phát triển thiết kế giao diện người dùng; § Trong quy trình kiểm thử để chạy các kiểm thử back-to- back. Nguyễn Thị Minh Tuyền 36 Nhập môn CNPM
  37. Lợi ích của nguyên bản v Cải thiện khả năng sử dụng hệ thống. v Thoả mãn tốt hơn nhu cầu thực của người dùng. v Cải thiện chất lượng thiết kế. v Cải thiện khả năng bảo trì hệ thống. v Giảm bớt nỗ lực phát triển. Nguyễn Thị Minh Tuyền 37 Nhập môn CNPM
  38. Quy trình phát triển nguyên bản Establish Define prototype prototype Develop Evaluate objectives functionality prototype prototype Prototyping Outline Executable Evaluation plan definition prototype report Nguyễn Thị Minh Tuyền 38 Nhập môn CNPM
  39. Phát triển nguyên bản v Có thể dựa vào các công cụ và ngôn ngữ để phát triển nguyên bản. v Có thể bao gồm cả việc loại bỏ bớt tính năng § Nguyên bản nên tập trung vào những tính năng chưa được hiểu rõ ràng; § Kiểm tra lỗi không nằm trong nguyên bản; § Tập trung vào các yêu cầu chức năng hơn là các yêu cầu phi chức năng. Nguyễn Thị Minh Tuyền 39 Nhập môn CNPM
  40. Throw-away prototypes v Các nguyên bản nên bị loại bỏ sau khi phát triển phần mềm vì chúng không phải là cái cơ bản để phát triển hệ thống: § Khó có thể điều chỉnh hệ thống để đáp ứng được các yêu cầu phi chức năng; § Nguyên bản thường không được tài liệu hóa; § Cấu trúc nguyên bản thường bị phá vỡ do bị thay đổi nhanh; § Nguyên bản có thể không đáp ứng được những tiêu chuẩn chất lượng về mặt tổ chức. Nguyễn Thị Minh Tuyền 40 Nhập môn CNPM
  41. Chuyển giao dần dần(incremental delivery) v Thay vì phân phối hệ thống một lần, việc phát triển và phân phối được chia ra thành từng phần nhỏ (increment). Mỗi phần giao cho khách hàng chứa một phần tính năng được yêu cầu. v Những yêu cầu người dùng được ưu tiên và những yêu cầu có độ ưu tiên cao nhất sẽ được đặt trong các phần đầu tiên. v Trong quá trình phát triển, việc phân tích yêu cầu cho phần tiếp theo có thể được tiến hành nhưng thay đổi yêu cầu cho phần hiện tại không được chấp nhận. Nguyễn Thị Minh Tuyền 41 Nhập môn CNPM
  42. Phát triển dần dần và chuyển giao dần dần v Phát triển dần dần § Phát triển từng phần hệ thống và đánh giá mỗi phần trước khi tiến hành phát triển phần tiếp theo; § Được sử dụng trong các phương pháp linh hoạt; § Đánh giá được thực hiện bởi đại diện người sử dụng/ khách hàng. v Chuyển giao dần dần § Triển khai một phần để sử dụng cho người dùng cuối; § Đánh giá thực tế hơn; Nguyễn Thị Minh Tuyền 42 Nhập môn CNPM
  43. Chuyển giao dần dần Define outline Assign requirements Design system Develop system requirements to increments architecture increment System incomplete? Validate Integrate Validate Deploy increment increment system increment System complete? Final system Nguyễn Thị Minh Tuyền 43 Nhập môn CNPM
  44. Ưu điểm của chuyển giao dần dần v Khách hàng sớm được bàn giao sản phẩm (từng phần). v Các phần đầu được xem như một nguyên bản để hỗ trợ cho việc làm lộ rõ những yêu cầu cho phần sau. v Nguy cơ thất bại toàn hệ thống là thấp. v Duy trì được ưu điểm của phát triển từng phần, do đó dễ thích nghi với sự thay đổi của hệ thống. v Những dịch vụ hệ thống có độ ưu tiên cao nhất sẽ được kiểm thử nhiều nhất § Khách hàng ít gặp lỗi phần mềm ở những phần quan trọng của hệ thống. Nguyễn Thị Minh Tuyền 44 Nhập môn CNPM
  45. Mô hình xoắn ốc Boehm v Quy trình được biểu diễn như một đường xoắn ốc hơn là một chuỗi tuần tự các hoạt động với các bước quay lui. v Mỗi vòng lặp trong đường xoắn ốc biểu diễn một pha của quy trình. v Không có những pha cố định như đặt tả hay thiết kế, các vòng lặp trong đường xoắn ốc được chọn theo nhu cầu. v Rủi ro được đánh giá rõ ràng và được giải quyết trong suốt quy trình. Nguyễn Thị Minh Tuyền 45 Nhập môn CNPM
  46. Quy trình phần mềm của mô hình xoắn ốc Boehm Determine objectives, Evaluate alternatives, alternatives and identify, resolve risks constraints Risk analysis Risk analysis Risk analysis Opera- Prototype 3 tional Prototype 2 protoype Risk analysis Proto- REVIEW type 1 Requirements plan Simulations, models, benchmarks Life-cycle plan Concept of Operation S/W requirements Product design Detailed design Development Requirement plan validation Code Unit test Integration Design and test plan V&V Integration Plan next phase test Acceptance Service test Develop, verify next-level product Nguyễn Thị Minh Tuyền 46 Nhập môn CNPM
  47. Các phân khu (sector) của mô hình xoắn ốc v Thiết lập mục tiêu § Xác định mục tiêu cụ thể của pha. v Đánh giá và giảm thiểu rủi ro § Rủi ro được đánh giá và các hoạt động được tiến hành để giảm thiểu các rủi ro chính. v Phát triển và thẩm định § Một mô hình phát triển cho hệ thống được chọn, đây có thể là một trong các mô hình tổng quát. v Lập kế hoạch § Dự án được duyệt và pha tiếp theo trong đường xoắn ốc được lên kế hoạch. Nguyễn Thị Minh Tuyền 47 Nhập môn CNPM
  48. Sử dụng mô hình xoắn ốc v Ưu điểm: § Là phương pháp thực tế để phát triển các hệ thống phần mềm lớn. § Giúp các kỹ sư hiểu rõ và tương tác tốt hơn với các nguy cơ tại mỗi mức tiến hóa. § Cho phép áp dụng nguyên bản tại bất cứ giai đoạn tiến hóa nào. § Giảm được các nguy cơ trước khi nó trở thành vấn đề của hệ thống. v Nhược điểm: § Không phải là “thuốc chữa bách bệnh”. § Khó khăn trong việc thuyết phục khách hàng rằng phương pháp này có thể điều khiển được. § Cần chuyên gia đánh giá về nguy cơ và dựa vào chuyên gia để thành công. Nếu một nguy cơ lớn không được tìm ra và quản lý được, các vấn đề về hệ thống sẽ xảy ra. Nguyễn Thị Minh Tuyền 48 Nhập môn CNPM
  49. Nội dung Mô hình quy trình phần mềm Các hoạt động của quy trình Thích nghi với sự thay đổi Quy trình RUP Nguyễn Thị Minh Tuyền 49 Nhập môn CNPM
  50. Quy trình RUP v The Rational Unified Process v Đây là một quy trình tổng quát bắt nguồn từ UML và Unified Software Development Process. v Kết hợp các khía cạnh của ba mô hình quy trình tổng quát. v Thường mô tả ba khía cạnh § Khía cạnh động (dynamic perspective): chỉ ra các pha theo thời gian; § Khía cạnh tĩnh (static perspective): chỉ ra các hoạt động của quy trình; § Khía cạnh thực tiễn (practice perspective): đề xuất những thực tiễn tốt. Nguyễn Thị Minh Tuyền 50 Nhập môn CNPM
  51. Các pha của RUP Phase iteration Inception Elaboration Construction Transition Nguyễn Thị Minh Tuyền 51 Nhập môn CNPM
  52. Các pha của RUP v Khởi động (Inception) § Thiết lập business case cho hệ thống. v Phát triển (Elaboration) § Nghiên cứu các vấn đề và phát triển kiến trúc hệ thống. v Xây dựng (Construction) § Thiết kế hệ thống, lập trình và kiểm thử. v Chuyển tiếp (Transition) § Triển khai hệ thống. Nguyễn Thị Minh Tuyền 52 Nhập môn CNPM
  53. Vòng lặp trong RUP v Lặp trong từng pha (In-phase iteration) § Mỗi pha được lặp lại với kết quả được phát triển tăng dần. v Lặp qua các pha (Cross-phase iteration) § Việc lặp có thể được thực hiện qua toàn bộ các pha. Nguyễn Thị Minh Tuyền 53 Nhập môn CNPM
  54. Các workflow tĩnh trong RUP Workflow Description Business The business processes are modelled modelling using business use cases. Requirements Actors who interact with the system are identified and use cases are developed to model the system requirements. Analysis and A design model is created and documented design using architectural models, component models, object models and sequence models. Implementation The components in the system are implemented and structured into implementation sub-systems. Automatic code generation from design models helps accelerate this process. Nguyễn Thị Minh Tuyền 54 Nhập môn CNPM
  55. Các workflow trong RUP Workflow Description Testing Testing is an iterative process that is carried out in conjunction with implementation. System testing follows the completion of the implementation. Deployment A product release is created, distributed to users and installed in their workplace. Configuration and This supporting workflow managed changes to the change system. management Project This supporting workflow manages the system management development. Environment This workflow is concerned with making appropriate software tools available to the software development team. Nguyễn Thị Minh Tuyền 55 Nhập môn CNPM
  56. Nguồn: Nguyễn Thị Minh Tuyền 56 Nhập môn CNPM
  57. Ưu điểm của RUP v Phát triển phần mềm theo vòng lặp § Các phần được lên kế hoạch dựa vào độ ưu tiên của khách hàng và phân phối những phần có độ ưu tiên cao nhất trước. v Quản lý yêu cầu § Viết tài liệu một cách rõ ràng cho các yêu cầu khách hàng và theo dõi sự thay đổi của những yêu cầu này. v Sử dụng kiến trúc dựa vào component § Tổ chức hệ thống như một tập các component có thể tái sử dụng. Nguyễn Thị Minh Tuyền 57 Nhập môn CNPM
  58. Ưu điểm của RUP v Mô hình hóa phần mềm một cách trực quan § Sử dụng các mô hình đồ họa UML để biểu diễn các góc nhìn tĩnh và động của phần mềm. v Kiểm tra chất lượng phần mềm § Đảm bảo rằng phần mềm đáp ứng được các chuẩn chất lượng về mặt tổ chức. v Điều khiển các thay đổi phần mềm § Quản lý những thay đổi phần mềm sử dụng những hệ thống quản lý thay đổi và các công cụ quản lý cấu hình. Nguyễn Thị Minh Tuyền 58 Nhập môn CNPM
  59. Tổng kết v Quy trình nên có các hoạt động để đối phó với sự thay đổi. Có thể có pha nguyên bản để hạn chế những thay đổi không cần thiết trên yêu cầu và thiết kế. v Quy trình có thể được cấu trúc hóa cho phát triển và phân phối dần dần sao cho nhưng thay đổi có thể được thực hiện mà không phá vỡ toàn bộ hệ thống. v RUP là một mô hình quy trình tổng quát hiện đại được tổ chức thành các pha (khởi động, phát triển, xây dựng và chuyển tiếp). Nguyễn Thị Minh Tuyền 59 Nhập môn CNPM
  60. Câu hỏi? Nguyễn Thị Minh Tuyền Nhập môn CNPM