上海交大-IT項目管理筆記說課材料

1、學習-好資料第一講1 .課程內(nèi)容a） 基本概念b）項目計劃總覽c）可行性分析d） 需求工程e）項目方法選擇f）工作量估算g）項目計劃h） 資源管理i） 項目監(jiān)控j） 外包管理k） 質(zhì)量管理l） 人員管理m）開發(fā)規(guī)范n）項目管理標準o）項目管理軟件使用第二講1 .軟件特征a）最根本的是，軟件是一種邏輯元素而不是一個物理產(chǎn)品;b）軟件是開發(fā)出來的，而不是用傳統(tǒng)方式制造出來的；c）軟件不會被用壞。普通產(chǎn)品的失效率有浴盆曲線d） 軟件的失敗概率曲線綠色線和紅色線的差異，產(chǎn)生于，每次因為需求的變化而對軟件進行的修改, 比如功能的增加、規(guī)模的增大、操作系統(tǒng)的改變等等。e）工業(yè)界已經(jīng)走向了標準化的裝配時代，

2、然而絕大多數(shù)軟件還是定制出來的。目前已經(jīng)經(jīng)歷了如下幾個發(fā)展階段：i. 科學計算函數(shù)庫ii. 重用數(shù)據(jù)結(jié)構(gòu)；iii. 重用組件f）軟件分類，很多比如：系統(tǒng)軟件、實時軟件、商務(wù)軟件、工程和科學軟件、嵌入式軟件、個人計算機軟件、基于 web的軟件2 .軟件危機a）軟件項目超出費用和進度目標普遍存在的原因在于：目標本身是完全錯誤的。b） 準確的說法是：慢性痛苦（ chronic affliction3 .項目是什么a）沒有例行的任務(wù)；b）需要計劃；c）有特定的目標需要滿足或者有特定的產(chǎn)品需要生成d）項目有一個預(yù)定義的時間范圍e）不僅僅是為自己，也是為他人；f） 工作有些特性，并分成若干個階段來進行。g

3、）項目管理，是在項目活動中應(yīng)用知識、技能、工具和技術(shù)來滿足項目需求 的過程。它通過初始化、計劃、執(zhí)行、控制和結(jié)束等活動來完成。第三講4 .項目管理的難點所在a）三角的同步發(fā)展要求，同時會相互影響。需要管理者在此三個方面尋求可以接受的 平衡。5 .項目管理的發(fā)展a） 50年代從制造業(yè)中引入甘特圖b） 60年代引入有向圖和最早、最晚完成時間等6 .項目管理者的知識管理體系：a) Core functioni. Scope mamagment,在IT項目中可以理解為需求，既最后能達到的目標;ii. Time management;iii. Cost managementiv. Quality man

4、agementb) Facilitating Function (支持性功能)i. HR management:人力資源管理ii. Communication management ：成員間的溝通，以及和客戶和資源擁有者的溝 通的管理iii. Risk managementiv. Procure management采購管理，主要指采購一下現(xiàn)有的模塊或者外包時的管理，包括進度和資金等。c) Project Integration Managementd)他們的關(guān)系如下：Tools andCore Functionst eel illiquidexpectationsFacilitating F

5、unctions9 Knowledge Areas更多精品文檔左邊的Stakeholders; needs and expectations作為輸入，通過或使用現(xiàn)有的一些 Tools and techniques, 達至U success, 這就是輸出。7 .項目管理者的必備素質(zhì)最上面的和左邊的，通用的管理知識和實踐，包括HR, time, goal管理等。Application area knowledge and practice ,指對特定應(yīng)用領(lǐng)域的知識和行業(yè)的了解。8 .項目的階段a) 每個項目階段的標記是一個或者幾個可以交付的物件(Deliverable)。Deliverable是一

6、個具體的可驗證的工作產(chǎn)品，如可行性研究，詳細設(shè)計或者一個工作原型。b）項目階段的結(jié)束是由關(guān)鍵交付物或者項目性能做標記的，以確定項目是否能夠繼續(xù)進行下一階段的開發(fā)或者進行檢測或者修正錯誤。階段結(jié)束的檢查通常被稱為phase exits , stage gates , kill points。c）因此，項目的階段通常如下圖：9 .項目生命周期a）項目生命周期定義了一個項目的開始和結(jié)束b）項目生命周期定義的階段順序通常包括某些技術(shù)的轉(zhuǎn)移和握手（hand off），如從需求到設(shè)計，從構(gòu)造到運行；他們一般是串行運行。但在風險允許時，也可以下一階段提前進行。此種重疊的階段被稱為快速跟蹤（fast trac

7、king）c） 在生命周期定義中同時會確定項目的各個階段，包括該階段的目標、 方法、涉及到的資源等等i. 各個階段需要完成的結(jié)束工作；ii. 各個階段需要設(shè)計的人員d）絕大多數(shù)項目生命周期的共同的成本和人員消耗的變化曲線:e）項目生命周期（指項目的開始到結(jié)束）和產(chǎn)品生命周期（指產(chǎn)品的設(shè)計，生產(chǎn)，使 用，報廢的過程）是不同概念10 .軟件項目的特征a）不可見；無實在的物品可供檢查b）復(fù)雜性高（以單位貨幣）c） 靈活性：軟件去適應(yīng)人和組織而不是相反。11 .軟件項目的分類a）目標驅(qū)動：比如進行某些改進，到達某個性能目標，或者進行前期驗證的目標；b）廣品驅(qū)動：生成最終的廣品c） 許多軟件項目分為兩個

8、階段，第一階段為目標驅(qū)動，此時需要進行一些原型驗證等；第二階段才是產(chǎn)品驅(qū)動，完成真正的產(chǎn)品。第四講12 .從系統(tǒng)的角度看軟件項目a）開放和封閉系統(tǒng)：需要開發(fā)人員開放系統(tǒng)并接收外界的變化，同時做相應(yīng)的調(diào)整；b）部分優(yōu)化：應(yīng)該盡量做整體的優(yōu)化，而不是僅對局部的高效提出要求；c）軟件是一個社會技術(shù)系統(tǒng)，很多時候非技術(shù)因素仍然在起作用。d）項目的目標必須清晰定義，以確定成功的關(guān)鍵。每一個項目必須有一個項目權(quán)威，該權(quán)威被稱為項目指導(dǎo)委員會（steering committee）,項目的目標必須由指導(dǎo)委員 會確定。e）所定義的目標必須是可以并且易于測量的。從而更能夠衡量是否成功。如減少客戶抱怨50%,就比

9、改善客戶關(guān)系更容易測量，因而是制定的合適的目標。目標的滿 足與否，必須能夠用“ yes”或者“no”來清晰回答是否完成了。同時，對于目標 必須給出明確具體可行的測量方法。比如，接受到的客戶電話投訴減少 50%。13 .項目的人員a）項目影響者：項目小組成員、同一組織的其它人員、客戶直接相關(guān)人員、客戶間接 相關(guān)人員b）不同的影響者有不同的目標和關(guān)心的問題。項目領(lǐng)導(dǎo)者要協(xié)調(diào)這些目標，使所有各方都能從項目中獲益從而都盡量使項目從成功的方向前進。c）應(yīng)該盡可能多和全面的考慮涉及的各個方面的人員的影響14 .組織內(nèi)的信息與控制a）遞階信息與控制系統(tǒng)b）決策與信息的層次i. 策略層：確定總體目標ii. 戰(zhàn)

10、術(shù)層：保證項目目標的實現(xiàn)iii. 操作層：確定每天的任務(wù)c）信息的不同類別d）度量：包括開發(fā)的規(guī)模i. 性能度量；ii. 預(yù)測度量e）總體來看，系統(tǒng)內(nèi)的信息和控制的流動如下：lirgurr l-J的5陽Mi 叩 rftr 甘鵬曲iwm睢?！皕t* Mgf15.項目經(jīng)理面臨的挑戰(zhàn)和問題a）對項目進度的估計和計劃。無法準確估計，導(dǎo)致總是和計劃不一樣。學習 好資料b) 缺乏明確的質(zhì)量測試和估計的標準和度量方法。c) 缺少組織決策的指南d) 缺少使進度可視化的進度。真正來判斷某一項完成的進度，仍然很困難。e) 角色的定義，如何將任務(wù)分配給適合的人f) 不正確的成功準則。比如，片面強調(diào)完成時間。g) 缺

11、少更多的其它的標準。16. 從項目成員來看a) 工作任務(wù)和目標的不正確或者不明確的描述；b) IT 的管理失誤，比如需求分析的欠缺c) 缺少實際客戶應(yīng)用領(lǐng)域的知識d) 缺少及時的文檔，比如馬上開始編碼了，但還沒有需求文檔。e) 前續(xù)任務(wù)或者前提條件沒有及時完成f) 用戶與技術(shù)人員之間缺少交流和溝通g) 缺少質(zhì)量控制的方式和標準h) 軟件環(huán)境以及開發(fā)模式等新技術(shù)的變化i) Deadline 的壓力17. 軟件項目常見錯誤(來自快速軟件開發(fā))a) 產(chǎn)品相關(guān)的錯誤哦i. 需求的鍍金： 客戶總是提出比實際需求更多的性能要求， 無論是否他真正需要；ii. 功能蔓延：項目平均會有25%的需求變更。iii.

12、 開發(fā)人員的鍍金： 開發(fā)人員著迷于新技術(shù)新方法， 而不是最合適， 最牢靠的技 術(shù)。項目經(jīng)理不能片面提取開發(fā)人員的新技術(shù)的建議；iv. 又推又拉的交易：經(jīng)理往往在批準項目進度延時的同時又加入新的功能要求；v. 研究導(dǎo)向的開發(fā)：充滿了不確定性；b) 和過程相關(guān)的錯誤i. 缺乏計劃；ii. 過于樂觀的計劃；iii. 在壓力下放棄計劃或者非理性的改變計劃iv. 缺乏足夠的風險管理或者對未來的風險預(yù)測不夠；v. 承包人導(dǎo)致的失敗。通常來自于過于相信承包人。vi. 在模糊的項目前期浪費太多時間vii. 前期活動不達到應(yīng)有的目的viii. 設(shè)計的低劣ix. 沒有質(zhì)量保證措施；x. 沒有有效的管理措施；xi.

13、 太早并過于頻繁的集成xii. 項目估算時遺漏必要的任務(wù)。xiii. 追趕計劃的想法。想通過后期的時間抓緊，來趕上前期某些因素導(dǎo)致的延期。xiv. 魯莽編碼c) 技術(shù)相關(guān)的錯誤i. 銀彈綜合癥：過于相信以前沒有采用過的技術(shù)的宣傳。ii. 過高估計了新技術(shù)和方法帶來的效果，忽略了對新技術(shù)的掌握和熟練也需要時間和資源。iii. 在項目中途切換工具iv. 缺少自動的源代碼控制和管理手段或者方法。尤其對于分布式的多點開發(fā)。d) 人員相關(guān)的錯誤i. 挫傷積極性：由于壓力的下傳并經(jīng)常修改原來的需求設(shè)計導(dǎo)致；ii. 人員的素質(zhì)低下iii. 對于問題員工的失控： 比如某個員工總是延誤工期， 而無法對他進行有效

14、的控制。iv. 個人英雄主義v. 項目后期添加人員，因為還需要對他們進行培訓(xùn)vi. 辦公環(huán)境的最優(yōu)化；vii. 開發(fā)和客戶的有效溝通和交流；viii. 不現(xiàn)實的預(yù)期。ix. 缺少高層的推動和支持x. 缺乏相關(guān)人員的齊心協(xié)力。xi. 缺乏用戶介入xii. 政治高于物資xiii. 充滿想象和環(huán)抱僥幸第五講18. 項目計劃的作用a) 指導(dǎo)項目的實施；b) 記載項目計劃的前提和假設(shè)，比如需要的資金以及設(shè)備應(yīng)該在何時到位；c) 記載根據(jù)選擇的方案以及據(jù)此做出的決策， 比如依據(jù)何種理由決定采用了何種的模型和算法。d) 促進項目涉及人員之間的溝通：作為彼此溝通的基礎(chǔ)和出發(fā)點。e) 確定項目管理的內(nèi)容、范圍和

15、時間f) 作為度量和控制項目進程的基準19. 項目計劃應(yīng)該包含的內(nèi)容和回答的問題a) 什么：工作的具體內(nèi)容，一定時期的工作重點；b) 怎樣：如何完成這些工作和任務(wù)c) 誰：確定具體的人員和部門；d) 何時：各項工作的起始和終止時間e) 多少：每項工作需要多少經(jīng)費和工作時間以及人力資源；f) 哪里：各項工作開展時以及測試時和最后交互使用時的環(huán)境20. 項目計劃必須滿足：a) 動態(tài)性要求：項目計劃本身是一個滾動過程， 應(yīng)該有必要的彈性； 尤其對于距當前時間較遠的項目b) 職能性：從總體出發(fā)，涉及到各相關(guān)部門c) 相關(guān)性：子計劃是會相互影響的；d) 系統(tǒng)性：大的項目也可以分成多個小項目，之間有內(nèi)在的

16、邏輯聯(lián)系e) 目標性：f) 積極性：應(yīng)做技術(shù)經(jīng)濟分析21. 項目計劃的模型a) StepWiseProject Planningb) PRINCE222. 例子1，開發(fā)學校的財務(wù)系統(tǒng)的自我設(shè)想步驟a) 和財務(wù)系統(tǒng)的主管領(lǐng)導(dǎo)聯(lián)系，獲取他們現(xiàn)在對該系統(tǒng)的期望包括原來系統(tǒng)的弊端；同時了解對于該系統(tǒng)學校可能給出的投資，以及希望獲取的收益； ( 此時應(yīng)該和客戶討論明確項目的客戶責任人)b) 假設(shè)該系統(tǒng)已經(jīng)完成，和使用該系統(tǒng)的人員溝通，了解他們現(xiàn)有系統(tǒng)的工作過程，業(yè)務(wù)流程，同時了解他們對該系統(tǒng)的期望；c) 了解市面上其它的類似系統(tǒng)的功能和價位d) 分析確定該套系統(tǒng)是否值得開發(fā)， 包括， 對于開發(fā)者的投資收

17、益比、 對于學校使用者的投資收益比；e) (確定項目的所有涉及人員和他們的興趣目標、關(guān)心的問題)f) (修改目標，最低也應(yīng)該使各方面都不反對或阻撓項目的實施)g) 建立各方通信的渠道和人員聯(lián)系窗口，并確定一些定期的溝通制度等h) 帶領(lǐng)分項目負責人進一步了解需求， 并確定項目計劃； 期間可能從a 多次迭代 ( 應(yīng)該將這些需求明確化，并制定目標的測試方法)i) 設(shè)計 編碼 測試23. 計劃過程a) 選擇項目b) 確定項目的范圍和目標i. 選擇項目的客戶方責任人， 也就是他可以確定工期和功能需求， 并在客戶的多個部門的意見不統(tǒng)一甚至矛盾時做出統(tǒng)一的明確的決定。ii. 確定項目的最終目標，并明確這些目

18、標的衡量和測試方法iii. 確定項目的客戶方所有涉及人員和他們的興趣目標、關(guān)心的問題iv. 根據(jù)上面第三項，修改目標， 最低也應(yīng)該使各方面都不反對或阻撓項目的實施。有時候由于新項目的實施將使某些部門增加此前并不存在的負擔或者風險， 這將使該部門產(chǎn)生抵觸情緒。如果該部門屬于重要部門必須得到他們的重心配合， 則有可能需要增加對他們有益的功能。 此應(yīng)慎用， 否則可能使系統(tǒng)越來越 復(fù)雜。v. 建立各方通信的渠道和人員聯(lián)系窗口，并確定一些定期的溝通制度等。c) 確定項目的結(jié)構(gòu)，包括總體的策略i. 建立項目和客戶的策略計劃的關(guān)系，明確正在建設(shè)的項目和客戶總體發(fā)展策略的關(guān)系，以此獲得客戶高層的支持； 同時，

19、在建項目應(yīng)該保持開放型， 完成后的項目不應(yīng)該成為一個信息化的孤島。ii. 建立標準和過程1. 開發(fā)軟件的組織必須定義開發(fā)過程。在最簡單的情形下， 在定義產(chǎn)品的同時，需要對軟件生命周期的每個階段進行定義2. 這些標準和過程可能有：a) 變更控制和配置管理標準；b) 質(zhì)量標準和過程手冊；c) 質(zhì)量程序和質(zhì)量控制流程d) 項目計劃和控制標準3. 如果客戶企業(yè)有現(xiàn)成的開發(fā)標準或者質(zhì)量控制體系， 可以直接使用； 否則就應(yīng)該首先確立最基本的流程和控制辦法， 比如功能修改流程、 是否要周期性的碰頭進行協(xié)商等。iii. 建立項目團隊組織：確定團隊結(jié)構(gòu)，以及是否應(yīng)該進行拆分；明確每一個任務(wù)的負責人。d) 分析項

20、目的特征i. 分析項目是目標驅(qū)動還是產(chǎn)品驅(qū)動ii. 分析項目的其它特征，如是數(shù)據(jù)庫操作，還是寫嵌入式的控制程序。iii. 確定項目的高層次的項目風險：比如人員短缺， 客戶方使用人員的熟悉性， 在不熟悉的階段是否會有矛盾或者引發(fā)問題；客戶方是否已經(jīng)有對應(yīng)的維護人 員；是否需要給客戶使用人員一個逐漸熟悉的過程。iv. 考慮用戶有關(guān)具體實現(xiàn)方面的需求， 比如客戶要求使用何種語言， 采用何種技 術(shù)，采用何種模型。v. 選擇項目適應(yīng)的生命周期方法，比如在用戶的需求不甚明確的時候， 可能需要使用原型法。vi. 檢查估計的資源是否能夠到位當確定了主要的風險和項目的大致方法后， 可以重新估計項目的工作量和所需

21、的資源，此時可以采用功能點法來進行稍微精確些的估計。e) 確定項目的產(chǎn)品和活動 關(guān)鍵步，遠階段粗，近階段應(yīng)該細i. 確定和描述項目產(chǎn)品或交付物。包括中期在內(nèi)部產(chǎn)生的文檔；1. 確信我們已經(jīng)完成確定了項目過程中所需要生成的所有產(chǎn)品， 包括各種文檔、 訓(xùn)練材料、 操作手冊等。 只有全部確定了產(chǎn)品， 才能確定我們的活動。2. 產(chǎn)品包括： 技術(shù)產(chǎn)品， 如訓(xùn)練材料和操作指令， 也包括管理和質(zhì)量方面的 材料，例如屬于管理范疇的計劃書。3. 產(chǎn)品應(yīng)形成層次結(jié)構(gòu)： 主要產(chǎn)品由子產(chǎn)品構(gòu)成， 子產(chǎn)品還有更小的子產(chǎn)品。并用產(chǎn)品分解結(jié)構(gòu)(Product Breakdown Structure:PBS )來記載。PBS

22、的描 述方法中的每個節(jié)點內(nèi)容如下a) 產(chǎn)品的名字/ 標識：如 CPUb) 產(chǎn)品的功能；如邏輯運算c) 產(chǎn)品的派生物(由其派生的其它產(chǎn)品) ，如需求文檔產(chǎn)生設(shè)計文檔d) 產(chǎn)品的分解結(jié)構(gòu)e) 產(chǎn)品的形式：文檔還是圖形還是代碼f) 相關(guān)標準，比如該文檔使用的模板g) 適用的質(zhì)量標準：該產(chǎn)品達到何種標準才算合格。4. 比如從頭開發(fā)套包含軟硬件設(shè)施的工資管理系統(tǒng)，其中的一個產(chǎn)品的PBSS包含如下的內(nèi)容，包含了3個層次：產(chǎn)品選擇：a) 容量，有多少雇員的信息需要維護；b) 辦公室的布置；c) 用戶需求：i. 現(xiàn)存系統(tǒng)的描述ii. 用戶所需的修改；iii. 測試案例d) 潛在供應(yīng)商列表e) 邀請信ii. 寫

23、出一般性的生產(chǎn)流程，通常用產(chǎn)品流圖(Product Flow Diagram , PFD)來描述。由于某些產(chǎn)品需要在其它產(chǎn)品產(chǎn)生后才能進行，那么寫出一般性的生產(chǎn)流程，有助于確定產(chǎn)品的生產(chǎn)順序。例如程序設(shè)計的一般性生產(chǎn)流程如下圖：更多精品文檔學習 好資料可以根據(jù)產(chǎn)品的PBS圖來確定該系統(tǒng)的 PFD,比如在確定了上例中的 PBS 后，可以畫出對應(yīng)的 PFD如下：suppbert需ju朝E detcnpftonmodvfiMf更多精品文檔iii.iv.(ysiemSutfWyu4erfLJ OtX*rt ose< iPlan otic*UyoufIssmoIWtliitlQCI IDlente

24、確定產(chǎn)品的實例：比如系統(tǒng)中的各個模塊定義理想的活動網(wǎng)絡(luò)。比如，何時應(yīng)該有何模塊產(chǎn)出；基本上，此時將此前確 定的PFD的名詞修改為動詞或動賓詞組，就成為了活動的網(wǎng)絡(luò)圖：v.考慮階段和檢查點，修改理想的活動網(wǎng)絡(luò)。 上一步得出的是一種理想狀態(tài)的活動網(wǎng)絡(luò)圖，比如，一階段結(jié)束后，下一階段馬上就可以進行，認為不需要對上一階段的活動加以檢查或者復(fù)查， 上一階段的結(jié)果也不會出問題。 但實際上是 需要進行檢查和復(fù)查的。通常都需要將項目分割成若干個階段，并在每個階段的結(jié)束引入檢查活動，添加檢查點f） 估計每個活動的工作量在總體的時候基本可以估計個大致過程量i. 自底向上的估計。由于此時已經(jīng)對每個產(chǎn)品都做出了PB&

25、#167;故可以先拆分成多個模塊， 然后各自估計模塊的工作量， 最后加以疊加 （當對整個產(chǎn)品還沒有拆 分的時候， 只能采用自頂向下的方式進行粗略的估計） 。 同時可以將完成時間， 以及某個關(guān)鍵活動的最晚完成時間標注在活動圖上， 進而可以計算出整個項目 的時間ii. 對計劃進行修改以生成可控的活動， 根據(jù)上一步的結(jié)果， 進一步進行精確控制；1. 對于需要很長時間的活動， 由于不好進行中途的完成量的評估， 因此應(yīng)該 將之加以分解， 以便在活動的中途可以添加檢查點， 進行進度的評估。 也 就是應(yīng)將粒度劃小。2. 比如對于某項功能模塊， 可以先行估計所需的代碼行， 進而便于小周期的 檢查。3. 而對于

26、二次開發(fā)，只能按任務(wù)來進行初步的分配時間。g） 確定活動風險i. 識別或量化活動風險，確定風險的危害和風險發(fā)生的可能性ii. 針對風險的兩點：可能性和危害，制定主要風險的降低方法（降低可能性）和緊急處理手段（減少危害）iii. 在考慮風險的基礎(chǔ)上對計劃進行重新估計和調(diào)整，必要時需要添加新的活動；比如對于一項必須采用的新技術(shù)， 則加入一個培訓(xùn)過程； 或者預(yù)留一部分的人 手，以防止人員流動的風險。h） 分配資源i. 確定和分配資源；ii. 在考慮資源約束的情況下修改計劃1. 某些人員在同一時間內(nèi)多個任務(wù)都需要， 此時只能制定優(yōu)先級； 而且項目 周期可能會因為人員等待而延長。2. 而增加人手來保證某

27、些人在項目一開始就能夠到位可能會造成他們有時 候處于等待狀態(tài)，導(dǎo)致效率不高，進而會導(dǎo)致項目總成本上升。i） 確定檢查公布計劃i. 檢查項目計劃中的質(zhì)量因素；1. 許多項目經(jīng)常因為前面完成活動的質(zhì)量問題需要重做。 此時可能使項目失 去控制。2. 必須確認在任務(wù)報告說 “完成了” 時， 它確實完成了。 任務(wù)的 “進入需求” ， 明確該任務(wù)開始進行時的必要條件和前提任務(wù)；而任務(wù)的“退出需求” ， 標明該任務(wù)的完成批判標準。因此質(zhì)量控制就必須檢查此二種需求。3. 如果有過程質(zhì)量控制的標準規(guī)范，應(yīng)該使用他們。4. 比如對于用戶需求， 一個基本的處理辦法就是用戶需求文檔需要經(jīng)過用戶閱讀和確認。 但如果到最

28、后才全部拿出來給用戶確認， 此時出現(xiàn)問題的話， 就已經(jīng)太晚了。 因此應(yīng)該在每次會談后， 都將采訪記錄交給用戶確認， 確 保及時的和用戶意圖保持一致。ii. 書面化計劃并上報批準j） 執(zhí)行計劃；逐步 要制定k） 制定更細層次上、可經(jīng)常檢查和度量的計劃。計劃的制定是一個貫穿始終的、 細化的過程，而不可能在一開始就制定得盡善盡美。因此對于近期的活動，詳細的計劃；而對于遠期的計劃，只能逐步推移的過程中進行細化。上面的步驟基本如下面的流程：0 "不 Setociot*dproject wmd 由 0cti*esLx pru|«cT cfiAr0cbxisticsTactwiyRevi

29、ewI/products artl actwit*ReviewLfiww )w«*產(chǎn)七，koiE priWI1r.Step6的時候應(yīng)該對每一步的風險都加以分析；Step8有一個返回的箭頭，就是通過制定更低層次的計劃并加以執(zhí)行而得。第六講作業(yè):學習 好資料，某公司需要對一個字處理軟件進行可用性測試.為了完 成測試工作，首先需要寫一個用戶手冊，然后選定一些 用戶參加測試工作,在選擇過程中，用戶需要填寫一張 調(diào)查表，上面將反映這些用戶以前使用字處理系統(tǒng)的經(jīng) 臉和所受過舟訓(xùn)練.，在測試時，這些用戶將采用字處理系統(tǒng)完成特定的任務(wù), 完成任務(wù)所需的時間和使用過程中所遇到的問題將被記 錄下來，磔誠

30、完成后，用戶將填寫一張問卷以反映他們對系統(tǒng)的 感受,M有測試中的數(shù)據(jù)將要被分析，最后需要完成一份對系 統(tǒng)的改進建議的報告.請作出PBS,PFD和初步的活動圖，下周交，打印稿第七講24.項目計劃過程小結(jié)a） 一個計劃需要包含下列活動i. 建立項目目標ii. 分析項目特點iii. 建立包含組織、標準、方法和工具在內(nèi)的基礎(chǔ)架構(gòu)iv. 確定項目的產(chǎn)品和所需的活動v. 分配資源、調(diào)整活動圖vi. 建立質(zhì)量控制手段b）項目管理是一個迭代的、不斷反復(fù)的過程25.項目評估的目的和內(nèi)容a）項目的起因i. 市場需要ii. 業(yè)務(wù)需要iii. 客戶需要iv. 技術(shù)進步的需要v. 法律的進步或更新vi. 社會需要b）

31、“不做”總是一個應(yīng)該仔細考慮的方案c）項目進行前需要評估；進行中也要不斷評估，以亡羊補牢。通常應(yīng)該在某個可以進一步的階段，進行評估d）評估的原則i. 投入產(chǎn)出匹配原則ii. 面向需求的原則。項目因需求而存在，如果需求不存在或者不迫切，項目的存在理由也不充分。iii. 資金的時間價值原則1 .資金本身能通過時間產(chǎn)生價值2 .資金的投入可能是多次的iv. 公正、科學、客觀原則。e）項目評估和可行性分析的關(guān)系i. 著重點不同： 可行性研究注重從企業(yè)角度評價； 項目評估注重項目的宏觀效益， 包含很多方面的評估，如 宏觀策略評估、 操作性評估、計劃評估、 技術(shù)評估、風險評估、社會可行性評估、經(jīng)濟性評估i

32、i. 為項目決策服務(wù)的任務(wù)和目的不同1. 可行性研究為復(fù)雜的技術(shù)經(jīng)濟性論證工作，往往要規(guī)劃多種方案；2. 項目評估一般借助于可行性研究的成果進行系統(tǒng)的審查和核實iii. 時序和地位不同， 可行性研究是項目評估的前提； 項目評估為決策提供最直接 和最終的依據(jù)。第八講26. 策略評估的內(nèi)容 策略評估有很多方面a) 目標：該項目是否有助于企業(yè)的整體目標的實現(xiàn)，對整體目標的實現(xiàn)有何貢獻b) IS計劃(信息系統(tǒng)計劃)，避免信息孤島的出現(xiàn)：提出的系統(tǒng)如何與IS計劃相適應(yīng)？ 它將替換或者與哪些系統(tǒng)接口？它與將來開發(fā)的系統(tǒng)有何交互關(guān)系？c) 組織結(jié)構(gòu)：新系統(tǒng)對目前的部門和組織結(jié)構(gòu)有何影響？是否意味著需要重組一

33、些部門？是否與目前的已有功能重疊？d) MIS 系統(tǒng)：新系統(tǒng)將在組織的何層次上提供何種信息？以何種方式對現(xiàn)存的管理信息系統(tǒng)進行補充和提高？能對現(xiàn)有管理提供何種幫助？e) 人員： 系統(tǒng)將以何種方式影響人力水平和現(xiàn)存雇員的技術(shù)？它對組織整個人員開發(fā)策略有何影響？或者現(xiàn)存人員能達到熟練使用該系統(tǒng)的能力嗎？如果不能， 是對他們進行培訓(xùn)還是另找新人?f) 外在的影響：客戶對新系統(tǒng)的接收程度？27. 策略評估中的模塊組式管理a) 模塊組是指一組相關(guān)的、 協(xié)調(diào)管理的項目， 通過模塊組式管理， 以獲得更好的效益。同時也可能會有通用的軟件，以及進行人員的專業(yè)化成長。b) 有效的模塊組管理需要一個明確的、 邊界清

34、晰的模塊組目標； 項目必須根據(jù)模塊組 目標來選擇c) 通常應(yīng)該整體的發(fā)展目標和現(xiàn)有的組織架構(gòu)來選項目，以避免有限的資源競爭28. 策略評估中的業(yè)務(wù)管理a) 所選擇的項目最后會成為業(yè)務(wù)的一部分，不可避免的會產(chǎn)生資源競爭29. 操作可行性評估a) 其內(nèi)容指：i. 評估系統(tǒng)是否能夠真正解決項目設(shè)立之初的初衷，是否足夠改變原來的使用習慣ii. 系統(tǒng)安裝運轉(zhuǎn)后，是否有足夠的人力資源來運行維護它iii. 用戶是否對新系統(tǒng)有抵觸情緒，該情緒是否可控30. 計劃評估評估項目完成的時間是否足夠，是否能夠在能產(chǎn)生效益前完成31. 技術(shù)評估a) 技術(shù)的成熟程度： 實驗室技術(shù)、經(jīng)過中試的技術(shù)、經(jīng)過工業(yè)化應(yīng)用的技術(shù)b)

35、 市場對技術(shù)的需求程度：顯在的(市場一直在尋找的) 、潛在的、競爭態(tài)勢的(各 有優(yōu)劣的技術(shù))c) 技術(shù)轉(zhuǎn)換成效益的成本d) 支撐技術(shù)和條件： 還需要的周邊設(shè)備的技術(shù)發(fā)展、 供應(yīng)鏈成熟度、 上下游是否成熟 齊全e) 發(fā)展前途： 能在賺回成本前保證不淘汰； 或者從占領(lǐng)市場或者打壓競爭對手的角度出發(fā)32. 技術(shù)方案的選擇a) 要考慮的制約條件i. 需求制約：現(xiàn)存的需求結(jié)構(gòu)以及可能的變化ii. 資源制約：資金、人力、自然、其它因素iii. 環(huán)境制約：經(jīng)濟技術(shù)環(huán)境、社會人文環(huán)境、自然環(huán)境b) 選擇的原則i. 經(jīng)濟性原則：最小的投入，產(chǎn)生最大的效益ii. 發(fā)展原則：希望長線看好iii. 兼容性原則：原有的

36、東西仍然能用，錦上添花。iv. 相關(guān)效果原則c) 選擇視角i. 技術(shù)的先進性ii. 技術(shù)的適用性33. 風險分析a) 風險的識別b) 風險的評估i. 風險分析：可能性、危害ii. 風險的優(yōu)先級：不同時間、時期、地點、人員，風險的優(yōu)先級都可能改變且不同；34. 社會可行性a) 是否滿足所有項目涉及者的利益b) 是否滿足法律或合同的要求35. 經(jīng)濟性分析a) 列舉所有成本：開發(fā)成本、運行成本b) 列舉因為該項目而產(chǎn)生的效益，需要考慮好效益增益的度量方式c) 如何進行經(jīng)濟性估計i. 成本估計：自底向上估計，將任務(wù)分解，估計每一個片段，累加多個片段ii. 自頂向下的攤派：從管理者的成本期望開始， 確定

37、在此成本的約束下能夠交付的產(chǎn)品，提供給管理者做多種選擇(給多少錢，辦多大的事)36. 成本：a) 開發(fā)成本b) 安裝成本c) 運行成本37. IT項目可能的成本a) 采購成本：咨詢成本、設(shè)備購買或租用成本、設(shè)備安裝成本、場所準備和修改、資金成本(上面都占用了資金，資金本身是可以產(chǎn)生效益的) 、管理成本(主要是管理者的工資等隱形成本)b) 啟動成本：操作系統(tǒng)軟件、安裝通訊設(shè)備、啟動人員成本、招聘費用、對其它部門的影響、啟動活動本身的管理c) 與項目有關(guān)的成本： 應(yīng)用軟件、 為了適應(yīng)本地系統(tǒng)需求而進行的軟件修改、 內(nèi)部開發(fā)人員成本、適應(yīng)該系統(tǒng)的人員培訓(xùn)、數(shù)據(jù)采集和分析、文件準備(如手冊) 、管 理

38、開發(fā)d) 運行成本：系統(tǒng)維護成本、場地設(shè)備租用、資產(chǎn)貶值、職員管理e) 一次性成本：系統(tǒng)啟動、系統(tǒng)開發(fā)、新的軟硬件、用戶培訓(xùn)、場所準備、數(shù)據(jù)系統(tǒng)轉(zhuǎn)換f) 重復(fù)成本：應(yīng)用軟件的維護、數(shù)據(jù)存貯費用的遞增、通信成本、新軟件和硬件、供應(yīng)商和其它花費38. 效益a) 直接效益b) 可見的間接效益i. 成本下降和避免ii. 減少錯誤iii. 柔性的增加iv. 執(zhí)行活動的速度增加v. 改善計劃和控制vi. 開拓新市場和增加銷售機會c) 不可見的效益，比如社會效益，不是簡單的轉(zhuǎn)化為金錢的i. 競爭的必要性：競爭對手在做ii. 更及時的信息獲取iii. 改善的組織計劃iv. 增加組織的柔性v. 提升組織學習和理

39、解vi. 能獲取更好更多更快的信息vii. 可以調(diào)查更多的方案viii. 通過改進工作過程從而改善雇員的士氣d) 凈收益： 在項目生命周期內(nèi)的收入和中的成本的差。不考慮時間因素e) 回收期限：將初始投資收回的期限i. 簡單，對小的估計錯誤不敏感；ii. 忽略了整個項目的盈利空間f) 回報率：項目周期內(nèi)的總收益/ 周期/ 總投資* 100i. 未考慮時間因素ii. 易與銀行利率混淆g) 凈現(xiàn)值(NPV)i. 考慮時間因素上，對未來的預(yù)期收益加以折扣。 比如， 預(yù)期明年收益為 10 萬，則在今年計算時只能按照 8 萬來計算。ii. 假定年折扣率r 為 10%， 則， 明年的 100 元， 只相當于

40、現(xiàn)在的 91 元 (91 * 1.1=100);后年的100元，只相當于現(xiàn)在的83元( 83*1.1 * 1.1 = 100)。從而有如下公式：目前值 = t 年后的值 / (1 + r )t該方法的問題在于年折扣率不好確定。 通?？紤]當前的物價、利率、 預(yù)期的風險可能性(比如新技術(shù)的突破導(dǎo)致收益急劇下降) 。h) 內(nèi)部的回報率： 為了提供一個可以與現(xiàn)有利率進行比較的方法。 內(nèi)部回報率就是使NPV 為 0 的折扣率39. 綜合評估 將各個評估綜合考慮，得出是否實施該項目的最后結(jié)論a) 使用決策矩陣如下， 將多個待選方案以及應(yīng)該考慮的多個因素分別成行和成列， 同更多精品文檔學習-好資料時，對每種

41、考慮因素加以不同的權(quán)重, 最優(yōu)方案?？傻贸雒糠N方案的綜合得分，據(jù)此可以得出FejiSibility Ci if eri aWeigM人 . a il u 上 . ： ： Operalionl FeaabilHy30%JTiaionaUfy To wnat degree does the_candidate Boliilon benefit the organization?Political; How well will the solution berec eived by users? Jul anagement?Cancliclatle 1Candidate 2Only supports

42、Fully supportsSarno aslulembers ServicearequiredCandidaterequirements andfunctionalitycurrent businessprocesses wouldhedW in be modifiedScore： 60Score: 100Scdte:100Tedinic*i1 F4«i9bility30* nTeclmologv： Assessment of maturity, availability, ability to acquire, and desifatjiiity of computer tech

43、noEo/ needed to support the candidate.Exjieilise: A ssessment of the techricel e;pertrse needed to developp operate； and Aiainlainthe candidate systemCurrent release ofCurrtnt lechnkalPlatinum Plus isstaff only has1 0; only or marketPowerbuiFder6 weeksex perienere.Staff thinks Accessapp is simple.Sc

44、oie: 50Scoie: 95Ec&nomk Feability30、Cofir to D«velap ，；Payliackpeiiod MiscountM Net Prent ValueDetailed Calculations1350,000I418Q0Moaooo1.5 ye an?3+5yeisX3 ye<iis1210,000*306,7 48$32 S, 500See aTtachnieiit ASee Altaclinient ASee Attachment AScore: 60Score: 85Sccie： 90Schedule Faaribility

45、10%Assessment of how long the solution will take to design and irnplennent.RankingHLass tharj 3 months9-12 months9 monthsScore: 95Score： 30Score： 8560.59283.5ItwiMi-jMcsu-40. 決策方法頭腦風暴法a）方法：召集一堆人任意的提出各種想法，每個人必須發(fā)言；任何人不允許對其它人的任何意見進行批評；b）收集這些方法后再進行評估，篩選其中合理的方法深入跟蹤和批判41. 決策方法：決策矩陣a）方法：列舉多個方案，以及考慮時的多個因素，必

46、須對每個因素施加一定的權(quán)重，某些因素可能是“必須的”從而具有“一票否決”的作用。b）舉例如下表的數(shù)據(jù)庫方案選擇，其中E,表示essential,必須的：c） 決策矩陣法最困難的是確定每個考慮因素的權(quán)重： delfa方法。42 .需求工程回答一下問題a）為什么實施該項目；b）項目要達到什么樣的結(jié)果；c）工作的具體內(nèi)容是什么；d）如何實施該項目；e）如何定義該項目的完成43 .需求工程的主要內(nèi)容a）目標管理b）范圍管理c） 需求管理i. 管理需求的目的ii. 管理需求的困難性iii. 軟件需求管理的特性iv. 需求工程-需求捕獲v. 如何獲取需求vi. 需求工程文檔、工具44.目標管理a）早期發(fā)展

47、：魯克1954發(fā)表“管理實踐”而提出；通用電氣也提出“管理決策分散 進行，要求用客觀目標和對目標完成進度的客觀測定來代替主觀的評價和個人的監(jiān) 督。通過實行一種客觀的測定計劃，可把主觀人員從具體事務(wù)中解脫出來”。b）目標管理的特點i. 是參與管理的一種形式，上下級目標形成“目標一手段”鏈：下級目標是上級目標的手段。ii. 目標管理強調(diào)自我控制。管理，人們應(yīng)控制的是行為的動機和目的，而不是行為方式本身。iii. 促進下方權(quán)力，有助于協(xié)調(diào)集權(quán)和分權(quán)的矛盾。iv. 注重“成果第一”的方針。c）項目目標的特點i. 項目目標就是實施項目要達到的期望結(jié)果ii. 項目目標是多目標的，往往要到達諸如時間、效益、

48、質(zhì)量多個綜合指標。更多精品文檔學習-好資料iii. 項目目標有動態(tài)的優(yōu)先性，在不同階段，多個綜合指標各自有不同的優(yōu)先級。比如， 性能在初始階段最重要； 而成本在實施階段最重要， 時間在結(jié)束階段最重要。iv. 項目目標有層次性：總體目標、具體目標；階段目標、長期目標?？傮w目標是通過多個具體目標來實現(xiàn)的。長期目標也是通過各個階段的階段目標來實現(xiàn)的。d) 項目目標的描述：i. 是定量的、可度量的；不應(yīng)該是定性的、不可度量的。比如“達到最好”就不是目標，因為他不是定量的，也不可度量。ii. 應(yīng)該使每個成員都清楚明白的認知；iii. 面向結(jié)果的，不是面向成本的；iv. 可實現(xiàn)的，現(xiàn)實的；v. 盡可能的簡

49、單，容易理解。vi. 能起激勵作用。e) 目標管理的建議i. 目標應(yīng)該是分層次的；從總體到局部；從長期到階段；ii. 目標應(yīng)形成一個網(wǎng)絡(luò)。 不要使各個單位、 各個個人的目標都完全獨立； 應(yīng)該盡量使多個單位、 個人之間的目標互相關(guān)聯(lián)。 從而可以避免人們采用對自己的職能有益而對公司整體缺有害的做法。iii. 目標應(yīng)該多樣性。多個方面都應(yīng)該考慮到。iv. 長期目標和短期目標應(yīng)成為一個有機、關(guān)聯(lián)的整體； 選擇短期目標的過程也是評定長期目標先后次序的過程。v. 培養(yǎng)管理者的素質(zhì)：1. 善于利用時間；2. 注意每個員工的貢獻和對手下給予正確的評價：3. 能發(fā)現(xiàn)手下的長處和短處；4. 善于分清工作的主次先后

50、；5. 善于做出有效的決策。45. 項目范圍管理：為了實現(xiàn)項目，對在實現(xiàn)過程中所必須要做的工作和事情進行的管理。有如下層次含義：a) 產(chǎn)品范圍管理：對該項目實施過程中和實施后將要產(chǎn)出的產(chǎn)品進行管理。b) 產(chǎn)品規(guī)格管理：對產(chǎn)品的特征、功能的具體描述c) 項目范圍：該項目所必須要做的工作。i. 啟動： 組織正式開始一個項目； 啟動的輸出是項目章程， 該章程標志啟動的存 在，并簡單描述該項目。ii. 范圍計劃： 在章程基礎(chǔ)上， 對項目的范圍做出明確規(guī)定， 包括用以描述項目或者項目階段成功的標準。iii. 范圍定義：在計劃基礎(chǔ)上進一步細化和分解。iv. 范圍的核實：將范圍交由相關(guān)人員部門進行確認。v.

51、 范圍的變更控制。46. IT 的需求管理就是項目范圍管理a) 軟件生命周期中，一個錯誤發(fā)現(xiàn)的越晚，修復(fù)錯誤所需的費用越高b) 很多錯誤是長期就隱藏并一直存在的；c) 在需求過程中會產(chǎn)生很多錯誤d）在需求階段代表性的錯誤是：疏忽、二義性、不明確、不一致、不正確的事實。e）需求階段的錯誤是可以被檢查出來的。重復(fù)檢查可以發(fā)現(xiàn)大部分錯誤。47.需求管理的困難a）需求不總是顯而易見的，而且它來自各個方面；b）需求并不總是容易用文字明白無誤的表達；c） 存在不同種類的需求，其詳細程度各不相同。d）若不加以控制，需求的數(shù)量將難以管理和控制；e） 需求之間總相互關(guān)聯(lián)f） 需求有唯一的特征和特征值g）需求涉及

52、多個方面，意味著要由功能交叉的各組人員來管理；h）需求會變更。48.什么是軟件需求a）需求為用戶解決問題或達到目標所需的條件或權(quán)能；b）系統(tǒng)或系統(tǒng)部件要滿足合同、標準、規(guī)范和其它正式規(guī)定文檔所需要具有的條件或 權(quán)能。c） 一種反應(yīng)上述條件或權(quán)能的文檔說明d）需求具有層次性：更多精品文檔業(yè)務(wù)需求：企業(yè)的經(jīng)營目標、 企業(yè)擬實施的的某項業(yè)務(wù)的目標，比如提升客戶忠誠度；就IT項目而言，業(yè)務(wù)需求產(chǎn)生用戶需求，也就是從用戶的角度看，最后完成的IT項目應(yīng)提供何種功能。比如以提升銷售額為業(yè)務(wù)需求的某項目，則用戶需求，可能是增加或者改善目前的網(wǎng)上訂購系統(tǒng)。從用戶需求進而產(chǎn)生具體的功能需求。比如網(wǎng)上訂購系統(tǒng)，則要

53、求網(wǎng)上銀行、網(wǎng) 上產(chǎn)品展示、網(wǎng)上訂單追蹤、客戶訂單查詢、意見反饋等功能需求。從功能需求反推，可得出系統(tǒng)需求，比如，要滿足上面的功能，以及其它的比如安全性、響應(yīng)的及時性，則要求使用何種硬件以及軟件體系的系統(tǒng)需求。最后有一些其它的需求， 比如可靠性要求，屬于質(zhì)量屬性；而總投資則產(chǎn)生了一個 約束條件；現(xiàn)有系統(tǒng)以及現(xiàn)存用戶的條件，則產(chǎn)生了其它非功能需求。49.產(chǎn)生不合格需求的原因a）無足夠的用戶參與或用戶參與深度不夠。產(chǎn)生原因可能是：i. 與用戶的合作或者交流是很多技術(shù)人員的短處或者不屑一顧的事情；ii. 開發(fā)人員錯誤的認為已經(jīng)完全明白用戶的需求b）用戶需求的持續(xù)不斷增加c） 模棱兩可的需求，以及對未

54、來本來的目標也不清楚；d）不必要的特性或者很少用的特性，反而成了開發(fā)者考慮的主要因素e）過于精簡而不明確的規(guī)格說明書；f） 忽略了用戶的分類或者不正確的分類，導(dǎo)致對某一類用戶關(guān)注過多，而對另一類用戶疏于關(guān)注而忽視了他們的需求。g）不正確的計劃，未留足夠時間進行需求分析50 .優(yōu)秀的需求的特性a）完整性：應(yīng)該表達的都有；b）正確性：每一條都是用戶真正想要的東西而不是開發(fā)者自己設(shè)想的；c）可行性：每一條都是當前各種約束條件下能夠?qū)崿F(xiàn)的；d）必要性：是用戶當前最必要的需求的表達；e）劃分有優(yōu)先級：按用戶的需求劃分了層次，哪些是必要的，哪些是可選的；并對每一項都單獨列出了預(yù)算和完成時間表；f） 明確的無二義的：g）可驗證性：當最后項目實現(xiàn)后，可以按照需求說明書來進行驗證是否實現(xiàn)