軟件

轉自 ThoughtWorks敏捷式軟體開發 (Agile Software Development)是從1990年代開始逐漸引起廣泛關注的一種新型軟體開發方法，是能夠應對快速變化的需求的一種軟體開發能力，它作為一種新型的開發模式，被越來越多地應用到軟體項目中。敏捷軟體測試指的是在敏捷式軟體開發 (Agile Software

多年來，軟體交付被視為輔助的商務程序。儘管軟體交付花費了企業大量的成本，但是它始終沒有成為企業業務的關注點，因為它不像供應鏈管理、

如果世界上有一個人能夠保證一次寫出來的代碼是百分之百正確的，那麼毫無疑問，他一定是世界上最優秀的程式員，沒有之一。為什麼要求代碼寫好過後要進行充分的自測(包括單元測試和整合測試)？就因為是人皆會犯錯，是程式就會有bug。作為一名軟體開發人員，必須要學會對程式進行測試，也就是要學會程式的調試。一般而言，對代碼的調試有以下幾種方法：第一，憑肉眼看。在開發階段，我們編寫的每一行代碼都需要用我們的“火眼金睛”多審查幾遍。如果要問，最好的代碼調試工具是什嗎？我認為是人眼。不管是代碼

最近看了一則笑話，大意是路人甲到電信營業廳去交電話費，給營業員說要充50塊錢，那個營業員問了一句“How much?”。路人甲心想現在社會真的與以往不同了，連一般的營業員都開始流行講英語了，於是便以不是很流利的口語說了一句“Fifty

在編寫程式的時候，定義變數是必不可少的，這時就要用到一些基礎資料型別 (Elementary Data Type)。也許你會說，定義一個變數有什麼困難的，這是很容易辦到的。要定義整型變數，直接用“int i;”語句就可以了；要定義字元型變數，直接用“char

序言正式踏上軟體開發崗位已經將近兩年了，經曆了很多，也學到了很多。“萬事開頭難”，學生轉變為職業人的過程，恰似繭化成蝶的過程。1.為什麼要寫作本系列？在工作的過程中，我發現我們在學校裡面學到的很多東西片面膚淺，根本達不到崗位的要求。像編碼規範、研發流程等等學校裡幾乎不提及的知識，在實際的軟體開發項目中卻恰恰是異常的重要。在學校裡面，我們欠缺的教育主要包括以下方面：第一，對編碼規範的要求。電腦編程課上，老師只要求學生能夠編寫程式實現既定的功能即可，幾乎不會對編碼規範提出要求

——對軟體分析設計的一次深刻反思與探討前言：你幹軟體開發多少年了？你是否開始感到困惑了、累了、算了？你是否該找一個加州旅館好好歇一歇腳了？這篇文章也許就是你的加州旅館，它給你解惑，反思軟體開發中出現的問題，探討解決這些問題的辦法，那就是建立模型——用例模型、領域模型、分析模型和設計模型。談起軟體開發，我在10年前就開始了。那時天是藍的，生活是美好的，程式設計也是輕鬆愉快的。如果當時有人告訴我，設計一個程式需要數十人、花數年的時間完成，我會張著大大的

軟體需求工程過程(SREP)，本文簡要地列舉並說明了在整個軟體需求工程的過程中的工作職責要點。一、 開始1. 專案經理根據項目特點，指定對過程表格的具體要求；2. 專案經理制訂項目的標準，包括：DTS(缺陷類型)、TRA(風險類型)、TRS(需求類型)等，在過程表格中按標準引用.二、 計劃1. 計劃經理估算需求開發時間；2. 計劃經理完成：SPT(進度計劃)、TPT(任務計劃)，將計劃資料錄入PDS(專案計劃摘要).三、 需求萃取1. 軟體需求工程師搜集系統概要資訊，填寫REQ(需求萃取概貌)；

最近公司因為需要對監測軟體進行改進~~所以對幾個不同的監測軟體安裝後進行了比較~~對於大家比較熟悉的MRTG , Cacti等等同上的文章已經很多了~~最近調查發現Munin也是一個非常好用安裝和設定方便的監測軟體~~小弟在FreeBSD下安裝後~~為了以後方便自己學習把簡單的安裝手順記錄了一下~~貼上來跟大家分享一下~~Environment :OS : FreeBSD 6.2

眾所周知，在軟體測試行業，往往都是以軟體 Bug 數量來衡量軟體的品質。一個軟體被測試團隊 發現有大量 Bug 時，該軟體的品質被認為處在不高的水平。當較少的 bug 被發現時，軟體則被認為 是具有較高品質的。測試的目的是為了發現更多的 Bug，然而測試人員經常會為追求發現更多的 Bug 數量而忽略了軟體測試更本質的東西。軟體測試的終極目標是給客戶提供滿意的產品和服務。因此， 只有真正去理解、熟悉、分析客戶所關注的業務，包括客戶的使用目的、客戶的使用預期、客戶的部

我很喜歡阿甘媽媽說的一句話：生活就像一盒牛皮糖，你永遠不知道下一顆是什麼滋味！（原文是英語，這是純正中國風的翻譯）然而不得不承認的是：程式員的工作多少有些枯燥，年複一年的類似編碼，久而久之容易乏味，再然後是抵觸，再然後是懷疑，然後就沒有然後了！回到早些年，我剛剛參加工作時，自己寫著代碼，也懷疑過，不過我一直用一句話鼓勵自己，在這裡和大家分享—— 今天的努力是為了兒時吹過的牛逼！小

第 8 章 軟體日誌8.1. 配置PVM可以使用JDK日誌（java.util.logging）或log4j.當第一個資訊被記錄， PVM日誌會根據下面的過程進行選擇：1. 如果一個logging.properties資源被發現在 classpath（使用context classloader）下，然後JDK日誌會被使用 這個檔案會被用來實現JDK日誌。2. 如果log4j在classpath中找到，然後log4j會被用到。 對log4j的檢測會通過檢測context

內容簡述背景一個好的J2ME 應用程式，最後就是在程式讀取系統資源的時候（網路，sms，pim，file等）無需彈出 煩人的提示。本文的目的就是探討這方面的知識。內容介紹J2ME 的認證可以解決上面提出的問題，本文主要是對網路上的一些解決方案跟經驗做次總結預期讀者跟建議需要對J2ME程式簽證的開發人員，假設開發人員已經熟悉了J2ME。由於本人水平有限，存在一些錯誤的地方，希望大家多多交流。MIDlets 簽證什麼是Java 數位憑證原文連結

無知是福，但是在處理軟體bug的時候，這句話並不適用。軟體品質專家會告訴我們，那些努力找出bug並且提高 軟體品質的公司可以得到客戶更多的信任，得到更高的利潤，降低開發和維護的費用，簡化交付的流程，同時還可以避免客 戶的流失。軟體品質是個大工程如果你覺得軟體品質沒有什麼大不了的，那麼就來看看Capers Jones在2011

為了延續整個系列的行文思路，我也會涉及一些我們團隊計劃sprint的方法以及sprint過程中發生的 事情，並穿插著回答你們提出的那些問題。首先，我想說的是，不存在敏捷無需計劃的神話。可是，敏捷開發中的計劃的確和傳統軟體開發中的 計劃有著很大區別。正如我在上一篇博文中所說，我們針對利益攸關方(stakeholders)給出的上層需求創 建了帶有優先順序的產品待開發事項(product backlog)。這一帶有優先順序的工作清單形成了最基本的

前言：通過建立代碼編寫規範，形成BCB開發小組編碼約定，提高程式的可靠性、可讀性、可修改性、可維護性、一致性，保證程式碼的品質，繼承軟體開發成果，充分利用資源。提高程式的可繼承性，使開發人員之間的工作成果可以共用。軟體編碼要遵循以下原則:1.遵循開發流程，在設計的指導下進行代碼編寫。2.代碼的編寫以實現設計的功能和效能為目標，要求正確完成設計要求的功能，達到設計的效能。3.程式具有良好的程式結構，提高程式的封裝性好，減低程式的耦合程度。4.程式可讀性強，易於理解；方便調試和測試，可測試性好。5.

軟體的未來其實在很大程度上要指望軟體介面的前景如何。我們知道，電腦世界裡的介面這兩個字具有兩種眾所周知的含義：其一是指軟體本身的狹義“介面”，比如各種軟體開發API等。其二則指的是人與軟體之間的互動介面。我們把這種人-軟體之間的介面稱作“使用者介面”,也就是“UI”。這裡要討論的前一種定義：

Rational Application Developer 可以與其他 Rational 產品相整合，並提供第三方的擴充支援。這 個由兩篇文章組成的專題，給出了 Rational Application Developer 與 IBM® Rational Team Concert™ 和 IBM® Jazz™ 技術、IBM® Rational® Asset Manager、IBM® Rational®

接CS結構軟體自動升級實現（三） ：Config.java處理設定檔：　1/** *//********************************************************************　 2 * 項目名稱　　　　　　　　：rochoc<p>　 3 * 包名稱　　　　　　　　　：com.rochoc.autoupdate<p>　 4 * 檔案名稱　　　　　　　　：Config.java<p>　 5 * 編寫者　　　　　　　

一、JUnitJUnit是由Erich Gamma 和Kent Beck 編寫的一個迴歸測試架構(regression testing