其他

MS研究院釋放了一種新的語言 Cω， 為了校正讀音，他們還在網頁上設定了語音功能。（讀C

作為一個具有發展前景的應用系統架構，SOA 尚處在不斷髮展中，肯定存在許多有待改進的地方。隨著標準和實施技術的不斷完善，這些問題將迎刃而解，SOA 應用將更加廣泛。一般認為，SOA 還是有一定的缺憾的：1）可靠性(Reliability）SOA 還沒有完全為事務的最高可靠性包括不可否認性(nonrepudiation)、訊息一定會被傳送且僅傳送一次（once-and-only-once

 布局 上一次我們簡單介紹了XAML的寫法，這一次，我們著重介紹XAML中介面的布局。同ASP.NET的Table類似，Grid也可以用來布局，下面的XAML顯示了2*2的網格： <Grid xmlns="http://schemas.microsoft.com/winfx/avalon/2005" xmlns:x="http://schemas.microsoft.com/winfx/xaml/2005"><Border Grid.Column="0" Background=

1，防止編寫成智力拚圖許多文檔寫成了類似智力拚圖的玩具，很多不同的相關定義與內容散落在文檔的不同地方。讀者不會預料到在文檔的其它地方會不會還有相關說明。為了閱讀這樣的文檔，人們需要把一切都記在腦子裡，智力拚圖是把散落在各處的小塊拼在一起，但人的大腦很難做到這一點。要記住，任何大的文檔都不同程度的具有智力拚圖性質，但我們的任務是減少智力拚圖塊的數量。不要讓閱讀者在一個地方看到的資訊塊做出了推論，而在另一個地方才發現這個理解是錯誤的，這就很危險。組織文檔的原則，大多數情況下是防止出現智力拚圖的情況，

 樣式 樣式類似於Html中的CSS，如果你的介面有許多元素（例如按鈕）的外觀有相同的屬性，那麼可以把這些屬性集中到一個稱為資源的元素中，之後每個元素可以通過引用相應的資源來達到外觀一致性的目的。下面的Xaml示範了上述的效果： <DockPanel xmlns="http://schemas.microsoft.com/winfx/avalon/2005"

很常見的情況是，開發人員對於書寫文檔有種種非議，但是一個正規的軟體項目，即使帶來了表面上的工作效率降低，也必須花費精力書寫文檔，為什麼呢？任何時候，只要是兩個人以上參與項目，都離不開口頭交流，但是每個人在傳遞這個口頭交流的內容的時候，都會把原來的意思歪曲一點點，人類的記憶能力就是這樣的。一個軟件項目永遠離不開口頭交流，我們不必要去停止這種交流方式，但是當開發人員比較多的時候，就可能帶來很多麻煩，某些情況需要大家都知道，需要其他人員與之互動等等，解決的辦法就是把所有的情況記錄下來，或者是要強調書寫

　　曾經有一位評估師開玩笑說，三級是寫文檔，四級是寫文檔的文檔，五級是寫文檔的文檔的文檔。由此可見，文檔貫穿於整個CMMI，在流程改善中起著舉足輕重的作用。那麼如何才能寫出既符合CMMI又立足於企業本身實際情況的文檔呢?這就是本文將要探討的問題——定義過程文檔。　　在定義過程文檔時，首先，應該進行企業的習慣表述與CMMI術語和語言間的映射。特別是組織圖中的一些術語、角色、組織內部之間關係以及過程活動的表述方式都需要映射到其組織的相應部分，以防止別人無法理解。　　定義過程文檔的一般步驟是：　　(1

使用者控制項——棋盤   顯示棋盤可能想上去並不太難，首先使用一個Canvas（畫布）控制項，然後在上面畫上我們需要的水平和垂直線條，它們的Xaml代碼如下：<Grid>…<Canvas Name=”board” Width=”400” Height=”400” Grid.Row=”1” Grid.Column=”1” ><Line X1=”20” Y1=”20” X2=”380” Y2=”20” Stroke=”Black” StrokeThickness=”1”

一　通過執行個體認識策略模式        首先讓我們來說明一個問題，在軟體業惟一不變的是什麼呢？是變化。這是不是有點冷笑話的感覺？不管怎樣，這就是事實，要想在軟體行業混，我們就必須得接受這一點，我想絕大多數的程式員也是接受了這一點的，要不為什麼有程式員是體力勞動者這一方法呢（當然變化只是造成程式員繁重工作的一個主要點，並不是全部原因）？    

1，介紹提供整個前景文檔的概述。1.1 前景文檔的目的文檔的目的是收集、分析、定義高層使用者需要和產品特性。1.2 產品綜述闡述該應用系統的目的、版本以及要交付的新特性。1.3 參考這一部分應該列出在前景文檔中引用的其它文檔的全部清單。2，使用者描述簡要描述系統使用者的觀點。2.1 使用者/市場統計總結決定產品動機的主要市場統計。2.2 使用者剖析簡要描述系統預期使用者。2.3 使用者環境描述在使用中包括應用程式和平台等成分的工作環境以及具體的使用模型。2.4

1，SOA 的三個抽象層級從概念上講，SOA 中有三個主要的抽象層級：操作：代表單個邏輯工作單元（LUW）的事務。執行操作通常會導致讀、寫或修改一個或多個持久性資料。SOA 操作可以直接與物件導向 (OO)

1、增量模型的優點：整個項目的資金不會被提前消耗，因為首先開發和交付了主要功能和高風險功能。每個增量交付一個可操作的產品。每次增量交付過程中擷取的經驗，有利於後面的改進，客戶也有機會對建立好的模型作出反應。採用連續增量的方式，可把使用者經驗融入到細化的產品，這比完全重新開發要便宜得多。“分而治之”的策略，使問題分解成可管理的小部分，避免Team

實獲值分析法又稱偏差分析法,是一種分析目標實施與目標期望之間差異的方法.掙值法的優點是能同時判斷項目預算和進度計劃的執行情況,以預算和費用來衡量工程的進度. 掙值法的三個基本參數1.計劃工作量的預算費用(BCWS---Budgeted Cost for Work Scheduled),也稱PV(規劃成本),2.已完成工作量的實際費用(ACWP---Actual Cost for Work Performed),也稱AC(實際成本)3.已完工作量的預算成本(BCWP---Budgeted

一、業務用例的分析不論是預測性過程還是敏捷過程，需求都是從瞭解業務開始的，並且在建立業務模型的過程中發現和挖掘需求。建立業務模型首先是建立業務上下文圖，也就是業務範圍看成一個黑箱，表示所有相鄰系統與業務範圍的資料互動關係。例如我們需要瞭解一個“道路除冰工作系統”，我們可以把上下文圖繪製如下。我們知道，在任何情況下，圖形都沒有辦法表達細節，但更容易表達關係。為了更精確的描述外部系統與系統之間資料流動關係，需要通過表格仔細列出每一個參與者與系統之間的資料流動，下表列出了這樣的資料流清單。道路除冰系統

軟體能力成熟度等級模型（CMM／CMMI）已成為IT業界通用的過程體系，是一條提高軟體企業產品品質、增強企業核心競爭力的有效途徑，它給軟體企業帶來的成功已經為許多國內、外著名軟體廠商所證明，根據SEI的統計，軟體企業在引入CMM後勞動生產率平均增長了35%；錯誤比率平均減少39%；平均成本回報率為5：1。縱觀國內自1993年開始Motorola（中國）實施起，至後來的東軟、金蝶、用友等公司紛紛實施CMM或CMMI，國內企業實施CMMI一時間方興未艾。但是大部分的企業（近60％的企業）實施CMMI

　　桂莉　　工作以來，我參與過多個CMM/CMMI項目的實施，其中全過程實施的項目(差距分析、流程定義、過程部署和實施、正式評估)有兩個。那時，我是作為實施CMM/CMMI的項目組員參與其中，不論是在相關知識(對CMM/CMMI體系較為深刻的認識)，還是在實施經驗方面(可以說具備全過程實施經驗的人不算多)，個人收穫頗多。而現在作為顧問參與到客戶的CMMI項目&lt;SCRIPT

為了能夠實現架構設計，概要層次的用例可以協助我們建立業務架構概念，利用概要層次的用例集中精力考慮了系統大的關係，專註於子系統和功能塊“黑盒”層面的狀態與行為，而有意的忽視了本身細節層面的內容，這在很多情況下是架構設計所需要的。但從另一方面來講，作為架構層面的需求分析，很多內容又需要從細節層面考慮，特別是各個子系統和功能塊之間互動行為的描述應該細緻翔實，從這個範圍來說，很多架構層面的需求分析又屬於使用者層面，因為這才有可能構建一個初始的架構基準。正是基於這樣兩個方面的考慮，我們需要把架構層面的一些

評估實踐證明：在進行CMMI評估之前，制定一個正確的評估計劃並將其文檔化，確保有一個富有經驗的、受過培訓且具有適當資格的小組能被用來評估，為執行評估過程做準備，是十分必要的。我們所說的文檔化評估計劃的結果，包括：要求，協定，估價，風險，剪裁方法，以及與評估相關的實際考慮（例如：排程，後勤，組織的背景資訊）。此外，還應當擷取並記錄發起方對於評估計劃的正式批准。在制定評估計劃之前，應對評估輸入中反映出來的協議文檔化，該協議將有助於評定目標和關鍵評估計劃參數的共同理解。在對驅動計划過程的關鍵參數達成共

模式是一種對現實世界的概念抽象，建築模式，設計模式，營銷模式，商業運作模式各行各業都有自己的模式。 這裡說的設計模式是軟體設計裡的模式，主要是指物件導向的軟體設計。遵照設計模式，可以有效提高軟體的可維護性和可複用性，提高開發軟體的效率，避免過多的出現再造輪子的現象。 我學習模式是從知道大名頂頂的四人幫的力作《設計模式》，真正感覺到了設計模式給軟體設計所帶來的諸多好處。《設計模式》內容精練，執行個體較少，我的理解力太差，實際學習中，我是結合jeffyyan的java於模式學的。 設計軟體的幾個原則

下面，我們針對系統架構和設計中的“壞味”（註：“壞味”是 Martin Fowler