Resources

Submitted by adminuser on

The content below provides additional software development information and guidance.

    • PASS ("A")
      • Cause: No major problems identified (see below for examples of major problems). Minor problem examples: mislabeled toolbar button or plot axis; inconsistent screen capture in manual; or cannot print from toolbar but can using menu.
      • Action: Fix (or prepare a plan to fix) minor problem(s), review with the SQA Team, distribute the software.
    • NOT PASS (Reject)
      • Cause(s):  
        • Incorrect Copyright, Disclaimer notices
        • Non-standard, illogical GUI
        • Non-functioning icons or menu items (inactive options are not ghosted)
        • Insufficient User Manual or On-line Help
        • Insufficient Test Case (or Tutorial):
          • Lack of test cases (or tutorial)
          • Test case aborts and cannot be completed
          • Test case results do not match expected results
        • Combination of several problems with user interface, documentation, or on-line help
      • Action: Fix problem(s), resubmit software for acceptance testing.

      Regardless of the software product, it is essential that the source code be clear, readable, and maintainable over time.

      We expect our software developers to uphold professional standards, which includes writing source code that others can easily understand and maintain.

      Our expectations for source code readability are similar to those we have for other internal documents: proper grammar, correct spelling, and thoughtful organization using headings, bullet points, and spacing.

      Given the diversity of software products and development styles used at EPRI, it is neither practical nor particularly useful to enforce a single set of coding guidelines across all projects. Professional developers typically follow established coding standards, and we recommend reviewing these guidelines with your developer.

      If no coding standards are in place, it’s important to clearly communicate your expectations. Below is a basic set of high-level coding principles that apply regardless of programming language. For projects involving multiple developers—especially from different organizations—more detailed guidelines may be necessary to ensure consistency and collaboration.

      There are many well-established coding standards available, each suited to different contexts. Just as EPRI follows the *Chicago Manual of Style* for technical reports, supplemented with EPRI-specific guidance, you may choose to adopt a recognized coding standard as a foundation and tailor it to your project’s needs.

      An example of a programming language-agnostic coding standard can be found at https://12factor.net/.

      High Level Coding Expectations

      1. Use comments liberally. Remember that you might be asked to modify this code a year from now and you will probably not remember what you did.
      2. Use appropriate white space to make the code easy to read. For example, include blank lines between functions and other major blocks of code. Indent nested logic. Include spaces between operators. This is no different than what you would do when writing a technical report.
      3. Avoid excessively long lines of code.
      4. Name variables in a clear and concise manner.
      5. Avoid doing anything ‘tricky’ or ‘non-standard’. If it is necessary to do something tricky, clearly explain it in the comments.
      6. Code defensively to avoid mistakes in the future. Explicitly type variables where possible, explicitly cast variables. Test all branch conditions (e.g. include ‘else’ and default cases’). Check for and report all unexpected errors. Validate input arguments.

      Related Requirements

      There are additional requirements that can be assessed during code reviews:

      1. The software must not include any behavior that changes based on date, time of day, duration of use, or time since installation (e.g., “time bombs”), unless it is clearly disclosed in the end-user documentation.
      2. The software must not include any password functionality that persist passwords in plain-text.
      3. For export control reasons, it is recommended that the software avoid using any encryption capability, and instead rely on passwords and security provided by the operating system.
      4. The software must not include any “back-door” access

        A key tenant of modern software development is to engage your customers and end-users as early and as often as possible during the software development process. The level of customer engagement will vary depending on the software and the target user community. In many cases, it is adequate to describe the software to users via PowerPoint presentations or the occasional web-delivered prototype demonstrations. Software can also be provided to end users in a "Beta" pre-release format, though in many cases this happens too late to receive meaningful feedback from the users.

        When an active and interested user community exists, many software development projects can be improved by providing the actual in-development software to a select group of users so that they can test the software with actual customer data, and provide essential feedback in areas of compatibility, speed, user flow, ease-of-use, and general value of the software to actual user needs. EPRI of course retains the ultimate decision-making authority and responsibility regarding the final product, but this feedback helps assure that the final product will be valuable to the industry. 

        This approach is implemented in the following process and can be alternatively described as one element of "Agile software development or "rapid prototyping". In these approaches, rather than providing a "Beta" release of the software when the software is nearly complete, the software is provided to a select user community on a frequent and recurring basis, possibly as often as every 2 to 4 weeks during the core implementation phases.

        This process can be applied to both open source and closed source, licensed software development projects and is distinct from the typical EPRI Beta release process, which may still be used to provide the software to a wider set of users under a less restrictive licensing arrangement.

        Engaging external users in the development process is similar to requesting the review of a draft copy of any deliverable. However, providing early pre-release software to users comes with a number of risks and challenges that need to be carefully managed, including:

        • The users selected to participate need to be sufficiently engaged in the software development activity so that they can provide insightful feedback within a short amount of time. This is not the place for users who just want to observe the current status of the development.
        • Users need to be selected carefully, as those who do not understand the nature of the development might complain about the quality or direction of the software in public forums.
        • The selected users need to represent the larger industry needs, and give a broad, holistic recommendation for possible features and avoid making recommendations based on self-interest.
        • The selected users will need to be advised of the quality level of each iteration of the software. Even though the software may not be complete and not tested, users will expect the software to have a basic level of quality to maximize the use of their time and enable meaningful feedback.
        • Since the software is not fully tested, the selected users need to understand that the software could damage their data files or systems, and take appropriate precautions.
        • The users must not attempt to use the software for "production" purposes.

        Specific legal challenges include:

        • Participation in the software development and access to the pre-release software is not covered by the existing master license agreements that members have with EPRI, so additional legal language must be provided.
        • EPRI staff needs to maintain our research role for the benefit of the public, and not develop software under this process for a single member, nor be unduly influenced by a single member that detracts from EPRI's research independence.

        To address some of these challenges, the following process has been developed:

        1. The EPRI Project Manager, in consultation with the Program Manager, may determine that given the associated risks and costs, the project will benefit from a select group of users to participate in the development process. This determination may occur at the beginning of a project, or at some later time during the development of the project.
        2. When the users have been identified, participation in this process, including the selection of development group participants, requires Director approval (or designee). The request for approval and authorization may be made by a simple email exchange. The approval is valid for a single development iteration (i.e. final release of a version of the software).

          As of September 1, 2018, all EPRI Pre-production (e.g., Beta) interim software releases must contain a Pre-production Acceptance Splash Screen. Users need to be given the option to accept (e.g., "Accept" button) or reject (e.g., "Reject" button) the acknowledgement. If accepted, the application loads; if they reject the acknowledgement, the application closes. The words "you," "your," or "your organization" herein each mean the EPRI-funding organization for which you are acting on behalf.

          This version of [SOFTWARE] ("Program") is a pre-release, interim version distributed in advance of EPRI's normal distribution for the purpose of obtaining user feedback and is subject to the terms and conditions of your agreement with EPRI, including confidentiality obligations use restrictions, and export control obligations. You may not distribute the Program to or use it for the benefit of any third parties. The Program (including information, data or results generated by the Program) is an "EPRI Material" and may not be used for any purpose other than providing feedback to EPRI. Your right to use the Program will terminate as stated in your agreement with EPRI or upon release by EPRI of a subsequent version of [SOFTWARE], whichever is sooner.

          The Program may contain errors or problems that impact your ability to use the Program, the accuracy of results generated by the Program, or may harm your system. You should promptly report any difficulties in using the Program, including, but not limited to, errors in the Program, assembly and run problems and/or inadequacy of documentation. EPRI may decide, in its sole discretion, whether to incorporate your feedback into subsequent releases of the Program.

          Please direct any questions or feedback regarding the Program to [PROJECT MANAGER] at [PHONE] or [EMAIL].

        3. Prior to providing the initial interim release of the software to a development group member, the software must be checked by the EPRI SQA team. Subsequent interim releases will then be checked by the EPRI SQA team or other individuals designated by the EPRI SQA team. The scope of the review is:
          1. Does the software install / run on a computer other than the developer's computer (does not need to be a pristine environment)?
          2. Is the information provided to the users with this interim release clear to explain what the current state of the software is?
        4. The software will be provided to the member of the development group electronically via SecureShare from the EPRI Software Distribution Department (EPSC).

          Note: The software cannot be provided directly by a vendor to the member.

        5. Members will be asked to uninstall/delete the software once the development period has ended (as required by the license). In the case of web-accessed software, the web access will be removed.

          ECM Supplemented Submittal - Once you have progressed your ECM Submittal Workflow to the Step: "Perform SQA Receipt Evaluation and Place Deliverable in SQA Testing Queue", submit an ECM Supplemented Submittal ticket. This ticket facilitates the transfer of information from ECM to the SQA Software Development Portal on your behalf.

          Nuclear QMP Database Agreement Splash Screen - All Subscriber Websites  (SWS) from the Nuclear sector that utilize databases to collect member or 3rd party data must include either of the following:

          1. A splash screen with the Nuclear Database Agreement language at the start of the application such that users will be aware of the agreement.
          2. The addition of the Nuclear Database Agreement language agreement to the websites landing page.

          Nuclear Database Agreement splash screen:

          Software Title (Software Acronym) Version #
          Electric Power Research Institute (EPRI)
          3420 Hillview Ave.
          Palo Alto, CA 94304

          Copyright © 2025 Electric Power Research Institute, Inc. All rights reserved.

          EPRI appreciates the support of the nuclear industry in establishing the [name of database] (the "Site").

          The words "you," "your," or "your organization" herein each mean the EPRI member organization for which you are acting on behalf.

          From time to time, EPRI publishes the results of its research in the form of technical reports, databases and other products in accordance with its research and reporting policies. By using this site, you certify that any data you provide ("your data") has been collected and submitted in accordance with standard industry practices and you are authorized by your organization's policies to provide your data for the following purposes:

          • Publication of your data and related information to other users of the Site
          • Use of your data by EPRI and EPRI contractors to perform research
          • Publication of research based on your data to EPRI members and/or members of the public in accordance with EPRI's policies

          Information provided via this Site may be viewed by other users; thus, you should not provide anything of a proprietary or sensitive nature.

          All information and other materials provided to you through the Site are "EPRI Materials" in accordance with the terms of your organization's master agreement with EPRI and shall be treated as provided therein, including the obligation to hold such materials in confidence.

          Should you have any questions regarding, or objections to, EPRI's use of your data or your obligations with regard to the EPRI Materials, do not proceed to the Site and contact [Project Manager] directly at [telephone] or [email].

           

            • Executable Computer-Based Training (EXE CBT): EXE CBTs are EPRI training products that EPRI uses to assist with technology transfer. CBT's are developed in either Adobe Captivate, Articulate Storyline or Articulate Presenter using EPRI Templates.
            • Spreadsheets
              • A Microsoft Excel spreadsheet that contains Macros, hidden rows and columns, protected functionality, and complicated formulas is considered a Complicated Spreadsheet and must follow the SQA process. 
              • A Microsoft Excel spreadsheet that contains formulas and trivial scripts, if it does not provide a user interface and no Macros, hidden cells, rows or columns (all calculations can be easily viewed and verified) is considered a Simple Spreadsheet and does not need to be tested by SQA. The spreadsheet should be tested by staff not involved in the development.  The deliverable distribution is processed by the Publications Department.
            • Desktop Application: Software that is installed the end user's computer. This includes traditional compiled software developed in a programming language like C++ or code developed in a scripting language like Python. In many cases, this software includes a graphical user interface, but this category also includes command-line computational tools run on the desktop.
            • Server/Enterprise: Software that is intended to be installed on a server in the enterprise. Typically, these are installed by the end user's IT staff. The software might not have a user interface other than installation and administrative functions, or it might be a web app that runs on the member's Intranet. This category does not include client workstation use of a corporate database, which would typically be categorized as Desktop Software.
            • Software Implemented via a Commercial Software Platform: Software that is created inside another commercial tool. A user interface is created using the features of the commercial tool, such as Microsoft Access, Microsoft Excel, or MATLAB. In general, the end users will need to procure a specific version of the underlying tool in order to use software provided.
            • Software Extension: Software that does not operate by itself, but is only useful when used in combination with other software tool. For example, this might include source code for a FORTRAN subroutine that describes material behavior that will be used by a finite element package. Or it might be a dynamic link library (DLL) that can be used by a thermohydraulic tool. Or it might be a database that is called by one or more EPRI software deliverables. This category is very similar to products developed on a commercial platform, but in this case the software usually has no user interface, has no immediate standalone use, and might not be limited to a single commercial tool.
            • Subscriber Website (SWS): Any software that runs through a web connection. This type includes externally-facing web sites, regardless of host location, that will be accessed by members. It also includes web services, which are "subroutines" without user interface that are accessible to other programs via the web. Some web sites might be content-only but still fall into this category.
            • Mobile Application: Mobile apps include all software intended to be deployed on a phone or tablet style computer. This software usually needs to be deployed via a "store" or some other specialized distribution channel.

              In 2020, a major cyberattack compromised the data, networks, and systems of thousands of organizations. While EPRI was not directly impacted, the incident highlighted potential risks and vulnerabilities within the software development lifecycle.

              In response, EPRI developed the Secure Software Development Framework (SSDF) along with supporting documentation—including the Playbook, Scan Requirements and Cost Estimates. The goal is to provide assurance to our members that EPRI is exercising due diligence in its software deliverables, ensuring they are safe to download and use.

              SSDF offers guidance for integrating security checks earlier and more frequently throughout the development process, helping to minimize issues by the time software is submitted. The Playbook outlines 12 leading practices designed to strengthen software security within a DevSecOps model, forming the foundation of EPRI’s SSDF Life Cycle.

              SSDF Documentation: