19 Jun Cyber Security Department

Cyber Security Department

Graduation Project (407422)

 

 

Project Title Here ….

 

Advisor: Dr. Ahmed Ali Otoom

Submitted By:

 

Student Name	Student ID
Name 1	Id1
Term:
Date:

 

 

 

 

 

23 | Page

 

Table of Contents

1. Introduction 5

2. Problem Statement 5

3. Background 5

4. Requirements and specification 5

4.1. User Groups 5

4.2. Functional Requirements 6

4.3. Non-Functional Requirements (NFRs) 7

5. System Design 10

5.1. Solution Concept 10

5.2. Proposed System Architecture 11

5.2.1 Alternative 1 11

5.2.2 Aternative 2 11

5.2.3 etc 11

5.2.4 Production and Staging Environments 13

5.3. Component Design 13

5.3.1 Hardware Components 13

5.3.2 Software Components 13

5.3.2.1 User Interface – Web client 13

5.3.2.2. Use Case Description 13

5.3.2.3. Back-End Database 14

4.4. Design Evaluation 15

6. Implementation 16

6.1 System Implemented Architecture 16

6.1.1. Tier Two – Application Server and Web-Server 16

6.1.1.1. The Web-Server 16

<<if needed>> 16

6.2 Access Levels 16

6.3 System Services or Functionalities 16

7. Testing, Analysis and Evaluation 17

7.1 Testing Methodology 17

7.2 System Analysis and Evaluation 17

7.3 Test Execution and Test Results 17

7.3.1 Integration Testing 17

7.3.2 Functional Testing 17

7.4 Examples on testing 18

7.4.1 Check password Strength 18

<< this might be an example of testing password strength>> 18

8. Issues, Engineering Tools and Standards 18

8.1. Issues 18

8.2. Engineering Tools and Standards 18

9. Teamwork 18

10. Conclusion 20

10.1. Conclusion 20

10.2. Future Work 20

Appendix A: Test Plan 21

Appendix B: Progress Report-Teamwork 22

Appendix C- Attachments and Source Code 24

References 25

 

19 | Page

 

List of Figures

Figure 5 Use-Case Diagram 12

Figure 7 High Level Implementation Architecture 15

Figure 14 Security Domains Access Levels 15

Figure 59 Password Complexity 17

 

List of Tables

 

Table 1 User Groups 5

Table 2 Non Functional Requirements 7

Table 3 System Use Case Description 12

Table 4 Comparing On-Cloud and On-Site Options 14

Table 7 Team responsiblites, Contributions, and expertise 18

 

1. Introduction

<<introduction>>

2. Problem Statement

 

<<problem>>

3. Background

 

<<literature review>>

4. Requirements and specification

4.1. User Groups

Table 1 lists the Users or groups of Users who will be interested in using the system

 

 

Table 1 User Groups

Ser

Name ( user or group of users)

Role

 

 

4.2. Functional Requirements

The functional requirements are features or functions that we are going to implement in the solution …

4.3. Non-Functional Requirements (NFRs)

 

The non-functional requirements define the quality and performance attributes of the solution

 

Table 2 Non Functional Requirements

NFR Type	Requirements	Implications on Design and/or operation
Example Availability	· The solution will be accessed by users during business hours and outside of business hours. · The system must be available up and running 24/7 * 365. In all cases, availability should be at least equal to 0.999 ·	Possible solution or workaround
Scalability	·	Possible solution or workaround ·

 

 

 

5. System Design

5.1. Solution Concept

 

<<example> The major solution concept for solution is having it built and deployed as a web-based application. etc

 

 

5.2. Proposed System Architecture

 

<< proposed architecture>>

5.2.1 Alternative 1

5.2.2 Aternative 2

5.2.3 etc

 

 

Which alternative your team has chosen and why? Performance, cost, simplicity , other factors

 

 

 

5.2.4 Production and Staging Environments

 

Example << explain if you need this staging environment or not >>

5.3. Component Design

 

The system will consists of << off-the-shelf hardware component>> <<custom components>> self developed << explain>>

5.3

5.3.1 Hardware Components

 

1.

2.

3.

4.

4.1.

4.2.

4.3.

4.3.1.

5.3.2 Software Components

5.3.2.1 User Interface – Web client

· Based on the system requirements listed in the previous sections, we present the system use case diagram as shown in Figure x

 

Figure 5 Use-Case Diagram

 

 

5.3.2.2. Use Case Description

For each of the identified use cases, we provide, in Table 3, a more detailed description. Use case description shows how users will interact with the solution. It describes, from a user’s point of view, the solution’s behavior as it responds to user requests.

 

Table 3 System Use Case Description

 

5.3.2.3. Back-End Database

Does the system use a back-end database, file system explain and provide the required data models

 

4.4. Design Evaluation

Table 4 shows a comparison between the On-Cloud Option and the On-Site Option

Where do you want to host your system << on-cloud vs on-site and why>>

 

Table 4 Comparing On-Cloud and On-Site Options

 

 

6. Implementation

In order to facilitate the understanding of the system that contains several major components, we start with high level architecture. The source code for this project is provided in Appendix C.

6.1 System Implemented Architecture

Figure 7 shows the major components of the system.

 

 

Figure 7 High Level Implementation Architecture

2

3

4

5

6

6.1

6.1.1

 

6.2 Access Levels

 

6.2

6.3

6.1.

The solution pays attention to security. The solution categories the users into << how many>> different categories.

<< explain >>.

 

Figure 14 Security Domains Access Levels

 

6.3 System Services or Functionalities

 

<<Provide snapshots and explain>>

 

7. Testing, Analysis and Evaluation

 

7.1 Testing Methodology

<< the following is an example of a testing methodology you can use your own>>

Our team has developed the test plan shown in Appendix A. We have built acceptance test scenarios for the system features that we have already identified in the project design phase. For each feature, we have provided the test description and expected outcome for all of the success and alternate scenarios. After we completed the development phase, the test plan is executed. We record and resolve each test outcome for each test case.

· Target System: <<your system>>

· Features and functions:

· Test approach: .

· Key process: if bugs are discovered we will

· Bookkeeping and Documentation: We are going to use .

· Test Schedule:

· Exit criteria: The test will be considered complete

7.2 System Analysis and Evaluation

<< how to test non-functional requirements>>

.

7.3 Test Execution and Test Results

The execution performed according to the already identified methodology and carried against the test plan.

<<provide details about results>>

7.3.1 Integration Testing

 

After modular testing, we moved to the integration testing.

<< explain how you performed integration testing>>

 

7.3.2 Functional Testing

<< provide examples on function testing>>

We identified the features of the system in the design document so we have went through each feature to make sure it is already satisfied by the delivered solution. The functional testing used manual exploratory testing in which we run each required scenario and evaluate the results.

 

7.4 Examples on testing

 

7.4.1 Check password Strength

<< this might be an example of testing password strength>>

The system is programmed to check for password strength. We have decided to have the password strength fair; that is being longer than 8 characters.

 

Figure 59 Password Complexity

8. Issues, Engineering Tools and Standards

8.1. Issues

<<We have faced several issues during the design and development of this project. We list three examples on these issues.>>

 

 

8.2. Engineering Tools and Standards

 

<<this is an example: Explain about your own tools and standards

In this project, we have used the open-standard technology and internet standard protocols and components>>

 

9. Teamwork

 

Without teamwork we would not be able to fulfill the requirements of this demanding project. Our team was able to work well together.

<<explain details>>

Appendix B. For each task listed in the appendix, we, we show owner, description, timespan, and status. Status will have the following values: in progress, completed, waiting for another task or delayed.

 

Table 7 shows the responsiblites, Contributions, and expertise of each of the team members.

 

Table 7 Team responsiblites, Contributions, and expertise

Student	Responsiblities	Contribution	Expertise
Student 1			·
Student 2			·
Student 3			·
Student 4			·

 

 

 

10. Conclusion

In this section, we list the conclusion and future work respectively.

10.1. Conclusion

 

We have reached the following conclusions

10.2. Future Work

We believe there are still rooms for future advancements of this proposed solution. We list few hints of what can be done differently in a similar project.

 

 

Appendix A: Test Plan

Solution Name	Team Leader:	Student 1
		Student 2
		Student 3
Test No. ID	Related Feature	Pre-conditions	Test Description (steps)	Expected Outcome	Test Outcome
1	Register	Not Applicable	1. user clicks on the “Register” button 2. user Fills valid data for all of: Id, name, email, phone number, and password. 3. user submit the form	System Database will create a record for the user with the entered data

 

20 | Page

 

 

Appendix B: Progress Report-Teamwork

 

Table 5 Progress Report

<< This is an example>> use your own>>

 

ID Task Name / Owner Timespan – Week # Status Mitigation Action Description 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 Risk Likelihood Impact Severity of the Risk if the based on Occurring Risk Impact occurs and likelihood

1.0

Project Plan

Team

X

X

X

Completed

5.1

ER Diagram

Project ERD is incomplete

Low

High

Moderate

Completed

Make Team review session Cross check with Proj. Requirements

5.2

Use Case Diagram

Use cases do not reflect actual requirements

Low

Moderate

Low

Completed

Review with someone that can represent stakeholders

 

 

22 | Page

 

 

8.3

Final Report

Team

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

Do not complete the report on time

Moderate

High

High

Completed

Team will reflect changes to the Final Report as we go. By the deadline Team should have the major parts of the final report already in place

 

 

Appendix C- Attachments and Source Code

In this appendix we list the source code of different pieces of the solution where applicable.

 

References

[1] M. A. Gottfried, “Chronic Absenteeism and Its Effects on Students’ Academic and Socioemotional Outcomes,” J. Educ. Students Placed Risk, vol. 19, no. 2, pp. 53–75, Apr. 2014, doi: 10.1080/10824669.2014.962696.

Cyber Security Department

Graduation Project (407422)

 

 

Project Title Here ….

 

Advisor: Dr. Ahmed Ali Otoom

Submitted By:

 

Student Name	Student ID
Name 1	Id1
Term:
Date:

 

 

 

 

 

23 | Page

 

Table of Contents

1. Introduction 5

 

2. Problem Statement 5

 

3. Background 5

 

4. Requirements and specification 5

 

4.1. User Groups 5

 

4.2. Functional Requirements 6

 

4.3. Non-Functional Requirements (NFRs) 7

 

5. System Design 10

 

5.1. Solution Concept 10

 

5.2. Proposed System Architecture 11

 

5.2.1 Alternative 1 11

 

5.2.2 Aternative 2 11

 

5.2.3 etc 11

 

5.2.4 Production and Staging Environments 13

 

5.3. Component Design 13

 

5.3.1 Hardware Components 13

 

5.3.2 Software Components 13

 

5.3.2.1 User Interface – Web client 13

 

5.3.2.2. Use Case Description 13

 

5.3.2.3. Back-End Database 14

 

4.4. Design Evaluation 15

 

6. Implementation 16

 

6.1 System Implemented Architecture 16

 

6.1.1. Tier Two – Application Server and Web-Server 16

 

6.1.1.1. The Web-Server 16

 

<<if needed>> 16

 

6.2 Access Levels 16

 

6.3 System Services or Functionalities 16

 

7. Testing, Analysis and Evaluation 17

 

7.1 Testing Methodology 17

 

7.2 System Analysis and Evaluation 17

 

7.3 Test Execution and Test Results 17

 

7.3.1 Integration Testing 17

 

7.3.2 Functional Testing 17

 

7.4 Examples on testing 18

 

7.4.1 Check password Strength 18

 

<< this might be an example of testing password strength>> 18

 

8. Issues, Engineering Tools and Standards 18

 

8.1. Issues 18

 

8.2. Engineering Tools and Standards 18

 

9. Teamwork 18

 

10. Conclusion 20

 

10.1. Conclusion 20

 

10.2. Future Work 20

 

Appendix A: Test Plan 21

 

Appendix B: Progress Report-Teamwork 22

 

Appendix C- Attachments and Source Code 24

 

References 25

 

19 | Page

 

List of Figures

Figure 5 Use-Case Diagram 12

 

Figure 7 High Level Implementation Architecture 15

 

Figure 14 Security Domains Access Levels 15

 

Figure 59 Password Complexity 17

 

List of Tables

 

Table 1 User Groups 5

 

Table 2 Non Functional Requirements 7

 

Table 3 System Use Case Description 12

 

Table 4 Comparing On-Cloud and On-Site Options 14

 

Table 7 Team responsiblites, Contributions, and expertise 18

 

1. Introduction

<<introduction>>

2. Problem Statement

 

<<problem>>

3. Background

 

<<literature review>>

4. Requirements and specification

4.1. User Groups

Table 1 lists the Users or groups of Users who will be interested in using the system

 

 

Table 1 User Groups

Ser

Name ( user or group of users)

Role

 

 

4.2. Functional Requirements

The functional requirements are features or functions that we are going to implement in the solution …

4.3. Non-Functional Requirements (NFRs)

 

The non-functional requirements define the quality and performance attributes of the solution

 

Table 2 Non Functional Requirements

NFR Type	Requirements	Implications on Design and/or operation
Example Availability	· The solution will be accessed by users during business hours and outside of business hours. · The system must be available up and running 24/7 * 365. In all cases, availability should be at least equal to 0.999 ·	Possible solution or workaround
Scalability	·	Possible solution or workaround ·

 

 

 

5. System Design

5.1. Solution Concept

 

<<example> The major solution concept for solution is having it built and deployed as a web-based application. etc

 

 

5.2. Proposed System Architecture

 

<< proposed architecture>>

5.2.1 Alternative 1

5.2.2 Aternative 2

5.2.3 etc

 

 

Which alternative your team has chosen and why? Performance, cost, simplicity , other factors

 

 

 

5.2.4 Production and Staging Environments

 

Example << explain if you need this staging environment or not >>

5.3. Component Design

 

The system will consists of << off-the-shelf hardware component>> <<custom components>> self developed << explain>>

5.3

5.3.1 Hardware Components

 

1.

2.

3.

4.

4.1.

4.2.

4.3.

4.3.1.

5.3.2 Software Components

5.3.2.1 User Interface – Web client

· Based on the system requirements listed in the previous sections, we present the system use case diagram as shown in Figure x

 

Figure 5 Use-Case Diagram

 

 

5.3.2.2. Use Case Description

For each of the identified use cases, we provide, in Table 3, a more detailed description. Use case description shows how users will interact with the solution. It describes, from a user’s point of view, the solution’s behavior as it responds to user requests.

 

Table 3 System Use Case Description

 

5.3.2.3. Back-End Database

Does the system use a back-end database, file system explain and provide the required data models

 

4.4. Design Evaluation

Table 4 shows a comparison between the On-Cloud Option and the On-Site Option

Where do you want to host your system << on-cloud vs on-site and why>>

 

Table 4 Comparing On-Cloud and On-Site Options

 

 

6. Implementation

In order to facilitate the understanding of the system that contains several major components, we start with high level architecture. The source code for this project is provided in Appendix C.

6.1 System Implemented Architecture

Figure 7 shows the major components of the system.

 

 

Figure 7 High Level Implementation Architecture

2

3

4

5

6

6.1

6.1.1

 

6.2 Access Levels

 

6.2

6.3

6.1.

The solution pays attention to security. The solution categories the users into << how many>> different categories.

<< explain >>.

 

Figure 14 Security Domains Access Levels

 

6.3 System Services or Functionalities

 

<<Provide snapshots and explain>>

 

7. Testing, Analysis and Evaluation

 

7.1 Testing Methodology

<< the following is an example of a testing methodology you can use your own>>

Our team has developed the test plan shown in Appendix A. We have built acceptance test scenarios for the system features that we have already identified in the project design phase. For each feature, we have provided the test description and expected outcome for all of the success and alternate scenarios. After we completed the development phase, the test plan is executed. We record and resolve each test outcome for each test case.

· Target System: <<your system>>

· Features and functions:

· Test approach: .

· Key process: if bugs are discovered we will

· Bookkeeping and Documentation: We are going to use .

· Test Schedule:

· Exit criteria: The test will be considered complete

7.2 System Analysis and Evaluation

<< how to test non-functional requirements>>

.

7.3 Test Execution and Test Results

The execution performed according to the already identified methodology and carried against the test plan.

<<provide details about results>>

7.3.1 Integration Testing

 

After modular testing, we moved to the integration testing.

<< explain how you performed integration testing>>

 

7.3.2 Functional Testing

<< provide examples on function testing>>

We identified the features of the system in the design document so we have went through each feature to make sure it is already satisfied by the delivered solution. The functional testing used manual exploratory testing in which we run each required scenario and evaluate the results.

 

7.4 Examples on testing

 

7.4.1 Check password Strength

<< this might be an example of testing password strength>>

The system is programmed to check for password strength. We have decided to have the password strength fair; that is being longer than 8 characters.

 

Figure 59 Password Complexity

8. Issues, Engineering Tools and Standards

8.1. Issues

<<We have faced several issues during the design and development of this project. We list three examples on these issues.>>

 

 

8.2. Engineering Tools and Standards

 

<<this is an example: Explain about your own tools and standards

In this project, we have used the open-standard technology and internet standard protocols and components>>

 

9. Teamwork

 

Without teamwork we would not be able to fulfill the requirements of this demanding project. Our team was able to work well together.

<<explain details>>

Appendix B. For each task listed in the appendix, we, we show owner, description, timespan, and status. Status will have the following values: in progress, completed, waiting for another task or delayed.

 

Table 7 shows the responsiblites, Contributions, and expertise of each of the team members.

 

Table 7 Team responsiblites, Contributions, and expertise

Student	Responsiblities	Contribution	Expertise
Student 1			·
Student 2			·
Student 3			·
Student 4			·

 

 

 

10. Conclusion

In this section, we list the conclusion and future work respectively.

10.1. Conclusion

 

We have reached the following conclusions

10.2. Future Work

We believe there are still rooms for future advancements of this proposed solution. We list few hints of what can be done differently in a similar project.

 

 

Appendix A: Test Plan

Solution Name	Team Leader:	Student 1
		Student 2
		Student 3
Test No. ID	Related Feature	Pre-conditions	Test Description (steps)	Expected Outcome	Test Outcome
1	Register	Not Applicable	1. user clicks on the “Register” button 2. user Fills valid data for all of: Id, name, email, phone number, and password. 3. user submit the form	System Database will create a record for the user with the entered data

 

20 | Page

 

 

Appendix B: Progress Report-Teamwork

 

Table 5 Progress Report

<< This is an example>> use your own>>

 

ID Task Name / Owner Timespan – Week # Status Mitigation Action Description 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 Risk Likelihood Impact Severity of the Risk if the based on Occurring Risk Impact occurs and likelihood

1.0

Project Plan

Team

X

X

X

Completed

5.1

ER Diagram

Project ERD is incomplete

Low

High

Moderate

Completed

Make Team review session Cross check with Proj. Requirements

5.2

Use Case Diagram

Use cases do not reflect actual requirements

Low

Moderate

Low

Completed

Review with someone that can represent stakeholders

 

 

22 | Page

 

 

8.3

Final Report

Team

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

Do not complete the report on time

Moderate

High

High

Completed

Team will reflect changes to the Final Report as we go. By the deadline Team should have the major parts of the final report already in place

 

 

Appendix C- Attachments and Source Code

In this appendix we list the source code of different pieces of the solution where applicable.

 

References

[1] M. A. Gottfried, “Chronic Absenteeism and Its Effects on Students’ Academic and Socioemotional Outcomes,” J. Educ. Students Placed Risk, vol. 19, no. 2, pp. 53–75, Apr. 2014, doi: 10.1080/10824669.2014.962696.

24 | Page

24 | PageCyber Security Department

 

Graduation Project (407422)

 

Project Title Here ….

 

Advisor: Dr. Ahmed Ali Otoom

 

Submitted By:

 

Student Name

 

Student ID

 

Name 1

 

Id1

 

Term:

 

Date:

 

23 | Page

 

Table of Contents

 

1. Introduction 5

 

2. Problem Statement 5

 

3. Background 5

 

4. Requirements and specification 5

 

4.1. User Groups 5

 

4.2. Functional Requirements 6

 

4.3. Non-Functional Requirements (NFRs) 7

 

5. System Design 10

 

5.1. Solution Concept 10

 

5.2. Proposed System Architecture 11

 

5.2.1 Alternative 1 11

 

5.2.2 Aternative 2 11

 

5.2.3 etc 11

 

5.2.4 Production and Staging Environments 13

 

5.3. Component Design 13

 

5.3.1 Hardware Components 13

 

5.3.2 Software Components 13

 

5.3.2.1 User Interface – Web client 13

 

5.3.2.2. Use Case Description 13

 

5.3.2.3. Back-End Database 14

 

4.4. Design Evaluation 15

 

6. Implementation 16

 

6.1 System Implemented Architecture 16

 

6.1.1. Tier Two – Application Server and Web-Server 16

 

6.1.1.1. The Web-Server 16

 

<<if needed>> 16

 

6.2 Access Levels 16

 

6.3 System Services or Functionalities 16

 

7. Testing, Analysis and Evaluation 17

 

7.1 Testing Methodology 17

 

7.2 System Analysis and Evaluation 17

 

7.3 Test Execution and Test Results 17

 

7.3.1 Integration Testing 17

 

7.3.2 Functional Testing 17

 

7.4 Examples on testing 18

 

7.4.1 Check password Strength 18

 

<< this might be an example of testing password strength>> 18

 

8. Issues, Engineering Tools and Standards 18

 

8.1. Issues 18

 

8.2. Engineering Tools and Standards 18

 

9. Teamwork 18

 

10. Conclusion 20

 

10.1. Conclusion 20

 

10.2. Future Work 20

 

Appendix A: Test Plan 21

 

Appendix B: Progress Report-Teamwork 22

 

Appendix C- Attachments and Source Code 24

 

References 25

 

19 | Page

 

List of Figures

 

Figure 5 Use-Case Diagram 12

 

Figure 7 High Level Implementation Architecture 15

 

Figure 14 Security Domains Access Levels 15

 

Figure 59 Password Complexity 17

 

List of Tables

 

Table 1 User Groups 5

 

Table 2 Non Functional Requirements 7

 

Table 3 System Use Case Description 12

 

Table 4 Comparing On-Cloud and On-Site Options 14

 

Table 7 Team responsiblites, Contributions, and expertise 18

 

1. Introduction

<<introduction>>

 

2. Problem Statement

<<problem>>

 

3. Background

<<literature review>>

 

4. Requirements and specification

4.1. User Groups

Table 1 lists the Users or groups of Users who will be interested in using the system

 

 

Table 1 User Groups

 

Ser

 

Name ( user or group of

 

users)

 

Role

 

4.2. Functional Requirements

The functional requirements are features or functions that we are going to implement in the solution …

 

 

4.3. Non-Functional Requirements (NFRs)

The non-functional requirements define the quality and performance attributes of the solution

 

 

Table 2 Non Functional Requirements

 

NFR Type

 

Requirements

 

Implications on Design

 

and/or operation

 

Example Availability

 

· The solution will be accessed by users during business hours and outside of business hours.

 

· The system must be available up and running 24/7 * 365. In all cases, availability should be at least equal to 0.999

 

·

 

Possible solution or workaround

 

Scalability

 

·

 

Possible solution or workaround

 

·

 

5. System Design

5.1. Solution Concept

<<example> The major solution concept for solution is having it built and deployed as a web-based application. etc

 

5.2. Proposed System Architecture

<< proposed architecture>>

 

5.2.1 Alternative 1

5.2.2 Aternative 2

5.2.3 etc

Which alternative your team has chosen and why? Performance, cost, simplicity , other factors

 

5.2.4 Production and Staging Environments

Example << explain if you need this staging environment or not >>

 

5.3. Component Design

The system will consists of << off-the-shelf hardware component>> <<custom components>> self developed << explain>>

 

5.3

 

5.3.1 Hardware Components

 

1.

 

2.

 

3.

 

4.

 

4.1.

 

4.2.

 

4.3.

 

4.3.1.

 

5.3.2 Software Components

5.3.2.1 User Interface – Web client

· Based on the system requirements listed in the previous sections, we present the system use case diagram as shown in Figure x

 

Figure 5 Use-Case Diagram

 

5.3.2.2. Use Case Description

For each of the identified use cases, we provide, in Table 3, a more detailed description. Use case description shows how users will interact with the solution. It describes, from a user’s point of view, the solution’s behavior as it responds to user requests.

 

 

Table 3 System Use Case Description

 

5.3.2.3. Back-End Database

Does the system use a back-end database, file system explain and provide the required data models

 

4.4. Design Evaluation

Table 4 shows a comparison between the On-Cloud Option and the On-Site Option

 

Where do you want to host your system << on-cloud vs on-site and why>>

 

Table 4 Comparing On-Cloud and On-Site Options

 

6. Implementation

In order to facilitate the understanding of the system that contains several major components, we start with high level architecture. The source code for this project is provided in Appendix C.

 

6.1 System Implemented Architecture

Figure 7 shows the major components of the system.

 

Figure 7 High Level Implementation Architecture

 

2

 

3

 

4

 

5

 

6

 

6.1

 

6.1.1

 

6.2 Access Levels

6.2

 

6.3

 

6.1.

 

The solution pays attention to security. The solution categories the users into << how many>> different categories.

 

<< explain >>.

 

Figure 14 Security Domains Access Levels

 

6.3 System Services or Functionalities

<<Provide snapshots and explain>>

 

7. Testing, Analysis and Evaluation

7.1 Testing Methodology

<< the following is an example of a testing methodology you can use your own>>

 

Our team has developed the test plan shown in Appendix A. We have built acceptance test scenarios for the system features that we have already identified in the project design phase. For each feature, we have provided the test description and expected outcome for all of the success and alternate scenarios. After we completed the development phase, the test plan is executed. We record and resolve each test outcome for each test case.

 

· Target System: <<your system>>

 

· Features and functions:

 

· Test approach: .

 

· Key process: if bugs are discovered we will

 

· Bookkeeping and Documentation: We are going to use .

 

· Test Schedule:

 

· Exit criteria: The test will be considered complete

 

7.2 System Analysis and Evaluation

<< how to test non-functional requirements>>

 

.

 

7.3 Test Execution and Test Results

The execution performed according to the already identified methodology and carried against the test plan.

 

<<provide details about results>>

 

7.3.1 Integration Testing

After modular testing, we moved to the integration testing.

 

<< explain how you performed integration testing>>

 

7.3.2 Functional Testing

<< provide examples on function testing>>

 

We identified the features of the system in the design document so we have went through each feature to make sure it is already satisfied by the delivered solution. The functional testing used manual exploratory testing in which we run each required scenario and evaluate the results.

 

7.4 Examples on testing

7.4.1 Check password Strength

<< this might be an example of testing password strength>>

The system is programmed to check for password strength. We have decided to have the password strength fair; that is being longer than 8 characters.

 

Figure 59 Password Complexity

 

8. Issues, Engineering Tools and Standards

8.1. Issues

<<We have faced several issues during the design and development of this project. We list three examples on these issues.>>

 

8.2. Engineering Tools and Standards

<<this is an example: Explain about your own tools and standards

 

In this project, we have used the open-standard technology and internet standard protocols and components>>

 

9. Teamwork

Without teamwork we would not be able to fulfill the requirements of this demanding project. Our team was able to work well together.

 

<<explain details>>

 

Appendix B. For each task listed in the appendix, we, we show owner, description, timespan, and status. Status will have the following values: in progress, completed, waiting for another task or delayed.

 

Table 7 shows the responsiblites, Contributions, and expertise of each of the team members.

 

Table 7 Team responsiblites, Contributions, and expertise

 

Student

 

Responsiblities

 

Contribution

 

Expertise

 

Student 1

 

·

 

Student 2

 

·

 

Student 3

 

·

 

Student 4

 

·

 

10. Conclusion

In this section, we list the conclusion and future work respectively.

 

10.1. Conclusion

We have reached the following conclusions

 

10.2. Future Work

We believe there are still rooms for future advancements of this proposed solution. We list few hints of what can be done differently in a similar project.

 

Appendix A: Test Plan

Solution Name

 

Team Leader:

 

Student 1

 

Student 2

 

Student 3

 

Test No. ID

 

Related Feature

 

Pre-conditions

 

Test Description (steps)

 

Expected Outcome

 

Test Outcome

 

1

 

Register

 

Not Applicable

 

1. user clicks on the “Register” button 2. user Fills valid data for all of: Id, name, email, phone number, and password. 3. user submit the form

 

System Database will create a record for the user with the entered data

 

 

 

20 | Page

 

Appendix B: Progress Report-Teamwork

Table 5 Progress Report

 

<< This is an example>> use your own>>

 

ID Task Name / Owner Timespan – Week # Status Mitigation Action

 

Description 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 Risk Likelihood Impact Severity

 

of the Risk if the based on Occurring Risk Impact

 

occurs and likelihood

 

1.0

 

Project Plan

 

Team

 

X

 

X

 

X

 

Completed

 

5.1

 

ER Diagram

 

Project ERD is incomplete

 

Low

 

High

 

Moderate

 

Completed

 

Make Team review session

 

Cross check with Proj. Requirements

 

5.2

 

Use Case Diagram

 

Use cases do not reflect

 

actual requirements

 

Low

 

Moderate

 

Low

 

Completed

 

Review with someone that can represent stakeholders

 

22 | Page

 

8.3

 

Final Report

 

Team

 

X

 

X

 

X

 

X

 

X

 

X

 

X

 

X

 

X

 

X

 

X

 

X

 

X

 

X

 

X

 

Do not complete the report on time

 

Moderate

 

High

 

High

 

Completed

 

Team will reflect changes to the Final Report as we go. By the deadline Team should have the major parts of the final report already

 

in place

 

Appendix C- Attachments and Source Code

In this appendix we list the source code of different pieces of the solution where applicable.

 

References

[1] M. A. Gottfried, “Chronic Absenteeism and Its Effects on Students’ Academic and Socioemotional Outcomes,” J. Educ. Students Placed Risk, vol. 19, no. 2, pp. 53–75, Apr. 2014, doi: 10.1080/10824669.2014.962696.

 

24 | Page