軟件

所有功能開發完成，並通過QA測試，就一切大功告成了--我們一直存在這樣的認識誤區。其實，從軟體產品正式發布交付給使用者使用的那一天起，挑戰才剛剛開始，路還很長。你會遇到各種各樣的問題，讓你半夜都無法安睡。因為，真實的運營環境跟開發測試環境是不同的，你會遇到各種各樣的新問題和挑戰。測試環境裡，可能只有一台伺服器，但是運營環境中可能有很多台伺服器。測試環境中，可能沒有防火牆，實際情況是防火牆一定存在。還有，測試時你只考慮了1000個正常的並發訪問，在運營環境中你卻會遭遇上萬個並發訪問（惡意的，無意的

        開始之初的架構設計決定著軟體產品的生死存亡。“好的開始相當於成功一半”。　　開始的架構設計也是最難的，需要調研同類產品的情況以及技術特徵，瞭解當前世界上對這種產品所能提供的理論支援和技術平台支援。再結合自己項目的特點(需要透徹的系統分析)，才能逐步形成自己項目的架構藍圖。　　比如要開發網站引擎系統，就從Yahoo的個人首頁產生工具 到虛擬機器主機商提供的網站自動產生系統，以及IBM Webphere Portal的特點和局限

要做軟體時，找個類似的軟體參考一下，進步最快。這裡是一個開源軟體分類列表，分類詳盡，可惜我們要用代理訪問http://en.wikipedia.org/wiki/List_of_open-source_software_packages內容很多，可以點擊進評論中有內容的轉載，:)Contents 1 Applied fields 1231.1 CAx1.1.1 CAD 1.1.2 CAE 1.2 Finance 1.3 Geographic information system 1.4

如何進行軟體架構設計？軟體架構設計的目的     對於外包業務類型的項目，軟體架構設計的目的與產品類型的項目有所不同，在這裡主要討論外包類型項目的軟體架構設計目的。    1、為大規模開發提供基礎和規範，並提供可重用的資產，軟體系統的大規模開發，必須要有一定的基礎和遵循一定的規範，這既是軟體工程本身的要求，也是客戶的要求。架構設計的過程中可以將一些公用部分抽象提取出來，形成公用類和工具類，以達到重用的目的。   

提高軟體可靠性的方法和技術         1.建立以可靠性為核心的品質標準    在軟體專案規劃和需求分析階段就要建立以可靠性為核心的品質標準。這個品質標準包括實現的功能、可靠性、可維護性、可移植性、安全性、吞吐率等等，雖然還沒有一個衡量軟體品質的完整體系，但還是可以通過一定的指標來指定標準基準。    軟體品質從構成因素上可分為產品品質和過程品質。     產品品質是軟體成品的品質，包括各類文檔、編碼的可讀性、可靠性、正確性，使用者需求的滿足程度等。    

    最近在維護公司的一箇舊項目的時候，發現有些BUG改了又改，子生孫，孫又生子的。公司裡只要接觸過這個項目的同事都覺得非常的痛苦。一個對象的狀態被七八個地方修改，經常是這邊改成這樣，那邊又改成這樣，這邊對了，那邊又錯了。幾經思考，我認為這是違反了迪米特法則導致的。    迪米特法則（Law of Demeter）又叫最少知識原則（Least Knowledge Principle

1．概念需求的定義包括從使用者角度（系統的外部行為），以及從開發人員角度（一些內部特性）來闡述需求。關鍵的問題是一定要編寫需求文檔。我曾經目睹過一個項目中途更換了所有的開發人員，客戶被迫與新的需求分析者坐到一起。系統的分析人員說：“我們想與你談談你的需求。”客戶的第一反應便是：“我已經將我的要求都告訴你們前任了，現在我要的就是給我編一個系統”。而實際上，需求並未編寫成文檔，因此新的分析人員不得不從頭做起。所以如果只有一堆郵件、會談記錄或一些零碎的未整理的對話，你就確信你已明白使用者的需求，那完全

 "我們決定下個月28號進行驗收"，客戶很輕鬆地在不經意之間和我說了這句讓我朝思暮想的話，這句話使曆時三個月的接受日期終於定下來了。回顧這三個月，我可是費了不少心力。日期雖然定了，但是和合約規定的日期足足晚了三個月。   

《程式員》官方部落格：http://blog.csdn.net/programmer_editor隨著中國軟體開發2.0技術大會的臨近，我們看到今天的軟體開發正在邁進一個新的時代。        從撥開關進行編程的時代開始，軟體開發經曆了一次又一次的蛻變。而最近的這一次蛻變，與以往都不相同，它是軟體開發一次最激動人心的Release版本，在這個軟體開發的新版本中，主要的變化包括以下方面：● 互連網和Web應用技術換代● 企業軟體社會化的革新● 軟體開發的底層環境改變● 軟體開發的語言與工具變化 

軟體測試工程師，目前IT行業極端短缺的金貴人才，未來5年IT行業最炙手可熱的高薪職位。中國軟體業每年新增約20萬測試崗位就業機會，而企業、學校培 養出的測試人才卻不足需求量的1/10，這種測試人才需求與供給間的差距仍在拉大。由於軟體企業要求測試人才有較高的專業水準，導致大量無測試經驗、無測 試技能的高學曆應聘者遭受冷遇。而且目前從業者大部分是從其他崗位轉型過來的，水平不一，不具備專業能力，導致企業“有活沒人幹”的尷尬境況。

作者:範智華 來源:天極       隨著電腦硬體成本的不斷下降，軟體在整個電腦系統的成本中佔有越來越高的比例，如何提高軟體品質是整個電腦軟體行業的重大課題。軟體測試作為軟體開 發的一個重要環節，日益受到人們的重視。為了儘可能多地找出程式中的錯誤，生產出高品質的軟體產品，加強對測試工作的組織和管理就顯得尤為重要。 1. 軟體生存周期    一個軟體從開始計划起，到廢棄不用止，稱為軟體生存周期。一般來說，軟體生存周包括計劃、開發、運行三個時期，每一時期又可分為若干更小的階段。計劃時期

第4章 測試            烈火驗真金，逆境磨意志。                        ——盧修斯.塞尼加（公元前4－公元65）1 測試驅動的開發方法    測試驅動的方法對於我們正在編寫的軟體的設計有積極的影響：    (1) 程式中的每一項功能都有測試來驗證它的操作的正確性。    (2) 首先編寫測試可以迫使我們使用不同的觀察點，可以設計出便於調用的軟體    (3) 通過首先編寫測試，可以迫使自己把程式設計為可測試的，迫使我們解除軟體中的耦合（force us to

IBM 首席軟體設計師 Steve Mills：IBM 會在很長一段時間內擔心 Oracle 將在 Java 授權上採取鐵腕做法。      上周 Interarbor Solution 首席分析師 Dana Gardner 與 IBM 首席軟體設計師 SteveMills 一起談論了 Oracle 對 Sun 的收購以及 Java 的未來。Mills 認為 Oracle、Sun 的收購交易將通過，但Mills 同時也認為 Oracle 首席執行官 Larry Ellison 收購 Sun

 以前讀過《藍血十傑》，說的是十位哈佛畢業生如何拯救了福特汽車公司的故事。今天我來搞一個開源軟體十傑。No.1 自然非偉大的 RMS 莫屬了。Richard Stallman，GNU 的創始人，GCC 和Emacs 的作者。GPL 的發明人。No.2 Linux Fan 的教父，Linus Torvalds，Linux 的創始人和領導者。 No.3 Apache 的作者 Brian Behlendorf。No.4 Perl 的發明人 Larry Wall。 No.5 Miguel de

異地分布式軟體開發（Distributed Software

 　“軟體業，以人為本”。參與軟體開發過程的各類人員的共通心理表現，對整個開發過程起著舉足輕重的影響。作為一名項目管理者，非常有必要對其進行一一剖析，找出心結，然後對症下藥，加大溝通力度，提高開發效率。　　結症一：使用者，由於觀念上的不同，國內的使用者更傾向於看到一個實實在在的“東西”。傳統開發方法的每個階段的審查和簽字，留下的往往是那句經典 笑話：“不錯，這是我所要求的，但不是我想要的。”而且由於客戶看不到一個成型的“東西”，讓他在確認報告上籤字也是一件比較頭痛的事，更何況客戶的需求

  大型軟體項目需要很多人的能力合作，花費一年或數年的時間才能完成。為了提高工作效率，保證工作品質，軟體開發人員的組織、分工與管理是一項十分重要和複雜的工作，它直接影響到軟體項目的成功與失敗。首先，由於軟體開以人員的個人素質與差異很大，因此對軟體開發人員的選擇、分工十分關鍵。1970年，Sackman對12名程式員用兩個不同的程式進 行實驗，結論是：程式排錯、調試時間差別為18：1;程式編製時間差別為15：1;程式長度慶功別為6：1;程式已耗用時間差別為13：1。近年來，隨著軟

這隻是一個草稿，作為這一個月研究、‘創新’上的一點總結。文章寫得比較亂，大家有興趣的話可以郵件我。BeyondTrack 的 Software Process Engine 以及 SPDL 看來要暫時告一段落了     Software Process Engine of BeyondTrack Software Process Engine of BeyondTrack  1 Motivation Software process modeling and execution is

關於軟體過程、或者是軟體生存周期領域內的工作流程、過程規範、產品研究了差不多半年時間了。研究的主要是開源、開放、業界標準相關，有點膚淺的心得，概要如下 :-)　對軟體過程支援環境而言：Eclipse: EPF比較成型的社區規模，沒有深入研究。不過感覺 eclipse 下面的東西基本是比較難用的，而且社區開發進度令人擔憂。OMG: SPEM規範就是規範，也只是規範。SPEM 的實現比較罕見，國內研究非常少，貌似中科院有個實現。國外關注也比較少，仍停留在理論上。規範，大而全啊....IBM:

基於 Petri 網的軟體過程支撐環境設計基於 Petri 網的軟體過程支撐環境設計摘要第 1 章 緒論1.1 軟體過程與過程建模1.3 軟體過程支撐環境現狀1.3 本課題的研究內容及意義1.3.1 研究內容1.3.2 意義1.4 Petri 網簡介第 2 章 軟體流程定義語言2.1 SPDL 概述2.2 SPDL 元模型2.2.1 XML Schema2.3 模型變換2.3.1 SPDL 域到 Java 域的變換2.3.2 SPDL 執行個體的 Petri 網圖產生2.3.2.1 基元塊2.3