1.傳統開發流程的問題

傳統的軟件開發流程是一個文檔驅動的流程,它將整個軟件開發過程劃分為順序相接的幾個階段,每個階段都必需完成全部規定的任務(文檔)后才能夠進入下一個階段。如必須完成全部的系統需求規格說明書之后才能夠進入概要設計階段,編碼必需在系統設計完成之后才能夠進行。這就意味著只有當所有的系統模塊全部開發完成之后,我們才進行系統集成,對于一個由上百個模塊組的復雜系統來說,這是一個非常艱巨而漫長的工作。

隨著我們所開發的軟件項目越來越復雜,傳統的瀑布型開發流程不斷地暴露出以下問題:

需求或設計中的錯誤往往只有到了項目后期才能夠被發現例如:系統交付客戶之后才發現原先對于需求的理解是錯誤的,系統設計中的問題要到測試階段才能被發現。

對于項目風險的控制能力較弱項目風險在項目開發較晚的時候才能夠真正降低,往往是經過系統測試之后,才能確定該設計是否能夠真正滿足系統需求。

軟件項目常常延期完成或開發費用超出預算項目開發進度往往會被意外發生的問題所打亂,需要進行返工或其他一些額外的開發周期,造成項目延期或費用超支。

項目管理人員專注于文檔的完成和審核來估計項目的進展情況所以項目經理對于項目狀態的估計往往是不準確的,當他回答系統已完成了80%的開發任務時,剩下20%的開發任務實際上消耗的是整個項目80%的開發資源。

在傳統的瀑布模型中,需求和設計中的問題是無法在項目開發的前期被檢測出來的,只有當第一次系統集成時,這些設計缺陷才會在測試中暴露出來,從而導致一系列的返工:重新設計、編碼、測試,進而導致項目的延期和開發成本的上升。

2.采用迭代化開發控制項目風險

為了解決傳統軟件開發流程中的問題,我們建議采用迭代化的開發方法來取代瀑布模型。在瀑布模型中,我們要完成的是整個軟件系統開發這個大目標。在迭代化的方法中,我們將整個項目的開發目標劃分成為一些更易于完成和達到的階段性小目標,這些小目標都有一個定義明確的階段性評估標準。迭代就是為了完成一定的階段性目標而所從事的一系列開發活動,在每個迭代開始前都要根據項目當前的狀態和所要達到的階段性目標制定迭代計劃,整個迭代過程包含了需求、設計、實施(編碼)、部署、測試等各種類型的開發活動,迭代完成之后需要對迭代完成的結果進行評估,并以此為依據來制定下一次迭代的目標。

與傳統的瀑布式開發模型相比較,迭代化開發具有以下特點:

允許變更需求

需求總是會變化,這是事實。給項目帶來麻煩的常常主要是需求變化和需求"蠕變",它們會導致延期交付、工期延誤、客戶不滿意、開發人員受挫。通過向用戶演示迭代所產生的部分系統功能,我們可以盡早地收集用戶對于系統的反饋,及時改正對于用戶需求的理解偏差,從而保證開發出來的系統真正地解決客戶的問題。

逐步集成元素

在傳統的項目開發中,由于要求一下子集成系統中所有的模塊,集成階段往往要占到整個項目很大比例的工作量(最高可達40%),這一階段的工作經常是不確定并且非常棘手。在迭代式方法中,集成可以說是連續不斷的,每一次迭代都會增量式集成一些新的系統功能,要集成的元素都比過去少得多,所以工作量和難度都是比較低的。

盡早降低風險

迭代化開發的主要指導原則就是以架構為中心,在早期的迭代中所要解決的主要問題就是盡快確定系統架構,通過幾次迭代來盡快地設計出能夠滿足核心需求的系統架構,這樣可以迅速降低整個項目的風險。等到系統架構穩定之后,項目的風險就比較低了,這個時候再去實現系統中尚未完成的功能,進而完成整個項目。

有助于提高團隊的士氣

開發人員通過每次迭代都可以在短期內看到自己的工作成果,從而有助于他們增強信心,更好地完成開發任務。而在非迭代式開發中,開發人員只有在項目接近尾聲時才能看到開發的結果,在此之前的相當長時間,大家還是在不確定性中摸索前近。

生成更高質量的產品

每次迭代都會產生一個可運行的系統,通過對這個可運行系統進行測試,我們在早期的迭代中就可以及時發現缺陷并改正,性能上的瓶頸也可以盡早發現并處理。因為在每次迭代中總是不斷地糾正錯誤,我們可以得到更高質量的產品。

保證項目開發進度

每次迭代結束時都會進行評估,來判斷該次迭代有沒有達到預定的目標。項目經理可以很清楚地知道有哪些需求已經實現了,并且比較準確地估計項目的狀態,對項目的開發進度進行必要的調整,保證項目按時完成。

容許產品進行戰術改變

迭代化的開發具有更大的靈活性,在迭代過程中可以隨時根據業務情況或市場環境來對產品的開發進行調整。例如為了同現有的同類產品競爭,可以決定采用搶先競爭對手一步的方法,提前發布一個功能簡化的產品。

迭代流程自身可在進行過程中得到改進和精煉

一次迭代結束時的評估不僅要從產品和進度的角度來考察項目的情況,而且還要分析組織和流程本身有什么待改進之處,以便在下次迭代中更好地完成任務。

迭代化方法解決的主要是對于風險的控制問題,從下圖可以看出,傳統的開發流程中系統的風險要到項目開發的后期(主要是測試階段)才能夠被真正降低。而迭代化開發中的風險,可以在項目開發的早期通過幾次迭代來盡快地解決掉。在早期的迭代中一旦遇到問題,如某一個迭代沒有完成預定的目標,我們還可以及時調整開發進度以保證項目按時完成。一般到了項目開發的后期(風險受控階段),由于大部分高風險的因素(如需求、架構、性能等)都已經解決,這時候只需要投入更多的資源去實現剩余的需求即可。這個階段的項目開發具有很強的可控性,從而保證我們按時交付一個高質量的軟件系統。

迭代化開發不是一種高深的軟件工程理論,它提供了一種控制項目風險的非常有效的機制。在日常的工作我們也經常地應用到這一基本思想,如對于一個非常大型的工程項目,我們經常會把它分為幾期來分步實施,從而把復雜的問題分解為相對容易解決的小問題,并且能夠在較短周期內看到部分系統實現的效果,通過盡早暴露問題來幫助我們及早調整我們的開發資源,加強項目進度的可控程度,保證項目的按時完成。

3.管理迭代化的軟件項目

當我們在實際工作中實踐迭代化思想時,Rational統一開發流程RUP(RationalUnifiedProcess)可以給予我們實踐的指導。RUP是一個通用的軟件流程框架,它是一個以架構為中心、用例驅動的迭代化軟件開發流程。RUP是從幾千個軟件項目的實踐經驗中總結出來的,對于實際的項目具有很強的指導意義,是軟件開發行業事實上的行業標準。

3.1軟件開發的四個階段

在RUP中,我們把軟件開發生命周期劃分為四個階段,每個階段的結束標志就是一個主要的里程碑(如下圖所示)。

這四個階段主要是為了達到以下階段性的目標里程碑:

先啟(Inception):確定項目開發的目標和范圍

精化(Elaboration):確定系統架構和明確需求

構建(Construction):實現剩余的系統功能

產品化(Transition):完成軟件的產品化工作,將系統移交給客戶

每個目標里程碑都是一個商業上的決策點,如先啟階段結束之后,我們就要決定這個項目是否可行、是否要繼續做這個項目。每一個階段都是由里程碑來決定的,判斷一個階段是否結束的標志就是看項目當前的狀態是否滿足里碑中所規定的條件。

從這種階段劃分模式中可以看出,項目的主要風險集中在前兩個階段。在精化階段中經過幾次迭代后,我們要為系統建立一個穩定的架構,在此之后再實現更多的系統需求時,不再需要對該架構進行修改。同時,在精化階段中,我們通過迭代來不斷地收集用戶的需求反饋,便得系統的需求逐步地明確和完整。

3.2關于開發資源的分配

基于RUP風險驅動的迭代化開發模式,我們只需要在項目的先啟階段投入少量的資源,對項目的開發前景和商業可行性進行一些探索性的研究。在精化階段再投入多一些的研發力量來實現一些與架構相關的核心需求,逐步地把系統架構搭建起來。等到這兩個階段結束之后,項目的一些主要風險和問題也得到了解決,這時候再投入整個團隊進行全面的系統開發。等到產品化階段,主要的開發任務已經全部完成,項目不再需要維持一個大規模的開發團隊,開發資源也可以隨之而減少。在項目開發周期中,開發資源的分配可以如下圖所示。

這樣安排可以最充分有效地利用公司的開發資源,緩解軟件公司對于人力資源不斷增長的需求,從而降低成本。另外一方面,由于前兩個階段(先啟和精化)的風險較高,我們只是投入部分的資源,一旦發生返工或是項目目標的改變,我們也可以將資源浪費降到最低點。在傳統的軟件開發流程中,對于開發資源的分配基本上是貫穿整個項目周期而不變的,資源往往沒有得到充分有效地利用。

基于這種資源分配模式,一個典型的項目在項目進度和所完成的工作量之間的關系可能如下表中的數據所示

先啟

精化

構建

產品化

工作量

~5%

20%

65%

10%

進度

10%

30%

50%

10%

3.3迭代策略

關于迭代計劃的安排,通常有以下四種典型的策略模式:

增量式(Incremental)

這種模式的特點是項目架構的風險較小(往往是開發一些重復性的項目),所以精化階段只需要一個迭代。但項目的開發工作量較大,構建階段需要有多次迭代來實現,每次迭代都在上一次迭代的基礎上增加實現一部分的系統功能,通過迭代的進行而逐步實現整個系統的功能。

演進式(Evolutionary)

當項目架構的風險較大時(從未開發過類似項目),需要在精化階段通過多次迭代來建立系統的架構,架構是通過多次迭代的探索,逐步演化而來的。當架構建立時,往往系統的功能也已經基本實現,所以構建階段只需要一次迭代。

增量提交(IncrementalDelivery)

這種模式的特點產品化階段的迭代較多,比較常見的例子是項目的難度并不大,但業務需求在不斷地發生變化,所以需要通過迭代來不斷地部署完成的系統;但同時又要不斷地收集用戶的反饋來完善系統需求,并通過后續的迭代來補充實現這些需求。應用這種策略時要求系統架構非常穩定,能夠適應滿足后續需求變化的要求。

單次迭代(GrandDesign)

傳統的瀑布模型可以看作是迭代化開發的一個特例,整個開發流程只有一次迭代。但這種模式有一個固有的弱點,由于它對風險的控制能力較差,往往會在產品化階段產生一些額外的迭代,造成項目的延誤。

這幾種迭代策略只是一些典型模式的代表,實際應用中應根據實際情況靈活應用,最常見的迭代計劃往往是這幾種模式的組合。

3.4制定項目開發計劃

在迭代化的開發模式中,項目開發計劃也是隨著項目的進展而不斷細化、調整并完善的。傳統的項目開發計劃是在項目早期制定的,項目經理總是試圖在項目的一開始就制定一個非常詳細完善的開發計劃。與之相反,迭代開發模式認為在項目早期只需要制定一個比較粗略的開發計劃,因為隨著項目的進展,項目的狀態在不斷地發生變化,項目經理需要隨時根據迭代的結果來對項目計劃進行調整,并制定下一次迭代的詳細計劃。

在RUP中,我們把項目開發計劃分為以下三部分:

項目計劃

確定整個項目的開發目標和進度安排,包括每一個階段的起止時間段。

階段計劃

當前階段中包含有幾個迭代,每一次迭代要達到的目標以及進度安排。

迭代計劃

針對當前迭代的詳細開發計劃,包括開發活動以及相關資源的分配。

項目開發計劃也是完全體現迭代化的思想,每次迭代中項目經理都會根據項目情況來不斷地調整和細化項目開發計劃。迭代計劃是在對上一次迭代結果進行評估的基礎上制定的,如果上一次迭代達到了預定的目標,那么當前迭代只需要解決剩下的問題;如果上一次迭代中留有一些問題還沒有解決,則當前迭代還需要繼續去解決這些問題。所以必須注意,迭代是不能重疊的,即你還沒有完成當前迭代時,你決不能進入下一迭代,因為下一次迭代的計劃是根據當前迭代的結果而制定的。

篇2:軟件開發工程師崗位工作職責

軟件開發工程師的工作主要是負責網站整體建設及網站程序開發,那么他的具體職責是什么呢以下由[制度職責大全]人才網為大家詳細介紹軟件開發工程師崗位職責,請閱讀。

1、軟件的程序設計與代碼編寫。

2、有關技術方案、文檔的編寫,軟件單元的測試。

3、根據項目具體要求,承擔開發任務,按計劃完成任務目標。

4、配合系統分析人員完成軟件系統以及模塊的需求調研、需求分析。

5、獨立完成軟件系統及模塊的編碼。

6、協助測試人員完成軟件系統及模塊的測試。

7、負責編制與項目相關的技術文檔。

8、根據項目具體要求,承擔大型網站設計與開發。

9、部分軟件功能模塊設計和軟件界面美化。

10、協助測試試人員完成軟件系統及模塊的測試。

篇3:國際化軟件開發職責流程

國際化軟件開發需要遵守國際化技術準則,采用軟件項目(或產品)方式進行。一個完整的國際化軟件項目將包含很多內容和階段,其中軟件的國際化和本地化是兩項主要內容。

為了更深入地理解國際化軟件的開發流程,我們先從分析國際化項目失敗的原因開始,然后列舉國際化軟件的設計準則,討論項目團隊的組織結構。在此基礎上,再詳細論述國際化軟件的開發流程和本地化流程。

1.國際化軟件項目失敗的原因分析

開發國際化項目最大的難點是避免失敗。由于軟件生產過程和技術的復雜性,軟件業在20世紀60年代出現了“軟件危機”——失敗的幾率很高。時至今日,雖然軟件開發和管理技術已經取得了“突飛猛進”式的發展,但是“軟件危機”仍然沒有根本消除,新開發軟件項目失敗的比例仍然居高不下。

與面向單一區域、單一語言的軟件開發項目相比,開發國際化軟件項目不僅在技術上,而且在項目需求和管理的各個方面都更加復雜,國際化軟件項目失敗的案例較多,開發國際化軟件項目成為高風險的生產活動。

分析那些失敗的國際化軟件項目,其原因可能多種多樣,但是沒有遵守國際化軟件的設計準則和技術要求,沒有考慮國際化和本地化的使用要求等因素成為最大的問題。具體而言,導致國際化軟件項目失敗的原因主要有以下幾個方面:

●在最初編寫軟件規格說明和開發階段沒有考慮軟件的國際化問題,經常在軟件編碼完成后進行測試時,才發現大量的國際化設計缺陷。

●雖然考慮了軟件的國際化需求,但是沒有深入考慮當地用戶和市場的特定需求。

●軟件開發團隊不熟悉國際化開發技術,不知道如何開發和管理國際化軟件。

●測試團隊不熟悉國際化測試技術,沒有在本地化的操作系統和設備上進行產品測試。

●項目管理團隊低估了軟件國際化和本地化處理所需的時間。

●國際化軟件開發公司讓當地不合格的軟件經銷商進行軟件本地化處理。

為了盡量避免國際化軟件項目的失敗,需要研究、學習和遵守國際化軟件準則,充分運用國際化設計技術、工程技術、本地化技術,深入獲取不同區域市場的特定功能特性需求和理解文化習俗等方面的差異。

2.國際化軟件設計準則

在進行國際化軟件設計實踐過程中,軟件專業人員逐步總結出一些通用的準則。遵守這些準則,可以盡可能地避免國際化軟件項目失敗,提高質量,降低開發和維護費用。

國際化軟件設計需要遵循的通用準則如下:

●在國際化軟件項目的初期融入國際化思想,并且使國際化貫穿于項目的整個生命周期。

●采用單一源文件進行多語言版本的本地化,不針對不同的語言編寫多套代碼。

●需要本地化的文字與軟件源代碼分離,存儲在單獨的資源文件中。

●軟件代碼支持處理單字節字符集和多字節字符集文字的輸入、輸出和顯示,并且遵守豎排和折行規則。

●軟件代碼應該支持Unicode標準,或者可以在Unicode和其他代碼頁(CodePages)互換。

●軟件代碼不要嵌入字體名,也不要假設使用某種字體。

●使用通用的圖標和位圖,避免不同區域的文化和傳統差異,避免在圖標和位圖中嵌入需要本地化的文字。

●菜單、對話框等界面布局能夠滿足處理本地化文字的長度擴展的需要。

●源語言的文字要準確精簡,使用一致的術語,避免歧義和拼寫錯誤,以便進行本地化翻譯。

●保證不同區域的鍵盤布局都能使用源軟件的快捷鍵。

●考慮不同區域的法律和文化習俗對軟件的要求。

●如果軟件中采用第三方開發的軟件或組件,需要檢查和確認是否滿足國際化的要求。

●保證源語言軟件可以在不同的區域和操作系統上正確運行。

●軟件代碼中避免“硬編碼”,不使用基于源語言的數字常量、屏幕位置、文件和路徑名。

●字符串的緩沖區長度要滿足本地化字符擴展的長度。

●軟件能正確支持區域排序和大小寫轉換。

3.項目與團隊

項目是為完成某一項特定產品、服務或結果而實施的一項臨時任務,它具有明確的目標、起止時間和預算。

復雜的項目需要成立項目團隊,來自不同國家或地區的具有不同技能和經驗的人員,為著共同的任務目標相互配合,共同完成項目的不同子任務。

國際化軟件的開發是復雜的工作,需要良好的項目規劃,成立有協作精神的團隊,由于現代軟件設計的復雜性和本地化對語言質量的較高要求,經常由分布在世界各地的多家公司的不同技術和管理人員組成國際化軟件項目團隊。

一般地,國際化軟件項目可以分為規劃階段、實施階段和驗收結尾階段。每一階段的任務都需要考慮國際化和本地化需要,而且盡早進行國際化需求分析,可以有利于控制項目成本和進度。

現在軟件外包成為國際化軟件項目新的開發模式,通常大型跨國軟件公司專注于進行軟件項目規劃和核心功能和特征設計,將軟件的本地化外包給專業的本地化公司?，F在,軟件編碼和測試的外包也流行起來。

項目團隊對于國際化軟件項目的成敗具有關鍵性的作用。除了軟件技術之外,大型國際化軟件項目的項目管理非常重要,尤其是當項目由多家分布于不同國家或地區的軟件公司共同實施時,項目規劃和管理交流就變得更為重要了。

為了便于項目管理,通常采用“單點聯系(Singlepointcontact)”的方式,每個公司在項目準備階段指定惟一的項目經理(ProjectManager,PM),負責項目聯系的一切任務。各個公司的項目經理負責組建各自的項目團隊,跟蹤和控制項目的實施,并且報告項目進度、存在的問題和可能的改進方法。

項目團隊的構成與各家公司承擔的項目任務有關系,通常項目經理按照任務類型組建不同的項目組,每個項目組指定一位組長(TeamLead),負責小組的技術和協調問題,每個組的成員由項目經理和組長協商確定。

為了順利實施軟件本地化,軟件開發公司的本地化項目經理,與軟件本地化外包服務公司的項目經理,以及軟件開發公司在當地的分公司經理互相協作完成軟件本地化。

軟件開發公司的分公司主要負責對本地化的內容進行語言質量和文化傳統等方面的審閱?？梢杂煞止緝炔康膶Ｂ毴藛T承擔審閱任務,也可以在當地市場尋找專業人士兼任。

軟件本地化公司根據項目的要求,可能組建不同的團隊。對于完整的本地化項目,一般需要成立本地化語言組、本地化工程組、本地化測試組和本地化桌面排版組等。

4.國際化軟件開發流程

在討論國際化軟件的流程前,需要熟悉國際化軟件的開發周期。對于國際化軟件而言,完整地開發周期包括需求分析、國際化、本地化、發布和維護等過程。其中國際化包括設計、開發和測試等,在國際化的各個環節都要重視軟件的本地化能力。越在軟件項目早期重視軟件的本地化要求,就越對控制軟件項目的正常進度和質量有利。

隨著市場競爭的加劇,軟件的國際化版本和本地化版本需要同時發布(Simship),而且本地化的語言版本越來越多,承擔本地化服務的公司往往不止一家,它們可能還要進一步外包。正是由于這種復雜的環節和過程,使得大型國際化軟件的項目管理更趨復雜。

國際化軟件的開發流程包括開發國際化軟件需要遵循軟件工程的要求,分為需求分析、軟件設計、軟件編碼、軟件測試、質量保證、軟件發布等過程。

在需求分析階段,既要考慮軟件的功能特性需求,也要考慮軟件的國際化需求。另外,為了縮短源語言開發的版本和本地化版本的發布時間間隔(甚至達到同步發布),國際化版本的開發應該與軟件本地化過程同時進行。在測試方面,對國際化版本的國際化功能測試和對本地化版本的本地化測試盡可能同時進行,以便盡早發現和修改國際化設計缺陷。

在軟件進入最終本地化和測試之前,需要“凍結(Freeze)”用戶界面和功能特性設計,保證軟件在發布之前不再對需要本地化的內容進行改動。因為,每次改動用戶界面,本地化過程都需要重新翻譯一次,相應的聯機幫助文檔和本地化的軟件手冊等的內容也需要重新更新,這樣會增加項目成本,延遲本地化版本的發布。

5.軟件本地化流程

軟件本地化的流程與具體的項目有關。復雜的軟件本地化可能包括翻譯、排版、工程處理和測試等內容,而較小的本地化項目可能只包含翻譯或排版。

和任何軟件項目一樣,本地化項目的前期準備非常重要,明確項目的范圍、要求、技術和資源,對于保證項目的成功可能起到關鍵的作用。

軟件本地化項目在正式開始之前,通常需要參加項目啟動會議。由軟件開發公司的項目經理召集和主持,由來自多個公司的項目組關鍵成員參加。

大型本地化項目的實施過程可能跨度較長,通常需要進行幾個周期的更新過程。按照項目計劃的里程碑進行進度和質量跟蹤,本地化服務公司的項目經理與開發商的本地化項目經理保持有效交流,有助于保證本地化項目的順利實施。