問題描述:
急用，多謝
解析:
中小型軟件開發項目管理
本處指的中小型軟件開發項目是指：
參與開發的直接人員（即開發團隊）數量在3~25人
開發時間在3個月~18個月的軟件項目
代碼行數5000~75000行
子程序數量300~3500個
1、軟件開發管理的任務
軟件開發管理的真正任務是團隊成員的智能充分而適宜地發揮，並有效地投註在創造軟件的活動中。也就是說：合理配置各種資源（管理人員、工程師、設備、軟件、制度、時間）確保軟件開發的有效進行。最起碼需要避免個體智商120，所開發的軟件象智商60的人開發的軟件——確保創造性智能活動保持創造性張力並取得創造性成果。
2、項目管理的根本焦點
項目管理的根本焦點集中在T、Q、C、S上，即：開發進度、特性與品質、成本、顧客服務。其中最核心的是開發進度、特性與品質兩個方面。其它壹切管理工作都必須圍繞這些焦點進行。
3、中小項目軟件開發的組織設計
有效的組織設計是進行項目開發的前提。大部分軟件開發項目都是中小軟件項目，或者說都可以應用本處所說的項目管理原則，中小項目軟件開發的組織設計主要是設計參與項目開發的各種角色及其權利、責任和這些角色之間的關系。
參與中小軟件開發項目人員，按角色可以分為五種：
⑴項目經理
項目經理也有時被稱為產品經理、品牌經理、項目負責人、項目總監。 項目經理的職責是：
領導團隊定義出壹個成功的產品
引導團隊對產品註入深切的期望和信念
帶領團隊將理想實現，變成可預見的產品誕生
原則1：在項目經理可以對團隊有任何價值之前不應該有任何直接的控制權——要權威不要霸權，充分授權是項目成功的必要條件。
項目經理是軟件開發的核心任務：他具備技術背景，擁有建構軟件的技術領導能力，他有擅長溝通和傾聽，是維系團隊靈魂的關鍵人物。
項目經理的具體工作是：負責制定開發日程、配置資源、與外界溝通。項目經理必須擔負著保證團隊士氣、營造***同美好前景的責任，也必須在困難出現時通過堅強的信心和必要的資源調整來確保士氣和進度。
⑵系統分析員
進行技術規劃和開發設計。
⑶程序開發員
寫程序、抓錯蟲。
⑷品保人員
測試、評估軟件品質
原則2：品保人員與開發人員比例不低於1：2
⑸文檔編制與使用者培訓
撰寫文檔，以便用文字的形式正確表達軟件的功能和使用
原則3：軟件文檔的編寫量要適中，壹般要作到詳細，但是文檔量上不要超過這個標準：1行程序代碼的文檔數量不要超過1頁。
原則3：軟件=團隊，所以溝通和互動是成功的基礎
圖壹：角色與溝通
詳細劃分應該包括：
項目主管
產品主管
構架者：負責在設計和實作層次整合軟件概念
使用者接口設計者
使用者聯絡人
開發人員
品管/測試人員
開發工具制作者
版本建立管理者
風險管理者
使用者文件編修專門人員
討論：註重開發程序與士氣的關系
4、軟件開發的金三角
軟件開發的核心是：特色（產品與其品質）、資源（人和錢）和時間。
圖二：軟件開發的金三角
原則4：金三角警惕
加派人手？小心但不禁止！
追加預算？可以但是別掉進無低洞！
增加特色？謹慎但不禁止！
推遲時間？可以但是千萬小心！
5、裏程碑與檢查點
裏程碑（基線、基點）則是壹個軟件配置項在生存周期內的某壹特定時刻正式設計並固定的靜正式批準的版本，不管媒體如何，它是階段性目標（可以認為是壹個中間產品）。配置項是壹個配置中的實體它滿足壹項最終使用功能，並能在給定的參考點上單獨標識。裏程碑應該是團隊階段性工作完成的標誌，對於任何壹個裏程碑都應該給於認真的檢查、審定和批準。 壹般裏程碑應該少於兩個月，多於三個星期，裏程碑給團隊帶來成就感，提高士氣。通常必須含有的裏程碑為：
裏程碑1：調研 審定對象：調研報告
裏程碑2：需求分析 審定對象：需求規格說明書、結構設計報告
裏程碑3：數據分析 審定對象：數據字典
裏程碑4：概要設計 審定對象：概要設計報告
裏程碑5：詳細設計 審定對象：詳細設計報告
裏程碑6：編碼 審定對象：各配置項編碼、測試報告、產品文檔
裏程碑7：發布 審定對象：用戶使用報告、產品文檔、總結報告
原則5：對於每個錯誤列出的需求，將在下遊開發中付出高達50~200倍的修正代價
原則5：裏程碑必須設置並且設置時間不應是團隊感到太長也不應感到太短，它必須有進行正式審定的衡量標準（零缺點裏程碑）。
原則6：除非任何壹個人都到達了裏程碑否則就沒有達到，即：團隊中最後到達的決定著團隊的效率。
在裏程碑中間應該設置大量的檢查點，這些檢查點應該有可以審查的不管是何種媒體的資料。檢查點應該細分到壹旦檢查點出現問題不至於無法在時間上挽回，壹般來說壹周壹個檢查點是不長的。任何人都應該有檢查點。 原則7：特殊的軟件程序設計師可以作出壹些無法想象的創舉，掀起壹波技術的飛躍，但是他絕不會出現在矢誌如期推出產品的開發團隊中。如果這種沒有檢查點的人，他是最可以破壞產品的開發者。
6、成功的項目管理者與成功實施項目管理的項目
作壹個成功的項目管理者：
不恥下問
給組員設定短期目標
建立長期計劃
<建立評核制度
成功實施項目管理的項目組應該是：
進度剛好可以完成，適度緊張而可以完成
團隊和組員士氣高漲
成員富有思考、樂於溝通
7、有效率的工作會議
如果以下超過3個的回答是是的話，那麽工作會議的質量就需要主管去考慮了，長期下去必將損害士氣、決策質量。
是否有人沒有發言？
是否出現了20%的人發言超過了80%的情況？
是否有這種情況：本次議定的題目，而在會中說下次再說吧？
是否發言需要主管點名？
會議沒有引導者？ l 發言是對人而不是對事？
主管是威脅多於鼓勵？
是否有人有話但沒有說？
8、需方委托得項目開發中的若幹實際原則：
原則8：顧客的需求是工作的核心，任何所謂天才的設想必須征得顧客贊同。
原則9：持續得改善比壹次性改善更能提高顧客得滿意度，更好得是對開發方好處更大，但是牢記顧客關心的需求絕不可推遲。
原則10：能夠成熟的技術莫要用不成熟的技術，叫的最響的不壹定是最好的，不成熟的技術不要流給顧客，留在實驗室或作BETA版吧
軟件開發中的幾個常見問題分析
如果妳在軟件開發中遇到了下列問題，那麽以下的建議也許對妳有幫助。
團隊成員為什麽不善於思考？表現為不發表自己的簡介、不與他人進行建設 *** 流
軟件管理在溝通體制上出現了問題，這些問題可能是以下問題的壹個或多個：
成員認為沒有人重視自己的想法
沒有好處，也許給主管的想法不壹致，主管是不能接受自己建議和批評的
成員認為應該主管告訴他壹切
管理者從來都是只管發號命令
解決辦法：
A.每壹個成員的建議都是重要的
B.與主管不同的意見更值得重視和討論
l) 主管告訴成員做什麽，不要問怎麽做——除非成員向妳詢問，那麽做下來壹起討論
2）為什麽軟件的進度老是落後或者功能上老是不能令人滿意？
也許妳會向軟件開發者或系統設計者找原因——基本上妳可能是失望的。實際上妳第壹個要看的品保人員：人數夠不夠？確實參與設計了？
朋友，妳堅持看完了壹篇好文章，希望妳對每壹件都能有耐心。