PHP vs Architektur ATAM Gruppenarbeit
0 gefällt mir1,098 aufrufe
Das Dokument beschreibt mehrere Projekte zur Entwicklung von Softwarelösungen, darunter einen Homepagegenerator mit einem Budget von 1.000.000 Euro, der eine konfigurierbare Benutzeroberfläche bieten soll, und andere Anwendungen wie ein Event-Photogästebuch sowie eine interne Zeitbuchungsapplikation für eine Unternehmensberatung. Jede Projektbeschreibung umfasst Aspekte wie Architektur, Risiken, empfindliche Stellen und Kompromisse, wobei für einige Projekte der Einsatz spezifischer Technologien wie Symfony empfohlen wird. Ziel ist es, die Software an die Bedürfnisse der Benutzer und die Gegebenheiten des Marktes anzupassen.
PHP vs Architektur ATAM Gruppenarbeit
- 1. Beispiel Portalgenerator Business Drivers Es soll mit einem Budget von 1.000.000 Euro ein Homepagegenerator erstellt werden, der das kostenlose Erstellen von Internetauftritten mit CMS, Forum, Blog, Shop, Ebay- Integration etc erlaubt. Die Oberfläche soll durch jeden Nutzer frei konfigurierbar sein. Es wird ein schnelles Wachstum erwartet. Eines der Hauptmarketingargumente ist die Stabilität und Verfügbarkeit der Plattform. Utility Tree (Priorität, Aufwand) Szenariobeschreibung
- 2. Architektur 1 (Beschreibung) Nutzung einer bekannten Of-the-Shelf-Portalsoftware Architektur 1: Risiken (Dinge, die in der Ausfallsicherheit aufwendig zu implementieren. Zukunft Probleme bereiten könnten) Architektur 1: Empfindliche Stellen Änderungen in der Modul-API (Architekturteile, bei denen kleine Änderungen grosse Auswirkungen haben) Architektur 1: Kompromisse Keine Erkennung fehlerhafter Daten. (Kompromisse oder Tradeoff-Points, an denen sich zwei Qualitätsmerkmale gegenseitig beeinflussen) Architektur 2 (Beschreibung) Neuentwicklung auf Basis von Symfony Architektur 2: Risiken (Dinge, die in der Latenz und Skalierbarkeit sind problematisch, automatische Erkennung fehlerhafter Zukunft Probleme bereiten könnten) Daten fehlt. Architektur 2: Empfindliche Stellen Umbau von generierten Modellen auf native-SQL-Queries aufwändig (Architekturteile, bei denen kleine Änderungen grosse Auswirkungen haben) Architektur 2: Kompromisse Die gute Modifizierbarkeit durch Doctrine und eine hohe Durchdringung von impliziten (Kompromisse oder Tradeoff-Points, an Logiken schränkt die Performance ein. denen sich zwei Qualitätsmerkmale gegenseitig beeinflussen) Architekturempfehlung Um hier Spezialanforderungen wie die Erkennung fehlerhafter Daten besser umsetzen zu können wir trotz höherer Aufwände der Einsatz von Symfony empfohlen.
- 3. Beispiel Event-Photogästebuch Business Drivers Bei einem Online-Event mit Webinar soll allen Teilnehmern die Möglichkeit gegeben werden, einen Kommentar mit einem Foto ergänzen zu können. Der Event dauert 2 Tage, das Formular soll danach deaktiviert werden und nur noch die Einträge werden angezeigt. Utility Tree (Priorität, Aufwand) Szenariobeschreibung
- 4. Architektur 1 (Beschreibung) Architektur 1: Risiken (Dinge, die in der Zukunft Probleme bereiten könnten) Architektur 1: Empfindliche Stellen (Architekturteile, bei denen kleine Änderungen grosse Auswirkungen haben) Architektur 1: Kompromisse (Kompromisse oder Tradeoff-Points, an denen sich zwei Qualitätsmerkmale gegenseitig beeinflussen) Architektur 2 (Beschreibung) Architektur 2: Risiken (Dinge, die in der Zukunft Probleme bereiten könnten) Architektur 2: Empfindliche Stellen (Architekturteile, bei denen kleine Änderungen grosse Auswirkungen haben) Architektur 2: Kompromisse (Kompromisse oder Tradeoff-Points, an denen sich zwei Qualitätsmerkmale gegenseitig beeinflussen) Architekturempfehlung
- 5. Beispiel Enterprise-Zeitbuchung Business Drivers Basis für eine interne Zeitbuchungsapplikation für eine Unternehmensberatung mit 2000 Consultants. Die Lebenszeit ist initial mit 8 Jahren geplant. Es soll zu Beginn ein Web- und ein Blackberry-Client implementiert werden, andere Systeme folgen. Utility Tree (Priorität, Aufwand) Szenariobeschreibung
- 6. Architektur 1 (Beschreibung) Architektur 1: Risiken (Dinge, die in der Zukunft Probleme bereiten könnten) Architektur 1: Empfindliche Stellen (Architekturteile, bei denen kleine Änderungen grosse Auswirkungen haben) Architektur 1: Kompromisse (Kompromisse oder Tradeoff-Points, an denen sich zwei Qualitätsmerkmale gegenseitig beeinflussen) Architektur 2 (Beschreibung) Architektur 2: Risiken (Dinge, die in der Zukunft Probleme bereiten könnten) Architektur 2: Empfindliche Stellen (Architekturteile, bei denen kleine Änderungen grosse Auswirkungen haben) Architektur 2: Kompromisse (Kompromisse oder Tradeoff-Points, an denen sich zwei Qualitätsmerkmale gegenseitig beeinflussen) Architekturempfehlung
- 7. Beispiel Startup: The new foursquare Business Drivers Es soll ein deutsches FourSquare entwickelt werden. Die kulturellen Unterschiede im Nutzungsverhalten und die Unterschiede durch die Telekommunikationsproviderinfrastruktur sollen schnell erkannt und adaptiert werden, und so eine „passendere“ Variante von FourSquare für den deutschen Markt geschaffen werden. Utility Tree (Priorität, Aufwand) Szenariobeschreibung
- 8. Architektur 1 (Beschreibung) Architektur 1: Risiken (Dinge, die in der Zukunft Probleme bereiten könnten) Architektur 1: Empfindliche Stellen (Architekturteile, bei denen kleine Änderungen grosse Auswirkungen haben) Architektur 1: Kompromisse (Kompromisse oder Tradeoff-Points, an denen sich zwei Qualitätsmerkmale gegenseitig beeinflussen) Architektur 2 (Beschreibung) Architektur 2: Risiken (Dinge, die in der Zukunft Probleme bereiten könnten) Architektur 2: Empfindliche Stellen (Architekturteile, bei denen kleine Änderungen grosse Auswirkungen haben) Architektur 2: Kompromisse (Kompromisse oder Tradeoff-Points, an denen sich zwei Qualitätsmerkmale gegenseitig beeinflussen) Architekturempfehlung