TÍCH DỰ ÁN PHẦN MỀM
Khi nhận đƣợc request công việc của khách hàng về công việc. Khách hàng sẽ thăm dò về estimate chi phí của chúng ta. Nếu chi phí phù hợp với quỹ ngân sách của họ thì họ sẽ đồng ý. Nhƣng estimate lại là một việc không hề đơn giản. Nó đƣợc coi là việc đau đầu khó khăn nhất của những ai làm dự án nói chung và dự án phần mềm nói riêng. Đặc điểm công việc, phạm vi công việc, công nghệ sử dụng của nó là gì, ngôn ngữ, framework là gì, mức độ khó dễ, yếu tố con ngƣời hiện có, từ những yếu tố chúng ta cân nhắc đắn đo để đƣa ra con số estimate effort sau cho khách hàng đồng ý mà chúng ta vẫn có lợi nhuận.
Khi khách hàng đồng ý và ký hợp đồng với chúng ta. Những ngƣời quản lý phần mềm sẽ quyết định mở dự án. Ngƣời PM sẽ làm Project Planning. Để làm Project Planning thì PM cần có kinh nghiệm làm dự án. Nếu dự án quen thuộc thì sẽ dựa trên những con số thống kê của dòng dự án đó. Nhƣng nếu dự án là một lĩnh vực hoàn toàn mới lạ thì cần phải tham khảo nhiều nguồn khác nhau, nhiều dòng dự án khác nhau. Project Planning gồm các chỉ số của dự án, số lƣợng effort, số lƣợng ngƣời làm, thời gian làm bao lâu, các con số đảm bảo chất lƣợng nhƣ Bug Code/KLOC, Bug Test/KLOC, con số cam kết về Productivity, size của dự án(tính bằng KLOC), dự đoán những risk có thể xảy ra, đề ra các chiến lƣợc đảm bảo chất lƣợng dự án, CSS, Timeliness.
Sau đây là một số ví dụ liên quan đến việc phân tích, dự đoán các chỉ số liên quan trong quá trình làm dự án phần mềm:
Ví dụ về khảo sát độ hài lòng của khách hang (CSS), chúng ta có thể xây dựng đƣợc biến ngôn ngữ V với bộ ba <V, U, Tv> nhƣ sau:
V=”CSS” là tên biến
U là tập các số nguyên chỉ ra điểm của khách hàng đánh giá. U= {1,2,…..,50,….80,….100}
Áp Dụng Logic Mờ Trong Phân Tích Dự Án Phần Mềm Trang 35 Tv ={„Không hài lòng‟, „Hài lòng‟, „Rất hài lòng‟}
Các tập con mờ „Không hài lòng‟, „Hài lòng‟, „Rất hài lòng‟ đƣợc định nghĩa bởi các hàm thuộc f‟Không hài lòng‟ , f‟Hài lòng‟ , f‟Rất hài lòng‟ nhƣ sau:
f‟Không hài lòng‟ = 1 if u<=80 1 1+ (u 80) /5 if 80<u<=90 0 if u>90 f‟Rất hài lòng‟ = 0 if u<=90 1 if 90<u<=95 1 + (u 90)/5 1 if u>=95
Trong một trƣờng hợp khác về phân tích và dự đoán risk của dự án liên quan yêu cầu của khách hàng:
Yêu cầu của khách hàng không rõ ràng càng nhiều thì càng cần nhiều thời gian phân tích, Q&A với khách hàng và risk của dự án xảy ra càng cao.
Yêu cầu không rõ ràng càng khó thì càng cần nhiều thời gian phân tích, Q&A với khách hàng và risk của dự án xảy ra càng cao.
Các biến ngôn ngữ trong trƣờng hợp trên là: 1/ Khối lƣợng yêu cầu không rõ ràng
Áp Dụng Logic Mờ Trong Phân Tích Dự Án Phần Mềm Trang 36 2/ Độ khó của khối lƣợng yêu cầu không rõ ràng
3/ Thời gian phân tích, Q&A khách hàng 4/ Mức độ xảy ra risk của dự án.
Sau đó chúng ta xác định giá trị của các ngôn ngữ trên tùy thuộc vào việc đƣa ra các giá trị của dự án. Ví dụ: Khối lƣợng yêu cầu không rõ ràng (10%, 20%, 30% của toàn bộ các yêu cầu khách hàng trong dự án). Độ khó của khối lƣợng yêu cầu không rõ ràng(1,3,5, 7 là trọng số của các mức độ khó)…
Chúng ta cũng có thể xây dựng các luật mờ liên quan quản lý dự án phần mềm. Ví dụ nhƣ: Nếu risk xảy ra thì thời gian can thiệp thế nào là tốt nhất, với risk có trọng số cao thì cần thời gian là bao nhiêu, biện pháp tránh và xử lý nhƣ thế nào.
Nếu yêu cầu của khách hàng có phạm vi ảnh hƣởng rất rộng thì thực hiện test thế nào là đủ…
Áp Dụng Logic Mờ Trong Phân Tích Dự Án Phần Mềm Trang 37