Software Engineering

Änderungsmanagement Änderungen systematisch dokumentieren, bewerten, genehmigen, verfolgen und umsetzen

Mana­ge­­ment-Zusam­­men­­fas­­sung die­ses Bei­trags:Das Ände­rungs­ma­nage­ment beschäf­tigt sich mit Pro­zes­sen und Metho­den, um Ände­run­gen am Pro­dukt­in­halt oder ‑umfang in ein Pro­jekt, ein Pro­dukt oder ein Requi­­re­­ments-→ Vor­ha­ben ein­zu­brin­gen. Es wird in die­sem Bei­trag das Ände­rungs­ma­nage­ment beschrie­ben. Ände­run­gen an Pro­duk­ten (in Pro­jek­ten) sind im → Sys­tems Engi­nee­ring (über den Pro­dukt­le­bens­zy­klus) der Nor­mal­fall. Auch wenn es wün­schens­wert ist, die … 

Wei­ter­le­sen …

Größe, Zahlenwert und Einheit Zusammenhang und Darstellung

Mana­ge­­ment-Zusam­­men­­fas­­sung die­ses Bei­trags:Grö­ße, Zah­len­wert und Ein­heit gehö­ren bei der Dar­stel­lung eines phy­si­ka­li­schen Para­me­ters zusam­men.In die­sem Bei­trag wird eine Kurz­dar­stel­lung des Zusam­men­hangs die­ser drei Begrif­fe gelie­fert. 1. Beschrei­bung In der Wiki­pe­dia steht zur phy­si­ka­li­schen Grö­ße /#Wiki-Physikalische-Größe/: “Eine phy­si­ka­li­sche Grö­ße ist eine an einem Objekt der Phy­sik → quan­ti­ta­tiv bestimm­ba­re Eigen­schaft eines Vor­gangs oder Zustands. Bei­spie­le solcher … 

Wei­ter­le­sen …

Restaurieren oder renovieren? Was ist der Unterschied?

Mana­ge­­ment-Zusam­­men­­fas­­sung die­ses Bei­trags:Die Begrif­fe restau­rie­ren und reno­vie­ren sind ähn­lich, haben aber leicht unter­schied­li­che Bedeu­tun­gen.In die­sem Bei­trag wird eine Kurz­dar­stel­lung zur Unter­schei­dung der Begrif­fe gelie­fert. Die bei­den Begrif­fe kön­nen im Mana­ge­­ment-Kon­­­text fol­gen­der­ma­ßen cha­rak­te­ri­siert wer­den: Die Wiki­pe­dia schreibt zur Restau­rie­rung /#Wiki-Restaurierung/:“Als Restau­rie­rung bezeich­net man bei Kul­tur­gü­tern die Wie­der­her­stel­lung eines alten Zustands, wel­cher oft im Lau­fe der Zeit … 

Wei­ter­le­sen …

T‑Shirt-Größen Relative Größenangaben für das Schätzen

Mana­ge­­ment-Zusam­­men­­fas­­sung die­ses Bei­trags:T‑Shirt-Grö­ßen (eng­lisch: T‑Shirt-Sizes) kön­nen beim → Schät­zen hel­fen, die Grö­ßen­ord­nung eines Betrach­tungs­ele­ments zu erfas­sen.In die­sem Bei­trag wer­den die T‑Shirt-Grö­­ßen und deren Ver­wen­dung beschrie­ben. Beim Agi­len Schät­zen kön­nen T‑Shirt-Grö­­ßen zum Ein­satz kom­men, aber die Ver­wen­dung der T‑Shirt-Grö­­ßen ist auch außer­halb der agi­len Welt mög­lich.  1. Beschrei­bung Das → Scrum-→ Glos­sar schreibt zu den T‑Shirt-Grö­­ßen …

Wei­ter­le­sen …

Fehlverhalten oder Fehlerverhalten? Was ist der Unterschied?

Mana­ge­­ment-Zusam­­men­­fas­­sung die­ses Bei­trags:Die Begrif­fe Fehl­ver­hal­ten und Feh­ler­ver­hal­ten wer­den im → Qua­li­täts­ma­nage­ment und beim → Soft­ware­test ver­wen­det.In die­sem Bei­trag wird eine Beschrei­bung der bei­den Begrif­fe gelie­fert. Die Begrif­fe Fehl­ver­hal­ten oder Feh­ler­ver­hal­ten wer­den in der Pro­jekt­durch­füh­rung / im → Pro­jekt­ma­nage­ment, beim Qua­li­täts­ma­nage­ment und beim Soft­ware­test benutzt. Bei­de Begrif­fe fin­den sich jedoch nicht in dem → Glos­sar des … 

Wei­ter­le­sen …

Softwarekosten Die Kosten der Software über die gesamte Lebenszeit erfassen

Die Kos­ten einer Soft­ware soll­te gene­rell ermit­telt wer­den, um so sicher­zu­stel­len, dass das Kos­­ten-Nut­­zen-Ver­­häl­t­­nis gut genug ist. Dabei müs­sen die sowohl die Kos­ten für die → Soft­ware­ent­wick­lung (Kos­ten für das → Soft­ware Engi­nee­ring) als auch die Soft­ware­kos­ten über den gesam­ten Pro­dukt­le­bens­zy­klus (von der Idee über den Betrieb bis zum Lebens­en­de der Soft­ware) betrach­tet wer­den. Abbil­dung 1 … 

Wei­ter­le­sen …

Entwicklung, Ermittlung oder Erstellung? Was ist der Unterschied?

Mana­ge­­ment-Zusam­­men­­fas­­sung die­ses Bei­trags:Die Begrif­fe Ent­wick­lung, Ermitt­lung und Erstel­lung wer­den im → Requi­re­ments Engi­nee­ring ver­wen­det, wo sie häu­fig ver­wech­selt wer­den.In die­sem Bei­trag wird eine kur­ze Beschrei­bung und Abgren­zung die­ser drei Begrif­fe gelie­fert. Die Begrif­fe Ent­wick­lung, Ermitt­lung und Erstel­lung wer­den beim Requi­re­ments Engi­nee­ring im Zusam­men­hang mit Anfor­de­run­gen / Requi­re­ments genutzt. Sie kön­nen fol­gen­der­ma­ßen cha­rak­te­ri­siert wer­den: Im → … 

Wei­ter­le­sen …

Die 18 Wissensgebiete des Software Engineerings nach IEEE Einordnung aller relevanten Themen zum Software Engineering

Das IEEE (Insti­tu­te of Elec­tri­cal and Elec­tro­nics Engi­neers) unter­teilt das → Soft­ware Engi­­nee­ring-Know-how in 18 → Wis­sens­ge­bie­te (engl. Know­ledge Are­as), die im SWEBOK (“Gui­de to the Soft­ware Engi­nee­ring Body of Know­ledge”) /SWEBOK24, *SWEBOK-24/ beschrie­ben wer­den. Die 18 Wis­sens­ge­bie­te sind (Abbil­dung 1): Abbil­dung 1: Die Wis­sens­ge­bie­te des Soft­ware Engi­nee­rings nach IEEE /SWEBOK24/ Beson­der­hei­ten die­ser Ein­tei­lung durch das … 

Wei­ter­le­sen …

Parametrieren oder Parametrisieren? Was ist der Unterschied?

Mana­ge­­ment-Zusam­­men­­fas­­sung die­ses Bei­trags:Die Begrif­fe Para­me­trie­ren und Para­me­tri­sie­ren wer­den im Sys­tems oder → Soft­ware Engi­nee­ring sowie in der → Soft­ware­ent­wick­lung benutzt.In die­sem Bei­trag wird eine Beschrei­bung der bei­den Begrif­fe gelie­fert. Hin­weis:Die Defi­ni­ti­on der Begrif­fe ist in der Lite­ra­tur nicht ein­deu­tig. Daher wird hier mei­ne Inter­pre­ta­ti­on der Begrif­fe vor­ge­stellt, die durch­gän­gig in allen mei­nen Bei­trä­gen und → … 

Wei­ter­le­sen …

Nicht-funktionale Anforderungen Wichtig und häufig unterschätzt

Mana­ge­­ment-Zusam­­men­­fas­­sung die­ses Bei­trags:Unter nicht-fun­k­­tio­na­­len Anfor­de­run­gen (abge­kürzt: NFAs, sel­te­ner NFAen, eng­lisch: Non-fun­c­­ti­on­al Requi­re­ments — NFRs) wer­den Anfor­de­run­gen ver­stan­den, die sich aus tech­ni­schen Erfor­der­nis­sen und Rand­be­din­gun­gen erge­ben und kei­ne funk­tio­na­len Anfor­de­run­gen dar­stel­len.In die­sem Bei­trag wer­den die nicht-fun­k­­tio­na­­len Anfor­de­run­gen beschrie­ben. Anfor­de­run­gen wer­den im → Requi­re­ments Engi­nee­ring in funk­tio­na­le und nicht-fun­k­­tio­na­­le Anfor­de­run­gen (NFAs) unter­teilt (Abbil­dung 0.1). Funk­tio­na­le Anfor­de­run­gen beschreiben … 

Wei­ter­le­sen …