Konceptuelle grundtræk:

Jeg skritsere hermed lige en hurtig plan for den ide vi pt. hælder mod efter vi har fået Camilla med i gruppen:

Ideen kom sig af at jeg fornyligt skulle aftale et møde med freeway. Det vil sige vi skulle finde en dato hvor 8 mennesker havde tid til at mødes:

Jeg tror at vi sendte 20 mails frem og tilbage med forslag, men det kunne IKKE lade sig gøre!

Efter langt tids søgning fandt jeg et system der kunne løse opgaven:

Grundlæggende fungerer det ved at du kan oprette et møde med en titel, vælge alle de dage DU kan, og så bede de andre om at krydse de dage af som de kan.

Så står alle derinde med navne, og hvilke dage de kan.

Og så lister programmet så de dage op hvor alle kan.

Det er super simpelt, Men ENORMT givtigt!

Vi fandt på den måde en dato inden for 5 minutter

Problemet er bare at det nævnte system, var så dårligt og grimt lavet;

Jeg har derfor foreslået at vi laver en ny af slagsen:

Opgaven er tilpas konceptuel til at være MEGET interessant, men alligevel simpel nok til at det kan udføres under de rammer der er givet.

sql sikkerhed

Hvis man har valgt at bruge push modellen, og dermed besluttet at udvikleren manuelt skal hente
data fra databasen og at det er op til backend-delen af applikationen at oprette forbindelse til
database og håndtere eventuelle sikkerheds problemet. Hvis man derimod anvender Pull-modellen
skal man være opmærksom på nogle sikkerheds problemer.

Et par gode kilder mere

Appelt, W.: WWW Based Collaboration with the BSCW System, in Proceedings of SOFSEM’99,
Springer Lecture Notes in Computer Science 1725, p.66-78; November 26 – December 4, Milovy
(Czech Republic)
Bentley, R., T. Horstmann, and J. Trevor, The World Wide Web as enabling technology for CSCW: The
case of BSCW. Computer Supported Cooperative Work: The Journal of Computer-Supported
Cooperative Work, 1997. 6(2-3): p. 111-134.
Dix, Alan Challenges for Cooperative Work on the Web: An Analytical Approach Computer Supported
Cooperative Work: The Journal of Computer-Supported Cooperative Work, 1997. 6(2-3): p.:135-
156
L. Garton and B. Wellman, 1995. “Social Impacts of Electronic Mail Organizations: A Review of the
Research Literature,” Communication Yearbook, volume 18, pp. 434-453.
Giddens, Anthony The Constitution of Society Berkeley University of California Press 1984
Greenberg S. and Roseman, M. Using a Room Metaphor to Ease Transitions in Groupware. Research
report 98/611/02, Department of Computer Science, University of Calgary, Alberta, Canada, 1998
Hamilton, Anne Metaphors in theory and practice: the influence of metaphors on expectations ACM
Journal of Comuter Documentation 2000 vol. 24 No. 4
Orlikowski, W.J. 1992b. The Duality of Technology: Rethinking the Concept of Technology in
Organizations. Organization Science, Vol. 3, No. 3, 1992, pp. 398-427.
Orlikowski, W.J. and Yates, J. (1994) Genre repertoire: norms and forms for work and interaction.
MIT Sloan School Working Paper 3671-94; Centre for Coordination Science Technical Report 166,
March. MIT, Cambridge MA
Shipman, F. and Marshall, C. Formality Considered Harmful: Experiences, Emerging Themes, and
Directions on the Use of Formal Representations in Interactive Systems Computer Supported
Cooperative Work: The Journal of Computer-Supported Cooperative Work, 1999. 8 (4):333-352
Yates, J. and W. Orlikowski, “Genres of Organizational Communication: A Structurational Approach
to Studying Communication and Media,” Academy of Management Review, Vol. 17, Iss. 2, pp.
299-326, 1992
H. Ishii. Teamworkstation: Towards a seamless shared workspace. In CSCW ‘90 Proceedings, pages
13 — 26. ACM SIGCHI SIGOIS, 1990

Checkliste til planlægning af visuel kommunikation på vores website

Eksplicit afsender
(Afsenderens intention med websitet)
1. Hvad vil afsenderen med sit website?

Implicit afsender
(Den ekspressive og de emotive funktioner)
2. Hvilke signaler og følelser vil afsender udtrykke om sig selv i websitet?
3. Hvilke visuelle og kommunikative virkemidler kan vi bruge til at formidle de signaler? (Komposition/layout, farver og deres sammensætning, motivvalg, illustrationer, typografiske valg, stemningsskabende udtryk, bevægelser, gestalter, etos, logos, pathos….)

Eksplicit modtager
(Undersøgelser af den kognitive, den konative og den emotionelle reception)
4. Hvordan skal websitet testes på målgruppen? (For at undersøge om målgruppen forstår websitet; om målgruppen kan finde rundt, om de ønskede signaler om afsender bliver formidlet)
5. Hvordan skal det testes om de faktiske brugere anvender websitet som planlagt, når websitet er taget i brug? (weblog, on-linespørgeskemaer…..)

Implicit modtager
(Den konative og de interaktive funktioner)
6. Har vi identificeret målgruppen?
7. Hvordan gør vi websitet nemt at orientere sig i og bruge for målgruppen?
8. Har vi tænkt over hvilke vigtige handlinger, vi gerne vil have brugeren til at gennemføre på websitet? (find, tilmeld, køb, stem, kommuniker….)
9. Hvordan kan vi bedst styre brugeren hen imod de handlinger, vi gerne vil have dem til at gennemføre?
10. Hvilken form for interaktion er absolut nødvendig? (Transmission, konversation, konsultation, transaktion, registrering)
11. Hvilke andre interaktionsformer kunne gøre websitet endnu mere attraktivt for afsender og/eller målgruppe?
12. Hvilke følelser skal websitet bibringe målgruppen?
13. Hvordan kan de følelser skabes?
14. Hvilke web-bruger-typer skal vi understøtte og hvordan? (Førstegangs-webbrugeren, den erfarne webbruger, websurferen og den internationale webbruger)
Produktet
(Den formale og den uudsigelige æstetiske funktion)
15. Hvordan gør vi websitet endnu mere kreativt, visuelt, lækkert?
16. Hvordan kan vi give målgruppen en større, bedre, anderledes, uventet – en ”jeg ved ej hvad-oplevelse”?
Konteksten
(Den referentielle og den intertekstuelle funktion)
17. Hvordan gør vi websitet let at komme i gang med at bruge?
18. Hvordan skal websitet ligne eller adskille sig fra andre af virksomhedens visuelle udtryk/figurer/slogans…. Eller fra andre lignende websites/medier?
Mediet
(Den fatiske og den navigative funktion)
19. Hvordan holder vi kontakten mellem websitet og brugeren og skaber oplevelsen af en rød tråd i websitet/ eller websitets dele (genkendeligt layout, design, typografi, farver, figurer)
20. Hvilke menu- og navigationsformer skal websitet have? (Funktionel, udforskende, narrativ, legende…)
21. Hvilken underliggende navigationsstruktur/informationsstruktur eller kombination af strukturer skal websitet anvende? (sekvens-, gitter-, hierarki-, hypertekststruktur)

Koden
(Den metakommunikative og den intersemiotiske funktion)
22. Hvilke billeder/motiver/andre elementer der refererer ud over websitet og giver særlige associationer (fra myter, legender, religiøse skrifter fx) kan evt. bruges til at understøtte/forstærke/visualisere de signaler og det budskab, der skal formidles?
23. Hvordan skal de visuelle elementer understøtte hinanden? (Skal der bruges en overordnet metafor og i givet fald hvilken? Skal billeder og andre visuelle elementer afløse eller forankre hinanden?)

Tidsplan

Dette er en af artefakterne fra Foranalyse fasen. Vi har udarbejdet en Gantt tidsplan

Faser

En fase er en delsekvens i et projektforløb. Hver fase indeholder mange aktiviteter fra de forskellige discipliner, fasen genererer artefakter, og fasen afsluttes med en milepæl og et review. En fase består af en eller flere iterationer, i dette projekt har jeg besluttet at en iteration er på 10 mandedage eller 2 uger.
Der er forskel på tids- og ressourceforbrug i de enkelte faser. Et typisk mellemstort projekt vil have ressourcer og tid fordelt som vist her: figur 1

Da vi skal skrive en del dokumentation er min Foranalyse og Detaljerings fase lidt længere end dem som er illustreret på figuren. Vi har udeladt Overleverings fasen da den ikke har relevans for vores projekt. Vi har beskæftiget mig med følgende Metode 2 faser:

Foranalyse:
Formålet med Foranalysen er at formulere og fastlægge systemets scope (mål og rammer) samt etablere en aftale (Projektbeskrivelse) med kravstilleren om hvad der skal udvikles.

Alle laver, aftale med projektlederen om en eventuel projektbeskrivelse.

Udover de nævnte artefakter der skal laves en projektdefinitionen, som indeholder indledning, problemformulering og afgrænsning. Denne fase skal være færdig efter
første iteration.

Hovedaktiviteter i Foranalysen:
· Afdække og formulere projektets scope og systemets grænser.
· Overordnet at beskrive de fremtidige forretningsprocesser og systemets Use Cases.
· At udarbejde en overordnet projektplan for hele projektet samt en detaljeret plan for den
første iteration i Detaljeringsfasen
· At udarbejde en Projektdefinition, herunder:
o Indledning
o Problemformulering
o Afgrænsning
· At udarbejde og dokumentere en Analyse som ligger til grund får valget af
løsningsmodellen.

Detaljering:
Det primære formål med Detaljeringsfasen er at få bygget en stabil arkitektur for den færdige løsning. Resultatet af denne fase er et ”skeletagtigt” men kørende system, der demonstrerer den endelige applikations arkitektur. Med hensyn til dokumentationen skal analyse afsnittet skrives i denne fase. Denne fase skal være færdig efter 2 iterationer eller 2 uger.

Hovedaktiviteterne i Detaljeringsfasen er:
· At få en bedre forståelse for de indsamlede krav, System Use Cases
· At designe, implementere og verificere en arkitektur, der kan understøtte den færdige
løsning

At implementere de kritiske System Use Cases og hændelser, der blev identificeret i
Foranalysefasen
· At sikre at miljøet omkring projektet, så som projekt databaser, udviklings- og test miljøer,
værktøjer og lokaler der er behov for til Konstruktions fasen, er på plads
· At få defineret og beskrevet test-strategier og test planer
· At få dokumenteret Design delen af projektet.

Konstruktionsfasen:
Formålet med Konstruktionsfasen at udvikle den resterende del af løsningen, på baggrund af den arkitektur, der blev defineret og udviklet i Detaljeringsfasen. Det er også her at den resterende funktionalitet udvikles og iterativt indarbejdes i applikationen.
Det primære resultat af Konstruktionsfasen er en produktionsklar version af den samlede løsning, der opfylder de krav til funktionalitet, der er blevet indsamlet og godkendt under detaljeringsfasen. I denne fase skal Implementerings afsnittet af rapporten skrives. Denne fase varer 2 iterationer.
Hovedaktiviteter i Konstruktionsfasen:
· Beskrivelse af de resterende krav, System Use Cases og Supplerende Specifikationer, der
skal implementeres i de enkelte iterationer
· Færdiggøre Analyse og Design af den resterende funktionalitet
· Implementering af de resterende dele af løsningen og integrere disse i den samlede løsning
· Løbende test af de dele af løsningen der udvikles i de enkelte iterationer
· At få dokumenteret Implementerings delen af projektet.
I konstruktionsperioden er det implementeringen af den valgte løsningsmodel som har første
prioritet. Det eneste der skal dokumenteres i denne fase de problemstillinger man vil komme til at
møde når man implementerer.

Hvis jeg skal nå at sove bare lidt (bliver jeg nødt til, min hjerne er
færdig), så skal jeg hoppe i seng om lidt.. det vil sige, jeg må prøve om
jeg kan komme til at skrive det sidste til konklussionen i toget; og så mangler vi metode,
og kode afsnittende, jeg kan ikke overskue en løsning til dem lige nu.. så
jeg må trylle noget ud af ærmet i morgen..

Jeg har sendt alt det tekst jeg har skrevet som vi skal bruge til dig nu..
men tager alt med i morgen, hvis der er noget du har overset,..

Ses så hurtigt som jeg overhovedet kan komme til århus.. stiller vækuret til
4 timer – i værste kommer jeg ikke op før efter 5!

God arbejde du har lavet, det ser rigtig godt ud..

/D

Plan

Det lyder som en god ide, ang. (så tidligt vi kan), kan jeg dog mærke nu, at
jeg skal ha min 3-4 timer søvn i nat, (jeg har heller ikke fået meget mere
end 5 i nat, på min sofa), – inden jeg hopper med toget, ellers brænder jeg
sammen;

Altså,

1. jeg arbejder nu til alt undtagen process er færdigt, hopper i seng 3-4
timer, hopper i toget, til århus!

2. Vi ser rapport igennem.

3. Hvis der er noget af process “delen” der mangler, skriver vi den færdig
(du har set den del af det som jeg har sendt til dig osse ikke?)

4- vi printer ud i s/h hos dig

5. Vi tar ind til byen og printer farve

6. vi brænder cder

7. Process dokumentationen som du siger igen får jeg dog her nok brug for
3-4 timers søvn om natten.

Jeg foreslår dog vi evt. brænder cderne sidst

Jeg har nogle dvd skiver jeg godt kan tage med, men har ingen cd’er.

Teksten til sitet er på vej

/D

From: Dennis Mister x
Date: Fri, 22 Dec 2006 16:53:41 +0000
To:
Subject: RE: Ang. Viderudvikling

helt enige; en ting der skal realateres til er det 3 princip for SOA, som
jeg netop nævner under de 3 krav til vores SOA. – da det det først er ved at
være skrevet færdigt nu, er det ikke postet i de tekster jeg har sendt; Det
handler om at vores SOA SKAL kunne parse xml filer (er et krav for at være
et rigtigt SOA)

Jeg har skrevet følgende, du kan bare relatere til det i teksten, altså
skrive det er noget der skal laves i fremtiden, så vores program, kan
relatere til andre programmer (eller sagt anderledes, så man kan gemme
resultatet fra produktet via xml):

Her er hvad jeg har skrevet indtil nu, det bliver kortet ned:

“Princip 3: En services udveksler xml beskeder fremfor klasser”

Som tidligere nævnt skal services kun udveksle på forhånd definerede
beskeder som er defineret ud
fra en service kontrakt. En af de mest anvendte service kontrakt typer er
den xml baserede WSDL.

NÃ¥r man designer og implementerer en applikation anvender man klasser som
repræsenter entiteter
i et forretnings specifikt problem (Indstilling, Ejendom, Interessent).
Disse klasser indeholder kun
data. En klasse er både programmeringssprog og platform afhængig. Hvis
services udvekslede
klasser fremfor xml beskeder, ville to forskellige services, der er udviklet
i forskellige sprog og
platforme ikke kunne kommunikere med hinanden. For at kommunikere skal
parterne have en
fællesnævner som de begge forstår, i dette tilfælde er det xml. En SOA
service udstiller datatyperne
som php konverterer xml baseret beskeder som er platform uafhængige. Det er
i kraft
af XML teknologien at SOA services kan opnå platform uafhængighed og
interoperabilitet. XML
beskederne som udveksles mellem service aftager og udbyder kan defineres i
en WSDL fil. Denne
service kontrakt indeholder information om de xml beskeder som servicen skal
bruge. BÃ¥de service
aftageren og udbyderen skal bruge disse xml beskeder til at kommunikere. Det
er derfor meget
vigtigt, især for service aftageren at kontrakten er statisk og ikke ændrer
sig. En service kontrakt
skal tage højde for at beskederne kan ændre sig uden at det påvirker service
aftagerne. Dette vil
tvinge service udvikleren til at implementere muligheden for udvidelser i
besked strukturen.
· Service kontrakten skal være statisk.
· Service kontrakten bør designes med henblik på at services kan udvides.
Udvidelsen skal
ikke have indflydelse på service aftagerne. Dette kan man opnå ved at
versionere service
interfacet.
· Grænsen mellem en privat og tilgængelig data skal styrkes. Servicens
interne data bør
skjules fra service aftageren mens de tilgængelige datatyper bør være
‰immutable‰ (Kan
ikke ændre sig)
· Hvis det er nødvendigt kan man versionere service kontrakten. Denne
fremgangsmetode
bevirker at man ikke bryder kontrakten med eksisterende service aftagere.
“

>From: Marlene Hørfarter
>To: Dennis Mister x
>Subject: Ang. Viderudvikling
>Date: Fri, 22 Dec 2006 17:07:11 +0100
>
>Vi er enige om at jeg skriver om viderudvikling ikke? Det er det samme som
>fremtid…

Jeg sender lige en mail til jer om 2 min, jeg har gjort mig en del tanker
her til aften…

1.
Jeg har sendt og skrevet en del løbende, det vigtigtigste blev sendt i går -
netop linket til computerworld artiklen med martin t.. Den ligger netop hele
grund-ideen (mere om det i min anden mail om lidt.) – Derud over er det du
hovedsageligt skal tænke på “hvordan tjener vi penge på vores produkt”

- Det hele giver forhåbentlig mere mening om lidt.

Tror også selv jeg får brug for den 26, så skal vi ikke bare sige, den 26
bliver vores sidste mulighed for at arbejde på tekster. – Det bliver bare en
dag mindre til website, men det må vi nøjes med, du har lavet en masse på
det og er helt fantastisk… Glæder mig til at høre, hvad vi gør med steps i
morgen.

Knus D

>From: Marlene Hørfarter
>To: Dennis Mister x
>Subject: Ang. Svar på mail
>Date: Sat, 23 Dec 2006 00:37:20 +0100
>
>
>
>3. Ang. Foretnings planen så har jeg allerede nævnt og sendt alle mine
>overvejelser omkring den (læs din msn log, de links og tekster jeg har
>sendt.)
>
>Jeg kan altså ikke lige helt finde det i min messenger look var det noget
>du
>sendte før i fredags for så må du godt lige sende mig en kopi af hvad du
>skrev.
>
>Men ang. Forretningsplanen har jeg styr på at der skal soa osv. Med men det
>er ikke det jeg vil vide jeg vil hører formålet…
>Skal vi ud og sælge det her bagefter er det det vi skal bruge det til…
>
>Skal det være en forretningsplan om timepuzzle på hvilke præmisser…
>
>Det er kort sagt hvad skal vi have ud af planen. Vi skal selvfølgelig have
>vores målgruppe, vores markedsførings (som du jo skriver) men hvad er det
>vi
>får ud af at skrive en forretningsplan det er det jeg ikke helt kan greje
>vi
>har snakket om det før og jeg kan huske at vi kom frem til en måde men lige
>pt. Kan jeg ikke helt gennemskue den. For du har jo skrevet en masse om at
>det skal være en del af soa og det er også en del af viderudviklingen og
>fremtidsplanen….
>
>Nå men hav det godt og sov godt når du skal sove…
>Og pas nu på dig selv…
>Det er super godt det du har skrevet. Jeg kan godt se du virkelig har
>arbejdet hårdt. Men pas på dig selv det er kun en skole opgave.
>
>Ang. Websitet ang. Steps så overvejer jeg det til i morgen..
>
>Og ang. D. 26 får jeg brug for hele dagen men jeg har jo ca. 5 tekster
>færdige og dem kan du jo bare starte med.
>
>
>Knus Marlene