軟體開發專案管理的模式概述
傳統的專案管理模式
根據pmi觀點，傳統的專案管理通常具有幾個固定的階段：
第一專案啟動階段，第二計畫階段，專案的規模、專案的需求、專案的估算，第三階段設計規範書(軟體開發的藍圖)，第四專案時間表(schedule)。樣品的試開發。第五執行階段，程式設計開發。同時fix bugs.第六控制階段，對發現的錯誤進行回車重新開發。第七結束階段。
啟動、計畫、執行、控制、結束
這五個階段的傳統的專案管理模式在業界使用的比較普遍。
靈活性模式的概念和實踐
1、輕型的計畫(light weight planning)
信奉改變(embrace change):從整個的專案的開始起就期望計畫、需求、和設計都會改變。
整個開發過程有客戶的經常參與，甚至邀請客戶來到開發團隊的工作處，對正在進行開發的半成品使用、審核、提意見。 客戶直接參加專案的計畫的修改 整個開發計畫是個不斷更新的過程 輕型計畫的象徵：沒有事先的計畫
加州大學俄凡分校在校園的時候，他們只蓋了大樓，鋪了墓地，卻不建築人走路的路邊行人路。第二年，建校的人回來，在草地上由人們走出來的路徑上，修建了讓走路的行人路。perl語言就是這樣一類的語言，它並沒有事先全設定好的規則，perl語言就是那些在墓地上由人們走出來的行人路。 計畫是乙個連續性的過程，而不是乙個一次性的過程。 2、經常性的發行(rrequent releases) 短期的重複開發周期
採取所謂的「時間盒」方法–將預定的週期鎖定為乙個發行週期 保持產品接近發行的狀態 好處是：
第一為團隊提供一種完成任務的快樂和成就感； 第二給使用者提供了在開發早期進行回饋的機會。 3、簡化的設計(****** design)
先對那些已經確定了的功能進行設計 使用yagni(you aren』t going to need it)
意識到任何多餘的功能，一旦加入到軟體產品中，會增加修改和維護的費用。 好處是便於返車重新設計和開發。每次改動都可能會影響其他部分的功能元件。 4、以測試為驅動的開發(testing driven development–tdd) 編寫產品的程式前先寫測試的程式 單元測試(unit test)應該全部自動化
單元測試的執行應該成為開發的日常工作 好處是：
第一保證測試部分能保質保量完成 第二以這種方法寫出的程式質量較高 5、重新組合(refactoring)
重組：在不改變功能和行為的前提下，對軟體的內部結構為更容易理解和更方便修改而進行設計和程式設計上的改動。
採用漸進式的設計方式來逐漸完善程式 好處是：
第一幫助推動漸進式的設計方式，使得軟體的避免一次性做完，卻又帶有費用昂貴的必需的改動
第二常常重組，再加上利用tdd，改動的費用會降低 何時進行重組？ martin fowler:
當你發現你必須在乙個軟體程式裡加乙個新的功能、但現有的程式的結構卻無法讓你奶方便地加入這個新的功能的時候，你應該先重新組合現有的程式，使得經能夠讓你方便地加任何新的功能，然後再加入你想加的新功能。 6、連續性的整合(continuous integration)
將開發團隊多人開發的各功能元件進行整合，最後生成完整的軟體系統或產品，應該是乙個經常進行的、連續不斷的過程。
每天或每幾個小時進行總彙編和產品建造(daily build) 好處：
第一幫助開發團隊及時發現build breaker並採取糾正措施
第二對任何由於設計差錯無法完善地與整個系統進行整合的功能元件能及時進行設計改動
7、及時檔案編輯(just-in-time documentation)
將產品或系統的使用手冊、維護條例、使用參考等等一系列文件根據各功能開發的進展進行編輯
趁著概念新鮮明確，將它們寫入文件 好處是：
第一避免編輯多餘的不必要的文件或不必要的內容
第二，但是也要注意不要將文件工作放到最後，而造成檔案內容缺乏或遺漏。 軟體開發管理模式的簡單介紹和比較 traditional(wate***ll) rup cmm scrum asd crystal
extreme(xp) dsdm
msf(microsoft solution framework) 自scrum後為靈活性模式 scrum
由ken schwaber和jeff sutherland提出和倡導 是一種極為輕型的靈活性模式的翻版 非完整的：沒有整個流程的定義
採用所謂的」sprints」，即一般是乙個月為週期，來進行迴圈式的短期性的開發和發行管理
每天進行15分鐘的團隊「scrum會議」
採用每天進行專案的最新狀態匯報，發表「burn down graph」 適合於整個開發團隊在同乙個大房間裡一塊工作
scrum本意是指橄欖球在開賽前的手拉手聚在一起商議進攻方案，在這裡是指專案管理的模式，指每天在開始工作前要所有團隊成員在一起開會，商討當天的工作和遇到的問題。
adaptive software development(asd) 由jim highsmith提出和倡導
也是一種輕型的靈活性模式，強調在混亂的邊緣上爭取平衡 不要求執行者完全按照流程規則來做
在專案週期裡安排乙個學習階段，具體解決哪些是重要的開發任務
將專案的歷程分成3個階段：思索、合作、學習(speculate,collaborate,and learn) 講究在合作階段進行迴圈式的重複漸進，採取「時間盒」(timeboxed)的方法 crystal
由alistaire cockburn提出和倡導 靈活性模式的一種，尊重不同大小的專案在管理上需要有不同程度的正式性管理規章，強調在完成目前的開發專案的同時，要將眼光放在開發團隊和企業未來的位置
使用幾個不同的管理方式：透明、黃色、桔黃、紅色等模式 採用輕型化的規章制度
比較注重專案文件的用途，要求管理人員使用各種檔案來幫助管理 extreme programming(xp)
由kent beck,ward cunningham,ron jeffries提出和倡導 在所有的靈活性管理模式中是最著名的 使用所謂的故事卡進行專案的計畫規劃 要求在開發過程中一直有客戶的參與
很短的開發周期：任何乙個開發分段都不超過3個星期 群體式負責制：任何人可以參與任何部分的開發 使用重組(refactoring)來進行漸進式設計 採用tdd和連續性整合 要求每週40小時工作時間
dynamic systems development method(dsdm) 是乙個通常由來推動的管理方法
將開發周期分成5個部分：可行性認證、商業需求認證、功能模式迴圈、設計和建造迴圈、以及最終的開發
是一種偏向於繁重規章制度的模式 開發的計畫和設計採取漸進式的
目前有一些商業工具可以用來幫助使用這種方法進行專案管理 類似rup，但是有明確的風險管理指南，能達到較好的靈活性
這個方法不是很常用，與其他幾種方式相比知名度較小，使用較少。
msf-microsoft solutions framework
由randy miller,paul haynes提出，微軟倡導 是基於傳統模式的基礎上發展起來的
屬於比較正式的模式，但最新版本包含了靈活性的模板，加入了使用者角色(personals)的概念
推行乙個從角色到使用方案的設計流程 開發過程採用迴圈型的3星期的週期
要求單元測試的程式與開發程式的原**一起提交 要求100%的原**執行測試(code coverage)
how much architecting is enough?(到底應該做多少事先的構架設計和計畫？)
靈活性與紀律性(指規章制度的嚴肅性嚴謹性)的平衡，兩位作者做了乙個調查，發現了與crystal模式相似的結論，就是在專案管理實施過程中沒有乙個一成不變的規章制度，而要根據專案的規模的大小和開發團隊規模靈活確定，當乙個專案比較小時，事先的構架設計和計畫就可以比較少，而當乙個專案比較大時，事先的構架設計和計畫以及規章制度就要相對增大，才能更有利於專案的順利實施。 管理流程設計的一些準則和指南
團隊成員之間的融洽交往是任何專案管理不可缺少的。有時非得用面對面的交流 規章制度太多會變成繁重的負擔。選擇對開發的靈活性和軟體質量最有利的規章去執行
通常情況下大型的團隊管理規章可以多些 將自我調節的能力設計利用到流程管理中去 總結
不同大小的專案可以採取不同的、能夠最佳適合於它的管理方法 靈活性模式有很多傳統模式所沒有的靈活性 靈活性模式對建立團隊文化很有效 靈活性模式也有它的侷限性
採用時可以考慮逐步採取其中的一部分先執行，根據效果再做調整
幾種軟體開發模式概述
瀑布模型 wate ll model 是由w.w.royce在1970年最初提出的軟體開發模型，在瀑布模型中，開發被認為是按照需求分析，設計，實現，測試 確認 整合，和維護堅定地順暢地進行。瀑布模型 wate ll model 最早強調系統開發應有完整之週期，且必須完整的經歷週期之每一開發階段，並系...
軟體開發概述
今天在學校學習了軟體開發概述，了解了軟體是指計算機系統中的程式以及其文件，程式就是指令的序列。人要與計算機交流需要有能夠溝通計算機的語言，最早的溝通語言為機器語言，只能識別1 0。以及後面出現的組合語言，這2種語言都很難學難記，然人看了頭痛。因此我們將這兩種語言成為低階語言。隨著計算機的發展，新的編...
軟體開發專案管理的3721
1.權力 作為乙個專案經理，你需要獲得授權，否則你很難推行你的計畫。權力主要來自於你上司的信任，從上司那裡獲得管理，評價和獎勵你組員的權力。同時，自身的專長 技能何知識，為人處世的風格，以及你自己的人格魅力都是權力的 2.專案金三角 專案中首先關注的是專案金三角，由三個邊組成，他們是專案的目標 資源...