Giải pháp phần mềm từ những năm 2000, tôi có nên cố gắng vá hoặc làm lại toàn bộ không?

Tôi đã được gửi đi để thảo luận về một hệ thống mà một công ty nào đó hiện đang sử dụng và những gì nên được thực hiện với nó.

Công ty sản xuất màn hình carton khác nhau. Hệ thống này được phát triển để theo dõi khách hàng, đơn đặt hàng và giá cả. Rất nhiều điều đã xảy ra kể từ khi hệ thống được tạo ra và hệ thống hiện tại, như người quản lý mô tả, " bị khóa " và " có vấn đề ", mà tôi dịch là "không động" và "không ổn định".

Một số thông tin về hệ thống

• Nó được phát triển vào khoảng năm 2000
• Hệ thống khá nhỏ, 2-5 người dùng, 6 biểu mẫu, ~ 8 bảng với số lượng dữ liệu trung bình
• Được xây dựng trên Visual Basic sớm, các biểu mẫu được tạo với thiết kế kéo và thả. Giao diện về cơ bản chỉ là một cửa sổ với một menu và một số hình thức
• Sử dụng cơ sở dữ liệu MSSQL (máy chủ SQL2005) để lưu trữ dữ liệu và trình điều khiển ODBC để truy vấn, dữ liệu đã được di chuyển từ excel trước hệ thống này và trước khi excel được xử lý, tính toán và viết bằng tay và giấy
• Người dùng làm việc trong môi trường Microsoft XP (trở lên)

Vấn đề chính của họ là họ không thể điều chỉnh và tính giá, không thể thêm các loại thùng carton mới, v.v., vì họ không thể (hay đúng hơn là họ không biết cách) chạm vào dữ liệu trên máy chủ.

Tôi đề nghị 3 giải pháp khả thi

1. Cố gắng vá hệ thống hiện tại
2. Tạo giao diện mới (tốt nhất là môi trường tương tự, dựa trên VB.net hoặc VB)
3. Đưa nó trở lại một giải pháp Excel, coi đó là một hệ thống nhỏ như vậy

Có thể có nhiều lựa chọn hơn, nhưng đây là những lựa chọn tôi có thể nghĩ ra.

Câu hỏi của tôi là

• Tôi nên giới thiệu cái gì và tại sao?
• Những gì là hoặc có thể là ưu và nhược điểm của các lựa chọn thay thế?
• Có những lựa chọn khác (có thể tốt hơn)?

Một cái gì đó chỉ có 6 hình thức và như vậy sẽ dễ dàng được xây dựng lại trên một khung hiện đại hơn. Tôi đã làm việc với việc di chuyển các dự án VB6 có khoảng 200 biểu mẫu cùng với hàng chục lớp và bảng cơ sở dữ liệu. Nghe có vẻ như bạn đang nhìn vào bất cứ thứ gì lộn xộn nhưng ngoại hình có thể bị đánh lừa.

Tôi phải phân tích mã, cơ sở dữ liệu và các yêu cầu nghiệp vụ để nói nếu viết lại hoặc tái cấu trúc cơ sở mã hiện tại là tốt nhất. Đưa ra những gì bạn đã nói, tôi nghiêng về viết lại. Nhưng, có thể có những khó khăn tiềm ẩn mà bạn không thấy ngay bây giờ.

Tôi có lời khuyên hơi khác nhau hầu hết các câu trả lời cho đến nay.

Cố gắng vá hệ thống hiện tại

Ít nhất tôi sẽ học được hệ thống hiện tại đủ tốt để giải thích cho khách hàng cách sử dụng nó. Tôi sẽ dành thời gian này để giải thích những sai sót trong hệ thống hiện tại của họ, tránh những từ tiêu cực, chỉ nói với họ những gì nó không thể làm được ngay cả khi tất cả các lỗi đã biết đã được sửa.

Tạo giao diện mới (tốt nhất là môi trường tương tự, dựa trên VB.net hoặc VB)

Sau khi bạn đã học mọi thứ bạn có thể với thiết lập hiện tại của họ. Cung cấp cho họ các tùy chọn, nếu bạn có thể giải quyết mối quan tâm của họ với hệ thống hiện tại của họ, thực sự không có gì sai với hệ thống hiện tại của họ. Tất nhiên mối quan tâm duy nhất là hỗ trợ Visual Basic 6 có thể không tồn tại trong 5 năm.

Một mối quan tâm khác là cách nó giao tiếp với cơ sở dữ liệu. Microsoft đang dần loại bỏ một số cách cũ hơn để giao tiếp với các sản phẩm cơ sở dữ liệu của mình (Access, MSSQL) để cách bạn tương tác với các sản phẩm đó sẽ xác định xem giải pháp có thể được sử dụng trên Windows 9 và Windows 10 trong tương lai hay không.

Câu trả lời này hoàn toàn phụ thuộc vào thực tế họ có nguồn cho ứng dụng. Nếu họ không có nguồn thì sẽ khó giải quyết mối quan tâm của họ, sửa các lỗi lớn hiện tại hoặc thậm chí biến nó thành một công cụ mà họ thực sự có thể sử dụng.

Tôi không cảm thấy có gì "sai" với ứng dụng Visual Basic 6, ngoài thực tế, sự hỗ trợ của nó cho các phiên bản trong tương lai vẫn chưa được biết. Ngay cả ngày nay với các hệ điều hành Windows 7 và 64 bit, nó ngày càng khó hỗ trợ hơn. Đây là một lý do chính khiến việc viết lại thành ngôn ngữ hiện đại với sự hỗ trợ 64 bit phù hợp có thể là một ý tưởng tốt.

Nếu họ không có nguồn tại thời điểm đó thì viết lại thực sự là giải pháp duy nhất của họ.

Viết lại giao diện là một lựa chọn tuyệt vời, với điều kiện là hệ thống tương đối nhỏ. Ưu điểm là -

1. Cải thiện sự ổn định (giả sử bạn làm tốt!)
2. Cải thiện khả năng bảo trì
3. Giao diện hiện đại

Nhược điểm chính là nó có thể vẫn sẽ tốn kém hơn một chút so với việc hack mã hiện có.

Tôi cũng có xu hướng viết lại, nhưng bạn cần chắc chắn 100% rằng bạn hiểu đầy đủ chức năng hiện tại cũng như bất kỳ chức năng nào bị hỏng, thiếu hoặc không đầy đủ. Hai cái sau rất quan trọng khi bạn đề cập đến việc điều chỉnh và tính giá. Bạn có hiểu đầy đủ hậu quả của việc thêm tính năng này?

Tôi đã từng làm việc trên cái được cho là "trang web", nhưng thực tế là đã sử dụng một công cụ kiểu CRM dựa trên Access tùy chỉnh từ cuối những năm 1990 và đưa nó vào thế giới hiện đại, dựa trên web. Nhà phát triển ban đầu đã mất từ ​​lâu, Cơ sở dữ liệu đã được sửa đổi nhiều lần, tài liệu gốc đã lỗi thời và không ai thực sự hiểu hệ thống hoạt động như thế nào. Nhưng họ biết cách sử dụng nó, chỉ. Có lẽ 80% ngân sách cho dự án này đã đi vào ba điều:

• thu thập yêu cầu
• hiểu hệ thống hiện tại
• đưa ra một lược đồ cơ sở dữ liệu đầy ý nghĩa cho cách họ dự định sử dụng phần mềm

Dự án này, về mặt tài chính, không thành công!

Một lựa chọn khác có thể là một sự thỏa hiệp giữa việc viết lại toàn bộ và hack ứng dụng hiện có.

Cung cấp cho họ chức năng mới trong một ứng dụng mới được xây dựng từ đầu.

Điều này có khả năng có thể dễ dàng hơn để làm, và không tốn nhiều chi phí như viết lại đầy đủ.

Một khi điều này đã được thực hiện và họ rất vui khi họ có thể thêm / cập nhật dữ liệu, nó sẽ mở ra doot ro một giai đoạn hai có thể thay thế chức năng hiện tại trong ứng dụng mới.

Đây có thể là một cách tiếp cận hợp lý hơn.

Viết lại thường có xu hướng hết ngân sách ... Thật tệ.

Nhưng có một bộ xương hiện đại cho ứng dụng, có thể là một khoản đầu tư tốt, đặc biệt là nếu không ai biết hệ thống cũ hoạt động như thế nào và nếu mọi thứ bị hỏng ngay khi bạn bắt đầu chạm vào chúng.

Ngoài ra, VB6 là xấu cho hỗ trợ. Khi bạn cần tìm chuyên gia trong 10 năm, điều đó sẽ khá khó khăn.