Mobile Application

To develop and publish a Mobile App, review the Software Developer Requirements page for applicable DevOps, Usability, Corporate and Security requirements. Follow the process steps below:

1. SQA Intake Meeting:  Project Manager working with the Software Developer (if available) starts the EPRI Mobile app development process by requesting an SQA Intake Meeting (Jira Portal Ticket #1) stating “Mobile App” in the ticket description. SQA will schedule an Intake meeting to review the mobile app development and support plans (e.g., Operating Systems, Platforms, etc.), process requirements (e.g., Apple TestFlight), SQA testing and InfoSec security scan requirements. Upon a successful intake meeting, SQA will approve the start of development.
2. Customer Experience (CX) Meeting: Project Manager working with the Software Developer submits the SWS Customer Experience (CX) Meeting Request (Jira Portal Ticket #2) stating “Mobile App” in the ticket description. The meeting will serve to:
   1. Align the mobile app development with the overarching EPRI mobile strategy
   2. Review the Mobile App customer/user experience
      1. Prepare a demo or mockup of the app to share via WebEx if possible 
      2. Review development requirements BrandEPRI (Internal EPRI URL), Web & Mobile UX v5.0, and EPRIMobileFrameworkv1.0.pdf
      3. Determine next steps for the project
3. Development: Software Developer codes the Mobile App (must meet all applicable requirements provided in the Software Developer Requirements page and SQA Testing Checklist) and submits the ADO Repo Request (Jira Portal Ticket #3). The source-code for your Mobile App must be regularly checked in to EPRI's On-Prem ADO version control system. When checking in source code to ADO there a few things to be aware of:
   1. The source code must be checked into the repository created and managed by SQA - this is the official repository.
   2. Repositories are for plaintext source code - checking in build artifacts and/or large binary files (e.g. DLL, EXE, etc.) is highly discouraged unless it is absolutely needed.
      1. If your application requires third-party dependencies those will be restored via your package manager (e.g. Nuget for .NET, NPM for JavaScript frameworks, Pip for Python, etc.).
      2. Storing large non-plaintext files in these repositories will increase the time it takes to clone and pull from them and is generally bad for version control best practices.
      3. When it's necessary to store large binary files (anything above 10 MB) Git LFS should be used.
4. Security Scans and InfoSec Approval: Software Developer must submit an ADO Repo Request and ADO Pipeline Request so that source code will be stored in the repository and Static Application Security Testing (SAST) scans can be automated in the pipeline. All Mobile Apps must be scanned by the SAST solution (Checkmarx is in use at EPRI). InfoSec must approve SAST scan results prior to SQA Submittal. Checkmarx generates a report detailing the vulnerabilities found ranging from Level 1 (Low) to Level 5 (High). The Software Developer must remediate any Level 3+ vulnerabilities found during the scan. InfoSec may also require that certain lower-level vulnerabilities be fixed at their discretion. 
   1. Scan Process:
      1. The SAST scan is run automatically when code is checked into the ADO repository, or the developer may run a manual scan of their source code in the Checkmarx platform.
      2. If new to the scan process, submit the Static Application Security Scan Onboarding Request (Jira Portal Ticket #3) for system access.
      3. Scan and perform remediation, if required.
      4. InfoSec's approval on a SAST Scan Approval ticket is a required prerequisite for the SQA testing submittal.
   2. To address the vulnerabilities:
      1. Scan, remediate vulnerabilities (if applicable), and rescan. When no vulnerabilities remain, request InfoSec approval via a Static Application Security Scan Approval Request (Jira Portal Ticket#4).                
      2. False Positives: Submit evidence in a SAST Scan Approval ticket that the vulnerability is a false positive and InfoSec will review the submission. Evidence can include screenshots or code snippets. InfoSec will review the evidence for each represented vulnerability type in question. Please use the same input values that the scanner used, where applicable.
      3. If the findings are not false positives and will not be addressed by the developer, send a remediation plan (see Remediation Plan Template) to InfoSec for approval within the SAST Scan Approval ticket. Please note this should only be completed after exhausting steps 1 and 2. The risks identified and plan within the document will need to be approved by project owner (accepting the risk) and IT stakeholders (TBD on case-by-case basis). 
5. Design Approval: Project Manager submits the SWS Design Approval Request (Jira Portal Ticket #6) stating “Mobile App” in the ticket description.
6. SQA Submittal & Usability Testing:  Project Manager submits the SQA Submittal – Software Acceptance Form (SAF) (Jira Portal Ticket #7) to submit the Mobile App for SQA Production (Final Acceptance) Testing and Apple TestFlight distribution (e.g., SQA, Internal EPRI, External EPRI). Prior to submittal, the Project Manager and/or Software Developer validates the Mobile App meets EPRI requirements (see Software Developer Requirements page).
   1. Be sure the submit the Mobile App Distribution Checklist information with the SQA Submittal. SQA will use that Information to setup the Apple TestFlight platform. 
   2. TestFlight is Apple's official platform for distributing Preproduction versions of the EPRI Mobile app to internal and external EPRI testers to gather feedback before the Production release on the EPRI Mobile App.

7. Distribution: Once the Mobile App has received all required approvals (e.g., Usability, Security Scans, etc.), the SQA team will release the Mobile App Production release from the Apple TestFlight platform, making it externally available to members and/or the public. The Mobile App Distribution Checklist received with the testing submittal will determine how SQA sets up the Mobile App distribution.