Escolar Documentos
Profissional Documentos
Cultura Documentos
REVISION PAGE
Overview
This report is for the software design description of the UTP CoQ Online Registration
Project. This report will explain in details about the process of design and the details of
design for the project.
Target Audience
Our target audience for this project is students of Universiti Teknologi PETRONAS and
the Block B Curriculum Unit.
19182
19025
19151
19149
19365
Signatures of Approval
14 November 2015
Dear Sir/Ms
It will a helpful for me, if you could assist them in their project.
Sincerely
Table of Contents
1 INTRODUCTION
1.1 Design Overview
1.2 Requirements Traceability Matrix
2 SYSTEM ARCHITECTURAL DESIGN
2.1 Chosen System Architecture
2.2 Discussion of Alternative Designs
2.3 System Interface Description
3 DETAILED DESCRIPTION OF COMPONENTS
3.n Component-n
4 USER INTERFACE DESIGN
4.1 Description of the User Interface
4.1.1 Screen Images
4.1.2 Objects and Actions
5 ADDITIONAL MATERIAL
Relevant IEEE
1. INTRODUCTION
1.1 Design Overview.
Online registration for CoQ unit is designed to meet the requirements of users which is
the students who taking the curriculum subjects and the administrator who control the
data and details of the CoQ units.
The design basically fulfilled both the user and administrator requirement such as user
friendly and easily to control the system.
SEARCH
GO
CO-Q Registration
Foundation Studies Programme
Undergraduate Studies Programme
Postgraduate Studies Programme
SESSIONS
Session 1
9pm-
SELECT
11pm
Monday
Gamelan room
Session
10 am-
2
SELECT
12pm
Tuesday
Gamelan room
SESSION IS FULL!
CHOOSE ANOTHER SESSION?
BACK
EXIT
9PM- 11PM
MONDAY
GAMELAN ROOM
BACK
PROCEED
YOU HAVE
SUCCESFULLY
REGISTERED
Design 2
UTP CoQ Online Registration
BACK
Login
HOME
Login
ID*
Course*
Year of Study
BACK
Co-Curriculum List
Seach
SUBMI
SPORTS
Badminton
Rugby
Football
Tennis
Swimming
Peer Group
Counseling
Recreation
&
Adventure
Student Voluntary
Activities
Gamelan 1
Gamelan II
Modern Music
I
Modern Music
II
o Session 2
9PM- 11PM
THURSDAY
BADMINTON HALL, UTP
SUBMIT
CONTINU
1.
NAME
Ali bin Abu
ID
12345
COURSE
Bis
DONE
YEAR
2nd
Gender
Male
Day
Tuesday
the system
will provide the user the page of Students CoQ Registration page. In this page, the
students need to fill some of their important details to be stored in the database such as
name, ID, course, and year of study. This information will be displayed in the table and
database as the reference of students, lecturer and CoQ Units.
After the student have filled the details and click the submit button, the system will
provide them the list of courses offered in that semester. The user only need to choose
their registered courses of CoQ by clicking the button that have their CoQ name on it.
After they click on the course such as badminton course, the session for the badminton
course will be display on the next page. The user only need to click on the radio button
from each session. For example, the user click on the radio button of session 1, and they
click on the continue button, the page will display the table of the list of students that
have been registered. Their name will be automatically filled in the table. After they click
the DONE button, the message of they already successfully registered for their session
will be appear. Besides that, the details of their chosen session also will be display on the
page.
The user will click the blue line which is Register your Co-Q Class Now
Online!
Second page (List of all CoQ Courses that are offered in that semester
The user will select any of the blue boxes based on their registered
courses
Third page ( The sessions from the chosen course)
ADMIN INTERFACE
First page (Login as admin)
still available or the session already full. If the session already full, the user need to
choose another session.
If the session is still available, the user can register for their session. The user need to fill
the details in the form such as name, id, course and the year of study. The user also need
to click for the radio button for each session and submit the details together with the
session that they have chosen.
After the user have submit the message of successfully registered will be displayed. It
means the registration from the students have been recorded. The student only can
register for each session only once because the system has been design with a unique
attribute of the ID. Once the student have entered their ID, their ID will be recorded and
if they cannot register again for another session. This will help the system from having
the redundancy of data for the database.
As for the admin, the admin can login to the system by login as the admin. The admin can
check the database of the system and they also can check the list of students from each
course. For the admin the list of courses will be display as Please choose Coq Course
that you want to view. If the admin click on the badminton course. The list of the students
registered for the Coq will be display. The admin can use this data as reference and they
can print the list of the students from the database.
The system have been set up the limit from each sessions. From each session, the limit
for registration is only 30 students per session. The limit can be change based on the
requirement from the lecturer. After the session have filled until 30 students, the system
will inform the user that the session already full and the user need to choose another
session.
First of all we will include the object model of online registration from
both user and admin.
WEBSITE
-link registration
for Coq course
session
USER
DATABASE
REGISTER
-name
-id
-course
-year
-details
saved in
database
-listed
the name
and
details in
table for
each
AVAILABILITY
DETAILS
-Sessions for each
courses
-Available Sessions
for chosen course
COQ COURSES
-submission of sessions
ADMIN
LOGIN AS
ADMIN
-username
-password
CHEC
DATABASE
-details saved in
database
-listed the name and
details in table for
each session
OPEN
CoQ COURSES
FP Function Point
FTC Federal Trade Commission (U.S.)
GUI Graphical User Interface
REFERENCES
Guru. 2015. How to create Requirement Traceability Matrix (RTM). Retrieved from
http://www.guru99.com/traceability-matrix.html
Khella,A. 2002 October. Objects-Action Interface model. akhella@cs.umd.edu. Retrieved
from https://www.cs.umd.edu/class/fall2002/cmsc838s/tichi/oai.html
REVISION PAGE
OVERVIEW
This document describe the plan and specifications to verify and validate the software
and results.
TARGET AUDIENCE
The students of University Technology Petronas and Co-Curriculum Registration Units.
PROJECT TEAM MEMBERS
1.
2.
3.
4.
5.
Revision History
Revision #
Revision
Date
Description of Change
Author
28/9/2005
First Draft
Massachusetts
Institute of
Technology
TABLE OF CONTENTS
No
1
2
3
4
5
6
Title
Introduction
System Overview
Objective
Scope
Test Approach
5.1 Black Box Testing &White Box
Testing
Test Plan
6.1Features to be tested
6.2Features not to be tested
6.3Testing Tools and Environment
Test Cases
7.1 Purpose
7.2Test Case Template
7.3Test Case UTP Co-Q Online
Registration
ADDITIONAL MATERIALS
APPENDIX A
8.1Manual Testing Questions &
Answer
8.2Plan Approval Process
8.3Test Results
8.4Test Incident Reports
8.5 Letter Template
8.6Acronym & Abbreviations in
Software Testing
8.7References
Page Number
1. INTRODUCTION
The project is about to create co-curriculum unit software to make it easier for
students and lecturer. The students can register the course online and no need to come to
Co-Curriculum block that far from the hostels. Therefore, the registration from cocurriculum unit will be systematic. The students can choose the course by the category
that are available in the semester. There will be sessions to be choose by the students and
they can choose to be in available sessions. There are only one ID that can be register
which means one ID for one student in one class. If the sessions are full, the system will
inform the students by pop-out at the page. After the students has successfully register the
course, they can logout or back to homepage of the page.
There are also UTP registration co-Q page for admins use. Admins can login the
system to see the list of the sessions. There will be easier to admins to categorize the list
of students in every course that are available. So this is basically the flow of the UTP
registration co-Q system.
2. SYSTEM OVERVIEW
The Co-Curriculum unit registration were using php, mysql, bootsrap, html, css and
xampp. The system qualification testing in each build of the system should be interpreted
to mean planning and performing tests of the current build of the system to ensure that
the system requirements to be implemented in the system. The steps that we use to test
software qualification are independence in system qualification testing.We fulfill the
requirements and put the details of the software in the system.The test cases is include in
the system. The detailed design or implementation of software in the system from
contributing the process. Secondly, testing on the target computer system. The system
qualification testing include testing on the target computer system or an alternative
system approved by the acquirer. Next, preparing for system qualification testing. It also
has the test preparations, test cases and test procedures to be used for system qualification
testing and the traceability between the test cases and the system requirements.
Therefore, dry run of system qualification testing.We also try running the system test
cases and procedure to ensure that the system is complete.There are also the screen shot
of the software and is ready for witnesses testing. Besides, performing system
qualification testing. This participation shall be in accordance with the system test cases
and procedures.Thus, we doing revision and retesting. We retesting the software and
updte the software development. The error of the system will be recover. Lastly, we
analyzing and recording system qualification test results.
3. OBJECTIVES
The test suite should provide coverage metrics and verify that each section is
working as intended. The test should verify that a section is ready to be deployed in the
field as soon as the test is completed.
4. SCOPE
Testing will be performed as a continuous process throughout the life cycle as the
product is in production. Due to the involved nature of testing, test planning will be a
continuous process that changes in scope alongside the products development. This test
plan template will be updated alongside the overall product and will reflect any changes
in scope, design, and time schedule. Test plans must be developed for each level of
product testing.
5. TEST APPROACH
The system is the initial qualification tets for the UTP Co-Curriculum unit to make it
easier for the Register units to determine the course that has been registered by the
students. It is because the register units were doing the registration manually so
sometimes there are duplication and missed of the data.
The software for the online registration system that we used are JAVA interface .It
allow a class to become more formal about the behavior it promises to provide. Interfaces
form a contract between the class and the outside world. This archive is a high-level
overview characterizing our testing procedure for the UTP Registration Co-Q unit. Its
goal is to convey venture wide quality benchmarks and strategies. This record will
address the diverse measures that will apply to the unit, coordination and framework
testing of the predetermined application. We will use testing criteria under the white box,
black box, and system testing paradigm. All through the testing procedure we will be
applying the test documentation particulars portrayed in the IEEE Standard 829-1983 for
Software Test Documentation.
Testing
Black Box
White Box
Equivalent
Partitioning
Bounding Value
Analysis
Loop Testing
Control Structure
Testing
Comparison Testing
Fuzz Testing
these should
Comparison testing
We want to run all versions in parallel with a real-time comparison of results, we
have to test under three possible combinations: Identical, Similar, and heterogeneous
combinations of hardware and software platforms. Such tests will bring out possible
associated problems like effect of platforms on software, effect of different
resolutions and size of screen on appearance, impact of varieties of browsers in web
applications, and so on. By doing these tests we can benchmark performance of
software and also, one can recommend suitable hardware and software platform for
the given software.
Fuzz Testing
Code
Technique
Effort
10 min
50%
25%
30 min
80%
50%
2 hr
80%
50%
2.5 hr
99%
100%
coverage
Defects found
dumb
Combination of white box +
dumb
Combination of black box +
smart
Combination of white box +
smart
6. TEST PLAN
6.1 Features To Be Tested
The following features are the major functional capabilities of the project that need to be
tested at all phases of the testing cycle.
USERS
1.) Login ID
2.) Choose course
3.) Choose sessions
4.) Put details of the students
5.) The Submit button is visible and active
6.) User creation
ADMINS
1)Login email and password
2)Choose course
3)Review the list
Hardware
The system requires a single standard desktop PC, as well as a basic smart
phone with a data plan. There are no restrictions on what these 2 items
need to be other than they can run the software in any capacity.
Software
This project has an android software requirement. The phone must have an
android operating system and the desktop will need an android emulator.
Risks and Assumptions
The only risk associated with this project will be in the 2 month time table
for completion. Any and all testing must be done before the project
delivery date is set.
7. TEST CASES
7.1 Purpose
This UTP online registration Test Case Document identifies all conditions to be
implemented within the Registration course tests. These conditions are mandatory for an
acceptable and successful implementation of the function, Registration.
Tested By:
Test Type
Test Case Number
Test Case Name
Test Case Description
Item(s) to be tested
1
2
Specifications
Expected
Input
Output/Result
Procedural Steps
1
2
3
4
5
6
7
Registration
Description
Module Name
Students
Status
Created
Test Information
Name
Ali
ID
19152
Test Cases
Input
Expected Value
Actual Result
Data
1
2.
Select
Select one of
Display message
Display message
the course
3.
Pass/
Rema
Fail
rks
Pass
pass
selected
Select the
session on the
selected
selected
View
availability of
class availability
the sessions
view
and view
Enter empty
Display error
value for
Name
message Name
Enter empty
Display error
value for ID
ID
message ID
Select option
Display selected
button for
programme
course programme
Display error
Pass
radio button
4.
5.
Pass
Pass
name
6.
7.
course
programme
8.
Enter empty
Pass
Pass
Year of study
message Year of
study
9.
Select the
gender on the
selected
selected
Select submit
button
session 1 or Submit
session 1 or
successful
2 are successful
Submit
button for
session is
available are
available are
choose
successful
successful
Expected value
Actual Value
Pass
radio button
10.
11.
Pass
Pass
Test Case
Input
Data
1.
2.
Enter empty
Display error
value for
address
email address
Enter empty
Display error
value for
password
3.
Login
Pass/
Rema
Fail
rks
Pass
Pass
password
Click Login box are
successful.The Login
are successful.The
Login button is
Pass
4.
Select one of
active
the course
5.
6.
Student list
Pass
selected
The name list are
View another
Entry box
previous page
back to previous
Pass
Pass
page
7.
Logout
Logout button is
active
Pass
8. APPENDIX A
8.1 Manual Testing Questions & Answers
1. What is basis for test case review?
The main basis for test case review is testing techniques oriented review,
requirements oriented review and defects oriented review.
Send him the problems software to the lecturer then ask him to wait. After the
lecturer see the siftware, explain the situation and ask some more time to fix the bug. If
the lecturer is not ready to give some more time then analyze the impact of bug and try to
find workarounds for the defect and mention these issues in the notes as known issues or
known bugs.
4. Give me examples for high priority and low severity defects?
Suppose in UTP Co-Q Online Registration there is one registration form for students.
In that form, the submit button cannot be click and submit but actually at the back end it
is happening properly with out any mistake means only missing of message. So, we can
consider this issues as high priority but low severity defects.
6. How you can decide the number of test cases is enough for testing the given
modules?
The developed test cases are covered all the functionality of the application we can
say the test cases are enough.
7.How does you perform regression testing, means what test cases u select for
regression?
Regression testing will be conducted after any bug fixed or any functionality
changed. During defect fixing procedure some part of coding may be changed or
functionality may be manipulated. In this case the old test cases will be updated or
completely are written.
8. If a very low defect (user interface) is detected by you and the developer not
compromising with the defect, what will you do?
1)Reproduce the defect
2)Capture the defect screenshots
3)Document the proper inputs that we are used to get the defect in the defect report
4)Send the defect report with the screenshots, procedure for defect reproduction.
Before that, we must check the computer hardware configuration that is same as
developer system configuration and check the system graphic drivers are properly
installed or not.
Milestone
Description
Proposal submitted and
Planned date
12nd June 2015
Approved
Approval of Prototype
M2
Approval of Software
M3
Requirement
Approval of Architectural
M4 & M5
M6
Design
Approval of Detailed Design
Completion of Coding
Acceptance Test Successful
Completion of Product and
report
Submission of Report and
M1
System
Requirement
Architectural
Design
Detailed Design
Transfer
Product
Project :
Code Number :
Date :
System under Test:
Software version:
Reported version:
Title:
Description:
Solution :
Modules Changed:
Comments:
Approved: _____________
Date: ___________
Dear Sir/Ms
It will a helpful for me, if you could assist them in their project.
Sincerely
BS British Standard
BONDING Bandwidth On Demand Interoperability Group
BR Business Requirement
BRS Business Requirement Specification.
BS7925-1 British Standard BS 7925-1 Vocabulary of terms in software testing
BVA Boundary Value Analysis
BITE Browser Integrated Test Environment
CA Configuration accounting
CASE Computer-Aided Software Engineering
CC Configuration control
CDR Critical design review
CE Critical error
CERT Computer Emergency Response Team
CHAP Challenge Handshake Authentication Protocol
CISP Cardholder information security program
CI Configuration item
CID Configuration identification
CM Configuration management
CMM Capability Maturity Model
CMMI Capability Maturity Model Integrated
CMP Configuration management plan
CMT Configuration Management Tool
PA Physical audit
PCA Performance and Coverage Analysis
PDR Preliminary design review
PERT Program Evaluation and Review technique Diagram
PIR Postimplementation review
PCRTS Problem and Change Request Tracking System
PIM Platform-Independent Model
PIPEDA Personal Information Protection and Electronic Documents Act
PIM Platform-independent model
POF Probability of Failure
POST Power- On Self - Test (Diagnostic Tests)
PSI Platform-Specific Implementation
PT Problem Ticket
PTR Problem trouble report
QA Quality Assurance
QC Quality Control
QMS Quality Management System
QoS Quality of Service
SA Structured Analysis
SADT Systems Analysis and Design Technique
SCA Static Code Analysis
SC Security Checklist
SCA Source Code Analyzer
SCR Software Change Request
SDK Software Development Kit
SC Standards committee
SDLC Software development life cycle
SDP Software development plan
SEI Software Engineering Institute
SG Standards group
SIR System Investigation Report
SLC Software life cycle
SQS Software quality system
SQSP Software quality system plan
SRR Software requirements review
SDD System and software design document
SMARTS Software Maintenance and Regression Test System
SSH Secure Shell
SOA Service-oriented architecture
STAF Software testing automation framework
Std standard (IEEE designation)
STEP Systematic Test and Evaluation Process
START Structured Testing and Requirements Tool
STL Software testing lifecycle
STR Software trouble report
STR System trouble report
SUT System Under Test
SETs Software engineers in test
VE Virtual environment
V&V Verification and validation
VNC Virtual network computing
XP eXtreme Programming
8.7 References
Massachusetts Institute of Technology (2005, November 28). Software Test Report.
Retrieved from http://www.slideshare.net/Softwarecentral/software-test-plan
?qid=215bbe5e-9b9a-42e0-8802-7aa6d614e6a7&v=qf1&b=&from_search=6
Sigma Five PTE LTD (2008, February 25). Online Movie Ticketing System . Test Case
Registration. Retrieved fromhttp://worldofindependent.50webs.com/
Registration%20Test%20Case%20v1%20Ap
proved.pdf
For