SW Engineering Tool Support

1. SW Engineering Tool Support

2. Content • Short introduction • ES activities • ES & MMP Helpdesk • Software Tool Support: • Configuration Management: Telelogic Synergy • Requirement Management: DOORS • Model Driven Development: Rhapsody • Change Management: Telelogic Change • Module testing: RTRT • Code coverage: SCC • Testing: SiTEMPPO • Testing: TTworkbench • Tool Scripting • Core messages

3. Medieval Helpdesk • how it was made in the past... • in the next slides, you will see how we are doing it in our days...

4. Engineering Support: About us • Software support: responding to customer needs with relation to software product/ application operation, management, maintenance and enhancement. Software support activities may include software product installation, integration, configuration, upgrades, updates, performance analysis, and customer interactions to address basic software product usage issues. • External tool support: the service provided by the vendor to deal with technical questions and problems with the software system. It is usually given by telephone or e-mail and includes help in installing and using the products. • Internal tool support: offering support to developers, testers... for various internal tools. • Why ask help from ES? • because we: • install, configure and maintain tools used during software and hardware development • train and support colleagues for proper usage of the various tools for configuration and change management, requirement management, compiling, testing, etc. • report bugs to the tool vendor • evaluate the new releases of existing tools and new tools if necessary • develop and maintain scripts which are written e.g. in Perl, Java, SQL, C#, C/C++ • make life easier at work for all colleagues!

5. Central Support User 1st Level 3rd Level Global Responsible Ticket System Central Support 2nd Level Local Admins

6. ES Helpdesk – Life Cycle 1st Level User User Ticket System Ticket System Central Support 2nd Level Local Admins User • contacts the Central Support (phone, email, ticket) • will get help • from Central Support (1st level) • or local tool admins (2nd level), if 1st level can't solve problem

7. Activities 1st level 1st Level User 3rd Level Global Responsible Ticket System Central Support 2nd Level Local Admins Central Support: receives phone call, email, ticket from user enters request in ticket system decides to solve the problem immediately, forward it to 2nd level or 3rd level support

8. Activities 2nd level 1st Level User 3rd Level Global Responsible Ticket System Central Support 2nd Level Local Admins get in contact with user if needed contacts 3rd level if needed (e.g. major tool problem, needs help from tool vendor, etc.) Local admins: receive email/ ticket work on problem depending on severity of ticket

9. Activities 3rd level 1st Level User 3rd Level Global Responsible Ticket System Central Support 2nd Level Local Admins Global Tool Responsible: gets ticket or email from 1st level or 2nd level support submits CR/PR if problem isn't solvable writes entry in FAQ knowledge base publishes information in Newsletter/Webpage etc.

10. Remedy – Action Request System • Is the system where the incidents are registered/ managed/ monitored (The incidents are requests of getting access, installing different applications, solving some problems/ errors appeared during running a program). • By Registering all the incidents receive a number (ticket id) through which automatically and easily can be found in the system. • By Managing all the incidents are categorized, transferred to the competence group and then solved by contacting the user or not (depending by the offered solution). • The incidents are monitored from their opening until their closure. The statuses through they get by are monitored: • assigned – the ticket is assigned to a group and someone must take it in work (investigate & solve the problem) • in work – already is handled by a software engineer • on hold – response at the long/ short time offered solution • solved – the problem was solved and the user informed about this. • A ticket can be updated, if it is necessary, with the possible remarks/ conclusions. By Monitoring it can be also followed up if it is fulfilled the SLA (Service Level Agreement) – the necessary time to close (solve) an incident.

11. Remedy – Action Request System

12. MMP Helpdesk • What is MMP Helpdesk? • ES provides an interface between the developers and the SW experts • a knowledgebase (WIKI included) is actively maintained by the Helpdesk • already existing solutions are provided or the experts are contacted but only via Helpdesk • Why is MMP Helpdesk needed? • great time saving for SW experts who do not need to explain same things over and over • short response time for developers • Helpdesk for developers of MMP based applications regarding • Target (set up, flash, error messages, ....) • Baseline (changes, new features, specific settings, documentation, ...) • Build Environment (settings, compile/build process, ...) • Architectural issues, Interfaces • Tool problems/ questions

13. Application developer MMP Helpdesk – how does it work? Reports MMP Helpdesk Ticketing System Telco • MMP Helpdesk: • receivesphone calls, emails, ticketsfrom users • inserts the requests in the ticketing system • decidesto solvethe problem if he is able or initiates a telco with an MMP Expert and the developer MMP Experts (architects, integrators, developers ...)

14. Tools used in our department

15. SITEMPPO SyRM SyTest Doors SITEMPPO Rhapsody Metric DB MS Build Env. SyA SyInt QAC QAC++ Sharepoint (DMS) SITEMPPO CS-Synergy TTworkbench TTWorkbench CM-Synergy SWRM Doors SWTest SITEMPPO Rhapsody SWA SWInt MS Build Env. Rhapsody SITEMPPO Visual Studio SW Design Module Test R-Test Realtime MS Compiler QAC QAC++ QAC QAC++ R-Test Realtime R-Test Realtime MS Comp.- Build Env. Visual Studio Coding Check/ Review Project Specific Tools: e.g. Profiler Tool V-Cycle @ I MM

16. SITEMPPO TTworkbench Visual Studio MS Compiler QAC QAC++ R-Test Realtime Tools interconnections • The idea is to have a tool for each step in creating our product (from system requirements, system architecture to design, coding, checking and testing) and these tools should interact to each other. (e.g. to import the requirements from Doors to be used in creating the design in Rhapsody) Doors Change Synergy Telelogic Change Rhapsody A interface that uses K2l Most and links to SUT (VW targets) MS Build Env.

17. Configuration Management – Telelogic Synergy • In software engineering, software configuration management (SCM) is the task of tracking and controlling changes in the software. Configuration management practices include revision control and the establishment of baselines. • Telelogic Synergy is a software tool that provides SCM capabilities for all artifacts related to software development including source code, documents and images as well as the final built software executables and libraries. • Other tools on configuration management: • Subversion, CVS, Microsoft Visual SourceSafe • Why Telelogic Synergy? • task-based configuration management • baselines and advanced release management • distributed database • Who is using it: • developers, build managers • ES role: • creates accounts, roles management • DB creation, maintenance, DCM synchronization

18. Why use Configuration Management? Configuration management is the process of identifying system components, tracking relationships between components and communicating the status and flux in those components.

19. Configuration Management – Telelogic Synergy • Telelogic Synergy is a task-based software configuration management tool • The lifecycle of a task and the corresponding source files are presented below: excluded assigned completed Tasks: working integrate released Sources:

20. Requirement Management – DOORS • Requirements are statements defining behavior and characteristic of a product being developed within a given set of condition. • DOORS is a client-server application (database and user interface) for capturing, structuring, analyzing, tracing and baselining of requirements. • Other tools on requirement management: • SpiraTest, Envision VIP, Compuware Optimal Trace • Why Doors? • the world's leading requirements management solution • it ensures capturing, linking, analyzing and managing changes to requirements and their traceability • Who is using it: • requirement managers, developers, system architects, project managers • ES role: • access (new accounts) • administration • proper usage of the tool

21. Advantage of using DOORS • Traceability from highest level requirements to implementation • Established via links through the database • Impact assessments of proposed changes • Analysis tools let you see which other requirements will be affected by a change • Controlled access to current project information • A shared database ensures that all users are working with current data • Change control • The Change Proposal System implements a controlled process for managing change.

22. Model Driven Development (MDD) – Rhapsody • UML, SysML, DoDAF-based MDD environment for embedded systems • Allows system engineers and software developers to create graphical models of the system which can be simulated and tested while automatically generating C/C++/ Ada or Java code that is directly deployable on the end product.

23. Rhapsody • Other tools on model driven development: • "Borland Together - Visual Modeling for Software Architecture Design" • Why Rhapsody? • specific tool for automotive • with Rhapsody, you have the ability to analyze the intended behavior of the application much earlier in the development cycle by generating code from UML and SysML diagrams and testing the application as you create it. • Who is using it: • developers, architects • ES role: • offers tools installation and configuration • develops new methodology's depending on the project requirements • finds solution to the errors that appear to users

24. Rhapsody's Purpose • Rhapsody enables a visual design environment to create requirements and model embedded software. It enables you to accomplish the following tasks: • Analysis—Define system requirements, identify necessary objects, and define their structure and behavior using the Unified Modeling Language™ (UML™) diagrams. • Design—Trace requirements to the design, taking into account architectural, mechanistic, and detailed design considerations. • Implementation—Automatically generate code from the analysis model, then build and run it from within Rhapsody. • Testing—Simulate the application on the local host or a remote target to perform design-level debugging within simulated views.

25. Change Management – Change Synergy • PR (Problem Report) – it is a problem reported by the customer • CR (Change Request) – it is a request for a new feature or enhancement of the product Why do we need CR/PR Management? • We have to keep track of the problems that appear in different stages of development • If we have a good tracking of problems we know exactly what needs to be tested • A good track of PR/CR provides a good strategy for integration testing stage • Tracking the CR/PR helps us estimate further implementation costs. • CONCLUSION: There is a real need for a specialized tool in PR/CR Management

26. Change Synergy – PR/CR Exchange Management • Other tools for change management: • AllChange, Rational ClearDDTS, PRTracker • Why Change Synergy? • accessible over Internet (web interface) from different locations • a User-friendly intuitive change request interface that allows you to create, disposition and track change requests • multiple lifecycle solutions together on a single change platform • ready-to-use templates, processes and procedures that embody the "best practices" • Who is using it: • developers, build managers • ES role: • creates accounts & roles management • database setup and synchronization

27. Scripting – CR/PR Exchange • Moving through different states, PRs are transferred between different parties (e.g. between the client and the provider or between the provider and the supplier) • In the CR/PR exchange: • We are using scripts written in interpreted languages (perl, bash) • PR/CR exchanges take place at specific time to keep consistency between parties involved • PR/CR can't be modified in the source database after it has been send to another database • The above principles assure consistency between databases during the CR/PR exchange

28. VWImEx – PR import/export tool (with Volkswagen) • VWImEx is an internal tool used in PR exchange with Volkswagen: • it runs on the same server as Change Synergy • it contains bash scripts, batch files and executables • it manages both import and export of PRs • it runs at specific time for consistency

29. MSExT – PR import/export tool (with Microsoft) • MSExT – internal tool for PR exchange with Microsoft written exclusively in Perl totally automated running on Unix with cron it manages both the import and export of PRs it emails the logs to the support team every time it runs

30. What is module testing? • Module testing is concerned with the testing of the smallest piece of software for which a separate specification exists. • The goal of module testing is to isolate each part of the program and show that the individual parts are correct. • The procedure is to write test cases for all functions and methods so that whenever a change causes a fault, it can be quickly identified and fixed. • Precise monitoring of code execution is necessary to reveal errors in • algorithms • loops • state machines • logic decisions • The later a bug is discovered, the more expensive is the fix=> Module testing not only raises quality, it even helps saving costs! • SW Module Test has to be executed if • a new module is in implementation or finished • a module is changed

31. IBM Rational Test RealTime • RTRT is used for obtaining the Code Coverage report (Code coverage is a measure used in software testing which describes the degree to which the source code of a program has been tested. ) • Other tools on module testing: • Cantata ++ • Why RTRT? • offers more functionality • Who is using it: • developers. • Integration with: • Visual Studio 2005 • ES role: • offers support in tool configuration and usage. • clarifies and finds solution to the tool specific errors.

32. Advantages offered by RTRT • Isolated, early and quick test of your SW because of • stable build and flashing process not necessary • Maximum automation degree and regression detection because of • quick test iteration/ execution at PC • repeat all tests by "one button click" • Maximum test coverage because of • easy measuring of coverage, show all reached SW branches • High reusability for new HW/projects • Unique and clear reporting • Efficient development and maximum quality User RTRT

33. Static Code Checking - Tool • QAC is a deep flow static analyzer for C code. QAC analyzes source code on a file-by-file basis. • Library of over 1000 warning messages; warning messages are displayed presented in HTML or Text format • Every developer has to check his new or changed code for non granted deviations before checking it in TS. • QAC behaves as a compiler. • Deviations are sometimes necessary; they are allowed when the architecture and the functionality are not affected and there is no other possibility of reaching the same result. • Other tools on static code checking: • Green Hills Software, HP Code Advisor, LDRA Testbed, Viva64 • Why QAC? • perform deep static analysis for quality assurance and guideline enforcement. • specific for QAC/QAC++ is "guideline enforcement" • the static code check based on MISRA rules as used in the Coding Guidelines Rule Set. • Who is using it: • developers, build managers, architects • ES role: users support for access on Iasi share, integration in Visual Studio, C&C++ Rules explanation

34. SCC – Output In the output after the static code checking the following two files are produced: grantedDeviations.tsv and nonGrantedDeviations.tsv It is very important that we do not have parsing errors!!!

35. Take into consideration: Not “Your” Code: you are working for Continental Automotive GmbH; your work is appreciated, but the result shall be code that is correct and easy to maintain or reuse … by your colleagues! “Comments Are For Cowards Only”: of course you know exactly what you are doing … now; but what will be in 2 years when you (or your colleagues) have to use (and change!) your code again? “I always used 9 spaces for tabs and ‘1TBS’; that’s simply the best!”: indenting and brace style indeed are questions of philosophy; for above reasons, however, the company will decide them, not you! KISS (Keep it simple and stupid) 4 eyes principle (requires that a single operation be performed by two different people)

36. Test Management – why use a tool for this? • enables one consistent set of test cases • enables one common view on test cases and test results • allows to easily deal with large amount of test cases • supports the efficient coordination of test teams which are big and/or distributed over several locations • enables the mapping of test cases against requirements • provides the generation of test suites from a repository of test cases as needed for a specific project situation (priority based if time is short, subsets of test cases according to latest modifications in the SW, …) • avoids double tests • allows the tracking of the test progress at any time • gives proof of the requirement test coverage • provides the generation of reports and statistics

37. Test Management – SiTEMPPO • SiTEMPPO (Siemens Test Execution, Managing, Planning and RePorting Organizer) is a comprehensive test management tool which was designed to provide support for all test verification stages in the software development process (gives an overview of the status of test activities as well as with details on test creation, test execution, progress and requirements coverage.) • Other tools on test management: • Test Director • Why SiTEMPPO? • it is intuitive and easy to use • has many useful features • Who is using it: • testers, project managers, test & requirement managers, analysts • ES role: • creates accounts and gives access to terminal server and license server • offers local tool installation and configuration • supports users with their daily demands for usage of the tool and administration

38. Life Cycle in Test Management • definition of test case structure • definition of test case attributes • definition of report templates • build up of test case structure • definition of test cases(name, test goal) • assignment of requirements • workout of test cases(preconditions, test steps,attribute assignment,attachments) test project definition sheet • test suite creation • manual test execution • automatic test execution • offline test • analysis, reports Test Planning Test Design Test Case Creation Test Execution Test Evaluation

39. Test Automation – TTWorkbench • TTworkbench is a TTCN-3 IDE (Integrated Development Environment) which provides various capabilities based on the Eclipse platform. It supports a broad spectrum of test development, ranging from the specification to the compilation and the execution of tests. • The tool is used for test automation. Test cases are written in this tool, in TTCN-3 language and after that they are executed on SUT (System Under Test). • Other tools on test automation: • Exhaustif/TTCN, OpenTTCN Tester for TTCN-3 • Tau Tester, TTCN-3 toolbox, TTCN-3 Express • Why TTWb? • projects are using the MOST interface and Testing Tech was the only one able to offer real support in this field • Who is using it: • test automation team for writing test cases in TTCN-3 language, compiling and executing them • ES role: • provides solutions on different kind of issues that the users reports • installs and configures the tool • evaluates new releases, reports bugs and problems to Testing Tech

40. Core messages ES in Iasi offers worldwide internal tool support(to developers, testers, architects for our internal tools) ES provides a tool for each stage in SW V-cycle and they interconnect one with another ES maintains the CR/PR workflow during the SW lifecycle ES provides easy interoperability between the developing teams and the other internal units or external partners ES always looks to the new SW tools on the market in order to provide the best solutions in the SW development process