Článok: Installation of IBM ELM

Tento článok popisuje naše skúsenosti pri implementáciách produktu ELM (Engineering Lifecycle Management) od IBM.

Introduction

Aplikácie ELM sú vedúcou platformou pre komplexný vývoj produktov a softvéru. ELM rozširuje štandardné funkcionality ALM produktov. Poskytuje integrované komplexné riešenie, ktoré ponúka úplnú transparentnosť a sledovanie všetkých technických údajov, cez požiadavky, testovanie a nasadenie. ELM optimalizuje spoluprácu a komunikáciu medzi všetkými zainteresovanými stranami, zlepšuje rozhodovanie, produktivitu a celkovú kvalitu produktu. Tento produkt prešiel značnou aktualizáciou a zmenil aj svoj názov z CLM (Collaborative Lifecycle Management) na ELM (Engineering Lifecycle Management).

Hlavné rozdiely medzi CLM a ELM sa týkajú zmeny názvov produktov:

• Rational DOORS – v ELM sa nazýva IBM Engineering Requirements Management DOORS Family (DOORS)
• Rational DOORS Next Generation (DNG) – v ELM na nazýva IBM Engineering Requirements Management DOORS Next (DOORS Next)
• Rational Team Concert (RTC) – v ELM na nazýva IBM Engineering Workflow Management (EWM)
• Rational Quality Manager (RQM) – v ELM na nazýva IBM Engineering Test Management (ETM)
• A mnoho iných...

Od verzie 6.0.6.1 sa už zmenilo aj používateľské rozhranie. Niektorým aplikáciám sa však názvy nemenili, ako napríklad Report Builder, Global Configuration Management, Quality Management, atď.

K ďalším rozdielom medzi CLM a ELM patrí to, že ELM podporuje rôzne webové aplikačné servery, operačné systémy a databázy. Pre maximálnu flexibilitu pri prijímaní nových pokročilých funkcií a na zjenodučenie potenciálneho budúceho presunu na alebo z:

• IBM ELM na Cloud SaaS
• IBM ELM ako Managed Service
• IBM ELM kontajnerizované na RedHat OpenShift, ktoré je v súčasnosti vo vývoji

 Aktuálna verzia, ktorú inštalujeme je 7.0.2 SR1 (ifix15). Tento produkt sa zameriava primárne na zákazníkov z oblastí zdravotníctva, armády, dopravy a mnohých ďalších kritických oblastí priemyslu a výroby. Medzi hlavné spoločné požiadavky týchto oblastí priemyslu patria rýchlosť, spoľahlivosť, flexibilita a bezpečnosť. Pre efektívne a spoľahlivé fungovanie ELM riešenie je dôležitá prvotná analýza požiadaviek a plánovanie.

Purpose of the article - challenges

Po definovaní požiadaviek klienta (požadované aplikácie, architektúra) sa pristupuje k samotnému nasadzovaniu produktu ELM. Pri návrhu zohľadňujeme požiadavky klienta, prispôsobujeme architektúru k už existujúcej infraštruktúre s technickými požiadavkami produktu ELM. ELM produkt podporuje implementáciu na operačných systémoch Linux (RedHat), Windows a IBM AIX.

IBM ELM ponúka viacero aplikácií, pričom nižšie sú uvedené niektoré z nich:

• JTS (Jazz Team Server)
• CCM (Change and Configuration Management)
• RM (Requirements Management)
• QM (Quality Management)
• ENI/RELM (IBM Engineering Lifecycle Optimization - Engineering Insights)
• AM (IBM Engineering Systems Design Rhapsody – Model Management)
• GC (Global Configuration Management)
• LDX (Link Index Provider)
• Jazz Reporting Service, obsahujúci viacero aplikácií:
  •  RS (Report Builder)
  •  DCC (Data Collection Component)
  •  LQE (Lifecycle Query Engine)
• JAS (Jazz Authorization Server)
• RPENG (Document Builder) – ktorý je implementovaný ako samostatná inštalácia

Pri veľkých infraštruktúrach odporúčame implementovať každú aplikáciu na samostatný server. To ale značne zvyšuje finančné požiadavky. Pre menej nižších požiadaviek na ELM hľadáme čo najvýhodnejší balans medzi výkonom a spoľahlivosťou za účelom dosiahnutia čo najlepších výsledkov vzhľadom k ich možným finančným obmedzeniam. Optimalizácia IBM ELM riešenia môže spočívať aj v tom, že na jednom serveri budú nasadené viaceré aplikácie naraz. Implementácia viacerých aplikácií na jednom serveri sa využíva pri menej používaných aplikáciách. Na základe našich skúseností sa nám overilo takéto logické usporiadanie aplikácií na serveroch (ASX):

• AS1: JTS, LDX, GC
• AS2: QM, CCM
• AS3: DCC, RPENG
• AS4: LQE, RS, RELM
• AS5: RM

Pre lepšie pochopenie architektúry uvádza nasledujúci obrázok návrh možnej logickej topológie:

Preferred solutions

Odporúčaním pre veľkých zákazníkov je inštalácia každej aplikácie na samostatný server, v prípade, že im to dovoľujú technické a finančné obmedzenia prostredia u zákazníka. Z toho ale vyplývajú zvýšené serverové náklady, ktoré pozostávajú z inštalácií, licencií, upgradov a „resources“ potrebných na prevádzku daného riešenia. 

U malých a stredne veľkých zákazníkov na základe úvodnej analýzy odporúčame inštalovať menej používané aplikácie na zdieľaný server. Časom ale môže dôjsť k vzniku problémov s pamäťou a vyťaženosťou systémových zdrojov. Pri správne navrhnutej architektúre je možné tieto aplikácie rozdeliť bez straty dát. Pre detekciu, prevenciu problémov a plánovanie do budúcna je odporúčané nasadiť monitorovací systém.

Z výsledku prvotnej analýzy sa určuje, ktorá aplikácia bude inštalovaná samostatne na serveri. Na samostatné servery je tiež vhodné inštalovať tie aplikácie, ktoré zákazník využíva pravidelne a obsahujú obrovské množstvá požiadaviek. Ostatné, menej výpočtovo a pamäťovo náročné aplikácie je možné prerozdeliť tak, aby vedeli zdieľať výpočtový a pamäťový výkon. 

Nevyhnutnou časťou každého ELM nasadenia je aplikácia JTS, ktorá zabezpečuje prepojenie jednotlivých aplikácií. Odporúčaným nasadením ELM balíkov do infraštruktúry je použiť IHS (IBM HTTP Server), ktorý je nakonfigurovaný ako Reverse Proxy. 

Nutnou súčasťou riešenia je implementácia databázového servera. Databázový server uchováva väčšinu dát, preto je potrebné mu venovať zvýšenú pozornosť pri nasadzovaní a výbere vhodného produktu. Medzi základné databázy pri inštalácií patrí Apache Derby, ktorý je určená primárne na testovacie účely s obmedzením na maximálne 10 používateľov. Táto databáza nie je určená pre produkčné prostredia, a preto ju neodporúčame. Medzi databázy vhodné pre produkciu aj testovanie patria:

• IBM DB2
• Oracle
• Microsoft SQL Server

Ak je inštalácia realizovaná cez cloud, preferované použitie je DB2 databázy. V prípade veľkých firiem je preferované použiť Oracle databázu. Použitie týchto databáz sa priamo odvíja od počtu používateľov a od množstva používateľských dát. 

Po nainštalovaní produktu sa venujeme implementácií overovania používateľov a zabezpečenia. Pre základné zabezpečenie sa používa WebSphere Liberty basic registry, ktorý je dostupný hneď po inštalácií, avšak táto možnosť sa odporúča iba na testovacie účely. Ďalšie možnosti autorizácie sú napríklad využitie protokolu LDAP, ktorý môže byť doplnený o inštaláciu JAS (Jazz Authorization Server). Pri možnosti autorizácie pomocou LDAPS sa používatelia autorizujú pomocou hierarchickej štruktúry používateľov. JAS rozširuje riešenie o OAuth2.0 protokol. Toto riešenie ponúka aj možnosť autorizácie aplikácie tretích strán. 

Specialized solutions, approached and tips

Z pohľadu Softacusu sa snažíme prispôsobiť sa potrebám zákazníkom a vykonávať inštalácie v súlade s ich zaužívanými štandardmi. Na základe požiadaviek klienta vieme v Softacuse pracovať na diaľku, no v prípade zákazníkov z kritickej infraštruktúry vieme pracovať aj na mieste. Pre bezpečné používanie sa využívajú technológie VPN (Virtual Private Network).

Pri inštalácií je potrebné zabezpečiť, aby inštalované IBM ELM aplikácie nemali prístup na prostredia, ku ktorým nemajú autorizáciu. Pozor taktiež treba dávať na inštaláciu aplikácií, ktoré sú uvedené, ako “package“ (aplikácia, pri ktorej je na výber sada podaplikácií – klient si zvolí, ktoré podaplikácie potrebuje). Po inštalácií a následnom nastavení prostredia je potrebné overiť funkčnosť systému, pri čom asistuje testovací tím (Softacus).

Jedným z posledných krokov po vykonaní inštalácie a zabezpečení serverovej komunikácie je zvážiť zálohovanie dát. Pri zákazníkoch je potrebné sa zamýšľať nad „disaster recovery“ plánom (vysporiadaním sa s potenciálnymi nehodami) a taktiež je potrebné naplánovať pravidelné zálohovanie dát z dôvodu zabezpečenia dát pred stratou alebo zlyhaním systému. Nevyhnutnou časťou každej infraštruktúry v tejto dobe je už aj monitoring. Monitoring pomáha s predikciou a zlepšuje reakciu na nežiadúce udalosti na serveroch a aplikáciách.

Conclusion

Implementácia ELM produktu obsahuje analýzu, plánovanie, nasadzovanie a neustály monitoring. V Softacuse pracujeme na zlepšovaní a zefektívňovaní počas celého priebehu riešenia. Je to súvislý a komplikovaný proces, počas ktorého je možné implementovať nové funkcionality a rozšírenia do prostredia zákazníkov. 

Introduction

Configuration Management has always been a difficult problem to solve, and it tended to get more and more difficult as the complexity of the products increased. As end-user expectations evolve, development organizations require more custom and tailored solutions. This introduces a necessity of effective management of versions and variants, which introduces more sophistication to the problem. The solution to being able to manage a complex product development lifecycle in this sense also requires a solution in a similar sophistication level.

The complexity of the end-products and being able to be tailored for the end user are not the only concerns for system developers. What about increasing competitive pressures, efficiency, etc.? These also have increasing importance when considering developing a system. 

Challenges in Product Development

Of course, when we talk about developing a system, we should think about how companies will be able to develop multiple products, share common components, and manage variants, product lines, and even product families, especially if this system needs to be able to answer many different types of user profiles, expectations, needs, and so on.

One main concern for such companies is how to optimize the reuse of assets across such product lines or product families for effective and efficient development processes. Such reusability may introduce new risks without being governed by effective tools and technologies. For instance,  a change to a component in one variant or one release cycle, may not be propagated correctly, completely, and efficiently to all other recipient versions and variants.

This may result in redundancy, error-prone manual work, and conflicts. We do not want to end up in this situation while seeking solutions for managing product lines, families, versions, and variants. In this article, we would like to provide a brief explanation of how IBM Engineering Lifecycle (ELM) Solution tackles such challenges by enabling a cross domain configuration management solution across requirements, system design, verification and validation, and all the way down to software source code management.

This solution, Global Configuration Management (GCM), is an optional application to the ELM Solution, which  integrates several products to provide a complete set of applications for software or systems development.

The Solution

Global Configuration Management (GCM) offers the ability to reuse engineering artifacts from different system components with different lifecycle statuses across multiple parts of the system. Stakeholder, system, sub-system, safety, software, hardware requirements, verification and validation scenarios, test cases, test plans, system architectural design, simulation models, etc. can be reused as well as configured from a single source of truth for different versions and variants. Each of these information sources above has their own configuration identification as per their domain and lifecycle. One main challenge is to combine all these islands of information into one big configuration.

Fig1

In the example above, there are 3 global configurations: 

• A configuration which was sent to manufacturing, the initial phase of the ACC (Adaptive Cruise Control) 
• A configuration where the identified issues are being addressed (mainly to fix some software bugs) 
• And a configuration on which engineering teams are currently working on to release the next functionally enriched revision.  

All these configurations include a certain set of requirements; test cases relevant to those requirements which will be used to verify the requirements; a system architecture parts which satisfies the requirements and will be used during the verification process; and if the system also includes any software the relevant source code to be implemented.

Of course, the sketch above can be extended to a full configuration of an end product, for instance a complete stand alone system like an automobile. In this case, we define a component hierarchy to represent the car. For a reference on component structures for global configurations the article from IBM here can be used.

In such applications of GCM a combination of components of the system and streams can be used to as follows to define the whole system:

Fig 2: Image from article: "CLM configuration management: Defining your component strategy" - https://jazz.net/library/article/90573

In such examples, the streams represented as right arrows on an orange background (global stream: ) correspond to a body part of the system and is constituted by several configurations of relevant domains. For instance, an “air pressure sensor” is defined by a set of requirements for this part, as well as a system design for the sensor and its test cases to verify the requirements. All these domain level, local configurations correspond to different information assets. The global configuration can be defined in such a way that if a different configuration is defined for Ignition System ECU (different baseline is selected for Ignition System ECU Requirements, Test Plans and Cases and Firmware) we end up with a different variant of the system. This effect is illustrated in the figure below:

Fig 3:  Developing 3 different variants at the same time, facilitating reusability.

We may have a base product and different variants being developed to this base product. The variants may share  considerable commonality, and they are based on a common platform. This platform is considered as a collection of engineering assets like requirements, designs, embedded software, test plans and test cases etc.

Effective reuse of the platform engineering assets is achieved through the Global Configuration Management application. Via GCM, ELM can efficiently manage sharing of engineering artifacts and facilitate effective variant management. While a standard variant (or we can call it also as Core Platform) is being developed (see Fig 3), some artifacts constituting specifications, test cases, system models and source code for sub systems, components or sub-components can be directly shared and reused, while others may undergo small changes to make a big difference. Sometimes there might be a fix that surfaces in one variant and should be propagated through other variants as well because we may not know if that variant is affected by this issue or not. Such fixes can easily and effectively be propagated through all variants making sure that the issue is addressed on those variants as well. This is because all artifacts regardless of being reused or changed, are based on one single source of truth and share the same basis. This makes comparison of configurations (variants) very easy and just one click away.

ELM with GCM manages strategic reusability by facilitating parallel development of the “Standard Variant” (Core Platform) and allows easy and effective configuration comparison and change propagation across variants.

Tips and Best Practices for GCM

The technology and implementation behind GCM are very enchanting. Talking about developing systems, especially for safety-critical systems, a two-way linking of information is required. Information here is any engineering artifact, from requirements to tests, reviews, work items, system architecture, and code changes.

So one should maintain a link from source to target and also the backward traceability should be satisfied from target to source. How is this possible with variants? There must be an issue here, especially when talking about traceability between different domains, say between requirements and tests.

To be more specific, let's look at a simple example:

In this example, we have two variants. The initial variant is made of one requirement and a test case linked to that requirement. Namely, "The system shall do this," and the test case is specifying how to verify this. The link between the requirement and the test case is valid (green connection). Now, in the second variant, we have to update the requirement. Because the system shall do this under a certain condition. Both requirements have the same id. They are two different versions of the same artifact. We can compare these configurations and see how the specification has changed from version 1 to version 2. But now, what will happen to the link? Is it still valid? Is the test case really testing the second version of the requirement? We have to check. That is why the link is not valid anymore in the second variant.

The team working on the first variant sees that the test case exactly verifies version 1 of the requirement. But the team working on the second variant is not sure. There is a suspect between the requirement and the test case because the requirement has changed. How is this possible with bidirectional links? Actually, it is not. Because it is supposed to be the same link as well, like it is the same version of the requirement. So we also kind of version control the links. However, if we anchor both sides of the links to the different artifacts on different domains, creating two instances for the same link is not possible. ELM enables this by deleting the reverse direction of links when Global Configuration is enabled and maintains the backward links via indices. This is the beauty of this design. Cause links from source to target exist but, looking backwards, are maintained by link indices, which makes the solution very flexible for defining variants and having different instances of links between artifacts among different variants.

There are some considerations to make when enabling Global Configurations in projects. The main question I ask to decide whether to enable it or not is, do I need to manage variants? How many variants? Is reusability required? Answers to these questions will shed light on the topic without any second thoughts. 

Then what is a component, how granular should it be, how to decide on streams and configurations. What domains should be included in GC, when to baseline, definition of a taxonomy for system components. Would also be typical questions on designating the global configuration environment. The discussion of this topic requires a separate article to focus on. Let's leave that for next time, then.

Conclusion

IBM ELM’s Global Configuration Management (GCM) is a very specific solution for Version and Variant Management and is designed to enable Product Line Engineering, by facilitating effective and strategic reuse.

With GCM implemented, the difficulties around sharing changes among different variants disappear, and every change can be easily and effectively propagated among different product variants.

GCM mainly helps organizations reduce time to market and cost by reducing error prone manual and redundant activities.

It also improves product quality by automating the change management process  which can be  used by multiple product development teams and multiple product variants.

References

When:  Oct 13, 2022 from 09:00 AM to 10:00 AM (PT)