On this page:
As a pre-condition of a CAST AIP analysis and in order to qualify the application from a technical and value perspective, CAST recommends gathering high level technical and non-technical information to help qualify the target application for the purpose of the analysis. The technical qualification will be used to establish what level of "out of the box" support CAST has for the application, identify any show-stoppers such as the use of unsupported technologies or frameworks and any potential customization that may be required to accommodate exceptions.
When unsupported technologies are part of the application, you must assess whether the remaining part using the unsupported technologies is worth analyzing. CAST recommends accepting the application for analysis only when at least 60% of the business logic is supported.
The questions are primarily focused on identifying:
The non-technical qualification will help to establish what level of potential value could be derived by analyzing the application. Questions are primarily focused on identifying:
Tangible outcome of this step includes:
The following image presents this in more detail:
The key tasks depicted above include:
The execution of tasks 1, 2 and 3 is usually combined. A single review meeting is scheduled to gather and validate all required information.
Gather information about the application's technological composition and structure. For example, for a typical J2EE application you should determine:
This information will support the "out of the box" analysis check and will help ensure that during the source code delivery validation you have access to all relevant application components. In the case of a J2EE application, this means ensuring the App Team has delivered, for example:
As an example, in the case of a J2EE application, many of the standard configurations such as JDK version, use of standard framework etc. are automatically discovered by the CAST Delivery Manager Tool by parsing the project file and are included in the delivery package. Others options such as the JAVA/JSP file version, EJB version and web services need to be manually configured by the CAST Admin based on the information gathered in these forms or discovered by inspecting the delivered source code.
As such, the more thorough and complete the qualification step is, the least effort is required from the CAST Admin to discover the correct analysis settings on his/her own by examining the delivered source code.
The recommended approach for executing this process step leverages the data collection form(s) identified above: forward the forms to application team stakeholders identified during the App. Team Kick-off for completion and follow-up with a meeting with all key application team stakeholders. The objectives of this meeting include:
The Application technical review may include the discovery of the analysis purpose. Understanding the Application team's intended use of the analysis results can help guide and direct the CAST Admin in deciding weather "a good configuration is good enough". This may be the case for example when fine tuning transaction identification: depending on the specific analysis use case, it may be sufficient to identify perhaps less than 70% of the expected transactions where in other cases a more precise tune up of the configuration would be needed. Thus, an understanding of the analysis purpose could help optimize the analysis value vs. effort ratio.
The information collected is used to:
Please see the following pages for more information specific to each technology:
|We have provided this as background information to ensure that the terminology used to describe elements in the source code is known by all.|
Wherever possible, this step must be executed proactively to save time and improve analysis efficiency. Typically, the need for pre-processing may be triggered by the information gathered during qualification of the application with the application team. Some of the more common situations are listed below:
Because an SCM can only manage files, and as the database schema of an application is strictly dependent on the version of the application, the database schema description is normally stored in file format in the SCM with the application source code. The descriptions can be stored as simple DDL scripts, or in a proprietary format. On the other hand, CAST analyzes only databases on servers, not scripts, as such, you will need to "pre-process" these SCM-fetched database scripts to transform them into participating databases.
POSSIBLE SYMPTOM(s): SQL file extension found and no database package
Sometimes the code inside each file is good for analysis, but the file organization is not satisfactory (this can happen for instance with web applications when URL-related pages are not folder-related using the same pattern, or when java source code is not in a folder path that matches their package). In these cases, you will probably need to do some pre-processing to move the files to a more appropriate location.
The information collected here is used to:
To completely define the analysis requirements, the CAST AI Admin needs to determine which analysis options should be considered during the analysis. This includes:
Armed with the information gathered, the CAST AI Admin must validate out of the box support against the Supported Technologies. Also review the known Analysis Limitations.
Any technology, framework, etc. not explicitly mentioned in this list is not officially supported.
Solutions and or workarounds may exist in some cases that are supported by the CAST PS Team: these are considered out of scope and will not be addressed here.
When unsupported technologies are part of the application to be analyzed, an analysis exception report must be created and forwarded to the requester of the analysis. This will halt the analysis process.
Previous: 1.2. Delivery Managers and other key participants
Next: 1.4. Deliver the application source code version