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.

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 shareholders 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

  • System Architecture On walls, boards and other surfaces, you do not see squares and rectangles connected with each other by lines. Next to them is the information of what these "squares are doing with each […]
  • Drawing Diagrams – Best Practices One of the aims of modeling is to present complex issues at such a level of abstraction that will allow us to understand a given aspect of the problem. When in the organization models […]
  • Implementation of the Methodology – Selection of a Modeling Tool 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 […]
  • Business Requirements vs System Requirements There is a lot of talk about the need to identify project goals, organization goals and the need to identify business and system requirements. All in order to better understand the […]
  • Analyst in Agile Team The role of the analyst and the importance of analysis in many organizations is strengthening and in others it is disappearing. Quite often, where there is an agile approach, the role of […]

Leave a Comment

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

Scroll to Top