Categories
architecture customer digital-transformation executive model-driven tool-integration

Tool Styles for Architecture

#architecture #clarity #velocity #direction #enterprise #modeling

When doing enterprise architecture as well as systems engineering (or system architecture in detail) the question arises if there can be one meta model like Archimate and one tool that does it all.

That means, supporting the strategic portfolio level (comparable to city planning) as well as the development-oriented system level (architecture for one building at a time).

Roles vs Tool Styles

A very important requirement if talking about ‘enterprise’ is easy access to the captured landscape and its building blocks if for business products, applications, data, or technology as well as blueprints, planned architectures, and governance. This access must be provided for a range of users comprised by many people in the enterprise very probably having various roles and skills.

Since all this architectural information shall not only be consumed but also improved and maintained in a distributed fashion, it becomes clear that a tool focusing on diagram-first modeling style cannot be the answer no matter if based on UML, SysML, Archimate, or any other formal modeling language. The reason is that most of the users are not able to model and only a fraction can be taught due to the costs. Mostly, the focus lies on roles already having a certain skill set you can easily build upon, i.e., mostly roles matching the word ‘architect’. Prominent examples of such expert tools are MagicDraw (Cameo) by No Magic (now Dassault Systèmes), ARIS Architect by Software AG, Adonis by BOC, Innovator by MID, Enterprise Architect by Sparx, and others. But, as we will see, any of these can be part of your overall story.

Since the average user needs a tool that makes live easier and not harder, most EA tool vendors have focused on an approach that is data-first ERP style – typically providing web-based access to collected portfolio information (products, applications, business objects, technologies, and such). That information is presented as profiles or sheets like for each application which can also be updated via data forms. Tools like Alfabet (planningIT) by Software AG, LeanIX by LeanIX, LUY by iteratec, ADOIT by BOC, and others follow this path. From the captured data, they automatically produce dynamic graphical or tabular reports. Some of these tools also support Archimate ranging from basic import over addition to their own metamodels to own metamodels based on Archimate.

But why do EA tools always provide more than Archimate provides? This is because many important aspects in daily life are missing in Archimate like roles and permissions, multi-tenancy, life cycle information (planned, active, deactivated; generally state per date interval), portfolio planning capabilities (as-is, plan, to-be; the later with alternatives), tool integration features (requirements, publication, test management), and a lot more.

Scaled Architecture

On the other hand, the last decade has shown, that focusing only on the strategic portfolio level ignoring the reality on the ground easily leads to the ivory-tower syndrome producing badly accepted plans to change the IT landscape.

In order to avoid this, it is important to couple portfolio data with refined software and hardware architectures. The portfolio acts as the common structure and its content had better reflect the software and hardware inside (compare with reporting). And that’s where the above mentioned architects come into play again. They can bridge this gap by drilling down deeper to system architecture level and even further.

In that case, diagram-first modeling style tools for experts are more appropriate. As mentioned above, these are typically based on UML, SysML, Archimate, another modeling language, or even a combination of those. Modeling tools supporting Archimate as a dialect can make integration with enterprise architecture tools that are also supporting Archimate a little easier.

Conclusion

Being able to address both worlds is an important issue and not an easy task. Common meta models may help, but are not a must. More important is the ability to map high-level enterprise architecture blocks to medium-level system architecture content and that in turn to low-level system design content which can also partly be reverse engineered directly from running systems.

There are also tools that address both tool styles like ADOIT or upcoming versions of Bpanda that might be helpful, too. Let’s call it hybrid data-diagram style. Again, it is not a must, especially if different tools are already set in the organization and shall be integrated. The options are ranging from built-in integration features like export/import capabilities to separate integration tools like Smartfacts which provides a portal merging data from different tools via OSLC or classic synchronization.

Categories
model-driven publication testing tool-integration

Umsetzung von Lean Quality Management

#modeling #testing #generation #integration

(Quelle: Drei Stossrichtungen für die Umsetzung von Lean Quality Management, Stefan Jobst, German Testing Magazin, Ausgabe 02/2020)

In einer Zeit, in der die Beschleunigung der Entwicklungs- und Release-Zyklen für viele Bereiche des Business zu einem entscheidenden Wettbewerbsfaktor geworden ist, wird das altbekannte Dilemma zwischen Geschwindigkeit und Qualität weiter auf die Spitze getrieben. Mit ganzheitlichen Herangehensweisen zur Umsetzung von Continuous Delivery hat sich hier im Softwareentwicklungsprozess im vergangenen Jahrzehnt mit der Nutzung von DevOps-Ansätzen bereits einiges getan.

Automatisierte Erstellung von Testfällen

Ein Teil des Artikels beschäftigt sich mit der automatisierten Erstellung von Testfällen und verweist auf meinen Artikel Model-Driven Test Generation with VelociRator.

Nachfolgende Abbildung veranschaulicht die Rundreise mit ihren Phasen rund um involvierte Tools zu den Disziplinen Requirement Management, Requirement Engineering, Output Management und Test Management.

Rundreise von Epic zu Test

Weiter zur detaillierten Beschreibung.

Categories
model-driven publication testing tool-integration

Model-Driven Test Generation with VelociRator

#modeling #testing #generation #integration

(Abstract of full article submitted to MBSE CES 2020 and Software-QS-Tag 2020 which have both been postponed to 2021; excerpt in German available as part of article on Lean Quality Management in German Testing Magazin)

Abstract

Concept, code, and tests tend to drift apart in larger or longer running projects. A lot of time and money is wasted to keep them aligned and yet to a bad degree. With agile working models and higher frequency of deployment cycles this gets even worse.

Two main reasons are identified:

  1. hands-on working style with insufficiently connected tools
  2. missing refactoring capability for concepts and tests (compared to code where we have learned to love powerful IDEs)

In order to keep concept and code aligned I have presented model-driven system documentation in 2018, see Ni2018 in Publications.

Today I will present model-driven test generation extending that successful alignment even further.

After having motivated model-driven test generation, I will present a little journey that many of us work with, probably on a daily basis. I will start with an epic, manually created by some Product Owner in a well known tracking tool named Jira. Via interface this epic is pushed to a system model in MagicDraw. There, a business analyst describes the impact of the epic on already existing use cases. Then, VelociRator, the model-driven test generator, produces tests from modeled behavior. These tests are finally pushed back to Jira and linked to the initial epic closing the loop with a neat test coverage on the epic. 

An outlook on model-driven test generation for automation will give a hint on how to combine test generation and test automation. Finally, I will conclude with why model-driven test generation saved our back during COVID-19.

How does it work?

The following figure shows the journey in phases around involved tools in the middle.

Now, let’s repeat the quick journey taken above with a more detail.

Define

As PO I create a new issue like an epic in Jira. Let’s name it “Improve CDM and Lead Management”.

Example epic

Initially, the test coverage is empty. After assigning the issue to the team or some analyst of a team, the epic is pulled into a model.

Analyse

The model is our digital twin of the system under design. It contains system use cases describing the logical interaction of users with the system for a set of scenarios.

Impact analysis, minimal version

The analyst identifies which of our use cases are impacted by the new requirement by drawing dependencies from the use cases to the issue.

Optionally, it is also possible to use change elements documenting what has to be changed and why.

Design

Next step is to dive into impacted use cases and change these accordingly.

Example for a workflow given by an activity diagram

The designer checks the steps in the workflow with associated rules, documentation, and expected results. Since testers, designers, and developers do their work based on those workflows, all relevant information is documented here. To the upper left we have highlighted a few steps so that we can easily find them in generated tests lateron.

In addition, but not technically necessary, it is also possible to document the external view as some kind of micro architecture per use case.

Example for external view – use case architecture

Configure Tests

Next, the tester configures the tests inside the model by providing values to test parameters of selected test paths.

Example test configurations

Each row is a test configuration and has name and documentation. All other columns represent test parameters like Account, CustomerType, and so on. When the test generator is switched on, it picks each selected test path and generates a test for each row.

Test

Back in Jira, the tester selects a generated test like the following.

Example for test in Jira, extract, details omitted

The name of the test is constructed from the name of the use case, the chosen alternative (ALT no fit), and the selected test configuration (person1). As part of its description you get a compact use case scenario. You also get full test details including test data and expected results per step.

Closing the Loop

Since the generated tests can be automatically linked to the originating epic, you also get a predefined test coverage.

Example for test coverage

If the tester now chooses to execute one or all of the tests, their results will be immediately reflected in the test coverage. Therefore, the PO can easily follow progress, too.

Presentation

See presentation below