開發技術

在系統開發中，需求定義階段所進行的工作是下列何者？

1. 決定程式內部的模組結構與處理程序
2. 修正正式上線後發生的故障，並改善功能
3. 調查使用者的業務，明確系統所需的功能與效能
4. 1支1支地確認撰寫完成的程式是否照設計書運作

外部設計（基本設計）所決定的內容，下列何者最適當？

1. 整合測試所使用測試資料的製作程序
2. 依照程式碼撰寫規範統一變數與函式的命名方式
3. 各模組內部的處理程序與演算法
4. 使用者操作的畫面與輸出報表的版面配置

說明外部設計與內部設計關係的敘述，下列何者適當？

1. 把外部設計所決定的使用者可見規格，在內部設計中落實為程式的結構
2. 先完成內部設計，再根據其結果進行外部設計
3. 外部設計與內部設計都是決定應與使用者取得共識的畫面、報表版面規格的階段
4. 外部設計以程式設計師為中心、內部設計以使用者為中心進行

實施系統開發各階段的順序，下列何者適當？

1. 需求定義 → 測試 → 系統設計 → 程式撰寫
2. 系統設計 → 需求定義 → 測試 → 程式撰寫
3. 需求定義 → 程式撰寫 → 系統設計 → 測試
4. 需求定義 → 系統設計 → 程式撰寫 → 測試

把程式分割成多個模組來設計，其主要目的為何？

1. 提高各元件的獨立性，使修改、測試與再利用更容易
2. 減少正式環境所用伺服器的臺數以降低費用
3. 減少使用者輸入的項目數，讓操作更簡單
4. 使程式整體的原始碼行數必定能減少

提高易用性（usability）的畫面設計例子，下列何者最適當？

1. 當場提示輸入錯誤，並具體顯示錯誤內容與修正方法
2. 大量使用專業術語，做成只有熟悉的使用者才會用的畫面
3. 操作方法不顯示在畫面上，只用另一本手冊說明
4. 把所有輸入欄位塞進1個畫面，完全不顯示標題與補充說明

關於軟體驗收的說明，下列何者適當？

1. 正式上線開始後，配合業務變化與使用者的要求改良軟體
2. 開發者把自己撰寫的程式，以模組或1支程式為單位分別進行測試
3. 訂購方以營運測試等方式確認交付的軟體，若滿足要求即予以接收
4. 開發者依照設計書，組建程式的內部結構與處理程序

關於單元測試的說明，下列何者適當？

1. 由使用者依實際業務程序使用，確認是否滿足要求
2. 以模組或1支程式為單位，確認內部處理是否正確運作
3. 在接近正式的環境中，含效能與負載承受度在內確認整個系統
4. 組合多個模組，確認彼此之間的資料交換是否正確

整合測試主要確認的內容是下列何者？

1. 組合後的模組之間，資料的交換與銜接是否正確
2. 使用者在實際業務流程中能否順利使用
3. 1個模組之中的指令與分支是否全部被執行
4. 開發費用是否控制在當初的預算內

系統測試（總合測試）所進行的內容，下列何者最適當？

1. 在接近正式的環境中以整個系統為對象，除功能外也確認效能與負載承受度
2. 用自動排版工具整理原始碼的縮排與格式的紊亂
3. 交付後把使用者提出的要求作為新功能陸續追加
4. 由負責人彼此把製作中的模組1支1支在桌面上對讀，確認敘述的錯誤

關於營運測試（驗收測試）的說明，下列何者適當？

1. 開發者在桌面上對讀程式，互相指出錯誤
2. 開發者著眼於程式的內部結構，涵蓋指令與分支進行確認
3. 開發者確認整合後模組之間的銜接
4. 使用者依照實際業務流程使用，確認是否滿足要求

在V字模型中，與外部設計（基本設計）相對應的測試階段是下列何者？

1. 單元測試
2. 整合測試
3. 系統測試
4. 營運測試

關於白箱測試的說明，下列何者適當？

1. 灌入與正式相同數量的資料，量測處理時間是否在基準之內
2. 不考慮程式的內部結構，只著眼於規格書所示輸入與輸出的關係進行測試
3. 著眼於程式的內部結構，涵蓋指令與分支被執行的路徑進行測試
4. 請使用者操作試作品，聽取要求並反映到需求中

黑箱測試中測試案例的設計方式，下列何者適當？

1. 機械式地按原始碼行數的比例分配並準備測試案例
2. 選擇路徑，使所有分支至少被執行1次
3. 逐行確認開發者所寫註解的敘述是否正確
4. 把規格書的輸入條件依意義的群組劃分，選取其代表值與交界的值

進行回歸測試（regression test）的目的是下列何者？

1. 確認因修改程式，修改前原本正常運作的地方是否產生了缺陷
2. 確認受過研習的使用者已正確學會變更後的新操作方式
3. 確認具有足以承受正式使用的處理效能
4. 只以新增功能是否照規格書運作為對象，僅就追加的部分進行確認

軟體的審查技法中，關於檢視（inspection）的說明，下列何者適當？

1. 由主持人（moderator）主辦，事先訂定參加者的角色與程序，正式地檢出成果物的缺陷
2. 實際執行程式，確認輸入所對應的輸出是否符合規格
3. 2人1組使用1台終端機，輪流交替撰寫程式
4. 以作成者為中心向相關人員依序說明成果物的內容，當場非正式地互相指出錯誤與疑點

瀑布模型的特徵，下列何者適當？

1. 製作試作品並取得使用者的評價，逐步確定需求
2. 依序推進各階段，原則上不返回前一階段地進行開發
3. 反覆進行短週期的迭代，每次迭代都提供可運作的軟體
4. 開發人員與營運人員一體協作，藉自動化頻繁地發布

採用雛型法（prototyping）模型的主要優點是下列何者？

1. 試作品可以代替設計書，因此完全不需要文件化的作業
2. 在早期階段就請使用者確認試作品，可減少因需求偏差或認知不一致造成的返工
3. 因為使用者已確認過試作品，可保證上線開始後不會發生規格變更
4. 藉由製作試作品，開發的總工時必定減少，費用變成一半

關於螺旋模型的說明，下列何者適當？

1. 以由上游到下游的1次流程完成全部功能，完全不返回前一階段、也不中途重新檢視
2. 省略需求定義階段，先做出可動的東西之後再把規格文件化
3. 把開發的全部階段委託給外部，進度只以每月的報告管理
4. 把系統分成數個部分，反覆進行設計、開發、評估這一連串作業，螺旋式地提高完成度

敏捷開發的思維，下列何者最適當？

1. 使用者只在需求定義與驗收時參與，開發期間不介入
2. 一開始就確定所有規格，之後的變更原則上不予承認
3. 以短的迭代做出可運作的軟體，一邊採納使用者的意見一邊因應變化
4. 把完美整備詳細的設計文件，看得比儘早展示可運作的軟體更優先

需求尚未確定、想一邊觀察使用者的反應一邊以短週期追加功能的系統，其開發方針以下列何者最適當？

1. 測試留到最後一次實施，在那之前不做動作確認
2. 需求定義書核可之前不著手開發，核可之後一概不接受變更
3. 每個短迭代發布可運作的功能，把使用者的評價反映到下一個迭代
4. 確定全部功能的規格後一次開發，完成時才第一次給使用者看

關於RAD（Rapid Application Development）的說明，下列何者適當？

1. 開發人員與營運人員密切合作，藉由自動化謀求持續改善的思維
2. 活用少人數的團隊與開發支援工具，在短期間內開發系統的手法
3. 組合多個公開的服務來做出新服務的手法
4. 解析既有的程式，導出其規格與設計資訊的手法

關於結對程式設計（pair programming）的說明，下列何者適當？

1. 2個團隊各自分別開發相同的功能，完成後採用做得較好的一方
2. 2人1組使用1台終端機，一人撰寫程式碼，另一人邊確認、建議邊開發
3. 請2位使用者操作相同的畫面，比較好用的程度
4. 同時實施2種測試以更早發現缺陷

測試驅動開發（TDD）的進行方式，下列何者適當？

1. 先撰寫測試碼，再實作程式使其能夠通過
2. 所有實作完成之後，才第一次擬定測試的計畫
3. 測試只交給外部的專門業者，開發者不進行測試
4. 正式上線之後接到使用者的故障報告，才第一次撰寫測試

關於重構（refactoring）的說明，下列何者適當？

1. 不改變由外部所見的動作，把程式的內部結構整理得更容易理解
2. 把營運中的系統遷移到別的資料中心
3. 因應使用者提出的要求，為既有的程式追加新功能
4. 為了提升處理速度而增加伺服器的臺數或記憶體

Scrum中產品負責人（Product Owner）的職責是下列何者？

1. 對產品待辦清單的內容與優先順序負責，使成果物的價值最大化
2. 對團隊成員進行人事考核，並逐一分派各人負責的作業
3. 記錄每日的進度，向經營層報告預算的超支
4. 支援Scrum的規則被正確遵守，排除妨礙開發的問題

Scrum中Scrum Master的職責，下列何者適當？

1. 支援Scrum被正確地實踐，排除妨礙團隊的問題
2. 與顧客進行價格交涉，決定合約條件
3. 對開發團隊的每一個人下達作業指示，斥責並管理進度落後的成員
4. 決定需求的優先順序，確定要發布的功能

Scrum中關於每日站會（Daily Scrum）的說明，下列何者適當？

1. 開發團隊每天短時間集合，共享進度與問題點，確認當天的作業
2. 在衝刺（Sprint）結束時，把該次完成的成果展示給相關人員，取得評價與意見
3. 把想實現的需求排出優先順序，整理成一覽清單
4. 回顧團隊的工作方式，決定接下來的改善方案

關於CI/CD（持續整合／持續交付）的說明，下列何者適當？

1. 營運人員以手工把檔案複製到正式環境，逐一反映變更
2. 在發布前夕把所有變更一次整批整合，到那時才第一次整批只實施1次測試
3. 中斷新的開發，只推進既有系統規格書的整備
4. 頻繁整合變更後的原始碼並自動執行建置與測試，到發布為止的流程也自動化

屬於逆向工程（reverse engineering）的是下列何者？

1. 利用只需在畫面上配置元件即可做出應用程式的開發環境
2. 根據設計書撰寫程式
3. 組合多個公開的服務來做出新的服務
4. 解析既有的程式，導出其規格與設計資訊