Kỹ thuật Ước tính - Hướng dẫn Nhanh
Estimation là quá trình tìm kiếm ước tính, hoặc ước lượng, là một giá trị có thể được sử dụng cho một số mục đích ngay cả khi dữ liệu đầu vào có thể không đầy đủ, không chắc chắn hoặc không ổn định.
Ước tính xác định cần bao nhiêu tiền, công sức, nguồn lực và thời gian để xây dựng một hệ thống hoặc sản phẩm cụ thể. Ước tính dựa trên -
- Dữ liệu trong quá khứ / Kinh nghiệm trong quá khứ
- Tài liệu / Kiến thức sẵn có
- Assumptions
- Rủi ro đã xác định
Bốn bước cơ bản trong Ước tính Dự án Phần mềm là:
- Ước tính kích thước của sản phẩm phát triển.
- Ước tính nỗ lực theo người-tháng hoặc người-giờ.
- Ước tính lịch trình trong các tháng dương lịch.
- Ước tính chi phí dự án bằng đơn vị tiền tệ đã thỏa thuận.
Các quan sát về ước tính
Ước tính không cần phải là một nhiệm vụ một lần trong một dự án. Nó có thể diễn ra trong -
- Mua lại một Dự án.
- Lập kế hoạch Dự án.
- Thực hiện Dự án khi có nhu cầu.
Phạm vi dự án phải được hiểu rõ trước khi bắt đầu quá trình ước tính. Sẽ rất hữu ích nếu có Dữ liệu dự án lịch sử.
Các chỉ số của dự án có thể cung cấp viễn cảnh lịch sử và đầu vào có giá trị để tạo ra các ước tính định lượng.
Việc lập kế hoạch đòi hỏi các nhà quản lý kỹ thuật và nhóm phần mềm phải đưa ra cam kết ban đầu vì nó dẫn đến trách nhiệm và giải trình.
Kinh nghiệm trong quá khứ có thể hỗ trợ rất nhiều.
Sử dụng ít nhất hai kỹ thuật ước tính để đạt được ước tính và đối chiếu các giá trị kết quả. Tham khảo Kỹ thuật phân tách trong phần tiếp theo để tìm hiểu về điều chỉnh ước tính.
Các kế hoạch nên lặp đi lặp lại và cho phép điều chỉnh khi thời gian trôi qua và biết thêm chi tiết.
Phương pháp tiếp cận ước tính dự án chung
Phương pháp Ước tính Dự án được sử dụng rộng rãi là Decomposition Technique. Kỹ thuật phân rã có cách tiếp cận chia để trị. Quy mô, Nỗ lực và Ước tính chi phí được thực hiện theo từng bước bằng cách chia nhỏ Dự án thành các Chức năng chính hoặc các Hoạt động Kỹ thuật Phần mềm liên quan.
Step 1 - Hiểu rõ phạm vi của phần mềm sẽ xây dựng.
Step 2 - Tạo ước tính kích thước phần mềm.
Bắt đầu với tuyên bố về phạm vi.
Phân chia phần mềm thành các chức năng có thể được ước tính riêng lẻ.
Tính kích thước của từng hàm.
Phát huy nỗ lực và ước tính chi phí bằng cách áp dụng các giá trị kích thước cho các chỉ số năng suất cơ bản của bạn.
Kết hợp các ước tính chức năng để tạo ra một ước tính tổng thể cho toàn bộ dự án.
Step 3- Tạo ra một ước tính về nỗ lực và chi phí. Bạn có thể đạt được nỗ lực và ước tính chi phí bằng cách chia nhỏ dự án thành các hoạt động kỹ thuật phần mềm liên quan.
Xác định trình tự các hoạt động cần thực hiện để dự án được hoàn thành.
Chia các hoạt động thành các nhiệm vụ có thể đo lường được.
Ước tính nỗ lực (tính bằng giờ / ngày) cần thiết để hoàn thành mỗi nhiệm vụ.
Kết hợp ước tính nỗ lực của các nhiệm vụ của hoạt động để tạo ra ước tính cho hoạt động.
Lấy đơn vị chi phí (tức là chi phí / đơn vị nỗ lực) cho mỗi hoạt động từ cơ sở dữ liệu.
Tính tổng nỗ lực và chi phí cho mỗi hoạt động.
Kết hợp nỗ lực và ước tính chi phí cho từng hoạt động để tạo ra nỗ lực tổng thể và ước tính chi phí cho toàn bộ dự án.
Step 4- Các ước tính đối chiếu: So sánh các giá trị thu được từ Bước 3 với các giá trị thu được từ Bước 2. Nếu cả hai bộ ước lượng đều đồng ý, thì các con số của bạn có độ tin cậy cao. Mặt khác, nếu xảy ra các ước tính khác biệt rộng rãi, hãy tiến hành điều tra thêm về việc liệu -
Phạm vi của dự án không được hiểu đầy đủ hoặc đã bị hiểu sai.
Phân tích chức năng và / hoặc hoạt động không chính xác.
Dữ liệu lịch sử được sử dụng cho các kỹ thuật ước tính không phù hợp với ứng dụng, hoặc lỗi thời, hoặc đã được áp dụng sai.
Step 5 - Xác định nguyên nhân của phân kỳ và sau đó đối chiếu các ước lượng.
Độ chính xác ước tính
Độ chính xác là một dấu hiệu cho thấy điều gì đó gần với thực tế. Bất cứ khi nào bạn tạo một ước tính, mọi người đều muốn biết các con số gần với thực tế như thế nào. Bạn sẽ muốn mọi ước tính chính xác nhất có thể, dựa trên dữ liệu bạn có tại thời điểm tạo nó. Và tất nhiên bạn không muốn trình bày ước tính theo cách tạo cảm giác tin tưởng sai lầm vào các con số.
Các yếu tố quan trọng ảnh hưởng đến độ chính xác của ước tính là -
Độ chính xác của tất cả dữ liệu đầu vào của ước tính.
Độ chính xác của bất kỳ phép tính ước tính nào.
Dữ liệu lịch sử hoặc dữ liệu ngành được sử dụng để hiệu chỉnh mô hình có khớp với dự án bạn đang ước tính chặt chẽ như thế nào.
Khả năng dự đoán của quá trình phát triển phần mềm của tổ chức bạn.
Tính ổn định của cả yêu cầu sản phẩm và môi trường hỗ trợ nỗ lực kỹ thuật phần mềm.
Dự án thực tế có được lên kế hoạch, giám sát và kiểm soát cẩn thận hay không và không có bất ngờ lớn nào xảy ra gây ra sự chậm trễ không mong muốn.
Sau đây là một số hướng dẫn để đạt được ước tính đáng tin cậy -
- Ước tính cơ sở về các dự án tương tự đã được hoàn thành.
- Sử dụng các kỹ thuật phân tách tương đối đơn giản để tạo ra các ước tính chi phí và nỗ lực của dự án.
- Sử dụng một hoặc nhiều mô hình ước tính thực nghiệm để ước tính chi phí và nỗ lực phần mềm.
Tham khảo phần Hướng dẫn ước tính trong chương này.
Để đảm bảo độ chính xác, bạn luôn nên ước tính bằng ít nhất hai kỹ thuật và so sánh kết quả.
Các vấn đề về ước tính
Thông thường, các nhà quản lý dự án sử dụng cách ước tính lịch trình bỏ qua để ước tính kích thước. Điều này có thể là do lịch trình do quản lý cao nhất hoặc nhóm tiếp thị đặt ra. Tuy nhiên, bất kể lý do là gì, nếu điều này được thực hiện, thì ở giai đoạn sau, rất khó để ước tính lịch trình để phù hợp với các thay đổi phạm vi.
Trong khi ước tính, một số giả định có thể được đưa ra. Điều quan trọng là phải ghi lại tất cả các giả định này trong bảng ước tính, vì một số vẫn không ghi các giả định trong bảng ước tính.
Ngay cả những ước tính tốt cũng có những giả định, rủi ro và sự không chắc chắn cố hữu, nhưng chúng thường được coi là chính xác.
Cách tốt nhất để thể hiện ước tính là một loạt các kết quả có thể xảy ra, chẳng hạn như nói rằng dự án sẽ mất từ 5 đến 7 tháng thay vì nói rằng nó sẽ hoàn thành vào một ngày cụ thể hoặc nó sẽ hoàn thành trong một số không cố định. trong tháng. Cẩn thận với việc cam kết một phạm vi quá hẹp vì điều đó tương đương với việc cam kết một ngày xác định.
Bạn cũng có thể bao gồm sự không chắc chắn như một giá trị xác suất đi kèm. Ví dụ, có 90% xác suất rằng dự án sẽ hoàn thành vào hoặc trước một ngày xác định.
Các tổ chức không thu thập dữ liệu dự án chính xác. Vì độ chính xác của các ước tính phụ thuộc vào dữ liệu lịch sử, nó sẽ là một vấn đề.
Đối với bất kỳ dự án nào, có một lịch trình ngắn nhất có thể cho phép bạn bao gồm các chức năng cần thiết và tạo ra đầu ra chất lượng. Nếu có ràng buộc về lịch trình bởi quản lý và / hoặc khách hàng, bạn có thể thương lượng về phạm vi và chức năng sẽ được phân phối.
Thống nhất với khách hàng về việc xử lý creep phạm vi để tránh vượt quá lịch trình.
Sự thất bại trong việc điều chỉnh dự phòng trong ước tính cuối cùng gây ra các vấn đề. Ví dụ, các cuộc họp, sự kiện tổ chức.
Việc sử dụng tài nguyên nên được coi là dưới 80%. Điều này là do các tài nguyên sẽ chỉ có hiệu quả trong 80% thời gian của chúng. Nếu bạn chỉ định tài nguyên ở mức sử dụng hơn 80%, chắc chắn sẽ có sự trượt giá.
Nguyên tắc ước tính
Người ta nên ghi nhớ các nguyên tắc sau trong khi ước tính một dự án -
Trong quá trình ước lượng, hãy hỏi kinh nghiệm của người khác. Ngoài ra, hãy đặt kinh nghiệm của riêng bạn vào công việc.
Giả sử rằng các nguồn lực sẽ chỉ có hiệu quả trong 80% thời gian của chúng. Do đó, trong quá trình ước tính, sử dụng tài nguyên dưới 80%.
Các tài nguyên làm việc trên nhiều dự án mất nhiều thời gian hơn để hoàn thành nhiệm vụ do mất thời gian chuyển đổi giữa chúng.
Bao gồm thời gian quản lý trong bất kỳ ước tính nào.
Luôn dự phòng cho việc giải quyết vấn đề, các cuộc họp và các sự kiện bất ngờ khác.
Dành đủ thời gian để ước tính dự án phù hợp. Các ước tính vội vàng là những ước tính không chính xác, có độ rủi ro cao. Đối với các dự án phát triển lớn, bước ước tính thực sự nên được coi như một dự án nhỏ.
Nếu có thể, hãy sử dụng dữ liệu được lập thành văn bản từ các dự án tương tự trong quá khứ của tổ chức bạn. Nó sẽ cho kết quả ước tính chính xác nhất. Nếu tổ chức của bạn không lưu giữ dữ liệu lịch sử, bây giờ là thời điểm tốt để bắt đầu thu thập dữ liệu đó.
Sử dụng ước tính dựa trên nhà phát triển, vì ước tính được chuẩn bị bởi những người khác với những người sẽ thực hiện công việc sẽ kém chính xác hơn.
Sử dụng nhiều người khác nhau để ước tính và sử dụng một số kỹ thuật ước tính khác nhau.
Đối chiếu các ước tính. Quan sát sự hội tụ hoặc lan truyền giữa các ước tính. Sự hội tụ có nghĩa là bạn đã có một ước tính tốt. Kỹ thuật Wideband-Delphi có thể được sử dụng để thu thập và thảo luận các ước tính bằng cách sử dụng một nhóm người, mục đích là tạo ra một ước tính chính xác, không thiên vị.
Ước tính lại dự án nhiều lần trong suốt vòng đời của nó.
A Function Point(FP) là một đơn vị đo lường để thể hiện số lượng chức năng kinh doanh mà một hệ thống thông tin (như một sản phẩm) cung cấp cho người dùng. FPs đo kích thước phần mềm. Chúng được chấp nhận rộng rãi như một tiêu chuẩn công nghiệp để định cỡ chức năng.
Đối với phần mềm định cỡ dựa trên FP, một số tiêu chuẩn được công nhận và / hoặc thông số kỹ thuật công khai đã ra đời. Tính đến năm 2013, đây là -
Tiêu chuẩn ISO
COSMIC- ISO / IEC 19761: 2011 Kỹ thuật phần mềm. Một phương pháp đo kích thước chức năng.
FiSMA - ISO / IEC 29881: 2008 Công nghệ thông tin - Kỹ thuật phần mềm và hệ thống - Phương pháp đo kích thước chức năng FiSMA 1.1.
IFPUG - ISO / IEC 20926: 2009 Kỹ thuật phần mềm và hệ thống - Đo lường phần mềm - Phương pháp đo kích thước chức năng IFPUG.
Mark-II - ISO / IEC 20968: 2002 Kỹ thuật phần mềm - Phân tích điểm chức năng Ml II - Sổ tay hướng dẫn thực hành đếm.
NESMA - ISO / IEC 24570: 2005 Kỹ thuật phần mềm - Phương pháp đo kích thước chức năng NESMA phiên bản 2.1 - Định nghĩa và hướng dẫn đếm để áp dụng Phân tích điểm chức năng.
Đặc tả nhóm quản lý đối tượng cho điểm chức năng tự động
Object Management Group (OMG), một thành viên mở và tập đoàn tiêu chuẩn ngành máy tính phi lợi nhuận, đã thông qua đặc điểm kỹ thuật Điểm chức năng tự động (AFP) do Hiệp hội Chất lượng Phần mềm CNTT dẫn đầu. Nó cung cấp một tiêu chuẩn để tự động đếm FP theo hướng dẫn của Nhóm người dùng điểm chức năng quốc tế (IFPUG).
Function Point Analysis (FPA) techniqueđịnh lượng các chức năng có trong phần mềm theo nghĩa có ý nghĩa đối với người sử dụng phần mềm. FP xem xét số lượng chức năng đang được phát triển dựa trên đặc điểm kỹ thuật yêu cầu.
Function Points (FP) Countingđược điều chỉnh bởi một bộ quy tắc, quy trình và hướng dẫn tiêu chuẩn được xác định bởi Nhóm người dùng điểm chức năng quốc tế (IFPUG). Chúng được xuất bản trong Sổ tay Hướng dẫn Thực hành Đếm (CPM).
Lịch sử của phân tích điểm hàm
Khái niệm về điểm chức năng được Alan Albrecht của IBM đưa ra vào năm 1979. Năm 1984, Albrecht đã cải tiến phương pháp này. Nguyên tắc Điểm Chức năng đầu tiên được xuất bản vào năm 1984. Nhóm Người dùng Điểm Chức năng Quốc tế (IFPUG) là một tổ chức toàn cầu có trụ sở tại Hoa Kỳ về những người sử dụng phần mềm phân tích số liệu Phân tích Điểm Chức năng. CácInternational Function Point Users Group (IFPUG)là một tổ chức phi lợi nhuận, do thành viên quản lý, được thành lập vào năm 1986. IFPUG sở hữu Phân tích điểm chức năng (FPA) như được định nghĩa trong tiêu chuẩn ISO 20296: 2009 chỉ rõ các định nghĩa, quy tắc và các bước áp dụng phương pháp đo lường kích thước chức năng (FSM) của IFPUG. IFPUG duy trì Sổ tay Hướng dẫn Thực hành Đếm Điểm Chức năng (CPM). CPM 2.0 được phát hành vào năm 1987 và kể từ đó đã có một số lần lặp lại. Bản phát hành CPM 4.3 vào năm 2010.
Bản phát hành CPM 4.3.1 với các sửa đổi biên tập ISO được kết hợp vào năm 2010. Tiêu chuẩn ISO (IFPUG FSM) - Đo lường kích thước chức năng là một phần của CPM 4.3.1 là một kỹ thuật để đo lường phần mềm về mặt chức năng mà nó cung cấp. CPM là tiêu chuẩn được quốc tế chấp thuận theo ISO / IEC 14143-1 Công nghệ thông tin - Đo lường phần mềm.
Quy trình cơ bản (EP)
Quy trình cơ bản là đơn vị nhỏ nhất của yêu cầu người dùng chức năng -
- Có ý nghĩa đối với người dùng.
- Tạo thành một giao dịch hoàn chỉnh.
- Là khép kín và để lại hoạt động kinh doanh của ứng dụng được tính ở trạng thái nhất quán.
Chức năng
Có hai loại chức năng -
- Chức năng dữ liệu
- Các chức năng giao dịch
Chức năng dữ liệu
Có hai loại hàm dữ liệu -
- Tệp logic nội bộ
- Tệp giao diện bên ngoài
Các Chức năng Dữ liệu được tạo thành từ các tài nguyên bên trong và bên ngoài có ảnh hưởng đến hệ thống.
Internal Logical Files
Tệp logic nội bộ (ILF) là một nhóm dữ liệu hoặc thông tin điều khiển liên quan đến logic có thể nhận dạng được người dùng nằm hoàn toàn trong ranh giới ứng dụng. Mục đích chính của ILF là giữ dữ liệu được duy trì thông qua một hoặc nhiều quy trình cơ bản của ứng dụng đang được tính. ILF có ý nghĩa vốn có là nó được duy trì nội bộ, nó có một số cấu trúc logic và nó được lưu trữ trong một tệp. (Tham khảo Hình 1)
External Interface Files
Tệp Giao diện Bên ngoài (EIF) là một nhóm dữ liệu hoặc thông tin điều khiển có liên quan đến logic có liên quan đến người dùng được ứng dụng sử dụng chỉ cho mục đích tham khảo. Dữ liệu nằm hoàn toàn bên ngoài ranh giới ứng dụng và được duy trì trong ILF bởi một ứng dụng khác. EIF có ý nghĩa cố hữu là nó được duy trì bên ngoài, một giao diện phải được phát triển để lấy dữ liệu từ tệp. (Tham khảo Hình 1)
Các chức năng giao dịch
Có ba loại chức năng giao dịch.
- Đầu vào bên ngoài
- Đầu ra bên ngoài
- Yêu cầu bên ngoài
Các chức năng giao dịch được tạo thành từ các quy trình được trao đổi giữa người dùng, các ứng dụng bên ngoài và ứng dụng được đo.
External Inputs
Đầu vào bên ngoài (EI) là một chức năng giao dịch trong đó Dữ liệu đi “vào” ứng dụng từ bên ngoài ranh giới vào bên trong. Dữ liệu này đến bên ngoài ứng dụng.
- Dữ liệu có thể đến từ màn hình nhập dữ liệu hoặc một ứng dụng khác.
- EI là cách một ứng dụng nhận được thông tin.
- Dữ liệu có thể là thông tin kiểm soát hoặc thông tin kinh doanh.
- Dữ liệu có thể được sử dụng để duy trì một hoặc nhiều Tệp Lôgic Nội bộ.
- Nếu dữ liệu là thông tin kiểm soát, nó không phải cập nhật Tệp lôgic nội bộ. (Tham khảo Hình 1)
External Outputs
Đầu ra bên ngoài (EO) là một chức năng giao dịch trong đó dữ liệu được “ra” khỏi hệ thống. Ngoài ra, EO có thể cập nhật ILF. Dữ liệu tạo ra các báo cáo hoặc các tệp xuất được gửi đến các ứng dụng khác. (Tham khảo Hình 1)
External Inquiries
Yêu cầu bên ngoài (EQ) là một chức năng giao dịch với cả hai thành phần đầu vào và đầu ra dẫn đến truy xuất dữ liệu. (Tham khảo Hình 1)
Định nghĩa RETs, DETs, FTRs
Loại phần tử ghi
Loại phần tử bản ghi (RET) là nhóm con lớn nhất có thể nhận dạng của người dùng trong một ILF hoặc EIF. Tốt nhất là xem xét các nhóm dữ liệu hợp lý để giúp xác định chúng.
Loại phần tử dữ liệu
Loại phần tử dữ liệu (DET) là nhóm con dữ liệu trong FTR. Chúng là duy nhất và người dùng có thể nhận dạng được.
Loại tệp được tham chiếu
Loại tệp được tham chiếu (FTR) là nhóm con có thể nhận dạng người dùng lớn nhất trong EI, EO hoặc EQ được tham chiếu đến.
Các hàm giao dịch EI, EO, EQ được đo bằng cách đếm FTR và DET mà chúng chứa các quy tắc đếm tuân theo. Tương tự như vậy, các hàm dữ liệu ILF và EIF được đo bằng cách đếm các DET và RET mà chúng chứa các quy tắc đếm tuân theo. Các phép đo của chức năng giao dịch và chức năng dữ liệu được sử dụng trong đếm FP, dẫn đến kích thước chức năng hoặc điểm chức năng.
Quy trình đếm FP bao gồm các bước sau:
Step 1 - Xác định kiểu đếm.
Step 2 - Xác định ranh giới của số đếm.
Step 3 - Xác định từng Quy trình Cơ bản (EP) theo yêu cầu của người dùng.
Step 4 - Xác định các EP duy nhất.
Step 5 - Đo lường các chức năng dữ liệu.
Step 6 - Đo lường các chức năng giao dịch.
Step 7 - Tính toán kích thước chức năng (đếm điểm chức năng chưa điều chỉnh).
Step 8 - Xác định Hệ số Điều chỉnh Giá trị (VAF).
Step 9 - Tính số điểm chức năng đã điều chỉnh.
Note- Đặc điểm hệ thống chung (GSC) được thực hiện tùy chọn trong CPM 4.3.1 và được chuyển sang Phụ lục. Do đó, có thể bỏ qua Bước 8 và Bước 9.
Bước 1: Xác định loại số lượng
Có ba loại đếm điểm chức năng -
- Đếm điểm chức năng phát triển
- Đếm điểm chức năng ứng dụng
- Đếm điểm chức năng nâng cao
Đếm điểm chức năng phát triển
Các điểm chức năng có thể được tính ở tất cả các giai đoạn của một dự án phát triển từ yêu cầu đến giai đoạn thực hiện. Loại số lượng này được liên kết với công việc phát triển mới và có thể bao gồm các nguyên mẫu, có thể được yêu cầu như một giải pháp tạm thời, hỗ trợ nỗ lực chuyển đổi. Loại đếm này được gọi là đếm điểm hàm cơ sở.
Đếm điểm chức năng ứng dụng
Số lượng ứng dụng được tính như các điểm chức năng được phân phối và loại trừ bất kỳ nỗ lực chuyển đổi nào (nguyên mẫu hoặc giải pháp tạm thời) và chức năng hiện có có thể đã tồn tại.
Đếm điểm chức năng nâng cao
Khi những thay đổi được thực hiện đối với phần mềm sau khi sản xuất, chúng được coi là những cải tiến. Để kích thước các dự án nâng cao như vậy, Số điểm chức năng được Thêm, Thay đổi hoặc Xóa trong Ứng dụng.
Bước 2: Xác định ranh giới của số đếm
Ranh giới cho biết biên giới giữa ứng dụng được đo và các ứng dụng bên ngoài hoặc miền người dùng. (Tham khảo Hình 1)
Để xác định ranh giới, hãy hiểu -
- Mục đích của chức năng đếm điểm
- Phạm vi ứng dụng được đo lường
- Làm thế nào và ứng dụng nào duy trì dữ liệu nào
- Các lĩnh vực kinh doanh hỗ trợ các ứng dụng
Bước 3: Xác định từng quy trình cơ bản do người dùng yêu cầu
Soạn và / hoặc phân tách các yêu cầu của người dùng chức năng thành đơn vị hoạt động nhỏ nhất, đáp ứng tất cả các tiêu chí sau:
- Có ý nghĩa đối với người dùng.
- Tạo thành một giao dịch hoàn chỉnh.
- Là khép kín.
- Để hoạt động kinh doanh của ứng dụng được tính ở trạng thái nhất quán.
Ví dụ: Yêu cầu của người dùng chức năng - “Duy trì thông tin nhân viên” có thể được phân tách thành các hoạt động nhỏ hơn như thêm nhân viên, thay đổi nhân viên, xóa nhân viên và hỏi về nhân viên.
Do đó, mỗi đơn vị hoạt động được xác định là một Quy trình Cơ bản (EP).
Bước 4: Xác định các quy trình cơ bản duy nhất
So sánh hai EP đã được xác định, tính chúng là một EP (cùng một EP) nếu chúng -
- Yêu cầu cùng một bộ DET.
- Yêu cầu cùng một bộ FTR.
- Yêu cầu cùng một bộ logic xử lý để hoàn thành EP.
Không chia một EP có nhiều dạng logic xử lý thành nhiều Eps.
Ví dụ: nếu bạn đã xác định 'Thêm nhân viên' là một EP, thì không nên chia nó thành hai EP để giải thích rằng một nhân viên có thể có hoặc không có người phụ thuộc. EP vẫn là 'Thêm nhân viên' và có sự thay đổi trong logic xử lý và DET để tính cho người phụ thuộc.
Bước 5: Đo lường các chức năng dữ liệu
Phân loại từng hàm dữ liệu dưới dạng ILF hoặc EIF.
Một hàm dữ liệu sẽ được phân loại là -
Tệp logic nội bộ (ILF), nếu nó được duy trì bởi ứng dụng đang được đo lường.
Tệp giao diện bên ngoài (EIF) nếu nó được tham chiếu, nhưng không được ứng dụng đo lường duy trì.
ILF và EIF có thể chứa dữ liệu kinh doanh, dữ liệu kiểm soát và dữ liệu dựa trên quy tắc. Ví dụ, chuyển mạch điện thoại được thực hiện bằng cả ba loại - dữ liệu kinh doanh, dữ liệu quy tắc và dữ liệu kiểm soát. Dữ liệu kinh doanh là cuộc gọi thực tế. Dữ liệu quy tắc là cách cuộc gọi nên được định tuyến qua mạng và dữ liệu điều khiển là cách các thiết bị chuyển mạch giao tiếp với nhau.
Hãy xem xét tài liệu sau để tính ILF và EIF -
- Mục tiêu và ràng buộc đối với hệ thống đề xuất.
- Tài liệu liên quan đến hệ thống hiện tại, nếu hệ thống như vậy tồn tại.
- Tài liệu về các mục tiêu, vấn đề và nhu cầu nhận thức của người dùng.
- Các mô hình dữ liệu.
Bước 5.1: Đếm số DET cho mỗi hàm dữ liệu
Áp dụng các quy tắc sau để tính DETs cho ILF / EIF -
Đếm một DET cho mỗi trường duy nhất có thể nhận dạng người dùng, không lặp lại được duy trì trong hoặc truy xuất từ ILF hoặc EIF thông qua việc thực thi EP.
Chỉ đếm những DET đang được sử dụng bởi ứng dụng được đo khi hai hoặc nhiều ứng dụng duy trì và / hoặc tham chiếu cùng một chức năng dữ liệu.
Đếm một DET cho mỗi thuộc tính do người dùng yêu cầu để thiết lập mối quan hệ với ILF hoặc EIF khác.
Xem lại các thuộc tính liên quan để xác định xem chúng được nhóm lại và được tính là một DET đơn lẻ hay chúng được tính là nhiều DET. Việc nhóm sẽ phụ thuộc vào cách các EP sử dụng các thuộc tính trong ứng dụng.
Bước 5.2: Đếm RET cho mỗi chức năng dữ liệu
Áp dụng các quy tắc sau để đếm RET cho ILF / EIF -
- Đếm một RET cho mỗi hàm dữ liệu.
- Đếm một RET bổ sung cho mỗi nhóm phụ logic bổ sung sau đây của DET.
- Thực thể liên kết với các thuộc tính không phải khóa.
- Loại phụ (khác với loại phụ đầu tiên).
- Thực thể thuộc tính, trong mối quan hệ không phải là 1: 1 bắt buộc.
Bước 5.3: Xác định độ phức tạp chức năng cho mỗi chức năng dữ liệu
| RETS | Các loại phần tử dữ liệu (DET) | ||
|---|---|---|---|
| 1-19 | 20-50 | >50 | |
| 1 | L | L | A |
| 2 đến 5 | L | A | H |
| > 5 | A | H | H |
Chức năng phức tạp: L = Thấp; A = Trung bình; H = Cao
Bước 5.4: Đo kích thước chức năng cho từng chức năng dữ liệu
| Chức năng phức tạp | Đếm FP cho ILF | Đếm FP cho EIF |
|---|---|---|
| Thấp | 7 | 5 |
| Trung bình cộng | 10 | 7 |
| Cao | 15 | 10 |
Bước 6: Đo lường các chức năng giao dịch
Để đo lường các chức năng giao dịch, sau đây là các bước cần thiết:
Bước 6.1: Phân loại từng chức năng giao dịch
Các chức năng giao dịch nên được phân loại thành Đầu vào bên ngoài, Đầu ra bên ngoài hoặc Yêu cầu bên ngoài.
Đầu vào bên ngoài
Đầu vào bên ngoài (EI) là một Quy trình cơ bản xử lý dữ liệu hoặc kiểm soát thông tin đến từ bên ngoài ranh giới. Mục đích chính của EI là duy trì một hoặc nhiều ILF và / hoặc để thay đổi hoạt động của hệ thống.
Tất cả các quy tắc sau phải được áp dụng:
Dữ liệu hoặc thông tin điều khiển được nhận từ bên ngoài ranh giới ứng dụng.
Ít nhất một ILF được duy trì nếu dữ liệu đi vào ranh giới không phải là thông tin kiểm soát làm thay đổi hành vi của hệ thống.
Đối với EP đã xác định, phải áp dụng một trong ba câu sau:
Logic xử lý là duy nhất so với logic xử lý được thực hiện bởi các EI khác cho ứng dụng.
Tập hợp các phần tử dữ liệu được xác định khác với các tập hợp được xác định cho các EI khác trong ứng dụng.
Các ILF hoặc EIF được tham chiếu khác với các tệp được tham chiếu bởi các EI khác trong ứng dụng.
Đầu ra bên ngoài
Đầu ra bên ngoài (EO) là một Quy trình cơ bản gửi dữ liệu hoặc thông tin điều khiển ra bên ngoài ranh giới của ứng dụng. EO bao gồm xử lý bổ sung ngoài quá trình điều tra bên ngoài.
Mục đích chính của EO là trình bày thông tin cho người dùng thông qua logic xử lý khác với hoặc ngoài việc truy xuất dữ liệu hoặc thông tin điều khiển.
Logic xử lý phải -
- Chứa ít nhất một công thức toán học hoặc phép tính.
- Tạo dữ liệu dẫn xuất.
- Duy trì một hoặc nhiều ILF.
- Thay đổi hành vi của hệ thống.
Tất cả các quy tắc sau phải được áp dụng:
- Gửi dữ liệu hoặc thông tin kiểm soát ra bên ngoài ranh giới của ứng dụng.
- Đối với EP đã xác định, phải áp dụng một trong ba câu sau:
- Logic xử lý là duy nhất so với logic xử lý được thực hiện bởi các EO khác cho ứng dụng.
- Tập hợp các phần tử dữ liệu được xác định khác với các EO khác trong ứng dụng.
- ILF hoặc EIF được tham chiếu khác với các tệp được tham chiếu bởi các EO khác trong ứng dụng.
Ngoài ra, phải áp dụng một trong các quy tắc sau:
- Logic xử lý chứa ít nhất một công thức toán học hoặc phép tính.
- Logic xử lý duy trì ít nhất một ILF.
- Logic xử lý làm thay đổi hành vi của hệ thống.
Yêu cầu bên ngoài
Yêu cầu bên ngoài (EQ) là một Quy trình cơ bản gửi dữ liệu hoặc thông tin kiểm soát ra bên ngoài ranh giới. Mục đích chính của EQ là trình bày thông tin cho người dùng thông qua việc truy xuất dữ liệu hoặc thông tin kiểm soát.
Logic xử lý không chứa công thức toán học hoặc phép tính và không tạo ra dữ liệu dẫn xuất. Không có ILF nào được duy trì trong quá trình xử lý, cũng như hành vi của hệ thống không bị thay đổi.
Tất cả các quy tắc sau phải được áp dụng:
- Gửi dữ liệu hoặc thông tin kiểm soát ra bên ngoài ranh giới của ứng dụng.
- Đối với EP đã xác định, phải áp dụng một trong ba câu sau:
- Logic xử lý là duy nhất so với logic xử lý được thực hiện bởi các EQ khác cho ứng dụng.
- Tập hợp các phần tử dữ liệu được xác định khác với các EQ khác trong ứng dụng.
- Các ILF hoặc EIF được tham chiếu khác với các tệp được tham chiếu bởi các EQ khác trong ứng dụng.
Ngoài ra, tất cả các quy tắc sau phải áp dụng:
- Logic xử lý lấy dữ liệu hoặc thông tin điều khiển từ ILF hoặc EIF.
- Logic xử lý không chứa công thức hoặc phép tính toán học.
- Logic xử lý không làm thay đổi hành vi của hệ thống.
- Logic xử lý không duy trì ILF.
Bước 6.2: Đếm số DET cho mỗi chức năng giao dịch
Áp dụng các Quy tắc sau để tính DETs cho EI -
Xem lại mọi thứ vượt qua (vào và / hoặc ra) ranh giới.
Đếm một DET cho mỗi thuộc tính nhận dạng người dùng duy nhất, không lặp lại vượt qua (nhập và / hoặc thoát) ranh giới trong quá trình xử lý chức năng giao dịch.
Chỉ đếm một DET cho mỗi chức năng giao dịch để có khả năng gửi tin nhắn phản hồi ứng dụng, ngay cả khi có nhiều tin nhắn.
Chỉ đếm một DET cho mỗi chức năng giao dịch để có khả năng bắt đầu (các) hành động ngay cả khi có nhiều phương tiện để làm như vậy.
Không tính các mục sau là DETs -
Các thuộc tính được tạo trong ranh giới bởi một chức năng giao dịch và được lưu vào ILF mà không cần thoát ra khỏi ranh giới.
Các chữ như tiêu đề báo cáo, số nhận dạng màn hình hoặc bảng điều khiển, tiêu đề cột và tiêu đề thuộc tính.
Ứng dụng tạo tem như thuộc tính ngày và giờ.
Các biến phân trang, số trang và thông tin định vị, ví dụ: 'Hàng 37 đến 54 trong tổng số 211'.
Hỗ trợ điều hướng chẳng hạn như khả năng điều hướng trong danh sách bằng cách sử dụng “trước”, “tiếp theo”, “đầu tiên”, “cuối cùng” và các tương đương đồ họa của chúng.
Áp dụng các quy tắc sau để tính DETs cho EO / EQ -
Xem lại mọi thứ vượt qua (vào và / hoặc ra) ranh giới.
Đếm một DET cho mỗi thuộc tính nhận dạng người dùng duy nhất, không lặp lại vượt qua (nhập và / hoặc thoát) ranh giới trong quá trình xử lý chức năng giao dịch.
Chỉ đếm một DET cho mỗi chức năng giao dịch để có khả năng gửi tin nhắn phản hồi ứng dụng, ngay cả khi có nhiều tin nhắn.
Chỉ đếm một DET cho mỗi chức năng giao dịch để có khả năng bắt đầu (các) hành động ngay cả khi có nhiều phương tiện để làm như vậy.
Không tính các mục sau là DETs -
Các thuộc tính được tạo trong ranh giới mà không vượt qua ranh giới.
Các chữ như tiêu đề báo cáo, số nhận dạng màn hình hoặc bảng điều khiển, tiêu đề cột và tiêu đề thuộc tính.
Ứng dụng tạo tem như thuộc tính ngày và giờ.
Các biến phân trang, số trang và thông tin định vị, ví dụ: 'Hàng 37 đến 54 trong tổng số 211'.
Hỗ trợ điều hướng chẳng hạn như khả năng điều hướng trong danh sách bằng cách sử dụng “trước”, “tiếp theo”, “đầu tiên”, “cuối cùng” và các tương đương đồ họa của chúng.
Bước 6.3: Đếm FTR cho mỗi chức năng giao dịch
Áp dụng các quy tắc sau để tính FTR cho EI -
- Đếm FTR cho mỗi ILF được duy trì.
- Đếm FTR cho mỗi ILF hoặc EIF được đọc trong quá trình xử lý EI.
- Chỉ đếm một FTR cho mỗi ILF được duy trì và đọc.
Áp dụng quy tắc sau để tính FTR cho EO / EQ -
- Đếm FTR cho mỗi ILF hoặc EIF được đọc trong quá trình xử lý EP.
Ngoài ra, hãy áp dụng các quy tắc sau để tính FTR cho EO -
- Đếm FTR cho mỗi ILF được duy trì trong quá trình xử lý EP.
- Chỉ đếm một FTR cho mỗi ILF được EP duy trì và đọc.
Bước 6.4: Xác định độ phức tạp chức năng cho từng chức năng giao dịch
| FTRs | Các loại phần tử dữ liệu (DET) | ||
|---|---|---|---|
| 1-4 | 5-15 | >=16 | |
| 0-1 | L | L | A |
| 2 | L | A | H |
| > = 3 | A | H | H |
Chức năng phức tạp: L = Thấp; A = Trung bình; H = Cao
Xác định độ phức tạp chức năng cho mỗi EO / EQ, ngoại trừ EQ phải có tối thiểu 1 FTR -
EQ phải có tối thiểu 1 FTR FTRs |
Các loại phần tử dữ liệu (DET) | ||
|---|---|---|---|
| 1-4 | 5-15 | > = 16 | |
| 0-1 | L | L | A |
| 2 | L | A | H |
| > = 3 | A | H | H |
Chức năng phức tạp: L = Thấp; A = Trung bình; H = Cao
Bước 6.5: Đo kích thước chức năng cho từng chức năng giao dịch
Đo kích thước chức năng cho mỗi EI từ độ phức tạp chức năng của nó.
| Phức tạp | Số lượng FP |
|---|---|
| Thấp | 3 |
| Trung bình cộng | 4 |
| Cao | 6 |
Đo kích thước chức năng cho mỗi EO / EQ từ độ phức tạp chức năng của nó.
| Phức tạp | Đếm FP cho EO | Đếm FP cho EQ |
|---|---|---|
| Thấp | 4 | 3 |
| Trung bình cộng | 5 | 4 |
| Cao | 6 | 6 |
Bước 7: Tính kích thước chức năng (Đếm điểm chức năng chưa điều chỉnh)
Để tính toán kích thước chức năng, bạn nên làm theo các bước dưới đây:
Bước 7.1
Nhớ lại những gì bạn đã tìm thấy trong Bước 1. Xác định loại số đếm.
Bước 7.2
Tính kích thước chức năng hoặc số điểm chức năng dựa trên loại.
- Để đếm điểm chức năng phát triển, hãy chuyển đến Bước 7.3.
- Để tính điểm chức năng ứng dụng, hãy chuyển đến Bước 7.4.
- Để đếm điểm chức năng nâng cao, hãy chuyển đến Bước 7.5.
Bước 7.3
Chức năng Phát triển Đếm điểm bao gồm hai thành phần của chức năng:
Chức năng ứng dụng có trong các yêu cầu của người dùng cho dự án.
Chức năng chuyển đổi bao gồm trong các yêu cầu của người dùng đối với dự án. Chức năng chuyển đổi bao gồm các chức năng chỉ được cung cấp khi cài đặt để chuyển đổi dữ liệu và / hoặc cung cấp các yêu cầu chuyển đổi khác do người dùng chỉ định, chẳng hạn như báo cáo chuyển đổi đặc biệt. Ví dụ: một ứng dụng hiện có có thể được thay thế bằng một hệ thống mới.
DFP = ADD + CFP
Ở đâu,
DFP = Số điểm chức năng phát triển
ADD = Kích thước của các chức năng do dự án phát triển cung cấp cho người dùng
CFP = Kích thước của chức năng chuyển đổi
ADD = Đếm FP (ILFs) + Đếm FP (EIFs) + Đếm FP (EIs) + Đếm FP (EO) + Đếm FP (EQs)
CFP = Đếm FP (ILFs) + Đếm FP (EIFs) + Đếm FP (EIs) + Đếm FP (EO) + Đếm FP (EQs)
Bước 7.4
Tính số điểm hàm ứng dụng
AFP = ADD
Ở đâu,
AFP = Số điểm chức năng ứng dụng
ADD = Kích thước của các chức năng do dự án phát triển cung cấp cho người dùng (không bao gồm kích thước của bất kỳ chức năng chuyển đổi nào) hoặc chức năng tồn tại bất cứ khi nào ứng dụng được tính.
ADD = Đếm FP (ILFs) + Đếm FP (EIFs) + Đếm FP (EIs) + Đếm FP (EO) + Đếm FP (EQs)
Bước 7.5
Đếm điểm chức năng nâng cao xem xét bốn thành phần sau của chức năng:
- Chức năng được thêm vào ứng dụng.
- Chức năng được sửa đổi trong Ứng dụng.
- Chức năng chuyển đổi.
- Chức năng bị xóa khỏi ứng dụng.
EFP = ADD + CHGA + CFP + DEL
Ở đâu,
EFP = Số điểm chức năng nâng cao
ADD = Kích thước của các chức năng được thêm vào bởi dự án nâng cao
CHGA = Kích thước của các chức năng được thay đổi bởi dự án nâng cao
CFP = Kích thước của chức năng chuyển đổi
DEL = Kích thước của các chức năng bị xóa bởi dự án nâng cao
ADD = Đếm FP (ILFs) + Đếm FP (EIFs) + Đếm FP (EIs) + Đếm FP (EO) + Đếm FP (EQs)
CHGA = Đếm FP (ILFs) + Đếm FP (EIFs) + Đếm FP (EIs) + Đếm FP (EO) + Đếm FP (EQs)
CFP = Đếm FP (ILFs) + Đếm FP (EIFs) + Đếm FP (EIs) + Đếm FP (EO) + Đếm FP (EQs)
DEL = Đếm FP (ILF) + Đếm FP (EIFs) + ĐẾM FP (EIs) + Đếm FP (EO) + Đếm FP (EQ)
Bước 8: Xác định yếu tố điều chỉnh giá trị
GSC được thực hiện tùy chọn trong CPM 4.3.1 và được chuyển sang Phụ lục. Do đó, có thể bỏ qua Bước 8 và Bước 9.
Hệ số điều chỉnh giá trị (VAF) dựa trên 14 GSC đánh giá chức năng chung của ứng dụng đang được tính. GSC là những ràng buộc kinh doanh của người dùng độc lập với công nghệ. Mỗi đặc điểm có các mô tả liên quan để xác định mức độ ảnh hưởng.
| Đặc điểm hệ thống chung | Mô tả ngắn gọn |
|---|---|
| Truyền thông dữ liệu | Có bao nhiêu phương tiện liên lạc để hỗ trợ việc chuyển giao hoặc trao đổi thông tin với ứng dụng hoặc hệ thống? |
| Xử lý dữ liệu phân tán | Dữ liệu phân tán và các chức năng xử lý được xử lý như thế nào? |
| Hiệu suất | Người dùng có yêu cầu thời gian phản hồi hoặc thông lượng không? |
| Cấu hình được sử dụng nhiều | Nền tảng phần cứng hiện tại được sử dụng nhiều đến mức nào, nơi ứng dụng sẽ được thực thi? |
| Tỷ lệ giao dịch | Tần suất các giao dịch được thực hiện hàng ngày, hàng tuần, hàng tháng, v.v.? |
| Nhập dữ liệu trực tuyến | Bao nhiêu phần trăm thông tin được nhập trực tuyến? |
| Hiệu quả của người dùng cuối | Ứng dụng có được thiết kế cho người dùng cuối hiệu quả không? |
| Cập nhật trực tuyến | Có bao nhiêu ILF được cập nhật bằng giao dịch trực tuyến? |
| Xử lý phức tạp | Ứng dụng có xử lý logic hoặc toán học mở rộng không? |
| Khả năng tái sử dụng | Ứng dụng có được phát triển để đáp ứng một hoặc nhiều nhu cầu của người dùng không? |
| Cài đặt dễ dàng | Chuyển đổi và cài đặt có khó không? |
| Hoạt động dễ dàng | Quy trình khởi động, sao lưu và phục hồi hiệu quả và / hoặc tự động như thế nào? |
| Nhiều trang web | Ứng dụng có được thiết kế, phát triển và hỗ trợ đặc biệt để được cài đặt tại nhiều trang web cho nhiều tổ chức không? |
| Tạo điều kiện thay đổi | Ứng dụng có được thiết kế, phát triển và hỗ trợ đặc biệt để tạo điều kiện thay đổi không? |
Mức độ ảnh hưởng theo thang điểm từ 0 đến 5, từ không ảnh hưởng đến ảnh hưởng mạnh.
| Xếp hạng | Mức độ ảnh hưởng |
|---|---|
| 0 | Không có mặt, hoặc không có ảnh hưởng |
| 1 | Ảnh hưởng ngẫu nhiên |
| 2 | Ảnh hưởng vừa phải |
| 3 | Ảnh hưởng trung bình |
| 4 | Ảnh hưởng đáng kể |
| 5 | Ảnh hưởng mạnh mẽ xuyên suốt |
Xác định mức độ ảnh hưởng của từng GSC.
Tổng các giá trị của 14 GSC thu được do đó được gọi là Tổng mức độ ảnh hưởng (TDI).
TDI = ∑14 Degrees of Influence
Tiếp theo, tính Hệ số điều chỉnh giá trị (VAF) như
VAF = (TDI × 0.01) + 0.65
Mỗi GSC có thể thay đổi từ 0 đến 5, TDI có thể thay đổi từ (0 × 14) đến (5 × 14), tức là 0 (khi tất cả các GSC đều ở mức thấp) đến 70 (khi tất cả các GSC đều ở mức cao) tức là 0 ≤ TDI ≤ 70. Do đó, VAF có thể thay đổi trong phạm vi từ 0,65 (khi tất cả các GSC đều thấp) đến 1,35 (khi tất cả các GSC đều cao), tức là 0,65 ≤ VAF ≤ 1,35.
Bước 9: Tính số điểm chức năng đã điều chỉnh
Theo cách tiếp cận FPA sử dụng VAF (các phiên bản CPM trước V4.3.1), điều này được xác định bởi,
Adjusted FP Count = Unadjusted FP Count × VAF
Trong đó, số lượng FP chưa điều chỉnh là kích thước chức năng mà bạn đã tính toán ở Bước 7.
Vì VAF có thể thay đổi từ 0,65 đến 1,35, VAF có ảnh hưởng ± 35% đến số FP được điều chỉnh cuối cùng.
Lợi ích của các điểm chức năng
Các điểm chức năng rất hữu ích -
Trong đo kích thước của giải pháp thay vì kích thước của vấn đề.
Vì yêu cầu là thứ duy nhất cần thiết để đếm điểm chức năng.
Vì nó độc lập với công nghệ.
Vì nó độc lập với ngôn ngữ lập trình.
Trong dự toán các dự án thử nghiệm.
Trong việc ước tính chi phí dự án tổng thể, tiến độ và nỗ lực.
Trong đàm phán hợp đồng vì nó cung cấp một phương pháp giao tiếp dễ dàng hơn với các nhóm kinh doanh.
Vì nó định lượng và gán giá trị cho các mục đích sử dụng thực tế, giao diện và mục đích của các chức năng trong phần mềm.
Trong việc tạo tỷ lệ với các số liệu khác như giờ, chi phí, số lượng nhân viên, thời lượng và các số liệu ứng dụng khác.
Kho lưu trữ FP
Nhóm tiêu chuẩn đo điểm chuẩn phần mềm quốc tế (ISBSG) phát triển và duy trì hai kho lưu trữ dữ liệu CNTT.
- Các dự án phát triển và nâng cao
- Ứng dụng Bảo trì và Hỗ trợ
Có hơn 6.000 dự án trong kho Dự án Phát triển và Nâng cao.
Dữ liệu được phân phối ở định dạng Microsoft Excel, giúp bạn dễ dàng phân tích sâu hơn mà bạn muốn thực hiện với nó hoặc thậm chí bạn có thể sử dụng dữ liệu cho một số mục đích khác.
Bạn có thể mua giấy phép kho lưu trữ ISBSG từ: http://www.isbsg.com/
ISBSG giảm giá 10% cho các thành viên IFPUG khi mua hàng trực tuyến khi sử dụng mã giảm giá “IFPUGMembers”.
Các bản cập nhật Phát hành Dữ liệu Dự án Phần mềm ISBSG có thể được tìm thấy tại: http://www.ifpug.org/isbsg/
COSMIC và IFPUG đã hợp tác để đưa ra Bảng chú giải thuật ngữ cho phần mềm Phi chức năng và Yêu cầu của dự án. Nó có thể được tải xuống từ - cosmic-sizing.org
A Use-Case là một loạt các tương tác có liên quan giữa người dùng và hệ thống cho phép người dùng đạt được mục tiêu.
Use-Case là một cách để nắm bắt các yêu cầu chức năng của hệ thống. Người dùng của hệ thống được gọi là 'Tác nhân'. Use-Case về cơ bản ở dạng văn bản.
Điểm Use-Case - Định nghĩa
Use-Case Points (UCP)là một kỹ thuật ước lượng phần mềm được sử dụng để đo kích thước phần mềm với các ca sử dụng. Khái niệm về UCP tương tự như FP.
Số lượng UCP trong một dự án dựa trên những điều sau:
- Số lượng và độ phức tạp của các ca sử dụng trong hệ thống.
- Số lượng và độ phức tạp của các tác nhân trên hệ thống.
Các yêu cầu phi chức năng khác nhau (chẳng hạn như tính di động, hiệu suất, khả năng bảo trì) không được viết dưới dạng ca sử dụng.
Môi trường mà dự án sẽ được phát triển (chẳng hạn như ngôn ngữ, động lực của nhóm, v.v.)
Ước tính với UCP yêu cầu tất cả các trường hợp sử dụng phải được viết với một mục tiêu và ở cùng một mức độ, cung cấp cùng một lượng chi tiết. Do đó, trước khi ước tính, nhóm dự án nên đảm bảo rằng họ đã viết các trường hợp sử dụng của mình với các mục tiêu xác định và ở mức chi tiết. Ca sử dụng thường được hoàn thành trong một phiên duy nhất và sau khi đạt được mục tiêu, người dùng có thể tiếp tục một số hoạt động khác.
Lịch sử của các điểm trường hợp sử dụng
Phương pháp ước lượng Use-Case Point được giới thiệu bởi Gustav Karner vào năm 1993. Công việc này sau đó đã được cấp phép bởi Rational Software đã sáp nhập vào IBM.
Quy trình đếm điểm Use-Case
Quy trình đếm điểm Use-Case có các bước sau:
- Tính toán UCP chưa điều chỉnh
- Điều chỉnh độ phức tạp kỹ thuật
- Điều chỉnh cho sự phức tạp của môi trường
- Tính toán UCP đã điều chỉnh
Bước 1: Tính điểm Use-Case chưa điều chỉnh.
Trước tiên, bạn tính Điểm trường hợp sử dụng chưa điều chỉnh bằng các bước sau:
- Xác định trọng lượng ca sử dụng chưa được điều chỉnh
- Xác định trọng lượng diễn viên chưa điều chỉnh
- Tính điểm trường hợp sử dụng chưa điều chỉnh
Step 1.1 - Xác định Trọng lượng Ca sử dụng Chưa điều chỉnh.
Step 1.1.1 - Tìm số lượng giao dịch trong mỗi Use-Case.
Nếu Use-Case được viết với Mức mục tiêu của người dùng, thì một giao dịch tương đương với một bước trong Use-Case. Tìm số lượng giao dịch bằng cách đếm các bước trong Ca sử dụng.
Step 1.1.2- Phân loại từng Use-Case là Đơn giản, Trung bình hoặc Phức tạp dựa trên số lượng giao dịch trong Use-Case. Ngoài ra, chỉ định Trọng lượng ca sử dụng như được hiển thị trong bảng sau:
| Độ phức tạp của ca sử dụng | Số lượng giao dịch | Trọng lượng ca sử dụng |
|---|---|---|
| Đơn giản | ≤3 | 5 |
| Trung bình cộng | 4 đến 7 | 10 |
| Phức tạp | > 7 | 15 |
Step 1.1.3- Lặp lại cho mỗi Use-Case và lấy tất cả Trọng lượng của Use-Case. Trọng lượng ca sử dụng chưa điều chỉnh (UUCW) là tổng của tất cả các trọng lượng ca sử dụng.
Step 1.1.4 - Tìm Trọng lượng ca sử dụng chưa điều chỉnh (UUCW) bằng bảng sau -
| Độ phức tạp của ca sử dụng | Trọng lượng ca sử dụng | Số ca sử dụng | Sản phẩm |
|---|---|---|---|
| Đơn giản | 5 | NSUC | 5 × NSUC |
| Trung bình cộng | 10 | NAUC | 10 × NAUC |
| Phức tạp | 15 | NCUC | 15 × NCUC |
| Unadjusted Use-Case Weight (UUCW) | 5 × NSUC + 10 × NAUC + 15 × NCUC | ||
Ở đâu,
NSUC là không. các Trường hợp Sử dụng Đơn giản.
NAUC là không. của Trường hợp Sử dụng Trung bình.
NCUC là không. trong các trường hợp sử dụng phức tạp.
Step 1.2 - Xác định trọng lượng diễn viên chưa điều chỉnh.
Tác nhân trong Ca sử dụng có thể là một người, chương trình khác, v.v. Một số tác nhân, chẳng hạn như hệ thống có API xác định, có nhu cầu rất đơn giản và chỉ làm tăng độ phức tạp của Ca sử dụng lên một chút.
Một số tác nhân, chẳng hạn như hệ thống tương tác thông qua một giao thức có nhiều nhu cầu hơn và tăng độ phức tạp của Use-Case đến một mức độ nhất định.
Các Tác nhân khác, chẳng hạn như người dùng tương tác thông qua GUI có tác động đáng kể đến độ phức tạp của Use-Case. Dựa trên những khác biệt này, bạn có thể phân loại các tác nhân là Đơn giản, Trung bình và Phức tạp.
Step 1.2.1 - Phân loại các Tác nhân là Đơn giản, Trung bình và Phức tạp và chỉ định Trọng số Tác nhân như được hiển thị trong bảng sau -
| Diễn viên phức tạp | Thí dụ | Trọng lượng diễn viên |
|---|---|---|
| Đơn giản | Hệ thống có API xác định | 1 |
| Trung bình cộng | Một hệ thống tương tác thông qua một giao thức | 2 |
| Phức tạp | Người dùng tương tác thông qua GUI | 3 |
Step 1.2.2- Lặp lại cho mỗi Diễn viên và nhận tất cả Trọng lượng Diễn viên. Trọng lượng diễn viên chưa điều chỉnh (UAW) là tổng của tất cả Trọng lượng diễn viên.
Step 1.2.3 - Tìm Trọng lượng diễn viên chưa điều chỉnh (UAW) bằng bảng sau:
| Diễn viên phức tạp | Trọng lượng diễn viên | Số lượng diễn viên | Sản phẩm |
|---|---|---|---|
| Đơn giản | 1 | NSA | 1 × NSA |
| Trung bình cộng | 2 | NAA | 2 × NAA |
| Phức tạp | 3 | NCA | 3 × NCA |
| Unadjusted Actor Weight (UAW) | 1 × NSA + 2 × NAA + 3 × NCA | ||
Ở đâu,
NSA là không. của Diễn viên Đơn giản.
NAA là không. của Diễn viên Trung bình.
NCA là không. của Diễn viên phức tạp.
Step 1.3 - Tính điểm Use-Case chưa điều chỉnh.
Trọng lượng ca sử dụng chưa điều chỉnh (UUCW) và trọng lượng tác nhân chưa điều chỉnh (UAW) cùng nhau tạo ra kích thước chưa điều chỉnh của hệ thống, được gọi là Điểm ca sử dụng chưa điều chỉnh.
Unadjusted Use-Case Points (UUCP) = UUCW + UAW
Các bước tiếp theo là điều chỉnh Điểm trường hợp sử dụng chưa được điều chỉnh (UUCP) đối với Độ phức tạp về kỹ thuật và Độ phức tạp về môi trường.
Bước 2: Điều chỉnh độ phức tạp kỹ thuật
Step 2.1 - Xem xét 13 Yếu tố góp phần vào tác động của Độ phức tạp Kỹ thuật của một dự án đối với các Điểm tình huống sử dụng và Trọng số tương ứng của chúng như được cho trong bảng sau -
| Hệ số | Sự miêu tả | Cân nặng |
|---|---|---|
| T1 | Hệ thống phân phối | 2.0 |
| T2 | Thời gian đáp ứng hoặc mục tiêu hiệu suất thông lượng | 1,0 |
| T3 | Hiệu quả người dùng cuối | 1,0 |
| T4 | Xử lý nội bộ phức tạp | 1,0 |
| T5 | Mã phải được sử dụng lại | 1,0 |
| T6 | Dễ dàng để cài đặt | .5 |
| T7 | Dễ sử dụng | .5 |
| T8 | Xách tay | 2.0 |
| T9 | Dễ dàng thay đổi | 1,0 |
| T10 | Đồng thời | 1,0 |
| T11 | Bao gồm các mục tiêu bảo mật đặc biệt | 1,0 |
| T12 | Cung cấp quyền truy cập trực tiếp cho các bên thứ ba | 1,0 |
| T13 | Cần có các cơ sở đào tạo người dùng đặc biệt | 1,0 |
Nhiều yếu tố trong số này thể hiện các yêu cầu phi chức năng của dự án.
Step 2.2 - Đối với mỗi yếu tố trong số 13 Yếu tố, đánh giá dự án và xếp hạng từ 0 (không liên quan) đến 5 (rất quan trọng).
Step 2.3 - Tính toán Tác động của Yếu tố từ Trọng số Tác động của Yếu tố và Giá trị Đánh giá cho dự án như
Impact of the Factor = Impact Weight × Rated Value
Step (2.4)- Tính tổng Tác động của tất cả các Yếu tố. Điều này cho biết Hệ số kỹ thuật tổng (TFactor) như được cho trong bảng dưới đây -
| Hệ số | Sự miêu tả | Trọng lượng (W) | Giá trị định mức (0 đến 5) (RV) | Tác động (I = W × RV) |
|---|---|---|---|---|
| T1 | Hệ thống phân phối | 2.0 | ||
| T2 | Thời gian đáp ứng hoặc mục tiêu hiệu suất thông lượng | 1,0 | ||
| T3 | Hiệu quả người dùng cuối | 1,0 | ||
| T4 | Xử lý nội bộ phức tạp | 1,0 | ||
| T5 | Mã phải được sử dụng lại | 1,0 | ||
| T6 | Dễ dàng để cài đặt | .5 | ||
| T7 | Dễ sử dụng | .5 | ||
| T8 | Xách tay | 2.0 | ||
| T9 | Dễ dàng thay đổi | 1,0 | ||
| T10 | Đồng thời | 1,0 | ||
| T11 | Bao gồm các mục tiêu bảo mật đặc biệt | 1,0 | ||
| T12 | Cung cấp quyền truy cập trực tiếp cho các bên thứ ba | 1,0 | ||
| T13 | Cần có các cơ sở đào tạo người dùng đặc biệt | 1,0 | ||
| Total Technical Factor (TFactor) | ||||
Step 2.5 - Tính Hệ số phức tạp kỹ thuật (TCF) là -
TCF = 0.6 + (0.01 × TFactor)
Bước 3: Điều chỉnh độ phức tạp của môi trường
Step 3.1 - Xem xét 8 Yếu tố Môi trường có thể ảnh hưởng đến việc thực hiện dự án và Trọng số tương ứng của chúng như được cho trong bảng sau -
| Hệ số | Sự miêu tả | Cân nặng |
|---|---|---|
| F1 | Quen thuộc với mô hình dự án được sử dụng | 1,5 |
| F2 | Kinh nghiệm ứng dụng | .5 |
| F3 | Trải nghiệm hướng đối tượng | 1,0 |
| F4 | Năng lực của nhà phân tích chính | .5 |
| F5 | Động lực | 1,0 |
| F6 | Yêu cầu ổn định | 2.0 |
| F7 | Nhân viên bán thời gian | -1.0 |
| F8 | Ngôn ngữ lập trình khó | -1.0 |
Step 3.2 - Đối với mỗi 8 Yếu tố, hãy đánh giá dự án và xếp hạng từ 0 (không liên quan) đến 5 (rất quan trọng).
Step 3.3 - Tính toán Tác động của Yếu tố từ Trọng số Tác động của Yếu tố và Giá trị Đánh giá cho dự án như
Impact of the Factor = Impact Weight × Rated Value
Step 3.4- Tính tổng Tác động của tất cả các Yếu tố. Điều này cho biết Hệ số Môi trường Tổng (EFactor) như được cho trong bảng sau:
| Hệ số | Sự miêu tả | Trọng lượng (W) | Giá trị định mức (0 đến 5) (RV) | Tác động (I = W × RV) |
|---|---|---|---|---|
| F1 | Quen thuộc với mô hình dự án được sử dụng | 1,5 | ||
| F2 | Kinh nghiệm ứng dụng | .5 | ||
| F3 | Trải nghiệm hướng đối tượng | 1,0 | ||
| F4 | Năng lực của nhà phân tích chính | .5 | ||
| F5 | Động lực | 1,0 | ||
| F6 | Yêu cầu ổn định | 2.0 | ||
| F7 | Nhân viên bán thời gian | -1.0 | ||
| F8 | Ngôn ngữ lập trình khó | -1.0 | ||
| Total Environment Factor (EFactor) | ||||
Step 3.5 - Tính Hệ số Môi trường (EF) là -
1.4 + (-0.03 × EFactor)
Bước 4: Tính điểm trường hợp sử dụng được điều chỉnh (UCP)
Tính điểm trường hợp sử dụng được điều chỉnh (UCP) dưới dạng:
UCP = UUCP × TCF × EF
Ưu điểm và nhược điểm của điểm Use-Case
Ưu điểm của điểm Use-Case
UCP dựa trên các trường hợp sử dụng và có thể được đo lường rất sớm trong vòng đời của dự án.
UCP (ước tính quy mô) sẽ độc lập với quy mô, kỹ năng và kinh nghiệm của nhóm thực hiện dự án.
Ước tính dựa trên UCP được cho là gần với thực tế khi ước tính được thực hiện bởi những người có kinh nghiệm.
UCP dễ sử dụng và không yêu cầu phân tích bổ sung.
Các ca sử dụng đang được sử dụng rộng rãi như một phương pháp được lựa chọn để mô tả các yêu cầu. Trong những trường hợp như vậy, UCP là kỹ thuật ước lượng phù hợp nhất.
Nhược điểm của điểm Use-Case
UCP chỉ có thể được sử dụng khi các yêu cầu được viết dưới dạng các ca sử dụng.
Phụ thuộc vào các trường hợp sử dụng có định hướng mục tiêu, được viết tốt. Nếu các trường hợp sử dụng không được cấu trúc tốt hoặc không thống nhất, UCP kết quả có thể không chính xác.
Các yếu tố kỹ thuật và môi trường có tác động cao đến UCP. Cần phải cẩn thận trong khi ấn định các giá trị cho các yếu tố kỹ thuật và môi trường.
UCP hữu ích để ước tính ban đầu về quy mô tổng thể của dự án nhưng chúng ít hữu ích hơn nhiều trong việc thúc đẩy công việc lặp đi lặp lại của một nhóm.
Delphi Methodlà một kỹ thuật truyền thông có cấu trúc, ban đầu được phát triển như một phương pháp dự báo tương tác, có hệ thống dựa vào một nhóm chuyên gia. Các chuyên gia trả lời bảng câu hỏi trong hai hoặc nhiều vòng. Sau mỗi vòng, điều hành viên cung cấp một bản tóm tắt ẩn danh về các dự báo của các chuyên gia từ vòng trước với lý do đưa ra các nhận định của họ. Sau đó, các chuyên gia được khuyến khích sửa đổi câu trả lời trước đó của họ dựa trên câu trả lời của các thành viên khác trong hội đồng.
Người ta tin rằng trong quá trình này, phạm vi câu trả lời sẽ giảm xuống và nhóm sẽ hội tụ về câu trả lời "đúng". Cuối cùng, quá trình được dừng lại sau khi một tiêu chí dừng được xác định trước (ví dụ: số vòng, đạt được sự đồng thuận và tính ổn định của kết quả) và điểm trung bình hoặc điểm trung bình của các vòng cuối cùng xác định kết quả.
Phương pháp Delphi được phát triển vào những năm 1950-1960 tại RAND Corporation.
Kỹ thuật băng rộng Delphi
Vào những năm 1970, Barry Boehm và John A. Farquhar đã tạo ra Biến thể băng rộng của phương pháp Delphi. Thuật ngữ "băng rộng" được sử dụng bởi vì, so với Phương pháp Delphi, Kỹ thuật Delphi băng rộng liên quan đến sự tương tác lớn hơn và giao tiếp nhiều hơn giữa những người tham gia.
Trong Kỹ thuật Wideband Delphi, nhóm ước tính bao gồm người quản lý dự án, người điều hành, các chuyên gia và đại diện từ nhóm phát triển, tạo thành một nhóm 3-7 thành viên. Có hai cuộc họp -
- Cuộc họp khởi động
- Cuộc họp ước tính
Kỹ thuật băng rộng Delphi - Các bước
Step 1 - Chọn nhóm Dự toán và một người kiểm duyệt.
Step 2- Người điều hành tiến hành cuộc họp khởi động, trong đó nhóm được trình bày với đặc tả vấn đề và danh sách nhiệm vụ cấp cao, bất kỳ giả định hoặc ràng buộc nào của dự án. Nhóm thảo luận về vấn đề và các vấn đề ước tính, nếu có. Họ cũng quyết định các đơn vị ước tính. Người điều hành hướng dẫn toàn bộ cuộc thảo luận, theo dõi thời gian và sau cuộc họp khởi động, chuẩn bị một tài liệu có cấu trúc chứa đặc tả vấn đề, danh sách nhiệm vụ cấp cao, các giả định và đơn vị ước tính được quyết định. Sau đó, anh ta chuyển tiếp các bản sao của tài liệu này cho bước tiếp theo.
Step 3 - Mỗi thành viên trong nhóm Ước tính sau đó tạo riêng một WBS chi tiết, ước tính từng nhiệm vụ trong WBS và ghi lại các giả định đã thực hiện.
Step 4- Người điều hành gọi cho nhóm Dự toán để họp Dự toán. Nếu bất kỳ thành viên nào trong nhóm Ước tính trả lời rằng các ước tính chưa sẵn sàng, người điều hành sẽ cho thêm thời gian và gửi lại Thư mời họp.
Step 5 - Toàn bộ nhóm Dự toán tập hợp cho cuộc họp dự toán.
Step 5.1 - Khi bắt đầu cuộc họp Ước tính, người điều hành thu thập các ước tính ban đầu từ mỗi thành viên trong nhóm.
Step 5.2- Sau đó, anh ta vẽ một biểu đồ trên bảng trắng. Anh ta vẽ sơ đồ tổng dự án của mỗi thành viên dưới dạng X trên dòng Vòng 1, mà không tiết lộ tên tương ứng. Nhóm Ước tính có được ý tưởng về phạm vi ước tính, ban đầu có thể lớn.
Step 5.3- Mỗi thành viên trong nhóm đọc to danh sách nhiệm vụ chi tiết mà họ đã thực hiện, xác định bất kỳ giả định nào được đưa ra và đưa ra bất kỳ câu hỏi hoặc vấn đề nào. Các ước tính nhiệm vụ không được tiết lộ.
Danh sách nhiệm vụ chi tiết riêng lẻ góp phần tạo nên danh sách nhiệm vụ hoàn chỉnh hơn khi được kết hợp.
Step 5.4 - Sau đó, nhóm thảo luận về bất kỳ nghi ngờ / vấn đề nào mà họ có về nhiệm vụ mà họ đã đến, các giả định đã đặt ra và các vấn đề ước tính.
Step 5.5- Mỗi thành viên trong nhóm sau đó xem lại danh sách nhiệm vụ và các giả định của mình, và thực hiện các thay đổi nếu cần thiết. Các ước tính nhiệm vụ cũng có thể yêu cầu các điều chỉnh dựa trên cuộc thảo luận, được ghi chú là + N Giờ. để nỗ lực nhiều hơn và –N Giờ. cho ít nỗ lực hơn.
Sau đó, các thành viên trong nhóm kết hợp các thay đổi trong ước tính nhiệm vụ để đi đến ước tính tổng dự án.
Step 5.6 - Người điều hành thu thập các ước tính đã thay đổi từ tất cả các thành viên trong nhóm và vẽ chúng trên dòng Vòng 2.
Trong vòng này, phạm vi sẽ hẹp hơn so với vòng trước, vì nó dựa trên sự đồng thuận nhiều hơn.
Step 5.7 - Sau đó, nhóm thảo luận về các sửa đổi nhiệm vụ mà họ đã thực hiện và các giả định.
Step 5.8- Mỗi thành viên trong nhóm sau đó xem lại danh sách nhiệm vụ và các giả định của mình, và thực hiện các thay đổi nếu cần thiết. Các ước tính nhiệm vụ cũng có thể yêu cầu điều chỉnh dựa trên cuộc thảo luận.
Các thành viên trong nhóm sau đó một lần nữa kết hợp các thay đổi trong ước tính nhiệm vụ để đưa ra tổng dự toán dự án.
Step 5.9 - Người điều hành thu thập lại các ước tính đã thay đổi từ tất cả các thành viên và vẽ chúng trên dòng Vòng 3.
Một lần nữa, ở vòng này, phạm vi sẽ hẹp hơn so với vòng trước.
Step 5.10 - Lặp lại các bước 5.7, 5.8, 5.9 cho đến khi đáp ứng một trong các tiêu chí sau:
- Kết quả được hội tụ trong một phạm vi hẹp có thể chấp nhận được.
- Tất cả các thành viên trong nhóm không muốn thay đổi ước tính mới nhất của họ.
- Thời gian họp Ước tính được phân bổ đã kết thúc.
Step 6 - Người quản lý dự án sau đó tập hợp các kết quả từ cuộc họp Dự toán.
Step 6.1 - Anh ta biên soạn các danh sách nhiệm vụ riêng lẻ và các ước tính tương ứng thành một danh sách nhiệm vụ chính duy nhất.
Step 6.2 - Ông cũng kết hợp danh sách các giả định riêng lẻ.
Step 6.3 - Sau đó anh ta xem xét danh sách nhiệm vụ cuối cùng với nhóm Ước tính.
Ưu điểm và nhược điểm của kỹ thuật băng rộng Delphi
Ưu điểm
- Kỹ thuật Wideband Delphi là một kỹ thuật ước tính dựa trên sự đồng thuận để ước tính nỗ lực.
- Hữu ích khi ước tính thời gian để thực hiện một nhiệm vụ.
- Sự tham gia của những người có kinh nghiệm và họ ước tính riêng lẻ sẽ dẫn đến kết quả đáng tin cậy.
- Những người sẽ thực hiện công việc đang lập các ước tính do đó đưa ra các ước tính hợp lệ.
- Tính ẩn danh được duy trì xuyên suốt giúp mọi người có thể tự tin bày tỏ kết quả của mình.
- Một kỹ thuật rất đơn giản.
- Các giả định được lập thành văn bản, thảo luận và thống nhất.
Nhược điểm
- Hỗ trợ quản lý là bắt buộc.
- Kết quả ước tính có thể không phải là những gì ban quản lý muốn nghe.
Ước tính ba điểm xem xét ba giá trị -
- ước tính lạc quan nhất (O),
- một ước tính có nhiều khả năng nhất (M) và
- một ước tính bi quan (ước tính ít khả năng nhất (L)).
Đã có một số nhầm lẫn liên quan đến Ước tính Ba điểm và PERT trong ngành. Tuy nhiên, các kỹ thuật là khác nhau. Bạn sẽ thấy sự khác biệt khi học hai kỹ thuật. Ngoài ra, vào cuối kỹ thuật PERT, sự khác biệt được đối chiếu và trình bày. Nếu bạn muốn nhìn vào chúng trước tiên, bạn có thể.
Ước lượng ba điểm (E) dựa trên giá trị trung bình đơn giản và tuân theo phân phối tam giác.
E = (O + M + L) / 3
Độ lệch chuẩn
Trong phân phối tam giác,
Trung bình = (O + M + L) / 3
Độ lệch chuẩn = √ [((O - E) 2 + (M - E) 2 + (L - E) 2 ) / 2]
Các bước ước tính ba điểm
Step 1 - Đến WBS.
Step 2 - Đối với mỗi nhiệm vụ, hãy tìm ba giá trị - ước tính lạc quan nhất (O), ước tính có khả năng xảy ra nhất (M) và ước tính bi quan (L).
Step 3 - Tính giá trị trung bình của ba giá trị.
Mean = (O + M + L) / 3
Step 4- Tính Ước tính Ba điểm của nhiệm vụ. Ước tính ba điểm là giá trị trung bình. Vì thế,
E = Mean = (O + M + L) / 3
Step 5 - Tính độ lệch chuẩn của nguyên công.
Standard Deviation (SD) = √ [((O − E)2 + (M − E)2 + (L - E)2)/2]
Step 6 - Lặp lại các Bước 2, 3, 4 cho tất cả các Nhiệm vụ trong WBS.
Step 7 - Tính Ước lượng Ba điểm của dự án.
E (Project) = ∑ E (Task)
Step 8 - Tính độ lệch chuẩn của dự án.
SD (Project) = √ (∑SD (Task)2)
Chuyển đổi Dự toán Dự án sang Mức độ Tin cậy
Do đó, Ước tính Ba điểm (E) và Độ lệch Chuẩn (SD) được tính toán được sử dụng để chuyển các ước tính của dự án thành “Mức độ tin cậy”.
Việc chuyển đổi dựa trên cơ sở đó -
- Mức độ tin cậy trong E +/– SD là khoảng 68%.
- Mức độ tin cậy trong giá trị E +/– 1.645 × SD là khoảng 90%.
- Mức độ tin cậy trong giá trị E +/– 2 × SD là khoảng 95%.
- Mức độ tin cậy trong giá trị E +/– 3 × SD là khoảng 99,7%.
Thông thường, Mức độ tin cậy 95%, tức là Giá trị E + 2 × SD, được sử dụng cho tất cả các ước tính dự án và nhiệm vụ.
Kỹ thuật đánh giá và xem xét dự án (PERT) xem xét ba giá trị: ước tính lạc quan nhất (O), ước tính có khả năng xảy ra cao nhất (M) và ước tính bi quan (ước tính ít khả năng nhất (L)). Đã có một số nhầm lẫn liên quan đến Ước tính Ba điểm và PERT trong Ngành. Tuy nhiên, các kỹ thuật là khác nhau. Bạn sẽ thấy sự khác biệt khi học hai kỹ thuật. Ngoài ra, ở cuối chương này, sự khác biệt được đối chiếu và trình bày.
PERT dựa trên ba giá trị - ước tính lạc quan nhất (O), ước tính có khả năng xảy ra cao nhất (M) và ước tính bi quan (ước tính ít khả năng nhất (L)). Ước tính có khả năng xảy ra nhất có trọng số gấp 4 lần so với hai ước tính còn lại (lạc quan và bi quan).
Ước lượng PERT (E) dựa trên giá trị trung bình có trọng số và tuân theo phân phối beta.
E = (O + 4 × M + L)/6
PERT thường được sử dụng cùng với Phương pháp Đường dẫn Tới hạn (CPM). CPM cho biết về các nhiệm vụ quan trọng trong dự án. Nếu có sự chậm trễ trong các nhiệm vụ này, dự án sẽ bị trì hoãn.
Độ lệch chuẩn
Độ lệch chuẩn (SD) đo lường sự thay đổi hoặc không chắc chắn trong ước tính.
Trong bản phân phối beta,
Trung bình = (O + 4 × M + L) / 6
Độ lệch chuẩn (SD) = (L - O) / 6
Các bước ước tính PERT
Step (1) - Đến WBS.
Step (2) - Đối với mỗi nhiệm vụ, hãy tìm ba giá trị ước tính lạc quan nhất (O), ước tính có khả năng xảy ra nhất (M) và ước tính bi quan (L).
Step (3) - PERT Mean = (O + 4 × M + L) / 6
PERT Mean = (O + 4 × M + L) / 3
Step (4) - Tính độ lệch chuẩn của nguyên công.
Độ lệch chuẩn (SD) = (L - O) / 6
Step (6) - Lặp lại các bước 2, 3, 4 cho tất cả các tác vụ trong WBS.
Step (7) - Tính toán dự toán PERT của dự án.
E (Dự án) = ∑ E (Nhiệm vụ)
Step (8) - Tính độ lệch chuẩn của dự án.
SD (Dự án) = √ (ΣSD (Nhiệm vụ) 2 )
Chuyển đổi Dự toán Dự án sang Mức độ Tin cậy
Ước tính PERT (E) và Độ lệch chuẩn (SD) được tính toán do đó được sử dụng để chuyển các ước tính của dự án sang mức độ tin cậy.
Việc chuyển đổi dựa trên cơ sở đó
- Mức độ tin cậy trong E +/– SD là khoảng 68%.
- Mức độ tin cậy ở giá trị E +/– 1.645 × SD là khoảng 90%.
- Mức độ tin cậy ở giá trị E +/– 2 × SD là khoảng 95%.
- Mức độ tin cậy trong giá trị E +/– 3 × SD là khoảng 99,7%.
Thông thường, mức độ tin cậy 95%, tức là Giá trị E + 2 × SD, được sử dụng cho tất cả các ước tính dự án và nhiệm vụ.
Sự khác biệt giữa Ước tính Ba điểm và PERT
Sau đây là những điểm khác biệt giữa Ước tính Ba điểm và PERT -
| Ước tính ba điểm | PERT |
|---|---|
| Trung bình đơn giản | Bình quân gia quyền |
| Theo dõi Phân phối hình tam giác | Theo dõi Phân phối beta |
| Được sử dụng cho các dự án nhỏ lặp lại | Được sử dụng cho các dự án lớn không lặp lại, thường là các dự án R&D. Được sử dụng cùng với Phương pháp đường dẫn tới hạn (CPM) |
E = Mean = (O + M + L) / 3 Đây là mức trung bình đơn giản |
E = Mean = (O + 4 × M + L) / 6 Đây là mức trung bình có trọng số |
| SD = √ [((O - E) 2 + (M - E) 2 + (L - E) 2 ) / 2] | SD = (L - O) / 6 |
Analogous Estimationsử dụng thông tin dự án tương tự trong quá khứ để ước tính thời lượng hoặc chi phí của dự án hiện tại của bạn, do đó có từ "loại suy". Bạn có thể sử dụng ước tính tương tự khi có thông tin hạn chế về dự án hiện tại của bạn.
Thông thường, sẽ có những tình huống khi các nhà quản lý dự án sẽ được yêu cầu đưa ra các ước tính chi phí và thời gian cho một dự án mới vì các nhà điều hành cần dữ liệu ra quyết định để quyết định xem dự án có đáng thực hiện hay không. Thông thường, cả người quản lý dự án hay bất kỳ ai khác trong tổ chức đều chưa từng thực hiện một dự án như dự án mới nhưng các nhà điều hành vẫn muốn ước tính chi phí và thời gian chính xác.
Trong những trường hợp như vậy, ước lượng tương tự là giải pháp tốt nhất. Nó có thể không hoàn hảo nhưng chính xác vì nó dựa trên dữ liệu quá khứ. Ước lượng tương tự là một kỹ thuật dễ thực hiện. Tỷ lệ thành công của dự án có thể lên đến 60% so với ước tính ban đầu.
Ước tính tương tự - Định nghĩa
Ước tính tương tự là một kỹ thuật sử dụng giá trị của các tham số từ dữ liệu lịch sử làm cơ sở để ước tính tham số tương tự cho một hoạt động trong tương lai. Ví dụ về tham số: Phạm vi, chi phí và thời lượng. Các phép đo của các ví dụ về quy mô - Kích thước, trọng lượng và độ phức tạp.
Bởi vì kinh nghiệm và phán đoán của người quản lý dự án, và có thể là của nhóm được áp dụng cho quá trình ước tính, nó được coi là sự kết hợp giữa thông tin lịch sử và đánh giá của chuyên gia.
Yêu cầu ước tính tương tự
Đối với ước lượng tương tự, yêu cầu sau:
- Dữ liệu từ các dự án trước đây và đang thực hiện
- Giờ làm việc mỗi tuần của mỗi thành viên trong nhóm
- Các chi phí liên quan để hoàn thành dự án
- Dự án gần với dự án hiện tại
- Trong trường hợp Dự án hiện tại là mới và không có dự án nào trong quá khứ tương tự
- Các mô-đun từ các dự án trước đây tương tự như các mô-đun trong dự án hiện tại
- Các hoạt động từ các dự án trước đây tương tự với các hoạt động trong dự án hiện tại
- Dữ liệu từ những cái đã chọn này
- Sự tham gia của người quản lý dự án và nhóm dự toán để đảm bảo đánh giá có kinh nghiệm về các ước tính.
Các bước ước tính tương tự
Người quản lý dự án và nhóm phải thực hiện ước tính tương tự.
Step 1 - Xác định miền của dự án hiện tại.
Step 2 - Xác định công nghệ của dự án hiện tại.
Step 3- Tìm trong cơ sở dữ liệu của tổ chức nếu có sẵn dữ liệu dự án tương tự. Nếu có, hãy chuyển đến Bước (4). Nếu không, hãy chuyển đến Bước (6).
Step 4 - So sánh dự án hiện tại với dữ liệu dự án quá khứ đã xác định.
Step 5- Đến thời hạn và ước tính chi phí của dự án hiện tại. Điều này kết thúc ước tính tương tự của dự án.
Step 6 - Tìm kiếm trong cơ sở dữ liệu của tổ chức nếu bất kỳ dự án trước đây có các mô-đun tương tự như trong dự án hiện tại.
Step 7 - Tìm trong cơ sở dữ liệu của tổ chức nếu có bất kỳ dự án nào trong quá khứ có các hoạt động tương tự như trong dự án hiện tại.
Step 8 - Thu thập tất cả những thứ đó và sử dụng đánh giá của chuyên gia để đưa ra thời hạn và ước tính chi phí của dự án hiện tại.
Ưu điểm của ước lượng tương tự
Ước lượng tương tự là một cách ước lượng tốt hơn trong các giai đoạn ban đầu của dự án khi rất ít chi tiết được biết đến.
Kỹ thuật này đơn giản và thời gian ước tính rất ít.
Tỷ lệ thành công của tổ chức có thể được mong đợi là cao vì kỹ thuật này dựa trên dữ liệu dự án trong quá khứ của tổ chức.
Ước tính tương tự cũng có thể được sử dụng để ước tính nỗ lực và thời gian của các nhiệm vụ riêng lẻ. Do đó, trong WBS khi bạn ước tính các nhiệm vụ, bạn có thể sử dụng Tương tự.
Cấu trúc phân chia công việc (WBS), trong Quản lý dự án và Kỹ thuật hệ thống, là sự phân rã theo hướng có thể phân phối của một dự án thành các thành phần nhỏ hơn. WBS là một dự án quan trọng có thể phân phối giúp tổ chức công việc của nhóm thành các phần có thể quản lý được. Cơ quan tri thức quản lý dự án (PMBOK) định nghĩa WBS là "sự phân tách thứ bậc có định hướng có thể phân phối của công việc được thực hiện bởi nhóm dự án."
Phần tử WBS có thể là sản phẩm, dữ liệu, dịch vụ hoặc bất kỳ sự kết hợp nào của chúng. WBS cũng cung cấp khuôn khổ cần thiết để ước tính và kiểm soát chi phí cùng với việc cung cấp hướng dẫn để phát triển và kiểm soát lịch trình.
Đại diện của WBS
WBS được biểu diễn dưới dạng danh sách phân cấp các hoạt động công việc của dự án. Có hai định dạng WBS -
- Chế độ xem phác thảo (Định dạng thụt lề)
- Chế độ xem cấu trúc cây (Sơ đồ tổ chức)
Trước tiên, chúng ta hãy thảo luận về cách sử dụng dạng xem phác thảo để chuẩn bị một WBS.
Xem phác thảo
Dạng xem phác thảo là một bố cục rất thân thiện với người dùng. Nó thể hiện một cái nhìn tốt về toàn bộ dự án và cũng cho phép dễ dàng sửa đổi. Nó sử dụng các con số để ghi lại các giai đoạn khác nhau của một dự án. Nó trông giống như sau:
Software Development
Scope
- Xác định phạm vi dự án
- Tài trợ dự án an toàn
- Xác định tài nguyên sơ bộ
- Bảo mật tài nguyên cốt lõi
- Phạm vi hoàn thành
Analysis/Software Requirements
- Tiến hành phân tích nhu cầu
- Dự thảo thông số kỹ thuật phần mềm sơ bộ
- Xây dựng ngân sách sơ bộ
- Xem xét thông số kỹ thuật / ngân sách phần mềm với nhóm
- Kết hợp phản hồi về thông số kỹ thuật phần mềm
- Phát triển tiến trình giao hàng
- Nhận được sự chấp thuận để tiếp tục (khái niệm, thời gian và ngân sách)
- Bảo mật các tài nguyên cần thiết
- Phân tích hoàn thành
Design
- Xem xét thông số kỹ thuật phần mềm sơ bộ
- Phát triển các thông số kỹ thuật chức năng
- Nhận được sự chấp thuận để tiếp tục
- Thiết kế hoàn chỉnh
Development
- Xem lại thông số kỹ thuật chức năng
- Xác định các thông số thiết kế mô-đun / phân cấp
- Phát triển mã
- Thử nghiệm dành cho nhà phát triển (gỡ lỗi chính)
- Phát triển hoàn thành
Testing
- Xây dựng kế hoạch thử nghiệm đơn vị bằng cách sử dụng các thông số kỹ thuật của sản phẩm
- Phát triển kế hoạch kiểm tra tích hợp bằng cách sử dụng các thông số kỹ thuật sản phẩm
Training
- Phát triển các đặc điểm đào tạo cho người dùng cuối
- Xác định phương pháp phân phối đào tạo (trực tuyến, lớp học, v.v.)
- Xây dựng tài liệu đào tạo
- Hoàn thiện tài liệu đào tạo
- Xây dựng cơ chế phân phối đào tạo
- Tài liệu đào tạo hoàn chỉnh
Deployment
- Xác định chiến lược triển khai cuối cùng
- Phát triển phương pháp triển khai
- Tài nguyên triển khai an toàn
- Đào tạo nhân viên hỗ trợ
- Triển khai phần mềm
- Triển khai hoàn tất
Bây giờ chúng ta hãy nhìn vào chế độ xem cấu trúc cây.
Chế độ xem cấu trúc cây
Chế độ xem Cấu trúc cây trình bày một cái nhìn rất dễ hiểu về toàn bộ dự án. Hình minh họa sau đây cho thấy một dạng xem cấu trúc cây trông như thế nào. Loại cấu trúc sơ đồ tổ chức này có thể được vẽ dễ dàng bằng các tính năng có sẵn trong MS-Word.
Các loại WBS
Có hai loại WBS -
Functional WBS- Trong WBS chức năng, hệ thống bị hỏng dựa trên các chức năng trong ứng dụng được phát triển. Điều này rất hữu ích trong việc ước tính kích thước của hệ thống.
Activity WBS- Trong WBS hoạt động, hệ thống bị hỏng dựa trên các hoạt động trong hệ thống. Các hoạt động được chia nhỏ thành các nhiệm vụ. Điều này rất hữu ích trong việc ước tính nỗ lực và lịch trình trong hệ thống.
Kích thước ước tính
Step 1 - Bắt đầu với WBS chức năng.
Step 2 - Xét các nút lá.
Step 3 - Sử dụng Analogy hoặc Wideband Delphi để ước tính kích thước.
Ước tính nỗ lực
Step 1- Sử dụng kỹ thuật Wideband Delphi để xây dựng WBS. Chúng tôi đề xuất rằng các nhiệm vụ không nên kéo dài hơn 8 giờ. Nếu một nhiệm vụ có thời lượng lớn hơn, hãy chia nhỏ nó ra.
Step 2 - Sử dụng Kỹ thuật Delphi băng rộng hoặc Ước tính ba điểm để đạt được Ước tính Nỗ lực cho Nhiệm vụ.
Lập lịch trình
Khi WBS đã sẵn sàng và đã biết được các ước tính về quy mô và nỗ lực, bạn đã sẵn sàng lên lịch cho các nhiệm vụ.
Trong khi lên lịch cho các nhiệm vụ, cần lưu ý một số điều sau:
Precedence - Một nhiệm vụ phải xảy ra trước một nhiệm vụ khác được cho là có quyền ưu tiên của nhiệm vụ kia.
Concurrence - Nhiệm vụ đồng thời là những công việc có thể xảy ra cùng một lúc (song song).
Critical Path - Tập hợp cụ thể các nhiệm vụ tuần tự phụ thuộc vào ngày hoàn thành dự án.
- Tất cả các dự án đều có một con đường quan trọng.
- Đẩy nhanh các nhiệm vụ không quan trọng không trực tiếp rút ngắn lịch trình.
Phương pháp đường dẫn quan trọng
Phương pháp đường dẫn tới hạn (CPM) là quá trình xác định và tối ưu hóa đường dẫn quan trọng. Các nhiệm vụ đường dẫn không quan trọng có thể bắt đầu sớm hơn hoặc muộn hơn mà không ảnh hưởng đến ngày hoàn thành.
Xin lưu ý rằng đường dẫn quan trọng có thể thay đổi thành đường dẫn khác khi bạn rút ngắn đường dẫn hiện tại. Ví dụ, đối với WBS trong hình trước, đường dẫn quan trọng sẽ như sau:
Vì ngày hoàn thành dự án dựa trên một tập hợp các nhiệm vụ tuần tự, các nhiệm vụ này được gọi là các nhiệm vụ quan trọng.
Ngày hoàn thành dự án không dựa trên việc đào tạo, tài liệu và triển khai. Những nhiệm vụ như vậy được gọi là những nhiệm vụ không quan trọng.
Mối quan hệ phụ thuộc nhiệm vụ
Một số thời điểm nhất định, trong khi lập lịch, bạn có thể phải xem xét các mối quan hệ phụ thuộc vào nhiệm vụ. Các Mối quan hệ Phụ thuộc Nhiệm vụ quan trọng là -
- Kết thúc để Bắt đầu (FS)
- Kết thúc để Kết thúc (FF)
Kết thúc để Bắt đầu (FS)
Trong mối quan hệ phụ thuộc nhiệm vụ Finish-to-Start (FS), Nhiệm vụ B không thể bắt đầu cho đến khi Nhiệm vụ A hoàn thành.
Kết thúc để Kết thúc (FF)
Trong mối quan hệ phụ thuộc nhiệm vụ Kết thúc đến Kết thúc (FF), Nhiệm vụ B không thể hoàn thành cho đến khi Nhiệm vụ A hoàn thành.
Biểu đồ Gantt
Biểu đồ Gantt là một loại biểu đồ thanh, được điều chỉnh bởi Karol Adamiecki vào năm 1896 và được Henry Gantt độc lập vào những năm 1910, minh họa lịch trình dự án. Biểu đồ Gantt minh họa ngày bắt đầu và ngày kết thúc của các yếu tố đầu cuối và các yếu tố tóm tắt của một dự án.
Bạn có thể đưa Định dạng Đường viền trong Hình 2 vào Microsoft Project để có được Dạng xem Biểu đồ Gantt.
Các cột mốc
Các mốc quan trọng là giai đoạn quan trọng trong lịch trình của bạn. Chúng sẽ có thời hạn bằng 0 và được sử dụng để gắn cờ rằng bạn đã hoàn thành một số nhiệm vụ nhất định. Các cột mốc thường được thể hiện dưới dạng một viên kim cương.
Ví dụ, trong Biểu đồ Gantt ở trên, Hoàn thành Thiết kế và Hoàn thành Phát triển được hiển thị dưới dạng các mốc quan trọng, được thể hiện bằng hình kim cương.
Các mốc quan trọng có thể được gắn với Điều khoản hợp đồng.
Ưu điểm của Ước tính bằng WBS
WBS đơn giản hóa quá trình ước tính dự án ở một mức độ lớn. Nó cung cấp những ưu điểm sau so với các kỹ thuật ước tính khác:
Trong WBS, toàn bộ công việc phải thực hiện của dự án được xác định. Do đó, bằng cách xem xét WBS với các bên liên quan của dự án, bạn sẽ ít có khả năng bỏ sót bất kỳ công việc nào cần thiết để cung cấp các sản phẩm dự án mong muốn.
WBS dẫn đến ước tính chi phí và lịch trình chính xác hơn.
Người quản lý dự án thu hút sự tham gia của nhóm để hoàn thiện WBS. Sự tham gia này của nhóm tạo ra sự nhiệt tình và trách nhiệm trong dự án.
WBS cung cấp cơ sở cho việc phân công nhiệm vụ. Vì một nhiệm vụ chính xác được giao cho một thành viên trong nhóm cụ thể, người sẽ chịu trách nhiệm về thành tích của nó.
WBS cho phép giám sát và kiểm soát ở cấp tác vụ. Điều này cho phép bạn đo lường tiến độ và đảm bảo rằng dự án của bạn sẽ được giao đúng thời hạn.
Lập kế hoạch Ước tính Poker
Lập kế hoạch Poker là một kỹ thuật dựa trên sự đồng thuận để ước tính, chủ yếu được sử dụng để ước tính nỗ lực hoặc quy mô tương đối của các câu chuyện người dùng trong Scrum.
Lập kế hoạch Poker kết hợp ba kỹ thuật ước tính - Kỹ thuật Delphi băng rộng, Ước tính tương tự và Ước tính sử dụng WBS.
Planning Poker lần đầu tiên được James Grenning định nghĩa và đặt tên vào năm 2002 và sau đó được Mike Cohn phổ biến trong cuốn sách “Agile Estimating and Planning”, mà thương mại công ty đã đánh dấu thuật ngữ này.
Lập kế hoạch Kỹ thuật Ước tính Poker
Trong Kỹ thuật Lập kế hoạch Ước tính Poker, ước tính cho các câu chuyện của người dùng được tính toán bằng cách lập kế hoạch chơi Poker. Toàn bộ nhóm Scrum đều tham gia và kết quả là các ước tính nhanh chóng nhưng đáng tin cậy.
Planning Poker được chơi với một bộ bài. Khi sử dụng dãy Fibonacci, các thẻ có các số - 1, 2, 3, 5, 8, 13, 21, 34, v.v. Những con số này đại diện cho “Điểm câu chuyện”. Mỗi người ước tính có một bộ bài. Các số trên thẻ phải đủ lớn để tất cả các thành viên trong nhóm có thể nhìn thấy khi một trong các thành viên trong nhóm giơ thẻ.
Một trong các thành viên trong nhóm được chọn làm Người điều hành. Người kiểm duyệt đọc mô tả về câu chuyện của người dùng mà ước tính đang được thực hiện. Nếu người ước tính có bất kỳ câu hỏi nào, chủ sở hữu sản phẩm sẽ trả lời họ.
Mỗi người ước tính chọn riêng một thẻ đại diện cho ước tính của họ. Các thẻ không được hiển thị cho đến khi tất cả những người ước tính đã thực hiện lựa chọn. Khi đó, tất cả các thẻ đồng thời được lật lên và giơ lên để tất cả các thành viên trong nhóm có thể xem từng ước tính.
Trong vòng đầu tiên, rất có thể các ước tính sẽ khác nhau. Các nhà ước tính cao và thấp giải thích lý do cho các ước tính của họ. Cần lưu ý rằng tất cả các cuộc thảo luận chỉ nhằm mục đích hiểu biết và không có gì phải được thực hiện một cách cá nhân. Người điều hành phải đảm bảo như vậy.
Nhóm có thể thảo luận về câu chuyện và ước tính của họ trong vài phút nữa.
Người điều hành có thể ghi chú vào cuộc thảo luận sẽ hữu ích khi câu chuyện cụ thể được phát triển. Sau khi thảo luận, mỗi người ước tính ước tính lại bằng cách chọn lại một thẻ. Các thẻ một lần nữa được giữ bí mật cho đến khi mọi người ước tính, tại thời điểm đó chúng được lật cùng một lúc.
Lặp lại quy trình cho đến khi các ước tính hội tụ thành một ước tính duy nhất có thể được sử dụng cho câu chuyện. Số lượng vòng ước tính có thể khác nhau tùy theo từng câu chuyện của người dùng.
Lợi ích của Lập kế hoạch Ước tính Poker
Lập kế hoạch chơi poker kết hợp ba phương pháp ước tính -
Expert Opinion- Trong cách tiếp cận ước tính dựa trên ý kiến chuyên gia, một chuyên gia được hỏi sẽ mất bao lâu hoặc mức độ lớn của một thứ gì đó. Chuyên gia đưa ra một ước tính dựa trên kinh nghiệm hoặc trực giác hoặc cảm giác của họ. Ước tính ý kiến của chuyên gia thường không mất nhiều thời gian và chính xác hơn so với một số phương pháp phân tích.
Analogy- Ước lượng tương tự sử dụng so sánh các câu chuyện của người dùng. Câu chuyện người dùng được ước tính được so sánh với câu chuyện người dùng tương tự được triển khai trước đó, cho kết quả chính xác vì ước tính dựa trên dữ liệu đã được chứng minh.
Disaggregation- Ước tính phân tách được thực hiện bằng cách chia câu chuyện người dùng thành các câu chuyện người dùng nhỏ hơn, dễ ước tính hơn. Các câu chuyện người dùng được đưa vào sprint thường trong khoảng từ hai đến năm ngày để phát triển. Do đó, các câu chuyện người dùng có thể mất nhiều thời gian hơn cần được chia thành các Trường hợp sử dụng nhỏ hơn. Cách tiếp cận này cũng đảm bảo rằng sẽ có nhiều câu chuyện có thể so sánh được.
Các nỗ lực kiểm tra không dựa trên bất kỳ khung thời gian nhất định nào. Các nỗ lực tiếp tục cho đến khi một số mốc thời gian quyết định trước được thiết lập, bất kể việc hoàn thành thử nghiệm.
Điều này chủ yếu là do thông thường, test effort estimation là một phần của development estimation. Chỉ trong trường hợp các kỹ thuật ước lượng sử dụng WBS, chẳng hạn như Wideband Delphi, Ước tính ba điểm, PERT và WBS, bạn mới có thể nhận được các giá trị cho ước tính của các hoạt động thử nghiệm.
Nếu bạn đã nhận được các ước tính dưới dạng Điểm chức năng (FP), thì theo Caper Jones,
Number of Test Cases = (Number of Function Points) × 1.2
Khi bạn có số lượng trường hợp thử nghiệm, bạn có thể lấy dữ liệu năng suất từ cơ sở dữ liệu tổ chức và thực hiện nỗ lực cần thiết để thử nghiệm.
Phần trăm của Phương pháp Nỗ lực Phát triển
Nỗ lực kiểm tra cần thiết là một tỷ lệ hoặc tỷ lệ phần trăm trực tiếp của nỗ lực phát triển. Nỗ lực phát triển có thể được ước tính bằng cách sử dụng Dòng mã (LOC) hoặc Điểm chức năng (FP). Sau đó, phần trăm nỗ lực để kiểm tra được lấy từ Cơ sở dữ liệu của Tổ chức. Tỷ lệ phần trăm thu được được sử dụng để ước tính nỗ lực cho thử nghiệm.
Ước tính các dự án thử nghiệm
Một số tổ chức hiện đang cung cấp dịch vụ xác minh và xác nhận độc lập cho khách hàng của họ và điều đó có nghĩa là các hoạt động của dự án sẽ hoàn toàn là các hoạt động thử nghiệm.
Việc ước tính các dự án kiểm thử đòi hỏi kinh nghiệm về các dự án khác nhau trong vòng đời kiểm thử phần mềm. Khi bạn đang ước tính một dự án thử nghiệm, hãy xem xét -
- Kỹ năng nhóm
- Kiến thức miền
- Độ phức tạp của ứng dụng
- Dữ liệu lịch sử
- Chu kỳ lỗi cho dự án
- Nguồn lực sẵn có
- Các biến đổi về năng suất
- Môi trường hệ thống và thời gian chết
Kiểm tra kỹ thuật ước tính
Các kỹ thuật ước tính thử nghiệm sau đây được chứng minh là chính xác và được sử dụng rộng rãi:
- Kỹ thuật ước lượng kiểm thử phần mềm PERT
- Phương pháp UCP
- WBS
- Kỹ thuật băng rộng Delphi
- Điểm chức năng / Phân tích điểm kiểm tra
- Phân phối phần trăm
- Kỹ thuật ước tính thử nghiệm dựa trên kinh nghiệm
Kỹ thuật ước tính kiểm tra phần mềm PERT
Kỹ thuật ước lượng kiểm thử phần mềm PERT dựa trên các phương pháp thống kê trong đó mỗi nhiệm vụ kiểm thử được chia nhỏ thành các nhiệm vụ con và sau đó ba loại ước tính được thực hiện trên mỗi nhiệm vụ con.
Công thức được sử dụng bởi kỹ thuật này là:
Test Estimate = (O + (4 × M) + E)/6
Ở đâu,
O = Ước tính lạc quan (trường hợp tốt nhất trong đó không có gì sai và tất cả các điều kiện đều tối ưu).
M = Nhiều khả năng ước tính (rất có thể là khoảng thời gian và có thể có một số vấn đề nhưng hầu hết mọi thứ sẽ diễn ra đúng như vậy).
L = Ước tính bi quan (trường hợp xấu nhất mọi thứ diễn ra không như ý muốn).
Độ lệch chuẩn của kỹ thuật được tính như sau:
Standard Deviation (SD) = (E − O)/6
Phương pháp điểm trường hợp sử dụng
Phương pháp UCP dựa trên các trường hợp sử dụng trong đó chúng tôi tính toán trọng số tác nhân chưa điều chỉnh và trọng số trường hợp sử dụng chưa điều chỉnh để xác định ước tính kiểm thử phần mềm.
Ca sử dụng là tài liệu chỉ định những người dùng, hệ thống hoặc các bên liên quan khác tương tác với ứng dụng liên quan. Họ được đặt tên là "Diễn viên". Các tương tác thực hiện một số mục tiêu xác định bảo vệ lợi ích của tất cả các bên liên quan thông qua các hành vi hoặc luồng khác nhau được gọi là các kịch bản.
Step 1- Đếm số không. của các diễn viên. Các tác nhân bao gồm tích cực, tiêu cực và đặc biệt.
Step 2 - Tính toán trọng lượng diễn viên chưa điều chỉnh như
Unadjusted Actor Weights = Total no. of Actors
Step 3 - Đếm số ca sử dụng.
Step 4 - Tính toán trọng lượng ca sử dụng chưa điều chỉnh như
Unadjusted Use-Case Weights = Total no. of Use-Cases
Step 5 - Tính toán các điểm trường hợp sử dụng chưa được điều chỉnh như
Unadjusted Use-Case Points = (Unadjusted Actor Weights + Unadjusted Use-Case Weights)
Step 6- Xác định yếu tố kỹ thuật / môi trường (TEF). Nếu không có sẵn, hãy lấy nó là 0,50.
Step 7 - Tính toán điểm trường hợp sử dụng đã điều chỉnh như
Adjusted Use-Case Point = Unadjusted Use-Case Points × [0.65 + (0.01 × TEF]
Step 8 - Tính tổng nỗ lực như
Total Effort = Adjusted Use-Case Point × 2
Cấu trúc phân chia công việc
Step 1 - Tạo WBS bằng cách chia nhỏ dự án thử nghiệm thành nhiều phần nhỏ.
Step 2 - Chia module thành các module con.
Step 3 Chia các mô-đun con thành các chức năng.
Step 4 - Chia chức năng thành các chức năng con.
Step 5 - Xem xét tất cả các yêu cầu thử nghiệm để đảm bảo chúng được thêm vào WBS.
Step 6 - Tìm ra số lượng nhiệm vụ mà nhóm của bạn cần hoàn thành.
Step 7 - Ước tính nỗ lực cho từng nhiệm vụ.
Step 8 - Ước tính thời lượng của từng nhiệm vụ.
Kỹ thuật băng rộng Delphi
Trong Phương pháp Wideband Delphi, WBS được phân phối cho một nhóm bao gồm 3-7 thành viên để ước tính lại các nhiệm vụ. Ước tính cuối cùng là kết quả của các ước tính tổng hợp dựa trên sự đồng thuận của nhóm.
Phương pháp này nói nhiều về kinh nghiệm hơn là bất kỳ công thức thống kê nào. Phương pháp này được phổ biến bởi Barry Boehm để nhấn mạnh vào việc lặp lại nhóm để đạt được sự đồng thuận trong đó nhóm hình dung các khía cạnh khác nhau của các vấn đề trong khi ước tính nỗ lực kiểm tra.
Phân tích điểm chức năng / điểm kiểm tra
FP chỉ ra chức năng của ứng dụng phần mềm từ quan điểm của người dùng và được sử dụng như một kỹ thuật để ước tính quy mô của một dự án phần mềm.
Trong thử nghiệm, ước tính dựa trên tài liệu đặc tả yêu cầu hoặc dựa trên nguyên mẫu của ứng dụng đã tạo trước đó. Để tính toán FP cho một dự án, cần phải có một số thành phần chính. Họ là -
Unadjusted Data Function Points - i) Tệp bên trong, ii) Giao diện bên ngoài
Unadjusted Transaction Function Points - i) Đầu vào của người dùng, ii) Đầu ra của người dùng & iii) Yêu cầu của người dùng
Capers Jones basic formula -
Số trường hợp thử nghiệm = (Số điểm chức năng) × 1,2
Total Actual Effort (TAE) -
(Số lượng trường hợp thử nghiệm) × (Phần trăm nỗ lực phát triển / 100)
Phân phối phần trăm
Trong kỹ thuật này, tất cả các giai đoạn của Vòng đời phát triển phần mềm (SDLC) được chỉ định nỗ lực theo%. Điều này có thể dựa trên dữ liệu quá khứ từ các dự án tương tự. Ví dụ -
| Giai đoạn | % Nỗ lực |
|---|---|
| Quản lý dự án | 7% |
| Yêu cầu | 9% |
| Thiết kế | 16% |
| Mã hóa | 26% |
| Thử nghiệm (tất cả các Giai đoạn Thử nghiệm) | 27% |
| Tài liệu | 9% |
| Cài đặt và Đào tạo | 6% |
Tiếp theo,% nỗ lực dành cho thử nghiệm (tất cả các giai đoạn thử nghiệm) được phân bổ thêm cho tất cả các Giai đoạn Thử nghiệm -
| Tất cả các giai đoạn thử nghiệm | % Nỗ lực |
|---|---|
| Kiểm tra thành phần | 16 |
| Kiểm tra độc lập | 84 |
| Total | 100 |
| Kiểm tra độc lập | % Nỗ lực |
|---|---|
| Thử nghiệm hội nhập | 24 |
| Thử nghiệm hệ thống | 52 |
| Kiểm tra chấp nhận | 24 |
| Total | 100 |
| Thử nghiệm hệ thống | % Nỗ lực |
|---|---|
| Kiểm tra hệ thống chức năng | 65 |
| Kiểm tra hệ thống phi chức năng | 35 |
| Total | 100 |
| Kiểm tra quy hoạch và kiến trúc thiết kế | 50% |
| Giai đoạn xem xét | 50% |
Kỹ thuật ước tính thử nghiệm dựa trên kinh nghiệm
Kỹ thuật này dựa trên phép loại suy và các chuyên gia. Kỹ thuật này giả định rằng bạn đã thử nghiệm các ứng dụng tương tự trong các dự án trước đó và thu thập số liệu từ các dự án đó. Bạn cũng đã thu thập số liệu từ các thử nghiệm trước đó. Lấy thông tin đầu vào từ các chuyên gia về chủ đề, những người hiểu rất rõ về ứng dụng (cũng như thử nghiệm) và sử dụng các chỉ số bạn đã thu thập và đến nỗ lực thử nghiệm.