基於敏捷開發框架的軟體工程/前言/開發歷史
構建用於軟體工程教學的敏捷框架
摘要 本文描述了我們在職業計算學位課程的軟體工程課程中，如何最終選擇並教授敏捷和結構化方法的特定組合。文章首先介紹了純結構化方法的教學背景，然後描述了八個迭代中敏捷性逐漸增強的過程。最後引入了並描述了當前採用的方法：“敏捷框架”。
關鍵詞：頂石專案，計算機教育，價值主張
1 引言 在本科階段教授軟體工程面臨著向學生呈現一個穩健的學科的同時，又要反映行業現狀的挑戰，因為軟體工程方法自誕生以來一直在不斷發展。敏捷方法的出現標誌著與既定軟體工程實踐的顯著轉變。這造成了Booch (2004) 所謂的“方法論戰爭”。機構在這一“戰場”中摸索前進的路徑非常值得關注，因為它提供了一個模型，可以借鑑如何將未來尚未預見的變革納入其中。本文描述了一個案例研究，即作者在構建“敏捷框架”過程中所走過的路徑。作者面臨的難題是在課程中引入敏捷開發的框架，同時又不失去過去六年成功教授的結構化方法的優勢。儘管Booch (2004) 使用了軍事類比，但我們認為這條路徑更像是一種演變，而不是革命。在接下來的章節中，我們將首先考察教學方法的要求。然後描述所採用的教學方法的演變。
2 軟體工程教學方法的要求 Boehm (2004) 描述了計劃驅動或預測性方法與敏捷方法之間的衝突，並指出“成功的、可持續的軟體開發需要紀律性和敏捷性”。在行業中，能夠快速適應變化可以使組織在競爭中佔據優勢，縮短產品上市時間並更好地滿足客戶需求。但是，為了確保軟體系統的健壯性，必須以健全、有紀律的實踐為基礎進行開發。在採用敏捷方法時，開發人員需要注意不要“把孩子和洗澡水一起倒掉”。傳統方法雖然經常被認為是災難性軟體工程專案失敗的關鍵因素（Standish 1994），但已成功應用於專案超過 40 年。敏捷方法也隨著越來越多的開發人員在新的環境中應用其原則而不斷發展。事實上，Conboy (2004) 斷言，“在資訊系統開發領域，沒有普遍接受的敏捷方法定義”。Noble, Marshall, Marshall, & Biddle (2004) 指出，行業轉向敏捷方法“需要軟體工程教育做出類似的轉變”，並解釋說“以文件為中心的專案方法與學生對更敏捷工作方法的合理期望並不一致”。因此，問題不在於如何教授敏捷，甚至不在於如何在課程中引入敏捷元素（Keefe & Dick, 2004），而是要提出一個連貫的模型來教授“中間地帶”，作為軟體工程教育的可持續方法，併為頂石專案做好準備。透過為學生提供一套連貫的軟體開發技術，他們就可以很好地準備在他們的頂石專案和工作中應用適當的策略。Boehm (2004) 引用Rational Unified Process的架構師Phillippe Kruchten的話，將CMM for Software比作字典——為了說明他想要表達的觀點，“不需要使用所有可用的詞彙”（第23頁）。類似地，一個穩健的框架可以呈現軟體工程的中間地帶，包含來自敏捷和計劃驅動方法的方法論，以及選擇適合手頭工作的工具的策略。軟體工程教學的穩健方法需要哪些要求？它應該包含一個真實的客戶，以反映行業經驗。它應該具有靈活性（以展示對變化的適應能力，包括專案和教學的變化）。它應該以使用者為中心——而不是以計劃為中心的方法，並且它應該適用於各種專案，包括基於硬體和網路的專案。2.1 敏捷模型 2001年，一群開發人員在猶他州的斯諾伯德聚會，討論軟體開發的現狀。他們透過不同的途徑得出了相同的結論——透過使用“輕量級”方法，重點關注溝通、簡潔和擁抱變化，可以提高軟體質量。在這次會議上，創造了“敏捷方法”一詞，並推出了一種全新的軟體開發方法。（Smits，2005）。這些開發人員，包括肯特·貝克（極限程式設計）和肯·施瓦伯（Scrum 方法論），組成了敏捷聯盟，致力於推廣敏捷方法。他們制定了敏捷運動的共享價值觀。敏捷意味著• 個人和迭代優於流程和任務• 可工作的軟體優於全面的文件• 客戶協作優於合同談判• 響應變化優於遵循計劃。3 案例研究：我們的演變 在回顧 1999 年的頂石專案並在評估 1998 年的專案時，我們感到學生沒有獲得足夠的結構，並且這個過程被當作遊戲來對待（這本身是前任講師決定遵循基於模擬的體驗式模型）。IT205課程為期一個學期，在第二學年開設，是頂石專案的必修先修課程。我們決定採取一種使其變得真實的策略：“為真實客戶提供真實專案”，並遵循“賦權”方法（Robinson 1994）。這些決定受到當時描述新經濟需求以及描述學生體驗重要性的論文的影響。我們的目標是創造一個教育環境或文化，使學生能夠融入新經濟。這需要改變方法，將重點放在學生賦權上。這種賦權是多方面的——課程講義以草稿形式呈現；課程內容根據專案和學生的需要進行調整；學生管理與客戶的關係，專案進行自我評估等等。另一個變化是採用一個真實客戶的真實專案，當年為海上主管設計了一個船舶安全系統（Mann & Buissink-Smith，2000）。課程的結構嚴格遵循霍弗、瓦拉奇奇和喬治（2004）所描述的七階段以文件為中心的軟體開發生命週期（SDLC）。課程不包括實施，因為我們認為，如果學生沒有被他們必須構建他們所設計的東西的知識（擔心）所困擾，他們將能夠更好地專注於最佳開發。在這一年及隨後的幾年中，我們採取的方法是嘗試讓學生接觸到“現實世界”的情況，同時保持積極和建設性的學習環境。在學術環境的範圍內，並忠於SDLC，我們努力複製“現實世界的經驗”。2001年，我們對專案組實施了專案交換（Smith, Mann & Buissink-Smith, 2001）。在課堂上反覆使用“被公共汽車撞倒”（ROBAB）場景，以強調專案文件的重要性。在分析階段結束時，一些小組被要求交換他們的專案文件並繼續進行新的專案和文件。對一些學生來說，這種影響是災難性的。一名學生做出戲劇性的反應，一邊怒吼一邊摔門而出：“我來這裡是為了學習和精進，而不是處理別人的垃圾”，但大多數學生都默默地接受了修改，並開始計劃他們的下一步行動。在這種情況下，學生受益於重量級結構。Smith 等人（2001）中的一條學生評論在事後看來尤其有趣
“It was important to keep in mind that the process seemed more important than the final product.” (SF)
當時我們將其理解為“我們專注於學習流程”，但事後我們不禁懷疑，流程是否過於主導，即他們是在學習SDLC而不是軟體工程，或者可能是在專注於客戶的產品開發？乍一看，交換流程似乎與賦權的概念相沖突。大多數賦權的概念至少受到了公交車事故的影響——特別是流程的所有權、選擇權以及可能出現的“紀律的實施者和受害者”等問題。然而，賦權模型並沒有說老師不能挑戰學生，事實上，該模型描述了學生“積極參與教師引導的有意義的體驗”。有一段時間，我們的軟體工程學生認為自己毫無控制權，但很快意識到他們可以做到，這在很大程度上歸功於SDLC提供的穩定性和框架。交換的學生認為我們應該重複這個練習。因此，雖然控制中心會暫時發生轉移，但它很快就會恢復，並且學生對課程的總體感覺是積極的。在隨後的幾年中，軟體工程中繼續使用真實的客戶和專案（Mann & Smith，2004，2005）。學生為這些客戶進行開發，遵循規定的SDLC開發流程（並逐漸增加敏捷性），同時伴隨著理論教學。目的是讓學生體驗軟體工程的全部範圍及其隱含的困難：客戶問題；業務系統的複雜性和團隊合作。敏捷性的提升是三方面的。首先，我們看到原型設計和以使用者為中心的設計越來越重要。第二個因素是主要教材Hoffer等（2005）中SDLC的演變。第一版給出了一個七階段的SDLC，到第三版變成了五階段模型，在第四版中實際上被繪製成一個迴圈。敏捷性提升的第三個因素來自於越來越多樣化的客戶選擇。我們的方法是教授整個SDLC，但重點關注特定客戶專案所需的方面。例如，學習和動機軟體的開發源於一種願望，即引入一個定義不明確的專案，並且比以前的資料驅動系統具有更大的創造性工作潛力。這是教授開發早期階段重要性的完美練習，客戶對他想要什麼幾乎沒有概念，他只認識到透過探索此類開發來“成為全球參與者並擁有更多空閒時間”將使他受益。它也很好地向學生強調了SDLC階段在推進專案中的價值。這個專案讓學生興奮，但隨著專案的進行，他們發現它令人沮喪，因為它定義不明確。動物倫理管理系統是針對開放式動機專案的回應——我們想要一個定義明確的專案。學生小組與一家皇冠研究機構的客戶合作，開發了一個動物追蹤和倫理審批系統。這將與現有系統整合。這種開發適合SDLC的範圍，並且非常適合資料分析階段，因為有很多現有的流程和資訊：在某些情況下，SDLC強加的結構給學生傳遞了錯誤的資訊，即確定性開發的資訊。一個針對三個客戶（小型工程企業的作業管理系統）的範圍明確的通用軟體開發，根據客戶的不同產生了多種結果，這並沒有得到學生的認可。
“why are there so many different outcomes to the same problem…I felt the lecturers let down the process by not doing enough homework on what was going to result…shouldn’t the lecturers have get a tighter reign” (SF)
我們當時的評論：“看到各小組利用SDLC從混亂中建立秩序很有趣……我們需要明確的是，學生的分數是根據他們展示流程的能力而不是實際結果來評定的。”（LecNotes）其他軟體工程專案包括一個學生管理系統專案，這個專案很有趣，因為學生最初認為它太小了，但實際上，當然，這是一個巨大的任務。開發過程揭示了這一點。它成為一個具有挑戰性的專案。來自海事博物館的一位客戶找到我們，說他想要一個網頁。我們立即意識到，他的需求遠不止於此。這項任務很有吸引力，因為它最終比學生最初的理解要大得多。博物館資料的複雜性、許多現有系統的整合以及多個方向的潛力意味著，學生很快意識到，如果沒有一個穩固的開發方法，他們將無所適從。2003年，我們能夠為軟體工程專案的選取制定指導方針。除了真實、令人興奮和有趣之外，我們還指出，專案應該“促進對所選方法（SDLC，特別是每個階段、里程碑）結構的教學。對於早期階段的開發，客戶應該有一個業務問題的概念，但沒有解決方案……促進對每種方法（SDLC）的各種工具和技術的教學。更有創意的專案更適合邏輯設計工作，但難以應用於資料建模。” 2005年，我們調查了專案方法、專案規模和學生學習之間的關係。大型複雜專案強調了正式方法的價值，可以帶來良好的成果，強調了在提供途徑方面的作用：“當我們第一次檢視“黑船長”的簡報時，我們認為該專案的範圍有可能比我們能夠自信地開發的任何專案都要大得多”（SF）然而，這可能會產生一種使人失去力量的影響，一個潛在的巨大專案顯然是不可行的，學生失去了興趣，一些小組將專案的範圍縮減得很小，以至於開發的內容只不過是登入系統。在另一個極端，一個非常小的專案可能會進一步縮小，因為學生由於覺得SDLC流程過於複雜而失去了興趣。介於兩者之間的是一些任務，這些任務最終比學生最初的理解要大得多。在2004年的一項實驗中（Mann & Smith，2005），不同的學習小組被賦予了不同技術範圍的專案。雖然目的是使差異在於規模，但專案的實際差異在於客戶指定其業務問題的能力。同樣，SDLC的結構為學生提供了一個框架，讓他們能夠解決問題。
“At the onset I had no clue of being able to do what was required, so I didn’t have a preconception about what it would look like. I did not think we could do it and definitely not me. Now I see it can be done…” (SF)
不幸的是，該結構並沒有克服第二個問題的反覆無常。相反，學生們只是走過場，經常給出毫無意義的陳述。“由於VideoShop對其當前的影片租賃系統提出了額外要求，因此有機會開發一個新的增強型系統來滿足這些要求。當前系統缺乏管理層和員工在業務上取得財務進步所需的特性”（SW）。兩組學生都沒有對複雜互動的考慮機會做出反應，即使是最強的組也只觸及了我們認定為複雜領域的表面。因此，我們看到一個模型的演變，該模型雖然基於SDLC，但已經越來越靈活。底層框架有幾個優點。它提供了一個在出現問題時可以返回的基本流程，它為開發鋪平了一條清晰的道路，並且具有可預測性以用於教學。與軟體工程的持續發展並行的是行業或畢業設計專案本身的發展。繼我們的軟體工程課程之後，學生將“SDLC與原型設計相結合”描述為他們選擇的方法並不令人意外。這種描述可能意味著什麼的問題超出了計算機教育的範圍：科學和貿易文獻廣泛涵蓋了原型的問題（保真度、進化/革命等），但成功的整合模型仍然難以捉摸。Hakim和Spitzer（2000）認為，“挑戰在於將原型系統地整合到軟體設計和開發生命週期中”。2003年，我們的目標是探索開發方法在成功完成畢業設計專案中的作用，特別是原型設計的程度、性質和整合（Mann & Smith，2004）。透過檢查示例專案的特徵，我們描述了一個開發框架，然後使用該框架描述更大的專案語料庫來驗證此模型。我們將這些提煉成一個示例開發框架。1.“SDLC”識別的開發方法2. 使用原型設計3. 使用強大的功能需求4. 使用低保真度但高互動性原型測試功能需求5. 早期開發穩定的開發平臺6. 原型是整合測試計劃的一部分7. 向客戶交付早期功能交付物8. 穩健的最終交付物9. 仍然需要“正常”設計——原型設計不能取代10. 原型設計用於與客戶的溝通11. 透過革命性（cf 進化性）成熟。硬體的分階段替換。Mann & Smith（2004）中的一個附帶發現是，儘管有一個規定的以文件為中心的流程，但文件頁數與評估成績之間只有微弱的關係。我們還發現，成績較差的組原型設計較少，這是可以理解的；他們做的其他事情也較少。關鍵的是，當他們進行原型設計時，他們也沒有進行“正常設計”或擁有穩定的系統、早期交付等。在早期階段使用原型的成績較差的組也具有非常弱的功能需求，沒有強大的測試計劃等，換句話說，原型設計成為了整個開發過程。處於中等水平的進行原型設計的組往往具有較弱的邏輯和物理設計，相反，他們將開發視為使原型設計穩健的過程。2004年，我們得出的結論是，“透過採用一個既能被視為產生良好產品又能靈活且穩健的流程，可以減少產品和流程之間的緊張關係。我們相信此處描述的開發框架將為畢業設計課程提供基礎”。2004年，此開發框架被所有畢業設計專案強制使用（Mann & Smith，2005），取得了巨大的成功。結果表明，專案組確實遵循了該框架，平均成績顯著提高，不及格成績有所減少。同樣，框架內參數之間的關係表明，對於較弱的組，增量傳統的SDLC流程與早期開發模型並不相容。在實施該框架時，給出了以下說明：我們要求您在敏捷軟體開發的框架下遵循SDLC。這提供了SDLC結構的優勢，同時增加了敏捷開發的靈活性。專案的重點是生產穩健的工作系統（軟體、硬體和維護文件）。規劃、全面的開發文件和流程很重要，但它們是“目的的手段”，重點是內容而不是格式/表示形式。預計您會丟棄開發的大多數模型（儘管您必須保留它們以供評估！）。我們還強調原型設計和測試。我們正在進行兩次SDLC。第一次迭代是為了分析和設計併發布（通常釋出給客戶）一個滿足大多數功能需求的系統。第二次迭代旨在審查第一次迭代在滿足業務需求方面的成功情況，審查功能需求（可能會有更多），並交付一個時尚的“防彈”實施方案。為了強制執行早期交付物等框架元件，設定了以下里程碑：您需要至少交付四個重要的系統。1. 需求原型。在分析階段結束時。這是一個旨在測試功能需求的原型。2. 穩定的平臺（第12周）。您的系統的平臺應開發並測試。例如，對於具有Web前端的資料庫，我們希望您透過Web演示連線性和基本資料庫功能（插入、刪除、查詢、更新）以及任何標準基礎設施（登入等）。3. 主要版本1，第25周。向客戶交付一個滿足其大部分需求的系統。此係統應可用且穩定。4. 主要版本2，第42周。向客戶交付一個滿足其所有需求的生產系統。儘管總體模式顯然是成績有所提高，但較弱的組再次表現出對敏捷方法各個方面與傳統流程之間關係的困惑。這些組的特點是：要麼開發原型並對其進行初始測試，但這成為了專案，隨後的穩健開發很差，要麼不善於將早期開發和測試整合到SDLC中。3.1迄今為止的演變總結所使用的方法主要是系統開發生命週期（基於Hoffer等，2004），但在教授這門課程的六年中已經發展起來。現有系統的侷限性在於它已經變得文件繁重並且對客戶的訪問許可權有限。此外，學生在真正瞭解客戶的需求之前就編寫了需求。由於該專案未實施，因此進入畢業設計專案的學生對實施問題幾乎沒有經驗，並且經常無法產生所需的結果。到2005年，所教授的方法已經發展成為一個修改後的SDLC，但採用了敏捷的“框架”——認識到在整個過程中擁抱變化的重要性。已經引入了使用SoDIS工具的道德風險管理方法，並在設計中應用了可用性重點。二年級所教授的方法可以描述為一個鬆散的SDLC，它非常重視原型設計並且具有很強的使用者重點，但沒有考慮實施問題。與此同時，畢業設計專案是“兩次透過SDLC”，也重點關注原型設計，其中評估的重點是實施和部署。許多敏捷方法都被積極鼓勵（尤其是Scrum會議、結對程式設計、基於測試的開發、使用者參與）。4 敏捷框架方法此處描述了一個開發框架，該框架將敏捷開發方法整合到一個結構化的框架中。專案的重點是生產穩健的工作系統（軟體、硬體和維護文件）。規劃、全面的開發文件和流程很重要，但它們是“目的的手段”，重點是內容而不是格式/表示形式。預計學生會丟棄他們開發的大多數模型，儘管他們必須保留這些模型以供評估，我們將其描述為證據組合。重點是合理流程的證據，因此我們鼓勵花時間註釋圖表，而不是為了演示而整理它們。任何開發方法都可以看作是減少不確定性的過程。在開始時，我們只有一個想法，或者要解決的一個業務問題，存在很多不確定性。最後，我們擁有了一個功能性的系統。影響任何特定時間點不確定性水平的壓力可以看作是互動的工作流（圖1和2）。
Figure 1: Pressures affecting uncertainty.
圖2：五條互動的工作流。
圖3：不同方面的重要性領域每個流的不同比例融合成由可交付成果、指導和與客戶的溝通定義的“領域”（圖3）。此處的領域可以被視為類似於結構化的開發流程，但至關重要的是，根據專案需求允許靈活的路徑。對於軟體工程和畢業設計專案，我們使用三個迭代（圖4）。第一次迭代旨在在開發團隊和客戶之間建立理解。第二次迭代旨在設計和釋出（給客戶）一個滿足許多功能需求的系統。第三次迭代，“穩健交付”，旨在審查第二次迭代在滿足業務需求方面的成功情況，審查功能需求（可能會有更多），並交付一個穩健且時尚的“防彈”實施方案。
圖4：三個迭代。因此，在任何特定時間，學生都在一個由五個工作流組成的領域中工作，該領域是三個迭代之一，並且專注於特定領域。每個領域由其產生的內容定義（表1）。儘管我們的目標是為學生提供一套可在每個領域內使用的工具，但只要他們能夠提供合理流程的證據（請參見下面的證據組合），我們就不太關心該領域的內部細節。領域圖用於說明開發框架中的位置和資訊流（圖5）。這是我們混合結構和敏捷性的方法的核心。鼓勵學生調整這些圖表，這意味著他們不必完成建議的每個任務，只要他們能夠證明從輸入到輸出已經有一個合理的流程（這裡Petri網的概念很有用）。在第二次迭代中，我們僅以敏捷為導向地介紹工具和技術，在第三次迭代中，重點是敏捷技術。表1中的下劃線專案構成了課程評估的基礎。75%的分數來自實施，儘管與上述論點類似，這必須得到“決策依據”的支援。這75%由穩定平臺的10%、第二次釋出的15%和最終交付的50%組成。決策依據在證據組合中給出。此外，客戶滿意度被視為評估的閾值要求。
圖 5：用於說明開發框架中的位置和資訊流的扇區圖（此圖用於第二次迭代：設計概念）。在第一次功能釋出中，重點是向客戶提供一個有用的系統。評估中的元件是及時的、決策的理由和技術能力。在最終的穩健交付中，這些元件與質量保證活動和成果、實施、部署、技術複雜性和客戶文件相結合。5 結論 在本文中，我們描述了我們在構建用於軟體工程教學的敏捷框架時所遵循的路徑。這種方法以一種促進敏捷性併為開發和教學提供底層結構的方式結合了敏捷和結構化方法。6 參考文獻 Beck, K. (2000)。極限程式設計解釋：擁抱變化。新澤西州：艾迪生-韋斯利。Boehm, B. & Turner, T. (2004)。平衡敏捷性和紀律性，困惑者的指南。馬薩諸塞州波士頓：艾迪生-韋斯利。Booch, G. (2004) 前言。在 Boehm, B. & Turner, T. 平衡敏捷性和紀律性，困惑者的指南。馬薩諸塞州波士頓：艾迪生-韋斯利。Conboy, K. & Fitzgerald, B. (2004)。邁向敏捷方法的概念框架：不同學科中敏捷性的研究 http://doi.Acm.Org/10.1145/1029997.1030005 2004 年 ACM 跨學科軟體工程研究研討會論文集（第 37-44 頁）。美國加利福尼亞州紐波特比奇：ACM 出版社。Hakim, J. & Spitzer, T. (2000)。有效的可用性原型設計。ACM 通訊設計特別興趣小組，IEEE 專業通訊學會國際專業通訊會議論文集和第 18 屆 ACM 國際計算機文件會議論文集：技術與團隊合作。47-54 Hoffer, J. A.，George, J. F. & J. S. Valacich (2004)。現代系統分析與設計。第三版。美國雷丁：本傑明·卡明斯。
Keefe, K. & Dick, M. (2004)。在頂點專案中使用極限程式設計。論文發表於第六屆澳大利亞計算教育會議論文集 - 第 30 卷，紐西蘭但尼丁。Noble, J.，Marshall, S.，Marshall, S. & Biddle, R. (2004)。更少的極限程式設計。論文發表於第六屆澳大利亞計算教育會議論文集 - 第 30 卷，紐西蘭但尼丁。Mann, S. & Buissink-Smith, N. (2000)。學生學到了什麼：透過授權學習。國家計算資格諮詢委員會第 13 屆年會，紐西蘭惠靈頓特帕帕，NACCQ。213-220 www.naccq.ac.nz Mann, S. & Smith, L.G. (2004) 開發方法和原型在頂點專案中的作用。第 17 屆 NACCQ 年會論文集，Mann, S. & Clear, T. (編)。基督城。2004 年 7 月 6 日至 9 日。第 119-128 頁。Mann S. & Smith, L.G. (2005) 軟體工程專案的技術複雜性。第 18 屆 NACCQ 年會論文集，Mann, S. & Clear, T. (編)。陶朗加。2005 年 7 月 10 日至 13 日。第 249-254 頁 Robinson, H. (1994) 授權的人類學：課堂互動的變革力量（布里斯托爾：福爾默出版社）。Schwaber, K.，Beedle, M. (2002)。使用 Scrum 進行敏捷軟體開發。新澤西州：普倫蒂斯·霍爾。Smits, H. (2005 年 3 月 12 日，2005 年)。什麼是敏捷軟體開發？2005 年 8 月 25 日檢索自 http://www.agilealliance.org/programs/roadmaps/Roadmap/index.htm Standish。（1995）。混亂。2005 年 9 月 1 日檢索自 http://www.standishgroup.com/ sample_research/PDFpages/chaos1994.pdf Smith, L.，Mann, S. & Buissink-Smith, N. (2001)。“讓一輛滿載授權軟體工程學生的巴士失控。”紐西蘭應用計算與資訊科技雜誌 5(2)：69-74。
SMITH, L.G.，MANN, S. (2004) 專案預測：選擇軟體工程專案，第 17 屆 NACCQ 年會論文集，Mann, S. & Clear, T. (編)。基督城。2004 年 7 月 6 日至 9 日。第 183-190 頁。Standish。（1994）。混亂。2005 年 9 月 1 日檢索自 http://www.standishgroup.com/sample_research/PDFpages/chaos1994.pdf
迭代 1：理解扇區輸出
評估管理文件（小組成立，環境背景）功能需求與客戶建立訪談設計概念倫理設計設計規範系統隱喻和知識庫實現概念原型（第一版）。評估向客戶提出建議迭代 2：功能交付的背景
Evaluation Project estimation
功能需求功能需求文件設計概念設計概念演示設計規範設計規範（樣式指南等），穩定的開發平臺：應開發和測試系統的框架。實現功能交付物（第二版）。向客戶交付一個滿足其大部分需求的系統。該系統應可用且穩定評估功能交付物的分析迭代 3：穩健交付
Evaluation Direction for Iteration 3. Complete Ethical processes.
功能需求重新審視功能需求設計概念設計概念更新，內容製作設計規範樣式指南，系統規範，實施和部署計劃實現穩健交付（第三版）評估專案評估和完成。客戶滿意度。
表 1：每個扇區所需的輸出