請問何謂CSCI與HWCI?
CI與Line Replaceable Unit(LRU)是否友直接關聯性?
對於專案而言，應該在那一份文件可以看出所有的xxCI?
xxCI應由買方或賣方訂定?
是否有標準可參考?
與Configuration Management是否有關聯性?
就專案發展管理而言，應於何時確定xxCI?

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項目。

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

抱歉，很少上來，(上一回是來註冊)

雖然小弟已離開至少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軟體撰寫(或維護)，可向他請教

以上敬請參考

在這個命題當中，美軍戰系是否真的當成一個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日發行。所以孰先孰後，只是一個標準沿革上史的知識而已。或許我們使用標準時，應該要注意的是這些"管理作法"的本意，及作法實作的實務吧。　

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

是否有CMMI-Level x公司能分享如何由System Requirements之 “Functional” allocated至HWCI與CSCI之經驗?

您的這個問題嚴格講比較接近「系統工程」範圍，若非系統工程類的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