MyCourses A UML Docoment With Usecase and Class Diagrams

COMSATS Institute of Information Technology, Islamabad Campus
MyCourses-A Course Scheduling System

CIIT-Spring-392-002
Spring 2011
SOFTWARE ENGINEERING-II (CSC 392)
Certificate of Approval
It is certify that the semester project of BS (CS) MyCourses-A Course Scheduling System was analyzed and designed by the following mentioned group members using object-oriented techniques under the guidance of Miss Sarah Masood and supervision of Mr. Saif ur Rehman Khan that in their opinions; it is fully adequate, in quality for passing the Software Engineering-II (CSC 392) course of the degree of Bachelors of Science in Computer Sciences. 1. Miss Fareeha Amjad (SP09-BCS-014) 2. Miss Asma Kaleem (SP09-BCS-006)
________________________ (Supervisor)
__________________________ (Project Coordinator)
________________________ (Course Instructor)
Table of Contents
1. 2. 3. 4. Executive Summary ............................................................................................................................... 3 Vision Document ................................................................................................................................... 4 Software Requirement Specification .................................................................................................... 8 Software Project Plan: ........................................................................................................................ 16
4.1 Cost Estimation ..................................................................................................... 16 4.2 Software Schedule: ............................................................................................... 18

567891011Software Test Plan Document ............................................................................................................ 23 Software Acceptance Test Plan........................................................................................................... 28 Test Cases............................................................................................................................................ 36 Test Summary Report ......................................................................................................................... 53 Formal Specification............................................................................................................................ 74 Functional Category List With System Attributes ........................................................................... 80 Use Cases: ....................................................................................................................................... 84
Brief use-cases: ............................................................................................................. 84 Expanded Use-Cases: ................................................................................................... 85 Use Case Model: ........................................................................................................... 93
1213141516171819CRC Index Cards .............................................................................................................................. 94 Role Play Diagrams (RPD) .............................................................................................................. 109 System Glossary ............................................................................................................................ 139 Conceptual Model ......................................................................................................................... 140 System Operations ........................................................................................................................ 143 Operation Contracts...................................................................................................................... 145 System Sequence Diagrams: ......................................................................................................... 151 UML Diagrams ............................................................................................................................... 156
123456-
Class Diagram ..................................................................................................... 156 Component Diagram ........................................................................................... 157 Deployment Diagram .......................................................................................... 158 Package Diagram ................................................................................................ 159 Activity Diagram ................................................................................................ 160 Sequence Diagram .............................................................................................. 163
1|Page
20-
Appendixes .................................................................................................................................... 165
Glossary ...................................................................................................................... 165
2|Page
1.
Executive Summary
Course scheduling is a tedious and error-prone task when done manually or semi-manually. For this reason a program that can automatically produce course scheduling with given requirements and constraints is very important. The goal of this project is to develop a course scheduler, MyCourses. MyCourses will make it possible to enter data and requirements in a simple way using a web-based interface, calculate and propose a schedule, enable manual updates, and finally present the schedule for the selected courses. Since different people (students, lecturers, program planners, etc.) will use the program its user friendliness is crucial. An efficient automatic scheduling is also important, but even more important is a possibility to manually reschedule or pre-schedule some courses or course elements (like lectures, labs, etc.). The goal of this project is to develop a course scheduler. Every university each year is facing with the same problem: How to schedule a large number of courses in an optimal way while fulfilling a number of constraints, such as available lecture rooms, limited availability of lecturers, students selections of the courses, and similar. MyCourses makes it possible to enter data and requirements in a simple way using a web-based interface, calculate and propose a schedule, enable manual updates, and finally present the schedule (manually re-schedule or preschedule some courses) for the selected courses. The program should be implemented as a distributed web-based, application, and data should be stored in a database. My Courses will be implemented as an interactive program that enables entering data, calculates and proposes a scheduling for courses, makes it possible to manually update the proposed schedule, but keeping track of the consistent scheduling, and provides a presentation of scheduled courses. The document audience is administrator, manager, faculty and students. A program administrator, who is responsible for management of the programs as the university defines programs. A program manager, when enabled, can enter all details about the program such as If the course is new, then the program manager creates it first, and then creates a new instance of it. The main lecturer defines the details about the course instance he is assigned for.
3|Page
2.
Vision Document 1- Introduction:

This document sets out the high level vision for the Software Engineering II project. We have to create a web-based course scheduler which will propose a schedule, enable manual updates, and present the schedule for the selected courses.
2- Positioning:
2.1- Problem Statement
The problem of Every university faces the problem of course scheduling every semester. Course scheduling is a tedious and error-prone task when done manually or semimanually. This has lead to the following two specific problems: How to schedule a large number of courses in an optimal way. How to schedule the courses while fulfilling a large number of constraints; such as available lecture rooms, limited availability of lecturers, students selections of the courses, etc. A successful solution would be If we create a program with a web-based interface that enables entering data and constraints related to the course scheduling. The program calculates and proposes a scheduling for courses and makes it possible to manually update the proposed schedule, meanwhile keeping track of the consistent scheduling. The program must be user-friendly so that different users can use this program as manual re-scheduling or pre-scheduling of some courses is important.
The impact of which is
2.2 Position Statement:
4|Page
We will create a distributed web-based application, and data should be stored in a database. Since the program is aimed for universities, FLOSS (Free/Libre and Open Source Software) will be used.
3- Stakeholder and User Descriptions:

3.1 Stakeholder Summary:
Name
Designers
Nominations
Fareeha Amjad Asma Kaleem
Responsibilities
The designers are responsible for designing and maintaining the data format, liaising and working with the project coordinator to ensure that it meets their requirements. The coordinator is responsible to check the work done by the project members is alright or not. The manager checks the work flow and assigns tasks to the project members.
Project Coordinator
Sara Masood
Project Manager
Saif-ur-Rehman
3.2
User Summary:
Name
Program Administrator
Description
They are typically coordinators of a certain department or the HODs. They could also be people from the examination department.
Responsibilities
Stakeholder
He is responsible for management of The designers the programs at the university defined will act as programs. stakeholders
for users.
He identifies the program, its running period (starting and ending year).
these
He enters data about different resources: The available lecture rooms and laboratories in which the courses (or particular elements) will take place, and some other elements such as data 5|Page
about number of available places, or availability of the room is entered. Program Manager They are typically coordinators of a certain department or the HODs. They could also be people from the examination department. He will have the overall responsibility The designers for the will act as Program.
stakeholders for these users.
He can enter all details about the program. He defines the details about the course instance he is assigned for.
Main lecturer
Professors
The designers will act as stakeholders for these users.
Automatic scheduling process-users
They could be professors or coordinators or people from the examination department.
Several users can run a The designers (semi)automatic scheduling process will act as that provides a schedule stakeholders proposal for a course or a set of courses
for users.
these
Users that use They could be the program to professors or present data coordinators or HOD or people from the examination department.
Different users can use the program to The designers present data. For example: Availability will act as and utilization of the facilities; Schedule for of a particular course etc users.
stakeholders these
3.3
User Environment It is recommended that FLOSS tools are used in the project
3.4
Alternatives and Political Landscape
This project has been made by many developers and is commercially available as well. It is possible that an alternative or similar format is present in the market. This is a purely academic project and is not available for sale.
4- Product Overview:
6|Page
This is a web-based application. It will perform its main functions as well as the program will be configurable and flexible i.e. that it can be configured with different rules of scheduling (for example definition of semesters, periods of the course execution, and similar). At the same time it is important that the program is user-friendly and that it is easy to import/export data to other systems which the universities can have. The project includes requirements solicitation, requirements specification, design and the Implementation. The program will be implemented as a distributed web-based, application, and the data will be stored in a database. Since the program is aimed for universities, FLOSS (Free/Libre and Open Source Software) will be used.
5- Product Features:
1- User-friendly 2- Standards based 3- Free to use 4- Extensible 5- Able to perform all the required functionalities 6- Able to schedule effectively and efficiently
7|Page
3.
Software Requirement Specification
1. Introduction
The system MyCourses-A Course Scheduling System will provide a systematic way to schedule courses which is considered very tedious when done manually or semimanually. It is also subjected to many errors. Therefore, our system will ease its users for scheduling the courses for the semester. In the following pages the reader is likely to find further elaboration of the project, and how it will be carried out and what will be its feature characteristics and in which environment it would likely work. Purpose
The purpose of our system is to ease its user in the most error-prone and tedious of all tasks i.e. course scheduling by providing a user friendly interface and making the application web-based that enables entering data and constraints related to the course scheduling. The program calculates and proposes a scheduling for courses and makes it possible to manually update the proposed schedule, meanwhile keeping track of the consistent scheduling.
It will also enable the user to schedule some courses manually and also alert the user if an error is made. The feature application of this product is to tell the user right there and then when an error is made and also an added accessory is when it proposes a possible schedule.
Scope
Our software will be a web application built on the Java and MySQL platforms. The interface of the software will be clear and intuitive to even non-technical users. We intend to include a number of features that will make our software as useful as possible to users, including: A secure login and registration system which allows only authenticated users to access the product features. A robust search engine which can search all the registered courses including the objectives and course contents of the specific course. Allow the user to see the previous professor who was teaching this courses schedule. A simple administration interface for the manager to perform tasks including user management, updating system settings, and overall maintenance of the system. Integration with all the universitys departments. This will help in indicating error if a teacher from a certain department is not allocated 2 lectures at the same time Entering the available resources such as available lecture rooms, project labs, labs etc. The system must automatically schedule the courses that provide a schedule proposal for a course or a set of courses: the days and time and places should be scheduled. The scheduler is not necessarily an automatic solver- but it allows some manual predefinition of the schedule and manual changes after the proposal is created. And if during the manual scheduling any error occurs the scheduler must alert the user and also propose other options available. Finally the scheduler will be able to present the schedule. 8|Page
Definitions, Acronyms and Abbreviations

a. Automatic Scheduling: Scheduling done by the system itself b. Course: The subjects taught to the students. Courses are organized by the departments name. c. Interface: A view of a semester which is visible to a users eye. d. Manual Scheduling: Scheduling done manually by the user himself by drag and drop service provided by the system. e. Resources: The things needed to teach a course e.g. lecture rooms etc f. Scheduler: Something that is responsible for scheduling within the resources and requirements.
References 1. MyCourses-Course Scheduling System Score 2011 Student Contest on Software Engineering- http://score-contest.org/2011/Projects.php#crnkovic 2. M. Dikaiakos, G. Tsouloupas; The Crossgrid SRS Templatehttp://grid.ucy.ac.cy/gridbench/repository/CG2.3-D2.1-v1.0-UCY001-SRS.pdf 3. The IEEE SRS Templatehttp://ieeexplore.ieee.org/Xplore/login.jsp?url=http%3A%2F%2Fieeexplore.ieee.org %2Fiel4%2F5841%2F15571%2F00720574.pdf%3Ftp%3D%26isnumber%3D15571 %26arnumber%3D720574&authDecision=-203
Overview
"The requirement document contains the general information and functionality about MyCourses". The scope and boundaries of the project are mentioned in the SRS. The functionality it will perform and the non-functional requirements are also illustrated.
Rest of the document is divided into chapters to enhance better understanding. In chapter 2 the overall description is provided.
9|Page
The chapter 3 shows the Specific Requirements.
2.
Overall Description
2.1
Product Perspective
This product is original, self-contained project.
2.2
Product Functions
following
The system is designed to ease the user to schedule the courses. It will have the functions: - Easy log-in - User-friendly interface - Drop-down menu to select department - Automatic Scheduling - Manual Scheduling - Error alerts - Presentation of the schedule for different users - Secure
2.3
User Characteristics
The user must be a part of the COMSATS Institute of Information Technology. He/she could be a professor, a coordinator, a student etc.
2.4
Constraints
TBD
2.5
Assumptions and Dependencies

TBD
2.6
Apportioning of requirements
TBD
3. Specific Requirements
3.1 Performance Requirements: 10 | P a g e
The maximum staff connected at the same time will be 10. But it will be designed to be able to connect simultaneously up to 50 users at any time of the day. Interfaces will have an automated system that will allow a maximum response time of 5 seconds.
3.2
Usability Requirements: This product will be very simple and easy to use. The overall system would be easily used by people with basic computer systems training and with little understanding of English. The system should be designed in a way that makes it easy for user to remember the steps they should follow. Ideally, the system should be free of errors, but in case that the users do something wrong the errors messages should be indicated in plain English, in that way, it will be easier for users to understand what they are doing wrong when using the system
3.3
Security Requirements: This is a very safe system; we do not foresee any kind of risk for the people using it, neither to the property nor to the environment. All the staff will have access to the system, but only the Administrator will have rights to either add new users or delete the ones that are leaving. Employees (faculty) will be able to generate reports and update information and student will be able to access the information they are required.
The system will prevent its data from incorrect usage by use of form validations.
Any user who uses the system shall have a Login ID and Password. Any modification (insert, delete, and update) for the Database shall be synchronized and done only by the administrator. Administrators shall be able to view and modify all information.
3.4
Precision requirements: This product has been designed to be the most accurate possible, we should take into consideration that this is a very simple system with no calculation formulae involved.
3.5
Reliability Requirements: It is a very simple product, in which only input of information and generation of reports is involved, our aim is to deliver a very reliable product with minimal degree of failures, and therefore minimal maintenance is required.
3.6
Availability Requirement: The system will be available for use 24 hours per day, 365 days per year.
3.7
Robustness Requirements:
11 | P a g e
The system's ability to continue functioning under abnormal circumstances is great. The system will continue operating in local mode whenever it loses its link to the central server, but only during the time the system gets linked to the backup server that will be set up for this kind of circumstances. Also in case of disaster, there is a ring of staff who will be chosen to connect from their homes either using cable or broadband.
3.8
Scalability or Extensibility Requirements: Due to the nature of the system, the capacity of processing information is indefinite. We are fully aware that the list of visitor will increase, that it is why we are designing our database in MS SQL, which is a very powerful application to keep records.
3.9
Portability Requirements:
The system is web based with its target browser being internet Explorer; however, it would be expected to run across various web browsers. 3.10 Maintainability Requirements: Since this system is web based should be maintained by either via phone or email where technical assistance will be available. The level of support this system will require is very low. The help desk will be able to provide the necessary support. Also it will have some help tab in the main interface. Functions: Following functions must the software include: The system shall tell the user that the password is case-sensitive. The system shall not let a user use the unauthenticated processes. The system shall check a teachers workload and does not assign work more than that. Teachers name shall only be alphabets
3.11
44.1-
System Features:
User Authentication: 4.1.1- Description: For security reasons and data hiding; user authentication is highly prioritized.
12 | P a g e
4.1.2- Stimulus/ Response Sequence:
Actor Action System Response 1: The user shall be able to open the page of the website by entering the correct username and password. 2: The user is connected to the server.
4.1.3- Functional Requirements: FQEQ-1 The system shall be able to provide secure login to its users 4.2Listing all the courses of a department 4.2.1- Description: The user must be able to list all the courses of the chosen department. 4.2.2- Stimulus/ Response Sequence:
Actor Action System Response 1. The user shall be able to choose the department of his/her choice. 2. The page for the department should open. 3. The user; when clicks to list the courses: the courses of that department shall be listed. 4. The system displays the list of all the courses.
4.2.3- Functional Requirements: FQEQ-2 The system shall be able to list the courses offered by the department FQEQ-3 The system shall be able to search the department. FQEQ-4 4.3The system shall be able to provide description of the courses offered.
Edit the course content 4.3.1- Description: The user shall be able to edit the description of a selected course. 4.3.2- Stimulus/ Activity Sequence:
13 | P a g e
Actor Action System Response 1. The user shall be able to open the page to Add Information. 2. The system opens the required page asking for the name of the course and the course ID. 3. The user shall be able to select the ID . 4. The system displays the name of the course automatically. 5. The user shall be able to edit on the area he/she wants editing and clicks Ok when done entering all the desired information. 6. The system updates the information.
4.3.3- Functional Requirements: FQEQ-5 The system shall be able to edit the course content. FQEQ-6 The system shall be able to enable the view of the previous course content. FQEQ- 7 The system shall be able to save the new course content. FQEQ-8 4.4The system shall be able to search the courses
Generating the time-table: 4.4.1- Description: The user shall be able to generate a schedule. 4.4.2- Stimulus/Activity Sequence:
Actor Action System Response 1. The user shall be able to enter the semester for which he/she wants to schedule. 2. The system asks to enter the semester. 3. The user shall be able to enter all the courses for that semester. 4. The user shall be able to pick the teachers. 5. The system schedule. displays the probable
14 | P a g e
4.4.3- Functional Requirements: FQEQ-9 The system shall be able to schedule manually. FQEQ-10 The system shall be able to schedule automatically. FQEQ- 11 The system shall be able to view the schedule. FQEQ-12 The system shall be able to edit the schedule. FQEQ-13 The system shall be able to save the schedule.
15 | P a g e
4.
4.1
Software Project Plan:

Cost Estimation
The FEMSEC model helps us to find the final cost of the project. First we need to know the size of the project and the formula for finding the size is
=
Where
+4
) [kloc].
= 6000 kloc. = 2000 kloc. = 3 kloc.
( 6000 + 4 ( 3) + 2000).
= 8012 kloc. This the size.
Now as the final size is given we can find the ideal work load where productivity is 3000 loc/py. 1) Ideal load :
= = 12 = 32.0[PM].
2) Optimal labour allocation. Now we will find where r = 60 %
= = =
16 | P a g e
= 2 [P].
3) The shortest duration time.
( r.
r +
) )
= . 32.0 ( 0.6 . 2 o.6 + = 25.6 [M].
4) Expected work load .
= 2 25.6 = 51.2 [PM].
5) The final expected project cost.
=
Where
= 6000 py.
= 2 25.6
= 25600 [$].
This was the final cost of our project. Now we have to find Effort as it is a algorithm critical area so the reliability is HIGH PCAP = HIGH= 0.70 and we will use organic mode to calculate effort. EFFORT = EAF 3.2 EFFORT = 0.70 3.2 EFFORT = 7.92
17 | P a g e
4.2
Software Schedule:
Roles of different people:
Role
Project Manager On-site Coordinator Developer(s)
Count
1 1(50%time) 2
Names
Saif Ur Rehman Sara Masood Fareeha Amjad Asma Kaleem
Tester(s)
Fareeha Amjad Asma Kaleem
Schedule: Person Performing the task Duration Start Date (days) End Date
Phase
Requirement Collection
Vision Document SRS Cost Estimation Project Plan User Stories Asma Kaleem Fareeha Amjad Asma Kaleem Asma Kaleem Fareeha Amjad Fareeha Amjad Test Cases Asma Kaleem 4 5 14 14 14 14 2nd March, 2011 7th March, 2011 7th March, 2011 7th March, 2011 7th March, 2011 21st March, 2011 7th March, 2011 21st March, 2011 21st March, 2011 21st March, 2011 21st March, 2011 25th March, 2011
Software Design
Fareeha Amjad Z Spec Language Asma Kaleem 3 25th March, 2011 28th March, 2011
18 | P a g e
Fareeha Amjad OOA model Asma Kaleem Fareeha Amjad System Model Asma Kaleem Fareeha Amjad Use Case Diagram Asma Kaleem Fareeha Amjad Conceptual Model Asma Kaleem System Diagram Sequence Fareeha Amjad 7 Asma Kaleem Fareeha Amjad Class Diagram Asma Kaleem Fareeha Amjad Object Diagram Asma Kaleem Fareeha Amjad Component Diagram Asma Kaleem Deployment Diagram Composite Collaboration Diagram Fareeha Amjad 8 Asma Kaleem Fareeha Amjad 7 Asma Kaleem Fareeha Amjad Package Diagrams Asma Kaleem Fareeha Amjad Sequence Diagram Asma Kaleem State Diagram Machine Fareeha Amjad 4 Asma Kaleem 3 7 8 10 10 7 7 7 3
25th March, 2011
28th March, 2011
28th March, 2011
4th April, 2011
28th March, 2011
4th April, 2011
4th April, 2011
11th April, 2011
4th April, 2011
11th April, 2011
11th April, 2011
21st April, 2011
11th April, 2011
21st April, 2011
21st April, 2011
29th April, 2011
21st April, 2011
29th April, 2011
29th April, 2011
6th May, 2011
29th April, 2011
6th May, 2011
6th May, 2011
9th May, 2011
9th May, 2011
13th May, 2011
19 | P a g e
Interaction Diagrams
Fareeha Amjad 3 Asma Kaleem Fareeha Amjad
13th May, 2011
16th May, 2011
Development
Asma Kaleem
16th May, 2011
20th May, 2011
Quality Check
Software Assurance Quality Fareeha Amjad 3 Asma Kaleem 20th May, 2011 23rd May, 2011
Testing
Fareeha Amjad Software Testing Asma Kaleem Fareeha Amjad 4 23rd May, 2011 27th May, 2011
Deployment
Asma Kaleem
10
27th May, 2011
6th June, 2011
Project Plan Summary:
Requirement Collection (23 days) Design Development Quality Testing Deployment (52 days) (4 days) (3 days) (4 days) (10 days)
Gant Chart:
20 | P a g e
Mar 2011
Apr 2011 3/20 3/27 4/3 4/10 4/17 4/24 5/1
May 2011 5/8 5/15 5/22 5/29
ID 1 2 3 4 5 6 7 8 9
Task Name Vision Document SRS Cost Estimation Project Plan User Stories Test Cases Z Spec Language OOA model System Model
Start 3/2/2011 3/7/2011 3/7/2011 3/7/2011 3/7/2011 3/21/2011 3/25/2011 3/25/2011 3/28/2011 3/28/2011 4/4/2011 4/4/2011 4/11/2011 4/11/2011 4/21/2011 4/21/2011 4/29/2011 4/29/2011 5/6/2011 5/9/2011 5/13/2011 5/16/2011 5/20/2011 5/23/2011 5/27/2011
Finish 3/7/2011 3/21/2011 3/21/2011 3/21/2011 3/21/2011 3/25/2011 3/28/2011 3/28/2011 4/4/2011 4/4/2011 4/11/2011 4/11/2011 4/21/2011 4/21/2011 4/29/2011 4/29/2011 5/6/2011 5/6/2011 5/9/2011 5/13/2011 5/16/2011 5/20/2011 5/23/2011 5/30/2011 6/6/2011
Duration
2/27 3/6 3/13
.8w 2.2w 2.2w 2.2w 2.2w 1w .4w .4w 1.2w 1.2w 1.2w 1.2w 1.8w 1.8w 1.4w 1.4w 1.2w 1.2w .4w 1w .4w 1w .4w 1.2w 1.4w
10 Use Case Diagram 11 Conceptual Model 12 System Sequence Diagram 13 Class Diagram 14 Object Diagram 15 Component Diagram 16 Deployment Diagram 17 Composite Collaboration Diagram 18 Package Diagram 19 Sequence Diagram 20 State Machine Diagram 21 Interaction Diagram 22 Development 23 Software quality assurance 24 Software Testing 25 Deployment
The Work Break Down Structure:
21 | P a g e
AON Chart:
25th March
52 Design
16th May
25th March
16th May 20th May 3 Quality 20 May

th
23rd May
S T A R T
2nd March
23
25th March 25th March
23rd May
Requirements 2 March
nd
27th May
10 Desployment
6th June
27th May 16 May

th
6th June
4 Development
20 May 23rd May 27th May
th
F I N I S H
4 Testing
16th May
20th May
rd
23 May
27th May
22 | P a g e
5-
Software Test Plan Document 1- Test Plan Identifier: TP-1 2- References:

Project Plan SRS Software Process Model
3- Introduction:
This is the Master Test Plan for the project MyCourses-A Course Scheduling System. This plan will address all parts of the project. The primary focus of this plan is to ensure that all inputs provide the desired outputs. The project will have three levels of testing; Unit, System/Integration, and Acceptance. The details for each level are addressed in the approach section and will be further defined in the level specific plans. The estimated time line for this project is approximately 2 months. However any delays during the semester schedule of the university may have significant effects on the test plan. The acceptance testing is likely to be taken after each iteration.
4- Test Items(Functions):
We are going to check the functional and non functional requirements of the system.
5- Software Risk Issues:

The critical areas of the project are: Complex algorithm Software link to the university database Getting all the information regarding the subjects on the website Integrating previous and new information Managing time of every teacher Managing all students issues regarding the schedule Documentation The risks involved with the software are: Short Time Rules and Regulations of the university Multiple Clients Many users
23 | P a g e
6- Features to be Tested:
The following is the list of items that are to be focused on during testing of the application. The level of risk scale is :(H for high; M for medium and L for low): - All information regarding all courses; H - Entering the courses parameters; M - No redundant data; H - Documentation; H - Interface to the system; H - Having different views for different users; M - Security; H - Data integrity; H - Server availability; H
7- Features Not to be Tested:

The following is a list of the areas that will not be specifically addressed. All testing in these Areas will be indirect as a result of other testing efforts. - Network Security and dial-in access: The software is independent of this issue as it would not affect it in any way. - Changes in courses: The changes are the responsibility of the administration. - Slow network access: This depends on the type of connection the user is logged in on.
8- Approach:
8.1-Testing Levels: The testing for the MyCourses-A course scheduling system will consist of Unit, System/Integration (combined) and Acceptance test levels. It is hoped that there will be at least one full time independent test person for system/integration testing. However, with the time line established; most testing will be done by the development team. UNIT Testing will be done by the developer and will be approved by the project coordinator; Miss Sara Masood. Proof of unit testing (test case list, sample output, and defect information) will be provided by the programmers to the project coordinator before unit testing will be accepted and passed on to the project manager. SYSTEM/INTEGRATION Testing will be performed by the developers and with assistance from the project coordinator as required. No specific test tools are available for this project. Programs will enter into System/Integration test after all critical defects have been corrected.
24 | P a g e
ACCEPTANCE Testing will be performed by the actual end users and/or the project manager with the assistance of the developers. Programs will enter into Acceptance test after all critical and major defects have been corrected. Prior to final completion of acceptance testing all open critical and major defects MUST be corrected and verified by the project manager. 8.2- Meetings: The team will meet once every two weeks to evaluate progress to date and to identify error trends and problems as early as possible. The project coordinator will meet with development and the project manager once every two weeks as well. These two meetings will be scheduled on different weeks. Additional meetings can be called as required for emergency situations. 8.3- Measures and Matrices: The following information will be collected by the Development team during the Unit testing process. This information will be provided to the project manager at program turnover as well as be provided to the project coordinator on a biweekly basis. - Defects by module and severity. - Defect Origin (Requirement, Design, Code) - Time spent on defect resolution by defect, for Critical & Major only. All Minor defects can be totaled together. The following information will be collected by the development team during all testing phases. This information will be provided on a biweekly basis to the project manager and to the project coordinator. Defects by module and severity. Defect Origin (Requirement, Design, Code) Time spent on defect investigation by defect, for Critical & Major only. All Minor defects can be totaled together. Number of times a program submitted to test team as ready for test. Defects located at higher levels that should have been caught at lower levels of testing.
9- Item Pass/Fail Criteria:

Once the project is submitted to the project manager, after using the product if he is happy or satisfied with our work and effort then the project has passed otherwise it has failed.
10- Suspension Criteria and Resumption Requirements:

Whenever a major flaw is found; unless it is not corrected testing should be stopped there and then as it is of no use. If during testing more than half of the tests do not indicate any error and if there is a shortage of time then it is alright not to test the remaining test items.
25 | P a g e
11- Test Deliverables:

Acceptance test plan Test cases Test summary report
12- Remaining Test Tasks:

TASK Create Acceptance Test Plan Create Test Cases Create Summary Report Assigned To Fareeha Amjad Asma Kaleem, Fareeha Amjad Asma Kaleem Status
13- Environmental Needs:

Access to both the development and production systems is the required element to support the overall testing efforts at all levels within the project scope.
14- Staffing and Training Needs:

The system is user friendly and it does not need special training. However we are going to make a presentation highlighting the characteristics of our project.
15- Responsibilities:
Developer 1 (Fareeha Amjad) Acceptance Test Plan Test Cases Summary Report Acceptance Testing X X X X X Developer 2 (Asma Kaleem) Project Manager
Miss Fareeha Amjad will make Acceptance Test Plan and Test Cases. Miss Asma Kaleem will make Test Cases and Summary Report. The Project Manager will perform Acceptance Testing. The entire project team will participate in the review of the system and detail designs as well as review of any change requests that are generated by the user/manager or as a result of defects discovered during development and testing
26 | P a g e
16- Schedule:
Following are the testing activities to be performed: A- Review of Requirements document and initial creation of Inventory classes, subclasses and objectives. B- Development of Master test plan. C- Review of the System design document and will further definition the Inventory classes, sub-classes and objectives. D- Development of System/Integration and Acceptance test plans. E- Review of the Detail design document(s) F- Unit test time within the development process.
17- Planning Risks and Contingencies:

A- Limited Team Members: As there are only two people working in this project. There is a shortage of people. The entire burden is thus being put on two shoulders. B- Limited Time: There are roughly 2 months left to complete the project and there is so much to do.
18- Approvals:
Project Manager Project Coordinator
27 | P a g e
6-
Software Acceptance Test Plan
INTRODUCTION This document is the Acceptance Test Plan (ATP) for MyCourses-A Course Scheduling System. The acceptance test verifies that the system works as required and validates that the correct functionality has been delivered. The ATP establishes the acceptance test framework used by the team to plan, execute, and document acceptance testing. It describes the scope of the work performed and the approach taken to execute the tests created to validate that the system performs as required. The details of the ATP are developed according to the requirements specifications, and must show traceability back to those specifications. The system MyCourses-A Course Scheduling System will provide a systematic way to schedule courses which is considered very tedious when done manually or semi-manually. It is also subjected to many errors. Therefore, our system will ease its users for scheduling the courses for the semester. Our software will be a web application built on the Java and MySQL platforms. The interface of the software will be clear and intuitive to even non-technical users. We intend to include a number of features that will make our software as useful as possible to users, including: A secure login and registration system which allows only authenticated users to access the product features. A robust search engine which can search all the registered courses including the objectives and course contents of the specific course. Allow the user to see the previous professor who was teaching this courses schedule. A simple administration interface for the manager to perform tasks including user management, updating system settings, and overall maintenance of the system. Integration with all the universitys departments. This will help in indicating error if a teacher from a certain department is not allocated 2 lectures at the same time Entering the available resources such as available lecture rooms, project labs, labs etc. The system must automatically schedule the courses that provide a schedule proposal for a course or a set of courses: the days and time and places should be scheduled. The scheduler is not necessarily an automatic solver- but it allows some manual predefinition of the schedule and manual changes after the proposal is created. And if during the manual scheduling any error occurs the scheduler must alert the user and also propose other options available. Finally the scheduler will be able to present the schedule.
28 | P a g e
ACCEPTANCE TEST APPROACH The approach we will be using is both the black box testing and the white box testing. The black box testing approach will be used to check if the applications requirements and specifications are according to the customers needs. The white box testing will do the same accept for the fact that it will use the actual code required for the testing. ACCEPTANCE TEST PROCESS The following is the process we will adopt for Acceptance Testing: Establish Acceptance Test Framework The Acceptance Test Plan establishes the acceptance test framework used by the team to plan, execute, and document acceptance testing of system. Industry best practices for acceptance testing and data derived from the acceptance test teams interface with the software development processes form the basis for the AT framework. Plan Acceptance Test Activities A successful acceptance test effort requires plannning. The acceptance test team identifies the tasks that need to be accomplished, including milestones. The functional requirements are the primary drivers for identifying those tasks. The acceptance test schedule is the timeline of acceptance testing activities and deliverable due dates. For each acceptance testing effort, a test schedule is developed identifying the major test preparation, test execution, and test reporting activities, as well as providing interim checkpoints to measure the progress of acceptance testing. Mr. Saif Ur Rehman Khan and Miss Sarah Masood will monitor the acceptance test effort. Exhibit 1: Sample Acceptance Test Schedule Planned Completion Date
11th April 2011
Activity
Plan Acceptance Testing
Actual Completion Date
Deliverable/ Checkpoint
Preliminary Acceptance Test Schedule
Identify Test Materials Establish Acceptance Test Environment
11th April 2011 11th April 2011
Preliminary Acceptance Test Matrix Acceptance Test Environment Inventory Draft Acceptance Test Plan Matrix Completed Test Readiness Review Checklist 29 | P a g e
Conduct Acceptance Test Readiness Review
1st June 2011
Activity
Execute Tests Complete Acceptance Testing Document Acceptance Testing
Planned Completion Date

6th June 2011 7th June 2011 7th June 2011
Actual Completion Date
Deliverable/ Checkpoint
Acceptance Test Progress Acceptance Test Summary Report Final Acceptance Test Report
Develop Acceptance Test Cases In the following subsections, the process used to create acceptance test cases is described. Sources for Test Cases The acceptance tests are made from the requirements, user stories, existing documentation, interviews, and research. The team reviews the software documentation, other documentation, and existing software to identify software components and features. The acceptance test team also attends requirements and design meetings and interviews persons involved in the system analysis, development, test, and operations to identify gaps and clarify questions. Structure for Acceptance Test Comprehensive acceptance test materials are a critical component of a successful acceptance test program. The acceptance test team uses a requirements-driven, structured approach to identify acceptance test data. The test casses are grouped into: functional and system test casses. Functional are those test casses that are made via user stories and system test casses are those that are created to check that the systems non functional requirements work properly such as security etc. Test Procedures Development Test procedures provide the testers with precise steps that should be followed to execute a test. Test procedures are essentially the recipe used to perform the test. Test cases are identified and documented as progressively detailed modules. Then they are prioritized on the basis of user stories and then tests are performed as scheduled and documented. Testing Priority Assigning a test priority provides built in mitigation for schedule risks. Therefore, prior to the test effort, the most critical system features are identified and assigned a priority level. The most critical items are tested first, followed by progressively less critical items. This ensures the critical items are tested when insufficient test time is allocated for acceptance testing. This approach also provides immediate feedback on the critical system features early in the acceptance test so the developers can begin addressing serious defects immediately. Any test cases and system features that are not tested are documented and provided in the Acceptance Test Summary Report.
30 | P a g e
We are going to prioritize on the basis of user stroies. The priority given to those user stories will be given to their corresponding test casses. Test Tools We are not going to use any tool. We are going to test manually. Acceptance Test Materials As the acceptance test activities are performed, acceptance test plan materials are created and added to the acceptance test plan as appendices. Each test for a particular release has its own corresponding appendix, which is continously updated throughout the acceptance test. The test casses are documented in another file in detail. Develop Test Traceability Documentation Test traceability is used to verify that functional requirements are accounted for, and tested in the delivered software. It provides traceability between the requirements and the test materials. The acceptance test team develops the traceability from the baselined requirements documents for the software. Each test case is formed from the user stories provided to us at the start of the project. Set Up the Acceptance Testing Environment Environment Preparation In preparation for acceptance testing, the team identifies and addresses missing or incorrectly configured hardware and software components. Preparatory activities involve constructing the actual acceptance test environment and installing the hardware and software, including the software to be tested, in order to ensure the configuration is correct. Changes need to be closely managed and controlled. Prior to an installation or configuration, the team checks and go through the test plan document as well as the acceptance test plan document. Deviations from the planned activities are recorded and reported to the acceptance test team. The test team begins acceptance testing by conducting an initial series of ad hoc, diagnostic tests designed to exercise the acceptance test environment and verify that major system software capabilities are available and functioning. The team also checks the documentation. Hardware/Software Hardware requirements are a fully functional laptop or desktop computer. Software requirements include code, Java IDE etc. Conduct Acceptance Test Readiness Review (ATRR) The ATRR is a critical acceptance testing checkpoint. At this review, Miss Sarah Masood, and the developers jointly review the status of the System Test results and known problems, the
31 | P a g e
developed system and its associated documentation, the planned acceptance testing, the acceptance test environment, and the support environment to determine whether or not to begin acceptance testing. With the Acceptance Test Plan as the guiding document, components reviewed include, but are not limited to: Software components Database Environmental components Documentation Known problems and outstanding issues from the System Test
Inventory of the acceptance test environment If the status of one or more of the components is unsatisfactory, the parties identify corrective actions and schedule another ATRR. If the status is acceptable, then testing will proceed. Execute Tests Acceptance test execution is an iterative process that begins with the initial execution of the planned tests. If no defects are discovered, then the test procedure has passed. If defects are discovered, they are documented, corrected, and retested. Acceptance testing continues until all the acceptance tests are successfully executed. However, if the deadlines are near then team focuses on critical functionality. If test time expires before completion of the acceptance tests, this would be documented. Record Issues/Defects As the issues and defects are identified, they are recorded. For each defect it is documented, area of defect, who found it, where was it found etc is provided and a preliminary assessment of the severity. Retesting Corrected Software After the defect has been detected it is removed and again presented for testing. Accompanying the software correction, an inventory of changed components, and the defects corrected, evidence of unit and/or System Testing, and instructions for installing the correction are also provided and then the testing of these corrected components takes place. Acceptance Regression Testing After receipt of a software correction, the team performs regression testing to ensure the defect or issue has been resolved and previously working software is not impacted. Document Acceptance Test Results At the end of the acceptance test, the acceptance test team produces two reports summarizing the results of the acceptance test. The Test Summary Report is a short report summarizing the test activities, and identifies outstanding deficiencies and issues. The Acceptance Test Final Report is the detailed record of the acceptance test activities. It records which tests were performed, the
32 | P a g e
pass/fail status of each test, and the discrepancies or issues found. In addition, the Acceptance Test Final Report identifies new tests added to the planned tests. Conduct Acceptance Test Status Meetings The acceptance testing will be done periodically to discuss the status of work. This will ensure any major issues or defects are identified in a timely manner so they can be resolved. Acceptance Test Deliverables The following is a list of deliverables produced during the acceptance test phase: Acceptance Test Plan Acceptance Test Summary Report Acceptance Test Final Report Support Client Acceptance The management department of COMSATS is the stakeholder who determines whether to accept or reject the delivered software. Acceptance testing exercises the software and provides data to be used in that decision. The management department of COMSATS will use the acceptance test results from the Acceptance Test Summary Report to determine whether the software, as-built, fulfills their mission requirements. If they determine that the software fulfills the requirements, the will accepts the software and the system is prepared for production. If they determine that the software does not fulfill its requirements, they will make a determination on further action. ACCEPTANCE TEST ENTRANCE / EXIT CRITERIA Acceptance Test Entrance Criteria The following must be completed: A. Acceptance Test Plan updated with the current tests B. Completed System Test Report C. Any open system issues. Acceptance Test Exit Criteria Acceptance Test Exit is based on the following criteria: A. Completion of the Acceptance Test Final Report, which provides the final status of acceptance test activities. REPORTS Interim Status Reporting Exhibit 2: Sample Interim Status Report
33 | P a g e
INTERIM TEST STATUS REPORT Tester Names:

Functional Areas Number of tests executed Subtotal of tests passed Subtotal of tests failed
Date:
Percent Failed Number of tests not tested
Functional Area 1
Functional Area 2
Issue/Defect Reporting Exhibit 3: Issue/Defect Report Sample ISSUE/DEFECT REPORT Tester Name: Area of Software Impacted: Nature of Issue/Defect: What occurred: How did it occur: When did it occur: Describe how to reproduce the error: SCR INFORMATION Assigned SCR Number: Severity: Status: Software Version: Preliminary Severity Assessment:
34 | P a g e
Acceptance Test Final Report Exhibit 5: Acceptance Test Final Report Sample ACCEPTANCE TEST FINAL REPORT System Name: Date:
General description of the acceptance test effort:
Unresolved Defects Issue/Defect Impact (H, M, L) Risk Mitigation (If known) Work Around (If known)
RISKS The following are typical, general overall acceptance test risks: 1. Insufficient test time Risk: If the amount of time available is too short, the team may not have enough time to complete acceptance testing or perform regression testing. Mitigation: Develop a critical path of tests, prioritized by importance.
35 | P a g e
7-
Test Cases
Test Case: Enter description of the course , T1 Description: This test case simulates one of the frequently performed actions is which the user enters the course requirements such as the allocation of books, reference books, the schedule of course etc. The user will search the course by course ID, and then modify/add the course description. Data Requirements: {username} username must be unique and valid {password} password must be valid {courseID} must be unique for every course Step Number Step Description Expected Result Transaction Name User Think Time
1)
Enter the websites URL and press enter. And log-in with {username} and {password}. Click the Add Information button
Main menu screen is displayed.
User_login
2)
Page opens asking for the course name and course ID. The name of the course automatically appears
Course_ identification Select_course
3)
Click the drop down menu of the course ID and choose the ID Click Ok
4)
Form appears containing the courses description (if already present) Confirms if it must be edited.
Description_ Course
5)
Click Edit on the area that needs to be edited; then click Ok
Edit_ Description
Test Case: Enter description of the course, T2 Description: This test case simulates one of the frequently performed actions is which the user enters the course requirements such as the allocation of books, reference books, the schedule of course etc. 36 | P a g e
The user will search the course by course ID, and then modify/add the course description. Data Requirements: {username} username must be unique and valid {password} password must be valid {courseID} must be unique for every course Step Number Step Description Expected Result Transaction Name User Think Time
1)
User_login
2)
3)
Click the drop down menu of the course ID and choose the ID Click Ok
4)
Form appears containing the courses description (if already present) Confirms if it must be canceled.(no change)
Description_ Course
5)
Click Edit on the area that needs to be edited; then click CANCEL.
Edit_ Description
Test Case: Enter description of the course, T3 Description: This test case simulates one of the frequently performed actions is which the user enters the course requirements such as the allocation of books, reference books, the schedule of course etc. The user will search the course by course ID, and then modify/add the course description. Data Requirements: {username} username must be unique and valid
37 | P a g e
{password} password must be valid {courseID} must be unique for every course Step Number Step Description Expected Result Transaction Name User Think Time
1)
User_login
2)
3)
Click the drop down menu of the course ID and choose the ID Click Cancel
4)
Return to main menu.
Back_to_Main
Test Case: Searching the course, T4 Description: The user will search the course by course ID. The user wants to search the course for various purposes. Data Requirements: {username} username must be unique and valid {password} password must be valid {courseID} must be unique for every course Step Number Step Description Expected Result Transaction Name User Think Time
1)
Enter the websites URL and press enter. And log-in with {username} and {password}. Enters the name or course ID
User_login
2)
Page opens for the
Course_
38 | P a g e
on the search bar
course.
identification
Test Case: Searching the course, T5 Description: The user will search the course by course ID. The user wants to search the course for various purposes. Data Requirements: {username} username must be unique and valid {password} password must be valid {courseID} must be unique for every course Step Number Step Description Expected Result Transaction Name User Think Time
1)
Enter the websites URL and press enter. And log-in with {username} and {password}. Enters the wrong name or course ID on the search bar
User_login
2)
Page opens informing the user to enter the correct course details.
Course_ identification
Test Case: Listing the courses offered by a certain department, T6 Description: The user enters the name of the department to list the courses offered by that department. Data Requirements: {username} username must be unique and valid {password} password must be valid {departmentName} must be unique name for each department Step Number Step Description Expected Result Transaction Name User Think Time
39 | P a g e
1)
Enter the websites URL and press enter. And log-in with {username} and {password}. Choose the department from the drop down menu Click the list of courses.
User_login
2)
Page of the chosen department opens. The list of courses offered by the department opens.
Department_ identification List_courses
3)
Test Case: View the course offered by a certain department, T7 Description: The user enters the name of the department to list the courses offered by that department. Data Requirements: {username} username must be unique and valid {password} password must be valid {departmentName} must be unique name for each department Step Number Step Description Expected Result Transaction Name User Think Time
1)
Enter the websites URL and press enter. And log-in with {username} and {password}. Choose the department from the drop down menu Click the list of courses.
User_login
2)
Page of the chosen department opens. The list of courses offered by the department opens. The course details open.
Department_ identification List_courses
3)
4)
Click on the course
Description_ Course
40 | P a g e
Test Case: Adding a new course, T8 Description: The user adds a new course. Data Requirements: {username} username must be unique and valid {password} password must be valid {courseID} must be unique for every course Step Number Step Description Expected Result Transaction Name User Think Time
1)
Enter the websites URL and press enter. And log-in with {username} and {password}. Choose the department from the drop down menu Click Add Course Enter the name, ID and the department it links to then add all the required information then click Ok.
User_login
2)
Page of the chosen department opens. Form appears Confirms the information.
Department_ identification New_course Add_ Course
3) 4)
Test Case: Adding a new course, T9 Description: The user adds a new course. Data Requirements: {username} username must be unique and valid {password} password must be valid {courseID} must be unique for every course Step Number Step Description Expected Result Transaction Name User Think
41 | P a g e
Time 1) Enter the websites URL and press enter. And log-in with {username} and {password}. Choose the department from the drop down menu Click Add Course Enter the name, ID and the department it links to then add all the required information then click Cancel. Main menu screen is displayed. User_login
2)
Page of the chosen department opens. Form appears Confirms it must be cancelled.(no course added)
Department_ identification New_course Add_ Course
3) 4)
Test Case: Auto-Scheduling, T10 Description: The user wants to schedule automatically; the system generates an automatic schedule. Data Requirements: {username} username must be unique and valid {password} password must be valid {courseID} must be unique for every course Step Number Step Description Expected Result Transaction Name User Think Time
1)
Enter the websites URL and press enter. And log-in with {username} and {password}. Click Auto Schedule
User_login
2)
Page opens that asks for the semester Page opens to choose teachers (if multiple teachers are available
Semester_ identification Assign_course
3)
Enter the semester and department along with the courses offered for that
42 | P a g e
semester 4) Click Schedule.
for a particular course) Conforms the schedule Auto_Schedule
Test Case: Auto-Scheduling, T11 Description: The user wants to schedule automatically; the system generates an automatic schedule. Data Requirements: {username} username must be unique and valid {password} password must be valid Step Number Step Description Expected Result Transaction Name User Think Time
1)
User_login
2)
Page opens that asks for the semester Page opens to choose teachers (if multiple teachers are available for a particular course) Conforms the schedule Returns to the previous page
Semester_ identification Assign_courses
3)
Enter the semester and department along with the courses(drop down menu) offered for that semester Click Schedule. Click Cancel
4) 5)
Auto_Schedule Assign_courses
Test Case: Auto-Scheduling, T12 Description: The user wants to schedule automatically; the system generates an automatic schedule. Data Requirements: {username} username must be unique and valid
43 | P a g e
{password} password must be valid Step Number Step Description Expected Result Transaction Name User Think Time
1)
User_login
2)
Page opens that asks for the semester Page opens to choose teachers (if multiple teachers are available for a particular course) Returns to main menu
3)
Enter the semester and department along with the courses(drop down menu) offered for that semester Click Cancel.
4)
Back_to_Main
Test Case: Manual-Scheduling, T13 Description: The user wants to schedule manually. Data Requirements: {username} username must be unique and valid {password} password must be valid Step Number Step Description Expected Result Transaction Name User Think Time
1)
Enter the websites URL and press enter. And log-in with {username} and {password}. Click Manual Schedule
User_login
2)
Page opens that asks for the semester Page opens to choose teachers (if multiple
3)
Enter the semester and department along with the
44 | P a g e
courses(drop down menu) offered for that semester 4) Drag the course and drop it in the table at the place you want it to be. Click Ok and repeat step 4 and 5, then click Done.
teachers are available for a particular course) Conforms the move Manual_Schedule
5)
Confirms the table
Assign_courses
Test Case: Manual-Scheduling, T14 Description: The user wants to schedule manually. Data Requirements: {username} username must be unique and valid {password} password must be valid Step Number Step Description Expected Result Transaction Name User Think Time
1)
User_login
2)
Page opens that asks for the semester Page opens to choose teachers (if multiple teachers are available for a particular course) Shows up a warning and does not save the move
3)
Enter the semester and department along with the courses(drop down menu) offered for that semester Drag the course and drop it in the table at the wrong place.
4)
Manual_Schedule
Test Case: Manual-Scheduling, T15
45 | P a g e
Description: The user wants to schedule manually. Data Requirements: {username} username must be unique and valid {password} password must be valid Step Number Step Description Expected Result Transaction Name User Think Time
1)
User_login
2)
Page opens that asks for the semester Page opens to choose teachers (if multiple teachers are available for a particular course) Shows up a warning and does not save the move
3)
Enter the semester and department along with the courses(drop down menu) offered for that semester Drag the course and drop it in the table at the place that creates a clash
4)
Manual_Schedule
Test Case: Edit Auto-Scheduling, T16 Description: The user wants to schedule automatically; the system generates an automatic schedule but edits it and schedule manually. Data Requirements: {username} username must be unique and valid {password} password must be valid Step Number Step Description Expected Result Transaction Name User Think Time
46 | P a g e
1)
User_login
2)
Page opens that asks for the semester Page opens to choose teachers (if multiple teachers are available for a particular course) Conforms the schedule Confirms the move.
3)
Enter the semester and department along with the courses offered for that semester Click Schedule. Click edit and move courses manually.
4) 5)
Auto_Schedule Edit_Schedule
1)
User_login
2)
Page opens that asks for the semester Page opens to choose teachers (if multiple teachers are available
3)
Enter the semester and department along with the courses offered for that
47 | P a g e
semester 4) 5) Click Schedule. Click edit and move courses at a wrong place.
for a particular course) Conforms the schedule Shows up a warning and does not save the move. Auto_Schedule Edit_Schedule
1)
User_login
2)
Page opens that asks for the semester Page opens to choose teachers (if multiple teachers are available for a particular course) Conforms the schedule Shows up a warning and does not save the move.
3)
Enter the semester and department along with the courses offered for that semester Click Schedule. Click edit and move courses at a place that creates a clash.
4) 5)
Auto_Schedule Edit_Schedule
48 | P a g e
Test Case: Presenting the Schedule, T19 Description: The user wants to present the generated schedule. Data Requirements: {username} username must be unique and valid {password} password must be valid Step Number Step Description Expected Result Transaction Name User Think Time
1)
Enter the websites URL and press enter. And log-in with {username} and {password}. Click Show Table
User_login
2)
Page opens that asks for the semester and department. Page opens that displays the schedule of that semester.
Semester_ identification Show_Schedule
3)
Enter the semester and department
Test Case: Presenting the Schedule, T20 Description: The user wants to present the generated schedule. Data Requirements: {username} username must be unique and valid {password} password must be valid Step Number Step Description Expected Result Transaction Name User Think Time
1)
Enter the websites URL and press enter. And log-in with {username} and {password}.
User_login
49 | P a g e
2)
Click Show Table
Page opens that asks to open your schedule Page opens that displays the schedule of the logged in teacher.
3)
Click your schedule.
Test Case: Saving the Schedule, T21 Description: The user wants to present the generated schedule and save it. Data Requirements: {username} username must be unique and valid {password} password must be valid Step Number Step Description Expected Result Transaction Name User Think Time
1)
User_login
2)
Page opens that asks to open your schedule Page opens that displays the schedule of the logged in teacher. Confirms it and asks for saving destination.
3)
Click your schedule.
4)
Click save
Save_Schedule
Test Case: Saving the Schedule, T22 Description: The user wants to present the generated schedule and save it.
50 | P a g e
Data Requirements: {username} username must be unique and valid {password} password must be valid Step Number Step Description Expected Result Transaction Name User Think Time
1)
User_login
2)
Page opens that asks for the semester and department. Page opens that displays the schedule of that semester. Confirms it and asks for saving destination.
3)
Enter the semester and department
5)
Click save
Save_Schedule
Test Case: Log-in, T23 Description: The user will log-in to his/her account to go to the main menu. Data Requirements: {username} username must be unique and valid {password} password must be valid Step Number Transaction Name User Think Time
Step Description
Expected Result
1)
Enter the websites URL and press enter Enter {username}
Page is displayed asking for {username} and {password} -
Enter_login
2)
Enter_username
51 | P a g e
3) 4)
Enter {password} Click Ok
Main Menu is displayed.
Enter_password User_login
Test Case: Log-in, T25 Description: The user will log-in to his/her account to go to the main menu. Data Requirements: {username} username must be unique and valid {password} password must be valid Step Number Transaction Name User Think Time
Step Description
Expected Result
1)
Enter the websites URL and press enter Enter wrong {username} Enter {password}
Page is displayed asking for {username} and {password} Display message Incorrect username or password
Enter_login
2) 3)
Enter_username Enter_password
4)
Click Ok
Incorrect_login
Test Case: Log-in, T26 Description: The user will log-in to his/her account to go to the main menu. Data Requirements:
52 | P a g e
{username} username must be unique and valid {password} password must be valid Step Number Transaction Name User Think Time
Step Description
Expected Result
1)
Enter the websites URL and press enter Enter {username} Enter wrong {password}
Page is displayed asking for {username} and {password} Display message Incorrect username or password
Enter_login
2) 3)
Enter_username Enter_password
4)
Click Ok
Incorrect_login
8-
Test Summary Report

GENERAL INFORMATION Unit Interface Performance Functionality Regression Integration Acceptance System Pilot
Test Stage:
Specify the testing stage for this Test Summary Report. Test Log Number: T1 Test Case Number: 01 Summary Review Date: 04/22/11
53 | P a g e
TEST SUMMARY Test Summary: Variances: Assessment: Summary of Results: Evaluation: Corrective Action Plan (CAP): APPROVALS <Signature>: <Signature>: . .
GENERAL INFORMATION Test Stage: Unit Interface Performance Functionality Regression Integration Acceptance System Pilot
TEST SUMMARY Test Summary: Variances: Assessment: Summary of 54 | P a g e
Results: Evaluation: Corrective Action Plan (CAP): APPROVALS <Signature>: <Signature>: . .
TEST SUMMARY Test Summary: Variances: Assessment: Summary of Results: Evaluation: Corrective Action Plan (CAP): APPROVALS .
55 | P a g e
<Signature>: <Signature>:
GENERAL INFORMATION Test Stage: Unit Functionality Integration System 56 | P a g e
Interface Performance
Regression
Acceptance
Pilot
57 | P a g e
59 | P a g e
Regression
Acceptance
Pilot
61 | P a g e
63 | P a g e
Regression
Acceptance
Pilot
65 | P a g e
67 | P a g e
Regression
Acceptance
Pilot
69 | P a g e
71 | P a g e
Regression
Acceptance
Pilot
73 | P a g e
9Formal Specification State Space Model:
The names of the sets are TEACHER, COURSE, ROOM, DESCRIPTION, PASSWORD, DEPARTMENT, STUDENT. known is the set of teachers. known2 is the set of courses, known3 is the set of course description, known4 is the set of rooms, known5 is the set of passwords, known6 is the set of department, and known7 is the set of students. inRoom is a function that maps courses with room, teach is a function that maps teacher with course, schedule is a function that maps course with teacher, cdesc is a function that maps course with its description, func is a function that maps teacher with password, dept is a function that maps course with department, func2 is a function that maps student with course, s_course is a function that maps student with course, s_dept is a function that maps student with department and c_student maps course with student. The part of the schema below the line is called the invariants, which are true in every case.
OPERATIONS:
1
This function states the initial state of the system. All sets are initialized to null. This is done to include empty set conditions.
74 | P a g e
______________________________________________________________________________ 2-
REPORT is a variable that consists of exactly two variables: Success and Failure. SuccessR is a function that reports Success and FailureR reports Failure. ______________________________________________________________________________ 3-
AddCourse is a function that adds a new course and its description in the database and reports success if done and failure if course is already present. It takes course name as input that should not belong to the set of courses and course description and outputs report to tell if its a Success or Failure. If the name of the input course exists then the course description is not added. ______________________________________________________________________________ 4-
Schedule_Teacher_with_Course is a function that takes teachers name and courses name as input and as a result saves it and reports success and failure accordingly. ______________________________________________________________________________ 5-
75 | P a g e
WhichRoom is a function that takes course name and room number as an input, if they both exists then that room is assigned to the course and reports success. ______________________________________________________________________________ 6-
FindCourseDesc is a function that takes courses name as input and gives its description as output and reports success if the course is present else reports failure. ______________________________________________________________________________ 7-
FindWhichRoom is a function that takes courses name as input and gives the room number assigned to it as output if courses name exists and reports success. ______________________________________________________________________________ 8-
In this schema we give teachers name as input and get the courses he/she teach as an output. If the teacher exists; success else failure is reported. ______________________________________________________________________________ 9-
76 | P a g e
In this schema we take courses name as input and get the teachers who teach those courses as an output. If the course name exists then success else failure is reported. ______________________________________________________________________________ 10-
In this schema; teachers name and password is taken as an input and if the two exists in the function: func; then success is reported else failure is reported. ______________________________________________________________________________ 11-
In this schema; students name and password is taken as an input and if the two exists in the function: func2; then success is reported else failure is reported. ______________________________________________________________________________ 12-
In this schema; departments name is taken as an input and the courses it offers is given as an output. If the departments name exists then success else failure is reported.
77 | P a g e
______________________________________________________________________________ 13-
This schema is user to edit description of a course or add the description of the course. It takes the courses name as an input if it exists then description is taken as an input and success is notified. Else if the courses name does not exist then failure is notified. ______________________________________________________________________________ 14-
AutoScheduling is a combination of Teacher_Teach_Which_Courses and FindWhichRoom schemas then success of these two schemas will be reported success of AutoScheduling else failure is reported. ______________________________________________________________________________ 15-
ManualScheduling is a combination of Teacher_Teach_Which_Courses and FindWhichRoom schemas then success of these two schemas will be reported success of ManualScheduling else failure is reported. ______________________________________________________________________________ 16-
Students name is taken a s input and if it exists then the list of courses he/she takes is given as an output and is reported success else failure. ______________________________________________________________________________ 17-
78 | P a g e
Courses name is taken as an input and if it exists then all the students who take the course are given as an output and is reported as success else failure. ______________________________________________________________________________ 18-
In this schema students name is taken as an input and the department he/she belongs to is given as an output and is reported success else failure. ______________________________________________________________________________
79 | P a g e
10- Functional Category List With System Attributes BASIC FUNCTIONS:

Ref# RQ.1 RQ.2 R2.1 R2.2 RQ.3 R3.1 R3.2 RQ.4 RQ.5 RQ.6 RQ.7 RQ.8 RQ.9 RQ.10 RQ.11 RQ.12 RQ.13 RQ.14 Function Login giving correct ID and password List the Courses List the courses using semester List the courses using department name Search a course Search a course using course name Search a course using a course ID Edit the details of the course Add a new course Schedule automatically Schedule manually Present the schedule Show the details of a course Edit auto- scheduling Save the schedule Delete Course Provide a persistent storage mechanism Detect errors Category Evident Evident Evident Evident Evident Evident Evident Evident Evident Evident Evident Evident Evident Evident Hidden Evident Hidden Hiddem
System Attributes:
Attribute Response Time Interface Metaphor Fault Tolerance Details and Boundary Constraints [Boundary Constraint]- The system should not take more than 10 sec for the calculations [Detail]forms-metaphor windows and dialog boxes [Detail] maximize for every keyboard navigation rather than pointer navigation [Boundary Constraint] the user can log-in at anytime of the day and any number of times
80 | P a g e
10Ref# RQ.1
System Attributes in Function Specification:

Function Login giving correct ID and password Cat. Evident Attributes Fault Tolerant Interface Metaphor Response Time Fault Tolerant Interface Metaphor Details and Constraints Must log in using username and password Form based Colorful System should be able to process the results timely The user should be logged in to use the functionality The courses must be chosen from the drop down menu System should be able to process the results timely The user should be logged in to use the functionality The courses must be chosen from the drop down menu as well as the semester System should be able to process the results timely The user should be logged in to use the functionality The courses must be chosen from the drop down menu as well as the department System should be able to process the results timely The user should be logged in to use the functionality System should be able to process the results timely Cat. Must
RQ.2
List the Courses
Evident
Must Want Must
Must
Must
R2.1
List the courses using semester
Evident
Response Time Fault Tolerant Interface Metaphor
Must
Must
Must
R2.2
List the courses using department name
Evident
Response Time Fault Tolerant Interface Metaphor
Must
Must
Must
RQ.3
Search a course
Evident
Response Time Fault Tolerant
Must
Must
R3.1
Search a course using course name
Evident
Response Time
Must
81 | P a g e
Fault Tolerant R3.2 Search a course using a course ID Evident Response Time Fault Tolerant RQ.4 Edit the details of the course Evident Fault Tolerant Interface Metaphor RQ.5 Add a new course Evident Fault Tolerant Response Time Fault Tolerant RQ.7 Schedule manually Evident Fault Tolerant Interface Metaphor
RQ.6
Schedule automatically
Evident
RQ.8
Present the schedule
Evident
Fault Tolerant Interface Metaphor Fault Tolerant Response Time
The user should be logged in to use the functionality System should be able to process the results timely The user should be logged in to use the functionality The user should be logged in to use the functionality The edit window should open up separately The user should be logged in to use the functionality System should be able to process the results timely The user should be logged in to use the functionality The user should be logged in to use the functionality The courses must be placed into the appropriate slots using drag and drop The user should be logged in to use the functionality Colorful The user should be logged in to use the functionality System should be able to process the results timely The user should be logged in to use the functionality The user should be logged in to use the
Must
Must
Must
Must
Must
Must
Must
Must
Must
Must
Must
Want Must
RQ.9
Show the details of a course
Evident
Must
RQ.10
Edit auto- scheduling
Evident
Fault Tolerant Fault Tolerant
Must
RQ.11
Save the schedule
Hidden
Must
82 | P a g e
Response Time RQ.12 Delete Course Evident Fault Tolerant Response Time RQ.13 Provide a persistent storage mechanism Detect Errors Hidden Fault Tolerant Fault Tolerant Response Time
RQ.14
Hidden
functionality System should be able to process the results timely The user should be logged in to use the functionality System should be able to process the results timely The user should be logged in to use the functionality The user should be logged in to use the functionality System should be able to process the results timely
Must
Must
Must
Must
Must
Must
83 | P a g e
11-
Use Cases:
Brief use-cases:
1- Login: The user opens the page of the website to enter the correct username and password. The system logs in the user to the server. 2- Listing the courses: The user chooses the department of his/her choice from a drop down menu. The system opens up the page of that department. The user clicks the List all Courses on the page. The system displays the list of all courses of that department. 3- Edit Course Content: The user clicks the button Add information. The system opens the required page asking for the name of the course and the course ID. The user selects the ID from the drop down menu. The system displays the name of the subject automatically. The user clicks ok. The system displays the form of the course having the previous data. The user clicks edit on the area he/she wants editing and clicks ok when finished. The system opens up a new window for the user to edit and it updates the information when ok is pressed by the user. 4- Adding a new Course: The user chooses the department of his/her choice from a drop down menu. The page for the department opens. The user clicks the add a course. The system displays a form. The user assigns the name and ID of the course. The system checks if the ID is not already in use. The user enters the information regarding the course and clicks Ok when done. The system updates. 5- Auto-Scheduling: The user clicks on automatic scheduling tab. The system asks to enter the semester. The user enters the semester for which he/she wants to schedule. The system asks to enter courses. The user enters all the courses for that semester. The system gives a list of teachers to choose from for the entire subjects if there are multiple teachers for a subject. The user picks the teachers. The system displays the probable schedule. 6- Manual-Scheduling: The user clicks on manual scheduling tab. The system asks to enter the semester. The user enters the semester for which he/she wants to schedule. The system asks to enter courses. The user enters all the courses for that semester. The system opens up the table and a drag and drop menu listing the subjects marked by the user. The user drags the subject and drops it in the table where he/she wants it to be. The system displays the schedule. The user clicks ok. The system updates.
84 | P a g e
7- View Schedule: The user clicks on Show Table. The system opens a drop down menu asking to present the time table of: semester, teacher or department. The user chooses one of the options. The system asks to enter semester or teachers id or departments name. The user enters the information. The system displays the schedule. 8- Deleting a course: The user writes the name of the course or course ID on the search bar and press enter. The system opens the page containing the information of that course. The user clicks on delete button. The system reconfirms. The user clicks ok. The course is deleted from the database. 9- Edit Auto-Scheduling: The user clicks on automatic scheduling tab. The system asks to enter the semester. The user enters the semester for which he/she wants to schedule. The system asks to enter courses. The user enters all the courses for that semester. The system gives a list of teachers to choose from for the entire subjects if there are multiple teachers for a subject. The user picks the teachers. The system displays the probable schedule. The user clicks edit. The system makes the subjects drag-able. The user drags the subjects/courses from its original place to the place he/she wants it to be. The user clicks ok when done. The system updates. 10- Saving Schedule: The user after scheduling clicks save. The system asks the location to save the schedule. The user browses the location and clicks ok. The system saves the file in .pdf format.
Expanded Use-Cases:
USE CASE NO USE CASE NAME PRIMARY ACTOR Purpose Overview Type Cross Reference 1 Login Any Authenticated User. Log-in a user to the system server. When any of the users wants to connect, he/she will provide his/her username and password. Primary and real Functions: RQ.1, RQ.14
NORMAL COURSE OF EVENTS
85 | P a g e
Actor Action Step 1: The user opens the page of the website to enter the correct username and password.
System Response
Step 2: The user is connected to the server.
ALTERNATE COURSE Step 1: The user is already connected to the server.
USE CASE NO USE CASE NAME PRIMARY ACTOR Purpose Overview Type Cross Reference
2 Listing the courses Any Authenticated User. For listing the courses. When any of the users wants to list all the courses of a certain department of his/her choice-the list is displayed. Primary and real RQ.2, RQ.14 System Response
NORMAL COURSE OF EVENTS Actor Action Step 1: The user chooses the department of his/her choice from a drop down menu.
Step 2: The page for the department opens.
Step 3: The user clicks the list of all courses on the page.
Step 4: The system displays the list of all the courses.
ALTERNATE COURSE Step 1: The user could also choose the department from home directly.
USE CASE NO
86 | P a g e
USE CASE NAME PRIMARY ACTOR Purpose Overview Type Cross Reference
Edit Course Content Any Authenticated User. To edit the content of the description of courses The user wants to enter the details of the course and the system updates the information. Primary and real Functions: RQ.4, RQ.13, RQ.14 System Response
NORMAL COURSE OF EVENTS Actor Action Step 1: The user clicks the button Add Information.
Step 2: The system opens the required page asking for the name of the course and the course ID. Step 4: The system displays the name of the course automatically. Step 6: The system displays the form of the course, having the previous data.
Step 3: The user selects the ID from the drop down menu.
Step 5: The user clicks OK.
Step 7: The user clicks edit on the area he/she Step 8: wants editing and clicks Ok when done The system updates the information. entering all the desired information. ALTERNATE COURSE Step 3: The user selects the name from the drop down menu and the system displays the course ID automatically.
USE CASE NO USE CASE NAME PRIMARY ACTOR Purpose Overview Type
4 Adding a new Course Any Authenticated User. To add new courses in the database. When any of the users wants to add a new course; the system generates a form and updates the information. Primary and real
87 | P a g e
Cross Reference
Functions: RQ.5, RQ.13, RQ.14 System Response
NORMAL COURSE OF EVENTS Actor Action Step 1: The user chooses the department of his/her choice from a drop down menu. Step 3: The user clicks the add a course Step 5: The user assigns the name and ID of the course. Step 7: The user enters the information regarding the course and clicks Ok when done.
Step 2: The page for the department opens.
Step 4: The system displays a form.
Step 6: The system checks if the ID is not already in use. Step 8: The system updates.
ALTERNATE COURSE Step 1: The user can click on the icon of the department directly if he/she is on the home page.
5 Auto-Scheduling Any Authenticated User. To schedule the time table automatically. When the user wants to schedule automatically; the system generates an automatic schedule. Primary and real Functions: RQ.6, RQ.13, RQ.14
NORMAL COURSE OF EVENTS Actor Action System Response Step 1: The user clicks on automatic scheduling tab. Step 2: The system asks to enter the semester. Step 3: The user enters the semester for which he/she wants to schedule. Step 4: The system asks to enter courses. Step 5:
88 | P a g e
The user enters all the courses for that semester.
Step 6: The system gives a list of teachers to choose from for the entire subjects if there are multiple teachers for a subject. Step 8: The system displays the probable schedule.
Step 7: The user picks the teachers.
ALTERNATE COURSE Step 1: The user clicks the automatic scheduling button if the user is on the home page.
6 Manual-Scheduling Any Authenticated User. To schedule the time table manually. When the user wants to schedule manually; the system generates saves the schedule. Primary and real Functions: RQ.7, RQ.13, RQ.14 System Response Step 2: The system asks to enter the semester.
NORMAL COURSE OF EVENTS Actor Action Step 1: The user clicks on manual scheduling tab. Step 3: The user enters the semester for which he/she wants to schedule. Step 5: The user enters all the courses for that semester. Step 7: The user drags the subject and drops it in the table where he/she wants it to be. Step 9: The user clicks ok. ALTERNATE COURSE Step 1:
Step 4: The system asks to enter courses. Step 6: The opens up the table and a drag and drop menu listing the subjects marked by the user.
Step 8: The system displays the schedule. Step 10: The system updates.
89 | P a g e
The user clicks the manual scheduling button if the user is on the home page.
7 View Schedule Any Authenticated User. To show the time table When the user wants to present the schedule; the system presents it. Primary and real Functions: RQ.8, RQ.14 System Response Step 2: The system asks to enter the semester. Step 4: The system displays the schedule.
NORMAL COURSE OF EVENTS Actor Action Step 1: The user clicks on Show Table. Step 3: The user enters the semester.
ALTERNATE COURSE Step 2: The semester chosen by the user isnt yet scheduled; the system displays the corresponding message informing the user.
8 Deleting a Course Any Authenticated User. To delete a specific course When the user wants delete a course already present in the database. Primary and real Functions: RQ.12, RQ.13, RQ.14 System Response
NORMAL COURSE OF EVENTS Actor Action Step 1: The user writes the name of the course or
90 | P a g e
course ID on the search bar and presses enter.
Step 2: The system opens the page containing the information of that course. Step 4: The system reconfirms. Step 6: The course is deleted from the database.
Step 3: The user clicks on delete button. Step 5: The user clicks ok.
ALTERNATE COURSE Step 2: The course chosen by the user isnt present in the database; the system displays the corresponding error message informing the user.
9 Edit Auto-Scheduling Any Authenticated User. To edit schedule the timetable that was generated automatically. When the user wants to schedule automatically; the system generates an automatic schedule. And the user wants to edit it. Primary and real Functions: RQ.10, RQ.13, RQ.14
NORMAL COURSE OF EVENTS Actor Action System Response Step 1: The user clicks on automatic scheduling tab. Step 2: The system asks to enter the semester. Step 3: The user enters the semester for which he/she wants to schedule. Step 4: The system asks to enter courses. Step 5: The user enters all the courses for that Step 6: semester. The system gives a list of teachers to choose from for the entire subjects if there are multiple teachers for a subject. Step 7: The user picks the teachers. Step 8: The system displays the probable schedule. Step 9:
91 | P a g e
The user clicks edit. Step 11: The user drags the subjects/courses from its original place to the place he/she wants it to be and clicks ok when done. Step 10: The system makes the subjects drag-able.
Step 12: The system updates.
ALTERNATE COURSE Step 1: The user clicks the automatic scheduling button if the user is on the home page.
USE CASE NO USE CASE NAME PRIMARY ACTOR Purpose Overview
10 Saving the schedule Any Authenticated User. To save schedule the timetable that was generated automatically or manually. When the user wants to schedule automatically or manually; the system generates an automatic schedule. And the user wants to save it. Primary and real Functions: RQ.11, RQ.14 System Response Step 2: The system asks the location to save the schedule.
Type Cross Reference
NORMAL COURSE OF EVENTS Actor Action Step 1: The user after scheduling clicks save.
Step 3: The user browses the location and clicks ok. Step 4: The system saves the file in .pdf format. ALTERNATE COURSE Step 1: If the schedule not complete; the system generates an error message.
92 | P a g e
Use Case Model:
93 | P a g e
12-
CRC Index Cards
Class Name: Person
ID: 1
Type: Abstract, Domain

Associated Use Case: 1,2,3,4,5,6,7,8,9,10,11
Description: A teacher who is registered. Responsibilities
Collaborators
Attributes: FirstName (String) LastName (String) ID (String) Password (String) Relationships: Generalization: Aggregation: Other: Teacher, Student, Admin
94 | P a g e
Class Name: Teacher
ID: 2
Type: Concrete, Domain Associated Use Case: 1,2,3,4,8,11 Collaborators Connectivity AddInfo Search
Description: A teacher who is registered. Responsibilities Log in Add Course Desc Search Course/s Show Related Teachers View Schedule Save Schedule Edit Course Content View View Edit
Attributes: Department (String) CoursesTeaching (String[])
Relationships: Generalization: Person Aggregation: Other: Connectivity, AddInfo, Search, List, View, Edit
95 | P a g e
Class Name: Student
ID: 3
Type: Concrete, Domain Associated Use Case: 1,2,3,8,11 Collaborators Connectivity Search List View
Description: A student who is registered. Responsibilities Log in Search Course/s List Courses View Course Content
Attributes: Department (String) Semester (String) CoursesTaking (String[])
Relationships: Generalization: Person Aggregation: Other: Connectivity, Search, List, View
96 | P a g e
Class Name: Admin
ID: 4
Type: Concrete, Domain

Associated Use Case: 1,2,3,4,5,6,7,8,9,10, 11
Description: A user from administration Responsibilities Log in Add a course Search course/s Schedule Time Table List Courses View Time Table Remove a Course
Collaborators Connectivity AddInfo Search Schedule List View Remove
Attributes:
Relationships: Generalization: Person Aggregation: Other: Connectivity, AddInfo, Search, Schedule, List, View, Remove
97 | P a g e
Class Name: Connectivity Description: To log in a user Responsibilities Check ID Check Pass
ID: 5
Type: Concrete, Domain Associated Use Case: 1 Collaborators Teacher, Student, Admin Teacher, Student, Admin
Attributes: ID (String) Password (String)
Relationships: Generalization: Aggregation: Other: Teacher, Student, Admin
98 | P a g e
Class Name: AddInfo
ID: 6
Type: Concrete, Domain Associated Use Case: 4, 5 Collaborators Course Course, Search
Description: To add info of a course or add a new one. Responsibilities Add Description of Course Add a new Course Save
Attributes: Description (String) CourseName (String)
Relationships: Generalization: Aggregation: Other: Course
99 | P a g e
Class Name: Search
ID: 7
Type: Concrete, Domain Associated Use Case: 3, 4, 9 Collaborators Course
Description: To search the registered courses. Responsibilities Search a Course Course Name exists?
Attributes: CourseName (String) Exists (boolean)
Relationships: Generalization: Aggregation: Other: Course
100 | P a g e
Class Name: Schedule
ID: 8
Type: Concrete, Domain Associated Use Case: 6, 7, 10, 11 Collaborators Course, Teacher, Search, Semester Course, Teacher, Search, Semester Course Edit View List
Description: A generate schedule manually or automatically
Responsibilities Manual Schedule Automatic Schedule Is Slot Free? Edit Auto Schedule Save List all courses
Attributes: SlotFree (boolean)
Relationships: Generalization: Aggregation: Other: Course, Teacher, Search, Edit, View, List
101 | P a g e
Class Name: List
ID: 9
Type: Concrete, Domain Associated Use Case: 2, 6, 7, 10 Collaborators Department Course
Description: To generate the list of registered courses Responsibilities Search Department List all Courses
Attributes: DepartmentName (String) Course (String [])
Relationships: Generalization: Aggregation: Other: Department, Course
102 | P a g e
Class Name: View
ID: 10
Type: Concrete, Domain Associated Use Case: 8,11 Collaborators Semester Teacher Department
Description: To view the schedule and/or saving it Responsibilities Search Semester Search Teacher Search Department View Schedule Browse Schedule Save
Attributes: Name (String)
Relationships: Generalization: Aggregation: Other: Semester, Teacher, Department
103 | P a g e
Class Name: Remove
ID: 11
Type: Concrete, Domain Associated Use Case: 9 Collaborators Search
Description: To delete a registered course Responsibilities Search Course Delete
Attributes: CourseName (String)
Relationships: Generalization: Aggregation: Other: Search
104 | P a g e
Class Name: Edit
ID: 12
Type: Concrete, Domain Associated Use Case: 4, 10 Collaborators Search
Description: To edit the content or edit auto-schedule Responsibilities Search Course Edit Content Edit Auto Schedule Save
Schedule
Attributes: Content (String)
Relationships: Generalization: Aggregation: Other: Search, Schedule
105 | P a g e
Class Name: Course
ID: 13
Type: Concrete, Domain Associated Use Case: 2,3,4,5,6,7,9, 10 Collaborators
Description: A Course which is registered. Responsibilities GetInfo Exists?
Attributes: CourseName (String) DeptName (String) Teacher (String) Time (String) Details (String) Relationships: Generalization: Aggregation: Other:
106 | P a g e
Class Name: Department
ID: 14
Type: Concrete, Domain Associated Use Case: 2, 5 Collaborators
Description: A department which is registered. Responsibilities GetInfo Exists?
Attributes: DeptName (String) Courses (String[]) RoomsAvailable (String[])
Relationships: Generalization: Aggregation: Other:
107 | P a g e
Class Name: Semester
ID: 15
Type: Concrete, Domain Associated Use Case: 6, 7, 8, 10, 11 Collaborators
Description: A semester with all the subjects offered. Responsibilities GetInfo Exists?
Attributes: SemsterName (String) Department (String)
Relationships: Generalization: Aggregation: Other:
108 | P a g e
13- Role Play Diagrams (RPD) Scenario 1:

Dr. Saba wants to log-in. She is a teacher. Her ID is Dr. Saba and her password is 123klm. Scenario 1: theGUI
1. Log in Dr. Saba having password: 123klm
Connectivity
Teacher ID: Dr. Saba Password: 123klm
Scenario 1: theGUI
Connectivity 2. ID ok? 3. ok
109 | P a g e
Scenario 1: theGUI
4. Pass ok? Connectivity 5. ok 2. ID ok? 3. ok
Scenario 1: theGUI
1. Log in Dr. Saba having password: 123klm 6. log in

4. Pass ok? Connectivity 5. ok 2. ID ok? 3. ok Teacher ID: Dr. Saba Password: 123klm
Scenario 1: theGUI 7. Done!
1. Log in Dr. Saba having password: 123klm 6. log in

4. Pass ok? 5. ok 2. ID ok? 3. ok Teacher ID: Dr. Saba Password: 123klm
Connectivity
110 | P a g e
Scenario 2: Dr. Saba wants to view all courses offered by the Computer Science department. The courses offered by the Computer Science department are: A, B, and C.
Scenario 1: theGUI
1. List all courses of Computer Science department
List Courses: A, B, C
Department DeptName: Computer Science
Scenario 1: theGUI
2. DeptName ok? 3. ok
111 | P a g e
Scenario 1: theGUI

4. List: A, B, C
Scenario 1: theGUI
5. Done!

4. List: A, B, C
112 | P a g e
Scenario 3: Dr. Saba wants to search the Software Engineering II Course and see the details of this course.
Scenario 1: theGUI
1. View Course details of Software Engineering II
Search
Course CourseName: Software Engineering II
Scenario 1: theGUI
1. View Course details of Software Engineering II
Search
2. Course Name ok? 3. ok
113 | P a g e
Scenario 1: theGUI
1. View Course details of Software Engineering II 4. Display details
Search
2. Course Name ok? 3. ok
Scenario 1: theGUI
5. Done!
1. View Course details of Software Engineering II 4. Display details
Search
2. Course name ok? 3. ok
114 | P a g e
Scenario 4: Dr.Saba wants to change the book name of the Software Engineering IIs course details. We assume that the already prescribed book Abc is no longer in need and the new Xyz book should be taught to the students.
Scenario 1: theGUI
1. Edit Course details of Software Engineering II; change book name to Xyz
Edit
Search
Course CourseName: Software Engineering II Details: Abc
Scenario 1: theGUI
Edit
2. Search Software Engineering II
Search
115 | P a g e
Scenario 1: theGUI
Edit
Search
3. Software Engineering II exists? 4. Ok
5.Edit Abc to Xyz
Scenario 1: theGUI
Edit
Search
116 | P a g e
5.Edit Abc to Xyz
Scenario 1: theGUI
Edit
2. Search Software Engineering II 6. Save
Search
5.Edit Abc to Xyz
Scenario 1: theGUI
6. Done!
Edit
2. Search Software Engineering II 6. Save
Search
117 | P a g e
Scenario 5: Add Discrete Structures to the database.
Scenario 1: theGUI
1. Add Discrete Structures In the database
AddInfo
Search
Course CourseName:
Scenario 1: theGUI
AddInfo
2. Search Discrete Structures Exists? Course CourseName:
Search
118 | P a g e
Scenario 1: theGUI
AddInfo
2. Search Discrete Structures Exists? 3. Discrete Structure exists? 4. No Course CourseName: No
Search
5. Add description
Scenario 1: theGUI
AddInfo
Search
119 | P a g e
5. Add description
Scenario 1: theGUI
AddInfo
6. Save
Search
5. Add description 7. Done!
Scenario 1: theGUI
AddInfo
2. Search Discrete Structures Exists? 3. Discrete Structure exists? 4. No
6. Save
Search
Course CourseName: No Yes
120 | P a g e
Scenario 6: The user wants to auto schedule the time table of the 6th semester using Maths, English and P-St; and Miss Itrat, Mis Sadia and Miss Shela as their teachers respectively. theGUI 1. Schedule timetable for 6th sem Schedule
Teacher
Search
Semester SemName:
Course
theGUI
1. Schedule timetable for 6th sem
Schedule
2. Semester 6th Teacher Search Semester SemName:
Course
121 | P a g e
theGUI
Schedule
3. Search English, P-St, Maths Teacher Search
2. Semester 6th Semester SemName: 6th
Course
theGUI
Schedule
3. Search English, P-St , Maths Teacher Search
4. En 4. English, Maths, P-St exists? 5. ok Course
122 | P a g e
theGUI
Schedule
6. Show Teachers 7. Mis Itrat, Mis Sadia, Mis Shela Teacher Teachers: Miss Itrat, Mis Sadia and Miss Shela 2. Semester 6th Semester SemName: 6th
3. Search English, P-St , Maths Search
8. Schedule theGUI 1. Schedule timetable for 6th sem Schedule
123 | P a g e
8. Schedule 9. Save theGUI 1. Schedule timetable for 6 sem

th
Schedule
10. Done! theGUI 1. Schedule timetable for 6th sem
8. Schedule 9. Save Schedule
124 | P a g e
Scenario 7: The user wants to schedule manually the time table of the 6th semester using Maths, English and P-St; and Miss Itrat, Mis Sadia and Miss Shela as their teachers respectively. theGUI 1. Schedule timetable for 6th sem Schedule
Teacher
Search
Semester SemName:
Course
theGUI
Schedule
Course
125 | P a g e
theGUI
Schedule
Course
theGUI
Schedule
126 | P a g e
theGUI
Schedule
8. MSchedule theGUI 1. Schedule timetable for 6th sem Schedule
127 | P a g e
8. MSchedule 9. Save theGUI 1. Schedule timetable for 6 sem

th
Schedule
10. Done! theGUI 1. Schedule timetable for 6th sem
8. MSchedule 9. Save Schedule
128 | P a g e
Scenario 8: View the schedule of semester 6th. theGUI 1. View Schedule of semester 6th View
Semester
Schedule
theGUI
1. View Schedule of semester 6th
View
2. Show Schedule Semester Semester: 6th Schedule
3. Done! theGUI 1. View Schedule of semester 6th View
2. Show Schedule Semester Schedule
129 | P a g e
Scenario 9: Delete Math from database.
theGUI
1. Delete Math
Remove
Course
Search
theGUI
1. Delete Math
Remove
2. Search Math
Course
Search
theGUI
1. Delete Math
Remove
2. Search Math 3. Math exists? 4. Yes
Course Course: Math
Search
130 | P a g e
5. Delete theGUI 1. Delete Math Remove
Course Course: Math
Search
6. Done! theGUI 1. Delete Math
5. Delete Remove
Course Course: Math
Search
131 | P a g e
Scenario 10: Mr. Habib wants to auto schedule the time table of semester 6th using Maths, English and P-St; and Miss Itrat, Mis Sadia and Miss Shela as their teachers respectively. Then he wants to edit the schedule. theGUI 1. Schedule timetable for 6th sem Schedule
Teacher
Search
Semester SemName:
Course
theGUI
Schedule
Course
132 | P a g e
theGUI
Schedule
Course
theGUI
Schedule
133 | P a g e
theGUI
Schedule
8. Schedule theGUI 1. Schedule timetable for 6th sem Schedule
134 | P a g e
8. Schedule 9. Edit theGUI 1. Schedule timetable for 6th sem Schedule
theGUI
8. Schedule 9. Edit 10. Save 1. Schedule timetable for 6th sem Schedule 6. Show Teachers
7. Mis Itrat, Mis Sadia, Mis Shela Teacher Teachers: Miss Itrat, Mis Sadia and Miss Shela
135 | P a g e
11. Done! theGUI
8. Schedule 9. Edit 10. Save 1. Schedule timetable for 6th sem Schedule 6. Show Teachers
7. Mis Itrat, Mis Sadia, Mis Shela Teacher Teachers: Miss Itrat, Mis Sadia and Miss Shela
Scenario 11: After viewing the time table of semester 6th; Mr. Habib wants to save it on his system. theGUI 1. View Schedule of semester 6th View
Semester
Schedule
136 | P a g e
theGUI
1. View Schedule of semester 6th
View
2. Show Schedule Semester Semester: 6th Schedule
3. save theGUI 1. View Schedule of semester 6th View
3. save theGUI 1. View Schedule of semester 6th
4. Browse location View
137 | P a g e
5. Done! theGUI
3. save 1. View Schedule of semester 6th
4. Browse location View
138 | P a g e
14Term
System Glossary Definition

An ID given to the user by the university A code assigned to every user for privacy Database where all the information is stored An ID given to the course by the admin Scheduling done by the system itself by running an algorithm Scheduling done by the user manualy Time table generated for every semester of each department A toolbar in GUI A kind of GUI due to which a user can drag and drop objects with the mouse A function that is used to change the already present content A function which saves the content in the database A function which is used to locate files in the users system
Format
Alphanumeric Alphanumeric(max 8 characters)
Aliases
Given by the university
Username Password Server Course ID Automatic scheduling
Alphabets
Manual scheduling Schedule
Search bar Drag and drop menu
Edit
Save Browse location
139 | P a g e
15-
Conceptual Model
Conceptual Class Category Conceptual Class keyboard SRS
Concept Category List
Physical or tangible objects Specifications, deigns or descriptions of things Places Transactions Transaction line items Roles of people Containers of other things Things in a container Other computer or electro-mechanical systems external to the system Organizations Events
University Schedule Courses, Teachers Student, Teacher, Admin Database Teacher, Student, Admin Comsis
University AutomaticScheduling ManualScheduling EditCourseDescription SavingSchedule
Rules and policies Catalogs
SchedulingPolicy CourseCatalog
Records of work, contracts, legal matters Comsis, Syllabus Manuals, documents, reference papers, books Syllabus, CourseSpecification
140 | P a g e
Concept Association List: Category A is a physical part of B A is a logical part of B Association between Conceptual Classes Keyboard Courses Teachers A is physically contained in/on B A is logically contained in B A is a description for B A is a line item of a transaction or report B A is known/ logged/ recorded/reported/captured in B System System Schedule Schedule University Syllabus Courses
CourseSpecification CourseSpecification Courses Teacher Schedule Schedule
AutomaticScheduling ManualScheduling EditCourseDescription SavingSchedule
MyCourses MyCourses MyCourses
MyCourses
A is a member of B
Teacher Student Admin
University University University University MyCourses MyCourses MyCourse Student Teacher Schedule
A is an organization subunit of B A use or manages B
Department Teacher Student Admin
A communicates with B
Teacher Admin
A is related to a transaction B
Admin
141 | P a g e
A is a transaction related to another transaction B A is next to B A is owned by B
AutomaticSchedule
ManualSchedule
MyCourses MyCourses
MyCourses University
142 | P a g e
161-
System Operations
log-in
System1 login()
2-
Listing the courses

System2 search() action()
3-
Edit Course Description

System3 action() edit() editContent() save()
4-
Adding a new Course

System4 search() event() create() new()
5-
Auto-Scheduling
System5 event() semester() enterC() enterT()
143 | P a g e
6-
Manual Scheduling
System6 event() semester() enterC() enterT() DragNDrop()
7-
View Schedule
System7 event() search() semester()
8-
Deleting a Course
System8 searchCourse() event()
9-
Edit Auto-Scheduling
System9 event() semester() enterC() enterT() DragNDrop()
10-
Saving the schedule

System10 event() search() semester() browse() 144 | P a g e
17- Operation Contracts

Name: login (username : String, password : String) 1 Number: Responsibilities: Checks that the entered username and password are correct; if they are correct then successfully login the user to the system otherwise display an error message. System Type: SSD: sd log-in Use-Case: 1 Cross References: Uses database Notes: If username and/or password is not valid indicate error Exceptions: The user is successfully logged in Output: Pre-conditions: Username and password are known to the system - If a teacher logged in; a new Teacher is created (instance created) Post- If a student logged in; a new Student is created (instance created) Conditions: - If an admin logged in; a new Admin is created (instance created)
Name: Search (deptName : String) 2 Number: Responsibilities: Checks that the entered department name exists in the database or not and if it does opens up that department page System Type: SSD: sd listing the courses, sd adding a new Course , sd saving the schedule Cross Use-Case: 2,4, 10 References: Uses database Notes: If department name does not exist indicate error Exceptions: The departments page opens up Output: Pre-conditions: Department name is known to the system - Department is created (instance created) Post- Courses is created (instance created) Conditions: - Teacher is created (instance created) - Department is associated with Courses (association) - Department is associated with Teachers (association)
Name: Number: Responsibilities: Type: Cross References:
Notes:
Event (ActionName : String) 3 Does appropriate function with reference to ActionName System SSD: sd listing the courses, sd edit course description, sd adding a new Course , sd auto scheduling, manual scheduling, sd view schedule, sd deleting a course, sd edit auto scheduling, sd saving the schedule Use-Case: 2, 3, 4, 5, 6, 7, 8, 9, 10 Has many function
145 | P a g e
Exceptions: Output: Pre-conditions: Post-Conditions:
If the action cannot be performed indicate error The action is done and returns true ActionName is known to the system - actionPerformed is set to true (attribute modification)
Name: Number: Responsibilities: Type: Cross References: Notes: Exceptions: Output: Pre-conditions: PostConditions:
Edit (courseID : String) 4 Determines which course description is to be edited System SSD: sd edit course description Use-Case: 3 Uses database If courseID does not exist indicate error Ready to edit courseID is known to the system - Courses is created (instance created) - Courses is associated with CourseSpecification (association) - CourseSpecification is created (Instance created)
EditContent (content : String) 5 Performs edit functionality. System SSD: sd edit course description
Use-Case: 3
Uses database If content is null indicate error The edit functionality is achieved courseID is known to the system - Courses is created (instance created) - Courses is associated with CourseSpecification (association) - CourseSpecification is created (Instance created) - CourseSpecification.description is changed (attribute modification)
Name: Number: Responsibilities: Type: Cross References: Notes: Exceptions:
Save () 6 Saves the content in the database System SSD: sd edit course description Uses database If content cannot be saved indicate an error
Use-Case: 3
146 | P a g e
Output: Pre-conditions: PostConditions:
Content is saved and returns true if done Saved variable is set to true (attribute modification)
Create (CName : String; CID : String) 7 Adds a new Course with name: CName and ID: CID System SSD: sd adding a new course Use-Case: 4 Uses database If CName and/or CID exists indicate an error A new course is created and added in database and returns true if done CName and CID are new to the system - Courses is created (instance created) - Courses is associated with CourseSpecification (association) - CourseSpecification is created (Instance created) - Department is created (instance created) - Schedule is created (instance created) - Courses is associated with Department (association) - Courses is associated with Schedule (association) - Set Done variable to true (attribute modification)
New (courseContent : String) 8 Adds Course content to the newly created course System SSD: sd adding a new course Use-Case: 4 Uses database If courseContent is null; indicate an error The new course is saved with its course content and saved CName and CID are created - Courses is created (instance created) - Courses is associated with CourseSpecification (association) - CourseSpecification is created (Instance created) - Department is created (instance created) - Courses is associated with Department (association) - Schedule is created (instance created) - Courses is associated with Schedule (association) - Content variable is modified( attribute modification)
147 | P a g e
Name: Number: Responsibilities: Type: SSD: Cross References: Notes: Exceptions: Output: Pre-conditions: PostConditions:
Semester (SemesterName : String) 9 Search if the entered semester is correct or not System sd auto-scheduling, sd view schedule, sd edit auto scheduling, sd saving the schedule Use-Case: 5, 7, 9, 10 Uses database If semsterName doesnt exist; indicate an error Returns true if semester exists SemesterName should be known to the system - Done variable is set to true (attribute modification)
EnterC (AllCourses : String[]) 10 Checks if the entered lists of courses exists or not System SSD: sd auto-scheduling, sd manual scheduling, sd edit auto scheduling UseCase: 5, 6, 9 Uses database If any course doesnt exist; indicate an error Returns true if all the courses exists All the courses should be known to the system - Schedule is created (Instance created) - If automatic scheduling; auto_schedule is created (instance created) - If manual scheduling; manual_scheduling is created (instance created) - Schedule_Desc is created (instance created) - Schedule is associated with Schedule_Desc (association) - Done variable is set to true (attribute modification)
EnterT (AllTeachers : String[]) 11 Checks if the entered lists of teachers exists or not System SSD: sd auto-scheduling, sd manual scheduling, sd edit auto scheduling UseCase: 5,6, 9 Uses database If any teacher name doesnt exist; indicate an error Returns true if all the teacher name exists All the teacher names should be known to the system - Schedule is created (Instance created) - If automatic scheduling; auto_schedule is created (instance created) - If manual scheduling; manual_scheduling is created (instance created) - Schedule_Desc is created (instance created)
148 | P a g e
Schedule is associated with Schedule_Desc (association) Done variable is set to true (attribute modification)
DragNDrop (Courses : String[]) 12 Changes the behavior of course to drag-and-drop System SSD: sd manual-scheduling, sd edit auto scheduling
Use-Case: 6, 9
Change the behavior of courses selected If any courses can not be placed at a place; indicate an error Returns true if the placing of course is possible Atleast one course must be selected - Schedule is created (Instance created) - If automatic scheduling; auto_schedule is created (instance created) - If manual scheduling; manual_scheduling is created (instance created) - Schedule_Desc is created (instance created) - Schedule is associated with Schedule_Desc (association) - Done is set to true if done (attribute is modified)
SearchCourse (CourseName : String) 13 Checks if the course exists or not System SSD: sd deleting a course Use-Case: 8 Uses database If course name does not exist indicate error Returns true if it exists Course name is known to the system - Courses is created (instance created) - CourseSpecification is created (instance created) - Schedule is created (instance created) - Department is created (instance created) - Courses is associated with CourseSpecification (association) - Courses is associated with Schedule (association) - Courses is associated with Department (association)
149 | P a g e
Browse (location : String) 14 Checks if location exists or not System SSD: sd deleting a course, sd saving the schedule
Use-Case: 8, 10
Uses users system If it can not be saved; indicate an error Returns true if location is ok and it can be saved in that location Location must exist - SaveSch is created (instance created) - SaveSch is associated with ViewSch (association) - ViewSch is created (instance created)
150 | P a g e
18-
System Sequence Diagrams:
151 | P a g e
152 | P a g e
153 | P a g e
154 | P a g e
155 | P a g e
191-
UML Diagrams
Class Diagram
156 | P a g e
2-
Component Diagram
157 | P a g e
3-
Deployment Diagram
158 | P a g e
4-
Package Diagram
159 | P a g e
5-
Activity Diagram
Listing the courses:
Edit Course Content:
160 | P a g e
Adding New Course:
Schedule:
161 | P a g e
Deleting a Course:
162 | P a g e
6-
Sequence Diagram
Add Course:
Auto-Schedule:
163 | P a g e
Manual Scheduling:
View Schedule:
164 | P a g e
20-
Appendixes
Glossary
Term
Username Password Server Course ID Automatic scheduling Manual scheduling Schedule Search bar Drag and drop menu Edit Save Browse location
Definition
An ID given to the user by the university A code assigned to every user for privacy Database where all the information is stored An ID given to the course by the admin Scheduling done by the system itself by running an algorithm Scheduling done by the user manualy Time table generated for every semester of each department A toolbar in GUI A kind of GUI due to which a user can drag and drop objects with the mouse A function that is used to change the already present content A function which saves the content in the database A function which is used to locate files in the users system
165 | P a g e

MyCourses A UML Docoment With Usecase and Class Diagrams

Uploaded by

Document Information

Original Description:

Original Title

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

MyCourses A UML Docoment With Usecase and Class Diagrams

Uploaded by

Copyright:

Available Formats

COMSATS Institute of Information Technology, Islamabad Campus

MyCourses-A Course Scheduling System

SOFTWARE ENGINEERING-II (CSC 392)

__________________________ (Project Coordinator)

________________________ (Course Instructor)

4.1 Cost Estimation ..................................................................................................... 16 4.2 Software Schedule: ............................................................................................... 18

Appendixes .................................................................................................................................... 165

Glossary ...................................................................................................................... 165

Vision Document 1- Introduction:

The impact of which is

2.2 Position Statement:

3- Stakeholder and User Descriptions:

stakeholders for these users.

The designers will act as stakeholders for these users.

Automatic scheduling process-users

They could be professors or coordinators or people from the examination department.

Alternatives and Political Landscape

Software Requirement Specification

Definitions, Acronyms and Abbreviations

The chapter 3 shows the Specific Requirements.

Assumptions and Dependencies

4.1.2- Stimulus/ Response Sequence:

Software Project Plan:

= 6000 kloc. = 2000 kloc. = 3 kloc.

= 8012 kloc. This the size.

2) Optimal labour allocation. Now we will find where r = 60 %

= . 32.0 ( 0.6 . 2 o.6 + = 25.6 [M].

4) Expected work load .

= 2 25.6 = 51.2 [PM].

5) The final expected project cost.

Roles of different people:

Fareeha Amjad Asma Kaleem

25th March, 2011

28th March, 2011

28th March, 2011

4th April, 2011

28th March, 2011

4th April, 2011

4th April, 2011

11th April, 2011

4th April, 2011

11th April, 2011

11th April, 2011

21st April, 2011

11th April, 2011

21st April, 2011

21st April, 2011

29th April, 2011

21st April, 2011

29th April, 2011

29th April, 2011

6th May, 2011

29th April, 2011

6th May, 2011

6th May, 2011

9th May, 2011

9th May, 2011

13th May, 2011

Fareeha Amjad 3 Asma Kaleem Fareeha Amjad

13th May, 2011

16th May, 2011

16th May, 2011