FINAL YEAR PROJECT TextSer

6/24/2011

By: Anum Tabani, Sahar Hasan Khan, Saud Imtiaz

Table of Contents
Acknowledgement ................................................................................................................................... 3 Preface .................................................................................................................................................... 4 1. Project Description .............................................................................................................................. 5 1.1 About the project ........................................................................................................................... 5 1.2 System functions ............................................................................................................................ 5 1.3 About User Characteristics ............................................................................................................. 6 2. Development Strategy ......................................................................................................................... 7 2.1 Requirement elicitation.................................................................................................................. 8 2.1.1 Student Requirement Elicitation .............................................................................................. 8 2.1.2 Admin/Faculty Survey............................................................................................................ 11 2.1.3 Systems Requirement elicitation ........................................................................................... 12 2.2 Design .......................................................................................................................................... 13 2.3 Implementation ........................................................................................................................... 16 2.4 Testing ......................................................................................................................................... 16 2.5 System Snapshots ........................................................................................................................ 17 3. 4. Risk Management Plan................................................................................................................... 23 Quality Assurance Plan................................................................................................................... 25 4.1 Project Quality Goals .................................................................................................................... 25 5. Feedback Form .............................................................................................................................. 26

Acknowledgement
We would like to thank Dr. Sajjad Haider and Mr. Imran Batada for their involvements and contributions to our Final Year Project TextSer . We are grateful to both of you for sharing your knowledge with us and sparing time for our project. Your cooperation in our FYP greatly assisted our learning and increased our knowledge base. Your support directed us throughout this project and is highly appreciated. Sincerely yours,

Anum Tabani Sahar Hasan Khan Saud Imtiaz BS-Class of 2011 Institute of Business Administration

Preface
The following report is a written documentation of our Final Year Project called TextSer for the Faculty of Computer Science of the Institute of Business Administration. The project was supervised by Dr Sajjad Haider and coordinated by Mr Imran batada. Work on the project started in 7th semester 2010 and finished in the 8th semester 2011. This project is a text based solution for students to know their results. It has a diverse scope to be expanded to provide features such as attendance and semester grades and so on. The system has a number of stake holders including the students, faculty, IBA MIS department and the ERP that is deployed in IBA. The objective is to design a system that will notify the students of their grades and CGPA, if they inquire.

1. Project Description
1.1 About the project
This project is a text based solution for students to know their results. It has a diverse scope to be expanded to provide features such as attendance and semester grades and so on. The system has a number of stake holders including the students, faculty, IBA IT department and The ERP that is deployed in IBA. The objective is to design a system that will notify the students of their grades and CGPA, if they inquire.

1.2 System functions

To inquire the CGPA a student would send the message in the following format <ERP ID> <password> CGPA If the ID or password is incorrect then system would notify the student to try again. For such a system, reliability and security are crucial. Students who have their cell numbers registered in the ERP will be able to use this system. Registering their cell numbers is a pre-requsite for security and privacy of data. The system would be connected to the ERP and would give an instant reply when the query is sent.

System Overview Diagram

1 2 3 4 5 6 SMS 7
CGPA CGPA

Within the middle tier:

Code

1. Connectivity 2. Message Parsing 3. Verification -password -phone # 4. Log maintenance 5. query

Internet

9 10

Client

ERP view-CGPA &Phone # fetch for verification

ERP PW check API connection

ERP PW check API connection

Log DB

1.3 About User Characteristics

Students The Students of IBA would send in the particular query in a fixed format. The system would verify the student by his registered cell number ERP ID and password. If these are correct the system would notify the students of their GPA. If the ERP and password do not match with the ERP then the students would be asked to send in their query again with the right password. System Administrator The system administrator would be managing the system. He would be looking into management of the system. The system would have a log of students who sent the querys and the date and timings of the texts sent. System Administrator will also make sure that the ERP is connected and that the system is functioning smoothly.
6

The ERP Since the system is connected to the ERP, it will fetch all information from the tables in the ERP. Hence when the GPA of students will be updated in the ERP. The system would also reply with the updated GPA when the query is sent. As of now ERP is an 24-7 online Suite the system would respond at any time of the day. Teachers The teachers have an indirect relation to the system. For every course the teacher would have to post marks of the semester. Once all course grades have been updated for the particular semester the GPA would be updated.

2. Development Strategy

Life cycle methodology Waterfall model was chosen as the as the development strategy for TextSer. The phases in the waterfall model were: Requirement Specification, Software Design, Implementation and Testing and maintenance. All these phases were cascaded to each other so that the second phase is states when the defined set of goals is achieved for the first phase and it is signed off. Hence the name Waterfall model

Requirements Gathering and Design Requirement elicitation was done in 3 phases. Student Requirement elicitation , Admin- Faculty elicitation and System requirement elicitation

2.1 Requirement elicitation

2.1.1 Student Requirement Elicitation

We randomly interviewed 10 people at IBA. The random sample included people from MBA, BS and BBA, semesters 3, 5 and 7. The questionnaire included basic questions regarding the textbased CGPA inquiring system, including would it be popular among students at IBA, to what extend will it be used, how would they rate the system in terms of reliability/security, minimal SMSes, instant response and easy to remember key words. The questionnaire also asked students as to what additional features would they want to have as an extension of the system. The following questionnaire was presented to the students:

Stakeholders: Students (users) 1. Do you know your CGPA? 2. Would you like to access your CGPA conveniently? 3. Would you use our text-based CGPA inquiring a system? 4. Rate the features that you think such a system would have y y y y Easy to remember keywords Minimal SMSs Reliability/security Instant response

5. What additional features would you like to have? (for extension of this system)

User requirements Analysis We randomly interviewed 10 people at IBA. The random sample included people from MBA, BS and BBA, semesters 3, 5 and 7. The questionnaire included basic questions regarding the textbased CGPA inquiring system, including would it be popular among students at IBA, to what extend will it be used, how would they rate the system in terms of reliability/security, minimal smses, instant response and easy to remember key words. The questionnaire also asked students as to what additional features would they want to have as an extension of the system.

Additional featuers

30% 40% course grades notifications others 30%

Fig (a)

Survey concluded that 40% of the students would want to know their individual course s grades. About 30% of the students being questioned said that they would like to get notifications regarding their number of absences in each course. Other 30% of answers related

to additional features of the system included class scheduling, inquiring the class room number, holiday notices and course registration. The students were asked which feature they would want our system to have. They were given the following 4 features: 1. Easy to remember keywords i.e the format of the text to be sent by the students 2. Instant response i.e To get reply from the system instantaneously 3. Reliability : The information received should be valid 4. Minimal SMSs: The number of text messages should be minimum

45% 40% 35% 30% 25% 20% 15% 10% 5% 0% Easy to remember instant response Keywords reliability Minimal SMSs

Fig (b)

In our analysis, as shown in fig (b) we found out that Easy to remember keywords and instant response are key features that our system should have. Reliability and Minimal SMS were not much of an importance for most of the students.

10

2.1.2 Admin/Faculty Survey

We interviewed admin and faculty members including Dr Shakeel Khoja, Mr Raza Abedia and Mr faisal Iradat. We received a positive response from all of them. They thought that an SMSbased CGPA inquiry system is a good idea and would be used by most of the students. They suggested that security should be verified by the combination of cell number and ERP ID of the students. Dr Khoja also suggested that pin code verification should be used in addition to the cell number and ERP ID. As for the additional features, all recommended that the system should be able to notify students about their number of absences in each course, their semester and course grades and class schedule. The following Questionnaire was presented to the Faculty for their views on our proposed system. Admin/Faculty Survey We are students of BS-7 and we are working on our Final Year Project titled: Text-based GPA Inquiry System. This survey aims to know the perception of the faculty and exam administrators about such a system. So far we have received a 100% positive response from the students to implement the system in IBA.

1. Do you think that the students would use our text based GPA inquiry system? o Yes o No

2. How do you think that faculty will respond to the implementation of the system o Positively o Negatively

3. What do you suggest the security should verified by: Cell number, Erp ID or a combination both? o ERP ID
11

o Cell no o Both

4. What additional features would you suggest for the system? o Notify semester grades and subject grades

o Notify class schedule o Notify number of absences for a course o Other__________________________________

2.1.3 Systems Requirement elicitation

The MIS department was asked for system requirements and the following requirements were gathered.

System Requirements Gathered

Constraints: y y y The client won t allow any kind of changes to be made in their ERP database. Only the particular and required fields of the database will be only accessible The developers can t view the records of the students. They will only be allowed to view the records of students who give their consent to view their records and results. y The formal consent to even access the ERP desired fields must be taken from the Associate Dean. y ERP will only be accessed to access the results and for verification and authentication purposes

12

Functional Requirements: y The MIS department wants us to maintain separate Database for the log of the transaction and to store the accessed the results. The results obtained after querying the ERP will be stored in our database. y y That database will be integrated with the ERP in the last stages of the deployment. The MIS department has given us a free hand to use any programming language and any tools that we are comfortable with. They kept no restrictions on the use of the open source code for certain modules of the application. y MIS manager advised us to keep a security check through phone numbers of the student that are stored in the ERP i.e. the query will only be answered to the phone numbers stored in their DB. y y ERP has 24/7 availability, there are only overload times but no crash. Our client wants us to make an MIS i.e. login interface through which they can view the log and reports of the system. y After the successful completion of prototype they may want us to develop an SMS utility application that will be a middle tier and serve as an integration module between the ERP and SMS DB. y The data flow suggested by the MIS manager is depicted in the diagram below

2.2 Design

The following UML diagrams were used for system design and coding:  Activity Diagram  Sequence Diagram

13

Activity Diagram

u s e r s e n d s s m s to g e t C G P A *

G S M m o d u le r e c e iv e s th e S M S

G S M p a s s e s th e S M S o n th e la p to p

E R P s y s te m r e c e iv e s th e Q u e r y

E R P s y s te m v e r ifie s th e q u e r y

V e r ifie d

In v a lid p a s s w o rd

* * E R P r e tr ie v e s C G P A a n d s e n d it to G S M E R P n o tifie s th e s tu d e n t v ia G S M *

G S M s e n d s th e r e s u lts to th e s tu d e n t

(student) sends SMS to the GSM module to get the CGPA. GSM module receives the SMS and passes it on to the laptop. The ERP system (database) receives the query and verifies it. If the

14

query is valid, the ERP database retrieves the CGPA ad sends it to GSM ad the GSM ultimately sends it to the system. Whereas if the query is invalid, the ERP database notifies the student via the GSM.

Sequence Diagram

Client

Nokia N8

SysApp

ERP ID,Ph #

ERP CGPA

getCGPA(userID,PW) PCCAPI() verify(Ph #, PW) Verified getCGPA()

getCGPA(3.2) getCGPA(3.2) getCGPA(3.2)

Scenerio1: Valid Password

15

Client

Nokia N8

SysApp

ERP ID,Ph #

ERP CGPA

getCGPA(userID,PW) PCCAPI() verify(Ph #, PW) Reverify(Ph #, PW) Reverify(Ph #, PW) Invalid password try again

Scenerio2: invalid Password

2.3 Implementation
After the design was finalized. Project coding and development was started in The project was developed in C# in visual Studio 2010. Microsoft SQL Management studio was used as a database for the prototype and Oracle was used . GSM COM

2.4 Testing There were two rounds of testing. First test was conducted with the prototype that was developed with Microsoft SQL Server. Test SMS was sent to TextSer and Textser system would instantly reply with either the GPA or incorrect id or password. The Second round of testing was done with Oracle.

16

2.5 System Snapshots The following screen shot shows our running application/ the executable file. The settings tab checks on which port on device is connected. The device is connected on COM11 port.

17

The users tab has four columns: ID, password, CellNo and CGPA. They display each user s ID, password, cellno and CGPA respectively.

18

The Receiving tab indicates the new message received and their details.

19

The SMS Received tab shows the details of the received SMSes and whether the message received is valid or not.

20

The SMS sent tab shows the details of the SMSes sent in response to the SMSes received by the students who want to inquire their CGPA.

21

Our database has 3 tables: smsrcvd, smssent and Studentinfo y y y Smsrcvd has the following fields: id, rcvdAt, message and num Smssent has the following fields: id, sentAt, message and num Studentid, password, cellno, cgpa

22

3. Risk Management Plan

We want our software to be free of any defects or errors, but it is hard or at times almost impossible to develop a system that is free of any defects. To be safe we would like to have a risk management plan to counter any difficulties that may impact the development or the creation of the software. Our goal is to develop a strategy to deal with any risk that may occur during or after our software has been developed. For this we will take a look at the possible risks, how to monitor them and how to manage the risk. Software development can avoid having risk by double-checking the project schedule and by being sync with the requirements of the project. Customer or stake holders can help avoid risk by providing all necessary software information during the early phase of the development. Client can avoid risk by making all necessary business changes before initiating request for the software. Following are the possible risks that might occur and the mitigation strategies to counter the risks: y y y Requirements change Security Breach Virus attack

Mitigation Strategies: Requirements change Requirements have been base lined but continue to change. This can be risky for a project where its profitability is concerned. To deal with changing requirements, revise all the requirements and get the programmer to integrate the new changes. At times even changing technology can lead to changing requirements.

23

Security Breach To ensure that the data is secure and safe and to avoid security breach, give data access to only a chosen few personnel and keep data encrypted. Create back up data and create backup source code. Virus attack The risk of a virus attack even in a normal scenario can t be denied. Antivirus software installed and latest definition files updated, the possibility of business disruption is either none or negligible.

Constraints of the system: y The phone we are using for the system is Motorola L7. Our system or the time being is restricted to Motorola phones only. y The system can handle upto 8-10 SMSes per minute. This can be handled by using separate phones for handling sending and receiving of SMSes.

24

4. Quality Assurance Plan

Quality assurance is a critical part of well-managed development and acquisition projects. Comprehensive quality assurance, risk management, and testing standards provide the best means to manage project risks and ensure software includes expected functionality, security, and operability. The purpose of this Software Quality Assurance (SQA) Plan is to establish the goals, processes, and responsibilities required to implement effective quality assurance functions for the SMSbased CGPA inquiry system. The SMS-based CGPA inquiry system Software Quality Assurance Plan provides the framework necessary to ensure a consistent approach to software quality assurance throughout the project life cycle. It defines the approach that will be used by the Software Quality (SQ) personnel to monitor and assess software development processes and products to provide objective insight into the maturity and quality of the software. The systematic monitoring of the SMS-based CGPA inquiry system processes and services will be evaluated to ensure they meet requirements and comply with the project policies, standards, and procedures.

4.1 Project Quality Goals

The project quality goals are as follows: y y Establish coding standards to ensure the delivery of quality code. The ease with which a developer can modify the system to change or add capabilities, improve performance or correct defects. y The degree to which the SMS-based CGPA inquiry system can be used in an environment which is different from the one it was developed in. y The degree to which the system is free from faults in its requirements, scope, specification, architecture, design, implementation and deployment.

25

5. Feedback Form

Please fill out the following feedback form

1. Do you think this project is useful? o Yes o No (if no , go to question 4)

2. If yes, then what additional features can be added to the system?

______________________________________________________________________________ ______________________________________________________________________________ ______________________________________________________________________________ ______________________________________________________________________________

3. Do you think that other institutions across Pakistan would implement it? o Yes o No

4. If not they why do you think this project is not useful? _____________________________________________________________________________________ _____________________________________________________________________________________ ___________________________________________________________________________________

5. Please give out any suggestions for the project _____________________________________________________________________________________ _____________________________________________________________________________________ _____________________________________________________________________________________ _____________________________________________________________________________________ 26

Feedback Results The aforementioned mentioned Feedback form was asked to be filled by judges attending Connections. The idea in general was liked by the judges. It was also suggested by one judge that this model can be applied by different organizations for different purposes. For example, it can be used to pay bills for KESC where the system would be a middleman between KESC and the customer. One of the criticism included that this would only be used once at the end of semester when the CGPA changes. The first question got 100% response. All in all the idea was appreciated by the judges.

27