Configuration Management Report

P a g e | 0
Table of Contents
Configuration Management ................................................................................................................1
Scope of Configuration Management...............................................................................................2
History of Configuration Management.............................................................................................2
Goals and Objectives of Software Configuration Management ..........................................................3
Software Configuration Management Practice Risks .........................................................................4
Advantages of Configuration Management.......................................................................................5
SDLC Waterfall Model.........................................................................................................................5
Waterfall Model Application............................................................................................................6
Software Development Life Cycle Flow Diagram...................................................................................7
Software Development Lifecycle..........................................................................................................8
1. Requirement and Analysis........................................................................................................8
The documents pertaining to this stage........................................................................................8
2. Development and Implementation.........................................................................................10
The documents pertaining to this stage......................................................................................11
3. Integration............................................................................................................................11
The basic steps of product integration........................................................................................12
4. Quality Control......................................................................................................................13
Quality Control Check parameters..............................................................................................14
5. Release and Deployment .......................................................................................................15
The primary functions of the Release team.................................................................................15
Advantages of the Waterfall Model................................................................................................16
Disadvantages of the Waterfall Model ...........................................................................................16
SDLC Agile Model..............................................................................................................................16
Advantages of the Agile Model......................................................................................................18
Disadvantages of Agile Model........................................................................................................18
Conclusion .......................................................................................................................................19

P a g e | 1
Configuration Management
Software Configuration Management refers to a discipline for evaluating, coordinating,
approving or disapproving, and implementing changes in artifacts that are used to construct and
maintain software systems. An artifact may be a piece of hardware or software or documentation.
Software Configuration Management enables the management of artifacts from the initial
concept through design, implementation, testing, baselining, building, release, and maintenance.
If a configuration is working well, Software Configuration Management can determine how to
replicate it across many hosts.
At its heart, Software Configuration Management 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. It involves the process of identifying and
defining the items in the system, controlling the change of these items throughout their lifecycle,
recording and reporting the status of items and change requests, and verifying the completeness
and correctness of items. Changes are made to correct errors, provide enhancements, or simply
reflect the evolutionary refinement of product definition. If something goes wrong, Software
Configuration Management can determine what was changed and who changed it. Software
Configuration Management is about keeping the inevitable change under control. Without a
well-enforced Software Configuration Management 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 Software Configuration Management requires a well-defined and
institutionalized set of policies and standards that clearly define
 The set of artifacts (configuration items) under the jurisdiction of Software Configuration
Management
 How artifacts are named
 How artifacts enter and leave the controlled set
 How an artifact under Software Configuration Management is allowed to change
 How different versions of an artifact under Software Configuration Management are
made available and under what conditions each one can be used
 How Software Configuration Management tools are used to enable and enforce Software
Configuration Management
These policies and standards are documented in a Software Configuration Management plan that
informs everyone in the organization just how Software Configuration Management is carried
out.

P a g e | 2
Scope of Configuration Management
History of Configuration Management
The history of Software Configuration Management in computing can be traced back as early as
the 1950s, when Software Configuration Management (for 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. With the advances in language
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. Eventually, the
tools became systems to manage software changes. Industry-wide practices were offered as
solutions either in an open or proprietary manner. 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.

P a g e | 3
Goals and Objectives of Software Configuration Management
 Configuration Identification - Identify the configuration items, components, and related
work products that will be placed under configuration management like configurations,
configuration items and baselines.
o Labeling and numbering documents and files
o Relationships between documents and files
o Addressing versions and releases
o Change Control Forms
o Various baselines for the project (product versioning)
 Configuration Control- Implementing a controlled change process. This is usually
achieved by setting up a change control board whose primary function is to approve or
reject all change requests that are sent against any baseline.
o Changing baselines
o Processing and managing change requests and Change Control Boards (CCBs)
o Communicating configuration status
o Performing configuration audits
o Building, testing, and debugging workspaces
o Who owns what product code and how to appropriately work with that code
 Configuration Status Accounting- Recording and reporting all the necessary
information on the status of the development process.
 Configuration Auditing- Ensuring that configurations contain all their intended parts
and are sound with respect to their specifying documents, including requirements,
architectural specifications and user manuals.
o Trackers
o Audit and Status reports
o Review
 Build Management- Managing the process and tools used for builds.
 Process Management- Ensuring adherence to the organization's development process.
o Master Project List
o Project plan, Initialization and Closure
o Naming Conventions
 Environment Management- Managing the software and hardware that host the system.
o Preventive Maintenance Checklist
 Teamwork - Facilitate team interactions related to the process.
 Defect Tracking- Making sure every defect has traceability back to the source.

P a g e | 4
Software Configuration Management Practice Risks
Software Configuration Management imposes intellectual control over the otherwise
unmanageable activities involved in updating and using a multitude of versions of a multitude of
artifacts, both core assets (of all kinds) and product-specific resources. Without an adequate
Software Configuration Management process in place, and without adequate, adherence to that
process, developers will not be able to build and deploy products correctly, let alone recreate
earlier versions of products. Inadequate Software Configuration Management control can result
from the following:
 An insufficiently robust process: Software Configuration Management for product lines
is more complex than Software Configuration Management for single systems. If an
organization does not define a robust enough Software Configuration Management
process, it will fail, and the product line approach to product building will become less
efficient.
 Software Configuration Management occurring too late: If the organization
developing the product line does not have Software Configuration Management practices
in place well before the first product is shipped, building new product versions or
rebuilding shipped versions will be very time-consuming and expensive, negating one of
the chief benefits of product lines.
 Multiple core asset evolution paths: There is a risk that a core asset may evolve in
different directions–something that can happen either by design in order to enable the
usage of a core asset in different environments such as multiple operating systems or by
accident when a core asset evolves within a specific product. When done by design, the
evolution might be unavoidable and increase the complexity of the Software
Configuration Management. You must watch for evolution by accident, because it can
degrade the usefulness of the core asset base.
 Unenforced Software Configuration Management practices: Owing to the complexity
of the total product line configuration, not enforcing a Software Configuration
Management process can result in total chaos (a result that's much worse than that for a
single-system).
 Insufficiently robust tool support: Software Configuration Management that is
sophisticated enough to support a nontrivial product line requires tool support, and there
is no shortage of available commercial Software Configuration Management systems.
However, most of them do not directly support the functionality required for the Software
Configuration Management to be useful in a product line context. Many of them can be
"convinced" to provide the necessary functionality, but this convincing is a time-
consuming task requiring specialized knowledge. If the organization fails to assign
someone to customize the Software Configuration Management system for the product
line, the Software Configuration Management tool support is likely to be ineffectual.

P a g e | 5
Such a person needs to have both a good understanding of the product line processes and
a solid grounding in Software Configuration Management.
Advantages of Configuration Management
Some advantages of Configuration Management are:
 Increased control over technology assets through improved visibility and tracking
 Enhanced system reliability through more rapid detection and correction of improper
configurations that could negatively impact performance
 The ability to define and enforce formal policies and procedures that govern asset
identification, status monitoring, and auditing
 Improved asset maintenance through the ability to better utilize proactive, preventative, and
predictive measures
 Greater agility through more accurate analysis of the impact of potential changes to
hardware, software, firmware, documentation, testing procedures, etc.
 Enhanced reconciliation and management of complex system and infrastructures
SDLC Waterfall Model
The Waterfall Model was first Process Model to be introduced. It is also referred to as a linear-
sequential life cycle model. It is very simple to understand and use. In a waterfall model, each
phase must be completed before the next phase can begin and there is no overlapping in the
phases.
Waterfall model is the earliest SDLC approach that was used for software development. The
waterfall development model originates in the manufacturing and construction industries;
highly structured physical environments in which after-the-fact changes are prohibitively costly,
if not impossible. Since no formal software development methodologies existed at the time, this
hardware-oriented model was simply adapted for software development. The first known
presentation describing use of similar phases in software engineering was held by Herbert D.
Benington at Symposium on advanced programming methods for digital computers on 29 June
1956. This presentation was about the development of software for SAGE. In 1983 the paper was
republished with a foreword by Benington pointing out that the process was not in fact
performed in a strict top-down fashion, but depended on a prototype.
The first formal description of the waterfall model is often cited as a 1970 article by Winston W.
Royce, although Royce did not use the term "waterfall" in that article. Royce presented this
model as an example of a flawed, non-working model. This, in fact, is how the term is generally
used in writing about software development—to describe a critical view of a commonly used
software development practice.

P a g e | 6
The earliest use of the term "waterfall" may have been a 1976 paper by Bell and Thayer.
The waterfall Model illustrates the software development process in a linear sequential flow;
hence it is also referred to as a linear-sequential life cycle model. This means that any phase in
the development process begins only if the previous phase is complete. In waterfall model phases
do not overlap.
Waterfall Model Application
Every software developed is different and requires a suitable SDLC approach to be followed
based on the internal and external factors. Some situations where the use of Waterfall model is
most appropriate are:
 Requirements are very well documented, clear and fixed.
 Product definition is stable.
 Technology is understood and is not dynamic.
 There are no ambiguous requirements.
 Ample resources with required expertise are available to support the product.
 The project is short.

P a g e | 7
SOFTWARE DEVELOPMENTLIFE CYCLE
REQUIREMENTS
DEVELOPMENT
INTEGRATION
QUALITY CONTROL
RELEASE AND
DEPLOYMENT

P a g e | 8
Software Development Lifecycle
1. Requirement and Analysis: This is the first stage of Software Development which
involves collecting the requirement data regarding the project from the client and analyzing
the same. This data may be technical, Business related or Technology related. It may also
contain constraints and guidelines that are to be kept in mind while designing and developing
the particular product. The requirements should be documented, actionable, measurable,
testable, traceable, related to identified business needs or opportunities, and defined to a level
of detail sufficient for system design.
Details regarding the functions and behavior expected from the product are taken down by
the Clients Requirement Support team. The clients communicate with the Project
Management team through the Client Requirements Support team.
The Technology Analysts and the Business Analysts now read through the requirements
collected from the user and analyze them for product feasibility in the economical,
operational, and technical areas. All analyses, changes are to be approved by the Change
Control Board.
The documents pertaining to this stage are:
 Client Requirement Document:
o This document contains the brief requirements from the product.
o It also specifies the Business logic and parameters that the product should be
able to handle.
o A few Business scenarios where this product can be used are also mentioned
so that the exact use of the product and what is expected from it is
communicated.
o If the client made use of any other software prior to this then the screenshots
of the same can be attached to this document.
 Business Requirements Document: After the requirements document has been read
through and analyzed by the Business Analyst, a formal document is created which
specifies
o Business need for the product
o Currently available capabilities for the enhancement
o The specific scope of the project
o Business rules requirements specified with a numerical outline
o The data sources and destination to and from the product
o Items impacting interfaces or conversion
o The assumptions, constraints and limitations.

P a g e | 9
 Functional Specifications Requirement Document: After the Business
Requirement is approved by Project Managers, this is now translated into a
Functional Specifications Requirement Document. This document
o Explains the exact behavior of the Engineering system
o Explains how its various functions would perform for the input data
o What outputs are generated
o Provide a precise idea of the problem to be solved so that they can efficiently
design the system and estimate the cost of design alternatives.
o Provide guidance to testers for verification (qualification) of each technical
requirement.
A functional specification does not define the inner workings of the proposed system;
it does not include the specification of how the system function will be implemented.
Instead, it focuses on what various outside agents (people using the program,
computer peripherals, or other computers, for example) might "observe" when
interacting with the system.
 Requirements Defects Tracker: This document gives a description of the lack of
information of the lack of clarity in the information provided by the Client in the
requirement document. This document describes
o The anomalies in the requirements specified by the client,
o How this defect was corrected or clarified with the clients confirmation
o How the requirement document was modified according to this new/modified
requirement information.
 Change Request Document: When the client wants a particular change in the
requirement from a product then this change can be requested. The change request
form has
o A brief description on the change the Client wants,
o The reason for which this change was requested from the client
o How this change is predicted to be implemented in the product
o Estimation of what impact it has on the various parameters and the aspects of
Project Management.
 Defect Resolution Document: This document refers to the defects encountered when
the product is implemented in the Client’s system. It contains:
o Steps for installation and use of product.
o Defects encountered when the above steps were performed. This must have
enough resolution for the Clients to reproduce.
o Steps if any for Client to resolve the issues
 High Level Estimation Document: This is an estimation document which mentions
o All the requirements and their brief description

P a g e | 10
o How the solutions for the corresponding requirements can be designed and
implemented using the available software resources
o The estimated effort (in days) that will be needed to fulfill that particular
requirement as mentioned
o A basic plan for the development team to follow during the development
process.
 Initial Analysis and Estimation Document: This document is an initial plan
document, which specifies
o How the requirements of the clients are met
o The planning done for meeting the requirements
o The estimates for the effort (days) allocated for each stage of the product
development process.
This analysis is done for every component of the requirement of the Client.
2. Development and Implementation: The Development team is responsible for the
Design, Development and Implementation of the primary functioning and behavior of the
product based on the Requirement Document received from the Client.
Based on the requirements more than one design approach is proposed to the stake holders.
These are reviewed and one approach is chosen. A design should clearly define all the
architectural modules of the product along with its communication and data flow
representation with the external and third party modules (if any). The internal design of all
the modules of the proposed architecture should be clearly defined with the minutest of the
details. If the design is performed in a detailed and organized manner, code generation can be
accomplished without much hassle.
The Development and Implementation is the process of actual program development in the
form of a code, usually done with high level language. This code should implement and
fulfill all the requirements of the Client. Developers have to follow the coding guidelines
defined by their organization and programming tools like compilers, interpreters, debuggers
etc are used to generate the code. Different high level programming languages such as C,
C++, C#, PL/SQL, PowerBuilder, ASP.net, Java, PHP etc…. are used for coding. The
programming language is chosen with respect to the type of software being developed.
Unit Testing is a software testing method by which individual units of source code, sets of
one or more computer program modules together with associated control data, usage
procedures, and operating procedures are tested to determine if they are fit for use. A test on
a particular unit is entirely independent of the test on another Unit and hence do not

P a g e | 11
guarantee the ideal functioning of the entire code. . Unit testing is generally a three cycle
process.
Once the code is tested and verified it is stored onto a storage called Code Repository, which
may be managed by Versioning software such a VSS or Tortoise SVN.
 Code ReviewChecklist: This document is a checklist to analyze the code so as to
o Check whether it follows the basic code guidelines set by the organization to
ensure the quality of code is optimal and is not wasteful of the available
resources.
o It is intended to find and fix mistakes overlooked in the initial development
phase, improving both the overall quality of software and the developers'
skills.
 Unit Test Case Document: The Unit Test Case document is created to keep track of
Unit Tests. The document contains
o The current version of code being tested
o The particular input given to the code segment
o The desired output
o The actual output
o The final result
o If a particular unit test is failed by the code segment, then this is made note of
in the review tab and it is ensured that the defect is duly corrected.
o The names of the personnel responsible for the correction
o Confirmation of the correction
o Other remarks
 Frontend Standards Checklist: This document is a checklist which checks for
specified set of rules for designing the Frontend (GUI) of the product. The
specifications (font size, buttons, titles etc.) should be as per the guidelines.
3. Integration: Software integration refers to the practice of combining individually tested
software components into an integrated whole. Software is integrated when components are
combined into subsystems or when subsystems are combined into products. Components
may be integrated after all are implemented and tested. It is the process of linking together
different computing systems and software applications physically or functionally, to act as a
coordinated whole.
Practically, the Integrator extracts the code pieces stored in the repository, creates a solution
out of these code segments and performs a Build operation using Build software such as MS

P a g e | 12
Build, Make etc. ‘Build’ refers to the process of converting source code files into standalone
software artifact that can be run on a computer. This is done by compiling the change code
components and linking them in the correct order. The output executable after ‘Build’ is now
Versioned and packaged with the related documents and stored back in the repository.
A Software Integrator is also responsible for Versioning. Software Versioning is the process
of assigning either unique version names or unique version numbers to unique states of
computer software. Within a given version number category, these numbers are generally
assigned in increasing order and correspond to new developments in the software.
The Software Integrator also performs Integration Testing. Integration testing is a logical
extension of unit testing. In its simplest form, two units that have already been tested are
combined into a component and the interface between them is tested. A component, in this
sense, refers to an integrated aggregate of more than one unit. In a realistic scenario, many
units are combined into components, which are in turn aggregated into even larger parts of
the program. The idea is to test combinations of pieces and eventually expand the process to
test your modules with those of other groups. Eventually all the modules making up a process
are tested together.
The basic steps of product integration for an Envision Financial Systems product are:
 Determine Integration Sequence
o Identify the product components
o Identify the Component verifications during integration
o Select the best integration sequence
 Establish the Product Integration Environment
o Identify the requirements
o Identify verification criteria
o Develop an integration environment
o Maintain the product integration environment
o Dispose of those portions of the environment.
 Establish Product Integration Procedures and Criteria
o Product integration procedures
 Build Procedures for PB (Full, Incremental) / Dot net
o Product integration criteria
 PA Level of build environment used for build
 Verification of product components version with repository
 Quality/cost tradeoffs for integration operations on Build server
 Are all the builds delivered on Build server are properly tested?
 Probability of proper functioning (should be 1)
 Are you foreseeing any issues related to build?

P a g e | 13
 Build Delivery rate and its variation
 Lead time from package request to package delivery
 Build Manager personnel availability
 Availability of the integration facility/line/environment
 Ensure Interface Compatibility
o Review Interface Descriptions for Completeness (Hardware and Software
configuration)
o Manage Interfaces (Build server)
 Assemble Product Components and Deliver the Product
o Confirm Readiness of Product Components for Integration.
o Assemble Product Components.
o Evaluate Assembled Product Components.
o Package and Deliver the Product or Product Component.
 Integration Request Form: This document is filled by the Developers to request
Integration of the code segments stored in the repository. This document contains
o All the details of the code components in the repository ready for Integration.
o Work ID, Package Type and Version number
o Target dates for release to QC and Target dates for release to Client
o Unit Tests Result and Code Review Checklist results and the impacted areas.
o Whether the Database script is re-run able or over-writes data
o If code change is done at latest Service pack or Roll Up level.
o If the products are sent for Integration to higher Version
o Any other Configuration documents to be packaged along with it.
 Build Sheet
o All the details of the code components identified for Product Integration for a
particular build.
 Product Integration Check-list
4. Quality Control: Quality Control is the set of procedures used by organizations to ensure
that a software product will meet its quality goals at the best value to the customer, and to
continually improve the organization’s ability to produce software products in the future.
Quality Control refers to specified functional requirements as well as non-functional
requirements such as supportability, performance and usability for all available inputs. It also
refers to the ability for software to perform well in unforeseeable scenarios and to keep a
relatively low defect rate.

P a g e | 14
The Quality Control team checks that the project follows its standards processes, and
procedures, and that the project produces the required internal and external products.
The Quality Control Tests are different from the Unit Tests in this way; Unit Tests are
performed only on specific components of the Software code. Thus they only conform to the
quality of that particular segment. Whereas QC Tests are performed on the complete product
after Build, which is the integration of all the components of the Software code and very
closely resembles what is delivered to the Client. The QC Tests may make us of the Unit Test
cases. This checks all the functions of the product and satisfaction of all the requirements
mentioned in the requirement documents are checked for.
It is also the duty of the Quality Control Team to add other required files and package
components (Plug-ins, add-ons etc) that are important for the ideal working of the tested
product.
Quality Control Check parameters:
 Correctness
 Product quality
o conformance to requirements or program specification; related to Reliability
 Scalability
 Understandability
 Conciseness
 Portability
 Testability
 Usability
 Efficiency
 Security
 Completeness
 Absence of bugs
 Fault-tolerance
o Extensibility
o Maintainability
 Documentation
Quality Control Test Case Document: This is a detailed document pertaining to the Quality
Control process which contains:
 The details of the Project, Program, Version number, Test Type and Documents
 The Impact areas where previous defects or errors were found, defect reference
 Test Cases, Test Scenarios, Tester, proof of testing

P a g e | 15
 Expected output, Actual output, Result
 Checklist to ensure all the crucial points are covered while Quality Testing.
 Defects, Defect type, the stage it were introduced, severity
 Defect correction details, person responsible, status, date of correction and Remarks.
 When three major defects are encountered, then the document should be sent for re-
review
5. Release and Deployment: Software deployment is all of the activities that make a
software system available for use. The general deployment process consists of several
interrelated activities with possible transitions between them. These activities can occur at
the producer side or at the consumer side or both. Because every software system is unique,
the precise processes or procedures within each activity can hardly be defined. Therefore,
"deployment" should be interpreted as a general process that has to be customized according
to specific requirements or characteristics.
User Acceptance Tests are also performed in this stage. User Acceptance Test or UAT are
real world tests, where the product functioning is checked on the Client’s system.
The Release and Deployment team are also responsible for making the product use able to
the customer, feedback, maintenance and support.
The primary functions of the Release team are:
 Release: This involves making the complete developed product available and transfer
of the product to the Client for installation. The resources required for operation of
the product are made available in this stage.
 Install and Activate: Installation is the process of starting up the executables on the
Clients systems so as to start the product’s functioning. Activation is initiation of
service to the customer from that product.
 Deactivate: The stopping of execution of the product is called Deactivation. This
may be done temporarily for modifications.
 Adapt: Certain local modifications done to the system to ensure ideal working of the
product is called Adapting.
 Update: The update process replaces an earlier version of all or part of a software
system with a newer release.
 Uninstall: It is the removal of a system that is no longer required. It also involves
some reconfiguration of other software systems in order to remove the uninstalled
system’s files and dependencies.
 Retire: Ultimately, a software system is marked as obsolete and support by the
producers is withdrawn. It is the end of the life cycle of a software product.

P a g e | 16
 Package Release and Upload Mail templates: These are the official formats for the
release of the product to the Client
 Package Delivery Delay form: This form is to specify when a particular package
will be released on a postponed date due to unforeseen circumstances. This should
specify the expected date the package can be received.
 Customer Feedback form: The response and feedback from the Client regarding the
product, services and support from the organization can be recorded
Advantages of the Waterfall Model
 The waterfall methodology stresses meticulous record keeping. Having such records allows
for the ability to improve upon the existing program in the future.
 With the waterfall methodology, the client knows what to expect. They’ll have an idea of the
size, cost, and timeline for the project. They’ll have a definite idea of what their program will
do in the end.
 In the case of employee turnover, waterfall’s strong documentation allows for minimal
project impact.
Disadvantages of the Waterfall Model
 Once a step has been completed, developers can’t go back to a previous stage and make
changes.
 Waterfall methodology relies heavily on initial requirements. However, if these requirements
are faulty in any manner, the project is doomed.
 If a requirement error is found, or a change needs to be made, the project has to start from the
beginning with all new code.
 The whole product is only tested at the end. If bugs are written early, but discovered late,
their existence may have affected how other code was written.
 Additionally, the temptation to delay thorough testing is often very high, as these delays
allow short-term wins of staying on-schedule.
 The plan doesn’t take into account a client’s evolving needs. If the client realizes that they
need more than they initially thought, and demand change, the project will come in late and
impact budget.
SDLC Agile Model
Agile SDLC model is a combination of iterative and incremental process models with focus on
process adaptability and customer satisfaction by rapid delivery of working software product.

P a g e | 17
Agile model believes that every project needs to be handled differently and the existing methods
need to be tailored to best suit the project requirements. In agile the tasks are divided to time
boxes (small time frames) to deliver specific features for a release.
Agile Methods break the product into small incremental builds. These builds are provided in
iterations. Each iteration typically lasts from about one to three weeks. Every iteration involves
cross functional teams working simultaneously on various areas like planning, requirements
analysis, design, coding, unit testing, and acceptance testing.
At the end of the iteration a working product is displayed to the customer and important
stakeholders.
Following are the Agile Manifesto principles
 Individuals and interactions - in agile development, self-organization and motivation
are important, as are interactions like co-location and pair programming.
 Working software - Demo working software is considered the best means of
communication with the customer to understand their requirement, instead of just
depending on documentation.
 Customer collaboration - As the requirements cannot be gathered completely in the
beginning of the project due to various factors, continuous customer interaction is very
important to get proper product requirements.
 Responding to change - agile development is focused on quick responses to change and
continuous development.
The Agile Manifesto is based on twelve principles:
 Customer satisfaction by rapid delivery of useful software
 Welcome changing requirements, even late in development
 Working software is delivered frequently (weeks rather than months)
 Close, daily cooperation between business people and developers
 Projects are built around motivated individuals, who should be trusted
 Face-to-face conversation is the best form of communication (co-location)
 Working software is the principal measure of progress
 Sustainable development, able to maintain a constant pace
 Continuous attention to technical excellence and good design
 Simplicity—the art of maximizing the amount of work not done—is essential
 Self-organizing teams
 Regular adaptation to changing circumstances

P a g e | 18
Agile Model
Advantages of the Agile Model
 The Agile methodology allows for changes to be made after the initial planning. Re-writes to
the program, as the client decides to make changes, are expected.
 Because the Agile methodology allows you to make changes, it’s easier to add features that
will keep you up to date with the latest developments in your industry.
 At the end of each sprint, project priorities are evaluated. This allows clients to add their
feedback so that they ultimately get the product they desire.
 The testing at the end of each sprint ensures that the bugs are caught and taken care of in the
development cycle. They won’t be found at the end.
 Because the products are tested so thoroughly with Agile, the product could be launched at
the end of any cycle. As a result, it’s more likely to reach its launch date.
Disadvantages of Agile Model
 With a less successful project manager, the project can become a series of code sprints. If this
happens, the project is likely to come in late and over budget.
 As the initial project doesn’t have a definitive plan, the final product can be grossly different
than what was initially intended.

P a g e | 19
Conclusion
Configuration Management has been defined as the process of management of all the artifacts
involved in the Software Development project to ensure ideal completion of the project.
Irrespective of the Software Development Model being used, Configuration Management is
important because it provides increased control over technology assets, Enhanced system
reliability, the ability to define and enforce formal policies and procedures, improved asset
maintenance, accurate analysis of change impact on Software Development process which
together help in ideal execution of the Management plan.
Two models of Software Development, Waterfall and Agile have been explained and their
respective differences have been elaborated in the report. We see that Waterfall Model is based
on phase by phase, sequential execution of the Software Development while Agile Model is
based on creating individual units with all phases in each unit. We see that the Agile model being
the newer Model has some advantages over the Waterfall Model such as allowing for changes in
the middle of development cycle, allowing addition of new features in the middle of the
Development cycle, testing after each phase of the Development Cycle ensuring on time delivery
of the product.
Taking the Waterfall Model as the base the different stages of Software Development are
mentioned and the processes in each stage are specified. The Configuration Items pertaining to
each stage which are crucial for Configuration Management are also elaborated on.
Thus a complete study on Configuration Management has been concluded.

Configuration Management Report

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Configuration Management Report

Similar to Configuration Management Report (20)

Configuration Management Report