Kiểm định phần mềm ứng dụng trên hệ thống phần mềm dịch vụ cho điện thoại di động

Kiểm định phần mềm ứng dụng trên hệ thống phần mềm dịch vụ cho điện thoại di động Kiểm định phần mềm ứng dụng trên hệ thống phần mềm dịch vụ cho điện thoại di động Kiểm định phần mềm ứng dụng trên hệ thống phần mềm dịch vụ cho điện thoại di động luận văn tốt nghiệp,luận văn thạc sĩ, luận văn cao học, luận văn đại học, luận án tiến sĩ, đồ án tốt nghiệp luận văn tốt nghiệp,luận văn thạc sĩ, luận văn cao học, luận văn đại học, luận án tiến sĩ, đồ án tốt nghiệp

M ỀM DỊCH VỤ CHO ĐIỆN THOẠI DI ĐỘNG

Chuyên ngành : Công nghệ thông tin

LUẬN VĂN THẠC SĨ KHOA HỌC CÔNG NGHỆ THÔNG TIN

NGƯỜI HƯỚNG DẪN KHOA HỌC:

TS Trần Minh

Hà Nội – 2011

i

L ời cam đoan

Tôi xin cam đoan: Bản luận văn này là công trình nghiên cứu thực sự của cá

nhân, được thực hiện trên cơ sở nghiên cứu lý thuyết, khảo sát các hệ thống phần

mềm trong thực tiễn và dưới sự hướng dẫn khoa học của Tiến sĩ Trần Minh

Các số liệu và những kết quả trong luận văn là trung thực Phương án đánh

giá, kiểm định chất lượng hệ thống phần mềm dịch vụ cho điện thoại di động đưa ra

xuất phát từ thực tiễn sản xuất tại đơn vị công tác của cá nhân tôi, chưa từng được

công bố dưới bất cứ hình thức nào trước khi trình và bảo vệ

Một lần nữa, tôi xin khẳng định về sự trung thực của lời cam kết trên

ii

Danh m ục các ký hiệu, các chữ viết tắt

chức tiêu chuẩn hóa quốc tế

2 ISO/IEC 9126 Tiêu chuẩn số 9126 (tiêu chuẩn này là kết quả từ các

công việc của JTC1)

4 ISO/IEC 14598 Tiêu chuẩn số 14598 (tiêu chuẩn này là kết quả từ các

công việc của JTC1)

không dây)

iii

Danh m ục các bảng

3

Bảng 1: Bảng các trọng số chất lượng đối với các phân hệ của hệ thống phần mềm

dịch vụ cho điện thoại di độngU 35 3

Bảng 2: Hàm trọng số cho các thuộc tính chất lượngU 39 3

Bảng 3: Tiêu chuẩn xếp hạng phần mềmU 39 3

Bảng 4: Mức chất lượng của các phân hệ trong hệ thống phần mềm dịch vụ cho điện thoại di độngU 40 3

Bảng 5: Trọng số cho các độ đo các thuộc tính chất lượng hệ thống phần mềm dịch

vụ cho điện thoại di độngU 42 3

Bảng 6: Bảng tiêu chí chất lượngU 44 3

Bảng 7: Bảng phân mức chất lượng dựa trên các yếu tố ảnh hưởng [4]U 46 3

Bảng 8: Bảng mức chất lượng đối với hệ thống phần mềm dịch vụ cho điện thoại di độngU 47 3

Bảng 9: Bảng các kỹ thuật đánh giá chất lượng phần mềm [4]U 48 3

Bảng 10: Bảng các đầu vào đánh giáU 50 3

Bảng 11: Bảng các đặc tính chất lượng và các đặc tính chất lượng conU 53 3

Bảng 12: Bảng thang mức đánh giá chất lượng phần mềmU 58 3

Bảng 13: Bảng mức đánh giá chất lượng phân hệ WAPU 58 3

Bảng 14: Bảng các độ đo chất lượng ngoài và trọng sốU 59 3

Bảng 15: Bảng các độ đo chất lượng sử dụng và trọng sốU 60 3

Bảng 16: Bảng lựa chọn kỹ thuật đánh giá chất lượng phân hệ WAPU 61 3

Bảng 17: Bảng các độ đo chất lượng ngoài cho phân hệ WAP và tiêu chí đoU 67 3

Bảng 18: Bảng các độ đo hiệu suất phân hệ WAP và tiêu chí đoU 68 3

Bảng 19: Bảng các độ đo mức độ an toàn của phân hệ WAP và tiêu chí đoU 69 3

Bảng 20: Bảng các độ đo năng suất phân hệ WAP và tiêu chí đoU 71 3

Bảng 21: Bảng các độ đo mức độ hài lòng đối với phân hệ WAP và tiêu chí đoU 72 3

Bảng 22: Bảng các trường hợp kiểm thửU 73 3

Bảng 23: Các giá trị độ đo thu đượcU 76 3

Bảng 24: Giá trị các đặc trưng conU 77

iv

3

Bảng 25: Giá trị các đặc trưng con theo phương án không thực hiện trên IphoneU 78

v

Danh m ục các hình vẽ

3

Hình 1: Chất lượng phần mềmU 4 3

Hình 2: Tương quan giữa chất lượng với các yêu cầuU 7 3

Hình 3: Mô hình chất lượng trong và chất lượng ngoài của phần mềmU 10 3

Hình 4: Mô hình chất lượng sử dụng theo ISO/IEC 9126U 11 3

Hình 5: Qui trình đánh giá chất lượng phần mềm theo ISO/IEC 14598U 12 3

Hình 6: Chất lượng phần mềm trong chu kỳ sống của phần mềmU 15 3

Hình 7: Sự phụ thuộc của các thuộc tính chất lượngU 17 3

Hình 8: Lựa chọn mức chât lượngU 19 3

Hình 9: Kiến trúc tổng thể hệ thống MobileTVU 25 3

Hình 10: Mô hình phân lớp phân hệ SMSU 26 3

Hình 11: Mô hình phân lớp phân hệ CMSU 28 3

Hình 12: Mô hình phân lớp phân hệ Mobile ClientU 29 3

Hình 13: Mô hình phân lớp phân hệ WEB (Front-end)U 31 3

Hình 14: Mô hình phân lớp phân hệ WAPU 32

2.23 3Kiến trúc và đặc điểm của các phân hệ trong một hệ thống phần mềm dịch

vụ cho điện thoại di động3 26

3

2.2.13 3Phân hệ SMS3 26

3

2.2.23 3Phân hệ CMS(Back-end)3 28 3

2.2.33 3Phân hệ Mobile Client3 29

Chương 3 – XÂY DỰNG QUI TRÌNH ĐÁNH GIÁ CHẤT LƯỢNG HỆ

TH ỐNG PHẦN MỀM DỊCH VỤ CHO ĐIỆN THOẠI DI ĐỘNG VÀ THỰC

Chương 4 – KẾT QUẢ VÀ BÀN LUẬN3 79

1

M Ở ĐẦU

Những năm gần đây, thế giới nói chung và nước ta nói riêng đã chứng

kiến sự phát triển bùng nổ của ngành viễn thông Nếu như trong thập kỷ trước, các hãng viễn thông cạnh tranh nhau về số lượng thuê bao thì những năm trở

lại đây, khi thị trường viễn thông của ta gần như đã bão hòa, việc cạnh tranh chuyển dần sang chất lượng mạng và các dịch vụ đi kèm Chính vì thế, việc phát triển các dịch vụ cho điện thoại di động là chiến lược không thể bỏ qua

của tất cả các công ty viễn thông Chất lượng của các dịch vụ đó càng được coi trọng vì nó là yếu tố quyết định tới sự thành công của mỗi công ty Từ xu hướng chung đó, cùng với thực tế đang làm việc tại một công ty viễn thông, tác giả đã chọn đề tài nghiên cứu và đề xuất phương pháp đánh giá, kiểm định

chất lượng của hệ thống phần mềm dịch vụ cho điện thoại di động

Luận văn tập trung tìm hiểu về các nguyên lý trong kiểm thử, đánh giá

phần mềm, mô hình chất lượng ISO/IEC 9126 và qui trình đánh giá chất lượng

phần mềm ISO/IEC 14598 Tiếp đó, tác giả nghiên cứu đề tìm ra những đặc trưng chung nhất của các hệ thống phần mềm dịch vụ cho điện thoại di động

Từ đó, tác giả đề xuất phương pháp đánh giá chất lượng các hệ thống phần

mềm này Cuối cùng, tác giả thử nghiệm phương pháp đã đề xuất vào một phân hệ của hệ thống phần mềm dịch vụ MobileTV (truyền hình di động qua sóng 3G) và đánh giá kết quả đạt được

2

Chương 1 – TỔNG QUAN

1.1 T ổng quan về kiểm thử và đánh giá chất lượng phần mềm

Kiểm thử giúp đo chất lượng phần mềm với số lượng các lỗi tìm thấy, số lượng trường hợp kiểm thử được thực hiện và độ phủ hệ thống của các kịch

bản kiểm thử Kiểm thử được thực hiện việc này cho cả các thuộc tính chức năng và phi chức năng của phần mềm Một kịch bản kiểm thử được thiết kế tốt

sẽ phát hiện ra các lỗi nếu có và do đó, nếu các trường hợp kiểm thử trong

kịch bản kiểm thử đó đạt, chúng ta sẽ đảm bảo tốt hơn về chất lượng phần

mềm và có thể xác nhận rằng rủi ro ở mức tổng thể của hệ thống đã được giảm

xuống Khi kiểm thử tìm ra lỗi, chất lượng hệ thống tăng lên sau khi các lỗi đó được sửa, với điều kiện việc sửa lỗi được thực hiện một cách đúng đắn

Các dự án có mục đích đưa ra phần mềm phù hợp với đặc tả Để dự án đưa

ra được cái mà khách hàng yêu cầu thì cần có một đặc tả chính xác Thêm vào

đó, hệ thống được chuyển giao phải phù hợp với đặc tả Việc này chính là Validation (Đặc tả có đúng không?) và Verification(hệ thống có đúng với đặc

tả không?) Tất nhiên, cũng như muốn hệ thống phần mềm được xây dựng đúng, khách hàng muốn dự án phải nằm trong ngân quĩ và khoảng thời gian

nhất định – nó cần hoàn thành khi khách hàng muốn và không quá đắt

Một điều rất quan trọng là đội dự án, khách hàng và những bên liên quan đến dự án thiết lập và thỏa thuận về các kết quả mong đợi Chúng ta cần hiểu cái mà khách hàng hiểu là chất lượng và cái mà họ mong đợi là gì Cái mà chúng ta trong vai trò người phát triển và kiểm thử phần mềm coi là chất lượng – là phần mềm đáp ứng các đặc tả đã xác định, là xuất sắc về mặt kĩ thuật và có một số lỗi trong nó – có thể không đưa ra được giải pháp chất lượng cho khách hàng Hơn nữa, nếu khách hàng nhận ra rằng họ đã bỏ ra nhiều tiền hơn họ muốn hoặc phần mềm không giúp đỡ họ thực hiện công việc

của họ, họ sẽ không có ấn tượng gì với ưu điểm kĩ thuật của giải pháp Nếu khách hàng muốn một chiếc ô tô rẻ để đi lại và chỉ có một lượng ngân quĩ nhỏ

3

thì một chiếu ô tô thể thao đắt tiền hoặc một xe tăng không phải là giải pháp

chất lượng, mặc dù chúng được chế tạo rất tốt

1.2 Các nguyên lý trong ki ểm thử và đánh giá chất lượng phần mềm

Hiện nay chúng ta có 7 nguyên lý kiểm thử được đưa ra và công nhận Các nguyên lý này có thể coi là chỉ dẫn chung nhất cho tất cả các kiểu kiểm thử cũng như đánh giá chất lượng phần mềm

Kiểm thử có thể chỉ ra lỗi nhưng không thể chứng minh rằng hệ thống không

có lỗi Việc kiểm thử làm giảm xác suất các lỗi chưa được phát hiện trong

phần mềm, nhưng cho dù ta không tìm thấy một lỗi nào trong phần mềm thì cũng không thể chứng minh rằng phần mềm hoàn toàn không có lỗi

Kiểm thử mọi thứ (tất cả các kết hợp giữa đầu vào với điều kiện đầu) là không

khả thi trừ một số trường hợp tầm thường Thay vì kiểm thử toàn bộ, chúng ta nên đánh giá rủi ro và đặt độ ưu tiên để tập trung nguồn lực kiểm thử

Trong chu trình phát triển phần mềm, việc kiểm thử nên tiến hành càng sớm càng tốt và nên tập trung vào các mục tiêu xác định

Một lượng nhỏ các module chứa hầu hết các lỗi không được tìm ra trước khi

kiểm thử hoặc chỉ ra thất bại khi vận hành

Nếu một kịch bản kiểm thử hoặc một bộ tiêu chí đánh giá cứ lặp đi lặp lại thì

cuối cùng bộ kiểm thử/bộ tiêu chí sẽ không thể phát hiện ra lỗi mới nào nữa

Để khắc phục vấn đề này, kịch bản kiểm thử/tiêu chí đánh giá cần phải được xem xét và sửa lại thường xuyên, và những trường hợp kiểm thử mới/tiêu chí

mới cần được bổ sung để thực hiện những phần khác nhau của phần mềm hoặc

hệ thống nhằm tìm ra nhiều lỗi hơn

4

Việc kiểm thử được thực hiện khác nhau trong những môi trường độc lập Ví

dụ, phần mềm nội bộ phải được kiểm thử khác với một trang web thương mại

Tìm và sửa lỗi sẽ không có giá trị gì nếu như hệ thống không thể dùng được và không đáp ứng nhu cầu cũng như mong đợi của người dùng

1.3 Mô hình ch ất lượng ISO/IEC 9126 [2]

1.3.1 Cách ti ếp cận chất lượng

Chất lượng ngoài

Phụ thuộc vào Phụ thuộc vào

đặc-Việc đánh giá các sản phẩm phần mềm có thỏa mãn các các yêu cầu về

chất lượng hay không là một phần của toàn bộ chu kỳ sống phát triển phần

mềm Chất lượng sản phẩm phần mềm có thể được đánh giá bằng cách đo

kiểm theo các độ đo trong của các thuộc tính (thường là các phép đo tĩnh trong các giai đoạn trung gian của phát triển phần mềm), hoặc theo các độ đo ngoài

của các thuộc tính chất lượng Các yếu tố chất lượng bên trong, bên ngoài và

5

chất lượng sử dụng có ảnh hưởng qua lại như hình 1

Tiến trình chất lượng bao hàm chất lượng trong quá trình phát triển

phần mềm, chất lượng sử dụng được đánh giá qua phản hồi của người sử dụng

sản phẩm phần mềm

Các thuộc-tính-trong của phần mềm là một phần sơ khởi để hiểu được các hành vi của phần mềm (hành-vi-ngoài) và các hành-vi-ngoài là bước sơ

khởi để xác định được các chất-lượng-sử-dụng

1.3.2 Ch ất lượng phần mềm và chu trình sống của phần mềm

Các quan điểm/nhìn nhận vấn đề cho trong, ngoài, chất-lượng-sử-dụng luôn thay đổi trong chu-kỳ-sống của phần mềm Ví

chất-lượng-dụ, chất lượng được mô tả như là các yêu cầu về chất lượng khi mới bắt đầu quá trình phát triển phần mềm, trong giai đoạn này, nhìn chung là giống với

chất-lượng-ngoài và theo cách nhìn nhận của người sử dụng Tuy nhiên, điều này có thể khác với chất lượng phần mềm trong quá trình sản xuất phần mềm,

ví dụ như việc thiết kế phần mềm – là liên quan đến chất-lượng-trong của

phần mềm

Mục tiêu cuối cùng là đạt được chất lượng đầy đủ thỏa mãn các yêu cầu người dùng ISO 8402 xác định chất lượng là khả năng đáp ứng những yêu cầu được phát biểu và các yêu cầu mặc nhiên Tuy nhiên các yêu cầu được phát

biểu bởi người sử dụng không hoàn toàn lúc nào cũng phản ảnh đích thực người sử dụng cần gì vì:

1) Người sử dụng thường không rõ họ cần gì

2) Các nhu cầu có thể thay đổi sau khi người sử dụng đã xác định 3) Người sử dụng khác nhau đôi khi có các môi trường cài đặt phần

6

định được đầy đủ nên cần thiết phải hiểu được điều người sử dụng cần thực sự

là gì một cách càng chi tiết càng tốt, và mô tả nó thành các yêu cầu về chất lượng Mục tiêu không phải là đạt được một chất lượng hoàn hảo mà nên là

một chất lượng cần thiết và đầy đủ cho mỗi một vấn đề đặt ra của người sử

dụng khi sản phẩm phần mềm được cài đặt và sử dụng

Thang đo lường các độ đo sử dụng cho các yêu cầu chất lượng cần được chia thành các phạm trù tương ứng với các mức độ khác nhau về sự thảo mãn các yêu cầu chất lượng Ví dụ, thang đo có thể chia thành hai phạm trù: Không đạt và Đạt hoặc 4 phạm trù: Vượt trội, thỏa mãn, đạt tối thiểu, không

chấp nhận được (ISO 14598-1) Các phạm trù cần được xác định sao cho cả người sử dụng và nhà phát triển tránh được những lãng phí về thời gian hoặc các chi phí không cần thiết

Sau đây là các cách nhìn khác nhau về chất lượng phần mềm ở những chu kỳ phát triển khác nhau (hình 2)

Các nhu c ầu người sử dụng: Có thể được xác định và mô tả dưới dạng

các độ đo chất-lượng-sử dụng Các độ đo này sau này có thể sử dụng làm tiêu chí để đánh giá chất lượng phần mềm Thường thì các sản phẩm phần mềm đạt được yêu cầu nếu quá trình sản xuất phần mềm luôn có sự đóng góp ý kiến và

phản hồi của người sử dụng

Các yêu c ầu chất-lượng-ngoài: xác định và mô tả mức độ chất lượng

từ cái nhìn bên ngoài Bao gồm các yêu cầu được dẫn xuất từ các nhu cầu, bao

gồm các yêu cầu về người-sử-dụng Các yêu cầu về ngoài của phần mềm được sử dụng làm mục tiêu và sử dụng để kiểm định tại

chất-lượng-hầu hết các giai đoạn phát triển phần mềm

Các yêu c ầu chất-lượng-trong: Chỉ ra các yêu cầu từ góc độ bên trong

phần mềm Nó chỉ ra các đặc điểm bên trong của phần mềm, có thể sử dụng

mô hình tĩnh hoặc mô hình động và các tài liệu hoặc mã nguồn Các yêu cầu

chất-lượng-trong của phần mềm có thể sử dụng như là mục tiêu để thẩm định (validation) phần mềm ở các giai đoạn khác nhau phát triển phần mềm Nó

7

cũng có thể được sử dụng để xác định chiến lược để phát triển sản phẩm phần

mềm và các tiêu chí để đánh giá và kiểm tra (verification) phần mềm ở các giai đoạn phát triển Có thể phải dùng tới một số độ đo khác nữa ở giai đoạn này, ví dụ như độ đo tính sử dụng lại (reuseability) mà không thuộc phạm vi

của đề tài này

Hình 2: Tương quan giữa chất lượng với các yêu cầu

Các độ đo trong

Các yêu c ầu

ch ất lượng trong

Ch ất lượng trong

8

Đánh giá (dự báo) lượng ngoài: là các đánh giá, dự báo

chất-lượng-sử-dụng tại mỗi giai đoạn phát triển phần mềm cho các đặc tính chất lượng sử dụng, dựa trên chất-lượng-trong

Ch ất-lượng-ngoài là toàn bộ các đặc tính các đặc tính của phần mềm

dưới góc nhìn từ bên ngoài Đó là chất lượng khi mà phần mềm hoạt động mà

có thể sử dụng độ đo ngoài để đo đạc và đánh giá được khi kiểm thử trong một môi trường mô phỏng với các dữ liệu mô phỏng Khi kiểm thử, phần lớn các

lỗi phần mềm đều được ghi nhận lại và cần phải được sửa chữa Tuy nhiên,

một số lỗi vẫn có thể còn lại sau khi kiểm thử Vì rất khó sửa chữa kiến trúc

phần mềm hoặc là những gì là nền tảng trong thiết kế phần mềm nên kiến trúc

phần mềm vẫn còn lại như cũ sau khi kiểm định

Đánh giá (dự báo) lượng-sử-dụng: là các đánh giá, dự báo

chất-lượng-sử-dụng tại mỗi giai đoạn phát triển phần mềm cho các đặc tính chất lượng sử dụng, dựa trên chất-lượng-ngoài và chất-lượng-trong

Ch ất-lượng-sử-dụng: là chất lượng phần mềm dưới góc độ người sử

dụng Nó đo mức độ đáp ứng các mục tiêu, yêu cầu người sử dụng trong môi trường cụ thể hơn là đo đạc các đặc điểm của chính phần mềm

1.3.3 Các y ếu tố cần đánh giá

Các yếu tố có thể được đánh giá bằng cách đo trực tiếp hoặc gián tiếp thông qua các yếu tố trung gian, qui trình có thể được đánh giá gián tiếp bằng cách đo và đánh giá sản phẩm của nó, sản phẩm có thể được đo đạc và đánh giá gián tiếp thông qua đo đạc các hiệu năng của tác vụ và người dùng

Phần mềm không bao giờ chạy riêng mà luôn là một phần của hệ thống

phần mềm lớn hơn với hệ thống các phần cứng, thiết bị ngoại vi, con người, qui trình làm việc Phần mềm hoàn chỉnh có thể được đánh giá theo lựa chọn

độ đo chất-lượng-ngoài Độ đo này đo sự tương tác với với môi trường và được ghi lại khi quan sát phần mềm trong lúc đang làm việc

Chất-lượng-sử-dụng được đo đạc theo phản hồi của người sử dụng

9

1.3.4 Mô hình ch ất-lượng-trong và chất-lượng-ngoài

Mô hình ISO 9126 đưa ra mô hình lượng-trong và mô hình lượng-ngoài Hai mô hình này dựa trên mô hình chung, và mô hình chung này

chất-có thể sử dụng để đánh giá chất lượng bên trong hoặc bên ngoài tuỳ thuộc vào

tập các đặc tính sử dụng để đánh giá Mô hình chung này được xây dựng dựa trên sáu đặc tính:

1 Tính năng (Functionality)

2 Độ ổn định hoặc khả năng tin cậy (Reliability)

3 Tính khả dụng (Usability)

4 Tính hiệu quả (Efficiency)

5 Khả năng duy trì (Maintainability)

6 Tính khả chuyển (Protability)

10

Tính khả dụng

Tính hiệu quả

(Efficiency)

Chất lượng trong và chất lượng ngoài

(External and Internal Quality)

Khả năng duy trì

(Maintainabi lity)

Tính khả chuyển

Khả năng chịu lỗi (FaultToleran cE)

Khả năng phục hồi (Recoverabili ty)

Tuân thủ đặc tính tin cậy (Reliability Compliance)

hệ thống (Learnability)

Hoạt động của các chức năng (Operability)

Hấp dẫn của giao diện (Attractivenes s)

Tuân thủ đặc tính khả dụng (Usability Compliance)

Thời gian đáp ứng (Time Behavior)

Sử dụng tài nguyên hệ thống (Resource Utilisation ) Tuân thủ đặc tính hiệu quả (Efficiency Compliance)

Khả năng phân tích (Analysabilit y)

Khả năng thay đổi (Changeabilit y)

Độ ổn định (Stability)

Khả năng kiểm tra (Testability)

Tuân thủ đặc tính duy trì (Maintainabil ity Compliance)

Khả năng thích ứng (Adaptability)

Khả năng cài đặt (Installabilit)

Khả năng cùng tồn tại hoạt động (Co- Exsitence) Khả năng thay thế (Replaceabilit y)

Tuân thủ đặc biệt tính khả năng (Portability Compliance)

Hình 3: Mô hình ch ất lượng trong và chất lượng ngoài của phần mềm

11

Đây là một mô hình đang được sử dụng đánh giá hiệu năng, độ an toàn,

độ tin cậy, sự hài lòng vv những đặc trưng này bao quát nên toàn bộ chất lượng sản phẩm phần mềm nhưng có thể dựa vào những khía cạnh đặc trưng

của nó để áp dụng đánh giá sản phẩm chất lượng phần mềm

Mô hình ISO 9126 sử dụng cho việc đánh giá chất lượng bên trong và bên ngoài và chất lượng sử dụng Tuy nhiên ta sẽ chỉ xem xét đến các đặc tính

chất lượng đánh giá ngoài

(Productivity)

Tính thỏa mãn

(Satisfaction)

Chất lượng sử dụng (Quality in use)

Hình 4: Mô hình ch ất lượng sử dụng theo ISO/IEC 9126

Mô hình chất-lượng-sử-dụng là chất lượng dưới góc độ người sử dụng Đạt được chất lượng người sử dụng bằng cách dựa vào chất lượng ngoài Chất lượng ngoài lại phụ thuộc vào chất lượng trong Độ đo thường phải được thực

hiện trên cả ba mức trong/ngoài và người sử dụng Độ đo chất lượng trong không đủ để xác định chất lượng ngoài và độ đo chất lượng ngoài không đủ để

12

xác định chất lượng sử dụng

1.4 Qui trình đánh giá chất lượng sản phẩm phần mềm ISO/IEC 14598[3]

Để đánh giá chất lượng phần mềm, trước tiên cần có các yêu cầu đánh giá, các đặc tả, các thiết kế và giai đoạn đánh giá (Hình ) Mỗi bước được miêu tả một cách chi tiết hơn trong các trường hợp cụ thể ISO 14598 đưa ra

tổng quan của quá trình kiểm định

9126-1: Các đặc tính chất lượng

Thiết lập các mục đích đánh giá Xác định loại sản phầm

Hình 5: Qui trình đánh giá chất lượng phần mềm theo ISO/IEC 14598 1.4.1 Các đặc tính cần lưu ý của công việc đánh giá

- Tính có thể lặp lại: Kết quả phải giống nhau nếu lặp lại việc đánh giá trên cùng một sản phẩm với cùng đặc tả đánh giá bởi cùng một người đánh giá

- Tính có thể tái sản xuất: Kết quả phải giống nhau nếu đánh giá cùng

một sản phẩm với cùng đặc tả đánh giá bởi hai người đánh giá khác nhau

- Tính công bằng: Việc đánh giá không được thiên về bất cứ kết quả đặc

13

biệt nào

- Tính khách quan: Các kết quả đánh giá cần phải căn cứ trên thực tế, nghĩa là không bị ảnh hưởng bởi cảm tính hay các quan điểm cá nhân của người đánh giá

Quá trình đánh giá:

Quá trình đánh giá là một quá trình gồm một loạt các hoạt động phối

hợp giữa người đánh giá và người yêu cầu đánh giá Các hoạt động này được

thực hiện trên các dữ liệu do người yêu cầu và người đánh giá hoặc sinh ra bởi các hoạt động khác Dữ liệu do các hoạt động đánh giá sinh ra sẽ được dùng cho các hoạt động khác hoặc trở thành kết quả của quá trình đánh giá

Các vấn đề dưới đây phải được tính khi thiết kế các hoạt động đánh giá:

- Các mục tiêu sẽ thay đổi từ trường hợp đánh giá này sang trường hợp đánh giá khác khi mà các sản phẩm phần mềm được phát triển để đáp ừng các yêu cầu khác nhau và một người yêu cầu đánh giá có thể đồng ý với các yêu

cầu đánh giá đặc biệt

- Các sản phẩm phần mềm được viết từ nhiều thành phần, kiểu dáng và tính chất của phần mềm phụ thuộc vào phương thức phát triển Mà phương

thức này rất có thể thay đổi

- Các kỹ thuật đánh giá có thể áp dụng là rất nhiều và việc lựa chọn cần cân nhắc tới các mục tiêu của việc đánh giá và cấu tạo của sản phẩm

Quá trình phải có độ linh hoạt rất cao để đáp ứng được các vấn đề trên

1.4.2 Thi ết lập các yêu cầu đánh giá

14

• Quy ết định việc chấp nhận ngay một sản phẩm từ một hợp đồng;

• Quy ết định hoàn thành quá trình và khi nào để gửi đến các sản

• Thu th ập thông tin về sản phẩm để kiểm soát và quản lý tiến trình

Mục tiêu cuối cùng của việc đánh giá chất lượng sản phẩm có thể là:

phẩm Nó đã được nói rõ trong ISO/IEC 12207

Loại sản phẩm được đánh giá sẽ phụ thuộc vào giai đoạn trong vòng đời sản phẩm và mục tiêu đánh giá

Mục tiêu là khi sản phẩm được sử dụng, nó phải đáp ứng được những nhu cầu và đảm bảo chất lượng Chất lượng ngoài phần mềm chỉ có thể được đánh giá cho một phần cứng/phần mềm hệ thống trong đó các sản phẩm phần

mềm là một phần Những đặc điểm bên ngoài được đánh giá khi thi hành các

phần mềm Các giá trị của việc đo bên ngoài nhất thiết phải phụ thuộc trên các

phần mềm, do đó phần mềm phải được đánh giá là một phần của một hệ thống làm việc

15

Vì phần mềm để có chất lượng trong sử dụng nó phải đáp ứng nhu cầu người sử dụng cụ thể để thực hiện nhiệm vụ riêng biệt trong môi trường phần

cứng và phần mềm cụ thể Phần mềm mà chạy tốt trong một môi trường thì có

lẽ phải xem chất lượng khuyết tật, sai sót của phần mềm trong một môi trường khác

Yêu cầu chất

Các yêu cầu chất lượng trong

Chất lượng trong

16

Đặc điểm chất lượng bên ngoài do đó có thể được đánh giá theo điều

kiện mà mô phỏng giống như điều kiện mong đợi của người sử dụng Đặc điểm bên ngoài được đo khi giai đoạn coding được hoàn tất, mặc dù vậy nó có

thể không được mô phỏng chính xác điều kiện sử dụng (ví dụ như mạng, môi trường và đặc điểm của người sử dụng), đo thực tế bên ngoài thường chỉ có

chỉ số về thực tế chất lượng trong sử dụng

Nếu những yêu cầu chất lượng bên ngoài không đạt được những kết

quả của việc đánh giá có thể được sử dụng như thông tin phản hồi để sửa đổi các đặc điểm của phần mềm để nâng cao chất lượng bên ngoài, vì vậy hỗ trợ là

một quá trình liên tục cải tiến

Vì mục đích phát triển những yêu cầu chất lượng bên trong được xác định ngay khi có thể kiểm tra chất lượng các sản phẩm Đặc điểm bên trong là

những đánh giá đặc điểm bên trong sản phẩm (như đặc tả hoặc mã nguồn) của

phần mềm Thông thường chỉ nhà phát triển và bảo trì phần mềm hiểu những đặc tính bên trong của phần mềm

Một trong những ví dụ về đặc tính bên trong là tính mô đun và khả năng dò tìm, đánh đấu Đo bên trong một cách trực tiếp là đo thuộc tính bên trong hay các đặc điểm bên trong khác Sự đáp ứng được yêu cầu chất lượng bên trong sẽ góp phần nâng cao chât lượng bên ngoài phần mềm theo yêu cầu

người sử dụng Đặc điểm chất lượng bên trong phần mềm có thể được sử dụng

để đảm bảo cho ước lượng cuối cùng về chất lượng phần mềm

Ví dụ về sự đáp ứng thời gian là một yêu cầu đo rất quan trọng để đánh giá sự hữu dụng và hiệu quả của phần mềm, nhưng khả năng đáp ứng thời gian không thể đo được trong suốt quá trình phát triển Thay vào đó đánh giá hiệu

quả của sản phẩm trong quá trình phát triển là một đường dài có thể đo được trên cơ sở sản phẩm hiện tại hoặc đặc tả của nó Những điều này có thể được

sử dụng như những chỉ thị cho những ước lượng về đáp ứng thời gian dưới

những điều kiện nào đó

Vấn đề rất quan trọng là chất lượng thuộc tính bên trong của phần mềm

17

liên quan trực tiếp đến chất lượng bên ngoài theo yêu cầu khách hàng, vì vậy

mà các đặc điểm chất lượng của sản phẩm phần mềm theo sự phát triển (cả

hiện tại và khi kết thúc dự án sản phẩm phần mềm) có thể được đánh giá cùng đối với trong hệ thống sử dụng cuối cùng - nhu cầu chất lượng Các phép đo bên trong thường có ít giá trị, trừ khi có chứng cứ chứng minh rằng họ đang có liên quan đến chất lượng bên ngoài

Các phép đo việc sử dụng thực tế

Các phép đo bên ngoài

hệ thống máy tính

Các phép đo bên trong phần mềm

Chất lượng sử dụng thực tế

Các đặc tính trong của phần mềm

Các đặc tính ngoài của

hệ thống máy tính Các phép đo

Các phép đo

Các phép đo Các chỉ số

Các chỉ số Các chỉ số

Hình 7: S ự phụ thuộc của các thuộc tính chất lượng

Cụ thể là các thuộc tính bên trong có liên quan đến chất lượng cuối cùng sẽ phụ thuộc vào nội dung điều kiện sử dụng Với một sản phẩm tương tác điều này sẽ phụ thuộc vào các nhu cầu của người sử dụng cuối và nhiệm

vụ

Các vấn đề khác mà ảnh hưởng cho các nhu cầu chất lượng sản phẩm bao gồm các phần mềm cho dù sản phẩm đã mua hoặc đang được phát triển, các giai đoạn phát triển, và các phần cứng, mạng lưới phần mềm và môi trường mà trong đó các sản phẩm sẽ được sử dụng

Các phép đo bên ngoài của một hệ thống máy tính cũng có thể được sử

18

dụng như các biện pháp đo gián tiếp chất lượng bên trong của phần mềm Vì

vậy, trong thời gian đáp ứng của một hệ thống máy tính có thể được sử dụng

để đo lường sự hiệu quả của phần mềm máy tính trong một môi trường cụ thể

Để đánh giá phần mềm điều cần thiết là sử dụng một mô hình chất lượng phần mềm có chất lượng dựa vào những đặc điểm khác nhau ISO/IEC 9126-1 cung cấp một mô hình chung, đó là định nghĩa rộng sáu loại của đặc điểm phần mềm được sử dụng: Tính chức năng, Tính tin cậy, Tính sử dụng, Tính hiệu quả, Tính bảo trì và Tính khả chuyển (dễ mang theo) Đây có thể được tiếp tục chia nhỏ thành các thuộc tính đo được

Thuộc tính chất-lượng-trong của sản phẩm phần mềm là tính năng đo được và thoả mãn các yêu cầu và ứng dụng cần thiết Một hoặc nhiều thuộc tính có thể được sử dụng để đánh giá là một đặc tính riêng của chất lượng

phần mềm hoặc đặc tính con của nó

1.4.3 Mô t ả việc đánh giá

Tùy theo các yêu cầu từ nhiều mục đích sử dụng khác nhau, người ta

lựa chọn mức đánh giá chất lượng khác nhau Bước này cho ta một hồ sơ (profile) chất lượng của phần mềm theo các mức chất lượng áp dụng cho các đặc trưng chất lượng của phần mềm (tính chức năng, tính tin cậy, tính sử dụng, tính hiệu quả, tính duy trì, tính khả chuyển)

19

Hình 8: L ựa chọn mức chât lượng

Ở đây, mức chất lượng phần mềm được xác định dựa trên các yếu tố sau (nguồn: xem phụ lục 14598-5:1998 B):

- Yếu tố an toàn

- Yếu tố kinh tế

- Yếu tố bảo mật

- Yếu tố môi trường

Lựa chọn kỹ thuật đánh giá

Để tạo ra sự so sánh hiệu quả đòi hỏi phải có quá trình đo lường Điều quan trọng là đo lường các sản phẩm phần mềm phải được làm dễ dàng và tiết

kiệm và kết quả đo phải đễ dàng sử dụng Nhiều quá trình đo phần mềm có lẽ đuợc thuận lợi hơn với một vài loại tool

Theo loại đặc điểm chất lượng đã được định nghĩa là không cho phép

đo trực tiếp chúng ta cần lập kiểu đo tương ứng với đặc điểm của sản phẩm

phần mềm đó Mọi số lượng tính năng của phần mềm và mọi số lượng bên

Quá trình đo sử dụng việc so sánh sẽ có hiệu quả và chính xác vì vậy chúng cần được sử dụng trong quá trình đánh giá Những yêu cầu này làm cho

việc đo sẽ theo mục đích, theo kinh nghiệm, có tái sử dụng hay không

Để được mục tiêu, sẽ có được một thoả thuận bằng văn bản và thủ tục cho việc phân công số các loại các thuộc tính của sản phẩm

Để theo kinh nghiệm dữ liệu sẽ được tạo ra từ những quan sát mà không định trước Để theo hướng tái sử dụng các thủ tục của việc đo sẽ có kết

quả giống với các phép đo đang được thu do khác nhau trong cùng một người làm đo lường trên sản phẩm phần mềm vào dịp khác nhau

Độ đo bên trong cũng nên có những dự báo hợp lý, nghĩa là chúng phải tương quan với một số mong muốn tiêu chuẩn bên ngoài Ví dụ một thước đo

nội bộ của một thuộc tính phần mềm nên tương quan với một số đo là khía

cạnh của chất lượng khi các phần mềm được sử dụng Điều quan trọng là đo lường chỉ định các giá trị mà trùng với các giá trị bình thường mong đợi Ví

dụ, nếu đại lượng đo các sản phẩm có chất lượng cao thì này sau đó phải phù

hợp với những đáp ứng của người dùng sản phẩm

Số lượng các tính năng có thể được đo bằng số lượng các phép đo chất lượng được sử dụng Kết quả, giá trị đo là một bản đồ tỉ lệ Giá trị này, không

chỉ mức độ hài lòng của chính nó Cho mục đích này, quy mô để có thể chia

ra thành các phạm vi tương ứng với các cấp độ hài lòng khác nhau của các yêu

cầu Ví dụ: Phạm vi chia thành hai loại: không thỏa mãn và hài lòng

21

Phạm vi chia tỉ lệ vào bốn thể loại bởi cấp độ hiện tại cho một sản phẩm

có sẵn hoặc cho một sản phẩm đã thay đổi, tình huống xấu nhất cho một sản

phẩm và cho kế hoạch tại mức hiện tại Cấp độ hiện tại là trạng thái để điều khiển hệ thống mới mà không làm hỏng từ tình huống hiện tại Cấp độ kế

hoạch là những gì được xem là một thành công với các nguồn tài nguyên sẵn

có Các trường hợp cấp độ tồi tệ nhất là một ranh giới cho người dùng chấp

nhận, trong trường hợp sản phẩm không đầy đủ theo kế hoạch

Những đặc tả kỹ thuật hoặc sẽ được trong điều kiện của các đặc điểm trong ISO/ EC 9126-1 hoặc xác định mô hình chất lượng khác Các biện pháp được xác định trong ISO/IEC 9126-2 và 3 nên được sử dụng khi thích hợp

Chú ý: Không xây dựng được phương pháp cho đặc tả chi tiết chất lượng trongquá trình sản xuất phần mềm

Để đánh giá chất lượng của các sản phẩm, kết quả việc đánh giá những đặc điểm khác nhau phải được tóm tắt Người đánh giá phải chuẩn bị cho thủ

tục thường bao gồm những đánh giá riêng rẽ cho các tiêu chí đặc tính chất lượng khác nhau, Thủ tục thường sẽ bao gồm các khía cạnh như thời gian và chi phí đó góp phần vào việc thẩm định chất lượng của một sản phẩm phần

mềm trong một môi trường nhất định

1.4.4 Thi ết kế các đánh giá

Kế hoạch đánh giá mô tả các phương pháp định giá và lịch trình hành động của người kiểm định (ISO/IEC 14598-5) Có thể nó là một phần của kế

hoạch rộng lớn kế hoạch đo lường (ISO/IEC 14598-2)

1.4.5 Th ực hiện việc đánh giá

22

Phương pháp: Đối với đo lường, các phép đo được lựa chọn được áp

dụng cho các sản phẩm phần mềm Kết quả là giá trị trên quy mô của phép đo

So sánh với các tiêu chí: Trong bước đánh giá, các đánh giá mức độ được xác định cho một giá trị đo

Đánh giá kết quả: Đánh giá là bước cuối cùng của quá trình đánh giá

phần mềm, nơi có một bộ các cấp đang đánh giá tóm tắt Kết quả là một tuyên

bố của các mức độ mà các sản phẩm phần mềm đáp ứng chất lượng yêu cầu Sau đó, các tóm tắt là so chất lượng với các khía cạnh khác như thời gian và chi phí Cuối cùng một quyết định quản lý sẽ được thực hiện dựa trên các tiêu chí quản lý Kết quả là một quản lý, quyết định về việc chấp nhận hay loại bỏ,

hoặc về việc phát hành hay không phát hành của phần mềm sản phẩm Kết quả

của việc đánh giá là quan trọng đối với các quyết định về bước tiếp theo trong phát triển chu kỳ đời sống phần mềm Ví dụ, làm các yêu cầu phải được thay đổi hay có thêm nguồn tài nguyên cần thiết cho quá trình phát triển?

Các hệ thống phần mềm dịch vụ cho điện thoại di động là các hệ thống bao

gồm nhiều phân hệ, trong đó phần lớn các phân hệ giao tiếp với khách hàng

cuối (là những người dùng dịch vụ di động của hãng viễn thông) Chất lượng

của các hệ thống này là vấn đề được đặt lên hàng đầu Do đó, việc đánh giá

chất lượng các hệ thống phần mềm này là thực sự cần thiết Công tác đánh giá,

23

kiểm định chất lượng cần phải có tính chính xác và hiệu quả cao, nhằm phát

hiện ra những thiếu sót trong hệ thống để có những hành động khắc phục, đảm

bảo hệ thống đạt chất lượng trước khi đưa vào phục vụ khách hàng

Để việc kiểm định, đánh giá đáp ứng được các yêu cầu đó, trước tiên, chúng ta cần nghiên cứu đặc trưng của các hệ thống phần mềm dịch vụ cho điện thoại di động Chương tiếp theo sẽ trình bày vấn đề này

24

Chương 2 – HỆ THỐNG PHẦN MỀM DỊCH VỤ CHO ĐIỆN THOẠI

DI ĐỘNG VÀ CÁC YẾU TỐ ĐẶC TRƯNG

2.1 T ổng quan về hệ thống phần mềm dịch vụ cho điện thoại di động

Phân tích các hệ thống phần mềm dịch vụ cho điện thoại di động thì

thấy có các đặc điểm đặc thù sau:

2.1.1 Đối tượng của phần mềm

• Khách hàng có nhu cầu sử dụng dịch vụ cho điện thoại di động

• Bộ phận chăm sóc khách hàng của nhà cung cấp dịch vụ

• Bộ phận quản trị hệ thống: Quản lý thành viên, Quản lý quyền, Quản lý vận hành hệ thống

• Nhân viên kinh doanh: Theo dõi thống kê báo cáo hiện trạng dịch vụ, hiện trạng thuê bao

• Nhà cung cấp nội dung cho phần mềm

2.1.2 V ề đặc điểm kỹ thuật

• Phần mềm thường được xây dựng trên mô hình 3 lớp với nhiều phân hệ

• Phần mềm được sử dụng lâu dài, cần có nâng cấp, bảo trì

• Việc đảm bảo nhu cầu mở rộng theo chiều ngang cũng là một tính năng kỹ thuật của phần mềm ngày càng được quan tâm và đòi hỏi từ các nhà quản lý

2.1.3 Ki ến trúc của các hệ thống phần mềm dịch vụ cho điện thoại di

• WEB(Front-end)/WAP: cho phép người dùng truy cập, sử dụng

dịch vụ trên các thiết bị đầu cuối

• Client: cho phép người dùng sử dụng các ứng dụng của dịch vụ trên điện thoại di động

Tham khảo mô hình kiến trúc của hệ thống dịch vụ Truyền hình di động qua sóng 3G

Mobile TV System

SMS Service Web

frontend

Teco core network

Media Service

CMS

Database

Exchange Gateway

Send/Receive Sms (SMPP)

VTC, IPTV, HTVC

Generate CDR

S

M S Player

http

Media Process

ws

ws

WAP Service

rtsp/rtp Player

Trừ tiền trả sau

Trừ tiền trả trước

Administrator Content Provider Call Center NV Kinh doanh

ws ws

26

2.2 Ki ến trúc và đặc điểm của các phân hệ trong một hệ thống phần mềm

d ịch vụ cho điện thoại di động

2.2.1 Phân h ệ SMS

SMSC

Communication Layer

Sender

Data Access Layer

JDBC

Data

SMS Gateway

o Lớp giao tiếp truyền thông (Communication Layer):

- Đảm nhận việc giao tiếp với SMS Gateway để nhận / gửi tin nhắn từ khách hàng Bao gồm 2 module chính:

 Receiver: Nhận tin nhắn từ SMS Gateway qua giao

thức TCP/IP

27

 Sender: Gửi tin nhắn đến SMS Gateway qua giao

thức SOAP

o Lớp xử lý (Process Layer):

- Bao gồm các tiến trình xử lý tin nhắn

- Gửi request tới mobile tv service để thực hiện yêu cầu của thuê bao như: đăng ký, hủy, mua thêm giờ, v.v

o Lớp dữ liệu (Data Access Layer):

- Thực hiện kết nối tới hệ thống CSDL để lưu trữ giao dịch tin nhắn của khách hàng

- Cung cấp service thực thi giữa tầng process layer và comunication layer để lấy dữ liệu từ CSDL hoặc chuyển dữ

28

2.2.2 Phân h ệ CMS(Back-end)

Web server

View Controller

Model (PDO)

Internet

Service

XML-RPC/HTTP

CSKH, Quản trị hệ thống, Quản trị nội dung

CP, báo cáo thống kê

Database server

Symphony Framework

Hình 11: Mô hình phân l ớp phân hệ CMS

Phân hệ CMS được phân chia thành 3 lớp như sau:

o Model: là lớp chứa các câu lệnh thao tác trực tiếp đến CSDL

o View: làm nhiệm vụ render trang web từ các action do controller truyền sang + dữ liệu từ model (có thể hiểu nó như là template render)

29

o Controller: chính là phần cốt lỗi, điều hành trang web, giao tiếp

với MobileTV Service

Phân hệ này thực hiện các chức năng về quản trị hệ thống và quản trị nội dung, là nền tảng cho các phân hệ khác

Đối tượng phục vụ của phân hệ CMS chính là các bộ phận của nhà cung cấp

dịch vụ (bộ phận chăm sóc khách hàng, bộ phận cung cấp nội dung, bộ phận

quản trị hệ thống)

Đặc điểm yêu cầu về kỹ thuật:

- Chính xác về chức năng

- Tính sử dụng tài nguyên (bộ nhớ, lưu trữ) hiệu quả (cluster)

J M E P o

l i s h

Memory Card

press key

display

JSON/HTTP Phân hệ Web frontend

Hình 12: Mô hình phân l ớp phân hệ Mobile Client

30

Phân hệ Mobile Client cho phép người dùng tương tác với dịch vụ qua ứng

dụng mobile do dịch vụ cung cấp được cài đặt trên điện thoại di động

Người dùng cài đặt, chạy ứng dụng mobile do dịch vụ cung cấp Ứng dụng hỗ

trợ người dùng tương tác, sử dụng dịch vụ: đăng ký/hủy dịch vụ, thêm/xóa kênh, thêm/xem giờ, xem/tải/tặng VOD, xem LiveTV…

Phân hệ Mobile Client giao tiếp với phân hệ Web Frontend (Web Frontend sẽ giao tiếp với Service hoặc truy vấn trực tiếp CSDL): Lấy dữ liệu theo từ API

mà Web Frontend cung cấp qua HTTP request

Đối tượng phục cụ của phân hệ Mobile client là các khách hàng sử dụng dịch

- Đáp ứng được trên nhiều dòng điện thoại

- Tính dễ hiểu với người sử dụng, hỗ trợ người sử dụng

php html

Style sheets

Mobile Client

Hình 13: Mô hình phân l ớp phân hệ WEB (Front-end)

Phân hệ Web-Frontend cho phép người dùng tương tác với dịch vụ qua ứng

dụng client được cài trên thiết bị di động

Người dùng truy cập tới web site của dịch vụ bằng thiết bị di động Hệ

thống phục vụ các yêu cầu của người dùng: đăng ký/hủy dịch vụ, thêm/xóa kênh, thêm/xem giờ, xem/tải/tặng VOD, xem LiveTV…

Phân hệ này giao tiếp với phân hệ Mobile Client: Cung cấp API, trả về

dữ liệu khi có HTTP request gửi đến từ Mobile Client

Đối tượng phục vụ của phân hệ WEB(front-end) là những khách hàng

có nhu cầu sử dụng dịch vụ và/hoặc quan tâm tới dịch vụ

Đặc điểm yêu cầu về kỹ thuật: