Quản lí dự án phần mềm

•ợc làm để bù trừ cho thừa số độ tin cậy đã đ•ợc đ•a vào ở mức thấp hơn. Tính phức tạp của hệ thống phụ có thể đ•ợc đ•a thành thừa số vào chi phí phát triển theo cách t•ơng tự. Những nhân tử phức tạp có thể đ•ợc bố trí cho mỗi hệ thống phụ. Điều này đơn giản hơn ph•ơng pháp mô tả tr•ớc đây cho các hợp phần phần mềm mức thấp hơn vì qui mô ch•ơng trình không đ•ợc tính đến ở mức hệ thống phụ. Các thuốc tính không tuỳ thuộc ở hệ thống phụ phải không đ•ợc áp dụng ở mức hệ thống phụ. Trong phần lớn tr•ờng hợp, trình độ nhân lực phải không đ•ợc đ•a thành thừa số vào dự toán chi phí phát triển vì thừa số nào bình th•ờng phải không biến biên trên mức hệ thống phụ. Khi nhân lực hoàn toàn khác đ•ợc bố trí cho mỗi hệ thống phụ, thông th•ờng chúng ta coi mỗi hệ thống phụ là hệ thống riêng rẽ vì mục đích chi phí phát triển dự toán. 10.4.6 Thuật toán dự toán chi phí Thuật toán sau suy từ mô thức gốc COCOMO của Boehm (Boehm 1981) và gồm 10 b•ớc cơ bản cho việc hình thành dự toán chi phí phát triển dự án. Các b•ớc này bao gồm việc phân giải dự án ra hợp phần, vận dụng công thức công sức cho mỗi hợp phần và phối hợp mọi dữ liệu tạo thành vào dự toán chi phí duy nhất của dự án. Thuật toán cơ bản bao gồm các b•ớc sau: 1. Phân giải hệ thống phần mềm sử dụng tinh lọc từng b•ớc, thành các hệ thống phụ và rồi phân giải mỗi hệ thống phụ thành các mô đun phần mềm mức thấp. 2. Sử dụng ph•ơng pháp dự toán qui mô (nh• mô tả trong phần 10.2) để dự toán qui mô của mỗi mô đun. Sau đó phối hợp các dự toán cho mỗi mô đun theo thế tạo lập dự toán cho qui mô của mỗi hệ thống phụ và cho toàn bộ hệ thống. 3. Xác định các nhân tử công sức cho mỗi mô đun, sử dụng các ph•ơng pháp t•ơng tự nh• mô tả ở đầu phần này. Các nhân tử công sức sử dụng ít ra phải bao gồm công thức về:  Trình độ nhân lực.  Qui mô dự án.  Độ tin.  Môi tr•ờng phát triển.  Tính phức tạp của mô đun. Quản lý dự án phần mềm 221 4. Vận dụng các nhân tử công sức vào mỗi mô đun sử dụng ph•ơng pháp nh• mô tả ở đầu phần này theo thế tạo lập dự toán cho mỗi mô đun 5. Xác định các nhân tử công sức của hệ thống phụ cho mỗi hệ thống phụ 6. Phối hợp các dự toán cho mô đun trong mỗi hệ thống phụ với nhân tử công sức hệ thống phụ theo thế tạo lập dự toán cho mỗi hệ thống phụ. 7. Phối hợp dự toán cho mọi hệ thống phụ, theo thế tạo lập dự toán cho toàn bộ hệ thống. 8. Duyệt lại các yếu tố đã đ•ợc xem xét trên mô đun và mức hệ thống phụ. Tìm t•ơng tác giữa các yếu tố, các mô đun và gi•ã các hệ thống phụ và tạo lập t•ơng tác 9. Tìm chi phí phụ đã bỏ quên ở dự toán hệ thống nh• phân tích, thị tr•ờng, tổng phí v.v.. Và phối hợp với dự toán hệ thống tạo lập. 10. Chuẩn bị dự toán độc lập thứ hai (và nếu có thể thứ ba). So sánh các dự toán mà mỗi nhóm tạo lập và kiểm tra bất cứ khác biệt cơ bản nào. Giải quyết bất kỳ khác biệt nào và tạo lập dự toán chi phí dự án duy nhất đ•ợc chấp nhận Thuật toán này tạo lập dự toán chi phí phát triển dự án chú ý mọi yếu tố chủ yếu. B•ớc 10 cũng đề cập sai lầm cá nhân trong dự toán bằng cách yêu cầu giải thích và giải quyết những khác biệt chủ yếu. B•ớc 1 liên quan đến từ mô đun phần mềm đồng nghĩa với đơn vị phân giải phần mềm mức thấp nhất. B•ớc 8 nhằm xác định các yếu tố đã sao chụp phần nào hay trọn vẹn trong dự toán. Thí dụ về sao chụp trọn vẹn là bố trí yếu tố phức tạp cho hợp phần phần mềm do những yêu cầu về độ tin cậy cao vì việc tạo lập độ tin cậy th•ờng đòi hỏi logic phức tạp. Điều này có thể dẫn đến trong dự toán cho hợp phần đ•ợc gia tăng hai lần, mỗi lần vì cùng lý do. Những yếu tố phụ có thể gộp trong các b•ớc 3 và 5 căn cứ ở đặc điểm của dự án hiện nay đ•ợc dự toán. Điều này có thể bao gồm những yếu tố nh• tính phức tạp của ngôn ngữ lập trình (nếu, chẳng hạn Ada đã đ•ợc sử dụng lần đầu) hay tính quen thuộc với phần cứng chủ đích (nếu phần cứng đặc biệt đ•ợc phát triển và do đấy pha hợp nhất hẳn khó khăn hơn). Việc thực hiện đầy đủ thuật toán này phải bao gồm mọi công thức công sức trên. Điều quan trọng là phải nhớ rằng sự phân loại các hợp phần phần mềm là khác nhau cho mỗi yếu tố. Điều này có nghĩa là khi vận dụng những nhân tử độ tin cậy vào các lớp hợp phần, những hợp phần đó chắc hẳn phải khác nhất với hợp phần tạo lập khi các nhân tử phức tạp đ•ợc vận dụng. Do đấy mỗi bộ nhân tử đ•ợc vận dụng riêng cho mỗi hợp phần phân giải. Có điều này ở nơi nào mà máy tính có thể có ích nhất và nh• đã nói tr•ớc đây, một số các khối ch•ơng trình máy tính COCOMO phải có đ•ợc để hoàn thiện những nhiệm vụ nhàm chán này Thuật toán COCOMO tuỳ thuộc nặng ở các quyết định chủ quan của ng•ời dự toán. Điều này đã dẫn đến việc phát triển nhiều biến thức của Quản lý dự án phần mềm 222 COCOMO và công thức công sức (coi Jeffery và Low (1990), Anderson (1990) và Balda và Gustafson (1990)). Vấn đề sai lệch của các dự toán chủ quan của những ng•ời dự toán khác nhau đ•ợc nêu trong phần 10.6. 10.5 Phân tích l•ợng chức năng. Có mâu thuẫn lớn khi xem xét trị số “dòng mã nguồn” là độ đo qui mô dự án (coi Ratcliff và Rollo (1990) Jeffery và Low (1990)). Không có định nghĩa chung nào cho độ đo SLOC: có thể hay không thể bao gồm mã thử nghiệm hay mã dùng lại hay trong một số tr•ờng hợp cả mã th• viện. Cũng vậy liệu SLOC có thực sự có nghĩa nh• vậy cho mã ch•ơng trình hợp ngữ và mã Ada không ? hay mã Cobol và mã C ? liệu một yếu tố duy nhất có thể thực sự đ•ợc vận dụng (coi các yếu tố COCOMO) để làm cho mọi ngôn ngữ lập trình so sánh đ•ợc? Các câu hỏi này có thể tránh đ•ợc khi h•ớng quá trình dự toán vào qui mô vấn đề dự án chứ không phải qui mô mã dự án. Phân tích l•ợng chức năng (FPA) là ph•ơng pháp tạo lập dự toán dự án căn cứ ở qui mô vấn đề. Qui mô vấn đề là độ đo suy từ các pha dự án ban đầu đặc biệt pha yêu cầu. Số l•ợng các chức năng trong dự án xác định qui mô vấn đề, nó đ•ợc biểu thị bằng số (trị số FPA). Trị số FPA của một dự án có thể đ•ợc dùng để:  So sánh tính phức tạp của các dự án  So sánh công sức t•ơng đối có yêu cầu để hoàn thành dự án  Phát sinh các độ đo dự án khác (nh• Sloc52) Có nhiều biến thức của kỹthuật FPA. Nhiều những biến thức đó nhằm thích ứng kỹ thuật vào các loại dự án đặc tr•ng hay tăng đ•ợc chính xác bằng cách thêm thuộc tính dự án vào quá trình FPA. 10.5.1 Các b•ớc FPA cơ bản. Qúa trình FPA cơ bản bao gồm tám b•ớc. Hai trong những b•ớc đó có thể đ•ợc chuẩn bị độc lập với dự án đ•ợc dự toán vì chúng tham gia vào các danh sách định các loại hàm số và các thuộc tính phức tạp đ•ợc sử dụng để phân loại đặc tính của dự án. Tám b•ớc FPA có bản là: 1. Xác định danh sách các loại chức năng phụ thuộc vào và ra. Điều này có thể bao gồm53.  Chức năng yêu cầu/nhập vào từ ngoài  Đầu vào dữ liệu hay kiểm tra của ng•ời dùng. 52 Jeffery và Low (1990) mô tả ch•ơng trình gọi là Clair đ•ợc dùng để đổi l•ợng chức năng (FP) sang Sloc. 53 các phạm trù hàm số này t•ơng tự với những phạm trù mà Albrecht và Gaffney (1983) đã gợi ý. Quản lý dự án phần mềm 223  Câu hỏi của ng•ời dùng đòi trả lời.  Chức năng ra ngoại  Chức năng ra tín hiệu hay dữ liệu dễ thấy  Chức năng file trung gian lôgic  Thông tin điều khiển hay dữ liệu  Chức năng file giao diện ngoại  Thông tin kiểm tra và dữ liệu và các file dùng chung. 2. Số các chức năng phần mềm cơ bản của mỗi loại đ•ợc xác định. Một chức năng phải đ•ợc tính nếu có dự kiến yêu cầu xử lý đặc biệt. 3. Mỗi chức năng đ•ợc đếm trong b•ớc 2 đ•ợc xếp loại là:  Đơn giản: tiếp cận file tối thiểu, ít kiểu dữ liệu khác biệt và tham gia tối thiểu của ng•ời dùng.  Trung bình: Loại này đ•ợc dành cho những chức năng giữa đơn giản và phức tạp. ‘Trung bình’ có thể đ•ợc phân chia phụ thành nhiều hơn một phân loại trung gian.  Phức tạp: Nhiều tiếp cận file, nhiều kiểu dữ liệu khác nhau và tham gia rộng rãi của ng•ời dùng. 4. Trị số trọng số đ•ợc gán cho mỗi bộ phân loại trong b•ớc 3 (thí dụ đơn giản = 6, trung bình = 8, phức tạp = 10 hay trung bình có thể mở rộng thành 7, 8 và 9). Mỗi loại chức năng có thể có một bộ trọng số khác nhau. Các giá trị của mọi chức năng đã gán trọng số đều đ•ợc thêm vào, cung cấp trị số FPA ch•a đ•ợc phán xét (UFP). 5. Các thuộc tính của độ phức tạp xử lý đã đ•ợc xác định. Nó có thể bao gồm54.  Chức năng truyền thông dữ liệu  Dữ liệu và kiểm tra đ•ợc chuyển khu vực và xa xôi  Chức năng phân tán  Chức năng dữ liệu phân tán  Chức năng xử lý phân tán  Hoàn thành  Mục tiêu hoàn thiện nh• ảnh h•ởng của năng suất và độ nhạy tới các hoạt động phát triển  Sử dụng cấu hình  Mức độ sử dụng phần cứng: đ•ờng truyền thông.  Tỉ suất giao dịch  Mức độ tỉ suất giao dịch ảnh h•ởng tới phát triển  Nhập dữ liệu th•ờng trực  Mức độ các chức năng dữ liệu th•ờng trực đ•ợc hệ thống xử lí  Hiệu quả của ng•ời dùng cuối 54 Albrecht và Gaffney (1983) gợi ý 14 nhân tố phức tạp và Symons (1988) gợi ý phụ thêm 6. Quản lý dự án phần mềm 224  Hiệu quả yêu cầu của xử lý chức năng dữ liệu th•ờng trực đ•ợc ng•ời dụng cuối thực hiện  Cập nhật th•ờng trực  Mức độ cập nhật yêu cầu cho các file trung gian logic  Xử lý phức tạp  Mức độ ảnh h•ởng của xử lý phức tạp tới phát triển. Điều này bao gồm bộ xử lý ngắt, mã táI-nhập, thuật toán phức tạp, I/O v.v.  Tái sử dụng  Mức độ mã phải đ•ợc phát triển coi nh• tái sử dụng cho các hệ khác.  Dễ lắp đặt.  Mức độ việc dễ lắp đặt ảnh h•ởng đến phát triển  Dễ vận hành  Mức độ yêu cầu về việc dễ dàng trong những chức năng nh• sao l•u, phục hồi, giao diện của ng•ời v.v.  Các điểm đa bội  Mức độ mà hệ thống đ•ợc phát triển cho các điểm khác nhau và các loại ng•ời dùng khác nhau  Giúp thay đổi dễ dàng  Mức độ mà phần mềm phải đ•ợc phát triển để hỗ trợ thay đổi chức năng dễ dàng. 6. Mỗi mức độ xử lý ảnh h•ởng tới mỗi yếu tố phức tạp đ•ợc chỉ định căn cứ ở 1 trong những trị số sau: 0: Không tồn tại 1: Không đáng kể 2: Vừa phải 3: Trung bình 4: Đáng kể 5: Mạnh và tổng số các trị số yếu tố phức tạp đ•ợc tính cung cấp tổng mức ảnh h•ởng (TGI) 7. Tổng mức trị số ảnh h•ởng đ•ợc chuyển đổi sang nhân tố điều chỉnh phức tạp (CAP). Hàm chuyển đổi đơn giản có thể là: 8. Độ đo chức năng điều chỉnh (APF) cho dự án đ•ợc tính là: AFP = CAF x UFP DựCAF Dự 5 x (số các nhân tố phức tạp) TGI D Quản lý dự án phần mềm 225 Bảng 10.6 Các trị FPA cho các kiểu dự án khác nhau Dự án HFP C FP A FP Hệ thời gian và bảo d•ỡng 1200 0.42 504 Hệ kiểm tra trung nhập 680 0.87 592 Bảng 10.6 có thí dụ về các trị số có đ•ợc ở phân tích chức năng. Các trị số trong bảng chứng minh tầm quan trọng của việc điều chỉnh trị số chức năng. Hệ thống xử lý dữ liệu th•ơng mại lớn cung cấp UFP lớn hơn hệ thống thời gian thực nhiều, nh•ng sự điều chỉnh phức tạp này tạo nên trị số điều chỉnh cao hơn cho hệ thống thời gian thực. Kết luận là ngay dù hệ thời gian và bảo d•ỡng có số chức năng hầu nh• gấp đôi hệ thống kiểm tra truy nhập, tính phức tạp của hệ kiểm tra truy nhập cho thấy nó sẽ đòi hỏi nhiều công sức hơn để phát triển. 10.5.2 ứng dụng của FPA. Có nhiều t•ơng đồng giữa dự toán COCOMO và phân tích điểm hàm. Cả hai ph•ơng pháp sử dụng kỹ thuật chất tải t•ơng tự để điều chỉnh dự toán ban đầu. Dù sao, FPA chỉ phụ thuộc ở tính chức năng của hệ thống đ•ợc dự toán và không ở bất cứ dự toán nào đã tính tr•ớc đây (thí dụ dòng mã, qui mô mô đun). Nh• chúng ta đã thấy, độ đo FPA là có ích để so sánh công sức của các dự án. Nó không trực tiếp cung cấp ph•ơng pháp dự toán chi phí của một dự án. Căn cứ ở giả định là có t•ơng quan cao giữa chi phí và công sức, hàm có thể vận dụng cho trị số FPA để có đ•ợc dự toán chi phí. Hàm đơn giản có thể dựa trên kinh nghiệm đã qua chẳng hạn dự án tr•ớc đây với trị số AFP là 1.000 hết $1.500.000 để phát triển và dự án khác tr•ớc đây với trị số AFP 850 hết $900.000. Nếu ta giả định t•ơng quan tuyến tính, thì nếu dự án hiện hành đ•ợc dự toán có trị số AFP là 920 chúng ta sẽ dự toán chi phí của nó là $1.800.000. Những ph•ơng pháp tính vi hơn để tính công sức (giờ lao động) và qui mô mã (KS LOC) đ•ợc Albrecht và Gaffney tình bày (1983). Ph•ơng pháp COCOMO có thể đ•ợc vận dụng cùng với phân tích điểm hàm để thực hiện 2 mục đích quan trọng: 1. Đảm bảo là dự toán hợp lý (không chênh lệch kết quả đáng kể) 2. Tạo ra bộ dự toán dễ hiểu hơn(trị số so sánh và trị số chi phí). Việc sử dụng COCOMO kết hợp với phân tích điểm hàm đ•ợc Ratcliff và Rollo (1990) nghiên cứu đi đến kết luận là “mục tiêu dài hạn có hiệu quả hơn hẳn là sự phát triển mô hình dự toán chung mới cho hệ dọc vận hành” có thể cho rằng tạo nên một bộ dự toán dể hiểu hơn. Nh•ng Quản lý dự án phần mềm 226 COCOMO và FPA đã đ•ợc phối hợp thành công trong tiện ích dự toán máy tính hoá dễ hiểu55 sử dụng cả hai kỹ thuật về dự toán chi phí và qui mô của dự án phần mềm. Thuộc tính của hai kỹ thuật trong tiện ích này có thể đ•ợc điều chình dựa trên kinh nghiệm có đ•ợc trong khi sử dụng và những mô hình xen kẽ (thuộc tính của mỗi mô hình) có thể đ•ợc l•u giữ riêng rẽ và chất tải trong tiện ích khi cần. 10.6 Dự toán là một lĩnh vực. Nếu đ•ợc hỏi mất bao lâu để phát triển một mô đun phần mềm duy nhất, thì một nhà lập trình có kinh nghiệm hẳn chắc chắn trả lời “điều đó còn tuỳ”. Nh• chúng ta đã thấy, điều đó tuỳ thuộc vào ngôn ngữ lập trình, vào tính phức tạp logic, vào cá nhân ng•ời lập trình và có thể vào những yếu tố khác. Nếu bị ép trả lời rõ, thì cũng nhà lập trình đó hẳn sẽ trả lời là có thể mất đâu đó trong khoảng từ 2 ngày và đến 2 tuần. Đây là câu trả lờì có gía trị. Dự toán th•ờng đ•ợc trình bày là một phạm trù. Phạm trù là một dự toán có ích trong lập kế hoạch phát triển của một dự án. Quản lý th•ờng sẽ sẵn sàng chấp nhận một dự án ban đầu cho biết dự án sẽ không d•ới $400.000 và không trên $750.000. Những loại dự toán nh• thế th•ờng đ•ợc dùng trong các pha qui hoạch của một dự án. Càng trở nên có đ•ợc nhiều thông tin, phạm vi càng trở nên đ•ợc thu hẹp hơn, thậm chí có khi trở thành một con số duy nhất. Lý thuyết thống kê đằng sau tiếp cận đó đề cập đến quan niệm khoảng tin cậy. Nếu một biến x có xác suất p ở giữa hai trị số a và b thì chúng ta nói khoảng cách (a,b) là khoảng cách p-tin-cậy của x. Lấy thí dụ, nếu (2,14) là khoảng cách tin cậy 95% có số ngày cần để phát triển một mô đun thì chúng ta có 95% chắc chắn là phát triển mô đun sẽ mất hơn 2 và kém 14 ngày để phát triển56. Thêm một lời về sự chắc chắn 95%. Nếu chúng ta có 95% chắc chắn về cái gì, thì trong 100 tr•ờng hợp chúng ta trông đợi đúng 95% lần và 5 lần sai. Phạm trù xét đến ở đây sẽ là phạm trù dự tính cho một thuộc tính dự án đã cho, nh• SLOC, nh• chi phí phát triển, nh• qui mô đội phát triển, nh• thời gian phát triển v.v. Chúng ta hãy giả định một phân bổ chính tắc dự toán. Điều đó có nghĩa nếu 20 ng•ời chuyên môn phần mềm đ•ợc yêu cầu dự toán số ngày cần để phát triển một mô đun phần mềm đặc tr•ng, chúng ta trông đợi kết quả t•ơng tự trong phân bổ với nh• sau: 1 ng•ời sẽ dự toán 2 ngày 55 Tiện ích máy tính tham khảo, Before you leap (BYL) đ•ợc nhóm Gordon Group, California công bố 56 chặt chẽ mà nói định nghĩa toán học của xác suất liên quan đến hàm tạo ra trị số giữa 0 và 1. Dù sao trong thế giới thực đặc biệt trong thế giới kinh doanh xác suất th•ờng đ•ợc biểu thị theo phần trăm trên thực tế trong thí nghiệm này của bản thân tác giả phần trăm đ•ợc chuộng trong trình bày dự toán cho quản lý vì chúng dễ nắm bắt hơn. Quản lý dự án phần mềm 227 2 sẽ dự toán 5 ngày 4 sẽ dự toán 7 ngày 6 sẽ dự toán 9 ngày 4 sẽ dự toán 11 ngày 2 sẽ dự toán 13 ngày 1 sẽ dự toán 16 ngày H10.3 Phân bổ chính tắc dự toán. Hình 10.3 giới thiệu đồ thị của các con số trên. Đ•ờng biểu diễn có đ•ợc, trong thống kê đ•ợc coi là đồ thị hàm phân bổ chính tắc57. Phân bổ chính tắc biểu thị bằng đồ thị hình dáng đều đặn có phân bổ đều các diễn biến quanh số trung bình. Trong thí dụ trên, dự toán bình quân là 9 ngày với càng nhiều dự toán d•ới trung bình nh• trên và quan trọng hơn cả, cả tần độ và cự ly các dự toán d•ới trung bình là t•ơng tự nh• những cái trên trung bình. Nhiều sự kiện th•ờng xảy ra về bản chất diễn ra là phân bổ chính tắc; chẳng hạn chiều cao của sinh viên nam (hay nữ) trong một lớp học, hay số những ngày m•a tháng 4 “ngoại trừ n•ớc Anh, bao giờ cũng là 30”. Giờ chúng ta hãy xem một bộ trả lời thứ hai có thể có của một nhóm các nhà chuyên môn phần mềm với cùng câu hỏi: 1 ng•ời sẽ dự toán 7 ngày 4 sẽ dự toán 9 ngày 10 sẽ dự toán 121 ngày 57 với ng•ời có ý nghĩ toán học, chặt chẽ mà nói, phân bổ chính tắc là phân bổ liên tục. Để đơn giản, chúng ta cũng bao gồm cả phép tính gần đúng riêng biệt của phân bố chuẩn Ngày Dự t Quản lý dự án phần mềm 228 4 sẽ dự toán 13 ngày 1 sẽ dự toán 15 ngày H10.4 Phân bổ chính tắc các dự toán có sai dị ít. Hình 10.4 giới thiệu đồ thị của những kết quả mới đó. Đ•ờng biểu diễn, biểu thị các kết quả đó, không nghi ngờ gì cũng biểu thị phân bổ chính tắc. Dù sao, đ•ờng biểu diễn hình chuông mỏng lại và cao hơn trong thí dụ đầu. Trong tr•ờng hợp này. Tình trạng trả lời sai trệch có ít hơn trong thí dụ đầu. Trung bình cũng lại chuyển dịch bây giờ là 11 ngày. Mọi phân bổ chính tắc đ•ợc biểu thị bởi hai thông số, số trung bình (kỳ vọng) và mức độ sai lệch (ph•ơng sai). Số trung bình đ•ợc coi là trị số mong đợi, , và mức độ sai lệch đ•ợc coi là sai lệch chuẩn . Chúng ta sẽ sử dụng các phép tính gần đúng58 để tính các tham số phân bổ chính tắc của các dự toán dự án phần mềm khác nhau. B•ớc đầu là tính dự toán tr•ờng hợp tồi nhất và dự toán tr•ờng hợp tốt nhất. Những số đó có thể đ•ợc dự toán bởi một các nhân hoặc bởi một nhóm ng•ời. Nếu chúng ta dự toán rằng việc phát triển của một bộ driver truyền thông đồng bộ hẳn nhanh nhất là 4 tuần, chậm nhất là 12 tuần, khi đó dự toán tr•ờng hợp tốt nhất là 4 tuần còn tr•ờng hợp xấu nhất là 12 tuần (đó không phải là một khoảng tin cậy, vì rằng chúng ta không biết xác suất của sự đúng đắn trong tính toán của chúng ta). Hai giá trị này, 58 thí dụ phép tính gần đúng của Nienbung (1989), để biết đ•ợc đầy đủ về các chủ đề này nọ của thống kê, hãy coi Fraser (1976). Dự tNgày Dự t Quản lý dự án phần mềm 229 tr•ờng hợp tốt nhất và tr•ờng hợp xấu nhất, là gần đúng với hai tháI cực của đ•ờng cong phân bố chuẩn. Bây giờ chúng ta cần phải tính toán các giá trị trung gian giữa hai giá trị thái cực đó. Càng nhiều dự toán chúng ta có thể cung cấp giữa hai cực đ•ờng biểu diễn chính tắc càng chính xác hơn. Dù sao, chúng ta sẽ tính gần đúng với trị số trung gian duy nhất, tr•ờng hợp rất có thể nhất. Trong thí dụ trên nếu bốn tuần là dự toán tr•ờng hợp tốt nhất và 12 tuần là dự toán tr•ờng hợp tồi nhất, chúng ta có thể kết luận là sáu tuần là thoả đáng về thời gian cho sự phát triển của ng•ời điều khiển liên lạc đồng bộ, thành thử 7 tuần là tr•ờng hợp rất có thể nhất (Xin nhớ là tr•ờng hợp rất có thể nhất là dự toán độc lập và không phải là số trung bình suy từ các dự toán tr•ờng hợp tốt nhất và tr•ờng hợp tồi nhất). Khi sử dụng ba dự toán, tr•ờng hợp tốt nhất, rất có thể và tồi nhất chúng ta sẽ qui xác suất cho mỗi tr•ờng hợp nh• sau59:   = (tr•ờng hợp tồi nhất + 4  rất có thể + tr•ờng hợp tốt nhất) P (tr•ờng hợp tốt nhất) = 0,2 P (tr•ờng hợp rất có thể) = 0,6 P (tr•ờng hợp tồi nhất)= 0,2 Định nghĩa riêng biệt của trị số trông đợi  là  = E (x) = xP(x) Bởi vậy, gần đúng của trị số trông đợi trong thí dụ tr•ớc hẳn là:  =E(x) = 0,24 + 0,67 + 0,212 = 7,4 Giá trị gần đúng đơn giản cho sai dị chuẩn hẳn là hiệu số của các cực trị nhân với xác suất của chúng:   = (tr•ờng hợp tồi nhất) P(tr•ờng hợp tồi nhất) - (tr•ờng hợp tốt nhất  P(tr•ờng hợp tốt nhất) Trong thí dụ tr•ớc sẽ cho:  = 0,212 – 0,24 = 16 Chúng ta có thể sử dụng các bảng phân bổ chính tắc để phát hiện là: (, ) cho 68% khoảng tin cậy (, ) cho 95% khoảng tin cậy (, ) cho 99% khoảng tin cậy 59 Cả Nienburg (1989) và Sodhi (1990) đều dùng công thức tiệm cận tuơng tự sau:  = (tr•ờng hợp xấu nhất + 4  tr•ờng hợp hay xẩy ra nhất + tr•ờng hợp tốt nhất)/6 Quản lý dự án phần mềm 230 Điều này có nghĩa là trong thí dụ trên, chúng ta có thể dự toán thời gian để phát triển ng•ời điều khiển liên lạc đồng bộ là giữa 4,2 ngày và 106 ngày và chúng ta tin cậy 95% của dự toán của chúng ta. Chúng ta cũng có thể dự toán thời gian phát triển là giữa 5,8 ngày và 9 ngày, nh•ng rồi chúng ta chỉ có thể là 68% tin cậy của dự toán của chúng ta. Một trong những tính chất của thông kê là kết quả chỉ có thể tốt nh• dữ liệu mà chúng dựa vào “một dạng của ‘rác vào thì rác ra’”. Do đấy quan trọng là phải dành thời gian và công sức cần thiết cho sự phát triển của 3 dự toán có hiệu quả. Một ph•ơng cách vững vàng, mặc dù công phu là đòi hỏi một số các kỹ s• phần mềm (cho là 6) để chuẩn bị các dự toán cá nhân cho các tr•ờng hợp tồi nhất, tốt nhất và rất có thể. Dự toán tr•ờng hợp tồi nhất và dự toán tr•ờng hợp tốt nhất hẳn là hai cực có đ•ợc trong khi dự toán tr•ờng hợp rất có thể hẳn hoặc là trung bình, bình quân hay th•ờng xuyên nhất (ph•ơng thức) 10.7 dự toán các nguồn lực phần cứng. Phần mềm phải đ•ợc thiết kế khớp một cách thoải mái vào môi tr•ờng chủ của nó. Môi tr•ờng chủ bao gồm phần cứng mục tiêu và các thuộc tính của nó. Thiết kế phần mềm tồi có thể dẫn đến quá tải của công suất CPU hay có thể v•ợt quá công suất bộ nhớ có đ•ợc hay l•u giữ hàng loạt. Đôi khi điều này có thể, nh•ng không phải luôn luôn đ•ợc bổ cứu bằng cách triển khai (mở rộng) phần cứng mục tiêu, dẫn đến tăng chi phí dự án. Các nguồn phần cứng đ•ợc đo bằng đơn vị của nguồn đặc biệt xét đến: với truyền thông thì bit/giây (hay byte/giây), với kho nhớ là kilobyte, megabyte và thậm chí là gigabyte, với CPU đặc hiệu thì phần trăm của tải CPU. Nguồn chủ yếu, tuỳ thuộc nặng nề vào phần cứng, mặc dù trên thực tế không phải bản thân phần cứng, mà là tốc độ. Dự toán tốc độ mô tả kỳ vọng của chúng ta về mặt thực hiện của hệ thống phải phát triển và th•ờng đ•ợc yêu cầu trong pha quy hoạch sớm của dự án. Chúng ta sẽ xem xét các ph•ơng pháp dự toán ba nguồn chính sau: 1 tải CPU 2 l•u giữ dữ liệu 3 tốc độ Tốc độ mặc dù là thuộc tính chứ không là nguồn, vẫn sẽ đ•ợc xem là nguồn cho mục đích thảo luận này. 10.7.1 Tải CPU Dự toán tải CPU có thể hoàn toàn phức tạp, đặc biệt trong môi tr•ờng xử lý nhiều hộ mà vào một thời gian đã cho phải hơn một xử lý có thể phải cạnh tranh cho CPU. Điều này t•ơng tự nh• xếp hàng dịch vụ trong đó một số những ng•ời yêu cầu dịch vụ chờ đợi dịch vụ, đ•ợc một hay Quản lý dự án phần mềm 231 nhiều nguời cung cấp dịch vụ cung cấp. Trong bối cảnh của chúng ta, những ng•ời yêu cầu dịch vụ là bộ xử lý và ng•ời cung cấp dịch vụ là CPU. Vấn đề xếp hàng dịch vụ là vấn đề phổ thông trong vận trù học và đ•ợc giải quyết có sự hỗ trợ của hống kê. Để thảo luận thêm về lý thuyết xếp hàng, hãy coi Gillett (1976) Chúng ta sẽ xem xét tải CPU trong môi tr•ờng xác định hơn một chút. Chúng ta giả sử rằng ở vào thời gian đã cho, chúng ta có thể xác định có những yêu cầu nào đối với các nguồn xử lý CPU. Không có giả định đó, dự toán tải CPU không thể tính toán đ•ợc và chỉ có thể đ•ợc suy ra khi mô phỏng môi tr•ờng thực tại và quan sát kết qủa. Tải CPU đ•ợc dự toán thành phần trăm. Chúng ta nói một hệ thống có 75% tải CPU, có nghĩa là 25% của năng suất xử lý có đ•ợc cho những nhiệm vụ phụ. Tải CPU luôn đ•ợc đo trong tình huống tr•ờng hợp tồi nhất. Một tải CPU 75%, có nghĩa là vào một thời gian đã cho, không quá 75% CPU đ•ợc sử dụng. Dù sao, điều này là nghịch lý, vì trên thực tế chúng ta biết là vào mọi lúc 100% CPU đã đ•ợc sử dụng. Do đó chúng ta phải định nghĩa là cái mà ta muốn nói về sử dụng CPU cho mục đích dự toán. Thứ nhất tải CPU luôn đ•ợc đo trong phạm vi một cửa sổ thời gian đặc biệt. Điều này có nghĩa trong một khoảng thời gian đặc biệt (chẳng hạn có thể là 10 ly giây) chúng ta đo l•ợng thời gian mà CPU sử dụng. Một trong những nhiệm vụ chính là lựa chọn cửa sổ thời gian thích hợp. Nhằm xác định sử dụng CPU trong phạm vi cửa sổ thời gian, chúng ta chỉ xem xét những nhiệm vụ không thể xử lý đ•ợc vào bất cứ thời gian nào khác. Trong một hệ thống mà chẩn đoán đ•ợc thực hiện trên cơ sở bất cứ khi nào CPU không có nhiệm vụ nào khác để xử lý, chúng ta hẳn không xem xét những nhiệm vụ chẩn đoán trong tính toán tải CPU. Một hệ thống có 60% tải CPU trong một cửa sổ 10 ly giây có thể chấp nhận một nhiệm vụ phụ 4 ly giây nếu nhiệm vụ đó có thể dung thứ chậm trễ tối đa 10 ly giây. Lấy thí dụ, chúng ta sẽ xem xét đầu vào dữ liệu ở một cảng biên lạc. Nếu cổng có suất chuyển giao dữ liệu 1200 bit mỗi giây thì một byte có thể có đ•ợc ở cổng đầu vào xấp xỉ mỗi 7 ly giây và chúng ta phải sẵn sàng rút một byte khỏi cổng tr•ớc khi byte sau trở nên có đ•ợc. Do đấy bộ điều khiển cảng liên lạc có thể chấp nhận dung sai tối đa 6 ly giâychậm trễ (giả định 1 ly gây thời gian xử lý). Dự toán tải CPU hầu hết th•ờng đ•ợc yêu cầu trong các hệ thống thời gian thực. Chúng hiểu khi đ•ợc yêu cầu trong hệ thống xử lý dữ liệu th•ơng mại. Các hệ thống thời gian thực th•ờng đ•ợc biểu thị bằng vòng lặp hệ thống cơ bản, th•ờng đ•ợc coi là vòng lặp chính hay điều hành. Đây là nhiệm vụ mức thấp, ở đó vòng lặp vô hạn, thực hiện một bộ các nhiệm vụ đồng bộ điều khiển hệ thống. Trong nhiều tr•ờng hợp, vònh lặp mức thấp hiện nay là bộ phận của hệ thống điều hành, nó có thể đ•ợc cấu hình dựa trên thời gian chu kỳ yêu cầu cho vòng lặp. Vòng lặp mức thấp này có thể đ•ợc lựa chọn coi nh• cửa sổ thời gian cho việc tính toán tải Quản lý dự án phần mềm 232 CPU. Nếu vòng lặp chính thậm chí bao gồm nhiều vòng lặp nhanh mức thấp thì vòng lặp nhanh nhỏ nhất có thể đ•ợc chọn làm cửa sổ thời gian (coi hình 10.5). H10.5 Thi hành thời gian thực với các vòng lặp nhanh và chậm Bộ các b•ớc sau mô tả ph•ơng pháp tính tải CPU. Ph•ơng pháp này đòi hỏi một phân giải ban đầu hệ thống thành những nhiệm vụ phần mềm chủ yếu và thời gian thực hiện dự kiến cho mỗi nhiệm vụ. 1. Xác định vòng lặp hệ thống mức thấp nhất, và suy từ điều là cửa sổ thời gian đó đ•ợc sử dụng để xác định tải CPU. 2. Hoàn thiện định thời gian cho phân tích hệ thống và nhận ra mọi nhiệm vụ có thể đ•ợc yêu cầu xử lý trong phạm vi cửa sổ thời gian đó. 3. Phối hợp các thời gian thực hiện dự toán cho mọi nhiệm vụ đ•ợc nhận ra ở b•ớc 2. 4. Phân chia kết quả của b•ớc 3 theo qui mô của cửa sổ thời gian. Xin nhớ là b•ớc 2 đòi hỏi nhận ra bất cứ nhiệm vụ nào có thể yêu cầu (chứ ch•a đ•ợc yêu cầu) thời gian CPU trong phạm vi cửa sổ thời gian. Điều này bao gồm những nhiệm vụ của hệ thống điều hành. Ta hãy xét thí dụ sau. Một hệ thống điều khiển quan tâm tích cực đ•ợc máy tính hoá bao gồm những hợp phần chính sau. 1. Đầu vào dữ liệu từ thiết bị điều khiển. 2. Báo động. 3. Hợp phần giao diện ng•ời dùng. 4. Vòng lặp điều hành để đọc thiết bị điều khiển. Vòng lặp điều hành bao gồm: Vòng lặp nhanh Vòng lặp nhanh Vòng lặp nhanh Vòng lặp nhanh Vòng lặp chậm Quản lý dự án phần mềm 233 i. Một vòng lặp chính đọc hai đầu vào phức tạp cũng đòi hỏi một chút xử lý logic cứ mỗi 400 mili-giây một lần. Nhiệm vụ này đ•ợc dự toán là 60 mili-giây một. ii. Một vòng lặp nhanh đọc hai đầu vào mỗi 40 mili-giây. Những nhiệm vụ này đ•ợc dự toán là 10 mili-giây một. Có 10 vòng lặp nhanh trong phạm vi vòng lặp chính. Chúng ta sẽ lựa chọn cửa sổ thời gian là 40 mili-giây. Khi tính tr•ờng hợp tồi nhất, trong phạm vi cửa sổ thời gian, chúng ta sẽ xem xét những nhiệm vụ vòng lặp nhanh tr•ớc đã. Những nhiệm vụ đó sử dụng ngay lập tức tới 20 mili-giây trong 40 mili-giây có đ•ợc. Điều đó có nghĩa là trong vòng lặp chính 400 mili-giây chỉ có 200 mili-giây đ•ợc dành cho những nhiệm vụ khác. Trong đó, 120 mili-giây đ•ợc yêu cầu cho hai nhiệm vụ vòng lặp chính có thể đ•ợc điều tiết dễ dàng. Nếu chúng ta chia đều những những nhiệm vụ của vòng lặp chính, giữa các vòng lặp nhanh, thì 12 mili-giây phụ sẽ phải có đ•ợc ở cửa sổ thời gian, để có đ•ợc tổng số 32 mili-giây. Hình 10.6 Thi hành thực với các vòng lặp chậm và nhanh (a) Cảm thụ phân tích thời gian (b) Định thời thi hành thực tại Spare & Background Vòng lặp chậm Vòng lặp nhanh Dự toán dựa trên Dự toán dựa trên Spare & Background Vòng lặp chậm Vòng lặp nhanh 40 80 120 160 200 240 280 320 360 400 t(ms) 40 80 120 160 200 240 280 320 360 400 t(ms) (a) (b) Quản lý dự án phần mềm 234 Chúng ta có thể giả định là một khi nhiệm vụ báo động đ•ợc thực hiện, mọi nhiệm vụ khác bị thui chột, khiến chúng ta không cần thiết xem xét thời gian thực hiện cho các nhiệm vụ này nữa. Hợp phần giao diện của ng•ời dùng không phải là hoạt động thời gian thực (so sánh với các nhiệm vụ đầu vào điều khiển thiết bị) và chúng ta có thể cho là giao diện của ng•ời dùng sẽ đ•ợc xử lý bằng phần dự trữ của vòng lặp chính 20 mili-giây trên nền. Các vòng lặp điều hành t•ơng đối đơn giản và đ•ợc dự kiến yêu cầu ít hơn 1 mili-giây và do đó cũng đ•ợc loại ra khỏi việc tính toán này. Tải CPU cho hệ thống điều khiển đ•ợc tăng c•ờng là 32/40 = 0,80 có nghĩa là tải CPU bằng 80% trong cửa sổ thời gian 40 mili-giây. Thí dụ này đ•ợc minh hoạ trong hình 10.6. Một tình huống lý thú xuất hiện khi việc tính toán tải CPU cho kết quả lớn hơn 1.00. Điều này có nghĩa tải CPU lớn hơn 100%! Kết luận hiển nhiên là bộ xử lý bất lực trong việc thực hiện các nhiệm vụ yêu cầu. Trong những tr•ờng hợp đó, có hai biện pháp sửa chữa có thể đ•ợc: hoặc yêu cầu của hệ thống phải giảm đi hoặc bộ xử lý nhanh hơn phải đ•ợc sử dụng. Nếu nh• một tải CPU 100% có gây ra vấn đề, thì thông th•ờng một tải CPU 90% cũng gây ra vấn đề không kém. Điều này là do việc dự toán tải CPU ít khi đ•ợc chính xác. Cũng vậy, việc thay đổi yêu cầu trong phát triển dự án th•ờng làm tăng tải CPU. Một nhận định khác là nhu cầu dự trữ nguồn CPU cho sự mở rộng sau này của hệ thống. Bao giờ đây cũng là thực tiễn tốt để thiết kế một hệ phần mềm, sao cho khởi thuỷ không cần quá 60% tải CPU. 10.7.2 L•u giữ dữ liệu. Chúng ta sẽ sử dụng từ l•u giữ dữ liệu cho cả l•u giữ phần cứng và l•u giữ dữ liệu. Việc sử dụng l•u giữ dữ liệu căn bản là một vấn đề thiết kế và thông th•ờng có liên quan (tuy hạn chế) về yêu cầu cho hệ thống. Các yêu cầu có thể xem xét l•u giữ dữ liệu ở khía cạnh chi phí, do việc thiết kế l•u giữ dữ liệu không hiệu qủa có thể đòi hỏi quá mức các ph•ơng tiện l•u giữ, nh• bộ điều khiển đĩa và bộ nhớ. Những ph•ơng tiện không nhất thiết đó biến thành những khoản chi phí bổ xung. Các yêu cầu cũng có thể nói đến l•u giữ dữ liệu trong khung cảnh không gian. Yêu cầu là hệ thống phải cung cấp 30% không gian đĩa mềm và bộ nhớ dự trữ, có thể có tác động to lớn đến thiết kế l•u giữ dữ liệu, đặc biệt trong một hệ thống mà việc tiêu dùng bộ nhớ trong vận hành là sát tới giới hạn. Xét toàn cục, ng•ời dùng không nhìn thấy đ•ợc việc sử dụng l•u giữ dữ liệu, và do đó việc đó chủ yếu đ•ợc xác định trong pha thiết kế. Dù sao, dự toán sơ bộ b•ớc đầu đ•ợc yêu cầu ngay ở những pha sớm nhất Quản lý dự án phần mềm 235 của dự án, để đảm bảo là cấu hình phần cứng mục tiêu có khả năng trợ giúp cho hệ thống phần mềm đ•ợc phát triển. Độ đo khối l•ợng phần mềm đ•ợc phát triển nh• bàn đến tr•ớc đây ở phần 10.1 có thể là các dòng mã (KSLOC) hay Kilobyte bộ nhớ. Việc l•u giữ bộ nhớ chỉ đ•ợc dự toán theo đơn vị Kbyte. B•ớc đầu liên quan đến phân giải hệ thống, t•ơng tự ph•ơng pháp dự toán từng b•ớc mô tả trong phần 10.2. Lần này mục tiêu là mô tả khối l•ợng bộ nhớ mà mỗi mô đun yêu cầu lúc thực hiện. Các hợp phần phần mềm mức thấp đ•ợc phối hợp thành những nhóm mô đun c• trú cạnh tranh bộ nhớ. Rồi các yếu tố khác cũng đ•ợc xem xét nh• phân bố động bộ nhớ, yêu cầu của hệ thống điều hành và các buffer c• trú trong bộ nhớ và các bảng. Ph•ơng pháp sau cung cấp dự toán bộ nhớ dựa trên sử dụng bộ nhớ tr•ờng hợp tồi nhất trong quá trình thực hiện hệ thống. 1. Phân giải hệ thống thành các mô đun mức thấp và dự toán các yêu cầu bộ nhớ cho mỗi mô đun vào lúc thực hiện. 2. Nhận ra các yêu cầu bộ nhớ gián tiếp của mỗi mô đun căn cứ vào  Các vùng hoạt động động và tĩnh của bộ nhớ.  Các bảng c• trú bộ nhớ  Các buffer (đệm) 3. Nhận ra bộ các mô đun bộ nhớ với yêu cầu bộ nhớ phối hợp lớn nhất mà sẽ là c• trú của bộ nhớ bất cứ lúc nào. 4. Duyệt lại t•ơng quan giữa mô đun bộ nhớ và loại bỏ yêu cầu bộ nhớ trùng lặp. 5. Lặp lại các b•ớc 3 và 4 cho đến khi việc sử dụng bộ nhớ lợi nhất đ•ợc trông đợi đã nhận ra. 6. Nhận ra các yêu cầu bộ nhớ mức hệ thống nh•:  Bảng c• trú của bộ nhớ  Buffer file (bộ đệm của file)  Kích cỡ stack. 7. Tính toán toàn bộ sử dụng bộ nhớ của hệ thống điều hành. 8. Phối hợp các kết quả của các b•ớc 5,6, và 7 tạo nên toàn bộ dự toán l•u trữ bộ nhớ. B•ớc 7 phải loại trừ các yêu cầu bộ nhớ đã đ•ợc xét đến ở các b•ớc 5 và 6 (thí dụ cùng các buffer của file phải không xét đến ở b•ớc 2 và b•ớc 6). Việc sử dụng overlay có thể giảm yêu cầu bộ nhớ, nh•ng điều này sẽ đạt đ•ợc với sự thực hiện tốn kém cho các nguồn phụ, nh• đĩa I/O, tải CPU và tốc độ thực hiện. Tình trạng bất lợi (trade-off) giữa bộ nhớ và tốc độ là một yếu tố thông th•ờng trong hầu hết các hệ thống phần mềm. Dự toán các yêu cầu l•u giữ hàng loạt ít gay cấn hơn dự toán yêu cầu của bộ nhớ. Bộ nhớ của máy tính hạn chế nhiều hơn l•u giữ đĩa. L•u giữ đĩa th•ờng chỉ bị hạn chế ở chi phí thiết bị l•u giữ đĩa. Quản lý dự án phần mềm 236 Dự toán sử dụng l•u giữ đĩa phải tính đến các tiêu dùng l•u giữ đĩa sau đây: 1. Hệ thống điều hành cố định và tiện ích dịch vụ. 2. Các yêu cầu hệ thống điều hành biến đổi (overlay và vùng swap, các file hệ thống v.v..) 3. Phần mềm dự án. 4. Các file dữ liệu. Vì mục đích thảo luận này, chúng ta sẽ bao gồm cả khối ch•ơng trình dịch vụ, nh• cơ sở dữ liệu và ch•ơng trình truyền thông, coi nh• bộ phận của hệ thống điều hành. Thông tin liên quan đến sử dụng đĩa của hệ thống điều hành th•ờng do ng•ời bán hàng của hệ thống điều hành cung cấp. Dù sao, nếu hệ thống điều hành đ•ợc phát triển nh• là bộ phận của dự án thì nó phải đ•ợc dự toán hoặc coi nh• hệ thống riêng biệt hoặc coi nh• bộ phận của phần mềm dự án (coi nh• hệ thống phụ). Những yêu cầu của hệ thống điều hành thay đổi phụ thuộc ở cấu hình của hệ thống điều hành đặc tr•ng và ở phần mềm của dự án. Lấy thí dụ không gian của đĩa cho overlay vừa là chức năng của hệ thống điều hành vừa là chức năng của thiết kế phần mềm thực tại. Những hệ thống điều hành tiên tiến th•ờng cung cấp tiện ích cho tổng phí đĩa dự toán (cả về mặt l•u giữ và truy nhập) khi sử dụng overlay. Vùng swap cho các ứng dụng đa ng•ời dùng th•ờng cũng có thể lấy kích cỡ dựa trên các tiện ích của hệ thống điều hành tiêu chuẩn. Các tiện ích đó th•ờng là phần chung điều chỉnh hay công cụ cấu hình của các hệ điều hành. Dự toán cho các yêu cầu về đĩa của phần mềm dự án là thẳng thừng và đ•ợc lập bởi việc phân giải hệ thống. Tổng các dự toán cho mỗi mô đun tạo ra các yêu cầu về đĩa cho toàn bộ phần mềm dự án đ•ợc phát triển. Việc chuẩn bị dự toán cho mọi kích cỡ file dữ liệu là một nhiệm vụ buồn tẻ và đ•ợc căn cứ ở kích cỡ của các bản ghi riêng rẽ và số tối đa các bản ghi cho mỗi file. Nó trở nên phức tạp hơn khi các bản ghi có chiền dài thay đổi. Trong những tr•ờng hợp nh• thế, các cỡ file bản ghi cực đại hay trung bình nên đ•ợc sự dụng. Mọi file dữ liệu đều có phần đầu bao gồm chỉ số và đ•ờng dẫn th• mục. Những thứ này cũng phải đ•ợc đ•a thành nhân tố dự toán và tuỳ thuộc nặng nề vào cơ sở dữ liệu hay hệ thống file đang đ•ợc sử dụng. Trong nhiệu tr•ờng hợp dự toán dữ liệu l•u giữ hàng loạt không cần căn cứ ở ch•ơng trình kịch bản tồi nhất. Điều này thoạt tiên do tính dễ dàng t•ơng đối trong việc bổ sung thêm bộ nhớ l•u giữ hàng loạt vào cấu hình. Do đấy, trong nhiều tr•ờng hợp, yêu cầu l•u giữ hàng loạt trung bình là có thể đủ. Rõ ràng rằng có một số tr•ờng hợp phải sử dụng kịch bản tồi nhất, nh• khi mà việc sử dụng kho nhớ hàng loạt tăng quá nhanh. Dự toán thiết kế cho yêu cầu l•u giữ dữ liệu cũng phải chiếu cố đến phần dự trữ. Điều này đặc biệt đúng với các dự toán bộ nhớ, lúc đó thiết kế phải dành khoảng 33% cho dự phòng. Bộ nhớ dự phòng này phải có Quản lý dự án phần mềm 237 sẵn để bao trùm các sai khi dự toán, các thay đổi yêu cầu và sự phát triển trong t•ơng lai. 10.7.3 Tốc độ Tốc độ của một hệ thống đ•ợc đo theo thời gian đáp ứng. Điều này th•ờng căn cứ ở bộ yêu cầu rất ngặt nghèo xác định đáp ứng của hệ thống với các sự cố đặc thù. Một thí dụ là có thể là yêu cầu rằng giao diện của ng•ời dùng phải đáp ứng đầu vào của ng•ời dùng không quá ba giây. Thật là cực kỳ thất vọng phải chờ đợi tr•ớc máy thủ qũi ngân hàng tự động để chờ trả lời một yêu cầu. Nhiều những máy thủ qũi nh• thế đã giảm nhẹ nỗi thất vọng phải chờ đợi bằng cách tạo ra tiếng động nền vang lên tựa nh• tiền đang đ•ợc đếm bằng máy cơ khí hay ít ra nh• có cái gì đang diễn ra. Một giải pháp đơn giản hơn là phát ra tín hiệu nhấp nháy để nói rằng là “giao dịch đang đ•ợc thực hiện”. Hình 10.7 Thời gian đáp ứng nhận đ•ợc khi liên hệ ng•ợc Hatley và Pirbhai (1988) phân biệt định thời gian ngoại tại và định thời gian nội tại. Định giờ nội tại là một kết quả của thiết kế trong khi định thời gian ngoại tại là kết quả yêu cầu. Theo thế định thời gian ngoại tại có thể có là thời gian đáp ứng. Hatley và Pirbhai gợi ý một biển đồ (mà các ông gọi là bức tranh yêu cầu định thời gian) tham gia vào việc phân tích các ràng buộc liên quan tới định thời gian hệ thống. Trong phân tích định thời gian nội tại của các ông, Hatley và Pirbhai bao gồm các hoạt động không liên quan trực tiếp tới thời gian đáp ứng. Chúng ta sẽ chỉ xét ở đây các kết quả định thời gian trực tiếp liên quan với thời gian đáp ứng nh• đ•ợc những ng•ời dùng hệ thống nhìn nhận bên ngoài. Thời gian đáp ứng có thể đ•ợc cảm nhận là phản hồi hệ thống phát sinh bởi một sự cố bên ngoàI: điều này đ•ợc minh hoạ ở hình 10.7. Do đấy thoả đáng là chia thời gian đáp ứng ra ba hợp phần cơ bản. 1. Thời gian từ cuối sự xuất hiện của sự cố cho đến khi sự cố đ•ợc hệ thống nhận ra. Sự kiện từ bên ngoài Liên hệ ng•ợc Tiến trình Ng•ời dùng Quản lý dự án phần mềm 238 2. Thời gian xử lý sự cố. 3. Thời gian từ khi kết thúc xử lý sự cố cho tới khi khởi đầu đáp ứng ngoại tại Hình 10.8 Khoảng thời gian đáp ứng Nhớ là thời gian đáp ứng không bao gồm thời gian để thực hiện sự cố ở cả hai đầu: nó chỉ bao gồm thời khoảng giữa hai sự cố (coi hình 10.8). Khi dự toán thời gian đáp ứng, thì viễn cảnh là một trong ba thứ đầu vào, xử lý và đầu ra. Hợp phần đầu vào liên quan đến thời gian để hệ thống nhận đ•ợc thông tin về cuối của một sự cố và nhận ra nó. Bảng 10.7 thí dụ về bảng phân bố thời gian đáp ứng Thời gian đáp ứng (tính theo giây) Tỷ lệ phần trăm 0-3 20% 3-6 60% 6-9 39% 9-15 1% Hợp phần đầu ra liên quan đến thời gian cần có để hệ thống có đ•ợc kết quả xử lý và truyền thông nó tới bộ phát đáp ứng bên ngoài. Hợp phần xử lí sự cố bao gồm mọi hoạt động trong phạm vi hệ thống cần có để phát ra đáp ứng. Điều này cũng bao gồm chậm trễ do những hoạt động •u tiên cao hơn và do những thiết bị bên ngoài nh• bộ điều khiển đĩa phải đ•ợc tuy cập để có đ•ợc thông tin liên quan. Thời gian đáp ứng thông th•ờng đ•ợc cung cấp nh• đáp ứng tr•ờng hợp tồi nhất và đáp ứng trung bình. Trong thí dụ tr•ớc thủ quĩ tự động trả lời đầu vào bàn phím của ng•ời dùng. Lần ấn phím cuối cùng của một giao dịch (th•ờng là enter) bắt đầu thời khoảng đáp ứng. Hiển thị màn hình hay phân phối tiền mặt kết thúc thời khoảng này ngay khi bắt đầu vận hành. Nh• chúng ta đã thấy ng•ời thiết kế hệ thống hẳn ‘lừa bịp’ bằng cách trả lời bằng thông báo “xin đợi một chút” tr•ớc khi có sẵn sàng câu trả lời thực. Điều này là một thực tế có hiệu lực hoàn mỹ và làm cho hệ thống trở nên thân thiện với ng•ời Tiến trìnhSự kiện Đáp ứng Thời gian đáp ứng Dự toá Quản lý dự án phần mềm 239 dùng hơn. Dù sao, thông báo nhấp nháy báo rằng “xin đợi, bây giờ đang xử lý yêu cầu” cũng có thể trở thành gây tức bực nếu hiện hình quá lâu. Đáp ứng trung bình của thủ quĩ tự động tr•ớc yêu cầu quyết toán có thể đòi hỏi thời gian đáp ứng là 5 giây. Trong một số tr•ờng hợp khi hệ thống thủ quĩ đang ở vào lúc sử dụng cao điểm và thời gian đáp ứng tr•ờng hợp hẳn là 15 giây. Mặc dù việc chậm trả lời 15 giây có thể gây tức bực cho ng•ời dùng thì nó lại có thể chấp nhận đ•ợc cho ngân hàng nếu điều này không xảy ra quá th•ờng xuyên. Do đấy cần thiết khi trình bày dự toán thời gian đáp ứng phải bao gồm cả dự toán phần trăm thời gian mà tr•ờng hợp tồi nhất có thể dự kiến xảy ra. Chẳng hạn chúng ta có thể khẳng định: 1. Thời gian đáp ứng trung bình dự kiến: 5 giây 2. Thời gian đáp ứng tr•ờng hợp tồi nhất dự kiến: 15 giây trong 1% giao dịch. Việc mô tả chi tiết hơn thời gian đáp ứng dự kiến th•ờng đ•ợc yêu cầu. Trong thí dụ trên 10% chậm trễ đáp ứng có thể chiếm 14,5 giây là không thể chấp nhận đ•ợc, nh•ng lại có thể khớp với các con số ở trên. Trong những tr•ờng hợp đó, thì bảng phân phối (coi bảng 10.7) đ•ợc •a thích hơn. 10.8 tổng phí không phát triển. Những dự toán tốt đ•ợc căn cứ ở hầu hết dữ liệu mới nhất và dễ hiểu hiện có. Do đấy, điều quan trọng là phải cập nhật định kỳ mọi dự toán của dự án. Chí ít ra thì điều này phải đ•ợc làm ở các cột mốc dự án chủ yếu, nh• tổng duyệt yêu cầu phần mềm, tổng duyệt thiết kế sơ bộ và tổng duyệt thiết kế tới hạn. Các dự toán đ•ợc cập nhật phải là bộ phận của những thứ giao đ•ợc có yêu cầu ở những tổng duyệt đó. Bảng 10.8 Tổng phí của các hoạt động không phát triển Tổng phí Quản lý 0.1 Khống chế cấu hình 0,02 Bảo đảm chất l•ợng phần mềm 0,03 Sau khi kết thúc pha thiết kế, các dự toán phải đ•ợc xem lại tr•ớc khi tích hợp bắt đầu và rồi lại xem lại tr•ớc khi thử nghiệm bắt đầu. Cũng vậy, mỗi sự cố không dự kiến xảy ra trong chu kỳ phát triển có thể đòi hỏi phải tính toán lại dự toán. Một thí dụ của sự cố nh• thế có thể là việc thay thế hợp phần lỗi thời bằng một hợp phần phát triển mới hay một sự chậm trễ dự án ch•a lập lịch chủ yếu. Cũng vậy mỗi thay đổi đến đặc tả yêu cầu của dự án bao giờ cũng phải kèm theo phân tích tác động của thay đổi đó đến lịch dự án. Mọi thay đổi Quản lý dự án phần mềm 240 với số rất ít ngoại lệ đều phải thay đổi chi phí. Ngay việc rút bỏ một yêu cầu cũng gây ra thay đổi chi phí dự án đã dự toán. Một khối l•ợng thay đổi nào đó đến đặc tả yêu cầu th•ờng đ•ợc tính đến trong việc chuẩn bị dự toán của dự án. Điều này bao gồm trong dự toán d•ới hình thức yếu tố an toàn. Yếu tố an toàn cũng có thể đ•ợc dùng để bù trừ cho các tr•ờng hợp khác nh• sai lầm trong dự toán và chậm trễ không dự kiến. Các yếu tố an toàn th•ờng sử dụng từ 20% đến 40% tuỳ theo mức độ tin cậy trong dự toán, dự đoán các thay đổi yêu cầu và các chậm trễ có thể xảy ra. Các yếu tố t•ơng tự cũng đôi khi đ•ợc dùng để đ•a vào trong dự toán những hoạt động không phát triển nh• quản lý dự án, kiểm tra cấu hình và bảo đảm chất l•ợng. Dù sao, chừng mực của những nhiệm vụ này cũng phụ thuộc ở các đặc tính khác của dự án. Một dự án rất nhỏ có thể không yêu cầu bất cứ quản lý trực tiếp nào trong khi dự án lớn hẳn bị kết tội nếu không có nó. Bảng 10.8 trình bày các yếu tố tổng phí cho các hoạt động không phát triển của dự án phần mềm. Các con số trong bảng 10.8 cho thấy là dự án phần mềm với đội ngũ 100 kỹ s• hẳn yêu cầu xấp xỉ 10 nhà quản lý (thời gian làm việc 100%). Điều này bao gồm những nhiệm vụ nh• quản lý dự án, phó quản lý dự án, lãnh đạo đội (có thể dành một phần thời gian vào công việc phát triển) v.v. Trong một dự án nhỏ ba ng•ời, một trong những thành viên hẳn đ•ợc dự kiến giành khoảng 1/3 thời gian của anh hay chị cho việc quản lý dự án. T•ơng tự, trong một dự án phần mềm do một đội ngũ 100 kỹ s• phát triển, chúng ta có thể dự kiến bố trí 2 kỹ s• kiểm tra cấu hình và 3 kỹ s• đảm bảo chất l•ợng phần mềm. Công bố tổng quát hơn có thể là trong một dự án 100 năm công, 2 năm công hẳn đ•ợc giành cho kiểm tra cấu hình và 3 năm công cho bảo đảm chất l•ợng tổng hợp. Các con số trong bản 10.8 có thể hơi bị ảnh h•ởng bởi qui mô dự án và bởi các yếu tố bản đến ở phần 10.4. Một dự án phức tạp sẽ đòi hỏi phần chung nhiều hơn một dự án t•ơng đối đơn giản. Toàn bộ tổng phí dự án cho những hoạt động đó tất cả khoảng 15%. Quan trọng là phải nhớ rằng điều này chỉ liên quan đến tổng phí dự án trực tiếp và không tính đến thời gian đầu t• của quản lý cấp cao, th• ký văn phòng v.v.. 10.9 Tóm tắt Ch•ơng này minh hoạ dự toán đ•ợc vận dụng thế nào trong việc tiên liệu bất trắc. Bất cứ l•ợng không biết nào đều có thể đ•ợc dự toán trong khi các l•ợng đã biết không cần dự toán. Với ng•ời quản lý dự án phần mềm có nhiều l•ợng không biết phải đ•ợc dự toán. Những l•ợng này liên kết với các lĩnh vực nh•: Quản lý dự án phần mềm 241 1. Chi phí phát triển dự án 2. Lịch phát triển dự án 3. Qui mô đội phát triển dự án 4. Khối l•ợng phần mềm phải phát triển 5. Nguồn lực phần cứng đòi hỏi. Dự toán từng b•ớc th•ờng đ•ợc coi là ph•ơng cách “phân chia và khuất phục”, phân vấn đề lớn ra vô vàn vấn đề nhỏ và đ•ợc dùng trong hầu hết kỹ thuật dự toán. Ph•ơng cách cơ bản là phân giải dự án thành những hợp phần xác định rõ và rồi lặp lại từng b•ớc đến khi chỉ còn lại những đơn vị nhỏ có thể dễ dự toán hơn. Phân giải ban đầu của dự án phần mềm nhận ra 4 phạm trù chủ yếu với những mức độ rủi ro phát triển khác nhau liên kết với chúng. B•ớc đầu tiên của phân giải dự án tạo ra những hợp phần dự án hoặc (1) chúng ta đã có (2) chúng ta biết phát triển nh• thế nào (kinh nghiệm trọn vẹn) (3) ít ra chúng ta đã phần nào làm quen với chúng (kinh nghiệm một phần) hay (4) hoàn toàn mới với chúng ta (phát triển mới). Các kỹ thuật dự toán đặc thù có thể đ•ợc vận dụng cho mỗi loại hợp phần dự án khác nhau. Một ph•ơng pháp khác, gọi là thuật toán chi phí kiến thiết (COCOMO) bao gồm 10 b•ớc cơ bản. Những b•ớc đó bao gồm phân giải dự án ra các hợp phần, vận dụng công thức công sức vào mỗi hợp phần và phối hợp mọi dữ liệu tạo ra vào một dự toán chi phí duy nhất của dự án. Phân tích chức năng (FPA) tạo ra dự toán của dự án căn cứ ở qui mô vấn đề. Số l•ợng các chức năng trong dự án xác định qui mô vấn đề, đ•ợc biểu thị bằng giá trị số (trị số FPA). Trị số FPA của dự án có thể đ•ợc dùng để:  So sánh độ phức tạp của các dự án.  So sánh công sức t•ơng đối đòi hỏi để hoàn thành dự án.  Phát sinh các độ đo dự án khác (nh• các SLOC) Dự toán cũng th•ờng đ•ợc trình bày nh• là một phạm vi. Một phạm vi là một dự toán có ích trong qui hoạch phát triển của dự án. Lý thuyết thống kê đứng sau ph•ơng cách này đề cập quan niệm khoảng tin cậy, nó cung cấp xác suất là chi phí phát triển sẽ nằm trong một phạm vi đã cho. Các ph•ơng pháp dự toán tải CPU, l•u giữ dữ liệu và tốc độ đ•ợc căn cứ ở phân giải phần mềm thành những mô đun dự toán đ•ợc. Rồi những dự toán này đ•ợc phối hợp với yếu tố an toàn. Các yếu tố an toàn th•ờng sử dụng từ 20% đến 40% tuỳ theo mức độ tin cậy trong dự toán và thời hạn dự kiến thay đổi yêu cầu. Các dự toán tốt đ•ợc căn c• ở hầu hết dữ liệu mới nhất, dễ hiểu hiện có đ•ợc. Do đó, quan trọng là phải cập nhật định kỳ toàn bộ dự toán của dự án. Dù sao, bất kể ph•ơng pháp dự toán nào đ•ợc sử dụng, quan trọng là Quản lý dự án phần mềm 242 bao giờ cũng phải nhớ rằng dự toán chỉ có thể tốt đ•ợc nh• các dữ liệu đ•ợc dùng làm căn cứ. Bài tập. 1. Phân tích một hệ thống kiểm warehouse do một công ty phát triển vốn tr•ớc đây đã phát triển hệ thống kiểm cửa hàng bách hoá. Hãy sử dụng dự toán từng b•ớc, phân giải hệ thống thành 4 phạm trù hợp phần. Sau đó phân giải hợp phần kinh nghiệm từng phần thành hợp phần kinh nghiệm đày đủ và hợp phần phát triển mới. Đặc tả mọi giả định đã làm. 2. Phát triển tiếp vấn đề ở bài tập 1 và chuẩn bị một kế hoạchdự toán các hợp phần phát triển mới bằng cách sử dụng lấy mẫu thống kê. Xác định nhóm phạm trù và bố trí mỗi hợp phần phát triển mới vào loại thích hợp của nó. Chọn những mô đun tiêu biểu từ mỗi phạm trù để thực hiện. Giải thích điều hợp lý của việc gán các loại và lựa chọn đã làm. 3. Căn cứ ở kinh nghiệm của bạn, hãy bố trí những con số KSLOC hợp lý vào mỗi hợp phần ở bài tập 2. Giả định mỗi ng•ời phát triển cho 5 KSLOC. Giả định là 10% nhân lực là mức 1, 30% ở mức 2, 45% mức 3 và 15% mức 4. Hãy tính nhân tố PL cho dự án phát triển. Bình luận tác động của trị số PL đó tới chi phí phát triển dự án. 4. Duyệt lại bảng 10.1, có liên quan đến việc tính toán thừa số PL. Cho một gợi ý một bảng trị số khác, căn cứ ở các mức KSLOC phụ thêm và một phạm trù rộng các nhân tử. Bình luận lý do chọn những con số trong bảng của bạn. Tính lại trị số trong bảng 10.2 căn cứ ở bảng bạn đã đề nghị. 5. Phân giải hệ thống kiểm kê warehouse mô tả ở bài tập 1 thành các hợp phần theo mức phức tạp. Căn cứ ở các con số KSLOC bố trí ở bài tập 3, hãy tính SEM cho mỗi lớp hợp phần và phối hợp kết quả để có đ•ợc con số dự toán của SEM cho toàn bộ dự án. 6. Phân giải hệ thống kiểm kê kho mô tả ở bài tập 1 ra những hợp phần theo mức tin cậy. Sử dụng năm mức tin cậy để đ•a thành thừa số độ tin cậy vào dự toán SEM tính ở bài tập 5. 7. (a) Gợi ý bảng các nhân tử 5 mức cho mức môi tr•ờng phát triển, căn cứ ở ba mức qui mô dự án. KSLOC < 25, 25 < KSLOC < 300, 3000 < KSLOC (b) Gợi ý bảng nhân tử để đ•a thành thừa số tính phức tạp của hệ thống phụ. Thảo luận về cỡ của dự án phải xét. 8. Tính dự toán chi phí cho hệ thống kiểm warehouse mô tả ở bài tập 1 bằng cách sử dụng các kết quả của các bài tập 3, 5, 6 và 7. 9. Xem xét việc vận dụng thuật toán phân tích l•ợng chức năng vào hệ thống kiểm warehouse mô tả ở bài tập 1. Lợi và bất lợi trong việc sử dụng ph•ơng pháp FPA ? So sánh FPA với COCOMO cho dự án đặc biệt này. Quản lý dự án phần mềm 243 10. Xếp loại uỷ thác: căn cứ ở các kết quả cá nhân khác nhau cho bài tập 8, hãy tính khoảng cách tin cậy 68% và 95% cho phạm vi chi phí phát triển đối với hệ thống kiểm warehouse này. 11. (a) Duyệt lại thí dụ tải CPU ở phần 10.6. Giả định rằng đầu vào của thiết bị đ•ợc điều khiển bởi các ngắt. Mỗi ngắt có tổng phí 0,5 mili-giây. Vậy tải CPU là bao? (b) Tải CPU phải là gì nếu vòng lặp nhanh có ba đầu vào chứ không phải 2 ? Bình luận tác động của kết quả.