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 chokhá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ểmcủa kháchhàngđánhgiá. U={1,2,…..,50,….80, ….100}
Tv={„Khônghàilòng‟,„Hàilòng‟,„Rấthàilò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‟Rấthàilòng‟=
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à:
• Khốilượngyêucầukhôngrõràng
• Độkhócủakhối lượng yêu cầu không rõràng
• Thờigianphântích,Q&A khách hàng
• Mức độ xảy rarisk củadựá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à đủ…