PTT推薦

[請益] 一份好的設計規劃應該怎麼寫

看板Soft_Job標題[請益] 一份好的設計規劃應該怎麼寫作者
icetofux
()
時間推噓14 推:14 噓:0 →:48

我目前從事販賣機的軟體開發,需求主幹很簡單:

1.用戶選定商品、檢查商品庫存。
2.提示付款、依據使用者付款方式檢查付款是否成功。
3.投放商品。
4.控管存放庫的溫度。

主幹的描述跟流程圖可以很快的寫出來,但問題在於細節的實施,比方說步驟2.,付款方式百百種,而且常常開發到一半就需要增減某種付款方式;又比方步驟4.,不同商品可能有不同的控管邏輯。

只要遇到需求變更,就得修改文件重畫流程圖,導致後來我也養成便宜行事的壞習慣,先把程式寫完,出版後再來按code寫規劃文件。

雖然目前也沒遇到什麼太大的問題,但違背了先畫流程圖跟寫規格書的原則,心裡總是留一根刺。

想向各位先進請教,像這種情形有沒有什麼好的建議或改善方向呢?

謝謝。

--

※ PTT 留言評論
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 223.137.14.208 (臺灣)
PTT 網址

SHANGOYANYI03/10 09:39泳道圖

謝謝,我來查一下這是什麼。

leolarrel03/10 10:40問GPT

abccbaandy03/10 11:09修改規格本來就很平常阿...便宜行事是你們的問題吧?

abccbaandy03/10 11:10不過我也沒碰過的照"規定"走的,一堆出張嘴就改的XD

f2672430903/10 11:25所以你寫的東西最好要有擴充彈性

lazarus112103/10 12:07找一個SA來做,PG兼SA 文件很容易會脫節

lazarus112103/10 12:07寫完code後你會沒動力修文件

lazarus112103/10 12:10或是你只寫文件,讓PG來看文件改這樣

我工作的場合編制沒有這麼齊全,所以工程師被要求從文件到產品都得做。

lazarus112103/10 12:12看能抵擋幾次需求變更而PG還不爆炸XD

DrTech03/10 12:14正常不會先畫流程圖吧,會先寫人與系統互動流程的文字。正

所以流程圖並不是必要的嗎?以前學寫程式都一直被灌輸要先畫出流程圖,再按照流程圖寫程式。

DrTech03/10 12:14式一點的說法是 use case。改文字比改圖方便多了

DrTech03/10 12:16很多圖根本是形式,重點是流程紀錄清楚比較重要。等到專案

DrTech03/10 12:16快結束,或沒事做時,才會根據合規要求,補各種說明文件與

DrTech03/10 12:16圖。

※ 編輯: icetofux (223.137.14.208 臺灣), 03/10/2023 13:08:49 ※ 編輯: icetofux (223.137.14.208 臺灣), 03/10/2023 13:09:49 ※ 編輯: icetofux (223.137.14.208 臺灣), 03/10/2023 13:12:26

MoonCode03/10 13:47好讚喔 是做什麼國家的需求 很好奇

APTON03/10 14:38不考慮狀態圖嗎?

remember6903/10 16:12PM的需求情境跟業務範圍是否完整 設計的範圍才比較

remember6903/10 16:12聚焦

remember6903/10 16:13如果開發只依照你4點的需求主幹往下直接開發 那沒問

remember6903/10 16:13題才是問題吧XD

jackflu03/10 17:31樓上有講跟沒講一樣XD

sp06343903/10 17:35Gherkin

jej03/10 18:15幾百年前的做法供你參考

jej03/10 18:15把需求的use case寫出來

jej03/10 18:16然後畫Active Diagram(就是上面說的泳道圖)

jej03/10 18:16然後再把DFD或是class Diagram畫出

jej03/10 18:16就可以開始coding了

jej03/10 18:16當然有些比較雞巴的地方

jej03/10 18:16會要求你維護sequence Diagram

jej03/10 18:16現在這世代的做法應該也差不多吧

jej03/10 18:23至於需求變更 看你的案子

jej03/10 18:23採用那種軟工手法

jej03/10 18:23若是瀑布式 就要和使用者重談需求 勾稽需求 然後改文件

jej03/10 18:23如果是使用scrum就下一個spint再說了

hegemon03/10 18:30流程圖可以切割,主幹引用到細節

hegemon03/10 18:31例如主幹跑到付款那段的時候,標示說請見付款細節,付款

hegemon03/10 18:31細節那邊有統一的interface的話,你對一種付款模式就是多

hegemon03/10 18:31一個付款模式的細節圖

hegemon03/10 18:32溫度控制那邊也可以看看能不能使用類似的做法,只要主幹

hegemon03/10 18:32跟細節圖之間的關聯讓人可以很快找到的話,適度的切割沒

hegemon03/10 18:32什麼不對

WaterLengend03/10 19:12通常有需求之後我會畫流程圖或活動圖,當作確認需求

WaterLengend03/10 19:12跟文件紀錄

s2994003/10 19:13Mermaid 畫流程圖很方便

GoalBased03/10 23:23你要先找到為什麼你說違背了你的原則,心裡會有刺的背

GoalBased03/10 23:23後真正的原因,再來看怎麼處理

GoalBased03/10 23:26你說的原則是為了什麼,還是只是無意義的個人原則,xy

GoalBased03/10 23:26問題

viper970903/11 00:08修改規格本來就很平常+1

enthos03/11 14:48設計一套DSL(Domain Specific Languages),可用LUA修改

enthos03/11 14:48我個人喜歡這種 https://github.com/zevv/zForth

enthos03/11 14:48文章代碼(AID): #1VclyWaS (CompilerDev) [ptt.cc]

enthos03/11 14:49不同商品對應到不同的 bytecode, 容易更新.

alan310003/11 14:52你舉的例子哪裡需要改流程圖..隨便找個範例改吧

burgess03/12 09:52你的主流程(購買行為)不應該包含副流程(付款方式)的

burgess03/12 09:52內容,副流程自己一張

burgess03/12 09:52這樣就不會一直修改

overhead03/12 22:43你要想why。為什麼該先畫流程圖?為什麼你們想便宜行事

overhead03/12 22:43?在我看來,開發中的設計草稿和發行時的定稿是兩件事

overhead03/12 22:43,前者重修改效率,後者重後人的易理解性。前者挑順手

overhead03/12 22:43的工具畫個內部人能釐清的圖,發行時再花心思讓圖變成

overhead03/12 22:43標準圖。