Các thuật ngữ trong môn công nghệ phần mềm

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

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

Như đã nêu trong chương 1, dãy các bước mà một phần mềm trải qua, bắt đầu từ những khảo sát đầu tiên cho đến khi phần mềm không còn được sử dụng được gọi là vòng đời phần mềm. Vòng đời phần mềm của mỗi sản phẩm nhiều khi có sự khác biệt rất lớn. Có phần mềm dùng một vài năm cho pha khảo sát, tìm hiểu vấn đề. Những trường hợp như thế này thường xảy ra do chưa có phần cứng phù hợp để xây dựng phần mềm, hoặc cần phải tiến hành khá nhiều nghiên cứu để tìm ra thuật toán hiệu quả. Có sản phẩm được thiết kế và viết chương trình rất nhanh nhưng lại tốn hàng năm để bảo trì do phải sửa đổi chương trình cho phù hợp với các yêu cầu của khách hàng. Cũng có những sản phẩm phần mềm sau một thời gian sử dụng người ta nhận thấy rằng có lẽ nên viết hẳn một sản phẩm mới hoàn toàn thì sẽ tốt hơn là bảo trì sản phẩm cũ. Cho đến nay có rất nhiều mô hình vòng đời phần mềm được sử dụng Tuy nhiên ở đây chúng ta chỉ tìm hiểu một vài mô hình tiêu biểu xét cả về mặt nhược điểm và mặt ưu điểm.

3.1. MÔ HÌNH XÂY DỰNG-VÀ-HIỆU CHỈNH [BUILD-AND-FIX MODEL]

Có khá nhiều phần mềm đã được xây dựng dựa trên mô hình xây dựng-và-hiệu chỉnh. Trong mô hình này không có các pha phân tích thiết kế. Phần mềm được xây dựng như sau: người phát triển sau khi trao đổi với khách hàng sẽ viết phiên bản đầu tiên. Tiếp theo, phần mềm được chạy thử với sự quan sát của khách hàng và liên tục được hiệu chỉnh cho đến khi khách hàng vừa ý [tức là đáp ứng được yêu cầu của khách hàng]. Sau khi được khách hàng chấp nhận, phần mềm được đưa vào sử dụng và bảo trì. Mô hình này có thể biểu diễn trong sơ đồ sau:

	Xây dựng phiên bản đầu tiên

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 triển đã hiểu khá rõ yêu cầu của khách hàng, họ cũng hiểu rõ các dòng lệnh vừa viết. Vì vậy khi khách hàng nêu yêu cầu hiệu chỉnh phần mềm thì họ biết ngay cần phải hiệu chỉnh phần nào của chương trình. Công việc thường được thực hiện khá nhanh chóng và phần mềm sớm được hoàn thành và đưa vào sử dụng.

Về hình thức, cách làm phần mềm theo kiểu xây dựng-và hiệu chỉnh cũng giống như làm bản mẫu. Tuy nhiên có một sự khác biệt, là khi làm bản mẫu ta bỏ qua các yếu tố quan trọng khác mà chỉ tập trung mô tả các yêu cầu của khách hàng; còn trong mô hình xây dựng-và-hiệu chỉnh thì ta chú ý tới cả các đặc trưng này khi xây dựng phần mềm.

Nhược điểm của mô hình thể hiện rõ trong giai đoạn bảo trì. Công việc bảo trì thường là sửa lỗi và cập nhật. Nếu phần mềm vừa mới được đưa vào sử dụng và tác giả vẫn còn chịu trách nhiệm công việc này thì không có vấn đề gì lắm. Tuy nhiên nếu phần mềm đã được sử dụng sau một thời gian dài, khiến cho chính người viết chương trình cũng quên đi ý nghĩa các dòng lệnh; hoặc việc bảo trì lại do một người khác thực hiện thì sẽ rất khó khăn. Nếu bạn thử đọc chương trình nguồn của một tác giả khác mà không có tài liệu giải thích kèm theo thì bạn sẽ thấy rất khó hiểu. Đôi khi bạn tìm hiểu vấn đề rồi viết mới chương trình có lẽ còn đơn giản hơn là sửa lại chương trình của người khác.

Rõ ràng mô hình xây dựng-và-hiệu chỉnh chỉ thích nghi cho phần mềm nhỏ, một người viết và ít khả năng phải sửa đổi trong quá trình sử dụng. Ngày nay các phần mềm thường lớn, do nhiều người viết do đó cách thức này trở nên không thích hợp. Khi có nhu cầu làm phần mềm, ta cần lựa chọn mô hình vòng đời thích hợp [đôi khi ta nói đơn giản là mô hình]. Mô hình này phải được cả nhóm làm phần mềm nhất trí, sau đó công việc phát triển phần mềm mới thực sự được bắt đầu.

Cho đến đầu những năm 1980 mô hình được sử dụng rộng rãi nhất là mô hình thác đổ [waterfall] mà ta sẽ nghiên cứu sau đây.

3.2. MÔ HÌNH THÁC ĐỔ [WATERFALL MODEL]

Mô hình thác đổ là mô hình phát triển phần mềm được đưa ra lần đầu tiên bởi W.W. Royce vào năm 1970. Trong mô hình này, quá trình phát triển phần mềm được coi như một dòng chảy trải qua các pha yêu cầu, phân tích, thiết kế, cài đặt, tích hợp và bảo trì. Thực ra, Royce có mô tả tính lặp của từng pha, nghĩa là nếu trong một pha người ta phát hiện ra điều gì đó sai sót hoặc không phù hợp thì sẽ quay lại hiệu chỉnh ở pha trước. Hình 3.2 là sơ đồ biểu diễn mô hình thác đổ.

Hình 3.2. Mô hình thác đổ [waterfall model]

Mô hình thác đổ là mô hình cũ nhất và được sử dụng rộng rãi nhất trong công nghệ phần mềm. Tuy nhiên cũng có nhiều ý kiến chỉ trích và cho rằng mô hình này có một số nhược điểm như sau:

Các dự án trong thực tế hiếm khi tuân theo dòng chảy tuần tự mà mô hình đề nghị. Mặc dầu mô hình cho phép lặp, nhưng điều đó chỉ làm gián tiếp. Kết quả là những thay đổi có thể gây ra lẫn lộn khi nhóm phát triển làm việc.

Khách hàng thường khó phát biểu mọi yêu cầu một cách tường minh ngay từ đầu. Mô hình tuần tự tuyến tính đòi hỏi điều này và thường khó thích hợp với sự không chắc chắn tự nhiên tồn tại vào lúc đầu của nhiều dự án. Khách hàng phải kiên nhẫn chờ đợi, vì bản làm việc được của chương tình chỉ có được vào cuối của thời gian dự án. Một sai lầm ngớ ngẩn, nếu đến lúc có chương trình làm việc mới phát hiện ra, có thể là một thảm họa.

Với việc phân tích một số dự án hiện tại, Bradax thấy rằng bản chất tuyến tính của vòng đời cổ điển dẫn tới "các trạng thái tắc nghẽn", nghĩa là có một số thành viên của nhóm phát triển phải chờ đợi sự chuyển giao từ nhóm khác hoàn thành công việc ở pha trước. Trong thực tế, thời gian chờ đợi có thể vượt quá thời gian sản xuất. Trạng thái nghẽn có xu hướng xẩy ra vào thời gian đầu và cuối của quy trình phần mềm.

Tuy nhiên, mô hình vòng đời cổ điển có một vị trí quan trọng vì nó đưa ra một hình mẫu về các bước mà một phần mềm cần phải trải qua là: phân tích hệ thống, thiết kế, cài đặt, tích hợp và bảo trì. Nhiều mô hình sau này là cải tiến mô hình này, nhưng vẫn giữ lại những điểm cốt lõi.

3.3. MÔ HÌNH BẢN MẪU [RAPID PROTOTYPING MODEL]

Mô hình bản mẫu thực chất cũng là mô hình thác đổ, nhưng phần xác định yêu cầu được thay bằng bản mẫu. Mô hình này có thể biểu diễn bởi sơ đồ sau:

Hình 3.3. Mô hình bản mẫu [rapid prototyping model]

Cũng như mô hình thác đổ, các pha từ bản mẫu đến thiết kế đều có kiểm tra [verify], các pha cài đặt và tích hợp có kiểm thử [test].

Thông thường khách hàng đã xác định được một tập các mục tiêu tổng quát cho phần mềm, nhưng còn chưa nhận diện được đầu vào, đầu ra, những cái cần xử lý. Trong các trường hợp khác người phát triển có thể không chắc về tính hiệu quả của thuật toán, việc thích nghi hệ điều hành hay dạng màn hình giao diện cần có. Trong trường hợp này và nhiều trường hợp khác, cách làm bản mẫu có thể đưa ra cách tiếp cận tốt nhất.

Để làm bản mẫu, đầu tiên người ta thu thập yêu cầu khách hàng. Người phát triển và khách hàng cùng ngồi lại với nhau để xác định các mục tiêu tổng thể cho phần mềm, xác định xem yêu cầu nào đã rõ ràng, yêu cầu nào còn phải xác định thêm. Tiếp theo là việc "thiết kế nhanh". Thiết kế nhanh chỉ tập trung vào việc biểu diễn các khía cạnh của phần mềm thấy được đối với người dùng, ví dụ màn hình nhập dữ liệu, các chức năng tìm kiếm, truy xuất thông tin, các báo cáo. Người phát triển có thể kết hợp để thử nghiệm một thuật toán. Tuy nhiên mục đích chính là thể hiện được các yêu cầu của khách hàng trong phần mềm mà chưa để ý đến tính tối ưu, tốc độ, sự hợp lý... Thiết kế nhanh dẫn tới việc xây dựng một bản mẫu. Bản mẫu được giới thiệu với khách hàng và có thể để họ dùng thử và đánh giá, góp ý kiến. Trên cơ sở ý kiến khách, hàng người phát triển làm mịn dần bản mẫu cho đến khi khách hàng thấy vừa ý [chủ yếu là cái vào, cái ra, giao diện...]. Căn cứ vào bản mẫu người phát triển cũng hiểu rõ hơn yêu cầu khách hàng, những yêu cầu về cấu hình, về các thuật toán, cấu trúc dữ liệu, ngôn ngữ lập trình phù hợp...

Hình 3.4. Mô thức làm bản mẫu

Một câu hỏi đặt ra là: bản mẫu được hiệu chỉnh cho đến khi khách hàng vừa ý, vậy có nên sử dụng ngay bản mẫu này hoặc hoàn thiện thêm để thành bản chính chuyển giao cho khách hàng không?

Về vấn đề này Brook đã nêu câu trả lời như sau:

Trong hầu hết các dự án, hệ thống đầu tiên hiếm khi sử dụng được. Nó có thể là quá chậm, quá lớn, cồng kềnh trong sử dụng hay tất cả những nhược điểm này. Không có cách nào khác là bắt đầu lại, đau đớn nhưng tinh khôn hơn, và xây dựng lại một phiên bản trong đó những vấn đề này đã được giải quyết.

Một cách lý tưởng, bản mẫu chỉ được xem như một cơ chế để xác định các yêu cầu của phần mềm. Khách hàng thường không biết được chất lượng thực sự của bản mẫu. Họ không biết được rằng trong khi xô đẩy để cho bản mẫu thể hiện được những yêu cầu khách hàng thì người ta không để ý đến chất lượng tổng thể hay tính bảo trì lâu dài của phần mềm. Khi được thông báo lại là sản phẩm được xây dựng lại để nó đạt tới mức độ chất lượng cao thì khách hàng thường kêu trời và đòi hỏi rằng "phải ít sửa chữa". Cách tốt nhất là ngay từ đầu nên xác định với khách hàng là bản mẫu chỉ sử dụng để xác định đúng yêu cầu khách hàng mà thôi.

So sánh mô hình thác đổ và mô hình bản mẫu

Trong mô hình thác đổ, mục đích của pha xác định yêu cầu là làm sao nắm bắt được những yêu cầu của khách hàng. Tuy nhiên việc này thường gặp khó khăn do khách hàng đôi khi không diễn đạt được chính xác yêu cầu của mình và có thể người phát triển đôi khi hiểu sai ý của khách hàng. Việc sử dụng bản mẫu trong pha xác định yêu cầu sẽ khắc phục được phần nào tình trạng này. Khách hàng dễ kiểm tra lại các yêu cầu của mình qua việc chạy thử các chức năng của phần mềm bản mẫu. Thực chất thì mô hình bản mẫu cũng là mô hình thác đổ nhưng kỹ thuật khảo sát được sử dụng là bản mẫu. Việc sử dụng bản mẫu còn có điểm lợi là giúp các nhà phát triển có cơ hội áp dụng thử và đánh giá những công nghệ và kỹ thuật mới và có thể giảm thiểu những rủi ro khi sử dụng những công nghệ mới này.

3.4. MÔ HÌNH TĂNG DẦN [INCREMENTAL MODEL]

Phần mềm được xây dựng từng bước, cũng như xây một ngôi nhà vậy. Nếu như khi xây dựng ngôi nhà có lúc người ta phải phá đi xây lại một bức tường không vừa ý thì khi làm phần mềm chúng ta cũng có thể sửa đổi thậm chí bỏ đi những module chương trình không phù hợp...Một phần mềm ra đời, được đưa vào sử dụng. Trong quá trình sử dụng ngoài việc phát hiện và sửa chữa sai sót, người ta thấy cần nâng cấp chất lượng bằng cách cải tiến một vài thuật toán, thêm một số chức năng... Ví dụ như khi làm phần mềm soạn thảo văn bản chẳng hạn. Phiên bản đầu có thể chưa có chức năng kiểm tra chính tả, chưa có chức năng chèn hình ảnh...Người ta nâng cấp phiên bản này bằng cách bổ sung các chức năng này. Sau khi hoàn thành công việc này người ta lại thấy nên thêm chức năng vẽ đồ thị, thêm khả năng tính toán trong bảng. Mỗi lần nâng cấp như vậy người ta lại dựa trên nền tảng phần mềm đã có và xem xét sửa đổi lại tài liệu các pha.

Từ nhận xét rằng phần mềm có thể được xây dựng từng bước đã đưa đến việc ra đời một mô hình mới là mô hình tăng dần.

Trong mô hình tăng dần, người ta xem phần mềm bao gồm nhiều thành phần [build] tương đối độc lập nhau. Với hệ điều hành chẳng hạn, đó là thành phần scheduler, thành phần file management system,.. Mỗi thành phần như vậy được coi như một phần mềm nhỏ, được thiết kế, lập trình, kiểm thử và đưa cho khách hàng sử dụng theo mô hình thác đổ rồi kết hợp dần thành phần mềm hoàn chỉnh thỏa mãn tất cả các yêu cầu của khách hàng. Ban đầu người ta chưa chú ý đến toàn bộ các yêu cầu của phần mềm mà chỉ chú ý đến những nét đặc trưng nhất và xây dựng phiên bản đầu tiên của phần mềm bao gồm các đặc trưng này rồi đưa cho khách hàng sử dụng. Chương trình được hiệu chỉnh theo ý kiến phản hồi của khách hàng. Tiếp theo người ta lại xây dựng phần mềm thứ hai thỏa mãn các đặc trưng quan trọng thứ hai và lại đưa cho khách hàng sử dụng và có ý kiến. Phần mềm thứ hai này sau khi hiệu chỉnh lại được tích hợp vào phần mềm đầu tiên thành một phần mềm lớn hơn. Phần mềm tích hợp này lại được kiểm thử để bảo đảm việc ghép nối thành công và chương trình chạy tốt. Cứ như vậy, thay vì xây dựng phần mềm hoàn chỉnh, người ta xây dựng các phần mềm con rồi tích hợp dần cho tới khi đạt được sản phẩm mong muốn. Sơ đồ sau mô tả mô hình tăng dần.

Hình 3.5. Mô hình tăng dần [incremental model]

Nhận xét mô hình tăng dần

Với mô hình thác đổ hoặc bản mẫu, sản phẩm được chuyển giao cho khách hàng chính là phiên bản hoàn chỉnh thỏa mãn tất cả các yêu cầu của khách hàng và có thể sử dụng ngay. Thời gian hoàn thành phần mềm được quy định trong hợp đồng và có thể sớm hoặc muộn hơn. Với mô hình tăng dần thì phần mềm được chia ra nhiều phần [thường là từ 5 đến 25 phần]. Phần đầu tiên chứa đựng những đặc trưng quan trọng nhất được nhanh chóng xây dựng và chuyển giao cho khách hàng sử dụng. Thời gian hoàn thành phần đầu tiên này thường rất ngắn so với thời gian xây dựng toàn bộ phần mềm hoàn chỉnh. Như vậy khách hàng được sử dụng sản phẩm trong thời gian ngắn nhất và họ có thể được hưởng lợi từ việc sử dụng phần mềm. Khi mỗi phần sau được hoàn thành và được tích hợp thì họ được sử dụng ngay. Như vậy họ được làm quen từng bước với sản phẩm và sẽ ít bỡ ngỡ khi sản phẩm chứa đựng những công nghệ mới. Nhờ theo sát từng bước phát triển của phần mềm mà khách hàng có thể có những ý kiến xác đáng, giúp cho nhà phát triển đi đúng hướng và sản phẩm cuối cùng sẽ thỏa mãn được các yêu cầu đặt ra, thậm chí qua việc sử dụng một số phần đầu, khách hàng nhận thấy rằng không nên phát triển tiếp vì sẽ không mang lại lợi ích kinh tế.

Khó khăn trong việc sử dụng mô hình tăng dần chính là sự tích hợp phần mới phát triển với phần chương trình đã có. Thiết kế của mô hình này do vậy phải có tính mở và tính mềm dẻo để thích nghi với việc mở rộng dần. Ta có thể nhận thấy rằng, trong mô hình tăng dần không có sự khác biệt giữa sự phát triển phần mềm và bảo trì cập nhật [nâng cao]. Nếu vận dụng không hợp lý, mô hình này có thể suy thoái thành mô hình xây dựng-và-hiệu chỉnh. Sự điều khiển toàn bộ quy trình phát triển phần mềm có thể bị mất và sản phẩm nhận được thay vì có tính mở lại là nỗi kinh hoàng cho những người bảo trì. Để tránh được điều này, người phát triển ngay từ đầu phải có cách nhìn toàn cục về sản phẩm, phải đưa ra thiết kế tổng thể của sản phẩm và sự phân chia các thành phần để phát triển sau này cũng phải trên cơ sở thiết kế toàn cục đó. Như sơ đồ 3.5. chỉ ra, các pha yêu cầu, đặc tả và thiết kế kiến trúc phải được thực hiện trước khi các thành phần nhỏ hơn được bắt đầu xây dựng. Nếu không có những nhà chuyên môn trình độ cao thì sản phẩm phát triển theo mô hình này có thể trở thành sản phẩm kém chất lượng.

Khi nào nên sử dụng mô hình tăng dần?

Nếu phần mềm có thể phân chia thành những thành phần tương đối độc lập nhau thì có thể áp dụng mô hình này. Với những bài toán như xây dựng phần mềm quản lý dịch vụ bay ở các công ty hàng không, chương trình quản lý tín dụng ở ngân hàng chẳng hạn, tính liên kết giữa các thành phần khá cao nên không nên áp dụng mô hình này.

3.5. MÔ HÌNH TĂNG DẦN ĐỒNG THỜI [CONCURRENT INCREMENTAL MODEL]

Mô hình tăng dần đồng thời được công ty Fujitsu [Nhật] sử dụng để xây dựng phần mềm truyền thông cỡ lớn vào khoảng năm 1993. Sau này K. Beck chính xác hóa khái niệm này vào năm 1999 và đặt tên là "lập trình cực điểm" [extreme programming]. Tuy nhiên chúng ta sẽ gọi là mô hình tăng dần đồng thời cho dễ hình dung. Có thể tóm tắt mô hình này như sau:

Trước hết người ta tìm hiểu nhu cầu khách hàng rồi phân chia thành nhóm các đặc trưng tương ứng với từng phần của phần mềm cần xây dựng. Sau đó nhóm đặc tả tiến hành xây dựng đặc tả của phần thứ nhất, sau khi hoàn thành thì trao kết quả cho nhóm thiết kế thực hiện thiết kế, nhóm lại chuyển qua đặc tả thành phần thứ hai,... cứ như vậy các thành phần được xây dựng song song, và mỗi nhóm sử dụng các thông tin nhận được từ các thành phần trước đó.

Cách tiếp cận này thực sự đã gây ra rủi ro là các thành phần có thể không tương thích với nhau. Với mô hình tăng dần, khả năng rủi ro phần nào được giảm thiểu vì thiết kế kiến trúc được thực hiện trước khi phần mềm được chia nhỏ thành từng phần và được xây dựng.

Sơ đồ mô hình này như sau:

...

Hình 3.6. Mô hình tăng dần đồng thời [concurrent incremental model]

Đây là mô hình còn có nhiều tranh cãi. Thực chất là mô hình tăng dần, nhưng các phần được thực hiện đồng thời. Mô hình này có tính rủi ro cao hơn mô hình tăng dần thông thường. Bước đầu tiên nhóm phát triển phần mềm dựa vào ý kiến khách hàng để xác định các đặc trưng khác nhau của phần mềm. Với mỗi đặc trưng như vậy họ thông báo cho khách hàng là phải xây dựng trong bao lâu và giá cả bao nhiêu. Tiếp theo khách hàng lựa chọn những đặc trưng cho các phần cần xây dựng dựa trên phân tích giá cả và lợi nhuận [cost-benifit analysis], tức là phân tích dựa trên thời gian và giá cả nêu ra bởi nhóm phát triển và lợi nhuận dự tính của công ty họ. Mỗi phần được lựa chọn lại được chia thành từng phần nhỏ hơn, được gọi là các nhiệm vụ. Mỗi lập trình viên trước hết nêu ra các trường hợp để thử cho từng nhiệm vụ sau đó cùng làm việc với cộng sự của họ trước một màn hình [kiểu lập trình này được gọi là pair programming]. Lập trình viên hoàn thành nhiệm vụ được giao và chạy các trường hợp thử để bảo đảm phần chương trình họ viết đã chạy tốt. Phần chương trình này sau đó được tích hợp vào phiên bản hiện thời của phần mềm cần xây dựng. Trường hợp lý tưởng là cả phần lập trình và tích hợp cho một nhiệm vụ chỉ kéo dài trong vài giờ. Thường thì các cặp lập trình viên thực hiện các nhiệm vụ song song, như thế sự tích hợp sẽ được tiến hành một cách liên tiếp. Các trường hợp dùng để thử các nhiệm vụ được giữ lại cho các phép kiểm thử tích hợp sau này. Một số đặc trưng của lập trình cực điểm [XP] có phần nào hơi khác thường:

1. Máy tính của các nhóm lập trình cực điểm được đặt giữa phòng lớn, trong các phòng nhỏ có vách ngăn.

2. Đại diện của khách hàng luôn luôn làm việc cùng nhóm XP.

3. Không ai làm việc quá giờ trong hai tuần liên tục.

4. Không có phân công đặc biệt. Tất cả các thành viên của nhóm XP đều có thể tham gia phân tích, thiết kế, lập trình và kiểm thử.

5. Như sơ đồ đã chỉ ra, không có thiết kế tổng thể trước khi các phần được xây dựng. Thay vào đó, thiết kế sẽ được hiệu chỉnh khi sản phẩm được xây dựng. Thủ tục này được gọi là tái phân tích nhân tố [refactoring]. Khi một trường hợp thử không chạy tốt thì các lệnh sẽ được viết lại cho đến khi nhóm lập trình thấy rằng thiết kế là đơn giản, rõ ràng và mọi trường hợp thử đều chạy tốt.

Mô hình này đã được sử dụng hiệu quả cho một số phần mềm vừa và nhỏ,có dung lượng công việc từ 9 người-tháng cho đến 100 người-năm. Mô hình này thực sự có lợi khi yêu cầu của khách hàng không rõ ràng và hay thay đổi. Tuy nhiên mô hình này còn chưa được sử dụng rộng rãi và do đó cũng chưa có điều kiện để kiểm chứng lại kết luận trên đây.

3.6. MÔ HÌNH ĐỒNG BỘ-VÀ-ỔN ĐỊNH [SYNCHRONIZE-AND-STABILIZE MODEL]

Công ty Microsoft là công ty sản xuất phần mềm đóng gói lớn nhất thế giới. Hầu hết phần mềm của họ được xây dựng dựa trên một phiên bản của mô hình tăng dần có tên gọi là đồng bộ-và-ổn định hóa [synchronize-and-stabilize model]. Pha xác định yêu cầu được thực hiện bằng cách phỏng vấn rất nhiều khách hàng dự kiến và các đặc trưng của nhu cầu khách hàng được liệt kê theo thứ tự ưu tiên. Sau đó tài liệu đặc tả được soạn thảo. Tiếp theo, công việc được chia làm ba hoặc bốn phần. Phần thứ nhất chứa các đặc trưng quan trọng nhất, phần thứ hai chứa các đặc trưng quan trọng thứ nhì...Mỗi thành phần sẽ được xây dựng bởi một số nhóm nhỏ làm việc song song. Cuối mỗi ngày các nhóm đồng bộ hóa [synchrronize], tức là họ hợp lại những phần họ đã làm riêng biệt thành một thành phần thống nhất, kiểm tra, sửa lỗi và kiểm thử. Sự ổn định hóa [stabilize] được thực hiện ở giai đoạn cuối của mỗi phần. Trong giai đoạn này những lỗi còn sót lại được phát hiện, được sửa chữa và thành phần được đóng gói [frozen], tức là không thực hiện thay đổi nào đối với các đặc tả.

Các bước đồng bộ hóa được lặp lại bảo đảm rằng các thành phần khác nhau có thể được kết hợp và cùng làm việc tốt.Một điểm lợi của cách làm này là những người phát triển có thể sớm nhìn thấy sự hoạt động của phần mềm và có thể hiệu chỉnh các yêu cầu, có thể là ngay trong quá trình các thành phần được xây dựng. Mô hình này có thể áp dụng ngay cả trong trường hợp các đặc tả ban đầu không hoàn thiện.

3.7. MÔ HÌNH XOẮN ỐC [SPIRAL MODEL]

Mô hình xoắn ốc [do Boehm đề xuất năm 1988] là kết hợp các khía cạnh của các mô hình trên đây. Cụ thể hơn, mô hình xoắn ốc là sự kết hợp tính lặp của mô hình bản mẫu và tính hệ thống của mô hình thác đổ. Về bản chất, mô hình mô tả sự phát triển của phần mềm qua các giai đoạn tiến hoá, mỗi giai đoạn được coi như một mô hình thác đổ. Ban đầu người ta chưa định nghĩa hệ thống một cách chi tiết, mà chỉ chú ý đến những đặc trưng nổi bật nhất. Sau đó phần đặc trưng này được xây dựng và đưa cho khách hàng xem xét, có ý kiến [cũng không hẳn là sử dụng cho công việc như trong mô hình tăng dần]. Cùng những thông tin phản hồi từ khách hàng, người phát triển trở lại thực hiện các đặc trưng với mức độ chi tiết hơn. Bản chất mô hình xoắn ốc như tên gọi của nó, là bắt đầu từ những cái khái quát nhất rồi đi dần đến chi tiết. Trong quá trình đó có lập kế hoạch cho từng giai đoạn làm chi tiết hóa sản phẩm và phân tích rủi ro. Tài liệu này chẳng hạn, cũng được biên soạn theo cách thức "xoắn ốc": ban đầu nêu các khái niệm chung, về sau đi sâu dần vào các chi tiết.

Quá trình xây dựng phần mềm thường chứa đựng những rủi ro. Ví dụ người chủ chốt có thể xin nghỉ việc trước khi phần mềm được hoàn thành. Công ty chế tạo phần cứng mà phần mềm sẽ cài đặt bị phá sản. Sau khi chi phí hàng trăm nghìn đô la cho sự phát triển phần mềm bỗng có một bước thay đổi đột phá trong công nghệ làm cho phần mềm trở nên vô dụng, phải thiết kế lại hoàn toàn. Công ty có thể nghiên cứu và phát triển hệ quản trị cơ sở dữ liệu, nhưng trước khi sản phẩm được hoàn thành và đưa ra thị trường thì một công ty khác lại quảng cáo một hệ tương đương có giá rẻ hơn. Có thể công ty sử dụng mô hình tằng dần đồng thời, nhưng sau đó các thành phần không thể tích hợp được với nhau để được phần mềm như yêu cầu đặt ra... Nói tóm lại, các nhà phát triển phần mềm thường có thể gặp rất nhiều rủi ro và họ muốn giảm thiểu các khả năng rủi ro đến mức có thể.

Một trong những cách làm giảm thiểu khả năng rủi ro là sử dụng bản mẫu. Như ta đã thấy, sử dụng bản mẫu trong pha xác định yêu cầu là cách thức tuyệt với để ngăn ngừa khả năng sản xuất ra một phần mềm không thỏa mãn tất cả các yêu cầu của khách hàng. Trong các pha tiếp theo người ta cũng có thể xây dựng những bản mẫu thích hợp. Ví dụ, công ty điện thoại có thể vừa phát minh ra một thuật toán hiệu quả cho việc phân tuyến các cuộc gọi thông qua mạng diên rộng. Nếu phần mềm được xây dựng nhưng không làm việc được như mong muốn, thì công ty sẽ bị thiệt hại về kinh phí. Trong trường hợp này khách hàng có thể bực tức và chuyển sang lựa chọn một công ty khác. Tình trạng này có thể được loại trừ nếu ta xây dựng một bản mẫu chỉ dùng cho mục đích phân tuyến các cuộc gọi và được kiểm thử trên thiết bị mô phỏng. Bằng cách này hệ thống thật sẽ không bị ảnh hưởng, và giá của công lập trình chỉ là thuật toán phân tuyến. Sau khi thử nghiệm, công ty sẽ quyết định được là có nên áp dụng thuật toán mới cho toàn hệ thống của họ hay không.

Ý tưởng làm giảm thiểu rủi ro thông qua việc sử dụng các bản mẫu và một số công cụ khác dẫn đến một mô hình mới mang tên: mô hình xoắn ốc[ spiral model]. Cách đơn giản nhất để xem xét mô hình này chính là mô hình thác đổ trong đó mỗi pha [trừ pha bảo trì] được bổ sung phần phân tích rủi ro ở trước. Trước khi bắt đầu một pha nào đó người ta phân tích các khả năng rủi ro và cách thức giải quyết có thể. Nếu không có cách nào để giải quyết được các rủi ro quan trọng thì dự án sẽ kết thúc.

Bản mẫu có thể sử dụng một cách hiệu quả để thu thập thông tin về sự rủi ro. Ví dụ ràng buộc về thời gian có thể kiểm thử bằng cách xây dựng một bản mẫu và ước lượng thời gian hoàn thành sản phẩm thông qua thời gian xây dựng bản mẫu. Bản mẫu với số liệu hoặc thiết bị mô phỏng có thể kiểm tra tính thích hợp của một thuật toán mới...

Tuy nhiên cũng có những rủi ro không thể đánh giá được thông qua bản mẫu. Ví dụ như nếu một thành viên chủ chốt xin thôi việc trước khi sản phẩm hoàn thành thì liệu có thể thuê được người thay thế kịp thời hay không? Hoặc trình độ của các thành viên trong nhóm phát triển liệu có đáp ứng được việc phát triển phần mềm quy mô lớn hay không? Các thành viên công ty lâu nay vẫn thường xây dựng các phần mềm sử dụng trong gia đình, nay phải xây dựng phần mềm phức tạp sử dụng trong công sở thì có làm được không? Một lĩnh vực khác mà bản mẫu cũng không sử dụng được trong việc đánh giá rủi ro là những hứa hẹn về sự phát triển phần cứng. Phần mềm được phát triển có tính tới sự ra đời của các thiết bị mà các công ty phần cứng hứa hẹn, nhưng thực tế lại không xảy ra như vậy...

Mô hình xoắn ốc cung cấp cách thức làm phần mềm bằng cách đưa ra các phiên bản tăng dần. Sự tăng dần ở đây không phải là bổ sung thêm các thành phần mới như mô hình tăng dần, mà sự tăng ở đây là sự tiến hóa [evolution], tức là cũng các đặc trưng ấy nhưng được làm mịn hơn, chi tiết hơn. Phiên bản sau cùng chính là phần mềm hoàn chỉnh có thể chuyển giao cho khách hàng sử dụng.

Mô hình xoắn ốc được chia thành một số khuôn khổ hoạt động, cũng còn được gọi là vùng nhiệm vụ. Về cơ bản, có khoảng từ ba đến sáu vùng. Ví dụ bốn vùng như sau:

1. Xác định mục tiêu, các giải pháp khác nhau để đạt được mục tiêu, các ràng buộc.

2. Phân tích rủi ro và khả năng giải quyết [thường là xây dựng bản mẫu].

3. Phát triển và kiểm tra.

4. Lập kế hoạch cho pha tiếp theo.

Để biểu diễn sơ đồ cho mô hình xoắn ốc, người ta vẽ hai đường thẳng vuông góc cắt nhau chia mặt phẳng thành 4 vùng. Bốn vùng này tương ứng với 4 vùng công việc: nếu dịch chuyển theo chiều kim đồng hồ và bắt đầu từ góc phần tư phía trên bên trái ta có các vùng tương ứng là 1,2,3,4.

Coi giao điểm của hai đường thẳng là tâm, ta vẽ các đường xoắn ốc đi từ phía trong ra ngoài cũng theo chiều kim đồng hồ. Độ dài đường xoắn ốc sẽ biểu diễn giá tích lũy của phần mềm, Một vòng của đường xoắn ốc sẽ biễu diễn một pha. Nếu đi từ trong ra ngoài ở góc phần tư số 3 ta được mô hình thác đổ. Một pha bắt đầu từ góc phần tư phía trên bên trái [góc 1] bằng việc xác định các mục tiêu của pha, các giải pháp khác nhau để đạt được các mục tiêu này và các ràng buộc cho từng giải pháp. Kết quả của giai đoạn này là chọn được giải pháp thích hợp. Ở góc phần tư thứ hai là phân tích rủi ro cho giải pháp đã lựa chọn. Một vài biện pháp được đưa ra để khắc phục rủi ro. Biện pháp thường được sử dụng là bản mẫu. Nếu rủi ro lớn và không có biện pháp khắc phục thì dự án phải dừng lại. Trong một số trường hợp, dự án vẫn được tiếp tục nhưng với quy mô nhỏ hơn. Nếu vấn đề rủi ro được giải quyết thì chuyển sang góc phần tư thứ ba là phát triển. Ở góc cuối cùng là kế hoạch cho pha tiếp theo. Đường xoắn ốc sẽ được lặp lại chừng nào sản phẩm chưa đạt mức hoàn chỉnh.

Nhận xét mô hình xoắn ốc

Mô hình xoắn ốc là cách tiếp cận thực tế cho việc phát triển các phần mềm quy mô lớn. Bởi vì phần mềm được tiến hóa theo đường xoắn ốc, từ tổng quan cho đến chi tiết, nên người phát triển và khách hàng hiểu rõ hơn và có phản ứng thích hợp với rủi ro tại từng mức tiến hóa. Mô hình này dùng bản mẫu như một cơ chế làm giảm rủi ro. Bản mẫu còn giúp cho khách hàng nhìn rõ từng bước phát triển của phần mềm và có ý kiến góp ý kịp thời để những người phát triển đi đúng hướng, nhanh chóng đưa đến phần mềm hoàn thiện. Mô hình đòi hỏi xem xét trực tiếp các rủi ro kỹ thuật cũng như quản lý tại mọi giai đoạn của dự án, và nếu được áp dụng đúng thì có thể làm giảm rủi ro trước khi những rủi ro này trở thành vấn đề thực sự.

Tuy nhiên mô hình này không phải là sự lựa chọn tốt nhất cho mọi dự án.

- Trước hết, phân tích rủi ro sẽ tốn kém, do đó mô hình chỉ có thể áp dụng cho các dự án lớn, khi mà chi phí phân tích rủi ro là không đáng kể so với tổng chi phí toàn bộ dự án.

- Phân tích rủi ro được thực hiện trong suốt quá trình phát triển phần mềm. Tuy nhiên nếu là phần mềm ký hợp đồng mà bị dừng lại thì công ty phát triển sẽ bị phạt. Do đó với các dự án ký hợp đồng thì nhà phát triển và khách hàng phải phân tích rủi ro trước khi hợp đồng được ký, chứ không phải trên đường xoắn ốc như mô hình mô tả.

- Liệu các nhà phát triển đã nhìn thấy hết các rủi ro không? Có thể rủi ro vẫn còn nhưng họ lại chủ quan cho rằng đã hết và có thể mắc sai lầm. Như vậy mô hình này chỉ nên áp dụng nếu công ty phần mềm có một đội ngũ chuyên gia phân tích rủi ro trình độ cao.

Cuối cùng, chính bản thân mô hình xoắn ốc còn chưa được áp dụng rộng rãi như mô hình thác đổ hoặc mô hình bản mẫu. Cần có thêm thời gian để xác định tính hiệu quả mô hình này.

3.8. MÔ HÌNH HƯỚNG ĐỐI TƯỢNG [OBJECT-ORIENTED MODEL]

Theo kinh nghiệm thì trong phương pháp hướng đối tượng, tính lặp giữa các pha và giữa các phần trong một pha xẩy ra nhiều hơn so với phương pháp cấu trúc. Khi xây dựng mô hình hướng đối tượng người ta muốn chỉ rõ đặc trưng này. Một trong những mô hình như vậy là mô hình núi đồi được biểu diễn bằng các hình tròn có một phần chồng lên nhau. Mỗi vòng tròn chỉ một pha. Vòng tròn không rời nhau chỉ ra rằng các pha có phần chung nhau. Bên trong các vòng tròn có các mũi tên uốn cong ngụ ý nói rằng trong mỗi pha cũng có tính lặp giữa các phần.

Các pha có phần chung là:

- Pha yêu cầu và pha phân tích hướng đối tượng.

- Pha thiết kế hướng đối tượng, pha lập trình và tích hợp.

- Pha sử dụng và bảo trì.

CHƯƠNG 4. PHÂN TÍCH CHỨC NĂNG HỆ THỐNG

Xác định chức năng nghiệp vụ là bước đầu tiên của việc phân tích hệ thống. Để phân tích yêu cầu thông tin của tổ chức ta phải biết được tổ chức đó thực hiện những nhiệm vụ, chức năng gì. Từ đó, tìm ra các dữ liệu, các thông tin được sử dụng và tạo ra trong các chức năng. Đồng thời, cũng phải tìm ra những hạn chế, mối ràng buộc đặt lên các chức năng đó.

Hình 4.1. FHD của hệ thống “Quản lý trường phổ thông”

4.1.1. Định nghĩa mô hình phân rã chức năng

Mô hình phân rã chức năng [FHD – Function Hierarchy Diagram] là công cụ biểu diễn việc phân rã có thứ bậc đơn giản các công việc cần thực hiện. Mỗi công việc được chia ra làm các công việc con, số mức chia ra phụ thuộc kích cỡ và độ phức tạp của hệ thống [hình 4.1].

4.1.2. Các thành phần của mô hình phân rã chức năng

Khái niệm về chức năng trong hệ thống thông tin

Chức năng là công việc mà tổ chức cần làm và được phân theo nhiều mức từ tổng hợp đến chi tiết.

Cần chú ý cách đặt tên cho chức năng, tên chức năng phải là một mệnh đề động từ, gồm động từ và bổ ngữ. Động từ thể hiện hoạt động, bổ ngữ thường liên quan đến các thực thể dữ liệu trong miền nghiên cứu. Tên các chức năng phải phản ánh được các chức năng của thế giới thực chứ không chỉ dùng cho hệ thông tin. Tên của chức năng cần ngắn và giải thích đủ nghĩa của chức năng và phải sử dụng thuật ngữ nghiệp vụ.

Mỗi chức năng có một tên duy nhất, các chức năng khác nhau phải có tên khác nhau. Để xác định tên cho chức năng có thể bàn luận và nhất trí với người sử dụng.

C

Chức năng

hức năng được biểu diễn bằng một hình chữ nhật

Quan hệ phân cấp chức năng

Mỗi chức năng được phân rã thành các chức năng con. Các chức năng con có quan hệ phân cấp với chức năng cha. Biểu diễn mối quan hệ phân cấp chức năng như sau:

Mô hình phân rã chức năng được biểu diễn thành hình cây phân cấp. Ví dụ về mô hình phân rã chức năng của chức năng “QL hồ sơ” được biểu diễn trên hình 4.2.

Hình 4.2. Mô hình phân rã của chức năng “QL hồ sơ”

4.1.3. Đặc điểm và mục đích của mô hình phân rã chức năng

Đặc điểm

Mô hình phân rã chức năng có các đặc điểm sau:

• Cung cấp cách nhìn khái quát về chức năng

• Gần gũi với sơ đồ tổ chức

• Không đưa ra được mối liên quan về thông tin giữa các chức năng.

Mục đích

Mục đích của mô hình phân rã chức năng là:

• Xác định phạm vi của hệ thống cần phân tích

• Cho phép mô tả khái quát dần các chức năng của tổ chức một cách trực tiếp, khách quan, phát hiện được chức năng thiếu hoặc trùng lặp

• Tạo điều kiện thuận lợi khi hợp tác giữa nhà thiết kế và người sử dụng trong qua trình phát triển hệ thống.

4.1.4. Xây dựng mô hình phân rã chức năng

Nguyên tắc phân rã các chức năng

Trong quá trình tiếp cận một tổ chức theo phương pháp từ trên xuống [top- down] ta nhận được thông tin về các chức năng từ mức gộp [do lãnh đạo cung cấp] đến mức chi tiết [do các bộ phận chức năng cung cấp]. Cách phân rã này tương ứng với sự phân công các chức năng của mọi tổ chức với các nguyên tắc sau:

Mỗi chức năng được phân rã phải là một bộ phận thực sự tham gia thực hiện chức năng đã phân rã ra nó.

Việc thực hiện tất cả các chức năng ở mức dưới trực tiếp phải đảm bảo thực hiện được các chức năng ở mức trên đã phân rã ra chúng

Nguyên tắc này được sử dụng để phân rã một sơ đồ chức năng nhận được còn đang ở mức gộp. Quá trình phân rã xuống dưới được tiếp tục cho đến khi nhận được một mô hình với các chức năng ở mức cuối mà ta hoàn toàn nắm được nội dung thực hiện nó.

Cách tiến hành phân rã

Bước 1: Xác định chức năng

Trong hầu hết các hoàn cảnh, các chức năng cha và chức năng con trong hệ thống có thể được xác định một cách trực tiếp theo thông tin nhận được qua quá trình khảo sát. Các chức năng ở mức đỉnh thường là các lĩnh vực hoạt động chính của tổ chức.

Bước 2: Phân rã các chức năng

Khi phân rã các chức năng cần phân rã có thứ bậc và thực hiện việc phân rã chức năng theo các nguyên tắc phân rã.

Việc bố trí sắp xếp các chức năng phải thực hiện theo nguyên tắc sau:

• Không nên quá 6 mức đối với hệ thống lớn, không quá 3 mức đối với hệ thống nhỏ.

• Sắp xếp các công việc trên một mức cùng một hàng đảm bảo cân đối.

• Các chức năng con của cùng một chức năng cha nên có kích thước, độ phức tạp và tầm quan trọng xấp xỉ như nhau.

• Các chức năng mức thấp nhất nên mô tả được trong không quá nửa trang giấy, nó chỉ có một nhiệm vụ hoặc một nhóm nhiệm vụ nhỏ do từng cá nhân thực hiện.

Mô hình phân rã chức năng cho ta một cái nhìn chủ quan về hệ thống nên cần tạo ra mô hình tốt và đạt được sự thống nhất với người sử dụng.

Bước 3: Mô tả chi tiết chức năng mức lá

Đối với mỗi chức năng lá [mức thấp nhất] trong mô hình cần mô tả trình tự và cách thức tiến hành nó bằng lời và có thể sử dụng mô hình hay một hình thức nào khác. Mô tả thường bao gồm các nội dung sau:

• Các sự kiện kích hoạt [khi nào? cái gì dẫn đến? điều kiện gì?]

• Yêu cầu giao diện cần thể hiện [nếu có]

• Dữ liệu vào [các hồ sơ sử dụng ban đầu]

• Công thức [thuật toán] tính toán sử dụng [nếu có]

• Dữ liệu ra [các báo cáo hay kiểm tra cần đưa ra]

• Quy tắc nghiệp vụ cần tuân thủ

Ví dụ [Mô tả chức năng “Thôi việc”]: Cần kiểm tra người cho thôi việc có phải là giáo viên không. Nếu là giáo viên và đang tham gia giảng dạy thì phải phân công giáo viên khác dạy thay.

4.1.5. Các dạng mô hình phân rã chức năng

Mô hình phân rã chức năng nghiệp vụ có thể biểu diễn ở hai dạng: dạng chuẩn và dạng công ty. Việc sử dụng dạng FHD nào tuỳ thuộc vào chiến lược xử lý dữ liệu của công ty và tầm quan trọng, độ mềm dẻo của hệ thống.

Mô hình dạng chuẩn

Dạng chuẩn được sử dụng để mô tả các chức năng cho một lĩnh vực khảo sát [hay một hệ thống nhỏ].

Mô hình dạng chuẩn là mô hình cây: ở mức cao nhất chỉ gồm một chức năng, gọi là “chức năng gốc” hay “chức năng đỉnh”; những chức năng ở mức dưới cùng [thấp nhất] gọi là “chức năng lá”.

[a]

[b]

Hình 4.3. Các dạng FHD dạng công ty và dạng chuẩn

[a] Dạng chuẩn; [b] Dạng công ty.

Mô hình dạng công ty

Dạng công ty được sử dụng để mô tả tổng thể toàn bộ chức năng của một tổ chức có qui mô lớn. Ở dạng công ty, mô hình thường gồm ít nhất hai mô hình trở lên. Một “mô hình gộp” mô tả toàn bộ hệ thống với các chức năng mức cha [từ hai đến ba mức]. Các mô hình còn lại các các “mô hình chi tiết” dạng chuẩn để chi tiết hóa mỗi chức năng lá của mô hình gộp. Nó tương ứng với các chức năng mà mỗi bộ phận của tổ chức thực hiện.

Ví dụ về mô hình gộp và mô hình chuẩn của hệ thống “quản lý trường phổ thông” được thể hiện trên hình 4.3.

Với cách tiếp cận dạng công ty cần phân tích toàn bộ tổ chức để xác định tất cả các chức năng nghiệp vụ mức cao nhất. Bất cứ dự án nào đang được phát triển đều là một phần của một trong những chức năng mức cao này.

4.2. MÔ HÌNH LUỒNG DỮ LIỆU

4.2.1. Mục đích của mô hình luồng dữ liệu

Mô hình luồng dữ liệu nhằm mục đích:

• Bổ sung khiếm khuyết của mô hình phân rã chức năng bằng việc bổ sung các luồng thông tin nghiệp vụ vào/ra của các chức năng.

• Cung cấp một cái nhìn đầy đủ hơn về các mặt hoạt động của hệ thống

• Là một trong số các đầu vào cho quá trình thiết kế hệ thống.

4.2.2. Định nghĩa mô hình luồng dữ liệu

Mô hình luồng dữ liệu [DFD - Data Flow Diagram] là một công cụ mô tả mối quan hệ thông tin giữa các công việc . Hình 4.4 thể hiện DFD của hoạt động “Nhập học”.

4.2.3. Các thành phần của mô hình luồng dữ liệu

Chức năng [còn gọi là Tiến trình]

Đ

ịnh nghĩa: Là một hoạt động có liên quan đến sự biến đổi hoặc tác động lên thông tin như tổ chức lại thông tin, bổ sung thông tin hoặc tạo ra thông tin mới. Nếu trong một chức năng không có thông tin mới được sinh ra thì đó chưa phải là chức năng trong mô hình luồng dữ liệu.

• Cách đặt tên: Động từ + bổ ngữ.

• Biểu diễn bằng một hình ô van hoặc hình tròn

Luồng dữ liệu:

• Định nghĩa: Là luồng thông tin vào hoặc ra khỏi chức năng

• Cách đặt tên: Danh từ + tính từ

• Biểu diễn bằng mũi tên với nhãn ghi thông tin di chuyển

 

Kho dữ liệu

Đ

ịnh nghĩa: Kho dữ liệu là nơi biểu diễn thông tin cần lưu giữ, để một hoặc nhiều chức năng sử dụng chúng.

Cách đặt tên kho dữ liệu như sau: danh từ + tính từ. Tên kho phải chỉ rõ nội dung dữ liệu trong kho.

Tên kho dữ liệu được biểu diễn giữa cặp đường thẳng song song:

Q

uan hệ giữa kho dữ liệu, chức năng và luồng dữ liệu được biểu diễn như sau:

T

ác nhân ngoài

• Định nghĩa: Là một người hoặc một nhóm người nằm ngoài hệ thống nhưng có trao đổi trực tiếp với hệ thống. Sự có mặt của các nhân tố này trên sơ đồ chỉ ra giới hạn của hệ thống, định rõ mối quan hệ của hệ thống với thế giới bên ngoài

• Biểu diễn bằng một hình chữ nhật.

Tác nhân trong

L

à một chức năng hoặc một hệ thống con của hệ thống đang xét nhưng được trình bày ở một trang khác của mô hình. Mọi sơ đồ luồng dữ liệu đều có thể bao gồm một số trang, thông tin truyền giữa các quá trình trên các trang khác nhau được chỉ ra nhờ kí hiệu này.

• Biểu diễn bằng một hình chữ nhật hở một cạnh

4.2.4. Một số quy tắc vẽ biểu đồ luồng dữ liệu

Khi vẽ biểu đồ luồng dữ liệu ta phải thực hiện theo các quy tắc sau:

• Các luồng dữ liệu vào của một tiến trình cần khác với các luồng dữ liệu ra của nó. Tức là các dữ liệu qua một tiến trình phải có thay đổi. Ngược lại, tiến trình là không cần thiết vì không tác động gì đến các luồng thông tin đi qua nó

• Các đối tượng trong một mô hình luồng dữ liệu phải có tên duy nhất: mỗi tiến trình phải có tên duy nhất. Tuy nhiên, vì lí do trình bày cùng một tác nhân trong, tác nhân ngoài và kho dữ liệu có thể được vẽ lặp lại.

• Các luồng dữ liệu đi vào một tiến trình phải đủ để tạo thành các luồng dữ liệu đi ra.

• Nói chung tên luồng thông tin vào/ra kho trùng với tên kho vì vậy không cần viết tên luồng. Nhưng khi ghi hoặc lấy tin chỉ tiến hành một phần kho thì lúc đó phải đặt tên cho luồng

• Không có một tiến trình nào chỉ có cái ra mà không có cái vào. Đối tượng chỉ có cái ra thì có thể là tác nhân ngoài [nguồn]

K
hông một tiến trình nào mà chỉ có cái vào mà không có cái ra. Một đối tượng chỉ có cái vào thì chỉ có thể là tác nhân ngoài [đích] - Không thể xảy ra các trường hợp biểu diễn sau:

 

4.2.5. Trình tự xây dựng mô hình luồng dữ liệu

Bước 1: Xây dựng mô hình luồng dữ liệu mức ngữ cảnh [context-level, mức 0]

• Mô hình luồng dữ liệu mức ngữ cảnhgồm một chức năng duy nhất biểu thị toàn bộ hệ thống đang nghiên cứu, chức năng này được nối với mọi tác nhân ngoài của hệ thống.

C

ác luồng dữ liệu giữa chức năng và tác nhân ngoài thể hiện thông tin vào/ra của hệ thống

Bước 2: Xây dựng mô hình luồng dữ liệu mức đỉnh [top-level, mức 1]

• Với mức đỉnh các tác nhân ngoài của hệ thống ở mức ngữ cảnh được giữ nguyên với các luồng thông tin vào ra.

• Hệ thống được phân rã thành các chức năng mức đỉnh là các tiến trình chính bên trong hệ thống theo mô hình phân rã chức năng mức 1.

X

uất hiện thêm các kho dữ liệu và luồng thông tin trao đổi giữa các chức năng mức đỉnh.

Bước 3: Xây dựng mô hình luồng dữ liệu mức dưới đỉnh [lower-level, mức 2 và dưới 2]

Ở mức này thực hiện phân rã đối với mỗi chức năng của mức đỉnh.

• Khi thực hiện mức phân rã này vẫn phải căn cứ vào mô hình phân rã chức năng để xác định các chức năng con sẽ xuất hiện trong mô hình luồng dữ liệu.

• Việc phân rã có thể tiếp tục cho đến khi đủ số mức cần thiết

• Khi phân rã các chức năng phải đảm bảo tất cả các luồng thông tin vào ra ở chức năng mức cao phải có mặt trong các chức năng mức thấp hơn và ngược lại.

4.2.6. Chuyển từ mô hình luồng dữ liệu vật lý sang mô hình luồng dữ liệu logic

Việc chuyển từ mô hình luồng dữ liệu vật lý sang mô hình luồng dữ liệu logic có tác dụng sau:

• Xác định nhu cầu thông tin ở mỗi chức năng

• Cho một thiết kế sơ bộ về thực hiện chức năng

• Là phương tiện giao tiếp giữa người phân tích thiết kế và người sử dụng

• Luôn có hai mức diễn tả vật lý và logic. Mức vật lý trả lời câu hỏi như thế nào, mức lôgíc trả lời câu hỏi làm gì.

• Trong thực tế người ta thấy rằng việc tạo ra một mô hình luồng dữ liệu cho hệ thống thực dưới dạng vật lý không có lợi vì những lý do sau:

• Tốn nhiều thời gian và tiêu tốn nguồn tài nguyên phát triển dự án một cách không cần thiết. Có thể xem quá trình này là việc sao chép công việc của kỹ thuật viên điều tra, sao chép tất cả những gì đang thực hiện hiện tại.

• Khi tạo ra mô hình thì phải tạo ra những điều chỉnh tượng trưng cho nó, xử lý nó như mô hình logic, kết quả là hệ thống mới chỉ đơn thuần là tin học hoá hệ thống cũ với rất nhiều lỗi mà cái ta cần cuối cùng là mô hình DFD logic.

• Mô hình luồng dữ liệu logic loại bỏ những ràng buộc và các yếu tố vật lý, mô hình này chỉ quan tâm chức năng nào là cần cho hệ thống và thông tin nào là cần để thực hiện cho chức năng đó. Các yếu tố vật lý cần loại bỏ là:

• Các phương tiện, phương thức: tự động, thủ công, bàn phím, màn hình…

• Các giá mang thông tin: các tệp, chứng từ

• Các chức năng xử lý gắn với các công cụ hay cách thức cài đặt cụ thể

• Tiến hành các loại bỏ và chỉnh đốn lại cấu trúc. Loại bỏ: loại bỏ các ngôn từ, hình vẽ biểu diễn các phương tiện, giá mang tin … giữ lại các chức năng và nội dung thông tin

• Nên xây dựng mô hình logic cần có bằng cách điều chỉnh mô hình logic thực tại.

• Không có sự phân chia rõ rệt giữa logic và vật lý. Mô hình càng phân rã ở mức thấp thì càng thêm nhiều yếu tố vật lý.

• Càng giữ cho mô hình của mình được logic nhiều nhất khi đi sâu vào chi tiết càng tốt.

 

4.2.7. Chuyển từ mô hình luồng dữ liệu của hệ thống cũ sang mô hình luồng dữ liệu của hệ thống mới

Giai đoạn này có ý nghĩa vô cùng quan trọng ảnh hưởng to lớn đến sự thành công của hệ thống mới. Trong giai đoạn này nhà quản lý và nhà phân tích phải hợp tác chặt chẽ để tìm cách hoà hợp cơ cấu tổ chức, nhận thức được vai trò của máy tính để thay đổi hệ thống cũ. Để chuyển từ mô hình luồng dữ liệu của hệ thống cũ sang mô hình luồng dữ liệu của hệ thống mới, trước tiên phải xác định các mặt yếu kém cần cải tiến, thay đổi trong hệ thống cũ. Các yếu kém chủ yếu do sự thiếu vắng gây ra: thiếu vắng về cơ cấu tổ chức hợp lý, thiếu vắng các phương tiện hoạt động từ đó dẫn đến hiệu quả hoạt động thấp, chi phí hoạt động cao.

Các bước chuyển đổi:

• Xem lại mô hình luồng dữ liệu

• Nếu thiếu vắng thì bổ sung

• Nếu thay đổi bắt đầu từ mức đỉnh

• Khoanh vùng vùng sẽ được thay đổi

• Giữ nguyên các luồng vào và luồng ra của vùng

• Xác định chức năng tổng quát của vùng

• Xoá bỏ mô hình luồng dữ liệu bên trong vùng được khoanh, lập lại các chức năng từ mức thấp nhất

• Thành lập kho dữ liệu và luồng dữ liệu cần thiết.

• Sửa lại mô hình phân rã chức năng theo mô hình luồng dữ liệu.

• Kiểm tra lại các mô hình dữ liệu điều chỉnh lại cho hợp lý.

Ví dụ: Hệ cung ứng vật tư

• Nhược điểm: thiếu kho hàng thông dụng

• Tốc độ chậm vì có khâu đối chiếu thủ công

• Theo dõi thực hiện đơn hàng còn nhiều sai sót

• Lãng phí do đối chiếu thủ công

• Sửa mô hình luồng dữ liệu

• Sửa lại mô hình luồng dữ liệu của hệ thống

4.2.8. Hoàn chỉnh mô hình luồng dữ liệu

Khi đã hoàn thành sơ đồ luồng dữ liệu cần kiểm tra về tính đầy đủ và nhất quán của nó. Phải làm cho sơ đồ đơn giản, chính xác và logic nhất có thể được. Nên tránh để xảy ra các tình huống sau:

• Tình huống 1: Hiệu ứng “mặt trời bừng sáng” tức là một chức năng có quá nhiều dòng vào, ra. Cách khắc phục tình huống này như sau: Gom nhóm hoặc phân rã tiếp một số chức năng chưa hợp lý.

• Tình huống 2: Thông tin đi qua một chức năng mà không bị thay đổi. Cách khắc phục tình huống này như sau: xoá bỏ chức năng không biến đổi thông tin.

Nếu xuất hiện một chức năng có các chức năng con không có liên quan về dữ liệu [không có dòng thông tin nội bộ gắn với nhau hoặc không sử dụng kho dữ liệu chung] thì việc phân bố sơ đồ phân rã chức năng là chưa hợp lý, lúc này cần phải xem xét lại.

Cần chú ý rằng khi thay đổi mô hình luồng dữ liệu thì phải sửa lại mô hình phân rã chức năng cho phù hợp.

Tác dụng của việc hoàn chỉnh mô hình luồng dữ liệu

• Xác định nhu cầu thông tin ở mỗi chức năng

• Cho một thiết kế sơ bộ về thực hiện chức năng

• Là phương tiện giao tiếp giữa người phân tích thiết kế và người sử dụng

• Luôn có hai mức diễn tả vật lý và lôgíc. Mức vật lý trả lời câu hỏi như thế nào, mức lôgíc trả lời câu hỏi làm gì.

4.2.9. Phân mức mô hình luồng dữ liệu

Sơ đồ luồng dữ liệu đầy đủ của hệ thống là rất phức tạp và không thể xếp gọn trong một trang nên cần dùng tới kỹ thuật phân rã sơ đồ theo một số mức. Các mức được đánh số thứ tự, mức cao nhất [mức khung cảnh] là 0 sau đó đến mức đỉnh 1, các mức dưới đỉnh 2, 3 …

Mức 0: Tên chức năng là tên toàn bộ hệ thống.

Mức 1: Mỗi chức năng được gắn với một số và sẽ được mang tiếp theo với các chỉ số chỉ mức phụ thuộc, xem như một cách đặt tên theo số cho từng chức năng con của nó. Bắt đầu ở mức 1 mới có các kho dữ liệu.

4.2.10. Hạn chế của mô hình luồng dữ liệu

• Không chỉ ra được yếu tố thời gian [Ví dụ: Thông tin chuyển từ tiến trình này sang tiến trình khác hết bao nhiêu thời gian]

• Không xác định được trật tự thực hiện các chức năng.

• Không chỉ ra được yếu tố định lượng đối với dữ liệu có liên quan [tối đa và tối thiểu những thông tin là cơ bản trong quá trình phân tích]