今天給各位分享軟件開發過程中的各個階段的知識,其中也會對軟件開發階段包括哪兩個過程活動進行解釋,如果能碰巧解決你現在面臨的問題,別忘了關注本站,現在開始吧!
本文目錄一覽:
- 1、軟件開發的四個階段
- 2、什么是軟件開發工作的五個階段
- 3、軟件的開發過程分為哪幾個階段?
軟件開發的四個階段
軟件開發的四個階段:規劃階段、分析階段、設計階段、實施階段。
一、規劃階段
階段是理解為什么要建立一個信息系統以及確定如何建設的基礎。規劃階段由兩個步驟:
項目啟動期間,系統對于組織的業務價值已經被確認:如何降低成本或增加收入?大多數新系統的想法來自于在IS區域以外(例如來自市場部門,會計部門)系統請求的形式。系統請求提供業務的簡要摘要需要,并解釋了如何支持需求的系統將創造商業價值。信息系統部門與產生信息的人員或部門一起工作要求(稱為項目發起人)進行可行性分析。
將系統請求和可行性分析呈現給信息系統審批委員會(有時也稱為指導委員會),決定該項目是否應該進行。
一旦項目獲得批準,即進入項目管理。在項目管理期間,項目經理創建一個工作計,工作人員的項目,并提出技術以幫助項目團隊控制和指導項目整個SDLC。項目管理的交付成果是一個項目計劃描述了項目團隊如何開發系統
二、分析階段
分析階段回答誰將使用系統的問題,系統將會如何做什么,以及何時何地將被使用。 在這個階段,項目組調查任何目前的系統,找出改進的機會,并為新系統形成一個概念。
這個階段有三個步驟:
1、一個分析策略是用來指導項目團隊的工作。這樣的策略通常包括對當前系統(稱為現狀系統)及其系統的分析問題,然后再設計一個新的系統(稱為待定系統)。
2、下一步是需求收集(例如,通過訪談或調查問卷)。分析這些信息 – 連同項目的投入贊助商和許多其他人– 產生新系統的開發概念。然后系統概念被用作開發一套業務的基礎分析模型,這些模型描述了新系統如何運作開發。
3、系統分析,系統概念和模型被合并成一個文件,稱為系統提案,系統提案被提交給項目發起人等關鍵決策決策者(例如審批委員會成員),由他們決定是否決定項目應該繼續前進。
系統建議是最初的交付成果,描述了新系統應該滿足的業務需求。因為這是新系統設計的第一步,一些專家認為用“分析”作為該階段的名稱是不合適的,有人認為更好的名字是“分析和初步設計”。大多數組織繼續用分析作為該階段的名稱,所以我們也在本書中使用它。只是請記住,分析階段的交付成果既是分析性的,也是高層次的新系統的初始設計。
三、設計階段
設計階段決定系統如何在硬件,軟件,和網絡基礎設施方面操作;并決定用戶界面,表單和報告; 特定的程序,數據庫和將需要的文件。雖然關于這個系統的大部分的戰略決策都是在分析階段制定系統概念的過程中,但是設計階段步驟確切地確定系統將如何操作。
四、實施階段
SDLC的最后階段是系統實施階段,在這個階段系統被真正創建(或者在包裝軟件設計的情況下購買)。這是最受關注的階段,因為對于大多數系統來說,它是開發過程中最長和最昂貴的一部分。這個階段的步驟:
1、系統建設是第一步。創建系統并測試以確保它按設計執行。因為修復bug的成本可能是巨大的,所以測試是實施過程中其中一個最關鍵的步驟。大多數組織給予測試更多的時間和關注,而不是開始寫的程序。
2、按安裝系統。安裝是關閉舊系統,打開新系統的過程。轉換系統的一個最重要的方面是一個培訓計劃的開展,教導用戶如何使用新系統并且幫助管理由新系統造成的改變。
分析團隊為系統建立一個支持計劃。這是計劃通常包括正式或非正式的后審查以及動態地確定系統的主要和次要的需求改變。
什么是軟件開發工作的五個階段
F1第一階段軟件工程,免費下載
鏈接:
提取碼:paem
計劃階段—-開發階段—-維護階段
計劃階段:問題定義,可行性研究,需求分析
開發階段:概要設計,詳細設計,編碼,測試
維護階段:運行與維護
軟件的開發過程分為哪幾個階段?
軟件生命周期分為問題定義、可行性研究、需求分析、開發階段、維護這5個階段。各個階段的主要任務是如下。
1、問題定義
要求系統分析員與用戶進行交流,弄清“用戶需要計算機解決什么問題”然后提出關于“系統目標與范圍的說明”,提交用戶審查和確認。
2、可行性研究
一方面在于把待開發的系統的目標以明確的語言描述出來,另一方面從經濟、技術、法律等多方面進行可行性分析。
3、需求分析
弄清用戶對軟件系統的全部需求,編寫需求規格說明書和初步的用戶手冊,提交評審。
4、開發階段
開發階段由四個階段組成:概要設計、詳細設計、實現、測試
五、維護
維護包括四個方面:
(1)改正性維護:在軟件交付使用后,由于開發測試時的不徹底、不完全、必然會有一部分隱藏的錯誤被帶到運行階段,這些隱藏的錯誤在某些特定的使用環境下就會暴露。
(2)適應性維護:是為適應環境的變化而修改軟件的活動。
(3)完善性維護:是根據用戶在使用過程中提出的一些建設性意見而進行的維護活動。
(4)預防性維護:是為了進一步改善軟件系統的可維護性和可靠性,并為以后的改進奠定基礎。
擴展資料:
軟件常見周期模型:
1、瀑布模型
瀑布模型首先由Royce提出。該模型由于酷似瀑布聞名。在該模型中,首先確定需求,并接受客戶和SQA小組的驗證。然后擬定規格說明,同樣通過驗證后,進入計劃階段?可以看出,瀑布模型中至關重要的一點是只有當一個階段的文檔已經編制好并獲得SQA小組的認可才可以進入下一個階段。
瀑布模型通過強制性的要求提供規約文檔來確保每個階段都能很好的完成任務。但是實際上往往難以辦到,因為整個的模型幾乎都是以文檔驅動的,這對于非專業的用戶來說是難以閱讀和理解的。
2、迭代式模型
迭代式模型是RUP推薦的周期模型,也是我們在這個系列文章討論的基礎。在RUP中,迭代被定義為:迭代包括產生產品發布(穩定、可執行的產品版本)的全部開發活動和要使用該發布必需的所有其他***
元素。
所以,在某種程度上,開發迭代是一次完整地經過所有工作流程的過程:(至少包括)需求工作流程、分析設計工作流程、實施工作流程和測試工作流程。實質上,它類似小型的瀑布式項目。RUP認為,所有的階段(需求及其它)都可以細分為迭代。
3、快速原型模型
快速原型模型在功能上等價于產品的一個子集。瀑布模型的缺點就在于不夠直觀,快速原型法就解決了這個問題。一般來說,根據客戶的需要在很短的時間內解決用戶最迫切需要,完成一個可以演示的產品。這個產品只是實現部分的功能(最重要的)。
它最重要的目的是為了確定用戶的真正需求。在我的經驗中,這種方法非常的有效,原先對計算機沒有絲毫概念的用戶在你的原型面前往往口若懸河,有些觀點讓你都覺得非常的吃驚。在得到用戶的需求之后,原型將被拋棄。
因為原型開發的速度很快,設計方面是幾乎沒有考慮的,如果保留原型的話,在隨后的開發中會為此付出極大的代價。至于保留原型方面,也是有一種叫做增量模型是這么做的,但這種模型并不為大家所接受的。
參考資料來源:百度百科-軟件生命周期
軟件開發過程中的各個階段的介紹就聊到這里吧,感謝你花時間閱讀本站內容,更多關于軟件開發階段包括哪兩個過程活動、軟件開發過程中的各個階段的信息別忘了在本站進行查找喔。