Phased Lifecycle Design Phase

October 2012

[Rev. # or date] – HP Restricted 1

Phased Lifecycle Design Phase

Participant Guide
a.4

For best results: First, install the tools. Then, use them to follow the pre-requisites and then this course, per
“Phased Lifecycle” here.

Rev 2 HP Restricted 2
Phased Lifecycle Design Phase

Rev 2 HP Restricted 3
Phased Lifecycle Design Phase

[Rev. # or date] – HP Restricted 4

Phased Lifecycle Design Phase

[Rev. # or date] – HP Restricted 5

 Phased Lifecycle Design Phase

Participant Guide

Technical specifications (or tech specs) are “timeless” artifacts. That means they are re-used and updated with
each release, in contrast to a list of line item deliverables used only for the current release. This permits tech specs
to stay consistent with the source code they specify. Recall the Release Perspective and Application Perspective
introduced in the Project Scoping Phase. Managing tech specs as timeless artifacts supports the application
perspective and use cases after the project is over.

[Rev. # or date] – HP Restricted 6

Phased Lifecycle Design Phase

Participant Guide

Technical specifications are timeless artifacts that stay in the application workspace and are
updated with each release. This keeps the app’s technical details up-to-date. Traces from the
functional specs of each release maintain the context of the changes.

This approach contrasts with:

1. Test spec line items that journal the changes for a release but which are not
modifications to the timeless technical design.
2. Separate tech spec document, e.g., Word in SharePoint, which does not trace from the
specifications and cannot trace to source code.

[Rev. # or date] – HP Restricted 7

Phased Lifecycle Design Phase

[Rev. # or date] – HP Restricted 8

Phased Lifecycle Design Phase

Participant Guide
u.4

A structure can also be called:

•Taxonomy
•ToC or Table of Contents

[Rev. # or date] – HP Restricted 9

 Phased Lifecycle Design Phase

Participant Guide
u.4

In the example illustrated here, it may be that 107181:ePrime is in the WS1:Tahiti release but “CI Name 3” is not. CI Name 3 is
under Application because its home is Workspace 1, which happens to be where WS1:Tahiti is hosted.

To create a folder, create a requirement and set Requirement Type = Folder.

Multiple workspaces
When the application and release workspaces are different, requirements and use cases will have been copied to the app workspace so that the
functional and technical specs can be authored there. For details, please see Lesson 1 of the Project Scoping Phase training.

A note about terminology:

ALM still uses the former term “Product” instead of the go-forward term “Application”. It also uses “Product Requirements” instead of
“Functional Specifications” and “Technical Requirements” instead of “Technical Specifications”. The go-forward terminology has not
changed and this training (and the rest of Application Transformation) will use it. The old terminology will be confined to ALM and
will be updated eventually. To minimize confusion, when ALM forms are being described, this notation will indicate the go-forward
and ALM field name, e.g., “TS (TR)”.

[Rev. # or date] – HP Restricted 10

Phased Lifecycle Design Phase

Participant Guide
u.4

* These values are not updated yet because, at the start of the Design Phase, it is not yet known which
components to change for the functional specifications. In the Design Phase, as those components are
identified the value of Target Release is assigned. Until that time, Target Release will equal the release for
which this component line item was last changed.

Note that application 114372:PDAPI is in release Jupiter whose home is Workspace 4. That release started
earlier than WS1:Tahiti and so its value of Target Release has been updated. The BRs and UCs from Jupiter
have been copied from Workspace 4 into Workspace 1 per the process described in Project Scoping Phase,
Lesson 1.

[Rev. # or date] – HP Restricted 11

Phased Lifecycle Design Phase

[Rev. # or date] – HP Restricted 12 12

Phased Lifecycle Design Phase

[Rev. # or date] – HP Restricted 13 13

Phased Lifecycle Design Phase

Participant Guide

This illustrates the rationale of the requirements folder structure. Because of the BR-FS alignment:
BR / FS (PR) is under “Releases”
whereas TSs, being timeless and therefore not aligned to BR and FS, is separate and under
“Applications”.

Traces connect these distinct groupings as above.

[Rev. # or date] – HP Restricted 14 14

 Phased Lifecycle Design Phase

Participant Guide
a.4

This is a simple example, but the concept is the same for any traces. Traces are leaf-to-leaf node and any FS(s) can
trace to any TS(s). This is the “FS-to-TS mapping”. We will see shortly that the only TSs involved in traceability are those
for which Target Release is assigned to the current one, e.g., “WS1:Tahiti”.

It is normal for these traces to cross project boundaries (unlike BR  PR traces). Traces from many projects can trace to
a single component. This is addressed in the “Interdependencies” topic shortly.

How to enter a trace: Please see the next slide.

[Rev. # or date] – HP Restricted 15

 Phased Lifecycle Design Phase

Participant Guide
a.4

To display this view, use View | Requirement Details. For a list of all ALM fields and values, please see here.

[Rev. # or date] – HP Restricted 16

 Phased Lifecycle Design Phase

Participant Guide

In this slide, we see a set of applications labeled by their CI Names. We are highlighting the four in the middle. If
we capture interface basics in ALM/Requirements, then we can use traceability to find and resolve tricky cross-asset
issues proactively. For example:

•If an interface between two applications is to be changed then there must be a common business requirement that
traces to those two applications.
•If no business requirement traces to functional specifications in adjacent applications then their interface should
not change (this is the converse of #1).
•If a business requirement traces to two applications, there might be an interface change between them but this is
not necessarily true. Imagine a requirement that traces to applications ABC, DEF, and JKL. ABC interfaces to DEF,
DEF interfaces to JKL but ABC does not interface to JKL. That kind of chain is quite common. This rule is listed for
completeness but there is currently no plan to automatically check for such cases.

[Rev. # or date] – HP Restricted 17

 Phased Lifecycle Design Phase

Participant Guide
u.4
Requirement Type: For this phase, “Technical” is used.

For each interface, in the TS Info tab select the:

• “Impacted application interface” - This is the application to which this interfaces
• “Data flow” - Whether the interface with the other application is an input, output, or both. Please see
previous slide.

In the Description tab, enter the details for that interface, including the names of people in the other app responsible
for the interface.

Values in “Impacted application interface” (and “Product”) pull downs will be CI Names which should be
automatically updated. If any are missing, please ask your PM to notify an ALM project admin.

Values in “Data flow” pull down are: Input, Output, Input and Output

[Rev. # or date] – HP Restricted 18

Phased Lifecycle Design Phase

[Rev. # or date] – HP Restricted 19

Phased Lifecycle Design Phase

[Rev. # or date] – HP Restricted 20

Phased Lifecycle Design Phase

Participant Guide
a.4

[Rev. # or date] – HP Restricted 21

Phased Lifecycle Design Phase

Participant Guide
u.4

“GADSC” is the former name of “Development Services”. The terminology will be updated in the next training release.

Reports to help manage ALM projects are described here.

Managing user accounts

The PM manages the user accounts for their project using the Permission Manager tool. For installation and usage
instructions, as well as details about the roles, please go here. Although a PM can create other PM accounts, the
guidance is to have no more than two per PPM project. How does the first PM get their account? See here.

Managing customized lists

The PM can customize the Team and Component lists in ALM to help manage their project. That is done with the List
Administrator tool. For installation and usage instructions, as well as info about these lists, please go here.

[Rev. # or date] – HP Restricted 22

Phased Lifecycle Design Phase

Participant Guide

• Ensures TSs are completely and accurately documented

– Including rationale: “Why this design instead of some other design?”
• Plans design review, leads design review, verifies cited review issues are logged as NCRs
in ALM/Change Requests and resolved.
• Ensures scorecard is updated at least 1x/week (per PM) to 100%:
– Creates a new copy of the scorecard from the Artifact Library and saves it as a new
file in a team SharePoint, per the Project Manager.
– Name the scorecard after the project (top level FS name).
– Ensures that TSs are scored by someone other than the TS author.
– Validates the scores and works issues as required.
– Checks completed scorecard into the SDLC Manager.
• Leads project phase retrospective.

[Rev. # or date] – HP Restricted 23

Phased Lifecycle Design Phase

Participant Guide

For details about the EDA process, please take Enterprise Data Architecture (EDA) training at
http://prime21.sharepoint.hp.com/teams/hpitportal/AppTrans/Pages/Training.aspx.

After you successfully complete the training, if you still have questions you may address them to an EDA
lead, per the Lead Directory at
http://prime21.sharepoint.hp.com/teams/hpitportal/AppTrans/Lists/L2%20AppTrans%20Contact%20
List/AllItems.aspx

Note which EDA artifacts were used in your design by adding them to the Details tab.

[Rev. # or date] – HP Restricted 24

Phased Lifecycle Design Phase

Participant Guide

For details about the EDA process, please take Enterprise Data Architecture (EDA) training at
http://prime21.sharepoint.hp.com/teams/hpitportal/AppTrans/Pages/Training.aspx.

After you successfully complete the training, if you still have questions you may address them to an EDA
lead, per the Lead Directory at
http://prime21.sharepoint.hp.com/teams/hpitportal/AppTrans/Lists/L2%20AppTrans%20Contact%20
List/AllItems.aspx

Note which EDA artifacts were used in your design by adding them to the Details tab.

[Rev. # or date] – HP Restricted 25

 Phased Lifecycle Design Phase

Participant Guide

For details about the EDA process, please take Enterprise Data Architecture (EDA) training at
http://prime21.sharepoint.hp.com/teams/hpitportal/AppTrans/Pages/Training.aspx.

After you successfully complete the training, if you still have questions you may address them to an EDA lead,
per the Lead Directory at
http://prime21.sharepoint.hp.com/teams/hpitportal/AppTrans/Lists/L2%20AppTrans%20Contact%20List/AllI
tems.aspx

Note which EDA artifacts were used in your design by adding them to the Details tab.

[Rev. # or date] – HP Restricted 26

Phased Lifecycle Design Phase

[Rev. # or date] – HP Restricted 27

Phased Lifecycle Design Phase

[Rev. # or date] – HP Restricted 28

Phased Lifecycle Design Phase

[Rev. # or date] – HP Restricted 29 29

Phased Lifecycle Design Phase

[Rev. # or date] – HP Restricted 30

Phased Lifecycle Design Phase

[Rev. # or date] – HP Restricted 31

Phased Lifecycle Design Phase

[Rev. # or date] – HP Restricted 32

Phased Lifecycle Design Phase

[Rev. # or date] – HP Restricted 33

Phased Lifecycle Design Phase

[Rev. # or date] – HP Restricted 34

Phased Lifecycle Design Phase

[Rev. # or date] – HP Restricted 35

 Phased Lifecycle Design Phase

Participant Guide
Status is read-only; its values change based on the chosen value of SubStatus.

Status = Submitted
When it is known that a component (TS) will change in a release, the value of Target Release is assigned and the value of Status
is set to “Submitted” and SubStatus to “New”.

Status = Investigating
The Technical Project Lead assigns a Technical Designer for each FS (PR). While the Technical Designer traces from each FS to
the impacted components (TS leaf nodes), the Status of those TS leaf nodes is “Investigating”. While the specifications are being
authored (changes to the impacted TS leaf nodes), SubStatus is “Designing”. After the specifications are authored and are being
reviewed, SubStatus is changed to “Reviewing”.

Status = Committed
Finally, after the technical specifications have been approved and baselined, then Status is “Committed” and SubStatus is
“Complete”. That signifies they are the Plan of Record.

If a tech spec is to be deferred or rejected, then assign the Status of the impacted artifacts accordingly. Rather than move them to
the Recycle Bin, it’s generally best to retain the artifacts for possible reuse. But the Project Manager can decide whether that is
preferable.

[Rev. # or date] – HP Restricted 36

Phased Lifecycle Design Phase

Participant Guide
a.4

1. For each functional spec, the Technical Project Lead (TL) assigns a Technical Designer (TD).
For that functional spec, the TD will own each corresponding technical spec (TS leaf
nodes).
2. The TD sets the ‘Status’ of each impacted TS to ‘Investigating’, SubStatus to ‘Designing’.
Traces are to TSs for the current release, e.g., “WS1:Tahiti”. That is per Step 3 of “Setting
Up For Design Phase”.
3. Set each TS ‘SubStatus’ to ‘Designing’. Author UML and TS description in whatever order
works best. Needn’t follow this flow.
4. When complete, set each TS ‘SubStatus’ to ‘Reviewing’.
5. For small-to-medium projects, this can be done by inspection with ALM Traceability Matrix.
For larger projects see here.

[Rev. # or date] – HP Restricted 37

Phased Lifecycle Design Phase

u.4

For the Architetcure Review, follow the guidance in the Artifact Library (here) for these
Design Phase artifacts:

• Application Landscape

• Infrastructure Landscape

• Security Landscape

[Rev. # or date] – HP Restricted 38 38

Phased Lifecycle Design Phase

[Rev. # or date] – HP Restricted 39

Phased Lifecycle Design Phase

[Rev. # or date] – HP Restricted 40

Phased Lifecycle Design Phase

Participant Guide
u.5

A “UML Quick Reference Card” is here.

[Rev. # or date] – HP Restricted 41

Phased Lifecycle Design Phase

[Rev. # or date] – HP Restricted 42

Phased Lifecycle Design Phase

[Rev. # or date] – HP Restricted 43

 Phased Lifecycle Design Phase

Participant Guide
a.4 u.5

Is ProVision is a good tool choice and can a business process model be used instead of UML? Here are some
considerations:
• The only modeling integration with ALM is via ProVision business process models (BPM). That integration is
very attractive but…
• BPMs do not capture how a sequence of transaction steps aligns with an actor (a component) the way a
UML Sequence or Activity Diagram does, as in the simple example on a previous slide. That layout shows
what changes to make to which components, which is essential to execute in the next phase.

There are several tool alternatives, notably Visio (with this training) and modeling tools that are part of IDEs. Even
PowerPoint can be used. Bottom line: The thought process that goes into creating the diagrams, tracing to them
from tech specs, reviewing and re-using the diagram is what’s most important.

The referenced Grow@HP course is comprehensive (est. 5 hours) but you can choose just to take a lesson titled
“Creating sequence diagrams in UML”. Review the other UML courses to decide which is best for you and your
team.

[Rev. # or date] – HP Restricted 44

 Phased Lifecycle Design Phase

Participant Guide

To enable ALM  SVN traceability, please see here.

For more details about ALM  SVN traces, please see here.

[Rev. # or date] – HP Restricted 45

Phased Lifecycle Design Phase

[Rev. # or date] – HP Restricted 46

Phased Lifecycle Design Phase

[Rev. # or date] – HP Restricted 47

Phased Lifecycle Design Phase

[Rev. # or date] – HP Restricted 48

Phased Lifecycle Design Phase

Participant Guide

“for the current release”: This is because, while all TSs are traceable, we only trace to
those involved in the current release, i.e., those for which Target Release = “WS1:Tahiti”.
That is how these ‘timeless’ artifacts are updated.

[Rev. # or date] – HP Restricted 49

Phased Lifecycle Design Phase

Participant Guide

“for the current release”: This is because, while all TSs are traceable, we only trace to
those involved in the current release, i.e., those for which Target Release = “WS1:Tahiti”.
That is how these ‘timeless’ artifacts are updated.

[Rev. # or date] – HP Restricted 50

Phased Lifecycle Design Phase

HP Restricted 51
Phased Lifecycle Design Phase

[Rev. # or date] – HP Restricted 52

Phased Lifecycle Design Phase

[Rev. # or date] – HP Restricted 53