Nhập môn Công nghệ phần mềm - Chương 2: Vòng đời phần mềm

Nội dung text: Nhập môn Công nghệ phần mềm - Chương 2: Vòng đời phần mềm

1. 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 – 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 – 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 • 4. Đánh giá sản phẩm và quy trình 1 2 1 2 Chương 2: Vòng đời phần mềm Vòng đời phần mềm 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 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. 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
2. 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 Phân tích cấu trúc hóa đoạn sau: yêu cầu Xác định yêu cầu phần mềm – 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 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 – Thiết kế — xác định cấu trúc / tổ chức của hệ thống Thiết kế của phần mềm (đơn vị chương trình hoặc Phương pháp Jackson phần mềm] chương trình – môđun) Phương pháp Warnier Mã hóa — viết phần mềm 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ử Kiểm tra chất lượng phần mềm đã phát triển khiếm khuyết chất lượng chương trình Vận hành Sử dụng, vận hành phần mềm đã phát triển. – Bảo trì — sửa chữa và nâng cao sản phẩm sau khi 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 5 6 5 6 Các mô hình vòng đời phần mềm 2. Quy trình phát triển phần mềm • 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ụ. • 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) 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
3. 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 – Các khái niệm dụng CMM CMM • 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. – bị thay đổi cập nhật mà không có Các tiến trình được cập nhật qua sự Tại sao sử dụng mô hình CMM sự chuần bị trước. đ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 kiểm thử. không chặt chẽ, dẫn đến sự • Vai trò, trách nhiệm của mỗi thành 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ó 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. 9 10 9 10 Các khái niệm cơ bản trong CMM Thực thi tiến trình phần mềm (Software Process Performance) • 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 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 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
4. Độ 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 đạt được Các tính năng phổ quả một cách rõ ràng. tiến trình nhận được từ biến • Cho biết khả năng phát triển, chỉ ra giá trị của 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ả thể chế hoá Cơ sỏ hạ tầng hoặc các hoạt động 13 14 13 14 Mô hình 5 mức của CMM Mô hình 5 mức của CMM Tiến trình phần mềm mang tính chất Có sự cải tiến hơn, chiến lược 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 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. 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
5. 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ý đ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) 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ó 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) 17 18 17 18 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ể KPA (Key Process Area) 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 Tiến trình cải 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. Cải tiến phần mềm 9. Kỹ thuật sản phẩm tiến trình 14. tiến liên tục (5) 2. Đảm bảo chất phần mềm 17. Quản lý chất 10. Quản lý phần mềm lượng phần mềm lượng phần mềm Quản lý thay đổi tích hợp công nghệ Tiến trình dự Được quản lý 3. Quản lý hợp đồng 15. con phần mềm 11. Chương trình huấn 18. (4) Quản lý quá trình đoán được 4. Theo dõi và giám luyện Phòng ngừa khiêm định lượng sát dự án phần mềm 12. Định nghĩa tiến trình khuyết Tiến trình ổn định, Được định nghĩa 5. Lập kế hoạch dự tổ chức chuẩn (3) án phần mềm 13. Trọng tâm tiến trình 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
6. 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. • 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 triển ngắn hơn, chất lượng và năng suất tăng. 21 22 21 22 Những điểm chung của 2 phương Cách thức sử dụng mô hình CMM thức sử dụng CMM • Định giá tiến trình phần mềm (Software process Câu hỏi thuần thục assessments ) xác định trạng thái của tiến trình Lựa chọn 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 tiên đối với các vấn đề có liên quan tới tiến Các mẫu CMM 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 đã có sẵn. liệu Dựa trên CMM (4) (5) (6) 23 24 23 24
7. 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à ngôn ngữ nào đó. Nếu thiết kế đã được chi tiết hóa chức năng bên ngoài, nhằm phát hiện (System / Information engineering and modeling): thì lập trình có thể chỉ thuần túy cơ học 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 phần cứng, người và CSDL 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ử Công nghệ học Công nghệ học Hệ thống / Thông tin Hệ thống / Thông tin 25 26 25 26 Mô hình tuyến tính Điểm yếu của Mô hình tuyến tính • 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ô phát triển do sự thay đổi của môi trường, nhu hình của Boehm) 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
8. 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 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 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 để 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 29 30 29 30 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) Team #3 Mô hình nghiệp vụ Team #2 Mô hình • Là quy trình phát triển phần mềm gia tăng, tăng dần dữ liệu Mô hình Mô hình từng bước (Incremental software development) với nghiệp vụ tiến trình mỗi chu trình phát triển rất ngắn (60-90 ngày) Team #1 Mô hình Tạo dữ liệu ứng dụng Mô hình Mô hình Kiểm thử • Xây dựng dựa trên hướng thành phần (Component- &Turnover nghiệp vụ tiến trình based construction) với khả năng tái sử dụng (reuse) Mô hình Tạo dữ liệu ứng dụng • Gồm một số nhóm (teams), mỗi nhóm làm 1 RAD theo Kiểm thử các pha: Mô hình nghiệp vụ, Mô hình dữ liệu, Mô hình Mô hình &Turnover tiến trình 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
9. 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 – 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 – 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 tượng dữ liệu 33 34 33 34 RAD: Tạo ứng dụng và kiểm thử RAD: Hạn chế ? • 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 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 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
10. 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 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 – 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 – Xoắn ốc WINWIN (WINWIN spiral) – Phát triển đồng thời (Concurrent development) 37 38 37 38 Mô hình gia tăng Mô hình xoắn ốc (spiral) 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 Công nghệ hệ thống/thông tin Giao tiếp 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
11. 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, . . .) 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 và mạo hiểm quản lý trong giai đoạn kỹ nghệ và cài đặt • Kỹ nghệ: Xây dựng một hay một số biểu diễn của ứng dụng 41 42 41 42 Mô hình xoắn ốc: Mạnh và yếu? Mô hình xoắn ốc WINWIN • 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) – hóa 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 • 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
12. Mô hình phát triển đồng thời Mô hình xoắn ốc WINWIN (concurrent development) • Xác định mạng lưới những hoạt động đồng thời 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 (Network of concurrent activities) và các ràng buộc, dự kiến • 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 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 • 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 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, 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 45 46 45 46 3.6. Mô hình hướng thành phần Mô hình dựa thành phần Component-based model • Gắn với những công nghệ hướng đối tượng Lập kế hoạch Phân tích rủi ro Xác định (Object-oriented technologies) qua việc tạo các lớp thành phần ứng viên (classes) có chứa cả dữ liệu và giải thuật xử lý dữ Giao tiếp khách hàng liệu 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 thành phần thành phần viện / kho các lớp: tiết kiệm 70% thời gian, 80% giá vào thư viện nếu có Kỹ nghệ 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
13. 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à lặp đi lặp lại • Xoăn ốc: kết hợp giữa mô hình tuyến tính và lặp đi lặp lại • Phát triển nhanh: mô hình lặp đi lặp lại 49 50 49 50 3.8. Các kỹ thuật thế hệ thứ 4 4GT: Tại sao ? (Fourth generation techniques) • 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 động mã nguồn dựa theo đặc tả đó để triển khai thiết kế qua 4GL • 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
14. 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 • Sản phẩm và quy trình cần được coi trọng như nhau 53 53