Độ tin cậy của chương trình máy tính là một yếu tố quan trọng của chất lượng toàn bộ của nó. Nếu một chương trình cứ lặp lại và thường xuyên không thực hiện được hoặc có lỗi thì hầu như các nhân tố chất lượng phần mềm có chấp nhận được cũng không thành vấn đề nữa.
Độ tin cậy phần mềm, không giống như nhiều yếu tố chất lượng khác, có thể được đo trực tiếp và ước lượng bằng cách dùng dữ liệu lịch sử và đang phát triển. Độ tin cậy phần mềm được định nghĩa dưới dạng thống kê như “xác suất vận hành không thất bại của chương trình máy tính trong một môi trường xác định với một thời gian xác định”. Ví dụ: chương trình X được ước lượng có độ tin cậy 0,96 với thời gian xử lý 8 tiếng đồng hồ, tức là nếu chương trình X được thực hiện 100 lần và cần 8 giờ xử lý thì có thể vận hành đúng (không thất bại) 96 lần.
c d e f R1 R2 R3 R4 R5 V(G) =5
Đo độ tin cậy và tính sẵn có:
Nếu xem xét một hệ thống dựa trên máy tính thì cách đo đơn giản về độ tin cậy là thời gian trung bình giữa những lần thất bại (MTBF):
MTBF = MTTF + MTTR Trong đó:
MTTF: thời gian trung bình của thất bại MTTR: thời gian trung bình để sửa chữa tương ứng.
Nhiều nhà nghiên cứu biện minh rằng MTBF là cách đo có ích hơn nhiều so với cách đo khiếm khuyết. Nói một cách đơn giản, người dùng cuối cùng quan tâm tới những thất bại, không mấy quan tâm tới số lỗi toàn bộ. Vì mỗi lỗi bao hàm trong chương trình không có cùng tỉ lệ thất bại, nên số lỗi toàn bộ ít được đưa ra chỉ báo về độ tin cậy của hệ thống. Ví dụ: hãy xét một chương trình đã vận hành 14 tháng, nhiều lỗi trong chương trình còn chưa được phát hiện, MTBF của những lỗi không rõ ràng này có thể lên đến 50 đến 100 năm. MTBF. Những lỗi khác chừng nào còn chưa được phát hiện ra có thể có tỷ lệ thất bại từ 18 đến 24 tháng. Ngay cả nếu mọi lỗi trong phân loại đầu tiên có bị loại bỏ ra thì tác động nên độ tin cậy phần mền vẫn không đáng kể.
Bên cạnh việc đo độ tin cậy, phải phát triển một cách đo tính có sẵn. Tính sẵn có của phần mền là xác suất một chương trình vận hành theo yêu cầu tại một điểm nào đó trong thời gian :
Tĩnh sẵn có = 100%
MTTR MTTF
MTTF
3.5 Cách tiếp cận bảo đảm chất lượng phần mềm
Lịch sử đảm bảo chất lượng trong phát triển phần mềm đi song song với lịch sử của chất lượng chế tạo phần cứng. Trong những ngày đầu của tin học (những năm 1950 và 1960) chất lượng là trách nhiệm duy nhất của người lập trình. Các chuẩn về đảm bảo chất lượng phần mềm đã được đưa vào trong các hợp đồng phát triển phần mềm đã nhanh chóng lan rộng trong thế giới phát triển phần mềm thương mại. Đảm bảo chất lượng phần mềm SQA (Software Quality Assurance) là một “mẫu hình hành động có hệ thống và có kế hoạch”. Những người thực hiện SQA phải nhìn vào phần mềm theo quan điểm của khách hàng. Phần mềm có đáp ứng được các nhân tố chất lượng đã nêu trên không. SQA bao gồm 7 hoạt động chính: (1) Áp dụng các phương pháp kỹ thuật, (2) Tiến hành các xét duyệt kỹ thuật chính thức, (3) Kiểm thử phần mềm, (4) Buộc tôn trọng các chuẩn, (5) Kiểm soát thay đổi, (6) Đo, (7) Lưu giữ và báo cáo kết quả ghi lại.
Mặc dù nhiều nhà quản lý và người phát triển sẽ tranh luận nhiều nhu cầu phát triển phần mềm nhưng nhiều người không quan tâm tới việc thiết lập các chức năng SQA hình thức. Có nhiều nguyên nhân cho sự mâu thuẫn này .
1. Người quản lý ngần ngại gánh thêm chi phí phụ tăng thêm 2. Người phát triển cảm thấy họ đã làm xong những thứ cần làm 3. Không ai biết phải đặt chức năng này ở đâu trong tổ chức
4. Mọi người đều muốn tránh việc SQA được công nhận phải đưa vào tiến trình kỹ nghệ phầm mềm.
Mục này thảo luận ngắn về mối quan tâm quan trọng nhất cho việc tiến hành các hoạt động đảm bảo chất lượng phần mềm.
Xem xét nhu cầu cho SQA
Tất cả mọi tổ chức phát triển phần mềm đều có một cơ chế nào đó để thẩm định chất lượng. Trước khi các thủ tục đảm bảo chất lượng chính thức được thiết lập, tổ chức phát triển phần mềm nên chấp nhận các thủ tục, phương pháp, công cụ kỹ nghệ phần mềm. Phương pháp luận này khi được tổ hợp với một khuôn cảnh (đã thảo luận trong Chương II) thì có thể cải thiện rất nhiều chất lượng của tất cả các phần mền của tổ chức đó tạo ra . Bước đầu tiên cần được tiến hành là kiểm toán SQA/SCM. Trạng thái hiện tại của việc bảo đảm chất lượng phần mềm là việc quản lý cấu hình phần mềm được thẩm định bằng cách xem xét các chủ đề sau:
Đường lối, thủ tục và các chuẩn hiện thời nào đang tồn tại cho mọi giai đoạn phát triển phần mềm? chúng có phải là bắt buộc không? có một đường lối riêng cho SQA không? Các đường lối có được áp dụng cho tất cả các hoạt động phát triển lẫn bảo trì không?
Tổ chức kỹ nghệ phần mềm nằm ở đâu trong sơ đồ tổ chức hiện tại? Việc bảo đảm chất lượng nằm ở đâu?
Giao diện chức năng: Đâu là mối quan hệ hiện thời giữa việc bảo đảm chất lượng và các thể chế khác. SQA tương tác thế nào với những người thực hiện các xét duyệt kỹ thuật quản lý cấu hình và kiểm thử?
Một khi những vấn đề trên đã được trả lời thì những điểm mạnh, điểm yếu cũng được xác định nếu nhu cầu cho SQA là rõ ràng thì việc thẩm định cẩn thận về những ý kiến ủng hộ và phản đối sẽ được xem xét .
Về phía tích cực SQA đưa ra những ích lợi sau:
1. Phần mềm sẽ có ít khiếm khuyết tiềm tàng hơn giúp giảm bớt nỗ lực và thời gian dành cho kiểm thử và bảo trì.
2. Độ tin cậy cao hơn sẽ làm nảy sinh sự thoả mãn lớn hơn cho khách hàng . 3. Chi phí bảo trì có thể được rút bớt.
4. Chi phí vòng đời toàn bộ của phầm mềm giảm.
Về phía tiêu cực :
SQA có thể gây ra vấn đề bởi những lý do sau:
1. Khó mà thiết lập được trong những tổ chức nhỏ nơi các tài nguyên sẵn có để thực hiện các hoạt động cần thiết là không sẵn sàng (adsbygoogle = window.adsbygoogle || []).push({});
2. Nó biểu tượng cho một truyền thống và việc thay đổi không bao giờ dễ dàng . 3. Nó đòi hỏi chi phí tiền của và nếu không có thì sẽ không lập ngân sách tường minh cho kỹ nghệ phần mềm hay bảo đảm chất lượng phần mềm được.
Tại mức nền tảng SQA là chi phí hiệu quả nếu: C3> C1 + C2
C3 Chi phí cho việc lỗi xuất hiện với chương trình không có SQA C2 là chi phí cho lỗi không được phát hiện ra bởi các hoạt động SQA C1 Là chi phí của bản thân chương trình SQA
Nói chung, SQA như một phần của cam kết quản lý toàn bộ để cải thiện chất lượng - thường được gọi là quản lý chất lượng toàn bộ. [4]
CHƢƠNG 4. PHÁT TRIỂN CHƢƠNG TRÌNH ỨNG DỤNG
4.1 Mục tiêu
Ước lượng chi phí nguồn lực cho việc phần mềm bằng cách xác định số lượng chức năng được yêu cầu và cung cấp bởi người dùng dựa chủ yếu trên thiết kế logic.
Ước lượng ngày công cho việc phát triển phần mềm, quá trình bảo dưỡng bảo trì độc lập về công nghệ được sử dụng
4.2 Tóm lược cơ sở khoa học
Phần mềm được xây dựng dựa trên hai phương pháp đã được nghiên cứu ở trên là Function Points và Use Case Points [5, 2]
4.2.1 Các bƣớc tính Function Points trong chƣơng trình
Bƣớc 1. Tính tổng số điểm chức năng (điểm chức năng thô - UFP)
Bƣớc 2. Xác định các tác tố ảnh hưởng đến độ phức tạp của phần mềm (14 tác tố);
các tác tố này được xác định trên 1 thang điểm 0..5, dựa trên việc đáp ứng các câu hỏi căn cứ trong bảng sau:
Tỉ lệ mỗi tác tố theo thang điểm từ 0 đến 5
0 1 2 3 4 5
Không ảnh hưởng
Ngẫu nhiên Đơn giản Trung bình Có ý nghĩa Bản chất
Tổng số điểm các tác tố gọi là độ ảnh hưởng (Fi với i=1..14) Fi:
1- Hệ thống có yêu cầu sao lưu và khôi phục không? 2- Có yêu cầu trao đổi dữ liệu không?
3- Có chức năng xử lí phân tán không?
4- Có đòi hỏi cao về vấn đề có làm việc tốt không?
5- Hệ thống có chạy trong môi trường có nặng về vấn đề tiện ích không 6- Hệ thống có đòi hỏi việc vào dữ liệu trực tuyến không
7- Việc vào dữ liệu trực tuyến có đòi hỏi phải xây dựng thao tác đưa vào thông qua nhiều màn hình hay thao tác không?
8- Tệp chính có phải cập nhật trực tuyến không? 9- Cái vào, cái ra, tệp, truy vấn có phức tạp không? 10- Xử lí bên trong có phức tạp không?
12- Việc chuyển đổi và cài đặt có được đưa vào trong thiết kế không?
13- Hệ thống có được thiết kế cho nhiều cài đặt trong các tổ chức khác nhau không?
14- Liệu ứng dụng có được thiết kế để làm thuận tiện cho việc thay đổi và dễ dàng cho người dùng không?
Bƣớc 3. Tính điểm chức năng:
FP = UFP * (0,65 + 0,01*SUM(Fi)). (adsbygoogle = window.adsbygoogle || []).push({});
Sau khi tìm được điẻm chức năng ta có thể tính toán ước lượng theo các công thức sau:
Hiệu năng = FP/ngƣời-tháng Phẩm chất = Khiếm khuyết /FP Chi phí = $/FP
Tƣ liệu = Số trang tƣ liệu /FP Các loại Funtion Points
1. Data storage
External Input (EI) (ví dụ, dữ liệu điền lên form) External Output (EO) (ví dụ, báo cáo)
2. Transactions
External Query (EQ) (ví dụ, hộp thoại tìm kiếm)
Internal Logical File (ILF) (ví dụ, quan hệ giữa các bảng được lưu giữ)
External Logical File (ELF) (ví dụ, các bảng khác ứng dụng liên hệ tới nhưng không lưu giữ)
Độ phức tạp của các FP là khác nhau:
EI, EO, EQ dựa trên số lượng các kiểu thành phần dữ liệu (ký hiệu DET: Data Element Types) được truy cập và số lượng kiểu file tham chiếu.
ILF và EIF có độ phức tạp dựa trên số lựợng của DET và số lượng các kiểu thành phần bản ghi.
Dưới đây là bảng các trọng số dành cho mỗi loại FP và mứ độ phức tạp tương ứng
*Các đặc trƣng chung của hệ thống (GSC: General Systems Characteristics),
có 14 loại nhƣ sau:
1. Data Communications
Dữ liệu và thông tin điều khiển được sử dụng trong ứng dụng được gửi hoặc nhận qua các điều kiện giao tiếp
2. Distributed Data Processing
Xử lý dữ liệu phân tán
3. Performance
Tốc độ đáp ứng của ứng dụng về thời gian
4. Heavily Used Configuration
Nặng về các thao tác cấu hình đặc biệt là cân nhắc thiết kế. Vấn đề này nảy sinh do nhu cầu sử dụng của mỗi người là khác nhau, do vậy mà việc cấu hình riêng cho mỗi người dùng sao cho chương trình chạy tốt nhất vấn cần thiết.
5. Transaction Rate. Tỷ lệ giao dịch 6. On-line Data Entry
Dầu vào dữ liệu trực tuyến.
7. End -User Efficiency: Hiệu quả sử dụng cuối
Mức độ thiết kế hiệu quả cho người sử dụng cuối cùng. Mức độ chi tiết các yêu cầu của người dùng, yêu cầu của người dùng về các chức năng càng đặc thù cho ứng dụng của họ thì yếu tố này càng lớn
8. On-line Update
Phần mềm hỗ trợ việc update online cho file hệ thống (ILF: internal logical files).
9. Complex Processing: xửlý phứct tạp (adsbygoogle = window.adsbygoogle || []).push({});
Độ phức tạp xử lý bên trong phần mềm, các phép tính toán, các thuật toán là phức tạp…
10. Reusability: khả năng sử dụng lại
Ứng dụng và mã nguồn trong ứng dụng được thiết kế, phát triển và hỗ trợ để có thể sử dụng lại trong ứng dụng khác. ứng dụng có tính mở rộng và phát triển cao.
11. Installation Ease: dẽ dàng cài đặt
Dễ dàng cài đặt và đưa vào sử dụng
12. Operational Ease: thao tác dễ dàng
Thao tác dễ dàng là một đặc điểm của ứng. Các thủ tục khởi động, sao lưu, khôi phục là hiệu quả và được cung cấp, kiểm tra trong khâu kiểm thử. Các chức năng bên trong ứng dụng đơn giản, dễ hiểu, dễ xử lý, không cần nhiều thời gian để làm quen sử dụng
13. Multiple Sites: nhiều nơi
Ứng dụng được thiết kế đặc trưng, được phát triển, hỗ trợ để cài đặt tại nhiều nơi cho nhiều tổ chức
14. Facilitate Change: thay đổi dễ dàng
Ứng dụng được thiết kế đặc trưng, được phát triển, hỗ trợ để dễ dàng thay đổi
Mỗi GSC được đặt giá trị giữa 0 và 5 phù hợp với sự ảnh hưởng của nó tới ứng ụng.Tổng các giá trị của 14 GSC này được gọi là TDI (Toptal Degree of Influence)
VAF (Value Adjustment Factor) = (TDI*0.01) + 0.65
Adjusted Function Points Count được tính như sau:
AFPC = VAF * UFPC
Sau khi tính toán được AFPC chúng ta có thể ước lượng giá phần mềm thông qua công sức(efford) trung bình bỏ ra để xây dựng một Function Points, tiếp sau đó nhân với ngày công thì ra giá của phần mềm.
4.2.2 Các bước tính Use Case Points trong chương trình
Phương pháp Use case points sẽ đếm các Actor và Use case trong mô hình UML
Để tính UUCP (Unjust Use case Points) ta nhân thêm trọng số tương ứng trong bảng trên với mỗi loại Actor và Use case.
ni: số lượng use case hoặc Actor wi: trọng số tương ứng
Để ước lượng phần mềm tốt hơn nữa thêm hai nhân tố là:
Technical Complexity Factor(TCF) và Environmental Factor (EF)
Technical Complexity Factor đã được nói tới ở trên (Phần Function Points)
Công thức tính : với C1 = 1.4, C2 = -0.3
Các hằng số C1, C2 là dựa trên những ước lượng sớm
F1: Mức độ quen thuộc: Mô hình của hệ thống là quen thuộc với các nhân viên phát triển phần mềm
F2: phụ thuộc vào số lượng và mức độ đóng góp của các nhân viên làm việc Part Time.
F3: Năng lực phân tích, người phân tích tốt sẽ cho hệ thống phát triển tốt, dễ cài đặt, phát triển và mở rộng
F4: kinh nghiệm đối với ứng dụng: hầu hết các công nhân đã làm việc quen thuộc trên ứng dụng này
F5: Kinh nghiệm lập trình hướng đối tượng: kinh nghiệm này ảnh hưởng rất lớn đến mô hình đối tượng của ứng dụng (adsbygoogle = window.adsbygoogle || []).push({});
F6: Động cơ thúc đẩy: nếu ứng dụng đang phát triển đang có nhu cầu lớn, hoặc có tương lai, thì động cơ thúc đẩy là tốt, việc tập trung phát triển cũng tốt hơn, và ứng dụng càng được hoàn thiện tốt.
F7: Mức độ khó khăn của ngôn ngữ lập trình: ngôn ngữ lập trình cấp thấp thường rất khó so với khi lập trình bằng các ngôn ngữ bậc cao.
F8: Mức độ ổn định của các yêu cầu: đây là nhân tố khá điển hình, như chúng ta đã biết người dùng đôi khi còn chưa phát hiện rõ và chính sác yêu cầu của mình, trong quá trình phát triển phần mềm sự thày đổi đôi khi là phải trả giá hết sức đắt.
Khi đó Use case points được tính:
4.3 Cài đặt
Công nghệ áp dụng:
Chương trình được xây dựng bằng ngôn ngữ C#, hoạt động trên OS MS Windows với môi trường Dot Net Framework 2.0
Yêu cầu hệ thống:
Windows 95, Windows 98, Windows NT 4, Windows 2000, or Windows XP.
4MB free trên ổ cứng.
RAM 128MB
Cài Dot Net Framework 2.0
Một số giao diện của chƣơng trình Software Estimation
Hình 7. Ước lượng phần mềm bằng phương pháp Use Case Points
KẾT LUẬN
Thị trường phần mềm luôn phát triển tương xứng (hoặc gần tương xứng) với nền kinh tế, đó là đặc điểm chung. Do đó đặc điểm của thị trường phần mềm luôn bị ảnh hưởng bởi đặc điểm của nền kinh tế, mà Việt Nam cũng không phải là một ngoại lệ. Chúng ta đều hiểu rằng tuy đã có nhiều phát triển trong những năm qua nhưng thị trường Việt Nam vẫn còn nhiều bất cập. Có thể tạm chia cách hoạt động làm việc của các loại hình kinh doanh Việt Nam thành hai loại:
Hoạt động khoa học, chuyên nghiệp.
Hoạt động còn mang nặng tính chất "tình cảm".
Cả hai loại đều có thể rơi vào các hình thức như công ty, xí nghiệp nhà nước hoặc tư nhân. Không thể nói hình thức thứ hai làm sai pháp luật, vì trên mặt giấy tờ khó có thể tìm ra một lỗi nào của họ về chế độ tài chính hay quản lý nhà nước, tuy