軟件工程快速入門(上）

1什么是SDLC？

軟件開發生命周期(SDLCSoftware Development Lifecycle)是構建軟件的系統過程，可確保構建軟件的質量和正確性。 SDLC流程旨在生產滿足客戶期望的高質量軟件。軟件開發應在預定義的時間范圍和成本內完成。

SDLC包含詳細的計劃，解釋如何規劃，構建和維護特定的軟件。 SDLC生命周期的每個階段都有自己的流程和可交付成果，可以進入下一階段。

為什么選擇SDLC？

這里是SDLC對于開發軟件系統非常重要的主要原因。

它為項目規劃，調度和估算提供了基礎
為一組標準活動和可交付成果提供框架
它是項目跟蹤和控制的機制
提高項目規劃對開發過程中所有相關利益相關者的可見性
增加并提高開發速度
改善客戶關系
幫助您降低項目風險和項目管理計劃開銷

SDLC階段

整個SDLC流程分為以下幾個階段：

階段1：需求收集和分析
第2階段：可行性研究：
第3階段：設計：
階段4：編碼：
第5階段：測試：
階段6：安裝/部署：
階段7：維護：

階段1：需求收集和分析：

該要求是SDLC流程的第一階段。它由高級團隊成員根據業內所有利益相關者和領域專家的意見進行。在此階段還要規劃質量保證要求并識別所涉及的風險。

此階段更清晰地描述了整個項目的范圍以及觸發項目的預期問題，機會和指令。

要求收集階段需要團隊獲得詳細和精確的要求。這有助于公司完成必要的時間表，以完成該系統的工作。

第2階段：可行性研究：

完成需求分析階段后，下一步是定義和記錄軟件需求。此過程在“軟件需求規范”文檔的幫助下進行，該文檔也稱為“SRS”文檔。它包括在項目生命周期中應設計和開發的所有內容。

主要有五種可行性檢查：

經濟：我們能否在預算范圍內完成項目？
法律：我們能否將此項目作為網絡法和其他監管框架/合規處理。
運營可行性：我們能否創建客戶期望的運營？
技術：需要檢查當前的計算機系統是否可以支持該軟件
時間表：確定項目是否可以在給定的時間表內完成。

第3階段：設計：

在第三階段，系統和軟件設計文檔按照需求規范文檔準備。這有助于定義整個系統架構。

該設計階段作為模型下一階段的輸入。

在此階段開發了兩種設計文檔：

高級設計（HLD）

每個模塊的簡要描述和名稱
關于每個模塊的功能的概述
模塊之間的接口關系和依賴關系
識別數據庫表及其關鍵元素
完整的架構圖以及技術細節

詳細設計（LLD）

模塊的功能邏輯
數據庫表，包括類型和大小
界面的完整細節
解決所有類型的依賴性問題
錯誤消息列表
為每個模塊完成輸入和輸出

階段4：編碼：

一旦系統設計階段結束，下一階段就是編碼。在此階段，開發人員通過使用所選編程語言編寫代碼來開始構建整個系統。在編碼階段，任務分為單元或模塊，并分配給各種開發人員。這是軟件開發生命周期過程中最長的階段。

在此階段，開發人員需要遵循某些預定義的編碼指南。他們還需要使用編譯器，解釋器，調試器等編程工具來生成和實現代碼。

第5階段：測試：

軟件完成后，將其部署在測試環境中。測試團隊開始測試整個系統的功能。這樣做是為了驗證整個應用程序是否符合客戶要求。

在此階段，QA和測試團隊可能會發現一些與開發人員溝通的錯誤/缺陷。開發團隊修復了該錯誤并將其發送回QA進行重新測試。此過程一直持續到軟件無錯誤，穩定并根據該系統的業務需求工作。

階段6：安裝/部署：

一旦軟件測試階段結束并且系統中沒有任何錯誤或錯誤，則開始最終部署過程。根據項目經理提供的反饋，最終軟件將被發布并檢查是否存在部署問題。

階段7：維護：

部署系統后，客戶開始使用已開發的系統，發生以下3項活動

錯誤修復 - 由于某些未完全測試的情況而報告錯誤
升級 - 將應用程序升級到較新版本的軟件
增強功能 - 在現有軟件中添加一些新功能

SDLC階段的主要重點是確保繼續滿足需求，并確保系統繼續按照第一階段提到的規范執行。

參考資料

軟件測試精品書籍文檔下載持續更新 https://github.com/china-testing/python-testing-examples 請點贊，謝謝！
本文涉及的python測試開發庫謝謝點贊！ https://github.com/china-testing/python_cn_resouce
python精品書籍下載 https://github.com/china-testing/python_cn_resouce/blob/main/python_good_books.md

流行的SDLC模型

這里是SDLC生命周期的一些最重要的階段：

瀑布模型

瀑布是一種廣泛接受的SDLC模型。在這種方法中，軟件開發的整個過程分為不同的階段。在該SDLC模型中，一個階段的結果充當下一階段的輸入。

該SDLC模型是文檔密集型的，早期階段記錄了后續階段需要執行的操作。

增量方法

增量模型不是單獨的模型。它本質上是一系列瀑布循環。這些要求在項目開始時分為幾組。對于每個組，遵循SDLC模型來開發軟件。重復SDLC過程，每個版本都添加更多功能，直到滿足所有要求。在此方法中，每個循環都充當先前軟件版本的維護階段。對增量模型的修改允許開發周期重疊。之后的循環可以在前一循環完成之前開始。

V模型

在這種類型的SDLC模型測試和開發中，階段是并行計劃的。因此，側面有驗證階段，另一側有驗證階段。 V-Model通過編碼階段加入。

敏捷模型

敏捷方法是一種在任何項目的SDLC過程中促進開發和測試的持續交互的實踐。在Agile方法中，整個項目分為小型增量構建。所有這些構建都是在迭代中提供的，每次迭代持續一到三周。

螺旋模型

螺旋模型是風險驅動的過程模型。此SDLC模型可幫助團隊采用一個或多個流程模型的元素，如瀑布，增量，瀑布等。

該模型采用了原型模型和瀑布模型的最佳特征。螺旋方法是設計和開發活動中快速原型設計和并發性的結合。

大爆炸模型

Big bang模型專注于軟件開發和編碼中的所有類型的資源，沒有或很少計劃。這些要求在它們到來時就被理解和實施。

此模型最適合與較小規模開發團隊合作的小型項目。它對學術軟件開發項目也很有用。這是一個理想的模型，其中要求是未知的或未給出最終發布日期。

小結

結論

SDLC是一個用于構建軟件的系統過程，可確保所構建軟件的質量和正確性
SDLC流程為標準的一系列活動和可交付成果提供了框架
七個不同的SDLC階段1）需求收集和分析2）可行性研究：3）設計4）編碼5）測試：6）安裝/部署和7）維護
高級團隊成員進行需求分析階段
可行性研究階段包括在項目生命周期中應設計和開發的所有內容
在設計階段，系統和軟件設計文檔是根據需求規范文檔準備的
在編碼階段，開發人員通過使用所選編程語言編寫代碼來開始構建整個系統
測試是下一階段，用于驗證整個應用程序是否按照客戶要求運行。
當軟件測試階段結束時，安裝和部署面開始，并且系統中沒有任何錯誤或錯誤
維護面中涉及的錯誤修復，升級和參與操作
瀑布，增量，敏捷，V型，螺旋，大爆炸是一些流行的SDLC模型
SDLC包含詳細的計劃，解釋如何規劃，構建和維護特定的軟件

2瀑布模型

什么是瀑布模型？

瀑布模型是一種將軟件開發劃分為不同階段的順序模型。每個階段都設計用于在SDLC階段執行特定活動。它由Winston Royce于1970年推出。

軟件工程中瀑布模型的不同階段

階段	活動
需求收集階段	從客戶收集要開發的軟件系統的詳細要求
設計階段	規劃編程語言、數據庫或者項目的其他高級技術細節
編碼	在設計階段之后，它是建立階段，這只是編碼軟件
測試階段	測試軟件以驗證它是否按照客戶端提供的規范構建。
部署階段	在相應的環境中部署應用程序
維護階段	可能需要根據客戶要求更改代碼

何時使用SDLC瀑布模型

可以使用瀑布模型

需求不經常變化
應用并不復雜和龐大
項目很短
要求很明確
環境穩定
使用的技術和工具不是動態的，而且是穩定的
資源可用并經過培訓

瀑布模型的利弊

好處	缺點
在下一個開發階段之前，必須完成上一階段	只能在階段期間修復錯誤
適用于需求定義明確的小型項目	對于需求經常變化的復雜項目，這是不可取的
應該在完成每個階段之前執行質量保證測試（驗證和驗證）	測試介入很晚
精心編寫的文檔	文檔占用了開發人員和測試人員的大量時間
項目完全依賴項目團隊，客戶干預最少	客戶的寶貴反饋不能包含在正在進行的開發階段
軟件的任何變化都是在開發過程中進行的	完成的軟件中出現的微小變化或錯誤可能會導致很多問題

3增量模型

什么是增量模型？

增量模型是一個軟件開發過程，其中需求被分解為軟件開發周期的多個獨立模塊。從分析設計，實施，測試/驗證，維護開始逐步進行增量開發。

每次迭代都要經過需求，設計，編碼和測試階段。并且系統的每個后續版本都會將功能添加到先前版本，直到實現了所有設計的功能。

系統在交付第一個增量時投入生產。第一個增量通常是解決基本要求的核心產品，并在下一個增量中添加補充功能。一旦客戶分析了核心產品，就會有下一個增量的計劃開發。

增量模塊的特征包括

系統開發分解為許多小型開發項目
部分系統相繼構建以產生最終的總系統
首先解決最高優先級要求
一旦制定了要求，就會凍結對該增量的要求

需求分析:收集軟件的要求和規格
設計: 在此階段設計了一些高端功能
編碼:在此階段完成軟件編碼
測試:部署系統后，它將進入測試階段

何時使用增量模型？

清楚地理解系統的要求
當產品的早期發布需求出現時
當軟件工程團隊不熟練或訓練有素時
當涉及高風險特征和目標時
這種方法更多地用于Web應用程序和基于產品的公司

優點：

軟件將在軟件生命周期中快速生成
更改要求和范圍更靈活，成本更低
發展階段的變化可以做到
與其他模型相比，該模型的成本更低
客戶可以回復每個版本
錯誤很容易識別

缺點：

它需要一個良好的規劃設計
問題可能是由于系統架構導致的，因此并非所有需求都在整個軟件生命周期中預先收集
每個迭代階段都是剛性的，并且彼此不重疊
在一個單元中糾正問題需要在所有單元中進行校正并且消耗大量時間

4螺旋模型

什么是螺旋模型？

螺旋模型是瀑布模型和迭代模型的組合。螺旋模型中的每個階段都以設計目標開始，最后由客戶審查進度。 Barry Boehm在1986年的論文中首次提到螺旋模型。

Spiral-SDLC模型的開發團隊從一小部分需求開始，并針對這些需求進行每個開發階段。軟件工程團隊在每個不斷增加的螺旋中增加了額外需求的功能，直到應用程序為生產階段做好準備。

螺旋模型階段

計劃

它包括估算迭代的成本，進度和資源。它還涉及了解系統分析員與客戶之間持續通信的系統要求

風險分析
在規劃和最終確定風險緩解策略的同時，確定潛在風險
工程
它包括在客戶現場測試，編碼和部署軟件
評估
由客戶評估軟件。此外，還包括識別和監控諸如進度滑點和成本超支等風險

什么時候使用螺旋方法？

當項目很大時
需要頻繁發布
創建原型時適用
風險和成本評估很重要時
適用于中高風險項目
當要求不清楚和復雜時
隨時可能需要更改
由于經濟優先事項的變化，長期項目承諾不可行

螺旋模型的優缺點

好處

其他功能或更改可在稍后階段完成
由于原型建筑是以小碎片完成的，因此成本估算變得容易
持續或重復的開發有助于風險管理
開發速度快，功能以系統的方式添加
始終存在客戶反饋的空間

缺點

不符合時間表或預算的風險
它最適合大型項目，也需要風險評估專業知識
為了順利運行，需要嚴格遵循螺旋模型協議
文檔更多，因為具有中間階段
對于較小的項目，這是不可取的，它可能會花費很多

5RAD快速應用程序開發模型

什么是RAD（快速應用程序開發）模型？

RAD或Rapid Application Development流程采用瀑布模型;它的目標是在短時間內開發軟件。

SDLC RAD模型具有以下階段

業務建模
數據建模
流程建模
應用程序生成
測試和Turnover

它側重于信息的輸入輸出源和目的地。它強調以小塊形式提供項目;較大的項目分為一系列較小的項目。 RAD模型的主要特點是它專注于模板，工具，流程和代碼的重用。

RAD模型的階段

業務建模：根據各種業務渠道之間的信息流動和分配，設計產品
數據建模:從業務建模收集的信息被細化為一組對業務有重要意義的數據對象
流程建模：轉換在數據建模階段聲明的數據對象，以實現實現業務功能所需的信息流
應用程序生成:自動化工具用于構建軟件，將過程和數據模型轉換為原型
測試和Turnover:由于原型在每次迭代期間都經過單獨測試，因此RAD的整體測試時間會縮短。

何時使用RAD Methodology？

當需要在短時間內（2-3個月）生產系統時
當要求已知時
當用戶將參與整個生命周期
當技術風險較小時
當有必要創建一個可以在2-3個月內模塊化的系統
當預算足夠高時，可以為設計人員提供建模以及代碼生成的自動化工具的成本

SDLC RAD模型的優缺點

好處

靈活且適應變化
當您必須降低整體項目風險時，它非常有用
它具有適應性和靈活性
以腳本，高級抽象和中間代碼的形式傳輸可交付物更容易
由于代碼生成器和代碼重用，減少了手動編碼
由于本質上的原型設計，可能存在較少的缺陷
RAD的每個階段都為客戶提供最高優先級的功能
人員越少，生產力就能在短時間內增加

缺點

它不能用于較小的項目
并非所有應用程序都與RAD兼容
當技術風險很高時，它是不合適的
如果開發人員不致力于按時交付軟件，RAD項目可能會失敗
由于時間裝箱而減少的功能，其中功能被推送到更高版本以在短時間內完成發布
由于RAD開發的應用程序作為原型開始并演變為完成的應用程序，因此降低了可伸縮性
習慣性的進步和問題難以跟蹤，因此沒有文件證明已經完成的工作
需要高技能的設計師或開發人員

模型	瀑布	增量模型	螺旋模型	Rad模型
早期規劃	是	是	是	沒有
回到早期階段	沒有	是	是	是
處理大型項目	不適當	不適當	適當	不適當
詳細文檔	必要	會，但不多	是	有限
成本	低	低	昂貴	低
需求規格	開始	開始	開始	時間盒發布
靈活變革	難	簡單	簡單	簡單
用戶參與	只在開始時	中間	高	只在一開始
維護性	最小	促進可維護性	典型	易于維護
持續時間	長	很長	長	短
風險	高	低	中到高風險	低
框架類型	線性	線性+迭代	線性+迭代	線性
測試	編碼階段完成后	每次迭代后	在工程階段結束時	編碼完成后
迭代	沒有	是（因為并行開發）	沒有	是
可重用性	最少可能	在某種程度上	在某種程度上	是
大體時間	很長	長	長	短
工作軟件可用性	在生命周期結束時	在每次迭代結束時	在每次迭代結束時	在生命周期結束時
目的	高保證	快速發展	高保證	快速發展
團隊規模	大團隊	不是大團隊	大團隊	小團隊
客戶控制	非常低	是	是	是

6原型模型

什么是軟件原型模型？

原型方法被定義為軟件開發模型，其中構建原型，測試，然后在需要時重新加工，直到實現可接受的原型。它還創建了生成最終系統的基礎。

軟件原型模型在項目要求未知的情況下效果最佳。它是一種在開發人員和客戶端之間進行的迭代，試驗和錯誤方法。

原型模型階段

原型模型遵循以下六個SDLC階段：

第1步：需求收集和分析

原型模型從需求分析開始。在此階段，詳細定義了系統的要求。在此過程中，對系統的用戶進行訪談，以了解他們對系統的期望。

第2步：快速設計

第二階段是初步設計或快速設計。在這個階段，創建了一個簡單的系統設計。但是，它不是一個完整的設計。它向用戶簡要介紹了系統。快速設計有助于開發原型。

第3步：構建原型

在此階段，基于從快速設計收集的信息設計實際原型。它是所需系統的小型工作模型。

第4步：初始用戶評估

在此階段，建議的系統將提交給客戶進行初步評估。它有助于找出工作模型的優缺點。評論和建議從客戶收集并提供給開發人員。

第5步：精煉原型

如果用戶對當前原型不滿意，您需要根據用戶的反饋和建議優化原型。

在滿足用戶指定的所有要求之前，此階段不會結束。一旦用戶對開發的原型感到滿意，就會根據批準的最終原型開發最終系統。

第6步：實施產品和維護

一旦最終系統基于最終原型開發，它就會經過全面測試并部署到生產中。該系統進行日常維護，以最大限度地減少停機時間并防止大規模故障。

原型模型的類型

四種原型模型是：

原型
進化原型
增量原型
極端原型

快速原型

快速一次性是基于初步要求。它很快就被開發出來以顯示需求在視覺上的外觀。客戶的反饋有助于推動對需求的更改，并再次創建原型，直到需求基線為止。

在這種方法中，開發的原型將被丟棄，并且不會成為最終接受的原型的一部分。該技術對于探索想法和獲得客戶需求的即時反饋非常有用。

進化原型

在這里，開發的原型根據客戶的反饋逐步完善，直到最終被接受為止。它可以幫助您節省時間和精力。這是因為從頭開始為過程的每次互動開發原型有時會非常令人沮喪。

該模型對于使用未被充分理解的新技術的項目很有幫助。它還用于復雜項目，其中必須檢查每個功能一次。當要求不穩定或在初始階段不清楚時，這是有幫助的。

增量原型

在增量型原型設計中，最終產品被抽取為不同的小型原型并單獨開發。最終，不同的原型被合并為一個產品。此方法有助于縮短用戶與應用程序開發團隊之間的反饋時間。

極端原型：

極端原型方法主要用于Web開發。它由三個連續階段組成。

所有現有頁面的基本原型都以HTML格式顯示。
您可以使用原型服務層模擬數據流程。
這些服務已實施并整合到最終原型中。

原型設計的最佳實踐

在這里，您需要在原型制作過程中注意以下幾點：

當要求不清楚時，您應該使用原型
執行計劃和控制的原型設計非常重要。
定期會議對于保持項目準時并避免代價高昂的延誤至關重要。
用戶和設計人員應該了解原型設計問題和陷阱。
在很早的階段，您需要批準原型，然后才允許團隊進入下一步。
在軟件原型設計方法中，如果需要部署新的想法，就不應該害怕改變先前的決策。
您應該為每個版本選擇適當的步長。
盡早實施重要功能，以便在用完時，您仍然擁有一個有價值的系統

原型模型的優點

在這里，使用Prototyping模型是重要的優點/好處：

用戶積極參與開發。因此，可以在軟件開發過程的初始階段檢測錯誤。
可以識別缺失的功能，這有助于降低故障風險，因為原型設計也被視為降低風險的活動。
幫助團隊成員有效溝通
客戶滿意度的存在是因為客戶可以在很早的階段就能感受到產品。
幾乎沒有軟件拒絕的可能性。
更快的用戶反饋可幫助您實現更好的軟件開發解決方案。
允許客戶端比較軟件代碼是否與軟件規范匹配。
它可以幫助您找出系統中缺少的功能。
它還確定了復雜或困難的功能。
鼓勵創新和靈活的設計。
這是一個簡單的模型，因此很容易理解。
無需專業專家來構建模型
原型作為推導系統規范的基礎。
原型有助于更好地了解客戶的需求。
原型可以改變甚至丟棄。
原型也可作為操作規范的基礎。
原型可以為軟件系統的未來用戶提供早期培訓。

原型模型的缺點

這里是原型設計模型的重要缺點：

原型設計是一個緩慢且耗時的過程。
由于原型最終被丟棄，開發原型的成本完全是浪費。
原型設計可能會鼓勵過多的變更請求。
有時，客戶可能不愿意在更長的持續時間內參與迭代周期。
每次客戶評估原型時，軟件需求可能會有太多變化。
文檔很差，因為客戶的要求正在發生變化。
軟件開發人員很難適應客戶要求的所有變更。
在看到早期的原型模型后，客戶可能會認為實際的產品很快會交付給他。
當客戶對初始原型不滿意時，客戶可能會對最終產品失去興趣。
想要快速構建原型的開發人員最終可能會構建不合標準的開發解決方案。

摘要

在軟件工程中，Prototype方法是一種軟件開發模型，其中構建原型，測試然后在需要時重新工作直到獲得可接受的原型。
1）需求收集和分析，2）快速設計，3）構建原型，4）初始用戶評估，5）精煉原型，6）實施產品和維護; 是原型制作過程的6個步驟
原型模型的類型是1）Rapid Throwaway原型2）進化原型3）增量原型4）極端原型
定期會議對于保持項目準時并避免原型制作方法出現代價高昂的延誤至關重要。
可以識別缺失的功能，這有助于降低故障風險，因為原型設計也被視為SDLC中的風險降低活動。
原型設計可能會鼓勵過多的變更請求。

能力成熟度模型CMM

什么是CMM？

能力成熟度模型(Capability Maturity Model)用作衡量組織軟件過程成熟度的基準。

CMM是在80年代后期在軟件工程研究所開發的。它是由美國空軍資助的一項研究的結果，作為評估分包商工作的一種方式。后來基于1991年創建的CMM-SW模型來評估軟件開發的成熟度，其他多個模型與CMM-I集成在一起

什么是能力成熟度模型（CMM）級別？

初始
重復/管理
定義
量化管理
優化

不同級別的CMM會發生什么？

水平	活動	優點
1級初始	在第1級，該過程通常是混亂和臨時的;能力的特征是基于個人而非組織; 未衡量進展;開發的產品通常是計劃和超出預算;計劃，成本，功能和質量目標的差異很大	沒有
2級管理	需求管理; 估算項目參數，如成本，進度和功能;衡量實際進度;制定計劃和流程; 定義了軟件項目標準;識別和控制產品，問題報告的變化等;項目之間的流程可能不同	流程變得更容易理解;管理人員和團隊成員花費更少的時間來解釋事情的完成方式以及執行事務的時間;項目得到更好的估計，更好的計劃和更靈活;質量已融入項目中;成本可能最初很高，但加班時間會下降;更多文書工作和文件
Level-3定義	澄清客戶要求;解決設計要求，制定實施流程;確保產品符合要求和預期用途;系統地分析決策'糾正和控制潛在的問題	流程改進成為標準;解決方案從“編碼”發展到“工程化”;在整個項目工作中出現質量門，整個團隊參與該過程;風險得到緩解，不會讓團隊感到意外
4級定量管理	統計管理項目的流程和子流程;了解流程績效，定量管理組織的項目;	優化整個組織的流程績效;促進組織中的定量項目管理。
5級優化	及早發現并消除缺陷的原因;確定并部署新工具和流程改進，以滿足需求和業務目標	促進組織創新和部署;推動因果分析和解決方案

下圖給出了在不同CMM級別發生的情況的圖示

實施CMM需要多長時間？

CMM是維護任何軟件開發公司產品質量的最理想的流程，但其實施所需的時間比預期的要長。

CMM實施不會在一夜之間發生
這不僅僅是一個“文書工作”。
典型的實施時間是
- 3-6個月- >準備
- 6-12個月- >實施
- 3個月- >進行評估準備
- 12個月-每個新級別> b

CMM的內部結構

CMM中的每個級別都定義為關鍵過程域或KPA (key process area) ，級別1除外。每個KPA都定義了一組相關活動，這些活動在共同執行時實現了一組對提高軟件能力至關重要的目標

對于不同的CMM級別，有一組KPA，例如對于CMM模型-2，KPA是

REQM-需求管理
PP-項目規劃
PMC-項目監測和控制
SAM-供應商協議管理
PPQA-流程和質量保證
CM配置管理

同樣，對于其他CMM模型，您有特定的KPA。要了解KPA的實施是否有效，持久和可重復，它將根據以下基礎進行繪圖

承諾執行
能夠執行
活動執行
測量和分析
驗證實施

CMM模型的局限性

CMM確定流程應該解決的問題，而不是如何實施
它沒有解釋軟件過程改進的所有可能性
它專注于軟件問題，但不考慮戰略業務規劃，采用技術，建立產品線和管理人力資源
它沒有說明組織應該從事什么樣的業務
CMM在目前正面臨危機的項目中沒有用處

為何使用CMM？

今天，CMM充當軟件行業的“批準印章”。它有助于以各種方式提高軟件質量。

它指導可重復的標準流程，從而縮短了如何完成工作的學習時間
實踐CMM意味著實踐標準協議進行開發，這意味著它不僅可以幫助團隊節省時間，還可以清楚地了解要做什么和期望什么
質量活動與項目完美結合，而不是單獨的事件
它充當項目和團隊之間的通勤者
CMM的努力始終是為了改進流程

摘要

CMM于80年代末首次在美國空軍引入，用于評估分包商的工作。后來，通過改進版本，它被實現為跟蹤軟件開發系統的質量。

整個CMM級別分為五個級別。

1級（初始）：系統的要求通常是不確定的，誤解和不受控制的。這個過程通常是混亂和臨時的。
2級（管理）：估算項目成本，進度和功能。軟件標準已定義
3級（定義）：確保產品符合要求和預期用途
4級（定量管理）：統計管理項目的流程和子流程
5級（成熟度）：識別和部署新工具和流程改進，以滿足需求和業務目標

8多層架構

什么是N-Tier？

N層應用程序是分布在分布式網絡中的三個或更多個單獨計算機之間的程序。

最常見的n層形式是3層應用程序，它分為三類。

用戶計算機中的用戶界面編程
更集中的計算機中的業務邏輯，和
管理數據庫的計算機中的必需數據。

此體系結構模型為軟件開發人員提供了最大靈活性的可重用應用程序/系統。

在N層中，“N”指的是正在使用的層數或層數，如 - 2層，3層或4層等 。它也被稱為“ 多層 架構”。

n層架構是經過行業驗證的軟件架構模型。它通過提供可伸縮性，安全性，容錯性，可重用性和可維護性的解決方案，適合支持企業級客戶端 - 服務器應用程序。它可以幫助開發人員創建靈活且可重用的應用程序。

N層架構

此處描述了n層系統的圖形表示 - 表示層，應用程序層和數據庫層。

根據要求，這三層可以進一步細分為不同的子層。

一些應用這種架構的熱門網站是

MakeMyTrip.com
Sales Force企業應用程序
印度鐵路 - IRCTC
亞馬遜等

要記住一些常用術語，以便更清楚地理解概念。

分布式網絡：它是一種網絡體系結構，位于網絡計算機上的組件僅通過傳遞消息來協調和傳遞其操作。它是位于不同節點的多個系統的集合，但在用戶看來是單個系統。
- 它提供單個數據通信網絡，可以由不同的網絡單獨管理。
- 分布式網絡的一個示例 - 其中不同的客戶端在一側的LAN架構內連接，另一側連接到高速交換機以及包含服務節點的服務器機架。
客戶端 - 服務器體系結構：它是一種體系結構模型，其中客戶端（一個程序）從服務器（另一個程序）請求服務，即它是通過因特網或通過內聯網提供的請求 - 響應服務。

在此模型中， 客戶端將作為一組程序/代碼，通過網絡執行一組操作。另一方面， Server是一組另一個程序，它根據請求將結果集發送到客戶端系統。
- 在此，客戶端計算機向終端用戶提供從服務器請求服務或資源的接口，另一方面服務器然后處理該請求并將結果顯示給最終用戶。
- 客戶端 - 服務器模型的一個例子 - ATM機。銀行是用于在大客戶數據庫內處理應用程序的服務器，并且ATM機器是具有用戶界面的客戶端，具有一些簡單的應用程序處理。
平臺：在計算機科學或軟件行業中，平臺是應用程序可以運行的系統。它由硬件和軟件組合而成，具有內置指令，供處理器/微處理器執行特定操作。
- 換句話說，平臺是一個系統或基礎，任何應用程序都可以運行和執行以獲得特定任務。
- 平臺示例 - 裝有ubuntu或Mac OS X的個人計算機，作為2個不同平臺的示例。
數據庫：它是一種有組織的信息集合，因此可以輕松訪問，管理和更新。
- 數據庫的例子 - mongoDB, MySQL，postgresql和Oracle數據庫是一些常見的Db。

N層架構的類型

有不同類型的N層體系結構，如3層體系結構，2層體系結構和1層體系結構。

首先，我們將看到3層架構，這非常重要。

3層架構

通過查看下圖，您可以輕松識別3層架構有三個不同的層。

表示層
業務邏輯層
數據庫層

在這里，我們采用了一個簡單的學生形式示例來理解所有這三個層次。它包含有關學生的信息 - 姓名，地址，電子郵件和圖片。

用戶界面層或表示層

private void DataGrid1_SelectedIndexChanged(object sender, System.EventArgs e)
{
// Object of the Property layer
clsStudent objproperty=new clsStudent();
// Object of the business layer
clsStudentInfo objbs=new clsStudentInfo();
// Object of the dataset in which we receive the data sent by the business layer
DataSet ds=new DataSet();
// here we are placing the value in the property using the object of the
//property layer
objproperty.id=int.Parse(DataGridl.SelectedItem.Cells[1].Text.ToString());

// In this following code we are calling a function from the business layer and 
// passing the object of the property layer which will carry the ID till the database.
ds=objbs.GetAllStudentBsIDWise(objproperty);

// What ever the data has been returned by the above function into the dataset
//is being populate through the presentation laye.
txtId.Text=ds.Tables[0].Rows[0][0].ToString();
txtFname.Text=ds.Tables[0].Rows[0][1].ToString();
txtAddress.Text=ds.Tables[0].Rows[0][2].ToString();
txtemail.Text=ds.Tables[0].Rows[0][3].ToString();

業務訪問層 -

這是業務層的功能，它接受來自應用層的數據并將其傳遞給數據層。

業務邏輯充當客戶端層和數據訪問層之間的接口
所有業務邏輯 - 如數據驗證，計算，數據插入/修改都是在業務邏- 輯層下編寫的。
它使客戶端和數據層之間的通信更快捷，更容易
定義完成任務所需的正確工作流活動。

// this is the function of the business layer which accepts the data from the 
//application layer and passes it to the data layer.
public class clsStudentInfo
{
	public DataSet GetAllStudentBsIDWise(clsStudent obj)
	{
	 DataSet ds=new DataSet();
	 ds=objdt.getdata_dtIDWise(obj);// Calling of Data layer function
	 return ds;
	}
}

數據訪問層

這是數據層功能，它從業務層接收數據并對數據庫執行必要的操作。

// this is the datalayer function which is receiving the data from the business 
//layer and performing the required operation into the database

public class clsStudentData // Data layer class 
{
	// object of property layer class
	public DataSet getdata_dtIDUise(clsStudent obj)
	{
	 DataSet ds;
	 string sql;
	 sql="select * from student where Studentld=" +obj.id+ "order by Studentld;
	 ds=new DataSet();
	//this is the datalayer function which accepts the sql query and performs the 
	//corresponding operation
		ds=objdt.ExecuteSql(sql); 
		return ds;
	}
}

單層或單層架構：

它是最簡單的一個，因為它等同于在個人計算機上運行應用程序。運行應用程序所需的所有組件都在單個應用程序或服務器上。

表示層，業務邏輯層和數據層都位于一臺機器上。

多層體系結構的優缺點

好處

可擴展性
數據的完整性
可重用性
更容易分布式
提高安全性
提高可用性

缺點

增加工作量
增加復雜性

N層架構技巧與發展

考慮到軟件專業人員必須完全控制架構的所有層，有關n層架構的提示如下

嘗試使用soap XML等技術盡可能地將圖層與其他圖層分離。
使用一些自動化工具生成業務邏輯層和關系數據庫層（數據層）之間的映射。可以幫助建模這些映射技術的工具是 - Entity Framework和Hibernate for .Net等。
在客戶端演示者層中，盡可能將所有客戶端的公共代碼放在單獨的庫中。這將最大化所有類型客戶端的代碼可重用性。
可以將緩存層添加到現有層中以加速性能。

小結：

N層體系結構有助于在一個屋檐下管理應用程序的所有組件（業務層，表示層和數據庫層）。
-在局域網上使用少量用戶的應用程序可以受益于n層架構。
-這種架構設計確定了在因特網上有效地維護，擴展和部署應用程序。

https://www.softwaretestinghelp.com/introduction-to-performance-testing-loadrunner-training-tutorial-part-1/

posted @ 2023-05-19 10:27 磁石空杯閱讀(333) 評論(0) 收藏舉報

刷新頁面返回頂部