Systems Architecture Delivery
This playlist deals with technology agnostic approaches in delivering business, technologies, and other architecture.
This playlist deals with technology agnostic approaches in delivering business, technologies, and other architecture.
(e1) In "Requirements Engineering for SUCCESS" we get into Requirements, where in system and software are the abilities to do things. The Requirements Engineering (RE) process is a critical step in the software development life cycle as it helps to ensure that the software system being developed meets the needs and expectations of stakeholders, and that it is developed on time, within budget, and to the required quality. While Requirements Development is essential to RE, Requirements Elicitation is the most important consideration for all efforts and delivery SUCCESS!
(e2) I wanted to get into Connectors (Associations) ASAP, so I started a multipart series starting with "Understanding Associations in UML Part 1". Here will apply UML as a visual language to understanding the relationship build of elements in our diagrams (boxes and lines). We will show examples of Aggregation, Composition, and relevance (traceability) in our models and diagrams. Using Chapters, we will touch on Class vs Object, Associations, Aggregation, and start our journey on Relevance (Traceability) (Closing).
(e3) Next we have "Understanding Associations (lines) in UML Part 2". In Object Oriented Design and Development (OOD), it is important to not only important to understand what elements are, and do, but more important to understand the associations, relationships, and purposes of UML Associations (lines between the boxes). In our last session we talked about Instance Level Relationships. In this session we will talk about Class Level Relationships which include Associative Relationships relevant to Associations we talked about in Part 1. This includes Generalization and Realization, and I will show some examples (Closing).
(e4) We conclude the Associations subject in "Understanding Associations in UML Part 3 Dependencies". This session is part 3 of a multi-part series on UML Associations (e.g. Lines). Dependencies is actually the most confusing topic for many modelers. In Model-Driven-Anything (MDA), a reference I coined over 20 years ago, we can use many modeling techniques to accomplish our visions and objectives. First, there is Model-Driven-Development (MDD), then Model-Driven-Architecture (MDA). However, when we are effectively modeling our systems and software, we are moving between MDA, MDD, and other forms of Computer-Aided Software/System Engineering (CASE). Thus the acronym, MDA for "anything" we are modeling, and is done best through Sparx Enterprise Architect (EA) IMHO. I will apply to other modeling platforms as we move forward in this channel (Closing).
(e5) In "Requirements Development Through Activities - Part 1" we start our next multi-part series which has 8 parts. As a very long series of videos, we attempt to break down one of the most important subjects in delivery...Requirements! We will touch on starting Scope Development, using Activities to drive elicitation, and Simulation to support validation (Closing & Next)
(e6) In "Requirements Development Through Activities Part 2" we will pick up where we left off in Requirements Development Through Activities - Part 1. Now with starting scope and Activity Diagrams, we can start to run simulations and collaborate to find gaps in requirements between Current Mode and Future (target) Mode. In a Sparx EA Cloud and/or SQL environment, the Team can work together 24x7x365 on delivery using these Mode-Driven-Delivery capabilities (Outro).
(e7) In "Model-Driven Requirements Development" is Part 3, we pick up where we left off in Requirements Development Through Activities - Part 2. Here we extend from Collaboration and Review of Activity Diagrams to Use Cases. This exercise sets up for the most productive approach to Requirements Engineering, and will support more effective Requirements Development, Solutioning, and Design as we continue in this series. Using such Model-Driven techniques, can save you time and money in your delivery and support time-to-market objectives (Wrap and Next).
(e8) In "Model Driven Requirements Development Through Activities Part 4" we will pickup where we left off in "Requirements Development Through Activities Part 3". This is part 4 of a multi-part series and Requirements Engineering using Sparx Enterprise Architect (EA) and the Unified Modeling Language (UML). We will use Model-Driven Requirements (MDR, MDD) and Test-Driven Design (TDD) techniques to support our delivery (Wrap up and Next).
(e9) In "Requirements Development Through Activities Part 5" we pickup where we left off in Requirements Development Through Activities - Part 4. We will introduce Cover Pages to make navigating your models for all stakeholders easier, plus these will render in your Web implementations. We will touch on Diagram Locking, Faster Requirements Development, Extended Requirement Types, and Auto-Naming. These practices and techniques are essential to better Requirements Engineering and achieving faster time-to-market (Outro).
(e10) In "Requirements Development Through Activities Part 6" we will pick up where we left off in Part 5, and start with connectors to tell your stories through the proper associations. Another view of "connections" is "relevance", in particular, data relevance. We are going to expose the power of Sparx Enterprise Architect (EA) and how it extends UML to more productive and effective modeling-driven delivery (Outro and Next).
(e11) In "Requirements Development Through Activities Part 7" we are going to touch on Teams working the same Models at the same time. This will include some tips/tricks on coordinating between each other while working in the same spaces. This will also touch on Locking Packages, Diagrams, and Elements (Wrap Up and What's Next).
(e12) In "Requirements Development Through Activities Part 8" we will talk about Team Reporting in Sparx Enterprise Architect (EA). Reporting, in project delivery, refers to the process of collecting, analyzing, and presenting information about an Effort's progress, performance, and status. As part of Model-Driven Delivery, each Team Member (stakeholder) may be responsible in delivering various reports for the Effort, Project, and Delivery at various points. You will take what you learned in previous Reporting Videos and start sharing with other team stakeholders. You will get started on using the Sparx Model Library which can be accessed and used by separate project SQL instances (Outro).
(e13) In "RAS Working Across Modelers and Projects Short Version" this session is only to create a short version of "e14 - RAS Working Across Modelers and Projects" for advanced Sparx Modelers. I felt that advanced Sparx EA modelers did not need to sit through the slower and longer video. If this video is too fast and/or over your head, please watch the longer version: https://youtu.be/OIg2HF84x5w.
(e14) In "3 Modelers on Same Diagram in Sync", it's hard to keep this session short as you first need to familiarize yourselves with the Delivery Team, What is being Delivered, What constraints the team may have, and ensure all the necessary practices are in place and understood. In this session we will attempt to capture all of this and show 3 Modelers working together on the same model assets at the same time. With Locking, Versioning, and RAS storage, this should be very easy to follow and understand (Conclusion).
(e15) In "RAS Check Package Dependencies Part 1", this session we will demonstrate Sparx EA Reusable Asset Service (RAS) Check Dependency Capabilities starting with Package Dependency/Import. Then we apply a Normative Registration, and finally with a Complete Dependency Check Registration. As long as you understand GUIDs and how data is managed in Sparx SQL, understanding how Check Dependency works during Registration and Imports should be simple.
(e16) In "2 Modelers 1 Diagram" we will have 2 modelers (UMLO and Eddy) create and work on the same Main Diagram using various approaches to keep them productive and maintain their model diagrams' and elements' integrity. They will work towards building a main shared diagram while modeling in separate workspaces. They will baseline (version) their models as they deliver to the common Main Diagram. While working together, they can Chat live, Discuss, and build Journals (Outro).
(e17) In "Versioning in Modeling" we will talk about "Versioning" Models, Documents, and Code. There are many ways to conduct the versioning of things in your shop, company, or enterprise. The key is to be consistent while following industry best practices. You may version code differently than how you versioning Diagrams, Elements, and Models. You may version Documents and Programs differently than how you version Diagrams and Code. If done correctly, these practices should be "simple", "consistent", "repeatable", and "well defined" (Outro).
(e18) In "Simple Model Driven Delivery" we are going to take what you have learned, in this channel, and step through the sequence of events, processing, and practices, to deliver Architecture using Model Driven Delivery (MDD or MD Delivery). WARNING: It's fast, so you prepare to pause and/or slow the video down. By the end, you should be able to start a new project and work with a team in real-time to deliver your objective (Tips and Closing).
(e19) In "Sparx Baseline vs RAS Baseline" we will compare using Sparx Desktop Baseline methods to Sparx RAS Baseline approach. We will demonstrate the different features between RAS and Desktop Baselining. We will show you how to configure RAS for Baselines, and how to revert back and forth between the two approaches. We will talk about the Pros and Cons of using RAS versus Desktop Baselining. We assume you have watched my previous videos on RAS, Baselines, and Versioning, or are familiar with these concepts. Happy Modeling! (Outro)
(e20) In "RAS Check Package Dependencies Part 1" we will demonstrate Sparx EA Reusable Asset Service (RAS) Check Dependency Capabilities starting with Package Dependency/Import. Then we apply a Normative Registration, and finally with a Complete Dependency Check Registration. As long as you understand GUIDs and how data is managed in Sparx SQL, understanding how Check Dependency works during Registration and Imports should be simple (Wrap Up).
(e21) In "When and What For RAS Check Dependencies" we want to clear up some confusion or conflicts in understanding Sparx EA RAS "Check Dependency" selections, and when to use which during Reusable Asset Service (RAS) Registrations. Also we look to clear up the differences between RAS and Baseline (Outro).
(e22) In "RAS Check Package Dependencies Part 2" we will pickup where we left off with RAS Check Package Dependencies Part 1. We will show you our Sparx EA Reusable Asset Service (RAS) demo configuration and RAS strategy. We will talk about the things to consider before and during Model registration in RAS. We will demo imports to a different Sparx instance, and show you what not to do in order to keep things simple and in sync (Outro).
(e23) In "Traceability Telling Your Story" we start our journey through the Role of Architects especially in Product or Project Realization. Traceability, if done correctly, is the most important factor (or outcome) of Modeling. In an earlier session we covered various UML "Associations" Types. Understanding these Associations helps you "tell your story" through Modeling and Model-Driven Anything. We will go back over the Association Types and what they mean from a Traceability perspective. Most modeling tools, especially "Drawing Tools" under the notion of UML, do not do a good job of telling stories about the model or diagram. Unless you know what each connector is or means, there may be important intelligence lacking in such models (Outro).
(e24) In "Telling A Story Deep Dive" we take what we learned from Traceability Telling Your Story video and do a deeper dive into modeling abilities in telling stories. Whether you are describing an Architect, Scope/Requirements, or writing a script for a book or movie, you can accomplish your objectives using Modeling and Model-Driven-Anything (Wrap Up).
(e25) In Building a Cover Page in Sparx we will build a Cover Page, sometimes referred to as Landing Page or Interstitial Page (not to be disruptive or intrusive). The purpose is to guide your users, including you, through a "flow" that describes interesting or relevant models. In addition, your Cover Page can act as a Web Home Page when publishing your models to your site. We will touch on creating a Cover Page from scratch or from a Pattern. We will create a Cover Page Pattern, and we will set a page as a Default to load when the project loads (Outro).
(e26) In "Requirement Scenario Building" we touch on one of the best methods for Requirements Development to Validation. This approach best supports collaboration with the team, discovering missing requirements, and faster delivery. In previous videos we used Scenarios, in Use Case Elements, to launch Structure Editor and build a step-by-step sequence of events, including Exception Handling and Alternate Flows. This then lead to auto-generating Activity Diagrams and Test Cases. In this video we will do the same, but with Requirement Elements. I was asked to make this video, so you it is (Outro).
(e27) In "Package Control in Sparx EA" we will talk specifically on Package Version Control in Sparx Enterprise Architect (EA). I touch on this in several other videos, but wanted to focus on the subject here today. There are many ways to handle versioning of your models at any level, and this is one option (Outro).
(e28) Overview of the Web UI Series... In "Simple Web UI Design Part 1" we are going to design a simple web site, actually this website, over the course of this series. Part 1 is a high level cursory view of planning and designing a web site. In later parts we will get into the details of diagrams and elements needed to deliver the objectives (Outro). NOTE: This episode will be part of the Systems Architecture Development Series.
(e29) Mapping Out our Website... In "Simple Web UI Design Part 2" we will walk through the Extended Diagram Type and UI Elements to build our Sitemap. We will talk about relationships and using a layered approach for our planned pages. We will also start the Requirements Development processes (Outro).
(e30) Start Requirements Development... "Simple Web UI Design Part 3" is part 3 of a multi-part series on Simple Web UI Design. In part 1 we gave a cursory overview of the series, and in part 2 we started our Sitemap to support Scope and Requirements Development. In this session we will show how we started Requirements Development along with some tips to speed up delivery (Outro).
(e31) Analytics & Reporting (A&R)... In "Simple Web UI Design Part 4" we are on Part 4 of a multi-part series on Simple Web UI Design. In this session, we will touch on Reporting and Analytics (R&A). This is critical to understanding progress in any delivery effort. We will ad simple Pie Charts for status on Requirements and Solution Approach. As part of our Project Dashboard, we can follow the progress of Requirements Development and Solution Approach necessary to support the development of our web site (Outro).
(e32) Taking a break with UI Design Series, we wanted to show more on autogenerating diagrams. In "Scenarios Generated Diagrams" we will focus on auto-generating diagrams using Sparx EA Scenarios and Structure Editor. We will auto-generate various types Activity Diagrams, Sequence Diagrams, Robustness Diagrams, and State Machine Diagrams. We will talk more on this subject in UI Design and Wireframing videos as we progress in this series.
(e33) User Interface (UI) Design...In "Simple Web UI Design Part 5" we are finally to UI Design and Wireframing. In previous sessions we introduced web design concepts (e28), started our Sitemap (e29), developed some Requirements (e30), and created a Dashboard to track our progress (e31). Here we will extend the UI Components from our Sitemap to UI Design. We will learn how to apply UI elements to Screen Elements and even turn them into Graphics. We will learn how to use the power of Sparx EA to deliver our Web Design.
(e34) In "Simple Web UI Design Part 6", we will focus on Sparx EA "Wireframing". UX designers use various tools, including wireframing and prototyping tools, user testing software, analytics, and research methods to gather insights and improve the overall user experience. Sparx EA can check all these boxes, but not by itself.
(e35) In "Simple Web UI Design (Patterns) Part 7" we will talk about the "Patterns" we built and used for designing and implementing our UML Operator Web site. This is the final part of our multi-part series on Simple Web Design. So far, we have covered the basic areas of concern in developing a Website. From Requirements to Implementation, we now have foundation for building and managing our website going forward.
(e36) In "Reusing Intelligence in Reporting" I want to show two use cases for the Model Document element in Sparx EA. 1) If the Data is in the same Project instance; and 2) if the "Data" is used across many project instances. We will use the Model Document element in both cases and touch on RAS for more global reuse.
(e37) In "Introduction to BPMN Part 1" we will introduce Business Process Modeling Notation (BPMN) as an alternative to just Activity Diagrams. BPMN, released in 2004, is a graphical modeling language specifically designed for representing business processes and workflows in a standardized manner. We will start with BPMN 1.x and we will bring in our other modeling approaches, recently covered in this channel, for support "simulations", "testing", and validation.
(e38) In "BPMN and Scenarios" we will bring BPMN (Business Process Modeling Notation) and Sparx UML Diagrams together for delivery. We will use a simple BPMN Model and Scenarios together to support how our Business Process Flows can technically work. These capabilities support Business Processes and technical Software and System Engineering.
To see what's coming next, visit the Home Page and "In the Pipeline...".