討論區主頁 軟體工程管理 Configuration Item | 無發表權 |
樹狀顯示 | 新的在前 | 前一個主題 | 下一個主題 | 頁尾 |
發表者 | 討論內容 |
---|---|
joker | 發表時間: 2009-04-02 14:42 |
Not too shy to talk 註冊日: 2006-12-22 來自: 發表數: 31 |
Configuration Item 請問何謂CSCI與HWCI?
CI與Line Replaceable Unit(LRU)是否友直接關聯性? 對於專案而言,應該在那一份文件可以看出所有的xxCI? xxCI應由買方或賣方訂定? 是否有標準可參考? 與Configuration Management是否有關聯性? 就專案發展管理而言,應於何時確定xxCI? |
tyrone | 發表時間: 2009-04-15 11:41 |
網站管理員 註冊日: 2003-04-19 來自: CSQA 發表數: 342 |
Re: Configuration Item CSCI-Computer Software Configuration Item 電腦軟體組態項目 (或電腦軟體構型項目)
HWCI-Hardware Configuration 硬體組態項目 (或硬體構型項目) 以上兩詞其實是舊式的軍用標準的術語,可見於MIL-std-973、MIL-HDBK-61、MIL-STD-2167、MIL-STD-498等等1994年以前發行的工程(系統工程與軟體工程)有關的標準中。在MIL-STD-498"脫下老虎皮,解甲歸田"成為EIA/IEEE J-std-016時,已將這些用詞改為商場用語,而在ISO/IEC 12207:1995年問世後,該相關用詞實際上已改為軟體項目(Software Item)。 CI-Configuration Item組態項目,實際上是為了產品的有效管理,在組態管理的思維下設計出來的一種產品識別與管理術語。從產品管理或組態管理的角度而言,其劃分的方法與其管理有關,並沒有一定。以實際的例子而言,美製的戰鬥系統,整體是一個CI,但是法製的戰鬥系統卻分為六至七個CI。 CI與Line Replaceable Unit是有關聯,但是其關聯性並非建立在組態管理上,而是系統的維護上。因為,CI只是一個用於組態管理的概念詞,實質上指的是一個產品(product)或是產品組件(product component),而Line Replaceable Unit,指的也是一個可在現場替換的單元。其可能設計成一系列可以替換的模組,當模組損壞時,可以立即抽換,在軍方使用的MCS戰鬥系統就是一個很顯著的例子,一個戰鬥系統裡有數部相同的Console,只是裡面跑的程式不同,在整體系統中負責不同的任務,當其中一部Console壞掉時(可能只是一塊模組戰損),而且它又負有戰鬥系統組合的重要角色時,那麼就可以直接拿其他console中相同的模組抽換掉,即可立即恢復戰鬥功能。當然也可以將該Console的軟體轉移至另一部可用的console上,此即整體模組的替換。 xxCI可以由獲取者或供應者決定,因為一個CI就是一個產品的識別,但是,一個產品的生命週期可能很長,此期間又需要有保養與維護的需要,因此,可以從納入獲取者的後勤補保體系的角度去要求,發展者在發展時,就遵循獲取者的後勤補保體系編訂CI識別。當然,有些一般商用現成品,很容易就可以從商場上購得補充,就可以不需要考慮。如果獲取者不限定,則供應者/發展者是可以基於自己內部管理的需要編訂CI。 所有的標準(例如MIL-STD-973、MIL-HDBK-61、IEEE-STD-1042、IEEE-STD-828、EIA-836、ISO/IEC 12207/15288等)僅訂出了組態管理的一些常規、指導原則、應履行的工作,至於CI的劃分與真正的管理實務,仍需要依據獲取者或供應者組織內部需要自行律定。 就專案發展管理而言,各項CI應在專案開始時即定出組態定訂的原則,隨著WBS(work breakdown structure)的產出與細分,CI項目就愈來愈明顯。而CI的項目,就在WBS的架構上,幾乎每一個WBS元素就可以訂為一個CI項目。
凡所有相皆是虛妄。見諸相非相。即見如來。 |
RCI@Taiwan | 發表時間: 2009-10-19 02:58 |
Not too shy to talk 註冊日: 2008-04-20 來自: 發表數: 24 |
Re: Configuration Item 抱歉,很少上來,(上一回是來註冊)
雖然小弟已離開至少18年,然仍有幾件事情澄清 美製戰系,整體並非完全是一個CI,而法製的戰系其CIs數應高達數十 MCS的軟/硬體恐怕也不是那樣子,軍事茶館那邊已有討論,且有原設計者漢威公司公開發表的論文片段說明(這是不涉及軍機的部份) http://taiwanbbs.org/cgi/index.pl?b=mil,s=120,m=1148537491#r196 http://taiwanbbs.org/cgi/index.pl?b=mil,s=120,m=1148537491#r197 http://taiwanbbs.org/cgi/index.pl?b=mil,s=120,m=1148537491#r199 以MCS的軟體為例,其上面至少有2-3個CSCIs(指單純的DCU而言),若為操控台,則其為顯控要多出1-2個CSCI(看如何分工及管理) 事實上,MCS每一Console的軟體為完全identical,當某一Console(例如AAW)故障時,任一正常之Console(例如ASW)均可直接補位,無需"抽換模組"或"移植軟體" CI其實是美國軍方所特有,在美國政府打算將CI「脫下軍服」的那段期間,第一個使用Software Item/Hardware Item代替CSCI/HWCI的是J-std-016 而ISO/IEC 12207:1995似乎與Software Item無關 若小弟沒記錯,協會的會員中應該有人參與過MCS軟體撰寫(或維護),可向他請教 以上敬請參考 |
tyrone | 發表時間: 2009-10-19 18:42 |
網站管理員 註冊日: 2003-04-19 來自: CSQA 發表數: 342 |
Re: Configuration Item 在這個命題當中,美軍戰系是否真的當成一個CI,並非重點。另外談到MCS與戰鬥系統的發展,只是在軍中曾經參與了訓練與計畫管理的工作。
在本項描述當中,需要傳達給讀者的乃是:CI沒有一定的劃分方式,可以根據產品的結構層級與工作的劃分去規劃CI,重點在於能在專案及產品的生命週期(包含營運與維護)當中有效的管理,並對系統的營運與維護提供支援。 至於所謂CI被「脫下軍服」,或者「解除武裝」的故事,只是因為ISO/IEC 12207正式發行之後,美軍已經不在做自行發展標準給業界使用的工作,並將MIL-STD-498移給EIA/IEEE,經由P1498專案,成為EIA/IEEE J-STD-016,這是一個暫行標準。在將MIL-STD 498改為民用版本EIA/IEEE J-STD-016時,配合形態的改變,將軍方用語轉換為民間用語,亦即使用Software Item/Hardware Item代替CSCI/HWCI。這個作法有其過渡性的目的。但基本上,認為美國軍方已經不再使用"CSCI/HWCI",可能並不能那麼武斷,因為至少在2001/2002年右左,個人所取得美軍DII/COE 相關項目(items)的SRS文件時,仍然使用CSCI/HWCI的用法。 當然,ISO/IEC 12207:1995中使用Software Item的故事,個人並不是很清楚,但根據一些文件中,可以知道,ISO/IEC 12207並非1995年才"出現",其發展與沿革,可以追溯至1987年,而1987年美軍尚有2167A,MIL-STD-498是於1994年12月4日發行,J-STD-016則是在1995年9月30日發行。所以孰先孰後,只是一個標準沿革上史的知識而已。或許我們使用標準時,應該要注意的是這些"管理作法"的本意,及作法實作的實務吧。
凡所有相皆是虛妄。見諸相非相。即見如來。 |
joker | 發表時間: 2009-10-22 10:06 |
Not too shy to talk 註冊日: 2006-12-22 來自: 發表數: 31 |
Re: Configuration Item 是否有CMMI-Level x公司能分享如何由System Requirements之 “Functional” allocated至HWCI與CSCI之經驗?
|
RCI@Taiwan | 發表時間: 2009-10-26 23:37 |
Not too shy to talk 註冊日: 2008-04-20 來自: 發表數: 24 |
Re: Configuration Item 您的這個問題嚴格講比較接近「系統工程」範圍,若非系統工程類的CMMI(SE),不見得能講得清楚
反之,講得清楚的,亦不見得非CMMI(SE)不可 您的問題是「系統設計」的工作項目之一,在此之前您需要先進行「系統架構設計」與「行為設計」(498用語)或者說「初步設計」(2167A用語) 「系統架構設計」將系統細分成次系統(Subsystems)或節段(Segments),....然後再往下細分....直到(最底層的系統)CIs 這個"細分"的工作並不一定要由單一角色完成 對於大型系統,您可以只作上面幾個層級segments,然後就可"分包"出去 此時的Requirements Allocation工作便只要到您所看到的那個(最底層的)segments即可 各segments的"分包者"可以個接下去進行segments的"系統分析"產生其"Segments Specifications" 再進行"Segments之架構設計"....如此一直到CI層級 有了CIs以後才是您的需求配置問題,這屬於系統的「細部設計」 一篇(系統工程方面的)論文資料連結如下,這裡面所述應該對您的問題有幫助.... http://www.cs.umu.se/~jubo/Papers/INCOSE06a.pdf The FAR Approach – Functional Analysis/Allocation and Requirements Flowdown Using Use Case Realizations |
樹狀顯示 | 新的在前 | 前一個主題 | 下一個主題 | 頁首 |
無發表權 | |