Traditional software development flow
When using a traditional software development process (waterfall or other common methodology), ALM Octane can help you plan and manage your development process.
The traditional development process typically follows a structure like this:
We recognize that not all traditional (non-Agile) software development models follow such a linear progression, but they all keep the generally rigid separation between development phases.
In traditional software development, you follow a number of steps:
Requirements phase: The requirements for the product or release are clearly deliniated. This may or may not include specific features within a product, but just a list of what the product needs to do.
Design phase: The requirements are turned into a functional product design. In addition, you define how these features are to be built inside the product.
Implementation: Using the planned design, the product is developed.
Testing/verification: The planned features are sent, in their entirety, to the quality assurance team for testing. Defects are opened for those problems encountered in testing.
Release/maintenance: The finished and approved features or product is released, and maintained for its entire lifecycle.
ALM Octane helps you manage your development processes through each of these development stages:
Select an image to learn more.
In traditional, software development, you define the requirements before beginning any work. This enables you to know exactly what your product needs to do for customers.
Furthermore, you need to know your exact timeline and manpower before beginning work on the requirements so you get an estimate if the plan is reasonable.
ALM Octane enables you to do this planning before beginning work on the release.
As part of the process of enumerating requirements for your application is defining how your application will be built. In ALM Octane you define application modules for each section of your application:
These application modules are created and viewed in the Quality module:
In the Quality Module you create the hierarchy of the application modules, and then associate features, tests, and defects with each application module.
Grouping the application enables you to see overall application health and progress as you proceed through development and testing. After the backlog items are designed in the Design stage, you can associate these items with each application module to help give a comprehensive view.
For details on application modules, see Product quality.
In addition to planning what you will build, you also have to set up the timelines for when you will release the developed product.
In ALM Octane your workspace administrator sets up the releases, sprints, and timelines in the workspace settings:
In each release it is possible to add sprints and other milestones to the release timeline:
For details on defining releases and release timelines, see Set up a release.
In addition to creating the release timelines, you must also plan the workforce. In ALM Octane a workspace administrator does this by creating teams and then assigning them to the necessary releases:
After the teams are assigned, they will be available in the Backlog when assigning items.
For details on creating and assigning teams, see Manage teams.
Once you have planned what the application should contain, when you should release product versions, and who is working on these releases, you can begin designing the application's development. This involves creating a backlog of work items and assigning these work items for development.
When designing how the application will be developed, you create a product backlog to organize the development process. This involves defining the large scale areas of your application, the features you want your application to contain, and specific things that need to be done to develop these product areas.
In ALM Octane, the backlog is maintained in the Backlog module. Use the Backlog module to:
Create Epics that specify the large-scale part of your applications
Create Features for each deliverable part of the product
Create Stories for each item that must be developed
Organize Epics, Features, and Stories in a meaningful way that displays your product development logic and hierarchy
Once you have created the product backlog structure, you can decide what and when to develop and release different items.
For details on using the Backlog, see Backlog management and release quality
After you create the full Backlog, you have to plan each release or sprint.
In ALM Octane there are multiple ways of assigning backlog items:
Directly from the Details tab of any item
By dragging the item from the list/grid view into a release bucket displayed in the Planning tab at the right side of the Backlog module window
Once you have defined the requirements for your application and designed what, when, and who will implement these requirements, you are ready to work on developing the application.
While working, move the phase within the backlog item itself:
Keeping the backlog item phase up-to-date ensures that you get an accurate reflection of the release's overall progress toward its completion.
For details on workflow phases, see Advance the phase of an item
While working, it is often helpful to break down the item into manageable tasks. This enables you to break down the sometimes very large requirements list into achievable parts.
To do that, ALM Octane provides a task list/task board to manage tasks:
From the Tasks tab in the Backlog module (when a story or defect is selected in the Backlog tree) or from inside a story or defect details
From the Tasks tab of the Team Backlog module
For details on managing individual backlogs, including using the Task Board, see Work on your stories.
During the development period you should track individual progress to see how development is progressing toward completion:
In the Backlog list or grid, you can see the story progress when you select an epic or feature in the Backlog tree or open the epic/feature details
In the Team Backlog module, there are graphs for overall team progress and individual team member progress for period selected in the filters.
The Dashboard module also enables you to create custom graphs to reflect progress as needed.
In addition to viewing that each individual part of the development team is progressing as planned for the given sprint or release, you can also check overall progress, for all teams or team members.
You can add widgets to the Dashboard, such a Stories Cumulative Flow graph, Burn Up and Burn Down widgets, and so on.
After you have developed the features in your application, you pass them off to a quality assurance team for verification and testing.
ALM Octane has a number of ways to help you with testing:
For each backlog item (including epics and features), you can add tests. This enables you to easily store the relevant tests for any item instead of having to locate them each time you verify a feature.
Note: An epic or feature's tests include all tests for the features and stories included in the epic or feature.
You can run tests in a number of ways:
Manually launch a test run from an individual test or test suite
Schedule (plan) a test run of a test or test suite
Attach the tests to your continuous integration server and run the tests as part of a regular build process
After running tests, view the test results to see successes and explore reasons for failure.
You can automatically view test results from both manual and Gherkin tests run in ALM Octane, and you can also automatically upload test results from other testing tools to ALM Octane. Once the tests run and the test results are available, you view the results directly inside the ALM Octane test item.
While running tests or analyzing tests results, if you find issues or errors in your application, open defects on these issues. This enables you to use the errors and issues found with testing to improve the quality of the existing features and development. Furthermore, these defects can be added as backlog items, which helps your development team more adequately balance new development efforts and improving product quality.
You can open defects in a number of different places:
In the Backlog module in the same way as an Epic, Feature, or User Story
From the Defects module
From the test details, as part of the test run
As you develop, in an effort to deliver higher quality features, monitor the application's quality. You can view this information both in terms of test results and defects still open.
ALM Octane provides a number of widgets with this information. You can view these widgets in:
The Overview tab of the Backlog module
The Overview tab of the Quality module
In addition to viewing global application quality, you should view the overall quality for the release on which you are currently working. Many of the widgets available from the Overview tabs of the Backlog and Quality modules also have per-release settings or are specific to a certain release.
For details on configuring dashboard widgets, see Use the ALM Octane Dashboard.
After you have completed the specified requirements according to the design, and had the developed application verified and tested, you release your application to customers.
After the release, it is common to continue maintenance of released versions (in addition to developing new features in other releases). To assist with maintenance, ALM Octane enables you to:
Run tests against any version of your application you want
Create a pipeline for previous versions which enable you to build and test additional fixes made for that version. For details on pipelines, see Pipelines: Integrate with your CI server
Create dashboard widgets for past releases of the product to see quality of that release.