For each process pattern you identified earlier, you should now identify how SD Elements activities map to logical process steps and roles. The following list represents common key activities:
- Create project
- Model project
- Set priority filters
- Review tasks
- Integrate with ALM OR Assign Tasks
- Handle development tasks
- Review activity
- Import security tool results
- Perform test tasks
- Generate reports
You will need to add and remove activities from this list to make sense in the context of a particular development process. For example, in a scrum agile process you may want to explicitly create an activity for adding requirements task to the product backlog.
Select a profile and answer project settings for the project. Note that in some cases, no single person will be able to answer all project settings exhaustively.You should attempt to answer to the best of your ability. You can then follow up with others to find outstanding answers to further improve the accuracy of the project settings.
Set priority filters
Filter tasks by priority, if applicable. Usually this is related to the project’s inherent risk. For example, high risk Internet-facing applications may require all tasks of all priorities to be in-scope while an internal facing application without much sensitive data may only require high priority tasks to be in-scope. This step is dependent on the level of rigour guidelines you set.
For existing applications, review the tasks in the requirements, architecture & design and development phases and mark them as Complete if you are reasonably sure that they have been completed. Mark any tasks that are not valid as Not Applicable and add a note explaining why. Leave the rest as TODO.
For new applications, review tasks in the requirements, architecture & design and development phase and mark any tasks that are not valid as Not Applicable. Add a note explaining why.
Integrate with ALM
If the development team uses a supported ALM tool then you can create an integration with that tool. Note that a system administrator will first have to setup the integration in the System: Integration menu. The integration profile should filter to match the tasks you wish to synchronize: including phases (e.g. requirements, architecture & design, and development) and priority (e.g. High - priority 7 and above).
Once the integration profile has been created, you can integrate the project with the ALM tool. Select a synchronization frequency that matches your need for up-to-date data. Most organizations select “Daily”, which means the task statuses will be synced once per day.
Once the tasks are in the ALM tool, they should follow the normal development process for assigning and completing the tasks.
If the development team does not use a supported ALM tool, they can either assign tasks from the requirements, design and development phases within SD Elements itself or export the tasks for inclusion into a requirements document. The former is preferable to the latter, but if the organization has traditionally used documents to manage requirements then this may be the easiest-to-adopt solution.
Handle development tasks
You should select one or more strategies for handling development phase tasks that are appropriate to the development process. SD Elements process consultants should be well versed with the different strategies
Periodically review the project activity log in the project overview page to ensure that the development team is making progress on the development tasks. Choose a tracking frequency that makes sense for the particular development velocity. For example, weekly or bi-weekly. Follow-up with the appropriate people within the development team if there is insufficient activity.
You can also get a quick view of the last time all projects were modified by reviewing the Applications page and sorting by Last Modified Date.
Import security tool results
Perform test tasks
Most organizations use security scanning tools to verify whether certain tasks have been completed or not. Testers can use SD Elements to verify tasks that were not covered by scanning tools, or all tasks if they do not use a scanning tools. For the case of the former, you can use the filters sidebar to review the tasks that do not have a verification status by setting the “Verification” filter to “No Verification Status”. Next review the related tasks for each remaining task in the requirements, design & architecture, and development phases. Click on all tasks in the testing phase and follow the instructions for testing.
Some test phase tasks require access to source code, and therefore may need to be verified as part of a code review process rather than by run-time QA testing. SD Elements tasks that start with the word “Test” are designed for runtime testing. SD Elements tasks that start with the word “Verify” will require access to source code, configuration, or logs.
Testers should mark each task that they test as “DONE”. They can also navigate back to the original task in requirements, architecture & design, or development to mark its verification status as Pass or Fail.
Work with security & development teams to determine who is best suited for performing testing tasks which are not covered by a scanner. Options include:
- Developers: Developers perform their own security tests
- QA: QA teams perform security testing
- Information security: Information security teams perform focused security testing
- External testers: External testers perform security testing
You may need to generate one or more project reports at the end of the process for audit evidence.
Once you have completed work on the project, you may wish to archive it to prevent further editing. For some processes, this may not be desirable if you wish to keep the project open for handling individual changes.