Bài giảng Nhập môn công nghệ phần mềm (Introduction to software engineering) - Chương 2: Vòng đời phần mềm

oặ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
 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
 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
 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
 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
 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
 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
 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
 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
 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
 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