FORM 2
THE PATENTS ACT, 1970
(39 of 1970)
&
THE PATENT RULES, 2003
COMPLETE SPECIFICATION
(See Section 10 and Rule 13)
Title of invention:
A SYSTEM AND METHOD FOR REAL-TIME TRACKING OF NUMBER
OF UNPLANNED RELEASES
Applicant:
Tata Consultancy Services Limited A company Incorporated in India under The Companies Act, 1956
Having address:
Nirma] Building. 9th Floor,
Nariman Point, Mumbai 400021,
Maharashtra, India
The following specification particularly describes the invention and the manner in which it is to be performed.

FIELD OF THE INVENTION
The invention generally relates to the field of software development lifecycle management. More particularly, the invention relates to a system and method for tracking the number of unplanned releases in release management process of software development.
BACKGROUND OF THE INVENTION
In a typical software development process, one of the important phases is software Quality-Assurance (SQA) phase. The software Quality-Assurance (SQA) phase encompasses the entire software development process, which includes processes such as software requirements specifications (SRS) definition, software design, coding, source code control, code reviews, change or modification management, configuration management, testing, release management, and product integration.
One of the key sub-processes in the software Quality-Assurance (SQA) phase is the release management process. In a typical release management process, the team involved needs to take a call on release of particular software and thereby manage or plan the further tasks and processes in the release of the software product. However, there are certain scenarios or cases wherein few of the software products need to be released which were actually not planned to release. Such scenarios or cases require management of unplanned release.
The release management therefore involves a well structured management process to deploy changes in the software product development environment. Such changes include items like fixing of bugs or errors, software and hardware upgrades, performance enhancements, and other changes. These changes may need to be incorporated due to many factors, including the need of maintaining accurate records. to prove data accuracy and final recall on the specifications etc. Changes are developed, tested, and packaged into releases for deployment. The change and release

management process of an organization is responsible for introducing these changes and managing their release.
A goal of a change and release management process is to ensure that all changes deployed successfully into the final software product ready for release in the least disruptive manner. A change and release management process includes determining the readiness of each release based on release criteria, including, for example, the quality of the release, release package and production environment readiness, training and support plans, rollout and backout plans, testing, and risk management plans. After planning and configuring a change, the change and release management process may include a change review to ensure that the release was successful.
The release management includes both planned and unplanned releases. It is critical to check the number of planned and unplanned releases. Tracking the number of unplanned release is a cumbersome task due to its dynamic nature of occurrence and the lack in communication between the development team initiating the unplanned release and the release management team managing the release management.
Further, the number of unplanned releases increases in a real-time according to different parameters in the software lifecycle management. For examples, such unplanned release may arise due to customer suggested enhancements, failure of SQA teams to manage or process the release, any planned release miss from the SQA team and other factors such as change is priorities etc. Therefore, this may result in large number of unplanned releases.
Generation of large number of unplanned releases may result in several problems. For example, if there are number of unplanned release requests received to software Quality-Assurance (SQA) team; there is always a possibility of some data loss at the release level itself. Further, as can be appreciated, due to receipt of multiple concurrent unplanned releases, it is difficult to track the status of each request.

In the background art, there are tools available that mainly provides information about various planned and unplanned releases by means of different metrics and dashboards.
Further, these tools are enabled to automatically differentiate the planned or unplanned release to track the status of each of these releases individually. However, it is difficult to retrieve various data on a weekly, monthly, and quarterly basis related to the planned or unplanned releases using such metrics and dashboards. This may in turn affect the tracking and smoothening of the entire delivery process. Also, the conventional tools cannot overcome the limitation on the number of unplanned releases that can be avoided based on certain pre-defined criteria such as priorities set to accommodate a particular set of unplanned release within a stipulated period.
Due to aforesaid problems resulted because of unplanned releases, commercial decision makers are generally keen to reduce the number of unplanned releases. Existing tools and systems do not easily facilitate data and metric gathering about the number of unplanned release and hence the data that is retrieved from these tools is inadequate. Therefore, the SQA team is unable to track and record the number of the unplanned releases received for release in the release management tool.
Therefore, in view of the above, it is clear that though there are conventional tools available in the art that enables tracking the status of the planned or unplanned releases, a problem of tracking actual number of unplanned releases needs to be
addressed.
More particularly, there is a long-felt need in the art for a technical solution that enables a tracking of number of unplanned releases generated during software Quality-Assurance (SQA) phase of the software development cycle.

OBJECTS OF THE INVENTION
The principal object of the present invention is to enable a system and method that facilitates real-time track of number of unplanned release in software development lifecycle.
Yet another object of the present invention is to enable a system and method for realtime generation of a unique token for each of the unplanned release request received from the software development team.
Yet another object of the present invention is to enable a system and method for verifying whether the said token generated has not been already generated for any of the previous unplanned releases.
Yet another object of the present invention is to enable a system and method that enables tracking the number of unplanned release based on the unique token generated and approved by the SQA team.
Still another object of the present invention is to enable a system and method to deploy the details of the unplanned release in a database for further tracking and future referencing.
SUMMARY OF THE INVENTION
Before the present methods, systems, and hardware enablement are described, it is to be understood that this invention is not limited to the particular systems, and methodologies described, as there can be multiple possible embodiments of the present invention which are not expressly illustrated in the present disclosure. It is also to be understood that the terminology used in the description is for the purpose of describing the particular versions or embodiments only, and is not intended to limit the scope of the present invention.

In one aspect, the present invention enables a system and method for real-time tracking of unplanned releases in software Quality Assurance (SQA) phase of the software development lifecycle. The system of the present invention comprises a deployment tracker module that is integrated with a release management module. The release management module receives request from the software development team. Once the request is received the said request needs to be approved by the team manager managing the SQA team. A unique token is automatically generated for the unplanned release request after the approval from the said team manager.
According to another aspect of the present invention, the deployment tracker module enables verification of whether the said token generated has been already utilized for any other release. Accordingly, if the token generated is detected as not been used earlier, then it is assigned for the received unplanned request. Also, the status of the token assigned is then displayed as used in the deployment tracker module.
In another aspect of the invention, the generation and assignment of the unique token to the unplanned releaser enables tracking the number of each of the approved unplanned releases in the software Quality Assurance (SQA) phase. This is possible due to the fact that for each unplanned release request, a unique token is generated and thus the number of such tokens can be monitored.
In still another aspect of the present invention, a database module, electronically coupled to the deployment tracker module enables deploying of the details of the approved unplanned release request such that the status of the unplanned release request is then displayed on the deployment tracker for future tracking and referencing.
Thus, the system and method of the present invention is not only limited to tracking the status of unplanned releases, but also enables real-time counting of each of the unplanned releases. This feature in turn allows the human resources of the software Quality Assurance (SQA) team to prove the number of unplanned release to the

higher management of the organization serving the customers with different software solutions.
BRIEF DESCRIPTION OF DRAWINGS
The foregoing summary, as well as the following detailed description of embodiments, is better understood when read in conjunction with the appended drawings. For the purpose of illustrating the invention, there is shown in the drawings example constructions of the invention; however, the invention is not limited to the specific methods and architecture disclosed in the drawings:
Figure 1 is a system block diagram (100) illustrating various system elements enabling real-time tracking of unplanned releases according to an exemplary embodiment of the invention.
Figure 2 is a block diagram (200) illustrating various components of the deployment tracker module according to an exemplary embodiment of the invention.
Figure 3 is a block diagram (300) illustrating user case diagram of the said deployment tracker module enabling tracking of the number of unplanned release according to an exemplary embodiment of the invention.
Figure 4 is a system diagram (400) illustrating a three-tier architecture implementing the tracking of number of unplanned releases according to an exemplary embodiment of the invention.
Figure 5(a) and 5(b) are flow diagrams (500) and (600) respectively illustrating various steps implemented for real-time tracking of unplanned releases according to an exemplary embodiment of the invention.

DETAILED DESCRIPTION:
The description has been presented with reference to various embodiments of the invention. Persons skilled in the art and technology to which this invention pertains will appreciate that alterations and changes in the described method and system of operation can be practiced without meaningfully departing from the principle spirit and scope of this invention.
Referring to figure 1 is system diagram (100) illustrating various system elements collectively arranged for real-time tracking of unplanned releases according to an exemplary embodiment of the invention.
As illustrated in figure 1, the system (100) comprises a release management module (101) integrated with a deployment trackeT module (102). Further, a database module (103) is displayed that is electronically coupled with the said deployment tracker module (102).
In an exemplary embodiment, the said release management module (101) is adopted to perform the tasks of entire release management process of the software development projects. In an exemplary embodiment, the release management module (101) is capable of receiving unplanned release request from the software development team. As shown, a user (104) from the software development team is' connected with the release management module (101) who may issue the said request for unplanned release in the release management module (101).
In an exemplary embodiment, the request for unplanned release is then received by a software quality-assurance team connected with the deployment tracker module (102) as illustrated in figure 1. In an exemplary embodiment, the task of the deployment tracker module (102) is to track the status of the received unplanned release requests from the release management tool (101). Figure 2 illustrates a block diagram (200)

displaying various components of the deployment tracker module according to an exemplary embodiment of the invention.
As illustrated in figure 2, the deployment tracker module comprises components including a web server (201) and database server (202). As shown, multiple users (203), (204), (205) from the different software development teams are shown that can interact with the web server (201). As illustrated in figure 2, the web server (201), and the database server (202) and the users (203), (204). (205) communicate electronically for enablement of deploying the details of unplanned releases. In an exemplary embodiment of the present invention, such communication exists between these components over a local-area network (LAN).
In an exemplary embodiment, as illustrated in figure 2, at least one of the said multiple users opens a web browser installed on the said web server (201) for accessing the deployment tracker application. Initially, the said user has to authenticate before logged in to the deployment tracker application. Depending on the role of each user, the privileges for accessing are assigned. For example, in an exemplary embodiment, if the user has a role of admin, then he/she is assigned the privileges to read, write and modify the content accessed through the application. On the contrary, if the user has a role of non-admin user, then he/she may be assigned limited privileges.
Referring to figure 1, as the deployment tracker module (102) receives the unplanned release request; the deployment tracker module initiates a tracking mechanism for the unplanned release. Figure 3 illustrates a use case diagram depicting the tracking of the number of unplanned release in accordance to an exemplary embodiment of the present invention.
As illustrated in figure 3. a manager (301) of the quality-assurance team in the form a user access the request received in the deployment tracker module (302) after successfully authenticated. The manager (301) then assesses the received unplanned

release request in accordance with pre-defined criteria so that it is approved for the release through software quality-assurance team. Such criteria on the basis of which the request for unplanned release is requested includes criticality of the request from the client point of view, size of the request in terms of efforts required for completion, and availability of resources etc. Therefore, based on these criteria, the manager approves the received unplanned request.
In an exemplary embodiment, the manager (301) based on the pre-defined criteria approves the request and clicks on the "Generate Token" button (303) in the deployment tracker module (302). As a result of this, a unique token is generated in the deployment tracker module (302) for the received unplanned request. In an exemplary embodiment, each time new unplanned release request is received, a unique token is generated in the deployment tracker module (302).
Referring to figure 1, once the unique token is generated for the unplanned release request, verification is required whether the token generated already exists for the other planned or unplanned releases. Therefore, a verification module (106) in the deployment tracker module (102) verifies that the generated token is unique and after such verification, the token generated is recorded in the database module (105) with updates status as used token.
In an exemplary embodiment, based on the verification of the token generated and thereby its updated status, the details of the unplanned release are then deployed in the database module (105) coupled to the deployment tracker module (102) for future tracking the status of the unplanned release. This can also be realized by referring to figure 3 illustrating a user case diagram for the deployment tracker module (302). As illustrated, after generation of the token (303), a QA team member (304) initiates the QA release details (305) and record the said details in the database module (105) shown in figure 1.

In an exemplary embodiment, the generation of unique token for each of the unplanned release enables tracking number of the said unplanned release. For example, each time unplanned release is received and approved, a unique token is generated in the deployment tracker module. Thus, the system enables counting of the actual number of unplanned releases and thereby facilitates real-time tracking of unplanned releases.
In an exemplary embodiment, the system (100) illustrated in figure 1 implements three-tier architecture for the tracking of number of unplanned releases in software quality-assurance phase of the software development process. Figure 4 illustrates the three-tier architecture diagram (400) displaying the three major layers implementing the tracking of unplanned releases in accordance with an exemplary embodiment of the present invention.
As illustrated in figure 4, the three-tier architecture includes a Graphical User Interface (GUI) layer (401), a Business Logic layer (402) and a Data Access Layer or DAL (403) respectively. In an exemplary embodiment, the said Graphical User Interface (GUI) layer (401) is implemented using ASP.Net platform, HTML and Java™ Script. The GUI layer (401) acts as an interface for users from the different software development teams in order to access the status details at each phase of the software development process.
In an exemplary embodiment, the said Business Logic Layer (402) implements plurality of business rules and procedures for enabling the tracking of number of unplanned release. For example, the Business Logic layer (402) implements rules and procedures that enables tracking receipt of unplanned release request, generation of a unique token for the said request after approval based on pre-defined criteria. verifying that the said token generated does not exists for any other release and deployment of the release details after verification in the database module for future tracking the status of the unplanned release. In an exemplar}' embodiment, the

Business Logic layer (402) is designed and developed using VB.Net platform and is isolated from the GUI layer (401). The GUI layer (401) is enabled to read or write data through Business Logic Layer (402).
In an exemplary embodiment, the Data Access Layer or DAL (403) performs the tasks of all data related operations and is electronically coupled to a data store (404) storing data related to unplanned releases. The DAL (403) is designed and developed using VB.Net and ADO.Net platforms. In an exemplary embodiment, the data store (404) is a MS SQL server 2005 express edition used as a database module. The GUI Layer (401) can't directly access data store (404) or DAL (403) and therefore it read/write data through the Business logic layer (402). Business logic layer (401) implements all the business rules of the application and read/write data through DAL (403) as it can't access directly to the data store (404).
Referring to figure 5(a) and 5(b) are flow diagrams illustrating various steps implemented for real-time tracking of unplanned releases according to an exemplary embodiment of the invention.
As illustrated in figure 5(a), at step (501), a request for unplanned release from software development team is received to SAQ team.
At step (502), meeting between SQA Manager and SQA team lead takes place for approving of the received unplanned release.
At step (503), determination of whether the received request is approved or not is done.
At step (504), if the request is approved, a token is generated for the requested unplanned release. If the request is not approved at step (503), the process is terminated.

At step (505), the token generated is created in the deployment tracker module for future tracking and referencing.
Referring to figure 5(b), at step (506), addition of unplanned release details is done in the deployment tracker module.
At step (507), determination of whether the token created is unused in the deployment tracker module is done.
At step (509), if it is determined at step (507) that the token created is unused, then the token created is recorded in the database module, else, the process is terminated at step (508) and displaying "Error Message"
At step (510), the status of the token created in the deployment tracker module is updated as "Used" in the database module for future referencing.
At step (511), a message depicting successful generation of token and thereby unplanned release approval is displayed. Finally, the process is terminated after successful deployment of unplanned release.
BEST ENABLED MODE:
In a preferred embodiment, consider an Information Technology (IT) organization catering software products to small and medium business (SMB) customers spread across of various domains involving separate set of stakeholders. Due to involvement of multiple stakeholders and customers of different domains or market segments, there is a constant push to add and enhance features to the existing software product from such customers and stakeholders. This may lead to multiple releases for the different products with many of them being unplanned to accommodate the request for new customers.
The increasing number of unplanned releases made it very tough to track the details very minutely. Therefore, in accordance with the preferred embodiment of the

present invention, a software quality-assurance (SQA) team of the IT organization implements a centralized deployment tracker module to facilitate centralized command over the unplanned releases. In the preferred embodiment, a control over the centralized deployment tracker module enables the QA manager of the SQA team to take judicious decision after consulting with the team and other involved stakeholders of the SMBs whether or not to take the unplanned release to QA for testing. In the preferred embodiment, the QA manager takes this decision based on pre-defined criteria that includes criticality of the request for the unplanned release, efforts required to serve the request and resource availability for serving the request etc.
In the preferred embodiment, the QA manager performs the role of 'webadmin' in the Deployment Tracker module and has all the privileges to read, write and modify the data in the deployment tracker module. In the preferred embodiment, the QA manager approves the unplanned release request for QA testing after discussion with team members and considering the priorities of the stakeholders in the SMB segment for whom the software products are to be developed by the IT organization.
In the preferred embodiment, as a result of approval of the unplanned release request, the QA manager clicks on the "Generate Token" button in the deployment tracker module that results in automatic generation of a unique number referred to as the TOKEN. In the preferred embodiment of the present invention, only after the creation of the TOKEN, the QA test team leader is enabled for entering the details of the unplanned release request to the deployment tracker module and then subsequently test to certify the software for production.
In the preferred embodiment, the generation of unique TOKEN for each of the unplanned release request enables tracking actual number of unplanned releases in the deployment tracker module. As a result of this, the SQA team can track the status for concurrent releases along with the number of releases to the SMB segments.

The methodology and techniques described with respect to the exemplary embodiments can be performed using a machine or other computing device within which a set of instructions, when executed, may cause the machine to perform any one or more of the methodologies discussed above. The machine may comprise a server computer, a client user computer, a personal computer (PC), a tablet PC, a laptop computer, a desktop computer, or any machine capable of executing a set of instructions (sequential or otherwise) that specify actions to be taken by that machine. Further, while a single machine is illustrated, the term "machine" shall also be taken to include any collection of machines that individually or jointly execute a set (or multiple sets) of instructions to perform any one or more of the methodologies discussed herein.
The machine may include a processor (e.g., a central processing unit (CPU), a graphics processing unit (GPU, or both), a memory which communicate with each other via a bus. The memory stores the instructions when executed, may cause the processor of the machine to perform any one or more of the methodologies discussed
above.
The illustrations of arrangements described herein are intended to provide a general understanding of the structure of various embodiments, and they are not intended to serve as a complete description of all the elements and features of apparatus and systems that might make use of the structures described herein. Many other arrangements will be apparent to those of skill in the art upon reviewing the above description. Other arrangements may be utilized and derived there from, such that structural and logical substitutions and changes may be made without departing from the scope of this disclosure. Figures are also merely representational and may not be drawn to scale. Certain proportions thereof may be exaggerated, while others may be minimized. Accordingly, the specification and drawings are to be regarded in an illustrative rather than a restrictive sense.

ADVANTAGES OF THE INVENTION
The present invention enables facilitation of a single centralized tool for tracking of multiple concurrent requests for unplanned releases.
The present invention enables tracking of number of unplanned releases in software quality-assurance (SQA) process.
The present invention enables admin manager to take judicious decision in regards to approval of the unplanned release requests based on pre-defined criteria by means of tracking the reJease management module integration with the deployment tracker module.
The present invention enables real-time generation of tracking reports for facilitating monitoring of unplanned release details through single centralized tool.
The present invention enables generation of a unique token in a real-time for each of the received unplanned release requests so that number of unplanned releases can be tracked in an appropriate manner.

Claims:
1. A system for tracking number of unplanned releases in a software development
cycle, the system comprising:
a) a release management module (101) to receive request for at least one unplanned release;
b) a deployment tracker module (102) to generate a token and thereby a unique number for the received unplanned release request according to pre-defined criteria;
c) a verification module (106) to verify whether a token has been generated for the received unplanned release request in the deployment tracker module; and
d) a database module (103) to accumulate the details of the unplanned release as a result of the said verification for future tracking and release of the said unplanned release.

2. The system of claim 1, wherein the said pre-defined criteria includes criticality of the request, efforts required to serve the request, resource availability, priority and combinations thereof.
3. The system of claim 1, wherein the verification of the token is done by checking if the token generated exists in the deployment tracker module for the approved request for unplanned release,
4. The system of claim 1, wherein the said unique number generated enables tracking the actual number of unplanned release requests in the release management module.
5. A method for tracking number of unplanned releases in a software development
cycle characterized by integration of software quality-assurance (QA) process into a

centralized software-based deployment tracker module, the method comprising processor implemented steps of:
a) receiving (501) at least one input through a release management module containing request for at least one unplanned release from software development team;
b) approving (503) the said request for at least unplanned release by the manager of the software quality-assurance (QA) team in the release management module according to various pre-defined criteria;
c) generating (504) at least one unique token based on the said approval and thereby a unique number for the said unplanned release request in a deployment tracker module;
d) verifying (507) whether a token has been generated for the received unplanned release request in the deployment tracker module (101); and
e) deploying (508) the details of the unplanned release in a database module for tracking of the unplanned release in the release management module based on the said verification.

6. The method of claim 5, wherein the said pre-defined criteria includes criticality of the request, efforts required to serve the request, resource availability, priority and combinations thereof.
7. The method of claim 5, wherein the verification of the token is done by checking if the token generated exists in the deployment tracker module for the approved request for unplanned release.
8. The method of claim 5, wherein the details of the unplanned release is deployed in the database after the successful verification of the token generated.

9. The method of claim 8, wherein the said deployed details of the unplanned release
in the database is used for tracking the unplanned release.
10. The method of claim 5, wherein the said unique number generated based on the
approval enables tracking the actual number of unplanned release requests in the
release management module.