軟體工程

第一章 Introduction

大啊看家菁給的 pdf

Software project failures (軟體專案失敗)

原因
1. 軟體複雜度提高
2. 未落實軟體工程的方法

Essential Attributes of Good Software (好軟體的必要特性)

特性	敘述
Maintainability (可維護性)	Software should be written in such a way so that it can evolve to meet the changing needs of customers (軟體必須能隨顧客的需求進化)
Dependability and security (可靠性&安全性)	should not cause physical or economic damage in the event of system failure.(系統錯誤不應該導致物理上或商業上的損失) Malicious users should not be able to access or damage the system.(不可以讓壞壞使用者存取或破壞系統)
Efficiency (效率)	should not make wasteful use of system resources such as memory and processor cycles (不應浪費系統資源,ex.處理器或記憶體)
Acceptability (可接受性)	understandable, usable and compatible with other systems that they(the users) use (必須可理解、可用，並和使用者所用的其他系統相容)

Software Development Life Cycle (軟體開發生命週期)

中文版

General issues affecting software (一般會影響軟體的問題)

Heterogeneity 異質性 (Difficulty is flexibility of system 困難在於系統的彈性)
As well as running on general-purpose computers, software may also have to execute on mobile phones and tablets(除了在一般用途的電腦上運作，軟體可能也需要在行動電話或平板上執行). You often have to integrate new software with older legacy systems written in different programming languages(通常必須將新軟體與用不同程式語言撰寫的舊系統整合).
Business and social change (Difficulty is process)
Security and Trust (Difficulty is design)
Scale (Difficulty is flexibility)

Discussion

Application Type (應用類型)
Development Cycle (開發方法)
- Waterfall(瀑布式開發)
- Agile(敏捷式開發)
Discuss the 4 product's characteristics? How we should achieve them? How flexible are they?

(Cell phone games, ATM software, Mission critical software, Embedded controller system)

ATM
- Security
- Accessible to end-users (Avoid double billing etc.)
Mission Critical Software
- Development : Waterfall Cycle
- Can't update

第二章 Software Processes

Software Engineering Processes

Set of related activities which lead to production of software system (產出軟體所需的一系列活動)
No universal method (沒有固定方法)
Method used depends on (方法取決於)
- company 公司
- type of software being developed 開發的軟體類型
- Requirements of software customer 客戶需求
- Skills of people writing the software 開發者技能

4 Common Fundamental Activities (共同的基本活動)

Specification(規格)
Development(開發，達成需求的規格)
Validation(驗證是否達到要求)
Evolution(進化，隨客戶需求)

Sub-activities: requirements validation, architectural design, unit testing, software configuration management, project planning to support production activities.

Software development processes

Safety critical systems have a very structured develop process as required, detail records maintained
(攸關生命的系統通常需要結構嚴謹的開發程序)
Business systems with rapidly changing requirements need to be more flexible, agile process is better.
(經常變動的商業系統需要有彈性的開發程序，適合使用agile)

Professional software development

Plan-driven processes
- all process activities are planned in advance and progress measured against the plan
  (事先計畫所有的開發活動且用計畫衡量開發進度)
Agile processes
- planning is incremental and continual.Easier to change process to reflect changing customer or product requirements
  (遞增、連續的計畫，較易隨客戶或產品需求改變開發程序)
need to find a balance between the two types of process
(需在兩者間找到平衡)

Process models的種類

Waterfall model
- 階段式
- 制定規格, 開發, 驗證, 進化
Incremental development
- 交錯式: 制定規格, 開發, 驗證
- 軟體隨著版本增加進化
Integration and configuration
- 依靠可重複使用的元件和系統
Rational Unified process (RUP) 統一軟體開發過程
- 整合上述所有process model
- 支援原型設計(prototyping)以及疊代式(iterative)開發

Waterfall

源自大型軍事系統的工程模型
Plan-driven
在開始前計畫所有程序
Waterfall的五個階段
1. Requirements analysis and definition (分析、定義需求)
  - 系統的服務、限制、目標
  - 詳細的定義，並用於制定系統規格
2. System and software design (系統、軟體設計)
  - 軟、硬體需求
  - 整體架構
  - 軟體系統間的關係
3. Implementation and unit testing (實作及單元測試)
  - 軟體變成多個實際的程式單元
  - 單元測試確保各個單元皆達到需求
4. Integration and system testing (整合及系統測試)
  - 整合程式單元並進行系統測試
  - 系統測試結束後進行交付
5. Operation and Maintenance (運行及維護)
  - 軟體生命週期中最長的一段
  - 系統被安裝、使用
  - 錯誤修正、增強(發現新需求)
原則上waterfall各階段的結果是一個以上被簽結(signed off)的文件。下一個階段在前一個階段結束後才會開始。硬體開發的製造成本很高，因此上述方法很合理。然而，對軟體開發而言，各階段因資訊的回饋而重疊，如設計過程中會發現需求的問題，程式撰寫中會發現設計的問題等等。軟體開發程序並非線性，需考慮各階段之間的回饋問題。
Waterfall適用於
- Embedded systems(嵌入式系統): Interface with hardware
- Critical systems(攸關生命的系統): extensive safety and security analysis of software specification and design
- Large software systems(大型軟體系統): part of broader engineering system developed by several partner companies
Changes and Life Cycle
- 在開發程序中有新資訊時，必須修改前一階段的文件)
  - 若需求成本過高，需調整需求
  - 客戶必須同意
運行與維護階段
- 處理錯誤和被忽略的需求)
- 可能需要新功能
- 系統需要持續進化避免過時
可能重複先前的階段
缺點
- 缺乏彈性
Alternatives 替代方案
- 若資訊的溝通可行且需要快速改動，建議選擇遞增式的開發，例如agile
- 變體
  - Formal system development via mathematical modeling
  - Based on B method

Incremental development (遞增式開發)

Based on developing an:
- initial implementation (初步實行)
- getting feedback from users and others (取得回饋)
- Evolving software through several versions until required system developed (實作多個版本直到系統達到需求)
Interleaving (交錯)
- Specification, development, validation (規格,開發,驗證)
- Rapid feedback across activities (在開發活動中得到快速的回饋)

Incremental development

優點
- 改動成本低
  - 分析和文件的量遠低於waterfall
- 容易即時獲得客戶的回饋
  - 客戶可評斷新功能
  - 不易從文件判斷
- 提前交付時間
缺點
- 管理上
  1. 過程不可視
    - 管理者需要用可交付的成果來衡量進度
    - 為快速開發的軟體寫文件並不划算
  2. 系統結構性變低(degrade,降級)
    - 定期的修改讓code變亂
    - Agile建議定期重構程式碼(refactoring)
- 不適合大型、複雜、多團隊合作的project
  1. 大型系統需要穩定的framework或archietecture
  2. 需清楚定義各團隊的職責
  3. 以上兩點需要事先的計畫

Integration and configuration

Informal reuse takes place regardless of the development process.(不論開發過程如何，都會發生非正式的再使用)
Rely on a base of reusable software components and an integrating framework.(依賴可重複使用的軟體組件以及整合框架的基礎)

Process Activities

Software specification 軟體規格制定

了解及定義系統所需的功能、限制
此階段的錯誤會影響下一階段
在規格制定前，需先進行可行性及市場的研究
目標
- 產出requirements document (給stakeholder)
需求工程的主要活動
1. 需求獲取和分析(Requirements elicitation and analysis )
  - 透過觀察現有系統、與潛在用戶交流來制定需求
  - 開發prototype
2. 需求規格(Requirements specification )
  - 把需求分析獲得的資訊整理為需求文件
  - User Requirements 抽象
  - System Requirements 詳盡
3. 需求驗證(Requirements validation)
  - 驗證需求的完整性、一致性、可行性
  - 需求中的錯誤通常在此階段被發現
上述3個活動互相交錯
agile
- 在agile中，需求規格不是獨立的活動，它被視為系統開發的一部份
- 需求在每個increment開發前提出(非正式)
- 需求以使用者為優先
- 從和開發團隊密切合作的使用者獲取需求

Software design and implementation 軟體設計與實作

實作階段(Implementation Stage)：開發一個可執行的系統
軟體設計和coding可能是分開的
agile的軟體設計和coding是互相交錯的，無正式設計文件
軟體設計
- 描述軟體的結構
- 系統使用的資料模型&結構
- 元件之間的介面和演算法
- 軟體設計是遞增、階段式的
- 會回到之前的階段(backtrack)("進兩步退一步")
Abstract model of design process
Software interfaces
- 大部分的軟體會和其他軟體互相作用(OS,資料庫,其他應用程式等)
  - 上述軟體構成了軟體平台(platform)
  - 和此平台相關的資訊對設計過程非常重要
  - 對於資料的描述必須是設計過程的input
  - 有助於定義系統資料的組織
- 設計過程中的活動取決於開發的系統
  - 例如：即時系統需要時間的設計，不需要資料庫
Activities
- 結構設計 Architectural design
  - 確定整體系統結構
  - 主要元件/子系統的關係
- 資料庫設計 Database design
  - 設計系統的資料結構以及資料庫的表示方式
  - 工作量取決於重複使用或是設計新資料庫
- 介面設計 Interface design
  - 清楚定義元件間的介面
  - 讓一個元件可以在不了解其他元件的內部運作的情況下，順利使用其他元件
  - 使元件可被單獨設計
- 元件選擇與設計 Component Selection and design
  - 搜尋可重複使用的元件
  - 此階段的設計可能只是對元件的簡單描述，細節交由程式設計人員處理
  - 可能列出需要修改的現存元件清單
  - 可能用UML表達設計模型
設計產出 Design Outputs
- 攸關生命的系統
  - 詳盡的設計文件
  - 基於模型的方法 - 產出圖表
  - Agile - 產出code
Programming 程式撰寫
- 沒有通用的程序
- Debugging
  - 缺陷測試 Defect testing - 發現缺陷的存在
  - Debugging - 找出錯誤的位置並修正
- 使用工具輔助debug

Software Validation 軟體驗證(Verification & Validation,V&V)

第三章 AGILE SOFTWARE DEVELOPMENT

基本原理 Rationale

應對市場、經濟、競爭的變化
軟體開發速度需要提高以應對競爭
必須達到基本需求(requirements),若時間允許則要求品質(quality)
很難先有一套穩定的規格再開始
- 不適用階段性方法，如waterfall或spec-based(基於規格的方法)
需求因客戶的理解和需要而改變
- Automation, external factors, interactions with other systems.
必須能回應需求的改變
- Design, implementation, must be reworked.
Software procurement has shorter schedules than hardware.(軟體採購的週期比硬體更短)
- Reason for software request change if a long process is used.(若使用了漫長的過程，需要軟體的理由會在開發途中改變)
Development processes that focus on rapid software development and delivery are essential.(重視快速研發及發行軟體的開發流程是很重要的)

Plan-Driven(基於計畫)的開發程序沒落

需要完整的需求(requirement)才能開始
當需求變動，系統的設計/實作需要重做
waterfall和spec-based的程序太冗長
給出規格到軟體交貨之間所需的時間很長
各階段的輸出會影響下階段的計畫

Agile的特色

規格制定、設計、實作互相交錯
遞增式的開發系統
廣泛的使用工具

Agile 的原則(Principle)

Agile manifesto 敏捷軟體開發宣言
藉著親自並協助他人進行軟體開發，
我們正致力於發掘更優良的軟體開發方法。
透過這樣的努力，我們已建立以下價值觀:
- 個人與互動重於流程與工具
- 可用的軟體重於詳盡的文件
- 與客戶合作重於合約協商
- 回應變化重於遵循計劃
也就是說，雖然右側項目有其價值，
但我們更重視左側項目。

原則	要點
Customer involvement 顧客參與	客戶需密切參與開發程序,以提供新的系統需求，並評估目前的遞增版本
Embrace Change 樂見改變	設計可容許改變的系統
Incremental delivery 遞增式交付	遞增式的開發，由客戶決定遞增中要加入的需求
Maintain simplicity 維持簡潔	簡化開發程序，積極消除系統的複雜性
People, not process 注重人，而非程序	團隊成員需發揮能力，並且可以制定自己的工作程序

Extreme Programming 極限編程

把備受肯定的做法，例如：疊代式開發，發揮到極限
多個新版本可能在一天內被開發、整合、測試
用user story表達需求
Extreme Programming Practices

Scrum

會頻繁產出實際成果
流程：
- 將開發過程分割成許多階段(衝刺，sprint)，每階段為固定時長(2~4周)
- 不須完整的產品需求規劃
產出：
- 產品代辦清單(product backlog)
  - PBI (Product Backlog Item)
  - 系統的需求，通常以user story呈現，user story包含：
    1. 需求的簡述(As a (user type), I want to (goal), so that (reason)…)
    2. 以流程步驟或對話形式描述操作程序及所得效益
    3. 描述如何測試或展示，確認系統符合Product owner的期望
  - 產品需求特性、價值預估、十成預估、優先順序等
  - 展示交付給product owner的最小單位
  - Product owner依市場需求、上市時程、團隊資源、功能重要性等決定優先順序
- 工作待辦清單(sprint backlog)
  - 從product backlog中選取PBI
  - 將PBI分解成更小的工作任務
  - 開發團隊領取工作任務，並在該sprint中完成
- 潛在可發布增量(potentially releasable increment,PRI)
  - 簡稱增量(increment)
  - 在sprint所增加的軟體功能
  - 隨時可以交付給客戶的版本，也就是可用的(usable)版本
  - 基於上一次的increment進行擴增
過程中開的會議：
1. sprint planning(衝刺規劃會議)
  - 每一個sprint前，product owner與scrum團隊開會，從product backlog中選擇一些PBI
  - scrum團隊將PBI分成數個工作任務(task)，紀錄於sprint backlog，成為SBI(sprint backlog item)
2. daily scrum(每日站立會議)
  - 每個上班日定時召開
  - 成員依序報告昨天完成的進度、今天預期的進度、遭遇的問題等
  - 在task board紀錄工作狀態(是否完成、完成日期、花費時間等)
  - 自待領區(backlog)領取今天要做的工作，標註姓名日期，並移至領出區(in progress)
3. sprint review(評審會議)
  - 當次sprint將結束前，scrum團隊向product owner 展示(demo)已完成的功能及品質特性(即展示這次sprint的increment)
  - 此展示也稱為sprint demo
  - 可邀請專案相關人員提供意見
4. sprint retrospective(回顧會議)
  - 由scrum master主持，檢討該次sprint的優缺點及改進事項
  - 進行下一個sprint，重複這些流程直到專案結束或完成所有PBI
參與角色：
- product owner
  - 內部/外部的客戶、委託者或聯絡代表，只有一個人
  - 擬定產品願景及目標
  - 產出product backlog
  - 決定PBI的優先順序
  - 監控產品的進展
  - 認可sprint demo的結果
  - 產品的守護者，決定要開發什麼(what)
- development team
  - 跨功能(分析、設計、寫程式、測試)的團隊
  - 負責完成工作任務，建構increment，在sprint review展示工作成果
  - 決定如何開發(How)
- scrum master
  - 排解development team在過程中遇到的阻礙
  - product owner和development team間的橋梁
  - Servant-Leadership(僕人式領導)，~~開發團隊的工具人~~

第六章 Architectural design

前言

何謂Architecture Design
- software design process的第一步
- It is the critical link between design and requirements engineering
- 識別系統中的主要結構元件(main structural component)以及它們之間的關係
- output: 描述系統組織架構以及系統元件間互相溝通情形的模型(an architectural model that describes how the system is organized as a set of communicating components)
Architecture Design in Agile
- 初期專注於overall system architecture
- Incremental的開發不適於system architecture
- 理由:重構system architecture很貴，因需要modify大部分的系統元件
system architecture為何重要
- 影響performance, robustness, distributability, and maintainability of a system
- 單一的元件實作的是functional system requirements，但主要影響non-functional system characteristics的是system architecture
設計和撰寫system architecture document的3個好處
- Stakeholder communication
- System analysis
- Large-scale reuse
Block Diagram
- 可能是唯一的architecture description
- 優點: 直覺、易懂，可促進stakeholders間的溝通
- 缺點: 只表示high-level的system structure
- 加入更多細節
  - 優:減少誤會
  - 缺:耗時

6.1 Architectural Design Decision

定義: 設計系統組織結構，以滿足functional and non-functional requirements的創造性過程
沒有公式化的做法
Architectural pattern
- 定義: description of a system organization
- 例: client–server organization, layered architecture
由於non-functional requirements和system architecture的關係密切， architectural style and structure取決於non-functional requirements，列舉如下:
- Performance
  - 將operation本地化(localize)，使用的component數量較少
  - 使用較大的component以避免過多component間的溝通
  - 考慮可讓system被複製並且在不同processor上執行的runtime system organizations
- Security
  - layered structure
  - 最重要的在最內層，且用high level of security validation保護
- Safety
  - safety-related operations位於一個(或少數個)component內，以減少safety validation之成本
- Availability
  - 使用多餘的component，以便在不停止system的狀態下替換或更新component
- Maintainability
  - 使用小的component，以便之後更改
  - data的生產者和消費者需要分開
  - 避免使用共享的data structure

6.2 Architectural Views

圖形化的view僅能顯示系統的一個面向，通常需要多個views來表示system architecture
4+1 view model
- Logical view
  - 展示系統的key abstractions (objects or object classes)
  - 展示system requirements和實體(entities)的關係
- Process view
  - 用interactive processes組成run-time的系統
  - 協助評斷 non-functional system characteristics 如: performance and availability
- Development view
  - 將軟體分解成可被單一開發者(或開發團隊)實作的元件
  - 對軟體的manager和programmer有幫助
- Physical view
  - 展示系統的硬體，以及展示軟體元件如何分散在不同processor上
  - 幫助system engineer進行系統部署
- (+1) Conceptual view
  - 抽象化的view。以此為基礎，可把high-level requirement分解為詳細規格(specification)
  - 幫助工程師決定重複使用的元件
  - 表示一整條product line，而非單一系統
  - 圖片支援

6.3 Architectural Pattern

Name	Layered architecture
Description

第七章 Design and Implementation

前言

可執行的(executable)Software被開發出來的階段
- 簡單的系統 -> 合併多個software engineering activities
- 大型系統 -> Design and Implementation只是其中的一個階段
design and implementation activities 互相交錯
- design
  - 創造性的(creative) process
  - 基於客戶需求，識別(identify)software components and their relationship
  - design有時是獨立的階段，有其文件和模型
  - design有時僅在programmer腦中或白板/紙上的草稿
    - Agile使用非正式的草圖，並將design decision交給programmer
  - design is about how to solve a problem
- implementation
  - 以程式實現設計
  - 和design密切相關，design時須考慮implementation的issue
UML
- 適合物件導向的design
  - web programming也適用
- dynamically typed languages(例如 Python. Perl)不適合
build or buy
- 買現成(off-the-shelf)
  - 便宜
  - 快速
  - 僅需依照user requirement調整
- 重複使用現成產品的應用程式開發
  - 專注於configuration
  - 不需要system modeling

7.1 Object Oriented Design using the UML

作業

HW1

1.2 What is the most important difference between generic software product development and custom software development? What might this mean in practice for users of generic software products?
1.3 Briefly discuss why it is usually cheaper in the long run to use software engineering methods and techniques for software systems.
1.4 Software engineering is not only concerned with issues like system heterogeneity, business and social change, trust, and security, but also with ethical issues affecting the domain. Give some examples of ethical issues that have an impact on the software engineering domain.
1.5 Based on your own knowledge of some of the application types discussed in Section 1.1.2, explain, with examples, why different application types require specialized software engineering techniques to support their design and development.
1.8 Noncertified individuals are still allowed to practice software engineering. Discuss some of the possible drawbacks of this.
1.10 The “Drone Revolution” is currently being debated and discussed all over the world. Drones are unmanned flying machines that are built and equipped with various kinds of software systems that allow them to see, hear, and act. Discuss some of the societal challenges of building such kinds of systems.

HW2

2.1 Suggest the most appropriate generic software process model that might be used as a basis for managing the development of the following systems. Explain your answer according to thetype of system being developed:

A system to control antilock braking in a car

A virtual reality system to support software maintenance

A university accounting system that replaces an existing system

An interactive travel planning system that helps users plan journeys with the lowestenvironmental impact
2.3 Consider the integration and configuration process model shown in Figure 2.3. Explain why itis essential to repeat the requirements engineering activity in the process.
2.4 Suggest why it is important to make a distinction between developing the user requirementsand developing system requirements in the requirements engineering process.
2.6 Explain why software testing should always be an incremental, staged activity. Are program-mers the best people to test the programs that they have developed?
2.9 Suggest two advantages and two disadvantages of the approach to process assessment and improvement that is embodied in the SEI’s Capability Maturity framework.

HW3

3.2. Explain how the principles underlying agile methods lead to the accelerated development and deployment of software.
3.3. Extreme programming expresses user requirements as stories, with each story written on a card. Discuss the advantages and disadvantages of this approach to requirements description.
3.6. Compare and contrast the Scrum approach to project management with conventional plan-based approaches as discussed in Chapter 23. Your comparison should be based on the effectiveness of each approach for planning the allocation of people to projects, estimating the cost of projects, maintaining team cohesion, and managing changes in project team membership
3.8. Why is it necessary to introduce some methods and documentation from plan-based approaches when scaling agile methods to larger projects that are developed by distributed development teams?
3.10. One of the problems of having a user closely involved with a software development team is that they “go native.” That is, they adopt the outlook of the development team and lose sight of the needs of their user colleagues. Suggest three ways how you might avoid this problem, and discuss the advantages and disadvantages of each approach.

HW4(不用繳)

4.2. Discover ambiguities or omissions in the following statement of the requirements for
part of a drone system intended for search and recovery:

The drone, a quad chopper, will be very useful in search and recovery operations, especially in remote areas or in extreme weather conditions. It will click high-resolution images. It will fly according to a path preset by a ground operator, but will be able to avoid obstacles on its own, returning to its original path whenever possible. The drone will also be able to identify various objects and match them to the target it is looking for.
4.4. Write a set of non-functional requirements for the drone system, setting out its expected safety and response time.
4.6. Suggest how an engineer responsible for drawing up a system requirements specification might keep track of the relationships between functional and non-functional requirements.
4.7 Using your knowledge of how an ATM is used, develop a set of use cases that could serve as a basis for understanding the requirements for an ATM system.
4.9. When emergency changes have to be made to systems, the system software may have to be modified before changes to the requirements have been approved. Suggest a model of a process for making these modifications that will ensure that the requirements document and the system implementation do not become inconsistent.

HW5

5.2. The way in which a system boundary is defined and an appropriate context model is created may have serious implications on the complexity and cost of a project. Give two examples where this may be applicable.
5.5. Develop a sequence diagram showing the interactions involved when a student registers for a course in a university. Courses may have limited enrollment, so the registration process must include checks that places are available. Assume that the student accesses an electronic course catalog to find out about available courses.
5.6. Look carefully at how messages and mailboxes are represented in the email system that you use. Model the object classes that might be used in the system implementation to represent a mailbox and an email message.
5.7. Based on your experience with a bank ATM, draw an activity diagram that models the data processing involved when a customer withdraws cash from the machine.
5.10. In principle, it is possible to generate working programs from a high-level model without manual intervention when using model-driven architectures. Discuss some of the current challenges that stand in the way of the existence of completely automated translation tools.

HW6

6.1 When describing a system, explain why you may have to start the design of the system architecture before the requirements specification is complete.
6.3 Performance and security may pose to be conflicting non-functional requirements when architecting software systems. Make an argument in support of this statement.
6.7 An information system is to be developed to maintain information about assets owned by a utility company such as buildings, vehicles, and equipment. It is intended that this will be updatable by staff working in the field using mobile devices as new asset information becomes available. The company has several existing asset databases that should be integrated through this system. Design a layered architecture for this asset management system based on the generic information system architecture shown in Figure 6.18.
6.8 Using the generic model of a language processing system presented here, design the architecture of a system that accepts natural language commands and translates these into database queries in a language such as SQL.
6.9 Using the basic model of an information system, as presented in Figure 6.18, suggest the components that might be part of an information system that allows users to view box office events, available tickets and prices, and to eventually buy tickets.

HW7(麻煩幫檢查有沒有抄錯版本或題號)

(我補了7.3和一點點版本不同的敘述、應該不影響答案，看有沒有人再幫忙對一次~)

7.1 Using the tabular notation shown in Figure 7.3, specify the weather station use cases for Report status and Reconfigure. You should make reasonable assumptions about the functionality that is required here.
7.3 Using the UML graphical notation for object classes, design the following object classes, identifying attributes and operations. Use your own experience to decide on the attributes and operations that should be associated with these objects.
■ a messaging system on a mobile (cell) phone or tablet
■ a printer for a personal computer
■ a personal music system
■ a bank account
■ a library catalogue
7.7 Draw a sequence diagram showing the interactions of objects in a group dairy system when a group of people are arranging a meeting.
7.9 When code is integrated into a larger system, problems may surface. Explain how configuration management can be useful when handling such problem.
7.10 A small company has developed a specialized product that it configures specially for each customer. New customers usually have specific requirements to be incorporated into their system, and they pay for these to be developed and integrated with the product. The software company has an opportunity to bid for a new contract, which would more than double its customer base. The new customer wishes to have some involvement in the configuration of the system. Explain why, in these circumstances, it might be a good idea for the company owning the software to make it open source.

演講

毫米波
5G最大的挑戰 - cost
怎麼解決成本問題?
O-RAN是一個2018年成立的組織，成員以電信商(operator)、vendor(軟硬體廠商)、研究機構為主
- 智能化，在基地台內加入AI
- open的架構(白盒化) 電路軟體公開透明
- 虛擬化(硬體->軟體) 雲端化
- 把基地台拆解成不同機器，由不同vendor提供(類似自組電腦)
O-RAN模組
- RU
- DU
- CU
台灣在O-RAN的機會
- RU.DU 硬體
- 軟體
整合不同的模組
- Cisco
O-RAN官網

期中考

CH 5-8 HW