General Questions for Software or IT Projects

All SR&ED claims must demonstrate Technological Advancement together with Technological Uncertainty. While the Advance is usually easy to show for most software projects, demonstrating Uncertainty is much more difficult.

Complexity by itself is not an indicator of uncertainty (e.g., "it took a really long time, cost a lot of money and used many programmers to get our system to work…" — unfortunately, that argument does not satisfy the criteria).

Also, software systems for internal use (e.g., accounting, drafting, etc.) are extremely difficult to defend, unless the company is in the business of selling software or software services, and this is a key element of those products/services.

To help assess the Uncertainty of your project, please answer the following questions:

1. What general category (or combination of categories) best describes the activity?

  1. Stand-alone software application for a single computer
  2. Software for a network with both client-side (desktop) and server-side (server) development
  3. Web-based applications (which may include elements of "b")
  4. Software and hardware components, forming an architecture of different modules that had to communicate with one another
  5. Embedded computing (low-level firmware in a customized computing platform, e.g., gas pump, cash register, etc.)
  6. A completely new theoretical algorithm (e.g., a new nonlinear filter for HDTV, a stock-market simulator based on neural nets, etc.)
  7. None of the above

2. In attempting the activity, did you have to overcome any of the following types of constraints?

  1. Limited Footprint: Limited memory or CPU cache, requiring a constrained "footprint" for the code
  2. Limited Computing Resources: Had to make the code run using a low-powered/low-cost CPU or other rudimentary/outdated/cheap components
  3. Limited Physical Size ("Form Factor")
  4. Instability: The system crashed very frequently when running the code
  5. Response Time: End-to-end response time had to meet a certain target
  6. Throughput: Certain number of items had to be processed in a given time
  7. Concurrency: Works for 10 users, but had to work for 10,000 users (see "h")
  8. Scalability: Network failed at 20 messages/second; needed to support 2000/sec
  9. Reliability: MTBF had to be 1 year, but only achieve 1 day initially
  10. Compatibility with Legacy Software or Hardware
  11. System-Level Uncertainty: While each module (software or h/w) might be off-the-shelf, you may have combined them in a novel way the created problems with interconnectivity/protocol incompatibility/response time/any of the above.

3. Did you do any experimentation of the following sort?

  1. Stand-alone testing of prototype software modules, before they were integrated into the final system
  2. Testing on one platform (e.g., a simulation on a PC) before porting it over to the final target platform (e.g., PowerPC motherboard)
  3. Network mock-ups/ "stress tests" , e.g., needed to simulate the stress on system caused by 1,000 concurrent users; had to do this in lab with only 10 computers; devised novel testing methodology
  4. Field trials or beta tests, in which preliminary version of the code/system are deployed to test sites and tested under "real world" conditions; feedback collected from these trials often leads to changes in code/system

4. To do "3," did you develop any novel testing software tools/utilities/code/mock-ups/test beds?

5. If the project involved system integration, did you encounter problems related to any of the following?

  1. resolving uncertainties related to integrating components, including standard off-the-shelf modules

  2. evaluating alternative approaches to integration

  3. overcoming problems in getting new-to-new/new-to-old/old-to-old integration to work

  4. porting from one environment to another (e.g., Windows to Linux)

  5. integrating components that have not been designed to function together

  6. overcoming sensitivities to combining different release versions or operating systems

  7. solving problems related to old or legacy components (e.g., the protocols for the 20-year-old minicomputer were no longer supported or were no longer documented, etc.)

  8. getting around unexpected or undocumented behavior in a component (e.g., the specs claimed the module would do "this", but when we tried, we discovered it actually did "that")

  9. working around defects (known or undocumented) in a component, including 3rd party off-the-shelf components

  10. experiments to fill in incomplete information/documentation about a component

  11. unexpected/ inconsistent behavior between components (unexpected interactions)

6. Did the creation of a new user interface pose any unusual technical or human-factors challenges (e.g., wanted to create GUI that could be intuitive enough for child to use)? Did you measure the effectiveness of the new GUI in a systematic way (e.g., focus groups, human-factors analysis at a university, etc.)

7. Did you have to perform a lot of analysis, simulation, modeling or prototyping to get the design working?