Skip to main content
Fachgebiete
Automobil + Motoren Bauwesen + Immobilien Business IT + Informatik Elektrotechnik + Elektronik Energie + Nachhaltigkeit Finance + Banking Management + Führung Marketing + Vertrieb Maschinenbau + Werkstoffe Versicherung + Risiko
DE
EN
Bücher
Zeitschriften
Themenseiten
Organisationspsychologie Projektmanagement Marketing Smart Manufacturing
Weitere Formate
Podcasts Webinare Technik Webinare Wirtschaft Kongresse Veranstaltungskalender Awards
Jetzt Einzelzugang starten
Zugang für Unternehmen
Referenzkunden
SLX-Digitalkonferenz: Zukunftswerkstatt 2024

Mehr Umsatz mit Top-Kontakten

Am 7. Mai erfahren Sie, wie Vertriebsteams Leadgenerierung, Leadnurturing und Leadstrategien effizient steuern können.
Erweiterte Suche
Anmelden
nach oben
Erschienen in:
Einführung Kapitel lesen Erstes Kapitel lesen

2022 | OriginalPaper | Buchkapitel

16. Architektur

verfasst von : Gerd Beneken, Felix Hummel, Martin Kucich

Erschienen in: Grundkurs agiles Software-Engineering

Verlag: Springer Fachmedien Wiesbaden

Einloggen

Aktivieren Sie unsere intelligente Suche, um passende Fachinhalte oder Patente zu finden.

search-config
loading …

Auszug

Kann man denn nicht einfach drauflosprogrammieren? Es heißt doch immer, dass sich das Design ,emergent‘ ergeben würde, schließlich kann mal alles durch Refactoring korrigieren? Für einige Systeme mag das zutreffen, da es sich um einfache Prototypen oder um Systeme handelt, die ihr schon sehr oft gebaut habt. Ein eigenständiger Entwurf einer Architektur oder das BDUF (Big Design Up Front) ist dagegen in folgenden Fällen notwendig:
  • Ihr arbeitet in einem großen Team. Die jeweiligen Mitarbeiter und Teilteams müssen unabhängig voneinander arbeiten können, sonst wird der Abstimmungsbedarf zu hoch. Über eine passende Strukturierung der Software und der Quelltexte sowie über sauber definierte Schnittstellen stellt ihr das sicher.
  • Das System ist in irgendeiner Weise mit dem Internet verbunden. Es kann also von außen angegriffen werden. Über die Architektur macht ihr euch klar, an welchen Stellen Angriffe erfolgen können und wie ihr das System dagegen schützen könnt.
  • Eventuell muss das System sehr viele Benutzer parallel verkraften. Hier wird in der Regel Skalierbarkeit gefordert. Auch diese muss über eine passende Architektur sichergestellt werden.
  • Das System ist sicherheitskritisch und eine Norm oder die Anforderungen des Auftraggebers fordern eine umfangreiche Architekturdokumentation.
Das waren erste Argumente, warum ihr euch um die Softwarearchitektur sowie die Architektur des gesamten Systems kümmern müsst. …

Sie haben noch keine Lizenz? Dann Informieren Sie sich jetzt über unsere Produkte:

Springer Professional "Wirtschaft+Technik"

Online-Abonnement

Mit Springer Professional "Wirtschaft+Technik" erhalten Sie Zugriff auf:

  • über 102.000 Bücher
  • über 537 Zeitschriften

aus folgenden Fachgebieten:

  • Automobil + Motoren
  • Bauwesen + Immobilien
  • Business IT + Informatik
  • Elektrotechnik + Elektronik
  • Energie + Nachhaltigkeit
  • Finance + Banking
  • Management + Führung
  • Marketing + Vertrieb
  • Maschinenbau + Werkstoffe
  • Versicherung + Risiko

Jetzt Wissensvorsprung sichern!

Jetzt informieren

Springer Professional "Technik"

Online-Abonnement

Mit Springer Professional "Technik" erhalten Sie Zugriff auf:

  • über 67.000 Bücher
  • über 390 Zeitschriften

aus folgenden Fachgebieten:

  • Automobil + Motoren
  • Bauwesen + Immobilien
  • Business IT + Informatik
  • Elektrotechnik + Elektronik
  • Energie + Nachhaltigkeit
  • Maschinenbau + Werkstoffe




 

Jetzt Wissensvorsprung sichern!

Jetzt informieren

Springer Professional "Wirtschaft"

Online-Abonnement

Mit Springer Professional "Wirtschaft" erhalten Sie Zugriff auf:

  • über 67.000 Bücher
  • über 340 Zeitschriften

aus folgenden Fachgebieten:

  • Bauwesen + Immobilien
  • Business IT + Informatik
  • Finance + Banking
  • Management + Führung
  • Marketing + Vertrieb
  • Versicherung + Risiko




Jetzt Wissensvorsprung sichern!

Jetzt informieren
Vorheriges Kapitel Domänendesign
Nächstes Kapitel Entwickeln
Fußnoten
2
Vgl. Technische und Organisatorische Maßnahmen laut Artikel 32 der DSGVO.
 
4
Befehle wie include, require oder import schaffen Abhängigkeiten.
 
5
Vgl. Kap. 15 zum Domain Driven Design.
 
10
Vgl. Abschn. 15.​2.​6.
 
22
Vgl. dazu das Law of Demeter [Hun99].
 
23
Details siehe Clements et al. [Cle03].
 
24
Gute Dienste leistet beispielsweise draw.io https://​app.​diagrams.​net/​ Wir arbeiten häufig auch mit PlantUML https://​plantuml.​com direkt im GitLab-Wiki.
 
26
Fault-Tree, vgl. DIN EN 61025:2007.
 
27
Failure Mode and Effects Analysis, vgl. DIN EN 60812 Fehlzustandsart- und -auswirkungsana- lyse.
 
28
Zusammenfassende Informationen auch zu den Lizenzauflagen findet ihr bei OpenHub https://​www.​openhub.​net/​ und auch GitHub bietet inzwischen umfangreiche Informationen, um ein Projekt einzuschätzen.
 
Literatur
[App16]
Appelo J (2016) Managing for Happiness: Games, Tools, and Practices to Motivate Any Team. Wiley
[Bas12]
Bass L, Clements P, Kazman R (2012) Software Architecture in Practice. SEI Software Engineering Series, 3. Aufl. Addison-Wesley
[Bas21]
Bass L, Clements P, Kazman R (2021) Software Architecture in Practice. SEI Software Engineering Series, 4. Aufl. Pearson Education
[Bec99]
Beck K (1999) Extreme Programming Explained: Embrace Change. Addison-Wesley
[Bey16]
Beyer B, Jones C, Petoff J, Murphy NR (2016) Site Reliability Engineering: How Google Runs Production Systems. O'Reilly
[Bro21]
Brown S (2021) Visualise, document and explore your software architecture. Software Architecture for Developers – Volume 2. Lean Pub
[Cle02]
Clements P, Kazman R, Klein M (2002) Evaluating Software Architectures, Methods and Case Studies. Addison-Wesley
[Cle03]
Clements P, Bachmann F, Bass L, Garlan D, Ivers J, Little R, Nord R, Stafford J (2003) Documenting Software Architectures: Views and Beyond. Addison-Wesley
[Coc06]
Cockburn A (2006) Agile Software Development: The Cooperative Game, 2. Aufl. Addison-Wesley
[Con68]
Conway ME (1968) How do committees invent? 14(4):28–31 Datamation Magazine
[Den92]
Denert E (1992) Software-Engineering – methodische Projektabwicklung. SpringerMATH
[DeR75]
DeRemer F, Kron H (1975) Programming-in-the-Large versus Programming-in-the-Small. In: Proceedings of the International Conference on Reliable Software, S 114–121MATH
[Eva03]
Evans E (2003) Domain-Driven Design: Tacking Complexity In the Heart of Software. Addison-Wesley
[Foo99]
Foote B, Yoder J (1999) Big Ball of Mud. In: Pattern Languages of Program Design. Addison-Wesley, S 653–692
[For18]
Forsgren N, Humble J, Kim G (2018) Accelerate: The Science of Lean Software and DevOps Building and Scaling High Performing Technology Organizations. IT Revolution Press
[Fow02]
Fowler M (2002) Patterns of Enterprise Application Architecture. Addison-Wesley
[Gam95]
Gamma E, Helm R, Johnson R, Vlissides J (1995) Design Patterns: Elements of Reusable Object-oriented Software. Addison-WesleyMATH
[Gut77]
Guttag J (1977) Abstract Data Types and the Development of Data Structures. Commun ACM 20(6):396–404CrossRefMATH
[Her99]
Herbsleb JD, Grinter RE (1999) Splitting the Organization and Integrating the Code: Conway's Law Revisited. In: Proceedings of the International Conference on Software Engineering. ACM Press, S 85–95
[Hoh03]
Hohpe G, Woolf B (2003) Enterprise Integration Patterns. Addison-Wesley
[Hun99]
Hunt A, Thomas D (1999) The Pragmatic Programmer: From Journeyman to Master. Addison-Wesley
[ISO]
ISO/IEC/IEEE (2011) 42010:2011 Systems and Software engineering – Recomended practice for architectural description of softwareintensive systems. ISO/IEC/IEEE, 12
[ISO05]
ISO/IEC (2005) 25000:2005, Software Engineering – Software Product Quality Requirements and Evaluation (SQuaRE). ISO/IEC
[Jue09]
Juergens E, Deissenboeck F, Hummel B, Wagner S (2009) Do Code Clones Matter? In: Proceedings of the 31st International Conference on Software Engineering, ICSE '09. IEEE Computer Society, S 485–495
[Kle17]
Kleppmann M (2017) Designing Data-Intensive Applications: The Big Ideas Behind Reliable, Scalable, and Maintainable Systems. O'Reilly
[Kru95]
Kruchten P (1995) The 4+1 view model of architecture. IEEE Softw 12(6):42–50CrossRef
[Lar08]
Larman C, Vodde B (2008) Scaling Lean & Agile Development: Thinking and Organizational Tools for Large-Scale Scrum. Addison-Wesley
[New15]
Newman S (2015) Building Microservices. O'Reilly
[Par72]
Parnas DL (1972) On the Criteria to be used in decomposing systems into modules. Commun ACM 15(12):1053–1058CrossRef
[Reu08]
Reussner R, Hasselbring W (Hrsg.) (2008) Handbuch Software-Architektur, 2. Aufl. dpunkt.verlag
[Ric20]
Richards M, Ford N (2020) Fundamentals of Software Architecture: An Engineering Approach. O'Reilly
[Roz05]
Rozanski N, Woods E (2005) Software Systems Architecture. Addison-Wesley
[Sho14]
Shostack A (2014) Threat Modeling: Designing for Security. Wiley
[Sie04]
Siedersleben J (2004) Moderne Softwarearchitektur – umsichtig planen, robust bauen mit Quasar. dpunkt.verlag
[Sta20]
Starke G (2020) Effektive Software-Architekturen: ein praktischer Leitfaden, 9. Aufl. HanserCrossRefMATH
[Tot15]
Toth S (2015) Vorgehensmuster für Softwarearchitektur: Kombinierbare Praktiken in Zeiten von Agile und Lean. Carl HanserCrossRef
[V-M14]
[Win20]
Winters T, Manshreck T, Wright H (2020) Software Engineering at Google: Lessons Learned from Programming Over Time. O'Reilly
Metadaten
Titel
Architektur
verfasst von
Gerd Beneken
Felix Hummel
Martin Kucich
Copyright-Jahr
2022
Buch
Grundkurs agiles Software-Engineering

Print ISBN: 978-3-658-37370-2

Electronic ISBN: 978-3-658-37371-9

Copyright-Jahr: 2022

DOI
https://doi.org/10.1007/978-3-658-37371-9_16