軟件

軟體開發和其他製造業的區別在於，軟體的成本在於研發，而不是製造，製造業可以有既有的模式來進行流水線的工作方式，大大的提高產品的品質。雖然，軟體有這種固有的特點，但是我認為還是可以藉助製造業的管理經驗來管理軟體開發。尤其是，軟體不會受許多物質條件的限制，也就有了很多更大的發揮空間。一個產品，如何才能稱之為品質高的產品？我認為應該滿足一下條件：1.符合消費者的需要（功能性）2.健壯3.高效（競爭力的體現）其實傳統製造業要弄個新產品出來，並不比軟體開發容易。先要構思，然後一步一步修改，觸達，諸如此類，

很多“架構”設計出來後，你用了一丁點東西吧，都要求你背負整個架構的大包袱。這樣很不好。軟體應該由使用者選擇自己用到的功能，而能將不必要的功能去掉。一個好的軟體設計，應該可以增大也可以減小的。從這種意義上，.net 的dll封裝模式，就不如java的class + jar zip包模式高明。dll 是個大包，可能包含了很多用不上的類，作為物件導向的封裝模式，細化到類是有意義的。假如你的程式只使用架構的某個類，那麼你只需要包含這個類的class檔案，然後包含這個類自身的相關引用，然後類推下去。比如，

提高軟體品質，需要一個良好定義的執行過程。而執行過程，每時每刻都需要一套行之有效檢測反饋的方案。包括擔當檢測主體的人，檢測的工具，和實施的方法。在一個品質管理團隊中，總有兩種角色。一種是送檢方，另一種是檢驗方。1.需求分析階段：送檢方是消費者，他提供了需求資訊，而檢驗方是我們團隊的需求分析員。工具是什嗎？檢驗的方法和標準是什嗎？2.系統模型的建立階段：送檢方是分析員，提供了需求分析報告，而檢驗方是架構設計師。工具是什嗎？檢驗的方法和標準是什嗎？3.功能模組化階段：送檢方是架構設計師，提供了架構層

現在的軟體開發流程是這樣的:需求分析->概要設計->架構設計->模組設計->類設計->編碼->維護新思路:使用者特點分析（類似的功能，對不同使用者的價值點有所不同）->軟體價值分析(也就是軟體給使用者帶來的實際利益的具體輸出結果)->演算法分析(確定軟體結果所需要的相關演算法,從這個可以得出資料的流通變換方式,得到資料實體類,同時還能確定使用者所需要提供的資料內容,和如何提供這些內容的相關手段)->功能分析(建立業務類,業務類使用資料實體類進

軟體架構：提升抽象層次(譯) Peter Eeles的文章，文中一些定義以下面的為準。 架構，是系統的基本組織，涵蓋組件，組件與組件的關係，組件與環境的關係，以及一些指導設計和演變的原則。[IEEE 1471]        與此相關的一些術語：       系統，是具有一個或一組功能的組件集合。該術語的概念涵蓋了個人應用程式，傳統意義上的系統，子系統，綜合系統，產品線，產品系列，整個企業，以及其他利益集合體。系統為任務而生。[IEEE 1471]       

物件導向的思想，先把現實中的對象轉化為程式上的對象。程式，是解決某個問題的相關步驟和次序。而實際很多時候，程式描述的是一個情境活動，首先是有主體，然後是相關活動。程式固有的含義，可能就比較關注活動，而不關注主體。物件導向，首先要確立活動情境中的主體，也就是對象，在分析主體所擔當的職責，也就是功能。過程性的開發方法，強調的是活動，那麼活動的主體是什嗎？是資料，也就是，在過程性的觀點下，程式只是資料的變換過程。而物件導向的觀點，則是對象之間職責的傳遞：“我把我的工作完成了，然後交給你接著做”。過程性

吉日先生說：軟體公司不在於大，只圖大未必是好事，公司不大也未必是壞事，需要有進化的過程

 技術人員有個毛病，明知不可為，偏要為之。 我們要強調使用者的需求，市場分析，去定位軟體，否則就走上了一條有挑戰性但很艱巨的道路。開發軟體為了什嗎？說到底還不是為了賺錢養家，何必要和自己過不去？ 應該如何找軟體的市場定位？首先是從消費者的需求出發，然後看看這個市場有多大，競爭者多不多，還有如何營銷。如果沒有需求，技術再怎麼領先也沒有意義。如果有需求，但是一堆免費的，或者可代替的廉價方案存在，也很難有作為。這兩個都沒有問題，那就要看看整體的潛在市場有多大，如果就兩三個人買，就很難分攤管理和研發的成

 其實財務軟體有什麼用？我覺得是給人一個快捷的印象，有這個印象協助人們怎麼利用現有的財富，怎麼去分配，設計新的理財方案。一般來說，我們不需要太過複雜的理財工具，只有大件的物品才需要我們動用這個數學工具。比如去買房，或者計算所得稅的時候，我們可能需要藉助比較專業的工具。那麼平時理財軟體有什麼用？第一個是記賬，記賬是無趣的，因為人們需要知道的是財務狀況。當然如果不記賬，怎麼能得到財務狀況呢，這是一個不可調和的矛盾。為此，我們需要靈活的設計記賬的錄入工作，讓它更加簡易和人性化。 財務狀況好的人，體現在

過程和方法對於結果只有次要影響，首要的影響是人。人不是插入即相容的編程裝置，如果想要項目取得成功，就必須構建起具有合作精神的自組織的團隊。合作、溝通以及互動能力要比單純的編程能力更為重要。過多的文檔比過少的文檔更糟，編寫以及代碼的同步會花費更多的時間。直到迫切需要並且意義重大時，才來編寫文檔。成功的項目需要頻繁、有序的客戶回函。成功的關鍵在於和客戶之間真誠的合作。在“充滿激烈討論的屋子”裡工作，生產率非但不會降低，反而會成倍的提高。軟體項目不是全速的短跑，而是馬拉松長跑。團隊必須有意識的保持穩定

1. Current Component/Service Oriented Software System Development Model2. Looking into Component (Coming later)3. Looking outside Component (Coming

6.2.1基礎標準 · 軟體工程術語GB/T 11457-1995 (http://www.itpub.net/thread-912864-1-1.html) · 資訊處理 資料流程圖、程式流程圖、系統流程圖、程式網狀圖和系統資源圖的檔案編輯符號及約定GB 1526-1989 (http://download.csdn.net/source/396311) · 資訊處理系統 電腦系統配置圖符號及約定GB/T 14085-1993 (http://www.itpub.net/viewthread.

現在軟體在大多數基於電腦的系統中已成為最昂貴的部分，如果軟體成本估算的誤差很大，就會使盈利變成虧損。 　　軟體項目估算是一種解決問題的形式，在多數情況下，要解決的問題非常複雜，想一次性整體解決比較困難。因此，對問題進行分解，把其分解成一組較小的接近於最終解決的可控的子問題，再定義它們的特性。　　估算技術一般有程式碼(LOC)和功能點(FP)估演算法，這是兩種不同的估算技術，但有許多共同特性。專案計劃人員首先給出一個有界的軟體範圍的敘述，再由此嘗試著把軟體分解成一些小的可分別獨立進行估算的子功能。

在Ubuntu 11.10版本中，有一個軟體中心。在該軟體中心安裝軟體，都會自動下載安裝。你在安裝的過程中沒有選擇路徑這一選項。我的eclipse就是直接在軟體中心中安裝軟體，但是後來想往裡面添加外掛程式，卻找不到路徑。尋找一遍後總算弄清楚怎麼一回事了。我的Eclipse安裝後存放的位置：第一：可執行檔。系統預設安裝在 /usr/bin 這個路徑下。第二：設定檔。系統將eclipse的設定檔存放在 /etc/ 的路徑下面。第三：其他檔案以及檔案夾。系統將用到的其他的資源或者外掛程式等存放在

藍海指還沒有人涉及的市場，紅海指存在激烈競爭的市場。哪個更容易發現？當然是紅海市場，因為參與者眾多。哪個更容易開拓？當然是藍海市場，因為不存在競爭。 從我個人觀點來說，不建議參與藍海市場。首先，我們沒有能力培育這個市場，其次是，我們沒有足夠實力保護這個市場不被別人侵入。有個小故事，相信大家都聽說過。說是一個賣鞋的業務員到某個島國推銷，卻發現他們從來不穿鞋，失望而去；另一個賣鞋的業務員，卻認為這是一個未發掘的藍海市場，免費贈送鞋子試穿，培養、改變他們的生活習慣，最終鞋子得到大量銷售。這個故事，我以

案例案例一某公司承接了一個電子政務平台的項目，該項目主要分“政務辦公”與“政務公開”

我最近碰到一個讓我很蛋疼的事情。一個C#程式員很自豪的宣布，說自己已經看不懂他一個星期前寫的代碼了。說實話，我真想知道他有什麼可值得驕傲的，我完全搞不懂嘛。他自豪的是，他每天寫了很多很多代碼？還是任何人都願意給他錢，讓他寫代碼？對於此事我的觀點是： 對於一個職業C#程式員來說，不能理解你在一周前或者一年前寫的代碼是一件不可原諒的事情。是的，我是麼說的。容我說明一下。我把軟體開發作為職業

1，網路基礎：網路與電腦群組成，作業系統以及傳輸串流程都是緊密關聯的，理解網路基礎 能讓你在開發過程中得心應手。2，需求分析：對於軟體工程來說，需求分析是項目的起點，也是整個項目最最重要的 部分。如果這玩意你搞錯了，整個項目的方向也就錯了。3，DI(獨立注入)：DI或者IoC(Inversion of Control)的具體實現架構Spring能讓你建立對象時更加輕鬆，對於大型企業階層專案更是如此。4，UML圖：UML圖已經是一個通用的軟體設計與分析的語言。如果你們在開發軟體的過程

1.一切的技術都是為實際需求服務的.需求重於技術,因為技術只是實現手段;新的技術的引入需要注意所有你要面臨的問題(開發成本,維護成本,效能問題,系統升級,使用者反響...);2.

必應繽紛案頭測試報告　　　　報告人員：10061152----李嘉良，  10061183----謝永青 軟體名稱: 必應繽紛案頭 (http://desktop.bing.msn.cn/)測試環境:第一部分:按照教程描述的 bug 定義, 找出一個功能性的比較嚴重的 bug   bug1:軟體不能縮小到托盤,必須在工作列中呈現。這個會對使用者的任務管理造成一定程度上的不適應。   現象:　建議：增加最小化托盤功能.