configuration management report

P a g e | 0

Table of ContentsConfiguration Management........................................................................................................................1

Scope of Configuration Management......................................................................................................3

History of Configuration Management....................................................................................................3

Goals and Objectives of Software Configuration Management...............................................................4

Software Configuration Management Practice Risks...............................................................................5

Advantages of Configuration Management.............................................................................................6

SDLC Waterfall Model.................................................................................................................................6

Waterfall Model Application...................................................................................................................7

Software Development Life Cycle Flow Diagram.........................................................................................8

Software Development Lifecycle.................................................................................................................9

1. Requirement and Analysis...............................................................................................................9

The documents pertaining to this stage..............................................................................................9

2. Development and Implementation................................................................................................11

The documents pertaining to this stage............................................................................................12

3. Integration.....................................................................................................................................12

The basic steps of product integration..............................................................................................13


4. Quality Control..............................................................................................................................14

Quality Control Check parameters.....................................................................................................15


5. Release and Deployment...............................................................................................................16

The primary functions of the Release team.......................................................................................16


Advantages of the Waterfall Model.......................................................................................................17

Disadvantages of the Waterfall Model..................................................................................................17

SDLC Agile Model.......................................................................................................................................17

Advantages of the Agile Model..............................................................................................................19

Disadvantages of Agile Model...............................................................................................................19

Conclusion.................................................................................................................................................21

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 ManagementThe 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 fileso Addressing versions and releases o Change Control Formso 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 baselineso Processing and managing change requests and Change Control Boards (CCBs)o Communicating configuration statuso Performing configuration auditso Building, testing, and debugging workspaceso 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 Trackerso Audit and Status reportso Review

Build Management- Managing the process and tools used for builds. Process Management- Ensuring adherence to the organization's development process.

o Master Project Listo Project plan, Initialization and Closureo 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 ManagementSome 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 DEVELOPMENT LIFE CYCLE

REQUIREMENTS

DEVELOPMENT

INTEGRATION

QUALITY CONTROL

RELEASE AND

DEPLOYMENT

P a g e | 8

Software Development Lifecycle1. 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 producto Currently available capabilities for the enhancemento The specific scope of the projecto Business rules requirements specified with a numerical outlineo The data sources and destination to and from the producto 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 generatedo 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 confirmationo 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 cliento 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 meto The planning done for meeting the requirementso 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.

The documents pertaining to this stage are:

Code Review Checklist: 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 testedo The particular input given to the code segmento The desired outputo The actual output o The final resulto 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 correctiono 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.

P a g e | 12

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 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 Criteriao Product integration procedures

Build Procedures for PB (Full, Incremental) / Dot neto 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?

P a g e | 13

Probability of proper functioning (should be 1) Are you foreseeing any issues related to build? 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 Compatibilityo Review Interface Descriptions for Completeness (Hardware and Software

configuration)o Manage Interfaces (Build server)

Assemble Product Components and Deliver the Producto 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.

The documents pertaining to this stage are: 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 numbero Target dates for release to QC and Target dates for release to Cliento Unit Tests Result and Code Review Checklist results and the impacted areas.o Whether the Database script is re-run able or over-writes datao If code change is done at latest Service pack or Roll Up level.o If the products are sent for Integration to higher Versiono Any other Configuration documents to be packaged along with it.

Build Sheeto 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

P a g e | 14

refers to the ability for software to perform well in unforeseeable scenarios and to keep a relatively low defect rate.

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 Extensibilityo Maintainability

Documentation


Quality Control Test Case Document: This is a detailed document pertaining to the Quality Control process which contains:

P a g e | 15

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 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-

review5. 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.

P a g e | 16

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.


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.

P a g e | 17

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.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

P a g e | 18

Simplicity—the art of maximizing the amount of work not done—is essential Self-organizing teams Regular adaptation to changing circumstances

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.

P a g e | 19

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.

ConclusionConfiguration 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.