|
DataMuseum.dkPresents historical artifacts from the history of: RegneCentralen RC850 |
This is an automatic "excavation" of a thematic subset of
See our Wiki for more about RegneCentralen RC850 Excavated with: AutoArchaeologist - Free & Open Source Software. |
top - metrics - download
Length: 5376 (0x1500)
Types: RcTekst, TextFile
Names: »CORN165.WP«
└─⟦1ce066637⟧ Bits:30005845 Dokumenter - Per Cornelius #135 - #236
└─⟦this⟧ »CORN165.WP«
╱04002d4e0a000600000000020a5031000000000000000000000000000000000000000000000000000e18222c36404a545e68727c86909aff04╱
corn afd. nr. 12 85.10.15 edb.corn.165↲
↲
↲
↲
TIL BAL: MRH, NMN, HLJ, JEKK.↲
↲
↲
TIL ÅRH: HCH.↲
↲
↲
↲
┆a1┆┆b0┆PROJEKT: 121053 ÆNDRING AF BRUGERKATALOG I TIMEREG.↲
↲
↲
↲
┆a1┆1. EDB-DRIFTS OPERATØRER.↲
↲
Brugerkategorien operatører vil ikke blive omtalt yderligere,↲
idet vi går ud fra UÆNDRET status for edb-drifts operatører med↲
tilladelse til opstart, nedlukning og tvangslukning.↲
↲
↲
┆a1┆2. BRUGERKATALOGET I DAG.↲
↲
Brugerkataloget til TIMEREG er i dag det almindelige SOS-bruger-↲
katalog, hvor TIMEREG fortolker et felt ( der af andre systemer↲
bruges til noget andet) til at afgøre om en bruger er↲
↲
1. priviligeret ( operatør),↲
2. med timeseddelrettigheder,↲
3. andre brugere.↲
↲
Vi kan ikke teste på brugerens lokation, det vil sige BAL, GLO, ODE,↲
PA eller ÅRH, og heller ikke teste på brugerens afdelingsnunmmer.↲
↲
Bemærk at en bruger i afdeling X kan foretage registreringer, der↲
angår afdeling Y.↲
↲
↲
┆a1┆3. ÆNDRINGS ØNSKET.↲
↲
Ændringen går ud på at projektledere i Århus må vedligeholde↲
projektoplysninger som plantimer og vurderet resttid via kom-↲
mandoen PPL (vedligehold projekt status) samt har adgang til↲
til forespørgsler og oversigter.↲
↲
Projektlederne skal IKKE have adgang til stamdata for projekt-↲
ter og aktiviteter, det vil sige oprettelse, ændring, sletning,↲
lukning/åbning samt opret/slet forbindelse afdeling projekt.↲
↲
┆b0┆Dette skal dog ikke gælde projektledere udenfor Århus.↲
↲
Ved 'projektledere' skal der i denne forbindelse forståes enhver,↲
der i TIMEREG opretter projekter med felt 2 p-leder = sine egne↲
initialer, uanset om projektet gælder for manuelt- eller edb-arbejde.↓
════════════════════════════════════════════════════════════════════════
↓
↲
↲
┆a1┆4. FORSLAG A.↲
↲
Går ud på at vi har 'en markering' på projektledere fra ÅRH, og at↲
vi kun tillader brugen af kommando PPL (vedligehold projekt status)↲
for disse medarbejdere.↲
↲
↲
┆a1┆5. FORSLAG B.↲
↲
Går ud på at vi i brugerkataloget opretter 1 brugerkategori mere,↲
samt ændrer test ved kommandoerne til disse kategorier.↲
↲
Kategori 0 = priviligeret (operatør)↲
↲
Kategori 1 = afdelingssekretærer der har adgang til alle↲
kommandoer medregnet timeseddel, ↲
og uden begrænsning for afdelingsområde.↲
↲
Kategori 2 = Brugere med adgang til kommandoer som i dag,↲
men ikke adgang til timeseddel,↲
og uden begrænsning for afdelingsområde.↲
↲
Kategori 3 = projektledere med adgang til PPL (vedligehold↲
projekt status) og forespørgsler og oversigter,↲
og uden begrænsning for afdelingsområde.↲
↲
┆b0┆SE BILAG: forslag B side 1 & 2, + er tilladt, - ikke tilladt.↲
↲
↲
┆a1┆6. FORSLAG C.↲
↲
Går ud på at vi i brugerkataloget opretter 5 brugerkategorier,↲
og indfører afdelings-områder, samt ændrer test ved kommandoerne↲
til disse kategorier og tester for afdelings-området.↲
↲
Et afdelingsområde kan være en eller flere afdelinger.↲
↲
Kategori 0 = priviligeret (operatør)↲
↲
Kategori 1 = lønningskontoret der har adgang til alle kommandoer↲
og ingen begrænsning for afdelingsområder.↲
↲
Kategori 2 = afdelingssekretærer der har adgang til alle↲
kommandoer medregnet timeseddel,↲
og begrænset til et afdelingsområde.↲
↲
Kategori 3 = brugere med adgang til kommandoer som i dag,↲
men ikke adgang til timeseddel,↲
og begrænset til et afdelingsområde.↲
↲
Kategori 4 = projektledere med adgang til PPL (vedligehold↲
projekt status) og forespørgsler og oversigter,↲
og begrænset til et afdelingsområde.↲
↲
Kategori 5 = øvrige brugere med adgang til forespørgsler og↲
oversigter begrænset til et afdelingsområde.↲
↲
┆b0┆SE BILAG: forslag C side 1 & 2, + er tilladt, - ikke tilladt.↲
════════════════════════════════════════════════════════════════════════
↓
↲
↲
┆a1┆7. FORSLAG D.↲
↲
En hurtig midlertidig måde at løse problemet på er at udskrive↲
projektstatus fra time batch systemet. Projektlederne retter så↲
plantimer og vurderet rest på papiret, og sekretærerne foretager ↓
den egentlige online vedligeholdelse.↲
↲
Slet projektlederne fra timereg online brugerkatalog.↲
↲
↲
┆a1┆8. LØSNINGS MULIGHED.↲
↲
↲
Forslag A kan ┆a1┆IKKE┆e1┆ lade sig gøre.↲
↲
↲
Forslag B kan relativt let lade sig gøre, idet vi kan benytte det↲
allerede eksisterende SOS-brugerkatalog, og blot fortolke tallene↲
på en anden måde.↲
↲
Vi kan ikke teste på brugerens lokation.↲
↲
↲
Forslag C kræver ┆a1┆to samtidige brugerkataloger┆e1┆, idet der ikke ind-↲
lægges yderligere oplysninger i SOS-brugerkataloget.↲
(SOS-brugerkataloget skal bibeholdes.)↲
↲
↲
Forslag D er ikke en medarbejderværdig løsning, det er trods alt↲
betydelig bedre at kunne rette direkte på skærmen og se resultatet↲
med det samme.↲
↲
↲
↲
I vurderingen af forslag B og C bør indgå:↲
------------------------------------------↲
↲
HVOR hurtigt skal det laves, d.v.s. hvor meget tid kan vi få↲
til programmeringen ?↲
↲
HVAD skal der ellers ændres i systemet, og hvordan er række-↲
følgen (= prioriteringen ) ?↲
↲
HVILKEN datasikkerhed kræver RC i dette system ? ↲
↲
HVORDAN bruges systemet i almindelighed om et halvt år, et↲
helt år med hensyn til tidsregistrering som ferie, flex, over↲
arbejde, fravær af forskellig art og med hensyn til projekt-↲
styring ?↲
↲
↲
↲
m.v.h.↲
↲
HAV/CORN↲
┆1a┆┆1a┆↲
styring ?↲
↲
↲
↲
m.v.h.↲
↲
HAV/CORN↲
↓
┆1a┆/CORN↲
↓
┆1a┆N↲
↓
┆1a┆↲
↲
↲
↲
m.v.h.↲
↲
HAV/COR
B▶02◀N▶04◀-N
▶06◀▶02◀
P1▶0e◀▶18◀",6@JT^hrø▶86◀▶90◀▶9a◀▶ff◀▶04◀corn afd. nr. 12 85.10.15 edb.corn.165
TIL BAL: MRH, NMN, HLJ, JEKK.
TIL ÅRH: HCH.
▶a1◀▶b0◀PROJEKT: 121053 ÆNDRING AF BRUGERKATALOG I TIMEREG.
▶a1◀1. EDB-DRIFTS OPERATØRER.
Brugerkategorien operatører vil ikke blive omtalt yderligere,
idet vi går ud fra UÆNDRET status for edb-drifts operatører med
tilladelse til opstart, nedlukning og tvangslukning.
▶a1◀2. BRUGERKATALOGET I DAG.
Brugerkataloget til TIMEREG er i dag det almindelige SOS-bruger-
katalog, hvor TIMEREG fortolker et felt ( der af andre systemer
bruges til noget andet) til at afgøre om en bruger er
1. priviligeret ( operatør),
2. med timeseddelrettigheder,
3. andre brugere.
Vi kan ikke teste på brugerens lokation, det vil sige BAL, GLO, ODE,
PA eller ÅRH, og heller ikke teste på brugerens afdelingsnunmmer.
Bemærk at en bruger i afdeling X kan foretage registreringer, der
angår afdeling Y.
▶a1◀3. ÆNDRINGS ØNSKET.
Ændringen går ud på at projektledere i Århus må vedligeholde
projektoplysninger som plantimer og vurderet resttid via kom-
mandoen PPL (vedligehold projekt status) samt har adgang til
til forespørgsler og oversigter.
Projektlederne skal IKKE have adgang til stamdata for projekt-
ter og aktiviteter, det vil sige oprettelse, ændring, sletning,
lukning/åbning samt opret/slet forbindelse afdeling projekt.
▶b0◀Dette skal dog ikke gælde projektledere udenfor Århus.
Ved 'projektledere' skal der i denne forbindelse forståes enhver,
der i TIMEREG opretter projekter med felt 2 p-leder = sine egne
initialer, uanset om projektet gælder for manuelt- eller edb-arbejde.
\f
▶83◀▶b8◀
▶a1◀4. FORSLAG A.
Går ud på at vi har 'en markering' på projektledere fra ÅRH, og at
vi kun tillader brugen af kommando PPL (vedligehold projekt status)
for disse medarbejdere.
▶a1◀5. FORSLAG B.
Går ud på at vi i brugerkataloget opretter 1 brugerkategori mere,
samt ændrer test ved kommandoerne til disse kategorier.
Kategori 0 = priviligeret (operatør)
Kategori 1 = afdelingssekretærer der har adgang til alle
kommandoer medregnet timeseddel,
og uden begrænsning for afdelingsområde.
Kategori 2 = Brugere med adgang til kommandoer som i dag,
men ikke adgang til timeseddel,
og uden begrænsning for afdelingsområde.
Kategori 3 = projektledere med adgang til PPL (vedligehold
projekt status) og forespørgsler og oversigter,
og uden begrænsning for afdelingsområde.
▶b0◀SE BILAG: forslag B side 1 & 2, + er tilladt, - ikke tilladt.
▶a1◀6. FORSLAG C.
Går ud på at vi i brugerkataloget opretter 5 brugerkategorier,
og indfører afdelings-områder, samt ændrer test ved kommandoerne
til disse kategorier og tester for afdelings-området.
Et afdelingsområde kan være en eller flere afdelinger.
Kategori 0 = priviligeret (operatør)
Kategori 1 = lønningskontoret der har adgang til alle kommandoer
og ingen begrænsning for afdelingsområder.
Kategori 2 = afdelingssekretærer der har adgang til alle
kommandoer medregnet timeseddel,
og begrænset til et afdelingsområde.
Kategori 3 = brugere med adgang til kommandoer som i dag,
men ikke adgang til timeseddel,
og begrænset til et afdelingsområde.
Kategori 4 = projektledere med adgang til PPL (vedligehold
projekt status) og forespørgsler og oversigter,
og begrænset til et afdelingsområde.
Kategori 5 = øvrige brugere med adgang til forespørgsler og
oversigter begrænset til et afdelingsområde.
▶b0◀SE BILAG: forslag C side 1 & 2, + er tilladt, - ikke tilladt.
\f
▶83◀▶e0◀
▶a1◀7. FORSLAG D.
En hurtig midlertidig måde at løse problemet på er at udskrive
projektstatus fra time batch systemet. Projektlederne retter så
plantimer og vurderet rest på papiret, og sekretærerne foretager
den egentlige online vedligeholdelse.
Slet projektlederne fra timereg online brugerkatalog.
▶a1◀8. LØSNINGS MULIGHED.
Forslag A kan ▶a1◀IKKE▶e1◀ lade sig gøre.
Forslag B kan relativt let lade sig gøre, idet vi kan benytte det
allerede eksisterende SOS-brugerkatalog, og blot fortolke tallene
på en anden måde.
Vi kan ikke teste på brugerens lokation.
Forslag C kræver ▶a1◀to samtidige brugerkataloger▶e1◀, idet der ikke ind-
lægges yderligere oplysninger i SOS-brugerkataloget.
(SOS-brugerkataloget skal bibeholdes.)
Forslag D er ikke en medarbejderværdig løsning, det er trods alt
betydelig bedre at kunne rette direkte på skærmen og se resultatet
med det samme.
I vurderingen af forslag B og C bør indgå:
------------------------------------------
HVOR hurtigt skal det laves, d.v.s. hvor meget tid kan vi få
til programmeringen ?
HVAD skal der ellers ændres i systemet, og hvordan er række-
følgen (= prioriteringen ) ?
HVILKEN datasikkerhed kræver RC i dette system ?
HVORDAN bruges systemet i almindelighed om et halvt år, et
helt år med hensyn til tidsregistrering som ferie, flex, over
arbejde, fravær af forskellig art og med hensyn til projekt-
styring ?
m.v.h.
HAV/CORN
«eof»