Five Tips of Software Modeling

My software modeling  is approach to software analysis based on reasonable diagrams. In this post I present my five tips of Software Modeling.

Models evolve over time

You can start with the basic case, but you’ll quickly decide to turn it into several system use cases. You can also decide to develop a set of Object-Role Model diagrams (ORMs) placed on the whiteboard as a contribution to the UML class diagram, which in turn will transform into source code.

Analysis models must be only good enough

Try to make your models as simple and light as possible. Focus on understanding, not documentation. Use the simplest and most general tools available. Realize that your models do not have to be perfect.

Each model can be used for many purposes

Data flow diagrams can be used both as an analysis technique to examine existing business processes and as design techniques to redefine them. Similarly, the BPMN or state machine diagrams can be used for both analysis and design purposes as well as for use cases for requirements, analyzes and sometimes even design.

Modeling lines are often blurred

The traditional concept of software development phases – requirements, analysis, design, coding, testing and implementation – left many people convinced that we need to distinguish between different types of modeling. But if the person concerned provides us with a requirement, such as the need to obtain a student’s home address, we will often go through these phases at intervals of a few seconds. We will start to think about how the user interface should look like, about the different data elements to be acquired, the need for the Address class, the possibility of using the Contact Point formula, the need to create the Address table in the database, and how to write the code for all this in Java, thus departing from the requirement through analysis and design to write code without stopping to create a complete model of requirements, or a complete analysis model, etc. As it is important to ask questions like what you need (requirements), what does it mean (analysis) and how we intend to build it (project), we will often do it in an iterative, not serial way.

Use the same terminology as the shareholders

Do not force stakeholders of your project to use artificial, technical jargon. It is for them that the system is created; therefore, you should use their terminology in the system model.

More from my site

  • Mappings That Go Beyond Enterprise Architecture Some month ago in the post I wrote My Favorite Perspectives in Enterprise Architecture I presented a few diagrams describing enterprise architecture from different perspectives. The […]
  • 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, […]
  • Categorization of Requirements According to the Kano Model Defining the requirements that will increase the satisfaction of stakeholders from the system being created is crucial for the process of acquiring requirements. Implementation of too many […]
  • Kanban Workflow In the preceding Kanban post, I wrote about partially done work. I wrote that it is worth limiting partily done work. The WIP (Work In Progress) which is too high results in the fact that […]
  • User Stories vs Requirements When writing any specification of requirements and the product register and sprint register, non-functional requirements should be included in this specification. While the user's […]

2 thoughts on “Five Tips of Software Modeling”

Leave a Reply to Laszlo Marai Cancel Reply

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

Scroll to Top