giáo trình công nghệ phần mềm

Công Nghệ Phần Mềm CHƯƠNG 1.

Đang xem: Giáo trình công nghệ phần mềm

TỔNG QUAN VỀ CÔNG NGHỆ PHẦN MỀM

1.1. ĐÔI ĐIỀU VỀ VẤN ĐỀ THUẬT NGỮ

Theo tiếng Anh thì công nghệ là technology , còn phần mềm là software . Như vậy công nghệ phần mềm phải chăng theo tiếng Anh là “software technology”? Tuy nhiên thực tế lại không phải vậy. Trong tiếng Anh không có thuật ngữ “software technology” trong các từ điển tin học hay bách khoa toàn thư, mà chỉ có thuật ngữ “software engineering” . Từ “engineering” có nghĩa là “kỹ nghệ”. Cũng chính vì vậy mà trong một số tài liệu có một số tác giả dùng thuật ngữ “kỹ nghệ phần mềm”. Ở Việt nam người ta quen dùng từ “công nghệ” hơn. Do đó phần lớn các trường vẫn gọi môn học “software engineering” là “công nghệ phần mềm”. Ở đây chúng tôi cũng dùng thuật ngữ này trên tinh thần như vậy.

Ngày nay kho kiến thức của loài người ngày càng được mở rộng, nhiều ngành khoa học đã áp dụng các thành tựu của nhau và do đó ranh giới giữa chúng không còn rõ ràng như trước đây. Việc định nghĩa chính xác các khái niệm cũng trở nên khó khăn và khó nhất quán. Cùng một khái niệm, cùng một thuật ngữ nhưng trong một hoàn cảnh nhất định lại được hiểu khác đi. Lấy ví dụ ngay trong lĩnh vực tin học: thuật ngữ “hệ thống” (system) có khi được hiểu là một tập hợp các chương trình giải quyết một vấn đề nào đó, ví dụ operating system hay management information system ; nhưng có khi bao hàm cả các chương trình và thiết bị phần cứng, ví dụ computer system hay the flight control system … Chính Stephen R. Schach, tác giả cuốn “Object-Oriented and Classical Software Engineering” cũng phải thốt lên rằng, tác giả đã quá mệt khi phải đánh vật với cối xay gió (tác giả ám chỉ việc sử dụng thuật ngữ) và mong các bạn đọc thông cảm.

Trong bối cảnh đó, các định nghĩa chúng tôi nêu ra sau đây chỉ nhằm mục đích cung cấp cho các bạn một sự hình dung về các khái niệm. Như vậy các bạn chỉ cần hiểu, và có thể diễn đạt lại theo cách suy nghĩ của mình, chứ không cần học thuộc từng chữ các khái niệm này. Có một số khái niệm các bạn có thể chưa hiểu ngay khi đọc lần đầu. Trong trường hợp này các bạn cứ tạm chấp nhận rồi tìm hiểu sau.

1.2. CÁC ĐỊNH NGHĨA VÀ THUẬT NGỮ

1.2.1. Một số khái niệm chung

Khoa học (science) là hệ thống các tri thức do con người khám phá ra. Khoa học tập trung vào việc tìm hiểu và rút ra các quy luật thực tế (của tự nhiên và của con người). Các quy luật này thường được phát biểu dưới dạng các định lý, các mệnh đề, các công thức toán học, các bài viết…ví dụ định luật vạn vật hấp dẫn, định lý Pitagor, quy luật giá trị thặng dư…Khoa học được chia thành các nghành như toán học, hóa học, sinh học, văn học, lịch sử, …

Kỹ thuật (technique) là chỉ ra một cách thức tiến hành một công việc cụ thể nào đó. Cách làm này thường có áp dụng kiến thức khoa học và được hệ thống thành các bước sao cho những người khác cũng có thể học và làm theo. Ví dụ kỹ thuật hàn , kỹ thuật tân trang xe máy . Trong tin học ta nói đến kỹ thuật phần mềm bao gồm kỹ thuật viết hệ điều hành, kỹ thuật làm chương trình điều khiển. Ta cũng hay nói “kỹ thuật lập trình” tức là cách thức viết chương trình sao cho tối ưu theo một nghĩa nào đó.

Công nghệ (technology) nói tới cách thức hay phương pháp để làm một việc gì đó, cụ thể hoặc trừu tượng, có áp dụng các thành tựu của khoa học và được thực hiện một cách có bài bản, hệ thống. Ta thường nói “công nghệ sinh học”, “công nghệ jen”, hay “công nghệ giáo dục”… Như thế, “công nghệ” có thể được hiểu là khái niệm rộng hơn khái niệm kỹ thuật. Kỹ thuật nói tới cách thực hiện chi tiết, còn công nghệ thì nhấn mạnh tính hệ thống, bài bản.

Kỹ nghệ (engineering) là việc sử dụng phối hợp các công nghệ cần thiết để tạo ra các sản phẩm.

Công nghiệp (industry) là khái niệm bao trùm cả một nghành lớn, trong đó bên cạnh yếu tố kỹ nghệ còn có thêm các yếu tố khác như kinh tế, tài chính, tổ chức xã hội.

Câu sau đây cho chúng ta cách hình dung về mối liên quan của các khái niệm vừa nói (trừ khái niệm khoa học):

Trong ngành công nghiệp xe hơi, kỹ nghệ xe hơi cần đến các kỹ thuật đúc hàn… của công nghệ cơ khí, kỹ thuật làm lốp xe của công nghệ cao

1.2.2. Một số khái niệm liên quan đến công nghệ phần mềm

Phần cứng (hardware) là các thiết bị cấu kiện mang tính vật lý có thể tiếp xúc bằng tay được như máy in, ổ đĩa, máy quét, các mạch tích hợp (IC).

Nghĩa đơn giản nhất của phần mềm (software) là các chương trình chứa các dòng lệnh chỉ thị cho máy tính thực hiện một công việc nào đó. Tuy nhiên thường người ta hiểu phần mềm là một tập hợp các chương trình và cả dữ liệu phục vụ cho một công việc được tin học hóa nào đó. Ví dụ phần mềm quản lý các dịch vụ bay, phần mềm điều khiển lò phản ứng hạt nhân, phần mềm điều khiển dịch vụ mobile phone…Đôi khi người ta gọi phần mềm là chương trình, cho dù thực tế thì phần mềm gồm nhiều chương trình và dữ liệu. Ví dụ: chương trình quản lý nhân sự, chương trình quản lý tín dụng…

Trong công nghệ phần mềm, người ta hiểu phần mềm không chỉ là các chương trình, dữ liệu , mà còn gồm cả các tài liệu liên quan như các bản đặc tả, thiết kế, hướng dẫn sử dụng.

Chương trình (program): đôi khi người ta gọi phần mềm là chương trình. Hay chính xác hơn, người ta thường gọi phần được cài đặt trên máy tính để chạy là chương trình . Với cách hiểu như vậy thì phần mềm = chương trình + tài liệu. Tuy nhiên, trong thực tế có khi người ta đồng nhất hai khái niệm này. Ví dụ người ta nói rằng “phần mềm được cài đặt trên máy tính khách hàng”.

Kỹ nghệ phần mềm (software engineering) là cách làm phần mềm tuân theo những nguyên tắc tương tự như các nguyên tắc của kỹ nghệ truyền thống (ví dụ kỹ nghệ xây dựng cầu, kỹ nghệ làm đường,…)

Như chúng tôi đã nói tới ở trên, do thói quen, chúng ta dùng từ công nghệ phần mềm thay cho từ được dịch đúng nghĩa hơn là kỹ nghệ phần mềm .

Vòng đời phần mềm (software life-cycle) là các bước mà một phần mềm phải trải qua, bắt đầu từ khảo sát nhu cầu khách hàng cho đến khi phần mềm không còn được sử dụng.

Phát triển phần mềm (software developement) quá trình xây dựng phần mềm từ bắt đầu cho đến khi chuyển giao cho khách hàng.

Người phát triển (software developer) là tên gọi chung cho những người tham gia xây dựng phần mềm.

Nhóm đảm bảo chất lượng phần mềm (software quality assurance group = SQA group) nhóm chuyên kiểm tra chất lượng phần mềm, kiểm tra kết quả của từng giai đoạn xây dựng phần mềm.

Quy trình phần mềm (software process) là cách thức làm ra phần mềm, bao gồm vòng đời phần mềm, các công cụ và những người phát triển phần mềm.

Pha (phase) là một giai đoạn trong quá trình xây dựng phần mềm. Ví dụ pha xác định yêu cầu, pha phân tích…

Yêu cầu (requirements) là pha đầu tiên trong quá trình xây dựng phần mềm. Pha này thường có tên gọi là tìm hiểu khái niệm (concept exploration). Người phát triển và khách hàng ngồi lại với nhau. Khách hàng nêu ra những yêu cầu mà phần mềm phải có. Những người phát triển ghi chép lại. Nếu dịch theo tiếng Anh “requirements phase” là pha yêu cầu. Tuy nhiên cách gọi quá đơn giản như thế này có thể hơi khó hiểu, do đó ta sẽ gọi là pha xác định yêu cầu .

Đặc tả (specification) hoặc phân tích (analysis): Trên cơ sở những yêu cầu của khách hàng, người phát triển mô tả lại chính xác hơn các yêu cầu mà phần mềm phải có. Cách mô tả này có tính chuyên môn và đôi khi sử dụng các công cụ trợ giúp. Pha này trả lời câu hỏi “phần mềm làm cái gì?”

Phân tích hệ thống (system analysis) người ta thường gộp hai pha yêu cầu và phân tích thành một pha và gọi là pha phân tích hệ thống.

Thiết kế (design) là pha tiếp theo pha đặc tả. Căn cứ vào tài liệu đặc tả, pha này mô tả cách thức mà phần mềm thực hiện các công việc cụ thể. Pha này trả lời câu hỏi “phần mềm làm như thế nào?”. Pha thiết kế thường có hai phần: thiết kế kiến trúc (architecture design) và thiết kế chi tiết (detail design).

Cài đặt (implementation) hoặc mã hóa (coding) hay lập trình (programming): viết chương trình bằng một ngôn ngữ cụ thể nào đó.

Tích hợp (integration) kết nối các phần chương trình đã viết thành một phần mềm thống nhất và chạy thử, hiệu chỉnh cho đến khi chạy tốt. Pha này đôi khi được gọi là kiểm thử hoặc kiểm chứng hay đơn giản là thử .

Bảo trì (maintenance) hay đôi khi được gọi là hỗ trợ (trong tài liệu tiếng Việt): Khi chương trình đã được cài đặt trên máy của khách hàng vẫn có thể có lỗi phát sinh cần loại trừ hoặc phải hiệu chỉnh lại phần mềm theo yêu cầu khách hàng.

Kế hoạch quản lý dự án phần mềm (software project management plan – SPMP) bản kế hoạch được soạn thảo sau khi hoàn thành pha đặc tả, trong đó mô tả chi tiết kế hoạch xây dựng phần mềm (có cả thời gian hoàn thành và giá cả).

Trong các phần sau chúng ta sẽ còn nêu lại các khái niệm này.

Như vậy các bạn có thể thấy, trong tin học các thuật ngữ không được sử dụng một cách chính xác như toán học .

1.2.3. Vấn đề dịch các thuật ngữ tiếng Anh ra tiếng Việt

Phần lớn các thuật ngữ tin học đều có xuất xứ tiếng Anh, khi dịch sang tiếng Việt thường rất khó dịch chính xác, vì một từ tiếng Anh tương ứng với rất nhiều từ tiếng Việt. Ví dụ từ “process” có các nghĩa là xử lý, quá trình , quy trình , trong đó từ quá trình được sử dụng nhiều hơn. Tuy nhiên khi dịch cụm từ “software process” sang tiếng Việt, nếu dịch là “quá trình phần mềm” sẽ nghe lạ tai và khó hiểu. Có tác giả dịch là “tiến trình phần mềm” tuy có dễ nghe hơn nhưng vẫn hơi khó hiểu. Theo chúng tôi có một số tác giả dịch là “quy trình phần mềm” có lẽ nghe xuôi tai và dễ hiểu hơn cả. Khi ta nói “quy trình làm sổ đỏ” có lẽ dễ hiểu hơn là nói “tiến trình làm sổ đỏ”.

Một số từ khác, ví dụ “implementation” có hai nghĩa như nhau là thực hiện , thi hành . Và vì thế trong quy trình làm phần mềm thì việc dịch thuật ngữ “implementation phase” là “pha thực hiện” có thể coi là cách dịch duy nhất. Tuy nhiên từ “thực hiện” lại được dùng ở rất nhiều nơi với ý nghĩa khác, chứ không hẳn là viết chương trình. Vì vậy nếu nói “pha thực hiện” thì đối với người chưa quen với tin học nghe rất khó hiểu. Làm sao họ có thể hiểu được “thực hiện phần mềm” lại là viết chương trình? Vì vậy có tác giả dùng từ “cài đặt” để thay thế, và dịch “implementation phase” là pha cài đặt . Bản thân tôi cũng ủng hộ cách dịch này, vì ở Việt nam vẫn quen dùng từ “cài đặt” để chỉ việc viết chương trình, ví dụ: cài đặt thuật toán Euclid bằng ngôn ngữ Pascal. Tuy nhiên từ “cài đặt” vẫn có thể nhầm với nghĩa của từ “installation” hay “setup”, tức là cài đặt (chứ không phải viết chương trình) một phần mềm lên máy tính để phần mềm này có thể chạy được. Có lẽ chúng ta đành chấp nhận từ “cài đặt” có hai nghĩa vậy: một nghĩa tương ứng với từ “setup” trong tiếng Anh, còn một nghĩa là “writing code”, tức là viết chương trình. Như vậy nếu các bạn gặp các thuật ngữ: lập trình, cài đặt, thực hiện, viết mã, viết code, mã hóa , thì thực ra chúng chỉ là một mà thôi. Có thể nói rằng tin học là lĩnh vực đang phát triển nên ngay ở Mỹ việc dùng thuật ngữ cũng không có sự thống nhất. Lấy ví dụ ngay trong mô hình vòng đời phần mềm, thì có người gọi pha “đặc tả” là pha “phân tích”, hay gộp hai pha “yêu cầu” và pha “phân tích” thành pha phân tích hệ thống. Cách dịch sát ý nhiều khi làm cho câu khó hiểu. Ví dụ như chúng tôi đã nói đến trong phần trước, nếu dịch “requirements phase” là pha yêu cầu thì khó hiểu hơn là dịch thoát ý: pha xác định yêu cầu . Như vậy, khi sử dụng các tài liệu tiếng Anh chúng tôi sẽ áp dụng cách dịch thoát ý nếu thấy cần thiết.

Khi đọc các tài liệu khác nhau, các bạn sẽ thấy những thuật ngữ được sử dụng không nhất quán. Chúng tôi nghĩ rằng điều đó đối với các bạn không quá quan trọng để các bạn phải băn khoăn. Các bạn hãy dùng một cách gọi nào đó mà các bạn thấy thích hợp, điều quan trọng là các bạn phải nắm được ý nghĩa thực sự của nó.

1.3. PHẠM VI CỦA CÔNG NGHỆ PHẦN MỀM

1.3.1.Mở đầu

Mục tiêu của công nghệ phần mềm là sản xuất ra các phần mềm không có lỗi , được hoàn thành đúng thời hạn với kinh phí cho phépthỏ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??

Viết một bình luận