Building Navigator with Navigator: How We Use Our Own Software to Develop it
Turns out, Alloy Navigator is incredibly flexible and can be applied in business processes beyond IT service management.
Alloy Navigator, our core software suite, is designed for IT service management tasks. But why not use it for software development? That’s what we thought several years ago, during one of the attempts to organise our software development process. As we’ve learnt, Navigator’s feature set adapts well to this use case. Find out more in this article.
The main principles of our development process
Before we proceed, here’s what you should know about our development process:
- Alloy Navigator is developed in-house by a geographically distributed team.
- We issue two major releases per year. These large updates are primarily focused on delivering new functionality to users, such as data grids or AI features.
- In addition, there are maintenance releases which are issued to fix bugs. Their main purpose is to address critical, high-impact issues.
- The management team formulates requirements for the next release according to the current business objectives. The role of the project manager is to ensure operational performance, while the lead developer communicates requirements to developers and double checks that the features are working well.
The core processes
Alloy Navigator is an ITIL-compliant software product. Here are the ITIL processes that we apply in our software development support system:
Change Management
We use Change Requests as requests for new functionality / features in Navigator. Change Requests (CRs) help project managers and the lead developer plan features, estimate the workload, and create reports to update company management on the progress.
When a major release is going live, Change Requests for the next release are first discussed. CRs are accompanied by a “Requirements” document.
Incident Management
We use Incidents as bug reports. These include both bugs uncovered in QA testing and those reported by users.
Work Order Management
We use Work Orders (WO) for task management for developers. Through WOs, developers get tasks assigned from the lead developer, report on their progress, and finally mark tasks completed. It’s a primitive but powerful toolset.
Nested objects
There’s something else that we use very actively: nested (child) objects. This is a feature the lead developer uses when assigning tasks. When a Change Request (CR) has been discussed and planned, the lead developer creates one or several nested work orders (WO), assigning each to a certain developer. When all nested WOs are completed, the system automatically changes the status of this CR.
Change Request workflow
Here’s the workflow that helps us plan and implement new features in Alloy Navigator:
| What is happening | What status the CR is getting |
| The project manager and the company management have discussed a new feature, preliminary deadlines, and the product version it will be released in. The project manager creates a new Change Request. | New |
| Together with the lead developer, the project manager has estimated the workload, and what resources will be employed. The lead developer takes over the CR. | Planned |
| The lead developer creates one or several nested WOs in this CR and assigns them to developers. These WOs detail the assignments for the developers in terms that developers can understand and use for work. | In Development |
| The developers have completed work on their WOs. When all nested WOs are completed, the lead developer gets a notification. | Implemented |
| The lead developer confirms that everything is done as planned and marks the features as ready for testing. | Ready for Testing |
| The QA lead takes over the CR. They create one or several nested WOs for testing and assigns it to the members of the team. Each WO details to the tester what has to be done. | In Testing |
| The tests went well! The system notifies all the affected people. | Completed |
Stay connected
Follow us on LinkedIn for the latest product insights, feature previews, and more exclusive updates.
The set of statuses for Change Requests and Incidents and the actions that trigger status change are the foundation of our software development support system. Want to understand the progress on a Change Request? Check out its status in Alloy Navigator.
Incident workflow
As mentioned, we rely on Incidents to manage the process of bugfixing for issues reported by users or discovered during testing.
An incident is a bug — some already existing functionality that isn’t working.
Most bugs come from testers. Whatever was done in a CR (change request) gets tested. Testers can reject the entire CR if the development completely messed up. If it’s not a total failure but a feature doesn’t work, testers log it as an incident.
The second source is users. When something doesn’t work for them, they complain to support, and support creates an incident. These incidents are prioritized. Bugs found during testing might never be noticed by users, since a user may not even think to use a feature in such a scenario. But a bug reported through support means users definitely encountered it.
| Process phase | Status | Description | Next status |
| Planning | New | This is the initial status, assigned to a newly created Incident. While the Incident is in New, the team lead assesses it.
When it becomes clear that the Incident should go into development, it is moved to status Planned. |
Planned |
| Planning |
Planned | The Incident is now handled by the team lead. They send the Incident into development, one or more development WOs (work orders) are created and assigned to developers. The Incident then gets the status In Development. | In Development |
| Development | In Development | The Incident has active subordinate WOs in development. When those WOs are completed, the Incident receives the status Implemented. | Implemented |
| Development | Implemented | All subordinate WOs for the Incident’s development are completed. This doesn’t necessarily mean all functionality is ready—further development may be needed by creating new WOs.
Implemented is a signaling status: it tells the team lead to review the Incident and confirm that everything needed is fully and correctly done.
|
Ready to Testing
In Development |
| Testing | Ready to Testing | The Incident is now managed by the QA Lead, who waits for the proper build with the required tag. Once the build is ready, the QA Lead sends the Incident into testing: a testing WO is created and assigned to a tester.
The Incident status becomes In Testing. |
In Testing |
| Testing | In Testing | The Incident has active subordinate WOs for testing. The next step depends on testing results:
|
Test Failed
Completed |
| Development | Test Failed | The Incident is again handled by the team lead. They send it back into development, create one or more development WOs, and assign them to developers. The Incident then returns to In Development. | In Development |
| Admin | Completed | Work on the Incident is finished. It remains active and visible in grids and reports until the project ends. At project completion, the Incident gets the status Closed. | Closed |
| Admin | Closed | This is the terminal status of the process. |
When introducing a new process for our internal usage, we always use this simple Workflow mapping template. It contains the following columns:
- Workflow phase: the title of the phase,
- Status: the corresponding status in our internal task management tool,
- Description: this column describes what is done during this stage, by whom, and what are the prerequisites for moving to the next stage,
- Next status: the status of the next workflow phase.
This approach works very well for documenting previously undigitized processes.
Read more about workflow management and automation in our Resources article.
Using Alloy Navigator ourselves: Insights
Using our own product for development helps us spot problems and see prominent usage scenarios firsthand. But that’s not the only thing that motivates this choice. That we’ve adapted Navigator for software development shows that it’s increadibly flexible in terms of the use cases, industries, and business processes it can be applied for.
Alloy Navigator is an IT service management (ITSM) and asset management platform designed to streamline IT operations for organizations of all sizes. It provides a centralized solution for tracking, managing, and optimizing the entire IT lifecycle, from incident and problem resolution to change management and asset control.
Key advantages of Navigator include:
- flexible process automation,
- integration with third-party systems,
- powerful reporting and analytics,
- and a user-friendly interface.
These strengths help organizations reduce downtime, improve IT service efficiency, maintain compliance, and make data-driven decisions to support business goals.
Want us to formalize your business process using Alloy Navigator? Connect with our sales team to try the product!
