1. 軟體型態管理

2. Problems 多人同時更新軟體 多人共用一程式碼，部分程式已更新，但有人不知道 使用版本不一致 發現程式錯誤原因但無法有效通知相關人員

3. CONFIGURATION MANAGEMENT Today we talk about Software Configuration Management (SCM for short): - What? - Why? - How?

4. Introduction Do you agree? Make a plan and stick with it – never waffle Requirements must be frozen – how else will we know what to code

5. Plans are living documents Plans will be in a continual state of change as project knowledge increases. Requirements are never frozen. We need some method of managing the change.

6. What is configuration? 所謂「型態」是對一個產品實體與功能特徵的描述， 實體特徵如 : 產品形狀、大小、重量、使用材料等； 功能特徵 : 可靠度、安全性、精確度等。 型態管理是產品在其生命週期中，依據其需求、設 計與作業資訊，建立與維持產品表現、功能與實體 屬性具一致性的管理程序。 Configuration management covers the lifecycle of software development

7. WHAT IS SCM? A set of activities designed to control change by identifying the work products that are likely to change,establishing relationships among them, defining mechanisms for managing different versions of these work products, controlling the changes imposed, and auditing and reporting on the changes made (Roger Pressman)

8. WHY SCM? Multiple people are working on changing software More than one version of the software needs to be supported: Different releases Different installations with different functionalities Development versions Software needs to run on different operating systems and different hardware

9. SCM & CMM SCM is an SEI CMM level 2 KPA Goals: Software configuration management activities are planned. Selected software work products are identified, controlled and available. Changes to identified software work products are controlled Affected groups and individuals are informed of the status and content of software baselines

10. SCM Activities CM data management Version management - Release versions - Development versions Concurrent development management Change management

11. Baselines Baseline: A specification or a product, which is formally reviewed and agreed on, and which can only be changed through formal change procedures Before an item becomes a baseline, changes can be made quickly and informally. Baseline is a kind of a milestone in software development Baseline typically creates new versions in SCIs.

12. Typical Baselines PhaseBaseline Feasibility study Requirements defn.Functional baseline SRS, Interface spec.Allocated baseline Detailed designDesign baseline Source and Object code User manuals Test documentsProduct baseline InstallationOperational baseline

13. Basic Requirements for an SCM System Identification: 將產品分解至可單獨獲得或管制的 項目，以利管制工作的進行。 Control: 透過系統化的程序，管制各型態項目的工 程變更。 Auditing: 對型態項目做全盤審核，並確認最終產 品滿足原定義之需求。 Status accounting: 有效管理型態項目所必須擁有 的產品資訊，並持續記錄型態項目之現況。

14. Identification Each software part is labeled so that it can be identified. Furthermore, there will be different versions of the software

15. SCM Items Design documents Code files Test data Test drivers Manuals System configuration data etc. A meaningful combination of above, meant to be treated as a single entity Also hardware items can be considered CM Items

16. Basic SCI information Item identity Baseline to which it belongs Relationships to other items Version Variant

17. SCM Terminology Version A SW CI having a defined set of functional capabilities. Revisions changes to a version to correct only errors in design logic but does not affect documented functional capabilities since none of the requirements have changed. Variants a variation of a version developed to run on different types of HW, or to provide slightly different facilities for different users.

18. Examples 1.11.21.31.4 successive versions branching versions (variants) 1.11.21.31.4 1.3.1.11.3.1.2

19. Managing SCM Items There may easily be thousands of SCM items A naming scheme should be introduced to identify these The hierarchical arrangement of software project items should be supported Should all CM items be managed When to start management for an item? If you start too early, you get bureaucracy.-> 官僚 If you start too late, you get chaos.

20. Control Proposed changes to a SCI are reviewed and, if approved, incorporated into the software configuration.

21. Version control / 1 Procedures and tools to manage different versions of configuration objects Versions may not always be created in sequential order, e.g. you create 1.0 -> 1.1 -> 1.2 -> 2.0 and then you need to create 1.3 for some customers who can not run 2.0 but need some changes or improvements.

22. Version control / 2 With big software, you may e.g have 4.0 as the official current version. You work on 5.0 to release it as the next official version, but you have already started to create 6.0, as it takes so long to get it ready.

23. 如何確保文件的版本一致 ? 也許你可以指派一位專人負責管理文件的進出，這個人姑且就叫他 Manager 好了， Manager 待在一間小小的辦公室裡，負責文件庫的維護 和文件的進出。當小組成員 Eric 要修改文件時，就拿磁片到這個窗口請 Manager 複製一份給他， Manager 在複製的同時會記下來：這份文件正 由 Eric 修改；而 Eric 則會把磁片拿到他自己的機器上，把檔案複製到 他的工作目錄（ working folder ），然後進行修改。等到 Eric 修改完畢， 再從工作目錄中把檔案複製到磁片上交給 Manager ，最後文件就被更新 到文件庫中（這動作叫做 check in ），至此整個文件的修改與更新的程 序就完成了。如果在 Eric 修改期間， Vivid 也拿著磁片向 Manager 要求 修改同一份文件，這時 Manager 會告訴 Vivid ：這份文件目前已經由 Eric 領出（ check out ），且還在修改當中，你得等他改完才行。

24. Change Control 專案開始進行 建立或更新 基準線 驗證 基準線 授權更改進行更改驗證更改結果 核准更改 基準線 需求 / 設計 / 使用 變更

25. Change Control / 1 1. Need for change is recognised 2. Someone (like a user) makes a change request 3. Developer evaluates 4. Change report is generated 5. Change control authority decides - Change is denied -> User is informed - Change is accepted -> go to next slide :)

26. Change Control / 2 6. Change request is queued for action and engineering change order (technical descr) is made 7. Assign individuals to make changes to configuration objects 8. ”Check out” configuration items from project repository 9. Make the change 10. Review (audit) the change 11. ”Check in” the changed configuration items

27. Change Control / 3 12. Establish a baseline for testing the change 13. Perform quality assurance (QA) and testing activities 14. ”Promote” changes for inclusion in next release 15. Rebuild appropriate version of software 16. Review (audit) the change to all configuration items 17. Include changes in new version 18. Distribute the new version

28. Techniques for storing Versions Forward Delta files Reverse Delta files Note : The set of differences between two versions is called a delta.

29. Forward Delta Files foward delta files + first version Vn version Vn version User Vn+1 version Vn+1 version Vn version CM System changes

30. Reverse Delta Files reverse delta files + Vn+1 new recent version Vn+1 version User Vn version Vn version CM System changes recent version

31. Configuration Audit A configuration audit establishes that product integrity has been maintained and that changes have taken place in an orderly and controlled manner. Audit of the SW product Audit of SCM activities

32. Physical Configuration Audit consists of determining that all items identified as being part of the configuration are present in the Product baseline it must also establish that the correct version and revision of each part are included in the product baseline and that they correspond to information contained in the baseline ’ s configuration status report.

33. Functional Configuration Audit it verifies that each CI in the product has been tested to determine that it satisfies the functions defined in the specifications or contract(s) for which it was developed.

34. SCM Audit / 1 The following questions should be answered 1. Has the change specified in the ECO been made? Have any additional modifications been incorporated? 2. Has formal technical review been conducted to assess technical correctness? 3. Has the software process been followed and SE standards been applied? 4. Has the change been appropriately recorded in the SCIs?

35. SCM Audit / 2 More questions to be answered: 5. Have Software Configuration Management procedures for the change been followed? 6. Have all related SCIs been properly updated?

36. Status Accounting Reports and documentation produced by the status accounting function They are the auditable entries The accounting provides the historic information to determine both what happened and when on the software project

37. SCM Tools PC based PVCS MS Visual SourceSafe 允許多人同時取出（ check out ）同一個檔案進行修改，並且在將 檔案送回（ check in ）資料庫時，自動進行合併（ merge), 但只有 文字檔（ text files ）才能夠多重 checkouts UNIX SCCS (Source Code Control System) RCS (Revision Control System) CVS (http://www.nongnu.org/cvs/)

38. Software Configuration Management Plan IEEE 828 Software Configuration Management Plan IEEE 1042 Software Configuration Management ISO10007 是國際標準組織針對 ISO90001 所提出之一 個子條款，內容主要規範企業對其產品制訂標準之型 態管理程序，以利產品在其生命週期中之資料管理。

39. Software Configuration Management Plan The SCM Plan is prepared in Project Initiation phase. It documents - what SCM activities are to be done - how they are to be done - who is responsible for doing specific activities - when they are to happen - what resources are required

40. IEEE Standard 828 for SCM Plan Introduction: Describes the Plan’s purpose, scope of application, key terms, and references SCM management: (Who?) Identifies the responsibilities and authorities for accomplishing the planned activities SCM activities: (What?) Identifies all activities to be performed in applying to the project SCM schedules: (When?) Identifies the required coordination of SCM activities with the other activities in the project SCM resources: (How?) Identifies tools and physical and human resources required for execution of the Plan SCM plan maintenance: Identifies how the Plan will be kept current while in effect