A-level 計算機科學/WJEC（Eduqas）/元件 1/系統分析
瀑布模型採用線性方式進行軟體開發，並在每個階段結束時產生“可交付成果”。該方法之所以得名，是因為開發的本質就像天然瀑布一樣，一個階段必須完成才能進入下一個階段——而且您也不能向上移動一個階段，必須從頭開始。在這個過程中，對文件的明確重視是顯而易見的，因為在每個階段，您都必須生成這些“可交付成果”。
優點
- 可交付成果可以向客戶展示，以便告知他們專案進度。
- 由於每個階段都有截止日期，因此整個過程都保持著紀律感。
- 必須在開始工作之前考慮需求。
缺點
- 使用這種方法交付專案需要很長時間。
- 缺乏靈活性——您不能隨意遍歷各個階段，必須按照嚴格的順序進行。
- 即使市場上出現了新的創新，您也不能在後期更改專案。
- 任何錯誤/遺漏的問題都意味著您需要完全重新開始專案。
- 在開始開發之前，幾乎不可能掌握需求。
敏捷方法將更多控制權交給了開發人員，而不是專注於客戶。開發人員被信任找到問題的解決方案並編寫程式碼，在獲得執行此操作的資源後，例如通常安裝有 Visual Studio 的功能強大的 PC。開發人員通常被分組為團隊，並被賦予實施解決方案的一部分，這些團隊會與客戶會面並詳細討論他們的需求。
優點
- 敏捷方法認為，您無法在專案開始時就瞭解所有需求。
- 該專案非常靈活，因為計劃可以更改。
缺點
- 許多人不喜歡結對程式設計。
- 不瞭解這種方法的客戶會不喜歡缺乏文件。
- 人們以衝刺的方式工作，這意味著程式碼通常是義大利麵條程式碼。
在敏捷宣言中，我們重視“個人和互動高於流程和工具，可工作的軟體高於詳盡的文件，客戶合作高於合同談判，對變化的響應高於遵循計劃”。
極限程式設計：在這種情況下，開發人員必須與彼此和其他團隊以及客戶進行溝通。應採用最簡單的解決方案，並由他人提供反饋，例如在結對程式設計中。
Scrum：以儘可能快的方式建立定期原型。這些原型在稱為“衝刺”的特定時間段內生成。由於人們在多個領域以團隊形式工作，因此會舉行稱為“每日站立會議”的會議，以討論進度併為他人提供建議。
利益相關者：對新系統感興趣的人。他們要麼是構建該系統並獲得報酬的人，要麼是為該系統付費的客戶。
使用者：使用新系統的人，例如使用購物網站的人。
程式設計師/開發人員：構建系統的人。
專案經理：透過將開發人員分配到專案的不同部分並監控他們的進度來協調專案的完成。他們可以根據自己的技能進行調動，而擁有更高技能的人可以從事原來的工作領域。
系統分析師：找出客戶在新系統中想要什麼。這是透過各種事實調查方法完成的，因為大多數客戶並不知道他們到底想要什麼，或者沒有提供關於系統已包含哪些資料的足夠資訊。
客戶和開發團隊將舉行會議並討論專案的範圍——需要做什麼以及當前系統的限制是什麼。客戶可能對可以完成的事情以及新系統必須包含哪些資料過於樂觀，這就是我們舉行會議並決定問題範圍的原因。問題定義可能是設計一個新的系統，因為他們的舊系統不符合他們當前的業務目標，或者使用新的網站或移動應用程式擴充套件系統。
可行性研究旨在評估在開發公司有限資源（資金、時間、技術能力和聲譽）的情況下，解決方案是否可行。
經濟方面
[edit | edit source]承接專案的公司資金有限，因為他們需要僱用開發人員以及辦公場所，而辦公場所也存在支出：Visual Studio 許可證、計算機、開發人員薪資、辦公場所費用（電費、燃氣費、租金等）。公司還希望獲得一些利潤，這些利潤可能與開發人員分成，也可能不分成。
時間限制
[edit | edit source]每天只有這麼多小時，開發人員從早上 9 點到下午 5 點工作，這意味著只有這些時間可用於專案。專案經理必須計算完成專案的所需時間，然後決定是否繼續進行 - 延期專案會面臨處罰，甚至可能面臨法律訴訟。客戶希望在截止日期前完成專案，這需要與完成專案所需的時間進行核對，以計算時間可行性。
技術方面
[edit | edit source]開發人員不是神，他們只能掌握有限的程式語言，只閱讀過一些文件，並不熟悉每一個系統實現。透過技能評估，公司可以瞭解開發人員的技能水平。另一個問題是，客戶可能要求一些目前技術上不可行的東西，例如薄型 VR（虛擬現實）眼鏡。
政治方面
[edit | edit source]一些系統由於政治環境惡劣而無法實施，例如道德選擇系統、醫療保健系統、產品測試系統。如果系統在政治上不正確，將影響公司的聲譽。
法律方面
[edit | edit source]提議的系統可能違反其原產國的一些法律。因此，該系統不能被認為是法律上可行的。這很難做到，例如公平使用法和分享檔案/製作評論影片，這些影片可能會被自動系統錯誤地標記。據報道，YouTube 因其內容識別系統錯誤標記影片而面臨強烈反對。
分析
[edit | edit source]分析是透過各種事實調查方法，如訪談、問卷調查、檔案收集和觀察，收集有關新系統需要具備的功能的詳細資訊的過程。
問卷調查
[edit | edit source]問卷調查也稱為調查，包含與系統相關的問卷。如果員工分佈在廣泛的地理區域或人數眾多，這種方法很有用。
優點
- 對於大量人群來說，製作成本相對較低。
- 可以收集廣泛的觀點。
- 大量的（可能非常豐富的）細節。
- 可以分佈在全球許多公司地點。
- 可以線上完成，因此結果可以很快獲得。
缺點
- 問卷必須由專家設計，否則資訊可能無法使用。
- 人們可能“太忙了”，可能不會完成問卷。
- 人們可能不會給出正確答案。
訪談
[edit | edit source]訪談是指利益相關者與系統分析師之間的一對一討論。當分析師需要從少量人那裡獲取大量資訊時，這種方法很適合。
優點
- 可以收集大量詳細的資訊。
- 可以透過個人接觸或肢體語言判斷資訊的有效性。
- 訪談物件將是利益相關者，因此會積極配合回答問題。
- 可以進行後續問題，這與其他分析方法不同。
缺點
- 耗時且成本高。
- 必須由經過培訓的訪談員或專家撰寫的封閉式問題進行。
- 難以分析大量資訊。
- 難以分析各種資訊。
檔案收集
[edit | edit source]檔案收集涉及收集各種公司檔案，例如發票、稅收收據、員工記錄、公司電子表格等。這種方法適合調查當前的資料儲存需求和資料流。
優點
- 團隊可以瞭解系統當前的執行方式。
- 一種廉價且快速收集大量資訊的方法。
- 可以確定系統的儲存需求。
缺點
- 員工可能沒有按照文件中列出的程式進行操作，而是以自己的方式使用系統。
- 資訊可能高度機密，系統分析師可能無法獲得。
- 文件可能已過時，沒有更新以反映對系統的更改。
觀察
[edit | edit source]觀察是指觀察某人進行日常工作，通常稱為“跟班學習”。這種方法適合直接收集資訊。
優點
- 瞭解問題定義中遺漏的細節。
- 驗證其他找到的資訊。
- 可以實際瞭解正在發生的事情，不依賴於其他人告訴您他們認為正在發生的事情。
缺點
- 非常耗時且成本高。
- 員工可能會因為被觀察而感到受到威脅，因此行為可能與他們的日常行為不同。
- 派遣分析師到全國各地會產生費用。
需求
[edit | edit source]需求是系統為了交付給客戶而必須滿足的具體目標。這在法律意義上很重要，這樣公司可以證明它提供了客戶要求的內容，但在另一個意義上，它可以將專案保持在範圍內。需求包括三個方面，所有這些方面都必須是可衡量的，以滿足法律/範圍要求：介面、功能和效能。
介面
[edit | edit source]介面需求是系統如何與使用者互動的可衡量標準。以影片流網站 Twitch 為例。使用者互動將透過使用者點選滑鼠按鈕來觸發流載入。在規範中，我們感興趣的是可衡量的標準，這將被稱為“網站必須可供所有型別的計算機使用者使用滑鼠訪問，以及可供使用觸屏的移動使用者訪問”。我們不關心他們在遊戲滑鼠上有多少個按鈕，而是左鍵單擊可以用來與網站互動，這意味著介面需求將得到滿足。
功能需求詳細說明系統應該具備的功能。繼續以Twitch為例，一些功能需求可能是“訂閱系統，使用者每月支付費用並獲得獎勵”，或者簡單地“影片必須在互動時載入相應的流”。這兩種方法都可以用多種方式實現，但僅僅擁有功能就足以滿足需求。
效能需求只涵蓋系統在使用時的速度。Twitch在良好的寬頻連線下相當流暢，也許它的效能需求是“在5秒內載入影片流”。這絕對是可衡量的，如果流確實在那麼快的時間內載入，那麼這個效能需求就達到了。
需求規格說明書，通常稱為“規格說明”，概述了新系統的生產及其內容。其內容因公司而異，但它們都嚴格遵循自己的規格說明模板。這可能包括：目的、範圍、功能/介面/效能需求、產品功能、約束和問題。可以在伊利諾伊大學檢視一個示例模板。
設計決定了系統的外觀以及資料如何在系統中輸入和處理。只有在需求規格說明書完成後才能建立最終設計。設計應考慮可用的硬體/軟體，例如網站或遊戲、資料結構設計、輸入（即資料如何進入系統）和輸出（即資料在讀取出系統時如何呈現）。
資料結構設計以圖表形式展示資料如何在系統中表示。分析階段收集的所有資料將被組織成欄位並放置在資料字典中。
| 名稱 | 型別 | 大小 | 描述 | 示例 |
|---|---|---|---|---|
| 姓 | 文字 | 64 個字元 | 學生的姓。 | Bob |
| 名 | 文字 | 64 個字元 | 學生的姓。 | Ross |
| 年齡 | 數字 | 3 個字元 | 學生的年齡。 | 13 |
| 年級 | 文字 | 2 個字元 | 學生獲得的年級。 | A* |
在構建資料字典後，選擇儲存方法，最常見的是某種形式的資料庫。
我們可以使用多種技術來解決問題，但你需要了解其中的兩種技術：抽象和分解。
抽象是指為一個過程命名。也許你可以在程式設計的意義上理解它 - 在你的程式碼中解決問題的許多方法，一旦你解決了它，你可能會將解決方案放在一個函式中，這樣你就可以在需要的時候呼叫它。這就是對問題進行抽象。
如果你仍然不理解，請檢視這個詳細的StackOverflow 答案。
分解是指將一個問題分解成更小、更可實現的部分。分解的一個很好的例子是在面向物件程式設計中，其中每段資料都被分解成各種不同的物件。
為了理解系統中的資料流，通常最好構建系統的圖表表示以供參考。你需要了解三種圖表：實體關係圖、流程圖和資料流圖。
實體關係圖 (ERM) 用於表示資料庫，顯示哪些表相互關聯以及以何種方式關聯。有三種類型的關係：一對一、一對多和多對多。每個連結表示兩個條目（資料庫表）之間的關係。
資料流圖 (DFD) 顯示資訊如何在系統中處理。將有一系列流程，系統將根據“外部實體”對系統的互動來執行這些流程（外部實體是任何與系統互動的人）。當執行一個程序（在系統中執行一個操作）時，將需要資料，這些資料可以從“資料儲存”中獲取。資料儲存是任何儲存資料的實體，通常是資料庫。例如，以電影院為例，員工將作為外部實體與系統互動，流程將預訂門票，而資料儲存將儲存誰購買了哪張門票、他們的支付資訊以及他們觀看電影的螢幕。
本節內容將很快補充完善。
在將專案交付給客戶之前，測試始終至關重要。它確保系統按預期工作，並且系統中沒有錯誤或嚴重錯誤，這在即時業務環境中可能至關重要。開發人員需要其他人測試專案，因為每臺計算機都不同，因此係統可能無法在其他計算機上正常工作。
白盒測試由原始開發人員以及內部的其他開發人員進行。程式碼對任何測試人員都是完全可見的，因此名稱中的“白色”來自程式碼清晰可見。在白盒測試中，執行每個可能遇到的路徑。一個簡單的 IF this THEN do that ELSE do this，有兩條路徑 - 一條是條件滿足，另一條是條件不滿足。
黑盒測試外包給其他專門測試程式的公司，或者由其他對程式碼一無所知的人進行。“黑色”來自程式碼對測試人員隱藏的事實。測試系統的每個元素以檢視每個路徑在正確或不正確的情況下是否產生正確的輸出。
Alpha 測試是在系統開發過程中進行的，此時系統尚未完工，缺乏很多功能或無法正常工作。這些版本**絕不會**提供給客戶，因為他們會認為這就是最終交付的產品。這種型別的測試由公司內部員工進行，以測試系統的功能。
Beta 測試是在系統接近完成時進行的，此時系統已經具備了所有功能，並且是在 Alpha 測試之後進行的。這項測試透過將系統釋出給公司外部的有限使用者群體來進行，並記錄他們的反饋意見。Beta 版本中通常會有一些小問題。
單元測試是完全自動化的測試，它以定期的時間間隔執行，將一些測試條件輸入系統，以檢視是否產生了相關的輸出。由於程式碼是單獨開發然後插入到主系統中的，因此新插入的程式碼很可能破壞舊程式碼，這就是進行單元測試的原因。單元測試的原始開發人員建立了需要透過的測試，才能將程式碼更改接受到主系統中。
終端使用者測試由最初請求系統的客戶進行。他們使用真實資料測試系統，並檢查需求規格說明，確保雙方都滿意地履行了自己的承諾。客戶將擁有完整的系統，而開發公司將獲得報酬。
驗收測試由客戶或終端使用者進行，以證明系統正常工作。
直接切換，也稱為“大爆炸”切換，是指突然用新系統替換舊系統。當系統故障不會對企業造成災難性後果時，可以使用這種方法，但當系統故障會導致人員傷亡或鉅額損失時，則不能使用這種方法。這種方法實施成本低廉，因為沒有額外的員工成本，但如果系統故障，企業將沒有系統可用，這可能會很危險或造成損失。
分階段切換是指逐步引入新系統，每次引入一部分新的功能。這種方法適用於企業中有多個部門的情況。如果新系統出現故障，員工可以恢復使用舊系統。由於會有更多的專家在手，因此問題可以很快得到解決。一個區域的問題也可以在下一個區域中得到修復，以免在實施系統的下一個部分時造成問題。但這種切換方法可能會在切換期間造成問題，因為員工需要使用兩個不同的系統並相互溝通。
試點切換是指在企業的某個部分實施系統，因此適用於多個分支機構/辦事處，可以在單個分支機構/辦事處推廣。如果新系統在該辦事處出現故障，其他辦事處將繼續正常運作，因此故障不會造成災難性後果。在一個區域發現的問題可以在下一個區域中得到修復，以免在所有分支機構/辦事處推廣時造成任何問題。但這種方法可能會造成問題，因為員工需要使用兩個不同的系統並相互溝通。例如，這種方法可以用於單個超市分店。
並行切換是指兩個系統同時執行一段時間。這是四種切換方法中最安全的一種，因為如果系統出現故障，企業仍然可以使用舊系統正常運作。這種方法可能很昂貴，因為可能需要額外的員工在兩個系統上輸入資料，或者現有的員工加班才能同時操作兩個系統。這可能會給客戶和企業的員工帶來混亂。這種方法適用於關鍵系統，例如銀行機構使用的系統。
系統文件是為系統開發內部使用以及系統使用者編寫的，以便他們瞭解系統的運作原理以及如何使用系統。
使用者文件幫助使用者瞭解系統的使用者介面 (UI)，並展示如何使用系統完成許多常見的任務，以及每個按鈕的功能，並解釋系統中每個元素的含義。文件必須使用通俗易懂的語言，以便普通使用者能夠理解，並且能夠完成系統可以執行的任何任務。
必須編寫維護文件，因為系統不可避免地需要進行一些更改，因為企業會發生變化，社會也會採用新的設計語言。系統維護人員需要能夠理解系統，他們將是技術嫻熟的，而這些文件將對他們具有相關性。系統可能需要完全遷移到另一個數據中心，而維護文件中的安裝部分將在這種情況下具有相關性，記錄如何設定資料庫，安裝 nginx/apache 等 Web 伺服器，等等。其他部分可以包括：資料結構，演算法流程圖，資料字典，內部文件（如設計文件）以及最低系統要求，例如 RAM、CPU 能力、所需驅動器空間。
在系統的生命週期中，將需要進行各種型別的維護。
這是在使用系統時發現錯誤時所需的維護。糾正性維護的一個例子是，當發現錯誤（例如錯誤的計算）時，需要修改計算以生成正確的結果。
當系統必須進行調整以適應新的法律或環境時，需要進行適應性維護。適應性維護的一個例子是，當程式必須進行修改以在新作業系統上執行時，例如，在 Windows 上執行的桌面應用程式必須進行修改以在行動電話上執行。或者法律的變化，例如，增值稅稅率從 20% 上調到 25%。
當系統的效能必須得到提升時，需要進行完善性維護。完善性維護的一個例子是，當程式的效能得到改進時，例如，修改搜尋演算法以更快地生成結果。
• 需求：評估原始需求是否應該得到滿足，以使解決方案取得成功。
• 成本 – 包括財務成本、人力成本和資源成本。解決方案必須不超過任何預算成本。
• 魯棒性 – 根據測試結果進行評估。應使用錯誤捕獲和驗證方法來提高魯棒性，並減少系統錯誤和故障的可能性。
• 可用性 – 根據終端使用者使用解決方案的難易程度進行評估。解決方案應使用直觀的使用者介面，適合終端使用者使用以取得成功。
• 效能 – 針對記憶體使用和處理速度進行評估
備份是指將一個儲存區域中的檔案複製到另一個獨立的儲存區域的過程。資料備份和恢復主要有兩種策略，第一種是
- 將資料複製到行動式介質上，例如 USB 快閃記憶體驅動器或外部硬碟驅動器。
- 這應該定期進行，例如每週或每月一次。
- 介質應存放在另一個位置，在防火/防水保險箱中。
- 如果發生災難，資料可以複製回新的硬碟驅動器/SSD。
第二種方法是使用“雲端儲存”
- 資料應上傳到第三方。
- 這應該定期進行，例如每週或每月一次。
- 資料物理儲存在第三方站點（其資料中心）。
- 如果發生災難，資料可以複製回新的硬碟驅動器/SSD。