Tài liệu Nghiên cứu các độ đo phần mềm và một số triển khai, đánh giá

L¦¥NG THANH B×nh bé gi¸o dôc vµ ®µo t¹o tr­êng ®¹i häc b¸ch khoa hµ néi --------------------------------------- luËn v¨n th¹c sÜ khoa häc c«ng nghÖ TH¤NG häc ngµnh : c«ng nghÖ TH¤NG TIN NGHIÊN CỨU CÁC ĐỘ ĐO PHẦN MỀM VÀ MỘT SỐ TRIỂN KHAI, ĐÁNH GIÁ L¦¥NG THANH BÌNH 2005 - 2007 Hà Nội 2007 Hµ Néi 2007 LuËn v¨n tèt nghiÖp CNTT 2005-2007 2 Mục lục Mục lục ................................................................................................................... 2 Danh mục hình vẽ .................................................................................................. 5 Danh mục bảng....................................................................................................... 7 Danh mục từ viết tắt ............................................................................................... 8 LỜI GIỚI THIỆU ................................................................................................. 10 CHƯƠNG 1: TỔNG QUAN VỀ CHẤT LƯỢNG PHẦN MỀM VÀ ĐỘ ĐO CHẤT LƯỢNG PHẦN MỀM ............................................................................. 13 1.1. Chất lượng phần mềm ............................................................................ 13 1.1.1. Chất lượng-những quan điểm chung ............................................... 13 1.1.2. Định nghĩa ....................................................................................... 15 1.1.3. Đánh giá kiến trúc phần mềm.......................................................... 18 1.1.4. Các chuẩn chất lượng phần mềm .................................................... 19 1.2. Tại sao cần độ đo phần mềm .................................................................. 22 1.3. Độ đo phần mềm .................................................................................... 25 1.3.1. Định nghĩa độ đo phần mềm ........................................................... 25 1.3.2. Phân loại các thang đo ..................................................................... 26 1.3.3. Lịch sử ............................................................................................. 28 1.3.4. Hướng nghiên cứu trong tương lai .................................................. 30 1.4. Khảo sát hiện trạng sử dụng độ đo phần mềm ở Việt Nam .................. 31 1.5. Kết chương ............................................................................................. 33 CHƯƠNG 2: ĐỘ ĐO CHO MẪU THIẾT KẾ .................................................... 34 2.1. Công nghệ phần mềm dựa theo thành phần ........................................... 34 2.2. Mẫu thiết kế ............................................................................................ 35 L­¬ng Thanh B×nh 2 LuËn v¨n tèt nghiÖp CNTT 2005-2007 2.3. 3 Mẫu thiết kế trong kiến trúc phần mềm ................................................. 37 2.4. Các mẫu thiết kế cơ sở của GoF ................................................................ 46 2.4.1. Creational Patterns........................................................................... 46 2.4.2. Structural Patterns ........................................................................... 51 2.4.3. Behavioral pattern ........................................................................... 56 2.5. Các độ đo hướng đối tượng gốc ................................................................ 63 2.5.1. Các độ đo hướng đối tượng cơ sở ....................................................... 63 2.5.2. Các độ đo dựa theo thành phần ........................................................... 65 2.6. Kết chương................................................................................................. 68 CHƯƠNG 3 : ĐÁNH GIÁ KIẾN TRÚC PHẦN MỀM DỰA TRÊN MẪU THIẾT KẾ ............................................................................................................ 69 3.1. Một số nghiên cứu về độ đo cho mẫu thiết kế ........................................... 69 3.2. Nhu cầu sử dụng các mẫu phức hợp .......................................................... 72 3.2. Nền tảng và những nghiên cứu liên quan .................................................. 74 3.3. Phương pháp được đề xuất ........................................................................ 77 3.4. Kết chương................................................................................................. 90 CHƯƠNG 4. THỬ NGHIỆM VÀ ĐÁNH GIÁ .................................................. 91 4.1. Giới thiệu chung ........................................................................................ 91 4.2. Chức năng .................................................................................................. 93 4.3. Thử nghiệm công cụ ................................................................................ 101 4.4. Kết chương............................................................................................... 103 CHƯƠNG 5: KẾT LUẬN ................................................................................. 105 5.1. Đánh giá kết quả đạt được của luận văn .................................................. 105 5.2. Hướng phát triển của luận văn ................................................................. 106 Danh mục tham khảo ......................................................................................... 108 L­¬ng Thanh B×nh 3 LuËn v¨n tèt nghiÖp CNTT 2005-2007 4 PHỤ LỤC: QUY TRÌNH ĐỘ ĐO ..................................................................... 113 1. Ý nghĩa của quy trình độ đo..................................................................... 113 2. Quy trình độ đo 8 bước [SPC05] ............................................................... 113 L­¬ng Thanh B×nh 4 LuËn v¨n tèt nghiÖp CNTT 2005-2007 5 Danh mục hình vẽ Hình 1.1: Quan hệ giữa yêu cầu và các đặc tính chất lượng................................ 16 Hình 1.2: Thế nào là độ đo phần mềm ................................................................. 25 Hình 2.1: Hai mẫu thiết kế cửa ra vào ................................................................. 35 Hình 2.2: Các thành phần trong kiến trúc phần mềm .......................................... 38 Hình 2.3: Quan hệ tĩnh trong OMT...................................................................... 39 Hình 2.4: Khung nhìn trong kiến trúc phần mềm ................................................ 39 Hình 2.5: Mô hình Abstract Factory Pattern ........................................................ 47 Hình 2.6: Mô hình Builder pattern ....................................................................... 48 Hình 2.7: Mô hình Factory Method Pattern ......................................................... 49 Hình 2.8: Mô hình Prototype Pattern ................................................................... 50 Hình 2.9: Mô hình Singleton Pattern ................................................................... 51 Hình 2.10: Mô hình Adapter Pattern .................................................................... 52 Hình 2.11: Mô hình Bridge Pattern ...................................................................... 52 Hình 2.12: Mô hình Composite Pattern ............................................................... 53 Hình 2.13: Mô hình Façade Pattern ..................................................................... 54 Hình 2.14: Mô hình Proxy Pattern ....................................................................... 54 Hình 2.15: Mô hình Decorator Pattern................................................................. 55 Hình 2.16: Mô hình Flyweight ............................................................................. 56 Hình 2.17: Mô hình State Pattern......................................................................... 57 Hình 2.18: Mô hình Strategy Pattern ................................................................... 57 Hình 2.19: Mô hình Template Method Pattern .................................................... 58 Hình 2.20: Mô hình Visistor Pattern .................................................................... 58 Hình 2.21: Mô hình Chain of Responsibility Pattern .......................................... 59 L­¬ng Thanh B×nh 5 LuËn v¨n tèt nghiÖp CNTT 2005-2007 6 Hình 2.22: Mô hình Iterator Pattern ..................................................................... 60 Hình 2.23: Mô hình Mediator Pattern .................................................................. 60 Hình 2.24: Mô hình Mementor Pattern ................................................................ 61 Hình 2.25: Mô hình Observer Pattern .................................................................. 61 Hình 2.26: Mô hình Command Pattern ................................................................ 62 Hình 2.27: Mô hình Command Pattern ................................................................ 63 Hình 3.1: Các pha trong quá trình xác định một mẫu phức hợp .......................... 79 Hình 3.2: Thiết kế mẫu (MVC) ............................................................................ 84 Hình 3.3: Biểu diễn đồ họa của các mức chồng mẫu........................................... 88 Hình 4.1: Mô hình hoạt động của PM4J .............................................................. 92 Hình 4.2: Giao diện PM4J .................................................................................... 94 Hình 4.3: Chức năng phân tích trong PM4J......................................................... 95 Hình 4.4: Các độ đo hướng đối tượng cho class .................................................. 97 Hình 4.5: Các độ đo hướng đối tượng cho thành phần ........................................ 98 Hình 4.6: Chức năng đo cho mẫu thiết kế............................................................ 99 Hình 4.7: Các độ đo độ phủ mẫu ....................................................................... 100 Hình 4.8: Các độ đo độ chồng mẫu .................................................................... 101 Hình 4.9: Thiết kế thử nghiệm BoF ................................................................... 101 Hình 4.10: Phân tích các thành phần trong BoF ................................................ 102 Bảng 4.4: Giá trị phủ mẫu cho BoF ................................................................... 103 Bảng 4.4: Giá trị phủ mẫu cho BoF ................................................................... 103 L­¬ng Thanh B×nh 6 LuËn v¨n tèt nghiÖp CNTT 2005-2007 7 Danh mục bảng Bảng 3.1: Các giá trị độ phủ................................................................................. 84 Bảng 3.2: Các giá trị độ chồng mẫu cho thiết kế mẫu ......................................... 86 Bảng 3.3: Các thành tố chồng mẫu ...................................................................... 87 L­¬ng Thanh B×nh 7 LuËn v¨n tèt nghiÖp CNTT 2005-2007 Danh mục từ viết tắt STT Từ viết tắt 1 BoF 8 Từ đầy đủ Bill of Material Factory Giải thích Mẫu thiết kế của người thử nghiệm 2 CBO Coupling between object classes Tính ghép cặp giữa hai lớp đối tượng 3 DIT Depth of Inheritance Tree Độ sâu cây thừa kế 4 EXTCBO Coupling between object classes Tính ghép cặp mở rộng External giữa hai lớp đối tượng 5 FP Function Point Điểm hàm 6 GoF Gang of Four Nhóm tác giả 23 mẫu thiết kế phần mềm cơ sở 7 GQM Goal/Question/Metric Mục đích/Câu hỏi/Độ đo 8 9 10 IEEE ISO LCOM Institute of Electrical and Viện kỹ thuật điện và Electronic Engineers điện tử Hoa Kỳ International Standard Tổ chức Chuẩn hóa Organization quốc tế Lack of cohesion in methods Thiếu độ gắn kết giữa các phương thức 11 LOC Line of Code Số dòng mã nguồn 12 MVC Model View Controller Mẫu thiết kế phần mềm tương tác L­¬ng Thanh B×nh 8 LuËn v¨n tèt nghiÖp CNTT 2005-2007 13 NASA 9 National Aeronautics and Space Cơ quan Hàng không Administration và Vũ trụ Hoa Kỳ 14 NC Number of Classes Số lớp 15 NOC Number of Children Số thành phần con 16 NOM Number of methods Số Phương thức 17 OMT Object Modeling Technique Kỹ thuật Mô hình hóa 18 RFC Response for a class Đáp ứng của một lớp 19 RFCOM Response Set for a Component Tập đáp ứng của một thành phần 20 RTTI RuntimeIdentifier Thời gian thực thi 21 SDC Software Development Cost Mô hình đánh giá chi phí phát triển phần mềm 22 SEl Software Engineering laboratory Phòng thí nghiệm Công nghệ phần mềm 23 SLOC Source Line of Code Số dòng mã nguồn 24 TQM Total Quality Management Quản lý Chất lượng toàn cục 25 UML Unified Modeling Language Ngôn ngữ Mô hình hóa 26 WCC Weighted classes per component Lớp có trọng số cho mỗi thành phần 27 WMC Weigthed methods per class Phương thức có trọng số cho mỗi lớp L­¬ng Thanh B×nh 9 LuËn v¨n tèt nghiÖp CNTT 2005-2007 10 LỜI GIỚI THIỆU Hiện nay, phần mềm đã trở thành một yếu tố không thể thiếu được trong đời sống con người với rất nhiều lĩnh vực ứng dụng như ngân hàng, tài chính, truyền thông, khám phá, nghiên cứu khoa học, giải trí,…, nhu cầu về các biện pháp, công cụ để đánh giá chính xác, liên tục và có thể dự đoán tiến trình phát triển phần mềm và sản phẩm phần mềm ngày càng trở nên gắt gao. Trong khi đó, giới chuyên môn từ lâu đã thừa nhận rằng chất lượng của một hệ thống phần mềm cần được đảm bảo ngay từ những pha đầu trong vòng đời phần mềm. Với nhận thức như vậy, pha thiết kế phần mềm, là cầu nối giữa các yêu cầu phi hình thức, mang tính chủ quan cao của người dùng và hoạt động triển khai mang tính hình thức, đúng đắn; đây là giai đoạn tự nhiên nhất để đảm bảo chất lượng một cách hiệu quả. Sản phẩm của pha thiết kế này là một kiến trúc phần mềm mô tả các thành phần chức năng của hệ thống phần mềm và mối quan hệ giữa các thành phần này. Vì lẽ đó, chủ đề xác định chất lượng phần mềm dựa trên phân tích thiết kế phần mềm ngày càng được quan tâm nhiều. Mặt khác, những lớp phổ biến nhất trong các thành phần - mẫu thiết kế - là những lớp mô tả các giải pháp kỹ thuật cho phép tái sử dụng và mở rộng được cho những vấn đề thiết kế phổ biến theo một khuôn dạng hướng đối tượng chuẩn. Đây là một công cụ thiết kế mạnh nhờ khả năng cho phép nhúng dưới dạng những biến thể của phần mềm hoặc kết hợp với những thay đổi trong kiến trúc phần mềm. Kỹ nghệ sử dụng mẫu thiết kế ngày càng hoàn thiện nên mẫu thiết kế cũng dần chiếm một vị trí quan trọng trong chất lượng thiết kế. Ngoài ra, mẫu thiết kế còn cho phép dự đoán chất lượng của một hệ thống phần mềm từ kiến trúc của hệ thống đó mà có chứa các L­¬ng Thanh B×nh 10 LuËn v¨n tèt nghiÖp CNTT 2005-2007 11 mẫu thiết kế. Do vậy, luận văn này tập trung vào vấn đề xác định chất lượng kiến trúc phần mềm phổ biến dựa trên các mẫu thiết kế trong kiến trúc phần mềm. Bố cục luận văn gồm 4 chương như sau : 1. Chương 1 : Tổng quan về chất lượng phần mềm và độ đo chất lượng phần mềm. 2. Chương 2 : Độ đo cho mẫu thiết kế 3. Chương 3 : Đánh giá kiến trúc phần mềm dựa trên mẫu thiết kế 4. Chương 4 : Thử nghiệm và đánh giá 5. Kết luận Đề hoàn thành luận văn này, tôi xin bày tỏ lòng biết ơn sâu sắc tới tập thể các thầy giáo, cô giáo trường Đại học Bách Khoa Hà Nội nói chung và khoa Công nghệ thông tin nói riêng đã tận tình giảng dạy truyền đạt cho tôi những kiến thức, kinh nghiệm, quý báu trong suốt những năm vừa qua. Tôi xin chân thành cảm ơn thầy giáo PGS. TS. Nguyễn Ngọc Bình, trường Đại học Công nghệ-Đại học Quốc Gia Hà nội đã khuyến khích, động viên, góp ý và hướng dẫn tôi rất tận tình trong suốt quá trình thực hiện luận văn. Và tôi cũng bày tỏ lòng biết ơn đối với tất cả các bạn bè, đồng nghiệp và người thân đã động viên, hỗ trợ tôi để tôi có thể hoàn thành luận văn này. Tuy nhiên, trong quá trình làm luận văn, dù đã cố gắng thực hiện nhưng do kinh nghiệm còn ít, thời gian nghiên cứu hạn chế nên chắc chắn không tránh khỏi thiếu sót, rất mong được sự giúp đỡ và góp ý của Quý thầy cô, và đồng nghiệp để luận văn này có thể phát triển một cách hoàn thiện hơn. L­¬ng Thanh B×nh 11 LuËn v¨n tèt nghiÖp CNTT 2005-2007 12 Hà nội ngày 8 tháng 11 năm 2007. Học viên Lương Thanh Bình L­¬ng Thanh B×nh 12 LuËn v¨n tèt nghiÖp CNTT 2005-2007 13 CHƯƠNG 1: TỔNG QUAN VỀ CHẤT LƯỢNG PHẦN MỀM VÀ ĐỘ ĐO CHẤT LƯỢNG PHẦN MỀM 1.1. Chất lượng phần mềm 1.1.1. Chất lượng-những quan điểm chung  Quan điểm phổ biến: Có nhiều quan điểm về chất lượng nhưng đa số đều đồng ý rằng đây là một đối tượng không thể nắm bắt được: ta có thể nói đến chất lượng, nhận xét về chất lượng nhưng không thể đo được hoặc nói cách khác, không lượng hóa được chất lượng. Với nhiều người, chất lượng là những đánh giá chung chung: chất lượng tốt, chất lượng tồi hoặc chất lượng tạm được… những thuật ngữ hay được sử dụng để nói về một đối tượng mập mờ không định nghĩa được hoặc khó định nghĩa. Quan điểm này phản ánh thực tế là con người nhận thức và diễn đạt chất lượng theo nhiều cách khi không thể quản lý, điều khiển hoặc định lượng được chất lượng. Quan điểm này đối lập hẳn với quan điểm nhà nghề trong kỷ luật của kỹ nghệ chất lượng rằng chất lượng có thể và cần được định nghĩa, đo đạc, giám sát, quản lý và cải thiện. Một quan điểm khá phổ biến khác coi chất lượng là sự xa xỉ và đẳng cấp. Theo đó, những sản phẩm đắt tiền, xa hoa sẽ có chất lượng cao hơn những sản phẩm xoàng xĩnh. Và do đó, một chiếc Lexus sẽ là một chiếc xe chất lượng nhưng Matiz thì không mà không cần xét tới các yếu tố về độ tin cậy cũng như đối sánh các thuộc tính giữa chúng. Nói một cách đơn giản, chất lượng chỉ thuộc về những sản phẩm đắt tiền với những chức năng kiểu cách còn những sản phẩm rẻ tiền khó có thể coi là chất lượng.  Quan điểm chuyên môn: L­¬ng Thanh B×nh 13 LuËn v¨n tèt nghiÖp CNTT 2005-2007 14 Những nhận thức sai xuất phát từ những quan niệm như trên sẽ không giúp cải thiện chất lượng trong các ngành công nghiệp. Vì vậy, trước tiên cần hiểu đúng thế nào là chất lượng? Crosby (1979) [Cro79] định nghĩa chất lượng là “sự tuân thủ các yêu cầu”, Juran và Gryna [JUG70] định nghĩa chất lượng là “sự phù hợp với hoạt động sử dụng”. Có thể thấy hai định nghĩa này về cơ bản có tính tương đồng và nhất quán với nhau. Hiện tại, nhiều tổ chức, công ty đã chấp nhận và sử dụng cả hai định nghĩa: • sự tuân thủ các yêu cầu: với các yêu cầu được phát biểu một cách tường minh để không bị hiểu sai. Khi đó, tiến trình phát triển và sản xuất thường xuyên thực hiện các phép đo nhằm xác định độ tuân thủ theo các yêu cầu. Trong quá trình này, những chi tiết không tuân thủ bị coi là khiếm khuyếtsụt giảm chất lượng. Như vậy, nếu một chiếc Lexus đảm bảo được tất cả các yêu cầu cho một chiếc Lexus, đó sẽ là một chiếc ô tô chất lượng. Và, nếu một chiếc Matiz đảm bảo được tất cả các yêu cầu cho một chiếc Matiz, đó cũng là một chiếc ô tô chất lượng. Hai loại ô tô này khác nhau về chủng loại, hiệu năng, và tính kinh tế nhưng do được đo trên các tiêu chuẩn tương ứng nên cùng là những chiếc ô tô chất lượng. • sự phù hợp với hoạt động sử dụng: cách định nghĩa này xét tới yêu cầu và sự kỳ vọng từ phía khách hàng có nghĩa là các sản phẩm hoặc các dịch vụ liệu có phù hợp với sự đa dạng trong nhu cầu sử dụng của khách hàng. Theo Juran, hai thông số quan trọng nhất của sự phù hợp với hoạt động sử dụng là chất lượng thiết kế và chất lượng tuân thủ. Quan điểm chất lượng từ phía khách hàng Xét từ phía khách hàng, chất lượng là giá trị thu nhận được từ sản phẩm mua  về, dựa trên rất nhiều yếu tố như giá cả, hiệu năng, tính tin cậy, độ thỏa mãn. L­¬ng Thanh B×nh 14 LuËn v¨n tèt nghiÖp CNTT 2005-2007 15 Trong đó, mức độ thỏa mãn sau khi mua sản phẩm là tiêu chí xét duyệt chất lượng quan trọng nhất để biết sản phẩm tuân thủ các yêu cầu và phù hợp với mục đích sử dụng. Với hai nhận thức về chất lượng như trên nên trong thực tế, định nghĩa chất lượng thường có hai cung bậc: • định nghĩa chất lượng nội tại thường gắn với tỉ suất sai sót và độ tin cậy. Định nghĩa hẹp này thường được gọi là “q nhỏ”-“small q” ( q: qualitychất lượng). • định nghĩa rộng hơn: gồm chất lượng sản phẩm, chất lượng tiến trình và sự thỏa mãn của khách hàng, được gọi là “Q lớn”-“big-Q”. Hai mức định nghĩa trên hiện được dùng trong rất nhiều ngành công nghiệp. Trong phạm vi luận văn này, tác giả chỉ xét định nghĩa chất lượng theo mức rộng “big-Q”. Từ hai mức chất lượng, đã hình thành một chu trình lặp khép kín trong sản xuất phần mềm: nhu cầu và mong muốn của khách hàng  yêu cầu và đặc tả  sản phẩm được thiết kế, phát triển theo yêu cầu với sự tập trung liên tục vào cải thiện quy trình chất lượng sản phẩm hoàn hảo, cộng thêm quá trình phân phối và dịch vụ tốt  sự thỏa mãn tuyệt đối của khách hàng. Tuy nhiên, quá trình này không phải lúc nào cũng đúng đặc biệt là trước thời điểm những năm cuối của thập kỷ 1980, thời điểm khởi thủy cho khái niệm chất lượng theo quan điểm hiện đại. 1.1.2. Định nghĩa Mỗi nhà phát triển đều có một ý tưởng riêng về chất lượng nên bước đầu tiên trong một dự án phát triển phần mềm là nêu rõ mối quan hệ giữa yêu cầu, đặc tính phần mềm và chất lượng phần mềm để xác định các chỉ tiêu chất lượng của L­¬ng Thanh B×nh 15 LuËn v¨n tèt nghiÖp CNTT 2005-2007 16 phần mềm. Hình 1.1 minh họa một sản phẩm phần mềm đáp ứng những yêu cầu xác định để có được những đặc tính phù hợp. sản phẩm phần mềm Q Q phải đáp ứng có liên quan tới yêu cầu (giúp đáp ứng) đặc tính Hình 1.1: Quan hệ giữa yêu cầu và các đặc tính chất lượng Trong phần mềm, nghĩa hẹp nhất của chất lượng sản phẩm thường được hiểu là sản phẩm “không có lỗi”, là ý nghĩa cơ bản nhất của việc tuân thủ các yêu cầu. Định nghĩa chất lượng phần mềm thường dựa trên một số đặc tính chất lượng. nên các đặc tính này thường được tính đến khi lập kế hoạch và thiết kế phần mềm tuy không phải lúc nào chúng cũng tương hợp với nhau. Ví dụ, càng nhiều chức năng (độ phức tạp càng lớn), phần mềm càng khó bảo trì. Tùy thuộc vào loại phần mềm và khách hàng mà ta dành sự quan tâm khác nhau cho các đặc tính chất lượng phân biệt. Nhằm cải thiện chất lượng trong tiến trình phát triển, người ta đã đưa ra những mô hình tiến trình phát triển phần mềm với những định hướng, giải pháp cụ thể cùng những công cụ và kỹ thuật thích hợp. Các đặc tính và các tham số chất lượng của tiến trình phát triển theo pha cũng như sản phẩm đầu ra của từng pha sẽ được đo đạc, giám sát để đảm bảo tiến trình phát triển và các sản phẩm L­¬ng Thanh B×nh 16 LuËn v¨n tèt nghiÖp CNTT 2005-2007 17 của từng pha vẫn nằm trong tầm điều khiển và đang hướng tới những mục tiêu chất lượng. Tuy nhiên, luận văn này không tập trung nghiên cứu độ đo chất lượng trên cơ sở quy trình mà sẽ hướng đến độ đo chất lượng cho sản phẩm phần mềm mà cụ thể là sản phẩm của pha thiết kế phần mềm. Từ các khía cạnh liên quan trình bày ở trên, ta có định nghĩa về chất lượng phần mềm: “Chất lượng phần mềm được coi là sự tuân thủ những yêu cầu về mặt chức năng và hiệu năng đã được xác định một cách rõ ràng, những chuẩn phát triển được tài liệu hóa và những đặc tính ngầm định.” Trong đó: • Các yêu cầu phần mềm là nền tảng để đo đạc chất lượng. • Các chuẩn định nghĩa các tiêu chí phát triển, là dẫn hướng cho cách xây dựng phần mềm. • Các yêu cầu ngầm định giúp phần mềm đạt được chất lượng hoàn hảo. Tồn tại hai mức chất lượng phần mềm: • Chất lượng phần mềm nội tại-Internal software quality: là phần ẩn của tảng băng, ví dụ cấu trúc chương trình, kiểu viết mã nguồn, khả năng bảo trì, sự thông thạo chuyên môn... Phần chất lượng này chỉ dành cho phía nhà phát triển. Khi chất lượng nội tại không đạt yêu cầu sẽ tiêu tốn nhiều thời gian phát triển, gây ra các lỗi dây chuyền và mất nhiều thời gian kiểm thử. Xét từ quan điểm thương trường, chất lượng nội tại không tốt sẽ làm suy giảm nghiêm trọng tới uy tín và khả năng cạnh tranh của công ty. • Chất lượng phần mềm bên ngoài-External software quality: là phần chất lượng mà khách hàng thấy được và có thể kiểm thử theo những phương pháp truyền thống. Khi chất lượng phần mềm bên ngoài không đạt yêu cầu L­¬ng Thanh B×nh 17 LuËn v¨n tèt nghiÖp CNTT 2005-2007 18 có thể xảy ra những hiện tượng như: sập hệ thống, không xử lý hoặc xử lý sai dữ liệu/lệnh đưa vào, sai lệch dữ liệu, tốc độ chậm… Chất lượng bên ngoài thường là kết quả của chất lượng nội tại. Chất lượng nội tại nghèo nàn sẽ dẫn đến chi phí bảo trì cao. Do đó, để nâng cao được chất lượng phần mềm cần nâng cao chất lượng nội tại. 1.1.3. Đánh giá kiến trúc phần mềm Một nguyên lý đã được chấp nhận lâu nay trong công nghệ phần mềm là chất lượng của một hệ thống phần mềm cần được đảm bảo ngay từ những pha đầu trong vòng đời phần mềm. Các phương pháp bảo đảm chất lượng sẽ đặc biệt hiệu quả khi nắm bắt được các yêu cầu của hệ thống và không còn nhiều hiệu quả khi hệ thống đã đưa vào vận hành. Nhưng điều bất lợi là ta không thể áp dụng các phương pháp bảo đảm chất lượng ngay trong những pha phát triển đầu tiên nếu chỉ dựa vào những tài liệu ghi chép thông thường. Trong khi đó, những phương pháp có mức tự động hóa cao (như kiểm thử) chỉ được áp dụng về sau khi mà chi phí chỉnh sửa sẽ tương đối tốn kém. Pha thiết kế phần mềm được coi là cầu nối giữa các yêu cầu phi hình thức, mang tính chủ quan cao của người dùng và hoạt động triển khai mang tính hình thức, đúng đắn; đây là giai đoạn tự nhiên nhất để đảm bảo chất lượng một cách hiệu quả. Mặt khác, thiết kế phần mềm là một trong những pha của hoạt động phát triển phần mềm mà nhà thiết kế vẫn làm việc ở một mức trừu tượng cao mà chưa đi sâu vào chi tiết. Sản phẩm của pha thiết kế này là một kiến trúc phần mềm mô tả các thành phần chức năng của hệ thống phần mềm và mối quan hệ giữa các thành phần này. Trong những năm gần đây, kiến trúc phần mềm ngày càng được coi trọng, trở thành yếu tố nền móng trong chất lượng phần mềm. L­¬ng Thanh B×nh 18 LuËn v¨n tèt nghiÖp CNTT 2005-2007 19 Vì lẽ đó, chủ đề xác định chất lượng phần mềm dựa trên phân tích thiết kế phần mềm ngày càng được quan tâm nhiều. Đặc biệt khi mà cộng đồng hướng đối tượng đã xử lý được những bài toán thường xuyên xuất hiện bằng cách tập hợp và chuẩn hóa những thành phần hay được sử dụng trong những bài toán này. Khi đó, những lớp phổ biến nhất trong các thành phần được gọi là mẫu thiết kế [LPR98], các lớp đó mô tả các giải pháp kỹ thuật cho phép tái sử dụng và mở rộng được cho những vấn đề thiết kế phổ biến theo một khuôn dạng hướng đối tượng chuẩn. Ý tưởng chung của mẫu thiết kế là áp dụng một giải pháp thiết kế dưới một hình thức tường minh để áp dụng được vào một hoàn cảnh cụ thể mà vẫn cho phép phân tích được ưu điểm và nhược điểm của giải pháp. Có thể tìm thấy các mẫu trong các hệ thống đã có hoặc có thể tạo mới mẫu từ đầu. Yếu tố khiến mẫu thiết kế trở thành một công cụ thiết kế mạnh là nhờ khả năng của mẫu thiết kế cho phép nhúng dưới dạng những biến thể của phần mềm hoặc kết hợp với những thay đổi trong kiến trúc phần mềm. Kỹ nghệ sử dụng mẫu thiết kế ngày càng hoàn thiện nên mẫu thiết kế cũng dần chiếm một vị trí quan trọng trong chất lượng thiết kế. Hơn nữa, với những ưu điểm cũng như nhược điểm đã xác định được, mẫu thiết kế còn cho phép dự đoán chất lượng của một hệ thống phần mềm từ kiến trúc của hệ thống đó mà có chứa các mẫu thiết kế. Do vậy, một hướng xác định chất lượng kiến trúc phần mềm phổ biến hiện nay là dựa trên các mẫu thiết kế trong kiến trúc phần mềm. Ngoài ra, các mẫu tìm được còn cho phép dự đoán chất lượng của các hệ thống thực tế phát triển về sau. 1.1.4. Các chuẩn chất lượng phần mềm • ISO 9001: Các hệ thống chất lượng-Mô hình Thiết kế và Đảm bảo Chất lượng -Quality Systems-Model for Quality Assurance and Design L­¬ng Thanh B×nh 19 LuËn v¨n tèt nghiÖp CNTT 2005-2007 20 • ISO 9004-2: Các thành phần Hệ thống Chất lượng và Quản lý Chất lượngQuality Management and Quality System Elements • ISO 9000-3: Các dẫn hướng để ứng dụng ISO 9001 cho Phát triển, Cung cấp và Bảo trì Phần mềm Trong các chuẩn trên, đặc biệt phải kể đến ISO 9126, tiêu chuẩn được giám sát bởi dự án SQuaRE, ISO 25000:2005 dựa trên các khái niệm chung tương đương. Tiêu chuẩn này được chia thành 4 phần: mô hình chất lượng, các độ đo ngoài, các độ đo trong, các độ đo chất lượng sử dụng. Mẫu chất lượng được thiết lập ở phần đầu của tiêu chuẩn, mô hình này được đặt tên là ISO 9126-1, phân loại chất lượng phần mềm theo một tập các tính năng và tính năng con như sau: • Tính chức năng-functionality • Tính tin cậy-reliability • Tính tiện dùng-usability • Tính hiệu quả-efficiency • Tính dễ bảo trì-maintainability • Tính khả chuyển-portability Tính chức năng Một tập các chức năng liên quan đến sự tồn tại của các tính năng với những thuộc tính cụ thể. Những tính năng này phải tuân thủ các yêu cầu ngầm định hoặc yêu cầu tường minh, gồm các tính năng con:  Phù hợp  Đúng đắn  Liên kết các yếu tố con người, dữ liệu và hệ thống  Tuân thủ các yêu cầu L­¬ng Thanh B×nh 20