Department of Computer and Information Science TDT4290

Transcription

Department of Computer and Information Science
TDT4290 Customer Driven Project
Adresseavisen AS
Automatic Import of Completed Ads
Group 15
Audun Skjervold
Erlend Løkken Sigholt
Hong-Dang Lam
Truls Hamborg
Supervisor
Meng Zhu
Customer Representatives
Asle Dragsten Liebech
Jostein Danielsen
Hans Kristian Ormberg
Abstract
This paper describes the process of developing a framework for Automatic Importing of Completed Ads, on request from Adresseavisen AS, which is a major
regional newspaper. It will describe the project, from the preliminary study phase
and project management/organization, to implementation and completion.
The goal is to create a framework which will facilitate automatic importing of
completed real estate ads in the form of pdf-files and associated data, with the
possibility to expand to other types of ads. The accompanying data will be placed
into the internal database of Adresseavisen and their internal order system for ads,
and the pdf is to be saved in their archives.
Adresseavisen, as a customer, is interested in the framework in itself, with
accompanying developer documentation for possible further development. In addition to this, we will produce full documentation of the process as a deliverable
in the course which this project is for.
i
Preface
This document was written for the project-based course TDT4290 Customer Driven
Project, at the Norwegian University of Technology and Science, NTNU during the
fall semester of 2013.
The project team consisted of four students from Computer Science at the
Department of Computer and Information Science at NTNU. The project was
Automated Import of Completed Ads, on behalf of Adresseavisen AS.
The team would like to thank customer representative Asle Dragsteen Liebech
for great support and technological guidance, as well as our supervisor Zhu Meng
for excellent supervising.
ii
Contents
I
Project Introduction
1
1 Introduction
1.1 Project name - Automatic Import
1.2 Customer - Adresseavisen AS . .
1.3 Project Purpose . . . . . . . . . .
1.4 Project Background . . . . . . . .
1.5 Problem Description . . . . . . .
1.6 Existing Technology . . . . . . .
1.7 Stakeholders . . . . . . . . . . . .
1.7.1 Customer . . . . . . . . .
1.7.2 Group Members . . . . . .
1.7.3 Course Staff . . . . . . . .
1.8 Measure of Project Effects . . . .
1.9 Duration . . . . . . . . . . . . . .
of Completed Ads
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
2 Project Management
2.1 Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2 Time schedule . . . . . . . . . . . . . . . . . . . . . . . .
2.3 Work Breakdown Structure . . . . . . . . . . . . . . . .
2.3.1 Estimation methods . . . . . . . . . . . . . . . .
2.3.2 Pre-Study . . . . . . . . . . . . . . . . . . . . . .
2.3.3 Requirements . . . . . . . . . . . . . . . . . . . .
2.3.4 General Project Management . . . . . . . . . . .
2.3.5 Architecture . . . . . . . . . . . . . . . . . . . . .
2.3.6 Technical/API documentation . . . . . . . . . . .
2.3.7 Documentation - Weekly report . . . . . . . . . .
2.3.8 Final Report . . . . . . . . . . . . . . . . . . . .
2.3.9 Implementation - Webassistenten . . . . . . . . .
2.3.10 Implementation - Import-System Service . . . . .
2.3.11 Implementation - Miscellaneous . . . . . . . . . .
2.3.12 Setup and Maintenance of Development Tools and
iii
.
.
.
.
.
.
.
.
.
.
.
.
2
3
3
3
3
4
4
4
4
5
5
5
6
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
Resources
7
8
10
10
10
11
12
12
13
13
14
14
15
16
17
18
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
2.4
2.5
2.6
2.7
2.8
2.9
2.3.13 Totals . . . . . . . . . . . . . . . . .
Gantt . . . . . . . . . . . . . . . . . . . . .
Burndown Chart . . . . . . . . . . . . . . .
Issues . . . . . . . . . . . . . . . . . . . . .
2.6.1 C# Compiler . . . . . . . . . . . . .
2.6.2 GitHub DDoS . . . . . . . . . . . . .
2.6.3 SDM . . . . . . . . . . . . . . . . . .
2.6.4 MSSQL . . . . . . . . . . . . . . . .
2.6.5 ASP.NET Web API . . . . . . . . . .
2.6.6 Naming conventions . . . . . . . . .
2.6.7 LATEX . . . . . . . . . . . . . . . . .
2.6.8 Disk Space . . . . . . . . . . . . . . .
2.6.9 File Transferring . . . . . . . . . . .
2.6.10 Construction Work . . . . . . . . . .
Internal Risks . . . . . . . . . . . . . . . . .
2.7.1 Low experience with the development
2.7.2 Unfamiliarity with technology . . . .
2.7.3 Unfamiliarity with tools . . . . . . .
2.7.4 Illness . . . . . . . . . . . . . . . . .
2.7.5 Other engagements . . . . . . . . . .
2.7.6 Other subjects . . . . . . . . . . . .
2.7.7 Underestimation of implementation .
External Risks . . . . . . . . . . . . . . . . .
2.8.1 Deaths . . . . . . . . . . . . . . . . .
2.8.2 Unreachable Customer . . . . . . . .
Procedures for Quality Assurance . . . . . .
2.9.1 Documentation and report . . . . . .
2.9.2 Group dynamics . . . . . . . . . . .
2.9.3 Customer relations . . . . . . . . . .
2.9.4 Advisor relations . . . . . . . . . . .
3 Preliminary Studies
3.1 Development Methodology
3.1.1 Waterfall . . . . . .
3.1.2 Scrum . . . . . . .
3.1.3 Our choice . . . . .
3.1.4 In Practice . . . . .
3.2 Technology . . . . . . . .
3.2.1 Windows 7, 8 . . .
3.2.2 Ubuntu Linux . . .
3.2.3 OS X . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
iv
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
process
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
18
19
20
21
21
21
21
22
22
23
23
23
23
24
25
25
25
25
26
26
26
27
28
28
28
29
29
29
29
29
.
.
.
.
.
.
.
.
.
30
31
32
33
34
38
39
39
39
39
3.3
3.4
3.5
3.6
3.7
3.8
II
3.2.4 Visual Studio 2012 . . . . . . . . . .
3.2.5 .NET and Mono . . . . . . . . . . . .
3.2.6 MonoDevelop . . . . . . . . . . . . .
3.2.7 Google Chrome with Developer Tools
3.2.8 Doxygen . . . . . . . . . . . . . . . .
3.2.9 LATEX . . . . . . . . . . . . . . . . .
3.2.10 Git . . . . . . . . . . . . . . . . . . .
3.2.11 Trello . . . . . . . . . . . . . . . . .
3.2.12 Web API . . . . . . . . . . . . . . .
3.2.13 Dropbox . . . . . . . . . . . . . . . .
3.2.14 Google Drive . . . . . . . . . . . . .
3.2.15 Microsoft SQL server . . . . . . . . .
3.2.16 Entity Framework . . . . . . . . . . .
3.2.17 Microsoft ASP.NET Web API . . . .
3.2.18 Server . . . . . . . . . . . . . . . . .
3.2.19 Database . . . . . . . . . . . . . . .
Extra Tools . . . . . . . . . . . . . . . . . .
3.3.1 LATEX Editors . . . . . . . . . . . . .
3.3.2 LATEX Compilers . . . . . . . . . . .
3.3.3 Git Tools . . . . . . . . . . . . . . .
3.3.4 LibreOffice Calc . . . . . . . . . . . .
3.3.5 Raw Text Editors . . . . . . . . . . .
3.3.6 Communication . . . . . . . . . . . .
Templates . . . . . . . . . . . . . . . . . . .
Documents . . . . . . . . . . . . . . . . . .
Coding . . . . . . . . . . . . . . . . . . . . .
3.6.1 Documentation . . . . . . . . . . . .
3.6.2 Naming and variables . . . . . . . . .
3.6.3 Comments and layout . . . . . . . .
3.6.4 Variables, types, and declaration . .
3.6.5 Try-catch, exceptions and using . . .
Static Members . . . . . . . . . . . . . . . .
3.7.1 Clean Coding . . . . . . . . . . . . .
APIs . . . . . . . . . . . . . . . . . . . . . .
3.8.1 ASP .NET Web API . . . . . . . . .
Requirements and Architecture
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
39
40
40
40
40
40
41
41
42
42
43
43
43
43
43
44
44
44
45
45
45
45
45
45
46
46
46
47
47
48
49
50
50
51
51
52
4 Requirements
53
4.1 Functional Requirements . . . . . . . . . . . . . . . . . . . . . . . . 54
v
4.2
4.3
Non-Functional Requirements . . . . . . . . . . . . . . . . . . . . . 55
User Stories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
5 Architecture
5.1 Stakeholders . . . . . . . . .
5.1.1 Customer . . . . . .
5.1.2 Implementers . . . .
5.1.3 Course Staff . . . . .
5.2 Quality Attributes . . . . .
5.2.1 Modifiability . . . . .
5.2.2 Performance . . . . .
5.2.3 Availability . . . . .
5.2.4 Interoperability . . .
5.2.5 Readability . . . . .
5.3 Views . . . . . . . . . . . .
5.3.1 Process View . . . .
5.3.2 Logical View . . . .
5.3.3 Scenario View . . . .
5.3.4 Physical View . . . .
5.4 Class diagram . . . . . . . .
5.5 Patterns . . . . . . . . . . .
5.6 Tactics . . . . . . . . . . . .
5.6.1 Modifiability . . . . .
5.6.2 Performance . . . . .
5.6.3 Availability . . . . .
5.6.4 Interoperability . . .
5.6.5 Readability . . . . .
5.7 Changes to the architecture
III
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
58
59
59
59
59
59
59
59
60
60
60
60
60
61
61
62
63
63
63
64
64
64
64
64
64
Implementation
69
6 Sprint 1
6.1 Time Frame . . . .
6.2 Original Plan . . .
6.3 Revised Plan . . .
6.4 Development . . .
6.5 Other Work . . . .
6.6 Backlog . . . . . .
6.7 Customer Meeting
6.8 Retrospective . . .
70
71
71
71
71
72
72
72
73
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
vi
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
7 Sprint 2
7.6 Backlog . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
74
75
75
75
76
76
76
77
77
8 Sprint 3
8.6 Backlog . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
78
79
79
79
79
79
80
80
80
9 Sprint 4
9.6 Backlog . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
81
82
82
82
82
82
83
83
83
10 Web Application Implementations
84
10.1 Microsoft ASP.NET MVC . . . . . . . . . . . . . . . . . . . . . . . 85
10.2 Microsoft ASP.NET Web API . . . . . . . . . . . . . . . . . . . . . 85
11 Testing
11.1 Testplan . . . . . . . . . . . . . .
11.2 Testing Methodology . . . . . . .
11.3 Testing . . . . . . . . . . . . . . .
11.3.1 Functionality and MVC .
11.3.2 WebAPI and Finalization
11.4 Test Results . . . . . . . . . . . .
vii
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
87
88
88
88
88
89
89
11.4.1 Functionality- and MVC-Results . . . . . . . . . . . . . . . . 89
11.4.2 WebAPI-Results and Finalization . . . . . . . . . . . . . . . 90
11.4.3 Implications of Test Results . . . . . . . . . . . . . . . . . . 90
IV
Evaluation and Conclusion
12 Evaluation
12.1 The Process . . . . . . . . . . .
12.2 Quality Assurance . . . . . . .
12.2.1 External Communication
12.2.2 Internal communication
12.3 Implementation . . . . . . . . .
12.3.1 Testing . . . . . . . . . .
12.4 Group dynamics . . . . . . . . .
12.5 Risk management . . . . . . . .
.
.
.
.
.
.
.
.
91
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
92
93
93
93
94
94
95
95
95
13 Conclusion and Future Work
97
13.1 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
13.2 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
Bibliography
100
V
Appendices
101
A Database setup
102
B Templates
104
B.1 Supervisor meeting . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
B.2 Customer meeting . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
B.3 Weekly report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
C Dictionary
108
D Test view
111
D.1 ModuleAPI response . . . . . . . . . . . . . . . . . . . . . . . . . . 112
D.2 API help page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
D.3 Upload successful . . . . . . . . . . . . . . . . . . . . . . . . . . . .
viii
List of Figures
2.1
2.2
2.3
Gantt Chart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Project Burndown Chart . . . . . . . . . . . . . . . . . . . . . . . . 20
SDM error . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.1
3.2
3.3
3.4
Unmodified Waterfall Model [6]
Agile Methods [2] . . . . . . . .
Example Scrum Board [5] . . .
Example Trello Board . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
32
33
36
42
5.1
5.2
5.3
5.4
5.5
5.6
5.7
5.8
Logical View . . . . . . . . . . . . . . . . . . . .
Scenario View . . . . . . . . . . . . . . . . . . .
Physical View . . . . . . . . . . . . . . . . . . .
Digital class diagram . . . . . . . . . . . . . . .
Temporary process view . . . . . . . . . . . . .
Process View of Final Architecture . . . . . . .
Logical View of Final Architecture of MVC . . .
Logical View of Final Architecture of Web API
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
61
62
62
63
65
66
67
68
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
D.1 The Web API help page . . . . . . . . . . . . . . . . . . . . . . . . 113
D.2 The response from Web API, success . . . . . . . . . . . . . . . . .
D.3 The local html file we used to test against the server . . . . . . . .
ix
List of Tables
1.1
1.2
1.3
Customer Representatives . . . . . . . . . . . . . . . . . . . . . . .
Group Members . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Course Staff . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1
2.2
2.3
2.4
2.5
2.6
2.7
2.8
2.9
2.10
2.11
2.12
2.13
2.14
2.15
2.16
2.17
2.18
2.19
2.20
2.21
2.22
2.23
2.24
2.25
Overview of Roles and Responsibilities . . . . . . .
Revised List of Roles and Responsibilities . . . . .
WBS: Pre-Study . . . . . . . . . . . . . . . . . . .
WBS: Requirements . . . . . . . . . . . . . . . . .
WBS: General Project Management . . . . . . . . .
WBS: Architecture . . . . . . . . . . . . . . . . . .
WBS: Technical Documentation . . . . . . . . . . .
WBS: Weekly Report . . . . . . . . . . . . . . . . .
WBS: Final Report . . . . . . . . . . . . . . . . . .
WBS: Implementation - Webassistenten . . . . . . .
WBS: Implementation - Import-System Service . .
WBS: Implementation - Miscellaneous . . . . . . .
WBS: Setup and Maintenance of Tools . . . . . . .
WBS: Totals . . . . . . . . . . . . . . . . . . . . . .
Size of WBS Packages in Whole Days . . . . . . . . .
Gantt Packages and Time Frames . . . . . . . . . . .
Risk: Low experience with the development process
Risk: Unfamiliarity with technology . . . . . . . . .
Risk: Unfamiliarity with tools . . . . . . . . . . . .
Risk: Illness . . . . . . . . . . . . . . . . . . . . . .
Risk: Other engagements . . . . . . . . . . . . . . .
Risk: Other subjects . . . . . . . . . . . . . . . . .
Risk: Underestimation of implementation . . . . . .
Risk: Deaths . . . . . . . . . . . . . . . . . . . . .
Risk: Unreachable Customer . . . . . . . . . . . . .
4.1
Requirements Key
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
4
5
5
8
9
11
12
12
13
13
14
14
15
16
17
18
18
19
19
25
25
25
26
26
26
27
28
28
. . . . . . . . . . . . . . . . . . . . . . . . . . . 54
x
4.2
4.3
4.4
4.5
4.6
4.7
4.8
4.9
Functional requirements . .
Non-functional requirements
User Story: C1 Customer . .
User Story: D1 Developer .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
xi
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
54
55
56
56
56
56
57
57
Part I
Project Introduction
1
Chapter 1
Introduction
This chapter gives a brief introduction to our project, including the customer,
project purpose, project background, problem description among other subjects.
2
1.1 Project name - Automatic Import of Completed Ads
The project is named Automated Import of Completed Ads by the
customer; Adressavisen AS. The team is to create a framework for automatic
import of real estate ads into Adresseavisen’s internal database and order system.
1.2 Customer - Adresseavisen AS
Adresseavisen is a regional newspaper in the Norwegian city Trondheim, and the
surrounding area. It publishes it’s newspaper in Trøndelag and Nordmøre on a
daily basis except on Sundays. It is an independent, conservative newspaper with
a daily circulation of approximately 85000 NOK.
"In addition to the main newspaper, Adresseavisen owns several smaller local
newspapers in the Trøndelag region. They also own and operate a local radio
station, Radio-Adressa, and a local TV station, TV-Adressa (prior to 30 January
2006: TVTrøndelag). They also have a stake in the national radio channel Kanal
24. In addition, the newspaper owns the local newspapers Fosna-Folket, HitraFrøya, Levanger-Avisa, Sør-Trøndelag, Trønderbladet and Verdalingen." [7]
1.3 Project Purpose
The purpose of this project is to create a framework for automated import of
complete ads in the form of pdf-files. The pdf-files will be accompanied by data,
which shall be added to the database and used to create an order in Adresseavisens internal order system for ads. This framework will also be able to provide
customers with certain information that is to be supplied when they wish to have
an ad featured in Adresseavisen, such as available dates and ad-packages.
1.4 Project Background
Adresseavisen currently uses a system where ads to be featured on their website
or published in newspapers are created in their internal order system, with the use
of one of very many templates. This is very complex and an increasing amount of
customers use their own fully completed ads, in the form of pdf-files.
Adresseavisen now has the need for a system which can automate and simplify
the process of receiving these ads into the system, with the purpose of eventually
replacing the old system.
3
1.5 Problem Description
Our plug-in to Webassistenten will take a completed ad in the form of a pdf file
and save it to the appropiate folder. These folders could for instance have the ID
of the customer so that Adressa can easily identify which pdf belongs to which
customer.
Webassistenten will require certain data along with the pdf, such as date to
publish, module type (what kind of format it should be printed as in the newspaper) and which newspaper it will be printed in (known as product). In the case
of real estate ads, the required data also includes locations, zip code, zip area,
address, responsible realtor, phone number of aforementioned realtor, email etc.
These data will be saved into a database internally in their system.
1.6 Existing Technology
There currently exists no technology equivalent to ours that we are aware of. The
technology that Adressa uses today in Webassistenten is different from the product
we’re developing for them in that the current solution doesn’t accept a pdf as input.
Instead it takes in pictures in addition to the accompanying data, and generates
a pdf based on this input.
The already existing alternative that Webassistenten utilizes isn’t as automated
as they would like it to be, and the real estate agents might not get the perfectly
designed ad in the pdf through this auto-generation.
1.7 Stakeholders
1.7.1 Customer
Customer: Adresseavisen AS
Name
Asle Dragsten Liebech
Jostein Danielsen
E-mail
[email protected]
[email protected]
Table 1.1: Customer Representatives
The customer is, along with our group, the most important stakeholder of our
project. The project supplies the customer with a product that hopefully will
improve their business, as well as saving them money they would otherwise have
had to spend developing the product themselves.
4
It is important for the customer that we have a successful project resulting in
a good product because delivering a poor product would require unnecessary work
on their end.
1.7.2 Group Members
Name
Audun Skjervold
Hong-Dang Lam
Truls Hamborg
E-mail
[email protected]
[email protected]
[email protected]
[email protected]
Table 1.2: Group Members
The members of our group are the other most important stakeholders of the
project. This is mainly because the course gives course credit equivalent to two
regular courses, making it more important to achieve a good grade.
1.7.3 Course Staff
Name
Meng Zhu
Reidar Conradi
Role
Group Supervisor
Course Responsible
E-mail
[email protected]
[email protected]
Table 1.3: Course Staff
The course staff are the final stakeholders. The staff wants satisfied customers, and
they want the students who participate in the course to achieve good results. To
accomplish this, we need to deliver a well written report with good documentation
of the project. We also need to keep our supervisor satisfied throughout the project,
supplying him with good under-way documentation.
1.8 Measure of Project Effects
The completed ads produced through our product will in theory not be distinguishable from completed ads produced without it, although the design might
differ from the auto-generated versions that would otherwise have been made. For
this reason, we do not expect to see any effects of this project.
5
We do however hope that Adressa and their customers will see effects in the
form of time and money saved. We also believe that the real estate agents to a
larger extent will find the submitted ads being accepted in the format and design
they want them to be.
1.9 Duration
The introduction to the course started on Wednesday 21.08.2013 when we all met
in S6 for information and were introduced to the customer and the project.
The final delivery is three months after the course start, on 21.11.2013, at which
point we will have a short 45 minute presentation where we introduce the product
and our experience with this course.
6
Chapter 2
Project Management
This chapter contains information about the management of our project. It describes our plans through the Work Breakdown Structure and Gantt diagram, as
well as role distribution, issues we had during the project, and risk analysis. It
also contains our procedures for quality assurance.
7
2.1 Roles
In the beginning of the project we defined the team roles as in the following table.
Role
Scrum Master
Name
Truls Hamborg
Documentation Manager
Truls Hamborg
Product Owner (scrum role)
Adressa
Lead coder
Erlend Sigholt
Secretary
Erlend Sigholt
Implementation manager
Audun Skjervold
Customer and supervisor contact
Hong-Dang Lam
System Architect
Hong-Dang Lam
Test Manager
Everyone
Responsibility
Scrum master/process manager leads the stand-up
meeting. Makes sure the
team follows the agreedupon process.
Ensures documentation coherency.
The customer, owns the
product
Oversees coding conventions and makes sure we
follow the "clean coding"
principles.
Takes notes during meeting(s)
Takes care of learning the
framework and implementation of the code.
Contact-person for customer and supervisor
Create and maintain the architecture of the system
Responsible for testing the
code.
Table 2.1: Overview of Roles and Responsibilities
As the project progressed, the actual roles we fell into changed. Our development methodology changed from the planned scrum to a more sequential method
(see sections 3.1.3 and 3.1.4 for more on this), and as a result roles such as the
Scrum Master were dropped. A table of the new role division can be seen below.
8
Name
Truls Hamborg
Role
Documentation Manager
Hong-Dang Lam
System Architect
Lead Coder
Customer and Supervisor Contact
Project Manager
Implementation Manager
Secretary
Audun Skjervold
Head of Quality Assurance
Technical Advisor
Responsibility
Ensures good design and
structure in internal and external documentation.
Create and maintain the architectural documentation.
Ensure implementation adheres to the documentation and prevent architectural drift/erosion.
Main contributor of code to
the implementation.
Main point of contact between the group and the
customer and supervisor.
Keep track of progress and
keep the group updated and
on course, coordinate the
team and prioritize tasks.
Making final decisions regarding implementation.
Responsible for taking notes
during meetings.
Chief responsible for the
quality of produced documentation.
Help achieve good technical solutions through advice
and guidance based in familiarity with the technology.
Table 2.2: Revised List of Roles and Responsibilities
9
2.2 Time schedule
In this section follows the time planning and schedule, in the form of a Work Breakdown Stucture (WBS), and a Gantt diagram. The Gantt diagram contains the
implementation packages in the form of sprints, seeing as the project plan called for
an agile-like organization of the implementation phase, with multiple iterations on
each implementation package, and the corresponding detailed architecture. More
information on that can be found in the overall project plan chapter.
2.3 Work Breakdown Structure
In this section you will find the main packages of our revised work breakdown
structure.
2.3.1 Estimation methods
The method used to split work into packages, and estimate the total work hours of
the packages was mostly one of cooperative iteration. Work was split into packages
by consensus in a group discussion after analysis of the project, and then assigned
work hours.
Hours were assigned by each member submitting a suggestion, and then the
average of those values was selected, possibly after some discussion if the discrepancies were large. When all packages were assigned such values, they were compared
to each other and adjusted if inconsistencies were found. Then, at the end, the
total sum of all hours were compared to the expected total of hours. This process
was then repeated a few times until a satisfactory result was achieved.
10
2.3.2 Pre-Study
This package contains sub-packages for most the basic work done in the preliminary
studies phase, before the start of implementation. The total number of hours in
this package is 174, or about 9 person days per person.
#
Sub-package
# persons
Hours/person
Total # of
hours
1.1
Choice
and
study of software/tools
Technology
learning
and
acclimatization
Overall
planning/management
Role
distribution
Process/Sprint
planning
Standards
Milestone planning and review
4
2
8
Person-days (ca
5h)/persons assigned
0.4
4
25
100
5
4
8
32
1.6
4
1
4
0.2
4
5
20
1
1
4
2
2
2
8
0.4
0.4
1.2
1.3
1.4
1.5
1.6
1.7
Table 2.3: WBS: Pre-Study
11
2.3.3 Requirements
This package consists of the gathering and analysis of functional and non-functional
requirements. The total number of hours in this package is 10, or 1 person day
per person.
#
Sub-package
# persons
Hours/person
Total # of
hours
2.1
Functional
requirements
Non-functional
requirements
4
2.5
10
Person-days(ca
5h)/persons
assigned
0.5
4
2.5
10
0.5
2.2
Table 2.4: WBS: Requirements
2.3.4 General Project Management
This package contains sub-packages related to project and group management,
such as meetings and managing plans. The total number of hours in this package
is 152, or 7.6 person days per person.
#
Sub-package
# persons
Hours/person
Total # of
hours
3.1
Meetings with
customer(s)
Advisor meetings
Meeting
with
the group (internal meetings not
directed towards
other packages)
Underway administration
Plan
maintenance/updating
4
3
12
Person-days(ca
5h)/persons
assigned
0.6
4
5
20
1
4
5
20
1
4
20
80
4
4
5
20
1
3.2
3.3
3.4
3.5
Table 2.5: WBS: General Project Management
12
2.3.5 Architecture
This package contains sub-packages for the design and documentation of the software architecture. The total number of hours in this package is 55, or 5 person
days per person.
#
Sub-package
# persons
Hours/person
Total # of
hours
4.1
Overall architecture
Detailed architecture
Patterns
Quality
Attributes
2
10
20
Person-days(ca
5h)/persons
assigned
2
3
5
15
1
2
2
5
5
10
10
1
1
4.2
4.3
4.4
Table 2.6: WBS: Architecture
2.3.6 Technical/API documentation
This package contains the sub-packages related to the creation and review of the
technical documentation. The total number of hours in this package is 33, or 3.4
person days per assigned person.
#
Sub-package
# persons
Hours/person
Total # of
hours
5.1
5.2
5.3
Standards
Writing
Review
1
2
4
5
10
2
5
20
8
Table 2.7: WBS: Technical Documentation
13
Person-days(ca
5h)/persons
assigned
1
2
0.4
2.3.7 Documentation - Weekly report
This package contains all sub-packages related to the creation of the weekly reports
for the meetings with our advisor. The total number of hours in this package is
16, or 0.8 person days per person.
#
Sub-package
6.1.1 Agenda
6.1.2 Hours planned &
work done
6.1.3 Finalization
# persons
Hours/person
Total # of
hours
4
4
1
2
4
8
Person-days(ca
5h)/persons
assigned
0.2
0.4
4
1
4
0.2
Table 2.8: WBS: Weekly Report
2.3.8 Final Report
This package consists of the writing of the various parts of this final report. The
total number of hours in this package is 210, or about 11.5 person days per person.
#
Sub-package
# persons
Hours/person
Total # of
hours
7.1
7.2
7.3
7.4
Pre-study
Architecture
Documentation
Implementation
4
2
4
4
12.5
10
20
15
50
20
80
60
Table 2.9: WBS: Final Report
14
Person-days(ca
5h)/persons
assigned
2.5
2
4
3
2.3.9 Implementation - Webassistenten
The sub-packages in this package are the parts of implementation related to the
interoperability of our product with the customer’s already existing system
Webassistenten. The total number of hours in the package is 30, or 3 person days
per assigned person.
#
Sub-package
# persons
Hours/person
Total # of
hours
8.1
Enable display
of
available
products
(no
GUI is to be
implemented)
Listing the next
5 available booking dates for a
selected product
Listing modules
available for a
selected product
2
5
10
Person-days(ca
5h)/persons
assigned
1
2
5
10
1
2
5
10
1
8.2
8.3
Table 2.10: WBS: Implementation - Webassistenten
15
2.3.10 Implementation - Import-System Service
This package contains the sub-packages that are the parts of implementation related to importing files and data, and placing the data into the database. The
total number of hours in the package is 60, or 6 person days per assigned person.
#
Sub-package
# persons
Hours/person
Total # of
hours
9.1
Receiving pdffile and save in
correct folder
Putting accompanying data in
Webassistenten
database (table
“prospekt”)
Checking
accompanying
data for required fields
Placing an order
in the internal
order system
2
5
10
Person-days(ca
5h)/persons
assigned
1
2
10
20
2
2
5
10
1
2
10
20
2
9.2
9.3
9.4
Table 2.11: WBS: Implementation - Import-System Service
16
2.3.11 Implementation - Miscellaneous
This package contains the rest of the sub-packages related to implementation. The
total number of hours in the package is 200, or 17 person days per assigned person.
#
Sub-package
10.1 Database communication
interface (Entity
Framework)
10.2 Bugfixing
10.3 Workarounds
10.4 Testing
10.5 Underway learning
# persons
Hours/person
Total # of
hours
2
10
20
Person-days(ca
5h)/persons
assigned
2
2
2
4
4
30
30
15
20
60
60
60
80
6
6
3
4
Table 2.12: WBS: Implementation - Miscellaneous
17
2.3.12 Setup and Maintenance of Development Tools and Resources
Because of the sheer number of various development tools and versions of those
tools we had to install and use, we created a package for the installation and
maintenance of these tools. The total number of hours in this package is 88, or
4.4 person days per person.
#
Sub-package
11.1 Database Setup
11.2 Visual
Studio Setup and
Installation
11.3 Version control
system
11.4 Configuration
and
maintenance of software packages
etc.
# persons
Hours/person
Total # of
hours
4
4
10
5
40
20
Person-days(ca
5h)/persons
assigned
2
1
4
2
8
0.4
4
5
20
1
Table 2.13: WBS: Setup and Maintenance of Tools
2.3.13 Totals
The total time in in all our packages are listed in the following table.
# persons
4
Hours per person
279.5
Total # of hours
Person days per person
1118
55.9
Table 2.14: WBS: Totals
18
2.4 Gantt
#
1
2
3
4
5
6
7
8
9
10
11
WBS Package
Pre-study
Requirements
General project management
Architecture
Technical/API documentation
Documentation
Report
Implementation - Webassistenten
Implementation - import-system service
Implementation - Misc.
Setup and Maintenance of Development
Tools and Resources
Size (Whole days)
9
1
8
5
4
1
12
3
6
18
4
Total:
71
Table 2.15: Size of WBS Packages in Whole Days
Gantt package name
Pre-study (Includes requirements)
Requirements
General project management and
documentation
Sub-package: Overall architecture and Quality Attributes
Technical/API documentation
Report
Sprint 1 (8, 9, 10, 4.2 and 4.3)
Sprint 2 (8, 9, 10, 4.2 and 4.3)
Sprint 3 (8, 9, 10, 4.2 and 4.3)
Sprint 4 (8, 9, 10, 4.2 and 4.3)
Setup and Maintenance of Development Tools and Resources
Size (Whole days)
9
Start
21.08
Finish
30.08
1
9
30.08
21.08
6.09
21.11
2
9.09
13.09
4
12
10
10
10
10
4
28.1
30.08
16.09
30.09
14.1
28.1
21.08
7.11
20.11
27.09
11.1
25.1
8.11
Table 2.16: Gantt Packages and Time Frames
19
Figure 2.1: Gantt Chart
2.5 Burndown Chart
Figure 2.2: Project Burndown Chart
Red: Planned hours worked. Blue: Hours worked
20
2.6 Issues
The project did not go as smoothly as we had hoped. The group agreed on pretty
much everything, but the issues we had were mostly related to the software and
tools not cooperating or working as we expected.
2.6.1 C# Compiler
When we tried to add the database to our project via the Entity Framework we had
troubles with the C# compiler not being found. This was due to the installation
of the Visual Studio 2012 Release Candidate edition (which had expired), so we
had to uninstall this RC version to install the "normal" Visual Studio 2012 which
lead to the compiler not working - we couldn’t add new items, compile or make a
new project.
There was however a quickfix to repair the compiler by using the gacutil utility
software included with Visual Studio 2012. This command in cmd fixed it:
gacutil /u Microsoft.VisualStudio.CSharp.Services.Language.Interop
2.6.2 GitHub DDoS
On October 14, the day of the midterm delivery, GitHub experienced a DDoS
attack. This resulted in some of the files we were working on for the report
becoming locked mid-commit and mid-pull, and preventing us from performing a
new git pull. This also prevented some of us from compiling, due to a previous
commit containing errors having been pulled.
2.6.3 SDM
NTNU’s Gurutjenesten offers a free MSDNAA account which we can use to download Microsoft software from MSDN software center (Microsoft Developer Network). To download software from MSDN we had to use Secure Download Manager (henceforth referred to as SDM), by opening the .SDX file obtained from the
MSDN webpage. The download went fine however the unpacking of the files gave
us an unknown error without any further information.
21
Figure 2.3: SDM error
2.6.4 MSSQL
The installation of MSSQL did not go as smoothly as we had hoped for, we tried
to install the MSSQL Management Studio Express first, but this did not install a
server instance of the database so we couldn’t restore the backup dump we received
from the customer. When we had installed a server instance there was problem
finding the database dump file - the database dump file needs to be in the correct
folders, otherwise the management studio software won’t be able to see it. The
backup dump was also too big for an express version.
2.6.5 ASP.NET Web API
During our adaptations of functions from ASP.NET MVC to Web API, we ran
into several problems. The first one was that our unfamiliarity with the technology required us to do some testing before we managed to follow the API conventions, which were different from most similiar conventions that we were familiar
with. The next issue was that WebAPIs model binding feature does not play
well with Entity Framework classes, something which proved to be the cause of a
large amount of time spent troubleshooting. Finally, we ran into issues with data
formatters when Web API was supposed to automatically parse input data from
HTTP Request bodies, but didn’t, which also was a timesink for troubleshooting
and solutions.
22
2.6.6 Naming conventions
A table in the database was named "System" which collided with the namespace
"System" in C#. This was due to the EF generating a System.cs file which was
used instead of the actual System namespace whenever there was a
using System .*;
statement in our code.
2.6.7 LATEX
Most of the group members had previous experience with LATEX beforehand,
though none of us have used it to create as large a report as this current one.
Most of us have used sections and subsections, but in this report we needed stuff
like subsubsubsections which do not exist in LATEX. We also had problems with
placing figures/pictures at the correct position in the document, because LATEX
tries to optimize the text and figures so there’s less blank space in the document,
however this jumbled our ordering of chapters, figures and text. We also had
problems with tables to make them appear decent looking.
2.6.8 Disk Space
SSDs tend to be very expensive compared to normal HDD (when comparing cost
per byte - however the average SSD are somewhere around 30% faster than the
average HDD). Because all of the members in our group have an SSD as their
system drive, we experienced problems with limited disk space. Because Windows
isn’t the main OS for everyone, we had to install it on top of the main OS on some
of the computers. Windows 7 needs 30 GiB disk space, and including all the tools
needed to get the code up and running (all the development tools and database
import etc.) there need to be somewhere around 60 GiB of free space on the disk.
2.6.9 File Transferring
Because the database backup dump was 10.8GiB it was not feasible to download
the file via Adressa’s server. The customer brought a copy of the file for us on an
external USB HDD. We ended up with a copy of the file on one of our computers,
but had trouble transferring it to another machine without an external HDD. USB
memory sticks were not viable because they are usually less than 10GiB and FAT32
format which has a maximum file size limit of 4GiB.
23
2.6.10 Construction Work
The IT building at NTNU has been under construction work since the summer
of 2013, and has therefore been affected by a lot of construction noise. This was
quite a disturbance when we were attempting to work.
Some of the rooms in the building were also off limits during certain periods,
thus limiting our possible workplaces drastically. We were only able to book a
room on Wednesdays between the hours of 10 and 14 and Thursdays from 10 to
16, leaving us to search for available rooms whenever we wanted to work together
during other time slots.
24
2.7 Internal Risks
2.7.1 Low experience with the development process
What:
Probability:
Impact:
Action:
The group doesn’t have much experience with lengthy projects
High
Low-High
Reduce by regularly reviewing progress and making use of
supervisor meetings etc.
Table 2.17: Risk: Low experience with the development process
2.7.2 Unfamiliarity with technology
What:
Probability:
Impact:
Action:
Some members of the group have no experience with the
programming language in use, and only one has used the
relevant framework. Will require extra time for learning.
Moderate
Low-Moderate
Reduce by group members with experience
coaching others in the relevant technology
and practices. Set time aside for learning.
Table 2.18: Risk: Unfamiliarity with technology
2.7.3 Unfamiliarity with tools
What:
Probability:
Impact:
Action:
Some members of the group have no experience with
the tools we’re using, it’s complicated to
install due to the different versions of the tools.
Additionally, there are a lot of tools needed to start.
Moderate
Low-Moderate
Reduce by group members with experience
coaching others in the relevant technology
and practices. Set time aside for learning.
Debugging via Google.
Table 2.19: Risk: Unfamiliarity with tools
25
2.7.4 Illness
What:
Probability:
Impact:
Action:
As winter approaches, the probability of group members becoming
ill increases. Being a small group, this might be critical.
Moderate
Low-High
Do not tailgate deadlines. Work steadily, and have margins
and practices. Expect some members to not produce at 100%
every week.
Table 2.20: Risk: Illness
2.7.5 Other engagements
What:
Probability:
Impact:
Action:
Group members have extracurricular activities that require time
on certain dates during the semester.
This might cause absence and/or reduced work-output.
Moderate
Low
Plan for it well in advance. It seems however that the time required
is fairly concentrated and/or pre-planned, so it should be easy to
plan around.
Table 2.21: Risk: Other engagements
2.7.6 Other subjects
What:
Probability:
Impact:
Action:
Customer driven projects isn’t the only subject we’re assigned to
this semester. The other subjects might have projects too so we
might not be able to allocate enough time for the project.
High
Moderate
Try to plan for it in advance. All the courses have
clear deadlines and we should be able to plan ahead.
Table 2.22: Risk: Other subjects
26
2.7.7 Underestimation of implementation
What:
Probability:
Impact:
Action:
We have estimated that the implementation scope is
not a significant majority of the project, and possibly
even smaller than the process and documentation parts.
If we somehow have misjudged this, we will face
significant delays/increased workload when the plan will have to
be adjusted.
Low
High
Ensure to plan for more time for the project than we expect to need.
Do not rush the pre-study, and familiarize ourselves sufficiently with
all aspects.
Ensure we have time to work overtime if necessary during the
implementation period/sprints.
Table 2.23: Risk: Underestimation of implementation
27
2.8 External Risks
2.8.1 Deaths
What:
Probability:
Impact:
Action:
There’s always a chance of a family member passing away, leading to
absence.
Low
High
Be understanding, try to reschedule working hours.
Table 2.24: Risk: Deaths
2.8.2 Unreachable Customer
What:
Probability:
Impact:
Action:
Customer might be on vacation, in a meeting or not able to respond
instantly.
This affects development and database setup the most.
Medium
Low
Wait and call again or send and email or short message service
Set up our own local database
Table 2.25: Risk: Unreachable Customer
28
2.9 Procedures for Quality Assurance
This section is about our routines to ensure the quality of the project - both
including the product and its report.
2.9.1 Documentation and report
All written material produced by the group should be proof-read by at least one
of the other group members. All meeting agendas and minutes will follow the
template as shown in Appendix B on page 104.
2.9.2 Group dynamics
Inside the group, all the communication will be done in Norwegian. We have
working hours each weekday from 10:15 except Tuesdays. We start each working
day with a status report from each member. Communication is done by email,
Skype, SMS and Facebook.
2.9.3 Customer relations
There will be meetings with the customer regularly to keep in contact and be sure
that we don’t miss important details about the product. All the communication
with the customer will be done in Norwegian. They can be translated to English
if need be.
2.9.4 Advisor relations
There will be meetings with the Advisor regularly. We started out weekly, but
when the sprints started we decided to have them between every sprint. Any
information which the Advisor should comment on or read should be sent to him
24 hours before the meeting. All contact with the Advisor will be done in English.
29
Chapter 3
Preliminary Studies
This chapter contains the information we found in our preliminary studies, and
the choices we made from the information we gathered. Covered here are processrelated topics such as development methodology, pros and cons of these, and which
we chose, as well as technology-related topics such as frameworks and standards.
30
3.1 Development Methodology
The course compendium proposes two types of development methodologies: the
sequential method Waterfall, and the agile method Scrum. This section supplies a
brief introduction to these two approaches, followed by our argumentation for and
against the two approaches in the case of our particular project. This subsequently
followed by a conclusion as to which approach(es) we chose for our project.
31
3.1.1 Waterfall
The Waterfall development method is a sequential design process. It is divided
into clearly defined, mostly separated phases, although there often is some overlap
between them.
The first phases focus on gathering requirements and writing initial documentation like design/architecture. Later phases move on to actual implementation,
then testing and verification, followed by final report. Maintenance after a "completed" project is also in some cases a part of the process.
The unmodified waterfall model is shown in the following figure.
Figure 3.1: Unmodified Waterfall Model [6]
32
3.1.2 Scrum
The scrum development method is an agile approach to development. It is an
iterative process consisting of several cycles or iterations. Each cycle, called a
Sprint, lasts a set length of time, typically one week to one month (7-30 days).
Within each of these cycles, most of the phases of a sequential method are
covered. A sprint starts with a sprint planning session, where tasks to be completed
in the sprint are planned and prioritized. The majority of the sprint consists of
completing these tasks, which usually are parts of the solution that then needs to
be integrated into the complete product. The sprint should result in a functioning
prototype, presented to the customer at the end of the sprint to receive feedback
for the next sprint, and concludes with a sprint review meeting.
The following figure depicts the typical flow in agile methods.
Figure 3.2: Agile Methods [2]
33
3.1.3 Our choice
Each of the proposed methods have their own advantages and disadvantages, that
make each of the methods respectively a better or worse fit for our project than
the other.
While the different methods have various advantageous features, not all of these
are applicable to our particular project, and others are negligible.
Below we have highlighted the most important advantages and disadvantages
of each method, while discussing whether or not the particular point is relevant to
our project, leading to a conclusion and our choice of method.
Waterfall
The following points are advantages of using the Waterfall method for projects,
both in general and for ours specifically.
• Waterfall is suitable for small projects because they are manageable to fully
plan up front. This fits our project description.
• It is easier to get every involved party on the same page with a thorough
plan, such as provided through the Waterfall method’s early phases. This
is beneficial to any project, but even more so in one such as ours, where
the team consists of students who may have other projects in other courses
running in parallel with this.
These next points are generally advantages of the Waterfall method, but are mostly
not applicable for our project for various reasons.
• Waterfall is a good method if you know everything about the project beforehand, or are able to acquire the required information and the full project
specification before the implementation phase. Due to the course schedule
and the relatively limited time frame of our project, we felt we needed to
start implementation earlier than a long planning and requirements phase
would allow.
• Sequential methods require little under-way feedback. This gives them the
edge over agile methods when access to the customer is restricted but specifications are expected to remain the same. While the specifications for our
project were expected to remain unchanged, our goal was to include the
customer in the process.
• The method supplies strong documentation as the first phases are focused entirely on creating these documents. However, while the course relies heavily
34
on documentation, the customer had no use for most of this documentation,
making this point less important for our project.
Lastly we have the biggest disadvantage of following a sequential method, which
applies to any project doing so.
• Sequential methods don’t handle change to the requirements particularly
well, making this approach risky in the case of the customer wishing to
modify the requirements during the implementation phase.
Scrum
Advantages of agile methods such as scrum include the following:
• Agile methods support rapid production of prototypes to present to the customer. This allows for easier correction of misunderstandings, because they
become apparent earlier in the process through the functioning prototypes.
• The method utilizes stand-up meetings, a scrum master, and optionally (and
preferably) a scrum board. These things do carry overhead, but provide both
the team and customer with frequent feedback, making the benefit much
greater than the disadvantage of the overhead.
35
Figure 3.3: Example Scrum Board [5]
• The approach is highly supported by online tools - e.g. Trello for the scrum
board - that let both parties (the team and the customer) stay up-to-date
on the planning and prioritizing of tasks during implementation.
While the next point generally is an advantage of agile development over a sequential process, it does contain some risks for a small project such as ours, as
explained below.
36
• Agile methods handle change to requirements very well, due to the high level
of underway involvement of the customer. The risk of weighting this point
when deciding on an approach is the possibility that there simply will not
be many changes, making this point irrelevant. Because we expected there
to be necessary changes to the requirements and specification during the
implementation, we decided this was important for our project.
There is one major disadvantage - or rather, risk - of choosing an agile approach.
• Agile methods rely on team members - or at least the project manager having experience with the full development process, assuming the entire
project is to be completed in agile fashion.
There is another important point when using an agile method, which can be the
deciding factor for some projects.
• Iterative approaches are heavily reliant on easy access to the customer for
continuous feedback and extraction of requirements. This is okay for our
project, as our customer is readily available through both e-mail and phone.
From our analysis of the two methods, we concluded that neither were a perfect
fit for every part of our project. We felt that our inexperience with projects such
as this one made it too difficult to complete the entire project through an agile
process, but we felt too unsure about the scope of the project to plan everything
ahead and do a straight sequential process. We did, however, wish to plan an
outline for the project, create a general architectural overview and gather the
most important requirements before we started implementation.
This led us to a decision of employing the waterfall method (or at least something similar) for the overarching process, with a relatively long period of planning
before starting implementation.
The customer suggested using an agile approach for implementation because it
is the same as they use. Using the same method as the customer might be beneficial
to the project, as it improves communication and work flow. We decided to complete the implementation phase as an agile process, divided into two-week sprints,
each consisting of a sprint planning meeting, then several days of implementation,
with semi-daily stand-up meetings, and ending in a sprint review meeting and a
functioning prototype.
37
3.1.4 In Practice
While we planned to utilize a combination of the two methods as described above,
we ended up with something a little different in practice.
The product proved to not be trivial to implement in agile fashion, because it
could not easily be divided into small parts or tasks. Because of this, we ended
up with very much a top-down approach, having to spend a lot of time on the big
things before we could do the little things. This led to a sequential type of process
also during implementation, as opposed to the agile iterative process we wanted
to employ.
While the process didn’t go quite as we had planned, we did manage to employ
some parts of scrum. We didn’t have official stand-up meetings, but the way we
started each day of development by letting each other know how things were going
and what we’d been working on was indeed very reminiscent of this aspect of agile
development.
We also kept a scrum board updated during each sprint to keep track of the
smaller tasks we were able to separate out from the rest, as well as the larger parts
that needed to be completed, such as figuring out the data flow and creating the
structure needed to satisfy this.
The most important aspects of agility that we utilized in our process were the
sprint planning meetings and end-of-sprint feedback sessions. We ended each sprint
with a customer meeting - as one should when working agile - to both figure out if
we were on the right track and what we had produced so far was satisfactory, and
to ascertain whether there would be changes in the requirements. The planning
meetings allowed us to more loosely plan the project because we were only focusing
on a relatively short period of time when making those plans.
Each customer meeting was followed by an internal sprint review session. These
sessions consisted of discussing both what we learned in the customer meeting and
otherwise during the sprint - such as the fact that we had been overly optimistic
in our planning of Sprint 1.
While we didn’t produce functioning prototypes for each sprint, the iterations
still served a purpose. The repeated process of planning, implementing and then
reviewing the previous period let us continuously improve, making better estimates
of how much we’d be able to do in a single sprint. The frequent contact with the
customer let us know when we were on track and figure out crucial changes in
time. Had we not kept the customer as involved, we might not have been able to
finish the product with as high quality and degree of customer satisfaction.
38
3.2 Technology
This subsection covers the technology we utilized during our project. It covers
the various operating systems our group members have been working on, editors
and IDEs for documents and code, as well as frameworks and platforms used
in development. Additionally it covers tools for version control and file sharing
between the group members, as well as communication platforms.
3.2.1 Windows 7, 8
Microsoft Windows 7 and Windows 8 are operating systems by the Microsoft
Corporation. They logically provide good support for .NET developments, seeing
as .NET targets the Windows platform and is made by Microsoft. Visual Studio
is made for Windows, and was our main IDE, so all group members had access to
PCs with Windows installed.
3.2.2 Ubuntu Linux
This OS is perhaps the most widely used distribution of Linux, developed by
Canonical Ltd. It provides good support for many development tools, except of
course Windows development. However we did find support for using it for some
Windows development. This operating system was used by one group member on
a laptop, when working on-site at NTNU. For coding, Mono with MonoDevelop
was used, while other tasks were mostly unaffected. The operating system provides
good support for other parts of the process, such as Git and LATEX.
3.2.3 OS X
OS X1 is the main operating system for the Macs developed by Apple. It is
based on the Mach kernel and as Ubuntu Linux it provides good support for many
development tools, except Windows development. One of our group members is
running OS X. He used OS X for writing documentation and rebooted to Windows
when writing code.
3.2.4 Visual Studio 2012
Visual Studio is Microsoft’s IDE for development for their platforms. This is the
main IDE we developed the framework on, seeing as it has very good integration
with C# and .NET platforms, which we were required to use. We decided to use
the Ultimate version because this version provides everything we might need.
1
http://en.wikipedia.org/wiki/OS_X
39
3.2.5 .NET and Mono
We were required to use ASP .NET MVC for our framework. ASP .NET MVC
is a framework for web applications which enables the use of the Model View
Controller (MVC) pattern. It is part of Microsofts .NET Framework suite, which
is the preferred way of interactiong with Windows systems and OSes.
Mono is the open source-, cross-platform version of the .NET suite, which we
used when not developing on Windows machines. It is available both for Windows,
OS X, most Linux Distributions, Android, and various other operating systems.
3.2.6 MonoDevelop
This is an open source IDE for development with Mono, available for OS X and
most Linux distributions. This was the IDE used when not developing on Windows
machines.
3.2.7 Google Chrome with Developer Tools
In the course of the project we made use of Google Chrome’s Developer Tools to
examine the HTTP messages that were sent in the testing of the project. Chrome’s
Developer Tools is one of many similar tools that allows examination of HTTP
requests and replies, and was chosen merely for convenience, because group members already had it installed. The console in the developer’s view can be used to
write JS in realtime.
3.2.8 Doxygen
Doxygen is a documentation generator that generates software reference documentation directly from source file comments and tags. It supports multiple programming languages, and outputs documentation in several formats, including, but not
limited to: HTML, LaTeX, and man pages.
We used Doxygen in our project to generate the API documentation requested
by the customer. It was chosen due to easy setup and configuration, support
for C#’s XML-comments and tags, as well as multi-platform support (Windows,
Linux and Mac OS X).
3.2.9 LATEX
We quickly chose LATEX for our typesetting, due to it being the de-facto standard for academic typesetting, with good support for both code snippets, tables,
references and bibliography.
40
Most of our group also had at least some experience using it, and some were
quite experienced, which made the choice easier.
3.2.10 Git
For our version control and source repository, we chose Git. This because we had
most experience with it, and found it easy to set up via GitHub (where we all
had accounts already). It also has the advantage of being distributed, so we could
avoid a single point of failure, and having a staging area where one can selectively
commit files according to whether they’re ready or not, instead of risking accidental
changes which might break something.
Both the source code and the entirety of the report source files were stored on
GitHub, since both would be catastrophical to lose, and were quite important to
have under version control in case we needed to track problematic changes.
To communicate with GitHub, we used various tools. Some of us used the built
in terminal with git installed, and some of us used GitBash. Git for windows was
also used on rare occasion.
3.2.11 Trello
To support our agile process and sprints, we used Trello for planning and control
of work flow. It is an online Scrum Board tool, where we can create work packages
and issues, while tracking who does what, and tracking backlog, finished modules,
and work in progress.
41
Figure 3.4: Example Trello Board
The above figure shows an example Trello board. You create cards (tasks) and
lists to contain and separate those cards into categories, such as Backlog, ToDo,
In Progress, Testing and Completed. The tasks can be assigned to the members
of the board, and there are handy functions available such as adding checklists to
cards to keep track of sub-tasks.
3.2.12 Web API
ASP.NET Web API is a framework for building web APIs on top of the .NET
Framework, it lets you create calls from the browser to the methods in the code,
this can be done via parameters or via JSON. The web API framework returns a
JSON-format of the given item, table or whatever was requested.
3.2.13 Dropbox
Dropbox is a syncing service that let you choose a local folder on your machine
that will be synced to the cloud. Dropbox lets you share folders and files inside a
shared Dropbox folder.
We used Dropbox for sharing and synchronizing internal documents that usually were only useful for a limited time, but might be referenced later.
42
3.2.14 Google Drive
Google Drive is Google’s productivity suite/office pack. The difference between
Drive and other office solutions (like Microsoft Office, OpenOffice/LibreOffice) is
that Drive exists in the cloud and lets the user simultaneously work on a document.
Google Drive was used for simultaneous collaboration on documents, where the
content was up for discussion, or it was advantageous to see what the others where
writing, as well as for dynamic internal documents like work logs.
3.2.15 Microsoft SQL server
The customer uses Microsoft SQL server as their database, and we received a
backup dump of their database. MSSQL is a relational database management
system developed by Microsoft. The first version of MSSQL was released in 1989
- a 16 bit version for OS/2 2 . The latest version of MSSQL is MSSQL version
11 (called MSSQL Server 2012 - codename Delali). There will be a new version
coming out in 2014 - MSSQL Server 2014 (version 12).
3.2.16 Entity Framework
The customer’s preference was that we utilized Microsoft’s Entity Framework to
connect to the database. The Entity Framework is an object-relational mapper
that enables .NET developers to access the database without writing the typical
data-access code that developers typically need to write. EF lets the developer
work with domain specific object and properties without worrying about the underlying database table.
3.2.17 Microsoft ASP.NET Web API
Web API is a framework for building request-reply web services from Microsoft.
The customer requested that we make use of this framework to ensure smooth
integration in their systems. It will be covered in detail in appropriate sections
later in this report.
3.2.18 Server
To run the Web API framework there’s IIS Express that comes with visual studio
2012. The express version is meant to be used for developing purposes, when
deploying the product a full version of IIS should be used.
2
http://en.wikipedia.org/wiki/OS/2
43
3.2.19 Database
We had a lot of problems with the database, the customer said he’d put up a
database server for us to use. However this turned out to be difficult to achieve
due to the security/confidentiality issues on their server. We had to try to set up
the database server ourself on our local machine. This proved to be rather difficult
due to Microsoft tools not giving enough information, and thereby not installing
the necessary tools. Some of us communicated via SMS and phone services.
The customer uses an MSSQL server and they provided an 11 GiB .bak file
which we could use to restore the database.
3.3 Extra Tools
3.3.1 LATEX Editors
We have used several editors for our LATEX documents. Some members have used
TeXstudio, others have used TeXworks, while others again have used Gummi.
TeXworks is a simple, lightweight working environment for LATEX documents,
and is modeled on TeXShop. It provides several compilers, and a raw text editor,
as well as a pdf viewer, but little else.
TeXstudio, a fork of Texmaker, is better described as an integrated development
environment (IDE). Relative to TeXworks, it better supports simultaneous work
on several LATEX documents. It also supplies multiple compilers, a pdf viewer and
a text editor, but it includes some nice-to-have features that are not available in
TeXworks. Some examples of these features are:
• Easy navigation between included files
• Compilation of main document directly from included files
• View included images through hover
• Keyboard shortcuts for often used functions
Gummi is a free, open-source, lightweight working environment for LATEX which
is available in the repositories of most widely used Linux distributions, and for
Windows as well. It provides live preview of the document without manual compilation, support for multiple compilers, bibliography management, and SyncTeX
support. It also provides easy insertion of tables and images.
44
3.3.2 LATEX Compilers
We have also used several LATEX compilers, most notably pdfLaTeX and BibTeX.
We have used BibTeX specifically to handle citations and references, and pdfLaTeX
for general compilation of our documents.
3.3.3 Git Tools
We have used various tools for Git, such as Git Bash and GitHub For Windows, as
well as Git for Linux. GitHub For Windows is a graphical user interface for Git,
and provided good visualization of branching, while Git Bash and Git for Linux
were used for straight-forward commit, pull and push.
3.3.4 LibreOffice Calc
Is an open source version of MS Excel. LibreOffice is a spread sheet software used
for organizing data. We used this to organize the parameters that we needed in
our implementation and as a temporary copy-paste buffer to get access to different
data in certain columns for easier macro editing in sublime.
3.3.5 Raw Text Editors
A variety of raw text editors were used, mainly for meeting notes and similar small
and temporary documents. Sublime Text was used by most of the group, allowing
us to read and edit text files with no file ending. Some also chose to use gedit.
3.3.6 Communication
Various software was used for communication when the group members were at
separate locations. Foremost of these were Facebook Messenger and e-mail. We
also used IRC, to which some connected through means such as PuTTY, to connect
through ssh to a server running irssi in screen, while others ran mIRC locally or
connected through ssh in another terminal (such as the native terminal of their
OS).
3.4 Templates
We have created the following templates for documents used in the process:
• Supervisor meeting agenda template, found in B.3 on page 106
45
• Naming standards for documents, found in B.1 on page 104
• A spreadsheet template for logging hours worked, which automatically showed
the last thing we worked on, the sum of total hours per person, the total sum
of working hours for all and the last date we had worked (not included in
this report)
We have established several standards for the project, as seen in the rest of this
section.
3.5 Documents
For internal documents we have established the naming standard:
MM_DD_<Description>_<Version if applicable>
This is to ensure documents are properly sorted, and that they are easily identifiable.
3.6 Coding
We will be using C# as a programming language, and will consequently be following the C# coding standards, as outlined by Microsoft. [4]
The guidelines are summarized in the following section.
3.6.1 Documentation
All public classes, methods, and preferably properties/fields shall be documented
with comments which will enable generation of documentation. Example:
// / < summary >
// / This is a summary of what the class contains and
its intended function
// / </ summary >
// / < author > Author Name </ author >
public class ExampleClass
{
// / < summary >
// / This summary tells what the method does ,
any side - effects , and how / why to use it .
46
// / It should NOT say how the method does what
it does , unless this is absolutely
neccessary .
// / </ summary >
// / < param name =" intName " > int </ praram >
// / < param name =" stringName " > String </ praram >
// / < returns > String </ returns >
// / < author > Author Name </ author >
public abstract String ExampleMethod ( int
intName , String stringName ) ;
}
3.6.2 Naming and variables
Use CamelCase for classes, method names and properties. Example:
public class ExampleClass
{
public abstract void ExampleMethod ( int intName ,
String stringName ) ;
private int ExampleProperty { get ; set ; }
}
Variables shall be named after the lowerUpper scheme, where the first word is
in lowercase, and any others starts with an uppercase letter. Example:
int exampleVariable = 1;
int stringExample = " This is an example " ;
3.6.3 Comments and layout
Blocks shall start and end with curly brackets on their own line.
Comments shall have a space between the double slashes and the actual comment. Continuation lines shall be indented. All comments shall start with a capital
letter, and end with a period.
There shall be only one statement per line. The same goes for declarations.
Parantheses shall be used to separate clauses in expressions, to ease understanding.
// This is a single line comment
void Foo ()
47
{
// The following is correct :
int x ;
int y ;
// The following is incorrect :
int x , y ;
// This is a multi line comment , with more text
this is line two of a multi line comment
if ( true )
{
StatementOne () ;
StatementTwo () ;
if (( var1 && var2 ) || ( var3 && var4 ) )
{
Bar () ;
}
}
}
3.6.4 Variables, types, and declaration
Implicitly typed local variables can be used when the right hand side clearly indicates type, or it’s not important.
Use in-line instantiation with constructors when possible, instead of instantiation and assignment.
Short strings shall be appended with the use of the + operator. Longer ones
in loops shall use StringBuilder.
Example:
// Apparent use of string . Use of var ok :
var name = " SampleString " ;
// Type inconsequential :
foreach ( var v in collection )
{
48
// Type - independent method :
handleVar ( v ) ;
}
// Array instantiation with constructor :
int [] numbers = { 1 , 2 , 3 , 4 };
// Use of var requires explicit instantiation
var numbers2 = new int [] { 1 , 2 , 3 , 4 };
// Avoid this if you could have used the above :
int [] numbers3 = new int [4];
numbers3 [0] = 1;
numbers3 [1] = 2;
// Etc .
// Short string example
string simpleString = " This is our " + var1 +
" test - string . " + var2 + " something . "
// String builder example
string longString = " LongLongLong " ;
var longBuilder = new StringBuilder () ;
for ( int i = 0; i < 1000; i ++)
{
longBuilder . Append ( longString ) ;
}
3.6.5 Try-catch, exceptions and using
Exception handling shall be done by try-catch statements. Code shall not unexpectedly throw exceptions; only when something unrecoverable has happened.
In the case of a try-finally statement, a using statement shall be used instead,
if the only function of the finally-block is disposing/closing of the used object.
Socket socket = new Socket () ;
try
{
socket . SomeMethod () ;
}
49
finally
{
socket . Close () ;
}
// Can be replaced by :
using ( Socket socket = new Socket () ;)
{
socket . SomeMethod () ;
}
3.7 Static Members
Static members shall always be called by class name, and never accessed in a
derived class when defined in a base class.
3.7.1 Clean Coding
We have also endeavored to follow the ten Clean Coding principles, as outlined by
one extra pixel’s post. [3] The ten principles are as following:
1. Revise your logic before coding
2. Clearly expose the structure of the page
3. Use the correct indentation
4. Write explanatory comments
5. Avoid abusing comments
6. Avoid extremely large functions
7. Use naming standards of functions and variables
8. Treat changes with caution
9. Avoid indiscriminate mixing of coding languages
10. Summarize your imports
50
3.8 APIs
3.8.1 ASP .NET Web API
One of the agreed upon requirements for the project was that we conform to ASP
.NET Web API. This to make it easier to interact with our framework from other
systems (both existing and future ones). An introduction to using this API can
be found at Asp.net3 or at Microsoft’s webpage4 .
3
4
http://www.asp.net/web-api
http://msdn.microsoft.com/en-us/library/hh833994(v=vs.108).aspx
51
Part II
Requirements and Architecture
52
Chapter 4
Requirements
This chapter presents the requirements specification for the project with functional
requirements, non-functional requirements and user stories. The goal of this chapter is to present the functions and behavior of the product. The contents of this
chapter consists mainly of listed requirements and their categories, seeing as the
customer provided a comprehensive and textual detailed description of requirements, which was well supplemented with additional details in the first customer
meeting.
There was not much need for discussion or evaluation of possible requirements
due to this fact, so as was mentioned earlier: the following is mostly lists and
classifications.
53
Key
F
M
P
A
I
R
Requirement Type
Functional
Modifiability
Performance
Availability
Interoperability
Readability
Table 4.1: Requirements Key
4.1 Functional Requirements
The purpose of functional requirements is to split up and define the functions of
a system.
ID
F1
F2
F3
F4
F5
Requirements
Recieve PDF-files over the Internet by
ASP.NET Web API
Save PDF-files to a location which is easy to
modify later
Recieve data supplied with the ad over the
Internet by ASP.NET Web API
Save the data supplied with the ad into an
existing for real estate ads
Create an order in the internal order system
for a submitted ad
Table 4.2: Functional requirements
54
Priority
H
Complexity
M
H
L
H
M
H
H
H
M
4.2 Non-Functional Requirements
The purpose of non-functional reqiurements is to describe qualities of how the
operations of a system can be judged.
ID
M1
P1
A1
I1
I2
R1
R2
Requirements
Support easy addition of other types of ads
Function with a satisfactory performance.
Provide a high degree of stability, so the customer can meet their availability demands
when our product is integrated into their systems
Be able to communicate with the existing
system Webassistenten
The software must be developed using modern .NET technologies
The code must be easy to read and understand
The code and product must be accompanied
by documentation of functionality
Priority
H
M
M
Complexity
M
M
M
H
M
H
L
H
L
H
L
Table 4.3: Non-functional requirements
55
4.3 User Stories
We created the following user stories from the customer-provided project description, and meetings with the customer.
Actor
Description
Example
C1.Customer
Customer submits a completed ad
Real estate agent sends a completed ad in pdf-format to the system,
with accompanying data. The data is automatically put in the correct
databases/tables
Table 4.4: User Story: C1 Customer
Actor
Description
Example
C2.Customer
Customer reviews and selects product options
A Real estate agent wants to insert an ad in the system.
The system displays available products, and when one is selected,
will list the next five available booking dates for this product,
and its options.
Actor
Description
Example
D1.Developer
Decides to develop a plugin for the system
Starts IDE of choice, and develops a plugin/extension,
using the interfaces and polymorphism provided.
Table 4.6: User Story: D1 Developer
Actor
Description
Example
D2.Developer
Developer wishes to use framework in/with other application
The developer, being already familiar with Microsoft Web API, quickly
integrates the Web API compliant framework with his intended target.
56
Actor
Description
Example
D3.Developer
Wishes to quickly understand system components for extension
Reads attached developer documentation in IDE, or as attached html/xml.
Quickly sees what each individual method does, and can easily
extend the system.
Actor
Description
Example
C3.Customer
Customer tries to submit an ad with insufficient information
The customer tries to add a pdf-file, but doesn’t provide the necessary data;
I.e. didn’t specify a price or place. The system rejects the ad.
The database remains coherent.
57
Chapter 5
Architecture
This chapter describes the software architecture of the product. It defines stakeholders, quality attributes, views, class diagram, patterns and tactics.
58
5.1 Stakeholders
5.1.1 Customer
Our goal with this course was to create a product that not only works the way
the customer intended, but does so with satisfactory performance. It also needed
a clear, logical and functional architecture to make it easy to maintain. Our
code needed to be written following the clean coding standard and make use of
interfaces and general polymorphism, so that their developers could further develop
this solution with ease.
5.1.2 Implementers
We wanted an architecture that would be easy to implement and would make sense
to the coders of our own team as well as to those of the customer.
5.1.3 Course Staff
The course staff wants a clear and well-documented architecture that is easy to
understand and evaluate.
5.2 Quality Attributes
The customer was very specific when it came to what they wanted when it came
to the product. They didn’t specify any quality attributes but we could deduce
the most common ones that we felt needed to be a part of the Quality attributes
of our implementation. The following were deduced: Modifiability, Performance,
Availability, Interoperability and Readability.
5.2.1 Modifiability
While we were the create the solution for real estate ads specifically, the solution
will be used for other ads as well. Therefore we need to make it modifiable so that
other developers later on can further develop using our solution as a base.
5.2.2 Performance
We wanted the system to function with a satisfactory performance, even though the
customer did not set any specific requirements for performance. For this reason,
we decided to merely strive to achieve this goal by writing as efficient code as
59
we could manage, making necessary changes to keep performance at a reasonable
level.
5.2.3 Availability
The system should be available for the users when they need it. Therefore we
needed to minimize the possible points of failure and the probability of these
failing.
5.2.4 Interoperability
Our solution was only a part of the larger Webassistenten solution, and needed
to inter-operate with already-existing order system. To achieve this goal, we used
the same technology as requested by the customer, including Web API, MSSQL
and so on.
5.2.5 Readability
The customer wanted us to write readable code. They requested that we used
polymorphism by creating interfaces so that other developers can easily develop it
further by developing plug-ins for the system. Readability is therefore important
for easier further development of this system.
5.3 Views
Views are a way to display the implementation of a system by showing separate
points of view associated with the various stakeholder concerns. We’ve tried to
follow the 4+1 architectural views model.1
5.3.1 Process View
When we started out by designing the architecture, we didn’t know how the information flow was supposed to be, and therefore didn’t create a process view for
the system. We also did not know how the internal system of Adressa works and
how the processes in their system inter-operate. However we did create a new
architecture to reflect on the changes we made during the project.
1
http://en.wikipedia.org/wiki/4+1_architectural_view_model
60
5.3.2 Logical View
The logical view concerns the functionality the system provides by displaying it
as a high level structure that shows how the components interact with each other.
The logical view is usually a class diagram or sequence diagram. We’ve decided
to use a class diagram because it’s easier to see how the classes interact with each
other and implement. Our logical view is based on the pattern Pipe and filter2
due to the requirement of modifiability.
Figure 5.1: Logical View
5.3.3 Scenario View
This view is also known as a use case view, which basically shows an example of
an imagined and expected use of the system. The main purpose of this view is to
show how the objects (in this case a client or a person) interacts with the processes
and system.
2
http://en.wikipedia.org/wiki/Pipeline_(software)
61
Figure 5.2: Scenario View
5.3.4 Physical View
The physical view shows how the physical components interacts with each other.
Figure 5.3: Physical View
We are to implement the bold arrows
62
5.4 Class diagram
From these views, we made this class diagram as a first draft of how we felt the
system should be. However this later turned out to not fit into how the framework
is supposed to be, and we had to change the architecture.
Figure 5.4: Digital class diagram
5.5 Patterns
Due to the project being a MVC.NET and Web API application we decided to use
MVC pattern because the project might have this pattern built in already. We
also wanted to use Pipe & Filter to filter the data and to satisfy the modifiability
requirement.
5.6 Tactics
Architectural tactics are common strategies used to achieve the quality attributes
required. These tactics should be kept in the back of ones head when developing
63
this product.
5.6.1 Modifiability
• Increase semantic cohesion
• Decrease coupling
• Split modules
5.6.2 Performance
• Write optimal code
5.6.3 Availability
• Our code should not crash the customer’s system, but it’s their responsibility
that the system is available.
5.6.4 Interoperability
• The technology and tools we’re using should be sufficient to ensure interoperability.
5.6.5 Readability
• We will follow the clean coding principle and use camelCase coding and
structure the code logically. The naming of classes and files should also be
clear. Refer to 3.4 Templates and Standards section on page 45.
5.7 Changes to the architecture
When we started to implement the system we quickly found out that the we had
architectural erosion because the architecture we designed in the start didn’t fit
well into the Web API framework. After we got an overview of the system we had
to change the architecture to a MVC pattern.
64
Figure 5.5: Temporary process view
We tried to follow this MVC pattern when we implemented the system, however
we quickly found out that the getView-Controller was not necessary.
65
Figure 5.6: Process View of Final Architecture
6 calls the upload method with files and data
7 is the upload method redirecting either to a FailView or a SuccessView
66
Figure 5.7: Logical View of Final Architecture of MVC
This is the logical view of the MVC architecture.
67
Figure 5.8: Logical View of Final Architecture of Web API
68
Part III
Implementation
69
Chapter 6
Sprint 1
This chapter describes the activites we planned, the time frame, what we have
done and the retrospective of the first sprint.
70
6.1 Time Frame
The time frame for Sprint 1 was week 38 and 39. We started the sprint on September 16th with a weekly supervisor meeting, followed by a sprint plan meeting. We
finished the sprint on September 27th, with the sprint review meeting postponed
to the following Monday.
6.2 Original Plan
Prior to the sprint, we had the following tasks planned for this sprint:
• Project set-up
• Database restoration
• Database connection interface
• Data object creation
6.3 Revised Plan
At the sprint plan meeting, we added more tasks to our Trello board (see section
3.2.11 in the chapter on Technology) beyond those from our original plan. Most
notably, we added the following:
• Database submission logic
We did not revise the plan for the first sprint beyond adding more tasks. Being
quite unfamiliar with the process and technology, we were unaware at the time
that we would not be able to complete all - or even any - of the planned tasks.
6.4 Development
The development started off with the creation of an ASP.NET MVC project. In
this project we created data objects for the ad info described in the assignment.
Towards the end of the sprint, we received a database dump from the customer,
which we spent the entire rest of the sprint attempting to restore. Please refer to
Appendix A on page 102 for more information on this.
71
6.5 Other Work
In addition to the development, we also completed a draft of the outline for this
report and improved on our architectural documentation by adding new and removing unused views.
6.6 Backlog
Of the tasks planned at the beginning of the sprint, the following remained in our
backlog at the end of the sprint:
• Enable display of available products (no GUI is to be implemented)
• Listing the next 5 available booking dates for a selected product
• Listing modules available for a selected product
These tasks were incidentally all of the tasks we had planned for the sprint,
as we were a bit optimistic in our planning. Some of these were included in the
revised plan for sprint 2, while others were postponed to be included in a later
sprint.
This customer meeting which took place on Friday 20 September had 2 customer
representatives; Asle Dragsteen and Hans Kristian Ormberg. Both of them are
involved with this technology at Adressa.
We started the customer meeting by going through our preliminary study phase
and its documents; the architecture and user stories documentation. The customer
was satisfied with the documentation we had created.
The customer proceeded by giving us the database dump and showed us the
database structure and which tables we are supposed to work with.
We also discussed which set of Clean Coding principles we should follow (refer
to 3.7.1 Clean Coding principle on page 50 for more info). The customer requested
that we adhere to "Uncle Bob Clean Code"1 standards.
1
cleancoders.com
72
6.8 Retrospective
While we had initially planned to complete some of the "easy" parts of the implementation during this sprint, this turned out to be a lot harder than expected. We
only managed to get started before we ran into problems related to unfamiliarity
with the technology. We mostly used this sprint to set up various tools needed for
the implementation, and to debug issues we encountered during the setup.
We also spent less time both on development and on the project in general
than we had originally planned, partly due to projects in other courses also taking
up a lot of our time.
What we learned from this sprint was more about how much we would actually
be able to do in a single sprint, and that we were still quite far away from being
able to implement specific parts of the requirements. We started doubting that we
would be able to finish in three sprints, but remained hopeful. We also learned a
lot about the tools we used.
73
Chapter 7
Sprint 2
done and the retrospective of the second sprint.
74
7.1 Time Frame
The time frame for Sprint 2 was week 40 and 41. We started the sprint on September 30th with a weekly supervisor meeting, followed by a sprint plan meeting. We
finished the sprint on October 11th with a customer meeting and sprint review
session.
7.2 Original Plan
From our Work Breakdown Structure, we had the following tasks planned for this
sprint:
• Receiving pdf-file and save in correct folder
• Checking accompanying data for required fields
• Putting accompanying data in the Webassistenten database (table “prospekt”)
• Placing an order in the internal order system
Additionally, the following tasks were carried from the previous sprint:
7.3 Revised Plan
At the sprint plan meeting, we planned the following for this sprint:
• Set up Entity Framework
• Modify start page
• Implement saving of pdf-files
• Prepare report for midterm delivery
75
7.4 Development
At the end of the first sprint, we received a database dump from the customer.
The majority of sprint 2 development was centered around setting up the database
so we could use it in our project. Refer to Appendix A: Database setup on page
102.
We managed to set up an instance of MSSQL server and restore the database
dump we received from the customer. We then connected the project in Visual
Studio 2012 with the database server instance. This connection to the database
via EF created a model of every single table in the database, which then let us
generate controllers for the tables we needed.
Near the end of sprint 2, we realized that we had created the wrong type of
project. We had missed the fact that the solution was supposed to use Web API,
and had created an MVC project. Some time was therefore spent creating a new
Web API project, and porting the code from the previous project into the new
one.
7.5 Other Work
The deadline for the mid term delivery of the report was originally October 14th,
but was at one point in time moved to October 8th. This date coincided with the
middle of sprint 2, so a relatively big part of the sprint was spent preparing the
report for this delivery. When the deadline was moved back to its original date,
more time was spent on improving the report.
7.6 Backlog
Of the tasks planned at the beginning of the sprint, the following remained in our
backlog at the end of the sprint:
• Modify start page
• Implement saving of pdf-files
We were able to complete some of the planned tasks in Sprint 2. The tasks in
Sprint 1 were postponed to later Sprints due to the fact that we weren’t able to
communicate with the database server yet due to our lack of familiarity with the
technology.
76
This customer meeting took place on Friday 11 October 2013. We showed the
customer what we had done since last time - setting up the database and generate
the controllers for the appropriate classes and tables.
There were also a few things we were confused about in the database structure.
This was mainly which table to put the data into and which tables to get the
necessary data from.
Due to the issues we had, the customer was told that picture upload was not
possible due to time constraint. This was not an issue according to the customer
because it wasn’t part of the original plan/assignment. The customer was impressed with how far we had come with the project so far.
At the end of the meeting, we were given notice that he was going on vacation
for 3 weeks. There was still a possibility to contact him via mail and customer
meetings could be arranged via Skype in this period.
7.8 Retrospective
We had a lot of trouble setting up the database and connect it to our project
via EF this Sprint. When we finally did get it set-up and were able to generate
controllers for the classes, we had trouble with naming conventions due to one
of the database tables. When we deleted the System class that was generated
from EF, the problems went away and we could finally launch the project with IIS
Express and view it through a web browser.
This was a good turn for us, because we felt that we finally could have some
visual feedback when we ran the code - other than an error message. It gave us
an overview of the project and how the controllers, views, models and Web API
work together.
The fact that we spent so much of the sprint preparing the report for mid-term
delivery was less than ideal. We lost a lot of development time due to this, as all
of the group members had to focus on the report. Had we not moved all resources
over to this, we might have been able to finish implementation a little earlier than
we did in the end.
77
Chapter 8
Sprint 3
done and the retrospective of the third sprint.
78
8.1 Time Frame
The time frame for Sprint 3 was week 42 and 43. We started the sprint on October
14th with a weekly supervisor meeting, followed by a sprint plan meeting. We
finished the sprint on October 25th with a sprint review meeting.
8.2 Original Plan
From our Work Breakdown Structure, we had the following tasks planned for this
sprint:
• Bugfixing
• Testing
8.3 Revised Plan
This sprint we had originally planned to be fixing and polishing the finished product. Due to the issues we had encountered in previous sprints, many of the originally planned tasks were pushed to Sprint 3. Sprint 3 thus became a "finish
everything that needs to be finished"-Sprint.
8.4 Development
We started development in this sprint by creating the master controller which
communicated with the database through the entity framework. It also took care
of passing models to the view(s) and handle user requests. This master controller
was a MVC-type controller which is mostly used as a prototype and for us to test
that the data we submit actually reached the system.
8.5 Other Work
After creating and finishing the master controller, the final architecture was made
to reflect the implementation of the system. We had architectural erosion due to
the framework working differently from what we expected.
The first Friday of this sprint we attended a technical writing course organized by the course staff, where we received pointers on writing our report. These
included both general tips as well as concrete improvements for our report specifically.
79
We started to create the documentation for the customer in Doxygen by XML
commenting our code (this was done by adding three slashes "///" in front of all
the methods). Doxygen read the implemented code and created the documentation
document in HTML.
8.6 Backlog
Originally we planned to finish the product in Sprint 3. However, we had a lot of
issues/problems in both Sprint 1 and 2 so we couldn’t start implementing most of
the code before Sprint 3.
When the problems were sorted out, we actually got down to implementing and
communicate with the database. We created a MVC controller of the assignment
so we were able to test database connection, through insert/select and various
other SQL commands via the EF. This MVC controller let us check how the
implementation works and gave us a better overview of the framework we were
using. However the assignment was to create a Web API controller, so we had to
convert it.
We decided to not have a customer meeting for sprint 3 due to our customer
representative, Asle, not being physically available. Asle was on a 3 week vacation
this period, and we didn’t feel it was necessary to go to the trouble of setting up
a video conference.
However, we felt that we were in control of the implementation or knew how
to fix the issues we had stumbled upon. We didn’t have much new to show either,
because we were in the middle of implementing the MVC controller.
8.8 Retrospective
Sprint 3 was a good Sprint for us, we felt that we finally were able to understand
the framework and that we actually were progressing forward. We were able to
communicate with the database, modify rows inside tables, insert data into tables
etc.
We also figured out how to serve Razor’s view files (.cshtml) as web pages
through IIS Express by launching the project via VS, and how these views were
connected to the controllers. This was enough for us to be able to invoke methods
in our controllers, which was heavily used for testing that our written code worked
as expected.
80
Chapter 9
Sprint 4
done and the retrospective of the fourth sprint.
81
9.1 Time Frame
When we didn’t finish implementation by the end of Sprint 3, we had to add
another sprint.
The time frame for Sprint 4 was week 44 and 45. We started the sprint on
October 28th with a weekly supervisor meeting. On November 6th we had a
Skype meeting with the customer. We finished the sprint on November 8th. After
the sprint, on November 13th, we held an acceptance meeting with the customer.
9.2 Original Plan
Because we had planned to finish within three sprints, there were originally no
plans for Sprint 4. However we quickly realized that we were going to need a
Sprint 4 due to having an incomplete product at the end of Sprint 3.
9.3 Revised Plan
The fact that we knew this would be the last sprint we had time for let us skip
the sprint planning meeting because we knew that everything that was to be
implemented that had not yet been, had to be done during this sprint.
9.4 Development
In this sprint, we converted the existing MVC controller of our implementation to
a Web API controller, and generated documentation with Doxygen.
9.5 Other Work
We made the final outline of the report, and discussed which sections (including
chapters and subsections) that we needed to include or rework before the final
delivery.
The technical documentation needed to be completed along with the product,
so we had to go through each method and write XML Documentation Comments
on each of them.
The architectural documentation that was created in the beginning did not
reflect the changes we had made to the product due to architectural erosion, and
needed to be updated to better the reflect the actual system implemented.
82
9.6 Backlog
In the sprint, we finished the implementation and had the acceptance meeting with
the customer. Therefore, the most important thing to focus on after Sprint 4 is
the report.
We had a customer meeting with the Asle on November 6th where we showed him
the MVC controller we made, how it interacted with the database and how data
was sent from one view to another. Due to the fact that Asle was still on vacation
we had to do the customer meeting through Skype (video conferencing software).
9.8 Retrospective
We weren’t happy that we had to do a Sprint 4, because we had hoped that we
would be finished with the implementation after Sprint 3. The conversion of the
MVC controller to the API controller yielded problems we didn’t expect, and it
should have gone more smoothly. Unfortunately we had to rewrite a lot of the
code due to big differences between the controllers.
83
Chapter 10
Web Application Implementations
This section will contain information and reasoning about our use of two of Microsofts web application technologies: ASP.NET MVC, and ASP.NET Web API.
Our use of these technologies stems from requirements by the customer, who
already uses Microsoft technology, and required that this project also made use
of MS technology in order to fit into their systems. In particular this was to ease
interaction with Entity Framework, which was another requirement for technology
to be used in database communication.
84
10.1 Microsoft ASP.NET MVC
ASP.NET MVC was used for easy, fast testing, and enabled easy visualization
data flow, and event sequences during the testing process. We also used it to
ease into the technology we needed to use, seeing as it was more familiar to us.
One group member already had previous experience with ASP.NET MVC, which
enabled us to easily set up the project and get started without any trial-and-error
in the setup. This enabled more focus on database setup and interaction, as well
as the business logic of the project.
There are three other reasons other than internal and product specific reasons that made an ASP.NET MVC test product worth the time spent on it. The
first reason being to more efficiently communicate functions and progress to the
customer, who also obviously benefited from our ability to visualizefunctions and
sequences as we progressed. We believe that this helped a great deal in ensuring
efficient and fast communication, and to prevent misunderstandings. The second
reason was that it doubles as an effective demonstration tool at the end presentation of the project, where we would have had to create some form of visual
presentation aid for the product anyhow, in order to demonstrate the product as
actually functioning. The third and final of these reasons was that it might give
added value to the customer in the form of a visual guide and overview for future
API users of the overall structure of the product. At least the customer agreed
with us when we presented this idea. They can potentially use it as a guide on how
to use the Web API functions in a full product, at least in the minimally required
sense.
10.2 Microsoft ASP.NET Web API
ASP.NET Web API was the main outward technology interface of our product, as
specified by the customers initial specifications. None of the team had any previous
experience with this technology, so we postponed the implementation until late in
the development cycle, when everything else was implemented. In doing so we
hoped to remove any other points of failure during this implementation.
Web API turned out to be a bit lacking in modularity, so it limited our ability
to implement the non-functional requirement of modifiability. There were few
meaningful ways to implement polymorphism and interfaces in the code; most
possibilities were redundant or trivial when knowledge of Web APIs design and
purpose is taken into account. That is to say that any meaningful modifications
will have to be done to Web API itself, and not to the product. The product
does fullfill criteria for modifiability as such, when the use of Web API is taken
into account; however that was not a consequence of any design or effort on our
85
part, merely a by-product of following the functional requirement of Web API
implementation and use.
Our implementation mostly follows the specifications for Web API, except for
one method which does not follow best practice due to issues with Web APIs
automatic argument parsing and model binding. As a result, that method implementation and the function it fulfills is slightly fragile, and harder to maintain. It
was however neccessary in order to achieve the desired function at all, and still
keep the much more important attribute of outward simplicity and ease of testing.
Any other solution would most likely have sacrificed the atomicity of the function,
which would have complicated testing a great deal, and introduced new sources
for bugs. Further discussion on that can be found in the issues section 2.6.5 on
page 22.
86
Chapter 11
Testing
This chapter will describe the methods used for testing the requirements, the
reasoning behind their choice, the testing methodology, and the results of the
testing.
87
11.1 Testplan
Due to the nature of the technology we used in the product, we judged TDD or
Unit Testing to be unsuitable for our project. The reasoning behind this is that
our unfamiliarity with WebAPI, as well as the products limited modularity (see
10.2 on page 85), meant that it would be hard to write good Unit Tests that tested
functionality and errors sufficiently. Instead we focused on writing clean, readable
code, with subsequent high level testing of entire modules at once.
The test plan consisted of testing module functionality, and when modules functioned according to specifications, testing the system as a whole with all currently
implemented modules.
11.2 Testing Methodology
As discussed in the previous section, TDD and Unit Testing was deemed unsuitable
for our project, and as a result we settled on a practical testing of each module
followed by integration testing of modules once they completed individual tests. All
of the tests of modules and higher levels were done by the person that completed it
in cooperation with another team member, for independent oversight and checking.
Tests were done manually, following the specifications for each module or the
overall system specification, as appropriate.
The main testing sequence consisted of first testing of method logic in the
IDE itself for each method once completed, by examining the state and output
during runtime. The next part consisted of testing a each module as they were
completed, and the final part was the overall system test for each phase of the
product implementation.
11.3 Testing
The testing consisted of two main phases, with two sub-phases to each main phase.
The first phase consisted of testing the data objects, method logic, EF connection,
EF saving and by extension database saving. The second phase consisted of testing
the WebAPI implementation, its function, errors, and the modified auto-generated
API-documentation. It also finished with the complete system level test, where
the system was tested in its entirety.
11.3.1 Functionality and MVC
The functionality tests consisted of state examination during runtime, with breakpoints in the execution, set by Visual Studio, supported by console printouts during
88
debug runs of the code. Once all the logic for a module fulfilled its required functionality the module was tested with simple MVC views for browsers, which were
made for testing and minimal examples of API use.
Once all the modules completed testing, the system level test for the MVCphase was run, where our MVC testing-views reperesented a minimal working
product for the project specifications.
11.3.2 WebAPI and Finalization
In the testing of our Micrsoft Web API implementation for the project, we were
limited to testing of functionality for each individual API method, and some simulated testing of possible use by Adresseavisens end users for the product (software
developers working for real estate agents). The handling of data by the API users
was not something we could simulate, so in testing we merely gave the inputs the
methods require, since it is up to the users of an API to give the correct input, and
handle data replies correctly, in accordance with the API documentation. With
that in mind we tested each method individually, inputting the data for the methods directly into the web requests or by crafting requests by script in the Developer
Tools in Google Chrome, and examining the replies. We simulated the proper sequence of data requests and submission by testing methods in proper order, and
submitting the appropriate data from the last method reply to the next request.
11.4 Test Results
In this section we will discuss the results of the completed tests, successes, failures,
their implications, and how we handled the results.
11.4.1 Functionality- and MVC-Results
Functionality tests started in Sprint 2, where they were mostly completed. They
were wholly completed in the start of Sprint 3, where all of the required functionality and modules were tested. All modules worked according to specification, and
we started testing all modules together in an ASP.NET MVC project in the middle of Sprint 3. The tests completed satisfactorily by the end of Sprint 3, and the
project was deemed suitable for implementation in Microsoft Web API as was required by specification. The MVC-testing gave a good overview of the interaction
between the various modules, something which was very useful in the implementation of Web API for the project, because as an API it wouldn’t allow for the
same level of comprehensive sequence testing for the entire ad order process.
89
11.4.2 WebAPI-Results and Finalization
Web API testing was conducted during Sprint 4, and finished during the same.
The first Web API test results were merely a confirmation of the functionality
tests from the previous phase, since the method functionality was the same, just
used in a slightly different context. Unsuprisingly the results were satisfactory, and
consistent with the previous results. After that came the Web API implementation
testing, where quite a few tests failed. For reasons undetermined (though not
for lack of trying), the refence implementation of Web API methods failed to
function as advertised. Interplay between Entity Framework, Web API and JSON
was suspected, but not confirmed. After that there was an extended period of
iteraterative workarounds and tests, until required functionality was achieved.
11.4.3 Implications of Test Results
The failure of our reference implementation of Web API methods forced us to use
a non-standard, and less transparent implementation to achieve the desired functionality, something which placed greater importance on both our integrated and
detached API documentation. This added some extra work with the documentation outside of what we expected, in addition to the not unsignificant amount of
work that had to be devoted to testing of potiential fixes and workarounds.
90
Part IV
Evaluation and Conclusion
91
Chapter 12
Evaluation
In this chapter we will evaluate the whole project and our process during the
project to see how what we felt was done correctly and what could have been done
better. This chapter will also take a look at our group dynamic and analyze how
we handled issues and risks.
92
12.1 The Process
12.2 Quality Assurance
12.2.1 External Communication
This sub chapter is mainly about communication with people outside of our group.
12.2.1.1 Communication with the Customer
The customer was always available via e-mail and whenever we needed him urgently we could call him via mobile phone, which was available via the assignment
text in the compendium.
The customer answered rapidly (usually with minutes), but there was one occurrence during his vacation when we didn’t receive a response to our e-mails for
a couple of days. We thought that he didn’t have an internet connection available,
however it soon turned out to be our mail having ended up in his spam folder.
Asle, the customer’s main representative, is a computer scientist himself, which
was beneficial for us because he could give precise answers to our questions, rather
than the more vague answers one often gets from less technologically inclined
customers. He was also a student at NTNU a few years back, which turned out
to be quite beneficial for us because he was familiar with the university and its
processes. This saved us time and trouble e.g. when letting him know where
meetings would take place.
In the customer meeting in Sprint 1 we got an demonstration of the database
structure. The other customer representative, Hans Ormberg, suggested that picture upload to the database was also a good idea to implement which Asle agreed
with. We on the other hand kept this in the backlog and would implement it if
we had the time to do so. When it turned out that we didn’t, we let Asle know
that we had to drop the picture upload implementation due to time constraints.
He understood the situation, and let us know it was not a problem, because this
was not a requirement in the original assignment.
12.2.1.2 Supervisor
Our supervisor, Meng Zhu, was in the beginning not very responsive via mail. It
would typically take a couple of days before we received a response from him. We
mentioned it to him in a supervisor meeting that we wanted a mail response within
24 hours of him receiving the mail. He let us know he would fix this issue, and
after that, all the mails that needed a response was responded to in less than 24
hours after we sent the mail. Most of our communication with Meng was through
93
the supervisor meetings where he went through our weekly report and minutes
from the previous meeting. He also asked us if there were any unresolved issues
we need help with to fix.
Meng was also concerned with how our report would turn out, and asked us
if we could make a draft layout of the final report so he could double check that
we had included all the chapters and sections we needed for a well written and
complete report. If we needed resources to fulfill a chapter in our report Meng
gladly offered to lend us one of his system development books.
When we had the first meeting with our supervisor we received a template that
we should use for the weekly reports. This template saved us time whenever we
created a weekly report for the supervisor meeting, and it made it easier for to be
more efficient on the meeting so we could focus on the assignment, although we
sometimes forgot to remove parts from the template that weren’t applicable for
that particular weekly report.
12.2.2 Internal communication
We had no set rules in our group, and instead followed common group sense, e.g.
notifying the other group members if we were late. We didn’t have issues with
people being 2 hours late, because we knew that they might have other subjects
that might need to be prioritized at that time. Deliveries in other subjects might
lead to sleepless nights, making meeting the group for working on the project at
8:00 in the morning not feasible. We did however call or contact the person if he
didn’t appear after a while when we had agreed to meet, in case he had simply
overslept, or to make sure he would be in time for a meeting with the customer
or our supervisor. We didn’t punish any late arrivals due to all of us being late in
turn, and experience no problems with this. There were no issues in our internal
group, and usually agreed on everything.
12.3 Implementation
Our implementation followed the clean code principle and template written on 3.4
Templates and Standards on page 45. This ensured that the code followed the
standard and was readable for other developers. All the methods we implemented
had XML Style Comments for documentation purposes.
We would hope the implementation of our code had went more smoothly than
"error message per third line of written code", but when we finally got somewhat
of a grasp of C# and Web API, things started to go a little more smoothly.
Due to our version control system with Git and GitHub we could easily experiment with the code without ruining the project, because Git let us revert the
94
changes made. Even if we wrote on the same file we had no large Git conflicts that
needed a lot of rework to fix the merge. It was usually just removing the "< < <
< <HEAD" section that Git added.
12.3.1 Testing
We had no specific test plan. The implementation of our code needed a pdf
accompanied by a lot of data. These data had to be checked against the database
and we had to make sure that all the data was in the correct format both to the
database and the input data. We had to make sure to give an appropriate error
message otherwise. The testing was done while developing, and we usually got a
lot of error messages, but when the code ran we could easily check if the result
was as expected or not by sending data to the IIS Express server via a web form
we created locally for testing.
12.4 Group dynamics
Our group had issues with people being late, but because we all were late now and
then it was not a problem that irritated any of us. The group was also fortunate
that all the group members are from the same class (Computer Science fourth
year), so everyone knew each other before we started working. The whole group
had also been together on a class trip to Japan before this project, where we got
to know each other better outside of school. This helped immensely on the group
dynamic. We therefore felt that the group dynamic course didn’t give us as much
as we had hoped for. The group dynamic course did however give us insight of our
group and helped us defining roles and responsibility amongst us.
12.5 Risk management
All group projects have risks, this is inevitable. Check 2.7 Internal Risks on page
25 and 2.8 External Risks on page 28. The most important risks are mentioned
below.
• The highest risk was our unfamiliarity with the technology
We faced this problem by using Googling the problem at hand if possible
and if this didn’t work out we asked our customer Asle if he knew how to fix
the problem.
• Development and Implementation
Development didn’t go as we had hoped. There were a lot of bugs and
95
hiccups when we implemented the code due to familiarity of the system.
However tons of debugging helped us get a better grasp of the whole project
and system.
• Other subjects
Due to all of us being a forth grader, we have a lot of other subjects which
tends to have big deliveries and/or projects which counts toward the final
score in that course. Therefore other subjects had to be prioritized now and
then. We mostly had to accept this and try to compensate for the lost time.
• Illness
There’s not much one can do with illness, the risk of being ill is especially
high in the fall semester due to the weather change from summer to winter.
The best thing to do as an ill person is to stay at home and fully recover as
fast as possible.
These risks that were the most risky ones was not a big factor for the end product.
We had a buffer in Sprint 3 and Sprint 4 was added as another buffer in case we
needed it.
96
Chapter 13
Conclusion and Future Work
In this chapter we make conclusions based on what we have learned and experienced in this project during this semester. We will also list future work which
we did not manage to finish and which could be a basis for further work on this
project.
97
13.1 Conclusion
The project we were given did not contain any questions regarding thing to evaluate, so there are nothing to conclude in that respect. However, as a group we have
come to several conclusions regarding the technology we used, and the project as
a whole.
While Web API has really practical automated functionality, when it works, it
is a disadvantage that it requires tweaks and setup to work according to specific
needs. It is also severly lacking in comprehensive and collected documentation
and tutorials, and most of the available learning materials come in the form of
videos and blog posts. This makes it a much harder technology to come to grips
with than it initially seems. The use of Web API in the system might still be the
most appropriate due to ease of integration into Adresseavisens systems. However:
the group feels the need to make a note that other technologies might be more
apppropriate, and easier to implement for the same type of service, if they provide
better documentation. This especially applies in cases where the developers are
not familiar with Web API, but might very well be more familiar with technological
concepts used by other more widely used, or more general alternatives.
In terms of the project overall, we have come to some conclusions as well. The
objective of modifiability and extensibility was not as easily achievable in some
main parts of the project as initially thought, and as a consequence it was left
more to aspects inherent in the technology (more on that in the Future Work
section). The reason behind this is that the nature of such an application is
rather intimately connected with its data types, class implementations, and the
data communication interface (i.e. the database connection, which in our case was
Entity Framework).
All in all, we conclude that the project has been moderately successful, with a
potential for improvement in several aspects: The technology study, learning, and
acclimatization parts probably should have been more emphasized, and included
as a larger part of the project. The modifiability and extensibility part is possibly
a whole project in itself to properly implement according to proper coding standards and practies. As a consequence, the part of the product that concerns that
requirement could use some improvement. And finally, following the last point,
the work required for modifiability and general implementations in Web API is
more of a project in extending and covering up missing features in Web API than
it is a subproject of the ad import system.
98
13.2 Future Work
In terms of future work, we as a group have several items we could suggest for a
future improvement of the product, after we have completed our part with this
report.
We did not have the time to implement accepting and adding pictures in
the database. This will require a module with some integration into our current
project, but should not be hard to accomplish.
Secondly we have mostly relied on the integrated extensibility in Web API
to provide the desired modularity and extensibility in the product. Any future
additions of modules could be added via modification of WebAPI settings, and
using our completed work as templates, but there is room for improvement in this
regard. It’s possible to generalize our API more, for support of other ad types,
though it would require significant work or much more experience with Web API
than our group have had. The required work would possibly involve generalized
Controller templates who can handle various types of input and operations, and
in that regard are extensible to usable Controllers for ads. This would also probably require generalized model binders and data formatters, which require more
understanding of Web API than we have been able to get; it should nonetheless
be achievable as a project in its own sense.
The project could also have benefited from a more purpose-built database,
and by extension: a more straigthforward way to communicate with data storage.
However, this would perhaps not be feasible to follow through on, due to the
current database serving other functions and possibly serving other systems as
well.
99
Bibliography
[1] Yusuf Arslan. Is agile and scrum really better than waterfall? http://
yusufarslan.net/agile-and-scrum-really-better-waterfall. Read on
26 August, 2013.
[2] BinaryHash.
Agile methods.
http://binaryhash.com/assets/agile_
process-d6666e8f6b47340f7117a3d149bce69c.png. Image found on 18
November, 2013. Slightly modified by us.
[3] Pamela Rodríguez Domínguez.
10 principles for keeping your programming code clean.
http://www.onextrapixel.com/2011/01/20/
10-principles-for-keeping-your-programming-code-clean/. Read on 2
September, 2013.
[4] Microsoft. C# coding conventions (c# programming guide). http://msdn.
microsoft.com/en-us/library/vstudio/ff926074.aspx. Read on 26 August, 2013.
[5] WikiMedia.
Scrum board.
http://en.wikipedia.org/wiki/Scrum_
(software_development). Image found on 18 November, 2013.
[6] WikiMedia. Waterfall model. http://en.wikipedia.org/wiki/Waterfall_
model. Image found on 18 November, 2013.
[7] Wikipedia. Adresseavisen. http://en.wikipedia.org/wiki/Adresseavisen.
Accessed 7 October, 2013.
100
Part V
Appendices
101
Appendix A
Database setup
The database dump we got from the customer was a 10.8GiB .bak file which contained the existing internal database of the adressa system - a MSSQL database.
We thus had to install MSSQL locally on our own computers to be able to restore this backup file before we could integrate the database into our project via
the entity framework. To manage and restore the database, we had to use SQL
Management Studio.1
This package let us install the 2012 version of the management studio, or choose
to update from an existing 2008 version of MSSQL Management Studio which it
claimed was already installed. However, this package did only the install the SQL
management studio but no SQL server instance was installed.
It was therefore impossible to connect to a MSSQL server instance because
none existed, which made it impossible to restore the .bak file (database backup
dump), because there were no SQL server instances to restore to. We then tried
to install "SQL server with tools express" which did in fact install a SQL server
instance and we were allowed to connect to a it via the management studio, and
we were able to click "restore database". We then navigated to the appropriate
folder and chose the .bak file to restore. When we clicked "OK", it started to
restore the database, but after a few minutes we got an error message saying that
the database was too big to be restored, this was due to the express version can
only restore a database up to 10.2GiB while the .bak file we got was 10.8GiB. Thus
we had to install the non-express version to be able to restore the database. The
last tool we tried to install was "Microsoft SQL Server 2012 Developer 32/64-bit",
this installation had a server instance which we could restore the database to.2 To
integrate the database into our development tools (Visual studio using web api)
we had to use the entity framework by adding an ADO.NET Entity data model3 of
1
http://www.microsoft.com/en-us/download/details.aspx?id=8961
http://www.katieandemil.com/sql-server-2012-restore-database-backup-file
3
http://www.entityframeworktutorial.net/
2
102
the database. This let us treat database tables as objects, and it converts objects
manipulation to SQL query syntax for the particular database.
103
Appendix B
Templates
B.1 Supervisor meeting
All the notes from the supervisor meeting was named following the template:
MM_DD_Supervisor_meeting
The document itself usually contained the members who attended the meeting (if
there was anyone missing). The document itself was made in plain text.
104
B.2 Customer meeting
All the notes from the customer meeting was named following the template:
MM_DD_Customer_meeting
The document itself usually contained the members who attended the meeting (if
there was anyone missing). The document itself was made in plain text and was
usually written in Norwegian, but was usually translated to English when needed.
105
B.3 Weekly report
<frontpage>
Weekly status report, week 36.
Project
Project name:
Customer:
Customer Driven Project - Group 15
Adresseavisen.
Participants
Audun Skjervold
Truls Hamborg
Hong-Dang Lam
1.0 Summary
In this week ...
2.0 Work done this period
In the previous week we have ...
2.1 Status of documents
2.2 Meetings
These are the meetings we have planned (disregarding internal meetings):
• date1
• date2
Week
37
Activity
<Activity>
<Activity>
..
.
Total
Estimated
<Number>
<Number>
..
.
Actual
<Number>
<Number>
..
.
<total>
<total>
3.0 Problems and issues
In the previous week we have had some problems with ...
4.0 Planning for the following period
In the following week we have plans to ...
4.1 Meetings
106
5.0 Meeting agenda
• Time: 12:00-13:00 (or 12pm to 13pm).
• Place:
• Attendees: Group 15 - <Names here>
Advisor: Meng Zhu
• Agenda:
– Approval of agenda
– Approval of minutes from previous advisor meeting
– Comments to the minutes from last customer meeting (or other meetings)
– Approval of the status report
∗
∗
∗
∗
∗
Summary
Work done this period
Problems
Planning of work for the next period
Other
– Review/approval of attached phase documents
– <add other agenda items here>
107
Appendix C
Dictionary
.
Adressa
Adresseavisen AS (customer)
API
Application Programming Interface
IDE
Integrated Development Environment
NTNU
Norwegian University of Scienceand Technology (Norges
Teknisk-Naturvitenskapelige Universitet)
IDI
Department of Computer and Information Science (Institutt for Data og Informatikk)
IME
Faculty of Information Technology, Mathematics and
Electrical Engineering (Fakultet for Informasjonsteknologi, matematikk og elektronikk)
SQL
Structured Query Language
DB
Database
MS
Microsoft
EF
Entity Framework
MSSQL
Microsoft SQL
108
PDF
Portable Document Format
HTML
Hyper Text Markup Language
JS
JavaScript
JSON
JavaScript Object Notation
C# or CS
C-sharp
ASP
Active Server Pages
WBS
Work Breakdown Structure
MVC
Model View Controller
VS
Visual Studio
IIS
Internet Information Services
OS
Operating System
USB
Universal Serial Bus
HDD
Hard Disk Drive
SSD
Solid-state drive
FAT
File Allocation Table
GiB
GibiByte - 1024 MiB
MiB
MibiByte - 1024 KiB
KiB
KibiByte - 1024 Bytes
IT
Information Technology
TDD
Test-driven development
109
SMS
Short Message Service
ID
Identification
110
Appendix D
Test view
This section contains pictures and responses of the product.
111
D.1 ModuleAPI response
This is the response of the ModuleAPI controller when we run a GET-request to
it with a partnerId of 2.
{"$id":"1","modulId":[101,101,102,102,103,103,104,104,105,105,281,317,318,319,
320,321,322,357,448,449,461,462,463,526,526,527,527,528,528,529,529,530,530,531
,532,533,534,800,800,801,801,802,802,803,803,804,804,805,805,806,806,807,808,809
,810,836,861,861,862,863,863,864,865,865,866,867,867,868,869,869,870,870,974,975]
,"modulNavn":["1/5 side","1/5 side","2/5 side","2/5 side","3/5 side","3/5
side","1/1 s (7 bilder)","1/1 s (7 bilder)","1/1 s (4 bilder)","1/1 s (4
bilder)","1/10 side","1/10 side","1/5 side","2/5 side","3/5 side","1/1 s (7
bilder)","1/1 s (4 bilder)","1/20 side","2/5 side","1/10 side","1/10 Tobb","2/5
Tobb","1/1 Tobb","1/16 side","1/16 side","1/8 side","1/8 side","1/4 side","1/4
side","1/2 side","1/2 side","1/1 side","1/1 side","1/16 Tobb","1/8 Tobb","1/4
Tobb","1/2 Tobb","1/12-side","1/12-side","1/6-side","1/6-side","2/6-side
2b","2/6-side 2b","2/6-side 3b","2/6-side
3b","1/2-side","1/2-side","1/1-side 3b","1/1-side 3b","1/1-side
5b","1/1-side 5b","1/12-side Tobb","1/6-side Tobb","2/6-side 2b
Tobb","1/2-side Tobb","2/6-side 3b Tobb","1/12 s","1/12 s","1/12 s
Tobb","1/6 s","1/6 s","1/6 s Tobb","2/6 s","2/6 s","2/6 s Tobb","1/2
s","1/2 s","1/2 s Tobb","1/1 s 5b","1/1 s 5b","1/1 s 4b","1/1 s
4b","1/2 s 3b","1/2 s Tobb
3b"],"dimensjoner":["248x66","248x66","248x135","248x135","248x204","
248x204","248x342","248x342","248x342","248x342","122x66","122x66","2
48x66","248x135","248x204","248x342","248x342","60x66","248x135","122
x66","122x66","248x135","248x342","122x41","122x41","122x85","122x85"
,"122x173","122x173","248x173","248x173","248x349","248x349","122x41"
,"122x85","122x173","248x173","122x55","122x55","248x55","248x55","24
8x113","248x113","248x113","248x113","248x171","248x171","248x345","2
48x345","248x345","248x345","122x55","248x55","248x113","248x171","24
8x113","122x55","122x55","122x55","248x55","248x55","248x55","248x113
","248x113","248x113","248x171","248x171","248x171","248x345","248x34
5","248x345","248x345","248x171","248x171"],"datoTilgjengelig":["23.1
1.2013","30.11.2013","7.12.2013","24.12.2013"]}
112
D.2 API help page
This page is auto generated by the framework.
Figure D.1: The Web API help page
113
D.3 Upload successful
The response from Web API when we get a successful upload and with correct
data which is verified by the code.
Figure D.2: The response from Web API, success
Figure D.3: The local html file we used to test against the server
This is the html file we used for passing data and pdf to the Web API, we expect
the customer to create something similar when they create an interface for the real
estate agents.

Department of Computer and Information Science TDT4290

Transcription

Similar documents

United Wireless DAL.indd

United Wireless DAL.indd

www.patha.org

retail customers - Digitalni Marketing

2015 - 06 - OTS Employees Federal Credit Union

system - Acclaim Federal Credit Union

Roam through Japan for $5 per month.

Spring 2015 - AmeriCU Credit Union