Professional Services Articles

How to Submit an Installation or Upgrade Services Request

By Carly Rossi posted 06-21-2022
Be the first person to like this.
When an installation or upgrade service is needed, here is the process to submit a request to the Jama Support team -- Navigate to the Jama Support site , then select ‘SUBMIT A TICKET’ > Installation and Upgrade Services Request. Enter all required fields within the request form, then submit the request. Note: The request must be submitted by the customer directly. The more information provided, the better and expedient the support received will be! The submitting customer will receive an automated response that the ticket has been received, and that it is in process of review and assignment. From that point, the customer should expect ...
0 comments

Jama Connect Interchange™ Administrator Guide

By Decoteau Wilkerson posted 10-12-2021
1 person likes this.
To learn more about Jama Connect Interchange, please contact your Account Manager. Visit our Services Practices Library HERE to access the Jama Connect Interchange User Guide.
0 comments

How To Create A Template Project

By Steve Rush posted 05-04-2020
2 people like this.
Introduction A best practice in administering Jama Connect is to create a Template Project that can be reused/duplicated as necessary. Creating a Template Project has the following benefits: - Standardize methodology A Template Project is a good way to enforce standardization of the requirements management and testing ​processes by using the same data templates and relationship rule configuration. Each team may operate in their own project in Jama which will allow flexibility and customization at the project level for things like a project tree structure, tags, release list, and workflows. - Increase speed for setting up new project teams ...
0 comments

Data Exchange User Guide (3.0)

By Chris Asakawa posted 01-15-2020
1 person likes this.
Version 3.X April, 20 th 2022 Table of Contents About Use Cases Intended Uses Getting Started Quick Start Guide Mapping Generation Import Only Export Only Settings Exchange Via Conversation Attachments About back to top hide/show Organizations utilizing requirements management tools often have the need to exchange large sets of information with other business units or organizations. The associated relationships and other metadata about individual information items must be persisted across different requirements management tools as part of the exchange of data. ReqIF (Requirements Interchange Format) is a standard ...
0 comments

Data Exchange Release Notes

By Eric Rickson posted 01-15-2020
4 people like this.
Data Exchange 3.8.3 Release Date November 11th, 2022 Issues Resolved (EES-EESD-291) - Fixes defect preventing import report generation (EES-EESD-292) - Fixes defect causing blank data in import report (EES-EESD-293) - Fixes defect causing NPE when a Rich Text Attribute is present in the ReqIF file but has no value. (EES-EESD-294) - Add logging of response body when the response cannot be parsed to JSON as expected. This may help some users identify Network Security features intercepting traffic. Data Exchange 3.8.2 Release Date September 9th, 2022 Issues Resolved (EES-EESD-286) - Resolved import issue with XHTML -> Text Field conversion. ...
0 comments

Pattern: Overview

By Michael Jastram posted 03-08-2019
Be the first person to like this.
What are Patterns? Initially developed by architect Christopher Alexander as a ”language to describe common architectural problems and their solutions". Adapted in Software Engineering (Design Patterns) to capture “Elements of Reusable Object Oriented Software”. Ever since, pattern languages have been developed for many fields. Great way for capturing best practices without having to worry about their interplay initially. Sometimes, the term "best practice" is used as well. What are Product Development Patterns? Product development patterns are intended to pragmatically (1) address issues with product development, or (2) apply them for continuous ...
0 comments

Pattern: Define Workflows

By Michael Jastram posted 03-07-2019
Be the first person to like this.
Intent Make it easy and intuitive for stakeholders to follow your processes by supporting them with workflows Also Known As One Motivation Your processes are important, at the same time you want to leave your users enough freedom to be creative and productive. Well-designed workflows are a way to realize this. While the process typically exists on paper, the workflow guides you through your daily activities. Applicability Use the pattern when: You have processes that need to adhered to, e.g. for regulatory reasons Your product description is complex, so you want to add guidance Structure A workflow is typically supported ...
0 comments

Pattern: Interfaces

By Michael Jastram posted 03-07-2019
Be the first person to like this.
Intent Be explicit about identifying and documenting interfaces Motivation As the complexity of products grows, we need robust decomposition (see Black Box ). This in turn requires stability in the interfaces. That's why interfaces need special attention. Having the right interfaces in the right places can make a huge difference in being able to react to changes, robustness and flexibility. Interfaces exist on many levels: It can be about connecting two physical components. It can be about consuming software libraries. It can be about a combination of hardware and software (e.g. a USB connection). It can be about talking to machines or humans. The key ...
0 comments

Pattern: Behavior/Test Driven Development (BDD)

By Michael Jastram posted 03-07-2019
Be the first person to like this.
Intent Look at the accepted product, passed test, etc. first, before thinking about the product descriptions, requirements or design. Also Known as Test-Driven Development (TDD) Behavior-Driven Development (BDD) Acceptance Test-Driven Development (ATDD) Motivation All these "-Driven Development" approaches have one thing in common: You first define what it means to be successful, before defining what it actually is what you want to build. TDD has worked really well in software development, where developers wrote first the test (which would initially fail), to then write the implementation that would make the test pass. A nice side effect was ...
0 comments

Pattern: Consistency Criteria

By Michael Jastram posted 03-07-2019
Be the first person to like this.
Intent Understand the state of your development by establishing and regularly evaluating consistency criteria Also Known as Coverage Invariants Motivation Typically, product development takes place in a dedicated tool that uses an underlying data model. There is a lot of useful information in the model. Make sure that you use it. Coverage is a simple example: If you want to make sure that every stakeholder requirement is tested, then your consistency criteria would be: "every stakeholder requirement has at least one test". Make sure that you don't over-engineer these criteria, and then monitor them. Applicability Always use this pattern when ...
0 comments

Pattern: Branch and Merge

By Michael Jastram posted 03-07-2019
Be the first person to like this.
Intent Avoid copy and paste. Also Known as Reuse Synchronization Motivation Copy and Paste is very easy, but in the long run, we regret it. Branching (and optionally merging) is an alternative that allows you to drastically reduce rework, thereby saving time and improving quality. Branching and merging has been state of the art in software development for 20 years, and it's time that we apply it to product development as well. Applicability Use the pattern: When you have standard content that you want to use in multiple places, and you want to periodically update it in all places You want to allow teams to work independently, but you ...
0 comments

Pattern: Evolve Hardware and Software Together

By Michael Jastram posted 03-07-2019
Be the first person to like this.
Intent As more and more software ends up in products, evolving them together results in superior products Motivation Traditionally, either you first have some hardware and then you write the software – or the other way around. This used to work in the past, where a complex hardware (e.g. hydraulic system) had to be driven by software; or where some software required some hardware extensions (e.g. ticket printing machine). But today, customers expect amazing products where hardware and software are seamlessly integrated. This is only possible if they evolve together. The blog post Why The Demand For System Engineers Is So High also makes a good case for ...
0 comments

Pattern: Functional Descriptions

By Michael Jastram posted 03-07-2019
Be the first person to like this.
Intent Functional thinking allows you decouple your product description from specific technologies. Motivation In order to "future-proof" your product, decouple technology from what your product actually does. For instance, your product may have a display. If you developed it 30 years ago, it probably had a cathode-ray tube, later an LCD display and maybe today an LED display. But the underlying function stayed the same. Applicability This pattern can be applied on many levels, from the stakeholder level ("The vehicle provides transportation"), to the lowest level (control engine torque). Of course, at some point you need to make specific technology ...
0 comments

Pattern: Good Requirements

By Michael Jastram posted 03-07-2019
Be the first person to like this.
Intent Requirements are the foundation in product development. Getting them right can spare you a lot of trouble. Motivation The requirements text is an important building block of product descriptions. Unless they are well-written, we cannot use them as the foundation for our product development Applicability You should always make sure that your requirements have the desired quality. The approach may vary if your requirements are not simple text. Structure There is lots of literature on good requirements. Good textual descriptions are: Atomic Unambiguous No redundancy (in itself and with respect to other items) No contradiction (in itself ...
0 comments

Pattern: Review

By Michael Jastram posted 03-07-2019
Be the first person to like this.
Intent Ensure quality by having more than just one pair of eyes looking at your product description. Motivation Reviews are part of every single functional safety standard, and there is a reason: Reviews improve quality and reduce development risks, especially if done early and often. Applicability Use the pattern at a minimum before you move to a new phase in your development (e.g. Quality Gate ). But most of the time, a review should be done much more often than that. Distinguish between formal and informal reviews. Structure In a review stakeholders are invited to provide feedback on some work items. There are many forms of reviews: An informal ...
0 comments

Pattern: Don't Repeat Yourself (DRY)

By Michael Jastram posted 03-07-2019
Be the first person to like this.
Intent Repetition leads to additional work and to inconsistencies: Avoid it whenever possible! Motivation It's almost embarrassing to mention DRY explicitly, as it is so well-known. Still, as part of the ongoing optimization of your product development, it's important to reflect on this on a regular basis. In particular, we are often forced to repeat ourselves: Our development history is largely a repetition, when we start a similar project, the temptation is there to copy and paste. Implementation A lot has been written about the DRY concept in general. In the context of product development, tools are key for preventing repetition: Use a tool ...
0 comments

Pattern: One-Pager

By Michael Jastram posted 03-07-2019
Be the first person to like this.
Intent Some information is so central that it needs to be very accessible. This pattern is described in detail in The Power of a One-Pager Motivation Some companies put their mission statement in a frame in every conference room. The idea behind this is that this information is so central to everybody's activities that it must be in full view all the time, and consumable in minutes. In product development, there are some pieces of information that are equally important. Making this information as accessible is a simple yet powerful pattern. Applicability Use the pattern when you feel that a significant number of people should have some key information, ...
0 comments

Pattern: Use Meta Data

By Michael Jastram posted 03-07-2019
Be the first person to like this.
Intent Separate the information describing your product from the information supporting the creation of the product description. Also Known as Context-Based Collaboration Motivation When developing a product, you create the product description. But in doing so, you also create a lot of information that is important, but not really part of the product description. By consciously separating the two you can better focus on the task at hand by filtering out what's of no interest. It improves understanding and creates transparency. Consider "rationale". Sometimes, it is useful to record the rationale for a design decision. You may be tempted to just ...
0 comments

Pattern: Engineering Efficiency Empowerment

By Michael Jastram posted 03-07-2019
Be the first person to like this.
Intent Recognize friction points between tools and ease them systematically. The full description of this pattern is documented at → eee-check.de Also Known as Tool Chain Optimization Motivation In theory, the process is first defined, then appropriate methods selected for implementation, and finally the appropriate tools set up. In practice, there are different situations and reasons why this order looks different. Structure A simple four-step process allows you to analyze the status quo an to improve it (see website for details): Step #1: Analysis Step #2: Evaluation of the transitions Step #3: Analysis of bottlenecks Step ...
0 comments

Pattern: Define Hand-Over Points

By Michael Jastram posted 03-07-2019
Be the first person to like this.
Intent Ensure that there is clarity with respect to ownership and responsibilities. Motivation A lot of problems happen when handing over information, no matter whether manually or automatically. By defining hand-over points, you ensure that nobody "drops the ball". This concerns responsibility (e.g. who owns the data when), but also data storage (where is the "master" stored?) Applicability Use the pattern when: You have more than one person work on the same artifacts The same artifact may reside in more than one place Structure A simple way for ensuring responsibility is to assign every work item exactly one owner all the time Ownership ...
0 comments