thiết kế và kiến trúc của Microsoft.NET

Mục lục
Mục lục...................................................................................................................................................... 1
Lời giới thiệu............................................................................................................................................. 2
Danh mục hình ảnh.................................................................................................................................. 3
Danh mục bảng......................................................................................................................................... 4
Danh mục từ tiếng Anh........................................................................................................................... 4
Giới thiệu về định nghĩa thiết kế và kiến trúc của Microsoft.NET.....................................................5
Hệ thống quản lí nhân sự trong trường học........................................................................................ 37
Tài liệu tham khảo.................................................................................................................................. 72

1


Lời giới thiệu
Giao diện là một phần của ứng dụng, nó cung cấp các cơ chế giao tiếp giữa
người dùng và các tầng dịch vụ của hệ thống. Trong một số trường hợp nó được
xem như phần quan trọng nhất của một chương trình ứng dụng, bởi vì với hầu hết
người dùng nó chính là chương trình. Một thiết kế giao diện tốt sẽ tạo một đảm
bảo cho sự thành công của dự án.
Các thành phần giao diện sẽ hiển thị dữ liệu và nhận dữ liệu từ người dùng, xử
lí các sự kiện tương ứng với các hành động của người dùng, và giúp họ theo dõi
tiến trình trong các thao tác.
Tài liệu này gồm hai phần, Phần I Định nghĩa thiết kế và kiến trúc của
Microsoft.NET, Phần II Tạo Prototype cho chương trình quản lí nhân sự.
Phẩn I: Định nghĩa thiết kế và kiến trúc của Microsoft.NET, là một quy trình
do Microsoft đề nghị cho các dự án phần mềm, quy trình được chia ra năm giai
đoạn chính. Trong đó, thiết kế Prototype nằm chủ yếu trong giai đoạn “Thiết kế”,
do đó tài liệu này tập trung vào các bước trong giao đoạn thiết kế.
Phần II: Tạo Prototype cho chương trình quản lí nhân sự, các tài liệu trong quá
trình tạo Prototype cho dự án. Quy trình tạo Prototype ít các giao đoạn hơn xây
dựng một hệ thống hoàn chính. Ví dụ sẽ giảm nhẹ các giao đoạn thiết kế Cơ sở dữ

liệu, Bảo mật, Tỷ xích.

2


Danh mục hình ảnh.
Hình 1: Mô hình thác nước và xoắn ốc.
Hình 2: Mô hình MSF
Hình 3: Các giai đoạn trong mô hình MSF
Hình 4: Các vai trò trong mô hình MSF
Hình 5: Thiết kế khái niệm
Hình 6: Mô phỏng 3 tiến trình trong giai đoạn lập kế hoạch
Hình 7: Các giai đoạn trong mô hình MSF
Hình 8: Các nhiệm vụ trong quá trình thiết kế logic.
Hình 9: Trách nhiệm của từng vai trò trong quá trình thiết kế logic.
Hình 10: Quan hệ giữa thiết kế vật lí và thiết kế khái niệm, logic
Hình 11: Các bước trong quá trình thiết kế vật lí và liên kết giữa chúng.
Hình 12: Một phần giản đồ cơ sở dữ liệu của hệ thống bán hàng.
Hình 13: Tỉ xích trên của một ứng dung.
Hình 14: Tỉ xích ngoài của một ứng dụng.
Hình 15: Kim tự tháp tỉ xích.
Hình 16: Giao diện chương trình Outlook
Hình 17: Mô tả giao diện hệ thống
Hình 18: Giao diện một chức năng của hệ thống
Hình 19: Giao diện Browse Control
Hình 20: Giao diện Detail Control
Hình 21: Kiểu GroupBox 2.
Hình 22: Kiểu GroupBox 1.
Hình 23: Hộp thoại kích thước cố định.
Hình 24: Hộp thoại kích thước thay đổi.

Hình 25: Sơ lược kiến trúc hệ thống.
Hình 26: Màn hình chính

3

Trang
6
7
8
11
14
15
18
19
21
24
25
28
35
36
36
41
42
48
50
52
54
55
56
57

66
68


Danh mục bảng
Bảng 1: Vai trò trong mô hình MSF
Bảng 2: Các tiến trình thiết kế
Bảng 3: Trách nhiệm của từng vai trò trong quá trình thiết kế logic.
Bảng 4: Phạm vi của thiết kế vật lí.
Bảng 5: Vai trò và trách nhiệm trong quá trình thiết kế.
Bảng 6: Thanh công cụ trái form Browse Control.
Bảng 7: Thanh công cụ trái form Browse Control.
Bảng 8: Thanh công cụ trái form Detail Control.
Bảng 9: Thanh công cụ phải form Detail Control.
Bảng 10: Các kiểu GroupBox.
Bảng 11: Danh sách nút trên hộp thoại
Bảng 12 Danh sách các Icon
Bảng 13: Các điều khiển mẫu
Bảng 14: Kích thước các điều khiển

Trang
9
15
21
22
23
50
51
53
53

54
57
58
60
61

Danh mục từ tiếng Anh
Từ tiếng Anh

Giải thích

GroupBox
Detail Control
Browse Control

Khung nhóm các điểu khiển có quan hệ logic với nhau
Khung chứa các thông tin chi tiết của một thực thể
Khung chứa các thông tin ngắn gọn, trợ giúp tìm kiếm các thực
thể
Khung chứa Detail Control và Browse Control

Container Control

4


Giới thiệu về định nghĩa thiết kế và kiến trúc của
Microsoft.NET
1.1 Các mô hình tiến trình.
Để đạt được các kết quả tốt nhất cho các dự án, Microsoft tạo ra các hướng dẫn

cho thiết kế, phát triển, triển khai, xử lí, và hỗ trợ. Một mô hình hướng dẫn sắp xếp
các hoạt động và vòng đời của một dự án. Có hai mô hình phát triển phần mềm
chính là thác nước và xoắn ốc.

1.1.1 Mô hình thác nước và xoắn ốc.

Hình 1: Mô hình thác nước và xoắn ốc.
Các mô hình cung cấp hai hướng tiếp cận khác nhau về vòng đời của một dự
án.

• Mô hình thác nước: mô hình này sử dụng các điểm mốc như các điểm quá
độ và đánh giá. Khi sử dụng mô hình thác nước, chúng ta cần hoàn thiện
một tập các công việc trong một giai đoạn trước khi chuyển sang giai đoạn
khác. Mô hình thác nước làm việc phù hợp với các dự án có các yêu cầu
được xác định rõ ràng và không bị thay đổi trong tương lai. Bởi vì mô hình
tạo ra các điểm quá độ cứng giữa các giao đoạn, nhưng chúng ta có thể dễ
dàng kiểm soát lịch trình và xác định rõ ràng trách nhiệm và kế hoạch.
• Mô hình xoắn ốc: mô hình dựa trên việc tinh chỉnh các yêu cầu và các đánh
giá của một dự án. Mô hình xoắn ốc phù hợp với các dự án khi người dùng
cần phát triển nhanh một ứng dụng. Hướng phát triển này dựa trên khả
năng điều phối giữa đội phát triển và khách hàng, bởi vì khách hàng được
tham gia vào tất cả các tình huống thông qua các thông tin phản hồi và các
xác nhận. Tuy nhiên mô hình xoắn ốc không có các điểm kiểm soát rõ ràng.

5


1.1.2 Mô hình Microsoft Solution Framework.
Mô hình MSF mô tả tuần tự các hành động để phát triển và triển khai một giải
pháp. MSF chia thành các giai đoạn, các điểm kiểm soát, mô hình lặp để có thể áp

dụng phát triển và triển khai các ứng dụng truyền thống, các hệ thống thương mại
điện tử, và các ứng dụng Web.

Hình 2: Mô hình MSF

1.1.2.1 Các giai đoạn trong mô hình MSF.
Mô hình MSF bao gồm 5 giai đoạn chính:
• Khảo sát.
• Lập lịch
• Phát triển
• Ổn định
• Triển khai
Từng giai đoạn được đánh dấu bằng các điểm mốc. Hình sau mô tả các giai
đoạn và các điểm mốc trong mô hình MSF.

6


Hình 3: Các giai đoạn trong mô hình MSF

Tổ chức đội dự án.
MSF cung cấp mô hình đội dự án MSF. Mô hình đội MSF làm nổi bật sự quan
trọng và vai trò của các vị trí, trách nhiệm, và mục tiêu của từng thành viên để
giúp dự án thành công. Sự mềm dẻo của mô hình MSF giúp chúng ta thích ứng với
phạm vi của dự án, nhân lực của đội, và kĩ năng của từng thành viên.

Các vai trò trong mô hình MSF.
Trong một dự án, một số lượng lớn các hoạt động cần thực hiện, dự án cần
được xem xét theo nhiều khía cạnh khác nhau. Để giúp đạt được điều đó, mô hình
MSF đặc tả 6 vai trò, mỗi vai trò có các định nghĩa rõ ràng về trách nhiệm và mục

đích.
• Product Management: có trách nhiệm quản trị các liên lạc và các mong
muốn của khác hàng. Trong suốt giao đoạn thiết kế, họ thu thập các yêu cầu
và đảm bảo các nghiệp vụ cần thiết được đáp ứng, như tóm lược thông tin
cho khác hàng , marketing với người dùng v.v…
• Program Management: chịu trách nhiệm trong giai đoạn phát triển và đưa
ra các giải pháp về dự án cho khách hàng, dựa trên các điều kiện của dự án.

7


• Development: chịu trách nhiệm phát triển giải pháp kĩ thuật tùy theo các
mô tả được cung cấp bởi Program Management.
• Testing: xác định các tiêu chuẩn đánh giá chất lượng của dự án, họ đánh giá
và kiểm tra các chức năng và phù hợp với phạm vi của dự án.
• Release Management: chịu trách nhiệm làm mịn các xử lí và triển khai,
kiểm tra cơ sở hạ tầng đảm bảo nó có thể được hỗ trợ và triển khai.
• User Experience: phân tích các hiệu năng và hỗ trợ người dùng, cân nhắc
chương trình có đáp ứng được các yêu cầu.
Đối với các, mỗi người trong dự án có thể nắm một hay nhiều vai trò. Việc
quản lí nhiều công việc sẽ tăng tích rủi ro của dự án. Do đó, cần cân nhắc các vị trí
cho các thành viên thích hợp trong dự án. Để làm tối thiểu rủi ro, MSF đưa ra
hướng dẫn về những vai trò có thể giao cho một người và những vai trò không thể.
Bảng 1: Vai trò trong mô hình MSF

Vai trò
Product
management
Program
management

Development
Test
User
experience
Release
management

Product
management

Program
management

Development Testing

K
K

K

P

P

U

K

U

U

P

K

K
P

K
P

K
P

K
U

K

P

U

K

P

U

P

K

P

P: có thể U: hiếm khi K: không

8

User
Release
experience management

U
U


1.2 Pha khảo sát.
Các vấn đề chính:
• Các mục đích của khảo sát
• Vai trò và trách nhiệm của các thành viên trong quá trình khảo sát
• Thành lập đội dự án
• Các kết quả của pha khảo sát

1.2.1 Mục đích của khảo sát.
Giai đoạn đầu tiên trong mô hình MSF là quá trình khảo sát. Trong suốt quá
trình này, chúng ta tạo ra cái nhìn tổng thể về các vấn đề nghiệp vụ và các thức
quan hệ giữa nghiệp vụ, khác hàng và môi trường. Nó sẽ tạo cho đội dự án có một
cách nhìn rõ ràng về các vần đề cần thực hiện cho khác hàng. Một dự án thành

công, chúng ta cần hiểu được khách hàng muốn gì từ hệ thống.
Giai đoạn khỏa sát có rất nhiều mục đích, đội dự án sử dụng giai đoạn này để:
• Xác định các mục đích và các ràng buộc trong dự án.
• Trả lới các câu hỏi về tính khả thi, nhận được sự đồng ý của các nhà tài trợ
chính, và đạt được sự nhất chí chung của tất cả các người có liên quan.
• Thành lập đội dự án.
• Định nghĩa phạm vi của dự án, giúp phân chia chi tiết trong các giai đoạn
tiếp theo.
• Xác định các tài nguyên cần thiết để phát triển dự án.
• Xác định và lên kế hoạch cho các điểm mốc quan trọng của dự án.

1.2.1.1 Vai trò và trách nhiệm của các thành viên trong dự án.
Mặc dù đội dự án làm việc như một khối thống nhất để đưa ra được phạm vi và
cái nhìn chung tại từng điểm mốc của quá trình khảo sát, nhưng mỗi vai trò sẽ có
các trọng điểm riêng.

9


Hình 4: Các vai trò trong mô hình MSF
Product Management: nhiệm vụ của quản trị dự án đảm bảo đội làm đúng các
yêu cầu của khách hàng. Quản trị dự án và quản trị phát triền cộng tác với nhau
tạo ra một tầm nhìn chung về dự án. Để thực hiện điều này, người quản trị dự án
cần nghiên cứu và phân tích các vấn đề nghiệp vụ, các yêu cầu nghiệp vụ, tầm
nhìn của dự án, các mục tiêu kinh doanh, và các đặc tính của người dùng.
Program Management: thành lập các mục tiêu thiết kế, định nghĩa các nhân tố
và thước đo thành công, làm rõ các khái niệm trong dự án, xây dựng cơ sở hạ tầng
cho dự án,
Development: cung cấp các thông tin phản hồi dưới dạng các thông tin kĩ thuật
của dự án và tính khả thi của các vần đề khi phát triển.

User experience: nhóm phân tích thể hiện cần thiết, hỗ trợ khách hàng, và cân
nhắc để sản phần đáp ứng các yêu cầu của khách hàng.
Testing: cung cấp các thông tin dựa trên mục tiêu chất lượng của dự án và mô
tả các hành động cần thiết để đạt được chất lượng đó. Đội kiểm tra áp dụng các
giải pháp để đề ra các chiến lược testing và các tiêu chuẩn đánh giá.
Release Management: xác định các yêu cầu để triển khai dự án, cách thức để
dự án được triển khai, khi nào thì được triển khai, và khi triển khai có cần bổ xung
thêm cơ sở hạ tầng gi không.

1.2.1.2 Cách thức thành lập đội dự án.
Một nhiệm vụ quan trọng trong suốt quá trình khảo sát là thành lập đội dự án.
Các thành viên của dự án là các nhận tố và có thể thực hiện các nhiệm vụ để đưa
ra sản phẩm. Nhiệm vụ tạo lập là tập hợp các kĩ năng cần thiết để hoàn thành dự

10


án thành công. Để lựa chọn các thành viên thích hợp cho một dự án chúng ta cần
xem xét các vần đề sau cho mỗi thành viên:
• Tri thức: mô tả thông tin mà mỗi thành viên cần có để thực hiện công việc,
ví dụ như các kiến thức cơ bản vê công nghệ thông tin.
• Kĩ năng: mô tả các hoạt động hay các khả năng tương ứng và phù hợp với
các kĩ năng của các thành viên, ví dụ như yêu cầu về kĩ năng toán học, hay
khả năng thẩm mỹ.
• Hiệu suất: mô tả khả năng và kêt quả mong đợi, ví dụ bạn chọ một người có
khả năng hoàn thành công việc đúng thời gian và đáp ứng được yêu cầu về
chất lượng.
Ngoài các vần đề nêu trên, còn có một số cân nhắc để lựa chọn các thành viên
cho dự án. Bao gồm:
• Các thành viên có sẵn trong dự án.

• Chi phí hoặc quỹ của dự án.

1.2.1.3 Cách chuẩn bị các kết quả của giai đoạn khảo sát.
Mặc dù có các điểm mốc trung gian trong quá trình khảo sát, như thành lập đội
hình cốt lõi của dự án, tạo các tài liệu thô về phạm vi và tầm nhìn, các tài liệu thô
về đánh giá rủi ro, nhưng cần có 3 tài liệu quan trọng cần đưa ra trong giai đoạn
khảo sát, đó là:
• Phạm vi/tầm nhìn: mô tả các mục đích và rằng buộc trong dự án. Nó phác
thảo dự án sẽ phát triển, các yêu cầu cần thực hiện, các đặc tính, và một kế
hoạch ban đầu.
• Cấu trúc dự án: phác thảo cấu trúc tổ chức dự án và mô tả tiến trình quản lý
dự án. Ai sẽ là người chịu trách nhiệm cho mỗi vai trò trong mô hình MSF.
• Đánh giá rủi ro: cung cấp đánh giá cơ bản và phân tích các rủi ro liên quan
đến dự án, cùng với các kế hoạch làm giảm nhẹ hoặc đối phó với các tình
huống bất ngờ giúp đội dự án quản lí rủi ro.
Tùy thuộc vào mức độ của dự án, một số tài liệu có thể được tạo ra trong giai
đoạn khỏa sát:
• Danh sách các thuộc tính có thể test.
• Các yêu cầu sơ bộ và các use case.
• Kiến trúc sơ bộ.
• Giao diện người dùng.
Để các tài liệu được chia sẻ với người dùng, đội phát triển đồng thời tạo ra các
tài liệu sử dụng nội bộ như:
• Danh mục các tác nhân.
• Danh mục các nguyên tắc nghiệp vụ.
• Từ điển nghiệp vụ.

11

1.3 Phạm vi dự án
Mục đích:
• Báo cáo các vấn đề.
• Mô tả đặc tính người dùng.
• Định nghĩa phạm vi của dự án.
• Khái niệm cho dự án (cách đội dự định để làm phù hợp với các yêu cầu của
dự án, nó bao gồm hệ thống phần mềm và kiến trúc phần cứng).
• Xác định các mục tiêu của dự án.

1.3.1 Tài liệu phạm vi của dự án.
Phạm vi của dự án là một trong những tài liệu cuối cùng được thông qua trong
giai đoạn khảo sát, nó chứa đựng các mục đích và các rằng buộc, là sự nhất trí đầu
tiên của mọi người tham gia dự án. Nó trợ giúp cho đội dự án đạt được thỏa thuận
mức cao về các mục tiêu chính. Đồng thời nó cũng là nhân tố chính quyết định
tính khả thi của dự án. Khi dự án được thông qua, đội dự án sử dụng tài liệu này
để xây dựng kế hoạch cho toàn bộ giai đoạn còn lại.
Để tạo ra được tài liệu phạm vi đội cần có nhiều lần phỏng vấn với các khách
hàng, các nhà tài trợ, phân tích các use case từ mức cao đên chi tiết.

12


1.4 Thiết kế khái niệm
Trong suốt quá trình lập kế hoạch, đội sẽ định nghĩa giải pháp gồm: xây dựng
cái gì, các thức xây dựng nó, ai là người xây dựng. Trong toàn bộ giai đoạn này
đội chuẩn bị đặc tả các chức năng, thực hiện tiến trình thiết kế, chuẩn bị lập kế
hoạch công việc, đánh giá chi phí và lập lịch cho các kết quả bàn giao.
Trong suốt giai đoạn khảo sát, các thông tin được thu thập đầy đủ để xác định
phạm vi của dự án. Quá trình lập lịch có thể bắt đầu ngay trong quá trình khảo sát,
ngay khi chúng ta thu thập đầy đủ thông tin để tổ chức và phân tích các thông tin

đó. Trong giai đoạn này đội nhận các kết quả công việc đã làm được trong giai
đoạn khảo sát và tiếp tục chi tiết hơn, tổ chức và phân tích các thông tin đó.

Hình 5: Thiết kế khái niệm

1.4.1 Mục đích của quá trình thiết kế.
Trong suốt quá trình này, đội tiếp nhận các tài liệu trong khi khảo sát như: các
yêu cầu người dùng, các tác vụ và các tác vụ tuần tự, đặc tính người dùng. Kết quả
của giai đoạn phân tích là kiến trúc và thiết kế của dự án, kế hoạch để đi tới phát
triển và triển khai dự án, vấn đề về các nhiệm vụ và tài nguyên. Mục đích nhằm
đưa ra một bức tranh rõ ràng về dự án. Tiến trình lập kế hoạch hướng dự án tiến về
phía trước, nhưng rất nhiều dự án bị mắc kẹt trong quá trình này, họ dành quá
nhiều thời gian cho lập lịch. Điều quan trọng là biết được khi nào chúng ta đã có

13


đủ thông tin để tiếp tục dự án. Quá ít thông tin sẽ tạo nên các rủi ro, quá nhiều
thông tin sẽ làm dự án bị đình trệ.

1.4.1.1 Ba tiến trình thiết kế: Khái niệm, Logic, Vật lí.
Có ba tiến trình thiết kế trong giai đoạn phân tích: khái niệm, logic, vật lí. Ba
tiến trình này không tiến hành song song mà gối đầu lên nhau, tiến trình này phụ
thuộc vào tiến trình khác. Thiết kế logic phụ thuộc vào thiết kế khái niệm, thiết kế
vật lí phụ thuộc vào thiết kế logic. Tất cả các thay đổi ở thiết kế khái niệm đều ảnh
hưởng đến thiết kế logic, dẫn tới ảnh hưởng đến thiết kế vật lí.

Hình 6: Mô phỏng 3 tiến trình trong giai đoạn lập kế hoạch
Bảng 2: Các tiến trình thiết kế
Loại thiết kế

Khái niệm
Logic
Vật lí

Mô tả
Mục đích
Xem xét vấn đề dưới cách nhìn của Định nghĩa các vấn đề và
người dùng và của nghiệp vụ
các giải pháp dưới dạng
các kịch bản sử dụng.
Xem xét giải pháp dưới góc nhìn Định nghĩa giải pháp dựa
của đội dự án
trên một tập các dịch vụ
xử lí logic
Xem xét giải pháp dưới góc nhìn Định nghĩa các kĩ thuật và
của người lập trình
các dịch vụ của giải pháp

Quá trình thiết kế khái niệm có thể được chia nhỏ thành: nghiên cứu thiết kế
khái niệm, phân tích thiết kế khái niệm, tối ưu thiết kế khái niệm.

1.4.1.2 Vai trò và trách nhiệm.
Từng vai trò trong đội dự án sẽ chịu các trách nhiệm khác nhau, cụ thể:
Product Management: đảm bảo kế hoạch phù hợp với các yêu cầu của khác
hàng. Họ chịu trách nhiệm sàng lọc các yêu cầu, phân tích trạng thái nghiệp vụ
hiện tại, tối ưu khái niệm, và tạo ra thiết kế khái niệm.

14

Program Management: đảm bảo các tài nguyên cần thiết để hoàn thành kế
hoạch của dự án. Chịu trách nhiệm trong toàn bộ quá trình thiết kế, trong đó quan
trọng nhất là thiết kế logic và đặc tả các chức năng. Quản trị sản phẩm tạo ra kế
hoạch và lịch của dự án, có trách nhiệm hoàn thành giai đoạn lập kế hoạch.
Development: đảm bảo tính khả thi của công nghệ sử dụng. Đội phát triển có
trách nhiệm tạo các thiết kế logic và thiết kế vật lí, có thể cả đặc tả các chức năng.
Đồng thời họ cũng chịu trách nhiệm xác định thời gian và tài nguyên cần thiết để
phát triển dự án.
Testing: đảm bảo kế hoạch đáp ứng được các yêu cầu, chịu trách nhiệm đánh
giá thiết kế để xác định các đặc tính có thể kiểm tra đồng thời lên kế hoạch kiểm
tra chúng.
Release Management: đánh giá thiết kế có phù hợp với phát triển, quản lí và hỗ
trợ. Đồng thời có trách nhiệm lên kế hoạch và lập lịch triển khai.
User Experience: đảm bảo người dùng có thể sử dụng sản phầm. Công việc
bao gồm: phân tích yêu cầu sử dụng, tạo chiến lược hỗ trợ, đánh giá mức độ hoàn
thiện của thiết kế dựa trên tính khả dụng, đánh giá thời gian và nỗ lực để phát triển
hệ thống hỗ trợ người dùng, kiểm tra khả năng sử dụng của tất cả các giao diện
người dùng.

1.4.1.3 Các điểm mốc và các kết quả.
Các điểm mốc là các thời điểm mà đội dự án, khách hàng, các nhà tài trợ đạt
được sự nhất trị dựa trên các kết quả bàn giao. Các tài liệu bàn giao chính trong
quá trình lập lịch là:
• Đặc tả chức năng: mô tả sản phẩm sẽ được phát triển, dựa trên thông tin
đầu vào từ toàn đội dự án.
• Kế hoạch chính của dự án: là một tập hợp các kế hoạch tương ứng với các
nhiệm vụ được thực hiện bởi từng vai trò để đạt được các tính năng được
mô tả trong đặc tả chức năng. Nó lưu giữ các chiến lược, thông qua đó các
nhóm dự định sẽ tiến hành để hoàn thành công việc của mình.
• Thời gian biểu chính của dự án: đồng bộ lịch làm việc của các nhóm trong

dự án. Nó bao gồm các khoảng thời gian, trong thời gian đó mỗi đội phải
hoàn thành công việc của mình. Tập hợp các thời gian đơn lẻ sẽ đưa ra cái
nhìn tổng thể về thời gian của dự án, qua đó có thể xác định ngày kết thúc.
• Cập nhật tài liệu đánh giá rủi ro: đánh giá rủi ro được phát triển trong suốt
quá trình khảo sát, và tiếp tục được xem xét và cập nhật thường xuyên, đặc
biệt tại các điểm mốc. Nó mô tả các rủi ro có thể xảy ra khi phát triển dự
án. Thông thường các đánh giá rủi ro sẽ được sắp xếp để xác định các rủi ro
cao nhất.
Các tài liệu này được lưu trữ và tiếp tục được phát triển trong quá trình phát
triển của dự án. Mặc dù các tài liệu này có thể thay đổi, nhưng bất kì sự thay đổi
nào trước hết phải được thông qua bởi sự đồng ý của khách hàng và các nhà tài
trợ.

15


1.5 Quá trình thiết kế logic
Trong quá trình thiết kế khái niệm, chúng ta đã mô tả dự án từ viễn cảnh của
người dùng và của tác vụ, trong quá trình này ta sẽ dựa trên viễn cảnh của đội dự
án.

1.5.1 Thiết kế logic là gì?
Thiết kế logic được định nghĩa như một tiến trình mô tả giải pháp dưới dạng tổ
chức, cấu trúc của nó, tương tác giữa các phần, bao gồm:
• Định nghĩa cấu tạo các phần của giải pháp.
• Cung cấp một khung làm việc để tập trung toàn bộ các phần của giải pháp.
• Giải thích cách giải pháp kết hợp với nhau, cách tương tác với người dùng
và các giải pháp khác.
Khi tạo một thiết kế logic, đội đưa vào tất cả các yêu cầu nghiệp vụ, người
dùng, hệ thống, các xử lí để xác định các yêu cầu cho vấn đề bảo mật, kiểm soát,

đang nhập, tính ổn định, quản lí trạng thái, kiểm soát lỗi, cấu trúc chương trình và
tương tác với các hệ thống khác.

1.5.2 Vị trí của thiết kế logíc.
Khi đội dự án bắt đầu xác định các đối tượng quan trọng và các thuộc tính của
một thực thể, chúng ta có thể bắt đầu giai đoạn thiết kế logic. Do đó, giai đoạn này
có thể bắt đầu trước khi giai đoạn thiết kế khái niệm kết thúc. Việc quyết định bắt
đầu quá trình thiết kế được đưa ra tùy từng trường hợp, nó phụ thuộc vào dự án và
toàn đội. Hình sau mô tả vị trí của quá trình thiết kế trong mô hình MSF.

16


Hình 7: Các giai đoạn trong mô hình MSF
Trong quá trình thiết kế khái niệm, đội dự án định nghĩa các vấn đề nghiệp vụ
dựa trên các thông tin thu thập được từ giao tiếp nghiệp vụ và người dùng. Trong
suốt quá trình thiết kế logic, họ định nghĩa các thành phần của giải pháp dựa trên
cách nhìn của chính họ. Các thành viên xác định các yêu cầu của giải pháp cần
thực hiện. Dựa trên các thông tin đó, họ định nghĩa các hành động và cấu trúc của
giải pháp.
Thiết kế logic giúp đội một lần nữa tinh chỉnh lại các yêu cầu đã được tạo ra
trong giai đoạn khảo sát và trong quá trình thiết kế khái niệm.
Một thiết kế logic tốt phụ thuộc vào một thiết kế khái niệm tốt. Nếu đội tạo
được một thiết kế logic tốt, nó sẽ tạo điều kiện dễ dàng cho những người mới dựa
trên thiết kế xác định các phần quan trọng của dự án, hiểu các phần được cách các
phẩn kết hợp với nhau đề giải quyết các vần đề. Thông thường, các công việc
trong quá trình thiết kế logic sẽ được lặp lại trong quá trình thiết kế vật lí. Đội sẽ
tối ưu cấu trúc trong quá trình thiết kế logic, và được cải thiện các xử lí của nó
trong quá trình thiết kế vật lí, điều đó tạo ra một vòng lặp giữa hai quá trình thiết
kế logic và thiết kế vật lí.

1.5.3 Các nhiệm vụ khi thiết kế logic.
Ở mức chi tiết hơn, thiết kế logic có thể được chia nhỏ thành các nhiệm vụ sau:
• Phân tích thiết kế logic, đội sẽ thực hiện các nhiệm vụ sau:

17


o Sàng lọc các kĩ thuật và các công cụ sẽ sử dụng
o Xác định các đối tượng nghiệp vụ và các dịch vụ
o Xác định các thuộc tính và các quan hệ quan trọng
• Tối ưu thiết kế logic:
o Tinh chỉnh thiết kế logic
o Kiểm tra thiết kế logic

Hình 8: Các nhiệm vụ trong quá trình thiết kế logic.
Trong suốt quá trình thiết kế logic, đội có thể tìm ra một vài yêu cầu mới hoặc
các tính năng mới, chưa được tìm ra trước đó. Với trường hợp này, đội dự án cần
gặp gỡ lại khách hành để kiểm tra lại các yêu cầu hoặc các tính năng phát sinh có
hợp lí hay không, và cách họ muốn xử lí đối với vần đề mới. Tùy thuộc vào câu trả
lời của khách hàng, phạm vi của dự án có thể thay đổi. Nếu phạm vi của dự án
thay đổi, cần sửa lại các tài liệu và các mô hình để tương ứng với các yêu cầu và
tính năng mới.

1.5.3.1 Các mục đích chính của quá trình thiết kế.
Mục đích chính của quá trình thiết kế là xác định hệ thống cần phải làm gì và
giải thích điều đó bằng cách sử dụng một tập các thành phần. Thiết kế logic cho
phép chúng ta:
• Mô tả các yêu cầu nghiệp vụ cần được hỗ trợ bởi các kĩ thuật. Mặc dù thiết
kế logic không phải là một giải pháp kĩ thuật, tuy vậy nó giúp đội dự án mô

tả các yêu cầu mà giải pháp cần hỗ trợ.
• Xác định các cơ hội và các rằng buộc kĩ thuật. Mặc dù thiết kế logic là độc
lập với triển khai vật lí, tuy vậy nó có thể bắt đầu xác định các cơ hội và
18


rằng buộc, những vấn đề có thể ảnh hưởng đến sự lựa chọn và triển khai
của một kĩ thuật.
• Xác định kĩ thuật thích hợp sẽ được sử dụng. Đội cần tìm hiều về giải pháp
trước khi lựa chọn công nghệ để thực hiện giải pháp.
• Xác định phạm vi của thiết kế logic để quyết định cơ sở hạ tầng, hoạt động,
và triển khai. Thiết kế logic không bị ảnh hưởng trực tiếp bởi các kĩ thuật
yêu cầu, tuy vậy nó ảnh hưởng đến thiết kế vật lí, và thiết kế vật lí lại phụ
thuộc vào kĩ thuật. Do đó, nếu khách hành yêu cầu một giải pháp Webbase, đội cần phải chuân bị các rằng buộc triển khai trong suốt quá trình
thiết kế logic.

1.5.3.2 Các lợi ích của thiết kế logic.
Tạo thiết kế logic cho một giải pháp đem lai rất nhiều lợi ích, như tạo một mối
liên kết giữa các thành viên có kiến thức về công nghệ và các thành viên khác. Sau
đây là một vài lợi ích khác của quá trình thiết kế.
• Thiết kế logic giúp quản lí độ phức tạp của dự án thông qua cấu trúc của
giải pháp, mô tả các phần của giải pháp, mô tả cách các phần tương tác với
nhau để giải quyết vấn đề. Rất nhiều dự án đã thất bại do chúng quá phức
tạp và không được thiết kế tốt trước khi thực hiện. Sự phức tạp dẫn đến lộn
xộn, kết quả là một thiết kế nghèo nàn.
• Thiết kế logic phản chiều và hỗ trợ các yêu cầu của thiết kế khái niệm.
Giúp đội tìm ra các lỗi và các mâu thuẫn trong quá trình thiết kế khái niệm,
xác đinh các kịch bản có khả năng sử dụng lại. Các phát hiện này có thể áp
dụng ngược trở lại thiết kế khái niệm và đánh giá lại các yêu cầu để chắc
chắn giải pháp có thể giải quyết vấn đề.

• Thiết kế logic như một điểm để liên kết các chức năng đồng xử lí giữa các
hệ thống và cung cấp một khung nhình chặt chẻ về toàn bộ dự án.Chúng ta
có thể phân tích thiết kế logic để xác định các phần sử dụng lại và làm cho
thiết kế hiệu quả hơn và có khả năng bảo trì tốt hơn.
• Khi thiết kế logic kết thúc, cũng là lúc bắt đầu quá trình thiết kế vật lí.

1.5.3.3 Vai trò và trách nhiệm trong thiết kế logic.
Trong quá trình thiết kế logic, mỗi nhóm sẽ chịu các trách nhiệm khác nhau.Ví
dụ, Program Management chịu trách nhiệm phát triển đặc tả chức năng, đảm bảo
điều kiện giao tiếp và đàm phán trong đội, lên kế hoạch bảo trì và báo cáo tình
trạng của dự án.

19


Hình 9: Tóm lược trách nhiệm của từng vai trò trong quá trình thiết kế logic.
Vai trò

Nhiệm vụ chính

Nhiệm vụ phụ

Product
Đảm bảo thiết kế phù hợp với
Management nghiệp vụ và yêu cầu của khách
hàng
Program
Chịu trách nhiệm chính trong các
Management kết quả bàn giao

Quản lí các mong đợi của
khách hàng

Định nghĩa các kế hoạch của
dự án bao gồm: tài nguyên,
lịch trình, đánh giá rủi ro
Development Xác định các đối tượng dịch vụ và Cố vấn kĩ thuật để đánh giá và
liên kết
làm mẫu
Testing

Kiểm tra thiết kế logic có phù hợp Đinh nghĩa kế hoạch kiểm tra
với thiết kế khái niệm
mức cao

User
Experience

Định nghĩa các mục đích của Định nghĩa kế hoạch mức cao
người dùng
cho huấn luyện người dùng

Release
Đánh giá tính khả thi khi thực Định nghĩa cơ sở hạ tầng và
Management hiện giải pháp
triển khai giải pháp

20

1.6 Thiết kế vật lí.
Quá trình thiết kế vật lí là quá trình cuối cùng của giai đoạn lập lịch trong mô
hình phát triển phần mềm của Microsoft. Đội bắt đầu quá trình thiết kế vật lí sau
khi tất cả các thành viên đồng ý thống nhất chúng ta đã có đầy đủ thông tin từ thiết
kế logic. Trong suốt quá trình này, toàn đội sẽ áp dụng các rằng buộc và cân nhắc
các kĩ thuật từ thiết kế khái niệm và logic. Bởi vì thiết kế vật lí phát triển từ thiết
kế khái niệm và logic, kết quả phụ thuộc vào sự đúng đắn của hai quá trình thiết
kế trước đó. Sự kế thừa thông tin của thiết kế vật lí từ thiết kế khái niệm và thiết
kế logic đảm bảo đội hoàn thành thiết kế vật lí phù hợp với yêu cầu của khách
hàng và nghiệp vụ.

1.6.1 Thiết kế vật lí là gì?
Thiết kế vật lí là tiến trình mô tả các thành phần, các dịch vụ và các kĩ thuật
của giải pháp dưới góc nhìn của yêu cầu từ đội phát triển. Thiết kế vật lí định
nghĩa các phần của giải pháp sẽ được pháp triển, cách chúng được phát triển, và
cách chúng tương tác với nhau.
Trong các công việc của thiết kế vật lí, đội sẽ tạo các thiết kế dựa trên các thiết
kế trước đó và tinh chỉnh kiến trúc của hệ thông đã được tạo từ trước tới thời điểm
hiện tại. Các thiết kế này áp dụng các rằng buộc kĩ thuật (thực tế) cho các mô hình
logic, bao gồm các công cụ phát triển và môi trường phát triển của giải pháp. Hơn
nữa, đội phát triển cần đáp ứng được các thiết kế như tính bảo mật, tính ổn định,
tính hữu dụng v.v... với mục tiêu làm phù hợp với dự án và các yêu cầu của nó.
Thông tin đầu vào cho quá trình thiết kế vật lí là toàn bộ các tài liệu đã được
tạo ra từ trước đến nay. Nó bao gồm mô hình đối tượng mức logic, thiết kế giao
diện người dùng mức cao và mô hình dữ liệu logic được tạo ra trong quá trình
thiết kế logic. Và các tài liệu như kế hoạch của dự án có thể được cập nhật và tạo
các điểm mốc cho quá trình thiết kế logic.
Ở thời điểm cuối của quá trình thiết kế, đội sẽ đưa ra các đặc tả là một tập các
thành phần, các assembly, các thư viện liên kết; chi tiết về giao diện của người
dùng; giản đồ cơ sở dữ liệu; các đối tượng cơ sở dữ liệu như trigger, index, store

procedure; và chi tiết về các báo cáo trong giải pháp.

1.6.1.1 Phạm vi của thiết kế vật lí.
Bảng 4: Phạm vi của thiết kế vật lí.
Không thuộc thiết kế vật lí
Code

Triển khai kĩ thuật

Hỗ trợ
• Tạo chi tiết các đặc tả thành phần cho phát
triển
• Xác định nơi các thành phần được sử dụng
Xác định kĩ thuật có thể sử dụng để triển khai
chương trình
21


Thiết kế vật lí chỉ thiết kế chương trình và không phát triển một version nào để
phục vụ cho quá trình bàn giao hay triển khai.

1.6.1.2 Sự khác nhau giữa thiết kế logic và thiết kế vật lí.
Trong quá trình thiết kế logic đội nhìn vần đề dưới góc độ đội dự án, trong quá
trình thiết kế vật lí đội nhìn nhận vấn đề dưới goc độ đội phát triển. Trong quá
trình thiết kế logic, đội ghi nhận các tài liệu về hoạt động, rằng buộc và các giả
định về nghiệp vụ. Trong quá trình thiết kế vật lí, đội định nghĩa một giải pháp
tương ứng với các rằng buộc của các kĩ thuật phát triển và môi trường triển khai
được lựa chọn.

1.6.1.3 Các mục tiêu của quá trình thiết kế vật lí.

Đội dự án tạo các tài liệu thiết kế vật lí nhằm các mục đích sau:
• Xác định kĩ thuật phù hợp cho phát triển. Trong quá trình thiết kế vật lí, đội
đánh giá các kĩ thuật và xác định kĩ thuật tốt nhất để sử dụng phát triển cho
dự án.
• Chuyển đổi từ thiết kế logic sang mô hình thiết kế vật lí. Đội sử dụng các
thông tin là đầu ra của quá trình thiết kế logic để tạo ra đặc tả mềm dẻo dựa
trên các thành phần. Đặc tả này trình bày ứng dụng từ góc nhìn của đội phát
triển. Chúng mô tả chương trình đủ chi tiết để cho phép đội phát triển bắt
đầu tạo chương trình dựa theo các yêu cầu.
• Cung cấp các ranh giới cho tiến trình phát triển. Để tạo ra các mô hình và
các chiến lược, đội định nghĩa các vai trò phát triển, các trách nhiệm và các
tiến trình.

1.6.1.3.1 Vai trò và trách nhiệm trong thiết kế vật lí.
Bảng 5: Vai trò và trách nhiệm trong quá trình thiết kế.
Vai trò

Nhiệm vụ chính

Nhiệm vụ phụ

Product
Management

Quản lí các yêu cầu người
dùng và tạo các kế hoạch liên
lạc
Quản lí tiến trình thiết kế vật
lí và tạo các đặc tả chức năng.

Chuẩn bị triển khai chương
trình

Program
Management
Development

Định nghĩa kế hoạch của dự án,
bao gồm tài nguyên, lịch biểu,
đánh giá rủi ro.
Tạo các tài liệu thiết kế vật lí; Đánh giá kĩ thuật, tạo mẫu nếu
mô hình thiết kế; kế hoạch và cần, chuẩn bị môi trường phát
lịch phát triển; ước lượng thời triển.
gian

22


Testing

User
Experience
Release
Management

Đánh giá và kiểm tra tính Định nghĩa các kế hoạch kiểm
năng và tương thích của thiết tra chi tiết và chuẩn bị môi
kế vật lí và kịch bản sử dụng
trường kiểm tra và đảm bảo
chât lượng

Đánh giá thiết kế vật lí với các Lập kế hoạch đào tạo người
yêu cầu của người dùng và dùng
thiết kế hướng dẫn
Đánh giá cơ sở hạ tầng liên Định nghĩa cơ sở hạ tầng và
quan đến thiết kế vật lí
các yêu cầu xử lí và các giải
pháp triển khai

1.6.1.3.2 Các tài liệu bàn giao của quá trình thiết kế vật lí.
Tại thời điểm cuối của giao đoạn thiết kế vật lí, đội dự án đã hoàn thiện các tài
liệu cho đội phát triển bắt đầu tạo chương trình. Các tài liệu này là đặc thù cho
từng dự án, chúng bao gồm:
• Biểu đồ lớp.
• Mô hình thành phần, biểu đồ tuần tự, hoặc biểu đồ hoạt động.
• Giản đồ cơ sở dữ liệu.
• Ranh giới mô hình triển khai.
• Đặc tả component: cấu trúc bên trong và các giao diện component.
• Chiến lược đóng gói và phân chia: xác định các dịch vụ để tập trung với
nhau thành một component, và cách các component được phân chia trên
mạng

1.6.1.3.3 Các bước trong quá trình thiết kế vật lí.

Hình 10: Quan hệ giữa thiết kế vật lí và thiết kế khái niệm, logic.

23


•
•

•

•

Hình 11: Các bước trong quá trình thiết kế vật lí và liên kết giữa chúng.
Nghiên cứu, bao gồm các nhiệm vụ sau:
o Xác định cac rằng buộc và yêu cầu vật lí.
o Xác định các thay đổi hoặc liên quan đến cơ sở hạ tầng
Phân tích:
o Phát triển một mô hình triển khai sơ bộ.
o Lựa chọn công nghệ để phát triển chương trình
Hợp lí hoá:
o Xác định các gói và chiến lược triển khai
o Đóng gói các component và các dịch vụ
o Phân chia các component trên mạng
Thực hiện:
o Xác định mô hình lập trình
o Mô tả các thuộc tính, giao diện, và các dịch vụ của component

1.6.1.3.3.1 Xác định các yêu cầu và các rằng buộc vật lí.
Trong suốt quá trình thiết kế, chúng ta thu thập và phân tích thông tin về các
yêu cầu và các rằng buộc nghiệp vụ. Trong quá trình thiết kế vật lí, đội tập trung
vào các yêu cầu và rằng buộc vật lí ảnh hưởng đến phát triển của dự án. Các thông
tin này được thu nhận từ kiến trúc của tổ chức và môi trường kinh doanh hiện tại.
Một vài kiểu yêu cầu vật lí:
• Sự thể hiện
• Chi phi và lợi nhuận
• Dễ dàng sử dụng
• Khả năng triển khai
• Khả năng hỗ trợ

24


• Độ tin cậy
• Tính tái sử dụng.
Một vài kiểu rằng buộc vật lí:
• Ngân sách
• Lịch làm việc
• Mạng
• Dữ liệu
• Component
• Hướng dãn kĩ thuật
• Bảo mật
1.6.1.3.3.2 Giải quyết xung đột giữa yêu cầu và rằng buộc.
Các yêu cầu và các rằng buộc thường xung đột với nhau. Bằng cách xác định
trước các xung đột tiềm năng trong quá trình thiết kế có thể làm giảm bớt các ảnh
hưởng. Nếu vấn đề xảy ra, chúng ta đã có những biện pháp để giảm nhẹ.
Để tránh các xung đột, ta nên tiến hành các công việc sau:
• Xác định các yêu cầu thực sự cần thiết cho dự án. Xác đinh xung đột giữa
các yêu cầu và đồng thời phân tích tương tác với bất kì rằng buộc nào.
• Xác định các khu vực trong cơ sở hạ tầng nơi các yêu cầu có thể xung đột
với các rằng buộc
• Phân tích các kẽ hở giữa yều cầu và rằng buộc, xác định liệu chúng ta cần
tiến hành lựa chọn để giải quyết xung đột.

25