Software process là gì

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

thường được phát biểu dưới dạng các định lý, các mệnh đề, các công thức toán học, các bài
viết ví dụ định luật vạn vật hấp dẫn, định lý Pitagor, quy luật giá trị thặng dư Khoa học được
chia thành các nghành như toán học, hóa học, sinh học, văn học, lịch sử,
Kỹ thuật [technique] là chỉ ra một cách thức tiến hành một công việc cụ thể nào đó. Cách làm
này thường có áp dụng kiến thức khoa học và được hệ thống thành các bước sao cho những
người khác cũng có thể học và làm theo. Ví dụ kỹ thuật hàn, kỹ thuật tân trang xe máy. Trong tin
học ta nói đến kỹ thuật phần mềm bao gồm kỹ thuật viết hệ điều hành, kỹ thuật làm chương trình
điều khiển. Ta cũng hay nói kỹ thuật lập trình tức là cách thức viết chương trình sao cho tối ưu
theo một nghĩa nào đó.
Công nghệ [technology] nói tới cách thức hay phương pháp để làm một việc gì đó, cụ thể hoặc
trừu tượng, có áp dụng các thành tựu của khoa học và được thực hiện một cách có bài bản, hệ
thống. Ta thường nói công nghệ sinh học, công nghệ jen, hay công nghệ giáo dục Như
thế, công nghệ có thể được hiểu là khái niệm rộng hơn khái niệm kỹ thuật. Kỹ thuật nói tới
cách thực hiện chi tiết, còn công nghệ thì nhấn mạnh tính hệ thống, bài bản.
Kỹ nghệ [engineering] là việc sử dụng phối hợp các công nghệ cần thiết để tạo ra các sản phẩm.
Công nghiệp [industry] là khái niệm bao trùm cả một nghành lớn, trong đó bên cạnh yếu tố kỹ
nghệ còn có thêm các yếu tố khác như kinh tế, tài chính, tổ chức xã hội.
Câu sau đây cho chúng ta cách hình dung về mối liên quan của các khái niệm vừa nói [trừ khái
niệm khoa học]:
Trong ngành công nghiệp xe hơi, kỹ nghệ xe hơi cần đến các kỹ thuật đúc hàn của công
nghệ cơ khí, kỹ thuật làm lốp xe của công nghệ cao
1.2.2. Một số khái niệm liên quan đến công nghệ phần mềm
Phần cứng [hardware] là các thiết bị cấu kiện mang tính vật lý có thể tiếp xúc bằng tay được
như máy in, ổ đĩa, máy quét, các mạch tích hợp [IC].
Nghĩa đơn giản nhất của phần mềm [software] là các chương trình chứa các dòng lệnh chỉ thị
cho máy tính thực hiện một công việc nào đó. Tuy nhiên thường người ta hiểu phần mềm là một
tập hợp các chương trình và cả dữ liệu phục vụ cho một công việc được tin học hóa nào đó. Ví
dụ phần mềm quản lý các dịch vụ bay, phần mềm điều khiển lò phản ứng hạt nhân, phần mềm
điều khiển dịch vụ mobile phone Đôi khi người ta gọi phần mềm là chương trình, cho dù thực
tế thì phần mềm gồm nhiều chương trình và dữ liệu. Ví dụ: chương trình quản lý nhân sự,

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,

người phát triển mô tả lại chính xác hơn các yêu cầu mà phần mềm phải có. Cách mô tả này có
tính chuyên môn và đôi khi sử dụng các công cụ trợ giúp. Pha này trả lời câu hỏi "phần mềm làm
cái gì?"
Phân tích hệ thống [system analysis] người ta thường gộp hai pha yêu cầu và phân tích thành
một pha và gọi là pha phân tích hệ thống.
Thiết kế [design] là pha tiếp theo pha đặc tả. Căn cứ vào tài liệu đặc tả, pha này mô tả cách thức
mà phần mềm thực hiện các công việc cụ thể. Pha này trả lời câu hỏi "phần mềm làm như thế
nào?". Pha thiết kế thường có hai phần: thiết kế kiến trúc [architecture design] và thiết kế chi tiết
[detail design].
Cài đặt [implementation] hoặc mã hóa [coding] hay lập trình [programming]: viết chương trình
bằng một ngôn ngữ cụ thể nào đó.
Tích hợp [integration] kết nối các phần chương trình đã viết thành một phần mềm thống nhất và
chạy thử, hiệu chỉnh cho đến khi chạy tốt. Pha này đôi khi được gọi là kiểm thử hoặc kiểm
chứng hay đơn giản là thử.
Bảo trì [maintenance] hay đôi khi được gọi là hỗ trợ [trong tài liệu tiếng Việt]: Khi chương
trình đã được cài đặt trên máy của khách hàng vẫn có thể có lỗi phát sinh cần loại trừ hoặc phải
hiệu chỉnh lại phần mềm theo yêu cầu khách hàng.
Kế hoạch quản lý dự án phần mềm [software project management plan - SPMP] bản kế hoạch
được soạn thảo sau khi hoàn thành pha đặc tả, trong đó mô tả chi tiết kế hoạch xây dựng phần
mềm [có cả thời gian hoàn thành và giá cả].
Trong các phần sau chúng ta sẽ còn nêu lại các khái niệm này.
Như vậy các bạn có thể thấy, trong tin học các thuật ngữ không được sử dụng một cách chính
xác như toán học.
1.2.3. Vấn đề dịch các thuật ngữ tiếng Anh ra tiếng Việt
Phần lớn các thuật ngữ tin học đều có xuất xứ tiếng Anh, khi dịch sang tiếng Việt thường rất khó
dịch chính xác, vì một từ tiếng Anh tương ứng với rất nhiều từ tiếng Việt. Ví dụ từ "process" có
các nghĩa là xử lý, quá trình, quy trình, trong đó từ quá trình được sử dụng nhiều hơn. Tuy nhiên
khi dịch cụm từ "software process" sang tiếng Việt, nếu dịch là "quá trình phần mềm" sẽ nghe lạ
tai và khó hiểu. Có tác giả dịch là "tiến trình phần mềm" tuy có dễ nghe hơn nhưng vẫn hơi khó
hiểu. Theo chúng tôi có một số tác giả dịch là "quy trình phần mềm" có lẽ nghe xuôi tai và dễ

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.

Để đạt được điều này các kỹ sư phần mềm phải được trang bị các kỹ năng về kỹ thuật cũng như
về quản lý. Các kỹ năng này không chỉ thể hiện khi viết chương trình, mà phải được áp dụng
trong các pha xây dựng phần mềm, bắt đầu từ khảo sát yêu cầu khách hàng cho đến giai đoạn
bảo trì.
Có nhiều người đã từng viết những chương trình máy tính, thậm chí đã tham gia viết nhiều
chương trình ứng dụng trong thực tế mà chưa hề biết về "công nghệ phần mềm". Một điều đáng
nói là không phải vì thế mà chương trình của họ kém hiệu quả. Vậy thì "công nghệ phần mềm"
liệu có ích lợi gì, có thực sự cần thiết đối với những người phát triển phần mềm không?
Chúng ta hãy xem một ví dụ thực tế: giả sử bạn cần xây dựng một ngôi nhà. Nếu bạn là thợ xây
và ngôi nhà nhỏ thì bạn có thể xây mà không cần thiết kế trên giấy. Thực ra thì trước và trong
quá trình xây nhà, bạn cũng đã hình dung ra công việc mình cần làm, bạn đã tưởng tượng ra ngôi
nhà của mình, nghĩa là bạn cũng có thiết kế, nhưng không ghi ra trên giấy mà thôi. Nếu cũng là
ngôi nhà đó nhưng bạn lại nhờ một người khác thì sao? Rõ ràng bạn phải giải thích cho người đó
biết cần phải làm gì. Không ít trường hợp xẩy ra là cho dù bạn đã giải thích rất rõ, nhưng người
thợ vẫn làm không đúng ý bạn. Có thể buổi sáng bạn đã căn dặn người thợ phải xây cầu thang
như thế nào nhưng buổi chiều về bạn lại thấy một chiếc cầu thang khác hẳn điều bạn đã mô tả và
kết quả là phải phá đi để làm lại. Đó là việc "xây ngôi nhà nhỏ". Nếu công trình ta cần xây dựng
là cả một tòa nhà hay chiếc cầu bắc qua sông lớn thì không thể thiếu bản thiết kế chi tiết. Bản
thiết kế phải được thảo luận rất nhiều trước khi đi đến phương án cuối cùng. Bản thiết kế đó phải
rõ ràng sao cho người kỹ sư thi công và những nhười thợ phải hiểu được chính xác, không bị
nhầm lẫn. Đối với việc viết chương trình cũng vậy. Nếu là vấn đề nhỏ như tính định thức ma trận
hay tính xấp xỉ tích phân, bạn chỉ cần biết thuật toán rồi bắt tay vào viết những dòng lệnh trên
máy. Thậm chí đối với bài toán lớn hơn như quản lý bán hàng ở một cửa hàng nhỏ chẳng hạn,
với một phần mềm quản trị cơ sở dữ liệu có sẵn như foxpro, bạn chỉ cần trao đổi đôi điều với
khách hàng rồi có thể bắt tay vào vừa viết vừa hiệu chỉnh cho đến khi nhận được sản phẩm có
thể sử dụng được. Chương trình máy tính có một đặc điểm khác với các sản phẩm khác là có tính
"mềm" như tên gọi của nó: ta có thể hiệu chỉnh các dòng lệnh hoặc xóa đi viết lại từng đoạn
chương trình mà không tốn nhiều công sức và không ảnh hưởng đến kết quả cuối cùng. Trong
thực tế có những việc khiến chúng ta phải cân nhắc rất kỹ trước khi thực hiện. Nếu là xây một
bức tường ta có thể phá đi từng phần để xây lại, cho dù như thế có thể tốn một số vật liệu và

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

ở Mỹ. Từ khoảng những năm 1955 thì bắt đầu có các phần mềm, tức là các chương trình máy
tính. Cho đến nay, nếu lấy phương pháp và mức độ phức tạp làm căn cứ, thì có thể chia quá trình
phát triển phần mềm thành 3 giai đoạn: 1955 - 1970, 1971 - 1985, 1986 đến nay. Tất nhiên sự
phân chia này chỉ là tương đối mà thôi. Đặc điểm của từng giai đoạn là:
- 1955 - 1970: Tính toán và quản lý rời rạc, quản lý nhỏ. Đặc tả những yêu cầu của khách hàng
lúc đó còn dùng ngôn ngữ tự nhiên thông thường. Ví dụ các câu kiểu như: tôi muốn có tệp dữ
liệu chứa những thông tin về bán sản phầm như số hóa đơn, người bán, mặt hàng, Dữ liệu sẽ
được nhập từ bàn phím, có kiểm tra rồi mới đưa vào tệp. Hàng tháng tôi muốn lấy thông tin
về doanh thu, lãi, số hàng bán Thiết kế thời ấy không được soạn thảo ra giấy mà chỉ hình
thành trong tư duy của người lập trình. Người lập trình vừa viết chương trình vừa suy nghĩ về
cách tổ chức dữ liệu, cách sử dụng các thuật toán sao cho chương trình chạy tốt, đáp ứng được
yêu cầu của khách hàng. Chương trình hồi đó chỉ gồm khoảng trên dưới vài trăm dòng lệnh.
Phương pháp lập trình được sử dụng thời đó là lập trình tuyến tính, tức là cách viết chương
trình trong đó phần lớn các lệnh được đặt theo trình tự thực hiện của chúng, nghĩa là lệnh cần
thực hiện trước sẽ được viết trước, lệnh thực hiện sau được viết sau.
- 1971 - 1985: Lúc này đã có nhu cầu xây dựng các phần mềm thời gian thực [nghĩa là tính toán
và sử dụng ngay kết quả, ví dụ tính toán trong lò phản ứng hạt nhân phải có ngay kết quả để
điều khiển kịp thời]. Lúc này có nhu cầu xây dựng các mạng cục bộ và kết nối các cơ sở dữ
liệu. Đặc tả thời đó chú trọng vào đặc tả đầu vào đầu ra, dữ liệu và các luồng dữ liệu [data
flow]. Ví dụ những tệp dữ liệu lưu trữ những thông tin gì, trong quá trình xử lý thì dữ liệu
được tính toán và di chuyển ra sao. Đầu ra của tệp dữ liệu này sau khi xử lý lại có thể trở
thành đầu vào của tệp khác Thiết kế thời đó chú trọng tới cấu hình hệ thống [system
configuration]. Vấn đề cấu trúc đối với dữ liệu và giải thuật cũng được chú ý, vì vấn đề lớn
cần phải được mô tả có cấu trúc cho dễ hiểu. Các chương trình tiêu biểu thời đó có thể kể tới
hệ điều hành DOS, UNIX Lúc đó cũng đã có những cơ sở dữ liệu có thể truy cập từ xa. Do
nhu cầu thực tế, các ngôn ngữ lập trình ra đời giai đoạn này đã có khả năng hỗ trợ phương
pháp lập trình có cấu trúc, nghĩa là chương trình được phân chia thành các chương trình
con, mỗi chương trình con có tên và các chức năng xử lý riêng, có thể giao tiếp với các
chương trình con khác thông qua các đối số và kiểu trả về [nếu có].
- Từ 1986 đến nay: Đây là thời kỳ của máy vi tính PC, thời nối mạng tầm rộng, mạng toàn

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].

Cho đến những năm 70 của thế kỷ trước, việc sản xuất một phần mềm được coi là kết quả của
hai giai đoạn nối tiếp nhau: phát triển [developement] và bảo trì [maintenance]. Dần dần quan
điểm này trở nên không phù hợp. Ta có thể lấy một ví dụ đơn giản: phần mềm ngày nay có thể
được phát triển trong một vài năm. Trong khoảng thời gian đó có thể có những phần đã hoàn
thiện theo đúng thiết kế ban đầu nhưng khách hàng lại bổ sung những yêu cầu mới và phải thiết
kế lại, viết lại Công việc này có thể xem là bảo trì. Có quan điểm cho rằng công việc sửa lỗi
hay hiệu chỉnh những phần chương trình đã hoàn thiện theo thiết kế ban đầu thì nên coi là công
việc bảo trì. Tuy nhiên cho đến nay thường người ta vẫn coi công tác bảo trì là những hoạt động
sau khi phần mềm đã hoàn chỉnh và được cài đặt để sử dụng. Trong tài liệu này chủ yếu chúng ta
cũng hiểu từ "bảo trì" với nghĩa như vậy.
Trong những năm cuối của thập kỷ 70 của thế kỷ trước, phần lớn các công ty khi sản xuất các
phần mềm đã sử dụng mô hình vòng đời phần mềm mà ngày nay người ta gọi là mô hình thác
đổ [waterfall]. Mô hình này bao gồm 7 giai đoạn như sau:
1. Xác định yêu cầu [Requirements phase]
2. Phân tích hay còn gọi là đặc tả [Analysis or specification phase]
3. Thiết kế [Design phase]
4. Cài đặt [Implementation phase]
5. Tích hợp [Integration phase]
6. Bảo trì [Maintenance phase]
7. Thôi sử dụng [Retirement]
Trong thực tế có thể một vài pha được bỏ qua hoặc được thay thế bởi các pha khác. Ví dụ người
ta hợp nhất hai pha đầu tiên thành pha hệ thống. Người ta lại cho rằng việc tích hợp phải được
thực hiện trong quá trình cài đặt, cài đặt xong thì phải có một thời gian kiểm thử, và như thế mô
hình gồm các giai đoạn sau:
1. Phân tích hệ thống
2. Thiết kế [kiến trúc và chi tiết]
3. Cài đặt [và tích hợp]
4. Kiểm thử
5. Bảo trì
6. Thôi sử dụng

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ẽ
làm gì?" [What the product is supposed to do?].
3. Thiết kế: Pha thiết kế bao gồm hai giai đoạn nối tiếp nhau: thiết kế kiến trúc [architechtural
design] và thiết kế chi tiết [detailed design]. Thiết kế kiến trúc phân chia phần mềm thành các
thành phần gọi là module. Thiết kế chi tiết là thiết kế từng module một cách chi tiết. Câu hỏi
cần trả lời trong pha này là: phần mềm thực hiện các công việc như thế nào? [How the
product is to do it?].
4. Cài đặt: Từng thành phần khác nhau được lập trình và kiểm thử.
5. Tích hợp: Các thành phần của sản phẩm được kết hợp với nhau và kiểm thử tổng thể. Sau khi
những người phát triển đã kiểm thử và cho rằng tất cả các chức năng của phần mềm đã hoạt
động tốt thì đến lượt khách hàng kiểm thử. Sự kiểm thử của khách hàng được gọi là kiểm thử
chấp nhận [acceptance testing]. Khi sự kiểm thử của khách hàng kết thúc và khách hàng vừa

lòng với sản phẩm thì phần mềm được cài đặt trên máy của khách hàng. Trong thực tế thì pha
tích hợp được tiến hành song song với pha cài đặt. Khi mỗi thành phần của sản phẩm được
hoàn thành thì người ta tiến hành thử luôn.
6. Bảo trì: Sản phẩm được sử dụng để thực hiện các công việc đã đặt ra trước đó. Trong quá
trình này có thể xẩy ra những sự cố: đó có thể là các lỗi chương trình chưa được loại trừ hết,
hay kết quả không được như khách hàng mong đợi. Người ta phân chia công việc bảo trì
thành hai loại: bảo trì sửa lỗi [software repair] và bảo trì cập nhật [softwair update]. Trong
tiếng Anh bảo trì sửa lỗi còn được gọi là corrective maintenance, bảo trì cập nhật còn được
gọi là software enhancement.
Bảo trì sửa lỗi như tên gọi của nó, là sửa các lỗi có thể vẫn còn xuất hiện trong khi chạy
chương trình. Bảo trì cập nhật lại được chia làm hai loại: bảo trì hoàn thiện [perfective
maintenance] và bảo trì thích nghi [adaptive maintenance]. Bảo trì hoàn thiện là sửa đổi phần
mềm theo ý khách hàng để nâng cao hiệu quả. Bảo trì thích nghi là sửa đổi để phần mềm thích
nghi với môi trường mới, ví dụ sửa đổi công thức tính lương theo chính sách mới ban hành
hay hiệu chỉnh để chương trình phù hợp với phiên bản mới của ngôn ngữ lập trình [Sự phân
chia này cũng chỉ là tương đối mà thôi]. Người ta tính toán rằng bảo trì sửa chữa và thích nghi
chiếm thời gian gần bằng nhau và khoảng 20% mỗi loại, còn bảo trì hoàn thiện chiếm thời
gian khoảng gấp 3 lần mỗi loại bảo trì kia [khoảng 60%].
Người ta thường nghĩ rằng "sản phẩm xấu" mới phải bảo trì. Tuy nhiên thực tế thì ngược lại:
"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ế
Các chuyên gia phát triển phần mềm cũng là những người bình thường và do đó không thể
tránh được sai sót trong công việc. Như vậy trong phần mềm họ phát triển có thể chứa lỗi. Lỗi có
thể chứa trong mọi pha. Dễ thấy rằng lỗi trong pha trước cũng sẽ gây nên lỗi ở pha sau. Do đó
nếu phát hiện lỗi càng chậm thì chi phí sửa chữa càng lớn. Chi phí tốn kém nhất là khi phần mềm
đã được chuyển giao và cài đặt cho khách hàng. Lúc đó không những phần lệnh phải viết lại mà
có thể các báo cáo trước đó cũng phải sửa chữa. Sau khi phần mềm được sửa chữa thì lại tốn
công phân phối và cài đặt lại Trong các pha xác định yêu cầu, phân tích thiết kế thì sản phẩm
còn nằm trên giấy và việc sữa chữa thường chỉ cần đến tẩy và bút chì. Vì vậy nên thực hiện các
pha này thật kỹ sao cho có ít sai sót nhất. Người ta cũng đã sử dụng một số kỹ thuật tìm lỗi
nhanh trong các pha yêu cầu và pha phân tích.
1.3.6. Vấn đề lập trình theo nhóm
Ngày nay nhờ sự phát triển rất nhanh của kỹ thuật, các công ty đã có thể trang bị những máy
tính có cấu hình cao, có thể chạy được những chương trình lớn. Nhiều phần mềm trở thành quá
lớn và không thể viết được bởi một người. Ví dụ người ta cần có sản phẩm trong khoảng thời
gian một năm, nhưng nếu một người làm thì mất 15 năm, rõ ràng lúc này phần mềm phải được
làm bởi nhiều người. Tuy nhiên không giống như việc xây nhà hoặc đào kênh rạch, việc phát
triển phần mềm theo nhóm thường gặp khó khăn trong việc phân chia và kết hợp công việc giữa
các thành viên. Ví dụ A và B đồng thời viết code cho hàm p và q. Hàm p có lời gọi tới hàm q. Để
chương trình không báo lỗi, khi viết p A phải khai báo nguyên mẫu cho q. Nếu không có sự trao
đổi cẩn thận, có thể B xây dựng hàm q với các tham số không hoàn toàn giống với nguyên mẫu
mà A khai báo, ví dụ thứ tự các tham số khác chẳng hạn, khi đó việc kết hợp sẽ không thành
công. Thực tế chứng tỏ rằng không phải nhiều người làm là thời gian được giảm xuống tỷ lệ với
số người. Giả sử một phần mềm được làm trong một năm bởi một người. Khi đó nếu có 3 người

làm thì thời gian không phải là 4 tháng như ta nghĩ mà có thể là gần 1 năm và chất lượng có thể
kém hơn phần mềm do một người xây dựng. Vấn đề làm việc theo nhóm quả thực là vấn đề rất
khó và là một lĩnh vực mà công nghệ phần mềm cần nghiên cứu.
1.3.7. Phương pháp hướng đối tượng
Trước 1975 phần lớn các công ty phân mềm đều không sử dụng một kỹ thuật nào đặc biệt.
Thường thì mỗi công ty có cách làm phần mềm riêng. Từ 1975 - 1985 phương pháp cấu trúc
[structured paradigm] ra đời, đánh dấu một sự thay đổi đáng kể trong kỹ thuật làm phần mềm.
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:

[a] [b]
Hình 1.1.
So sánh
sự tính
toán tài
khoản
ngân
hàng
bằng [a]
phương
pháp cấu
trúc và [b] phương pháp hướng đối tượng.
Nhìn về hình thức thì ta chưa thấy rõ lắm sự khác biệt giữa phương pháp cấu trúc và phương
pháp hướng đối tượng. Sự khác biệt cơ bản được thể hiện trong cách thức đối tượng vận hành.
Trong phương pháp cấu trúc, số dư tài khoản được khai báo sao cho các hành động gửi tiền, rút
tiền, hay tính toán số dư có thể tác động lên nó. Đây là các thao tác bên ngoài, do đó số dư phải
được khai báo sao cho các hàm bên ngoài đều biết rõ các thông tin kiểu dữ liệu là gì; khai báo
như biến độc lập hay là một trường của một cấu trúc khác Như vậy ngoài 3 hành động trên đâ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
6. Bảo trì
7. Thôi sử dụng
1. Xác định yêu cầu
2. Phân tích hướng đối tượng [xác định phần
mềm làm gì, phần mềm gồm các đối tượng
nào?]

3. Thiết kế hướng đối tượng [thiết kế chi tiết
các đối tượng]
4. Lập trình hướng đối tượng
5. Tích hợp
6. Bảo trì
7. Thôi sử dụng
Trong phương pháp cấu trúc, pha phân tích trả lời câu hỏi: "phần mềm làm gì?" , còn pha thiết kế
trả lời câu hỏi: "làm như thế nào?". Pha thiết kế gồm hai pha con: thiết kế kiến trúc [phần mềm
được chia thành các module như thế nào?] và thiết kế chi tiết [mỗi module được thiết kế như thế
nào?]
Với phương pháp HĐT, trong pha phân tích thì ngoài việc xác định phần mềm sẽ làm những gì
[như phương pháp cấu trúc] còn phải xác định các đối tượng trong phần mềm; như vậy trong pha
thiết kế không phải xác định các đối tượng nữa, mà chỉ cần thiết kế chi tiết các đối tượng.
Như vậy trong phương pháp HĐT các bước chuyển tiếp từ pha này sang pha khác mịn hơn, và
do đó giảm được các lỗi trong quá trình phát triển.
CHƯƠNG 2. QUY TRÌNH LÀM PHẦN
MỀM
2.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.
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
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.
2.3. PHA XÁC ĐỊNH YÊU CẦU
2.3.1. Giới thiệu
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.
Những khảo sát ban đầu về nhu cầu khách hàng được gọi là tìm hiểu vấn đề [concept
exploration]. Các buổi gặp tiếp theo sẽ bàn kỹ hơn về các chức năng của phần mềm, các vấn đề
kỹ thuật liên quan và kinh phí.
Thường thì mọi việc trong pha xác định yêu cầu có vẻ như được thực hiện suôn sẻ. Khách hàng
và người phát triển hiểu nhau, công việc được chuyển qua pha tiếp theo. Tuy nhiên thực tế lại
chứng tỏ rằng, thường thì pha xác định yêu cầu không được thành công lắm. Sau này khi sản
phẩm được cài đặt và đưa vào sử dụng, khách hàng bỗng đến gặp những người phát triển và phàn
nàn rằng "quả tình là các anh đã làm đúng những gì tôi yêu cầu, nhưng bây giờ tôi mới nhận ra là
có lẽ phần mềm tôi cần lại không hẳn là cái mà các anh đã xây dựng". Trong những trường hợp
này, phần mềm lại phải sửa đổi, các tài liệu phải viết lại, Những tình huống trên đây rất hay
xảy ra trong các trường hợp khách hàng hiểu biết ít về máy tính. Lúc này người phát triển và
khách hàng thường bị "bất đồng ngôn ngữ". Để khắc phục tình trạng này, người phát triển
thường viết nhanh một phần mềm thực hiện những điều mà khách hàng yêu cầu. Trong phần
mềm này chưa cần giao diện đẹp, chưa cần kiểm tra nhập dữ liệu, cốt là để khách hàng có thể
dùng thử xem nó có thực hiện đúng những điều họ muốn không. Phiên bản thử nghiệm này được
gọi là bản mẫu nhanh [rapid prototype]. Phương pháp xác định yêu cầu sử dụng bản mẫu được
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,
tương đối, phong phú Tài liệu đặc tả phải được viết sao cho có thể sử dụng như là chứng cứ khi
có vấn đề cần đưa ra phân xử ở tòa án, ngay cả khi phần mềm được viết để sử dụng trong nội bộ
một cơ quan [và như vậy khả năng kiện tụng sẽ không xảy ra]. Tài liệu đặc tả đóng vai trò quan
trọng trong việc kiểm thử và bảo trì phần mềm. Ta có thể căn cứ vào tài liệu này để kiểm tra xem
phần mềm đã thỏa mãn các mục tiêu đặt ra chưa. Nếu nhu cầu khách hàng thay đổi thì phần nào
của tài liệu đặc tả cần thay đổi cho phù hợp
Các thiếu sót sau có thể xảy ra trong pha đặc tả:

- Một lỗi mà nhóm đặc tả thường vi phạm là diễn tả vấn đề không chính xác, đôi lúc có thể hiểu
nhiều nghĩa. Ví dụ: sắp xếp mảng A rồi chọn phần tử đầu tiên. Ở đây từ sắp xếp chưa cho cách
hiểu duy nhất, sắp tăng dần hay giảm dần?
- Tài liệu chưa đầy đủ: Ví dụ nếu dữ liệu có lỗi thì giải quyết như thế nào?
Sau khi tài liệu đặc tả được biên soạn xong thì tiếp theo là xây dựng kế hoạch chi tiết và ước
lượng thời gian hoàn thành và giá trị phần mềm. Khách hàng sẽ không chấp nhận dự án phần
mềm nếu chưa biết các thông tin là dự án sẽ kéo dài trong bao lâu và chi phí hết bao nhiêu. Các
vấn đề này rất khó. Nếu giá cả thấp thì công ty bị thiệt, cao thì có thể khách hàng lại chọn một
công ty khác chấp nhận giá rẻ hơn. Nếu thời gian ước lượng quá ngắn, không kịp hoàn thành thì
công ty phần mềm hoặc bị mất lòng tin đối với khách hàng, hoặc nếu khách hàng kiện thì có thể
bị phạt. Nếu thời hạn hoàn thành quá dài thì khách hàng có thể chọn đối tác khác làm nhanh hơn.
Ngoài việc ước lượng thời gian và giá cả, những người phát triển còn phải phân công nhân sự
một cách thích hợp cho từng giai đoạn. Ví dụ nhóm viết chương trình chưa thể bắt đầu khi các
tài liệu thiết kế chưa được nhóm SQA kiểm tra và chấp nhận. Nhóm thiết kế lại không thể bắt
đầu công việc nếu nhóm đặc tả chưa hoàn thành công việc của họ. Tóm lại, kế hoạch quản lý
dự án phần mềm [SPMP] cần được biên soạn kỹ lưỡng nhằm phản ánh các giai đoạn khác
nhau của quá trình phát triển phần mềm, những thành viên tham gia trong từng giai đoạn
và thời hạn cần hoàn thành.
Thời điểm sớm nhất để bắt đầu xây dựng SPMP là khi phần đặc tả kết thúc. Trước đó thì dự
án vẫn chưa định hình nên không thể viết kế hoạch được. Dĩ nhiên cũng có những phần của dự
án có thể lập kế hoạch sớm hơn, có thể ngay khi bắt đầu; tuy nhiên cho đến khi những người
phát triển xác định được là cần xây dựng cái gì thì họ không thể xem xét mọi khía cạnh của dự
án và xây dựng kế hoạch được.
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
Pha đặc tả cho chúng ta biết "phần mềm làm gì?", còn pha thiết kế lại trả lời câu hỏi "làm như
thế nào?" Với việc tìm hiểu nghiên cứu bản báo cáo đặc tả, nhóm thiết kế xác định cấu trúc bên
trong của phần mềm. Họ phân chia phần mềm thành các module, là những phần mã lệnh độc lập
nhau và có các giao tiếp phù hợp với các phần còn lại của phần mềm. [Đối tượng cũng là một
trường hợp đặc biệt của module]. Các giao tiếp của một module là các tham số vào và các tham
số ra của nó. Ví dụ nếu module là tính lãi suất tiết kiệm thì đầu vào là số tiền gửi, thời gian gửi,
loại tiết kiệm [không kỳ hạn, 3 tháng, 6 tháng hay 1 năm ] và đầu ra là số tiền lãi.

Sau khi kết thúc việc phân chia phần mềm thành các module [thiết kế kiến trúc], nhóm làm việc
bắt đầu công việc thiết kế chi tiết cho từng module. Với mỗi module cần chọn các thuật toán và
các cấu trúc dữ liệu thích hợp.
Trong quá trình phân chia phần mềm thành các module, nhóm làm việc cần ghi chép lại các
bước quyết định và lý do lựa chọn. Làm như vậy có hai điều lợi:
Thứ nhất, có thể đôi khi công việc đi đến chỗ bế tắc, người ta phải quay lại và sửa đổi một số
quyết định của các bước trước đó. Nếu có bản ghi chép đầy đủ thì việc quay lại này dễ dàng hơn.
Thứ hai, việc ghi chép đầy đủ sẽ rất tốt cho công tác bảo trì. Chúng ta biết rằng phần mềm
không bao giờ giữ nguyên mà thường hay bị sửa đổi. Một phần mềm tốt phải có tính mở [open-
ended], có nghĩa là ta có thể thêm vào, bớt đi hoặc thay đổi một số module mà không phải thay
đổi nhiều các phần còn lại. Tuy nhiên điều này trong thực tế rất khó thực hiện. Do sức ép về thời
gian, nhóm làm việc chủ yếu tập trung vào việc thiết kế phần mềm theo các yêu cầu hiện có mà ít
khi suy nghĩ đến việc mở rộng nâng cấp trong tương lai. Nhóm làm việc thường chọn sự thỏa
hiệp là thiết kế và ghi chép lại sao cho sau này khi cần nâng cấp phần mềm thì biết được cần thay
đổi module nào, sao cho sự sửa đổi càng ít càng tốt. Thậm chí ngay cả trong trường hợp phần
mềm phải thiết kế lại hoàn toàn thì bản thiết kế cũ với ghi chép đầy đủ cũng sẽ cung cấp nhiều
thông tin bổ ích.
2.5.2. Kiểm thử pha thiết kế
Như đã nhắc đến, một tính chất rất quan trọng của một sản phẩm [tài liệu báo cáo, phần mềm]
là tính theo dõi được [traceable]. Trong trường hợp thiết kế thì điều này có nghĩa là bản thiết kế
phải là sự nối tiếp của bản báo cáo đặc tả. Nhìn vào bản thiết kế ta phải biết được các phần
tương ứng với báo cáo đặc tả. Bản thiết kế cũng phải được xem xét kỹ, xem nó đã thực sự phù
hợp với báo cáo đặc tả chưa. Tuy nhiên, khác với báo cáo yêu cầu và báo cáo đặc tả, bản thiết kế
đã 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
2.7.1. Giới thiệu
Trong pha cài đặt thì từng module đã được kiểm thử. Trong pha tích hợp các module sẽ được
kết hợp thành phần mềm và chúng ta cần kiểm tra xem các chức năng của phần mềm có hoạt
động chính xác không. Thực tế chứng tỏ rằng nên tích hợp các module lúc có thể, chứ không
chờ đến lúc tất cả các module đều được xây dựng. Nghĩa là nên thực hiện pha cài đặt và tích hợp
song song với nhau.
2.7.2. Kiểm thử pha tích hợp

Mục đích kiểm thử ở đây là kiểm tra xem các module có được kết hợp một cách chính xác
để tạo nên phần mềm thưc hiện đúng những yêu cầu nêu trong báo cáo đặc tả hay không. Lúc
này cần chú ý đến phần giao tiếp giữa các module. Ví dụ các tham số thực tế và các tham số
hình thức phải cùng loại, chúng cùng là thực, nguyên hay chuỗi ký tự chẳng hạn. Tuy nhiên có
những ngôn ngữ lập trình lại không đòi hỏi khắt khe về kiểu dữ liệu.
Sau khi kiểm tra tích hợp và thấy rằng các module đã được ghép nối với nhau một cách chính
xác thì nhóm SQA chuyển sang kiểm thử phần mềm [product testing]. Các chức năng của phần
mềm được kiểm tra theo các ràng buộc được nêu trong báo cáo đặc tả. Ví dụ như chương trình
tính toán và cho kết quả có đủ nhanh không. Bởi vì mục tiêu của việc kiểm thử phần mềm là xác
định xem phần đặc tả có được thực hiện đúng không, vì vậy nên đưa ra nhiều trường hợp thử
[tức là các số liệu và kết quả mẫu] khi kết thúc phần đặc tả.
Không chỉ tính chính xác mà cả tính ổn định của chương trình cũng được kiểm thử. Người ta
thử xem chương trình xử lý như thế nào với một dữ liệu sai. Chương trình sẽ sụp đổ hay có cách
xử lý hợp lý hơn như thông báo và tạm ngừng chờ dữ liệu mới chẳng hạn. Nếu chương trình
được cài trên máy khách hàng cùng với một phần mềm khác thì có gây sự xung khắc không
Bước cuối của kiểm thử tích hợp là kiểm thử chấp nhận [acceptance testing]. Chương trình
được cài đặt trên máy khách hàng, chạy với cấu hình và số liệu thực. Cho dù nhóm phát triển đã
sử dụng những số liệu mẫu như thế nào thì thường vẫn có sự khác biệt rất lớn giữa số liệu mẫu
và số liệu thực tế. Phần mềm sẽ không được coi là thỏa mãn các đặc tả chừng nào chưa trải
qua kiểm thử chấp nhận.
Trong trường hợp phần mềm đóng gói thì không có khách hàng cụ thể. Với phần mềm loại này
thì sau khi nhóm phát triển xây dựng và kiểm thử xong, phần mềm sẽ được gửi cho một số khách
hàng được coi là những người sử dụng trong tương lai để họ dùng thử. Phần mềm gửi đi được
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
đặt ra chưa. Thứ hai là sau khi sửa đổi lại một phần của phần mềm thì phần còn lại có bị ảnh
hưởng không. Để thực hiện phép kiểm thử thứ hai này ta phải giữ lại tất cả các trường hợp thử
trước đây. Việc dùng các dữ liệu mẫu cũ để thử lại các chức năng không liên quan đến phần
chương trình vừa sửa đổi được gọi là phép thử lùi lại hay phép thử hồi quy [regression testing].
2.8.3. Tài liệu báo cáo trong pha bảo trì
Tài liệu quan trọng trong pha bảo trì là các ghi chép về các sửa đổi đã được thực hiện cùng
các lý do. Khi phần mềm bị sửa đổi thì cần thực hiện phép thử hồi quy. Do đó các trường hợp

thử hồi quy cũng là một phần quan trọng trong tài liệu này.
2.9. THÔI SỬ DỤNG
Sau nhiều năm sử dụng có thể phần mềm trở nên không cần thiết và không còn cần sự bảo trì
nữa. Các lý do có thể như sau:
1. Sự thay đổi do khách hàng đưa ra quá lớn. Tốt nhất là xây dựng một phần mềm khác thay
thế.
2. Sau nhiều lần thực hiện các sửa đổi trên thiết kế ban đầu làm cho các phần của phần mểm trở
nên quá phụ thuộc lẫn nhau [một cách tình cờ chứ không phải là do yêu cầu của phần mềm]
do đó mỗi lần thay đổi một module nhỏ cũng có thể làm ảnh hướng đến các chức năng của
toàn bộ phần mềm nên việc bảo trì trở nên quá khó khăn. Tốt nhất là đặt lại yêu cầu và thiết
kế mới từ đầu, tức là làm phần mềm mới.
3. Sau nhiều lần sửa đổi nhưng các tài liệu lại không cập nhật đầy đủ nên không kiểm soát được
các lỗi hồi quy. Tốt nhất là nên viết lại phần mềm.
4. Phần cứng đã bị thay đổi. Phần mềm không còn thích hợp nữa, tốt nhất là nên viết lại.
Trong các trường hợp trên đây, phần mềm cũ được thay bằng phần mềm mới và quy trình phần
mềm lại được bắt đầu. Sự kết thúc sử dụng thực sự thường ít xảy ra hơn nhưng không phải là cá
biệt. Nếu một phần mềm trở nên lỗi thời thì dĩ nhiên người ta không sử dụng chúng nữa và xóa
khỏi các máy tính của họ. Ví dụ ở Việt nam thì các phần mềm soạn thảo văn bản thế hệ cũ đã
được loại bỏ và thay thế các phần mềm hoàn toàn mới.
CHƯƠNG 3. CÁC MÔ HÌNH VÒNG ĐỜI
PHẦN MỀM
!"#$%
&'$$[]*%+,*-.vòng đời phần mềm/0]1
2 3%4$5%6$78./95:;<
$%=>;8/#1*'1? 5@:*
>?A6B&'$@>= C7/95
%4*'$';;'D8 .EFD%+
GD:*;2 $/9H5#%4%
1 %+,1 C8I5.J;'K%4D%JF
.D%4H/9' 58[D;]1*%+,L

MAN O=>;[D&>?P;B*>;B>/
3.1. MÔ HÌNH XÂY DỰNG-VÀ-HIỆU CHỈNH [BUILD-
AND-FIX MODEL]
95$*?A66 [D?A6Q;Q7O/L[D
không có các pha phân ch thiết kế/R*?A6% S1>% $
G;$%J;'&/L'T*E+;%6 %
2 $;.,*7O'$$;" UV@.@*
2 $W/X $*$8C* ;%+,;D/Y[
D5>>Z%[% S


\D]//Y[D?A6Q;Q7O
0D% @*1%+,>.8.
^_'5`?D[DA$[5.7Aa'$'/0D6 $
;'DD1>HD @?A6Q;7OHF.c/L
5sự khác biệt.$.c ^ 'F -$OC[
2 $i][D?A6Q;Q7OD NUB

$?A6/
*>2 [D>7g ED/9[;7D1.%+ .3;C
C/';" * ;%+,;;c]j7[;7
D$[5;8D.!/L'*%+,% 1 $'
`1;'DHUb ].7iB;7D.E1
$67D%J8$5$6%6*!/
9'#* .&Mt/t/mT;*]
yêu cầu phân ch,thiết kếcài đặtch hợp;bảo trì/L6 mT5[a.B2 "
b .' 1 7 D5% %5B$[:*D%J .E
7OM /\D]/v.%[>Z[DG/


\D ]/v/ Y[DGVr Ts T.W
Y[DG.[DH8;*%+,8[7/L
H5U$'O`;I[D5%F*>% S