Bài giảng Nhập môn công nghệ phần mềm (Introduction to software engineering): Chương 2 - Nguyễn Nhất Hải

Chia sẻ: _ _ | Ngày: | Loại File: PDF | Số trang:14

Thêm vào BST

Báo xấu

31
lượt xem 3
download

Download Vui lòng tải xuống để xem tài liệu đầy đủ

Chương 2 - Vòng đời phần mềm. Chương 2 cung cấp cho người học những kiến thức cơ bản về: Định nghĩa vòng đời phần mềm, quy trình phát triển phần mềm, một số mô hình phát triển phần mềm, đánh giá sản phẩm và quy trình. Mời các bạn cùng tham khảo.

Chủ đề:

Bình luận(0) Đăng nhập để gửi bình luận!

Lưu

Nội dung Text: Bài giảng Nhập môn công nghệ phần mềm (Introduction to software engineering): Chương 2 - Nguyễn Nhất Hải

Chương 2: Vòng đời phần mềm • 1. Định nghĩa NHẬP MÔN • 2. Quy trình phát triển phần mềm CÔNG NGHỆ PHẦN MỀM • 3. Một số mô hình phát triển phần mềm – 3.1. Mô hình CMM (INTRODUCTION TO SOFTWARE – 3.2. Mô hình tuyến tính om – 3.3. Mô hình chế thử ENGINEERING) – 3.4. Mô hình phát triển ứng dụng nhanh – 3.5. Các mô hình tiến hóa .c – 3.6. Mô hình hướng thành phần – 3.7. Mô hình RUP – 3.8. Các kỹ thuật thế hệ thứ 4 ng • 4. Đánh giá sản phẩm và quy trình co 1 2 an 1 2 th Chương 2: Vòng đời phần mềm o ng Vòng đời phần mềm du 2.1. Định nghĩa (Vòng đời phần mềm) • Mọi sản phẩm phần mềm đều có vòng đời. – Vòng đời phần mềm là thời kỳ tính từ khi phần • Vòng đời thường khá dài — một số sản phẩm u mềm được sinh (tạo) ra cho đến khi chết đi (từ lúc phần mềm đã “tồn tại” được 30 năm. cu hình thành đáp ứng yêu cầu, vận hành, bảo dưỡng cho đến khi loại bỏ không đâu dùng) • Vòng đời có thể được rút ngắn do tiến bộ – Quy trình phần mềm (vòng đời phần mềm) được công nghệ phân chia thành các pha chính: phân tích, thiết kế, chế tạo, kiểm thử, bảo trì. Biểu diễn các pha có khác nhau theo từng người 3 4 3 4 CuuDuongThanCong.com https://fb.com/tailieudientucntt
Các phương pháp luận và kỹ thuật Các pha trong vòng đời PM cho từng pha • Một cách rõ ràng hoặc rõ ràng, tất cả các sản phẩm phần mềm đều trải qua ít nhất các giai Tên pha Nội dung nghiệp vụ Phương pháp, kỹ thuật Xác định Đặc tả yêu cầu người dùng đoạn sau: yêu cầu Xác định yêu cầu phần mềm Phân tích cấu trúc hóa – Yêu cầu — xác định nhu cầu của khách hàng và các Thiết kế Thiết kế cơ bản phần mềm Thiết kế cấu trúc hóa ràng buộc của sản phẩm hệ thống Thiết kế cấu trúc ngoài của phần mềm om – Thiết kế — xác định cấu trúc / tổ chức của hệ thống Thiết kế Là thiết kế chi tiết: Thiết kế cấu trúc bên trong Lập trình cấu trúc phần mềm] chương trình của phần mềm (đơn vị chương trình hoặc Phương pháp Jackson môđun) Phương pháp Warnier – Mã hóa — viết phần mềm .c Lập trình Mã hóa bởi ngôn ngữ lập trình Mã hóa cấu trúc hóa – Kiểm thử — vận hành hệ thống để tìm và loại bỏ các Đảm bảo Phương pháp kiểm thử khiếm khuyết chất lượng Kiểm tra chất lượng phần mềm đã phát triển chương trình ng – Bảo trì — sửa chữa và nâng cao sản phẩm sau khi Vận hành Sử dụng, vận hành phần mềm đã phát triển. Chưa cụ thể khách hàng triển khai Bảo trì Biến đổi, điều chỉnh phần mềm co 5 6 an 5 6 th Các mô hình vòng đời phần mềm o ng 2. Quy trình phát triển phần mềm du • Quá trình là một tập hợp các hoạt động, với các đầu vào và đầu ra được xác định rõ ràng, để hoàn thành một số nhiệm Khung quy trình chung (Common process framework) vụ. u • Mô hình vòng đời là một mô tả về một quá trình thực hiện Hoạt động khung (Framework activities) cu một sản phẩm phần mềm trong toàn bộ hoặc một phần Tập tác vụ (Task sets) vòng đời của nó. Tác vụ (Tasks) – Các mô hình vòng đời có xu hướng tập trung vào các pha chính của chu kỳ và mối quan hệ của chúng với các pha khác. Điểm quan trọng (milestones),sản phẩm chuyển – Các nghiên cứu gần đây về quy trình phần mềm đã xem xét chi giao (deliverables) tiết nhiều khía cạnh của việc phát triển và bảo trì. – Mô hình vòng đời là một mô tả quy trình phần mềm, nhưng Điểm Kiểm Tra Chất Lượng thuật ngữ mô hình vòng đời có trước các cuộc thảo luận về quy (SQA points) trình phần mềm. Các hoạt động giám sát, đánh giá kỹ thuật, đảm bảo chất lượng phần mềm, quản lý cấu hình, quản lý rủi ro, ... (Umbrella activities) 7 8 7 8 CuuDuongThanCong.com https://fb.com/tailieudientucntt
3. Một số mô hình phát triển PM 3.1. Mô hình khả năng thuần thục 3.1. Capability Maturity Model (CMM by SEI): Tại sao phải sử dụng mô hình CMM trong công nghệ làm phần mềm? Mô hình khả năng thuần thục • Khó khăn khi không sử • Thuận lợi khi sử dụng dụng CMM CMM – Các khái niệm • Các tiến trình phần mềm thường • Dễ dàng quản lý phát triển phần mềm. om – Tại sao sử dụng mô hình CMM bị thay đổi cập nhật mà không có sự chuần bị trước. Các tiến trình được cập nhật qua sự điều khiển của các nhà phần tích và – Các thức sử dụng mô hình • Đặc tả một tiến trình phần mềm không chặt chẽ, dẫn đến sự kiểm thử. • Vai trò, trách nhiệm của mỗi thành .c khủng hoảng khi thực hiện một viên trong các tiến trình được phân dự án. định rõ ràng. • Thiếu cơ sở để đánh giá chất • Quản lý chất lượng của phần mềm, lượng phần mềm, để đưa ra thoả mãn các yêu cầu khách hàng. Có ng phương thức tiến hành và cách cơ sơ chuẩn xác đánh giá chất lượng, giải quyết các vấn đề phát sinh. thời gian, chi phí và phân tích dự án và các tiến trình. co 9 10 an 9 10 th Các khái niệm cơ bản trong CMM o ng Thực thi tiến trình phần mềm (Software Process Performance) du • Tiến trình (Process) • Thực thi tiến trình phần mềm cho biết kết quả – Một tiến trình phần mềm là một tập hợp các hành thực tế của một tiến trình phần mềm. động, phương thức, thực hành, thay đổi mà người ta u dùng để duy trì và phát triển phần mềm cũng như các • Hướng tới kết quả đạt được còn khả năng tiến cu thành phần liên quan tới chúng (ví dụ: kế hoạch dự án, thiết kế, lập trình, kiểm thử, tài liệu hướng dẫn...). trình phần mềm cho thấy kết quả có thể mong • Khả năng tiến trình phần mềm đợi. (Software Process Capability) • Do phụ thuộc vào đặc trưng của dự án và từng – Cho biết phạm vi kết quả có thể mong đợi của một trường hợp cụ thể, nên kết quả thực tế thường tiến trình phần mềm. – Dự đoán khả năng làm dự án phần mềm tiếp theo của không phản ánh đầy đủ khả năng tiến trình của công ty. một công ty. 11 12 11 12 CuuDuongThanCong.com https://fb.com/tailieudientucntt
Độ thuần thục của tiến trình PM Mô hình chi tiết các thành phần trong (Software process maturity) cấu trúc CMM. Mức độ thuần nhận được từ thục • Chỉ rõ một tiến trình phần mềm được xác chỉ ra Các vùng tiến tổ chức bởi định, quản lý, đánh giá, điều khiển, đạt hiệu trình chính Khả năng om quả một cách rõ ràng. tiến trình đạt được Các tính năng phổ nhận được từ biến • Cho biết khả năng phát triển, chỉ ra giá trị của .c Các mục tiêu ánh xạ Các thực hành tiến trình phần mềm, tính vững chắc của dự chính án. Thực thi hoặc mô tả ng thể chế hoá Cơ sỏ hạ tầng hoặc các hoạt động co 13 14 an 13 14 th Mô hình 5 mức của CMM Tiến trình phần mềm mang tính chất o ng Mô hình 5 mức của CMM Có sự cải tiến hơn, chiến lược du tuỳ tiện, lộn xộn, có ít tiến trình quản lý dự án vµ thủ tục để thực được xác định trước, hiệu quả của thi chiến lược ấy được thiết lập. công việc mang tính riêng lẻ. Các kế hoạch và quản lý dự án Khó có được một môi trường làm mới được dựa trên những kinh việc ổn định. Kế hoạch và ngân sách, tiến trình cải Cải tiến nghiệm của dự án cũ. Tiến trình cải Cải tiến u chất lượng sản phẩm và vận hành tiến liên tục (5) tiến liên tục (5) không thể dự đoán trước được. cu Tiến trình dự Được quản lý Tiến trình dự Được quản lý đoán được (4) đoán được (4) Tiến trình ổn định, Được định nghĩa Tiến trình ổn định, Được định nghĩa chuẩn (3) chuẩn (3) Tiến trình có Có tính lặp lại Tiến trình có Có tính lặp lại kỷ luật (2) Quá trình vận hành phụ thuộc vào khả năng của từng cá kỷ luật (2) Kết quả là đưa được những hiệu quả quản lý tiến trình của nhân riêng lẻ, và thường xuyên thay đổi do phụ thuộc vào kỹ một dự án nµy vào một dự án khác. Điều này cho phép lặp năng, trình độ hiểu biết và các hoạt động của từng thành lại (repeatable) những thành công đối với một dự án tương Ban đầu viên trong dự án. Ban đầu tự mặc dù có thể các dự án này cũng có những điểm khác (1) (1) biệt. 15 16 15 16 CuuDuongThanCong.com https://fb.com/tailieudientucntt
Mô hình 5 mức của CMM Mô hình 5 mức của CMM Lập được tài liệu tiến trình tiêu Mục tiêu là điều khiển tiến trình. chuẩn đối với việc phát triển và Các tiến trình phần mềm được bảo trì phần mềm có tổ chức, bao quản lý để vận hành ổn định, an gồm cả công nghệ phần mềm, các toàn. Có những đánh giá phần tiến trình quản lý, và các tiến trình mềm và chất lượng, hiệu quả các tích hợp với nhau (nghĩa rằng đầu Tiến trình cải Cải tiến hoạt động trong tiến trình. Tiến trình cải Cải tiến ra của một tiến trình sẽ là đầu vào tiến liên tục (5) tiến liên tục (5) của tiến trình tiếp theo ). Tiến trình dự Được quản lý Tiến trình dự Được quản lý om đoán được (4) đoán được (4) Tiến trình ổn định, Được định nghĩa Tiến trình ổn định, Được định nghĩa (3) (3) .c chuẩn chuẩn Tiến trình có Có tính lặp lại Tiến trình có Có tính lặp lại kỷ luật (2) Một tiến trình được định nghĩa tốt gồm có các tính chất như kỷ luật (2) Do các tiến trình ổn định và được đánh giá đúng nên khi có ng có tiêu chuẩn, đầu vào, tiêu chuẩn và thủ tục rõ ràng để tiến các trường hợp ngoại lệ, sẽ xác định và chỉ rõ những nguyên hành công việc, kiểm tra các đầu ra. nhân gây ra biến đổi. Ban đầu Ban đầu (1) (1) co 17 18 an 17 18 th 18 Vùng tiến trình chính Mô hình 5 mức của CMM Tiếp tục cải tiến tiến trình, có thể o ng KPA (Key Process Area) du xác định được những điểm mạnh và điểm yếu của tiến trình, có khả 7. Xem xét ngang nhau năng phân tích các khiếm khuyết, LEVEL 2: Có thể lặp 8. Hợp tác giữa các 16. xác định các nguyên nhân gây ra 1. Quản lý cấu hình nhóm Quản lý thay đổi để tránh các khiếm khuyết này. Tiến trình cải Cải tiến phần mềm 9. Kỹ thuật sản phẩm tiến trình u tiến liên tục (5) 2. Đảm bảo chất phần mềm 14. 17. Quản lý chất cu lượng phần mềm 10. Quản lý phần mềm Quản lý thay đổi lượng phần mềm tích hợp Tiến trình dự Được quản lý 3. Quản lý hợp đồng 15. công nghệ con phần mềm 11. Chương trình huấn 18. đoán được (4) 4. Theo dõi và giám luyện Quản lý quá trình Phòng ngừa khiêm 12. Định nghĩa tiến trình định lượng sát dự án phần mềm khuyết Tiến trình ổn định, Được định nghĩa 5. Lập kế hoạch dự tổ chức (3) án phần mềm 13. Trọng tâm tiến trình chuẩn 6. Quản lý yêu cầu tổ chức Tiến trình có Có tính lặp lại MỨC 3: Được định nghĩa kỷ luật (2) MỨC 4: Được quản lý Ban đầu MỨC 5: Cải tiến (1) 19 20 19 20 CuuDuongThanCong.com https://fb.com/tailieudientucntt
Khả năng nhìn nhận tại mỗi mức Khả năng tiến trình và dự đoán theo thuần thục các mức của CMM • Khi mức độ thuần thục tăng, sự sai khác giữa kết quả đạt được và kết quả dự tính giảm xuống. • Khi mức độ thuần thục tăng, độ biến động của kết quả thực tế so với kết quả đề ra giảm xuống. om • Khi mức độ thuần thục tăng thì các kết quả sẽ được cải thiện. Đó là, chi phí giảm, thời gian phát .c triển ngắn hơn, chất lượng và năng suất tăng. ng co 21 22 an 21 22 th Những điểm chung của 2 phương Cách thức sử dụng mô hình CMM o ng thức sử dụng CMM du • Định giá tiến trình phần mềm (Software process Câu hỏi thuần assessments ) xác định trạng thái của tiến trình Lựa chọn thục Phân tích phần mềm hiện tại của tổ chức, xác định mức độ đội trả lời u ưu tiên đối với các vấn đề có liên quan tới tiến Các mẫu CMM cu trình phần mềm khi xử lý chúng và xây dựng hệ thống hỗ trợ phát triển tiến trình phần mềm. (1) (2) (3) • Đánh giá khả năng phần mềm (Software Hồ sơ KPA capability evaluations) xác định các nhà thầu có Thăm tại chỗ Tìm kiếm đủ tư cách triển khai một dự án phần mềm hoặc Phỏng vấn và quản lý hiện trạng của một hệ thống phần mềm xem xét tài Dựa trên CMM đã có sẵn. liệu (4) (5) (6) 23 24 23 24 CuuDuongThanCong.com https://fb.com/tailieudientucntt
3.2. Mô hình tuyến tính Mô hình tuyến tính Tạo mã / lập trình (Code generation / programming): Kiểm thử (Testing): Kiểm tra các chương • Công nghệ học Hệ thống / Thông tin và mô hình hóa Chuyển thiết kế thành chương trình máy tính bởi trình và môđun cả về lôgic bên trong và (System / Information engineering and modeling): ngôn ngữ nào đó. Nếu thiết kế đã được chi tiết hóa thì lập trình có thể chỉ thuần túy cơ học chức năng bên ngoài, nhằm phát hiện ra lỗi và đảm bảo với đầu vào xác định thiết lập các yêu cầu, ánh xạ một số tập con các yêu thì cho kết quả mong muốn cầu sang phần mềm trong quá trình tương tác giữa om phần cứng, người và CSDL .c Phân tích Thiết kế Lập trình Kiểm thử Phân tích Thiết kế Lập trình Kiểm thử ng Công nghệ học Công nghệ học Hệ thống / Thông tin co Hệ thống / Thông tin 25 26 an 25 26 th Mô hình tuyến tính o ng Điểm yếu của Mô hình tuyến tính du • Hỗ trợ / Bảo trì (Support / Maintenance): Đáp • Thực tế các dự án ít khi tuân theo dòng tuần ứng những thay đổi, nâng cấp phần mềm đã tự của mô hình, mà thường có lặp lại (như mô u phát triển do sự thay đổi của môi trường, nhu hình của Boehm) cu cầu • Khách hàng ít khi tuyên bố rõ ràng khi nào xong hết các yêu cầu • Khách hàng phải có lòng kiên nhẫn chờ đợi Phân tích Thiết kế Lập trình Kiểm thử thời gian nhất định mới có sản phẩm. Nếu Công nghệ học phát hiện ra lỗi nặng thì là một thảm họa! Hệ thống / Thông tin 27 28 27 28 CuuDuongThanCong.com https://fb.com/tailieudientucntt
3.3. Mô hình chế thử (Prototyping model) Mô hình chế thử: Khi nào ? • 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 Nghe Khách Tạo / sửa om trình bày bản mẫu • 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á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 để ng Khách kiểm tra bản mẫu thảo luận gợi yêu cầu của người dùng co 29 30 an 29 30 th 3.4. Mô hình phát triển ứng dụng nhanh (Rapid Application Development: RAD) o ng Mô hình phát triển ứng dụng nhanh Team #3 Mô hình du nghiệp vụ • Là quy trình phát triển phần mềm gia tăng, tăng dần Team #2 Mô hình dữ liệu Mô hình từng bước (Incremental software development) với nghiệp vụ Mô hình tiến trình mỗi chu trình phát triển rất ngắn (60-90 ngày) Mô hình u Tạo Team #1 ứng dụng dữ liệu cu Mô hình Mô hình Kiểm thử • Xây dựng dựa trên hướng thành phần (Component- nghiệp vụ &Turnover tiến trình based construction) với khả năng tái sử dụng (reuse) Mô hình Tạo ứng dụng • Gồm một số nhóm (teams), mỗi nhóm làm 1 RAD theo dữ liệu Kiểm thử Mô hình các pha: Mô hình nghiệp vụ, Mô hình dữ liệu, Mô hình tiến trình &Turnover xử lý, Tạo ứng dụng, Kiểm thử và đánh giá (Business, Tạo Data, Process, Appl. Generation, Test) ứng dụng Kiểm thử &Turnover 31 60 - 90 days 31 32 CuuDuongThanCong.com https://fb.com/tailieudientucntt
RAD: Business modeling RAD: Mô hình dữ liệu và tiến trình • Luồng thông tin được mô hình hóa để trả lời • Mô hình dữ liệu (Data modeling): các đối tượng các câu hỏi: dữ liệu cần để hỗ trợ nghiệp vụ (business). Định – Thông tin nào điều khiển xử lý nghiệp vụ ? 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 om – Thông tin gì được sinh ra? – Ai sinh ra nó ? • Mô hình tiến trình (Process modeling): Các đối tượng dữ liệu được chuyển sang luồng thông tin .c – Thông tin đi đến đâu ? thực hiện chức năng nghiệp vụ. Tạo mô tả xử lý – Ai xử lý chúng ? đễ cập nhật (thêm, sửa, xóa, khôi phục) từng đối ng tượng dữ liệu co 33 34 an 33 34 th RAD: Tạo ứng dụng và kiểm thử o ng RAD: Hạn chế ? du • Tạo ứng dụng (Application Generation): Dùng • Cần nguồn nhân lực dồi dào để tạo các nhóm cho các kỹ thuật thế hệ 4 để tạo phần mềm từ các các chức năng chính u thành phần có sẵn hoặc tạo ra các thành phần • Yêu cầu hai bên giao kèo trong thời gian ngắn cu có thể tái dụng lại sau này. Dùng các công cụ phải có phần mềm hoàn chỉnh, thiếu trách nhiệm tự động để xây dựng phần mềm của một bên dễ làm dự án đổ vỡ • Kiểm thử (Testing and Turnover): Kiểm thử các • RAD không phải tốt cho mọi ứng dụng, nhất là với thành phần mới và kiểm chứng mọi giao diện ứng dụng không thể môđun hóa hoặc đòi hỏi tính (các thành phần cũ đã được kiểm thử và dùng lại) năng cao • Mạo hiểm kỹ thuật cao thì không nên dùng RAD 35 36 35 36 CuuDuongThanCong.com https://fb.com/tailieudientucntt
Mô hình gia tăng 3.5. Các mô hình tiến hóa (The incremental model) • Phần lớn các hệ phần mềm phức tạp đều tiến hóa theo • Kết hợp mô hình tuần tự và ý tưởng lặp lại của 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 chế bản mẫu • Các mô hình tiến hóa (evolutionary models) có tính lặp • Sản phẩm lõi với những yêu cầu cơ bản nhất lại. Kỹ sư phần mềm tạo ra các phiên bản (versions) ngày om của hệ thống được phát triển càng hoàn thiện hơn, phức tạp hơn • Các mô hình tiêu biểu: • Các chức năng với những yêu cầu khác được .c – Gia tăng (Incremental) phát triển thêm sau (gia tăng) – Xoắn ốc (Spiral) • Lặp lại quy trình để hoàn thiện dần ng – Xoắn ốc WINWIN (WINWIN spiral) – Phát triển đồng thời (Concurrent development) co 37 38 an 37 38 th Mô hình gia tăng o ng Mô hình xoắn ốc (spiral) du Gia tăng 1 Lập kế hoạch Phân tích rủi ro Phân tích Thiết kế Lập trình Kiểm thử Xuất xưởng 1 u Công nghệ hệ thống/thông tin Giao tiếp cu khách hàng Gia tăng 2 Phân tích Thiết kế Lập trình Kiểm thử Xuất xưởng 2 Khái niệm Kỹ nghệ Gia tăng 3 Phân tích Thiết kế Lập trình Kiểm thử Xuất xưởng 3 Làm mới Gia tăng 4 Phân tích Thiết kế Lập trình Kiểm thử XX 4 Nâng cấp Khách hàng Xây dựng & đánh giá Xuất xưởng Thời gian/lịch Bảo trì 39 40 39 40 CuuDuongThanCong.com https://fb.com/tailieudientucntt
Mô hình xoắn ốc (tiếp) Mô hình xoắn ốc (tiếp) • Giao tiếp khách hàng: giữa người phát triển và • Xây dựng và xuất xưởng: xây dựng, kiểm thử, khách hàng để tìm hiểu yêu cầu, ý kiến cài đặt và cung cấp hỗ trợ người dùng (tư liệu, • Lập kế hoạch: Xác lập tài nguyên, thời hạn và huấn luyện, . . .) om những thông tin khác • Đánh giá của khách hàng: Nhận các phản hồi • Phân tích rủi ro: Xem xét mạo hiểm kỹ thuật 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 .c và mạo hiểm quản lý • Kỹ nghệ: Xây dựng một hay một số biểu diễn ng của ứng dụng co 41 42 an 41 42 th Mô hình xoắn ốc: Mạnh và yếu? o ng Mô hình xoắn ốc WINWIN du • Tốt cho các hệ phần mềm quy mô lớn • Nhằm thỏa hiệp giữa người phát triển và • Dễ kiểm soát các mạo hiểm ở từng mức tiến khách hàng, cả hai cùng “Thắng” (win-win) u – Khách thì có phần mềm thỏa mãn yêu cầu chính hóa cu – Người phát triển thì có kinh phí thỏa đáng và thời • Khó thuyết phục khách hàng là phương pháp gian hợp lý tiến hóa xoắn ốc có thể kiểm soát được • Các hoạt động chính trong xác định hệ thống: • Chưa được dùng rộng rãi như các mô hình – Xác định cổ đông (stakeholders) tuyến tính hoặc chế thử – 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 43 44 43 44 CuuDuongThanCong.com https://fb.com/tailieudientucntt
Mô hình phát triển đồng thời Mô hình xoắn ốc WINWIN (concurrent development) 2. Xác định điều kiện 3a. Hòa hợp điều kiện thắng • Xác định mạng lưới những hoạt động đồng thời 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 (Network of concurrent activities) 1. Xác định mức • Các sự kiện (events) xuất hiện theo điều kiện vận tiếp của cổ đông động trạng thái trong từng hoạt động om 4. Đánh giá tiến trình và dự kiến sản phẩm, • Dùng cho mọi loại ứng dụng và cho hình ảnh khá giải quyết rủi ro chính xác về trạng thái hiện trạng của dự án .c • Thường dùng trong phát triển các ứng dụng 7. Xét duyệt và đánh giá khách/chủ (client/server applications): hệ thống ng 6. Kiểm định sản phẩm và quy trình 5. Xác định mức tiếp của sản phâm và quy trình, và các thành phần cấu thành hệ thống được phát kể cả phân chia nhỏ triển đồng thời co 45 46 an 45 46 th 3.6. Mô hình hướng thành phần Component-based model o ng Mô hình dựa thành phần du • Gắn với những công nghệ hướng đối tượng Lập kế hoạch (Object-oriented technologies) qua việc tạo các lớp Phân tích rủi ro Xác định thành phần u (classes) có chứa cả dữ liệu và giải thuật xử lý dữ ứng viên Giao tiếp cu liệu khách hàng Xây dựng Tìm bước lặp thứ n thành phần • Có nhiều tương đồng với mô hình xoắn ốc của hệ thống từ thư viện • Với ưu điểm tái sử dụng các thành phần qua Thư Đặt Lấy viện / kho các lớp: tiết kiệm 70% thời gian, 80% giá Kỹ nghệ thành phần vào thư viện thành phần nếu có thành, chỉ số sản xuất 26.2/16.9 Khách hàng Xây dựng & Xây dựng đánh giá Xuất xưởng thành phần • Với UML như chuẩn công nghiệp đang triển khai nếu kh.có 47 48 47 48 CuuDuongThanCong.com https://fb.com/tailieudientucntt
2.3.7. Mô hình RUP Tổng kết các mô hình (Rational Unified Process) • SV tự nghiên cứu • Thác nước: mô hình tuyến tính • Chế thử: mô hình lặp đi lặp lại • Gia tăng: kết hợp giữa mô hình tuyến tính và om lặp đi lặp lại • Xoăn ốc: kết hợp giữa mô hình tuyến tính và .c lặp đi lặp lại • Phát triển nhanh: mô hình lặp đi lặp lại ng co 49 50 an 49 50 th 3.8. Các kỹ thuật thế hệ thứ 4 (Fourth generation techniques) o ng 4GT: Tại sao ? du • Tập hợp các công cụ cho phép xác định đặc • 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 tính phần mềm ở mức cao, sau đó sinh tự • Không nên bỏ qua khâu thiết kế. 4GT chỉ áp dụng u động mã nguồn dựa theo đặc tả đó để triển khai thiết kế qua 4GL cu • Các công cụ 4GT điển hình: ngôn ngữ phi thủ • Mạnh: giảm thời gian phát triển và tăng năng tục cho truy vấn CSDL; tạo báo cáo; xử lý dữ suất liệu; tương tác màn hình; tạo mã nguồn; khả • Yếu: 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 năng đồ họa bậc cao; khả năng bảng tính; kỹ năng của kỹ sư phần mềm khả năng giao diện Web; vv • Tương lai: 4GT với mô hình theo thành phần 51 52 51 52 CuuDuongThanCong.com https://fb.com/tailieudientucntt
4. Đánh giá: Sản phẩm và quy trình (Product and process) • Quy trình yếu thì sản phẩm khó mà tốt, song không nên coi trọng quá mức vào quy trình hoặc quá mức vào sản phẩm om • Sản phẩm và quy trình cần được coi trọng như nhau .c ng co 53 an 53 th o ng du u cu CuuDuongThanCong.com https://fb.com/tailieudientucntt