Soziale Strukture in neuen Softwareprojekten

1
Soziale Strukture in neuen Softwareprojekten
Dr. Bernhard Scheffold, (bernhard.scheffold_at_adinf
initum.de) Walter Kriha, (walter_at_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
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 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
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
22
(No Transcript)
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.