Skip to main content
SpringerLink
Log in

MiHOS: an approach to support handling the mismatches between system requirements and COTS products

  • Original Research
  • Published:
Requirements Engineering Aims and scope Submit manuscript

Abstract

In the process of selecting Commercial Off-The-Shelf (COTS) products, it is inevitable to encounter mismatches between system requirements and COTS products. These mismatches occur as a result of an excess or shortage of the COTS attributes. This paper proposes a decision support approach, called MiHOS (Mismatch Handling for COTS Selection), that aims at addressing COTS mismatches during and after the selection process. MiHOS can be integrated with existing COTS selection methods at two points: (1) For evaluating COTS candidates: MiHOS estimates the anticipated fitness of the candidates if their mismatches are resolved. This helps to base our COTS selection decisions on the fitness that the candidates will eventually have if selected. (2) Mismatch resolution after selecting a COTS product: MiHOS suggests alternative plans for resolving the most appropriate mismatches using suitable actions, such that the most important risk, technical, and resource constraints are met. A case-study is used to illustrate MiHOS and to discuss its added value.

This is a preview of subscription content, log in via an institution to check access.

Access this article

Log in via an institution

Price excludes VAT (USA)
Tax calculation will be finalised during checkout.

Instant access to the full article PDF.

Institutional subscriptions

Fig. 1
Fig. 2
Fig. 3
Fig. 4
Fig. 5
Fig. 6
Fig. 7

Similar content being viewed by others

Notes

  1. Some efforts were made to support the alignment of COTS functionality and customer requirements in [11, 12] which focus on COTS products named ERP (Enterprise Resource Planning) systems.

  2. The term “COTS attributes” is used to refer to COTS functionalities and qualifications. These attributes are defined based on COTS vendors’ documentations and based on our understanding for the domain.

  3. More details on ML estimation are documented in a technical report that is available upon request.

  4. Full details of the case study are available upon request.

  5. In most cases, the differences between the anticipated fitness in these plans did not exceed ±1%.

  6. MiHOS-SA is described in a technical report that is available on request.

References

  1. Morisio M, Seaman CB, Parra AT, Basilli VR, Kraft SE, Condon SE (2000) Investigating and improving a COTS-based software development process. In: ICSE’00, Limmerick, Ireland, pp 32–41

  2. CeBASE: center for empirically based software engineering, at http://www.cebase.org

  3. Torchiano M, Morisio M (2004) Overlooked aspects of COTS-based development. IEEE Softw 21(2):88–93

    Article  Google Scholar 

  4. Boehm B, Abts C (1999) COTS integration: plug and pray? Computer 32(1):135–138

    Article  Google Scholar 

  5. Alves C (2003) COTS-based requirements engineering. In: Component-based software quality—methods and techniques, vol 2693. Springer, Heidelberg, pp 21–39

  6. Ruhe G (2003) Intelligent support for selection of COTS products, Web, Web-services, and database systems, lecture notes in computer science, vol 2593. Springer, Heidelberg, pp 34–45

  7. Kontio J (1995) OTSO: a systematic process for reusable software component selection. University of Maryland, Maryland, CS-TR-3478, Dec 1995

  8. Lozano-Tello A, Gomez-Pérez A (2002) BAREMO: how to choose the appropriate software component using the analytic hierarchy process. In: Proceedings of the 14th international conference on software engineering and knowledge engineering, ACM, Ischia, pp 781–788

  9. Ncube C, Maiden N (1999) Guiding parallel requirements acquisition and COTS software selection. In: IEEE international symposium on requirements engineering (RE’99), University of Limerick, Ireland, pp 133–140

  10. Ochs M, Pfahl D, Chrobok-Diening G, Nothhelfer-Kolb B (2000) A COTS acquisition process: definition and application experience. In: ESCOM-SCOPE 2000, Munich, Germany

  11. Rolland C, Prakash N (2001) Matching ERP system functionality to customer requirements. In: The fifth IEEE international symposium on requirements engineering, IEEE Computer Society, Toronto

  12. Zoukar I, Salinesi C (2004) Matching ERP functionalities with the logistic requirements of French railways: a similarity approach. In: The sixth international conference on enterprise information systems (ICEIS’04), Universidade Portucalense, Port0-Portugal, pp 444–450

  13. Carney D (1998) COTS evaluation in the real world. SEI interactive, Carnegie Mellon University, December

  14. Carney D, Hissam SA, Plakosh D (2000) Complex COTS-based software systems: practical steps for their maintenance. J Softw Maint 12(6):357–376

    Article  Google Scholar 

  15. Vigder MR, Gentleman WM, Dean J (1996) COTS software integration: state of the art. National Research Council Canada (NRC), 39198, January 1996

  16. Ruhe G, Ngo-The A (2004) Hybrid intelligence in software release planning. Int J Hybrid Intell Syst 1(2):99–110

    Google Scholar 

  17. Maiden NA, Ncube C (1998) Acquiring COTS software selection requirements. IEEE Softw 15(2):46–56

    Article  Google Scholar 

  18. Franch X, Carvallo JP (2003) Using quality models in software package selection. IEEE Softw 20(1):34–41

    Article  Google Scholar 

  19. Lamsweerde AV (2001) Goal-oriented requirements engineering: a guided tour. In: Fifth IEEE international symposium on requirements engineering, pp 249–263

  20. Alves C, Finkelstein A (2003) Investigating conflicts in COTS decision-making. Int J Softw Eng Knowl Eng 13(5):473–493

    Article  Google Scholar 

  21. Alves C, Franch X, Carvallo JP, Finkelstein A (2005) Using goals and quality models to support the matching analysis during COTS selection. In: The fourth international conference on COTS based software systems (ICCBSS’05), Bilbao, Spain, pp 146–156

  22. Grau G, Carvallo JP, Franch X, Quer C (2004) DesCOTS: a software system for selecting COTS components. In: The 30th EUROMICRO conference, Rennes, France, pp 118–126

  23. I*-homepage: http://www.cs.toronto.edu/km/istar

  24. ISO/IEC1926–1, Software engineering—product quality model—Part 1: quality model, International Organization for Standardization, Geneve, Switzerland

  25. Mohamed A, Ruhe G, Eberlein A (2006) A basis for mismatch handling during OTS acquisition. SEDS Lab, UofC, Calgary, TR, 056/2006, July 2006, http://www.enel.ucalgary.ca/∼asamoham/SEDS/TR056-2006-Short.pdf

  26. Carney D (1999) Requirements and COTS-based systems: a thorny question indeed. In: SEI interactive, Carnegie Mellon University, June 1999

  27. Brownsword L, Carney D, Oberndorf T (1998) The opportunities and complexities of applying commercial off-the-shelf components. CrossTalk 11(4):25–30

    Google Scholar 

  28. LINDO_Systems-homepage: http://www.lindo.com

  29. Li J, Ruhe G, Al-Emran A, Richter M (2006) A flexible method for effort estimation by analogy. Empir Softw Eng. (doi: 10.1007/s10664-006-7552-4)

  30. Humphrey WS (1989) Managing the software process, 1st edn. Addison-Wesley, Reading

  31. Ruhe G, Saliu MO (2005) The art and science of software release planning. IEEE Softw 22(6):47–53

    Article  Google Scholar 

  32. Wolsey LA, Nemhauser GL (1998) Integer and combinatorial optimization. Wiley, New York

    Google Scholar 

  33. Comella-Dorda S, Dean JC, Lewis G, Morris E, Oberndorf P, Harper E, A (2004) Process for COTS software product evaluation. Carnegie Mellon University, Software Engineering Institute, CMU/SEI-2003-TR-017, July 2004, http://www.springerlink.com/index/MAFK2LV46922UW45

  34. Saaty TL (1990) The analytic hierarchy process. McGraw-Hill, New York

    Google Scholar 

  35. Du G, McElroy J, Ruhe G (2006) Ad hoc versus systematic planning of software releases—a three-staged experiment. In: Seventh international conference on product focused software process improvement (PROFES06), Amsterdam

Download references

Acknowledgments

We appreciate the support of the Natural Sciences and Engineering Council of Canada (NSERC) and of the Alberta Informatics Circle of Research Excellence (iCORE) to conduct this research.

Author information

Authors and Affiliations

  1. University of Calgary, 2500 University Drive, NW, Calgary, AB, T2N1N4, Canada

    Abdallah Mohamed & Guenther Ruhe

  2. American University of Sharjah, Sharjah, P.O. Box 26666, UAE

    Armin Eberlein

Authors
  1. Abdallah Mohamed
    View author publications

    You can also search for this author in PubMed Google Scholar

  2. Guenther Ruhe
    View author publications

    You can also search for this author in PubMed Google Scholar

  3. Armin Eberlein
    View author publications

    You can also search for this author in PubMed Google Scholar

Corresponding author

Correspondence to Abdallah Mohamed.

Appendices

Appendix 1: Diversification strategy used in MiHOS

Searching for a subset having the maximum diversification among a set of solutions is a challenging problem [16]. To illustrate this, suppose we have a COTS product with 70 mismatches m i each of which can be solved by using one of two resolution actions a i,1and a i,2. The solution space for such problem would contain 370 possible solutions; this is because each mismatch m i has three handling actions: solve using a i,1, solve using a i,2, and tolerate m i . If only 0.0001% of these solutions are qualified, then the number of qualified solutions for this problem equals 0.0001% × 370 ≈ 2.58 × 1026. Now, it is required to search this subset for the most diversified solutions. Assuming that we need a subset of five diversified solutions, we would have 2.58 × 1026!/[(2.58 × 1026−5)! × 5!] ≈ 9.53 × 10129 alternative subsets.

A strategy that simplifies the problem by searching only a subset of the feasible space for the most diversified solutions was introduced in [16]. However, as stated by the authors, this strategy does not guarantee the identification of the solutions with the maximum diversification among the whole feasible space.

In our paper, we propose another strategy. Suppose that we want to obtain a subset SOL that contains five solutions having the maximum diversification among the set of all qualified solutions. And suppose that if we have two solution plans X i and X j ∈SOL, then we can measure the level of diversification by comparing the structure of X i and X j and simply counting the number of differences ℵ i,j between them. Based on this, we can identify the subset SOL by applying the following procedure (see Fig. 8):

  1. 1.

    Initialize the procedure:

    1. 1.1.

      Formulate the original problem P 0 as described in Sect. 3 and get the optimum solution X 0 by solving P 0.

    2. 1.2.

      Set SOL = {X 0}.

    3. 1.3.

      Set η = 1 (where η is required degree of diversification. η represented by the number of differences that are counted between the different solution plans).

  2. 2.

    Get a qualified solution X 1 which has η differences with X 0. This is done as follows:

    1. 2.1.

      Formulate a new problem P 1 which is the same as P 0 in addition to a new constraint ℵ1,0 = η (see Fig. 8).

    2. 2.2.

      Get the solution X 1 by solving P 1.

    3. 2.3.

      Add X 1 to the solution subset SOL; i.e., change SOL = {X 0, X 1}.

  3. 3.

    Repeat Step 2 to get the solution X 2, and add X 2 to SOL subset. Note that the new formulated problem P 2 has the same formulation as P 0 but has additionally two more constraints, ℵ2,0 = η and ℵ2,1 = η.

  4. 4.

    Similarly to Step 3, repeat Step 2 to get X 3and X 4, while adding more constraints that guarantees a number of differences equal to η among all solutions (see Fig. 8).

  5. 5.

    If the optimization engine, (i.e., LINDO [28]) has successfully found all diversified solutions X 0–X 4, then increment η by one.

  6. 6.

    Repeat Steps 2–5 (while η is being incremented) until the optimization engine fails to find a feasible solution to at least one of the new formulated problems (this often happens when the optimization engine fails to solve P 4).

  7. 7.

    The required subset SOL would then include the diversified solutions identified in the most recent successful run of the optimization engine.

The above procedure also cannot guarantee identifying the set of qualified solutions with maximum diversification. This is because it assumes equal distances between the diversified solutions, while in reality, the distances between the diversified solutions might vary. In addition, adding constraints such as ℵ1,0 = η makes the problem non-linear which makes it harder to solve.

Fig. 8
figure 8

Procedure of finding a subset of qualified solutions with maximum diversification

Full size image

Appendix 2: Mismatches between COTS4 and technical goals

Table 4 A list of COTS4 mismatches
Full size table

Rights and permissions

Reprints and permissions

About this article

Cite this article

Mohamed, A., Ruhe, G. & Eberlein, A. MiHOS: an approach to support handling the mismatches between system requirements and COTS products. Requirements Eng 12, 127–143 (2007). https://doi.org/10.1007/s00766-007-0041-5

Download citation

  • Received:

  • Accepted:

  • Published:

  • Issue Date:

  • DOI: https://doi.org/10.1007/s00766-007-0041-5

Keywords

Search

Navigation