Bài giảng Công nghệ phần mềm ứng dụng - Bài 1: Giới thiệu chung về công nghệ học phần mềm - Thạc Bình Cường

ghệ học trong công nghệ học phần mềm :
  Như các ngành công nghệ học khác, công nghệ học phần mềm cũng lấy các
 phương pháp khoa học làm cơ sở.
  Các kỹ thuật về thiết kế, chế tạo, kiểm thử và bảo trì phần mềm đã được hệ
 thống hóa hóa thành phương pháp luận và hình thành nên công nghệ học
 phần mềm.
  Toàn bộ quy trình quản lý phát triển phần mềm gắn với khái niệm vòng đời phần
 mềm, được mô hình hóa với những kỹ thuật và phương pháp luận trở thành các
 chủ đề khác nhau trong công nghệ học phần mềm.
  Trong vòng đời phần mềm không chỉ có chế tạo mà bao gồm cả thiết kế, vận
 hành và bảo dưỡng (tính quan trọng của thiết kế và bảo dưỡng).
  Trong khái niệm phần mềm, không chỉ có chương trình mà cả tư liệu về
 phần mềm.
  Cách tiếp cận công nghệ học (khái niệm công nghiệp hóa) thể hiện ở chỗ nhằm
 nâng cao năng suất (tính năng suất) và độ tin cậy của phần mềm, đồng thời giảm
 chi phí giá thành.
v1.0015112208 35
1.3.2. VÒNG ĐỜI PHẦN MỀM
• Vòng đời phần mềm là thời Mô hình vòng đời phần mềm của Boehm
 kỳ tính từ khi phần mềm
 được sinh (tạo) ra cho đến
 khi chết đi (từ lúc 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).
• Quy trình phần mềm (vòng
 đời phần mềm) được 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.
v1.0015112208 36
1.3.2. VÒNG ĐỜI PHẦN MỀM
• Suy nghĩ mới về vòng đời phần mềm
  Pha xác định yêu cầu và thiết kế có vai trò quyết định đến chất lượng phần mềm,
 chiếm phần lớn công sức so với lập trình, kiểm thử và chuyển giao phần mềm.
  Pha cụ thể hóa cấu trúc phần mềm phụ thuộc nhiều vào suy nghĩ trên xuống
 (top-down) và trừu tượng hóa, cũng như chi tiết hóa.
  Pha thiết kế, chế tạo thì theo trên xuống, pha kiểm thử thì dưới lên (bottom-up).
  Trước khi chuyển sang pha kế tiếp phải đảm bảo pha hiện nay đã được kiểm thử
 không còn lỗi.
  Cần có cơ chế kiểm tra chất lượng, xét duyệt giữa các pha nhằm đảm bảo không
 gây lỗi cho pha sau.
  Tư liệu của mỗi pha không chỉ dùng cho pha sau, mà chính là đối tượng quan
 trọng cho kiểm tra và đảm bảo chất lượng của từng quy trình và của chính
 phần mềm.
  Cần chuẩn hóa mẫu biểu, cách ghi chép tạo tư liệu cho từng pha, nhằm đảm bảo
 chất lượng phần mềm.
  Thao tác bảo trì phần mềm là việc xử lý quay vòng trở lại các pha trong vòng đời
 phần mềm nhằm biến đổi, sửa chữa, nâng cấp phần mềm.
v1.0015112208 37
1.3.2. VÒNG ĐỜI PHẦN MỀM
Các phương pháp luận và kỹ thuật cho từng pha:
 Phương pháp, kỹ 
 Tên pha Nội dung nghiệp vụ
 thuật
 Xác định yêu cầu Đặc tả yêu cầu người dùng; Phân tích cấu trúc hóa.
 Xác định yêu cầu phần mềm.
 Thiết kế hệ thống Thiết kế cơ bản phần mềm; Thiết kế cấu trúc hóa.
 Thiết kế cấu trúc ngoài phần mềm.
 Thiết kế Là thiết kế chi tiết – thiết kế cấu trúc Lập trình cấu trúc,
 chương trình bên trong của phần mềm (đơn vị phương pháp Jackson,
 chương trình hoặc module). phương pháp Warnier.
 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.
 Đảm bảo Kiểm tra chất lượng phần mềm đã Phương pháp kiểm thử
 chất lượng phát triển. chương trình.
 Vận hành bảo trì Sử dụng, vận hành phần mềm đã phát Chưa cụ thể.
 triển. Biến đổi, điều chỉnh phần mềm.
v1.0015112208 38
1.3.3. QUY TRÌNH PHÁT TRIỂN PHẦN MỀM
 Common process framework - Khung quy trình chung
 Framework activities - Hoạt động khung
 Task sets - Tập tác vụ
 Tasks - Tác vụ
 Milestones, deliverables
 SQA points - Điểm kiểm tra chất lượng
 Umbrella activities
v1.0015112208 39
1.3.3. QUY TRÌNH PHÁT TRIỂN PHẦN MỀM
a. Mô hình thuần thục khả năng
• Lịch sử phát triển: Tháng 11 năm 1986 Viện Công nghệ phần mềm SEI (Software
 Engineering Institute) ra khung sườn và các khái niệm liên quan để giúp cải thiện qui
 trình sản xuất phần mềm.Tháng 9 năm 1987 viện SEI đã đưa ra đặc tả của khung
 sườn thuần thục tiến trình này.
• Năm 1991, phát triển thành mô hình thuần thục khả năng (CMM). Phiên bản đầu tiên
 là CMM 1.0 phát triển vào những năm 1991-1992. Trong phần này chúng ta sẽ tìm
 hiểu về CMM 1.1.
• Một số khó khăn khi không sử dụng CMM:
  Các tiến trình phần mềm thường bị thay đổi cập nhật mà không có sự chuẩn bị
 trước. Đặc tả một tiến trình phần mềm không chặt chẽ, dẫn đến sự khủng hoảng
 khi thực hiện một dự án.
  Thiếu cơ sở để đánh giá chất lượng phần mềm, để đưa ra phương thức tiến
 hành và cách giải quyết các vấn đề phát sinh.
• Một số thuận lợi khi sử dụng CMM:
  Dễ dàng quản lý phát triển phần mềm. 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à kiểm thử.
  Vai trò, trách nhiệm của mỗi thành viên trong các tiến trình được phân định
 rõ ràng.
  Quản lý chất lượng của phần mềm, thoả mãn các yêu cầu khách hàng. Có cơ sở
 chuẩn xác đánh giá chất lượng, thời gian, chi phí và phân tích dự án và các
 tiến trình.
v1.0015112208 40
1.3.3. QUY TRÌNH PHÁT TRIỂN PHẦN MỀM (tiếp theo)
v1.0015112208 41
1.3.3. QUY TRÌNH PHÁT TRIỂN PHẦN MỀM (tiếp theo)
v1.0015112208 42
1.3.3. QUY TRÌNH PHÁT TRIỂN PHẦN MỀM (tiếp theo)
Mức 1 (Khởi đầu):
• Tính chất: 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ẻ. Khó có được một môi
 trường làm việc ổn định. Kế hoạch và ngân sách, chất lượng sản phẩm và vận hành
 không thể dự đoán trước được. 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à các hoạt động của từng thành viên trong dự án.
• Các KPA: Không có.
Mức 2 (Lặp):
• Tính chất: 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 mới được dựa trên những
 kinh nghiệm của dự án cũ. 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 thành công đối với một dự án tương tự mặc dù có thể các dự án này cũng có
 những điểm khác biệt.
• Các KPA:
  Requirements Management (quản lý Các yêu cầu);
  Software Project Planning (lập kế hoạch dự án phần mềm);
  Software Project Tracking and Oversight (điều chỉnh và giám sát DAPM);
  Software Subcontract Management (quản lý các hợp đồng phần mềm phụ);
  Software Quality Assurance (đảm bảo chất lượng phần mềm);
  Software Configuration Management (quản lý cấu hình phần mềm).
v1.0015112208 43
1.3.3. QUY TRÌNH PHÁT TRIỂN PHẦN MỀM (tiếp theo)
Mức3(Xácđịnh):
• Tính chất:
  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 tiến trình quản lý, và các tiến
 trình tích hợp với nhau (nghĩa rằng đầu ra của một tiến trình sẽ là đầu vào của
 tiến trình tiếp theo).
  Một tiến trình được xác định 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 tra các đầu ra.
• Các KPA:
  Organization Process Focus (tập trung vào tiến trình tổ chức);
  Organization Process Definition (định nghĩa tiến trình tổ chức);
  Training Program (chương trình tập huấn);
  Integrated Software Management (quản lý phần mềm tích hợp);
  Software Product Engineering (công nghệ sản xuất phần mềm);
  Intergroup Coordination (kết hợp giữa các nhóm);
  Peer Reviews (rà soát ngang hàng).
v1.0015112208 44
1.3.3. QUY TRÌNH PHÁT TRIỂN PHẦN MỀM (tiếp theo)
Mức 4 (Quản lý):
• Tính chất: 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 và chất lượng, hiệu quả
 các hoạt động trong tiến trình. 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 và chỉ rõ những nguyên nhân gây ra
 biến đổi.
• Các KPA Quantitative Process Management (quản lý tiến trình định lượng): Software
 Quality Management (quản lý chất lượng phần mềm)
Mức 5 (Tối ưu hóa):
• Tính chất: 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 khuyết, xác định các
 nguyên nhân gây ra khó tránh các khiếm khuyết này.
• Các KPA:
  Defect Prevention (phòng chống khiếm khuyết);
  Technology Change Management (quản lý thay đổi về công nghệ).
v1.0015112208 45
1.3.3. QUY TRÌNH PHÁT TRIỂN PHẦN MỀM (tiếp theo)
v1.0015112208 46
1.3.3. QUY TRÌNH PHÁT TRIỂN PHẦN MỀM (tiếp theo)
• 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à cơ sở dữ liệu.
• Phân tích yêu cầu (Requirements analysis): Hiểu lĩnh vực thông tin, chức năng, hành
 vi, tính năng và giao diện của phần mềm sẽ phát triển. Cần phải tạo tư liệu và bàn
 thảo với khách hàng, người dùng.
• Thiết kế (Design): là quá trình nhiều bước với 4 thuộc tính khác nhau của một
 chương trình: cấu trúc dữ liệu, kiến trúc phần mềm, biểu diễn giao diện và chi tiết thủ
 tục (thuật toán). Cần tư liệu hóa và là một phần quan trọng của cấu hình phần mềm.
• Tạo mã/lập trình (Code generation/programming): Chuyển thiết kế thành chương
 trình máy tính bởi 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.
• Kiểm thử (Testing): Kiểm tra các chương trình và module cả về logic bên trongvà
 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 thì cho
 kết quả mong muốn.
• 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.
v1.0015112208 47
1.3.3. QUY TRÌNH PHÁT TRIỂN PHẦN MỀM (tiếp theo)
• Đ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.
v1.0015112208 48
1.3.3. QUY TRÌNH PHÁT TRIỂN PHẦN MỀM (tiếp theo)
c. Mô hình chế thử
 NgheNghe Kháchkhách TạoTạo/sửa / sửa
 trình bày bản mẫu
 Khách kiểm tra
 bản mẫu
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.
v1.0015112208 49
1.3.3. QUY TRÌNH PHÁT TRIỂN PHẦN MỀM (tiếp theo)
d. Mô hình phát triển ứng dụng Team #3
 nhanh (Rapid Application Business
 Development - RAD) Modeling
 Team #2 Data
• Là quy trình phát triểnphần Modeling
 Business Process
 mềmgiatăng, tăng dầntừng Modeling Modeling
 bước (Incrimental software Team #1 Data Application
 Modeling Generation
 development) vớimỗi chu trình Business Process Testing &
 phát triểnrấtngắn (60-90 ngày). Modeling Modeling Turnover
 Application
•Xâydựng dựatrênhướng Data
 Generation
 thành phần (Component-based Modeling
 Testing &
 construction) vớikhả năng tái Process Turnover
 sử dụng (reuse). Modeling
•Gồmmộtsố nhóm (teams), mỗi Application
 nhóm làm 1 RAD theo các pha: Generation
 mô hình nghiệpvụ,môhìnhdữ
 liệu, mô hình xử lý, tạo ứng Testing &
 Turnover
 dụng, kiểmthử và đánh giá.
 60 - 90 days
v1.0015112208 50
1.3.3. QUY TRÌNH PHÁT TRIỂN PHẦN MỀM (tiếp theo)
• Data modeling: Các đốitượng dữ liệucần để hỗ trợ nghiệpvụ (business). Định
 nghĩacácthuộc tính củatừng đốitượng và xác lập quan hệ giữacácđốitượng.
• Process modeling: Các đốitượng dữ liệu được chuyển sang luồng thông tin thực
 hiệnchứcnăng nghiệpvụ.Tạomôtả xử lý đễ cậpnhật(thêm,sửa, xóa, khôi phục)
 từng đốitượng dữ liệu.
• Application Generation: Dùng các kỹ thuậtthế hệ 4 để tạophầnmềmtừ các thành
 phầncósẵnhoặctạo ra các thành phầncóthể tái dụng lại sau này. Dùng các công
 cụ tựđộng để xây dựng phầnmềm.
• Testing and Turnover: Kiểmthử các thành phầnmớivàkiểmchứng mọigiaodiện
 (các thành phầncũđã đượckiểmthử và dùng lại).
•Hạnchế củaRAD:
  Cần nguồn nhân lựcdồi dào để tạo các nhóm cho các chứcnăng chính;
  Yêu cầu hai bên giao kèo trong thờigianngắnphảicóphầnmềm hoàn chỉnh,
 thiếu trách nhiệmcủamột bên dễ làm dự án đổ vỡ;
  RAD không phảitốtchomọi ứng dụng, nhấtlàvới ứng dụng không thể module
 hóa hoặc đòi hỏi tính năng cao;
  Mạohiểmkỹ thuật cao thì không nên dùng RAD.
v1.0015112208 51
1.3.3. QUY TRÌNH PHÁT TRIỂN PHẦN MỀM (tiếp theo)
• 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.
• 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).
• Hạn chế của RAD:
  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ể module
 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.
v1.0015112208 52
1.3.3. QUY TRÌNH PHÁT TRIỂN PHẦN MỀM (tiếp theo)
e. Các mô hình tiến hóa: gia tăng, xoắn ốc, xoắn WINWIN
• 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 có tính lặp lại. Kỹ sư phần mềm tạo ra các phiên bản ngày
 càng hoàn thiện hơn, phức tạp hơn.
• Các mô hình: incremental, spiral, WINWIN spiral, concurrent development model.
Mô hình gia tăng
• 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.
v1.0015112208 53
1.3.3. QUY TRÌNH PHÁT TRIỂN PHẦN MỀM (tiếp theo)
v1.0015112208 54
1.3.3. QUY TRÌNH PHÁT TRIỂN PHẦN MỀM (tiếp theo)
v1.0015112208 5 5
1.3.3. QUY TRÌNH PHÁT TRIỂN PHẦN MỀM (tiếp theo)
v1.0015112208 56
1.3.3. QUY TRÌNH PHÁT TRIỂN PHẦN MỀM (tiếp theo)
v1.0015112208 57
TÓM LƯỢC CUỐI BÀI
 Trong bài này chúng ta đã tìm hiểu những nội dung sau:
 • Bản chất phần mềm;
 • Khủng hoảng phần mềm;
 • Công nghệ học phần mềm: định nghĩa, vòng đời phần
 mềm và quy trình phát triển phần mềm.
v1.0015112208 58