Systems Engineering Center (SEC)

(1)

Systems Engineering Center

(SEC)

(2)

©_OMNINET 2

-Efficient tool for the entire software and systems development lifecycle:  Application to manage processes in software and systems engineering

organisations

 Workflow and role based process control  _{Assurance of}

 Data consistency and data availability  Detailed Reporting: logging of all events

 Development efficiency: integral view of results and artefacts of

development

 Cross-process queries, filters, reports

 CMMI support

 Iterative extension of existing OMNITRACKER solutions e.g. OMNITRACKER

Project Management Center

 _{Improved Release Management}

OMNITRACKER Systems Engineering Center at a

Glance

(3)

Processing and Development

 Fast creation of tickets (defects, change requests or new requirements)  Assign tickets to releases

 Planning and tracking of releases of products throughout their life-cycle  Administration of builds

 Optional: Interface to version control systems (VCS)

 Administration and versioning of test specifications and test cases  Structured test execution

 _{Optional: Interface to test automation systems}

 Reuse of application knowledge (knowledge base)  Consistent reporting

Web Client

 For creation and processing of tickets also the web client can be used.  No client installation for the end user necessary

(4)

©_OMNINET 4

-Interface and Display

 Quick navigation between processes  Rule based display of objects

 Integrated view of results and artefacts  Management reports

Cost Reduction

 Saving of license costs (license reuse)

 Decrease in maintenance and administration costs

 _{Elimination of connectors between individual process tools}  Reduction in infrastructure resources

Miscellaneous

 Integration of further OMNITRACKER business process applications  Quick configuration adaptations possible to cope with new process

requirements

Technical features 2/2

(5)

OMNITRACKER Systems Engineering Center (SEC)

Introduction

(6)

©_OMNINET 6

- _{Combining the OMNITRACKER applications}Systems Engineering Center, Requirements Management Center and Project Management Center

accomplishes a "One Tool Solution" for software development process

management. Setting up interfaces towards existing version control and build systems as well as towards automated test systems effectively supports

process control and progress tracking.

 For achieving level 2 of CMM maturity, an organization must have introduced at

least the following processes:

 RM&E process  _{Project Planning}

 Project Monitoring and Control

SEC in the SW Development Process

(7)

 Steering Committee Development

Constituted of executive managers, who decide about product resp. system development strategies based upon customer, market and business

requirements.

SEC: Responsible for review and approval of the roadmaps.

 Product Management

A team coordinating the product planning, the development and marketing support activities.

SEC: Responsible for creation and maintenance of product roadmaps and on the other hand, for coordination of those with the development project manager.

 Change-Control-Board

Group of project stakeholders, who decide about implementation of change requests at a development project.

SEC: Responsible for approval and planning of changes and new feature requests.

(8)

©_OMNINET 8

- Development Coordinators

Small group evaluating and classifying incoming development requests, i.e. assigning defect, change request or feature requests.

SEC: Responsible for the Communication Center (SPOC).

 Technical Staff and Technical Managers

System architects, system and SW developers, test engineers, service and support engineers

SEC: Responsible for processing the tickets, the test, configuration and release management.

Roles and Responsibilities

(9)

Request (RQ)

A generic request (notifications, questions, alerts, change or feature requests), also summary requests.

New Requirement (SREQ)

A new resp. significantly enhanced system functionality, which require an analysis, a technical review and the approval by stakeholders.

Change Request (CR)

A CR aims to change an existing

system function. The implementation of a CR normally require the approval and planning by a CCB.

Defect (DF)

Usually a development internal bug report resp. a defect occurred after

releasing the system. Defects for which correction is complex, risky or need

significant effort for implementation, can be linked to and treated as a CR.

(10)

©_OMNINET 10

-Process: Request Management

At the communication center all incoming requests are recorded, classified and processed (SPOC – Single Point of Contact).

(11)

 _{Allows to submit requests towards development easily and quickly}  Timely evaluation of the requests by DCG

 Correct classification and derivation of tickets for product development: as

defect (DF), change request (CR) or as new requirement (SREQ)

 _{Fast decisions regarding urgent bug fixes, implementation of less complex and}

uncritical CRs, which do not require the approval of the CCB

 Quick assignment of tickets to releases and builds

 Timely feedback to submitter of a request and follow-up tracking information

based on the derived ticket(s): DFs, CRs, and / or SREQs

(12)

©_OMNINET 12

-Process: Defect Tracking

Recording and tracking of defects during a life cycle of software respectively system development project

(13)

 _{Quick and easy recording of defects and their dependencies}  Tracking of defects

 Allocation of defects and releases („Posted for" and „Assigned to" means

resolved with release)

 _{Maintenance of a knowledge base to assure quick search of solutions and}

workarounds

 Bug fixing at minimum time

 New defects will be typically recorded by testers  _{Shortened workflow to fix release internal „bugs"}

(14)

©_OMNINET 14

-Process: Change Management

Logging and tracking of change request (CR) to adapt existing system functions.

(15)

 _{Quick and easy logging of change requests (CRs) and their dependencies}  Tracking of all CRs

 Assigning CRs to releases („Posted for" and „Assigned to" means resolved with

release)

 _{Structured processing of CRs: Planning, evaluation and prioritisation; followed}

by an approval stage, the implementation and test

 Implementation of CRs demands typically an approval by CCB (Change Control

Board)

(16)

©_OMNINET 16

-Process: Release Management

Administration of product releases concerning whole product lifecycle, from planning to discontinuation

(17)

 _{Planning, development and provisioning of product releases}  Global support of release life-cycle

 Tracking of product releases history

 Definition of release scope (major, minor, maintenance)  assigned requirements (SREQs)

 assigned change requests (CRs)  assigned bug fixes (DFs)

 Automatic generation of release notes

 _{Connection to version control and build systems to administrate the software}

sources

(18)

©_OMNINET 18

-Process: Test Management

Support and improvement of quality assurance in product development

(19)

 _{Administration and maintenance of test specifications based on products and}

product releases

 Structured approach for the execution of tests  Reproducibility of tests

 _{Definition of test cases including test setups and iterative approach}  Test cases for manual or automated execution

 Test executions are assigned to builds (releases)

 Administration of testruns for testing a build several times, using e.g. different

test environments.

 Logging of test results

(20)

©_OMNINET 20

-Administration of release builds, testrun based test execution and test setups

Build Based Test Execution / Test Automation

(21)

 _{Structured test execution: tests of builds based on testruns}  Usage of different test setups in terms of quality assurance  Reproducibility of test executions

 Administration of test setup configurations CMDB

 Test automation (OT SEC as leading system), i.e. the test control information is

stored in the testrun object and will be transferred to the test automation system

 After the test execution the results are transmitted back to and logged in SEC

test execution objects

 _{Every executed test case is linked to result object}

Objectives of Build Based Test Execution and Test

Automation

(22)

©_OMNINET 22

-Process: Configuration Management

Providing detailed configuration information for the product – development within a centralized database, the CMDB

(23)

 _{Administration of a product catalogue, registration of the developed artefacts}

belonging to the products delivered to customers as well as the developed artefacts and tools used internally

 Registration of the configuration of the products  Visualisation of the component structure

 Tracking of relations (e.g. CI and its assigned tickets: DFs, CRs, xREQs)

 Registration of all configurations of development internally used tools (e.g. test

automation systems, loadtest systems)

(24)

©_OMNINET 24

-The CMDB as the centralised database to administrate the artefacts and components of a product release

 Illustration of dependencies between the artefacts (CIs),

being imported for releasing the products

 At the beginning of system development, the hierarchical

structure and the dependencies between the components are documented (e.g. System > Unit > Component >

Module)

 Multiple hierarchy levels are available to model the system

configuration

 Product catalogue to record and structure the products of

the organization

Configuration Management: Relations

(25)

 _{Horizontal traceability in OMNITRACKER Systems Engineering Center}

 Documents dependencies between defects and change request (i.e. which

CR was needed to solve which defect)

 Documents which SW source code changes have been done to resolve

defects or to implement change requests

 Vertical traceability in OMNITRACKER Systems Engineering Center  Documents which features have been delivered in which release.  Starting from the release it is traceable:

 _{Which requirements have been implemented}  Which change requests have been implemented  Which defects have been fixed

 This information is available down to build level.

(26)

©_OMNINET 26

- _{OMNITRACKER Systems Engineering Center includes}

pre-defined reports:

 Generate and print test specifications

 Generate and print management reports

 _{Statistics of existing tickets „Open Ticket Statistic Report"}

 Statistics of implementation and test progress „Release

Status Report"

 Statistics of test automation

 _{Generate and print release notes}

 Existing reports may be easily and flexibly adapted and

customized

 Ticket lists may be exported for external data processing,

e.g. a list containing all CRs, defects and xREQs that are assigned to the release.

 View of effort on release level, if the release is a package

release the effort of the contained releases is accumulated to the package release

Reports and Exports

(27)

 _{Release status reports:}

 Release Development Status

Report

 Open Tickets Statistic Report

 _{Data exports for external}

reporting (csv, xlsx etc.)

 Access in folder „SEC – CMDB" >

"Product Library"

Tracking of the Development Process Using

Reports and Exports

(28)

©_OMNINET 28

- _{OMNITRACKER Systems Engineering Center can be integrated with external}

software development tools

 Version Control System (VCS)  Automatic Build System

 _{Automated Testing Tools}

 Working with OMNITRACKER Systems Engineering Center in integrated

development environments

 Data exchange between different systems  _{Interactions between different systems}

 Impacting OMNITRACKER workflows and objects

Integration with External Tools

(29)

OMNITRACKER SEC Interfacing with External

Version Control Systems

(30)

©_OMNINET 30

- _{OMNITRACKER Systems}

Engineering Center can be integrated easily in existing OMNITRACKER installations

 _{With the integration of}

OMNITRACKER Project

Management Center (PMC) a „One-Tool Solution" for software or system development organisations is

available.

Extensibilities

(31)

Questions?

(32)

©_OMNINET 32 -OMNINET GmbH D-90542 Eckental [email protected] – http://www.omninet.de OMNINET Austria GmbH A-1010 Wien [email protected] – http://www.omninet.at

OMNINET Technologies NV/SA

B-3018 Leuven

[email protected] – http://www.omninet.be

OMNINET Nederland

NL-2517 Den Haag

[email protected] – http://www.omninet.nl

OMNINET OOO (Russia and CIS)

RUS-Moscow 121099 [email protected] – http://www.omninet.ru OMNINET GmbH (Schweiz) CH-8808 Pfäffikon [email protected] – http://www.omninet.ch OMNINET USA US-New York, NY 10011 [email protected] – http://www.omninet.biz SEC 3.5.0