Sunteți pe pagina 1din 12

Six Exercises to Strengthen Traceability

Ta s k 2
k Ta s
1
Ta s k 3

Seapine Traceability Toolkit | Part 2

White Paper

Best Practices for Exploring Traceability and Communication in Product Development


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 quality standards, 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?

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 benefits 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 affected the business. Communicate the benefits of traceability to each department. The benefits may include:

Improved communication Collaboration across departments Specialization between departments Continuous improvement Reduced individual work

Which technology best supports these new best practices?

When you begin to discuss traceability with the key stakeholders in your organization, youll likely find differing ideas about what traceability is and how it affects their jobs. Some groups might even resist improvements to your companys traceability, because they dont understand the benefits of doing so.

Describe specific regulatory and compliance requirements. Assess current traceability. Develop and enforce traceability best practices.

White Paper

Once you determine that traceability is important to the organization, where do you begin the improvements? The first step is to meet with stakeholders to begin identifying, exploring, and capturing traceability best practices. Six Exercises to Help Develop Traceability Best Practices The basics of strong traceability involve knowing what information needs to be traced, capturing that information at different 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 afford 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 different 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 offer 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 with participants 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.

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, such as specific requirements, test cases, development tasks, and issues. Dont pigeonhole yourself into the old ways, such as using flat-file documents. Instead break the artifacts down to core elements that are more manageable. A good example of this is focusing on specific requirements, and not treating the entire requirements document as a single artifact. You can also have specific 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 affected 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, verification 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, firmware 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.

Requirements
Business Requirements User Stories Functional Requirements Design Physical Requirements Electrical Requirements

Testing
Test Cases Test Recor d s Automated T es t s Functional T e s t s Regression T es t s Performan c e T e s t s

2. Explore Terminology and Meaning After completing the previous exercise, you will likely see differences 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 specific 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 different 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 definition of the different types of artifacts. Dont worry about defining every type of artifact, unless there is a specific reason for tracking and relating them differently. (Requirements will likely be the exception to this rule, because each requirement type or artifact will likely have a different meaning.) Once youve agreed to each artifacts name and written all definitions on sticky notes, put the sticky notes at the head of the table or on another board to the side. Youll use these definitions later as remindersor to combine artifacts or add other meaningsin upcoming exercises.

Questions to Ask: Does each artifact name have a different 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 test case 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 or compliance perspective.

Tasks & Issues


Featu re = Reque sts
f eatures are suggestions or recommended by customers, or others. business analysts, They can be cosmetic, in f unctional, or performance to nature. They are routed f ormal f or product development approved f or review and can be a user specif ic projects as story or f ormal requirement.

Deve lopme nt Tasks=


are task s or work items f or software developmen t to code into the sof tware product. They can be cosmetic, f unctional, or perf ormance in nature and may be routed f rom requiremen ts or user stories.

Iss ue s=
are anoma lies, change reques ts, or bugs found w i t h i n the produc t. They can be cosmet ic, functio nal, or perform ance in nature .

Fe a tu re Re q uests Development Tasks Is su es D ef e c t s Anoma lies Work Items

3. Analyze the Impact of Change You now need to determine how change affects 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, you must stop this exercise when you reach 15 minutes. If the exercise cannot be completed in 15 minutes, you may want to finish 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 effect, 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, affecting 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.

Testing
Tes t Case s =
pdat e test Crea te/u refle ct case s to ging ent new/ chanal requ irem func tion ciat ed lag asso Crea te/f s test case ted ely upon Imme diat of new/ upda ent appr oval al requ irem func tion

Tasks & Issues


Feature Requests =
Reco mmended em ents suggestio ns/improv

The steps o f manual, al, automat ed, function regressi o n, and perfo rmance tests. can These test cases . have test variants

T est Cases T est Records Automated Tests F unctional Tests Regression Tests Performance Tests

Feature Request s Development Tas k s Issues Defects Anomalies Work Items

T e s t R ec o r d s =
The results of a test case executio n with a ssociated test varia nts, typically sa ved to a particular build/test run set. Also called test runs o r test executio ns.

Dev elop men t Task s=


Wo rk items f o r develo pers to co de into the so ftwar e/firm ware

Issues =
Anom alies , change requests, o r bugs fo und by either QA tes ting or custom ers

4. Establish Trace Relationships and Handoffs You can now start to define the types of relationships and handoffs 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 only with what is ideal for the company. In other words, dont focus on how you do it today. Instead, consider what is the most effective or ideal way to communicate changes and handoffs. Exercise: (30 minutes) On a sticky note, define 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 notified of the change? (A specific group, manager, assigned person, customer, etc.) What needs to be checked, approved, changed, or created if the related artifact changes or enters a final state? (A simple flag, 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 notification, etc.) When should the changes be communicated? (Immediately, time-based, escalate if no action taken within x days, etc.) This exercise can take more time than youve allocated for this meeting, so try to define one key relationship per group at a minimum. Ideally, tracing two to three relationships per group helps drive home the importance of key handoffs. 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.

Testing
T es t C a s e s T es t Re c o r d s Automated Tests F u n c t i o n a l T es t s Reg r es s i o n T es t s
W ho : QA e should be led Issu d upo n fai W ha t : cretate ord for review tes rec H ow :
ati on of Em ail not ific m fai led fro new iss ue t rec ord tes led ly upo n fai Imm edi ate tes t rec ord
Feature Requests =
Recommende d suggestio ns/impro vements

Tasks & Issue


Deve lopme nt Tasks=
Work items for develope rs to co de into the software /firmwar e

F e a t ur e R eq u D ev e l o p m en t I s s ue s D ef e c t s A n o m a l i es

W he n :

Issues =
Anomalies, change requests, or bugs f ound by either QA testing or customers

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 be challenging. 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 defined earlier as an artifact and verify that nothing was overlooked. Re-read the definitions 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.

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 and velocity 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.

Reports
Tracea bility Report =
Shows the trace relationships of core artifacts from requirements to test recor ds to iss ues.

Traceabil ity Rep ort Open Issues Report Project Status Burn Do wn/Up Ch arts

Show s all open issue and deve lopme nt s tasks for the proje ct, typic ally share d with upper mana geme nt

Ope n Iss Rep ort ues =

Project Status =
Shows overall status of a project/release

Burn Down/Burn Up Charts =


Provides a graphical representation of work left to do versus time in the current iteration/release.

Testing
Test Cases =
Wh o:
Wha t:
QA

A yellow X, to indicate there is not a unanimous decision.

How :

ate test t Creat e/upd to reflec cases hangin g new/c ional requir ement funct iated e/flag assoc Creatcases test upon d Immed iately new/u pdate of

The steps of manual, automated , functional, regression, and performanc e tests. can These test cases have test variants.

Test C ase s Test Rec ord s Automated Tests Funct ion al Tests Regr ession Te sts Performance Tests
7

al Whe n: approvional requirement funct

Tes t Records =
The results of a test case executi on with a ssoci ated t es t v a ri a n t s , t y pi c a ll y saved to a particular b ui ld / te s t r un s et . A l s o c a l l ed t es t r un s o r t es t executi ons.

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 are they 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 forward traceability? Are key activities and notifications 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 efficiency and productivity. A good process will also reduce risk, and identify areas that should be controlled to ensure success.

W h o : QIsA e should be ailed su f d t : ctrestatreecorudpofnor review Wha e How:


ic a t io n o f E m a il n o t if m f a ile d f ro n e w is su e re c o rd t e st ile d ly u p o n f a Im m e d ia t e rd t e st re c o

When:

Whats Next? Now that youve completed all six traceability exercises, how does your current traceability strategy measure up? Does it effectively meet your needs? Check out the whiteboard. How much red do you see? Any red mark can hurt your business from a daily productivity or compliance perspective. Yellow marks could indicate that your teams are not on the same page, which may require a more thorough analysis of that particular area, or additional training. If you have more than a few red Xs, you may want to consider upgrading your traceability tools and strategy. Lets take a look at how to implement the ideal traceability solution for your needs.

Implementing the Ideal Traceability Solution Knowing what problems you face, how they affect your organization, and why it is better to solve those problems than merely putting bandages on them is an important step when identifying your ideal traceability process. Mapping this process and identifying traceability best practices is not usually practical for older systems or technology because of the lack of inherent integration between artifacts. Adapting a business tool to a process instead of adapting a business process to a tool reduces the learning curve. Traceability can also help your companys bottom line. Ideal traceability solutions reduce manual errors that can cost you money if not caught early enoughor not caught at all. You can also reduce timelines by automating core processes, thus contributing to bottom-line profitability.

Requirements
B u s i ne s s R e qu i r em ent s =
T h e pr o du ct s h i g h -l e v e l b u si n es s r eq u i r e me n t s

Testing
Test Cases =
Who:
What :
QA

Tasks & Issues


Feature Requests =
Recomm ended suggesti ons/im provements

Business Requirements User Stories Functional Requirements Design


Engin

How:

pdate test Create/u reflect cases to ging ent new/chanal requirem function d lag associate Create/f test cases ted ely upon Immediat of new/upda ent

The steps of manual, automated, f unctional, regression, and perf ormance tests. can These test cases have test variants.

Test Cases Test Records Automated Tests F unc t i o n a l T e s t s


Who: QA Create issue upon What: failed test record How:
of Email notification failed new issue from test record upon failed

F e a t ur e R eq ue s t s D e v el o p m e nt T a s k s I s s ues D e f e ct s A no m a l i e s Work Items


Who : Create user story d upon approve Wha t: feature request upon tion Email notifica d feature How : approve request Whe n: feature
approved ely upon Immediat request

When : approval al requirem function

User St o ri e s =
A re q ui re m e nt s hi gh - l e ve l d ef i n i t i o n , t y p i ca l l y w ri t t e n b y p r o j ect s t a k eh o l d er

T e s t Re co r d s =
Th e results o f a tes t ca se ex ecution wit h a ssociated test v ariants , typically sa ved to a pa rticula r build/ tes t run s et. Also ca lled test r uns or test ex ecutions.

D ev elopmen t Tasks=
Wo rk item s fo r devel opers to cod e into the so ftwa re/firm ware

When: Immediately test record


F u nc ti o n a l R e qu i r em ent s =
D o c u me n t ed s pe c if i c a t i o n s , u s ua l ly t ra c k e d a s s p e ci f i c, t es t a b l e c o mp o ne n t s

Issues =
Anom alies, change requests, o r bugs f o und by either QA testin g o r custo m ers

A products architect ure, blueprints and circuit diagrams

D esign =

Wh o: Updatechanntnttodesign : requireme ging requ Wh at new/ ireme ication of

g eerin cal refle ct physi

Physical R e qu i r em ent s =
A products physical characteristics, usually hardware

Physical Requirements Electrical Requirements


Who: Communica Update technical reflect to change in functional What: documentation requirement How: When: of updated functional requirement
Email notification updated functional requirement approval Immediately upon

Ho w: flagg diately upon rd reco : Imme test failed Wh en

l notif or Emai desig n chan ged new ed if

R e g r es s i o n T e s t s Performance Tests
Who : Team Wha t: Break down into tasks stories
accepte How : The entire team d after theyve been sized and

Who: Product Manageme nt What: requirement te functional Create/upda How:


new/changin s to reflect requirement g business Email notification business of new flagged ifrequirement or changed

Who: Test Engineer Test records should use What: casethe latest test for testing
specific variants

Produ ct

Owner

When: of Immediately upon approval


tions
new/updated business requirement

When : During iterationa task list

down an breaks stories iteration s user into

How:

Create test records for a build or specific testing cycle

team self-selec planning, work on ts during the tasks to iteration

As defined When: testing planin the

Who: Develocode should use nt Source developme What : the updated coding task for How: approved developme
Email notificatio n upon nt task Immediat ely upon task update

per

Who: QA Issue should Wha t: created be upon failed test record for How: Email notificat review Whe n: Immediately upon
test record ion of new issue from failed test record failed

When: development

Source Control
S o ur c e C o d e =
Project commands and components stored and versioned

Reports
Traceabil ity Report =
Shows the trace relat ionships of co re artif acts fro m requi rem ents to tes t records to is sues.

Source Code CAD Drawing

Who: Engineering Physical requirements should What: use the CAD drawings
for refinement

How:

Email notification of updated physical requirement

T r a c ea b i l i t y Re p o r t O p e n I s s ue s R ep o r t P r o j ec t S t a t us B ur n - D o w n/ U p C h a r t s D a i l y St a t us Re p o r t W o r k i n P r o g r es s R e p or t

Immediately when CAD When: drawing is updated.

CA D D r a w i n g s =
Graphical, detailed images of the product or a component of a physical product

Shows all open iss ues and develop ment tasks for the project , typical ly share upper manage d with ment

Open Issu Repo rt es =

T ec hn i c a l D o c um en t a t i o n =
Adm inis trative, user, and ins talla tion documentatio n fo r the pro duct

Technical Documentation Website Development Firmware Code Word Documents

Project Status =
Shows overall status of a project/release

Burn D own/Burn Up Charts =


Provides a graphical representation of work lef t to do versus time in the current iteration/release.

Integrated Software Solution Providing strong traceability strategies and best practices involves adoption of a comprehensive, integrated, and configurable product development lifecycle solution that matches your business needs, quality standards, and compliance initiatives. Adaptable and Configurable Just like businesses, no two processes are ever the same. Most businesses need solutions that can be easily configured to fit 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: Configurable Security Strong, configurable 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. Configurable Workflow Configurable workflows ensure that your business and compliance rules are enforced and tracked, even if you require electronic signatures or approval processes. Again, the solution should be adaptable enough to meet your business needs/requirements. Configurable Naming and Labeling Configurable naming and labeling helps encourage user adoption of a new solution by allowing users to change the names of development artifacts, requirement types, specific fields, events, and reports that match your business and compliance initiatives. Trying to fit in to canned naming conventions only makes users more resistant to a new solution. Configurable Automation Rules Ensuring the right communication is happening in your organization sometimes requires proactive notifications, like emails or reminders based on escalation rules. Configurable automation rules ensure tasks or specific events are completed on time, based on your business rules.

Effective Content Reuse Item field mapping allows for effective content reuse in an organization, as artifacts transition from requirements to test cases to test executions to issues. Instituting content reuse between artifacts helps prevent 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 flag linked artifacts as suspect. Actionable Traceability Matrix A traceability matrix is a tool that can assist in coverage analysis, 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 identifying gaps in artifact relationships. A traceability matrix may also be 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.

10

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 was required 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 workflow. 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 configured to match your processes and language, then the system should provide transparent traceability to the users. With an automated product 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 confident that specific business and compliance rules are being met by the system. Need Help? Many organizations find it difficult 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 of other groups and ideas.

Seapine Software can assist in these efforts 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, configuration, validation, and training services. 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 configuration 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 specific 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 confidence that critical business and compliance rules are being met.

www.seapine.com
2011 Seapine Software, Inc. All rights reserved.

11
Cincinnati, Ohio I London, England I Melbourne, Australia I Munich, Germany

S-ar putea să vă placă și