敏捷開發框架下的軟體工程/第二輪迭代
第二輪迭代是開發過程的核心。在這一輪中，我們從對業務問題/機會的高層理解，到系統部署並被使用者實際使用，完成了整個過程。
在第一輪迭代中，我們已經
- 建立了開發團隊
- 與客戶建立了牢固的溝通渠道
- 確認了我們與客戶對專案高層需求的共識
- 制定了方法和工作實踐。
在第二輪迭代中，我們將經歷一個完整的開發週期。我們首先詳細地確定需要做的事情，然後制定如何做，最後（你猜對了）去做。在本輪迭代結束時，我們將擁有一個功能完善、實用且已部署的系統。該系統具體的功能（以及哪些功能留到第三輪迭代中完成）我們稍後會再討論。現在，重要的是我們知道交付日期是最重要的變數。這被稱為時間盒，這意味著我們將調整我們想要做的事情，以適應可用的時間和資源。
請記住，每個部門的內部細節並沒有明確定義。更重要的是資訊的流動，我們會在移動到該部門的輸出時不斷完善和增強我們的理解。不過，我們應該始終能夠解釋我們為什麼做某件事，並證明它是如何幫助我們實現目標的。
雖然這裡關注的是結構化流程，但我們根據敏捷原則執行這些流程。我們期望每天的工作以Scrum會議為基礎，以質量和最簡單可行的方式為中心，並將重點放在結果上，而不是為了流程而流程。始終用象徵性的眼光審視這個部門，以a）檢查所有工作流是否被覆蓋，以及b）瞭解你正在做的事情如何直接推動該部門的結果。我們應該儘可能地讓客戶參與整個過程，並在每個部門結束時傳送正式的文件（有時是詳細的提案，有時是更新信）。
評估部門是迭代之間的過渡。在評估部門，我們將回顧迄今為止完成的工作，並規劃下一個部門。這是透過提案正式化我們與客戶互動的重要階段。
功能需求部門可以用一個詞概括：“什麼”。在這裡，我們確定系統需要做什麼（而不是如何做）。
功能需求是描述軟體應該提供的功能、軟體應該具有的特性以及軟體應該實現或幫助使用者實現的目標的說明。功能需求陳述以“系統應該...”開頭。（注意：有些人試圖用使用者故事“使用者應該...”來替代這種說法）。它們通常伴隨著系統需求：“系統應該具有...”
為了獲得這些功能需求，我們經歷了一個收集和理解儘可能多資訊的流程。我們需要很快地理解我們合作的組織的每一個細節。從第一次訪談開始，我們就必須瞭解該業務。幸運的是，我們有一些技巧可以幫助我們收集和結構化這些資訊，從問題之上和之下進行工作。我們使用功能分解來幫助我們理解業務流程，使用資料建模來識別結構和關係，使用邏輯結構來捕獲業務規則。我們還會觀察和詢問使用者。
這些技術將直接引導我們得出定義系統必須做什麼的功能需求。我們測試這些功能需求，確保它們能解決業務機會，並且是可開發的（儘管我們必須小心不要限制我們的思維）。這些需求將成為我們開發的基礎，並傳遞到下一個部門。
在互動設計中，我們開發符合功能需求的系統的外觀和感覺。雖然我們大多數情況下都認為介面是電腦螢幕，但大多數專案都有其他非螢幕介面元素，例如表單、報告，有時還有物理互動系統。
該部門的輸出是一個設計提案，我們將正式向客戶展示。客戶和使用者應該密切參與這個部門。
這是整個開發過程中最有趣和最有創意的階段，但它也是一個需要非常嚴格和謹慎的部門。所有五個工作流可能同時執行，你應該預期同時進行多個任務。
這次有四個技巧
- 測試所有東西：使用者不會像你一樣思考或行動
- 不要作弊：在你最喜歡的 IDE 中構建一個介面，然後倒著進行流程是行不通的。不要忽視對話方塊圖。
- 使用者應該忘記他們正在使用你的系統：成功的衡量標準主要在於與使用者如何完成某項任務的模型相匹配，人們喜歡簡單的東西，所以你應該儘可能地優雅：幾個精心設計的介面遠比大量雜亂無章的介面好得多。
- 重新開始。這個部門很辛苦，但也是最令人滿意的。如果有些事情行不通，那就繼續嘗試；如果行得通，那就測試它，直到它崩潰。在這裡做對要比在編碼了很長時間後才做對容易得多。請記住，對於使用者來說，介面就是系統，其他所有東西都只是機制 - 這必須是正確的。
這裡的資訊流動直接來自功能需求，我們將它們轉化為使用者執行的任務（我們對使用者進行詳細的考慮）。我們將這些任務發展成圖示，代表完成這些任務的最佳方式。然後，我們考慮所有可能出錯的事情，並確保我們的系統可以支援這些錯誤。在進行這些操作的同時，我們會關注開發一個支援我們正在使用資訊的邏輯資料模型。同時，我們也會開發設計主題。從隱喻開始，我們會想出一些關於系統外觀的替代方案。這意味著外觀風格，但可能更重要的是互動風格。
然後是最重要的部分：將主題、對話方塊圖和邏輯資料模型轉換成線框介面。我們將這個介面作為紙質原型與實際使用者進行測試。預期在這裡你會意識到自己完全做錯了什麼，然後回到對話方塊圖、設計主題、任務甚至功能需求。重要的是認識到這個階段的迭代性質，修改過去的決定，新增或更改功能需求是開發過程的一部分。
我們將互動設計開發和測試的結果以互動設計演示/文件的形式呈現給客戶。
在設計規範中，我們詳細說明互動設計。
在本部門結束時，我們將擁有一個藍圖，可以提供給程式設計師。他們應該能夠完全按照我們指定的規範構建系統。設計規範將外觀和方法整合在一起。我們採用設計主題和線框圖，開發詳細的介面規範和完整的已設計產品，如使用者手冊。除此之外，我們還繼續開發資料庫（這裡的關鍵是“沒有魔法” - 所有資料都來自某個地方，並去往某個地方）。物理資料模型是關於系統要儲存和操作的資訊的詳細規範。
除了介面的“如何”，我們還確定後端的“如何”。這從資料庫和系統架構（以圖示表示）開始，然後是關於編碼結構的決定，最後是穩定開發平臺的開發和測試。
穩定開發平臺是構建系統的框架。例如，對於具有 Web 前端的資料庫，我們希望你演示透過 Web（插入、刪除、查詢、更新）以及任何標準基礎設施（登入等）進行連線和基本資料庫功能。
實現階段是根據規範構建系統。這是你獲得迄今為止所有辛苦工作回報的地方。在穩定平臺的基礎上，結合經過設計和測試的物理資料庫以及詳細的介面規範，這個實現不應該是一項巨大的任務。幸運的是，軟體工程也有助於實現階段。我們使用來自極限程式設計（XP）的幾個工具來幫助我們。我們使用模組化和基於模式的開發，使用結對程式設計，使用基於測試的開發。我們進行了廣泛的測試，然後我們進行了更多測試。我們仔細考慮部署系統的最佳方式，然後我們執行它。在進行這些操作的同時，我們還會培訓使用者。
在本部門結束時，我們將擁有一個可執行的系統，更重要的是，它被使用者實際使用。
當系統使用一段時間後，我們需要花時間進行評估。這不僅僅是“它是否有效？”（雖然這也很重要），還包括對功能需求的仔細審查（是否正確？是否遺漏了任何內容？等等），以及對開發所有方面的反思。客戶應密切參與此反思過程。