PaR methodical framework

Systematic

Software

Engineering

PaR methodical framework Processes as Requirements The Book

Project

RegulatoryStandards

Requirements

CorporateProcess

Requirements

How-tomanuals

Documents

Templates

SystemRequirements

Team Members

Roles,Expertise,Trainings

Text(generic type)

Needs(Market

Requirements)

ProductRequirements Input/Output

work products

Terms,Abbreviations,

Definitions

PaR – ProcessesasRequirements.info p.9

Contents Preface 13

PaRt I – The Core 15 1 PaRamount .......................................................................................... 17 2 PaRade of Challenges Showing the Needs ............................................ 18

2.1 Projects coached – 5 Challenges identified .................................................... 18 2.2 Challenges accepted - Needs identified ......................................................... 19

2.2.1 Introduction ........................................................................................................ 19 2.2.2 How do you design corporate development processes that are flexible

enough to be a help for all types of your projects? ............................................ 19 2.2.3 How do you merge all needed regulatory standards with the corporate

development processes to make it a holistic approach? .................................... 20 2.2.4 How do you establish sustainable corporate development processes that

can learn together with or from the project teams? .......................................... 20 2.2.5 How do you ensure that your projects continuously comply with corporate

development processes and regulatory standards? ........................................... 21 2.2.6 How do you monitor the actual progress of the project and product

maturity, in addition to monitoring time and budget? ....................................... 22 2.3 Needs accepted – Requirements identified ................................................... 23

3 Getting to PaRis (PaR information system) ........................................... 26 3.1 PaR methodical framework satisfies the requirements ................................. 26 3.2 PaRis detailed ................................................................................................. 31 3.3 PaRis overview ............................................................................................... 33 3.4 PaRis abstract ................................................................................................. 33

PaRt II – PaRty Time 35 4 Principles ............................................................................................. 36

4.1 Cascading “what” and “how” ......................................................................... 36 4.2 When are requirements good (enough)? ....................................................... 38 4.3 Complicate, complex, chaotic ........................................................................ 47 4.4 The art of process design ............................................................................... 49 4.5 Before and after the V-Model ........................................................................ 52 4.6 The process house .......................................................................................... 58

p.10 PaR – ProcessesasRequirements.info

5 Platform Based Families ....................................................................... 60 5.1 Product families with product platforms ....................................................... 60 5.2 UML in PaRis ................................................................................................... 66

5.2.1 Process family requirements .............................................................................. 70 5.2.2 Project requirements .......................................................................................... 72 5.2.3 Product family requirements .............................................................................. 74

5.3 SysML in PaRis ................................................................................................ 75 5.4 Process families with process platforms ........................................................ 77 5.5 The PaRadox of Uniting Process and System ................................................. 80

PaRt III – The Transformation 85 6 PaRadigm Shift .................................................................................... 86

6.1 Rebuilding PaRadise ....................................................................................... 86 6.2 Teamwork, no heroes ..................................................................................... 88 6.3 PaRachute for project planning? .................................................................... 91

7 Reorganize ........................................................................................... 92 7.1 Projects like wildfire ....................................................................................... 92 7.2 SWOT Analysis ................................................................................................ 93 7.3 Cost-Benefit Analysis? .................................................................................... 94 7.4 The dark side of PaR ....................................................................................... 96

PaRt IV – The Tools 101 8 PaRtout – Bringing the Methods into the Tools .................................. 102

8.1 Hands-on ...................................................................................................... 102 8.2 Tool landscape .............................................................................................. 102 8.3 Tool chain along the process abstraction levels ........................................... 104 8.4 Tool features to satisfy the needs of PaR ..................................................... 106

8.4.1 Basic features and advanced features .............................................................. 106 8.4.2 Feature 1: Definition of requirement item types .............................................. 107 8.4.3 Feature 2: Implementation of the PaRis map ................................................... 109 8.4.4 Feature 3: Evaluation of project maturity ......................................................... 112 8.4.5 Feature 4: Compliance checks by standards coverage ..................................... 114 8.4.6 Feature 5: Support for process versions ........................................................... 118 8.4.7 Feature 6: Reuse of requirements sets ............................................................. 120 8.4.8 Feature 7: Synchronization of requirements sets ............................................. 121 8.4.9 Feature 8: Definition and management of variability ....................................... 122

9 PaRameters to Measure Anything ...................................................... 124 9.1 The concept of measurement ...................................................................... 124 9.2 Your PaRallel universe .................................................................................. 126


9.3 Typical KPIs for typical manager questions .................................................. 126 9.3.1 KPI 1: “Are we still on time?” ............................................................................ 126 9.3.2 KPI 2: “Are we on budget?” .............................................................................. 129 9.3.3 KPI 3: “How much is the coverage?” ................................................................. 131 9.3.4 KPI 4: “Are we compliant?” ............................................................................... 132 9.3.5 KPI 5: “What is the maturity?” .......................................................................... 133

10 PaRticular Scenarios and Use-Cases ................................................... 134 10.1 Scenarios and use-cases in the engineering lifecycle ................................... 134 10.2 Process-related scenarios and use-cases ..................................................... 135

10.2.1 Define the regulatory standards ....................................................................... 135 10.2.2 Design the corporate processes for the projects .............................................. 135

10.3 Project-related scenarios and use-cases ...................................................... 136 10.3.1 Configure a project ........................................................................................... 136 10.3.2 Reuse the processes in a project ...................................................................... 136 10.3.3 Work off the process activities ......................................................................... 136 10.3.4 Perform assessments and audits ...................................................................... 137 10.3.5 Reuse united components and activities .......................................................... 137 10.3.6 Improve the process platform from the projects ............................................. 137 10.3.7 Reuse a new process version ............................................................................ 138

PaRt V – Appendixes 141 11 Index ................................................................................................. 142 12 PaR - The Book – as PDF file ............................................................... 156 13 PaRdon – there is more ...................................................................... 157


Preface I started coding software on a Wang micro in school in the late 1970s. Obviously it wasn’t all that bad because my teachers and my father started promoting me. In 1981 I won a competition for young researchers, also because of my systematic approach and my profound documentation.

I started studying in 1983 and stopped after the first semester because I wanted to make more software. I got a paid job as a programmer, learned to lead a core team of older colleagues, established release management, did some refactoring from 8085 to C and C++, and a lot more.

In 1992 I started my own business because I wanted to help others to systematically make software. I created training curricula and finally was a technical lead of what became the largest Microsoft Certified Technical Education Center in Europe, and we made a lot of software also.

After the dot-com crash in 2000 I joined an awesome software startup. We made a lot of software for a huge infrastructure project that was planned for 25 years with a budget of 5bn EUR. I organized our work in an agile manner and we successfully delivered every 2 months for 10 years!

At the same time, I designed and coached processes for systematically and efficiently making automotive software. This became my core activity in the 10s when I designed a process framework for platform-based product engineering with defined reference variability for product variants.

During this work the idea arose to apply a platform process also to process platforms ;-) I finally realized that it is all about requirements. Fortunately, all of my projects ended in 2019. This made it easier for me to focus on that approach and, ironically, a pandemic then helped me.

PaR was a logical consequence of everything I’ve learned and done before!

I started on my own, writing it down, proofing it in tools, publishing it openly to everyone under CC BY-SA 4.0, and founding a community to get support to help as many people, teams, projects and companies as possible to become more agile and efficient – and to have more fun!

Ralf Bürger, in January 2021 (after the 1st year working on PaR and The Book)


2 PaRade of Challenges Showing the Needs

2.1 Projects coached – 5 Challenges identified When a project team claims that following the processes causes extra effort without any help this should be heard and analyzed and changed, but it quickly turns out to become a real challenge. Nowadays we often perform projects or organize departments in an agile fashion to stay focused, to inspect and adapt frequently, and to enable teams to do the right things. We give responsibility to the people doing the work and let them organize themselves.2 Then we may figure out that the teams forget to merge their doing with the standards to ensure corporate sustainability. Motivating teams to apply regulatory standards can be a real challenge after passing the responsibility to them.3 We see innovations spreading faster, new products emerging in variants, windows of opportunities closing quicker, paradigm shifts like “from oil to Tesla”, and even the “first new” pandemic. We have to learn quickly, but the processes to be applied in the projects often are the same as a decade ago, getting more and more heavy-weight and almost frozen like being defined once and forever4. This needs to be challenged and changed. While I am writing this, I am also helping a new project team on a highly innovative product. They have just been audited and assessed by officials how they comply to regulatory standards. It made the key experts feel like kids back in school who actually don’t get it - not good! Better catch people doing something right – and do it often to lead the people.5 The same team has to monitor and report its progress on funny colored standardized presentation slides to managers who don’t know what the project really is about, not to even talk about the projects’ obstacles. Analyzing challenges to figure out the root cause often leads to violation of key values. For the challenges above, the leaders should trust their teams, the teams should respect the corporate responsibility of their leaders, and both should be open minded. And yes, I’m also talking about attitude.

2 Read “Two Types of Authority Leaders Must Give to Self-Organizing Teams” by Mike Cohn

(https://www.mountaingoatsoftware.com/blog/preview/1680) 3 Read “The Dilbert Principle” about ISO 9000 J (Scott Adams) – ISBN 978-0-7522-7220-7 4 Read “The New New Product Development Game” by Takeuchi and Nonaka - Jan.1986

(https://hbr.org/1986/01/the-new-new-product-development-game) 5 Read “The One Minute Manager” (Blanchard, Johnson) – ISBN 0-688-01429-1

❶

❷

❸

❹

❺

◎


Corporate processes shall be defined as requirements, to speak the formal language of the development project teams. Corporate process requirements shall be clustered to sets, to support different sub-processes (e.g. for architectural design). Sets of process requirements shall be reusable in development projects, to pull them for instantiation into the projects’ tools. The development projects shall be in the focus, to emphasize that the company sells products and not process or project documents. The possibility of different types of requirement items in the tools shall be presumed, to support best practical framework application. Variability of process requirements sets shall be considered, to support flexibility, self-organization and tailoring in projects. The sets of corporate process requirements shall be organized as a process platform, to support improvements from projects also. The reused sets of corporate process requirements shall be related to the product requirements, to map “how” and “what” . Reusing corporate processes in the project multiple times shall be possible, to support project iterations and product features. The relation of process and product requirements shall be uniting but flexible, to support single, platform and application projects. Regulatory standards shall be defined as requirements, to be able to merge the corporate processes with the standards. The corporate processes shall be merged with the regulatory standards, to ensure compliance and offer help to the projects. Terms, Abbreviations and Definitions shall be provided and related centrally, to ensure that all people talk the same language. The process requirements shall be related to the standards requirements bi-directionally, to measure coverage up and down. The project teams shall be enabled to pull the corporate process requirements as needed, to support modern (agile) teamwork. The reuse of the process requirements in the projects shall be bi-directional traceable, to enable compliance/deviation measuring. Teambuilding aspects like roles, expertise and trainings shall be considered, to systematically support the people who do the job.

❶ ❶

❶❸❹

❶ ❶❸ ❶❺

❶❸ ❶❷

❶❷❹

❶❸

17.

❷❹

❷

❸❹

❺

❺

❷

❶

1. 2. 3. 4. 5. 6. 7. 8. 9.

10. 11. 12. 13. 14. 15. 16.


SystemRequirements

ProductRequirements

Terms,Abbreviations,Definitions

RESYSRFQ

Samples

Needs(Market

Requirements)

RegulatoryStandards

Requirements

CorporateStandards

Requirements

Projectreuse &tailor may be planned

and executed classical or agilelearn

(sync)

match

ISOIATF

IEEEASPICE

CustomerHow-tomanuals

Teambuilding

Templates

Simple Templatesfor SimpleDocuments

RolesExpertiseTrainingsTeam-Members

from Custom

er to Project

from Product Platform

to Project

from Project to Product Platform

Or W

ithin Product Platform

improve

reuse

3 Getting to PaRis (PaR information system)

3.1 PaR methodical framework satisfies the requirements The diagram in the introducing PaRamount chapter shows the initial idea: Designing Corporate Standards (usually processes) as requirements and pulling them in the development Project by reuse. And ensuring that those corporate processes make a good standard, because they are compliant to the regulatory standards. To ensure this, redesign the Regulatory Standards as requirements in the same tool and relate them to the corporate standards requirements. Together with the Functional & Technical product requirements this makes a holistic, consistent and smart approach. The regulatory standards (as sophisticated documents) and the corporate standards (as processes) are made as good advice of best practices for the projects. So, any implementation should ensure that these standards can get as deep into the projects as possible, also bringing lessons learned back into the standards to improve them. The diagram here is now showing more details, that we also want to relate to the requirements (x.) that we defined for this methodical framework.

20.

11.

2.

12.

1.

19.

13.

9. 16.

4.

17.

8. 10.

7.

3. 14.

15.

6.


4.3 Complicate, complex, chaotic

Something becomes complicate when it gets more aspects or details and becomes more difficult as a result. But it still has a clear structure and defined rules with clear cause and effect relationship. Architecture can help to describe the parts (structure) and their interactions (behavior). A good example is a mechanical watch. It already looks complicated when it only shows hours and minutes. Adding a calendar, moon phases, and alarm makes them even more complicated. But it still works exactly as it was defined for a very long time. Their function is very predictable and can be perfectly described.

It becomes complex when it has too many rules or too many elements with a relation of cause and effect only in retrospect. In a swarm of birds, everyone follows only three rules: keep your speed, distance and direction. Any bird can understand this, but each parameter varies during flight. Due to the high number of elements (birds) it is such a dynamic system that no one can predict what this swarm will look like just a minute later. In fact, the key aspect of complexity is the lack of predictability. Complexity can be reduced by reducing the number of elements or rules.

Imagine the same swarm with just seven birds. They may change positions from time to time, but the swarm will always be in a simple V shape. But even a large swarm of birds will keep the general direction and reach the destination even if it is thousands of kilometers away. It would be impossible to manage this swarm from the outside and tell each bird all

complicate

complex


Making the first product of its kind usually doesn’t scale directly and automatically. Managing the “clone & own” is a good first step towards a platform. That means, if for a new product the archeology finds things in the older versions and variants that can be reused, it is a good idea to track in a change management tool that this has happened. This gives the opportunity to trace bugs back to their source or to generalize things to make reuse become more systematic. These generalized things can be collected centrally as the commonality of all products of the product family that evolves from the first product of its kind. Another good start is to store the basic stuff, that has always been reused “as is”, in a central repository.

This diagram is based on one created by Martin Becker (Fraunhofer IESE) & Danilo Beuche (pure-systems). A basic platform like that will quickly lead to reuse as much as possible in new customer projects or new product variants or versions, only extending it with some specialty or modifying a few components. These additions or

PlatformManaged

Cloning

track

Commonality

Repository

base

generalize

Variability

vary

Product Variant

custom

izeSpecialty

extendSt

rate

gic

Ad-h

oc

Independent Projects Related Projects

Clone & Own

improve

30%

50%

75%

150%

100%


With these action relationships it is now possible to design a UML-style diagram (the left one), based on the detailed PaRis diagram of chapter 3.2 (mapped to the UML diagram on the right side) :

Project

RegulatoryStandards

Requirements

REG

CorporateProcess

Requirements

COP

Terms,Abbreviations,

Definitions

TAD

How-tomanuals

HOW

Documents

Templates

TPL

SystemRequirements

SYS

Team Members

Needs(Market

Requirements)

NED

ProductRequirements

PRO

Roles,Expertise,Trainings

TEB

Input/Outputwork products

WOP

Project

Product Family

satisfysatisfy

satisfy

Domain Requirements

Standards

stipula tory

regulatorystatutory

contracturally

CorporateProcess

derive

organizations

normslaws

customers

derive

REG

derive

COP

...

sub-process

derive

COP

Templates

TPLderive

Documents

TPLsatisfy

reuse

How-to manuals

derive

derive

derive

derive

Terms, Abbreviations,

Definitions

TAD

derive

derive

HOW

derive

Roles, Expertise, Trainings

TEBderive

Team Members

TEB

reuse

reuse

...

...

sub-process

derive

...

reuse

...

Input/Output work products

satisfy

WOP

Needs (Market Requirements)

Product Requirements

System Requirements

Ned

PRO

SYS

satisfy

MDDOM

...DOM

SWDOM

HWDOM

derive

derive

derive

satisfy

derive

reuse

satisfy


Project

Corporate Process

Requirements

Regulatory Standards

Requirements

How-to manuals

Terms, Abbreviations,

Definitions

Teambuilding

Templates

Needs

Product Requirements

System Requirements

①

②

③

④

6.2 Teamwork, no heroes The next diagram shows how the methodical framework PaR can be applied for organizing in teams that really work together. While the teams focus on their objective with high transparency the members can switch from team to team to work in a cross-functional fashion. This also helps to prevent “social loafing”.63

Team 1 may be a single person in a small organization, or even multiple teams joining the ISO/IEEE committees in a large organization. Anyway, Team 1 drills down all the regulatory standards as sets of requirements, which is a lot of detailed work with many reviews, together with assessors and auditors also, always checking the Copyright clauses and licenses of the standards carefully. Team 1 also actively coaches change on the other teams, mainly Team 2.

Team 2 knows the own company inside out and has good connections to stakeholders, to Team 1 as well as to the developers that work in Team 3. Again, it may be a single person in a small organization starting from scratch, or even multiple teams in a large organization that already has large processes up and running, with many templates, forms, tools and how-to manuals. Anyway, Team 2 brings all this into the requirements management tool with all the relations, figuring out the details of the information system (or relationship model), also for the platform approaches.

63 Read “Social Loafing” in “The Art of Thinking Clearly” (Dobelli, Rolf) – ISBN 978-0-0-06-221969-5

①knows all about standards

②knows the company inside out

18.


7 Reorganize

7.1 Projects like wildfire Introducing PaR does not only require people to change, but also organizations. How can this change be motivated at colleagues and higher management levels? We need real arguments and a strategy. If your projects are like wildfire that burns everything, money, time, motivation, just everything, then the standards and processes are certainly not the cause. On the other hand, following and applying them does not automatically save any project, because “no matter how smart you are, you spend much of your day being an idiot”67. Think of standards and processes as reusing base practices and best practices. Follow them and apply them to iterate towards a goal. This may help make project success more likely. And when the going gets tough: “You don’t have enough time in a death march project to do everything the users are asking for. If you build your processes and methods around that sobering fact, you have a chance of succeeding.”68

ü The PaR framework may be the cheapest, simplest and most efficient to systematically implement standards and processes and help projects applying them under all conditions.

ü The PaR framework can be implemented step by step and also partially, so that the business can go on and the risk of giving it a try is low.

ü The PaR framework provides the standards and processes for the projects in a most flexible way to support them in their organization as much as possible, regardless of what else they have to do to withstand business wildfires.

67 Read “The Dilbert Principle” (Scott Adams) and enjoy it J – ISBN 978-0-7522-7220-7 68 Read “Death march: managing ‘mission impossible’ projects” (Edward Yourdon) – ISBN 0-13-014659-5


Helpfulto achieve the objectives

Harmfulto achieve the objectives

Internal

fact

ors

(Project)

External

envi

ronm

ent

(Com

pany)

S Lightweight (just requirements)S Efficient (apply when needed)S Reuse & Tailor (apply as needed

with high flexibility)S Easy to learn and adopt/adaptS Holistic methodical frameworkS Welcomed by developersS Supports self-organized teams

WRequires change in mindWDilutes established sophisticated

process design toolsWDoesn’t make nice process flow

diagramsWEstablishes true transparency

(not wanted by everyone)WWhat shines also has a dark side

O Cheap (uses the RE tool)O Can be implemented step by

step (low risk)O Increases compliance in projects

and processes to standardsO Focuses central competenciesO Advocates platform techniquesO Empowers a learning culture

T Favors Agile over TaylorismT Reduces the big lever of the

central departmentsT Auditors, assessors and Q need

to adapt (getting more flexible)T Process tool vendors don’t like it

PaR

7.2 SWOT Analysis69 I apply the SWOT analysis technique with the objectives of mastering the identified challenges (see chapter 2.1). I do this with a view to the PaR framework from the projects as main users in its environment (the company).

Strengths Weaknesses

characteristics that give it an advantage over others

characteristics of the business that place it at a disadvantage relative to other

Opportunities Threats elements in the environment that it could exploit to its advantage

elements in the environment that could cause trouble

69 see Wikipedia: https://en.wikipedia.org/wiki/SWOT_analysis


8.4 Tool features to satisfy the needs of PaR

8.4.1 Basic features and advanced features Features 1 to 4 deal with the entirety of the standards, processes and projects, by defining all item types, implementing the complete information system, evaluating the overall project maturity and checking compliance with all the standards. Features 5 to 8 bring in the structure, by thinking about versions of parts with dependencies between versions, reusing parts when needed (instead of all upfront), updating standard parts and reused parts in both directions and managing variability to reuse different parts in different variants. Somehow in this list later features depend on earlier ones: Implementing the PaRis requires different item types that can be related to each other. Compliance checks can also be done with relations according to an information system. Systematically synchronizing a change requires definitions of sets of requirements with dedicated versions. Inversely it shows the purposes also: The definition of different item types is needed to define an information system. The information system is needed to check compliance. Definition of requirements sets with versions is needed to synchronize changes systematically.

The following table shows some tools and their capability for PaR (at late 2020). But this is not at all a recommendation or warning and also sometimes depends on the experience with the tool. Some experts of the PaR community can give detailed advice.

Feature Tool 1 2 3 4 5 6 7 8

Jama good good good good fair good good lack Jira with R4J good fair good good pale fair lack lack Polarion good fair fair good lack fair lack lack PTC good pale fair fair pale fair lack lack IBM DOORS 9 pale lack pale pale pale pale lack Lack IBM ELM good good good good good good good good

Basic features 1: Definition of requirement item types

2: Implementation of the PaRis map

3: Evaluation of project maturity

4: Compliance checks by standards coverage

Advanced features 5: Support for process versions

6: Reuse of requirements sets

7: Synchronization of requirements sets

8: Definition and management of variability


However, a metric or instrument is needed to be able to measure data or an object. To value what has been measured and recorded, a ruleset is needed. The result is an index that should be reported according to an index list as an indicator as final result. If necessary, make decisions. Simple Example: “How is your fever doing?” data/object: human being

metric/instrument: thermometer measuring: put it in the mouth value(s) recorded: 38,1°C ruleset: < 37,5°C à “fine” 37,5°C – 37,8°C à “increased” > 37,8°C à “fever” resulting index: “fever” indicator: traffic light index list: “fever” à red “increased” à yellow “fine” à green final result: red traffic light decision: consult doc, take pills, stay in bed Consider simple questions, typically asked by managers “by the way”, like an elevator pitch. Every team member should be able to answer these simple questions with simple answers. This is also important for themselves to stay focused. It is not always simple to find an answer (like in the example above), but the answer itself should be simple. If they ask for details, then give them all the information according to the measurement concept, typically from bottom to top, like a root cause analysis following 5-whys82. Consider “how?” also bringing you into details: “How is your fever doing?” – “Red” (or “bad”) – “Why?” – “It’s real fever, not just increased” – “Why?” – “It’s above 37,8°C” – “How do you know?” – “I put a thermometer in my mouth” – “Why is it so high?” – “The doc says ‘virus’”. Notice: So far there is nothing special about the PaR framework to KPIs!

82 Read “Five whys” on Wikipedia: https://en.wikipedia.org/wiki/Five_whys

Date post:	03-Feb-2022
Category:	Documents
Upload:	others
View:	7 times
Download:	0 times