國內應用軟體開發管理的探討 (轉)

國內應用軟體開發管理的探討 (轉)[@more@]

國內應用開發管理的探討

雷劍文 曹衛華

隨著行業生產的擴大和提高，對企業運作的管理和的要求也在不斷提高。一個好的適合企業管理的應用軟體可以給企業帶來成本，人力等資源的大大減低，從而為企業帶來經濟效益。而企業對應用軟體的需求又帶來一種局面，即企業不願為接受外面已有的應用軟體來改變自己已經成型的管理方式，又確實需要進一步藉助的應用來提高企業的管理水平。於是企業根據自己的管理需要來開發應用軟體，一旦把軟體開發侷限於企業內部，開發出來的應用軟體質量必然受到員的水平和所限。怎麼讓企業利用企業內部已有程式設計師來更好地為企業開發好的應用軟體呢?以下我們將從企業應用軟體開發管理的角度加以探討。

一、應用軟體開發的主體程式設計師

應用軟體發展到今天，已積累了大量好的經驗值得我們學習，這裡就不再贅述。由於國內企業應用軟體開發程式設計師的水平高低不同，在這種情形下開發質量和穩定性較好的企業應用軟體是比較困難的，怎樣儘可能地使應用軟體開發的數量和質量不受程式設計師技術差異的影響呢?當然不需要每一個參與該應用軟體開發的程式設計師都具備了各項能力以後才去完成，只需員具備解決技術難題的能力，合理分配工作來完成。技術在進步，人類也在進步，透過完成具體工作來不斷地提高各個成員的素質，在技術提高的同時，提高技術實施的水平。

例如：先進的企業生產線在沒有飽和的情況下，產量和生產力會隨著工人(技術水平相似)數增加而呈顯著正值增加。其簡單的數學圖形可用圖1表示。

在面向的第四代語言廣泛應用的今天，在企業現有程式設計師的基礎上，完全可以透過改進一些應用軟體開發的管理方法來提高企業應用軟體的開發能力。下面是我們透過實踐而產生的一些觀點，拿出來和同行們探討一下。

讓我們簡單地假設把這種企業應用軟體開發方法同生產線加工生產作一比較，如下圖所示：

工廠生產線作業 企業應用軟體開發作業

開始 開始
流水線設計 需求分析
流水線 資訊流分析
系統員 流水線 設計
流水線執行 應用軟體開發分析
流水線維護 各種規範的定義
物件類設計及再用性封裝
簡單作業培訓 各種定義熟悉
程式設計師 生產線上實習已定義的物件類使用瞭解
組裝加工產品各種重複工作的完成
規範定義標準檢查
系統員 質量檢驗和控制論 模組執行檢查
整體品質控制檢查
程式設計師 包裝完成 系統編譯執行
完成 投入使用

可以看出，一般的先進生產線，若在非飽和狀態生產能力會隨著員工的增加而正向線性增加。在此員工一般不需要特別培訓，即一個在該生產線上工作五年的員工和一個工作一個月的員工的工作能力相差無幾，因為他們的工作只是在生產線上加工，生產線的維護和改造則由技術工程人員完成，再業看看企業應用軟體開發的管理方法和改進的情形。

二、企業應用軟體開發的內部調節管理

在企業內部軟體開發的數量和質量與程式設計師數量會是一個怎樣的關係呢?這裡假設一個各方面知識和能力都合格的程式設計師值數為1，單方面知識和能力合格值數0.5，那麼我們可以為企業軟體開發情況做一個分析：

1、理想情況為軟體開發的數量和質量隨著值數為1的程式設計師的數量變化而成正比變化：
1=1
1+1=2
1+1+1=3
1+1+1+1=4
…
1+1+…+1=n
這種情況解釋為真空，只可能出現在一般的專業軟體開發公司。在企業內部我們就不必過多分析。

2.一般情況為軟體開發的數量和質量隨著值數0.5的程式設計師的數量變化而成正比變化：
0.5=0.5
0.5+0.5<1
0.5+…+0.5=1

這種情況在企業應用軟體開發中較為普遍，如果值數為0.5的程式設計師的知識領域是互補的，又是較為理想的，有可能在積級配合下達到甚至超過值數為1的程式設計師所完成的工作。如果他們的知識領域是相同的，又為這種情況下的最差組合，完成的軟體數量和質量就達不到企業發展的要求。

3.較差情況為軟體開發的數量和質量隨著值數為小於0.5的程式設計師的數量增加而幾乎不發生變化：
0.4=0.4
0.4+0.3=0.4
0.4+…+0.4=0.5

這種情況在企業應用軟體發展初期較為普遍，即使值數小於0.5的程式設計師的知識領域是互補的，而且是在理想的積級配合下，達到甚至超過值數為1的程式設計師所完成的工作的可能性也是極小的。如果他們的知識領域是相同的，又為這種情況的最差組合，完成的軟體是列加遠遠達不到企業發展的要求。

4.經濟而又適合企業的組合(為現代企業所接納)是必須有一名值數為1的系統分析員，加上值數低的程式設計師組合。怎樣更好地發揮這種組合的效率，是我們議論的主題。

從圖2可以看出，一個企業的軟體開發程式設計師的值數(完成程式設計技術難度)高低各不相同，這是實際情況。當然我們這時是從某一個時刻靜止的角度看去，隨著程式設計師值數的增加我們以下的觀點仍然成立。如果程式開發過程中的工作安排是根據各人的實際情況合理分配的，那麼整個開發過程基本上會按計劃逐步完成，否則會出現許多方面的問題，影響整個計劃實現的進度，怎親才算合理呢?我們知道應有軟體發展到今天，其開發過程已是一個有計劃的技術性團體合作的過程，在對各個程式設計師技術能力要標的同時，對整個開發團體的協同作戰能力也是一個考驗。物件導向式程式設計為這種團體工程提供優質保障，從管理的角度，在圖2的基礎上我們增加了一個企業程式設計師在軟體開發時所應完成的技術難度線。如圖3所示。

由於應用軟體的開發是一個技術要求較高的工作，如圖3所示，很明顯如果把一些技術難度係數高於某些程式設計師值數的工作安排給他們，必然會使整個計劃的實施受到他們工作完成的質量和數量的影響，從而使計劃失去意義。怎樣解決由於技術難度的分配帶來的問題?傳統的方法是著力於對那些值數較低的程式設計師進行培訓，提高他們完成開發軟體技術難度所需的值數。我們知道這是需要大量時間、精力和資金作保障的。同時由於人員日趨變動的社會經濟的發展，企業能否認可和等待，其本身就使這種方法的實效大打折扣。我們找到了另外一種可行的方法，那就是說既然技術難度不能統一分配，我們把一般程式設計師所需完成工作的技術難度線降低，而把系統分析員的技術難度線增高，如圖4所示。

圖4所示的管理實施效果已在插圖4企業實施並達到。它不僅使得每個一般程式設計師能夠按計劃保質保量地完成任務，而且使得企業應用軟體的開發能夠有效地進行(基本上保持現狀)。當然其中的關鍵是系統分析員完成技術難度大的工作，他要完成技術核心和質量控制的工作。這在物件導向式程式設計的現在較容易實施。就像開發工個軟體提供的系統物件一樣，一些適合企業應用的再用性較強的自定久物件和模組由系統分析員完成並提供給一般的程式設計師來使用。這不僅達到降低他們工作的技術難度，而且為企業應用統一的規範性作出了定義。不僅使得應用軟體的質量和穩定性得到保障，而且使軟體的維護變得更為簡單和容易。這種方法很好地解決了企業應用軟體開發在高速發展變化的情形下的實施。如果這種方法能夠有效實施，就會使得企業應用軟體的開發走上良性迴圈的軌道。雖然程式設計師完成的質術難度較低的工作，但是他閃可置身於整個互動工程之中，學習到的卻是多方面的知識，不難想象在這種工程迴圈完成之中得來的能力提高是極有價值的。這種方法在我們企業中運用並取得實效。但是這種方法也需進一步完善，如很明顯的，其中某些值數較高的程式設計師的資源和時間未能得到較好的利用，而又增加了系統分析員的工作量。可以將一些技術難度大的工作分配給那些值數較高的程式設計師去完成(但是一定要注意規範性和一致性)，如圖5所示。

可以看出，對於不同值數的程式設計師，他們工作的質量和數量的標準的高低是不同的。這樣使得工作的安排能根據個人的值數各盡所能地進行，人盡其才地工作使得整個工作計劃的圓滿完成變為可能。該圖中的曲線是動態的，也就是各個時期個人的值數是不同的，值數增長幅度也是不同的，所以曲線會隨著時間的推移不斷地向上移動。這就要求客觀正確地定位各個時期各個程式設計師的值數，以動態地調整最佳曲線的變化。

三、在實際工作中從應用軟體開發管理角度來看用這種管理方法達到其預計效果的幾個方面

1.應用軟體的開發應該是規範的，使得應用軟體開工作能夠很容易地被別人接手和修改。由於開發出的軟體是依照一定規則的物件組合，所以相當於符合標準，而只要是群體開發軟體，標準又是非常重要的，標準其實在應用軟體開發的程式設計師之間起到了相互溝通的橋樑作用。

2.由於規範性很強，應用軟體開發的關鍵就落到了設計規範化的物件類上，如果擁有優良的物件類(就像工廠擁有了先進的生產線)來繼承和繁衍，軟體開發的技術難度就可降低，從而使得不同層次的軟體開發程式設計師都能很快地投入工作，就像工廠生產線新上崗的工人一樣。

3.軟體開發的生產力與程式設計師是成正向線性變化的。怎樣可以做到呢?因為技術難題都由系統分析員來解決完成，使得技術要求水平降低，一般程式設計師做一些重複、再用、繼承、組合等技術難度較低的工作，使得他們的工作效率大大增高，從而使得整個企業應用軟體開發生產力大為增高。例圖6所示。

事實上我們只不過把一些問題具體化、物件化、關鍵的事情還是要由經驗豐富的人員來做。比如對資料庫資訊的SAVE、DELETE、INSERT等的操作完整性(無論從資料庫完整性還是客戶端應用程式的完整性實現)工作。而增加一般程式設計師的數量從而達到增加應用軟體開發的生產力，不論從經濟上還是從管理上都是值得的。而透過一個又一個工作實踐來提高程式設計師的技術水平，隨之會問下一個起點邁進。

四、企業軟體開發管理中應注意的幾個方面

在物件導向程式設計的第四代語言中，可以充分利用物件的繼承性、封裝性、多型性來提高軟體開發效率，使得企業為生產和管理服務。這裡簡單論述一下。

強再用性

我們知道物件的繼承性允許新的物件類從已建立的物件類中透過繼承得到，繼承所有屬性、變數、、結構、控制和程式。在祖先物件類基礎上的覆蓋或擴充套件，不但能提高軟體開發效率，而且使得物件的應用保持一致性、減少出錯或除錯維護變得容易簡單。例如：在POWERBUILD中，因為視窗、選單、物件均可繼承，一個多人合作的軟體開發就變得輕鬆容易許多，一些祖先物件的建立維護和一些理難度大的問題出值數較高的程式設計師來完成，以保證質量效能，那些大量重複的、較為基本的工作則由一般程式設計師來完成。可根據個人的情況，調整出個人的最佳效率點。所以說，開發出好的祖先物件和建立良好的思維方式是企業軟體開發的成敗關鍵。

好完整性

在客戶/伺服器系統應用中，資料及資料處理完整性是保證資訊準確無誤的重要環節。所以在軟體開發中對這一點的邏輯要求是最嚴密的。例如，在一個事務處理過程中，可能對多個表進行修改。如果在中間發生錯誤時，應該放棄整個處理而不是其中的一個過程，返回到開始的狀態以保證操作的完整性，從而使得資料及資料處理的完整性得到保證。

1.運算或計算燈錯誤。這類錯誤較為分散，不易檢錯和修改，應儘可能把計算的處理過程採用物件函式處理。

2.區域性變數。儘可能地多使用區域性變數。這樣一來把一些事物的處理過程儘量區域性化，使得軟體的檢錯和修復變得更為容易。

可擴充套件性

一個事物是不斷變化的，對這些事物統計和管理的電腦軟體也應該是可以隨之變化。因此一個好的軟體程式的可擴充套件也是很重要的一個方面，也要加以分析和應用。例如：如果是對人類性別的分析，因為它的變化是固定的，非男即女。所以我們用IF THEN語句來規範。如果是對變化狀態多於兩種且狀態是固定的事物，選擇IF THEN或CASE就看個人的所好和專長。如果是對變化狀態有不斷增加的新狀態出現的事物，我們應以CASE語句來加以規範，以便於以後的擴充套件。

易維護性

因為使用了物件的繼承性，對祖先物件的修改直接影響到其繼承物件，使得軟體程式的維護性得到一定程式的提高，但相同的語法和邏輯規定又使得多人合作開發的軟體和維護性得到保證，不會因為各自特有的思想和作風而受到限制，也為相互的提高彌補提供了可能性。

同樣，因為使用了物件的封裝性，即把資料和程式封裝在物件中，使之成為物件類的一部分，不但遮蔽了物件程式設計的複雜難度，又提高了程式程式碼的質量而使得維護容易。因為修改被封裝在物件上的程式不會影響其他的物件。

因為應用軟體的開發不是由一個人而是由一個可能變化的群體合作完成，即使同一個人在不同的時期也會有不同的風格，所以保持高度的一致性是群體合作的關鍵之一，也是修復和改善的保障。

那些經常變化、需要集中管理和控制的運算、重複又要求一定執行效率的企業規則儘可能地放在伺服器端(透過、過程)。隨著企業規則的不斷變化而需要作的修改和維護更為容易，而且它有高的執行效率，使得運算易於管理和控制。因為它的變動邏輯與應用軟體是相互獨立的。

例如，企業工資管理中的獎金計算方法(根據崗位、出勤等規定計算個人獎金的企業規則)，它可能隨著企業經營狀況的變化而變化，它的實現要放在伺服器端(即資料庫段)。

結

本文提出了一些企業應用軟體開發管理上的想法和觀點，並在實際工作中加以應用，而且取得較好的實效。其思想不難理解，就像一些系統軟體現在提供的優良的開發環一樣(系統提供的物件、函式等)。我們透過不斷建立和積累自定義物件及其類業不斷改善企業內部應用軟體的開發環境，加快了企業應用軟體的開發程式。本文中不足之處，歡迎批評指正。