Đăng ký Đăng nhập
Trang chủ Luận văn thạc sĩ các tiêu chí đánh giá chất lượng phần mềm...

Tài liệu Luận văn thạc sĩ các tiêu chí đánh giá chất lượng phần mềm

.PDF
75
456
106

Mô tả:

ĐẠI HỌC THÁI NGUYÊN KHOA CÔNG NGHỆ THÔNG TIN NGUYỄN THỊ LAN PHƯƠNG CÁC TIÊU CHÍ ĐÁNH GIÁ CHẤT LƯỢNG PHẦN MỀM LUẬN VĂN THẠC SĨ KHOA HỌC MÁY TÍNH Thái Nguyên, 2010 Số hóa bởi Trung tâm Học liệu - Đại học Thái Nguyên http://www.lrc-tnu.edu.vn ĐẠI HỌC THÁI NGUYÊN KHOA CÔNG NGHỆ THÔNG TIN NGUYỄN THỊ LAN PHƯƠNG CÁC TIÊU CHÍ ĐÁNH GIÁ CHẤT LƯỢNG PHẦN MỀM Chuyên ngành: Khoa học máy tính Mã số: 60 48 01 LUẬN VĂN THẠC SĨ KHOA HỌC MÁY TÍNH NGƯỜI HƯỚNG DẪN KHOA HỌC PGS. TSKH NGUYỄN XUÂN HUY Thái Nguyên, 2010 Số hóa bởi Trung tâm Học liệu - Đại học Thái Nguyên http://www.lrc-tnu.edu.vn i LỜI CAM ĐOAN Tôi xin cam đoan luận văn này là công trình nghiên cứu, tìm hiểu và tham khảo của riêng tôi. Các số liệu trong luận văn là trung thực. Số hóa bởi Trung tâm Học liệu - Đại học Thái Nguyên http://www.lrc-tnu.edu.vn ii MỤC LỤC Trang Trang phụ bìa ..................................................................................................... Lời cam đoan ..................................................................................................... i Mục lục ............................................................................................................. ii Danh mục các hình ảnh .................................................................................... iv MỞ ĐẦU ........................................................................................................ 1 Chƣơng 1 TỔNG QUAN VỀ ĐÁNH GIÁ CHẤT LƢỢNG PHẦN MỀM 1.1. Các thuật ngữ ........................................................................................... 5 2.1. Quá trình phát triển phần mềm .................................................................. 6 1.2.1. Các giai đoạn phát triển phần mềm .................................................. 7 1.2.2. Các mô hình vòng đời phần mềm .................................................. 10 1.3. Yêu cầu về đánh giá chất lượng ph ần mềm ............................................. 13 1.3.1. Tầm quan trọng c ủa việc đánh giá chất lượng ph ần mềm ................ 13 1.3.2. Tiêu chí đánh giá chất lượng m ột số loại phần mềm ....................... 15 Chƣơng 2 TIÊU CHUẨN ĐÁNH GIÁ CHẤT LƢỢNG PHẦN MỀM 2.1. Tổng quan về tiêu chuẩn chất lượng phần mềm ...................................... 20 2.1.1. Tìm hiểu về c hất lượng phần mềm .................................................. 20 2.1.2. Đánh giá chất lượng sản phẩm phần mềm bằng các bộ chuẩn c ủa các tổ chức tiêu chuẩn quốc tế ....................................................................... 20 2.2. Các tiêu chí đánh giá phần mềm ............................................................. 34 Số hóa bởi Trung tâm Học liệu - Đại học Thái Nguyên http://www.lrc-tnu.edu.vn iii 2.2.1. Tiêu chí chức năng (Functionality) ................................................. 35 2.2.2. Tiêu chí độ tin cậy (Reliability) ...................................................... 36 2.2.3. Tiêu chí khả dụng (Usability) ........................................................ 36 2.2.4. Tiêu chí hiệu quả (Effictiency) ....................................................... 37 2.2.5. Tiêu chí bảo trì được (Maintainability) .......................................... 37 2.2.6. Tiêu chí khả chuyển (Portability) ................................................... 38 2.3. Độ đo các tiêu chí .................................................................................. 38 2.3.1. Khái niệm đ ộ đo phần mềm ............................................................ 38 2.3.2. Độ đo các tiêu chí ........................................................................... 38 Chƣơng 3 PHƢƠNG PHÁP ĐÁNH GIÁ PHẦN MỀM 3.1. Các giai đoạn tiến hành đánh giá phần mềm .......................................... 42 3.2. Đánh giá phần mềm về giao diện ........................................................... 48 3.3. Đánh giá phần mềm về chức năng ........................................................ 50 3.4. Đánh giá phần mềm về tiện ích ............................................................. 51 3.5. Đánh giá phần mềm về an toàn, bảo mật ............................................... 52 Chƣơng 4 XÂY DỰNG MỘT SỐ TIÊU CHÍ ĐÁNH GIÁ PHẦN MỀM 4.1. Ví dụ đánh giá phần mềm ...................................................................... 53 4.2. Xây dựng một số tiêu chí đánh giá phần mềm ....................................... 62 KẾT LUẬN VÀ ĐỀ NGHỊ ........................................................................ 68 TÀI LIỆU THAM KHẢO ......................................................................... 69 Số hóa bởi Trung tâm Học liệu - Đại học Thái Nguyên http://www.lrc-tnu.edu.vn iv DANH MỤC CÁC HÌNH ẢNH Trang Hình 2.1. Chất lượng trong vòng đời sản phẩm ............................................ 28 Hình 2.2. Mô hình chất lượng cho chất lượng trong và ngoài ....................... 31 Hình 2.3. Mô hình chất lượng sử dụng ......................................................... 34 Hình 3.1. Quy trình đánh giá sản phẩm phần mềm ....................................... 45 Hình 3.2. Giao diện chương trình BkavPro Internet Security 2010 ............... 54 Số hóa bởi Trung tâm Học liệu - Đại học Thái Nguyên http://www.lrc-tnu.edu.vn 1 MỞ ĐẦU Cơ sở khoa học và tính cấp thiết của đề tài Trong hơn ba chục năm qua con ngƣời đã chứng kiến sự lớn mạnh về số lƣợng cũng nhƣ mức độ quan trọng trong việc ứng dụng công nghệ thông tin vào cuộc sống. Ở trong nƣớc lĩnh vực công nghệ thông tin đang phát triển mạnh mẽ với sự xuất hiện ngày càng nhiều những công ty phần mềm. Chất lƣợng các sản phẩm phần mềm do các công ty này sản xuất chủ yếu là sự thỏa thuận với ngƣời sử dụng và họ tự đƣa ra quy trình cũng nhƣ tiêu chí cho riêng mình. Để đánh giá đƣợc chất lƣợng phần mềm có đáp ứng đƣợc nhu cầu cho trƣớc hay không thì cần phải đƣa các tiêu chí đánh giá chất lƣợng ph ần mềm về một tiêu chuẩn chung và phải đánh giá chất lƣợng phần mềm trong thực tế (tức là phần mềm phải qua sử dụng). Mục tiêu và nhiệm vụ của luận văn Các tổ chức tiêu chuẩn quốc tế nhƣ ISO, IEEE . . . đã công bố các bộ chu ẩn gồm các tiêu chí đánh giá chất lƣợng sản phẩm phần mềm nhƣ: a. ISO 9126: Software engineering -- Product quality b. ISO 14598: Information technology -- Software product evaluation c. ISO 12119: Software Packages – Quality Requirement and Testing d. ISO 9000-3: Quality Management and Quality Assurance Standards- part 3 e. IEEE Std 1061-1992: Standard for Software Quality Metrics Methodology Tuy nhiên một trong các chuẩn thông dụng về tiêu chí đánh giá chất lƣợng phần mềm chúng ta chỉ có thể áp dụng một phần nhỏ. Vì vậy, chúng ta cần có các tiêu chí theo một tiêu chuẩn chung, có mức tƣơng đƣơng với quốc tế để áp dụng. Trong phạm vi luận văn với đề tài "Các tiêu chí đánh giá chất lƣợng phần mềm" với mong muốn tìm hiểu về các tiêu chuẩn quy trình, phƣơng pháp đánh giá chất lƣợng phần mềm giúp khách hàng cũng nhƣ ngƣời sử dụng phần mềm có thể đánh giá khách quan về chất lƣợng phần mềm sử dụng trong thực tế. Số hóa bởi Trung tâm Học liệu - Đại học Thái Nguyên http://www.lrc-tnu.edu.vn 2 Mục tiêu của đề tài là nghiên cứu, tìm hiểu về các tiêu chuẩn đánh giá phần mềm, ý nghĩa của các tiêu chuẩn đó và tìm hiểu quy trình, phƣơng pháp đánh giá phần mềm, để từ đó có thể áp dụng để đánh giá một phần mềm cụ thể. Phạm vi nghiên cứu Luận văn tập trung nghiên cứu, tìm hiểu các tiêu chí đánh giá chất lƣợng phần mềm của các tổ chức tiêu chuẩn quốc tế. Phƣơng pháp nghiên cứu Luận văn tập trung nghiên cứu, tìm hiểu các tiêu chí đánh giá chất lƣợng sản phẩm phần mềm thông qua việc thu thập, tổng hợp các sách, các bài báo, các tài liệu trên mạng bằng tiếng Việt, tiếng Anh. Nghiên cứu các tiêu chuẩn, hƣớng dẫn của các tổ chức tiêu chuẩn quốc tế (ISO/IEC, IEEE ...) về đánh giá chất lƣợng sản phẩm phần mềm qua các bộ chuẩn. Cấu trúc của luận văn Cấu trúc của luận văn gồm: phần mở đầu; chƣơng 1, 2, 3 và 4; phần kết luận và đề nghị; tài liệu tham khảo; Số hóa bởi Trung tâm Học liệu - Đại học Thái Nguyên http://www.lrc-tnu.edu.vn 3 Nội dung chính của luận văn Chƣơng 1: Trình bày tổng quan về quá trình phát triển phần mềm, các tiêu chí đánh giá sản phẩm phần mềm cho một số loại phần mềm. Chƣơng 2: Trình bày tổng quan về tiêu chuẩn chất lƣợng phần mềm, một số tiêu chí đánh giá chất lƣợng phần mềm và độ đo các tiêu chí. Chƣơng 3: Trình bày các bƣớc tiến hành đánh giá sản phẩm phần mềm. Chƣơng 4: Đƣa ra ví dụ đánh giá một phần mềm cụ thể, từ đó xây dựng một số tiêu chí đánh giá phần mềm. Số hóa bởi Trung tâm Học liệu - Đại học Thái Nguyên http://www.lrc-tnu.edu.vn 4 Lời cảm ơn Luận văn này đƣợc hoàn thành tại Khoa Công nghệ Thông tin – Đại học Thái Nguyên dƣới sự hƣớng dẫn của PGS.TSKH NGUYỄN XUÂN HUY. Tác giả xin bày tỏ lòng kính trọng và biết ơn sâu sắc tới thầy về sự tận tình hƣớng dẫn trong suốt thời gian tác giả làm luận văn. Trong quá trình học tập và làm luận văn tác giả thƣờng xuyên nhận đƣợc sự quan tâm giúp đỡ và đóng góp ý kiến của các thầy cô trực tiếp giảng dạy cũng nhƣ các thầy cô trong khoa CNTT – ĐHTN. Từ đáy lòng mình tác giả xin bày tỏ lòng biết ơn sâu sắc đến các thầy cô. Tác giả xin bày tỏ lòng biết ơn tới Ban Giám Hiệu, các thầy cô trƣờng THCS TRƢNG VƢƠNG đã tạo điều kiện giúp đỡ tác giả trong thời gian làm luận văn. Xin chân thành cảm ơn anh chị em học viên lớp CAO HỌC K7 và bạn bè đồng nghiệp đã trao đổi và khích lệ tác giả trong quá trình học tập, nghiên cứu và làm luận văn. Luận văn sẽ không hoàn thành đƣợc nếu không có sự quan tâm, động viên của ngƣời thân trong gia đình tác giả. Đây là món quà tinh thần, tác giả xin gửi tặng gia đình thân yêu của mình với lòng biết ơn chân thành và sâu sắc. Tác giả Chƣơng 1 Số hóa bởi Trung tâm Học liệu - Đại học Thái Nguyên http://www.lrc-tnu.edu.vn 5 TỔNG QUAN VỀ ĐÁNH GIÁ CHẤT LƢỢNG PHẦN MỀM 1.1. Các thuật ngữ: Tiêu chí: là bộ tiêu chuẩn dùng để kiểm định hay để đánh giá một đối tƣợng, mà bao gồm các yêu cầu về chất lƣợng, mức độ, hiệu quả, khả năng, tuân thủ các qui tắc và qui định, kết quả cuối cùng và tính bền vững của các kết quả. Tiêu chuẩn: Là những quy định thống nhất đƣợc xây dựng theo một thể thức nhất định do một cơ quan có thẩm quyền ban hành để bắt buộc hay khuyến khích áp dụng cho các bên liên quan. Đánh giá phần mềm: Tập hợp các tiêu thức xác định chất lƣợng phần mềm và các phƣơng pháp xác định tiêu thức này. Phần mềm: là những chƣơng trình điều khiển các chức năng phần cứng và hƣớng dẫn phần cứng thực hiện các tác vụ của mình. Chất lượng phần mềm: Là sự đáp ứng các nhu cầu chức năng, sự hoàn thiện và các chuẩn (đặc tả) đƣợc phát triển. Quy trình phát triển phần mềm RUP (Rational Unified Process): Quy trình hợp nhất của Rational (hãng IMB) dùng riêng cho phát triển phần mềm. Quy trình gồm 4 pha cơ bản: Inception (khởi đầu), Elaboration (phân tích, phân rã), Construction (xây dựng) và Transition (bàn giao). Tính mềm dẻo: Nỗ lực cần để cải biên một chƣơng trình là chấp nhận đƣợc. Tính phổ biến: Mức độ tiềm năng trình ứng dụng của các bộ phận trong chƣơng trình. Tính toàn vẹn: Có thể khống chế đƣợc việc truy cập của những ngƣời không đƣợc phép sử dụng phần mềm và dữ liệu. Tính thiết thực: Là mức độ sản phẩm các công việc thích hợp đƣợc chuyển tiếp tới các chức năng hợp thức dƣới các điều kiện hoặc tình huống khác thƣờng. Tính an ninh, an toàn: Là khả năng của sản phẩm phần mềm bảo vệ các thông tin và các dữ liệu khi bị xâm nhập bất hợp pháp. Tính đơn giản: Mức độ dễ hiểu của một chƣơng trình. Tính ổn đinh: Là khả năng của sản phẩm phần mềm tránh đƣợc các tác Số hóa bởi Trung tâm Học liệu - Đại học Thái Nguyên http://www.lrc-tnu.edu.vn 6 động bất ngờ từ các cải biên của phần mềm. Tính dung thứ được: Kết hợp các khả năng mở rộng chƣơng trình, khả năng thích ứng và tính tiện lợi. Tính thử nghiệm được: Là khả năng của sản phẩm phần mềm cho phép cải biên nó, và quá trình thử nghiệm không ảnh hƣởng đến cấu hình và các bộ phận đƣợc tạo ra. Tính dời chuyển được: Là những thuộc tính liên quan đến chi phí vận chuyển một sản phẩm phần mềm từ ổ cứng gốc đến ổ cứng khác hoặc từ một môi trƣờng hoạt động này đến môi trƣờng hoạt động khác. Tính tin cậy được: Khả năng của hệ thống có thể cung cấp cho ngƣời sử dụng các thông tin về lỗi dịch vụ. Tính hiểu được: Là khả năng của sản phầm phần mềm cho phép ngƣời sử dụng hiểu đƣợc phần mềm có thích hợp hay không và sử dụng nó nhƣ thế nào. Tính tiện lợi: Là khả năng của sản phẩm phần mềm trở nên dễ hiểu, dễ học, dễ sử dụng và hấp dẫn ngƣời sử dụng. Tính tiện ích: Là mức độ cho phép nhiều ngƣời sử dụng truy cập và sử dụng phần mềm ở các kiểu khác nhau. Tính thẩm tra được: Là không phụ thuộc vào các trình ứng dụng hay các bộ phận đƣợc kiểm tra. Tính không ổn định: Là các thuộc tính liên quan đến các văn bản thủ tục khi sản phẩm phần mềm đƣợc thay đổi thƣờng xuyên. 1.2. Quá trình phát triển phần mềm Quá trình phát triển phần mềm là tập hợp các thao tác và các kết quả tƣơng quan để sản xuất ra một sản phẩm phần mềm. Quá trình phát triển phần mềm là sự kết hợp giữa mô hình vòng đời phần mềm, các công cụ đƣợc sử dụng và những ngƣời xây dựng nên phần mềm đó. Những thao tác đó hầu hết đƣợc tiến hành và thực hiện bởi các kỹ sƣ phần mềm. Nền tảng của hầu hết các quá trình phần mềm là 4 thao tác sau: Số hóa bởi Trung tâm Học liệu - Đại học Thái Nguyên http://www.lrc-tnu.edu.vn 7  Đặc tả phần mềm: Các chức năng của phần mềm và điều kiện để nó hoạt động phải đƣợc định nghĩa.  Sự triển khai phần mềm: Để phần mềm đạt đƣợc đặc tả thì phải trải qua quá trình phát triển này, đó chính là quá trình tạo ra phần mềm.  Đánh giá phần mềm: Phần mềm phải đƣợc đánh giá để xem nó làm đƣợc những gì, có đáp ứng đƣợc yêu cầu cũng nhƣ những mong muốn của ngƣời dùng.  Sự tiến hóa của phần mềm: Phần mềm phải đƣợc đổi cũng nhƣ phát triển để thỏa mãn sự thay đổi các yêu cầu của khách hàng. 1.2.1. Các giai đoạn phát triển phần mềm: Quá trình phát triển phần mềm luôn đƣợc xây dựng trên cơ sở các giai đoạn chuẩn, theo đúng thứ tự đã đặt ra:  Xác định yêu cầu phần mềm – Requirement Engineering  Phân tích hệ thống phần mềm – Anslysis  Thiết kế phần mềm – Design  Cài đặt phần mềm – Development  Kiểm thử phần mềm – Testing  Bảo trì phần mềm – Maintenance Các công ty phần mềm khác nhau có các quá trình phát triển phần mềm khác nhau. Trong một số trƣờng hợp thì tên các giai đoạn (pha) này có thể khác. 1.2.1.1. Xác định yêu cầu phần mềm Khách hàng và ngƣời phát triển trong những lần gặp nhau đầu tiê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ủa phần mềm mà họ muốn đặt hàng. Nhiệm vụ của ngƣời phát triển là phải tìm hiểu xem khách hàng cần gì. 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). Kiểm thử pha yêu cầu Số hóa bởi Trung tâm Học liệu - Đại học Thái Nguyên http://www.lrc-tnu.edu.vn 8 Nhóm bảo đảm chất lƣợng phần mềm (SQA = software quality assurance) 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ó đã đƣợc thực hiện đúng các yêu cầu mà khách hàng cần không. Tài liệu báo cáo trong pha yêu cầu Tài liệu báo cáo trong pha yêu cầu này 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. 1.2.1.2. Phân tích (hay đặc tả) hệ thống phần mềm Nhóm phân tích sẽ biên soạn tài liệu đặc tả (hay tài liệu phân tích). Những điều đƣợc nêu lên trong tài liệu của pha yêu cầu sẽ đƣợc chi tiết và chính xác hóa. Tài lệu đặc tả còn chỉ rõ đầu vào (input) và đầu ra (output) của phần mềm. 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. 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 ... Kiểm thử pha đặc tả Nhóm SQA 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 hay chƣa đầy đủ. Ngoài ra, nhóm SQA còn phải xem xét tính khả thi của đặc tả. Tài liệu đặc tả phải có thể kiểm thử đƣợc. Nếu có bản mẫu trong pha yêu cầu thì trong đặ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. Tài liệu trong pha đặc tả Tài liệu trong pha này bao gồm: bản báo cáo đặc tả và bản thiết kế quản lý dự án phần mềm. 1.2.1.3. Thiết kế phần mềm Nhóm thiết kế tìm hiểu, nghiên cứu bản báo cáo đặc tả, xác định cấu trúc bên trong của phần mềm, 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 Số hóa bởi Trung tâm Học liệu - Đại học Thái Nguyên http://www.lrc-tnu.edu.vn 9 còn lại của phần mềm, tiếp theo là 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. Kiểm thử pha thiết kế Bản thiết kế đƣợc nhóm SQA thực hiện 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. Các lỗi thƣờng đƣợc phát hiện trong pha này 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ả. Tài liệu báo cáo trong pha thiết kế Sản phẩm chính trong pha này là bản thiết kế kiến trúc và thiết kế chi tiết. 1.2.1.4. Cài đặt phần mềm 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. 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 ngƣời lập trình thực hiện bằng cách chạy thử các số liệu mẫu, xem xét các mã nguồn để tìm ra lỗi lập trình. Sau đó nhóm SQA sử dụng một số phƣơng pháp đã có để thử lại các module. Tài liệu báo các 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 lời chú thích. 1.2.1.5. Kiểm thử phần mềm Trong pha cài đặt từng module đã đƣợc kiểm thử. Trong pha kiểm thử 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. Bƣớc cuối của kiểm thử là kiểm thử chấp nhận (acceptance testing). Tài liệu báo cáo trong pha kiểm thử Số hóa bởi Trung tâm Học liệu - Đại học Thái Nguyên http://www.lrc-tnu.edu.vn 10 Sản phẩm trong pha kiểm thử là các mã nguồn đã đƣợc hiệu chỉnh cùng các 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 dụng chƣơng trình, giải thích các cơ sở dữ liệu ... 1.2.1.6. Bảo trì phần mềm 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. 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. Kiểm thử pha bảo trì 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ì những phần còn lại có bị ảnh hƣởng không. Tài liệu báo cáo trong pha bảo trì Tài liệu quan trọng trong pha bảo trì là các ghi chép về các sửa đổi đã đƣợc thực hiện cùng các lý do. 1.2.2. Các mô hình vòng đời phần mềm Mô hình vòng đời phần mềm (SLC – Software Life Cycle) là tập hợp các công việc và quan hệ giữa chúng với nhau diễn ra trong quá trình phát triển phần mềm. Có nhiều mô hình khác nhau, một số trong đó đƣợc ứng dụng khá phổ biến trên thế giới. 1.2.2.1. Mô hình thác nƣớc Trong mô hình thác nƣớc, các pha phải đƣợc thực hiện một cách tuần tự, kết thúc pha trƣớc, rồi mới đƣợc thực hiện pha tiếp theo. Do đó, nhƣợc điểm chính của mô hình thác nƣớc là rất khó khăn trong việc thay đổi các pha đã đƣợc thực hiện. Giả sử, pha phân tích và xác định yêu cầu đã hoàn tất và chuyển sang pha kế tiếp, nhƣng lúc này lại có sự thay đổi yêu cầu của ngƣời sử dụng, thì chỉ còn cách là phải thực hiện lại từ đầu. Cho nên, mô hình này chỉ thích hợp khi các yêu cầu đã đƣợc tìm hiểu rõ ràng và những thay đổi sẽ đƣợc giới hạn một cách rõ ràng trong suốt quá Số hóa bởi Trung tâm Học liệu - Đại học Thái Nguyên http://www.lrc-tnu.edu.vn 11 trình thiết kế. Tuy nhiên, trong thực tế có rất ít những hệ thống nghiệp vụ có các yêu cầu ổn định. Phân tích các yêu cầu và định nghĩa: hệ thống dịch vụ, khó khăn và mục tiêu đƣợc hình thành bởi sự trợ ý của hệ thống ngƣời tiêu dùng. Thiết kế phần mềm và hệ thống: thiết kế hệ thống các quá trình, các bộ phận và các yêu cầu cả phần mềm lẫn phần cứng. Hoàn tất hầu nhƣ tất cả kiến trúc của hệ thống này. Thực hiện và thử nghiệm các đơn vị: trong giai đoạn này, thiết kế phần mềm phải đƣợc chứng thực nhƣ là một tập hợp nhiều chƣơng trình hay nhiều đơn vị nhỏ. Thử nghiệm các đơn vị bao gồm xác minh rằng mỗi đơn vị thỏa mãn đặc tả của nó. Tổng hợp và thử nghiệm toàn bộ: các đơn vị chƣơng trình riêng lẻ hay các chƣơng trình đƣợc tích hợp lại và thử nghiệm nhƣ là một hệ thống hoàn tất và chứng tỏ đƣợc các yêu cầu của phần mềm đƣợc thỏa mãn. Sau khi thử nghiệm phần mềm đƣợc cung ứng cho ngƣời tiêu dùng. Sản xuất và bảo trì: thông thƣờng (nhƣng không bắt buộc) đây là pha lâu nhất của chu kỳ sống (của sản phẩm). Phần mềm đƣợc cài đặt và đƣợc dùng trong thực tế. Bảo trì bao gồm điều chỉnh các lỗi mà chƣa đƣợc phát hiện trong các giai đoạn trƣớc của chu kỳ sống, nâng cấp sự thực hiện của hệ thống các đơn vị và nâng cao hệ thống dịch vụ. Chỗ yếu của mô hình này là nó không linh hoạt. Các bộ phận của đề án chia ra thành những phần riêng của các giai đoạn. Hệ thống phân phối đôi khi không dùng đƣợc vì không thỏa mãn đƣợc yêu cầu của khách hàng. Mặc dù mô hình này phản ánh thực tế công nghệ. Nhƣ là một hệ quả đây vẫn là mô hình cơ sở cho đa số các hệ thống phát triển phần mềm - phần cứng. 1.2.2.2. Mô hình phát triển tiến hóa của phần mềm Phân tích mô hình: Mô hình phát triển tiến hóa này hiệu quả hơn mô hình thác nƣớc. Tuy nhiên, nó vẫn có khuyết điểm: Số hóa bởi Trung tâm Học liệu - Đại học Thái Nguyên http://www.lrc-tnu.edu.vn 12 - Quá trình không nhìn thấy rõ đƣợc: Các nhà quản lý cần phân phối thƣờng xuyên để đo lƣờng sự tiến bộ. Nó không kinh tế trong việc làm ra các hồ sơ cho phần mềm. - Phần mềm thƣờng đƣợc cấu trúc nghèo nàn: Sự thay đổi liên tục dễ làm sai lệch cấu trúc của phần mềm, tạo ra sự khó khăn và tốn chi phí. - Thƣờng đòi hỏi những kỹ năng đặc biệt: Hầu hết các hệ thống khả dĩ theo cách này đƣợc tiến hành bởi các nhóm nhỏ có kỹ năng cao. Mô hình này hợp với:  Phát triển các loại phần mềm tƣơng đối nhỏ.  Phát triển các loại phần mềm có đời sống tƣơng đối ngắn.  Tiến hành trong các hệ thống lớn hơn ở những chỗ mà không thể biểu thị đƣợc các đặc tả chi tiết trong lúc tiến hành. Thí dụ của trƣờng hợp này là các hệ thống thông minh nhân tạo (AI) và các giao diện cho ngƣời dùng. 1.2.2.3. Mô hình xoắn ốc Boehm Mô hình Boehm có dạng xoắn ốc. Mô hình Boehm có thể chỉ ra các rủi ro có thể hình thành trên căn bản của mô hình quá trình (sản xuất) tổng quát. Mỗi vòng mô hình đại diện cho một pha của quá trình phần mềm. Vòng trong cùng tập trung về tính khả thi, kế đến là vòng định nghĩa các yêu cầu, vòng tiếp theo là thiết kế ... Không có một pha nào đƣợc xem là cố định trong vòng xoắn. Mỗi vòng có 4 phần tƣơng ứng với 1 pha. - Cài đặt đối tƣợng: chỉ ra các đối tƣợng của pha trong đề án. Những khó khăn của quá trình và của các sản phẩm đƣợc xác định và đƣợc lên kế hoạch chi tiết. Xác định các yếu tố rủi ro của đề án. Các phƣơng án thay thế tùy theo các rủi ro này có thể đƣợc dự trù. - Lƣợng định và giảm thiểu rủi ro. Tiến hành phân tích mỗi yếu tố rủi ro đã xác định. Đặt ra các bƣớc để giảm thiểu rủi ro. Số hóa bởi Trung tâm Học liệu - Đại học Thái Nguyên http://www.lrc-tnu.edu.vn 13 - Phát triển và đánh giá: Sau khi đánh giá các yếu tố rủi ro, một mô hình phát triển cho hệ thống đƣợc chọn. - Lên kế hoạch: Đề án đƣợc xem xét và quyết định có nên hay không tiếp tục pha mới trong vòng lặp. 1.3. Yêu cầu về đánh giá phần mềm 1.3.1. Tầm quan trọng của việc đánh giá chất lƣợng phần mềm Trong kỷ nguyên hiện đại, phần mềm đóng vai trò vô cùng quan trọng, có thể so sánh nhƣ một hệ thần kinh số điều khiển toàn bộ hoạt động hệ thống thông tin toàn cầu. Trong bối cảnh đó, một sai lầm, dù rất nhỏ của phần mềm cũng có thể gây ra hậu quả khôn lƣờng. Chỉ vì một dấu phẩy nhầm lẫn trong hệ thống phần mềm điều khiển mà tàu vũ trụ Apollo 11 của Mỹ đã nổ tung khi phóng lên quỹ đạo, gây thiệt hại hàng tỷ USD và nghiêm trọng là đã cƣớp đi mạng sống của toàn bộ phi hành đoàn. Theo kết quả nghiên cứu của Viện Công Nghệ và Tiêu Chuẩn Quốc Gia (NIST) thuộc Bộ Thƣơng Mại Mỹ, các nhƣợc điểm trong phần mềm không chỉ gây phiền phức cho ngƣời dùng mà hàng năm còn gây tổn thất lớn cho nền kinh tế Mỹ ƣớc tính 59,5 tỷ USD. Tuy nhiên, cũng theo NIST, thử nghiệm để phát hiện và loại bỏ khiếm khuyết ngay từ quá trình sản xuất phần mềm có thể giảm mức thiệt hại khoảng 22,2 tỷ USD trong tổng số 59,5 tỷ này. Thời gian gần đây, cùng với sự phát triển mạnh của ngành phần mềm Việt Nam, nhiều doanh nghiệp đã nhận thức đúng về vai trò của chất lƣợng phần mềm và định hƣớng xây dựng các quy trình sản xuất phần mềm theo chuẩn quốc tế với mục đích sản xuất phần mềm chất lƣợng. Lĩnh vực công nghệ thông tin trong nƣớc đang phát triển rất mạnh mẽ với sự xuất hiện rất nhiều các công ty phần mềm. Chất lƣợng của các sản phẩm phần mềm do các công ty này sản xuất chủ yếu là sự thỏa thuận với ngƣời sử dụng và họ tự đƣa ra quy trình cũng nhƣ tiêu chí cho riêng mình. Để đánh giá đƣợc chất lƣợng phần mềm có đáp ứng đƣợc nhu cầu cho trƣớc Số hóa bởi Trung tâm Học liệu - Đại học Thái Nguyên http://www.lrc-tnu.edu.vn 14 hay không thì cần phải đƣa các tiêu chí đánh giá chất lƣợng ph ần mềm về một tiêu chuẩn chung và phải đánh giá chất lƣợng ph ần mềm trong thực tế (tức là phần mềm ph ải qua sử dụng). Tuy nhiên, hiện nay cơ quan quản lý nhà nƣớc về ngành công nghệ thông tin còn thiếu cơ sở phƣơng pháp và các tiêu chí đánh giá để xác định định mức cho sản phẩm phần mềm. Và một vấn đề đặt ra đối với công tác quản lý chất lƣợng phần mềm là cần phải có một tổ chức độc lập để xây dựng các tiêu chí đánh giá chất lƣợng phần mềm. Nhằm hỗ trợ các doanh nghiệp phần mềm Việt Nam trong việc nâng cao chất lƣợng của sản phẩm phần mềm cũng nhƣ việc thống nhất quản lý chất lƣợng phần mềm trong các doanh nghiệp thành viên của Hiệp hội doanh nghiệp phần mềm Việt Nam (VINASA). Mới đây, VINASA đã chính thức thành lập Ban công tác chất lƣợng VINASA (VINASA QUALITY COMMITEE -VQC), với nhiệm vụ xây dựng “các tiêu chuẩn và đánh giá chất lƣợng phần mềm Việt Nam” tƣ vấn cho các doanh nghiệp phần mềm về quy trình đảm bảo chất lƣợng phần mềm, cung cấp cho doanh nghiệp các chỉ tiêu, các tiêu chuẩn để đánh giá chất lƣợng phần mềm trong các lĩnh vực khác nhau dựa trên các chuẩn quốc tế ISO-9000, ISO-9126, ISO-14598 … Công ty cổ phần phần mềm Hà Nội (HanoiSoftware) kinh doanh trên các giải pháp phần mềm cho Website thƣơng mại điện tử, phát triển và triển khai các cổng thông tin tích hợp thì xây dựng các sản phẩm phần mềm đáp ứng các mô hình chất lƣợng của tiêu chuẩn ISO-9126. Tập đoàn bƣu chính viễn thông Việt Nam lại thực hiện đánh giá sản phẩm phần mềm theo tiêu chuẩn ISO/IEC 12119:1994 về “Yêu cầu và kiểm tra chất lƣợng phần mềm”. Các tiêu chí đánh giá về phần mềm của Trung tâm Công nghệ thông tin CDiT thuộc Học viện Bƣu chính Viễn thông đƣợc xây dựng dựa trên 6 đặc tính chất lƣợng nêu trong tiêu chuẩn ISO/IEC 9126 và áp dụng tiêu chuẩn ISO/IEC 12119:1994 để đánh giá chung cho các tài liệu hƣớng dẫn, tài liệu mô tả sản phẩm, chƣơng trình và dữ liệu. Nói tóm lại hiện nay trong nƣớc vẫn chƣa có một tiêu chuẩn chung nào để đánh giá chất lƣợng phần Số hóa bởi Trung tâm Học liệu - Đại học Thái Nguyên http://www.lrc-tnu.edu.vn
- Xem thêm -

Tài liệu liên quan

Tài liệu xem nhiều nhất