1、 軟體：是與乙個系統，特別是乙個計算機系統有關的程式、過程和有關文件的的集合。
2、 軟體工程的活動是指生產乙個最終滿足需求達到工程目標的軟體產品所需要的步驟。主要包括：問題定義、可行性研究、需求分析、設計實現、確認、支援。
3、 描述系統邏輯模型的方法：資料流圖、資料字典、簡要的演算法。
4、 四類維護活動：改正性維護、適應性維護、完善性維護、預防性維護。
5、 目標的明確性：專案的目標有成果性目標和約束性目標。
6、 專案以「慢-快-慢」的進展方式朝向目標是普遍的現象。
7、 專案管理：在專案活動中運用一系列的知識、技能、工具和技術以滿足或超過相關利益者對專案的需求。
8、9、 專案管理的要素（五個）：技術、方法、團隊建設、資訊、溝通。
10、 有時候，作為解決問題的手段而受到青睞的新技術，不是某些問題的解決方案，而是導致問題的原因。
11、 97年版的ieee軟體工程標準詞彙表把需求定義為：a.使用者解決問題或達到目標所需的條件或能力；b.
系統或系統部件要滿足合同、標準、規範或其它正式文件所需具有的條件或能力；c.一種反映上面第一點或第二點所描述的條件或能力的文件說明。
12、 通過定義以下五項內容來確一組完整的軟體需求：a.系統的輸入；b.系統的輸出；c.系統的功能；d.系統環境的屬性。
13、 系統構建過程需要跟蹤第項需求與相應的設計和軟體**。
14、 軟體需求的抽象層次。原始問題空間：原始問題的描述-----使用者需求；解決方案空間：系統需求----軟體設計描述。
15、 系統的功能需求應該具有全面性和一致性。
16、 軟體需求規格srs：精確地闡述乙個軟體系統必須提供的功能和效能以及它所需要考慮的限制條件，是對外部行為和系統環境介面的簡潔完整的描述性文件
17、 需求工程是乙個包括建立和維護需求文件所必需的所有活動的過程，是將使用者非形式化的軟體需求轉變為形式化的規格說明的過程。
18、 需求分析活動不僅限於軟體開發的最初階段，而是貫穿於軟體專案開的整個生命週期。
19、 需求工程：需求開發、需求管理。
需求開發：需求獲取、需求分析、規格說明、需求驗證；
需求管理：變更管理、版本控制、需求跟蹤、需求狀態。
20、 軟體專案的需求總是在變化著，原因如下：a.在專案的早期所有的問題不可能被完全定義，軟體需求是不完全的，這就注定了需求需要變更以便達到完善的程度；b.
隨著專案的進行軟體開了人員對問題的理解會發生變化，這些變化也要反饋到需求中去。
21、 變更管理過程分為：變更描述、變更分析和變更實現三個階段。
22、 需求跟蹤有正向跟蹤與逆向跟蹤，需求跟蹤的雙向模式可以能過需求鏈來表示，實現需求跟蹤的一種通用方法是採用跟蹤矩陣。
23、 軟體專案估算包括工作量估算和成本估算。初步的估算用於確定軟體專案的可行性，詳細的估算用於指導軟體計畫的制定。
24、 對任何一種估算方法來說，估算的時機和精度都一對矛盾體。
25、 軟體規模的估計從軟體分解開始，分層結構對對應著工作分解結構（wbs），常用的軟體規模度量標準：**行和功能點。
26、 成本估算模型：靜態單變數模型、靜態多變數模型（中級co***o模型、高階co***o模型）、動態多變數模型。putnam模型是乙個基於norden-rayleigh曲線的動態多變數模型co***o模型是乙個採用自底向上的方法進行估算的代表。
27、 進行估算值的迭代有兩個原因：a.樂觀和悲觀現象：由於角色差異導致對類似軟體部分不同的估算值；b.帳篷中的高桿現象。
28、 分階段交付的必要性。分階段的方法：定義乙個階段的主題。
29、 pert圖：設g=（v，e，g）是乙個網路圖，若g中只有乙個了點和乙個收點，其中權函式表示為時間函式，則網路圖g常稱為pert圖（計畫評審圖）。定理：
在pert圖的關鍵路徑中，各任務的緩衝時間均為0。
30、 對於任何乙個變更有乙個基本原則：除非知道它不重要，否則都是都要的。
31、 軟體配置項sci是為了配置管理的目的而作為乙個單位來看待的軟體要素的集合。
32、 基線以乙個或多個軟體配置項的交付為標準，是開發過程的里程碑。
33、 配置管理cm是在系統生命週期中對系統中的配置項進行標識和定義的過程。
34、 計畫cm---cm方案----配置控制----狀態審計 ; 軟體配置管理過程，軟體配置管理是乙個二級cmm的乙個kpa。
35、 scm檔案體系：方針/過程定義/規程或模板。
36、 為了支援並行開發，軟體配置管理必須具有支援分支檔案比較和合併的功能。版本控制提供了這種機制。
37、 基線管理的兩個功能：對基線進行適當控制、為程式設計師提供靈活的服務。
38、 確定變更是否正確有正式技術審核和軟體配置審核兩種措施：
a.正式技術審核關注已變更的配置物件的技術正確性，審核者評估軟體配置項的一致性，遺漏及潛在的***。軟體配置審核關注的是正式技術審核中未考慮的因素；
b.軟體配置審核關注的因素有：
1）變更指令中指定的變更是否完成，每個附加變更是否已經納入到系統中；
2）是否進行了正式技術審核；
3）是否遵循了軟體工程標準；
4）變更的軟體配置項是否作了特殊記號而得到強調，是否註明變更日期和變更執行人員，軟體配置項屬性是否反映了變更；
5）是否遵循與變更有關的注釋、記錄及報告的軟體配置管理規程；
6）相關的軟體配置項是否都得到了同步更新。
39、 可復用軟體是指為了復用目的而設計的軟體。
40、 sez將風險定義為損失的可能性。
41、 軟體風險分為：軟體專案風險、軟體過程風險、軟體產品風險。
42、 風險管理過程：風險識別、風險分析、風險計畫、風險跟蹤和風險應對。
43、 風險管理策略：主動的風險管理、綜合的風險管理、系統的、自覺的。
44、 風險管理機制是將風險管理活動的輸入轉變為風險管理成果過程中所用的技巧與工具，包括風險核對清單、風險管理**和風險資料庫模式。
45、 採用sei推薦的軟體風險分類系統或專案工作細分結構wbs作為核對清單。
46、 風險度量準則包括可能性，後果和行動時間框架。
47、 **風險影響：風險影響（pe）=可能性（p）*後果（c）。
48、 過分自信的進度加上固定的成本預算，必然導致進度與成本方面的風險。
49、 風險應用策略：避免、轉移、緩解、接受、研究、儲備以及退避。轉移包括保險投保、發行債券、擔保等，可以通過合同的方式將風險轉移，如果專案的設計可靠，乙個固定**的合同行為將風險轉移。
50、 風險資訊通過觸發器發出，觸發器有三種控制功能：啟用、解除、掛起。以下四種觸發器用於提供風險通知：定期事件觸發器、時間觸發器、相對變化觸發器、閾值觸發器。
51、 風險閾值是啟動風險行動計畫的值。
52、 軟體質量的評價：功能性、可靠性、可用性、效率、可維護性、可移植性。
53、 軟體評審是專案早期軟體質量保證的手段，軟體測試是專案後期的主要手段。
54、 軟體測試是指為了尋找軟體缺陷而執行程式的過程，目的是盡可能發現軟體的缺陷，而不是證明軟體正確。
55、 軟體資源的主要復用方式：源**復用、目標**復用、設計結果復用、分析結果復用、類模組復用。類模組的復用又分為：例項復用、繼承復用、多型復用。
56、 專案團隊的組織可採用垂直方案、水平方案、混合方案。
57、 psp：個體軟體過程；tsp：團隊軟體過程。
58、 軟體缺陷的跟蹤最好在對軟體需求的基線已經確定，工作產品已經置於變更控制狀態時即開始。
軟體專案管理與CMM複習
一 填空。1 專案管理的4個管理要素是 範圍 時間 費用 質量。2 質量管理的迴圈是pdca。pdca迴圈過程為 計畫plan 執行do 檢查check 行動action。3 專案的特徵 臨時性 獨特性 漸進明細。4 單代號網路圖用節點表示活動，雙代號網路圖用箭線表示活動。5 任何乙個專案所必須的5...
軟體專案管理複習提綱
前言1 軟體專案管理是軟體工程和專案管理的交叉學科，是專案管理的原理和方法在軟體工程領域的應用。2 軟體專案的抽象性決定了軟體專案管理的難度要大於一般的工程專案管理。3 軟體專案需求管理 專案估算與進度管理 專案配置管理 專案風險管理 專案質量管理 專案資源管理等六個方面對軟體專案中的管理問題進行了...
軟體專案管理
第一次作業概述和專案啟動 1 選擇題 1 下列哪些活動不屬於專案範圍？a到教室上課 b開發軟體產品 c修建萬里長城 d老師答疑 2 pmbok的核心四項活動是下列哪四項 a時間 成本 範圍 風險 b範圍 時間 成本 質量 c人力資源 時間 成本 質量 d範圍 溝通 成本 質量 3 專案管理的四個階段...