chương 1) đưa ra tổng quan về ước lượng dự án phần mềm và đánh giá chất lượng phần mềm trong quản lý dự án phần mềm, trên cơ sở đó, phần hai (chương 2 và 3) đi sâu vào các kỹ thuật ước lượng và kỹ thuật đánh giá cụ thể, phần cuối cùng (chương 4) dựa trên những nghiên cứu thu được, phát triển một công cụ ước lượng tự động dùng để ước lượng công sức và ngày công cho dự án phần mềm. LUAN VAN CHAT LUONG download : add luanvanchat@agmail.com 7 CHƢƠNG 1. TỔNG QUAN VỀ ƢỚC LƢỢNG DỰ ÁN PHẦN MỀM VÀ ĐÁNH GIÁ CHẤT LƢỢNG PHẦN MỀM 1.1 Ước lượng dự án phần mềm [4] Trong những ngày đầu của tin học, chi phí phần mềm bao gồm một phần trăm nhỏ của toàn bộ chi phí cho hệ thống dựa trên máy tính. Một lỗi lầm lớn trong ước lượng chi phí phần mềm có thể tương đối ít ảnh hưởng.
Ngày nay, phần mềm là yếu tố tốn kém nhất trong nhiều hệ thống dựa trên máy tính. Lỗi lầm ước lượng chi phí lớn có thể tạo ra sự chênh lệch giữa lợi nhuận và thất thoát. Việc bội chi phí có thể là thảm hoạ cho người phát triển. Ước lượng chi phí và công sức phần mềm chắc chắn không là một khoa học chính xác.
Có quá nhiều tham biến (con người, kỹ thuật, môi trường, chính trị.) có thể ảnh hưởng tới chi phí chung cuộc của phần mềm và công sức cần để phát triển nó. Để đạt được các ước lượng chi phí và công sức tin cậy, một số tuỳ chọn nảy sinh: Trì hoãn việc ước lượng tới giai đoạn sau của dự án (hiển nhiên chúng ta có thể đạt được ước lượng chính xác 100% khi dự án đã hoàn tât); Dùng các kỹ thuật phân rã để sinh ra ước lượng về chi phí và công sức dự án; Phát triển mô hình kinh nghiệm cho chi phí và công sức làm phần mềm; Thu được từ một hay nhiều công cụ ƣớc lƣợng tự động. Tuỳ chọn đầu tiên mặc dầu rất „hấp dẫn‟ nhưng lại không thực tế. Các ước lượng chi phí phải đưa ra ngay từ đầu.
Tuy vậy đợi càng lâu thì chúng ta biết càng nhiều, và biết càng nhiều thì càng ít có khả năng phạm lỗi lầm trong ước lượng. Ba tuỳ chọn còn lại là những cách tiếp cận có thể đứng được tương đối đối với ước lượng dự án phần mềm. Một cách lý tưởng, các kỹ thuật được lưu ý cho từng tuỳ chọn nên được áp dụng nối tiếp nhau, mỗi tuỳ chọn được dùng như một phép kiểm tra chéo cho tuỳ chọn khác. Các kỹ thuật phân rã lấy quan điểm „chia để trị‟ cho việc ước lượng dự án phần mềm.
Bằng cách phân rã một dự án thành các chức năng chính và các nhiệm vụ kỹ nghệ phần mềm có liên quan, việc ước lượng chi phí và nỗ lực có thể được thực hiện theo kiểu từng bước. Các mô hình ước lượng theo kinh nghiệm có thể được dùng để bổ sung cho các kỹ thuật phân rã và đưa ra một cách tiếp cận ước lượng tiềm năng có giá trị theo đúng nghĩa của nó. Một mô hình dựa trên kinh nghiệm (dữ liệu lịch sử) có dạng: LUAN VAN CHAT LUONG download : add luanvanchat@agmail.com 8 d = f(vi) d: là một trong một số các giá trị ước lượng (như công sức, chi phí, thời hạn dự án.) vi: các tham biến độc lập được chọn lựa (LOC hoặc FP được ước lượng) Có các công cụ ước lượng tự động cài đặt cho một hay nhiều kỹ thuật phân rã (hay mô hình kinh nghiệm). Khi được tổ hợp với một giao diện người-máy tương tác, các công cụ tự động hoá đưa ra một tuỳ chọn cho việc ước lượng.
Trong một hệ thống như vậy, các đặc trưng của tổ chức phát triển (như kinh nghiệm, môi trường…) và phần mềm cần phát triển sẽ được mô tả. Các ước lượng chi phí và nỗ lực được suy ra từ dữ liệu này. [4] Một dự án khi được thực hiện hoặc lập kế hoạch sẽ cần phải đánh giá được độ lớn của nó, các tài nguyên cần thiết, lịch thực hiện và các cột mốc quan trọng như: gửi tài liệu, bắt đầu kiểm thử, bàn giao.Thông thường thì giá thành và lịch trình thực hiện của một dự án thường mang tính rủi ro nhất do không được đánh giá đúng mức. Một số trong các những lý do đó là: Giá thành và lịch trình thường được quyết định trước bởi các đối tượng ngoài dự án như: khách hàng, chủ đầu tư…; Công việc phân tích thiết kế không phải bao giờ cũng bao quát hết các trường hợp, tình huống, các yêu cầu chưa được hiểu hết, hiểu đúng; Thường thì khách hàng không hiểu được việc phát triển phần mềm là một công việc có tính công nghệ cao với giá thành cao.
Quy trình ước lượng chi phí phần mềm dưới đây mô tả các bước cần thiết cho việc bắt đầu đánh giá một vòng đời phần mềm và sau đó là theo dõi, tinh chỉnh những đánh giá xuyên suốt thời gian thực hiện dự án. Thiết lập quy trình này càng sớm sẽ giúp cho việc đánh giá được chính xác hơn, tin cậy hơn, từ đó có thể xác định rõ ràng các nhân tố liên quan tới giá thành của dự án. Quy trình này cũng đồng thời cung cấp các phương pháp cho dự án cách thức quản lý các rủi ro liên quan tới chi phí và lịch trình dự án. Quy trình ước lượng là một quá trình liên tục, được thực hiện không ngừng trong thời gian thực hiện dự án.
Các hoạt động của nó bao gồm: 1. Ước lượng kích cỡ; 2. Ước lượng chi phí và các nỗ lực; 3. Ước lượng lịch trình; 4.
Ước lượng các tài nguyên máy tính; LUAN VAN CHAT LUONG download : add luanvanchat@agmail. Đánh giá rủi ro; 6. Kiểm tra / xác nhận; 7. Theo dõi và báo cáo về tiến độ; 8.
Đánh giá và cải tiến quy trình. Các hoạt động ước lượng kích cỡ, nỗ lực và chi phí cần được thực hiện trước khi xây dựng vì thứ tự trên là bắt buộc trong tất cả các mô hình tính toán giá thành. Tuy nhiên việc xây dựng lịch trình thường được bắt đầu thực hiện trước khi hoàn thành tất cả công việc xác định các nỗ lực. Ngoài ra, việc sớm thiết lập bảng cấu trúc phân việc (Work Breakdown Structure - WBS) giúp việc phân chia các nỗ lực ra các phần việc độc lập mà có thể lập lịch hoặc xét mức độ ưu tiên xem thực hiện phần việc nào trước.
(ít nhất 2 người cùng tham gia xây dựng ) Yêu cầu Ước lượng kích cỡ (dùng ít nhất là 2 kỹ thuật ) Ước lượng nỗ lực/chi phí (dùng ít nhất là 2 kỹ thuật ) Ước lượng lịch trình (dùng ít nhất là 2 Cơ sở dữ liệu các dự kỹ thuật ) án đã ước lượng Ước lượng hệ thống máy tính Quản lý rủi ro (lặp lại định kỳ) Kiểm tra/xác thực Theo dõi, báo cáo về dự án Đánh giá và cải tiến quy trình Hình 1. Quy trình ước lượng dự án phần mềm 1.1 Ƣớc lƣợng kích cỡ (LOC & FP) Kích cỡ của phần mềm thường được đánh giá bằng đại lượng số lượng dòng mã (Source Lines of Code - SLOC) hoặc số nghìn dòng mã (Thousands of Source LUAN VAN CHAT LUONG download : add luanvanchat@agmail.com 10 Lines of Code - KSLOC). Phần mềm thường được phát triển theo cách viết mới hoàn toàn hoặc dùng một hay nhiều module có sẵn, do vậy việc ước lượng các đoạn mã đã có cũng cần được quan tâm như việc ước lượng các đoạn mã mới cần viết thêm. Việc tích hợp các module sẵn có và có vẻ đơn giản nhưng thực sự thì các nỗ lực dành cho nó cũng không kém so với việc phát triển mới từ đầu.
Kích cỡ cũng có thể được đánh giá qua đơn vị điểm chức năng (Function Points). Các điểm chức năng được đánh giá dựa trên chức năng của phần mềm và thường được áp dụng trong pha tìm hiểu yêu cầu. Dòng mã (LOC – Line Of Code) và điểm chức năng (FP – Function Point) là những dữ liệu cơ sở để từ đó tính ra độ đo hiệu năng. Dữ liệu LOC và FP được dùng theo hai cách trong việc ước lượng dự án phần mềm như: (1) Các biến ước lượng được dùng để lấy “kích cỡ” cho từng phần tử phần mềm.
(2) Độ đo vạch ranh giới được thu thập từ những dự án quá khứ và được dùng chung với các biến ước lượng để xây dựng các dự tính chi phí và công sức. Ước lượng LOC và FP là các kỹ thuật ước lượng phân biệt, nhưng cả hai đều có một số đặc trưng chung. Người lập dự án bắt đầu với một tuyên bố về phạm vi phần mềm, từ đó, dự định phân rã phần mềm thành các chức năng nhỏ hơn có thể được áp dụng riêng biệt. LOC và FP sẽ được ước lượng cho từng chức năng con đó.
Độ đo tính hiệu năng vạch ranh giới (như LOC/người-tháng hay FP/người-tháng) sau đó được áp dụng cho biến ước lượng thích hợp và ước lượng về chi phí và công sức từ đó được suy dẫn ra. Các ước lượng chức năng con được tổ hợp lại để tạo ra một thiết kế ước lượng tổng thể cho toàn bộ dự án. Các ước lượng kỹ thuật LOC và FP khác nhau ở mức độ chi tiết cần cho việc phân rã. Khi LOC được dùng như biến ước lượng thì việc phân rã chức năng thường được thực hiện cho các mức chi tiết đáng kể.
Vì dữ liệu cần cho việc ước lượng điểm chức năng ở mức vĩ mô hơn, nên mức độ phân rã được dùng khi FP là biến ước lượng sẽ ít chi tiết hơn. Cũng cần lưu ý rằng LOC được ước lượng trực tiếp trong khi FP được xác định gián tiếp bằng cách ước lượng số cái vào, cái ra, tệp dữ liệu, câu hỏi, và giao diện ngoài kèm theo 14 giá trị điều chỉnh độ phức tạp sau: Fi: 1. Hệ thống có đòi hỏi sao lưu và phục hồi không? 2. Có đòi hỏi trao đổi dữ liệu không? 3.
Có chức năng xử lý phân tán không? LUAN VAN CHAT LUONG download : add luanvanchat@agmail. Có đòi hỏi cao về làm việc tốt không? 5. Hệ thống có chạy trong môi trường hiện có mà nặng về vận hành 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 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? 11.
Mã chương trình có được thiết kế để dùng lại không? 12.