Chương V: Quy trình làm phần mềm docx

CHƯƠNG V – QUI TRÌNH LÀM PHẦN MỀM.
1. MỞ ĐẦU
Quy trình làm phần mềm (hay gọi đơn giản theo tiếng Anh: software
process - quy trình phần mềm) là quá trình tạo ra phần mềm. Quy trình này là sự
kết hợp mô hình vòng đời phần mềm, các công cụ được sử dụng và quan trọng
hơn hết, là những người xây dựng nên phần mềm đó. Các công ty phần mềm
khác nhau có các quy trình phần mềm khác nhau. Ví dụ hãy xem vấn đề tài liệu.
Có một số công ty cho rằng chính bản thân phần mềm với các mã nguồn là tài
liệu về phần mềm. Họ cho rằng phần mềm có thể hiểu được bằng cách đọc các
mã nguồn này. Một số công ty khác chuẩn bị tài liệu rất chi tiết. Ngay cả khi
phần mềm đã cài đặt cho khách hàng và chuyển sang giai đoạn bảo trì, thì mọi sự
sửa đổi phần mềm cũng được ghi chép lại, các bản thiết kế cũng được thay đổi
cho phù hợp. Từ thực tế có thể thấy rằng một phần mềm được kiểm thử kỹ lưỡng
và có các tài liệu báo cáo đầy đủ trong từng pha thì chất lượng sẽ tốt hơn và
công việc bảo trì cũng thuận lợi hơn.
Nói chung, một quy trình phần mềm thường trải qua 7 pha: xác định yêu
cầu, phân tích, thiết kế, cài đặt, tích hợp, bảo trì và thôi sử dụng. Trong một số
trường hợp thì tên các pha này có thể khác. Ví dụ người ta hợp nhất hai pha xác
định yêu cầu và phân tích thành pha phân tích hệ thống. Một vài pha khác lại
được chia nhỏ hơn, ví dụ pha thiết kế được chia thành pha thiết kế kiến trúc và
thiết kế chi tiết. Hai pha cài đặt và tích hợp được kết hợp thành pha cài đặt và
tích hợp. Những lý do sau đây trả lời câu hỏi vì sao các pha của vòng đời phần
mềm cần được kiểm thử kỹ và báo cáo thành tài liệu chi tiết bởi nhóm thực hiện
trước khi tiến hành các pha tiếp theo:
- Vì sự thúc ép về thời gian hoàn thành nên những phần tài liệu bị trì hoãn
thường ít khi được tiếp tục hoàn thiện.
- Trách nhiệm về một pha nào đó có thể được chuyển giao cho nhóm khác
thậm chí ở một công ty phần mềm khác.
- Phần mềm thường liên tục thay đổi trong quá trình xây dựng. Ví dụ thiết
kế có thể bị thay đổi trong pha cài đặt. Rõ ràng nếu tài liệu thiết kế được biên
soạn đầy đủ thì sự sửa đổi sẽ thuận lợi hơn.

99
II. CÁC ĐỐI TƯỢNG
1. Khách hàng
Khách hàng là cá nhân hoặc công ty có nhu cầu sử dụng phần mềm.
2. Người phát triển
Những người phát triển là những người nhận trách nhiệm xây dựng
phần mềm do khách hàng yêu cầu.
3. Người sử dụng
Người sử dụng là người trực tiếp sử dụng phần mềm khi nó được cài
đặt cho khách hàng.
Khách hàng, người phát triển và người sử dụng có thể ở các công ty khác
nhau hoặc ở ngay trong một công ty. Cũng có khi họ là những người lao động tự
do. Thường thì khách hàng và người sử dụng ở cùng một công ty, còn những
người phát triển là thành viên của một công ty phần mềm nào đó. Nếu xét về mặt
giá cả thì người ta phân các phần mềm thành hai loại: Phần mềm được xây dựng
cho một khách hàng thường có giá cao, và phần mềm đóng gói được bán cho
nhiều khách hàng ví dụ như Microsoft Word, Microsoft Excel thường có giá rẻ
hơn.
Trong những lần gặp đầu tiên giữa khách hàng và người phát triển, khách
hàng phác thảo các yêu cầu, chức năng, các công việc cần thực hiện của phần
mềm mà họ muốn đặt hàng. Theo cách nhìn nhận của người phát triển thì những
điều khách hàng mô tả có thể mơ hồ, có những điều không hợp lý, thậm chí mâu
thuẫn hay không khả thi. Nhiệm vụ của người phát triển là phải tìm hiểu xem
thực chất khách hàng cần gì. Ngoài những yêu cầu về chức năng và công việc,
họ còn phải tìm hiểu xem các điều kiện về phần mềm là gì? Ví dụ như phần mềm
phải hoàn thành trong thời gian bao lâu, phần mềm cần làm việc với hệ điều
hành nào, trên máy tính có cấu hình ra sao, giá cả khoảng bao nhiêu thì chấp
nhận được. Thường thì chính khách hàng hỏi lại người phát triển giá của phần
mềm, và người phát triển phải cân nhắc khi trả lời câu hỏi này.
III – PHA XÁC ĐỊNH YÊU CẦU

1. Nắm bắt yêu cầu
Quá trình khám phá các yêu cầu của khách hàng được gọi là sự nắm bắt
yêu cầu (requirements capture), hoặc sự gợi mở yêu cầu (requirements
100
elicitation) hay tìm hiểu vấn đề (concept exploration). Sau khi các yêu cầu được
xác định thì chúng được xem xét để hiệu chỉnh, lược bỏ bớt hoặc mở rộng. Quá
trình này được gọi là phân tích yêu cầu (requrements analysis). Pha yêu cầu
thường được bắt đầu bằng việc gặp gỡ trao đổi giữa một vài thành viên của
nhóm yêu cầu và một vài thành viên đại diện cho công ty khách hàng để cùng
nhau xác định xem sản phẩm phần mềm cần những gì. Cuộc trao đổi thường
được thực hiện theo cách là thành viên của nhóm yêu cầu đưa ra các câu hỏi có
tính gợi mở về lĩnh vực mà phần mềm được sử dụng. Các thành viên của công ty
khách hàng hoặc trả lời các câu hỏi của nhóm yêu cầu, hoặc chủ động nêu ra các
vấn đề mà họ cần. Rõ ràng, những thành viên tham gia khám phá yêu cầu của
khách hàng phải có hiểu viết về lĩnh vực mà phần mềm ứng dụng giải quyết, để
có thể hiểu được những điều khách hàng nói, và có thể đưa ra các câu hỏi có ý
nghĩa. Vì vậy, nhiệm vụ đầu tiên của nhóm yêu cầu chính là tìm hiểu và làm
quen với lĩnh vực ứng dụng của phần mềm mà khách hàng muốn có. Ví dụ, nếu
phần mềm là quản lý các chuyến bay của một hãng hàng không thì lĩnh vực cần
tìm hiểu là cách thức quản lý các chuyến bay của một hãng hàng không. Nếu
phần mềm là chương trình quản lý thư viện thì nhóm yêu cầu cần có hiểu biết
nhất định về lĩnh vực thư viện Để sử dụng từ một cách chính xác, các thành
viên nhóm yêu cầu cần tìm hiểu các thuật ngữ. Ví dụ, nếu họ đang chuẩn bị làm
phần mềm trong lĩnh vực sinh học thì cần tìm hiểu các thuật ngữ về sinh học.
Một trong những phương pháp khắc phục vấn đề thuật ngữ là xây dựng bộ từ
vựng về lĩnh vực ứng dụng. Mỗi lần gặp một thuật ngữ mới thì nhóm yêu cầu
cần tìm hiểu để biết được một cách chính xác ý nghĩa và đưa thuật ngữ này vào
bộ từ vựng. Sau khi đã có những hiểu biết nhất định về lĩnh vực ứng dụng phần
mềm, các thành viên bắt đầu khám phá, tìm hiểu các yêu cầu khách hàng theo
các cách thức sau:

1.1. Phỏng vấn khách hàng
Có hai kiểu phỏng vấn: có cấu trúc (structured) và không có cấu trúc
(unstructured). Với kiểu phỏng vấn cấu trúc thì các câu hỏi đóng (close-ended)
và được chuẩn bị trước. Ví dụ như: "công ty sử dụng bao nhiêu nhân viên bán
hàng", "lương trung bình của các nhân viên trong công ty là bao nhiêu" Trong
cách phỏng vấn không có cấu trúc thì các câu hỏi có tính mở (open-ended) được
đưa ra. Ví dụ: "Hãy nêu ra một vài điểm yếu của phần mềm đang sử dụng mà
101
khách hàng có ý định thay thế". Tuy nhiên, cũng không nên hỏi những câu quá
chung chung, khó trả lời như: "Hãy nói cho tôi biết về sản phẩm hiện tại". Các
câu hỏi mở nên đưa ra sao cho có thể khích lệ người được phỏng vấn có thể cho
câu trả lời trong một phạm vi rộng, tuy nhiên cũng không nên rộng quá mà chỉ
nằm trong phạm vi các thông tin cần nắm bắt. Phỏng vấn có hiệu quả là công
việc không dễ dàng. Điều kiện quan trọng đầu tiên là người phỏng vấn cần am
hiểu về lĩnh vực mà họ chuẩn bị phỏng vấn. Các câu hỏi đưa ra cũng phải hợp lý
để người được phỏng vấn có thể nói ra những thông tin có ích cần thiết một cách
tự nhiên, không bị gò ép hay e ngại gì. Đôi khi những câu hỏi quá thẳng thắn và
trực tiếp chưa chắc đã nhận được câu trả lời đúng. Ví dụ nếu hỏi rằng "lương anh
chị rất thấp, nhưng chi tiêu thì có vẻ rất nhiều. Anh chị hãy cho biết làm sao có
được khoản tiền ngoài lương kia " thì thường là người được hỏi sẽ tìm cách né
tránh câu trả lời thật.
Sau khi phỏng vấn xong thì người phỏng vấn cần viết báo cáo về kết quả
phỏng vấn và nên đưa cho người được phỏng vấn xem và góp ý kiến.
1.2. Kịch bản (scenario)
Kịch bản là một kỹ thuật được sử dụng để phân tích yêu cầu. Kịch bản
là mô tả các thao tác cần thực hiện trên phần mềm cần xây dựng để hoàn thành
một công việc nào đó (trong các công việc mà phần mềm cung cấp).
1.3. Một vài kỹ thuật nắm bắt yêu cầu khác
Một kỹ thuật khác hay được sử dụng để nắm bắt các yêu cầu khách
hàng là gửi các bảng câu hỏi cho một số thành viên đại diện của công ty khách

hàng. Bằng cách này có thể gửi cho hàng trăm thành viên để nhận được các câu
trả lời dưới dạng viết, được suy nghĩ kỹ. Tuy nhiên, nếu từ bảng câu hỏi đã được
trả lời, người phỏng vấn có thể đưa ra thêm các câu hỏi thích hợp với người được
phỏng vấn thì có thể nhận được các thông tin bổ ích. Đôi khi các thông tin này
có ích hơn nhiều so với trả lời viết đã có.
Một cách khác để tìm hiểu và nắm bắt yêu cầu khách hàng, đặc biệt trong môi
trường kinh doanh, là xem xét các biểu mẫu khác nhau mà các khách hàng sử
dụng. Ví dụ, từ việc xem xét các biểu mẫu được in ra có thể biết được các dạng
báo cáo, cỡ giấy; tài liệu viết về cách thức điều hành hoặc mô tả công việc là
102
những công cụ rất hữu ích để giúp tìm ra công việc gì đang được thực hiện, và
được thực hiện như thế nào ở công ty khách hàng.
Gần đây, người ta thường áp dụng thêm một phương pháp nữa là quay băng
video cảnh làm việc ở công ty khách hàng (tất nhiên là được sự cho phép của
công ty và của những người được quay). Như vậy, có thể biết được chính xác
những gì đang xảy ra. Tuy nhiên, cách này có một nhược điểm là phải tốn khá
nhiều thời gian để xem lại băng và phân tích để rút ra những thông tin cần thiết.
Một nhược điểm rất lớn khác của phương pháp này là phần lớn những người
được quay đều không thích mình xuất hiện trong máy quay và trở nên dè dặt khi
hành động.
Sau khi thu được các thông tin ban đầu về yêu cầu khách hàng, bước tiếp theo
là phân tích các yêu cầu đó để rút ra những thông tin cơ bản nhất có thể giúp ích
cho việc xây dựng phần mềm.
2. Phân tích yêu cầu
Tới thời điểm này, nhóm yêu cầu đã có được tập hợp khởi đầu các yêu cầu
khách hàng. Các yêu cầu này được phân làm hai loại: chức năng (functional) và
phi chức năng (nonfunctional).
Yêu cầu chức năng thường gắn với chức năng tương ứng của phần mềm cần
xây dựng và thể hiện dưới dạng các mục chọn của thực đơn, ví dụ như: "Phần
mềm cung cấp chức năng tìm kiếm hàng hóa theo tên hàng và ngày bán". Đặc tả

phi chức năng dùng để chỉ rõ tính chất nào đó của phần mềm cần xây dựng, ví dụ
tính tin cậy và bảo trì được; hoặc liên quan đến môi trường mà phần mềm được
sử dụng, ví dụ: tất cả các mã khách hàng được nhập trực tiếp từ bàn phím và
được lưu trong một tệp bảng dữ liệu". Tóm lại yêu cầu chức năng là nói đến một
công việc cụ thể, thường thể hiện bằng các mục chọn trong chương trình; còn
yêu cầu phi chức năng thì nói về các tính chất của phần mềm, các tính chất này
không thể thể hiện được bằng một việc cụ thể. Thí dụ từ câu: "yêu cầu phần mềm
phải có giao diện đẹp, thân thiện với người sử dụng", ta không thể nói được cụ
thể là phải làm gì.
Một điều rất quan trọng là phần mềm phải theo dõi được (traceable). Điều
này có nghĩa là có thể kiểm tra xem tất cả các yêu cầu đã được thể hiện trong bản
đặc tả chưa; điểm nào trong bản báo cáo yêu cầu tương ứng với điểm nào trong
báo cáo đặc tả. Tương tự, báo cáo thiết kế hay chương trình cũng phải tương ứng
103
với các tài liệu trước đó. Như vậy, nhóm bảo đảm chất lượng phần mềm có thể
kiểm tra xem có phải tất cả các mục trong các yêu cầu khách hàng đã được thực
hiện hay chưa.
Tất cả các yêu cầu thu thập được ban đầu đều được đưa cho khách hàng xem
xét. Họ sẽ sắp xếp các mục yêu cầu theo thứ tự quan trọng, phát hiện và hiệu
chỉnh những điều không chính xác hoặc bỏ đi những mục không cần thiết
Tiếp theo, nhóm yêu cầu sẽ thảo luận với những khách hàng đã được phỏng
vấn và xem xét lại các vấn đề một cách kỹ càng, xem có điều gì còn bị bỏ sót
không. Và như chúng ta biết, kỹ thuật phân tích yêu cầu hiệu quả và chính xác
nhất là làm bản mẫu, vì vậy nếu có thể thì nhóm chuyển qua bước làm bản mẫu
để đưa cho khách hàng xem xét một cách trực quan hơn.
3. Làm bản mẫu (prototyping)
Bản mẫu được xem là kỹ thuật phân tích yêu cầu chính xác nhất.
Bản mẫu là phần mềm được xây dựng nhanh chủ yếu để thể hiện các chức
năng quan trọng nhất của phần mềm cần xây dựng. Mục đích của bản mẫu là thể
hiện các yêu cầu khách hàng, do đó khi xây dựng người ta chú ý nhiều đến giao

diện và các báo cáo in ra. Những vấn đề quan trọng khác mà một phần mềm sản
phẩm cần phải có như tính bảo mật, an toàn dữ liệu, tốc độ tính toán, kiểm tra và
khắc phục lỗi đều chưa được chú ý khi làm bản mẫu; nghĩa là bản mẫu chỉ là
thể hiện bên ngoài của sản phẩm và bỏ qua những phần được che dấu. Bản mẫu
được cài đặt để khách hàng sử dụng thử. Qua việc thao tác trực tiếp với bản mẫu,
họ sẽ thấy được các chức năng của phần mềm đã thể hiện đúng các yêu cầu của
họ chưa, cái gì cần thêm bớt hay hiệu chỉnh bổ sung. Những người phát triển sẽ
hiệu chỉnh bản mẫu cho đến khi khách hàng vừa ý và cho rằng mọi yêu cầu của
họ đã được bao hàm trong phần mềm (tất nhiên là về hình thức). Bản mẫu sẽ
được dùng làm cơ sở để biên soạn tài liệu đặc tả.
Như tên gọi của nó, bản mẫu nhanh (rapid prototype) được xây dựng với mục
đích để người phát triển và khách hàng thống nhất càng nhanh càng tốt những
điều mà sản phẩm chính cần làm. Như vậy, nhiều điều có thể bỏ qua khi làm bản
mẫu. Bản mẫu có thể thường xuyên gặp sự cố và phải khởi động lại; màn hình
nhập dữ liệu có thể chưa đẹp; báo cáo in ra còn thiếu biểu tượng công ty khách
hàng,
104
4. Tính thân thiện với người dùng của phần mềm
Khách hàng thao tác với bản mẫu thông qua giao diện người sử dụng (user
interface) hay còn gọi là "giao diện người máy" (human-computer interface,
HCI). Nên khuyến khích khách hàng làm quen và chú ý tới giao diện người máy.
Điều này có thể giúp cho sản phẩm sau này đạt được "tính thân thiện với
người sử dụng" (user-friendliness), một tiêu chuẩn quan trọng của tất cả các phần
mềm. Một phần mềm có tính thân thiện với người sử dụng có nghĩa là phần mềm
đó dễ học sử dụng đối với cả những người ít hiểu biết về máy tính.
Một chương trình thân thiện với người sử dụng thường bao gồm các yếu tố
sau: dùng thực đơn hoặc các biểu tượng thay cho lệnh phải nhớ; luôn có sẵn trợ
giúp màn hình mỗi khi ấn phím; các chức năng của chương trình được tổ chức
trên bàn phím theo một trật tự logic; các thông báo lỗi có giải thích nguyên nhân
và cách khắc phục; các tính năng trung gian và phức tạp được làm ẩn, không

nhìn thấy để khỏi gây rối màn hình và lẫn lộn cho người mới học
Bản mẫu nên được xây dựng có giao diện người máy thân thiện với người
dùng (user-friendly HCI). HCI của bản mẫu gần giống với HCI của sản phẩm
thật, như vậy sau này khách hàng sẽ nhanh chóng làm quen với sản phẩm thật và
cảm thấy là các yêu cầu của họ đã được đáp ứng.
5. Bản mẫu như một kỹ thuật đặc tả
Bản mẫu được sử dụng như một công cụ để xác định rằng: các yêu cầu của
khách hàng đã được nhận biết một cách chính xác. Khi bản đặc tả hoàn thành và
được ký duyệt bởi khách hàng thì vai trò của bản mẫu cũng kết thúc. Tuy nhiên,
có một cách tiếp cận khác là người ta xem bản mẫu như đặc tả, hoặc một phần
quan trọng của đặc tả. Như vậy, không cần tốn thời gian viết bản đặc tả và những
khó khăn thường gặp trong phần đặc tả như sự không rõ ràng, thiếu các thành
phần hoặc có sự mâu thuẫn sẽ không còn. Vì bản mẫu thay thế đặc tả, nên ta chỉ
cần ghi chú rằng: sản phẩm thật sẽ hoạt động giống như bản mẫu, đồng thời liệt
kê thêm các đặc trưng khác mà sản phẩm cần có như cập nhật tệp, bảo mật, xử lý
lỗi Tuy nhiên, việc sử dụng bản mẫu như đặc tả cũng có nhiều nhược điểm khó
khắc phục. Đặc tả là tài liệu được khách hàng ký duyệt, là căn cứ để nhà phát
triển và khách hàng ký hợp đồng. Rõ ràng, bản mẫu không thể thay thế vai trò
này của đặc tả, không thể căn cứ vào bản mẫu để kết luận rằng điểm này hay
105
điểm khác của hợp đồng chưa được thực hiện đúng. Cho dù phần mềm được
phát triển trong nội bộ cơ quan thì vẫn có thể có vấn đề nảy sinh giữa người phát
triển và người quản lý. Rõ ràng, các nhà phát triển không thể chỉ dựa vào bản
mẫu để thuyết phục các nhà quản lý là họ đã làm đúng các yêu cầu mà cơ quan
đặt ra.
Lý do thứ hai khiến cho việc sử dụng bản mẫu làm đặc tả bị hạn chế là vấn đề
bảo trì. Cho dù có đầy đủ các tài liệu thì việc bảo trì bao giờ cũng là công việc
khó khăn và tốn nhiều tiền của. Nếu thiếu tài liệu đặc tả thì việc bảo trì thực sự
trở thành cơn ác mộng. Đặc biệt với công việc bảo trì nâng cao (enhancement),
tức là thay đổi các yêu cầu ban đầu thì công việc thay đổi lại thiết kế đặc biệt khó

khăn nếu không có tài liệu đặc tả.
Vậy chỉ nên xem bản mẫu là một kỹ thuật phân tích yêu cầu. Nó được sử
dụng để bảo đảm rằng các yêu cầu của khách hàng đã được nắm bắt một cách
đầy đủ và chính xác. Bước tiếp theo là dựa vào bản mẫu để biên soạn tài liệu đặc
tả dưới dạng văn bản.

Có nên sử dụng lại bản mẫu?
Thực tế cho thấy rằng cho dù về hình thức bản mẫu giống với sản phẩm thật
và có thể hiệu chỉnh để trở thành sản phẩm thật, nhưng về chất lượng thực sự thì
bản mẫu và sản phẩm thật còn một khoảng cách rất lớn. Ví dụ như phần lưu trữ
dữ liệu hay một số phần chất lượng cao như thuật toán tối ưu, tính bảo mật, còn
chưa có trong bản mẫu. Kinh nghiệm cho thấy rằng nên thiết kế lại và xây dựng
lại hoàn toàn phần mềm. Chỉ nên sử dụng một số phần của bản mẫu được tạo
nên bởi các bộ công cụ CASE như bộ tạo màn hình (screen generator), tạo báo
cáo (report generator). Cũng có khi bản mẫu và bản chính không sử dụng cùng
một ngôn ngữ lập trình. Trong trường hợp này thì việc viết lại hoàn toàn bản
chính là điều khá hiển nhiên, không thể khác được.
6. Sử dụng các công cụ CASE trong pha yêu cầu
Có thể sử dụng một ngôn ngữ lập trình nào đó để viết bản mẫu. Vai trò của
bản mẫu là cầu nối giữa người phát triển và khách hàng để người phát triển nắm
bắt nhanh và đầy đủ các yêu cầu khách hàng. Như vậy bản mẫu cần được viết
càng nhanh càng tốt. Người ta thấy rằng ngôn ngữ lập trình thông dịch
(interpreted language) khá thích hợp cho việc xây dựng bản mẫu, vì không mất
106
thời gian để dịch hay liên kết như ngôn ngữ biên dịch (compiler). Tính hiệu quả
được nâng cao nếu công cụ CASE được liên kết cùng với ngôn ngữ lập trình.
Các ngôn ngữ có hỗ trợ công cụ CASE như Smalltalk, Java, Perl (Practical
Extraction and Report Language) có thể sử dụng để xây dựng bản mẫu nhanh và
hiệu quả. HTML cũng là một ngôn ngữ làm bản mẫu được ưa chuộng. Nếu bản
mẫu chắc chắn được vứt đi thì HTML còn một lợi điểm nữa: thật khó hình dung

sản phẩm chuyển giao lại được viết bằng HTML, như vậy việc viết bản mẫu
bằng HTML gần như được ngầm hiểu là bản mẫu sẽ được vứt đi.
Trong những năm gần đây, một số ngôn ngữ lập trình thuộc thế hệ thứ 4
(fourth-generation laguage, 4GL) như Oracle, PowerBuilder và DB2 cũng được
sử dụng để làm bản mẫu. Mục đích thiết kế của hầu hết 4GL là viết ít dòng lệnh
hơn cho cùng một chức năng so với ngôn ngữ thế hệ thứ 3 như Java, Ada hay C+
+. Phần lớn 4GL là thông dịch và được hỗ trợ các công cụ CASE tính năng cao,
do đó làm tăng tốc độ xây dựng bản mẫu.
Tuy nhiên 4GL cũng có nhược điểm. Môi trường CASE trong đó 4GL được
nhúng thường là một phần của một tập hợp lớn hơn các công cụ được sử dụng
cho một quy trình phần mềm đầy đủ (complete software process). Các nhà cung
cấp 4GL thường khuyến khích sử dụng ngôn ngữ của họ làm bản mẫu, sau đó
hoàn thiện dần thành bản chính thức. Các nhà cung cấp không nhận thức được
rằng bằng cách này quy trình phần mềm có thể suy thoái thành mô hình xây
dựng-và-hiệu chỉnh (build-and-fixed model). Đáng tiếc là các nhà cung cấp 4GL
muốn khách hàng mua sản phẩm của họ và họ quảng cáo rằng công cụ CASE
của họ có thể thực hiện mọi phần công việc của một dự án phần mềm.
Giả sử rằng người quản lý dự án đã bỏ ra khá nhiều tiền để mua công cụ
CASE hỗ trợ cho tất cả các pha của quy trình phần mềm. Thật khó thuyết phục
họ bỏ thêm tiền mua một ngôn ngữ khác để phát triển phần mềm chính thức và
bỏ đi bản mẫu vừa mới xây dựng. Tuy nhiên, cần chỉ cho họ thấy rằng cho dù
như vậy vẫn còn rẻ hơn là cố giữ lại bản mẫu và phát triển nó thành sản phẩm
chính thức. Sẽ tốn một số tiền khổng lồ cho việc chuyển đổi bản mẫu thành bản
chính thức và bảo trì sau này.
7. Kiểm thử pha xác định yêu cầu
Trong mỗi công ty phần mềm cần có một nhóm làm việc mà nhiệm vụ
chính của họ là bảo đảm rằng phần mềm hoạt động tốt và đáp ứng đúng các yêu
107
cầu của khách hàng. Nhóm này được gọi là nhóm bảo đảm chất lượng phần mềm
(SQA = software quality assurance). Nhóm SQA bắt đầu thực hiện vai trò của

mình ngay từ pha khởi đầu. Nếu sử dụng bản mẫu thì trong pha này nhóm cùng
khách hàng kiểm thử phiên bản cuối cùng của bản mẫu xem nó đã thực hiện
đúng các yêu cầu mà khách hàng cần hay không.
8. Tài liệu báo cáo trong pha xác định yêu cầu
Tài liệu được biên soạn trong pha yêu cầu bao gồm bản mẫu và các
ghi chép trong quá trình trao đổi với khách hàng. Những ghi chép này chính là
cơ sở để những người phát triển xây dựng và sửa đổi bản mẫu. Nếu nhóm phát
triển không làm bản mẫu thì tài liệu sẽ mô tả những yêu cầu của khách hàng. Tài
liệu này được kiểm tra bởi khách hàng và một số người sử dụng trước khi được
nhóm SQA kiểm tra kỹ lưỡng và chi tiết.
IV – PHA ĐẶC TẢ CÓ CẤU TRÚC
Pha đặc tả hay còn được gọi là pha phân tích, là tiếp theo pha yêu cầu. Nếu
gọi là pha phân tích thì dễ nhầm với giai đoạn phân tích yêu cầu trong pha yêu
cầu, do đó người ta thường gọi là pha đặc tả (specification). Tài liệu báo cáo của
pha này phải thỏa mãn hai yêu cầu trái ngược nhau. Một mặt, tài liệu phải rõ
ràng, dễ hiểu đối với khách hàng, thường là những người không phải là chuyên
gia máy tính. Mặt khác, tài liệu đặc tả lại phải đầy đủ và chi tiết, bởi vì đây gần
như là nguồn duy nhất để soạn thảo thiết kế. Như vậy tài liệu đặc tả là mô tả sản
phẩm trong một khuôn dạng không mang tính kỹ thuật quá, sao cho có thể dễ
hiểu đối với khách hàng, nhưng đồng thời cũng phải đủ chính xác để căn cứ vào
đó có thể xây dựng được phần mềm không có lỗi, đúng như yêu cầu của khách
hàng. Chúng ta sẽ tìm hiểu hai kỹ thuật đặc tả: kỹ thuật cổ điển hay còn gọi là
kỹ thuật đặc tả có cấu trúc (hoặc còn gọi là phân tích có cấu trúc) và phân tích
hướng đối tượng. Chương này, chúng ta sẽ tìm hiểu kỹ thuật đặc tả có cấu trúc,
còn trong chương 5 tiếp theo sẽ nghiên cứu kỹ thuật đặc tả hướng đối tượng
hay còn được gọi đơn giản là phân tích hướng đối tượng. Lưu ý rằng trong thuật
ngữ "phân tích có cấu trúc" thì từ "cấu trúc" đóng vai trò tính từ bổ nghĩa cho
phân tích. Thuật ngữ này được dịch từ tiếng Anh là "structured analysis" hoặc
"structured specification". Như vậy, nếu dịch đúng thì phải là "phân tích theo
kiểu cấu trúc". Từ "cấu trúc" ở đây khác với ý nghĩa của từ "cấu trúc" trong câu

108
"phân tích cấu trúc câu", vì trong câu này thì từ "cấu trúc" là danh từ. Thuật ngữ
"phân tích hướng đối tượng" cũng được dịch từ thuật ngữ tiếng Anh là "object-
oriented analysis", và cũng có nghĩa là "phân tích theo kiểu hướng đối tượng".
Như vậy, cùng một hệ thống cần xây dựng, nhưng ta có thể nhìn nhận và xem
xét theo phương pháp cấu trúc hoặc theo phương pháp hướng đối tượng. Để bạn
đọc tránh được sự hiểu nhầm, chúng tôi đôi khi sẽ gọi là "phân tích (hay đặc tả)
theo phương pháp cấu trúc" và "phân tích theo phương pháp hướng đối tượng".
Tuy nhiên, thường thì chúng tôi cũng viết đơn giản là "phân tích có cấu trúc"
và "phân tích hướng đối tượng" như các tài liệu khác thường sử dụng. Chúng ta
sẽ sử dụng khá nhiều lần thuật ngữ "hệ thống". Từ "hệ thống" ở đây là nói tới
phần mềm cần xây dựng được đặt trong môi trường nó được ứng dụng. Cho nên
ta nói "phân tích hệ thống", có nghĩa là ta xem xét chương trình cần xây dựng
cùng với các yếu tố liên quan. Ví dụ, với chương trình quản lý bán hàng thì ta
xem xét chương trình cùng với các thao tác liên quan đến người bán hàng và
khách hàng Tóm lại, khi nói "phân tích hệ thống" thì ta hiểu đó chính là phân
tích phần mềm cần xây dựng.
1. Tài liệu đặc tả
Ta đã biết rằng tài liệu trong pha yêu cầu hoặc là bản mẫu, tức là chương
trình trong đó chỉ chú ý đến giao diện, cốt thể hiện được các yêu cầu của khách
hàng; hoặc là tài liệu mô tả các yêu cầu của khách hàng được viết bằng ngôn ngữ
tự nhiên. Nhiệm vụ của pha đặc tả là mô tả phần mềm thực hiện các yêu cầu đó.
Phải mô tả đầy đủ và chi tiết, sao cho có thể dựa vào đó để đánh giá phần
mềm sau này có đáp ứng được yêu cầu đặt ra hay không. Tài liệu đặc tả còn là
cơ sở để thực hiện thiết kế. Nếu như tài liệu đặc tả trả lời câu hỏi "phần mềm
phải làm những việc gì?" thì tài liệu thiết kế lại trả lời câu hỏi "phải làm những
việc đó như thế nào?".
Vào những năm 60, 70 của thế kỷ trước, người ta vẫn dùng ngôn ngữ tự nhiên
để viết tài liệu đặc tả. Tuy nhiên, người ta phát hiện rằng tài liệu biên soạn theo
kiểu như thế này rất hay lỗi và có nhiều điều mập mờ. Ví dụ, chỉ với tài liệu đặc

tả của Naur (1969) cho vấn đề xử lý văn bản mà từ đó có thể viết thành chương
trình khoảng từ 25 đến 30 dòng lệnh, người ta đã phát hiện ra nhiều lỗi.
Trong năm 1985, Mayer đã viết một bài báo nói về vấn đề này. Mayer đưa ra
kết luận rằng: nếu dùng ngôn ngữ tự nhiên để viết đặc tả thì sẽ dẫn đến tình trạng
109
tài liệu đặc tả chứa đựng các mâu thuẫn, những điều nhập nhằng không hiểu
được nghĩa chính xác hoặc bị thiếu, không đầy đủ. Ông đề nghị sử dụng các
thuật ngữ toán học để biểu diễn đặc tả một cách hình thức. Mayer đã dùng cách
này để đặc tả vấn đề xử lý văn bản và từ đặc tả toán học ông đã chuyển đổi thành
đặc tả bằng tiếng Anh. Tuy nhiên người ta lại tìm thấy những điều nhập nhằng
trong đặc tả tiếng Anh này. Vậy ngôn ngữ tự nhiên không phải là cách thức tốt
để biểu diễn đặc tả. Vào những năm 70, có một số tác giả đã dùng các biểu tượng
trực quan (đồ họa) để biểu diễn đặc tả. Có ba kỹ thuật đồ họa đã trở thành nổi
tiếng và được sử dụng nhiều. Đó là của DeMarco (1978), Gane và Sarsen
(1979), Yourdon và Constantine (1979). Cả ba kỹ thuật này đều khá tốt và về cơ
bản là tương đương. Tuy nhiên kỹ thuật của Gane và Sarsen được sử dụng nhiều
hơn và do đó chúng ta sẽ tìm hiểu kỹ thuật này trong các phần tiếp theo.
2. Phân tích hệ thống bằng phương pháp cấu trúc
Phương pháp phân tích có cấu trúc (structured analysis, SA) do DeMacro
và những người khác đề xuất vào khoảng những năm 70 của thế kỷ trước.
Phương pháp này ngày nay vẫn còn phát huy tác dụng, đặc biệt là với các hệ
thống thông tin quản lý. Nó vẫn là nền tảng của một số phần mềm trợ giúp phân
tích và thiết kế nổi tiếng, như Designer 2000 của Oracle chẳng hạn. Đặc điểm
của phương pháp này là đơn giản, dễ thực hiện nhưng không quá sơ lược. Công
cụ chính được sử dụng là biểu đồ luồng dữ liệu (data flow diagram, DFD) mà ta
sẽ tìm hiểu trong các phần sau. Mục đích của SA là tiến hành phân tích các chức
năng của hệ thống thực tế để thành lập một mô hình logic cho hệ thống, dưới
dạng một hay nhiều DFD. Nó vận dụng ba kỹ thuật:
- Kỹ thuật phân mức, hay còn gọi là phân tích từ trên xuống (top-down
analysis): thực chất là phân rã yếu tố phức tạp thành các yếu tố đơn giản hơn.

- Kỹ thuật chuyển đổi DFD vật lý (trong đó chứa đựng các yếu tố vật lý như
đĩa, băng từ, giấy, máy in ) thành DFD logic (đã loại bỏ các yếu tố vật lý).
- Kỹ thuật chuyển đổi DFD của hệ thống cũ thành DFD của hệ thống mới
bằng cách thêm, bớt, hiệu chỉnh lại các yếu tố trên DFD cũ.
110
2.1. Một số kỹ thuật thường sử dụng trong công nghệ phần mềm
Các kỹ sư phần mềm thường sử dụng hai loại công cụ: loại công cụ
dùng để phân tích (analytical tool) như tinh chỉnh từng bước (stepwise
refinement) hoặc phân tích mối quan hệ vốn-lãi (cost-benefit analysis), và các
phần mềm được dùng để phát triển, bảo trì các phần mềm khác. Các bộ phần
mềm đóng vai trò như máy cái để phát triển các phần mềm khác được gọi là
công cụ CASE (computer-aided software engineering). Trong phần này, chúng ta
sẽ chỉ xem xét kỹ thuật tinh chỉnh từng bước, là kỹ thuật được làm nền tảng cho
rất nhiều kỹ thuật khác của công nghệ phần mềm. Bản chất của tinh chỉnh là
"hoãn đưa ra các quyết định về chi tiết đến chừng nào có thể, nhằm tập trung vào
các điểm trọng yếu nhất". Lý do sử dụng kỹ thuật tinh chỉnh chính là định luật do
Miller đưa ra vào năm 1956, trong đó nói rằng con người ta cùng lúc chỉ có thể
tập trung sự chú ý của họ vào một vấn đề. Khi phát triển phần mềm thường có
khá nhiều vấn đề cần xem xét trong cùng thời gian. Ví dụ như class thường có
nhiều hơn 7 thuộc tính và phương thức, mỗi khách hàng thường có nhiều hơn 7
yêu cầu Kỹ thuật tinh chỉnh giúp cho các kỹ sư phần mềm chỉ cần chú ý tới
khoảng 7 vấn đề thích hợp nhất tại mỗi thời điểm trong quá trình phát triển phần
mềm.
2.2. Một số dạng biểu đồ thường sử dụng
Như chúng tôi đã đề cập, việc dùng đồ họa để biểu diễn các vấn đề
được sử dụng từ khá lâu và tỏ ra khá hiệu quả, không chỉ riêng trong lĩnh vực
công nghệ phần mềm mà cả trong các lĩnh vực khác. Biểu diễn đồ họa cho chúng
ta một hình ảnh trực quan, dễ nắm bắt hơn là viết hoặc sử dụng lời nói. Trong
công nghệ phần mềm, kỹ thuật này chủ yếu được dùng từ pha đặc tả, nhưng đôi
khi được sử dụng cả trong pha yêu cầu để làm cho vấn đề được rõ ràng hơn. Ví

dụ, trong pha yêu cầu có thể dùng sơ đồ biểu diễn tổ chức một cơ quan, sự trao
đổi thông tin giữa các bộ phận Ta thường gặp những dạng sơ đồ sau đây trong
công nghệ phần mềm:
2.2.1. Biểu đồ phân cấp chức năng (FD)
Biểu đồ phân cấp chức năng (functional diagram, FD) là loại biểu
đồ có cấu trúc cây diễn tả sự phân rã dần dần các chức năng từ đại thể đến chi
tiết. Mỗi nút trong biểu đồ là một chức năng, và quan hệ duy nhất giữa các nút là
111
quan hệ bao hàm: chức năng trong nút cha bao gồm các chức năng trong các nút
con. Hình 5.1. sau là biểu đồ biểu diễn các chức năng quản lý của một doanh
nghiệp.

Hình 5.1. Một biểu đồ phân cấp chức năng
Đặc điểm của biểu đồ chức năng là:
- Cho một cách nhìn khái quát, từ đại thể đến chi tiết về các chức năng,
nhiệm vụ cần thực hiện.
- Dễ xây dựng, bằng các phân rã dần các chức năng từ trên xuống.
- Thiếu sự trao đổi thông tin giữa các chức năng.
Đối với hệ thống phức tạp thì sự trao đổi thông tin giữa các chức năng là
không thể thiếu, do đó biểu đồ này chỉ được sử dụng làm mô hình chức năng như
phần mở đầu của pha đặc tả, hoặc thậm chí được sử dụng trong pha yêu cầu hoặc
trong phần riêng về tìm hiểu lĩnh vực ứng dụng.
Đối với hệ thống đơn giản, các chức năng được xử lý một cách độc lập (tức là
không có trao đổi thông tin cho nhau) thì mô hình phân tích chức năng có thể sử
dụng làm tài liệu đặc tả cho hệ thống. Có thể thấy rằng, những xử lý thực sự chỉ
xẩy ra ở các nút lá, vì chức năng ở nút cha lại được phân rã thành các chức năng
ở các nút con của nó. Thường thì chức năng ở nút lá là khá đơn giản, có thể giải
thích trực tiếp mà không cần phân rã tiếp. Cách diễn tả thao tác cần thực hiện ở
nút lá được gọi là đặc tả chức năng và gọi tắt là P-spec (process specification).
Mô tả này thường được trình bày một cách ngắn gọn, không vượt quá một

trang giấy A4, và gồm hai phần: đầu đề và thân. Đầu đề gồm tên chức năng, các
dữ liệu vào, dữ liệu hoặc kết quả ra. Phần thân mô tả nội dung xử lý, ví dụ công
thức toán học, bảng hoặc cây quyết định, sơ đồ khối, ngôn ngữ tự nhiên cấu trúc
hóa. Hình sau là một ví dụ về đặc tả chức năng.
Đầu đề:
112
Theo dõi
nhân sự
Trả công
Kế toán
thu chi
Kế toán
tổng hợp
Quản lý doanh nghiệp
Qlý nhân sự Q.lý tài chính Q.lý vật tư Q.lý khách hàng
Tên chức năng:Trả công
Đầu vào: Hệ số lương a và số ngày công n trong
tháng
Đầu ra: Lương
Thân:
Lương = n*a*10
Hình 5.2. Một P-spec
Chú ý: Cần phân biệt FD với sơ đồ tổ chức một cơ quan. Ví dụ như sơ đồ sau:
Hình 5.3. Một sơ đồ tổ chức
Bởi sự phân cấp quản lý cũng thường được áp dụng trong các cơ quan, cho
nên sơ đồ tổ chức cũng có dạng cây. Nói chung cũng có sự tương ứng giữa tổ
chức và chức năng, nhưng sự tương ứng này không nhất thiết là 1-1, do đó cấu
trúc cây phân cấp chức năng có thể không có dạng như cây sơ đồ tổ chức. Các
nút trên cây chức năng biểu thị các chức năng tức là công việc cần thực hiện; còn
các nút trên cây sơ đồ tổ chức lại là tên các bộ phận

Sơ đồ tổ chức chỉ được dùng khi cần thiết trong pha yêu cầu hoặc trong phần
riêng về tìm hiểu lĩnh vực ứng dụng.
2.2.2. Các lưu đồ hệ thống (SD)
Lưu đồ hệ thống (systematic diagram) là một loại biểu đồ được sử
dụng để diễn tả quá trình xử lý thông tin của một hệ thống với các đặc điểm sau:
- Sự diễn tả là ở mức vật lý, nghĩa là chỉ rõ cả phương tiện xử lý, ví dụ đưa
thông tin ra trên giấy hay băng từ, đĩa từ
- Chỉ rõ các công việc cần thực hiện.
- Chỉ rõ trình tự các công việc và các thông tin được chuyển giao giữa các
công việc đó.
Loại biểu đồ này được IBM đề xuất. SD phục vụ cho sự diễn tả ở mức độ vật
lý và cũng khá dễ hiểu. SD được sử dụng nhiều vào những năm 60-70 của thế kỷ
trước. Chúng thường được sử dụng ở giai đoạn khảo sát hệ thống cũ hoặc ở giai
113
Ban Giám đốc
Phòng tổ chức Phòng tài vụ Phòng vật tư Phòng kinh doanh
đoạn thiết kế. Ngày nay các phương tiện xử lý và lưu trữ thông tin khá đa dạng,
nên việc xây dựng biểu đồ quá chi tiết, chỉ rõ cả các phương tiện lưu trữ sẽ làm
cho biểu đồ trở nên quá phức tạp và bị hạn chế trong ứng dụng, do đó người ta ít
sử dụng.
2.2.3. Biểu đồ luồng dữ liệu (DFD)
Biểu đồ luồng dữ liệu, tên tiếng Anh là "data flow diagram"
(DFD), là một loại biểu đồ được sử dụng để diễn tả quá trình xử lý thông tin của
một hệ thống với các đặc điểm sau:
- Sự diễn tả là ở mức logic (nghĩa là không chỉ rõ phương tiện xử lý và lưu
trữ thông tin).
- Chỉ rõ các công việc cần thực hiện.
- Chỉ rõ trình tự các công việc và các thông tin được chuyển giao giữa các
công việc đó.
Các tác giả sử dụng một số biểu tượng khác nhau để biểu diễn DFD. Sau đây

là 4 biểu tượng mà Gane và Sarsen đã sử dụng:
(1)Các tác nhân: Một tác nhân (hay còn được gọi chính xác hơn là tác nhân
ngoài hay điểm mút), là một thực thể ngoài hệ thống, có trao đổi thông tin
với hệ thống. (Thực thể là một đối tượng tồn tại trong thế giới thực, ví dụ:
người, dự án, xe máy)
Tác nhân trong DFD được biểu diễn bằng một hình vuông, bên trong là
tên tác nhân. Ví dụ tác nhân "khách hàng" được biểu diễn như sau:
(Một số tác giả sử dụng biểu tượng hình chữ nhật)
(2)Các chức năng: Một chức năng là một thao tác biến đổi dữ liệu (thao tác
này có thể gồm nhiều thao tác khác nên còn được gọi là quá trình).
Chức năng được biểu diễn bằng hình chữ nhật có góc tròn. Ví dụ chức
năng "lập hóa đơn" được biểu diễn như sau:
(Một số tác giả sử dụng hình tròn hoặc hình ô van.
(3)Các luồng dữ liệu: một luồng dữ liệu là một tuyến truyền dẫn thông tin.
114
Khách
hàng
Lập hóa đơn
Luồng dữ liệu được biểu diễn bằng mũi tên, phía trên mũi tên là tên của
luồng dữ liệu. Ví dụ luồng dữ liệu "hóa đơn đã lập" được biểu diễn như
sau:
(4)Các kho dữ liệu: Một kho dữ liệu là nơi chứa dữ liệu để sử dụng về sau.
Tên kho dữ liệu được chứa trong một hình chữ nhật mở về phía bên phải.
Ví dụ kho dữ liệu "Hàng hóa" chứa danh sách các mặt hàng được biểu
diễn như sau:
Có tác giả sử dụngbiểu tượng là hai đoạn thẳng song song, ở giữa là tên
kho dữ liệu. Ví dụ kho dữ liệu "khách hàng" chứa danh sách các khách
hàng được biểu diễn như sau:
Ghi chú: từ định nghĩa các biểu tượng, ta có thể rút ra một số điều cần lưu ý
như sau:

- Không có luồng dữ liệu giữa hai tác nhân ngoài. Ví dụ với hệ thống phần
mềm hỗ trợ bán hàng của cửa hàng H có thể có các tác nhân ngoài là khách
hàng K và nhà cung cấp C. Rõ ràng có thể có mối liên hệ giữa khách hàng K
với nhà cung cấp C, nhưng mối liên hệ này không liên quan đến hệ thống nên
không được đưa vào biểu đồ.
- Không có luồng dữ liệu trực tiếp giữa hai kho dữ liệu (vì không có hai kho
khác nhau chứa cùng một loại dữ liệu)
- Nếu luồng dữ liệu cùng tên với đầu ra của chức năng thì không cần viết
lên luồng dữ liệu. Ví dụ:
Khi sử dụng DFD để làm tài liệu đặc tả người ta thường bổ sung thêm một số
yếu tố nữa. Ví dụ, ta thêm vào biểu đồ những biểu tượng diễn tả sự điều khiển.
115
Hóa đơn đã lập
Hàng hóa
Hàng hóa
Lập hóa đơn
Khách
hàng
Cũng giống với biểu đồ phân cấp chức năng, trong DFD đối với các chức
năng đơn giản ở mức cuối cùng phải có thêm P-spec, tức là bản đặc tả chức
năng.
2.2.4. Một số dạng biểu đồ khác
Ngoài các dạng biểu đồ nói trên người ta còn sử dụng nhiều dạng
biểu đồ khác, như biểu đồ MERISE chẳng hạn. Thậm chí, đôi khi nếu thấy cần
thiết, người ta có thể tự tạo lấy biểu đồ để diễn tả vấn đề của mình (ví dụ biểu đồ
diễn tả quá trình trao đổi công văn giấy tờ ở một cơ quan chẳng hạn). Nói cho
cùng, mục tiêu của chúng ta là xây dựng được phần mềm đúng như mong đợi,
vừa dễ bảo trì lại hoạt động chính xác. Nếu bằng cách nào đó, có thể làm được
điều này và có thể giải thích cho mọi người hiểu thì ta có thể làm. Những kiến
thức về công nghệ phần mềm mà con người đã tích lũy được dĩ nhiên là nguồn

tham khảo quý giá.
2.2.5. Các phương tiện đặc tả chức năng
Một điểm chung trong FD và DFD là để diễn tả một yếu tố, ta phân
rã nó thành các yếu tố đơn giản hơn. Ví dụ như với FD chẳng hạn, ta phân rã các
chức năng theo sơ đồ hình cây cho đến khi gặp chức năng đơn giản nhất không
phân rã được nữa thì dừng lại. Trên cây biểu diễn thì chức năng không phân rã
được thể hiện bằng nút lá và phải giải thích cụ thể. Cách giải thích này được gọi
là đặc tả chức năng (P-Spec), như chúng ta đã xem xét ở phần trên. Ở ví dụ trên,
ta đã dùng một công thức toán học làm phương tiện mô tả trong phần thân của P-
spec (Lương= n*a*10). Người ta còn sử dụng một số phương tiện khác như sau:
- Các bảng quyết định và cây quyết định.
Được sử dụng khi chức năng được đặc tả thực chất là một sự phân chia các
trường hợp tùy thuộc vào một điều kiện nào đó.
- Các sơ đồ khối.
Sơ đồ khối sử dụng 3 loại biểu tượng: hình thoi biểu diễn điều kiện, hình chữ
nhật biểu diễn hành động phải làm và mũi tên biểu diễn sự chuyển giao điều
khiển (chuyển giao quyền thực hiện). Với vấn đề đơn giản thì việc diễn tả bằng
sơ đồ khối khá dễ hiểu, vì vậy nó thích hợp cho người mới lập trình. Nếu như
các DFD chỉ tập trung diễn tả những việc phải làm thì sơ đồ khối ngoài các việc
phải làm, còn chỉ ra cách dẫn dắt thực hiện các việc đó. Vì vậy với vấn đề lớn, có
116
nhiều yếu tố và nhiều mối quan hệ thì sơ đồ khối rất phức tạp và khó xây dựng.
Do đó sơ đồ khối không thích hợp cho việc diễn tả các chức năng phức tạp.
- Ngôn ngữ giả lập trình (mã giả).
Về hình thức trông giống ngôn ngữ lập trình nhưng bỏ đi những chi tiết cụ
thể. Mục đích là giúp người đọc hiểu được thuật toán và cách thức viết chương
trình cho một ngôn ngữ lập trình bất kỳ nào đó.
2.3. Phân tích có cấu trúc một hệ thống cụ thể
Có thể nói rằng: không có một chuẩn mực chung để theo đó cứ thực
hiện từng bước là có thể xây dựng nên một phần mềm đáp ứng được yêu cầu đặt

ra. Cho dù đã có những nguyên lý chung, nhưng với từng vấn đề cụ thể, mỗi kỹ
sư phần mềm lại có cách nhìn nhận và phân tích khác nhau, do đó đưa ra các
cách giải quyết vấn đề khác nhau.
Bây giờ chúng ta sẽ bắt đầu công việc phân tích theo phương pháp cấu trúc
cho một bài toán cụ thể: xây dựng phần mềm hỗ trợ công việc bán hàng cho một
cửa hàng chuyên bán các đĩa CD lưu trữ các phần mềm máy tính, như đĩa cài đặt
Vietkey, Microsoft Office, VB, đĩa trò chơi
Giả sử chủ nhân của cửa hàng có tên là Hoa. Hoa mua các phần mềm từ các
nhà cung cấp khác nhau và bán lại cho khách hàng. Cô lưu trữ các đĩa được
nhiều người ưa chuộng và đặt mua các loại đĩa khác nếu cần. Hoa cho một vài cơ
quan và cá nhân có thể mua chịu. Có thể hình dung công việc hàng ngày của Hoa
diễn ra như sau:
Khi có khách hàng đến, hoặc là họ xem catalog chứa danh sách các băng đĩa,
hoặc họ nói ra tên băng đĩa cần mua. Hoa sẽ xem trên các ngăn để đĩa, hoặc
trong catalog để tìm đĩa mà khách yêu cầu. Nếu tìm thấy thì Hoa sẽ xem trong
danh sách khách hàng xem người khách này còn nợ không. Nếu khách đồng ý
mua thì hoặc là Hoa viết hoá đơn thanh toán bằng tiền mặt, hoặc lại ghi vào sổ
nợ. Giả sử bạn là người giúp Hoa tin học hóa công việc bán hàng này, và Hoa trở
thành khách hàng đặt bạn làm phần mềm. Gane và Sarsen đã đề nghị một kỹ
thuật gồm 9 bước để phân tích nhu cầu khách hàng (ở đây là khách hàng đặt làm
phần mềm, vậy chính là Hoa) như sau:
Bước 1. Xây dựng DFD (biểu đồ luồng dữ liệu).
Căn cứ vào vấn đề thực tế, bước đầu tiên có thể xây dựng DFD logic như sau:
117
Khách
hàng
Khách
hàng
Xử lý yêu cầu
mua hàng

Kho đĩa CD
Yêu cầu
Hóa đơn
Thông tin về đĩa
Thông tin về tiền nợ
Danh sách khách hàng
Hình 5.4. DFD đầu tiên trong quá trình tinh chỉnh
Căn cứ vào biểu đồ này ta có thể hình dung ra hai cách diễn tả như sau:
Cách diễn tả 1: kho dữ liệu đĩa CD chứa nhiều đĩa, ví dụ 900 đĩa chẳng hạn.
Các đĩa được xếp trên các ngăn. Trong ngăn kéo có một vài catalog chứa
danh sách các đĩa này. Kho dữ liệu khách hàng chính là tập các danh thiếp của
khách hàng được buộc bằng dây cao su, kèm theo là danh sách các khách hàng
mà tiền nợ đã quá hạn. Thao tác "xử lý yêu cầu mua hàng" có nghĩa là khi có
khách hàng yêu cầu mua đĩa nào đó, Hoa sẽ tìm trên các giá để đĩa và có thể là
trong các catalog. Sau đó Hoa lại tìm trong tập danh thiếp, rồi danh sách khách
hàng để kiểm tra khách hàng còn nợ chưa trả không. Nếu mọi việc ổn thì Hoa bắt
đầu viết hóa đơn đưa cho khách hàng. Đây là mô tả các thao tác trong thực tế,
chưa hề có bóng dáng của máy tính, nó phản ánh đúng những thao tác mà Hoa
thực hiện hàng ngày.
Cách diễn tả 2: kho dữ liệu đĩa CD hoặc danh sách khách hàng là các tệp
được lưu trữ trên đĩa cứng. Còn thao tác xử lý yêu cầu có nghĩa là Hoa nhập từ
bàn phím tên khách hàng và tên đĩa cần mua. Máy tính sau đó sẽ tìm kiếm trên
tệp chứa danh sách các đĩa và danh sách khách hàng. Trong trường hợp việc tìm
kiếm có kết quả và mọi điều kiện cần thiết thỏa mãn thì hóa đơn sẽ được in ra
cho khách hàng. Các diễn tả này tương ứng với giải pháp tin học hóa với mọi
thông tin được cung cấp trực tuyến (available online).
Trên đây là hai cách diễn tả. Thực ra còn có thể có nhiều cách khác.
Bây giờ chúng ta sẽ tinh chỉnh biểu đồ này. Ta thấy rằng thao tác "xử lý yêu
cầu khách hàng" còn quá đơn giản. Trong thực tế khi khách hàng muốn mua một
đĩa mà không có thì thường chủ hàng ghi lại thông tin này. Nếu có nhiều khách

hàng hỏi mua thì chủ hàng sẽ gửi yêu cầu của họ tới các nhà cung cấp để mua
loại đĩa mới này. Ta sẽ tinh chỉnh DFD 5.4. bằng cách chi tiết hoá thao tác "xử
lý yêu cầu khách hàng" như sau: nếu khách hàng yêu cầu thì Hoa xem xét ở kho
đĩa, đồng thời kiểm tra các thông tin về khách hàng. Nếu đĩa có trong kho và
thông tin về khách hàng không có vấn đề gì thì hóa đơn sẽ được lập và gửi cho
118
khách hàng. Nếu đĩa không có trong kho thì yêu cầu này tạm thời được đưa vào
kho dữ liệu "các yêu cầu đang treo", tức là các yêu cầu chưa được đáp ứng. Nếu
số yêu cầu đang treo đạt đến một số nào đó hoặc yêu cầu đã chờ 5 ngày thì một
đơn đạt hàng trong đó liệt kê các yêu cầu đang treo (tức là danh sách các đĩa
khách hàng yêu cầu mà không có trong kho) rồi gửi tới các nhà cung cấp.
Từ những điều mô tả này ta có DFD sau:

Hình 5.5. DFD trong bước tinh chỉnh thứ hai
Tuy nhiên DFD này cũng chưa phải là cái cuối cùng. Ví dụ, còn thiếu thông
tin về luồng dữ liệu biểu thị các đĩa được nhập từ các nhà cung cấp và cách thức
thanh toán
DFD đầy đủ của bài toán này có thể chiếm tới 6 trang giấy. Đây chỉ mới là
bài toán nhỏ. Đối với vấn đề lớn thì không thể biểu diễn trong một DFD.
Lúc đó, nhiều DFD được xây dựng và được sắp xếp theo kiểu phân tầng. Mỗi
nút tại một mức nào đó sẽ được phát triển thành một DFD đầy đủ ở mức thấp
hơn.

Bước 2. Quyết định sẽ tin học hóa phần nào trong các công việc nói trên, và
theo cách gì, xử lý theo bó hay tương tác? (batched processing or interactive
processing, nguyên bản là xử lý theo bó hay trực tuyến, online). Sau khi xác định
được phần cần tin học hóa thì trong 3 bước tiếp theo của kỹ thuật Gane và Sarsen
là tinh chỉnh từng bước các luồng dữ liệu, các thao tác và các kho dữ liệu.
Bước 3. Xác định chi tiết của các luồng dữ liệu.
119

Khách
hàng
Khách
hàng
Kiểm tra yêu
cầu
Kho đĩa CD
Yêu cầu
Hóa đơn
Thông tin về đĩa
Thông tin về tiền nợ
Danh sách khách hàng
Lập hóa đơn
Hóa đơn
Đĩa bán cho
khách hàng
Các yêu cầu còn treo
Đĩa yêu cầu
nhưng không có
Đặt hàng
nhà cung
cấp
Thông tin về đĩa
cần đặt hàng
Nhà cung
cấp
Nhà cung
cấp
Địa chỉ hoặc số
điẹn thoại

Trước hết xác định xem những mục dữ liệu nào có trong luồng dữ liệu. Trong
ví dụ trên đây thì một yêu cầu từ khách hàng có thể bao gồm:

Yêu cầu:
Định danh yêu cầu (order identification hay viết tắt là order ID)
Thông tin về khách hàng (họ tên, giới tính, địa chỉ )
Thông tin về các đĩa cần mua (tên đĩa, giá cả )
Tiếp theo là tinh chỉnh các mục dữ liệu. Đối với vấn đề lớn thì cần xây dựng
từ điển dữ liệu ghi lại các giải thích cần thiết của tất cả các thành phần dữ liệu.
Ví dụ như, order_ID là số nguyên 10 chữ số, là số không được lặp lại và
được tự động tạo ra bởi một thủ tục có tên là gen_order_ID chẳng hạn. Tất nhiên
là từ điển dữ liệu cần được trình bày theo dạng văn bản có cầu trúc, ví dụ theo
các cột: tên, mô tả, giải thích, Trong từ điển này ngoài tên các mục dữ liệu còn
có các hàm (thủ tục) nếu cần thiết. Ví dụ với luồng dữ liệu "yêu cầu" có thể có
thủ tục very_order_is_valid chẳng hạn, với đầu vào là các thông tin về yêu cầu
và đầu ra là có hợp lệ hay không.
Bước 4. Định nghĩa logic của các chức năng (các thao tác xử lý).
Sau khi các luồng dữ liệu đã được xác định, bước tiếp theo là định nghĩa các
chức năng xử lý chúng, tức là cần mô tả điều gì xảy ra trong các nút chức năng.
Giả sử hệ thống có một thao tác "giảm giá cho kỹ sư CNTT", lúc đó Hoa cần
cho người làm phần mềm biết thông tin về sự giảm giá, ví dụ nếu kỹ sư CNTT
mua trên 4 đĩa thì được giảm giá 15%, mua ít hơn được giảm 10%. Để tránh mô
tả bằng ngôn ngữ tự nhiên, ta có thể biểu diễn những điều này bằng cây quyết
định như sau:

Hình 5.6. Cây quyết định diễn tả sự giảm giá
Bước 5. Định nghĩa các kho dữ liệu.
120
Khác 0 %
Kỹ sư

CNTT
≤4 đĩa
10%
>5 đĩa
15%
Trong bước này cần xác định những dữ liệu được chứa trong mỗi kho dữ liệu
và khuôn dạng của chúng.
Bước 6. Định nghĩa các tài nguyên vật lý.
Trong phần này ta xác định cụ thể cách lưu trữ dữ liệu. Ví dụ, nếu ta sử dụng
hệ quản trị cơ sở dữ liệu để thao tác với dữ liệu như Foxpro, Access, thì ta phải
định nghĩa cấu trúc các bảng.
Bước 7. Xác định các đặc tả vào ra.
Xác định màn hình nhập liệu, các dạng biểu mẫu xem thông tin, các dạng báo
cáo cần in ra.
Bước 8. Xác định kích cỡ.
Phần này cần tích toán kích cỡ các tệp dữ liệu, tính thường xuyên của thao tác
nhập dữ liệu: hàng ngày hay hàng giờ, thời gian in ấn các báo cáo định kỳ
Bước 9. Xác định các yêu cầu phần cứng.
Trên cơ sở tính toán ở bước 8, xác định các yêu cầu phần cứng: cần CPU như
thế nào, tốc độ bao nhiêu, RAM bao nhiêu MB, ổ cứng có dung lượng bao nhiêu,
cần máy in màu hay in đen trắng
Tóm lại kỹ thuật đặc tả của Gane và Sarsen gồm 9 bước như sau:
(1) Xây dựng biểu đồ luồng dữ liệu.
(2) Xác định phần nào của DFD sẽ được tin học hóa.
(3) Xác định chi tiết của các luồng dữ liệu.
(4) Định nghĩa logic của các chức năng.
(5) Định nghĩa các kho dữ liệu.
(6) Định nghĩa các nguồn tài nguyên vật lý.
(7) Xác định các đặc tả vào ra.
(8) Xác định kích cỡ.

(9) Xác định các yêu cầu phần cứng.
Cho dù có nhiều ưu điểm, phương pháp trên đây không phải là đã hoàn hảo.
121
Vẫn còn nhiều vấn đề còn chưa có câu trả lời. Ví dụ: thời gian cần thiết để
đưa ra kết quả tính toán cho một yêu cầu nào đó, hay số kênh vào ra cần thiết
cho trường hợp tốt nhất,
Kỹ thuật này đã có tính hình thức hơn kỹ thuật đặc tả dùng ngôn ngữ tự nhiên
nhưng chưa phải là hình thức hoàn toàn. Kỹ thuật của Gane và Sarsen thuộc loại
nửa hình thức (semiformal technique).
Còn một số kỹ thuật bán hình thức tương tự như kỹ thuật trên đây. Có một vài
kỹ thuật hình thức hoàn toàn, như các máy trạng thái hữu hạn, lưới Petri,
nhưng để sử dụng những công cụ này đòi hỏi các kiến thức toán khá tốt, là điều
khó thực hiện đối với các kỹ sư phần mềm và đặc biệt là với các khách hàng.
3. Phân tích hệ thống về dữ liệu
SA là phương pháp phân tích dựa vào các hành động (chức năng). Vì các
hành động trong một hệ thống phần lớn là xử lý dữ liệu, do đó trong mô hình SA
thì dữ liệu cũng được thể hiện, nhưng chỉ đóng vai trò thứ yếu sau hành động mà
thôi. Đối với các hệ thống lớn, đặc biệt là các hệ thống thông tin quản lý, thì dữ
liệu thường rất lớn, và do đó việc tổ chức dữ liệu một cách hợp lý sẽ làm cho
tính hiệu quả của hệ thống tăng lên, ví dụ có thể cập nhật dữ liệu nhanh, truy
xuất thông tin, in ấn báo cáo nhanh và chính xác Trong nhiều trường hợp, bên
cạnh việc phân tích hệ thống về mặt chức năng, người ta còn tiến hành phân tích
về mặt dữ liệu (data-oriented analysis, DOA) và hai việc phân tích này được tiến
hành độc lập nhau, bởi vì người ta muốn tập trung nghiên cứu cấu trúc tĩnh của
dữ liệu (không phụ thuộc vào các xử lý, không phụ thuộc vào thời gian). Mục
đích của phân tích hệ thống về dữ liệu là lập lược đồ khái niệm về dữ liệu, làm
căn cứ cho việc thiết kế cơ sở dữ liệu của hệ thống sau này. Sở dĩ nó được gọi là
lược đồ khái niệm (để phân biệt với lược đồ vật lý), bởi vì khi thiết kế còn phải
chỉnh sửa ít nhiều mới phù hợp cho việc cài đặt trên máy tính.
Nói rằng việc phân tích hệ thống về mặt dữ liệu được tiến hành độc lập với

việc phân tích theo chức năng không có nghĩa là ta bỏ qua mối liên hệ tất yếu
giữa các xử lý và dữ liệu, mà ta chỉ tạm hoãn việc xem xét mối liên quan này cho
tới giai đoạn thiết kế, khi cần lập lược đồ vật lý của cơ sở dữ liệu.
Lược đồ khái niệm về dữ liệu được thành lập theo mô hình thực thể-liên kết
(entity-relationship modeling, ERM), rồi được hoàn chỉnh theo mô hình cơ sở dữ
liệu quan hệ (Relational Database Model, RDM). Trong mục này, chúng ta chỉ
xem xét sơ lược mô hình ERM cùng mô hình quan hệ được phát triển từ nó.
122
3.1. Thực thể (entity)
Theo từ điển tiếng Việt thì thực thể là cái có sự tồn tại độc lập. Như
vậy con người là thực thể, còn các thuộc tính như màu sắc không phải là thực
thể.
Trong mô hình tin học ta cũng dùng khái niệm thực thể để chỉ cái tồn tại
trong thế giới thực, nhưng có phần khái quát hơn một chút. Thực thể có thể là vật
nhìn thấy được và có thể tiếp xúc được bằng tay như con người, hạt cát, mặt
hàng; nhưng cũng có thể là khái niệm trừu tượng như dự án, kế hoạch
Thông thường khi xây dựng mô hình dữ liệu, các thực thể được biểu diễn
bằng những hình chữ nhật, ví dụ:
và một thực thể khi đó đại diện cho một lớp đối tượng trong thực tế, chứ không
chỉ một trường hợp cụ thể. Ví dụ thực thể "khách hàng" sẽ chỉ tập hợp các khách
hàng của một cửa hàng mà ta đang quan tâm khảo sát. Khi đó khách hàng cụ thể
có tên là "Trần Nguyên Đán", địa chỉ 14 Lò Sũ, Hà Nội là một thể hiện của thực
thể "khách hàng". (Cũng có tài liệu định nghĩa thực thể là đối tượng cụ thể, còn
kiểu thực thể, hay entity type, mới chỉ một lớp các đối tượng được mô tả bởi
cùng một số thuộc tính).
3.2. Thuộc tính (attribute)
Trong một hệ thông tin, ta cần lựa chọn một số tính chất đặc trưng để
diễn tả một thực thể, các tính chất này được gọi là các thuộc tính của thực thể.
Ví dụ:
Các thuộc tính: họ tên, địa chỉ, ngày sinh của thực thể "Sinhviên".

Các thuộc tính: tên, giá của thực thể "Mặt hàng".
Giá trị các thuộc tính của một thực thể cho phép diễn tả một trường hợp cụ
thể của thực thể và được gọi là thể hiện của thực thể đó.
Ví dụ.
Khách hàng
123