UML Operator Blog

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

On the UML Operator Channel our focus is on Model-Driven Anything. In Sparx Enterprise Architect (EA), we are able to model-drive all aspects of delivery. From Ideation to Code Deployment and Test, Computer Aided Design (CAD), whether simple Unified Modeling Language (UML), Computer Aided Software Engineering (CASE), Business Process Engineering (BPM, BPMN, or BPEL), any delivery is possible. Model-Driven Design Model-Driven Design (MDD) is an approach to software development that emphasizes the use of models to describe various aspects of a system's structure, behavior, and functionality, and to drive the development process. In MDD, models serve as the primary artifacts for communication and analysis among stakeholders, and they are used to generate executable code or other artifacts. Here are key concepts and principles of Model-Driven Design: Abstraction : MDD promotes the use of abstract models to represent different perspectives of a system, hiding implementation details and...

In the previous episode, " From UML Class to Code ," I attempted to expose Platform Independent Modeling (PIM) leading in  Design  so that we can transform to a Domain Specific Language(s) (DSL). I also stated that we do not teach "coding" on this channel, but I do not want to confuse or mislead modelers who are focused on  Design . In our next episode, Model-Driven Design (PIM to DSL Part 1) , I will further explain so that  Design  can be accomplished  in a manner that is not disruptive to the project or your developers. With that said, let's preface  once  again that our focus when doing PIM is "Design ".   This  should be referred to as "High-Level Design" as more "Detailed Design" would be using  real  software language (or Code). So  with  that now said, let's break this episode into two parts: High Level Design and Detailed Design as we move from Model-Driven Design to Model-Driven Code (Development). High-Leve...

Design is the process of creating a plan or blueprint for the construction or realization of something, whether it's a physical object, system, structure, or experience. It involves generating ideas, making decisions, and defining specifications to achieve a desired outcome or solve a particular problem. Too many times, delivery stalls because teams do not start Design early enough. The key is to work in iteration: Analyze, Specify, and Validate in iterative cycles. You do not need to be an expert to start design. Use Design Approaches that work best for you and your team. Software design is the process of conceptualizing and planning the structure, behavior, and functionality of software systems before they are built. It involves transforming requirements into a blueprint that developers can follow to create the software. Software design encompasses various activities and artifacts aimed at ensuring that the resulting software meets the desired specifications, is maintainable, sca...

In this episode, we will focus on " Inspector ". In Sparx Systems Enterprise Architect (EA), the Inspector is a panel that provides detailed information and properties of selected elements within a model. It allows users to view and modify various attributes, relationships, and other details associated with elements such as classes, objects, use cases, actors, etc. Over the past couple of years, I have been in projects where project teams are using a Wiki to drive their projects. First off, I am not against this by any means. After all, wikis started as Knowledge-Management platforms and what is more important to project delivery than access to knowledge, right? However, and OMG!, if you cannot effectively manage knowledge, how useful is your Wiki? Thus to my point about seeing the most atrocious uses of Wiki and then wondering why the company has so much trouble with delivery and/or managing their architecture. What I see is more like "fire and forget"...literally!...