軟件

軟體開發管理中的博奕論吳旻泰岩網路工作室          軟體開發人員大多懂得演算法的威力，但無數失敗的項目卻向我們展示了一個又一個教科書解決不了的困境。不斷前進軟體的管理方式在力爭避免項目失敗，其實就是在不遺餘力的破解這些困境。今天我們從博奕論的角度重談這些問題，沒準你會覺得從此天高雲淡！ 一、到底誰的BUG：“智豬博奕”，多勞並不多得？        

軟體架構軟體架構（software architecture）是一系列相關的抽象模式，用於指導大型軟體系統各個方面的設計。軟體架構是一個系統的草圖。軟體架構描述的對象是直接構成系統的抽象組件。各個組件之間的串連則明確和相對細緻地描述組件之間的通訊。在實現階段，這些抽象組件被細化為實際的組件，比如具體某個類或者對象。在物件導向領域中，組件之間的串連通常用介面_(電腦科學)來實現。

Linux下是除了二進位形式的軟體分發外，還有原始碼形式的軟體包，講一講這些軟體的安裝與卸載： 一、二進位分發軟體包的安裝與卸載 Linux軟體的二進位分發是指事先已經編譯好二進位形式的軟體包的發布形式，其優點是安裝使用容易，缺點則是缺乏靈活性，如果該軟體包是為特定的硬體/作業系統平台編譯的，那它就不能在另外的平台或環境下正確執行。 1、*.rpm形式的二進位軟體包 安裝：rpm -ivh *.rpm 升級：rpm -Uvh *.rpm 卸載：rpm -e

從網站或是在CD-ROM上找到的Linux軟體包，大部分為rpm、tar、gz、tgz、bz、bz2等格式。下面我們編介紹一下它們的安裝方法。一、RPM格式檔案的安裝RPM是RedHat Package Manager(RedHat軟體包管理工具）的縮寫。現在主流的Linux發行版本都採用了這一公認的開放式行業標準了（包括Red Hat Linux、Open Linux、S.u.S.E Linux、Turbo

 通用公式：計算平均的並發使用者數： C = nL/TC是平均的並發使用者數；n是login session的數量；L是login session的平均長度；T指考察的時間段長度。並發使用者數峰值： C’ ≈ C+3根號CC’指並發使用者數的峰值，C就是公式（1）中得到的平均的並發使用者數。該公式的得出是假設使用者的login

做軟體要厚道----《如何管理軟體企業》讀後感吳旻泰岩網路工作室林銳在CSDN的CTO俱樂部上贈送他的新作《如何管理軟體企業》。昨天下午收到贈書，晚上回家翻開就讀。書一開啟，就覺得從沒見過這麼容易理解的管理學書籍。看他寫的《高品質C/C++編程指南》，就沒這麼通俗。仔細想了一下，技術人員寫技術，那一定簡單不了；但技術人員寫管理，那一定是他自身體會的精華，他把他能理解的要點都講出來了，而且應該都經過他的親曆實踐。他去掉了大量的統計和論證，甚至過濾了很多管理體系的細節說明，比如CMM/CMMI和RU

賣軟體，賣服務，賣思想？吳旻泰岩網路工作室          林銳講了這樣一個故事。有一次當他給客戶示範完了自己的管理軟體後，客戶表示完全可以自己組織幾個開發人員，用一段時間來開發出相同的產品來，不但可以自己用，將來也可以銷售給其它公司。言外之意，沒必要買他的產品。         林銳接著說，表面上看管理軟體好像挺簡單，其實後面隱藏著複雜的管理思想。你自己可以開發出來相關的產品，但遇到問題找誰來解決？後期的升級工作如何規劃，銷售給其它客戶，又如果進行售後支援？        

軟體設計需要有一點曆史觀吳旻泰岩網路工作室          國慶假期去看了一下趙州橋，就是我們小學課本中描述的，那座已經存在了1400多年的石拱橋。        

 一、責任心   

軟體涉眾（stakeholder），即客戶、管理者和開發人員等，他們想要的是具有可預測性的工作。當前，已有一定比例的軟體組織達到了這個目標。他們證明了這一目標的存在性，正如科學家們所聲稱的：有序的軟體開發是可以實現的。這並不是說實現它很容易，而只是說它是可能的。我們所說的可預測性指什麼呢？我們的意思是，一個具有一定層級生產力（productivity）的項目組織能夠在計劃的時間(time)架構下，消耗計劃數量的努力(effort)，而完成所要求的功能(work)

軟體架構是一種思想，一個系統藍圖，對軟體結構組成的規劃和職責設定。而軟體架構是一個實現，一個半成品，是針對一個特定問題的解決方案和協助工具輔助。這一篇講軟體架構和軟體架構在UML設計過程中所起的作用。本系列文章不是專門討論軟體架構和軟體架構的，所以不會深入講怎麼做軟體架構和軟體架構。另一個原因是筆者尚無這個自信能夠在這裡班門弄斧講軟體架構。之所以要講，是因為在設計過程中，設計類必然會受到軟體架構和架構的約束。從分析類到設計類，軟體架構和架構是不得不考慮的一個重要因素。

軟體架構屬於設計範疇，但並不是所有設計都屬於軟體架構設計之列。　　正如前面軟體架構的“決策派”概念所揭示的，軟體架構可以視為一系列重要決策的集合。不僅如此，架構決策還是分層次依次展開的。　　首先，伴隨著對軟體系統的依次分解，軟體架構師應當不斷做出決策，例如需要劃分成哪些模組、每個模組的職責為何、每個模組的介面如何定義、模組間採用何種互動機制、如何滿足約束和品質屬性需求、如何適應可能發生的變化等等。　　以一個硬體裝置調試系統為例。軟體架構師通過理解需求，對該裝置調試系統應完成的主要目標有了全域地把

在軟體開發中，我們對於軟體架構經常看到極端，要麼不重視軟體架構，要麼過分重視以至於她成了“天條”。我甚至遇到了這樣的事情，某公司強制推行某基於Struts的架構設計，然而到了項目組它卻處處遭到抵制，特別是分部基本上拋棄了這個架構設計。那麼，這個原因在哪裡呢？為什麼一個成本高昂的架構設計沒有被接納呢？　　實際上有時候一個良好的設計也未必會被接納，特別是沒有Java開發實際經驗甚至缺乏軟體開發經驗的專案經理試圖控制技術的時候更加如此。我們拋開這個可能的影響來看待這個問題。

現在對於我們的團隊來說，是時候幹點實際的了，我們在這裡開發軟體，所以讓我們來談談軟體。我答應過要把這裡最新的東西展示給大家，我決定以"在微軟我們怎麼開發軟體:一名准專案經理的視角"

中小型軟體企業的技術生存方式大體可以分為兩類，一類為應用服務型，另一類為技術研髮型，目前大部分的中小型軟體企業均屬於應用服務型，筆者所在公司的技術生存方式也屬於第一種類型，即為應用服務型。下面，僅就技術服務型技術生存方式軟體企業的技術管理工作發表一些自己的建議，供同行參考：一、開發和管理崗位分離      

中國有很多優秀的軟體人才，但為什麼難以做出大型軟體系統？中國軟體人才應如何培養？微軟亞洲研究院院長張亞勤今天提出了軟體業人才需要具備的四種素質，其中特彆強調了團隊合作精神。 　 張亞勤在今天舉行的“技能人才與中國製造”高層論壇發言後接受了記者的採訪。 　

什麼是架構

軟體架構師的工作職責 構架設計師負責在整個項目中對技術活動和工件進行領導和協調。構架設計師要確立每個構架視圖的整體結構：視圖的詳細組織圖、元素的分組以及這些主要分組之間的介面。因此，與其他角色相比，構架設計師的見解重在廣度，而不是深度。(RUP中的定義）人員配備“理想的建築師應該既是文學家又是數字家，他還應通曉曆史，熱衷於哲學研究，精通音樂，懂得醫藥知識，具有法學造詣，深諳天文學及天文計算。”---維特魯威（古羅馬建築師），約公元前 25 年簡而言之，構架設計師必須多才多藝、成熟練達、洞察力強、

 　　北京時間10月13日下午訊息，據美國科技部落格網站 BusinessInsider 報道，南非招聘網站 JobVine 根據美國線上職業互動網站 Glassdoor

“ 軟體藍領 ” 隨著來自印度的 IT 培訓被耳熟能詳時，更有來自各地的有關重金招募 “ 軟體藍領 ” 的新聞時不時地激起人們對該職業的嚮往。一份被稱為 “ 藍領 ” 的工作竟會得到如此多的 “ 追捧 ” ，不禁讓人多少心存疑惑。 　　經過記者幾番調查，得出這樣兩個結論：在中國，還很少有絕對意義上的 “ 軟體藍領 ” 存在，這個詞被 “ 軟體工程師 ” 所代替，軟體工程師在中國前景廣闊；入行需要多重能力。 中國 “ 軟體藍領 ” 等同軟體工程師