RES-861 Assignment: Theoretical Foundation of COTS Software Selection
VerifiedAdded on 2020/05/16
|6
|1282
|130
Report
AI Summary
This report delves into the theoretical foundation of selecting Commercial Off-The-Shelf (COTS) software, addressing the challenges organizations and individuals face during acquisition. The study focuses on developing a procedure to aid in COTS software selection, analyzing existing case studies to identify key factors. Important aspects to consider include the cost of ownership, vendor demonstration of product fit, and the product's ability to meet critical business needs. The report emphasizes the importance of a clear software roadmap, supplier compatibility, and reliable customer support. It examines factors such as vendor business maturity and the ability to meet timeframes, providing a comprehensive guide for informed COTS software selection. The research utilizes sources like Ayala et al. (2011), Grossniklaus et al. (2012), Nautiyal & Gupta (2013), Tarawneh et al. (2011), and Wnuk et al. (2015) to support its findings.

RUNNING HEAD: THEORETICAL FOUNDATION
1
Theoretical Foundation section of a research study
Name Singh
Institution Grand Canyon University
Course: RES-861
Date 1/31/2018
1
Theoretical Foundation section of a research study
Name Singh
Institution Grand Canyon University
Course: RES-861
Date 1/31/2018
Paraphrase This Document
Need a fresh take? Get an instant paraphrase of this document with our AI Paraphraser

RUNNING HEAD: THEORETICAL FOUNDATION
2
Problem of study
The problem under study aims to investigate current techniques that are required when
assessing commercially off the shelf (COTS) software. This has been a major problem when
organizations and individuals are purchasing COTS. The case would evaluate COTS selection
concepts and dilemma encountered. When selecting already made software, some issues should
be put in to consideration to make sure it meets all standards and thresholds (Cipra, 2016).
Precisely, the study problem is to come up with a procedure that can be used to help in selecting
software that is already developed. To come up with the best procedure, previous case studies in
selection of COTS would be analyzed. The gap to be filled is the challenge faced by
organizations and individuals when sourcing COTS. After analyzing factors to consider when
selecting COTS, Ayala et al (2011, 631) argues that, there is need for further study on challenges
that customers face once they have acquired software of their choice. The COTS selection theory
would be of great importance to customers in understanding which concepts to consider before
adopting COTS in to business operations.
Theories and concepts
COTS selection theory should consider several factors because already made software are
primarily developed without specific organizational requirements (Grossniklaus et al, 2012).
When purchasing COTS, some of the important aspects that should be factored are; the cost
associated with ownership of the product. It has been quite challenging for customers who need
already made software to know what they own once they purchase the software and the roadmap.
It is important to note that, COTS are associated with many risks and may end up being subject
to proprietary ownership in most cases. Roadmap defines the intention of developing the
2
Problem of study
The problem under study aims to investigate current techniques that are required when
assessing commercially off the shelf (COTS) software. This has been a major problem when
organizations and individuals are purchasing COTS. The case would evaluate COTS selection
concepts and dilemma encountered. When selecting already made software, some issues should
be put in to consideration to make sure it meets all standards and thresholds (Cipra, 2016).
Precisely, the study problem is to come up with a procedure that can be used to help in selecting
software that is already developed. To come up with the best procedure, previous case studies in
selection of COTS would be analyzed. The gap to be filled is the challenge faced by
organizations and individuals when sourcing COTS. After analyzing factors to consider when
selecting COTS, Ayala et al (2011, 631) argues that, there is need for further study on challenges
that customers face once they have acquired software of their choice. The COTS selection theory
would be of great importance to customers in understanding which concepts to consider before
adopting COTS in to business operations.
Theories and concepts
COTS selection theory should consider several factors because already made software are
primarily developed without specific organizational requirements (Grossniklaus et al, 2012).
When purchasing COTS, some of the important aspects that should be factored are; the cost
associated with ownership of the product. It has been quite challenging for customers who need
already made software to know what they own once they purchase the software and the roadmap.
It is important to note that, COTS are associated with many risks and may end up being subject
to proprietary ownership in most cases. Roadmap defines the intention of developing the

RUNNING HEAD: THEORETICAL FOUNDATION
3
software and possibilities of advancing the software in future. It has to define who will be
responsible in upgrading the software and specifications that would be covered by monthly
subscription. Therefore, there should be clear agreement between the parties on modalities of
what buyer has been licensed for.
Secondly, when acquiring off the shelf products, it is important for the vendor to
demonstrate how the product actually fits into specific organizational needs. Since customer
would give out organizational requirements to the vendor, it is the responsibility of the vendor to
decide reasonably if product would solve organizational problems. As discussed previously, it
would be important to get several vendors to showcase their products so that it is possible to
decide which fits organizational needs. The product should be able to meet at least 90% of the
critical business needs (Nautiyal & Gupta, 2013). Business needs defined by the organization
should be covered by the product as it appears in the current state, in future and ability to deliver
on these aspects without failure. The main purpose of acquiring the software is to come up with
business solution to the problem. In this regard, most of the software may not be fit to solve
critical business needs when acquiring them but vendors would insist on customizing them to
critical business logic (Ayala et al, 2011). The main question should be on the cost of
customizing it and whose responsibility is that? On the same note, focusing on future growth of
the organization, it will be important to determine if software would allow business logic
expansion. Again, the issue of ownership cripples in because total ownership would mean extra
cost to the product owner.
Additionally, it would be very important to understand if product has any clear defined
roadmap. The product roadmap helps to define if the vendor has any future plan regarding the
product. It should highlight the basis of whether the vendor is currently redeveloping the product
3
software and possibilities of advancing the software in future. It has to define who will be
responsible in upgrading the software and specifications that would be covered by monthly
subscription. Therefore, there should be clear agreement between the parties on modalities of
what buyer has been licensed for.
Secondly, when acquiring off the shelf products, it is important for the vendor to
demonstrate how the product actually fits into specific organizational needs. Since customer
would give out organizational requirements to the vendor, it is the responsibility of the vendor to
decide reasonably if product would solve organizational problems. As discussed previously, it
would be important to get several vendors to showcase their products so that it is possible to
decide which fits organizational needs. The product should be able to meet at least 90% of the
critical business needs (Nautiyal & Gupta, 2013). Business needs defined by the organization
should be covered by the product as it appears in the current state, in future and ability to deliver
on these aspects without failure. The main purpose of acquiring the software is to come up with
business solution to the problem. In this regard, most of the software may not be fit to solve
critical business needs when acquiring them but vendors would insist on customizing them to
critical business logic (Ayala et al, 2011). The main question should be on the cost of
customizing it and whose responsibility is that? On the same note, focusing on future growth of
the organization, it will be important to determine if software would allow business logic
expansion. Again, the issue of ownership cripples in because total ownership would mean extra
cost to the product owner.
Additionally, it would be very important to understand if product has any clear defined
roadmap. The product roadmap helps to define if the vendor has any future plan regarding the
product. It should highlight the basis of whether the vendor is currently redeveloping the product
⊘ This is a preview!⊘
Do you want full access?
Subscribe today to unlock all pages.

Trusted by 1+ million students worldwide

RUNNING HEAD: THEORETICAL FOUNDATION
4
to meet current situation in the market (Tarawneh et al, 2011). Again, the vendor should show
willingness to re-platform the product or integrate it with required components to make it feature
out in the market domain. Once the vendor has given the roadmap of the product, it is client’s
duty to examine if the product is in line with organizational business logic, vision, and direction
of development. The custom-made software roadmap should be business requirements and
priorities. It should capture organizational timing and cost to be involved because the customer
should control all of these.
Finally, supplier compatibility is of great importance because it provides ability to
incorporate acquired software within business processes without major technical issues. Vendor
should be able to give a clear timeline of when the product updates are coming and what measure
are necessary before patches are deployed (Wnuk et al, 2015). In this regard, some updates
would require existing organizational infrastructure to be upgraded such as database and
operating systems. To facilitate all required updates or upgrades in order to avoid incompatibility
issues, communication should be clear. Due to compatibility issues, there is need for reliable
local customer support as this will help the vendor to move at the same phase with business
needs. Subsequently, the product buyer has wide array of functionalities and responsibilities to
follow rather than product itself. These aspects would help to facilitate smooth flow of business
and include the following; ability of conducting business with other entities, vendor’s business
maturity, ability to offer required customer support and ability to meet timeframes.
4
to meet current situation in the market (Tarawneh et al, 2011). Again, the vendor should show
willingness to re-platform the product or integrate it with required components to make it feature
out in the market domain. Once the vendor has given the roadmap of the product, it is client’s
duty to examine if the product is in line with organizational business logic, vision, and direction
of development. The custom-made software roadmap should be business requirements and
priorities. It should capture organizational timing and cost to be involved because the customer
should control all of these.
Finally, supplier compatibility is of great importance because it provides ability to
incorporate acquired software within business processes without major technical issues. Vendor
should be able to give a clear timeline of when the product updates are coming and what measure
are necessary before patches are deployed (Wnuk et al, 2015). In this regard, some updates
would require existing organizational infrastructure to be upgraded such as database and
operating systems. To facilitate all required updates or upgrades in order to avoid incompatibility
issues, communication should be clear. Due to compatibility issues, there is need for reliable
local customer support as this will help the vendor to move at the same phase with business
needs. Subsequently, the product buyer has wide array of functionalities and responsibilities to
follow rather than product itself. These aspects would help to facilitate smooth flow of business
and include the following; ability of conducting business with other entities, vendor’s business
maturity, ability to offer required customer support and ability to meet timeframes.
Paraphrase This Document
Need a fresh take? Get an instant paraphrase of this document with our AI Paraphraser

RUNNING HEAD: THEORETICAL FOUNDATION
5
References
Ayala, C., Hauge, O., Conradi, R., Franch, X., & Li, J. (2011). Selection of third party software
in Off-The-Shelf-based software development—an interview studies with industrial
practitioners. Journal of Systems and Software, 84(4), 620-637.
Cipra, D. (2016). Chapter 5: Introduction to the chapter and background of the problem. In
Grand Canyon University (Ed.), GCU Doctoral Research: Analyzing Research.
Grossniklaus, M., Wimmer, M., & International Conference on Web Engineering, ICWE.
(2012). Current trends in web engineering: ICWE 2012 international workshops MDWE,
ComposableWeb, WeRE, QWE, and Doctoral Consortium. Berlin, Germany, July 23-27,
2012: revised selected papers. Heidelberg: Springer.
Nautiyal, L., & Gupta, N. (2013). Elicit-A New Component based Software Development Model.
International Journal of Computer Applications, 63(21).
Tarawneh, F., Baharom, F., Yahaya, J. H., & Ahmad, F. (2011). Evaluation and selection COTS
software process: The state of the art. International Journal of New Computer
Architectures and their Applications (IJNCAA), 1(2), 344-357.
Wnuk, Krzysztof & Kabbedijk, Jaap & Brinkkemper, Sjaak & Regnell, Björn & Callele, David.
(2015). Exploring factors affecting decision outcome and lead time in large-scale
requirements engineering. Journal of Software: Evolution and Process. 27.
10.1002/smr.1721.
5
References
Ayala, C., Hauge, O., Conradi, R., Franch, X., & Li, J. (2011). Selection of third party software
in Off-The-Shelf-based software development—an interview studies with industrial
practitioners. Journal of Systems and Software, 84(4), 620-637.
Cipra, D. (2016). Chapter 5: Introduction to the chapter and background of the problem. In
Grand Canyon University (Ed.), GCU Doctoral Research: Analyzing Research.
Grossniklaus, M., Wimmer, M., & International Conference on Web Engineering, ICWE.
(2012). Current trends in web engineering: ICWE 2012 international workshops MDWE,
ComposableWeb, WeRE, QWE, and Doctoral Consortium. Berlin, Germany, July 23-27,
2012: revised selected papers. Heidelberg: Springer.
Nautiyal, L., & Gupta, N. (2013). Elicit-A New Component based Software Development Model.
International Journal of Computer Applications, 63(21).
Tarawneh, F., Baharom, F., Yahaya, J. H., & Ahmad, F. (2011). Evaluation and selection COTS
software process: The state of the art. International Journal of New Computer
Architectures and their Applications (IJNCAA), 1(2), 344-357.
Wnuk, Krzysztof & Kabbedijk, Jaap & Brinkkemper, Sjaak & Regnell, Björn & Callele, David.
(2015). Exploring factors affecting decision outcome and lead time in large-scale
requirements engineering. Journal of Software: Evolution and Process. 27.
10.1002/smr.1721.

RUNNING HEAD: THEORETICAL FOUNDATION
6
6
⊘ This is a preview!⊘
Do you want full access?
Subscribe today to unlock all pages.

Trusted by 1+ million students worldwide
1 out of 6
Related Documents
Your All-in-One AI-Powered Toolkit for Academic Success.
+13062052269
info@desklib.com
Available 24*7 on WhatsApp / Email
Unlock your academic potential
Copyright © 2020–2026 A2Z Services. All Rights Reserved. Developed and managed by ZUCOL.





