Skip to end of metadata
Go to start of metadata

The development process is divided into 8 steps. It is a life cycle that covers the major releases.

The formal requirements are gathered from the user community, but also from the OpenDNSSEC Architechture Board (OAB). These needs to be written down, sanitized, and prioritized. Not all of the requirements can be fulfilled in one release.


A set of functional specifications can be derived from the requirements. It does not describe the inner workings of the system, but are focusing more on the interaction between the system and outside world.


The architecture is the overall design of the system. It is based on the requirements and the specification. The development team prepare a draft that is submitted to the OAB. The OAB will then help with the process of creating the architecture. This is to keep the development inline with general strategy and requirements.


A more detailed design can be created once the architecture has been set. This is done within the development team. The aim is to describe each component and its internal structures.


There are four different parts of the implementation phase.

  • Backlog
    The backlog contains all features that need to be implemented and bugs that need to be fixed. The work items are created based on the design of the system. Each item has an estimated workload. The sum of the workload is then output as estimation for the release plan.
  • Release backlog
    Not all features can be implemented in one release, but must be split up into smaller minor releases. The OAB can help with this decision. The release backlog is a subset of the backlog and contains only the features needed for this release.
  • Iterations
    A normal iteration within an agile development process contains all parts of a software development cycle. But the iteration in our case is only the period between each telephone conference meeting where we have the chance to plan the release, give updates on our progress, and discuss current issues. We try to have a meeting every second week.
  • Release
    The developer team can initiate the release process when they e.g. want to get feedback or have implemented all features. The software then goes on to the next step, QA.


The changes in this release are tested against the requirements and the specification.

  • The developer does sufficient developer testing to ensure that the functionality is complete and the major use cases pass
  • Ideally a second developer or tester then does manual testing of the features to include success and failure cases and corner cases. Any issues found are recorded on the JIRA issue for the development for the original developer to fix before re-testing. For major developments a separate testing issue may be created. 
  • Regression tests should then also be put in place to cover the functionality in jenkins.


The software is released to user community according to the Release Management process.


See the  Release Management process for details of release maintenance.

  • No labels