Claims:1. A method for planning and scheduling of requirements for software development, the method comprising a processor implemented steps of:

providing a plurality of functional user requirements of the software to be developed, wherein the requirements are the plurality of functional user requirements;
providing a set of predefined input parameters related to the plurality of functional user requirements of the software;
assigning a value to each parameter of the set of predefined input parameters corresponding to each of the plurality of functional user requirements, wherein the value is chosen from a set of predefined values;
calculating a score for each of the plurality of functional user requirements based on the parameter values and corresponding weights;
calculating a final unique rank for each of the plurality of functional user requirements based on the assigned values and the score to the set of predefined parameters;
generating a first list of requirements for first release of the software, wherein the first list of requirements is chosen out of the plurality of functional user requirements based on a predefined criteria; and
generating subsequent lists of requirements for subsequent releases of the software based on the predefined criteria until all the plurality of functional user requirements are developed in the software.

2. The method of claim 1 wherein the set of input parameters include eleven predefined input parameters.

3. The method of claim 1, wherein the set of input parameters include ‘functional sequence’, ‘core business process’, ‘business proposition deployment order’, ‘functional dependency’, ‘legal compliance’, ‘operational risk’, ‘financial management’, ‘business benefits’, ‘customer impact’, ‘supplier impact’ and ‘transaction volume’.

4. The method of claim 3 further comprising assigning the value to each of the set of input parameters corresponding to each of the functional user requirements.

5. The method of claim 3 further comprising assigning a weightage to each of the set of input parameters except ‘functional sequence’.

6. The method of claim 3 further comprising assigning the value to ‘core business process’ to at least one of a tier1, tier 2 or tier3, wherein the tier1 1 means that the requirement corresponds to a business process that is required for all the business propositions, the tier2 means that the requirement corresponds to a supporting process of tier1 which will enhances the efficiency of the tier1 related process and the tier3 means that the requirements corresponds to a supporting process set that is not mandatory but good to have and adds some value to the business operations value chain.

7. The method of claim 3 further comprising assigning the value to ‘business proposition deployment order’ from 1 to N, wherein the N is the sequential order in which the business proposition will be rolled out to production.

8. The method of claim 3 further comprising assigning the value to ‘functional sequence’ parameter from at least one of 1 to M, where M is the business function related to the requirement and 1 to M is the predefined sequence order in which the business functions of the business would get engaged in a desired customer journey.

9. The method of claim 3 further comprising assigning the value to ‘functional dependency’ parameter wherein the value is the total number of downstream business process activities which are dependent on the business process that the requirement corresponds to.

10. The method of claim 3 further comprising assigning the value to ‘legal compliance’ parameter as one of ‘1’, ‘2’ or ‘3’, wherein ‘1’ is assigned if the business process that the requirement corresponds to is expected to be executed less than 5 % of the overall annual business operations transaction volume, ‘2’ is assigned if the business process that the requirement corresponds to is expected to be executed is between 5 and 15 % and ‘3’ is assigned if the business process that the requirement corresponds to is expected to be executed is above 15%.

11. The method of claim 3 further comprising assigning the value to ‘operational risk’ parameter at least one of ‘0’, ‘1’, ‘2’ or ‘3’.

12. The method of claim 3 further comprising assigning the value to ‘financial management’ parameter at least one of ‘0’, ‘1’, or ‘2’.

13. The method of claim 3 further comprising assigning the value to ‘business benefits’ parameter at least one of ‘0’, ‘1’, or ‘2’.

14. The method of claim 3 further comprising assigning the value to ‘customer impact’ parameter at least one of ‘0’, ‘1’, or ‘2’.

15. The method of claim 3 further comprising assigning the value to ‘supplier impact’ parameter at least one of ‘0’, ‘1’, or ‘2’.

16. The method of claim 3 further comprising assigning the value to ‘transaction volume’ parameter at least one of ‘0’, ‘1’, ‘2’ or ‘3’.

17. The method of claim 1, wherein the predefined criteria comprises choosing functional user requirements as the first list of requirements if the input parameter ‘core business process’ is assigned a value of tier1.

18. The method of claim 1, wherein the predefined criteria further comprises choosing functional user requirements as the subsequent lists of requirements if the input parameter ‘core business process’ is assigned a value of tier2 and the input parameter ‘production deployment order’ is assigned to 1 to N for the subsequent lists of requirements.

19. The method of claim 1, wherein the predefined criteria further comprises choosing functional user requirements as a final list of requirements if the input parameter ‘core business process’ is assigned a value of tier 3.

20. The method of claim 1 further comprising calculating intermediate ranks before
calculating the final unique rank.

21. A system for planning and scheduling of requirements for software development, the system comprises:

a user interface (102) for providing a plurality of functional user requirements of the software to be developed and providing a set of predefined input parameters related to the plurality of functional user requirements of the software;
a memory (104); and
a processor (106) in communication with the memory, wherein the processor further configured to perform the steps of:
assigning a value to each parameter of the set of predefined input parameters corresponding to each of the plurality of functional user requirements, wherein the value is chosen from a set of values;
calculating a score for each of the plurality of functional user requirements based on the parameter values and corresponding weights using a score calculation module (108);
calculating a final unique rank for each of the plurality of functional user requirements based on the assigned values and the score to the set of predefined parameters using a rank calculation module (110);
generating a first list of requirements for first release of the software using a release requirement generation module (112), wherein the first list of requirements are chosen out of the plurality of functional user requirements based on a predefined criteria; and
generating subsequent lists of requirements for subsequent releases of the software using the release requirement generation module (112) based on the predefined criteria until all the plurality of functional user requirements are developed in the software.
, Description:FORM 2

THE PATENTS ACT, 1970
(39 of 1970)
&
THE PATENT RULES, 2003

COMPLETE SPECIFICATION
(See Section 10 and Rule 13)

Title of invention:
SYSTEM AND METHOD FOR PLANNING AND SCHEDULING OF REQUIREMENTS FOR SOFTWARE DEVELOPMENT

Applicant:
Tata Consultancy Services Limited
A company Incorporated in India under the Companies Act, 1956
Having address:
Nirmal 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.

TECHNICAL FIELD
[0001] The present application generally relates to the field of software development planning. More particularly, but not specifically, the invention is related to system and method for planning and scheduling of requirements for a software development.

BACKGROUND OF THE INVENTION
[0002] The software development is intensive and time consuming process. Generally the software involves a plurality of requirements related to the functionality of the software. These requirements may go up to multiple of thousands in a complex software. During the development of the software, the plurality of requirements of the software needs to be prioritized properly.
[0003] Requirement prioritization in the software development life cycle use different strategies which are often subjective. The most commonly used one is to categorize the requirements into three to five categories based on the stakeholders views and perceived alignment to business objectives. All requirements in a category therefore is of the same priority and the process is subjective.
[0004] MoSCoW is another similar prioritization technique defined in the IIBA BABOK for business analysts. This technique categorizes the list of the requirements into following segments: MUST (Mandatory), SHOULD (High Priority), COULD (Desired but not necessary), WOULD (Can be delayed and proposed for future releases). All requirements in a category therefore is of the same priority and is subjective. Yet another method, Analytical Hierarchical Process (AHP), uses the concept of pairing the requirements and then the same are compared to define the importance of the pairs. In this approach if there are n requirements, total pair should be n*(n-1)/2 and then the analysis should be done. Sometimes the requirement goes in multiple of thousands which make this process complex. Another decision making technique that can be used is Interpretive Structural Modeling (ISM) which again is a pair wise comparison of relative importance. Such techniques are complex, effort intensive and time consuming.

SUMMARY OF THE INVENTION
[0005] The following presents a simplified summary of some embodiments of the disclosure in order to provide a basic understanding of the embodiments. This summary is not an extensive overview of the embodiments. It is not intended to identify key/critical elements of the embodiments or to delineate the scope of the embodiments. Its sole purpose is to present some embodiments in a simplified form as a prelude to the more detailed description that is presented below.
[0006] In view of the foregoing, an embodiment herein provides a system for planning and scheduling of requirements for software development. The system comprises a user interface, a memory and a processor in communication with the memory. The user interface provides a plurality of functional user requirements of the software to be developed and providing a set of predefined input parameters related to the plurality of functional user requirements of the software. The processor further configured to perform the steps of: assigning a value to each parameter of the set of predefined input parameters corresponding to each of the plurality of functional user requirements, wherein the value is chosen from a set of values; calculating a score for each of the plurality of functional user requirements based on the parameter values and corresponding weights; calculating a final unique rank for each of the plurality of functional user requirements based on the assigned values and the score to the set of predefined parameters; generating a first list of requirements for first release of the software, wherein the first list of requirements are chosen out of the plurality of functional user requirements based on a predefined criteria; and generating subsequent lists of requirements for subsequent releases of the software based on the predefined criteria until all the plurality of functional user requirements are developed in the software.
[0007] Another embodiment provides a processor implemented method for planning and scheduling of requirements for software development. Initially, a plurality of functional user requirements of the software to be developed are provided. At the same time, a set of predefined input parameters related to the plurality of functional user requirements of the software are also provided. Further a value is assigned to each parameter of the set of predefined input parameters corresponding to each of the plurality of functional user requirements. The value is chosen from a set of predefined values. In the next step a score is calculated for each of the plurality of functional user requirements based on the parameter values and corresponding weights. In the next step, a final unique rank is calculated for each of the plurality of functional user requirements based on the assigned values and the score to the set of predefined parameters. Later a first list of requirements is generated for first release of the software. The first list of requirements are chosen out of the plurality of functional user requirements based on a predefined criteria. And finally subsequent lists of requirements are generated for subsequent releases of the software based on the predefined criteria until all the plurality of functional user requirements are developed in the software.

BRIEF DESCRIPTION OF THE DRAWINGS
[0008] The embodiments herein will be better understood from the following detailed description with reference to the drawings, in which:
[0009] Fig. 1 shows a block diagram of a system for planning and scheduling of requirements for software development in accordance with an embodiment of the disclosure;
[0010] Fig. 2 shows a table including a set of input parameters along with their weightage, possible values and default value in accordance with an embodiment of the disclosure;
[0011] Fig. 3 shows a flow chart illustrating the steps involved for planning and scheduling of requirements for software development in accordance with an embodiment of the disclosure; and
[0012] Fig. 4 shows an example sheet with 50 functional requirements uniquely ranked in accordance with an embodiment of the disclosure.

DETAILED DESCRIPTION OF THE INVENTION
[0013] The embodiments herein and the various features and advantageous details thereof are explained more fully with reference to the non-limiting embodiments that are illustrated in the accompanying drawings and detailed in the following description. The examples used herein are intended merely to facilitate an understanding of ways in which the embodiments herein may be practiced and to further enable those of skill in the art to practice the embodiments herein. Accordingly, the examples should not be construed as limiting the scope of the embodiments herein.
[0014] Referring now to the drawings, and more particularly to Fig. 1 to Fig. 4, where similar reference characters denote corresponding features consistently throughout the figures, there are shown preferred embodiments and these embodiments are described in the context of the following exemplary system and/or method.
[0015] The expression “requirements” or “a plurality of functional user requirement” or “functional requirements” in the context of the present disclosure refers to the requirements which are required for a software to be developed. The requirements may include business functionality requirements, non-functional requirements, user test cases which are required for the development of the software. For a complex software the requirements may go up to thousands.
[0016] Fig. 1 illustrates a schematic block diagram of a system 100 for planning and scheduling of requirements for a software development. The system 100 provides an objective methodology to plan and schedule the plurality of functional requirements of the software which needs to be developed during the multiple releases of the software. The system 100 uniquely rank business functionality requirements for software development scheduling. The method comprising of an algorithm and its related formulae, applied on a set of eleven input parameters related to functional user requirements, to derive an output which is a sequentially ranked list which is unique or singular i.e. ranked 1 to n, where n is the total number of requirements. This ranked list can then be used to plan and schedule development of the software
[0017] The system 100 comprises a user interface 102, a memory 104 and a processor 106 in communication with the memory 104. The memory 104 is configured to store a plurality of algorithms. The processor 106 further includes a plurality of modules for performing various functions of the system 100. The plurality of modules may include a score calculation module 108, a rank calculation module 110, a release requirements generation module 112 and other modules 114. The plurality of modules access the plurality of algorithms stored in the memory 106 to perform various functions.
[0018] The user interface 102 or the input / output interface is configured to provide a plurality of functional user requirements of the software to be developed. The user interface 102 also configured to provide a set of predefined input parameters related to the plurality of functional user requirements of the software. The user interface 102 can include a variety of software and hardware interfaces, for example, a web interface, a graphical user interface, and the like and can facilitate multiple communications within a wide variety of networks N/W and protocol types, including wired networks, for example, LAN, cable, etc., and wireless networks, such as WLAN, cellular, or satellite. In an embodiment, the user interface device(s) 104 can include one or more ports for connecting a number of devices to one another or to another server.
[0019] According to an embodiment of the disclosure, the set of predefined input parameters include set of 11 parameters which are attributes of business context, business functional dependencies, technical development dependencies captured along with requirements. The set of input parameters include ‘functional sequence’, ‘core business process’, ‘business proposition deployment order’, ‘functional dependency’, ‘legal compliance’, ‘operational risk’, ‘financial management’, ‘business benefits’, ‘customer impact’, ‘supplier impact’ and ‘transaction volume. Each of the input parameter except ‘functional sequence’ is further assigned a weight to them. In addition to that a value is also assigned to each parameter of the set of input parameters corresponding to each of the functional user requirements mentioned above.
[0020] The possible value, weightage and default value of each of the input parameters is provided in the table shown in Fig. 2. The definition of each of the input parameter is provided as follows:
• ‘functional sequence’ (FS): Logical sequence of dependent functional areas (domains) based on the customer life cycle (Eg; Superannuation lifecycle given below) dependency. In case there are functional areas which are independent of each other, they can appear at the same level. For example, 1-Employer, 2-Member, 3-Receipts, 4-Contribution, 5-Insurance, 6-Claims, 7-Benefits etc.
• ‘core business process’ (CBP): This can be either Tier 1, Tier 2 or Tier 3. Tier 1 -Core business process that is required for all the products or services sold (ie; common bare minimum required for the business to operate. Tier 2 - Supporting process of Tier 1 which will enhance the products/services and/or the effectiveness and or efficiency of the core process set. Tier 3 - supporting process set that is good to have but adds value to the operations value chain.
• ‘business proposition deployment order’ (Prod): The business proposition / product for which this activity / EUS will be executed 1 to N is the sequential order in which the products / proposition that would be supported by the system will be rolled out to production. This will ensure that the process / activities related to products that have to be rolled out first is delivered in first.
• ‘functional dependency’ (FD): Number of downstream activities / EUS that are directly dependent on this activity / US being successfully executed. M is the total number of activities in the process set.
• ‘legal compliance’ (LC): It could be either low, medium or high. 1 - Low - This activity is related to a regulatory / legal compliance process and the number of time this activity is executed forms less than 5 % of the annual transaction volume of the process within the related functional area (identified under functional sequence). 2 - Med - Same as Low but the range will be 5-15%. 3 - High - Same as Low but the range will be greater than 15%.
• ‘operational risk’ (OR): 1 - Low - Not performing this activity completely and correctly can result in a) process or business disruption. 2 - Med - Not performing this activity completely and correctly can result in a) process or business disruption AND b) potential loss of revenue or result in additional cost. 3 - High - Not performing this activity completely and correctly can result in a) process or business disruption AND b) potential loss of revenue or result in additional cost AND c) could lead to audit / legal / regulatory compliance issue.
• ‘financial management’ (FM): 0 - This activity is not used or monitored to manage the financial wellbeing of the organization. 1 - This activity is optionally used or monitored to manage the financial wellbeing of the organization. 2 - This activity is mandatorily used or monitored to manage the financial wellbeing of the organization.
• ‘business benefits’ (BB): 0 - This activity does not contribute to any customer value add, revenue, operational excellence. 1 - This activity contributes to business operations effectiveness and / or efficiency (cost). 2 - This activity is a customer value add or revenue generating activity.
• ‘customer impact’ (CI): 1 - Low - This activity does not involve a customer touch point. 2 - High - This activity involves a customer touch point.
• ‘supplier impact’ (SI): 1 - Low - This activity does not involve a supplier touch point. 2 - High - This activity involves a supplier touch point.
• ‘transaction volume’ (TV): 1 - This transaction's execution volume is < 5% of the total per month transaction volume. 2 - This transaction's execution volume is > 5% and < 15% of the total per month transaction volume. 3 - This transaction's execution volume is > 15% of the total per month transaction volume. This will ensure that the high volume transactions are picked up earlier in the life cycle for automation and thereby bringing in early efficiencies in operations.
[0021] According to an embodiment of the disclosure, the user is configured to assign a value to each of the input parameters against each of the plurality of functional user requirements. The value is chosen by the user in such a way that it fits the definition as defined above.
[0022] According to an embodiment of the disclosure, the system 100 further configured to calculate a score for each of the plurality of functional user requirements based on the parameter values and their corresponding weights using the score calculation module 108 as shown in Equation (1):

Score = [(Maximum value of input parameter no. 3 shown in Fig. 2 + 1) - Value of input parameter no. 3 in Fig 2. for the Requirement] * Weight of the input parameter no. 3 in Fig. 2 + S (Priority Rating Parameter (Input Parameter no. 3 in Fig. 2) * Corresponding Weight) ……………………………. (1)

This indicates the reversal of the input parameter no. 3, i.e. ‘Business proposition deployment order’ before summation, to ensure that first business proposition in the roll-out sequence gets first priority. The score calculation module 108 further calculates the relative score using Equation (2):

Relative Score = Score / (Maximum value of scores) …………………………………. (2)

[0023] According to an embodiment of the disclosure, the system 100 further configured to calculate a final unique rank for each of the plurality of functional user requirements based on the assigned values and the score to the set of predefined parameters using the rank calculation module 110. It should be appreciated that the rank calculation module 110 also calculates a plurality of intermediate rank before calculating the final unique rank. The rank calculation module 110 calculates a Rank1.X using Equation (3):

Rank1.X = (Maximum value of the input parameter no. 2 of Fig. 2 Value + 1 – Input parameter no. 2 value of the requirement in Fig. 2 …………………………………... (3)

This indicates that highest possible value of the input parameter no. 2, i.e. ‘Core business process’ of Fig. 2+ 1 – individual input parameter no. 2 value of the requirement, to reverse sequence. This ensures that the ‘core business process’ is delivered first as Foundation Release. Further, the rank calculation module 110 calculates a Rank1.Y using Equation (4):

Rank1.Y = (Maximum value of the input parameter no. 1 of Fig. 2+ 1 – Input parameter no. 1 value of the requirement of Fig. 2) ……………………………………………… (4)

This indicates that the highest possible value of the input parameter no. 1 of Fig. 2, i.e. ‘functional sequence’+ 1 - individual the input parameter no. of Fig. 2 value, to reverse the sequence. This ensures that the functional sequence (a technical dependency) is maintained in the development. Further, the rank calculation module 110 calculates a Rank1.Z using Equation (5):

Rank1.Z = (Maximum value of the input parameter no. 3 of Fig. 2 +1 – Input parameter no. 3 value of the requirement of Fig. 2) ……………………………………………… (5)

This indicates that the highest possible value of the ‘Business proposition deployment order’ + 1 – individual ‘Business proposition deployment order’, to reverse the sequence. This ensures that the ‘Business proposition deployment order’ sequence gets next priority after ‘Core business process’. Further the rank calculation module 110 calculates a Rank 1 using Equation (6):

Rank1 = 10000 * Rank1.X + 100 * Rank1.Z + Rank1.Y ……………………………. (6)

[0024] Thus the priority will be “Core business process”, “Business proposition deployment order” and “Functional Sequence” In case when the relative scores are same for 2 or more rows then the rank calculation module 110 will perform the tie breaker using equation (7)

Tie Breaker = Requirement Serial number / 10^8 ……………………………………. (7)

Using serial number of the requirement as a unique number to maintain the same order of rows. Further the rank calculation module 110 calculates a Rank 2 using Equation (8):

Rank2 = (Rank1) + (Relative Score) + Tie Breaker …………………………………... (8)

Rank2 is a ranking score between 1 and the maximum value of the functional sequence score + 1, each score having 8 digits after the decimal place. Finally, the rank calculation module 110 calculates the unique final rank using Rank function as shown in Equation (9):

Unique Final Rank = RANK (Of the requirement in the sorted list of Rank 2, in ascending order) – default ascending order of input……………………………….. (9)

Thus the use of RANK function to get the rank of each cell in the complete list of "Rank 2" in ascending order. The unique order is obtained due to the unique value of Rank 2.
[0025] According to an embodiment of the disclosure, the system 100 is further configured to generate a first list of requirements for first release of the software using the release requirements generation module 112. The first release of the software is also called as the foundation release of the software which is the core business functionality implementation. The release requirements generation module 112 also configured to generate subsequent list of functional user requirements. The first list of functional user requirements and subsequent lists of functional user requirements are chosen out of the plurality of functional user requirements based on a predefined criterion.
[0026] The predefined criteria comprise choosing functional user requirements as the first list of requirements if the input parameter ‘core business process’ is assigned a value of tier1. The predefined criteria further comprises choosing functional user requirements as the subsequent lists of requirements if the input parameter ‘core business process’ is assigned a value of tier2 and the input parameter ‘production deployment order’ is assigned to 1 to N for the subsequent lists of requirements. The predefined criteria further comprises choosing functional user requirements as a final list of requirements if the input parameter ‘core business process’ is assigned a value of tier 3. It should be appreciated that the plurality of functional requirements when incorporated into the requirements gathering tool, the ranking and release grouping would be automatically achieved by the time the requirements gathering is completed.
[0027] In operation, a flowchart 200 illustrating the steps involved for planning and scheduling of requirements for software development is shown in Fig. 3, according to an embodiment of the invention. Initially, at step 202, a plurality of functional user requirements of the software to be developed is provided using the user interface 102. The requirements are the plurality of functional user requirements. At step 204, the set of predefined input parameters related to the plurality of functional user requirements of the software are also provided to using the user interface 102.
[0028] At the next step 206, a value is assigned to each parameter of the set of predefined input parameters corresponding to each of the plurality of functional user requirements. The value is chosen from a set of predefined values. These values are chosen objectively which makes this method more objective as compared to the prior art. At step 208, a score is calculated for each of the plurality of functional user requirements based on the parameter values and corresponding weights. In the next step 210, a final unique rank is calculated for each of the plurality of functional user requirements based on the assigned values and the score to the set of predefined parameters. It should be appreciated that this step also includes calculation of various intermediate ranks before calculating the final unique rank.
[0029] At step 212, a first list of requirements is generated for first release or the foundation release of the software. The first list of requirements is chosen out of the plurality of functional user requirements based on a predefined criteria. Similarly, at step 214, subsequent lists of requirements are generated for subsequent releases of the software based on the predefined criteria until all the plurality of functional user requirements are developed in the software. It should be appreciated that the predefined criteria is mainly dependent on the input parameter ‘core business process’.
[0030] According to an embodiment of the disclosure, the method 200 can also be explained with the help of an example as shown in the sheet of Fig. 4. As shown there are a total of 50 functional user requirements. Each of the input parameters are then provided a value against each of the functional user requirements. This value and weights is then further used to calculate the score, relative score and unique final rank. In this particular example, the first 25 requirements are ranked ‘1’ as they have ‘CBP’ value equal to 1 and will comprise the foundation release. Similarly, business proposition release 1 would comprise of additional requirements ranked 26 to 28 and provide all functionalities required for serving business proposition 1. Further, business proposition release 2 would comprise of additional requirements ranked 33 to 37 over release 1. And final product release would have all the functionalities.
[0031] The written description describes the subject matter herein to enable any person skilled in the art to make and use the embodiments. The scope of the subject matter embodiments is defined by the claims and may include other modifications that occur to those skilled in the art. Such other modifications are intended to be within the scope of the claims if they have similar elements that do not differ from the literal language of the claims or if they include equivalent elements with insubstantial differences from the literal language of the claims. The embodiment, thus provides the system and method for planning and scheduling of requirements for software development.
[0032] It is, however to be understood that the scope of the protection is extended to such a program and in addition to a computer-readable means having a message therein; such computer-readable storage means contain program-code means for implementation of one or more steps of the method, when the program runs on a server or mobile device or any suitable programmable device. The hardware device can be any kind of device which can be programmed including e.g. any kind of computer like a server or a personal computer, or the like, or any combination thereof. The device may also include means which could be e.g. hardware means like e.g. an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or a combination of hardware and software means, e.g. an ASIC and an FPGA, or at least one microprocessor and at least one memory with software modules located therein. Thus, the means can include both hardware means and software means. The method embodiments described herein could be implemented in hardware and software. The device may also include software means. Alternatively, the embodiments may be implemented on different hardware devices, e.g. using a plurality of CPUs.
[0033] The embodiments herein can comprise hardware and software elements. The embodiments that are implemented in software include but are not limited to, firmware, resident software, microcode, etc. The functions performed by various modules described herein may be implemented in other modules or combinations of other modules. For the purposes of this description, a computer-usable or computer readable medium can be any apparatus that can comprise, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device.
[0034] The medium can be an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system (or apparatus or device) or a propagation medium. Examples of a computer-readable medium include a semiconductor or solid state memory, magnetic tape, a removable computer diskette, a random access memory (RAM), a read-only memory (ROM), a rigid magnetic disk and an optical disk. Current examples of optical disks include compact disk-read only memory (CD-ROM), compact disk-read/write (CD-R/W) and DVD.
[0035] A data processing system suitable for storing and/or executing program code will include at least one processor coupled directly or indirectly to memory elements through a system bus. The memory elements can include local memory employed during actual execution of the program code, bulk storage, and cache memories which provide temporary storage of at least some program code in order to reduce the number of times code must be retrieved from bulk storage during execution.
[0036] Input/output (I/O) devices (including but not limited to keyboards, displays, pointing devices, etc.) can be coupled to the system either directly or through intervening I/O controllers. Network adapters may also be coupled to the system to enable the data processing system to become coupled to other data processing systems or remote printers or storage devices through intervening private or public networks. Modems, cable modem and Ethernet cards are just a few of the currently available types of network adapters.
[0037] A representative hardware environment for practicing the embodiments may include a hardware configuration of an information handling/computer system in accordance with the embodiments herein. The system herein comprises at least one processor or central processing unit (CPU). The CPUs are interconnected via system bus to various devices such as a random access memory (RAM), read-only memory (ROM), and an input/output (I/O) adapter. The I/O adapter can connect to peripheral devices, such as disk units and tape drives, or other program storage devices that are readable by the system. The system can read the inventive instructions on the program storage devices and follow these instructions to execute the methodology of the embodiments herein.
[0038] The system further includes a user interface adapter that connects a keyboard, mouse, speaker, microphone, and/or other user interface devices such as a touch screen device (not shown) to the bus to gather user input. Additionally, a communication adapter connects the bus to a data processing network, and a display adapter connects the bus to a display device which may be embodied as an output device such as a monitor, printer, or transmitter, for example. The preceding description has been presented with reference to various embodiments. Persons having ordinary skill in the art and technology to which this application pertains will appreciate that alterations and changes in the described structures and methods of operation can be practiced without meaningfully departing from the principle, spirit and scope.