TDIU14 Föreläsning 2: Informationssökning Ola Leifler, IDA WExUpp, thesis administration IDA/ISY

advertisement
TDIU14
Föreläsning 2: Informationssökning
Ola Leifler, IDA
måndag 25 januari 16
WExUpp, thesis administration IDA/ISY
Informationssökning
måndag 25 januari 16
Hur många har sökt efter information?
Vilken typ av information har man sökt efter?
I vilket syfte?
Vad är bra information?
Vi kommer prata om hur processen att leta efter information till era examensarbeten kommer
att gå till. Det finns många likheter mellan hur man letar efter information till sina
ingenjörsprojekt i allmänhet och hur man letar efter information till sitt examensarbete, men
också några viktiga skillnader. Den främsta skillnaden är att vi nu är intresserade av
bekräftade resultat av effekten hos olika tekniker/metoder.
Att hitta rätt
information
måndag 25 januari 16
Learn about the subject area:
use Wikipedia, books and previous course material
måndag 25 januari 16
Extract keywords that you can use when searching papers.
måndag 25 januari 16
Use Google Scholar & Unisearch first, specific publications second
måndag 25 januari 16
Hur man hittar specifik
information
”HLA active probing
runtime performance
requirements in a
Wide Area Network”
måndag 25 januari 16
{}
HLA
active probing
simulation
fault detection and localization
runtime performance requirements
in a Wide Area Network
måndag 25 januari 16
latency, throughput
IP networks
Information för
ingenjörer och forskare
Frågor
Pålitlighet
Källor
måndag 25 januari 16
Ingenjörer
Forskare
Hur man löser ett
problem
Hur man kan
förklara något
Bekräftade lösningar
Bekräftade
arbeten
Systembeskrivningar, Granskade
programvara
publikationer
Iterativ sökning
”On AI”
”On Planning”
”Fie Planner”
”Foo Heuristic”
”On Heuristic Search”
1
måndag 25 januari 16
2
3
Vetenskaplig publicering
Systematic Literature
Review
”The foo
planner”
Primärstudier
t
”A survey of AI
planning
”On Planning”
algorithms”
Sekundärstudier
t+2 år
”Vad”
måndag 25 januari 16
Böcker
t+5 år
Vetenskaplig publicering
Tidskriftsartiklar
Granskade artiklar
Konferensbidrag
Tekniska rapporter
Icke-granskade texter
Systembeskrivningar
”Hur”
måndag 25 januari 16
Publikationstyper
P. Kruchten, H. Obbink, and J. Stafford. The past, present,
and future for software architecture. IEEE Software,
23(2):22–30, March–April 2006.
Inga nya resultat. Expertgranskad artikel publicerad i
vetenskaplig tidskrift.
måndag 25 januari 16
Publikationstyper
T. K. Paul and M. F. Lau. A systematic literature review on
modified condition and decision coverage. In Proceedings
of the 29th Annual ACM Symposium on Applied Computing,
SAC ’14, pages 1301–1308, New York, NY, USA, 2014.
ACM.
Systematic Literature Review, sekundärstudie. Expertgranskat
konferensbidrag
måndag 25 januari 16
Publikationstyper
C. Wohlin, P. Runeson, M. Höst, M. C. Ohlsson, B. Regnell,
and A. Wesslén. Experimentation in Software Engineering.
Springer Berlin Heidelberg, 2012.
Bok om empiriska metoder i Software Engineering
måndag 25 januari 16
Publikationstyper
I. Maier, T. Rompf, and M. Odersky. Deprecating the
observer pattern. Technical report, École Polytechnique
Fédérale de Lausanne, 2010.
Teknisk rapport, ej granskad. Inga empiriska data, men analys
och förslag på ny arkitektur.
måndag 25 januari 16
Publikationstyper
A. Nilsson, J. Bosch, and C. Berger.Visualizing testing
activities to support continuous integration: A multiple case
study. In G. Cantone and M. Marchesi, editors, Agile Processes
in Software Engineering and Extreme Programming, volume
179 of Lecture Notes in Business Information Processing, pages
171–186. Springer International Publishing, 2014.
Fallstudie, expertgranskat konferensbidrag från sammanställning
av konferenser
måndag 25 januari 16
Publikationstyper
J. Andrews, L. Briand, and Y. Labiche. Is mutation an
appropriate tool for testing experiments? In Proceedings of
the 27th International Conference on Software Engineering,
ICSE 2005, pages 402–411, May 2005. IEEE Computer
Society.
Experiment, expertgranskat konferensbidrag
måndag 25 januari 16
Vad är resultat?
Typ
Procedur/teknik
Förklaringsmodell
Erfarenhetsrapport
måndag 25 januari 16
Hur?
Kvalitet
Formella bevis,
experiment,
statistik
Korrekt
användning av
statistik
Korrekt
beskrivning av
verkligheten
Intervjuer,
observationer,
användardata
Verkliga system
och människor
Trovärdighet
måndag 25 januari 16
Stack Overflow
måndag 25 januari 16
Trovärdighet bedöms av
• författarnas tidigare arbeten och renommé
• processen för granskning av resultaten
• andras omdömen om arbetet
måndag 25 januari 16
Vad är starka resultat?
Table 6. Types of research validation represented in ICSE 2002 submissions and acceptances
Type of validation
Analysis
Evaluation
Experience
Example
Some example, can't tell whether it's toy or actual use
Persuasion
No mention of validation in abstract
TOTAL
Submitted
48 (16%)
21 (7%)
34 (11%)
82 (27%)
6 (2%)
25 (8%)
84(28%)
300(100.0%)
Accepted
11 (26%)
1 (2%)
8 (19%)
16 (37%)
1 (2%)
0 (0.0%)
6 (14%)
43 (100.0%)
Ratio Acc/Sub
23%
5%
24%
20%
17%
0%
7%
14%
M. Shaw. Writing goodValidation
software engineering research papers: Minitutorial.
In Proceedings of the 25th
Validation
International
pages 726–736, Washington, DC, USA,_,,2003.
100%300 Conference on Software Engineering, ICSE ’03,
IEEE Computer Society.
250
80% . . . . . . . . . . . . . . . .
~ :i~ ~
_
-
200
i
iiiiiiiiiii!
100
50
måndag 25 januari 16
20%.
0% -
o
-"
),Accept.
t
Figure 5. Counts of acceptances and rejections
by type of validation
4.3 What do program committees look for?
~,.+~
~
~'~!!i
~
fll .
n
<,.+" ~
oe .o"
U" Accepted [] Rejected-]
Figure 6. Distribution of acceptances and rejections
by type of validation
Is the validation related to the claim? If you're claiming
Starka resultat
Verkliga system &&
korrekt analys
måndag 25 januari 16
Att hitta rätt artikel
• Relevans = f(titel, typ, år, sammanfattning,
citeringar)
• Ju mer specifik & ny desto färre citeringar..
• Böcker - litteraturöversikter - primärstudier
• Referera till huvudresultaten, inte till något från
introduktionen
måndag 25 januari 16
Men icke-granskade
referenser då?
• Använd för att stödja existens: ”There are
several implementations of Flux
controllers”
• Inte för att stödja påståenden som kräver
granskade data: ”Flux controllers are more
user friendly than Flax controllers”
måndag 25 januari 16
Att värdera en artikel
”Software product lines are related software
products that are customized to different
customers [1]”
[1] Kästner, C., Apel, S., and Kuhlemann, M. Granularity in software product lines. In Proceedings of the
30th International Conference on Software Engineering, ICSE ’08, pages 311–320, New York, USA, 2008.
Inte huvudresultaten från [1]
[1] Pohl, K., Böckle, G., and van der Linden, F. J. (2005). Software product line engineering: foundations,
principles and techniques. Springer Science & Business Media.
Använd ovanstående i stället
måndag 25 januari 16
Teori
1. Analys:Vad är det här? Klassificeringar,
taxonomier, ontologier
2. Förklaring:Varför händer det här?
3. Förutsägelser:Vad kommer hända?
måndag 25 januari 16
Plagiering &
upphovsrätt
måndag 25 januari 16
noplagiat.bibl.liu.se
måndag 25 januari 16
Att använda bild utan
referens
Plagiering +
upphovsrättsbrott
Att använda bild med
referens
Använda egen bild eller
CC-bild med referens
upphovsrättsbrott
OK!
måndag 25 januari 16
Att använda referenser
måndag 25 januari 16
Referenser i text
[1] has studied software design patterns
Odersky et al. have studied software design patterns [1].
Odersky et al. (2010) have studied software design
patterns.
måndag 25 januari 16
There are a number of conventions of how to use references properly: use in-text references
or outside-text references consistently. IEEE has a good standard for this.
For a qualitative model
For an empirical model or tool
For a notation or technique
Parafrasering
Example
... narrative
... data, usually statistical, on pra
... comparison o f systems in actu
Here's an example of how it works on
For a technique or procedure
...a "slice of life" example based
For a technique or procedure
...a system that I have been deve
For a technique or procedure
... a toy example, perhaps motiva
The "slice of life" example is most likely to be convincing, especially
explanation o f why the simplified example retains the essence of t
Toy or textbook examples often fail to provide persuasive validati
examples used as model problems by the field).
thought hard
about this,
and I believe passionately
Over a quarter
2002
abstracts
give that
no...
Persuasionof the I ICSE
For a technique
... if you do it the following way
For a system
... a system constructed
indication of how the paper's
results are validated,
if at like
allthis
For a model
... this example shows how my id
[1]. purely by persuasion is rarely sufficient for a research pap
Validation
original question was about feasibility, a working system, even wi
No serious attempt to evaluate result. This is highly unlikely to be ac
The most successful kind
4.2 Which of these are most common?
analysis and real-world expe
were also successful. Persu
Alas, well over a quarter of the ICSE 2002 abstracts
narrative evaluation was o
give no indication of how the paper's results are validated,
Table 6 gives the distribu
if at all. Even when the abstract mentions that the result
2002, based on reading the
was applied to an example, it was not always clear
followed by graphs of t
whether the example was a textbook example, or a report
Figures 5 and 6 show these
on use in the field, or something in between.
Blatant assertion
[1] M. Shaw. Writing good software engineering research papers: Minitutorial. In Proceedings of the 25th
International Conference on Software Engineering, ICSE ’03, pages 726–736, Washington, DC, USA, 2003.
IEEE Computer Society.
måndag 25 januari 16
Do not copy verbatim from published papers.
732
$-*2&'-0' )- ":' <&!2$"7 !""#$%&"'8 !-+ ! +)4- !##)4
(75%)2 G" H $-+$0!"'( ":!" ":' +'($,- 1#)1'#"7 :!( ! -',!"$3'
$-*2&'-0' )- ":' <&!2$"7 !""#$%&"'.
Citat
/-0!1(&2!"$)- $( 3$'4'+ ") 1#)5)"'
!-+ &-+'#("!-+!%$2$"7. 9:$2' 2)4
,))+ *)# &-+'#("!-+!%$2$"78 '6"'-+;
78 :$,:'# 5'!(&#'( )* 0)&12$-, !#'
$-*2&'-0' ":'(' <&!2$"7 !""#$%&"'(.
") :!3' ! ($,-$*$0!-" '**'0" )- !
27 !-+ #'&(!%$2$"7.
"' %7 5'((!,' 1!(($-, !-+8 ":'#'*)#'8
*2&'-0'( *&-0"$)-!2$"7 !-+ '**'0"$3';
5)"'( #'&(!%$2$"7. 9:$2' ":' &(' )*
$-"'#-!2 #'&(!%$2$"78 *&-0"$)-!2$"78
'0"$3'-'((8 $" :!( ":' 1)"'-"$!2 ")
6$%$2$"7 !-+ &-+'#("!-+!%$2$"7. A$5$;
*&2 &(' )* )%@'0" 0)51)($"$)- 0!$-"'#-!2 #'&(!%$2$"78 *&-0"$)-!2$"78
'(($3' !-+ $-0)##'0" &(!,' 0!- 5!B'
'#("!-+. C:' &(' )* 0)51)($"$)- 5!7
-'(( !-+ '6"'-+$%$2$"7. 9:$2' ":' &('
3$'4'+ ") $-0#'!(' ":' *2'6$%$2$"78
-'((8 !-+ *&-0"$)-!2$"7 !""#$%&"'( )*
3$'4'+ ") 5!B' +'($,-( :!#+'# ")
"7 $( 3$'4'+ !( !- $-+$0!"$)- )* ":'
+'($,-. D- ,'-'#!28 ":' 5)#' 0)512'6
!"#"$ %&'()*'+( *)& ,'+-.(&/ 0123 4&/'(+ 5126&1*'&/ *2
78.9'*: ;**1'<8*&/
I!('+ &1)- ":' +'($,- 1#)1'#"7 ") <&!2$"7 !""#$%&"'
#'2!"$)-(:$1 5!"#$6 $- C!%2' E8 ":' #'2!"$3' ($,-$*$0!-0' )*
$-+$3$+&!2 +'($,- 1#)1'#"$'( ":!" $-*2&'-0' ! <&!2$"7
!""#$%&"' $( 4'$,:"'+ 1#)1)#"$)-!227 () ":!" ":' 0)51&"'+
3!2&'( )* !22 <&!2$"7 !""#$%&"'( :!3' ":' (!5' #!-,'. F #!-,'
)* ! ") #" 4!( ('2'0"'+ *)# ":' 0)51&"'+ 3!2&'( )* ":'
<&!2$"7 !""#$%&"'(.
J)# !- $-$"$!2 1!(( $- ('""$-, 5)+'2 1!#!5'"'#(8 !
4'$,:"'+ 3!2&' )* KL )# KM.E 4!( &('+ *)# ":' 1)($"$3'
$-*2&'-0'(8 !-+ ! 3!2&' )* ;L )# ;M.E 4!( &('+ *)# ":'
-',!"$3' $-*2&'-0'(. C:' $-$"$!2 4'$,:"'+ 3!2&'( )* +'($,1#)1'#"7 $-*2&'-0'( )- ! <&!2$"7 !""#$%&"' 4'#' ":'1#)1)#"$)-!227 0:!-,'+ ") '-(&#' ":!" ":' (&5 )* ":' -'4
4'$,:"'+ 3!2&'( )* !22 +'($,- 1#)1'#"7 $-*2&'-0'( )- !
<&!2$"7 !""#$%&"' !++'+ ") #"8 ":' ('2'0"'+ #!-,' *)# ":'
0)51&"'+ 3!2&'( )* <&!2$"7 !""#$%&"'. C:$( #'(&2"( $- ":'
#'2!"$)-(:$1( (:)4- $- C!%2' N. C:$( (0:'5' *)# 4'$,:"$-,
":' $-*2&'-0'( 4!( 0:)('- %'0!&(' $" 4!( ($512' !-+
("#!$,:"*)#4!#+ ") !1127.
Bansiya and Davis claim that the QMOOD model may
address ”different weightings, other perspectives, and new
goals and objectives” [1]
!"# $%&'('() *(+ ,+*-.'() ./% 01+%2
C:' OP??Q <&!2$"7 5)+'2 !22)4( 0:!-,'( ") %' '!($27
5!+' ") ":' 5)+'2 ") !++#'(( +$**'#'-" 4'$,:"$-,(8 )":'#
1'#(1'0"$3'(8 !-+ -'4 ,)!2( !-+ )%@'0"$3'(. F" ":' 2)4'("
2'3'28 ":' 5'"#$0( &('+ ") !(('(( +'($,- 1#)1'#"$'( 5!7 %'
0:!-,'+8 )# ! +$**'#'-" ('" )* +'($,- 1#)1'#"$'( 5!7 %' &('+
") !(('(( <&!2$"7 !""#$%&"'(8 )# '3'- ":' ('" )* <&!2$"7
!""#$%&"'( ") %' !(('(('+ 0!- %' 0:!-,'+. C:' $-*2&'-0'
#'2!"$)-(:$1( *#)5 +'($,- 1#)1'#"$'( ") <&!2$"7 !""#$%&"'(
[1] J. Bansiya and C. Davis.
A hierarchical model for object-oriented design quality assessment. IEEE
%'81$ H
Transactions
on Software Engineering, 28(1):4–17, Jan 2002.
IJKL=AM 'AAB=NJA;<O:;<=>?
FBEG;BAM &;LKA=E?<P=G<
måndag 25 januari 16
Use proper citation if needed, but only cite if necessary.
Referenshantering
måndag 25 januari 16
Mendeley
måndag 25 januari 16
måndag 25 januari 16
Mendeley
BibDesk
måndag 25 januari 16
måndag 25 januari 16
Att skriva om det du
läst
• Anteckna vad du läst
• Tänk efter vad som behöver vara med i
rapporten. Skriv inte allt du läst (det gör
inte andra). Kom ihåg att ha en stark
koppling mellan frågeställning, teori och
metod
måndag 25 januari 16
Sammanfattning
• Börja lära dig om ämnet, och hitta därefter
granskade källor för att stödja dina påståenden.
• Alla granskade källor bygger på samma
grundläggande förtroendemekanism: andras
omdömen.
• Det finns olika typer av vetenskapliga
publikationer och resultat.
• Plagiera inte, och kopiera inte bilder.
• Använd referenshanteringsprogram för korrekt
typsatta referenser.
måndag 25 januari 16
Download