UML Operator Blog

My focus today is on launching a new "Tool" or "Major Version of a Tool". I am not a big fan of Humans or Human Nature, but we must embrace it. Yes, humans can be fickle, meaning they are inconstant and unreliable because they change their minds frequently. And yes, I am "human" too, and constantly challenged by my own human nature. Moving to any major platform release can be a challenge. We tend to let ourselves get in the way of progress. The top three things are: Human Nature to be Negative to Change Slowing down progress is frustrating and costly (money and labor/energy) Learning "new" things Learning "new" things may not be necessary. However, doing old things and potentially learning new approaches can be beneficial. This is where I embrace change, and often look forward to changes! This gets my creative juices flowing. Make Learning Rewarding When we are forced to move from the mundane, mindless, and repetitive motions, we are fo...

I get asked, quite often, "Is there a way to integrate Sparx Enterprise Architect (EA) with other tooling?" My answer is always, "Yes". There are multiple approaches, from very simple to more advanced. I have helped several shops do this over the years, and may do videos on this in the future. Integrating Sparx with Azure DevOps and other Cloud platforms, as well as other Tooling, is very possible and beneficial for managing delivery, such as requirements, problem solving, design, and development... all in a unified way.  The integration can allow companies/shops to seamlessly synchronize between Sparx EA's modeling environment and platforms, such as Azure DevOps'. Remember that one of the biggest benefits of Sparx EA over other modeling platforms, is that Sparx is based on Data-First implementation and supports open integration. Years ago, something call Open Services for Lifecycle Collaboration (OSLC) came out and Sparx was one of the first to embrace it. ...

The problem with most diagrams, whiteboards, drawings, and presentations, is that they "dazzle" but do not have "dazzling results". Maybe I should title this post as, "Dazzling Results Don't Lead to Dazzling Outcomes". The whole purpose of documenting things is to "remember things", to "communicate things", or to "reuse and deliver things better and faster". In the UML Operator Channel , we talk about and demonstrate Modeling. As a Systems and Software Architect and Engineer, I have seen the good and bad in documenting and collaborating on things . Drawing Tools vs Modeling Tools There are many "drawing tools" in the marketplace today. Tools such as Draw.io, Lucidchart, and more. These are amazing and simple tools, and I use them quite often. However, they are not very good at "documenting" and only...sometimes...result in nice "drawings". I often have to ask the team, "So what does this ...

In our Series on Model-Driven Anything , Solution Approach and Design are related yet distinct concepts in the development of systems, software, or projects. Here’s a breakdown of each: 1.  Solution Approach The  Solution Approach  focuses on the overall strategy or high-level method for solving a particular problem. It is more abstract and involves selecting technologies, methodologies, and architectures that are best suited to address the problem. Key Aspects: High-Level Overview : Describes how the problem will be addressed in a broad sense so that both Technical and Non-Technical Stakeholders can understand and collaborate. Focus on Feasibility : Evaluates possible options for solving the problem and their feasibility (e.g., whether to use cloud computing or on-premise solutions, or which platform or programming language to use or re-use). Stakeholder Alignment : Ensures the solution aligns with business goals, stakeholder expectations, and constraints like time and b...

  In the COCOMO (Constructive Cost Model) software cost estimation model, scale factors are attributes that have a significant impact on the software project's effort and cost. They influence how the effort varies with the size of the project. Specifically, the COCOMO II model uses five scale factors that are considered to be exponential drivers of cost. I must first preface that this is my interpretation of COCOMO II with ad hoc applications to form simple discussions with less technical stakeholders. The Scale Factors start with an understanding in these areas: 1.  Precedentedness (PREC):  Measures how similar the current project is to past projects. Higher familiarity and experience with similar projects can reduce the effort needed. 2.  Development Flexibility (FLEX):  Assesses the flexibility and willingness of the project to accommodate changes in requirements. Higher flexibility can reduce the effort. 3.  Architecture/Risk Resolution (RESL):  Ev...

 I have kicked off a Series for Model-Driven Anything , to expose my thinking on delivering "anything". Anything can be Software, Systems, Construction, or even a Dinner Party. Drawing pictures, during planning, is something that most people do, but putting intelligence behind the pictures is an art that most do not do well. When the Unified Modeling Language (UML) came about in the mid-late 90's, a world of opportunities opened up for the industry. Since then there has been my platform providers that have attempted to fill the niche with everything from cute drawing tools to tooling that fits a particular need. In this series, we will demonstrate how to start a project from scratch, model through the Delivery Lifecycles (DLCs), and produce Reporting & Analytics to track KPI's. While I use many different tools for delivering anything I am focused on, Sparx Enterprise Architect (EA) has been the best and simplest platform to achieve most of what I need. Thus, my Yo...

This post kicks of a new series on UML Operator Channel  UML Operator Channel around systems and software delivery, titled "Model-Driven Anything". Subscribe, turn on notifications, follow, and most importantly...Contribute 😎 IMPORTANT NOTE: Never start a software development effort without Requirements!!! or Scope!!! However, sometimes software starts out as a means of developing scope and requirements! So what are we talking about? Model-Driven Architecture (MDA) and Model-Driven Development (MDD) are both approaches within the realm of software development that emphasize the use of models as primary artifacts in the software engineering process. However, they have distinct focuses and methodologies. Here are the key differences between the two: Model-Driven Architecture (MDA) Origin and Standardization: Origin: MDA is a software design approach proposed by the Object Management Group (OMG). Standardization: It is a well-defined framework with standardized guidelines and...