敬請註冊 ... !    登入
關於本協會
登入
軟體品質資源專區
主選單
最新討論文章
討論區主頁
   軟體專案管理
     工作條款(SOW)
無發表權

樹狀顯示 | 舊的在前 前一個主題 | 下一個主題 | 頁尾
發表者 討論內容
tyrone
發表時間: 2010-09-04 10:45
網站管理員
註冊日: 2003-04-19
來自: CSQA
發表數: 342
Re: 工作條款(SOW)
引文:

具體的說好了,您認為以下這段"裁適的決策"紀錄

The contractor shall comply with all requirements of DOD-STD-2167A with the following exceptions
4.1.2 Delete entire paragraph
4.2.9 Delete reference to software development files.
etc.

是不是SOW?(就先到這,等您回應,澄清聚焦後再接下去處理異議)

為避免被誤導,讀者可以再回MIL-HDBK-287的MIL-HDBK-287第19頁,"4.3.5 Where are tailoring decisions specified?"小節中。而且建議讀者最好手上就有MIL-HDBK-287與DOD-STD-2167A (雖然都已被美國軍方cancel掉,但仍舊很有參考價值),可以實際翻出來對照(連小弟typo都歡迎拿出檢討、指正)。
a. Statement of Work. Tailoring decisions for standard are specified in the contract SOW. A typical tailoring statement is:
The contractor shall comply with all requirements of DOD-STD-2167A with the following exceptions:
4.1.2 Delete entire paragraph
4.2.9 Delete reference to software development files
etc.


本段是教導DOD-STD-2167A及MIL-HDBK-287的使用者,裁適後該納到那裡。這裡是指這些裁適決策(亦即裁適結果),會納到SOW中。當然一旦這些裁適決策納到SOW中時,那麼他們就成為SOW中的一項,這時才會成為Statements of work的一部分。注意後列這段話,正因為是在合約/RFP的SOW寫了"The contractor shall comply with all requirements of DOD-STD-2167A",這個時候,DOD-STD-2167A,才與SOW發生關聯,"The contractor shall comply with all requirements of DOD-STD-2167A"是SOW的一個項目,但是DOD-STD-2167A本身是不是SOW呢?當然不是它是與計畫/專案工作(tasks)、過程(processes)有關之requirements的來源納在合約/RFP中的此項SOW,是指示contractor要遵循(comply with)這些(DOD-STD-2167A中的)requirements去完成其工作,達到計畫/專案的目標,後段"with the following exceptions:",指示contractor遵循時所要去掉相對的requirements項目。若 RCI@Taiwan 要說因此DoD-STD-2167A繼承那段話的屬性(是為合約/RFP中的SOW),而成為"標準SOW",似乎也太牽強,這麼說的其理由可以參看美國聯邦法規法典(Code of Federal Regulations):
TITLE 48 - FEDERAL ACQUISITION REGULATIONS SYSTEM (聯邦獲取法規制度, FARS)
CHAPTER 3 - HEALTH AND HUMAN SERVICES
SUBCHAPTER B - COMPETITION AND ACQUISITION PLANNING
PART 307 - ACQUISITION PLANNING (獲取規劃)
307.7106 - Statement of work. (工作條款)
其對於工作條款的觀點來判斷了。

註:
Statement of work - 指單純的一項工作條款敘述;Statements of work - 指SOW文件。
就像Specification指一項規格,Specifications指規格書;Description指一項說明,而Descriptions指說明書。

引文:

至於Formal review是不是會真的可能被裁掉?....要實例嗎?....先看指導書吧!

→287附錄A的工作表顯示,2167A的每一條requirement都不能排除被"D"掉...

小弟不是說了嗎,看案子的籌獲策略(這是複誦),....也有的要看案子的規模(這是新增)...


基本上MIL-HDBK-287附錄A是一份可以直接用於專案中的"Tailoring Worksheet",既然是一份裁適工作表,把所有的裁適時該考慮的項目都列出來是必要的。但是,這是份工作表,基於其格式使然,所有項目必須全列,以相同的方式呈現,所以沒有所謂是不是能否"排除被"D"掉"的問題(儘管每一個項目的前面欄位都有"K D R"字樣,是格式所要求的一貫性的標示而已,參見MIL-HDBK-287, 第51至62頁),我認為"不能排除被"D"掉"這句話是一項誤解。舉例來說,從發展的角度(DOD-STD-2167A之存在,就是為了軟體發展)來看,試試將"4.1 software development management"之4.1.1(軟體發展過程)、4.1.2(正規審查/稽核)、4.1.3(軟體發展規劃)、4.1.4(風險管理)、4.1.9(矯正措施過程)刪掉("D"掉)看看....。如果有,那必定是個失敗的案子。我們要談可以"D"掉,那麼舉的例子,必定是"D"掉之後,專案還是可以成功才行(就工程本身的努力,政治力介入不算)。

附帶一提:CMMI的使用者,在自己公司的工程/工程管理制度建立後,公司裡的裁適指引,可以依樣畫葫蘆,弄一份自己公司工程/工程管理制度用於專案時的裁適工作表,當然,其所提列的項目得源自公司的practices,而不是DOD-STD-2167A。(這麼做時,公司本身也能審視自己公司的CMMI制度是不是夠強大,夠不夠應用於各種類型的軟體發展專案了)


----------------
引文:

凡所有相皆是虛妄。見諸相非相。即見如來。

林泰龍
◎軟體品質協會 理事
◎經濟部標準檢驗局資訊及通信國家標準技術委員會(TC21/SC3資訊軟體分組委員會)委員
Youtube Channel: http://www.youtube.com/user/tyrone9304

RCI@Taiwan
發表時間: 2010-09-04 00:31
Not too shy to talk
註冊日: 2008-04-20
來自:
發表數: 24
Re: 工作條款(SOW)
究竟是否"引喻失義"還是"見到黑影就開槍"?建議您自己先留著,不急著出手,討論完有共識再決定給誰不遲!

具體的說好了,您認為以下這段"裁適的決策"紀錄

The contractor shall comply with all requirements of DOD-STD-2167A with the following exceptions
4.1.2 Delete entire paragraph
4.2.9 Delete reference to software development files.
etc.


是不是SOW?(就先到這,等您回應,澄清聚焦後再接下去處理異議)

按:小弟的感覺,您講的那一大落(甚至引經據典的)東東,有點在像講白馬非馬,希望小弟沒有誤解您的意思或"引喻失義"

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++

至於Formal review是不是會真的可能被裁掉?....要實例嗎?....先看指導書吧!

→287附錄A的工作表顯示,2167A的每一條requirement都不能排除被"D"掉...

小弟不是說了嗎,看案子的籌獲策略(這是複誦),....也有的要看案子的規模(這是新增)...

某案子中不要求承商按1521作Formal review,承商自己就不會去review啦?...說不定承商自己review得比有要求Formal review還"用力"哩....

標準/SOW的裁適原則中有一條→成本效益!

這點小弟不是已經"暗示過很多回"了嗎?

每一條requirement都要算錢(計價)的....


有關Formal Review與J. Rvw,您說得很好啊,也很正確....但這只是故事的結果,至於這故事的結局是怎麼來的?您可知道?

您提到2167A的時代,好極了,就講那個時代!

不曉您有沒有讀過,書上有說,在使用2167A的案子中,經常發生為了舉辦Formal review,要耗去數以百計的人時(換算過來就是一大筆工錢),計畫卻要停擺6週的故事?!

小弟的經驗,停擺2個月(或更久)亦是可能的....!

這也是J. Rvw會出現在這個世界上的原因之一....(另外的原因之一,是90年代美國DOD政策的改變,這部份您有提過,可惜沒把這個環境變化因素與在這一條聯想再一起....)
+++++++++++++++++++++++++++++++++++++++++++++++++++++

至於WBS用於計畫,謝謝您的關心,小弟一直用得很好,至少差強人意(按:前面不是也有暗示過嗎).....

小弟只是不贊成放到我國政府爾....(原因之一及之二已經講過多次,恕不再"複誦")....(原因之三或....有機會再談吧!)
++++++++++++++++++++++++++++++++++++++++++++++++++++++
題外話,先恕小弟將外出若干日,期間未便回應,有什麼批評指教請不必客氣,待小弟返回來後將一併處理,祝週末愉快,萬事如意!
tyrone
發表時間: 2010-09-03 07:09
網站管理員
註冊日: 2003-04-19
來自: CSQA
發表數: 342
Re: 工作條款(SOW)
引文:

最後,還是得回來面對2167A/498/016是不是標準的SOW的爭異議題(希望您的結語不是逃避的藉口)

若您不喜歡頁19的sow的例子

The contractor shall comply with all requirements of DOD-STD-2167A with the following exceptions “ -
4.1.2 Delete entire paragraph
4.2.9 Delete reference to software development files.
etc.

小弟認為這是"引喻失義",請注意該段要說明的是什麼!!小弟將全文貼在下面:
MIL-HDBK-287第19頁,4.3.5 Where are tailoring decisions specified? (4.3.5 裁適決策於何處規定?)
a. Statement of Work. Tailoring decisions for standard are specified in the contract SOW. A typical tailoring statement is:(工作條款。標準的裁適決策要規定在合約SOW中。典型的裁適語句為:)
The contractor shall comply with all requirements of DOD-STD-2167A with the following exceptions: (合約商應併同下列排除條款,遵循DOD-STD-2167A的要求:)
4.1.2 Delete entire paragraph
4.2.9 Delete eference to software development files
etc.

這是只在說明DOD-STD-2167A的裁適結果要放在何處,怎麼寫,所給出的例子而已。這段要表達的是說,裁適決策要放在SOW裡面(這也同時反映出,SOW裡該包括:標準的裁適決策)而已,至於是不是真的把"Formal Reviews/Audits裁了,那是另外一段事情,真有這種實例嗎?是用在軟體發展的例子,如果有,我真的懷疑,因為從其他的軍方手冊裡都指向,軟體發展是高風險的工作,把這個裁掉....真的可行嗎?如果真的有,那個計畫應該是失敗的(成本超支、夭折、軟體不能用)。

何謂Formal Reviews?何以改為J. Rvw.? 用Joint Review只是在反映,這是甲乙雙方聯席召開的審查。而Formal reviews,的Formal指的是用科學、客觀、數學、邏輯等的正規方式來做審查。Joint Review並不妨礙正規方法的使用。但Formal Review可能是甲方自己單獨實施。從Formal Review到Joint Review是觀念上的改變而已。但不代表嚴謹度會降低,不會把漫不經心的甲乙雙方搞垮,而是有更多的選擇。但是不實施Formal review還是很怪的,計畫中初步設計審查(PDR)與關鍵設計審查(CDR),總是會用到,尤其是技術風險有關的部分,在DOD-STD-2167A的擅場的年代裡刪除Formal Review,不可思議呀....。當然,如果甲方要關起門來自己做Formal Review,是可以不告訴合約商,是可以在SOW的裁適決策,將之刪除(然而,應注意的是,在做Formal Review時,有很多事情可能是需要乙方協助的,例如與設計結果驗證有關之特殊環境的提供)。但計畫裡不做Formal review是很不合理的。

引文:
HDBK-287頁37-38上 para 5.8還有幾個不同(但手法類同)的用2167A為藍本寫SOW的例子

5.8 STEP 7: Record the tailoring decisions in the Statement of Work.
a. Description. The final step in tailoring the standard itself is to record the tailoring decisians in the contract SOW.


這段談的還是"將裁適決策要記錄到合約SOW中"。

看來,我們得回到根本問題:什麼是SOW。
SOW-"Statement of Work"是合約中或協議書(agreements)中,發展者應履行之工作的列表。這算是美國政府的合約用語。放在SOW中的東西,才會是SOW(工作條款)(理由很簡單,"SOW" 是合約/協議/RFP的一部分,SOW是因合約/協議/RFP格式的規定而存在的,脫離了合約/協議/RFP格式,這些東西就不會是SOW。小弟還真討厭文字遊戲);若2167A/498是標準SOW,何以相關章節裡都要再提到"SOW"的字眼(難道SOW有二義性?)。例如,2167A的適用範圍:

1.2 Application.
The requirements of this standard apply to the development of Computer Software Configuration Items (CSCIs). This standard applies to the extent specified in the contract clauses, the Statement of Work (SOW), and the Contract Data Requirements List (CDRL).(本標準之要求適用於電腦軟體組態項目(CSCI)的發展。本標準適用至合約條款、工作條款(SOW)、以及合約資料需求清單(CDRL)所規定的範圍中)。

有關SOW寫在498的適用範圍1.2.1節,上次已列過,不再贅述。所以任何標準的條文,在沒有被放入SOW這份文件之前,標準的條文本身都不會是"工作條款",只是該標準之範圍體系中一個描述性的條目而已,而其意義與目的,應由該標準的前言、目的的描述去定義。而在ISO/IEC 12207:2008, ISO/IEC 15288:2008, 或發展中的ISO/IEC 29110系列裡,都沒有用到"Statement of Work"一詞(除了在ISO/IEC 12207:2008中的Terms and definitions 4.46出現一下,正文中完全沒有提及,真不知道它為什麼被列入Terms and definitions乙節中)。

思考一下,這句話:"網頁應用交付前,應完成基於風險的測試(risk-based testing)"。如果寫在一份關於security testing的論文裡,它是論文的一部分;我寫在一張廢紙上,它什麼都不是,只是我在練字時所寫的一段文字,根本不具意義;但是我將之放在合約的SOW部分裡,它就是合約工作條款的一項(或一部分)了。

小弟非槓子頭,但"看到幾分證據,說幾分話"是指導原則。但恕小弟直言,您所提的例子,不論是源自2167A或287,都是"看到黑影就開槍"(都出現"Statement of Work"字眼),這無助於讀者的學習,而且對於列示這些例子或文句的目的相當不明確,到底想要表達這些都能支持"2167A/498就是標準SOW"還是表達"裁適作法"(若是要表達裁適作法,"裁適"亦是很好的議題,可以另外開個討論串)。建議引用文字時,能中英文同時呈現,以確定認知無誤。

小弟一再強調,貼這些是因為,CMMI與PMBOK提到了,但是追求CMMI與PMP認證者,連SOW與WBS是什麼都搞不清楚(組織也通過評鑑,人也取得認證),只能算是分享一些知識,如果, RCI@Taiwan 就認為,我在推動標案裡的運用,太過抬舉,也無能為力,但是我自己經手的案子,我會去運用。而運用的原因,也只是因為了解,也確認其對於專案有幫助,運用的部分也是適合專案的部分而已。我會做的,只是自我要求而已。但問我個人的意見,我還是強烈建議--用吧,WBS!(但得先學會理解與遵重系統工程過程)。再根據WBS所劃定的範疇,研提RFP/合約的工作清單(要稱做SOW也行),這時候用不用國家標準、國際標準、工業標準、區域標準,還是要用內規(像是美國軍方標準。不過,現在美國軍方的軟體工程標準,與工業標準及國際標準一致),那就看規定了(我國政府部門逃不了受限於"政府採購法",那就是得遵循國家標準與國際標準了)

小弟不理解的是,何以"懂得"如何運用裁適的概念於DOD-STD-2167A、MIL-STD-498,但同樣的裁適觀念,卻不會運用於MIL-HDBK-245D及MIL-DHBK-881A,是何道理?

附帶資料:資料來源
有關於"SOW是什麼",由於這個term出於美國聯邦的採購法規,因此提列相關的法律解釋供參考:
美國聯邦法規法典(Code of Federal Regulations)
TITLE 48 - FEDERAL ACQUISITION REGULATIONS SYSTEM (聯邦獲取法規制度, FARS)
CHAPTER 3 - HEALTH AND HUMAN SERVICES
SUBCHAPTER B - COMPETITION AND ACQUISITION PLANNING
PART 307 - ACQUISITION PLANNING (獲取規劃)
307.7106 - Statement of work. (工作條款)
(a) General. A statement of work (SOW) differs from a specification and purchase description primarily in that it describes work or services to be performed in reaching an end result rather than a detailed, well defined description or specification of the end product. The SOW may enumerate or describe the methods (statistical, clinical, laboratory, etc.) that will be used. However, it is preferable for the offeror to propose the method of performing the work. The SOW should specify the desired results, functions, or end items without telling the offeror what has to be done to accomplish those results unless the method of performance is critical or required for the successful performance of the contract. The SOW should be clear and concise and must completely define the responsibilities of the Government and the contractor. The SOW should be worded so as to make more than one interpretation virtually impossible because it has to be read and interpreted by persons of varied backgrounds, such as attorneys, contracting personnel, cost estimators, accountants, scientists, educators, functional specialists, etc. The SOW must clearly define the obligations of both the contractor and the Government so as to protect the interests of both. Ambiguous statements of work can create unsatisfactory performance, delays, and disputes, and can result in higher costs.
(a) 概述。 工作條款(SOW)基本上與規格及採購說明不同,其中,描述將履行以達成最終結果的工作或服務,而不是最終產品的詳細、明確界定的說明或規格。SOW可列舉或描述將使用的方法(統計、臨床、實驗室等等)。然而,最好是讓投標者(offeror)提出工作履行方法的建議。SOW宜規劃所欲結果、功能、或最終項目,而不告知投標者該做哪些工作以完成該等結果,除非履行的方法是屬關鍵或合約成功履行所必需。SOW應是明確且簡明的,且須完整地定義政府部門與合約商的職責。SOW的措辭宜使多重解讀實屬不可能,因其須由不同背景的人閱讀與解釋,諸如律師、訂約人員、成本估算者、會計師、科學家、教育家、功能專家等等。SOW須明確地定義合約商與政府部門雙方的義務,以保護雙方的利益。模糊的工作條款會造成令人不滿意的效能、延遲、及爭議,並能導致更高的成本。


----------------
引文:

凡所有相皆是虛妄。見諸相非相。即見如來。

林泰龍
◎軟體品質協會 理事
◎經濟部標準檢驗局資訊及通信國家標準技術委員會(TC21/SC3資訊軟體分組委員會)委員
Youtube Channel: http://www.youtube.com/user/tyrone9304

RCI@Taiwan
發表時間: 2010-09-03 02:12
Not too shy to talk
註冊日: 2008-04-20
來自:
發表數: 24
Re: 工作條款(SOW)
引文:
有任何獲取方計畫/專案經理,在規劃CSCI的發展時把Formal Review/Audit(2167A的4.1.2)刪除,那真是太勇敢了,我如果是他/她的長官,我會叫他/她回家好好反省反省吧。當然,把審查與稽核砍掉,代表軟體在發展時,是完全不會用到MIL-STD-1521B (Technical Reviews and Audits for Systems, Equipments, and Computer Software)的。但是這亦代表,獲取方放任供應方(合約商)恣意胡為,完全不予控制的意思。....


令人意外,也令人失望,您怎會對HDBK-287的內容下出如此(對不起,小弟要下重話了)"離譜"的comment?

首先,那個出自HDBK-287頁19的SOW的例子

The contractor shall comply with all requirements of DOD-STD-2167A with the following exceptions
4.1.2 Delete entire paragraph
4.2.9 Delete reference to software development files.
etc.


是被美國國防部正式核可公佈發行的,....照您的意思,把上段文字放到HDBK-287的作者...以及所有的核閱者全該回家吃老米飯!?.....

其次,美國政府/軍方的哪條法案/DODD/DODI規定Formal Reviews/Audits的要求不能自採用2167A的案子中刪除的?

刪掉就刪掉啊,有啥好大驚小怪的?...沒見過把Formal Reviews/Audits全刪掉的案子嗎?

以美國的環境,決定要不要採用Formal Reviews/Audits其實和案子的籌獲策略有關,有些案子,在2167A的裡面,就是可以不必選用Formal Reviews/Audits!

(題外話)若不考慮其他,單純只檢討Formal Reviews/Audits在計畫中的存在意義與效益...小弟不知道您有沒有參加/執行/主導過任合一項1521B上所提到的Formal Reviews/Audits啦,但以小弟當年所見(國內外加起來的次數加起來應該有3位數了吧?),Formal Reviews/Audits本來就可以不必非存在不可!

按:就算您沒參與過這些計畫,但也應該讀過資料吧?498/016/12207之所以會改成用J. Rvw.,原因之一就是許多人都被Formal Reviews/Audits整慘了....

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

最後,還是得回來面對2167A/498/016是不是標準的SOW的爭異議題(希望您的結語不是逃避的藉口)

若您不喜歡頁19的sow的例子

The contractor shall comply with all requirements of DOD-STD-2167A with the following exceptions “ -
4.1.2 Delete entire paragraph
4.2.9 Delete reference to software development files.
etc.


HDBK-287頁37-38上 para 5.8還有幾個不同(但手法類同)的用2167A為藍本寫SOW的例子

5.8 STEP 7: Record the tailoring decisions in the Statement of Work.
a. Description. The final step in tailoring the standard itself is to record the tailoring decisians in the contract SOW.

b. Tailoring aids. Completed DOD-STD-2167A Tailoring Workaheete.

c. Instructions.
1)Premrepare draft SOW entry. Using the completed DOD-STD-2167A Tailoring Worksheet, prepare a Statement of Work entry that specifies your tailoring decisions. There are several ways of indicating these decisions:

o By exception with each excveption Itemized. One method of specifying tailoring
decisions is to write a SOW paragraph that looks like this:


第一種寫sow的方法,把2167A放上來要求承商遵循,列出其中要刪改的除外條款(需求之2167A段落編號),例子為
"The contractor shall comply with all requirements of DOD-STD-2167A with the following exceptions:
4.1.7 Delete entire paragraph
4.2.6 Delete reference ta Interface Requirements Specification
5.1.2.4 Delete entire paragraph
5.1.4.d Delete entire paragraph
5.5.4 Madify as follows: The contractor shall ...”

o By exception, using global reference. A second method of specifying tailoring decisians is to group all related instructions. For example:


第二種方法,把2167A放上來要求承商遵循,以歸納群組的方式列出其中要刪改的項目,例子為

"The contractor shall comply with all requirements of DOD-STD-2167A with the following exceptions:
1. Delete all references to the Interface Requirements Specification.
2. Replace all references to the system specification with references to the Data System Management specification.”

o BY inclusion. A third method is to list the paragraph numbers of those requirements that YOU have kept, indicating modifications As appropriate. For example


第三種方法,逐條列出2167A條文(需求)以及修訂/刪改處,要求承商遵循,例如

The contractor shall camply with the following requirements of DOD-STD-21 67A, with exceptions as noted:
4.,4.1 ,4.1.3,...
4.2.6 Delete reference to Interface Requirements Specification"


++++++++++++++++++++++++++++++++++++++++++++++++++++++++

您提到881A,....小弟不知您有沒有用過881A啦....然小弟兩份881A都用過,...第一個881A是(小弟先前有提過)STD-881A,1984年起....就是那個沒有軟體WBS時代的標準881A,第二個881A即您現在所提的有軟體WBS的HDBK-881A,事實上,軟體WBS第一次出現,是在STD-881B....小弟1998年起甚至用MS-Project建了一套東東...這軟體的確提供不少幫助....

但是小弟還是不認為放到我國政府的案子會有多少好處(按:正面負面效益加總)
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++

至於1679,....和2167a/498/016/12207是不一樣的,...二者觀念相差很大.....這標準小弟也用過,用英文寫的軟體規格叫IDS/PPS(或者說CPPS)....

1679是綁在美國海軍一大套戰系(Combat System)系統工程(含指定方法論與流程)裡的一個軟體標準,可以用在合約,但不能用裁適(按:例如美海軍的神盾艦其戰系軟體就是用1679那一套發展出來的),美軍某些戰機航電/射控也有的是用1679....

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

您提到時代變遷與軍規改版的問題
245E也有人在草擬中,
是的,小弟一直以來都說245對美國是好的,是合宜的

但對我國言卻不見得....尤其基礎配套沒有的條件下...

這部份小弟不想覆誦舊留言....

打個比方好了,在美國住過的人應該都用過鐵胃,這東西非常地好,幾乎是美國家庭廚房的標準配備

但在我國,廚房就不能裝那玩意兒...

當今聖上...喔不..總統馬先生當年還是市長大人的時候就曾大力反對市民家中裝鐵胃!....何也?....

配套基礎建設的沒有完成嘛(完成比率極低)!...裝了鐵胃將會未蒙其利,反受到環境被大量污染的問題....台北市將到處充滿腥味....

目前我們各地政府/民間用的是垃圾不落地+廚餘回收/再利用

當然,我們也看到各地政府有許多已經積極在挖...
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++
tyrone
發表時間: 2010-09-02 08:16
網站管理員
註冊日: 2003-04-19
來自: CSQA
發表數: 342
Re: 工作條款(SOW)
小弟得思考一下,再繼續這個討論串的意義、必要性,對於讀者的幫助會有多大。
小弟現在大抵對我國政府軍購案的問題又獲得了一些理解。我想,小弟大概只能為這個討論串,做個結語:吾人該與時俱進,深度學習,旁徵博引。

有任何獲取方計畫/專案經理,在規劃CSCI的發展時把Formal Review/Audit(2167A的4.1.2)刪除,那真是太勇敢了,我如果是他/她的長官,我會叫他/她回家好好反省反省吧。當然,把審查與稽核砍掉,代表軟體在發展時,是完全不會用到MIL-STD-1521B (Technical Reviews and Audits for Systems, Equipments, and Computer Software)的。但是這亦代表,獲取方放任供應方(合約商)恣意胡為,完全不予控制的意思。這就跟現在許多政府部門資訊業務委外專案有何分別?他們在發展期間對相關發展文件、技術文件,合約商的工作完全不聞不問(文件最多改改typo、wording、標點符號),只管--程式寫好了沒?--寫好了,我們開始測試吧...,又有何差別?裁適,有許多原則,但對於這種在專案中不做不可的活動,是不會全盤刪除的,而是在執行頻率、深度與範圍去做一些調整。

美國軍方的文件,如果沒有新增或修改,就不會有版本的問題,或也不需要改版。MIL-HDBK-881(1998)與881A(2005)就有很多地方不同,包括連長的樣子都不大一樣。軟體工程有關的美軍標準1679->2167->2167A->498,一路走來,多有變革,環境變了,相應指導文件(DoDD, DoDI)多了,從業人員亦該隨之成長。就像美國軍方亦在隨之成長一樣,進入了裁適自ISO/IEC 12207-1995(E)的IEEE/EIA 12207-1996,到現在,透過IEEE,直接與ISO/IEC 12207:2008接軌,因為ISO/IEC 12207:2008亦即全等於IEEE STD 12207-2008(ISO標準直接將兩者家標準的識別符放在一起)。而文件標準裡IEEE/EIA 12207.1由ISO/IEC 15289所取代(請參閱ISO/IEC 12207-2008中IEEE部分的前言),未來IEEE/EIA 12207.2將會由新版本的ISO/IEC TR 15271所取代。

1679/2167/2167A/498/ISO/IEC 12207在沒有計畫/專案時,亦可以存在,其存在之目的,就是在描述一個軟體生命週期全程(或僅發展部分的生命週期)過程而已,是一份描述性的文件,在給讀者一個標準的軟體生命週期過程的完整印象(具有對從業人員的教育意義)。當然,透過一些方式進入專案時,又是另外一回事了。

在1994年時Dr. Jerome G. Lake在Program Manager, September-October 1994寫了一篇DO WE NEED THE STATEMENT OF WORK? (我們真的需要工作條款嗎?)其結論如下:
Current SOWs are redundant, not well-prepared, and lead to confusion and inefficiencies in providing high-quality products and services with orrect performance features at an affordable price and on time. The time for acquisition reform is now. One place to start is with the SOW.

This exposition challenges the conventional wisdom which dictates that a SOW be utilized to guide the performing activity in a contractual effort. Reform in acquisition requires a challenge to this thinking. I have asserted that a lengthy SOW is no longer needed. I have justified this assertion for acquisitions that have a specification, WBS, and CDRLs, and that require a SEMP, with an accompanying SEMS. The synergy of these documents, with other management documents and plans, provides necessary and sufficient information to guide performing activities in accomplishing a contractual effort, and to provide enough information to tasking activities to track and assess an effort.

Radical ideas often create entrenchment by those who want to protect established and conventional methods. I challenge you to reflect on the arguments presented herein. I trust that such reflection will alter your mind-set on the need for a lengthy SOW associated with a contractual effort for development of a system, large or small, new or incremental. Where my logic has holes in it resulting from my lack of knowledge, don’t prematurely throw away the ideas initiated herein. To my arguments, add your ideas and any needed documents available to the program office to help reduce the need of, and reliance on, lengthy SOWs.

Finally, until management directs the radical change encouraged herein, perhaps as you prepare your next SOW you will reflect on this article. Remember to flow the SOW from the WBS, use MIL-HDBK-245 as a guide, and tailor references in Section III. We just might get better SOWs.
而在此頁一個框框中的文字是: "The existence of specifications, CDRLs and WBS dictionary tasks in the RFP/contract are not sufficient to justify eliminating the SOW as structured today." (規格、CDRL及WBS字典工作的存在,在今天並不足做為消去RFP/合約結構中之SOW的正當理由)。

在今日MIL-HDBK-245 (245C,年份為1991)依然存在,而且改版至MIL-HDBK-245D (1996,之後即無新版本,245D也沒有canceled)。依然作為美軍計畫之合約SOW發展之指導。當然,前後版本之間必定有些改進吧。


----------------
引文:

凡所有相皆是虛妄。見諸相非相。即見如來。

林泰龍
◎軟體品質協會 理事
◎經濟部標準檢驗局資訊及通信國家標準技術委員會(TC21/SC3資訊軟體分組委員會)委員
Youtube Channel: http://www.youtube.com/user/tyrone9304

RCI@Taiwan
發表時間: 2010-09-02 01:10
Not too shy to talk
註冊日: 2008-04-20
來自:
發表數: 24
Re: 工作條款(SOW)
剛剛輸入了半顛竟失敗,重寫時間的關係,請恕小弟謹簡單回應

1. -std與SOW的問題,對話時誤會難免,能說明白就好了,謝謝您的澄清。

2.從498到12207是否也是SOW的問題,小弟的回答"Yes",肯定!
二者有相同的DNA!

3.HDBK-287中的para4.1.2/4.2.9問題,請原諒小弟多放肆幾句
您誤會可大了,不是去刪287的4.1.2,也不是去改287的4.2.9,而是去刪2167A的4.1.2,改2167A的4.2.9!

要被裁適的是2167A,不是287!

來源出在HDBK-287的19頁,para. 4.3.5 Where are tailoring decisions specified?的a.SOW

小弟是原文照抄,一字不改,亦請參閱本頁第一個留言,上面就有較多287之4.3.5的部份節錄,包括這一段,因為已經是第二次引述,所以小弟才會說"複誦"!

MIL-HDBK-287 A Tailoring Guide for DOD-STD-2167A
4.3
4.3.1What is tailoring?
Definition. Tailoring is the process of
o Evaluating each requirement in a selected standard or DID to determine whether it is necessary for a given project.

0 Deleting those requirements that are not needed. Tailoring ia intended to eliminate unnecessary and duplicaye requirements. For standards, a modified version of the requirement may be included in the SOW. For DIDs, requirements may be deleted or partially deleted, but not modfied.



這裡講要刪掉的是2167A的4.1.2 Formal Reviews/Audits(按:即2167A引用到的1521B條文),以及2167A的4.2.9 中參考到SDF的部份
舉例說明把裁適後的2167A放在SOW時會長成什麼樣...

所以小弟才會接著說(恕小弟再"複誦"一次)

這種用法就是已經是把經裁適(去除掉不適用的條文諸如4.1.2和4.2.9中的SDF....後,剩下)的2167A條文作為CSCI發展合約的SOW

4.從498→016→12207的"逐步"裁適配套環境與"危險"問題
裁適環境配套的問題
2167A有287,287提供的10個步驟其原理和498/016/12207的裁適其實是相通的。
再者,498的裁適指導書上面也提供了18個步驟,498和016是雙包胎(一個穿軍服,一個穿便服),而016和12207(95版起)的淵源又是那麼地深厚....

危險的部份
您說得對極了,把2167A/498/016全文照抄當然是危險的,但小弟引用287上面的例子是經過裁適的SOW(我們看到刪掉了Formal Reviews/Audits),也看到了修改不參用SDF...

這和您說的全文照抄2167A/498/016的危境是不同的....

(按:過去,在美軍,真的有發展者拿到的SOW竟是全文照抄2167A,"Copy and past",這是真實發生過的故事)

我們都知道所有標準都需要配合專案裁適,標準的SOW自然不能例外

出不了合用的SOW不是有沒有WBS的問題,而是發包者(籌獲者)對合約標的物有沒有充分了解的問題,了解的SOW和WBS都能弄對,不了解的二者都會搞錯,甚至搞砸....

純就履約言,拿標準SOW來裁適/談判就夠用了...

5.軟體WBS的問題,如果您要認為小地沒有深入了解HDBK-881和245D亦由得您(自由心證是不犯法的)

小弟已經說過,2167A出生時的標準版881是沒有軟體WBS的,但仍然要將CSCI發包出去,還要驗收、結案,佈署使用,美軍現役最先進的戰機F-22其上的航電軟體就是在這樣的背景下發包出去的..且成功驗收..加上我國自己的案子的經驗教訓,沒有WBS,有標準軟體SOW供裁適運用,可行!

另一個案子的動用499的CWBS條款卻差點玩不下去的例子,讓我們深刻體會到制度不同真的有些東西並不是外表看起來那麼美好!

其實您點出的政府基礎建設的問題也是挺好的,基礎建設要務之一就是要把WBS與主/會計和財務制度作一整合,這點很難,加上受監院審計之節制,以現今政府主財制度,更難辦,民間機構或有機會...

基礎建設做好了,想去拿CMMI L5,有機會

而在那之前,被美國政府WBS881綁架的245D是"極難"亦無必要用在我國政府環境的!

2167a/498/016 裡頭的requirements全是"in terms of" SOW!
這些標準,都是用SOW的用語寫的requirements的集合!
本質就是拿來當SOW(或合約)的標準條文!
tyrone
發表時間: 2010-09-01 07:51
網站管理員
註冊日: 2003-04-19
來自: CSQA
發表數: 342
Re: 工作條款(SOW)
引文:
請問,小弟幾時說過"軍規是標準的SOW"或表達過類似說法?
(這是小弟第二次就這個點提問,請您回答並舉證上述說法的來源,小弟並不希望重覆第三次)

按:小弟表達過2167A/498/016是標準的SOW(或可說,是SOW的標準),也表達過諸如1521B中的條文可被2167A引用而成為SOW,但幾時表達過您所說


或許因為 RCI@Taiwan 一直強調"2167A/498/016是標準的SOW",所以小弟引申為 "(所有)軍規是標準的SOW",如果, RCI@Taiwan 沒有那樣的意思,我對於我的擴大引申道歉

但若"2167A/498/016是標準的SOW",由於1995年ISO/IEC 12207:1995(E)發布,美軍將MIL-STD-498 "脫下軍服"給了EIA/IEEE透過P1498轉成EIA/IEEE J-STD-016。並於1998年5月27日以MIL-STD-498 Notice 1發布取消,並以IEEE/EIA 12207代替。以下是內容:
MIL-STD-498, dated 5 December 1994, is hereby canceled. Information regarding software development and documentation is now contained in the Institute of Electrical and Electronics Engineers (IEEE)/Electronics Industries Association (EIA) standard, IEEE/EIA 12207, “Information technology-Software life cycle processes”. IEEE/EIA 12207 is packaged in three parts. The three parts are: IEEE/EIA 12207.0, “Standard for Information Technology-Software life cycle processes”; IEEE/EIA 12207.1, “Guide for ISO/IEC 12207, Standard for Information Technology-Software life cycle processes-Life cycle data”; and IEEE/EIA 12207.2, “Guide for ISO/IEC 12207, Standard for Information Technology-Software life cycle processes-Implementation considerations.”

不知,由此看來,498被取消之後(2167A被498取代,DOD-STD-2167A Notice 1, 1994年12月5日),是否IEEE/EIA 12207也是"標準SOW"?IEEE/EIA 12207的前言為中,有關其運用:
IEEE/EIA 12207.0 may be used to
a. Acquire, supply, develop, operate, and maintain software.
b. Support the above functions in the form of quality assurance, configuration management, joint reviews, audits, verification, validation, problem resolution, and documentation.
c. Manage and improve the organization's processes and personnel.
d. Establish software management and engineering environments based upon the life cycle processes as adapted and tailored to serve business needs.
e. Foster improved understanding between customers and vendors and among the parties involved in the life cycle of a software product.
f. Facilitate world trade in software.

IEEE/EIA 12207.0-1996 (其實就是ISO/IEC 12207:1995(E))第1.5節Limitations中提到:
 This International Standard describes the architecture of the software life cycle processes but does not specify the details of how to implement or perform the activities and tasks included in the processes.
 This International Standard is not intended to prescribe the name, format, or explicit content of the documentation to be produced. This International Standard may require development of documents of similar class or type; various plans are an example. This International Standard, however, does not imply that such documents be developed or packaged separately or combined in some fashion. These decisions are left to the user of this International Standard.
 This International Standard does not prescribe a specific life cycle model or software development method. The parties of this International Standard are responsible for selecting a life cycle model for the software project and mapping the processes, activities, and tasks in this International Standard onto that model. The parties are also responsible for selecting and applying the software development methods and for performing the activities and tasks suitable for the software project.
 This International Standard is not intended to be in conflict with any organization’s policies, standards or procedures that are already in place. However, any conflict needs to be resolved and any overriding conditions and situations need to be cited in writing as exceptions to the application of this International Standard.

有關所指MIL-HDBK-287中下列說法:
引文:

The contractor shall comply with all requirements of DOD-STD-2167A with the following exceptions “ -
4.1.2 Delete entire paragraph
4.2.9 Delete reference to software development files.
etc.

在MIL-HDBK-287小弟並未看到相關的說法,所指287各小節為:
1. MIL-HDBK-287無4.1.2小節
2. 4.2.9標題為:Flexibility of DOD-STD-2167A
看了各節內容也沒有。(在DOD-STD-2167A中也找不到)

引文:
不知這樣的作法,(照您的說法,希望小弟沒誤解您的意思)"危險"在哪?

並非裁適的作法有問題,而是2167A的裁適方式,目前新的標準中,有裁適的原則與裁適的流程(12207置於附錄A/B),但沒有一完整的裁適指引(逐步裁適的說明,在ISO/IEC TR 15271也見不到)。而國家標準有CNS 14837(ISO/IEC 12207)及CNS 14974 (ISO/IEC TR 15271)也一樣有相同的問題,再者有ISO/IEC 15289為文件內容標準,CNS無相對標準。所以聲稱為標準SOW時,在不明的情況下(不能拿您我對於標準的理解來看所有的政府部門專案承辦人),對於政府部門最簡單的做法就是,全部列入(我通通都要,因為是標準的SOW),其思維可以凌駕於標準裁適過程與原則之上。最後的做法就是把廠商"整死",這就是我所謂的"危險"。而沒有WBS的指導,這件事就更加危險(廠商責任就會在莫名其妙中,變成包山包海),因為WBS是系統工程的結果,可以做為寫SOW或訂合約需求的方向、與範圍。直接宣稱那些標準是"標準SOW"是危險的,且也沒有個標準(2167A/498/016/12207)有直接標示:本文件敘述的內容為工程計畫/專案之SOW標準;還是不要擴大引申為宜。雖然人可以創造環境,但是環境沒有形成前,保守比較好

引文:
其實,整個討論串中,小弟還有個異見,也就是您不斷提到的→HDBK-245D(及其背上負載的那一大落包含美國政府制度在內的"包袱",例如881/WBS)是否能不經篩選地全套搬到我國政府運用來擬SOW的問題。

這是我所不明白的,為何RCI@Taiwan 會認為我支持"不經篩選地全套搬到我國政府運用來擬SOW"。再者,恕小弟粗暴地認為RCI@Taiwan 並沒有細讀及深入理解MIL-HDBK-881與MIL-HDBK-245D。我在協會的論壇裡只談軟體生命週期裡可以用的部分(其中包含系統工程),畢竟協會是軟體品質協會。MIL-HDBK-881A只是取了完整的發展概念與方法,給出的也是其中與軟體系統有關者(其中還有武器系統、艦船、火砲、飛彈等等的WBS,這些我都沒有談),而MIL-HDBK-245D也只談了格式與發展的注意事項與用詞/用語,以及可以用的部分。這些其實也就是篩選/裁適的結果了。


----------------
引文:

凡所有相皆是虛妄。見諸相非相。即見如來。

林泰龍
◎軟體品質協會 理事
◎經濟部標準檢驗局資訊及通信國家標準技術委員會(TC21/SC3資訊軟體分組委員會)委員
Youtube Channel: http://www.youtube.com/user/tyrone9304

RCI@Taiwan
發表時間: 2010-09-01 00:57
Not too shy to talk
註冊日: 2008-04-20
來自:
發表數: 24
Re: 工作條款(SOW)
謝您的建議,小弟也試著回顧整個對話過程....

您開始聚焦,回到2167A/498/016的軟體SOW問題,非常好!

但是,您將小弟留言解讀成如下的說法,是有問題的

引文:
RCI@Taiwan 的觀點是:軍規是標準的SOW,包括MIL-STD-498/499,DOD-STD-2167A。(就這麼單純)


請問,小弟幾時說過"軍規是標準的SOW"或表達過類似說法?
(這是小弟第二次就這個點提問,請您回答並舉證上述說法的來源,小弟並不希望重覆第三次)

按:小弟表達過2167A/498/016是標準的SOW(或可說,是SOW的標準),也表達過諸如1521B中的條文可被2167A引用而成為SOW,但幾時表達過您所說

引文:
認定軍用標準(MIL-STD/DOD-STD)或者其他的標準(IEEE或ISO/IEC標準)就是"標準SOW"


很遺憾您會有這樣的認知,小弟承受不起您的如此"認定"

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

是的,2167A/498/016的軟體SOW上,您我的確有異見!

2167A/1521B的條文是否能放到SOW裡面,小弟已引述287中之例子(原諒小弟再複誦一遍)

軟體CSCI的SOW可以是

The contractor shall comply with all requirements of DOD-STD-2167A with the following exceptions “ -
4.1.2 Delete entire paragraph
4.2.9 Delete reference to software development files.
etc.


這種用法就是已經是把經裁適(去除掉不適用的條文諸如4.1.2和4.2.9中的SDF....後,剩下)的2167A條文作為CSCI發展合約的SOW

另外一種用法就是把2167A經裁適後(例如,刪除了諸如4.1.2和4.2.9中的SDF....等)的2167A,附(attatch)到SOW.

不知這樣的作法,(照您的說法,希望小弟沒誤解您的意思)"危險"在哪?

按:小弟先前提到的使用TAILOR這個由Logicon提供的2167a裁適軟體的案子,其軟體發展的SOW就是如此這般談,您能指出其"危險"所在嗎?小弟願洗耳恭聽!

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

其實,整個討論串中,小弟還有個異見,也就是您不斷提到的→HDBK-245D(及其背上負載的那一大落包含美國政府制度在內的"包袱",例如881/WBS)是否能不經篩選地全套搬到我國政府運用來擬SOW的問題。

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
(題外話)
最後,謝謝您對小弟的謬贊,其實小弟的故事可透露一點

1984年,第一次試著使用499+881於某個系統工程編組規劃案,以及另一個計畫的建案規劃!.....第一次知道SEMP該長成什麼樣....
tyrone
發表時間: 2010-08-31 04:41
網站管理員
註冊日: 2003-04-19
來自: CSQA
發表數: 342
Re: 工作條款(SOW)
建議RCI@Taiwan ,也建議所有這個討論串的讀者,從這個討論串的6樓開始了解問題的起因,否則真的會覺得是一場混戰。我們溫習一下:
RCI@Taiwan 的觀點是:軍規是標準的SOW,包括MIL-STD-498/499,DOD-STD-2167A。(就這麼單純)

小弟的觀點,比較複雜:所指這些不是標準的SOW。美軍計畫/專案的SOW,係根據MIL-HDBK-245D HANDBOOK FOR PREPARATION OF STATEMENT OF WORK (SOW)描述的過程與原則發展,不能直接抄錄自各項標準(RCI@Taiwan 所認為的標準SOW)。絕大多數的SOW的發展/準備需要有WBS,當然也有不需要WBS的情況,245D裡也有提到相關的例子(屬於non-personal services contracts)。但是MIL-HDBK-881A裡頭給了8種計畫的WBS前3層(軟體系統的WBS則給到第5層),這些計畫/專案的SOW發展當然是一定要WBS的。

讀者若有興趣可以Review一下每樓的說法,或者全部列印出,仔細比較。當然,這其中RCI@Taiwan 的說法與標準的知識,還是值得參考與學習的。對於RCI@Taiwan 與小弟討論中所提到的各種美國軍方標準及手冊(DOD-STD-2167A, MIL-STD-498, MIL-STD-499B、MIL-HDBK-881A、MIL-HDBK-245D、MIL-HDBK-287),均可以從Internet上免費取得,亦不需要特別的身分鑑別。本討論串的讀者亦可下載這些標準後自行尋找答案,以驗證RCI@Taiwan 與小弟的觀點。

附帶一點:認定軍用標準(MIL-STD/DOD-STD)或者其他的標準(IEEE或ISO/IEC標準)就是"標準SOW"是危險的,若在RFP中,以這些所謂的"標準SOW"當成專案的SOW,將造成過於瑣碎而滯礙難行(而,這樣的RFP內容,與軟體專案管理計畫、軟體發展計畫、IMP/IMS,又有何差異?又,是誰在執行專案?獲取者還是合約商?)。這些談"工程過程(系統工程與軟體工程)"的標準,裁適成為Project defined processes,納入計畫/專案管理計畫是適當的,而從MIL-HDBK-248(Acquisition Streamlining)、MIL-HDBK-287、ISO/IEC TR 15271,ISO/IEC 12207附錄A、B、MIL-STD-498第6節等所提供的裁適資訊,就是在協助這些標準在專案實務上的運用。


----------------
引文:

凡所有相皆是虛妄。見諸相非相。即見如來。

林泰龍
◎軟體品質協會 理事
◎經濟部標準檢驗局資訊及通信國家標準技術委員會(TC21/SC3資訊軟體分組委員會)委員
Youtube Channel: http://www.youtube.com/user/tyrone9304

RCI@Taiwan
發表時間: 2010-08-31 00:07
Not too shy to talk
註冊日: 2008-04-20
來自:
發表數: 24
Re: 工作條款(SOW)
引文:
以下是您所提供文件(美國陸軍有關C4ISR的SOW)中的一段,有關於系統工程部分:
.......
以上的敘述,不會是直接引用MIL-STD-499,所謂"標準SOW"而來的。因為寫得很籠統,把一缸子的系統工程活動的監視與支援活動全寫在一起。而,標準一般(基於表達的需要)會使用一個循序的方式描述過程、活動與工作。


很好!這回您避開了不能用499B的問題,小弟原以為您已經了解小弟先前針對245D中的樣版本SOW與499B關係的回應

可惜
引文:
再看來自同份文件的另一個例子:
3.5.2 The contractor shall develop ICDs for interoperability design and assessment. Supporting analyses shall include system-level interfaces, potential impacts to other system programs and subsystems, and support the development of technical and cost risks (trade-off analyses).
使用"interoperability"於MIL-STD-499B裡尋找,這個字出現的幾個地方,多半在審查活動裡,例如PDR與CDR,而不在Design裡。介面控制文件(ICD)確實出現在Design中,但並未提及interoperability。


您又想試圖從中找出其與499B的關係並予否認,....您難道真的不知道499B仍然不能用嗎(小弟先前不已暗示過了)?....這和2167A/498的處境是不一樣的

要用,就只能用499A,....然後,您還是會找不到499A與interoperability關係,雖然499A也有出現ICD....

知道為何嗎?

首先,您知道ICD是幹啥用的嗎?和interoperability與interoperability Design之關係,以及和IRS/IDD間的關係又是如何嗎?(其實,這裡已經離題了,因為要進入系統工程的實務面了....)


引文:
該文件從格式上來看是不符合MIL-HDBK-245D中的標準格式,但是,245D在第7頁,3.6標準格式乙節中提到:Deviations from the standard format may be made by the writer when necessary to accommodate overriding program needs.(意指:標準格式可由撰寫者就肆應計畫需要之需,自行修改。)所以,仔細讀245D還是很重要的。


這又有啥好提的,美軍規範的運用裡頭不要說Deviations,連Waiver都有可能!

(按:此處規範指的可能是std,也可能是HDBK,但講Deviations或Waiver時多半指的是std,小弟沒有細查,但std應該多半有Deviations,亦不排除Waiver,連std都如此了,HDBK就不必提了吧!)
(再按:Deviations/Waiver也是美軍制度的一環,習慣了,就好了)

再說,SOW本來就沒有那麼多"格式"上的規範必須遵守,只要雙方都滿意且認為可行,在履約條件上的認知無(重大)爭議...價碼時程談得攏....就可以成交了!

當然,245D對美軍還是有點拘束力的,其樣版也是具極高參考價值的,只是小弟不認為必需長成那個樣子才算好的SOW爾,....

而因本欄主題在軟體專案管理下開的,245D上面的東東雖好,卻不以軟體為主,再加上又要去展WBS....

是的,國情不同,基礎建設也不同,....sow真的非要有wbs不可嗎?
RCI@Taiwan
發表時間: 2010-08-30 23:01
Not too shy to talk
註冊日: 2008-04-20
來自:
發表數: 24
Re: 工作條款(SOW)
引文:
或許您想要強調那些就是美軍軍方標準就是SOW,遵重您的看法(但,我還是不認同)~~
您有豐富經驗,但是過往的經驗與實際做法搭不起來時,這代表其中有環節出問題,或者缺乏實務/技術上的可行性(畢竟國情不同)。有些環節代表的可能是執行FMS的廠商有對其國家機密保密之責;或許大可請美國廠商直接用美軍的SOW來充當(「反正不就是標準的條文嗎,而且都是unclassified的呀」,這是從您的角度出發,不是我的,我還是不認為軍方的標準與手冊,就是SOW),可行嗎?如果,那些標準條文就是SOW,下次有機會再參與軍售案時,那就試著那麼說吧。


這誤解可大了,希望您下筆前仔細看清楚小弟的留言/回應
小弟幾時說過美軍的哪份手冊是SOW來著?若小弟說過,您大可不認同,小弟亦會同意您的不認同!(按:您該不會是指小弟引述的287或498指導書的內容吧?若然,建議您再回頭仔細看看小弟相關留言所指為何?)

美軍的制度,標準(-STD)是標準,手冊(-HDBK)是手冊,二者是不同的,可互補,但仍不能混為一談....(注意,小弟先前的留言中應該有暗示到-STD與-HDBK二者的差異...)

就標準的部份,小弟幾時說過所有的標準都是SOW來著?

有關標準SOW,小弟講最多的標準是2167A,其次是498→J-STD-016,間或帶到1521B/480-483/499等...但仍以2167A/498/016為聚焦點

所以我們只要聚焦於2167A/498/016是不是標準的SOW?您若不認同,只要能證明2167A不是標準的SOW就可以了!而小弟只要舉出2167A被美軍當作SOW來使用的實例,不也就結束了?

您舉出了245D裡面的東西,小弟以歷史背景及SOW的實務不受限於245D的那一套回應,再多的SOW都無法證明2167A不是標準SOW

按:小弟舉的TAILOR軟體,以及我國政府用2167A當標準SOW的實例或許因為您沒看到而無法取信。2167A當SOW的部份小弟無法舉證,這牽涉道政府的國家機密是否已解密的問題,所以只能講故事!但,難一定要舉美軍把2167A當SOW用的真實故事不可嗎?

再者,小弟不解,何以小弟的"經驗"會是您所描述的那樣?
小弟舉的2167A的標準SOW的故事失敗了嗎?這個SOW難以履約嗎?
是的,國情不同,所以讓我們過往的"經驗"可以在這個案子中避開WBS與SOW的糾結所產生的風險,讓合約能順利履行,拿到我們要的...
若您以為那個SOW是承商提出的,那您就猜錯了,拿2167A當SOW是我方的主意,承商於是提議用TAILOR來談,由於我方也有TAILOR,雙方都是頭一次經驗,但因為用相同的軟體,同樣是源自2167A原創作者的相關知識,自然好取得共識,幾個傳真修一修,SOW就搞定了....

CMMI是有關於WBS的東東,但別忘了,CMMI自始是出自美國國防部的政策....小弟不玩CMMI,此於小弟如浮雲...但不會擋人財路,樂觀其成...CMMI界的看倌們一路順風了!

至於美軍Classified的東東云云,小弟不知您遇到的FMS Case是如何?....小弟看到的是,只要是FMS Case,賣給我們的部份,該有的資訊都會給,哪怕是C字頭的,S字頭...甚至T字頭的都有!

non-FMS 的案子才可能有不給你C類資料的問題.....

話說回來,讓承商先出SOW來談又有何不好?
tyrone
發表時間: 2010-08-30 10:24
網站管理員
註冊日: 2003-04-19
來自: CSQA
發表數: 342
Re: 工作條款(SOW)
您寫得很辛苦...或許您想要強調那些就是美軍軍方標準就是SOW,遵重您的看法(但,我還是不認同)~~

您有豐富經驗,但是過往的經驗與實際做法搭不起來時,這代表其中有環節出問題,或者缺乏實務/技術上的可行性(畢竟國情不同)。有些環節代表的可能是執行FMS的廠商有對其國家機密保密之責;或許大可請美國廠商直接用美軍的SOW來充當(「反正不就是標準的條文嗎,而且都是unclassified的呀」,這是從您的角度出發,不是我的,我還是不認為軍方的標準與手冊,就是SOW),可行嗎?如果,那些標準條文就是SOW,下次有機會再參與軍售案時,那就試著那麼說吧。

建議您,還是要把MIL-HDBK-245D仔細看完,別漏了任何一字一句。再者,其他的標準、手冊,也是一樣,最好連同這些標準的前言也不要漏掉。務必字字句句去深入理解。最好試著去譯成通順合理的中文後再理解(因為我己這麼做了,覺得獲益良多)。包括像CMMI裡的IPM過程領域有關的,美國軍方還有IMP/IMS的手冊、專案排程也有,這些也都與SOW/RFP的制訂有關的文件,更多的DID....。

再次強調,我貼那些東西的目的,只是要讀者好好去思考而已。在CMMI裡,提到了WBS、SOW,大家都去爭取CMMI評鑑通過了,但是多半只是聽過"SOW"與"WBS"這樣的詞,而實際上是什麼,大概都沒有見過,亦無完整的概念。既然CMMI是來自美國軍方的東西,那就讓大家看看美國軍方的東西到底長什麼樣子而已。經濟部工業局大力推動CMMI而且給了導入廠商補助,顧問努力賺錢之際,是否想過那些typical work product是什麼,那些typical work product怎樣才可以產生,typical work product的內容該有什麼(工業局該好好理解一下這些東西才對,設法補上不足的東西,或是對業界相對應CMMI作法提出配套)。例如"需求配置單(requirement allocation sheet)"就出現在CMMI的typical work product裡,可是我從未見過有導入公司的團隊做需求配置這個動作的...這是SE的東西,但是在CMMI裡於SWE範疇中被用到,它確實可用、好用、而且也應該用,但是沒有公司做,因為顧問不懂,所以客戶廠商不懂,那是美國軍方的東西...。(我自己在提供顧問服務時有教,在協會的課程裡也提過怎麼做)。但是用到了需求配置單,那麼,什麼是WBS元素與CI項目,這些觀念又要串在一起用了。

以下是您所提供文件(美國陸軍有關C4ISR的SOW)中的一段,有關於系統工程部分:
3.5.4 The contractor shall monitor and support system engineering activities; review related documentation; participate in system design concept development; develop system modification and upgrade concepts and requirements; provide system and equipment item engineering analysis to assess reliability, availability, maintainability, and logistical supportability. The contractor shall provide technical assistance at Configuration Control Boards, simulation and software tests, and other software development activities for the subsystems at operations and planning centers. Technical service includes, but is not limited to verification, testing, and configuration management.

以上的敘述,不會是直接引用MIL-STD-499,所謂"標準SOW"而來的。因為寫得很籠統,把一缸子的系統工程活動的監視與支援活動全寫在一起。而,標準一般(基於表達的需要)會使用一個循序的方式描述過程、活動與工作。

再看來自同份文件的另一個例子:
3.5.2 The contractor shall develop ICDs for interoperability design and assessment. Supporting analyses shall include system-level interfaces, potential impacts to other system programs and subsystems, and support the development of technical and cost risks (trade-off analyses).
使用"interoperability"於MIL-STD-499B裡尋找,這個字出現的幾個地方,多半在審查活動裡,例如PDR與CDR,而不在Design裡。介面控制文件(ICD)確實出現在Design中,但並未提及interoperability。

該文件從格式上來看是不符合MIL-HDBK-245D中的標準格式,但是,245D在第7頁,3.6標準格式乙節中提到:Deviations from the standard format may be made by the writer when necessary to accommodate overriding program needs.(意指:標準格式可由撰寫者就肆應計畫需要之需,自行修改。)所以,仔細讀245D還是很重要的。


----------------
引文:

凡所有相皆是虛妄。見諸相非相。即見如來。

林泰龍
◎軟體品質協會 理事
◎經濟部標準檢驗局資訊及通信國家標準技術委員會(TC21/SC3資訊軟體分組委員會)委員
Youtube Channel: http://www.youtube.com/user/tyrone9304

RCI@Taiwan
發表時間: 2010-08-30 00:04
Not too shy to talk
註冊日: 2008-04-20
來自:
發表數: 24
Re: 工作條款(SOW)
引文:

tyrone 寫道:

我認為,可以當成發展SOW的基礎或依據,與"等於"或"就是"SOW是兩回事。我自始至終的意思均是:2167A、498及其他的軍規、手冊等,"可以當成發展SOW的基礎或依據",但它們"不等於"SOW。


這個看法無妨,但您不能否認2167A/498是標準的SOW!

但是您前面說的是

引文:

所以,應該更不可能拿標準去當成SOW,因為這樣會約束了專案的執行彈性。


不之是何意?

(按:小弟已經不只一次提到"裁適")

引文:
另外,若2167A之類的文件或是498是屬於SOW,那麼何以對SOW的發展,又有軍方手冊MIL-HDBK-245, HANDBOOK FOR PREPARATION OF STATEMENT OF WORK (SOW)(目前使用版本為MIL-HDBK-245D,版本日期1996年4月3日),而有關於SOW與WBS之間的關係,即敘述於本文件中。而如果這些工程標準(不論是498或499)是屬於SOW,似乎MIL-HDBK-245D應該寫得更簡單或使用DoDI去做指導即可,亦不需要介紹一個所謂SOW發展的過程/程序/步驟了。

假設把時間點方在1988年7月,以美軍制度言,CI是一個單獨發包項,如美軍某單位欲將某CSCI委外發展,試問CSCI發包合約的SOW要如何訂?

用HDBK-245D那一套嗎?

很遺憾,1988年2月底2167A出生,那時的HDBK-245並不是您現在看到的D版!

而且,那時的881也不是您現在看到的HDBK-881A,也是很不幸的,那個(當時有效)標準版的881沒有提供像目前我們看到的(地位已經降下來了的)HDBK-881A Appendix B (按:那是一個沒有軟體WBS的時代),易言之,對軟體案言,就算把當時的HDBK-245背得滾瓜爛熟,恐怕也很難套用在前述的美軍CSCI委外發展案

易言之,HDBK-245在這時的CSCI委外發展案中是派不上用場的

反之,不考慮太多,單純地用2167A和伴隨的各項標準(如1521B),選用HDBK-287(頂多加上HDBK-248)提供的指導,其實即不難達成SOW協議

一個成功的實例是10餘年前我國委(非美國的)某國承商的某個軟體發展案,其SOW就是在沒有美國政府制度牢籠(如881)下,單純只用2167A的條款(按:其引用標準,如1521B,中的適用條款在此被視同為2167A的一部份)裁適而成,整個過程,沒人考慮HDBK-245

雙方只藉助一個由美商Logicon公司(按:2167A的作者)提供的DOS版軟體→TAILOR(按:該軟體的名稱就叫作TAILOR,一個專門用來裁適2167A而產出軟體發展SOW的軟體)→即很快達成最終裁適協議!

其SOW(不只一個CSCI)用的是在TAILOR上進行"裁適"的結果!

雖然在裁適過程中使用了許多HDBK-287上面沒有提到的手法,也處理了各shells(這部份作法與HDBK-287相符),但並不影響用2167A作為該案唯一軟體發展SOW談判藍本的事實地位!

事實上,該案的裁適結果,其SOW幾乎就是刪除不適用的2167A需求,並針對其中適用的Shells加以處理後的結果!

小弟的記憶,這應該是我國政府歷來委外的軟體發展案中動用2167A作為和承商就SOW進行裁適協商的首例,由於合約雙方都不受美國政府制度約束,發包方並未出PWBS,承包方(似乎也是第一次使用美系的2167A)不必出CWBS,完全甩脫美軍那一套制度,卻讓我們看到了遠異於美國承商的軟體發展管理模式,而軟體的"移轉"(Transition,即2167A的4.6),也是合約雙方用教科書上找不到的模式達成(這是一個在性能績效指標上成功的軟體移轉案例)!


引文:
我在這個討論串裡貼的SOW範例(本討論串3樓中的例子),即來自於MIL-HDBK-245D的附錄。先不談MIL-STD-498,從該範例中的工作條款描述,就可以知道,那些絕對不是直接抄自MIL-STD-499B。因為根本找不到相對的東西。而是在系統工程的過程context中,結合了預期專案的進展、與其他各別專案進程的搭配、以及計畫目標的達成等等而產生的計畫/專案特定的SOW


這和499條文可以是SOW本身並不衝突,反正SOW的表述可以有很多種,且499B從來就沒有生效過,而且,對美國政府言,您很清楚,499系列究竟如何了....可以用嗎(按美國的制度)?

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++
回過頭來談245D自己的問題,就算今天,245D現在仍為有效,她提供了一套結合美軍881與961(還有其它諸多種中)的SOW過程,並且,提供了一些"格式樣版"作為US DOD的指引,看來似乎一切都是那麼的美好.....

然實務上,美軍仍不一定會按照(US DOD)部頒245D提供的"樣版"或"格式"去出SOW...

底下就是245D發佈多年後且生效中,兩個(與245D樣版格式不同的美軍SOW)例子
http://www.smdc.army.mil/Contracts/SMDISIII/SOW10-15-08Draft.doc
https://www.contract-portal.com/Portals/0/COMETS%20Statement%20of%20Work%20(3%20Sep%2003).doc

能解釋發生了何事嗎?
RCI@Taiwan
發表時間: 2010-08-29 23:44
Not too shy to talk
註冊日: 2008-04-20
來自:
發表數: 24
Re: 工作條款(SOW)
您特別提到245D,並提到245D存在的意義問題....

245D既然存在且生效,對美軍(或US DOD)自然有其價值

但不是可以全盤移植(要篩選合用的部份)

若您實際參與過我國政府與外國承商的案子,且實際參與SOW的談判或協商,或許您對是否鼓勵我國政府採用HDBK-245去研訂SOW會有不同的看法....

要使用HDBK-245去準備SOW,建議您將HDBK-245的整個故事(發展、演變史)作一個了解,以及從出生的第一版開始,直到今日,一路走來,她會被什麼東東給"綁住"後,再決定要不要推薦給我國政府採用

(按:民間事業制度彈性較大,可能不會那麼難實施)

以我政府過去的許多(非常大型)案子為例,幾乎沒有一個案子是採用HDBK-245那一套去擬SOW的,有的案子PWBS有架出來,其中卻只有極少項目和SOW有關,事實上,沒有一個案子用WBS去談(或擬)SOW,或說談SOW時會去考量WBS,每一個案子的發包方、承包方皆然。其中,承包方不乏有經驗的美國政府承商,WBS那套對他們言是再熟悉不過的事。

舉個真實發生過的例子,當HDBK-245還是美國海軍所出的古早年代,我國海軍正好有幾個案子委給替美國海軍承包相同裝備(FMS CASE)的承商,這些不同的案子裡面不乏與系統工程關係密切的合約,然從其SOW的草擬(沿用美海軍的SOW)到定稿故事中,完全沒有看到(當年美海軍)HDBK-245的影子在其中....這(些)個SOW當然有我國海軍或發包單位的"裁適",其中亦有為我國環境"量身定做"的條款,還有其他....(其中一個案子在雷根政府時代,被評價為全美第二,僅次於NASA的太空梭,當然案子是成功的,無論從時程掌控、性能績效、或是經費支用任何一個指標評量都是標準的成功案例,會排在NASA之後係吃虧在案子的規模沒人家大)

特別要的提的一點是該(第二名的)案子,我方也是有PWBS的,但與SOW無關

前面講到WBS,順便藉此回應就教CWBS問題,所謂Preliminary 版的CWBS,其實就是Preliminary 版的PWBS中的某(些)個要發包出去的element(s),您要說需要發包者去出Preliminary 版的CWBS也由您(發包者決定哪些element要發包委外),但以發包者(此處指我國政府方)的立場言,不過就是一個還沒展開的項(當然,發包者自己也可以展下去,但無此必要,既然都要包出去了,除非不得已,承商自己展合約責任才會明確,這就是我國制度與美國制度的不同點之一)

按:Preliminary 版的PWBS中要發包出去的每一element(s)都可單獨發包(注意:此時之element(s)不一定已展到CI)....
tyrone
發表時間: 2010-08-28 09:43
網站管理員
註冊日: 2003-04-19
來自: CSQA
發表數: 342
Re: 工作條款(SOW)
引文:

RCI@Taiwan 寫道:
您的回應,老實講,非常令人意外

如果2167A不是標準的SOW(其經裁適後變成履約用的SOW),或說2167A中的requirements(含shall的條文)不能成為SOW,實在不知道要怎麼講下去了?

2167A是不是標準的SOW不是您我用自己解讀的結果說的算,也不是任何人可以隨意解讀的!


我認為,可以當成發展SOW的基礎或依據,與"等於"或"就是"SOW是兩回事。我自始至終的意思均是:2167A、498及其他的軍規、手冊等,"可以當成發展SOW的基礎或依據",但它們"不等於"SOW。否則,MIL-HDBK-245D即無存在的意義。我在這個討論串裡貼的SOW範例(本討論串3樓中的例子),即來自於MIL-HDBK-245D的附錄。先不談MIL-STD-498,從該範例中的工作條款描述,就可以知道,那些絕對不是直接抄自MIL-STD-499B。因為根本找不到相對的東西。而是在系統工程的過程context中,結合了預期專案的進展、與其他各別專案進程的搭配、以及計畫目標的達成等等而產生的計畫/專案特定的SOW

以下取材自MIL-HDBK-245D 3.6.4節SOW的do's and dont's
a. Do's:
• 選擇適任的團隊,並由經驗豐富者帶領。
• 排除 “how to” 需求,因為投標者應在合約下,以最具成本效益的方式提供交付項目下交派工作。
• 使用本手冊第3.8.1節中討論的計畫工作產出分解結構(WBS),勾勒必要的工作投入。
• 如果可以,設定SOW目標以支持獲取計畫(Acquisition Plan, AP)。
• 明白地定義所有列舉之標準及規格的裁適後界限
• 排除設計控制或硬體效能參數,因為此等需要應在規格中涵蓋。
• 就獲取(案)順暢,對人員實施教育。(DFARS 211.002 – 70 合約條款)。
• 當商用項目滿足軍方需求時,對商用項目超越規格項目設定優先權。
• 對商業常規做為獲取的手段設定優先權 (DFARS 212 商用項目獲取 – 通則)。
b. Dont's:
• 指示、描述、或討論合約資料需求清單(CDRL)資料。
• 援用、列舉、或討論資料項目說明(Data Item Description, DID)。雖然SOW本文不包含資料格式及內容調製指示及/或資料交付需求,列於CDRL之資料項目說明編號可以交叉參照至SOW。
• 規定技術建議書準則或評估因子。
• 建立交付時程。(就澄清目的,可以納入重大里程碑)。
• 規定設計控制參數或硬體的效能,因為這些項目應該涵蓋在規格中。
• 在合約商格式可被接受時,強行合約商使用政府部門的格式。
• 過度規定。僅規定所需要的事項,並讓合約商建立履行需求的最佳方法。
• 援用內部管理指示。
• 使用SOW以建立或修定規格。
• 援用手冊、軍種規定、技術命令、或所有其他未根據DoD標準具體寫作的文件。(排除非政府部門文件)


----------------
引文:

凡所有相皆是虛妄。見諸相非相。即見如來。

林泰龍
◎軟體品質協會 理事
◎經濟部標準檢驗局資訊及通信國家標準技術委員會(TC21/SC3資訊軟體分組委員會)委員
Youtube Channel: http://www.youtube.com/user/tyrone9304

(1) 2 3 »
樹狀顯示 | 舊的在前 前一個主題 | 下一個主題 | 頁首

無發表權
 
-=協會通訊地址:330047 桃園市桃園區大林路100號6樓 =-
電話:(03) 367-8567 電子信箱:register@csqa-tw.org.tw=-
-=本網著作權為中華民國資訊軟體品質協會所有,禁止未經授權轉貼節錄=-
Powered by XOOPS , Twe76.net