SA/SD的方法由傳統的
(1)應用功能導向式SA/SD 方法(Application Oriented SA&SD)
到
(2)結構化系統分析與設計方法(Structured SA&SD)
到現在最具威力的
(3)物件導向分析與設計方法(Object Oriented SA&SD)
在需求規格中有要求委外軟體公司必須使用OOSA及OOSD開發設計應用系統(其使用語言JAVA).主要是著眼於OOSA及OOSD開發設計的應用系統容易修改 管理 維護.進行修改與擴充時,是在物件內部進行,不會影響到外部其他運作.
請問:有無簡易方法,可從委外軟體公司所交付的文件(SA and SD documents)中辨識出其開發方法確實是使用OOSA及OOSD?
已邀請的邦友 {{ invite_list.length }}/5
如果委外不含原始碼:
直接要求交付 UML 文件就可以了
主要是下面三個觀點：
1.功能觀點：從用戶的觀點看系統模型，主要圖式為『使用案例圖(Use-case Diagram)』。
2.物件觀點：關心物件的屬性、操作和關係，主要圖式有『類別圖(Class Diagram)』。
3.動態觀點：關心系統的內部行為，主要圖式有『順序圖(Sequence Diagram)』、『活動圖(Activity Diagram)』、和『狀態圖(State Diagram)』等。
至少要交付
1.『使用案例圖(Use-case Diagram)』
2.『類別圖(Class Diagram)』
3.『順序圖(Sequence Diagram)』
即使文件是OOSA OOSD 但是開發出來的程式 未必真的就和文件的一樣
所以過程中 可以自行CODE REVIEW一下，或是看一下程式碼的設計模式
無論用MVC還是其他各種的設計模式 大約看一下程式碼的部份 看整個的開發架構
否則文件交付是一回事 開發出來的又是一回事
以上的總總,都不可能推出適用哪一種.
系統在分析,設計,實作..都會不停的在修正.有些東西很難去結構化.
除非你開發合約上明確的規範,Code要怎麼寫,要產生哪些文件.而Code看得出是做什麼就好了.推他的方法論未免也太~
SA/SD的方法由傳統的
＞＞(1)應用功能導向式SA/SD 方法(Application Oriented SA&SD)到
＞＞徒善不足以為正 徒法不足以自行！！！
＞＞目標永遠比方法/工具重要！！！
＞＞(2)結構化系統分析與設計方法(Structured SA&SD)到現在最具威力的??
大卡車最具威力
跑車最具威力
摩托車最具威力
單車最具威力
那要看你再哪一個場合！！！
是林道,是無限速高速路,是小徑,是有時要扛著走一段？？？
(3)物件導向分析與設計方法(Object Oriented SA&SD)
在需求規格中有要求委外軟體公司必須使用OOSA及OOSD開發設計應用系統
(其使用語言JAVA).
＞＞我們比外包廠商了解,因此我們是請他來聽課,要求他照此進行！！！
主要是著眼於OOSA及OOSD開發設計的應用系統
容易修改 管理 維護.進行修改與擴充時,
是在物件內部進行,不會影響到外部其他運作.
＞＞這要開規格標, 在合約要將細節列出,
＞＞＂容易修改 管理 維護＂這是形容詞沒有標準可循
＞＞我們是說哪些必須參數化
＞＞我們是說哪些必須外掛驗證引擎
//
// 以下片段 ModelValidationEngine.java(外掛驗證引擎)
// 在 MInOut.java prepareIt() 執行單據 客制化 驗證 (單據成立前的驗證(校正) )
// 我們觸發了 m_processMsg = ModelValidationEngine.get().fireDocValidate(this, ModelValidator.DOCTIMING_BEFORE_PREPARE);
// 在 MInOut.java completeIt() User Validation 執行 客製化 驗證 (單據成立後的驗證)
// 我們觸發了 String valid = ModelValidationEngine.get().fireDocValidate(this, ModelValidator.DOCTIMING_AFTER_COMPLETE);
//
請問:有無簡易方法,
可從委外軟體公司所交付的文件(SA and SD documents)
中辨識出其開發方法確實是使用OOSA及OOSD?
＞＞結論是規格是被要求出來的,不需要當偵探,況且用對工具用不一定是走對路線
會用工具不一定可以作出你要的系統.....
有開細部規格問題嗎??
要教育好你的外包商??
技術轉移顧問
Skype: Adempiere/Compiere
MSN : albert_a_chen@yahoo.com
理論跟事實有一定的差別.
理論可以寫一堆邏輯...但事實已經將這些合在一起.
比如說,我寫程式裡面用很多設計樣式,但說我用哪些樣式,我不知道,我已經化有形為無形.
寫程式還在想大卡,小卡..問題,系統做到何時了?
系統開發大家都用捷徑法,能省就省,能少就少,比如1+1=?這種還要文件化?還要考量方法論?就跟2x2=多少,你用建構式數學論,只會為難自己.
很多公司,你開給他規格,你開哪些,他就做哪些,你要什麼文件,他就寫什麼文件給你,你沒開的或內部的實作,他就隨便應付.
很多公司,你開給他規格,你開哪些,他就做哪些,
這是對的,,你要他作多少她就作多少
你不知如何要求或沒有要求他就不寫也不該寫
你不知如何要求時, 請顧問教你開規格
你要什麼文件,他就寫什麼文件給你,
文件是發包者給的;不會是寫程式做的
你沒開的或內部的實作,
他就隨便應付.
沒有規格就沒作品 也不需隨便應付,,
沒有驗收標準的作品是無法驗收的
謝謝指教
堤外話
堤內水災！！！！
題外話...關聯式物件也是物件
再談＂容易修改 管理 維護＂
超級使用者（資訊中心） 可以依照
在同一作業
為不同使用者,為不同同職務
設定欄位為＜不顯示＞＜唯讀＞
設定可讀取資料區段
設定可改取資料區段
不需要改程式
...
再談＂容易修改 管理 維護＂
超級使用者（資訊中心） 可以依照
以上是我們的系統 OO + MDA
系統開發大家都用捷徑法,
能省就省,能少就少,
比如1+1=?
這種還要文件化?
===> SA沒有文件要 1+1 寫程式的人可以自行 1+1 嗎!!
===> 不了解寫程式的可以自己加加減減一些 文件沒有要作的事
還要考量方法論?
就跟2x2=多少,你用建構式數學論,只會為難自己.
有些東西就是要 (每個 Valuation Area 的 Valuation class)
一個一個加進來 一個一個移動 算平均成本
又不是在算每月平均值當人要一個一個來
又不是在算每月平均值當然要一個一個來
你的＜＜委外＞＞
好像怪怪的！！
買技術買顧問買文件買 BinaryCode ...沒有買原始碼??
不像委外
一般委外是你比它內行. SubContract
你沒有那麼多人力
你教她(或講解規格) 100 人工小時
希望他 能夠提供 十倍 到 百倍 時間
用 一千人工小時 或 一萬人工小時 來幫忙
說委外,哪有那麼容易.寫什麼東西都跟你想的一模一樣,坦白說你找不到這種公司.就算找到成本也非常非常的高.
就算你花錢請幾個小朋友來做,組個團隊,裡面成員每個寫的方式或多或少會不一樣.
一般而言,你要哪些文件,他們就有辦法做到哪些文件.就程式而言,你要做哪些文件,我只能說可以,只是文件跟Code會不一樣.實作是以功能為主.程設師為實做那些功能是不擇手段.不管是結構,半結構,亂寫一通,反正功能出來就是對的.有時寫到自己寫什麼都不知道.
所以去看,沒什麼太大意義,有時你一看就可以看出裡面很多人補補貼貼過.有的Code看了你都會掉眼淚.
//SA沒有文件要 1+1 寫程式的人可以自行 1+1 嗎!!
什麼東西都文件化,告訴你SA寫死了,東西都做不出來.
//有些東西就是要 (每個 Valuation Area 的 Valuation class)
要的沒話說.不要的你去做.做到瘋都不一定作的對,效能也會很差.
9
pantc328 說：
實作是以功能為主.程設師為實做那些功能是不擇手段.不管是結構,半結構,亂寫一通,反正>>功能出來就是對的.有時寫到自己寫什麼都不知道.
個人過去經驗,好像真的都是如此. 反正能將功能寫出來就好,管他什麼OO,結構,半結構.
不曉得各位的看法如何???
委外
無關痛癢的東西可以委外
例如：清潔工作可以委外、物流配送可以委外、餐飲可以委外
Mail Server可以委外、DNS可以委外
會計系統可以委外
基本上就是非常成熟且標準化的東西可以委外
萬一還在發展階段、東西並不成熟
最好是找人力派遣！
找五個工程師、兩個物件導向系統分析師、一個專案經哩！
OR找一兩個很厲害的工程師，外加一個文件助理，自己下海當專案經理也是可以！
記住喔！要很成熟以及標準化的東西才能委外喔！
不是很熟成也不是很標準化的，最好直接利用人力派遣！
比較可以控制到細節的問題！
weihsinchiu 大大 說得好
委外 :: 記住喔！要很成熟以及標準化的東西才能委外喔！
第一個直覺是，這個問題好怪，因為我也認同分析方法論是因地置宜的，去強調這個很怪
第二個是，如果要正確的了解他們怎麼開發的，最好的方式就是Code Review，不過，我也懷疑在臺灣的專案環境，如果能夠選擇性的看就很好了，很難大規模的看。
第三是，如果您一定要看出來，我會建議看ERD圖，跟Class Diagram，如果有空可以再看一下循序圖，如果這三個圖不是亂寫的，只要留心看他們物件或Class間的偶合性大概就可以猜了，習慣於結構式分析法的人，會習慣用流程思考問題，而非物件間的協同，雖不中亦不遠，但這要一點經驗。但要給您一個觀念，用物件導向也不代表較高的品質，而且這也跟語言特性有關，早期很多程式都是流程導向，硬用改成物件導向不是不行，但我覺得還不如拿新語言重寫算了，這又回到第一個問題了，所以我還是不懂為什麼要問這個問題
iThome鐵人賽
看影片追技術