Software Engineering

Requirements Engineering als Schlüsseldisziplin

Requirements Engineering ist die Schlüsseldisziplin in der Software-Entwicklung, da die Anforderungen an ein System die Grundlage für Ihre weiteren Entwicklungstätigkeiten legen. Ob Sie klassisches Anforderungsmanagement betreiben oder agiles Requirements Engineering: Method Park hilft Ihnen dabei, diese Herausforderungen zu meistern.

System- & Software-Architektur für klare Strukturen

Architektur nimmt eine zentrale Position zwischen Anforderungen, Implementierung und Test ein. Wenn Sie die Architektur vernachlässigen, gehen Sie viele Risiken ein: Technische Probleme werden ohne Architektur erst spät entdeckt. Ihr Entwicklungsteam arbeitet ineffizient, wenn das gemeinsame Bild fehlt. Ohne Architektur bleibt es dem Zufall überlassen, ob Ihr System seine Qualitätsanforderungen erfüllt.

Qualitätssicherung durch effiziente Software-Tests

Testen und eine unabhängige Qualitätssicherung sind wesentliche Basis für die Sicherstellung der von Ihnen erwarteten Software-Qualität. Mit der steigenden Komplexität im Software Engineering sind Sie zudem gefordert, Ihre Maßnahmen zur Qualitätssicherung kontinuierlich weiterzuentwickeln. Method Park konzipiert und realisiert für Sie die geeigneten Testprozesse und zeigt Ihnen, wie Sie Ihr Qualitätsmanagement an veränderte Anforderungen anpassen.

Mit professionellem Software Engineering Consulting

  • greifen Sie auf umfangreiches Methoden- und Technologie-Know-how zu
  • fließen die besonderen Gegebenheiten Ihrer Branche, Ihres Unternehmens und Ihrer Projekte in ein pragmatisches Software Engineering ein
  • integrieren Sie die richtigen Schritte von der Anforderungserhebung, über die Architektur bis hin zum Test und verbessern damit Ihre Software-Engineering-Prozesse
  • bleiben Ihre Prozesse konform zu Normen und Standards (IEC 61508, ISO 26262, SPICE, CMMI etc.)
  • führen Sie passende Methoden und Werkzeuge in Ihr Software Engineering ein
  • konzipieren, entwickeln und testen Sie auch variantenreiche Systeme mit weniger Aufwand
  • steigern Sie die Software-Qualität Ihrer Produkte und stellen eine hohe Qualität Ihrer Systeme sicher
  • laufen Ihre Entwicklungsprojekte einfach runder

Services zum Software Engineering bei Method Park

  • Beratung und projektbegleitendes Coaching zu den Grundvoraussetzungen einer hochwertigen Entwicklung
  • Seminare, Trainings und Qualifizierung von Requirements Engineers, Software-Architekten und Testern nach anerkannten Standards
  • Analyse, Bewertung, Assessment und Verbesserung Ihrer Architektur-, Requirements-Engineering- und Test-Prozesse gemäß SPICE, CMMI, IEC 61508, ISO 26262, IEC 62304
  • Unterstützung beim Roll-out neuer Software-Engineering-Prozesse
  • Evaluierung, Auswahl und Anpassung von Werkzeugen und Methoden
  • Schulung Ihrer Mitarbeiter im Umgang mit diesen Werkzeugen und Techniken
  • Erstellung und Review von Pflichten- und Lastenheften
  • Entwicklung von Architekturen für Software-Produktlinien
  • Konzeption und Umsetzung von Testprozessen (auch im agilen Umfeld) sowie Testautomatisierung und Durchführung von Testprojekten

Die Bewertung einer Software-Architektur ist ein wichtiger Baustein in der Qualitätssicherung eines Systems. Bei dieser Bewertung sind aber nicht nur reine Fachfragen entscheidend. Die Beziehungen zwischen den Beteiligten spielen oftmals eine große Rolle. Eine sachliche Analyse der Stärken und Schwächen einer Architektur ist erst dann möglich, wenn Ängste um Ansehen und Position abgebaut sind und eine offene Kommunikationskultur etabliert ist. Bei der Vorbereitung und Durchführung einer Architekturbewertung sind daher einige Regeln zu beachten.in: SQ-Magazin (Ausgabe Dezember 2012)

Download

Im Automotive Umfeld nimmt die Anzahl aktiver Sicherheits- und Assistenzfunktionen stark zu. Da diese Komponenten direkten Einfluss auf das Fahrzeug nehmen, entstehen zusätzliche Risiken, die bei der Entwicklung im Rahmen der Funktionalen Sicherheit nach ISO 26262 betrachtet werden müssen. Sicherheits- und Assistenzsysteme sind gekennzeichnet von hohen Verfügbarkeitsanforderungen, aus denen sich harte Echtzeitanforderungen ergeben. Diese Anforderungen werden in der Entwicklung oft erst spät betrachtet. Die daraus entstehenden Mehrkosten lassen sich vermeiden, indem man frühzeitig verschiedene Architekturvarianten miteinander vergleicht. Dieser Artikel zeigt anhand eines konkreten Beispiels, was dabei zu beachten ist. In: HANSER automotive (Ausgabe 10/2017) Eine noch ausführlichere Darstellung des Themas finden Sie unter https://www.hanser-automotive.de/4239662

Download

In einem Automatisierungssystem sind meist einen ganze Reihe von Sensoren und Aktoren involviert. Für einfache Systeme mit nur wenigen, verschiedenartigen Ereignissen und einer überschaubaren Anzahl von Sendern und Empfängern reichen sicherlich bekannte Entwurfsmuster zur Lösung aus. Dagegen sind diese Muster bei Systemen mit vielen Software-Komponenten unzureichend: Sehr viele verschiedene Sender verschicken unterschiedliche Nachrichten. Und: Nicht immer ist klar, wo sich die Sender im System befinden.Eine Lösung für dieses Problem ist ein Messaging-System, das zentral die Nachrichten verteilt und dabei Sender und Empfänger komplett entkoppelt. Dieses Messaging-System wird durch einen Broker umgesetzt, an dem sich alle im System befindlichen Sender und Empfänger registrieren. Deren Entwicklung ist mithilfe der Sprache C# möglich.Dieser Artikel beschreibt iterativ, welche Schritte dabei nötig sind. Außerdem gibt er einen Ausblick darauf, wie ein Messaging-System losgelöst von vorhandenen Hilfsmitteln einer Sprache erreicht werden kann.In: iX Developer “Internet der Dinge“ (Sonderheft Dezember 2015)

Download

Frontlastige Architektur und Agilität scheinen wie Feuer und Wasser – schließlich bedeutet Upfront eine frühe Festlegung sämtlicher Architekturelemente, während agile Vorgehensweisen Entscheidungen möglichst spät treffen. Aber kann „spät“ nicht auch „zu spät“ sein? Können im agilen Vorgehen manche Entscheidungen auch früh gefällt werden? Die Antwort liegt in der Betrachtung der Risiken und Rahmenbedingungen des Software-Projektes. Wenn Upfront-Architektur bedeutet, mehr Wissen über das Produkt zu erhalten, dann deckt sich dies mit dem agilen Gedankengut. Mit einem Mindestmaß an Analyse kann es gelingen, den „Sweet Spot“ zwischen ungeplantem und überplanvollem Vorgehen zu treffen. in: OBJEKTspektrum (Ausgabe 4/2014)

Download

Architektur ist nicht einfach nur ein Abbild der Software-Struktur oder entsteht durch die Genialität eines einzelnen Architekten. Sie folgt vielmehr festen Konstruktionsregeln, die als Stand der Technik veröffentlicht sind und durch regulatorische Anforderungen näher beschrieben oder eingegrenzt werden.Der VDI bot im Rahmen der MedConf 2015 eine Vortragsreihe an, die am Beispiel des „VDInsulinmanagers“ die Entwicklung eines medizinischen Software-Systems darstellt, konform zu Normen und dem Stand der Technik und durchgängig von den Anforderungen bis zur Zulassung. Während das MedicalSPICE, als VDI Richtlinie 5702 Blatt 1, alle regulatorischen Anforderungen aus IEC62304, ISO13485 etc. harmonisiert, wird 2016 im Blatt 2 der Stand der Technik in Form von Best Practices veröffentlicht. Der vorliegende Beitrag beschreibt dessen Anwendung für die Erstellung der Architektur für den „VDInsulinmanager“.In: MED engineering (Ausgabe 11-12/2015)

Download

„All the brilliant people working on the same thing, in the same space, on the same computer“ – mit diesem Slogan wirbt die Software-Entwicklungsmethode Mob Programming für sich und buhlt um die Gunst der Praktiker. Das grundlegende Prinzip dieser Methode besteht darin, an eine Aufgabe gemeinsam im Plenum – dem namensgebenden „Mob“ – heranzugehen. Nach einer Einführung in die Methodik zeigt dieser Artikel, wie sich Mob Programming auf Code Retreats oder in einem konkreten Entwicklungsprojekt anwenden lässt. Er gibt Tipps zum Tailoring der Methode und Hinweise zu wichtigen Rahmenbedingungen und erläutert die involvierten Rollen. In: E&E (Ausgabe 8, 2017) Dieser Link führt Sie zum Fachartikel auf der Webseite der E&E: https://www.industr.com/de/E-und-E-Magazin/designtools-software/gemeinsam-gestalten-2303751

Download

Agile Herangehensweisen werfen die etablierten Testmethoden über den Haufen. Das verwirrt erfahrene Tester und fordert von Projektmanagern eine neue Definition ihrer Aufgaben. Ein Beitrag von Dr. Uwe Hehn im aktuellen Juni-Heft des „SQ-Magazins“ zeigt, dass der agile Test eine sinnvolle Erweiterung der bekannten Testvorgehensweisen sein kann. in: SQ-Magazin (Ausgabe Juni 2012)

Download

Der Artikel vermittelt das Konzept und die Grundzüge des agilen Testens. Er bespricht und diskutiert die Vor- und Nachteile agilen Testens in der Praxis. Neben den fachlichen Unterschieden zwischen traditionellem, systematischem, geplantem Testen und agilem Testen werden vor allem die „kulturellen Unterschiede“ dieser beiden Sichtweisen dargestellt. Der Beitrag zeigt Ihnen außerdem, wo Sie agiles Testen einsetzen und wo Sie traditionelles und agiles Testen sinnvoll kombinieren. in: Elektronik Praxis (Ausgabe Dezember 2011)

Download

Informatik-Absolventen verfügen über ein vielfältiges fachliches Wissen aufgrund einer langjährigen formalen Ausbildung an der Hochschule. Beim Einstieg ins Berufsleben werden von ihnen aber meist weitere Kompetenzen verlangt, damit sie in ihrer Funktion als Software Engineer ihren Teil zu qualitativ hochwertiger Software beitragen können. Für IT-Unternehmen gilt es die nicht nur Beschäftigungsfähigkeit der Berufseinsteigers herzustellen, sondern auch ihr Bewusstsein für Software-Qualität zu wecken. Der Beitrag stellt am Beispiel des „Certified Method Park Engineer“ (CMPE) von Method Park einen Entwurf für ein innerbetriebliches Lehr-Lern-Konzept vor. Der Artikel will Unternehmen einen Anstoß für die Entwicklung eigener Einführungsprogramme geben und Berufseinsteiger dazu motivieren, dies nicht nur als Verbesserung ihrer Kompetenzprofile zu sehen, sondern zudem ihr Unternehmen als attraktiven Arbeitgeber für eine langfristige Bindung wahrzunehmen. In: ZWF (11/2016)

Download

Qualität ist Führungsaufgabe. Mit der Definition von Qualitätsrichtlinien, Prozessen und Zielen ist diese Führungsaufgabe aber bei weitem nicht erfüllt. Qualitätsrichtlinien müssen umgesetzt und vorgelebt werden. Dazu sind Fachwissen, hohes Verantwortungsbewusstsein, ein solides Verständnis der regulatorischen Auflagen, der eigenen Prozesse und Organisationsstruktur sowie eine gute Portion wirtschaftlichen Mitdenkens genauso von Nöten wie klassische Führungstugenden. Gerade im gesamten Healthcare-Bereich stellen sich hier besondere Herausforderungen. Der Beitrag beantwortet die Frage, welche Kernkompetenzen und welche Fachkenntnisse hier unbedingt gefragt sind, wie sie aufgebaut werden können, wie sie in der Praxis zusammen spielen und was passieren kann, wenn sie es nicht tun.in: MED engineering (Ausgabe 9-10/2013)

Download

Medizintechnik-Hersteller nehmen heute vielfach die Unterstützung externer Berater in Anspruch. Diese Dienstleister entwickeln im Kundenauftrag auch die in den Medizingeräten enthaltene Software. Dabei kommen meist kundeneigene Prozesse zum Einsatz.Beratungsunternehmen entwickeln jedoch auch eigene Prozesse, um eine hohe Qualität ihrer Dienstleistungen sicherzustellen. Diese müssen den Anforderungen der Medizintechniknormen genauso standhalten wie die Entwicklungsprozesse der Hersteller. Damit sie den steigenden Qualitätsansprüchen der Branche genügen, lassen immer mehr Dienstleister ihr Qualitätsmanagement-System und die damit verbundenen Prozesse nach DIN EN ISO 13485 zertifizieren. Am Beispiel des Standard Engineering Prozesses von Method Park zeigt der Beitrag, welche Schritte notwendig sind, um den Software-Entwicklungsprozess für die Zertifizierung vorzubereiten. in: MEDIZIN+elektronik (Ausgabe 3/2015) Mit freundlicher Genehmigung der Redaktion steht dieser Artikel hier zum Download bereit.

Download

Hersteller von Medizintechnik und medizinischer Software müssen ihre Arbeitsprozesse und –ergebnisse konsistent dokumentieren; erst dann dürfen sie ihre Software auf den Markt bringen. Entwickler müssen ihr Vorgehen also korrekt, aber mit möglichst geringem Aufwand über den gesamten Projekt-Lebenszyklus hinweg erfassen. Der Beitrag beschreibt die fünf für die Software-Entwicklung geltenden Normen und zeigt exemplarisch, wie eine schlanke und sinnvolle Dokumentation aussehen kann.in: OBJEKTspektrum (Ausgabe 3/2011)

Download

Damit Software-Systeme fehlerfrei arbeiten, müssen sie eingehenden Tests unterworfen werden. Verschiedene Normen geben hier Hilfestellung zu Testerfahren und –methoden. Allerdings setzen diese Normen unterschiedliche Schwerpunkte. Mit der neuen Testnorm ISO/IEC 29119 solle einzelne Ansätze aufeinander abgestimmt werden. Der Beitrag gibt einen detaillierten Überblick über die ISO/IEC 29119.in: SQ-Magazin (Ausgabe Juni 2011)

Download

Bevor man Qualitätssicherung in einem Software-Entwicklungsprojekt einführt, möchte man so genau wie möglich die Frage beantworten: Welche zusätzlichen Kosten wird die Sicherung der Qualität wirklich mit sich bringen?Bei der Planung der Kosten muss zunächst entschieden werden, ob die Qualitätsaktivitäten mit den schon vorhandenen Ressourcen abgedeckt werden sollen. Bei diesem Ansatz geht man von einem festen Kostenrahmen und den zur Verfügung stehenden Mitarbeiterqualifikationen aus. Dann priorisiert man die Aufgaben so, dass sie mit den gegebenen Kapazitäten abgedeckt werden können.Ein anderer möglicher Ansatz geht von der Arbeitsmenge für die Qualitätssicherung aus und schätzt deren Gesamtkosten: Sind zusätzliche Kapazitäten nötig, die sich ausschließlich auf die Qualität fokussieren? In manchen Unternehmen ist es üblich, ein Qualitätsteam zu etablieren, das in mehreren Projekten die gleiche Rolle übernimmt. Der Artikel erläutert ausführlich die Mechanismen der Qualitätsplanung und zeigt, wie sich je nach Kontext und Anspruch an die Qualität Kosten berechnen lassen. Außerdem stellt er weitere Erfahrungswerte und konkrete Use Cases vor.in: Qualität und Zuverlässigkeit (Ausgabe 1/2015)

Download

Software lässt sich weder greifen noch offensichtlich qualitativ bewerten. Man kann nur das äußere Erscheinungsbild und die Funktionalität sehen. Der Software-Entwickler muss alle Prinzipien und Praktiken beherrschen, die die Güte von Software sicherstellen. Die Clean Code Developer Initiative stellt einen Werkzeugkasten für Software-Entwickler bereit, der einfache Methoden zur kontinuierlichen Verbesserung von Quellcode beinhaltet. Clean Code beschreibt pragmatische Ansätze, die in jedem Software-Projekt anwendbar sind. Der Artikel bietet eine Einführung in die Grundlagen von Clean Code, ohne technisch zu sehr in die Tiefe zu gehen. Er wendet sich daher insbesondere an Führungskräfte, die den Nutzen von Maßnahmen zur Verbesserung von Software-Qualität verstehen müssen, um ihren Teams die Freiheit zur Umsetzung von Clean Code einräumen zu können.in: Qualität und Zuverlässigkeit (Ausgabe 5/2014)

Download

Die Bandbreite der Techniken und Modelle für die Qualitätssicherung ist kontinuierlich größer geworden. Die Kunst besteht nun darin, gleich in der Startphase eines Projektes hier die spezifisch richtige Auswahl zu treffen. Sie entscheidet über den Erfolg oder Misserfolg der Qualitätssicherung.in: Management und Qualität (Ausgabe 11/2011)

Download

Software-Projekte scheitern in der Regel nicht an technischen Problemen, sondern an mangelhafter Kommunikation. Ein reibungsloser Informationsaustausch zwischen allen Projektbeteiligten – auch zwischen Auftragnehmer und Auftraggeber – ist hier der Schlüssel zum Erfolg. Anhand mehrerer Beispiele aus der Praxis zeigt der Beitrag klassische Problemsituationen und adäquate Lösungsmöglichkeiten auf.in: Qualität und Zuverlässigkeit (Ausgabe 1/2012)

Download

Für viele Projektverantwortliche ist Risikomanagement entweder überhaupt nicht existent oder sie kümmern sich kaum darum. Werden jedoch Risiken frühzeitig erkannt, lassen sich diese vermeiden oder umgehen. Im schlimmsten Fall trägt rechtzeitiges Risikomanagement zur Vorsorge bei. Der Beitrag zeigt einfache Methoden auf, um für viele Fälle gewappnet zu sein.in: Elektronik Praxis, ESE-Report, Titelstory (Ausgabe Februar 2011)

Download

Die Validierung von Software-Werkzeugen für die Entwicklung, Qualitätssicherung und Herstellung von Medizinprodukten ist ein Thema, über das nicht gerne gesprochen wird. Denn oft herrscht Unsicherheit über mindestens eine der folgenden Fragen: Welche Software muss eigentlich validiert werden? Kann man ein Werkzeug nicht stillschweigend verwenden? Welchen Anforderungen muss eine Werkzeug-Validierung genügen? Wie erfüllt man diese effizient und wie wird das dokumentiert? Diesen Fragen beantwortet der vorliegende Artikel.in: mt medizintechnik (Ausgabe 3/2014)

Download

Die ISO 13485 fordert für die Herstellung von Medizinprodukten eine Validierung von Prozessen und nötigen Werkzeugen. Diese Validierung dient als Nachweis, dass die eingesetzten Werkzeuge das korrekte Ergebnis liefern. Dies gilt für Hardware und Software. Leider kann man z.B. bei Software-Testwerkzeugen nicht einfach durch Messen überprüfen, ob das Werkzeug in der angegebenen Toleranz korrekt funktioniert. Hier muss ein geeigneter Validierungsplan aufgestellt und eine passende Strategie gefunden werden. in: mt medizintechnik (Ausgabe 4/2013)

Download

2012 wurde der Lehrplan für den Certified Tester, Advanced Level komplett überarbeitet. Die Erwartungen an den neuen Lehrplan waren hoch. Zu viele Wünsche ließ die Vorgängerversion von 2007 offen; insbesondere die Redundanzen der Module waren auf heftige Kritik gestoßen. Der Fachartikel beschreibt, worin sich die alte Version von dem neuen Lehrplan unterscheidet. Sofort erkennbar sind wesentliche strukturelle Änderungen. Der Beitrag zeigt aber nicht nur die wesentlichen Änderungen im Gesamtlehrplan, sondern erläutert auch ausführlich, was sich in den einzelnen Modulen geändert hat. in: SQ-Magazin (Ausgabe März 2013)

Download

2012 wurde der Lehrplan für den Certified Tester, Advanced Level komplett überarbeitet. Die Erwartungen an den neuen Lehrplan waren hoch. Zu viele Wünsche ließ die Vorgängerversion von 2007 offen; insbesondere die Redundanzen der Module waren auf heftige Kritik gestoßen. Das White Paper beschreibt, worin sich die alte Version von dem neuen Lehrplan unterscheidet. Sofort erkennbar sind wesentliche strukturelle Änderungen. Das White Paper zeigt aber nicht nur die wesentlichen Änderungen im Gesamtlehrplan, sondern erläutert auch ausführlich, was sich in den einzelnen Modulen geändert hat.

Download