Posts

Is UML Compliance Necessary?

The answer to “Is UML Compliance Necessary” is No, UML compliance is not strictly necessary in most cases. However, whether UML compliance is necessary depends on the context of your project, industry, or organizational requirements.  We created a short video on this topic, with the same title, " Is UML Compliance Necessary ". UML Compliance refers to the adherence to standards and specifications defined by the Unified Modeling Language (UML), a standardized modeling language used in software engineering to visualize, specify, construct, and document the structure and behavior of software systems. UML is governed by the Object Management Group (OMG), which sets the official specifications. So when is, or is not, UML Compliance necessary? Here's an overview: When UML Compliance Might Be Necessary Regulated Industries or Standards Some industries, such as aerospace, defense, or finance, might require UML for standardization in software engineering. Compliance might be tied ...

The Implementation of Traceability in UML/CASE Modeling

The Challenge The Challenge is around approaching Data Relevance in Modeling, where UML or some other CASE (Computer Aided System/Software Engineering) approach play a role in Model-Driven Anything and Modeling our Intelligence. For this topic we need to understand three key aspects of "Relevance": Data Relevance, Model Data Relevance (applicable to Data Science and Learning), and UML Model Data Relevance (which is focus on CASE and UML). PREFACE: The content below is based on my 30+ years in Systems and Software Engineering, a lot of Internet Searches for different perspectives, and use of OpenAI. My objective is to share different perspectives on this subject, and then apply to the real world. Focusing on Data Relevance What is Data Relevance Data relevance refers to the importance and applicability of data to a specific purpose or context. Relevant data is valuable because it directly supports decision-making, problem-solving, or specific research goals, while irrelevant d...

Introducing Changes in Delivery

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

Sparx EA and Open Collaboration

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

There are NO Silver Bullets In Systems/Software Engineering

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

Solution Approach vs Design

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

Scale Factors in Delivery Decisioning

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