軟件工程項目開發(fā)各階段的質(zhì)量保證

軟件工程項目開發(fā)各階段的質(zhì)量保證軟件工程項目開發(fā)各階段的質(zhì)量保證軟件工程項目開發(fā)各階段的質(zhì)量保證、需求剖析需求剖析是開發(fā)人員對系統(tǒng)需要做什么和怎樣做的定義過程。從系統(tǒng)剖析的經(jīng)驗來看，這個過程經(jīng)常是個次序漸進的過程，一次性對系統(tǒng)形成完滿的認識是困難的。只有不斷地和客戶領(lǐng)域?qū)＜疫M行交流確認，方能漸漸了然用戶的需求。從系統(tǒng)開發(fā)的過程得知，系統(tǒng)剖析時犯下的錯誤，會在接下來的階段被成倍的放大，越是在開發(fā)的后期，糾正剖析時犯下的錯誤所開銷的代價越是昂貴，也更為影響系統(tǒng)的工期和系統(tǒng)的質(zhì)量。解決系統(tǒng)剖析錯誤的方法我們公司平時采用邀請用戶參加進行需求評定，爾后對其用戶的建議由質(zhì)保成員追蹤檢測可否歸入需求規(guī)格說明書，同時與用戶簽字確認形成需求基線，交由配置管理員放入配置管理庫。誠然盡早的邀請用戶參加，依舊防備不了項目進行中用戶的需求更正央求。對于開發(fā)過程存在的需求變動，我們要求用戶填寫更正申請單發(fā)送給項目配置管理員，在經(jīng)過配置員轉(zhuǎn)交質(zhì)保小組，負責組織專家小組和項目組成員一同討論推行更正的可行性及推行后所帶來的影響，小的更正則直接記錄入更正記錄原因剖析項細風險項欄，大的更正則需要形成正式的更正報告，無論那種更正都需要對相應的文檔推行同步更正（包括需求規(guī)格說明書、詳細設計文檔、安裝手冊、操作手冊等）。但是對于無法實現(xiàn)或是更正會帶來巨大的影響而將致使進度的延期，這時，我們將更正報告提交給用戶或邀請用戶進行協(xié)調(diào)會議，討論更正棄取問題或是項目進度更正問題。決定更正此后，由項目經(jīng)理組織推行更正，測試人員檢測更正結(jié)果，而質(zhì)保小組成員監(jiān)察更正推行過程并協(xié)助配置管理員對更正后的成就物進行版本控制。更正推行完后，上線前還需要指定人員協(xié)助用戶一同測試并由用戶簽字后贊成方可上線。、系統(tǒng)設計優(yōu)異的系統(tǒng)結(jié)構(gòu)應當具備可擴展性和可配置性，而好的系統(tǒng)結(jié)構(gòu)則需要好的設計方法，自然設計選型成為了系統(tǒng)設計首要的工作，終究是采用哪一種設計方法好呢?對于設計選型不能夠混作一談，需要針對項目的結(jié)構(gòu)、項目的特點和用戶的需求來剖析，同樣也要考慮到參加項目小組成員的素質(zhì)，若是其中大部分都沒有從事過面向?qū)ο蟮脑O計且項目進對緊迫，這樣沒有節(jié)余的時間來培訓小組成員來掌握面向?qū)ο蟮脑O計方法，只管眾所周知面向?qū)ο笤O計方法的優(yōu)勢，我們?nèi)允遣蝗绮捎妹嫦蜻^程的方式（除用戶指定開發(fā)設計方式外）能夠減少項目擔當?shù)募夹g(shù)風險。我們公司有過一個項目，用戶指定需要采用面向?qū)ο笃饰?、設計和開發(fā)，且開發(fā)周期短，在無賴的情況下，項目小組只能采用面向?qū)ο蟮能浖_發(fā)過程，由于項目小組很少從事過面向?qū)ο蟮拈_發(fā)，經(jīng)驗缺乏，致使項目上馬后項目進度延緩，項目沒有達到預期的收效。針對此次開發(fā)，我們剖析其原因，發(fā)現(xiàn)小組成員在開發(fā)過程中對于新技術(shù)互相交流少，各自有各自的理解和想法，造成理解上的不一致性，致使工作重復性高，滯后項目進度。建議解決方法是項目組成員采用集中辦公，分塊學習，學習的成就馬上向項目相關(guān)人員宣布，再由配置管理員對其宣布的文檔進行整理、規(guī)類放入配置庫以供大家共享。這樣方便大家的互相學習，減少重復的工作。在此次開發(fā)中我們公司從管理人員、設計人員到開發(fā)人員都吸取了很多教訓，同時經(jīng)過此次項目的開發(fā)，小組成員也積累了豐富的面向?qū)ο蟮拈_發(fā)經(jīng)驗。除設計選型，還有一個簡單被忽略的問題，就是公共類開發(fā)。公共類開發(fā)能夠減少工作中的重復工作，降低開發(fā)成本。這要求我們再設計階段經(jīng)過對用戶需求的認真研究，盡可能的鑒別出公共類，并進行定義指定專人負責設計通知其他設計人員，以減少重復工作。對于項目組供應的設計文檔，由質(zhì)保小組組織技術(shù)專家、項目組設計人員、開發(fā)人員和測試人員對其設計文檔的評審，檢測設計文檔對其下一階段工作的可行性，實時發(fā)現(xiàn)設計中可能存在的錯誤，降低項目開發(fā)風險，同時保證設計文檔能為開發(fā)人員、測試人員供應確實的指導。對于可復用的設計進行提取作為公共庫設計和開發(fā)，供應項目組或整個公司重用。最后交由配置管理員進行設計文檔的版本控制。、實現(xiàn)實現(xiàn)也就是代碼的生產(chǎn)過程。這里不只包括代碼的產(chǎn)生，同時也包括測試用例的產(chǎn)生。針對上一階段供應詳細設計，程序員開始編碼而且調(diào)試程序，測試人員則依照設計進行測試用例的設計，設計出來的用例需要獲得項目組成員認可由項目經(jīng)理審察經(jīng)過才能進入配置庫。同時程序員調(diào)試完程序提交測試人員進行程序正確性檢測。、文檔管理文檔保護主若是配置管理小組的工作。文檔從用途上分主要分為內(nèi)部文檔和外面文檔。內(nèi)部文檔包括：項目開發(fā)計劃；需求剖析；系統(tǒng)結(jié)構(gòu)設計說明；詳細設計說明；構(gòu)件索引；構(gòu)件成分說明；構(gòu)件接口及調(diào)用說明；組件索引；組件接口及調(diào)用說明；類索引；類屬性及方法說明；測試報告；測試統(tǒng)計報告；質(zhì)量監(jiān)察報告；源代碼；文檔分類版本索引；軟件安裝打包文件。外面文檔主要包括：軟件安裝手冊；軟件操作手冊；在線幫助；系統(tǒng)性能指標報告；系統(tǒng)操作索引。怎樣保證文檔的全面性，使其真切為項目的進度供應保證，又不由于文檔的寫作而耽誤項目的進度，這依舊是一個比較難解決的問題。解決此問題，其核心依舊是個"度"的問題。在本項目的開發(fā)中，配置管理小組的一個特別重要的任務仍是書寫文檔規(guī)范和文檔模板。當有文檔模板后需要書寫文檔的人員只剩下"填空"的工作，從某種意義上講，書寫文檔的速度會加快。若是書寫文檔的人員認為文檔的更認真的部分能夠由他人幫助達成，則該文檔即交由他人達成，但此時文檔其實不算被正式提交，當他人書寫達成此后，必定由文檔的初寫者進行復審，復審通過后方能夠正式提交，進入軟件配置管理能夠由他人幫助達成，則該文檔即交由他人達成，但此時文檔其實不算被正式提交，當他人書寫達成此后，必定由文檔的初寫者進行復審，復審通過后方能夠正式提交，進入軟件配置管理的循環(huán)中。配置管理小組真切核心的工作是對文檔的組織管理。依照文檔的不同樣，文檔的本源也不同樣，有些是經(jīng)過質(zhì)量保證小組經(jīng)過復審此后轉(zhuǎn)交給配置管理小組，有些則會直接從文檔的出處到達配置管理小組。文檔的管理是一個特別煩雜的工作，但是長久來看它不只使項目的開發(fā)對單個主要人員的依賴減少，進而減少人員流動給項目的帶來的風險，更重要的是在項目進行到后百分之十的時候起到拉動項目的作用。從過去做大項目的經(jīng)驗來看，寫作文檔在項目開發(fā)的早期可能會使項目的進度比起不寫文檔要稍慢，但隨著項目的進展，各個部門需要配合越來越多，開發(fā)者越來越需要知道其他人員的開發(fā)思路和開發(fā)過程，才能使自己的開發(fā)向前推進。一個顯然的例子就是系統(tǒng)整合，也許某些環(huán)節(jié)是建立在其他環(huán)節(jié)達成的基礎之上時，就更展現(xiàn)出文檔交流的正確性和高效性。、系統(tǒng)保護質(zhì)量保證在我們公司，保護小組的任務一方面是保證對項目客戶的追蹤服務，另一方面是保證該項目其他的開發(fā)人員從項目中趕忙的解脫出來以便投入到下一個項目的開發(fā)中。所過去常項目保護小組成員主要由項目組的少部分開發(fā)人員擔當達成。他們不只認識軟件的核心內(nèi)容，而且與客戶也不陌生，以便能夠以最快的速度修正錯誤。對于一般性的錯誤，如操作不當?shù)纫鸬膯栴}，全部由保護小組執(zhí)行達成，但需要用戶測試確認上線。若是較大的