Articles

Preparing for SAML Enablement on the Cloud

By Kimberly posted yesterday
Be the first person to like this.
In order to set up SAML, your company must have a  SAML 2.0 compliant  Identity Provider (IdP) and a technical person, often an IT Administrator, who can provide your  Identity Provider’s metadata URL . This person is a key figure to the configuration and must be identified prior to engaging Jama Software as they may need access to Jama Connect for testing purposes. In addition to the above, there are a few caveats you should be aware of when using our SAML implementation.   Please review everything below with your IT Administrator: Jama supports SAML 2.0 compliant Identity Providers (IdPs.) We currently only support SP-initiated (Service Provider ...
0 comments

Jama Software Response to BIRT Report Defect: SOS-DEF-4056

By Chloe posted 7 days ago
Be the first person to like this.
The Issue: BIRT reports with embedded charts/images/tables will fail when attempting to export to Microsoft Word format. While working in Jama, the actions of: Go to Reports > Select (BIRT report with images) > Select Word Format > Run ; will result with the error message of: “ An error occurred while rendering a report ”. Root Cause Analysis (RCA): The root of the problem lies with the images within the BIRT reports. The embedded version of BIRT, which is the SQL reporting engine included in Jama Connect, requires a feature that was deprecated in Java 4 and was not included in the OpenJDK8 delivered with Jama Connect 8.31.2. We ...
0 comments

Pattern: Overview

By Michael posted 11 days ago
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 posted 12 days ago
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 by tooling. ...
0 comments

Pattern: Interfaces

By Michael posted 12 days ago
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 posted 12 days ago
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 posted 12 days ago
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 ...
0 comments

Pattern: Branch and Merge

By Michael posted 12 days ago
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 posted 12 days ago
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 ...
0 comments

Pattern: Functional Descriptions

By Michael posted 12 days ago
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: Review

By Michael posted 12 days ago
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 ...
0 comments

Pattern: Don't Repeat Yourself (DRY)

By Michael posted 12 days ago
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 posted 12 days ago
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 posted 12 days ago
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 posted 12 days ago
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 ...
0 comments

Pattern: Define Hand-Over Points

By Michael posted 12 days ago
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

Pattern: Define and Enforce a Data Model

By Michael posted 13 days ago
Be the first person to like this.
Intent Effective traceability needs a data model. If one is defined and enforced, this will result in a consistent, high-quality product description Also Known as Relationship Model Entity-Relationship-Model (ER-Model) Motivation Understand your development artifacts and their relationships Perform automated consistency checks Applicability Use the pattern when you are doing actual development work. You may omit it during the creative phase (e.g. brainstorming) Structure Define the item types that you anticipate and their relationship. Here is a simple example: And here is another one for agile development: Of course, you need ...
0 comments

Pattern: V-Model (Relationship Model)

By Michael posted 13 days ago
Be the first person to like this.
Intent The V-Model establishes a triangular relationship between requirement, its refinement and a corresponding validation which provides robustness to your development artifacts. Notes Please see the blog article The Myth of the V-Model Don't confuse this pattern with the process model that is called V-Model or V-Model XT, a development standard . Motivation Quality Robustness with respect to change Applicability Use the pattern when you have multiple levels of refinement and you anticipate changes. Structure The central element of the V-Model is the triangular relationship between requirement, it's refinement and a corresponding ...
0 comments

Pattern: Separate Project Structure from Traceability

By Michael posted 13 days ago
Be the first person to like this.
Intent An effective structure for product development has (at least) two dimensions: product structure and traceability structure.. Motivation We tend to organize information in a tree structure. When we were still working with documents, this structure was reflected in the headings. But as we move to fine-grained traceability we have another hierarchy. It is important to not mix the two and to understand their purpose. Applicability Use the pattern when you set up your project. Configure your tool to follow these structures. Structure For example, consider a simple system description with a decomposition into subsystems and tests. Your product ...
0 comments

Pattern: Black Box

By Michael posted 15 days ago
Be the first person to like this.
Intent Describe systems and subsystems so that no knowledge of its implementation is necessary. Also Known as Block (SysML) Class (UML) Component Motivation Limit propagation of changes Allow exchange of implementation technology Support modularization Applicability Use the Black-Box System pattern when: You need to decompose a structure Define clear channels of communication or interaction Structure At a minimum, you need to describe the behavior of interfaces of the subsystem. More complex systems benefit of a clear functional description. If physical elements are involved, you need to describe the relevant physical ...
0 comments