Ten Criteria for Selecting the Right Component

Ten Criteria for Selecting the Right Component

In last month's article I wrote about the importance of proper planning when building with third party code. Today, I am introducing a methodology for selecting the third party component that best meets the needs of your project and your development team.

The first step is to identify the criteria that you will use to evaluate potential third party software solutions. You will find that the set of criteria and the weight of each may vary from project to project. Evaluation criteria are dependent upon three factors; 1) the primary goals of your project (i.e., schedule, functionality, etc...); 2) the unique skills and level of domain knowledge within the development team and 3) the requirement set (e.g., flexibility, customizability, granularity of presentation, etc...)

To select relevant criteria, think in terms of identifying key attributes or descriptive elements that best represent the "perfect" component. To help, I've included below ten general examples of criteria. There's a good chance that your specific criteria would be different, based upon the three factors described above. Whatever criteria you decide upon, it is important that you are consistent in your approach and that you use the criteria set as the core guide for reviewing, analyzing and selecting a third party component.

In the final article of this series, I will use the criteria below to introduce you to an easy to use methodology for managing the results of your research. Using this methodology you will be confident that you will be selecting the "right" component for the job.

Ten Basic Criteria to be used in Selecting the Right Component

1. Ease of use - How productive, right out of the box, does it make the engineer?
2. Ease of customization - How customizable is the component's functionality?
3. Performance - If performance is critical to the requirement and the user experience, time should be included in the schedule to build a prototype and test.
4. Documentation - How much support does it provide and how comprehensive is it?
5. Sample code and demo applications - How many different samples and demos are provided with the component?
6. Granularity - Does the component provide the level or granularity of detail that your end-users expect?
7. Evaluations (free trials) - Does the evaluation license provide sufficient time and functionality to test the component meaningfully?
8. Technical support - Does the vendor provide timely, useful support?
9. Future growth - Is the component's functionally rich enough to accommodate an application's future requirements and growth?
10. Access to source code - May or may not be important.

By David E. Quigley
Executive Director
Component Vendor Consortium