Questions about IRS requirements?

Software Development Risk Categories

CONTENTS:
High Risk Categories of Software Development

• Maintenance of existing software applications/products
• Software application configuration
• Reverse engineering
• Performing studies, or similar activities, to select vendor products
• Detecting flaws and bugs in software
• Modifying an existing software business component to make use of new or existing standards or devices
• Developing a business component that is substantially similar in technology, functionality and features to the capabilities already in existence at other companies
• Upgrading to newer versions of hardware or software, or installing vendor fix releases
• Re-hosting or porting an application to a new hardware or software platform
• Writing hardware device drivers to support new hardware
• Data quality, data cleansing, and data consistency activities
• Bundling existing individual software products into product “suites”
• Expanding product lines by purchasing other products
• Interfaces
• Y2K Program Changes
• Vendor Product Extensions
• Graphical User Interfaces

Moderate Risk Categories of Software

• Functional enhancements to existing software applications/products
• Software developed as an embedded application, such as in cell phones, automobiles, airplanes
• The development of software utility programs, such as debuggers, backup systems, performance analyzers, data recovery, etc.
• Changing from a product based on one technology to a product based on a different or newer technology
• The adaptation and commercialization of a technology developed by a consortium or an open software group

Low Risk Categories of Software

• The initial release of an application software product
• The development of system software, such as operating systems and compilers
• The development of specialized technologies, such as image processing, artificial intelligence, or speech recognition
• Software developed as part of a hardware product

There are many different categories of software development, such as, but not limited to, the initial development of software products and new product application areas, feature extensions and enhancements to existing products, combining existing products to create a new product or product suite, and creating new versions of existing products by removing features (e.g., to provide a more entry-level product).

The facts and circumstances of each case must be taken into account in making a determination as to whether or not a taxpayer’s activities constitute elements of a process of experimentation under the Code and the Treasury Regulations. The following list is intended to provide assistance in identifying categories of software development at a low risk, moderate risk, and high risk of not being qualified research under I.R.C. § 41(d).

High Risk Categories of Software Development – means that these activities usually fail to constitute qualified research under I.R.C. § 41(d).

• Maintenance of existing software applications/products.
Software applications generally last for years, if not decades. Thus, once a vendor releases a new product, subsequent minor releases (e.g., release 1.1, 1.2, 2.4, 3.2, etc.) usually involve corrective maintenance to debug, diagnose, and fix design, logic, and/or programming errors, adapt the product to externally imposed changes, such as regulatory matters or competitive developments, and perfect it to match features in competitive products. Critical fix or patch releases may occur more frequently, such as to fix software bugs or security issues that cannot wait for the next minor or major release of the software. Perfective enhancements include modifications and improvements to the software to extend the product’s useful life (e.g., improve the product’s ease of use, performance, responsiveness, space requirements, etc.). Corrective, adaptive, and perfective maintenance generally utilize the same existing architecture and technologies of the released product.[iv] Such maintenance efforts are needed to keep the product operational and competitive in the marketplace.

These maintenance activities typically involve analysis, debugging, reverse engineering, making program modifications, and testing of the modifications that were made. Such maintenance activities, in general, are not directed at resolving software development uncertainties through identifying and conducting a process designed to evaluate alternatives which fundamentally relies on the principles of computer science.

• Software application configuration.
Applications purchased from outside vendors frequently have to be configured to meet the specific needs and requirements of the taxpayer. For example, configuration activities may involve defining a chart of accounts, defining the number of users, setting access privileges to various functions or reports, etc. This process may involve selecting among vendor defined options, and/or modifying vendor specified default capabilities (e.g., which users can access the payroll report) using vendor provided software. Such configuration activities, in general, are not directed at resolving software development uncertainties through identifying and conducting a process designed to evaluate alternatives which fundamentally relies on the principles of computer science.

• Reverse engineering.
Reverse engineering activities typically consist of examining existing programs, databases, and files in order to figure out how an existing application really works. For example, if a new application was supposed to interface with an existing legacy application, then the software engineers might need to reverse engineer the data interface supported by the legacy application.

Reverse engineering is not qualified research under I.R.C. § 41(d). See Treas. Reg. § 1.41-4(c)(10), Example 8.

• Performing studies, or similar activities, to select vendor products.
For example, choosing between database management systems (like Oracle or DB2), choosing between computer manufacturers (e.g., H-P, IBM, or Dell), choosing between enterprise resource program suppliers (e.g., SAP, Oracle, or PeopleSoft), or choosing between web portal platforms (e.g., WebLogic or Web Sphere) are generally routine due diligence product selection studies.

Such studies are generally not directed at resolving software development uncertainties through identifying and conducting a process designed to evaluate alternatives which fundamentally relies on the principles of computer science. See Treas. Reg. § 1.41-4(c)(10), Example 9.

• Detecting flaws and bugs in software.
Encountering flaws and bugs in software, including vendor software, usually occurs during debugging and routine testing of the software. These debugging and testing activities are generally not directed at resolving software development uncertainties through identifying and conducting a process designed to evaluate alternatives, which fundamentally relies on the principles of computer science, but instead are activities directed toward the verification and validation that the software was programmed as intended and works correctly. See I.R.C. § 41(d)(4)(A); Treas. Reg. § 1.41-4(c)(2).

• Modifying an existing software business component to make use of new or existing standards or devices, or to be compliant (i.e., certified, validated, etc.) with another vendor’s product or platform.
Activities associated with modifying software to use new devices or standards generally involve an examination of the existing software to locate where these changes need to be inserted into the software. In order to locate where these changes should be inserted, activities such as reviewing program code and/or documentation, reverse engineering, debugging, and routine testing are typically performed. In order to be compliant with another vendor’s product or platform, the activities usually involve running a target vendor’s validation test suite, examining the results, and then, through a process of debugging and reverse engineering, resolving any problems that the certification test suite encountered.

These activities are generally not directed at resolving software development uncertainties through identifying and conducting a process designed to evaluate alternatives, which fundamentally relies on the principles of computer science, but are instead directed at verifying that the software works according to the standards or devices, or successfully passes another vendor’s certification tests.

• Developing a business component that is substantially similar in technology, functionality and features to the capabilities already in existence at other companies.
These activities usually involve an analysis of the products already in the marketplace in order to determine, for example, functions and features, what the user interface screens look like, and what must be done in order to develop a similar business component. In addition, since these other competitive products are already on the market, the technologies, the training to learn these technologies, and the available software engineering skills to develop a similar business component, are generally available in the marketplace.

The development of these business components generally does not involve activities directed at resolving software development uncertainties through identifying and conducting a process designed to evaluate alternatives which fundamentally relies on the principles of computer science.
• Upgrading to newer versions of hardware or software, or installing vendor fix releases.
These activities involve installing new releases of software, or installing new hardware, each of which typically involves following the vendor’s installation instructions. There are occasions in which an installation or upgrade fails. However, the resultant activities would then generally be directed at debugging the installation and/or talking with the vendor to determine what went wrong, but not at resolving software development uncertainties through identifying and conducting a process designed to evaluate alternatives which fundamentally relies on the principles of computer science.
• Re-hosting or porting an application to a new hardware (e.g., from mainframe to PC) or software platform (e.g., Windows to UNIX), or rewriting an existing application in a new language (e.g., rewriting a COBOL mainframe application in C++).
Re-hosting or porting an application to a new hardware platform generally involves the adaptation of the existing software business component to the new hardware or software platform, not resolving software development uncertainties through identifying and conducting a process designed to evaluate alternatives which fundamentally rely on the principles of computer science. Note that such an adaptation of an existing business component to a new hardware platform is not qualified research under I.R.C. § 41(d).

Rewriting an application in a new language generally involves reverse engineering the existing code to determine all of the requirements and processing algorithms that the rewritten software must support, and possibly dividing the existing large components into smaller components. There is generally no new application architecture, and the original program code is typically converted into the new language constructs. There are generally no software development uncertainties, resolved through a process of experimentation, associated with breaking a large program into smaller components, or in converting program code written in one language into another language.
• Writing hardware device drivers to support new hardware (e.g., disks, scanners, printers, modems, etc.).
The vendors of new hardware devices generally provide documentation as to what the capabilities and functions of the devices are, as well as a description of the commands that must be programmed in order to make the devices work. For example, a hard disk vendor would provide the software commands to read data from and write data to a hard disk drive. The software activities are then generally directed at writing software to use these documented device interfaces, not at resolving software development uncertainties through identifying and conducting a process designed to evaluate alternatives which fundamentally relies on the principles of computer science.
• Data quality, data cleansing, and data consistency activities.
These activities include such activities as designing and implementing software to validate and/or clean data fields, and/or make the data fields consistent across databases and applications. For example, an address field could be defined differently in every database, or when transferring data between systems, such as between a mainframe and a UNIX server, the format of the data may need to be translated, such as from EBCDIC to ASCII. There is generally no software development uncertainty, resolved through a process of experimentation, with respect to reading data from a file or database, converting that data to a different format (e.g., mm/dd/yy converted to mm/dd/yyyy), or writing the newly formatted data into a file or database. The decisions related to what format to select for any given piece of data, such as a date or an address, are business uncertainties, not software development uncertainties.
• Bundling existing individual software products into product “suites” (e.g., combining existing word processor, spreadsheet, and slide presentation software applications into a single “suite”).
Software suites usually involve the development or improvement of a common user interface to allow users to invoke each of the existing individual applications in the bundled suite, or to select configuration or runtime options for the programs in the suite. The products themselves, including any configuration and runtime options, are generally not modified in this process.

In addition, the interfaces to the individual applications are not generally uncertain, as the creation or modification of a user interface to invoke a software application is based upon information available to the taxpayer. The activities associated with the bundling of software applications into a suite of products are not generally directed at resolving software development uncertainties through identifying and conducting a process designed to evaluate alternatives which fundamentally relies on the principles of computer science.
• Expanding product lines by purchasing other products.
Commercial software vendors may also purchase software products from other vendors, and then may need to develop software to migrate customers from one product to another in order to consolidate the vendor’s overall product offerings, and/or integrate the products so that they work properly together. For example, a database company could purchase another company which had financial software products, and then modify the financial software to work only with the acquiring company’s new database product.

Modifying a purchased software product to access a different database, for example, means that you have to review the product’s program code to find all of the database references, and then change each of them to reference the new database. These activities require reading the documentation for both products, perhaps reverse engineering the purchased product to extract more information about the data items, and then making the appropriate software modifications. Just as in Y2K work, these activities are directed at finding all of the location in the software than need to be modified, and are not generally directed at resolving software development uncertainties.

If the vendor decides to migrate existing customers off of the purchased products and onto the vendor’s current products, then the vendor must develop software to convert the customer’s current data into the vendor’s data structures. This involves understanding the purchased product’s data requirements, as well as an understanding of their own data requirements. Once these requirements are known, which may require reverse engineering activities, it is a straightforward process to write software to read the old data, convert that data into the new data formats, and then to write that data into new data structures (i.e., files or databases). There is generally no software development uncertainty associated with reading or writing data, or in converting data items from one format to another, that is resolved by identifying and conducting a process, designed to evaluate alternatives, which fundamentally relies on the principles of computer science.
• Interfaces.
There are many ways in which a software business component can interface with other software components and/or users. For example, one type of interface development includes designing and implementing electronic interfaces between software applications, wherein one software application can “talk” to another software application and exchange data, or execute a business transaction. A software business component might involve interfacing with one or more other software applications, whether internal (e.g., an inventory software application might “talk” to a warehouse software application), or external (e.g., a business-to-business software interaction) to the taxpayer.

A software business component might also interface with a user, such as via an Internet browser. For example, a taxpayer could have an application that runs on a PC, and then decide to add an Internet browser interface to essentially the same application (e.g., one could have a PC application to calculate your taxes and print your tax forms, or have an Internet browser interface to a similar application to do your taxes).

Interface software development activities involve defining the data and transaction requirements that must be supported on each end of the interface, which may also involve reverse engineering of the interfaces. These activities are generally directed at defining the requirements of the interface, and writing the software accordingly, but not at resolving software development uncertainties through identifying and conducting a process designed to evaluate alternatives which fundamentally relies on the principles of computer science.
• Y2K Program Changes.
Y2K activities typically involved the examination of application program code in order to identify when two-character fields were used to represent year (e.g., ‘89), and once identified, these date fields had to be modified to hold a four character year (e.g., 1989). Y2K activities also involved the modification of program code to correctly make date calculations when using this larger date field. Once all of these changes were made, extensive testing had to be done in order to ensure that the Y2K compliant software produced the same answers as the existing, non-Y2K compliant, application.

There is generally no software development uncertainty associated with reading existing program code to locate code and data that may need to be modified, or in testing an existing application to verify that it still works correctly. See Rev. Proc. 97- 50, 1997-2 C.B. 525.
• Vendor Product Extensions.
This software is typically written by customers to fill gaps in the functionality of a product. For example, one could develop software to perform some calculation not provided by a spreadsheet product, or develop software to customize the format of a report. In order to develop these product extensions, vendors typically provide welldefined interfaces (a/k/a user exits), and/or APIs (Application Programming Interfaces), to permit new code to interact with the vendor’s code. Herein, the vendor’s product is not modified, and the new user code must conform to the vendor’s defined interface or API.

These activities of determining which interface or API to use, and then implementing the modifications, are generally not directed at resolving software development uncertainties through identifying and conducting a process designed to evaluate alternatives which fundamentally relies on the principles of computer science.

• Graphical User Interfaces (“GUI”).
The design of the graphical user interface screens generally involves issues such as determining what data items and graphics should be displayed on each screen, and where on each screen each item should be displayed. These are business and/or project uncertainties. However, there is typically no software development uncertainty, resolved through a process of experimentation, with respect to the appropriate design of the graphical user interface, or in the capability or method of developing the actual graphical user interface screens.
[back to top]

Moderate Risk Categories of Software – means that these activities often fail to constitute qualified research under I.R.C. § 41(d).
• Functional enhancements to existing software applications/products.
Software applications tend to last for years, if not decades. Thus, once a vendor releases a new product, subsequent major releases (e.g., release 2.0, 3.0, “product name 2004”, “product name 2005”, etc.) of the software typically include new functional enhancements (i.e., product features or capabilities), within the same existing architecture and technologies, and built using the same tools, proven during the development of the original software application. However, particular software development uncertainties that need to be resolved through identifying and conducting a process designed to evaluate alternatives which fundamentally relies on the principles of computer science are more likely to arise if, for example, the underlying architecture or technologies also need to be modified.

Some major releases may contain features and functions that require software development activities which are generally not directed at resolving software development uncertainties through identifying and conducting a process designed to evaluate alternatives which fundamentally relies on the principles of computer science. For example, a new version of an income tax product may contain updated income tax tables and modified tax forms, or an anti-virus product may contain modified screens to permit a user to choose when to automatically run an anti-virus scan.

Alternatively, major releases may contain features and functions that involve software development activities that are directed at resolving software development uncertainties through a process of experimentation by identifying and conducting a process designed to evaluate alternatives which fundamentally relies on the principles of computer science. For example, a new version of an income tax product may involve the development or modification of data encryption algorithms to protect the privacy and integrity of the electronic submission of tax returns, or a new version of an anti-virus product may involve the development or modification of heuristic algorithms to detect new incoming computer viruses.
• Software developed as an embedded application, such as in cell phones, automobiles, airplanes.
Embedded software applications generally utilize the software already included in the system in order to execute the new application. In addition, embedded applications tend to be developed using existing architectures, languages, tools, and methodologies. Once developed, the application is then downloaded using established tools to the target environment, such as a cell phone.

For example, particular software development uncertainties, such as very small screen sizes, software that must be failsafe, or a requirement to develop a new communication protocol, may need to be resolved through identifying and conducting a process designed to evaluate alternatives which fundamentally relies on the principles of computer science.

Alternatively, embedded software to display information on a user’s screen, such as caller ID names and phone numbers displayed on a cell phone screen, or to produce a report, such as the time and speed a car was going when an accident occurred, generally do not involve activities which are directed at resolving software development uncertainties through identifying and conducting a process designed to evaluate alternatives which fundamentally relies on the principles of computer science.
• The development of software utility programs, such as debuggers, backup systems, performance analyzers, data recovery, etc.
Utility software applications generally utilize software interfaces, or application programming interfaces (APIs) that already exist in the system. Typical activities may involve understanding the capabilities of the underlying system, including the existing APIs, devices, file systems, and/or databases, that may be needed as part of the business component. For example, to develop a business component to backup data on a computer generally involves an understanding of the file system on the computer (i.e., how to find the location of a file on a hard disk, and how to retrieve the entire file, etc.), the devices to which the backup files will be written (e.g., hard disk, tape, floppy disk, CD, etc.), and the underlying application programming interfaces provided by the operating system (e.g., Microsoft Windows, IBM’s MVS, UNIX, etc.). Such software development does not generally involve activities which are directed at resolving software development uncertainties through identifying and conducting a process designed to evaluate alternatives which fundamentally relies on the principles of computer science.Alternatively, for example, a software utility program designed to recover data from a hard disk, even though the file was previously deleted and its disk space reused by other applications, may involve design uncertainties which can only be resolved through identifying and conducting a process designed to evaluate alternatives, which fundamentally relies on the principles of computer science.
• Changing from a product based on one technology to a product based on a different or newer technology (e.g., switching from a hierarchical database technology to a relational database technology).
The functions and features of the old technology and new technology products tend to be similar, if not identical. Activities generally involve a comparison of the features and requirements in the current system versus the capabilities provided by the newer technology. In addition, there is generally an analysis of the current design to understand how the existing system works, followed by the subsequent development of a design that incorporates the newer technology. For example, the activities related to extracting data from a hierarchical database, converting that data into a new format, and then loading that data into a relational database, generally do not involve software uncertainties which can only be resolved through identifying and conducting a process designed to evaluate alternatives, which fundamentally relies on the principles of computer science.

Alternatively, changing a technology upon which an existing product was originally based may involve changing the underlying architecture of the software in order to accommodate the new technology. For example, changing an application that had run on a mainframe, to an application that runs in a grid computing environment may involve software development uncertainties that need to be resolved through identifying and conducting a process designed to evaluate alternatives which fundamentally relies on the principles of computer science.
• The adaptation and commercialization of a technology developed by a consortium or an open software group.
A vendor may, for example, join a consortium to jointly define a software model for how to perform electronic transactions with the suppliers to that industry (e.g., business-to-business transactions). Each vendor in the consortium may then commercialize parts, or all, of the model. Such models defined by a consortium typically specify in detail the requirements of the model which the software must then satisfy. A vendor can then proceed to design, develop, and test the software which satisfies the model. While the models define the requirements, they usually, for example, do not define the underlying architecture of the software that must conform to the model, and thus there may be particular software development uncertainties which can only be resolved through identifying and conducting a process designed to evaluate alternatives which fundamentally relies on the principles of computer science.
[back to top]

Low Risk Categories of Software – means that these activities rarely fail to constitute qualified research under I.R.C. § 41(d).

• The initial release of an application software product may require new constructs, such as, for example, new architectures, new algorithms, or new database management techniques.
The design of these new constructs often requires a process of experimentation to resolve specific software development uncertainties through identifying and conducting a process designed to evaluate alternatives which fundamentally relies on the principles of computer science.

• The development of system software, such as operating systems and compilers, frequently entails the resolution of software development uncertainties related to, for example, process scheduling and memory management designs, and instruction execution optimization.
Such software development uncertainties are typically resolved through identifying and conducting a process designed to evaluate technical alternatives which fundamentally relies on the principles of computer science.

• The development of specialized technologies, such as image processing, artificial intelligence, or speech recognition, often requires a process of experimentation to resolve software development uncertainties through identifying and conducting a process designed to evaluate alternatives which fundamentally relies on the principles of computer science.

• Software developed as part of a hardware product wherein the software interacts directly with that hardware in order to make the hardware/software package function as a unit.
The activities involved in developing a hardware/software product generally include evaluating the designs and tradeoffs among the hardware and software components by running, for example, performance benchmarks on the combined product to measure operations per minute, graphical display times, or data throughput. The hardware and software designs will generally be modified together in order to develop the final hardware/software business component. This process of concomitantly modifying the hardware and the software in order to develop the hardware/software product frequently entails the identification and conducting of a process designed to evaluate alternatives which fundamentally relies on the principles of computer science.
[back to top]

—-footnotes—-
[iv] Section 3.1, Definitions, IEEE Standard for Software Maintenance, Software Engineering Standards Committee of the IEEE Computer Society, June 25, 1998, pages 3 & 4.