Software Quality Assurance  
Software Development Process

Table of Contents

The software development process describes how software is developed at EMOTIVE.

The software development process is clearly structured yet flexible enough to address the specific requirements of developing software products. With a team of about 20 employees, great emphasis is placed on agility and adaptability. Established methods and principles are applied in a way that meets the needs of smaller teams. Here is an overview of the approach.

Note: EMOTIVE is a software product manufacturer and not a development service provider. Software product development and software project development differ in some ways. Software project development is customer and requirement-oriented, while software product development is market and user-oriented. The two approaches differ in terms of target group, development process, financing and long-term orientation.

  1. Specification
    • The requirements for the software product are collected and categorized
    • Goals and priorities are defined
    • Based on the requirements, a concept is created and the technical architecture is defined
    • Suitable technologies and tools can be suggested
    • Result: Understandable, complete specification
  2. Design
    • Only for complex, new functions, e.g. high-performance profiling
    • Can be omitted if the architecture is already clearly defined by the overall architecture
    • Prototypes can be implemented if required
    • Result: Extended specification and, if necessary, a PoC implementation
  3. Implementation
    • The development process is deliberately designed to be flexible and does not use rigid methods such as SCRUM or KANBAN, as these are often superfluous for small teams (2-3 people)
    • Clear communication and personal responsibility are the focus.
    • Code reviews take place for non-trivial implementations
    • Testing of the implementation (no first-level bugs)
  4. Testing
    • Automated and manual tests ensure quality
    • Test against the specification (black box tests)
    • The software is tested for performance, security and user-friendliness
  5. Deployment
    • Creation of the software
    • Conducting the release tests and generating the protocols
    • Updating the user documentation
    • Provision for all target environments
  6. Support and Maintenance
    • After provision, regular updates and technical support are provided
    • Extensions and new functions are implemented in close coordination with the user
Software Development Process

Why This Approach Chosen?

This approach aims to deliver innovative, reliable, and sustainable software products that align perfectly with the needs of users and stakeholders. By maintaining flexibility and focusing on quality, the team ensures that each product is both functional and impactful.

The following aspects were the focus:

  1. Flexibility
    Tailored workflows accommodate the needs of small teams and evolving project requirements.
  2. Client Focus
    Regular communication and feedback loops ensure alignment with stakeholder expectations.
  3. High Quality
    A meticulous testing and review process guarantees a reliable and robust final product.
  4. Efficiency
    Streamlined processes, clear roles, and open communication foster effective collaboration.

Specification

The software development for the OTX Tool Chain is starting by creating the Software Requirements derived from the inputs like

  • Standards (e.g. ISO 13209),
  • Customer Requirements or
  • Internal requirements

The Specification is realized in Issue Tracking System (REDMINE) within a ticket of the WIKI. In some cases the requirements are specified in Confluence or other formats (e.g. Word or PDF) whereby here a linked reference to Issue Tracking System (REDMINE) is mandatory.

Before a Requirement is ready to implement it has to pass a review from the PM. The PM is approving the requirement for implementation if the review is successful.

The ticket workflow, see Ticket States is the reference for the workflow to create a specification.

  1. The PL creates a new ticket with state New in the public Issue Tracking System (REDMINE) area (Customer visible) and mirrored in the internal area (emotive only)

    Note: If the content of the subject in the ticket is too big then sub-tickets will be created and linked to the main ticket. This is only done in the internal area.

  2. The PL describes the scope of the update or change in the ticket
  3. All needed activities & inputs will be listed in the ticket
  4. A 4 eyes review via PM is executed if all inputs and sub-tickets are created accordingly
    1. The priority for the ticket must be set, see Ticket Priorities. For time-critical tickets, an expected completion date can optionally be specified.
    2. The Ticket must be assigned to a target branch, see Versioning and Branching
    3. For important or critical tickets a code review must be carried out. In that case the attribute To Review must be set.
  5. The PL assigns the ticket to the DEV-TL or if the developer is clear direct to the DEV for implementation. The DEV-TL can assign the ticket to a DEV.

Design

The design phase is like an extended specification phase, see Specification. It is only executed if it is required. If the implementation is clearly defined and has no impact on the existing design this phase can be skipped. If the implementation is complex the design phase is mandatory (e.g. API-Design). The decision is taken at the specification review by the PL or PM.

Implementation

After review and approval of the specification the ticket is inside the ticket store and ready for implementation by a developer DEV. When the DEV has finished with the last ticket, he selects a ticket from the ticket store assigned to him according to priority.

For tickets with the same priority, the DEV can select the next ticket at his own opinion but according to the following criteria:

  1. Tickets with expected short processing times are preferred
  2. Tickets that require the least amount of training compared to the previous ticket are preferred
  3. If there are any uncertainties, the PL should be ask

When the DEV accepts a ticket, the following procedure must be followed:

  1. First, the DEV sets the ticket status to In Progress, see Ticket States.
  2. The DEV reads the ticket carefully to understand the content.
    1. If questions arise, the question can be written in the ticket and the ticket is assigned back to the creator with the status Feedback.
    2. The creator of the ticket answers the question, sets the status back to In Progress and assigns it back to the DEV.

      Note: This process can be carried out until there is clarity about the content and implementation.


  3. After the DEV has understood the ticket, he estimates the processing time and updates the completion date in the ticket.
  4. Now the implementation is carried out
    1. The developer is obliged to document his code in a reasonable manner
    2. If there are changes to an API, DEV is obliged write the code for the generated user documentation for each API
    3. It can be necessary that the DEV must stop the work at the ticket. Because some requirements are missing or an urgent ticket must be implemented. In this case the DEV must set the state to Pending and write the reason into the ticket.
    4. At the end of each working day, the progress and the completion date of the ticket must be updated by the DEV
    5. The DEV is obliged to commit his code in a meaningful and timely manner. Meaningful stands in this context for committing logical and functional connected blocks together for a better understanding and assignment into the Software System later on. Timely stands in this context for at least one commit at the end of the working day. If it cannot be committed, then it must be backed up to an internal network drive using a patch!

      Important: It must be noted that the updated code is still compilable.


  5. If the attribute To Review is set to TRUE, a code review using the 4-eye principle must be carried out
    1. The result of the code review must be documented in the ticket
    2. The PL decides whether the code review needs to be repeated after an gap or error found by the TE.
  6. If the implementation is finished from the perspective of DEV, then the implementation must be tested by DEV according to the following criteria:
    1. To improve the code quality for all runtime relevant changes to the OTX Runtime API or DiagManager, Code Sanitizers must be executed and their results must be applied (zero findings), e.g. Clang.
    2. For changes to the OTX Runtime API or DiagManager, a static code analysis should be performed and its results assessed, e.g. using SonarQube.
    3. If there are changes to an API, the DEV must either rewrite or update the API unit tests
    4. For other changes, DEV only needs to test for errors at the 1st level
  7. After this tests has been successfully completed, the ticket status must be set to Resolved.
    1. The progress must be set to 100%
    2. The due date must be set to the current date

Testing

After the ticket is set to Resolved be the DEV, the ticket is inside the To be tested store and ready for testing by a tester TE. When the TE has finished with the last ticket, he selects a ticket from the "To be tested" store according to the priority criteria described above for the DEV.

  1. To finally test the ticket, a tester (TE) takes the ticket, sets the status to In Testing
  2. The TE tests against the specification. He independently selects a suitable test procedure for this.
  3. If the change is relevant to release, then the release tests, see Testing, must be adapted by the TE or commissioned to DEV. Changes relevant to release are:
    1. All changes to the APIs
    2. All changes or extensions to the OTX standard

      Note: New tickets may have to be created for this. This also applies if other errors are found during testing that have nothing directly to do with the ticket.

  4. If the TE finds a defect, he documents it in a traceable manner in the ticket, sets the ticket to the status In Progress and assigns it to the DEV again.
  5. The DEV processes the ticket, see point 4 above

    Note: This process is repeated until the TE finds no more errors.


  6. If the attribute Adapt UserDoc is set, the TE is responsible to update the user documentation.
    1. The TE can do it by its own or create a new ticket with the tracker "Documentation", link it with the to be tested ticket and assign it to an other team member.
  7. If the TE tested the ticket and finds no errors, the state must be set to Tested

    Note: Only tickets with the status Tested should be published.

Deployment

The following categories are distinguished for the delivery of the software:

  1. Main version
    A main version contains new, essential features. According to an agreed release plan, approximately one to two main versions are delivered per year. Extended Release Test are carried out for a main version.
  2. Hot-Fix
    A hot-fix does not contain any new features, only bug fixes for the main version. A hot-fix is ​​always delivered on the hot-fix branch, see Versioning and Branching. Release Test are carried out for a hot-fix.
  3. PoC
    A PoC (proof of concept) is created normally, but no Release Test are carried out. A PoC is only used to test a change at the customer's site.

Important: A PoC may not be used productively.

The following steps are performed for delivery:

  1. Building the software via a Jenkins build server.
    1. Creation occurs automatically once a night
    2. Creation is triggered manually if necessary, for example during delivery.
    3. Creation occurs for all target systems (Win32, Win64, Linux32, Linux64)
    4. User documentation is also created
      1. All API unit tests are carried out via GoogleTest
    5. All installers and ZIP files are created
  2. Execution of Release Test
    1. The test protocols are created
    2. If tests are not passed, the PM or PL decides whether a release is granted anyway or whether the error must be eliminated first.

      Note: Tests for known problems can be hidden.

  3. Check if the Free and Open Source Software (FOSS) declaration is up-to-date
    1. The user documentation may need to be adapted
  4. Check if the software is virus free and create the virus report
    1. False-Negative Findings should be listed inside the delivery ticket in Issue Tracking System (REDMINE)
    2. The virus check is performed by VIRUSTOTAL

      IMPORTANT: A detected virus does not mean that the file contains a virus! It only means that the related virus scanner means that there is a virus. Note, that each file is scanned with more than 50 different scanners.

  5. Providing the software to the user
    1. The software is uploaded to the license portal
    2. The software, the user documentation and all created protocols are uploaded to Issue Tracking System (REDMINE)
  6. Optionally, users can be informed via a circular email

Support and Maintenance

After the software has been released and delivered, questions may arise or errors or defects may become apparent. The software is maintained and further developed for this purpose. The following process has been established for maintenance:

If a question or problem arises, a ticket is created, see Issue Tracking System (REDMINE).

  1. Depending on the type of problem, e.g. error or support request, the corresponding ticket type is selected.
    1. A feature request can also be made using the feature ticket type.
    2. One ticket should be created for each problem. Do not combine several independent problems in one ticket. If there are any ambiguities, the ticket can be split later.
    3. The ticket can also be created directly by the user.
  2. The ticket should contain the following information:
    1. Brief description of the problem
    2. Detailed, comprehensible description to be able to reproduce the problem (use OTX terminology!)
    3. Specify the name and version number of the software used
    4. If possible, attach log or trace files that contain the problem to the ticket, see Logging and Tracing
    5. Write example code, for example in OTL or DotNet, in the ticket

      Note: Foreign program code, foreign terms, file formats or log files cannot be processed without FAQ_ExtendedIntegrationSupport.

  3. After creation, the ticket is handled as described under Implementation.