徐長梅,楊鳳年,尹俊文
(1.長沙學院教務處,湖南 長沙 410022; 2. 湖南格凡安信科技有限公司,湖南 長沙 410008)
六十年代的軟件危機,引起計算機領域對軟件的高度關注,“軟件工程”概念應運而生,繼而引出了大量與工程相關的管理問題.在軟件項目中,質量、成本和時間形成了管理三要素[1],所有的管理決策以及后續的管理活動都需要對三要素進行估計和測量.
特別是在軟件開發項目中,軟件開發成本主要取決于人力成本,而人力成本又取決于軟件項目周期——時間,粗略地說人力成本等于人數*人均工資*時間,在這個公式中人數*人均工資*時間稱為軟件開發工作量.
為了測算軟件開發工作量,人們發明了模型法、專家法和類比法等諸多方法,在這些方法中,核心的因素只有一個——軟件規模.軟件規模的度量最直觀的方法是代碼行(LOC)[2],但是代碼行度量方法存在兩個固有的缺點,其一是度量標準不穩定——軟件代碼行取決于編程人員的經驗、技術水平和編程語言;其二是度量標準可能不存在——代碼只有在軟件開發完成時才是確定的,在軟件項目立項、需求分析和設計階段,代碼并不存在.
20世紀70年代,IBM公司的Allan Albrecht引入了軟件功能規范中的功能點分析(FPA)思想[3],提出了一種對軟件功能“點”計數模型,從而擺脫了代碼行方法對軟件開發技術的依賴.Albrecht的模型需要從軟件功能規格說明中識別出5種類型的組件:輸入、輸出、查詢、邏輯內部文件和邏輯外部文件,分別對這五個組件進行計數并計算這些計數的加權和,從而得到軟件的未調整功能點,最后根據軟件的其他因子調整這個加權和,最終生成軟件功能規模值.Albrecht模型最終形成了軟件功能規模度量方法IFPUG[4].
IFPUG方法出現之后,在20世紀80年代到90年代初期,正值計算機在各行業得到廣泛應用的時期,各類管理信息系統(MIS)層出不窮,IFPUG方法在軟件項目管理中受到推崇.但是由于軟件系統逐漸涵蓋更廣泛的領域,對軟件規模的度量也拓展到軟件項目的整個生命周期,度量人員發現IFPUG功能規模度量方法存在若干的問題,這其中包括IFPUG方法不適用于實時系統度量,也不能滿足軟件項目早期的管理要求,甚至在軟件功能復用中存在重復計數的缺陷.雖然在此期間Albrecht模型衍生出了Mk-II度量方法,依然無法掩蓋功能規模度量中存在的諸多問題.
在20世紀90年代后期,軟件項目管理對功能規模度量方法(FSM)采取了審慎的態度[5],也催生了更加通用的功能規模度量方法——全功能點(FFP)方法.新一代FSM以COSMIC[6]為代表,包括FiSMA[7]、NESMA[8]等各種ISO標準,它們對軟件特性進行了一般化建模,采用了模型+應用指南的模式來指導軟件規模度量實踐,分別就實時系統、GUI系統、Web系統等提出了自己的解決方案.
盡管新一代FSM對GUI系統、Web系統等多層體系結構系統給出了答案,但是這個答案并不完全,本文就COSMIC、FiSMA、NESMA在軟件規模度量實踐中存在的問題進行分析,討論了軟件開發的分層問題以及軟件分層對功能點重復計數的影響,并提出了一些減少計數重復的若干措施.
分層是解決復雜軟件系統問題的最常見技術[9].分層技術至少有兩個不可忽視的優點,一個是重用,下層軟件功能可以在上層軟件中重復使用,降低了軟件復雜度,也減少了質量風險;第二個優點是封裝,下層軟件可以抹平再下層系統的差異性,為上層軟件提供統一的功能接口,從而提高了上層軟件的內聚性.
IFPUG FPA和COSMIC FFP所采用的軟件模型,抽取目標軟件(待度量軟件)與外部環境之間的交互特性,通過度量目標軟件與外部環境的交互復雜度來計算軟件功能規模,因此在FSM中,劃定目標軟件的外部邊界是至關重要的.目標軟件的外部邊界由人機接口、軟硬件接口和軟件之間的接口組成.如果目標軟件處于一個復雜軟件系統的某一層次,那么目標軟件的外部環境自然就包括它的上層軟件和下層軟件.但是如果目標軟件本身是一個分層系統,那么在上下層中功能之間的交互該如何度量呢?
Client/Server模型是典型的分層系統,無論是GUI系統還是Web系統都采用了Client/Server模型.Client與Server的分離隔離了人機交互邏輯和業務處理邏輯,但是Client與Server之間的應用程序邊界具有獨特的特性,因此可能會發生功能重復.
對于使用IFPUG的度量人員來說,是否應該重復計算邏輯事務,從而在Client端復制Server系統事務?TOTALMETRCS認為,前后端是由兩個團隊獨立完成的,因此前后端對同一事務會實現各自自己的功能,為完成同一事務所實現的功能交互應該獨立計算.而且“由于應用程序邊界的定位,Client系統和Server系統對功能的重復計算已被視為一種務實的解決方案”[10].
COSMIC FFP使用“層(Layer)”概念來解決多層軟件的度量問題,試圖度量多層軟件中每個獨立層次的規模.COSMIC FFP不再拘泥于計算整個軟件的規模度量,而是采用更靈活的度量方式,可以給出針對每個層次的度量結果.
FiSMA則給出了度量多層體系結構軟件的具體指南,就“用戶接口-業務邏輯-數據訪問”這一典型的三層結構給出了明確的度量規則(集合),提高了FSM的一致性[11].
綜上所述,多層軟件系統始終是FSM特別關注的度量對象和實施對象.但是這樣的解決方案是不完整的.
新一代FSM力圖建立一個與技術無關的度量模型,主要目的是想實現全生命周期的軟件規模度量.軟件分層是體系結構問題,主要出現在軟件設計階段.上述的解決方案仍然不能解決軟件開發早期階段的問題,特別是在軟件項目立項和需求分析階段.
軟件層次的劃分在很多的系統中并不明顯,而是在分析和設計中逐步演化而來的[12],要求先劃分層次,然后再進行度量,是非常困難的.為了解決一個難題,有可能會引入一個更困難的工作,對于功能管理來說是不可以接受的.
課程注冊系統[13]和網關系統[14]是COSMIC官方提供的兩個基準案例,目的是通過對這兩個案例的分析指導具體的FSM實踐.
課程注冊系統一共有登錄、添加教授、修改教授、刪除教授、選擇要教的課程、新增學生、修改學生、刪除學生、創建課程表、修改課程表、刪除課程表、關閉注冊、提交成績、查看成績報告卡等14個功能過程,總計功能點為106Cfps.
網關系統則包含登錄交易、更改密碼、注銷交易、定貨、列出帳戶訂單、訂單帳戶對帳單、顯示語句摘要、臨時目錄命令、凍結登錄ID、注冊產品類別、刪除產品類別、產品類別類別、用戶產品類別、獲取帳戶余額、獲取帳號序列號、獲取最近的N筆交易、獲取產品類別的序列號等17個功能過程,總計功能點為108Cfps.
在課程注冊系統中,查詢教授、學生和課程表是在刪除和修改教授、學生和課程表等功能過程中必須完成的操作.網關系統的獲取帳戶余額、獲取帳號序列號、獲取最近的N筆交易、獲取產品類別的序列號等功能過程被其他的功能過程調用.
在COSMIC FFP的參考文檔中,他們對這些存在公共關系的功能過程或者操作序列采取了“視而不見”的“鴕鳥”策略.這遵循了COSMIC FFP的一般原則,這樣的功能過程或者操作序列發生在層(軟件)內部,不再識別內部的調用關系.
但是我們認為,這樣的功能的功能過程或者操作序列肯定會被程序設計人員識別出來,至少形成一個公共的庫(組件)提供給其他人員重用.值得爭論的是,這樣的庫(組件)是否是技術無關的,畢竟新一代FSM力圖實現一個與技術無關的度量方法.但是我們的觀點是,這樣設計公共(通用)零配件(組件)的方法與軟件開發技術無關,而應該是一種工程常識,從生產成本和質量控制角度看是一個必須的管理措施.這些公共組件雖然不能稱為完全意義的軟件層次,但是確實在外部環境和其他功能過程之間建立一種層次關系.
為了能夠準確的將公共操作序列抽象為公共功能過程,我們遵循以下規則:
規則一:任何一層至少包含一個功能過程.
規則二:任何識別出來的層次都處于當前層的下一層.
規則三:被調用的功能過程被放置于新的下一層中.
在這樣的規則之下,度量過程中使用規則四、規則五和規則六識別重復的操作序列.
規則四:抽取的公共操作序列必須滿足功能過程定義.
規則五:重復出現的、并且滿足規則四的操作序列識別為功能過程.
規則六:將功能過程中滿足規則五的操作序列都替換成功能過程的調用,即以此Entry和Exit.
增加了新的規則之后,則形成了兩種不同的度量結果,如表1和表2.兩個案例中雖然產生的差異小于10%,但是在并不表明這個差異可以忽略不計[13].
我們的方法借鑒了軟件分層技術,識別出軟件需求中的公共組件,符合工程常識,與COSMIC FFP的常規差別在于軟件層次的劃分時機,我們認為軟件中的層次劃分不僅存在于軟件設計階段,在業務分析階段依然可以識別出軟件層次.
相較于COSMIC FFP的常規方法,如果需要給出軟件的整體規模,我們的方法存在著重復度量的問題,為此,我們也借鑒了FiSMA的實踐指南,采用雙向識別、單向計數的規則,這樣就可以較好的去除重復的計數.
規則七:度量軟件的整體規模時,如果包含多個層次,那么上層功能過程僅僅對功能過程中調用下層功能過程的Exit計數,不對上層功能過程調用下層功能過程的Entry計數.下層功能過程僅僅對Exit計數,也不對Entry計數.
在上述兩個案例中,我們的最終結果分別是87Cfps和102Cfps.