Serena Development Manager Usage Overview

The components included with Serena Development Manager work together as defined in the following diagram. This describes a standard configuration, as well as the order in which users interact with it. This only focuses on the end user scenario; configuration is addressed in the Serena Development Manager Installation and Configuration Guide.usage_arch.png

Lets step through this diagram.




At the beginning of a project, a project manager uses the ALM Projects process app in Development Control (running on Serena Business Manager) to create a new project. This is typically in response to incoming demand, such as requirements from a business analyst for a new feature, or a customer request or defect.


At any point during a project’s lifecycle, leads, managers, executives, and others may consult Serena ALM Dashboard to review project status and key performance indicators (KPIs). The reports displayed here may help decision makers choose the correct path forward when work must be prioritized or re-evaluated.


The Development Manager creates change requests using the Dev Change Requests process app - or from the project in ALM Projects. The change requests describe the features and other work to be implemented. The change requests are related back to the project, ensuring complete traceability of work. The Development Manager and others also create tasks using the Dev Tasks process app. Tasks can be used to split the work into more manageable units, that can be assigned to individual developers. When you create a development task, the task is synchronized to Dimensions CM, and a new request of type Task is created.


Developers update the source code using their source control environment. Serena Development Manager includes Serena Dimensions CM. Tasks in Development Control are synchronized to Dimensions CM, and information on all work on files in Dimensions CM is stored in Dimensions CM tasks. This information is then synchronized back to the originating tasks (which are in turn related back to the originating change requests) in Development Control, ensuring a complete audit path of all work completed in context of a project.


As work progresses on the project, the build engineer sets up packages using the Dev Packages process app in Development Control. The build engineer relates the packages to baselines in Dimensions CM that collect all of the files associated with change requests in the project and deploy them to a build area. Using these files, the build engineer runs a build and installs it for testing purposes.


Using HP Quality Center / ALM, the QA staff tests the builds, both the nightly builds and release candidate builds. Defects may be tracked in the Dev Change Requests process app, and related to defects in Quality Center. Failed tests are returned to Development Control and the original change requests are returned to developers to fix. When a release candidate build passes testing, the build is turned over to the release engineer who will use a release management solution, such as Serena Release Manager, to deploy the build into all of the required environments.