Soziale Strukture in neuen Softwareprojekten

Dr. Bernhard Scheffold, (bernhard.scheffold@adinfinitum.de)

Walter Kriha,

(walter@kriha.de)

• 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

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 Software-Architektur: Neue Rollen, Interaktionsmuster, Denkmuster und Kultur der Entwicklung von Software

Formen der Kritik am Alten

Business Technik Sozial Denkmuster

Art Offen Offen Implizit odergar nicht

kaum

Tiefe Im Detail Im Detail,aber oftnicht überden Lebens-zyklus

KaumUrsachen-forschung

Kein Wissen,Leiden

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 Software-Entwicklung als sozialer Prozess

TechnischeStrukturen

Soziale GliederungKategorien-

system

First SW-Architecture Model

Software

Programmers

A piece of software gets downloaded to special hardware. It contains system and application. No decomposition of software or programming

BusinessUse, Ergonomics,

Require-ments,

Availability

ProgrammingLanguage

Base-Model SW-ArchitectureSmall scale

System

Application

System Group

Application group

Technical

InterfaceSocial

Interface

BusinessUse, Ergonomics,

Require-ments,

Availability

ProgrammingLanguage

SystemResources,

Concurrency

Base-Model SW-ArchitectureLarge scale: application tower

System

App.

System Group

App.group

Technical

InterfaceSocial

Interface

App. App.

App.group

App.group

Business Business Business

3-Tier-Model SW-ArchitectureLarge scale: common services

System

App.

System Group

App.builder

App. App.

App.builder

App.builder

Service Builder

Common business logiccommon appl. services

Bus. Bus. Bus.

Framework Architecture with Components

ORB

Special ORB

Entities/Storage

Branch specific

Customer specific

Model

Branch specific

Customer specific

GUI

Branch specific

Customer specific

BASE

Branch specific

Customer specific

APP

Branch specific

Customer specific

Meta-Information component

ComponentEditor

Buys

Beans

BusinessUser

Frameworking

Framework

Appl.

Hollywood

principle

Business Business

Appl.Progr.

FrameworkerAppl.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

Beanproducer A

Beanproducer B

Beanproducer C

Free market of human beans

Minimizes social interfaces

Beantoolconnects beans

BeanA

BeanB

BeanC

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

Development

Test/QAShipping,tayloring

Support,Maintenance

Reliability, Quality and Extendability show up as problems not in development but in other groups.

Progr. QA/QC. Service.HelpDesk

Waterfall Development view

APPLIKATION

Analysis

Design

Coding

Analyst

Designer

Coder

Who takes care of performance, reuse etc.? Who sees the whole?

Where is the process view?

Money, image, power

Money, image, power

How Networking becomes “Novell”

NetworkSpecialist

at CompanyX

Network abstractions, protocols,Standards and technology

Network productcompany

Abstract and technical categories

UsageorientedInterface

Business

Analytic Structure

GenerationStructure

ReflectiveStructure

ExtensionStructure

Logical Structure

RuntimeStructure

Social Structure

PhysicalStructure

Source CodeStructure

Usage Structure

User / DomainRequirements

Requirements: put weights onall the structures

DevelopmentResources

Extension Reqs. /Hot Spots

BOM to IOMMeta-DataReqs.

Run-TimeInstrumentation

ComponentsLayout

Source CodeOrganisation

Know-How

Division of Labor /Team Roles

Know-How

Format / Meta-Information

Build-Process /Build-Time

Business Domains /Customer Profiles

Model

Packaging / FileMapping

Ext.Concepts &Mechanisms

Interface / Impl.Description

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.