1 / 56

Server Technologies II

Server Technologies II. Configuration Management INFO 321 Glenn Booker. Configuration Management (CM). Additional references include: Configuration Management Training Foundation International Society of Configuration Management

derek-decker
Download Presentation

Server Technologies II

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Server Technologies II Configuration Management INFO 321 Glenn Booker INFO321 Week 4

  2. Configuration Management (CM) • Additional references include: • Configuration Management Training Foundation • International Society of Configuration Management • IEEE standards (replaced military standards), such as IEEE 828 (Configuration Management Plans) INFO321 Week 4

  3. Configuration Management (CM) • Need Configuration Management in order: • To define what the product is • To track changes to the product • To help control product integration • (and to meet ISO and CMM standards) • Helps deliver the product 1) on schedule, 2) within budget, and 3) according to the stated requirements INFO321 Week 4

  4. Configuration Management (CM) • Main functions of CM are: • Configuration Identification • Configuration Control • Configuration Audits • Configuration Status Accounting • Done properly, CM is almost invisible! • CM mistakes are often far too visible INFO321 Week 4

  5. Configuration Items • Systems are divided into configuration items • Formal name of major software configuration items may be a “Computer Software Configuration Item” (CSCI) • Scope of each CSCI is selected during high level design based on: criticality, complexity, interfaces, maintenance needs, functions, source (supplier), and documentation needs INFO321 Week 4

  6. Configuration Items • CSCIs may be very broad, such as Software, Hardware, Network, or Documentation • Computer Software Components (CSCs) are often major functions, such as User Interface, or Application Software INFO321 Week 4

  7. Configuration Items • Computer Software Units (CSUs) are single functions, which may still consist of one or more closely-related modules of code INFO321 Week 4

  8. Naming Configuration Items • One naming convention for configuration items is the formaa-bb-cc Where aa is the CSCI numberbb is the CSC numbercc is the CSU number • Extremely complex systems might use multiple levels of CSCs (components) INFO321 Week 4

  9. Configuration Structure Excerpt CSUs -> INFO321 Week 4

  10. Configuration Identification • What is the smallest thing controlled and tracked? • Important to define for maintenance • Answer is called the “Lowest Replaceable Unit (LRU)” • Software: could be a CSU, module, script, etc. • Hardware: chip (CPU), board (motherboard), box (rack element), or unit level (entire rack) INFO321 Week 4

  11. Configuration Identification • Clarify revision, variation, and version • Revisions (revised copy of a CI) include changes to the CI due to: • Added functions (new features) • Performance improvement (redesign) • Reduced bugs (bug fix) • Other directed changes INFO321 Week 4

  12. Configuration Identification • Variations - alternate configurations to meet different requirements • Are generally named differently, not just renumbered • E.g. if different installation sites need variations on some CIs • “Version” is a major step in a CI’s evolution • At the product level, Word 2000 versus Word XP INFO321 Week 4

  13. Configuration Identification • Each CI is given a unique identifier, and tracked by a version number (2.0) and/or revision letter (A, B, …) • Old copies are kept: • In case you need “the last version that worked” • To recreate bugs • To develop metrics for future projects INFO321 Week 4

  14. Configuration Identification • Configuration identifiers are basis for: • Baseline identification • Engineering release • Drawing repository • Document repository • Parts and inventory control INFO321 Week 4

  15. Configuration Control • Scope of controlled CIs includes: • Support software (system build files, compilers, operating system, linkers and loaders, procedure languages, shell scripts) • Object code • CASE elements, third party tools • Libraries • Project plans... INFO321 Week 4

  16. Configuration Control • Test plans and procedures • Test data • Documentation • Software Development Folders (including source code) • CM plans, procedures, and reports • HW platform interfaces • Problem reports INFO321 Week 4

  17. Configuration Control • Establishes: • Interface management • Asset accountability • Change processes • Baseline control • Non-conformance tracking • Upgrade capability INFO321 Week 4

  18. Change Types • Class I - changes to the product’s form, fit, or function (big changes) • Class II - minor changes • Why make this distinction? • Might have more extensive review process for Class I changes, such as cost analysis, expert review, interface impact analysis, etc. INFO321 Week 4

  19. Change Types • Can also distinguish between changes to fix the existing system (break/fix) versus changes to implement new features (meet new requirements) • See sample change control process here and a discussion of possible change relationships INFO321 Week 4

  20. Configuration Audits • Audits can be formal or informal, internal or external (e.g. contractual or legal): • Product buy-off (approve first article off production line) • Assessment (internal audit) • Subcontractor reviews (external) • Functional Configuration Audit (FCA) • Physical Configuration Audit (PCA) INFO321 Week 4

  21. Configuration Audits • Often conduct audits when transitioning from informal to formal control • FCA is done after product has completed certification testing - determines if product is acceptable to the customer INFO321 Week 4

  22. Configuration Audits • PCA immediately follows FCA - determines what the configuration is, and defines the first official Product Baseline INFO321 Week 4

  23. Internal Audits • Review compliance with internal procedures, work flow, and spot checking physical inventory • Determines whether your CM processes are really being used, or serve as dust-catchers INFO321 Week 4

  24. Internal Audits • CM internal audits should be performed by the QA organization • Results are published, and problems fixed INFO321 Week 4

  25. External Audits • External audits may be performed for several reasons: • To prove the quality of your processes (e.g. ISO 9000, CMM) • To provide legal proof of activities (cost audits, tax audits) • To prove to the world you really know what’s going on! • To meet customer requirements INFO321 Week 4

  26. Configuration Status Accounting • Enables: • Traceability through configuration changes • Production of metrics • Integrated repository • Automated tool suites • Change chronology INFO321 Week 4

  27. Configuration Status Accounting • Purpose is to convey output of the other CM processes • Establishes a configuration record • Provides management metrics • Tracks proposed changes through implementation INFO321 Week 4

  28. Configuration Status Accounting • Must be able to: • Identify the current configuration • Report status of all proposed engineering changes • Report status of all configuration audits • Provide traceability among configurations • Track specific configuration identifiers (e.g. serial numbers) INFO321 Week 4

  29. Configuration Status Reports • Baseline Configuration Report • Software Structure Diagram • Periodic reports: • Project library and media contents • Outstanding software • Change Request status • Change Summary report INFO321 Week 4

  30. Management’s Role in CM • Define organization • Assign roles and responsibilities • Identify management representative from CM • Identify training needs • Act as conflict resolution authority INFO321 Week 4

  31. Software-specific CM • Provides: • Version control • Software documentation • Workspace management • Media vaulting • Development library (reuse and other) • Project visibility INFO321 Week 4

  32. Time Need SSR CDR FCA/PCA SDR Concept Definition Requirements Definition Design, Code, and Test Production & Operation End of Life or Archive Functional Baseline SW Allocated Baseline Allocated Baseline Product Baseline SW Product Baseline Baselines During Product Life Cycle INFO321 Week 4

  33. Formal Baselines 1) Functional Baseline - describes the key performance and functions of the product - what will it do? • Completed by the end of concept definition, after successful Software (or System) Design Review (SDR) • What must this product do in order to be successful? INFO321 Week 4

  34. Formal Baselines 2) Software Allocated Baseline (SAB) - consists of the Software Requirements Specification (SRS) and Interface Requirements Specification (IRS!) • After the requirements for the product have been defined, the SAB is released as a result of the Software Specification Review (SSR) • Full development of the software follows, based on the SAB INFO321 Week 4

  35. Formal Baselines • “Allocated” in this context refers to the product’s requirements being allocated, or assigned, to specific parts of the software or system • This defines which functions must be performed by each portion of the software or system INFO321 Week 4

  36. Formal Baselines 3) Allocated Baseline - describes how the functional baseline applies to each major area of the product; What does each part of the product do? How do they interact? • Allocated Baseline follows a successful Critical Design Review (CDR) (well after the SSR) • Before the CDR, there can be one or more Preliminary Design Reviews (PDR) INFO321 Week 4

  37. Formal Baselines • The Allocated Baseline forms the foundation for the remainder of detailed product design and development • If a life cycle model is being used which breaks into subprojects or stages, that break generally occurs after the Allocated Baseline is defined and approved • Allocated Baseline essentially marks the end of high level design INFO321 Week 4

  38. Formal Baselines 4) Product Baseline - describes the final product, including end user, design, and maintenance information • Is first released after development has been completed, as the product goes into production • Generally defined at the end of FCA/PCA INFO321 Week 4

  39. Formal Baselines 5) Software Product Baseline - includes software product specification, Version Description Document (VDD), and the actual software • Is established just after the Product Baseline and FCA/PCA • Consists of the software-related parts of the Product INFO321 Week 4

  40. Formal Baselines • All of the Baselines will evolve throughout the life of the product • All changes to the system must check for changes to baselined documentation too • Software-only projects (no hardware) will simplify to three baselines • Functional, Allocated, and Product INFO321 Week 4

  41. Software Libraries • Need at least three levels of libraries: • Restricted access project archives of each version (CM control only) • Working copies of the current version for day-to-day development and testing, which are checked out to developers • Archive storage (disaster planning) INFO321 Week 4

  42. Library Tasks • “Check in” software - accept software and documentation • Store software in a known location • “Check out” software to authorized users • Use of check in and check out prevents two people from changing one piece of code at the same time INFO321 Week 4

  43. Software Developmental Configuration (SDC) • Consists of all successfully tested and approved software, and approved documentation • Is stored in Software Development Library INFO321 Week 4

  44. Software Developmental Configuration (SDC) • Is controlled manually, or with a CM tool • MS SourceSafe, Rational Clearcase, QVCS, Metrowerks, CVS • Contains the product baseline at selected moments in time INFO321 Week 4

  45. Software Developmental Configuration (SDC) • Has restricted access, and sealed media • Changes only by approval of the Configuration Control Board (or equivalent) • A critical CM concept is to require approval of all changes to anything which has been baselined (put under CM control) INFO321 Week 4

  46. Document Control • A “Release” means that a document is ready for its intended use • The release process, which is part of Document Control, includes reviewing, validating, storing, maintaining, archiving, and communicating controlled design information INFO321 Week 4

  47. Version Control • Tracks initial versions, changes to code, and derived relationships (code splits or merges) • Version control is needed to define, construct, and manage software configurations; and control product releases • Each software release is a collection of programs, data, and documents on magnetic media INFO321 Week 4

  48. Version Description Document • Describes the software to be released • Describes approved changes since the last release • Describes approved changes NOT in this release • Identifies each software release and its documentation INFO321 Week 4

  49. Software Control Drawing • Describes characteristics of executable software, such as the structure of a CSCI, or the relationship between CSCI’s and hardware, e.g. • Interface flow charts • Entity-Relationship Diagrams • Class diagrams • Network diagrams INFO321 Week 4

  50. CM Tools • Source Code Control System • Revision Control System • Build Management • “Make” tools (to compile software) • Might include the entire Software Engineering Environment! INFO321 Week 4

More Related