Created by BestPractices, last modified on Dec 11, 2023

Version 5.1

Date  

Table of Contents

Purpose

This document details CAST’s Agile Onboarding Process along with the checklist templates used. Agile process is recommended to implement in measurement program with .management visibility – it helps in quick onboarding with minimal technical documents needed from the application team.

Applicability 

Iterative Agile process is recommended to implement measurement program with management visibility – it helps in quick onboarding with minimal technical documents needed from app teams and helps to avoid tunnel effect. Agile onboarding will have three iterations and will not have any custom solution implemented.

Prerequisites for Onboarding

  • CAST Application Intelligence Portal (AIP core) is installed, Imaging console & CAST Imaging is installed
  • Supported Technologies/Frameworks
  • Extension to be used if required
  • Admin / Super Admin has access to Console and node 

Out of Scope

  • Rescan and rescan automation
  • Unsupported technologies
  • Cleanup and retention

Target Audience

  • All Admins and Super Admin who would be onboarding an application.

Process Flow with Imaging Console 

Agile Onboarding Process Overview

Agile onboarding process consist of three iterations -

  1. 'Discover' is applicable to all applications
  2. 'Onboard' is applicable only to those applications where the feedback is received from the application team on the gaps identified during rapid onboarding
  3. 'Integrate' is applicable only if there are customized measurement required by the application team based on the identified use case

Objective

The objective of Agile process are:

  • Minimizing initial questions to app teams
  • Avoiding tunnel effect and maintaining exchanges with app teams on progress of the analysis
  • Bringing visibility and speed in the early stages for the CAST programs at customers

Approach Detail 

Key inputs required

Steps in Agile Onboarding Process

1. Discover

This iteration consists of three main activities i.e.

  • Qualification of the application
  • Acceptance of the software components provided by the customer and delivering initial measurement
  • Technology and transaction understanding of CAST consultant/architect to the customer. 

As a precondition of a CAST AIP analysis and to qualify the application from a technical and value perspective, CAST recommends gathering high level technical and non-technical information to help and qualify the target application for 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 showstoppers such as the use of unsupported technologies or frameworks. It describes guidelines on delivering application source code, packaging source code with CAST DMT, validating alerts, analyzing application first time, discovering application's boundaries (Entry/Endpoints), technology, and missing software components and delivering the relevant reports and initial measurement to the customer.

AIP Product Documentation

    1. Application Qualification process overview: https://doc.castsoftware.com/display/DOC83/Qualification
    2. Application Acceptance process overview: https://doc.castsoftware.com/display/DOC83/Delivery+acceptance
    3. Initial Analysis Configuration overview: https://doc.castsoftware.com/display/DOC83/Review+Technology+and+Dependency+settings

Entry Criteria

Process Steps

  1. Kickoff Meeting: A formal meeting (preferably) has to be conducted - Agenda should be application technologies, availability of software components and introduction to CAST AIP Program
  2. App Qualified: 
    1. FO has to verify whether the software components (source code, database and context diagram) are in line with the technical survey essential 
    2. Service Engagement Sheet has to be prepared to define scope of the application
  3. Add application ( Click on Onboard application button)
  4. Run the Fast scan:
  5. Run Initial Deep Analysis:
      • The deep analysis process in the onboarding with Fast Scan workflow automatically includes all of the following steps:
        • Application analysis
        • Generation and publishing of results to CAST Imaging and CAST Dashboards (if configured)
      • When using onboarding with Fast Scan, Console does not expose the advanced configuration options BEFORE an initial analysis has been completed. Therefore the following analysis workflow should be followed:
  6. Post Initial deep analysis, the different analysis phases can be run individually (run analysis only, run snapshot only, upload to imaging, publish the dashboard)
  7. Completeness Check: Check if we are good to proceed further based on the Analysis Completeness Report (if more than 10% of the software components are not analyzed then make go to step 4. 'Run Analysis & Snapshot') To Do
  8. Share Initial Results with customer
  9. App Boundary Definition:
    1. Validate the technologies and frameworks
      1. Validate missing software components
    2. Identify and validate the Entry and Endpoints
    3. Identify and document impact of missing software components
  10. Rapid Discovery Report:
    1. Share the Rapid Discovery Report (FERC) with the FO/Customer ( Enclosed the Rapid Discovery Template Here )

Exit Criteria

    1. Initial measurement delivered to the customer
    2. Rapid discovery report delivered to the customer

Deliverable

    1. Initial Measurement
    2. Rapid Discovery Report (Template Link  - Sample Report)
      1. Note : The guidelines to prepare the report are updated Here

2. Onboard

This iteration is applicable if and only if the gaps identified as part of the rapid discovery report are filled or we have the complete source code and there is no gap identified during Discover phase. Main activities in this iteration are fine-tuning of the analysis configuration, transaction configuration, review of transaction completeness and validation of dashboard results.

AIP Product Documentation

    1. Fine-tuning of Analysis Configuration - https://doc.castsoftware.com/display/DOC83/Run+and+validate+the+analysis
    2. Transaction Configuration - https://doc.castsoftware.com/display/DOC83/TCC+-+CAST+Transaction+Configuration+Center
    3. Review of transaction completeness - https://doc.castsoftware.com/display/DOC83/Transaction+management
    4. Validation of dashboard results - https://doc.castsoftware.com/display/DOC83/Engineering+Dashboard & https://doc.castsoftware.com/display/DOC83/Health+Dashboard
    5. Link to refer while loading Imaging and validating results - https://doc.castsoftware.com/display/IMAGING/

Entry Criteria

    • Completion of Discover iteration
    • Customer's inputs on the gaps identified as part of the rapid discovery report

Process Steps

  1. Gaps Addressed:
    1. Check whether the open questions as identified in the transaction report has been addressed by the customer?
    2. Ensure that the missing software components are delivered by the application team
    3. In case of gaps that are still open, contact the application team to receive the inputs or take an Informed exception
    If yes, handover to Admin: The Expert has to handover all the application related information along with the relevant report (Rapid Discovery Report)
  2. Upload the new code again
    1. Reject the current version
    2. Upload the code again with the gaps addressed . Best Practices for code folder:

      1. For Java

        • The folder structure should be the same as it is there in the SCM which project team is using. Including complete hierarchy of ALL .pom and parent .pom files. These files will allow the automated discovery and analysis configuration.

        • In the case of maven project: a copy of the local maven repository should be provided in the code folder .

        • Library files for Java technology should be present in the code folder

      2. For .NET
        • Usually, the source code is versioned using tools like SVN or Git. 
        • The best way to deliver source code is to use the CMS and check out the source code of the version that has been selected for analysis. Make sure to NOT include the ".git" or ".svn" folders
        • Include the "bin" folders that contain binaries (debug and/or release assemblies) that are created at build time. They should also contain third-party assemblies.
      3. For Mainframe
        • PDS can not be included in case of Imaging console
        • Each application must be delivered in a single folder. 1 file per object type.
        • 1 file per program, 1 file per copybook, 1 file per JCL job, etc in the folder structure as shown in the image below
  3. Modify the code file/folder and upload, Run analysis again 
    1. Follow all the steps that is identified as applicable in step-6 (Setup CMS, Run analysis and snapshot) of Discover phase

    2. Setup Environment & Analysis configuration 

      1. Source code “File Adjustments” (Optional)

      2. “Preprocess” Source Code (Optional) - In some situations, the source code cannot be parsed and must be preprocessed. A study should be done first to identify the pre processing rules which must be applied to the source code. Add Pre processor batch file ‘Tools Before Analysis’ under Content Enrichment tab

    3. Verify Framework Settings if there is any issue identified during log / result validation.

      1. Ensure that correct versions of technologies and frameworks are selected

    4. Adding dependencies – add the dependencies between analysis units (if required)

    5. Fine-tune  settings

      1. Choose an Environment Profile if needed (Only Product supported profiles)

      2. Configure include/classpaths according to the technology

      3. Enable User Input Security if it is within the scope of the analysis

  4. KB Inventory Validation:
    1. Check if all the technologies/frameworks have been analyzed properly
    2. Check if all the files have been analyzed properly ( Files in DMT vs files in KB )
    3. Validate for the check on 'Unexpected Objects Count
  5. Log Validation :
    1. Follow the troubleshooting process to remediate warning and errors by referring to product documentation available at https://doc.castsoftware.com/display/DOC83/Validate+analysis+based+on+log+messages
    2. Document the log validation results: Number of alerts, type of alerts, and tickets raised (if any).Incase if any alert is remediated, put up the process of remediation of the alert.
  6. Review Dynamic Links: ( AALV )
    1. Create application-specific DLM rules to resolve the dynamic links
    2. Guidelines to validate the dynamic links are available in https://doc.castsoftware.com/display/DOC83/Validate+Dynamic+Links
  7. Module Configuration : 
    1. Set up the module content according to the client’s requirement
    2. Validate the check on 'Overlapping Objects count'
    3. If no recommendation, retain the Full Content
    4. Guidelines to create user-defined modules are available in https://doc.castsoftware.com/display/AIPCONSOLE/Application+-+Config+-+Modules
  8. Architecture Checker Flow:
    1. If the app team has provided the information then configure the Architecture Flows

  9. Transaction Configuration (FERC):

    1. Entry point configuration / Data Entity configuration / End of transaction configuration

      1. Trace the transactions based on the entry and endpoints given on the rapid discovery report

      2. Validate the empty transactions under Incomplete transactions report which will help in the identification of missing links. Document any broken transactions and missing links in Confluence

      3. Create specific entry/endpoints for transactions which have not been identified in the Rapid Discovery Report 

    2. Review Transactions

      1. Verify if there are artifacts with high Data Element Types (DET) / Record Element Types (RET) values. If there are then check the objects with issues and remediate them - Use Snapshot indicator Large SCC count to identify large SCC group. (If the issue still exists, raise a support ticket)

      2. Check the code coverage i.e., validate that all artifacts are covered in the transactions - Use Snapshot Indicator Artifacts in transactions to validate the artifact coverage

      3. If there are a few artifacts which do not belong to any transaction, investigate if they are in scope of module definition

  10. Load Imaging and validate results .
  11. All Checks Passed: A list of checks are executed at this step to ensure the quality of results - if any check fails then it will lead to a exception review
  12. QA - Onboard phase:
    1. Review the Analysis results, entry and endpoints as defined in the transaction report, validate the smell test results justification, dashboards and delivery report as per the checklist
    2. QA checks to review the process followed so far and give the go-ahead to deliver the refined dashboard to the customer
  13. Imaging Discovery Report: ( PRRC and FENF)
    1. Upon the GO recommendation ,  the refined measurement and Consumption Report is delivered to the application team
    2. Extensions PRRC and FENF can be used for preparing consumption report
  14. Report for Expected Content of zip File : Take a screenshot of the delivered source folder structure .

Exit criteria

    • Imaging Discovery Report delivered to the customer

Deliverable

    1. Imaging Discovery Report (Sample Link) - Sample Discovery Service Report - v1.2.pptx
    2. Refined Measurement (Engineering and Health dashboard) 

3. Integrate

This phase is applicable only if there are customized measurement required by the application team based on the identified use case, after the onboard phase. If there are no customization required by the application team then the results delivered as part of onboard phase are the baseline results.

AIP Product Documentation

Entry Criteria

    1. Refined measurement delivered to the application team
    2. An additional requirement from the application team

Process steps

  1. Additional Inputs
    1. Check if there are additional inputs provided by the application team to make any adjustment in the Assessment model, Dashboard and Action Plan 
    2. Inputs for Automation of rescans
  2. Customization of Imaging results : 
    1.  Create use case based views 
  3. Adjust Automation for Rescans
    1. Validate the Automation set up during the previous iterations
    2. Check the Automation Adjustment needed as per Customer's requirement and make necessary changes
  4. Report for zip content for the next release
    1. The report should be prepared in order to get the same format of zip files in the next releases also
    2. It should contain the folder structure which we have got during the onboarding phase
  5. QA - Integrate phase
    1. Review the dashboards and updated delivery report as per the checklist
    2. PQM has to review the process followed so far and give the go-ahead to deliver the refined dashboard to the customer
  6. Baseline Measurement
    1. Upon the go recommendation of PQM, deliver the baseline measurement and provide updated delivery report/preliminary findings to the customer

Exit criteria

    • Application baselined in Imaging console and automated for future rescans ( If applicable )

Deliverable

    1. Final Imaging Discovery Report

Support Process:

  • As explained in the documentation, only approved workarounds can be applied in Agile onboarding approach and to get an approved workaround, we need to raise a Zendesk ticket and ensure that the subject of the ticket is prefixed with [AGILE]. 

Extensions Needed in Agile Approach:

  1. Extension for Rapid Discovery Configuration - FERC

  2. Extension to identify potential nuggets in the analysis results - FENF

                  Link to download - Click here

Product Extensions Needed in Agile Approach:       

  1. Automatic Links Validator - AALV : This extension will automatically validate DLMs

       2. Report Generation for Consumption - PRRC

Training Material: