Tài liệu tham khảo hỗ trợ môn học công nghệ phần mềm

Chia sẻ: Nguyen Quang Long | Ngày: | Loại File: DOC | Số trang:111

0
478
lượt xem
306
download

Tài liệu tham khảo hỗ trợ môn học công nghệ phần mềm

Mô tả tài liệu
  Download Vui lòng tải xuống để xem tài liệu đầy đủ

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ệ”.

Chủ đề:
Lưu

Nội dung Text: Tài liệu tham khảo hỗ trợ môn học công nghệ phần mềm

  1. Tài liệu tham khảo hỗ trợ môn học CÔNG NGHỆ PHẦN MỀM Hà nội, 2009
  2. 1.1. ĐÔI ĐIỀU VỀ VẤN ĐỀ THUẬT NGỮ ..........................3 1.2. CÁC ĐỊNH NGHĨA VÀ THUẬT NGỮ.............................3 1.3. PHẠM VI CỦA CÔNG NGHỆ PHẦN MỀM..........................6 2.1. MỞ ĐẦU.................................................14 2.2. KHÁCH HÀNG, NGƯỜI PHÁT TRIỂN VÀ NGƯỜI SỬ DỤNG.......14 2.3. PHA XÁC ĐỊNH YÊU CẦU....................................14 2.4. PHA ĐẶC TẢ (HAY PHÂN TÍCH).............................15 2.5. PHA THIẾT KẾ........................................... 17 2.6. PHA CÀI ĐẶT............................................ 18 2.7. PHA TÍCH HỢP........................................... 18 2.8. PHA BẢO TRÌ............................................ 19 2.9. THÔI SỬ DỤNG...........................................20 3.1. MÔ HÌNH XÂY DỰNG-VÀ-HIỆU CHỈNH (BUILD-AND-FIX MODEL). . .21 3.2. MÔ HÌNH THÁC ĐỔ (WATERFALL MODEL).....................22 3.3. MÔ HÌNH BẢN MẪU (RAPID PROTOTYPING MODEL).............23 3.4. MÔ HÌNH TĂNG DẦN (INCREMENTAL MODEL)..................25 3.5. MÔ HÌNH TĂNG DẦN ĐỒNG THỜI (CONCURRENT INCREMENTAL MODEL)...................................................... 27 3.6. MÔ HÌNH ĐỒNG BỘ-VÀ-ỔN ĐỊNH (SYNCHRONIZE-AND-STABILIZE MODEL)...................................................... 28 3.7. MÔ HÌNH XOẮN ỐC (SPIRAL MODEL)......................... 28 3.8. MÔ HÌNH HƯỚNG ĐỐI TƯỢNG (OBJECT-ORIENTED MODEL). . . .31 5.1. NẮM BẮT YÊU CẦU........................................ 32 5.2. PHÂN TÍCH YÊU CẦU...................................... 33 5.3. LÀM BẢN MẪU (PROTOTYPING).............................. 34 5.4. TÍNH THÂN THIỆN VỚI NGƯỜI DÙNG CỦA PHẦN MỀM..........34 5.5. BẢN MẪU NHƯ MỘT KỸ THUẬT ĐẶC TẢ ...................... 34 5.6. CÓ NÊN SỬ DỤNG LẠI BẢN MẪU?...........................35 5.7. SỬ DỤNG CÁC CÔNG CỤ CASE TRONG PHA YÊU CẦU ..........35 5.8. CÓ KHÁI NIỆM YÊU CẦU HƯỚNG ĐỐI TƯỢNG KHÔNG?..........36 5.9. TÓM TẲT CHƯƠNG........................................ 36 5.10. PHA YÊU CẦU: TÌM HIỂU VẤN ĐỀ AIR GOURMET ............36 6.1. TÀI LIỆU ĐẶC TẢ........................................ 39 6.2. PHÂN TÍCH HỆ THỐNG BẰNG PHƯƠNG PHÁP CẤU TRÚC..........40 6.3. PHÂN TÍCH HỆ THỐNG VỀ DỮ LIỆU......................... 49 7.1. SỰ RA ĐỜI CỦA PHƯƠNG PHÁP HƯỚNG ĐỐI TƯỢNG .........53 7.2. TỔNG QUAN VỀ NGÔN NGỮ UML ...........................53 7.3. MÔ HÌNH USE-CASE .....................................55
  3. Chương 1. Tổng quan về công nghệ phần mềm 7.4. MÔ HÌNH LỚP ........................................... 66 7.5. BIỂU ĐỒ HOẠT ĐỘNG......................................73 7.6. BIỂU ĐỒ TRẠNG THÁI..................................... 77 7.7. BIỂU ĐỒ TUẦN TỰ.......................................78 7.8. BIỂU ĐỒ CỘNG TÁC.......................................80 8.1. PHÂN TÍCH HƯỚNG ĐỐI TƯỢNG ........................... 81 8.2. QUẢN LÝ THÔNG TIN VỀ CHẾ ĐỘ ĂN ĐẶC BIỆT TRÊN MÁY BAY ..81 8.3. NHỮNG VẤN ĐỀ CẦN CHÚ Ý TRONG PHA PHÂN TÍCH.............86 9.1. THIẾT KẾ VÀ SỰ TRỪU TƯỢNG HÓA (DESIGN AND ABSTRACTION) 88 9.2. THIẾT KẾ HƯỚNG HÀNH ĐỘNG.............................. 89 9.3. PHÂN TÍCH DÒNG DỮ LIỆU................................. 89 9.4. THIẾT KẾ HƯỚNG ĐỐI TƯỢNG............................. 91 9.5. NHỮNG THÁCH THỨC TRONG PHA THIẾT KẾ HƯỚNG ĐỐI TƯỢNG . 97 9.6. THÊM MỘT SỐ GHI CHÚ VỀ VẤN ĐỀ THIẾT KẾ HƯỚNG ĐỐI TƯỢNG 97 10.1. LỰA CHỌN NGÔN NGỮ LẬP TRÌNH.......................... 98 10.2. CÁC PHƯƠNG PHÁP CÀI ĐẶT VÀ TÍCH HỢP..................99 10.3. KIỂM THỬ SẢN PHẨM PHẦN MỀM..........................100 10.4. KIỂM THỬ CHẤP NHẬN...................................101 11.1. VÌ SAO BẢO TRÌ LÀ CẦN THIẾT?.........................103 11.2. BẢO TRÌ PHẦN MỀM HƯỚNG ĐỐI TƯỢNG...................103 12.1. MỞ ĐẦU...............................................105 12.2. CÀI ĐẶT CÁC LỚP VÀ CÁC ĐỐI TƯỢNG ĐỘC LẬP ..........106 12.3. CÀI ĐẶT CÁC LỚP VÀ CÁC ĐỐI TƯỢNG CÓ TÍNH THỪA KẾ . .109 12.4. ĐÔI LỜI KẾT LUẬN.....................................110 2
  4. Chương 1. Tổng quan về công nghệ phần mềm 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 ừ 3
  5. Chương 1. Tổng quan về công nghệ phần mềm 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 4
  6. Chương 1. Tổng quan về công nghệ phần mềm 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 5
  7. Chương 1. Tổng quan về công nghệ phần mềm 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 6
  8. Chương 1. Tổng quan về công nghệ phần mềm 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 7
  9. Chương 1. Tổng quan về công nghệ phần mềm 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 ả 8
  10. Chương 1. Tổng quan về công nghệ phần mềm 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 Thiết Cài đặt và tích hợp Bảo trì Thôi sử dụng tả kế PM lớn Yêu cầu Đặ c Thiết Cài đặt Tích hợp Bảo trì Thôi sử dụng tả kế Ý nghĩa của các pha: 1. Xác định yêu cầu: Tìm hiểu các yêu cầu c ủa khách hàng, đưa ra các khái ni ệm và v ấn đề. 2. Phân tích: Phân tích các yêu cầu c ủa khách hàng. Mô tả các k ết qu ả phân tích d ưới d ạng "tài liệu đặc tả". Cuối giai đoạn này là kế ho ạch qu ản lý dự án ph ần m ềm đ ược đ ưa ra, mô tả 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 9
  11. Chương 1. Tổng quan về công nghệ phần mềm 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: 132 dự án gần đây của Hewlett- Các pha Các dự án từ 1976-1981 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, 10
  12. Chương 1. Tổng quan về công nghệ phần mềm 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 ư. 11
  13. Chương 1. Tổng quan về công nghệ phần mềm 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: thông báo thông gửi rút báo tiền tiền gửi rút tiền số dư số dư tài tài khoản khoản tính số tính số dư tài khoản thông báo (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 1. Xác định yêu cầu 2. Phân tích (xác định phần mềm làm 2. Phân tích hướng đối tượng (xác định phần gì?) mềm làm gì, phần mềm gồm các đối tượng nào?) 12
  14. Chương 1. Tổng quan về công nghệ phần mềm 3. Thiết kế (thiết kế kiến trúc, tức là 3. Thiết kế hướng đối tượng (thiết kế chi phân chia phần mềm thành các tiết các đối tượng) module, và thiết kế chi tiết, tức là thiết kế chi tiết các module) 4. Cài đặt (viết chương trình) 4. Lập trình hướng đối tượng 5. Tích hợp 5. Tích hợp 6. Bảo trì 6. Bảo trì 7. Thôi sử dụng 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. 13
  15. CHƯƠNG 2. QUY TRÌNH LÀM PHẦN MỀM 2.1. MỞ ĐẦU Quy trình làm phần mềm (hay gọi đơn gi ản theo tiếng Anh: software process - quy trình phần mềm) là quá trình tạo ra phần mềm. Quy trình này là sự kết hợp mô hình vòng đời phần mềm, các công cụ được sử dụng và quan trọng hơn hết, là những người xây dựng nên phần mềm đó. Các công ty phần mềm khác nhau có các quy trình ph ần m ềm khác nhau. Ví dụ hãy xem vấn đề tài liệu. Có một số công ty cho rằng chính b ản thân ph ần m ềm v ới các mã nguồn là tài liệu về phần mềm. Họ cho rằng phần mềm có th ể hi ểu đ ược b ằng cách đ ọc các mã nguồn này. Một số công ty khác chu ẩn b ị tài li ệu r ất chi ti ết. Ngay c ả khi ph ần m ềm đã cài đặt cho khách hàng và chuyển sang giai đo ạn b ảo trì, thì m ọi s ự s ửa đ ổi ph ần m ềm cũng được ghi chép lại, các bản thiết kế cũng được thay đổi cho phù h ợp. T ừ th ực t ế có th ể thấy rằng một phần mềm được kiểm thử kỹ lưỡng và có các tài li ệu báo cáo đ ầy đ ủ trong từng pha thì chất lượng sẽ tốt hơn và công vi ệc b ảo trì cũng thu ận l ợi h ơn. Nói chung, một quy trình phần mềm thường trải qua 7 pha: xác đ ịnh yêu c ầu, phân tích, thiết kế, cài đặt, tích hợp, bảo trì và thôi sử dụng. Trong m ột s ố tr ường h ợp thì tên các pha này có thể khác. Ví dụ người ta hợp nhất hai pha xác đ ịnh yêu c ầu và phân tích thành pha phân tích hệ thống. Một vài pha khác lại được chia nhỏ hơn, ví dụ pha thiết k ế đ ược chia thành pha thiết kế kiến trúc và thiết kế chi tiết . Hai pha cài đặt và tích hợp được kết hợp thành pha cài đặt và tích hợp . Những lý do sau đây trả lời câu hỏi vì sao các pha c ủa vòng đời phần mềm cần được kiểm thử kỹ và báo cáo thành tài li ệu chi ti ết bởi nhóm th ực hi ện trước khi tiến hành các pha tiếp theo: - Vì sự thúc ép về thời gian hoàn thành nên những phần tài liệu bị trì hoãn thường ít khi được tiếp tục hoàn thiện. - Trách nhiệm về một pha nào đó có thể được chuyển giao cho nhóm khác thậm chí ở một công ty phần mềm khác. - Phần mềm thường liên tục thay đổi trong quá trình xây dựng . Ví dụ thiết kế có thể bị thay đổi trong pha cài đặt. Rõ ràng nếu tài liệu thiết k ế được biên so ạn đ ầy đ ủ thì s ự s ửa đ ổi sẽ thuận lợi hơn. 2.2. KHÁCH HÀNG, NGƯỜI PHÁT TRIỂN VÀ NGƯỜI SỬ DỤNG (Client, developer, and user) Khách hàng là cá nhân hoặc công ty có nhu c ầu s ử d ụng ph ần m ềm. Những người phát triển là những người nhận trách nhi ệm xây d ựng ph ần m ềm do khách hàng yêu cầu. Người sử dụng là người trực tiếp sử dụng phần mềm khi nó được cài đ ặt cho khách hàng. Khách hàng, người phát triển và người sử dụng có thể ở các công ty khác nhau ho ặc ở ngay trong một công ty. Cũng có khi họ là những người lao đ ộng t ự do. Th ường thì khách hàng và người sử dụng ở cùng một công ty, còn những người phát tri ển là thành viên c ủa m ột công ty phần mềm nào đó. Nếu xét về mặt giá cả thì người ta phân các ph ần m ềm thành hai lo ại: phần mềm được xây dựng cho một khách hàng thường có giá cao, và phần mềm đóng gói được bán cho nhiều khách hàng ví dụ như Microsoft Word, Microsoft Excel...th ường có giá rẻ hơn. 2.3. PHA XÁC ĐỊNH YÊU CẦU 2.3.1. Giới thiệu Trong những lần gặp đầu tiên giữa khách hàng và người phát tri ển, khách hàng phác th ảo các yêu cầu, chức năng, các công vi ệc c ần th ực hi ện c ủa ph ần m ềm mà h ọ mu ốn đ ặt hàng. Theo cách nhìn nhận của người phát triển thì những điều khách hàng mô tả có thể mơ hồ, có những điều không hợp lý, thậm chí mâu thuẫn hay không khả thi . Nhiệm vụ của người phát triển là phải tìm hiểu xem thực chất khách hàng cần gì. Ngoài những yêu cầu về chức năng
  16. Chương 2. Quy trình làm phần mềm 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 15
  17. Chương 2. Quy trình làm phần mềm 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 16
  18. Chương 2. Quy trình làm phần mềm 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 17
  19. Chương 2. Quy trình làm phần mềm 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ả. 18
  20. Chương 2. Quy trình làm phần mềm 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). 19
Đồng bộ tài khoản