Package Selection & Integration Process For Web-Applications
Raghav S. Nandyal
raghav@intelligroup.co.in
General Manager, Corporate R & D
Intelligroup, Mana Sarovar Plaza, Secretariat Road Hyderabad 500 063 India
Abstract
Commercial web applications are often built by making a judicious pick of the different packages that address specific functionality. Some of this functionality includes for example, content management, personalization, security, user profiles, login & administration, data management and so on. This paper presents a "How-to" approach that was used with useful results to measure up on a package selection and integration exercise. It presents a systematic evaluation of commercial packages and their integration. The process articulated in this paper has factored a reduction in cycle time of the order of 6X for hosting web applications by collapsing an otherwise 12-phase implementation exercise into six tightly coupled but mutually collaborative phases after repeated improvements to the process over 6 months. This process is quite different from a COTS (Commercial Off-The Shelf product) evaluation in that, we are evaluating & selecting a "host" of COTS solutions addressing specific requirements and then using the technology of today to integrate them into one harmonious web application. The ways and means by which it is accomplished is described in what follows in an ETVX (Entry-Tasks-Verification-Exit) style.
1.0 Introduction
Development initiatives for web applications require an articulation of a well-defined Package Selection & Integration Process (PSIP) involving a judicious choice of package evaluation. The most common challenge in application development using a combination of packages addressing specific needs, include integration issues. And since most commercial applications are seldom developed from scratch, the PSIP must also factor and address design for change and must have the ability to choose from a survey of the steady stream of products available from the market place.
The process described in this paper has been "the practiced process" that has continuously been refined from applying it to several exercises. The process is decomposed into six tightly coupled phases. The Package Selection & Integration Process identifies the six phases to be:
As is obvious from the above, collaborating processes have been clubbed to have an optimizing effect on each phase. Repetition and duplication of work is avoided. Whereby increasing effectiveness of each phase by an observed cycle time reduction of 6X. This has been accomplished after repeated application of the original 12-phase approach that was attempted first. This approach is illustrated in the figure 1.
3.0 RDRA – Requirements Definition & Requirements Analysis
3.1 Objectives
3.2 Entry Criteria
3.3 Tasks
Feasibility Study
In the feasibility study, the present system if any is also reviewed to understand current capability of the system. This study will provide inputs to conduct an impact analysis of the new system on present capability. It will help to understand the business needs of the customer and summarize cost implications of having to modify existing system. This will result in the creation of Current System Analysis Report. The configuration item from this phase would be the Functional and Business Requirements Specification [FBRS] and the Package Selection and Integration Plan [PSIP].
Develop Functional & Business Requirements Specification
Prioritizing the importance of the requirements to the customer is important. All requirements should therefore be identified as core and non-core. This would help in assigning weights to product features that would ultimately decide in the ranking of the product. Assignment of weights could be based on ease of accomplishment (cost effectiveness), productivity improvement, and a business reason for the requirement.
Develop Package Selection & Integration Plan
One of the major inputs to the PSIP for the project is the Package Selection and Integration process itself, since it lays-out the agenda for package selection and integration. Together with the FBRS, historical data on similar exercises provide very resourceful insights into the percentage of time spent on each phase.
Major Considerations and Activities-Stakeholder concerns
Each of the different stakeholders in the COTS based package selection and integration projects have their own needs and expectations. Hence, the requirements in the RDRA phase come in two flavors - business and technical keeping in mind the different interests in COTS evaluation.
Derive detailed requirements
The high-level FBRS should be used as input to develop a detailed list of requirements. If we are using the current system as a baseline, then the general practice of reuse, buy and/or build will govern the detailed requirements. The current system analysis would have to be performed during the process of determining the detailed requirements. Decision to reuse the current system would mean that a migration strategy has to be explored and the corresponding migration requirements should be identified. Decision to buy a COTS package would involve an early identification of all the licensing requirements. It is extremely important to identify the relationship between the requirements and its correlation to the application domain. Such a relationship would help in the next phase (Product Survey & Market Screening).
3.4 Verification
Formal Requirements Definition
Using business needs and requirements as input generate a comprehensive set of functional requirements that are implementation independent.
Conceptualization
Perform a preliminary survey of products and/or implementations to get an idea of how the requirements might be satisfied. Consult with domain experts in applicable technologies. Research product features and possibly contact vendors. This is an informal process, but must be documented nonetheless. Conceptualization is inherently flexible; approaches will differ, based on domain, products, participants, resources, etc.
Package Types List
Identify types of packages available, using conceptualization, research, and requirements as input.
Obtain Sign-off
It is crucial to begin the next phase after obtaining customer commitment to the package selection and integration process. If there were an absence of management commitment from the customer to a packaged system solution, then the project would have to be terminated right at this stage.
The application domain introduces its own characteristic business and technical requirements that can influence COTS evaluation. All these can be documented in a Quality Assurance Plan [QAP].
3.5 Exit Criteria
Major Deliverables Requiring Sign-off –
4.0 PSMS – Product Survey & Market Screening
4.1 Objectives
4.2 Entry Criteria
4.3 Tasks
Requirements to Products Matrix
Create a traceability matrix for each one of the product vis-à-vis the requirements from the FBRS.
Study RDRA deliverables in relation to products
Create a matrix of requirements versus the products that are being evaluated. Understand the mechanisms by which the stated and implied requirement will be fulfilled. Study product virtues in relation to other competing products. Include market analysis if available for the product in the study. To narrow down the sample of the final evaluation to 3 products, it is imperative that we start with an initial product list that is at least 3 times bigger. The distillation process itself is refined from some sort of market survey/analysis activity whereby a number of feasible products are identified. From this set some number are selected, and prepared for integration by means of adaptation, wrapping and so forth, and, ultimately, integrated into a larger system. Finally, products are replaced as new versions of existing products are released, as superior products are identified, and as the underlying technologies are replaced.
Understand design decisions and tradeoffs
Which design constraints should be used to impose a feasibility litmus test on the marketplace of COTS products? Once the feasible products are identified, how are design tradeoffs quantified so that a measure of fitness for use can be computed? Answers to these types of questions often involve making tradeoffs among requirements, design, and the products selected to implement the design. As a consequence, we can expect to see (and do see) COTS software evaluation being applied not only to select products, but also to support design decision which are made before and after products are selected.
Archive product reports
Obtain product referrals from vendors. Contact site representatives and obtain references for the product using which create a product binder from archives resulting from study of product catalogs, research reports, white paper evaluation, product reviews and reports of past experience from knowledgeable individuals.
Conduct Preliminary Screening
Conduct a preliminary screening of the products after performing an evaluation of similar products. The preliminary screening process would include preparation of the evaluation criteria for product by categorizing the importance & relevance of detailed requirements to the evolving scenario of the web application domain. In order to improve the coordination of all concerned stakeholders, it is important to generate a glossary of terms that will explain the key topics concerning the application domain.
Prepare Evaluation Questionnaire
Prepare an elaborate questionnaire to quiz the vendor during the demonstration of the product based on both business and technical requirements documented in the FBRS. Prepare the questionnaire to include security, information integrity and integration issues in mind. Technology concerns of the application domain should also be addressed. The PSIP must make sure that this exercise is broken down into different levels of abstraction. This exercise results in the creation of Demo Evaluation Questionnaire.
Run a product race
Divide the team into groups representing the different products that stand a good chance to make up the final three and run an internal product race. Shortlist the candidate products and prepare a product specific questionnaire. Plan the vendor demonstrations and contact vendors for demonstration.
4.4 Verification
Adequacy of Number of Products under Evaluation
During product study in the PSMS phase, it would become abundantly clear whether the sample space of products being evaluated is sufficient to make the final selection. If the number of products in the sample space is not enough, it is important to reopen the initial product list from RDRA phase and conduct the PSMS phase on any additional products.
Assessment of product capability
It is important to obtain "separate" assessment reports for the product from as many viewpoints as possible. A few of these perspectives are Technology considerations, Database connectivity, Integration with legacy systems, Security and control, Learning curve & Product adherence to standards in the application domain.
Requirements to Package Mapping
Using the package types list and functional requirements as input, create an approximate mapping of functional requirements to package types. This provides a concise, tabular, representation of what types of products can support each requirement (if any).
Package Identification
Using package types and functional requirements as input, identify packages within each type. Both a vendor and product list should be maintained, along with pertinent contacts and product information. At this stage, these packages are considered candidates.
Preliminary Package Screening—Platform & Security
Using security and infrastructure standards, eliminate any unacceptable packages from the list of candidates. This applies to platform issues as well as security (e.g., will it run under our production operating system, web servers, etc.). If the vendor will shortly release an acceptable product but current product is unacceptable, then the product might not be excluded at this stage (if timelines can be met and the risk of non-delivery is acceptable, e.g., when no acceptable product is available). The resulting deliverable is the Platform & Security Alignment Report.
Internal Standards Alignment
Standards from appropriate standards groups should be consulted to identify if there is a recommendations or requirements for products in the desired package types. If there is no standard, then the process may proceed. If there is more than one acceptable standard, then proceed with final package selection, using the acceptable standards as candidates. If there is no acceptable standard, then proceed, but be prepared to request an exception (which might be denied). The resulting deliverable is the Internal Standards Alignment Report.
Preliminary Package Screening—Business and Technical Requirements
Using the Requirements to Products Matrix as input, perform a preliminary screening of candidate products to produce a smaller number of viable candidates that will be evaluated in greater depth. Ideally, one package may be selected if it appears best in class, is representative of industry best practices, and has a demonstrated usage history in enterprises that have similar functional requirements and similar operating environments (including volume and reliability). It may be desirable to extend the package evaluation matrix further, by introducing weighting criteria (based on business need), and possibly including non-product related selection criteria such as cost, support, corporate stability, etc.
4.5 Exit Criteria
Major Deliverables Requiring Sign-off –
5.0 VDPR – Vendor Demonstration & Product Ranking
5.2 Entry Criteria
5.3 Tasks
Technical evaluation business, architecture, security
Evaluate the business, architecture and security requirements based on the Platform & Security Alignment Report.
Exception criteria documentation
Formalize the exception criteria from the platform & security alignment report and the internal standards alignment report.
Vendor Demonstration of Products
This exercise may have to be conducted several times to make sure that all perspectives to product evaluation are represented in the final selection.
Product references from vendor
Obtain product references from sites that are currently using the vendor’s product. Talk to site representatives to ascertain adequacy of the product to meet required criteria.
Hardware and Software Evaluation
For the final solution to work effectively, either as a "single-product" solution or as a "suite-of-products", what are the different hardware and software requirements? This question has to be answered from different perspectives to have meaningful trade-off rules.
Rank the products
After evaluating the demonstration, rank the products based on coverage obtained on the FBRS and any additional evaluation criteria for the specific application domain.
Final package selection
Using the smaller list of candidates that passed prior screening, conduct a formal evaluation that includes a prototype or pilot, and which completes all of the entries in the requirements to products matrix. Use any weighting criteria, additional requirements, and additional criteria, as are available at this stage to identify the final package.
Package customization
Understand any solution specific customizations that would have to be rendered in the final package mix should the products by themselves not support the solution completely.
5.4 Verification
Ensure requirements coverage
It is important to dedicate a few individuals to make sure that at the end of product demonstration, adequate coverage on the requirements has been obtained. If coverage of 80% or over cannot be obtained, then this phase has to be conducted again with a fresh sample of products.
Review vendor proposals
Review proposals against established selection criteria. If additional data is required from the vendors to conduct this exercise, it has to be communicated now. Develop an implementation strategy report that will highlight a preliminary assessment of how the solution is going to be developed. Rework the project completion plans after conducting detailed micro level assessment of time required for completing the solution. [Vendor Proposals]
Review results with sponsor and management
Results from demonstration should be reviewed with the sponsor and management. [Adjusted Project Plan]
5.5 Exit Criteria
Major Deliverables Requiring Sign-off -
6.0 SASR – Solution Alternatives & Solution
RecommendationTo document solution alternatives and propose a final solution
6.2 Entry Criteria
6.3 Tasks
Work out solution recommendation
After a detailed understanding of all the products is obtained, it is now important to put together a solution recommendation involving as little a number of products from the shortlist as possible that would effectively provide for the solution. Develop scoring criteria with an objective of achieving maximum score.
For all the demonstrated products work this out in parallel
The above permutations and combinations should be worked out in parallel.
Fit solution provided by the product to the requirements
Establish enough vendor support to fine-tune the product to meet the stated and implied requirements
Build an Integration strategy for different products
This strategy has to be worked simultaneously for all selected products to make sure that pilots are effective.
Conduct Price negotiations
The project team must evaluate costs based on the following, Package cost including License Fees, Design and installation cost, Selling price and maintenance fees, Operating costs, Training costs and On-site Assistance costs, Other costs such as travel and Overheads.
Take a re-look at the products
If no product or a combination can fulfill at least 80% of the stated and implied requirements, then the selection criteria may have to be re-addressed for an additional stage of package selection, or the functional requirements must be addressed differently (presumably cost justified for custom development).
Final Recommendations Document
After examining the solution alternatives from the point of view of product interoperability, a final product recommendation can be given to the customer. Project team must justify and quantify the benefits of each of the solution alternatives. Team should group the solution space to accommodate the best-fit solution providing for good interoperability. This can be done best at the vendor location with numeric weights. The resulting deliverable is the Final Solution Recommendation Report.
6.4 Verification
80% or more coverage
It is important to determine if 80% or more of coverage is obtained from the recommended solution on the stated and implied requirements.
6.5 Exit Criteria
Major Deliverables Requiring Sign-off
7.0 RCPI – Requirements Confirmation & Product Interoperability
To perform acceptance testing of the solution recommendation and to ensure product interoperability
7.2 Entry Criteria
7.3 Tasks
Integration & Acceptance Testing
The Final Solution Recommendation Report might contain certain features that were stubbed out. When the final solution is put together, these stubs have to be replaced with working alternatives from the chosen products that have the exhibited and demonstrated capability to accomplish the goals of the solution. The different testing strategies that will be adopted for final package integration have to be documented. The resulting deliverable is the Integration Test Report.
Create the feasibility test Matrix
This matrix will contain traceability of the solution to the requirements. It will have to verify that at the end of the demonstration, 100% coverage on the stated and implied requirements is accomplished by putting together the different products forming a solution alternative. It might be necessary to build wrappers where the products themselves don’t fully satisfy the requirements.
Test environment setup - Rent, Purchase or Lease considerations
Evaluate the above options to establish the test environment setup.
Contract for the product
After a thorough investigation on product suitability has been established from the above process, award the contract to the vendor for the product. This must include payment terms and conditions, penalty clauses, legal considerations.
Revised Project Plan
Update the project plan to reflect current project status.
7.4 Verification
Integration and Acceptance Testing Report
This report must achieve 100% coverage on the requirements from the proposed solution.
Legal considerations
Make sure that the legal implications of using the solution alternatives have been thoroughly whetted by legal experts before signing the contract.
7.5 Exit Criteria
Major Deliverables Requiring Sign-off –
8.0 PDRO – Product Development & Roll Out
8.1 Objectives
To define the final product from a suite of products
8.2 Entry Criteria
8.3 Tasks
Design document for product implementation
Document the final design of the solution based on the product mix. This document must consider all interoperability issues, hardware and software support requirements.
Simulate all usage situations
This exercise can be done in several ways. Simple data flow diagrams, entity relationship diagrams, use-case or any other traditional object oriented approaches involving the use of depicting event-trace diagrams or preparation of scenarios.
Migration & Conversion
In preparation for final rollout of the product, data migration from any existing legacy systems should be worked out. If data retrieval and modification is possible with the final solution without changing the legacy system, wrappers that will facilitate this should be developed. File-to-file conversions may be required for manipulating data elements.
Customization & final rollout
It might become necessary to customize the product if it has to inter-operate with the existing legacy system before final rollout.
8.4 Verification
Verify project milestones
Ensure that additional customizations for final rollout are planned in advance without affecting project milestones.
Verify product compliance
Verify whether the product meets all the stated and implied requirements as it is being built. Document any deviations and have them resolved by the vendor.
8.5 Exit Criteria
Major Deliverables Requiring Sign-off
CONCLUSION
The Package Selection & Integration Process for Web Applications described in this paper has been applied to develop several commercial web applications. Besides a choice of interoperability are often built by making a judicious pick of the different packages that address specific functionality. Some of the functionality includes for example, content management, personalization, security, user profiles, login & administration, data management and so on.
Package Selection and Integration Process described in this paper is based on determining the quality of the product in the context of its intended use. The questions that would arise are:
These questions answer the different possible goals that can influence how to define the Package Selection and Integration Process. There is therefore a need for a "variety of methods" in COTS evaluation that is based on the application domain. This paper attempts to provide one such repeatable evaluation process that can be used by practitioners, specific to package selection and integration. This paper attempts to make this process as comprehensive and generic as possible while addressing this goal.
Bibliography
[1] IEEE Standards for Software Engineering
About Raghav S. Nandyal
Raghav Nandyal is a General Manager heading Corporate Research & Development at Intelligroup Asia Pvt. Ltd. He has 12 years of software engineering and management experience in both research, and software development environments. He is an alumnus of Illinois Institute of Technology, Chicago where he graduated with a Master of Science degree in Computer Engineering. He is a donor alumnus of the Indian Institute of Science where he worked as Research Associate in the VLSI CAD Laboratory.
He has held several positions ranging from software engineer to senior manager in prestigious organizations worldwide. He began his professional career with Motorola India Electronics Pvt. Ltd., one of the very few CMM level 5 companies in the world where he developed several innovative software tools with an attempt to automate the software development life cycle. He worked for NYNEX Science and Technology Asia (P) Ltd., in their Bangkok and New York locations as senior manager. He held several management positions at LG Software Development Center (India) before joining Intelligroup Asia Pvt. Ltd. He was also the driving force behind implementing a CMM Level 2 process infrastructure in one of the LG affiliates in South Korea in eleven months.
He has published and presented several papers in international conferences. His current research interests are in mitigating software risks and building self-sustaining software process improvement program in development environments working with emerging technologies-Intelligroup being one such fertile implementation grounds. Implementation of the Software CMM and People CMM initiatives are vested with the corporate research & development. He was the driving force behind implementing a CMM Level 3 process infrastructure in the Advanced Development Center, Intelligroup, Hyderabad in nine months.
Figure 1. Package Selection and Integration Process