QUY TRÌNH LÀM CÔNG NGHỆ PHẦN MỀM - software engineering

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):

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ảivậ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ẫngọ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ậtngữ 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 đã ápdụ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ộtkhá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 khiphả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ôngcả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ácbạ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 theocá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áiniệ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ấpnhậ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 ột số khái niệm chung ố khái niệm chung ệ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àythườ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àiviế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 đượcchia 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 ưutheo 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ớicá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áiniệ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 ột số khái niệm chung ố khái niệm chung ệm chung ến công nghệ phần mềm ệm chung ần mề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ộttậ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ấthai 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ớinhau 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éplạ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àmcá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ảihiệ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ầnmề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 ấn đề dịch các thuật ngữ tiếng Anh ra tiếng Việt ềm ịch các thuật ngữ tiếng Anh ra tiếng Việt ật ngữ tiếng Anh ra tiếng Việt ữ tiếng Anh ra tiếng Việt ến công nghệ phần mềm ến công nghệ phần mềm ệm chung

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ườichư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ệcdù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ạnphả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 ở đầu ần mềm

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ụngtrong 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ạnbả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ềuchươ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 đángnó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à trongquá 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ôinhà 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ườithợ 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 thangnhư 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ảnthiế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ậnhay 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ênmá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ớikhá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ạnchươ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ộtbứ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 đưalưỡ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ônlườ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ềmdù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ườitrong 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 đượcbá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ờigian 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ửalạ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 rathê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ầnmề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ôn ngữ chung giữa người xây dựng phần mềm và khách hàng

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ốiliê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 đạtcá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àngcá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

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 chongườ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àychung 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 chung ần mềm ềm ừ góc độ lịch sử ột số khái niệm chung ịch các thuật ngữ tiếng Anh ra tiếng Việt ử

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áytí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ìnhphá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 đượcyê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ầnthự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ậtgiố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ộtchiế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ọngnhư 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ínhtoá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ầnmề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ắtmá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ại50% 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 ừ góc độ lịch sử ột số khái niệm chung ến công nghệ phần mềm

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ựngphầ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ậptrì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ì ềm ấn đề dịch các thuật ngữ tiếng Anh ra tiếng Việt ềm ả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ànthiệ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ỗihay 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ôngviệ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 độngsau 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 tacũ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 đượcthự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:

kế

kế

Ý 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ả chitiế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ỏicầ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 theproduct 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ì phatí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 đượchoà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íchnghi 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ànhhay 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ânchia 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 nghichiế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ờigian 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à chiphí 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ếmkhoả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ảotrì 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ảngsau:

Các pha Các dự án từ 1976-1981 132 dự án gần đây của Hewlett- Packard

1.3.5 V n đ phân tích và thi t k ấn đề dịch các thuật ngữ tiếng Anh ra tiếng Việt ềm ến công nghệ phần mềm ến công nghệ phần mềm

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ốncô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ẩmcò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ácpha 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ỗinhanh 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 ấn đề dịch các thuật ngữ tiếng Anh ra tiếng Việt ềm ật ngữ tiếng Anh ra tiếng Việt

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áytí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ờigian 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 đượclà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áttriể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ữacá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ànhcô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ườilà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ấtkhó 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 ng pháp h ướng đối tượng ng đ i t ố khái niệm chung ượng 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ạnchế 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áchà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ộtthà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ànhphầ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ántài khoản ngân hàng bằng (a) phương pháp cấutrú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ươngphá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úttiề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áonhư 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úcthì 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, trongphươ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ànhphầ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

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)

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ệcbả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ậnlợ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àngyê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 trongmộ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 ớng đối tượng ệm chung

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ácyê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áttriể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ạichứ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ảnphẩ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ànnà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ợpnà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 hayxả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ểnthườ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ầnmề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 đượcgọ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ếngAnh: requirements phase.

2.3.2 Ki m th pha yêu c u ểm thử pha yêu cầu ử ần mềm

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 đảmrằ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 đầuthự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ómcù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êucầ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 ệm chung ần mềm

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 ớng đối tượng ệm chung

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 đượcchuyể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ậpcủ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àocủ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áchhiể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ộtcô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 ểm thử pha yêu cầu ử ặc tả ảo trì

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ụctươ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áthiệ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 ệm chung ặc tả ảo trì

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 ớng đối tượng ệm chung

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ậpnhau 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ộttrườ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ở 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ờigian, 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à ítkhi 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

(open-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ầnmề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ềuthông tin bổ ích.

2.5.2 Ki m th pha thi t k ểm thử pha yêu cầu ử ến công nghệ phần mềm ến công nghệ phần mềm

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 ệm chung ến công nghệ phần mềm ến công nghệ phần mềm

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à chitiế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ậptrình

2.6 PHA CÀI ĐẶT

2.6.1 Gi i thi u ớng đối tượng ệm chung

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 thử pha yêu cầu ử ặc 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 đơngiả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ủacá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 xemxé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 đượcghi chép lại

2.6.3 Tài li u báo cáo trong pha cài đ t ệm chung ặc 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 ớng đối tượng ệm chung

Trong pha cài đặt thì từng module đã được kiểm thử Trong pha tích hợp các module sẽ đượckế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 thử pha yêu cầu ử ợng

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ìnhtí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àythì 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áchhà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ểnchị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ầnmề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ạinhữ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àylạ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 ệm chung ợng

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èmtheo đó 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ảithí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 giaocho khách hàng

2.8 PHA BẢO TRÌ

2.8.1 Gi i thi u ớng đối tượng ệm chung

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ọithay đổ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ônglà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ầnmề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ì ểm thử pha yêu cầu ử ả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ì ệm chung ả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ùngcá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ợpthử hồi quy cũng là một phần quan trọng trong tài liệu này

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ầnmề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óakhỏ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

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 AND-FIX MODEL)

(BUILD-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 sản phẩm Sau khi viết phiên bản đầu tiên, người phát

Xây dựng phiên bản

đầu tiên