Bài giảng Công nghệ phần mềm - Phần I: Giới thiệu chung về công nghệ phần mềm - Vũ Thị Hương Giang

ác thành phần
 trong cấu trúc CMM.
 Maturity nhận được từ
 Levels
 chỉ ra Key Process
 tổ chức bởi
 Areas
 Khả năng
 đạt được Common
 tiến trình nhận được từ
 Features
 Các mục tiêu ánh xạ Key 
 Practices
 Thực thi hoặc mô tả
 thể chế hoá
 Cơ sỏ hạ tầng hoặc 
 các hoạt động
 65
 d. Mô hình 5 mức của CMM
Tiến trình phần mềm mang
tính chất tuỳ tiện, lộn xộn, 
có ít tiến trình được xác định
trước, hiệu quả của công việc
mang tính riêng lẻ. 
 Continuously improving Optimizing
Khó có được một môi trường (5)
làm việc ổn định. Kế hoạch và process
ngân sách, chất lượng sản
phẩm và vận hành không thể Predictable Managed
dự đoán trước được. (4)
 process
 Standard,consistent Defined
 (3)
 process
 Disciplined Repeatable
 (2)
 process Quá trình vận hành phụ thuộc vào khả năng của
 từng cá nhân riêng lẻ, và thường xuyên thay đổi
 do phụ thuộc vào kỹ năng, trình độ hiểu biết và
 Initial các hoạt động của từng thành viên trong dự án.
 (1)
 66
 33
 9/6/2011
d. Mô hình 5 mức của CMM
 Có sự cải tiến hơn, chiến
 lược quản lý dự án vµ thủ
 tục để thực thi chiến lược
 ấy được thiết lập. Các kế
 hoạch và quản lý dự án
 Continuously improving Optimizing
 mới được dựa trên những (5)
 kinh nghiệm của dự án cũ. process
 Predictable Managed
 (4)
 process
 Standard,consistent Defined
 (3)
 process
 Disciplined Repeatable
 (2)
 process Kết quả là đưa được những hiệu quả quản lý tiến
 trình của một dự án nµy vào một dự án khác. 
 Điều này cho phép lặp lại (repeatable) những
 Initial thành công đối với một dự án tương tự mặc dù
 (1) có thể các dự án này cũng có những điểm khác
 biệt.
 67
d. Mô hình 5 mức của CMM
 Lập được tài liệu tiến trình
 tiêu chuẩn đối với việc phát
 triển và bảo trì phần mềm
 có tổ chức, bao gồm cả
 công nghệ phần mềm, các
 Continuously improving Optimizing
 tiến trình quản lý, và các (5)
 tiến trình tích hợp với nhau process
 (nghĩa rằng đầu ra của một
 tiến trình sẽ là đầu vào của Predictable Managed
 tiến trình tiếp theo ). (4)
 process
 Standard,consistent Defined
 (3)
 process
 Disciplined Repeatable
 (2)
 process Một tiến trình được định nghĩa tốt gồm có các
 tính chất như có tiêu chuẩn, đầu vào, tiêu chuẩn
 và thủ tục rõ ràng để tiến hành công việc, kiểm
 Initial tra các đầu ra.
 (1)
 68
 34
 9/6/2011
d. Mô hình 5 mức của CMM
 Mục tiêu là điều khiển tiến
 trình. Các tiến trình phần
 mềm được quản lý để vận
 hành ổn định, an toàn. Có
 những đánh giá phần mềm
 Continuously improving Optimizing
 và chất lượng, hiệu quả các (5)
 hoạt động trong tiến trình. process
 Predictable Managed
 (4)
 process
 Standard,consistent Defined
 (3)
 process
 Disciplined Repeatable
 (2)
 process Do các tiến trình ổn định và được đánh giá đúng
 nên khi có các trường hợp ngoại lệ, sẽ xác định
 Initial và chỉ rõ những nguyên nhân gây ra biến đổi.
 (1)
 69
d. Mô hình 5 mức của CMM
 Tiếp tục cải tiến tiến trình, 
 có thể xác định được
 những điểm mạnh và điểm
 yếu của tiến trình, có khả
 năng phân tích các khiếm
 Continuously improving Optimizing
 khuyết, xác định các (5)
 nguyên nhân gây ra để process
 tránh các khiếm khuyết
 này. Predictable Managed
 (4)
 process
 Standard,consistent Defined
 (3)
 process
 Disciplined Repeatable
 (2)
 process
 Initial
 (1)
 70
 35
 9/6/2011
18 KPA (Key Process Area)
 7. Peer reviews
 LEVEL 2: Repeatable
 8. Intergroup 16.
 1. SW configuration 
 coordination Process
 management
 9. SW product change
 2. SW quality 14. 
 engineering management
 assurance SW quality
 10. IntegratedSW 17. 
 3. SW subcontract Management
 management Technology
 management 15. 
 11. Training program change
 4. SW project tracking Quantitative
 12. Organization management
 and oversight process
 process definition 18.
 5. SW project management
 13. Organization Defect
 planning
 process focus prevention
 6. Requirements 
 management
 LEVEL 3: Defined 
 LEVEL 4: Managed
 LEVEL 5: Optimizing
 71
Khả năng nhìn nhận tại mỗi mức thuần
thục
 72
 36
 9/6/2011
Khả năng tiến trình và dự đoán theo
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. 
 73
e. Cách thức sử dụng mô hình CMM
• Định giá tiến trình phần mềm (Software process 
 assessments ) xác định trạng thái của tiến trình 
 phần mềm hiện tại của tổ chức, xác định mức độ 
 ưu tiên đối với các vấn đề có liên quan tới tiến 
 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.
• Đánh giá khả năng phần mềm (Software 
 capability evaluations) xác định các nhà thầu có 
 đủ tư cách triển khai một dự án phần mềm hoặc 
 quản lý hiện trạng của một hệ thống phần mềm 
 đã có sẵn.
 74
 37
 9/6/2011
Những điểm chung của 2 phương thức
sử dụng CMM
 75
4.2. Mô hình tuyến tính
• Công nghệ học Hệ thống / Thông tin và mô hình
 hóa (System / Information engineering and 
 modeling): thiết lập các yêu cầu, ánh xạ một số
 tập con các yêu 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ử
 Công nghệ học
 Hệ thống / Thông tin
 76
 38
 9/6/2011
4.2. Mô hình tuyến tính
Tạo mã / lập trình (Code generation / Kiểm thử (Testing): Kiểm tra
programming): Chuyển thiết kế thành các chương trình và môđun cả
chương trình máy tính bởi ngôn ngữ nào về lôgic bên trong và chức năng
đó. Nếu thiết kế đã được chi tiết hóa thì bên ngoài, nhằm phát hiện ra
lập trình có thể chỉ thuần túy cơ học lỗi và đảm bảo với đầu vào xác
 định thì cho kết quả mong
 muốn
 Phân tích Thiết kế Lập trình Kiểm thử
 Công nghệ học
 Hệ thống / Thông tin
 77
4.2. Mô hình tuyến tính
• Hỗ trợ / Bảo trì (Support / Maintenance): Đáp
 ứng những thay đổi, nâng cấp phần mềm đã phát
 triển do sự thay đổi của môi trường, nhu cầu
 Phân tích Thiết kế Lập trình Kiểm thử
 Công nghệ học
 Hệ thống / Thông tin
 78
 39
 9/6/2011
Điểm yếu của Mô hình tuyến tính
• Thực tế các dự án ít khi tuân theo dòng tuần tự 
 của mô hình, mà thường có lặp lại (như mô hình 
 của Boehm)
• 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 thời 
 gian nhất định mới có sản phẩm. Nếu phát hiện 
 ra lỗi nặng thì là một thảm họa!
 79
4.3. Mô hình chế thử (Prototyping 
model)
 Nghe Khách Tạo / sửa
 trình bày bản mẫu
 Khách kiểm tra
 bản mẫu
 80
 40
 9/6/2011
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
• 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
 81
4.4. Mô hình phát triển ứng dụng nhanh
(Rapid Application Development: RAD)
• Là quy trì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)
 82
 41
 9/6/2011
Mô hình phát triển ứng dụng nhanh
 Team #3
 Business
 Modeling
 Team #2 Data
 Modeling
 Business Process
 Modeling Modeling
 Team #1 Data Application
 Modeling Generation
 Business Process Testing &
 Turnover
 Modeling Modeling
 Data Application
 Modeling Generation
 Testing &
 Process Turnover
 Modeling
 Application
 Generation
 Testing &
 Turnover
 60 - 90 days
RAD: Business modeling
• Luồng thông tin được mô hình hóa để trả lời các 
 câu hỏ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 ?
 84
 42
 9/6/2011
RAD: Data and Process modeling
• 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 
 85
RAD: Appl. Generation and Testing
• 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)
 86
 43
 9/6/2011
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
 87
 Mở đầu
 • 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 tiêu biểu: 
 – Incremental
 – Spiral
 – WINWIN spiral
 – Concurrent development model
 88
 44
 9/6/2011
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
 89
Mô hình gia tăng
 Gia tăng 1
 Phâ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
 90
 45
 9/6/2011
Mô hình xoắn ốc (spiral)
 Lập kế hoạch
 Phân tích rủi ro
 Giao tiếp
 khách hàng
 Khái niệm Kỹ nghệ
 Làm mới
 Nâng cấp
 Khách hàng Xây dựng & 
 đánh giá
 Bảo trì Xuất xưởng
 91
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ý
• Kỹ nghệ: Xây dựng một hay một số biểu diễn của 
 ứng dụng
 92
 46
 9/6/2011
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 
 93
Mô hình xoắn ốc: Mạnh và yếu?
• Tốt cho các hệ phần mềm quy mô lớn
• Dễ kiểm soát các mạo hiểm ở từng mức tiến hóa
• 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ử
 94
 47
 9/6/2011
Mô hình xoắn ốc WINWIN
• 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 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
 95
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ỏ
 96
 48
 9/6/2011
Mô hình phát triển đồng thời
(concurrent development)
• 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 cấu thành hệ thống được phát
 triển đồng thời
 97
 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ệu
 • Có nhiều tương đồng với mô hình xoắn ốc
 • Vớ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, chỉ số sản xuất
 26.2/16.9
 • Với UML như chuẩn công nghiệp đang
 triển khai
 98
 49
 9/6/2011
 Mô hình dựa 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ên
Giao tiếp
 khá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ó
 99
 4.7. Mô hình RUP
 (Rational Unified Process)
 • SV tự nghiên cứu
 100
 50
 9/6/2011
 4.8. 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 đó sinh tự động 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; vv
 101
4GT: Tại sao ?
• 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
• Mạnh: giảm thời gian phát triển và tăng năng 
 suất
• 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 
 kỹ năng của kỹ sư phần mềm
• Tương lai: 4GT với mô hình theo thành phần
 102
 51
 9/6/2011
5. 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
 103
 52