軟件

做軟體也有幾年了，將學到別人的經驗，項目中自己的體驗，參加培訓的收穫一起總結一下。需求階段：首先要明確軟體項目開發完後是為瞭解決什麼問題？對於要解決的核心問題必須要明確，以後可以重點設計作為軟體的亮點。明確軟體的終端使用者是誰？有幾種類型的使用者？在進行使用者訪談的時候就會目標明確，這也是項目干係人的來源之一。訪談計劃:格式舉例 使用者訪談計劃（樣本）一、  訪談內容概述1. 業務事件：涉稅業務受理2. 瞭解涉稅業務受理的整個過程，使用者的特點，輸入、輸出與處理要點，資料量等3.

1． 測試流程首先說說測試流程，微軟的測試流程也沒什麼新的東西，和大多數的測試流程一樣。大致是先進行測試準備，然後是Testcase的編寫，然後是白盒測試（不一定每個項目都有），然後是功能測試階段，然後是驗收測試，最終release。如果看流程的話，和一般公司大同小異，沒什麼新花樣。但是我覺得值得借鑒的是兩點。第一，

        軟體工程定義：運用現代科學技術知識來設計並構造電腦程式及為開發、運行、維護這些程式所必須的相關 檔案資料。        從軟體開發的發展來看，軟體工程並不是隨著軟體開發的出現而出現，在軟體開發發展到一定階段，出現了一系列的危機，比如：                                    1.產品不符合使用者的實際需求                                     2.軟體開發生產效率提高的速度遠遠不能滿足客觀需要           

 拜讀林銳先生的《軟體工程思想》發現一段經典有句名言：“人分四類——人物，人才，人手，人渣。”    如果一個軟體公司裡上述四類人齊全了，那麼最好的分工是讓“人物”當領導，“人才”做第一線的開發人員，“人手”做行政人員，“人渣”負責行賄。    這裡只談公司的領導與開發人員“行還是不行”。“人物”畢竟是少數，“人才”可是濟濟的。舉重若輕的那類“人才”可以做領導，舉輕若重的那類人才適合做軟體開發人員。假如一群持有學士、碩士和博士文憑的畢業生到軟體公司應聘，該如何錄用呢？我的建議如下：   

績效作為公司考核員工的依據，其重要性不言而喻。管理者依據上級的目標並結合工作重點來制定績效，然後根據下屬應負的責任，將任務層層分解到責任人。如果績效做得好，員工的業績就會更好，員工就會獲得更多的獎勵，企業的凝聚力就更強了。軟體開發績效的特點相比其他行業，軟體開發的績效似乎並不好做。有一些客觀的因素，如：工作難以統計與量化；軟體各模組難易程度有時難以衡量等。尤其像敏捷開發這樣，不斷更新任務就更難以制定考核計划了。軟體開發績效的效果不理想還有一些主觀上的原因：（1）管理者大部分時間忙於技術性的工作，

   需求工程的基本任務是確定系統的目標和範圍,調查使用者的需求,分析系統必須做什麼,編寫需求規格說明書等其他相關文檔,以及需求工程審查.除此之外,還包括需求變更的控制,需求風險控制,制定需求過程的基本計劃等工作.    需求是指系統必須實現什麼的規格說明,他描述了系統的行為,特性或屬性,是在開發過程中對系統的約束.    不知道看到這樣兩個比較權威的定義,你被嚇到了沒有,我們往往是以謹慎+恐懼的態度對待官方的文檔和說明.我想寫一下自己對需求工程中各種問題的理解.  

當前軟體測試都在考慮自動化測試這個奇妙的玩意兒，很多公司或者從業者對自動化測試載入器都很迷惑，就目前來看，大部分公司基本把自動化測試列為了“雞肋”。我曾在一段時間對自動化測試也非常著迷，以至於一不小心讓自己攤上了這麼一個活，但是當我辛苦兩個月之後，把這個工具的demo展現在評審委員會面前時，他們在技術上是肯定的，但是從他們的臉上我看出了一些擔心。結合多個公司自動化測試的成敗，我得出了一些心得。　　1、開發技術實力不足　　一般公司的自動化測試載入器基本不會立項來做，主要依賴測試部門自己的開發實力，

    /// <summary>    /// 旋轉的可視驗證碼圖象    /// </summary>    public class VlidationCode    {        public enum RandomStringMode        {            /// <summary>            /// 小寫字母            /// </summary>           

軟體外包測試管理與實踐        管理是指通過計劃、組織、領導、控制等途徑去完成某個任務、達成某個目的。以此類推，軟體外包測試管理，就是指利用以上途徑，去滿足軟體外包測試工作的需求。 　　本文圍繞這一主題，主要從軟體外包測試服務提供者的角度，探討軟體外包測試專案的管理方法及實踐經驗。為了便於讀者閱讀和理解，筆者將分計劃、組織、領導、控制四個篇章來展開論述。 　　1． 軟體外包測試管理之計劃篇 　　1.1 靈活選擇外包測試服務的方式及合約類型

1．考試要求：（1）掌握資料表示、算術和邏輯運算； （2）掌握相關的應用數學、離散數學的基礎知識； （3）掌握電腦體繫結構以及各主要組件的效能和基本工作原理；  （4）掌握作業系統、程式設計語言的基礎知識，瞭解編譯器的基本知識；（5）熟練掌握常用資料結構和常用演算法；（6）熟悉資料庫、網路和多媒體的基礎知識；（7）掌握C程式設計語言，以及C++、Java、Visual Basic、Visual

 軟體架構師應該知道的 97 件事        1.客戶需求重於個人簡曆(Nitin Borwankar)        客戶需求至上。為了自己的簡曆更炫而採用新技術是沽名釣譽，往往事與願違。        2.簡化根本複雜性，消除偶發複雜性(Neal Ford)        分析問題好比撥雲見月、水落石出。        3.關鍵問題可能不是出在技術上(Mark Ramm)        團隊同心，其利斷金。     

本人只是測試心愛的Ctrl+V功能，如需跨貼追捕，自己找作者去。 轉自 http://blog.cnw.com.cn/index.php/44250/viewspace-101337 Joel的Fog Creek軟體公司換了一個辦公地點，這給了他一個實踐自己觀點的機會。在新辦公室的設計過程中，Joel說他主要考慮兩點： 1）有利於提高工作（編程）效率。程式員要思考很多東西，所以辦公環境中所有令人分心的因素都要最小化，保證程式員能夠集中注意力。

{*** 檔案名稱：uMainForm.pas* 檔案類別：delphi 代碼檔案** 檔案版本：0.1* 作    者：俞偉* 完成時間；2008-01-28* 連絡方式: yu924@hotmail.com* QQ:       183088201**}unit uMainForm;interfaceuses  Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,  Dialogs,

      從暑假學軟體工程到寒假運用其開發思想來二次開發機房收費系統，我在逐漸的清晰軟體工程的存在意義。      在這次開發中可以說將軟體工程的幾個重要過程都體現了：可行性分析、需求分析、概要設計、詳細設計、資料庫設計、測試等。並且運用了UML建模，SubVersion進行本版控制以便多人合作，Nunit進行單元測試。也接觸了部分專案管理方面的知識。      當然每個步驟目前接觸的還不是很深，但現在至少正在從一個高度向下包圍。

#define DEBUGMSG#include <windows.h>#include <windef.h>#include <string.h>#include <stdlib.h>#include <stdio.h>#include "Psapi.h"#pragma comment (lib,"Psapi.lib")#define erron GetLastError ()#define FIVE 50#define HIGH 2

Chapter 11

     三國中的諸葛亮能看破天象，對敵軍的破綻之處也更是了如指掌，死孔明嚇跑活仲達的笑話無人不知，無人不曉。作為軟體測試員就應該有孔明先生這樣的本領，測試員能該把軟體當作自己的敵人，兵法雲知己知彼方能百戰不殆。本節將總結黑箱測試中的又一常用方法——錯誤推測法。        在錯誤推測法中，測試員的角色就相當於三國中孔明的角色，測試員要根據自己的經驗，預測出軟體中哪些地方容易出現缺陷，我們應該怎樣發現缺陷，確保缺陷得以修複。    常見的輸入與輸出錯誤推測情況：     

   前面總結了軟體測試層次的各階段目標和任務等相關內容，接下來將總結軟體測試的經典方法，即黑箱測試和白盒測試。其中黑箱測試有等價分類、邊界值分析、錯誤推測和因果圖等經典分析方法，本節先介紹黑箱測試中的等價分類，也稱等價分配或等價劃分，即分步驟的把過多（無限）的測試案例減小到同樣有效小範圍過程。   

 本節主要介紹一下層次測試的第一步——單元測試。在瞭解單元測試之前先看一個簡單的主程式樹狀模組圖：        所謂模組測試就是在底層進行的測試，如，單元測試就是測試中紫色的模組。單元測試是整個測試的基礎，單元測試中發現的錯誤約佔程式總錯誤數2/3，單元測試的目標是通過對程式底層模組的靜態和動態測試使底層模組達到模組說明的要求。   單元測試主要測試5方面的的問題：