- Operating Systems Supported by EPRI-developed Software
- Software must be designed for the Windows 32-bit or 64-bit platform (is coded using 32-bit or 64-bit internal architecture, not 16-bit). Exceptions must be documented and approved by the EPRI software quality manager.
- Software coexists with other products on the platform.
- System response time meets industry performance standards.
- Any media duplicated outside of EPRI must include the new Product ID number for the release on the label. This number is obtained by the EPRI Project Manager from the Apollo system Product Master.
- Internationalization : End users for all software will be able to choose, by changing the regional settings of their operating system, to the country of their choosing and the application will pick up the proper units of measure, currencies, date formats, and number formats. If data has been already entered into the application or stored in a file or database, then the users needs to be told what will happen to the data already entered or stored.
The options are:
- Convert the data already entered to the new units or format. This would have to be done by the application conversion program
- Use the original data and format type for data already entered or stored and the new format for new data. The application program would have to make this happen correctly
- The application program could clear the fields of the application where data was already entered
The user manual should document the expected results and the user interface should provide information or warning indicating what changes will occur when a user changes the regional settings. Exceptions must be documented and approved by EPRI Corporate Software Quality in the development plan.
Where numbers are used with scientific units the ability to use both US English and Metric (or SI) units is required.
The specific units to be converted, and the types of conversions, will be determined for each software project, based upon user requirements. There is no single definition to be followed. More on internationalization.
- Localization (Optional): Localization is generally the issue of providing the application in the local language, or supporting multiple languages. It is optional, but useful, for international users to have all GUI screen text information and error messages in a file that can be easily translated and loaded into the program on initiation. Some special domain projects may have specific Localization requirements defined in advance. For all applications the Localization plan will be documented in the lifecycle plan and requirements documents.
- Maintenance & Local Language Support (Optional): All messages, such as error messages and on-line help, must be placed into a single table, file, or other central location. This will ease software maintenance as well as the implementation of future local language support.
- Security Policy
As a minimum, the following requirements will be met:
- Security issues and security plan for the software will be covered and described in the planning documents (e.g., Functional Specifications, Software Requirements Document, etc.) and in the User Manual.
- Software is free from viruses.
- No passwords are viewable in plain text nor are passwords kept in an open-access file or database in plain text. Plain text may be used in databases or files that can otherwise be secured from general users.
- There is no "backdoor" method to enter the software.
- There are no "Trojan horses" or similar detrimental coding in the software.
- Software is written in a manner that promotes the highest security state applicable for this software.
- Software uses Authentication and Access control as appropriate.
- Software must offer ability to use Windows Authentication as well as proprietary Authentication when both are available (i.e., using Windows Authentication and MS SQL Authentication).
- Software is delivered in the maximum security state as stated in the design documents (e.g., the documentation has warnings and clear directions to set up the security states; software that uses passwords and administrative functions have them enabled).
- Security Vulnerabilities Usability Testing: A web application may contain many security vulnerabilities that can be exploited. Information can be read and databases corrupted if the vulnerabilities are not addressed. Click here to see examples of testing EPRI SET will perform.
Return to top of the page 
- Software Encryption
Software uses encryption as appropriate and in accordance with US Export Regulations.
Encryption - The translation of data into a secret code. Encryption is the most effective way to achieve data security. To read an encrypted file, you must have access to a secret key or password that enables you to decrypt it. Unencrypted data is called plain text; encrypted data is referred to as cipher text (Data that has been encrypted. Cipher text is unreadable until it has been converted into plain text (decrypted) with a key.)
In very basic terms, encryption is a way to send a message in code. The only person who can decode the message is the person with the correct key; to anyone else, the message looks like a random series of letters, numbers, and characters.
Data Encryption - The process of scrambling stored or transmitted information so that it is unintelligible until it is unscrambled by the intended recipient.
Official data encryption definition provided by EPRI Legal and Export Control: Export Administration Regulations
If encryption is used, the developer must be able to answer the questions asked by the U.S. Department of Commerce. If the developer does not know how to answer those questions, another encryption routine must be used.
Is software encryption (e.g., keys, database keys, data transfer, etc.) used or required in your software? If yes, please complete EPRI Legal's Encryption Functions Checklist and submit it to York Huang ("cc" your Software Quality Manager). Keep in mind that encryption greater than 56-Bit may require a special license which may take 90 days to process. For legal advice, please contact EPRI’s Intellectual Property staff.
- Conformance Statement (Certificate of Conformance)
All software delivered for final acceptance test to EPRI will be accompanied by a "Certificate of Conformance" which certifies that the software meets all requirements in the developer's corporate quality plan (for contracted developers), EPRI's software development requirements, security policies, and the requirements of the contract to develop the software. In the case of the contracted developer, the "Certificate of Conformance" will be signed by the highest person in the company responsible for software quality such as the quality manager, the software project manager, or an officer of the company. For internal EPRI developed software, the "Certificate of Conformance" will be signed by the Project Manager or Program Manager. Please talk with EPRI's Software Quality Manager before sending the letter if there are issues or questions.
The following is an example of a "Certificate of Conformance" required to be submitted by a contracted developer. (Note: EPRI Nuclear "Q" software has their own "CofC" requirement.)
********************************************
[Company Letterhead]
Certificate of Conformance
Date: _________________
| To: |
Software Quality Manager |
| Electric Power Research Institute (EPRI) |
| 3420 Hillview Avenue |
| Palo Alto, CA 94304 |
Subject: ________________________________________________
Software Name: _________________________________________
Revision Number: ________________________________________
Reference: _______________________________________________
Contract Number(s): _____________________________________
[Company Name] hereby certifies that the product identified above is being furnished in accordance with the [Company Name] Software Quality Plan and is in conformance with all requirements prescribed in the referenced agreement and EPRI's software deliverable and security requirements (as stated on EPRI's website reviewed on ________(MM/DD/YYYY)).
Certified by: ______________________________ Date: ___________________
[Company Name] Software Quality Manager
********************************************
The following is an example of a "Certificate of Conformance" required to be submitted by a internal developer. (Note: EPRI Nuclear "Q" software has their own "CofC" requirement.)
********************************************
Certificate of Conformance
Date: _________________
| To: |
Software Quality Manager |
| Electric Power Research Institute (EPRI) |
| 3420 Hillview Avenue |
| Palo Alto, CA 94304 |
Subject: ________________________________________________
Software Name: _________________________________________
Revision Number: ________________________________________
[Project Manager or Program Manager Name] hereby certifies that the product identified above is in conformance with all deliverable and security requirements as prescribed in EPRI's software website (http://mydocs.epri.com/docs/SDRWeb/processguide/index.html).
Certified by: ______________________________ Date: ___________________
Project Manager or Program Manager
********************************************
Return to top of the page
- End User & Software Integration in Enterprise Systems
Definition
Certain applications of EPRI software require such software be integrated with key systems in the members' Information Technology (IT) inventory. Member IT inventory that most justifies specific requirements are so-called enterprise systems. These systems include basic everyday systems familiar to all users, e.g., Microsoft Office, as well as large integrated systems that facilitate or control major activities, e.g., work management and enterprise resource planning systems such as SAP, Maximo, etc., data repositories such as OSIsoft's PI, and other systems with similar comprehensive uses (some of which may be EPRI systems).
Integration with member's enterprise systems is critical because these systems contain much of the critical data the EPRI applications must use, e.g., work activities performed and their results, equipment operations, etc., or they facilitate the actions that EPRI applications indicate should be taken, e.g., performing an inspection or a maintenance activity. Therefore, the success of an EPRI application relies upon the effectiveness of its integration with other software.
Finally, within EPRI and other software of this enterprise nature, there are common applications or routines that can be used without the need for additional development. Both EPRI and member costs will be reduced if EPRI software begins to take better advantage of existing EPRI and commercial software. Reuse of software also creates opportunities for cost sharing in the development or maintenance of common routines.
Software Integration Requirement for Software requiring integration with Member's Enterprise System(s)
The following are the requirements for software integration.
1.0 Plans for Software Integration
Plans for software integration should be included in the earliest phases of the project, certainly no later than the development of the planning documents (e.g., Software Requirements) and preferably during the project development process (e.g., Destinations). Plans should specify the enterprise systems from which data are required and/or in which EPRI software results are used.
2.0 Software Integration Standards
Preference should be given to the use of software integration standards such as the Common Information Model (CIM) as this approach will reduce life cycle costs.
3.0 Software Modules Creation, Use and Reuse
Consideration should be given to the use of existing software capability either in EPRI or commercial products. EPRI Software Quality and ESI staff can provide information as to the availability of such software and member experience with its use. Examples include reporting capabilities such as graphic routines, data acquisition capabilities for specialty systems such as predictive maintenance systems, application login and security, etc. and many capabilities that are already part of member systems. Member input in the requirements process should be obtained to identify opportunities for use of existing member IT inventory capabilities.
- Source Code & Design Quality - Special Domain Software
Special Domain Software (chosen by EPRI management for its strategic or important software development efforts)
When EPRI's strategic initiatives include important software development efforts (referred to as Special Domain Software), EPRI management at its discretion may wish to increase the assurance of quality by imposing additional requirements. These additional quality requirements will be focused on the underlying source code, including the architecture and design. Quality factors to be addressed would include but not be limited to considerations such as assurance the software can be maintained efficiently, reusability of components and overall componentization, ease of understanding (e.g., commenting and organization) as well as software integration with EPRI and selected commercial products (see also Software Integration).
The following are the requirements for Special Domain Software.
1.0 Software Development Policies and Procedures
Developers will need to have specific development policies and procedures for development. Developers will certify that they have such policies and procedures. EPRI Software Quality can mandate to review the appropriate policies and procedures, especially with regard to key lessons learned either from EPRI's experience with the developer or from EPRI's general experience with developers.
2.0 Performance of Design and Code Reviews
Developers will perform design and code reviews of software or portions of software designated by EPRI as Special Domain Software. If required by EPRI management, EPRI Software Quality (or its designees) may perform design and code reviews of the subject software. Developers will provide EPRI with documentation of the developers design and code reviews.
3.0 Documentation
Specific guidance documents in the form of project plans, functional and non-functional specifications, design documents, and user interface documents may be required to be created for software developed in Special Domains. All software developed in an identified Special Domain is required to adhere to the guidance provided in this documentation. All software development documents specified in the EPRI Software Quality Process Table should be deliverables in a development contract and provided to EPRI Software Quality at or before the time of software release.
4.0 Software Modules Documentation
The developer will provide a Programmer's Manual for software modules developed as part of Special Domain projects if those modules are either to be used in more than one application or are involved in software integration with "enterprise systems" (see Software Integration). The Programmer's Manual will contain sufficient information for other developers to practically reuse the module including descriptions of the program logic, input/out parameters, and the module function. The Programmer's Manual will be for use by developers with access to and plans for use of the source code and not be released to members.
Return to top of the page
- Software Life Cycle Management Template - Requirements
Download the Software Life Cycle Management Template in Microsoft Word (.doc) format.
Overview
The lifecycle of a software application covers the time from conception through its full retirement and can cover time from as short as a few months to several years. At EPRI it is important that we define the expected lifecycle for our software. This will enable users, funders, EPRI project managers, and developers to make good decisions concerning software and development issues.
This Software Lifecycle Plan should be part of the early development process. Preferably, it would be part of the initial concept, budget, and schedule that is provided to the stakeholders along with the funding request. As a minimum, the Software Lifecycle document must be provided to the EPRI Software Engineering Team prior to the Software Quality Managers approval for a contract.
This template covers the following items:
- The software concept
- The expected design of the software (simple tool, integrated office application, multi-tier web based application, etc.)
- The expected software platform and special hardware and/or software requirements
- Internationalization and Localization expectations
- The plan and need for integration with other software
- The expected user base (type and number)
- Quality expectations (reliability, serviceability, availability, etc.)
- The initial budget and schedule estimates
- The expected lifetime of the current software version
- A funding plan for maintenance and support of the current software version (at least three years)
- A plan for future upgrades (this should cover the expected design and quality of future upgrades as well as estimated budgets for the upgrades).
Each item is defined below. Some additional descriptive text is provided for guidance. The EPRI Project Manager should provide a written answer to Software Quality for each item below.
1.0 Define the Software Concept
Define the initial concept of the software from a feature and functional point of view. Answer questions such as: What is the objective of the software? What will it do? How will it be helpful? Is there a business case to develop this software? What problem is the software trying to solve?
2.0 Define the Expected Design of the Software
Define the expected design and architecture of the software from a very high level. For example, will the software be a simple VBA application embedded in Excel, a single user desktop application, a multi-user client/server application, an enterprise level n-tier intranet application, a hosted web based application, or will it have some other type of design?
3.0 Define the Planned Software Platform and any Hardware and/or Software Requirements or Restrictions Known at this Time
Define the planned software platform, such as Windows, UNIX, etc., on which the software is intended to operate. Also, if there are any specific hardware or software requirements or restrictions those should be defined as well. Some key examples are targeting specific web servers or database servers.
4.0 Define Internationalization and Localization
Define the Internationalization and Localization requirements for this software. Internationalization means proper handling of international units, date, time, and number formats. (This is normally a required item for all EPRI software, however it may be waived via written exemption by an applicable Director. Please describe reasoning if waiving the requirement.) Localization means allowing for different languages. (This is normally an optional requirement.) Please list all planned languages that will be supported. Additionally, the minimum requirement is software run in US English on a US English operating system (ex. the US English version of Windows); if there are international funders, please ask them if software working in US English on the US operating system is OK for them.
5.0 Define the Plan for Integration with other Desktop or Enterprise software applications.
Define the expected plan, or need, for integration with other desktop software, such as Microsoft Office, or other enterprise software such as Enterprise Resource Planning Software (SAP, PeopleSoft), Computerized Maintenance Management Systems (Maximo), Data Historians (PI), etc.
6.0 Define the Expected User Base
Define the type and number of people that are expected to use the software. It is best to define several types of people whom are likely to use the software. For example, in addition to key target engineers who might use the software, the plant IT department, management, and outage personnel might interact with the software as well.
7.0 Define the Quality Expectations
Define the quality expectations for the final software product. Note that the EPRI minimum requirements must always be maintained, however, it should be noted whether the application should have additional quality requirements, which would be important in enterprise level software, or software that is expected to have commercial appeal.
8.0 Define the Initial Budget and Schedule Estimates
Define the initial schedule and budget estimates for the project. Also specify the top risks to both schedule and budget.
9.0 Define the Expected Lifetime of the Currently Proposed Software Version
Define the length of time that the currently proposed version of software is intended to be used by its user base and how long it is planned to go without additional upgrade and/or maintenance after initial release.
10.0 Define the Funding Plan for Maintenance and Support of the Currently Proposed Software Version
Almost all software requires support, and possibly maintenance, in the future as users begin to make use of the software. Define how this support and maintenance will be funded and implemented for a minimum of the next three years, preferably for the next five years. Address bug fixes as well new issues such as operating system upgrades, etc.
11.0 A Plan for Future Upgrades
Define the plan, if any for future upgrades to the software. If future upgrades are planned, define how they will be funded. These plans should be reflected in supporting planning budgets.
