jama
 

Jama Blog: Leverage your collective genius.









Posts Tagged ‘Traceability’

Social Traceability with Derwyn Harris

Wednesday, May 2nd, 2012

Today, the Sticky ToolLook newsletter from Stickyminds.com featured Jama Contour and conducted a short Q&A with Derwyn Harris, co-founder and senior solutions architect at Jama Software. In the interview he discusses “social traceability” in software development.

- – - – - – - – - – - – - – -

Sticky tool look: Would you give us your definition of “social traceability” as it applies to software development?

Derwyn Harris: Social traceability is a new concept with respect to project or product lifecycles regardless of software, hardware, or other. There are two concepts we hear time and time again from customers looking to improve efficiency and success in their process: collaboration and traceability. Collaboration is the ability for teams to effectively review, approve, and make decisions as part of an on-going process, and traceability connects the artifacts of a project, such as business requirements to technical requirements to test or, in an agile world, epics to stories to test. When we at Jama talk about “social traceability,” we are referring to how collaboration is continually occurring around the different artifacts. If the artifacts are connected through traceability, a solution should leverage that connection not only to show what artifacts are impacted but also to show who is impacted along with the conversations.

If I were a BA working on site with a customer and identified a change, I’d turn to Contour to see the impact of that change and whom it impacts. From there, I could better determine and communicate the scope of the change. Without a solution in place, days or weeks may go by before that information was truly understood.

Stl:What are some tools that can improve that traceability, and how do they help?

DH: That’s a great question because it raises an interesting point. Do we even need tools? The answer is absolutely! We’ve learned that what makes teams successful is their ability to communicate effectively around the project artifacts. Not all teams have the luxury of being a five-person team in a single room with a whiteboard. We’re dealing with complex projects and geographically dispersed teams. True traceability is information tied together for all to see, as compared to being managed separate from the live data. Collaboration should also be inherent in the tool and should utilize the traceability to better understand not only what’s impacted but also who.

Stl:How does social traceability impact our communication and productivity?

DH: In the past decade, we have experienced huge change in the social sphere that has altered how we interact and communicate with each other. This evolution in communication has been a bit slower to take hold in business process and project management. The main reason for this is that, with respect to building products or managing projects, it’s more than just collaboration. Projects need clear decisions and a broader view of how information is connected. I guess one why to think about it is that “social,” in and of itself, is very much about the moment, while a project is much more of a living entity that requires constant iterations and the ability to see the whole as well as the focused. Social traceability provides this holistic view across project information, teams, and time to better communicate and thus improve productivity through better efficiency and visibility.

Stl:What are some current traceability challenges, and how do you approach them?

DH: The biggest problem I see is that teams and organizations simply don’t track traceability. Those that do typically use a separate Excel sheet to manage how artifacts are linked, but the effort it takes to ensure this is accurate and up to date is huge, and it’s actual effectiveness is questionable because it lacks visibility.

Traceability is a problem for the entire team and not just a business analyst or project manager. I had someone ask me once on a demo “Who manages the traceability?” My response was that it’s the responsibility of the entire team. Traceability is managed throughout the lifecycle as we move downstream or upstream. Business analysts work on distilling the requirements or stories from a stakeholder’s requests, and QA works on creating test cases based on the upstream artifacts entered by the business analysts. This is why traceability needs to be considered a social solution. It’s about connecting the people together along with what they are working on in a natural flow that doesn’t burden one person but rather makes the entire team work more efficiently.

Derwyn invites you to send him your comments and questions about social traceability.

Best of 2011: The Top Five Whitepapers

Tuesday, January 3rd, 2012

Year-end requirements wrap up: The five best whitepapers of 2011.

We’ve compiled a list of our top resources in 2011, covering topics from understanding Agile planning to the top frustrations in project management (and how to solve them):

  1. Requirements Management 101. Wish someone would explain requirements management in plain English? Have stakeholders that could benefit from understanding the value at a high-level? Your executives might not care about CMMI, BABOK or the nitty gritty details of functional requirements, but they do care about delivering what was promised to customers on time. And, that’s requirements management. To make sure your projects run smoothly, make sure everyone on your team understands the basics.

  2. The State of Requirements Management 2011. Let’s separate the hype from reality. The results of an industry survey shed light on the real trends, challenges and solutions in requirements management and its impact on innovation. Some results might surprise you, others will validate what you’ve been saying for years.

  3. The Top Five Frustrations for Project Managers. See how you can avoid management swoop-in at the eleventh hour, or creating and sending around a dreaded 200-page plan that no one has time to read once, let alone every time a change occurs. We’ve compiled the top 5 frustrations based on what we’ve experienced and seen others endure over the years and include a tip for how to combat each one and put these tips into action.

  4. The Five Challenges to Agile Planning. If you have experience with Waterfall or traditional “phase-gate” developmental processes, then you know why Agile has gained traction so quickly. It’s a nimble, collaborative way to work. But like any professional process, it takes new skills to gain the promised benefits. Learn the five major challenges that we’ve seen lead to Agile failure, as well as advice on how to make Agile work for your entire team.

  5. Big Hairy Projects: An Infographic. Innovation is tough. Today’s economic pressures make innovation more difficult. Fewer teams have access to a plentiful R&D budget, making R&D funds even more valuable. So, how do teams develop ideas and transform them into successful projects? Jama Software sponsored an industry-wide survey, including over 800 project managers, business analysts & developers, to determine the trends in requirements management in 2011. Download the infographic and full report to see see how organizations deliver successful projects.

The 4 fundamentals of requirements management everyone should know… in simple terms.

Thursday, June 16th, 2011

Learn them, share them, live by them. No Ph.D. required.

Wish someone would explain requirements management in plain English? Have stakeholders that could benefit from understanding the value at a high-level? Your executives might not care about CMMI, BABOK or the nitty gritty details of functional requirements, but they do care about delivering what was promised to customers on time. And, that’s requirements management.

Think of requirements management as your ticket to ensure your entire team understands what you’re building and why. The “why” is critical because it provides context to the needs, feedback and decisions being made about the requirements as they evolve during the development process. To make sure your projects run smoothly, make sure everyone on your team understands the basics on:

  • Planning good requirements: “What the heck are we building?”
  • Collaboration and buy-in: “Just approve the scope, already!”
  • Traceability and change management: “Wait, does the dev team know?”
  • Quality assurance: “Hello, did anyone test this thing?”

Download the whitepaper and share it with your team >

For additional whitepapers, please visit our whitepaper page here.

Traceability with Greg Unrein

Wednesday, June 1st, 2011

Today, the Sticky ToolLook newsletter from Stickyminds.com featured Jama Contour 3.1 and conducted a short Q&A with Contour product manager, Greg Unrein, who discusses traceability — managing the important connections between requirements and testing.

- – - – - – - – -

StickyToolLook: Please tell us about the value of clarity in requirements planning.
Greg Unrein: From my perspective, the whole idea behind “requirements” is to create a shared understanding of what you’re creating and why among all the people involved in the project, whether you call these details “requirements,” “stories,” “use cases,” or something else. With that in mind, the value of clarity in requirements becomes obvious. It’s the same as the value of clarity in any other form of expression, from code to prose, graphic design to mathematical proof: A shared understanding becomes much less likely without clarity. Lack of clarity leads to many problems, such as cost and time overruns, incorrect implementations, and low team morale.

More specifically, if a requirement isn’t clear, then there is a good chance that any test cases used to validate that requirement are going to be incorrect.

Clarity can come from strong writing, sketches and more formal diagrams, wireframes, storyboards, and any number of other communication techniques. It’s important to note that clarity does not imply verbosity; in fact, it is usually the reverse. As Pascal wrote, “I made this so long only because I didn’t have the time to make it shorter.”

STL: What other suggestions do you have for getting the most useful test coverage—both at the requirements planning stage and during testing?

GU: Being clear on what is being built and why is critical to success. Another important aspect of success is to understand how all of your requirements and test cases are related to each other so that the impact of changes in one area can be understood and decided upon in an informed way. This is the value of traceability.

My favorite technique, though, is to get people critically reviewing each other’s work. Like code reviews for developers, requirement and test case reviews are essential to achieving high quality. Whether you review in a meeting or online, have your test authors actively involved in reviewing requirements and your requirements authors actively involved in reviewing test cases. This fosters shared understanding and improves the quality of both the requirements and test cases.

STL: When you see issues with traceability between requirements and test cases, where does the disconnect most often occur? How do you repair it, and how do you avoid it next time?

GU: When you’re relating your test cases to requirements, it isn’t hard to identify and fill the gaps left by uncovered requirements, so this is rarely a problem. However, some requirements are more challenging to test than others, and a common disconnect is that while all requirements are covered by test cases, there are some requirements that don’t have adequate coverage. Repairing the immediate problem is simple: Focus more testing on the complex requirements. Avoiding the problem in the future usually comes down to having the test authors involved during requirement creation in order to characterize the testing complexity of each requirement, so that your test coverage analysis can include this dimension.

STL: How do you recommend tackling a change to the requirements after the rest of the process is in motion?

GU: Start with the basics: Figure out which artifacts are impacted by the change, and decide whether you can afford to update those artifacts, leave them out of date, or avoid the change. This is usually called impact analysis.

Beyond the basics, involve stakeholders and the people whose artifacts will be impacted in a review of the proposed change. The group will see the change more holistically and be able to assess the true difficulty involved in making the change. Often, changes that seem daunting in a classic impact analysis are less onerous upon inspection by the people most closely involved in the work. With modern collaboration tools, this doesn’t have to take long or involve a meeting; just get the proposed change in front of this group with a way to discuss the changes, and make any necessary decisions to keep the team bought in and motivated and the project moving forward.

Greg invites you to send him your comments and questions about traceability.


How can we help?

Toll-Free: 1 (800) 679-3058
Direct: (503) 922-1058
Fax: (877) 665-8476

Jama Headquarters
600 NW 14th Ave. Suite 200
Portland, Oregon 97209
support@jamasoftware.com
sales@jamasoftware.com

Connect with Jama online:

           


CONTOUR
Overview
USD Pricing
Euro Pricing
Videos
Screenshots
Features
Why Contour
What's New
Review Center
Integrations
Technology
Download Contour
Free Trial
Request Demo
Login



CUSTOMERS
Overview
Government
Customer List
Success Stories
Testimonials

RESOURCES
News
Webinars
Whitepapers
Blog
Twitter

SUPPORT
Overview
Training
Pro Services
Support Forum
Documentation

COMPANY
About Us
Jama Partners
Management Team
Board & Advisors
Careers
Contact Us
Privacy  |  Legal  |  Preferences  |  Enjoy the Journey