其他

SEI每年都組織一次CMMI研討會，多數CMMI主任評估師都利用這個機會瞭解SEI的最新動向，同時也作為一個與圈內人士社交的場所。主任評估師的工作多數比較獨立，SEPG大會與年度CMMI研討會成為大家難得的機會來相互交流、增進友誼。會上有位美國的主任評估師和我聊起了一個有趣的故事。他在美國的某個軟體工程的相關部落格網站上看到這樣的文章。

當演算法牽涉到一種鏈型運算，而且不希望處理過程中有過多的迴圈和條件選擇語句，並且希望比較容易的擴充文法，可以採用職責鏈模式。1、意圖使多個對象都有機會處理請求，避免請求的寄件者和接收者之間的耦合關係，可以把這些對象鏈成一個鏈，並且沿著這個鏈來傳遞請求，直到處理完為止。當處理方式需要動態寬展的時候，職責鏈是一個很好的方式。2、使用場合以下情況可以使用職責鏈模式：1）有多個對象處理請求，到底怎麼處理在運行時確定。2）希望在不明確指定接收者的情況下，向多個對象中的一個提交請求。3）可處理一個請求的對象

（失敗指：沒有按期完成開發、交付，或沒有達到客戶預期，或沒有完成公司下達的品質/成本/利潤/工作量等方面目標的情況。）引起這些失敗，公司常見的原因如下：1、項目需求沒有提前計劃；（盲目承諾和進入開發）2、不切實際的項目估算，工作量估計不足。（例如：承諾用6個月時間完成10個月才能做完的工作） 3、需求變更缺乏控制，忽視需求的變更和變更控制 4、不收集項目的度量資料，沒有軟體項目開發的曆史資料 5、忽視監督項目的進度（過於粗放的過程監控）

Q：SCM(Software Configuration Management 軟體組態管理)是什嗎？ A: SCM是軟體組態管理（Software Configuration Management）。IEEE中將組態管理定義為一個準則，通過以下手段在技術和管理兩方面對項目進行指導和監督。 l         標識和歸檔配置項的功能和物理特性 l         控制這些特性的變更 l         記錄和報告變更過程以及實現狀態 l        

是 W3C 給出的 SOA 模型中三種不同角色的關係。其中：服務是一個自包含的、無狀態（stateless）的實體，可以由多個組件組成。它通過事先定義的介面響應服務要求。它也可以執行諸如編輯和處理事務（transaction）等離散性任務。服務本身並不依賴於其他函數和過程的狀態。用什麼技術實現服務，並不在其定義中加以限制。服務提供者（service provider）：也稱之為服務生產者，它主要提供符合契約（contract）的服務，並將它們發布到服務代理。服務要求者（service

軟體的品質由一系列品質要素組成，每一個品質要素又由一些衡量標準組成，每個衡量標準又由一些量度標準加以定量刻畫。品質度量貫穿於軟體工程的全過程以及軟體交付之後，在軟體交付之前的度量（內部屬性）主要包括程式複雜性、模組的有效性和總的程式規模。在軟體交付之後的度量（外部屬性）則主要包括殘存的缺陷數和系統的可維護性方面。ISO 9126 稱為“軟體產品評價：品質特性及使用指南”。在這個標準中，把軟體品質定義為“與軟體產品滿足聲明的或隱含的需求能力有關的特性和特性的總和”，可以分為 6

在上一章我們已經構建了軟體架構設計總體過程，為了強調針對品質屬性的架構設計策略，我們還應該在每個節點加入如下子過程。一、以核心功能為主進行架構設計對於任何一個基礎架構，我們都需要回答如下一些問題：這個系統有哪些核心功能？這些核心功能分布在哪些系統級的架構之內？是什麼樣的品質要求才使我們這樣分配功能分布？這些系統功能互相互動的時候考慮了哪些品質要求？事實上，我們總是傾向於使用一些我們熟悉的架構，但是通用的架構很難讓我們回答上述問題。為了確保設計的清晰，在我們已經存在一些熟悉的架構的基礎上，需要按照

在 SOA 領域中有一些常見誤區，現說明如下：1）認為 SOA=Web Service：Web 服務通常指的是基於 SOAP/HTTP 的一種服務，這些服務通常是實踐 SOA 所定義服務的一種技術形式，它提供了分布式環境下卓越的互操作能力，但實現 SOA 的方法還很多，並不僅僅是 Web 服務一種。SOA 構架是獨立於技術實現的。SOA 並不必用 Web Services 來實現，相反，Web Services 也並不一定遵循 SOA 標準。不過，Web Services

ASP.NET利用一個名為_VIEWSTATE的隱藏表單域在回傳中儲存控制項屬性的狀態。如果想要儲存控制項的屬性值，就要把控制項屬性值添加到該隱藏的表單域。2.0支援在回傳/回傳儲存值得兩種方法：檢視狀態和控制項狀態2.1支援檢視狀態使用Control或Page類的ViewState屬性把值添加到檢視狀態。理論上講，可以添加任何可序列化類別的執行個體到ViewState，但在實踐中，應當只添加間的地值到ViewState，否則會影響頁面的執行效率。程式碼範例：ViewStateControl.c

　　一、要完全瞭解整個項目的目標和內容，相信自己的眼睛，而不是耳朵。　　　　作為領導者一定要把確保整個項目的目標以及進展，所以也一定要完全瞭解項目的目標的進展過程中的任何狀況，這樣才能在及時把握住整個專案生命週期。在瞭解的過程中不要道聽途說，其他的人情況和報告很可能是錯誤的，也可能是被誇大的。缺乏經驗的工作都往往會用不同的標準進行衡量，所以標準只能由領導者一人決定和統計。　　　　二、要時刻瞭解手中能夠使用的資源。　　　　項目的資源套件括了裝置、人員、時間、金錢等，只有已經到手的資源才是可用資源，

假定某一個大型系統的設計提出了極高的可靠性要求，因此在架構設計的時候，就需要針對可靠性問題討論具體的解決方案。一、進程間提升可靠性的方法大型系統一般是按照多處理器環境設計的，邏輯上組成處理器組，處理器組的目的是運行一個或者多個應用程式的副本，這一思想對於支援容錯性和可靠性是非常重要的。在多個運行副本中，一個為主，稱為主地址空間（PAS），其它的為輔，稱為備用地址空間（SAS）。一個主地址空間，和相應的備用地址空間的集合稱為操作單元，某個操作單元完全駐留在同一處理器組的處理器中，一個處理器組最多可

　　（一）品質是過程、人、技術三者缺一不可。　　　　QA可以有用，也可以沒用，看自己如何定位，看企業處於什麼環境。在大部分公司，PM的角色是很忙的，QA能發現PM發現不了的問題，這就是對於項目組的作用之一；PM是有跟蹤，但是發現問題，PM只能自己內部解決，不能給高層提供一個準確的進度資訊；但是QA能保證項目進度的透明化.　　　　檢查一些工作日誌時,上面的內容的真實性,識別風險,看到過程中的不足,能提出有效方案完善整個過程,平衡軟體中的三個因素的關係.　　　　至於QA所發現的NC或者其他的問題，得

組合可以說是非常常見的一種結構，我們經常會遇到一些裝配關係，從資料結構上來說，這些關係往往表達為一種樹狀結構，這就用到了組合模式。它的意圖是，把對象組合成樹形結構來來表示“部分-整體”關係，使得使用者對單個對象和組合對象的使用具有一致性。1、結構組合模式的結構可以有多種形式，一個最典型的結構如下。2、效果使用組合模式有以下優點：1）組合對象可以由基本對象和其它組合對象構成，這樣，採用有限的基本對象就可以構造數量眾多的組合對象。2）組合對象和基本對象有相同的介面，這樣操作組合對象和操作基本對象基本

隨著公司資訊化程度的不斷提高，各類應用系統同時並存並支撐著企業的業務應用。越來越多企業的資訊化主管在開發公司專屬應用程式時已經考慮到Data

後期綁定和允許非開發人員進行修改，可以使系統的可維護性大大提升，延遲綁定時間還能夠使終端使用者或者系統管理員進行設定，或者提供影響行為的輸入。後期綁定需要系統的設計上做好準備，方案套件括：運行時註冊：即支援隨插即用操作。設定檔：目的是啟動時設定參數。多態：允許方法調用的後期綁定。構件更換：允許載入時綁定。遵守已定義的協議：允許獨立進程的運行時綁定。

　　太上，不知有之；其次，親而譽之；其次，畏之；其次，侮之。功成事遂，百姓皆謂：我自然——老子

Question：當完成需求評審以後做什嗎？Answer：評審後的需求文檔（一般稱：需求規格書），是作為工程和管理的基準（基礎）。1、在《需求規格書》評審通過後，需求跟蹤責任人應建立【需求跟蹤矩陣】(RTM)，RTM作為一個獨立的文檔來用於跟蹤、維護客戶的需求是否在設計、編碼、測試等階段是否被正確地實現。

Question：同行評審，是否一定要開會？Answer：同行評審的開展方式是多種多樣的，可以開會進行，也可以不開會地進行，關鍵是要對評審問題進行正確反饋、記錄、跟蹤處理。不採用開會的同行評審的開展方式如：1、擁有者和協調員 確認好參與評審的評審人，評審的開始和結束時間後；2、準備好評審包（包含：被《評審對象》、《同行評審記錄表》、《被評審對象對應的檢查單》）3、擁有者或協調員

Question：同行評審，需要統計、分析那些資料？Answer：需要統計和分析的資料包括：評審工作量：評審投入的每個人時、總人時；返工工作量：根據評審意見返工投入的工作量；缺陷數：發現的缺陷和缺陷的等級；規模：被評審對象的規模（單位為：頁、功能點、或程式碼數）；缺陷的階段分析：每個階段引入的缺陷，和每個階段消除的缺陷；缺陷的效率分析：每人時發現的缺陷分析；缺陷的效果分析：每規模上發現的缺陷（如評審規格時每頁發現的缺陷） Question：SCM組態管理，要統計、分析哪些資料？Answer：以下

Question：項目開發過程，還需要和銷售代表溝通交流嗎？  Answer：項目組和銷售代表的交流，不僅僅在售前階段，而是貫穿於整個項目過程。 l       銷售代表從客戶得到的客戶特徵、各種項目或產品資訊，需要及時傳遞給技術部門分析和決策； l       項目組開發過程中碰到的無法解決的問題，需要時要及時反饋給銷售代表以便協調客戶資深經理協助解決； l       售前中收集的各種資訊，銷售代表在項目立項時，需要將項目各種特徵文檔化、詳細說明及傳遞給項目組，