Cách tốt nhất để ước tính chi phí liên quan đến chuyển mã từ ngôn ngữ A sang ngôn ngữ B?

Có một khách hàng suy nghĩ về việc ước tính chi phí chuyển một dự án từ ngôn ngữ A sang ngôn ngữ B. Cách tốt nhất để đưa ra một yêu cầu đề xuất để làm điều này là gì?

Nếu mục tiêu chỉ đơn giản là tái tạo một ứng dụng chính xác sang một ngôn ngữ mới, tôi sẽ đề nghị bạn nói với khách hàng của mình về điều đó. Porting là một trong những điều nguy hiểm nhất mà bạn có thể làm bởi vì tất cả những tật mà đã đưa ra vì họ thực hiện trong ngôn ngữ A có thể được tin cậy bởi người dùng cuối, và đột nhiên bạn phải tạo lại chúng trong ngôn ngữ B . Thứ dơ bẩn. Chưa kể rằng porting là một chi phí chìm hoàn toàn mà họ không bao giờ có thể hy vọng để phục hồi.

Tôi sẽ đề nghị đối xử với dự án như bất kỳ dự án nào khác và thu thập các yêu cầu và ước tính như thể bản gốc không tồn tại. Bạn có thể sẽ thấy rằng người dùng cuối có quan điểm mới về sản phẩm kể từ khi sử dụng nó. Nếu bạn sẽ viết lại nó, cũng có thể làm cho nó tốt hơn.

Nếu bạn đã có cơ sở mã Perl, bạn sẽ biết các dòng mã (LỘC). Xem nếu bạn có thể tìm thấy một so sánh biểu cảm giữa Perl và Ngôn ngữ B. Đây là một ví dụ.

Nói ngôn ngữ B là Java. Sau đó, LỘC được dự đoán cho cổng sẽ gấp khoảng bốn lần LỘC của bản gốc (độ biểu cảm 6 so với 1,5).

Sau đó, sử dụng một cái gì đó như phần mềm Ước tính Construx trong chế độ LỘC để ước tính bạn sẽ mất bao lâu (và sẽ mất bao nhiêu người).

Điều đó sẽ cung cấp cho bạn ước tính chi phí và thời gian trên sân bóng, cũng như một số ý tưởng về khả năng bạn sẽ vượt quá.

Nếu bạn đã thành thạo Ngôn ngữ B và đã thực hiện một số dự án được đo lường trong đó, bạn có thể sử dụng phần mềm Construx Ước tính để hiệu chỉnh cho nhóm của mình.

Joels bài viết phổ biến nhất , 'Những điều bạn không bao giờ nên làm' nói điều đó tốt nhất: Họ đã làm điều đó bằng cách mắc một lỗi chiến lược tồi tệ nhất mà bất kỳ công ty phần mềm nào cũng có thể mắc phải:

Họ quyết định viết lại mã từ đầu.

Nếu bạn cuối cùng viết lại nó, hãy viết lại cho đúng và không chỉ chuyển nó:

• Những phần nào của chương trình không còn được sử dụng? Bỏ qua những phần này.
• Phần nào của chương trình là quan trọng nhất? Cảng những đầu tiên.
• Một chương trình mới, đã đến lúc làm mới GUI và làm cho nó dễ sử dụng hơn và 'gợi cảm' hơn.
• Ồ, có phải đầu tư thời gian khổng lồ không được sử dụng tốt hơn để chỉ thêm nhiều tính năng vào mã cũ?

Sẽ mất rất nhiều thời gian tôi nghĩ. Bạn nên chắc chắn rằng nó có giá trị nó. Hãy thử lấy một phần của mã và chuyển nó. Nhân số thời gian cần thiết với tỷ lệ của các dòng mã bạn đã chuyển so với tổng số dòng mã. Nó sẽ cung cấp cho bạn một con số trên sân bóng, con số thật sẽ cao hơn bởi một số người rất có thể.

Thực tế, bạn đang viết lại ứng dụng từ đầu nhưng có các yêu cầu được chỉ định bằng ngôn ngữ khác, nó không tầm thường.

Tôi nghĩ đầu tiên và quan trọng nhất, bạn thực sự nên xem xét nếu đây là một lựa chọn tốt. Những lợi thế của việc sử dụng ngôn ngữ B thay vì ngôn ngữ A là gì?

Tôi nghĩ rằng IBM đã có một cuộc điều tra nói rằng các lập trình viên viết trung bình 100LOC một giờ. Vẫn còn nhiều thứ để phát triển hơn thế, nhưng kiến ​​trúc cũ vẫn được lên kế hoạch. Giả sử 50% sẽ viết mã, vì chương trình vẫn còn khá nhiều kế hoạch, phải không? (Nó có thể để bạn có một chương trình có cấu trúc và bạn muốn một chương trình hướng đối tượng và đó sẽ là một nhiệm vụ lớn hơn).

Nhưng nếu người ta viết 100LOC / giờ, hãy chia số lượng LỘC hiện tại trong hệ thống và nhân nó với doanh số trung bình của một lập trình viên và nhân số đó với 2. Điều này có thể đưa ra ước tính sơ bộ. Đừng xem những con số bạn nhận được rất nghiêm túc. (thậm chí tốt hơn, đừng coi trọng họ chút nào). Những gì bạn muốn làm phụ thuộc vào nhiều cách để đo lường đơn giản, chẳng hạn như:

• Các lập trình viên có năng lực trong ngôn ngữ mới
• Dự án cũ được ghi chép tốt như thế nào
• Ngôn ngữ nào đang được chuyển đổi từ và ngôn ngữ nào đang được chuyển đổi?

Nó phụ thuộc vào bao nhiêu thời gian bạn có sẵn. Một số tùy chọn:

• Không có thời gian, chỉ cần hoàn thành nó - Lấy mặt sau của một chiếc khăn ăn và đi đến đó. Nó giống như là ít hơn nó đã làm cho nó ở vị trí đầu tiên, và không chỉ đơn giản là gõ lại nó theo một cú pháp khác.
• 1-3 ngày - tìm hiểu những gì làm lại kiến ​​trúc có thể được yêu cầu, hãy cố gắng ước tính. Chỉ ra bao nhiêu logic phải được chuyển, tìm ra một số tỷ lệ. Thêm một chút thời gian cho các nhiệm vụ liên quan đến bảo mật sẽ cung cấp một số hy vọng rằng bạn đã tăng cường bảo mật trong quy trình. Thêm thời gian để thử nghiệm tích hợp dựa trên sự phức tạp của công việc và sự đơn giản của kiến ​​trúc của bạn.
• 1 tháng - thử một số - giai đoạn một kiến ​​trúc thử nghiệm, và thử chuyển một cái gì đó. Chỉ ra phần nào của mã bạn đã chuyển và ước tính thêm. Có khả năng bạn cũng sẽ tìm ra một vài điều hoàn toàn không thể trong ngôn ngữ mới và nó sẽ cung cấp cơ sở tốt hơn cho công việc thực tế liên quan đến việc thực hiện quá trình chuyển đổi.

Trong một thế giới lý tưởng, tôi đề xuất với khách hàng rằng họ trả tiền cho một nhiệm vụ điều tra để chi trả cho một tháng làm việc đó để cho bạn làm nguyên mẫu những gì bạn làm. Điều đó cho họ lựa chọn tạm dừng và không đi tiếp nếu chi phí quá lớn. VÀ, bạn vẫn được trả tiền cho công việc bạn đã làm.

Chỉ có một cách để có được ước tính hợp lý cho một nhiệm vụ phần mềm. Chỉ định các nhân viên có sẵn để thực hiện một số phần nhỏ nhưng có thể kiểm tra được của nhiệm vụ HOÀN TOÀN và xem mất bao lâu. Chia công việc còn lại thành nhiều trường hợp sử dụng nhất có thể và có cùng một nhân viên ước tính mỗi lần lặp so với công việc đã thực hiện. Đừng yêu cầu họ ước tính thời gian, chỉ cần yêu cầu họ cho bạn biết nó so sánh như thế nào với lần lặp đầu tiên. Điều này sẽ cung cấp cho bạn ước tính tốt nhất có thể cho phần còn lại của dự án.