FORM 2
THE PATENTS ACT, 1970
(39 of 1970)
&
THE PATENTS RULES, 2003
COMPLETE SPECIFICATION
(See section 10, rule 13)
1. Title of the invention: MANAGING CHANGE REQUESTS OF SOFTWARE
APPLICATIONS
2. Applicant(s)
NAME NATIONALITY ADDRESS
TATA CONSULTANCY
SERVICES LIMITED
Indian Nirmal Building, 9th Floor,
Nariman Point, Mumbai,
Maharashtra 400021, India
3. Preamble to the description
COMPLETE SPECIFICATION
The following specification particularly describes the invention and the manner in which it
is to be performed.
1
2
TECHNICAL FIELD
[0001] The present subject matter described herein, in general, relates to change
requests, and more particularly to managing change requests associated with software
applications.
BACKGROUND
[0002] Software applications include hundreds or thousands of lines of code and are
usually developed iteratively. As would be appreciated by a person skilled in the art, as the
software lifecycle for a particular software application progresses, over time features and/or
functionality are added or may be modified as a result of client input, changes in technology,
and/or as new innovations are discovered. The new features, designs, and/or functionalities
are usually incorporated by modifying the existing code or by appending the primary code
with additional lines of code. Requests to modify the software application may be presented
as a change request. It may be understood that these change requests may be presented either
during the software development lifecycle or thereafter.
[0003] Software developers may analyze the change requests and modify the software
application as per the change requests. Further, based upon the change requests, the software
developers may also wish to, at first, estimate the degree of effort that may be expended in
order to modify the software application. The estimation of degree of effort may be useful, for
example, to schedule the implementation of the change request. Further, the estimation of
degree of effort may also be useful to provide a client with a cost estimate for implementing
the change request.
[0004] It is to be understood that the software developers receive a lot of change
requests which need to be managed effectively and efficiently for smooth implementation of
the change requests. Although several tools exist for planning and management of software
development projects, these tools rely on uncoordinated spreadsheets and excessive human
intervention.
3
SUMMARY
[0005] This summary is provided to introduce concepts related to systems and
methods for managing change requests associated with a software application and the
concepts are further described below in the detailed description. This summary is not intended
to identify essential features of the claimed subject matter nor is it intended for use in
determining or limiting the scope of the claimed subject matter.
[0006] In one implementation, a method for managing one or more change requests
associated with a software application is disclosed. The one or more change requests are
indicative of modifications to be made in the software application. The method comprises
performing impact analysis for the one or more change requests. Performing the impact
analysis comprises comparing at least one of requirement descriptions associated with the one
or more change requests, components associated with the one or more change requests, and
scripts associated with the one or more change requests. The requirement descriptions, the
components, and the scripts are stored in a change request database. Performing the impact
analysis further comprises identifying one or more conflicting requirements associated with
the one or more change requests based upon the comparison. The one or more conflicting
requirements are indicative of inconsistency among requirements associated with the one or
more change requests.
BRIEF DESCRIPTION OF THE DRAWINGS
[0007] The detailed description is described with reference to the accompanying
figures. In the figures, the left-most digit(s) of a reference number identifies the figure in
which the reference number first appears. The same numbers are used throughout the
drawings to reference like features and components.
[0008] Figure 1 illustrates a network implementation of a system for managing change
requests associated with a software application is shown, in accordance with an embodiment
of the present subject matter.
4
[0009] Figure 2 shows a flowchart illustrating a method for managing change requests
associated with a software application, in accordance with an embodiment of the present
subject matter.
DETAILED DESCRIPTION
[0010] Systems and methods for managing change requests for software applications
are described. As mentioned above, the change requests are indicative of change orders being
initiated either by a user or by a software developer, such as an Information Technology (IT)
organization to modify a software application for satisfying one or more requirements of the
user or of the IT organization that developed the software application. The change requests
are required to be effectively managed from a planning phase to a delivery phase. However,
conventional systems do not provide for end to end management of the change requests. The
conventional systems either focus on the planning phase or on the delivery phase, thereby
leading to format issues when data is transferred from a tool associated with the planning
phase to a tool associated with the delivery phase. Further, as different tools or systems are
used for the planning phase and for the delivery phase, issues relating to compatibility of
tools, format dependency, excessive human intervention, communication from one tool to
another, and the like are encountered by the IT organization while implementing the change
requests. The following description has been provided from the purview of an IT
organization. However, the same would also be equally applicable for other organizations or
groups of individual users who are developing one or more software applications.
[0011] As would also be appreciated by a person skilled in the art, one or more change
requests may result in code which may eventually implement the desired functionality. Such
change requests are implemented in one or more software modules. The software modules
when implemented with the desired change requests may further interact with other software
modules. It may also happen that as a result of implementing the change requests, the
functionality of other software module may get affected. Such change requests can be
considered to be conflicting with the functioning of the previously existing modules. In this
case, such conflicts should be determined before implementing such changes requests.
5
[0012] Conventional systems do not perform impact analysis of the change requests.
Impact analysis is generally performed manually. Impact analysis may include identifying
conflicting requirements that may arise as a result of implementing functionalities associated
with the change request when considered in conjunction with previously existing components
or functionalities.
[0013] The conflict may arise due to a single change request and or when multiple
change requests are involved, between multiple change requests. Impact analysis may enable
the IT organization to completely understand the impact of the change requests on various
components or modules of the software application. It may be understood that incapability of
conventional systems to perform impact analysis may lead to inefficient and tedious
implementation of the change requests.
[0014] In order to effectively and efficiently manage the change requests, the present
subject matter provides an end to end system for managing the change requests from the
planning phase to the delivery phase along with a capability of performing impact analysis
and reporting of the change requests. For example, a user of a software application may wish
to get 20 changes implemented in a software application being developed by the IT
organization. In order to implement all the 20 changes effectively, a change request
corresponding to each change required by the user may be generated. In one example, a
change request may be in a form of a document illustrating the change required by the user.
[0015] In order to implement these change requests efficiently, each of these change
requests needs to be managed effectively in three phases, namely, a planning phase, an impact
analysis phase, and a delivery phase. In one implementation, certain data relating to the
change requests may be provided to a system. At first, the data may be provided for the
planning phase. The data provided to the system during the planning phase may be referred to
as change planning information and may include information related to planning of
implementation of the change requests.
[0016] In one implementation, while providing the information in the planning phase,
the employee of the IT organization may provide information pertaining to requirement
gathering, development, testing, production, documentation, etc., associated with each of the
6
change requests. The information may also include identification of requirements,
components, and scripts associated with each change request. In other words, as each change
request may be associated with a set of requirements, a set of components, and a set of scripts;
such information may also be provided to the system during the planning phase. The set of
requirements include one or more tasks to be performed for implementation of a change
request; the set of components include one or more software components which may be
affected due to implementation of that change request; and the set of scripts include one or
more scripts associated with delivery of components related to the change requests.
[0017] After various data pertaining to the planning phase is provided to the system,
impact analysis of the change requests may be performed by the system in the next phase, i.e.,
the impact analysis phase. The impact analysis may be performed to assess and identify one
or more conflicting requirements that may arise due to implementation of the change requests.
The conflicts may arise due to a conflict between one or more requirements that are associated
with the change requests. Conflicting requirements are the requirements that may conflict
with one another due to implementation of one or more change requests. In other words,
conflicting requirements are indicative of inconsistency among the requirements present in the
set of requirements.
[0018] In one implementation, once one or more change requests are received, one or
more requirements, components, and scripts associated with the one or more change requests
are determined. Once all such information is determined, conflicting requirements may be
determined based upon at least one of requirement descriptions, components, and scripts.
After the conflicting requirements are determined, the same can be provided to the user. Once
the conflict has been notified to the user, one or more corrective actions can be implemented
by the user to resolve the conflict.
[0019] In one implementation, impact analysis may be performed for inter-change
dependency and intra-change dependency. Impact analysis for inter-change dependency may
refer to identifying conflicting requirements associated with implementation of several change
requests, whereas, impact analysis for intra-change dependency may refer to identifying
conflicting requirements associated with implementation of a single change request. It may be
understood that impact analysis for inter-change dependency may be performed across
7
releases and/or clusters, whereas impact analysis for intra-change dependency may be
performed within the same release and/or cluster.
[0020] Further, impact analysis for inter-change dependency to identify conflicting
requirements may be performed based upon requirement description, or components, or
scripts, or by using any combination of these as explained below. Similarly, impact analysis
for intra-change dependency to identify conflicting requirements may be performed based
upon requirement description, or components, or scripts, or by using any combination of these
as explained below. It may be understood that impact analysis may help to reduce time,
human dependency, and effort that may be spent in implementing the change requests.
[0021] Therefore, it may be understood that the present subject matter facilitates a 360
degree planning and delivery mechanism of change requests as the system includes all
information related to various dates, deadlines, statuses, developer names, components
affected, resource allocation, task to resource mapping, and effort utilization, delivery of
scripts and any other information that may pertain to the planning phase, impact analysis
phase, and delivery phase. Since all the data associated with the change requests is maintained
within the system, impact analysis and reporting becomes very easy for the technical and
functional users thus saving time and effort for the clients and for the IT organization. All
these features enable effective planning, tracking, completion, and delivery of the components
associated with the change requests.
[0022] While aspects of described system and method for administration of change
requests may be implemented in any number of different computing systems, environments,
and/or configurations, the embodiments are described in the context of the following
exemplary system.
[0023] Referring now to Figure 1, a network implementation 100 of a system 102 for
managing one or more change requests associated with a software application is illustrated, in
accordance with an embodiment of the present subject matter. In one embodiment, the system
102 provides for comprehensive management of change requests from a planning phase to a
delivery phase. Although the present subject matter is explained considering that the system
102 is used by an Information technology (IT) organization, it may be understood that the
8
system 102 may be used by any other person/organization for managing change requests
associated with software applications.
[0024] The system 102 may be implemented in a variety of computing systems, such
as a laptop computer, a desktop computer, a notebook, a workstation, a mainframe computer,
a server, a network server, and the like. It will be understood that the system 102 may be
accessed by stakeholders through one or more client devices 104-1, 104-2,…104-N,
collectively referred to as client devices 104 hereinafter, or applications residing on client
devices 104. Examples of the client devices 104 may include, but are not limited to, a portable
computer, a personal digital assistant, a handheld device, and a workstation. The client
devices 104 are communicatively coupled to the system 102 through a network 106.
[0025] In one implementation, the network 106 may be a wireless network, a wired
network or a combination thereof. The network 106 can be implemented as one of the
different types of networks, such as intranet, local area network (LAN), wide area network
(WAN), the internet, and the like. The network 106 may either be a dedicated network or a
shared network. The shared network represents an association of the different types of
networks that use a variety of protocols, for example, Hypertext Transfer Protocol (HTTP),
Transmission Control Protocol/Internet Protocol (TCP/IP), Wireless Application Protocol
(WAP), and the like, to communicate with one another. Further the network 106 may include
a variety of network devices, including routers, bridges, servers, computing devices, storage
devices, and the like.
[0026] In one embodiment, the system 102 may include at least one processor 108, an
I/O interface 110, and a memory 112. The at least one processor 108 may be implemented as
one or more microprocessors, microcomputers, microcontrollers, digital signal processors,
central processing units, state machines, logic circuitries, and/or any devices that manipulate
signals based on operational instructions. Among other capabilities, the at least one processor
108 is configured to fetch and execute computer-readable instructions stored in the memory
112.
[0027] The I/O interface 110 may include a variety of software and hardware
interfaces, for example, a web interface, a graphical user interface, and the like. The I/O
9
interface 110 may allow the system 102 to interact with a user directly or through the client
devices 104. Further, the I/O interface 110 may enable the system 102 to communicate with
other computing devices, such as web servers and external data servers (not shown). The I/O
interface 110 can facilitate multiple communications within a wide variety of networks and
protocol types, including wired networks, for example, LAN, cable, etc., and wireless
networks, such as WLAN, cellular, or satellite. The I/O interface 110 may include one or
more ports for connecting a number of devices to one another or to another server.
[0028] The memory 112 may include any computer-readable medium known in the art
including, for example, volatile memory, such as static random access memory (SRAM) and
dynamic random access memory (DRAM), and/or non-volatile memory, such as read only
memory (ROM), erasable programmable ROM, flash memories, hard disks, optical disks, and
magnetic tapes. The memory 112 may include modules 114 and data 116.
[0029] The modules 114 include routines, programs, objects, components, data
structures, etc., which perform particular tasks or implement particular abstract data types. In
one implementation, the modules 114 may include a planning module 118, an impact analyzer
120, a delivery module 122, a reporting module 124, and other modules 126. The other
modules 126 may include programs or coded instructions that supplement applications and
functions of the system 102.
[0030] The data 116, amongst other things, serves as a repository for storing data
processed, received, and generated by one or more of the modules 114. The data 116 may also
include a change request database 128 and other data 130. The other data 130 may include
data generated as a result of the execution of one or more modules in the other module 126.
[0031] In one implementation, an employee, such as a software developer of the IT
organization may input certain data associated with the change requests into the system 102.
The data may be input into the system 102 using the I/O interface or by using one or more
client devices 104. The change requests may be associated with a software application being
developed by the IT organization. As mentioned earlier, the change requests are indicative of
modifications or changes that are to be made in the software application. Change requests
may originate either due to user’s requirements or due to change in technology or due to any
10
other reason. In one example, to accommodate all the needs and requirements of the user as
well of the IT organization, 20 change requests may be generated to modify the software
application.
[0032] In order to implement these change requests efficiently, each of these change
requests needs to be managed effectively in three phases, namely, a planning phase, an impact
analysis phase, and a delivery phase.
PLANNING PHASE
[0033] At first, the data may be provided for the planning phase. The data provided to
the system by an employee of the IT organization during the planning phase may be referred
to as change planning information and may include information related to planning of
implementation of the change requests. In one implementation, the change planning
information may be received by the planning module 118. The planning module 118 may
provide a framework for methodically segregating the change planning information. The
change planning information may include change request information (shown in Table 1A),
capacity planning information (shown in Table 1B), work break down structure information
(shown in Table 1B), change phase wise schedule information (shown in Table 3), intra
change request dependency information (shown in Table 4), and inter-change request
dependency information (shown in Table 5). The change planning information may be stored
in the change request database 128 in form of Tables 1-5.
[0034] As mentioned above, Table 1A includes change request information. The
change request information may include change name, change version number, requirement
description, deployment end date, priority, such as low, medium or high, detailed impact
analysis (IA) information, for example, impact done by, components of the software
application being impacted, IA status, IA start date, IA end date, IA hours and the like as
shown in Table 1A. The change version number may be used for tracking the history of
changes due to functional requirement changes or production issues and also for compliance.
The change request information may further include a) detailed development information,
such as developer name, status, start date, end date, hours, and the like; b) detailed testing
11
information, such as tester name, status, start date, end date, hours, number of defects, defects
assigned to, number of hours, and the like; and c) detailed documentation information, such as
documenter, status, start date, end date, hours, and the like.
Table 1A: Change Request Information
Serial No
Change
Description
Priority
Status
Impact Done By
Impact
Analysis (IA)
Start Date
IA End Date
IA Hours
IA Status
1 CR1 test1 High Development ABC 1-Mar-12 31-Mar-12 10 Completed
2 CR2 test2 Medium
System
Integration
Testing
XYZ 1-Mar-12 31-Mar-12 8 Completed
[0035] Referring now to Table 1B, the capacity planning information and work breakdown
structure information are shown. The capacity planning information may include
number of employees/resources, role of each resource, i.e., developer, tester, manager, etc;
and allocation details. Further, Table 1B also includes the work breakdown structure
information which includes information related to task allocated to each resource, for
example, impact analysis done by, developer, tester, documenter; hour allocation, status, such
as not started, in progress, or completed; and priority, such as low, medium, or high. Further,
the work breakdown structure information also provides a scope of work which is divided into
tasks and distributed amongst employees in a project and tracked to completion for successful
project completion.
12
Table 1B: Capacity Planning Information and Work Break-down Structure Information
Developer
Dev Start Date
Dev End Date
Dev Hours
Unit Testing Hours
Total Hours
Dev Status
Tester
SIT Start Date
SIT End Date
SIT Hours
No Of Defects
Assigned To
Rework Hours
SIT Status
Documenter
Doc Start Date
Doc End Date
Doc Hours
Doc Status
ABC
1-Apr-12
30-Apr-12
24
10
34
Completed
XYZ
1-Jun-12
30-Jun-12
5
1
ABC
2
Completed
ABC
01-Dec-12
31-Dec-12
0
Not Started
XYZ
1-May-12
31-May-12
0
0
0
Not
Started
ABC
1-Jun-12
30-Jun-12
0
0
XYZ
0
Not
Started
ABC
01-Dec-12
31-Dec-12
10
Not
Started
[0036] Referring now to Table 2, information related to components and scripts
associated with the change requests is shown. It may be understood that the change planning
information may also include information pertaining to a set of requirements, a set of
components, and a set of scripts associated with each change request. Such information may
also be provided to the system during the planning phase. The set of requirements include one
or more tasks to be performed for implementation of a change request; the set of components
include one or more software components which may be affected due to implementation of
that change request; and the set of scripts include one or more scripts associated with delivery
of the component pertaining to the change requests. For example, a change request CR1 may
be associated with a set of requirements, such as R1, R2, and R3, a set of components C1, C2,
C3, and a set of scripts S1, S2, and S3. This means that the IT organization needs to fulfill
requirements R1, R2, and R3 in order to implement the change request CR1; and in a process
of fulfilling these requirements, the components C1, C2, and C3 of the software application
may get affected. Based upon the implementation of the requirements, the deliverables, i.e.,
the scripts S1, S2, and S3 may also get associated with the change request CR1.
13
[0037] Further, each requirement in the set of requirements is explained using a
requirement description, thereby creating a set of requirement description corresponding to
each set of requirements. In one implementation, the requirement description explains the
requirement in a standardized manner so as to enable the IT organization to fulfill the
requirements effectively. The information pertaining to the components and scripts is shown
in Table 2, whereas the information pertaining to the requirements and requirement
description is shown in Tables 4 and 5 below.
Table 2: Information related to Components and Scripts associated with the change requests
Serial Number
Change Request/
Production
Incident
Description
Developer
Components
Used
Component
Type
Operation
Performed
File Name
/ Script Name
1 CR101 test1 ABC
test1_odc
Oracle
Database
Component
Created
test1_tab.tab
test1_drp.drp
test1_vw.vw
test1_sqs.sqs
test1_con.con
test1_pks.pks
test1_pkb.pkb
test.syn.syn
2 CR102 test2 XYZ
test2_odc
Oracle
Database
Component
Created
test2_tab.tab
test2_sql.sql
test3_fmx Screen Created
test3_fmx.fmx
test3_mnu.mmx
test1_odc
Oracle
Database
Component
Created
test2.fmx
14
[0038] Referring now to Table 3, the change phase wise schedule information is
shown. The change phase wise schedule information may include phase name, such as
requirement gathering, impact analysis (IA), development, system integration testing (SIT),
functional acceptance testing, user acceptance testing, production, documentation, and the
like. The change phase wise schedule information may also include planned start and end
date, actual start and end date, schedule slippage information, i.e., whether the planned dates
were missed, and phase status, i.e., not started, in progress, and completed. The phases
mentioned above are similar to the ones used in a Software Development Life Cycle (SDLC)
and are used for each change request as well for proper planning and implementation of the
change requests. Further, the phases mentioned in the change phase wise schedule
information are well known in the art, and therefore, for the sake of brevity, the phases are not
explained herein.
Table 3: Change Phase Wise Schedule Information
Serial No
Phase Information
Planned Start Date
Planned End Date
Actual Start Date
Actual End Date
Status
Schedule Slippage
Slippage Percentage ( in %)
1 Requirement Gathering 1-Jan-12 29-Feb-12 1-Jan-12 29-Feb-12 Completed No 0%
2 Impact Analysis 1-Mar-12 31-Mar-12 1-Mar-12 31-Mar-12 Completed No 0%
3 Development 1-Apr-12 31-May-12 1-Apr-12 In
Progress No 0%
4 System Integration
Testing 1-Jun-12 30-Jun-12 Not
Started No 0%
5 Functional Acceptance
Testing 1-Jul-12 31-Jul-12 Not
Started No 0%
6 User Acceptance
Testing 1-Aug-12 31-Oct-12 Not
Started No 0%
7 Production 1-Nov-12 30-Nov-12 Not
Started No 0%
8 Documentation 1-Dec-12 31-Dec-12 Not
Started No 0%
15
[0039] Referring now to Table 4, the intra-change dependency information is shown.
The intra-change dependency information, as shown in Table 4, as provided by the employee
of the IT organization, may show dependency of requirements on one another within the same
change request. The dependency of requirements on one another is indicative of conflicting
requirements. As can be seen from Table 4, information related to a cluster, a release,
requirements, requirement descriptions, conflicting requirements, components, and scripts
associated with a single change request is present. For example, it may be observed from
Table 4 that the change request CR5 is associated with cluster 2 and release 3. Further, change
request CR5 is associated with 6 requirements namely, R5.1, R5.2, R5.3, R5.4, R5.5, and
R5.6. Further, Table 4 shows that the change request CR5 may have conflicting requirements
within itself. The conflicting requirements in intra-change dependency may be determined
during the impact analysis phase as explained below.
16
Table 4: Intra change request dependency information
1 2 3 4 5 6 7 8 9 10 11 12
S.NO
Cluster
Release
Change Request
Requirement
Requirement description
Intra-change Request Dependency
Requirement
Dependency
Component
Dependency
Script
Dependency
Conflicting
Requirement
Requirement
Description
Conflicting
Requirement
Component
Conflicting
Requirement
Script
1
Cluster 2
Release 3
CR 5
R
5.1
Requirement 1
R 5.2
Require
ment 2
R 5.2 Test 1 R 5.2 Test_1.sql
R 5.3
Require
ment 3
None None None None
None None R 5.1 Test 1 None None
None None None None R 5.1 Test_1.sql
R
5.2
Require
ment 2
R 5.1
Require
ment 1
R 5.1 Test 1 R 5.1 Test_1.sql
R
5.3
Require
ment 3
R 5.1
Require
ment 1 None None None None
R
5.4
Require
ment 4
None None R 5.1 Test 1 None None
R
5.5
Require
ment 5 None None None None R
5.1 Test_1.sql
R
5.6
Require
ment 6
None None None None None None
[0040] Referring now to Table 5, the inter-change dependency information is shown.
The inter-change dependency information, as shown in Table 5, may show how several
change requests are interlinked or interdependent on one another across releases and clusters.
17
In other words, Table 5 shows relationship of change request CR5 present in cluster 2/release
3 with change requests CR1 and CR4 of cluster 1/release 1 and 2. Further, as can be seen
from Table 5, information related to a cluster, a release, requirements, requirement
descriptions, conflicting requirements, components, and scripts associated with the change
request CR5 and its dependency on change requests CR1 and CR4 is shown. Further, Table 5
shows that the change request CR5 may have conflicting requirements with other change
requests, such as CR1 and CR4. The conflicting requirements in inter-change dependency
may be determined during the impact analysis phase as explained below.
18
Table 5: Inter change request dependency information
1 2 3 4 5 6 7 8 9 10 11 12 13 14
Cluster
Release
Change
Request
Requirement
Requirement
description
Inter-change Request Dependency
Cluster
Release
Change
Request
Requirement
Dependency
Compone
nt
Depende
ncy
Script
Dependency
Conflicting
Requirement
Requirement
Description
Conflicting
Requirement
Component
Conflicting
Requirement
Script
Cluster 2
Release 3
CR
5
R
5.
1
Requirement 1
Clust
er 1
Rele
ase 1
CR
1
R
1.2
Requirem
ent 2
R
1.1
Tes
t 1
R
1.1
Test_1
.sql
Clust
er 1
Rele
ase 1
CR
1
R
1.3
Requirem
ent 3
No
ne
No
ne
No
ne None
Clust
er 1
Rele
ase 2
CR
4
No
ne None R
4.1
Tes
t 1
No
ne None
Clust
er 1
Rele
ase 2
CR
4
No
ne None No
ne
No
ne
R
4.2
Test_1
.sql
R
5.
2
Requirement 2
Clust
er 1
Rele
ase 1
CR
1
R
1.2
Requirem
ent 2
R
1.1
Tes
t 1
R
1.1
Test_1
.sql
Clust
er 1
Rele
ase 1
CR
1
R
1.3
Requirem
ent 3
No
ne
No
ne
No
ne None
Clust
er 1
Rele
ase 2
CR
4
No
ne None R
4.1
Tes
t 1
No
ne None
Clust
er 1
Rele
ase 2
CR
4
No
ne None No
ne
No
ne
R
4.2
Test_1
.sql
R
5.
3
Require
ment 3
Clust
er 1
Rele
ase 1
CR
1
R
1.2
Requirem
ent 2
R
1.1
Tes
t 1
R
1.1
Test_1
.sql
Clust
er 1
Rele
ase 1
CR
1
R
1.3
Requirem
ent 3
No
ne
No
ne
No
ne None
R
5.
4
Require
ment 4
Clust
er 1
Rele
ase 1
CR
1
R
1.2
Requirem
ent 2
R
1.1
Tes
t 1
R
1.1
Test_1
.sql
Clust
er 1
Rele
ase 2
CR
4
No
ne None R
4.1
Tes
t 1
No
ne None
R
5.
5
Require
ment 5
Clust
er 1
Rele
ase 1
CR
1
R
1.2
Requirem
ent 2
R
1.1
Tes
t 1
R
1.1
Test_1
.sql
Clust
er 1
Rele
ase 2
CR
4
No
ne None No
ne
No
ne
R
4.2
Test_1
.sql
19
R
5.
6
Require
ment 6
None Non
e
No
ne
No
ne None No
ne
No
ne
No
ne None
IMPACT ANALYSIS PHASE
[0041] Subsequent to gathering of change planning information in form of Tables 1-5
by the planning module 118, impact analysis may be performed by the impact analyzer 120.
The impact analyzer 120 may use the change planning information, and specifically, the inter
and intra-change dependency information (as shown in Tables 4 and 5) to perform impact
analysis in the impact analysis phase. The impact analysis may be performed to assess and
identify one or more conflicting requirements. Conflicting requirements are the requirements
that may conflict with one another due to implementation of one or more change requests. In
other words, conflicting requirements are indicative of inconsistency among the requirements
associated with one or more change requests.
[0042] In one implementation, impact analysis may be performed for intra-change
dependency and inter-change dependency. Impact analysis for intra-change dependency may
refer to identifying conflicting requirements associated with implementation of a single
change request, whereas impact analysis for inter-change dependency may refer to identifying
conflicting requirements associated with implementation of several change requests within
releases/clusters and/or across releases/clusters.
[0043] Further, impact analysis for intra-change dependency to identify conflicting
requirements may be performed based upon requirement description, or components, or
scripts, or by using any combination of these. Similarly, impact analysis for inter-change
dependency to identify conflicting requirements may be performed based upon requirement
description, or components, or scripts, or by using any combination of these.
[0044] In one implantation, the impact analysis for intra-change dependency to
identify conflicting requirements may be explained in the following example. In this example,
the conflicting requirements may be determined by comparing requirement descriptions of
one or more requirements present in the same set of requirements. In the present
implementation, the impact analyzer 120 may compare the requirement descriptions
associated with a single change request to identify conflicting requirements. For example, the
20
impact analyzer 120 may analyze Table 4 to identify that the requirement R5.1 in column 5 is
conflicting with requirement R5.2 and R5.3 shown in column 7. Similarly, the impact
analyzer 120 may compare the components and/or scripts associated with the same change
request CR5 to identify conflicting requirements based upon components and scripts as shown
in Table 4.
[0045] Similarly, in another example, impact analysis for intra-change dependency to
identify conflicting requirements based only upon components may be explained with the
help of following example. Let us consider that in this example, the change request CR7 has
requirement R1 and R2 to be fulfilled for implementation of the said change request CR7. It
may be observed from intra-change dependency information that both of these requirements
R1 and R2 may necessitate a different change on component C1. In other words, components
affected by different requirements associated with the same change request are compared for
identification of conflicting requirements. Therefore, it may be understood that, as different
requirements are necessitating different task or activity to be performed on the component C1,
there exist conflicting requirements.
[0046] Similarly, the impact analysis for inter-change dependency to identify
conflicting requirements may be explained in the following example. In this example, the
conflicting requirements may be determined by comparing requirement description associated
with a change request with requirement description associated with another change request. In
one implementation, the impact analyzer 120 may compare the requirement descriptions
associated with two or more change requests to identify conflicting requirements. For
example, as shown in Table 5, requirement R5.1 in column 4 is conflicting with requirement
R1.2 and R1.3 shown in column 9. Similarly, the impact analyzer 120 may compare the
components and/or scripts associated with two or more change requests to identify conflicting
requirements as shown in Table 5.
[0047] Similarly, in another example, impact analysis for inter-change dependency to
identify conflicting requirements based only upon the components associated with the change
requests may be explained with the help of following example. Let us consider that in one
example, the change request CR8, affects the components C1, C2, and C3; and the change
request CR9 affects the components C3, C4, and C5. After performing the impact analysis for
21
inter-change dependency, the IT organization would know that there subsist a conflicting
requirement between the change requests CR8 and CR9 as there exist a component C3 that is
affected by implementation of both the change requests CR8 and CR9. In other words,
components affected by different requirements associated with different change requests are
compared for identification of conflicting requirements. This information may prove useful to
the IT organization while it is implementing the change requests.
[0048] Therefore, it may be understood that the impact analyzer 120 may identify
conflicting requirements within multiple change requests and within a single change request
to assist the IT organization to better manage and implement the change requests.
DELIVERY PHASE
[0049] Subsequent to the receiving of the change planning information and
performing the impact analysis, the system 102 may receive the delivery management
information associated with the change requests. In one implementation, the delivery module
122 may receive the delivery management information. The delivery module 122 provides a
framework for methodically segregating the delivery management information. The delivery
management information may include delivery tracking information, delivery components
information, component files information, a database to tabulate and organize components,
and output files in terms of deployment scripts.
[0050] The delivery tracking information is associated with tracking of deliveries,
such as code, deployment scripts, and the like associated with the change requests. In one
implementation, the delivery tracking information may include delivery components
associated with the change requests, files associated with the components, hierarchical
relationship between change requests, components, and files; wherein change requests are
parent node, components are corresponding child node and corresponding files are leaf nodes.
[0051] Similarly, the delivery components information may include component name,
type of component i.e., database, non database, screen, menu, etc., operation performed i.e.,
created, deleted, updated, and the like. Similarly, component files information may include
file name, file extension, and status in different environment like development, testing, and
22
production. The status may be one of a) not started, b) yet to be deployed, c) confirmed.
Further, the database to tabulate and organize components may include change name, version,
and description, list of components associated with each change request, component name,
type and operation, list of files associated with each change request, file name, extension and
status in different environments. Further, the output files in terms of deployment scripts may
include deployment master script and SQL scripts.
[0052] Subsequent to receiving all the data associated with the planning phase and the
delivery phase by the system 102, the reporting module 124 may use the data to generate
reports at any time of the planning phase and/or the delivery phase to know a real time status.
The reports may include at least in part the change planning information and the delivery
management information. In one implementation, the reports may include any information
shown in Tables 1-5 and may be stored in the change request database 128.
[0053] Further, the reporting module 124 may also create a three-dimensional
traceability database. The three-dimensional traceability database may include change request
structure, inter change request dependency information as shown in Table 4, and intra change
request dependency information as shown in Table 5. In one implementation, the threedimensional
traceability database is maintained in the change request database 128.
[0054] The change request structure present in the three-dimensional traceability
database is indicative of releases and clusters associated with the one or more change
requests. As it is understood that change requests may be small, medium, or large; and
therefore these change requests of various sizes are often clubbed into releases and the
releases are clubbed into clusters while delivering the scripts. Deliverables for each change
request, release, or cluster is maintained by the delivery module 122.
[0055] Therefore, it may be understood that the system 102 may be used for managing
the change requests from the planning phase to the delivery phase along with a capability of
performing impact analysis and reporting of the change requests. Further, the system 102
allows the IT organization to easily merge change requests into releases and releases into
clusters. Furthermore, the system 102 provides for any time reporting with any number fields
23
preferred by the IT organization. Moreover, the system 102 helps in reducing dependency on
subject matter experts for managing the change requests.
[0056] Referring now to Figure 2, a method 200 for managing change requests
associated with a software application is shown, in accordance with an embodiment of the
present subject matter. The method 200 may be described in the general context of computer
executable instructions. Generally, computer executable instructions can include routines,
programs, objects, components, data structures, procedures, modules, functions, etc., that
perform particular functions or implement particular abstract data types. The method 200 may
also be practiced in a distributed computing environment where functions are performed by
remote processing devices that are linked through a communications network. In a distributed
computing environment, computer executable instructions may be located in both local and
remote computer storage media, including memory storage devices.
[0057] The order in which the method 200 is described is not intended to be construed
as a limitation, and any number of the described method blocks can be combined in any order
to implement the method 200 or alternate methods. Additionally, individual blocks may be
deleted from the method 200 without departing from the spirit and scope of the subject matter
described herein. Furthermore, the method can be implemented in any suitable hardware,
software, firmware, or combination thereof. However, for ease of explanation, in the
embodiments described below, the method 200 may be considered to be implemented in the
above described system 102.
24
[0058] At block 202, change planning information is received for the one or more
change requests in the first phase, i.e., the planning phase. The one or more change requests
are indicative of modifications to be made in the software application. Further, the change
planning information comprises information pertaining to a set of requirements, a set of
components, and a set of scripts. The set of requirements includes requirements to be met for
implementation of the each change request. Each requirement in the set of requirements is
explained using a requirement description, thereby creating a set of requirement descriptions
corresponding to the set of requirements. The set of components includes components being
affected by the implementation of the each change request. The set of scripts includes scripts
associated with delivery of the set of components.
[0059] The change planning information may further include information related to
planning of implementation of the change requests. In one implementation, the change
planning information may include at least one of change request information, phase wise
schedule information, capacity planning information, inter-change request dependency
information, intra-change request dependency information, and work breakdown structure
information. The change planning information may be stored in the change request database
128 in form of Tables 1-5 shown above. In one implementation, the change planning
information may be received by the planning module 118.
[0060] After receiving the change planning information, impact analysis of the one or
more change requests is performed in the second phase, i.e., the impact analysis phase. The
impact analysis may be performed to assess and identify one or more conflicting
requirements. Conflicting requirements are the requirements that may conflict with one
another due to implementation of one or more change requests. In other words, conflicting
requirements are indicative of inconsistency among the requirements associated with one or
more change requests.
[0061] The impact analysis is performed in two steps as illustrated in blocks 206 and
208. At block 206, the first step of the impact analysis is performed. The first step includes
comparing at least one of requirement descriptions with requirement descriptions, components
with components, and scripts with scripts associated with the one or more change requests to
25
facilitate impact analysis. In one example, the comparison is performed by the impact
analyzer 120.
[0062] At block 208, the second step of impact analysis is performed. The second step
includes identifying one or more conflicting requirements associated with one or more change
requests based upon the comparison of at least one of the requirement descriptions, the
components, and the scripts.
[0063] It may be understood that impact analysis may be performed for intra-change
dependency and for inter-change dependency. Impact analysis for intra-change dependency is
performed to identify conflicting requirements within a single change request, whereas impact
analysis for inter-change request is performed to identify conflicting requirements within
several change requests within and/or across releases/clusters as explained above. In one
example, the one or more conflicting requirements are identified by the impact analyzer 120.
[0064] At block 210, delivery management information may be received for the one or
more change requests. The delivery management information pertains to delivery of scripts
associated with the change requests. The delivery management information comprises at least
of delivery tracking information, delivery components information, component files
information, a database to tabulate and organize components, and output files. In one
implementation, the delivery management information may be received by the delivery
module 122.
[0065] At block 212, one or more reports associated with the change requests is
generated. The reports may include at least in part the change planning information and the
delivery management information. Further, the reports may include real time statuses and
other information related to the planning phase and the delivery phase of the change requests.
In one implementation, the reports may be stored in the change request database 128. Further,
the reports may be generated by the reporting module 124.
[0066] Although implementations for methods and systems for managing change
requests associated with a software application have been described in language specific to
structural features and/or methods, it is to be understood that the appended claims are not
necessarily limited to the specific features or methods described. Rather, the specific features
26
and methods are disclosed as examples of implementations for managing the change requests
associated with a software application.
27
I/We claim:
1. A system (102) for managing one or more change requests associated with a software
application, the one or more change requests are indicative of modifications to be
made in the software application, the system (102) comprising:
a processor (108); and
a memory (112) coupled to the processor (108), the memory (112) comprising
an impact analyzer (120) configured to perform impact analysis for the
one or more change requests, wherein the impact analyzer (120)
compares at least one of requirement descriptions associated
with the one or more change requests, components associated with the
one or more change requests, and scripts associated with the one or
more change requests; and
identifies one or more conflicting requirements associated with
the one or more change requests based upon the comparison, wherein
the one or more conflicting requirements are indicative of inconsistency
among requirements associated with the one or more change requests.
2. The system (102) of claim 1, further comprises a planning module (118) configured to
receive change planning information for each of the one or more change requests, the
change planning information comprises information pertaining to
a set of requirements to be met for implementation of the each of the one or
more change requests, wherein each requirement in the set of requirements is
explained using a requirement description, thereby creating a set of requirement
descriptions corresponding to the set of requirements,
a set of components being affected by the implementation of each of the one
or more change requests, and
a set of scripts associated with delivery of the set of components.
28
3. The system (102) of claim 2, wherein the change planning information further
comprises at least one of change request information, phase wise schedule
information, capacity planning information, work breakdown structure information,
inter-change request dependency information, and intra-change request dependency
information.
4. The system (102) of claim 2, further comprises a delivery module (122) configured to
receive delivery management information for the one or more change requests,
wherein the delivery management information is indicative of information associated
with delivery of the set of components.
5. The system (102) of claim 4, wherein the delivery management information comprises
delivery tracking information, delivery components information, component files
information, a database to tabulate and organize components, and output files in terms
of deployment scripts, and wherein the delivery module (122) is further configured to
provide a framework for methodically segregating the delivery management
information.
6. The system (102) of claim 3, wherein the memory (112) further comprises a reporting
module (124) configured to generate a report comprising at least in part the change
planning information and delivery management information.
7. The system (102) of claim 3, wherein the memory (112) further comprises a reporting
module (124) configured to create a three-dimensional traceability database
comprising at least one of a change request structure, inter-change request dependency
information, and intra-change request dependency information associated with the one
or more change requests.
29
8. The system (102) of claim 7, wherein the change request structure is indicative of
releases and clusters associated with delivery of the set of components of the one or
more change requests.
9. The system (102) of claim 1, wherein the one or more change requests are
hierarchically mapped with components, files, and scripts of the software application.
10. The system (102) of claim 2, wherein the planning module (118) is further configured
to provide a framework for methodically segregating the change planning information.
11. A method for managing one or more change requests associated with a software
application, the one or more change requests are indicative of modifications to be
made in the software application, the method comprising:
performing impact analysis for the one or more change requests, wherein
performing the impact analysis comprises
comparing at least one of requirement descriptions associated with the
one or more change requests, components associated with the one or more
change requests, and scripts associated with the one or more change requests,
wherein the requirement descriptions, the components, and the scripts are
stored in a change request database; and
identifying one or more conflicting requirements associated with the
one or more change requests based upon the comparison, wherein the one or
more conflicting requirements are indicative of inconsistency among
requirements associated with the one or more change requests.
12. The method of claim 11, further comprising receiving change planning information for
each of the one or more change requests, the change planning information comprises
information pertaining to
a set of requirements to be met for implementation of the each of the one or
more change requests, wherein each requirement in the set of requirements is
30
explained using a requirement description, thereby creating a set of requirement
descriptions corresponding to the set of requirements,
a set of components being affected by the implementation of each of the one or
more change requests, and
a set of scripts associated with delivery of the set of components.
13. The method of claim 12, wherein the change planning information further comprises
at least one of change request information, phase wise schedule information, capacity
planning information, work breakdown structure information, inter-change request
dependency information, and intra-change request dependency information.
14. The method of claim 13, further comprising generating a report comprising at least in
part the change planning information and delivery management information.
15. The method of claim 13, further comprising creating a three-dimensional traceability
database comprising at least one of a change request structure, inter-change request
dependency information, and intra-change request dependency information associated
with the one or more change requests.
16. The method of claim 11, wherein the impact analysis is performed for at least one of
multiple-change requests and single change request.
17. A computer-readable medium having embodied thereon a computer program for
executing a method for managing one or more change requests associated with a
software application, the one or more change requests are indicative of modifications
to be made in the software application, the method comprising:
performing impact analysis for the one or more change requests, wherein
performing the impact analysis comprises
comparing at least one of requirement descriptions associated with the
one or more change requests, components associated with the one or more
31
change requests, and scripts associated with the one or more change requests
wherein the requirement descriptions, the components, and the scripts are
stored in a change request database; and
identifying one or more conflicting requirements associated with the
one or more change requests based upon the comparison, wherein the one or
more conflicting requirements are indicative of inconsistency among
requirements associated with the one or more change requests.