軟體專案管理的質量保證(轉)

ger8發表於2007-08-15
摘要:專案開發根據進度分為需求、設計、開發、測試等各個階段,質量保證工作始終貫穿各階段,同時又必須根據每個階段特點採取相應的措施。


  軟體工程專案管理是一個系統工程,軟體工程專案管理的主要目標是保證專案在規定時間內高質量地完成。專案管理包括了專案組開發各階段的人員結構的配置,質量控制的實施方略,內部文件和產品文件的組織編寫等多項工作,其中質量控制方法具有軟體開發的特點。

  專案開發根據進度分為需求、設計、開發、測試等各個階段,質量保證工作始終貫穿各階段,同時又必須根據每個階段特點採取相應的措施。

  需求分析

  需求分析是開發人員對系統需要做什麼和如何做的定義過程。從系統分析的經驗來看,這個過程往往是個循序漸進的過程,一次性對系統形成完整的認識是困難的。只有不斷地和客戶領域專家進行交流確認,方能逐步明瞭使用者的需求。從系統開發的過程得知,系統分析時犯下的錯誤,會在接下來的階段被成倍的放大,越是在開發的後期,糾正分析時犯下的錯誤所花費的代價越是昂貴,也越發影響系統的工期和系統的質量。。

  在具體專案中,一般的做法有兩種:一是請領域專家參與到系統開發的早期階段;二是開發系統原型,原型包括功能性的原型和使用者介面性的原型,也可以是二者混合的原型,用這些原型確認使用者的需求。讓領域專家參與開發的早期階段,是保證分析人員有充足的時間和領域專家進行充分的交流和確認。在這個階段,原型可能在提交到使用者之前,首先被領域專家確認,這樣保證了原型被認可的程度和認可過程耗費的時間儘可能的短,從而在提高效率的同時保證了質量。

  在開發方內部還有三項保證措施:系統分析委員會保證系統分析集思廣益;質量監督組對分析工作的監督;技術支援人員參與需求調研。

  分析委員會的意義在於任何分析人員在提交其所分析部分的分析說明書前,必須透過委員會的共同審議,委員會的成員根據各自的分析經驗和自身所分析的部分對他人的分析報告提出質疑。如此審議過後保證了各部分間相互關聯的部分被明確定義,避免了由於“疏忽”造成系統在後期進行整合時出現較嚴重的系統鴻溝或系統重疊。

  質量監督組在專案的任何階段都要提出監督計劃。按照監督計劃分配相應的資源來保證某階段的開發質量。分析階段的監督計劃會在分析任務之前被專案經理、專案負責人、系統分析員以及技術支援所瞭解。為保證分析工作高質量進行,同時分析工作又不被過分打擾,質量監督組則主要針對《系統分析報告》進行復審,並在認為確實有必要的情況下才召開質量複審會議。質量複審會議的主要參與者是專案經理、專案負責人、分析人員和質量監督組組長。會議的主要議題是提出質量質疑,給出改進建議即可。具體是否存在質量問題,是否需要改進,不在會議中進行討論,以此保證了會議參與的人數較少,會議的時間儘可能的短。

  系統實現

  實現也就是程式碼的生產過程。生產的類別有類的生產,元件的生產,構件的生產,應用系統的整合,以及各種測試用例的生產。為了能夠提高生產的質量,我們將生產的程式人員按職能分成兩組,測試用例的生產和測試用例生產,也就是說如果某個程式設計師生產了某個元件,則其測試用例不能再由該程式設計師來生產,但他可以生產其他元件的測試用例。這樣交叉生產更容易發現元件的存在的問題。測試人員按照測試用例來測試元件的各項指標提出測試報告。

  為了控制系統開發過程中的往復,不至於產生重大過失和往復的泛濫,文件組和質量監督組協同完成軟體開發的配置管理。

  軟體配置管理的目的在於控制軟體開發過程中的“變化”,這種變化可能是外部引起的,如需求的變化。也可能是來自於內部的變化,如早期設計的某個部件不夠完備,需要修改等。為了控制這些變化,把變化引起的波動儘可能的控制在有限的範圍內。

  配置項是指需要進行控制的任何文件單元,它可能是需求說明報告,也可能是需求說明報告的某個點。在本專案中需要控制的內部配置項包括需求報告,設計報告,元件程式碼,元件介面文件,構件及相關構件。

  測試

  測試組的工作被分成若干階段,不同階段的劃分是以保證軟體質量的不同指標為目標的。

  測試的軟體指標分別包括如下幾點:

  軟體的正確性:正確性測試主要是測試軟體的功能是否被正確的實現。測試的方式主要是按照功能的要求按照給定的輸入,看是否有給定的輸出,在非標稱輸入時,輸出是否異常等。同時也可以測試軟體的功能是否實現或完整實現。

  效能指標:該專案對效能的要求非同一般的軟體專案。效能測試往往包含了壓力測試、攻擊性測試等測試,軟體所能承受的極限是多少,一般來將軟體的極限應當高出使用者要求的效能,各種指標也應當為使用者所瞭解。

  易用性:軟體的使用介面在設計實現的時候應當設法使之與功能的實現相脫離。脫離的原因在於易用性是透過友好的介面實現的。然而讓開發人員以使用者的角度來確定軟體是否易用是件非常困難的事情,在確定使用介面時往往需要多次的反覆修改,甚至只能在軟體的最後交付之前或使用者使用一段時間之後才被提出來。

  鑑於這種特點,軟體在開發的不同階段都作了相應的保證措施,比如在軟體需求界定的時候請領域專家參與,在軟體設計階段,讓功能的實現儘可能地包含在軟體的元件之中,也就是沒有介面要求的底層實現。介面的實現僅僅依賴於一個資料介面,介面僅僅負責將使用者輸入的資料送到指定的資料塊中,用於顯示的資料也在指定的資料塊中提取,只要保證資料塊被互斥的訪問就可以了。有了這樣的設計結構,軟體的易用性也就相當容易保證了。當測試中發現易用性的問題時,軟體不會傷到筋骨,皮毛的修改總是非常容易的。
[@more@]

來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/7839396/viewspace-958366/,如需轉載,請註明出處,否則將追究法律責任。

相關文章