SE560 Notebucket Final Report

FINAL REPORT
NoteBucket Project
Ozan Dlgerolu 2121101
Bar Dastn 2120210
Cansn Tartc 2061000
JUNE 13, 2016

Document History
Report Name Date Description State
PMP V1.0 29.02.2016 Project summary draft Released
PMP V1.02 11.06.2016 Project Management Plan Released
SRS V1.02 11.06.2016 Software Requirement Released

Specification
SDD V1.02 11.06.2016 Software Design Document Released
STD V1.02 11.06.2016 Software Test Document Released
1
Preface
The purpose of this document is to gather all documents for our project NoteBucket as a Final Report. This
documents contains Project Management Plan (PMP), Software Requirement Specification (SRS), Software
Design Document (SDD) and Software Test Document (STD)
2
Contents
Document History ......................................................................................................................................... 1
Preface........................................................................................................................................................... 2
1. Project Overview ....................................................................................................................................... 7
1.1 Project summary ................................................................................................................................. 7
1.1.1 Purpose, scope and objectives ..................................................................................................... 7
1.1.2 Assumptions and constraints ....................................................................................................... 7
1.1.3 Project Deliverables...................................................................................................................... 8
1.1.4 Schedule ....................................................................................................................................... 9
1.2 Evolution of the Plan ......................................................................................................................... 10
2. References ............................................................................................................................................... 10
3. Definitions ............................................................................................................................................... 10
4. Project Context ........................................................................................................................................ 11
4.1 Process Model ................................................................................................................................... 11
4.2 Process Improvement Plan ................................................................................................................ 12
4.3 Methods, Tools and Techniques ....................................................................................................... 12
4.4 Infrastructure Plan............................................................................................................................. 12
4.5 Product Acceptance Plan................................................................................................................... 12
4.6 Project Organization .......................................................................................................................... 12
5. Project Planning....................................................................................................................................... 12
5.1 Project Initiation ................................................................................................................................ 12
5.1.1 Estimation Plan ........................................................................................................................... 12
5.1.2 Staffing Plan ................................................................................................................................ 12
5.1.3 Resource Acquisition Plan .......................................................................................................... 13
5.1.4 Project Staff Training Plan .......................................................................................................... 13
5.2 Project Work Plans ............................................................................................................................ 13
5.2.1 Work Activities ........................................................................................................................... 13
5.2.2 Schedule Allocation .................................................................................................................... 13
5.2.3 Resource Allocation .................................................................................................................... 13
5.2.4 Budget Allocation ....................................................................................................................... 13
5.2.5 Procurement Plan ....................................................................................................................... 13
6. Project Assessment and Control ............................................................................................................. 13
6.1 Requirements Management Plan...................................................................................................... 13
3
6.2 Scope Control Plan ............................................................................................................................ 13
6.3 Schedule Control Plan ....................................................................................................................... 14
6.4 Budget Control Plan........................................................................................................................... 14
6.5 Quality Assurance Plan ...................................................................................................................... 14
6.6 Subcontractor Management Plan ..................................................................................................... 14
6.7 Project Closeout Plan ........................................................................................................................ 14
7. Product Delivery ...................................................................................................................................... 14
8. Supporting Process Plans ........................................................................................................................ 14
8.1 Project Supervision and Work Environment ..................................................................................... 14
8.2 Decision Management....................................................................................................................... 14
8.3 Risk Management .............................................................................................................................. 15
8.4 Configuration Management .............................................................................................................. 15
8.5 Information Management ................................................................................................................. 15
8.5.1 Documentation........................................................................................................................... 15
8.5.2 Communication and Publicity .................................................................................................... 15
8.6 Quality Assurance .............................................................................................................................. 15
8.7 Measurement .................................................................................................................................... 15
8.8 Reviews and Audits ........................................................................................................................... 16
8.9 Verification and Validation ................................................................................................................ 16
9. SRS Overview ........................................................................................................................................... 18
9.1 Product Perspective .......................................................................................................................... 18
9.2 Product functions .............................................................................................................................. 18
9.2.1 Create new note ......................................................................................................................... 18
9.2.2 Delete note ................................................................................................................................. 18
9.2.3 Send note.................................................................................................................................... 18
9.2.4 Edit note ..................................................................................................................................... 18
9.3 User Characteristics ........................................................................................................................... 19
9.4 Limitations ......................................................................................................................................... 19
9.5 Assumptions and Dependencies ....................................................................................................... 19
9.6 Apportioning of Requirements .......................................................................................................... 20
10. Requirements ........................................................................................................................................ 20
10.1 External Interface Interfaces ........................................................................................................... 20
10.2 Functions ......................................................................................................................................... 20
4
10.3 Usability Requirements ................................................................................................................... 21
10.4 Performance requirements ............................................................................................................. 21
10.5 Logical Database Requirements ...................................................................................................... 22
10.6 Software system attributes ............................................................................................................. 22
10.7 Other Requirements ........................................................................................................................ 22
11. Verification ............................................................................................................................................ 23
12. Use Case ................................................................................................................................................ 24
12.1 Use Case descriptions and Sequence Diagrams .................................................................................. 25
13. Class Diagram ........................................................................................................................................ 32
14. Design Introduction ............................................................................................................................... 33
14.1 Purpose............................................................................................................................................ 33
14.2 Scope ............................................................................................................................................... 34
14.3 Definitions ....................................................................................................................................... 34
14.4 Context ............................................................................................................................................ 35
14.5 Summary.......................................................................................................................................... 36
15. References: ............................................................................................................................................ 36
16. Design Viewpoints ................................................................................................................................. 37
16.1 Context Viewpoints ......................................................................................................................... 37
16.1.1 Use Cases .................................................................................................................................. 37
16.2 Composition Viewpoint ................................................................................................................... 44
16.3 Logical Viewpoint ............................................................................................................................ 45
16.4 Patterns Viewpoint .......................................................................................................................... 47
16.5 Interface Viewpoint ......................................................................................................................... 48
16.6 Interaction Viewpoint...................................................................................................................... 49
17. Introduction ........................................................................................................................................... 55
17.1 Scope ............................................................................................................................................... 55
17.2 References ....................................................................................................................................... 55
18. Plan Context .......................................................................................................................................... 56
18.1 Project ............................................................................................................................................. 56
18.2 Test Items ........................................................................................................................................ 58
19. Test Strategy .......................................................................................................................................... 59
19.1 Test Sub-processes .......................................................................................................................... 59
19.2 Test Deliverables ............................................................................................................................. 59
5
19.2 Test design Techniques ................................................................................................................... 59
19.3 Test Completion Criteria ................................................................................................................. 59
20. Test Design Specification ....................................................................................................................... 60
21. Test Case Specification .......................................................................................................................... 61
22. Test Data Requirements ....................................................................................................................... 64
23. Test Environment Requirements........................................................................................................... 64
24. Test Completion Report ........................................................................................................................ 65
6
1. Project Overview
1.1 Project summary
1.1.1 Purpose, scope and objectives
Note-Bucket is a platform for users to keep their notes on the cloud and share them with other
registered users in the system. The user can take notes as text, voice and create reminder for
specific events. The purpose of this project is to help users to keep all their notes in a cloud based
environment so that they can access them from anywhere. The user can edit, delete, read existing
notes and create new notes. If a note has a reminder function set up beforehand, the system shall
inform the user about it.
With this project, we aim to help people keep on top of their to-do more efficiently and organize
their daily/weekly etc. activities better.
1.1.2 Assumptions and constraints
The project will both be a web application and an android application. The technologies
to be used are Java, Spring Framework, ElasticSearch, RESTfull API and Maven in Server
side
HTML5, JS, CSS, Flash, RESTfull API and Maven in client side to implement the project.
Then, PhoneGap will be used to port our web client for mobile applications.
Testing will done using Selenium Framework for java and Selenium Web Driver for
automated testing.
The project will be open source. Github will be used both to make teamwork easier and
to match to the evolving software development trends.
The end product will be delivered in 13.07.2016 making the whole project lifecycle 3.5
months (not including maintenance).
Free trial cloud services will be used thus, it is assumed that the budget will be close to
non-existent or none at all.
Since NoSql is not optimal for relational data handling, MySQL will be used for storing user
related information. For other information handling, NoSql Will be used
Since PhoneGap will be used, the mobile application will not be native thus, complex
animations will not be used to make the front end performance effective.
7
1.1.3 Project Deliverables
No Name Abbreviation Date
1 Project Management PMP Week 3

Plan
2 Software Requirement SRS Week 5

Specification
3 Software Design SDD Week 10

Description
4 Test Documents TD Week 13
5 End Product EP Week 17
Table 1 Deliverables
8
1.1.4 Schedule
Weekly Schedule
Week 2 Project summary drafts to be submitted

Feb 29
Week 3 Software project management plans to be

submitted (IEEE 16326)
Mar 7
Week 5 Software requirement specifications to be

submitted including draft system
Mar /21
architecture. (IEEE 29148)
Week 8 System demos (release-1).

Apr 11
Week 10 Design documents to be submitted (IEEE

1016).
Apr 25
Week 13 Test plans to be submitted. (IEEE 829,

system level)
May 16
System integration, system testing.
Week 16 Project presentations and system demos

(the second and final release)
(Finals week 2)
Jun 6
Week 17 Submission of final reports. The final report

includes the revised and extended versions
(Post-finals week)
of the previously submitted documents,
Jun 13 release-2 test report (IEEE 829), and related
data packages (sources, configuration files,
databases, test data, installation guide, user
guide, etc.)
Table 2 Schedule
9
1.2 Evolution of the Plan
The plan shall go through internal review and internal acceptance steps, after that, it shall be
presented to the Stakeholders for approval. If there is any change (update) request, the PMP shall
be reviewed and changed accordingly and shall be subjected to internal review and internal
acceptance steps again. This cycle will continue until all stakeholders approves the PMP. All these
steps shall be documented according to the configuration plan
2. References
Title Date Version
ISO/IEC/IEEE16326 System and Software Engineering, Software

Life Cycle Processes- Project Management
15.12.2009 First edition
Project Management Plan Draft

29.02.2016 V1.0
Table 3 References
3. Definitions
Name Definitions
Git Github: Version Checking and Team Management Tool
METU Middle East Technical University
UML Unified Modelling Language
UML Unified Modelling Language
10
Waterfall The waterfall model is a sequential design process, used in software development
processes
SRS Software Requirement Plan
SDD System Design Document
Table 4 Definitions
4. Project Context
4.1 Process Model
Project life cycle model has been determined according to the corporate Life Cycle Processes document
and Waterfall Model has been selected as life cycle for NoteBucket project. Milestones and baselines are
determined as for work product publish and approval at the end of each phases.
Baselines will be drawn are followings:
Approval of SRS document,

Approval of SDD document,
Build of source code,
Testing and fixing the source code; test results document approval,
Acceptance of the end product
Figure 1 Waterfall
11
4.2 Process Improvement Plan
There is no process improvement plan that would be conducted for this project.
4.3 Methods, Tools and Techniques

Java, Spring Framework, ElasticSearch, RESTfull API, Maven in server side
HTML5, JS, CSS, Flash, PhoneGap in client side
NoSql and MySQL for database management system
Selenium Framework and Selenium Web Driver for testing
Github for team collaboration
Microsoft Project for project management tool
Star UML for UML modeling
4.4 Infrastructure Plan

Hardware and software stated in 3.3 Methods, Tools and Techniques will be used integrated in appropriate
network infrastructure in order to perform project activities.
4.5 Product Acceptance Plan

The product will be accepted with a project presentation and final report. In the presentation, product
should satisfy the requirements driven from the analysis and design phases. Test plans will be the guide
for the proficiency of the product before the presentation.
4.6 Project Organization

Each member of the project has equal responsibilities. There are no authority or responsibility differences
between team members.
5. Project Planning
5.1 Project Initiation
5.1.1 Estimation Plan
The cost of the project will be 16 man-months. There is no other cost or budget planning for the
project. Schedule is very strict and shown in the Gantt chart. To satisfy the necessary schedule
milestones, each week there will be a weekly progress meeting between project members. In
these meetings progress will be discussed and how to improve the process will be defined.
5.1.2 Staffing Plan

There will be no staffing plan in the project. Four members of the project will work during the
project and there will be no other staffing.
12
5.1.3 Resource Acquisition Plan
The release activities are specified in the Gantt chart.
5.1.4 Project Staff Training Plan

There will be no project staff training plan in the project but for technical document sharing
google drive will be used.
5.2 Project Work Plans

5.2.1 Work Activities
Work activities are shown on the Gantt chart.
5.2.2 Schedule Allocation

Schedule is shown on the Gantt chart.
5.2.3 Resource Allocation

Resources of the each task are the project members. There is no other external or internal
resource dependency.
5.2.4 Budget Allocation

There is no budget allocation for the project. As mentioned above all the budget is the work of
the project members and it is nearly 16 man-months.
5.2.5 Procurement Plan

There are no goods to be purchased in the project. All the services will be provided by project
members.
6. Project Assessment and Control

6.1 Requirements Management Plan
Project Requirements shall be extracted from the proposal and the discussions with the
Stakeholders. The extracted information shall be documented in the SRS. After the internal review
and approval phase, the SRS shall be given to the Stakeholders for an external review. The
stakeholders shall conduct their own review and the proposed changes (if any) shall be integrated
according to the Configuration Management Plan. Once the SRS those processes are complete,
the baseline shall be established. The SRS and SDD shall be linked to make sure there are no
requirements without a link to the proposed and discussed system requirements
6.2 Scope Control Plan

Since the Project scope is already discussed and approved by the stakeholders, there will be no
scope changes thus, this project does not have a Scope Control Plan
13
6.3 Schedule Control Plan
Every member shall be responsible for fallowing the schedule described in Gantt chart. The
conformance to the schedule shall be checked biweekly to assure that the team is on schedule.
In case of derivations from the plan, all stakeholders will be informed and weekly Development
sprints shall be conducted by the development team to get the schedule back on track.
6.4 Budget Control Plan

Project budget shall only be considered with respect to the man-month since there is no monetary
budget required as mentioned above. Man-month allocation shall be decided biweekly in the
team meetings.
6.5 Quality Assurance Plan

6.6 Subcontractor Management Plan
The project does not have any subcontractors thus, there is no Subcontractor Management Plan
6.7 Project Closeout Plan

In the Closeout, the project shall be delivered as a final report and in-class Demo. All reports (including the
final report shall be kept with respect to their versions. For further reference.
7. Product Delivery
Below can be seen the delivery lists:
Project Summary Draft

Software Project Management Plan
Software Requirement Specifications
Software Design Document
Test Plan
Project Demo
Final Report
For the delivery, the plan is shown in the Gantt chart. To deliver each report, demonstrations and other
documents waterfall approach will be used as mentioned above. In each phases of the project a delivery
will be done with cooperative work among the project members.
8. Supporting Process Plans

8.1 Project Supervision and Work Environment
Work environment for all the phases of the project is Computer Engineering Building in METU.
Necessary hardware and software described in 3.3 Methods, Tools, and Techniques will be provided to the
team members.
8.2 Decision Management

Project progress meetings will be the guide for assignments of duties. Every analysis and design decision
will be made on those meetings.
14
8.3 Risk Management
Initially anticipated risks with high priority rate are listed in Table 6 Risk List. This list will be updated
throughout the project.
Priority Definition Impact

High Lack of experience and resources. As a team, we Delivery,
have no much experience about cloud applications. Delay
We have to complete the project within 4 months.
High The cloud environment that we will use may Cost
demand us some money according to the usage of
the system.
High The software which we will use may be Inconsistency
incompatible. We have to integrate the software
described in Methods, Tools and Techniques
appropriately.
Table 5 Risk Management
8.4 Configuration Management

For configuration management git will be used.
8.5 Information Management

8.5.1 Documentation
Documentation plan is also given in the Gantt chart. So far we submitted project summary draft and this
project management plan. Other documentation details can be seen in the Figure 1.
8.5.2 Communication and Publicity

As mentioned above project progress meetings are essential for communication. Also google drive for
technical documents, e-mail and phone are other communication ways.
8.6 Quality Assurance
For quality assurance our plan will be based on those clauses:
Requirements
Function Points
Test cases
Verification and validation processes
8.7 Measurement
Git, UML modeling tools (Star UML) and Function Points will be the guides for measurements.
Requirements will be the base for measurement of the final product.
15
8.8 Reviews and Audits
Feedback, review of our instructor will maintain our projects faults and we will be correcting these
drawbacks.
8.9 Verification and Validation

We will do test plan and we will have test steps and we will write these steps together. Each use cases will
have a scenario and they will be tested with test scenarios.
16
Figure 2 Gantt
17
9. SRS Overview
9.1 Product Perspective
The product is shall be an open source, under the GNU general Public License. It is a web based
system implementing client-server model. The NoteBucket application provides simple
mechanism for users to save and share their daily notes and reminders.
User interfaces will be implemented as html pages and also since NoteBucket will support Android
Devices, there will be an .apk Android application.
Google Cloud Services will be used as web service provider. Facebook API - OAuth will be used as
external services to enable users to login with Facebook accounts.
NoteBucket is multiple user environment so the server will have multi-core processor and at least
6 GB ram needed. There will be both relational database for user credentials and stored
document links, also there will be a NoSQL Database for text base input storage.
9.2 Product functions

9.2.1 Create new note
Create a new note function shall happen by fallowing steps; User clicks the new note button.
Then, he enters data (text, voice etc.) and clicks save button. Data is encoded as JSON and sent to
the server and the server authenticates the user and processes the request. If the user does not
click the save button, the data is not saved
9.2.2 Delete note
Delete note function shall happen by the fallowing steps; User opens note repository and hits
delete button on the note, then he is prompted to verify their action. If the user verifies the action,
a request shall be sent to the server. Server authenticates the user and the note shall be deleted.
If the user selects not to delete the note, the action shall be reversed back.
9.2.3 Send note
Send note function shall happen by fallowing steps; User opens note repository and hits share
button on the note, then he is prompted to verify their action and to enter e-mail address of the
recipient. After the user verifies the action, a request shall be sent to the server to processing. If
the entered e-mail address is faulty, the user shall be informed and prompted to enter a new e-
mail address.
9.2.4 Edit note
Edit note function shall happen by the fallowing steps; User opens note repository and hits edit
button on the note, the user makes changes and then hits the save changes button, then he is
prompted to verify their action. After the user verifies the action, a request shall be sent to the
server to processing. If there is no change in the note, the user shall be notified. If the user does
not verify the edit action, the note shall be kept as is.
18
9.3 User Characteristics
The application shall be used by users who have at least passing knowledge about using
computers i.e. Novice and upper level users. Thus, the application shall not be aiming to teach
how to use a device; rather it will try to make users understand the note taking, sharing etc. and
accessing them through cloud. Other than this, the application shall appeal to anyone who knows
how to use a device that is connected to internet.
9.4 Limitations
Regular limitations of a Cloud application such as data security and network connection reliability
naturally applies to our project. In addition to these, complex animations will be limited in number
since we will be auto porting our web client to mobile.
Data security is a crucial part of the project because of 2 reasons. First one is that users will have
to sign up using their personal info (such as e-mail address, Facebook account etc.) and the second
reason is that users may take notes that includes personal data or something they do not want to
be publicized. The clients data can be susceptible to hacking or phishing attacks. Since the servers
on cloud are interconnected it is easy for malware to spread further to other clients.
Another limitations is that we cannot assume that the user has a reliable network connection that
can handle big data transfers on high speed. Because of this, most of our data transfers are text
based like text notes and reminders. The only exception to this is that the user can take voice
based notes (voice recordings).
The last limitation is about animations on the client side. We are planning to have both a web
client and a mobile client. In order to achieve this we will first create our web client and then port
it to mobile using PhoneGap. While PhoneGap is an effective way to make the product delivery
faster, it also has trouble converting web based animations to mobile animations.
9.5 Assumptions and Dependencies

The project will both be a web application and an android application. The technologies
to be used are Java, Spring Framework, ElasticSearch, RESTfull API and Maven in Server
side
HTML5, JS, CSS, Flash, RESTfull API and Maven in client side to implement the project.
Then, PhoneGap will be used to port our web client for mobile applications.
Testing will done using Selenium Framework for java and Selenium Web Driver for
automated testing.
The project will be open source. Github will be used both to make teamwork easier and
to match to the evolving software development trends.
19
The end product will be delivered in 13.07.2016 making the whole project lifecycle 3.5
months (not including maintenance).
Free trial cloud services will be used thus, it is assumed that the budget will be close to
non-existent or none at all.
Since NoSql is not optimal for relational data handling, MySQL will be used for storing user
related information. For other information handling, NoSql Will be used
Since PhoneGap will be used, the mobile application will not be native thus, complex
animations will not be used to make the front end performance effective.
9.6 Apportioning of Requirements

Implementation of the application in mobile platform (Android) shall be done in later releases.
For the first step, we will focus on building a web based client application.
10. Requirements
10.1 External Interface Interfaces
Google Cloud Platform will be used as web service provider. It provides the building blocks to
quickly develop everything from simple websites to complex applications. All MySQL and NoSql
queries and services will go through it
10.2 Functions
1. The software shall authenticate user login info upon entrance
2. The software shall take data (text, voice etc.) from the user and process it for a saving action
3. The software shall send data to be saved to the server as JSON object
4. The software shall take data (text, voice etc.) from the user and process it for an editing action
5. The software shall send data to be edited to the server as JSON object
6. The software shall only take a request and Note ID from the user and process it for a deleting
action
7. The software shall send delete request and Note ID to the server as JSON object
8. The software shall take data (text, voice etc.) from the user and process it for a sharing action
9. The software shall send share request and Note ID data to be shared to the server as JSON
object
10. The software shall give error feedback to the user in case of save, edit, delete or share error
occurs
11. The software shall give feedback to the user upon the success and fail of each operation
12. The server shall process any input JSON according to its operation type, data type and user
13. The software shall give reminder notifications if the reminder option is selected for any note
20
10.3 Usability Requirements
The interfaces shall be consistent throughout the application such as having same and clear image
buttons for all buttons. Tutorial for new users shall be offered to improve the learnability by
decreasing the time of learning. Feedback for user actions (such as deleting a note or adding a
note or error handling) shall be implemented to ensure a smoother usage of the application by
all users.
The application shall be designed with minimalistic design in mind to improve its attractiveness
and its chance to be used again by the users.
10.4 Performance requirements

The response time shall be less than 5 seconds to keep user focused.
Average response time shall be less than or equal to 1 for all user activities
The application shall consume no more than 5% CPU of a modern device (PC, smartphone etc.) to
ensure that the application runs even on the old devices
The application shall be scalable to handle the at least 1000 users at any given time and scale up
and down depending of the current number of users.
21
10.5 Logical Database Requirements
10.6 Software system attributes

Availability: application shall have an uptime of 99.9%
Verification: There shall be unit and integration tests using Selenium to test he code
Usability Requirement: Time of education shall be minimal. A person who can use any computer
can use the application. English shall be the language used for interface
Security: Default security configurations on server side shall be applied.
10.7 Other Requirements

Backups
Backup servers shall be established to take backups every week to make sure no data is lost. Also
data can be stored in the locale (users computer) if the user wants to achieve double redundancy.
22
Privacy and Security
Every user shall only access their own and the files sent to them by other users. There shall be no
public data that everyone can access. With this, the aim is to make sure the private information
of the users is kept save and secure
Scalability
A NoSql database shall be used to ensure the application to scale regardless of the number of
users. To ensure
Extensibility
The application shall be designed with future expansions in mind. It shall be designed modular
enough to allow future changes with minimal internal structural changes or optimally, none at all.
11. Verification
All requirements shall be subjected to unit and integration testing to qualify the software. In addition to
that, performance and system requirements shall be tested with a prototype of the application.
23
12. Use Case
24
12.1 Use Case descriptions and Sequence Diagrams
Use Case ID 1
Use Case Name Login
Actors NoteBucket User
Description User logs in to the NoteBucket to create and share his/her notes.
Preconditions User is defined in NoteBucket: user exists in the system with a valid
username and password.
Postconditions User is successfully logged in NoteBucket system.
Normal Flow 1. User requests to enter NoteBucket system.
2. System prompts user to log in.
3. User enters his/her username and password.
4. System verifies entered information.
5. System logs user into NoteBucket system.
Exceptions 3a. If the username and/or password entered by the user is/are
not valid:
1. NoteBucket system displays Invalid username and/or

password error message.
2. Use case resumes on Step 2 of Normal Flow.
25
Login Sequence Diagram
Use Case ID 2
Use Case Name Create Text Note
Description User creates a text note on the cloud environment.
Postconditions A text note is created on the cloud environment.
Normal Flow 1. User selects Text mode to generate a text note.

2. User generates a text note on the system.
3. User clicks Save button to save the note on the cloud.
Alternative Flow 3.a. User clicks Cancel button to cancel for creating a text note.
3.b. User clicks Exit button to leave application.
26
Crete text note Sequence Diagram
Use Case ID 4
Use Case Name Create Image Note
Description User creates an image note on the cloud environment.
Postconditions An image note is created on the cloud environment.
Normal Flow 1. User selects Image mode to generate an image note.

2. User generates an image note on the system.
Alternative Flow 3.a. User clicks Cancel button to cancel for creating an image
note.
27
Create Image note Sequence Diagram
Use Case ID 5
Use Case Name Add Reminder
Description User adds reminder to his/her note.
A note is already created.
Postconditions A reminder is added to the note.
Normal Flow 1. User selects Reminder option to add reminder to the current
note.
2. User selects the date that he/she will be reminded at that date.
3. User clicks Save button to add the reminder to the current
note.
Alternative Flow 3.a. User clicks Cancel button to cancel for adding reminder.
28
Add Reminder Sequence Diagram
Use Case ID 6
Use Case Name Edit Text Note
Description User edits the current note.
The note to be edited is selected.
Postconditions The selected text note is edited.
Normal Flow 1. User selects a text note to be edited.

2. User organize the selected note.
3. User clicks Save button to edit the selected note.
Alternative Flow 3.a. User clicks Cancel button to cancel for editing a text note.
29
Edit Note Sequence Diagram
Use Case ID 7
Use Case Name Remove Note
The note to be removed is selected.
Postconditions The selected text note is removed.
Normal Flow 1. User selects a text note to be removed.

2. User clicks Remove button to remove the selected note.
Alternative Flow 2.a. User clicks Exit button to leave application.
30
Remove Note Sequence Diagram
31
13. Class Diagram
32
14. Design Introduction
The document follows the IEEE STD 10162009, IEEE Standard for Information Technology Systems
Design Software Design Description.
The development and maintenance of NoteBucket are provided at this document. The design Viewpoints
are stated in detail at this document. This document is helpful for acquirers, project managers, quality
assurance staff, configuration managers, software designers, programmers, testers and maintainers. It is
important to meet unique requirements of these stakeholders.
This document consists of five semantic parts:

1. Definition of scope and purpose
2. Definition of terms used within development activities
3. Provides explanation for stakeholders to understand their responsibilities
4. Required content and organization of development activities
5. Provides design viewpoints
14.1 Purpose
This document is for acquirers, project managers, quality assurance staff, configuration managers,
software designers, programmers, testers and maintainers:
Acquirers use this document to check their design requirements are met.
Project manager uses this document to control the dynamics of development activities according
to the plans
Quality assurance staff use this document to check the development activities according to the
quality plans
Configuration manager use this document to check development activities for different
configurations
Software designers serve this document for stakeholders
Programmer use this document to implement the system
Testers use this document to prepare test plans and documents
Maintainers use this document to maintain system according to the changing needs after the
delivery of the system
33
14.2 Scope
This document is restricted according to IEEE Std 10162009, IEEE Standard for Information Technology
Systems Design Software Design Description. In this document the following design viewpoints are used
to describe the system:
UML Use Case Diagrams

UML Sequence Diagram
UML Class Diagram
UML Object Diagram
UML Component Diagram
UML Composite Structure Diagram
Whole structure of the design is explained by providing UML diagrams particularly. These diagrams are
prepared in detail to show the key aspects of design decisions.
14.3 Definitions
Definitions for the terms, acronyms and abbreviations are presented in this section.
Unified Modeling Language (UML): is a general-purpose modeling language in the field of

software engineering, which is designed to provide a standard way to visualize the design of a
system.
Star UML: is a UML tool by MKLab. The software was licensed under a modified version of GNU
GPL until 2014, when a rewritten version 2.0.0 was released for beta testing under a proprietary
license.
Java EE: is a widely used enterprise computing platform developed under the Java Community
Process. The platform provides an API and runtime environment for developing and running
enterprise software, including network and web services, and other largescale, multi-tiered,
scalable, reliable, and secure network applications. Java EE extends the Java Platform, Standard
Edition (Java SE),[1] providing an API for object relational mapping, distributed and multitier
architectures, and web services. The platform incorporates a design based largely on modular
components running on an application server.
Software for Java EE is primarily developed in the Java programming language. The platform
emphasizes convention over configuration [2] and annotations for configuration. Optionally XML
can be used to override annotations or to deviate from the platform defaults.
Spring Framework: is an application framework and inversion of control container for the Java
platform. The framework's core features can be used by any Java application, but there are
extensions for building web applications on top of the Java EE platform. Although the framework
34
does not impose any specific programming model, it has become popular in the Java community
as an alternative to, replacement for, or even addition to the Enterprise JavaBeans (EJB) model.
The Spring Framework is open source.
Cloud Computing: is a kind of Internet based computing that provides shared processing resources
and data to computers and other devices on demand. It is a model for enabling ubiquitous, on
demand access to a shared pool of configurable computing resources (e.g., networks, servers,
storage, applications and services),[1][2] which can be rapidly provisioned and released with
minimal management effort. Cloud computing and storage solutions provide users and enterprises
with various capabilities to store and process their data in third-party data centers.[3] It relies on
sharing of resources to achieve coherence and economy of scale, similar to a utility (like the
electricity grid) over a network.
MySQL: is an open source relational database management system (RDBMS).[6] In July 2013, it
was the world's second most[a] widely used RDBMS, and the most widely used open source client
server model RDBMS.[9] It is named after Michael Widenius' (who is a cofounder of MySQL)
daughter, My, [10] While "SQL" stands as the abbreviation for Structured Query Language. The
MySQL development project has made its source code available under the terms of the GNU
General Public License, as well as under a variety of proprietary agreements. MySQL was owned
and sponsored by a single for-profit firm, the Swedish company MySQL AB, now owned by Oracle
Corporation.[11] For proprietary use, several paid editions are available, and offer additional
functionality.
Google Cloud Datastore: Cloud Datastore is a highly-scalable NoSQL database for your
applications. Cloud Datastore automatically handles sharding and replication, providing you with
a highly available and durable database that scales automatically to handle your applications' load.
Cloud Datastore provides a myriad of capabilities such as ACID transactions, SQL-like queries,
indexes and much more.
14.4 Context
In this document, composition, logical, interface and interaction viewpoints are provided according to 1.1.
Purpose Section. The tools that used to display these viewpoints are listed at below:
Composition viewpoint is displayed with the UML component diagram.

Logical viewpoint is displayed with the UML class diagram.
Interface viewpoint is displayed with the UML class diagram.
Interaction viewpoint is displayed with the UML sequence diagram.
35
14.5 Summary
In section 1 introduction to SDD, design purpose, scope and context of the design are provided. Section 1
gives an introduction to the reader, section 1.1 expresses the responsibilities and duty of stakeholders,
section 1.2 provides the viewpoints for design, section 1.3 explains the terms and abbreviations and finally
section 1.4 gives an abstract understanding about the design according to the requirements.
15. References:
1. https://en.wikipedia.org/wiki/Unified_Modeling_Language
2. https://en.wikipedia.org/wiki/StarUML
3. https://en.wikipedia.org/wiki/Java_Platform,_Enterprise_Edition
4. https://en.wikipedia.org/wiki/Spring_Framework
5. https://en.wikipedia.org/wiki/Cloud_computing
6. https://en.wikipedia.org/wiki/MySQL
7. https://cloud.google.com/datastore
36
16. Design Viewpoints
16.1 Context Viewpoints
The Context viewpoint describes services provided by a design subject, relationships and dependencies in
the software development environment. The Context viewpoint is a way of representing the system as a
black box, users, stakeholders and their interaction are represented. Context diagram is shown below:
16.1.1 Use Cases

The UML Use case Diagrams below illustrates how a user interacts with the system
37
The detailed explanation of the user case's scenarios are provided from the following tables:
Use Case ID 1
Use Case Name Login
Description User logs in to the NoteBucket to create and share his/her notes.
Postconditions User is successfully logged in NoteBucket system.
Normal Flow 1. User requests to enter NoteBucket system.
2. System prompts user to log in.
3. User enters his/her username and password.
4. System verifies entered information.
5. System logs user into NoteBucket system.
Exceptions 3a. If the username and/or password entered by the user is/are
not valid:
1. NoteBucket system displays Invalid username and/or

password error message.
2. Use case resumes on Step 2 of Normal Flow.
38
Use Case ID 2
Use Case Name Create Text Note
Description User creates a text note on the cloud environment.
Postconditions A text note is created on the cloud environment.
Normal Flow 4. User selects Text mode to generate a text note.

5. User generates a text note on the system.
Alternative Flow 3.a. User clicks Cancel button to cancel for creating a text note.
39
Use Case ID 4
Use Case Name Create Image Note
Description User creates an image note on the cloud environment.
Postconditions An image note is created on the cloud environment.
Normal Flow 4. User selects Image mode to generate an image note.

5. User generates an image note on the system.
Alternative Flow 3.a. User clicks Cancel button to cancel for creating an image
note.
40
Use Case ID 5
Use Case Name Add Reminder
Description User adds reminder to his/her note.
A note is already created.
Postconditions A reminder is added to the note.
Normal Flow 4. User selects Reminder option to add reminder to the current
note.
5. User selects the date that he/she will be reminded at that date.
6. User clicks Save button to add the reminder to the current
note.
Alternative Flow 3.a. User clicks Cancel button to cancel for adding reminder.
41
Use Case ID 6
Use Case Name Edit Text Note
The note to be edited is selected.
Postconditions The selected text note is edited.
Normal Flow 4. User selects a text note to be edited.

5. User organize the selected note.
6. User clicks Save button to edit the selected note.
Alternative Flow 3.a. User clicks Cancel button to cancel for editing a text note.
42
Use Case ID 7
Use Case Name Remove Note
The note to be removed is selected.
Postconditions The selected text note is removed.
Normal Flow 3. User selects a text note to be removed.

4. User clicks Remove button to remove the selected note.
Alternative Flow 2.a. User clicks Exit button to leave application.
43
16.2 Composition Viewpoint
For this Viewpoint, we chose to use UML Component Diagram. The diagram below allows us to view the
bigger picture of the system by reducing complexity and giving us a more abstract view of the system. A
note for the reader; the Note Ops lollipop interface denotes multiple different operations the user can
perform on the notes
44
16.3 Logical Viewpoint
The relationship between the server-side system classes are shown in this viewpoint to elaborate designed
types and their implementations. This relationship is shown as a UML Class Diagram below.
As can be seen from the class diagram above, server side classes are separated into two main packages
called Account and Note. Account represents the user accounts and Note represents all types of Note
entities that will be created through the system's lifetime.
45
HomeController:
The main controller of the server side is the HomeController class that is aggregated with the
AccountController. Home controller has a constructor and an index method for directing service URLs to
appropriate classes.
AccountController:
AccountController is the class for controlling user account requests. It has two methods, currentAccount
and account, the former returns the current user's Account object, the latter returns the Account of the
requested user.
Account:
The account class is the main representative of the users' accounts. It has all the needed account
properties of the user with their getters and setters. The Account class is associated with the
AccountController and AccountService classes.
AccountService:
This class will be used to serve the main account operations requested by the user. These operations are
currently limited with signing in and saving the account properties of the user, which are operated with
the methods named respectively.
AccountModel:
This class is the model that will be used with the database operations. The properties listed as username,
mail and password will also be used as relational database columns.
Note:
The Note class is the main representative class for note entities. With its basic properties for defining a
note entity, it also has a shareNote method for sharing a note with a specified user account. This class is
associated with the NoteService and NoteController classes which are described below.
NoteController:
This class is used as the controller class for sending and actually showing the note entity to the user.
NoteService:
The NoteService class is the main service provider for the requested note related tasks. Saving, editing and
deleting note objects are carried out with this service class.
NoteModel:
NoteModel is an abstract base class that will be used with the database operations. With its basic
properties for identifying a note, it also has a method called saveNote for saving the requested note in the
database. It has three children TextNoteModel, VoiceNoteModel and ImageNoteModel which will be
expanded later on.
46
16.4 Patterns Viewpoint
This viewpoint addresses design ideas (emergent concepts) as collaboration patterns involving abstracted
roles and connectors. In NoteBucket MVC architectural pattern.
Modelviewcontroller (MVC) is a software architectural pattern for implementing user interfaces. It

divides a given software application into three interconnected parts, so as to separate internal
representations of information from the ways that information is presented to or accepted from the user.
A Model View Controller pattern is made up of the following three parts:
Model - The lowest level of the pattern which is responsible for maintaining data.
View - This is responsible for displaying all or a portion of the data to the user.
Controller - Software Code that controls the interactions between the Model and View.
Model View Controller (MVC) Pattern
47
16.5 Interface Viewpoint
With this Viewpoint we aimed to provide a complete documentation of the internal and external interfaces
used in the system. The Diagram below is created using UML Component Diagram to give all stakeholders
that take part in the development and testing phases of the project
48
16.6 Interaction Viewpoint
Interaction between key parts of the system are shown in this viewpoint with sequence diagrams. The
sequence diagrams discussed below are linked to the Use Case descriptions analyzed in the Context
Viewpoints in section 3.1. Although the flow of interaction and the data passed between the class
representatives are self-explanatory, the steps in the diagrams are described thoroughly below.
Login Sequence Diagram:
1: When user wants to login to the system the login method of the: Display class is called.
1.1: A login request is sent to the: ServerConnector class.
1.2: A response is returned to: Display class.
2: A response is returned to the User object.
49
Create Text Note Sequence Diagram:
1: User object calls the createNote method of the: Display class.
1.1: A new Note object is created.
1.2: The note object is encoded as a JSON string.
2: The encoded JSON string is passed to: AESHelper for encryption.
3: The encodedNote is returned back to: JSONHelper class.
1.3: The encodedNote is returned back to the: Display class.
1.4: The: Display class sends the encodedNote object to the: ServerConnector class.
1.4.1: The: ServerConnector class sends the encodedNote object to the: Controller class located at the
server side.
1.4.2: A response is returned back to the: ServerConnector class.
1.5: A response is returned back to the: Display class.
50
Create Image Note Sequence Diagram:
1: User object calls the browseImages method of the: Display class.
1.1: A new image note object is created.
1.2: The image note object is encoded as a JSON string.
server side.
51
Add Reminder Sequence Diagram:
1: User selects the note from the list of notes by calling the selectNote method of the: Display class.
1.1: A new note reminder object is created.
1.2: The reminder object is encoded as a JSON string.
3: The encodedReminder is returned back to: JSONHelper class.
3.1: The encodedReminder is returned back to the: Display class.
1.3: The: Display class sends the encodedReminder object to the: ServerConnector class.
1.3.1: The: ServerConnector class sends the encodedReminder object to the: Controller class located
at the server side.
52
Edit Note Sequence Diagram:
1: User selects a note for editing from the list of notes by calling the editNote method of the: Display
class.
1.1: When editing completes, the note is sent to the: JSONHelper class for JSON string encoding.
server side.
53
Remove Note Sequence Diagram:
1: User selects a note for removal from the list of notes by calling the removeNote method of the
:Display class.
1.1: The information of the note to be removed is sent to the: JSONHelper class for JSON string
encoding.
server side.
54
17. Introduction
17.1 Scope
This document aims to describe the testing process plan of NoteBucket in detail. The processes detailed
in this document shall be used verbatim during testing phase.
17.2 References
ISO/IEC/IEEE 29119
NoteBucket Software Project Management Plan Document
NoteBucket Software Requirement Specification Document
NoteBucket Software Design Description Document
55
18. Plan Context
18.1 Project
Note-Bucket is a platform for users to keep their notes on the cloud and share them with other registered
users in the system. The user can take notes as text, voice and create reminder for specific events. The
purpose of this project is to help users to keep all their notes in a cloud based environment so that they
can access them from anywhere. The user can edit, delete, read existing notes and create new notes. If a
note has a reminder function set up beforehand, the system shall inform the user about it.
With this project, we aim to help people keep on top of their to-do more efficiently and organize their
daily/weekly etc. activities better.
Main use case diagram below is the basis for our testing of the software
56
The Context view of the NoteBucket is as fallows
57
The software modules of the system is as follows:
Cloud Module: the backend of the system. Runs on Google App Engine
Client Module: the frontend of the system. Implemented using HTML, CSS and JS
18.2 Test Items

The system functionalities shall be tested according to Use cases provided
58
19. Test Strategy
19.1 Test Sub-processes

Black-box testing shall be used to test the system. White box testing is not used because all testing
scenarios will be based on functional testing and not the inner workings of the system.
19.2 Test Deliverables

Documentation for test design, specification and plan will be provided. In addition to that, test completion
report will be included in the final report.
19.2 Test design Techniques

Test cases will be based on use case scenarios. Every test case can be traced to a use case (Feature sets)
described in Test Design Specification sub-clause described in this document.
19.3 Test Completion Criteria

Testing phase shall be considered as complete only when at least 9 out of 11 test cases succeeds.
Integration, usability and performance test will be conducted one after another.
59
20. Test Design Specification
1. Feature Set (FS1): User registration
Objective: To test register module.

Approach: Testing of user input validation and checking if user is already registered to
the system.
Priority: High
Traceability: [Use Case 1]
2. Feature Set (FS2): User login
Objective: To test user login to the system.

Approach: Testing of user credentials and the input validation.
Priority: Medium
3. Feature Set (FS3): Create text note
Objective: To test creating a text note.

Approach: Testing of creation a text note on the cloud environment.
Priority: High
4. Feature Set (FS3): Create voice note
Objective: To test creating a voice note.

Approach: Testing of creation a voice note on the cloud environment.
Priority: High
5. Feature Set (FS3): Create image note
Objective: To test creating an image note.

Approach: Testing of creation an image note on the cloud environment.
Priority: High
6. Feature Set (FS3): Edit text note
Objective: To test editing a text note.

Approach: Testing of editing a text note on the cloud environment.
Priority: Medium
60
7. Feature Set (FS3): Remove note
Objective: To test removing a note.

Approach: Testing of removing a note on the cloud environment.
Priority: Medium
8. Feature Set (FS3): Share note
Objective: To test sharing a note.

Approach: Testing of sharing a note on the cloud environment with other registered
users..
Priority: Medium
21. Test Case Specification
Test Case ID: 11

Priority: Medium
Purpose: To test if an existing user will try to register to the
system.
Preconditions: User must enter input fields in correct format.
Input: User credentials including; username, email,
password, name and surname.
Expected Result: If the system finds a match in database that the
user is already registered, a message will be
displayed Bu e-mail adresine ait bir hesap
bulunmaktadr. The user will be redirected to the
home page to login.
Test Case 1 1 test if an existing user will try to register to the system
Test Case ID: 12

Priority: High
Purpose: To test a successful user registration.
Preconditions: User must not be registered to the system and
enter valid input data.
Expected Result: User must successfully register to system. A
notification message Kayt tamamland. Ltfen
giri yapnz. displayed to the user and page
redirects to home page.
Test Case 1 2 test a successful user registration
61
Test Case ID: 13
Priority: Medium
Purpose: To test if user enters invalid input in registration
form.
Preconditions: User must not be registered to the system and
enter invalid input data.
Expected Result: The system shows valid input expression format
to user. User is not registered to the system until
input field filled in correctly.
Test Case 1 3 test if user enters invalid input in registration form
Test Case ID: 21

Priority: High
Purpose: To test a successful user login.
Preconditions: User enters the login credentials properly.
Input: Username and user password.
Expected Result: Users credentials matches database data and
input format. User name is shown on the right top
corner of the page with option Oturumu Kapat
[username]. User is redirected to the create note
page.
Test Case 2 1 Test a successful user login
Test Case ID: 22

Priority: Low
Purpose: To test an unsuccessful login condition.
Preconditions: User enters email address or password
incorrectly.
Input: Username and user password.
Expected Result: Entered user credentials dont match with the
information in database. Yanl ifre ya da
kullanc ad! message is shown to the user and
system redirects user to the login page.
Test Case 2 2 Test an unsuccessful login condition
62
Test Case ID: 31
Priority: High
Purpose: To test creating a text note.
Preconditions: User must be registered and logged in.
Input: Enter a text note and click Share button.
Expected Result: Entered text note is created on the cloud
environment.
Test Case 3 1 Test creating a text note.
Test Case ID: 41

Priority: High
Purpose: To test creating a voice note.
Input: Enter a voice note and click Share button.
Expected Result: Entered voice note is created on the cloud
environment.
Test Case 4 1 Test creating a voice note.
Test Case ID: 51

Priority: High
Purpose: To test creating an image note.
Input: Enter an image note and click Share button.
Expected Result: Entered image note is created on the cloud
environment.
Test Case 5 1 Test creating an image note.
Test Case ID: 61

Priority: Medium
Purpose: To test editing a text note.
Input: Select the text note which will be edited. Edit the
note and click Save button.
Expected Result: Selected text note is edited and saved on the
cloud environment.
Test Case 6 1 Test editing a text note.
63
Test Case ID: 71
Priority: Medium
Purpose: To test removing a note.
Input: Select the note which will be removed. Click
Remove button.
Expected Result: Selected text note is removed on the cloud
environment.
Test Case 7 1 Test removing a note.
Test Case ID: 81

Priority: Medium
Purpose: To test sharing a note.
Input: Select the note which will be shared with other
users. Click Share button.
Expected Result: Selected note is shared on the cloud
environment with other registered users.
Test Case 8 1 Test sharing a note.
22. Test Data Requirements
System is published to Google App Engine. Test data will include user and note information. Notes will be
populated by beta users and it will be used as test data. For generating note data, administrator of the
system will add notes to system to be tests by users.
23. Test Environment Requirements
Hardware
Windows machines will be used for the testing. Every team member (developer) is responsible for
setting the testing environment for their own PC.
Software
Every team member will have Intellij IDEA 2016 1.1 configured on their PCs and Git is used for
communication and revision control of the software. Additionally, Google Datastore and SQL server are
used for database management.
64
24. Test Completion Report
Testing performed:
i) Summary of testing performed
The test specification was produced; it included 11 test procedures.
Tests are conducted according to the test plan.
ii) Deviations from planned testing
Add Reminder feature set has been removed.
iii) Test completion evaluation
All functional test procedures are executed with failures in User registration (High severity) and minor
failures Editing Text Note.
65

SE560 Notebucket Final Report

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

SE560 Notebucket Final Report

Uploaded by

Copyright:

Available Formats

FINAL REPORT

Ozan Dlgerolu 2121101

Bar Dastn 2120210

Cansn Tartc 2061000

JUNE 13, 2016

Report Name Date Description State

PMP V1.0 29.02.2016 Project summary draft Released

PMP V1.02 11.06.2016 Project Management Plan Released

SRS V1.02 11.06.2016 Software Requirement Released

SDD V1.02 11.06.2016 Software Design Document Released

STD V1.02 11.06.2016 Software Test Document Released

No Name Abbreviation Date

1 Project Management PMP Week 3

2 Software Requirement SRS Week 5

3 Software Design SDD Week 10

4 Test Documents TD Week 13

5 End Product EP Week 17

Week 2 Project summary drafts to be submitted

Week 3 Software project management plans to be

Week 5 Software requirement specifications to be

Week 8 System demos (release-1).

Week 10 Design documents to be submitted (IEEE

Week 13 Test plans to be submitted. (IEEE 829,

Week 16 Project presentations and system demos

Week 17 Submission of final reports. The final report

Title Date Version

ISO/IEC/IEEE16326 System and Software Engineering, Software

Project Management Plan Draft

Git Github: Version Checking and Team Management Tool

METU Middle East Technical University

UML Unified Modelling Language

UML Unified Modelling Language

SRS Software Requirement Plan

SDD System Design Document

Baselines will be drawn are followings:

Approval of SRS document,

4.3 Methods, Tools and Techniques

HTML5, JS, CSS, Flash, PhoneGap in client side

NoSql and MySQL for database management system

Selenium Framework and Selenium Web Driver for testing

Github for team collaboration

Microsoft Project for project management tool

Star UML for UML modeling

4.4 Infrastructure Plan

4.5 Product Acceptance Plan

4.6 Project Organization

5.1.2 Staffing Plan

5.1.4 Project Staff Training Plan

5.2 Project Work Plans

5.2.2 Schedule Allocation

5.2.3 Resource Allocation

5.2.4 Budget Allocation

5.2.5 Procurement Plan

6. Project Assessment and Control

6.2 Scope Control Plan

6.4 Budget Control Plan

6.5 Quality Assurance Plan

6.7 Project Closeout Plan

Project Summary Draft

8. Supporting Process Plans

8.2 Decision Management

Priority Definition Impact

8.4 Configuration Management

8.5 Information Management