Bạn đã bao giờ thiết kế phần mềm bằng cách hình dung ra giải pháp lý tưởng chưa?

Question

Tôi thấy bản thân mình làm điều này và tôi tự hỏi liệu người khác có làm việc như thế này không:

Điều tôi thường làm khi đối mặt với vấn đề thiết kế phần mềm là tôi ghi lại giải pháp "lý tưởng" tính khả thi hoặc bất kỳ sự cân nhắc nào khác. Sau đó, tôi bóc vỏ nó từ trên xuống, cho đến khi tôi có giải pháp.

Đó có phải là phương pháp phổ biến và có tên dễ nhớ không? Nếu vậy, tôi rất muốn biết để tôi có thể tìm hiểu thêm về nó.

Answer 1

Phần mềm xây dựng từ điểm trải nghiệm là cách tốt nhất để đi.

Phát triển tầm nhìn, đặt trường hợp sử dụng, tạo danh sách tính năng từ những trường hợp đó, ưu tiên về giá trị bạn sẽ nhận được để xây dựng chúng, sau đó tạo theo mức độ ưu tiên đó.

Điều này giúp thực hiện là xây dựng các tính năng có giá trị cao tất cả các thời gian trong khi di chuyển theo hướng giải pháp lý tưởng, nơi một số tính năng chỉ có thể được sử dụng bởi một nhóm nhỏ người dùng

Answer 2

Có, nó được gọi là top-down design. :)

Answer 3

Ở một trong số cũ sách phân tích/thiết kế của mình (không thể nhớ được và không yêu Google), họ đã giới thiệu khái niệm "không có bộ lọc công nghệ" nơi bạn nghĩ về thực tế mục tiêu và suy nghĩ về giải pháp lý tưởng. Nó rất, rất giống với những gì bạn đang nói đến. Sản phẩm cuối cùng có thể không có nhiều điểm tương đồng với giải pháp lý tưởng do công nghệ hiện tại, nhưng biết lý tưởng có nghĩa là khi các phần mới có sẵn, bạn có thể dễ dàng đánh giá thiết kế hiện tại của mình có thể được cập nhật để tận dụng chúng như thế nào. Ngược lại với chỉ biết vấn đề và giải pháp về những gì bạn có thể xây dựng ngày hôm nay. Nhìn xung quanh và tìm thấy một số phần mềm đã phải vật lộn để thực hiện chuyển đổi sang công nghệ mới và bạn có thể thấy điều này đang hoạt động. Hãy suy nghĩ về lý tưởng!

Answer 4

Khi tôi thiết kế chương trình, trước tiên tôi thiết kế giao diện người dùng bằng cách tạo mẫu giấy. Tôi kiểm tra nguyên mẫu giao diện người dùng mà người dùng có thể đạt được mục tiêu của họ với nó. Có thứ gì đó cụ thể/hiển thị để hiển thị cho người dùng và khách hàng giúp bạn dễ dàng khám phá các yêu cầu và tìm hiểu những gì người dùng thực sự cần.

Trong giai đoạn thiết kế giao diện người dùng (phân tích yêu cầu), tôi luôn cố gắng thiết kế giải pháp lý tưởng. Tôi không xem xét rằng một số tính năng khó có thể thực hiện được. Sau đó, khi thiết kế đã ổn định đủ để được thực hiện (thường phải mất một hoặc hai tuần), chúng tôi thảo luận với khách hàng và các lập trình viên về việc phải mất bao nhiêu để thực hiện những thứ và điều quan trọng nhất. Vì chúng tôi lần đầu tiên thiết kế giải pháp lý tưởng, chúng ta có thể thấy toàn bộ bức tranh về những gì cần thiết, và chúng ta có thể bắt đầu điều chỉnh phạm vi của dự án, do đó chỉ có những tính năng quan trọng nhất mới được triển khai. Ngoài ra nếu một số thiết kế giao diện người dùng lý tưởng sẽ quá tốn kém để triển khai, chúng tôi có thể tạo ra một thiết kế bị xâm phạm có khả năng sử dụng thấp hơn một chút, nhưng sẽ rẻ hơn nhiều để triển khai. Nhà thiết kế UI luôn là người thiết kế sự thỏa hiệp (nghĩa là không phải là người lập trình), để nó đáp ứng tất cả các yêu cầu và khả năng sử dụng của nó sẽ đủ tốt.

Answer 5

Đây là nhiều hơn hoặc ít hơn những gì tôi làm, trong lập trình và trong cuộc sống. Thông thường, tôi nghĩ về cách người dùng sẽ cần sử dụng phần mềm mới. Tay họ đâu rồi. Những thứ khác mà họ sử dụng để thực hiện công việc (điện thoại, cửa sổ trình duyệt khác). Theo thứ tự thông tin sẽ đến với họ, và thứ tự đó sẽ ảnh hưởng như thế nào đến các công cụ mà phần mềm của tôi cung cấp mà họ cần.

Answer 6

Trong khoa học/số tính toán điểm khởi đầu của bạn là luôn luôn một số lý tưởng toán học, nhưng sau đó bạn phải thỏa hiệp rằng lý tưởng để có được một giải pháp có thể sử dụng thực tế.