PTT職涯區 / Soft_Job (軟體人)

[請益] UML對不同工作的必要性

看板Soft_Job (軟體人)作者 (沒有存在感的人)時間9年前 (2016/10/09 00:23), 編輯推噓20(20推 0噓 159→)
留言179則, 24人參與, 最新討論串1/1
UML據我最近有限的study看來算是軟體的設計圖。 (如果有錯請小力鞭，我只研究了兩三天) 主要由SA負責將客戶的需求用UML的方式具象化， 就像是建築師畫設計圖一樣。 那請問SD跟SE對於UML的了解程度該到多少呢？ 就像建築工自己不會畫設計圖，但是可以照著設計圖來做這樣？ （不太懂SD跟SE的分工就是） 感謝解惑。 -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 90.41.170.137 ※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1475943832.A.681.html
→
10/09 00:25, , 1F
設計圖通常是事後才做好的東西(無誤)
10/09 00:25, 1F
→
10/09 00:28, , 2F
那請問沒有設計圖是要怎麼跟客戶溝通？
10/09 00:28, 2F
推
10/09 00:29, , 3F
溝通也是事後才要做的事情(無誤)
10/09 00:29, 3F
→
10/09 00:30, , 4F
溝通完如果才知道跟客戶要求差很多那工程師不是嘔死？
10/09 00:30, 4F
→
10/09 00:33, , 5F
user story 寫好寫滿比較實在啊.
10/09 00:33, 5F
→
10/09 00:34, , 6F
UML要也是給對方SA看, 不會直接跟end user用這講
10/09 00:34, 6F
→
10/09 00:34, , 7F
現在一些老師就提倡迭代方式阿, 反正都會有爭議不如就縮短
10/09 00:34, 7F
推
10/09 00:34, , 8F
我跟user溝通都是用Prototyping
10/09 00:34, 8F
→
10/09 00:34, , 9F
每個周期, 要錯也不會錯太大
10/09 00:34, 9F
→
10/09 00:35, , 10F
那爆肝工程師要做出來不是也是看UML嗎？
10/09 00:35, 10F
→
10/09 00:36, , 11F
而且user往往也不知道自己真的要什麼, 翻盤不見得是溝通出錯
10/09 00:36, 11F
→
10/09 00:37, , 12F
沒有吧, SA給你什麼你就看什麼
10/09 00:37, 12F
→
10/09 00:37, , 13F
SA也不見得想畫這個, 除非案子要交付UML圖
10/09 00:37, 13F
→
10/09 00:39, , 14F
而且工程師看UML圖就做得出來系統? 頂多了解系統架構吧
10/09 00:39, 14F
→
10/09 00:39, , 15F
可是不給UML的話SA要怎麼有系統的叫工程師寫程式？
10/09 00:39, 15F
→
10/09 00:40, , 16F
SA兼SD的人就直接用html或是excel畫畫面, 功能簡單寫寫
10/09 00:40, 16F
→
10/09 00:41, , 17F
table 欄位寫夠詳細跟正確
10/09 00:41, 17F
→
10/09 00:42, , 18F
我自己的理解是SA是把程式該有的功能全列出來(列出必要
10/09 00:42, 18F
→
10/09 00:42, , 19F
公司要求更多的就會再加寫sudo code, 讓溝通更容易
10/09 00:42, 19F
→
10/09 00:43, , 20F
的函式)，然後SD負責系統或介面，SE把SA要的函式依照
10/09 00:43, 20F
→
10/09 00:43, , 21F
SD的設計寫出來，這樣有無理解錯誤？
10/09 00:43, 21F
推
10/09 00:47, , 22F
依照你說的這個流程, 哪一段非用UML不可?
10/09 00:47, 22F
→
10/09 00:48, , 23F
所以最後就都省掉了, 除非有人要求才去畫
10/09 00:48, 23F
推
10/09 01:06, , 24F
user不知道但SASD要知道吧，什麼都不清楚下去做當然翻
10/09 01:06, 24F
→
10/09 01:07, , 25F
盤
10/09 01:07, 25F
→
10/09 01:45, , 26F
可是一般來說user不知道怎麼定義很正常阿，好的SA
10/09 01:45, 26F
→
10/09 01:46, , 27F
不是應該藉由溝通引導user好好定義spec?
10/09 01:46, 27F
→
10/09 01:46, , 28F
我看了一些uml教學都說他的作用就是類似建築設計圖
10/09 01:46, 28F
→
10/09 01:47, , 29F
或ikea賣的組合櫃的組合說明，就是給工程師照著做的
10/09 01:47, 29F
→
10/09 01:48, , 30F
做出這種軟體設計圖不就是SA的工作？
10/09 01:48, 30F
→
10/09 06:45, , 31F
use case, class, sequence diagram這三個學好。
10/09 06:45, 31F
推
10/09 07:52, , 32F
UML規劃得好的確寫code會比較快，但需求常常變的話很麻煩
10/09 07:52, 32F
推
10/09 10:49, , 33F
同意ptt大的那三張圖 另外本來就沒一定要UML才能定義spec
10/09 10:49, 33F
推
10/09 10:52, , 34F
我好像沒畫過UML，也沒看過哪個architect畫UML...
10/09 10:52, 34F
→
10/09 10:52, , 35F
基本上"由architect設計，再給engineer實做"這點就是傳統
10/09 10:52, 35F
→
10/09 10:53, , 36F
waterfall思維，如果比較走Agile的，應該就是user story
10/09 10:53, 36F
→
10/09 10:53, , 37F
寫好，溝通一下，真正實做細節是engineer在做story時再去
10/09 10:53, 37F
→
10/09 10:54, , 38F
弄出來，通常在planning meeting會先過一遍，有問題這時
10/09 10:54, 38F
→
10/09 10:54, , 39F
就可以溝通，之後做到一半有問題還是可以溝通
10/09 10:54, 39F
還有 100 則推文
→
10/11 21:23, , 140F
生過什麼大大小小的戰爭，只有你自己知道 XD
10/11 21:23, 140F
→
10/11 21:25, , 141F
因為這些不可見，旁人難以模仿，會成為 SA/SD 的實力差。
10/11 21:25, 141F
→
10/11 21:36, , 142F
講白了，敏捷開發法就是當初高手們覺得 RUP 這些古典方法
10/11 21:36, 142F
→
10/11 21:37, , 143F
太繁瑣笨重緩慢，他們想要變得輕巧迅捷所以簡化流程。
10/11 21:37, 143F
→
10/11 21:38, , 144F
但是在加速猛衝的時候，遇到困難，因為他們曾經慢慢爬過
10/11 21:38, 144F
→
10/11 21:39, , 145F
，所以把速度降下來 (回到舊方法從基礎思考) 就解了。
10/11 21:39, 145F
→
10/11 21:40, , 146F
但是對於從一開始就只懂快速衝刺，遇到問題也沒辦法減速
10/11 21:40, 146F
→
10/11 21:41, , 147F
(也就是缺乏基礎)，那也只能一頭撞上障礙物死掉而已 XD
10/11 21:41, 147F
→
10/11 21:45, , 148F
有機會你可以觀察一下，當客戶丟一句要把什麼改成什麼的
10/11 21:45, 148F
→
10/11 21:46, , 149F
時候，這兩類型表現出來的樣子可說是大不相同。
10/11 21:46, 149F
→
10/11 21:49, , 150F
因為這個時候流程大都迭代過幾次，就算是 porgrammer 也
10/11 21:49, 150F
→
10/11 21:49, , 151F
很容易看破 SA/SD 的手腳，會直接感受到他們是不是假會。
10/11 21:49, 151F
→
10/11 22:15, , 152F
可是就算全知道好了，還是要有一定的溝通技巧才能引導user
10/11 22:15, 152F
→
10/11 22:15, , 153F
詳細說出自己想要的(大部份user沒全局觀)
10/11 22:15, 153F
→
10/11 22:16, , 154F
這點沒錯好底下的人就會被不斷變更的spec累死
10/11 22:16, 154F
→
10/11 22:17, , 155F
(我吃虧的就是這點，看來很難成為好SA，只好走SD/SE)
10/11 22:17, 155F
→
10/11 22:22, , 156F
user 會有才奇怪，但溝通絕對不是用 UML 跟 user 溝通啊
10/11 22:22, 156F
→
10/11 22:26, , 157F
其實談需求有點超過 SA 範圍，但是國內都混在一起。
10/11 22:26, 157F
→
10/11 22:26, , 158F
有涉獵過正規的需求工程相關知識嗎？
10/11 22:26, 158F
→
10/11 22:30, , 159F
可是要先跟user溝通才生的出UML(部份)阿
10/11 22:30, 159F
→
10/11 22:30, , 160F
需求是PM還是SA該去談？
10/11 22:30, 160F
→
10/11 22:31, , 161F
有個公司會有 RA 這個職位，帶著 SA 一起去談。
10/11 22:31, 161F
→
10/11 22:32, , 162F
title 可能是需求分析師之類，但不常見。
10/11 22:32, 162F
→
10/11 22:32, , 163F
一般都併入 SA 的職務裡了。
10/11 22:32, 163F
→
10/11 22:32, , 164F
有的公司 第一句打錯 XD
10/11 22:32, 164F
→
10/11 22:33, , 165F
感覺你要補的是 requirements elicitation 和 validation
10/11 22:33, 165F
→
10/11 22:33, , 166F
這塊知識，但不確定你有沒有學過。
10/11 22:33, 166F
→
10/11 22:34, , 167F
我沒有學過，半路出家非資工管出生
10/11 22:34, 167F
→
10/11 22:35, , 168F
那先從第一線退下來補知識也好，這個急不來。
10/11 22:35, 168F
→
10/11 22:38, , 169F
要讓 user 嘴裡吐出幾個有用句子光靠國語課本是天方夜譚
10/11 22:38, 169F
→
10/11 22:39, , 170F
感謝分享，不過好像愈來愈複雜了@@
10/11 22:39, 170F
→
10/11 22:40, , 171F
我自己也曾站在user的立場過，真的很難講出有用的句子
10/11 22:40, 171F
→
10/11 22:40, , 172F
真要做的好搞不好得練chat skill @@
10/11 22:40, 172F
→
10/11 22:41, , 173F
跟SA比起來，SD跟SE比較需要跟有跡可循的機器跟code搞
10/11 22:41, 173F
→
10/11 22:41, , 174F
單純太多了....
10/11 22:41, 174F
→
10/11 22:43, , 175F
chat skill 太抽象，可以先參考既有方法論，再發展出當下
10/11 22:43, 175F
→
10/11 22:43, , 176F
公司跟團隊可以接受的形式出來。
10/11 22:43, 176F
推
10/12 07:04, , 177F
T大高手啊！整個流程描述的好清晰
10/12 07:04, 177F
→
10/12 14:53, , 178F
是阿，獲益良多
10/12 14:53, 178F
推
10/14 21:05, , 179F
t大應該回文的 整段看下來好清楚
10/14 21:05, 179F
‣ 更多 wtchen 的文章
文章代碼(AID): #1N-HsOQ1 (Soft_Job)
Soft_Job 近期熱門文章
更多 近期熱門文章 >>
PTT職涯區 即時熱門文章
更多 即時熱門文章 >>
‣ 更多 wtchen 的文章
文章代碼(AID): #1N-HsOQ1 (Soft_Job)