Products – P4-Dev Framework V2

System Increment

29. September 201911. May 2020 Oliver Schönfeld

System increments are partial or full integrations of system versions that are verified by internal or external tests, as well as by user and / or market tests.

System increments are often generated at the Cluster level, ie by integrating partial results from the different teams in a cluster.

For the system increment, P4 has adopted the types and definitions of patterns from the Design Thinking Framework. You also use it to define the maturity levels of the samples.

The level of maturity is ultimately defined by the type and number of Knowledge Gaps. Patterns are built to close Knowledge Gaps.

\r\n

Further suitable links:

Events

Roles

Groups

Artifacts

Cluster Planning

Cluster Sync

Cluster Backlog Refinement

Cluster Review

Cluster Retrospective

Cluster Product Owner

Cluster System Engineer

Cluster Scrum Master

Team Product Owner Group

Team System Engineer Group

Team Scrum Master Group

Cluster Management Circle

Cluster Backlog

Usable Knowledge

Cluster DoD

Cluster Improvement Backlog

Integrated System Sample

21. August 201915. April 2020 Oliver Schönfeld

System-Inkremente sind Teil- oder Vollintegrationen von Systemversionen, die durch interne oder externe Tests, sowie (je nach Grad der Regulierung) durch Nutzer- oder sogar Markttests verifiziert werden.

System-Inkremente werden häufig auf Cluster-Ebene erzeugt d.h. durch die Integration von Teilprodukten der verschiedenen Teams eines Clusters.

Für das System-Inkrement hat P4 die Arten und Definitionen von Mustern aus dem Design Thinking Framework übernommen. Sie definieren damit auch die Reifegrade der Muster (Samples).

Der Reifegrad wird letztlich über die Art und Anzahl der Knowledge-Gaps definiert. Um Knowledge Gaps zu schließen werden Muster aufgebaut

Prototype	Name	Description
B	Base Prototype	for design space exploration
C	Critical Function Prototype	Need finding; feasibility; fail early
D	Dark Horse Prototype	The alternative; thinking out of the box
E	Emergent Prototype	Combining several Functions and ideas; iterative and incremental
F	Functional Prototype	Fully functional, but differs in (e.g. form-factor)
G	Gap Closing Prototype	Specific to close Knowledge Gaps or prove Hypotheses
H	Hindmost Prototype	Closest to series production

All Prototype can appear as iterating Prototypes, like G1, G2, G3.

\r\n

Further suitable links:

Internally provided Services

21. August 201916. May 2020 Oliver Schönfeld

Internal services are the result of Service Teams.

Versioned Modules

21. August 201912. May 2020 Oliver Schönfeld

Versioned modules are the results of Module Teams .

Features

21. August 201912. May 2020 Oliver Schönfeld

Integrated and tested features are the results of application teams .

Usable Knowledge & Documented Decisions

21. August 201912. May 2020 Oliver Schönfeld

Usable Knowledge also represents the first stage of reuse (see principles).

At a higher level, however, this also represents knowledge of the possibilities and limitations of integrated system solutions. To achieve this, partially or fully integrated prototypes and structures are usually necessary, the suitability of which can be verified by appropriate tests.

\r\n

Further suitable links:

Applications and Market Variants

11. August 201911. May 2020 Oliver Schönfeld

Applications and market versions are integrated, tested and approved products of the organization that can be sold in target markets to customers. They meet the requirements specified as a group from the Stakeholer Needs in the ” feature sets “. These are individually defined in the System Requirements & Functions as well as the Quality Attributes & Constraints (QA&C) .

\r\n

Further suitable links:

Marketable Systems and Applications

11. August 201914. May 2020 Oliver Schönfeld

Applications and market variants are the organization’s integrated, tested and approved products that can be sold to customers in the target markets. They meet the requirements specified as a group from the Stakeholer Needs in the ” feature sets “. These are individually defined in the System Requirements & Functions as well as the Quality Attributes & Constraints (QA&C) .

Suitable and further articles: