A Knowledge Based Framework For Managing Software Components

IPASJ International Journal of Information Technology (IIJIT)
Web Site: http://www.ipasj.org/IIJIT/IIJIT.htm

Email:editoriijit@ipasj.org
ISSN 2321-5976
A Publisher for Research Motivation ........
Volume 4, Issue 8, August 2016
A Knowledge based framework for Managing

Software Components
Abid Thyab Al Ajeeli,
Higher Education Committee, C. O. R., Iraq.
ABSTRACT
In today's world, Software projects are very complex with thousands of components and with a high degree of relationships.
These intangible components are hard to manage and trace without automated tools. Configuration management is one of the
disciplines that can deals with such complex systems. This paper addresses a knowledge base framework to incorporate
configuration management processes. The framework aims to records activities associated with software projects as well as
their relationships and accountability. Managing components of the software of an organization is essential when it is faced
with license audits, reconciliation, reclamation, and deployment. By using the software management system, organizations will
be able to manage all points from any single location. Managing Software Resources is essential to understand what
applications are installed in the organizations' environment, for both license compliance and for tracking blacklisted or other
software. This article provides useful information for making the process successful and enabling users to get accurate
information concerning what is installed in the environment.
The framework enables a number of automatic controls to explore data, components, and associated items of information.
Such controls include version control, document control, change management, build management, and release control. These
controls act as guards against any misuse of the software project properties. It acts against any error occurrence, threats, and
irregularities that might lead to inconsistencies. The framework supports a set of policies that monitors and controls final
software product and its components. It determines locations of components, how component be assembled in order to produce
a software product. The framework enables developers to monitor the visibility over products, components, relationships and
linkages. It also checks vulnerabilities and whether the development of the software product complies with the preset standards,
guidelines, and policies.
Keywords: Knowledge base, Configuration Management, Audit, Version control, Build management, Release control,
Configuration identification.
1.INTRODUCTION
The information processing power is increasing and becoming integral parts of our lives. The driving force behind
these advancements is computer software. Computer software is becoming more and more complex and the amount of
software being developed each year is increasing at an exponential rate [1]. Software is widely being used in our daily
life from the mission-critical applications through controlling satellite operations, ballistic missiles, and managing the
functioning of hospitals and banks, to handling airlines, manufacturing activities, and performing tasks like operating
door-locking systems or desktop publishing.
One well established constant fact about software is change. The software system that is perfectly developed, has met
all requirements, and has passed all audits and reviews will also change. Lehman [2] claimed that even if the system
were built in complete conformance to the requirement, it would still evolve and it needs to adapt changes because it is
introduced into an environment which the system is subject to a change. Therefore a mechanism for managing the
change and controlling is required. Software configuration management is one of such mechanism.
A well-designed and properly implemented SCM system offers many benefits to developers, organizations, and
customers including [3]:
Improve organizational competitiveness,
Better customer service and improve customer goodwill,
Better return on investments,
Page 1


ISSN 2321-5976
Improve management control over software developments activities,

Improve software development productivity,
Easier handling of software complexity and improve security,
Higher software reuse and lower software maintenance costs,
Better quality assurance,
Reduction in percentage of defects and bugs, and faster problem identification and bug fixes,
Process-dependent development rather than person dependent development,
Assurance that the correct system is built.
Software configuration management (SCM) is the process of tracking, controlling, and monitoring changes in the
software products. CM deals with items visibility, accuracy, and timely information. The CM process tracks the current
and historical states of all related services and provides such information to authorized stakeholders. This visibility is a
key to the effective and efficient for planning and implementation changes. This visibility reduces risks, irregularities to
the software relating to impaired availability, security, and performance. This visibility is achieved through the related
activities recorded in the knowledge base framework. Because large and complex service topologies are hard to manage
using plain configuration management without other automation tools [3].
SCM can determine what was changed and who changed it, if unexpected irregularities happened. SCM can determine
how to replicate it across many hosts, whenever a configuration is working well. This can be achieved through the use
of revision control and the establishment of baselines. SCM is also expanded as source configuration management
process and software change and configuration management.
The word configuration is generally understood to cover changes typically made by a system administrator. Software
Configuration Management is the process that defines how to control and manage the changes [4]. Software
Configuration Management is an ability to control and manage change in a software project. Changes are inherent and
ongoing in any software project. The ability to track control such changes in a proper manner form a good software
project. Software Configuration Management tries to bridge this gap by defining a process for the change control.
Configuration management (CM) is a systems engineering process for establishing and maintaining consistency of a
product's performance, functional and physical attributes with its requirements, design and operational information
throughout its life [5, 6]. The CM process is widely used by military engineering organizations to manage complex
systems, such as weapon systems, vehicles, and information systems. Outside the military, the CM process is also used
with IT service management as defined by ITIL, resp. ISO/IEC 20000, and with other domain models in the civil
engineering and other industrial engineering segments such as roads, bridges, canals, dams, and buildings [7, 8, 9].
CM, when applied over the life cycle of a system, provides visibility and control of its performance, functional and
physical attributes. CM verifies that a system performs as intended, and is identified and documented in sufficient
detail to support its projected life cycle. The CM process facilitates orderly management of system information and
system changes for such beneficial purposes as to revise capability; improve performance, reliability, or maintainability;
extend life; reduce cost; reduce risk and liability; or correct defects. The relatively minimal cost of implementing CM is
returned many folds in cost avoidance. The lack of CM, or its ineffectual implementation, can be very expensive and
sometimes can have such catastrophic consequences such as failure of equipment or loss of life [10].
A component is a subsystem of a piece of equipment (i.e. engine, transmission, differential). A subsystem is a part that
is used on a piece of equipment until it wears out, and then is thrown away (i.e. brake pads, oil filters, etc.). Both
components and subsystems are often viewed as unbreakable things that don't need to be monitored. we believe that
those unbreakable things can end up affecting maintenance and profits in big ways
Page 2


ISSN 2321-5976
CM emphasizes the functional relation between parts, subsystems, and systems for effectively controlling system
change. It helps to verify that proposed changes are systematically considered to minimize adverse effects. Changes to
the system are proposed, evaluated, and implemented using a standardized, systematic approach that ensures
consistency, and proposed changes are evaluated in terms of their anticipated impact on the entire system. CM verifies
that changes are carried out as prescribed and that documentation of items and systems reflects their true configuration.
A complete CM program includes provisions for the storing, tracking, and updating of all system information on a
component, subsystem, and system basis [11].
A structured CM program ensures that documentation (e.g., requirements, design, test, and acceptance documentation)
for items is accurate and consistent with the actual physical design of the item. In many cases, without CM, the
documentation exists but is not consistent with the item itself. For this reason, engineers, contractors, and management
are frequently forced to develop documentation reflecting the actual status of the item before they can proceed with a
change. This reverse engineering process is wasteful in terms of human and other resources and can be minimized or
eliminated using CM.
A review of the configuration management process should focus on, and alter as required, the process design, including
inputs and outputs, workflows, controls, roles and responsibilities, data models, reporting and opportunities for process
automation [12].
This paper is structured as follows: section 2 provides some background on literature reviews. In section 3, the
theoretical and functional models of software configuration management are described. The knowledge structure is
introduced in section 4. Information assurance is discussed in section 5 while Section 6 explores Operating System
Configuration Management. Some standards and guidelines for software configuration management are listed and
discussed in section 7. In section 8, software construction is explained. Finally, conclusions and future works are
summarized in section 9.
2.Literature Review
The history of software configuration management (SCM) can be traced back to early1950s, when Configuration
Management, originally for hardware development and production control, was being applied to software development.
Early software had a physical footprint, such as cards, tapes, and other media. The first software configuration
management was a manual operation [13]. With the advances in computer languages and complexity, software
engineering, involving configuration management and other methods, became a major concern due to issues like
schedule, budget, and quality. Practical lessons, over the years, had led to the definition, and establishment, of
procedures and tools [14]. . With the growing use of computers, systems emerged that handled a broader scope,
including requirements management, design alternatives, quality control, and more; later tools followed the guidelines
of organizations, such as the Capability Maturity Model of the Software Engineering Institute [15].
In the 80s, the first systems were built in house and focused closely on file control. Most of them were built as a set of
UNIX scripts over RCS (a simple version control tool) and Make (for derived object control). From this period we can
mention DSEE [16], the only serious commercial product, which introduced the system model concept, an Architecture
Description Language (ADL) ancestor; NSE [17] which introduced workspace and cooperative work control; Adele
which introduced a specialized product model with automatic configuration building [18], and Aides de Camp (now
TRUE software) which introduced the change set (see later).
Configuration Management (CM) as a formal management approach was developed as a technical management
discipline for hardware material itemsand it is now a standard practice in virtually every industry. The CM process
became its own technical discipline sometime in the late 1960s when the DoD developed a series of military
standards called the "480 series" (i.e., MIL-STD-480 and MIL-STD-481) that were subsequently issued in the 1970s. In
1991, the "480 series" was consolidated into a single standard known as the MILSTD973 that was then replaced by
MILHDBK61 pursuant to a general DoD goal that reduced the number of military standards in favor of
industry technical standards supported by Standards Developing Organizations (SDO) [24].
The first real SCM products appeared in the early 90s. These systems are much better. They often use a relational
database but still rely on file control, they provide workspace support, but no or built-in process support. This
generation included Clear Case [19] (DSEE successor) which introduced the virtual file system and Continuus [20, 21]
which introduced, with Adele, explicit process support [22]. Continuus and Clear Case are currently the market leaders.
In the second half of the 90s, process support was added and most products matured. This period saw the consecration
Page 3


ISSN 2321-5976
of SCM, as a mature, reliable and essential technology for successful software development; the SCM market was over
$1 billion sales in 1998 [23]. Many observers consider SCM as one of the very few Software Engineering successes.
Software Configuration management is widely used by many military organizations to manage the technical aspects of
any complex systems, such as weapon systems, vehicles, and information systems. The discipline combines the
capability aspects that these systems provide an organization with the issues of management of change to these systems
over time. Outside of the military, CM is appropriate to a wide range of fields and industry and commercial sectors
[51].
This marked the beginning of what has now evolved into the most widely distributed and accepted standard on CM,
ANSIEIA6491998 [25]. Now widely adopted by numerous organizations and agencies, the CM discipline's concepts
include systems engineering (SE), integrated logistics support (ILS), Capability Maturity Model Integration (CMMI),
ISO
9000, Prince2 project
management
methodology, COBIT, Information
Technology
Infrastructure
Library (ITIL), product lifecycle management, and application lifecycle management. Many of these functions and
models have redefined CM from its traditional holistic approach to technical management. Some treat CM as being
similar to a librarian activity, and break out change control or change management as a separate or stand alone
discipline.
3.Software Configuration Management Model

CM is the practice of handling changes systematically so that a system maintains its integrity over time. CM
implements the policies, procedures, techniques, and tools that are required to manage, evaluate proposed changes,
track the status of changes, and to maintain an inventory of system and support documents as the system changes. CM
programs and plans provide technical and administrative direction to the development and implementation of the
procedures, functions, services, tools, processes, and resources required to successfully develop and support a complex
system. During system development, CM allows program management to track requirements throughout the life cycle
through acceptance and operations and maintenance. As changes are inevitably made to the requirements and design,
they must be approved and documented, creating an accurate record of the system status. Ideally the CM process is
applied throughout the system lifecycle.
The CM process for both hardware and software configuration an item comprises a number of distinct areas as
established in the MILHDBK61A and ANSI/EIA-649. These areas are carried out as policies and procedures for
establishing baselines and performing a standard change management process. These are discussed in the following
sub-sections.
3.1 SCM Planning and Management
A formal document and plan to guide the CM program that includes items such as: Personnel; Responsibilities and
Resources; Training requirements; Administrative meeting guidelines, including a definition of procedures and tools;
baselining processes; Configuration control and Configuration status accounting; Naming conventions; Audits and
Reviews; and Subcontractor/Vendor SCM requirements.
3.2 Configuration Identification (CI)
Configuration identification consists of setting and maintaining baselines, which define the system or subsystem
architecture, components, and any developments at any point in time. It is the basis by which changes to any part of an
information system are identified, documented, and later tracked through design, development, testing, and final
delivery. It is the process that deals with identifying configurations, configuration items and baselines. It manages and
enforces company's process of resolving issues. CI incrementally establishes and maintains the definitive current basis
for Configuration Status Accounting (CSA) of a system and its configuration items (CIs) throughout their lifecycle
(development, production, deployment, and operational support) until disposal.
When the CIs are identified, acquired, and baselined, they come under the preview of configuration control, and formal
change control procedures come into effect. This means that once the CI is brought into SCM system, the changes
cannot be done unless they pass through a formal change management process.
3.3 Configuration Control
Configuration control includes the evaluation of change requests and change proposals, and their subsequent approval
or disapproval. It is the process of controlling modifications to the system's design, hardware, firmware, software, and
Page 4


ISSN 2321-5976
documentation. It is an activity that Implements a controlled change process. This is usually achieved by setting up
a change control board whose primary function is to approve or reject change requests that are sent against any
baseline.
One important aspect of the control process is that it provides adequate analysis of changes in terms of impact to system
functionality, interfaces, utility, cost, schedule, and contractual requirements. Each change should be analyzed for
impact on software, safety, reliability, maintainability, transportability, and efficiency. Configuration control takes
place at the conclusion of development with formal software baselines prior to validation.
3.4 Configuration Status Accounting
Configuration status accounting includes the process of recording and reporting configuration item descriptions (e.g.,
hardware, software, firmware, etc.) and all departures from the baseline during design and production. In case of
suspected problems, the verification of baseline configuration and approved modifications can be quickly determined. It
is a process that records and reports all the necessary information on the status of the development piece of work. It
reports Up-to-the-minute project information and status to team members everywhere to foster collaboration.
3.5 Configuration Verification and Audit
An independent review of hardware and software for the purpose of assessing compliance with established performance
requirements, commercial and appropriate military standards, and functional, allocated, and product baselines.
Configuration audits verify the system and subsystem configuration documentation complies with their functional and
physical performance characteristics before acceptance into an architectural baseline. This control takes place at the
conclusion of specification and then continues throughout with traceability of documents to software baselines.
3.6 Build management
Build management is a process that manages the process and tools used for builds. Build Management is the process of
assembling all the components of a software application into an installable software product. This process usually
includes the following steps [26]:
Preparing the build environment,
Gathering source code,
Labeling the source code,
Compilation or Interpreting of the code,
Creation of build logs and bill of materials,
creation of installation packages,
updating of build statuses, and
Sending build notifications.
In order to increase efficiencies and improve quality of the software, development team should focus the software build
process. It is frustrating to implement a complete testing process or purchase expensive development tools if the
software cannot be reliably built, deployed, and deliver to a run-time system. For large software that involves multiple
teams, remote development teams, out-sourced development functions or all of the above, proper efforts for build
management is crucial for success.
3.7 Process management
It is a method that ensures adherence to the organization's development process. It verifies the completeness and
correctness of configuration items. Process management is the application of knowledge, skills, tools, techniques, and
systems to define, visualize, measure, control, report and improve processes with the goal to profitably
meet customer requirements. It can be differentiated from program management in which program management is
Page 5


ISSN 2321-5976
concerned with managing a group of inter-dependent projects. From another viewpoint, process management includes
program management. In project management, process management is the use of a repeatable process to improve the
outcome of the project [27].
Process management sees processes as important assets of an organization that must be understood, managed, and
developed to announce value-added products and services to clients or customers. This approach closely resembles
other total quality management or continual improvement process methodologies and business process management
proponents also claim that this approach can be supported, or enabled, through technology. As such, many business
process management articles and scholars frequently discuss it from one of two viewpoints: people and/or technology
[28].
3.8 Environment management
It is a program manages the software and hardware that are hosting the system. It is administrative functions that
develop, implement, and monitor environmental policy of an organization [29] it refers to the management of an
organization's environmental programs in a comprehensive, systematic, planned and documented manner. It includes
the organizational structure, planning and resources for developing, implementing and maintaining policy
for environment management.
More formally, environment management system is a system and database which integrates procedures and processes
for training of personnel, monitoring, summarizing, and reporting of specialized environmental performance
information to internal and external stakeholders of an organization [30]. The most widely used standard on which an
EMS is based is International Organization for Standardization (ISO) 14001. An environmental management
information system (EMIS) is an information technology solution for tracking environmental data for an organization
as part of their overall environmental management system [31].
3.9 Teamwork
It is a team that facilitates the interactions related to the process. It shows how proven SCM practices can foster a
healthy team-oriented culture that produces better software. It shows that workflow, when properly managed, can avert
delays, morale problems, and cost overruns. A patterns approach (proven solutions to recurring problems) is outlined so
that SCM can be easily applied and successfully leveraged in small to medium sized organizations. The patterns are
presented with an emphasis on practicality. The results speak for themselves: improved processes and a motivated
workforce that synergize to produce better quality software [32].
3.10 Defect tracking
It is a tool that makes sure every defect has traceability back to the source. It is intended to increase productivity,
improve products, improve customer satisfaction, and sometimes simply by ensuring each fix of an important bug
makes it into the next release. Tracking reports bugs, defects, business issues, enhancement requests, etc and
automatic routing and notification to get issues resolved.
It is the process to ensure that configurations contain all their intended parts and are sound with respect to their
specifying documents, including requirements, architectural specifications and user manuals. It is a guard against
irregularities that could affect the status of a configuration item. It reports history and audit trail.
From the above five concepts, we come up with the conclusions that define a software configuration management as a
discipline that manages the evolution of complex software systems [33]. It is also defined as the process of controlling
and monitoring change to work products [34].
4 Knowledge Base structure

Knowledge-based configuration, of complex products and services, has a long history as an artificial
intelligence application area. Configuration can be defined as a special case of design activity, where the artifact being
configured is assembled from instances of a fixed set of well-defined component types which can be composed
according to a set of constraints. These constraints can be technical restrictions, restrictions related to economic
aspects, and conditions related to production processes. The result of a configuration process is a product configuration,
Page 6


ISSN 2321-5976
concrete configuration, that is; a list of instances and in some cases also connections between these instances. Examples
of such configurations are computers to be delivered or financial service portfolio offers [35, 36].
Configuration systems or also referred to as configurators or mass customization toolkits are one of the most
successfully applied Artificial Intelligence technologies. Examples are the automotive industry, the telecommunication
industry, the computer industry, and power electric transformers. Starting with rule-based approaches such as
R1/XCON, model-based representations of knowledge (in contrast to rule-based representations) have been developed
which strictly separate product domain knowledge from the problem solving one. Examples thereof are the constraint
satisfaction problem, the Boolean satisfiability problem, and different answer set programming (ASP) representations.
There are two commonly cited conceptualizations of configuration knowledge. The most important concepts in these
are components, ports, resources and functions. This separation of product domain knowledge and problem solving
knowledge increased the effectiveness of configuration application development and maintenance, [37] since changes
in the product domain knowledge do not affect search strategies and vice versa.
Configurators are also often considered as "open innovation toolkits", i.e., tools which support customers in the product
identification phase. In this context customers are innovators who articulate their requirements leading to new
innovative products. Mass Confusion [38] the overwhelming of customers by a large number of possible solution
alternatives (choices), is a phenomenon which often comes with the application of configuration technologies. This
phenomenon motivated the creation of personalized configuration environments taking into account customers'
knowledge and preferences.
The ability to use an SCM system to recursively define and manage the subsystems that make up a software system
enables y to define and control very complex development efforts and to designate subsystems as projects that are
independently controlled, managed, and released and that can become candidates for reuse in other projects. Figure (1)
below illustrates the hierarchical nature of subsystem.
Figure 1: knowledge base systems, subsystems, and components

Core configuration, i.e., guiding the user and checking the consistency of user requirements with the knowledge base,
solution presentation and translation of configuration results into bill of materials (BOM) are major tasks to be
supported by a configurator [39]. Configuration knowledge bases are often built using proprietary languages. In most
cases knowledge bases are developed by knowledge engineers who elicit product, marketing and sales knowledge from
domain experts. Configuration knowledge bases are composed of a formal description of the structure of the product
and further constraints restricting the possible feature and component combinations.
Recently, knowledge based configuration has been extended to service and software configuration. Modeling software
configuration has been based on two main approaches: feature modeling and component-connectors.
One of the main methods that prevent defects is the creation of a knowledge base that contains the classified and
categorized defects. The knowledge base should have search facilities where one can search for irregularities by such
aspects as category, phase of origin, cause, and severity. Details of irregularity such as project, the defect of the
description, the cause, and the solution should be deduced from the knowledge base [3].
The knowledge base is tremendously valuable because it serves as a road map and guidebook for analysts, designers,
programmers, people who do the testing and maintenance. For analysts, designers, and programmers, it serves as a
guide, telling them, what to do, what to avoid, what mistakes can occur. The people who do the testing create better test
cases and test data, if they know about the defects that escaped testing and how that happened, people who do the
problem fixing will find similar problems and can see how they were fixed. This information is very useful for people
who manage the helpdesk and for the technical support team. In addition, as new problem get added to the system, it
Page 7

ISSN 2321-5976
will become more comprehensive and its usefulness will increase. Browse the knowledge base before starting the
analysis, design, or development, to be forewarned of the problems that could occur.
The traditional software configuration management (SCM) process is looked upon by practitioners as the best solution
to handling changes in software projects. It identifies the functional and physical attributes of software at various points
in time, and performs systematic control of changes to the identified attributes for the purpose of maintaining software
integrity and traceability throughout the software development life cycle.
A sample of change analysis document may looks as figure (2) below:
Figure 2: knowledge base for change analysis document

The following facts should also be incorporated into the knowledge base including as shown in figure (3):
project (Name, No, Change-request, Priority, Date).
Item (No, Name, DescriptionElementsforChangeNeed).
Descriptionofchange( No, DescriptionRequired).
Accountability( No, Disposition, E-signature, Date).
Disposition (No, ReviewBoard, ReviewPerson,DateofVerification ).
Figure 3: facts in a knowledge base structure

A change request form that should be incorporated into the knowledge base as in figure (4) below:
changerequest ( CrNo, AnalysisDocumentNo, Type, ItemtobeChanged).
Classification ( CrNo, Enhancement, BugFixing, Others).
Priority ( Urgent, AsSoonAsPossible,Dessirable).
Changestatus( CrNo, Status, ByWhom, Remarks, Date).
Status(Initiated, Received, Analyzed, Action, assigned, CheckOut, ModifiedAndTested,
Reviewed, Approved, CheckIn, BaseLined).
Action(CrNo, Approved, Rejected, Referred, Remarks).
Page 8


ISSN 2321-5976
Type ( CrNo, Project, System).
Figure 4: knowledge base change requests

The SCM process further defines the need to trace changes, and the ability to verify that the final delivered software has
all of the planned enhancements that are supposed to be included in the release. It identifies four procedures that must
be defined for each software project to ensure that a sound SCM process is implemented. They are: configuration
identification, configuration control, configuration status accounting, and configuration audits. These terms and
definitions change from standard to standard, but are essentially the same.
Configuration identification is the process of identifying the attributes that define every aspect of a configuration
item. A configuration item is a product (hardware and/or software) that has an end-user purpose. These attributes
are recorded in configuration documentation and baselined. Baselining an attribute forces formal configuration
change control processes to be effected in the event that these attributes are changed.
Configuration change control is a set of processes and approval stages required to change a configuration item's
attributes and to re-baseline them.
Configuration status accounting is the ability to record and report on the configuration baselines associated with
each configuration item at any moment of time.
Configuration audits are broken into functional and physical configuration audits. They occur either at delivery or
at the moment of effecting the change. A functional configuration audit ensures that functional and performance
attributes of a configuration item are achieved, while a physical configuration audit ensures that a configuration
item is installed in accordance with the requirements of its detailed design documentation.
The need for an SCM process came when there are many developers and many versions of the software. Suffice to say
that in a complex scenario where bug fixing should happen on multiple productions of systems and enhancements must
be continued on the main code base, SCM acts as the backbone which can make this happen. The SCM processes
further defines the need to trace the changes and the ability to verify that the final delivered software has all the
planned enhancements that are supposed to be part of the release.
The traditional SCM identifies some procedures that must be defined for each software project to ensure that a good
SCM process is implemented [3]. Software is usually made up of several programs. Each program has its related
documentation and data can be called as a configurable item(CI). The number of CI in any software project that
makes up a CI is a decision made of the project. The end product is made up of a bunches of CIs.
The status of the CIs at a given point in time is called as a baseline. The baseline serves as a reference point in the
software development life cycle. Each new baseline is the sum total of an older baseline plus a series of approved
changes made on the CIs. The process of deciding, coordinating the approved changes for the proposed CIs and
implementing all the changes on the appropriate baseline is called Configuration control. It should be kept in mind that
configuration controls only address the process after changes are approved. The act of evaluating and approving
changes to the software comes under the purview of an entirely different process is called change control.
Configuration status accounting is the keeping process of each release. This procedure involves tracking what all is in
each version of software and the changes that lead to this version. Configuration status accounting keeps a record of all
the changes made to the previous baseline to reach of the new baseline.
Practical experience has shown that the following best practices are essential to successful software development. This
can be formulated as fact in the knowledge base as in figure (5) below:
Page 9


ISSN 2321-5976
bestpractice( Identify and store artifacts in a secure repository, Control and audit changes to
artifacts, Organize versioned artifacts into versioned components, Organize versioned
components and subsystems into versioned subsystems, Create baselines at project milestones,
Record and track requests for change, Organize and integrate consistent sets of versions using
activities, Maintain stable and consistent workspaces, Support concurrent changes to artifacts
and components, Integrate early and often, Ensure reproducibility of software builds).
Figure 5: best practice properties as a knowledge base fact
Configuration identification should include both artifacts used to manage and design a system, such as project plans
and design models, and those that instantiate the system design itself, such as source files, libraries, and executables
and the mechanisms used to build them. Configuration identification is an element of configuration management,
consisting of selecting the configuration items for a system and recording their functional and physical characteristics
in technical documentation. Figure (6) a sample of items identification.
Technicaldocument( CiNo, FunctionalCharcteristic, PhysicalCharacteristic).
Identificationcontrol( CiNo, WhatChange, Who, Why, Locations, Date, E-signature).
Audit(CiNo, ErrorTypes, ProcrdureForCrrection, Approved, Date, E-signature).
Figure 6: items identification
Configuration control impact can be formulated as shown in figure (7) below:
Controlprocessanalysisimpact( Functionalit, Interfaces, Utility, Cost, Schedule,

Requirements).
Figure 7: control process analysis impact
Organizing artifacts and locating them are not enough. Fault-tolerant, scalable, distributable, and replicable
repositories are required to maintain high system performance. In order to optimize for development productivity while
eliminating known security risk, control is implemented to restrict changes while audit information enable one to make
correction if errors are introduced.
5.Information Assurance
For information assurance, CM can be defined as the management of security features and assurances through control
of changes made to hardware, software, firmware, documentation, test, test fixtures, and test documentation throughout
the life cycle of an information system [40]. CM for information assurance, sometimes referred to
as secure configuration management, relies upon performance, functional, and physical attributes of IT platforms and
products and their environments to determine the appropriate security features and assurances that are used to measure
a system configuration state. For example, configuration requirements may be different for a network firewall that
functions as part of an organization's Internet boundary versus one that functions as an internal local network firewall.
Page 10


ISSN 2321-5976
Configuration management is used to maintain an understanding of the status of complex assets with a view to
maintaining the highest level of serviceability for the lowest cost. Specifically, it aims to ensure that operations are not
disrupted due to the asset (or parts of the asset) overrunning limits of planned lifespan or below quality levels.
In the military, this type of activity is often classed as "mission readiness", and seeks to define which assets are
available and for which type of mission; a classic example is whether aircraft on board an aircraft carrier are equipped
with bombs for ground support or missiles for defense.
Software configuration management (SCM) is a software engineering discipline consisting of standard processes and
techniques often used by organizations to manage the changes introduced to its software products. SCM helps in
identifying individual elements and configurations, tracking changes, and version selection, control, and baselining.
SCM is also known as software control management. SCM aims to control changes introduced to large complex
software systems through reliable version selection and version control.
SCM defines a mechanism to deal with different technical difficulties of a project plan. In a software organization,
effective implementation of software configuration management can improve productivity by increased coordination
among the programmers in a team. SCM helps to eliminate the confusion often caused by miscommunication among
team members. The SCM system controls the basic components such as software objects, program code, test data, test
output, design documents, and user manuals.
The SCM system has the following advantages:
Reduced redundant work.
Effective management of simultaneous updates.
Avoids configuration-related problems.
Facilitates team coordination.
Helps in building management; managing tools used in builds.
Defect tracking: It ensures that every defect has traceability back to its source.
For information assurance to be more effective, reviews and audits should verify the physical existence of CIs. They
check that CIs are correctly recorded and parts are listed. Configuration authentication (CA) should also be
incorporated in the framework. CA is defined as a process of assuring that a new baseline has all the planned and
approved changes incorporated. The process involves verifying that all the functional aspects of the software is
completed and also the completeness of the delivery in terms of the right programs, documentation and data are being
delivered. The configuration authentication is an audit performed on the delivery before it is opened to the entire world.
6.Operating System Configuration Management

Configuration management can be used to maintain OS configuration files [41]. systems include, for example,
CFEngine, Bcfg2, Puppet, and Chef. A theory of configuration maintenance was worked out by a number of researchers
[42, 43, 44). Understanding the "as is" state of an asset and its major components is an essential element in preventive
maintenance as used in maintenance, repair, and overhaul and enterprise asset management systems.
Complex assets such as aircraft, ships, industrial machinery etc. depend on many different components being
serviceable. This serviceability is often defined in terms of the amount of usage the component has had since it was
new, since fitted, since repaired, the amount of use it has had over its life and several other limiting factors.
Understanding how near the end of their life each of these components is has been a major undertaking involving labor
intensive record keeping until recent developments in software.
Many types of component use electronic sensors to capture data which provides live condition monitoring. This data is
analyzed on board or at a remote location by computer to evaluate its current serviceability and increasingly its likely
future state using algorithms which predict potential future failures based on previous examples of failure through field
experience and modeling. This is the basis for "predictive maintenance".
Page 11


ISSN 2321-5976
Availability of accurate and timely data is essential in order for CM to provide operational value and a lack of this can
often be a limiting factor. Capturing and disseminating the operating data to the various support organizations is
becoming an industry in itself.
The consumers of this data have grown more numerous and complex with the growth of programs offered by original
equipment manufacturers (OEMs). These are designed to offer operators guaranteed availability and make the picture
more complex with the operator managing the asset but the OEM taking on the liability to ensure its serviceability. In
such a situation, individual components within an asset may communicate directly to an analysis center provided by the
OEM or an independent analyst.
7.Standards and Guidelines

Software Institutions have developed policies and procedures for software configuration management that is made
public and forms part of their strategic management. These policies and procedures are strategic tools and guidelines to
help companies tackle some of the most demanding challenges of modern business technology. They ensure that
business operations are as efficient as possible, increase productivity and help companies access new markets.
As outlined in previous sections, SCM is intended to eliminate the confusion and error brought about by the existence
of different versions of artifacts. Artifact change is a fact of life: plan for it or plan to be overwhelmed by it. Changes
are made to correct errors, provide enhancements, or simply reflect the evolutionary refinement of product definition.
SCM is about keeping the inevitable change under control. Without a well-enforced CM process, different team
members (possibly at different sites) can use different versions of artifacts unintentionally; individuals can create
versions without the proper authority; and the wrong version of an artifact can be used inadvertently. Successful SCM
requires a well-defined and institutionalized set of policies and standards that clearly define [45.]:
the set of artifacts (configuration items) under the jurisdiction of SCM
how artifacts are named
how artifacts enter and leave the controlled set
how an artifact under SCM is allowed to change
how different versions of an artifact under SCM are made available and under what conditions each one can be
used
how SCM tools are used to enable and enforce SCM
Internal stakeholders have developed and implement the policies and procedure through appropriate structures and
processes, while involving external stakeholders. These policies and standards are known as standards and guidelines.
They are the main pillars of a coherent institutional software configuration management that forms a cycle for
continuous improvement and contributes to the accountability of the institution. It supports the development of
configuration management culture in which internal stakeholders assume responsibility for quality and engage in
quality coherence at all levels of the institution. These policies and standards are documented in a SCM plan that
informs everyone in the organization just how SCM is carried out. Standards have a formal status and are publicly
available and for their valuable importance, a list of them is outlined below:
ANSI/EIA-649-1998 National Consensus Standard for Configuration Management
EIA-649-A 2004 National Consensus Standard for Configuration Management
TechAmerica/ANSI EIA-649-B 2011 Configuration Management Standard
ISO 10007:2003 Quality management systems - Guidelines for configuration management
Federal Standard 1037C
GEIA Standard 836-2002 Configuration Management Data Exchange and Interoperability
IEEE 829Standard for Software Test Documentation
MIL-STD-973 Configuration Management (cancelled on 20 September 2000)
Page 12


ISSN 2321-5976
STANAG 4159 NATO Materiel Configuration Management Policy and Procedures for Multinational Joint
Projects
STANAG 4427 Introduction of Allied Configuration Management Publications (ACMPs)
ACMP 2100 (DRAFT) NATO Contractual Configuration Management Requirements
CMMI CMMI for Development, Version 1.2 CONFIGURATION MANAGEMENT
CMII-100E CMII Standard for Enterprise Configuration Management
Extended List of Configuration Management & Related Standards
Guidelines have a formal status and are publicly available and for their valuable importance for software configuration
management stakeholders, a list of them is included such as:
828-2012 Currently active IEEE Standard which supersedes/supports older ones.

MIL-HDBK-61A Configuration Management Guidance 7 February 2001
10007 Quality management - Guidelines for configuration management
ACMP 2009 (DRAFT) NATO Guidance on Configuration Management
GEIA-HB-649 - Implementation Guide for Configuration Management
ANSI/EIA-649-1998 National Consensus Standard for Configuration Management
EIA-836 Consensus Standard for Configuration Management Data Exchange and Interoperability
ANSI/EIA-632-1998 Processes for Engineering a System
MIL-STD-3046 (ARMY) Interim Standard on Configuration Management, 6 March 2013.
Standards and guidelines are the backbone of modern society, ensuring the safety and quality of products and services,
facilitating international trade and improving the environment in which we live in. Conformity to Standards and
guidelines, in general, helps reassure stakeholders of that the software products, systems and organizations are safe,
reliable and good for the environment. Numerous studies have shown that standards and guidelines boost business and
economies. In the UK, for example, standards account for an $8.2bn annual growth in GDP, while in Canada, the use
of standards has injected over $91bn into the economy since 1981 [46].
8.SOFTWARE CONSTRUCTION FRAMEWORK

Software construction is a process that follows certain procedures and regulations in order to construct (build) a
component, subsystem, or a complete software system or product. This construction is not a straight forward operation;
it has a number of challenges that need to be aware off. Rapid product development and frequent changes to source
code demands frequent check-ins, it is important that the developer has some confidence that the code will successfully
construct and pass unit testing before one can integrate it into the main code line. By utilizing private check-ins at an
isolated area off the main line (e.g., a private branch) and constructing the code in the private sandbox before checking
it into the main code line, the developer can test and debug the code locally, and only after passing the construct and
unit tests can the code be integrated into the main code line. Integration build is likely to fail without incorporating it
into the software configuration framework.
In todays software organizations that are adapting to agile methodologies, product features are usually broken up into
the smallest size tasks possible so that each task can be tracked, integrated, and debugged. This methodology of task
oriented development will enable the software construction o be done properly with maximum utilization of resources.
One of the goals of SCM is to enable an organization to perform task-oriented development that includes providing
visibility into changes made for each task, supporting the ability to work by task instead of by individual file, to merge
changes from one configuration to another, and to reverting changes for a task if needed [53].
Page 13


ISSN 2321-5976
Although a private construct prior to integrating changes reduces the chance of a broken construct, there are still cases
when an integration construct may fail. For example, if two developers commit changes at about the same time, it is
possible that each one did not test his individual changes with those of the other. In the event of a construct failure, it is
the function of SCM to be able to revert to the last good construct so that other developers have a clean configuration of
component (code) to use for their own work. Reverting to the last good configuration allows one developer to fix the
broken construct while the rest of the team can continue working on their tasks and verifying the work with their own
private constructs.
Having all development work from the main line often causes chaos. This can be mitigated by use of a development
hierarchy. A development hierarchy is simply a hierarchical representation of the dependencies between groups that
includes process steps such as integration, quality assurance, and code reviews. A separate code configuration is used
for each stage in the hierarchy. It is a natural extension of private branching. As a change is pushed from one stage to
the next, the particular change as well as the system as a whole reaches a higher level of maturity. Continuous multistage integration can be employed to automatically build and test changes as they are pushed to each stage.
The function of SCM is to support the creation of a hierarchy, give visibility into the changes at each stage, and enable
straightforward merging between stages. Utilizing a staging hierarchy along with private versioning gives the added
benefit of more code stability at each step up the hierarchy. Generally software requirements are driven by the business
and can be changed throughout the SDLC. For this reason, it is the goal of SCM system to be able to identify the
changes made for a particular feature and remove the changes, from one iteration and retarget them to the next. For
this reason, code must periodically be re-factored to make it easier to understand and reusable for other features.
With todays advance technology, it is possible to utilize specialized talents that are even geographically distributed.
Due to this distributed nature of software development organizations [52], it is not always possible to assemble crossfunctional teams without involving team members at more than one location. For these scenarios, it is important that
the SCM provides a central repository so that members of distributed teams can work together.
One major function of SCM is to enable continuous integration of changes. Each developer should submit changes as
soon as a task is complete. Continuous integration construct can be used to poll the code repository periodically and, if
any changes exist, construct the new configuration. Equally important to this concept is the immediate reporting of
construct status. If a construct breaks or any of the unit tests fail, the developer who recently committed the changes
must fix the code right away.
So, system construction is the process of combining source components into components or subsystems which execute
on a particular target configuration. The system or parts of it have to be rebuilt after every change in design,
specifications, and ultimately source. The following queries in figure (8) can use the knowledge base framework to
issue:
?:- Have all components C1, C2,, Cn, included in the build structure.
?:- Do components have the proper versions.
?:- List all component versions and show the current applicable ones that will be used
in software construction.
?:- Are all required ancillary data files and documents available for the target
machine.
?:- Are compiler and linker tools available and do have the right versions.
Figure 8: knowledge base queries
The knowledge base framework has capabilities to identify components and can choose the right versions, right
locations, and other related issues and processes. It incorporate built management facility similar to the building tool
'MAKE' the UNIX operating system. This tool has the capability of executing multiple platforms from multiple
Page 14


ISSN 2321-5976
environments. The proposed knowledge base framework contains Software Build Tools which is a collection of tools
used to create automated software builds [54]. This automatic configuration builders save time, shorten build cycles,
and eliminate build errors by providing repeatable automated builds of the software development projects. The
knowledge base framework incorporates building tools that work closely with versions management tools and construct
the correct versions of developed objects from libraries [55].
Dimoji et al. [47] outlined that more recently configuration management has been applied to large construction projects
which can often be very complex and have a huge amount of details and changes that need to be documented.
Construction agencies such as the Federal Highway Administration have used configuration management for their
infrastructure projects. There are construction-based configuration management tools that aim to document change
orders and RFIs in order to ensure a project stays on schedule and on budget. These programs can also store
information to aid in the maintenance and modification of the infrastructure when it is completed. Figure (9) shows the
main scheme of controlling software components [47].
Figure 9: shows top level configuration management activity model [47]
Page 15


ISSN 2321-5976
One such application, ccsNet, was tested in a case study funded by the Federal Transportation Administration (FTA) in
which the efficacy of configuration management was measured through comparing the approximately 80% complete
construction of the Los Angeles County Metropolitan Transit Agency (LACMTA) 1st and 2nd segments of the Red
Line, a $5.3 billion rail construction project [48, 49]. This study yielded results indicating a benefit to using
configuration management on projects of this nature [50].
9.Conclusions
The paper proposed a knowledge base system for software configuration management as mechanisms used to control
the evolution of a software project and to browse its activities. In order to enable best practices, the paper specifically
discussed software-development components and how they are enabled by a good SCM system. it also introduced the
concepts of the SCM tools and processes that are used to implement those best practices. The paper shows also how to
use those concepts and processes efficiently and effectively. The paper presented concepts to integrate configuration
management with knowledge base structure in one framework. The goal was to bring together the strengths of both
service management paradigms.
The proposed knowledge framework incorporates software projects that are very complex in nature and with a high
degree of relationships. These projects are hard to manage and hard to trace their interactivity and relationships without
automatic tools. Configuration management is one of the disciplines that can deals with such complex systems. The
framework has capabilities for recording activities associated with software projects as well as their relationships. By
using the software management system, organizations will be able to manage all points from any single location.
Managing software resources is essential to understand what applications are installed in the organizations'
environment, for both license compliance and for tracking blacklisted or other software. This framework provides
useful information for making the process successful and enabling users to get accurate information concerning what is
installed in the environment.
The knowledge framework showed that the incorporated software configuration management system provides methods
and techniques to monitor components and subsystems with unique reporting requirements module, track performance
and costs of each individual component and/or subsystem. It calculates a projected date for the life of a component
and/or subsystem, give the user time to plan and schedule the change-out in advance. It also alerts users when a
component and/or subsystem is due for change-out, allows users to schedule the change-out of components and/or
subsystems nearing the end of their projected lives. It prevents components from failing while they are in service, track
warranty information and monitors the status of each component's and/ or subsystem's warranty. It keeps track of each
component's and/or subsystem's current and historical location, and graphically shows exactly where a component
and/or subsystem is located on a specific piece of equipment.
For future work, the framework will extend the work to deals with cloud software configuration management. The
future extension should include tools that become virtual appliances. They can be instantiated as virtual machines and
saved with state and version. The tools can model and manage cloud-based virtual resources, including virtual
appliances, storage units, and software bundles. The future work should show how the roles and responsibilities of the
cloud actors become merged well with developers.
References
[1]. Leon A., (2015). Software Configuration Management Hanbook, Artech House, MA.
[2]. Lehman M. M., (1991). Software Engineering: The Software Process and Their Support, Software Engineering
Journal, Vol. 6, No. 5, pp. 243-258.
[3]. Wettinger J., Behrendt M., Binz T., Breitenbcher U., Breiter G., Leymann F., Moser S., Schwertle I. and Spatzie
T., (2013). Integrating Configuration Management with Model-Driven Cloud Management Based on TOSCA,
2013 SciTePress.
[4]. what-is-software-configuration-management,
(2016).
Retreived
from
https://intensetesting.wordpress.com/2014/03/13/what-is-software-configuration-management-and-why-it-isrequired/, July 016.
[5]. MIL-HDBK-61A, (2011). Military Handbook: Configuration Management Guidance, Department of Defense,
Retrieved June 2016.
[6]. ANSI/EIA-649B, (2011). National Consensus Standard for Configuration Management, TechAmerica, Retrieved
June 2016.
[7]. History and Heritage of Civil Engineering (2016). Retrieved from ASCE, June 2016.
[8]. Institution of Civil Engineers, (2016). What is Civil Engineering, Retrieved from ICE, June 2016.
Page 16


ISSN 2321-5976
[9]. Configuration Management and the Federal Transportation Administration (FTA) National Lessons Learned
Program, (2016). Retrieved from Federal Transportation Administration, June 2016.
[10]. ANSI/EIA-649B, (2011). National Consensus Standard for Configuration Management. TechAmerica, Retrieved
June 2016.
[11]. Systems Engineering Fundamentals, (2001). Defense Acquisition University Press. January 2001.
[12]. Aiello, R. (2010). Configuration Management Best Practices: Practical Methods that Work in the Real World (1st
Ed.), Addison-Wesley.
[13]. Amies A., Peddle S., Pan T. M. and Zou P. X., (2012). Develop cloud applications with rational tools. IBM
developer Works (IBM).
[14]. Jones M. K., (2000). Software Configuration Management for the Web, Methods & Tools: Global knowledge
source for software development professionals ISSN 1023-4918 Winter 2000 Vol. 8, No. 4, PP. 16-25.
[15]. IEEE STD, (2012). IEEE Standard for Configuration Management in Systems and Software Engineering, 8282012, doi:10.1109/IEEESTD.2012.6170935, ISBN 978-0-7381-7232-3.
[16]. Leblang D. B. and McLean G. D., (1985). Configuration Management for large-scale software development
efforts. In Proceedings of the workshop on Software Environments for Programming-in-the-Large. Pages 122- 127.
Harwichport, Massachussets.
[17]. Sun Microsystem. Introduction to the NSE, (1988). Network Software Environment: Reference Manual. Sun. Part
N 800-2095, March 1988. J. Estublier. A configuration manager: The Adele Database of Programs . In
Proceedings of the workshop on Software Environments for Programming-in-the-Large. Pages 140-147.
Harwichport, Massachussets, June 1985.
[18]. Thakur D., (2016). Explain Software Configuration Management Process, Computer Note, Retrieved from
http://ecomputernotes.com/software-engineering/explain-software-configuration-management-process, June 2016.
[19]. Leblang D. B., (1994). The CM Challenge: Configuration Management that Works. Configuration
Management, Edited by W. Tichy; J. Wiley and Sons.
[20]. Cagan M. and Wright A., ( 1993). Untangling configuration management: Mechanism and methodology in CM
systems. In Proc. 4th Int. Workshop on Conf. Man. SCM4. Baltimore 1993. Springer Verlag LNCS, pp. 35-53.
[21]. Dart S., (1991). Concepts in Configuration Management Systems. Proc. of the 3rd. Intl. Workshop on Software
Configuration Management. Trondheim, Norway.
[22]. Estublier J., Dami S. and M. Amiour, (1997). High Level Process Modeling for SCM Systems. SCM 7, LNCS
1235. Pp. 81-98, May, Boston, USA.
[23]. Estublier J., (2016).
Software Configuration Management: A Road Map, retrieved from
http://www0.cs.ucl.ac.uk/staff/a.finkelstein/fose/fdestublier.pdf, july 2016.
[24]. Memorandum, Specifications and Standards, (1994). A New Way of Doing Business. Secretary of Defense. 29
June. Retrieved June 2016.
[25]. Configuration Management Compliance Validation, (2001). Critical Review and Technology Assessment
(CR/TA) Report. Defense Technical Information Center. Retrieved June 2016.
[26]. Halogen software, (2016). Retrieved from http://www.scmwise.com/build-management.html, June 2016.
[27]. Thom, W., (2009). People, Process, and Performance Management in Project Management, Retrieved from
http://www.pmhut.com/people-process-and-performance-management-in-project-management, July 2016.
[28]. Theodore P., (2012). The Ultimate Guide to Business Process Management: Everything You Need to Know and
How to Apply It to Your Organization. CreateSpace Independent Publishing Platform. pp. 67. ISBN 978-1-47748613-9.
[29]. Environmental management, (2016). Retrieved from http://www.busnessdictionary.com/definition/environmentalmanagement.html, June 2016.
[30]. Sroufe, R. (2003). Effects of Environmental Management Systems on Environmental Management Practices and
Operations. Production and Operations Management. 12-3: 416-431.
[31]. El-Gayar, O.; Fritz, B. D. (2006). Environmental Management Information Systems (EMIS) for Sustainable
Development: A Conceptual Overview. Communications of the Association for Information Systems (Association
for Information Systems) 17. ISSN 1529-3181.
[32]. Berczuk, S. P. and Appleton B., (2003). Software Configuration Management Patterns: Effective Teamwork,
Practical Integration, Addison-Wesley Professional.
[33]. Y. Wang, and M. Tseng, (2011). Adaptive Attribute Selection for Configurator Design via Shapley Value.
Artificial Intelligence for Engineering Design, Analysis and Manufacturing, 25 (1): 189199.
[34]. Felfernig A., Friedrich G. and Jannach D., (2001). Conceptual modeling for configuration of mass-customizable
products, Artificial Intelligence in Engineering 15(2): 165176.
Page 17


ISSN 2321-5976
[35]. Felfernig A., (2007). Standardized Configuration Knowledge Representations as Technological Foundation for
Mass Customization, IEEE Transactions on Engineering Management, 54 (1), pp. 4156.
[36]. Felfernig A., Hotz L., Bagley C., and Tiihonen J., (2014). Knowledge-based Configuration: From Research to
Business Cases, Elsevier/Morgan Kaufmann.
[37]. Asikainen T., Mnnist T., and Soininen T., (2007). Kumbang: Domain ontology for modelling variability in
software product families, Advanced Engineering Informatics, 21(1): 2340.
[38]. National Information Systems Security Glossary, Retrieved June 2016.
[39]. Lueninghoener C., (2011). Getting Started with Configuration Management. [[;login:]] issue: April, Volume 36,
Number 2. Retrieved June 2016. Wikilink embedded in URL title (help).
[40]. Burgess M., (1995). Cfengine: a site configuration engine, USENIX Computing systems, Vol. 8, No. 3.
[41]. Burgess M., (2003). On the theory of system administration, Science of Computer Programming pp.1-46
[42]. Burgess M., (2004). Configurable immunity for evolving human-computer systems, Science of Computer
Programming, pp.197-213
[43]. Configuration Management for Transportation Management Systems Handbook, (2016). Federal Highway
Administration. Retrieved June 2016.
[44]. Configuration Management Case Study, (2016). PACO Technologies, Inc., Retrieved June 2016.
[45]. Bachmann F. and Clement P., (2005). Variability in Software Product Lines (CMU/SEI-2005-TR-012,
ADA450337). Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University.
[46]. Benefitsofstandards, (2016). Retrieved from http://www.iso.org/iso/home/standards/benefitsofstandards.htm, July
2016.
[47]. Dimoji D. O., Oju O., Olawuyi J.O, BensonEmenike M. E, (2012). Computer System Configuration
Management, EIEs 2nd Intl Conf.Comp., Energy, Net., Robotics and Telecom.
[48]. CMCS (2016). Retrieved from http://www.pacotechnologies.com/Pages/Case-Study.aspx, Jul 2016, Configuration
Management Case Study PACO Technologies, Inc.
[49]. Federal Transportation Administration National Lessons Learned Program (2016). Retrieved from
http://www.fta.dot.gov/printer_friendly/planning_environment_1338.html, June 2016.
[50]. FTA, (2016). Retrieved from http://www.pacotechnologies.com/Pages/FTA-National-Lessons-LearnedProgram.aspx, Configuration Management and the Federal Transportation Administration (FTA) National Lessons
Learned Program, Jul 2016.
[51]. ANSI/EIA-649-1998 National Consensus Standard for Configuration Management.
[52]. Sarma A., Redmiles D., and van der Hoek A., (2007). A Comprehensive Evaluation of Workspace Awareness in
Software Configuration Management Systems. IEEE Symposium on Visual Languages and Human-Centric
Computing. pp. 23-26.
[53]. Storey, M.-A., Cubranic D., and German D.M., (2005). On the Use of Visualization to Support Awareness of
Human Activities in Software Development: A Survey and a Framework. ACM Symposium on Software
Visualization. pp. 193-202.
[54]. SoftwareBuildTools, (2016). Retrieved from http://www.scmwise.com/software-build-tools.html, July 2016.
[55]. Lee, K. A., (1996). The Buildmeister's Guide - Achieving Agile Software Delivery. Lulu.com. p. 21.
Page 18

A Knowledge Based Framework For Managing Software Components

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

A Knowledge Based Framework For Managing Software Components

Uploaded by

Copyright:

Available Formats

IPASJ International Journal of Information Technology (IIJIT)

Web Site: http://www.ipasj.org/IIJIT/IIJIT.htm

A Publisher for Research Motivation ........

Volume 4, Issue 8, August 2016