Systems Engineering

Safety oder Security? Was ist der Unterschied?

Mana­ge­­ment-Zusam­­men­­fas­­sung die­ses Bei­trags:Die Begrif­fe Safe­ty und Secu­ri­ty wer­den bei­de im Sys­tems Engi­nee­ring, im Requi­re­ments Engi­nee­ring sowie im Qua­li­täts­ma­nage­ment (und Risi­ko­ma­nage­ment) häu­fig benutzt. Um eine Ver­wech­se­lung zu ver­mei­den, soll­te eine Unter­schei­dung die­ser Begrif­fe vor­ge­nom­men wer­den.In die­sem Bei­trag wird eine Kurz­dar­stel­lung dazu gelie­fert. Die bei­den Begrif­fe kön­nen fol­gen­der­ma­ßen kurz cha­rak­te­ri­siert wer­den: Die Unter­schie­de von Safe­ty und Security … 

Wei­ter­le­sen …

Systems Engineering Komplexe Systeme richtig entwickeln

Das Sys­tems Engi­nee­ring beschäf­tigt sich mit der Beschrei­bung und Umset­zung von kom­ple­xen tech­ni­schen Sys­te­men und wird als eigen­stän­di­ge Dis­zi­plin gese­hen.In die­sem Bei­trag wer­den eini­ge Grund­be­grif­fe des Sys­tems Engi­nee­rings vor­ge­stellt. Das Sys­tems Engi­nee­ring wird als eigen­stän­di­ge oder dem Requi­re­ments Engi­nee­ring über­ge­ord­ne­te Dis­zi­plin gese­hen. Gene­rell betrach­tet das Sys­tems Engi­nee­ring neben der Soft­ware­ent­wick­lung auch das “klas­si­sche” Engi­nee­ring für … 

Wei­ter­le­sen …

Das Kano-Modell Kundenwünsche ermitteln und einordnen

Mana­ge­­ment-Zusam­­men­­fas­­sung die­ses Bei­trags:Das Kano-Modell dient zur Beschrei­bung und Klas­si­fi­ka­ti­on von Kun­den­wün­schen, um so zu ver­deut­li­chen, wel­che Eigen­schaf­ten ein (neu­es) Pro­dukt oder eine (neue) Dienst­leis­tung haben soll­te. Anhand des Kano-Modells und des damit ver­bun­de­nen Kano-Dia­­gramms kann schnell ermit­telt wer­den, was beson­ders wich­tig bei Pro­duk­ten oder Dienst­leis­tun­gen ist.In die­sem Bei­trag wird das Kano-Modell beschrie­ben. Das Kano-Modell (nach …

Wei­ter­le­sen …

Die FMEA — Fehlermöglichkeits- und Einfluss-Analyse Wichtig in allen Bereichen

Manage­m­ent­zu­sam­men­fas­sung die­ses Bei­trags:Die FMEA — Feh­­ler-Mög­­lich­keits- und Ein­­fluss-Ana­­ly­­se — dient der Vor­her­sa­ge von mög­li­chen Schwach­stel­len von Pro­duk­ten oder Dienst­leis­tun­gen und wird als Teil­dis­zi­plin dem Qua­li­täts­ma­nage­ment wie auch dem Risi­ko­ma­nage­ment zuge­ord­net. In die­sem Bei­trag wird die FMEA vor­ge­stellt. Die FMEA — Feh­­ler-Mög­­lich­keits- und Ein­­fluss-Ana­­ly­­se (eng­lisch Fail­ure Mode and Effects Ana­ly­sis) — ist ein Ver­fah­ren zur Vorhersage … 

Wei­ter­le­sen …

Das V‑Modell Darstellung und Verwendung

Mana­ge­­ment-Zusam­­men­­fas­­sung die­ses Bei­trags:Das V‑Modell (auch Vor­ge­hens­mo­dell, engl. V‑Model) beschreibt ein Vor­ge­hen bei der Ent­wick­lung von Soft­ware, Sys­te­men oder Pro­duk­ten, wel­ches sich gra­fisch ent­lang eines Vs visua­li­sie­ren lässt.In die­sem Bei­trag wird das V‑Modell und des­sen Ein­satz in ver­schie­de­nen Kon­tex­ten wie dem Sys­tems oder Requi­re­ments Engi­nee­ring beschrie­ben. Das V‑Modell ver­wen­det ein V zur Visua­li­sie­rung der Rei­hen­fol­ge von … 

Wei­ter­le­sen …

Use Case Wesentlich für die Erfassung von Anforderungen

Mana­ge­­ment-Zusam­­men­­fas­­sung die­ses Bei­trags:Ein Use Case (deutsch Anwen­dungs­fall) beschreibt mit weni­gen Ele­men­ten eine gro­be Sicht auf Sys­te­me im Requi­re­ments und Soft­ware Engi­nee­ring.Es wer­den in die­sem Bei­trag die Use Cases beschrie­ben. Use Cases sind ein “Standard”-Diagrammtyp der → UML / Uni­fied Mode­ling Lan­guage, wel­ches sehr häu­fig ein­ge­setzt wer­den kann. Da es nur weni­ge Ele­men­te auf­weist, kann es … 

Wei­ter­le­sen …

Die UML — Unified Modeling Language Die wichtigste Modellierungssprache für Anforderungen

Mana­ge­­ment-Zusam­­men­­fas­­sung die­ses Bei­trags:Die UML (Uni­fied Mode­ling Lan­guage, auf Deutsch Uni­ver­sel­le Model­lie­rungs­spra­che) ist die Model­lie­rungs­spra­che für Anfor­de­run­gen im Requi­re­ments und Soft­ware Engi­nee­ring. Es wird in die­sem Bei­trag die UML mit den 14 Dia­gramm­ty­pen beschrie­ben. Die UML / Uni­fied Mode­ling Lan­guage ist eine Model­lie­rungs­spra­che für das Requi­re­ments Engi­nee­ring (RE) und Soft­ware Engi­nee­ring (SE). Ent­stan­den Ende der 1990er … 

Wei­ter­le­sen …

Komplex vs. Kompliziert Erläuterungen und Einsatz

Mana­ge­­ment-Zusam­­men­­fas­­sung die­ses Bei­trags:Den Schlag­wor­ten “Kom­ple­xi­tät” und “Kom­pli­ziert” begeg­net man häu­fig — auch im beruf­li­chen Kon­text.In die­sem Bei­trag wer­den die bei­den Begrif­fe erläu­tert und Anwen­dungs­fäl­le benannt. Den Schlag­wor­ten “Kom­ple­xi­tät” und “Kom­pli­ziert” begeg­net man im Umfeld der Pro­dukt­ent­wick­lung und in Pro­jek­ten häu­fig. Sie wer­den zur Cha­rak­te­ri­sie­rung von Sach­ver­hal­ten oder Sys­te­men her­an­ge­zo­gen und lie­fern dann Anhalts­punk­te für ein … 

Wei­ter­le­sen …

Der Korridor der Unsicherheit

Der “Korridor der Unsicherheit” Grafik des Monats Dezember 2014

1. Beschrei­bung Wer­den Schät­zun­gen des Auf­wands und der Dau­er (für ein Pro­jekt) durch­ge­führt, so sind die­se immer mit einer Unsi­cher­heit behaf­tet. Genaue Schät­zun­gen sind auf­wen­dig (und damit teu­er) und wer­den daher meis­tens erst durch­ge­führt, wenn das Pro­jekt wei­ter kon­kre­ti­siert wird. Es ergibt sich somit ein “Kor­ri­dor der Unsi­cher­heit” (eng­lisch Cone of Uncer­tain­ty, ande­re Bezeich­nung auch … 

Wei­ter­le­sen …