Vận hành phát triên và bảo trì hệ thống

[09520149]

Tổng hợp lại cho các bạn

Giới thiệu
1. Vận hành hệ thống, bảo trì hệ thống là:
- Giai đoạn cuối của chu trình sống của phần mềm
- Không quá trễ thực hiện kế hoạch sau khi hệ thống đã được phát triển
- Độ đo cho vận hành và bảo trì cũng bao gồm nỗ lực phát triển hệ thống
- Nhằm đạt mục tiêu cho chuẩn bị vận hành và bảo trì hiệu quả
2. Chi phí thời gian sống hệ thống phần mềm liên quan đến bảo trì
- REQUIREMENTS ANALYSIS ( 3 % )
- SPECIFICATION (3 % )
- DESIGN ( 5 % )
- CODING ( 7 % )
- TESTING ( 15 % )
DEVELOPMENT PHASES
- OPERATION AND MAINTENANCE ( 67 % ) => PRODUCTION PHASES
3. Thành phần Quản lý đòi hỏi cho vận hành hệ thống
- Quản lý tài nguyên (Resource Management)
- Quản lý vấn đề( Problem Management)
- Quản lý tiện nghi (Facility Management)
- Quản lý bảo mật (Security Management)
- Quản lý vận hành (Performance Management)
- Quản lý chi phí (Cost Management)
4. Cần có kiến thức chính xác về tài nguyên đòi hỏi cho vận hành dùng tài nguyên
hệ thống hiệu quả
- Tài nguyên Hardware
- Tài nguyên Software
- Tài nguyên dữ liệu
- Tài nguyên mạng (network)
5. Quản lý tài nguyên hardware
- Kiểm tra các thiết bị hardware sử dụng như thế nào?
- Việc sắp xếp tài nguyên hardware được lưu ý để phân phối tốt
- Sử dụng tài nguyên hiệu quả để tăng tốc độ vận hành cho mỗi thiết bị phần
cứng
- Thiết bị dùng nhiều hơn một giai đoạn nhất định thường gây ra vấn đề
- Xem xét việc thay thế thiết bị - kiểm tra vấn đề phát sinh dựa trên dữ liệu thu
thập:
Tốc độ phản hồi
Khả năng xử lý (số thành phần theo giờ)

6. Tài nguyên phần mềm (software)
- Chỉ định quản lý chương trình đang chạy trên hệ thống
Quản lý thư viện
Nơi lưu trữ vật lý xác định (bao gồm backup)
Phiên bản dữ liệu (tránh tồn tại phiên bản mới và cũ nên
tránh)
Thư viện được bảo vệ (cho bảo mật, và từ virus)
Ngăn sử dụng vi phạm
Việc sao chép được và không được phép
Tài nguyên phần mềm được dùng nên quản lý như thế nào?
7. Quản lý tài nguyên dữ liệu
- Quản lý dữ liệu có hệ thống
- Chọn lựa dữ liệu quan trọng cho quản lý đặc biệt mục đích bảo mật tốt
Bảo mật hoàn chỉnh
Đảm bảo bảo mật (ngăn sử dụng bất hợp lệ)
Quản lý có hệ thống tài nguyên dữ liệu
8. Quản lý tài nguyên mạng (network)
- Thiết bị nối kết mạng như CCU (communication Control Unit), DCE (Data
circuit Terminating Equipment
- Tổ chức quản lý bao gồm nhà cung cấp viễn thông được thiết lập
9. Quản lý vấn đề
- Lưu ý: không phải hệ thống nào là không có vấn đề
- Làm thế nào hệ thống có thể khôi phục sau khi sự cố xảy ra.
- Thủ tục chuẩn thực thi khi sự cố xảy ra: (Thảo luận)
Tìm và báo cáo sự cố
Tạo những báo cáo sự cố
Phân tích sự cố
Thực thi khôi phục từ một vấn đề
Công việc phục hồi hệ thống
- Thảo luận vấn đề trên đưa ra giải pháp – công cụ áp dụng mang lại hiệu quả --
Mind Mapping , Fishbone model …?
10. Tìm và báo cáo sự cố
- Sự cố phát hiện càng sớm động hệ thống nhỏ hơn và sớm đo lường,đánh giá
- Chú ý đến dữ liệu được thu thập trong quản lý tài nguyên sắp xếp trình tự hoạt
động các tình huống
- Thiết lập tổ chức quản lý cho phép sự cố được báo cáo đến cấp quản lý
-

11. Tạo những báo cáo sự cố
- Cần sử dụng báo cáo:
Cho phân tích vấn đề và đo lượng độ chính xác
Một dữ liệu thống kê tiện ích để ngăn ngừa trước vấn đề
12. Phân tích sự cố
- Điều tra nguyên nhân gây ra vấn đề:
Từ hardware: xem logged data tại thời điểm xảy ra sự cố, danh sách dump
được phát sinh.
Liên quan software
Một số tìm thấy nguyên nhân thực sự xảy ra sau đó
- Nếu data log hay dump data không tìm hiệu quả thì:
Tình huống được tại lập do người tác động
Đo lường nếu sự cố tương tự xảy ra lần nữa, cho phép dữ liệu chi tiết thu
được
- Rõ ràng nguyên nhân vấn đề được ngăn xảy ra vấn đề tương tự lần nữa
13. Công việc phục hồi từ vấn đề
- Dựa trên nguyên nhân vấn đề, các phương pháp khôi phục hệ thống được xác định
và khôi phục vận hành
Hardware:
Thiết bị backup được dùng
Thiết bị có vấn đề tách biệt
Software:
Phần mềm tái hoạt động
Phiên bản cũ hơn được khôi phục thay cho phiên bản hiện tại
Hiệu chỉnh thực hiện phần mềm hiện tại
Data:
Thay thế và cập nhật dữ liệu gây ra vấn đề
Roll-back hay roll-forward
Hơn nữa, lưu giữ báo cáo việc khôi phục được thực hiện cho phép tài liệu
được xem xét cho những vấn đề tương tự xảy ra sau đó
14. Công việc phục hồi hệ thống
- Hệ thống được khôi phục, kiểm tra xem các chức năng vận hành bình thường.
- Từ thuộc cách khôi phục, các tình huống cần xem xét:
Hardware: khi backup xem xét
Tốc độ so sánh với hardware chính
Khôi phục
Software

Giảm mức các chức năng
Giới hạn sử dụng được xem xét khả năng phản hồi
Data
Dữ liệu được hiệu chỉnh phải phù hợp, nếu dữ liệu chính xác
- Công việc phục hồi được tiếp tục cho đến khi tất cả chức năng được khôi phục
15. Quản lý tiện nghi
- Để vận hành hệ thống máy tính, các tiện nghi và thiết bị được duy trì ở mức độ
chất lượng nhất định
Tiện nghi liên quan cung cấp điện
Nguồn cung cấp chính, bổ trợ, UPS …
Khác: pin, tiện ích phân bố điện…
Máy điều hoà
Tiện nghi ngăn chặn xảy ra rủi ro
Tiện nghi chống lửa, động đất, thiết bị thông báo khẩn cấp
Tiện nghi ngăn tội phạm
Thiết bị kiểm soát vào ra, máy điều khiển
Tiện nghi lưu trữ
Bảo mật mức cao nhất chống dữ liệu mất cắp, ngăn hiểm hoạ,
ngăn lửa, nước
16. Quản lý bảo mật
- Mục tiêu đảm bảo sử dụng trái phép hệ thống và rò rỉ thông tin trong vận hành :
Quản lý người dùng
Quản lý truy cập
Quản lý sử dụng
Data thu thập: User name, Use date, Use time (login, logout
time , Terminals used, System used, Resource used
Các kỹ thuật liên quan mã hoá
17. Quản lý tốc độ
- Mục tiêu kiểm tra tốc độ vận hành hệ thống và kiểm tra dịch vụ đạt yêu cầu
chuẩn?
- Thành phần cần quản lý:
Thời gian phản hồi và lần thay đổi
Đầu vào
Thời gian sẵn sàng (bắt đầu và kết thúc)
Số tối đa vận hành ngừng
Chất lượng dữ liệu output
SLA (Service Level Agreement) của mạng

Thu thập và phân tích dữ liệu để đảm bảo xác định tốc độ mong cho hệ thống được
bảo trì
- Chú ý đến phản ánh của người dùng liên quan tốc độ khó nhận biết bởi đo đạc đơn
giản
- Kiểm tra yếu tô bên ngoài
18. Quản lý chi phí
- Chi phí đóng vai trò quan trọng tăng lợi nhuận
Chi phí khởi đầu: chi phí trong giai đoạn cài đặt
Mua sắm chi phí thiết bị
Mua sắm chi phí phần mềm
Chi phí phát triển phần mềm
Chi phí hoạt động (running cost)
Chi phí thuê mướn
Phí license phần mềm (cơ bản, package software)
Chi phí bảo trì (hardware & software)
Chi phí bảo trì thiết bị
Chi phí thêm vào
Chi phí nhân sự
19. Quản lý vận hành khác
- Vận hành hệ thống
Vận hành thủ công, mô tả phương pháp, thủ tục vận hành
Liệt kê kiểm soát công việc (job schedule)-> xử lý tự động
Kiểm soát đầu vào đầu ra
- Công cụ vận hành hệ thống
Công cụ vận hành tự động
Công cụ kiểm soát
Công cụ chuẩn đoán
- Chuyển giao hệ thống
Chuẩn bị kế hoạch chuyển giao
Chuẩn bi kế hoạch thủ tục chuyển giao thủ công
Thực hiện các công việc chuyển giao
Kiểm tra vận hành
Chuyển giao các công đoạn vận hành
-

(Bảo trì)
20. Bảo trì hệ thống
- Bảo trì là gì
- Tầm quan trọng của việc bảo trì
- Chi phí bảo trì
- Nhiệm vụ của bảo trì
- Tổ chức bảo trì
- Các loại bảo trì
- Bảo trì phần mềm và phần cứng
21. Bảo trì phần mềm
- Hệ thống được phát triển theo mô hình thác nước (water fall)
- Hệ thống phải được hiệu chỉnh nếu có bug (error)
- Khi người dùng yêu cầu thay đổi đặc tả hệ thống
- Việc hiệu chỉnh hay cập nhật được gọi là bảo trì
22. Nhiệm vụ của bảo trỉ
- Truyền thông giữ phía người dùng và phía phát triển
Bài tập: Thảo luận nhóm vấn đề <??> người dùng và phía phát triển (15
phút) phác hoạ sơ đồ để diễn giải
- Đo lường bởi phía phát triển và phía người dùng
- Tác vụ của bảo trì phần mềm
23. Giới thiệu bảo trì
- Định nghĩa
- Phát triển mới và hoạt động bảo trì khác nhau ?
- Tại sao phần mềm cần phải bảo trì?
- Duy trì hệ thống một cách hiệu quả
- Phân loại sự thay đổi phần mềm
24. Khái quát chung
- Khái niệm cơ bản
- Khung làm việc của bảo trì
- Nền tảng sự thay đổi phần mềm
- Vấn đề liên quan giới hạn và kinh tế
- Mô hình qui trình bảo trì
25. Ngữ cảnh bảo trì phần mềm
- Tìm kiếm chi tiết điều gì xảy ra trong qui trình bảo trì
- Cung cấp nền tảng hỗ trợ trong xây dựng tốt hệ thống phầnmềm
- Hiểu rõ cơ sở lý thuyết và ngữ cảnh vận hành

Nghiên cứu nền tảng phần mềm với những giới hạn và ràng buộc qua mô hình qui
trình bảo trì
26. Nhu cầu của bảo trì phần mềm
- Đảm bảo phần mềm vẫn thoả mãn yêu cầu của khách hàng.
- Bảo trì thích hợp đối với phần mềm phát triển sử dụng mô hình vòng đời phần
mềm (mô hình xoắn ốc).
- Hệ thống thay đổi để hiểu chínhvà không hiệu chính những hành động phần mềm.
Bảo trì thực hiển để
Hiệu chỉnh lỗi
Cải tiến thiết kế
Thực thi cải tiến
Giao diện với hệ thống khác
Thích nghi chương trình sao cho tiện nghi hardware, software, system
features, and telecommunications khác được dùng
Chuyển đổi phần mệm hợp lệ
Không lưu hành phần mềm
- Hoạt động của người bảo trì gồm 4 key chính theoPfleeger:
Duy trì kiểm soát software’s day-to-day functions
Duy trì kiểm soát qua sự cập nhật phần mềm
Hoàn chỉnh chức năng tồn tại
Ngăn tốc độ phần mềm từ suy giảm mức độ không thể chấp nhận được
27. Tại sao bảo trì phần mềm
- Cung cấp tính liên tục của dịch vụ
- Hỗ trợ việc nâng cấp bắt buộc
- Hỗ trợ yêu cầu người dùng cho việc cải tiến
- Thuận tiện cho công việc bảo trì trong tương lai
28. Phân loại thay đổi phần mềm
- Sự thay đổi khởi đầu bởi dò lỗi trong phần mềm
- Thay đổi dẫn xuất từ nhu cầu cung cấp thay đổi môi trường của hệ thống phần
mềm
- Thay đổi dưới tác động mở rộng yêu cầu tồn tài của hệ thống
- Thay đổi dưới ngăn cản sai lệch chức năng
29. Maintenance Framework
- Định nghĩa
- Software maintenance framework
Cấu thành của Framework
Người dùng (User)
-

Môi trường (Environment)
Môi trường vận hành
Môi trường tổ chức
Qui trình bảo trì
- Sản phẩm phần mềm
- Nhân sự trong bảo trì
- Mối liên hệ giữa các yếu tô trong bảo trì
30. Khung làm việc của bảo trì phần mềm
- Yêu cầu người dùng
- Môi trường tổ chức
- Môi trường vận hành
- Qui trình bảo trì
- Sản phẩm phần mềm
- Nhân sự phần mềm
31. Quy trình bảo trì
- Nắm bắt thay đổi yêu cầu
- Biến đổi thực nghiệm chương trình
- Dịch chuyển tiến hoá
- Tiến hoá “death” cho hệ thống “living”
- Dò lỗi và hiệu chỉnh lỗi
32. Các tác vụ của bảo trì phần mềm
- Thực thi qui trình
- Phân tích vấn đề và cập nhật thay đổi
- Thực hiện thay đổi
- Chấp nhận/Xét duyệt việc bảo trì
- Migration
- Loại bỏ (cho về hưu) phần mềm
33. Các hoạt động của bảo trì
- Unique activities
- Supporting activities
- Maintenance planning activity
- Software configuration management
- Software quality
- Techniques for Maintenance
- Program Comprehension
- Reengineering
- Reverse engineering

44. mối liên hệ giữa các yếu tố
- Liên hệ giữa sản phẩm và môi trường
- Liên hệ sản phẩm và người dùng
- Tương tác giữa nhân sự và sản phẩm
Nền tảng của sự thay đổi phần mềm
-
Nền tảng của sự thay đổi phần mềm
1. Sự thay đổi phần mềm
- Tiến hoá phần mềm
Loại phần mềm
Luật tiến hoá
2. Phân loại những thay đổi
- Thay đổi hiệu chỉnh (Corrective Change)
- Thay đổi thích nghi (Adaptive Change)
- Thay đổi hoàn chỉnh (Perfective Change)
- Thay đổi ngăn ngừa (Preventive Change)
3. Nguồn của sự thay đổi
- Những điều kiện kinh doanh và thị trường mới gây ra thay đổi những yêu cầu
sản phẩm và qui tắc nghiệp vụ (business rules)
- Khách hàng mới cần thay đổi nhu cầu dữ liệu, chức năng hay dịch vụ phân
phối bởi hệ thống
- Tái tổ chức hay cắt giảm kinh doanh mà thay đổi ưu tiên và cấu trúc nhóm
(team)
- Ràng buộc ngân sách và lịch trình gây ra tái định nghĩa hệ thống
- HẦU HẾT SỰ THAY ĐỔI LÀ CÓ LÝ DO CHÍNH ĐÁNG
4. Bảo trì và SDLC
- Qui trình phát triển phần mềm Waterfall, chúng ta có hộp ở mỗi cuối qui trình
và được bỏ qua trong mô tả qui trình
- Chu trình cải tiến hơn như Spiral Model,bảo trì phù hợp nhiều vị trí nổi bật
- Bảo trì vẫn liên quan đến khía cạnh của SDLC
5. Loại chương trình
- Chương trình S-type (“Specifiable”)
Vấn đề được khẳng định hình thức và hoàn chỉnh
Chấp nhận: Chương trình có chính xác như đặc tả của nó?
Phần mềm này không tiến triển.

-
Thay đổi đặc tả định nghĩa vấn đề mới, như vậy một chương
trình mới
Chương trình P-type (“Problem-solving”)
- Khẳng định không chính xác vấn đề thế giới thực
- Chấp nhận: Chương trình là giải pháp có thể chấp nhận đối với vấn đề?
- Phần mềm này xem như tiến triển liên tục
Bởi giải pháp không bao giờ hoàn hảo, và có thể cải tiến
Bởi thế giới thực thay đổi và vấn đề thay đổi
Chương trình E-type (“Embedded”)
a. Một hệ thống trở thành một phần thế giới nó được mô hình hoá
b. Chấp nhận: phụ thuộc toàn bộ vào ý kiến và phán xét
c. Phần mềm này vốn đã tiến hoá
Thay đổi trong phần mềm và thế giới tác động lẫn nhau
6. Loại bảo trì
- Làm thế nào và tại sao chúng ta tốn khá nhiều thời gian và nỗ lực cho việc bảo
trì?
- Bảo trì thì nhiều vấn đề hơn việc fix bug
- Phân chi thành ba loại chính
Corrective Maintenance (bảo trì hiệu chỉnh)
Adaptive Maintenance (Bảo trì thích nghi)
Perfective Maintenance (Bảo trì hoàn chỉnh)
- Ranh giới giữa các loại bảo trì khá mờ không rõ
- Chúng ta có thể định nghĩa các loại bảo trì khác – bảo trì ngăn ngừa
7. Bảo trì hiểu chỉnh (Corrective Maintenance)
- Tập trung vào fix lỗi
- Là qui trình có phản ứng lại
Lỗi và lỗi kết hợp nói chung cần được chính xác ngay lập tức hay trong
tương lai gần
- Lỗi biến đổi theo chi phí để hiệu chỉnh:
Coding – thường tương đối rẻ
Design – Khá tốn kém khi chúng có thể đòi thay đổi vài thành phần
chương trình
Requirements – Tốn kém nhất – có lẽ đòi tái thiết kế hệ thống mở rộng
- Thiết kế và Yêu cầu là nguồn chiếm khoảng 80% lỗi
- Hiệu chỉnh lỗi có 20 đến 50% cơ hội đưa ra lỗi khác
-

Nguyên nhân lỗi mới gồm :
Dấu vết tác động nơi mà sự thay đổi ở một nơi gây ra sự thay đổi vùng
dường như không liên quan
Người sửa lỗi nói chung không phải là người viết code hay thiết kế hệ
thống
- Hai loại bảo trì hiệu chỉnh
Sửa chữa khẩn cấp – thời gian ngắn- thường chương trình đơn, lỗi cần
được sửa sớm như có thể
Sữa chữa theo lịch trình - lỗi không cần chú ý ngay, kiểm tra lại tất cả
sữa chữa khẩn cấp
8. Bảo trì thích nghi(Adaptive Maintenance)
- Tiến hoá hệ thống nhằm đạt nhu cầu người dùng và doanh nghiệp
- Gây ra bởi
Nhu cầu nội bộ
Canh trạnh bên ngoài
Những yêu cầu ngoài ví dụ thay đổi Luật
- Cần thiết đưa ra những yêu cầu mới cho hệ thống
- Như vậy chúng ta nên xử lý giống như phát triển mới theo hướng tiếp cận và
phương pháp
9. Bảo trì hoàn chỉnh (Perfective Maintenance)
- Thành ngữ xưa “Nếu không hỏng, thì không sửa nó”
- Bảo trì hoàn chỉnh bỏ qua câu thành ngữ xưa
- Cải thiện chất lượng chương trình sẳn sàng hoạt động
- Mục tiêu đạt được
Giảm chi phí trong sử dụng hệ thống
Tăng khả năng bảo trì hệ thống
Gần hơn nhu cầu người dùng
- Gồm tất cả nỗ lực để trau chuốt hay cải tiến chất lượng phần mềm và sưu liệu
- Important that the potential benefits of the perfective maintenance outweigh
Chi phí của bảo trì
Và chi phí cơ hội của cải tiến nơi khác hay dùng tài nguyên trong phát
triển mới
- Như vậy, trước khi thực hiện bảo trì hoàn chỉnh,đầu tiên nên qua tiến trình
phân tích
- Tuy nhiên, bảo trì hoàn chỉnh bé có thể những ảnh hưởng
10. Bảo trì ngăn ngừa (Preventative Maintenance)
- Có thể thấy như bảo trì hoàn chỉnh mức cơ bản hay một sự lựa chọn để bảo trì
-

Được biết như Software Re-engineering
Nắm giữ hệ thống và chuyển đổi cấu trúc hay chuyển đổi thành ngôn ngữ mới
Hệ thống cữ bắt đầu như đặc tả cho hệ thống mới
Phương pháp chung được biết như vỏ bọc mà toàn hệ thống được thay bởi vỏ
bọc OO và được xử lý như đối tượng lớn
11. Sự lựa chọn để bảo trì
- Đôi khi, bảo trì không thoả mãn chính nó
- Tái cấu trúc không hoàn chỉnh tích hợp với bảo trì thích nghi
Dùng để cải tiến có thứ tự với mỗi phiên bản hệ thống
- Hoàn chỉnh sắp xếp lại hoặc xem xét toàn bộ code toàn tại
Dùng hệ thống thiên về bảo trì mức độ cao
- Hoàn chỉnh tái thiết kế và viết lại
Dùng khi nhiều hơn 20% chương trình phải thay đổi
Dùng khi chương sẽ được nâng cấp cho công nghệ mới
Không dùng khi thiết kế và và chức năng của hệ thống không được biết
- Từ bỏ hệ thống và hoàn chỉnh tái phát triển
Dùng khi chuyển qua công nghệ mới
Dùng khi chi phí bảo trì phần mềm và phần cứng đạt đến chi phí của tái
phát triển
12. Qui trình bảo trì phần mềm
- Thực hiện sự thay đổi
Thay đổi thiết kế
Coding
Kiểm thử Testing – phải thực hiện regression testing
- Phiên bản hệ thống bao gồm
Sưu liệu
Phần mềm
Huấn luyện
Thay đổi phần cứng
Chuyển đổi dữ liệu
13. OnGoing Support
- Truyền thông hiệu quả
Thiết lập mối liên hệ tốt với khách hàng
Hiểu rõ nhu cầu khác hàng
Tránh ra quyết định trái ngược yêu cầu khách hàng
- Huấn luyện end-user
Hỗ trợ người dùng dễ dàng hiểu, ex: phone online queries
-
-
-
-

Cung cấp thông tin kinh doanh
Thông tin chính xác để thể hỗ trợ ra quyết đinh chiến lược
14. Các luật của Tính tiến hoá chương trình
- Continuing Change
o Any software that reflects some external reality undergoes
continual change or becomes progressively less useful
The change process continues until it is judged more cost
effective to replace the system entirely
- Increasing Complexity
o As software evolves, its complexity increases…
…unless steps are taken to control it.
- Fundamental Law of Program Evolution
o Tiến hoá của phần mềm là qui định tự nó với hướng có thể xác
định và không thay đổi theo thống kê
- Conservation of Organizational Stability
o Trong suốt hoạt động thực sự của hệ thống phần mềm, đầu ra
công việc của một dự án phát triển là gần không đổi (xem như tài
nguyên)
- Conservation of Familiarity
o Trong suốt hoạt động thực sự của một chương trình số lượng
thay đổi trong những phiên bản kế tiếp gần không đổi
Mối liên hệ kinh tế của việc cập nhật phần mềm
- Giới hạn đối với sự thay đổi
- Hạn chế tài nguyên
- Chất lượng của hệ thống tồn tại
- Chiến lược tổ chức
- Tính trì trệ (không thay đổi)
1. Chi phí bảo trì
- Một nghiên cứu đưa ra
Định nghĩa yêu cầu 3%
Thiết kế sơ bộ3%
Thiết kế mức chi tiết5%
Thực thi7%
Kiểm thử15%
Bảo trì67%
- Nghiên cứu khác đưa ra ít nhất 50% nỗ lực chi cho bảo trì
- Nghiên cứu khá tìm thấy khoảng giữa 65% và 75% cho bảo trì
-

Những hệ thống nhúng thời gian thực, chi phí bảo chỉ chiếm gấp 4 lần chi phí phát
triển
2. Tại sao bảo trì tốn kém?
- Hầu hết phần mềm có từ 10 and 15 năm
- Nhiều phần mềm chỉ tuổi nó được tạo bởi kích thước chương trình và không gian
lưu trữ là những yêu tố quan trọng hơn
- Điều này dẫn đến không thay đổi thiết kế, code, và sưu liệu
- Bảo trì được thực hiện bởi đội ngũ không có kinh nghiệm và không quen với ứng
dụng
- Người phát triển không thích bảo trì
- Thay đổi thường gây ra lỗi mới trong hệ thống
- Thay đổi hướng làm manh mún cấu trúc chương trình
- Thay đổi thường không được ghi sưu liệu
3. Yếu tố tác động đến chi phí bảo trì
- Tính độc lập module
Khả năng thay đổi một phần hệ thống
Thuận lợi tiềm năng của OO
- Ngôn ngữ lập trình
Mức độ ngôn ngữ lập trình càng cao, càng bảo trì rẻ hơn
C – ngôn ngữ chữ viết :-)
- Kiểu chương trình
Cách thức một chương trình được viết
- Đánh giá và kiểm thử chương trình
Càng nhiều thời gian và nỗ lực chi cho đánh giá thiết kế và chương trình,
lỗi càng ít và nhu cầu bảo trì hiệu chỉnh càng ít hơn
- Chất lượng sưu liệu chương trình
Sưu liệu càng tốt, việc bảo trì càng dễ dàng
- Kỹ thuật quản lý cấu hình
Lưu vết tất cả tài liệu hệ thống và đảm bảo chúng phù hợp thì chi phí chính
của bảo trì, như vậy công cụ quản lý cấu hình (CM tools) và thực tế giảm
chi phí này
- Phạm vi ứng dụng
Càng ít hiểu phạm vi được hiểu kỹ, the less well-understood the domain,
nhu cầu có thể xảy ra càng lớn cho bảo trì thích nghi như người dùng và
người phát triển bắt đầu hiểu phạm vi
- Ổn định đội ngũ
-

Chi phí bảo trì giảm nếu người phát triển phải bảo trì chính hệ thống của
họ, thường qua chu kỳ sống của hệ thống
- Tuổi hệ thống
Hệ thống càng cũ, càng nhiều mức độ manh mún và khó bảo trì
Lôi cuốn đội ngũ người biết hệ thống cũ ngôn ngữ, DB, vận hành trở nên
khó hơn và nhiều kinh nghiệm
- Phù thuộc hệ thống và môi trường ngoài
Sự phụ thuộc càng cao,càng nhiều bảo trì thích nghi được cần
- Độ ổn định phần cứng
Nếu platform phần cứng sẽ không thay đôi qua thời gian hệ thống, bảo trì
cho nguyên nhân này sẽ không cần
4. Khác nhau giữa bảo trì và phát triển mới
- Ràng buộc của hệ thống tồn tại
Thay đổi phải phù hợp hay tương thích với kiến trúc tồn tại, thiết kế, ràng
buộc mã nguồn
- Khung thời gian ngắn hơn
Phát triển khoảng 6 tháng trở lên
Bảo trì tính giờ hay ngày cho đến 6 tháng
- Tính sẵn sàng dữ liệu kiểm thử
Phát triển tạo tất cả dữ liệu từ hỗn tạp
Bảo trì dùng dữ liệu kiểm tra tồn tại với regression testing, tạo dữ liệu mới
từ sự thay đổi
5. Giải pháp tiềm năng đối với vấn đề bảo trì
- Tái cấp phát Ngân sách và Nỗ lực (Effort)
Ít tài nguyên để phát triển cho hệ thống khó bảo tri và khó, ngược lại đầu tư
nhiều cho phát triển, đặc tả và thiết kế với hệ thống có thể bảo trì
Sử dụng nhiều đặc tả yêu cầu thiết kế trước đã phê duyệt, kỹ thuật thiết kế,
công cụ, chất lượng đảm bảo tiêu chuẩn ISO … làm hệ thống có thể bảo trì
hơn
- Hoàn chỉnh thay thế hệ thống
Ràng buộc kinh tế
Lỗi thường trú trong hệ thống mới
Cơ sở dữ liệu của thông tin
- Bảo trì hệ thống tồn tại
6. Những vấn đề đối mặt của người bảo trì
- 5 vấn đề hàng đầu:
(Kém) Chất lượng sưu liệu

Nhu cầu người dùng cho việc cải tiến và mở rộng
Nhu cầu đối đầu thời gian người bảo trì
Khó khăn trong trong buổi họp cam kết lịch trình
Doanh thu trong tổ chức người dùng
- Sự hiểu biết hạn chế
47% nỗ lực bảo trì phần mềm dành cho hiểu phần mềm
Thí dụ: nếu một hệ thống có m thành phần và chúng ta cần thay đổi
k trong chúng …
…Có k*(m-k) + k*(k-1)/2 giao diện kiểm tra tác động
Cùng , >50% nỗ lực đóng góp cho sự thiếu hiểu biết của người dùng
I.e. báo cáo không hoàn chỉnh và sai lầm của lỗi và cải tiến
- Tinh thần Thấp
Bảo trì phần mềm được xem xét như ít thích thú hơn việc phát triển
7. Cách tiếp cận bảo trì
- Triết lý bảo trì
“throw-it-over-the-wall” – người nào khác chịu trách nhiệm cho bảo trì
Đầu tư kiến thức và kinh nghiệm là uổng phí
Bảo trì trở thành thách thức reverse engineering
“mission orientation” – nhóm phát triển thực hiện cam kết giới hạn để bảo
trì phần mềm
- Mô hình qui trình bảo trì của Basili:
Quick-fix model
Thay đổi làm ở mức lập trình (code) dễ dàng có thể
Phân rã (manh mún) nhanh cấu trúc của phần mềm
Iterative enhancement model
Thay đổi thực hiện dựa trên phân tích hệ thống tồn tại
Cố gắng kiểm soát độ phức tạp và duy trì thiết kết tốt
Full-reuse model
Bắt đầu bằng những yêu cầu hệ thống mới, tái sử dụng nhiều như có
thể
Cần tăng trưởng văn hoá dùng lại để thành công
8. Làm trẻ lại phần mềm
- Redocumentation
Tạo hay xem lại những thể hiện sự thay đổi phần mềm
Tại cùng mức độ của trừu tượng hoá
Phát sinh :

Bảng giao diện dữ liệu, đồ hình gọi hàm, thành phần/biến qua bảng
tham chiếu etc.
- Restructuring
Chuyển dịch phần code của hệ thống mà không thay đổi hành vi
- Reverse Engineering
Phân tích hệ thống để chính xác thông tin về hành vi hay cấu trúc
Cũng khôi phục thiết kế - Tạo lại trừu tượng thiết kế từ code, tài liệu,
và kiến thức phạm vi
Phát sinh:
Sơ đồ cấu trúc, lược đồ quan hệ thực thể, DFD, mô hình yêu cầu
- Reengineering
Kiểm tra và thông báo hệ thống khôi phục nó trong hình thức khác
Cũng cần biết như nâng cấp, phân loại lại
9. Reuse
- Dùng lại phần mềm để cắt giảm chi phí
Phát triển phần mềm tốn kém, vì vậy dùng lại cho những hệ thống liên quan
Hướng tiếpcận thành công tập trung sử dụng lại tri thức và kinh
nghiệm hơn sản phẩm phần mềm
Tính kinh tế việc dùng lại là phức tạp khi nó tốn nhiều hơn để phát
triển reusable software
- Thư viện của thành phần có thể sử dụng lại
Thư viện phạm vi cụ thể (e.g. Math libraries)
Thư viện phát triển chương trình (e.g. Java AWT, C libraries)
- Domain Engineering
Phân chia phát triển phần mềm thành 2 phần :
Phân tích phạm vi – nhận diện thành phần dùng lại có chung đặc
điểm cho một phạm vi vấn đề
Phát triển ứng dụng – dùng thành phần phạm vi cho ứng dụng cụ
thể.
- Họ phần mềm
Nhiều công ty đề nghị dãy các hệ thống phần mềm liên quan
Chọn kiến trúc ổn định cho họ phần mềm
Nhận diện sự đa dạng cho những thành viên khác nhau trong họ
Thể hiện quyết định chiến lược kinh doanh về phần mềm gì để phát triển
10. Thúc đẩy đội ngũ bảo trì
- Thường xem xét đến dead-end trong tổ chức cũng như sự chán nản
- Quyết định đến sự thành công của tổ chức

-
Chiến lược có thể
Cặp mục tiêu phần mềm và mục đích của tổ chức
Cặp Phần thưởng bảo trì phần mềm với thực hiện tổ chức
Tích hợp nhân sự bảo trì phần mềm với nhóm vận hành
Tạo biện pháp, hoàn chỉnh/ngăn ngừa, ngân sách bảo trì cho phép nhóm
bảo trì quyết định khi re-engineer hệ thống
Lối kéo độ ngũ bảo trì sớm trong qui trình phần mềm trong suốt chuẩn bị
qui chuẩn, review, và chuẩn bị kiểm thử
CÁC CÔNG CỤ BẢO TRÌ
1. Các công cụ
- CÔNG CỤ BẢO TRÌ
Giới thiệu & Định nghĩa
Điều kiện cho chọn lựa công cụ
- Taxonomy of tools
- Công cụ đọc hiểu và reverse engineering
Program Slicer
Static Analyser
Dynamic Analyser
Data Flow Analyser
Cross-Referencer
Dependency Analyser
Transformation Tool
- CÔNG CỤ HỖ TRỢ KiỂM THỬ
Công cụ mô phỏng giả lập (Simulator)
Bộ phát sinh test case (Generator)
Bộ phát sinh Test Paths (Generator)
- CÔNG CỤ ĐỂ HỖ TRỢ QuẢN LÝ CẤU HÌNH
Source Code Control System
Other Utilities
2. Tiêu chí chọn lựa công cụ
- Có một vài nhà cung cấp phát triển mở rộng thị trường các công cụ rất đa dạng hỗ
trợ bảo trì phần mềm. Một số yếu tố khi xem xét chọn lựa
Khả năng: hỗ trợ tác vụ thực thi (tính tự động, hay làm tay)
Chức năng: xem xét tính năng tự động
Chí phí và lợi ích:

Platforms: Win, Linux, …
Ngôn ngữ lập trình: hỗ trợ ngôn ngữ Java, Ada, C, C++,Cobol, Fortran,
Modula-2, Lisp and Prolog, …
Tính dễ dụng: ví dụ: command line or menu-driven
Tính mở của kiến trúc:tính mở rộng và khả chuyển của CASE-tools
Tính ổn định của nhà cung cấp
Văn hoá tổ chức: a working culture và work patterns. Để tăng cơ hội công
cụ được chấp nhận bởi người dùng cuối, cần thiết xem xét đển văn hoá và
mẫu công việc
3. Taxonomy of Tools
- Phân loại tác vụ cho công cụ được thảo luận dựa trên :
Khả năng nắm bắt chương trình và reverse engineering
Kiểm thử
Quản lý cấu hình
Sưu liệu và độ đo.
- Đọc thêm tài liệu giới thiệu về Taxonomy of Tools
4. Công cụ đọc hiểu và reverse engineering
- Program Slicer
- Static Analyser
- Dynamic Analyser
- Data Flow Analyser
- Cross-Referencer
- Dependency Analyser
- Transformation Tool
- Yêu cầu các nhóm
Xem định nghĩa các công cụ này ở ebook
Tìm hiểu các công cụ trên tìm phần mềm nguồn mở hỗ trợ các tính
năng công cụ này.
Xem xét các CASE-tools có sẵn hỗ trợ tính năng này
QUI TRÌNH VÀ MÔ HÌNH BẢO TRÌ PHẦN MỀM
1. Thảo luận Waterfall Model
- Thuận lợi
Process visibility
Separation of tasks
Quality control at each step
Cost monitoring at each step

-
2.
-
-
3.
-
-
-
-
-
-
-
4.
5.
Không thuận lợi
Mỗi giai đoạn trong quá trình này cho thấy sự hiểu biết mới của giai đoạn
trước đó, thường đòi hỏi giai đoạn trước đó được sửa đổi
Tính tuần tự của các quy trình
Mô hình thuần tuần tự thì không thể
Kế hoạch phải được cho phép cho những hình thành từ bước lặp.
Mô hình Life-Cycle khác
Build-and-fix model
Rapid prototyping model
Incremental model
Extreme programming
Component-based software engineering
Mô hình đồng bộ hoá và ổn định (Synchronize-and-stabilize) model
Object-oriented life-cycle models
Lưu ý
- Hầu hết phần mềm được phát triển dùng mô hình build-and-fix model. Cơ bản
là không có mô hình.
Không đặc tả
Không thiết kế
- Mô hình này hoàn toàn không thoả mãn và không nên được chấp nhận.
Hoạt động phát triển tăng trưởng
6. 4-Extreme Programming (XP)
- Là một điển hình qui trình Agile
- Appropriate for environments with:
Nhóm nhỏ
Yêu cầu thay đổi nhanh

Một số nguyên lý XP đặc nền tảng trên:
Small Releases – Phần mềm đã phát triển trong những giai đoạn đã
được cập nhật thường xuyên
Simple Design – Hiện thực code cần đạt kết quả khách hàng mong đợi
khôg nhấn mạnh đến version tương lai
Testing – Hoàn tất qua toàn bộ qui trình phát triển. Kiểm thử là thiết kế
đầu tiên trước khi viết phần mềm
7. Các tiếp cận để phát triển phần mềm
- Traditional systems development life cycle
- Prototyping
- Packaged software
- End-user development
- Outsourcing
- Open source
8. Các mô hình bảo trì phần mềm
- Mô hình Quick-Fix
- Mô hình Boehm
- Mô hình Osborne
- Iterative Enhancement Model
- Mô hình hướng sử dụng lại (Reuse-Oriented)
9. Quick - Fix
- Thuận lợi
Nhanh
Có thể hữu ích cho dự án nhỏ
- Không thuận lợi
Nhỏ hay không sưu liệu
Bất kỳ thiết kế trở nên ít hiệu quả vượt quá thời gian
10. Boehm’s
- Thuận lợi
Qui trình được kiểm soát
Nhấn mạnh vào phản hồi
- Không thuận lợi
Thấp hơn quick-fix
11. Osborne’s
- Thuận lợi
Liên quan đến tất cả giai đoạn chu trình sống
Sưu liệu được cập nhật
-

Không thuận lợi
Phức tạp
Lots of Overhead
12. Iterative
- Thuận lợi
Relatively simple
Allows for analysis
- Không thuận lợi
Những quyết định bao gồm không rõ ràng
Appears informally to be on a tilt!
13. Reuse
- Thuận lợi
Có thể dùng các thành phần từ các dự án khác
Code is modular
- Không thuận lợi
Overhead in designing for reuse
14. Khi thực hiện thay đổi
- Tăng trưởng qui trình
- Mô hình tăng trưởng CMM (Capability Maturity Model) cho phần mềm
- Cơ sở kinh nghiệm phần mềm
15. Quy trình cải tiến nâng cao chất lượng
- Quy trình khung là cơ sở để cải tiến tiến trình nâng cao chất lượng, năng suất
- Quy trình khung phổ biến (Các chuẩn)
ISO
CMM (Capability Maturity Model)
CMMI (Capability Maturity Model Integration): 5 level
Initial (chaotic, ad hoc, heroic) the starting point for use of a new
process.
Repeatable (project management, process discipline) the process is
used repeatedly.
Defined (institutionalized) the process is defined/confirmed as a
standard business process.
Managed (quantified) process management and measurement takes
place.
Optimising (process improvement) process management includes
deliberate process optimization/improvement.

-

16. Cơ sở tri thức kình nghiệm
- Tri thức được hình thành từ hướng dẫn (guidleline),mô hình hay thể hiện rõ ràng
kỹ năng nhân sự.
- Tổ chức tạo ra hệ thống để hỗ trợ và chia sẽ kinh nghiệm. 4 yếu tổ đòi hỏi thực thi
thành công cơ sở tri thức kinh nghiệm:
Thay đổi văn hoá
Tính ổn định
Giá tri nghiệp vụ (business value)
Thực thi tăng cường
17. Vấn đề tham dự trong quá trình bảo trì ?
- Hiểu hệ thống hiện hành
Hệ thống thực sự làm được gì?
Ở đâu cần thay đổi?
Các phần của phần mềm liên quan với nhau như thế nào?
- Thực thi sự thay đổi
- Kiểm thử
- Nhận diện nhu cầu thay đổi
- Thảo luận
Hiểu chương trình ?
Tác động thay đổi?
Kiểm thử ?
Vấn đề Quản lý?
KHẢ NĂNG DÙNG LẠI VÀ KIỂM THỬ
1. Mục đích của việc dùng lại
- To increase productivity:
- To increase quality:
- To facilitate code transportation:
- Reduction in maintenance time and effort:
- To improve maintainability:
2. Công nghệ cấu phần (Components engineering)
- Design for Reuse
Characteristics of Reusable Components
Problems with Reuse Libraries
- Reverse Engineering
- Components-Based Processes

3.
-
-
-
-
-
-
4.
-
-
-
-
5.
-
Characteristics of Reusable Components
Generality:
Cohesion versus coupling:
Interaction:
Uniformity and standardisation:
Data and control abstractions:
Interoperability:
Problems with Reuse Libraries
The granularity and size dilemma:
The search problem:
The classification problem:
The specification and flexibility problems:
Các yếu tố tác động lên việc sử dụng lại
Technical Factors
Programming Languages
Representation of Information
Reuse Library
Reuse-Maintenance Vicious Cycle
- Non-Technical Factors
Initial Capital Outlay
Not Invented Here Factor
Commercial Interest
Education
Project Co-ordination
Legal Issues
6. Question: Why do we test software? Answer: To see if it works?
7. Testing Code
- Black Box and White Box Testing
- Structured Testing
- Integration Testing
- Regression Testing
CÁC TÁC VỤ YÊU CẦU BẢO TRÌ
1. Hiểu chương trình
- Mục tiêu của nắm bắt chương trình
Phạm vi vấn đề
Hiệu quả thực thi
Mối liên hệ Nhân – Quả (Cause-Effect)

Mối liên hệ sản phẩm – Môi trường
Đặc trưng Quyết định – Hỗ trợ
2. Các bước thực hiện: Thuật toán chung(GA)
- GA1. Liệt kê tất cả các đối tượng với mức khác nhau
- GA2. Sắp xếp đối tượng quan trọng dựa trên tài liệu khác nhau và kiến thức
của người bảo trì . Câu Trả lời: đối tượng là gì (WHAT)
- GA3. Nếu đối tượng được chọn làm bùng nổ đối tượng khác thì được bỏ
vào danh sách. Câu trả lời: mối liên hệ Chuồng bồ câu của các đối tượng
được chọn
- GA4. Nếu có mối liên hệ từ và đến đối tượng khác, tạo mối liên hệ đến đối
tượng mới sau đó lặp lại từ GA1
3. Người bảo trì và các nhu cầu thông tin
- Managers
- Analysts
- Designers
- Programmers
VẤN ĐỀ QuẢN LÝ VÀ TỔ CHỨC
QUẢN LÝ CẤU HÌNH & KiỂM SOÁT THAY ĐỔI
1. Cải thiện năng suất bảo trì
- Chọn người phù hợp
- Động lực nhân sự bảo trì
- Một số cách để thúc đẩy nhâ sự thông qua, khen thưởng, giám sát phù hợp,
mẫu phân công việc và công nhận :
Khen thưởng:
Cấp trên giám sát:
Mẫu phân công việc :
Công nhận:
Cấu trúc nghề nghiệp :
- Truyền thông
Người tài nguyên tương xứng thích hợp
Kiến thức phạm vi
2. Nhóm bảo trì
- Nhóm tạm thời
- Nhóm cố định
Lãnh đạo nhóm bảo trì
The coleader
user-liaison

-
-
-
-
maintenance administrator
maintenance programmers
3. huấn luyện và đào tạo nhân sự
Mục tiêu
Nâng cao mức nhận thức
Hiểu nhu cầu cụ thể
Nhân sự ít kinh nghiệm (e.g. mới tuyển dụng) được gán công
việc bảo trì,
Cải thiện sự công nhận
Chiến lược đào tạo và huấn luyện
Đào tạo đại học :
Hội nghị và hội thảo :
Kinh nghiệm truyền nhau :
4. Chế độ tổ chức
Kết hợp phát triển và bảo trì
Module Ownership
Change Ownership
Work-Type
Application-Type
Bộ phận bảo trì riêng biệt
5. Quan lý cấu hình
-
Nếu không quản lý cấu hình tốt:
Một module được xây dựng và kiểm chứng tốt bất ngờ không hoạt
động
Một chức năng vừa được thêm vào phần mềm không tồn tại
Một lỗi đã được sửa xuất hiện trở lại
Quản lý cấu hình tốt sẽ giúp khắc phục các tình trạng:
Cập nhật đồng thời: Một nhóm nhiều người cùng làm việc trong
cùng một chương trình, những thay đổi của người cuối cùng có thể
xóa đi phần làm của người khác.
Chia sẻ mã nguồn: Trong các hệ thống lớn, khi những chức năng
chung được thay đổi, tất cả nhân viên đều cần biết Nếu không có
cách quản lý code hiệu quả, sẽ rất khó khăn trong việc tìm kiếm và
thông báo cho mọi người.
Phát hành các phiên bản: Các phần mềm lớn đều được phát hành
nhiều phiên bản. Khi một phiên bản được phát hành, phiên bản khác
-

-
-
-
-
-
đang được test, phiên bản khác đang được phát triển. Nếu có khách
hàng phát hiện lỗi, lỗi phải được sửa trong tất cả các phiên bản
6. Lưu ý
- Quản lý cấu hình liên quan đến cả công cụ và tiến trình
- Tất cả các dự án đều cần một mức độ quản lý nhất định
- Tất cả các thành viên đều có trách nhiệm trong quản lý cấu hình
7. Version Control
- Các version có thể được đánh dấu để thể hiện
Các mốc phát triển
Việc chấp nhận một thành phần
Hoàn thành baseline
- Version control tool : Rational® ClearCase®, Microsoft® Visual Source
Safe™, CVS, SubVersion, ...
8. Định danh các thành phần cấu hình
Mục đích của việc định danh các thành phần cần quản lý cấu hình là để có
thể xác định duy nhất chúng, xác định được mối quan hệ với thế giới bên
ngoài và với những thành phần khác.
Cần có một cơ chế định danh chung tất cả các thành phần cấu hình
9. Tổ chức lưu trữ
Mục đích của lưu trữ
là nhằm đảm bảo các thành phần cấu hình không bị thất lạc hoặc bị
hư hỏng.
Đảm bảo các thành phần cấu hình có thể được tìm thấy bất cứ khi
nào cần.
Đảm bảo phát hành nó đúng với những gì mong đợi
Giúp biết được ai tạo ra, ai cập nhật và ai copy, sử dụng
10. Quan lý thay đổi
Trong quá trình phát triển và bảo trì sản phẩm, việc thay đổi là không thể
tránh khỏi
Khách hàng thay đổi
Developer sửa lỗi
Môi trường thay đổi
Đảm bảo việc thay đổi các thành phần cấu hình
Được tiến hành có giám sát
Tất cả các nhóm hoặc cá nhân liên quan đến thành phần cấu hình
được thông báo về việc thay đổi

11. Báo cáo tình trạng
- Báo cáo tình trạng cung cấp thông tin cần thiết để quản lý hiệu quả quá
trình phát triển và bảo trì
- Tất cả mọi thành phần đưa vào quản lý cấu hình đều có thể cung cấp
thông tin để báo cáo tình trạng
12. Kiểm soát thay đổi
- Trách nhiệm của quản lý trong kiểm soát thay đổi
- Sưu liệu
- Phân loại tài liệu phần mềm
- Vai trò của sưu liệu phần mềm
- Tạo và bảo trì sưu liệu có chất lượng
13. Các hoạt động kiểm soát thay đổi
- Chọn từ danh sách ưu tiên hàng đầu.
- Tái tạo vấn đề (nếu có một).
- Phân tích mã nguồn (và đặc tả nếu có sẵn).
- Hợp nhất thay đổi.
- Thiết kê những thay đổi và kiểm thử.
- Đảm bảo chất lượng.
14. Trách nhiệm của quản lý trong kiểm soát thay đổi
- Ra quyết định nếu thay đổi nên được làm : Nó là công việc của Ban
kiểm soát thay đổi -Change Control Board (CCB) để quyết định có chấp
nhận hay không những yêu cầu thay đổi.
- Quản lý và thực hiện những thay đổi :
- Thẩm định chất lượng :
15. Phân loại sưu liệu
- Sưu liệu người dùng :Mô tả chức năng của hệ thống mà không tham
chiếu đến những chức năng được thực thi như thế nào
- Sưu liệu hệ thống: bao gồm tài liệu mà mô tả tất cả các mặt của hệ
thống bao gồm phân tích, đặc tả, thiết kế, thực thi, kiểm thử, bảo mật,
triệu chứng lỗi và khắc phục.
16. Sưu liệu người dùng
- System overview
- Installation guide
- Beginner's guide / tutorial
- Reference guide
- Enhancement booklet
- Quick reference card

- System administration
17. Sưu liệu hệ thống
- Các nhân tố cơ bản của hệ thống
- Phân tích đặc tả yêu cầu
- Đặc tả /Thiết kế :
(i) Những yêu cầu hệ thống được thực thi thế nào
(ii) Hệ thống phân rà thành những đơn vị chương trình tương tác
thế nào
(iii) Chức năng của mỗi đơn vị chương trình
- Thực thi :
(i) Thiết kế chi tiết được diễn giải thế nào trong ngôn ngữa lập
trình hình thức
(ii) program actions in the form of intraprogram comments
- System test plan: Cung cấp mô tả đơn vị chương trình được kiểm thử cá
nhân và toàn bộ hệ thống được kiểm thử sau khi tích hợp
- Acceptance test plan: Mô tả kiểm thử mà hệ thống phải thông qua trước
khi người dùng chấp nhận nó
- Tự điển dữ liệu
18. Cách phân loại khác
- Phương pháp luận phát triển :
- Phân loại khách hàng :
- Version of the system:
19. Vai trò của sưu liệu
- Tiện nghi nắm bắt chương trình :
- Thao tác hướng dẫn người dùng:
o Cung cấp khởi động và mô tả chính xác hệ thống là gì
o Cung cấp thông tin cho phép người dùng cài đặt hệ thống
o Cung cấp thông tin kỹ thuật và làm thế nào để quản lý sai sót.
- Bổ sung hệ thống :
20. Tính hiệu quả tài liệu qua những mô tả hệ thống nên được làm bởi:
- Văn phong viết :
- Gắn kết chuẩn tài liệu :
- Chuẩn và đánh giá chất lượng:
- Kỹ thuật sưu liệu :
- Công cụ hỗ trợ sưu liệu: Công cụ hỗ trợ giúp phân loại và cập nhật sưu
liệu.

[hailinh]

Bạn tổng hợp lại từ đâu mà dài lê thê vậy, khó theo dõi quá
Thanks

[maithoa]

Bạn có sách hay tài liệu về vấn đề này không ?
Mình đang cần để viết tài liệu.
cảm ơn bạn

[hungtmvt12]

Bạn nào có tài liệu cho mình tham khảo với nhé. thanks.