1
GIAI ĐOẠN THIẾT KẾ
ThS. Nguyễn Khắc Quốc
IT Department – Tra Vinh University
2
4.1 Mục tiêu
- Giai đoạn thiết kế nhằm:
+ Xác định chính xác hệ thống sẽ làm việc "như
thế nào".
+ Xác định các bộ phận, các chức năng và các
mối liên kết giữa chúng của hệ thống.
3
4.2 Các công việc
Được tiến hành theo 3 mức:
Mức tổng thể:
+ Được thực hiện ở cuối giai đoạn phân tích.
+ Nó cho thấy kiến trúc chung của hệ thống về cả
phần cứng và phần mềm.
+ Sử dụng các mô hình khái niệm để minh hoạ.
Mức giữa:
+ Tiếp tục việc chia nhỏ bản thiết kế ở mức tổng thể
thành các thành phần nhỏ hơn.
+ Các thành phần của phần cứng được chi tiết đến
mức các khối.
+ Các thành phần phần mềm được chi tiết đến mức
các chương trình trong mỗi Môđun hoặc mỗi ứng dụng.
+ Sử dụng đến các mô hình lôgic để minh hoạ.
4
4.2 Các công việc (tt)
Thiết kế Môđun:
+ Được tiến hành trong giai đoạn thực hiện)
+ Là mức hi tiết nhất, nhằm thiết kế ra các thành phần
cơ bản tạo ra phần cứng, các chương trình con tạo thành các
chương trình phần mềm ứng dụng.
+ Mức này thường do các chuyên gia phát triển làm
trong giai đoạn thực hiện.
+ Các sơ đồ ở đây chi tiết đến từng dữ liệu và thao
tác một.
5
4.2 Các công việc (tt)
Các công việc của giai đoạn thiết kế bao gồm:
- Thiết kế hệ thống mức giữa và phối hợp với kết quả thiết kế
hệ thống mức tổng thể để viết tài liệu Đặc tả thiết kế (Design
Specification - DS)
- Soạn thảo tài liệu "Kế hoạch kiểm thử để chấp nhận"
(Acceptance Test Plan - ATP).
+ Là tài liệu liệt kê tất cả các phép thử sẽ phải thực
hiện để kiểm tra tất cả các chức năng của hệ thống cho
người dùng thấy trong giai đoạn chấp nhận.
- Mốc chính của giai đoạn này là tài liệu Đặc tả thiết kế được
xem xét thông qua và được chứng tỏ là không sai sót.
- Trong giai đoạn này người sử dụng có thể ký duyệt "Kế
hoạch kiểm thử để chấp nhận”.
6
4.3 Một số chú ý
- Vai trò và công sức của các nhà quản lý giảm.
- Công việc chủ yếu liên quan đến các nhà thiết kế, các
chuyên gia phát triển, các lập trình viên và những người xét
duyệt.
- Vai trò của nhà quản lý chủ yếu chỉ là giám sát và theo dõi.
- Tuy nhiên để có thể làm nhà quản lý tốt, ta cũng nên biết
được nội dung cơ bản của các công việc đang được tiến
hành trong giai đoạn này. Ở đây chúng ta không đi sâu vào
các phương pháp và công cụ thiết kế.
- Trong giai đoạn thiết kế nên cố gắng phân chia dự án thành
các dự án con.
- Mỗi dự án con có thể đòi hỏi một người quản lý dự án và
một đội thực hiện dự án riêng.
7
4.4 Đặc tả thiết kế
- Là tài liệu mang tính chất kỹ thuật.
- Viết để cho các lập trình viên đọc và hiểu để thực hiện.
- Người sử dụng cũng có thể đọc song không nhất thiết phải
hiểu tất cả.
- Khi viết tài liệu này cần chú ý:
+ Sử dụng ngôn ngữ chặt chẽ, chính xác.
+ Nguyên nhân lớn thứ hai gây ra sai sót trong hệ
thống phần mềm là do lập trình viên hiểu sai thiết kế (Nguyên
nhân lớn gây ra sai sót là do nhà phân tích hiểu sai nhu cầu
của người dùng).
+ Sử dụng các sơ đồ, các hình vẽ, các mô hình thiết
kế chuẩn.
+ Nhất quán về ngôn ngữ trình bày, cả về lời văn lẫn
các hình vẽ - một người viết toàn bộ.
8
4.4 Đặc tả thiết kế (tt)
Nội dung:
1. Tổng quan về hệ thống thông tin
+ Các mục tiêu
+ Các sơ đồ thiết kế cấu trúc
2. Các chuẩn và các quy ước
-Trong thiết kế cần thiết lập các chuẩn cho mỗi thành phần.
* Phần cứng
+ Các thành phần: Các sơ đồ cấu trúc, máy chủ, máy
trạm, mạng.
+ Các nhà cung cấp
* Phần mềm
+ Các loại thành phần
+ Các nhà cung cấp
+ Các phương pháp thiết kế có cấu trúc
+ Các phương pháp lập trình có cấu trúc
+ Các phương pháp kết nối
9
4.4 Đặc tả thiết kế (tt)
3. Các thành phần chức năng
- Liệt kê tất cả các thành phần chức năng, các môđun;
- Quyết định làm, mua hay sửa đổi cho thích ứng
- Chia thành các thành phần con
- Liệt kê các thành phần
4. Các cơ sở dữ liệu, các file và các bảng
- Liệt kê tất cả và đối với mỗi loại hãy chỉ rõ:
+ Mục đích
+ Sử dụng
+ Loại
- Thiết lập dữ liệu ở mức vật lý
+ Tạo lập
+ Duy trì, cập nhật
+ Tổ chức
+ Kiểu dạng
+ Các giới hạn
+ Vị trí
10
4.5 Một số vấn đề trong quá trình thiết kế
4.5.1 Đội thiết kế
- Nhà quản lý dự án phải chọn những người tốt nhất vào đội
thiết kế:
+ Là những người có đầu óc tổng hợp,
+ Có thể hình dung tổng thể sự việc.
- Tránh quan điểm cầu toàn, hoàn thiện trong đội thiết kế.
- Có thể tìm ra cách tốt hơn để thực hiện dự án nếu có đủ
thời gian và nguồn lực, nhưng cần phải nhớ là chúng ta bị
hạn chế về thời gian và kinh phí.
- Có nhiều sự so sánh lựa chọn phải làm trong thời gian thiết
kế, do đó đội nên có một số lẻ người, hoặc ít ra phải có đội
trưởng giỏi, để dễ dàng bỏ phiếu quyết định một vấn đề gì đó
cần sự thống nhất.
11
4.5 Một số vấn đề trong quá trình thiết kế (tt)
4.5.2. Rà soát lại bản thiết kế
- Cần tiến hành các cuộc họp để rà soát lại bản thiết kế trên
khía cạnh kỹ thuật.
- Cuộc họp gồm các đại biểu của đội dự án và có thể có thêm
các đại biểu từ các nhóm khác.
- Khi rà soát lại cần đảm bảo rằng thiết kế:
+ Đáp ứng tất cả các đặc tả chức năng đã đề ra.
+ Được chia thành các thành phần một cách lôgic.
+ Mọi vấn đề kỹ thuật được trình bày rõ ràng, dễ hiểu
và nằm trong giới hạn về thời gian và giá cả.
12
4.6 Vấn đề chấp nhận dự án
- Chấp nhận dự án nghĩa là người sử dụng khẳng định bằng
văn bản rằng sản phẩm đã được cung cấp đúng như thoả
thuận, nếu dự án được thực hiện dưới dạng hợp đồng thì
cần tiến hành thanh toán hợp đồng.
- Mặc dù chưa đến giai đoạn chấp nhận, song giai đoạn thiết
kế là thời điểm tốt nhất để bắt đầu lập kế hoạch cho giai đoạn
này.
- Tại giai đoạn chấp nhận, lần đầu tiên người dùng thực sự
mới được trông thấy và sử dụng sản phẩm.
- Họ cần kiểm tra để xem có chấp nhận được sản phẩm đó
hay không.
13
4.6 Vấn đề chấp nhận dự án (tt)
4.6.1 Phương pháp cổ điển
- Giai đoạn chạy thử hoặc cho chạy song song
- Giai đoạn chạy thử là giai đoạn đội dự án cài đặt hệ thống
và cho người sử dụng chạy thử nghiệm.
- Cho chạy song song là hệ thống mới được cài đặt song vẫn
duy trì hệ thống cũ và cả hai hệ thống được hoạt động song
song để có thể so sánh các kết quả.
- Khách hàng sử dụng hệ thống mới trong một khoảng thời
gian quy định.
- Trong khoảng thời gian này nếu hệ thống hoạt động không
nảy sinh vấn đề gì thì hệ thống được chấp nhận.
- Nếu có vấn đề nảy sinh thì đội dự án phải sửa chữa, khắc
phục và hệ thống lại được chạy thử nghiệm lặp lại một
khoảng thời gian nữa.
14
4.6 Vấn đề chấp nhận dự án (tt)
Ưu điểm:
+ Đơn giản, Dễ lập kế hoạch,
Nhược điểm.
+ Phải chạy thử nghiệm lặp đi lặp lại nhiều lần
n
ếu liên tục
có nhiều vấn đề nhỏ nảy sinh đối với hệ thống. Đôi khi một hệ thống
phần mềm phức tạp có thể không bao giờ sửa chữa hết lỗi được và
ta phải biết cách chung sống với lỗi.
+ Khó tìm được nguyên nhân của những trục trặc nảy sinh.
+ Khi có nhiều người cùng hoạt động trên một hệ thống
phức tạp gồm nhiều thành phần tương tác với nhau thì khi có trục
trặc, có thể rất khó biết nguyên nhân tại sao.
+ Không có gì đảm bảo là các đặc tính cơ bản của hệ thống
đã được kiểm tra đầy đủ trong thời gian chạy thử
+ Có thể để lại ấn tượng không tốt cho người dùng khi hệ
thống sinh lỗi.
15
4.6 Vấn đề chấp nhận dự án (tt)
4.6.2 Phương pháp trình diễn hoặc kiểm tra lần lượt tất
cả các chức năng
+ Phương pháp tốt hơn là đưa ra một chuỗi các phép thử để
trình diễn và kiểm tra tất cả các chức năng đã thỏa thuận.
+ Quá trình chấp nhận sẽ tiến hành tất cả các phép thử này
đối với khách hàng.
+ Các phép thử nghiệm thành công sẽ được ký nhận lần
lượt.
+ Nếu phép thử nào thất bại, đội dự án cần khắc phục vấn đề
nảy sinh, nếu vấn đề đơn giản thì sửa chữa ngay, nếu vấn đề
nghiêm trọng thì quá trình thử nghiệm được hoãn lại cho đến
lúc khắc phục xong.
+ Về nguyên tắc chỉ cần thử lại các phép thử không thành
công, song người sử dụng có quyền chạy lại các phép thử đã
được chấp nhận trước khi nảy sinh vấn đề.
16
4.6 Vấn đề chấp nhận dự án (tt)
Các phương pháp:
- Liệt kê tất cả các chức năng mà hệ thống cần phải thực
hiện.
- Xác định các phép thử nghiệm đối với từng chức năng.
- Danh sách các phép thử chính là tài liệu "Kế hoạch kiểm
thử chấp nhận".
- Thực hiện lần lượt các phép thử nghiệm đối với người sử
dụng
- Chỉ chạy lại các phép thử nghiệm không thành công, các
phép thử nghiệm thành công được người sử dụng ký nhận.
17
4.6 Vấn đề chấp nhận dự án (tt)
Những lợi ích:
- Có thể trình diễn tất cả các chức năng đã thoả thuận.
- Dễ dàng nhận biết nguyên nhân gây ra các trục trặc.
- Có thể lặp lại.
- Người sử dụng thoải mái khi ký nhiều chữ ký cho từng
phần hơn là ký một chữ ký cho toàn bộ.
Những nhược điểm:
- Phải mất nhiều công sức để viết tài liệu "Kế hoạch
kiểm tra để chấp nhận” và thực hiện kế hoạch đó.
Người sử dụng không quen với phương pháp này.
18
4.7 Xem xét lại các ước lượng
- Tại thời điểm cuối của giai đoạn thiết kế, chúng ta tiếp tục xem xét
lại kế hoạch dự án, đặc biệt là xem xét lại các đánh giá.
- Mặc dù bây giờ chúng ta chỉ đánh giá bốn giai đoạn còn lại, song
phần lập trình trong giai đoạn thực hiện có thể là tốn kém thời gian
và công sức nhất trong toàn bộ dự án.
- Thiết kế cho chúng ta biết số các môđun và ước lượng độ phức
tạp của chúng.
- Đồng thời bây giờ ta cũng đã biết ai sẽ là lập trình viên và có thể
đưa năng suất của họ vào các đánh giá.
- Như vậy, có thể dễ dàng đánh giá chính xác hơn lượng thời gian
cần thiết để lập trình.
- Thống kê đã cho thầy là vào cuối giai đoạn thiết kế, ước lượng
thuộc loại lớp A (sai số ± 10%).
19
4.8 Kết luận
Các mốc chính của giai đoạn thiết kế là:
1. Tài liệu đặc tả thiết kế được hoàn thành và thông qua
2. Soạn thảo tài liệu Kế hoạch kiểm tra để chấp nhận
3. Đánh giá lại các ước lượng
20
Câu hỏi thảo luận
1. Mục tiêu của giai đoạn thiết kế là gì?
2. Các mục của giai đoạn thiết kế là gì?
3. Các ưu điểm và nhược điểm của các phương pháp
kiểm tra để chấp nhận dự án.