Systems Engineering

Schätzen in Projekten Aufwände passend zum richtigen Zeitpunkt ermitteln

Die Bedeu­tung des Schät­zens von Auf­wän­den bei der Pla­nung und Umset­zung von Pro­jek­ten ist unbe­strit­te­ner­ma­ßen sehr hoch. Den­noch tre­ten in der Pra­xis Proble­me mit Schät­z­er­geb­nis­sen auf, die sel­ten aus der man­geln­den oder fal­schen Anwen­dung von Werk­zeu­gen und Metho­den resul­tie­ren, son­dern oft­mals das Resul­tat von nicht-abge­­­stim­m­­ten Schätz­pro­zes­sen sind.In die­sem Bei­trag wird das Schät­zen von Auf­wän­den in … 

Wei­ter­le­sen …

Softwarearchitektur Die Definition und Beschreibung von Softwarearchitekturen mit professionellen Methoden

Die Soft­ware­ar­chi­tek­tur beschreibt den Auf­bau eines Soft­ware­sys­tems und unter­stützt die Ent­wick­lung von Soft­ware­sys­te­men. Die Soft­ware­ar­chi­tek­tur eines Soft­ware­sys­tems ist ent­schei­dend für die Lauf­fä­hig­keit und Akzep­tanz eines Sys­tems. Nur “gute Soft­ware­ar­chi­tek­tu­ren” tra­gen ein Sys­tem durch den gesam­ten Lebens­zy­klus. 1. Ein­lei­tung und Grund­la­gen Hier wer­den zunächst eini­ge Defi­ni­tio­nen zur Soft­ware­ar­chi­tek­tur vor­ge­stellt.  1.1 Defi­ni­tio­nen In der Wiki­pe­dia steht zur … 

Wei­ter­le­sen …

Safety oder Security? Was ist der Unterschied?

Mana­ge­­ment-Zusam­­men­­fas­­sung zu die­sem Bei­trag: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: Safety … 

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 tech­­nisch-kom­­ple­­xen 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 zu die­sem Bei­trag: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 … 

Wei­ter­le­sen …

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

Manage­ment­zu­sam­men­fas­sung zu die­sem Bei­trag:Die FMEA — Feh­­ler-Mög­­li­ch­­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­­li­ch­­keits- und Ein­­fluss-Ana­­ly­­se (eng­lisch Fail­u­re Mode and Effects Ana­ly­sis) — ist … 

Wei­ter­le­sen …

Das V‑Modell Darstellung und Verwendung

Mana­ge­­ment-Zusam­­men­­fas­­sung zu die­sem Bei­trag:Das V‑Modell 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 → Requi­re­ments Engi­nee­ring beschrie­ben. Das V‑Modell beschreibt ein Vor­ge­hen bei der Ent­wick­lung von Soft­ware, Sys­te­men oder Pro­duk­ten, welches … 

Wei­ter­le­sen …

Use Cases Wesentlich für die Erfassung von Anforderungen

Mana­ge­­ment-Zusam­­men­­fas­­sung zu die­sem Bei­trag:Uses Cases (deutsch: Anwen­dungs­fäl­le) beschrei­ben 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 Uses 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 … 

Wei­ter­le­sen …

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

Mana­ge­­ment-Zusam­­men­­fas­­sung zu die­sem Bei­trag:Die UML (Uni­fied Mode­ling Lan­guage, 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 … 

Wei­ter­le­sen …

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), der die … 

Wei­ter­le­sen …