Tài liệu Khảo sát và đánh giá sản phẩm phần mềm theo các tiêu chuẩn chất lượng

ĐẠI HỌC THÁI NGUYÊN TRƯỜNG ĐẠI HỌC CÔNG NGHỆ THÔNG TIN VÀ TRUYỀN THÔNG NÔNG THỊ NHÀN KHẢO SÁT VÀ ĐÁNH GIÁ SẢN PHẨM PHẦN MỀM THEO CÁC TIÊU CHUẨN CHẤT LƯỢNG LUẬN VĂN THẠC SĨ KHOA HỌC MÁY TÍNH THÁI NGUYÊN - 2012 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 TRƯỜNG ĐẠI HỌC CÔNG NGHỆ THÔNG TIN VÀ TRUYỀN THÔNG NÔNG THỊ NHÀN KHẢO SÁT VÀ ĐÁNH GIÁ SẢN PHẨM PHẦN MỀM THEO CÁC TIÊU CHUẨN CHẤT LƯỢNG 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 - 2012 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. Tác giả Nông Thị Nhà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 ii LỜI CẢM ƠN Luận văn này được hoàn thành tại trường Đại học Công nghệ Thông tin và Truyền thông - Đạ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. Tác giả xin bày tỏ lòng kính trọng và biết ơn tới PGS.TS Nguyễn Thiện Luận đã cung cấp một số tài liệu trong quá trình làm luận văn. Trong quá trình học tập tại trường Đại học Công nghệ Thông tin và Truyền thông - Đại học Thái Nguyên tác giả thường xuyên nhận được sự quan tâm giúp đỡ, đóng góp ý kiến của các thầy cô trực tiếp giảng dạy và các cán bộ, giáo viên trong trường. Tác giả xin bày tỏ lòng biết ơn sâu sắc đến những thầy cô đó. Tác giả xin bày tỏ lòng biết ơn tới Ban Giám Hiệu, các bạn đồng nghiệp trường Trung học Phổ thông Quang Trung đã tạo điều kiện sắp xếp công việc, giúp đỡ tác giả trong thời gian học tập và 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 K9A đã giúp đỡ, động viên, khích lệ tác giả trong quá trình học tập và nghiên cứu. 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 sâu sắc. Tác giả 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 MỤC LỤC Lời cam đoan ...................................................................................................... i Lời cảm ơn ........................................................................................................ ii Mục lục ............................................................................................................. iii Danh mục các từ viết tắt ................................................................................... v Danh mục các hình ảnh, hình vẽ ...................................................................... vi MỞ ĐẦU .......................................................................................................... 1 Chƣơng 1. QUY 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 ................................................ 4 1.1. Các thuật ngữ ......................................................................................... 4 1.2. Quy trình phát triển phần mềm .............................................................. 6 1.2.1. Các giai đoạn của quy trình phát triển phần mềm .............................. 6 1.2.1.1. Nghiên cứu sơ bộ ..................................................................... 7 1.2.1.2. Phân tích hệ thống phần mềm .................................................. 7 1.2.1.3. Thiết kế hệ thống...................................................................... 8 1.2.1.4. Xây dựng phần mềm ................................................................ 8 1.2.1.5. Thử nghiệm hệ thống ............................................................... 9 1.2.1.6. Thực hiện, triển khai ................................................................ 9 1.2.1.7. Bảo trì, nâng cấp ...................................................................... 9 1.2.2. Các mô hình vòng đời phần mềm ..................................................... 10 1.2.2.1. Mô hình tăng trưởng (growth model) .................................... 10 1.2.2.2. Mô hình đồng bộ và ổn định (Synchronize-AndStabilize Model).................................................................... 11 1.2.2.3. Mô hình hướng đối tượng (Object-Oriented model) ............. 12 1.3. Chất lượng phần mềm .......................................................................... 12 1.4. Đánh giá phần mềm ............................................................................. 13 1.4.1. Tầm quan trọng của việc đánh giá chất lượng phần mềm ................ 14 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 1.4.2. Một số mô hình đánh giá chất lượng phần mềm............................... 15 1.4.2.1. Mô hình ISO/IEC-9126 .......................................................... 15 1.4.2.2. Mô hình ISO/IEC-14598........................................................ 19 1.4.2.3. Một số mô hình khác.............................................................. 23 1.5. Các độ đo chất lượng phần mềm - Metrics (ISO/IEC 9126-2) .............. 25 1.5.1. Độ đo trong ............................................................................... 26 1.5.2. Độ đo ngoài ............................................................................... 27 Chƣơng 2. PHƢƠNG PHÁP ĐÁNH GIÁ SẢN PHẨM PHẦN MỀM THEO TIÊU CHUẨN CHẤT LƢỢNG ........................................... 29 2.1. Phân loại phần mềm ............................................................................. 29 2.1.1. Phân loại theo phương thức hoạt động.............................................. 29 2.1.2. Phân loại theo khả năng ứng dụng .................................................... 30 2.1.3. Phân loại theo nhu cầu của người dùng ............................................ 30 2.2. Độ đo ngoài cho sản phẩm phần mềm ................................................. 31 2.3. Các tiêu chí đánh giá các nhóm phần mềm.......................................... 43 2.3.1. Nhóm phần mềm Quản lý giáo dục................................................... 44 2.3.2. Nhóm phần mềm Kế toán - Tài chính ............................................... 46 2.3.3. Nhóm phần mềm tiện ích diệt virus .................................................. 50 Chƣơng 3. XÂY DỰNG MỘT SỐ TIÊU CHUẨN CHẤT LƢỢNG PHẦN MỀM .................................................................................................. 55 3.1. Bài toán quản lý trường học và những phần mềm ứng dụng............... 55 3.2. Đánh giá Phần mềm Quản lý trường học - V.EMIS ............................ 57 3.2.1. Tổng quan về V.EMIS ...................................................................... 57 3.2.2. Đánh giá phần mềm V.EMIS (V.EMIS.Student).............................. 59 3.2.3. Xây dựng tiêu chí đánh giá phần mềm V.EMIS (V.EMIS.Student)........................................................................................ 63 KẾT LUẬN VÀ ĐỀ NGHỊ ........................................................................... 67 TÀI LIỆU THAM KHẢO ............................................................................ 68 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 v DANH MỤC CÁC TỪ VIẾT TẮT Từ viết tắt The ISO Ý nghĩa Diễn giải International Tổ chức quốc tế về tiêu chuẩn hóa for trong các lĩnh vực sản xuất, thương Organisation Standardisotion The IEC mại và thông tin. International Electrotechnical thành lập năm 1906. Commission The International Organisation ISO/IEC Standardisotion Uỷ ban Kỹ thuật Điện Quốc tế được for / The Sự hợp tác giữa ISO và IEC để thành lập ra Ủy Ban kỹ thuật chung. International Electrotechnical Commission IEEE Tổ chức khoa học nghề nghiệp - Hỗ Instituse of Electrical and trợ các hoạt động nghiên cứu khoa Electronic Engineers học, thúc đẩy sự phát triển Khoa học Công nghệ trong các lĩnh vực Điện tử. Viễn thông, Công nghệ Thông tin… 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 vi DANH MỤC CÁC HÌNH ẢNH, HÌNH VẼ Hình 1.1. Mô hình chất lượng ISO/IEC 9126-1 ............................................. 18 Hình 1.2. Qui trì nh kiểm tra đánh giá sản phẩm phần mềm ........................... 19 Hình 1.3. Thang đo chất lượng ....................................................................... 21 Hình 1.4. Mối liên hệ giữa tiêu chuẩn ISO 9126 và ISO 14598 ..................... 23 Hình 3.1. Giao diện chính chương trình V.EMIS.Student phiên bản 1.1.4 .... 59 Hình 3.2. Giao diện chức năng “Nhập danh sách học sinh trúng tuyển” ....... 60 Hình 3.3. Giao diện chức năng “Nạp và sửa hồ sơ ban đầu”.......................... 60 Hình 3.4. Giao diện chức năng “Phân phòng thi tự động” ............................. 61 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 của đề tài Khi nói đến chất lượng phần mềm, có nhiều định nghĩa tùy theo cách nhìn khác nhau. Từ cách nhìn của khách hàng, chất lượng được xác định là việc đáp ứng nhu cầu và đạt tới sự thỏa mãn; Từ cách nhìn của người phát triển, phần mềm được thiết kế tốt và sản phẩm tuân thủ theo thiết kế đó (đáp ứng yêu cầu đặc tả chức năng); Ngoài ra chất lượng có thể được xác định như quy trình hiệu quả tạo ra sản phẩm mà không có lỗi nào và cung cấp giá trị đo được cho những người tạo ra sản phẩm và người dùng nó. Còn theo định nghĩa hình thức về Chất lượng phần mềm của Tổ chức Tiêu chuẩn quốc tế ISO trong Bộ Tiêu chuẩn 8402: “Chất lượng là khả năng đáp ứng toàn diện nhu cầu của người sử dụng về tính năng cũng như công dụng được nêu ra một cách tường minh hoặc không tường minh trong những ngữ cảnh xác định”. Những quan niệm và cách nhìn về chất lượng phần mềm nêu trên có thể đầy đủ nhưng thiếu hẳn yếu tố định lượng. Chất lượng phần mềm luôn là mối quan tâm hàng đầu của người sử dụng. Vì vậy, rất cần có những tiêu chí đánh giá cụ thể và phương pháp đo đạc mang yếu tố định lượng. Đề tài mong muốn đề xuất các tiêu chí đánh giá phần mềm, giúp khách hàng cũng như người sử dụng có thể đánh giá khách quan về chất lượng phần mềm sử dụng trong thực tế. Mục tiêu và nhiệm vụ của luận văn Đề xuất những tiêu chuẩn chung để đánh giá một số nhóm phần mềm từ việc nghiên cứu, tìm hiểu các tiêu chuẩn đánh giá phần mềm đã có, ý nghĩa của các tiêu chuẩn đó. Ngoài ra, đề tài tìm hiểu quy trình, phương pháp đánh giá phần mềm, từ đó áp dụng thử nghiệm để đánh giá một phần mềm cụ thể. 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 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 d. ISO 9000-3: Quality Management and Quality Assurance Standards- part 3 e. IEEE Std 1061-1992: Standard for Software Quality Metrics Methodology Trong mỗi bộ chuẩn nêu trên, không phải tất cả đều có thể áp dụng để đánh giá cho mọi phần mềm. Trong mỗi bộ chuẩn chúng ta chỉ có thể áp dụng một phần nhỏ phù hợp với mỗi nhóm phần mềm khác nhau. Vì vậy, 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 đề tài luận văn, 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 có thể đánh giá khách quan về chất lượng phần mềm sử dụng trong thực tế, tôi chọn đề tài "Khảo sát và đánh giá sản phẩm phần mềm theo các tiêu chuẩn chất lượng". Đối tƣợng và phạm vi nghiên cứu 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 trong nước và quốc tế; Khảo sát một số phần mềm ứng dụng; Áp dụng thử nghiệm đánh giá chất lượng cho một phần mềm cụ thể. Phƣơng pháp 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. Vận dụng thử nghiệm các tiêu chí đánh giá cho một phần mềm cụ thể. Cấu trúc và nội dung chính của luận văn Cấu trúc và nội dung chính của luận văn gồm: - Phần mở đầu. - Chương 1. Quy 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. Chương này trình bày tổng quan về quá trình phát triển phần mềm; Chất lượng phần mềm; Thông qua một số mô hình đánh giá chất lượng phần mềm của các tổ chứ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 3 Tiêu chuẩn quốc tế, trình bày phương pháp và các tiêu chí đánh giá của các tổ chức đó; Trình bày độ đo các tiêu chí chất lượng phần mềm theo ISO/IEC 9126-2. - Chương 2. Phương pháp đánh giá sản phẩm phần mềm theo tiêu chuẩn chất lượng. Chương này chia nhóm, phân loại các loại phần mềm khác nhau; Trình bày đề xuất về độ đo ngoài cho sản phẩm phần mềm; Khảo sát và đề xuất phương pháp đánh giá phần mềm theo tiêu chuẩn chất lượng cho một số loại phần mềm; Chi tiết thang điểm cho từng tiêu chí đánh giá cụ thể. - Chương 3. Xây dựng một số tiêu chuẩn chất lượng phần mềm. Đặt vấn đề cho bài toán Quản lý trong trường học hiện nay; Nêu những phần mềm được ứng dụng cho bài toán đó và nhu cầu cần được đánh giá; Áp dụng các phương pháp được đề xuất ở Chương 2, đánh giá Phần mềm Quản lý trường học V.EMIS; Xây dựng một số tiêu chuẩn của Phần mềm Quản lý trường học V.EMIS. - Phần kết luận và hướng phát triển. - 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 4 Chƣơng 1 QUY 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 1.1. Các thuật ngữ Chất lượng: Là một tập hợp các tính chất và đặc trưng của sản phẩm tạo ra cho nó khả năng thỏa mãn nhu cầu đã được nêu ra hoặc còn tiềm ẩn. Chất lượng ngoài: Là toàn bộ các đặc điểm của sản phẩm phần mềm từ góc độ của người đánh giá phần mềm độc lập. 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. Chất lượng trong: Là tổng hợp của tất cả các đặc điểm của sản phẩm phần mềm từ góc độ của người phát triển phần mềm. Chất lượng sử dụng: Là cách nhìn của người sử dụng về chất lượng sản phẩm phần mềm khi nó được cài đặt trong một môi trường và ngữ cảnh cụ thể. Đá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. Đo đạc: Là quá trình gán một giá trị hoặc phân loại cho một thực thể để mô tả một thuộc tính của thực thể. Luật đo (metric): Là phương pháp đo, cũng như thang đo dùng trong các phép đo đạc. Mô hình chất lượng: Là tập hợp các tiêu chuẩn dùng để chỉ ra các yêu cầu về chất lượng cũng như đánh giá chất lượng của sản phẩm phần mềm. 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. Quy trình: Là phương pháp thực hiện hoặc các bước sản xuất ra sản phẩm. Sản phẩm phần mềm: Là tập hợp các chương trình máy tính, thủ tục, tài liệu liên quan, cũng như dữ liệu đi kèm. 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ả. 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 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. Tiêu chuẩn hóa: Là hoạt động thiết lập các điều khoản để sử dụng chung và lặp đi lặp lại đối với những vấn đề thực tế hoặc tiềm ẩn nhằm đạt được mức độ trật tự tối ưu trong những khung cảnh nhất định. 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 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 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 đơn giản: Mức độ dễ hiểu của một chương trình. 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 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. 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 ổn đinh: Là khả năng của sản phẩm phần mềm tránh được các tác động bất ngờ từ các cải biên của phần mềm. 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 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 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 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. 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 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 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 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 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. 1.2. Quy trình phát triển phần mềm Quy trình phát triển phần mềm được bắt đầu từ khi hình thành ý tưởng và bao gồm nhiều vòng đời dưới dạng đường xoắn ốc. Quy trình này thể hiện sự hoàn thiện dần từng giai đoạn của dòng sản phẩm theo thời gian. Mỗi vòng đời thường bắt đầu từ công đoạn thiết kế, đặc tả các yêu cầu từ phía khách hàng đối với hệ thống và kết thúc sau công đoạn kiểm định chấp nhận một phiên bản của sản phẩm. Vòng đời tiếp theo là một bước phát triển để tạo ra một phiên bản mới của dòng sản phẩm do công ty phần mềm đang bảo trì. Quy trình phát triển phần mềm thường được thực hiện bởi thứ tự các thao tác: Phân tích yêu cầu; Thiết kế sơ bộ; Thiết kế chi tiết; Lập trình và kiểm định đơn vị; Tích hợp và kiểm định tích hợp; Kiểm định hệ thống; Khai thác và bảo trì hệ thống. 1.2.1. Các giai đoạn của quy trình phát triển phần mềm Nhiều tổ chức phần mềm khác nhau có thể có các quy trình phát triển phần mềm khác nhau; Tên gọi của mỗi giai đoạn phát triển cũng khác nhau. Nhưng hầu hết mọi phần mềm đều được xây dựng theo thứ tự các giai đoạn như: - Nghiên cứu sơ bộ (Preliminary Investigation); - Phân tích hệ thống phần mềm (Analysis); - Thiết kế hệ thống (Design of the System); - Xây dựng phần mềm (Software Constrution); - Thử nghiệm hệ thống (System Testing); - Thực hiện, triển khai (System Implementation); - Bảo trì, nâng cấp (System Maintenance). 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 1.2.1.1. Nghiên cứu sơ bộ Trước khi bắt tay vào một dự án, cần tạo một bức tranh về ý tưởng. Ý tưởng này phải nắm bắt các yêu cầu và xuất hiện trong giai đoạn khởi đầu. Các hoạt động trong thời gian này thường bao gồm thu thập các ý tưởng, nhận biết rủi ro, nhận biết các giao diện bên ngoài, các chức năng chính mà hệ thống cần cung cấp, và có thể tạo một vài nguyên mẫu dùng để “chứng minh các khái niệm của hệ thống”. Ý tưởng có thể đến từ nhiều nguồn khác nhau: Khách hàng, chuyên gia trong lĩnh vực này, các nhà phát triển khác, chuyên gia về kỹ nghệ, các bản nghiên cứu tính khả thi cũng như việc xem xét các hệ thống khác đang tồn tại. Một khía cạnh cần lưu ý là code viết trong thời kỳ này thường sẽ bị “bỏ đi”, bởi chúng được viết nhằm mục đích thẩm tra hay trợ giúp các giả thuyết khác nhau, chứ chưa phải code được viết theo kết quả phân tích và thiết kế thấu đáo. Giai đoạn này, nhóm phát triển hệ thống cần xem xét các yêu cầu của doanh nghiệp (cần dùng hệ thống), những nguồn tài nguyên có thể sử dụng, công nghệ cũng như cộng đồng người dùng cùng các ý tưởng của họ đối với hệ thống mới. Ngoài ra người ta cũng tiến hành tạo một phiên bản thô của lịch trình và kế hoạch sử dụng tài nguyên. Một giai đoạn nghiên cứu sơ bộ không được thực hiện sẽ dẫn tới các hệ thống không được như mong muốn, tốn nhiều chi phí, bất khả thi và được định nghĩa lầm lạc. Kết quả của giai đoạn nghiên cứu sơ bộ là Báo cao kết quả nghiên cứu tính khả thi. Khi hệ thống tương lai được chấp nhận dựa trên bản báo cáo này cũng là lúc giai đoạn phân tích bắt đầu. 1.2.1.2. Phân tích hệ thống phần mềm Đây được coi là giai đoạn quan trọng nhất trong công việc lập trình, người thực hiện nó là nhà phân tích. Quá trình phân tích trả lời cho câu hỏi “Hệ thống cần phải làm gì?”. Quá trình phân tích này bao gồm việc nghiên cứu chi tiết hệ thống, tìm cho ra nguyên lý hoạt động của nó và những vị trí có thể được cải thiện hoặc nâng cao hơn. Ngoài ra, phân tích còn là việc xem xét các chức năng mà hệ thống cần cung cấp, các mối quan hệ giữa chúng, mối quan hệ bên trong với phía ngoài hệ 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 thống. Trong toàn bộ giai đoạn này, nhà phân tích và người dùng cần cộng tác mật thiết với nhau để xác định các yêu cầu đối với hệ thống, tức là các tính năng mới cần phải được đưa vào. Những mục tiêu cụ thể của giai đoạn này là: - Xác định hệ thống cần phải làm gì. - Nghiên cứu thấu đáo tất cả các chức năng cần cung cấp và những yếu tố liên quan. - Xây dựng mô hình nêu bật bản chất vấn đề từ một hướng nhìn có thực. - Định nghĩa vấn đề cho chuyên gia lĩnh vực để nhận sự đánh giá, góp ý. - Kết quả của giai đoạn này là bản Đặc tả yêu cầu (Requirements Specifications). 1.2.1.3. Thiết kế hệ thống Sau giai đoạn phân tích, khi các yêu cầu cụ thể đối với hệ thống đã được xác định, giai đoạn tiếp theo là thiết kế cho các yêu cầu mới. Việc thiết kế giải quyết câu hỏi: Hệ thống làm cách nào để thỏa mãn các yếu cầu đã được nêu trong Đặc tả yêu cầu. Trong giai đoạn thiết kế, các công việc thường được thực hiện là: - Nhận biết form nhập liệu tùy theo các thành phần dữ liệu cần nhập; - Nhận biết reports và những output mà hệ thống mới phải sản sinh; - Thiết kế forms (vẽ trên giấy hay máy tính, sử dụng công cụ thiết kế); - Nhận biết các thành phần dữ liệu và bảng tạo database; - Ước tính các thủ tục giải thích quá trình xử lý từ input đến output. Kết quả giai đoạn thiết kế là Đặc tả thiết kế (Design Specifications). Bản Đặc tả thiết kế chi tiết sẽ được chuyển sang cho các lập trình viên để thực hiện giai đoạn xây dựng phần mềm. 1.2.1.4. Xây dựng phần mềm Đây là giai đoạn viết lệnh (code) thực sự tạo hệ thống. Từng người viết code thực hiện những yêu cầu đã được nhà thiết kế định sẵn. Cũng chính người viết code chịu trách nhiệm viết tài liệu liên quan đến chương trình, giải thích thủ tục (procedure) do mình tạo nên được viết như thế nào và lý do cho việc này. Để đảm bảo chương trình được viết nên phải thỏa mãn mọi yêu cầu có ghi trước trong Bản đặc tả thiết kế chi tiết, người viết code cũng đồng thời phải tiế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 hành thử nghiệm phần chương trình của mình. Phần thử nghiệm trong giai đoạn này có thể được chia thành hai bước chính: - Thử nghiệm đơn vị: Người viết code chạy thử các phần chương trình của mình với dữ liệu giả (test/dummy). Việc này được thực hiện theo một kế hoạch thử, cũng do chính người viết code soạn ra. Mục đích chính trong giai đoạn thử này là xem chương trình có cho ra những kết quả mong đợi. Giai đoạn thử nghiệm đơn vị nhiều khi được gọi là “Thử hộp trắng” (White Box Testing). - Thử nghiệm đơn vị độc lập: Công việc này do một thành viên khác trong nhóm đảm trách, thường chọn người không liên quan trực tiếp đến việc viết code của đơn vị. Chương trình cần thử nghiệm để đảm bảo tính “độc lập”. Công việc thử nghiệm này cũng được thực hiện dựa trên kế hoạch thử do người viết code soạn nên. Kết quả của giai đoạn này là tài liệu về các mã nguồn của mỗi module cùng với lời chú thích. 1.2.1.5. Thử nghiệm hệ thống Sau khi các thủ tục đã được thử nghiệm riêng, cần phải thử nghiệm toàn bộ hệ thống. Mọi thủ tục được tích hợp và chạy thử, kiểm tra xem mọi chi tiết ghi trong Đặc tả yêu cầu và những mong chờ của người dùng có được thỏa mãn. Dữ liệu thử cần được chọn lọc đặc biệt, kết quả cần được phân tích để phát hiện mọi lệch lạc so với mong chờ. Kết quả của giai đoạn Thử nghiệm hệ thống 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, 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. Thực hiện, triển khai Trong giai đoạn này hệ thống vừa phát triển sẽ được triển khai. Trước khi để người dùng thật sự bắt tay vào sử dụng hệ thống, nhóm các nhà phát triển cần tạo các file dữ liệu cần thiết cũng như huấn luyện cho người dùng để đảm bảo hệ thống được sử dụng hữu hiệu nhất. 1.2.1.7. Bảo trì, nâng cấp Bảo trì và nâng cấp phần mềm là công việc trải qua nhiều thách thức nhất trong quá trình phát triển phần mềm. Tùy theo các biến đổi trong môi trường sử 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 dụng, hệ thống có thể trở nên lỗi thời hay cần phải được sửa đổi nâng cấp để sử dụng có hiệu quả. Hoạt động bảo trì hệ thống có thể rất khác biệt tùy theo mức độ sử đổi và nâng cấp cần thiết. Kết quả của của giai đoạn này 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 Vòng đời phần mềm (SLC - Software Life Cycle) là thời kỳ tính từ khi phần mềm được đề xuất sử dụng cho đến khi bị loại bỏ (tức là hình thành đáp ứng yêu cầu vận hành, bảo trì, cho đến khi loại bỏ không đâu dùng nữa). Mô hình vòng đời phần mềm 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. Vòng đời phần mềm được chia thành các pha chính như: Xác định yêu cầu, triển khai, kiểm thử, bảo trì (vận hành)… Phạm vi thứ tự các pha khác nhau tùy theo từng mô hình dự án cụ thể. Vòng đời phần mềm của mỗi sản phẩm nhiều khi có sự khác biệt rất lớn. Có sản phẩm được thiết kế và viết chương trình rất nhanh nhưng lại tốn hàng năm để bảo trì do phải sửa đổi chương trình cho phù hợp với các yêu cầu của khách hàng. Cũng có những sản phẩm phần mềm sau một thời gian sử dụng người ta nhận thấy rằng có lẽ nên viết hẳn một sản phẩm mới hoàn toàn thì sẽ tốt hơn là bảo trì sản phẩm cũ. 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 tăng trưởng (growth model) Một phần mềm ra đời được đưa vào sử dụng, trong quá trình sử dụng ngoài việc phát triển và sửa chữa những sai sót, người ta thấy cần nâng cấp chất lượng bằng cách cải tiến một vài thuật toán hoặc thêm một số chức năng… Mỗi lần nâng cấp như vậy người ta lại dựa trên nền tảng phần mềm đã có và xem xét, sửa đổi lại tài liệu các pha. Trong mô hình tăng trưởng, người ta xem phần mềm bao gồm nhiều thành phần (build) tương đối độc lập nhau. Mỗi thành phần được coi như một 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 11 nhỏ, được thiết kế, lập trình, kiểm thử và đưa cho khách hàng sử dụng theo mô hình thác đổ rồi kết hợp dần thành phần mềm hoàn chỉnh thỏa mãn tất cả các yêu cầu của khách hàng. Thay vì xây dựng phần mềm hoàn chỉnh, người ta xây dựng các phần mềm con rồi tích hợp dần cho tới khi đạt được sản phẩm mong muốn. Ưu điểm của mô hình này là phần đầu tiên chứa đựng những đặc trưng quan trọng nhất được nhanh chóng xây dựng và chuyển giao cho khách hàng sử dụng. Thời gian làm phần đầu tiên này thường rất ngắn so với thời gian xây dựng toàn bộ phần mềm hoàn chỉnh. Như vậy khách hàng được sử dụng sản phẩm trong thời gian ngắn nhất và họ có thể được hưởng lợi từ việc sử dụng phần mềm. Nhờ theo sát từng bước phát triển của phần mềm mà khách hàng có những ý kiến xác đáng, giúp cho nhà phát triển đi đúng hướng và sản phẩm cuối cùng sẽ thỏa mãn được các yêu cầu đặt ra. Tuy nhiên, khó khăn trong việc sử dụng mô hình tăng trưởng chính là sự tích hợp phần mới phát triển với phần chương trình đã có, vì thế thiết kế phải có tính mở và tính mềm dẻo để thích nghi với việc mở rộng dần. Sự điều khiển toàn bộ quy trình phát triển phần mềm có thể bị mất và sản phẩm nhận được thay vì có tính mở lại là khó khăn cho những người bảo trì. Nếu không có những nhà chuyên môn trình độ cao thì sản phẩm phát triển theo mô hình này có thể trở thành sản phẩm kém chất lượng. Nếu phần mềm có thể phân chia thành những thành phần tương đối độc lập nhau thì có thể áp dụng mô hình này. Với những bài toán như xây dựng phần mềm Quản lý dịch vụ bay ở các công ty hàng không; Chương trình Quản lý tín dụng ngân hàng, Quản lý trường học… Tính liên kết giữa các phần khá cao thì không nên áp dụng mô hình này. 1.2.2.2. Mô hình đồng bộ và ổn định (Synchronize-And-Stabilize Model) Trong mô hình này, pha xác định yêu cầu được thực hiện bằng cách phỏng vấn rất nhiều khách hàng dự kiến. Các đặc trưng của nhu cầu khách hàng được liệt kê theo thứ tự ưu tiên, sau đó tài liệu đặc tả được soạn thảo. Tiếp theo, công việc được chia làm ba hoặc bốn phần. Phần thứ nhất chứa các đặc trưng quan trọng nhấ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 12 phần thứ hai chứa các đặc trưng quan trọng thứ hai… Mỗi thành phần sẽ được xây dựng bởi một số nhóm nhỏ làm việc song song. Cuối mỗi ngày, các nhóm đồng bộ hóa (Synchronize), tức là họ hợp lại các phần họ đã làm riêng biệt thành một phần đồng nhất, sau đó họ kiểm tra, sửa lỗi và kiểm thử. Sự ổn định hóa (stabilize) được thực hiện ở giai đoạn cuối của mỗi phần. Trong giai đoạn này những lỗi còn sót lại được phát hiện, được sửa chữa và thành phần được đóng gói (frozen), tức là không thực hiện thay đổi nào đối với đặc tả. Các bước đồng bộ hóa được lặp lại bảo đảm rằng các thành phần khác nhau có thể được kết hợp và cùng làm việc tốt. Một điểm lợi của cách làm này là những người phát triển có thể sớm nhìn thấy sự hoạt động của phần mềm và có thể hiệu chỉnh các yêu cầu ngay trong quá trình các thành phần được xây dựng. Mô hình này có thể áp dụng ngay cả trong trường hợp các đặc tả ban đầu không hoàn thiện. 1.2.2.3. Mô hình hướng đối tượng (Object-Oriented model) Trong mô hình hướng đối tượng, tính lặp giữa các pha và giữa các phần trong một pha xảy ra nhiều hơn so với mô hình khác. Một trong những mô hình giống như mô hình hướng đối tượng là mô hình núi đồi, nó được biểu diễn bằng các hình tròn có một phần chồng lên nhau. Bên trong các vòng tròn có các mũi tên uốn cong ngụ ý nói rằng trong mỗi pha cũng có tính lặp giữa các phần. Các pha có phần chung là: - Pha yêu cầu và pha phân tích hướng đối tượng. - Pha thiết kế hướng đối tượng, pha lập trình và tích hợp. - Pha sử dụng và bảo trì. Kết luận: Có rất nhiều mô hình vòng đời phần mềm, tuy nhiên các mô hình nói chung có những thành phần tương tự nhau, chúng chỉ khác nhau ở trình tự tổ hợp, lắp ghép các thành phần. Điểm khác biệt nổi trội giữa các mô hình là các vòng lặp thể hiện quy trình làm mịn tại các pha của quy trình. 1.3. Chất lƣợng phần mềm Như đã nêu ở phần mở đầu, chất lượng phần mềm có nhiều cách định nghĩa khác nhau tùy theo cách nhìn của mỗi đối tượng người dùng. Từ cách nhìn của khách hàng, chất lượng được xác định là việc đáp ứng nhu cầu và đạt tới sự thỏa 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