Das Stichwort

In der Kate­go­rie “Das Stich­wort” wer­den Ein­zel­be­grif­fe oder klei­ne­re The­men­fel­der erfasst, für die es jeweils eine eige­ne Web­sei­te (auf die­ser Web­site) mit Beschrei­bun­gen / Erläu­te­run­gen gibt.

Eine alpha­be­tisch-sor­tier­te Lis­te aller Bei­trä­ge zu die­ser Kate­go­rie fin­det sich auf der Web­sei­te → Das Stich­wort.

Abbil­dung: Ein­ord­nung der Kate­go­rie “Das Stichwort”

Projekt oder Vorhaben? Was ist der Unterschied?

Mana­ge­­ment-Zusam­­men­­fas­­sung die­ses Bei­trags:Die Begrif­fe Pro­jekt und Vor­ha­ben wer­den häu­fig syn­onym benutzt. Im Pro­jekt­ma­nage­ment wie auch im Requi­re­ments Engi­nee­ring ist eine Unter­schei­dung aber wesent­lich.In die­sem Bei­trag wird eine Kurz­dar­stel­lung zur Klä­rung der Begrif­fe gelie­fert. Pro­jekt und Vor­ha­ben? Für das Pro­jekt­ma­nage­ment ist die Unter­schei­dung zwi­schen Pro­jekt und Vor­ha­ben wesent­lich. Wäh­rend ein Vor­ha­ben “etwas mehr als eine Idee” … 

Wei­ter­le­sen …

Iterativ oder inkrementell? Was ist der Unterschied?

Mana­ge­­ment-Zusam­­men­­fas­­sung die­ses Bei­trags:Die Begrif­fe ite­ra­tiv und inkre­men­tell wer­den im Soft­ware Engi­nee­ring und im Requi­re­ments Engi­nee­ring ver­wen­det. Auch wenn bei­de Begrif­fe häu­fig zusam­men genutzt wer­den, so soll­te der Unter­schied den­noch bekannt sein.In die­sem Bei­trag wird eine Beschrei­bung der bei­den Begrif­fe gelie­fert. Die bei­den Begrif­fe kön­nen fol­gen­der­ma­ßen cha­rak­te­ri­siert wer­den: In der Wiki­pe­dia steht zur Ite­ra­ti­on /#Wiki-Iteration/:“Ite­ra­ti­on (von …

Wei­ter­le­sen …

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 …

Liste, Register oder Matrix? Was ist der Unterschied?

Mana­ge­­ment-Zusam­­men­­fas­­sung die­ses Bei­trags:Die sprach­li­che Unter­schei­dung von Lis­te, Regis­ter und Matrix im Pro­jekt­ma­nage­ment soll­te vor Pro­jekt­start vor­ge­nom­men wer­den, um Klar­heit zu schaf­fen.In die­sem Bei­trag wird eine kur­ze Beschrei­bung der Begrif­fe gelie­fert. Gene­rell soll­te zwi­schen einer Lis­te, einem Regis­ter oder einer Matrix in einem The­men­be­reich unter­schie­den wer­den, um so für Klar­heit bei den Betei­lig­ten zu sor­gen. Die … 

Wei­ter­le­sen …

Die Projektumfeldanalyse Übergreifend den gesamten Kontext des Projekts betrachten

Bei der Pro­jekt­um­feld­ana­ly­se (abge­kürzt: PUMA oder PUA, auch als Umwelt­ana­ly­se bezeich­net) wird über­grei­fend der gesam­te Kon­text des Pro­jekts betrach­tet, um so Stake­hol­der zu benen­nen und zu klas­si­fi­zie­ren. 1. Beschrei­bung Die DIN 69901–5:2009 defi­niert /DIN20/:“Pro­jekt­um­feld — pro­ject envi­ron­ment: Umfeld, in dem das Pro­jekt ent­steht und durch­ge­führt wird.” In der Wiki­pe­dia steht zu den Zie­len der Pro­jekt­um­feld­ana­ly­se (fett …

Wei­ter­le­sen …

Mission oder Vision? Was ist der Unterschied?

Mana­ge­­ment-Zusam­­men­­fas­­sung die­ses Bei­trags:Die Begrif­fe Mis­si­on und Visi­on wer­den häu­fig ver­wech­selt. Im Manage­ment und in der Orga­ni­sa­ti­ons­leh­re ist eine genaue Unter­schei­dung aber wesent­lich.In die­sem Bei­trag wird eine Kurz­dar­stel­lung zur Unter­schei­dung der Begrif­fe gelie­fert. Mis­si­on und Visi­on sind für Unter­neh­men (und Orga­ni­sa­tio­nen) von gro­ßer Bedeu­tung, denn aus (gut for­mu­lier­ten) Mis­sio­nen und Visio­nen kön­nen Zie­le, Pro­jek­te und Produkte … 

Wei­ter­le­sen …

Satzschablonen Das Formulieren von Anforderungen mit Schablonen

Mana­ge­­ment-Zusam­­men­­fas­­sung die­ses Bei­trags:Satz­scha­blo­nen sind ein Hilfs­mit­tel, um Ein­zel­an­for­de­run­gen so zu struk­tu­rie­ren und zu for­mu­lie­ren, dass sie eine hohe Qua­li­tät auf­wei­sen.In die­sem Bei­trag wer­den Satz­scha­blo­nen und deren Ein­satz im Requi­re­ments Engi­nee­ring beschrie­ben. Satz­scha­blo­nen (auch Anfor­de­rungs­scha­blo­nen, eng­lisch Phra­se Tem­pla­tes oder Requi­re­ment Tem­pla­tes) die­nen der natür­lich­sprach­li­chen Erfas­sung von (ein­zel­nen) Anfor­de­run­gen. Durch den Ein­satz von Satz­scha­blo­nen erhal­ten die Formulierungen … 

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 …

Die Komfortzone Warum die Komfortzone nicht ideal ist

Mana­ge­­ment-Zusam­­men­­fas­­sung die­ses Bei­trags:Die Kom­fort­zo­ne bezeich­net einen Bereich, in dem sich ein Mensch aus­ge­gli­chen bewegt, da (von außen) kei­ne Ände­rungs­not­wen­dig­keit besteht. Aller­dings sind in der Kom­fort­zo­ne kaum Wei­ter­ent­wick­lun­gen mög­lich.In die­sem Bei­trag wird eine kur­ze Beschrei­bung der Kom­fort­zo­ne mit dem Kom­­for­t­­zo­­nen-Modell und der Kom­­for­t­­zo­­nen-Matrix gelie­fert. 1. Beschrei­bung Jeder ein­zel­ne Mensch ist bestrebt, in sei­nem Umfeld aus­ge­gli­chen zu … 

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 …