T-404-LOKA, Final Project · developed using Scrum methodology and Balsamiq Mockups. 3 T-404-LOKA,...

T-404-LOKA, Final Project

Evert

Hildur AndrjesdóttirHulda LárusdóttirÓlafur Ómarsson

2014BSc Computer Science

Instructor: Elín Elísabet TorfadóttirExaminer: Hlynur Sigurþórsson

i

Index

INDEX ................................................................................................................................................. I

INTRODUCTION ................................................................................................................................. 1

Project Description ................................................................................................................................................. 1

Development tools and technology:.......................................................................................................................... 1

Workflow ............................................................................................................................................................... 3

Methodology and workload ...................................................................................................................................... 3

Delivery Schedule ...................................................................................................................................................... 3

Division of Duties ................................................................................................................................................... 5

Task........................................................................................................................................................................ 5

Description ............................................................................................................................................................ 5

Responsible Partee ................................................................................................................................................ 5

Risk analysis ........................................................................................................................................................... 7

Risk ........................................................................................................................................................................ 7

How Likely ............................................................................................................................................................. 7

Effect ..................................................................................................................................................................... 7

Prevention ............................................................................................................................................................. 7

Reduce Damage ..................................................................................................................................................... 7

Responsible ........................................................................................................................................................... 7

Date Resolved ........................................................................................................................................................ 7

Risk Factor ............................................................................................................................................................. 7

DESIGN .............................................................................................................................................. 8

Message Types ........................................................................................................................................................... 8

User Groups ............................................................................................................................................................... 9

User group ............................................................................................................................................................. 9

Background ............................................................................................................................................................ 9

System use ............................................................................................................................................................. 9

Environment .......................................................................................................................................................... 9

Goal ....................................................................................................................................................................... 9

Class Diagram........................................................................................................................................................... 10

System Diagram ....................................................................................................................................................... 11

Workflow ............................................................................................................................................................. 12

Navigation Chart ...................................................................................................................................................... 12

Scenarios .................................................................................................................................................................. 12

Scenario 1 ............................................................................................................................................................ 13

Scenario 2 ............................................................................................................................................................ 14

Scenario3 ............................................................................................................................................................. 15

Scenario4 ............................................................................................................................................................. 16

Layout and logo .................................................................................................................................................... 17

PROGRESS REPORT .......................................................................................................................... 18

Introduction and backlog ..................................................................................................................................... 18

Sprint backlog: ......................................................................................................................................................... 18

Removed Items ........................................................................................................................................................ 22

Progress ............................................................................................................................................................... 23

Burn-down’s ............................................................................................................................................................ 23

Release 1 ............................................................................................................................................................. 24

Release 2 ............................................................................................................................................................. 24

Comments ................................................................................................................................................................ 25

CONCLUSION ................................................................................................................................... 26

The Good.............................................................................................................................................................. 26

The Bad ................................................................................................................................................................ 26

And the Ugly ........................................................................................................................................................ 26

APPENDIX I ......................................................................................................................................... I

Test Report ............................................................................................................................................................. I

Introduction ................................................................................................................................................................ I

Summary ..................................................................................................................................................................... I

Overall Progress of the Testing Cycle ..................................................................................................................... I

On time ................................................................................................................................................................... I

Detailed status ........................................................................................................................................................... II

TFS ID ....................................................................................................................... Error! Bookmark not defined.

PBI Title .................................................................................................................... Error! Bookmark not defined.

Test Case Title.......................................................................................................... Error! Bookmark not defined.

Status (Pass/Fail) ..................................................................................................... Error! Bookmark not defined.

Issues ........................................................................................................................................................................ VI

Defect ID ............................................................................................................................................................... VI

Defect Description ................................................................................................................................................ VI

Steps to Reproduce .............................................................................................................................................. VI

Severity ................................................................................................................................................................. VI

State ..................................................................................................................................................................... VI

Remaining Risks ........................................................................................................................................................ VI

Nr. ......................................................................................................................................................................... VI

Risk ....................................................................................................................................................................... VI

Description ........................................................................................................................................................... VI

Severity ................................................................................................................................................................. VI

Test Conclusion ......................................................................................................................................................... VI

APPENDIX II ...................................................................................................................................... VI

Progress Report ..................................................................................................................................................... VI

Release 1 ................................................................................................................................................................... VI

Sprint 1 ................................................................................................................................................................ VII

Good - Keep up: ................................................................................................................................................... VII

Could be better: .................................................................................................................................................. VII

Sprint 2 ............................................................................................................................................................... VIII

Good - Keep up: .................................................................................................................................................. VIII

Could be better: ................................................................................................................................................. VIII

Release Conclusion ............................................................................................................................................... IX

Release 2 .................................................................................................................................................................... X

Release 2 burn-down: ................................................................................................................................................ X

Sprint 3 .................................................................................................................................................................. X

Good - Keep up: ..................................................................................................................................................... X

Could be better: .................................................................................................................................................... X

Sprint 4 ................................................................................................................................................................. XI

Good - Keep up: ................................................................................................................................................... XII

Could be better: .................................................................................................................................................. XII

Sprint 5 ............................................................................................................................................................... XIII

Good - Keep up: .................................................................................................................................................. XIII

Could be better: ................................................................................................................................................. XIII

Sprint 6 ............................................................................................................................................................... XIV

Good - Keep up: .................................................................................................................................................. XIV

Could be better: ................................................................................................................................................. XIV

Stabilization and documentation ........................................................................................................................ XV

Good - Keep up: ................................................................................................................................................... XV

Could be better: .................................................................................................................................................. XV

Summary ................................................................................................................................................................. XVI

1 T-404-LOKA, Lokaverkefni, 2014-3

Introduction

Project Description

Evert is an open sourced project of process definitions made for Reykjavík. The team met with Daníel,

company contact and Product owner, weekly over the course of the project to discuss progress and

other subjects that might have risen in the working period. The team had access to an office area in the

Reykjavík University building.

The problem that the team faced was that many processes were hard-coded in the school system. Thus

the program was designed to allow users to define graphically what should happen when the system

receives events from an external system. This makes the system more accessible e.g. for the office staff

since it won’t need to program each process from scratch. There is also a more advanced option for

those who want to be able to control the events more thoroughly through bits of code.

The solution was to create the system, Evert that has access to a RabbitMQ message queue which

includes events from the schools inner systems. Evert has access to various API’s and is able to react to

various events in different ways. Evert includes an easy to use interface letting a specific user define

processes. It contains a “proof of concept” implementation of more than two events and what happens

when they occur. As mentioned above, Evert also includes an interface that is less constrictive for

advanced users. There a user with programming knowledge could write JavaScript snippet that will be

run when the events are processed.

Development tools and technology:

Front end: HTML5, CSS3, JavaScript, AngularJS.

Back end: JavaScript, Node.js.

Web application framework: Express.js.

Database: MongoDB.

Evert is a Single-Page app, event driven program that listens to events on the RabbitMQ message queue.

It is based on the MEANJS framework which includes AngularJS with Jasmine unit tests and Karma test

runner for the front end. Style sheets were developed in concoction with Bootstrap. Sublime Text was

the main development tool, Bitbucket is the code repository and thus Git was used for distributed

version control. A server written in Node.js, including Mocha unit tests, was implemented and everything


is run using Bower and npm package manager and Grunt task runner. The project was planned and

developed using Scrum methodology and Balsamiq Mockups.


Workflow

Methodology and workload

The team used Scrum methodology and divide the project into nine 1-2 week long sprints. Sprint zero

was one week, all sprints after that were 2 weeks.

Each team member worked 20 hours weekly, included in that were two weekly meetings, one with the

product owner, Daníel Brandur Sigurgeirsson, and the other with the team instructor, Elín Elísabet

Torfadóttir. Twice weekly standups on skype and a (bi) weekly retrospective and planning meeting on

Saturdays at 09:00. The hours were divided between the days of the week with Saturdays being the

heaviest in workload since the team plans on meeting every Saturday both for meetings and work.

Delivery Schedule

25. August:

Detailed description of the project including an overview picture of the projects systems and the

connecting systems.

08. September:

Work organization.

First draft of a work plan.

15. September:

Work organization.

Risk Identification report.

Progress summary.

Hand-in of products according to work organization.

No products should be ready, implementation has just started.

4. October:

Release 1.


The projects base components should be ready, Evert should be able to get an event from

RabbitMQ, determine if it is an event type or event message, and handle it appropriately.

Including the possibility of sending an email as part of a handling for an event message.

20. October:

Progress summary.

Hand-in of products and data according to work organization.

Here the user should be able to handle events by sending an email.

He should also be able to create more than one handles for each event.

And the user should be able to see all handles of that particular event and edit them.

28. November:

Operating manual.

User guide.

Other data according to work organization.

Here the system should be mostly ready, after this point is a stabilization sprint to tackle any

bugs in our system before final release.

13. December:

Release 2.

All functionality should be ready and the project should be as close to bug free as possible.

All documentation should be ready to be handed in.

15. December - Final hand-in:

Final report, max three hard copies.

All data on a CD, code included.


Division of Duties

Task Description Responsible Partee

Architect Main object was to design the systems

base parts. Setting up schemas and

diagrams to describe the systems

functionality and how it connects to other

systems.

The whole group.

Business Analyst / Product Owner Main object was to keep the client’s

demands fulfilled. Creating work items,

setting up and prioritizing the product

backlog.

The whole group.

Project Manager Main objects were to make sure the

project was progressing within the set

limits, keeping in contact with all outside

parties and documentation.

Hulda Lárusdóttir.

Programming backend Main objects were the setup of the

systems back end, programming and unit

testing.

The whole group.

Programming front end Main objects were the setup and

programming of the systems front end,

programming and unit testing.

Hildur Andrjesdóttir.

Designing front end Main objects were design and setup of

the view that the user sees. Designing a

logo, setting up CSS files and maintaining

them.

Ólafur Ómarsson.


Database management Main objects were setting up and

maintaining the database, testing,

development and production databases

were set up.

Ólafur Ómarsson.

Project setup and installation Setting the project up on our clients

servers, connecting RabbitMQ and

general

Ólafur Ómarsson.

Testing and continuous integration Main objects were creating and running

acceptance tests, setting up unit tests for

programmers to continue. Later on

continuous integration and automatic

testing were added to this role.

Hulda Lárusdóttir.


Risk analysis

The risk analysis contains factors that could have impacted the systems development in a negative way. The risk factor was calculated by

multiplying the likelihood of the risk and the effect it could have. Most risks were resolved early on and the team did not have any big problems

that caused delays to production.

Risk How Likely

Effect Prevention Reduce Damage Responsible Date Resolved

Risk Factor

Not enough flow of events to handle from RabbitMQ.

5 5 Write a script that creates events and pipe to RabbitMQ.

Write the script in the beginning of the project.

Hulda. 28/9/2014 25

Our MOCK data might not represent real data well enough.

3 3 Discuss the form of data with our project manager.

Create MOCK data according to discussion with project manager.

Hildur. Hulda.

12/9/2014 9

Team member gets sick.

3 2 Work evenly to reduce likelihood of load points.

If a team member gets sick then other members share work.

Hulda. Hildur. Ólafur.

Not applicable.

6

Losing data from google drive.

1 5 Take backups of data regularly.

Backup of the data. Ólafur. 25/10/2014 5

Setup and access to servers might be delayed.

2 4 Start set-up early. Set-up locally to fall back on.

Ólafur. 19/9/2014 8

Connection to the client’s servers might fail.

3 5 Set up our own RabbitMQ and MOCK data.

Create the MOCK data early on.

Hildur. Ólafur.

19/9/2014 15


Design

This section holds design documents for the system, images to show navigation, scenarios and layout

designs which we used while developing our program. There are traditional UML images mixed in with

more unconventional images based on Simon Brown’s approach to drawing software architecture.

Message Types

There are three different types of Json strings that can be sent through RabbitMQ that Evert will pick up

from the queue and handle. Event type, event message and functions.

Event Type is a string that initiates a new event type in Evert. Event types are the sorts of events

that will happen in the clients system and users are be able to create event handlers for a

specific event type with placeholders for information to be filled in from the event message.

Event message is a string that will cause Evert to trigger all handlers for a specific event type,

send emails, text messages and run scripting handlers.

Functions is a string that will insert functions for users to have easy access to the clients system.

These will be added to a functions drop-down where code snippets can be added to the scripting

handler for programmers to have easy access to available functions in the clients API.


User Groups

User group Background System use Environment Goal

Employee Importance:

Most important.

Age: 20-60 years.

Gender: Both.

Education:

Nothing special.

Ability / disability:

Computer skills:

General computer knowledge.

Use:

Mostly used at the end and beginning of each semester.

Training:

None

Attitude:

Number of users:

5.

Technical environment:

Standard office PC.

Real environment:

At the office.

Other:

Handle events easily with little effort.

Employee with programming skills: Importance: Nice to have.

Age: 20-60 years.

Gender: Both.

Education: system engineering, Computer science .

Ability / disability:

Computer skills: Programming skills.

Use: Mostly used at the end and beginning of each semester.

Training: None

Attitude:

Number of users: 5

Technical environment: Developer.

Real environment: At the office.

Other:

Can do everything a basic employee can do and handle events more accurately.


Class Diagram

The class diagram shows the main components of Evert’s database. Tables, variables and connections between various tables. Evert’s database is

MongoDB which is a dynamic schema database consisting of objects, quite like Json objects.


System Diagram

The system diagram shows the systems main components and how it connects to outside systems. Centris is the system for which Evert was

designed but since it is a decoupled, standalone system that part of the image could stand for any API.


Workflow

Navigation Chart

The navigation chart shows the flow of the systems front end system which is a website. It shows what

pages are accessible from where and how they are connected.

Scenarios

On the following pages are four scenarios to show the inner working of Evert. The scenarios are based on

Simon Brown’s approach which focuses on more accessible images to depict how a system works. The

four scenarios show everything from an action taken in the clients API to the way event handlers are run

and processed in Evert.


Scenario 1


Scenario 2


Scenario3


Scenario4


Layout and logo

The system’s layout is based

on flat design where

functionality is the primary

object. Edges are straight,

corners are not rounded and

there are no shadows. This

leads to a faster, more

accessible website since

nothing slows loading time

more than visual effects. The

system color scheme is

based on navy blue and rich

orange, the logo is a butler

delivering messages except

the messages consist of modern symbols for emails, text messages and app notifications.

The sites layout is in style with the logo, the color scheme holds throughout the website and all fields

are clear. The image here below is of an email event handler in the system. The event type “Book

registration for course” is selected as shown in the light-blue drop-down. All event handlers for the

current event type are shown in a list on the pages left half. Active handlers are marked with a green

icon while inactive ones are marked with a dark-grey icon. Buttons to delete a single handler are

shown as X’s to the right of each item and buttons to delete all handlers and create new ones are

shown at the bottom of the list. The email handler itself is on the right hand side, with Title at the

top, fields for address, subject and main content and a save button on the bottom. Further

information about layout and usability can be found in Everts User Guide.


Progress Report

Introduction and backlog

The work was divided into two releases, one on October 4th and the second on December 13th. The

aim of the first release that is marked down below in orange was to create a basic system that could

receive events from the RabbitMQ, parse them and offer office personnel to handle these events by

sending an email of their construct including information embedded in the objects received through

the queue. The system should also be able to send an email to a specified address when such an

event occurs. This should be accomplished in two sprints and thus the two first sprints in our backlog

encompass what should have been finished before the first release.

The second release, shown below in blue shows release two where we added new features,

expanding already existing functionality and worked on setting up automation. The second sprint

was divided into four programming sprints and one stabilization sprint at the end to fix known

problems and documentation.

At last we have removed three items from our backlog. They are shown in grey below the sprint

backlog.

Sprint backlog:

User

story

Size Sprint User type Story

Status Priority

5 1 Evert

As Evert I would like to receive a list of available

event types from a company's API so that I can

listen for them on the queue. Done A

13 1 Evert

As Evert I would like to receive events from

RabbitMQ so that I can process them Done A

2 1 Employee

As an employee I would like to be able to log into

Evert so that I can work on the system Done A


1 1 Employee

As an employee I would like to sign out from

Evert so that I can leave without having the

system open. Done A

3 1 Employee

As an employee I would like to see events that I

can handle so that I can create and edit an event

handler. Done A

2 1 Employee

As an employee I would like to select a specific

event type so that I can handle it. Done A

13 2 Employee

As an Employee I would like to be able to send an

email to specific address so that I can respond

appropriately to a specific event type.

Done A

8 2 Employee

As an employee I would like to see the email

template so that I can more easily edit the

template the way I like.

Done A

8 2 Employee

As an employee I would like to use information

from an event so that I can more easily fill in an

email template

Done A

5 2 Employee

As an employee I would like to select more than

one reaction for each event type so that I can

send two or more emails.

Done A

3 2 Employee

As an employee I would like to see a list of

created event handlers so that I can have

oversight as to what has been handled

Done A

2 2 Employee

As an employee I would like to be able to sort the

visible list of event handlers based on types so

that I can have better oversight as to what has

been handled in what way.

Done B


3 2 Employee

As an employee I would like to be able to select

an item from a list of event types so that I can see

how that event is handled.

Done A

5 2 Evert

As Evert I would like to show an existing event

handler on the screen so that an employee can

edit it

Done A

5 2 Employee

As an employee I would like to see how each

event type is handled when creating/editing so

that I can choose which way to handle the event

type.

Done A

3 2 Evert

As Evert I would like to create one place for event

handlers for each event type so that I can avoid

conflicts.

Done A

2 3 Evert Fix routing problems / partial views. Done A

1 3 Evert Code review all existing code in project. Done A

1 3 Document Update presentation. Done A

1 3 Document Update progress report. Done A

13 3 Evert

Create a style sheet and work on the appearance

of the site. Done A

3 3 Employee

As an employee I would like to be able to change

how an event type is handled, e.g. add or remove

a step so that I can make sure the handler is up to

date.

Done A

5 3 Employee

As an employee I would like to select an old event

handler and delete it so that I can remove

unnecessary items from Evert.

Done A


13 3 Evert Work on unit testing existing code. Done A

3 3 Employee

As an employee I would like to select to send an

email to multiple addresses so that I can make a

response to a specific event type.

Done A

12 3 Evert Automation planning Done A

2 4 Employee

As an employee I would like to be able to select

an advanced interface so that I can have more

control over the events

Done B

5 4 Evert

As Evert I would like to get further information

from company's API so that I can provide

additional options for employee with

programming skills.

Done

B

20 4 Employee

As an employee with programming skills I would

like to create an event handler using JavaScript so

that I can handle events in more details.

Done B

13 4 Evert Setting up CI and Automated test. Started B

5 4 Evert Unit testing Done

5 4

Employee w.

programming

skills

As employee with programming skills I would like

to edit script for an existing event so that I can

create a new handler for an already handled

event type. Done B

5 5 Evert

As Evert I would like to show the script for the

existing event handler which the employee can

edit so that an employee with programming skills

can create a new handler for an already handled

event type. Done B


8 5 Employee

As an employee I would like to be able to sort the

visible list of event types so that I can have better

oversight. Done B

3 5 Updating reports and writing manuals Done B

6 Evert Outside API Done C

3 6 Employee

As an employee I would like to select to send a

text message to multiple phone numbers so that I

can make a response to a specific event type. Done C

3 6 Employee

As an employee I would like to select to send a

text message to multiple phone numbers so that I

can make a response to a specific event type. Done C

6 Create help page Done B

1 6 Update presentation. Done A

1 6 Update progress report. Done A

6 Evert Setup logging Done C

7 Regression testing Started C

7 Configuration and setup Started A

7 Items to be fixed Started C

Removed Items

Below is a list of removed items. They were removed after discussion with our Product Owner and it

became apparent that this functionality did not fit the system well. This could cause problems

because of how different event types are set up. The event messages carry with them information

and the user has the option to insert a placeholder into any handling they create.


5 6 Employee

As an employee I would like to select an

email template when creating/editing an

event handler so that I can send emails

about the event.

Removed B

8 5 Employee

As an employee I would like to create an


event handler so that I can customize the

information sent in the email. Removed B

13 6 Employee

As an employee I would like to save an


event handler so that I can use that

template again later. Removed B

Progress

As stated before the project had two releases. The first release encompassed sprint zero and two

programming sprints, or four weeks for programming and three weeks before that in setting up and

planning the project. The second one was 5 sprints, four programming sprint and one stabilization

and documentation sprint, it encompassed ten weeks.

Burn-down’s

Following are burndowns for the two releases and a short explanation of the progress. For a more

detailed account please refer to Appendix II for a full progress report.


Release 1

Basic Flow

This burn-down shows the progress of the two programming sprints for release one. The planning

period was not inserted into the planning and to begin with only sprint one was broken down into

hours. After sprint one was finished the team had more information of its capacity and the rest of

the backlog was broken down roughly this is why the chart spikes suddenly in the middle.

Release 2

Added features

Release two encompasses more time and more features, to begin with the team was hesitant to plan

too much in. When the full extent of the teams capacity and the scope of items on the backlog was

clear planning was finalized. Some nice to have items, like logging and others, were added to the

scope as can be seen by the spike around the middle of November. The red line at the burn-downs


tail signifies status on the date when this report went into printing for final hand in. At that time

three days were remaining of the last sprint.

Comments

By the burn-down’s it is apparent that the progress was constant, if a bit jerky, and the original scope

of the project was just about the correct size for this group. Everything discussed by the Product

Owner and the team in the beginning of the period was implemented in an orderly and timely

fashion. Some problems arose, team members, or their children, were sick and some tasks were not

as straight forward as anticipated. But the impact on the product and the continuity was minimal,

team members helped each other out and took tasks that other could not finish and in some cases

tasks were moved between sprints to finish them.


Conclusion

The Good

The process went well, the team was coherent and everyone was willing to do the best job they

could. All deliverables were handed in according to schedule and most features were finished before

the deadline and then some. The only features left out were the ones our Product Owner was not

excited about. We had planned on enabling the user to create message templates to be used in

different places in the system but it did not fit in well with the way event types and event handles

were tied together. There were also quite a few features added in the course of the project that

were not originally planned into the scope but some the Project owner asked for, i.e. ace editor for

the advanced handler, and others because the team felt they would add value to the project. Among

those were search features, ability to activate and deactivate event handlers (instead of deleting

those not wanted at the moment) and logging of activities in the system for future users.

The Bad

As stated above the project had a constant progress, the team had very few problems and most of

them were anticipated and solved rather quickly. The only problem that the team encountered was

using Jenkins for continuous integration and automated testing. There were problems with deploying

from the machine Jenkins is located on (a windows server) to the machine where Evert was

supposed to be running (CentOS machine) for Reykjavík University, our client. The theory is that

there is a communication problem within the Jenkins plugin so after much work and a lot of time the

decision was made in conference with Project owner and instructor to put the continuous integration

aside to work on other things. This was something that was not required and was added to the

project as an afterthought so there was not a big loss in setting it aside. There were also some

problems with test automation, Jenkins could not run Evert’s unit tests and thus an automatic test

report was not created. This might be due to the fact that PhantomJs (the test browser) that Jenkins

wanted to use was installed for another project kept on the same server as Jenkins.

And the Ugly

The team feels that there are three obvious steps to be taken next in the course of this project, to

connect it to mobile apps, set up functionality to create event types in Evert’s GUI and to look into

security concerns.

Connection with mobile apps was left out from the projects scope, this was discussed between the

team and the Product owner on behalf of Reykjavík University, but it would add greatly to the

systems value to have the ability to send messages to mobile apps. For example if sending push


notifications to apps connected with the client. Those might be notification apps or interactive apps

that also offer the possibility of sending notifications.

Event types can only be created through RabbitMQ, but it would be preferable if Evert’s users could

set up event types through the user interface.

Security issues were also left out of the scope since the system will be run behind a firewall and it will

not have any contact with systems outside of the firewall except through a proxy. Thus it was judged

that there were minor security concerns when developing the system in-house. However if anyone

wants to take the project and use it with their system there are a few valid concerns. There is no

encryption on messages sent to and from the system and thus anyone can intercept the messages

and do with them what they will. That should be a big concern for anyone using the system. For a

more detailed list of known issues please refer to the test report in Appendix I.

I T-404-LOKA, Lokaverkefni, 2014-3

Appendix I

Test Report

Introduction

This document identifies the scope, test cases being tested, test results, and the test conclusion during

testing of the system Evert. The objective of the report is to report the activities during the testing of the

sprint plan “Stabilization and documentation: Evert”.

Summary

Overall Progress of the Testing Cycle On time

Total number of test cases 40

Number of testers 1

Test cycle duration 1 day

Number of test cases executed 40

Number of defect encountered 3

Number of critical defects- still open 0

Pass Percentage of the defects 100%

Defects density 3 per day

Critical defects percentage 30%

II T-404-LOKA, Lokaverkefni, 2014-3

Detailed status

TFS ID PBI Title Test Case Title Status

(Pass/Fail)

4 As an employee I would like to be able to log into Evert so that I can work on the system.

69 Is there a login screen? Pass

70 Login screen appearance. Pass

71 Logging in. Pass

5

As an employee I would like to sign out from Evert so that I can leave without having the system open.

72 Logging out - is there a logout button? Pass

73 Try logging out. Pass

74 Is the user really logged out? Pass

6

As an employee I would like to see events that I can handle so that I can create and edit an event handler.

Pass

75 Is there a dropdown with listed events in the event handling page?

Pass

302 Are all event types listed on the start page?

Pass

7 As an employee I would like to select a specific event so that I can handle it.

76

Is the event: Book registration for course selectable?

Pass

8

As an Employee I would like to be able to send an email to specific address so that I can respond appropriately to a specific event.

105 Is there an input field for receivers address?

Pass

106 Add an email address to an email template.

Pass

107 Verify that when an event occurs an email is sent.

Pass

III T-404-LOKA, Lokaverkefni, 2014-3

108 Verify that when an event occurs an email including data from the event object is sent.

Pass

10

As an employee I would like to use information from an event so that I can more easily fill in an email template.

101 Are there buttons representing available information for the specified event in email handlers?

Pass

102 Does a placeholder appear in an email handler when a placeholder button is pressed?

Pass

327 Does a placeholder appear in a text message handler when a placeholder button is pressed?

Pass

328 Does a placeholder appear in a scripting handler when a placeholder button is pressed?

Pass

331 Are there buttons representing available information for the specified event in text message handlers?

Pass

332 Are there buttons representing available information for the specified event in scripting handlers?

Pass

11

As an employee I would like to select more than one reaction for each event so that I can send two or more emails.

303 Can there be more than one event handlers for any event type?

Pass

304 Can there be multiple email handlers for any event type?

Pass

305 Can there be multiple text message handlers for any event type?

Pass

306 Can there be multiple scripting handlers for any event type?

13

As an employee I would like to be able to sort the visible list of event types so that I can have better oversight.

323 Can event types be sorted alphabetically? Pass

IV T-404-LOKA, Lokaverkefni, 2014-3

324 Can event types be sorted chronologically?

Pass

325 Can event types be sorted by number of handlers?

Pass

326 Can a user search for any one event type? Pass

14

As an employee I would like to be able to select an item from a list of event types so that I can see how that event is handled.

307 Is there a list of available event handlers connected to an event type?

Pass

15

As Evert I would like to show an existing event handler on the screen so that an employee can edit it.

308 Is an event handler available for editing? Pass

18

As an employee I would like to be able to change how an event is handled, e.g. add or remove a step so that I can make sure the handler is up to date.

319 Is there any way to see how an event type is handled?

Pass

22

As an employee I would like to select an old event handler and delete it so that I can remove unnecessary items from Evert.

314 Can a user toggle the view to see active/all event handlers?

Pass

313 Can a user deactivate an event handler? Pass

312 Can a user delete all event handlers for a specific event type?

Pass

311 Can a user delete an event handler? Pass

23

As an employee I would like to select to send an email to multiple addresses so that I can make a response to a specific event.

320 Can Evert send the same email to multiple email addresses?

Pass

V T-404-LOKA, Lokaverkefni, 2014-3

24

As an employee I would like to select to send a text message to a specific mobile number as a response to a specific event so that I can notify people via mobile.

322 Can Evert send the same text messages? Pass

25

As an employee I would like to select to send a text message to multiple phone numbers so that I can make a response to a specific event.

321 Can Evert send the same email to multiple phone numbers?

Pass

37

As Evert I would like to get further information from company's API so that I can provide additional options for employee with programming skills.

196 Are there clickable buttons in scripting handler interface?

Pass

39

As an employee with programming skills I would like to create an event handler using JavaScript so that I can handle events in more details.

198 As an advanced interface user can I add a script that will work with Evert functions?

Pass

41

As employee with programming skill I would like to edit script for an existing event so that I can create a new handler for an already handled event type.

310 As an advanced interface user can I edit a scripting handler?

Pass

VI T-404-LOKA, Lokaverkefni, 2014-3

Issues

Defect

ID Defect Description Steps to Reproduce Severity State

263 When enter pressed while creating handler something goes wrong.

Go to an event type.

Click to create new text message / scripting handler.

Press enter without doing anything else

The window behaves oddly, jumps up and when an event handler is created the window does not disappear.

High To Do

Remaining Risks

Nr. Risk Description Severity

R001 Security is

lacking

No measures have been taken

to encrypt data going to and from the system. Anyone

could send messages to the system and have them

processed as long as they

know the correct format.

Critical

Test Conclusion Advice - Based on the results of testing, knowing the open defects the advice for Evert for proceeding to

the next stage is: Positive.

Appendix II

Progress Report

This is a record of retrospectives and our conclusions after each sprint. The sprint burn-downs are

included as well as release burn-downs. The sprints will have uneven burn-downs since the bulk of our

work is done on weekends.

Release 1

The project has two releases and release one has two out of the 7 sprints, sprint one and two. The goal is

to set up a basic system that can receive events and send out an email when the event has been

VII T-404-LOKA, Lokaverkefni, 2014-3

processed. The system should offer a simple interface to control what the email says and where it should

be sent.

Release one, as stated above, included two sprints. The division is very obvious in the burn-down since

we did not finish planning sprint two until just before it started and thus the release was planned in two

stages as shown by the sudden jump on September 19th.

Sprint 1

Sprint goal

Getting started, get a connection to RabbitMQ and set up the web UI.

Retrospective notes

Good - Keep up: Could be better:

Good team spirit. III Communication with instructor (Elín) should be more regular. I

Easy to discuss problems. II Standups should be firmly held as scheduled. I

Everyone wants to work well. I I should ask for help sooner rather than later. I

Project is progressing as expected.

I I need more time to acquaint myself with other team member’s work.

I

VIII T-404-LOKA, Lokaverkefni, 2014-3

Get more help from Project owner (Daníel) with RabbitMQ. I

Burn-down

Conclusion

We are happy with the way we work together, everyone is willing to participate fully and do everything

as well as they can. But we need to ask for help sooner rather than spend too much time stuck on

problems in our little corners. We also need to adhere strictly to the scum method to reap the benefits,

like holding standups three times a week and keep to meeting our instructor regularly. By doing that we

will likely have more natural opportunities to ask others for help.

Sprint 2

Sprint goal

Getting a connection through our system from RabbitMQ and out with an email.

Retrospective notes


Good cooperation. I Heavy sprint. I

Reached our goals. I Could be good to get a clearer coherent picture of the final product.

I

IX T-404-LOKA, Lokaverkefni, 2014-3

Communication has been improving. I Standup meetings could be held more regularly. I

Everyone ready to help and support each other.

I We need to Get a clearer image of what our capacity is.

I

Lot of work done. I

Burn-down

65 story points almost finished. We had 18 points from sprint three that were finished almost by default

since we did not understand how MongoDB works and thus the planning for our UI was not

accurate. Furthermore 18 of these story points were carried over from sprint 1 and thus they are not

fully there so organized work for the sprint was around 30 points originally.

Conclusion

We work well together and strive to reach our goals. We need to make sure to set reasonable goals so

we do not overwork the team or single team members. We also need to be firmer when it comes to

standups so we are always well aware of what other team members are doing and if they are struggling.

Release Conclusion

After release one almost all planned features were finished, tasks from three stories were moved to

release two and thus there are three open items at the end of release one. First the set-up of our

database and RabbitMQ on Reykjavík university machines, that we did not get access to until a couple of

X T-404-LOKA, Lokaverkefni, 2014-3

days before the end of release one. Secondly we did not accomplish putting together information from

incoming objects to outgoing messages.

Release 2

Release two is aimed at improving our system by adding tests and automation, making the email

function more complete and add an advanced interface for users with programming knowledge.

Release 2 burn-down:

This burn-down was inserted three days before release date since the report had to go be printed before

final hand-in.

Sprint 3

Sprint goal

Clearing up the code and work on TDD and Automation.

Retrospective notes


The base of the product is coming well together.

I Sprint started slowly. I

XI T-404-LOKA, Lokaverkefni, 2014-3

The view is looking good. II We need to burn hours more regularly in TFS.

I

Code has been cleaned up a lot. I

Meetings with PO and instructor are going well. I

Old issues solved, i.e. server and text assembly. II

Burn-down

Conclusion

The sprint started slowly but progressed well once everyone started their tasks. The code’s format has

been moved closer to standard JavaScript standards, we solved some old issues and the project is

looking good both code wise and it is aesthetically pleasing.

Sprint 4

Sprint goal

Setting up advanced feature, TDD and automation.

XII T-404-LOKA, Lokaverkefni, 2014-3

Retrospective notes


Good preparation and successful presentation.

III Keep up the meeting schedule, standups for example.

I

All parties to the project are willing to help at any time.

I Perhaps a touch of complacency, mainly due to tiredness because of hard work so far.

II

Growing understanding between members. Everyone knows their role in the group.

I

Team spirit is good. I

Burn-down

Conclusion

The sprint was a bit rocky, we forgot to plan in time to prepare for the presentation and thus many tasks

were started late in the sprint. The presentation went well and we started our tasks and finished most of

them on time. The only thing that was not finished in the sprint was setting up CI using Jenkins, we are

trying to sort out our problems with deploying to leit.dev.nem.ru.is but we might need to get some help.

That being said the group work is going smooth, we are all aware of how to separate tasks, what are

each other’s strengths and weaknesses.

XIII T-404-LOKA, Lokaverkefni, 2014-3

Sprint 5

Sprint goal

Improve advanced feature and finalize automation.

Retrospective notes


Team spirit stronger than ever. I Automated testing did not get finished like planned.

I

Good and flexible organization lets members be away (test, sickness) without harm.

II

Final functionality is starting to show. I

Understanding when sickness of team members and team helpers slows down progress.

II

Status of project is good considering the time we have left.

I

Burn-down

XIV T-404-LOKA, Lokaverkefni, 2014-3

Conclusion

The sprint was not finished due to tests and sickness so the overflow will be moved to the next sprint.

Team spirit is very good and the project is progressing well.

Sprint 6

Sprint goal

Set up text message functionality and finalize test automation.

Retrospective notes


We got Evert “Almost feature complete” for the final sprint.

II Standups are not held formally but we talk almost every day.

I

Staying on course to finish on time. III Worried about lack of code feedback. III

Great to see initial planning paying off. II

Burn-down

XV T-404-LOKA, Lokaverkefni, 2014-3

Conclusion

The sprint had a positive conclusion even though Jenkins setup is still giving us problems. All deliverables

are coming along nicely and we are a tightly knit group with a common goal to work well and delivering a

good product. We are growing more and more worried about the lack of code feedback since time grows

short and it will be hard to make more than minor changes.

Stabilization and documentation

Sprint goal

Finalize project and reports for hand-in.

Retrospective notes


Tasks are getting done really fast. I

Team members are all going the extra mile to put finishing touches on the project.

II

Everyone is pulling in the same direction and helping each other out.

I

Burn-down

XVI T-404-LOKA, Lokaverkefni, 2014-3

Conclusion

This was the status of the burn-down at the time of printing this document. Three days were remaining

and almost all tasks were done. Remaining were one bug, a few items that might be added, finalizing

setup of the system on the schools machines with the right configuration. The sprint went well and

everyone was cooperating to finish all loose ends and handing in a good product.

Summary

Most estimations have been accurate us in the latter half of the project. All functionality discussed at the

start of the working period has been implemented except for a few things excluded after discussion with

Daníel Brandur, the Product Owner. A few extra features have been implemented as well, for example

activating and deactivating event handlers, search functionality and syntax highlighting is in the works

for the advanced feature by adding Ace to the project.

T-404-LOKA, Final Project · developed using Scrum methodology and Balsamiq Mockups. 3 T-404-LOKA,...

Documents

Transcript of T-404-LOKA, Final Project · developed using Scrum methodology and Balsamiq Mockups. 3 T-404-LOKA,...