Software-Entwicklung vs. Software Interaction/ Design

Dieser Beitrag dient der eigenen Reflektion und kann in der nächsten Zeit noch verändert und verbessert werden. Dieses ist quasi nur ein erster Entwurf des Textes. Trotzdem sind Kommentare erwünscht

Mir ist in den letzten Jahren immer mehr aufgefallen, dass wir in der Software-Entwicklung Probleme haben mit Wordings in dem Bereich. In den letzten Jahren haben sich neue Softwareentwicklungs-Methoden und das Bewusstsein für Usability und User Interface Design sich weiter durchgesetzt.

Eine etwas grobe Beschreibung des Vorgehens ist das Design Implement Analyse (DIA)-Cycle. Das ist bei einigen Informatik Lehrstühlen an der RWTH Aachen das Vorgehen bei den Diplomarbeiten. In einigen Fällen wird auch “nur” Design Prototype Evaluate Cycle (DPE) durchlaufen.

Diese Vorgehen sind vergleichbar mit den Entwicklungsstufen nach Logical User-Centered Interactive Design Methodology von Cognetics Coporation, Princton Junction, New Jersy (Kreitzberg, 1996):

Stufe 1: Entwicklung des Produkt-Konzeptes

Stufe 2: Durchführung von Forschungs- und Bedarfsanalysen

Stufe 3: Design-Konzepte und Prototypen mit zentral wichtigen Screens

Stufe 4: Wiederholung Design mit Verfeinerungen

Stufe 5: Implementierung der Software

Stufe 6: Sicherstellung des Supports beim Rollout

Diese Stufen sind angedacht für das ausrollen von Software in der “Wirtschaft” nach Ben Schneiderman.

Ich sehe nur ein Problem, dass Stufe 5 eine eigene komplexe Stufe ist, die Ihre eigene Methodik erfordert. Das heißt an der Stelle muss ein eigenes Vorgehen Methodisch eingeführt werden. Die Implementierung von Software besteht schon an sich aus mehreren Stufen.

Persönlich finde ich für Web und mobile Development z.B.: Feauter-Driven-Development, Test-Driven-Development usw. geeignet.

In vielen Abschlussarbeiten oder Projekten wird momentan meist nur DIA oder DPE als Methode angewendet oder eins der Software Entwicklungsmethoden. Eine sinnvolle Kombination findet meist nicht statt, weil sehr viele die sich für DIA oder DPE entscheiden, denken dass sie eine Software-Entwicklungsmethode anwenden.

Ich tendiere inzwischen zu Software Product Development als das Ganze zu betrachten, welches unterteilt ist in: Design und Software Entwicklung. Im Design sind Dinge wie Produkt-Idee, Software(Produkt)-Konzept, Erstellung von Szenarien und Personas, Interaction Design, User Interface Design, Usability-Testing usw. Im zweiten Feld sind Dinge wie Anforderungs-Analyse, Use-Case-Entwicklung, Software Architektur, Software-Implementierung, Software-Test angebracht.

In einigen Agilen-Software-Dev. Teams gibt es Überschneidungen in den einzelnen Tätigkeiten. Die jeweiligen Aufgaben sind auch nicht immer ganz sequenziell an zusehen. Usability-Tests können noch einmal mit dem fertigen Software-Produkt durchgeführt werden.

Wichtig ist, dass grade bei Abschlussarbeiten die Studierenden wissen an welchem Punkt sie mit ihrer Arbeit ansetzen und auch die Betreuer wissen, was sie von dem Studierenden wollen. Oft wird ein Mischmasch gemacht und als “evolutionäres” Vorgehen bezeichnet.

Hier sollte ein Blick in Unternehmen geworfen werden die momentan Software mit hoher Qualität und Joy of Use ausliefern. In diesen Firmen gibt es meist eine klare Trennung zwischen Konzept, Design und Implementierung. Für jeden Bereich werden Spezialisten eingesetzt. Informatiker sind meist oder durchgängig im Implementierungsbereich. Für die anderen Bereiche gibt es meist aus anderen Disziplinen begabtere und besser ausgebildete Menschen.

Gehalt Wissenschaftliche Mitarbeiter nach TV-L 13 und Lehrer nach A13 in NRW

Da sehr viele Anfragen auf mein Blog kommen die nach dem Gehalt von wissenschaftlichen Mitarbeitern fragen, denke ich mir ein eigener Eintrag zu dem Thema wäre angemessen.

Ich gehe von der Annahme aus, dass der oder die Person Lohnsteuerklasse I hat und keine Kinder. Die Berechnungen gehen vom Startgehalt auf der Stufe 1 aus. Ich habe angenommen, dass der Krankenkassenbeitrag bei 15,0% liegt. Bei der TK ist der momentan z.B. bei 15.5%. Die Tabelle ist auch nach dem Stand von 01.04.2011

	50% halbtags Stelle	100% volle Stelle
Jahreseinkommen	18663.06€	37326.12 €
Jahressonderzahlung	777.63€	1555.26€
Jahres Brutto	19440.69€	38881.38€
Monatlich Brutto durchschn.	1620.05€	3240.11 €
Grundgehalt monatlich	1555.26€	3110.51€
Netto Gehalt monatlich	1110.79€	1937.25 €
Abgaben ca.	29.3%	38.2%

In den Abgaben sind so Dinge wie Lohnsteuer, Soli, Krankenversicherung, Pflegeversicherung, Rentenversicherung, Arbeitslosenversicherungen.  Die Zahlen können etwas variieren je nachdem, ob man Kirchensteuerzahlt oder einen niedrigeren Krankenkassenbeitrag hat. Das Gehalt kann in den einzelnen Bundesländern auch etwas anders sein.

Ich habe diesmal noch die Gehaltstabelle für Lehrerinnen und Lehrer aufgestellt. Diese gilt für Gymnasiallehrer ohne Sonderzulagen beim Einstig in NRW. Tarifgruppe A13. Man muss hier beachten, dass Lehrende sich selbst privat krankenversichern müssen. Hier habe ich nachgeschaut, würde eine gute Versorgung ca. 190 € pro Monat kosten für einen Verbeamteten Lehrenden. Beamtinnen und Beamte bekommen noch eine Pension im Ruhestand.

	50% halbtags Stelle	100% volle Stelle
Jahreseinkommen	18945.60 €	37891.20 €
Jahressonderzahlung + Stellenzulage	496.91€ + 465.30 €	970.55€ + 930.60 €
Jahres Brutto	19907.81 €	39792.35 €
Monatlich Brutto durchschn.	1658.98 €	3316.02 €
Grundgehalt monatlich	1578.80 €	3235.15 €
Netto Gehalt monatlich	1459.42 €	2568.13€
Abgaben ca.	10.2%	21.0%

Das Gehalt bei E13 und A13 sehen recht gleich aus im Bruttobereich. Durch die geringen Abgaben der Verbeamteten erreichen sie einen deutlich höheren Monatsnetto. Bei Lehrenden kommt noch dazu, dass sie recht schnell Zulagen erlangen können für weitere Aufgaben die sie an der Schule übernehmen oder z.B. ein Studienseminar leiten. Dann geht das Gehalt noch sehr gut nach oben. Mit steigender Berufserfahrung steigt auch das Gehalt bei den Lehrenden.

Ich hoffe ich habe den Suchern nach Informationen etwas weitergeholfen. Meine Berechnungen habe ich mit Hilfe der Webseite http://oeffentlicher-dienst.infogemacht. Dort kann jeder an sich angepasst sein Gehalt ausrechnen. Eine sehr schöne Seite. Denke Anfangs etwas gewöhnungsbedürftig, aber dann klappt es ganz gut.

why the bridge building analogy fails and the war analogy succeeds from Effective UI Book

Ich habe ein kurzen Text aus einem Buch abgetippt. Es beschreibt die Situation/Prozess der Softwareentwicklung. Hier bei handelt es sich um Softwareentwicklung für Lösungen die von Menschen bedient werden. Das Buch Effective UI kann ich nur empfehlen bis jetzt. Es geht weniger um gutes Design, als gute Software. Grade im Bereich Web und Mobile kann das Buch einigen Entwicklerinnen und Entwicklern helfen. Das Besondere ist, dass es nicht wie andere Bücher bla bla nur über hochtrabende Methoden spricht und wie alles Apfel Like wird. Es behandelt das Thema schon recht pragmatisch und richtet sich an Entwicklungs-Teams in Unternehmen oder auch SE-Consultants.

To demonstrate how uncertainty and the unknown are inevitable components of a software development project, we`ll examine why the bridge building analogy fails and the war analogy succeeds. But even with the aid of analogies, it`s extremely difficult to explain why uncertainty and the unknown are unavoidable to someone who’s never been in the trenches of a software development project. Much of the understanding comes from seeing how design, creativity, and inspiration factor into every aspect of building an application. It also comes from having seen how false certainty, and the demand for it, can cause failure and lead to poorly designed products. It`s difficult to explain or prove this fact expect to state it this way for now: you understand your project far less than you think you do.

And so do your stakeholders, by the way. For your project to be successful, you need to cultivate in yourself and in your stakeholders a certain humility and a recognition that, for as much as you know, you know very little, and that the essence of the project is to investigate and solve a complex problem and not simply to implement a known solution. Embracing this humility of unknowing isn`t a resignation to defeat or admission of weakness, but rather is a state of wisdom required to allow you to succeed.

[…]

Everything required to design a bridge to a valley is knowable in advance and can be planned to an extremely high level of accuracy before construction begins. All of the important goals, variables, and constraints can be accurately obtained before design begins.

[…]

Once those key considerations have been discovered, the design of the project begins and can be entirely completed before construction starts. With accurate and complete design in hand, construction is then all about ensuring the pieces all come together as designed. Construction is not concerned with any remaining questions about design and isn`t burdened by the risk that the design will change during the course of construction.

By contrast, a general preparing for a battle can estimate the strength and disposition of his forces, the resources and capabilities available to him, the attitudes an aptitudes of his commanders in the field, the lay of the battlefield, the strategic goals of the battle, the state of the enemy`s forces, and the parameters for success. He also has history and personal experience to help him intuit how events will unfold. Based on this knowledge, he can formulate a plan for the battle.

But this plan, no matter how carefully devised, is inherently incomplete and imprecise. It is wholly premised on estimates of the conditions before the battle and entirely ignorant of the unforeseen conditions that arise during the battle. These unforeseen conditions are based as much on vagaries of weather, emotion, chance, and uncertainty as they are on even the best-laid plan. This reality is the basis for the famous quote:

No battle plan survives first contact with the enemy. – Helmut von Moltke

The same is true for software development. No matter how well you think you understand the domain and no matter how earnestly you`ve thought through the requirements, there is still great uncertainty in the original facts ans premises and a vast depth of the unknown still awaiting you. As with battle, the outcome will be determined at least as much by what comes during the course of the project as by what comes before it.

[…]

Hier der amazon Link: http://www.amazon.de/Effective-UI-Building-Experience-Software/dp/059615478X und noch der “native shop” oreilly.com/shop/