CHƯƠNG 1. TỔNG QUAN VỀ CÔNG
NGHỆ PHẦN MỀM
1.1. ĐÔI ĐIỀU VỀ VẤN ĐỀ THUẬT NGỮ
Theo tiếng Anh thì công nghệ là technology, còn phần mềm là software. Như vậy công nghệ
phần mềm phải chăng theo tiếng Anh là “software technology”? Tuy nhiên thực tế lại không phải
vậy. Trong tiếng Anh không có thuật ngữ “software technology” trong các từ điển tin học hay
bách khoa toàn thư, mà chỉ có thuật ngữ “software engineering”. Từ “engineering” có nghĩa là
“kỹ nghệ”. Cũng chính vì vậy mà trong một số tài liệu có một số tác giả dùng thuật ngữ “kỹ nghệ
phần mềm”. Ở Việt nam người ta quen dùng từ "công nghệ" hơn. Do đó phần lớn các trường vẫn
gọi môn học “software engineering” là “công nghệ phần mềm”. Ở đây chúng tôi cũng dùng thuật
ngữ này trên tinh thần như vậy.
Ngày nay kho kiến thức của loài người ngày càng được mở rộng, nhiều ngành khoa học đã áp
dụng các thành tựu của nhau và do đó ranh giới giữa chúng không còn rõ ràng như trước đây.
Việc định nghĩa chính xác các khái niệm cũng trở nên khó khăn và khó nhất quán. Cùng một
khái niệm, cùng một thuật ngữ nhưng trong một hoàn cảnh nhất định lại được hiểu khác đi. Lấy
ví dụ ngay trong lĩnh vực tin học: thuật ngữ "hệ thống" (system) có khi được hiểu là một tập hợp
các chương trình giải quyết một vấn đề nào đó, ví dụ operating system hay management
information system; nhưng có khi bao hàm cả các chương trình và thiết bị phần cứng, ví dụ
computer system hay the flight control system Chính Stephen R. Schach, tác giả cuốn "Object-
Oriented and Classical Software Engineering" cũng phải thốt lên rằng, tác giả đã quá mệt khi
phải đánh vật với cối xay gió (tác giả ám chỉ việc sử dụng thuật ngữ) và mong các bạn đọc thông
cảm.
Trong bối cảnh đó, các định nghĩa chúng tôi nêu ra sau đây chỉ nhằm mục đích cung cấp cho các
bạn một sự hình dung về các khái niệm. Như vậy các bạn chỉ cần hiểu, và có thể diễn đạt lại theo
cách suy nghĩ của mình, chứ không cần học thuộc từng chữ các khái niệm này. Có một số khái
niệm các bạn có thể chưa hiểu ngay khi đọc lần đầu. Trong trường hợp này các bạn cứ tạm chấp
nhận rồi tìm hiểu sau.
1.2. CÁC ĐỊNH NGHĨA VÀ THUẬT NGỮ
1.2.1. Một số khái niệm chung
Khoa học (science) là hệ thống các tri thức do con người khám phá ra. Khoa học tập trung
vào việc tìm hiểu và rút ra các quy luật thực tế (của tự nhiên và của con người). Các quy luật này
chương trình quản lý tín dụng
Trong công nghệ phần mềm, người ta hiểu phần mềm không chỉ là các chương trình, dữ liệu,
mà còn gồm cả các tài liệu liên quan như các bản đặc tả, thiết kế, hướng dẫn sử dụng.
Chương trình (program): đôi khi người ta gọi phần mềm là chương trình. Hay chính xác hơn,
người ta thường gọi phần được cài đặt trên máy tính để chạy là chương trình. Với cách hiểu như
vậy thì phần mềm = chương trình + tài liệu. Tuy nhiên, trong thực tế có khi người ta đồng nhất
hai khái niệm này. Ví dụ người ta nói rằng "phần mềm được cài đặt trên máy tính khách hàng".
Kỹ nghệ phần mềm (software engineering) là cách làm phần mềm tuân theo những nguyên tắc
tương tự như các nguyên tắc của kỹ nghệ truyền thống (ví dụ kỹ nghệ xây dựng cầu, kỹ nghệ làm
đường, )
Như chúng tôi đã nói tới ở trên, do thói quen, chúng ta dùng từ công nghệ phần mềm thay cho
từ được dịch đúng nghĩa hơn là kỹ nghệ phần mềm.
Vòng đời phần mềm (software life-cycle) là các bước mà một phần mềm phải trải qua, bắt đầu
từ khảo sát nhu cầu khách hàng cho đến khi phần mềm không còn được sử dụng.
Phát triển phần mềm (software developement) quá trình xây dựng phần mềm từ bắt đầu cho
đến khi chuyển giao cho khách hàng.
Người phát triển (software developer) là tên gọi chung cho những người tham gia xây dựng
phần mềm.
Nhóm đảm bảo chất lượng phần mềm (software quality assurance group = SQA group) nhóm
chuyên kiểm tra chất lượng phần mềm, kiểm tra kết quả của từng giai đoạn xây dựng phần mềm.
Quy trình phần mềm (software process) là cách thức làm ra phần mềm, bao gồm vòng đời phần
mềm, các công cụ và những người phát triển phần mềm.
Pha (phase) là một giai đoạn trong quá trình xây dựng phần mềm. Ví dụ pha xác định yêu cầu,
pha phân tích
Yêu cầu (requirements) là pha đầu tiên trong quá trình xây dựng phần mềm. Pha này thường có
tên gọi là tìm hiểu khái niệm (concept exploration). Người phát triển và khách hàng ngồi lại với
nhau. Khách hàng nêu ra những yêu cầu mà phần mềm phải có. Những người phát triển ghi chép
lại. Nếu dịch theo tiếng Anh "requirements phase" là pha yêu cầu. Tuy nhiên cách gọi quá đơn
giản như thế này có thể hơi khó hiểu, do đó ta sẽ gọi là pha xác định yêu cầu.
Đặc tả (specification) hoặc phân tích (analysis): Trên cơ sở những yêu cầu của khách hàng,
hiểu hơn cả. Khi ta nói "quy trình làm sổ đỏ" có lẽ dễ hiểu hơn là nói "tiến trình làm sổ đỏ".
Một số từ khác, ví dụ "implementation" có hai nghĩa như nhau là thực hiện, thi hành. Và vì thế
trong quy trình làm phần mềm thì việc dịch thuật ngữ "implementation phase" là "pha thực hiện"
có thể coi là cách dịch duy nhất. Tuy nhiên từ "thực hiện" lại được dùng ở rất nhiều nơi với ý
nghĩa khác, chứ không hẳn là viết chương trình. Vì vậy nếu nói "pha thực hiện" thì đối với người
chưa quen với tin học nghe rất khó hiểu. Làm sao họ có thể hiểu được "thực hiện phần mềm" lại
là viết chương trình? Vì vậy có tác giả dùng từ "cài đặt" để thay thế, và dịch "implementation
phase" là pha cài đặt. Bản thân tôi cũng ủng hộ cách dịch này, vì ở Việt nam vẫn quen dùng từ
"cài đặt" để chỉ việc viết chương trình, ví dụ: cài đặt thuật toán Euclid bằng ngôn ngữ Pascal.
Tuy nhiên từ "cài đặt" vẫn có thể nhầm với nghĩa của từ "installation" hay "setup", tức là cài đặt
(chứ không phải viết chương trình) một phần mềm lên máy tính để phần mềm này có thể chạy
được. Có lẽ chúng ta đành chấp nhận từ "cài đặt" có hai nghĩa vậy: một nghĩa tương ứng với từ
"setup" trong tiếng Anh, còn một nghĩa là "writing code", tức là viết chương trình. Như vậy nếu
các bạn gặp các thuật ngữ: lập trình, cài đặt, thực hiện, viết mã, viết code, mã hóa, thì thực ra
chúng chỉ là một mà thôi. Có thể nói rằng tin học là lĩnh vực đang phát triển nên ngay ở Mỹ việc
dùng thuật ngữ cũng không có sự thống nhất. Lấy ví dụ ngay trong mô hình vòng đời phần mềm,
thì có người gọi pha "đặc tả" là pha "phân tích", hay gộp hai pha "yêu cầu" và pha "phân tích"
thành pha phân tích hệ thống. Cách dịch sát ý nhiều khi làm cho câu khó hiểu. Ví dụ như chúng
tôi đã nói đến trong phần trước, nếu dịch "requirements phase" là pha yêu cầu thì khó hiểu hơn là
dịch thoát ý: pha xác định yêu cầu. Như vậy, khi sử dụng các tài liệu tiếng Anh chúng tôi sẽ áp
dụng cách dịch thoát ý nếu thấy cần thiết.
Khi đọc các tài liệu khác nhau, các bạn sẽ thấy những thuật ngữ được sử dụng không nhất quán.
Chúng tôi nghĩ rằng điều đó đối với các bạn không quá quan trọng để các bạn phải băn khoăn.
Các bạn hãy dùng một cách gọi nào đó mà các bạn thấy thích hợp, điều quan trọng là các bạn
phải nắm được ý nghĩa thực sự của nó.
1.3. PHẠM VI CỦA CÔNG NGHỆ PHẦN MỀM
1.3.1.Mở đầu
Mục tiêu của công nghệ phần mềm là sản xuất ra các phần mềm không có lỗi, được hoàn
thành đúng thời hạn với kinh phí cho phép và thỏa mãn yêu cầu khách hàng. Hơn nữa phần
mềm phải dễ sửa đổi khi người sử dụng cần.
công sức. Nhưng với người bác sĩ phẫu thuật thì anh ta phải suy nghĩ vô cùng cẩn thận khi đưa
lưỡi dao cắt đi một phần nào đó của cơ thể người, vì nếu anh ta sai sót thì hậu quả thật khôn
lường và đôi khi không thể sửa chữa được.
Ngày nay có những hệ phần mềm cần hàng trăm người làm trong nhiều năm như hệ phần mềm
dùng cho chương trình không gian của Mỹ. Thậm chí có những hệ cần đến hàng ngàn người
trong nhiều nước làm trong nhiều năm như chương trình điều khiển tổng đài điện thoại hiện được
bán khắp nơi trên thế giới. Khác với các sản phẩm khác, phần mềm không bao giờ giữ nguyên
mà không ngừng được thay đổi. Ví dụ như chương trình quản lý kết quả thi đại học chẳng hạn.
Có thể mỗi năm lại có một chính sách khác và phải sửa lại cho phù hợp. Chương trình quản lý
nhân sự của một cơ quan, chương trình quản lý du lịch, cũng vậy. Thường thì sau một thời
gian cài đặt và sử dụng, khách hàng lại có thêm một số yêu cầu và họ muốn phần mềm được sửa
lại theo yêu cầu đó. Nếu lúc đó họ phải tìm lại tác giả cũ thì thật là khó khăn. Điều này đặt ra
thêm một yêu cầu cho phần mềm: phần mềm phải được xây dựng sao cho các chuyên gia phần
mềm khác (mà không phải là tác giả) có thể hiểu và bảo trì được. Tóm lại, có thể nêu một vài lý
do khiến chúng ta phải nghiên cứu các cách thức xây dựng phần mềm một cách có khoa học là:
Ngày nay phần lớn phần mềm được xây dựng theo đơn đặt hàng. Như vậy cần có một
ngôn ngữ chung giữa người xây dựng phần mềm và khách hàng.
Phần mềm thường không do một người mà gồm rất nhiều người xây dựng. Những người
cùng phát triển một phần mềm phải hiểu rõ công việc của mình và công việc chung, mối
liên hệ giữa công việc của từng cá nhân hoặc từng nhóm. Cần có một cách thức diễn đạt
các công việc làm phần mềm sao cho mỗi kỹ sư phần mềm đều có thể trao đổi dễ dàng
các ý tưởng và công việc của mình với các kỹ sư trong nhóm làm việc.
Phần mềm cũng là một thứ hàng hóa như những thứ hàng hoá khác và do đó phải tuân
thủ nguyên tắc của kinh tế thị trường là sản phẩm phải độc lập với người sản xuất.
Nghĩa là sau khi mua hàng, người mua không bị lệ thuộc vào người bán. Muốn vậy thì
sản phẩm phần mềm ngoài chương trình chạy trên máy, cần có thêm các tài liệu sao cho
người khác có thể tìm hiểu và bảo trì được. Vậy thì cần một ngôn ngữ, một cách trình bày
chung cho các sản phẩm phần mềm.
1.3.2. Công nghệ phần mềm nhìn từ góc độ lịch sử
Máy tính điện tử đầu tiên cho mục đích thương mại là máy UNIVAC-1 được sản xuất năm 1951
cầu Internet. Đặc tả dự án được biết nhiều là hướng đối tượng, công cụ CASE (Computer
Aided Software Engineering). Trong thiết kế người ta chú ý đến môđun (module), đối tượng
(object), giao thức (protocol) và giao diện (interface). Giao thức hay giao diện nói về sự trao
đổi giữa các đối tượng. Khi cài đặt trên máy tính người ta thường dùng ngôn ngữ hướng đối
tượng. Ngoài các phần mềm được viết theo đặt hàng, người ta chú trọng đến các phần mềm
đóng gói như: Netscape, Internet Explorer, Word, Excel
Ngày nay phần mềm ngày càng lớn, càng tích hợp. Phần mềm ngày nay còn được truy cập ở
khắp nơi trên thế giới thông qua Internet.
Người ta cho rằng việc xây dựng một phần mềm cũng cần tuân theo những nguyên tắc và kỹ luật
giống như khi xây dựng một chiếc cầu hay thực hiện những công việc kỹ nghệ khác. Nếu một
chiếc cầu bị lỗi khi xây dựng và do đó bị sập thì tác hại gây ra rất lớn. Một phần mềm quan trọng
như phần mềm điều khiển hệ thống tên lửa đạn đạo của một nước mà có lỗi, cho kết quả tính
toán sai thì hậu quả nó gây ra cũng thật là kinh khủng. Chính vì vậy một nhóm nghiên cứu của
NATO trong năm 1967 đã sử dụng thuật ngữ "Software engineering". Họ muốn rằng khi xây
dựng phần mềm thì các kỹ sư cũng cần áp dụng các nguyên tắc của kỹ nghệ truyền thống.
Tuy nhiên, có nhiều sự khác biệt giữa sản phẩm của kỹ nghệ truyền thống và công nghệ phần
mềm. Ví dụ như chiếc cầu và hệ điều hành chẳng hạn. Sự cố cầu sập rất ít khi xảy ra và nếu xảy
ra thì cách khắc phục thường là xây dựng lại. Còn hệ điều hành nếu có sự cố có khi chỉ cần tắt
máy khởi động lại là lại chạy tốt. Phần mềm có thể sửa lại, có khi là tới 50% để có thể chạy trên
máy tính có cấu hình khác hoặc thực hiện thêm các chức năng khác. Còn chiếc cầu muốn sửa lại
50% thì rất khó, nhiều khi xây dựng mới còn dễ thực hiện hơn.
1.3.3. Từ góc độ kinh tế
Trong kỹ nghệ truyền thống, khi có nhiều cách thức để sản xuất một sản phẩm nào đó, ví dụ
chiết xuất dầu lửa từ than đá chẳng hạn, các kỹ sư thường chọn phương án rẻ nhất. Khi xây dựng
phần mềm cũng vậy, người ta thường lựa chọn cách thức chi phí ít nhất. Một phương pháp lập
trình mới có thể viết chương trình nhanh hơn, nhưng chi phí huấn luyện sử dụng và công bảo trì
có thể lớn hơn khiến người ta phải cân nhắc khi lựa chọn.
1.3.4. Về vấn đề bảo trì
Dãy các bước mà một phần mềm trải qua, bắt đầu từ những khảo sát ban đầu cho đến khi
phần mềm không còn được sử dụng được gọi là vòng đời của phần mềm (software life cycle).
Cũng có quan điểm cho rằng thực ra kiểm tra (verify) hoặc kiểm thử (test) là công việc cần được
thực hiện ở mọi nơi. Ví dụ với pha đặc tả, kiểm tra là xem xét đối chiếu xem tài liệu đặc tả đã mô
tả đầy đủ và chính xác các yêu cầu khách hàng hay chưa, còn kiểm thử chính là xem xét xem
từng điểm trong pha đặc tả đã được thể hiện trong các pha sau đó hay không. Vì vậy không nên
tách riêng kiểm thử thành một pha. Theo quan điểm của chúng tôi thì không nên gộp hai pha yêu
cầu và đặc tả. Với phần mềm lớn, nhiều người viết thì việc tích hợp là rất quan trọng và nên để
riêng thành một pha, còn với phần mềm vừa và nhỏ thì nên kết hợp cài đặt và tích hợp thành một
pha, trong đó bao hàm cả tích hợp, như trong bảng sau:
PM nhỏ
Yêu cầu
Đặc tả
Thiết
kế
Cài đặt và tích hợp
Bảo trì
Thôi sử dụng
PM lớn
Yêu cầu
Đặc tả
Thiết
kế
Cài đặt
Tích hợp
Bảo trì
Thôi sử dụng
Ý nghĩa của các pha:
1. Xác định yêu cầu: Tìm hiểu các yêu cầu của khách hàng, đưa ra các khái niệm và vấn đề.
2. Phân tích: Phân tích các yêu cầu của khách hàng. Mô tả các kết quả phân tích dưới dạng "tài
liệu đặc tả". Cuối giai đoạn này là kế hoạch quản lý dự án phần mềm được đưa ra, mô tả chi
tiết quá trình phát triển phần mềm. Câu hỏi mà pha này cần cho câu trả lời là: "phần mềm sẽ
"sản phẩm xấu" bị vứt vào sọt rác, còn "sản phẩm tốt" thì được hiệu chỉnh, nâng cấp và sử
dụng trong nhiều năm (tức là được bảo trì). Phần mềm là mô hình của thế giới thực, mà thế
giới thực thì biến đổi không ngừng, do đó phần mềm cũng phải được bảo trì thường xuyên để
phản ánh đúng thế giới thực. Trong thực tế công việc bảo trì chiếm một lương thời gian và chi
phí khá lớn so với các pha khác. Nếu ta gọi các pha 1-5 thành tên chung là các pha phát triển,
phần còn lại là pha bảo trì thì thực tế cho thấy rằng trung bình pha bảo trì thường chiếm
khoảng hai phần ba (67%) chi phí sản phẩm. Thậm chí có nhiều công ty phần chi phí cho bảo
trì có thể lên tới 80%. Tỷ lệ % thời gian thực hiện các pha phát triển có thể thấy trong bảng
sau:
Các pha
Các dự án từ 1976-1981
132 dự án gần đây của Hewlett-
Packard
Phân tích hệ thống
21
18
Thiết kế
18
19
Cài đặt
36
34
Tích hợp
24
29
Tổng
99
100
7. Thôi sử dụng.
1.3.5. Vấn đề phân tích và thiết kế
Kỹ thuật này bao gồm: phân tích hệ thống có cấu trúc (structured system analysis), phân tích
dòng dữ liệu (data flow analysis), lập trình cấu trúc (structured programming) và kiểm thử theo
cấu trúc (structured testing). Lúc mới ra đời, phương pháp cấu trúc tỏ ra có rất nhiều hứa hẹn và
cũng đã được áp dụng khá hiệu quả. Tuy nhiên, khi độ lớn của các phần mềm tăng lên thì
phương pháp này bộc lộ những nhược điểm. Theo thời gian, người ta rút ra 2 nguyên nhân hạn
chế khả năng của kỹ thuật này:
Thứ nhất, người ta nhận thấy rằng phong cách lập trình cấu trúc tỏ ra không phù hợp với những
phần mềm chứa khoảng trên 5000 dòng lệnh (tức là khoảng 100 trang). Các phần mềm ngày nay
có thể chứa đến 500 000 , thậm chí chứa đến 5 triệu dòng lệnh hoặc hơn.
Thứ hai, khi xây dựng phần mềm người ta dự kiến về trung bình thì kinh phí bảo trì chiếm
khoảng hai phần ba tổng kinh phí (66%). Tuy nhiên trong thực tế thì phương pháp cấu trúc đã
không làm được điều này. Rất nhiều công ty đã dùng đến 80% kinh phí cho công việc bảo trì.
Nguyên nhân làm cho lập trình cấu trúc chưa thật thành công là vì phương pháp này hoặc là định
hướng hành động (action oriented) hoặc là định hướng dữ liệu (data oriented), chứ không phải là
cả hai. Các thành phần cơ bản của một phần mềm chính là các hành động và dữ liệu mà các
hành động này tác động lên. Ví dụ việc xác định chiều cao trung bình bao gồm hai thao tác: thu
thập chiều cao (dữ liệu), và tính chiều cao trung bình. Một vài kỹ thuật cấu trúc, ví dụ phân tích
dòng dữ liệu (xem [6], mục 13.3), là định hướng thao tác. Nghĩa là kỹ thuật này chú ý hơn các
thao tác, dữ liệu chỉ là thứ yếu. Ngược lại, kỹ thuật khác như hệ thống Jackson (xem [6], mục
13.5) lại là định hướng dữ liệu. Ở đây sự nhấn mạnh lại là dữ liệu, còn thao tác là thứ yếu.
Phương pháp hướng đối tượng lại xem dữ liệu và hành động đều quan trọng như nhau.
Người ta xem đối tượng là một thành phần của phần mềm trong đó bao gồm dữ liệu và các
hành động thao tác trên dữ liệu này.
Tài khoản ngân hàng là một ví dụ về đối tượng. Dữ liệu của đối tượng là số dư tài khoản. Các
hành động tác động lên số dư tài khoản là việc gửi tiền, rút tiền và tính số dư.
Nhìn từ quan điểm phương pháp cấu trúc thì phần mềm giải quyết bài toán này bao gồm một
thành phần dữ liệu là số dư tài khoản và 3 hành động là gửi tiền, rút tiền và tính lại số dư.
Theo quan điểm hướng đối tượng thì tài khoản ngân hàng là một đối tượng bao gồm 3 thành
phần trên. Ta có thể biểu diễn các phương pháp này trong các hình sau đây:
số dư có thể bị thay đổi bởi một thao tác (hàm) khác. Trong phương pháp HĐT thì số dư chỉ có
thể chịu tác động của 3 thao tác của đối tượng. Bên ngoài nếu muốn biết thông tin về số dư thì
chỉ có thể gửi thông báo đến đối tượng (người ta nói gửi thông báo đến đối tượng có nghĩa là
chạy một hàm thành phần của đối tượng). Ví dụ nếu khách hàng gửi 10$ thì sẽ gửi thông báo và
kích hoạt hàm gửi tiền, và hàm gửi tiền sẽ tăng số dư lên 10 $.
Ích lợi của phương pháp HĐT còn thể hiện trong quá trình bảo trì phần mềm. Trở lại ví dụ trên
đây. Giả sử kiểu dữ liệu của số dư bị thay đổi do một lý do nào đó. Trong phương pháp cấu trúc
thì tất cả các phần của chương trình liên quan đến số dư đều phải sửa đổi. Ngược lại, trong
phương pháp HĐT thì số dư chỉ bị tác động bởi các hàm của chính đối tượng chứa nó, vì vậy chỉ
cần sửa đổi các hàm này.
Phương pháp HĐT được thiết kế tốt thì các đối tượng là những phần độc lập, ít phụ thuộc lẫn
nhau, và như vậy chúng có thể được xây dựng một cách độc lập và do đó dễ phân chia công
việc cho nhiều người thực hiện. Một phần mềm được xây dựng theo phương pháp cấu trúc thì
thường được coi là một đơn thể duy nhất (vì cho dù nó chứa nhiều thành phần nhưng các thành
phần lại phụ thuộc lẫn nhau), do đó phương pháp này không thích hợp cho phần mềm kích cỡ
lớn.
Cũng nhờ tính độc lập của các đối tượng mà khả năng sử dụng lại của phương pháp HĐT cao
hơn.
Nếu sử dụng phương pháp HĐT, vòng đời phần mềm sẽ được sửa đổi chút ít như trong hình sau:
Phương pháp cấu trúc
Phương pháp hướng đối tượng
1. Xác định yêu cầu
2. Phân tích (xác định phần mềm làm
gì?)
3. Thiết kế (thiết kế kiến trúc, tức là
phân chia phần mềm thành các
module, và thiết kế chi tiết, tức là
thiết kế chi tiết các module)
4. Cài đặt (viết chương trình)
5. Tích hợp
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.
2.2. KHÁCH HÀNG, NGƯỜI PHÁT TRIỂN VÀ NGƯỜI
SỬ DỤNG
(Client, developer, and user)
Khách hàng là cá nhân hoặc công ty có nhu cầu sử dụng phần mềm.
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.
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
gọi là kỹ thuật dùng bản mẫu.
Từ đây có lúc ta sẽ gọi đơn giản pha xác định yêu cầu là pha yêu cầu, đúng như thuật ngữ tiếng
Anh: requirements phase.
2.3.2. Kiểm thử pha 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 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 không.
2.3.3. Tài liệu báo cáo trong pha 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.
2.4. PHA ĐẶC TẢ (HAY PHÂN TÍCH)
2.4.1. Giới thiệu
Khi khách hàng cho rằng nhóm phát triển đã hiểu được các yêu cầu của họ thì công việc được
chuyển sang pha đặc tả. Nhóm đặc tả (hay phân tích) sẽ biên soạn tài liệu đặc tả. Những điều
được nêu trong tài liệu của pha yêu cầu sẽ được chi tiết và chính xác hóa. Các chức năng của
phần mềm được mô tả một cách rõ ràng, tường minh. Những điều kiện ràng buộc về phần mềm
được liệt kê đầy đủ. Tài liệu đặc tả còn chỉ rõ đầu vào (input) và đầu ra (output) của phần mềm.
Ví dụ, nếu yêu cầu của khách hàng là phần mềm tính bảng lương của một cơ quan thì đầu vào là
các mức lương của mỗi nhân viên, bảng ghi các ngày làm việc, các thông tin về thuế thu nhập
của từng người Đầu ra là bảng lương cùng với báo cáo về phần khấu trừ vào bảo hiểm xã hội,
bảo hiểm y tế Báo cáo đặc tả là cơ sở tạo ra bản hợp đồng. Hay nói chính xác hơn, báo cáo
đặc tả là những điều kiện của bản hợp đồng. Những người phát triển phần mềm sẽ được coi như
hoàn thành hợp đồng nếu sản phẩm thỏa mãn các tiêu chuẩn nêu ra trong bản đặc tả. Chính vì
vậy bản đặc tả không chứa những từ không có ý nghĩa chính xác như: nói chung, thích hợp,
Những thành phần chính của kế hoạch là: những phần sản phẩm chuyển giao cho khách
hàng, các mốc thời gian cần chuyển giao, chi phí của các phần sản phẩm này.
Bản kế hoạch mô tả tỉ mỉ quy trình phần mềm bao gồm: mô hình vòng đời phần mềm được sử
dụng, cơ cấu tổ chức của công ty phần mềm, những mục tiêu của dự án, các kỹ thuật và các
công cụ CASE được sử dụng, lịch trình làm việc chi tiết, chi phí
2.4.2. Kiểm thử pha đặc tả
Như đã nói dến trong chương 1, phần lớn các lỗi trong phần mềm chuyển giao cho khách hàng
thường do lỗi trong tài liệu đặc tả gây nên. Các lỗi này chỉ bị phát hiện khi phần mềm được cài
đặt trên máy tính của khách hàng. Vì vậy nhóm SQA cần phải kiểm tra tài liệu đặc tả một cách
kỹ lưỡng, nhận ra những điều mâu thuẫn, mơ hồ hoặc chưa đầy đủ. Ngoài ra, nhóm SQA còn
phải xem xét tính khả thi của đặc tả, ví dụ các phần cứng nói đến trong phần này thực sự có phù
hợp với việc cài đặt phần mềm không, dung lượng các bộ nhớ trên máy khách hàng có đủ để vận
hành phần mềm không. Tài liệu đặc tả phải có thể kiểm thử được, ví dụ có thể dựa vào tài liệu
này mà kiểm tra tiến độ công việc thực hiện, có thể so sánh với từng mục trong pha yêu cầu. Tài
liệu đặc tả cũng nên có các phần, các mục được đánh số tương ứng với tài liệu xác định yêu cầu
để tiện theo dõi. Nếu có bản mẫu trong pha yêu cầu thì trong tài liệu đặc tả cũng nên có các mục
tương ứng với các chức năng trong bản mẫu.
Cách tốt nhất để kiểm tra tài liệu đặc tả là xem xét. Đại diện của nhóm đặc tả và nhóm khách
hàng cùng ngồi lại dưới sự chủ tọa của thành viên nhóm SQA, xem xét kỹ lưỡng bản đặc tả, phát
hiện những sai sót, những điều chưa chính xác
Sau khi khách hàng đã vừa lòng với bản đặc tả thì chuyển sang xem xét bản kế hoạch thực hiện
dự án. Cũng như với bản đặc tả, cách tốt nhất để kiểm tra bản kế hoạch là xem xét. Hai yếu tố
cần chú ý là thời gian thực hiện và chi phí. Thường thì các ước lượng về thời gian và chi phí
được hai hoặc nhiều nhóm nghiên cứu độc lập nhau, sau đó cùng trao đổi để đưa ra kết luận
thống nhất.
2.4.3. Tài liệu báo cáo trong pha đặc tả
Tài liệu được biên soạn trong pha đặc tả bao gồm hai tài liệu: bản báo cáo đặc tả và bản kế
hoạch quản lý dự án phần mềm (SPMP).
2.5. PHA THIẾT KẾ
2.5.1. Giới thiệu
đã mang tính chuyên nghiệp và nếu khách hàng không phải là kỹ sư tin học thì sẽ rất khó hiểu.
Chính vì vậy khi kiểm tra bản thiết kế thì thường khách hàng không có mặt. Công việc xem xét
này được nhóm SQA thực hiện. Các lỗi thường được phát hiện trong pha này thường là: lỗi
logic, lỗi giao tiếp, thiếu phần xử lý các trường hợp ngoại lệ, và quan trọng nhất là không tương
hợp với báo cáo đặc tả. Ngoài ra nhóm SQA cần chú ý nhận ra những lỗi trong các pha trước
nhưng chưa được phát hiện.
2.5.3. Tài liệu báo cáo trong pha thiết kế
Sản phẩm chính trong pha này chính là bản thiết kế. Bản này gồm hai phần: kiến trúc và chi
tiết. Các bản thiết kế chi tiết sẽ được chuyển cho các lập trình viên để thực hiện công việc lập
trình.
2.6. PHA CÀI ĐẶT
2.6.1. Giới thiệu
Trong pha này các lập trình viên viết chương trình cho các module theo thiết kế chi tiết.
2.6.2. Kiểm thử pha cài đặt
Mỗi module cần kiểm thử trong khi thực hiện và sau khi hoàn thành (desk checking). Các
module được chạy thử với số liệu thử (test case). Ví dụ với module tính lãi suất thì ta thử nhập số
liệu là số tiền gửi, thời gian gửi, loại hình tiết kiệm rồi chạy thử để cho kết quả. Số liệu nên đơn
giản hoặc đã được tính toán trước bằng cách nào đó, sao cho ta có thể biết được chương trình cho
kết quả đúng hay sai. Công việc thử từng module này được người lập trình thực hiện. Sau đó
nhóm SQA sử dụng một số phương pháp đã có để thử lại các module.
Cùng với việc chạy thử các số liệu mẫu, việc xem xét các mã nguồn cũng là một cách kiểm thử
hiệu quả để tìm ra lỗi lập trình. Người lập trình sẽ giới thiệu các dòng lệnh, cách hoạt động của
các module. Nhóm xem xét mã nguồn cần có đại diện của nhóm SQA. Cũng giống như việc xem
xét báo cáo đặc tả hay thiết kế, hoạt động kiểm thử trong pha này của nhóm SQA cũng phải được
ghi chép lại.
2.6.3. Tài liệu báo cáo trong pha cài đặt
Tài liệu trong pha cài đặt chính là các mã nguồn của mỗi module cùng với các lời giải thích.
Các lập trình viên phải bổ sung bên cạnh mã nguồn những tài liệu khác để hỗ trợ cho việc bảo trì
sau này, ví dụ các số liệu và kết quả mẫu dùng để thử chương trình.
2.7. PHA TÍCH HỢP
gọi là phiên bản alpha. Sau khi khách hàng (được lựa chọn) kiểm thử và hiệu chỉnh thì phiên
bản alpha trở thành phiên bản beta. Phiên bản beta thường được coi là gần với phiên bản cuối
cùng.
Lỗi trong phần mềm đóng gói thường làm cho phần mềm không bán được và công ty phát triển
chịu thua lỗ lớn. Các phiên bản alpha và beta được gửi cho một số công ty được lựa chọn và sử
dụng vào công việc của họ với hy vọng trong quá trình sử dụng sẽ phát hiện ra các lỗi tiềm ẩn.
Các công ty thử các phiên bản alpha và beta thường được hứa là được cung cấp miễn phí phần
mềm thành phẩm. Tuy nhiên các công ty này cũng phải chịu sự rủi ro là rất có thể trong quá trình
sử dụng thì lỗi trong phần mềm làm cho họ tốn thời gian vô ích, các lỗi này có thể làm tổn hại
những công việc khác, ví dụ như cơ sở dữ liệu bị sụp chẳng hạn. Bù lại, đôi khi các công ty này
lại được hưởng lợi trong cạnh tranh do được sử dụng phần mềm mới, chưa ai có.
2.7.3. Tài liệu báo cáo trong pha tích hợp
Sản phẩm trong pha tích hợp là các mã nguồn đã được hiệu chỉnh cùng các lời chú thích. Kèm
theo đó là tài liệu hướng dẫn sử dụng, tài liệu hướng dẫn cài đặt và vận hành chương trình, giải
thích các cơ sở dữ liệu Tóm lại tất cả các tài liệu cần thiết cùng với phần mềm để chuyển giao
cho khách hàng.
2.8. PHA BẢO TRÌ
2.8.1. Giới thiệu
Nếu phần mềm được chấp nhận bởi khách hàng và cài đặt trên máy của họ thì từ lúc đó mọi
thay đổi về phần mềm đều được gọi là bảo trì. Bảo trì là một phần của quy trình phần mềm và
thường có chi phí lớn hơn tất cả các pha khác cộng lại. Một vấn đề quan trọng hay bị lãng quên
trong pha bảo trì là vấn đề cập nhật tài liệu. Mỗi khi có thay đổi về phần mềm trong pha bảo trì
thì đáng lẽ các tài liệu trong các pha trước đó đều phải sửa đổi. Tuy nhiên người ta thường không
làm điều này và tài liệu trong pha bảo trì thường chỉ có mã nguồn của phần mềm đã sửa đổi.
Trong nhiều trường hợp, thời gian bảo trì khá dài và có thể những người xây dựng nên phần
mềm không còn ở công ty nữa, và việc bảo trì càng trở nên khó khăn. Nói chung pha bảo trì là
pha trải qua nhiều thách thức nhất trong quá trình sản xuất phần mềm.
2.8.2. Kiểm thử pha bảo trì
Khi một phần của phần mềm bị sửa đổi thì dĩ nhiên ta phải tiến hành kiểm thử lại. Việc kiểm
thử ở đây bao gồm hai phần: thứ nhất cần kiểm tra xem phần mềm được sửa theo đúng yêu cầu
PHẦN MỀM
Như đã nêu trong chương 1, dãy các bước mà một phần mềm trải qua, bắt đầu từ những khảo sát
đầu tiên cho đến khi phần mềm không còn được sử dụng được gọi là vòng đời phần mềm. Vòng đời
phần mềm của mỗi sản phẩm nhiều khi có sự khác biệt rất lớn. Có phần mềm dùng một vài năm cho pha
khảo sát, tìm hiểu vấn đề. Những trường hợp như thế này thường xảy ra do chưa có phần cứng phù hợp
để xây dựng phần mềm, hoặc cần phải tiến hành khá nhiều nghiên cứu để tìm ra thuật toán hiệu quả. Có
sản phẩm được thiết kế và viết chương trình rất nhanh nhưng lại tốn hàng năm để bảo trì do phải sửa
đổi chương trình cho phù hợp với các yêu cầu của khách hàng. Cũng có những sản phẩm phần mềm sau
một thời gian sử dụng người ta nhận thấy rằng có lẽ nên viết hẳn một sản phẩm mới hoàn toàn thì sẽ tốt
hơn là bảo trì sản phẩm cũ. Cho đến nay có rất nhiều mô hình vòng đời phần mềm được sử dụng Tuy
nhiên ở đây chúng ta chỉ tìm hiểu một vài mô hình tiêu biểu xét cả về mặt nhược điểm và mặt ưu điểm.
3.1. MÔ HÌNH XÂY DỰNG-VÀ-HIỆU CHỈNH (BUILD-
AND-FIX MODEL)
Có khá nhiều phần mềm đã được xây dựng dựa trên mô hình xây dựng-và-hiệu chỉnh. Trong mô hình
này không có các pha phân tích thiết kế. Phần mềm được xây dựng như sau: người phát triển sau khi
trao đổi với khách hàng sẽ viết phiên bản đầu tiên. Tiếp theo, phần mềm được chạy thử với sự quan sát
của khách hàng và liên tục được hiệu chỉnh cho đến khi khách hàng vừa ý (tức là đáp ứng được yêu cầu
của khách hàng). Sau khi được khách hàng chấp nhận, phần mềm được đưa vào sử dụng và bảo trì. Mô
hình này có thể biểu diễn trong sơ đồ sau: Hình 3.1. Mô hình xây dựng-và-hiệu chỉnh
Vì sao cách thức này được nhiều người sử dụng để làm phần mềm, nhất là các phần mềm nhỏ? Nếu nói
chính xác hơn thì mô hình trên đây không có tài liệu phân tích, thiết kế. Vì thực ra khi viết chương trình
thì người phát triển cũng phải hình dung ra các chức năng của phần mềm, những module phải có, những
thuật toán sử dụng Nghĩa là phần nào đó họ cũng có phân tích thiết kế, nhưng họ không biên soạn lại
thành tài liệu mà thôi. Chắc các bạn cũng đã từng thấy những bác thợ mộc miệt mài làm việc, chẳng thấy
có bản vẽ thiết kế nào mà họ vẫn làm ra những chiếc tủ, chiếc giường rất đẹp. Dĩ nhiên là họ không làm
một cách vô thức mà theo một cách thức có sẵn trong trí nhớ của họ. Nếu phần mềm do một người viết
và dễ dàng trao đổi với khách hàng thì có lẽ mô hình xây dựng-và-hiệu chỉnh là cách nhanh nhất để đi tới
1970. Trong mô hình này, quá trình phát triển phần mềm được coi như một dòng chảy trải qua các pha
yêu cầu, phân tích, thiết kế, cài đặt, tích hợp và bảo trì. Thực ra, Royce có mô tả tính lặp của từng pha,
nghĩa là nếu trong một pha người ta phát hiện ra điều gì đó sai sót hoặc không phù hợp thì sẽ quay lại
hiệu chỉnh ở pha trước. Hình 3.2 là sơ đồ biểu diễn mô hình thác đổ. Hình 3.2. Mô hình thác đổ (waterfall model)
Mô hình thác đổ là mô hình cũ nhất và được sử dụng rộng rãi nhất trong công nghệ phần mềm. Tuy
nhiên cũng có nhiều ý kiến chỉ trích và cho rằng mô hình này có một số nhược điểm như sau:
Copyright: Tài liệu đại học ©