Bài giảng Phát triển vận hành bảo trì phần mềm - Chương 4: Các tác vụ yêu cầu bảo trì - Nguyễn Thị Thanh Trúc

Phạm vi vấn đề

 Nắm bắt được kiến thức phạm vi khá quan trọng. Tác động đến

vấn đề vùng phạm vi chuyên biệt, cụ thể.

o Vd: môi trường điều trị bệnh nhân

 Trong hệ thống lớn

o Ví dụ chăm sóc sức khoẻ, viễn thông, tài chính được phân nhỏ

thành vấn đề nhỏ, thành phần nhỏ hơn, được quản lý thành đơn vị

chương trình như mô đun, thủ tục, hàm.

o Ví dụ Trình biên dịch bao gồm thành phần parser, phân tích, phát

sinh code, mỗi thành phần được phân rà thành phần nhỏ hơn .

 Tác động đến sự thay đổi, ước tính nguồn tài nguyên đòi hỏi

cho tác vụ bảo trì, kiến thức phạm vi vấn đề nói chung và vấn

đề nhỏ cụ thể là cần thiết tác động trực tiếp nhân sự bảo trị

trong việc chọn lựa thuật toán phù hợp, phương pháp luận, và

công cụ.

 Việc chọn lựa nhân sự với mức độ chuyên gia và kỹ năng phù

hợp là khía cạnh khác. Thông tin bao gồm từ nguồn khác nhau

– tài liệu hệ thống, end-users, và chương trình nguồn

Hiệu quả thực thi

 Ở mức cao trừu tượng, nhân sự bảo trì cần phải nắm (dự

đoán) kết quả chương trình sẽ được phát sinh kết quả gì từ

đầu vào được cho mà không cần biết đơn vị chương trình

được xây dựng để có kết quả tổng thể và kết quả được cho

như thế nào.

 Ở mức thấp, họ cần biết kết quả mỗi đơn vị chương trình sẽ

được tạo và thực thi.

 Kiến thức data flow, control flow, và thuật toán có thể thuận

tiện hoàn thành thực thi mục tiêu này.

 Ví dụ người lập trình muốn biết ở mức trù tượng, đầu ra của

qui trình hoàn tất biên dịch và ở mức thấp, đầu ra từ parser.

Trong khi, thông tin này sẽ giúp cho người bảo trì xác định

những thay đổi đã thực thi có đạt hiệu quả như mong đợi hay

không

Bài giảng Phát triển vận hành bảo trì phần mềm - Chương 4: Các tác vụ yêu cầu bảo trì - Nguyễn Thị Thanh Trúc trang 1

Trang 1

Bài giảng Phát triển vận hành bảo trì phần mềm - Chương 4: Các tác vụ yêu cầu bảo trì - Nguyễn Thị Thanh Trúc trang 2

Trang 2

Bài giảng Phát triển vận hành bảo trì phần mềm - Chương 4: Các tác vụ yêu cầu bảo trì - Nguyễn Thị Thanh Trúc trang 3

Trang 3

Bài giảng Phát triển vận hành bảo trì phần mềm - Chương 4: Các tác vụ yêu cầu bảo trì - Nguyễn Thị Thanh Trúc trang 4

Trang 4

Bài giảng Phát triển vận hành bảo trì phần mềm - Chương 4: Các tác vụ yêu cầu bảo trì - Nguyễn Thị Thanh Trúc trang 5

Trang 5

Bài giảng Phát triển vận hành bảo trì phần mềm - Chương 4: Các tác vụ yêu cầu bảo trì - Nguyễn Thị Thanh Trúc trang 6

Trang 6

Bài giảng Phát triển vận hành bảo trì phần mềm - Chương 4: Các tác vụ yêu cầu bảo trì - Nguyễn Thị Thanh Trúc trang 7

Trang 7

Bài giảng Phát triển vận hành bảo trì phần mềm - Chương 4: Các tác vụ yêu cầu bảo trì - Nguyễn Thị Thanh Trúc trang 8

Trang 8

Bài giảng Phát triển vận hành bảo trì phần mềm - Chương 4: Các tác vụ yêu cầu bảo trì - Nguyễn Thị Thanh Trúc trang 9

Trang 9

Bài giảng Phát triển vận hành bảo trì phần mềm - Chương 4: Các tác vụ yêu cầu bảo trì - Nguyễn Thị Thanh Trúc trang 10

Trang 10

Tải về để xem bản đầy đủ

pdf 66 trang duykhanh 10260
Bạn đang xem 10 trang mẫu của tài liệu "Bài giảng Phát triển vận hành bảo trì phần mềm - Chương 4: Các tác vụ yêu cầu bảo trì - Nguyễn Thị Thanh Trúc", để tải tài liệu gốc về máy hãy click vào nút Download ở trên

Tóm tắt nội dung tài liệu: Bài giảng Phát triển vận hành bảo trì phần mềm - Chương 4: Các tác vụ yêu cầu bảo trì - Nguyễn Thị Thanh Trúc

Bài giảng Phát triển vận hành bảo trì phần mềm - Chương 4: Các tác vụ yêu cầu bảo trì - Nguyễn Thị Thanh Trúc
thể hệ thống, bức tranh tổng thể tương 
 tác giữa các đơn vị chức năng chính. 
Xác định mối gắn kết thay đổi trên hiệu năng của hệ thống 
Giống nhà quản lý, không cần cái nhìn cục bộ - bức tranh 
 cục bộ những phần của hệ thống và chúng thực thi như thế 
 nào. 
Sử dụng mô hình vật lý như sơ đồ ngữ cảnh để triển khai 
 và thể hiện thành phần chính và chúng liên hệ với môi 
 trường, như vậy giúp nhà phân tích thu được hiểu biết tốt 
 hệ thống mà không cần lãng phí xem chi tiết thiết kế mức 
 thấp và code. 
 24 
 UIT-VNUHCM 2009 
 Designers 
 Thiết kế kiến trúc (Architectural design) kết quả trong sản 
 phẩm thành phần chức năng, cấu trúc dữ liệu mức khái niệm 
 và tương tác giữa các thành phần khác nhau 
 Thiết kế chi tiết (Detailed design) kết quả trong thuật toán 
 chi tiết, thể hiện dữ liệu, cấu trúc dữ liệu, giao diện giữa các 
 thủ tục và chu trình. 
 Khi bảo trì, người thiết kế: 
 o trích rút thông tin và xác định cải tiến có thể được cung cấp bởi 
 kiến trúc, cấu trúc dữ liệu, luồng dữ liệu và luồng kiểm soát của 
 hệ thống hiện tại, 
 o thông qua chương trình nguồn để lấy ý tưởng độ lớn công việc, 
 vùng phạm vi của hệ thống bị tác động, và kiến thức và kỹ năng 
 đòi hỏi bởi nhóm lập trình 
 Dùng khái niệm che dấu thông tin, mô đun, phân rà chương 
 trình, dữ liệu trừu tượng, hướng đối tượng, lý thuyết thiết kế 
 tốt, sơ đồ luồng dữ liệu, sơ đồ luồng kiểm soát, sơ đồ cấu trúc, 
 qui trình phân cấp đầu vào/đầu ra có thể giúp người thiết kế 
 thu được hiểu biết tốt về hệ thống trước khi thiết kế thay đổi 
 25 
UIT-VNUHCM 2009 
 Programmers & thông tin giúp cho họ 
 1. Quyết định restructure hay rewrite phân đoạn 
 chương trình cụ thể hay không 
 2. Dự đoán dễ dàng bất kỳ tác động khi thực hiện 
 thay đổi tác động những phần khác của hệ thống 
 3. Đưa ra những giả thiết vị trí và nguyên nhân gây 
 ra lỗi 
 4. Xác định tính khả thi của những thay đổi đề xuất 
 và cho thông báo cấp quản lý bất kỳ những vấn đề 
 thấy trước. 
 26 
UIT-VNUHCM 2009 
 Ví dụ programmer cần biết: 
 Chức năng của thành phần đơn lẻ của hệ thống 
 và mối tương quan. 
 Mỗi khối lệnh làm gì, kết quả thực hiện (control 
 flow), 
 Tác động qua lại trên đối tượng dữ liệu (data flow) 
  và mục đích tập các câu lệnh (functions) 
 27 
UIT-VNUHCM 2009 
 Thảo luận 
 Exercise 6.1 Mục tiêu đạt được của bạn là gì khi 
 cố găng hiểu chương trình 
 Exercise 6.2 Tại sao hiểu chương trình là quan 
 trọng? 
 Exercise 6.3 Giả sử bạn là lập trình viên, bạn 
 được yêu cầu như sau (i) cung cấp tiện ích quản 
 lý thông điệp cho hệ thống vận hành quản lý thông 
 tin (MIS), và (ii) tích hợp hệ thống MIS vào gói văn 
 phòng tự động. Những thông tin về MIS bạn cần 
 làm gì, có tác động đến thay đổi không? Chỉ ra lý 
 do. 
 28 
UIT-VNUHCM 2009 
 4.3 MÔ HÌNH QUI TRÌNH NẮM BẮT THÔNG TIN 
 Mô hình qui trình nắm bắt thông tin 
 o reading about the program 
 o reading its source code 
 o running it 
 Chiến lược nắm bắt chương trình 
 oTop-Down Model (Brook’s model) 
 oBottom-Up / Chunking Model 
 oOpportunistic Model 
 Bài tập: đọc tìm hiểu các mô hình trên 
 trong tài liệu ebook chính 
 29 
UIT-VNUHCM 2009 
 Mô hình qui trình nắm bắt thôn tin 
 Read about the program 
 o Sưu liệu hệ thống – tài liệu đặc tả và thiết kế 
 o Sơ đồ cấu trúc và dữ liệu và control flow 
 o Phát triển tổng quan và hiểu biết tổng thể hệ thống. 
 o Giai đoạn này có thể bỏ qua nếu tài liệu hệ thống không 
 chính xác, không cập nhật và không tồn tại. 
 30 
UIT-VNUHCM 2009 
 Mô hình qui trình nắm bắt thông tin 
  Read the source code 
 o Cái nhìn toàn cục 
 top-level understanding of the system 
  xác định phạm vi bất kỳ tác động thay đổi có thể 
 có ở phần khác của hệ thống 
 o Xem xét mức cục bộ 
  tập trung vào phần cụ thể của hệ thống. 
  Thông tin về cấu trúc hệ thống, loại dữ liệu, mẫu 
 thuật toán 
 31 
UIT-VNUHCM 2009 
 Mô hình qui trình nắm bắt thông tin 
 Run program 
 o to study the dynamic behavior (Ex: trace data) 
 o reveal some characteristics of the system which are 
 difficult to obtain by just reading the source code. 
 32 
UIT-VNUHCM 2009 
 Mô hình qui trình nắm bắt thông tin 
 Hình 6.2 
 33 
UIT-VNUHCM 2009 
 Các bước nắm bắt thông tin chương trình 
Người lập trình có cách để suy nghĩ, giải quyết vấn 
 đề, chọn lựa kỹ thuật và công cụ. Tuy nhiên có ba 
 bước cơ bản để hiểu chương trình: 
 o Bước 1: Đọc chương trình 
 o Bước 2: Đọc chương trình nguồn (source code) 
 o Bước 3: Chạy chương trình (Run) 
Thảo luận exercise 6.4: Mô hình qui trình nắm bắt 
 thông tin Hình 6.2 (như 3 bước trên) có khác biệt và 
 tương tư với những cách mà bạn đã sử dụng. Nêu 
 rõ lý do? 
 34 
UIT-VNUHCM 2009 
 Mental Models 
  Our understanding of a phenomenon depends on our ability 
 to form a mental representation 
  which serves as a working model of the phenomenon to be 
 understood 
  The content and formation of mental models hinges on 
 cognitive structures and cognitive processes. 
  The mental model is formed after observation, inference or 
 interaction with the target system. 
 35 
UIT-VNUHCM 2009 
 Chiến lược nắm bắt chương trình 
 36 
UIT-VNUHCM 2009 
 Phạm vi kiến thức trong nắm bắt thông tin 
 37 
UIT-VNUHCM 2009 
 Các hướng dẫn cho chương trình 
  Internal to the program text 
 1. Prologue comments, including data and variable dictionaries 
 2. Variable, structure, procedure and label names 
 3. Declarations or data divisions 
 4. Interline comments 
 5. Indentation or pretty-printing 
 6. Subroutine or module structure 
 7. I/O formats, headers, and device or channel assignments 
  External to the program 
 1. Users' manuals 
 2. Program logic manuals 
 3. Flowcharts 
 4. Cross-reference listings 
 5. Published descriptions of algorithms or techniques 
 38 
UIT-VNUHCM 2009 
 Bottom-up 
 39 
UIT-VNUHCM 2009 
 Điểm yếu của top-down và bottoom-up 
 Những điểm yếu chính của cả chiến lược nắm bắt 
 thông tin bằng top-down and bottom-up: 
 o Thiếu xem xét chú ý đến đóng góp những yếu tố như 
 công cụ hỗ trợ sẵn để hiểu chương trình; 
 o Những sự kiện mà qui trình hiểu chương trình hiếm khi 
 tham dự như vai trò các mô hình được định nghĩa tốt. 
 Trái lại người lập trình hướng đến bất kỳ mối liên gắn 
 kết có trước mà được xảy ra như cách tình cờ cơ hội. 
 40 
UIT-VNUHCM 2009 
 Kỹ thuật đọc hiểu 
 Exercise 6.5: Liệt kê những loại khác nhau của 
 chiến lược hiểu chương trình, phân biệt giữa 
 chúng 
 Exercise 6.6: Những chiến lược gì bạn đã dùng 
 và trong những hoàn cảnh nào? 
 41 
UIT-VNUHCM 2009 
 Các yếu tố tác động đến đọc hiểu 
 Phạm vi kiến thức: Chuyên gia, Vấn đề, Ứng 
 dụng, hệ thống 
 Thực nghiệm chương trình, vấn đề thực thi: Độ 
 phân rã, tính môđun, tính che dấu thông tin, Thuật 
 toán, Chương trình, cách đặt tên, ghi chú 
 Tài liệu: bên ngoài, bên trong tổ chức 
 Tổ chức/ thuyết trình: 
 Công cụ hỗ trợ nắm bắt thông tin: công cụ phân 
 tích tĩnh/ động 
 42 
UIT-VNUHCM 2009 
 43 
UIT-VNUHCM 2009 
 Chuyên gia 
 “Experts differ from novices in both their breadth 
 and their organisation of knowledge: experts store 
 information in larger chunks organised in terms of 
 underlying abstractions. This organisation 
 apparently facilitates quick recognition of problem 
 types and recall of associated solution strategies.“ 
 Petre 
 Người lập trình càng có kinh nghiệm phạm vi ứng 
 dụng với ngôn ngữ lập trình, càng dễ và nhanh 
 chóng hiểu chương trình và cũng như toàn bộ hệ 
 thống hiệu quả 
 44 
UIT-VNUHCM 2009 
 Vấn đề thực thi 
 Kiểu/ cách thức đặt tên 
 Ghi chú chương trình 
 Cơ chế phân rã 
 o Phân rã mô đun 
 o Lập trình có cấu trúc 
  Đề xuất document standard và coding standard, 
 phong cách lập trình => viết bằng văn bản thực thi 
 cho nhóm dự án (Bài tập) 
 45 
UIT-VNUHCM 2009 
 Tài liệu 
 Tài liệu hệ thống rất hữu ích và quan trọng bởi nó 
 không chỉ đầu mối liên lạc tác giả gốc của hệ 
 thống thông tin. 
 Đó là phần báo cáo trang trọng trong công nghiệp 
 phần mềm: từ dự án khác, phòng ban, và công ty 
 khác. Như vậy, khi người bảo trì cần truy xuất vào 
 hệ thống tài liệu để có thể hiểu chức năng, thiết 
 kế, thực thi vàvấn đế liên quan đến bảo trì thành 
 công. 
 Đôi khi, tài liệu hệ thống không chính xác, quá lỗi 
 thời chưa cập nhật. Trong trường hợp như vậy, 
 người bảo trì phải thường xuyên xem sưu liệu nội 
 bộ với chính chương trình nguồn – ghi chú 
 chương trình. 
 46 
UIT-VNUHCM 2009 
 Tổ chức/ thuyết minh chương trình 
 Thuyết minh chương được cải tiến có thể cải thiện 
 khả năng hiểu chương trình: 
 Thuận tiện biểu thức rõ ràng và chính xác mô hình 
 chương trình và truyền thông của các mô hình này 
 đối với người đọc chương trình 
 Nhấn mạnh đến luồng kiểm soát, cấu trúc phân 
 cấp chương trình và tính logic và tổng hợp của 
 người lập trình – mục đích gạch dưới cấu trúc và 
 cải thiện tính dễ nhìn của chương trình nguồn qua 
 cách sử dụng ngắt dòng, khoảng trắng, khối và 
 tô bóng 
 47 
UIT-VNUHCM 2009 
 Công cụ hỗ trợ nắm bắt thông tin 
 Có công cụ được sử dụng để tổ chức và thể hiện 
 chương trình nguồn theo cách thực hiện càng rõ 
 ràng càng dễ đọc và như vậy càng dễ hiểu. 
 'Book Paradigm' là pretty-printer, static analyser và 
 browser. 
 Nhiều công cụ đọc hiểu được thiết kế phục vụ trợ 
 giúp cho người đọc hiểu, tăng tốc độ, qui trình 
 hiểu. Tuy nhiên, đầu ra của công cụ này không 
 cung cấp sự giải thích chức năng của mỗi thành 
 phần. Ở đây mô tả Book Paradigm và một số đặc 
 chưng của nó 
 48 
UIT-VNUHCM 2009 
 Ví dụ 
 49 
UIT-VNUHCM 2009 
 Ví dụ Hình 6.10 
 FROM BasicIO IMPORT WriteReal, WriteString, WriteLn, Readlnt, 
 Writelnt; 
 CONST max = 20; 
 VAR a : ARRAY [L.max] OF INTEGER; number: INTEGER; total: 
 INTEGER; 
 BEGIN 
 WriteString("Type in 20 numbers"); number := 0; 
 WHILE number 20 DO number := number + 1; Readlnt (afnumber]); 
 END; 
 WriteString ("The 20 numbers in reverse are "); WriteLn; number := 20; 
 REPEAT Writelnt (a[number]),max); WriteLn; number := number - 1 
 UNTIL number = 0; 
 number := 20 total := 0; 
 WHILE number 0 DO total := total + a[number]; DEC (number); END; 
 WriteString ("The average for the 20 numbers is "); 
 WriteReal (FLOAT (total) / FLOAT (max), 12); 
 END AddNumbers 
 50 
UIT-VNUHCM 2009 
 Bài tập thảo luận 
Exercise 6.7 Liệt kê và giải thích các yếu tố chính tác 
 động đến việc hiểu một chương trình 
Exercise 6.8 Bạn có thể cải thiện khả năng đọc hiểu 
 chương trình Hình 6.10 bằng những cách xử lý nào? 
Exercise 6.9 Liệt kê tất cả công cụ bảo trì đã có trong 
 hệ thống của bạn. Có gắng thử 3 trong những công 
 cụ này, với mỗi loại chức năng chính của chúng là gì 
 và làm thể nào nó cải thiện khả năng đọc. 
Exercise 6.10 Tại sao quan trọng đối với người bảo 
 trì thu được hiểu biết tốt chiến lược nắm bắt chương 
 trình khác nhau và vấn đề dựa trên kinh nghiệm 
 51 
UIT-VNUHCM 2009 
 4.4 REVERSE ENGINEERING 
 Định nghĩa 
 Mục đích và mục tiêu của reverse 
 engineering 
 Các mức của reverse engineering 
 Kỹ thuật hỗ trợ 
 Các lợi ích 
 52 
UIT-VNUHCM 2009 
 Định nghĩa 
Abstraction –là mô hình tóm tắt chi tiết chủ đề được tái 
 thể hiện 
Forward engineering – tiếp cận công nghệ phần 
 mềm truyền thống bắt đầu với phân tích yêu cầu và 
 tiến hành thực thi hệ thống. 
Reengineering – Qui trình kiểm tra và thông báo nơi 
 hệ thống thay đổi lần đầu bởi reverse engineering và 
 sau đó forward engineering. 
Restructuring – chuyển đổi một hệ thống từ hình 
 thức này sang hình thức khác. 
Reverse engineering – Qui trình phân tích một hệ 
 thống: nhận diện thành phần hệ thống và mối liên hệ 
 bên trong và tạo thể hiện hệ thống trong hình thức 
 khác ở mức trừu tượng cao hơn. 
 53 
UIT-VNUHCM 2009 
 Tính trừu tượng 
 Trừu tượng chức năng 
 Trừu tượng dữ liệu 
 Trừu tượng qui trình 
 54 
UIT-VNUHCM 2009 
Mục đích và mục tiêu của reverse engineering 
 Khôi phục thông tin mất mát : 
 To facilitate migration between platforms: 
 Cải thiện và cung cấp sưu liệu : 
 To provide alternative views: 
 Trích rút thành phần có thể dùng lại : 
 Đối phó với độ phức tạp : 
 Dò hiệu ứng phụ: 
 Giảm nỗ lực bảo trì : 
 55 
UIT-VNUHCM 2009 
 Tóm tắt mục tiêu và lợi ích 
 56 
UIT-VNUHCM 2009 
 Các mức của reverse engineering 
 57 
UIT-VNUHCM 2009 
 Các mức của reverse engineering 
 Redocumentation 
 Khôi phục thiết kế 
 Khôi phục đặc tả 
 Những điều kiện cho Reverse Engineering 
 58 
UIT-VNUHCM 2009 
 Kỹ thuật hỗ trợ 
Forward Engineering 
Restructuring 
 o Control-flow-driven restructuring: 
 o Efficiency-driven restructuring: 
 o Adaption-driven restructuring: 
Reengineering 
 59 
 UIT-VNUHCM 2009 
 Bài tập 
 60 
UIT-VNUHCM 2009 
 61 
UIT-VNUHCM 2009 
 Các lợi ích 
 Bảo trì 
 o Corrective Change 
 o Adaptive Change/Perfective change 
 o Preventive Change 
 Tính sử dụng lại phần mềm 
 Reverse Engineering và kỹ thuật kết hợp trong 
 thực nghiệm 
 62 
UIT-VNUHCM 2009 
 Case study 7.8 
 Đọc hiểu case study 7.8 
 Phân tích vấn đề hiện trạng đã nêu: 
 o Vấn đề tự động hóa : 
 o Vấn đề đặt tên : 
 o ??? 
 Thực hiện bài tập theo sau: 
 63 
UIT-VNUHCM 2009 
 Bài tập (1) 
 Exercise 7.1 Giải thích khác nhau giữa những loại 
 khác nhau kỹ thuật reverse engineering và cho ví 
 dụ thích hợp. 
 Exercise 7.2 Thực hiện khôi phục đặc tả và thiết 
 kế trên tất cả hay các phần của hệ thống phần 
 mềm mà bạn không quen (hệ thống nên có ít nhất 
 2K dòng code độ lớn). 
 o Những kỹ thuật bạn dùng nhận diện đặc tả và thiết kế là 
 gì và tại sao? 
 o Những hình thức thể hiện bạn xem là phù hợp cho 
 những tác vụ này là gì? Chỉ ra lý do. 
 o Bài học kinh nghiệm mà bạn đã học được trong các 
 công việc này là gì? 
 64 
UIT-VNUHCM 2009 
 Bài tập (2) 
Exercise 7.3 Một ngân hàng có substantial investment 
 trong hệ thống phần mềm viết bằng Cobol ít nhất 1 
 triệu dòng code và chạy trên 20 năm. Nó được dùng 
 cơ bản mỗi ngày để thực thi thao tác khác nhau như 
 quản lý tài khoản khách hàng và loans. Sau vài năm 
 cập nhật, cả dự định và không hoạch định – hệ thống 
 trở nên quá đắt tiền để bảo trì. Kết quả là, ngân hàng 
 muốn vài lời khuyên ở các bước tiếp để làm. 
 o Giả sử bạn được thuê làm việc như nhân viên tư vấn 
 bảo trì. 
 o Bạn sẽ cho Ngân hàng lời khuyên gì? 
 o Chỉ ra lý do cho bất kỳ đề nghị mà bạn đã thực hiện 
 65 
UIT-VNUHCM 2009 
 Yêu cầu thực hiện tuần tiếp theo 
Viết lại các báo cáo cho các thảo luận trên lớp và các 
 bài tập 
Tiếp tục chuẩn bị công việc cho nhóm 
Mỗi nhóm tự chuẩn bị tìm hiểu và thử nghiệm một 
 trong các công cụ hỗ trợ qui trình bảo trì hướng dẫn 
 sử dụng và demo trước lớp 
Chủ động Đăng ký thuyết trình nhóm với lớp trưởng, 
 để điều phối nhóm thuyết trình ở các buổi học tiếp 
 theo. 
 66 
UIT-VNUHCM 2009 

File đính kèm:

  • pdfbai_giang_phat_trien_van_hanh_bao_tri_phan_mem_chuong_4_cac.pdf