《軟件工程基礎(chǔ)》第2章-軟件開發(fā)過程.ppt

《《軟件工程基礎(chǔ)》第2章-軟件開發(fā)過程.ppt》由會(huì)員分享，可在線閱讀，更多相關(guān)《《軟件工程基礎(chǔ)》第2章-軟件開發(fā)過程.ppt（37頁珍藏版）》請(qǐng)?jiān)谘b配圖網(wǎng)上搜索。

1 38 第2章軟件開發(fā)過程 2 1軟件過程2 2常見的軟件過程模型2 3軟件過程的新發(fā)展 2 38 第2章軟件開發(fā)過程 2 1軟件過程2 1 1軟件過程的概念與理論基礎(chǔ)2 1 2軟件過程討論的主要內(nèi)容2 2常見的軟件過程模型2 3軟件過程的新發(fā)展 3 38 2 1 1軟件過程的概念與理論基礎(chǔ) 軟件過程的概念軟件過程模型的理論基礎(chǔ) 4 38 軟件過程的概念 軟件過程是為了獲得高質(zhì)量軟件所需要完成的一系列任務(wù)的框架 它規(guī)定了完成各項(xiàng)任務(wù)的工作步驟 在完成開發(fā)任務(wù)時(shí)必須進(jìn)行一系列開發(fā)活動(dòng) 并且使用適當(dāng)?shù)馁Y源 在過程結(jié)束時(shí)將把輸入轉(zhuǎn)化為輸出 因此 ISO9000把過程定義為 使用資源將輸入轉(zhuǎn)化為輸出的活動(dòng)所構(gòu)成的系統(tǒng) 過程定義了運(yùn)用方法的順序 應(yīng)該交付的文檔資料 為保證軟件質(zhì)量和協(xié)調(diào)變化所需要采取的管理措施 以及標(biāo)志軟件開發(fā)各個(gè)階段任務(wù)完成的里程碑 5 38 軟件過程模型及理論基礎(chǔ) 通常使用生命周期模型簡(jiǎn)潔地描述軟件過程 建立軟件開發(fā)過程模型的理論基礎(chǔ)是軟件生命周期理論和相關(guān)的軟件工程原則 因此 軟件過程模型又稱軟件生命周期模型 SoftwareLifeCycleModel 其核心思想主張把軟件過程劃分成若干個(gè)階段 每個(gè)階段所包含的活動(dòng)內(nèi)容和性質(zhì)具有 高內(nèi)聚 低藕合 的特征 這樣有助于簡(jiǎn)化問題 有助于驗(yàn)證階段性的工作成果 有助于對(duì)軟件工程的施工與管理 生命周期模型規(guī)定了把生命周期劃分成哪些階段及各個(gè)階段的執(zhí)行順序 因此 也稱為過程模型 軟件過程模型是對(duì)軟件開發(fā)活動(dòng)進(jìn)行有效地組織 協(xié)調(diào) 管理與控制的一種策略過程模型化是為了便于理解和操作 6 38 SoftwareLifeCycleModel 7 38 2 1 2軟件過程討論的主要內(nèi)容 軟件過程討論的主要內(nèi)容包括軟件過程模型 項(xiàng)目軟件過程定義 軟件過程裁剪 軟件過程改進(jìn)及軟件能力成熟度的評(píng)價(jià)等內(nèi)容 軟件過程模型給出了適合不同軟件項(xiàng)目的軟件過程活動(dòng)組織的參考框架 對(duì)不同的軟件組織來講 典型軟件過程模型僅僅是理論參考框架 為了不斷提高軟件能力 軟件組織 企業(yè)與團(tuán)隊(duì) 應(yīng)該不斷積累經(jīng)驗(yàn) 針對(duì)不同的軟件項(xiàng)目和軟件組織自身的特點(diǎn) 在軟件過程定義 軟件過程裁剪 軟件過程改進(jìn)等方面不斷努力和提高 軟件能力成熟度模型 CMM 是對(duì)一個(gè)軟件組織的軟件能力成熟度進(jìn)行評(píng)價(jià)的框架模型 它同時(shí)對(duì)軟件組織不斷提高軟件能力具有的一定的促進(jìn)作用 8 38 2 2常見的軟件過程模型 軟件過程包括軟件開發(fā)過程和軟件維護(hù)過程 實(shí)踐中 人們基于軟件工程方法論和軟件項(xiàng)目特點(diǎn)總結(jié)出了不同的軟件過程模型 好的過程模型吸收了成功的軟件工程經(jīng)驗(yàn)和有效的軟件工程原則 因此參考軟件過程模型框架組織軟件項(xiàng)目有利于提高工作效率 把握開發(fā)質(zhì)量 總體上可以提高軟件項(xiàng)目的成功率 為獲得高質(zhì)量的軟件產(chǎn)品 軟件過程必須科學(xué) 有效 沒有一個(gè)適用于所有軟件項(xiàng)目的任務(wù)集合 因此 科學(xué) 有效的軟件過程應(yīng)該定義一組適合于所承擔(dān)的項(xiàng)目特點(diǎn)的任務(wù)集合 通常 一個(gè)任務(wù)集合包括一組軟件工程任務(wù) 里程碑和應(yīng)該交付的產(chǎn)品 9 38 典型的過程模型 實(shí)際的軟件開發(fā)活動(dòng)中 應(yīng)該項(xiàng)目的特點(diǎn)來劃分階段 但是 下面講述典型的軟件過程模型時(shí)并不是針對(duì)某個(gè)特定項(xiàng)目講的 因此只能使用 通用的 階段劃分方法 由于瀑布模型與快速原型模型的主要區(qū)別是獲取用戶需求的方法不同 因此 下面在介紹生命周期模型時(shí)把 規(guī)格說明 作為一個(gè)階段獨(dú)立出來 此外 問題定義和可行性研究的主要任務(wù)都是概括地了解用戶的需求 為了簡(jiǎn)潔地描述軟件過程 把它們都?xì)w并到需求分析中去了 同樣 為了簡(jiǎn)潔起見 把總體設(shè)計(jì)和詳細(xì)設(shè)計(jì)合并在一起稱為 設(shè)計(jì) 10 38 1 4 1瀑布模型 在20世紀(jì)80年代之前 瀑布模型一直是惟一被廣泛采用的生命周期模型 現(xiàn)在它仍然是軟件工程中應(yīng)用得最廣泛的過程模型 傳統(tǒng)軟件工程方法學(xué)的軟件過程 基本上可以用瀑布模型來描述 圖1 2所示為傳統(tǒng)的瀑布模型 按照傳統(tǒng)的瀑布模型開發(fā)軟件 有下述的幾個(gè)特點(diǎn) 11 38 圖1 2傳統(tǒng)的瀑布模型 12 38 1 階段間具有順序性和依賴性這個(gè)特點(diǎn)有兩重含義 必須等前一階段的工作完成之后 才能開始后一階段的工作 前一階段的輸出文檔就是后一階段的輸入文檔 因此 只有前一階段的輸出文檔正確 后一階段的工作才能獲得正確的結(jié)果 2 推遲實(shí)現(xiàn)的觀點(diǎn)對(duì)于規(guī)模較大的軟件項(xiàng)目來說 往往編碼開始得越早最終完成開發(fā)工作所需要的時(shí)間反而越長(zhǎng) 這是因?yàn)?前面階段的工作沒做或做得不扎實(shí) 過早地考慮進(jìn)行程序?qū)崿F(xiàn) 往往導(dǎo)致大量返工 有時(shí)甚至發(fā)生無法彌補(bǔ)的問題 帶來災(zāi)難性后果 13 38 瀑布模型在編碼之前設(shè)置了系統(tǒng)分析與系統(tǒng)設(shè)計(jì)的各個(gè)階段 分析與設(shè)計(jì)階段的基本任務(wù)規(guī)定 在這兩個(gè)階段主要考慮目標(biāo)系統(tǒng)的邏輯模型 不涉及軟件的物理實(shí)現(xiàn) 清楚地區(qū)分邏輯設(shè)計(jì)與物理設(shè)計(jì) 盡可能推遲程序的物理實(shí)現(xiàn) 是按照瀑布模型開發(fā)軟件的一條重要的指導(dǎo)思想 3 質(zhì)量保證的觀點(diǎn)軟件工程的基本目標(biāo)是優(yōu)質(zhì) 高產(chǎn) 為了保證所開發(fā)的軟件的質(zhì)量 在瀑布模型的每個(gè)階段都應(yīng)堅(jiān)持兩個(gè)重要做法 14 38 1 每個(gè)階段都必須完成規(guī)定的文檔 沒有交出合格的文檔就是沒有完成該階段的任務(wù) 完整 準(zhǔn)確的合格文檔不僅是軟件開發(fā)時(shí)期各類人員之間相互通信的媒介 也是運(yùn)行時(shí)期對(duì)軟件進(jìn)行維護(hù)的重要依據(jù) 2 每個(gè)階段結(jié)束前都要對(duì)所完成的文檔進(jìn)行評(píng)審 以便盡早發(fā)現(xiàn)問題 改正錯(cuò)誤 事實(shí)上 越是早期階段犯下的錯(cuò)誤 暴露出來的時(shí)間就越晚 排除故障改正錯(cuò)誤所需付出的代價(jià)也越高 因此 及時(shí)審查 是保證軟件質(zhì)量 降低軟件成本的重要措施 15 38 傳統(tǒng)的瀑布模型過于理想化了 事實(shí)上 人在工作過程中不可能不犯錯(cuò)誤 在設(shè)計(jì)階段可能發(fā)現(xiàn)規(guī)格說明文檔中的錯(cuò)誤 而設(shè)計(jì)上的缺陷或錯(cuò)誤可能在實(shí)現(xiàn)過程中顯現(xiàn)出來 在綜合測(cè)試階段將發(fā)現(xiàn)需求分析 設(shè)計(jì)或編碼階段的許多錯(cuò)誤 因此 實(shí)際的瀑布模型是帶 反饋環(huán) 的 如圖1 3所示 圖中實(shí)線箭頭表示開發(fā)過程 虛線箭頭表示維護(hù)過程 當(dāng)在后面階段發(fā)現(xiàn)前面階段的錯(cuò)誤時(shí) 需要沿圖中左側(cè)的反饋線返回前面的階段 修正前面階段的產(chǎn)品之后再回來繼續(xù)完成后面階段的任務(wù) 16 38 圖1 3實(shí)際的瀑布模型 17 38 瀑布模型有許多優(yōu)點(diǎn) 可強(qiáng)迫開發(fā)人員采用規(guī)范的方法 例如 結(jié)構(gòu)化技術(shù) 嚴(yán)格地規(guī)定了每個(gè)階段必須提交的文檔 要求每個(gè)階段交出的所有產(chǎn)品都必須經(jīng)過質(zhì)量保證小組的仔細(xì)驗(yàn)證 各個(gè)階段產(chǎn)生的文檔是維護(hù)軟件產(chǎn)品時(shí)必不可少的 沒有文檔的軟件幾乎是不可能維護(hù)的 遵守瀑布模型的文檔約束 將使軟件維護(hù)變得比較容易一些 由于絕大部分軟件預(yù)算都花費(fèi)在軟件維護(hù)上 因此 使軟件變得比較容易維護(hù)就能顯著降低軟件預(yù)算 可以說 瀑布模型的成功在很大程度上是由于它基本上是一種文檔驅(qū)動(dòng)的模型 18 38 但是 瀑布模型是由文檔驅(qū)動(dòng)的 這個(gè)事實(shí)也是它的一個(gè)主要缺點(diǎn) 在可運(yùn)行的軟件產(chǎn)品交付給用戶之前 用戶只能通過文檔來了解產(chǎn)品是什么樣的 但是 僅僅通過寫在紙上的靜態(tài)的規(guī)格說明 很難全面正確地認(rèn)識(shí)動(dòng)態(tài)的軟件產(chǎn)品 而且事實(shí)證明 一旦一個(gè)用戶開始使用一個(gè)軟件 在他的頭腦中關(guān)于該軟件應(yīng)該做什么的想法就會(huì)或多或少地發(fā)生變化 這就使得最初提出的需求變得不完全適用了 事實(shí)上 要求用戶不經(jīng)過實(shí)踐就提出完整準(zhǔn)確的需求 在許多情況下都是不切實(shí)際的 總之 由于瀑布模型幾乎完全依賴于書面的規(guī)格說明 很可能導(dǎo)致最終開發(fā)出的軟件產(chǎn)品不能真正滿足用戶的需要 19 38 1 4 2快速原型模型 所謂快速原型是快速建立起來的可以在計(jì)算機(jī)上運(yùn)行的程序 它所能完成的功能往往是最終產(chǎn)品能完成的功能的一個(gè)子集 如圖1 4所示 圖中實(shí)線箭頭表示開發(fā)過程 虛線箭頭表示維護(hù)過程 快速原型模型的第一步是快速建立一個(gè)能反映用戶主要需求的原型系統(tǒng) 讓用戶在計(jì)算機(jī)上試用它 通過實(shí)踐來了解目標(biāo)系統(tǒng)的概貌 20 38 通常 用戶試用原型系統(tǒng)之后會(huì)提出許多修改意見 開發(fā)人員按照用戶的意見快速地修改原型系統(tǒng) 然后再次請(qǐng)用戶試用 一旦用戶認(rèn)為這個(gè)原型系統(tǒng)確實(shí)能做他們所需要的工作 開發(fā)人員便可據(jù)此書寫規(guī)格說明文檔 根據(jù)這份文檔開發(fā)出的軟件可以滿足用戶的真實(shí)需求 從圖1 4可以看出 快速原型模型是不帶反饋環(huán)的 這正是這種過程模型的主要優(yōu)點(diǎn) 軟件產(chǎn)品的開發(fā)基本上是線性順序進(jìn)行的 能做到基本上線性順序開發(fā)的主要原因如下 21 38 圖1 4快速原型模型 22 38 1 原型系統(tǒng)已經(jīng)通過與用戶交互而得到驗(yàn)證 據(jù)此產(chǎn)生的規(guī)格說明文檔正確地描述了用戶需求 因此 在開發(fā)過程的后續(xù)階段不會(huì)因?yàn)榘l(fā)現(xiàn)了規(guī)格說明文檔的錯(cuò)誤而進(jìn)行較大的返工 2 開發(fā)人員通過建立原型系統(tǒng)已經(jīng)學(xué)到了許多東西 至少知道了 系統(tǒng)不應(yīng)該做什么 以及怎樣不去做不該做的事情 因此 在設(shè)計(jì)和編碼階段發(fā)生錯(cuò)誤的可能性也比較小 這自然減少了在后續(xù)階段需要改正前面階段所犯錯(cuò)誤的可能性 軟件產(chǎn)品一旦交付給用戶使用之后 維護(hù)便開始了 根據(jù)所需完成的維護(hù)工作種類的不同 可能需要返回到需求分析 規(guī)格說明 設(shè)計(jì)或編碼等不同階段 如圖1 4中虛線箭頭所示 23 38 快速原型的本質(zhì)是 快速 開發(fā)人員應(yīng)該盡可能快地建造出原型系統(tǒng) 以加速軟件開發(fā)過程 節(jié)約軟件開發(fā)成本 原型的用途是獲知用戶的真正需求 一旦需求確定了 原型將被拋棄 因此 原型系統(tǒng)的內(nèi)部結(jié)構(gòu)并不重要 重要的是 必須迅速地構(gòu)建原型然后根據(jù)用戶意見迅速地修改原型 UNIXShell和超文本都是廣泛使用的快速原型語言 最近的趨勢(shì)是 廣泛地使用第四代語言 4GL 構(gòu)建快速原型 當(dāng)快速原型的某個(gè)部分是利用軟件工具由計(jì)算機(jī)自動(dòng)生成的時(shí)候 可以把這部分用到最終的軟件產(chǎn)品中 24 38 1 4 3增量模型 增量模型也稱為漸增模型 如圖1 5所示 使用增量模型開發(fā)軟件時(shí) 把軟件產(chǎn)品作為一系列的增量構(gòu)件來設(shè)計(jì) 編碼 集成和測(cè)試 每個(gè)構(gòu)件由多個(gè)相互作用的模塊構(gòu)成 并且能夠完成特定的功能 使用增量模型時(shí) 第一個(gè)增量構(gòu)件往往實(shí)現(xiàn)軟件的基本需求 提供最核心的功能 第二個(gè)增量構(gòu)件提供更完善的編輯和文檔生成功能 第三個(gè)增量構(gòu)件實(shí)現(xiàn)拼寫和語法檢查功能 第四個(gè)增量構(gòu)件完成高級(jí)的頁面排版功能 25 38 把軟件產(chǎn)品分解成增量構(gòu)件時(shí) 應(yīng)該使構(gòu)件的規(guī)模適中 規(guī)模過大或過小都不好 最佳分解方法因軟件產(chǎn)品特點(diǎn)和開發(fā)人員的習(xí)慣而異 分解時(shí)惟一必須遵守的約束條件是 當(dāng)把新構(gòu)件集成到現(xiàn)有軟件中時(shí) 所形成的產(chǎn)品必須是可測(cè)試的 采用瀑布模型或快速原型模型開發(fā)軟件時(shí) 目標(biāo)都是一次就把一個(gè)滿足所有需求的產(chǎn)品提交給用戶 增量模型則與之相反 它分批地逐步向用戶提交產(chǎn)品 整個(gè)軟件產(chǎn)品被分解成許多個(gè)增量構(gòu)件 開發(fā)人員一個(gè)構(gòu)件接一個(gè)構(gòu)件地向用戶提交產(chǎn)品 從第一個(gè)構(gòu)件交付之日起 用戶就能做一些有用的工作 顯然 能在較短時(shí)間內(nèi)向用戶提交可完成部分工作的產(chǎn)品 是增量模型的一個(gè)優(yōu)點(diǎn) 26 38 圖1 5增量模型 27 38 增量模型的另一個(gè)優(yōu)點(diǎn)是 逐步增加產(chǎn)品功能可以使用戶有較充裕的時(shí)間學(xué)習(xí)和適應(yīng)新產(chǎn)品 從而減少一個(gè)全新的軟件可能給客戶組織帶來的沖擊 使用增量模型的困難是 在把每個(gè)新的增量構(gòu)件集成到現(xiàn)有軟件體系結(jié)構(gòu)中時(shí) 必須不破壞原來已經(jīng)開發(fā)出的產(chǎn)品 此外 必須把軟件的體系結(jié)構(gòu)設(shè)計(jì)得便于按這種方式進(jìn)行擴(kuò)充 向現(xiàn)有產(chǎn)品中加入新構(gòu)件的過程必須簡(jiǎn)單 方便 也就是說 軟件體系結(jié)構(gòu)必須是開放的 但是 從長(zhǎng)遠(yuǎn)觀點(diǎn)看 具有開放結(jié)構(gòu)的軟件擁有真正的優(yōu)勢(shì) 這樣的軟件的可維護(hù)性明顯好于封閉結(jié)構(gòu)的軟件 28 38 因此 盡管采用增量模型比采用瀑布模型和快速原型模型需要更精心的設(shè)計(jì) 但在設(shè)計(jì)階段多付出的勞動(dòng)將在維護(hù)階段獲得回報(bào) 如果一個(gè)設(shè)計(jì)非常靈活而且足夠開放 足以支持增量模型 那么 這樣的設(shè)計(jì)將允許在不破壞產(chǎn)品的情況下進(jìn)行維護(hù) 事實(shí)上 使用增量模型時(shí)開發(fā)軟件和擴(kuò)充軟件功能 完善性維護(hù) 并沒有本質(zhì)區(qū)別 都是向現(xiàn)有產(chǎn)品中加入新構(gòu)件的過程 29 38 從某種意義上說 增量模型本身是自相矛盾的 它一方面要求開發(fā)人員把軟件看作一個(gè)整體 另一方面又要求開發(fā)人員把軟件看作構(gòu)件序列 每個(gè)構(gòu)件本質(zhì)上都獨(dú)立于另一個(gè)構(gòu)件 除非開發(fā)人員有足夠的技術(shù)能力協(xié)調(diào)好這一明顯的矛盾 否則用增量模型開發(fā)出的產(chǎn)品可能并不令人滿意 30 38 圖1 5所示的增量模型表明 必須在開始實(shí)現(xiàn)各個(gè)構(gòu)件之前就全部完成需求分析 規(guī)格說明和概要設(shè)計(jì)的工作 由于在開始構(gòu)建第一個(gè)構(gòu)件之前已經(jīng)有了總體設(shè)計(jì) 因此風(fēng)險(xiǎn)較小 圖1 6描繪了一種風(fēng)險(xiǎn)更大的增量模型 一旦確定了用戶需求之后 就著手?jǐn)M定第一個(gè)構(gòu)件的規(guī)格說明文檔 完成后規(guī)格說明組將轉(zhuǎn)向第二個(gè)構(gòu)件的規(guī)格說明 與此同時(shí)設(shè)計(jì)組開始設(shè)計(jì)第一個(gè)構(gòu)件 用這種方式開發(fā)軟件 不同的構(gòu)件將并行地構(gòu)建 因此有可能加快工程進(jìn)度 但是 使用這種方法將冒構(gòu)件無法集成到一起的風(fēng)險(xiǎn) 除非密切地監(jiān)控整個(gè)開發(fā)過程 否則整個(gè)工程可能毀于一旦 31 38 圖1 6風(fēng)險(xiǎn)更大的增量模型 32 38 1 4 4螺旋模型 軟件風(fēng)險(xiǎn)是任何軟件開發(fā)項(xiàng)目中都普遍存在的實(shí)際問題 項(xiàng)目越大 軟件越復(fù)雜 承擔(dān)該項(xiàng)目所冒的風(fēng)險(xiǎn)也越大 軟件風(fēng)險(xiǎn)可能在不同程度上損害軟件開發(fā)過程和軟件產(chǎn)品質(zhì)量 因此 在軟件開發(fā)過程中必須及時(shí)識(shí)別和分析風(fēng)險(xiǎn) 并且采取適當(dāng)措施以消除或減少風(fēng)險(xiǎn)的危害 33 38 構(gòu)建原型是一種能使某些類型的風(fēng)險(xiǎn)降至最低的方法 正如1 4 2節(jié)所述 為了降低交付給用戶的產(chǎn)品不能滿足用戶需要的風(fēng)險(xiǎn) 一種行之有效的方法是在需求分析階段快速地構(gòu)建一個(gè)原型 在后續(xù)的階段中也可以通過構(gòu)造適當(dāng)?shù)脑蛠斫档湍承┘夹g(shù)風(fēng)險(xiǎn) 當(dāng)然 原型并不能 包治百病 對(duì)于某些類型的風(fēng)險(xiǎn) 原型方法是無能為力的 螺旋模型的基本思想是 使用原型及其他方法來盡量降低風(fēng)險(xiǎn) 理解這種模型的一個(gè)簡(jiǎn)便方法 是把它看作在每個(gè)階段之前都增加了風(fēng)險(xiǎn)分析過程的快速原型模型 如圖1 7所示 完整的螺旋模型如圖1 8所示 34 38 圖1 7簡(jiǎn)化的螺旋模型 35 38 圖1 8完整的螺旋模型 36 38 螺旋模型有許多優(yōu)點(diǎn) 對(duì)可選方案和約束條件的強(qiáng)調(diào)有利于已有軟件的重用 也有助于把軟件質(zhì)量作為軟件開發(fā)的一個(gè)重要目標(biāo) 減少了過多測(cè)試 浪費(fèi)資金 或測(cè)試不足 產(chǎn)品故障多 所帶來的風(fēng)險(xiǎn) 更重要的是 在螺旋模型中維護(hù)只是模型的另一個(gè)周期 在維護(hù)和開發(fā)之間并沒有本質(zhì)區(qū)別 螺旋模型主要適用于內(nèi)部開發(fā)的大規(guī)模軟件項(xiàng)目 如果進(jìn)行風(fēng)險(xiǎn)分析的費(fèi)用接近整個(gè)項(xiàng)目的經(jīng)費(fèi)預(yù)算 則風(fēng)險(xiǎn)分析是不可行的 事實(shí)上 項(xiàng)目越大 風(fēng)險(xiǎn)也越大 因此 進(jìn)行風(fēng)險(xiǎn)分析的必要性也越大 此外 只有內(nèi)部開發(fā)的項(xiàng)目 才能在風(fēng)險(xiǎn)過大時(shí)方便地中止項(xiàng)目 37 38 螺旋模型的主要優(yōu)勢(shì)在于 它是風(fēng)險(xiǎn)驅(qū)動(dòng)的 但是 這也可能是它的一個(gè)弱點(diǎn) 除非軟件開發(fā)人員具有豐富的風(fēng)險(xiǎn)評(píng)估經(jīng)驗(yàn)和這方面的專門知識(shí) 否則將出現(xiàn)真正的風(fēng)險(xiǎn) 當(dāng)項(xiàng)目實(shí)際上正在走向?yàn)?zāi)難時(shí) 開發(fā)人員可能還認(rèn)為一切正常