DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Priority
Acknowledgment is made of applicant’s claim for foreign priority under 35 U.S.C. 119 (a)-(d) with respect to Indian parent Application No. IN202241030167 filed on 5/26/2022.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 8/25/2025 is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Notice to Applicant
Claims 1-5, 9-15, 18 and 20 are presently amended.
Claims 1-20 are pending.
Response to Amendment
Applicant’s amendments are acknowledged.
Response to Arguments
Applicant' s arguments filed 8/6/2025 have been fully considered in view of further consideration of statutory law, Office policy, precedential common law, and the cited prior art as necessitated by the amendments to the claims, and are persuasive in-part for the reasons set forth below.
Claim Interpretation
First, Applicant argues that “Applicant has amended the claims such that the said terms are no longer used. That is, Applicant respectfully submits that claim 1 has been suitably amended to remove the term "risk estimation engine". Similarly, claims 2-3 have been amended to remove the term "unstructured data analysis unit". Claim 9 has been amended to remove the term "data pre-processing unit". Claim 10 has been amended to remove the term "correlation unit". Claims 11-14 have been amended to remove the term "predictability unit". Claim 14 has been amended to remove the term "risk estimation unit". As such, Applicant respectfully requests the Examiner that the presumption that the claim limitation is interpreted under 35 U.S.C.112 (f) is waived off.” [Arguments, pages 11-12].
In response, Applicant’s arguments are considered and are persuasive. Examiner observes that the presently amended claims do not necessitate a 35 U.S.C.112 (f) claim interpretation.
35 USC § 101 Rejections
First, Applicant argues that “Applicant submits that claimed system is implemented by the claimed processor executing program instructions stored in the claimed memory, and is in effect, a special purpose computer limited to the use of the particularly claimed combination of elements performing the particularly claimed combination of functions. In fact, the claimed processor and memory are central to the invention which has been specifically programmed to give effect to the specific claimed functions, as recited in amended claim 1. The claimed processor and memory, therefore, cannot be said to be a generic computer carrying out well-known, routine and conventional functions…
…this systematic approach enables real-time monitoring and minimization of risks, thereby enhancing project performance and providing a concrete technical solution to the challenges inherent in existing software project management systems as mentioned herein below.
It is submitted that the claimed invention provides a technical solution to the technical problem of static nature and design limitations in agile project management systems that fail to showcase root causes of failure…
Amended claim 1 is not directed to a mere abstract idea, but rather to a patent- eligible technological improvement in the field of predictive risk assessment in software development lifecycle projects. The claim as a whole recites the acts of transformation of unstructured project data into actionable risk indicators. Specifically, amended claim 1 requires the processor to fetch historical unstructured dataset relating to work items documented for past agile projects… Applicant submit that this sequential and systematic approach minimizes risks and improves overall performance in software development lifecycle of projects in real-time… Applicant submits that these operations are computationally intensive and data-driven, requiring the integration of multiple machine learning and data processing techniques and cannot be performed by a human…
As such, Applicant submits that the claimed features are a specific technical process executed by the processor of the claimed system and is not a generic computer function, nor is it a mere mathematical concept… and in fact, the claimed invention recites features that are significantly more and tied to a practical application of specific improvement in the field of software project management…” [Arguments, pages 12-20].
In response, Applicant’s arguments are considered but are not persuasive. Examiner respectfully disagrees and maintains that the present claims recite a judicial exception without significantly more. With regard to the assertion that the claimed invention recites features that are significantly more and tied to a practical application of specific improvement in the field of software project management, Examiner respectfully disagrees. In particular, and Examiner observes that the present invention, when considered as a whole and in context of the additional elements, fails to demonstrate a practical application. Specifically, independent claims 1, 15 and 20 only recite the following additional elements –
A system… the system comprising: a memory storing program instructions; a processor executing program instructions stored in the memory and configured to…; …train a supervised learning model… [Claim 1],
… a processor in communication with a memory…; …train a supervised learning model… [Claim 15],
… A computer program product comprising: a non-transitory computer-readable medium having computer program code stored thereon, the computer-readable program code comprising instructions that, when executed by a processor, causes the processor to…; …train a supervised learning model… [Claim 20].
Examiner respectfully observes that the generically claimed computer components and supervised learning model are recited at a high-level of generality (see MPEP § 2106.05(a)), like the following MPEP example:
iii. Gathering and analyzing information using conventional techniques and displaying the result, TLI Communications, 823 F.3d at 612-13, 118 USPQ2d at 1747-48;
Furthermore, the computer implemented element is considered to amount to no more than mere instructions to apply the exception using a generic computer component (see MPEP 2106.05(f)), like the following MPEP example:
i. A commonplace business method or mathematical algorithm being applied on a general purpose computer, Alice Corp. Pty. Ltd. V. CLS Bank Int’l, 573 U.S. 208, 223, 110 USPQ2d 1976, 1983 (2014); Gottschalk v. Benson, 409 U.S. 63, 64, 175 USPQ 673, 674 (1972); Versata Dev. Group, Inc. v. SAP Am., Inc., 793 F.3d 1306, 1334, 115 USPQ2d 1681, 1701 (Fed. Cir. 2015);
Accordingly, these additional elements are not considered sufficient to demonstrate an integration of the abstract idea into a practical application. The remaining dependent claims do not recite any new additional elements, and thus do not integrate the abstract idea into a practical application.
Similarly, with regard to the assertion that the claims demonstrate a technological improvement, Examiner respectfully maintains that the claimed additional elements amount to no more than mere instructions to apply the exception using a generic computer component (see MPEP 2106.05(f)).
Further still, and with respect to the argument that these operations are computationally intensive and data-driven, requiring the integration of multiple machine learning and data processing techniques and cannot be performed by a human, Examiner observes that these factors are considerations for determining whether or not a claim recites an abstract idea in the grouping of ‘mental processes’. Instead, Examiner respectfully maintains that the present claims recite certain methods of organizing human activity, and in particular, concepts relating to fundamental economic principles or practices. The limitations of the present claims describe steps for fundamental economic principles or practices, which includes hedging, insurance and mitigating risk. Specifically, performing an optimized predictive risk assessment of software development lifecycle of projects is considered to describe steps for mitigating risk. As such, claims 1, 15 and 20 recite concepts identified as abstract ideas. Thus, these claims are not patent eligible. As such, Examiner remains unpersuaded.
35 USC § 103 Rejections
First, Applicant argues that “…Amended claim 1 requires, among other things, fetching a historical unstructured attribute dataset relating to work items from past agile projects, grouping this unstructured data based on derived KPI scores, and converting it into a structured attribute dataset using pre-defined rules. Fox, in contrast, describes a dashboard system that collects and aggregates structured data from various source systems and generates analytics using business formulae (support for the same may be found at para [0012] of Fox), and does not address the acquisition, analysis, or transformation of unstructured attribute datasets as required by amended claim 1.
Furthermore, Fox does not disclose any process for deriving KPI scores from unstructured data or grouping data based on such scores. The analytics engine and agile module as disclosed in Fox operate solely on structured, predefined business metrics and do not perform technique for extracting KPI scores from unstructured sources…” [Arguments, pages 20-22].
In response, Applicant’s arguments are considered but are not persuasive. Examiner respectfully disagrees and directs the Applicant to (Fox, ¶ 1, The present disclosure relates to a business intelligence dashboard that focuses on software development performance. More specifically, the present disclosure relates to a system and method for an enterprise software development dashboard tool that provides actionable intelligence to various levels of stakeholders within an organisation as an enterprise monitoring tool, while continuing with process adherence and quality standards), (Id., ¶ 12, The system comprises a processor, a memory operatively coupled to the processor, and a connector component configured to receive data from business attributes of at least one source program and an analytical component configured to generate an analytics from the received data. Further, the analytical component comprises an analytics engine to track the at least one source program status using quality parameters, an agile module to provide continuous improvement steps to the business attributes using an agile maturity index score, wherein business formulae are applied to generate the analytics from the received data by the analytical component, and wherein the agile maturity index score is calculated for each of the business attributes by the analytical component using the generated analytics), (Id., ¶ 58, The solution provides an enterprise dashboard for tracking software development progress and risks that facilitates transparency for all stakeholders in predictability, productivity, quality & agile maturity by organization levels, offers return on investment (ROI) and other business metrics to engage all stakeholders in technology investments. It also gives filtered metrics across organization levels such as enterprise, business unit, program, project, team and individual (in some cases) and that too in an integrated view mode in code quality, build quality and operational (ASM) metrics), (Id., ¶ 81, The agile module 210 of the analytical component 112 follows the agile approach of dividing tasks into short phases of work and frequently reassessing and adapting new approaches in order to ensure quality deliverables in a timely manner. The agile module 210 performs its task by overlooking activities and providing insights on the same. The activities include but may not be limited to capturing requirements, constructing or initiating work, reviewing the constructed work, deploying the same, testing the work for errors, releasing the work to the next level of stakeholders and eventually managing the work. Further, the agile module 210 manages agility by doing and being agile through various agile coaches including but not limited to agile documentation (discloses work items documented for past agile projects), collaborative planning, continuous integration and delivery, low process ceremony, paired programming, agile estimation, continuous improvement, evolutionary requirements, multi-level adaptive planning and self-organizing team. Additionally, the agile module also calculates an agile maturity index scores for enhancing performance), (Id., ¶ 83, The vendor module 212 of the analytical component 112 assists in keeping track of vendor records and productivities, especially for outsourced work, this further assist in keeping key performance indicators (KPI) of a vendor or a consultant. The KPI generally include productivity, efficiency, quality or other performance indicators as requisite for a particular business. The vendor module 212 comprised in the analytical component 112 calculates vendor productivity on the basis of multiple factors including but not limited to comparative analysis at the vendor and consultant level, story point analysis, summary analysis, resource productivity, and predictability including cost, time and scope variants. Predictability may also be calculated on the basis of a schedule performance index and a cost performance index).
Here, Fox discloses a system for gathering historical unstructured attribute datasets using an agile module in order to group the datasets based on derived KPI (i.e. metrics) scores, in accordance with the present invention. Thus, Examiner respectfully maintains that the Fox reference renders the above-argued elements of the claim obvious. As such, Examiner remains unpersuaded.
Second, Applicant argues that “…Amended claim 1 requires correlating a derived attribute data from the structured attribute dataset to derive an accuracy percentage as a risk indicator, and creating a decision tree structure using the structured attribute dataset (derived from unstructured data) to train a supervised learning model for predicting spillover risk values and defect density. Fox does not disclose or suggest any such correlation, nor does it describe the use of decision tree models, supervised learning, or any machine learning technique applied to structured data derived from unstructured sources. Fox’s analytics are generated using business formulae and do not involve the training or application of machine learning models for predictive risk assessment as claimed in amended claim 1…” [Arguments, page 22].
In response, Applicant’s arguments are considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument. Examiner formulates a new rejection as detailed below. As such, Examiner remains unpersuaded.
Third, Applicant argues that “…amended claim 1 recites combining KPI scores, accuracy percentages, spillover risk values, and defect density values for risk assessment in the software development lifecycle to generate indicators of risk, and employing these indicators for real-time predictive risk assessment to monitor and minimize risks and improve overall performance in software development cycle in real-time. Fox fails to disclose or suggest any such combination of indicators, nor does it employ the outputs of machine learning models trained on structured data derived from unstructured sources for real-time predictive risk assessment. Fox’s system is limited to the aggregation and display of structured metrics and does not provide the claimed real-time, machine learning-based risk monitoring and mitigation functionality, as required by amended claim 1…” [Arguments, page 22].
In response, Applicant’s arguments are considered but are not persuasive. Examiner respectfully disagrees and directs the Applicant to Id., ¶ 53, The KPIs to measure vendor performance may include factors such as cost, on-time delivery, code quality, and software performance. Most of these KPIs may be tangible and directly related to the vendor. The cost component may be measured against the expected cost for performing similar function internally within the software development company. Cost overruns may be a factor when measuring this KPI. On-time delivery may be measured against specified due dates. A good measure of code quality may be the number of bugs in the developed code. Finally, software performance may be measured against metrics such as computational performance, load time, scalability, and performance as perceived by the users), (Id., ¶ 29, The task of Quality Management 225 may present a good candidate for outsourcing for some software developing companies. An iterative process, Quality Management 225 may be closely aligned to Code Development 220. Using the product requirements document prepared by Product Management 215, Quality Management 225 may ensure that the features specified by Product Management 215 are correctly implemented in the final product. The performance of Quality Management 225, and implicitly of Product Development 220, may be easily determined in some software developing companies by remotely monitoring product quality. Thus, the company may have an incentive to carefully monitor the reports prepared by Quality Management 225 to reduce, or even minimize, the risks associated with outsourcing Quality Management 225. Therefore, despite depending on Product Management 215, Quality Management 225 may be outsourced. Some software developing companies may find it advantageous to outsource Quality Management 225 and Coding 220 to the same vendor. Doing so may allow Quality Management 225 to perform its task more efficiently by using the knowledge gained by Coding 220 of the developed software), (Id., ¶ 20, As shown in the exemplary flow chart of FIG. 1, step 120 includes identifying one or more tasks to outsource. These tasks may include the tasks identified with software development, such as pre-sales, sales, product marketing, product management, product development, quality management, product support, consulting, and documentation. The software development company may decide to outsource tasks in a manner that minimizes the disruption to the business process. To avoid disruptions to the business process, the software development company can consider the adverse effects that outsourcing different tasks may have on the base criteria identified in step 110. These adverse effects may be grouped into at least three sets of risks--strategic risks, operational risks, and demographic risks. (discloses indicators of risk) It will be understood that the set of risks and the risks in each group are not exhaustive and should be enhanced as required), (Id., ¶ 30, The software development company may have as a goal the awareness of customer issues as well as the vendor's response to these issues at all times. To achieve this goal, the software development company may implement a well-defined escalation process in which the software development company itself may become involved with customer problems).
Here, Nagar discloses a system intended to monitor risks and improve overall performance of software development lifecycle projects at least by implementing NLP and supervised learning models to assist developers with tools and by tracking metrics at all times. Thus, Examiner respectfully maintains that Nagar renders the above-argued limitation obvious. As such, Examiner remains unpersuaded.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more.
Step 1: Claims 1-20 are directed to statutory categories, namely a machine (claims 1-14), a process (claims 15-19) and an article of manufacture (claim 20).
Step 2A, Prong 1: Claims 1, 15 and 20 in part, recite the following abstract idea:
… for optimized predictive risk assessment of software development lifecycle of projects… fetch a historical unstructured attribute dataset relating to work items documented for past agile projects and group the unstructured attribute dataset based on derived Knowledge Performance Indicator (KPI) scores; convert the unstructured attribute dataset into a structured attribute dataset by applying pre-defined rules, wherein each attribute data of the structured attribute dataset is mapped to pre-determined categorical values; correlate a derived attribute data from the structured attribute dataset with a defined attribute data to derive an accuracy percentage, wherein the accuracy percentage signifies a potential risk to subsequent tasks in the software development lifecycle of projects; create a decision tree structure using the structured attribute dataset to… and predict spillover risk values, wherein a maximum information retention is determined for predicting the spillover risk values that are obtained when a branching node is created for the structured attribute data; apply an iterative logic to predict defect density values based on the structured attribute dataset; and combine the KPI scores, the accuracy percentage and the spillover risk values and the defect density values for risk assessment in the software development lifecycle of projects to generate indicators of risks, wherein the system employs the generated indicators of risks for predictive risk assessment to monitor and minimise risks and improve overall performance of software development lifecycle projects in real-time [Claim 1],
A method for optimized predictive risk assessment of software development lifecycle of projects, wherein the method is executed by…, the method comprising: fetching a historal unstructured attribute dataset relating to work items documented for past agile projects and group the unstructured attribute dataset based on derived Knowledge Performance Indicator (KPI) scores to create a grouped attribute dataset; converting the unstructured attribute dataset into a structured attribute dataset by applying pre-defined rules, wherein each attribute data of the structured attribute dataset is mapped to pre-determined categorical values; correlating a derived attribute data from the structured attribute dataset with a defined attribute data to derive an accuracy percentage, wherein the accuracy percentage signifies a potential risk to subsequent tasks in the software development lifecycle of projects; creating a decision tree structure using the structured attribute dataset to… and predict spillover risk values, wherein a maximum information retention is determined for predicting the spillover risk values that are obtained when a branching node is created for the structured attribute data; applying an iterative logic to predict defect density values based on the structured attribute dataset; and combining the KPI scores, the accuracy percentage and the spillover risk values and defect density values for risk assessment in the software development lifecycle of projects to generate indicators of risks, wherein the system employs the generated indicators of risks for predictive risk assessment to monitor and minimise risks and improve overall performance of software development lifecycle projects in real-time [Claim 15],
…fetch a historical unstructured attribute dataset relating to work items documented for past agile projects and group the unstructured attribute dataset based on derived Knowledge Performance Indicator (KPI) scores; convert the unstructured attribute dataset into a structured attribute dataset by applying pre-defined rules, wherein each attribute data of the structured attribute dataset is mapped to pre-determined categorical values; correlate a derived attribute data from the structured attribute dataset with a defined attribute data to derive an accuracy percentage, wherein the accuracy percentage signifies a potential risk to subsequent tasks in the software development lifecycle of projects; create a decision tree structure using the structured attribute dataset to… and predict spillover risk values, wherein a maximum information retention is determined for predicting the spillover risk values that are obtained when a branching node is created for the structured attribute data; apply an iterative logic to predict defect density values based on the structured attribute dataset; and combine the KPI scores, the accuracy percentage and the spillover risk values and defect density values for risk assessment in the software development lifecycle of projects to generate indicators of risks, wherein the system employs the generated indicators of risks for predictive risk assessment to monitor and minimise risks and improve overall performance of software development lifecycle projects in real-time [Claim 20].
These concepts are not meaningfully different than the following concepts identified by the MPEP:
Concepts relating to fundamental economic principles or practices. The aforementioned limitations describe steps for fundamental economic principles or practices, which includes hedging, insurance and mitigating risk. Specifically, performing an optimized predictive risk assessment of software development lifecycle of projects is considered to describe steps for mitigating risk. As such, claims 1, 15 and 20 recite concepts identified as abstract ideas.
The dependent claims recite limitations relative to the independent claims, including, for example:
…configured to group the unstructured attribute dataset to create a grouped attribute dataset including a positive, a negative, a mixed and a neutral grouped sentiment dataset, the grouping is carried out by employing a sequence of computational linguistics techniques including stemming followed by tokenization on the unstructured attribute dataset comprising communication threads to create the grouped attribute dataset, and wherein the … is configured to detect risks and initiate corrective actions on instances of a continuous non-positive grouped attribute outputs from a set of tasks for deriving the KPI scores, and wherein … performs analysis of the KPI score using…, the communication thread is broken down into sub-component parts and the parts are individually validated to identify sentiment bearing phrases through word associations, the KPI score is assigned to each phrase in the sub-component parts such that the KPI score is proportional to a degree to which sentiment is expressed [Claim 2],
…performs analysis of the KPI score to determine if the communication threads have KPI scores across multiple sentiments, and groups the unstructured attribute dataset comprising such communication threads as the mixed grouped sentiment dataset, and wherein … performs analysis of the KPI score and groups the unstructured attribute dataset comprising communication threads as a neutral grouped sentiment dataset in the event the KPI scores are determined to be low [Claim 3],
…wherein the structured attribute dataset comprises a first attribute data representing unique requirement identifiers assigned by … corresponding to the software development lifecycle of projects, and wherein the structured attribute dataset comprises a second attribute data representing base requirements provided by a team which is split at a functional or a technical level, and wherein the base requirements include modules and segments associated with user interface, database connectivity, error control, reporting that are required to build a software system corresponding to the software development lifecycle of projects [Claim 4],
…wherein the structured attribute dataset comprises a third attribute data representing a count of number of days for completing technical or functional requirements in a work item, the third attribute is scaled in between a value of 1-8 days, and wherein the structured attribute dataset comprises a fourth attribute data representing an urgency of the work items, sequence in which tasks are to be accomplished and a level of significance of the work items, the fourth attribute data may be represented as a major, a medium, a minor and a rush in a scale, wherein rush represents an ad-hoc requirement. [Claim 5],
wherein the structured attribute dataset comprises a fifth attribute data representing a count of people that have worked or are working on a work item, wherein with increase in complexity in the software development lifecycle of projects a count of the fifth attribute data increases, and wherein the structured attribute dataset comprises a sixth attribute data representing a length of a field … comprising textual description of technical and functional requirements in words and characters [Claim 6],
The limitations of these dependent claims are merely narrowing the abstract idea identified in the independent claims, and thus, the dependent claims also recite abstract ideas.
Step 2A, Prong 2: This judicial exception is not integrated into a practical application. In particular, claims 1, 15 and 20 only recite the following additional elements –
A system… the system comprising: a memory storing program instructions; a processor executing program instructions stored in the memory and configured to…; …train a supervised learning model… [Claim 1],
… a processor in communication with a memory…; …train a supervised learning model… [Claim 15],
… A computer program product comprising: a non-transitory computer-readable medium having computer program code stored thereon, the computer-readable program code comprising instructions that, when executed by a processor, causes the processor to…; …train a supervised learning model… [Claim 20].
The apparatus, processor, memory, supervised learning model and executable instructions are recited at a high-level of generality (see MPEP § 2106.05(a)), like the following MPEP example:
iii. Gathering and analyzing information using conventional techniques and displaying the result, TLI Communications, 823 F.3d at 612-13, 118 USPQ2d at 1747-48;
Furthermore, the computer implemented element is considered to amount to no more than mere instructions to apply the exception using a generic computer component (see MPEP 2106.05(f)), like the following MPEP example:
i. A commonplace business method or mathematical algorithm being applied on a general purpose computer, Alice Corp. Pty. Ltd. V. CLS Bank Int’l, 573 U.S. 208, 223, 110 USPQ2d 1976, 1983 (2014); Gottschalk v. Benson, 409 U.S. 63, 64, 175 USPQ 673, 674 (1972); Versata Dev. Group, Inc. v. SAP Am., Inc., 793 F.3d 1306, 1334, 115 USPQ2d 1681, 1701 (Fed. Cir. 2015);
Accordingly, these additional elements do not integrate the abstract idea into a practical application.
The remaining dependent claims do not recite any new additional elements, and thus do not integrate the abstract idea into a practical application.
Step 2B: Claims 1, 15 and 20 and their underlying limitations, steps, features and terms, considered both individually and as a whole, do not include additional elements that are sufficient to amount to significantly more than the judicial exception for the following reasons:
Independent claims 1, 15 and 20 only recite the following additional elements –
A system… the system comprising: a memory storing program instructions; a processor executing program instructions stored in the memory and configured to…; …train a supervised learning model… [Claim 1],
… a processor in communication with a memory…; …train a supervised learning model… [Claim 15],
… A computer program product comprising: a non-transitory computer-readable medium having computer program code stored thereon, the computer-readable program code comprising instructions that, when executed by a processor, causes the processor to…; …train a supervised learning model… [Claim 20].
As such, both individually or in combination, these limitations do not add significantly more to the judicial exception.
The remaining dependent claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the dependent claims do not recite any new additional elements other than those mentioned in the independent claims, which amount to no more than mere instructions to apply the exception using a generic computer component (see MPEP 2106.05(f)). As such, these claims are not patent eligible.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-7 and 9-20 are rejected under 35 U.S.C. 103 as being unpatentable over Fox et al., U.S. Publication No. 2022/0051162 [hereinafter Fox] in view of Nagar, U.S. Publication No. 2008/0086354 [hereinafter Nagar] and further in view of Muddakkagari et al., U.S. Publication No. 2020/0241872 [hereinafter Muddakkagari].
Regarding Claim 1, Fox discloses … A system for optimized predictive risk assessment of software development lifecycle of projects, the system comprising: a memory storing program instructions; a processor executing program instructions stored in the memory and configured to: fetch a historical unstructured attribute dataset relating to work items documents for past agile projects and group the unstructured attribute dataset based on derived Knowledge Performance Indicator (KPI) scores (Fox, ¶ 1, The present disclosure relates to a business intelligence dashboard that focuses on software development performance. More specifically, the present disclosure relates to a system and method for an enterprise software development dashboard tool that provides actionable intelligence to various levels of stakeholders within an organisation as an enterprise monitoring tool, while continuing with process adherence and quality standards), (Id., ¶ 12, The system comprises a processor, a memory operatively coupled to the processor, and a connector component configured to receive data from business attributes of at least one source program and an analytical component configured to generate an analytics from the received data. Further, the analytical component comprises an analytics engine to track the at least one source program status using quality parameters, an agile module to provide continuous improvement steps to the business attributes using an agile maturity index score, wherein business formulae are applied to generate the analytics from the received data by the analytical component, and wherein the agile maturity index score is calculated for each of the business attributes by the analytical component using the generated analytics), (Id., ¶ 58, The solution provides an enterprise dashboard for tracking software development progress and risks that facilitates transparency for all stakeholders in predictability, productivity, quality & agile maturity by organization levels, offers return on investment (ROI) and other business metrics to engage all stakeholders in technology investments. It also gives filtered metrics across organization levels such as enterprise, business unit, program, project, team and individual (in some cases) and that too in an integrated view mode in code quality, build quality and operational (ASM) metrics), (Id., ¶ 81, The agile module 210 of the analytical component 112 follows the agile approach of dividing tasks into short phases of work and frequently reassessing and adapting new approaches in order to ensure quality deliverables in a timely manner. The agile module 210 performs its task by overlooking activities and providing insights on the same. The activities include but may not be limited to capturing requirements, constructing or initiating work, reviewing the constructed work, deploying the same, testing the work for errors, releasing the work to the next level of stakeholders and eventually managing the work. Further, the agile module 210 manages agility by doing and being agile through various agile coaches including but not limited to agile documentation (discloses work items documented for past agile projects), collaborative planning, continuous integration and delivery, low process ceremony, paired programming, agile estimation, continuous improvement, evolutionary requirements, multi-level adaptive planning and self-organizing team. Additionally, the agile module also calculates an agile maturity index scores for enhancing performance), (Id., ¶ 83, The vendor module 212 of the analytical component 112 assists in keeping track of vendor records and productivities, especially for outsourced work, this further assist in keeping key performance indicators (KPI) of a vendor or a consultant. The KPI generally include productivity, efficiency, quality or other performance indicators as requisite for a particular business. The vendor module 212 comprised in the analytical component 112 calculates vendor productivity on the basis of multiple factors including but not limited to comparative analysis at the vendor and consultant level, story point analysis, summary analysis, resource productivity, and predictability including cost, time and scope variants. Predictability may also be calculated on the basis of a schedule performance index and a cost performance index);
convert the unstructured attribute dataset into a structured attribute dataset by applying pre-defined rules, wherein each attribute data of the structured attribute dataset is mapped to pre-determined categorical value (Id., ¶ 73, A dashboard framework system 104 implements a method for dashboard framework 200 (discloses structured attribute dataset) on a web and application server 102 or a web server 102, the dashboard framework system 104 also known as web and application system 104 includes a display component 110 or a dashboard interface, a connector agent 202, an analytical component 112 or a web API, and other components 114. The display component 110 allows the system 104 to interact with a user 150. The analytical component 112 comprises an agile module 210, a vendor module 212, a test case module 214, an analytics engine 216, and other modules 220. The analytical component 112 communicates with a connector component 204 having a connector service 116 and further connected to a plurality of sub-connectors 204a, 204b, 204c, 204d, . . . , 204n, such as a JIRA connector, a Jenkins connector, a SonarQube connector, a ServiceNow connector, an Excel connector, and alike for each program, project, or such source systems/applications 130. Each of the sub-connectors 204a, 204b, 204c, 204d, . . . , 204n are respectively coupled to one of a plurality of third party program, project, or such source systems 130 or applications, such as 132a, 132b, 132c, 132d, . . . , 132n, such a JIRA, a Jenkins, a SonarQube, a ServiceNow, an Excel file programs. Further, the components of the system 104 communicates to other computing devices, ex web servers and external data servers, such as a DB server 120 having a database system 122 and a database 124), (Id., ¶ 74, The enterprise software development dashboard tool of the solution provides the connector component 204, the analytical component 112 and the display component 110. Additionally, the tool also comprises a server component 122 of the DB server 120 which remains in constant communication with the analytical component 112. The connector component 204 of the dashboard framework system may be incorporated to gather data from multiple tools, systems and applications 130 in a way that the data is gathered via a predefined function initiated in a specified time period. The analytical component 112 may be instructed to receive the data from the connector component 204, applying business formulae (discloses pre-defined rules) onto the data and deriving useful analytics, eventually supplementing said data to the display component 110. The analytical component 112 may further be facilitated to perform analytics in order to derive descriptive analytics, predictive analytics and prescriptive analytics from the data supplemented to the analytical component 112 from the connector sub-connectors 204a, 204b, . . . , 204n. The analytical component 112 may further derive analytics from the supplemented data mainly for the attributes including but not limited to predictability, productivity, quality, maturity and return-on-investment (discloses mapping to pre-determined categorical values). The display component 110 of the software development dashboard system may be developed to display the analytics supplemented by the analytical component in a flexible and user-friendly manner), (Id., ¶ 93, FIG. 3.2 illustrates an exemplary dashboard report 300 generated by a dashboard framework system, in accordance with an embodiment of the present subject matter);
PNG
media_image1.png
366
539
media_image1.png
Greyscale
apply an iterative logic to predict defect density values based on the structured attribute dataset (Id., ¶ 84, The test case module 214 is a review module which reviews the work being performed by individuals in an organization. The test case module 214 of the analytical component 112 identifies test case scenarios based on multiple parameters including but not limited to coverage percentage, completion percentage, executed pass percentage and executed failure percentage which assist in analysing the performance of a project or program as being developed or worked upon (discloses defect density values)), (Id., ¶ 7, agile software development processes are also added that further encourages flexible planning and low reaction time to changing requirements. The agile method divides jobs into small, incremental steps that may be completed with little forethought. Software iterations are created in a short amount of time. Consolidating and enabling project management, product management, customer management, and other stakeholders in a single environment or tool is required by project management systems that have been built to arrange these operations. They are typically unable to communicate with other third-party technologies or collaborate across many development teams or geographically dispersed locales);
While suggested in at least Fig. 2 and related text, Fox does not explicitly disclose …correlate a derived attribute data from the structured attribute dataset with a defined attribute data to derive an accuracy percentage, wherein the accuracy percentage signifies a potential risk to subsequent tasks in the software development lifecycle of projects; create a decision tree structure using the structured attribute dataset to train a supervised learning model and predict spillover risk values, wherein a maximum information retention is determined for predicting the spillover risk values that are obtained when a branching node is created for the structured attribute data; and combine the KPI scores, the accuracy percentage and the spillover risk values and the defect density values for risk assessment in the software development lifecycle of projects to generate indicators of risks, wherein the system employs the generated indicators of risks for predictive risk assessment to monitor and minimise risks and improve overall performance of software development lifecycle projects in real-time
However, Nagar discloses …correlate a derived attribute data from the structured attribute dataset with a defined attribute data to derive an accuracy percentage, wherein the accuracy percentage signifies a potential risk to subsequent tasks in the software development lifecycle of projects (Nagar, ¶ 37, With each vendor having its own node, the software development company may associate with each vendor's node the risk-percentage for outsourcing the CBP to that specific vendor. The software development company may begin this process by assigning risk percentages to risks shared by all vendors (discloses accuracy percentage signifying risk). This risk percentage may be calculated using the previously-identified risks in the task-vendor risk-profiles. For example, a software development company may associate a sixty percent risk of knowledge transfer to outsourcing the CBP to any vendor, regardless of the vendor chosen. The software development company may assign this risk percentage to link 410, which connects outsourcing node 400 with complete business process node 415), (Id., ¶ 38, The software development company may then assign risk percentages to risks posed by each individual vendor. The software development company may identify the individual risks by referring to the previously created risk-profiles. The individual risk percentages may be reflected in the links 430, 432, and 434 connecting each vendor node 420, 422, and 424, respectively, to complete business process node 415. The set of all risks taken together for each vendor-process scenario constitutes the decision-tree risk-profile associated with the scenario), (Id., ¶ 43, A software development company may associate individual risks for outsourcing a specific subset of the tasks of the CBP to a specific vendor with the link connecting that vendor to the specific subset node 510 or 520. For example, outsourcing subset X of the CBP to vendor i may involve a fifty-five percent risk of work stoppages (discloses downstream risk) because of the threat of a volcano eruption near the facilities used by vendor i. In this case, the software development company may associate this work stoppage risk percentage with link 516 connecting vendor node 512 to subset X node 510. Each of links 516, 518, 526, and 528 may have individual risk percentages associated with specific risks for outsourcing a specific subset of tasks of the CBP to an individual vendor);
and combine the KPI scores, the accuracy percentage and the spillover risk values and the defect density values for risk assessment in the software development lifecycle of projects to generate indicators of risks, wherein the system employs the generated indicators of risks for predictive risk assessment to monitor and minimise risks and improve overall performance of software development lifecycle projects in real-time (Id., ¶ 53, The KPIs to measure vendor performance may include factors such as cost, on-time delivery, code quality, and software performance. Most of these KPIs may be tangible and directly related to the vendor. The cost component may be measured against the expected cost for performing similar function internally within the software development company. Cost overruns may be a factor when measuring this KPI. On-time delivery may be measured against specified due dates. A good measure of code quality may be the number of bugs in the developed code. Finally, software performance may be measured against metrics such as computational performance, load time, scalability, and performance as perceived by the users), (Id., ¶ 29, The task of Quality Management 225 may present a good candidate for outsourcing for some software developing companies. An iterative process, Quality Management 225 may be closely aligned to Code Development 220. Using the product requirements document prepared by Product Management 215, Quality Management 225 may ensure that the features specified by Product Management 215 are correctly implemented in the final product. The performance of Quality Management 225, and implicitly of Product Development 220, may be easily determined in some software developing companies by remotely monitoring product quality. Thus, the company may have an incentive to carefully monitor the reports prepared by Quality Management 225 to reduce, or even minimize, the risks associated with outsourcing Quality Management 225. Therefore, despite depending on Product Management 215, Quality Management 225 may be outsourced. Some software developing companies may find it advantageous to outsource Quality Management 225 and Coding 220 to the same vendor. Doing so may allow Quality Management 225 to perform its task more efficiently by using the knowledge gained by Coding 220 of the developed software), (Id., ¶ 20, As shown in the exemplary flow chart of FIG. 1, step 120 includes identifying one or more tasks to outsource. These tasks may include the tasks identified with software development, such as pre-sales, sales, product marketing, product management, product development, quality management, product support, consulting, and documentation. The software development company may decide to outsource tasks in a manner that minimizes the disruption to the business process. To avoid disruptions to the business process, the software development company can consider the adverse effects that outsourcing different tasks may have on the base criteria identified in step 110. These adverse effects may be grouped into at least three sets of risks--strategic risks, operational risks, and demographic risks. (discloses indicators of risk) It will be understood that the set of risks and the risks in each group are not exhaustive and should be enhanced as required), (Id., ¶ 30, The software development company may have as a goal the awareness of customer issues as well as the vendor's response to these issues at all times. To achieve this goal, the software development company may implement a well-defined escalation process in which the software development company itself may become involved with customer problems).
It would have been obvious to a person of ordinary skill in the art before the effective filing date to have modified the software development risk assessment elements of Fox to include the decision tree and spillover risk elements of Nagar in the analogous art of outsourcing software development.
The motivation for doing so would have been to improve the ability of “A software development company… [to] …use the preferences for each base criteria to evaluate possible scenarios for outsourcing different software development tasks” [Nagar, ¶ 19], wherein such improvements would benefit Fox’s method which seeks to provide “relevant analytics across the entire software development lifecycle … to increase software development process performance and quality, decreasing waste and ensuring positive business impact” [Nagar, ¶ 19; Fox, ¶ 2].
While suggested in at least Fig. 2 and related text of Fox, the combination of Fox and Nagar does not explicitly disclose … create a decision tree structure using the structured attribute dataset to train a supervised learning model and predict spillover risk values, wherein a maximum information retention is determined for predicting the spillover risk values that are obtained when a branching node is created for the structured attribute data
However, through KSR Rationale D (See MPEP 2141(III)(D)), the combination of Nagar and Muddakkagari discloses …create a decision tree structure using the structured attribute dataset to train a supervised learning model and predict spillover risk values, wherein a maximum information retention is determined for predicting the spillover risk values that are obtained when a branching node is created for the structured attribute data.
First, Nagar discloses the creation of a decision tree structure to predict spillover risk values, as well as to determine data retention policies (Nagar, ¶ 32, After risks are identified and a risk profile is created, a decision tree is created (step 140). After using the identified risks to create a risk-profile for each task, the software development company may use the risk profiles to build a decision-tree to assist it in making a decision as to which task or tasks to outsource (step 140). FIGS. 3-5 show an exemplary decision-tree that may be used in the decision of outsourcing software development tasks. The decision-tree process may be a multi-stage process, where each stage can be interrelated. At each stage, the organization may make a decision having an associated set of risks and consequences. Further, the decisions made at one stage may affect the risks associated with decisions made at subsequent stages because of the interrelationships existing between stages. For example, the set of risks associated with the decision to outsource Code Development 220 may depend on the decision to outsource Quality Management 225), (Id., ¶ 33, The decision-tree based approach may allow the software development company to systematically build a decision-tree risk-profile for each task or set of tasks considered for outsourcing. In some embodiments, the decision-tree based approach may allow the software development company to consider the risks of outsourcing each task or set of tasks to one or more different vendors. By building the decision-tree risk-profile, the software development company may be able to quantify the risks and calculate the expected monetary costs of all possible task-vendor combinations of the risk-profile), (Id., ¶ 41, FIG. 5 shows a similar process for determining the risks for outsourcing a subset of the tasks of the CBP. The risk percentages associated with each subset-vendor pair may be grouped under partial business process node 500. In the exemplary decision-tree shown in FIG. 5, a software development company may consider outsourcing two subsets of the CBP, subset X and subset Y. Each subset may receive its own node, such as, for example, node 510 for subset X and node 520 for subset Y), (Id., ¶ 21, Strategic risks include, for example, loss of innovation, loss of intellectual property, and the possibility of strategic policy diversion between a software development company and an external vendor responsible for outsourced tasks. Outsourcing one or more key functions over a period of time can increase the dependence of the software development company on the external vendor. Over time, this dependence can deplete the technical capabilities of the company, limiting its ability to undertake product development in the future. This risk can be more pronounced with outsourcing of some functions than others. To guard against this risk, the company can determine its core competencies and retain strategic control over functions relevant to these competencies. Further, the software development company decide to take measures to provide increased security for its intellectual property that is sent to an external vendor, especially in the absence of strict and enforceable legal protections of the company's intellectual property from misuse by the external vendor and its employees. There is also the risk of a strategic diversion of policies between the software development company and the external vendor over a long period of time. For example, the external vendor may decide to develop competing products or switch to a totally different product line in the future, forcing the outsourcing company to search for new vendors, an expensive proposition in some instances).
PNG
media_image2.png
369
624
media_image2.png
Greyscale
Further, Muddakkagari discloses training a supervised learning model to process queries and determine metrics in a software development environment (Muddakkagari, ¶ 32, The NLP system 114 may include various processors (pre-processor 116A, post-processor 116B), libraries (e.g., library 118), and Al-based systems (e.g., machine learning (ML) tool 120) to analyze and convert natural language to one that could result in a computing system to perform substantive functions (e.g., find a response to the query). Using the pre-processor 116A, the NLP system 114 may rephrase and/or reformat the query for computing systems (e.g., AIML Interpreter 122, DevOps system 130, etc.) to understand. In some aspects, the NLP may also determine whether the query is a dynamic or a static query, as will be discussed further below. Using post-processor 116B, the NLP system 114 may rephrase and/or reformat a proposed response to a query, e.g., so that it may be understandable to a user of the user device 102A-102C that sent the original query. In some aspects, the NLP 114 may assess a proposed response, and upon determining that the proposed response is incorrect, unsatisfactory, or misguided, can facilitate a new response. The NLP system 114 may be guided by a library 118 (e.g., database, look-up tables, repository, etc.) and Al-based tools (e.g., ML tool 120) for various uses in natural language processing, including the undergoing of supervised and unsupervised learning from language data. Together with its library 118, the ML tool 120 may support common NLP tasks, such as tokenization, sentence segmentation, part-of-speech tagging, named entity extraction, chunking, parsing, and coreference resolution. These tasks may be needed to build more advanced text processing services. The ML tool 120 may also include maximum entropy and perceptron based machine learning tools. The NLP system 114 and/or query engine 112 may determine whether a received query solicits a static or dynamic response. For example, a static response may invoke a simple retrieval of information from a local database 124, e.g., of an AIML interpreter 122. A dynamic response may involve invoking the DevOps System 130, which may investigate specific event(s) of an application development from various DevOps tools 138A-138E and their respective source integrators 136A-136E), (Id., ¶ 61, If the query does concern a quality metric, the query/response system 110 and/or the DevOps system 130 may determine relevant quality assurance (QA) tools associated with the DevOps system 130. These QA tools may assist in generating a dynamic response to the query. The QA tools may include a framework for testing units of code for an application, code coverage tools to find out which parts of the code are tested, analytical tools to help predict vulnerability, and a dashboard to present results of the test to the user. The QA tools may be used to analyze source code, search for defects and bugs, and display results of the search on a dashboard. The QA tools may include a framework or application for testing units of the code (e.g., JUnit in the JAVA™ programming language, JAVA™ Code Coverage (JaCoCo) as a tool for code coverage, and a source code analyzer for statistically analyzing the code base and learning the vulnerability of the standards of usage. Some source code analyzers (e.g., PMD reports) may help find unused variables, empty catch blocks, unnecessary object creation, etc. The statistical analysis may be presented as one or more of a report, spreadsheet, slide, chart, graph, etc. on a dashboard, and may be segregated or divided into many levels. Examples of QA tools that could be used may include, for example, SONARQUBE™ (formerly SONAR™), DYNATRACE™ (e.g., for monitoring applications on a server), VERACODE (e.g., for security analysis), WHITESOURCE (e.g., for security analysis), APPSPIDER (e.g., for dynamic testing analysis), JMETER (e.g., for service test analysis), etc).
One of ordinary skill in the art would have recognized that applying the known technique of Muddakkagari would have yielded predictable results and resulted in an improved system. It would have been recognized that applying the supervised machine learning technique of Muddakkagari to the decision tree and risk value determination teachings of Nagar would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate such data processing features into similar software development management systems. Further, applying a supervised machine learning technique to Nagar with spillover risk values determined accordingly, would have been recognized by those of ordinary skill in the art as resulting in an improved system that would allow more detailed reports and greater control over the software development lifecycle process.
Thus, through KSR Rationale D (See MPEP 2141(III)(D)), the combination of Nagar and Muddakkagari discloses …create a decision tree structure using the structured attribute dataset to train a supervised learning model and predict spillover risk values, wherein a maximum information retention is determined for predicting the spillover risk values that are obtained when a branching node is created for the structured attribute data.
It would have been obvious to a person of ordinary skill in the art before the effective filing date to have modified the software development risk assessment elements of Fox and the decision tree and spillover risk elements of Nagar to include the supervised learning elements of Muddakkagari in the analogous art of automating and monitoring software development operations.
The motivation for doing so would have been to “increase an organization's ability to deliver applications and services at high velocity: evolving and improving products at a faster pace than other organizations using software development and infrastructure management processes” [Muddakkagari, ¶ 24], wherein such improvements would benefit Nagar’s method which seeks to improve the ability of “A software development company… [to] …use the preferences for each base criteria to evaluate possible scenarios for outsourcing different software development tasks” [Nagar, ¶ 19], and wherein such improvements would further benefit Fox’s method which seeks to provide “relevant analytics across the entire software development lifecycle … to increase software development process performance and quality, decreasing waste and ensuring positive business impact” [Muddakkagari, ¶ 24; Nagar, ¶ 19; Fox, ¶ 2].
Regarding Claim 2, the combination of Fox, Nagar and Muddakkagari discloses …the system as claimed in claim 1…
Fox further discloses …wherein the processor is configured to group the unstructured attribute dataset to create a grouped attribute dataset including a positive, a negative, a mixed and a neutral grouped sentiment dataset, the grouping is carried out by employing a sequence of computational linguistics techniques including stemming followed by tokenization on the unstructured attribute dataset comprising communication threads to create the grouped attribute dataset, and wherein the processor is configured to detect risks and initiate corrective actions on instances of a continuous non-positive grouped attribute outputs from a set of tasks for deriving the KPI scores, and wherein the processor performs analysis of the KPI score … (Fox, ¶ 90, Key metrics beyond source application program or project to support detailed reporting for continuous improvements from agile teams to senior management includes productivity, predictability, quality and ROI. Productivity option 304a, metric 306a covers team's average velocity, program velocity, impediments scorecard, release burn down w/all dimensions, vendor productivity. This ranges release burn down, other than work completion trend, it also tracks requirement volatility trends by sprint to help predict revised date of delivery. Impediment score card 308 would directly reflect on the impediment status and hence the efficiency of the scrum master backlog health would directly reflect on the feature clarity and hence the efficiency of the product owner. Predictability option 304b, metric 306b covers scope variance, schedule variance, cost variance, SPI & CPI (EVM), supports predictability around time, cost, scope. concept of earned value measurement in agile to measure the cost performance index i.e. CPI and schedule performance index i.e. SPI. The CPI and SPI value greater than 1 indicates a positive. (discloses grouping by sentiment) Application service management (ASM) covers open & closed tickets, average ticket age, mean time to recovery/restore/repair (MTTR), mean time to service (MTTS) compliance by priority, volumetric metrics by portfolio, status, root cause analysis (RCA), priority. Out of the box connectors for JIRA, VersionOne, TFS, VSTS, SonarQube, Jenkins, ServiceNow & HP-ALM. Quality parameters covers—code quality that includes code complexity, vulnerability, code coverage, function point analysis, job statistics by status. ex—SonarQube. Quality parameters covers build quality that includes job statistics by status, build statistics, test statistics by job, job statistics by status. Ex—Jenkins. Test statistics by job covers team's average defect density (defects/story points), program avg. defect density, team's average % unit test coverage, program % unit test coverage and QA performance covers team's average defect density (defects/story points), program avg. defect density, team's average % unit test coverage, program % unit test coverage), (Id., ¶ 91, All subsequent views would be the same for all users with the relevant work stream and data point restricted access. A near real time view of backlog health would directly reflect on the feature clarity and hence the efficiency of the product owner, a near real time view of the impediment scorecard would directly reflect on the impediment status and hence the efficiency of the scrum master. Along with the work completion trend the release burn down also tracks requirement volatility trends by sprint to help in predicting a revised date of delivery as a result of the voice of customer in a multi-vendor scenario solution provides comparative analysis at the vendor and the consultant level), (Id., ¶ 92, Story point analysis, such as 304f provides comparative analysis on story points delivered by each consultant, by project and by sprint. Summary analysis across consultants is comparative analysis giving the count of delivered user stories tasks subtasks and defects by each consultant resource productivity gives count of tasks and subtasks delivered by the selected consultant, by project and by sprint. Further, cost time and scope variants are used as the contributing factors to determine predictability. The concept of earned value measurement in agile to measure the cost performance index and schedule performance index to depict cost and schedule variance respectively. The CPI and SPI value greater than one indicates a positive. The ratio of accepted and committed story points calculates the scope variants. A positive scope variance indicates that the team delivered more than commitment. This shows the quality of deliverable by test case coverage and testing execution outcomes until the last completed by sprint. There are various other dashboard attributes, metrics, pertaining to business, customizable by users and dependent on type of software development tools used or required).
While suggested in at least Fig. 2 and related text of Fox, the combination of Fox and Nagar does not explicitly disclose … using natural language processing, the communication thread is broken down into sub-component parts and the parts are individually validated to identify sentiment bearing phrases through word associations, the KPI score is assigned to each phrase in the sub-component parts such that the KPI score is proportional to a degree to which sentiment is expressed
However, Muddakkagari discloses …using natural language processing, the communication thread is broken down into sub-component parts and the parts are individually validated to identify sentiment bearing phrases through word associations, the KPI score is assigned to each phrase in the sub-component parts such that the KPI score is proportional to a degree to which sentiment is expressed… (Muddakkagari,¶ 6, In accordance with other embodiments of the present disclosure, another example method comprises: receiving, by a first computing device having at least one processor and from a user device of a user via a communication network, a request to receive information concerning a software application development across a development operations (DevOps) pipeline; identifying the software application development and query parameters from the request; forming, using a natural language processing (NLP) application, a query comprising an identifier of the software application development (discloses natural language processing) and the query parameters; sending the query to a second computing device, wherein the second computing device is associated with an integration of a plurality of DevOps tools in the DevOps pipeline; receiving, from the second computing device, a response to the request to receive information; presenting the response to the user device via the communication network), (Id., ¶ 21, Some users may desire to know, via their user devices 102A-102C, a characteristic of a specific aspect of an application's development. For example, a user may wish to know the status of a build, or a quality metric for the build. (discloses KPIs) The devices 102A-102C for such users may be configured to transmit a query over the communication network 104 to the query response system 110. An inquiring user may input its query, via a user device 102A-102C, in natural language, e.g., via text, audio etc. The query response system 110 may be configured to process the natural language input, e.g., via its natural language processor (NLP) 114, and facilitate a response for presentation to the user device), (Id., ¶ 51, Thus, the NLP system 114 may use its library of tools and stored data and language recognition functionalities to identify and determine a query from the received input. Examples of the NLP system's functionalities may include, but are not limited to: syntax recognition (e.g., grammar induction, lemmatization, morphological segmentation, part-of-speech tagging, parsing, sentence breaking, stemming, word segmentation, terminology extraction, etc.); semantics recognition (e.g., lexical semantics, machine translation, named entity recognition (NER), natural language generation, natural language understanding, optical character recognition (OCR), question answering, textual entailment recognition, relationship extraction, sentiment analysis, topic segmentation, word sense disambiguation, etc.); discourse analysis and summarization; and audio speech recognition and segmentation), (Id., ¶ 52, At step 306, the query/response system 110 may determine whether the identified query is an appropriate form. In one aspect, form appropriateness may be the degree to which one or more components of the query/response system 110 (e.g., the AIML interpreter) may be able to execute commands based on the query alone. The commands may include searching for or generating a response to the identified query. Furthermore, a query may not be in form if there are issues with syntax, semantics, and/or the discourse of the query, as identified by the tools and functionalities of the NLP system 114 described above. If the query is not in form, the query may be reformatted and/or rephrased (e.g., as in step 308). This may be performed by the NLP system (e.g., via the pre-processor 116A) and/or the calibrator 126 (e.g., to solicit a specific or better response). Also or additionally, the user may be prompted to reformat or rephrase the query).
It would have been obvious to a person of ordinary skill in the art before the effective filing date to have modified the software development risk assessment elements of Fox and the decision tree and spillover risk elements of Nagar to include the NLP elements of Muddakkagari in the analogous art of automating and monitoring software development operations for the same reasons as stated for claim 1.
Regarding Claim 3, the combination of Fox, Nagar and Muddakkagari discloses …the system as claimed in claim 2…
Fox further discloses …wherein the processor performs analysis of the KPI score to determine if the communication threads have KPI scores across multiple sentiments, and groups the unstructured attribute dataset comprising such communication threads as the mixed grouped sentiment dataset, and wherein the processor performs analysis of the KPI score and groups the unstructured attribute dataset comprising communication threads as a neutral grouped sentiment dataset in the event the KPI scores are determined to be low (Id., ¶ 90, Key metrics beyond source application program or project to support detailed reporting for continuous improvements from agile teams to senior management includes productivity, predictability, quality and ROI. Productivity option 304a, metric 306a covers team's average velocity, program velocity, impediments scorecard, release burn down w/all dimensions, vendor productivity. This ranges release burn down, other than work completion trend, it also tracks requirement volatility trends by sprint to help predict revised date of delivery. Impediment score card 308 would directly reflect on the impediment status and hence the efficiency of the scrum master backlog health would directly reflect on the feature clarity and hence the efficiency of the product owner. Predictability option 304b, metric 306b covers scope variance, schedule variance, cost variance, SPI & CPI (EVM), supports predictability around time, cost, scope. concept of earned value measurement in agile to measure the cost performance index i.e. CPI and schedule performance index i.e. SPI. The CPI and SPI value greater than 1 indicates a positive. (discloses grouping by sentiment) Application service management (ASM) covers open & closed tickets, average ticket age, mean time to recovery/restore/repair (MTTR), mean time to service (MTTS) compliance by priority, volumetric metrics by portfolio, status, root cause analysis (RCA), priority. Out of the box connectors for JIRA, VersionOne, TFS, VSTS, SonarQube, Jenkins, ServiceNow & HP-ALM. Quality parameters covers—code quality that includes code complexity, vulnerability, code coverage, function point analysis, job statistics by status. ex—SonarQube. Quality parameters covers build quality that includes job statistics by status, build statistics, test statistics by job, job statistics by status. Ex—Jenkins. Test statistics by job covers team's average defect density (defects/story points), program avg. defect density, team's average % unit test coverage, program % unit test coverage and QA performance covers team's average defect density (defects/story points), program avg. defect density, team's average % unit test coverage, program % unit test coverage), (Id., ¶ 91, All subsequent views would be the same for all users with the relevant work stream and data point restricted access. A near real time view of backlog health would directly reflect on the feature clarity and hence the efficiency of the product owner, a near real time view of the impediment scorecard would directly reflect on the impediment status and hence the efficiency of the scrum master. Along with the work completion trend the release burn down also tracks requirement volatility trends by sprint to help in predicting a revised date of delivery as a result of the voice of customer in a multi-vendor scenario solution provides comparative analysis at the vendor and the consultant level), (Id., ¶ 92, Story point analysis, such as 304f provides comparative analysis on story points delivered by each consultant, by project and by sprint. Summary analysis across consultants is comparative analysis giving the count of delivered user stories tasks subtasks and defects by each consultant resource productivity gives count of tasks and subtasks delivered by the selected consultant, by project and by sprint. Further, cost time and scope variants are used as the contributing factors to determine predictability. The concept of earned value measurement in agile to measure the cost performance index and schedule performance index to depict cost and schedule variance respectively. The CPI and SPI value greater than one indicates a positive. The ratio of accepted and committed story points calculates the scope variants. A positive scope variance indicates that the team delivered more than commitment. This shows the quality of deliverable by test case coverage and testing execution outcomes until the last completed by sprint. There are various other dashboard attributes, metrics, pertaining to business, customizable by users and dependent on type of software development tools used or required).
Regarding Claim 4, the combination of Fox, Nagar and Muddakkagari discloses …the system as claimed in claim 1…
Fox further discloses …wherein the structured attribute dataset comprises a first attribute data representing unique requirement identifiers assigned by a standard project management system corresponding to the software development lifecycle of projects, and wherein the structured attribute dataset comprises a second attribute data representing base requirements provided by a team which is split at a functional or a technical level, and wherein the base requirements include modules and segments associated with user interface, database connectivity, error control, reporting that are required to build a software system corresponding to the software development lifecycle of projects (Fox, ¶ 70, a system 104 has hardware and software requirements of deployment as an OS: Windows server 2012 R2 or higher; a web server: IIS 7+; .NET: MS .NET Framework 4.5; RAM: 8 GB (Web), 16 GB (DB); Storage: 50 GB (Web), 100 GB (DB); Processor: 4 cores; SQL Server: SQL Server 2016+ (standard edition); Connectivity: standard access all required projects on JIRA, Jenkins, SonarQube, etc. and has ability to configure Windows service (web server only). The existing instance of an MS SQL Server can be leveraged by adding solution application schema or a dedicated MS SQL Server that will be required for the solution application. As the load increases the hardware configuration has to be scaled up. In one example, it supports JIRA, VersionOne, ServiceNow (4 Metrics), Jenkins, SonarQube. (discloses standard project management systems) Any customization/new ALM connector would require more effort based on the requirement. (discloses unique requirement identifiers) The source systems used are JIRA, Jenkins, SonarQube. In this implementation, access & permissions required are web server permissions to install web application, permissions to configure Windows services (connectors), user with read only access to source systems (JIRA, Jenkins and SonarQube) Web API, read/write access to database, SMTP server details to send email notifications and with SQL Server for DB creation (to create database) and a database user with read/write access to the database), (Id., ¶ 81, The agile module 210 of the analytical component 112 follows the agile approach of dividing tasks into short phases of work and frequently reassessing and adapting new approaches in order to ensure quality deliverables in a timely manner. The agile module 210 performs its task by overlooking activities and providing insights on the same. The activities include but may not be limited to capturing requirements, constructing or initiating work, (discloses base requirements) reviewing the constructed work, deploying the same, testing the work for errors, (discloses error control) releasing the work to the next level of stakeholders and eventually managing the work. Further, the agile module 210 manages agility by doing and being agile through various agile coaches including but not limited to agile documentation, collaborative planning, continuous integration and delivery, low process ceremony, paired programming, agile estimation, continuous improvement, evolutionary requirements, multi-level adaptive planning and self-organizing team. Additionally, the agile module also calculates an agile maturity index scores for enhancing performance), (Id., ¶ 73, A dashboard framework system 104 implements a method for dashboard framework 200 on a web and application server 102 or a web server 102, the dashboard framework system 104 also known as web and application system 104 includes a display component 110 or a dashboard interface, a connector agent 202, an analytical component 112 or a web API, and other components 114. The display component 110 allows the system 104 to interact with a user 150. The analytical component 112 comprises an agile module 210, a vendor module 212, a test case module 214, an analytics engine 216, and other modules 220. The analytical component 112 communicates with a connector component 204 having a connector service 116 and further connected to a plurality of sub-connectors 204a, 204b, 204c, 204d, . . . , 204n, such as a JIRA connector, a Jenkins connector, a SonarQube connector, a ServiceNow connector, an Excel connector, and alike for each program, project, or such source systems/applications 130. Each of the sub-connectors 204a, 204b, 204c, 204d, . . . , 204n are respectively coupled to one of a plurality of third party program, project, or such source systems 130 or applications, such as 132a, 132b, 132c, 132d, . . . , 132n, such a JIRA, a Jenkins, a SonarQube, a ServiceNow, an Excel file programs. Further, the components of the system 104 communicates to other computing devices, ex web servers and external data servers, such as a DB server 120 having a database system 122 and a database 124).
Regarding Claim 5, the combination of Fox, Nagar and Muddakkagari discloses …the system as claimed in claim 1…
Fox further discloses …wherein the structured attribute dataset comprises a third attribute data representing a count of number of days for completing technical or functional requirements in a work item, the third attribute is scaled in between a value of 1-8 days, and wherein the structured attribute dataset comprises a fourth attribute data representing an urgency of the work items, sequence in which tasks are to be accomplished and a level of significance of the work items, the fourth attribute data may be represented as a major, a medium, a minor and a rush in a scale, wherein rush represents an ad-hoc requirement (Fox, ¶ 90, Key metrics beyond source application program or project to support detailed reporting for continuous improvements from agile teams to senior management includes productivity, predictability, quality and ROI. Productivity option 304a, metric 306a covers team's average velocity, program velocity, impediments scorecard, release burn down w/all dimensions, vendor productivity. This ranges release burn down, other than work completion trend, it also tracks requirement volatility trends by sprint to help predict revised date of delivery. Impediment score card 308 would directly reflect on the impediment status and hence the efficiency of the scrum master backlog health would directly reflect on the feature clarity and hence the efficiency of the product owner. Predictability option 304b, metric 306b covers scope variance, schedule variance, cost variance, SPI & CPI (EVM), supports predictability around time, cost, scope. concept of earned value measurement in agile to measure the cost performance index i.e. CPI and schedule performance index i.e. SPI. The CPI and SPI value greater than 1 indicates a positive. Application service management (ASM) covers open & closed tickets, average ticket age, mean time to recovery/restore/repair (MTTR), mean time to service (MTTS) compliance by priority, (discloses urgency attribute) volumetric metrics by portfolio, status, root cause analysis (RCA), priority. Out of the box connectors for JIRA, VersionOne, TFS, VSTS, SonarQube, Jenkins, ServiceNow & HP-ALM. Quality parameters covers—code quality that includes code complexity, vulnerability, code coverage, function point analysis, job statistics by status. ex—SonarQube. Quality parameters covers build quality that includes job statistics by status, build statistics, test statistics by job, job statistics by status. Ex—Jenkins. Test statistics by job covers team's average defect density (defects/story points), program avg. defect density, team's average % unit test coverage, program % unit test coverage and QA performance covers team's average defect density (defects/story points), program avg. defect density, team's average % unit test coverage, program % unit test coverage), (Id., ¶ 91, All subsequent views would be the same for all users with the relevant work stream and data point restricted access. A near real time view of backlog health would directly reflect on the feature clarity and hence the efficiency of the product owner, a near real time view of the impediment scorecard would directly reflect on the impediment status and hence the efficiency of the scrum master. Along with the work completion trend the release burn down also tracks requirement volatility trends by sprint to help in predicting a revised date of delivery (discloses number of days for completing requirements) as a result of the voice of customer in a multi-vendor scenario solution provides comparative analysis at the vendor and the consultant level).
Regarding Claim 6, the combination of Fox, Nagar and Muddakkagari discloses …the system as claimed in claim 1…
Fox further discloses … wherein the structured attribute dataset comprises a fifth attribute data representing a count of people that have worked or are working on a work item, wherein with increase in complexity in the software development lifecycle of projects a count of the fifth attribute data increases, and wherein the structured attribute dataset comprises a sixth attribute data representing a length of a field in a project management system comprising textual description of technical and functional requirements in words and characters (Fox, ¶ 76, a user 150 accesses a display component 110 via a user authentication module 152. A user to project mapping is maintained in a database, such as a database 124 or alike. Any user authorization or authentication is controlled using this mapping (discloses tracking users working on an item). A default user is created in advance; all additional users are authenticated using the user authentication module 152. The authentication happens, outside a web server 102, managed by identity and access management (IAM) systems or lightweight directory access protocol (LDAP) or alike), (Id., ¶ 80, The analytical component 112 performs analytics, using specific calculations in order to derive descriptive analytics, predictive analytics and prescriptive analytics from the data supplemented to the analytical component 112 from the connector component 204 while providing flexible and run-time view of information in terms of technical, business and operational metrics. Further, the analytical component 112 derives analytics from the supplemented data mainly for the attributes including but not limited to predictability, productivity, quality, maturity and return-on-investment in order to provide insightful facts to be utilized by the user for business-related decision-making. The analytical component 112 facilitates to provide story-point analysis for monitoring a program 130 throughout its lifecycle over the various stakeholder levels, and a risk-projection analysis wherein projects at risk of derailment or delay are highlighted and brought to attention, such that appropriate action may be taken to minimize all possible risk factors and ensure timely delivery).
Regarding Claim 7, the combination of Fox, Nagar and Muddakkagari discloses …the system as claimed in claim 1…
Fox further discloses …wherein the structured attribute dataset comprises a seventh attribute data representing a count of a number of similar work items, tasks, bugs that have dependency on the work items, wherein a higher count indicates a higher complexity, and wherein the structured attribute dataset comprises an eighth attribute representing a count of number of times a closure of a work item is postponed on account of the work item not being completed within its due date, the eighth attribute is represented as a spill count that is a count of number of times the work item is not completed on time, the eighth attribute is represented as 'no' in the event the spill count is zero, 'low' in the event the spill count is one and requirement is completed, and 'high' in the event spill count is more than one and requirement is completed (Id., ¶ 85, The analytics engine 216 facilitates the various analytics required to track the progress of a project or program effectively. The analytics engine 216 of the analytical component 112 tracks the progress of a project by way of parameters including but not limited to trend analysis, defect analysis, critical and high defect fixes, defect density, defects by status, as well as defects by severity, code or work quality and build quality), (Id., ¶ 97, Test coverage completion execution pass and execution failure gives test quality baseline to date to be considered during a retrospective. Test cases execution trend analysis 306 gives further breakdown by status 308 taken as the basis to showcase the trend analysis. Defect analysis is used to portray the quality of sprint outcomes to date another quality bass line to make a sprint retrospective more productive. Critical and high defect fix a ratio of critical and high severity defects raised to defects fixed giving an inference on sprint or release stability. Defect density, this gives the density of defects by sprint, is the weighted average by defect criticality to the number of story points delivered defects by status this gives and near real time depiction of defects categorized by status by sprint or by release. Defects by severity, gives a near real time depiction of defects categorized by severity by sprint or release), (Id., ¶ 98, Solution also analyses trade-offs and team productivity against code quality, automated code review tools such as SonarQube and are the source for the static code analysis measurements covering code complexity, code coverage, function count and technical debt. Continuous build and deployment is a given for optimal agility the focus here is the status on jobs governing automated builds and deployments at a project and code base branch level to help in root cause analysis. The dashboard 302 shows the measurable insights for projects following the campaign model. Measurements can be analysed at daily, weekly, monthly, quarterly, yearly and at any customizable period levels. Mean lead and cycle time with throughput allow one to take inclusive actions on productivity improvement measures while the average aging helps eliminate process and productivity blocks and improve team efficiency. FIG. 3.3 represent a view as per a dashboard 302, described above. There are many such options available as per business or user needs. It is only one representation that is shown by way of example), (Id., ¶ 101, The ASM dashboard provides near real time operational metrics to monitor and drive high quality to our customers there are multiple views by process, region, and portfolio. It showcases summarized visualization of incidents problems and change request by service SLAs timely RCA and schedule variance respectively for each of these views. Portfolio view provides a bird's-eye view at enterprise level of operational metrics including volume trends and SLA compliance it gives a near real time tickets trend analysis for a carefully selected set of metrics for the given period. Volume metric trends provides various representations of ticket volume by key dimensions including portfolio priority and status. The solution improves an enterprise's scaled agile maturity and enhance engineering effectiveness to maintain business agility. FIG. 3.4 represent a view as per a dashboard 302, described above. There are many such options available as per business or user needs. It is only one representation that is shown by way of example).
Regarding Claim 9, the combination of Fox, Nagar and Muddakkagari discloses …the system as claimed in claim 1…
Fox further discloses … wherein the processor is configured to process the structured attribute dataset by performing standardisation of the structured attribute dataset via a z-transform technique, and wherein a scaled attribute data is generated by removing scaling biasness such that the z-transform is used to represent variability in one or more attribute data in the structured attribute dataset, and wherein the processor is configured to remove a plurality of standardised attributes from the structured attribute dataset, along with a personal identifiable information and sensitive information through masking or conversion to metadata (Fox, ¶ 32, It is a primary object of the present subject matter to provide a system and a method for a software development dashboard that can collect data from a variety of systems, applications, projects, programs, and portfolios, transform the data, and derive useful analytics, and then display the derived analytics to an individual or a group of individuals who need to make decisions. In addition, the software development dashboard system may enable high-performance teams achieve optimal engineering effectiveness while maintaining maximum transparency and reliability), (Id, ¶ 116, In one other example, for a health care company a business challenge involved unprecedented view into software development lifecycle (SDLC) effectiveness, business units make technology decisions without long term considerations, continuous improvement tool for monitoring & risk identification at various decision making levels (scrum teams, projects, product/program, portfolio, org) and flexible view using data points from descriptive, predictive and prescriptive analytics. The solution provides wide range of technical, business & operational metrics with advanced analytics and industry benchmarking, single source of truth within IQVIA to enable stakeholders take informed decision. Proactive identification of pain areas to enable the team take preventive and corrective course to deliver deliverables on time and align business units on priorities to eliminate duplicate efforts and disjointed experience. The solution covered agile transformation of all business units comprising of software development and maintenance types of work to IQVIA scaled agile framework called HPE (high performance enterprise). The solution further provides enterprise dashboard tool that can be implemented across various user groups. The solution was implemented in the following sequence: backbone to achieve engineering effectiveness & a high performance enterprise, collects data from various IQVIA engagements to establish own agile benchmarks. The outcomes achieve dare tracking and monitoring, the increase in productivity by 20% from baselines using enterprise dashboard solution, improvement in quality by reducing production incidents by at least 10% by tracking quality metrics and overall improvement in agile maturity in organization leveraging solution to baseline and track the KPI's).
Regarding Claim 10, the combination of Fox, Nagar and Muddakkagari discloses …the system as claimed in claim 1…
Fox further discloses …wherein the processor is configured to correlate the derived attribute data with the defined attribute data to identify a significant gap in a derived story point and a defined story point that signifies a gap in an estimation analysis and consequently a potential risk to subsequent tasks, the derived attribute data is a pre-processed third attribute data that represents a rescaled value of a complexity noise, and wherein the processor is configured to rescale the value of the derived third attribute data to a value of 1-8 (Fox, ¶ 83, The vendor module 212 of the analytical component 112 assists in keeping track of vendor records and productivities, especially for outsourced work, this further assist in keeping key performance indicators (KPI) of a vendor or a consultant. The KPI generally include productivity, efficiency, quality or other performance indicators as requisite for a particular business. The vendor module 212 comprised in the analytical component 112 calculates vendor productivity on the basis of multiple factors including but not limited to comparative analysis at the vendor and consultant level, story point analysis, (discloses story point analysis) summary analysis, resource productivity, and predictability including cost, time and scope variants. Predictability may also be calculated on the basis of a schedule performance index and a cost performance index), (Id., ¶ 81, The agile module 210 of the analytical component 112 follows the agile approach of dividing tasks into short phases of work and frequently reassessing and adapting new approaches in order to ensure quality deliverables in a timely manner. The agile module 210 performs its task by overlooking activities and providing insights on the same. The activities include but may not be limited to capturing requirements, constructing or initiating work, reviewing the constructed work, deploying the same, testing the work for errors, releasing the work to the next level of stakeholders and eventually managing the work. Further, the agile module 210 manages agility by doing and being agile through various agile coaches including but not limited to agile documentation, collaborative planning, continuous integration and delivery, low process ceremony, paired programming, agile estimation, continuous improvement, evolutionary requirements, multi-level adaptive planning and self-organizing team. Additionally, the agile module also calculates an agile maturity index scores for enhancing performance), (Id., ¶ 90, Key metrics beyond source application program or project to support detailed reporting for continuous improvements from agile teams to senior management includes productivity, predictability, quality and ROI. Productivity option 304a, metric 306a covers team's average velocity, program velocity, impediments scorecard, release burn down w/all dimensions, vendor productivity. This ranges release burn down, other than work completion trend, it also tracks requirement volatility trends by sprint to help predict revised date of delivery. Impediment score card 308 would directly reflect on the impediment status and hence the efficiency of the scrum master backlog health would directly reflect on the feature clarity and hence the efficiency of the product owner. Predictability option 304b, metric 306b covers scope variance, schedule variance, cost variance, SPI & CPI (EVM), supports predictability around time, cost, scope. concept of earned value measurement in agile to measure the cost performance index i.e. CPI and schedule performance index i.e. SPI. The CPI and SPI value greater than 1 indicates a positive. Application service management (ASM) covers open & closed tickets, average ticket age, mean time to recovery/restore/repair (MTTR), mean time to service (MTTS) compliance by priority, volumetric metrics by portfolio, status, root cause analysis (RCA), priority. Out of the box connectors for JIRA, VersionOne, TFS, VSTS, SonarQube, Jenkins, ServiceNow & HP-ALM. Quality parameters covers—code quality that includes code complexity, vulnerability, code coverage, function point analysis, job statistics by status. ex—SonarQube. Quality parameters covers build quality that includes job statistics by status, build statistics, test statistics by job, job statistics by status. Ex—Jenkins. Test statistics by job covers team's average defect density (defects/story points), program avg. defect density, team's average % unit test coverage, program % unit test coverage and QA performance covers team's average defect density (defects/story points), program avg. defect density, team's average % unit test coverage, program % unit test coverage), (Id., ¶ 102, Other benefits of the solution covers, cloud deployments, for example on AZURE, ASM-SLA based tracking on volumetric & timeliness metrics, easily configurable & customizable, scaled agile model metrics reporting, agile maturity index scores, aggregated views and filters at project, program and portfolio level, alerts and notifications on specific threshold, and downloadable reports for offline project reviews).
Regarding Claim 11, the combination of Fox, Nagar and Muddakkagari …the system as claimed in claim 1…
Fox further discloses … wherein the processor is configured to fetch a pre- processed structured attribute dataset and execute a predictability model on the pre-processed structured attribute dataset based on pre-defined values, and wherein the processor is configured to map each of the attribute data of the structured attribute dataset using the predictability model to different categorical values including the spillover risk values in terms of high, low, no and defect density in terms of high, medium, low or no, and wherein the processor is configured to traverse decision nodes in the decision tree structure recursively using the predictability model, and wherein the processor is configured to select an optimal split in the structured attribute dataset at each level in the decision tree structure until further splits are possible… (Id., ¶ 114, In an example, for an as-is implementation plan, a connector component 204 extracts the details from external third parties such as JIRA, TFS, SonarQube and an analytical component 112 manages data between a database 124 and an application on the display component 110 that consists of admin and metric application. A connector service 116 of the connector component 204 is a Windows service that extracts the Jira data in a specified interval. A due diligence is conducted via assigning an expert; providing access to ALM (JIRA); analysing ALM tool for readiness and identifying any custom needs; agree on as-is predictability and productivity metrics; review testing tool, code quality tool, build automation tool; providing access to testing, build and code quality tool; agree on as-is quality, build and code quality metrics; agree on pilot project(s) to be integrated for as-is implementation. The infrastructural prerequisites are 2 servers—1 web server and 1 SQL server; provide access to expert to deploy and configure solution application), (Id., ¶ 90, Key metrics beyond source application program or project to support detailed reporting for continuous improvements from agile teams to senior management includes productivity, predictability, quality and ROI. Productivity option 304a, metric 306a covers team's average velocity, program velocity, impediments scorecard, release burn down w/all dimensions, vendor productivity. This ranges release burn down, other than work completion trend, it also tracks requirement volatility trends by sprint to help predict revised date of delivery. Impediment score card 308 would directly reflect on the impediment status and hence the efficiency of the scrum master backlog health would directly reflect on the feature clarity and hence the efficiency of the product owner. Predictability option 304b, metric 306b covers scope variance, schedule variance, cost variance, SPI & CPI (EVM), supports predictability around time, cost, scope. concept of earned value measurement in agile to measure the cost performance index i.e. CPI and schedule performance index i.e. SPI. The CPI and SPI value greater than 1 indicates a positive. Application service management (ASM) covers open & closed tickets, average ticket age, mean time to recovery/restore/repair (MTTR), mean time to service (MTTS) compliance by priority, volumetric metrics by portfolio, status, root cause analysis (RCA), priority. Out of the box connectors for JIRA, VersionOne, TFS, VSTS, SonarQube, Jenkins, ServiceNow & HP-ALM. Quality parameters covers—code quality that includes code complexity, vulnerability, code coverage, function point analysis, job statistics by status. ex—SonarQube. Quality parameters covers build quality that includes job statistics by status, build statistics, test statistics by job, job statistics by status. Ex—Jenkins. Test statistics by job covers team's average defect density (defects/story points), program avg. defect density, team's average % unit test coverage, program % unit test coverage and QA performance covers team's average defect density (defects/story points), program avg. defect density, team's average % unit test coverage, program % unit test coverage).
While suggested in at least Fig. 2 and related text of Fox, the combination of Fox and Nagar does not explicitly disclose …and wherein a entropy reduction technique is employed to perform the optimal slit.
However, Muddakkagari discloses …and wherein a entropy reduction technique is employed to perform the optimal slit (Muddakkagari, ¶ 32, The NLP system 114 may include various processors (pre-processor 116A, post-processor 116B), libraries (e.g., library 118), and Al-based systems (e.g., machine learning (ML) tool 120) to analyze and convert natural language to one that could result in a computing system to perform substantive functions (e.g., find a response to the query). Using the pre-processor 116A, the NLP system 114 may rephrase and/or reformat the query for computing systems (e.g., AIML Interpreter 122, DevOps system 130, etc.) to understand. In some aspects, the NLP may also determine whether the query is a dynamic or a static query, as will be discussed further below. Using post-processor 116B, the NLP system 114 may rephrase and/or reformat a proposed response to a query, e.g., so that it may be understandable to a user of the user device 102A-102C that sent the original query. In some aspects, the NLP 114 may assess a proposed response, and upon determining that the proposed response is incorrect, unsatisfactory, or misguided, can facilitate a new response. The NLP system 114 may be guided by a library 118 (e.g., database, look-up tables, repository, etc.) and Al-based tools (e.g., ML tool 120) for various uses in natural language processing, including the undergoing of supervised and unsupervised learning from language data. Together with its library 118, the ML tool 120 may support common NLP tasks, such as tokenization, sentence segmentation, part-of-speech tagging, named entity extraction, chunking, parsing, and coreference resolution. These tasks may be needed to build more advanced text processing services. The ML tool 120 may also include maximum entropy and perceptron based machine learning tools. The NLP system 114 and/or query engine 112 may determine whether a received query solicits a static or dynamic response. For example, a static response may invoke a simple retrieval of information from a local database 124, e.g., of an AIML interpreter 122. A dynamic response may involve invoking the DevOps System 130, which may investigate specific event(s) of an application development from various DevOps tools 138A-138E and their respective source integrators 136A-136E), (Id., ¶ 35, The query/response system 110 may further include a calibrator 126. The calibrator 126 may be an interface, plug-in, application, and/or subsystem of the query/response system 110 that can reformat queries if the proposed responses is not a desired response, e.g., whether the response is appropriate. In some aspects, the user device 102A-102C may inform the calibrator that a response is not the desired response to the query. For example, an AIML interpreter may receive a query that appears to solicit a static response. The calibrator may notice that the AIML interpreter does not have the answer to the query in static form, e.g., the query is “out-of-bound.” Consequently, the calibrator may reformat the query so that the query/response system 110 may solicit non-static responses (e.g., dynamic responses) for the query. An “out-of-bound” response may signify, for example, that the AIML Interpreter 122 cannot determine or find a static response to a query locally (e.g., using database 124). Thus, the calibrator 126 may assist in calibrating queries after receiving an “out-of-bound” response from the AIML interpreter 122).
It would have been obvious to a person of ordinary skill in the art before the effective filing date to have modified the software development risk assessment elements of Fox and the decision tree and spillover risk elements of Nagar to include the entropy elements of Muddakkagari in the analogous art of automating and monitoring software development operations for the same reasons as stated for claim 2.
Regarding Claim 12, the combination of Fox, Nagar and Muddakkagari discloses …the system as claimed in claim 11…
Fox further discloses … and wherein the spillover risk values indicate that an assigned task is spilled over an assigned deadline and is causing delay in the software development life cycle projects, and wherein the processor is configured to split the parent root node into child nodes based on pre-defined threshold values, and wherein the processor branches the decision tree structure and derives of a learning pattern that is applied to records of the structured attribute datasets, the records are classified as a risk or a non-risk record, and wherein the processor repeats a process of determining information retention in the decision tree structure that results in an iterative nature of the predictability model, and wherein a second new attribute is determined and a second branching point (node) is created (Id., ¶ 59, A few of the important features, the solution offers are a customizable options set, set targets and thresholds for key metrics, send alerts when thresholds are not met, collects data at various periodical intervals, detects and mitigates early risks, reviews formally by project governance team monthly and executive team quarterly, provide near real time status & consolidated insight for quick and informed decision-making to elevate team performance. It is capable of interfacing with a variety of application lifecycle management (ALM) tools/data sources in order to perform descriptive analytics, predictive & prescriptive analytics. Also, it's wide range of technical(e.g. code quality, technical debt etc.), business (e.g. ROI) and operational (e.g. productivity, predictive etc.) metrics providing transparency across all stakeholders throughout the process. Unique metrics includes but not limited to predictability, sprint injection, backlog health, impediment scorecard, ROI, code performance index (CPI), schedule performance index (SPI), resource productivity, and alike), (Id., ¶ 114, In an example, for an as-is implementation plan, a connector component 204 extracts the details from external third parties such as JIRA, TFS, SonarQube and an analytical component 112 manages data between a database 124 and an application on the display component 110 that consists of admin and metric application. A connector service 116 of the connector component 204 is a Windows service that extracts the Jira data in a specified interval. A due diligence is conducted via assigning an expert; providing access to ALM (JIRA); analysing ALM tool for readiness and identifying any custom needs; agree on as-is predictability and productivity metrics; review testing tool, code quality tool, build automation tool; providing access to testing, build and code quality tool; agree on as-is quality, build and code quality metrics; agree on pilot project(s) to be integrated for as-is implementation. The infrastructural prerequisites are 2 servers—1 web server and 1 SQL server; provide access to expert to deploy and configure solution application), (Id., ¶ 89, The landing page of the enterprise dashboard gives a quick snapshot elaborating multiple critical attributes covering current status and the trend till date. It provides a view at the enterprise business unit or portfolio, program, project and in a few cases team and individual levels allowing users to drill down to a closer level of detail. Logged in users can see data and work stream metrics, such as 306, 308 at their respective levels. Projects at risk are highlighted and alerts are triggered when they fall below the threshold. Return on investment (ROI), for example at 304d, is another important metric for C-level executives showcasing efficiency of investment. ROI graph, for example at 308, shows the expected spend against the actual spend along with allied details, it also gives details of the projected investment, if relevant financial data points are made available for integration.
While suggested in at least Fig. 2, Fox does not explicitly disclose …wherein the processor is configured to construct the decision tree structure by selecting an attribute data of the structured attribute dataset as a parent root node and a parameter for splitting the decision tree structure to predict the spillover risk values…
However, Nagar discloses …wherein the processor is configured to construct the decision tree structure by selecting an attribute data of the structured attribute dataset as a parent root node and a parameter for splitting the decision tree structure to predict the spillover risk values… (Nagar, ¶ 33, The decision-tree based approach may allow the software development company to systematically build a decision-tree risk-profile for each task or set of tasks considered for outsourcing. In some embodiments, the decision-tree based approach may allow the software development company to consider the risks of outsourcing each task or set of tasks to one or more different vendors. By building the decision-tree risk-profile, the software development company may be able to quantify the risks and calculate the expected monetary costs of all possible task-vendor combinations of the risk-profile), (Id., ¶ 35, FIG. 4 shows a next step in the exemplary process of building a decision-tree. At this next step, the software development company may determine the business tasks to be outsourced by using its previously completed risk-profile analysis. The company at this step may need to consider the possibilities of outsourcing either the complete business process (CBP) or a subset of the tasks in the CBP, a decision the software development company may make at outsourcing node 400. To make this decision, the software development company may identify the risks associated with each task, possibly using the risk-profile developed earlier. As shown in step 150 in FIG. 1, the company may also identify a set of vendors for each set of tasks considered for outsourcing), (Id., ¶ 37, With each vendor having its own node, the software development company may associate with each vendor's node the risk-percentage for outsourcing the CBP to that specific vendor. The software development company may begin this process by assigning risk percentages to risks shared by all vendors. This risk percentage may be calculated using the previously-identified risks in the task-vendor risk-profiles. For example, a software development company may associate a sixty percent risk of knowledge transfer to outsourcing the CBP to any vendor, regardless of the vendor chosen. The software development company may assign this risk percentage to link 410, which connects outsourcing node 400 with complete business process node 415).
It would have been obvious to a person of ordinary skill in the art before the effective filing date to have modified the software development risk assessment elements of Fox to include the decision tree and spillover risk elements of Nagar in the analogous art of outsourcing software development for the same reasons as stated for claim 1.
Regarding Claim 13, the combination of Fox, Nagar and Muddakkagari discloses …the system as claimed in claim 11…
While suggested in at least Fig. 2, Fox does not explicitly disclose … wherein the processor is configured to apply the iterative logic to predict defect density values in the software development lifecycle of projects using a decision tree-based classifier with a target variable set to a derived project attribute where bug occurrences indicate number of valid defects found, and wherein the processor re-uses the structured attribute data set to predict the defect density on a set of current or future tasks.
However, Nagar discloses … wherein the processor is configured to apply the iterative logic to predict defect density values in the software development lifecycle of projects using a decision tree-based classifier with a target variable set to a derived project attribute where bug occurrences indicate number of valid defects found, and wherein the processor re-uses the structured attribute data set to predict the defect density on a set of current or future tasks. (Nagar, ¶ 53, The KPIs to measure vendor performance may include factors such as cost, on-time delivery, code quality, and software performance. Most of these KPIs may be tangible and directly related to the vendor. The cost component may be measured against the expected cost for performing similar function internally within the software development company. Cost overruns may be a factor when measuring this KPI. On-time delivery may be measured against specified due dates. A good measure of code quality may be the number of bugs in the developed code. Finally, software performance may be measured against metrics such as computational performance, load time, scalability, and performance as perceived by the users), (Id., ¶ 43, A software development company may associate individual risks for outsourcing a specific subset of the tasks of the CBP to a specific vendor with the link connecting that vendor to the specific subset node 510 or 520. For example, outsourcing subset X of the CBP to vendor i may involve a fifty-five percent risk of work stoppages because of the threat of a volcano eruption near the facilities used by vendor i. In this case, the software development company may associate this work stoppage risk percentage with link 516 connecting vendor node 512 to subset X node 510. Each of links 516, 518, 526, and 528 may have individual risk percentages associated with specific risks for outsourcing a specific subset of tasks of the CBP to an individual vendor), (Id., ¶ 33, The decision-tree based approach may allow the software development company to systematically build a decision-tree risk-profile for each task or set of tasks considered for outsourcing. In some embodiments, the decision-tree based approach may allow the software development company to consider the risks of outsourcing each task or set of tasks to one or more different vendors. By building the decision-tree risk-profile, the software development company may be able to quantify the risks and calculate the expected monetary costs of all possible task-vendor combinations of the risk-profile), (Id., ¶ 35, FIG. 4 shows a next step in the exemplary process of building a decision-tree. At this next step, the software development company may determine the business tasks to be outsourced by using its previously completed risk-profile analysis. The company at this step may need to consider the possibilities of outsourcing either the complete business process (CBP) or a subset of the tasks in the CBP, a decision the software development company may make at outsourcing node 400. To make this decision, the software development company may identify the risks associated with each task, possibly using the risk-profile developed earlier. As shown in step 150 in FIG. 1, the company may also identify a set of vendors for each set of tasks considered for outsourcing), (Id., ¶ 37, With each vendor having its own node, the software development company may associate with each vendor's node the risk-percentage for outsourcing the CBP to that specific vendor. The software development company may begin this process by assigning risk percentages to risks shared by all vendors. This risk percentage may be calculated using the previously-identified risks in the task-vendor risk-profiles. For example, a software development company may associate a sixty percent risk of knowledge transfer to outsourcing the CBP to any vendor, regardless of the vendor chosen. The software development company may assign this risk percentage to link 410, which connects outsourcing node 400 with complete business process node 415).
It would have been obvious to a person of ordinary skill in the art before the effective filing date to have modified the software development risk assessment elements of Fox to include the decision tree and spillover risk elements of Nagar in the analogous art of outsourcing software development for the same reasons as stated for claim 1.
Regarding Claim 14, the combination of Fox, Nagar and Muddakkagari discloses …the system as claimed in claim 1…
While suggested in at least Fig. 2, Fox does not explicitly disclose …wherein the processor is configured to fetch the KPI scores, the accuracy percentage from a correlation unit and the spillover risk values and defect density values for risk assessment in the software development lifecycle of projects to detect causes for delay in the projects as the indicator of risks.
However, Nagar discloses …wherein the processor is configured to fetch the KPI scores, the accuracy percentage from a correlation unit and the spillover risk values and defect density values for risk assessment in the software development lifecycle of projects to detect causes for delay in the projects as the indicator of risks (Nagar, ¶ 37, With each vendor having its own node, the software development company may associate with each vendor's node the risk-percentage for outsourcing the CBP to that specific vendor. The software development company may begin this process by assigning risk percentages to risks shared by all vendors. This risk percentage may be calculated using the previously-identified risks in the task-vendor risk-profiles. For example, a software development company may associate a sixty percent risk of knowledge transfer to outsourcing the CBP to any vendor, regardless of the vendor chosen. The software development company may assign this risk percentage to link 410, which connects outsourcing node 400 with complete business process node 415), (Id., ¶ 38, The software development company may then assign risk percentages to risks posed by each individual vendor. The software development company may identify the individual risks by referring to the previously created risk-profiles. The individual risk percentages may be reflected in the links 430, 432, and 434 connecting each vendor node 420, 422, and 424, respectively, to complete business process node 415. The set of all risks taken together for each vendor-process scenario constitutes the decision-tree risk-profile associated with the scenario), (Id., ¶ 39, In some instances, the individual risk percentage may represent an increased risk of an event occurring to a specific vendor even though all vendors share some risk of the event occurring. In this case, the software outsourcing company may choose to associate an increased risk percentage for an event occurring to a specific vendor with the link 430, 432, or 434 connecting the specific vendor node 420, 422, or 424 to complete business process node 415. When calculating the increased risk percentage, the software outsourcing company may choose to take into account the risk percentage shared by all vendors and associated with link 410 connecting complete business process node 415 with outsourcing node 400. For example, referring to FIG. 4, outsourcing the CBP to vendor i may represent a risk percentage for knowledge transfer of eighty percent. All vendors, however, may have a sixty percent risk percentage of having knowledge transfer occur, and the software development company may associate this shared sixty percent chance with link 410. The software development company may take into account the shared sixty percent risk percentage when calculating the risk percentage to associate with link 430 connecting node 420 for vendor i to complete business process node 415. For example, the software development company may associate a twenty percent risk of knowledge transfer with link 430), (Id., ¶ 40, A software development company may associate individual risks for outsourcing the complete business process to a specific vendor with the link connecting that vendor to complete business process node 415. Referring to FIG. 4, vendor i, for example, may be subject to a specific risk of work stoppages because of the geographic location of the vendor's employees. Vendor j and k may not be subject to this risk. The risk percentage for work stoppages for vendor i may be sixty percent. Some software outsourcing companies may choose to associate this sixty percent risk percentage with link 430 connecting vendor node 420 for vendor i with complete business process node 415. The software outsourcing company may choose to associate multiple individual risks pertaining to vendor i with link 430. The software development company may choose to associate one or more of an increased risk percentage and an individual risk percentage with one or more of the links connecting vendor nodes 420, 422, and 424 to complete business process node 415).
It would have been obvious to a person of ordinary skill in the art before the effective filing date to have modified the software development risk assessment elements of Fox to include the decision tree and spillover risk elements of Nagar in the analogous art of outsourcing software development for the same reasons as stated for claim 1.
Regarding Claim 15, Fox discloses … A method for optimized predictive risk assessment of software development lifecycle of projects, wherein the method is executed by a processor in communication with a memory, the method comprising: fetching a historical unstructured attribute dataset relating to work items documented for past agile projects and group the unstructured attribute dataset based on derived Knowledge Performance Indicator (KPI) scores to create a grouped attribute dataset (Fox, ¶ 1, The present disclosure relates to a business intelligence dashboard that focuses on software development performance. More specifically, the present disclosure relates to a system and method for an enterprise software development dashboard tool that provides actionable intelligence to various levels of stakeholders within an organisation as an enterprise monitoring tool, while continuing with process adherence and quality standards), (Id., ¶ 12, The system comprises a processor, a memory operatively coupled to the processor, and a connector component configured to receive data from business attributes of at least one source program and an analytical component configured to generate an analytics from the received data. Further, the analytical component comprises an analytics engine to track the at least one source program status using quality parameters, an agile module to provide continuous improvement steps to the business attributes using an agile maturity index score, wherein business formulae are applied to generate the analytics from the received data by the analytical component, and wherein the agile maturity index score is calculated for each of the business attributes by the analytical component using the generated analytics), (Id., ¶ 58, The solution provides an enterprise dashboard for tracking software development progress and risks that facilitates transparency for all stakeholders in predictability, productivity, quality & agile maturity by organization levels, offers return on investment (ROI) and other business metrics to engage all stakeholders in technology investments. It also gives filtered metrics across organization levels such as enterprise, business unit, program, project, team and individual (in some cases) and that too in an integrated view mode in code quality, build quality and operational (ASM) metrics), (Id., ¶ 81, The agile module 210 of the analytical component 112 follows the agile approach of dividing tasks into short phases of work and frequently reassessing and adapting new approaches in order to ensure quality deliverables in a timely manner. The agile module 210 performs its task by overlooking activities and providing insights on the same. The activities include but may not be limited to capturing requirements, constructing or initiating work, reviewing the constructed work, deploying the same, testing the work for errors, releasing the work to the next level of stakeholders and eventually managing the work. Further, the agile module 210 manages agility by doing and being agile through various agile coaches including but not limited to agile documentation (discloses work items documented for past agile projects), collaborative planning, continuous integration and delivery, low process ceremony, paired programming, agile estimation, continuous improvement, evolutionary requirements, multi-level adaptive planning and self-organizing team. Additionally, the agile module also calculates an agile maturity index scores for enhancing performance), (Id., ¶ 83, The vendor module 212 of the analytical component 112 assists in keeping track of vendor records and productivities, especially for outsourced work, this further assist in keeping key performance indicators (KPI) of a vendor or a consultant. The KPI generally include productivity, efficiency, quality or other performance indicators as requisite for a particular business. The vendor module 212 comprised in the analytical component 112 calculates vendor productivity on the basis of multiple factors including but not limited to comparative analysis at the vendor and consultant level, story point analysis, summary analysis, resource productivity, and predictability including cost, time and scope variants. Predictability may also be calculated on the basis of a schedule performance index and a cost performance index);
converting the unstructured attribute dataset into a structured attribute dataset by applying pre-defined rules, wherein each attribute data of the structured attribute dataset is mapped to pre-determined categorical values (Id., ¶ 73, A dashboard framework system 104 implements a method for dashboard framework 200 (discloses structured attribute dataset) on a web and application server 102 or a web server 102, the dashboard framework system 104 also known as web and application system 104 includes a display component 110 or a dashboard interface, a connector agent 202, an analytical component 112 or a web API, and other components 114. The display component 110 allows the system 104 to interact with a user 150. The analytical component 112 comprises an agile module 210, a vendor module 212, a test case module 214, an analytics engine 216, and other modules 220. The analytical component 112 communicates with a connector component 204 having a connector service 116 and further connected to a plurality of sub-connectors 204a, 204b, 204c, 204d, . . . , 204n, such as a JIRA connector, a Jenkins connector, a SonarQube connector, a ServiceNow connector, an Excel connector, and alike for each program, project, or such source systems/applications 130. Each of the sub-connectors 204a, 204b, 204c, 204d, . . . , 204n are respectively coupled to one of a plurality of third party program, project, or such source systems 130 or applications, such as 132a, 132b, 132c, 132d, . . . , 132n, such a JIRA, a Jenkins, a SonarQube, a ServiceNow, an Excel file programs. Further, the components of the system 104 communicates to other computing devices, ex web servers and external data servers, such as a DB server 120 having a database system 122 and a database 124), (Id., ¶ 74, The enterprise software development dashboard tool of the solution provides the connector component 204, the analytical component 112 and the display component 110. Additionally, the tool also comprises a server component 122 of the DB server 120 which remains in constant communication with the analytical component 112. The connector component 204 of the dashboard framework system may be incorporated to gather data from multiple tools, systems and applications 130 in a way that the data is gathered via a predefined function initiated in a specified time period. The analytical component 112 may be instructed to receive the data from the connector component 204, applying business formulae (discloses pre-defined rules) onto the data and deriving useful analytics, eventually supplementing said data to the display component 110. The analytical component 112 may further be facilitated to perform analytics in order to derive descriptive analytics, predictive analytics and prescriptive analytics from the data supplemented to the analytical component 112 from the connector sub-connectors 204a, 204b, . . . , 204n. The analytical component 112 may further derive analytics from the supplemented data mainly for the attributes including but not limited to predictability, productivity, quality, maturity and return-on-investment (discloses mapping to pre-determined categorical values). The display component 110 of the software development dashboard system may be developed to display the analytics supplemented by the analytical component in a flexible and user-friendly manner), (Id., ¶ 93, FIG. 3.2 illustrates an exemplary dashboard report 300 generated by a dashboard framework system, in accordance with an embodiment of the present subject matter);
PNG
media_image1.png
366
539
media_image1.png
Greyscale
applying an iterative logic to predict defect density values based on the structured attribute dataset (Id., ¶ 84, The test case module 214 is a review module which reviews the work being performed by individuals in an organization. The test case module 214 of the analytical component 112 identifies test case scenarios based on multiple parameters including but not limited to coverage percentage, completion percentage, executed pass percentage and executed failure percentage which assist in analysing the performance of a project or program as being developed or worked upon (discloses defect density values)), (Id., ¶ 7, agile software development processes are also added that further encourages flexible planning and low reaction time to changing requirements. The agile method divides jobs into small, incremental steps that may be completed with little forethought. Software iterations are created in a short amount of time. Consolidating and enabling project management, product management, customer management, and other stakeholders in a single environment or tool is required by project management systems that have been built to arrange these operations. They are typically unable to communicate with other third-party technologies or collaborate across many development teams or geographically dispersed locales);
While suggested in at least Fig. 2 and related text, Fox does not explicitly disclose …correlating a derived attribute data from the structured attribute dataset with a defined attribute data to derive an accuracy percentage, wherein the accuracy percentage signifies a potential risk to subsequent tasks in the software development lifecycle of projects; creating a decision tree structure using the structured attribute dataset to train a supervised learning model and predict spillover risk values, wherein a maximum information retention is determined for predicting the spillover risk values that are obtained when a branching node is created for the structured attribute data; and combining the KPI scores, the accuracy percentage and the spillover risk values and the defect density values for risk assessment in the software development lifecycle of projects to generate indicators of risks, wherein the system employs the generated indicators of risks for predictive risk assessment to monitor and minimise risks and improve overall performance of software development lifecycle projects in real-time.
However, Nagar discloses …correlating a derived attribute data from the structured attribute dataset with a defined attribute data to derive an accuracy percentage, wherein the accuracy percentage signifies a potential risk to subsequent tasks in the software development lifecycle of projects (Nagar, ¶ 37, With each vendor having its own node, the software development company may associate with each vendor's node the risk-percentage for outsourcing the CBP to that specific vendor. The software development company may begin this process by assigning risk percentages to risks shared by all vendors (discloses accuracy percentage signifying risk). This risk percentage may be calculated using the previously-identified risks in the task-vendor risk-profiles. For example, a software development company may associate a sixty percent risk of knowledge transfer to outsourcing the CBP to any vendor, regardless of the vendor chosen. The software development company may assign this risk percentage to link 410, which connects outsourcing node 400 with complete business process node 415), (Id., ¶ 38, The software development company may then assign risk percentages to risks posed by each individual vendor. The software development company may identify the individual risks by referring to the previously created risk-profiles. The individual risk percentages may be reflected in the links 430, 432, and 434 connecting each vendor node 420, 422, and 424, respectively, to complete business process node 415. The set of all risks taken together for each vendor-process scenario constitutes the decision-tree risk-profile associated with the scenario), (Id., ¶ 43, A software development company may associate individual risks for outsourcing a specific subset of the tasks of the CBP to a specific vendor with the link connecting that vendor to the specific subset node 510 or 520. For example, outsourcing subset X of the CBP to vendor i may involve a fifty-five percent risk of work stoppages (discloses downstream risk) because of the threat of a volcano eruption near the facilities used by vendor i. In this case, the software development company may associate this work stoppage risk percentage with link 516 connecting vendor node 512 to subset X node 510. Each of links 516, 518, 526, and 528 may have individual risk percentages associated with specific risks for outsourcing a specific subset of tasks of the CBP to an individual vendor);
and combining the KPI scores, the accuracy percentage and the spillover risk values and the defect density values for risk assessment in the software development lifecycle of projects to generate indicators of risks, wherein the system employs the generated indicators of risks for predictive risk assessment to monitor and minimise risks and improve overall performance of software development lifecycle projects in real-time (Id., ¶ 53, The KPIs to measure vendor performance may include factors such as cost, on-time delivery, code quality, and software performance. Most of these KPIs may be tangible and directly related to the vendor. The cost component may be measured against the expected cost for performing similar function internally within the software development company. Cost overruns may be a factor when measuring this KPI. On-time delivery may be measured against specified due dates. A good measure of code quality may be the number of bugs in the developed code. Finally, software performance may be measured against metrics such as computational performance, load time, scalability, and performance as perceived by the users), (Id., ¶ 29, The task of Quality Management 225 may present a good candidate for outsourcing for some software developing companies. An iterative process, Quality Management 225 may be closely aligned to Code Development 220. Using the product requirements document prepared by Product Management 215, Quality Management 225 may ensure that the features specified by Product Management 215 are correctly implemented in the final product. The performance of Quality Management 225, and implicitly of Product Development 220, may be easily determined in some software developing companies by remotely monitoring product quality. Thus, the company may have an incentive to carefully monitor the reports prepared by Quality Management 225 to reduce, or even minimize, the risks associated with outsourcing Quality Management 225. Therefore, despite depending on Product Management 215, Quality Management 225 may be outsourced. Some software developing companies may find it advantageous to outsource Quality Management 225 and Coding 220 to the same vendor. Doing so may allow Quality Management 225 to perform its task more efficiently by using the knowledge gained by Coding 220 of the developed software), (Id., ¶ 20, As shown in the exemplary flow chart of FIG. 1, step 120 includes identifying one or more tasks to outsource. These tasks may include the tasks identified with software development, such as pre-sales, sales, product marketing, product management, product development, quality management, product support, consulting, and documentation. The software development company may decide to outsource tasks in a manner that minimizes the disruption to the business process. To avoid disruptions to the business process, the software development company can consider the adverse effects that outsourcing different tasks may have on the base criteria identified in step 110. These adverse effects may be grouped into at least three sets of risks--strategic risks, operational risks, and demographic risks. (discloses indicators of risk) It will be understood that the set of risks and the risks in each group are not exhaustive and should be enhanced as required), (Id., ¶ 30, The software development company may have as a goal the awareness of customer issues as well as the vendor's response to these issues at all times. To achieve this goal, the software development company may implement a well-defined escalation process in which the software development company itself may become involved with customer problems).
It would have been obvious to a person of ordinary skill in the art before the effective filing date to have modified the software development risk assessment elements of Fox to include the decision tree and spillover risk elements of Nagar in the analogous art of outsourcing software development for the same reasons as stated for claim 1.
While suggested in at least Fig. 2 and related text of Fox, the combination of Fox and Nagar does not explicitly disclose … creating a decision tree structure using the structured attribute dataset to train a supervised learning model and predict spillover risk values, wherein a maximum information retention is determined for predicting the spillover risk values that are obtained when a branching node is created for the structured attribute data
However, through KSR Rationale D (See MPEP 2141(III)(D)), the combination of Nagar and Muddakkagari discloses …creating a decision tree structure using the structured attribute dataset to train a supervised learning model and predict spillover risk values, wherein a maximum information retention is determined for predicting the spillover risk values that are obtained when a branching node is created for the structured attribute data.
First, Nagar discloses the creation of a decision tree structure to predict spillover risk values, as well as to determine data retention policies (Nagar, ¶ 32, After risks are identified and a risk profile is created, a decision tree is created (step 140). After using the identified risks to create a risk-profile for each task, the software development company may use the risk profiles to build a decision-tree to assist it in making a decision as to which task or tasks to outsource (step 140). FIGS. 3-5 show an exemplary decision-tree that may be used in the decision of outsourcing software development tasks. The decision-tree process may be a multi-stage process, where each stage can be interrelated. At each stage, the organization may make a decision having an associated set of risks and consequences. Further, the decisions made at one stage may affect the risks associated with decisions made at subsequent stages because of the interrelationships existing between stages. For example, the set of risks associated with the decision to outsource Code Development 220 may depend on the decision to outsource Quality Management 225), (Id., ¶ 33, The decision-tree based approach may allow the software development company to systematically build a decision-tree risk-profile for each task or set of tasks considered for outsourcing. In some embodiments, the decision-tree based approach may allow the software development company to consider the risks of outsourcing each task or set of tasks to one or more different vendors. By building the decision-tree risk-profile, the software development company may be able to quantify the risks and calculate the expected monetary costs of all possible task-vendor combinations of the risk-profile), (Id., ¶ 41, FIG. 5 shows a similar process for determining the risks for outsourcing a subset of the tasks of the CBP. The risk percentages associated with each subset-vendor pair may be grouped under partial business process node 500. In the exemplary decision-tree shown in FIG. 5, a software development company may consider outsourcing two subsets of the CBP, subset X and subset Y. Each subset may receive its own node, such as, for example, node 510 for subset X and node 520 for subset Y), (Id., ¶ 21, Strategic risks include, for example, loss of innovation, loss of intellectual property, and the possibility of strategic policy diversion between a software development company and an external vendor responsible for outsourced tasks. Outsourcing one or more key functions over a period of time can increase the dependence of the software development company on the external vendor. Over time, this dependence can deplete the technical capabilities of the company, limiting its ability to undertake product development in the future. This risk can be more pronounced with outsourcing of some functions than others. To guard against this risk, the company can determine its core competencies and retain strategic control over functions relevant to these competencies. Further, the software development company decide to take measures to provide increased security for its intellectual property that is sent to an external vendor, especially in the absence of strict and enforceable legal protections of the company's intellectual property from misuse by the external vendor and its employees. There is also the risk of a strategic diversion of policies between the software development company and the external vendor over a long period of time. For example, the external vendor may decide to develop competing products or switch to a totally different product line in the future, forcing the outsourcing company to search for new vendors, an expensive proposition in some instances).
PNG
media_image2.png
369
624
media_image2.png
Greyscale
Further, Muddakkagari discloses training a supervised learning model to process queries and determine metrics in a software development environment (Muddakkagari, ¶ 32, The NLP system 114 may include various processors (pre-processor 116A, post-processor 116B), libraries (e.g., library 118), and Al-based systems (e.g., machine learning (ML) tool 120) to analyze and convert natural language to one that could result in a computing system to perform substantive functions (e.g., find a response to the query). Using the pre-processor 116A, the NLP system 114 may rephrase and/or reformat the query for computing systems (e.g., AIML Interpreter 122, DevOps system 130, etc.) to understand. In some aspects, the NLP may also determine whether the query is a dynamic or a static query, as will be discussed further below. Using post-processor 116B, the NLP system 114 may rephrase and/or reformat a proposed response to a query, e.g., so that it may be understandable to a user of the user device 102A-102C that sent the original query. In some aspects, the NLP 114 may assess a proposed response, and upon determining that the proposed response is incorrect, unsatisfactory, or misguided, can facilitate a new response. The NLP system 114 may be guided by a library 118 (e.g., database, look-up tables, repository, etc.) and Al-based tools (e.g., ML tool 120) for various uses in natural language processing, including the undergoing of supervised and unsupervised learning from language data. Together with its library 118, the ML tool 120 may support common NLP tasks, such as tokenization, sentence segmentation, part-of-speech tagging, named entity extraction, chunking, parsing, and coreference resolution. These tasks may be needed to build more advanced text processing services. The ML tool 120 may also include maximum entropy and perceptron based machine learning tools. The NLP system 114 and/or query engine 112 may determine whether a received query solicits a static or dynamic response. For example, a static response may invoke a simple retrieval of information from a local database 124, e.g., of an AIML interpreter 122. A dynamic response may involve invoking the DevOps System 130, which may investigate specific event(s) of an application development from various DevOps tools 138A-138E and their respective source integrators 136A-136E), (Id., ¶ 61, If the query does concern a quality metric, the query/response system 110 and/or the DevOps system 130 may determine relevant quality assurance (QA) tools associated with the DevOps system 130. These QA tools may assist in generating a dynamic response to the query. The QA tools may include a framework for testing units of code for an application, code coverage tools to find out which parts of the code are tested, analytical tools to help predict vulnerability, and a dashboard to present results of the test to the user. The QA tools may be used to analyze source code, search for defects and bugs, and display results of the search on a dashboard. The QA tools may include a framework or application for testing units of the code (e.g., JUnit in the JAVA™ programming language, JAVA™ Code Coverage (JaCoCo) as a tool for code coverage, and a source code analyzer for statistically analyzing the code base and learning the vulnerability of the standards of usage. Some source code analyzers (e.g., PMD reports) may help find unused variables, empty catch blocks, unnecessary object creation, etc. The statistical analysis may be presented as one or more of a report, spreadsheet, slide, chart, graph, etc. on a dashboard, and may be segregated or divided into many levels. Examples of QA tools that could be used may include, for example, SONARQUBE™ (formerly SONAR™), DYNATRACE™ (e.g., for monitoring applications on a server), VERACODE (e.g., for security analysis), WHITESOURCE (e.g., for security analysis), APPSPIDER (e.g., for dynamic testing analysis), JMETER (e.g., for service test analysis), etc).
One of ordinary skill in the art would have recognized that applying the known technique of Muddakkagari would have yielded predictable results and resulted in an improved system. It would have been recognized that applying the supervised machine learning technique of Muddakkagari to the decision tree and risk value determination teachings of Nagar would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate such data processing features into similar software development management systems. Further, applying a supervised machine learning technique to Nagar with spillover risk values determined accordingly, would have been recognized by those of ordinary skill in the art as resulting in an improved system that would allow more detailed reports and greater control over the software development lifecycle process.
Thus, through KSR Rationale D (See MPEP 2141(III)(D)), the combination of Nagar and Muddakkagari discloses …creating a decision tree structure using the structured attribute dataset to train a supervised learning model and predict spillover risk values, wherein a maximum information retention is determined for predicting the spillover risk values that are obtained when a branching node is created for the structured attribute data.
It would have been obvious to a person of ordinary skill in the art before the effective filing date to have modified the software development risk assessment elements of Fox and the decision tree and spillover risk elements of Nagar to include the supervised learning elements of Muddakkagari in the analogous art of automating and monitoring software development operations for the same reasons as stated for claim 1.
Regarding Claim 16, the combination of Fox, Nagar and Muddakkagari discloses …the method as claimed in claim 15…
Fox further discloses …wherein the grouped attribute dataset includes a positive, a negative, a mixed and a neutral grouped sentiment dataset, wherein the grouping is carried out by employing a sequence of computational linguistics techniques including stemming followed by tokenization on the unstructured attribute dataset comprising communication threads to create the grouped unstructured attribute dataset, the communication threads in the unstructured attribute dataset is broken down into sub-component parts and the parts are individually validated to identify sentiment bearing phrases through word associations, and wherein the KPI score is assigned to each phrase in the sub-component parts such that the KPI score is proportional to a degree to which sentiment is expressed … (Fox, ¶ 90, Key metrics beyond source application program or project to support detailed reporting for continuous improvements from agile teams to senior management includes productivity, predictability, quality and ROI. Productivity option 304a, metric 306a covers team's average velocity, program velocity, impediments scorecard, release burn down w/all dimensions, vendor productivity. This ranges release burn down, other than work completion trend, it also tracks requirement volatility trends by sprint to help predict revised date of delivery. Impediment score card 308 would directly reflect on the impediment status and hence the efficiency of the scrum master backlog health would directly reflect on the feature clarity and hence the efficiency of the product owner. Predictability option 304b, metric 306b covers scope variance, schedule variance, cost variance, SPI & CPI (EVM), supports predictability around time, cost, scope. concept of earned value measurement in agile to measure the cost performance index i.e. CPI and schedule performance index i.e. SPI. The CPI and SPI value greater than 1 indicates a positive. (discloses grouping by sentiment) Application service management (ASM) covers open & closed tickets, average ticket age, mean time to recovery/restore/repair (MTTR), mean time to service (MTTS) compliance by priority, volumetric metrics by portfolio, status, root cause analysis (RCA), priority. Out of the box connectors for JIRA, VersionOne, TFS, VSTS, SonarQube, Jenkins, ServiceNow & HP-ALM. Quality parameters covers—code quality that includes code complexity, vulnerability, code coverage, function point analysis, job statistics by status. ex—SonarQube. Quality parameters covers build quality that includes job statistics by status, build statistics, test statistics by job, job statistics by status. Ex—Jenkins. Test statistics by job covers team's average defect density (defects/story points), program avg. defect density, team's average % unit test coverage, program % unit test coverage and QA performance covers team's average defect density (defects/story points), program avg. defect density, team's average % unit test coverage, program % unit test coverage), (Id., ¶ 91, All subsequent views would be the same for all users with the relevant work stream and data point restricted access. A near real time view of backlog health would directly reflect on the feature clarity and hence the efficiency of the product owner, a near real time view of the impediment scorecard would directly reflect on the impediment status and hence the efficiency of the scrum master. Along with the work completion trend the release burn down also tracks requirement volatility trends by sprint to help in predicting a revised date of delivery as a result of the voice of customer in a multi-vendor scenario solution provides comparative analysis at the vendor and the consultant level), (Id., ¶ 92, Story point analysis, such as 304f provides comparative analysis on story points delivered by each consultant, by project and by sprint. Summary analysis across consultants is comparative analysis giving the count of delivered user stories tasks subtasks and defects by each consultant resource productivity gives count of tasks and subtasks delivered by the selected consultant, by project and by sprint. Further, cost time and scope variants are used as the contributing factors to determine predictability. The concept of earned value measurement in agile to measure the cost performance index and schedule performance index to depict cost and schedule variance respectively. The CPI and SPI value greater than one indicates a positive. The ratio of accepted and committed story points calculates the scope variants. A positive scope variance indicates that the team delivered more than commitment. This shows the quality of deliverable by test case coverage and testing execution outcomes until the last completed by sprint. There are various other dashboard attributes, metrics, pertaining to business, customizable by users and dependent on type of software development tools used or required).
Regarding Claim 17, the combination Fox, Nagar and Muddakkagari discloses …the method as claimed in claim 15…
Fox further discloses …wherein the derived attribute data is correlated with the defined attribute data to identify a significant gap in a derived story point and a defined story point which signifies a gap in an estimation analysis and consequently a potential risk to subsequent tasks, the derived attribute data is a pre-processed third attribute data which represents a rescaled value of a complexity noise, and wherein each of the attribute data of the structured attribute dataset is mapped using a predictability model to different categorical values including spillover values in terms of high, low, no and defect density in terms of high, medium, low or no (Fox, ¶ 83, The vendor module 212 of the analytical component 112 assists in keeping track of vendor records and productivities, especially for outsourced work, this further assist in keeping key performance indicators (KPI) of a vendor or a consultant. The KPI generally include productivity, efficiency, quality or other performance indicators as requisite for a particular business. The vendor module 212 comprised in the analytical component 112 calculates vendor productivity on the basis of multiple factors including but not limited to comparative analysis at the vendor and consultant level, story point analysis, (discloses story point analysis) summary analysis, resource productivity, and predictability including cost, time and scope variants. Predictability may also be calculated on the basis of a schedule performance index and a cost performance index), (Id., ¶ 81, The agile module 210 of the analytical component 112 follows the agile approach of dividing tasks into short phases of work and frequently reassessing and adapting new approaches in order to ensure quality deliverables in a timely manner. The agile module 210 performs its task by overlooking activities and providing insights on the same. The activities include but may not be limited to capturing requirements, constructing or initiating work, reviewing the constructed work, deploying the same, testing the work for errors, releasing the work to the next level of stakeholders and eventually managing the work. Further, the agile module 210 manages agility by doing and being agile through various agile coaches including but not limited to agile documentation, collaborative planning, continuous integration and delivery, low process ceremony, paired programming, agile estimation, continuous improvement, evolutionary requirements, multi-level adaptive planning and self-organizing team. Additionally, the agile module also calculates an agile maturity index scores for enhancing performance), (Id., ¶ 90, Key metrics beyond source application program or project to support detailed reporting for continuous improvements from agile teams to senior management includes productivity, predictability, quality and ROI. Productivity option 304a, metric 306a covers team's average velocity, program velocity, impediments scorecard, release burn down w/all dimensions, vendor productivity. This ranges release burn down, other than work completion trend, it also tracks requirement volatility trends by sprint to help predict revised date of delivery. Impediment score card 308 would directly reflect on the impediment status and hence the efficiency of the scrum master backlog health would directly reflect on the feature clarity and hence the efficiency of the product owner. Predictability option 304b, metric 306b covers scope variance, schedule variance, cost variance, SPI & CPI (EVM), supports predictability around time, cost, scope. concept of earned value measurement in agile to measure the cost performance index i.e. CPI and schedule performance index i.e. SPI. The CPI and SPI value greater than 1 indicates a positive. Application service management (ASM) covers open & closed tickets, average ticket age, mean time to recovery/restore/repair (MTTR), mean time to service (MTTS) compliance by priority, volumetric metrics by portfolio, status, root cause analysis (RCA), priority. Out of the box connectors for JIRA, VersionOne, TFS, VSTS, SonarQube, Jenkins, ServiceNow & HP-ALM. Quality parameters covers—code quality that includes code complexity, vulnerability, code coverage, function point analysis, job statistics by status. ex—SonarQube. Quality parameters covers build quality that includes job statistics by status, build statistics, test statistics by job, job statistics by status. Ex—Jenkins. Test statistics by job covers team's average defect density (defects/story points), program avg. defect density, team's average % unit test coverage, program % unit test coverage and QA performance covers team's average defect density (defects/story points), program avg. defect density, team's average % unit test coverage, program % unit test coverage), (Id., ¶ 102, Other benefits of the solution covers, cloud deployments, for example on AZURE, ASM-SLA based tracking on volumetric & timeliness metrics, easily configurable & customizable, scaled agile model metrics reporting, agile maturity index scores, aggregated views and filters at project, program and portfolio level, alerts and notifications on specific threshold, and downloadable reports for offline project reviews).
Regarding Claim 18, the combination Fox, Nagar and Muddakkagari discloses …the method as claimed in claim 15…
While suggested in at least Fig. 2, Fox does not explicitly disclose …wherein the decision tree structure is implemented by selecting an attribute data of the structured attribute dataset as a parent root node and a parameter for splitting the decision tree structure to predict the spillover risk values, wherein the spillover risk values indicate that an assigned task is spilled over an assigned deadline and is causing delay in the software development life cycle projects.
However, Nagar discloses … wherein the decision tree structure is implemented by selecting an attribute data of the structured attribute dataset as a parent root node and a parameter for splitting the decision tree structure to predict the spillover risk values, wherein the spillover risk values indicate that an assigned task is spilled over an assigned deadline and is causing delay in the software development life cycle projects. (Nagar, ¶ 53, The KPIs to measure vendor performance may include factors such as cost, on-time delivery, code quality, and software performance. Most of these KPIs may be tangible and directly related to the vendor. The cost component may be measured against the expected cost for performing similar function internally within the software development company. Cost overruns may be a factor when measuring this KPI. On-time delivery may be measured against specified due dates. A good measure of code quality may be the number of bugs in the developed code. Finally, software performance may be measured against metrics such as computational performance, load time, scalability, and performance as perceived by the users), (Id., ¶ 43, A software development company may associate individual risks for outsourcing a specific subset of the tasks of the CBP to a specific vendor with the link connecting that vendor to the specific subset node 510 or 520. For example, outsourcing subset X of the CBP to vendor i may involve a fifty-five percent risk of work stoppages because of the threat of a volcano eruption near the facilities used by vendor i. In this case, the software development company may associate this work stoppage risk percentage with link 516 connecting vendor node 512 to subset X node 510. Each of links 516, 518, 526, and 528 may have individual risk percentages associated with specific risks for outsourcing a specific subset of tasks of the CBP to an individual vendor), (Id., ¶ 33, The decision-tree based approach may allow the software development company to systematically build a decision-tree risk-profile for each task or set of tasks considered for outsourcing. In some embodiments, the decision-tree based approach may allow the software development company to consider the risks of outsourcing each task or set of tasks to one or more different vendors. By building the decision-tree risk-profile, the software development company may be able to quantify the risks and calculate the expected monetary costs of all possible task-vendor combinations of the risk-profile), (Id., ¶ 35, FIG. 4 shows a next step in the exemplary process of building a decision-tree. At this next step, the software development company may determine the business tasks to be outsourced by using its previously completed risk-profile analysis. The company at this step may need to consider the possibilities of outsourcing either the complete business process (CBP) or a subset of the tasks in the CBP, a decision the software development company may make at outsourcing node 400. To make this decision, the software development company may identify the risks associated with each task, possibly using the risk-profile developed earlier. As shown in step 150 in FIG. 1, the company may also identify a set of vendors for each set of tasks considered for outsourcing), (Id., ¶ 37, With each vendor having its own node, the software development company may associate with each vendor's node the risk-percentage for outsourcing the CBP to that specific vendor. The software development company may begin this process by assigning risk percentages to risks shared by all vendors. This risk percentage may be calculated using the previously-identified risks in the task-vendor risk-profiles. For example, a software development company may associate a sixty percent risk of knowledge transfer to outsourcing the CBP to any vendor, regardless of the vendor chosen. The software development company may assign this risk percentage to link 410, which connects outsourcing node 400 with complete business process node 415).
It would have been obvious to a person of ordinary skill in the art before the effective filing date to have modified the software development risk assessment elements of Fox to include the decision tree and spillover risk elements of Nagar in the analogous art of outsourcing software development for the same reasons as stated for claim 1.
Regarding Claim 19, the combination of Fox, Nagar and Muddakkagari discloses …the method as claimed in claim 15…
While suggested in at least Fig. 2, Fox does not explicitly disclose … wherein the iterative logic is applied to predict defect density values in the software development lifecycle of projects using a decision tree-based classifier with a target variable set to a derived project attribute where bug occurrences indicate number of valid defects found.
However, Nagar discloses … wherein the iterative logic is applied to predict defect density values in the software development lifecycle of projects using a decision tree-based classifier with a target variable set to a derived project attribute where bug occurrences indicate number of valid defects found (Nagar, ¶ 33, The decision-tree based approach may allow the software development company to systematically build a decision-tree risk-profile for each task or set of tasks considered for outsourcing. In some embodiments, the decision-tree based approach may allow the software development company to consider the risks of outsourcing each task or set of tasks to one or more different vendors. By building the decision-tree risk-profile, the software development company may be able to quantify the risks and calculate the expected monetary costs of all possible task-vendor combinations of the risk-profile), (Id., ¶ 35, FIG. 4 shows a next step in the exemplary process of building a decision-tree. At this next step, the software development company may determine the business tasks to be outsourced by using its previously completed risk-profile analysis. The company at this step may need to consider the possibilities of outsourcing either the complete business process (CBP) or a subset of the tasks in the CBP, a decision the software development company may make at outsourcing node 400. To make this decision, the software development company may identify the risks associated with each task, possibly using the risk-profile developed earlier. As shown in step 150 in FIG. 1, the company may also identify a set of vendors for each set of tasks considered for outsourcing), (Id., ¶ 37, With each vendor having its own node, the software development company may associate with each vendor's node the risk-percentage for outsourcing the CBP to that specific vendor. The software development company may begin this process by assigning risk percentages to risks shared by all vendors. This risk percentage may be calculated using the previously-identified risks in the task-vendor risk-profiles. For example, a software development company may associate a sixty percent risk of knowledge transfer to outsourcing the CBP to any vendor, regardless of the vendor chosen. The software development company may assign this risk percentage to link 410, which connects outsourcing node 400 with complete business process node 415).
It would have been obvious to a person of ordinary skill in the art before the effective filing date to have modified the software development risk assessment elements of Fox to include the decision tree and spillover risk elements of Nagar in the analogous art of outsourcing software development for the same reasons as stated for claim 1.
Regarding Claim 20, Fox discloses …A computer program product comprising: a non-transitory computer-readable medium having computer program code stored thereon, the computer-readable program code comprising instructions that, when executed by a processor, causes the processor to: fetch a historical unstructured attribute dataset relating to work items documented for past agile projects and group the unstructured attribute dataset based on derived Knowledge Performance Indicator (KPI) scores (Fox, ¶ 1, The present disclosure relates to a business intelligence dashboard that focuses on software development performance. More specifically, the present disclosure relates to a system and method for an enterprise software development dashboard tool that provides actionable intelligence to various levels of stakeholders within an organisation as an enterprise monitoring tool, while continuing with process adherence and quality standards), (Id., ¶ 12, The system comprises a processor, a memory operatively coupled to the processor, and a connector component configured to receive data from business attributes of at least one source program and an analytical component configured to generate an analytics from the received data. Further, the analytical component comprises an analytics engine to track the at least one source program status using quality parameters, an agile module to provide continuous improvement steps to the business attributes using an agile maturity index score, wherein business formulae are applied to generate the analytics from the received data by the analytical component, and wherein the agile maturity index score is calculated for each of the business attributes by the analytical component using the generated analytics), (Id., ¶ 58, The solution provides an enterprise dashboard for tracking software development progress and risks that facilitates transparency for all stakeholders in predictability, productivity, quality & agile maturity by organization levels, offers return on investment (ROI) and other business metrics to engage all stakeholders in technology investments. It also gives filtered metrics across organization levels such as enterprise, business unit, program, project, team and individual (in some cases) and that too in an integrated view mode in code quality, build quality and operational (ASM) metrics), (Id., ¶ 81, The agile module 210 of the analytical component 112 follows the agile approach of dividing tasks into short phases of work and frequently reassessing and adapting new approaches in order to ensure quality deliverables in a timely manner. The agile module 210 performs its task by overlooking activities and providing insights on the same. The activities include but may not be limited to capturing requirements, constructing or initiating work, reviewing the constructed work, deploying the same, testing the work for errors, releasing the work to the next level of stakeholders and eventually managing the work. Further, the agile module 210 manages agility by doing and being agile through various agile coaches including but not limited to agile documentation (discloses work items documented for past agile projects), collaborative planning, continuous integration and delivery, low process ceremony, paired programming, agile estimation, continuous improvement, evolutionary requirements, multi-level adaptive planning and self-organizing team. Additionally, the agile module also calculates an agile maturity index scores for enhancing performance), (Id., ¶ 83, The vendor module 212 of the analytical component 112 assists in keeping track of vendor records and productivities, especially for outsourced work, this further assist in keeping key performance indicators (KPI) of a vendor or a consultant. The KPI generally include productivity, efficiency, quality or other performance indicators as requisite for a particular business. The vendor module 212 comprised in the analytical component 112 calculates vendor productivity on the basis of multiple factors including but not limited to comparative analysis at the vendor and consultant level, story point analysis, summary analysis, resource productivity, and predictability including cost, time and scope variants. Predictability may also be calculated on the basis of a schedule performance index and a cost performance index);
convert the unstructured attribute dataset into a structured attribute dataset by applying pre-defined rules, wherein each attribute data of the structured attribute dataset is mapped to pre-determined categorical values (Id., ¶ 73, A dashboard framework system 104 implements a method for dashboard framework 200 (discloses structured attribute dataset) on a web and application server 102 or a web server 102, the dashboard framework system 104 also known as web and application system 104 includes a display component 110 or a dashboard interface, a connector agent 202, an analytical component 112 or a web API, and other components 114. The display component 110 allows the system 104 to interact with a user 150. The analytical component 112 comprises an agile module 210, a vendor module 212, a test case module 214, an analytics engine 216, and other modules 220. The analytical component 112 communicates with a connector component 204 having a connector service 116 and further connected to a plurality of sub-connectors 204a, 204b, 204c, 204d, . . . , 204n, such as a JIRA connector, a Jenkins connector, a SonarQube connector, a ServiceNow connector, an Excel connector, and alike for each program, project, or such source systems/applications 130. Each of the sub-connectors 204a, 204b, 204c, 204d, . . . , 204n are respectively coupled to one of a plurality of third party program, project, or such source systems 130 or applications, such as 132a, 132b, 132c, 132d, . . . , 132n, such a JIRA, a Jenkins, a SonarQube, a ServiceNow, an Excel file programs. Further, the components of the system 104 communicates to other computing devices, ex web servers and external data servers, such as a DB server 120 having a database system 122 and a database 124), (Id., ¶ 74, The enterprise software development dashboard tool of the solution provides the connector component 204, the analytical component 112 and the display component 110. Additionally, the tool also comprises a server component 122 of the DB server 120 which remains in constant communication with the analytical component 112. The connector component 204 of the dashboard framework system may be incorporated to gather data from multiple tools, systems and applications 130 in a way that the data is gathered via a predefined function initiated in a specified time period. The analytical component 112 may be instructed to receive the data from the connector component 204, applying business formulae (discloses pre-defined rules) onto the data and deriving useful analytics, eventually supplementing said data to the display component 110. The analytical component 112 may further be facilitated to perform analytics in order to derive descriptive analytics, predictive analytics and prescriptive analytics from the data supplemented to the analytical component 112 from the connector sub-connectors 204a, 204b, . . . , 204n. The analytical component 112 may further derive analytics from the supplemented data mainly for the attributes including but not limited to predictability, productivity, quality, maturity and return-on-investment (discloses mapping to pre-determined categorical values). The display component 110 of the software development dashboard system may be developed to display the analytics supplemented by the analytical component in a flexible and user-friendly manner), (Id., ¶ 93, FIG. 3.2 illustrates an exemplary dashboard report 300 generated by a dashboard framework system, in accordance with an embodiment of the present subject matter);
PNG
media_image1.png
366
539
media_image1.png
Greyscale
apply an iterative logic to predict defect density values based on the structured attribute dataset (Id., ¶ 84, The test case module 214 is a review module which reviews the work being performed by individuals in an organization. The test case module 214 of the analytical component 112 identifies test case scenarios based on multiple parameters including but not limited to coverage percentage, completion percentage, executed pass percentage and executed failure percentage which assist in analysing the performance of a project or program as being developed or worked upon (discloses defect density values)), (Id., ¶ 7, agile software development processes are also added that further encourages flexible planning and low reaction time to changing requirements. The agile method divides jobs into small, incremental steps that may be completed with little forethought. Software iterations are created in a short amount of time. Consolidating and enabling project management, product management, customer management, and other stakeholders in a single environment or tool is required by project management systems that have been built to arrange these operations. They are typically unable to communicate with other third-party technologies or collaborate across many development teams or geographically dispersed locales);
While suggested in at least Fig. 2 and related text, Fox does not explicitly disclose …correlate a derived attribute data from the structured attribute dataset with a defined attribute data to derive an accuracy percentage, wherein the accuracy percentage signifies a potential risk to subsequent tasks in the software development lifecycle of projects; create a decision tree structure using the structured attribute dataset to train a supervised learning model and predict spillover risk values, wherein a maximum information retention is determined for predicting the spillover risk values that are obtained when a branching node is created for the structured attribute data; and combine the KPI scores, the accuracy percentage and the spillover risk values and the defect density values for risk assessment in the software development lifecycle of projects to generate indicators of risks.
However, Nagar discloses …correlate a derived attribute data from the structured attribute dataset with a defined attribute data to derive an accuracy percentage, wherein the accuracy percentage signifies a potential risk to subsequent tasks in the software development lifecycle of projects (Nagar, ¶ 37, With each vendor having its own node, the software development company may associate with each vendor's node the risk-percentage for outsourcing the CBP to that specific vendor. The software development company may begin this process by assigning risk percentages to risks shared by all vendors (discloses accuracy percentage signifying risk). This risk percentage may be calculated using the previously-identified risks in the task-vendor risk-profiles. For example, a software development company may associate a sixty percent risk of knowledge transfer to outsourcing the CBP to any vendor, regardless of the vendor chosen. The software development company may assign this risk percentage to link 410, which connects outsourcing node 400 with complete business process node 415), (Id., ¶ 38, The software development company may then assign risk percentages to risks posed by each individual vendor. The software development company may identify the individual risks by referring to the previously created risk-profiles. The individual risk percentages may be reflected in the links 430, 432, and 434 connecting each vendor node 420, 422, and 424, respectively, to complete business process node 415. The set of all risks taken together for each vendor-process scenario constitutes the decision-tree risk-profile associated with the scenario), (Id., ¶ 43, A software development company may associate individual risks for outsourcing a specific subset of the tasks of the CBP to a specific vendor with the link connecting that vendor to the specific subset node 510 or 520. For example, outsourcing subset X of the CBP to vendor i may involve a fifty-five percent risk of work stoppages (discloses downstream risk) because of the threat of a volcano eruption near the facilities used by vendor i. In this case, the software development company may associate this work stoppage risk percentage with link 516 connecting vendor node 512 to subset X node 510. Each of links 516, 518, 526, and 528 may have individual risk percentages associated with specific risks for outsourcing a specific subset of tasks of the CBP to an individual vendor);
and combine the KPI scores, the accuracy percentage and the spillover risk values and the defect density values for risk assessment in the software development lifecycle of projects to generate indicators of risks, wherein the system employs the generated indicators of risks for predictive risk assessment to monitor and minimise risks and improve overall performance of software development lifecycle projects in real-time (Id., ¶ 53, The KPIs to measure vendor performance may include factors such as cost, on-time delivery, code quality, and software performance. Most of these KPIs may be tangible and directly related to the vendor. The cost component may be measured against the expected cost for performing similar function internally within the software development company. Cost overruns may be a factor when measuring this KPI. On-time delivery may be measured against specified due dates. A good measure of code quality may be the number of bugs in the developed code. Finally, software performance may be measured against metrics such as computational performance, load time, scalability, and performance as perceived by the users), (Id., ¶ 29, The task of Quality Management 225 may present a good candidate for outsourcing for some software developing companies. An iterative process, Quality Management 225 may be closely aligned to Code Development 220. Using the product requirements document prepared by Product Management 215, Quality Management 225 may ensure that the features specified by Product Management 215 are correctly implemented in the final product. The performance of Quality Management 225, and implicitly of Product Development 220, may be easily determined in some software developing companies by remotely monitoring product quality. Thus, the company may have an incentive to carefully monitor the reports prepared by Quality Management 225 to reduce, or even minimize, the risks associated with outsourcing Quality Management 225. Therefore, despite depending on Product Management 215, Quality Management 225 may be outsourced. Some software developing companies may find it advantageous to outsource Quality Management 225 and Coding 220 to the same vendor. Doing so may allow Quality Management 225 to perform its task more efficiently by using the knowledge gained by Coding 220 of the developed software), (Id., ¶ 20, As shown in the exemplary flow chart of FIG. 1, step 120 includes identifying one or more tasks to outsource. These tasks may include the tasks identified with software development, such as pre-sales, sales, product marketing, product management, product development, quality management, product support, consulting, and documentation. The software development company may decide to outsource tasks in a manner that minimizes the disruption to the business process. To avoid disruptions to the business process, the software development company can consider the adverse effects that outsourcing different tasks may have on the base criteria identified in step 110. These adverse effects may be grouped into at least three sets of risks--strategic risks, operational risks, and demographic risks. (discloses indicators of risk) It will be understood that the set of risks and the risks in each group are not exhaustive and should be enhanced as required), (Id., ¶ 30, The software development company may have as a goal the awareness of customer issues as well as the vendor's response to these issues at all times. To achieve this goal, the software development company may implement a well-defined escalation process in which the software development company itself may become involved with customer problems).
It would have been obvious to a person of ordinary skill in the art before the effective filing date to have modified the software development risk assessment elements of Fox to include the decision tree and spillover risk elements of Nagar in the analogous art of outsourcing software development for the same reasons as stated for claim 1.
While suggested in at least Fig. 2 and related text of Fox, the combination of Fox and Nagar does not explicitly disclose … create a decision tree structure using the structured attribute dataset to train a supervised learning model and predict spillover risk values, wherein a maximum information retention is determined for predicting the spillover risk values that are obtained when a branching node is created for the structured attribute data
However, through KSR Rationale D (See MPEP 2141(III)(D)), the combination of Nagar and Muddakkagari discloses … create a decision tree structure using the structured attribute dataset to train a supervised learning model and predict spillover risk values, wherein a maximum information retention is determined for predicting the spillover risk values that are obtained when a branching node is created for the structured attribute data.
First, Nagar discloses the creation of a decision tree structure to predict spillover risk values, as well as to determine data retention policies (Nagar, ¶ 32, After risks are identified and a risk profile is created, a decision tree is created (step 140). After using the identified risks to create a risk-profile for each task, the software development company may use the risk profiles to build a decision-tree to assist it in making a decision as to which task or tasks to outsource (step 140). FIGS. 3-5 show an exemplary decision-tree that may be used in the decision of outsourcing software development tasks. The decision-tree process may be a multi-stage process, where each stage can be interrelated. At each stage, the organization may make a decision having an associated set of risks and consequences. Further, the decisions made at one stage may affect the risks associated with decisions made at subsequent stages because of the interrelationships existing between stages. For example, the set of risks associated with the decision to outsource Code Development 220 may depend on the decision to outsource Quality Management 225), (Id., ¶ 33, The decision-tree based approach may allow the software development company to systematically build a decision-tree risk-profile for each task or set of tasks considered for outsourcing. In some embodiments, the decision-tree based approach may allow the software development company to consider the risks of outsourcing each task or set of tasks to one or more different vendors. By building the decision-tree risk-profile, the software development company may be able to quantify the risks and calculate the expected monetary costs of all possible task-vendor combinations of the risk-profile), (Id., ¶ 41, FIG. 5 shows a similar process for determining the risks for outsourcing a subset of the tasks of the CBP. The risk percentages associated with each subset-vendor pair may be grouped under partial business process node 500. In the exemplary decision-tree shown in FIG. 5, a software development company may consider outsourcing two subsets of the CBP, subset X and subset Y. Each subset may receive its own node, such as, for example, node 510 for subset X and node 520 for subset Y), (Id., ¶ 21, Strategic risks include, for example, loss of innovation, loss of intellectual property, and the possibility of strategic policy diversion between a software development company and an external vendor responsible for outsourced tasks. Outsourcing one or more key functions over a period of time can increase the dependence of the software development company on the external vendor. Over time, this dependence can deplete the technical capabilities of the company, limiting its ability to undertake product development in the future. This risk can be more pronounced with outsourcing of some functions than others. To guard against this risk, the company can determine its core competencies and retain strategic control over functions relevant to these competencies. Further, the software development company decide to take measures to provide increased security for its intellectual property that is sent to an external vendor, especially in the absence of strict and enforceable legal protections of the company's intellectual property from misuse by the external vendor and its employees. There is also the risk of a strategic diversion of policies between the software development company and the external vendor over a long period of time. For example, the external vendor may decide to develop competing products or switch to a totally different product line in the future, forcing the outsourcing company to search for new vendors, an expensive proposition in some instances).
PNG
media_image2.png
369
624
media_image2.png
Greyscale
Further, Muddakkagari discloses training a supervised learning model to process queries and determine metrics in a software development environment (Muddakkagari, ¶ 32, The NLP system 114 may include various processors (pre-processor 116A, post-processor 116B), libraries (e.g., library 118), and Al-based systems (e.g., machine learning (ML) tool 120) to analyze and convert natural language to one that could result in a computing system to perform substantive functions (e.g., find a response to the query). Using the pre-processor 116A, the NLP system 114 may rephrase and/or reformat the query for computing systems (e.g., AIML Interpreter 122, DevOps system 130, etc.) to understand. In some aspects, the NLP may also determine whether the query is a dynamic or a static query, as will be discussed further below. Using post-processor 116B, the NLP system 114 may rephrase and/or reformat a proposed response to a query, e.g., so that it may be understandable to a user of the user device 102A-102C that sent the original query. In some aspects, the NLP 114 may assess a proposed response, and upon determining that the proposed response is incorrect, unsatisfactory, or misguided, can facilitate a new response. The NLP system 114 may be guided by a library 118 (e.g., database, look-up tables, repository, etc.) and Al-based tools (e.g., ML tool 120) for various uses in natural language processing, including the undergoing of supervised and unsupervised learning from language data. Together with its library 118, the ML tool 120 may support common NLP tasks, such as tokenization, sentence segmentation, part-of-speech tagging, named entity extraction, chunking, parsing, and coreference resolution. These tasks may be needed to build more advanced text processing services. The ML tool 120 may also include maximum entropy and perceptron based machine learning tools. The NLP system 114 and/or query engine 112 may determine whether a received query solicits a static or dynamic response. For example, a static response may invoke a simple retrieval of information from a local database 124, e.g., of an AIML interpreter 122. A dynamic response may involve invoking the DevOps System 130, which may investigate specific event(s) of an application development from various DevOps tools 138A-138E and their respective source integrators 136A-136E), (Id., ¶ 61, If the query does concern a quality metric, the query/response system 110 and/or the DevOps system 130 may determine relevant quality assurance (QA) tools associated with the DevOps system 130. These QA tools may assist in generating a dynamic response to the query. The QA tools may include a framework for testing units of code for an application, code coverage tools to find out which parts of the code are tested, analytical tools to help predict vulnerability, and a dashboard to present results of the test to the user. The QA tools may be used to analyze source code, search for defects and bugs, and display results of the search on a dashboard. The QA tools may include a framework or application for testing units of the code (e.g., JUnit in the JAVA™ programming language, JAVA™ Code Coverage (JaCoCo) as a tool for code coverage, and a source code analyzer for statistically analyzing the code base and learning the vulnerability of the standards of usage. Some source code analyzers (e.g., PMD reports) may help find unused variables, empty catch blocks, unnecessary object creation, etc. The statistical analysis may be presented as one or more of a report, spreadsheet, slide, chart, graph, etc. on a dashboard, and may be segregated or divided into many levels. Examples of QA tools that could be used may include, for example, SONARQUBE™ (formerly SONAR™), DYNATRACE™ (e.g., for monitoring applications on a server), VERACODE (e.g., for security analysis), WHITESOURCE (e.g., for security analysis), APPSPIDER (e.g., for dynamic testing analysis), JMETER (e.g., for service test analysis), etc).
One of ordinary skill in the art would have recognized that applying the known technique of Muddakkagari would have yielded predictable results and resulted in an improved system. It would have been recognized that applying the supervised machine learning technique of Muddakkagari to the decision tree and risk value determination teachings of Nagar would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate such data processing features into similar software development management systems. Further, applying a supervised machine learning technique to Nagar with spillover risk values determined accordingly, would have been recognized by those of ordinary skill in the art as resulting in an improved system that would allow more detailed reports and greater control over the software development lifecycle process.
Thus, through KSR Rationale D (See MPEP 2141(III)(D)), the combination of Nagar and Muddakkagari discloses …create a decision tree structure using the structured attribute dataset to train a supervised learning model and predict spillover risk values, wherein a maximum information retention is determined for predicting the spillover risk values that are obtained when a branching node is created for the structured attribute data.
It would have been obvious to a person of ordinary skill in the art before the effective filing date to have modified the software development risk assessment elements of Fox and the decision tree and spillover risk elements of Nagar to include the supervised learning elements of Muddakkagari in the analogous art of automating and monitoring software development operations for the same reasons as stated for claim 1.
Claim 8 is rejected under 35 U.S.C. 103 as being unpatentable over Fox in view of Nagar and Muddakkagari and further in view of Mohanty, U.S. Publication No. 2023/0065530 via Provisional Application No. 63/260,723 [hereinafter Mohanty].
Regarding Claim 8, the combination of Fox, Nagar and Muddakkagari discloses …the system as claimed in claim 1…
While suggested in at least Fig. 2 and related text of Fox, the combination of Fox, Nagar and Muddakkagari does not explicitly disclose …wherein the structured attribute dataset comprises a ninth attribute data that represents a count of number of comments logged amongst team members in a work item, the number of comments is determined by a number of people communicating in communication threads associated with the structured attribute dataset, and wherein the structured attribute dataset comprises a tenth attribute data representing an attachment count of artifacts signifying complexity within a work item, a higher count of attachments indicates complexity in the work item, and wherein the structured attribute dataset comprises an eleventh attribute data representing a count of defects found in a work item, and wherein the eleventh attribute represents bug occurrences in an unstructured data.
However, Mohanty discloses …wherein the structured attribute dataset comprises a ninth attribute data that represents a count of number of comments logged amongst team members in a work item, the number of comments is determined by a number of people communicating in communication threads associated with the structured attribute dataset, and wherein the structured attribute dataset comprises a tenth attribute data representing an attachment count of artifacts signifying complexity within a work item, a higher count of attachments indicates complexity in the work item, and wherein the structured attribute dataset comprises an eleventh attribute data representing a count of defects found in a work item, and wherein the eleventh attribute represents bug occurrences in an unstructured data (Mohanty, ¶ 212, Referring now to FIG. 9A, the UI screen 900A is shown to include a first user-selectable menu 902 (e.g., a drop-down menu). The first user-selectable menu 902 is shown to include a plurality of user-selectable options that enable the user (e.g., the plurality of users) to create, upload, or link designs (or documents) for a plurality of categories associated with the design stage 216b. The plurality of categories (e.g., the plurality of user-selectable options) may include, but are not limited to, UI design, UX design, collaborative tools, technical design, technical architecture, system architecture, deployment architecture, functional approach, low level design, information architecture, wireframing and prototyping, sitemap, UI tools, user research documents, or the like. The first user-selectable menu 902 (e.g., the plurality of user-selectable options) enables the user to select a category (e.g., a design category) for each design that is to be created, linked, or uploaded. In one embodiment, the software product may be associated with various business requirements or features, various workstreams, or the like. Each business requirement, feature, or workstream may be associated with a corresponding set of designs. The UI screen 900A may include options (not shown) to link, with a business requirement (e.g., the new business requirement), a feature, or a workstream, each design that is to be created, linked, or uploaded. Further, the UI screen 900A is shown to include a collaboration zone 904 that enables the plurality of users to collaborate in the implementation of the design stage 216b of the SDLC of the software product. The collaboration zone 904 is shown to include a first text box 906 that enables the plurality of users to post comments for display in the collaboration zone 904. The first plurality of user actions may include, but are not limited to, an entry in the first text box 906, the selection of the category for each design, selection of the options link the set of designs with a business requirement/workstream/feature, or the like), (Id., ¶ 395, Referring now to FIG. 19D, the UI screen 1900D is rendered by the user action designer 202 when the user-selectable option “Artifact Management” is selected. The UI screen 1900D presents a plurality of artifact management technologies. In other words, a plurality of user-selectable options (as shown by a dotted box 1908) that correspond to the plurality of artifact management technologies may be presented. In a non-limiting example, the plurality of user-selectable options include first through third user-selectable options that correspond to first through third artifact management technologies, respectively), (Id., ¶ 396, Artifact management technologies (e.g., the plurality of artifact management technologies) enable storage and management of binaries (e.g., Docker images) or artifacts. Artifact management technologies are well known to those of skill in the art. The first plurality of technologies 114 include the plurality of artifact management technologies. Detailed explanation of functionality of the plurality of artifact management technologies is skipped to avoid obscuring the disclosure), (Id., ¶ 93, In an embodiment, the development stage 216c may further include a testing sub-stage. During the testing sub-stage, code committed to a repository (e.g., one or more code repositories) may be tested using various one or more unit testing tools. Examples of the one or more unit testing tools include, but are not limited to, Nunit®, JUnit®, TestNG®, or the like. The detected bugs, anomalies, and/or errors may be reported (e.g., to a user who committed the Java code snippet and/or the plurality of users) on the service application 112. In one embodiment, the detected bugs, anomalies, errors, or the like may be debugged or removed automatically by way of one or more features provided by the service application 112, various technologies, or a manual input provided via the plurality of the user devices 102. In other words, the service application 112 allows for testing of the software product to find defects therein. Further, the service application 112 enables the plurality of users to verify whether the developed product behaves as expected and according to definitions and requirements ideated and defined during the define stage 216a).
It would have been obvious to a person of ordinary skill in the art before the effective filing date to have modified the software development risk assessment elements of Fox, the decision tree and spillover risk elements of Nagar and the supervised learning elements of Muddakkagari to include the communication thread and artifact elements of Mohanty in the analogous art of design, development, and deployment of software products.
The motivation for doing so would have been to provide an improved “architecture to facilitate definition, design, development, or deployment of an application” [Mohanty, Abstract], wherein such benefits would improve Muddakkagari’s method which seeks to “increase an organization's ability to deliver applications and services at high velocity: evolving and improving products at a faster pace than other organizations using software development and infrastructure management processes” [Muddakkagari, ¶ 24], and wherein such improvements would further benefit Nagar’s method which seeks to improve the ability of “A software development company… [to] …use the preferences for each base criteria to evaluate possible scenarios for outsourcing different software development tasks” [Nagar, ¶ 19], and wherein such improvements would further benefit Fox’s method which seeks to provide “relevant analytics across the entire software development lifecycle … to increase software development process performance and quality, decreasing waste and ensuring positive business impact” [Mohanty, Abstract; Muddakkagari, ¶ 24; Nagar, ¶ 19; Fox, ¶ 2].
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Alam et al., U.S. Publication No. 2019/0324744 discloses methods, systems, articles of manufacture, and apparatus for a context and complexity-aware recommendation system for improved software development efficiency.
Sabharwal, U.S. Patent No. 11,340,898 discloses a system and method for automating software development life cycle.
Chaptini, U.S. Patent No. 11,593,096 discloses systems and methods for measuring complexity of applications and components in software development and deployment platforms.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to NICHOLAS D BOLEN whose telephone number is (408)918-7631. The examiner can normally be reached Monday - Friday 8:00 AM - 5:00 PM PST.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Patty Munson can be reached at (571) 270-5396. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/NICHOLAS D BOLEN/Examiner, Art Unit 3624 /PATRICIA H MUNSON/Supervisory Patent Examiner, Art Unit 3624
Prosecution Insights