Systems Engineering

Pilot oder Prototyp? Was ist der Unterschied?

Mana­ge­­ment-Zusam­­men­­fas­­sung zu die­sem Bei­trag:Die Begrif­fe Pilot und Pro­to­typ wer­den im Sys­tems oder → Soft­ware Engi­nee­ring und in der Soft­ware­ent­wick­lung benutzt.In die­sem Bei­trag wird eine Beschrei­bung der bei­den Begrif­fe gelie­fert. Die bei­den Begrif­fe kön­nen im Sof­t­­wa­re­en­t­­wick­­lungs- / Sof­t­­wa­re-Engi­nee­­ring-Kon­­text fol­gen­der­ma­ßen cha­rak­te­ri­siert wer­den: Pilot: Erst­an­wen­dung, die dazu dient, ein fer­ti­ges Sys­tem zu über­prü­fen und in eine Vor­se­rie gehen … 

Wei­ter­le­sen …

Konfigurationsmanagement Die zentrale Disziplin zur Zusammenfassung von Produkt- oder Projekteinheiten

Mana­ge­­ment-Zusam­­men­­fas­­sung zu die­sem Bei­trag:Das Kon­fi­gu­ra­ti­ons­ma­nage­ment ist eine zen­tra­le Dis­zi­plin zur Erfas­sung und Zusam­men­stel­lung ver­schie­den­ar­ti­ger Arte­fak­te, um die­se als Ein­heit zu ver­wal­ten.In die­sem Bei­trag wird das Kon­fi­gu­ra­ti­ons­ma­nage­ment beschrie­ben. Das Kon­fi­gu­ra­ti­ons­ma­nage­ment fin­det sich in ver­schie­de­nen Dis­zi­pli­nen wie­der; dies sind ins­be­son­de­re: Pro­dukt­ma­nage­ment → Pro­jekt­ma­nage­ment → Soft­ware Engi­nee­ring → Sys­tems Engi­nee­ring → Requi­re­ments Engi­nee­ring IT Ser­vice Manage­ment (ITSM) → …

Wei­ter­le­sen …

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 …