EPRI | Software Development

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
- - Review EPRI's Acceptance Testing Criteria
  - Download the EPRI SQA Team's 2016 Guide for Testing Your Software (590 KB) for hints for testing your software
- 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