Transcript Soziale Strukture in neuen Softwareprojekten Dr. Bernhard Scheffold, ([email protected]) Walter Kriha, ([email protected]) • Wieso beschäftigen sich SoftwareEntwickler mit sozialen Strukturen? • Das Leiden am Alten und.

Soziale Strukture in neuen
Softwareprojekten
Dr. Bernhard Scheffold,
([email protected])
Walter Kriha,
([email protected])
• Wieso beschäftigen sich SoftwareEntwickler mit sozialen Strukturen?
• Das Leiden am Alten und der Weg zum
Neuen
• Beobachtungen: Verhalten,
Kategoriensysteme, Architektur, Typen
• Erklärungsversuche
• Verwobenheit sozialer und technischer
Strukturen
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?
Anerkennung sozialer Faktoren
wird “legal”
• Design-Pattern-Bewegung
• Soziale Tauglichkeit von
Programmiersprachen
• Firmenorganisation als Framework
• Weitere Sichtweise von SoftwareArchitektur: Neue Rollen,
Interaktionsmuster, Denkmuster und Kultur
der Entwicklung von Software
Formen der Kritik am Alten
Business Technik
Sozial
Offen
Implizit oder kaum
gar nicht
Kaum
Kein Wissen,
UrsachenLeiden
forschung
Offen
Im Detail Im Detail,
aber oft
nicht über
den Lebenszyklus
Denkmuster
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
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
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.
Grundbausteine der SoftwareEntwicklung als sozialer Prozess
Kategoriensystem
Soziale Gliederung
Technische
Strukturen
First SW-Architecture Model
Use,
Ergonomics,
Software
Business
Requirements,
Availability
Programming
Language
Programmers
A piece of software gets downloaded to special hardware. It
contains system and application. No decomposition of software
or programming
Base-Model SW-Architecture
Small scale
Use,
Ergonomics,
Application
Technical
Interface
System
Requirements,
Availability
Programming
Language
Business
Application group
Social
Interface
System
Resources,
Concurrency
System Group
Base-Model SW-Architecture
Large scale: application tower
App.
App.
System
Business
Business
Business
App.
group
App.
group
App.
group
App.
Technical
Social
Interface
Interface
System Group
3-Tier-Model SW-Architecture
Large scale: common services
App.
App.
Bus.
Bus.
Bus.
App.
builder
App.
builder
App.
builder
App.
Common business logic
common appl. services
Service Builder
System
System Group
Framework Architecture with
Business
Components
User
Meta-Information component
Buys
Beans
Component
Editor
Frameworking
Business
Business
Framework
Frameworker
Hollywood
principle
Appl.
Appl.
Progr.
Appl.
Progr.
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
Simple Component Architecture
Minimizes social interfaces
Beantool
connects beans
Bean
A
Free market of human beans
Bean
B
Beanproducer C
Beanproducer B
Bean
C
Beanproducer A
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
Lifecycle view
Develop
ment
Progr.
Test/QA
QA/QC.
Shipping,
tayloring
Support,
Maintenance
Service.
Help
Desk
Reliability, Quality and Extendability show up as problems not in
development but in other groups.
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?
How Networking becomes
“Novell”
Network abstractions, protocols,
Standards and technology
Business
Abstract and
technical
categories
Network product
company
Usage
oriented
Interface
Network
Specialist
at Company
X
Requirements: put weights on
all the structures
An al yti c Stru ctu re
Development
Resources
User / Domain
Requirements
Extension Reqs. /
Hot Spots
Exten si o n
Stru ctu re
Ext.
Concepts &
Mechanisms
L o g i cal Stru ctu re
Usag e Stru ctu re
Know-How
BOM to IOM
So ci al Stru ctu re
Business Domains /
Customer Profiles
Source Code
Organisation
Meta-Data
Reqs.
Know-How
Division of Labor /
Team Roles
Model
Format / MetaInformation
So u rce Co d e
Stru ctu re
Build-Process /
Build-Time
Interface / Impl.
Description
Packaging / File
Mapping
G en erati o n
Stru ctu re
Ph ysi cal
Stru ctu re
Run-Time
Instrumentation
Layout
Components
Ru n ti me
Stru ctu re
Refl ecti ve
Stru ctu re
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.