Modellieren für Software & System
“Wer hohe Türme bauen will, muss lange am Fundament verweilen.”
Anton Bruckner
(Österreichischer Komponist)
"Man muß die Dinge so einfach wie möglich machen. Aber nicht einfacher."
(Einstein)
Festpreisprojekte zwangen mich
- Requirements schätzen zu lernen
- Modellierung einzusetzen um präzise zu formulieren
- Immer an Test denken
- Erfahrungen als Wissen für mich und andere zu dokumentieren
- Arbeitsprodukte müssen zu den Zielen führen
- Kosten, Termine, Wartbarkeit im Auge behalten
- Prozesse nicht für Arbeitsprodukte sondern für Inhalte
Was mich überraschte:
- Ausgaben für Verstehen, Requirements, Modelle und Test bringen Rendite
- Abkürzungen sind riskant - nicht nur beim Umfahren eines Staus
Profitieren von Erfahrung
Sie profitieren von 35 Jahre Projekte, 25 Jahre Modellierung:
- Ihre Modelle bringen Ihnen Nutzen
- Ihre UML / SysML Modelle passen zu Ihre Prozessen
- Requirements, Architektur / Design und Test ergänzen sich
- Toolchain automatisiert wiederkehrende Dinge
- Ihr Management und Ihre Mitarbeiter kennen den Wert Ihrer Modelle
- Ihre Mitarbeiter wissen was Sie tun und wo es Hilfe gibt
- Reverseengineering könnte ein Startpunkt sein
Themen
- Architektur & Design mit
-
- UML
- SysML inkl. integrieren Simulation mit Modelica
- Integration in Prozesse
-
- SPICE / CMMI
- Functional Safety
- Produktlinie
- Tools wie
-
- SPARX Enterprise Architect
- IBM Rhapsody
- Reverse Engineering C/C++ für SPICE, CMMI, Functional Safety
- Automatisierung wiederkehrender Aufgaben
Services
- Coaching + Projektarbeit
- Workshops
- Trainings
- SPARX Enterprise Architect
-
- Reverse Engineering von Code (C/C++)
- Ihr Addin für Ihre Prozesse und Arbeitsschritte
- Produktlinie statt viele Modelle
- Hilfe als Service (Telefon, E-Mail, Online Meeting)
Branchen
In den letzten Jahren:
- Embedded
- Automotive inkl. Functional Safety
- Industrie
aber auch:
- Banken & Versicherung
- und mehr
Berufliche Prägung
Was mich beruflich prägte:
- Festpreisprojekte lehren auf die harte Art
- Inbetriebname fremder Software zeigte mir den Wert von explizietem Wissen
- Abkürzungen sind meistens teuer
- Dass Problem verstehen ist mehr als die halbe Lösung
- Ohne Pioniergeist und Begeisterungsfähigkeit geht fast nichts
- Zuhören
Erfolgsfaktoren für gute Modelle
Ein guter Modellierer hat das Problem verstanden und ist in der Lage dies möglichst einfach seinen Lesern zu vermitteln. Hierzu nutzt er grafische Sprachen wie UML oder SysML. Bei aller Begeisterung vergisst er nicht seine Modelle mit Text zu erklären.
- Verstehen den Unterschied zwischen Model und Diagram
- Diagram als Sicht
- Jedes gute Diagram sollte eine Story haben die das Diagram erzählt
- 7 +-2 Elemente auf einem Diagram ist Leser geeignet
- Es ist einfach komplizierte Diagramme zu machen
- Es ist schwierig einfache Diagramme zu machen
- Vergessen Sie niemals Ihre Ziele
Private Prägung
Was mich privat prägte:
- Begeisterung
- Familie
- Marathon
- Fussball, mittelmäßig aber mit Engagement
- Schach
Wofür mein Herz schwingt
Mir macht Spass:
Aktivitäten
Meine Aktivitäten:
- SPARX Forum
- SPARX Community
- hoTools, was mir bei SPARX Enterprise Architect fehlt
- hoReverse, Model aus C/C++ Code, ReqIF mit SPARX Enterprise Architect
Was mir noch einviel
- Modellierer sollten sich als Author fühlen
- Der Author sollte seinen Lesern (Stakeholder) erklären
- Da Englisch für die meisten von uns keine Muttersprache ist:
Investieren Sie ein Paar Euros in: -
- Tools die klare und korrekte englische Sprache fördern wie Grammarly oder Hemmingway