軟件開(kāi)發(fā)管理流程（軟件開(kāi)發(fā)管理流程是什麼(me)）
本篇文章給大家談談軟件開(kāi)發(fā)管理流程，以及軟件開(kāi)發(fā)管理流程是什麼(me)對(duì)應的知識點，希望對(duì)各位有所幫助，不要忘了收藏本站喔。
本文目錄一覽：
軟件開(kāi)發(fā)流程八個步驟
1、項目開(kāi)發(fā)目的分析與确定
軟件開(kāi)發(fā)流程的這(zhè)一階段，主要是在在軟件開(kāi)發(fā)商將(jiāng)開(kāi)發(fā)項目确定下來之後(hòu)，需要與需求方進(jìn)行讨論，确定需求方對(duì)于軟件開(kāi)發(fā)的需要實現目标及其具體需要的功能(néng)等等，并确定是否可達成(chéng)。
2、需求分析
這(zhè)是軟件開(kāi)發(fā)流程的第二個階段，也是爲軟件開(kāi)發(fā)的正常進(jìn)行确定具體思路的階段。在确定軟件開(kāi)發(fā)可進(jìn)行後(hòu)，必須要對(duì)客戶需要實現的軟件功能(néng)需求進(jìn)行具體詳細的分析。同時應當考慮在開(kāi)發(fā)過(guò)程中可能(néng)出現的變化情況，制定需求變更計劃随時應對(duì)特殊情況的發(fā)生，保證軟件開(kāi)發(fā)流程的順暢進(jìn)行。
3、設計
軟件設計要根據上一階段對(duì)軟件功能(néng)需求分析的結果，來設計軟件系統的框架結構、功能(néng)模塊和數據庫等等。分爲總體設計和詳細設計兩(liǎng)個部分。
4、編程
軟件開(kāi)發(fā)流程中每上一個階段都(dōu)是下一個階段的實施進(jìn)行的基礎。編程也是根據對(duì)軟件設計，將(jiāng)軟件設計的各部分需求通計算機程序代碼來實現運行，編程有統一、規範的程序編寫規則，保證軟件程序的易懂性、易維護性。
5、軟件測試
在根據設計將(jiāng)客戶軟件需用編程代碼來實現之後(hòu)，也就是軟件程序完成(chéng)之後(hòu)，需要對(duì)編寫的程序，形成(chéng)整體構架、功能(néng)進(jìn)行單元、組裝、系統三階段的測試，以測試程序編寫的正确性，以及對(duì)客戶需求功能(néng)滿足的充分性，以此來确定軟件是否達到開(kāi)發(fā)要求，同時也是一個發(fā)現問題、糾正問題的過(guò)程。
6、軟件交付
軟件開(kāi)發(fā)流程通過(guò)以上核心環節完成(chéng)了軟件開(kāi)發(fā)，接下來就是在軟件開(kāi)發(fā)達到客戶需求之後(hòu)，開(kāi)發(fā)者將(jiāng)軟件系統交予客戶，并將(jiāng)軟件安裝程序、數據庫的數據字典、《用戶安裝手冊》、《用戶使用指南》、需求報告、設計報告、測試報告等産物交付給客戶。
同時指導客戶進(jìn)行軟件安裝、以及安裝技巧，提醒客戶注意軟件運行狀況、環境、服務器及相關中間件的檢測與注意事(shì)項，知道(dào)客戶軟件的實際操作方法、使用流程等等問題，實現合同規定任務。
7、驗收
用戶在接收開(kāi)發(fā)商交付的軟件開(kāi)發(fā)結果，并進(jìn)行實際操作、測試運行，實現滿意結果之後(hòu)，對(duì)開(kāi)發(fā)出來的軟件進(jìn)行驗收。
8、維護
定制開(kāi)發(fā)的軟件通常都(dōu)需要提供售後(hòu)服務，定期對(duì)軟件進(jìn)行維護，或者根據用戶出現的新需求，進(jìn)行應用軟件程序的修改，使之不斷滿足客戶實際需求。
軟件項目的管理流程
導語：關于軟件項目的管理流程，相關人員來了解一下吧。下面(miàn)是我收集整理的軟件項目管理流程，供各位閱讀和參考。
一、 風險評估
軟件項目風險是指在整個項目周期中所涉及的成(chéng)本預算、開(kāi)發(fā)進(jìn)度、技術難度、經(jīng)濟可行性、安全管理等各方面(miàn)的問題，以及由這(zhè)些問題而對(duì)項目所産生的影響。項目的風險與其可行性成(chéng)反比，其可行性越高，風險越低。軟件項目的可行性分爲經(jīng)濟可行性、業務可行性、技術可行性、法律可行性等四個方面(miàn)。而軟件項目風險則分爲産品規模風險、需要風險、相關性風險、管理風險、安全風險等六個方面(miàn)：
1. 産品規模風險
項目的風險是與産品的規模成(chéng)正比的，一般産品規模越大，問題就越突出。尤其是估算産品規模的方法，複用軟件的多少，需求變更的多少等因素與産品風險息息相關：
(1) 估算産品規模的方法
(2) 産品規模估算的信任度
(3) 産品規模與以前産品規模平均值的偏差
(4) 産品的用戶數
(5) 複用軟件的多少
(6) 産品需求變更的多少
2. 需求風險
很多項目在确定需求時都(dōu)面(miàn)臨著(zhe)一些不确定性。當在項目早期容忍了這(zhè)些不确定性，并且在項目進(jìn)展過(guò)程當中得不到解決，這(zhè)些問題就會(huì)對(duì)項目的成(chéng)功造成(chéng)很大威脅。如果不控制與需求相關的風險因素，那麼(me)就很有可能(néng)産生錯誤的産品或者拙劣地建造預期的産品。每一種(zhǒng)情況對(duì)産品來講都(dōu)可能(néng)緻命的，這(zhè)些的風險因素有:
(1) 對(duì)産品缺少清晰的認識
(2) 對(duì)産品需求缺少認同
(3) 在做需求分析過(guò)程中客戶參與不夠
(4) 沒(méi)有優先需求
(5) 由于不确定的需要導緻新的市場
(6) 不斷變化需求
(7) 缺少有效的需求變化管理過(guò)程
(8) 對(duì)需求的變化缺少相關分析等
3. 相關性風險
許多風險都(dōu)是因爲項目的外部環境或因素的相關性産生的。控制外部的相關性風險， 能(néng)緩解策略應該包括可能(néng)性計劃，以便從第二資源或協同工作資源中取得必要的組成(chéng)部分，并覺察潛在的問題,與外部環境相關的因素有：
(1) 客戶供應條目或信息
(2) 交互成(chéng)員或交互團體依賴性
(3) 内部或外部轉包商的關系
(4) 經(jīng)驗豐富人員的可得性
(5) 項目的複用性
4. 技術風險
軟件技術的飛速發(fā)展和經(jīng)驗豐富員工的缺乏，意味著(zhe)項目團隊可能(néng)會(huì)因爲技巧的原因影響項目的成(chéng)功。 在早期，識别風險從而采取合适的預防措施是解決風險領域問題的關鍵，比如：培訓、聘請顧問以及爲項目團隊招聘合适的人才等。關于技術主要有下面(miàn)這(zhè)些風險因素：
(1) 缺乏培訓
(2) 對(duì)方法、工具和技術理解的不夠
(3) 應用領域的經(jīng)驗不足
(4) 對(duì)新的技術和開(kāi)發(fā)方法應用不熟悉
5. 管理風險
盡管管理問題制約了很多項目的成(chéng)功，但是不要因爲風險管理計劃中沒(méi)有包括所有管理活動而感到驚奇。在大部分項目裡(lǐ)，項目經(jīng)理經(jīng)常是寫項目風險管理計劃的人，他們有先天性的不足——不能(néng)檢查到自己的錯誤。因而，使項目的成(chéng)功變得更加困難。如果不正視這(zhè)些棘手的問題，它們就很有可能(néng)在項目進(jìn)行的某個階段影響項目本身。當我們定義了項目追蹤過(guò)程并且明晰項目角色和責任，就能(néng)處理這(zhè)些風險因素：
(1) 計劃和任務定義不夠充分
(2) 對(duì)實際項目狀态不了解
(3) 項目所有者和決策者分不清
(4) 不切實際的承諾
(5) 不能(néng)與員工之間的進(jìn)行充分地溝通
6. 安全風險
軟件産品本身是屬于創造性的産品，産品本身的核心技術保密非常重要。但一直以來，我們在軟件這(zhè)方 面(miàn)的安全意識比較淡薄，對(duì)軟件産品的開(kāi)發(fā)主要注重技術本身，而忽略了專利的保護。軟件行業的技術人員流動是很普遍的現象，随著(zhe)技術人員的流失、變更，很能(néng)會(huì)導緻産品和新技術的洩密，緻使我們的軟件産品被(bèi)它公司竊取，導緻項目失敗。而且在軟件方面(miàn)關于知識産權的認定目前還(hái)沒(méi)有明确的一個行業規範，這(zhè)也是我們 軟件項目潛在的風險。
7. 回避風險的方式
(1) 以開(kāi)發(fā)方誘導能(néng)保證需求的完整，使需求與客戶的真實期望高度一緻。再以書面(miàn)方便形成(chéng)《用戶需求》這(zhè)一重要的文檔，避免疏漏造成(chéng)的損失在軟件系統的後(hòu)續階段被(bèi)逐步地放大。
(2) 設立監督制度，項目開(kāi)發(fā)中任何較大的決定都(dōu)必須有客戶參與進(jìn)行的，在該項目中項目監督由項目開(kāi)發(fā)中的質量監督組來實施。
(3) 需求變更需要經(jīng)過(guò)統一的負責人提出,并且要用戶需求的審核領導認可,需求變更應該是定期而不是随時的提出,而且開(kāi)發(fā)方應該做好(hǎo)詳細的記錄,讓客戶了解需求變更的實際情況。
(4) 控制系統的複雜程度，過(guò)于簡單的系統結構，對(duì)用戶來使用比例會(huì)有明顯的折扣，甚至造成(chéng)軟件壽命過(guò)短。反之，軟件結構的過(guò)于靈活和通用，必然引起(qǐ)軟件實現的難度增加，系統的複雜度會(huì)上升，這(zhè)又會(huì)在實現和測試階段帶來風險。适當控制系統的複雜程度有利于降低開(kāi)發(fā)的風險。
(5) 從軟件工程的角度看，軟件維護費用約占總費用的55%~70%，系統越大，該費用越高。對(duì)系統可維護性的輕視是大型軟件系統的最大風險。在軟件漫長(cháng)的運營期内，業務規則肯定會(huì)不斷發(fā)展，科學(xué)的解決此問題的做法是不斷對(duì)軟件系統進(jìn)行版本升級，在确保可維護性的前提下逐步擴展系統。
(6) 設定應急計劃，每個開(kāi)發(fā)計劃都(dōu)至少應該設定一個應急預案去應對(duì)出現突發(fā)情況和不可遇知的風險。
二、 成(chéng)本預算
1. 成(chéng)本預算方式
(1) 自上而下的預算方法
自上而下的預方法主要是依據上層、中層項目管理人員的管理經(jīng)驗進(jìn)行判斷，對(duì)構成(chéng)項目整體成(chéng)本的子項目成(chéng)本進(jìn)行估計，并把這(zhè)些判斷估計的結果傳遞給低一層的管理人員，在此基礎上由這(zhè)一層的管理人員對(duì)組成(chéng)項目的子任務和子項目的成(chéng)本進(jìn)行估計，然後(hòu)繼續向(xiàng)下一層傳遞他們的成(chéng)本估計，直到傳遞到最低一層。
使用此預算方式，在上層的管理人員根據他們的經(jīng)驗進(jìn)行的費用估計分解到下層時，可能(néng)會(huì)出現下層人員認爲上層的估計不足以完成(chéng)相應任務的情況。這(zhè)時，下層人員不一定會(huì)表達出自己的真實觀點，不一定會(huì)和上層管理人員進(jìn)行理智地讨論，從而得出更爲合理的預算分配方案。在實際中，他們往往隻能(néng)沉默地等待上層管理者自行發(fā)現問題并予以糾正，這(zhè)樣(yàng)往往會(huì)給項目帶來諸多問題。
自上而下更适用于項目啓動的前期，與真實費用相差在30% ~ 70%之間。
Scrum使用自上而下的成(chéng)本預算方式，它不會(huì)立即精确地确定成(chéng)本，而是以最大限度容納客戶對(duì)未來産品要求所産生的變更。
(2) 自下而上的預算方法
自下而上方法要求運用WBS（Work Breakdown Structure，工作分解結構）對(duì)項目的所有工作任務的時間和預算進(jìn)行仔細考察。最初，預算是針對(duì)資源（團隊成(chéng)員的工作時間、硬件的配置）進(jìn)行的，項目經(jīng)理在此之上再加上适當的間接費用（如培訓費用、管理費用、不可預見費等）以及項目要達到的利潤目标就形成(chéng)了項目的總預算。自下而上的預算方法要求全面(miàn)考慮所有涉及到的工作任務，更适用于項目的初期與中期，它能(néng)準備地評估項目的成(chéng)本，與真實費用相差在5% ~ 10%之間。
注解：WBS
WBS是面(miàn)向(xiàng)提交成(chéng)果對(duì)項目的分解，從提交成(chéng)果的列表可以确定每個提交成(chéng)果需要執行的活動。Scrum會(huì)對(duì)WBS進(jìn)一步細化，把一個叠代分解爲一個或多個的工作包，再把工作包分解爲細小的開(kāi)發(fā)任務（一般開(kāi)發(fā)任務的開(kāi)發(fā)周期在15個工作小時以内）。
2. 确定項目支出
總體成(chéng)本預算就是結合下列多個成(chéng)本預算方式綜合計算的開(kāi)發(fā)成(chéng)本：
(1) 零基數預算
在成(chéng)本預算的初期應該使用零基數的計算原則，而不可以使用類似于：以上一年總體費用加上20% 這(zhè)樣(yàng)粗略的方式計算項目成(chéng)本。
(2) 軟硬件成(chéng)本、物品成(chéng)本
物品成(chéng)本是指類似于：服務器（RAM 硬盤 CPU NIC卡 RAID簇）成(chéng)本、維護成(chéng)本、機房租金、光纖通訊成(chéng)本、軟件成(chéng)本等的成(chéng)本。
計算成(chéng)本時需要考慮組裝硬盤需時的長(cháng)短，技術人員需要具備的質素，産品供應商能(néng)否提供保證質量，管理時是否需要額外的管理人員這(zhè)些多方因素。
(3) 軟件許可證成(chéng)本
(4) 外包成(chéng)本
當使用類似：視頻、短信、移動電信類服務、門戶網站等子項目時可以考慮以外包形式完成(chéng)，以降低開(kāi)發(fā)成(chéng)本。
(5) 人力資源成(chéng)本
計算人力資源成(chéng)本時應該使用以最高和最低的工作效率估算平均效率的方式，計算出人力資源的平均成(chéng)本。
(6) 維修保養成(chéng)本
三、 客戶溝通的過(guò)程
從客戶溝通的方向(xiàng)出發(fā)來看，軟件項目可分爲：需求識别、方案定制、項目實施、項目結束等4個不同的階段，各個階段都(dōu)具有不同的溝通重點。
1. 需求識别階段
(1) 文本溝通
在需求識别的前期，應該通過(guò)問卷、原型展示、界面(miàn)展示、邏輯處理展示、準化文檔模闆等方式進(jìn)行全方位多角度的分析，随時將(jiāng)不明确之處反饋給客戶,以期待客戶解答。并以文本記錄的方式建立需要分析書，并要求客戶審核需求分析書，以達到需要分析與客戶的真實期望高度一緻的結果。
(2) 業務邏輯溝通
在進(jìn)行業務溝通時，應該了解客戶的行業語言，以促進(jìn)業務分析的過(guò)程，越過(guò)應用需求和開(kāi)發(fā)之間的鴻溝。溝通過(guò)程提倡以草圖或者可視信息化的方式進(jìn)行, 針對(duì)不同層面(miàn)的企業用戶提供最适合的操作界面(miàn)。以多角度的方式思考問題，要抓住需求重點,尤其是客戶方領導所關注的創新類和實用類需求。
(3) 需求變更的規範化管理
需求變更在軟件開(kāi)發(fā)類項目中是可以理解的,但必須對(duì)需求變更做好(hǎo)規範化的管理，以避免出現需求無止境變更的風險。需求變更必須由統一的負責人提出,并且由用戶需求的審核領導者認可。需求變更的提出應該是定期而不是随時的，開(kāi)發(fā)方應該做好(hǎo)詳細的文本記錄,讓客戶了解需求變更的實際情況和開(kāi)發(fā)方爲之所付出的成(chéng)本代價。
2. 方案定制階段
該階段項目的主要任務是與客戶共同制定一個以前期明确的需求、雙方的資源、項目開(kāi)始的階段、實施的時間約定、項目費用限制等爲基礎的具有可操作性的項目計劃,從本階段開(kāi)始争取客戶全面(miàn)參與項目的管理，并以雙方的共同利益考慮項目實施的具體計劃與風險規避。
3. 項目實施階段
在該階段,軟件項目團隊應該與客戶共同領導項目的實施。同時,項目團隊應實時評估客戶滿意度,并通過(guò)持續改進(jìn)的方式提高客戶滿意度,還(hái)應要求客戶參加必要的培訓,以及在必要時檢查項目産品。在出現客戶的需求變更前,應主動與客戶溝通交流,使客戶充分了解項目的每個環節,以及變更帶來的影響,減少需求變更。如果出現客戶需求變更,應與客戶一起(qǐ)共同解決由變更引起(qǐ)的成(chéng)本、進(jìn)度、質量變化。
4. 結束階段
該階段主要進(jìn)行項目成(chéng)果的移交，并把系統交付給維護人員，幫助客戶實現商務目标，結清各種(zhǒng)款項。完成(chéng)這(zhè)些工作後(hòu)應該進(jìn)行項目評估，審核此項目的成(chéng)果并總結項目經(jīng)驗。
5. 售前人員注意事(shì)項
在産品型項目作爲開(kāi)發(fā)成(chéng)果時，相關銷售人員應該注意：對(duì)産品的推銷不應該過(guò)分承諾。如果過(guò)分承諾,會(huì)給後(hòu)續的項目實施帶來困難;一旦承諾沒(méi)有兌現,也會(huì)降低客戶滿意度,影響今後(hòu)合作。如果有附加承諾,一定要以文本形式記錄，讓實施項目經(jīng)理知曉并傳達給項目組成(chéng)員。
注解：在軟件項目中,需要明确以下四種(zhǒng)客戶角色
A. 要明确最終使用部門和用戶,要去了解他們現有的工作方式,要讓他們知道(dào)項目的目标框架,知道(dào)項目要解決他們的哪些困難,但絕對(duì)不是全部困難,這(zhè)樣(yàng)可以較好(hǎo)的控制項目範圍。
B. 要明确需求的提出者,他或者他們要能(néng)夠代表最終客戶群體。提出産品需求的這(zhè)類客戶要具有一定的技術、業務能(néng)力和權威,能(néng)夠真正代表最終客戶團隊的意願和想法,最好(hǎo)有IT基礎,能(néng)夠用IT語言描述問題和需求,以利于雙方的溝通、協作,避免産生歧義。
C. 要明确做需求确認的中層領導,他要把握方向(xiàng)。軟件開(kāi)發(fā)項目是解決實際生産或者管理問題,同時 也是領導系統建設的具體實現,做需求确認的客戶領導,既要了解高層領導的系統建設要點和方向(xiàng),又要谙熟具體業務和生産管理實際。如果是這(zhè)樣(yàng)的客戶領導來把 握和決策,對(duì)企業軟件開(kāi)發(fā)項目的順利進(jìn)展作用非凡。
D. 要明确誰來對(duì)成(chéng)品提意見,誰來驗收。項目驗收環節,是項目的收尾環節,如果驗收的人對(duì)項目初期的需求目标不了解,會(huì)從态度和産品實際使用效果上對(duì)驗收産生負面(miàn)的影響,對(duì)提供産品的企業關閉項目非常不利。根據實踐總結,由需求提出人和确認人來做項 目的驗收工作,能(néng)夠促進(jìn)項目的順利完成(chéng),避免延期。
四、 需求分析
1. 需求分析的過(guò)程
需求過(guò)程包括需求開(kāi)發(fā)和需求管理2個部分：
(1) 需求開(kāi)發(fā)就是對(duì)開(kāi)發(fā)前期的管理，與客房的溝通過(guò)程，可以分爲4個階段：需求獲取、需求分析、編寫需求和需求驗證。
(2) 需求管理：就是軟件項目開(kāi)發(fā)過(guò)程中控制和維持需求約定的活動。包括：變更控制、版本控制、需求跟蹤、需求狀态跟蹤。
2. 需求的層次
需求的層次包括：業務需求、用戶需求、功能(néng)需求、非功能(néng)需求等4個方面(miàn)。
3. 需求開(kāi)發(fā)階段的重點
(1) 提取業務對(duì)象
業務對(duì)象是指系統使用的真實對(duì)象，例如一個供應鏈管理 (Supply Chain Management ,簡稱SCM) 業務對(duì)象主要包括：生産批發(fā)商、零售商、送貨商、顧客多個層次。
(2) 提取業務流程
在了解業務邏輯的過(guò)程中，應該列舉出所開(kāi)發(fā)軟件模塊的各自職能(néng)，并細化每個工作流程，深入分析業務邏輯。
(3) 性能(néng)需求
在分析的前期應該注意客戶對(duì)所開(kāi)發(fā)軟件的技術性能(néng)指标，如存儲容量限制、運行時間限制、安全保密性等。
(4) 環境需求
環境需求是指軟件平台運行時所處環境的要求，如硬件方面(miàn)：機型、外部設備、數據通信接口;軟件方面(miàn)：系統軟件，包括操作系統、網絡軟件、數據庫管理系統方面(miàn);使用方面(miàn)：使用部門在制度上，操作人員上的技術水平上應具備怎樣(yàng)的條件。
(5) 可靠性需求
對(duì)所開(kāi)發(fā)軟件在投入運行後(hòu)發(fā)生故障的概率，應該按實際的運行環境提出要求。對(duì)于重要的軟件，或是運行失效會(huì)造成(chéng)嚴重後(hòu)果的軟件，應提出較高的可靠性要求。
(6) 安全保密要求
在需求分析時應當在這(zhè)方面(miàn)恰當地做出規定，對(duì)所開(kāi)發(fā)的軟件給予特殊的設計，使其在運行中，其安全保密方面(miàn)的性能(néng)得到必要的保證。
(7) 用戶界面(miàn)需求
爲用戶界面(miàn)細緻地規定到達的要求。
(8) 資源使用需求
開(kāi)發(fā)的軟件在運行時和開(kāi)發(fā)時所需要的各種(zhǒng)資源。
(9) 軟件成(chéng)本消耗與開(kāi)發(fā)進(jìn)度需求
在軟件項目立項後(hòu)，根據合同規定，對(duì)軟件開(kāi)發(fā)的'進(jìn)度和各步驟的費用提出要求，作爲開(kāi)發(fā)管理的依據。
(10) 開(kāi)發(fā)目标需求
預先估計以後(hòu)系統可能(néng)達到的目标，這(zhè)樣(yàng)可以比較容易對(duì)系統進(jìn)行必要的補充和修改。
4. 需求分析的任務
需求分析的主要任務是借助于當前系統的邏輯模型導出目标系統的邏輯模型，其流程如下：
(1) 确定對(duì)系統的綜合需求（功能(néng)、性能(néng)、運行、擴充需求）
(2) 制作産品需求文檔 (PRD)
(3) 分析系統的數據需求（概念模型、數據字典、規範化）
(4) 導出目标系統的詳細的邏輯模型（數據流圖、數據字典、主要功能(néng)描述）
(5) 開(kāi)發(fā)原形系統
(6) 從PRD提取編制軟件需求規格說明書（SRS）
注解：SRS格式
1.引言 2系統概述（項目背景、系統目标、核心業務流程） 3.術語說明 4.系統結構（架構圖、功能(néng)圖）
5.主體功能(néng)與業務邏輯（重點） 6.接口需求（内部、外部接口、） 7.網絡總體設計（拓撲網絡、主機、組網）
8.運行環境（Linux、Windows、IIS、 WebLogic、Tomcat、OLAP、OLTP、JDK 8.0 、.NET Framework 4.0等）
五、 面(miàn)向(xiàng)對(duì)象程序設計（略）
1. 設計原則
(1) SRP單一職責鏈
每個類都(dōu)應該隻負責做一件事(shì)。
(2) OCP開(kāi)封閉合原則
軟件的實體（類、模塊、函數等）應該是可以擴展的，但是不可修改的。
(3) LSP替換原則
子類必須能(néng)替換他們的基類型。
(4) DIP依賴倒置原則
高層模塊不應該依賴于低層模塊，二者都(dōu)應該依賴于接口與抽象類。抽象不應該依賴于細節，細節應依賴于對(duì)象。
(5) ISP接口隔離原則
不應該強迫客戶依賴于并未使用的接口，而應該把胖接口分離。
2. 實現UML建模
(1) 業務對(duì)象的提取
(2) 根據SRS、CRC等實現用況建模
(3) 實現業務順序圖
(4) 建立類圖，根據用況圖建立對(duì)象之間的關聯
(5) 繪制活動圖、實現協作圖、狀态圖
六、 開(kāi)發(fā)管理
1. 建立項目計劃
(1) 設計總體架構
針對(duì)系統的實施需要，采取适當的且成(chéng)熟的框架結構。
(2) 控制可擴展度
擴展度過(guò)大，將(jiāng)提高系統的複雜程度，延長(cháng)開(kāi)發(fā)時間；擴展度過(guò)低，會(huì)直接影響系統的二次開(kāi)發(fā)與維護。控制系統的可擴展性，能(néng)提高開(kāi)發(fā)效率，降低系統維護的難度。
(3) 建立基礎設施
合理分配部署軟、硬件等基礎設施所需要的時間與成(chéng)本（例如：服務器的訂購安裝、光纖接入、軟件平台訂購）。
(4) 劃分開(kāi)發(fā)任務
利用WBS（Work Breakdown Structure，工作分解結構）對(duì)可交付結果進(jìn)行分類與劃分。每個項目都(dōu)能(néng)劃分爲多個不同階段，每個階段又可以分爲多個工作包（Work Package），工作包是WBS裡(lǐ)最小的可交付結果，最後(hòu)從工作包中分解出多個開(kāi)發(fā)任務列表。
(5) 部署開(kāi)發(fā)進(jìn)度
一個項目應該按進(jìn)度劃分爲多個開(kāi)發(fā)階段，每個階段的開(kāi)發(fā)周期一般在30~60個工作日以内。在此階段内應該與客戶舉行協商會(huì)議，制定産品路線圖，在開(kāi)發(fā)過(guò)程中邀請客戶積極參與并提出反饋意見。然後(hòu)把該時段内的開(kāi)發(fā)任務按照開(kāi)發(fā)難度，依賴性，重要性等多方條件劃分爲多個叠代周期。
在Scrum 敏捷軟件開(kāi)發(fā)原則中，應該把每個叠代任務進(jìn)一步細分爲多個開(kāi)發(fā)任務列表，再開(kāi)發(fā)任務分配給組員各自負責，而開(kāi)發(fā)時間應該控制在15個工作小時以内。如果開(kāi)發(fā)時間超出15個工作小時，應該考慮把開(kāi)發(fā)任務再度細化。開(kāi)發(fā)任務建議應該由組員自主選擇，而不要使用強制分配的方式。
(5) 測試項目成(chéng)果
每個工作包都(dōu)應該同步部署測試工作，提高項目的質量。對(duì)出錯BUG的工作包應該由測試人員以文本方式記錄，向(xiàng)開(kāi)發(fā)人員展示錯誤所在，讓開(kāi)發(fā)人員及時進(jìn)行修改。
2. 管理開(kāi)發(fā)團隊
(1) 組建團隊
按照工作任務與項目時間的前提條件建立團隊，按團隊職責分配人員，一般團隊人數應該控制在8~12人之間。當團隊人數超過(guò)15人時，應該考慮把團隊分解成(chéng)2個獨立團隊，負責不同的開(kāi)發(fā)任務。
(2) 分配開(kāi)發(fā)任務
在每個叠代周期内（一般是15~30個工作日），應該把每個工作包進(jìn)一步細分爲多個開(kāi)發(fā)任務，再開(kāi)發(fā)任務分配給組員各自負責，開(kāi)發(fā)時間應該控制在15個工作小時以内。如果開(kāi)發(fā)任務的開(kāi)發(fā)時間超出15個工作小時，應該考慮把任務再度細化。而開(kāi)發(fā)任務應該以自由選擇的方式分配給每個組員。
(3) 監督開(kāi)發(fā)進(jìn)度
在叠代的前期舉行一次會(huì)議，讓組員了解開(kāi)發(fā)的進(jìn)展及流程，并以自主選擇的方式分配開(kāi)發(fā)任務。期間可使用Microsoft Project等工具記錄開(kāi)發(fā)流程的進(jìn)展，在每個工作包完成(chéng)開(kāi)發(fā)後(hòu)應該進(jìn)行性功能(néng)的測試，并以文本方式記錄測試結果。
每天舉行一次15分鍾的站立會(huì)議，讓組員交待昨天已完成(chéng)的開(kāi)發(fā)任務，當天將(jiāng)要做的任務，與開(kāi)發(fā)過(guò)程中所遇到的問題。并在每周末舉行一次例行會(huì)議，交待總體進(jìn)程。
在叠代末期舉行一次沖刺會(huì)議，總結項目的進(jìn)展，交行已完成(chéng)的任務，回顧該叠代周期内所遇到的問題，爲下一個叠代做好(hǎo)準備。
(4) 系統測試
對(duì)每個已完成(chéng)的工作包進(jìn)行适時的測試，保證系統質量與性能(néng)。對(duì)測試結果進(jìn)行文本的記錄，并把測試結果與績效工資收入挂鈎，并以真實數據計算組員的績效收入。
(5) 解決開(kāi)發(fā)中所遇到的問題
對(duì)開(kāi)發(fā)人員進(jìn)行前期培訓，可适當按工作能(néng)力分配任務，指導組員的開(kāi)發(fā)。當遇到問題時應該在當天的站立會(huì)議時即時提出，并在15個工作小時内解決所遇到的問題以防止問題進(jìn)一步擴大。
3. 監管産品質量
(1) 質量需要的是計劃、設計而并非審查的。在産品建立的初級，必須與“質量保證”（QA）的部門進(jìn)行協商，以正式文檔的方式，決定恰當的質量策略和标準。
(2) 在開(kāi)發(fā)過(guò)程中使用TDD（測試驅動開(kāi)發(fā)）的模式，提高開(kāi)發(fā)質量。測試人員應該以文本方式記錄bug，并與開(kāi)發(fā)人員共同工作的，把突出的缺陷演示給開(kāi)發(fā)人員，以提高修改的效率。
(3) 在每個叠代的結束時進(jìn)行一次産品效果的演示，從客戶、使用者、高層領導中收集反饋信息。在團隊内部舉行評審會(huì)議，分析測試結果，了解産品性能(néng)，爲下次叠代所需要做的改進(jìn)做好(hǎo)計劃。
4. 修改項目計劃
(1) 在産品需要識别階段，應該以文檔形式記錄産品功能(néng)與開(kāi)發(fā)流程，在開(kāi)發(fā)計劃需要修改時，應該與客戶共同探讨，讓客戶了解計劃修改對(duì)項目進(jìn)度所造成(chéng)的影響。
(2) 項目計劃的修改應該由統一的負責人提出,并且由用戶需求的審核領導者認可。需求變更的提出應該是定期而不是随時的。
(3) 計劃的變更應該做好(hǎo)詳細的文本記錄，讓客戶了解需求變更的實際情況和開(kāi)發(fā)方爲之所付出的成(chéng)本代價。
七、 産品交付
1. 項目的後(hòu)期審核
在項目開(kāi)發(fā)最終完成(chéng)後(hòu)，對(duì)開(kāi)發(fā)人員來說可算是放下工作的重擔，但對(duì)項目經(jīng)理來說這(zhè)往往是項目的關鍵時刻。前期的風險評估、成(chéng)本預算、需求分析、軟件設計都(dōu)是爲了引導項目走向(xiàng)這(zhè)一時刻，此時所有的目光都(dōu)將(jiāng)投向(xiàng)項目管理人員。你可能(néng)發(fā)現大量而瑣碎的工作將(jiāng)要在幾個小時内完成(chéng)，此刻項目經(jīng)理更需要保持清醒與鎮定，把最後(hòu)的工作視爲微型項目來對(duì)待。細緻地對(duì)項目進(jìn)行後(hòu)期的審核，分析項目成(chéng)果、項目團隊的效率、可交付産品的價值，以此審核結果可作爲項目管理經(jīng)驗總結的一部分。
2. 質量評審
在項目交付前，應該把項目交給相關的“質量保證”（QA）部門進(jìn)行質量評審，并邀請典型用戶感受産品的質量。
3. 項目的最終交付
正常情況下在項目的前期就會(huì)訂立項目交付的協議，項目交付方式分爲非正式驗收與正式驗收兩(liǎng)種(zhǒng)。一般在項目完成(chéng)後(hòu)都(dōu)會(huì)先進(jìn)行非正式驗收，讓客戶體會(huì)項目的質量并提出反饋意見，最後(hòu)在客戶肯定産品質量後(hòu)再以書面(miàn)協議的形式進(jìn)行正式的産品驗收。
4. 項目的最終報告
在項目的最後(hòu)，應該制定項目的最終報告，此報告可以視爲是對(duì)該項目一個記錄，但報告不必包含項目的所有方面(miàn)。一般最終報告應該包含以下方面(miàn)：
(1) 最初引進(jìn)項目時的初期項目視圖
(2) 對(duì)該項目的價值評估及支持性信息
(3) 項目的範圍
(4) 項目的開(kāi)發(fā)流程及WBS
(5) 項目的會(huì)議記錄
(6) 項目變更的報告及變更的理由
(7) 與項目相關的溝通過(guò)程文件
(8) 項目的審核報告與客戶驗收報告
(9) 項目成(chéng)員的表現報告
(10) 項目的最終成(chéng)果
軟件開(kāi)發(fā)流程
具體流程如下：
1、啓動
在項目啓動階段，主要确定項目的目标及其可行性。我們需要對(duì)項目的背景、幹系人、解決的問題等等進(jìn)行分析。并制定項目章程和組建項目團隊，包括：産品經(jīng)理、架構工程師、UI工程師、開(kāi)發(fā)工程師、測試工程師等。完成(chéng)以上準備工作之後(hòu)，召開(kāi)項目啓動會(huì)，啓動會(huì)結束後(hòu)則進(jìn)入下一步的工作。
2、規劃
在項目的規劃階段，項目經(jīng)理需要和項目需求方，以及項目的相關幹系人确定項目的範圍，創建WBS(把工作進(jìn)行徹底分解，并梳理出其間的邏輯關系，利用整分合原則組織起(qǐ)來），确定項目的裡(lǐ)程碑和項目計劃。同時制定項目的管理計劃，包括成(chéng)本，質量。風險等方面(miàn)的預測和控制方案。
3、需求
在需求階段，需要對(duì)采集的需求進(jìn)行需求分析，編寫PRD文檔（PRD就是將(jiāng)宏觀抽象化的業務，拆分成(chéng)具體化的功能(néng)需求，并通過(guò)文字或圖像等方式呈現出來）、UI設計、高保真設計。最後(hòu)進(jìn)入需求評審，評審通過(guò)則進(jìn)入下一步的工作。
4、設計
在設計階段，設計人員根據需求文檔，對(duì)軟件系統進(jìn)行設計，包括數據結構、系統架構、業務模型及規則、流程控制、模塊接口等。輸出概要設計，詳細設計文檔，以及數據庫設計說明書等。
5、開(kāi)發(fā)
在明确需求後(hòu)，開(kāi)發(fā)工程師正式進(jìn)入編碼階段，根據産品原型圖、UI效果圖、設計文檔，選擇合适的開(kāi)發(fā)環境、開(kāi)發(fā)工具、開(kāi)發(fā)語言等等進(jìn)行實現，這(zhè)個階段也是個很長(cháng)很難的階段，也是軟件實現的核心。
6、功能(néng)測試
對(duì)軟件進(jìn)行測試是保證軟件質量的重要手段。開(kāi)發(fā)工程師開(kāi)發(fā)完成(chéng)後(hòu)，可以交由測試工程師測試。測試工程師測試到BUG要反饋給開(kāi)發(fā)，開(kāi)發(fā)進(jìn)行修改。功能(néng)測試通常需要進(jìn)行很多次，直到測試通過(guò)，達到質量要求。
7、端到端測試
在端到端測試階段，測試人員根據完整的業務流程設計可以覆蓋全流程的端到端測試案例，然後(hòu)基于端到端案例對(duì)系統的各個模塊進(jìn)行全面(miàn)測試，确保系統能(néng)夠符合需求和驗收質量标準。
8、用戶驗收測試
用戶驗收測試階段，也是通常的UAT(User Acceptance Test)用戶驗收測試階段，用戶驗收測試是最終用戶可以檢查軟件是否符合業務要求的最後(hòu)階段。
UAT由了解要求并了解構建軟件目的的最終用戶執行。此測試是在軟件運行之前執行的最後(hòu)一次測試。最終用戶使用現實生活場景并爲真實數據構建UAT測試用例，用戶驗收測試在最終用戶在上線之前驗證軟件是否滿足這(zhè)些業務需求方面(miàn)具有重要作用。
9、上線
所有測試通過(guò)，并與客戶或者上級達成(chéng)一緻後(hòu)，系統進(jìn)行試運行，穩定後(hòu)上線。
上線包括：上線部署、部署後(hòu)驗證、整理交付物（需求文檔、設計文檔、安裝部署手冊、産品幫助等等）和運維移交。
10、收尾
項目的收尾階段，移交項目成(chéng)果，釋放項目團隊，進(jìn)行項目回顧總結，項目彙報，完成(chéng)項目結項。
軟件開(kāi)發(fā)怎麼(me)去弄？
軟件開(kāi)發(fā)流程是指軟件開(kāi)發(fā)設計的一般流程，包括軟件的總體結構、模塊的組成(chéng)、功能(néng)的設計、程序的編譯、調試、聯調、測試等過(guò)程。主要步驟有：項目分析、确定開(kāi)發(fā)、需求分析、設計、編程、軟件測試、軟件交付、驗收、維護。
軟件開(kāi)發(fā)必須符合某些程序和技術規範開(kāi)發(fā)。軟件開(kāi)發(fā)團隊的每一個成(chéng)員都(dōu)遵循統一的規範來設計，開(kāi)發(fā)，測試和溝通。才可以提高開(kāi)發(fā)的效率。以下是軟件開(kāi)發(fā)流程八個步驟：
1、軟件開(kāi)發(fā)的第一個過(guò)程是對(duì)項目開(kāi)發(fā)的分析和确定。主要是軟件開(kāi)發(fā)商所确定項目開(kāi)發(fā)後(hòu)，需要和需求方讨論确定需求方軟件開(kāi)發(fā)的目标和具體需求。
2、接下來就是需求分析。此步驟也是确定正常實施軟件開(kāi)發(fā)的具體想法的階段。在确定軟件開(kāi)發(fā)可以進(jìn)行後(hòu)，對(duì)客戶的需要實現的軟件功能(néng)進(jìn)行詳細的分析。同時要考慮開(kāi)發(fā)過(guò)程中可能(néng)出現的變化，制定需求變更計劃，随時應對(duì)特殊情況的發(fā)生，保證軟件開(kāi)發(fā)過(guò)程的順利進(jìn)行。
3、接下來就是軟件設計。要根據上一階段的軟件功能(néng)需求分析結果進(jìn)行設計，涉及到軟件設計框架結構、軟件系統模塊和軟件系統的數據庫，主要分爲總體設計和詳細設計兩(liǎng)部分。
4、接下來就是編程的實施步驟。編程也是基于軟件的設計，軟件設計的所有部分都(dōu)是通過(guò)計算機程序代碼實現的。編程由統一規範的程序書寫規則，保證了軟件程序的可理解性。
5、接下來的就是步驟軟件測試。也就是客戶軟件按照設計用編程代碼實現後(hòu)，也就是軟件程序。完成(chéng)後(hòu)，需要修改書面(miàn)的程序，形成(chéng)整體框架，功能(néng)爲單元，組裝，系統三個階段測試，程序的正确性，客戶要求功能(néng)的充分性，以确定軟件是否滿足開(kāi)發(fā)要求，這(zhè)也是一個發(fā)現問題、糾正問題的過(guò)程。
6、軟件開(kāi)發(fā)是通過(guò)以上核心環節完成(chéng)的。接下來就在軟件開(kāi)發(fā)之後(hòu)滿足了客戶的要求，軟件系統交給了客戶，并向(xiàng)客戶交付軟件安裝程序、數據庫的數據字典、《用戶安裝手冊》、《用戶使用指南》、需求報告、設計報告、測試報告等文檔，指導客戶安裝軟件及安裝技巧。提醒客戶關注軟件的運行狀态、環境、服務器及相關中間件的檢測和注意事(shì)項，了解客戶軟件的實際操作方法、使用流程等問題，實現合同規定的任務。
7、用戶接受開(kāi)發(fā)交付的軟件開(kāi)發(fā)後(hòu)，實際操作運行測試。達到滿意的結果後(hòu)，對(duì)開(kāi)發(fā)出來的軟件進(jìn)行驗收。
8、定制開(kāi)發(fā)的軟件通常需要提供售後(hòu)服務，維護軟件，或者根據用戶的新需求修改應用軟件程序，不斷滿足客戶的實際需求。
關于軟件開(kāi)發(fā)管理流程和軟件開(kāi)發(fā)管理流程是什麼(me)的介紹到此就結束了，不知道(dào)你從中找到你需要的信息了嗎 ？如果你還(hái)想了解更多這(zhè)方面(miàn)的信息，記得收藏關注本站。
