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

  • Kanban Tasks In the previous entry, I wrote about the task board in Kanban. Now I will add some words about tasks and task cards. Kanban tasks are specified by means of a card. Many people prefer […]
  • When is it worth modeling in UML? For some time, there has been a discussion about the value of modeling. Advocates of agile approach are not very happy to see models. Conservatives preferring the classic approach to the […]
  • Kanban Bottlenecks Queues and WIP limits, which I discussed in the previous posts,  make up a chief indicator of problems in the flow. They show bottlenecks and when they are going to form. Bottlenecks […]
  • Managing Relationships Between Requirements Requirements management is an important element of the software development process. One of its elements is building and managing relationships between requirements. The most common is […]
  • Impact Mapping In my practice I have met many times the situation in which the change was implemented in accordance with the maxim of King Julien " Quick, to the volcano, before we all come to our […]

2 thoughts on “Five Tips of Software Modeling”

Leave a Reply to Michael Cancel Reply

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

Scroll to Top