In software development communities made up of large numbers of software developers, it is frequently difficult to communicate relevant architectural decisions to developers at times when such information is needed. Specifically, when a developer is ready to develop or significantly modify a program code component, he or she needs immediate assistance in making myriad design decisions according to standards established for the project. Such assistance must either be sought by searching through a potentially large, unwieldy, and potentially out-of-date body of project documents, or from team leadership, who can be bottlenecks to getting an answer quickly. Existing systems for code management in the development process have not addressed this problem adequately.
A common example is the developer faced with choosing where to store persistent settings for “points of variability” (“POV data”), such as configuration values, application assembly values, and the like, for a component s/he is developing. Guidance on where and how to store POV data (and the “where-and-how” of other project standards) can be difficult to find, and when the system under development is relatively complex, there are often many different places to store such POV data. Although the design and development process gradually reveals what the POV for a component should be, making the right decision about where to store POV data is not always obvious.
Several undesirable consequences may result from this situation. First, different developers may each independently make their own determinations as to where POV data should be stored. This likely leads to a proliferation of disparate, disconnected data stores (e.g., separate text files, relational data stores, etc.) across the system. Second, developers may choose to use existing data stores that have inappropriate characteristics for the specific data to be stored. For example, a poorly chosen store might not be available to the component in certain use cases, or may not be translatable to all supported languages, etc. Developers could spend large amounts of development time learning the characteristics of all data stores just so they can make an informed decision about where to store the POV data for the components they develop.
None of these consequences are desirable, and each may result in bad design decisions that must be fixed and re-written, and, in the case where the product has already been shipped and installed in live production, migrated from one POV data store to another as storage decisions are re-made in newer versions of the product.
For the above reasons and others, it would be desirable to have a new system for software system development that provides a convenient way for developers to access “development guide” information reflecting architectural decisions about a system under development in a just-in-time fashion—that is, when they need such information to make specific design decisions about their component. Such a system would be applicable to providing convenient, clear, on-demand guidance in determining storage locations for storing POV data, and to making other component design decisions not related to POV data value storage.
USPTO Backgrounds
USPTO Backgrounds