[互聯(lián)網(wǎng)]ch5-系統(tǒng)分析-文庫吧資料
2025-04-19 22:19本頁面
【正文】 據(jù)存儲定義 ?外部實體定義 ?數(shù)據(jù)字典的數(shù)據(jù)項定義 ?數(shù)據(jù)字典的數(shù)據(jù)結(jié)構(gòu)定義 ?數(shù)據(jù)結(jié)構(gòu)描述數(shù)據(jù)項之間的關(guān)系，可由數(shù)據(jù)項組成，也可由其他數(shù)據(jù)結(jié)構(gòu)組成 ?數(shù)據(jù)字典的數(shù)據(jù)流定義 ?數(shù)據(jù)字典的處理邏輯定義 ?數(shù)據(jù)字典的數(shù)據(jù)存儲定義 ?數(shù)據(jù)字典的外部實體定義 3 處理邏輯的表達 ?結(jié)構(gòu)化英語 ?決策表 ?決策樹 4 邏輯模型的提出 ?對數(shù)據(jù)流圖進行優(yōu)化，必要時進行業(yè)務(wù)流程的重組，確定最終系統(tǒng)的邏輯模型 第四節(jié) 需求定義與文檔 1 需求定義與文檔的撰寫 ?對收集到的用戶需求進行分析、歸納與總結(jié)，然后根據(jù)一定的格式撰寫 《 用戶需求說明書 》 ，調(diào)查過程中的中間資料可作為附件。 ?數(shù)據(jù)字典是對數(shù)據(jù)流程圖中的各個數(shù)據(jù)元素做的進一步的說明。 ?將整個系統(tǒng)看成一個處理的 DFD稱為關(guān)聯(lián)圖 DFD圖例：銷售管理系統(tǒng)流程圖 DFD繪制技巧 ?DFD繪圖思路：從外向里畫 ?畫輸入與輸出 ?畫系統(tǒng)內(nèi)部 ?畫處理的內(nèi)部 ?DFD繪圖原則： ?適當(dāng)命名 ?畫數(shù)據(jù)流而不是控制流 ?從上到下或從左到右的流向 ?先考慮穩(wěn)定狀態(tài) ?避免陷入細節(jié) ?注意子圖與父圖的平衡 ?隨時可能重畫 DFD繪制步驟 例：工資發(fā)放系統(tǒng)的數(shù)據(jù)流圖 ?已對業(yè)務(wù)流程進行調(diào)查：月末發(fā)工資，2023日財務(wù)部根據(jù)上月工資清單和人力資源部送達的人員及工資變動表填寫本月工資清單，總務(wù)科 24日將扣款清單送交財務(wù)部，財務(wù)總計入扣款數(shù)并計算應(yīng)發(fā)工資，填入工資發(fā)放清單，為發(fā)放工資做好準備。較大型的軟件系統(tǒng) DFD分為多個層次，稱為父圖與子圖，可以表示數(shù)據(jù)流和處理的進一步細節(jié)。 ? 兩種思維方式： ?還沒有壞，就不需要修理 ?總有一種更好的解決方法 ?數(shù)據(jù)流分析的方法： ?抽象掉物理操作，留下信息 /數(shù)據(jù)流 ?從關(guān)聯(lián)圖開始，逐層分解細化 ?遵循數(shù)據(jù)流圖的繪制原則 ?數(shù)據(jù)流圖（ Data Flow Diagram）。提出創(chuàng)新的問題解決之道是系統(tǒng)分析員的素質(zhì)要求之一。系統(tǒng)分析員只有在需要理解商業(yè)業(yè)務(wù)流程時才去檢查現(xiàn)有系統(tǒng)。 ? 不適合于全新系統(tǒng)的開發(fā)，特別是一些 WEB項目，如電子商務(wù)方面的項目開發(fā)，這些項目沒有可參考的舊系統(tǒng)。這種方法可以保證系統(tǒng)分析能按步就班的完成，但缺點是 ? a) 系統(tǒng)分析時間較長，要花費更多時間與資金去分析、了解和記錄舊系統(tǒng)的運行，提煉出運行邏輯。每月 庫工 根據(jù) 庫存賬 和用料流水賬 制作 庫存報表 上報 管理部門 。 ?用戶間需求沖突則以級別大的用戶需求為準，同級則少數(shù)服從多數(shù)。記錄形式一般為表格 需求標題 調(diào)查方式 調(diào)查人 調(diào)查對象 時間 、 地點 需求信息記錄 是什么 ？ 不是什么 ？ 為什么 ？ ?需求沖突的解決 ?需求從獲取渠道收集到以后，可能產(chǎn)生不一致的地方。在調(diào)查過程中隨時記錄（或存儲）需求信息 。要特別留意的是不要漏掉典型的用戶。 ?JAD（聯(lián)合應(yīng)用開發(fā)會議）是加快調(diào)查的重要方法，即將相關(guān)人員全部召集在一起參加單一會議直接解決需求分析問題。 ?制定問題表最簡便的方法就是從 《 用戶需求說明書 》 的模板中提取需求問題。 ?問題表可以有多份，隨著調(diào)查的深入，問題表將不斷地被細化。通過多次迭代最終得到完整的系統(tǒng)需求。 ?需求工程的主要內(nèi)容： ?需求開發(fā)產(chǎn)生的主要文檔為 《 用戶需求說明書》 與 《 軟件需求規(guī)格說明書 》 。 ?需求跟蹤是指通過比較需求文檔與后續(xù)工作成果之間的對應(yīng)關(guān)系，建立與維護“需求跟蹤矩陣”，確保產(chǎn)品依據(jù)需求文檔進行開發(fā)。 ?需求管理過程：在客戶與開發(fā)方之間建立對需求的共同理解，維護需求與其它工作成果的一致性，并控制需求的變更。 ?需求定義的目的是根據(jù)需求調(diào)查和需求分析的結(jié)果，進一步定義準確無誤的產(chǎn)品需求，產(chǎn)生 《 產(chǎn)品需求規(guī)格說明書 》 。 ?需求分析的目的是對各種需求信息進行分析，消除錯誤，刻畫細節(jié)等。 ?需求開發(fā)過程：通過調(diào)查與分析，獲取用戶需求并定義產(chǎn)品需求。（ Brooks： 《 沒有銀彈 》 ） ?功能需求與技術(shù) (性能 )需求 需求獲取 VS軟件開發(fā)過程 客戶需求 產(chǎn)品需求 系統(tǒng)設(shè)計 系統(tǒng)實現(xiàn) 單元測試 集成測試 系統(tǒng)測試 驗收測試 什么是需求工程？ ?在軟件開發(fā)的生命周期中，與需求直接相關(guān)的活動。最困難的概念性工作是編寫出詳細的需求，包括所有面向用戶、面向機器和其它軟件系統(tǒng)的接口。 ?需求可能來自以下幾個方面：用戶（客戶）、接口、環(huán)境（硬件、組織文化、政策等）。所以需求變更控制是需求工程的重要活動。毫無疑問，這種需求變更將使項目付出額外的代價。 失之毫厘，謬之千里 —— 軟件錯誤的積累與放大效應(yīng) 原始要求 正確的規(guī)格說明 錯誤的規(guī)格說明 需求 分析 設(shè)計 正確的設(shè)計 錯誤的設(shè)計 對錯誤說明的設(shè)計 編碼 正確編碼 對錯誤說明的編碼 錯誤編碼 對錯誤設(shè)計的編碼 測試 正確功能 潛伏的
教學(xué)課件相關(guān)推薦
鄂ICP備17016276號-1