Displaying items by tag: ibm
Softacus provides a training program on the Automotive Compliance Process from IBM which is released with the IBM Engineering Lifecycle Management Solution.
Type: Instructor-led Classroom
Duration: 24 hours
Location: Remote or Onsite (World-Wide)
What is Automotive Compliance (AC) Process
The AC Process is a well documented process definition which includes the following:
- Process Roles
- Process Activities and Tasks
- Process Work Products
- Tool Guidance (enacting the process with IBM ELM toolchain)
- Templates for IBM ELM tools supporting the AC Process (templates are provided for IBM DOORS Next Generation ® (DNG), IBM Engineering Test Management ® (ETM), IBM Engineering Workflow Management ® (EWM) and IBM Architecture Management ®(AM))
- ISO 26262, ISO/SAE 21434 standards and ASPICE Capability Model topics
- Mapping between process elements and ISO 26262, ISO/SAE 21434 and ASPICE standards to ensure compliance.
- The AC Process is designed based on SAFe (Scaled Agile Framework), to support an agile systems and software engineering approach.
The AC process is developed and documented in order to provide a process framework to the followers of this process, which will definitely help to comply with the target standards (ie, ISO 26262, ISO/SAE 21434 and ASPICE).
The Automotive Compliance Process provides a process framework for system development that takes into account the certification needs for:
- ASPICE Base and Generic Practices
- ISO 26262 Functional Safety requirements
- ISO/SAE 21434 Cybersecurity requirements
The AC process definition has a mapping between process activities / work products and these standard requirements. This means, when a work product is generated in compliance with the AC Process or a task / activity is conducted again from the AC Process, you know which standard requirement is being covered and satisfied.
That will enable an effective gap analysis between project work and standard requirements.
IBM ELM Automotive Compliance Process Training Topics
We provide a custom training program developed for our customers’ needs. Our target outcome of this training program is, in addition to understanding the basic usage of the IBM Engineering Management Solution tools (namely, DNG, ETM, EWM and AM), also explore how these tools and solutions can be / should be used in the context of the Automotive Compliance Process.
During the training we run an instance of the process flow on a sample system development example from the Automotive industry.
We try to provide answers to the following selective questions during the training:
- How do we elicit stakeholder requirements?
- How do we analyze / review system requirements?
- How to identify main capabilities of the system and plan requirements for different releases / variants?
- How to link requirements with test cases in different levels of the V-lifecycle?
- How to develop test cases and manage manual test runs
- How to plan development activities iteratively, using agile methodology?
- How to incorporate system architectural design (with requirements)
- How to prepare a traceability matrix between requirements, work items, plans, architecture (logical / physical) and tests.
- How to manage versions and variants
All these questions are approached in the context of the Automotive Compliance Process.
Benefits of the Automotive Compliance Process Training
Upon completion the IBM Automotive Compliance Process, you will have practical knowledge on:
- how to apply the process tasks on the IBM Engineering Lifecycle Management tools
- how to merge tool usage with process flow.
Contact us to get a customized offer for your team. Upon discussion, we will learn your processes and incorporate key elements and terms used by your team into the training program.
Apr 25, 2023 from 12:30 PM to 01:00 PM (ET)
Want to learn more about IBM Turbonomic hybrid cloud cost optimization features, capabilities, and use cases in a quick, no-pressure setting? Join the Turbonomic Monthly Deminar for an informative 15-minute demo followed by Q&A. We'll over an overview of the Turbonomic platform, walkthrough of the UI, and use cases including cloud cost optimization, cloud migration planning, on-prem virtualization optimization, and more.
- Get a detailed overview of Turbonomic from a Turbonomic expert
- Learn how Turbonomic uniquely automates decisions to minimize cloud costs while assuring application performance
- Ask our expert questions about Turbonomic
Our experts will give an in-depth comparison of Maximo Application Suite Dedicated and Maximo Application Suite as a Service and will dive into the preconditions, process, timeline, and roles and responsibilities for migrating workloads from a client-managed EAM installation to an IBM-managed MAS Dedicated or MAS SaaS solution. Come hear from our team who has been delivering hosting for Maximo for more than 20 years. Also, check out the free MAS trial: Click here for the MAS Trial
We are pleased to announce that our company has been awarded at the IBM Ecosystem Kick-off DACH 2023 in the category Sustainability Software for exceptional growth in Engineering Lifecycle Management.
With tools and add-ons developed in-house for IBM products, Softacus has managed to demonstrate added value for customers and thus increase their competitiveness.
We look forward to continue working together with IBM to create innovative solutions that will have a positive impact on our society and the world!
Auch dieses Jahr wird Softacus bei der REConf, die vom 24 bis 28. April 2023 stattfindet, sein.
Die REConf (Requirements Engineering Conference) ist Europas führende Konferenz mit Schwerpunkt Requirements Engineering. Auf der Veranstaltung werden neue Methoden, Trends und Tools in Vorträgen, Diskussionsrunden und Workshops diskutiert.
Am zweiten Tag der Konferenz (25 April) um 16:00 Uhr wird unser Solution Director, Jan Jancar, zusammen mit Peter Schedl von IBM, einen Vortrag zum Thema "Traceability - das Salz in der Suppe" halten.
Anforderungen sind der Ausgangspunkt der Entwicklung und somit auch der Traceability für alle Entwicklungsdaten. Projekte stellen heute bereits sicher, dass alle Kundenanforderungen in Systemanforderungen überführt wurden und Testfälle spezifiziert sind. Nicht selbstverständlich ist die Traceability in Verbindung mit KPI’s oder der toolgestützten Impactanalyse bei sich ändernden Anforderungen.
Softacus zeigt gemeinsam mit IBM Best Practices wie sich solche Szenarien mit DOORS und der Engineering Lifecycle Management Lösung einfach abbilden lassen.
Melden Sie sich für RECconf 2023 hier an: https://www.hood-group.com/reconf/anmeldung
The history is an important part of the requirements management tool and the purpose of this article is to explain functions and capabilities of DOORS Next for working with history of requirements.
On the very basic level history of requirements management items in DOORS Next is organized on artifacts level and is presented as revisions and audit history. This information is accessible for artifacts via ‘Open history’ action in the menu (Figure 1).
The first tab you see when you open history is ‘Revisions’, it is splitted on ‘Today’, ‘Yesterday’, ‘Past week’, ‘Past month’ and ‘Earlier’ sections which include different versions of an artifact and baselines of project area or component. When you switch to the ‘Audit history’ tab you see only versions of a current artifact with explanation of actions performed on it and changes which were created with information on date and time and author of it.
Revisions can be restored to the current state. To revert the requirement to a previous state you need to use artifact menu and select ‘Restore’ action (Figure 3).
History in attributes
Another source of history of an artifact are system attributes, which preserve information on date and time of creation and modification of an artifact and a user who created and modified an artifact. These attributes are updated by the application on creation of an artifact (Created On for date and time of creation and Created By for username) and Modified On and Modified by for the latest modification. Additionally, if you use ReqIF import to add artifacts, attributes with the prefix ‘Foreign’ will show you related information from the source (Figure 4). Attributes with prefix ‘Foreign’ will display timestamps and usernames from the source of imported requirements.
Of course, a revision list and attributes of a single artifact is not enough to manage requirements history, so versions of artifacts are aggregated to baselines. The first kind of baselines is a DOORS Next baseline, in other words it can be explained as a snapshot which includes certain revisions of artifacts. Baselines are created to preserve some agreed state of requirements, artifacts cannot be edited in a baseline (Figure 5).
When we are talking about artifact revisions It is meaningful to mention that module revisions are specific - they are created when module structure is changed (a set and / or order of included artifacts) or attributes of a module as an artifact itself. So when you edit an artifact in module context without changing position of this artifact in module (Figure 6, marked with green color) - you do not create new revision of module automatically. Only insertion of new artifact, editing module attributes (Figure 6, marked with purple) or moving artifacts within a module will update attributes of a module with date & time and contributor name. To capture the complete state of a module you need to create a DOORS Next baseline.
History in streams and changesets
DOORS Next with configuration management capabilities has more options to manage history of requirements. First of all - streams, which allow you to have parallel timelines for different variants of requirements. All requirements in DOORS Next have their initial stream, which is the default timeline for requirements changes. DOORS Next has an option to create a parallel timeline using additional streams, which is mostly used to manage variants of requirements.In this case usually some existing version of requirements is used as an initial state for a new stream. And changes of artifacts in a new stream will not affect the initial stream - revisions of artifacts created in a new stream are visible only in this stream unless the user initiates synchronization (see Figure 7, the module is shown in two different streams - stream names and changed artifact are coloured with purple). During synchronization the user has options with merging approaches, and one of them is using changesets, which are explained below.
Changesets are another kind of data set in DOORS Next which can be observed in the audit history. There are two types of changesets - user created changeset (name of changeset in this case is specified by user) and internal changeset, which is a reference for changes in the audit history. Internal changesets can be found in the audit history and can be also used as an option to deliver changes across streams. Created by user changesets aggregate small changesets automatically created by DOORS Next, which can be found in audit history and in the merging menu when you deliver changes from one stream to another. Both types of changesets can be found on stream’s page, and if a stream is allowed to be edited only via changesets - it means, users are forced to create a changeset to edit requirements in a stream - a list of changesets of a stream gives you a good representation of history for a stream (Figure 8).
Another functionality to manage history is Global Configuration baseline. When you enable DOORS Next project area for configuration management, links between requirements in different components are created via Global Configuration stream - you need to switch to Global Configuration context to create a link across DOORS Next components and also to see such links. As each component is baselined independently in DOORS Next, in order to preserve cross-component linkage state you need to create a Global Configuration baseline. When you perform this action, baselines are created on each component level automatically and included to a Global Configuration baseline. Switching to this baseline in the future will show you the exact state of linking at the moment of global baseline creation - proper links between proper revisions of artifacts (Figure 9).
DNG functionality of configuration comparison can be used between streams, baselines and changesets and provides overview of changes in history and/or across variants on several layers - type system (data model), folder structure, and the data itself (including module structure, artifacts text and attribute values, links) with an option to filter changes (Figure 10).
Tips and tricks
- As mentioned above, baselines are created on component level (or project area level if project area is not enabled for configuration management). When number of baselines grows, some maintenance of baselines is required - to shorten the list of baselines, some of them need to be archived
- To help users with navigation in list of baselines we provide special widget, which filters from the flat baseline list those baselines which were created in a certain module context
- Links operations to not modify artifacts, link changes can be found in configuration comparison results
- To support filtering history events in a module scope Softacus provides special widget, which allows to get list of artifacts modified in a module scope
- Using change sets to update streams with link from change sets to Engineering Workflow Management work items adds context for history with explanation of a reason for changes
Softacus has been selected as one of the Top 10 IBM Solution providers for 2022 by the CIOApplications Europe - a popular European magazine on innovations and technology.
In this article, featured in the magazine in December 2022, our Solution Director, Jan Jancar, talks about the challenges engineering teams are facing nowadays and how Softacus and the IBM Engineering Lifecycle Management solution help organizations improve collaboration among software and system developers, increasing efficiency and product quality.
IBM® Rational® DOORS® Next Generation is consistently one of the best requirements management tools out there. One of its biggest strengths is the opportunity to expand its capabilities by the people using it, so that they can utilize it to its fullest. Whether you are someone who already uses IBM® Rational® DOORS® Next Generation on a regular basis or someone who is considering using it, the knowledge of how you can optimize your work environment is the key to peak productivity in the workplace.
Purpose of the article - OS Gadgets
Here is how an OpenSocial Gadget is defined:
Another feature involves viewing and designating the current artifact selection and reacting to when the artifact has been interacted with (opened, selected, saved…)
Furthermore, the API offers a User picker and an Artifact picker.
Adding and creating OpenSocial Gadgets
How can you start using OpenSocial Gadgets? Well, you can either add gadgets that already exist to your Mini Dashboard (a compact dashboard that you can have constantly on hand - pinned to the web UI) or you can create your own OpenSocial Gadgets.
While the entire creation process is too complex to be described in this short article, it can be boiled down to six essential steps.
The first step will be the most important for the development as you have to establish the goal for its functionality and what will it be used for. This is crucial because having a clear aim in mind will greatly help you with the creation and implementation process.
For the second step, you will need to acquire the tools and libraries essential for developing your gadgets (e.g. web server, text editor, OpenSocial container). In other words, you will need to put your development environment in order.
For the fifth step you will move onto one of the most critical development stages - testing and debugging, through which you can ensure that your gadget is working as intended and remove any problems that may arise. You can do this in DOORS Next Generation or in an OpenSocial container.
Finally, you should now be at the end of the journey of developing an OpenSocial Gadget and should be able to deploy it to DNG. You will most likely be doing this by uploading it to DOORS Next Generation. Then you can finally include it in a dashboard or wherever you will be able to/need it.
Additional OS related activities
Another thing is, that a situation can occur when a widget makes an external request (call to an external server). If this happens, what you have to do is enable Cross Origin Resource Sharing if you wish for the request to go through.