Serena Orchestrated ALM Reference Architecture

SERENA®

Orchestrated ALMReference Architecture

Serena Proprietary and Confidential Information

Copyright © 2011 Serena Software, Inc. All rights reserved.This document, as well as the software described in it, is furnished under license and may be used or copied only in accordance with the terms of such license. Except as permitted by such license, no part of this publication may be reproduced, photocopied, stored in a retrieval system, or transmitted, in any form or by any means, electronic, mechanical, recording, or otherwise, without the prior written permission of Serena. Any reproduction of such software product user documentation, regardless of whether the documentation is reproduced in whole or in part, must be accompanied by this copyright statement in its entirety, without modification.This document contains proprietary and confidential information, and no reproduction or dissemination of any information contained herein is allowed without the express permission of Serena Software.The content of this document is furnished for informational use only, is subject to change without notice, and should not be construed as a commitment by Serena. Serena assumes no responsibility or liability for any errors or inaccuracies that may appear in this document.Third party programs included with the Dimensions product are subject to a restricted use license and can only be used in conjunction with Dimensions.

TrademarksSerena, StarTool, PVCS, Comparex, Dimensions, Mashup Composer, Prototype Composer, and ChangeMan are registered trademarks of Serena Software, Inc. The Serena logo and Meritage are trademarks of Serena Software, Inc. All other products or company names are used for identification purposes only, and may be trademarks of their respective owners.

U.S. Government RightsAny Software product acquired by Licensee under this Agreement for or on behalf of the U.S. Government, its agencies and instrumentalities is "commercial software" as defined by the FAR. Use, duplication, and disclosure by the U.S. Government is subject to the restrictions set forth in the license under which the Software was acquired. The manufacturer is Serena Software, Inc., 1900 Seaport Boulevard, 2nd Floor, Redwood City, California 94063-5587.

Publication date: October 2011

Reference Architecture 1

Table of Contents

Getting Started with The Serena O-ALM Architecture. . . . . 5What is the Serena Orchestrated ALM Architecture?. . . . . . . . . . . . . . . . 6

Audience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6Content and Format Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

End-to-End Orchestrated ALM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7What is the End-to-End ALM Lifecycle?. . . . . . . . . . . . . . . . . . . . . . 7

End-to-End Domain Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8About Projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9About Service Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9About Requirements Management . . . . . . . . . . . . . . . . . . . . . . . . . 10About Development Management . . . . . . . . . . . . . . . . . . . . . . . . . 10About Test Case Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . 10About Release Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

Projects Domain Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11Projects SBM Workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

Request Types for Demand Management. . . . . . . . . . . . . 13What is Serena Demand Management?. . . . . . . . . . . . . . . . . . . . . . . . . 14Change Requests Domain Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

Service Management Domain Model . . . . . . . . . . . . . . . . 17What is Serena Service Management? . . . . . . . . . . . . . . . . . . . . . . . . . 18Service Management Domain Model Diagram . . . . . . . . . . . . . . . . . . . . 18Service Management Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

Problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19Incident . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19Ops Change Request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19Configuration Item (CI) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19Knowledge Base (KB) Article. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

Configuration Management Database (CMDB) Domain Model . . . . . . . . . 20CMDB Objects. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20Configuration Item (CI) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

Requirements Management Domain Model . . . . . . . . . . . 23What is Serena Requirements Management?. . . . . . . . . . . . . . . . . . . . . 24

Where Requirements Management Fits in the Project Lifecycle . . . . . 24Requirements Management Domain Model Diagram. . . . . . . . . . . . . . . . 25Requirements Management Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

Requirement. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25Requirement Version . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

2 Serena® Orchestrated Application Lifecycle Management

Requirement Baseline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26Collection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26Snapshot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26Document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26Requirement Change Request . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26Approval Request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

Development Management Domain Model . . . . . . . . . . . . 27What is Serena Development Management? . . . . . . . . . . . . . . . . . . . . . 28Development Management Domain Model. . . . . . . . . . . . . . . . . . . . . . . 28Development Management Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

Development Change Requests. . . . . . . . . . . . . . . . . . . . . . . . . . . 29Baselines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29Build Jobs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29Development Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29Development Packages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30Sprints. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30Story . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30Software Defect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

Agile Planning Domain Model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31Sprints. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31Composite Stories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31Epics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31Goal Stories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32Development Change Requests. . . . . . . . . . . . . . . . . . . . . . . . . . . 32Stories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32SW Defects. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32Dev Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

Development Management SBM Workflows . . . . . . . . . . . . . . . . . . . . . . 32Development Change Requests Workflow. . . . . . . . . . . . . . . . . . . . 33Development Tasks Workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34Development Packages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

Release Management Domain Model . . . . . . . . . . . . . . . 37What is Serena Release Management? . . . . . . . . . . . . . . . . . . . . . . . . . 38Release Management Domain Model . . . . . . . . . . . . . . . . . . . . . . . . . . 38Release Management Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

Release Trains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38Releases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39Release Packages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39Release Change Requests. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39Deployment Units . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39Environments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

Deployment Tasks Domain Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39Release Packages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40Process Templates. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40Runbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40Deployment Tasks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40


Release Management Environments Domain Model . . . . . . . . . . . . . . . . 41Release Management SBM Workflows. . . . . . . . . . . . . . . . . . . . . . . . . . 42

Release Train Workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43Application Release Workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44Deployment Task Workflows. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45Release Package Workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48Deployment Process Template Workflow . . . . . . . . . . . . . . . . . . . . 50

Test Case Management Domain Model . . . . . . . . . . . . . . 51What is Serena Test Case Management?. . . . . . . . . . . . . . . . . . . . . . . . 52Test Case Management Domain Model . . . . . . . . . . . . . . . . . . . . . . . . . 52Test Case Management Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

Test Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53Test Plans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53Test Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53Test Runs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53Test Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53Test Suites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

Key Performance Indicators (KPI) Domain Model . . . . . . . 55What are Serena KPIs?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56Default KPIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

Build Success Rate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56Defect Escape Rate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57Project Defects Found / Project Defects By Month . . . . . . . . . . . . . . 57Development Packages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57Project Change Requests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57Project Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58



Chapter 1Getting Started with The Serena O-ALM Architecture

What is the Serena Orchestrated ALM Architecture? 6End-to-End Orchestrated ALM 7End-to-End Domain Model 8Projects Domain Model 11


Chapter 1 Getting Started with The Serena O-ALM Architecture

What is the Serena Orchestrated ALM Architecture?The Serena Orchestrated ALM Architecture provides you with a view of the various domains supported by the Serena Orchestrated ALM product line, and will help anyone implementing Serena solutions understand how the solutions are designed. These solutions include Serena Development Manager and Serena Release Manager.

AudienceThis document is intended for:

Serena product users who want to understand the high level Orchestrated ALM scenario, and the various solutions that comprise it.

Advanced Serena product users and administrators who want to better understand the architectural domain models underlying the Orchestrated ALM solutions, and the objects that comprise these models.

Content and Format OverviewThis document includes a series of diagrams that illustrate the domain model for the related elements of the complete, end-to-end application lifecycle management scenario as implemented by Serena Software. These diagrams lay out the different types of objects that comprise the Serena solutions for each of these domains (such as development management and release management). The objects are simply the components that each domain includes. For example, development management includes change request and task objects. Every object is described for your reference. In this sense, you can regard this document as an illustrated glossary of Serena Orchestrated ALM concepts.

UML Notation Quickstart

The diagrams in this document use established UML (Unified Markup Language) notation. You will see the following symbols. It is important to understand what they mean.

Symbol Meaning

Aggregated connection; items associated via an aggregate connection may exist independently of the connection object; the original object aggregates the connected object

Sits beside a related object; denotes that any number of that type of object may be related.

The object to which the arrow points inherits properties from the related object.

Sits beside a related object (see connector line); denotes that there may be anywhere between zero and one of the associated objects.

End-to-End Orchestrated ALM


End-to-End Orchestrated ALMSerena Orchestrated ALM is a collection of solutions that, altogether, address the entire product development lifecycle, starting with incoming demand management and concluding with release management. Here we will look at an example lifecycle as implemented by Serena ALM, and then study the end-to-end Orchestrated ALM domain model.

What is the End-to-End ALM Lifecycle?The following diagram illustrates an example end-to-end Serena Orchestrated ALM lifecycle.



Lets take a look at specifics for each lifecycle stage, in order to better understand how Serena Orchestrated ALM solutions plays a role.

End-to-End Domain ModelThe following domain model illustrates the complete, end-to-end, orchestrated ALM architecture. This includes the high level objects that make up the Serena ALM offerings, including Service Management, Request Management, Requirements Management, Development Management, Release Management, and Test Case Management. This diagram complements the end-to-end scenario by clarifying what objects the various systems include, and how those objects interact. This diagram, like others in this

StageSerena O-ALM Solutions Description

Project Approval

Serena Service Manager / Serena Request Manager, Serena Development Manager

The Business Manager uses Serena Service Manager to manage incoming demand. Then, using Serena Request Manager, the Business Manager can create change requests to start implementing the work.

The Project Manager creates a new project in Serena Development Manager for this work.

Analysis, Definition

Serena Release Manager, Serena Requirements Manager, Serena Test Case Manager, Serena Development Manager

The Release Manager creates a release train (with calendar) and release in Serena Release Manager.

The Business Analyst defines requirements in Serena Requirements Manager based on the original change requests.

The Quality Assurance team then creates a test plan and test cases and suites using Serena Test Case Manager.

The Product Owner then generates development change requests in Serena Development Manager based on the requirements.

Develop, Test

Serena Development Manager, Serena Test Case Manager

The development team implements changes by working on tasks in Serena Development Manager. The tasks are synchronized to Dimensions CM, where developers can check files in and out using their IDE.

The build engineer runs regular builds.

QA tests the builds using Serena Test Case Management.

When the project is ready, the Management Team transitions it to the Ready for Release state in Serena Development Manager.

Product Test

Serena Test Case Manager, Serena Development Manager

Turnover builds for testing are created from baselines generated using development packages in Serena Development Manager.

Turnover build is deployed to QA, who in turn deploys the turnover build to system integration testing.

QA staff test the build using Serena Test Case Manager, and submit defects into Serena Development Manager.

Release to Production

Serena Development Manager, Serena Release Manager

Management approve the project for release and transition it to the Release state in Serena Development Manager.

In Serena Release Manager, the Release Engineers define release and deployment tasks.

The release tasks and completed and the build is tested in staging. If it passes, it is deployed to production and the project is closed.

End-to-End Domain Model


document, use simple standard UML notation. Please see "UML Notation Quickstart" on page 6.

About ProjectsA project (shown here in dark blue) is a container unit for all work related to a development project. It stores all relevant artifacts across the development lifecycle, starting with enhancement requests and defects, progressing through development, and concluding with release. Projects are associated with all project-relevant objects such as change requests, requirements, and release packages.

To better understand how projects are implemented within the Serena Orchestrated ALM solutions, please see"Projects Domain Model" on page 11

About Service ManagementService Management (shown here in violet) is the practice of managing incoming demand to an IT organization, by tracking new Ops Change Requests (such as incident and problem reports), and then managing change over time in response to those requests, incidents, and problems. Service Management is implemented by Serena Service Manager.

For details on the Requirements Management domain, please see Chapter 3, "Service Management Domain Model" on page 17.



About Requirements ManagementRequirements Management (shown here in pink) is the practice of tracking the development and implementation of product requirements, from inception through to delivery. Serena Requirements Manager supports your requirements management process by allowing you to organize your product requirements according to type, into custom collections, and into documents that you can share with other stakeholders. Key to requirements management is the audibility of work over time, so that you can see how requirements have been implemented by developers and testers, and how final products are delivered. You can associated requirements to the change requests, enhancement requests, and releases via which the requirements are implemented.

For details on the Requirements Management domain, please see Chapter 4, "Requirements Management Domain Model" on page 23.

About Development ManagementDevelopment management (shown here in light blue) is implemented by Serena Development Manager. Development Manager enables you to orchestrate and monitor your key software development efforts, tracking source code changes and approvals through a central workflow engine. Development Manager uses Serena Business Manager (SBM) to coordinate events across your systems using Web services, integrating application project definition, source code management, test management, and release approvals. Track and report on development progress using the included dashboard solution, providing comprehensive decision-making support to managers and directors who need the latest information at all times on key performance indicators (KPIs).

For details on the Requirements Management domain, please see Chapter 5, "Development Management Domain Model" on page 27. For more on KPIs, please see Chapter 8, "Key Performance Indicators (KPI) Domain Model" on page 55.

About Test Case ManagementTest case management (shown here in green) is the process of managing product test cases and tracking the success or failure of tests when validating built products. This is implemented by Serena Test Case Management. Test cases are related to the development change requests that they are intended to validate. For details on the Requirements Management domain, please see Chapter 7, "Test Case Management Domain Model" on page 51.

About Release ManagementRelease management manages the flow of change into production. It is the handoff between development, quality assurance, and production operation teams. The goal of release management is to deploy application changes into production with high quality and without disrupting the business. But this process is often performed manually and is inefficiently connected to the rest of the application lifecycle, leaving a critical gap between application development and operations as well as creating a backlog of changes that must be made.

Release Management is implemented by Serena Release Manager.

For details on the Requirements Management domain, please see Chapter 6, "Release Management Domain Model" on page 37.

Projects Domain Model


Projects Domain Model

Projects SBM WorkflowProjects are implemented in SBM with the following workflow:



In this default workflow, project states include:

1 Inception: During this state, the Project Manager creates the project.

2 Elaboration: During this state, enhancement requests and defects are collected and prioritized. Business requirements may be submitted as well. Changes requests are prioritized and the final scope is agreed to. The project is approved.

3 Construction: Development work may be organized into sprints and user stories, if the team uses Agile development methodology. Development tasks are created and related to the requests. The tasks are assigned to developers to implement. Developers work on the tasks, storing new versions of files in their configuration management system (such as Dimensions CM). Regular builds are compiled and installed for testing, and requests are assigned to QA to test. Once all of the requests have been implemented, the Development Manager can transition the project to the next state.

4 Transition: During this state, QA perform robust testing of the completed product or features, recording defects as they find them. Working from test plans, QA executes test cases. QA submits defects to the Change Request process app, and the defects are assigned to developers to fix. QA validates fixes and closes defects as they are resolved. the finished product is prepared for release. The final builds are collected and packaged for deployment. Once the project has been released, the project can move to the final state.

5 Complete.


Chapter 2Request Types for Demand Management

What is Serena Demand Management? 14Change Requests Domain Model 14


Chapter 2 Request Types for Demand Management

What is Serena Demand Management?Demand management is the practice of planning and managing incoming demands for work using different classes of change request that are tailored to specific parts of the business.

Change Requests Domain ModelThe following model illustrates the different types of change requests implemented by Serena Demand Management, and describes the relationships between request types.

This model describes the following types of change request.

Business Change Request

Change Requests Domain Model


A business change request is submitted and managed at the project level. This may be a request for a new project, a defect, or an enhancement request. You can learn more about the project domain model here: "Projects Domain Model" on page 11.

Development Change Request

A development change request describes work to be completed by development staff. It may be based on a business change request, a new requirement, or both. Development change requests can be broken down into stories and tasks. Stories describe the expected user experience, and tasks describe the actual work to be completed. Tasks can then be assigned to specific developers. For more on development change requests, see Chapter 5, "Development Management Domain Model" on page 27.

Ops Change Request

An ops change request is a request submitted into service management, to be reviewed and managed by IT ops staff. For more on ops change requests, see Chapter 3, "Service Management Domain Model" on page 17.


Chapter 2 Request Types for Demand Management


Chapter 3Service Management Domain Model

What is Serena Service Management? 18Service Management Domain Model Diagram 18Service Management Objects 19Configuration Management Database (CMDB) Domain Model 20


Chapter 3 Service Management Domain Model

What is Serena Service Management?Serena Service Manager represents a new process-driven approach to ITSM – one that allows business and IT to work together, in perfect harmony. Serena Service Manager comes packaged with fully functional, easy-to-use applications including those for Request, Incident, Problem, Change and Configuration Management. Core processes have been verified by Pink Elephant, proving that they deliver true IT process improvements and efficiency in accordance with ITIL best practices.

Service Management Domain Model DiagramThe following image describes the relationships between objects in the Serena Service Management domain model.

Service Management Objects


Service Management Objects

ProblemA problem is a description of an issue that needs resolution. This may be a defective software issue, a hardware failure, or any other type of problem. Problems have a unique workflow. A problem may be related to any number of incidents and change requests.

IncidentAn incident is a specific occurrence or symptom related to a problem. For example, while a problem might describe a known software issue that needs to be resolve, an incident describes specifically what happened to a particular user and may provide steps to work around in. Incidents follow their own workflow. They may be related to any number of problems, change requests, or knowledge-base articles.

Ops Change RequestAn ops change request is a request for change that has been submitted to the IT operations group, in response to particular problems or incidents. A change request can affect any number of configuration items (CIs). The CIs may include web pages, images, source code files, etc.

ServiceA service is a particular activity or action to be delivered in response to a service request, and as required by the established Service Level Agreement (SLA). Services may include providing new computers, upgrading specific software packages, etc. A service is a configuration item related to the change request. In this domain model, services may aggregate any number of servers, where software is to be installed or modified. Services may also aggregate any number of applications to be modified.

Configuration Item (CI)A CI may be any object that is affected by a related change request. CIs are classified into types, categories, and subcategories. A simple example is a server. A server is a hardware node, and the service to be implemented may be carried out on it. Another example is an application. An application is simply a collection of software objects, residing on a server, that may be affected by the originating service request. Configuration items may be related to any number of other configuration items.

Knowledge Base (KB) ArticleA knowledge base (KB) article is a document stored in a knowledge base that describes symptoms of a technical issue, and provides instructions for working around the issue.



Configuration Management Database (CMDB) Domain Model

Service management is about the management of configuration items. The Configuration Management Database (CMDB) domain model describes the objects that may be related to a configuration item.

CMDB ObjectsThe Configuration Management Database domain model includes the following objects.

Ops Change Request

A request for change that has been submitted to the IT operations group, in response to particular problems or incidents.

Configuration Item (CI)A CI may be any object that is affected by a related change request. CIs are classified into types, categories, and subcategories. A CO can be related to any number of other CIs. A CI can be broken down into the following example types, as in this model:

Service.

Hardware. This may be further categorized into storage, network, or server hardware.

Configuration Management Database (CMDB) Domain Model


Software.




Chapter 4Requirements Management Domain Model

What is Serena Requirements Management? 24Requirements Management Domain Model Diagram 25Requirements Management Objects 25


Chapter 4 Requirements Management Domain Model

What is Serena Requirements Management?Serena Requirements Management provides you with a way to define, manage, and trace all of your requirements across the development lifecycle. Distributed teams can collaborate, discuss and update many different types of requirements, which can be collected and published to Microsoft Word and Excel documents.

Serena Requirements Management provides deep functionality over the web. You can concurrently edit requirements, comment, vote in polls, and manage changes.

Where Requirements Management Fits in the Project LifecycleAs illustrated in the end-to-end domain model (see "End-to-End Orchestrated ALM" on page 7), requirements definition happens early in a development project’s lifecycle. Ideally, requirements are defined and approved before active produce development begins; approved requirements are the basis of development change requests, which in turn determine the work to be carried out by development staff. Requirements are also the basis of test requirements, thus ensuring that the original requirements for a product are followed through to the end of a project, and validated as features are tested.

Requirements Management Domain Model Diagram


Requirements Management Domain Model DiagramThis diagram illustrate the Requirements Management domain model. This includes key objects that comprise the requirements management domain, and elaborates on the relationships between those objects.

Requirements Management Objects

RequirementA requirement defines the specific use case and attributes of a new feature.

The domain model defines the following characteristics for requirements:

Any number of requirements may be aggregated into collections.

Requirements may be created in response to Requirement Change Requests.

Requirements are versioned.

A requirement can be related to other requirements.

Requirements may be related to any number of test requirements, from the test management system.

Requirements may be related to any number of development change requests, from the development management system.


Chapter 4 Requirements Management Domain Model

There may be many types of requirements. Out of the box, a requirement can be classified as a business requirement, a system requirement, or a design requirement.

Requirement VersionA requirement version is a specific instance of a requirement that was saved at a particular point in time. Any number of requirement versions may be aggregated into baselines.

Requirement BaselineA requirement baseline is a frozen collection of versions of requirements at a given point in time. A baseline is related to a collection, and may also be related to any number of requirements approval requests.

CollectionA collection is a gathering of any number requirements that are all related in some way. A collection may also be aggregated into a document for publishing. A collection may also include requirements that are in a baseline.

SnapshotA snapshot is backup of a specific version of a requirements document.

DocumentA document is a representation of a collection of requirements that may be published out to Microsoft Word format.

Requirement Change RequestA specific type of change request that asks for new requirements or modifications to existing requirements. A requirements change request can be related to any number of requirements.

Approval RequestA request sent to project stakeholder to approve a requirement.


Chapter 5Development Management Domain Model

What is Serena Development Management? 28Development Management Domain Model 28Development Management Objects 29Agile Planning Domain Model 31Development Management SBM Workflows 32


Chapter 5 Development Management Domain Model

What is Serena Development Management?Serena Development Management enables you to orchestrate and monitor your key software development efforts, tracking source code changes and approvals through a central workflow engine. Development Manager uses Serena Business Manager (SBM) to coordinate events across your systems using Web services, integrating application project definition, source code management, test management, and release approvals. Track and report on development progress using the included dashboard solution, providing comprehensive decision-making support to managers and directors who need the latest information at all times on key performance indicators (KPIs).

For detailed information on the out-of-box workflows and usage scenarios for Serena Development Manager, please see the Serena Development Manager Getting Started Guide, available from here:

http://help.serena.com/alm/dvm/doc/development_manager_getting_started_guide.pdf

Development Management Domain ModelThis domain model lays out the primary objects that comprise Serena Development Management, and illustrates their relationships to each other.

http://help.serena.com/alm/dvm/doc/development_manager_getting_started_guide.pdf

Development Management Objects


Development Management ObjectsThe Serena development management model comprises the following objects.

Development Change RequestsDevelopment change requests capture and track requests for code changes that are submitted into the development organization. These may be in response to defects found during testing, or may be enhancement requests derived from project requirements. As described in the domain model:

Any number of development change requests can be collected into development sprints (or planning intervals).

Change requests can be aggregates into development packages, providing details on updated code to be included in builds.

Development work can be broken down into any number of tasks that are then aggregated up into the change request.

Development requests may be broken down into stories or defects.

Any number of test cases from the test management system may be related to a change request.

BaselinesA baseline is a collection of change requests that are all related to a particular milestone or release. Those change requests are in turn related to tasks and then to specific versions of files. Baselines therefore represent the state of all source files related to specific change requests at a given point in time. Baselines enable you to recreate the complete set of source files for specific milestones, from which you can then build and deploy.

In addition to change requests, baselines are associated with development packages, and in turn with release packages.

Build JobsA build job is a description of actions to be taken to initiative and deploy a build, for testing or other purposes. A build job in Dimensions CM works with external build tools to run regular builds.

Development TasksA development task is a type of change request that is designed to be assigned to specific developers and worked on. Using Serena Dimensions CM, you can associate tasks to specific code objects, ensuring traceability between change requests and work. Any number of tasks can be assigned to parent change requests.



Development PackagesA development package is a collection of a change requests to be included in a build for testing or release. Baselines that include the physic files to be built are associated to the development package.

SprintsA sprint is an interval of work, with a collection of change requests to be completed associated with it. In Agile development, this collection might be called a backlog. A sprint is a way to organize work into small increments that development teams can work on, one at a time.

StoryA story is a description of a user’s experience with the enhancement or fix that the change request is asking for.

Software DefectA software defect is an issue that describes a functional problem with software.

Agile Planning Domain Model


Agile Planning Domain ModelThe following domain model describes the objects and relationships when managing Agile development projects. This expands the Sprint node in the Development Management Domain Model.

Objects in the Agile Planning domain model include the following.

SprintsA sprint is an interval of work, with a collection of change requests to be completed associated with it. In Agile development, this collection might be called a backlog. A sprint is a way to organize work into small increments that development teams can work on, one at a time.

Composite StoriesA composite story is a collection of multiple user stories that describe a new feature, enhancement, or defect fix from a user perspective. A composite story may broken down into epics or goals stories, and may be related to product requirements.

EpicsAn epic is a type of user story that is too large in scope to fit into one user story. It may be broken down into several user stories.



Goal StoriesA goal story is a story that describes a high level feature or product goal.

Development Change RequestsSee "Development Management Domain Model" on page 28.

StoriesA story is a description of a user’s experience with the enhancement or fix that the change request is asking for.

SW DefectsA software defect is an issue that describes a functional problem with software.

Dev TasksA development task is a type of change request that is designed to be assigned to specific developers and worked on. Using Serena Dimensions CM, you can associate tasks to specific code objects, ensuring traceability between change requests and work. Any number of tasks can be assigned to parent change requests.

Development Management SBM WorkflowsDevelopment management is implemented by the Development Manager solution. This solutions includes the following SBM process apps, each with workflows specific to the objects that the apps manage. Review these workflows, which are exported directly from SBM Composer, to understand how the development management domain model is implemented out-of-the-box.

These process apps include:

Development Change Requests

Development Tasks

Development Packages

Development Management SBM Workflows


Development Change Requests Workflow

Development change requests follow this workflow out of the box with Serena Development Manager. This can be tailored as needed to meet the needs of specific organizations.

1 The Development Manager persona plans the work. This includes requesting information from other resources, and either approving the request for work to start, or rejecting and closing the request.

2 The Developer persona completes work on the request while it is in the "Under Work" state.

3 The Build Engineer persona consumes the finished work once the developer declares that it is ready for build and test, and then runs a build.

4 The Quality Assurance Persona then tests the built code. If the test fails, the request is returned to the Developer persona in the Under work state. If the test succeeds, then the request can be approved and closed.

5 At any point in the workflow, development tasks and child change requests can be created, the request synchronized with an external test management system, or the request can be deleted.



Development Tasks Workflow

Development tasks follow this workflow, out of the box, with Serena Development Manager. This can be tailored as needed to meet the needs of specific organizations.

1 The Developer persona starts work.

2 When work is initially completed, the Developer persona can send the task (and its associated work) to a peer to review. If the peer accepts, then the task can be completed. If the peer rejects, then the task can be returned to the Under Work state.

3 At any time, the task can be synchronized to Dimensions CM (so that developers can see the task in context of their development environment, which is integrated to Dimensions CM, as well as relate files to the task).

Development Management SBM Workflows


Development Packages

Development packages follow this workflow, out of the box, with Serena Development Manager. This can be tailored as needed to meet the needs of specific organizations.

1 The Build Manager persona creates the package that will store the contents of the baseline to be built. The build manager then creates and verifies the baseline. If the baseline appears to include the correct requests and associated files, then the build is started. If the build succeeds, then the build can be sent to QA. If the build fails, then the build is returned to the initial state so that a new baseline can be created.

2 The Quality Assurance persona receives the build and tests it. If testing fails, then the development package is returned to the initial state and the Build Manager must recreate the build after addressing issues. If testing is successful, then the build can be prepared for release.

3 The Release Manager persona approves the development package for release and the workflow is complete. The release itself is then carried out using the Release Management workflows. See Chapter 6, "Release Management Domain Model" on page 37.

4 At any time, a new Dimensions CM baseline can be created or built.



Getting Started Guide 37

Chapter 6Release Management Domain Model

What is Serena Release Management? 38Release Management Domain Model 38Release Management Objects 38Deployment Tasks Domain Model 39Release Management Environments Domain Model 41Release Management SBM Workflows 42


Chapter 6 Release Management Domain Model

What is Serena Release Management?Serena Release Management enables you to plan, control, and automate all your application releases from definition to deployment into production with start-to-finish traceability and end-to-end visibility across both mainframe and distributed environments.

Release Management Domain ModelThe following domain model describes the key objects that comprise the Serena Release Manager architecture, and their relationships to each other. Orange items are part of the Serena Release Control offering, a set of applications that run on Serena Business Manager.

Release Management Objects

Release TrainsRelease trains provide published schedules of changes to production. One or more application releases are associated with each release train.

Release trains have types of major, minor, and emergency. These are used to determine the stages the releases go through as well as drive release policies on what types of changes may be delivered.

A release train may be related to any number of releases, and to any number of stages.

Deployment Tasks Domain Model


ReleasesReleases are associated with an application or project, where the application or project architecture is specified by components. One or more release packages are associated with each application release.

Releases may be related to any number of release packages. Releases are also related to the CMDB application that is used as the release vault.

Release PackagesA release package is a portion of IT or service infrastructure normally built, deployed, tested, and released together. Release packages group changes within an application release. One or more development change requests and deployment units are associated with each release package.

Release Change RequestsA change request is an object used to report a defect, suggest an enhancement, or detail other work for a particular product. Requests can include external files (such as requirements or specification documents) as attachments. Release change requests may also be related to other types of change requests, such as development change requests or operational change requests.

Deployment UnitsA deployment unit is a representation of a set of deployable components, such as a Dimensions CM baseline with build outputs.

EnvironmentsAn environment is a physical computer and operating system on which software resides; for example, a Windows or UNIX server. See "Release Management Environments Domain Model" on page 41.

Deployment Tasks Domain ModelDeployment activities in Serena Release Manager are carried out by deployment tasks. This domain model describes the objects related to deployment tasks.



Release PackagesA release package is a portion of IT or service infrastructure normally built, deployed, tested, and released together. Release packages group changes within an application release. One or more development change requests and deployment units are associated with each release package.

Process TemplatesA release process template Defines repeatable processes for deploying application release components into environments. One or more release packages are associated with each deployment process template.

RunbooksA runbook is a set of defined deployment procedures that support routine, successful deployment operations.

Deployment TasksA deployment task is an action to be executed as part of the deployment process to deploy a release package into a specific environment. Deployment task types include manual, vault, and automation.

Release Management Environments Domain Model


Manual Tasks

A manual task is a type of deployment task. This is an action to be executed by a person as part of the deployment process

Release Vault Tasks

A release vault task is a type of deployment task that integrates with Release Vault for secure deployment of deployment units. Vault deployment tasks move deployment units (baselines in Dimensions CM) securely to deployment areas (environments).

Release vault tasks are related to the following objects:

Dimensions CM Build

Dimensions CM Build is a set of build management features provided by Serena Dimensions CM. Using Dimensions Build, you can define complex build jobs including scheduled start times, error handling, and more.

Dimensions CM Deployment

Dimensions CM Deployment is a set of deployment features provided by Serena Dimensions CM and utilized by Serena Release Vault as part of Serena Release Manager. Use Dimensions CM Deployment to automate the release of source code to specific deployment areas, and scope those releases using Dimensions CM baselines.

Subversion Import

Release vault tasks may include importing content from Subversion.

Clearcase Import

Release Vault tasks may include importing content from ClearCase.

Release Automation Task

A release automation task is a type of deployment task that integrates with release automation to automate installation and configuration tasks through the Release Automation software (such as Nolio) as part of the deployment process.

Operations Change Task

An operations change task is a type of deployment task that implements an internal operational process change.

Release Management Environments Domain ModelSerena Release Management comprises a number of environments that are required to support management and release of assets. This includes one source control environment, here denoted as CMDB (configuration management database) and associated software and server (all of which may reside on different systems. At the



release level, code is deployed to staging systems, deployment environments, and servers depending on the needs of the specific release package.

Release Management SBM WorkflowsRelease management is implemented by the Serena Release Manager solution. This solution includes several SBM process apps, each with workflows specific to the objects that the apps manage. Review these workflows, which are exported directly from SBM Composer, to understand how the release management domain model is implemented out-of-the-box.

Serena Release Manager includes out-of-the-box workflows for the following types of object:

Release trains

Application releases

Automated Deployment tasks

Manual Deployment tasks

Release packages

Release Vault deployment task

Deployment process template

Release Management SBM Workflows


Release Train Workflow

Release trains follow this default workflow with Serena Release Manager. This can be tailored as needed to meet the needs of specific organizations.

Release trains include the following states:

1 Planning: Once the release train has been created, the release engineer plans the release train at a high level, including defining release intervals and creating specific releases that will be related to this release train.

2 Review: The release train content is reviewed with project stakeholders. When it is approved, it can be transitions to the next state.

3 In Progress: The release train is actively in use. This may span a great deal of time, depending how many releases are associated with it.

4 Completed: The release train is no longer active.

5 Release Failed: Deployment of a particular release failed.



Application Release Workflow

Application releases follow this default workflow with Serena Release Manager. This can be tailored as needed to meet the needs of specific organizations.

Application releases include the following states:

1 Planning: Once the release has been created, the release engineer plans the release work, including defining the scope and timing of the release.

2 Review: The planned release content is reviewed with project stakeholders. When it is approved, it can be transitions to the next state.

3 In Progress: The release is under work.

4 Completed: The release has been deployed and can be closed.



Deployment Task Workflows

Automated Deployment Task Workflow

Automated deployment tasks follow this default workflow with Serena Release Manager. This can be tailored as needed to meet the needs of specific organizations.

Automated deployment tasks include the following states:

1 Planned: Once the task has been created, the release engineer plans the release work.

2 In Progress: The task is executed, and the release engineer carries out the release work described by the release task.

3 Failed: If the task fails, it is returned to In Progress until it is corrected and succeeds.

4 Completed: The task has completed successfully.



Manual Deployment Task Workflow

Manual deployment tasks follow this default workflow with Serena Release Manager. This can be tailored as needed to meet the needs of specific organizations.

Manual deployment tasks include the following states:







Release Vault Deployment Task Workflow

Release vault deployment tasks follow this default workflow with Serena Release Manager. This can be tailored as needed to meet the needs of specific organizations.

Release vault deployment tasks include the following states:







Release Package Workflow

Release packages follow this workflow out of the box with Serena Release Manager. This can be tailored as needed to meet the needs of specific organizations.

The release vault workflow is here visualized as a series of steps spanning several stages: Start, Development, Integration, Staging, and Production. We will look at each of these swimlanes in turn.

Start

The development package is created.

Development

The release manager defines development change requests, deployment tasks, and deployment units, gradually assembling the components to be releases. When the release is ready for deployment, it can be approved, which transitions it to the Ready for Deployment state. From here, it can be deployed for integration testing, to staging, or into production.



Integration

During integration testing, the package is deployed to the integration testing environment, then tested. If testing is successful, it enters the Ready for Staging state.

Staging

During staging, the package is first deployed to the staging environment (if this fails then the package enters an exception state and re-deployed). While in Staging, the release is tested. If it fails testing, it enters an Exception state and is redeployed with fixes as needed. If testing succeeds, the package moves into the Ready for Production state, and it is then deployed.

Production

The package is deployed to production and the workflow is completed.

Exceptions

When certain events fail, the package enters into an exception state until the issue can be resolved.



Deployment Process Template Workflow

Deployment process templates follow this default workflow with Serena Release Manager. This can be tailored as needed to meet the needs of specific organizations.

Deployment process templates include the following states:

1 Development: The template is under work.

2 Review: Stakeholders review the template.

3 Available: The template is now available to use by other team members.

4 Inactive: The template is no longer available to use.


Chapter 7Test Case Management Domain Model

What is Serena Test Case Management? 52Test Case Management Domain Model 52Test Case Management Objects 53


Chapter 7 Test Case Management Domain Model

What is Serena Test Case Management?Serena Test Case Management is implemented as a process application running on Serena Business Management. This process app provides the fundamental features necessary to validate that requirements have been implemented correctly. You can manage your test plans and suites, and script specific test steps. Test plans and test results are in turn related back to change requests in other Serena Orchestrated ALM solutions.

Test Case Management Domain Model

Test Case Management Objects


Test Case Management Objects

Test CasesA test case is a specific series of steps to be completed by a tester to validate functionality.

Any number of test cases can belong to a test suite or test requirement.

Test PlansA test plan is an overall collection of test requirements and test suites that, in total, comprises the testing strategy for a project or application.

Test RequirementsA test requirement provides specific criteria for validating that a feature has been implemented correctly. A test requirement may be associated with any number of test cases.

Test RunsA test run represents the completion of the steps in a test plan.

Test StepsA test step is a specific instruction to a tester who is working on completing a test run.

Test SuitesA test suite is a collection of test cases related to a specific test plan. A test suite may include any number of test cases.


Chapter 7 Test Case Management Domain Model


Chapter 8Key Performance Indicators (KPI) Domain Model

What are Serena KPIs? 56Default KPIs 56


Chapter 8 Key Performance Indicators (KPI) Domain Model

What are Serena KPIs?Serena provides a powerful ALM Dashboard application that enables you to track key performance indicators in your environment, such as Build Success Rate, Defect Escape Rate, and more. Serena ALM Dashboard is a graphical reporting server that you can tailor as needed to provide rich metrics on the data of your choice.

Default KPIsSerena ALM Dashboard includes a number of default KPI metrics.

Build Success RateThis graph displays the percentage of builds that completed successfully. This data is pulled from Dimensions CM. For example:

You can click the graph to see information about specific builds, including the name of the Dimensions CM build configuration, when the build stopped, and whether it succeeded.

Default KPIs


Defect Escape Rate

This graph displays the percentage of defects that are escaped. These are defects that were reported by users or customers, that were not found by internal testing.

Project Defects Found / Project Defects By MonthThese graphs (Project Defects Found and Project Defects by Month) display, in different colors, the number of active and inactive defects either for particular projects, or found on from month to month. The following is an example of Projects Defects Found.

Development PackagesThis graph lists the number of development packages in each project defined in ALM Projects. These packages are associated from the Dev Packages process app.

Project Change RequestsThis graph displays the number of open change requests against projects defined in ALM Projects. The change request count is pulled from the Dev Change Requests process app.


Chapter 8 Key Performance Indicators (KPI) Domain Model

The change requests are color-coded according to their current state, such as Planning, Ready for Build, Ready for Work, and Complete.

Project StatusThe project status graph lists all current projects in the ALM Projects process app and displays their status as green, red, or yellow. This graph also lists the state that the project is currently in. You can click a project name to drill down into project state, start date, and end date.

Documents

Serena Orchestrated ALM Reference Architecture