OASIS Development Policy

At Ingen Software, we often receive requests for new features, adjustments, and bug reports. In response, we regularly release updates implementing new features and fixing bugs. However, the time it takes for developments and features to be implemented depends on several factors. 

Development Type Prioritization

As new features, modifications, or bugs are sent to Ingen Software, they are categorized and reviewed by our team. To efficiently deliver the best possible software, we prioritize development internally to maximize our development efforts. 

Prioritization by Man Hours

It is common to estimate the amount of work required to develop software in "man hours." This is the number of hours required for a single developer to create or alter software to resolve a defect or implement a new feature.

There is no set guide to determine the amount of time required to implement a change. However, form only changes in OASIS typically takes 1-2 business days, if no changes are required to the OASIS system itself. Additionally, database changes are on an annual schedule, usually completed in February. these changes will likely be delayed until the February cycle.

Below are some examples of OASIS projects that have been completed recently and the number of hours required for development.

Adding "Transmit Date" to the Manufacturer Shipping Request Report

• Hours: 0.5
• Implementation Tasks: added the variable “TransmitDate” properly formatted to the report generator. The form was changed to include “Transmit Date” in the header of each PO.
• Unit Testing: the report was run against a regression database to determine how the report looked in the previous version. Then the new report generator was run against the same database to view the result.
• Defects Resolved: (all defects found in Unit Testing.) Date was not originally shown, but label was. The data tag in the XML did not match the data element created by OASIS. Changed OASIS to match the more natural tag of TransmitDate. Date was shown truncated. XML was altered to allow for enough space on the printed report for the date.

Allow the use of “Lamps” within “Kits” in projects and quotes.

• Hours: 16+ for coding. Planning, testing and feedback from users took about 30 days!
• Implementation Tasks: Rewrote the following code modules:
  • OASIS quote object (the kit and global total recalculate logic was very tricky!)
  • OASIS quote line object
  • OASIS quote print renderer
  • OASIS Order Create routines
  • OASIS Submittal creation routines, including the “roll up” features.
  • Various OASIS reports
• Additionally, a number of smaller routines were altered to account for the updates to the new OASIS quote and quote line objects.
• Implementation Strategy: The first try at implementation was thrown away as the goal was to simply apply the same lamp rules used with the “part” lines. The second concept was to rewrite the tests for “lamp” and “kit component” into a single test taking a Boolean argument as to whether the customer was including lamps or not. Once implemented, all the resulting “compile errors” were used to identify the modules requiring change. Each module was identified and altered independently.
• This method relies heavily on testing. A quote was configured to test the quote and each of the features identified as “changed”. A full regression is not possible (identifying the number of permutations would have taken weeks). However, the use of “educated testing” (based on code changes) and the use of existing user data simplified the testing while maintaining quality.
• Unit Testing: A regression database was used to compare the output (forms) and features (order creation, submittal creation) behaved as expected. Numerous iterations were performed between unit testing and implementation.

Conflicting Requirements

Ingen Software adheres to the philosophy that new ideas are always presenting themselves and we will implement these new ideas. However, some of the new ideas conflict with how OASIS currently operates. Additionally, some clients may disagree on how a feature is to be implemented. To resolve these conflicts, we take the time during the implementation process to ask the following questions:

• What impact will the software change have on the business processes for our existing customers?
• If customers disagree on how a feature is to be implemented then should we create a global preference to alter the behavior? The other option is to implement the feature as a custom extension to OASIS (the client will be charged for these changes).

In short, it takes time to resolve these issues. Additionally, conflicts are sometimes discovered after a new feature is released, forcing us to delay the final implementation while we create a global preference or work with the customer with the conflict to develop a work-around.

Conclusion

Software is an engineering science and an art, so development priorities depend on several factors. These priorities are determined by the type of development, the time it will take to complete a development, and any conflicting requirements.