Die Liste-offener-Punkte (LOP) Beschreibung und Einsatz

Mana­ge­­ment-Zusam­­men­­fas­­sung die­ses Bei­trags:Die → Lis­­te-offe­­ner-Pun­k­­te ist ein Doku­ment, wel­ches häu­fig in Pro­jek­ten ein­ge­setzt wird. Es wer­den in der Lis­­te-offe­­ner-Pun­k­­te die­je­ni­gen Punk­te erfasst, die unmit­tel­bar zu erle­di­gen sind.In die­sem Bei­trag wird die Lis­­te-offe­­ner-Pun­k­­te beschrie­ben. Die Lis­­te-offe­­ner-Pun­k­­te (LOP) fin­det sich häu­fig in Pro­jek­ten und dient als eine Grund­la­ge der → Pro­jekt­steue­rung. Sie wird in der Regel bei … 

Wei­ter­le­sen …

Die 1 %-Regel Bedeutung und Verwendung

Mana­ge­­ment-Zusam­­men­­fas­­sung die­ses Bei­trags:Mit der 1 %-Regel wird beschrie­ben, dass zur Erken­nung, ob die Umset­zung eines Arbeits­pa­kets plan­mä­ßig begon­nen wur­de, ein Fer­tig­stel­lungs­grad von 1 % ver­wen­det wird.Es wird in die­sem Bei­trag die 1 %-Regel erläu­tert und der Umgang damit beschrie­ben. Ein­ord­nung:Die 1 %-Regel ist ein Teil der → Pro­jekt­steue­rung und damit auch des → Pro­jekt­con­trol­lings und … 

Wei­ter­le­sen …

Die 100 %-Regel Bedeutung und Verwendung

Mana­ge­­ment-Zusam­­men­­fas­­sung die­ses Bei­trags:Mit der 100 %-Regel wird beschrie­ben, dass in einen → Pro­jekt­struk­tur­plan (in einem Pro­jekt) 100 % der Pro­jekt­tä­tig­kei­ten erfasst wer­den müs­sen.Es wird in die­sem Bei­trag die 100 %-Regel erläu­tert und der Umgang damit beschrie­ben. Ein­ord­nung:Die 100 %-Regel ist ein Teil der → Pro­jekt­pla­nung und damit auch des → Pro­jekt­ma­nage­ments. 1. Ein­lei­tung und Grundlagen … 

Wei­ter­le­sen …

Alpha, Beta und Release Candidate Die Entwicklungsstadien von Softwarekomponenten

Mana­ge­­ment-Zusam­­men­­fas­­sung die­ses Bei­trags:Die Begrif­fe Alpha, Beta und Release Can­di­da­te wer­den im Sof­t­­wa­re-Release­­pro­­zess ver­wen­det, um das → Ent­wick­lungs­sta­di­um einer Soft­ware­kom­po­nen­te zu kenn­zeich­nen. In die­sem Bei­trag wer­den die­se drei Begrif­fe vor­ge­stellt und in den (über­ge­ord­ne­ten) Soft­ware­ent­wick­lungs­pro­zess ein­ge­ord­net. Um das Ent­wick­lungs­sta­di­um eines Soft­ware­sys­tems oder einer Soft­ware­kom­po­nen­te zu cha­rak­te­ri­sie­ren, wer­den häu­fig die Begrif­fe Alpha, Beta und Release Can­di­da­te verwendet. … 

Wei­ter­le­sen …

Projektkosten Die Projektkosten ermitteln und verwenden

Mana­ge­­ment-Zusam­­men­­fas­­sung die­ses Bei­trags:Die Pro­jekt­kos­ten sind wesent­li­ches Betrach­tungs­ele­ment in Pro­jek­ten — kein Pro­jekt wird ohne Pro­jekt­kos­ten­er­mitt­lung gestar­tet.In die­sem Bei­trag wer­den die Ermitt­lung der Pro­jekt­kos­ten und der Umgang damit beschrie­ben. Die Ermitt­lung der Pro­jekt­kos­ten (sel­ten auch als Pro­jekt­kal­ku­la­ti­on bezeich­net) ist eines der zen­tra­len The­men im → Pro­jekt­ma­nage­ment, schließ­lich reprä­sen­tie­ren die Pro­jekt­kos­ten eines der drei Ecken des → … 

Wei­ter­le­sen …

Die DEEP-Kriterien Die Qualität des Product Backlogs einschätzen

Die DEEP-Kri­­te­ri­en hel­fen dabei, zu über­prü­fen, ob ein­zel­ne Pro­duct Back­logs “gut” sind. Das Akro­nym DEEP steht für fol­gen­de vier Eigen­schaf­ten: Beim → PMI steht zu DEEP /PMG-BA17/:“Descri­bes the cha­rac­te­ristics that a pro­duct → back­log needs to demons­tra­te to be con­side­red well refi­ned. DEEP is an acro­nym that stands for detail­ed appro­pria­te­ly, esti­ma­ted, emer­gent, and prio­ri­ti­zed.“Eige­ne …

Wei­ter­le­sen …

Kostenart, Kostenstelle oder Kostenträger? Was ist der Unterschied?

Mana­ge­­ment-Zusam­­men­­fas­­sung die­ses Bei­trags:Die Begrif­fe Kos­ten­art, Kos­ten­stel­le und Kos­ten­trä­ger wer­den im betrieb­li­chen Kon­text / Con­trol­ling ver­wen­det. Doch ist die Bedeu­tung unter­schied­lich.In die­sem Bei­trag wird eine kur­ze Beschrei­bung und Abgren­zung der Begrif­fe gelie­fert. Die Begrif­fe Kos­ten­art, Kos­ten­stel­le oder Kos­ten­trä­ger kön­nen im betrieb­li­chen Kon­text auf­tau­chen und fin­den zum Teil auch beim → Pro­jekt­ma­nage­ment Anwen­dung. Sie kön­nen fol­gen­der­ma­ßen charakterisiert … 

Wei­ter­le­sen …

Typische Fehler in Projekten Häufig auftretende Fehler und deren Auswirkungen

Mana­ge­­ment-Zusam­­men­­fas­­sung die­ses Bei­trags:Eini­ge → Feh­ler in Pro­jek­ten tre­ten beson­ders häu­fig auf und füh­ren zu Pro­ble­men bei der Pro­jekt­durch­füh­rung. Wenn die­se Feh­ler aber bereits in der Ent­ste­hung erkannt wer­den, kann dies den Pro­jekt­ab­lauf und damit das Pro­jekt­er­geb­nis ver­bes­sern.In die­sem Bei­trag wer­den typi­sche Feh­ler, Feh­ler­ur­sa­chen und deren Fol­gen in Pro­jek­ten benannt. Feh­ler in Pro­jek­ten füh­ren zu ungenügenden … 

Wei­ter­le­sen …

Die Verbindlichkeit von Anforderungen und Zielen Schlüsselwörter richtig einsetzen

Mana­ge­­ment-Zusam­­men­­fas­­sung die­ses Bei­trags: Um die recht­li­che Ver­bind­lich­keit von Anfor­de­run­gen und Zie­len zu erfas­sen, wer­den in der Regel Schlüs­sel­wör­ter in Sät­zen (häu­fig über → Satz­scha­blo­nen) ver­wen­det.In die­sem Bei­trag wer­den die Schlüs­sel­wör­ter aus der Lite­ra­tur sowie in den Nor­men und Stan­dards gegen­über­ge­stellt. 1. Ein­lei­tung und Grund­la­gen Um die recht­li­che Ver­bind­lich­keit einer Anfor­de­rung oder eines Ziels fest­zu­le­gen, werden … 

Wei­ter­le­sen …

Testverfahren Vorgehen zur Erstellung von Testbedingungen, Testfällen und Testdaten bestimmen

Mana­ge­­ment-Zusam­­men­­fas­­sung die­ses Bei­trags:Test­ver­fah­ren beschrei­ben Vor­ge­hens­wei­sen beim → Soft­ware­test zur Erstel­lung von Test­be­din­gun­gen, Test­fäl­len und Test­da­ten.In die­sem Bei­trag wer­den Test­ver­fah­ren mit den ein­zel­nen Aus­prä­gun­gen vor­ge­stellt. Die Test­ver­fah­ren bestim­men das (gene­rel­le) Vor­ge­hen bei der Erstel­lung von Test­be­din­gun­gen, Test­da­ten und Test­fäl­len. Ent­spre­chend ist die Bedeu­tung für den Soft­ware­test hoch und es fin­den sich umfang­rei­che Defi­ni­tio­nen und den Normen … 

Wei­ter­le­sen …