系統開發與新技術

瀑布模型是讓工序像瀑布一樣從上游到下游依次推進、確定各工序的成果物後再進入下一步的開發模型。以短迭代開發的是敏捷開發，用原型確定需求的是原型化模型，組合既有服務是mashup的說明。

原型化模型的目的是儘早製作試作品（原型）讓使用者實際接觸，在早期消除需求的模糊之處以及發包方與開發方的認識偏差。它不以減少行數為目的，也不能實現省略測試或免除維護。

敏捷開發是每個短迭代都累積可執行的軟體、以規格變更為前提靈活應對的開發理念，Scrum和XP是代表性方法。確定全部需求後一次性開發、完成文件後才動手、使用者只在最後參與，都接近瀑布式的做法，不是敏捷的特徵。

衝刺是Scrum中作為開發單位的固定短週期，每個週期制定計劃、進行開發、做出可執行的軟體並回顧，如此迴圈往復。它不是指需求定義工序或驗收測試期間，也不是隻做錯誤修正的期間。

瀑布模型以不回頭為前提推進，因此在下游的測試階段發現需求或設計錯誤時，返回上游重做的返工成本非常大。它在每個工序都確定規格書、設計書等成果物，掌握進度反而是其所長，並且是適合大規模開發的模型。它也並非無法將需求文件化。

增量模型是把系統按功能單位分割、逐步疊加開發和釋出的模型，與迭代型開發模型一樣，優點是早期就能使用部分功能。瀑布模型是整體一次性按順序開發的模型，結構化分析方法是使用DFD等的分析方法，mashup是既有服務的組合，都不符合。

開發從整理使用者需求的需求分析開始，接著是設計使用者可見部分的外部設計、內部實現方式的內部設計、程式設計，再到測試，這是基本順序。設計先於需求分析的順序，或測試先於程式設計的順序，從成果物的依賴關係看都不能成立。

外部設計設計畫面規格、報表規格、與其他系統的介面等使用者和外部可見的部分。內部演算法和物理儲存方式的決定是內部設計、程式設計的作業，單個模組的執行確認是單元測試的作業。

單元測試是以模組為單位確認是否按詳細設計執行的測試，是測試工序的最初階段。組合模組確認介面的是整合測試（聯調測試），發包方的驗收是驗收測試，高負荷下的效能確認是負載測試、效能測試的說明。

測試從小單位開始逐層累積：先做各模組的單元測試，再做組合模組的整合測試，然後是確認系統整體的系統測試，最後是發包方和使用者進行的驗收測試。先做整體確認或驗收的順序，會在部件缺陷混雜的狀態下做上層測試，不合理。

驗收測試是發包方和使用者一方從業務角度確認交付的系統、判斷能否驗收的最終階段測試。內部邏輯的確認是開發者進行的單元測試（白盒測試），不執行而確認的是靜態測試，模組間連線確認是整合測試，都不是驗收測試的說明。

黑盒測試把程式內部當作“黑箱”，只憑輸入與輸出的關係是否符合規格來確認。白盒測試是著眼於覆蓋內部分支和路徑的技法，靜態測試是不執行程式、透過評審等確認的方法，迴歸測試是確認修改的影響沒有破壞其他部分的測試。

施加大量併發訪問和海量資料等高負荷、確認系統能否承受和效能是否保持的是負載測試，它與確認響應時間等的效能測試一起在系統測試階段進行。單元測試是模組級的確認，靜態測試是不執行的確認，白盒測試是著眼於內部結構的技法。

需求定義書是把需求分析的成果——系統應實現的功能、效能和約束——整理成文、由發包方與開發方達成一致的文件，是此後設計、測試和驗收的基準。操作手冊是面向使用者的使用說明，單元測試成績書是測試結果的記錄，網路拓撲圖是表示構成的設計類圖紙，都不是達成一致的基準文件。

WBS是把專案的成果物及其所需作業分層分解、加以結構化的方法，可防止作業遺漏，並明確估算和分工的單位。用橫條表示日程的是甘特圖，按掙值管理的是EVM，風險的評估是風險分析的說明。

甘特圖用橫條表示各作業專案的開始和結束計劃，廣泛用於日程和進度的視覺化。資料流圖表示資料的流動，E-R圖表示實體間的關係，用例圖表示系統與使用者的互動，都不是用於日程管理的圖。

路徑有A→B→D→F（3＋5＋4＋2＝14天）和A→C→E→F（3＋4＋6＋2＝15天）兩條，F要等兩條路徑都完成，因此整體最短所需天數取較長的15天。這條最長路徑A→C→E→F就是關鍵路徑。14天是隻看A→B→D→F一側的值，12天和13天與任何路徑的合計都不一致。

路徑有A→B→D→F（2＋4＋3＋1＝10天）、A→C→D→F（2＋6＋3＋1＝12天）、A→C→E→F（2＋6＋4＋1＝13天）三條，最長的A→C→E→F＝13天就是關鍵路徑。10天和12天是其他路徑的合計，14天與任何路徑都不一致。關鍵路徑上的作業（A、C、E、F）的延誤會直接變成整體的延誤。

功能點法把輸入輸出、查詢、內部檔案等功能的數量和複雜度打分來估算軟體規模，不依賴程式行數，可在開發早期估算。LOC是基於行數的另一種估算尺度，德爾菲法是透過對專家反覆問卷使意見收斂的方法，KJ法是用卡片整理和分組資訊的創意方法。

風險管理按以下順序推進：先是找出風險的風險識別，然後是評估發生機率和影響程度的風險分析（定性和定量），再是決定應對措施的風險應對計劃，最後是執行中跟蹤狀況的風險監視與控制。在識別之前做應對計劃或監視，物件風險尚未確定，無法成立。

規格變更應遵循變更管理流程，在評估對進度、成本和品質的影響後，由變更管理委員會（CCB）判斷批准或駁回。無條件接受會導致延期和品質下降，全部拒絕則連必要的變更也會失去。由負責人當場修改的做法會造成與配置和文件的不一致，失去管控。

利益相關者是發包方、使用者、開發者、經營層等與專案結果存在利害關係的個人和組織的總稱，把握並協調他們的期望是專案管理的重要活動。日程圖是甘特圖，分層的作業分解是WBS，風險清單對應風險登記冊。

SLA是服務提供者與使用者之間就開機率、故障恢復時間、支援時間段等服務品質水準達成一致的約定，是執行服務的評價基準。著作權的保護是許可合同，作業分解圖是WBS，裝置租借是租賃合同的說明，都不是SLA。

ITIL（Information Technology Infrastructure Library）是把IT服務執行管理的最佳實踐體系化的文件群，作為故障管理、變更管理、服務檯等服務管理的框架被廣泛參照。程式語言的規格、規範化理論和無線LAN規格都是別的領域的內容。

開機率用MTBF÷（MTBF＋MTTR）求得：570÷（570＋30）＝570÷600＝0.95。MTBF是從一次故障到下一次故障的平均執行時間，MTTR是修理所需的平均時間。0.90和0.98即使把分母分子弄錯也對不上，0.93也不符合計算。

容量管理是預測資料量、訪問量等未來使用量，有計劃地確保和擴充伺服器、儲存和網路的容量，防患效能下降和容量不足於未然的管理活動。故障時的聯絡體制屬於故障管理和應急響應，密碼的管理屬於使用者管理，許可證數量的管理屬於軟體資源管理。

伺服器虛擬化是藉助虛擬化軟體在1臺物理伺服器上執行多臺虛擬機器的技術，透過伺服器整合提高資源利用效率，並獲得配置變更和恢復的靈活性。物理分散安放和機箱小型化是硬體層面的事，紙面保管與虛擬化無關。

SaaS（Software as a Service）是把應用程式本身作為服務經網路提供的形態，使用者無需安裝軟體即可使用。IaaS提供伺服器等基礎設施，PaaS提供到應用程式執行環境為止的形態；本地部署是在自己組織內持有並運營裝置的形態，不是雲的提供形態。

Society5.0是透過IoT等把現實世界的資料彙集到賽博空間進行分析、再把結果回饋給現實世界，藉助賽博空間與物理空間的高度融合實現經濟發展與社會課題解決兼得的社會構想。在現實上疊加資訊的技術是AR，計算的分擔是分散式處理，開發管理的知識體系是PMBOK的說明。

有監督學習是給出帶正確答案標籤的資料、訓練由輸入預測正確答案的模型的方法，用於影象分類和數值預測等。不給正確答案、讓機器發現資料結構和分組的是無監督學習。面向人的使用者培訓不是機器學習，用隨機數隨機生成輸出也與學習無關。