資料結構
網路
關係型資料庫管理系統 (RDBMS)
作業系統
Java
MS Excel
iOS
HTML
CSS
Android
Python
C 程式設計
C++
C#
MongoDB
MySQL
Javascript
PHP
物理學
化學
生物學
數學
英語
經濟學
心理學
社會學
服裝設計
法律研究軟體工程中的敏捷開發模型
對於某些型別的軟體和特定型別的軟體專案，敏捷軟體工程是傳統軟體工程和敏捷軟體工程之間可以接受的折衷方案。敏捷流程可以在短時間內提供高質量的系統。它強調開發人員和客戶之間持續溝通和合作的必要性。
為了有效執行具有更短上市時間和不斷變化的公司需求等特性的離岸軟體開發專案，我們使用敏捷軟體開發流程模型。具有頻繁客戶交付的迭代軟體開發是敏捷軟體開發中的一項基本策略，它立即解決了離岸開發的主要問題之一：缺乏對專案進度的洞察力。
客戶滿意度、增量軟體交付、小型專案團隊（由軟體工程師和利益相關者組成）、非正式方法和最少的軟體工程工作產品都是敏捷軟體工程概念的一部分。敏捷軟體工程原則優先考慮及時交付功能軟體增量，而不是分析和設計。
在專案開發過程中，敏捷團隊可以適應變化。
敏捷開發承認專案計劃需要適應性。
敏捷培養團隊結構和思維方式，促進開發人員和客戶之間的溝通。
敏捷使客戶和開發人員不再分離。
敏捷強調快速交付可操作軟體的價值，同時淡化中間工作項的相關性。
如果專案團隊能夠自由地簡化活動並以消除非必要工作項的方式進行準備，那麼任何軟體流程都可以從敏捷中獲益。
敏捷流程
敏捷流程基於三個基本假設 -
很難預測哪些客戶優先順序或需求會發生變化，哪些不會。
許多型別的軟體開發和設計任務是交織在一起的（構造用於證明設計）
從計劃的角度來看，分析、設計和測試不像人們希望的那樣可預測。
為了應對不確定性，敏捷流程必須逐步調整。增量適應需要基於在短時間內提供的軟體增量（可執行原型）的評估的客戶輸入。
敏捷原則
最高目標是透過及時且持續地交付有用的軟體來滿足客戶。
應歡迎法規的變化。即使在開發過程的後期，容忍變化也被視為為客戶贏得競爭優勢。
頻繁交付功能軟體，偏向於更短的交付時間（例如，每 2 或 3 周）
在專案期間，業務人員和開發人員必須每天進行協作。
圍繞積極進取的人員構建專案，為他們提供所需的氛圍和支援，並相信他們能夠完成任務。
在開發團隊內部，面對面的交流是傳遞知識最有效的方式。
工作的軟體是衡量進展的最重要指標。
敏捷方法鼓勵長期開發，因此開發人員和客戶應該能夠永遠繼續開展專案。
持續關注技術卓越和智慧設計可以提高敏捷性。
簡單性（定義為最大限度地減少未完成的工作量）至關重要。
自組織團隊提供最佳的體系結構、需求和設計。
團隊定期思考如何變得更成功，並相應地改變其行為。
影響人類的因素
敏捷開發團隊成員必須具備以下特徵 -
勝任力
共同的目標
協作
決策能力
解決模糊問題的能力
相互尊重和信任
自我組織
敏捷流程模型
極限程式設計 (XP)
自適應軟體開發 (ASD)
動態系統開發方法 (DSDM)
Scrum
Crystal
面向特徵的開發 (FDD)
敏捷建模 (AM)
極限程式設計
使用面向物件的方法。
最重要的行為
組織（使用者故事由客戶價值建立和排序）
概念化（首選簡單設計，CRC 卡和設計原型是唯一的工作產品，鼓勵使用重構）
編碼過程（專注於單元測試以練習故事，強調使用結對程式設計來建立故事程式碼，持續整合，並使用冒煙測試）
檢查（在編碼之前建立的單元測試使用自動測試框架實現，以鼓勵使用迴歸測試，每天進行整合和驗證測試，驗收測試側重於客戶可見的系統特性和功能）
自適應軟體開發
當一群自主代理協同工作以解決超出任何單個參與者能力的問題時，就會發生自組織。
強調自組織團隊、人際合作以及個人和團隊學習。
自適應迴圈的特徵
階段 -
使命驅動型
元件化
迭代
時間盒
構思（專案啟動並進行自適應迴圈計劃）
協作很重要（需要來自凝膠團隊的團隊合作，首選聯合應用程式開發作為需求收集方法，建立迷你規範）
學習（實現和測試元件，焦點小組提供反饋，正式的技術審查，事後分析）
動態系統開發方法
透過在安全的環境中使用增量原型，為開發和管理滿足嚴格期限的系統提供框架。
使用帕累託原則（80% 的專案可以在交付整個專案所需的 20% 的時間內交付）
每個增量僅具有足以允許您進入下一個增量的功能。
時間盒用於透過固定時間和資源來確定每個增量中將提供多少功能。
遵循的原則
積極使用者的參與
擁有決策權的團隊
交付成果的驗收基於其對業務目的的適用性。
需要迭代和增量開發才能得出精確的業務解決方案。
在整個開發過程中進行的所有修改都可以撤消。
在高級別上，需求是基線化的。
測試整合到整個生命週期中。
利益相關者以協作和合作的方式共同工作
在整個生命週期中發生的活動
可能性研究（確定需求和約束條件）
業務研究（確定提供業務價值所需的功能和資訊需求）
功能模型迭代（生成一系列增量原型以向客戶演示功能）
設計和構建迭代（重新訪問原型以確保它們為終端使用者提供業務價值，可能與功能模型迭代同時發生）
實施（最新迭代置於操作環境中）
Scrum
Scrum 原則 -
使用小型工作組來增強溝通、減少開銷並最大化非正式知識交流。
為了確保建立最佳結果，該過程必須能夠適應技術和商業難題。
該過程生成可以檢查、修改、測試、記錄和擴充套件的定期增量。
開發中的工作以及執行工作的人員被劃分為簡潔的、低耦合的部門。
在構建產品時，會進行測試和記錄。
允許您在任何時候選擇宣告產品已完成。
開發活動由過程模式定義。
產品待辦列表（按優先順序排序的需求或功能列表，為客戶提供業務價值，隨時可以新增條目）
衝刺（完成待辦列表中一項所需的工作單元，必須符合預定義的時間盒，受影響的待辦列表條目凍結）
每日站會（每天15分鐘的會議），涵蓋以下主題：自上次會議以來完成了什麼？您遇到了哪些挑戰？在下一次會議召開之前將完成什麼？
演示（向客戶交付軟體增量以供評估）
Crystal
在提供功能性軟體這一主要目標和為下一階段做好準備這一次要目標的驅動下，制定了一種開發策略，該策略在資源受限的創新和溝通遊戲中優先考慮敏捷性。
水晶方法的基本原則 -
面對面溝通總是更經濟、更快捷。
隨著流程變得越來越嚴格，團隊變得不堪重負，難以應對專案工作的變化。
隨著專案規模的擴大，團隊規模擴大，流程變得更繁重。
隨著專案變得越來越重要，流程的某些方面將需要變得更加正規化。
隨著反饋和溝通效率的提高，中間工作項的需求減少。
流程、形式和文書工作都受到紀律、能力和理解的制約。
不在核心專案路徑上的團隊成員可以利用空閒時間開發產品或協助核心專案成員。
採用增量開發方法，專案時間線為1到3個月。
在專案開始之前、增量開發過程中以及增量交付之後，都會舉行反思研討會。
水晶方法
透明水晶（小型、低關鍵性專案）
橙色水晶（大型、中等關鍵性專案）
橙色網路水晶（典型的電子商務應用程式）
面向特徵的設計
面向物件軟體工程過程模型在實踐中
客戶重視的功能，可在兩週或更短時間內部署。
FDD的理念
強調團隊成員之間的協作。
使用基於特徵的分解和軟體增量整合來控制問題和專案複雜性。
利用口頭、圖形和文字方式傳達技術資訊。
增量開發、設計和程式碼審查、SQA 審計、度量收集和模式使用都有助於提高軟體質量（分析、設計、構建）
構成框架的操作
建立綜合模型（包含一組描述要構建的應用程式業務模型的類）
列出功能（從領域模型中提取的功能，功能被分類和優先順序排序，工作被分解成兩週的塊）
制定基於功能的計劃（根據優先順序、工作量、技術問題和時間安排依賴關係評估功能）
基於功能的設計（選擇與功能相關的類，編寫類和方法序言，開發初步設計細節，為每個類分配所有者，所有者負責維護其工作包的設計文件）
基於功能的構建（類所有者將設計轉換為原始碼並執行單元測試，整合由首席程式設計師執行）
敏捷環境中的建模
一種輕量級、基於實踐的範例，用於成功建模和記錄軟體系統。
建模原則 -
目標明確的模型
使用多種模型
只取所需（只保留具有長期價值的模型）
內容的重要性超過表示形式的重要性。
您應該熟悉您用來開發模型的模型和工具。
本地化您的適配。
收集需求並對分析進行建模
協作確定客戶想要做什麼。
在建立需求模型之後，與客戶的協作分析建模繼續進行。
架構建模
初步架構源自分析模型。
架構模型必須在環境方面準確且對開發人員友好。
瀏覽量 1K+
