Friends, in this post I'm going to give you some off technical topic. (It is Technical but no codes or complex theories ) In software engineering we heard terms like configuration management, change management etc???
What is meant by configuration Management??????
So this article will provide you a deep dive into configuration management and its subsidiaries...
Check it out!!!!!
Check it out!!!!!
Starting from Introduction Overview
Changes
are inevitable when software is built. A primary goal of software engineering
is to improve the ease with which changes can be made to software.
Configuration management is all about change control. Every software engineer
has to be concerned with how changes made to work products are tracked and
propagated throughout a project. To ensure that quality is maintained the
change process must be audited. A Software Configuration Management (SCM) Plan
defines the strategy to be used for change management.
Software
Configuration Items (SCI)
·
Computer
programs (both source and executable)
·
Documentation
(both technical and user)
·
Data
(contained within the program or external to it)
Fundamental
Sources of Change
·
New
business or market conditions dictate changes to product requirements or
business rules
·
New
stakeholder needs demand modification of data, functionality, or services
delivered by a computer-based system
·
Business
reorganization causes changes in project priorities or software engineering
team structure
·
Budgetary
or scheduling constraints cause system to be redefined
Configuration
Management System Elements
·
Component elements – set of tools coupled within a file
management system to enable access to and management of each SCI
·
Process elements – collection of procedures and tasks that
define and effective approach to change management for all stakeholders
·
Construction elements – set of tolls that automate the
construction of software by ensure a set of validated components is assembled
·
Human elements – team uses a set of tools and process
features encompassing other CM elements
Baselines
·
A
work product becomes a baseline only after it is reviewed and approved.
·
A
baseline is a milestone in software development that is marked by the delivery
of one or more configuration items.
·
Once
a baseline is established each change request must be evaluated and verified by
a formal procedure before it is processed.
·
Baseline
work products are place in a project database or repository
SCM
Repository Functions
·
Data
integrity
·
Information
sharing
·
Tool
integration
·
Data
integration
·
Methodology
enforcement
·
Document
standardization
SCM
Content
·
Problem
description
·
Problem
domain information
·
Emerging
system solution
·
Software
process rules and instructions
·
Project
plan, resources, and history
·
Organizational
content information
SCM
Tool Features
·
Versioning - control changes to all work products
before and after release to customer
·
Dependency tracking and change management - tracking relationships among
multiple versions of work products to enable efficient changes (link
management)
·
Requirements tracing – depends on link management, provides
the ability to track all work products that result from a specific requirements
specification (forward tracing) and to identify which requirement generated by
any given work product (backward tracing)
·
Configuration management – works closely with link management
and versioning facilities to keep track of a series of configurations representing
project milestones or production releases
·
Audit trails -
establishes additional information about when, where, why, and by whom
changes were made
SCM
Process Objectives
1.
Identify
all items that define the software configuration
2.
Manage
changes to one or more configuration items
3.
Facilitate
construction of different versions of a software application
4.
Ensure
that software quality is maintained as configuration evolves
Software
Configuration Management Tasks
·
Identification
(tracking multiple versions to enable efficient changes)
·
Version
control (control changes before and after release to customer)
·
Change
control (authority to approve and prioritize changes)
·
Configuration
auditing (ensure changes made properly)
·
Reporting
(tell others about changes made)
Configuration
Object Identification
·
To
control and manage configuration items, each must be named and managed using an
object-oriented approach
·
Basic
objects are created by software engineers during analysis, design, coding, or
testing
·
Aggregate
objects are collections of basic objects and other aggregate objects
·
Configuration
object attributes: unique name, description, list of resources, and a
realization (a pointer to a work product for a basic object or null for an aggregate object)
Version
Control
·
Combines
procedures and tools to manage the different versions of configuration objects
created during the software process
·
Version
control systems require the following capabilities
- Project repository – stores all
relevant configuration objects
- Version management capability –
stores all versions of a configuration object (enables any version to be
built from past versions)
- Make facility – enables collection
of all relevant configuration objects and construct a specific software
version
- Issues (bug) tracking
capability – enables team to record
and track status of outstanding issues for each configuration object
·
Uses
a system modeling approach (template – includes component hierarchy and
component build order, construction rules, verification rules)
Change
Control
·
Change
request is submitted and evaluated to assess technical merit and impact on the
other configuration objects and budget
·
Change
report contains the results of the evaluation
·
Change
control authority (CCA) makes the final decision on the status and priority of
the change based on the change report
·
Engineering
change order (ECO) is generated for each change approved (describes change,
lists the constraints, and criteria for review and audit)
·
Object
to be changed is checked-out of the project database subject to access control
parameters for the object
·
Modified
object is subjected to appropriate SQA and testing procedures
·
Modified
object is checked-in to the project database and version control mechanisms are
used to create the next version of the software
·
Synchronization
control is used to ensure that parallel changes made by different people don’t
overwrite one another
Software
Configuration Audit Questions
1.
Has
the change specified by the ECO been made without modifications?
2.
Has
a FTR been conducted to assess technical correctness?
3.
Was
the software process followed and software engineering standards been properly applied?
4.
Do
the attributes of the configuration object reflect the change?
5.
Have
the SCM standards for recording and reporting the change been followed?
6.
Were
all related SCI's properly updated?
Configuration
Status Reporting Questions
1.
What
happened?
2.
Who
did it?
3.
When
did it happen?
4.
What
else will be affected by the change?
WebApp
Configuration Issues
·
Content
·
integrating heterogeneous
media
·
volatility
·
People
·
designers often
are forced to create content
·
content
creators often have no software engineering knowledge
·
Scalability
·
simple WebApps
become large quickly
·
rigor of
configuration control should be proportional to its size
·
Politics
·
Who owns a
WebApp?
·
Who assumes
responsibility for accuracy?
·
Who makes
changes?
·
Who pays for changes?
Content Management System
·
Establishes a process that acquires existing content, structures it to be
presented to an end-user, and provides for display to the client-side
environment
·
Collection subsystem
o converts content to
displayable format
o organizes content for
client-side display
·
Management subsystem
o content database
o database capabilities
o configuration management
functions
·
Publishing subsystem
o static elements
o publication services
o external services
WebApp Change Classes
·
Class 1 – content or function change to correct error or enhance local
content or functionality
·
Class 2 – content or function change that has impact on other content
objects or functional components
·
Class 3 – content or function change that has broad impact across WebApp
·
Class 4 – major design change that will be noticeable to one or more
categories of user
WebApp Change Management
·
Code and go philosophy dominates WebApp development
·
Class 1 and 2 changes are treated informally and are handled in an agile
manner
·
Class 2 changes require an impact study
·
Class 3 and 4 changes are handled in and agile manner, but some documentation and more formal change review procedures are required
·
Class 3 changes are reviewed by developers
·
Class 4 changes are reviews by both developers and stakeholders
WebApp Version Control
1. Central repository for
WebApp project should be established
2. Each Web engineer should
have his or her own working folder
3. Clocks on all developer
workstations should be synchronized
4. As new configuration
management object as developed or changed they are imported into the
repository.
5. A time-stamped log message
should be made any time an object is imported or exported from the repository.
Web App Auditing and Reporting
·
In the interest of agility auditing and reporting functions are
deemphasized
·
Changes can be tracked by reviewing the change log
Automatic e-mail messages can be used to notify
affected stakeholders when changes are made
Hope this article help you to understand the concept of Configuration Management, Please share your feedbacks!!!
No comments:
Post a Comment