Slide 1

Slide 1 text

Two Shockingly Recurring Problems Gernot Starke INNOQ Fellow Peter Hruschka Atlantic Systems Guild

Slide 2

Slide 2 text

Re ● cur ● ring adjective Happening many times, or happening again Foto: Tabitha Turner on unsplash

Slide 3

Slide 3 text

Re ● cur ● ring Have you ever made the same dumb mistake twice? Have you ever made the same mistake 100 times? Welcome to the real world! Welcome to software development Tom DeMarco

Slide 4

Slide 4 text

Dr. Peter Hruschka üSystem Engineer üCoach, Trainer ü arc42, req42 ü iSAQB, IREB

Slide 5

Slide 5 text

Dr. Gernot Starke INNOQ Fellow üArchitecture-Improver üCoach, Trainer ü arc42, aim42 ü iSAQB

Slide 6

Slide 6 text

https://ahaslides.com/VVNJI action required

Slide 7

Slide 7 text

Solutions to (some) recurring problems Agenda

Slide 8

Slide 8 text

Bad Requirements. Technical and other Debt. Disclaimer: Of course there are other recurring problems J

Slide 9

Slide 9 text

PROBLEM #1 Good (enough) Requirements?

Slide 10

Slide 10 text

garbage in, garbage out

Slide 11

Slide 11 text

Input Requirements Output Software

Slide 12

Slide 12 text

Input Output

Slide 13

Slide 13 text

Input Output ? Photo by John Cameron on Unsplash

Slide 14

Slide 14 text

Requirements-Chaos Instead of „true“ Product Owners: • competing business departments • constantly changing priorities • unclear requirements • diffuse Terms

Slide 15

Slide 15 text

Who is blamed? Development Teams L Photo by Aimee Vogelsang on Unsplash

Slide 16

Slide 16 text

On a scale from 1 (very good) to 5 (very bad) how would you rate your requirements?

Slide 17

Slide 17 text

Requirements-Responsibility (Business Analysts, Product Owner, Requirements Engineer, …) Stakeholder (Users, Clients, Customers, Security-People, Legal Staff, Data Protection Agencies, …) Development Team (Architects, Developers, Testers, …) Only 2 ways to improve the situation

Slide 18

Slide 18 text

Clarifying requirements (& constraints) is part of the tasks of architects evaluate architecture clarify requirements & constraints design technical concepts shepherd realization communicate architecture design structures

Slide 19

Slide 19 text

Architecturally Significant Requirements Requirements, that (can) have special impact on architecture (decisions). These are much less than 25% evaluate architecture clarify requirements & constraints design technical concepts shepherd realization communicate architecture design structures

Slide 20

Slide 20 text

Product Owner Universe *) *) www.req42.de Management Requirements Development Legend:

Slide 21

Slide 21 text

Architecturally Significant Requirements MUST !!! At the beginning only overview, then ”Just in Time” details Top 3 – 5 of each Top10

Slide 22

Slide 22 text

1 Business Goals 2 Assets 3 Stakeholder 4 Business Scope 5 Product Backlog (Functional Requirements) 6 Domain Terminology 7 Supporting Models 8 Quality Requirements 9 Org. Constraints 10 Roadmaps 11 Risks/Assumptions 12 Teams req42 – The Requirements Framework linearized Form (e.g. for Confluence- Pages) MUST !!! At the beginning only overview, then ”Just in Time” details Top 3 – 5 of each Top10

Slide 23

Slide 23 text

needed (available) Visions/ Goals often implicit Stakeholders often incomplete, not documented Scope not at all or incomplete Functional Requirements Functions & Processes often given, mostly plain text Data often implicit, without glossary Quality Requirements often missing Constraints often known, but not documented

Slide 24

Slide 24 text

Scope (Defining your „Playground“) Stakeholder Vision /Goals The successful (Project) Start Even agile projects need some „upfront“ work Clean Start

Slide 25

Slide 25 text

Visions/Goals The vision describes why the project is being undertaken and what the desired end state is. (Ken Schwaber 2004) You should understand: • How does your product compare to existing product in your company or prodcuts of the competition. What are your „unique selling points“ (USPs) • What is critical for product success? Goals are Requirements that hopefully do not (constantly) change during the planned duration of the project (L) those Vision /Goals

Slide 26

Slide 26 text

Stakeholder Missing Stakeholders = Missing Requirements Photo by Yiran Ding on Unsplash • Persons or organizations that have a direct or indirect influence on the requirements of a system. • All persons or groups that have an interest in the product or the project. • Stakeholders in this context can be more than just customer: – Domain Experts – Subject Matter Experts (SME) – Groups or Organizations (e.g. for standardization) – ...

Slide 27

Slide 27 text

SCOPE = YOUR PLAYGROUND CONTEXT = NOT YOUR PLAYGROUND

Slide 28

Slide 28 text

GPS System position Example: Traffic Pursuit Unit

Slide 29

Slide 29 text

The minimum prerequisite for a clean start Know Your goals Your stakeholders Your scope

Slide 30

Slide 30 text

You will find requirements of different granularity § coarse grained § ..... § fine grained ... and stakeholder will constantly speak on these different levels Functional Requirements The final truth is in the implemented systems (i.e. its software and hardware Features User Stories Epics

Slide 31

Slide 31 text

Epics Features User Storys Refinement “just in time”, driven by needs.. The Product Backlog is a living repository, never finished You have to create a tree-like structure for your functional requirements

Slide 32

Slide 32 text

The T-Model Concentrate on overview (Epics, Features) Delay details (user stories) until needed for implementation Enough overview Details only for the next iteration Degree of details Product Scope Requirements Architecture/Design Coding/Unit Testing Integration/Acceptance Testing

Slide 33

Slide 33 text

You should at least agree on your 10 – 15 most important terms of your domain! Trend: Epics, Features, Stories using natural language, but … …everything that improves communication (Use-Cases, Activity Diagrams, EPKs, Data Models, Wireframes, …) is good practice!

Slide 34

Slide 34 text

Functional Requirements are only “one half of the story" Technical and organizational Constraints Often forgotten needed qualities ✓

Slide 35

Slide 35 text

If you don‘t get good enough requirements as development team ... ... help yourself! Clarify ASRs (Architecturally Significant Requirements)

Slide 36

Slide 36 text

#1 Ensure a „clean start“ Never start without knowing • your visions/goals • your stakeholders • your scope

Slide 37

Slide 37 text

#2 Get an overview of functional requirements to allow for planning and risk management

Slide 38

Slide 38 text

#3 Clarify Quality Requirements and Constraints You will need them for making your architecture decisions

Slide 39

Slide 39 text

PROBLEM #2 Legacy

Slide 40

Slide 40 text

system that is hard to maintain suffers from technical / organizational debt Legacy...

Slide 41

Slide 41 text

3 https://www.flickr.com/photos/celestinechua/9661913835

Slide 42

Slide 42 text

??

Slide 43

Slide 43 text

Action required

Slide 44

Slide 44 text

Cannabidiol 100mg/day treatment of neurological disorders: anxiety, chronic pain, epilepsy etc.

Slide 45

Slide 45 text

Therefore: start by getting an overview avoid technology-/solution-driven actionism

Slide 46

Slide 46 text

Systematic Improvement https://aim42.org

Slide 47

Slide 47 text

Some Details

Slide 48

Slide 48 text

Software Reviews ???

Slide 49

Slide 49 text

https://www.flickr.com/photos/jonasb/24341 322

Slide 50

Slide 50 text

https://www.flickr.com/photos/emiliano- iko/5354414276

Slide 51

Slide 51 text

The Microscope Trap If you ONLY look into code, you will only find problems THERE...

Slide 52

Slide 52 text

No content

Slide 53

Slide 53 text

One man's problem is another man's friend The Relativity Trap

Slide 54

Slide 54 text

expect strange reactions...

Slide 55

Slide 55 text

Analyze: Find Issues analyze e valuate improve https://aim42.org

Slide 56

Slide 56 text

Iteration 2 Analyze: Getting Overview Iteration 1 Breadth-first search Stakeholder Code Context Quality Data Processes

Slide 57

Slide 57 text

VENOM Data Warehouse (Business Intelligence) Buchhaltung, Lohn/Gehalt DATEV Support (Call Center) Buchhaltung Sage etc. Personal- wirtschaft Partner- management Lieferanten- management EMail + Kalender Sharepoint + Wiki CITRIX Facilities Contracts LDAP / SSO Context analysis / Scoping Clarify scope and external interfaces

Slide 58

Slide 58 text

https://ahaslides.com/VVNJI action required

Slide 59

Slide 59 text

Analyze: Quality... Breadth-first search • Are quality requirements met? • Performance • Robustness • Security/Safety • etc... • Method: ATAM Software Product Quality Functional Suitability Reliability Performance efficiency Operability Security Compatibility Maintain- ability Transfer- ability Appropriate- ness Accuracy Compliance Availability Fault tolerance Recover- ability Compliance Time- behaviour Resource- utilisation Compliance Appropriate- ness Recognise- ability Learnability Ease-of-use Helpfulness Attractiveness Technical accessibility Compliance Confidential- ity Integrity Non- repudiation Account- ability Authenticity Compliance Replace- ability Co- existence Inter- operability Compliance Modularity Reusability Analyzability Changeability Modification stability Testability Compliance Portability Adaptability Installability Compliance Stakehold er Code Contex t Quality Data Processes

Slide 60

Slide 60 text

Analyze Quality... Software Product Quality Functional Suitability Reliability Performance efficiency Operability Security Compatibility Maintain- ability Transfer- ability Appropriate- ness Accuracy Compliance Availability Fault tolerance Recover- ability Compliance Time- behaviour Resource- utilisation Compliance Appropriate- ness Recognise- ability Learnability Ease-of-use Helpfulness Attractiveness Technical accessibility Compliance Confidential- ity Integrity Non- repudiation Account- ability Authenticity Compliance Replace- ability Co- existence Inter- operability Compliance Modularity Reusability Analyzability Changeability Modification stability Testability Compliance Portability Adaptability Installability Compliance Pri o Category Szenario 1 Performance Configurator displays potential add-on-parts + services < 5 sec 1 Operability Configuration (private customers) works on iOS & Android 2 Performance Binding offer price displayed < 10 sec 2 Changeabilit y New product category live < 30d ... Approaches in Architecture / System storage of add-on parts in DB (no caching) multiple data sources for add- on and service-data Add-ons by wrong data in optical archive Configurator developed in Flash Binding offer price depends on client history, requires access to optical archive 1 2 3 4

Slide 61

Slide 61 text

Analyse application data 1. Structure 2. Types 3. Access • Read / write 4. Volume • Query-results + indices 5. Correctness 6. Security requirements 7. Distribution / decentralization 8. Duplication / redundancy 9. Throughput -> Runtime analysis Structure and types suitable for the problem read oder write optimization? Overly many of sth? Sth overly large? Wrong/incorrect data? sensitive data? duplicate data items? duplicate data items?

Slide 62

Slide 62 text

Analyse Component Structure

Slide 63

Slide 63 text

https://ahaslides.com/VVNJI action required

Slide 64

Slide 64 text

Analyse Code • (manual) Reviews • Collect Metrics • automated (e.g. SonarQube) • manual (e.g. performance) • Analyse Code • Dependency checks • Hotspots

Slide 65

Slide 65 text

Metrics • Coupling / Dependencies • Code complexity • Performance • … good

Slide 66

Slide 66 text

Metrics • Coupling / Dependencies • Code complexity • Performance • … • Bugs per component • Know-How per component • Change frequency • … good better

Slide 67

Slide 67 text

complex code, that‘s frequently modified. Consider Hotspots

Slide 68

Slide 68 text

complex code, that‘s frequently modified. try for yourself... https://codescene.io/projects/1737/jobs/4353/results/code/hotspots/system-map https://bit.ly/hotspot-sample Hotspot analysis of Linux kernel...

Slide 69

Slide 69 text

https://ahaslides.com/VVNJI action required

Slide 70

Slide 70 text

Analyse Tests • Adequate tests available: • automated... • Unit-, integrationstests • acceptance tests • Others ... • Load tests • Penetration tests • Test infrastructure • Test data Important prerequisite for (low-risk) modification..

Slide 71

Slide 71 text

Analyse Technology Base technology: • Hardware • Programming languages • Operating systems Frameworks, Libraries 3rd-Party Products • Build-/CI-Server • Database • Middleware • Container-/Hypervisor • current? adequate? used correctly? sufficient know-how

Slide 72

Slide 72 text

Analyse Processes Requirements processes • elicit, clarify, manage Development- /design processes • Architecture, Implementation, Documentation Operations • Deployment, Rollout, Administration, Monitoring Management • Team- and Taskmanagement, Risk management

Slide 73

Slide 73 text

https://ahaslides.com/VVNJI action required

Slide 74

Slide 74 text

now you have.. (large) collection of explicitly known problems Prob. 1 Prob. 1 Prob. 1 Prob. 1 Prob. 1 Prob. 10 Prob. 1 Prob. 1 Prob. 42

Slide 75

Slide 75 text

Evaluate: Prioritize Issues analyze improve e valuate https://aim42.org

Slide 76

Slide 76 text

minor Evaluate – Prioritize What problem is (currently) the worst: costing or hindering the most real minor really serious, dangerous, > 10.000 $ serious, > 1000 $ annoying, hindering a little, >> 100 $ trivial, ok to have, < 100 $ minor minor real real serious real extreme very bad

Slide 77

Slide 77 text

Improve: Resolve Issues e valuate analyze improve https://aim42.org

Slide 78

Slide 78 text

Improvement and Daily Business day-to-day development Practices Practices time Approaches Practices Practices Practices Practices

Slide 79

Slide 79 text

Strategic Improvement Approaches... Build new system Migrate old data to new formats, rewrite corresponding code Make it smaller Partly rework system re-distribute responsibilities in code Separate domain from technology «category» Long-Term Improvement Approach «category» Rewrite «category» Restructure «category» Data Migration «category» Brainsize «category» Improve Modularization «category» Supporting Patterns Supportie improvements, e.g. in operations, test, development.

Slide 80

Slide 80 text

Change by Extraction 2 1 Client Flawed (incohesive) System Client „other“ other features Client Flawed System Client „other“ other features Better other features Client (reduced) Flawed System Client „other“ «category» Restructure «category» Downsize

Slide 81

Slide 81 text

No content

Slide 82

Slide 82 text

Decorating Collaborator Client Code Flawed Supplier «use» Client Code Flawed Supplier „Proxy“ «use» «delegate» 1. 2. New functionality Client Code Flawed Supplier „Proxy“ «use» «delegate» «decoration» 1. 2. 3. 1 2

Slide 83

Slide 83 text

Get your POs trained -> IREB Get yourself trained in requirements –> ISAQB REQ4ARC Establish a culture of IMPROVEMENT Problems can be solved, but need actions Foto: brett-Jordan on unsplash

Slide 84

Slide 84 text

THANX. Gernot Starke [email protected] Twitter: @gernotstarke Peter Hruschka [email protected]