Kĩ thuật phần mềm ứng dụng

Kỹ thuật phần mềm ứng dụng

CHƯƠNG 1. TỔNG QUAN VỀ CÔNG NGHỆ PHẦN MỀM 1.1. ĐÔI ĐIỀU VỀ VẤN ĐỀ THUẬT NGỮ Theo tiếng Anh thì công nghệ là technology, còn phần mềm là software. Như vậy công nghệ phần mềm phải chăng theo tiếng Anh là “software technology”? Tuy nhiên thực tế lại không phải vậy. Trong tiếng Anh không có thuật ngữ “software technology” trong các từ điển tin học hay bách khoa toàn thư, mà chỉ có thuật ngữ “software engineering”. Từ “engineering” có nghĩa là “kỹ nghệ”. Cũng chính vì vậy mà trong một số tài liệu có một số tác giả dùng thuật ngữ “kỹ nghệ phần mềm”. Ở Việt nam người ta quen dùng từ "công nghệ" hơn. Do đó phần lớn các trường vẫn gọi môn học “software engineering” là “công nghệ phần mềm”. Ở đây chúng tôi cũng dùng thuật ngữ này trên tinh thần như vậy. Ngày nay kho kiến thức của loài người ngày càng được mở rộng, nhiều ngành khoa học đã áp dụng các thành tựu của nhau và do đó ranh giới giữa chúng không còn rõ ràng như trước đây. Việc định nghĩa chính xác các khái niệm cũng trở nên khó khăn và khó nhất quán. Cùng một khái niệm, cùng một thuật ngữ nhưng trong một hoàn cảnh nhất định lại được hiểu khác đi. Lấy ví dụ ngay trong lĩnh vực tin học: thuật ngữ "hệ thống" (system) có khi được hiểu là một tập hợp các chương trình giải quyết một vấn đề nào đó, ví dụ operating system hay management information system; nhưng có khi bao hàm cả các chương trình và thiết bị phần cứng, ví dụ computer system hay the flight control system Chính Stephen R. Schach, tác giả cuốn "Object- Oriented and Classical Software Engineering" cũng phải thốt lên rằng, tác giả đã quá mệt khi phải đánh vật với cối xay gió (tác giả ám chỉ việc sử dụng thuật ngữ) và mong các bạn đọc thông cảm. Trong bối cảnh đó, các định nghĩa chúng tôi nêu ra sau đây chỉ nhằm mục đích cung cấp cho các bạn một sự hình dung về các khái niệm. Như vậy các bạn chỉ cần hiểu, và có thể diễn đạt lại theo cách suy nghĩ của mình, chứ không cần học thuộc từng chữ các khái niệm này. Có một số khái niệm các bạn có thể chưa hiểu ngay khi đọc lần đầu. Trong trường hợp này các bạn cứ tạm chấp nhận rồi tìm hiểu sau. 1.2. CÁC ĐỊNH NGHĨA VÀ THUẬT NGỮ 1.2.1. Một số khái niệm chung Khoa học (science) là hệ thống các tri thức do con người khám phá ra. Khoa học tập trung vào việc tìm hiểu và rút ra các quy luật thực tế (của tự nhiên và của con người). Các quy luật này thường được phát biểu dưới dạng các định lý, các mệnh đề, các công thức toán học, các bài viết ví dụ định luật vạn vật hấp dẫn, định lý Pitagor, quy luật giá trị thặng dư Khoa học được chia thành các nghành như toán học, hóa học, sinh học, văn học, lịch sử, Kỹ thuật (technique) là chỉ ra một cách thức tiến hành một công việc cụ thể nào đó. Cách làm này thường có áp dụng kiến thức khoa học và được hệ thống thành các bước sao cho những người khác cũng có thể học và làm theo. Ví dụ kỹ thuật hàn, kỹ thuật tân trang xe máy. Trong tin học ta nói đến kỹ thuật phần mềm bao gồm kỹ thuật viết hệ điều hành, kỹ thuật làm chương trình điều khiển. Ta cũng hay nói “kỹ thuật lập trình” tức là cách thức viết chương trình sao cho tối ưu theo một nghĩa nào đó. Công nghệ (technology) nói tới cách thức hay phương pháp để làm một việc gì đó, cụ thể hoặc trừu tượng, có áp dụng các thành tựu của khoa học và được thực hiện một cách có bài bản, hệ thống. Ta thường nói “công nghệ sinh học”, “công nghệ jen”, hay “công nghệ giáo dục” Như thế, “công nghệ” có thể được hiểu là khái niệm rộng hơn khái niệm kỹ thuật. Kỹ thuật nói tới cách thực hiện chi tiết, còn công nghệ thì nhấn mạnh tính hệ thống, bài bản. Kỹ nghệ (engineering) là việc sử dụng phối hợp các công nghệ cần thiết để tạo ra các sản phẩm. Công nghiệp (industry) là khái niệm bao trùm cả một nghành lớn, trong đó bên cạnh yếu tố kỹ nghệ còn có thêm các yếu tố khác như kinh tế, tài chính, tổ chức xã hội. Câu sau đây cho chúng ta cách hình dung về mối liên quan của các khái niệm vừa nói (trừ khái niệm khoa học): Trong ngành công nghiệp xe hơi, kỹ nghệ xe hơi cần đến các kỹ thuật đúc hàn của công nghệ cơ khí, kỹ thuật làm lốp xe của công nghệ cao 1.2.2. Một số khái niệm liên quan đến công nghệ phần mềm Phần cứng (hardware) là các thiết bị cấu kiện mang tính vật lý có thể tiếp xúc bằng tay được như máy in, ổ đĩa, máy quét, các mạch tích hợp (IC). Nghĩa đơn giản nhất của phần mềm (software) là các chương trình chứa các dòng lệnh chỉ thị cho máy tính thực hiện một công việc nào đó. Tuy nhiên thường người ta hiểu phần mềm là một tập hợp các chương trình và cả dữ liệu phục vụ cho một công việc được tin học hóa nào đó. Ví dụ phần mềm quản lý các dịch vụ bay, phần mềm điều khiển lò phản ứng hạt nhân, phần mềm điều khiển dịch vụ mobile phone Đôi khi người ta gọi phần mềm là chương trình, cho dù thực tế thì phần mềm gồm nhiều chương trình và dữ liệu. Ví dụ: chương trình quản lý nhân sự, chương trình quản lý tín dụng Trong công nghệ phần mềm, người ta hiểu phần mềm không chỉ là các chương trình, dữ liệu, mà còn gồm cả các tài liệu liên quan như các bản đặc tả, thiết kế, hướng dẫn sử dụng. Chương trình (program): đôi khi người ta gọi phần mềm là chương trình. Hay chính xác hơn, người ta thường gọi phần được cài đặt trên máy tính để chạy là chương trình. Với cách hiểu như vậy thì phần mềm = chương trình + tài liệu. Tuy nhiên, trong thực tế có khi người ta đồng nhất hai khái niệm này. Ví dụ người ta nói rằng "phần mềm được cài đặt trên máy tính khách hàng". Kỹ nghệ phần mềm (software engineering) là cách làm phần mềm tuân theo những nguyên tắc tương tự như các nguyên tắc của kỹ nghệ truyền thống (ví dụ kỹ nghệ xây dựng cầu, kỹ nghệ làm đường, ) Như chúng tôi đã nói tới ở trên, do thói quen, chúng ta dùng từ công nghệ phần mềm thay cho từ được dịch đúng nghĩa hơn là kỹ nghệ phần mềm. Vòng đời phần mềm (software life-cycle) là các bước mà một phần mềm phải trải qua, bắt đầu từ khảo sát nhu cầu khách hàng cho đến khi phần mềm không còn được sử dụng. Phát triển phần mềm (software developement) quá trình xây dựng phần mềm từ bắt đầu cho đến khi chuyển giao cho khách hàng. Người phát triển (software developer) là tên gọi chung cho những người tham gia xây dựng phần mềm. Nhóm đảm bảo chất lượng phần mềm (software quality assurance group = SQA group) nhóm chuyên kiểm tra chất lượng phần mềm, kiểm tra kết quả của từng giai đoạn xây dựng phần mềm. Quy trình phần mềm (software process) là cách thức làm ra phần mềm, bao gồm vòng đời phần mềm, các công cụ và những người phát triển phần mềm. Pha (phase) là một giai đoạn trong quá trình xây dựng phần mềm. Ví dụ pha xác định yêu cầu, pha phân tích Yêu cầu (requirements) là pha đầu tiên trong quá trình xây dựng phần mềm. Pha này thường có tên gọi là tìm hiểu khái niệm (concept exploration). Người phát triển và khách hàng ngồi lại với nhau. Khách hàng nêu ra những yêu cầu mà phần mềm phải có. Những người phát triển ghi chép lại. Nếu dịch theo tiếng Anh "requirements phase" là pha yêu cầu. Tuy nhiên cách gọi quá đơn giản như thế này có thể hơi khó hiểu, do đó ta sẽ gọi là pha xác định yêu cầu. Đặc tả (specification) hoặc phân tích (analysis): Trên cơ sở những yêu cầu của khách hàng, người phát triển mô tả lại chính xác hơn các yêu cầu mà phần mềm phải có. Cách mô tả này có tính chuyên môn và đôi khi sử dụng các công cụ trợ giúp. Pha này trả lời câu hỏi "phần mềm làm cái gì?" Phân tích hệ thống (system analysis) người ta thường gộp hai pha yêu cầu và phân tích thành một pha và gọi là pha phân tích hệ thống. Thiết kế (design) là pha tiếp theo pha đặc tả. Căn cứ vào tài liệu đặc tả, pha này mô tả cách thức mà phần mềm thực hiện các công việc cụ thể. Pha này trả lời câu hỏi "phần mềm làm như thế nào?". Pha thiết kế thường có hai phần: thiết kế kiến trúc (architecture design) và thiết kế chi tiết (detail design). Cài đặt (implementation) hoặc mã hóa (coding) hay lập trình (programming): viết chương trình bằng một ngôn ngữ cụ thể nào đó. Tích hợp (integration) kết nối các phần chương trình đã viết thành một phần mềm thống nhất và chạy thử, hiệu chỉnh cho đến khi chạy tốt. Pha này đôi khi được gọi là kiểm thử hoặc kiểm chứng hay đơn giản là thử. Bảo trì (maintenance) hay đôi khi được gọi là hỗ trợ (trong tài liệu tiếng Việt): Khi chương trình đã được cài đặt trên máy của khách hàng vẫn có thể có lỗi phát sinh cần loại trừ hoặc phải hiệu chỉnh lại phần mềm theo yêu cầu khách hàng. Kế hoạch quản lý dự án phần mềm (software project management plan - SPMP) bản kế hoạch được soạn thảo sau khi hoàn thành pha đặc tả, trong đó mô tả chi tiết kế hoạch xây dựng phần mềm (có cả thời gian hoàn thành và giá cả). Trong các phần sau chúng ta sẽ còn nêu lại các khái niệm này. Như vậy các bạn có thể thấy, trong tin học các thuật ngữ không được sử dụng một cách chính xác như toán học. 1.2.3. Vấn đề dịch các thuật ngữ tiếng Anh ra tiếng Việt Phần lớn các thuật ngữ tin học đều có xuất xứ tiếng Anh, khi dịch sang tiếng Việt thường rất khó dịch chính xác, vì một từ tiếng Anh tương ứng với rất nhiều từ tiếng Việt. Ví dụ từ "process" có các nghĩa là xử lý, quá trình, quy trình, trong đó từ quá trình được sử dụng nhiều hơn. Tuy nhiên khi dịch cụm từ "software process" sang tiếng Việt, nếu dịch là "quá trình phần mềm" sẽ nghe lạ tai và khó hiểu. Có tác giả dịch là "tiến trình phần mềm" tuy có dễ nghe hơn nhưng vẫn hơi khó hiểu. Theo chúng tôi có một số tác giả dịch là "quy trình phần mềm" có lẽ nghe xuôi tai và dễ hiểu hơn cả. Khi ta nói "quy trình làm sổ đỏ" có lẽ dễ hiểu hơn là nói "tiến trình làm sổ đỏ". Một số từ khác, ví dụ "implementation" có hai nghĩa như nhau là thực hiện, thi hành. Và vì thế trong quy trình làm phần mềm thì việc dịch thuật ngữ "implementation phase" là "pha thực hiện" có thể coi là cách dịch duy nhất. Tuy nhiên từ "thực hiện" lại được dùng ở rất nhiều nơi với ý nghĩa khác, chứ không hẳn là viết chương trình. Vì vậy nếu nói "pha thực hiện" thì đối với người chưa quen với tin học nghe rất khó hiểu. Làm sao họ có thể hiểu được "thực hiện phần mềm" lại là viết chương trình? Vì vậy có tác giả dùng từ "cài đặt" để thay thế, và dịch "implementation phase" là pha cài đặt. Bản thân tôi cũng ủng hộ cách dịch này, vì ở Việt nam vẫn quen dùng từ "cài đặt" để chỉ việc viết chương trình, ví dụ: cài đặt thuật toán Euclid bằng ngôn ngữ Pascal. Tuy nhiên từ "cài đặt" vẫn có thể nhầm với nghĩa của từ "installation" hay "setup", tức là cài đặt (chứ không phải viết chương trình) một phần mềm lên máy tính để phần mềm này có thể chạy được. Có lẽ chúng ta đành chấp nhận từ "cài đặt" có hai nghĩa vậy: một nghĩa tương ứng với từ "setup" trong tiếng Anh, còn một nghĩa là "writing code", tức là viết chương trình. Như vậy nếu các bạn gặp các thuật ngữ: lập trình, cài đặt, thực hiện, viết mã, viết code, mã hóa, thì thực ra chúng chỉ là một mà thôi. Có thể nói rằng tin học là lĩnh vực đang phát triển nên ngay ở Mỹ việc dùng thuật ngữ cũng không có sự thống nhất. Lấy ví dụ ngay trong mô hình vòng đời phần mềm, thì có người gọi pha "đặc tả" là pha "phân tích", hay gộp hai pha "yêu cầu" và pha "phân tích" thành pha phân tích hệ thống. Cách dịch sát ý nhiều khi làm cho câu khó hiểu. Ví dụ như chúng tôi đã nói đến trong phần trước, nếu dịch "requirements phase" là pha yêu cầu thì khó hiểu hơn là dịch thoát ý: pha xác định yêu cầu. Như vậy, khi sử dụng các tài liệu tiếng Anh chúng tôi sẽ áp dụng cách dịch thoát ý nếu thấy cần thiết. Khi đọc các tài liệu khác nhau, các bạn sẽ thấy những thuật ngữ được sử dụng không nhất quán. Chúng tôi nghĩ rằng điều đó đối với các bạn không quá quan trọng để các bạn phải băn khoăn. Các bạn hãy dùng một cách gọi nào đó mà các bạn thấy thích hợp, điều quan trọng là các bạn phải nắm được ý nghĩa thực sự của nó. 1.3. PHẠM VI CỦA CÔNG NGHỆ PHẦN MỀM 1.3.1.Mở đầu Mục tiêu của công nghệ phần mềm là sản xuất ra các phần mềm không có lỗi, được hoàn thành đúng thời hạn với kinh phí cho phép và thỏa mãn yêu cầu khách hàng. Hơn nữa phần mềm phải dễ sửa đổi khi người sử dụng cần. Để đạt được điều này các kỹ sư phần mềm phải được trang bị các kỹ năng về kỹ thuật cũng như về quản lý. Các kỹ năng này không chỉ thể hiện khi viết chương trình, mà phải được áp dụng trong các pha xây dựng phần mềm, bắt đầu từ khảo sát yêu cầu khách hàng cho đến giai đoạn bảo trì. Có nhiều người đã từng viết những chương trình máy tính, thậm chí đã tham gia viết nhiều chương trình ứng dụng trong thực tế mà chưa hề biết về "công nghệ phần mềm". Một điều đáng nói là không phải vì thế mà chương trình của họ kém hiệu quả. Vậy thì "công nghệ phần mềm" liệu có ích lợi gì, có thực sự cần thiết đối với những người phát triển phần mềm không? Chúng ta hãy xem một ví dụ thực tế: giả sử bạn cần xây dựng một ngôi nhà. Nếu bạn là thợ xây và ngôi nhà nhỏ thì bạn có thể xây mà không cần thiết kế trên giấy. Thực ra thì trước và trong quá trình xây nhà, bạn cũng đã hình dung ra công việc mình cần làm, bạn đã tưởng tượng ra ngôi nhà của mình, nghĩa là bạn cũng có thiết kế, nhưng không ghi ra trên giấy mà thôi. Nếu cũng là ngôi nhà đó nhưng bạn lại nhờ một người khác thì sao? Rõ ràng bạn phải giải thích cho người đó biết cần phải làm gì. Không ít trường hợp xẩy ra là cho dù bạn đã giải thích rất rõ, nhưng người thợ vẫn làm không đúng ý bạn. Có thể buổi sáng bạn đã căn dặn người thợ phải xây cầu thang như thế nào nhưng buổi chiều về bạn lại thấy một chiếc cầu thang khác hẳn điều bạn đã mô tả và kết quả là phải phá đi để làm lại. Đó là việc "xây ngôi nhà nhỏ". Nếu công trình ta cần xây dựng là cả một tòa nhà hay chiếc cầu bắc qua sông lớn thì không thể thiếu bản thiết kế chi tiết. Bản thiết kế phải được thảo luận rất nhiều trước khi đi đến phương án cuối cùng. Bản thiết kế đó phải rõ ràng sao cho người kỹ sư thi công và những nhười thợ phải hiểu được chính xác, không bị nhầm lẫn. Đối với việc viết chương trình cũng vậy. Nếu là vấn đề nhỏ như tính định thức ma trận hay tính xấp xỉ tích phân, bạn chỉ cần biết thuật toán rồi bắt tay vào viết những dòng lệnh trên máy. Thậm chí đối với bài toán lớn hơn như quản lý bán hàng ở một cửa hàng nhỏ chẳng hạn, với một phần mềm quản trị cơ sở dữ liệu có sẵn như foxpro, bạn chỉ cần trao đổi đôi điều với khách hàng rồi có thể bắt tay vào vừa viết vừa hiệu chỉnh cho đến khi nhận được sản phẩm có thể sử dụng được. Chương trình máy tính có một đặc điểm khác với các sản phẩm khác là có tính "mềm" như tên gọi của nó: ta có thể hiệu chỉnh các dòng lệnh hoặc xóa đi viết lại từng đoạn chương trình mà không tốn nhiều công sức và không ảnh hưởng đến kết quả cuối cùng. Trong thực tế có những việc khiến chúng ta phải cân nhắc rất kỹ trước khi thực hiện. Nếu là xây một bức tường ta có thể phá đi từng phần để xây lại, cho dù như thế có thể tốn một số vật liệu và công sức. Nhưng với người bác sĩ phẫu thuật thì anh ta phải suy nghĩ vô cùng cẩn thận khi đưa lưỡi dao cắt đi một phần nào đó của cơ thể người, vì nếu anh ta sai sót thì hậu quả thật khôn lường và đôi khi không thể sửa chữa được. Ngày nay có những hệ phần mềm cần hàng trăm người làm trong nhiều năm như hệ phần mềm dùng cho chương trình không gian của Mỹ. Thậm chí có những hệ cần đến hàng ngàn người trong nhiều nước làm trong nhiều năm như chương trình điều khiển tổng đài điện thoại hiện được bán khắp nơi trên thế giới. Khác với các sản phẩm khác, phần mềm không bao giờ giữ nguyên mà không ngừng được thay đổi. Ví dụ như chương trình quản lý kết quả thi đại học chẳng hạn. Có thể mỗi năm lại có một chính sách khác và phải sửa lại cho phù hợp. Chương trình quản lý nhân sự của một cơ quan, chương trình quản lý du lịch, cũng vậy. Thường thì sau một thời gian cài đặt và sử dụng, khách hàng lại có thêm một số yêu cầu và họ muốn phần mềm được sửa lại theo yêu cầu đó. Nếu lúc đó họ phải tìm lại tác giả cũ thì thật là khó khăn. Điều này đặt ra thêm một yêu cầu cho phần mềm: phần mềm phải được xây dựng sao cho các chuyên gia phần mềm khác (mà không phải là tác giả) có thể hiểu và bảo trì được. Tóm lại, có thể nêu một vài lý do khiến chúng ta phải nghiên cứu các cách thức xây dựng phần mềm một cách có khoa học là:  Ngày nay phần lớn phần mềm được xây dựng theo đơn đặt hàng. Như vậy cần có một ngôn ngữ chung giữa người xây dựng phần mềm và khách hàng.  Phần mềm thường không do một người mà gồm rất nhiều người xây dựng. Những người cùng phát triển một phần mềm phải hiểu rõ công việc của mình và công việc chung, mối liên hệ giữa công việc của từng cá nhân hoặc từng nhóm. Cần có một cách thức diễn đạt các công việc làm phần mềm sao cho mỗi kỹ sư phần mềm đều có thể trao đổi dễ dàng các ý tưởng và công việc của mình với các kỹ sư trong nhóm làm việc.  Phần mềm cũng là một thứ hàng hóa như những thứ hàng hoá khác và do đó phải tuân thủ nguyên tắc của kinh tế thị trường là sản phẩm phải độc lập với người sản xuất. Nghĩa là sau khi mua hàng, người mua không bị lệ thuộc vào người bán. Muốn vậy thì sản phẩm phần mềm ngoài chương trình chạy trên máy, cần có thêm các tài liệu sao cho người khác có thể tìm hiểu và bảo trì được. Vậy thì cần một ngôn ngữ, một cách trình bày chung cho các sản phẩm phần mềm. 1.3.2. Công nghệ phần mềm nhìn từ góc độ lịch sử Máy tính điện tử đầu tiên cho mục đích thương mại là máy UNIVAC-1 được sản xuất năm 1951 ở Mỹ. Từ khoảng những năm 1955 thì bắt đầu có các phần mềm, tức là các chương trình máy tính. Cho đến nay, nếu lấy phương pháp và mức độ phức tạp làm căn cứ, thì có thể chia quá trình phát triển phần mềm thành 3 giai đoạn: 1955 - 1970, 1971 - 1985, 1986 đến nay. Tất nhiên sự phân chia này chỉ là tương đối mà thôi. Đặc điểm của từng giai đoạn là: - 1955 - 1970: Tính toán và quản lý rời rạc, quản lý nhỏ. Đặc tả những yêu cầu của khách hàng lúc đó còn dùng ngôn ngữ tự nhiên thông thường. Ví dụ các câu kiểu như: tôi muốn có tệp dữ liệu chứa những thông tin về bán sản phầm như số hóa đơn, người bán, mặt hàng, Dữ liệu sẽ được nhập từ bàn phím, có kiểm tra rồi mới đưa vào tệp. Hàng tháng tôi muốn lấy thông tin về doanh thu, lãi, số hàng bán Thiết kế thời ấy không được soạn thảo ra giấy mà chỉ hình thành trong tư duy của người lập trình. Người lập trình vừa viết chương trình vừa suy nghĩ về cách tổ chức dữ liệu, cách sử dụng các thuật toán sao cho chương trình chạy tốt, đáp ứng được yêu cầu của khách hàng. Chương trình hồi đó chỉ gồm khoảng trên dưới vài trăm dòng lệnh. Phương pháp lập trình được sử dụng thời đó là lập trình tuyến tính, tức là cách viết chương trình trong đó phần lớn các lệnh được đặt theo trình tự thực hiện của chúng, nghĩa là lệnh cần thực hiện trước sẽ được viết trước, lệnh thực hiện sau được viết sau. - 1971 - 1985: Lúc này đã có nhu cầu xây dựng các phần mềm thời gian thực (nghĩa là tính toán và sử dụng ngay kết quả, ví dụ tính toán trong lò phản ứng hạt nhân phải có ngay kết quả để điều khiển kịp thời). Lúc này có nhu cầu xây dựng các mạng cục bộ và kết nối các cơ sở dữ liệu. Đặc tả thời đó chú trọng vào đặc tả đầu vào đầu ra, dữ liệu và các luồng dữ liệu (data flow). Ví dụ những tệp dữ liệu lưu trữ những thông tin gì, trong quá trình xử lý thì dữ liệu được tính toán và di chuyển ra sao. Đầu ra của tệp dữ liệu này sau khi xử lý lại có thể trở thành đầu vào của tệp khác Thiết kế thời đó chú trọng tới cấu hình hệ thống (system configuration). Vấn đề cấu trúc đối với dữ liệu và giải thuật cũng được chú ý, vì vấn đề lớn cần phải được mô tả có cấu trúc cho dễ hiểu. Các chương trình tiêu biểu thời đó có thể kể tới hệ điều hành DOS, UNIX Lúc đó cũng đã có những cơ sở dữ liệu có thể truy cập từ xa. Do nhu cầu thực tế, các ngôn ngữ lập trình ra đời giai đoạn này đã có khả năng hỗ trợ phương pháp lập trình có cấu trúc, nghĩa là chương trình được phân chia thành các chương trình con, mỗi chương trình con có tên và các chức năng xử lý riêng, có thể giao tiếp với các chương trình con khác thông qua các đối số và kiểu trả về (nếu có). - Từ 1986 đến nay: Đây là thời kỳ của máy vi tính PC, thời nối mạng tầm rộng, mạng toàn cầu Internet. Đặc tả dự án được biết nhiều là hướng đối tượng, công cụ CASE (Computer Aided Software Engineering). Trong thiết kế người ta chú ý đến môđun (module), đối tượng (object), giao thức (protocol) và giao diện (interface). Giao thức hay giao diện nói về sự trao đổi giữa các đối tượng. Khi cài đặt trên máy tính người ta thường dùng ngôn ngữ hướng đối tượng. Ngoài các phần mềm được viết theo đặt hàng, người ta chú trọng đến các phần mềm đóng gói như: Netscape, Internet Explorer, Word, Excel Ngày nay phần mềm ngày càng lớn, càng tích hợp. Phần mềm ngày nay còn được truy cập ở khắp nơi trên thế giới thông qua Internet. Người ta cho rằng việc xây dựng một phần mềm cũng cần tuân theo những nguyên tắc và kỹ luật giống như khi xây dựng một chiếc cầu hay thực hiện những công việc kỹ nghệ khác. Nếu một chiếc cầu bị lỗi khi xây dựng và do đó bị sập thì tác hại gây ra rất lớn. Một phần mềm quan trọng như phần mềm điều khiển hệ thống tên lửa đạn đạo của một nước mà có lỗi, cho kết quả tính toán sai thì hậu quả nó gây ra cũng thật là kinh khủng. Chính vì vậy một nhóm nghiên cứu của NATO trong năm 1967 đã sử dụng thuật ngữ "Software engineering". Họ muốn rằng khi xây dựng phần mềm thì các kỹ sư cũng cần áp dụng các nguyên tắc của kỹ nghệ truyền thống. Tuy nhiên, có nhiều sự khác biệt giữa sản phẩm của kỹ nghệ truyền thống và công nghệ phần mềm. Ví dụ như chiếc cầu và hệ điều hành chẳng hạn. Sự cố cầu sập rất ít khi xảy ra và nếu xảy ra thì cách khắc phục thường là xây dựng lại. Còn hệ điều hành nếu có sự cố có khi chỉ cần tắt máy khởi động lại là lại chạy tốt. Phần mềm có thể sửa lại, có khi là tới 50% để có thể chạy trên máy tính có cấu hình khác hoặc thực hiện thêm các chức năng khác. Còn chiếc cầu muốn sửa lại 50% thì rất khó, nhiều khi xây dựng mới còn dễ thực hiện hơn. 1.3.3. Từ góc độ kinh tế Trong kỹ nghệ truyền thống, khi có nhiều cách thức để sản xuất một sản phẩm nào đó, ví dụ chiết xuất dầu lửa từ than đá chẳng hạn, các kỹ sư thường chọn phương án rẻ nhất. Khi xây dựng phần mềm cũng vậy, người ta thường lựa chọn cách thức chi phí ít nhất. Một phương pháp lập trình mới có thể viết chương trình nhanh hơn, nhưng chi phí huấn luyện sử dụng và công bảo trì có thể lớn hơn khiến người ta phải cân nhắc khi lựa chọn. 1.3.4. Về vấn đề bảo trì Dãy các bước mà một phần mềm trải qua, bắt đầu từ những khảo sát ban đầu cho đến khi phần mềm không còn được sử dụng được gọi là vòng đời của phần mềm (software life cycle). Cho đến những năm 70 của thế kỷ trước, việc sản xuất một phần mềm được coi là kết quả của hai giai đoạn nối tiếp nhau: phát triển (developement) và bảo trì (maintenance). Dần dần quan điểm này trở nên không phù hợp. Ta có thể lấy một ví dụ đơn giản: phần mềm ngày nay có thể được phát triển trong một vài năm. Trong khoảng thời gian đó có thể có những phần đã hoàn thiện theo đúng thiết kế ban đầu nhưng khách hàng lại bổ sung những yêu cầu mới và phải thiết kế lại, viết lại Công việc này có thể xem là bảo trì. Có quan điểm cho rằng công việc sửa lỗi hay hiệu chỉnh những phần chương trình đã hoàn thiện theo thiết kế ban đầu thì nên coi là công việc bảo trì. Tuy nhiên cho đến nay thường người ta vẫn coi công tác bảo trì là những hoạt động sau khi phần mềm đã hoàn chỉnh và được cài đặt để sử dụng. Trong tài liệu này chủ yếu chúng ta cũng hiểu từ "bảo trì" với nghĩa như vậy. Trong những năm cuối của thập kỷ 70 của thế kỷ trước, phần lớn các công ty khi sản xuất các phần mềm đã sử dụng mô hình vòng đời phần mềm mà ngày nay người ta gọi là mô hình thác đổ (waterfall). Mô hình này bao gồm 7 giai đoạn như sau: 1. Xác định yêu cầu (Requirements phase) 2. Phân tích hay còn gọi là đặc tả (Analysis or specification phase) 3. Thiết kế (Design phase) 4. Cài đặt (Implementation phase) 5. Tích hợp (Integration phase) 6. Bảo trì (Maintenance phase) 7. Thôi sử dụng (Retirement) Trong thực tế có thể một vài pha được bỏ qua hoặc được thay thế bởi các pha khác. Ví dụ người ta hợp nhất hai pha đầu tiên thành pha hệ thống. Người ta lại cho rằng việc tích hợp phải được thực hiện trong quá trình cài đặt, cài đặt xong thì phải có một thời gian kiểm thử, và như thế mô hình gồm các giai đoạn sau: 1. Phân tích hệ thống 2. Thiết kế (kiến trúc và chi tiết) 3. Cài đặt (và tích hợp) 4. Kiểm thử 5. Bảo trì 6. Thôi sử dụng Cũng có quan điểm cho rằng thực ra kiểm tra (verify) hoặc kiểm thử (test) là công việc cần được thực hiện ở mọi nơi. Ví dụ với pha đặc tả, kiểm tra là xem xét đối chiếu xem tài liệu đặc tả đã mô tả đầy đủ và chính xác các yêu cầu khách hàng hay chưa, còn kiểm thử chính là xem xét xem từng điểm trong pha đặc tả đã được thể hiện trong các pha sau đó hay không. Vì vậy không nên tách riêng kiểm thử thành một pha. Theo quan điểm của chúng tôi thì không nên gộp hai pha yêu cầu và đặc tả. Với phần mềm lớn, nhiều người viết thì việc tích hợp là rất quan trọng và nên để riêng thành một pha, còn với phần mềm vừa và nhỏ thì nên kết hợp cài đặt và tích hợp thành một pha, trong đó bao hàm cả tích hợp, như trong bảng sau: PM nhỏ Yêu cầu Đặc tả Thiết kế Cài đặt và tích hợp Bảo trì Thôi sử dụng PM lớn Yêu cầu Đặc tả Thiết kế Cài đặt Tích hợp Bảo trì Thôi sử dụng Ý nghĩa của các pha: 1. Xác định yêu cầu: Tìm hiểu các yêu cầu của khách hàng, đưa ra các khái niệm và vấn đề. 2. Phân tích: Phân tích các yêu cầu của khách hàng. Mô tả các kết quả phân tích dưới dạng "tài liệu đặc tả". Cuối giai đoạn này là kế hoạch quản lý dự án phần mềm được đưa ra, mô tả chi tiết quá trình phát triển phần mềm. Câu hỏi mà pha này cần cho câu trả lời là: "phần mềm sẽ làm gì?" (What the product is supposed to do?). 3. Thiết kế: Pha thiết kế bao gồm hai giai đoạn nối tiếp nhau: thiết kế kiến trúc (architechtural design) và thiết kế chi tiết (detailed design). Thiết kế kiến trúc phân chia phần mềm thành các thành phần gọi là module. Thiết kế chi tiết là thiết kế từng module một cách chi tiết. Câu hỏi cần trả lời trong pha này là: phần mềm thực hiện các công việc như thế nào? (How the product is to do it?). 4. Cài đặt: Từng thành phần khác nhau được lập trình và kiểm thử. 5. Tích hợp: Các thành phần của sản phẩm được kết hợp với nhau và kiểm thử tổng thể. Sau khi những người phát triển đã kiểm thử và cho rằng tất cả các chức năng của phần mềm đã hoạt động tốt thì đến lượt khách hàng kiểm thử. Sự kiểm thử của khách hàng được gọi là kiểm thử chấp nhận (acceptance testing). Khi sự kiểm thử của khách hàng kết thúc và khách hàng vừa lòng với sản phẩm thì phần mềm được cài đặt trên máy của khách hàng. Trong thực tế thì pha tích hợp được tiến hành song song với pha cài đặt. Khi mỗi thành phần của sản phẩm được hoàn thành thì người ta tiến hành thử luôn. 6. Bảo trì: Sản phẩm được sử dụng để thực hiện các công việc đã đặt ra trước đó. Trong quá trình này có thể xẩy ra những sự cố: đó có thể là các lỗi chương trình chưa được loại trừ hết, hay kết quả không được như khách hàng mong đợi. Người ta phân chia công việc bảo trì thành hai loại: bảo trì sửa lỗi (software repair) và bảo trì cập nhật (softwair update). Trong tiếng Anh bảo trì sửa lỗi còn được gọi là corrective maintenance, bảo trì cập nhật còn được gọi là software enhancement. Bảo trì sửa lỗi như tên gọi của nó, là sửa các lỗi có thể vẫn còn xuất hiện trong khi chạy chương trình. Bảo trì cập nhật lại được chia làm hai loại: bảo trì hoàn thiện (perfective maintenance) và bảo trì thích nghi (adaptive maintenance). Bảo trì hoàn thiện là sửa đổi phần mềm theo ý khách hàng để nâng cao hiệu quả. Bảo trì thích nghi là sửa đổi để phần mềm thích nghi với môi trường mới, ví dụ sửa đổi công thức tính lương theo chính sách mới ban hành hay hiệu chỉnh để chương trình phù hợp với phiên bản mới của ngôn ngữ lập trình (Sự phân chia này cũng chỉ là tương đối mà thôi). Người ta tính toán rằng bảo trì sửa chữa và thích nghi chiếm thời gian gần bằng nhau và khoảng 20% mỗi loại, còn bảo trì hoàn thiện chiếm thời gian khoảng gấp 3 lần mỗi loại bảo trì kia (khoảng 60%). Người ta thường nghĩ rằng "sản phẩm xấu" mới phải bảo trì. Tuy nhiên thực tế thì ngược lại: "sản phẩm xấu" bị vứt vào sọt rác, còn "sản phẩm tốt" thì được hiệu chỉnh, nâng cấp và sử dụng trong nhiều năm (tức là được bảo trì). Phần mềm là mô hình của thế giới thực, mà thế giới thực thì biến đổi không ngừng, do đó phần mềm cũng phải được bảo trì thường xuyên để phản ánh đúng thế giới thực. Trong thực tế công việc bảo trì chiếm một lương thời gian và chi phí khá lớn so với các pha khác. Nếu ta gọi các pha 1-5 thành tên chung là các pha phát triển, phần còn lại là pha bảo trì thì thực tế cho thấy rằng trung bình pha bảo trì thường chiếm khoảng hai phần ba (67%) chi phí sản phẩm. Thậm chí có nhiều công ty phần chi phí cho bảo trì có thể lên tới 80%. Tỷ lệ % thời gian thực hiện các pha phát triển có thể thấy trong bảng sau: Các pha Các dự án từ 1976-1981 132 dự án gần đây của Hewlett- Packard Phân tích hệ thống 21 18 Thiết kế 18 19 Cài đặt 36 34 Tích hợp 24 29 Tổng 99 100 [...]... 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... 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... 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... 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... 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ô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... 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 1 Xác định yêu cầu 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ì?) 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ế (thiết kế kiến trúc, tức là phân chia phần mềm. .. 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... 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... 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 . 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. 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. 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 độ