敏捷外包工程系列之四 合理選擇質量管理的等級(一)

2021-06-05 16:57:03 字數 1917 閱讀 1508

敏捷外包工程系列的第四篇(欄目目錄)。

cmmi最近沒有以往火了,原因之一是sei發現中國和印度的很多企業在級別評估上造假,尤其是高等級評估。為此sei還在4級以上做了複審的規定。

為什麼那麼多企業爭先恐後地爭搶高等級呢?因為想證明自己的質量高。

在軟體外包,或者說專案開發(而非產品研發)中,進度、質量、成本、需求這些因素雖然可能達到的最終效果有限,但各自的投入卻可能是無限的,只是每個因素都以對數曲線規律執行,任憑你投入10倍的人力物力,它只增加一倍。

所以,在投入之前,應該問自己:到底哪個是我的終極目標呢?

在軟體外包或者說專案開發領域,成本是終極目的。

因為外包或專案的終極目的是交易,是乙個以金錢購買人力的過程,如果成本超過了合同額,無論進度、質量、需求如何,交易的本質目標已經受到了傷害,甲乙雙方遲早均會為此付出代價。

因此,甲乙雙方應該審時度勢地合理選擇質量等級,來控制成本。

順便說一下產品研發的終極目的是提供功能(即專案開發中的需求),剩下的三者則為其服務。

質量管理活動大致有以下這些,並因為實施了這些活動而可以達到對應的質量管理等級:

質量控制 quality control

質量保證 (process and product) quality assurance

質量定義 quality definition

量化質量管理 quantitative quality management

根源分析與缺陷預防 causal analysis and resolution

實施質量控制的乙個典型情況是有基本的軟體測試行為,對應cmmi的1級(乙個在cmmi模型中描述過,但沒有定義的級別)。

為什麼稱之為control呢?因為測試活動發生在產品完成之後,因此它本身不能直接提公升產品的質量,但可以把產品中不好的部分檢查出來。在製造業中,不合格品檢出後會被扔掉,而軟體界則把不合格品退回重新修改。

質量控制存在侷限性:

1. 效果有限

正如我們不希望購買到被「返修」的汽車、家電一樣,「重新修改」過的軟體也是存在問題的,因為多數缺陷不是孤立的事件,而是軟體整體質量低下的乙個表象。

2. 成本高

如果一輛汽車只有完全安裝好後才知道質量如何,而一旦知道了就只能整個扔掉或完全拆開修,將是乙個很痛苦的事情。

而軟體測試正是如此,在軟體能執行之前是無法測試的,而測出了缺陷和發現了缺陷是兩碼事,得用肉眼重新「拆」開軟體,才能找到缺陷的根源。

敏捷開發中的持續整合和自動化測試可以有效降低成本高的問題,因為持續整合極大地加速了裝、拆兩個過程

加速裝的過程很好理解,為什麼說可以加速拆的過程呢?

由於每次持續整合,被「裝」進去的**很少,所以一旦測試發現問題,就能很容易地判斷問題存在的地方就是剛剛加進去的**,或至少是由這些**引起的,因而可以迅速定位問題。

這比在最終產品成型的時候才進行測試,拆的過程要快得多。

不過,既然知道持續集成是用來解決成本問題的,那麼就別投入過多的人力做持續整合本身,要問自己一些問題,來判斷持續整合是否發揮了作用,比如:

1. 專案的長度,是否長到需要中間持續整合?

如果只有1個月,估計1個月後大家拆裝的速度也未必差到**去。

2. 即使需要持續整合,應該以何種頻率和程度進行整合和測試?

切忌不要為了敏捷而敏捷。

3. 在整合後,是否順便邀請了客戶來觀摩一下當前的產品,以便提出改進?

有些改進未必是**缺陷問題,興許是需求缺陷問題。

4. 這個專案有沒有二期三期四期,是否需要把持續整合和測試環境搭建地好一點?

5. 這個專案有沒有多個客戶?(已經接近產品化了)

這影響到是否需要乙個大環境同時架設多個客戶,以便在為一家客戶修改底層後,快速檢查一下是否其他客戶受到了影響。

……

暢通工程系列

對於這題,現在還是有點蒙。不過第二題把條件轉換成 若道路已修建,則費用為0 剩下的就是查詢最小生成樹的問題 瞬間思路就清晰了。感覺還是最小生成樹沒有掌握好。如下 include include using namespace std int pre 105 int cost 105 struct n...

暢通工程系列相關題型

上週花了一周多的時間看了最小生成樹,最短路,並查集這一塊內容,這是上週新學的知識點,時間拉的確實有點長,尤其是1875那一題卡了很久,用兩種方法寫比較混亂,雖然也是花了一周多的時間,但是也只會寫寫這些模板題,而且對於這些容易把 摻雜在一起寫,思路邏輯不清,這一點需要自己多去找找原因,理清思路。ac ...

軟體工程系列 詳細設計

目錄 詳細設計階段是邏輯上將系統的每個功能都設計出來,並保證設計出的處理過程應該盡可能的簡明易懂。結構化程式設計 定義 如果乙個程式的 塊僅僅通過順序 選擇和迴圈這3種基本控制進行連線,並且只有乙個入口和乙個出口,則稱這 個程式是結構化的。結構化程式設計的3種基本結構 順序 選擇 迴圈。程式流程圖 ...