軟件設計的最終目標是要取得最佳方案。
“最佳”是指在所有候選方案中，就節(jié)省開發(fā)費用，降低資源消耗，縮短開發(fā)時間的條件，選擇能夠贏得較高的生產(chǎn)率、較高的可靠性和可維護性的方案。在整個設計的過程中，各個時期的設計結果需要經(jīng)過一系列的設計質(zhì)量的評審，以便及時發(fā)現(xiàn)和及時解決在軟件設計中出現(xiàn)的問題，防止把問題遺留到開發(fā)的后期階段，造成后患。
概要設計的評審
軟件概要設計監(jiān)理的目的是對軟件概要設計有關內(nèi)容（重點是軟件的結構、軟件的功能、軟件的結構、接口設計、接口關系等）、概要設計過程、概要設計活動、文檔格式進行審查，確定承建單位提出的軟件總體結構設計是否實現(xiàn)了軟件需求規(guī)格說明的要求，確認是否滿足要求；給出是否符合要求的結論；確定其可否作為軟件詳細設計的前提和依據(jù)。
檢查項
清晰性
1.是否所設計的架構，包括數(shù)據(jù)流，控制流和接口，被清楚地表達了？
2.是否所有的假設、約束、策略及依賴都被記錄在本文檔了？
3.是否定義了總體設計目標？
完整性
4.是否所有的以前的TBD（待確定條目）都已經(jīng)被解決了？
5.是否設計已經(jīng)可以支持本文檔中遺留的TBD有可能帶來的變更？
6.是否所有的TBD的影響都已經(jīng)被評估了？
7.是否仍存在可能不可行的設計部分？
8.是否已記錄設計時的權衡考慮？ 該文件是否包括了權衡選擇的標準和不選擇其它方案的原因？
依從性
9.是否遵守了項目的文檔編寫標準？
一致性
10.數(shù)據(jù)元素、流程和對象的命名和使用在整套系統(tǒng)和外部接口之間是否一致？
11.該設計是否反映了實際操作環(huán)境（硬件、軟件、支持軟件）？
可行性
12.從進度、預算和技術角度上看該設計是否可行？
13.是否存在錯誤的、缺少的或不完整的邏輯？
數(shù)據(jù)使用
14.所有復合數(shù)據(jù)元素、參數(shù)以及對象的概念是否都已文檔化？
15.是否還有任何需要的但還沒有定義的數(shù)據(jù)結構，反之亦然？
16.是否已描述最低級別數(shù)據(jù)元素？是否已詳細說明取值范圍？
功能性
17.是否對每一下級模塊進行了概要算法說明？
18.所選擇的設計和算法能否滿足所有的需求？
接口
19.操作界面的設計是否有為用戶考慮（例如：詞匯、使用信息和進入的簡易）？
20.是否已描述界面的功能特性？
21.界面將有利于問題解決嗎？
22.是否所有界面都互相一致，與其它模塊一致，以及和更高級別文檔中的需求一致？
23.是否所有的界面都提供了所要求的信息？
24.是否已說明內(nèi)部各界面之間的關系？
25.界面的數(shù)量和復雜程度是否已減少到最小？
可維護性
26.該設計是否是模塊化的？
27.這些模塊具有高內(nèi)聚度和低耦合度？
28.是否已經(jīng)對繼承設計、代碼或先前選擇工具的使用進行了詳細說明？
性能
29.主要性能參數(shù)是否已被詳細說明（例如：實時、速度要求、磁盤輸入/輸出接口等）？
可靠性
30.該設計能夠提供錯誤檢測和恢復（例如：輸入輸出檢查）？
31.是否已考慮非正常情況？
32.是否所有的錯誤情況都被完整和準確地說明？
33.該設計是否滿足該系統(tǒng)進行集成時所遵守的約定？
易測性
34.是否能夠對該套系統(tǒng)進行測試、演示、分析或檢查來說明它是滿足需求的？
該套系統(tǒng)是否能用增量型的方法來集成和測試？
可追溯性
35.是否各部分的設計都能追溯到需求說明書的需求？
36.是否所有的設計決策都能追溯到原來確定的權衡因素?
37.所繼承設計的已知風險是否已確定和分析？
詳細設計的評審
軟件詳細設計監(jiān)理的目的是對軟件詳細設計有關內(nèi)容（重點是軟件的算法、數(shù)據(jù)結構、數(shù)據(jù)類型、異常處理、計算效率等）、詳細設計過程、詳細設計活動、文檔格式進行審查，確定承建單位提出的軟件詳細設計內(nèi)容是否實現(xiàn)了軟件概要設計的要求，確認是否滿足要求；給出是否符合要求的結論；確定其可否作為軟件編碼的前提和依據(jù)。
檢查項
清晰性
1.所有單元或過程的目的是否都已文檔化？
2.包括了數(shù)據(jù)流、控制流和接口的單元設計是否已清晰的說明？
完整性
3.是否已定義和初始化所有的變量、指針和常量？
4.是否已描述單元的全部功能？
5.是否已詳細說明用來實現(xiàn)該單元的關鍵算法（例如：用自然語言或PDL）?
6.是否已列出該單元的調(diào)用？
依從性
7.該文檔是否遵循了該項目已文檔化的標準？
8.是否采用了所要求的方法和工具來進行單元設計？
一致性
9.數(shù)據(jù)元素的命名和使用在整個單元和單元接口之間是否一致？
10.所有接口的設計是否互相一致并且和更高級別文檔一致？
正確性
11.是否處理所有條件 （大于、等于、小于零、switch/case）？是否存在處理“case not found”的條件？
12.是否正確地規(guī)定了分支（邏輯沒有顛倒）？
數(shù)據(jù)使用
13.是否所有聲明的數(shù)據(jù)都被實際使用到？
14.是否所有該單元的數(shù)據(jù)結構都被詳細說明？
15.是否所有修改共享數(shù)據(jù)（或文件）的程序都考慮到了其它程序對該共享數(shù)據(jù)（或文件）的存取權限？
16.是否所有邏輯單元、時間標志和同步標志都被定義和初始化？
接口
17.接口參數(shù)在數(shù)量、類型和順序上是否匹配？
18.是否所有的輸入和輸出都被正確定義和檢查？
19.是否傳遞參數(shù)序列都被清晰的描述？
20.是否所有參數(shù)和控制標志由已描述的單元傳遞或返回？
21.是否詳細說明了參數(shù)的度量單位、取值范圍、正確度和精度？
22.共享數(shù)據(jù)區(qū)域及其存取規(guī)定的映射是否一致？
可維護性
23.單元是否具有高內(nèi)聚度和低耦合度（例如：對該單元的更改不會在該單元有任何無法預料的影響并對其它單元的影響很小）？
性能
24.是否該單元的所有約束例如過程時間和規(guī)模都被詳細說明？
可靠性
25.初始化是否使用到缺省值，缺省值是否正確？
26.是否在內(nèi)存訪問的時候執(zhí)行了邊界檢查（例如：數(shù)組、數(shù)據(jù)結構、指針等）來確保只是改變了目標存儲位置？
27.是否執(zhí)行輸入、輸出、接口和結果的錯誤檢查？
28.是否對所有錯誤情況都發(fā)出有意義的信息？
29.對特殊情況返回的代碼是否和已規(guī)定的全局定義的返回代碼相匹配？
30.是否考慮到意外事件？
易測性
31.是否能夠對每個單元進行測試、演示、分析或檢查來說明它們是滿足需求的。
32.該設計是否包含檢查點來幫助測試（例如：有條件的編譯代碼和數(shù)據(jù)聲明測試）？
33.是否所有的邏輯都能被測試？
34.是否已描述測試程序、測試數(shù)據(jù)集和測試結果？
可追溯性
35.是否設計的每一部分都能追溯到其它項目文檔的需求，也能追溯到更高級別文檔的需求？
36.是否所有的設計決定都能追溯到權衡考慮？
37.單元需求是否都能上溯到更高級別的文檔？ 更高級別文檔的需求是否已經(jīng)在單元中體現(xiàn)？
設計監(jiān)理總則
軟件設計監(jiān)理的基本準則包括： 審查提交的文檔是否齊全，審查文檔編制與描述工具是否符合規(guī)范。確定承辦單位提出的軟件總體結構設計是否實現(xiàn)了軟件需求規(guī)格說明的要求，評價軟件設計方案與數(shù)學模型的可行性，評價接口設計方案和運行環(huán)境的適應性，審查軟件集成測試計劃的合理性和完備性，審查數(shù)據(jù)庫設計的完備性和一致性。并確定該階段文檔能否作為詳細設計的依據(jù)，決定可否轉入詳細設計階段。確認軟件詳細設計文檔的內(nèi)容符合軟件編碼的要求。
設計階段中監(jiān)理單位要盡可能與業(yè)主單位協(xié)調(diào)配合工作，聽取業(yè)主單位從業(yè)務角度出發(fā)提出的對開發(fā)方設計的意見。監(jiān)理單位主要從文檔的規(guī)范性、可實施性出發(fā)，以國家相關標準為依據(jù)，從軟件工程學的角度對承建單位提出意見與建議，配合業(yè)主單位工作，敦促承建單位做好工程項目的設計工作。在設計階段，監(jiān)理單位主要針對需求的覆蓋性及可跟蹤性、模塊劃分的合理性、接口的清晰性、技術適用性、技術清晰度、可維護性、約束與需求的一致性、可測試性、對軟件設計的質(zhì)量特性的評估、對軟件設計的風險評估、對比情況、文檔格式的規(guī)范性等幾個方面進行評審。在此過程中，業(yè)主單位也需要對設計文檔做檢查，主要在功能設計是否全面準確地反映了需求、輸入項是否完全與正確并符合需求、輸出項是否符合需求、與外界的數(shù)據(jù)接口是否完全與正確并符合需求、各類編碼表是否完全與準確并符合需求、界面設計是否符合需求、維護設計是否符合需求、各類數(shù)據(jù)表格式和內(nèi)容是否符合要求、是否存在其它有疑問的設計等幾個方面進行核查。
設計的評審內(nèi)容
（1） 可追溯性：即分析該軟件的系統(tǒng)結構、子系統(tǒng)結構，確認該軟件設計是否復蓋了所有已確定的軟件需求，軟件每一成分是否可追溯到某一項需求。
（2） 接口：即分析軟件各部分之間的聯(lián)系，確認該軟件的內(nèi)部接口與外部接口是否已經(jīng)明確定義。模塊是否滿足高內(nèi)聚和低耦合的要求。模塊作用范圍是否在其控制范圍之內(nèi)。
（3） 風險：即確認該軟件設計在現(xiàn)有技術條件下和預算范圍內(nèi)是否能按時實現(xiàn)。
（4） 實用性：即確認該軟件設計對于需求的解決方案是否實用。
（5） 技術清晰度：即確認該軟件設計是否以一種易于翻譯成代碼的形式表達。
（6） 可維護性：從軟件維護的角度出發(fā)，確認該軟件設計是否考慮了方便未來的維護。
（7） 質(zhì)量：即確認該軟件設計是否表現(xiàn)出良好的質(zhì)量特征。
（8） 各種選擇方案：看是否考慮過其它方案，比較各種選擇方案的標準是什么。
（9） 限制：評估對該軟件的限制是否現(xiàn)實，是否與需求一致。
（10） 其它具體問題：對于文檔、可測試性、設計過程，……，等等進行評估。
在這里需要特別注意：軟件系統(tǒng)的一些外部特性的設計，例如軟件的功能、一部分性能、以及用戶的使用特性等，在軟件需求分析階段就已經(jīng)開始。這些問題的解決，多少帶有一些“怎么做”的性質(zhì)，因此有人稱之為軟件的外部設計。
McGlanghlin給出在將需求轉換為設計時判斷設計好壞的三條特征：
① 設計必須實現(xiàn)分析模型中描述的所有顯式需求，必須滿足用戶希望的所有隱式需求。
② 設計必須是可讀、可理解的，使得將來易于編程、易于測試、易于維護。
③ 設計應從實現(xiàn)角度出發(fā)，給出與數(shù)據(jù)、功能、行為相關的軟件全貌。
以上三點就是軟件設計過程的目標。為達到這些目標，必須建立衡量設計的技術標準。
① 設計出來的結構應是分層結構，從而建立軟件成份之間的控制。
② 設計應當模塊化，從邏輯上將軟件劃分為完成特定功能或子功能的構件。
③ 設計應當既包含數(shù)據(jù)抽象，也包含過程抽象。
④ 設計應當建立具有具有獨立功能特征的模塊。
⑤ 設計應當建立能夠降低模塊與外部環(huán)境之間復雜連接的接口。
⑥ 設計應能根據(jù)軟件需求分析獲取的信息，建立可驅動可重復的方法。
軟件設計過程根據(jù)基本的設計原則，使用系統(tǒng)化的方法和完全的的設計評審來建立良好的設計。
核心關注：拓步ERP系統(tǒng)平臺是覆蓋了眾多的業(yè)務領域、行業(yè)應用，蘊涵了豐富的ERP管理思想，集成了ERP軟件業(yè)務管理理念，功能涉及供應鏈、成本、制造、CRM、HR等眾多業(yè)務領域的管理，全面涵蓋了企業(yè)關注ERP管理系統(tǒng)的核心領域，是眾多中小企業(yè)信息化建設首選的ERP管理軟件信賴品牌。
轉載請注明出處：拓步ERP資訊網(wǎng)http://m.hanmeixuan.com/
本文標題：概要設計詳細設計階段的監(jiān)理
本文網(wǎng)址：http://m.hanmeixuan.com/html/news/10515524530.html
相關文章
