Page tree
Skip to end of metadata
Go to start of metadata

Overview

As precondition of a CAST AIP analysis and in order to qualify the application from a technical and value perspective, CAST recommends to gather 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-stopper such as the Application use of unsupported technologies or framework and any potential customization that may be required to accommodate exceptions.

 When unsupported technology are part of the application : one must assess if the remaining part is worth to be analyzed. CAST recommends to accept the application for analysis only when at least 60% of the business logic is supported.

The questions are primarily focused on identifying:

  • Main technologies in use, including versions
  • Estimated size of the application
  • Architectural questions about cross technology architecture, functional domains, etc
  • Technology specific questions giving insight into specific technical aspects and use of particular frameworks
  • Main contacts within the application team

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:

  • Business related information e.g. criticality, number of users, major releases, etc.
  • Application information e.g. maturity level, Package Solution like PeopleSoft, etc
  • Team organisation e.g. maturity level of dev team, in house/out sourced dev, staff turnover, etc
  • Quality e.g. production downtime hours, number and type of support calls, known issues, etc. 

Tangible outcome of this step include:

  • Application Technical Survey and Source Code Delivery form (combine?)
  • Architecture review diagram and notes
  • Service Engagement Sheet
  • Analysis Exception Form (if the application disqualified for technical, schedule or benefits vs panned-effort reasons and the analysis request rejected by the AI Center)


(click picture to magnify)

The key task 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.

Application Technical Review

Use the ATSF and SCDF (combine and link to out-of the box application analysis acceptance criteria  [TBD]?) to gather information about application technology composition and structure. For example, a typical J2EE application you should determine:

  • The JDK version used to compile the source code
  • The frameworks used and the version numbers
  • The different application layers
  • The archives (third-party)
  • The application server used to run the application

These 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. This, for example, in the case of a J2EE application means ensuring the App Team has delivered:

  • All the JAVA/JSP application source code, the relevant XML and .properties files and all the client files (HTML, JavaScript ...).
  • The deployment descriptor files required for EJB and Web Services analyses
  • The archives of libraries required to run the application, including those of the application server 

As an example, in the case of a J2EE application, many of the standard configurations such as JDK version, use of standard framework and other are automatically discovered by the DMT by parsing the project file and included in the delivery package. Others 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. The more thorough and complete is the qualification step the least effort is required from the CAST Admin to discovered the right analysis setting on his/her own by examining the source code delivered.

The recommended approach for executing this process step leverages the data collection form(s) identified above. The recommended approach is to forward the forms to application team stakeholders identified during the App. Team Kick-off  for completion and follow-up by a meeting with all key application team stakeholders.  The objective of this meeting include:

  • review any information provide (accuracy, clarity, completeness, etc.) by the app team before the meeting
  • document in the form any relevant missing information

The application technical technical review may include the discovery of the analysis purpose. Understanding the Application team 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 the transactions finding. Depending on the specific analysis use case,it may be sufficient to identify perhaps  less than 70% of the expected transaction where in other cases a more precise tune up of the configuration would be needed. Thus understanding the analysis purpose could help optimize the analysis value vs effort ratio. 

 

Why is it important?

The information collected are used to:

  • evaluate completeness of the SC delivered
  • assess if analysis out-of-the-box support is possible and/or determine any potential solutions to address any limitations/constraints

Application Architecture Review

The architecture review aims to develop an high level understanding of the application architecture to help with the configuartion of analysis and the discovery of transaction . For more details see Architecture Review.

This meeting should include the Application Architect, Senior developer, etc. as applicable.

 

Why is it important?

The information collected here are used to:

  • evaluate completeness of the SC delivered
  • ensure complete and accurate analysis configuration
  • support the configuration of transaction
  • support Automated FP calculation

Analysis Options

To completely define the analysis requirement the CAST Admin needs to determine which analysis options should be considered during the analysis. This include : escalated links, XXL rules, User Input Security Dataflow, UDM modules design, which aggregation mode, ...

  • escalated links
  • XXL table rules
  • User Input Security Dataflow
  • User Defined Module (UDM) design (portfolio tree)
  • Aggregation mode
  • any additional application team expectation

MODIFY: service engagement sheet 

Why is it important?

  • document app team expectation
  • in a Managed Analytically Services (MAS) context capture the term of the analysis service contract between FO and BO
  • essential for modules and other analysis options configuration

Assess CAST out-of the-box support 

Armed with the information gathered, the CAST Admin must validate out of the box support against the supported technologiesAlso review the known Analysis Limitations

Any technology, framework, etc. not explicitly mentioned in this list is not officially supported.

Solutions and or workaround may exist in same cases that are supported by the CAST PS team .Those are considered out of scope and will not be addressed here.

When unsupported technology are part of the application to be analyzed an analysis exception report (template?) must be created and forwarded to the requester of the analysis. This will halt the analysis process normal execution. 

Why is it important?

  • identify any exceptions to out-of-the box support as early as possible
  • improve efficiency and avoid reworks

 

Previous: Analysis Kick-off
Next: Application Analysis Process with CAST AIP

 

  • No labels