The development may be performed using any number of development methods, with agile, scrum, Kanban, v-model, spiral, or whatever is appropriate for the team and the product.
No matter what method is used, there are some key attributes that are addressed during the development, including requirements, design, implementation, and testing. In most cases these activities are performed in an iterative process as the software is developed.
Product Requirements
Having well-defined and prioritized requirements is important to manage expectations and progress with the members as the schedule progresses, and to prevent "scope creep".
- The format, rigor, complexity, and scope of your requirements should track with the criticality and complexity of your project.
- If the contractor is needed to write the requirements, then a separate task in the statement of work is recommended. In complex cases, the identification of the requirements may be a separate phase or contract
- The requirements can be produced in several forms, such as a document, and spreadsheet, items in a Jira database, or whatever works best for the project.
- The requirements should be explicitly tested in the software testing activities.
- Manage High Risk areas:
- First of a Kind? If it's never been done or if your developer has never done it, be sure to include capability development and proof of concept to ensure that the learning curve and risk are baked into your project
- The Software Testing approach should be identified in conjunction with the Requirements
The requirements are to be provided to SQA upon submittal of the software. This information is used to support the SQA acceptance testing and to archive the information for future software development maintenance activities.
For the Nuclear Sector, this information is also stored in ECM per the QMP.
Special EPRI Requirement
- EPRI has specific requirements for various aspects of the software implementation. Requirements vary depending on software type and TR level. Some key areas:
- Also refer to Test Planning Guide (307 kB) for designing requirements and test cases
Software Design
Software design information explains how the software will operate.
- Scope of the design should correspond to the needs of the project
- Primary objective is to communicate to developers (current and future) and the project manager
- Some typical elements
- Software Architecture (when the software contains multiple modules)
- User flow
- Algorithms
- Database structures
- Key user screens
- APIs and similar key interface points
- The approach for capturing deign information depends on the needs of the project. For example, you might:
- Define use-cases in Jira
- Develop development instructions in Confluences
- Write the user manual
- Design is usually iterative. No matter the development method, you should obtain frequent user feedback
- Prototyping and demonstrate to stakeholders via web cast
- Provide beta versions to the users
The design information is to be provided to SQA upon submittal of the software. It might be in the form of a documents or in a PDF export from Jira, Confluence, or other database system. This information is archived the information for future software development maintenance activities, so the scope and quantity of the material should support that objective.
For the Nuclear Sector, this information is also stored in ECM per the QMP.
Implementation
Implementation is the actual act of producing the product. Specific EPRI requirements:
- Refer to the Coding Standards page, for the minimal list of coding requirements and additional suggestions. Be sure to provide this information to all developers. If the team has multiple developers, consider developing project-specific coding guidelines.
- For subscriber web sites, developers must store the code to an ADO repository.
- Other development projects do not currently require the use of EPRI ADO, but it is recommended that external developers periodically submit their source to ADO so that we have access to the source
- All EPRI contracts require that the vendor provide the source to EPRI.
- Larger and/or critical projects should have regular source code reviews
Source code build instructions should be created and maintained as new dependencies are added to the project. This must be provided to SQA when submitting the product.
Progress Reviews
Software projects are easily derailed -- hidden or late problems can cause major headaches. The project manager is responsible for the ultimate success of the project, which requires careful monitoring of the software progress. The exact nature and form of progress reviews will depend on the development methodology.
- Frequency and formality or project reviews are driven by software type, and project size, size of development team, etc.
- Make frequent software builds to facilitate frequent stakeholder feedback
- Demonstrate features to end users or a regular basis
- Use multiple preproduction 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 the current version
- Test & document product as you go
- This is the only way to determine the state of completion
- 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
Testing
- 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
- 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
Documentation
- Externally distributed software requires some form of user documentation that is appropriate for the product.
- Formal production software will often have a user manual that includes installation instructions, a tutorial/test cases, and a detailed breakdown of the software functionality.
- Formal software manuals must use the EPRI Software Manual Template
- User documentation may exist in multiple parts. For example, a description of the methods, algorithms, and equations might be in a separate Technical Manual included in the product or as a separate EPRI deliverable.
- Other types of software may have other simpler forms of user documentation:
- Web apps might have a Help menu that redirects to one or more pages of help
- A spreadsheet might have a Help worksheet
- Caution: Make sure that user documentation, especially screenshots, do not leak confidential information.
- Also make sure that any 3rd party material (images, diagrams, data, etc.) have appropriate copyright releases.
Who to Call for Help?
- SQA for requirements, test expectations, expected timeline
- Software Excellence Network (SEN) for advice on coding standards, testing scope, and related technical issues