Sự khác biệt giữa một nguyên mẫu và một giải pháp mức sản xuất là gì?

Câu hỏi này hoàn toàn dành cho việc học và nâng cao hiểu biết kỹ thuật của tôi. Tôi biết không có giải pháp hoàn hảo và câu hỏi này có thể không bao giờ kết thúc danh sách giải pháp nhưng tôi nghĩ mọi kiến ​​trúc sư đều hiểu được sự khác biệt giữa bản demo và dự án trực tiếp.

Tôi đã tạo ra nhiều giải pháp demo trong .Net trong quá khứ. Bây giờ tôi đã được giao cho kiến ​​trúc sư và thực hiện một giải pháp web mức sản xuất vì vậy tôi muốn hỏi - ở mức độ rất cao, những gì cần thiết để chuyển đổi một bản demo thành một giải pháp cấp độ sản xuất. Theo hiểu biết của tôi, điều này sẽ yêu cầu (ngoài chức năng thực hiện các yêu cầu của khách hàng):

1. Đơn vị kiểm tra mọi phương pháp
2. Đảm bảo đạt được phạm vi bảo hiểm mã 100%
3. Ghi nhật ký tất cả các trường hợp ngoại lệ và các điểm cắt có thể - có thể với AOP
4. Sử dụng mẫu thiết kế giao diện, nội xạ phụ thuộc, có thể bằng cách sử dụng khung, ví dụ spring.net
5. Sử dụng bộ đếm hiệu suất và hồ sơ cho các thiết bị
6. Áp dụng bảo mật thích hợp - tức là xác thực windows (nếu đó là những gì khách hàng yêu cầu).
7. Quản lý giao dịch trên mọi phương thức
8. Sao lưu các tệp ứng dụng web trước khi triển khai giải pháp mới

Còn gì nữa không

Câu hỏi của tôi liên quan nhiều hơn đến khía cạnh kỹ thuật thay vì chức năng / tài liệu vì nếu không chúng tôi sẽ đi vào một con đường khác :-)

Cảm ơn bạn.

Tôi nghĩ rằng sự khác biệt quan trọng nhất là mục tiêu của nguyên mẫu là:
1. Để chứng minh rằng một vấn đề có thể được giải quyết theo một cách nào đó HOẶC
2. Tạo cho khách hàng / quản lý cảm nhận về sản phẩm sẽ như thế nào và cảm thấy như thế nào

trong khi mục tiêu của một hệ thống sống là:
1. Để giải quyết một vấn đề / giải quyết một vấn đề nào đó.

Lưu ý rằng các mục tiêu của hai là hoàn toàn khác nhau .
Do đó, theo tôi một nguyên mẫu nên được vứt đi trước khi phát triển một hệ thống sống .

Điều này cũng là do một nguyên mẫu thường là một dự án 'nhanh và bẩn', được kết hợp với nhau mà không có bất kỳ cân nhắc nào mà bạn đã chỉ ra trong câu hỏi của mình (như kiểm tra, hiệu suất, bảo mật và nhiều hơn nữa).
Vì vậy, bạn nên bắt đầu một dự án mới, phù hợp hơn là cố gắng làm cho một dự án tồi trở nên tốt hơn.

Không phải tất cả những điều đó là bắt buộc, tùy thuộc vào yêu cầu của bạn, hoặc có thể có nhiều cách hơn. Nếu bạn biết ý tôi là gì;) Kiểm thử đơn vị và bảo hiểm mã là những điều tốt, nhưng tùy thuộc vào cách bạn đi về các phần khác của quy trình, có thể không bắt buộc. Một số người sẽ nói rằng quan trọng hơn hồ sơ hiệu suất là mã tài liệu tốt, hoặc một hướng dẫn đào tạo. Nó thay đổi!

Tôi nhận ra bạn đang nhìn vào khía cạnh kỹ thuật nhưng hy vọng bạn sẽ hiểu quan điểm của tôi, nó thay đổi tùy thuộc vào khía cạnh phi kỹ thuật. Hoặc ít nhất nó phải.

Sử dụng bộ đếm hiệu suất và trình biên dịch cho thiết bị .. có thể phù hợp, nhưng có thể là quá mức cần thiết. Có thể không được yêu cầu.

Những gì bạn đang thiếu ở đây là không tính đến bối cảnh, phạm vi và yêu cầu kinh doanh của dự án.

Theo ngữ cảnh và phạm vi tôi muốn nói - bạn đang tạo ra thứ gì đó để sử dụng nội bộ bởi một doanh nghiệp? Đối mặt với khách hàng? Được sử dụng bởi người dùng cuối? Trên thực tế, đây là phiên bản vui nhộn của Notepad hay RDBMS mới từ đầu? Những gì nên được bao gồm sẽ thay đổi ồ ạt (ồ ạt!) Theo dự án bạn đang xem xét.

Theo yêu cầu kinh doanh, tôi không có nghĩa là các trường hợp sử dụng cho phần mềm, mà là các yêu cầu của quy trình sản xuất / quản lý dự án. Nếu bạn khẳng định rằng bạn cần tất cả những điều đó cho một dự án sản xuất, chi phí sẽ được phản ánh tương ứng (rất cao). Điều đó có thể có nghĩa là nó vượt quá ngân sách, muộn hoặc thậm chí không được bật đèn xanh để bắt đầu phát triển.

Điều quan trọng hơn là có một bộ tiêu chí cố định bây giờ chỉ đơn giản là có khung sản xuất / phát triển tốt, khả năng hiển thị cao và phát hành thường xuyên để chất lượng có thể được đánh giá theo cách đó. Nó có thể là không ai liên quan đưa ra một tào lao về bảo hiểm mã.

Thật thú vị, tôi nghĩ rằng các điểm 1, 2, 4 và 7 nên được thực hiện trong quá trình hình thành nguyên mẫu của bạn, ngoại trừ việc tôi không nghĩ bạn nên thử nghiệm mọi phương pháp trong mỗi lớp. Kiểm tra mã quan trọng, không xem các phương thức get / set có hoạt động chính xác không.

Tùy thuộc vào mục đích của ứng dụng của bạn, nơi bảo mật là một vấn đề lớn, điểm 6 có thể đủ quan trọng để bạn cần đạt được nó trong nguyên mẫu. Tùy thuộc vào mục đích của ứng dụng của bạn, trong đó hiệu suất là chìa khóa, điểm 5 có thể rất quan trọng ... Bạn biết ý tôi là gì. Ý kiến ​​của tôi là các điểm 3, 5 và 6 có thể cần thiết trong nguyên mẫu nếu chúng được coi là quan trọng (điểm 8 thực sự hợp lệ cho các ứng dụng sản xuất)

Chỉnh sửa: có vẻ như ý kiến ​​của tôi khác hoàn toàn với sJhonny vì tôi ngụ ý rằng tôi coi nguyên mẫu là cơ sở / vỏ / bộ xương cho sự phát triển trong tương lai của bạn, vì vậy đối với tôi nguyên mẫu không bị vứt bỏ.

Ngoài những gì đã được đề cập, trong một dự án sản xuất, bạn cần có những điều sau đây (trong số những dự án khác):

0-Chọn một phương pháp thực hiện

1-Hoàn thiện và xuất bản các yêu cầu chính (bao gồm cả các trường hợp sử dụng, v.v.)

2-Nhận kiến ​​trúc đúng

3-Chọn các công cụ chính xác

4-Thiết kế cơ sở dữ liệu cho hiệu suất

5-Sản xuất thiết kế lớp học và thiết kế quy trình công việc của bạn

6-Xác định và thực hiện chiến lược tích hợp cơ sở dữ liệu / nguồn dữ liệu / nguồn cấp dữ liệu được hỗ trợ

7-Xác định và thực hiện các yêu cầu bảo mật

8-Sắp xếp để thực hiện vật lý (Máy chủ, kết nối, giấy phép, v.v.)

9-Kế hoạch cho các yêu cầu lưu trữ và xác định các biện pháp hiệu suất

10-Sản xuất tất cả các tạo tác và cài đặt trong môi trường sản xuất

11-Kiểm tra

12-Đưa ra giải pháp cuối cùng và thực hiện phản hồi

Tính năng quan trọng nhất của các giải pháp chất lượng sản xuất là - theo tôi - mạnh mẽ .

Bất kể điều gì xảy ra, giải pháp xử lý tình huống hợp lý, thông báo cho những người cần biết và tiếp tục (nếu lỗi có thể phục hồi được).

Có hai loại nguyên mẫu:

• Các ứng dụng "bằng chứng khái niệm" nhanh và bẩn được "dọn sạch" và trở thành mã sản xuất. Giai đoạn "dọn dẹp" có xu hướng hoặc là một cơn ác mộng, hoặc nó thực sự là một giai đoạn "quét các vấn đề dưới tấm thảm", dẫn đến nợ kỹ thuật lớn.

• Nguyên mẫu "Mockup" hoặc "khung lưới". Đây có thể là bản phác thảo UI bằng giấy và bút chì, hoặc thậm chí là các mockup tương tác được thực hiện bằng ngôn ngữ mà bạn có thể nhanh chóng ném loại công cụ này lại với nhau mà không cần suy nghĩ nhiều về cách nó khớp với nhau. Nó nên sử dụng dữ liệu giả, không có kiến ​​trúc thực, v.v. Vấn đề là họ cung cấp cho các bên liên quan ý tưởng về hệ thống sẽ như thế nào, để bạn có thể tinh chỉnh các yêu cầu của mình, nhưng chúng không thể được sử dụng như một phần của giải pháp cuối cùng của bạn .

Tôi thích loại thứ hai. Họ bị ném ra ngoài, vì thực sự không có lựa chọn nào khác.

Tôi nói xây dựng nó giống như một dự án không có bản demo, nhưng bây giờ bạn có thể bao gồm những gì bạn đã học được từ bản demo trong thiết kế của mình. Mã hóa ban đầu có thể xấu ngay cả khi bạn bắt đầu sản xuất. Dù sao bạn cũng sẽ phải cấu trúc lại phần lớn.

Vấn đề thực sự cần giải quyết là thời gian của bạn. Khi những người ra quyết định muốn bạn tiếp tục làm việc trên bản demo, họ sẽ cảm thấy rằng phần lớn ứng dụng đã sẵn sàng, do đó sẽ không mất nhiều thời gian. Tôi đã nghe người khác sử dụng logic này về lý do tại sao họ thích hiển thị bản phác thảo cho khách hàng thay vì các bản nháp quá thực tế. Hãy chú ý đến mã demo vì nó có thể đã phát hiện ra các vấn đề bạn chưa từng nghĩ đến và có lẽ không có tài liệu trong quy trình này. Bây giờ bạn phải xem xét chúng (Đơn giản hóa quá mức, nhưng vâng, cơ sở dữ liệu có thể không truy cập được chẳng hạn.).

Tất cả các nguyên mẫu và bản demo không được tạo ra bằng nhau. Toàn bộ mã có thể là vô giá trị hoặc một số phần nhất định có thể đã được thực hiện rất tốt. Không thành vấn đề nếu đó là bản demo bạn phải biết sự khác biệt. Bạn sẽ không ném ra một ứng dụng leglists và bắt đầu lại chứ? Quên tôi hỏi.