2019/01/28
2020/06/10 (增加連結)
2024/02/14 (改寫)
本課程採用兩個目前最常用的方法論，第一個方法論就是在創意與設計思考中採用的設計思考。簡單的說，設計思考是將科學方法應用在設計，也就是加入科學的方式去理解並驗證使用者的需求。在業界常提到的使用者經驗(User Experience, UX)經常採用設計思考，從使用者的角度設計產品或服務。從資訊系統的開發來說，就是以使用者的觀點 (而非開發者的觀點)來開發系統，因為開發者往往不理解使用者的使用情境，開發出使用者覺得很難用的系統。這時候，透過設計思考的科學方法可以協助開發者去理解使用者的使用情境，並進行驗證。第二個方法論是敏捷開發，為了因應環境變化迅速、需求不確定，開發者改變過去一定要完整確認需求之後才開始進開發的模式，而改採透過部分功能的開發去探索、驗證使用者的需求，再基於驗證結果去開發後續的功能。這樣的思維跟階段式開發不一樣的是: 階段式開發還是會完整確認需求之後才開始進開發，只是分階段完成。
這兩個方法論常常被視為是互斥的方法論，認為設計思考、使用者經驗就是完整的了解使用者的需求，所以，不適用於敏捷開發。其實，敏捷開發的根源是產品開發，當時發現很多的企業改用這種新的產品開發模式，而由於資訊系統的開發越來越成熟，所以，在資訊系統開發上開始廣泛運用敏捷的開發方式。最近幾年，產品開發的技術也開始改變，所以，也開始將敏捷開發與設計思考、使用者經驗結合。
資訊系統的開發有一些不同的方法論，所謂的方法論就是一些常用的活動(或程序)、或文件的組合。一般來說，不管是哪一種方法論都會有以下的幾個基本活動:系統評估、系統分析、邏輯系統設計、實體系統設計、開發 (Marakas, 2001) 。
系統評估通常會進行問題的定義、系統規模的估計、系統可行性分析、系統資源需求評估。通常在系統評估之後，才會決定是否開發系統，也會決定系統開發的範圍，因為有時候會因為資源有限，決定先解決部份的問題。也會有一些產出: 整體的問題定義、系統範圍、可行性分析報告、資源需求報告。傳統的作法會花長多的人力物力進行系統評估，然而，以敏捷開發的精神，只會進行基本的評估。就專題文件上要求的發展背景與動機 (使用者情境描述及競品分析概述、目前面臨的問題概述)、系統發展目的(問題描述以及解決方案概述)、系統範圍(解決方案描述)、背景知識(競品分析)、系統限制(初步的可行性分析報告)。
以傳統的瀑布式開發模式而言，會在評估階段投入大量的人力、物力進行可行性評估，可行性分析就是要了解整個專案是否可行，通常會了解組織有多少資源，根據資源到底是否能完成組織所期望的功能，接下來會討論是否有法律上的限制及時程上的限制，Marakas(2001)列舉了五種可行性分析: 技術面(硬體、軟體、作業環境)、作業面(時程、公司文化、現有流程)、人為面(公司現有利害關係人)、法律政治面、經濟面(成本及效益分析)，Satzinger, et al( 2012)則列出組織面(組織文化及利害關係人)、技術面、資源面、時程面等方面進行分析，至少都要去進行軟硬體的需求分析、人力的需求分析，在利用軟硬體及人力需求估算出財務需求，了解以專案是否可行。
有時候會發現部份需求不可行，就將那些需求列為系統限制，也會對於需求排優先順序，根據資源的多寡，決定先開發哪些需求。將其他需求列為系統限制。
在實務上，可行性分析是個很困難的工作，在系統需求都還沒有確定的時候，要去想像系統的所有功能，並去分析各方面的可行性，尤其是成本的分析，是很不容易的工作。
在可行性分析中，通常必須對開發時程及成本進行評估，在業界，有些公司是利用經驗法則，來判斷每個功能的人力需求，也就是說利用類似專案的經驗數字來推估專案人力需求，另外，還可以利用使用個案點(Use Case Point, UCP)來進行估算。使用個案點是利用使用個案的複雜度算出未調整之使用個案點，再利用未調整之使用個案點進行一些整體調整(如：是否開發過類似的系統)，來算出調整後使用個案點，最後，利用公司過去的內部歷史資料(如：每位參加專案員工的個別開發能力)來計算開發人時，並根據每位參加專案員工的個別薪資計算出粗略的開發成本。做完這樣的分析後，便可以進行財務上的可行性分析。以學生專題而言，可以用UCP估計出來的人時乘上時薪，若不清楚自己的時薪標準，可以用政府規定的最低時薪來估算。在實務上，開發成本會利用「資訊委外服務人員計價參考要點」來做為估算的基準。
在初步的評估之後，我們會將需求以文件的方式記錄下來，以專題文件的格式為例，我們會先整理出發展背景與動機、系統發展目的、系統範圍、背景知識、系統限制、資源需求。
發展背景一般是描述系統的使用者(合作對象)或者目前存在的相關系統，而發展動機一般是描述目前使用者所面臨的問題或現有系統的缺點。
系統發展目的則是根據上述的發展動機，簡單描述的需求也就是可以及解決哪些問題，並且會簡單的描述功能性及非功能性需求。
系統範圍則是更詳細的描述為滿足發展目的所要發展的各項主要具體功能性需求。
背景知識是整理一些讀者(未來的系統開發、維護者)所需要的背景知識，一般而言，讀者缺乏組織的領域知識，對於一些組織內常用的名詞及概念很不熟悉，需要一些概略性的介紹，另外，也可能會用到一些讀者所不熟悉的技術，也需要一些概略性的介紹。
系統限制的部份，則是陳述可行性分析的結果，簡單描述未包含在系統範圍之使用者的需求，以及未能開發之原因。
資源需求的部份通常則是列出開發系統所需資源(不包含後續營運所需要的資源)，如:人力需求、技術需求 (包含軟體及硬體設備需求)、財務需求。
系統分析通常包括需求分析、並完成初步的行為模型及動態模型，需求分析會用一些方法，如:訪談，決定新系統的範圍，以敏捷開發而言，最後的產出就是專題文件上要求的使用者故事一覽表及使用者故事 (User Story) 。以傳統的瀑布式開發模式而言，產出使用個案圖 (Use Case Diagram)、使用個案說明 (Use case Description)、活動圖。
以以敏捷開發而言，系統設計通常就是資料庫設計、介面設計。資料庫設計又因為採用的資料庫形式，如果是關聯式資料庫，就會完成關連結構、關聯一覽表，如果是非關聯式資料庫，說明的方式因為採用的資料庫而有所不同。介面設計則是完成介面藍圖一覽表、介面藍圖，利用介面藍圖一覽表說明介面與使用者故事之間的關係，利用介面藍圖說明介面以及與其他介面的關係。另外，也會進行資源需求(軟體、硬體、人力等)估算。
以傳統的瀑布式開發模式而言，通常又將系統設計分為邏輯設計及實體設計等兩個階段，在邏輯設計階段，通常開發的工具以及開發的方式尚未確定，先以分析的結果進行初步的設計。以最後的產出大致上就是實體關聯圖(Entity Relationship Diagram, ERD)、介面藍圖一覽表及介面流程圖。
在決定開發的工具以及開發的方式後，再根據開發的工具以及開發的方式來進行系統實體設計，最後的產出大致上就是專題文件上要求的的資料庫設計、介面設計、程式設計 。也就是關連結構、關聯一覽表、介面流程、介面藍圖一覽表、介面藍圖、類別圖、類別字典、循序圖、部屬圖。另外，也會進行資源需求(軟體、硬體、人力等)估算。
但是，越來越多人認為系統設計中很多文件是多餘的，因為當系統單純時，這些圖就沒有必要，當系統複雜時，畫這些圖又會花太多時間，也很難看得懂，就敏捷開發而言，通常採用Document in Code的觀念來取代。
開發的部份就是依照系統設計的結果進行開發。通常包括寫程式、測試、系統安裝與上線，最後的產出通常包括測試報告、及使用手冊。很多人建議文件應該跟著程式 ，例如在專案裡有README (詳參: A beginner’s guide to writing documentation)。如果以Java開發，可以參考: How to Write Doc Comments for the Javadoc Tool。
The beginner’s advanced guide to building an app
User Flows
User Stories
Writing User Stories
Categorizing User Stories
Tracking User Stories
Document in Code，就是讓程式碼容易閱讀，在開發階段，在程式碼中加上適當的命名與說明來取代開發說明文件:
利用類別(或檔案)的名稱說明類別(或檔案)的角色(如:Controller、Persistence)，所以，可以不用類別圖、循序圖就可以了解這些類別的角色與類別之間的關係
變數、方法的命名應該有意義，讓別人一眼就可以了解變數、方法的用途。有必要的話，用中文註解解釋變數、方法的用途。
方法的參數命名應該有意義，讓別人一眼就可以了解參數的意義，如果是比較複雜的計算，請利用註解解釋方法的計算規則。不少人認為註解是不得已的解決方案，一方面是因為很多人可能會改了程式但忘了改註解，這反而會讓看的人更困擾，所以，一般而言，最好的方法就是寫讓人容易看得懂得程式。