Soziale Strukture in neuen Softwareprojekten

Präsentation zum Thema: "Soziale Strukture in neuen Softwareprojekten"—  Präsentation transkript:

1 Soziale Strukture in neuen Softwareprojekten
Dr. Bernhard Scheffold, Walter Kriha,

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 Explizite, offene Kritik am Alten
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

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 First SW-Architecture Model
Business 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 Base-Model SW-Architecture
Small scale Business Use, Ergonomics, Require- ments, Availability Application Programming Language Application group Technical Interface Social Interface System Resources, Concurrency System System Group

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

13 3-Tier-Model SW-Architecture
Large scale: common services Bus. Bus. Bus. App. App. App. App. builder App. builder App. builder Common business logic common appl. 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 Appl.
principle Appl. Progr. Appl. Progr. Appl.

16 New roles for component models
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

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 Social reasons why new architectures fail
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

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
K T 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

22

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.