Xây dựng và chuyển đổi hệ thống

Xây dựng và
chuyển đổi hệ
thống

1


Xây dựng và chuyển đổi
HT
Mở đầu 
Quản lý lập trình
Thiết kế kiểm thử
Xây dựng tài liệu hệ thống
Chuyển đổi hệ thống
Bảo trì hệ thống
2


1. Mở đầu
• Xây dựng là sự triển khai tất cả các phần của hệ
thống, trong đó chủ yếu bao gồm:
- Bản thân phần mềm HTTT.
- Lập tài liệu hệ thống.
- Thủ tục qui trình xử lý công việc mới.
• Trọng tâm của giai đoạn này là lập trình, theo
sau là kiểm thử (test) kết quả lập trình.
• Một sai lầm thường thấy là nhiều lập trình viên
xem thường việc kiểm thử và lập tài liệu hệ thống.
3

• Các tổ chức chuyên nghiệp sẳn sàng mất thời
gian và tốn tiền cho việc kiểm thử và lập tài liệu
HT nhằm ngăn chận những sai lầm có thể xảy
ra sau khi HT được cài đặt.
• Lập trình được đề cập nhiều ở các môn học
lập trình. Do đó ở đây nhấn mạnh đến:
- Quản lý việc lập trình.
- Kiểm thử chương trình.
- Lập tài liệu hệ thống.
4


Xây dựng và chuyển đổi
HT
Mở đầu

Quản lý lập trình 
Thiết kế kiểm thử
Xây dựng tài liệu hệ thống
Chuyển đổi hệ thống
Bảo trì hệ thống
5


2. Quản lý lập trình
• Thông thường thì PTV không phải lập trình, các
lập trình viên (LTV) sẽ lập trình. PTV sẽ quản lý
việc lập trình của các LTV.
• Quản lý việc lập trình liên quan đến:
- Gán các môđun cho LTV.

- Phối hợp các hoạt động.
- Quản lý lịch trình.
6


• Gán các môđun cho LTV.
- PTV nhóm các môđun liên quan với nhau và
giao cho LTV.
- Trong nhiều công việc, nhiều người làm tốt
hơn ít người làm và công việc sẽ xong nhanh.
- Đối với phát triển hệ thống (lập trình),
nhiều LTV tham gia có thể làm chậm dự án.
- Tại sao? Nhiều LTV sẽ làm tăng các hoạt
động phối hợp và còn ít thời gian lập trình.
- Dự án phức tạp đòi hỏi nhóm lớn LTV nên
chia thành nhiều phần nhỏ độc lập.
7


• Phối hợp các hoạt động.
- Họp đều đặn, hiệu quả. Khuyến khích các
LTV trao đổi các vấn đề trước khi chúng có
thể trở thành những khó khăn, rủi ro.
- Trao đổi về những vấn đề phát sinh, những
thay đổi về yêu cầu, các chuẩn và qui ước
chung liên quan lập trình.
- Nhiều dự án tổ chức việc lập trình thành ba
khu vực gồm khu vực phát triển (lập trình),
khu vực kiểm thử và khu vực sản phẩm.
8

• Các khu vực hoạt động phối hợp như sau:
- Khu vực phát triển chịu trách nhiệm lập
trình. Các chương trình hoàn thành được
copy và chuyển đến khu vực kiểm thử.
- Khu vực kiểm thử chịu trách nhiệm test
chương trình. Nếu không đạt sẽ được
chuyển trở lại khu vực phát triển.
- Khi tất cả chương trình được test và sẳn
sàng hỗ trợ HT mới thì sẽ được copy chuyển
đến khu vực sản phẩm. Tại đây HT cuối
cùng được hình thành.
9


• Ba khu vực này có thể ở ba thư mục khác nhau
trên đĩa cứng server, ở ba server khác nhau,
hoặc ở ba chỗ làm việc khác nhau.
• Việc sao chép để giữ các files và chương trình
ứng với tình trạng hoàn thành sẽ giúp PTV kiểm
soát được sự thay đổi.
• Một kỹ thuật quản lý khác là PTV có thể dùng
program log. Đây là một form trên đó PTV ký
nhận CT để viết, và ký xác nhận CT hoàn thành.
• Khu vực lập trình và program log giúp PTV biết
được sự làm việc của LTV và tình trạng các CT.
10

• Quản lý lịch trình.
- Luôn đối chiếu với thời gian được hoạch
định trong dự án.
- Điều chỉnh thời gian thích hợp khi việc xây
dựng HT bắt đầu tiến hành.
- Coi chừng vấn đề “scope creep” do sự phát
sinh yêu cầu mới.
- Cần chống lại khuynh hướng giảm chất
lượng lập trình để đúng với lịch trình dự kiến.

11


• Một trong những vấn đề gây khó khăn nhất
cho việc quản lý lịch trình là yêu cầu HT thay
đổi hoặc bổ sung trong quá trình xây dựng HT.
• Tránh những lỗi “cổ điển” sau đây khi phát
triển hệ thống:
- Phát triển HT chạy theo nghiên cứu.
- Dùng lập trình viên “lương thấp”.
- Mất đi sự kiểm soát mã lập trình.
- Tổ chức kiểm thử không phù hợp.
12


Xây dựng và chuyển đổi
HT
Mở đầu
Quản lý lập trình

Thiết kế kiểm thử 
Xây dựng tài liệu hệ thống
Chuyển đổi hệ thống
Bảo trì hệ thống
13


3. Thiết kế kiểm thử
• Nguyên tắc kiểm thử.
- Sẽ nguy hiểm nếu như test các môđun quá
sớm trong khi chưa có kế hoạch kiểm thử.
- Việc kiểm thử không có kế hoạch sẽ làm cho
các test quan trọng có thể được xem xét không
chi tiết và rất khó để tạo lại chuỗi biến cố gây
nên lỗi sai.
- Việc kiểm thử phải được thực hiện một cách
có hệ thống và các kết quả kiểm thử phải được
lập tài liệu cẩn thận.

14


• Việc kiểm thử phải được bắt đầu bằng việc lên
kế hoạch kiểm thử cho các tester.
• Kế hoạch kiểm thử xác định dãy các test cần
được tiến hành.
• Mỗi một test trong kế hoạch kiểm thử phải có
mục tiêu cụ thể, tập các test cases phải được mô
tả rõ ràng và chính xác, phải dự đoán kết quả
test, và ghi rõ kết quả test thực sự thu được.

• Trong thực tế các test cases không thể vét cạn
các tổ hợp có thể có. Do vậy cần phải chọn các
test cases điển hình.
15


• Khi test không phải tất cả các môđun đều
xong cùng lúc để có thể kết hợp khi test. Do
vậy cần viết các stub đối với các môđun chưa
hoàn thành để có thể tiến hành test.
• Stub là nơi giữ chỗ cho môđun chưa hoàn
thành. Một stub đơn giản có thể chỉ là một
thông báo cho biết môđun làm công việc gì.
• Ví dụ test môđun thực đơn, có thể các môđun
công việc chưa viết xong. Khi test thực đơn thì
lúc chọn công việc chỉ cần xuất ra màn hình
thông báo công việc đó là gì.
16


Ví dụ kế
hoạch
kiểm thử.

17


• Phân loại các test.
- Test từng phần: Test các cấu trúc điều
khiển trước khi môđun hoàn thành.

- Test đơn vị: Test từng môđun để bảo đảm
nó thực hiện đúng chức năng.
- Test tổng hợp: Test sự tương tác giữa các
môđun để bảo đảm chúng phối hợp được.
- Test hệ thống: Test nhằm bảo đảm phần
mềm làm việc tốt (as part of overall system).
- Test chấp nhận: Test nhằm bảo đảm hệ
thống đáp ứng nhu cầu của tổ chức.
18


• Test từng phần (Stub Tests).
Có thể tạo các
stub giữ chỗ
cho các môđun
để có thể test
menu.

19


• Test đơn vị (Unit Tests).
- Kiểm tra xem đơn vị có thực hiện đúng
chức năng đã xác định trong đặc tả CT
không. Đơn vị có thể là môđun hoặc CT.
- Có hai cách tiếp cận để test gọi là hộp đen
(black-box) và hộp trắng (white-box).
- Test kiểu hộp đen tức là xem chương trình
như là hộp đen, vào input và test các output.
- Test kiểu hộp trắng tức là xem chi tiết các

đoạn mã lập trình. Có thể không cần xem
hết, chỉ xem các đoạn mã quan trọng.
20


• Test tổng hợp (Integration Tests).
- Đánh giá xem các môđun hoặc chương
trình cần làm việc với nhau có thể kết hợp với
nhau mà không có sai sót.
- Bao gồm:
User interface testing.
User scenario testing.
Data flow testing.
System interface testing.
21


• Test hệ thống (System Tests).
- Đánh giá xem toàn bộ các môđun và các
chương trình làm việc kết hợp cùng với nhau
mà không có sai sót.
- Test hệ thống tương tự như test tổng hợp
nhưng ở phạm vi rộng hơn, bao quát hơn.
- Test tổng hợp nhấn mạnh đến các môđun
hoặc chương trình kết hợp với nhau được
không. Còn test hệ thống tập trung đánh giá
HT đáp ứng các nhu cầu công việc của tổ
chức đến mức nào.
22

• Các loại test hệ thống.
- Requirements testing: Test xem các yêu
cầu đặt ra ban đầu có đáp ứng được không.
- Usability testing: Test xem HT có sử dụng
thuận tiện đối với NSD không.
- Security testing: Test khả năng phục hồi hư
hỏng và ngăn chận các truy cập trái phép.
- Performance testing: Khảo sát khả năng thi
hành của HT trong tình trạng tải cao.
- Documentation testing: Test sự chính xác
của các tài liệu (sưu liệu) HT.
23


• Test chấp nhận (Acceptance Test).
- Các test trên thực hiện bởi các testor, LTV,
PTV và NSD (ít). Test chấp nhận thực hiện
chủ yếu bởi tổ chức và nhóm dự án.
- Test nhằm xác nhận HT đã được hoàn
thành, đáp ứng các yêu cầu của tổ chức, và
được nhấp nhận bởi tổ chức.
- Alpha testing: NSD test HT dùng các madeup data, có thể lặp lại các test trước.
- Beta testing: NSD test HT dùng các real
data, có sự giám sát cẩn thận.
24


Mức độ khám phá lỗi sai qua các giai đoạn test.

25