Modeling of Business Processes in the Software Development Process

Business process modeling is relatively common today. In many organizations, it is even done in two places :-). In a cell responsible for improving or supervising processes and in IT, where software is made. The BPMN notation is the commonly used description language.

The modeling of business processes in the software development process was, in my opinion, sanctioned in the Rational Unified Process.

Source: Rational Unified Process

Many years ago, the application of BPMN in business process modeling was not so obvious. In the aforementioned Rational Unified Process had the extension of business modeling, which allowed to model business process scenarios in UML.

Then the discussion could be justified. BPMN was just beginning to be a standard. Reading this text today – I smile to myself. Modeling business processes in BPMN notation is a commonly used standard. The question that should be asked about the above is whether business process modeling in the software development process is needed? Well, it is. In my opinion, regardless of whether we operate in agile or classic or cascaded modeling of business processes is needed. Business models allow you to:

  • understanding how a company is currently operating and how implementing a change in an IT system can change its operation (sometimes affects 1 process)
  • improving communication, because showing where we are going allows us to understand the organization in the same way,
  • assigning business requirements to the activity, which will later be decomposed into requirements dedicated to individual systems
  • showing the business process at a different level of detail (more on this topic in the next entry).

Continuing to prepare one or several diagrams, it should illustrate two states for us. Current and target. Sometimes the target process is the same as the current process. What’s changing? One or more business activities change. More precisely, the scope of IT support. Bending over a part of the process allows you to focus on only a few business activities that you change. Adding the requirements will facilitate verification, which should answer the question of whether and how new requirements, change the process and affect other processes.

Building business process models is not only:

  • improvement of work efficiency by standardizing the process
  • improving the quality of processes
  • shortening the process implementation time
  • finding errors and bottlenecks in processes
  • getting the opportunity to estimate the costs of business processes

Modeling business processes in the software development process is the basis to which the subsequent stages of this process relate. System analysts, based on business processes and business requirements, identify use cases and requirements for the system. Testers build test plans and test scenarios (especially when it comes to integration testing). Developers have an easier task in planning the sequence of implementation of individual functions.

Modeling business processes in the software development process will make sense when the levels of abstraction in describing these models are well chosen. I will write more in the next article.

 

More from my site

  • Registration of Problems Identified During the Analysis I received an interesting question by e-mail: According to your knowledge, is there an object in EA that would be best suited for registering problems identified during business or […]
  • KANBAN – basic terms and rules This article opens a series of texts on Kanban. I am planning 7-8 texts in this area, which will be posted every two weeks. Let us start from the beginning. What is […]
  • Three Benefits of Use Cases I recommend each person to use the use cases particular in Agile projects. Below three are basic advantages that I think will convince you to use the use cases in Agile projects 1. […]
  • Maintenance Diagram in Enterprise Architect 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 […]
  • User Stories vs. Use Cases We are currently in a “strange situation”. There are user stores and usage case scenarios, of which the latter can be divided into formal and informal use cases as well as summaries of […]

Leave a Comment

Your email address will not be published. Required fields are marked *

Scroll to Top