Systems
Analysis and Its Role in COTS selection
By
Matt House
The ever-changing business
climate has forced companies to rethink their approach to information
technology. Many companies are opting to
use Commercial of-the-shelf (COTS) software packages. COTS software is a vendor-supplied product
that performs a specific function that can be integrated with existing systems
(Morisio).
These packages can be sold or licensed to any company, and because of
this it’s sold as a standard product with little or no modification of the
source code. The vendor still owns the
intellectual property rights to the software (Morisio). The development phase isn't the only place
where companies can see cost savings; many COTS providers also provide support
of their software during a licensing period.
The COTS buyer source selection process involves the matching of the
company's requirements to the various producers’ capabilities while looking for
the supplier with the smallest gap. The
use of COTS software requires companies to revise their processes and procedure
to mirror the functionality of the COTS software.
The requirements gathering
phase maybe more important when planning for a COTS project than a
traditionally developed system. You
always want to have your requirements defined the best they can, but when planning
a COTS system it may be even more important because in a traditionally
developed system you can always go amend your software development package
unlike COTS where you get what you get. Its not enough to know what your needs/wants are, they need to
be prioritized because more often than not you will not be able find them all
fulfilled by one package (Moriso). When looking at the purchase of COTS
products, it needs to be done from the perspective of buying any commercially
available product. For the most part
COTS software is sold "as-is" and cannot be changed to fulfill a
requirement. It is for this reason
requirements need to be well defined before you can begin the process of
selecting your COTS systems. Steps for determining your requirements should
include: determine what systems and actors will be involved, determine the
importance of the systems features and their relationship to your quality
model, the relationship to these features and your system throughput needs, and
to make sure that the new COTS component with be within compliance tolerances (Carvallo). Poor
requirements definition can lead to the purchase of a system or component that
does not fulfill all of your immediate needs and may not be flexible enough for
changing needs down the road. This diagram shows a
comparison between the traditional software development process and the COTS
selection process (Carvallo). As you narrow your selection
of potential systems, you will need to look at what trade-offs you may or may
not have to deal with. Since it is
doubtful that all of your needs are going to be met, you may need to look at
what end-user processes may need to change as a result of the limitations of
your possible systems (Brownsword). It is also gauge the functional performance
of a proposed COTS application. It isn't
enough that a system does what you
want it to; it needs to do it with a
performance time that is acceptable with regard to your whole system. Testing and profiling needs to be done to see
how well a piece of software performs required functions (Putrycz).
Architecture is another
aspect of selecting a COTS product that is a key aspect in the analysis of a
COTS product. Many COTS components are
modularized so that they can be "plugged" into one's existing
architecture (Yakimovich). This is
another reason why it is important to understand what will be required of a
system before you can decide on a COTS system.
Architecture validation is key to helping
ensure that your COTS software interfaces with your other existing
components. Your architecture needs
designed un such a way that you will be able to
facilitate linkage between your COTS software and other shared modules,
libraries and data sources (Yakimovich). The
architecture must be robust enough to survive through many years of
evolutionary change so as to prevent costly replacement. This requires you to understand the market place
so as to determine the long-term viability of the various offerings you are
evaluating (Brownsword). He is a link to a video where
a project manager discusses issues that arise from having architecture issues
when integrating COTS components.
Another consideration of
your source selection process is the interface definition to ensure that your
COTS system can work seamlessly with its existing systems. Do you need to develop middle ware to make
your COTS product work with existing systems?
You need to make sure that your architecture allows this plug and play
capability or that middle ware development costs and issues don't nullify the
selection of a COTS product (Brownsword). You need to
monitor these connections and allow for full integration testing of new patches
and updates to make sure that these changes in the software do not affect you
architecture integrations. Modification
of your COTS software is a two-headed monster; you get what you want, but you
then have unique and more costly software to maintain because that maintenance
is solely your responsibility (Chang). Testing
and test cases should be prioritized as to the level of severity a fault can
have. Integrations or functions that
could severely affect the throughput of your system, as a whole should be
tested early and with every new patch and release. Lower impact integrations or functionality
can be tested less frequently or if a new change directly affects them (Mariani).
Configuration management is
just as important with COTS software as it is with in-house development. All updates, patches and defect fixes must be
thoroughly tested to ensure that it doesn't affect your core program
functionality. A small tweak can cause
devastating impacts to targeted and adjacent systems thus requiring the full
integration testing that can't be accomplished at the software supplier and can
only be accomplished by the buyer’s team.
Therefore, there is a greater testing burden on the buyer of COTS
software that in the traditional development (Brownsword). In the traditional environment you know all
the changes that have been made to the source code whereas in a COTS
environment you're relying on the producer's testing who has no knowledge of
your systems and potential interface issues.
So it is incumbent on the buyer to fully test the software before you
put it into your production environment.
Failure to do can have devastating impact on your business's
operation. With COTS software you find
yourself with more patches and enhancements than you do with in house designed
software because of the numerous customers and varying needs of those
customers. These numerous patches must be constantly tested to make sure that
they do not interfere with your overall system functionality (Cortellessa).
In traditional software development you go through a development phase followed
by a maintenance phase but with COTS the needs of all their customers cause the
producer and their customers to live in a state of constant development. Therefore, the user must decide if and when
they put software updates into their system.
In an effort to maintain a stable production environment a company may
elect to incorporate updates in block point structures versus how the supplier
releases their updates.
Another consideration in the
selection and management of COTS developers is the management and assessment of
the inherent risk with your potential suppliers. Does your supplier have sufficient resources
to support your deployment? Are other customers
a higher priority and does my project rate the A team or the B Team from the
COTS provider? Is the potential provider
financially solvent and able to provide support for years to come? Many of the issues are the same as a
traditional development but the ability to control the process and outcome
change. Your ability to direct resources
and set priorities is significantly less as a buyer versus a designer
(Yang). As a designer you have one
priority and that is your company and as a COTS provider you have to balance
the priorities of your many customers and the challenges is where does your
company fit in to those priorities. The
ability to successfully support the deployment of their COTS applications can significantly
affect the business case for your source selection. Schedule delays drive cost as your standing
army of systems engineers, testers and middle ware developers can put a project
in the red in short period of time.
The ability to evaluate
trade-off activities is crucial to successfully selecting a COTS provider and
executing a project on cost and within budget.
Since not all COTS applications are equal you must be able to evaluate
as part of your requirements definition phase the relative importance of those
requirements versus cost, schedule and functionality. Trade-offs must be performed during the
selection phase and you will undoubtedly be required to make tradeoffs during
the deployment phase as issues arise and choices must be made to execute the
project on time or within cost.
Therefore a disciplined method for evaluating these trade-offs must be
developed and utilized throughout the project (Morgan).
Another unique challenge of
COTS software is the internal challenge of setting the appropriate expectations
with your internal stakeholders. With an
in house design your are developing a system around
existing processes and with COTS products the users will be forced to make
changes and compromises. Change is
frightening to most people and organizations.
If your deployment is to go successfully you need to bring those
stakeholders along with you every step of the way. You need make sure that you stakeholders feel
like their concerns are being addressed, but that the reason you are moving to
a new COTS product is for the benefit of the organization. Your internal team's participation is vital
or any number of real and imagined walls will be built in order to kill your
project and prove their fears have foundation (Morgan).
There are many pros and cons
to the use of COTS products. It can
produce very large cost savings due to a lower development and maintenance
effort. However a project needs to be
aware of the differences between integrating a COTS package and a traditional
in house development project. The
biggest difference between the two is being aware of what you can and can't
control. Here is model showing what the flow of work
is on a COTS project. This model
illustrates which aspects of the project are worked on in house and which parts
are out of the COTS buyer’s hands (Brownsword). Since
changes in the baseline version are unlikely, a company needs to make sure the
new COTS package will fulfill their needs.
Since the buyer has little no control of the core functionality of the
product, the buyer must aware of and properly manage the things it does have
control of. These things include how the
new package will fit into the company's existing architecture, testing
methodologies and schedule, and maybe most importantly stake holder perception
and usability. It should not be
understated how important stakeholder buy in is. COTS changes the way systems are designed and
in turn how they are used. If an
organization can adapt to new ways of thinking about systems analysis, then
they will be able to leverage the all the positives that can come from
integrating COTS software into their systems.
Works Cited:
Putrycz, Eric “Using Trace
Analysis For Improving Performance in COTS Systems”
Yang, Ye; Boehm, Barry; Clark, Betsy.
“Assessing COTS Integration Risk Using
Cost Estimation Inputs”
