Exam preparation Flashcards
(128 cards)
1
Q
Hvilke vision scenarios er relevante for vores problem?
A
- Information/Intervention
- User/Law
2
Q
Hvilke forskellige teknikker brugte vi for at undersøge vores visions scenarios?
A
Vi brugte:
- Metaphors
- Propositions
3
Q
Hvilken type af innovation er vores projekt og hvorfor
A
Vores er en proces innovation, da den måde vi bruger sensors på ikke har vist sig succesfuld endnu
4
Q
Hvilke typer af innovation er der?
A
produkt, proces, projekt og paradigme
5
Q
Hvorfor bruges configuration tables?
A
I et projekt bør der være plads til innovation.
Af denne grund skal vi kunne håndtere gradvis udvikling.
Denne gradvise udvikling resulterer i en serie af prospects.
En configuration reflekterer over et helt projekt, sådan at det kan tages til vurdering.
Configuration tables viser denne reflektion.
6
Q
Hvor mange gange bør man lave et nyt configuration table?
A
Hver gang du ændre til et nyt prospect.
7
Q
Hvordan er vores ene configuration table anderledes end det andet?
A
Vi valgte at skifte retning med projektet da vi fandt ud af at der ikke var nogen fast standard for valg af modeller.
8
Q
Hvad var vores projekt trigger?
A
En kombination af user needs og technological oppertunity. Der er rigtig mange som kommer til skade i traffiken grundet uopmærksomhed på vejen. Med de nye sensor teknologier er det nu muligt at undersøge en løsning på dette.
9
Q
Hvad er views?
A
Views bruges til at opdele bekymringer om projektet i forskellige kategorier.
Disse kategorier kaldes for de fire P’er
10
Q
Hvad er de fire P’er?
A
Paradigm, Product, Project og Process
11
Q
Forklar hvad Paradigm view er
A
Se SWI1.png
Det er det view som har fokus på udfordringen og problemet.
Her ser man det fra brugerens side som en række komponenter
“This View is called Paradigm because Problems and Challenges reflect the underlying mental models of the problem domain”
12
Q
Forklar product view
A
Dette view har focus set fra en ingeniørs perspektiv og ser på produktet indefra for at undersøge hvordan det skal bygges.
Dette view har fokus på de teknologier som skal bruges, den arkitektur som skal benyttes og de features som produktet skal have. Paradigm og product views er typisk de views som udforsker problemet og hvordan man løser det.
Fokus på
- Teknologier
- Arkitektur
- Features (hvad kan systemet)
“The Product view sees the con- struction from the ‘inside’ with a focus on technologies and ways to build function- alities. This view represents the solution domain. “
Se SWI3.png
13
Q
Forklar project view
A
Dette view fokuserer på management. Det er her hvor projektets vision befinder sig og bruges til at håndtere usikkerheder. Det er her vi vælger hvilke strategier der skal investeres energi i. Det er også her at vi skal fastholde det mål der er for projektet, sådan at der stadig er frihed til innovation, men at vi husker at bevæge os mod vores vision.
Se Swi4.png
14
Q
Forklar process view
A
Dette view vurdere man på de ting man har fundet og hvad man vil igang med. Det er derfor man her forklarer hvad ens forventninger, kriterier og fund består af. Dette view bruges til at repræsentere forskellige ideer og evaluere den potentielle kost der vil være i at undersøge en mulig løsning på et problem.
15
Q
Hvad er de tre paradigmer for software udvikling?
(Specielt den tredje mulige)
A
Traditionel,
Agil
og pramatisk, som er den præsenteret i essence
16
Q
Hvem kom på ideen og pragmatisme?
A
John Dewey
17
Q
Hvad er ideen om pragmatisk tankegang?
A
Praktiske problemer kræver kreative problem løsninger
Den pragmatiske tangeganke gang er derfor en slags
learning by doing.
Der kan være tidspunkter hvor man laver fejl, og lærer af disse.
18
Q
Hvad er et objekt ifølge John Dewey?
A
Et objekt er en ting som har egenskaber og effekter - en ting som har en beskrivelse.
Men det er også en måde at udvide vores forståelse på.
Folk har en ide om hvad en computer er og hvad den kan f.eks.
19
Q
Hvad er et event ifølge John Dewey?
A
Et event kan ligesom et objekt have beskrivelser,
men ydermere er den bestående af:
en begyndelse.
et interval
en terminering
20
Q
Hvad er en situation?
A
En situation betyder at problemet er kontekstuelt, altså at det er I en verden af objekter og hændelser.
21
Q
Hvad er de tre niveauer af software udvikling?
A
tactic, strategy og rationale
22
Q
Hvad er tactics niveauet?
A
I dette niveau går vi efter et specifict mål. Dette handler om hvordan dele af vores løsning bliver opnået
Det er her man faktisk beskriver hvordan man vil nå sit mål
23
Q
Hvad er strategy niveauet?
A
Strategy niveauet er meget lignende tactics i form af komponenter,
men her er der fokus på hvad der kræves for at løsningen kan komme i mål. Det vil sige i form af arkitekturer, teknologier, problemer som skal løses og de elementer som kræves af løsningen.
24
Q
Hvad er rationale view?
A
I rationale viewet er der fokus på begrundelse for de valg vi tager dvs:
Vores vision (vores end-in-view)
begrænsninger ved løsningen (qualifier)
Rationalet har fokus på hvorfor vi gør alt det her og derfor er det også her at vi beskriver vores problem
25
Hvad er PROBLEMATIC i configuration tables?
Det er den første firkant under rationale/paradigm.
Her beskriver vi udfordringen der er generelt i form af challenge
efterfølgende beskriver vi vores delproblem kaldes problem
26
Hvad er Technologies i configuration table?
Det er de teknologier vi bruger under rationale / product
Vi fokuserer på hvilke teknologier produktet skal have for at kunne levere løsningen.
Ex. smart phone, smart watch etc.
27
Hvad er resolution i configuration tables?
Dette er under rationale / project.
Vi ser her på hvad visionen er for holdet,
vores warrant beskriver hvorfor det er vigtigt at løse problemet
Vores backing forklarer hvorfor vores ide er en god løsning til problemet
28
Hvad er criteria for resolution i configuration tables?
Det er hvad vores forventninger er at systemet kan når det er færdigt.
Det er også hvad vi rent faktisk fandt ud af, og om projektet derfor skal gå en anden retning
29
Hvad er elements i configuration tables?
Det er den første firkant i strategy / paradigm
Her tænker vi over hvilke elementer systemet skal have for at kunne løse problemet.
Dette kan være sådan noget som sensor teknologier eller lignende.
30
Hvad er arhitechture i configuration tables?
Det er de krav der er til systemet set med mere ingeniør briller.
Finde i strategy / product
Her kan vi reflektere over hvilke moduler der er brug for til løsningen, og hvad der helt lav praktisk er brug for, for at systemet kan virke
ex. skal vi bruger servere?
Skal brugeren have en wifi forbindelse hele tiden?
31
Hvad er Qualification i configuration tables?
Det er under strategy / project
her beskriver vi qualifier, det vil sige de limitations der er ved løsningen, men samtidig vores rebuttal, som er hvorfor vi kan leve med de limitations der er.
32
Hvad er criteria for arhitechture i configurationt tables?
Det er under strategy / process
Her beskriver vi de forventninger vi har til arkitekturen af systemet,
det er også her vi notere hvad vi fandt ud af om dette.
Et eksempel kan være om alle komponenter til systemet er velfungerende.
33
Hvad er Scenarios i configurationt tables?
Det er den første firkant under tactics / paradigm
her beskriver hvordan de forskellige scenarier som beskriver brugen af systemet er forbundet med mindst en af de elements vi har
34
Hvad er Features i configuration tables?
Det er under tactics / product
her beskriver vi hvordan systemet kan hjælpe med problemet,
i form a specifikke features.
Ex. systemet kan bruges til systematisk test af modeller på nyt data.
35
Hvad er offers i configuration tables?
Det er under tactics / project
Hvad er det denne løsning på systemet tilbyder?
En løsning kræver forskellige features for at være brugbar, disse features er begrundet af de scenarier som systemet skal kunne anvendes i
36
Hvad er Criteria for offer i configuration tables?
Det er under tactics / process
Her beskriver vi hvad vores forventninger er for hvad vores offer skal kunne når vi er færdige med systemet
Ydermere beskriver vi hvad vi fandt ud af.
Ex. Vi kan sammenligne modeller, men det er svært at få høj performance for dette.
37
Hvad er en transaction i deweyian inquiry?
Det er de interaktioner som den som undersøge situationen har med de elementer som danner situationen.
The inquirer does not stand outside the problematic situation like a spectator; he is in it and in transaction with it
38
Hvilke to operationer gør inquiry brug af?
1. ideational subject matter - som er de koncepter der gør en situation forståelig, ex. objekter og events
2. Existential subject matter - som er de eksperimenter som interagere med objekter eller events i en allerede eksisterende situation
39
Hvad er et mean?
Means er brugbare for at opnå et resultat. En database eller en server er et mean. Ikke alle means er dog genstande i den materielle verden. Nogle facilitere de processer som bruges for at opnå resultatet. John Dewey skelner derfor mellem material means og procedural means.
40
Hvad er material means?
Material means er den type af means som er krævet for at forstå løsningen. Ex. Software mønstre, programmerings paradigmer og værktøjer som kan bruges. Udover dette er det også de koncepter som gruppemedlemmerne kender til, såsom familie, firma, underholdning, togstation osv.
41
Hvad er procedural means?
Denne type means er med fokus på den procedure der er i udviklingen, det er her vi har sådan noget som sprints og generel planlægning.
42
Hvad er end-in-view?
End-in-view er en ide om et mål, det kan fx. være et sprint goal, men det kan også være et overordnet mål for projektet.
Omstændigheder kan ændre end-in-view. Man kan have et overordnet mål, som er bygget på antagelser. Disse antagelser kan dog være forkerte, og målet skal derfor ændres.
Dette er et overordnet end-in-view. Dette gælder også for et sprint, hvor det er muligt at ændre retning efter sprintet. Dette gælder også for delproblemer som kan forekomme under projektet.
43
Hvad bruges Paradigm View til?
Til at reflektere over "Problem" og "Challenge" set ud fra brugerens og eksterne systemers synspunkt.
44
Hvad bruges Process View til?
Bruges til ideudvikling og -evaluering, den del som kaldes "appreciation".
45
Hvad bruges Product View til?
Det bruges til Transactions med problemdomænet ud fra et teknologisk synspunkt.
Dermed bruges til at vurdere hvordan løsningen skal bygges, og til at identificere nøgle teknologier.
46
Hvad bruges Project View til?
Bruges til rationalet af projektet, og for management af projektet.
Det er her at projektets Vision udvikles og vedligeholdes, samt "research efforts" håndteres.
47
Hvad bruges roller til?
Rollerne opfordrer til at bestemte tankegange og ansvarområder blandt projektets udviklere.
48
Hvad er "Paradigm Innovation"?
Ændringer i "Mental Model", der enten fjerner blokeringer eller give nye perspektiver, som giver anledning til nye muligheder og løsninger (Tidd et al, 2005)
49
Hvad er Anchors 4 ansvarsområder?
• Ensure that the team is fully functional and productive at all times.
• Offer and adapt methods, techniques, and tools to support work.
• Ensure fairness in Potential and idea evaluations via appropriate methods
and evaluation criteria.
• Take care of ‘foreign affairs’ by representing the project to stakeholders
and shield the team from external interference.
50
Hvad er Responders funktioner?
• Point to technological alternatives in building solutions.
• Help evaluate strengths, weaknesses, opportunities, and threats.
• Engage in scenario and vision development from a technological
perspective.
• Help evaluate feasibility and potential of wanted scenarios.
51
Hvad er rollen Anchor?
Anchoren er facilitatoren for arbejdsprocessen, og er ansvarlig for det samlede hold fungerer.
Samtidig er han/hun ansvarlig overfor eksterne stakeholders.
52
Hvad er rollen Challenger?
Er den rolle der ser det fra kundens perspektiv, og som står for prioriteringen og godkendelse af ideer.
Skal have stor viden om anvendelsesområdet.
53
Hvad er rollen Child?
Child kan stille alle de dumme spørgsmål, komme med de store tanker, men ingen har ansvar for at lytte til ham/hende.
Child tager heller ikke ansvar for sine forslag/tanker.
Det er også en rolle, som alle kan tage på sig midlertidigt i løbet af projektet.
54
Hvad er rollen Responder?
Kommer med, og implementere, de tekniske løsninger.
Skal være åbne overfor nye ideer og god argumentation.
55
Hvad er to almindelige spørgsmål Challenger kan stille?
- Is this the right solution for us?
- Is this the best we can get?
56
Hvad vil du gerne udforske med Paradigm View?
What "is" and what "could be". P. 118
57
Hvilke 4 aktiviteter deltager Child i?
Ideation, Detaling, Evaluation, og Vision maturation.
58
Ideation, Detaling, Evaluation, og Vision maturation.
* Be responsible for the value created by the product.
* Engage in idea and scenario development.
* Prioritize features according to value.
* Accept or reject proposals and work results.
* Decide on release dates and contents.
59
Hvilken rolle extra kan en Anchor have samtidig med at være Anchor?
Responder
60
Hvilken Value har Responder meget at gøre med?
Transaction
61
Hvilket View er Challenger i?
Project View
62
Hvilket view hører Child til?
Paradigm View
63
Hvor mange Challengers er der på et hold?
Oftest én.
64
Hvordan er 4 views knyttet op mod værdierne?
* Paradigm: Reflection over requirements.
* Product: Transaction over solution.
* Project: Reasoning over assignments.
* Process: Appreciation over structuration.
65
I hvilket View er Responder?
Product View?
66
Når man snakker om scenarier i Paradigm View, hvilke to faktorer drejer det sig så om?
Stakeholders; Dem, der bliver berørt af løsningen.
Kontekst; I hvilke fysiske, lovmæssige, og "systemic worlds" udfolder løsningen sig i.
67
The four innovasion triggers
User needs
Technological opportunity
Solution reuse
Competitive stress
68
The four P's in Essence
Paradigm, project, product, process
69
What is the two basic parts of Pragmatic Software Development?
The Hypercomplex.
The problem-oriented.
70
Hvad er et review i essence?
Essence gør brug af Rationale, strategy og tactics review, for at forstå problemet. Essence udvider et almindeligt sprint sådan at RST bliver indført i sprint planlægningen, og vurderet i sprint reviewet. (se billede).
71
Hvordan struktureres et review i essence?
Så for at strukturere et review, tager essence udgangspunkt i de her ETVX modeller (se billede). Her er entry kriteriet vores refleksion. Opgaverne der findes er vores transaction. Validering er appreciation. Og exit criteria er reasoning.
72
Hvad er paradigm for RST reviews?
Agile value: Samarbejde med kunden er vigtigere end at lave en rigid kontrakt
Agreement: Både traditionel og agil forventer at kunden formulerer krav
Essence value: Refleksion over krav hvilket betyder: Det er vigtigere at forstå needs end at lave en liste af specifikationer
73
Hvad er reflection for paradigm i RST reviews?
Problem, elements og scenarios
| (se billede)
74
Hvad er product for RST reviews?
Agile value: Kørende kode over uddybende dokumentering
Agreement: Både traditionel og agil fokuserer på at levere løsninger defineret af kunden
Essence value: Transaction over løsning hvilket betyder: Det er vigtigere at finde muligheder end at levere rå resultater
75
Hvad er reflection criteria for project i RST reviews?
Technologies, Arhitecture og Features
76
Hvad er project for RST reviews?
Agile value: Reagere på ændringer over at følge planen
Agreement: Både traditionel og agil styrer projekter med opgaver
Essence value: Reasoning over opgaver hvilket betyder: Det er vigtigere at have en retning end at vide hvordan vi skal komme derhen
77
Hvad er reflection criteria for project i RST reviews?
Vision, warrant, Backing, qualifier rebuttal og offer
78
Hvad er process for RST reviews?
Agile value: Individer og interaktioner over processer og værktøjer
Agreement: Både traditionel og agil værdsætter stabile software processer
Essence value: Appreciation over strukturering hvilket betyder: Det er vigtigere at bevæge sig i den rigtige retning end at følge rutinen
79
Hvad er reflection criteria for process i RST reviews?
Her vurdere vi processen på det hele
| (se billede)
80
Beskriv child
Child er den naive rolle. Her er der mere fokus på refleksion istedet for krav til systemet. Det er en kreativ rolle, hvor vilde ideer som ikke tager hensyn til den arkitektur som systemet har. Ingen har ansvar til at lytte til child, men child har heller ikke ansvar til at føre sine ideer ud i livet. Alle kan påtage sig rollen som child i løbet af projektet. Child er den optimistiske rolle som deltager i fire aktiviteter.
**Ideation:** Engaging in activities stimulated by what-ifs, let’s trys and the like to open up for alternative ideas or notions of context and needs.
**Detailing:** Developing or challenging scenarios or key elements. Problem domain needs and desires are fleshed out in wireframes, prototype simulations and improvisations inspired by technology options.
**Evaluation:** Questioning idea evaluations, offering alternative assessments, or suggesting other criteria for evaluations.
**Vision maturation:** Challenging or expanding the core assumptions or raison d’être of the project.
81
Beskriv challenger
I traditionel software udvikling, er denne rolle delvist customer og delvist project manager. Challenger agerer på baggrund af de interessenter som er for projektet. Rollen er central for hvordan udfordringen bliver præsenteret for holdet. Challengeren skal have ekspertviden for anvendelsesområdet (det område hvor systemet skal bruges). Som regel er der kun en challenger, men der kan være situationer hvor flere challengers bliver brugt. At have en rigtig kunde som challenger er bedst, men ikke altid mulig.
Finally, the Challenger together with the team defines product releases that will help explore and implement the overall project idea. The Challenger thus has several functions, as he or she must:
Be responsible for the value created by the product.
Engage in idea and scenario development.
Prioritize features according to value.
Accept or reject proposals and work results.
Decide on release dates and contents
82
Beskriv responder
Responder er den som står for den teknologiske viden. Responderen sørger for at maksimere brugen af nyttigt teknologi, som skaber mest værdi for den ønskede løsning til problemet. En god responder sørger for at forskellige teknologier og designs bliver afprøvet. Responderen kan selv eksperimentere med forskellige teknologier for at finde frem til den bedste for det specifikke problem. Der kan sagtens være flere responders i et projekt. En responder svarer måske meget en team member i scrum. Responders skal blive enige om system arkitektur og design, eller have en overordnet rolle som tager beslutningen. Det er dog vigtigt at dette design er så simpelt som muligt, sådan at der er plads til nye ideer.
The Responder thus has several functions as he or she must:
Point to technological alternatives in building solutions.
Help evaluate strengths, weaknesses, opportunities, and threats. 180
Engage in scenario and vision development from a technological perspective.
Help evaluate feasibility and potential of wanted scenarios.
83
Beskriv anchor
Anchoren er den som står for administration og kommunikation med eksterne interessenter. Anchoren er ansvarlig for det samlede projekt. Det er anchoren som har ansvar for brugen af reviews og sprint planning. I traditionel software udvikling er anchoren en project manager. Rollen er central for at vedligeholde flow i projektet. Det er anchoren som skal sikre at teamet ikke mister fokus på projektet. Der skal være plads til innovativ tankegang, men projektet skal stadig nå i mål. Anchoren sørger for at selvom der er diskussion i projektet, skal der sikres gode argumenter for de valg der kommer. Anchoren er ofte en responder som har det her ekstra ansvar. I scrum vil det svare til en scrum master.
The Anchor has several responsibilities as he or she must
Ensure that the team is fully functional and productive at all times.
Offer and adapt methods, techniques, and tools to support work.
Ensure fairness in Potential and idea evaluations via appropriate methods and evaluation criteria.
Take care of ‘foreign affairs’ by representing the project to stakeholders and shield the team from external interference.
84
Hvad er affordance
Affordance er elementer der muliggør noget i samspil med nogen der vil gøre det “noget”.
Hovedsagligt 3 ting i software innovation: Foreseeable hardware changes, Upcoming services, Upcoming standards
85
Hvilke process værktøjer har vi at bruge?
Idegenerering, Single idea evaluation og Comparative idea evaluation
86
Hvad er de to forskellige (og vigtige) tankegange når det kommer til ide generering?
Der er to forksellige tankegange som er vigtige når det handler om idegenerering. Den første er kalde divergent thinking hvor man breder sig ud og danner alternativer og nye perspektiver, den anden kaldes convergent thinking, hvor man udvider og undersøger specifikke ideer.
87
Hvilke to redskaber giver essence til single idea evaluation?
SWOT og value analysis
88
Beskriv SWOT
Strengths, weaknesses, oppertunities og threads
89
Beskriv value analysis
Denne type evaluering er mere fokuseret end SWOT, her beskriver man nelig potentialet ved de forskellige egenskaber for ideen. Så for vores projekt kan det være at det er sikkerhed som er en vigtig egenskab. Derfor kan man give den en vurdering.
(se billede)
90
Hvilke to typer af evaluation giver essence for comparative idea evaluation?
NAF analyse og PMI analyse
91
Beskriv hvad NAF analyse er
Hvis vi skal sammenligne to ideer kan vi gøre brug af en NAF analyse. Her vurdere man de enkelte værdier baseret på novelty, attractiveness, and feasibility i en skala fra et til fem, hvor fem er højest.
92
Beskriv en PMI analyse
Hvor en NAF analyse har faste predefinerede kategorier til sammenligning, så vil brugen af en PMI analyse ikke sådanne kategorier, men i stedet gør brug af plus, minus og interessante ting ved hver ide.
93
Beskriv forholdet mellem software process innovation og software product innovation
Der er et meget kompleks forhold mellem software processer og software produkter. Det er ikke bevist at innovative software processor fører til innovative software produkter.
Måske kan bedre software processer inden for et bestemt område føre til bedre og innovative produkter, men i nogle situationer kan det også være bedre at udvikle produktet ved brug af traditionelle software processer.
94
Hvad er forskellen på creativity, invention og innovation?
Creativity refers to the personal (or group) characteristics which can lead to invention, often described as internal abilities or states or relationships.
Invention refers to the process or result of creativity - to an idea or artifact which is novel, or the action of developing it.
Innovation describes the creative act and invention carried into wider use, leading to substantial kinds of change; thus the successful exploitation of new ideas.
Thus we should understand that innovation is more than creativity and more than invention. Merely to design something that is new is not innovation; in fact novel ideas are fairly commonplace and often not the difficult part of innovation. The invention must be developed and produced (normally commercially), distributed and brought into use. The end result of innovation is social change, a change of understanding or practice in a community of people.
95
Hvilke elementer har indflydelse på software timing?
Installed base, Software trajectories, software convergance, user demand.
Alt dette leder op til innovation window
96
Beskriv installed base
For at forstå alt software innovation, er det nødvendigt at forstå både den sociale og tekniske infrastruktur som gør denne innovation mulig.
Infrastrukturen er noget som mange ikke lægger mærke til i løbet af deres hverdag, men den er essentiel for at man kan bruge de forskellige teknologier eller komme op med nye. Rose opdeler infrastrukturen i to kategorier, fysisk og social.
Et eksempel på en teknologi, som krævede denne rette installed base er Skype.
97
Beskriv software trajectories
Trajectories beskriver den retning noget bevæger sig. For skype var det vigtigt at voice over internet blev udviklet på, hvortil de protokoller som tillader dette, blev interessante i 90’erne. Ydermere var det vigtigt at brugen af peer to peer netværk blev mere populært i samme tidsrum. Dette muliggjorde skype. Figuren nedenfor viser ideen om trajectories.
98
Beskriv software convergance
Det sker mere og mere at teknologier bliver digitaliseret og samlet i et sted. Dette kaldes technological convergance, hvor teknologier som før var analoge (ex. pladespiller) bliver digitale (ex. spotify / mp3 musik). Dette giver derfor en mulig for at vi samler systemer under samme overordnede teknologi, hvilket åbner op for helt nye muligheder.
99
Beskriv user demand
Ved enten at opfylde en efterspørgsel (facebook), eller ved at lave en efterspørgsel (apple: iPhone) kan man påvirke markedet og derved måske danne ny innovation. Eksempelvis skabte Skype mere fokus på brugen af telefonisk kommunikation, og det førte også til priskrig blandt mobile udbydere.
En virksomhed ønsker at opfylde brugernes behov, og at finde frem til dem, og forstå dem, er afgørende for hvorvidt ens produkt kan fange køberne.
100
Beskriv innovation window
Timingen er helt utrolig vigtig for at gøre en software innovation vigtig. Kommer den for tidligt, kan det være der ikke er den korrekte installed base, og udviklingen vil derfor blive omkostningsfuld, og prisen derefter. For sent og innovationen er allerede sket af mange andre inden for markedet. Det er derfor vigtigt at man som innovativ software udvikler:
Teknologiske trends og trajectories
Digitalisering og convergence
Sociale og teknisk infrastruktur udvikling
Bruger efterspørgsel (demand)
Og timing i forhold til sit innovation window
101
Forklar hvorfor det er vigtigt at øge sit community?
For at kunne være innovativ, er det vigtigste at udvide sit community af lige sindede. Det handler om at kunne bruge forskellige værktøjer til både eksplicit og underforstået forståelse for hinandens viden. Dette giver os alle en bedre base for innovation
102
Nævn de forskellige teknologiske karakteristika
novelty / utility
broad -\> focused
low \<--\> high
incremential / radical
103
Hvad er utility / novelty?
Novelty og utility er to karakteristika som kan bruges til at afgøre en teknologi.
Billedet forklarer det perfekt
104
Hvad er Althullers hieraki af tekniske systemer?
Althuller præsenterede også sit hieraki af tekniske systemer:
Se billede
105
Hvad giver utility / novelty
og
althullers hieraki os?
Disse værktøjer giver mulighed for at kunne forstå hvordan denne teknologi er innovativ. Er den fokuseret på en meget lille del af det overordnede system, eller er den en helt ny radikal ændring på kemiske processer som kan bruges til transportation? Er den meget brugbar for de enkelte brugere, eller er den måske mere noget man ikke har set før, og derfor er så nytænkene at vi først nu skal finde steder den kan bruges? Alt dette giver et overblik over ens innovation.
106
Hvad er low / high figuren som althuller bruger til opdeling af teknologier?
Se figur
Som man kan se er et niveau fem en meget sjælden videnskabelig ændring. Hvor level to er mindre forbedringer på et eksisterende system.
107
Hvad er forholdet mellem broad / focused og low / high?
Vi kan bruge dette forhold til at forstå om vi har at gøre med en inkrementiel innovation eller en radikal innovation.
Se figur
108
Hvad er de seks innovation process strategies?
1. Creative Requirements Analysis
2. Designed Process Framework
3. Low Tech Prototyping
4. User driven innovation
5. Community development – the open source model
6. Research Prototype
109
Beskriv Creative Requirements Analysis
Integrer light bulb modellen til en normal udviklings cyklus
I stedet for requirements ingenieering, erstatter man den med mere fantasifulde og kreative teknikker
Arbejd med brugere som primært er ansvarlige for nye ideer.
110
Beskriv Designed Process Framework
Mere agil tankegang med fokus på værktøjer, teknikker, roller og opgaver alt sammen integreret i dette.
Udviklere tager ansvar for ideudvikling.
Dette svarer fint til essence:
Views: Product, Paradigm, Project og Process
Roles: Challenger, Responder, Anchor og Child
111
Beskriv Low Tech Prototyping
Se figur!
112
Beskriv User driven innovation
Hav meget mere fokus på brugere, og derved høre dem ad hvilke ideer de har til en mulig løsning.
Det kan dog være svært at overføre information fra brugerne til udviklere, da de måske ikke helt ved hvad de vil have. Det er også vigtigt at de er specifikke i deres forklaring.
Man kan gøre brug af lead users, dvs. brugere med ekspertise inden for området samt IT kompetencer.
Her kan man også gøre brug af online communities til at få et indtryk.
113
Beskriv Community development – the open source model
Ved brug af open source tilgangen, er det muligt at få hurtig udvikling og have en kæmpe mængde af brugere som kan prøve forskellige versioner af. Det er en mulighed for rig kommunikation og mange ekspert personer kan have input.
114
Beskriv Research Prototype
Dette er innovation ved brug af research, som jo kræver ekstern funding.
Her kan researchers teame op med udviklere, sådan at man både forstår de videnskabelige og udviklingsmæssige begrænsninger.
115
Beskriv Software Team Innovation/Creativity Factors
Negative factors
* Creativity barriers
* Group dysfunction
Positive factors
* Software team roles
* Communicative interactions
* The accommodation of divergent thinking
* Team learning
* Overview (common purpose)
* Expertise integration
* Social practice patterns
* Environmental scanning
116
Beskriv innovation activity model
se figur
117
Hvad er ideen med values i essence?
Vi har forskellige view (måder at se projektet på) hvert view undersøtter et value. Som er en måde at sammenligne sig i forhold til det agile manifesto. Det er altså de værdier som vi tager med videre:
(Reflection) rejects the conventional focus on requirements and points to reflection as a way to see needs in light of options.
(Transaction) rejects the conventional struggle for finishing work and points to viewing any design step as offering possibilities for even better solutions
(Reasoning) rejects the conventional view on project management as handling assignments and suggests using the project Vision as an alternative way to steer development in a wanted direction
(Appreciation) rejects the conventional focus on structuring work according to universal practices and suggests a stronger focus on reviewing work according to the specifics of the moment.
118
Er vores projekt broad eller focused
Broad, da vi bruger mange forskellige komponenter
119
Hvad er de 8 heuristics?
Keep your head up
Grow your knowledge community
Target your product’s innovation profile
Develop your personal creativity
Be a super-team-worker
Bring your toolbox
Shape your own process
Know when you are (not) innovative
120
Beskriv keep your head up
Do you understand the latest technical trends and developments in the field you are working on?
Do you know the rival products that other software companies are working on?
Do you understand the emerging technology potential?
Have you assessed what infrastructure your product requires, and will it in place when the product is released?
Have you investigated the potential market for your product?
Is your timing right?
121
Beskriv grow your knowledge community
Are you in contact with leaders in the field: other development groups, researchers, universities, lead users?
Do you partner to improve your expertise base?
Can you import necessary expertise for the project when you need it?
Do you get valuable external feedback from outside the project? From outside the company
Are you a member of relevant online and offline knowledge communities?
122
beskriv Target your product’s innovation profile
Can you articulate the added value (utility) for the user?
Have you determined how your product is new and original?
Do you understand your user community – their work and leisure habits?
Do you understand how your users’ lives will change when they use your product?
Do you work with the product’s innovation profile?
123
Shape your own process
Do you have an innovation process strategy and is it suitable for the task?
Do you have the correct balance of market-led and technology-led strategies?
Are there techniques and practices which stimulate the creativity of the team, and does it allow space for creativity and innovation?
Can you improvise your way out of the difficulties?
Do you continually and explicitly adapt your process to the current needs of the project?
124
Beskriv Develop your personal creativity
Are you, personally, learning fast?
Does your role in the project suit and stimulate you?
Can you bring your expertise and experience to bear on the software challenge?
Are you challenged and stimulated by the tasks you have without feeling chronic stress?
Are you often in flow?
125
Be a super-team-worker
Are you aware of the factors that hinder the team’s innovation and do you work to improve them?
Does the team recognise sub-optimal teamwork and work to improve it?
Does the team work towards an evolving shared vision and know where it is going?
Does the team work at effective communication (dialogue)?
Does the team understand how to accommodate divergent thinking?
Do the team members communicate their experience and expertise and learn from each other?
126
Bring your toolbox
Does the project have a repertoire of formal or informal creativity techniques and use them where appropriate to help you to move forward?
Do you have the right tool support to maximise creative progress and minimise drudge work?
127
Know when you are (not) innovative
Does the team recognise when it is not moving forward, discuss it openly and do something differently as a result?
128
