Source: http://www.google.com/patents/US20070006161?dq=7,013,345/
Timestamp: 2017-07-20 16:57:45
Document Index: 193644437

Matched Legal Cases: ['Application No. 60', 'art 100', 'art 200', 'art 300', 'art 300', 'art 400', 'art 200', 'art 200']

Patent US20070006161 - Methods and systems for evaluating the compliance of software to a quality ... - Google PatentsSearch Images Maps Play YouTube News Gmail Drive More »Sign inPatentsA method for evaluating the compliance of software to a standard quality process includes establishing a standard quality process that includes a plurality of stages, each of the plurality of stages corresponding to a software development process. A plurality of objective qualifiers associated with the...http://www.google.com/patents/US20070006161?utm_source=gb-gplus-sharePatent US20070006161 - Methods and systems for evaluating the compliance of software to a quality benchmarkAdvanced Patent SearchTry the new Google Patents, with machine-classified Google Scholar results, and Japanese and South Korean patents.Publication numberUS20070006161 A1Publication typeApplicationApplication numberUS 11/445,201Publication dateJan 4, 2007Filing dateJun 2, 2006Priority dateJun 2, 2005Also published asUS7788632, WO2006130846A2, WO2006130846A3Publication number11445201, 445201, US 2007/0006161 A1, US 2007/006161 A1, US 20070006161 A1, US 20070006161A1, US 2007006161 A1, US 2007006161A1, US-A1-20070006161, US-A1-2007006161, US2007/0006161A1, US2007/006161A1, US20070006161 A1, US20070006161A1, US2007006161 A1, US2007006161A1InventorsAnthony Kuester, Wanda Key, Lillian ZelinskiOriginal AssigneeKuester Anthony E, Key Wanda L, Lillian ZelinskiExport CitationBiBTeX, EndNote, RefManPatent Citations (22), Referenced by (102), Classifications (8), Legal Events (2) External Links: USPTO, USPTO Assignment, EspacenetMethods and systems for evaluating the compliance of software to a quality benchmark
US 20070006161 A1Abstract
A method for evaluating the compliance of software to a standard quality process includes establishing a standard quality process that includes a plurality of stages, each of the plurality of stages corresponding to a software development process. A plurality of objective qualifiers associated with the standard quality process are defined, and a weighting factor is assigned to each of the plurality of objective qualifiers. The method also includes applying each of the plurality of objective qualifiers to a software application, and determining a field worthiness score corresponding to the correlation of the software application with each of the objective qualifiers. Images(8) Claims(45)
1. A method for evaluating the compliance of a software comprising: establishing a standard quality process that includes a plurality of stages, each of the plurality of stages corresponding to a software development process; defining a plurality of objective qualifiers associated with the standard quality process; assigning a weighting factor to each of the plurality of objective qualifiers; applying each of the plurality of objective qualifiers to a software application; and determining a field worthiness score corresponding to the correlation of the software application with each of the objective qualifiers. 2. The method of claim 1, wherein the standard quality process includes a software development life cycle associated with the development of one or more software programs. 3. The method of claim 2, wherein the software development life cycle includes at least one of a requirement definition phase, a project planning and design phase, a build phase, a test phase, or a deliver phase. 4. The method of claim 1, wherein defining a plurality of objective qualifiers includes developing, for each of the plurality of objective qualifiers, a plurality of objective questions, wherein each possible response to each of the plurality of objective questions is assigned a value. 5. The method of claim 4, wherein applying each of the plurality of objective qualifiers to the software application further includes: analyzing the software application; and determining a response to one or more of the plurality of questions based on the analysis. 6. The method of claim 5, wherein determining the field worthiness score includes: determining, based on the determined responses, a raw score associated with each of the plurality of objective qualifiers, wherein the raw score is calculated as the sum of the values corresponding to responses to each of the plurality of questions; and calculating the field worthiness score as the sum of the raw scores associated with each of the plurality of objective qualifiers, wherein each raw score is adjusted by the weighting factor associated with a corresponding objective qualifier. 7. The method of claim 6, further including: comparing the field worthiness score to a predetermined threshold; approving, if the field worthiness score exceeds the predetermined threshold, an implementation of the software application; and determining, if the field worthiness score does not exceed a predetermined threshold, that the software application requires further development prior to implementation. 8. The method of claim 7, further including documenting one or more of the field worthiness score and the raw score associated with each of the plurality of objective qualifiers for future analysis. 9. The method of claim 8, further including providing a report indicative of a potential risk associated with the software application based on the raw score associated with each of the plurality of objective qualifiers. 10. The method of claim 5, wherein analyzing the software application includes evaluating at least a portion of the software application using a predetermined benchmark associated with the software development process. 11. The method of claim 11, wherein the predetermined benchmark includes a statement of work under which the software application was developed. 12. The method of claim 11, wherein the predetermined benchmark includes a predefined software evaluation checklist. 13. The method of claim 1, further including providing a report indicative of a potential risk associated with the software application based on the field worthiness score. 14. The method of claim 1, wherein the weighting factor is predetermined based on a desired level of importance that each of the plurality of object qualifiers has in determining the field worthiness score. 15. The method of claim 14, wherein the desired level of importance is based on empirical data gathered from a previous software development process. 16. A computer-readable medium for use on a computer system, the computer-readable medium having computer-executable instruction for performing a method comprising: comparing a software application to a plurality of objective qualifiers associated with a predetermined standard quality process, the standard quality process having a plurality of stages, each of the plurality of stages corresponding to a software development process, wherein each of the plurality of objective qualifiers is weighted according to a weighting criteria; and determining, based on the comparison. a field worthiness score corresponding to the correlation of the software application with each of the objective qualifiers. 17. The method of claim 16, wherein the standard quality process includes a software development life cycle associated with the development of one or more software programs. 18. The method of claim 17, wherein the software development life cycle includes at least one of a requirement definition phase, a project planning and design phase, a build phase, a test phase, or a deliver phase. 19. The method of claim 16, wherein the plurality of objective qualifiers includes a plurality of objective questions, wherein each possible response to each of the plurality of objective questions is assigned a value. 20. The method of claim 19, wherein comparing the software application to a plurality of objective qualifiers further includes: analyzing the software application; and determining a response to one or more of the plurality of questions based on the analysis. 21. The method of claim 20, wherein determining the field worthiness score includes: determining, based on the determined responses, a raw score associated with each of the plurality of objective qualifiers, wherein the raw score is calculated as the sum of the values corresponding to responses to each of the plurality of questions; and calculating the field worthiness score as the sum of the raw scores associated with each of the plurality of objective qualifiers, wherein each raw score is adjusted by a weighting factor associated with a corresponding objective qualifier. 22. The method of claim 21, further including: comparing the field worthiness score to a predetermined threshold; approving, if the field worthiness score exceeds the predetermined threshold, an implementation of the software application; and determining, if the field worthiness score does not exceed a predetermined threshold, that the software application requires further development prior to implementation. 23. The method of claim 22, further including documenting one or more of the field worthiness score and the raw score associated with each of the plurality of objective qualifiers for future analysis. 24. The method of claim 23, further including providing a report indicative of a potential risk associated with the software application based on the raw score associated with each of the plurality of objective qualifiers. 25. The method of claim 20, wherein analyzing the software application includes evaluating at least a portion of the software application using a predetermined benchmark associated with the software development process. 26. The method of claim 25, wherein the predetermined benchmark includes a statement of work under which the software application was developed. 27. The method of claim 25, wherein the predetermined benchmark includes a predefined software evaluation checklist associated with the software development process. 28. The method of claim 16, wherein the weighting criteria is predetermined based on a desired level of importance that each of the plurality of object qualifiers has in determining the field worthiness score. 29. The method of claim 28, wherein the desired level of importance is based on empirical data gathered from a previous software development process. 30. The method of claim 16, further including providing a report indicative of a potential risk associated with the software application based on the field worthiness score. 31. A computer system, comprising: a display; at least one input device; and a processor in communication with the display and the at least one input device and configured to: compare a software application to a plurality of objective qualifiers associated with a predetermined standard quality process, the standard quality process having a plurality of stages, each of the plurality of stages corresponding to a software development process, wherein each of the plurality of objective qualifiers is weighted according to a weighting criteria; and determine, based on the comparison. a field worthiness score corresponding to the correlation of the software application with each of the objective qualifiers. 32. The computer system of claim 31, wherein the standard quality process includes a software development life cycle associated with the development of one or more software programs. 33. The computer system of claim 32, wherein the software development life cycle includes at least one of a requirement definition phase, a project planning and design phase, a build phase, a test phase, or a deliver phase. 34. The computer system of claim 31, wherein the plurality of objective qualifiers includes a plurality of objective questions, wherein each possible response to each of the plurality of objective questions is assigned a value. 35. The computer system of claim 34, wherein comparing the software application to a plurality of objective qualifiers further includes: analyzing the software application; and determining a response to one or more of the plurality of questions based on the analysis. 36. The computer system of claim 35, wherein determining the field worthiness score includes: determining, based on the determined responses, a raw score associated with each of the plurality of objective qualifiers, wherein the raw score is calculated as the sum of the values corresponding to responses to each of the plurality of questions; and calculating the field worthiness score as the sum of the raw scores associated with each of the plurality of objective qualifiers, wherein each raw score is adjusted by a weighting factor associated with a corresponding objective qualifier. 37. The computer system of claim 36, wherein the processor is further configured to: compare the field worthiness score to a predetermined threshold; approve, if the field worthiness score exceeds the predetermined threshold, an implementation of the software application; and determine, if the field worthiness score does not exceed a predetermined threshold, that the software application requires further development prior to implementation. 38. The computer system of claim 37, wherein the processor is further configured to document one or more of the field worthiness score and the raw score associated with each of the plurality of objective qualifiers for future analysis. 39. The computer system of claim 38, wherein the processor is further configured to provide a report indicative of a potential risk associated with the software application based on the raw score associated with each of the plurality of objective qualifiers. 40. The computer system of claim 35, wherein analyzing the software application includes evaluating at least a portion of the software application using a predetermined benchmark associated with the software development process. 41. The computer system of claim 40, wherein the predetermined benchmark includes a statement of work under which the software application was developed. 42. The computer system of claim 40, wherein the predetermined benchmark includes a predefined software evaluation checklist associated with the software development process. 43. The computer system of claim 31, wherein the weighting criteria is predetermined based on a desired level of importance that each of the plurality of object qualifiers has in determining the field worthiness score. 44. The computer system of claim 43, wherein the desired level of importance is based on empirical data gathered from a previous software development process. 45. The computer system of claim 31, further including providing a report indicative of a potential risk associated with the software application based on the field worthiness score.
RELATED APPLICATIONS [0001] This application claims the benefit of the filing date of U.S. Provisional Application No. 60/686,393, filed Jun. 2, 2005, titled “Methods and Systems for Evaluating the Compliance of a Software to a Quality Benchmark,” by Anthony E. Kuester, Wanda L. Key, and Lillian Zelinski, incorporated in its entirety herein by reference.
TECHNICAL FIELD [0002] This application relates generally to a method for evaluating software and, more specifically, to a method for evaluating the compliance of software to a quality benchmark. BACKGROUND [0003] Over the past several years, software has taken an increasingly important role in the efficient execution of several types of business processes. In fact, software continues to provide much of the infrastructure for reliability and flexibility of automated equipment, whereby older equipment systems are upgraded and modernized through the application and implementation of software systems. In many cases, a software application defines the operability of a particular hardware system. In business processes that rely heavily on efficient use of automated equipment and reliability and repeatability of the functionality of the equipment, it is imperative that the software applications associated with the equipment perform efficiently and predictably. [0004] Traditionally software solutions are designed, developed, and tested in phases, each phase relying heavily on trial and error design processes. Often, software systems or applications are integrated into the business process in small test batches to ensure that the software system is operating predictably and reliably before the systems are deployed throughout the business process. However, in high volume enterprises it may be beneficial to implement new or upgraded software systems efficiently and reliably in a much shorter timeframe than traditional systems. Furthermore, it may be beneficial to evaluate a particular software system based upon a correlation of the software system with a benchmark corresponding to the particular business process that may be implemented. [0005] The disclosed methods and systems for evaluating the compliance of software to a quality benchmark are directed toward overcoming one or more of the problems set forth above. SUMMARY [0006] In accordance with one aspect, the present disclosure is directed toward a method for evaluating the compliance of software to a standard quality process includes establishing a standard quality process that includes a plurality of stages, each of the plurality of stages corresponding to a software development process. A plurality of objective qualifiers associated with the standard quality process may be defined, and a weighting factor may be assigned to each of the plurality of objective qualifiers. The method may also include applying each of the plurality of objective qualifiers to a software application, and determining a field worthiness score corresponding to the correlation of the software with each of the objective qualifiers. [0007] According to another aspect, the present disclosure is directed toward a computer-readable medium for use on a computer system, the computer-readable medium having computer-executable instruction for performing a method for evaluating the compliance of software to a standard quality process. The method may include comparing a software application to a plurality of objective qualifiers associated with a predetermined standard quality process having a plurality of stages, each of which may correspond to a software development process. Each of the plurality of objective qualifiers may be weighted according to a weighting criteria. The method may also include determining, based on the comparison. a field worthiness score corresponding to the correlation of the software with each of the objective qualifiers. [0008] In accordance with yet another aspect, the present disclosure is directed toward a computer system that includes a display, at least one input device, and a processor in communication with the display and the at least one input device. The processor may be configured to compare a software application to a plurality of objective qualifiers associated with a predetermined standard quality process having a plurality of stages, each which may correspond to a software development process. Each of the plurality of objective qualifiers may be weighted according to a weighting criteria. The processor may also be configured to determine, based on the comparison, a field worthiness score corresponding to the correlation of the software application with each of the objective qualifiers.
BRIEF DESCRIPTION OF THE DRAWINGS [0009] FIG. 1 is a diagram of an exemplary standard quality process. [0010] FIG. 2 is an illustration of an exemplary method for evaluating the compliance of software to a quality benchmark. [0011] FIG. 3 is an illustration of an exemplary method for defining a plurality of objective qualifiers. [0012] FIG. 4 is an illustration of an exemplary disclosed method for employing a method for evaluating the compliance of software to a quality benchmark within a business process. [0013] FIG. 5 is an exemplary embodiment of a field worthiness evaluation report for new software releases, referred to as Automation Equipment Plan (AEP). [0014] FIG. 6 is an exemplary embodiment of a field worthiness report for maintenance releases of existing software, referred to as Mail Processing Equipment (MPE). [0015] FIG. 7 is an illustration depicting an exemplary computer system in which systems and methods consistent with the principles of FIG. 2 may be implemented.
DETAILED DESCRIPTION [0016] One embodiment of an evaluation tool to assess the “field worthiness” of software produced by and/or for engineering equipment and systems includes the Field Worthiness Evaluation Report (FWER) that is used by the Engineering Software Process Management (SPM) group of the United States Postal Service (USPS). Effectively, such evaluation tools are a measure of compliance of a software project to the engineering software quality process referred to as the Software Development Life Cycle (SDLC). The more a project follows the defined SDLC quality process, the more likely the software application will meet the required quality standards that allow software to be released to the field operating environment. One example of SDLC includes a five-phase process including: Requirements Definition, Project Planning and Design, Build, Test, and Deliver—each phase having several sub-elements. [0017] In certain embodiments, there are two versions of the FWER. One is tailored for maintenance releases of existing software applications, for example the USPS MPE FWER, standing for the schedule of Mail Processing Equipment software releases. The other is tailored for new acquisitions of software applications, such as the USPS AEP FWER, standing for the Automation Equipment Plan schedule. [0018] In one embodiment, the FWER includes a color-coded method of evaluating software application projects, but this embodiment may be prone to subjective judgment and interpretation, which can lead to a lack of evidence for scoring results and disagreements among the participants in a software project. [0019] Another embodiment is the “quantified FWER”, which uses evaluation criteria that are non-ambiguous and fact based. This embodiment uses sets of questions for each phase/sub-element, which consist of “Yes/No” questions, the answers to which are based upon facts—artifacts, content, completeness, conformance to plan/schedule, etc. According to one embodiment, the questions and answers for each phase/sub-element may be embedded in an Excel workbook, where the “Yes/No” answers drive a calculation engine, producing an unambiguous score for each sub-element. These scores are applied to weighted values, and automatically rolled-up and summed on a summary sheet. The summary allows a final determination of the field worthiness (i.e., conformance to the SDLC) of a given software application project. The weighting of the phases and sub-elements may represent the believed importance of each item in comparison to others and in the context of the entire project life cycle. The summary may be used as a management tool to determine whether or not to release the software to the field, or at least to point to areas of risk, so that if the business case requires the release, the stakeholders would be aware to the issues. Further, the FWER results may be used to identify areas of weakness in the process, to prioritize improvement strategies, and to point to areas where improved management oversight may be warranted. [0020] FIG. 1 is a diagram of an exemplary standard quality process. As illustrated in flowchart 100 of FIG. 1, a standard quality process 100 describes the development of a software application within an operating environment. Standard quality process 100 may be implemented as a standard (or benchmark) for a particular business model or software control process where several software systems interact, where there may be a need to ensure that each software system is developed in substantially the same way. Standard quality process 100 may be defined as a Software Development Life Cycle (SDLC), wherein a software system developed using the Software Development Life Cycle should meet a pre-determined quality standard to allow implementation. Although standard quality process 100 is illustrated as the Software Development Life Cycle, it is conceived that standard quality process 100 may include any such quality standard known in the art for determining the worthiness of software for implementation into a system or process. [0021] As shown, standard quality process 100 may be divided into several sub-phases 110-150, wherein each phase may further define various functions of one or more portions of the development process. For example, exemplary disclosed standard quality process 100 may include a requirements definition phase 110, a project planning and design phase 120, a build phase 130, a test phase 140, and a deliver phase 150. Each phase may be defined according to the role a respective phase takes within the software development process. [0022] The requirements definition phase 110 of standard quality process 100 may include the initial definitions of the requirements of a particular software system. The requirements definition phase may set forth desired functionality of a software system, including the problem solving techniques proposed to define the software solution. For example, for a maintenance release or update of an existing software system, the requirements definition phase 110 may include evaluation of one or more aspects of the updated software such as the past performance of the software, the change request documentation, the statement of work/task order, and software requirement specification. Alternatively, for a new software system, the requirements definition phase 110 may include evaluation of one or more initial characteristics of the new software package, such as desired capabilities, statement of work/task order, software requirements specification, and system/subsystem design description. Requirements definition phase 110 may further include additional evaluation criteria known in the art to ensure proper definition of the functional requirements of a software system. [0023] The project planning and design phase 120 of standard quality process 100 may include specifications for the planning and design of a particular software system. Project planning and design phase 120 may set forth the definitions for the systematic and structural development for the design and function of the software system. For example, for a maintenance release of existing software or for a new software system, the project planning and design phase 120 may include the evaluation of one or more of the software management configuration plan, the software design description, the traceability of the requirements, the software test plan, the software management test plan, the software quality assurance plan, and the proposed implementation schedule. Project planning phase 120 may further include additional evaluation criteria known in the art to ensure proper planning and design of a software system. [0024] The build phase 130 of standard quality process 100 may include specifications for the construction of the software program. Build phase 130 may establish the specific requirements set forth for the development of the software platform. For example, for a new software systems or a software system upgrade, the build phase 130 may include one or more of the evaluation of the software version description, the project development environment, the software release archive, and the software test descriptions. Build phase 130 may further include additional evaluation criteria known in the art to ensure proper construction and assembly of a software system. [0025] The test phase 140 of standard quality process 100 may set forth the requirements for testing and/or debugging of the software program. Test phase 140 may define the specific requirements ensuring that the software program has been sufficiently tested and the test results appropriately documented. For example, for a new software system or an upgrade to an existing software system, test phase 140 may include evaluation or audit of one or more of the independently built software systems, the software version description and associated documentation, the documentation for the in-plant test results, the reports for the first article test results, and the documentation for any beta-test results performed. The evaluation in test phase 240 may also include the review of the standard documentation of any tests performed and the adherence of the tests to existing industry standards. Test phase 140 may further include additional evaluation criteria known in the art to ensure proper testing of a software system. [0026] The deliver phase 150 of standard quality process 100 may define the specification for the appropriate delivery of the software system. Deliver phase 150 may establish the guidelines and requirements for the physical delivery of the software systems to the associated equipment system. For example, for a new software system or an upgrade to an existing software system, deliver phase 150 may include the evaluation of one or more of the final field notifications and associated documentation, the engineering software change order, the software media duplication for the backup of the software, the authorization to install the software, the product announcement, and the deliverables schedule. Deliver phase 150 may further include additional evaluation criteria known in the art to ensure proper delivery of a software system. [0027] FIG. 2 is an illustration of an exemplary method for evaluating the compliance of a software-based system. As shown in flowchart 200 of FIG. 2, upon establishing a standard quality process (stage 210) which may be used for the uniform development of software applications for a plurality of equipment systems, a plurality of objective qualifiers may be defined for objective determination of the adherence of a new or existing software applications to standard quality process 100 (stage 220). For example, the definition of objective qualifiers may include establishing a plurality of “yes/no” questions corresponding to specific requirements or specifications of standard quality process 100, as shown in flowchart 300 of FIG. 3. Alternatively, the definition of objective qualifiers may include other methods of objective analysis such as, for example, a checklist, a punch list, a “true/false” system, or any other objective method known in the art for objective determination of adherence of one or more software systems to a software development process. [0028] The defined objective qualifiers may be assigned a numerical value and weighting factor corresponding to the determination of the conformance of the software system to standard quality process 100 and the importance of the objective qualifier in determining conformance of the software system to standard quality process 100, respectively (stages 230 and 240). In similar fashion to the assignment of numerical values to the responses, as in the foregoing example, the assignment of numerical values and weighting factors to the objective qualifiers serves to provide a raw data indication and a priority of the particular objective qualifier to a calculation system, based upon the qualification of the software system in view of standard quality process 100. [0029] Each of the plurality of objective qualifiers may be applied to a particular software program in order to evaluate correlation of the development of the software program to standard quality process 100 (stage 250), resulting in the calculation of a field worthiness score which may be indicative of the correlation (stage 260). The field worthiness score may correspond to how closely the development of the software program may have followed the standard guidelines established by the standard quality process 100. The field worthiness score may be an indication of a potential ability of the software program to be deployed or implemented in a software-based system or process. The field worthiness score may also be used to address potential risk factors associated with the deployment of the software program or insufficiencies in the cooperation of the program with other applications developed using standard quality process 100. [0030] FIG. 3 is an illustration of an exemplary method for defining a plurality of objective qualifiers. As illustrated in flowchart 300 of FIG. 3, defining a plurality of objective qualifiers may be initiated by one or more questions directed to deliver a response indicative of the comparison to standard quality process 100 (stage 310). For example, a question may be directed to whether a previous software application version required an emergency patch to correct flaws in the previous software version. A “yes” response may indicate that a previous performance problem existed. A “no” response may indicate that the previous performance problem did not exist. These questions may contribute to the analysis of the requirements definition phase of the software update. Likewise, the one or more questions developed to define the plurality objective qualifiers may contribute to the determination of the overall compliance of a new or updated software system to standard quality process 100. [0031] Upon specifying the one or more questions which may serve as the objective qualifiers, numerical values may be assigned to each response of one or more questions, wherein the numerical values may provide a raw data value for each of the respective responses (stage 320). As in the example above, a “yes” response may be assigned a numerical value indicative of the contribution that the correction of flaws may have on the standard quality process. For example, the numerical value of 0 may be assigned to a “yes” response, since an emergency patch to correct a potential performance flaw of a previous version has no contribution to the quality of the past performance. Likewise, a “no” response may be assigned a different numerical value indicative of the contribution that the lack of the correction of flaws may have on standard quality process 100. For example, the numerical value of 50 may be assigned to a “no” response, since the past performance was such that an emergency patch was not required to address a potential flaw. The numerical values provide a raw data value, which may be further analyzed to assist in the evaluation of the software system. [0032] According to another exemplary embodiment, questions may be directed toward one or more activities associated with a particular software development entity (e.g., software development business unit of USPS, independent software development firm, software contractor, etc.). For example, in determining the field worthiness score associated with a project planning and design phase, one or more questions may be directed toward objectively analyzing the compliance of the activities of a software developer with one or more deliverables required by a statement of work under which the software application was developed. These questions may be directed, for example, to whether a software developer delivered a software design description (SDD) in accordance with the provisions of the statement of work (SOW), whether a software project manager has evaluated the SDD to ensure accordance with any applicable standards; whether the project manager has accepted the SDD from the developer; and whether any issues associated with the SDD have been appropriately resolved in accordance with the SOW. “Yes” responses to each of these questions may indicate compliance of the software design process to the SOW. Points may be awarded for “yes” responses based on the predetermined value that each planning milestone plays in the overall quality of the software application. This predetermined value may be based on empirical data collected from past software development processes. [0033] Similarly, “no” answers to these objective questions may indicate a non-compliance of the software application with one or more project planning and design phase elements. Accordingly, “no” responses may be assigned predetermined numerical values indicative of the impact that non-compliance may have on the overall quality of the software application. As indicated above, this value may be quantified based on experimental data from previous software development process. According to one embodiment, non-compliance may have no impact and may be assigned a value of “0”. It is contemplated, however, that in certain other cases, non-compliance may have a negative impact on the software application and may be assigned a negative value. For example, historical test data may indicate that a failure to obtain final approval for an SDD, where all other requirements have been met, has no impact on the compliance of the final software application to the benchmark. In contrast, failure to provide an SDD altogether may actually have a negative impact on the compliance of the software application to the quality benchmark. [0034] According to another exemplary embodiment, one or more questions may be directed toward a software version description (SVD) associated with the build phase of the software development life cycle. The SVD may include one or more aspects associated with bug and/or virus vulnerability of the software application, system requirements (e.g., operating systems, software interface requirements, etc.), data recovery features and/or procedures, or any other critical information. For example, one question may be directed toward whether the SVD complies with a standard SVD template. A “yes” response may indicate that the SVD may be implemented directly with one or more existing software applications without SVD modification and/or standardization. Consequently, a “yes” response may be assigned a predetermined numerical value corresponding to the contribution that this compliance may have on standard quality process 100. A “no” response may be assigned a numerical value of “0”, as the lack of compliance of the SVD with the SVD template provides no contribution to the overall compliance of the software application to the standard quality process 100. [0035] In additional to the assignment of numerical values for the responses to each of the one or more questions, a weighting value may be assigned to each of the one or more responses (stage 330). Assignment of the weighting value for each of the one or more questions may include determination of the importance that each of the one or more questions may have to the overall determination of the software system's conformance to standard quality process 100. For example, it may be determined that questions related to the test phase of the software system may have significantly less impact on the evaluation of the software system than the requirements determination phase. Therefore, questions related to the requirements definition phase may be assigned a weighting value indicative of the importance of those questions in relation to the questions corresponding to the test phase. This may ensure that each of the phases of standard quality process 100 may be appropriately evaluated. [0036] Calculation of a score based upon tabulation of the values corresponding to the responses of the one or more questions and the respective weighting values of each of the one or more questions may be performed (stage 340) and the results may be provided to a calculation system for further analysis (stage 350). The calculation of the score may include inputting the raw data values in a tabular form, applying the weighting values to the raw data thereby providing corrected data, and determining a score for each of the one or more phases of the software system with respect to standard quality process 100. The calculation may be performed by any number of appropriate methods known in the art for performing general calculation on raw parametric data such as, for example, a computer program, a calculating device, a digital logic circuit, or any other calculation method. The data may then be provided to an associated calculation system, which may further analyze the raw and/or corrected data values for broader analysis. [0037] As described thus far, the evaluation of the compliance of a software application may be used to objectively evaluate any software that may be implemented within a software-based system. In one exemplary disclosed embodiment, a software system may be evaluated with respect to the correlation of the software system to a standard quality process 100 to determine a field worthiness score corresponding to the potential ability of the software application program to be deployed in a business process. An exemplary system for applying the disclosed evaluation method will now be described in detail. [0038] FIG. 4 is an illustration of an exemplary disclosed method for employing a method for evaluating the compliance of a software-based system within a business process. As illustrated in flowchart 400 of FIG. 4, a field worthiness score is determined according to the exemplary method for evaluation of the compliance of software, for example, as illustrated in flowchart 200 (stage 410). The field worthiness score, when viewed in context with the standard quality process 100, may provide an indication of potential risk factors or problem areas associated with the software (stage 420). For example, in evaluation of the compliance of the software system with the requirements definitions phase 110 of standard quality process 100, low corrected values corresponding to the compliance of the software system to requirements definitions phase 110 may indicate that the software system may not have an adequate preliminary definition of desired functionality. In such circumstances, a software management team may choose to evaluate the functionality of the software system more closely prior to deploying the system in the field. [0039] After the potential risks and weaknesses have been evaluated, a decision may be made as to whether the software application could be effectively deployed (stage 430). Although the decision may be based upon the field worthiness score and/or report, this decision may be subjective. A determination to deploy the software system may be accompanied by documenting any potential risk factors that may exist along with the implementation of the software system within the software-based environment (stage 440). Alternatively, if the decision is made not to release the software system, the software may be redeveloped or revised, based upon determination of the software development management team (stage 450), wherein any subsequent versions of the software system may be re-evaluated by the disclosed method for software evaluation (stage 460). Re-evaluation of the software system would essentially require that any subsequent revisions would be applied to the same “quantified FWER,” as disclosed, for example, in flowchart 200, so that any revisions that were made may be included in the report. [0040] The method described in FIG. 4 for the evaluation of the compliance of software has several advantages. For example, since a software system is evaluated based upon the conformance of the system to a standard quality process, each new software system may be objectively analyzed based upon the same criteria as each existing software system. This may provide a standard measure for each particular software system, thereby providing a more reliable evaluation method than other evaluation systems, which may use only function-based evaluation methods. [0041] The method of FIG. 4 may thus reduce the need for trial and error software development, as the disclosed method for evaluation of software compliance provides an objective analysis on how closely a particular software development process corresponds to a standard quality process. Since this method may be highly repeatable, with substantially similar results, a determination can be made during each phase of the software design process of how closely the developing software meets the standard specification. This may substantially reduce the time required to complete the software development process, thereby reducing the development costs and providing a more reliable field deployable software product. [0042] The exemplary disclosed field worthiness evaluation reports of FIG. 5 and FIG. 6 are examples of reports for Automated Equipment Programs and Mail Processing Equipment embodiments, respectively. FIG. 5 is an exemplary embodiment of a field worthiness evaluation report for new software releases, referred to as Automation Equipment Plan (AEP). FIG. 6 is an exemplary embodiment of a field worthiness report for maintenance releases of existing software, referred to as Mail Processing Equipment (MPE). In FIGS. 5 and 6, each phase of standard quality process 100 is defined in detail, with a plurality of objective qualifiers corresponding to each phase, as shown. [0043] Each of the plurality of objective qualifiers may be associated with a plurality of “yes/no” questions, each question assigned a point value for each response. According to one embodiment, the plurality of objective qualifiers and/or the plurality of objective questions may each be directed to one or more aspects associated with the software development process. For example, one or more of the plurality of objective questions (and the responses thereto) may be directed toward determining how closely one or more aspects of the software application correlate with predetermined benchmarks established prior to the development of the software. [0044] Systems and methods consistent with the present invention may be implemented by computers organized in a conventional distributed processing system architecture. FIG. 7 is a block diagram illustrating a computer system 700 in which an embodiment consistent with the invention may be implemented. Computer system 700 includes a computer 701 having a bus 702 or other communication mechanism for communicating information, and a processor 704 coupled with bus 702 for processing information. Computer 701 also includes a main memory, such as random access memory (RAM) 706 or other dynamic storage device, coupled to bus 702 for storing information and instructions by processor 704. RAM 706 also may be used for storing temporary variables or other intermediate information during execution of instructions to be executed by processor 704. During operation, some or all portions of an operating system (not shown) are loaded into RAM 706. Computer 701 further includes a read only memory (ROM) 708 or other static storage device coupled to bus 702 for storing static information and instructions for processor 704. A storage device 710, such as a magnetic disk or optical disk, is provided and coupled to bus 702 for storing information and instructions. [0045] Computer 701 may be coupled via bus 702 to a display 712, such as a cathode ray tube (CRT), for displaying information to a computer user. An input device 714, including alphanumeric and other keys, is coupled to bus 702 for communicating information and command selections to processor 704. Another type of user input device is cursor control 716, such as a mouse, a trackball or cursor direction keys for communicating direction information and command selections to processor 704 and for controlling cursor movement on display 712. This input device may have two degrees of freedom in two axes, a first axis (e.g., x) and a second axis (e.g., y), which allow the device to specify positions in a plane. [0046] System 700 may further include an input drive device 717, such as a CD reader, for reading high capacity computer-readable media, such as CD-ROMs and CDRs. [0047] The invention is related to the use of computer system 700 for evaluating software to a benchmark. According to one implementation, systems and methods consistent with the present invention use processor 704 to execute one or more sequences of one or more instructions contained in RAM 706. Such instructions may be read into RAM 706 from a computer-readable medium via an input device such as storage device 710. Execution of the sequences of instructions contained in main memory 706 causes processor 704 to perform the process steps described herein. In an alternative implementation, hard-wired circuitry may be used in place of or in combination with software instructions to implement the invention. Thus, implementations consistent with the principles of the present invention are not limited to any specific combination of hardware circuitry and software. [0048] Computer 701 also includes a communication interface 718 coupled to bus 702. Communication interface 718 provides a two-way data communication coupling to a network link 720 that is connected to local network 722. For example, communication interface 718 may be an integrated services digital network (ISDN) card or a modem to provide a data communication connection to a corresponding type of telephone line. As another example, communication interface 718 may be a local area network (LAN) card to provide a data communication connection to a compatible LAN. Wireless links may also be implemented. In any such implementation, communication interface 718 sends and receives electrical, electromagnetic or optical signals that carry digital data streams representing various types of information. [0049] Network link 720 typically provides data communication through one or more networks to other data devices. For example, network link 720 may provide a connection through local network 722 to host computer 724 and/or to data equipment operated by Internet Service Provider (ISP) 726. ISP 726, in turn, provides data communication services through the Internet 728. Local network 722 and Internet 728 both use electric, electromagnetic or optical signals that carry digital data streams. The signals through the various networks and the signals on network link 720 and through communication interface 718, which carry the digital data to and from computer system 700, are exemplary forms of carrier waves transporting the information. [0050] Computer system 700 can send messages and receive data, including program code, through the network(s), network link 720 and communication interface 718. In the Internet example, a server 730 might transmit a requested code for an application program through Internet 728, ISP 726, local network 722 and communication interface 718. The received code may be loaded in RAM 706 and executed by processor 704 as it is received. Alternatively, or in addition, it may be stored in storage device 710, or other non-volatile storage for later execution. In this manner, computer system 700 may obtain application code in the form of a carrier wave. [0051] Although computer system 700 is shown in FIG. 7 as being connectable to one server 730, those skilled in the art will recognize that computer system 700 may establish connections to multiple servers on Internet 728. Such servers may include an HTML-based Internet application, which may provide information to computer system 700 upon request in a manner consistent with the present invention. [0052] The foregoing descriptions of the invention have been presented for purposes of illustration and description. They are not exhaustive and do not limit the invention to the precise form disclosed. Modifications and variations are possible in light of the above teachings or may be acquired from practicing of the invention. For example, the described implementation includes software but the present invention may be implemented as a combination of hardware and software or in hardware alone. Additionally, although aspects of the present invention are described as being stored in memory, one skilled in the art will appreciate that these aspects can also be stored on other types of computer-readable media, such as secondary storage devices, like hard disks, floppy disks, or CD-ROM; a carrier wave from the Internet or other propagation medium; or other forms of RAM or ROM. [0053] It will be apparent to those skilled in the art that various modifications and variations can be made to the methods and systems without departing from the scope of the invention. Other embodiments of the present disclosure will be apparent to those skilled in the art from consideration of the specification and practice of the present disclosure. It is intended that the specification and examples be considered as exemplary only, with a true scope of the present disclosure being indicated by the following claims and their equivalents. Patent CitationsCited PatentFiling datePublication dateApplicantTitleUS5428788 *Jun 4, 1993Jun 27, 1995Siemens Corporate Research, Inc.Feature ratio method for computing software similarityUS5446895 *Mar 31, 1994Aug 29, 1995White; Leonard R.Measurement analysis software system and methodUS5485621 *Apr 6, 1994Jan 16, 1996Siemens Corporate Research, Inc.Interactive method of using a group similarity measure for providing a decision on which groups to combineUS5500795 *Jul 6, 1994Mar 19, 1996Teknekron Infoswitch CorporationMethod and system for monitoring and controlling the performance of a call processing centerUS5907704 *Oct 2, 1996May 25, 1999Quark, Inc.Hierarchical encapsulation of instantiated objects in a multimedia authoring system including internet accessible objectsUS6438594 *Aug 31, 1999Aug 20, 2002Accenture LlpDelivering service to a client via a locally addressable interfaceUS6532586 *Apr 30, 1997Mar 11, 2003Information System Development InstituteSoftware producing method, processor, processing method and recording mediumUS6601233 *Jul 30, 1999Jul 29, 2003Accenture LlpBusiness components frameworkUS6618852 *Sep 13, 1999Sep 9, 2003Intellichem, Inc.Object-oriented framework for chemical-process-development decision-support applicationsUS6671874 *Apr 3, 2000Dec 30, 2003Sofia PassovaUniversal verification and validation system and method of computer-aided software quality assurance and testingUS6904449 *Jan 14, 2000Jun 7, 2005Accenture LlpSystem and method for an application provider frameworkUS7047518 *Oct 4, 2001May 16, 2006Bea Systems, Inc.System for software application development and modelingUS7149734 *Mar 26, 2002Dec 12, 2006Logic Library, Inc.Managing reusable software assetsUS7240327 *Jun 4, 2003Jul 3, 2007Sap AgCross-platform development for devices with heterogeneous capabilitiesUS7272823 *Aug 22, 2002Sep 18, 2007Sun Microsystems, Inc.Method and apparatus for software metrics immediate feedback mechanismUS7430498 *Sep 7, 2004Sep 30, 2008The Boeing CompanySystem, method and computer program product for developing a system-of-systems architecture modelUS7448020 *Nov 18, 2004Nov 4, 2008International Business Machines CorporationAutonomic computing system, execution environment control method and programUS7472373 *Feb 20, 2004Dec 30, 2008International Business Machines CorporationMethod and system to gauge and control project churnUS7627855 *Oct 2, 2002Dec 1, 2009Japan Science And Technology AgencySoftware component importance evaluation systemUS20030097308 *Nov 16, 2001May 22, 2003Mary ConnorsSoftware evaluation toolUS20040243968 *May 27, 2003Dec 2, 2004Sun Microsystems, Inc.System and method for software methodology evaluation and selectionUS20050015675 *Jul 3, 2003Jan 20, 2005Kolawa Adam K.Method and system for automatic error prevention for computer software* Cited by examinerReferenced byCiting PatentFiling datePublication dateApplicantTitleUS7823124Aug 29, 2006Oct 26, 2010Sap AgTransformation layerUS7827528Aug 29, 2006Nov 2, 2010Sap AgDelta layeringUS7831568Aug 29, 2006Nov 9, 2010Sap AgData migrationUS7831637Aug 29, 2006Nov 9, 2010Sap AgSystem on the flyUS7908589Aug 29, 2006Mar 15, 2011Sap AgDeploymentUS7934214 *Mar 31, 2006Apr 26, 2011Lenovo (Singapore) Pte Ltd.Computer implemented method, system and computer program product for controlling software entitlementUS7958494 *Apr 13, 2007Jun 7, 2011International Business Machines CorporationRapid on-boarding of a software factoryUS8028269 *Mar 9, 2007Sep 27, 2011International Business Machines CorporationCompliance management method and systemUS8037455 *Aug 30, 2006Oct 11, 2011Siemens AktiengesellschaftMethod and device for the automated evaluation of software source code qualityUS8065661Aug 29, 2006Nov 22, 2011Sap AgTest engineUS8131644Aug 29, 2006Mar 6, 2012Sap AgFormular updateUS8135659Oct 1, 2008Mar 13, 2012Sap AgSystem configuration comparison to identify process variationUS8141030Aug 7, 2007Mar 20, 2012International Business Machines CorporationDynamic routing and load balancing packet distribution with a software factoryUS8141040Apr 13, 2007Mar 20, 2012International Business Machines CorporationAssembling work packets within a software factoryUS8219983 *Mar 31, 2008Jul 10, 2012Symantec CorporationSystems and methods for providing guidance on the potential impact of application and operating-system changes on a computing systemUS8255429Dec 17, 2008Aug 28, 2012Sap AgConfiguration change without disruption of incomplete processesUS8255881Jun 19, 2008Aug 28, 2012Caterpillar Inc.System and method for calculating software certification risksUS8271949Jul 31, 2008Sep 18, 2012International Business Machines CorporationSelf-healing factory processes in a software factoryUS8280756 *Aug 3, 2005Oct 2, 2012Sprint Communications Company L.P.Milestone initial schedulingUS8296719Apr 13, 2007Oct 23, 2012International Business Machines CorporationSoftware factory readiness reviewUS8327318Apr 13, 2007Dec 4, 2012International Business Machines CorporationSoftware factory health monitoringUS8332807Aug 10, 2007Dec 11, 2012International Business Machines CorporationWaste determinants identification and elimination process model within a software factory operating environmentUS8336026Jul 31, 2008Dec 18, 2012International Business Machines CorporationSupporting a work packet request with a specifically tailored IDEUS8341591Apr 13, 2006Dec 25, 2012Sprint Communications Company, L.P.Method and software tool for real-time optioning in a software development pipelineUS8359566Apr 13, 2007Jan 22, 2013International Business Machines CorporationSoftware factoryUS8370188Feb 3, 2012Feb 5, 2013International Business Machines CorporationManagement of work packets in a software factoryUS8375370Jul 23, 2008Feb 12, 2013International Business Machines CorporationApplication/service event root cause traceability causal and impact analyzerUS8396893Dec 11, 2008Mar 12, 2013Sap AgUnified configuration of multiple applicationsUS8407073Aug 25, 2010Mar 26, 2013International Business Machines CorporationScheduling resources from a multi-skill multi-level human resource poolUS8418126Jul 23, 2008Apr 9, 2013International Business Machines CorporationSoftware factory semantic reconciliation of data models for work packetsUS8448129Jul 31, 2008May 21, 2013International Business Machines CorporationWork packet delegation in a software factoryUS8452629Jul 15, 2008May 28, 2013International Business Machines CorporationWork packet enabled active project schedule maintenanceUS8464205Apr 13, 2007Jun 11, 2013International Business Machines CorporationLife cycle of a work packet in a software factoryUS8527329Jul 15, 2008Sep 3, 2013International Business Machines CorporationConfiguring design centers, assembly lines and job shops of a global delivery network into “on demand” factoriesUS8539437Aug 30, 2007Sep 17, 2013International Business Machines CorporationSecurity process model for tasks within a software factoryUS8566777Apr 13, 2007Oct 22, 2013International Business Machines CorporationWork packet forecasting in a software factoryUS8589882 *Jun 22, 2010Nov 19, 2013International Business Machines CorporationAnalyzing computer code development actions and processUS8595044May 29, 2008Nov 26, 2013International Business Machines CorporationDetermining competence levels of teams working within a softwareUS8606614Apr 13, 2006Dec 10, 2013Sprint Communications Company L.P.Hardware/software and vendor labor integration in pipeline managementUS8612275Aug 3, 2005Dec 17, 2013Sprint Communications Company L.P.Spreading algorithm for work and time forecastingUS8639553Apr 13, 2006Jan 28, 2014Sprint Communications Company L.P.Predictive growth burn rate in development pipelineUS8660878Jun 15, 2011Feb 25, 2014International Business Machines CorporationModel-driven assignment of work to a software factoryUS8667469May 29, 2008Mar 4, 2014International Business Machines CorporationStaged automated validation of work packets inputs and deliverables in a software factoryUS8671007Mar 5, 2013Mar 11, 2014International Business Machines CorporationWork packet enabled active project management scheduleUS8682701Apr 13, 2006Mar 25, 2014Sprint Communications Company L.P.Project pipeline management systems and methods having capital expenditure/expense flip targetingUS8694969Jun 8, 2012Apr 8, 2014International Business Machines CorporationAnalyzing factory processes in a software factoryUS8694983 *May 16, 2012Apr 8, 2014Symantec CorporationSystems and methods for providing guidance on the potential impact of application and operating-system changes on a computing systemUS8782598Sep 12, 2012Jul 15, 2014International Business Machines CorporationSupporting a work packet request with a specifically tailored IDEUS8924916 *Nov 9, 2012Dec 30, 2014Bank Of America CorporationSoftware development standards compliance systemUS8984472Nov 25, 2014Mar 17, 2015Bank Of America CorporationSoftware development standards compliance systemUS9053441 *Jan 23, 2012Jun 9, 2015GxPReady, Inc.Systems and methods for regulatory compliance with qualified systemsUS9158655 *Jul 9, 2013Oct 13, 2015Bank Of America CorporationComputer development assessment systemUS9158663 *Mar 5, 2013Oct 13, 2015Tata Consultancy Services LimitedEvaluating performance maturity level of an applicationUS9189757Aug 23, 2007Nov 17, 2015International Business Machines CorporationMonitoring and maintaining balance of factory quality attributes within a software factory environmentUS9646273Jun 21, 2013May 9, 2017International Business Machines CorporationSystems engineering solution analysisUS20070055959 *Aug 30, 2006Mar 8, 2007Horst EckardtMethod and device for the automated evaluation of software source code qualityUS20070088589 *Oct 17, 2005Apr 19, 2007International Business Machines CorporationMethod and system for assessing automation package readiness and and effort for completionUS20070234348 *Mar 31, 2006Oct 4, 2007Lenovo (Singapore) Pte. Ltd.Computer implemented method, system and computer program product for controlling software entitlementUS20080059630 *Aug 29, 2006Mar 6, 2008Juergen SattlerAssistantUS20080071555 *Aug 29, 2006Mar 20, 2008Juergen SattlerApplication solution proposal engineUS20080071828 *Aug 29, 2006Mar 20, 2008Juergen SattlerFormular updateUS20080082517 *Aug 29, 2006Apr 3, 2008Sap AgChange assistantUS20080126448 *Aug 29, 2006May 29, 2008Juergen SattlerTest engineUS20080127082 *Aug 29, 2006May 29, 2008Miho Emil BirimisaSystem and method for requirements-based application configurationUS20080127084 *Aug 29, 2006May 29, 2008Sap AgDeploymentUS20080127085 *Aug 29, 2006May 29, 2008Juergen SattlerSystem on the flyUS20080127123 *Aug 29, 2006May 29, 2008Juergen SattlerTransformation layerUS20080222631 *Mar 9, 2007Sep 11, 2008Ritu BhatiaCompliance management method and systemUS20080255693 *Apr 13, 2007Oct 16, 2008Chaar Jarir KSoftware Factory Readiness ReviewUS20080255696 *Apr 13, 2007Oct 16, 2008Chaar Jarir KSoftware Factory Health MonitoringUS20080256390 *Apr 13, 2007Oct 16, 2008Chaar Jarir KProject Induction in a Software FactoryUS20080256505 *Apr 13, 2007Oct 16, 2008Chaar Jarir KRapid On-Boarding of a Software FactoryUS20080256506 *Apr 13, 2007Oct 16, 2008Chaar Jarir KAssembling Work Packets Within a Software FactoryUS20080256507 *Apr 13, 2007Oct 16, 2008Chaar Jarir KLife Cycle of a Work Packet in a Software FactoryUS20080256516 *Apr 13, 2007Oct 16, 2008Chaar Jarir KSoftware FactoryUS20080256529 *Apr 13, 2007Oct 16, 2008Chaar Jarir KWork Packet Forecasting in a Software FactoryUS20090037869 *Jul 30, 2007Feb 5, 2009Darin Edward HamiltonSystem and method for evaluating a product development processUS20090043622 *Aug 10, 2007Feb 12, 2009Finlayson Ronald DWaste Determinants Identification and Elimination Process Model Within a Software Factory Operating EnvironmentUS20090043631 *Aug 7, 2007Feb 12, 2009Finlayson Ronald DDynamic Routing and Load Balancing Packet Distribution with a Software FactoryUS20090055795 *Aug 23, 2007Feb 26, 2009Finlayson Ronald DSystem to Monitor and Maintain Balance of Factory Quality Attributes Within a Software Factory Operating EnvironmentUS20090064322 *Aug 30, 2007Mar 5, 2009Finlayson Ronald DSecurity Process Model for Tasks Within a Software FactoryUS20090300586 *May 29, 2008Dec 3, 2009International Business Machines CorporationStaged automated validation of work packets inputs and deliverables in a software factoryUS20090319980 *Jun 19, 2008Dec 24, 2009Caterpillar Inc.System and method for calculating software certification risksUS20100017782 *Jul 15, 2008Jan 21, 2010International Business Machines CorporationConfiguring design centers, assembly lines and job shops of a global delivery network into "on demand" factoriesUS20100023918 *Jul 22, 2008Jan 28, 2010International Business Machines CorporationOpen marketplace for distributed service arbitrage with integrated risk managementUS20100023920 *Jul 22, 2008Jan 28, 2010International Business Machines CorporationIntelligent job artifact set analyzer, optimizer and re-constructorUS20100023921 *Jul 23, 2008Jan 28, 2010International Business Machines CorporationSoftware factory semantic reconciliation of data models for work packetsUS20100031090 *Jul 31, 2008Feb 4, 2010International Business Machines CorporationSelf-healing factory processes in a software factoryUS20100031226 *Jul 31, 2008Feb 4, 2010International Business Machines CorporationWork packet delegation in a software factoryUS20100031234 *Jul 31, 2008Feb 4, 2010International Business Machines CorporationSupporting a work packet request with a specifically tailored ideUS20100082518 *Oct 1, 2008Apr 1, 2010Joachim GaffgaSystem configuration comparison to identify process variationUS20100153443 *Dec 11, 2008Jun 17, 2010Sap AgUnified configuration of multiple applicationsUS20100153468 *Dec 17, 2008Jun 17, 2010Sap AgConfiguration change without disruption of incomplete processesUS20110138352 *Dec 17, 2010Jun 9, 2011International Business Machines CorporationMethod and System for Assessing Automation Package Readiness and Effort for CompletionUS20110314450 *Jun 22, 2010Dec 22, 2011International Business Machines CorporationAnalyzing computer code development actions and processUS20120278900 *Jan 23, 2012Nov 1, 2012Vince SebaldSystems and methods for regulatory compliance with qualified systemsUS20130019315 *Sep 14, 2012Jan 17, 2013Bank Of America CorporationDesigning security into software during the development lifecycleUS20130117075 *Nov 4, 2011May 9, 2013Richard BrownProject compliance assessmentUS20140040871 *Aug 2, 2013Feb 6, 2014Solstice Consulting, LLCMobile build, quality and deployment managerUS20140137071 *Nov 9, 2012May 15, 2014Bank Of America CorporationSoftware Development Standards Compliance SystemUS20140201714 *Mar 5, 2013Jul 17, 2014Tata Consultancy Services LimitedEvaluating performance maturity level of an applicationUS20140331200 *Jul 9, 2013Nov 6, 2014Bank Of America CorporationComputer Development Assessment System* Cited by examinerClassifications U.S. Classification717/126, 717/121, 717/100International ClassificationG06F9/44Cooperative ClassificationG06Q10/06, G06F11/3672European ClassificationG06Q10/06, G06F11/36T2Legal EventsDateCodeEventDescriptionAug 4, 2006ASAssignmentOwner name: UNITED STATES POSTAL SERVICE, DISTRICT OF COLUMBIAFree format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:KUESTER, ANTHONY E.;KEY, WANDA L.;ZELINSKI, LILLIAN;REEL/FRAME:018133/0851;SIGNING DATES FROM 20060724 TO 20060727Owner name: UNITED STATES POSTAL SERVICE, DISTRICT OF COLUMBIAFree format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:KUESTER, ANTHONY E.;KEY, WANDA L.;ZELINSKI, LILLIAN;SIGNING DATES FROM 20060724 TO 20060727;REEL/FRAME:018133/0851Dec 23, 2013FPAYFee paymentYear of fee payment: 4RotateOriginal ImageGoogle Home - Sitemap - USPTO Bulk Downloads - Privacy Policy - Terms of Service - About Google Patents - Send FeedbackData provided by IFI CLAIMS Patent Services