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 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. 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 […]
  • 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 […]
  • 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 […]
  • Requirements Documentation Requirements specification is a systematic representation of a set of requirements for a system or component that meets specific criteria. Requirements are like contract. All […]

2 thoughts on “Five Tips of Software Modeling”

Leave a Comment

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

Scroll to Top