Very often thinking about software engineering we are thinking about software development. And what about its maintenance, development? It does not say about it too much. UML or BPMN alone are not enough to manage the exchange. How to do it?
Enterprise Architect is a tool that comprehensively tries to support processes related to software engineering. In the area of broadly understood change management, it offers beings with which defects, issues and changes can be described. In other words, you can model changes and maintain systems in Enterprise Architect. A number of these elements can be found in the Maintenance Diagram.
The maintenance diagram is a diagram that allows me to present (mapping) the impact of identified defects or issues on individual elements.
The meaning of individual elements:
- Change – if the need to change is reported to an already implemented system, this element is ideal to call this change and describe in a few sentences what it is about. I collect changes in the appropriate package – a kind of register of changes. They have their statuses. In the maintenance diagram, I map the change to components, use cases, interfaces and sometimes to individual classes.
- Issue – corresponds to the failure to meet the requirements for the current system due to new factors. For me, this is an excellent element for presenting the gap that arises after the change. The gap illustrates the difference between the target state (after change) and the current state (before the change). The issue is not a requirement but rather a description of how the target state differs from the current state. I often use this element to select a topic to discuss with stakeholders. The result of the conversation mentioned are tasks or requirements.
- Defect – corresponds to the failure of the current system due to a malfunction in the model, system or process. In other words, it’s an element about marking an error. I use it very rarely for the system, because in organizations defects are usually reported in such tools as JIRA. Nevertheless, Enterprise Architect gives you the opportunity to mark errors that can be attributed to other elements such as use cases or components. The defect should include information about the vulnerability in the commentary and measures taken to remove it.
- Task – is an element that is used to mark or rather define the work that needs to be done to investigate or solve a problem or a fault. You can create a tree hierarchy or structure from task elements. In this way, you can divide a large task into smaller parts and assign elements to the smaller parts to which the task applies.
The advantage of using these elements is the ability to use them on any diagram. Any change, issue or defect can be combined with other elements of the model in the project to illustrate how these entities contribute or are affected by the mapped element. What’s more, each of these elements has a status bar at the left end, which is color coded to visually represent the value of the Status field in the element properties. In this way, you can indicate active or resolved defects, issues or tasks.
In the example above, the resulting change adds support for non-fiscal receipts. This change affects the use case Transmission of Order Parameters. In connection with this change, the issue of Minimal Data Scope for Non-Fiscal receipt has arisen. The task was also to expand the main scenario with a non-fiscal receipt. This task concerns the change in the indicated relation of realization – use case.
To sum up. The use of elements from the maintenance diagram described above provides a wide range of change management, defects and issues. It allows you to visualize the problem and solve it with related elements. In addition, the influence of these artifacts on entities from models describing software or business processes can be indicated by means of links.