軟體開發所必須做的事情的清單

2021-04-13 08:55:20 字數 3022 閱讀 9292

軟體開發所必須做的事情的清單

雖然我並不是乙個很有經驗的軟體開發管理者,但是在這幾年的摸爬滾打中還是有一些自己的心得的,下面先記錄下來免得忘掉。 1.

要有**歸檔庫

**歸檔庫是在開發中必須有有的,現在我們一般使用

vss、

clearcase

以及cvs

(或者subversion

)管理我們的**與文件與我們的安裝包。

從實際的使用上看

vss不能滿足大規模使用的要去(同時使用的人越多

vss的速度就越慢,人們的耐性越少)

clearcase

太大也太貴了,我們現在的使用基本上把

clearcase

當成能切分支的

vss在用,不知道知道這樣的用法,

relation

公司的那幫人會不會暈倒:)

建議使用

cvs,這個便宜,簡單,並且我們所需要的任何功能都是可以提供的。

我個人建議文件與**庫應該是合一的,這樣可以減少文件與**不一致的可能性。

下面列一下我個人認為的一下重要的事情:

(a)**、文件等的修改一定要增加修訂記錄。要明確下面的資訊

什麼人、什麼事、在什麼地方、修改了什麼。只有增加了修訂記錄這個歸檔庫才真正的發揮了他的作用。

(b)**轉測試,版本歸檔一定要打

label

。這樣可以簡單的去到乙個以前的版本定位問題

(c)**/

文件/發布包的許可權需要控制,按照最小授權的原則進行授權。

(d)配置庫要定期備份,防止資料丟失的發生。配置庫管理需要有專人負責。 2.

要有自動歸檔工具

自動歸檔工具要保證可以從原始的**直接生成我們的安裝盤,並能記錄中間產生的問題。發給專案組進行處理。

這裡需要強調的就是從源**開始的,而不是從其中的某乙個狀態。

**歸檔要能在夜裡自動進行也能手工觸發。從我個人的感覺上看,使用

gun make

工具與shell

進行處理是一種比較好的方式,在

windows

還是有一些不舒服的地方的。乙個專案組要保證有一組機器能專門的進行環境的搭建。 3.

要有自動st、

ut測試工具 自動

st、ut工具是版本開發的乙個關鍵的部分,只要能做到這兩點我們就可以很容易的能聚焦於軟體的質量。 ut

、st工具要在軟體的設計時就要考慮,真正的軟體是設計出來的。

自動st、ut

測試工具與自動歸檔工具構成乙個統一的整體。每天晚上都要有下面的乙個過程

(a)從配置庫上去最新的**

(b)在目標機器上編譯(編譯時自動執行ut)

(c)部署到測試機器上

(d)自動執行st

(e)將結果傳送給專案組成員

實際上如果完成上面的部分我們需要的只不過是每天喝著咖啡看郵件了。

這個過程中發生的問題需要強制在當天能處理完畢,防止在第二天也出現類似的問題。

在實際的測試與實際執行中發現的問題要同步的更新我們的自動測試用例庫

4.要有bug

管理工具

bug管理工具是乙個比較高的要求。我們最核心的目的就是要保證問題的閉環,這裡不只是乙個

bug管理的問題,實際上我們所有的任務都是可以安裝這個方法來管理的。

現在最好的工具就是

notes

的工作流,但是也有其不好的地方

--太慢!我們不必強求形式

只要能達成閉環就可以了。下面說一下乙個簡單的

bug單處理流程

(a)bug被測試人員建立

(b)測試經理審核

(c)開發人員定位

(d)專案經理審核

(e)開發人員設計方案

(f)se/tl審核

(g)授權修改

(h)修改實施

(i)se/tl審核

(j)授權歸檔

(k)分配測試人員回歸

(l)回歸測試

(m)bug單關閉

實際的流程包括單不限於上面的步驟

5.要有需求管理工具

需求管理工具保證所有的需求被充分的實現而不被遺漏

需求管理包括:

原始需求(包需求)

分配需求

設計需求

我們要從原始的需求一致到最後的設計需求完整的管理,包括在後面需要增加相應的測試用力,並記錄測試結果這樣在最後交付的時候就可以清楚我們已經實現了什麼東西,什麼東西還沒有實現。

6.要有詳細設計文件

要有詳細的設計文件,從系統、子系統、模組、物件各個層面上都要有明確的分解。我不喜歡正式的設計規格、需求規格、概要設計與詳細設計這樣的流程。上面的這些文件實際上都是描述的同一件事情,只是關注點與層次上是不一樣。

我認為要抓住核心,只要能提供乙個能讓乙個完全不懂這個系統的人能在

2天之內能寫相應的**就可以了。

7.**對比工具

**比對工具是我認為最好的工具,有很多問題都是在這個工具下面被發現了,我感覺 bc

是最好的。這裡不強求使用哪種工具,但是這種工具是必須的。

8.**靜態與動態檢查工具

pclint

、purify

這樣的**檢查工具是必須的,這些工具的使用也應該做到在每天的自動構建中執行,並記錄詳細的結果。有問題必須修改,不過要強調的是在寫**的時候就要使用這些工具進行處理了。

按照嚴格的原則沒有經過靜態處理的**是不能進行編譯的。

9.單獨的測試

要有乙個單獨的測試來測試最後的版本,測試的入口應該是原始的需求。這樣可以減少因為思維定勢導致的問題。測試過程是乙個降低總擁有成本的過程,是乙個窗在價值的過程。

10.經驗與資料的收集

專案組中遇到的問題,生產率應該被自動記錄下來,並在以後的過程中自動執行之。這裡關注點我個人認為如下 l

經驗文件的總結 l

**生產率的度量 l

缺陷密度的度量 l

需求穩定度的度量 l

進度的跟蹤

。。。上面是我在實際的專案中的一點經驗,現在先寫一些,實際上還有很多的事情需要確認,比如嚴格的同行評審等,以後再完善。

軟體開發必須的文件

軟體 文件 程式 資料。我認為文件是軟體的核心。沒有文件,開發的程式將會很粗糙,而且難於維護,這樣的軟體是沒有生命力的。文件是依據軟體的階段而產生的。根據軟體開發的幾個階段 專案開發計畫,軟體需求定義,軟體總體設計,軟體編碼設計,軟體測試計畫,軟體執行與維護。文件階段 可行性研究,專案開發計畫,軟體...

情侶必須做的事情

要和你一起去唱ktv,我們還要一起甜蜜的情歌對唱,然後錄下來一遍遍回味。要和你一起去逛宜家,一起計畫我們以後的房子要怎麼布置,然後再買一些家居用品,努力和你到白頭。洗完頭髮之後要讓你給我吹頭髮,吹風機轟隆隆的聲音和你輕柔捧著我頭髮的樣子,都是你對我滿分的愛。要和你一起去玩密室逃脫,經歷重重關卡之後迎...

軟體開發架構必須了解的知識

兩個程式之間通訊的應用大致可以分為兩種 第二種是web類程式 使用者只需要瀏覽器即可訪問程式。常見的web類應用程式 而這兩個分類又對應了兩個軟體開發的架構 服務端 要一直執行著給別人提供服務的機器 電腦 伺服器 客戶端與服務端的大致區別 一般客戶端負責和使用者的互動,服務端負責資料儲存。c s即 ...