Systems Engineering Center (SEC)

Transcription

1 Systems Engineering Center (SEC) Overview - 1 -

2 OMNITRACKER Systems Engineering Center at a Glance 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 - 2 -

3 Technical features 1/2 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 - 3 -

4 Technical features 2/2 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 - 4 -

5 OMNITRACKER Systems Engineering Center (SEC) Introduction Application to manage software and system development processes

6 SEC in the SW Development Process 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 - 6 -

7 Roles and Responsibilities 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 Roles and Responsibilities 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

9 Ticket Types 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 Process: Request Management At the communication center all incoming requests are recorded, classified and processed (SPOC Single Point of Contact)

11 Establishment of a SPOC, why? 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 Process: Defect Tracking Recording and tracking of defects during a life cycle of software respectively system development project

13 Objectives of Defect Tracking 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 Process: Change Management Logging and tracking of change request (CR) to adapt existing system functions

15 Objectives of Change Management 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 Process: Release Management Administration of product releases concerning whole product lifecycle, from planning to discontinuation

17 Objectives of Release Management 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 Process: Test Management Support and improvement of quality assurance in product development

19 Objectives of Test Management 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 Build Based Test Execution / Test Automation Administration of release builds, testrun based test execution and test setups

21 Objectives of Build Based Test Execution and Test Automation 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

22 Process: Configuration Management Providing detailed configuration information for the product development within a centralized database, the CMDB

23 Objectives of Configuration Management 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 Configuration Management: Relations 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

25 Comprehensive Traceability in OMNITRACKER SEC 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 Reports and Exports OMNITRACKER Systems Engineering Center includes predefined 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

27 Tracking of the Development Process Using Reports and Exports 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"

28 Integration with External Tools 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

29 OMNITRACKER SEC Interfacing with External Version Control Systems

30 Extensibilities 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

31 Thanks for your attention! Questions?

32 Software Solutions GmbH D Eckental Austria GmbH A-1010 Wien Technologies NV/SA B-3018 Leuven Nederland NL-2517 Den Haag OOO (Russia and CIS) RUS-Moscow GmbH (Schweiz) CH-8808 Pfäffikon USA US-New York, NY