This first step starts with conceptual development, working with your stakeholders to develop an idea for a software product, and proceeds to developing an approach and plan for how to develop the product.
During these phases you will need to consider not just the technical scope, but also the end user expectations, market suitability for the product, various funding sources, methods of delivery, licensing and legal issues, as well as a host of unique EPRI policies and strategies.
Concept Development Considerations
Before starting on a software project, you should have a good idea on what you are trying to accomplish, and from that decide on a general approach.
- Basic Requirements
- What is the problem you are trying to solve?
- Who is the user? (skill, frequency, motivation)
- What does the user need? What is the value we are providing?
- Why EPRI? What is being developed that's unique?
- Software Type
- What is the best software solution for the problem?
- Is it best as a web application, a desktop application, a mobile application, and Excel spreadsheet, or a combination of approaches?
- What's the appetite for the stakeholders for security, administration, and maintenance?
- What is the technical readiness level (TRL) of the technology? Is this just proof-of-concept research that few people will use, or it a robust product that is critical to our member's success.
- Does EPRI have existing software that is a close analogue to what you what to do?
- What is the best software solution for the problem?
- Budgetary Cost and Schedule
- Where is the funding coming from? Will stakeholders need to be recruited?
- Is the available funding commensurate with the intended scope and value?
- When does the product need to be available, to maximize value to the membership?
- Software licensing of the final product
- How will the product be made available to the members? Specific supplemental members, all members, publicly available?
- Does it depend on 3rd-party content? (software libraries, data, IP)
- Interface to 3rd-party products?
- Risks
- Do we have everything we need?
- Does the software depend on external parties (for schedule, data, license, technology, or research)
- Are you prepared to meet the EPRI requirements and processes?
Project Life-Cycle
Software projects represent an additional commitment due to the ongoing support, development, and funding requirements of a successful and popular product. Some items to consider:
- Original Development
- What is the development strategy and resources?
- Can this be developed in-house, or do we need a vendor with specialized capabilities?
- How will the software be licensed to members and other parties?
- Where does this fit in the software process requirements?
- Supporting Users
- What is the problem being solved? What stage is the software supporting at this time?
- How is the software used (and who will use the product)?
- How will these users be supported? (User documentation, training courses, phone/email support, newsletters, user groups)
- What will happen when users call for support, or when bugs need to be fixed?
- Ongoing Development
- How will updates be handled in the future?
- Will we beholden into the original developer, or can other resources be used to maintain the software?
- What is the life of the product? How do we expect the product to evolve over time; do we expect updates to occur, and how will these be funded?
- How will hardware support and obsolescence be handled?
- Ongoing Development
- Commercialize
- Open source
- Retire completely when no longer supported
- Free to public
To set expectation with your management, it is recommended that you capture answers to the above questions in a life-cycle management plan. Some EPRI organizations require this. You may wish to refer to the example template for a Software Lifecycle Management plan (41 KB), or include this in your project solicitation material. For the Nuclear Sector the life-cycle information would typically be included in the QMP.
Project Planning Considerations
Once the concept has been agreed upon, actual project planning can proceed.
- Some EPRI Policies and other software requirements have significant impact on the planning - costs, schedule, or feasibility. Key Policies (links are internal to EPRI only)
- Funding
- Be aware of your funding source. This may impact the availability of the product.
- Software Technology and Tools
- Unsupported products/platforms require early review and appropriate approval(s) from IT (for security and support) and/or Legal (for licensing)
- All software must be reviewed by SQA prior to release to members. This includes any form of beta or pre-release software.
- Software may only be provided to people outside of EPRI via authorized channels.
- Some software types have special requirements described elsewhere. For planning purposes, be aware of the following:
- Content-only web sites
- Wiki sites (see MediaWiki Specific Requirements)
- Collaboration sites in EPRI.com (requested via the Digital Solutions Request Portal (URL Internal to EPRI only))
- Web-Based Software (not content-only)
- Web-based software requires front-end approvals, whether hosted inside or outside of EPRI
- Web-based software requires a kick-off meeting. Your developer will need to work with a number of EPRI organizations to properly develop the web site, including
- Websites and web apps have specific branding/layout requirements
- Web apps and web services have significant security requirements that require additional security testing and documentation requirements
- There are a number of additional requirements for URL access, database provisioning, CI/CD promotion, etc.. More information can be found on the kickoff checklist
- Contractors may need network access to submit software
- Mobile Apps
- Require approval from Web & Mobile Solutions prior to project initiation
- Distribution of mobile apps through a 'store' lead to addition challenges
- Software Type: Spreadsheets
- Simple Spreadsheets may be classified as E-media
- Complicated Spreadsheets
- Content-only web sites
Software Types
Provided below is a summary of software types at EPRI. For the complete definition of software types created by EPRI, review the Software Type Definitions. Refer to the Software Type Matrix for information and requirements on the EPRI software types developed at EPRI.
- Common software types:
- Desktop Application
- Subscriber Website (SWS)
- Complicated spreadsheets
- Mobile Application
- Server/Enterprise
- Software Implemented via a Commercial Software Platform
- Software Extension
- Special software types:
- Computer-Based Training (CBT)
- In most cases these are created and delivered via the LMS system, for which other requirements apply. Contact the Training department (epriu@epri.com) for requirements.
- E-Media: Desktop (includes simple spreadsheets)
- For example, simple spreadsheets, databases, etc.
- E-Media: Web
- For example, simple HTML sites with no input capability
- Billable Service Agreement (BSA) — these are custom-developed for an individual customer and the requirements are contract-driven
- Computer-Based Training (CBT)
Planning Budget Cost and Schedule
- Development Costs:
- Developers should be able to provide estimates for each phase of the software development life cycle. This should include costs for User documentation costs and testing
- Project plan should include costs for SQA testing (contact SQA for an estimate)
- Schedule
- Most software will require a Preproduction version to be made available to members before the Production release. Be sure to allow adequate time for Preproduction internal reviews and customer feedback reviews.
- SQA review will take longer towards the end of the year
- If software includes server, web, or mobile components, include plenty of time in the schedule for EPRI Server Ops, Web & Mobile Solutions and/or Database Administrators
- Assume something will go wrong
Development Team
- Team Composition
- Implementation personnel may include internal developers, or contracted developers. In many cases it is a good idea to include both to provide continuity and options for future maintenance.
- Consider how the software will be tested. In some cases, using a third party for testing is appropriate.
- Seek assistance for selecting contracted developers
- SQA Team, who have insight to experience of existing contractors
- Peers who have delivered the same software type
- Software Excellence Network representative in your sector
Project Initialization
- If the project includes external developers
- SQA will review the SOW before the contract is written with the vendor.
- You should complete and submit a Developer Quality Plan
- For Nuclear Sector deliverables, it is crucial at the start of the project you initiate the SQA Software Acceptance Form Traveler via ECM, as this is required for progression and completion of your deliverable.
Who to Call for Help?
- Software Excellence Network (SEN) can connect you to experienced developers and project managers in EPRI who can help, as well as provide information on technology and business compatibility questions.
- SQA for contractor requirements, contract approval, and information about vendors we have worked with
- Legal for licensing questions
- Web & Mobile Solutions if it is a web application