第二階段系統分析

需求建模CollegeofComputerScienceandTechnologyZhejiangUniversity階段概述本階段是SDLC五個階段中的第2個階段在上一階段，系統規劃階段，分析員已經做了初步的調查，了解了更多的系統需求，并從技術、經濟、社會和文化、進度、資源等方面，確定了項目需求的合理性和可行性本階段，分析員將使用需求建模、數據和過程建模及對象建模來描述新系統在進入到下一階段前，還需要考慮系統開發策略需求建模在需求建模的工作環節，需要采用基于團隊的方法收集系統項目事實，準備文檔以及創建要用于系統設計和開發的模型這其中需要經歷一系列的過程，包括使用事實發現技術，如會談、文檔復查、觀察、問卷調查、抽樣和調查研究等獲取需求列出并描述需求，包括輸入、過程、輸出以及性能、控制等定義整體擁有成本做一次成功的會談最后，使用有效的文檔編制方法，產生系統需求文檔，并將此有效的文檔編制方法貫穿項目始終系統分析階段概述所謂系統分析，其總體目標就是了解項目系統，確保其支持業務需求，為系統開發奠定堅實的基礎在這一階段，通常都會使用模型和其它文檔工具來描述和呈現將要建立的系統系統分析活動系統分析主要包括四項活動：需求建模、數據和過程建模、對象建模、開發策略考慮如圖所示，盡管瀑布模型呈現了順序特征，但在實際的建模過程中，每當發現新的事實，或者系統需求有改變時，三種建模任務之間總會產生典型的交互行為系統分析階段的每一個活動都有最終產品及一個或多個里程碑，大項目的系統活動往往需要很多工作來進行人、任務、資源、時間、預算等的協調需求建模數據和過程建模對象建模開發策略系統分析技術由于新的信息系統的開發將會涉及并影響使用該系統的企業的所有人，因此，采用合適的系統分析技術顯得尤為重要首先，需要分析員具有很強的分析能力和人際交往能力分析員擁有強的分析能力使其能夠較快確定問題核心，評價關鍵元素，并創建有用的解決方案而人際交往能力對分析員來說更為重要。因為，分析員需要和所有工作層次的人共同工作，協調用戶的需求沖突，并最終達成對系統需求的共同一致另外，系統分析階段的工作策略也至關重要，它將影響到系統分析工作的順利進行，以及系統需求的完整取得和眾人的一致認同通常都會采用從系統分析的初始就采用面向團隊的開發策略面向團隊的方法和技術面向團隊的開發方法給我們帶來的最為明顯的好處就是，系統需求獲取的高效以及較低的需求獲取成本另外，用戶的參與也使得需求能夠更好地貼合用戶，發現問題可以盡早發現并得到糾正面向團隊的方法和目前仍然流行的結構化方法有較大的不一樣，后者當且僅當需要用戶的輸入或確認時，才和用戶溝通基于團隊的開發模式事實是已經存在一段時間了，其中常見的一種就是所謂的聯合應用程序開發(JAD)——進行事實發現和需求建模的面向用戶開發技術另一種流行的方法是快速應用程序開發(RAD)，用戶可以參與開發過程的每一步JAD通常只集中于事實發現和需求決策上，而RAD則針對系統開發任務的整個過程提供了一種快速跟蹤的方法，包括計劃、設計、構建和實施聯合應用程序開發在JAD中，用戶可以作為一個積極的參與者參與開發過程目前典型的用戶參與策略是JAD團隊技術，就是將用戶、經理、IT專業人員組成任務團隊，一起收集信息，討論并定義新系統需求下表是典型的JAD參與者及其任務JAD參與者任務JAD項目領導制定JAD會議議程并主持會議高層管理者為項目提供企業級授權和支持經理為項目提供部門級支持，了解項目如何支持業務功能和需求用戶在當前操作中，提供期望的日常任務流程的操作需求描述系統分析員為JAD成員提供技術幫助和資源記錄員為JAD會議創建文檔，和分析員一起創建新系統模型

但JAD方法也有缺點，如資源開銷會比傳統的方法更大。不過與用戶參與帶來的好處，如用戶對新系統的支持度提高、新系統更容易成功等好處相比，大多數情況下，開銷的增加還是值得的快速應用程序開發這是一種基于團隊的技術，能夠加速信息系統的開發，產生機能信息系統和JAD不同的是，JAD的最終產品是需求模型，而RAD作為一個完整、擁有4個階段的生命周期，其最終產品則是新的信息系統RAD非常依賴原型的創建和用戶的參與允許用戶盡可能早地檢查工作模型，以確定是否滿足他們的需求，并提出修改建議根據用戶的輸入修改原型，反復交互直至用戶滿意項目組使用CASE工具構建原型，并創建一系列連續的文檔RAD階段和活動RAD模型由四個階段組成：需求計劃、用戶設計、構建和驗收注意用戶設計和構建階段之間連續的交互過程

RAD的目標就是通過用戶參與來縮減資源消耗

RAD的優點是高效、低成本缺點是強調系統本身結構，而可能忽略企業戰略上的業務需求另外，加速開發會導致質量等目標被忽略需求計劃構建用戶設計轉換任務

用戶、經理和IT職員對企業需求、項目范圍和系統需求達成一致意見獲得批準繼續任務

用戶參與構建模型和原型進行嚴密的JAD型會議任務

程序和應用開發編碼單元、集成和系統測試任務

數據轉換全面測試系統變更用戶培訓建模工具和技術

建模包括用來在各個開發階段描述系統的方法，包括圖、表、形式表達及非技術語言模型往往會有助于用戶、項目相關人員、管理人員等理解系統的設計，而建模描述工具可以幫助這樣的理解，以及有利于用戶與系統的交互常用的工具主要有：CASE工具、功能分解圖、數據流圖、統一建模語言等CASE工具在CASE工具環境下，分析員可以交替使用建模和事實發現技術：首先，將事實發現結果轉變成模型然后，研究模型，以確定是否需要更多的事實發現系統分析員通常都會使用功能分解圖和統一建模語言來幫助理解系統需求功能分解圖功能分解圖(FDD)是一種自頂向下描述業務功能和過程的方法使用FDD，分析員可以顯示業務功能，并將這些功能分解成更低層的功能和過程。下圖是系統開發過程工作分解的示意圖RequirementsDefinitionSystemDevelopmentSystemTestingDocumentationSystemDesignEquipmentHistoryModuleSparePartsInventoryControlModuleDataDictionaryDevelopmentScreen&ReportDesignLogicDiagramsCodeDevelopmentModuleTestingWorkOrderControlModule數據流圖FDD之后，分析員可以創建數據流圖(DFD)來描述系統存儲、處理和轉換數據的過程在稍大規模的系統中，DFD都應該是分層結構的一個用PAD圖繪制的描述某算法的DFD開始結束aj

Until

x5i

Until

x6bx1kfx4ghdefkx2de123

While

x3c統一建模語言統一建模語言(UML)是一種可以使軟件系統設計可視化并能為其組織文檔的方法UML提供了各種圖形工具，如用例圖和順序圖。在需求建模過程中，分析員可以利用UML從用戶角度出發來描述信息系統如圖，是用UML表示某個事實存在的基本方法ShapeShapePolygonCircleSpline……PolygonCircleSpline……系統需求審核列表在需求建模過程中，分析員必須確定并清晰描述所有的系統需求作為信息系統包含的特征的系統需求，必須既能滿足系統業務需求，又能為用戶所接受作為衡量一個已完成系統總體可接受性的基準，系統需求由五大類組成：輸入輸出過程性能控制教材P.81對上述每一類，都給出了一些實例示范未來增長、成本和效益在項目系統的系統分析階段，一個優秀的分析員不僅關注系統的需求，同時還必須關注需求以外的許多方面。如，系統的可擴展性、整體擁有成本系統可擴展性決定了一個系統未來處理自身增長和需求的能力整體擁有成本包括系統交付用戶后的運作和支持費用這兩者可能會直接影響項目系統今后的市場競爭力和被接受程度換句話說，一個系統能否被市場所接受，并不僅僅由技術和功能、性能所決定，還取決于許多非技術因素可擴展性可擴展性是指系統處理未來增加的業務量和交易的能力可擴展性好的系統意味著可以使用更長的時間，以及能夠更好地適應用戶需求和市場的變化，因此更能夠為市場所歡迎，系統的初期投資也能有更多的回報系統擴展通常包括重要的系統功能和性能的增加和改進由于系統能力的擴展往往還意味著系統數據存儲和處理量的增大，以及系統網絡吞吐量的增加因此，為了對系統可擴展性進行評價，需要分析員盡早掌握系統將來可能的輸入、輸出和過程的業務量信息這就需要分析員對項目系統今后服務的領域有深入的理解和預見整體擁有成本如果系統開發費用可以被視作開發系統的直接費用，那么系統服務、支持、運行、維護、日常開支等費用就是相對于直接費用的間接費用作為系統從開發到運行、維護的全部費用，整體擁有成本(TCO)應該是直接成本和間接成本的總和在有多個方案選擇的時候，對TCO的估算就顯得特別重要由于間接費用通常都是不那么明顯的，許多起初看上去并不昂貴的系統，最后往往會成為費用最多的選擇因此，對間接費用的估算，往往是對分析員最大的考驗，分析員必須盡力確定間接費用因為，即使具體的效益很難量化，還是應該體現IT投資的戰略角色好在微軟已經開發了一種度量總成本和效益的方法，即快速經濟合理性論證(REJ)，可以幫助分析員優化IT投資的框架事實發現事實發現就是采用合適的事實發現技術收集項目系統需求相關的信息，為需求建模提供資料事實發現技術包括面談、文檔復查、觀察、調查、問卷調查、抽樣和研究等事實發現概述雖然目前已經有一些工具可以幫助分析員收集、整理和分析事實，但實際的事實發現過程還是需要分析員自己完成分析員通常可以提出類似以下的問題來確定所需要的信息：當前系統支持哪些業務功能？新系統必須支持什么戰略目標和業務需求？目標系統的收益和TCO怎么樣？系統將處理什么樣的交易？用戶和經理需要從系統了解什么信息？新舊系統之間需要交互嗎？業務過程再造工程可以減少哪些手續？存在哪些安全問題？哪些風險是可以接受的？什么樣的資金預算和時間表約束會影響系統開發？分析員為了順利收集到這些信息，必須首先制定策略，確定采用的事實發現技術，設計必要的方法、框架或表格，執行事實發現技術Who、what、where、when、how和why事實發現一般都會涉及到5個熟悉的問題：Who、what、where、when、how對于每個問題，分析員還都必須追問一個很重要的問題：why下表列出了基本的問題以及應該在什么時候提出這些問題，它反映的是，在需求建模過程中，隨著重點從當前系統轉移到目標系統所需要提出并解答的問題的示例當前系統目標系統誰做的？為什么這個人做？應該什么人做？做的什么？為什么做這個？應該做什么？在什么地方做的？為什么在那里做？應該在什么地方做？什么時候做的？為什么那個時候做？應該什么時候做？怎樣做的？為什么用這種方法做？應該怎樣做？面談作為最常用的事實發現技術，面談是一個有計劃的會面過程，使得分析員可以有目的地從面談對象那里獲取有意義的信息想要成功地進行面談，需要事先進行計劃，并執行面談計劃，最后將面談結果整理成文檔，這些都需要一定的技能在獲得前面了解的面談必要的各項信息后，就可以按照以下七個步驟進行面談：確定面談對象確立面談目標準備面談內容和確定面談方法準備面談進行面談將面談結果整理成文檔對面談進行評價面談過程需要注意的問題分析員在選擇面談候選人時，必須考慮組織的非正式結構——因為這些人可能更有影響力或在目標業務領域更有地位、學識更高面談目標的確立應與面談對象的角色相關，如高層對象多談宏觀層面的內容，這樣會有利于分析員對系統的整體理解和把握在作面談提問時，應避免使提問帶有誘導性，這可能使答案帶有傾向性，而使結果偏離需要，或誤導分析員的工作面談時間應該盡可能限制在1小時內，地點通常在被訪者辦公室或中立的第三地，這兩類面談地點各有好處，前者方便取得資料，而后者可以盡量避免打擾盡可能不要安排連續面談，因為分析員需要時間盡快記錄面談獲取的信息其它事實發現技術文檔復查：有助于對當前系統如何運作有更好的理解。需要注意的