A-level 計算機/AQA/試卷 1/系統解決問題的步驟
| 規範要點 | 內容 | 附加資訊 |
|---|---|---|
| 4.13.1.1 分析 | 意識到在解決問題之前，必須定義問題，確定解決問題的系統需求並建立資料模型。系統需求必須透過與系統的預期使用者互動來確定。明確需求的過程可能涉及原型/敏捷方法。 | 學生應該有使用抽象來模擬程式中外部世界方面的經驗。 |
| 4.13.1.2 設計 |
|
學生應該有足夠的經驗成功地將程式結構化為具有清晰記錄的介面的模組化部分，使他們能夠為解決方案設計適當的模組化結構。 |
| 4.13.1.3 實施 |
|
學生應該有足夠的編寫、除錯和測試程式的實踐經驗，使他們能夠發展技能，闡明程式的工作原理，使用邏輯推理、測試資料和使用者反饋來論證程式的正確性和效率。 |
| 4.13.1.4 測試 |
|
|
| 4.13.1.5 評估 | 瞭解評估計算機系統的標準。 |
分析系統以識別需求並定義正在解決的問題。
例如，網站的構建可以涵蓋
- 資料 - 它的來源、用途、數量和特徵
- 程式 - 做了什麼，在哪裡，何時以及如何，以及如何處理錯誤和異常
- 未來 - 發展計劃和預期增長率
- 任何現有系統的問題
對於其他型別的問題，例如模擬或遊戲，需求仍然需要涵蓋類似的一組考慮因素。
在設計系統時，應考慮以下部分或全部內容
- 處理：記錄和建立演算法以及解決方案的適當模組化結構。
- 資料結構：資料如何儲存以及如何訪問 - 例如在動態結構（如佇列或樹）中，或在檔案或資料庫中
- 輸出：內容、格式、順序、頻率、媒介等。
- 輸入：數量、頻率、使用文件、輸入方法；
- 使用者介面：螢幕和對話方塊、選單、特殊用途需求
- 安全性：如何保護資料免受意外損壞或故意篡改或駭客攻擊
- 硬體：選擇合適的配置
設計達成一致後，就可以對程式進行編碼。需要保持對專案最終目標的清晰關注，避免使用者或程式設計師被偏離到建立可能有用或未來可能需要的額外功能上。程式設計師需要靈活地接受使用者反饋並在發現問題或設計缺陷時對程式進行更改。即使在中等複雜的系統中，也很難預測所有東西將如何協同工作，因此在每個階段進行迭代更改是原型/敏捷方法的正常部分。
在開發過程的每個階段都進行測試。一旦所有程式都使用正常、邊界和錯誤資料進行測試，還將進行單元測試、模組測試和系統測試。然後，系統需要由使用者測試，以確保它符合規範。這被稱為驗收測試。它涉及使用終端使用者提供的資料進行測試，而不是專門為測試目的設計的資料。它具有以下目標
- 確認交付的系統符合最初的客戶規範
- 找出是否需要對操作程式進行任何重大更改
- 在系統將要執行的環境中測試系統，使用現實的資料量
測試是一個迭代過程，測試過程中的每個階段都會重複，由於在後續階段出現錯誤，必須進行修改。
評估可能包括實施後審查，這是對系統投入執行後三到六個月進行的批判性審查。這個等待時間讓使用者和技術人員可以學習如何使用系統，習慣新的工作方式並瞭解所需的新程式。它讓管理層有機會評估他們可以進行的報告和線上查詢的有效性，並經歷幾個“月末”週期，在此期間將生成各種例行報告。系統的缺點（如果有的話）將在組織的各個層面上變得越來越明顯，使用者將希望有機會表達他們的觀點並討論改進。應該根據有效性、可用性和可維護性評估解決方案。實施後審查將重點關注以下內容
- 比較系統的實際效能與預期效能目標
- 根據預設標準評估系統的各個方面
- 系統開發過程中的錯誤
- 意外的益處和問題