Abstract:
The present invention discloses an end-to-end software development system that includes multiple computing devices, a network data store, and a usage reporting engine. Each of the computing devices can execute a software product that is configured to automatically log usage information on a feature-by-feature basis. The network data store can aggregate logged usage information obtained from the computing devices. The usage report engine can analyze data of the network data store and can generate feature-by-feature usage reports. These reports can be used to focus a software development effort on user desired features and/or upon previous software product shortcomings.

Description:
BACKGROUND 
       [0001]    1. Field of the Invention 
         [0002]    The present invention relates to the field of software development and, more particularly, to software product changes based on usage patterns gathered from users of previous product releases. 
         [0003]    2. Description of the Related Art 
         [0004]    A majority of successful software products are modified in a series of iterative version releases. New versions provide new desired features, integrate new technologies into an existing product, and generally correct perceived shortcomings of previous releases. A success of a new version of a software product can ultimately be determined by a user population and whether this population utilizes and is satisfied by the new features/changes made in the new version of the software product. 
         [0005]    Several conventional factors drive the evolution of a software product such as competition, market opportunities, and user feedback. User feedback is a pivotal factor and can be obtained in the form of surveys and usability studies. These forms of user feedback are important to the software industry as evidenced by their widespread use. Traditional feedback forms have a number of significant limitations, such as response biases. 
         [0006]    Additionally, survey instruments, incentivized feedback, usage studies, and other product success determination techniques are expensive and time consuming to implement. Traditional methods include user surveys and usability testing, which are limited in scope. At present, conventional software evolution is based on a set of educated guesses regarding what end-users desire and a series of additional guesses regarding whether new features are actually being utilized and valued by end users. So while user insight and feedback is important to the software requirement management process, it is often an incomplete and one dimensional source of information. It would be advantageous if automated real-time usage patterns, generated directly from the real-time usage of an application, could be integrated into the software development cycle to aid in creating more successful software revisions that can be successfully adopted and effectively used by end users. It would also be beneficial if feature enhancement usage was tracked by development tools against expected end user usage patterns to systematically determine feature success. 
       SUMMARY OF THE INVENTION 
       [0007]    The present invention discloses a solution for directing software evolution based upon real time usage patterns of previous product releases. In the solution, usage patterns obtained from a software application&#39;s user population can be used to direct the requirements management process. This solution can be used in parallel to current development techniques increasing the correlation between software evolution and user needs. Effectively, the disclosed solution adds a “sense and respond” capability to the software design process, where software developers are granted insights into useful features, usability issues, training needs, and other concerns about a software product. These insights can be gleaned from reports showing how a previous release of a product is actually used in a production environment on a feature-by-feature basis. 
         [0008]    More specifically, usage patterns can be recorded and conveyed to a central repository. For example, feature use, frequency, and duration can be monitored from the actual production environment as a software product is used. In one embodiment, user specific metrics, such as expertise level or authority level can be monitored and mapped to specific software feature usage. Usage data can be aggregated in a central repository for data mining. Data mining can allow for the production of usage pattern reports, which can give rise to meaningful relationships between user activity and software features. Generated reports can be used to present correlations between requirements management and software features. These correlations can be useful in project planning, task management, execution faults, and feature development prioritization. 
         [0009]    It should be noted that various embodiments of the invention can be implemented as a program for controlling computing equipment to implement the functions described herein, or as a program for enabling computing equipment to perform processes corresponding to the steps disclosed herein. This program may be provided by storing the program in a magnetic disk, an optical disk, a semiconductor memory, any other recording medium, or can also be provided as a digitally encoded signal conveyed via a carrier wave. The described program can be a single program or can be implemented as multiple subprograms, each of which interact within a single computing device or interact in a distributed fashion across a network space. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0010]    There are shown in the drawings, embodiments which are presently preferred, it being understood, however, that the invention is not limited to the precise arrangements and instrumentalities shown. 
           [0011]      FIG. 1  is a schematic diagram illustrating a system in which software is developed as part of an end-to-end iterative solution in which software changes are driven by actual software usage information. 
           [0012]      FIG. 2  is a sample report showing actual usage of a Top N number of features verses expected use. 
           [0013]      FIG. 3  is a sample report showing actual usage of software features by department. 
           [0014]      FIG. 4  is a sample report showing software feature use by country. 
           [0015]      FIG. 5  is a flow chart illustrating a method for driving software changes based on usage patterns gathered from users of previous releases in accordance with an embodiment of inventive arrangements disclosed herein. 
       
    
    
     DETAILED DESCRIPTION OF THE INVENTION 
       [0016]      FIG. 1  is a schematic diagram illustrating a system  100  in which software is developed as part of an end-to-end iterative solution in which software changes are driven by actual software use. Effectively, system  100  integrates a novel “sense and respond” capability to the software design process, where information concerning feature-by-feature use of a deployed software product is used for developing new product versions. Thus, production usage feedback is integrated into the software development cycle to aid in creating more successful software revisions that can be successfully adopted and effectively used by end users. 
         [0017]    System  100  shows a number of distinct software design phases, which include a deployment phase  105 , a usage information gathering phase  110 , an analysis phase  120  and  130 , a product design phase  140 , and a product development phase  150 . Each phase can include generated documents useful in guiding the software development process. Software revisions, enhancements, and new features can be driven by usage data obtained from users  112  of previous versions of the software product. A software revision can include the addition of new features, program error fixes, graphical user interface (GUI) usability improvements and the like. 
         [0018]    Initially, a software product  105  can be deployed in a manner in which usage of the product can be monitored. In one embodiment, usage monitoring code  153  can be directly inserted in the software product  105 . In another embodiment, an executing program can be distinctly implemented from a usage monitoring component. Regardless, usage of deployed software  105  can be recorded, as shown by phase  110 . Each software product can be used by multiple users  112 . In one embodiment, the usage data  116  can detail many user  112  specific attributes, which can be used to customize usage reports  124 . User  112  specific attributes can include, but are not limited to, a user&#39;s proficiency level, organization, role in an organization, authority level within the organization, physical location, and the like. 
         [0019]    In one embodiment, a user identifier can initially be included in a locally generated usage log. Personnel and other data stores can be accessed to determine user specific attributes for the user by querying these databases using the user identifier as a unique key. When privacy, confidentiality, and/or security are a concern, usage data  116  can be sanitized before being sent to a remote data repository. Sanitizing data is a process through which personal identifying elements are removed to produce accurate, but impersonal usage records. The user  112  specific usage records can be important to track whether different types of users  112  are utilizing software features than those whom the software design team  143  or other feature defining agents ( 131 - 133 ) envisioned. 
         [0020]    The usage data  116  can also include information concerning the machines  114  upon which the deployed software product  105  executes. Machine specific data can include available hardware resources, operating system, other software applications executing on the machines, response time, etc. Hardware specific information relating to the computing environment  114  can help designers determine whether certain software features of a product  105  are more successful on one platform compared to another, whether a specific feature is used more often when response time is over a particular threshold, whether some features that are otherwise popular are ignored when competing software is present on a machine upon which the product  105  executes, and the like. 
         [0021]    In general, the usage data  116  will include an interaction log that includes for each interaction, a timestamp, a unique user identifier, and a unique application feature used. The timestamp can be used to determine a duration of feature usage and an order of usage among different features. The usage data  116  can be used, for example, to record an order in which different features are executed relative to each other. These feature usage sequences can be significant when determining usage patterns which can impact future designs of the product. For example, if two current features require multiple interface steps to utilize, yet which are still used very often in sequence, then future design teams  143  can decide to decrease the number of steps a user must perform to use the features in sequence. 
         [0022]    An analysis phase can include a product analysis phase  130  and a usage analysis phase  120 . In the product analysis phase  130  a set of product goals  134  can be established by managers  132 , marketing personnel  133 , and technical consultants  131 . These goals can indicate which markets a new software version is to attempt to penetrate, usage goals for new features, and the like. 
         [0023]    The usage analysis phase  120  can utilize aggregated usage data  116  obtained in the information gathering phase  110 . The aggregated usage data  116  can be data-mined  121  or can be interactively queried  122  to produce usage reports  124 . Further, expected usage reports  123 , developed from past development cycle product goals  134  can be compared against the usage data  116  to produce gap reports  125 . Gap reports  125  express deltas between expected feature usage and actual feature usages by users  112  in a production environment. 
         [0024]    The usage reports  124 , gap reports  125 , expected usage reports  123 , and other reports  136  (e.g., user survey reports, usability testing reports, etc.) can be examined during the requirements development process  141  by experts to generate a set of product requirements  142 . These product requirements  142  can be optionally refined by a software design team  143  until a set of product design documents  144  are produced. These documents  144  can be conveyed to a software development team  151 , which uses them to produce a revised software product  152  in a product development phase  150 . In one embodiment, the revised product  152  can include usage monitoring code  153 . The code  153  can also be a separate application bundled with the product  152 , which is to be executed when the revised software product  152  is deployed ( 105 ) into a runtime environment ( 110 ). 
         [0025]      FIG. 2  is a sample report  200  showing actual usage of a Top N number of features verses expected use. The report  200  can be generated in the context of system  100  and represents one contemplated variant of a gap report  125 . 
         [0026]    Report  200  shows a bar chart of actual verses expected usages across ten features, F 1 -F 10 , in order of decreasing actual usages. As shown, Feature  5  (e.g., F 5 ) received approximately one hundred and ninety seven usages, while a number of expected usages was one hundred. Thus, report  200  indicates that Feature  5  was successfully implemented in a software product and was well received by users. In contrast, the number of actual usages for Feature  2  was approximately seventy nine while the number of expected usages was approximately one hundred and fifty. The shortfall of actual usages against expected usages for Feature  2  can indicate that users may not have been aware of an existence of Feature  2 , that users may not have liked the implementation of Feature  2 , that users may not desire functionality of Feature  2  as much as believed, and the like. Analysts can combine results shown in report  200  with other feedback artifacts, such as user survey results, to interpret a meaning of the report  200 . 
         [0027]      FIG. 3  is a sample report  300  showing actual usage of software features by department. The report  300  can be generated in the context of system  100  and represents one contemplated variant of a usage report  124 . 
         [0028]    Report  300  shows the number of times that four different features, Features one through four, are used by five different departments, Departments A-E. For example, the report  300  shows that Feature  1  was used six times by Department A, six times by Department B, Four times by Department C, six times by Department D, and four times by Department E. 
         [0029]    It should be appreciated that different departments can have different associated areas of responsibility and reports like report  300  can help software designers target different functional markets. Report  300  can also help software designers bundle and price different subsets of features of a single software product in a manner designed to maximize profits. For example, a feature report  300  can show that one feature is highly used by enterprise-level users, but is rarely used by others, which could indicate that the feature should be bundled only with an enterprise product. 
         [0030]      FIG. 4  is a sample report  400  showing feature use by country. The report  400  can be generated in the context of system  100  and represents one contemplated variant of a usage report  124 . 
         [0031]    Report  400  shows a usage of each of six features, F 1 -F 6 , as a percentage of total usage by country and month. For example as shown, Country A in Month  1  had usage percentages of approximately six percent (of total usage percent) for Feature  1 , nineteen percent for Feature  2 , twenty one percent for Feature  3 , nine percent for Feature  4 , thirty two percent for Feature  5 , and thirteen percent for Feature  6 . 
         [0032]    The report  400  is one report that a reporting interface  410  is able to dynamically generate. Similar feature usage reports illustrating usage by organization, by role, and the like can be presented by changing a parameter of interface selector  420 . 
         [0033]    Reports  200 ,  300 , and  400  are for illustrative purposes only and are not to be construed to limit the invention in any way. That is, report  200 ,  300 ,  400  or interface arrangements expressed in  FIGS. 2-4  are not intended to exhaustively illustrate contemplated arrangements, which will naturally vary based upon implementation specifics for which the solution is used. 
         [0034]      FIG. 5  is a flow chart illustrating a method  500  for driving software changes based on usage patterns gathered from users of previous releases in accordance with an embodiment of inventive arrangements disclosed herein. Method  500  can be performed in the context of system  100 . Method  500  illustrates a process of utilizing automatically gathered usage data to generate reports useful in developing software products consistent with a user centric focus. 
         [0035]    In step  505 , a software product can be deployed that has product usages recorded by a usage monitoring component. The monitoring component can be internally coded or can be an external software component which can optionally be bundled with the software when it is deployed. As the product is used, usage monitoring capabilities can convey usage information to a processing engine, as shown in step  510 . In step  515 , the processing engine can process usage metrics to generate sanitized usage data. Sanitized data can include a data set wherein specific personally identifiable information is removed. The removal of this information can satisfy privacy requirements necessary in keeping a data set untainted. In step  520 , an engine can data mine sanitized usage data to generate reports indicating usage patterns. 
         [0036]    In determining step  530 , if previous expected usages exist then the method can proceed to step  535 . Otherwise, the method can proceed to step  540 . In step  535 , expected usages can be compared against actual usages to generate one or more gap reports. Usage reports, gap reports, and expected usage reports can be used to generate a new product requirement document, as shown in step  540 . In step  545 , a product requirement document can be converted into new features and software development artifacts that include the new features. In step  550 , features can be implemented and the development artifacts can be used to create a revision version of the product. 
         [0037]    The present invention may be realized in hardware, software, or a combination of hardware and software. The present invention may be realized in a centralized fashion in one computer system or in a distributed fashion where different elements are spread across several interconnected computer systems. Any kind of computer system or other apparatus adapted for carrying out the methods described herein is suited. A typical combination of hardware and software may be a general purpose computer system with a computer program that, when being loaded and executed, controls the computer system such that it carries out the methods described herein. 
         [0038]    The present invention also may be embedded in a computer program product, which comprises all the features enabling the implementation of the methods described herein, and which when loaded in a computer system is able to carry out these methods. Computer program in the present context means any expression, in any language, code or notation, of a set of instructions intended to cause a system having an information processing capability to perform a particular function either directly or after either or both of the following: a) conversion to another language, code or notation; b) reproduction in a different material form. 
         [0039]    This invention may be embodied in other forms without departing from the spirit or essential attributes thereof. Accordingly, reference should be made to the following claims, rather than to the foregoing specification, as indicating the scope of the invention.