VUCA Bedeutung und Verwendung

Das Akro­nym VUCA steht für die fol­gen­den vier eng­li­schen Begrif­fe zur Cha­rak­te­ri­sie­rung der aktu­el­len Arbeits- und Lebens­welt: Ursprüng­lich wur­de VUCA zur Beschrei­bung der ver­än­der­ten poli­ti­schen Welt­la­ge mit dem Ende des kal­ten Krie­ges in den 1990er Jah­ren ent­wi­ckelt. Es zeig­te sich jedoch, dass VUCA auch für die Cha­rak­te­ri­sie­rung der wirt­schaft­li­chen Welt geeig­net ist. In Abbil­dung 1 sind … 

Wei­ter­le­sen …

Die Wissenspyramide Der Übergang von Daten zu Wissen

Die Wis­sens­py­ra­mi­de beschreibt ein mehr­schich­ti­ges Modell zur Gene­rie­rung von Wis­sen aus Daten. Die Wis­sens­py­ra­mi­de wird sowohl dem → Wis­sens­ma­nage­ment als auch dem → Infor­ma­ti­ons­ma­nage­ment zuge­ord­net. In der Mini­mal­dar­stel­lung umfasst die Wis­sens­py­ra­mi­de drei Ebe­nen. Dies sind (Abbil­dung 1): Abbil­dung 1: Die Wis­sens­py­ra­mi­de (mini­mal) Der Über­gang von Daten zur Infor­ma­ti­on erfolgt durch inhalt­li­che Inter­pre­ta­ti­on / Seman­tik. Durch weitere … 

Wei­ter­le­sen …

Die Architekturpyramide Die Softwarearchitektur über fünf Schichten betrachten

Die Archi­tek­tur­py­ra­mi­de beschreibt ein fünf­schich­ti­ges Modell für die → Soft­ware­ar­chi­tek­tur, wel­ches unter­schied­li­che Betrach­tungs­hö­hen auf­weist. Hier­über wird ein (Informations-)System aus ver­schie­de­nen Sich­ten betrach­tet und eine Soft­ware­ar­chi­tek­tur kann abge­lei­tet wer­den. Daher wird die Archi­tek­tur­py­ra­mi­de sowohl der Dis­zi­plin Soft­ware­ar­chi­tek­tur als auch dem → Infor­ma­ti­ons­ma­nage­ment zuge­ord­net. Die fünf Schich­ten der Archi­tek­tur­py­ra­mi­de sind (Abbil­dung 1): Abbil­dung 1: Die Archi­tek­tur­py­ra­mi­de Der Einsatz … 

Wei­ter­le­sen …

Die Automatisierungspyramide Ein zentrales Modell in der industriellen Leittechnik

Die Auto­ma­ti­sie­rungs­py­ra­mi­de beschreibt ein fünf­schich­ti­ges Modell im (Maschinen-)Automatisierungskontext / in der Leit­tech­nik, über das die Daten­gra­nu­la­ri­tät und die Daten­agg­re­gie­rung (Teil-)Systemen zuge­ord­net wer­den kann. Die Auto­ma­ti­sie­rungs­py­ra­mi­de wird in die­sem Bei­trag als Teil des → Sys­tems Engi­nee­ring gese­hen. In der Wiki­pe­dia steht /#Wiki-Automatisierungspyramide/:“Die Auto­ma­ti­sie­rungs­py­ra­mi­de dient der Ein­ord­nung von Tech­ni­ken und Sys­te­men in der Leit­tech­nik und stellt die … 

Wei­ter­le­sen …

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 des → Projektmanagements. … 

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 Grund­la­gen Mit der 100 %-Regel wird … 

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 …