Alec Adams rất hào hứng khi quản lý dự án Hệ thống bán hàng qua Internet tại CD Selections nhưng ông nhận ra rằng nhóm dự án của ông sẽ có ít thời gian để phân phối ít nhất một số bộ phận của hệ thống bởi vì công ty muốn ứng dụng phát triển đúng thời điểm cho kỳ nghỉ lễ. Vì vậy, ông quyết định rằng dự án nên tuân theo phương pháp tiếp cận Unified Process (xem Hình 1-11). Bằng cách này, anh ta có thể chắc chắn rằng một số phiên bản của sản phẩm sẽ nằm trong tay của người dùng trong vòng vài tháng, ngay cả khi hệ thống đã hoàn thành sẽ được phân phối vào một ngày sau đó.
Là người quản lý dự án, Alec đã phải ước lượng quy mô, nỗ lực và thời gian của dự án - một số công việc ít được yêu thích nhất vì khó khăn của họ khi thực hiện dự án. Nhưng ông biết rằng người dùng sẽ mong đợi ít nhất là phạm vi chung cho một ngày giao hàng sản phẩm. Ông bắt đầu bằng cách cố gắng để ước lượng kích thước của dự án bằng cách sử dụng các điểm chức năng và bảng tính điểm chức năng trong Hình 3-3. Đối với phần Web của khách hàng, khách hàng có thể nghĩ đến bốn yêu cầu chính (tìm kiếm theo nghệ sỹ, theo tiêu đề CD, theo tiêu đề bài hát, và theo tiêu chí đặc biệt), ba màn hình đầu vào (chọn CD, nhập thông tin đặt đĩa CD và màn hình đặt hàng đặc biệt), bốn màn hình đầu ra (trang chủ với thông tin tổng quát, thông tin về đĩa CD, thông tin về lệnh đặc biệt của khách hàng, trạng thái tạm dừng), ba tệp (thông tin đĩa CD, hàng tồn kho thông tin và đơn đặt hàng của khách hàng), và hai giao diện chương trình (một hệ thống đặt hàng đặc biệt của công ty và một hệ thống truyền thông giữ thông tin đến các hệ thống cửa hàng bán lẻ). Đối với một phần của hệ thống sẽ được các nhân viên của CD Selections sử dụng (để duy trì các tài liệu tiếp thị), ông đã xác định ba đầu vào bổ sung, ba đầu ra, bốn truy vấn, một tệp, và một giao diện chương trình. Dựa trên sự phức tạp của mỗi người, ông đã nhập những con số vào phần trên của bảng tính (xem Hình 3-21). Dựa vào tính toán, có 158 điểm chức năng không được điều chỉnh (TUFP).
Độ phức tạp Sự mô tả Tổng số Thấp Trung bình Cao Tổng Đầu vào 6 0 * 3 4 * 4 2 * 6 28 Đầu ra 7 2 * 4 4 * 5 1 * 7 35 Truy vấn 8 3 * 3 4 * 4 1 * 6 31 Các tập tin 4 0 * 7 4 * 10 0 * 15 40 Giao diện CT 3 0 * 5 2 * 7 1 * 10 24
33
Hình 3-21 Kích thước và động lực ước tính cho Hệ thống Bán hàng Internet
Dự án đƣợc giả định phức tạp xử lý phức tạp (APC) = 1.2 Tổng số điểm chức năng điều chỉnh: 1.2 * 158 = 189.6
Các dòng mã dự kiến: (.75 * 190 * 60) + (.25 * 190 * 43) =10,600 dòng mã Động lực ƣớc tính COCOMO: (1.4 * 10.6) = 15 person-months
Lịch trình dự kiến: 3.0 * 15^(1/3) = 7.5 months Ƣớc tính nỗ lực cuối cùng: 1.34 * 7.5 = 10 months Ƣớc tính nhân sự cuối cùng: 15/10 = 1.5
Thay vì cố gắng đánh giá mức độ phức tạp của hệ thống, Alec chọn sử dụng giá trị 1.20 cho sự phức tạp xử lý được điều chỉnh (APC). Ông lý luận rằng hệ thống này có độ phức tạp trung bình và đội dự án có ít kinh nghiệm về các hệ thống dựa trên Internet. Điều này tạo ra một điểm chức năng điều chỉnh tổng cộng (TAFP) khoảng 190.
Việc chuyển đổi các điểm chức năng thành các dòng mã là một thách thức. Dự án sẽ sử dụng một sự kết hợp của Java (cho hầu hết các chương trình) và HTML cho các màn hình Web. Alec đã quyết định cho rằng khoảng 75% các điểm chức năng là Java và 25% sẽ là HTML. Sử dụng bảng trong hình 3-4, Alec ước tính sẽ có khoảng 10.600 dòng mã. Sử dụng công thức COCOMO, ông thấy rằng điều này đã được dịch sang khoảng 15 tháng. Điều này đến lượt đề xuất một lịch trình thời gian khoảng 7,5 tháng. Bởi vì nhóm phát triển có rất ít kinh nghiệm trong việc phát triển loại hệ thống này, Alec đã không chắc chắn về ước tính. Sau nhiều lần thảo luận, Alec quyết định đưa ra ước tính này lên 33%. Như vậy, Alec ước tính rằng dự án sẽ mất khoảng 10 tháng.
Một khi ước tính đã được tiến hành, Alec bắt đầu tạo ra một cấu trúc phân tích công việc tiến hóa và kế hoạch làm việc lặp đi lặp lại để xác định các nhiệm vụ mà sẽ là cần thiết để hoàn thành hệ thống. Ông bắt đầu bằng cách xem xét các quy trình và tiến trình công việc được tăng cường của Unified (xem Hình 1-11) và cấu trúc cơ cấu phân tích tiến hóa (xem Hình 3-14). Vào thời điểm đó, Alec không biết đủ để tạo ra một kế hoạch làm việc hoàn chỉnh. Như vậy, ông đã bao gồm càng nhiều chi tiết như ông biết là chính xác (xem hình 3-22).
Ví dụ, Alec cảm thấy tự tin về ước tính thời gian cần thiết để tạo ra các yêu cầu định nghĩa và gợi ra các yêu cầu. Tuy nhiên, anh ta sẽ không biết phải mất bao lâu để phát triển mô hình phân tích chức năng, cấu trúc hoặc hành vi cho đến khi anh ta có một ý tưởng tốt hơn về các yêu cầu thực tế. Cho đến khi quyết định này có thể được thực hiện, bất kỳ ước tính nào về thời gian yêu cầu sẽ chỉ đơn giản là đoán. Theo thời gian, Alec mong muốn biết nhiều hơn về quá trình phát
34
triển và sẽ thêm nhiều chi tiết hơn vào kế hoạch làm việc. (Hãy nhớ rằng quá trình phát triển và quy trình quản lý dự án lặp đi lặp lại và gia tăng trong tự nhiên.)