Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Two shockingly recurring problems

Two shockingly recurring problems

Developing Software architectures is a demanding task that is usually quite rewarding (aka "fun")

## Missing requirements

The whole thing would be even better, if somebody told the development team what exact problem they are supposed to solve.
In other words: Teams urgently need better requirements as the basis of their development work.
In our 20+ years of architecture and development experience, we consistently encountered teams around the world to complain about missing, incomplete or contradicting requirements.
Our brief and fast-paced tutorial summarizes some important and pragmatic approaches that architects and development teams can follow to improve their requirements. It starts with better stakeholder management, more efficient overview, elegant formulation of functional requirements and, last not least, a pragmatic approach to handling quality requirements.

## Technical and other Debt
Which leads to the second recurring issue: The existing systems which most of us regularly work on often carry a load of technical and organizational debt.

In other words: These existing systems are in serious need of improvements, to become maintainable and future-proof.

But how to start? Management does not listen to your pleas and demands more features.
Small refactorings don’t solve the root causes of evil problems.
That’s where systematic architecture improvement comes into play: A pragmatic and simple approach to methodically address all kinds of problems, technical and organizational.

In our workshop, we demonstrate the fundamental techniques and methods for architecture improvement, technology-agnostic and applicable to all kinds of development projects.

Dr. Gernot Starke

November 14, 2022
Tweet

More Decks by Dr. Gernot Starke

Other Decks in Programming

Transcript

  1. Re • cur • ring adjective Happening many times, or

    happening again Foto: Tabitha Turner on unsplash
  2. 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
  3. Requirements-Chaos Instead of „true“ Product Owners: • competing business departments

    • constantly changing priorities • unclear requirements • diffuse Terms
  4. On a scale from 1 (very good) to 5 (very

    bad) how would you rate your requirements?
  5. 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
  6. Clarifying requirements (& constraints) is part of the tasks of

    architects evaluate architecture clarify requirements & constraints design technical concepts shepherd realization communicate architecture design structures
  7. 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
  8. Architecturally Significant Requirements MUST !!! At the beginning only overview,

    then ”Just in Time” details Top 3 – 5 of each Top10
  9. 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
  10. 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
  11. Scope (Defining your „Playground“) Stakeholder Vision /Goals The successful (Project)

    Start Even agile projects need some „upfront“ work Clean Start
  12. 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
  13. 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) – ...
  14. 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
  15. 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
  16. 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
  17. 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!
  18. Functional Requirements are only “one half of the story" Technical

    and organizational Constraints Often forgotten needed qualities ✓
  19. If you don‘t get good enough requirements as development team

    ... ... help yourself! Clarify ASRs (Architecturally Significant Requirements)
  20. #1 Ensure a „clean start“ Never start without knowing •

    your visions/goals • your stakeholders • your scope
  21. ??

  22. The Microscope Trap If you ONLY look into code, you

    will only find problems THERE...
  23. 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
  24. 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
  25. 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 ... <etc.> 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 <u.v.a.m.> 1 2 3 4
  26. 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?
  27. Analyse Code • (manual) Reviews • Collect Metrics • automated

    (e.g. SonarQube) • manual (e.g. performance) • Analyse Code • Dependency checks • Hotspots
  28. Metrics • Coupling / Dependencies • Code complexity • Performance

    • … • Bugs per component • Know-How per component • Change frequency • … good better
  29. 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..
  30. Analyse Technology Base technology: • Hardware • Programming languages •

    Operating systems Frameworks, Libraries 3rd-Party Products • Build-/CI-Server • Database • Middleware • Container-/Hypervisor • <etc> current? adequate? used correctly? sufficient know-how
  31. Analyse Processes Requirements processes • elicit, clarify, manage Development- /design

    processes • Architecture, Implementation, Documentation Operations • Deployment, Rollout, Administration, Monitoring Management • Team- and Taskmanagement, Risk management
  32. 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
  33. 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
  34. 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.
  35. 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
  36. 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
  37. 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