軟件工程-美備課筆記

第1---作為開發(fā)運行產品的載體，是計算機控制、信息通信、創(chuàng)建及控制其它程軟件工程：制造正確軟件所需要的技術，包括過程、方法和工具早期----->第二階段----->第三階段----->第四階 計算機發(fā)展----->軟件需求激增----->產生軟件----->軟件工程 >第產業(yè)的觀老化的軟件工與50、60年代的鋼鐵產業(yè)類似，70年代末發(fā)生：軟件，軟件開發(fā)周期太長，成本太大，難以。軟件的競軟件的開發(fā)由原來的自行開發(fā)（公司有自己的軟件人員委托第開發(fā)廠商完軟 ：競軟程序 能夠完成特定功能和性能的可以執(zhí)行的指文檔 描述程序的操作和使軟件特軟件不會“磨損”，軟件的比硬件的要復雜得多軟件構

過程語軟件應確定性：信息的處理順序及時間是可預定 確定的應用非確定性：信息的處理順序及時間是不可預定 非確定的應用工科學計算軟件PC軟件：地平線上的軟件：尋求解決途 軟件工第2軟件過程：建造高質量的軟件所需要完成的任務的框架---將系統化的、規(guī)范的、可度量的方法應用于軟件的開發(fā)、運行和的過程；1過程、方法和工包括軟件工程在內的任何工程方法，必須以有組織的質量保證為基礎軟件工程是一種層次化的技術：P/16圖軟件工程的過程層：將技術層結合在一起，使得軟件能夠被合理、及時地被開發(fā)成功。過程定義了：一組關鍵過程區(qū)域（）的框架；關鍵過程區(qū)域：構成軟件項目的管理控制的基礎，確立上下各區(qū)域之間的關系；規(guī)定了技術方法的采用、工程產品（模型、文檔、數據、報表等）的產生、里程碑的建立、質量的保證、對變化的管理等。軟件工程的方法層：提供開發(fā)軟件“如何做”的技術方法方法涵蓋了一系列的任務：需求分析、設計、編程、測試、。軟件工程的工具層：對軟件工程的工方法提供自動或半自動支持的工具。如果這些工具被集成后，使得一個工具所產生的信息可以被另一個工具使用，就建立了一個支持軟件開發(fā)的、稱為計算機輔助軟件工程的系統。計算機輔助軟件工程CASE集成了硬件、軟件、軟件工程數據倉庫（包含有關分析、設計、編程、測試的重要信息），從而形成了一個軟件工程的環(huán)境。與CAD/CAE（計算機輔助設計/工程）軟件工程的階段劃對于某個工程，必須考慮的問題階段：修改軟件，以糾正軟件錯誤、適應環(huán)境的改變、增強功能、或預防性。軟件工程的其它活動軟件過程的圖形表示：P/172-下面是軟件過程的描述，如果不考慮項目的規(guī)模和復雜性，下述的框架活動適用于所有軟件項目，保護性活動貫穿整個軟件過程，并且獨立于任何一個框架活動：任務集合 軟件工程產品、交付 軟件過

一個公共過程框

任務集合 軟件工程產品、交付任務集合 軟件工程產品、交付 任務集合 軟件工程產品、交付

過程成熟度：軟件工程（SEI）一個綜合模型，該模型定義了一個軟件組SEI第一級：初始級，軟件過程的特征是無序、甚至的；無過程定義；軟件的開發(fā)成第二級：可重復級，建立了最基本的項目管理、費用追蹤、進度和功能控制的軟件過程，有一定的過程規(guī)范，使得可以重視以前類似項目的成功。第三級：定義級，軟件過程文檔化、標準化，與整個組織的軟件過程相集成；并包含第二級的所有特征。第四級：管理級，收集軟件過產品質量的詳細度量數據，通過這些數據定量地理解和控制軟件過產品的生產；并包含第三級的所有特征。第五級：優(yōu)化級，通過來自于過程、或測試新的想法和技術而得到的定量的反饋，不斷對過程進行改進；并包含第四級的所有特征。須具有的軟件工程的功能，例如軟件項目計劃、需求管理等等。每個KPAs都235實現的方法：活動在實現過程中被的方18KPA都用上述特征進行描述。在成熟度第五級中包含18KPA。為解決軟件產業(yè)開發(fā)環(huán)境中的實際問題而綜合制定的策略。這些策略能夠覆蓋前面所述的軟件過程、方法和工具，及軟件工程的一般階段。是從用戶到開發(fā)者、到技術的續(xù)過程?？梢韵鄬澐殖?個階段（狀態(tài)描述、問題定義、技術開發(fā)、方案綜述），但是，不可能清楚地進行劃分，因為在各階段內部和各階段之間的活動往往是交叉進行的。即：對一個軟件項目，不管選擇什么過程模型，所有的階段（狀態(tài)描述、問題定義、技術開發(fā)、方案綜述）在某個細節(jié)的P/202-3。線性順序模軟件工程的“線性順序模型”也稱“傳統生命周期模型”、或“瀑布模型”；是一種最早的、應用最廣的、支持直線開發(fā)的過程模型。P/212-4缺點：1在開發(fā)過程中的變化可能引起運行版本只能到項目開發(fā)晚期得到，這時才發(fā)現的錯誤，其可能是災原型模軟件工程的“原型模型”是一種從用戶處開始收集需求、初步定義軟件的總體目標，然后進行快速設計、建造軟件“模型”，運行原型、征求用戶意見；進一步了解需求，再設計、修改“模型”，再運行原型、征求用戶意見…，的一個迭代過程。P/222-5原型模型可以幫助用戶和開發(fā)者清楚地理解需求，但不是最終交付的軟件產品。優(yōu)點：12缺點：1用戶往往把看到的原型作為軟件的最初“版本”，實際上是沒有考慮軟件的總體質量和可性的快速“拼湊”而成的“演示軟件”；2由于很早就得到用戶“認可”，往往就放松軟件開發(fā)的管理，開發(fā)者也常常進行“折衷”，把“演示”功能中的不合理部分處理成軟件的實際功能。應該：原型作為參考，實際的軟件開發(fā)必須在充分考慮質量和可性以后才進行RAD（快速應用開發(fā)）模模型適用于能夠被模塊化的信息系統的應用軟件的開發(fā)。P/242-6。RAD5處理建模：抽象并定義數據建模中的數據對象的和處理測試及反復：測試新的構件及所有接口（被復用的構件已經被測試過）特點：1一個開發(fā)組一般在短期（60～90）內就能創(chuàng)建出一個功能完善的軟件缺點：1RADRAD演化軟件過程模先理解好系統需求和產品部分，其它細節(jié)部分暫緩進行。P/262-采用隨時間的進展而交錯迭代的線性序列。每一個線性序列產生一個可發(fā)布的軟件“增量”。任何增量的處理流程均可以結合進原型范型，但與原型模型有所不同：強調每個增量均是一個可操作產品，最早的增量是最終產品的“可拆卸”的、給用戶提供服務和評估的版本。典型的螺旋模型：P/272- 用戶評估：為獲得用戶的反饋所需要的任務工程項目從開始沿螺旋移動螺旋的第一圈一般產生的是產品的規(guī)格說明，第二圈一般產生的是一個原適用于整個生命周期的螺旋模型：P/282-螺旋模型需要相當的風險評估的專門技術，其開發(fā)成功依賴于這種專門技術；因此，應用并不廣泛。利用預先包裝好的軟件構件（“類”）來構造應用程序。P/292-10并發(fā)過程模型（也稱“并發(fā)工程P/302-該模型可以用于任何類型的軟件開發(fā)，但多用于“客戶/形式化方法模第四代技術4GT數據庫查詢的非過程語言、報告、數據、屏幕交互和定義、代碼、4GT用一種特定的語言，或者用一種用戶可以理解的問題描述方法來描述要解決的問題的圖形表示，因此，4GT過程模型的關鍵是：說明軟件的能力。4GT第3穿于整個軟件的定義、開發(fā)和過程中。項目管理活動包括：測量、度量、估算、風險分析、進度安排、項目和控制。選擇、業(yè)績管理、培訓、、專業(yè)發(fā)展、組織和工作計劃、團隊精神、企業(yè)文化培方案，定義對人員、、技術和管理上的約束。人項目參與5項項目必須具有管理人的才能應該具有如下能力（JerryWeinbergMOI模型）：想法（Ideas）或創(chuàng)新（Innovation）：管理者的：必須并項目和人員。成就：和團結有成績的人員，并鼓勵在項目的約束下進行“積極”的技術。影響和隊伍建設：與人“溝通”，具有在高壓力的環(huán)境下保持良好的控制能力軟件項目nk1：nm人，各小組之間的協調工作由項目進行。3：nm組和項目共同控制。3：P/433-41234主程序員：負責規(guī)劃、協調和工程的全部技術活動。協調和通信問問隨著項目開發(fā)的不斷進展，需求可能不斷被改變，管理者必須不斷和考慮人軟件范問題分因此，劃分和分解問題（任務）是需求分析的活動過所有的軟件項目的開發(fā)均有如下的一般階段：定義、開發(fā)、在著手開發(fā)軟件前，必須選擇合適的軟件工程“過程模型”，然后基于公共過程框架活動集合，定義一個初步的計劃。合并問題和過制定項目計劃的開始，往往是對問題和過程進行歸并：P/473-2每個框架活動都有相應的軟件工程的任務，每個軟件工程任務又對應具體的軟件的功能。項目可以根據圖的各個活動單元估算資源要求和時間。過程分項第4章軟件過項目的度過程度量：從級洞悉軟件過程的功效。測度（measurement）：測量（measure）：對軟件產品的質量進試描述。是對一個產品過程的某個屬度量（metric）：對一個系統、構件、或過程所具有的某個給定屬性的“度”的一個定量的測量。在某種程度上與單個的測量相關（例如，在復審中每人、每小時所發(fā)現的錯誤的平均數）。指標（indicator）：是度量、或度量的組合。收集測量結果、產生度量，就可以過項目領域中的度應該：收集度量，以確定過產品的指標12潛在的風險3在問題造成前發(fā)現問題45過程度量和軟件過程改軟件過程度量對提高組織的總體過程成熟度有利。是的。改進過程的唯一合理的方法就是測量過程的特定屬性，基于這些屬性開發(fā)一組度量，然后使用這組度量來提供指導改進過程的指標。項目度軟件項目度量：是戰(zhàn)術的。軟件管理者和開發(fā)者利用項目度量、及從項目度量中得到的指標，改進項目工作流技術活動。軟件的間接測量：功能、質量、性能、可靠性、可性等等。面向規(guī)模的度度量是通過規(guī)范化質量和（或）生產率的測量而得到，這些測量是基于所開發(fā)的軟件的規(guī)模。缺點：在開發(fā)初期估算代碼行較，適用于過程式程序設計語言。代碼行度量依賴于程序設計語言，存在因素。面向功能的度根據事物信息處理程序的基本功能進行度量，在軟件的開發(fā)初期能估算出軟件的規(guī)模。功能點：是基于軟件信息領域的可計算的、直接測量，以及軟件復雜性評估而計算出來的。計算實例：P/594-缺點：涉及到的因素較多，有些數據不易，功能點EP值沒有直觀的物理擴展的功能點度功能點度量適合商業(yè)信息系統的應用軟件，不適合其它工嵌入式系統的軟件。代碼行的度量和功能點的度量之間的關系依賴于開發(fā)軟件所采用的程序設計語言和設計質量。不同的程序設計語言所產生的代碼行的“度量”，不能進行直接比較，尤如“蘋果和橘子”無法進行直接比較一樣。生產率度量，影響軟件生產率的幾個重要因素概述影響質量的因影響質量的一組因素產品轉換（軟件的移植測量質測量。例如，對于“正確性”的質量因素的測量，可以使用如下方法進量：缺陷排除效DRE：DREDRE1，當把一個項目作為一個整體考慮時：DRE=E/(E+D其中：EDiDREi=Ei/(Ei+Ei+1其中 =在軟件工程活動i中所發(fā)現的錯誤測量：軟件工程過程測量、軟件測量、生產率測量，使得管理者和開發(fā)者能夠改善軟件過程，輔助軟件項目的計劃、、控制，評估產品質量。度量的收集可以使組織“調整”軟件工程過程，以排除對軟件會引起重大影響的缺陷的致命原因。度量必須在估算、技術、項目控制、過程改善中加以評估和使用。軟件項目的管理過程從一組被稱為“項目計劃”的活動開始，其第一個活動是在項目開始進行之前，必須先對如下幾件事進行估算：開發(fā)周期、開發(fā)工作量、開發(fā)人員、開發(fā)成本、開發(fā)所需要的軟硬件資源、開發(fā)風險。項目計劃的目標：提供一個框架，使得項目責任者能夠在一個限定的時間框架內，對資源、成本、進度進行合理的估算（“最好情況估算”與“情況估算”）。軟件范圍的確定：是軟件項目計劃的第一個活動。軟件范圍的確定，可以幫助估算開發(fā)軟件的工作量。獲取定義軟件范圍所需的信一個范圍定義的例然后對獲取的信息進行評估。功能、性能、約束必須一起評估。因為，約束性能不同，相同的功能的實現可能存在數量級的差別。性進量在描述軟件范圍所需要的信息（這些信息已檔化了）.否則，計劃實施者必須進行資資源的特征說明：資源描述、可用性說明、需要該資源的時間、該資源被持續(xù)使用的時間。人力資職位：項目、高級軟件工程師、程序員、文檔管理員等。專業(yè)技能：網絡、數據庫、設備等?？蓮陀密浖Y可直接使用的構件：能夠從第廠商獲得，或已經在過去的項目中開發(fā)成功、數據等，軟件開發(fā)人員在這些構件所代表的應用領域中已具有豐富的經驗，只要稍加修改就可使用。因此，修測試數據等，軟件開發(fā)人員在這些構件所代表的應用領域中具有有限的經驗，要作實質上的修改才能使用。因環(huán)境資軟件項目估在軟件范圍（規(guī)模）估算的基礎上，可以進行工作量和資源的估算，在此基礎上，可以進行成本估算。 3直接方法：代碼量法（LOC）使用模糊邏輯基礎的近似推理技術。計劃者先說明應用軟件的類型，建立定性的規(guī)模估算，然后在最初的范圍內精化估算。此法需要計劃者的個人經驗和歷史數據庫的支持。計劃者估算每個標準構件出現的次數，然后統計確定每個標準構件交付時的大小，得到最終的規(guī)模值。用于必須作修改才能把已有軟件作為項目一部分使用的情況。計劃者估算必須完成的修改的數目和類型，得到修改的規(guī)模?；趩栴}的估算和例根據說明分解軟件成可以被獨立估算的“元素”，元素可以是代碼行、功能點、類、某個“修改”等；LOCFP基于過程的估算和例根據說明，把軟件的開發(fā)過程分解成相對獨立的任務，及其相關的“過程活動”；根據“平均勞動力價格”計算每個“過程活動”的工作量和成本；估算小應該至少分別利用上述2種方法進行估算工作量和成本，然后進行比較。如果估算典型的經驗估算模型：通過對以往的軟件項目所收集到的數據，進行回歸分析而導出的。估算模型的結經驗估算模型的總體結構：E=A+B*不同的模型，其計算結構有所不同O模1981年BarryBoehm“構造性成本模型（COnstrucriveCOstMOdel）”：在靜態(tài)、單變量模型的基礎上進行構造，把整個模型分為3個層次：基本、中間、詳細層次模型：估算相對獨立的軟部件（模塊）OO3軟件方程4000估算公式自行開發(fā)或的決在許多情況下，軟件比開發(fā)軟件的費用要低。因此，對自行開發(fā)軟件、還是1可以直接使用的軟件2“具有完全經驗”或“具有部分經驗”的軟件構件，然后進行修改和集成3建立軟件需求（功能、性能），3～4在最后，決定自行開發(fā)還是的決定因素2成本是否比自行開發(fā)低3外部支持成本（軟件合同）是否比內部支持成本低創(chuàng)建決策P/875-3外存在許多能夠幫助計劃者進行工作量和成本估算的自動估算工具，這些工具具有共同的特性，并且需要提供一定的數據：P/88。第66.1和主動的風險策對軟件開發(fā)的計劃產生的。技術風險：因軟件在設計、實現、接口、驗證、過程中可能存在潛在的問題，或采用了不可靠的技術等，對項目質量和交付時間造成的。試圖系統化地確定對項目計劃（估算、進度、資源分配）構成的所有因素，建立“風險條目檢查表”，羅列、歸類風險。產品規(guī)模風常見的與產品規(guī)模有關的風險商業(yè)影響風商業(yè)考慮常常會與技術實現發(fā)生。客戶相關的風不同的客戶對項目會產生不同的影響。“不好的”客戶往往會對項目構成和常見的與客戶有關的風險過程風過程風險：由于軟件過程定義得不清楚，軟件分析、設計、測試的方式方法不合理而產生的風險。P/95~96技術風開發(fā)環(huán)境風與人員數目及經驗相關的風人是項目成功的重要因一常見的與人員及人員素質、經驗有關的風險風險因素和驅動因風險驅動因子：對風險預算產生影響的類別?？煞譃榭珊雎缘摹⑤p微的、嚴重的、4P/986-風險預測（也稱：風險估算描述風險的建立風險P/996-2：分析羅列所有的風險，對每個風險進行分類、概率估算、確定影響類別；然后進行風險排序（按發(fā)生概率的高到低、影響的高到低進行排序），確定“中止線”（在中止線上的風險必須進行控制。在中止線下的風險，繼續(xù)進行評估，然后進行第二次排序…）。評估風險影3風險范圍：風險的嚴重性、及風險整體分布情況（即項目中有多少部分受到影風險評在整個軟件過程中，必須不斷關注風險、評估風險，尤其是導致成本超支、進度延遲、性能降低、支持的風險。對某個風險，如果一旦超過此值就會導致項目的被迫終止。如果多個風險的組合所產生的問題，引起一個或多個參考水平值被超值，則軟件過程被停止。P/1016-風險緩減、和管避免風險是最好的風險策略。為避免風險，必須預先對風險制定風險緩減計劃。例如，人員的流動會產生風險，可以制定計劃，使得人員流動延任務完成時才發(fā)生。風險隨著項目的開展，風險控制活動就開始進行。對會產生風險的因素進行控制，同時應控制緩減風險步驟的效力。風險的主要目的注意：風險緩減、和管理（RMMM）將增加額外的項目開銷安全性風險和軟件的安全性、潛在的。RMMM計RMMM計劃：RiskMitigation、Monitoring ManagementPlanRMMM計劃的大綱：P/103組成部分。是項目管理者和控制項目的主要活動。軟件延期交付的幾個根本原因關于“延遲”的評管理者必須：保護軟件開發(fā)隊伍免受不適當的進度安排的壓力，并且把這種壓力如果某些迫使提前完成軟件開發(fā)的壓力是必須給予“重視”的，一般的方法是與施加壓力方會談，采用分期交付軟件的方法，即：首先提交最關鍵的功能，然后逐次提交其它部分?；驹總€任務必須指定具體 一個例所有參與開發(fā)的人員之間存在“通信”問題，因此，產生通信成本和通信時間。所以，不能簡單地認為mmm一個經驗關在P/85頁的5.7.3節(jié)中描述的軟件方程式中：完成項目的時間與投入的人員的工為實現同樣的目標，開發(fā)時間與投入人員的工作量應該細加計算：P/111工作量分40－20－40后期的測試工作量應用項目：以用戶不察覺的方式對現有軟件進行糾錯、或適應性的。軟件開發(fā)是一個過程，不同的過程模型為開發(fā)軟件提供了不同的范型。過程模型是由一個任務集合組成的。任務集合使得項目組能夠定義、開發(fā)和最終軟件。小的軟件系統的任務集合相對簡單，而大的軟件系統的任務集合就相對復雜。一個任務集合包括一組軟件工程的任務、里程碑和交付產品，這些任務是必須完成才能得到軟件產品的。一個項目所選擇的任務集合必須為最終得到高質量的產品而提供規(guī)程要求，但同時又不能讓項目組承擔不必要的工作。有許多因素影響項目任務集合選擇，當綜合考慮這些因素時，就構成一個稱為嚴格4隨意的：使用所有過程框架活動，但只需要一個最小的任務集合；最小化保護性活動的任務，降低文檔要求。結構化的：過程框架活動、適用于項目類型的相關任務、為保證高質量所需要的保護性活動將得到應用。嚴格的：整個過程按照一種能夠保證高質量的嚴格規(guī)程要求進行，所有的保護性活動都將被采用，并且建立健壯的文檔。項目管理者為選擇合適的嚴格度，需要定義項目適應性準則，并計算“任務集合選擇因子（TSS）”的值。定義適應性準11每條準則都有一個等級分數，取值范圍：1～55計算任務集合選擇因子的TSS：TSS復審每個適應性準則的因子，因子的值在0.8～1.2之間，以表示適應逐條計算“乘積’：P/1137-TSS：“解釋TSS值并選擇任務集TSSTSS的取 嚴格TSS< 1.0<TSS< TSS> 上述存在取值范圍的“”，表示不可能定義精確的邊界。例如，如果一個項目的TSS值是2.8，表示該項目可以選擇結構化的、或嚴格的任務集合；在進行最后的選擇時，還應結合“經驗”、“”等考慮因素。例：P/114本節(jié)以“概念“型的開發(fā)項目為例，列出的需要完成的主要任務：P/115必須完成的任務（項目范圍）；是否有人去完成；進行風險評估；以某種方式證明采用的新技術；把采用的技術用原型方式實現（概念實現）；用戶評價。最后，如果這個概念可行，則進行產品開發(fā)。任務精化可以用大綱格式進行：P/117（概念類型項目的任務的精化格式）任務網絡：一個項目的任務流程的圖形表示。P/1187-3任務和子任務之間存在相互關系，由于多個開發(fā)人員的參與，任務和活動并行進行的可能性就增大。項目必須確定關鍵任務、各任務之間的依賴關系，協調并發(fā)任務，以確保任務的如期完成。2種方法：時間時間表：P/1207-進項目表：P/1217-項目表與時間表一起使用，可以使項目管理者項目的進展情況。文檔格式：P/1227-5SQA：是在軟件過程中的每一步都要進行的“保護性“活動。是將質量保證的管理對象和設計原則映射到適用的軟件工程管理和技術空間上，當映射成功時，其結果就是成3差異控制：是質量控制的。質軟件質量：在很大程度上是一種知識實體，因為軟件特征的定義比物理對象要質量控質量控制：為保證產品符合需求而在整個開發(fā)過程中進行的一系列的、復審、質量保質量的成3鑒定成本：為鑒定在各過程中產品的狀態(tài)而進行的活動成本。例如，設備成本、內部失敗成本：指產品交付前發(fā)現錯誤而的成本。例如，返工、修外部失敗成本：指產品交付后發(fā)現錯誤而的成本。例如，解決用軟件行業(yè)與其它行業(yè)一樣，必須進行“全面（TQM）”TQM4質量定義：明確的功能和性能要求、明確文檔化過的開發(fā)標準、以及專業(yè)開發(fā) 會），如果軟件只符合了明確的需求、卻沒有滿足隱含要求，則軟件的質背中期（70～80年代）：質量保證的定義是為了保證軟件質量而必須的“有計劃的、近期：質量保證的定義是在中，有多個機構負有保證軟件質量的責任（包SQA活SQA 為項目制定一套方法：在需求分析階段對軟件質量提出要求，并自頂向對軟件開發(fā)的各個階段進行軟件工程的正式技術評審保證軟件的開發(fā)過選用的軟件開發(fā)標準相一致SQASQA除上述活動外，獨立的SQA小組還要協調變化的控制和管理，并且?guī)椭占头治鲕浖毕輰Τ杀镜挠敖涍^數據收集、分析和統計，如果假定一個在軟件設計階段發(fā)現的錯誤，其改正1改正一個在測試開始前發(fā)現的錯誤的成本是6.5個貨幣單位；改正一個在測試時發(fā)現的錯誤的成本是15個貨幣單位；改正一個在軟件發(fā)布后發(fā)現的錯誤的成本是60～100缺陷的放大和消“缺陷放大模型”：用于說明在軟件工程過程中的概要設計、詳細設計、編碼、測試階段中的錯誤的產生及檢測。在軟件工程的各個階段都會產生新的錯誤，同時會存一個階段沒有被發(fā)現和改正的錯誤。在某些情況下，前面帶過來的錯誤會被放大：P/1328-2。8-38-4發(fā)和成本要大大低于無復審的開發(fā)和成本。復審使得開發(fā)人員必須付出時間和費用。但是，必須明白：現在付出，否則以后付出。正式技術復審（FTR）：FTR同時，由于FTR的進行，使得參與人員更加了解軟件系統，可以起到提高項目連FTR方式：“走查”、“”、“論查”等FTR復審會3～52復審報告和記錄保發(fā)現什么（或把復審問題列表作為附件）？：保證問題列表中的每個條目均得到改正?？梢灾付ㄓ蓮蛯徹熑握?、或小組進行復審指正式技術復審指南的最小集合：P/134～135SQA以數學方法證明程序的正確性。即，把計算機程序看作一個數學對象，對于每一種程序設計語言都能夠定義一套嚴格的語法和語義，并且對軟件需求說明也有一種類似的嚴格定義方法。這樣，一旦需求說明以一種嚴格的方法被表示出來，就能夠采用程序正確性的數學證明來說明程序是否嚴格符合它的說明。Pareto20%Pareto統計數據的收集：P/1378-2。t例表示：一個軟件在相同的環(huán)境中被執(zhí)行了10030092300，8改正一個失敗可能引入其它，而這些失敗的“實現”又可能會引入其它的可靠性和可用性的度平均修復時間（MTTR）：軟件可靠性的度量：軟件平均失敗間隔時間即：MTBF＝MTTF+MTTR可用性＝平均失敗時間/(平均失敗時間＋平均修復時間)*分析：對于那些“隱藏”時間很常才被發(fā)現的缺陷，可靠性度量就不適用。而可用性度量對平均修復時間較敏感。因此，除可靠性度量外，還應該進行可用性度量。軟件的安全和的分軟件的安全和分析主要解決如何標識出潛在的、導致整個系統失敗 ，以及評估潛在 系統可能形成的影響和引起整個系統癱瘓的可能性導致系統或。而軟件安全性則軟件失敗會導致系統發(fā)生的條件，把SQA計IEEESQA：P/1408-ISO9000ISO9000ISO對質量的保證系統的方ISO9000包括用現質量計劃、質量控制、質量保證和質量改進所需的組織結構、規(guī)程、過資源。但是，ISO9000并不描述應該如何實現這些質量要素。因此，真正的在于如何設計一個能夠滿足這個標準、并且適用于自己公司的產品、服務和文化的質量保證系統。ISO9001標ISO9001ISO900120如果某個軟件組織要通過ISO9001，就必須對這些問題的每一條需求都建立相關的軟件配置：由一組相關聯的軟件配置項（包括開發(fā)環(huán)境）4 目開始，到軟件退出運行后才終止的一組和控制活動?；€：已經通過正式復審和批準的某個規(guī)約或產品，這些規(guī)約或產品可以作為進一步開發(fā)的基礎，并且只能通過正式的變化來控制過程的改變。軟件配置組成一組基線的項目配置項要改變某個基線SCI，只有在遵循軟件配置管理（SCM）的情況下才可以SCM過SCM軟件配置中對象的標對象：由基本對象和其它對象組成的對象集合版本控SCI（源代碼、文檔、數據）的集合，每個版本可能由多個變化控變化控制過程：P/1559-控制和同步控制：P/1569-8SCI配置審軟件配置項的標識、版本控制、變化控制能夠幫助開發(fā)秩序。有關配置審計的問題配置狀態(tài)報配置狀態(tài)報告的內容：發(fā)生了什么、發(fā)生的事是誰做的、什么時候發(fā)生的、將會造成什么影響？SCM標SCM：ANSI/IEEEStd.No.828-1983、No.828-1984系統工程：從“整體視圖”開始分析產品，以建立所有的基本需求；然后關注點縮小到“領域視圖”，分析各個系統元素；把每個系統元素分配給一個或多個工程構件，然后這些元素由相關的工程方法處理。系統工程的任務以創(chuàng)建了系統規(guī)約而結束，系統規(guī)約是后續(xù)工程的工作的基礎文檔。系統工程構件（元素）：軟件、硬件、人員、數據庫、文檔、過程。系統工程把用戶的需求映射到使用這些構件的系統。信息工程、產品工程：都是系統工程方法的一種。本書的“系統工程”包括信息工程和產品工程。構成系統的一組元素可能表示了某個更大的系統的宏元素，而這個宏元素是一個基于計算機的系統，這個系統是某個更大的基于計算機的系統的一部分。例如“工廠自動化系統”中的數控機床，這個數控機床是基于計算機的系統的一個元素，而它本身又是基于計算機的系統。系統工程師：在系統的整體層次（宏元素）的語境內為特定的基于計算機的系統定義一系列元素。法導出：P/16410-2。系統建表示使得工程師更好地理解視圖的所有連接（包括輸出）信息工程：概產品工程：概系統工程與軟件工系統工程的進一步開發(fā)，就轉變?yōu)檐浖こ蘌/16610-3、P/16710-4信息策略計業(yè)務域分系統分說明客戶需可行性研經濟分技術分描述基于計算機的系統的功能和性能、以及將支配其開發(fā)的約束的文檔；是硬件工程、軟件工程、數據庫工程、人機工程的基礎。系統規(guī)約文檔的一般格式：P/184是發(fā)現、求精、建模、規(guī)約的過程。為開發(fā)和最后的驗收提供標準和依據，由系統分析員承擔。需求規(guī)約復審完成：需求規(guī) 軟件開發(fā)的“合約能、性能、軟件與其它系統元間的接口、軟件的約束等。過程的啟便利的應用規(guī)約技FAST（便利的應用規(guī)約技術一種面向團隊的需求收集方法，用戶和開發(fā)者雙方共同標識和商議，確定解決方案，編寫完整的規(guī)約草案。質量功能部QFD（質量功能部署是一種技術，把用戶的需求翻譯成軟件的技術需求QFD3記錄每個需求的和原因信息軟件的信息域：包括數據和事件（控制）3信息內容表示各單個數據和控制對象，這些數據和控制對象可以構成某個更大的由軟件變換的信息集合。數據和控制對象可以與其它數據和控制對象相關聯，就產生了信息之間的關系。建用圖形符號體系創(chuàng)建。把信息、處理、系統行為和其它特征描述為不同的、可識別的符號，模型的其它部分可以用文字描述。從軟件的名字開始，經過一系列的迭代處理、提供越來越多的功能細節(jié)，直到所有系統功能得到完全描述。描述軟件外部的行為模式、及改變行為模式（狀態(tài)）劃分解問題，可以進行功能劃分、信息劃分、行為劃分，使得復雜的問題分解成若干個小而簡單的問題，易于問題的求解?；疽晥D視軟件需求的基本視圖：描述軟件要完成的功能和處理的信息，不描述具體如何實現。軟件需求的實現視圖：描述處理功能和信息結構的實現元素，需求的實現視圖不處理見：2.3選擇原型方 表11-1原型方法和工見：2.3規(guī)約原 定義系統運作的環(huán)境，并指明：一組高度纏繞在一起的，如何對環(huán)境中其它表軟件需求規(guī)軟件需求規(guī)約的格式：P/20111-產生了需求規(guī)約，用戶和開發(fā)者必須共同對其進行復審。一旦復審通過，規(guī)約就成為軟件開發(fā)的“合約”，即作為軟件驗收和測試的依據。簡19601970定義一組在軟件完成后可以被確認（驗收）結構化分析模型：P/20712-數據字典：是分析模型的，包含軟件的所有數據對象的描述。狀態(tài)－變遷圖數據對象、屬性和關基數和形3 111 1，N。 M，N。1，表示關系必須出現一次。關系的基數和形態(tài)實例：P/21112-實體---關系E－R例：P/21212-612-712-812-數據流（人機界面）：

針對實時系統的擴實時系統的數據流圖擴展的新符號：P/12612-Ward和Mellor擴Hatley和Pirbhai擴P/221~222：12－1912－2012－21對外接口：使用戶通過本手冊了解系統的用途，并且能夠確定在什么情況下如何使用本系統；創(chuàng)建實體---關系E－R：P/223實例 創(chuàng)建數據流模實例 創(chuàng)建控制流模 控制規(guī)實例：SafeHome狀態(tài)變遷圖P/229加工規(guī)例：P/23012-3012-31數據字典：是所有與系統相關的數據元素的有組織的列表，并對數據進行精確的、嚴格的定義，使得用戶和系統分析員對于輸入、輸出、成分和中間計算數據有共同的理解。名稱：數據或外部實體的主名；別名：數據或外部實體的其它名稱；數據字典中的內容描述的符號：P/23212-訂票信息＝{航班號|起點＋終點}＋起始地點＋終止地點＋日期＋其中：班號|點＋終點程，例如，到：＋、＋、＋其它常用的三種結構化分析方法：DSSD、Jackson、SADT數據結構化系統開發(fā)DSSD：Warnier-OrrJackson系統開結構化分析和設計軟件設計是軟件工程的技術。設計自“需求分析”之后開始。軟件設計模型的創(chuàng)建基于軟件的分析模型：P/23913-14，4數據設計：把分析時創(chuàng)建的信息域模型變換成軟件所需要的數據結構。依據體系結構設計：定義程序的主要結構元間的關系。從分析模型的數據流圖的設計和軟件質3 對于編程、測試和人員而言，設計必須是可讀、可理解的 設計應該導出具有獨立功能特征的模塊，例如子例過程軟件設計的演3013.4設計對于分析建模應該能夠的設計應該具有一致性和集 應該復審設計，以減少概念性（語義性）“軟件工程師的智慧的體現，開始于對程序工作和程序正確性之間的區(qū)別的識抽使得能夠集中于某個一般性級別上的問題，而不考慮無關的底層細節(jié)。軟件工程過程中的每一個步驟都是軟件解決方案抽象級別上的求精。抽象過程是一個命名的指令序列（抽象描述過程），具有特定的和有限的功能。求模塊模塊是把軟件劃分成可以獨立命名和可以獨立的程序“構件”。是對復雜問軟件體系結功能、可靠性、安全性、適應性、和其它系統特。控制層P/24513-扇出大：說明模塊復雜，可以增加中間層（7）結構劃數據結數據結構：表示單個數據元間的邏輯關系，是數據的組織形式軟件過因此，過程的表示也是有層次關系的。P/24813-5。信息隱隱藏加強了模塊內部過程細節(jié)或模塊使用的任何局部數據結構的模塊化設計：降低了復雜性，方便軟件的理解、測試和模塊劃分沒有標準，但是有劃分原則 功能獨立內內聚 （功能模塊的內聚：模塊的“”度量低內聚：相對中度內聚“”多些中內聚：相對高內聚，一個模塊中有一個以上的“”。高內聚：一個模塊只有一個“”，就是高內聚的模塊耦數據耦合：通過數據傳遞而的模塊，稱之間存在數據耦合。印記耦合：通過傳遞部分數據結構而的模塊，被傳遞的部分數據結構在如果多個模塊中存在相同的處理，則把這相同的處理定義成新的模塊，提高模塊的內聚度。減少對全局變量