ฉันเคยเรียนหลักสูตรการออกแบบซอฟต์แวร์มาบ้างในช่วงสองสามภาคการศึกษาที่ผ่านมาและในขณะที่ฉันเห็นประโยชน์ของการทำพิธีการมากมายฉันรู้สึกว่ามันไม่ได้บอกอะไรเกี่ยวกับโปรแกรมเอง:
- คุณไม่สามารถบอกได้ว่าโปรแกรมจะทำงานอย่างไรจาก Use Case spec แม้ว่าจะกล่าวถึงสิ่งที่โปรแกรมสามารถทำได้
- คุณไม่สามารถบอกอะไรเกี่ยวกับประสบการณ์การใช้งานของผู้ใช้จากเอกสารข้อกำหนดแม้ว่ามันจะรวมถึงข้อกำหนดด้านคุณภาพ
- ลำดับไดอะแกรมเป็นคำอธิบายที่ดีว่าซอฟต์แวร์ทำงานเป็น call stack อย่างไร แต่มีข้อ จำกัด มากและให้มุมมองบางส่วนของระบบโดยรวม
- คลาสไดอะแกรมเหมาะอย่างยิ่งสำหรับการอธิบายวิธีการสร้างระบบ แต่ไร้ประโยชน์อย่างเต็มที่ในการช่วยให้คุณทราบว่าซอฟต์แวร์จำเป็นต้องมีอะไรบ้าง
ซึ่งในพิธีการทั้งหมดนี้คือสิ่งที่สำคัญที่สุด: โปรแกรมมีลักษณะอย่างไรดำเนินการและมีประสบการณ์อย่างไร มันไม่สมเหตุสมผลเลยหรือที่จะออกแบบจากนั้น? มันจะดีกว่าหรือไม่ที่จะเข้าใจว่าโปรแกรมควรทำงานผ่านต้นแบบและพยายามนำไปใช้จริงหรือไม่?
ฉันรู้ว่าฉันอาจเป็นทุกข์จากการสอนวิศวกรรมโดยนักทฤษฎี แต่ฉันต้องถามพวกเขาทำสิ่งนี้ในอุตสาหกรรมหรือไม่ ผู้คนจะทราบได้อย่างไรว่าโปรแกรมคืออะไรไม่ใช่สิ่งที่ควรจะเป็น ผู้คนต้นแบบมากหรือพวกเขาส่วนใหญ่ใช้เครื่องมือทางการเช่น UML และฉันก็ยังไม่ได้ใช้
2
จากการอ่านของฉันดูเหมือนว่าคุณจะมุ่งเน้นไปที่ส่วนต่อประสานผู้ใช้ของการพัฒนาซอฟต์แวร์ ต้นแบบนั้นยอดเยี่ยมสำหรับการพัฒนาและปรับแต่ง UIs ไม่มากนักสำหรับการไขตรรกะหลัก (หรือแม้แต่การค้นหาว่าตรรกะทางธุรกิจที่คุณควรจะนำไปปฏิบัตินั้นคืออะไร)
—
Anon
หากมีผู้ใช้ที่เป็นมนุษย์มักจะมี GUI GUI ที่มีหน้าตาเป็นอย่างไรและมีประสิทธิภาพอย่างไรจะส่งผลต่อการออกแบบของระบบทั้งหมด
—
งาน