Quality Assurance

Our commitment to quality

Exchange personnel are committed to providing our customers with the custom software solutions that meet or exceed their quality requirements. The quality requirements for a specific solution may vary from one customer to next; for this reason, we rate every asset, according to our published guidelines, during the appraisal process, so every Buyer can make an informed decision during the evaluation process.

Why isn't the source code certified by the software vendor?

There are three primary reasons why none of the assets sold on the exchange are vendor certified:

• Fit with our business model - Our business model is predicated upon the idea of having a very large repository of assets across various platforms, industries, functions and development type. Obtaining vendor certification for any or all of these assets would not only be impractical, it would also be too time consuming and difficult to justify.
• Cost - A key component of our value proposition to our Buyers is the low price of the assets. In order to obtain certification for a specific asset, the price of that asset would probably have to triple or quadruple in price. At that price point, the asset would have to be a 100% fit with the Buyer's requirements in order for them to justify the purchase, which is usually not the case.
• Benefit - There are some customers who will only use solutions that are vendor certified and, in many cases, the customer does not understand what is being certified. Is the vendor certifying the quality of the code, the performance of the code or the functionality? Is a certification the same thing as a recommendation on the part of the software vendor? The answer to all these questions is usually no. The same customers that will only use vendor-certified solutions are usually perfectly willing to have custom solutions developed, which have the least assurance of quality of any solution alternative. It is our belief that our internal ratings and the asset history (live in Seller system) provide a much greater level of assurance to our Buyers than a vendor's certification provides.

Assessment Process

Our objective is to accept only assets that are unique and attractive, technically and functionally, to our Buyers. We therefore carefully review each asset submitted to the exchange to ensure that we have a high degree of confidence in the demand for the asset in the market. During our appraisal process, an asset is graded on FIVE key dimensions:

• Uniqueness - Is the solution space of the custom code currently covered by any existing assets (in the same platform/system)? If it is, then what differentiates this custom application from the existing asset? Our objective is to limit the number of assets to the best and broadest assets available, and not have a lot of redundant assets.
• Documentation - How complete and well-written is the documentation accompanying the asset.
• Structure, Quality and Performance of Source Code - How well structured is the source code? Is the code tuned for performance? How difficult will it be to generalize the code?
• Functionally - Does the asset functionality enhance or extend the vendor's standard software? How complicated is the functionality to understand and use? Does the asset represent a comprehensive solution, or will a majority of Buyers need to further customize the asset?
• Support - How difficult will it be for a Buyer to support the asset once installed? How vulnerable is the asset source code to side effects of upgrades or vendor service packs?

Asset Quality Ratings

The overall rating is an average value calculated from the individual support, functionality and source code reviews that are carried out.

• Platinum - TBD
• Gold - TBD
• Silver - TBD
• Bronze - TBD
• Failed - If the asset fails on any of the five dimensions, then the asset is considered unsuitable for the exchange

Solution documentation

Accompanying every asset is a set of documentation that is commensurate with the price and complexity of the asset. The documentation provided with a report is much shorter and more concise than the documentation accompanying a stand-alone application. The documentation generally covers the following topics:

• Executive Summary
• End-User Training
• Technical Documentation
• Functional Documentation
• Unit Testing Plan
• Glossary of Terms

Back to Top