Six Exercises Strengthen Trace Ability
Transcript of Six Exercises Strengthen Trace Ability
-
8/2/2019 Six Exercises Strengthen Trace Ability
1/12
Six Exercises toStrengthen Traceability
Seapine Traceability Toolkit|Part 2
Task2
Task3
Task
1
-
8/2/2019 Six Exercises Strengthen Trace Ability
2/12
1
White Paper
In Part One of Seapines Traceability Toolkit, Recognizing
the Danger Signs of Weak Traceability, we looked at the
strength of your traceability and shared some symptoms
that might indicate weaknesses in your traceability
processes. In this part, we provide six exercises to help you
strengthen traceability in your product development
lifecycle.
Achieving traceability within a product development
lifecycle helps ensure that changes are shared across teams,
in order to maintain quality and compliance. Traceability
is especially critical for achieving compliance with
ever-stricter government agencies and other qualitystandards, such as the DOD, FAA, FDA, GxP, IEC, and
ISO. Good traceability strategies and best practices help
eliminate unforeseen issues and provide a greater
assurance of quality and communication.
Developing a Traceability Strategy
The purpose of a traceability strategy is to put in place the
processes, tools, and best practices that will help your business
maintain a high level of quality and ensure compliance with
industry regulations. To that end, key stakeholders should
answer the following questions when developing a strong
traceability strategy.
What are our current product development problems?
What compliance requirements must we meet now
and in the near future?
What best practices should we adopt?
Which technology best supports these new best practices?
When you begin to discuss traceability with the key
stakeholders in your organization, youll likely nd dieringideas about what traceability is and how it aects their
jobs. Some groups might even resist improvements to your
companys traceability, because they dont understand the
benets of doing so.
Stakeholders may believe that strengthening traceability
will mean more hours or days lost to building traceability
matrices in Excel. However, once stakeholders understand the
importance and the benets of traceability, it should become
clear that traceability will not impede the current workload,
and stakeholders may be more amenable to adopting the new
strategy, best practices, and software tools.
Often, companies neglect steps and dont include the right
people when formulating a traceability strategy, which can
create animosity between groups and may cause territory
wars. Make sure you survey all groups and include everyone
who will be impacted by the new traceability strategy.
Topics to Consider
The following framework of topics may help you begin to
develop a traceability strategy:
Describe why traceability is important to the business.
Cite examples of how the lack of traceability has
negatively aected the business.
Communicate the benets of traceability to each
department. The benets may include:
Improved communication
Collaboration across departments
Specialization between departments
Continuous improvement
Reduced individual work
Describe specic regulatory and compliance requirements.
Assess current traceability.
Develop and enforce traceability best practices.
Best Practices for Exploring Traceability
and Communication in Product Development
-
8/2/2019 Six Exercises Strengthen Trace Ability
3/12
2
White Paper
Once you determine that traceability is important to the
organization, where do you begin the improvements? The
rst step is to meet with stakeholders to begin identifying,
exploring, and capturing traceability best practices.
Six Exercises to Help Develop Traceability Best PracticesThe basics of strong traceability involve knowin g
what information needs to be traced, capturing that
information at dierent points in the process, and sharing
it across teams, departments, and ultimately the entire
organizationall in a timely manner.
To complete these six exercises, youll need to make the
time, invite the right people, create the right environment,
and take steps in advance to prepare for success.
Make the Time
The time it takes to cover the six areas will vary by organization,
but it could take as little as two hours if properly managed and
structured. Another approach is to break the exercises into
mini-sessions. We have outlined an estimated time for each
key exercise below for better time management.
Many may balk at spending two hours on these exercises. The
problem, however, is that you cant aord to not make time for
a critical issue like traceability.
Another way of looking at it is this: Would you rather waste
hours or even days creating a traceability matrix manually,only to have it fail to prove to auditors you are compliant?
Or would you rather spend two hours to create a strong
traceability strategy that will result in more accurate matrices
and less painful audits?
Invite the Right People
Too many times, management believes they know what
is best for their teams, but a lack of knowledge about
day-to-day activities and processes can impede developing
a best practice.
Consider inviting the following core people:
Product experts from Marketing, R &D ,
and Product Management
Business analysts and project managers from Design
Developers and engineers from Development
Testers and QA managers from Quality Assurance
Product documentation personnel
Key regulatory and compliance personnel
Your business may have dierent titles for the people
you invite, but this list should give you a good idea of the
roles to consider. All participants should be familiar with
product development artifacts and how theyre managed.
Get a Fresh Perspective
Often, people have a bias toward doing things the way theyve
always been done, and this can hinder your attempts to
achieve stronger traceability. It may not even be a visible or
conscious bias; you and your team may think your practices
are best because theyre the only practices to which youve
been exposed.
A neutral third party, such as an outside consultant, can oer
a fresh perspective. Try enlisting the aid of someone who has
engaged in this type of discussion before and knows the best
practices of similar businesses. An outside professional can
help direct the conversation, ensuring that everyones needs
and concerns are addressed in a way that attains the best
results for the business.
Prepare for Success
Once the meeting is scheduled, share this toolkit withparticipants one week prior, so the wheels are already turning
and they know what to expect. Some participants may also
suggest you invite other participants who are more aware of
the process or daily activities.
Before you get started, make sure you have access to the
following resources:
Meeting room with a whiteboard (the larger, the better)
Markers for whiteboard (black, blue, green, red, and yellow)
Sticky notes (the larger, the better)
Pens and paper for each participant
Youre now ready to tackle the traceability best
practices exercises.
-
8/2/2019 Six Exercises Strengthen Trace Ability
4/12
3
1. Identify Key Artifacts
Within any product development lifecycle, there are key
artifacts that should be tracked and managed. A key artifact is
any type of product development item that should be managed
independently for better tracking and accountability, suchas specic requirements, test cases, development tasks, and
issues. Dont pigeonhole yourself into the old ways, such as
using at-le documents. Instead break the artifacts down to
core elements that are more manageable. A good example of
this is focusing on specic requirements, and not treating the
entire requirements document as a single artifact. You can also
have specic product artifacts that are managed collectively,
such as a traceability matrix or other reports.
There are no wrong answers when identifying key artifacts.
Exercise (15 minutes)
Have each participant write down the key artifacts they
manage, and the other artifacts that are aected by changing
each managed artifact. Collect the lists of artifacts and write
them on a white board with a black marker, organizing these
key product artifacts into groups that make sense to your
company, such as:
Design/Requirements
Testing
Issues/Tasks/Feature Requests
Source Control/Other Product Assets
Reports
Again, there are no wrong answers.
Questions to Ask:
What are you going to deliver? (Explicit product
requirements, electrical requirements, functional
requirements, compliance requirements, user stories, etc.)
How are you going to consistently verify the product?
(Functional test, materials test, regression test, load
test, verication test, test cases, etc.)
What types of issues are you going to track? (Change
requests, product defects, program bugs, spelling
mistakes, quality problems, etc.)
What types of customer requests are you going to
track? (Feature, cosmetic, functional, training, etc.)
What types of intellectual product capital require
versioning? (Software source code, rmware code,
technical documentation, standard operating
procedures, etc.)
What types of reports are essential for you and your
team? (Traceability matrices, detailed reports, trend
reports, etc.)
Exploring and identifying these core development artifacts
gives the group a better understanding of all the related
artifacts that are managed in a product development lifecycle.After you have collected and organized your key artifacts on a
whiteboard, you can move on to the next exercise.
Test ing
Test Cases
Requ irements
Bus iness Requ i rements
-
8/2/2019 Six Exercises Strengthen Trace Ability
5/12
4
2. Explore Terminology and Meaning
After completing the previous exercise, you will likely see
dierences in terminology. Before getting started on this
exercise, remind participants that this is a traceability exercise.
Participants should think beyond just the artifact naming,because you may want to separate key artifacts for specic
reporting or tracking needs later.
Exercise (15 minutes)
Get all participants to agree on one naming convention per
artifact, especially if there are legal or compliance reasons for
consistent artifact names.
There may be situations where an agreement is not possible,
in which case these artifact names should be documented
or mapped to each other, even if they are essentially the
same. For example, customers may call something a bug, QA
may call it a defect, Development may call it an issue, and
Engineering may call it an anomaly, but ultimately each group
may be referring the same thing. Map these terms to each
other and move on.
If your artifacts cannot be grouped into one name or have a
dierent process, then assign a name for each artifact.
Establish a simple meaning for each artifact, and write the
meaning on a sticky note. You can even use some of the original
words used by others, so everybody is on the same page.
Write a general denition of the dierent types of artifacts.
Dont worry about dening every type of artifact, unless
there is a specic reason for tracking and relating them
dierently. (Requirements will likely be the exception to this
rule, because each requirement type or artifact will likely
have a dierent meaning.)
Once youve agreed to each artifacts name and written all
denitions on sticky notes, put the sticky notes at the head
of the table or on another board to the side. Youll use these
denitions later as remindersor to combine artifacts or addother meaningsin upcoming exercises.
Questions to Ask:
Does each artifact name have a dierent process? If not,
try to get the team to agree on names for artifacts that
are essentially the same. For example, maybe all types
of tests (manual and automated) require a formal testcase to document or verify completion of the test.
Which artifacts require consistent naming for auditing
or compliance? Identify these artifacts and agree on
a name for each. If a government agency explicitly
defines a specific artifact with a certain name, it is
usually a best practice to call it by the same name
to minimize auditing confusion.
Getting everyone on the same page with artifact
terminology and meaning helps reduce confusion and
eliminates possible negative implications from a legal orcompliance perspective.
Tasks & IssuesFeature Requests
are anoma li es , change
r equests , or bugs found
withi n theproduct.
They canbe cosmetic ,
functional, o r pe rformance
in nature .
I ssues=
are sugg estions orfeatures
recommendedby customers,
busines s analy sts, or others .
They can becosmetic,
functional, or performance in
nature. Th ey are routed to
produ ct development for formal
review and canbe approved for
specific pr oje cts as a us er
story or formal requirement.
Requ ests=Fe
ature
are tasks orwork i tems forsoftware developmentto c ode into thesoftware produc t.Th eycan be cosmetic , functiona l, or performance innature a nd maybe routed fromrequire ments or user storie s.
De ve lopme ntTasks=
-
8/2/2019 Six Exercises Strengthen Trace Ability
6/12
5
3. Analyze the Impact of Change
You now need to determine how change aects other
related artifacts. For example, what is the impact on a test
case when a requirement changes?
Because this is one of the tougher, more sensitive areas to
explore, this exercise is simple.
Exercise (15 minutes)
On the whiteboard, draw blue arrows from each artifact
to the dependent artifacts that would also change if the
original artifact changes.
Do not perform this exercise for reports, because the
whiteboard could become unmanageable.
Note: To complete all six exercises in two hours, youmust stop this exercise when you reach 15 minutes. If the
exercise cannot be completed in 15 minutes, you may want
to nish it in a separate meeting. For now, map out a few
key impacts of change per category.
Questions to Ask:
Which artifacts are directly impacted by change?
Changing one artifact can have a ripple eect, resulting
in other indirect changes, which is quite common in
most product development lifecycles.
Managing change in an organization is not easy and can
have many risk factors. Mapping these potential risks
will give your team a bigger picture of how each change
ripples outward, aecting both upstream and downstream
artifacts. This visual impact analysis can also be used to
help determine if an artifact is worth changing, because it
may cause delays in your product development lifecycle.
Test ing
Test Cases
Tasks & IssuesFeature RequestsThe steps o fmanu al, automated , functi onal , r egre ssion , and
performance tests.
These testcase s can
have test variants .
TestCases=
The results of a te st caseexecution wit h associatedtest va r iants, typical ly
saved to a particu larbuild/test run set. Alsocal l ed test runs or testexecutions.
Te st Recor ds =
Work i tem s for develope rstocode into th esoftware /fi rm ware
DevelopmentTasks=
Anomal ies, change
requests , o r b ugs found
by e ither QA testing orcustomers
Is sues =
Cr t/u
t tt
c t r f
l ct
n /cn in
functi n lr
uirnt
Cr t/fl
ci t
t t c
Ii t ly
u n
r lfn
/u t
functin lr
uirnt
Re commended
su ggestions /improvem ents
Re quest s = Fe ature
-
8/2/2019 Six Exercises Strengthen Trace Ability
7/12
6
4. Establish Trace Relationships and Handos
You can now start to dene the types of relationships and
handos that need to occur if change happens. It is a best
practice to ask the participants to not worry about current
technologies or processes, but to concern themselves onlywith what is ideal for the company. In other words, dont
focus on how you do it today. Instead, consider what is the
most eective or ideal way to communicate changes and
handos.
Exercise: (30 minutes)
On a sticky note, dene the type of relationships that exist
for each blue arrow on the whiteboard. The facilitator
should write the who, what, how, and when on the left
side of each sticky note, then place it on the blue arrow.
Do not perform this exercise for reports.
Questions to Ask:
Who needs to be notied of the change? (A specic
group, manager, assigned person, customer, etc.)
What needs to be checked, approved, changed, orcreated if the related artifact changes or enters a nal
state? (A simple ag, quick review, formal review,
creation of another artifact, etc.)
What other systems need to be updated? (PLM, QMS,
CRM, ERP, SCM, Help Desk, etc.)
How should the changes be communicated? (Flagged,
email, formal notication, etc.)
When should the changes be communicated?
(Immediately, time-based, escalate if no action takenwithin x days, etc.)
This exercise can take more time than youve allocated
for this meeting, so try to dene one key relationship
per group at a minimum. Ideally, tracing two to three
relationships per group helps drive home the importance
of key handos.
Using trace relationships to connect artifacts helps
map out the interdependencies and impact before
change is considered. These relationships are critical
for achieving effective traceability and should be
automated as much as possible.
est ing
Cases
Task Feat
Who:
What:
How:
When:
Issueshouldbe
createduponfaile
d
testrecordforrev
iew
Email notification
of
newissuefromfa
iled
testrecord
Immediately upon
failed
testrecord
QA
Work i temsford eve loperstocode i ntothe software/ firmware
Deve lopmentTa sks=
Anomal i e s, change
requests, o r bugs fou ndby ei ther QA test i ng o r
custome rs
I ssues =
Rec ommend ed
su ggestions /impr ovements
Re qu est s =Feat ure
-
8/2/2019 Six Exercises Strengthen Trace Ability
8/12
7
5. Making Sense of Data
Establishing performance guidelines and tracking metrics
are critical to measuring the success of an organization
and helping to reduce the risk of future issues. However,
getting your team to adhere to these guidelines can bechallenging. Many times, team members dont understand
why a report is needed or dont have the time each day to
record the necessary data.
Exercises: (15 minutes)
Step 1: Review each report you dened earlier as an artifact
and verify that nothing was overlooked. Re-read the
denitions from the second exercise, and assess how easy
it is to get the information required of each report. Mark
each of the sticky notes with one of the following symbols:
A red X, to indicate there are problems getting data.
A green check, to indicate there are no problems
getting data in a timely fashion.
A yellow X, to indicate there is not a unanimous
decision.
Step 2: Remind the team to be honest with this exercise
because you need an accurate representation of the
current state of data. For each artifact, ask the teams who
are most responsible for the daily management of data to
rate how easy it is to pull data together for daily tasks and
how easy it is to analyze data without generating reports.
Mark each sticky note with one of the following:
A red X, to indicate they cannot easily get the data for
daily tasks or they have to generate reports to analyze
data.
A green check, to indicate they can easily get the data
to do their job.
A yellow X, to indicate there is not a unanimous decision.
Questions to Ask:
What type of reports do you need to create? Do you
have all reports listed from an operational,
management, and governmental compliance
perspective? Can you easily determine status andvelocity of your projects? Can we easily pull the
appropriate data to report against?
Can you easily get the data you need to do your job?
From a daily operational perspective, can you easily
view the data you need to make well-informed
decisions? Can you take action with this data?
Can you analyze key data quickly? Are you able to
organize data the way you work or do you have to
create reports to analyze data?
These metrics drive an organizations performance and
establish targets and goals for each department. Using a
system that gathers and presents metrics in a seamless
operational task helps to ensure that good performance
metrics are documented and eliminates the scramble to
document, roll-up, and report metrics. It also provides
good quality metrics to management.
Shows the trace
relation shi ps of core
artif acts fromrequir ements to tes
t
record s to issues .
Traceability
Report=
Showsa llopenissuesand developmenttasksfortheproject, typica llysharedwithupper management
Open IssuesReport=
Sh o ws o ve ra l l status of
a pro j ec t/re le ase
Pro jectStatus =
Pro vi de s a g ra phi ca l
r epr e se nt ati on of wor k
le f t t o do ve r su s t i m e in
the current iteration/re lease.
Bu rn D own /Bu rn
Up Cha rts =
Reports
Traceab i l i ty Report
Test ing
Test CasesThe steps o f m
anual ,
autom at ed, functional ,
regre ssion, and
per formancetest s.
The se t est cas es can
have test variants.
TestCases =
The results of a test caseexecuti on wi th assoc i atedtest vari ants, ty pical ly
saved to a part icular
bui ld/ test run set. Alsocal led test runs or t estex ecuti ons.
Test Reco rds =
Who:
What:
How:
When:
Create/updatetest
casesto reflect
new/changing
functional requirement
Create/flagassociated
testcases
Immediatelyupon
approval ofnew/updated
functional requirement
QA
-
8/2/2019 Six Exercises Strengthen Trace Ability
9/12
8
6. Inventory Current Processes and Tools
Are your methods and practices outdated? Do they
impede daily activities? There are always new tactics
and development methodologies that can give you a
competitive advantage for each product or project, but arethey compliant?
How do you ensure that traceability between artifacts
happens on a daily basis? Thats the question this exercise
aims to resolve.
Exercises: (30 minutes)
Read the sticky notes with the who, what, how, and when
for each trace relationship aloud. Then ask the participants
to decide if they can do everything listed on these sticky
notes with the current process, and if the systems and
software support these ideal processes. Mark each sticky
note with one of the following:
A red X, to indicate the process is broken or the tools
dont support the process.
A green check, to indicate everything on the sticky note
can be accomplished with the current process and tools.
A yellow X, to indicate there is not a unanimous
decision.
Once you identify processes that are successful and ones
that fail, ask the following questions.
Questions to Ask:
For each green check, ask:
Why are these processes successful?
Do they give proactive backward and forwardtraceability?
Are key activities and notications automated?
For each red or yellow X, ask:
Why arent they successful?
Do people not understand the process?
Is there a lack of communication?
Do the tools support your preferred trace relationships?
Is the process still valid or have there been changes in
the organization that make the process obsolete?
Other questions to consider about current systems and
processes:
Will they continue to support current and future
development and project methodologies?
Will they continue to handle our current and future
compliance needs?
Do they help us or get in our way?
Establishing ideal processes will remove some of the burden
of having emergency knee-jerk reactions, audit failures,
and the need to improve eciency and productivity. A
good process will also reduce risk, and identify areas that
should be controlled to ensure success.
Who:
What:
How:
When:
Issueshouldbe
createduponfa
iled
testrecordforrev
iew
Emailnotification
of
newissuefromf
ailed
testrecord
Immediatelyupon
failed
testrecord
QA
-
8/2/2019 Six Exercises Strengthen Trace Ability
10/12
-
8/2/2019 Six Exercises Strengthen Trace Ability
11/12
10
Integrated Software Solution
Providing strong traceability strategies and best practices
involves adoption of a comprehensive, integrated, and
congurable product development lifecycle solution
that matches your business needs, quality standards, andcompliance initiatives.
Adaptable and Congurable
Just like businesses, no two processes are ever the
same. Most businesses need solutions that can be easily
congured to t with internal terminology, project
requirements, business rules, compliance regulations, and
user needs. As your business grows, so will your business
processes. You will need a system that can adapt. When
searching for such a system, keep in mind these key
attributes:
Congurable Security
Strong, congurable security measures are required of
most government and compliance agencies. Even if you
arent required to have security measures for
compliance reasons, some level of security allows you
to be certain that your intellectual property is protected
when working with clients or contractors.
Congurable Workow
Congurable workows ensure that your business and
compliance rules are enforced and tracked, even if yourequire electronic signatures or approval processes.
Again, the solution should be adaptable enough to
meet your business needs/requirements.
Congurable Naming and Labeling
Congurable naming and labeling helps encourage
user adoption of a new solution by allowing users to
change the names of development artifacts,
requirement types, specic elds, events, and reports
that match your business and compliance initiatives.
Trying to t in to canned naming conventions only
makes users more resistant to a new solution.
Congurable Automation Rules
Ensuring the right communication is happening in
your organization sometimes requires proactive
notifications, like emails or reminders based on
escalation rules. Congurable automation rules ensure
tasks or specic events are completed on time, based
on your business rules.
Eective Content Reuse
Item eld mapping allows for eective content
reuse in an organization, as artifacts transition from
requirements to test cases to test executions to issues.
Instituting content reuse between artifacts helpsprevent mistakes and establish a common language
across the organization.
Relationship Linking
Based on your business needs, creating and managing
links between artifacts can be accomplished manually,
suggestively, or automatically. Advanced parent-child
linking, many-to-many linking, and relationship
descriptions help identify the type of relationship that
exists with a link. These linking capabilities ultimately
enable the workings of good traceability practices:
validation matrices, suspect notifications, process
coverage, and forward and backward impact analysis.
Suspect Relationships Change Impact Analysis
When an artifact changes, it can impact other artifacts.
For example, a test case is impacted when a
requirement changes. Flagging or marking artifacts as
suspect can be automated by the system, or the user
can be prompted to ag linked artifacts as suspect.
Actionable Traceability Matrix
A traceability matrix is a tool that can assist in coverageanalysis, which can be represented in many ways, such as:
Requirement to Sub-requirements
Requirements to Test Cases
Test Cases to Test Runs
Test Runs to Issues
Traceability matrices also help in identif ying gaps
in artifact relationships. A traceability matrix may alsobe printed or exported for management or auditing
purposes. One advantage of an integrated product
development lifecycle solution is that the data is never
stale. As changes are made on a daily basis, the matrix
is automatically updated.
-
8/2/2019 Six Exercises Strengthen Trace Ability
12/12
Cincinnati, Ohio I London, England I Melbourne, Australia I Munich, Germany
www.seapine.com
2011 Seapine Software, Inc. All rights reserved.
11
Some life sciences companies have a dedicated
resource who continually updates a spreadsheet that
generates their trace matrix. This spreadsheet is always
being updated, but never in real time. As a result, it
often includes human errors. This type of practice wasrequired before product development lifecycle
solutions arrived on the market.
Impact Analysis
Understanding the impact of a change is essential.
Knowing dependencies before a change is considered
or made provides a logical control over the process
workow. Complete product development lifecycle
solutions can show both forward and backward impact
analyses. These solutions can also generate reports
that provide this same data within a hierarchical view.
Traceability Reporting
All businesses have unique reporting needs to track both
internal and external goals and help ensure that they
are met. By providing strong traceability and objective
evidence reporting, the fear of failing internal or external
audits will be a thing of the past.
Transparency
If all of the above features are congured to match your
processes and language, then the system should provide
transparent traceability to the users. With an automatedproduct development lifecycle solution, you no longer
have to worry about duplications or trying to remember
to email team members about changes. An automated
solution will allow your users to do their daily jobs, analyze
key data, and feel condent that specic business and
compliance rules are being met by the system.
Need Help?
Many organizations nd it dicult to dedicate the time
or resources necessary to develop traceability strategies
and best practices. Some are afraid that one group or
department may take control without the consideration ofother groups and ideas.
Seapine Software can assist in these eorts by exploring
and creating a solution that works for everybody in your
organization. We have an experienced professional services
team that can help with discovery sessions, installation,
data migration, conguration, validation, and trainingservices. Contact your Seapine sales representative to
discuss how we can help improve your traceability strategy.
About Seapine
Seapine Software is a leading provider of
quality-centric Application Lifecycle Management
(ALM) solutions. Seapines software development
tools help organizations of all sizes streamline
communication, improve traceability, achieve
compliance, and deliver quality products. Over
8,500 companies use Seapines award-winning
tools for requirements management, software
change and conguration management, test case
management, issue and defect tracking, load
testing, and automated functional testing.
Seapines TestTrack product suite provides a
complete product development lifecycle solution
that has helped businesses achieve high levels of
compliance in some of the most strictly regulated
industries. TestTrack delivers actionable, real-time
traceability matrices that can be tailored to meet
your specic needs. Youll no longer be burdened
with stale, duplicate, or erroneous data. TestTrack
ensures your data is updated on a daily basis,
keeping your traceability matrix current.
TestTrack allows your team to do its job with the
condence that critical business and compliance
rules are being met.