LOC có phải là thông số chính xác cho ước tính dự án không?

Question

LOC có phải là thông số chính xác cho dự toán dự án không?

có quá nhiều trường hợp phức tạp mất nhiều thời gian hơn cho một dòng mã, ngoài LOC có thể là tham số được đề xuất cho ước tính dự án là gì?

Khi mọi người đang nói về điểm chức năng của chương trình, điều đó có ý nghĩa gì đối với thông tin liên quan đến ca sử dụng không?

Tôi đang cố gắng tìm ra bất kỳ cơ sở vững chắc nào để ước tính phát triển phần mềm đầy đủ có thể bao gồm phân tích, thiết kế, chuẩn bị testcase và mã hóa, vui lòng đề xuất?

Answer 1

Chỉ khi bạn sử dụng nó trong nghịch đảo.

- Chỉnh sửa

Nhưng không. Nó không phải là. Đó là một biện pháp chủ yếu vô dụng, và thường có hại. Như bạn lưu ý, ít mã hơn hầu hết là luôn luôn tốt hơn.

Những thứ khác cần kiểm tra? Vâng, bạn đang cố đo lường điều gì? Bạn muốn thấy kết quả gì từ sự thay đổi về những thứ mà bạn sẽ kiểm tra? Bạn sẽ đưa ra quyết định gì dựa trên những thay đổi này?

Answer 2

Steve McConnell trong phát triển nhanh (Microsoft Press, 1996):

Bởi vì khác lập trình ngôn ngữ tạo ra tiếng nổ khác nhau như cho một số lượng nhất định của dòng mã, nhiều của ngành công nghiệp phần mềm là di chuyển về phía biện pháp được gọi là "điểm chức năng" để ước tính kích thước chương trình . Điểm chức năng là thước đo tổng hợp của kích thước chương trình dựa trên số trên tổng trọng số của số đầu vào, đầu ra, yêu cầu và tệp. Các điểm chức năng hữu ích vì chúng cho phép bạn suy nghĩ về chương trình kích thước bằng ngôn ngữ độc lập.

"Điểm chức năng" của Google để biết thêm thông tin.

Answer 3

LOC là một biện pháp proxy để đo lường kích thước vấn đề .

Ước tính LOC có thể được sử dụng và số lượng LOC tương đối rẻ để đo lường từ các dự án lịch sử. Nhưng LOC có thể có vấn đề nếu được sử dụng cho bất cứ điều gì khác hơn là một proxy cho kích thước vấn đề, như đã được chỉ ra bởi câu trả lời khác.

Kích thước vấn đề khá ổn định theo yêu cầu. Từ một ước tính kích thước bạn có thể đi đến các ước tính công sức, tiến độ và chi phí. Nó phụ thuộc vào trình điều khiển lập kế hoạch của bạn như chi phí hoặc lịch trình. Từ dữ liệu lịch sử, bạn có thể tìm thấy mối tương quan giữa kích thước vấn đề được dịch như thế nào và nỗ lực của các trình điều khiển lập kế hoạch khác ảnh hưởng đến kết quả như thế nào. Vì vậy, bạn cần phải đo lường kích thước và nỗ lực so với các thông số khác và tiếp tục tinh chỉnh quy trình ước tính của bạn. Có một số biện pháp LOC-to-effort có sẵn trong văn học, nhưng chúng không chính xác lắm trong miền của bạn, sử dụng công nghệ bạn đang sử dụng và nhóm bạn có.

Các proxy khác cho kích thước vấn đề là các điểm chức năng và điểm câu chuyện.Kinh nghiệm của tôi về các điểm chức năng là chúng hiếm khi đáng để nỗ lực. Mặt khác, các điểm câu chuyện trong các phương thức nhanh hoạt động rất tốt vì chúng cố tình trừu tượng (do đó tránh được nhiều vấn đề với LOC) và được đo trên cơ sở chạy nước rút, với phản hồi tức thì vào các lần chạy nước rút sau.

Answer 4

Thấy nhà phát triển có khả năng * dành phần lớn thời gian của mình để thử nghiệm thay đổi, dòng mã không bao giờ là chỉ báo tốt về kích thước của sự cố.

Giả sử bạn có một ứng dụng lớn hiện có - việc thay đổi một dòng mã có thể có vẻ tầm thường, nhưng việc lập kế hoạch thử nghiệm và thực thi có thể mất vài tuần.

Tương tự như vậy, việc thêm một số lượng mã tương đối lớn vào một mô-đun phạm vi giới hạn duy nhất dễ kiểm tra có thể chỉ là một vài ngày.

* ít nhất là họ nên làm. Nếu họ dành nhiều thời gian viết mã hơn kiểm tra nó, nó có thể là đầy đủ các lỗi. Và tôi có nghĩa là TRƯỚC KHI nó đạt đến đội QA chuyên dụng của bạn.

Answer 5

Không, không phải vậy. Lý do rất đơn giản: nếu bạn tạo ra một dòng mã mới trong quá trình phát triển của mình, bạn có tiến gần hơn tới một giải pháp không? Nếu bạn ước tính 1000 dòng mã để hoàn thành một công việc, bây giờ bạn đã hoàn thành 0,1% với nhiệm vụ đó chưa?

Các dòng mã có thể được sử dụng làm chỉ số nhưng chỉ theo nghĩa tiêu cực: đối với số dòng mã lớn hơn, bạn có thể giả định rằng bạn có nhiều lỗi hơn. Dựa trên dữ liệu lịch sử, thường có mối tương quan tuyến tính giữa các dòng mã và số lỗi.

Dưới đây là một số yếu tố hữu ích và có thể đo lường được giá trị xem xét:

1. giờ lao động.
2. đô la chi tiêu: đây là một tốt bởi vì nó thực thi mạnh mẽ thực tế mà bạn muốn tìm lỗi ở máy tính để bàn của nhà phát triển hơn trong tay của một thử nghiệm hoặc khách hàng).
3. Cột mốc đáp ứng: hệ thống có sẵn cho khách hàng vào đúng ngày không?
4. Yêu cầu đã hoàn thành: đây có thể là một điều thú vị - nếu bạn phát hiện ra một nhu cầu khách hàng mới trong dự án thì sao?

Trong ngắn hạn, dòng mã rất gần với số liệu có thể tồi tệ nhất mà bạn từng sử dụng.

Answer 6

Cách duy nhất để có được bất kỳ ước tính hợp lý nào về thời lượng dự án là HOÀN TOÀN thực hiện và phân phối một số tập hợp con các yêu cầu cuối cùng. Sau đó, bạn có thể ước tính các yêu cầu còn lại bằng cách so sánh độ phức tạp của chúng với công việc đã hoàn thành.