Soziale Strukture in neuen Softwareprojekten

1. Soziale Strukture in neuen Softwareprojekten Dr. Bernhard Scheffold, (bernhard.scheffold@adinfinitum.de) Walter Kriha, (walter@kriha.de)

2. Wieso beschäftigen sich Software-Entwickler mit sozialen Strukturen? • Das Leiden am Alten und der Weg zum Neuen • Beobachtungen: Verhalten, Kategoriensysteme, Architektur, Typen • Erklärungsversuche • Verwobenheit sozialer und technischer Strukturen

3. Fragen an gescheiterte Projekte • Was hat die “Neuen” von den “Alten” unterschieden? • Welche Modellbildungen waren unannehmbar? • War der neue Arbeitsstil so anders (basierend auf Kommunikation und gemeinsames Verständnis)? • Wieso fällt es so schwer, von alten Konzepten Abschied zu nehmen? • Wie ist der Zusammenhang zwischen technischen Strukturen und Konzepten und sozialen Strukturen? • Welche Rolle spielt die Arbeitsteilung in der Software-Entwicklung? • Sind Grundprobleme der Software-Entwicklung wie Zuverlässigkeit, Erweiterbarkeit, Wartbarkeit und Qualität letztlich soziale Phänomene? • Wieso scheinen sich bestimmte Probleme in Softwareprojekten immer zu wiederholen?

4. Anerkennung sozialer Faktoren wird “legal” • Design-Pattern-Bewegung • Soziale Tauglichkeit von Programmiersprachen • Firmenorganisation als Framework • Weitere Sichtweise von Software-Architektur: Neue Rollen, Interaktionsmuster, Denkmuster und Kultur der Entwicklung von Software

5. Formen der Kritik am Alten

6. Kosten Mangelnde Flexibilität Fehler, Qualität Schwierige Handhabung Aufwendige Installation und Wartung Nicht mehr zeitgemäss Mangelnde Kapselung macht Änderungen schwierig und gefährlich Keine Reuse der Software Explizite, offene Kritik am Alten

7. Implizite, versteckte Kritik am Alten • Verwalter des alten Systems sind arrogant • Sie wollen keine Veränderungen • Keine benutzerfreundliche Organisation • Gängelung statt Unterstützung • Undurchschaubare, zirkuläre Argumente • Technik dominiert Business

8. Kritik alter Denkmuster - Hilflosigkeit - • Die Auseinandersetzung wird gescheut • Wenn sie stattfindet, ist sie persönlich schmerzhaft und aufreibend • Erfolg (sprich: Aufweichen der Denkmuster) ist minimal • Rückfälle in alte Denkmuster • Einzelne Personen schaffen den Sprung in die neuen Denkbilder • Prinzip Hoffnung und neue Leute.

9. Grundbausteine der Software-Entwicklung als sozialer Prozess Kategorien- system Soziale Gliederung Technische Strukturen

10. Business First SW-Architecture Model Software Use, Ergonomics, Require- ments, Availability Programming Language Programmers A piece of software gets downloaded to special hardware. It contains system and application. No decomposition of software or programming

11. Business Base-Model SW-Architecture Use, Ergonomics, Require- ments, Availability Application Programming Language Application group Small scale Technical Interface Social Interface System Resources, Concurrency System System Group

12. Base-Model SW-Architecture App. App. App. Business Business Business App. group App. group App. group Large scale: application tower Technical Interface Social Interface System System Group

13. 3-Tier-Model SW-Architecture Bus. Bus. Bus. App. App. App. App. builder App. builder App. builder Common business logic common appl. services Large scale: common services Service Builder System System Group

14. Framework Architecture with Components Business User Buys Beans Meta-Information component Component Editor

15. Frameworking Business Business Framework Frameworker Hollywood principle Appl. Progr. Appl. Progr. Appl.

16. Technical roles Business/App. Architect Business Object Architect Component Developer System Object Architect System Architect Business roles Business Project Manager IT Project Manager Component Owner New roles for component models

17. Simple Component Architecture Minimizes social interfaces Free market of human beans Beantool connects beans Beanproducer C Bean A Bean B Beanproducer B Bean C Beanproducer A

18. Old app. Roles/kategories Oriented towards one specific business case, must be done quickly expectation of fixed API to system technical competence for applications is within the app. Programming groups New app. Roles/kategories building generic parts reuse over speed system is changeable, needs arch. Knowledge Role threatened by enabling technology: business users can build the final applications Social reasons why new architectures fail

19. Lifecycle view Develop ment Test/QA Shipping, tayloring Support, Maintenance Progr. QA/QC. Service. Help Desk Reliability, Quality and Extendability show up as problems not in development but in other groups.

20. Waterfall Development view A P P L I K A T I O N Analysis Analyst Money, image, power Design Designer Money, image, power Coding Coder Who takes care of performance, reuse etc.? Who sees the whole? Where is the process view?

21. How Networking becomes “Novell” Network abstractions, protocols, Standards and technology Business Abstract and technical categories Network Specialist at Company X Network product company Usage oriented Interface

23. Some requirements of successful projects • Multi-dimensional decomposition of architecture • Projection of technical and social architecture over time • Make category systems explicit: no single “right” view • Expect multiple and changing category systems. Architecture must support those • Beware of “mapping” approaches. They try to reduce complexity to just one category system and fail in reality • Minimize social interaction using framework technology • Maximize social interaction by separating social interfaces from technical interfaces • Micro level of coding: Make the connection between complexity and abstraction visible and socially understandable.