In many companies there is a discussion about formalizing the software development process. Spontaneous creation of diagrams by broadly understood analysts and designers does not build the value of documentation. The value is created when the whole team adds a diagram to the diagram as a brick to a brick. The added business process models or BPMN diagrams complement each other. Specify the solution.
When thinking about implementing the methodology, you often think about tools and notations. Notations absorb less. Simply put: UML and BPMN are modeling 🙂
When looking for a tool, it is worth considering that the tool should support the team in the following areas. Here they are (expanding slogan):
Iterative approach and decomposition
The model is built incrementally while maintaining the rules of objectivity.
It is important to be able to decompose a given fragment of the process, because only the decomposition ensures the level of detail that is currently needed by the recipients.
Objectivity and reuse
Once defined, the process should be visualized once and described in the project repository. It is a waste of time to describe the same activities and objects (generally artifacts) repeatedly.
The documentation must be built quickly in established templates. The documentation generators save time.
Models and notations
A good modeling support tool allows the use of standards-compliant notations. Models can and should complement one another.
Models are built for people and by people. It must be possible to work in groups, share resources and identify those responsible for changes in diagrams.
One repository for many stakeholders
When building business process models, I would like to be able to use them in the future to design IT systems. When creating a corporate architecture, it is good to have references to the implementation of, for example, application services. One project repository is the key to success here
One cannot forget about accepted practices in a given organization. Bad practices must be eliminated. Good care. The CASE tool should support this area. There is nothing worse than imposing an “upper” product, which by its action breaks and destroys what is good and has already been worked out by the organization
Migration and integration
Sometimes the day comes when you need to move our model repository to a different environment. The XMI standard is now the basis. It is also worth knowing the schema of the database on which the repository is embedded. It helps in integration with other tools (JIRA) or in reporting.
Matrices of dependence
Activity from the business process, the use case should be mapped with business requirements or rules. It allows for a better understanding of the principles of the process and checking the coverage of requirements. Tracking changes is also easier.
Summarizing. CASE tools are just an add-on, an important addition, but only an addition to modeling because the methodology of creating systems is important.
When thinking about the methodology, it is worth to analyze the current manufacturing process. The implementation of modeling tools should be an evolution, an improvement of the process and not a revolution – its destabilization.