敏捷開發框架下的軟體工程/全過程
原型: 建立一些東西來回答具體的問題，從中學習並繼續前進。
客戶滿意度
客戶參與
文件（和證據組合）
部門 {{Adfmetabox |title |Bite |2 hours |Inputs |Evidence |Stakeholders }}
| 標題 |
|
|
本書中的彩虹扇形圖旨在作為引導您自己的專案的模板。在前兩次迭代中，我們將方框連線起來，在第三次迭代中，扇形是空白的。
訣竅是從左邊的輸入到右邊的輸出。
1. 畫出您從輸入到輸出所需的活動。如果某些東西沒有朝向輸出方向，那麼問問自己，我們為什麼要這樣做？
2. 注意所有五個工作流。
- 理解
- 構建
- 評估
- 溝通
- 引導
頂點專案是大多數資訊科技學位的重要組成部分，奧塔哥理工學院的資訊科技學士（B.InfoTech）也不例外。完整的專案列表可以線上獲取：www.otagopolytechnic.ac.nz
Fincher 等人（2001）描述了專案的“成功關鍵”。雖然他們希望這些措施用於建立專案，而不是具體的專案，但它們確實為成功的專案提供了一個有用的衡量標準。奧塔哥 B.InfoTech 在完整系統方面可能獨樹一幟，包括硬體和軟體。
頂點課程設計中一個重大的挑戰是過程與產品之間的關係。作為學者，我們認為強大的過程將產生好的產品，但講師在確定合適的過程方面卻很少有指導。一個主要問題是將原型系統地整合到軟體設計和開發生命週期中。在本文中，我們確定了一個成功進行這種整合的開發框架。該框架是根據示範專案開發的，並提供了一個最佳系統框架。該框架還用於探索較弱專案的開發過程。
本章旨在探討開發方法論在成功頂點專案中的作用，特別是原型設計的程度、性質和整合。
在計算開發專案中，開發方法論的選擇是一個永恆的爭論話題，就像程式語言的選擇一樣。任何給定專案都需要選擇一種方法論，選擇可能基於無數因素。許多教育機構都包含一個頂點專案，學生，通常是小組，合作完成一個重要的專案。開發過程的選擇在頂點專案中變得至關重要（Beasley 2003; Chamillard 和 Goold 2003; Bridgeman 2003, Clear 2003）。在計算教育中，引入教學要求使得選擇變得複雜。我們面臨的問題不僅是找到最佳的開發方法，而且是找到最佳的教學方法。
Clear 等人（2001）描述了他們在頂點課程設計中所謂的“過程與產品之間的張力”（p95）。他們指的是頂點課程的重點應該是開發過程還是開發的產物：一個可工作的系統。他們認為，由於頂點課程模擬了專業人士的工作，“建議採用並遵循一種可接受的方法論或過程。選擇何種具體的方法論或其變體並不重要，重要的是使用某種正式過程”。Chamillard 和 Braun (2002) 這樣描述了這個問題
| “ | “鑑於過程在實際軟體開發活動中的重要性，我們希望確保我們的學生能夠充分了解過程問題。另一方面，我們也不希望我們的學生認為，只要遵循了適當的過程，他們生成的是否是一個可工作的產品並不重要！因此，我們還必須適當強調學生正在開發的產品，以確保它滿足專案要求”。（p229） | ” |
那麼，頂點專案適合什麼過程？傳統上，大多數頂點課程都使用軟體開發生命週期 (SDLC) 的派生版本，例如 Hoffer 等人（1999）所描述的版本。近年來，教學設計師將它與敏捷建模，特別是原型設計的元件混合起來（Fincher 等人 2001）。
Hakim 和 Spitzer (2000) 認為“挑戰在於將原型系統地整合到軟體設計和開發生命週期中”。
在本文中，我們的目標是確定一個成功的專案框架。
在接下來的部分中，我們將檢查示範專案的開發過程的定性證據。選擇小組是為了提供一系列的專案類別。來自學生反思性評論的引言說明了決策和過程的複雜性。
 案例研究 ACKI |
|
小組: Kevin Barclay
ACKI 專案旨在開發一個放置在電腦和鍵盤之間的盒子，供行動不便的使用者使用 (Barclay 等人，2001)。這是一個針對獨特使用者需求的通用解決方案。該盒子模擬鍵盤，可以從任何裝置接收模擬或數字輸入。 開發過程中的幾個方面尤為突出。建立了一個穩定的測試平臺，這意味著可以建立詳細的測試協議，並整合測試程式。小組詳細記錄了過程，並定義了測試結果。不同級別的原型滿足不同的需求，測試平臺用於調查技術問題，而白板筆模擬操縱桿以探索控制水平，輸入裝置需要做什麼。 儘管這是一個硬體專案，但該專案與敏捷開發框架相符。對於每個元件，都使用了“微型生命週期”，並進行了分析-設計-測試迴圈。
|
| 案例研究 學校網路 |
|
小組: Boudewyn Erkens, Lorna Lou, Rebecca Sidaway
該專案旨在滿足當地一所小學的 ICT 需求。除了網路設計和實施外，小組還與教師密切合作，滿足其專業發展需求。雖然該專案涉及硬體和培訓，但小組遵循了 SDLC 的自上而下的結構。特別是在培訓需求方面，小組透過培訓需求分析來滿足需求，然後設計和實施課程。網路解決方案使用快速安裝和借用裝置進行了原型設計，學校使用了一個月，以檢視解決方案是否滿足他們的需求。
|
5.7 替代 CAD 介面 SDLC 被用作開發一個繪圖板介面，用於建築 CAD 系統 (Lawton 和 Meikle，2003) 專案的基礎。該專案的大部分工作是開發和配置硬體，然後對每次迭代進行使用者測試。團隊開發了許多不同的原型系統，儘管使用了許多相同的元件，但他們每次都從頭開始在他們開發的平臺上進行構建。
“原型設計的一些方面被反覆... 而且又一次地重新審視。某些方面被證明過於耗時，並且在一個案例中，由於這個原因，一個決定不得不被放棄。”
“紙質”介面將在建築製圖學生的協助下開發。將要求學生評估每個版本的介面，並提出建議或批評。這將影響後續的介面草稿，以及選單檔案（CAD 應用程式的介面程式碼）的要求。
硬體將被組裝和安裝，以便與潛在使用者一起進行測試。與批評一樣，觀察和建議也將被評估並納入系統。重複此階段，直到滿足功能需求。”
分析、邏輯設計和原型設計的迭代階段同時進行。涉及原型設計的專案方面包括繪圖表面、框架的構建、指向裝置、投影系統和 AutoCAD 介面的定製。遇到了問題，也發現了系統意想不到的優勢。
5.8 簡訊 該小組的目標是開發一個透過手機控制多個遠端裝置的系統。該系統涉及多個硬體和軟體元件的開發和整合。小組遵循 SDLC 流程，在分析中開發了一個硬體和軟體原型：“我們拼湊了一個應用程式……在該測試應用程式執行後，我們發現設計中存在一些問題……現在我們已經確定了功能需求，並簽署了協議，可以繼續深入規劃……”
小組開發了一個可工作的系統“原型”，並在實施階段按順序更換了主要元件。
5.9 Edubuilder 建築行業是一個存在多層複雜性、互動作用、不同時間尺度和決策後果的領域。這是技術支援的良好互動式學習體驗的主要目標。該專案承擔了提供一個內容管理系統，該系統所在的領域擁有大量的專家知識，但很少有好的資訊來源利用互動式媒體。小組遵循 SDLC，從梳理大量建築標準開始，並努力尋找一個可以將它們聯絡在一起的主題。他們使用了幾個比喻，然後又回到了建築本身和專案計劃圖上。他們開發了一個圖示原型，並在與幾個“客戶”的討論中，他們發現不同時間尺度、上下文和使用者對甘特圖的看法，這才是難以捉摸的概念。為了檢驗這一前提，小組開發了幾個原型來證明這一概念，這些原型從單個草圖到系統的半功能互動式模型不等。這些原型用於明確測試前提的各個方面。為了實現這一概念，小組意識到需要一些複雜的技術程式。小組使用了精心管理的測試製度，該制度確定了測試的必要性、程式碼的開發、測試程式和記錄。由於需求定義明確，開發了一個穩定的系統，並使用了嚴格的測試製度，因此專案結束時的實施非常迅速，但交付成果既健壯又實用。5.10 為西裝租賃開發資訊系統 儘管這個專案是傳統資訊系統的理想選擇，但客戶並不完全相信他需要一個計算機化的系統。為了消除這種顧慮，小組在計算機上開發了一個早期原型，該原型反映了紙質系統。客戶相信，他將提高效率，而不會失去紙質系統的基礎。該原型還允許開發強大的功能需求。小組還能夠透過在客戶的場所同時執行原型和現有系統來測試他們對當前系統的理解。分析完成後，小組放棄了原型。然後他們經歷了正常的邏輯和物理設計，涉及幾個原型。客戶在該階段五個月內無法使用，但小組能夠根據他們開發的強大功能需求來測試原型。最終的系統在業務運營方面與最初的原型有很大不同，但它保留了紙質系統的外觀。 5.11 Familtrak 熟悉之旅（“Famil”）是指旅行社人員進行的旅行，以熟悉他們正在銷售的產品。他們應該在返回後寫一份報告，但幾乎從不這樣做。該專案的客戶想要一個系統來促進此類報告的釋出和傳播。這不僅僅是一個簡單的資料庫，解決方案涉及網頁、XML、GIS 和高度的互動性 (Hamilton 2003)。最初的功能需求是在小組和客戶之間協商的。然後，小組花費數週時間驗證和改進功能需求。這包括對工作模式進行大量觀察、問卷調查和紙質原型。原型最初用於表示系統需要執行的功能集。在邏輯設計中，使用了第二個紙質原型來開發系統的結構。小組首先在紙面上與客戶一起測試了原型，然後他們巧妙地掃描了紙張並將它們連結在一起，從而產生了一個低保真但高互動性的原型。這意味著“測試在任何程式碼編寫之前就已完成”。該系統在截止日期前三個月釋出給客戶進行實際生產使用，然後小組能夠致力於完善系統並開發一些更困難的方面（連結空間和多媒體方面）。 6 示例流程 從示例專案中，一些主題出現了。我們將這些主題提煉成一個示例開發框架。
1. “SDLC”識別的方法 2. 原型使用 3. 強大的功能需求使用 4. 使用低保真但高互動性的原型測試功能需求 5. 早期開發穩定平臺 6. 原型是整合測試計劃的一部分 7. 向客戶交付早期功能產品 8. 穩健的最終產品 9. 仍然需要“正常”設計 - 原型設計不會取代 10. 原型用於與客戶進行溝通 11. 透過革命性（與進化性相比）的成熟。分階段硬體更換。
這些因素中的一些可能是質量的預期衡量標準；它們出現在這裡並不令人驚訝：我們沒有關注拼寫或良好的組內溝通，但這些也是這種框架所期望的。然而，我們擁有的證據表明，示例小組確實做了這些事情。有些因素令人驚訝；我們沒有預料到會發現示例專案中的成熟過程如此相似。
7 驗證 為了進一步探討開發框架的重要性，我們對所有已記錄專案的完整集進行了分析。第一作者與一個不瞭解專案歷史的第三方合作，對十一個因素中的每一個因素進行五分制評分。這些分數與專案的成績進行比較。需要注意的是，本分析使用成績作為質量衡量指標，我們認識到這裡還有其他因素在起作用。我們也認識到作者在進行這種評估時可能存在的偏見，儘管這應該會在一定程度上被公正的第三方所緩解。對十一個因素進行簡單彙總，與每個專案獲得的成績之間存在很高的相關性（r=0.756）（圖 3：對於此統計資料以及後續統計資料，示例專案除外）。此外，這種關係不受專案型別的影響。
圖 3：流程評分彙總與質量密切相關，不受專案型別影響。
圖 4 顯示了根據開發框架評估的所有專案。所有因素都與成績呈正相關。可以識別出一些異常專案：“78 HW A”專案是一個沒有遵循框架的硬體採購專案，而 “174 IS A-”專案是一個回顧性專案，該專案雖然遵循了流程，但證據不足，導致成績略低。構成此評分的大多陣列成因素可以被認為是質量的一般衡量指標。其他指標，例如團隊合作的效率或拼寫，可能也會具有正相關性。這仍然有用，我們也會將這些因素確定為關鍵成功因素。一些因素並不那麼明顯；實施型別——革命性或階段性替換，而不是演進式——在由優秀團隊執行的模式中令人注目。
圖 4：按開發框架評估的專案，按成績從上到下排序。較深的陰影表示使用此因素時的 4 或 5。示例專案位於線以上。
也許比流程因素的總體相關性更重要的是它們在頻譜兩端的關係——較差的團隊在做什麼不同？仔細觀察圖 4（或檢視相關性——未顯示），會發現一些有趣的模式。較差的團隊進行的原型設計較少，這是可以理解的；他們也較少做其他事情。關鍵的是，當他們進行原型設計時，他們並沒有同時進行“正常設計”，也沒有穩定的系統、提前交付等。在早期階段使用原型的較差團隊也具有非常薄弱的功能需求，沒有強大的測試計劃等，換句話說，原型成為了整個開發。中等範圍內的團隊，他們進行原型設計，往往有較弱的邏輯和物理設計，相反，他們將開發視為使原型更穩固的過程。這些模式也可以從評審小組對成績排名前一半的團隊的評論中看出來（表 2）。
將程式碼寫成概念驗證原型，然後嘗試設計它。'團隊的一半在設計，另一半在編碼，而且速度不同'
在獲得原型時做出的技術決策困擾了後期的開發，良好的流程受技術技能的限制
功能原型在早期開發出來，但沒有設計，這個糟糕的設計一直存在，將糟糕的流程數字化，因為 SDLC 的一些階段被遺漏了。
最初的概念是用原型完成的，任何被認為太難的東西都沒有被視為 SDLC 中的真實需求，而是從最初的想法跳躍到實施。
無法實現太多技術複雜性，因此縮減了範圍以使原型可交付。
成功地完成原型後，在接下來的一年裡幾乎沒有進展。在最後一刻，他們獨立地實施了剩下的部分，並回顧性地進行了 SDLC 分析。
為概念驗證開發的原型卡住了 SDLC，非常薄弱。客戶很滿意，但技術複雜性不足。
手掌開發。從來沒有穩定的平臺。無法使其正常工作。
表 2：評審小組對 C 組和不及格組的評論
8 結論 Hakim（2000）認為，“挑戰在於將原型系統地納入軟體設計和開發生命週期”。在本文中，我們已經確定了一個成功地實現了這種整合的開發框架。該框架是從示例專案中發展而來的，並提供了一個最佳系統框架。
Stein（2002）也確定了成功專案共有的屬性。但警告說，“然而，對於我發現的每個屬性，……我都能找到包含相同屬性的不太成功的專案”。透過研究開發框架與較差團隊正在做什麼的比較，我們已經能夠確定該框架如何適用於較弱的團隊。特別是，我們證明了較弱的團隊進行原型設計而不是正常設計，或者相反，堅持對 SDLC 的天真看法，導致設計測試不足的風險。
本文沒有考慮專案的技術複雜性。Goold（2003）討論了團隊成員的技術技能和擬議專案的範圍的影響。值得研究專案的複雜性，以及這與成績和採用的開發框架之間的關係。我們發現，該框架同樣適用於不同型別的專案（參見 Avrahani 2002）。
透過採用能夠被認為可以生產出優質產品的同時又靈活和穩健的流程，可以減輕產品和流程之間的緊張關係。我們相信本文中開發的開發框架將為頂點課程提供基礎。
9 致謝 我們感謝多年來學生們提供的豐富資訊。以及本課程其他講師的工作。Patricia Haden、Phoebe Eden-Mann 和 Zuzette van Vuuren 在分析方面提供了幫助。本研究是在奧塔哥理工學院 B 類倫理審批下進行的。參考文獻
Barclay，K.，Mann，S.，Brook，P. 和 Doonan，A.（2001）自適應計算機鍵盤介面的開發和測試 在第 14 屆全國計算資格諮詢委員會年會的論文集 Napier，第 13-22 頁 Beasley，R. E.（2003）。“在計算領域成功進行高階頂點課程。”小型學院計算雜誌 19（1）：122-131。Bridgeman，N.（2003）。專案成功：定義、設計、構建和展示頂點專案。第 16 屆 NACCQ 年會，帕默斯頓諾斯，NACCQ.211-216 Clear，T.（2003）。“瀑布已死，長存瀑布！”SIGSCE 公告 35（4）：13-14。Clear，T.，F. H. Young，M. Goldweber，P. M. Leidig 和 K. Scott（2001）。“計算領域頂點課程講師的資源。”ACM SIGCSE 公告 33（4）：93-113。Chamillard，A. T. 和 K. A. Braun（2002）。軟體工程頂點：結構和權衡。第 33 屆計算機科學教育 SIGCSE 技術研討會論文集，辛辛那提，肯塔基州。227-231 Fincher，S.，M. Petre 和 M. Clark，編者（2001）。計算機科學專案工作：原則和實用性。倫敦，施普林格。Garrett，P.，D. Youngman，J. McCormack，C. Rosescu 和 S. Mann（2003）。成功的特點——虛擬存在。第 16 屆 NACCQ 年會論文集。269-272 Goold，A.（2003）。為頂點課程中的專案提供流程。第八屆計算機科學教育創新與技術年會論文集，塞薩洛尼基，希臘，SIGCSE ACM。26-29 Hakim，J. 和 T. Spitzer（2000）。有效地進行原型設計以實現可用性。ACM 通訊設計特別興趣小組，IEEE 專業通訊學會國際專業通訊會議論文集和第 18 屆 ACM 國際計算機文件大會論文集：技術與團隊合作。47-54 Hamilton，M.（2003）。Familtrack。第 16 屆 NACCQ 年會論文集，NACCQ.484 Hoffer，J. A.，J. F. George 和 J. S. Valacich（1998）。現代系統分析與設計。美國雷丁，本傑明·卡明斯。Lawton，B. 和 A. Meikle（2003）。替代 CAD 使用者介面。第 16 屆 NACCQ 年會論文集，NACCQ.487 Ponting，D.，L. Quarrie 和 G. Robertson（2003）。為酒店業提供正確的服務：酒店培訓 CD-ROM。第 16 屆 NACCQ 年會論文集。495 Rudd，J.，K. Stern 和 S. Isensee（1996）。“低保真度與高保真度之爭。”互動 3（1）：76-85。Singh-Cosgrave，B.，Sinclair-Fox，C.，McLellan，G.，Mann，S. 和 McGregor，G.（2001）用於教授基於開發的主題的互動式 CD 簡明論文，第 14 屆全國計算資格諮詢委員會年會論文集 Napier，第 460 頁 Stein，M. V.（2002）。“在頂點課程和軟體工程課程中使用大型和小型小組專案。”小型學院計算雜誌 17（4）：1-6。
4 結果
4.1 初始發現 值得調查專案的外部特徵，以表明成功專案的開發特徵。在 2001 年至 2003 年之間，完成了 65 個專案。35% 獲得 A，32% 獲得 B，16% 獲得 C，17% 失敗。這些專案可以分為八類，如表 1 所示，以及每類的分數分佈。除了一些小的例外（“總系統”全部成功，“硬體”的失敗率高於預期），專案型別與成績之間沒有強烈的關係。無論專案型別如何，都可以獲得好成績。
表 1：專案的分類和成績分佈。
總系統 3 硬體 15 應用軟體 7 資訊系統 13 多媒體 12 內容管理 6 網路 3 其他 6 總計 65
圖 1：小組規模對專案成績的影響。
小組規模存在影響，如圖 1 所示。雖然兩人或三人的小組表現出類似的模式，但單獨工作的學生失敗的可能性要高得多。我們認為這裡有兩個潛在因素：學生的質量（即為什麼他們單獨工作）以及他們錯過了在小組中工作的益處。
大多數學生遵循以文件為中心的開發方法。然而，學生們錯了，規模並不重要，關於按權重分配成績的謠言是不真實的。圖 1 表明最終成績與文件頁數之間的關係非常弱（n=49，圖書館中有完整的文件）。一旦超過大約 100 頁的最低閾值，任何成績都是可能的。在約 260 頁處有一組高分。文件最多的專案沒有獲得最高分，而且顯然，糟糕的專案無法透過大量文件來挽救。
圖 2：頁數和成績之間的弱關係（n=49）
無法透過專案型別或工作量來識別好的專案。因此，我們回到這個問題，優秀的團隊在做什麼？