V4.0

Process to Onboard an Application

Introduction

This document details CAST's Field Onboarding Process along with the checklist templates used.
Pre-requisites for on-boarding:

• CAST Application Intelligence Portal (AIP) is installed
• Supported Technologies/Frameworks
• Extension to be used if required
• Application Intelligence Administrator AIA has access to CAST Virtual Machine (VM)

The following topics are out of scope for this document:

• Rescan and rescan automation
• Unsupported technologies
• Clean-ups and retention

Target Audience
AIA
Application Manager

Process Flow

Related processes and checklist templates

1. Qualification Phase:

• Template – Service Engagement Sheet

2. Acceptance Phase: 

• Template - Source Discovery
• Architecture Discovery Process
• Template - Architecture Discovery Review checklist

3. Analysis Phase:

• Analysis Configuration Phase: 
  
  • Template - Analysis Log Book
• Transaction Configuration Phase
• Calibration Phase:
• Reconciliation Phase:
  • Template – Automated Function Point (AFP) Configuration/Calibration

4.  Delivery Phase:

• Template - Dashboard Validation Page
• Template - On Boarding Release Audit checklist

Qualification Phase

As a pre-condition 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 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 show-stoppers such as the use of unsupported technologies or frameworks and any potential customization that may be required to accommodate exceptions.

Official Documentation

AIP Product Documentation for Application Qualification:

1. Application Qualification process overview: http://doc.castsoftware.com/display/DOC82/1.3.+Application+Qualification

Entry Criteria:

1. Application identified to be on-boarded onto CAST AIP
2. Application Architecture Context Diagram (See appendix)
3. Existing Application Detail Design documents if any e.g. Sequence Diagrams
4. Access to Build Manager and/or Source Control Manager (SCM) details for source code and database connection details available
5. Application Delivery Portal (ADP) / Technical Survey to be completed (See appendix)

Process Steps:

1. Kick-Off meeting
   1. Meet with Application Team to understand architecture of the Application
   2. Confirm application boundaries and validate source code completeness
   3. Module Definition
   4. Update ADP / Technical Survey
2. Technology info in ADP
   1. Verify app team contacts
   2. Verify Technology Details and Questions
   3. Verify if Architecture Context Diagram and Transaction Code Flow Document has been uploaded
3. Front Office Qualified
   1. Front Office resources will validate above steps 1 and 2 are complete.
   2. Front Office resources will confirm using the Delivery Manager Tool (DMT) that source code delivery is complete including all dependencies.
   3. Front Office resources will complete the qualification and deliver the application to Back Office for next steps
4. Setup Application Intelligence Center (AIC) Portal – Registering new domains and applications in the CAST AIC Portal. This step is performed to trigger the on-boarding and first-time analysis of a new application with CAST AIP
5. Service Engagement Sheet – This sheet must be completed to define the scope of the Application
6. DMT Package
   1. In case of extensions, ensure it is installed –http://doc.castsoftware.com/display/DOC82/Managing+extensions
   2. Package the source code using CAST DMT to prepare the code for analysis by CAST AIP. Refer to Deliver Application Source Code for more information.
   3. Deliver Application Source Code: http://doc.castsoftware.com/display/DOC82/1.4.+Deliver+the+application+source+code+version
   4. DMT Packaging Alerts:  
      http://doc.castsoftware.com/display/DOC82/DMT+-+Package+Content+tab+-+Packaging+alerts

Exit Criteria:

1. All details and documents received and verified
2. Complete application source code and database are delivered with dependencies

Deliverable Outcomes:

Application is configured in DMT.

Best Practices for DMT:

1. Library files for Java technology, and assemblies for .NET technology (application specific and 3^rd party framework) should be packaged separately. For further details refer to http://doc.castsoftware.com/display/DOC82/DMT+-+Folders
2. Include Discoverer in DMT plugins
3. Exclude test files/folders/projects and generated code - http://doc.castsoftware.com/display/DOC82/DMT+-+Use+Regular+Expressions

Acceptance Phase

This phase marks the source code delivery completeness from the Application team. It describes guidelines on delivering application source code, packaging source code with CAST DMT, validating alerts, completing the source code discovery before proceeding with analysis.

Official Documentation

AIP Product Support Documentation for Application Acceptance:

1. Validate and Accept the Delivery:

http://doc.castsoftware.com/display/DOC82/2.1.1.++Validate+and+Accept+the+Delivery

Entry Criteria:

Qualification is completed

Process Steps:

1. DMT Alerts
   1. Resolve ALL DMT errors, alerts and warnings per DMT Packaging Alerts
      1. Any alerts related to missing code need to be documented, and reported back to application teams for code delivery improvement  
         (http://doc.castsoftware.com/display/DOC82/Technology+Delivery+Instructions)

1. 1. Repackage the code.
   2. Repeat Steps a and b until all errors and warnings in the DMT log are resolved
2. Source Code Accepted – Deliver the source code and set as Current Version
   1. Field Extension Step: Set the application Source Code Accepted Phase in ADP
3. Application Discovery
   1. Architects review the source code and refers to the design documents provided by application Subject Matter Expert (SME).
   2. Initial dry analysis is completed in this phase.
   3. Complete the App Discovery and produce the Application Discovery Document & Consultant Help Document. Include discovery questions, if any, in the Discovery Document to cover the Functional view of the application
4. App discovery Acceptance
   1. Peer Reviewer reviews documents for this phase and updates the checklists
   2. In case of 'Good to go', the App Discovery Document is submitted to the client. If not, it will go back to Step 3a
   3. Receive signoff of Application Discovery Document from the client completing the initial acceptance and verify the following items:
      1. Entry & Exit Points
      2. All the relevant flows
      3. Additional source code delivered (if any); any changes will go to Step 3a
5. Handover to AIA – Conduct a handover meeting with Tech Lead/Consultant and Solution Design (SD) Team (if required based on the engagement/project and SD's involvement) to share knowledge on the application and discuss CAST constraints

Exit Criteria:

1. Receive signoff from the Application Team
2. Application Discovery Document completed
3. Consultant Help document completed

Deliverable Outcomes:

1. Approved Application Discovery Document
2. Handover to AIA

Analysis Configuration Phase

The process below provides an overview of the Application Source Code Analysis process with CAST AIP. It consists of two phases: Analysis set-up and Analysis Execution. An optional, although strongly recommended Analysis Automation phase, may follow.

Official Documentation

AIP Product Support Documentation for Application Analysis:

1. Application Analysis Process with CAST AIP: http://doc.castsoftware.com/display/DOC82/2.+Application+Analysis+Process+with+CAST+AIP

Entry Criteria:

1. Availability of technical knowledge of configuration
2. Application Discovery, Consultant Help Document, and Handover Document to understand application scope, technology, and extensions (if any)
3. Current version should be set during the Acceptance Phase
4. Source code acceptance - Error/alert-free packages and all the exclusions (test code, 3^rd party frameworks, etc…) should be completed during DMT packaging

Process Steps:

1. Set-Up Environment & Analysis configuration with respect to ADP and source code discovery
   1. Source Code "File Adjustments" (Optional)
   2. "Pre-process" Source Code (Optional) - In some situations, the source code cannot be parsed and must be pre-processed. 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. Repackage DMT (Optional) if above steps are applicable – Application code must be repackaged to reflect changes
2. Non-standard technology – In case the technology is not supported but in scope, do a feasibility study to support through a custom development; or do a post feasibility study to exclude it from the technology boundary
   1. If the application scope includes non-standard technology, install a supporting custom Extension as needed and import into the Assessment Model (optional)
3. Verify Framework Settings
   1. Select correct versions of technologies and frameworks
4. Setup Cast Management Studio (CMS)
   1. Choose an Environment Profile if needed
   2. Configure include/classpaths according to the technology
   3. Enable User Input Security if it is within the scope of the analysis
5. Run CMS Analysis - http://doc.castsoftware.com/display/DOC82/CMS+-+Run+analysis+only
6. Log validation – Perform analysis log validation
   1. Follow the troubleshooting process to remediate warning and errors using different platforms (if any)
   2. Document the log validation results: Number of alerts, type of alerts, and tickets raised (if any)
7. Resolving warnings and errors
   1. If no warnings or errors exist at the end of Analysis, proceed to Step 8
   2. If warning or errors are found, return to Step 4 to correct them
8. Results validation – Perform inventory validation
   1. If the delivered code matches the analyzed code (unless excluded because it is out of scope), proceed with following steps a, b, and c
      1. Validate Dynamic Links / Dynamic Link Rules creation – Document the number of Dynamic Links.
      2. Parameterization – Document the number of Parameterization Steps
      3. Module Definition
         1. Set up the module content according to the client's requirement
         2. If no recommendation, retain the Full Content
      4. In case of any mismatch, check if any paths have been missed in the analysis units. If yes, apart from below 4 steps, analysis configuration and analysis units must be re-visited
         1. Adding dependencies
         2. KB Update Assistant
         3. Ref Finder
         4. Return to Step 4

Exit Criteria:

1. Log validation
2. Inventory validation
3. Post-analysis validation

Deliverable Outcomes:

1. Error-free analysis results along with inventory and log validation

Best Practices:

1. Add Class Paths, Include Paths, Working Folders, and Header Files
2. Select the appropriate Integrated Development Environment (IDE) for each technology
3. Retrieve Macro list from source code
4. Use only supported versions of extensions (Alpha or Beta not supported)

Transaction Configuration

The CAST Application Intelligence Platform enables users to measure Function Points from the source code of an application. CAST AIP measures the functional size of an application using Object Management Group (OMG)-compliant Automated Function Points.
However, Function Points is a functional size measure that is based on the application's specifications and requires knowledge of the intent of the application's designers ("primary intent" mentioned in the OMG-compliant Automated Function Points Counting manual). So, to make the measure possible, Function Point (FP) Experts and Consultants need to calibrate the initial automatic count made by CAST. Calibration includes removing technical and temporary objects from the list of Function Points counted, aggregating, and splitting several function points into one and changing the type of the Data or Transactional Functions.

Official Documentation

AIP Product Support Documentation for Transaction Configuration:

1. How to configure TCC: 
   http://doc.castsoftware.com/display/DOC82/TCC+-+CAST+Transaction+Configuration+Center

Entry Criteria:

1. Analysis results are validated, and a snapshot is available
2. Transaction Configuration Kit is available

Process Steps:

1. Deploy Transaction Kit – Standard Entry and End points will be available from the technology specific configuration kit. It is available for download from the following link (Link to download Calibration Kit)
2. Entry point configuration / Data Entity configuration / End of transaction configuration
   1. Trace and save all the transactions (identified in Consultant Help Document) in Enlighten
      Note: There should be a one-to-one mapping between the Enlighten Diagrams and the flows identified in the consultant help document.
   2. Validate the empty transactions. Document any broken transactions and missing links in Confluence
   3. Create specific rules for transactions which have been identified in the Application Discovery Document but not configured in TCC through the Transaction Kit. These rules include configuration of Transaction Entry Points, End Points, and Data Entities
      1. Verify with the Technical Lead if the new transactions can be added
      2. If yes, communicate this to the Architect and get a sign off
      3. Document the transactions properly and provide a feedback in the standard AFP Configuration/Calibration page
3. 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. If the issue still exists, raise a support ticket
   2. Check Data Production Tracker (DPT)/ADP to see if there are any recommendations for changing default FP values
   3. Check the code coverage i.e., validate that all artifacts are covered in the transactions
   4. If there are a few artifacts which do not belong to any transaction, check if they are in scope of module definition
   5. Generate and share the list of artifacts which are part of module definition but are not covered in transaction with the Tech Lead. Take the necessary remediation steps suggested by Tech Lead
   6. Share the list of artifacts with Architect obtained from step e
   7. If the code coverage is in an acceptable range, document the action details taken in the above steps
4. Transaction Completeness
   1. If empty transactions exist, follow the steps below:
      1. If this is a configuration issue, go back to analysis configuration
      2. If this is a standard framework supported by CAST, raise a Support ticket
      3. Add links between objects that are not recognized by AIP out of the box through the Reference Pattern process, Knowledge Base (KB) update queries, and supported extensions to create missing objects/links
      4. Once the link is completed in Enlighten, compute in the Transaction Configuration Center (TCC), validate the flow, and continue with activity in Step 2
   2. Code coverage must be in the acceptable range

Exit Criteria:

1. Document all the configuration and code coverage details
2. Launch snapshot

Deliverable Outcomes:

1. Transactions configured for the Application

Calibration and Reconciliation

The main aim of the CAST Transaction Configuration Center is to allow you to calibrate objects with regards to their Function Point size - in other words, you can choose how an object is interpreted by the CAST algorithm and thus how its Function Point size is derived (or you can manually set a Function Point size for an object), instead of having to use the default CAST configuration, which may not always be appropriate. This section provides information about how you can do this using the CAST Transaction Configuration Center. 

Official Documentation

AIP Product Support Documentation for Transaction Calibration:

1. Transaction Calibration:
   http://doc.castsoftware.com/display/DOC82/TCC+-+Calibrate

Entry Criteria:

1. TCC configuration is done
2. Analysis results are validated
3. Standard calibration kit is used
4. New snapshot has been computed

Process Steps:

1. Deploy Calibration Kit – download the latest function point calibration kit for your version of AIP from the CAST Extensions link. Apply the kit as described in the documentation. This will calibrate function point counts by removing or ignoring redundant transactions, and unifying duplicates.
2. Rule based Ignore / Rule based Deletion / Rule based Grouping / Rule based Splitting – manually check the transactions in TCC for further calibration opportunities.
   1. Review the Entry & End Points list to avoid duplicate and redundant transactions
   2. Make sure the Data and Transaction filters are not ignoring, deleting, grouping or splitting wrong transactions. If there are such transactions, add them as exceptions by modifying the filter functions
3. Rule based value / Rule based type
   1. Filter grouping rules based on naming, types, inheritance, and free definition
4. Run a Preliminary Snapshot
5. Manual Grouping / Manual Splitting / Manual type Adjustment / Manual FP Adjustment (Optional)
   1. If the transaction configuration requires further calibration, manually make adjustment

Exit Criteria:

1. Document the configuration
2. Launch a snapshot

Deliverable Outcomes:

1. Transactions calibrated for the Application

Delivery Phase

The Delivery phase provides guidelines on how to run a snapshot, deploy dashboards, and hand over the results to the customers for consumption.

Official Documentation

1. AIP Product Support Documentation for End User Guides (installing dashboards):
   http://doc.castsoftware.com/display/DOC82/End+User+Guides

Entry Criteria: 

1. Function point configuration is completed
2. Module definitions are properly configured in Analysis phase
3. Scope and result expectations are verified
4. If there are any specific credentials for Engineering Dashboard, it should be frozen during project phase
5. Custom reports should be decided during the acceptance (if any)

Process Steps:

1. Run Baseline snapshot
2. UI validation
   1. Launch dashboard either via CMS or deployed Web Archive (WAR)
   2. Validate if Engineering Dashboard pages are displaying data correctly e.g., Transaction-wide Risk Index (TwRI) page, Risk Indicator pages, Critical Violation pages, Compare Version pages
   3. If there is any issue with the above step, follow the Troubleshooting Process
3. Inventory Validation
   1. Check the Lines of Code (LoC) per modules and validate with the inventory
   2. Validate the number of files, classes, tables, and artifacts per technology. If the numbers are not as expected, follow the Troubleshooting Process
   3. If this check is for maintenance, validate the variation in data from Quick Access view
   4. If there are lot of unexpected added/deleted artifacts in the above step, follow the Troubleshooting Process to fix the issue. If the issue is due to folder structures, reject the delivery and start from DMT phase
4. Engineering Dashboard Metrics validation:
   1. Check the number of critical violations and validate few of them to see if there are any false positives. If there is any false positive, follow the Troubleshooting Process
   2. Check the other metrics such as Technical Debt, Cyclomatic Complexity
   3. If this process is for maintenance, check the evolution
   4. FP count must match with FP count in TCC
5. Analytics Dashboard Metrics validation:
   1. Consolidate Engineering Dashboard with Application Analytics Dashboard (Analytics Dashboard) if Engineering Dashboard can't be navigated to from Analytics Dashboard
   2. Validate that the numbers displayed on Analytics Dashboard must match with Engineering Dashboard
6. Delivery Report Generation
   1. Delivery reports must be prepared once all the validations are completed
   2. Prepare and document custom reports in Confluence (if any)
7. Maintenance documentation
   1. This document groups together all miscellaneous backup, optimization, and maintenance documentation related to the CAST Storage Service
8. Automation
   1. This page describes how to install and use the CAST Analysis Automation Application Programming Interface (API) to automate the process of analysis with CAST AIP

Exit Criteria:

1. All validations completed must be properly documented and the reports must be uploaded in Confluence

Deliverable Outcomes:

1. Application onboarding completed.

Troubleshooting Process

Entry Criteria:

1. Errors/warning/alerts are encountered in the CAST tools (DMT, CMS, Enlighten, TCC)
2. Global Application Intelligence Center (GAIC) troubleshooting guide

Process Steps:

1. When an error or warning is encountered:
   1. Refer to the GAIC troubleshooting guide for CAST tools which gives information about:
      1. Which errors/warnings/alerts can be ignored?
   2. Remediation, resolution, and workaround details
      1. Refer to Technical Knowledge Base (TKB) for known issues and limitations
      2. Refer to Zendesk for similar issues faced
      3. Raise a Support ticket
      4. Consult Product Management (PMT) or the Research and Development (R&D) team
      5. Consult SME if recommended by Support or PMT

Exit Criteria:

1. Verify if the above steps have solved the issue

Deliverable Outcomes:

1. All errors, warnings and alerts are remediated

Best Practices:

1. Refer to the Zendesk for Solution Delivery best practices

Consumption Tools

Engineering Dashboard

CAST Application Engineering Dashboard (AED) is the technical dashboard to review application analysis results. Engineering dashboard lets you drill down into the violations down to the violating object list and view non-compliant source code. Here are more details about application engineering dashboard.
http://doc.castsoftware.com/display/DOC82/CAST+Application+Engineering+Dashboard+-+CAST+AED

Analytics Dashboard

CAST Application Analytics Dashboard (AAD) is core AIP tool for consuming portfolio level analytical information, Target uses of AAD are portfolio management and application management group. AAD provides analytical information, trending and consolidated information of all applications in the portfolio. Here is the cookbook for various functionalities AAD offers
http://doc.castsoftware.com/display/DOC82/CAST+Application+Analytics+Dashboard+-+CAST+AAD

Report Generator

The CAST Report Generator is a standalone solution for automatic generation of reports based on CAST AIP results. The solution provides the opportunity (for example) to prepare and automate assessments for each new version of application analyzed with CAST AIP. Documents are based on Microsoft Office templates and they can be modified to prepare a specific template to meet a particular use case or to comply with a company format. After generation, the resulting document can be further adapted if necessary.
The Report Generator is based on the CAST RestAPI meaning that CAST AI Administrators and project managers alike can use the tool. Here is the link for more information on CAST Report Generator.
http://doc.castsoftware.com/display/DOCCOM/CAST+Report+Generator

Advanced Analytics Report (AAR)

Overview

Target audience - Business Analyst and Key User who are interested in using CAST results analytic as part of advanced data analysis reports that may blends CAST metrics and own data.
Summary - This document provides installation an deployment instruction of the back end solution and the configuration of automated data-feed and core set of standardized views. Report templates based on this solution may be available as separate filed extensions.

Key Benefits

Enabling a new way to consume CAST analytics - Organizations can use the existing talent base and tools to rapidly discover new business insights from CAST Analytics, build ad-hoc dashboard and report that better cater to specific needs and goal of IT management and business users. Create blended report that correlate and links internal metrics from internal ERP, financial and production monitoring systems to investigate date, exposes correlation and interdependency and inform fact based decision.
Efficiency with easy governance: no need for unnecessary ETL cycles and schema maintenance activities, but still ensure governance through easy-to-deploy granular access controls. Even the most complex AAR views can be developed and deployed to users without complex or lengthy data preparation and regardless of input data structural complexity and organization.

DATAPOND: built upon REST to create / update data tables in a report manner

Use Cases

• Self-service raw data exploration: You can explore and analyze CAST raw data sets of any complexity as they are produced, using familiar Business Intelligence (BI) tools. You can now use SQL to natively query and manipulate complex/semi-structured CAST Rest API JSON data. Blend Rest API query with traditional CAST storage and dashboard services SQL query to gain new insights and more effectively determine what is useful and what is not, without spending lots of IT cycle.
• Business intelligence on CAST analytics:  Specialized ANSI SQL extensions allow for instant flattening and native querying of even the most complex nested data. You can perform secure, concurrent, low latency SQL analytics your IT data. You can do instant joins across CAST and your own data to create blended data report and dashboard that highlight correlation and interdependency between CAST analytics and your own business and operational metrics. 

Description

AAR solution is built upon Apache Drill and is fundamentally a query engine that support a variety of NoSQL databases and file systems, including HBase, MongoDB, MapR-DB, HDFS, MapR-FS, Amazon S3, Azure Blob Storage, Google Cloud Storage, Swift, NAS and local files. A single query can join data from multiple datastores. For example, you can join Rest API JSON response, to text file output to a PSQL query to a Central Schema to a user profile collection in MongoDB.
Leveraging Drill JSON data model AAR support queries on complex/nested data as well as rapidly evolving structures. AAR/Drill provides intuitive extensions to SQL so that you can easily query complex data.
AAR queries results in virtual datasets (views) that can be mapped into BI-friendly structures which users can explore and visualize using their tool of choice.  Business users, analysts and data scientists can use standard BI/analytics tools such as Tableau, Qlik, MicroStrategy, Spotfire, SAS and Excel to interact with CAST Rest API JSON response and/or SQL response (and any non-CAST non-relational datastores) by leveraging Drill's JDBC and ODBC drivers. 
A standard set of core views that combine selected CAST outputs are deployed and configured as part of the initial installation and ready to use in any of the sported data visualization solution.

Cast2Jira

The CAST AIP Action Plan to Jira Jenkins plugin is designed to allow the user to export the contents of the CAST Engineering Portal (CEP) Action Plan to Jira as a Jira ticket. This plugin connects with CAST Database and extracts action items based on priority of the action items and uses Jira rest API for creating the tickets.
Below is the documentation to configure and use the plugin

Appendix

Template – Qualification Phase

1. Service Engagement Onboarding Template

   Service engagement Sheet - V1.3
   #	Service engagement question
   1	Documents
   	·         Technical Survey
   	·         Others if available
   2	Offshore deadline (specify the date)
   3	Client presentation deadline (specify the date)
   4	Split by Version – specify versions and sequence
   5	Client constraints and background - support for estimation
   	·         Explain constraints & background
   	·         PS project for booking
   6	Primary regional contact for front office validation and source code extraction support
   7	Do you want us to publish the results to send the dumps via File Transfer Protocol (FTP)?
   8	Source code
   	·         Location
   	·         Current account details
   9	Analysis type
   	·         Pilot
   	·         Initial analysis service
   	·         Recurring analysis service
   11	Cast AIP version
   12	Aggregation type
   13	Do we need to enable Security Flow Analyzer (Y/N)
   	·         Specify sanitation methods if available
   14	Do we need to enable escalated links (Y/N)
   15	User Designed Module (UDM) design (mark your choice and provide the basic)
   	·         Technology split
   	·         Functional Domain split
   	·         Other, please specify
   16	Transaction configuration
   	·         Required Y/N
   17	Snapshot labeling
   	·         Default will be the execution date
   18	Extra Extra Large (XXL) information
   	·         Required Y/N
   19	CAST Architecture Implementation
   	·         Required Y/N
   20	Diagnostics update required
   	·         Specify what needs to be changed
   21	Specific FO validation points that are important to know
   22	Comments/other inputs

2. Service Engagement Onboarding template

3. Technical Survey

Latest version is available at  Technical Survey#Technical_Survey_LIGHT

Template – Acceptance Phase

Source discovery

1. Source code comparison checklist with drop site – The below checks must be performed on all delivered source files provided by the Application Team before configuring DMT packages
   
   

   #	Check	OK?	Justification for Exceptions
   1	Match the provided source code at drop site with the Technical survey and architecture document (look for the associated technology file ext.)
   2	Map the high-level module mentioned in the architecture document with the provided source (one way is to look for matching folder names)
   3	Cross check the framework related files (e.g. Struts) mentioned in the Technical Survey with the provided source
   4	Folders with release names or branch names (like Trunk, dev, head, svn) should not be part of source delivery. If it they exist, cross check the actual structure of source code with Client (if required) or remove/rename before packaging
   5	Folder name must not contain the version number as this will cause added/deleted objects in rescans. Folders should be renamed without version numbers and both folder structure and naming conventions must be maintained in all future rescans
   6	In case of duplicate code (e.g. if project name is different but the code is same, or if there are any backup folders), verify findings with the Client.  Duplicate code should be removed after client confirmation
   7	Take backup of drop site source code at: Source: R:\Sources\[App Name]\[Version]Source_Provided\Source DB: R:\Sources\[App Name]\[Version]Source_Provided\DB
   8	Verify that project files are delivered (e.g. csproj are delivered in .NET, project files or .pom files in java)

2.  Source code comparison checklist with DMT Package – Below checks must be performed during DMT packaging

Onboarding Checklist

Ensure that the DMT source packaging has been configured correctly as per the technologies in the Application. For further details on how source code is delivered in DMT for each technology, refer to http://doc.castsoftware.com/display/DOC82/Technology+Delivery+Instructions

3. DMT report

Attach the report generated by DMT which lists file counts and total size per extension. The information from DMT can be used to fill the below table

4.  Technology & Framework Analysis Approach

Following approaches can be implemented to configure an application for analysis:

• CAST AIP - Analysis supported by out of the box CAST analyzers
• Product Extension - Analysis using extensions listed at http://doc.castsoftware.com/display/DOCEXT/CAST+AIP+Extensions+Documentation
• Field Extension - Analysis using non-standard technologies. Refer to extensions listed at CAST Extend
• Custom configuration - Custom extension, Environment Profile built depending on specific application
• Technology not supported for analysis

Supported Technologies can be found at http://doc.castsoftware.com/display/DOC82/Supported+Technologies

5. Source Code Validation Summary 

6. Architecture Discovery Process

This section is detailed in the presentation below (Architects_User_Document.pdf).

7. Architecture Discovery Review checklist

Quality check to ensure the completeness and correctness of the Architecture Context Document

Template – Analysis Configuration Phase

Analysis Log Book

1. Open Issues/Questions
   This section contains question/issue from the Source discovery phase till the analysis is completed. AIA working on the analysis has the responsibility to log the questions and update status whenever there is a resolution / response.
   Risk in below table can be one of the following:

• • Blocking - Something we cannot proceed with
  • Critical - We can move but will impact the analysis results
  • Low - Can be ignored - little impact of results but need confirmation

2. Application Discovery Handover

For application architecture details, refer to the Application Discovery document, Consultant Help Document, and Client approval email in the AIC tracking page for the application

3. Pre-analysis Checklist

Below mandatory checks should be performed before and after an analysis for all versions. Once checks are done, state status and add comments when needed.

4. CMS setup validation (QC2)

*  Analysis can be started only when QC2 is passed.

5. Assessment Model Settings (based on customer requirement)

 6. Analysis Details

7.  Log Validation 

In case of multiple runs, please make sure to update the last run details
Rationale: CAST Analyzer reports warning and error through the generated .castlog files. However, log files could be tedious to read. Log manager inserts all entries in a table, so instead of reading the logs, we can count the number of most important messages in that table. A difference in the count between V2 and V1 (previous) is an indication of the validity of the analysis.  If source code size increased by a little (LoC), and count of error messages increased a lot, this is a gap which must be investigated, and is worth investing time on.  If increase in source code size and number of error messages are in line, then this is a waiver to bypass precise checks, and hence save time during the reanalysis.
Summary of Warnings/Errors 

8.  DLM Validation  

In case of multiple runs, please make sure to update the last run details. Use Analysis Operation Portal (AOP) to obtain the DLM report to verify DLMs

9.  Boundary Definition

In case of multiple runs, please make sure to update the last run details

10.  Analysis results validation (QC3)

11.  Backup

Template – AFP Configuration/Calibration Phase

1. Entry Points

   #	Type of entry point	object Type	Description*
   1	Ex: jsp		Why this choice?

   *For standard Entry points, mention as "Standard"
   
   

2. End Points / Data Function

3. Specific Links added / Content Enrichment

4. Transaction sample

*Order, Flow Pattern ID, and Objects in Enlighten Print should match with Architect document (Consultant help document)

5. Analysis Execution

6. Smell tests

Refer to the documentation to get details of the smell tests (https://doc.castsoftware.com/display/FBP/Offline+Smell+Test+-+OST):

7. Transaction Completeness check 

Run the queries at Transactional Function Completeness page and attach the collected data.

8. TCC configuration/results validation (QC4)

9. Backup

10. Calibration Summary

If a standard calibration kit (i.e. data and transaction filter SQL query) is used, note the version used or the location from where it is picked. Please inform respective owner (PMT/SME) when there is a customization done on the kits

11. Calibration Validation (QC5)

Template – Dashboard Validation Page

1. Inventory Validation

If App Compare is not used, then retrieve the number of files received from DMT Package Content tab, else use query to retrieve both the details

2. Dashboard Validation -  Validation Summary

3. Delivery Reports

Attach all reports to be sent to the customer

4. Dashboard Validation Checklist (QC6)

5. House Keeping Actions

Template – Onboarding release audit checklist

1. 1. House Keeping Actions

      #	Auditor	Date	Referenced	Time taken	Auditee	Overall Feedback
      1	<Auditor Name>	<Date of Audit>	<What references you used to conduct this Audit>	<Time taken>	<Auditee Name>	<Go / No Go)

2. GAIC Quality Checklist - Onboarding

Backup Details (Manual)