iT邦幫忙

0

如何從委外軟體公司所交付的SA/SD文件中辨識出其開發方法使用OOSA及OOSD?

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?

看更多先前的討論...收起先前的討論...
隨便提一個修改需求
然後觀察委外公司人員的第一個反應動作

1.打開程式開始改
2.填寫變更需求單
3.哭天搶地說沒時間
4.拿出SA/SD文件來看

如果什麼事都發生了
只有第4點沒有發生
那我覺得是不是OO也不是那麼重要了 XD
Albert iT邦高手 1 級 ‧ 2009-08-17 19:48:48 檢舉
隨便提一個修改需求
然後觀察委外公司人員的第一個反應動作??
mail 一設定文字串 要你自己貼上去>>這一定是 OO + MDA
然後依毛錢不收
然後功能好了
也不需Compilere

正所謂
此曲只應天上有
人間能得幾回聞 ^_^
ithomelee iT邦研究生 1 級 ‧ 2009-08-18 14:06:01 檢舉
這樣看來,委外時在產品驗收前的軟體公司文件審查,沒什用處?因文件內容歸文件內容,coding歸coding. 二者大概都不相干? 這樣的話,只要驗收最後產品之功能就好了,專案各milestone產出文件也不必審查了?!
我的看法倒也沒這麼極端

我只是覺得
文件與程式碼的符合程度是第一種層次
而要求採用OO(或其他方法)則是第二種層次
能夠要求到第一種層次已經不容易了
更別說第二種層次了

個人經驗,僅供參考
總裁 iT邦好手 1 級 ‧ 2009-08-18 14:17:34 檢舉
看了大家的討論, 感覺有一派人很不重視文件, 認為最後產出的程式最重要, 其他都不重要, 這其實是很傳統的想法, 很多程設師做久的人都有這種想法, 但是, 我個人認為這樣是不妥的, 這樣很容易把人和程式綁在一起, 對系統來講風險是很高的, 或許用這種方法可以讓某人看起來很重要, 但這絕非長久之計, 用正確的方法開發出正確的系統, 這樣才是雙贏的方法.
外獅佬 iT邦大師 1 級 ‧ 2009-08-18 14:32:58 檢舉
同意+1
很多程式,在開發時期級沒有做好SA,
之後的維護工作,簡直就是惡夢...
剛剛找了Caterpillar大大的文章
建議您看一下裡面有關物件導向的章節

若是你要速成的判斷方法
可以在原始碼中搜尋 abstract, interface, extends 等關鍵字
如果從頭到尾都沒有用到這幾個字
那麼就算是java
也不算是物件導向設計
pantc328 iT邦研究生 1 級 ‧ 2009-08-18 15:24:36 檢舉
程式設計師的價值在哪裡?程設師的價值就在這裡.老闆要什麼,就給什麼.老闆不注重文件,坦白的說也沒用.程設師每天都被念,好了沒,怎麼那麼慢,一下又要支援這裡,那裏.一下使用者又說印表機有問題...哪有時間做文件.
老闆每次都用最低的價格,去找那種3-5年經驗,會C,VB,Java...什麼都會的程設師.好像全世界的人都很笨.老實說程設師很聰明,等上線後情勢是完全相反的.
pantc328 iT邦研究生 1 級 ‧ 2009-08-18 15:30:03 檢舉
老實說,你們要Source Code 幹什麼?
對我來說我看Source Code 只是看他們有沒有放一些不乾淨的碼而已.比如說保固期一到,就發生一些原來不該有的動作來跟你嘞索一下.
坦白說去看人家的Code也學不到什麼,不如去看原廠的說明文件.
如果Code有問題,或者要擴充..我都自己寫,直接去抓資料庫就好了.
ithomelee iT邦研究生 1 級 ‧ 2009-08-19 09:20:27 檢舉
謝謝!您的建議很具體.
ithomelee iT邦研究生 1 級 ‧ 2009-08-19 09:29:37 檢舉
我同意CDFU的見解.其實在 SA/SD階段還看不到程式碼,只有文件.
我希望廠商前面用 OOSA/OOSD 設計,後續才有可能OOP.對吧!?
24
bizpro
iT邦大師 1 級 ‧ 2009-08-16 20:40:29
最佳解答

如果委外不含原始碼:

  1. 資料庫: 看資料庫結構, 資料正規化, 資料庫欄位定義, 表單的名字與欄位名字是否清楚,...等等.
  2. 程式: 把一個一個Jar拆開, 即使有經過obfuscation, 物件間的關係依然可清楚看出, 和MVC之間的區隔應該也可以明顯看出. 至於是否需要deobfuscating, 在於貴公司的決定.
  3. 畫面: 各畫面元件的關係會說故事, 文件中應該要有清楚的說明, 哪些畫面的更動影響哪些物件, 從事件的觸發與處理可以看出是否有嚴格的MVC處理.
    如果委外含原始碼, 以上的東西可以看得更清楚.
    無論如何, 資料庫, 程式, 畫面, 與文件要對得起來, 而不論是否有原始碼, 資料庫應該要用Plain English來描述, 而程式碼應呈現物件關係, 畫面的事件流程要清楚, 文件應該清楚表明.
24
weihsinchiu
iT邦新手 4 級 ‧ 2009-08-16 13:18:08

直接要求交付 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)』

22
markshu
iT邦好手 1 級 ‧ 2009-08-16 16:25:44

即使文件是OOSA OOSD 但是開發出來的程式 未必真的就和文件的一樣
所以過程中 可以自行CODE REVIEW一下,或是看一下程式碼的設計模式
無論用MVC還是其他各種的設計模式 大約看一下程式碼的部份 看整個的開發架構
否則文件交付是一回事 開發出來的又是一回事

20
pantc328
iT邦研究生 1 級 ‧ 2009-08-17 08:31:25

以上的總總,都不可能推出適用哪一種.
系統在分析,設計,實作..都會不停的在修正.有些東西很難去結構化.
除非你開發合約上明確的規範,Code要怎麼寫,要產生哪些文件.而Code看得出是做什麼就好了.推他的方法論未免也太~

16
Albert
iT邦高手 1 級 ‧ 2009-08-17 08:55:33

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

看更多先前的回應...收起先前的回應...
pantc328 iT邦研究生 1 級 ‧ 2009-08-17 09:05:52 檢舉

理論跟事實有一定的差別.
理論可以寫一堆邏輯...但事實已經將這些合在一起.
比如說,我寫程式裡面用很多設計樣式,但說我用哪些樣式,我不知道,我已經化有形為無形.
寫程式還在想大卡,小卡..問題,系統做到何時了?
系統開發大家都用捷徑法,能省就省,能少就少,比如1+1=?這種還要文件化?還要考量方法論?就跟2x2=多少,你用建構式數學論,只會為難自己.
很多公司,你開給他規格,你開哪些,他就做哪些,你要什麼文件,他就寫什麼文件給你,你沒開的或內部的實作,他就隨便應付.

Albert iT邦高手 1 級 ‧ 2009-08-17 16:12:13 檢舉

很多公司,你開給他規格,你開哪些,他就做哪些,

這是對的,,你要他作多少她就作多少
你不知如何要求或沒有要求他就不寫也不該寫
你不知如何要求時, 請顧問教你開規格

你要什麼文件,他就寫什麼文件給你,

文件是發包者給的;不會是寫程式做的

你沒開的或內部的實作,
他就隨便應付.

沒有規格就沒作品 也不需隨便應付,,
沒有驗收標準的作品是無法驗收的

謝謝指教

Albert iT邦高手 1 級 ‧ 2009-08-17 16:14:27 檢舉

堤外話
堤內水災!!!!
題外話...關聯式物件也是物件

Albert iT邦高手 1 級 ‧ 2009-08-17 19:42:51 檢舉

再談"容易修改 管理 維護"
超級使用者(資訊中心) 可以依照

在同一作業
為不同使用者,為不同同職務
設定欄位為<不顯示><唯讀>
設定可讀取資料區段
設定可改取資料區段
不需要改程式
...

Albert iT邦高手 1 級 ‧ 2009-08-18 00:02:52 檢舉

再談"容易修改 管理 維護"
超級使用者(資訊中心) 可以依照

以上是我們的系統 OO + MDA

Albert iT邦高手 1 級 ‧ 2009-08-18 00:50:38 檢舉

系統開發大家都用捷徑法,
能省就省,能少就少,
比如1+1=?
這種還要文件化?
===> SA沒有文件要 1+1 寫程式的人可以自行 1+1 嗎!!
===> 不了解寫程式的可以自己加加減減一些 文件沒有要作的事

還要考量方法論?
就跟2x2=多少,你用建構式數學論,只會為難自己.
有些東西就是要 (每個 Valuation Area 的 Valuation class)
一個一個加進來 一個一個移動 算平均成本
又不是在算每月平均值當人要一個一個來

Albert iT邦高手 1 級 ‧ 2009-08-18 00:51:21 檢舉

又不是在算每月平均值當然要一個一個來

Albert iT邦高手 1 級 ‧ 2009-08-18 07:29:06 檢舉

你的<<委外>>
好像怪怪的!!
買技術買顧問買文件買 BinaryCode ...沒有買原始碼??
不像委外
一般委外是你比它內行. SubContract
你沒有那麼多人力
你教她(或講解規格) 100 人工小時
希望他 能夠提供 十倍 到 百倍 時間
用 一千人工小時 或 一萬人工小時 來幫忙

pantc328 iT邦研究生 1 級 ‧ 2009-08-18 08:55:07 檢舉

說委外,哪有那麼容易.寫什麼東西都跟你想的一模一樣,坦白說你找不到這種公司.就算找到成本也非常非常的高.
就算你花錢請幾個小朋友來做,組個團隊,裡面成員每個寫的方式或多或少會不一樣.
一般而言,你要哪些文件,他們就有辦法做到哪些文件.就程式而言,你要做哪些文件,我只能說可以,只是文件跟Code會不一樣.實作是以功能為主.程設師為實做那些功能是不擇手段.不管是結構,半結構,亂寫一通,反正功能出來就是對的.有時寫到自己寫什麼都不知道.
所以去看,沒什麼太大意義,有時你一看就可以看出裡面很多人補補貼貼過.有的Code看了你都會掉眼淚.

pantc328 iT邦研究生 1 級 ‧ 2009-08-18 13:26:30 檢舉

//SA沒有文件要 1+1 寫程式的人可以自行 1+1 嗎!!
什麼東西都文件化,告訴你SA寫死了,東西都做不出來.
//有些東西就是要 (每個 Valuation Area 的 Valuation class)
要的沒話說.不要的你去做.做到瘋都不一定作的對,效能也會很差.

ithomelee iT邦研究生 1 級 ‧ 2009-08-18 13:51:47 檢舉

9
pantc328 說:

實作是以功能為主.程設師為實做那些功能是不擇手段.不管是結構,半結構,亂寫一通,反正>>功能出來就是對的.有時寫到自己寫什麼都不知道.
個人過去經驗,好像真的都是如此. 反正能將功能寫出來就好,管他什麼OO,結構,半結構.
不曉得各位的看法如何???

委外
無關痛癢的東西可以委外
例如:清潔工作可以委外、物流配送可以委外、餐飲可以委外
Mail Server可以委外、DNS可以委外
會計系統可以委外
基本上就是非常成熟且標準化的東西可以委外
萬一還在發展階段、東西並不成熟
最好是找人力派遣!
找五個工程師、兩個物件導向系統分析師、一個專案經哩!
OR找一兩個很厲害的工程師,外加一個文件助理,自己下海當專案經理也是可以!
記住喔!要很成熟以及標準化的東西才能委外喔!
不是很熟成也不是很標準化的,最好直接利用人力派遣!
比較可以控制到細節的問題!

Albert iT邦高手 1 級 ‧ 2011-07-28 20:37:55 檢舉

weihsinchiu 大大 說得好

委外 :: 記住喔!要很成熟以及標準化的東西才能委外喔!

16
miin1130
iT邦新手 5 級 ‧ 2009-08-17 15:18:59

第一個直覺是,這個問題好怪,因為我也認同分析方法論是因地置宜的,去強調這個很怪
第二個是,如果要正確的了解他們怎麼開發的,最好的方式就是Code Review,不過,我也懷疑在臺灣的專案環境,如果能夠選擇性的看就很好了,很難大規模的看。
第三是,如果您一定要看出來,我會建議看ERD圖,跟Class Diagram,如果有空可以再看一下循序圖,如果這三個圖不是亂寫的,只要留心看他們物件或Class間的偶合性大概就可以猜了,習慣於結構式分析法的人,會習慣用流程思考問題,而非物件間的協同,雖不中亦不遠,但這要一點經驗。但要給您一個觀念,用物件導向也不代表較高的品質,而且這也跟語言特性有關,早期很多程式都是流程導向,硬用改成物件導向不是不行,但我覺得還不如拿新語言重寫算了,這又回到第一個問題了,所以我還是不懂為什麼要問這個問題

我要發表回答

立即登入回答