EPRI: Electric Power Research Institute

Software Development

Step 5: Implementation & Testing Phase

Progress Reviews

  • Frequency and formality driven by software type, and project size
  • Make frequent software builds to facilitate frequent stakeholder feedback
    • Demonstrate features to end users or a regular basis
    • Use multiple "alpha" or "beta" releases to enable user feedback
    • Ensure vendor contracts reflect multiple builds
    • Manage changes to requirements to remain flexible within cost and schedule
    • Leverage the prioritization. Allow flexibility for requirements to change
    • Capture scope changes in project documentation and be clear on what is current version (e.g., SharePoint, shared folders)
  • Policy reminder: Don't release software on servers that circumvent the EPRI product access mappings


  • Developers should be aware of EPRI requirements, coding and/or UI standards (98KB), particularly secure coding standards that apply
    • Experienced developers recognize and avoid gold-plating
    • Developers must check-in their Subscriber Website (SWS) code to a GitLab repository and commit messages should briefly describe the code changes being submitted (i.e. Feature X implemented, Bug Y fixed, etc.). To request a GitLab repository, send a message to SQA@epri.com.
    • Source code build instructions should be created and maintained as new dependencies are added to the project
    • Larger and/or critical projects will benefit from regular source code reviews
  • Remember the mythical man-month
    • Progress is not a function of time
    • Too much overtime to accommodate poor estimates or scope creep can affect quality, introduce more bugs, and incur more costs in the long run
    • Adding more developers increases the communication factor of a project more than it improves the progress of project, especially late in the schedule
  • Test & document product as you go


  • The Project Manager is responsible to assure adequate performance of the software
    • The SQA Team only tests for compliance with EPRI requirements
  • Testing should be an on-going activity throughout the development
  • Testing includes:
    • Unit testing on individual software functions of modules
    • Functional testing of the entire software package
    • Integration testing with other software tools
    • Regression testing when updates are made to the software
    • Installation testing on target platforms
  • The nature of the testing should be identified in the project plan
    • Testing needs to demonstrate the completion of the requirements
    • Testing should involve searching for possible errors in the software, not simply verification that a few cases happen to work
    • To the extent possible, the testing should include testing by 3rd parties not directly involved in the development of the software
  • Test cases or tutorial must be provided as part of the project
    • However, in most cases this is not sufficient, and more testing should be performed
  • Developers should:
    • Be aware of how the SQA Team's standards for usability testing affects their efforts
    • Should make sure that any data displayed is correct/complete and verify the results of algorithms/calculations
  • Testing should be documented to be repeatable
  • Again, the Project Manager is responsible


  • Externally distributed software requires some form of user documentation that is appropriate for the product
    • Spreadsheets might have a Help worksheet
    • Web apps might have a Help menu that redirects to one or more pages of help
    • A script file might have a readme
  • Formal software manuals must use the EPRI Software Manual Template
  • Make sure that documentation, especially screenshots, do not leak confidential information