主辦方：省軟件協會

地點：武漢光谷軟件園C6棟1樓報告大廳

與會者：多數為武漢軟件公司，宜昌除我公司外未見公司參加

會議時間：2011-12-8?14：00 – 17：00

講師：微軟中國 開發工具技術服務部?

?

研討命題

1、?如何使用VisualStudio2010來管理軟件開發的生命周期

2、?如何運用VisualStudio2010來實現各種項目管理方法論

3、?云計算下如何使用VisualStudio實現項目服務及測試、計算托管

?

感想

1、本企業如何應用

微軟的軟件開發產品架構完善，且有很多實際利用這套工具的開發案例。但相應的，要熟練運用這套工具不僅需要熟練的開發人員，項目經理、配置管理人員、文檔管理、測試人員的素質都要跟上，而且按微軟的工具應用教程，如果完全應用到公司的某些開發項目上（譬如XX人力資源或是傳真項目），所要使用的人員起碼還要再加一倍，而且必須是素質相對比較高的人員。而且，微軟的案例也大多是高端軟件企業，譬如上海石化盈科等等

由此，我感覺微軟的這套產品無疑是完善的，但要使用到中小型開發企業和需求多變的項目中還需要根據實際情況加以裁剪和應用。具體如何裁剪，需通過以下幾個生命周期來予以考慮：

1）?立項

在這套開發工具中，立項這個環節可以通過與TFS集成的SharePoint來完成立項相關文檔的發布和版本管理。而且完全可以公司的制度建立相應的文檔發布模板。

好處：可以根據生命周期模型建立相對固定的立項時的流程和文檔

難點：

??立項的文檔及相關模板是在不斷改進的，作為公司來講進度、質量的壓力很大，這部分工作很難及時定期改進，目前公司的《項目章程》的版本已經有近一年半沒有改進了。

??要有相應的架構師研究TFS的模板功能，這個需要理解項目管理的人員和一定的開發能力

2）?需求分析

（1）原型工具

微軟對需求分析這塊倒沒有什么出彩的工具，個人感覺我們公司現在使用的原型工具Axure還是很先進的，在目前實踐過程中的問題是：部分客戶理解不了Axure生成的原型（原因很多：想象力低、接觸B/S項目少等，譬如B項目），而且原型的保真度有高有低，遇到低保真度的原型時，可能開發出來的迭代版本與客戶根據原型想象的版本之間還有差距。但高保真的原型（譬如A項目）是相當耗費成本的，不是高額項目根本承擔不了這一成本。但低保真原型是目前短周期、低投入項目唯一適應性較高的做法，至于理解差距只有通過版本的加快發布來彌補。個人感覺，項目型的軟件開發在需求分析上是最難的，因為客戶的素質參差不齊，譬如某廠的車間系統，客戶方使用負責人XX可以說每個版本的發布都參與了，發布的時候也通過了他的認可，但實際應用時，又提出車間員工操作不方便，提出了改進需求，通常這些改進就要耽誤其它項目的開發進度，而且員工一般不愿意維護老項目，一方面是精力不夠，另一方面老項目的確是個費力不討好的工作。

（2）需求分析文檔的棄舍

對需求分析說明書（文檔）目前團隊內有兩種傾向，一種是覺得不必寫文字的需求分析說明書，晦涉難懂，直接用原型表達即可。且有的客戶根本不看這個（譬如XX集團）；另外一種傾向是測試部門需要需求分析文檔，但應該說測試部門需要的需求分析主要是圍繞項目中各模塊的測試要求（譬如壓力指標、輸入輸出范圍、客戶描述等）。

因此，目前各個項目除非客戶特別要求，基本停止了需求分析說明書的編寫，而改為原型說明，部分要求高的項目還加上了業務流程圖的說明。而對測試這邊，加入了數據字典，對測試用例加強了輸入輸出范圍的要求，在測試計劃中補充客戶描述和測試背景等資料。

3）?系統架構

Visual Studio本身是有一套UML建模工具，但在本公司的實踐中這個工具是沒有用到的，一方面是在項目建制上架構師資源是很缺乏的，根本沒有相應的架構人員來專職負責架構，另外一個問題是，需求一直在變化，架構的改變也會變得頻繁，偶爾的變動就會導致架構的部分重構，架構人員在進度壓力下，就無法及時更新架構模型，只能以完成兼任的開發任務為優先，改動的架構就以口頭溝通也能達到相應效果。而且公司目前也有比較成熟的三層架構模型，基本所有開發人員都能理解和明白這個架構，因此，建模架構在目前看來并不是特別的需要。除非有相當大的項目，拆分為2個或以上的項目小組并行開發，或者采用較新的架構模型，我覺得才有必要配置專職的架構師人員維護各個版本的架構模型。

從公司明年的規劃看，架構也會由XX的小組來專職負責審校和推出標準架構，這樣一方面規范了一套可積累的基礎架構，也避免了架構師必須對各個項目需求深入了解的時間不足的問題。

4）?代碼實現

這一環節，是工作量最大的，其實也是細節最多的。微軟在這方面做了很多人性化的改進，對開發者來說，確實方便了很多的。更重要的，這套工具將代碼實現與項目管理進行了有機的結合，譬如說任務管理、進度跟蹤、代碼出入庫等，但還是前面那句話，大公司有大公司的用法，小公司有小公司的用法，目前我們的實際中，任務管理和進度跟蹤基本上還是利用Excel來完成的，實際過程中，利用的最好的還是代碼的出入庫管理，也就是說只用到了基本功能。這并不是我們不會用，而是要實現上述所說的任務管理、進度跟蹤、需求變更等需要比較專職的項目經理，或者專業的配置管理員，目前看來，用Excel來管理進度和任務，用word來管理需求變更也足夠了，將這些嵌入到Visual Studio中誠然更好，但只有相應的主動使用的情況才會有效，否則就流于形式。另一方面，將任務、進度、變更集成到Visual Studio中去管理，其實也是對比較上規模的開發企業有效，因為可以根據各個項目分析各種項目指標，目前對我們來說還沒有必要，一方面項目組成員經常變化，比較缺乏說服力基礎；另一方面，項目經理身兼數職，難以做到專業化。

5）?測試環節

個人覺得Visual Studio的測試是最好的一個模塊。很多先進的測試概念（單元測試、測試驅動、自動化測試、測試用例、版本發布管理、自動化構建）等都有體現，但具體應用時，感覺測試部門基本能掌握這些工具，但在使用時明顯感覺精力不足，基本上這些測試工具還停留在未使用的狀態。

單元測試因為需要一對一的寫代碼，這需要大量的時間與一對一的專職測試，目前測試人員的代碼和時間都比較欠缺。

測試驅動也比較耽誤進度，這與測試人員關系不大

自動化測試是我極力想推進的，但測試部門使用的過程中反映因為需求變化較快，界面和功能變化后，當測試任務較多時，自動化測試很難及時更進維護。但我還是想在合適的項目中試行一下自動化測試。

版本發布管理目前是手工操作的，目前問題主要是內部的版本發布較頻繁，基本上是在測試人員電腦上即時生成，并沒在相應的測試環境上發布，只是在發布到客戶環境上發布到測試環境上。目前看來還是能滿足要求的，可以維持現狀不變。

自動化構建目前是需要推廣的，但要重新搭建一個新的TFS服務器場，目前需要重新研究一下TFS中自動構建的多服務器構建再行推廣，因為項目較多，不同項目的構建環境不同。今天會場上也咨詢了微軟許Sir，應該是可行的。

6）?實施

實施的問題，主要是現場與后方的溝通誤差的問題，這個主要靠項目經理的經驗彌補，另外客戶在現場施加的壓力也是很大的，容易造成過程管理的失控。除非是系統上線期間，一般建議不要在現場開發。

7）?維護

維護的成本越來越大，項目的差異性越大，帶來的維護成本與維護問題也越來越多。目前組建專職的維護部門是不可能的，只能靠完善的代碼和項目文檔資料來彌補。

其它

? ? ? 個人感覺，湖北的軟件公司對新技術的熱情并不高，很多使用Visual Studio開發的公司連Hyper-V都未聽說過，對各種VS的先進工具在會場上也有較多人提問，而且所問的問題基本上我都可以回答，在項目管理上也未見有精彩提問，也許感覺比較偏頗，但確實感覺在場提問的公司在項目管理和新知識的掌握程度上與沿海差距較遠，可能其它未提問的公司有能力較出眾的也不一定。

?

???????? 以上為本次會議本人的一些感想，希望能引導大家積極思考，起到拋磚引玉的作用。

轉載于:https://www.cnblogs.com/georgehu/archive/2011/12/09/meeting1.html

總結

以上是生活随笔為你收集整理的软件生命周期管理研讨会有感的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。