it項目匯報范文第1篇
若干年前，我們憧憬IT業，因為IT業神圣的，很多硅谷的故事給我們很多啟迪，IT業不僅可以創造無數富豪，而且其中很多都是年輕的學生，那時候IT就是一個神話„„若干年后，我們進入IT業，發現原來IT沒有那么神秘。確實IT創造了很多神話，Yahoo!,Microsoft等是早期IT的神話，現在Google來了，中國的Baidu也上市了，造就了很多百萬富翁。中國納斯達克上市公司很多了，最早的是網易、新浪、搜狐，然后是前程無憂、攜程網、空中網、TOM、e龍、掌上靈通、金融界、分眾傳媒、德信無線、中芯國際、亞信科技、九城軟件、CDC(china doc com)，現在的baidu。中國目前有18個納市上市公司，明年還有更多。這樣看的話現在的IT業前途是很光明，或許IT業在走向成熟。但是成熟的背后寓意著什么，一個不成熟的行業往往能造就很多天才，一旦這個行業走向成熟，那天才不好容易誕生了，想白手起家什么的，也困難。說到這里都沒有圍繞題目在轉，因為我想先把文章的背景說明下，然后再說明下自己一不是研究這個領域的專家，也不是搞互聯網的老手，自己只是一個個人站長，或者說還是一名本科大學生，在這里寫這篇文章，唯一一點就是自己還算在互聯網里學習了幾年，有了一點對IT業，互聯網行業自己的一點看法，于是就寫下來，大家可以看下，不知道有沒有可取之處。
現在搞IT真的很難了，如果你是學生的話，我不是在唬你。你以前可能聽說一個加拿大的小學生，9歲左右的時候，就靠互聯網掙了不少的財富，2000年他還隨加拿大總理訪華了，這個小孩子能不能成為比爾·蓋次第二我們這里不討論。這么小的孩子可以成為富翁，只有IT才能成就，但是現在在中國，你說可能嗎?反正暫時我沒有聽說過，以前有一個黑龍江漠河的神童，現在也不說了，結果怎么樣我也不知道。剛才說到搞IT難是因為現在IT需要的起點高了，我就拿互聯網一個方面說明，2000年以前的時候，做1-2張靜態網頁就可以掙2-3萬，會個動態網頁那是非常牛的。加拿大的那個小孩子就是靠做網頁掙錢的，阿里巴巴的馬云最初積累資金我覺得也是做網頁掙的，但是現在有了做網頁的工具了，不用一行一行寫代碼了。而且會做網頁的中國人太多了，會ASP、PHP、CGI、JPS、ASP.NET的都大有人在，中國現在有個人網站的人都數不勝數?，F在做網站門檻很低，但是很少能成功的。門檻低，但是需要的起點高。本身現在大學生自主創業追者眾成者寡，大學生創業很不容易。但是事在認為，相對而言，我感覺大學生如果要創業的話，選擇IT業的一些東西，起點是高了，對技術要求是很高，但是只要把握好方向后，堅持不懈還是能成功的。新東方的周承剛，很多喜歡新東方的同學都應該知道，他說了一句話我至今難忘，他說為什么俞敏洪成功了，前提是俞敏洪是當時他們班成績最差的，而現在原來他們班成績最好的幾個都給他打工，因為在這十年中俞敏洪一直在做同一件事情;百度成功了因為李彥宏一直堅持在做同一件事情，ChinaRen創始人陳一舟再次創業創辦“空中網”，然后也成功了。成功學的秘訣就是堅持。所以我覺得大學生IT創業，即使丁磊這樣的前輩都不贊成大學生創業，我還是覺得很有好處的。
先舉幾個例子，我自己身邊的朋友，他們有的現在已經畢業了，有的現在還是學生，但是起步都是從大學開始的，做的事業都是互聯網方面。雖然不是非常成功，但是還是值得我們廣大大學生IT創業借鑒的。個人網站站長開始建站的時候肯定喜歡在源碼下載站上轉悠，都知道中國站長站，我的朋友不是該站站長，但是也是源碼下載站，一個是源易網的站長(杭商院)，一個是下吧的站長，現在網絡開始火了，這些代碼下載站也火了，流量也不小，網站收入也不少，肯定能養活站長。FlashKu的站長：碧落洞仙和納米，陜西的兩個學生，網站排名不錯，收入也可以。還有商務零八的岳貴，西南交大的，據說他發了，掙錢不少，廈門的站長大會他也去了，也算在圈子還是有一點的知名度的。還有華中科大學生創辦的5Q地帶，很多大學生朋友都知道。還有2000年清華大學的三位博士、三位碩士創辦的蔚藍書店。這些都算是值得我們學習的前輩。大學生IT創業是行得通的，但是還是應該注意下問題，下面我就談談個人的看法：
一、找準目標
it項目匯報范文第2篇
摘 要：近年來信息技術迅猛發展，IT團隊開發迭代時效性要求越來越高，技術迭代速度也在提高，作為IT開發團隊的雛形學生開發團隊的壓力也隨之增加。在這一背景下，學生團隊急需一個團隊協作軟件或工具來輔助學生項目的開展，為此設計出了WorkLog團隊協作平臺。該平臺為用戶提供個人、團隊項目管理和團隊考核等功能，是一款側重于學生設計和研發的管理工具，同時也是為廣大用戶提供了一個輕巧便捷、高效性能的團隊協作平臺。
關鍵詞：團隊協作;時間管理;項目考核
0 引 言
隨著信息技術的飛速發展，軟件開發團隊規模的擴大，團隊協作能力已經成為各高?？己巳瞬诺闹匾笜酥?，擁有良好的團隊精神是一個IT開發團隊必不可缺的一部分。與此同時，面對日益增長的在校大學生數量，學生們的時間管理和團隊管理也沒有得到較好的指引，學生的學習和工作壓力越來越大。由此看來，一個團隊協作平臺對學生而言尤為重要。
國內對協作平臺進行研究以來，市場上的團隊協作平臺不少，產品種類越來越豐富。由上海匯翼信息科技有限公司開發的Teambition，實現了項目知識的分享、溝通、項目任務的安排及進度監督，但是產品沒有審批和考勤功能，企業專業版略顯昂貴。以任務管理為中心的協作辦公平臺——Worktile實現了任務和消息模塊的連通，提升了團隊協作效率，但是其他日常辦公的模塊比較欠缺，需要配合其他軟件一起使用。沈澤[1]設計了基于CSCW的虛擬團隊協作平臺，由于時間限制，基于CSCW的工作流管理系統對安全機制考慮得不是很周全。余鵬[2]研究了基于Wiki的企業資源共享與團隊協作平臺搭建應用，而Wiki平臺局限于小范圍公司，非行政強制性，對團隊成員管理松散。哈爾濱工業大學孫志朋[3]設計與實現了面向軟件項目管理的團隊協作平臺，改進了當前很多軟件缺乏的最基礎的溝通交流功能。華南理工大學甘東[4]發表了基于多域管理模式的團隊協作學習平臺設計與實現的相關文獻，此系統基于課程教學，學習者以個人或班級的方式進行學習，無法基于項目或主題教學以團隊成員的方式進行學習。
顯然，團隊協作工具已經進入專業的互聯網4.0時代，團隊協作軟件功能和作用隨技術的演變，呈集大成趨勢，通過協作工具進行團隊管理將成為一種主流模式。WorkLog團隊協作平臺汲取同類平臺的優點，開發了一個風格簡樸、易于操作、功能較全的平臺，最終實現網站和微信小程序的多端口供用戶使用。本系統已經在廣西財經學院信息與統計學院參與科研項目和大創項目的學生團隊中得到推廣使用，通過近一年的使用表明該系統不僅適用于個人還適用于團隊，可進行廣泛推廣，可走進校園和企業，便利學習、生活與工作。
1 系統總體結構
WorkLog是為團體用戶量身打造的一款團隊協作、時間管理和項目考核工具，系統整體架構如圖1所示。
整個系統可以劃分為5個層次，分別為：前端UI、業務層、框架層、基礎服務和運行環境。平臺前端采用ZUI+ jQuery等技術框架相互配合使用，大大減輕了Web前端開發難度及工作量。其中主要提供手機移動端和PC端的訪問。業務層是其中的重要組成部分，業務層的各項功能不僅便于用戶每日溝通團隊工作，還有利于管理員評閱團隊工作日志以及進行上下級各項進展的溝通。在業務層中，用戶可以梳理每日待辦事項，清晰列出一日工作，合理安排工作節奏，隨時記錄和更新工作進展，確認工作完成情況。系統每日發送任務提醒，使用戶養成良好的工作習慣，其中以多圖表形式展示的工作日志，讓學習工作時間比例清晰明了?？蚣軐诱故境鯳orkLog平臺后臺使用的技術框架，主要采用Spring+MyBatis等技術框架?；A服務層提供文件存儲和郵件服務等基礎服務，其中數據庫使用MySQL。平臺運行環境使用常見的云服務器。此外WorkLog微信小程序設置了工作日志、OKR、今日待辦、統計回顧、個人中心和我的消息6個模塊，為用戶提供填寫日志、待辦提醒、OKR管理、統計回顧、消息提醒等功能。
2 系統功能模塊
WorkLog團隊協作平臺擁有PC端和移動端兩個子模塊。
2.1 PC端子模塊
PC端子模塊的注冊方式除了郵箱注冊方式外，還支持第三方賬戶的注冊，比如微信登錄、QQ登錄和微博登錄。為了保證平臺信息安全，用戶只有注冊并登錄后才可以使用平臺的功能。用戶注冊并登錄PC網站，即可使用網站記錄工作日志、回顧工作歷程、進行項目管理和團隊管理。功能模塊主要分為兩大模塊，即用戶模塊和管理員模塊。在用戶模塊中，用戶在注冊并登錄該平臺后，可在“我的日志”頁面記錄自己的工作動態和學習內容;在“統計回顧”頁面中，可以清晰地看到近期記錄的工作內容;在“項目管理”頁面中，可以看到自己參與項目的狀態和內容。相比用戶模塊，管理員模塊具有更高級的管理功能。除注冊登錄、用戶管理、項目管理、統計分析等功能之外，管理員還可登錄后臺系統進入“用戶管理”頁面了解用戶動態并進行管理;在“項目管理”頁面管理已創建的項目，并查看項目進度;在“統計分析”頁面查看團隊成員的工作記錄，并以Excel形式導出記錄。管理員設置的任務提醒團隊成員可以隨時隨地收到。在這種多功能的管理模塊下，管理員可以及時獲取每個團隊成員的反饋信息，直觀地了解他們的工作進度和工作狀態，及時糾正工作中的偏差。
本校項目管理頁面如圖2所示。
2.2 移動端子模塊
WorkLog微信小程序為用戶提供工作日志、OKR、今日待辦、統計回顧、消息管理、個人中心等功能，系統功能設計圖如圖3所示。
用戶進入微信APP，搜索WorkLog小程序，便可進入小程序和應用小程序相應功能?！肮ぷ魅罩尽蹦K的功能齊全，具有基本的填寫、修改和刪除功能?！癘KR”模塊旨在共享OKR，如圖4所示，有助于整個團隊明確目標，達成可衡量的關鍵結果，幫助協調和集中精力。
小程序將“統計回顧”模塊細化，可將工作記錄詳細分為周記錄、月記錄和年記錄，并將工作時間分布運用扇形統計圖直觀地展示在用戶面前，便于用戶觀察時間比例。在“今日待辦”模塊中，用戶可根據自身需求進行設定，該設定具有人性化，設定的時間提醒準確到秒。系統根據待辦提醒時間發送提醒消息，減少工作被遺忘的事件發生，提高了團隊的工作效率。在“消息管理”模塊中，系統每天提醒用戶記錄工作情況，編寫工作日志，使用戶養成良好的工作習慣，在項目過程中或項目結束時，方便用戶查詢自己的工作記錄，做好工作總結?！跋⒐芾怼蹦K支持消息的跟蹤和回饋，是解決團隊溝通的一個重要渠道，用戶還可以在此模塊查看積分和積分排行。在“個人中心”模塊中，用戶可以查看和修改個人資料。
3 結 論
WorkLog團隊協作平臺遵循“簡單、活潑、極致”的原則，對網站、微信小程序進行合理的板塊規劃，采用豐富有趣的配色對頁面進行設計，增加用戶對本軟件的粘性。巧妙采用PC端和移動端形式，輕巧便捷，很好地提高運行速度，增大用戶體驗。平臺適用于各種大小型團隊，能處理較多事務，解決了團隊中時間不合理安排，工作效率低、工作完成質量差等常見問題，尤其解決了大多數人接手多項目時，出現的計劃安排亂、項目延期多、反饋不及時、經驗難復制等普遍情況。WorkLog是針對這些問題研發的一個團隊協作平臺，方便個人和團隊的管理，集中寶貴資源解決項目問題，消除或減少重復的工作，按時間、按程度、按內容分類自己的工作，按時按質量地完成，讓其養成良好的時間規劃習慣，為生活工作提供便利。成員在團隊項目中可以及時接收到自己的任務，合理安排工作計劃。管理者只需要給每位成員分配OKR，系統會自動計算項目的完成率，輕松管理項目的進度，提高工作效率。WorkLog團隊協作平臺是以服務個人和團隊為宗旨，我們希望通過這樣一個平臺能為團隊提供更好的管理環境，提高其工作和學習效率。
參考文獻：
[1] 沈澤.基于CSCW的虛擬團隊協作平臺的分析與設計 [D].湖北：湖北工業大學，2010.
[2] 余鵬.基于Wiki的企業資源共享與團隊協作平臺搭建應用研究 [J].信息技術與信息化，2014（5）：39-41.
[3] 孫志朋.面向軟件項目管理的團隊協作平臺的設計與實現 [D].哈爾濱：哈爾濱工業大學，2017.
[4] 甘東.基于多域管理模式的團隊協作學習平臺設計與實現 [D].廣州：華南理工大學，2019.
作者簡介：方熾帶（1998.12—），女，漢族，廣西欽州人，本科，研究方向：數據挖掘;梁為磊（1997.01—），男，漢族，廣西欽州人，本科，研究方向：數據挖掘;鐘鋌偉（2000.02—），男，漢族，廣西玉林人，本科，研究方向：數據挖掘;廖云翔（1998.05—），男，漢族，廣西玉林人，本科，研究方向：數據挖掘;通訊作者：高榮（1979.02—），男，漢族，山東濰坊人，講師，教師，研究生，研究方向：數據挖掘。
it項目匯報范文第3篇
第一章
P32 習題與思考
一、請談一談你對項目與項目管理的價值的認識，舉例說明項目和項目管理的價值所在。 答：
我們把利用有限資源，在一定的時間內，完成滿足一系列特定目標的多項相關工作叫做項目。項目的價值是指項目具有明示和潛在的功能，能滿足利益相關方明示和潛在的需要。項目是實現價值、成就事業的載體，所有重大事件、所有的宏偉工程、所有的卓越發明、所有的時代精英，都是通過一個個項目造就的。而且，項目作為國民經濟。組織運作和個人發展的基本元素，對國家、組織和個人的發展都將起到至關重要的作用。例如，一個組織或者是公事，是靠一個至多個項目的啟動，當這些項目完成后，組織進入日常工作狀態來維持基本地運行，隨著環境的變化和組織的發展，組織通過新的項目來推進和壯大自身的規模。 所謂項目管理，就是把各種知識、技能、手段和技術應用于項目活動之中，以達到項目的要求。項目管理是通過應用和綜合諸如啟動、規劃、實施、監控和收尾等項目管理過程來進行的。項目管理的價值就在于，通過項目管理，企業在財務能力、客戶滿意度、項目成功率和學習能力以及增長指數方面都將獲得極大的改進。項目管理另一個非常重要的價值就是知識的積累。例如，每個項目的成功實施除了產生新的產品和相應的服務外，還會給我們留下非常珍貴的經驗和教訓。
七、在PMBOK的九個知識領域中，有哪幾個是核心知識領域，為什么稱它們為核心知識領域?
答：
在PMBOK的9個知識領域中，有四個核心知識領域，這四個核心知識領域分別是范圍管理、時間管理、費用管理和質量管理，之所以稱其為核心知識領域是因為在這幾個方面將形成具體的項目目標。
十三、一個軟件系統通常包括哪幾部分?它們的作用是什么?
答：
一個軟件系統通常包括在計算機運行中能夠提供所希望的功能和性能的程序;使程序能夠正確運行的數據結構和數據;描述系統結構的系統文檔和如何使用與維護該系統的用戶文檔。其中，程序是按照事先設計的功能和性能要求執行的指令序列，是軟件的窗口，它展示著系統的能力;數據是是程序能正常、正確操縱信息的設計結構，是軟件的根本，它決定了系統的價值;文檔是與程序的開發、維護和使用有關的圖文資料，是軟件的靈魂，它關系到系統的命運。
十八、查閱一些網站，讀一遍寫得不錯的IT項目管理文章，用1~2頁篇幅概括文章的內容(要求附文章及來源)
在文章中提到很多IT項目管理過程中要注意的細節問題。本文中系統的細節的幾大類，如：用人不當、流程問題、計劃問題和溝通問題。并且在這幾個類中又有細分常見的項目實施管理的失誤對項目的影響和建議。
一、在用人不當中，列舉了缺乏適當的人員與技能和缺乏富有經驗的項目經理兩個細節。
二、在流程問題中，列舉了沒有遵循標準的項目管理流程、流程太多太雜、對項目變更缺乏追蹤、對項目動態缺乏了解項目經理圈子和對小問題掉以輕心，這個幾個細節，并給出建議。
三、在計劃問題中，列舉了沒有定義項目范圍、風險評估過于隨意、對用戶抵觸心理認識不足、和時間進度表欠完善等細節，詳細的給出了作者的建議。
四、在溝通問題中，列舉了對不合理的項目期限不作反駁影響和與項目支持者、參與者缺少溝通兩細節，針對這兩個細節給出相應的建議。
IT部門在項目管理上的失誤大多是由計劃不當或溝通不暢所引起的。這些錯誤嚴重降低了項目的成功幾率，公司在眾多項目的實施管理中或多或少存在著問題，在文中羅列出幾類常見的項目實施管理失誤，幫助我們在以后的實踐操作中加以比照、測量與改善。
文章標題：IT項目管理中要注重細節問題
IT部門在項目管理上的失誤大多是由計劃不當或溝通不暢所引起的。這些錯誤嚴重降低了項目的成功幾率，公司在眾多項目的實施管理中或多或少存在著問題，在下文中將羅列出幾類常見的項目實施管理失誤，幫助你加以比照、測量與改善。
一、用人不當
1.缺乏適當的人員與技能
影響：用人不當與資源分配失調是項目管理失誤中最常見的一種現象。一個項目能否圓滿完成，人員與技能的配備占了主導因素。用人不當的結果往往會導致項目無法繼續執行，這樣就算計劃再好，也是紙上談兵。
建議：IT與項目經理應全面了解及掌控技能與資源情況，包括對項目顧問、合約承包商和外包商的詳細評估。使用項目管理軟件可以幫助項目經理充分掌握所有團隊成員的技能與工作量分配。在了解分工與職責后，IT與項目經理就可以決定如何在日常工作和項目中合理分配資源。指派專門的資源經理來負責解決人員與資源的分配問題也是一個不錯的主意。
如果你在項目人員分配上依然有困難，或許可以考慮先查看整個公司的項目組合，然后暫緩那些與商業戰略關系不大，或非任務關鍵的項目，從而釋放部分可用資源。
2.缺乏富有經驗的項目經理
影響：如果沒有一名經驗豐富的項目經理掌舵，項目很可能會隨著發展而失去控制。建議：聘用一名符合項目要求，并擁有出色人際關系處理技巧的項目經理。他應當有號召力，能夠管理風險，并在團隊成員和外部參與者之間起到協調作用。此外，一名優秀的項目經理也應該具備相關技術的知識與技能。
二、流程問題
1.沒有遵循標準的項目管理流程
影響：這是項目管理中的第二大常見失誤。缺乏合理的流程會抬高項目風險，加大項目失敗的可能性，最終導致無法在限定的時間與預算內完成項目。
建議：制定良好的項目管理流程能助你提高項目效率，并及時捕捉到項目執行過程中的各種問題，控制風險。
IT與項目經理應事先建立可重復的流程來進行項目規劃、資源分配與成員溝通。這樣才能保障項目所能產生的回報與成效。
2.流程太多太雜
影響：過多的流程會讓項目失去靈活性，繼而影響參與者的積極性。
曾經有一家軟件開發商告訴客戶公司的項目經理，他們能夠在不增加成本與工作量的基礎上添加額外的功能，但項目經理卻回絕了這一建議，因為他覺得公司用戶并沒有要求這一功能。其實，只要不影響項目預算與計劃進度，又征得用戶的同意，多添加一些功能是利大于弊的。
建議：提高靈活性，與項目支持者及參與者積極溝通。
3.對項目變更缺乏追蹤轉自項目
影響：要么預算超支，要么進度拖慢(或兩者兼有)。
建議：建立正式的變更申請流程，任何項目范圍內的變更(比如添加新功能)都應在變更文件上詳細注明，并由項目最高主管簽字批準。此外，項目經理也需判別出該申請對預算和時間進度會產生什么影響。
4.對項目動態缺乏了解項目經理圈子
影響：管理學大師彼得德魯克曾說過，無法管理就無法測量。反應到項目上，即無法及時協調資源，或對變更做出應變。
建議：使用軟件。
5.對小問題掉以輕心
影響：問題不會自己解決。如果對小問題掉以輕心，那么它們就會演化成大問題，最終成倍增加項目成本。
建議：加強項目團隊成員的態度與意識，及早糾錯。等到亡羊補牢，為時已晚。
三、計劃問題
1.沒有定義項目范圍
影響：如果商業與IT部門沒有事先定義項目范圍，那項目終將無法滿足預期的成效，IT也會缺乏方向來如期完成項目。建議：通過商業用例和范圍劃定來糾正錯誤定義的項目。
2.忽略項目之間的關聯項目
影響：忽略項目之間的關聯會造成資源分配失調(比如配給某項目的人員也是另一項目所需要的)，從而影響項目進度，作為連鎖反應，其它項目也會受到拖累。
建議：在制定項目計劃時將關聯因素考慮在內。與項目參與者多交流，并繪制項目關聯表，可協助你明確了解各項目之間的關系。
3.風險評估過于隨意
影響：項目脫離原有軌道，IT需清理預料外的麻煩。
建議：風險評估應是項目計劃的一部分?？梢栽趫F隊中進行頭腦風暴，收集可能的風險因素，然后設法規避這些風險。這一活動不會花費太久的時間，而且他也能幫助你在正式開始前充分了解項目的軟肋所在。
4.對用戶抵觸心理認識不足
影響：用戶對新技術的抵觸會讓項目所投入的資金與精力白費。
建議：在項目計劃階段先考慮到推行過程中的阻礙，并設法化解這些阻力。與那些工作將受新項目影響的用戶交流溝通，向他們闡述項目會給他們的工作流程帶來的有利變化與價值。
5.時間進度表欠完善
影響：團隊成員對何時完成何種任務沒有概念，對整體項目的按時達成形成阻滯。
建議：最簡單的方法是判別出項目中所有的活動，并在這些活動后面標注預計完成日期。使用項目管理軟件亦可創建進度計劃表。
四、溝通問題
1.對不合理的項目期限不作反駁影響：使自己陷入無法如期完成項目的窘境，并有損IT部門的信譽。
或許公司所設定的項目期限過于苛刻，而IT部門強行完成只會起到反作用。
建議：IT經理應向公司管理層解釋無法預期完成的實際困難，以及強行完成所需付出的代價(比如成本大幅上升，資源預算超支等)，讓管理人員在成本和速度之間做出選擇。
2.與項目支持者、參與者缺少溝通
影響：IT無法達成預期的要求。
建議：在傳遞關鍵書面文件與表格的同時加以當面說明，并用對方能夠理解的方式簡明地闡述要點(有些商業人員不會理解長篇大論的技術術語)。
在這種溝通互動中，其實公司的商業分析師在用戶與IT之間扮演了一個非常重要的協調角色。
建議：對參與項目，或受項目影響的所有商業成員提供一份項目綜述(從計劃到部署)，并標示出那些活動要求商業人員參加互動，以及互動的目的?？傊?，IT應多花一些時間來指導商業部門了解項目執行的步驟。
文章來源：
(http:///articles/show_article_content.asp?articleID=22466)
第二章
四、項目生命周期分為哪幾個階段?每個階段的主要任務有哪些?
答：
項目生命周期分為四個階段，分別是分為定義階段、開發階段、實施階段和收尾階段。 定義階段主要任務是明確要求、策劃項目、調查分析、收集數據及信息、確立目標、進行可行性研究、明確合作關系、確定風險等級、擬定戰略方案、進行資源測算、提出組建項目組方案、提出項目建議書和獲準進入下一個階段。
開發階段主要任務是確定項目組主要成員、界定最終產品范圍、研究實施方案、確定項目整體計劃、預算項目費用與現金流量、形成工作分解結構、制訂項目政策與程序、評估項目風險、確認項目有效性、編制項目概要報告和獲準進入下一階段。
實施階段主要任務是建立項目組、建立與完善項目溝通渠道、實施項目激勵機制、建立項目工作包，細化相關技術需要、建立項目信息控制與管理系統、執行工作分解結構的各項工作、獲得訂購物資和服務、指導/監督/預測/控制項目范圍、進度、費用、質量和管理項目的變更，解決實施中的問題。
收尾階段的主要任務是提交最終產品、評估與驗收、清算與審計賬務、評估項目、項目技術與管理文檔的歸檔、資源清理、轉移產品責任者和項目組的解散與人員再分配。
六、建立組織的目的是什么?組織的設計原則有哪些?
答：
德魯克認為組織的目的，就是要使平凡的人做出不平凡的事。其實質是對管理人員的管理勞動進行橫向和縱向的分工。
組織的設計原則包括如下7個原則：(1)目標的一致性原則(2)合理的管理幅度和管理層次原則(3)命令統一原則(4)責任與權利對等原則(5)合理分工與密切協作原則(6)集權與分權相結合的原則(7)環境適應性原則
十、簡述5個過程組中每個過程組的主要任務，以及每個過程組的主要成果。
答：
在大多數情況下，大多數項目都有共同的項目管理過程，這一過程包括啟動、規劃、執行、監督、結束5個過程組。
啟動過程組的主要任務是確認并核準項目或項目階段。在項目開始階段啟動過程的主要成果就是形成一個項目章程和選擇一位項目經理。
規劃過程組的主要任務是確定和細化目標，并規劃為實現項目目標和項目范圍的行動方針與路線，確保實現項目目標。規劃過程的主要成果包括完成工作任務分解結構，項目進度計劃和項目預算。
執行過程組的主要任務是通過采用必要的行動，協調人力資源和其他資源，整體地、有效地實施項目計劃。執行過程的主要成果就是交付實際的項目工作。
監控過程組的主要任務是定期測量和實時監控項目進展情況，發展偏離項目管理計劃之
處，及時采取糾正措施和變更控制，確保項目目標的實現。監控過程的主要成果是在要求的時間、成本和質量的限制范圍內獲得滿意的結果。
it項目匯報范文第4篇
1、 項目經理為整個項目的第一責任人。
2、 項目經理對《質量檢查報告》中的所有細則負首要責任。
3、 項目經理必須有效掌控項目開發的各個環節，協助、指導項目組成員的工作，及時發現并處理項目中存在的問題，并對項目組成員的工作進行合理的評價。
4、 負責管理和控制項目全過程的質量、進度。分析偏差，采取糾正措施。如果發現項目實際進展顯著偏離計劃，則及時采取糾正措施。
5、 根據項目規范建立項目組內部管理和溝通機制。
6、 可根據需要調配組內人員等資源。
7、 有權對項目組成員提出獎懲建議。
8、 項目經理負責組織需求分析工作，并組織對需求文檔和需求變更文檔進行復審。
9、 分配系統設計任務，包括體系結構設計、模塊設計、用戶界面設計、數據庫設計等。
10、組織對體系結構設計、模塊設計、用戶界面設計、數據庫設計進行評審。
11、負責組織項目開發小組會議并編寫會議紀要。開發小組會議每周至少舉行一次(可與項目例會合并)，對難點、疑點問題進行分析、解決，保證小組內成員充分溝通。
12、負責每周對開發人員的代碼進行檢查。
13、負責提交測試版本、搭建符合實際的集成測試環境，每個項目只能有一個測試環境，開發環境不可與測試環境混合。
14、所需提交文檔：
? 立項后制定《項目計劃》并保證該計劃的合理性和現實性。組織項目組內對《項目計劃》進行評審，《項目計劃》制定或變更后必須發郵件通知部門經理、測試部及項目相關人員。
? 每周五下班前提交項目的《項目周報》至TFS上項目相關目錄。
? 協助設計人員編寫《體系結構設計報告》、《模塊設計報告》、《用戶界面設計報告》、《數據庫設計報告》
? 提交《內部驗收表》。項目成果交付用戶前項目經理必須組織內部驗收，并簽字生效。
? 結項前向項目管理部門提交《結項申請書》。
? 負責組織開發設計人員、需求分析人員、測試人員，根據《用戶需求說明書》提交各類技術文檔，并保證該文檔的及時有效性和準確性。
二、 項目管理FAQ
1、 項目計劃如何編寫?
項目計劃按文檔模板的提示完成各項內容，統一使用PROJECT工具制定并跟蹤。
2、 項目計劃編寫好后怎么提交?
項目計劃編寫完畢后，需將初稿提交給項目管理部門進行初審，并由其組織項目管理部門成員及項目組成員進行開會評審。
3、 怎樣進行項目計劃變更?
在項目過程中，需根據實際情況對《項目計劃》進行變更，須提交項目管理部門進行評估，如對項目有重大影響，項目經理須填寫《項目計劃變更申請表》并提交項目管理部門進行審核。
4、 需求分析文檔編寫有哪些要求?
項目的需求分析文檔是開發的依據，在編寫中每項功能的描述必須思路清晰，要求有輸入、輸出項和操作步驟、業務流程等信息，并能對功能畫出示意圖、流程圖等。需求分析文檔編寫完成后需將初稿提交項目管理部門進行初審，再由其組織項目組成員并邀請相關人員進行會議評審。
5、 整個項目實施過程中，各類角色周期性需要提交什么文檔?
項目經理：每周五舉行項目例會，并提交《項目周報》的“項目進度”部分。 開發人員：每周五提交《項目周報》的“實際完成任務”和“問題匯總”。 測 試 員：每周五提交《項目周報》的“質量保證報告”。
6、 項目經理的主要任務是什么?
在立項申請評審會議中指定項目經理后，項目經理需提供項目組開發人員的建議名單，包括體系結構設計員、界面設計員、數據庫設計員及模塊設計員。
制定完《項目計劃》后，項目經理應按《項目計劃》要求制定《開發計劃》。 項目經理負責對各系統設計員所提交的設計文檔進行初審。
項目經理應經常對開發人員的模塊設計或源碼進行抽查，確保軟件開發質量，并符合設計要求，并在每周五提交的《項目周報》中的“源碼檢查情況”記錄相關信息。
7、 如何使用Bug管理系統?
項目立項后，測試部將會在Bug管理系統創建該項目，并設置項目組成員及各成員的角色。
項目組內任何人發現項目缺陷都應該登錄Bug管理系統中進行記錄，若非項目組成員發現錯誤應及時反映給測試人員。
提交缺陷時，根據缺陷的嚴重性選擇類別，并選擇“嚴重級別”能讓開發人員及時獲取信息進行修改。標題應該簡要說明缺陷內容，以便進行相關查詢和統計，不能以“錯誤”、“測試結果”等無意義的詞作為標題。
8、 怎樣進行驗收、升級、安裝?
所有項目在提交客戶前，必須通過測試部和項目經理組織的內部驗收，并填寫《內部驗收表》。
內部驗收通過后，項目經理制定《客戶驗收計劃》并組織客戶及項目相關人員進行驗收，編寫《客戶驗收報告》。
項目組/開發人員負責提供需要驗收的軟件和建立驗收環境。并編寫安裝、升級腳本。 安裝、升級前應先在測試服務器上搭建與正式服務器相同的環境，執行安裝、升級腳本，確保腳本執行無誤，然后再驗證程序的正確性。
測試服務器上安裝、升級無誤后，項目經理指定開發人員進行正式系統的安裝、升級，安裝、升級人員填寫《升級(安裝)記錄表》。
9、 如何結項?
所有交付給用戶使用的系統，必須在交付驗收的同時，提交經項目經理和質保員審核的操作手冊、軟件系統管理手冊、系統安裝、配置和維護手冊等驗收所需文檔。 所有驗收文檔提交齊全后，由項目經理撰寫《結項申請書》，申請結項?！督Y項申請書》應附上經項目經理審核的項目竣工文檔清單，并對項目進行全程回顧，總結項目中的經驗教訓，對項目組成員的工作質量、責任心和效率等進行評估。
項目管理部門對《結項申請書》進行評審，決定是否同意結項，并提交《結項評審報告》。
10、操作手冊等驗收文檔由誰來寫?
驗收所需文檔均由項目經理指定項目組內成員完成，項目經理和測試員負責審核。
11、結項后又有新需求或需求變更怎么辦?
根據需要重新考慮立新項目。
12、對于細小需求頻繁變更，時間要求又緊張的需求變更如何應變?
對于較小的需求變更，經過需求分析人員和開發人員的溝通，記錄在需求文檔的歷史記錄中，并由項目經理簽字確認;重大需求的變更，則必須按照需求變更流程進行控制，提交《需求變更申請書》，并進行項目組內的需求評審。如果質保員在測試時才發現需求有重大變更但未形成文檔且未經評審，則嚴肅處理。
三、 項目風險控制
1、 合同風險
簽訂的合同不科學、不嚴謹，項目邊界和各方面責任界定不清等是影響項目成敗的重大因素之一。
預防這種風險的辦法是項目建設之初項目經理就需要全面準確地了解合同各條款的內容、盡早和合同各方就模糊或不明確的條款簽訂補充協議。
2、 需求變更風險
需求變更是軟件項目經常發生的事情。一個看似很有“錢途”的軟件項目，往往由于無限度的需求變更而讓項目承建方苦不堪言，甚至最終虧損(實際上項目建設方也面臨巨大的風險)。
預防這種風險的辦法是項目建設之初就和用戶書面約定好需求變更控制流程、記錄并歸檔用戶的需求變更申請。
3、 溝通不良風險
項目組與項目各干系方溝通不良是影響項目順利進展的一個非常重要的因素。 預防這種風險的辦法是項目建設之初就和項目各干系方約定好溝通的渠道和方式、項目建設過程中多和項目各干系方交流和溝通、注意培養和鍛煉自身的溝通技巧。
4、 缺乏領導支持風險
上層領導的支持是項目獲得資源(包括人力資源、財力資源和物料資源等)的有效保障，也是項目遇到困難時項目組最強有力的“后臺支撐”。
預防這種風險的辦法是主動爭取領導對項目的重視、確保和領導的溝通渠道暢通、經常向領導匯報工作進展。
5、 進度風險
有些項目對進度要求非?？量?進度要求不高的項目，我們同樣要考慮該風險)，項目進度的延遲意味著違約或市場機會的錯失。
預防這種風險的辦法一般是分階段交付產品、增加項目監控的頻度和力度、多運用可行的辦法保證工作質量避免返工。
6、 質量風險 有些項目，用戶對軟件質量有很高的要求，如果項目組成員同類型項目的開發經驗不足，則需要密切關注項目的質量風險。
預防這種風險的辦法一般是經常和用戶交流工作成果、品牌管理采用符合要求的開發流程、認真組織對產出物的檢查和評審、計劃和組織嚴格的獨立測試等。
7、 系統性能風險
有些軟件項目屬于多用戶并發的應用系統，系統對性能要求很高，這時項目組就需要關注項目的性能風險。
預防這種風險的辦法一般是在進行項目開發之前先設計和搭建出系統的基礎架構并進行性能測試，確保架構符合性能指標后再進行后續工作。
8、 工具風險
軟件項目開發和實施過程，所必須用到的管理工具、開發工具、測試工具等是否能及時到位、到位的工具版本是否符合項目要求等，是項目組需要考慮的風險因素。 預防這種風險的辦法一般是在項目的啟動階段就落實好各項工具的來源或可能的替代工具，在這些工具需要使用之前(一般需要提前一個月左右)跟蹤并落實工具的到位事宜。
9、 技術風險
在軟件項目開發和建設的過程中，戰略管理技術因素是一個非常重要的因素。項目組一定要本著項目的實際要求，選用合適、成熟的技術，千萬不要無視項目的實際情況而選用一些雖然先進但并非項目所必須且自己又不熟悉的技術。如果項目所要求的技術項目成員不具備或掌握不夠，則需要重點關注該風險因素。
預防這種風險的辦法是選用項目所必須的技術、在技術應用之前，針對相關人員開展好技術培訓工作。
10、團隊成員能力和素質風險
團隊成員的能力(包括業務能力和技術能力)和素質，對項目的進展、項目的質量具有很大的影響，項目經理在項目的建設過程需要實時關注該因素。
預防這種風險的辦法是在用人之前先選對人、開展有針對性的培訓、將合適的人安排到合適的崗位上。
11、團隊成員協作風險
團隊成員是否能齊心協力為項目的共同目標服務，生產管理是影響進度和質量的關鍵因素。 預防這種風險的辦法是項目在建設之初項目經理就需要將項目目標、工作任務等和項目成員溝通清楚，采用公平、公正、公開的績效考評制度，倡導團結互助的工作風尚等。
12、人員流動風險
項目成員特別是核心成員的流動給項目造成的影響是非?？膳碌娜肆Y源。人員的流動輕則影響項目進度，重則導致項目無法繼續甚至被迫夭折。
預防這種風險的辦法是盡可能將項目的核心工作分派給多人(而不要集中在個別人身上)、加強同類型人才的培養和儲備。
13、工作環境風險
工作環境(包括辦公環境和人文環境)的好壞直接影響項目成員的工作情緒和工作效率。 預防這種風險的辦法是在項目建設之前就選擇和建設好適合項目特點財務管理和滿足項目成員期望的辦公環境、在項目的建設過程中不斷培育和調整出和諧的人文環境。
14、系統運行環境風險
目前，大部分項目系統集成和軟件開發是分開進行的(甚至由不同公司承接)。因此，軟件系統賴以運行的硬件環境和網絡環境的建設進度對軟件系統是否能順利實施具有相當大的影響。
預防這種風險的辦法是和用戶簽定相關的協議、跟進系統集成部分的實施進度、及時提醒用戶等。
15、分包商風險
有些項目管理可能會涉及到將系統的部分功能分包出去，這時項目組就需要關注項目的分包商風險。
it項目匯報范文第5篇
A公司是一家經營紙產品的企業，近幾年業務得到了成倍的發展，原來采用手工處理業務的方式已經越來越顯得力不從心，因此，經過公司董事會研究決定，在公司推行一套管理軟件，用管理軟件替代原有的手工作業的方式，同時，請公司副總經理負責此項目的啟動。
副總經理在接到任務后，即開始了項目的啟動工作。項目經過前期的一些工作后，副總經理任命小丁為該項目的項目經理，小丁組建了項目團隊，并根據項目前期的情況，開始進行項目的計劃，表1一1所示為初步項目進度計劃表。
項目進行了一半，由于公司業務發展的需要，公司副總經理要求小丁提前完工，作為項目經理，小丁對項目進行了調整，保證了項自的提前完工。
【問題1】(7分)
請用400字以內的文字描述你作為項目前期的負責人，在接到任務后將如何啟動項目?
【問題2】(9分)
作為項目經理，你項目的進度控制中的重點是什么?請描述你在項目進度控制中的甘特圖，以及雙代號網絡圖，并比較甘特圖與網絡圖的區別。
【問題3】(9分) 假設公司總經理要求提前完工，作為項目經理將如何處理，請用400字以內的文字描述你應該如何處理?
【問題1】 (7分)
本題中，項目前期的負責人實際是公司副總經理，在項目章程中確定項目經理的人選。作為項目前期的負責人，在接到項目的任務后將開始項目的啟動工作。項目的啟動包括了以下幾個主要活動：
(1)識別項目的需求。
(2)解決方案的確定。
(3)對項目進行可行性分析。
(4)項目立項。
(5)項目章程的確定。
【問題2】(9分)
項目時間管理中的重點是把握好關鍵路徑上的任務，項目甘特圖繪制如圖1-1所示。
項目雙代號網絡圖繪制如圖1一2所示。
甘特圖與網絡圖的區別：
甘特圖直觀、簡單、容易制作，便于理解，一般適用比較簡單的小型項目，可用于WBS的任何層次、進度控制、資源優化、編制資源和費用計劃。但是不能系統地表達一個項目所包含的各項工作之間的復雜關系，難以進行定量的計算和分析，以及計劃的優化等。
采用網絡圖進行進度控制，能夠清晰地展現現在和將來完成的工程內容、各工作單元間的關系，并且可以預先確定各任務的時差。了解關鍵作業或某一環節的進度的變化對后續工程和總工期的影響度，.便于及時地采取措施或對進度進行調整。
【問題3】(9分)
項目的質量、進度、成本相關聯，因此，在進度控制和成本管理上考慮：
(1)在進度管理上，可以采用加班等方式進行。
(2)投入更多的人力、物力。
(3)把握關鍵路徑上的任務。
在實際處理的過程中，因為新投入人力到項目，而且新的人力對項目的熟悉程度不一，新員工需要經過一段時間的培訓才能適應項目，所以，最佳的方式應該是采用加班方式來提前完成項目，
1 同時，項目經理應該調整進度計劃，在關鍵路徑上加班，縮短關鍵路徑的長度。 第3章項目時間管理案例
項目管理的首要任務是制定一個構思良好的項目計劃，以確定項目的范圍、進度和費用。在給定的時間完成項目是項目的重要約束性目標，能否按進度交付是衡量項目是否成功的重要標志。因此，進度控制是項目控制的首要內容，是項目的靈魂。同時，由于項目管理是一個帶有創造性的過程，項目不確定性很大，項目的進度控制是項目管理中的最大難點。 3.1案例一：時間管理
閱讀以下關于信息系統項目管理過程中時間管理問題的敘述，回答問題1至問題4。 3.1.1案例場景
小張為希賽信息技術有限公司(CSAI) IT主管，最近接到公司總裁的命令，負責開發一個電子商務平臺。小張粗略地估算該項目在正常速度下需花費的時間和成本。由于公司業務發展需要，公司總裁急于啟動電子商務平臺項目，因此，要求小張準備一份關于盡快啟動電子商務平臺項目的時間和成本的估算報告。
在第一次項目團隊會議上，項目團隊確定出了與項目相關的任務如下：
第一項任務是比較現有電子商務平臺，按照正常速度估算完成這項任務需要花10天，成本為15000元。但是，如果使用允許的最多加班工作量，則可在7天、18750元的條件下完成。
一旦完成比較任務，就需要向最高層管理層提交項目計劃和項目定義文件，以便獲得批準。項目團隊估算完成這項任務按正常速度為5天，成本3750元，如果趕工為3天，成本為4500元。
當項目團隊獲得高層批準后，各項工作就可以開始了。項目團隊估計需求分析為15天，成本45000元，如加班則為10天，成本58500元。
設計完成后，有3項任務必須同時進行：①開發電子商務平臺數據庫; ②開發和編寫實際網頁代碼;③開發和編寫電子商務平臺表格碼。估計數據庫的開發在不加班的時候為10天和9000元，加班時可以在7天和11250元的情況下完成。同樣，項目團隊估算在不加班的情況下，開發和編寫網頁代碼需要10天和17500元，加班則可以減少兩天，成本為19500元。開發表格工作分包給別的公司，需要7天、成本8400元。開發表格的公司并沒有提供趕工多收費的方案。
最后，一旦數據庫開發出來，網頁和表格編碼完畢，整個電子商務平臺就需要進行測試、修改，項目團隊估算需要3天，成本4500元。如果加班的話，則可以減少一天，成本為6750元。
【問題1】(6分)
如果不加班，完成此項目的成本是多少?完成這一項目要花多長時間?
【問題2】(6分)
項目可以完成的最短時間量是多少?在最短時間內完成項目的成本是多少?
【問題3】(6分)
假定比較其他電子商務平臺的任務執行需要13天而不是原來估算的10天。小張將采取什么行動保持項目按常規速度進行?
【問題4】(7分)
假定總裁想在35天內啟動項目，小張將采取什么行動來達到這一期限?在35天完成項目將花費多少?
【問題1】
對于該問題，需要進行關鍵路徑的計算，關鍵路徑法(CPM)的工作原理是：為每個最小任務單位計算工期、定義最早開始和結束日期、最遲開始和結束日期、按照活動的關系形成順序的網絡邏輯圖，找出必需的最長的路徑，即為關鍵路徑。
一般可以通過兩個原則來確認關鍵路徑：
(1)總持續時間最長的線路稱為關鍵線路。
(2)總時差最小的工作組成的線路為關鍵線路。
由此判斷，關鍵路徑為：①②③④⑥⑧⑨。
累加關鍵路徑上的時間即為完成這一項目所要花費的時間。
【問題2】
顯然在趕工情況下項目完成時間最短，因此，累加關鍵路徑上趕工的時間即可得出項目完成最短工作量，累加趕工成本即可得出在最短時間內完成項目的成本是多少。
容易產生的失誤地方就是在關鍵路徑的選擇上，被題干中所描述的“最短時間量”所迷惑，在④-⑤開發電子商務平臺數據庫、④-⑥開發和編寫實際網頁代碼、④-⑦開發和編寫電子商務平臺表格碼這三項任務上選擇④-⑤或④-⑥，導致時間量和項目成本計算全部出錯。
【問題3]
假定比較其他電子商務平臺的任務執行需要13天而不是原來估算的10天。那么，由于①-②比較其他電子商務平臺位于關鍵路徑上，因此，將導致整個工期延長3天，為此，小張必須考慮趕工來保證項目按進度完成。趕工原則是“采用優先考慮趕工費用率最低的工作”。根據表3-3推導出表3-4.
根據表3-4的信息，為保證項目完成，要求在關鍵路徑上趕工3天，趕工費用率最低的是②-③，但②-③進行趕工2天后，還差1天。此時，可以在關鍵路徑④-⑥上趕工1天，使得④-⑥的完成時間變為9天，但此時④-⑥的趕工導致④-⑤也必須趕工1天。由此，計算出趕工的費用。本題容易產生錯誤的地方為：只考慮了④-⑥趕工的費率，而沒有考慮④-⑤相應的變化。
【問題4】
與問題3類似，同樣，必須采用趕工的方式，也必須考慮關鍵路徑上活動的變化導致了其他非關鍵路徑的變化的情況。由于，原有關鍵路徑上的工期為10+5+15+10+3=43，現要求35天完成，因此，必須趕工8天時間。
首先，我們列出并行的3個任務④-⑤、④-⑥.、④-⑦的趕工費用率，如表3-5所示。
④-⑦是不可調整的，④一⑥趕工時間為8，因此，最多可趕工2天，如表3-6所示。
趕工的優先順序如表3-7所示。
因此，趕工費用為103150+750+3750+3500+2250=113400. 3.1.3參考答案
【問題1】(6分)
本題的關鍵是確定關鍵路徑，完成這一項目要花43天。如果不加班，完成此項目的成本是103150元。
【問題2】(6分)
項目可以完成的最短時間量是30天，在最短時間內完成項目的成本是127 650元。
【問題3】(6分)
在關鍵路徑②一③“向最高管理層提交項目計劃和項目定義文件”進行趕工2天后，在關鍵路
3 徑④-⑥“開發和編寫實際網頁代碼”上趕工1天，同時，在④-⑤“開發電子商務平臺數據庫”也必須趕工1天。
【問題4】(7分)
總共需要趕工8天，在②-③“向最高管理層提交項目計劃和項目定義文件”上趕工2天，在①-②“比較現有電子商務平臺”上趕工3天，在④-⑤“開發
電子商務平臺數據庫”，④-⑥“開發和編寫實際網頁代碼”上趕工2天，在⑧-⑨“測試，修改”上趕工1天。
在35天內完成項目將花費為113400元。 第4章項目成本管理案例 4.1 案例一：成本估算
閱讀以下關于信息系統項目管理過程中成本估算方面問題的敘述，回答問題1至問題3。 4.1.1案例場景
希賽信息技術有限公司(CSAI主要致力于為國內教育提供信息化服務，成立業內一流的研發中心，不斷研究和推出深受用戶歡迎的軟件產品，客戶遍布中國每個省/市/自治區。公司創立8年來，通過不斷加強和改進技術管理來完善產品和提升服務品質，已成為中國教育軟件研發領域首家通過CMM3評估項目的公司。
張工是CSAI的項目經理，1個月前剛接手某高校學生管理系統研發項目。完成項目需求調研后，張工開始制定詳細的進度和成本計劃。表4-1和表4-2
分別是張工用兩種方法做的項目成本估算，估算貨幣單位為(元)。
【問題1】(8分)
請用200字以內說明信息系統項目管理過程進行成本估算的基本方法。
【問題2】(8分)
表4-1和表4一2分別采用了什么估算方法，表中估算成本A, B各為多少?
【問題3】(9分)
請結合你本人的實際項目經驗，用300字以內文字分析信息系統項目成本估算過程中的主要困難和應該避免的常見錯誤。 4.1.2案例分析
【問題2】
表4-1采用了自下而上的成本估算方法，表4-2采用了參數法成本估算方法。
項目經理的成本是30元/小時，項目經理張工參與項目的時間是500小時，而分析人員的成本參數是20元/小時，2個分析人員，每人參與項目時間是500小時，編程人員的成本參數是13元/小時，2個編程人員，每人參與項目時間是500小時，由于參數模型是簡單的線性模型，所以，很方便計算出人力成本是61000元;其間接成本包括一般管理費和額外費用，一般管理費是人力成本的35%，額外費用是人力成本和管理成本的25%;這樣合計為98820元;還有設備費用及其間接費用13000元，項目成本總計111820元，詳見表4-3.
對于表4-1，估計分解之后每個任務的規模，然后總計項目的總規模成本。
采用自下而上的估算方法，用的模型是：
估算總值=估算值+風險基金+稅 其中
估算值=直接估算值+間接估算值
間接估算值=直接估算值× 15%
風險基金=估算值× 20%
稅=估算值×5%
要求估算的誤差應該保持在-5%～+5%
按照這個算法并根據表4-3的WBS的分析結果圖示，估算過程如下：
直接成本=202000元
間接成本=202 000 × 0.15=3030元
估算值=202 000+3 030=23230元
總成本=23 230+23 230 × 20%+23 230 × 5 %=29037.5元
經過計算，兩表中A為202000元，B為111820元。
【問題3】
4.1.3參考答案
【問題1】(8分)
信息系統項目進行成木估算的基術方法包括：
(1)自頂向下估算法或類比估算法。
(2)自下而上估算法。
(3)參數估算法。
(4)專家估算法。
(5)猜測估算法等。
【問題2】(8分)
表4-1采用了自下而上的成本估算方法，表4-2采用了參數法成本估算方法。經過計算，兩表中估算值A為202000元，B為111820元。
【問題3】(9分)
綜合起來，信息系統的項目成本估算的困難主要包括以下方面：
(1)需求信息的復雜性。
(2)開發技術與工具的不斷變化。
(3)缺乏類似的項目估算數據可供參考。
(4)缺乏專業和富有經驗的人才。
(5)信息系統研發人員技術能力的差異。
(6)管理層的壓力與誤解。
在對項目進行成本估算時，應該避免以下的常見錯誤：
(1)草率的成本估算。
(2)在項目范圍尚未確定時就進行成本估算。
(3)過于樂觀或者保守的估算。 4.2 案例二：成本估算
閱讀以下關于信息系統項目管理過程中成本估算問題的敘述，回答問題1至問題4。 4.2.1案例場景
希賽信息技術有限公司(CSAI )憑借豐富的行業經驗和精湛的技術優勢，堅持沿著產品技術專業化道路，為銀行、證券、保險等領域提
5 供完整全面的解決方案。李工是CSAI證券事業部的高級項目經理，目前正負責國內B銀行信貸業務系統的開發項目。作為項目經理，李工必須制定高質量的項目管理計劃，以有效實現范圍、進度、成本和質量等項目管理目標。
項目正式立項后，李工制定了一份初步的項目成本計劃。李工估計出了每項工作的工期及所需要的工作量，如表4-4所示。此外，表4-4也給出了每項工作除人力資源費用外的其他固定費用(如硬件設備和網絡設備等)。
【問題1】(6分)
請計算表4-4中每項工作所需安排的人力資源數量(按每天8小時工作制計算)。
【問題2】(6分)
假設每種人力資源的小時成本如下：測試員30元/小時，程序員40元/小時，軟件設計師60元/小時，系統分析師100元/小時。請計算每項工作所需的總費用(每周按照5個工作日計算)。
【問題3】(6分)
計算每項工作每周的平均費用(每周按照5個工作日計算)。
【問題4】(7分)
假設該項目計劃的甘特圖如圖4-1所示，請繪制該項目的費用預算曲線圖(時間單位為周，每周按照5個工作日計算)。 4.4.2案例分析
在費用預算方面，如按時間坐標來分析，有兩種表現方式：一是費用預算曲線圖，二是費用預算累計曲線圖。圖4-3和圖4-4為Project 2000繪制的費用預算曲線圖和費用預算累計成本曲線圖。
人力資源數=工作量÷8÷工期，如方案設計階段系統分析師人數=160÷8÷10=2,其他階段計算類似;
總費用=固定費+工作量×成本，如詳細設計階段總費用=6 400+160×60=16000, 其他階段總費用計算類似。各階段總費用累加得到項目總費用為493000. 平均每周費用=總費用÷(工期÷5),如主界面設計階段平均每周費用=73000÷(50÷5)=7300。 4.2.3參考答案
【問題1】(6分) 【問題2】(6分)【問題3】(6分) 參考答案見表4-5。 【問題4】(7分) 根據圖4-1和表4-5計算每周費用總和，如圖4-5所示。 4.3 案例三：掙值管理
閱讀以下關于信息系統項目管理過程中掙值管理和項目成本管理方面問題的敘述，回答問題1-問題4。 4.3.1案例場景
財政基本建設管理信息系統是一套能夠為財政服務，提供財政基本建設資金管理，財務監督、審核，為財政的基建科、預算科和國庫科等相關部門提供數據互享的工程項目管理的應用系統。系統充分地體現財政部門對基本建設項目的管理，對國家預算安排的基本建設資金的使用的管理，反映財政部門對基本建設項目的管理，更好地實現財政的管理監督的職能作用。
張工是大型電子政務系統集成商希賽信息技術有限公司(CSAI )的項目經理，目前正作為項目經理負責CSAI與某地財政局開發的基本建設管理信息系統項目，項目組成員包括項目經理1人、系統分析師1人、高級程序員3人、程序員3人、軟件界面美工1人、測試人員2人、客戶方技術人員2人。由于財政等因素，項目的計劃工期為40周，預算成本為50萬元。根據該項目的需求和進度等要求，項目具有工期緊、技術要求高、業務復雜等特點。為順利實現項目進度和質量等目標，CSAI項目管理部門和高層領導對該項目格外重視，要求項目組每周匯報進度狀態。
在項目的實施過程中，第19周時張工向公司經理報告項目的進展狀態，在狀態報告中經理列出了第18周(包含第18周)的項目狀態數據，詳細情況如下：
(1)截至項目狀態日期，項目實際已完成的工作量為50%.
(2)截至項目狀態日期，項目已完成工作量的實際成本(AC)為28萬元。
(3)截至項目狀態日期，項目的計劃成本(PV)為26萬元。
【問題1】(6分)
試確定項目截止到項目狀態日期已完成工作量的掙值EV 。
【問題2】(6分)
預測項目結束時的總成本EAC 。
【問題3】(6分)
請對該項目在費用控制方面的執行狀況進行分析。
【問題4】(7分)
項目經理在檢查經費超支時發現，有一項任務F還沒有開始實施，但為F任務購買設備的支票已經支付，其費用為4萬元。另外，還有一張已經支付的支票，其費用為3萬元，是作為整個H任務的硬件費用，但H任務在狀態日期完成的工作量為40%.根據這一信息再預測項目結束時的總成本。 4.3.2案例分析
掙值管理(Earned Value Management)，是一種綜合了范圍、進度計劃、資源和項目績效度量的方法，它通過對計劃完成的工作、實際掙得的收益、實際花費的成本進行比較，以確定成本與進度是否按計劃進行，提供分析、決策依據，從而選取不同的應對措施，以保證最終完成項目目標。
根據圖4-6在測量時間點上，有必要先了解14個重要的概念，如表4-6所示。
(1)應完成多大工作量?
計劃成本PV(Planned Value)，也稱為計劃工作的預算成本(BCWS)。
在圖4-6中，PV=1000元。
(2)“已完成”工作的成本是多少?
實際成本AC(Actual Cost)，也稱為已完成工作的實際成本(ACWP)。
在圖4-6中，AC=1100元。
(3)已完成多大工作量?
掙值EV(Earned Value)，也稱為已完成工作的預算成本(BCWP)。
對EV的解釋：有一項任務預定在測量時間點上完工，其計劃成本為1000元。但只完成這項任務的95%0這樣，就完成了950元的工作量，這就是掙值(EV)。
(4)成本偏差CV(Cost Variance)：
CV=EV-AC
CV是項目任務的掙值與實際成本之間的差異，已完成了950元的工作量(EV)，但為完成這一工作實際花費了1100元(AC)。完成這項工作比原先預想的多花了150元(CV)。
(5)進度偏差SV(Schedule Variance)
SV=EV-PV
SV是項目或項目任務的掙值與預算值之間的差異。對于一項工作，原先預計到測量時間點為止會完成1 000元的工作量(PV)。而實際上完成了950元的工作量(EV)。這樣，就比原計劃少完成了50元的工作量(SV)。
(6)成本績效指數CPI(Cost Performance Index)：
CPI=EV÷AC
CPI是總掙值除以總成本。仍以圖4一6為例，已完成了950元的工作量(EV)，而為完成這項工作花了1100元(AC)。實際花一元完成了0.864元的工作量(成 本與績效之比)。
(7)進度績效指數SPI(Schedule Performance Index)：
SPI=EV÷PV
SPI是總掙值除以總預算成本。在圖4一6中，已完成了950元的工作量(EV,)，而計劃工作的價值是1000元(PV)。這樣，計劃完成一元工作量，實際完成了0.95元的工作量(進度績效之比)。
(8)全部工作假定價值，即完工預算BAC (Budget At Completion)或稱“總預算”。
BAC=完成時的預算一項目預計總成本的基線
在圖4-6中，BAC=2000元。
(9)尚未完工部分的估算ETC(Estimate To Completion)價值，即從開始到完成項目將還需要花費多少成本。ETC=EAC-AC
在圖4一6中，ETC為：ETC=2315-1100=1215(元)
(l0)完工估算EAC (Estimate At Completion),反映了根據項目的進展總成本是多少，如表4-6所示。
最常用的兩個公式是EAC=BAC÷CPI和EAC=AC+ETC 。在計算過程中，優先使用第一個公式，如果有明確的理由說明第一個公式不可用，則采用第二個公式。在圖4-6中，EAC=2000÷0.864=2315(元)
(11)完工偏差VAC(Variance At Completion)，即全部工作預算價值(BAC)與全部工作概算價值(EAC)之差。
VAC=BAC-EAC
正值是項目組追求的目標，表明成本比預計情況要好。
在圖4-6中，有： VAC=2000-2315=-315(元)
(12)績效指數TCPI(To Complete Performance Index)：
TCPI=(BAC-EV) ÷(BAC-AC)
在圖4-6中，有：TCPI=(2000-950) ÷(2000-1100)=1.7
從這一點出發，必須取得效益，即每花費一元要完成1.17元的價值，以便用預計剩下的資金完成余下的工作。
(13)任務完成百分比PC(Percent Complete)，即已完成的工作占總工作量的比例。
PC=EV ÷BAC
在圖4-6中，有：PC=950 ÷2000=47.5%
(14)成本消耗百分比PS (Percent Spent)是指已經消耗的成本占項目總預算的比例。在圖4-6中，有： PS=1100÷2000=55%
所有的價值，無論是計劃的還是實際的，都用貨幣值表示偏差。這會使大家認為掙值與貨幣有關，但它反映的是項目績效(Project Performance).因此，掙值是溝通管理的一個重要工具，也是項目績效度量的一個非常有幫助的工具。
進度偏差和成本偏差對項目的影響如表4-7所示。 4.3.3參考答案
【問題1】(6分)
截至項目狀態日期已經完成工作量的預算成本，即掙值EV：EV=50×50%=25萬元。
【問題2】(6分)
項目結束時的總成本：EAC=28÷50%=56萬元。
【問題3】(6分)
由于AC>PV>EV,說明項目實際費用支出超前，與實際完成工作量相比費用超支，項目實際完成工作量與計劃工作量相比出現拖期。
【問題4】(7分) 重新預計的項目完工總成本：EAC=(28-4-3×(1-40%))÷50%=44.4萬元。 第5章項目質量管理案例
8 5.1案例一：計劃及跟蹤
閱讀以下關于信息系統項目管理過程中質量管理方面問題的敘述，回答問題1至問題3。 5.1.1案例場景
某銀行信息系統工程項目，包含省級廣域網工程、儲蓄所終端安裝工程、主機系統工程、存儲系統工程、備份系統工程、銀行業務軟件開發工程等若干子項目。此工程項目通過公開招標方式確定承建單位，希賽信息技術有限公司(CSAI)經過激烈競標爭奪，贏得工程合同。合同約定，工程項目的開發周期預算為36周。
由于銀行對于應用軟件質量要求很高，CSAI也非常重視工程質量，安排有資深資歷的高級工程師張工全面負責項目實施。在工程正式開工之前，張工對工程項目進行了分解，根據工程分析，張工認為此工程項目質量、進度的關鍵在于銀行業務定制應用軟件的開發。除工程整體的開發計劃外，張工還針對應用軟件開發制定了詳細的開發計劃，定制應用軟件的開發周期為36周。網絡工程、終端安裝工程、主機系統工程、存儲系統工程、備份系統工程等與應用軟件開發并行實施。
張工對工程項目在需求分析、概要設計、詳細設計、編碼、單元測試、集成測試等各個環節要求均非常嚴格。根據張工安排，需求分析、概要設計均安排有多年工作經驗的高級軟件工程師擔任，各個階段的階段成果均組織了嚴格的評審，以保證各個階段成果的質量。
在軟件編碼及單元測試工作完成之后，張工安排軟件測試組的工程師編制了詳細軟件測試計劃、測試用例，包括集成測試、功能測試、性能測試、安全性測試，等等。
張工在安排軟件測試任務的時候，在動員軟件開發小組時宣講：“軟件測試環節是軟件系統質量形成的主要環節，各開發小組，特別是測試小組，應重視軟件系統測試工作”。因此，張工安排給測試組進行測試的時間非常充足，測試周期占整個軟件系統開發周期的40%,約14.5周。在軟件系統測試的過程中，張工安排了詳細的測試跟蹤計劃，統計每周所發現軟件系統故障數量，以及所解決的軟件故障。根據每周測試的結果分析，軟件系統故障隨時間的推移呈明顯的下降趨勢，第1周發現約100個故障，第2周發現約90個故障，第3周發現50個故障，„„，第10周發現2個故障，第11周發現1個故障，第12周發現I個故障。于是張總工斷言軟件系統可以在完成第14周測試之后順利交付給用戶，并進行項目驗收。
【問題1】 (7分)
請以300字內回答，張工的軟件開發計劃中是否存在問題?為什么?
【問題2】(8分)
請以200字內回答，張工根據對定制軟件系統測試的跟蹤統計分析結論，得出項目可于計劃的測試期限結束后達到驗收交付的要求，你認為可行嗎，為什么?
【問題3】(10分)
請以300字內回答，若你是本項目的總工，你將怎樣改進工作，以提高軟件系統開發的質量，保證工程項目按期驗收? 5.1.3參考答案
【問題1】(7分)
張工安排測試計劃的編制時機不對。測試計劃和測試用例的編制應當與軟件系統的概要設計、詳細設計同步進行。
測試計劃不夠全面，還應當包含系統整體測試、運行測試。運行測試是對應用軟件系統整體功能的全面檢驗，也是最能夠說明軟件系統質量的測試環節。
系統測試計劃、確認測試計劃應當在需求分析階段制定，測試用例、測試說明應當在概要設計階段制定。
集成測試計劃應當在概要設計階段制定，測試用例、測試說明應當在詳細設計階段制定。
單元測試計劃應當在詳細設計階段制定，測試用例、測試說明應當在編碼階段制定。
【問題2】(8分)
在定制軟件開發項目中，根據測試結果判定軟件系統的質量是不夠的，因為軟件系統中的缺陷可能由于多種原因而未在測試中被發現，如測試環境與運行環境的區別、測試人員的能力問題、測試計劃和測試用例的局限及缺陷。
由于軟件系統質量、功能、性能具有很強隱蔽性的特點，用戶往往不大可能根據項目開發小組的測試結論來進行項目的驗收。最好讓用戶組織對項目進行試運行，以試運行的結論來作為驗收的依據之一是比較有說服力的。
【問題3】(10分)
(1)在進行需求分析的時候，同步制定功能確認測試計劃和測試用例，同步制定系統整體測試計劃和測試用例。
(2)在進行軟件系統概要設計的時候，制定集成測試計劃和測試用例。
(3)在進行軟件系統詳細設計的時候，制定單元測試計劃和測試用例。
(4)在項目計劃驗收日期前，提前與用戶協商系統試運行計劃，并給用戶進行充分的培訓，包括領導和一般操作人員，讓系統接受實際運行的考驗，在試運行過程中暴露出來的問題，及時進行解決。以軟件系統實際運行所表現出來的功能、性能來說服用戶對項目進行驗收，這通常是更可行的方法。
第8章項目風險管理案例 8.1案例一：風險分類
閱讀以下關于信息系統項目管理過程中人群風險分類方面問題的敘述，回答問題1至問題3。 8.1.1案例場景
某公司召開會議，商量是否實施ERP項目，三個部門主要負責人就此問題發表自己的看法。
甲：我們公司不應該實施這個項目?，F在我們剛把辦公自動化系統搞好，還沒有適應，工作效率也沒提高多少，再上ERP有些不適應，而且這個ERP項目花費太大。ERP在國內很多企業都搞失敗了，成功的幾率不會多大。如果我們也失敗了，會給公司帶來災難性的后果。利用搞ERP的這些錢我們可以做一些短、平、快的項目，多招一些開發高手，提高公司的收益，而不是搞這些無端的風險投資。
乙：不應該一棒子打死ERP o ERP是一種新興事務，ERP不是萬能的，但是不上ERP又是萬萬不行的。企業規模到了一定程度，管理和決策就是一個重要的問題。ERP是知識經濟時代的管理方案，是面向供應鏈和“流程制”的智能決策支持系統，其先進的管理思想可以幫助企業最大限度地利用已有資源，解決管理和決策問題。但是實施 ERP風險很大，很多企業都失敗了，主要原因在于項目實施的管理問題，沒有及時識別項目中的風險并及時處理，項目監控機制不好，高層支持不夠，老員工的適應性差等，最終導致“ERP天折”。我們公司以后想獲得更大發展，應該實施ERP o現在有些條件不夠，整體上ERP不太可行，我們可以分步實施。我們可以借鑒其他企業實施ERP的經驗，先進行小范圍ERP試驗、積累經驗，等以后時機成熟了，我們就整體實施ERP 。
丙：ERP應該上，而且要迅速上，不應該等。如果其他企業都上了ERP,那么我們公司再依靠ERP獲得收益就沒有什么希望了。ERP本身就是一把雙刃劍，雖然有風險，但是收益也大，現在我們的目標是收益，對于風險要想法化解。項目實施中要注意借鑒其他企業的經驗，摸著石頭過河，形成自己的特色，提高自己公司的管理和決策水平，爭取把公司做大做強。小的、可以自己解決的風險自己處理;難以處理的、不確定的風險進行外包，實施風險轉移;如果管理有問題的話，可以從專業咨詢公司招聘顧問來擔當項目經理的職務?？傊?，盡一切可能實施ERP，實現收益最大化。
【問題1】(8分)
如圖8-1所示，橫軸表示項目投資的大小，縱軸表示項目成功的概率，A、B, C代表三種不同應對風險的人。請寫出A,B,C的名字和特征，并且指出上述案例中甲、乙、丙分別屬于哪一種對象(250字左右)。
【問題2】(8分)
如果公司有以下三種職位，你認為甲、乙、丙分別適合做什么：項目經理、程序員、產品銷售人員(請說清楚原因，不超過150字
【問題1】(8分)
A為風險規避者：屬于保守派。他們自始至終都不愿意接受較大的風險，希望利用少量投資就可以得到較高的成功概率;隨著投資的增加，他們希望成功概率越來越大，最后達到百分之百。
B為風險中立者：屬于中庸派。當投入少時，他們可以接受較大的風險;當投入逐漸增加時，他們就開始變得謹慎起來，希望獲得成功的概率提高了，最后達到百分之百。
C為風險冒險者：屬于冒險派。他們自始至終都愿意接受較大的風險，當投入少時，他們可以接受較大的風險;隨著投入的增加，他們也會變得謹慎一些，希望成功概率有所增加，最后達到百分之百。
上述案例中，甲、乙、丙分別對應A, B, C.
【問題2】(8分)
甲屬于風險規避者，做事小心謹慎，不愿意冒大風險，比較適合做程序員。
乙屬于風險中立者，做事深思熟慮、講究章法，制定計劃切實可行、可進可退，比較適合做項目經理。
丙屬于風險冒險者，做事大膽，敢于冒風險，一切以效益為先，積極追求成功，具有強烈的成功欲望，比較適合做產品銷售人員。 8.4案例四：風險管理方案
閱讀以下關于信息系統項目管理過程中風險管理方面問題的敘述，回答問題1至問題3。 8.4.1案例場景
2000年，國內一家省級電信公司(H公司)打算上某項目，經過發布RFP (需求建議書)，以及談判和評估，最終選定希賽信息技術有限公司(CSAI)為其提供IP電話設備。宏達公司作為CSAI的代理商，成為了該項目的系統集成商。李先生是該項目的項目經理。
該項目的施工周期是三個月。由CSAI負責提供主要設備，宏達公司負責全面的項目管理和系統集成工作，包括提供一些主機的附屬設備和支持設備，并且負責項目的整個運作和管理。CSAI和宏達公司之間的關系是一次性付賬。這就意味著CSAI不承擔任何風險，而宏達公司雖然有很大的利潤，但是也承擔了全部的風險。
3個月后，整套系統安裝完成。但自系統試運行之日起，不斷有問題暴露出來。H公司要求宏達公司負責解決，可其中很多問題涉及CSAI的設備問題。因而，宏達公司要求CSAI予以配合。但由于開發周期的原因，CSAI無法馬上達到新的技術指標并滿足新的功能。于是，項目持續延期。為完成此項目，宏達公司只好不斷將CSAI的最新升級系統(軟件升級)提供給H公司，甚至派人常駐在H公司(外地)。
又經過了3個月，H公司終于通過了最初驗收。在宏達公司同意承擔系統升級工作直到完全滿足RFP的基礎上，H公司支付了10%的驗收款。然而，2002年底，CSAI由于內部原因暫時中斷了在中國的業務，其產品的支持力度大幅下降，結果致使該項目的收尾工作至今無法完成。
【問題1】(8分)
請用200字以內文字描述該項目存在的主要問題和原因。
【問題2】(8分)
請用300字以內文字結合你本人的實際項目經驗，描述如何解決案例中所述問題的辦法。
【問題3】(9分)
請用400字以內文字說明如果你是李經理，·你覺得應如何制定有效的項目風險管理方案?
8.4.3參考答案
【問題1】(8分)
該項目最終失敗的原因主要在于風險控制和風險處理機制。在很多IT項目中，由于競爭和其他原因造成了風險過度集中在某一個相對弱勢的角色身上。在本案例中，宏達公司就處于這樣的境地：一方面它需要依賴代理CSAI的產品生存，另一方面要它還必須要滿足用戶的具體需求。
【問題2】 (8分)
一般情況下，如果項目經理在項目合同簽訂以前加入項目，可以充分利用項目采購管理一章的知識，了解自己公司在項目中的位置，對買方提出的RFP認真回答，規避潛在的風險，這是非常重要的。對于RFP中過高的要求不能完全滿足時，應充分說明。在項目的進行過程中，項目經理和項目的擁有人要將風險管理納入日常工作的重要步驟。要明確成本與風險、成本與時間的關系。制定完善的風險管理計劃，建立管理風險預警機制。
【問題3】(9分)
在全面分析評估風險因素的基礎上，制定有效的管理方案是風險管理工作的成敗之關鍵，它直接決定管理的效率和效果。因此，翔實、全面、有效成為方案的基本要求，其內容應包括：風險管理方案的制定原則和框架、風險管理的措施、風險管理的工作程序等。 10.6案例六：項目估算
閱讀以下關于信息系統項目管理過程中綜合性管理問題的敘述，回答問題1至問題3。 10.6.1案例場景
軟件項目開發通常用LOC (line of Code)衡量項目規模，希賽信息技術有限公司(CSAI) )經過多年
11 的開發，積累了一定的經驗數據，經過分析統計發現公司每一萬行C語言源代碼形成的源文件(.c和.h文件)約為250KB。
現公司承接某一項目，該項目源文件大小為3.75MB,項目累計投入工作量為240人月，每人月費用為10000元(包括人均工資、福利以及辦公費用分攤等)。
現項目經理小丁帶領的項目組承接該項目，經過研究，項目組把該軟件開發項目分為了需求分析、設計編碼、測試和安裝部署等4個活動，各個活動順序進行，沒有時間上的重疊，活動的完成時間估計如表10-4所示。
【問題1】(8分)
請計算該項目中1個LOC的價值以及項目的人月均代碼行數?
【問題2】(8分)
項目在開發中，需要使用一些組件，這些組件估計有10000行代碼，假定30%需要重新設計，50%需要重新編碼，70%需要重新測試，請問項目經理該如何安排人力資源的投入?
【問題3】(9分)
請為項目組計算軟件開發中各項活動的時間和項目周期。 10.6.2案例分析
【問題1】
軟件開發的工作量和工期的估算歷來比較復雜，因為軟件本身的復雜性、歷史經驗的缺乏、估算工具的缺乏，以及一些人為的錯誤，導致軟件項目的規模估算往往和實際情況相差甚遠，因此，估算錯誤被列入軟件項目失敗的4大原因之一。
軟件項目開發通常用LOC (line of Code)衡量項目規模，LOC指所有可執行的源代碼行數，包括可交付的語句、數據定義、數據類型聲明、等價聲明及輸入/輸出格式聲明等。項目經理可以根據對歷史項目的審計來核算組織的單行代碼值。
本題考察項目進度控制中的工作量和工期的估計。
【問題1】(8分)
該項目中1個LOC的價值為：(240 ×10000)÷150000=16元/LOC。
該項目的人月均代碼行數為：150000÷240 = 625 LOC/人月。
【問題2】(8分)
[(30%+50%+70%)÷3]× 10 000=5000等價代碼行
根據該項目的人月均代碼行數為625 LOCI人月，則需投入人力為5000÷625=76.9人月。
【問題3】(9分)
根據公式Ti=(4mi+ai+bi) /6,其中，ai表示第i項活動的樂觀時間，mi表示第i項活動的最可能時間，bi表示第i項活動的悲觀時間。
T需求分析=(7+4×11+15)÷6=11
T設計編碼=(14+4×20+32)÷6=21
T測試=(5+4×7+9)÷6=7
T安裝部署=(5+4×15+13)÷6 =13