完整的IT項目開發流程

  通常狀況下,企業開發軟件時會按照基線和定製兩塊並行方式執行項目開發工做。不管什麼公司,都須要聽從一套成熟的產品研發過程體系,才能作出質量較好的產品。所以,若是出現項目較多的狀況,應該合理地安排基線和定製以前的里程碑,讓基線產品可以儘可能多地收集用戶的通用型需求,爲定製項目進度實現技術支撐,減小定製項目中大量更改代碼、須要新增模塊狀況發生。此外,產品研發過程體系也須要按照業務實際時間要求變化,不要拘泥於必定要按照瀑布方式,或是敏捷方式進行管理,凡事都須要找到契合本身的方式。程序員

【這裏以一個基線產品開發過程做爲流程解釋基礎,須要注意的是,如下說描述的各個階段,在項目執行前要明確各個階段的目標、指定計劃、及時溝通,並確保各個時期全部成員對項目理解一致】算法


項目啓動會編程

項目啓動會的目標是明確該產品開發項目的目標。目標不是孤立存在的,目標與計劃相輔相成,目標指導計劃,計劃的有效性影響着目標的達成。因此在執行目標的時候,考慮清楚本身的行動計劃,怎麼作才能更有效地完成目標,是每一個人都要詳情清楚的問題,不然,目標越是不清晰或是太高,都會影響項目的實際結果。安全

項目啓動會須要說明項目目標、階段劃分、組織結構、管理流程等關鍵事項,並將這些內容寫入 PPT(最好是有固定格式和範文,讓團隊內部或者公司內部共同遵照規範),須要你們達成一致。對於關鍵角色任命,事前也須要聽取相關領導和項目主要干係人的意見。服務器

用戶需求網絡

軟件開始開發前須要肯定代價和所得到價值的對比,也就是 ROI(Return On investment),一旦肯定須要建立,就須要安排一系列的資源來支撐這個軟件的生存。這是需求的最原始描述。數據結構

爲何既要有用戶需求,也要有產品需求?由於二者是有差別的,用戶需求由用戶提出,對技術通常不描述,只描述產品目標。產品需求是根據用戶需求轉化而來的技術實現需求,須要針對用戶提出的產品目標進行細分,總結出具體的每個功能點,再針對每個功能點細分爲各類不一樣的操做流程,對每個操做流程進行技術化定義。架構

用戶需求和產品需求容易發生不同,這是由於雖然你們都在談需求,可是出發點可能不一樣,形成了雙方關注點和思惟方式不一樣。用戶需求關注的是系統如何支持業務流程,背後的需求是「實現業務目標」。技術人員關注的是合理技術方案,背後的需求是「工做量」、「實現難度」和「系統性能」。框架

產品需求編程語言

咱們須要弄清楚產品經理或項目需求提出者爲何要作這個項目?這是最本質的業務需求。需求分析肯定的業務需求,都是從業務需求推導出來的,都必須爲業務需求服務。

產品需求通常包括產品需求規格說明書和產品需求矩陣。產品需求矩陣通常按照子系統、功能集、執行單元的結構列出全部的功能需求,每列則對應每項功能的工做步驟以及每一個步驟的工做量。

產品需求寫完後,須要進行評審。在需求評審會上,產品、技術詳細評審需求是否完整,產品功能的正常場景是什麼?是否造成閉環?異常場景是什麼?是否考慮周全?

需求評審後,開發和測試負責人,分別編寫技術方案和測試用例。技術方案評審,開發負責人拉上涉及到其餘系統的負責人一塊兒討論,技術方案中必需要有業務流程圖和時序圖,業務流程圖是爲了梳理開發對業務的理解,是否和需求一致。時序圖是了梳理本次需求涉及的系統交互。技術方案評審經過後,確認工做量和交付時間,反饋給產品。

整體設計

設計階段的目標主要是對待開發系統的構架進行分析和設計,並創建系統構架的基線,以便爲以後的實施工做提供一個穩定的基礎。

設計階段包括了系統架構的輸出,一個好的系統架構設計能夠幫助人類梳理業務邏輯且抓住核心需求,設計穩定可擴展的業務系統,評估業務開發週期和開發成本,有效的規避風險。例如蓋房子的時候得有建築圖紙,有了圖紙,才能覈算施工週期。

整體設計是整個系統的框架型設計,意義及其重大,通常狀況下不能省略(只有維護項目能夠省略整體設計,由於基準項目已經設計完畢),全部的產品開發項目均須要首先進行整體設計,它是設計首要步驟,決不容許本末倒置,不能出現先編碼後設計的狀況,這是軟件開發的第二大痛點(第一大是需求不明確、任意變動需求)。

整體設計分爲三個階段:

第一階段:初始設計。在對給定的數據流圖進行復審和精化的基礎上,將其轉化爲初始的模塊結構圖。

第二階段:精化設計。依據模塊「高內聚低耦合」的原則,精化初始的模塊結構圖,並設計其中的全局數據結構和每一模塊的接口。

第三階段:設計複審階段。對前兩個階段獲得的高層軟件結構進行復審,必要時還可能須要對軟件結構作一些精化工做。

概要設計

概要設計的目的是描述系統的每一個模塊的內部設計,對整體設計和詳細設計承擔承上啓下的做用。

概要設計按照結構化設計方法進行設計。結構化設計方法的基本思路是:按照問題域,將軟件逐級細化,分解爲沒必要再分解的的模塊,每一個模塊完成必定的功能,爲一個或多個父模塊服務(即接受調用),也接受一個或多個子模塊的服務(即調用子模塊)。模塊的概念,和編程語言中的子程序或函數是對應的。

概要設計階段把軟件按照必定的原則分解爲模塊層次,賦予每一個模塊必定的任務,並肯定模塊間調用關係和接口。

在這個階段,設計者會大體考慮並照顧模塊的內部實現,但不過多糾纏於此。主要集中於劃分模塊、分配任務、定義調用關係。模塊間的接口與傳參在這個階段要制定得十分細緻明確,須要編寫嚴謹的數據字典,避免後續設計產生不解或誤解。概要設計通常不是一次就能作到位,而是反覆地進行結構調整。典型的調整是合併功能重複的模塊,或者進一步分解出能夠複用的模塊。在概要設計階段,應最大限度地提取能夠重用的模塊,創建合理的結構體系,節省後續環節的工做量。

概要設計文檔最重要的部分是分層數據流圖、結構圖、數據字典以及相應的文字說明等。以概要設計文檔爲依據,各個模塊的詳細設計就能夠並行展開了。

詳細設計

詳細設計階段就是依據概要設計階段的分解,設計每一個模塊內的算法、流程,爲每一個模塊完成的功能進行具體的描述,要把功能描述轉變爲精確的、結構化的過程描述。

詳細設計這個階段,各個模塊能夠分給不一樣的人去並行設計。設計者的工做對象是一個模塊,根據概要設計賦予的局部任務和對外接口,設計並表達出模塊的算法、流程、狀態轉換等內容。這裏要注意,若是發現有結構調整(如分解出子模塊等)的必要,必須返回到概要設計階段,將調整反應到概要設計文檔中,而不 能就地解決,不打招呼。詳細設計文檔最重要的部分是模塊的流程圖、狀態圖、局部變量及相應的文字說明等。一個模塊對應一篇詳細設計文檔。

概要設計階段一般獲得軟件結構圖,詳細設計階段經常使用的描述方式有:流程圖、N-S 圖、PAD 圖、僞代碼等。而詳細設計的目的是描述某一個模塊內部的處理流程、開發方法和編碼技巧。通常來講,詳細設計由項目簡介、模塊說明(具體說明每個模塊內部的流程、功能、邏輯、消耗以及未解決問題)、接口設計(包括內部接口和外部接口)、數據結構設計(包括物理結構和邏輯結構)、特殊處理等幾個部分構成。軟件的詳細設計,最終是將軟件系統的各個部分的具體設計方法、邏輯、功能採用文字方式進行表述。這樣在實現過程當中,編碼人員原則上嚴格按此進行代碼實現便可。

編寫代碼

編寫代碼能夠遵循如下幾點原則:

先作核心模塊的壓測:不少程序員,習慣把東西作完,而後等着快上線的時候才作性能測試,那麼若是前面設計出了問題,這個就很頭大了。固然,後期快上線的時候也要作性能測試,但前期的我認爲仍是很重要的。固然,作好這一點,須要懂一些業務,你要知道業務壓力在哪裏,業務請求的重心在哪裏,不少時候,產品經理不講,你也要問清楚。

確保過程可控:代碼執行時必定要保持中間的輸出,好比說,每處理 10 萬條日誌,寫一條狀態日誌,記錄處理的日誌條目數和當前的執行時間。

多打日誌:不少時候,代碼寫的本身也不是很滿意,好比某個處理效率不夠優化,某個處理的方法不夠簡潔,或者擴展性比較差,代碼寫的很弱智,但可能短期沒有辦法想清楚最合理的解決方案,考慮到上線初期這裏並非重心所在,因此也不會特地去優化它,但這種狀況下我每每會留下注釋,並說明下一步優化的可能思路是什麼,或者想到的可行方案是什麼。

簡單易懂的邏輯:千萬不要把本身繞進去了,時間一長,誰都看不明白你的邏輯。若是邏輯真的很難在一個函數內完成,嘗試切分。

不要沉迷於框架:框架最大的問題是什麼?是過於繁冗的嵌套。爲何我一直很煩框架?由於常常遇到須要一秒鐘幾千次請求的處理場景,那麼調優的時候,要從數不清的框架中尋找數據處理的邏輯,尋找性能卡點,可能改動代碼只有兩行,可是找問題須要兩天。程序員記住,你的技術能力絕對不能被框架約束住。

使用熟悉、成熟的技術:不少人根本沒搞明白本身的障礙和問題在哪裏,根本不知道相關技術產品的優點和劣勢在哪裏,看一堆第三方的數據測評,腦子一熱,去學新技術,而後,掉進坑裏出不來,若是是創業公司,可能項目就死在裏面了。使用新技術前,建議全面瞭解該技術的特徵,適用範圍,以及不適用的範圍。

代碼審覈

衆所周知,在團隊中進行代碼審查(Code Review)能夠提高代碼質量,分享項目知識、明確責任,最終達到構建更好的軟件、更好的團隊。

代碼審覈及其重要,通常來講每週都要作一次代碼審覈。首先,代碼審覈有利於你跟蹤項目進展狀況,咱們能真實地看到手下的人進展如何,而且更早發現他們是否誤入歧途。有時候,手下人會說「完成得差很少了!」,你去看代碼時發現什麼都沒有或者只是一堆垃圾,諸如此類,總之離完成還很遙遠。在管理中,這種狀況是最讓人討厭的,因此我認爲代碼審查是避免這種麻煩的最佳途徑。

單元測試

要認識單元測試,首先要明白什麼是「單元(Unit)」。所謂「單元」指的是代碼調用的最小單位,實際上指的是一個功能塊(Function)或者方法(Method)。因此單元測試指的就是對這些代碼調用單元的測試。

單元測試是一種白盒測試,就是必需要對單元的代碼細節很清楚才能作的測試。因此,單元測試的編寫和執行都是由軟件工程師來作的。相對於單元測試,還有集成測試。集成測試基本都是黑盒測試,主要是由測試人員根據軟件的功能手冊來進行測試,須要有專門的測試環境配合。集成測試又分功能測試、迴歸測試等。

須要單元測試的代碼其實是開發人員本身寫的邏輯,測試邏輯所依賴的環境是否正常不是單元測試的目的。在環境訪問代碼中引入邏輯,只會讓邏輯更難測試,致使邏輯代碼沒法進行單元測試。所以,可單元測試的代碼,纔可以採用單元測試。判斷可測試的代碼還有一個方法,就是看這個方法可否用一個 main 函數直接運行,若是能夠的話就是可單元測試的代碼。可測試的代碼還有另外一個特徵,就是該方法單元的參數,開發人員能夠自由模擬,不須要依賴外部環境。

集成測試

集成測試,也叫組裝測試或聯合測試。在單元測試的基礎上,將全部模塊按照設計要求組裝成爲子系統或系統,進行集成測試。實踐代表,一些模塊雖然可以單獨地工做,但並不能保證鏈接起來也能正常的工做。一些局部反映不出來的問題,在全局上極可能暴露出來。

集成測試是在軟件系統集成過程當中所進行的測試,其主要目的是檢查軟件單位之間的藉口是否正確。它根據集成測試計劃 ,一邊將模塊或其餘模塊組合成愈來愈大的系統,一邊運行該系統,以分析所組成的系統是否正確,各個組成部分是否合拍。集成測試的策略主要有自頂向下和自底向上兩種。也能夠理解爲在軟件設計單元、功能模塊組裝、集成爲系統時,對應用系統的各個部件(軟件單元、功能模塊接口、連接等)進行的聯合測試,以決定他們可否在一塊兒共同工做,部件能夠是代碼塊、獨立的應用、網絡上的客戶端或服務器端程序。

系統測試

系統測試階段包括系統測試方案及用例編寫、功能性測試、性能測試、穩定性測試。

爲了驗證需求分析肯定的功能是否齊全並被正確實現,同時還要對安裝、部署、適應性、安全性、界面等非功能性需求進行測試。系統測試也有測試人員負責,應該在需求分析完成後進行設計,在集成測試完成後進行實施。

功能性測試通常由獨立測試小組採用黑盒方式來測試,主要測試系統是否符合「需求規格說明書」。在通過以上各階段測試確認以後,把系統完整地模擬客戶環境來進行的測試。系統測試是將已經確認的軟件、計算機硬件、外設、網絡等其餘元素結合在一塊兒,進行信息系統的各類組裝測試和確認測試,其目的是經過與系統的需求相比較,發現所開發的系統與用戶需求不符或矛盾的地方,從而提出更加完善的方案。

性能測試驗證系統的穩定性和效率,檢查系統是否知足規定的性能要求。性能測試一般選擇一些典型的功能,檢驗這些功能在大量用戶同時使用系統時系統是否穩定。性能測試由測試人員負責,能夠在系統測試完成後進行,也能夠對重要模塊先進行性能測試,能夠貫穿整個測試周期,目的是儘早發現系統的性能瓶頸並提前解決。

穩定性測試和性能測試都必須等到系統基本沒問題、趨於穩定時再進行纔有效果,不然很難順利測下去,出現異常也不能定位到底是系統架構的問題,仍是功能上的缺陷。

穩定性測試(亦可稱可靠性測試)經過給系統加載必定的業務壓力,讓系統持續運行一段時間(通常爲 7x24 小時),檢測系統是否可以穩定運行。

產品發佈

產品發佈是系統測試結束後的最後一步,一般在軟件產品開發過程當中不須要產品試製環節,能夠直接上線,只須要系統測試員輸出系統測試報告並批准產品發佈(上線)就能夠了。

產品發佈前須要經過產品發佈說明會形式,對整個產品開發過程從立項開始回溯過程,指出整個過程當中的不足點,總結經驗,爲下一個項目提供經驗案例。這一會議能夠經過正式會議形式召開,須要召集產品經理、主要開發人員、測試人員、上級領導等參與,準備充分,盡最大可能說清楚這個產品發佈以後的效果、效益,爲上線後的價值評估作準備。這一環節不可缺乏,即使在互聯網公司,迭代速度很快的狀況下,這一環節也須要知足。

開發過程覆盤

其實開發過程體系裏並無這一過程,可是我我的認爲它很是重要。

全部的總結,只有帶着問題去思考纔會有收穫,這就是覆盤。不論我說多少,若是沒有過相似的經驗,就很難有很強的共鳴。我以爲看清一個問題最好的方式,就是你曾經處在一個問題的兩個不一樣的角色中。

總結項目經驗教訓的目的,在於總結問題、分析緣由,避免之後犯一樣的錯誤,而不是追究誰的責任。

假設一個需求理解的缺陷,若是在需求階段發現,修改一下可能只要一個小時,可是若是到了設計完成時發現這個缺陷,由於涉及的人員、文檔增多,估計要一天時間,而若是等到代碼都編寫完成時才發現這個缺陷,可能須要十天八天了。若是缺陷沒被發現,而是直接到了生產系統中呢?這就不是工做量的問題了,估計損失就難以估計了。在質量管理的理論中,缺陷每延遲一個階段被發現,修復的代價就要乘上十倍。

 


來源: InfoQ  

做者: 周明耀

相關文章
相關標籤/搜索