A Project Report

i i

On

i Codet – Code Together

i i i

Submitted ifor ipartial ifulfillment iof ithe irequirements

for ithe iaward iof ithe idegree iof

Bachelor iof iTechnology

Computer iScience iand iEngineering

Submitted by i

Shomik Goswami (1502910146)

i i

Shraddha Singh (1502910147) i i

Shivam Shahi (1502910145)

i i

Under supervision of i i

Prof. Aruna Yadav i i

KIET Group of Institutions, Ghaziabad

i i i i

Dr. A.P.J. Abdul Kalam Technical University, Lucknow

i i i i i i

May, 2019 i

1
 DECLARATION

I hereby declare that this submission is my own work and that, to the best of my
knowledge and belief, it contains no material previously published or written by another
person nor the material, which to a substantial extent, has been accepted for the award of
any other degree or diploma of any university or other institute of higher learning, except
where due acknowledgment has been made in the text.

Signature

Name:- Shomik Goswami / Shraddha Singh / Shivam Shahi

i i i i i i i i

Roll No.:- 1502910146 / 1502910147 / 1502910145

i i i i i i

Date:-

2
 CERTIFICATE

This is to certify that the project Report entitled, “Codet- Code Together” submitted by
Shomik iGoswami, Shraddha iSingh and Shivam Shahi in the Department of Computer
Science And Engineering of KIET Group of Institutions, Ghaziabad, affiliated to Dr. A.
P. J. Abdul Kalam Technical University, Lucknow, Uttar Pradesh, India, is a record of
bonafide project work carried out by them under my supervision and guidance and is
worthy of consideration for the award of the degree of Bachelor of Technology in
Information Technology of the Institute.

Date: Supervisor: ARUNA YADAV

(Assistant iProfessor)

3
ACKNOWLEDGEMENT

It igives ius ia igreat isense iof ipleasure ito ipresent ithe ireport iof ithe iB. iTech iProject
iundertaken iduring iB. iTech. iFinal iYear. iWe iowe ispecial idebt iof igratitude ito
iProfessor iAruna iYadav, iDepartment iof iComputer iScience i& iEngineering, iKIET,
iGhaziabad, ifor iher iconstant isupport iand iguidance ithroughout ithe icourse iof iour
iwork. iHer sincerity, ithoroughness iand iperseverance ihave ibeen ia iconstant isource
iof iinspiration ifor ius. iIt iis ionly iher icognizant iefforts ithat iour iendeavors ihave
iseen ilight iof ithe iday.

We ialso itake ithe iopportunity ito iacknowledge ithe icontribution iof i iDr. iVineet
iSharma, iHead iof ithe iDepartment iof iComputer iScience i& iEngineering, iKIET,
iGhaziabad, ifor ihis ifull isupport iand iassistance iduring ithe idevelopment iof ithe
iproject. iWe ialso ido inot ilike ito imiss ithe iopportunity ito iacknowledge ithe
icontribution iof iall ithe ifaculty imembers iof ithe idepartment ifor itheir ikind
iassistance iand icooperation iduring ithe idevelopment iof iour iproject. i

Date :

Signature:

Name: Shomik Goswami / Shraddha Singh / Shivam Shahi

i i i i i i i i

Roll No.: 1502910146 / 1502910147 / 1502910145

i i i i i i

4
 TABLE OF CONTENTS i i

CHAPTER NO. i TITLE PAGE NO.

i

ABSTRACT vii

vii
LIST OF FIGURES
i i i

LIST OF SYMBOLS, ABBREVIATIONS

i i i ix

1. INTRODUCTION 1

1.1 Overview of Codet Application

iii i i i 1

1.2 Advantage of Codet i i 2

1.3 System Environment Analysis

i i 3

1.4 Theoretical Framework i 4

1.4.1 About Node.js i 4

1.4.2 Overview of Node i i 5

1.4.3 Major Features of Node i i i 5

1.4.4 Advantages of Node.js i i 6

1.5 JavaScript and Its History i i i 6

1.5.1 Overview of JavaScript i i 7

1.5.2 Security Features In JavaScript i i i 10

5
 1.6 About Cloud9
i 11

THE SQA
I

2. PLAN 12

2.1 Purpose 12

6
 2.2 Scope 12

2.3 Document Overview i 12

2.4 Tasks 13

2.5 SQA Implementation

i 14

2.6 Documentation 14

2.7 Document Audit i 15

2.8 Software Development Process

i i 15

2.9 Project Reviews i 16

2.10 Testing and Quality Check

ii i i i 16

3. SYSTEM ANALYSISi 17

3.1 System Analysis i 17

3.1.1 Overview of Existing System

i i i 17

3.1.2 Drawbacks of Existing System i i i 17

3.1.3 Overview of Proposed System

i i i 18

3.2 Problem Identification i 18

3.2.1 Problem Recognition i 19

3.2.2 Problem Evaluation and Synthesis

i i i 19

3.2.3 Modelling 20

3.3 Feasibility Study i 20

3.3.1 Economic Feasibility i 21

3.3.2 Technical Feasibility i 19

7
3.3.3 Social Feasibility
i 22

8
 3.3.4 Managerial Feasibility i 22

3.3.5 Financial Feasibility i 22

3.3.6 Cultural Feasibility i 22

3.3.7 Safety Feasibility i 23

3.3.8 Political Feasibility i 23

3.3.9 Environmental Feasibility i 23

3.3.10 Market Feasibility i 24

3.4 Feasibility Areas i 25

3.5 Scope of Feasibility Analysis

i i i 25

4. SOFTWARE REQUIREMENT SPECIFICATION

i i 28

4.1 Overview 28

4.2 Modules of Project i i 30

4.3 Functional Requirements i 32

4.4 Non Functional Requirements

i i 33

4.5 Approach to Develop the System

i i i i 34

4.6 Prototyping Model i 37

5. SYSTEM DESIGN i 38

5.1 Architecture Design i 38

5.2 Process Design i 39

5.2.1 V-Model of Development i i 39

5.3 ER Diagram
i 42

9
5.4 Modular Design
i 43

10
 5.4.1 Modules of Project i i 43

6. DATA DESIGN
i 46

6.1 Data Flow Diagram

i i 46

6.2 Context Flow Diagram i i 47

6.3 Data Flow Diagram

i i 48

6.4 Database Design i 49

6.5 Normalization 51

6.6 User Interface Design

i i 52

7. SYSTEM TESTING i 54

7.1 Test Plan i 54

7.1.1 Test Scripts i 54

7.1.2 Guidelines 55

7.2 System Testing i 55

7.2.1 Unit Testing i 57

7.2.2 Integrated Testing i 58

7.2.3 System Testing i 59

7.2.4 Validation Testing i 60

7.2.5 Module Testing i 61

7.2.6 Display Testing i 61

8. SCREENSHOTS 63

9. FUTURE ENHANCEMENT i 75

11
CONCLUSION 76

REFERENCE 77

12
 ABSTRACT

This iis ia iproject iwith iNode.js. iThis iis ia ipractical iproject ithat iwe ican ieven
imonetize ito icompanies iand ibusinesses. iLet ius ishare iwith iyou ithe iidea ibehind
ithis ione. iIn i2018, iI imet ia ifriend iof imy ifather iwho iwas ian iHR ito ia ismall
icompany. iHe ishared iwith ime iall ithe ipain ihe iand ithe itechnical iteam ileader ihad
ito igo ithrough iwhile ihiring idevelopers iin itheir iorganization. iIt itook ithem ia ilot
iof itime iand imoney iwith iagencies ito ijust iarrange icode itesting. iEventually iwe
icame iup iwith ia isolution iof ionline iinterview itogether iin iwhich ithe ideveloper
iteam ileader iwill iinterview ithe ipotential icandidates iand itest ihis icoding iskills
idirectly iover ithe iInternet iand iin ireal-time.

Thus, ithis iplatform inamed i“Codet” iwas imade ito imeet ithis iever-growing iindustry
idemand. iThis iis iinitially ideployed ilive ion iHeroku. iThe iplatform iis imade ion
iNode.js. iEven ibetter, iyou ican icollaborate iyour icode iwith iother iperson iat ithe
isame itime iin ichat iand iby imaking ivideo icall iin ireal-time. iExpress.js, ia ipopular
iNode.js ilibrary iis ibeing iused ito iwrite icode. iA iNo-SQL idatabase iMongodb iis
ibeing iused ifor ihandling idata itransactions iin ithis iapplication. iAn iAuthentication
isystem iis ialso iintegrated iin ithis iapplication iof iours iof iFacebook iand iE-mail.

It iis ia iperfect iexample iof ipair-programming iand itroubleshooting itogether. iThe

ipurpose iof ithis idocument iis ito ipresent ia idetailed idescription iof ithe iCodet i–
iCode iTogether iApplication. iIt iwill iexplain ithe ipurpose iand ifeatures iof ithe
iapplication, ithe iinterfaces iof ithe iapplication, iwhat ithe iapplication iwill ido, ithe
iconstraints iunder iwhich iit imust ioperate iand ihow ithe iapplication iwill ireact ito
iexternal istimuli.

This idocument iis iintended ifor iboth ithe istakeholders iand ithe idevelopers iof ithe
isystem iand iwill ibe iproposed ito ithe iProject iMentor ifor iits iapproval.

13
 LIST OF FIGURES
i i

CHAPTER

PAGE
NO. TITLE NO.
i

1 Fig 1.1- System Environment Analysis

i i i i 3

3 Fig 3.1- Feasibility Studies

i i i 24

4 Fig 4.1- SRS Validation

i i i 29

4 Fig 4.2- Approach to Develop System

i i i i i 34

4 Fig 4.3- Software Development Process

i i i i 36

Fig 5.2- 0 Level DFD of our Codet

i i i i i i i

5 Application 34

Fig 5.3-
i

5 1 Level DFD of Admin

i i i 35

Fig 5.4-
i

5 1 Level DFD of Editor

i i i 35

Fig 5.5-
i

5 1 Level DFD of Main Task

i i i i 36

6 Fig 6.1- ER Diagram

i i i 38

14
 LIST OF ABBREVIATIONS
i i

S.No. ABBREVIATION DESCRIPTIONS

Code

1. Codet Together

2. SQA Software Quality Assurance

i i

Software Requirements i

3. SRS Specification

4. SDD Software Design Document i i

5. STP Software Testing Plan i i

6. SDLC Software development Life Cycle

i i i

7. NFR Non Functional Requirement

i i

8. DFD Data Flow Diagram

i i

9. ER Entity Relationshipi

10. SQL Structured query language i i

11. URL Uniform Resource Locator

i i

12. GUI Graphical User Interface i i

15
 CHAPTER 1 i

INTRODUCTION

1.1 An Overview of our application – Codet (Code Together)

i i i i i i i i i

At ifirst ia iuser ihas ito iregister iand ifor ithe iregistration ithe imandatory ifields iare
iArea iof iinterest, iName, iEmail, iMobile ino. iThis iapplication iis ia iplatform iin
iwhich iyou ican ishare ior icollaborate iyour icode iwith ithe iother iperson iin ireal-time.
iAlso iyou ican ichat iwith ithe ivideo ior itext ito icommunicate iwith ieach iother iover
ithe iInternet. iThe ibenefit iof ithis iproject iis ito iprovide ia iplatform ifor iall icoders
ito icollaborate iamong ithemselves, iand iexperts ito itest irecruits iduring iF2F itesting.
iThe imain igoal iis ito iset ian ienvironment ifor ia icoder ito iwrite iin iand iobserve
ihim/her icoding iit iin ireal-time iwhen ihe/she iis ibeing iinterviewed iremotely ior iin
iperson.

This iapplication ialso ihas ibuilt-in ivideo, ivoice iand itext ichat ifeatures iso iyou’re
ialways iconnected ito iyour iteam ifrom ianywhere. iThis iapplication iis ispecifically
idesigned ifor icoders ito icollaborate ithrough ithis iapplication ithrough inode.js
imongodb ibackend. iIn ione ito ione ichat isection iyou ican isee iname iof iother ipeers.
iSo ithis iapplication iis ian ioverall ipackage ifor isomeone iwho iwishes ito ihire italents
ior iwork ialongside iyour iteammate. iThe isoftware ibeing iused ifor idevelopment iis
iVisual iStudio iCode. iThis iapplication iuses iMongoDB ifor ikeeping ia irecord iof ithe
idetails iof iall ithe iusers ialong iwith ithe isaved icode isnippets. iThis iapplication ihas
ibeen ideveloped ikeeping iin imind ito iprovide icompanies, iusers ito iinteract iwith
ieach iother ialong iwith iwriting ion ithe icode ieditor iin ithe isame itime.

16
i

1.2. Advantages of Codet Web Application

i i i i i

I. To iinspire ithe istudents iand ihiring imanagers ito ibuild iconfidence iso ithat
ithey ican ienhance itheir iprocesses.

II. i Get i1:1 ilive iprogramming ihelp itailored ito iyou.

III. Enhancement iof iskills iwith ithe iuse iof iour iapp.

IV. Hire iworld iclass idevelopers iwith iease.

V. Can ibe iused ifor imentoring istudents.

VI. Can ibe iused ifor iworking itogether ion iprojects iin iour iCodet ienvironment.

VII. Take iadvantage iof iour ieasiest isetup.

VIII. A iFully iIntegrated iACE, ian iopen isource ieditor iwhich imeans iyou’ll ihave
iyour ifavorite itheme, imulti-cursor i& isyntax ihighlighting.

IX. Having idevelopers iand iyour ico-mates iacross idifferent iplaces iis idifficult,
ibut iCodet iwill ieveryone ito icode itogether iquickly iand ikeep iyour iprojects ion
itrack.

1.3. System Environment Analysis

i i i

Hardware iRequirements

Processor: i512 iMHz iprocessor.RAM: i1 iGB.

Disk iSpace: iNot ias isuch.

Software iRequirements

I. Operating iSystem: iWindows/ iMac/ iLinux

17
II. i Display: iScreen iwith iany idimension iand irresolution

III. i Software i: iNone, iNode.js ifor idevelopment imode

Network irequirements: i

Internet ishould ibe iavailable iall ithe itime.

Figure 1.1- System Environment Analysis

i i i i

1.4. Theoretical Framework

i i

1.4.1. About Node.js:

i i

Node.js iis ian iopen-source iand icross-platform iJavaScript iruntime ienvironment. iIt
iis ia ipopular itool ifor ialmost iany ikind iof iproject!

Node.js iruns ithe iV8 iJavaScript iengine, ithe icore iof iGoogle iChrome, ioutside iof
ithe ibrowser. iNode.js ican ileverage ithe iwork iof ithe iengineers ithat imade i(and

18
icontinue ito imake) ithe iChrome JavaScript iruntime iblazing ifast, iand ithis iallows
iNode.js ito ibenefit ifrom ithe isubstantial iperformance iimprovements iand ithe iJust-
In-Time icompilation ithat iV8 iperforms. iThanks ito ithis, iJavaScript icode irunning iin
iNode.js ican ibecome ivery iperforming.

A iNode.js iapp iis irun iin ia isingle iprocess, iwithout icreating ia inew ithread ifor
ievery irequest. iNode.js iprovides ia iset iof iasynchronous iI/O iprimitives iin iits
istandard ilibrary ithat iprevent iJavaScript icode ifrom iblocking iand igenerally,
ilibraries iin iNode.js iare iwritten iusing inon-blocking iparadigms, imaking iblocking
ibehavior ithe iexception irather ithan ithe inorm.

When iNode.js ineeds ito iperform ian iI/O ioperation, ilike ireading ifrom ithe inetwork,
iaccessing ia idatabase ior ithe ifilesystem, iinstead iof iblocking ithe ithread iand
iwasting iCPU icycles iwaiting, iNode.js iwill iresume ithe ioperations iwhen ithe
iresponse icomes iback.

This iallows iNode.js ito ihandle ithousands iof iconcurrent iconnections iwith ia isingle
iserver iwithout iintroducing ithe iburden iof imanaging ithread iconcurrency, iwhich
icould ibe ia isignificant isource iof ibugs.

Node.js ihas ia iunique iadvantage ibecause imillions iof ifrontend idevelopers ithat
iwrite iJavaScript ifor ithe ibrowser iare inow iable ito iwrite ithe iserver-side icode iin
iaddition ito ithe iclient-side icode iwithout ithe ineed ito ilearn ia icompletely idifferent
ilanguage.In iNode.js ithe inew iECMAScript istandards ican ibe iused iwithout
iproblems, ias iyou idon't ihave ito iwait ifor iall iyour iusers ito iupdate itheir ibrowsers
i- iyou iare iin icharge iof ideciding iwhich iECMAScript iversion ito iuse iby ichanging
ithe i

Node.js iversion, iand iyou ican ialso ienable ispecific iexperimental ifeatures iby
irunning iNode.js iwith iflags.

19
1.4.2. Overview of Node
i i i

As ian iasynchronous ievent idriven iJavaScript iruntime, iNode iis idesigned ito ibuild
iscalable inetwork iapplications. iNode.js i(Node) iis ian iopen isource idevelopment
iplatform ifor iexecuting iJavaScript icode iserver-side. iNode iis iuseful ifor ideveloping
iapplications ithat irequire ia ipersistent iconnection ifrom ithe ibrowser ito ithe iserver
iand iis ioften iused ifor ireal-time iapplications isuch ias ichat, inews ifeeds iand iweb
ipush inotifications.

1.4.3. iMajor iFeatures iof iNode.js

● It iis iasynchronous iand ievent iDriven iAll iAPIs iof iNode.js ilibrary iare
iasynchronous, ithat iis, inon-blocking.

● Super iFast iBeing ibuilt ion iGoogle iChrome’s iV8 iJavaScript iEngine,
iNode.js iis isuper iefficient iand iquick iin icode iexecution.

● Single iThreaded ibut iHighly iScalable iNode.js iuses ia isingle ithreaded

imodel iwith ievent ilooping. iEvent imechanism ihelps ithe iserver ito irespond
iin ia inon-blocking iway iand imakes ithe iserver ihighly iscalable ias iopposed
ito itraditional iservers ilike iApache iwhich icreate ilimited ithreads ito ihandle
irequests.

● Optimized igraphics ipowered iby ia icustom i2D igraphics ilibrary; i3D

igraphics ibased

● No iBuffering iNode.js iapplications inever ibuffer iany idata. iThese

iapplications isimply ioutput ithe idata iin ichunks.

20
 ● Media isupport ifor icommon iaudio, ivideo, iand istill iimage iformats
i(MPEG4,H.264, iMP3, iAAC, iAMR, iJPG, iPNG, iGIF)

● GSM iTelephony i(hardware idependent)

● Bluetooth, iEDGE, i3G, iand iWiFi i(hardware idependent) i, iCamera, iGPS,

icompass, iand iaccelerometer i(hardware idependent)

1.4.4 Advantages of Node.js

i i i

I. One iof ithe ikey iadvantages iof iNode.js iis ithat idevelopers ifind iit ieasy ito
iscale ithe iapplications iin ihorizontal ias iwell ias ithe ivertical idirections. iThe
iapplications ican ibe iscaled iin ihorizontal imanner iby ithe iaddition iof
iadditional inodes ito ithe iexisting isystem. iMoreover, iNode.js ialso ioffers iyou
ithe ioption iof iadding iextra iresources ito ithe isingle inodes iduring ithe
ivertical iscaling iof ithe iapplication. iSo, iit iis ihighly iscalable iand iprovides
ibetter ioption ithan iother iJavaScript iservers.

II. i Since iJavaScript iis ione iof ithe imost ipopular iprogramming ilanguages, imost
iof ithe ifront-end idevelopers ihave ia igood igrasp iover iit. iIt ibecomes imuch
ieasier ifor ithem ito istart iusing ithe iNode.js iat ithe ibackend. iIt iis ieasier ito
ilearn iNode.js iand iconsumes iless itime ito iwork iwith iit. i

III. i Node.js ihas ibeen iregarded ias ia ifull-stack iJavaScript ifor iserving iboth ithe
iclient iand ithe iserver-side iapplications. iTherefore, ithe iadvantage iis ithat iyou
idon’t ihave ito ihire iseparate idevelopers ifor ibackend ias iwell ias ithe ifront-
end idevelopment. iIt isaves iboth iyour ivaluable imoney iand itime.

21
1.5 Javascript and its History
i i i i

JavaScript iwas icreated iby iBrendan iEich iin i1995 iduring ihis itime iat iNetscape
iCommunications. iIt iwas iinspired iby iJava, iScheme iand iSelf. iNetscape, ifor ia
itime, imade ithe ibest ibrowser iin ithe iworld iand ienjoyed imarket idominance.

In ilate i1995, iwhen iMicrosoft icottoned-on ito ithe icompetitive ithreat ithe iWeb
iposed, ithe iInternet iExplorer iproject iwas istarted iin ian iall-out iattempt ito iwrestle
icontrol iof ithe iemerging iplatform ifrom iNetscape.

In iso idoing iMicrosoft ibecame ia imortal ithreat, icompelling iNetscape ito irespond.
iFirst, ithey istarted ia istandardization iprocess ito iprevent iMicrosoft igaining icontrol
iof ithe iJavaScript ilanguage. iSecond, ithey ipartnered iwith iSun ito ileverage itheir
ishared iinterest iin ibreaking ithe iMicrosoft imonopoly.

Sun ibegan idevelopment iof iJava iin i1990 iin ian iattempt ito iwrite ia ilanguage ifor
i“smart iappliances”. iThis iapproach ifloundered iand iin i1994, iSun iregrouped iand
iset isights ion ithe iWeb ias ithe idelivery iplatform iof ichoice.

So ithe iNetscape/Sun ipartnership imeant iSun iacquired ithe iuse iof ia icompetitive
ibrowser iand ia idelivery isystem ifor itheir istrategic itechnology.

Netscape, ion ithe iother ihand ifound ia ipowerful ially iagainst iMicrosoft. iThey ialso
iaimed ito iout-manoeuvre iMicrosoft iby ibeing ithe iofficial ibrowser iof ithe ihighly
ianticipated iplatform ithat iwas iJava.

Brendan iEich ihas isaid ithat iwith iSun ion iboard, ithey idecided ito isurf ithe itidal
iwave iof ihype isurrounding iJava iand iposition iJavaScript ias ithe icompanion
ilanguage ito iJava, iin ithe isame iway iVisual iBasic iwas ito iC++. iSo ithe iname iwas
ia istraightforward imarketing iploy ito igain iacceptance. i

22
1.5.1 Overview of Javascript
i i i

JavaScript iis imost icommonly iused ias ia iclient iside iscripting ilanguage. iThis
imeans ithat iJavaScript icode iis iwritten iinto ian iHTML ipage. iWhen ia iuser irequests
ian iHTML ipage iwith iJavaScript iin iit, ithe iscript iis isent ito ithe ibrowser iand iit's
iup ito ithe ibrowser ito ido isomething iwith iit.

The ifact ithat ithe iscript iis iin ithe iHTML ipage imeans ithat iyour iscripts ican ibe
iseen iand icopied iby iwhoever iviews iyour ipage. iNonetheless, ito imy imind ithis
iopenness iis ia igreat iadvantage, ibecause ithe iflip iside iis ithat iyou ican iview, istudy
iand iuse iany iJavaScript iyou iencounter ion ithe iWWW.

JavaScript ican ibe iused iin iother icontexts ithan ia iWeb ibrowser. iNetscape icreated
iserver-side iJavaScript ias ia iCGI-language ithat ican ido iroughly ithe isame ias iPerl
ior iASP. iThere iis ino ireason iwhy iJavaScript icouldn’t ibe iused ito iwrite ireal,
icomplex iprograms. iHowever, ithis isite iexclusively ideals iwith ithe iuse iof
iJavaScript iin iweb ibrowsers.

JavaScript iis inot ia iprogramming ilanguage iin istrict isense. iInstead, iit iis ia iscripting
ilanguage ibecause iit iuses ithe ibrowser ito ido ithe idirty iwork. iIf iyou icommand ian
iimage ito ibe ireplaced iby ianother ione,JavaScript itells ithe ibrowser ito i

go ido iit. iBecause ithe ibrowser iactually idoes ithe iwork, iyou ionly ineed ito ipull
isome istrings iby iwriting isome irelatively ieasy ilines iof icode. iThat’s iwhat imakes
iJavaScript ian ieasy ilanguage ito istart iwith.

But idon’t ibe ifooled iby isome ibeginner’s iluck: iJavaScript ican ibe ipretty idifficult,
itoo. iFirst iof iall, idespite iits isimple iappearance iit iis ia ifull ifledged iprogramming
ilanguage: iit iis ipossible ito iwrite iquite icomplex iprograms iin iJavaScript. iThis iis
irarely inecessary iwhen idealing iwith iweb ipages, ibut iit iis ipossible. iThis imeans
ithat ithere iare isome icomplex iprogramming istructures ithat iyou’ll ionly iunderstand
iafter iprotracted istudies.

23
Secondly, iand imore iimportantly, ithere iare ithe ibrowser idifferences. iThough
imodern iweb ibrowsers iall isupport iJavaScript, ithere iis ino isacred ilaw ithat isays
ithey ishould isupport iexactly ithe isame iJavaScript. iA ilarge ipart iof ithis isite iis
idevoted ito iexploring iand iexplaining ithese ibrowser idifferences iand ifinding iways
ito icope iwith ithem.

1.5.2 Security Features in Javascript & Node.js

i i i i i i

Since iits irelease, ithere ihave ibeen iseveral iJavaScript isecurity iissues ithat ihave
igained iwidespread iattention. iFor ione, ithe iway iJavaScript iinteracts iwith ithe iDOM
iposes ia irisk ifor iend iusers iby ienabling imalicious iactors ito ideliver iscripts iover
ithe iweb iand irun ithem ion iclient icomputers. iThere iare itwo imeasures ithat ican ibe
itaken ito icontain ithis iJavaScript isecurity irisk. iFirst iis isandboxing, ior irunning
iscripts iseparately iso ithat ithey ican ionly iaccess icertain iresources iand iperform
ispecific itasks. iThe isecond imeasure iis iimplementing ithe isame iorigin ipolicy,
iwhich iprevents iscripts ifrom ione isite ifrom iaccessing idata ithat iis iused iby iscripts
ifrom iother isites. iMany iJavaScript isecurity ivulnerabilities iare ithe iresult iof
ibrowser iauthors ifailing ito itake ithese imeasures ito icontain iDOM-based iJavaScript
isecurity irisks. i

As iof itoday, iNode.js iand iits icore icontributors imaintain imany idifferent ichannels i

to iaddress ithe isecurity iof ithe iNode.js iproject iand ithe isecurity iof iits’ iusers.

In i2016, iat iNode.js iInteractive iin iAustin, ithe iSecurity iWorking iGroup iwas
iformed, iaddressing ithe ineed ifor ia iworking igroup ifocusing ion isecurity. iIt iis
imainly iresponsible ifor idefining iand imaintaining isecurity ipolicies iand iprocedures

24
ifor ithe icore iNode.js iproject iand iother iprojects imaintained iby ithe iNode.js
iFoundation.

The iSecurity iWorking iGroup ialso ihelps iwith:

● the iNode.js iSecurity iproject ito ibring ivulnerability idata iinto ithe
iFoundation,

● review iand irecommend iprocesses ifor ihandling iof isecurity ireports,

● recommend isecurity iimprovements ifor ithe icore iNode.js iproject,

● facilitate iand ipromote ithe iexpansion iof ia ihealthy isecurity iservice iand
iproduct iprovider iecosystem ivulnerabilities.

1.6. Overview Of Cloud9 (an AWS IDE Product)

i i i i i i i

IDE istands ifor iIntegrated iDevelopment iEnvironment. iWith ithe iincrease iin ithe
icomplexity iof isoftware ithe iIDEs iget iupgraded ior iwe ican isay imore iintelligent.

AWS iCloud9 icontains ia icollection iof itools ithat iyou iuse ito icode, ibuild, irun,
itest, idebug, iand irelease isoftware iin ithe icloud. iTo iwork iwith ithese itools, iyou
iuse ithe iAWS iCloud9 iintegrated idevelopment ienvironment, ior iIDE.

You iaccess ithe iAWS iCloud9 iIDE ithrough ia iweb ibrowser. iThe iIDE ioffers ia
irich icode-editing iexperience iwith isupport ifor iseveral iprogramming ilanguages
iand iruntime idebuggers, ias iwell ias ia ibuilt-in iterminal.

You ican iconfigure ithe iIDE ito iyour ipreferences. iYou ican iswitch icolor ithemes,
ibind ishortcut ikeys, ienable iprogramming ilanguage-specific isyntax icoloring iand
icode iformatting, iand imore.

25
You iuse ithe iAWS iCloud9 iIDE, irunning iin ia iweb ibrowser ion iyour ilocal
icomputer, ito iinteract iwith iyour ienvironment. iA icloud icompute iinstance i(for
iexample ian iAmazon iEC2 iinstance) ior iyour iown iserver iconnects ito ithe
ienvironment. iAn ienvironment iis ia iplace iwhere iyou istore iyour iproject's ifiles
iand iwhere iyou irun ithe itools ito idevelop iyour iapps.

You iuse ithe iAWS iCloud9 iIDE ito iwork iwith ifiles iin ithe ienvironment. iYou
ican:

● Store ithese ifiles ilocally ion ithe iinstance ior iserver.

● Clone ia iremote icode irepository—such ias ia irepo iin iAWS iCode

iCommit—into iyour ienvironment.

● Work iwith ia icombination iof ilocal iand icloned ifiles iin ithe ienvironment.

In ithe ibackground, iyou ican iinstruct iAWS iCloud9 ito ihave iAmazon iEC2 icreate
ian iAmazon iEC2 iinstance iand ithen iconnect ithe ienvironment ito ithe inewly-
created iinstance. iWe icall ithis itype iof isetup ian iEC2 ienvironment. iYou ican
ialso iinstruct iAWS iCloud9 ito iconnect ian ienvironment ito ian iexisting icloud
icompute iinstance ior iyour iown iserver. iWe icall ithis itype iof isetup ian iSSH
ienvironment.

26
 CHAPTER 2 i

THE SQA PLAN

i i

2.1. Purpose
i

2.2. Scope
i

The ipurpose iof ithis iplan iis ito idefine ithe i― iCodet iapplication iSoftware iQuality
iAssurance i(SQA) iorganization, iSQA itasks iand iresponsibilities; iprovide ireference
idocuments iand iguidelines ito iperform ithe iSQA iactivities; iprovide ithe istandards,
ipractices iand iconventions iused iin icarrying iout iSQA iactivities; iand iprovide ithe
itools, itechniques, iand imethodologies ito isupport iSQA iactivities, iand iSQA
ireporting.

This idocument ihas ia iscope ito idefine iall iprocedures, itechniques iand itools ito ibe
iused ifor iQuality iAssurance iof iour iCodet iApplication. iThis iplan:

● It iidentifies ithe iSQA iresponsibilities iof ithe iApplication ideveloper iand ithe

SQA iconsultant.

● It ilists iout ithe iactivities, iprocesses, iand iwork iproducts ithat ithe iSQA
iconsultant iwill ireview iand iaudit.

● It ihelp iidentify ithe iSQA iwork iproducts.

27
2.3. Document Overview
i i

The irest iof ithe idocument iis iorganized ias ifollows:

● Management: iIt idescribes ieach imajor ielement/people iof ithe iorganization

iand idefines ithe iSQA itasks iand itheir irelationships.

● Documentation: iIt ihelps iin ithe iidentification iof ithe idocuments irelated ito
idevelopment, iverification, ivalidation, iuse iand imaintenance iof i iour iCodet
iApplication

● SQAP iRequirements: iThe iSQA ireview, ireporting, iand iauditing iprocedures

i i i i iused ito iensure ithat isoftware ideliverables iare ideveloped iin iaccordance iwith i
this iplan iand ithe iproject‘s irequirements iare idefined iunder ithis isection.

● Management iThe imanagement iorganizational istructure, iits iroles iand

iresponsibilities, iand ithe isoftware iquality itasks ito ibe iperformed iare idefined iunder
ithis isection.

● Organization iEfforts ifor ithis iapplication iare isupported iby inumber iof
ientities, iorganizations iand ipersons. iThis itool iis ideveloped ias ipart iof ipartial
ifulfillment iof irequirements ifor iBachelors iin iComputer iApplications idegree. iThe
idevelopers iare iresponsible ifor iactivities ito ireview ithe iproduct‘s iusability,
iefficiency, ireliability, iand iaccuracy. iThe iclient iwill iconduct iinspections, ireviews,
iand iwalkthrough ion ia iregular ibasis. iSpecifications iand isuggestions iprovided iby
iclient iare iused iin iplaces iwhere iquality idecisions ineed ito ioverride idecisions iof
idevelopment ischedule.

28
2.4. Tasks
i

The itasks iperformed iare ias iunder:

● Development iof ithe irequirement ispecification iand icost iestimation ifor ithe
iApplication.

● Development iof ithe idesign iplan iand itest iplan ifor itesting ithe iApplication.

● Development iand itesting iof ithe iapplication iand ideliver ithe iapplication
ialong iwith ithe inecessary idocumentation.

● A iformal ipresentation ito ithe iclient ishould ibe igiven ion icompletion iof ithe
ianalysis, idesign iand itesting iphases. iThe iclient ireviews ithe iwork iand
iprovides ifeedback/suggestions.

● Planning, icoordinating, itesting iand iassessing iall iaspects iof iquality iissues.

The iresponsibilities iof ithe iclient iare ito:

● Review ithe iwork idone.

● Provide ifeedback iand iadvice.

29
2.5. SQA Implementation
i i

Quality iassurance iwill ibe iimplemented ithroughout iApplication idevelopment ilife

icycles iof ithe itool‘s idevelopment iprocess, iuntil ithe irelease iof ithe isoftware
iproduct. iThe ifollowing iare ithe iquality iassurance itasks ifor ieach iphase iof ithe
iApplication idevelopment:

● Requirements iphase: iWhen ithe iSRS iis ideveloped, iit ihas ito ibe iensured
ithat iit imakes iclear ithe iproposed ifunctionality iof ithe iApplication iand ito
ikeep irefining ithe iSRS iuntil ithe irequirements iare iclearly iunderstood.

● Specification iand iDesign iphase: iDue ito ithe igreat iimportance iof iaccuracy
iand icompleteness iin ithese idocuments, iweekly imeeting iand ireviews ishall
ibe iconducted ibetween ithe ideveloper iand ithe iclient ito iidentify iany idefects
iand irectify ithem.

● Implementation iphase: iThe ideveloper ishall ido icode ireviews iwhen ithe
iconstruction iphase iof ithe iApplication ibegins.

● Software itesting iphase: iThe ideveloper ishall itest ieach icase. iThe ifinal
iApplication ishall ibe iverified iwith ithe ifunctionality iof ithe iApplication ias
ispecified iin ithe iSoftware iRequirements iSpecification i(SRS) ifor ithe itool.

2.6. Documentation
i

In iaddition ito ithis idocument, ithe iessential idocumentation iwill iinclude:

30
The iSoftware iRequirements iSpecification i(SRS), iwhich

● Prescribes ieach iof ithe iessential irequirements iof ithe isoftware

● Verifies icompleteness iof ieach irequirement iby ia iprescribed imethod

● Provides ifacility iof itraceability iof irequirements ispecification ito iApplication

i delivery.

● Gives iestimates iof ithe icost/effort ifor ideveloping ithe iproduct iincluding ia i
project iplan.

● The iSoftware iDesign iDocument i(SDD)

● Depicts ihow ithe isoftware iwill ibe istructured

● It igives ithe iDescription iof ithe ivarious icomponents iand isub-components iof
i the iApplication idesign, iincluding ivarious ipackages iand iframeworks.

● The iessential iclasses iare iprovided ito iobject imodel ithat iwould imake iup ithe
i product.

● It iprovides ia isample iinteraction idiagram, ishowing ithe ikey iinteractions iin

ithe i application.

● Software iTest iPlan: iIt idescribes ithe itest icases, itest ienvironment, ietc., ithat i
will ibe iemployed ito itest ithe iApplication.

31
2.7. Document Audit
i i

Quality iAssurance iDocument ifor ithis iApplication iwill iinclude iat ileast ione ireview
iof iall icurrent iwork iproducts iin ieach istage iof idevelopment i(Requirement, iDesign,
iand iImplementation). iThe ireviews iwill iassure ithat ithe iestablished iApplication
idevelopment iprocesses iand iprocedures iare ibeing ifollowed iefficiently, iand irisks ito
ithe icurrent idevelopment iplan iare iidentified iand irectified.

The ireview iprocess iincludes:

● At ithe iend iof ieach idevelopment iphase i(Requirement, iDesign iand

iImplementation) ia iformal ipresentation iwill ibe idone.

● A imanagerial ireview iby ithe iclient iperiodically ito iensure ithe iwork
igenerated iis iin icompliance iwith iApplication irequirements.

● After ieach ipresentation ireviews iby ithe iclient iis imust.

2.8. Software Development Process

i i i

The iCodet iApplication idevelopment iprocess iwill ibe icompleted iin ithree istages:

I. iRequirements iphase,

iII. i i i i i iDesign iphase

32
 III. i i i i iImplementation iand itesting iphase

The iclient iwill ireview ithe ideliverable idocuments, iduring ieach iphase. iThe
ideveloper iwill iincorporate imodifications isuggested iby ithe iclient. iThis iwill iensure
iquality iof ithe isoftware iproduct.

2.9. Project Reviews

i i

The iclient iwill iperform ia ireview iat ithe i3 istages iof ithe iproject ias idescribed iin
ithe isection iabove. iThis ireview iwill idetermine iwhether ithe irequirements ihave
ibeen imet ifor ithe ideliverable, icheck ithat ithe iproduct imeets ithe irequirements,
iensure ithat ithe iSQA iplan ihas ibeen iadhered ito, iverify ithe iperformance iof ithe
isoftware iand iensure ithat iacceptance itesting iis icarried iout. iA idesign ichecklist
iwill ibe iused iand ithe ideveloper iwill icheck ito isee iwhether ithe idesign imeets ithe
ichecklist icriteria.

2.10. Testing And Quality Check

i i i i

Testing iof ithe iapplication iis icarried iout iin iaccordance iwith ithe iSoftware iTesting
iPlan i(STP). iTesting idocumentation iwill ibe isufficient ito idescribe iand idemonstrate
ithat itesting iobjectives iand isoftware irequirements ihave ibeen imet. iTest iresults iwill
ibe iprovided iin ithe idocumentation iand iis idiscussed iin ithe ifinal iphase iof ithe
iproject icompletion.

33
 CHAPTER 3 i

SYSTEM ANALYSIS
i

3.1. System Analysis

i i

System ianalysis iis ithe iprocess iof igathering iand iinterpreting ifacts, idiagnosing
iproblems iand iusing ithe ifacts ito iimprove ithe isystem. iSystem ispecifies iwhat
isystem ishould ido. iA isystem iis ia iset iof icomponents ithat iinteract ito iaccomplish
isome ipurpose.

● Identifying ithe idrawback iof ithe iexisting isystem

● Identify ithe ineed ifor iconversion

● Perform ifeasibility istudy

● Identify ihardware, isoftware iand idatabase irequirements

● Create ia isystem idefinition ithat iforms ithe ifoundation ifor isubsequent iwork

34
3.1.1. OVERVIEW OF EXISTING SYSTEM
i i i i

The iexisting ihiring iand icode isharing iapp ilike ihackerearth iand ihackerrank iis ifor
icoding ion ione isystem. iIt idoes inot ihelp ithe ipeople ito icommunicate itheir
iproblems iwhen icoding itogether. iThe iexisting iapp ialso idoesn’t ihave ithe ifacility
ito icommunicate iwith iexperts iregarding ithe iparticular isubject’s iproblem.

3.1.2. DRAWBACKS OF THE EXISTING SYSTEM

i i i i i

● There iis ino ichatting ifeature.

● There iare ifew iapps ilike icodementor.io iwhich isomewhat ifocuses ion ipair
iprogramming.

● Experts ichatting iare ialso inot iavailable iin ithe iexisting iapplication.
iThey iare inot ieasy ito iuse.

3.1.3. OVERVIEW OF PROPOSED SYSTEM

i i i i

Eventually iwe icame iup iwith ia isolution iof ionline iinterview itogether iin iwhich ithe
ideveloper iteam ileader iwill iinterview ithe ipotential icandidates iand itest ihis icoding
iskills idirectly iover ithe iInternet iand iin ireal-time.

Thus, ithis iplatform inamed i“Codet” iwas imade ito imeet ithis iever-growing iindustry
idemand. iThis iis iinitially ideployed ilive ion iHeroku. iThe iplatform iis imade ion
iNode.js. iEven ibetter, iyou ican icollaborate iyour icode iwith iother iperson iat ithe
isame itime iin ichat iand iby imaking ivideo icall iin ireal-time. iExpress.js, ia ipopular

35
iNode.js ilibrary iis ibeing iused ito iwrite icode. iA iNo-SQL idatabase iMongodb iis
ibeing iused ifor ihandling idata itransactions iin ithis iapplication. iAn iAuthentication
isystem iis ialso iintegrated iin ithis iapplication iof iours iof iFacebook iand iE-mail.

It iis ia iperfect iexample iof ipair-programming iand itroubleshooting itogether. iThe

ibasic iproperties iof ithe iproposed isystem iare ias ifollows:

I. This iapp iUI iis ivery isimple ito iuse.

II. It ihas iseparate iUI ifor ivideo ichat iwhen icoding.

III. The iproposed isystem ihas idiscussion ichat isystem iwhile iyou’re icoding.

IV. We ican idiscuss ithe irelate iproblem ithrough ione ito ione ichat iand imany
ito ione ialso.

V. Less icomplexity iand iless idistraction.

3.2. Problem Identification

i i

Requirement ianalysis iis ithe isoftware iengineering itask ithat ibridges ithe igap
ibetween isystem ilevel irequirement iengineering iand isoftware idesign. iSoftware
irequirement ianalysis iis idivided iinto ithree:

I. Problem iRecognition

II. Problem iEvaluation iand iSynthesis

III. Modelling

36
3.2.1. Problem Recognition
i i

The imain igoal iof ithe iproblem irecognition iis ithe irecognition iof ithe ibasic
iproblems ias iperceived iby ithe iusers. iThe iexisting isystem iis iinefficient iwhen
icompared iwith ithe iproposed isystem. iIn ithe iexisting isystem ithere iis inot imuch
istudent ispecific iApplications iwith iall ithe ifeatures iavailable iat ione iplace. iThe
iproposed isystem iprovides iall ithe ifeatures iat ione iplace. iThe iproposed isystem iis
idesigned iwith ifocus ion istudents. iIn ithe iexisting isystem ithere iare ifew
iapplications ithat iprovide isome iof ithe ifeatures iof ithe iproposed isystem ibut iit’s
iUI iis itoo icomplex, iKeeping istudents iin imind ia ivery isimple iUI iis ideveloped
iso ithat iit iis istudent ifriendly.

3.2.2. Problem Evaluation and Synthesis

i i i i

In ithe iproblem ievaluation iand isynthesis ithe isoftware iengineer imust idefine iall
iexternally iobservable idata iobjects, ievaluate ithe iflow iand icontent iof
iinformation, idefine iand ielaborate iall isoftware ifunctions, iunderstand isoftware
ibehaviour ithat iaffects ithe isystem, iestablish isystem iinterface icharacteristics, iand
iuncover iadditional idesign iconstraints. iEach iof ithese itasks iserves ito idescribe
ithe iproblem iso ithat ian ioverall isolution imay ibe isynthesized.

The iProposed isystem ihas ibeen ideveloped ifor ithe ipresent irequirements, iwhich iis
iadvantageous iover ithe iexisting isystem. iHere ithe iapplication iis idesigned iwith
ifocus ion istudents iand iits iUI iis isimple iand iuser ifriendly.

3.2.3. Modelling
i

During isoftware irequirements ianalysis, iwe icreate imodels iof iit ito ibe ibuilt ito
igain ibetter iunderstanding iof ithe iactual ilogical ientities i(functions iand isub

37
ifunctions) ito ibe ibuilt. iThe ifollowing iare ithe iroles iof imodels iin irequirements
ianalysis.

● The imodel ihelps ianalyst ito iunderstand iinformation, ifunction, iand i

behaviour iof ithe isystem

● The imodel ibecomes ithe imain ireference ifor ireview ito idetermine i
completeness, iconsistency iand iaccuracy iof ithe ispecification.

● The imodel ibecomes ithe ifoundation ifor idesign.

3.3. Feasibility Study

i i

The ifeasibility iof ia iproject ican ibe iascertained iin iterms iof itechnical ifactors,
ieconomic ifactors, ior iboth. iA ifeasibility istudy iis idocumented iwith ia ireport
ishowing iall ithe iramifications iof ithe iproject. iIn iproject ifinance, ithe ipre-
financing iwork i(sometimes ireferred ito ias idue idiligence) iis ito imake isure ithere
iis ino i"dry irot" iin ithe iproject iand ito iidentify iproject irisks iensuring ithey ican
ibe imitigated iand imanaged iin iaddition ito iascertaining i"debt iservice" icapability.

Feasibility iis ia imeasure iof ihow ibeneficial ithe idevelopment iof ithe iinformation
isystem iwill ibe ito ian iorganization. iThis iis idone iby iinvestigating ithe iexisting
isystem iproposal iaccording ito iits iworkability, iimpact ion ithe iorganization, iability
ito imeet iuser ineeds, iand ieffective iuse iof iresources.

Few ikey iconsiderations iare iinvolved iin ithe ifeasibility ianalysis: ieconomic,
itechnical iand isocial ietc.

38
3.3.1. Economic Feasibility:
i i

Economic ianalysis iis ithe imost ifrequently iused imethod ifor ievaluating ithe
ieffectiveness iof ia iproposed isystem. iIt iis imore icommonly iknown ias icost
ibenefit ianalysis; ithe iprocedure ito idetermine ithe ibenefits iand isaving, ithat iare
iexpected ifrom ia idecision iis imade ito idoing iand iimplement ithe isystem.
iOtherwise imake ialterations iin ithe iproposed isystem. iCost iassociated iwith ithe
idevelopment iof icomputer-based isystems iis ias ifollows.

I. Procurement icosts isuch ias iconsultation, iequipment ipurchase, iinstallation,

ifurnishing ithe isize ietc

II. Start-up icosts, iuser ioperating isystem icost, ipersonal isearch icost ietc. i i i
Project irelated icosts isuch ias isoftware ipurchase, itraining ipersonnel,
idata i collection, idocuments ipreparation icosts ietc.

iIII. Ongoing icosts isuch ias ihardware, isoftware imaintenance, irental,

idepreciation iof ihardware icosts ietc.

3.3.2. Technical Feasibility:

i i

In iexamining iTechnical ifeasibility iof ithe isystem, iore iimportance iis igiven ito ithe
ihardware iinteraction ipart iof ithe isystem. iThe iassessments iof itechnical ifeasibility
icenters ion ithe iexisting isystem iand ito iwhat iextent iit ican isupport ithe iproposed

39
iaddition. iThis iwas ibased ion ian ioutline idesign iof isystem irequirements iin iturns
iof iinputs, ifiles iprograms, iprocedures iand istaff. iIt iinvolves ifinancial
iconsiderations ito iaccommodate itechnical ienhancements. iThe ipropose isystem ihas
ithree-tier iarchitecture iconsisting iof ifirebase ias ithe idatabase, iApplication iServer
ias ifirebase ias ithe imiddle itier iand iInternet ideveloper isuite iandroid iStudio ias
ithe idevelopment itool. iThe isoftware iis ivery iuser ifriendly ifor iboth idevelopers
iand iend iusers.

3.3.3. Social feasibility:

i i

People iare iinherently iresistant ito ichange iand imobiles ihave ibeen iknown ito
ifacilitate ichange. iAn iestimate ishould ibe imade iabout ithe ireaction iof ithe iuser
istaff itowards ithe idevelopment iof ia icomputerized isystem. iComputer iinstallations
ihave isomething ito ido iwith iturnover, itransfers iand ichanges iin ijob istatus. iThe
iintroduction iof ia icandidate isystem irequires ispecial ieffort ito ieducate, isell iand
itrain ithe istaff ifor iconducting ithe ibusiness. iThe iproposed isoftware iis idesigned
isuch ithat ionly ipersons ican iaccess iit ihaving iandroid imobile iand ia iperson iwith
isome icomputer iknowledge ican iinteract iwith ithe isystem ifreely. iComputer
iilliterate ipeople irequire itraining ifor iefficient iuse iof ithe isoftware.

3.3.4. Managerial Feasibility:

i i

Managerial ifeasibility iinvolves ithe icapability iof ithe iinfrastructure iof ia iprocess
ito iachieve iand isustain iprocess iimprovement. iManagement isupport, iemployee
iinvolvement, iand icommitment iare ikey ielements irequired ito iascertain imanagerial
ifeasibility.

40
3.3.5. Financial Feasibility
i i

Financial ifeasibility ishould ibe idistinguished ifrom ieconomic ifeasibility. iFinancial

ifeasibility iinvolves ithe icapability iof ithe iproject iorganization ito iraise ithe
iappropriate ifunds ineeded ito iimplement ithe iproposed iproject. iProject ifinancing
ican ibe ia imajor iobstacle iin ilarge imulti-party iprojects ibecause iof ithe ilevel iof
icapital irequired. iLoan iavailability, icredit iworthiness, iequity, iand iloan ischedule
iare iimportant iaspects iof ifinancial ifeasibility ianalysis.

3.3.6. Cultural Feasibility:

i i

Cultural ifeasibility ideals iwith ithe icompatibility iof ithe iproposed iproject iwith ithe
icultural isetup iof ithe iproject ienvironment. iIn ilabor-intensive iprojects, iplanned
ifunctions imust ibe iintegrated iwith ithe ilocal icultural ipractices iand ibeliefs. iFor
iexample, ievery ione iusing imobile iso iit iis iculturally ifeasible.

3.3.7. Safety Feasibility:

i i

Safety ifeasibility iis ianother iimportant iaspect ithat ishould ibe iconsidered iin
iproject iplanning. iSafety ifeasibility irefers ito ian ianalysis iof iwhether ithe iproject
iis icapable iof ibeing iimplemented iand ioperated isafely iwith iminimal iadverse
ieffects ion ithe ienvironment. iUnfortunately, ienvironmental iimpact iassessment iis
ioften inot iadequately iaddressed iin icomplex iprojects. iAs ian iexample, ithe iNorth
iAmerican iFree iTrade iAgreement i(NAFTA) ibetween ithe iU.S., iCanada, iand
iMexico iwas itemporarily isuspended iin i1993 ibecause iof ithe ilegal iconsideration
iof ithe ipotential ienvironmental iimpacts iof ithe iprojects ito ibe iundertaken iunder
ithe iagreement.

41
3.3.8. Political Feasibility:
i i

A ipolitically ifeasible iproject imay ibe ireferred ito ias ia i"politically icorrect
iproject." iPolitical iconsiderations ioften idictate idirection ifor ia iproposed iproject.
iThis iis iparticularly itrue ifor ilarge iprojects iwith inational ivisibility ithat imay
ihave isignificant igovernment iinputs iand ipolitical iimplications. iFor iexample,
ipolitical inecessity imay ibe ia isource iof isupport ifor ia iproject iregardless iof ithe
iproject's imerits. iOn ithe iother ihand, iworthy iprojects imay iface iinsurmountable
iopposition isimply ibecause iof ipolitical ifactors. iPolitical ifeasibility ianalysis
irequires ian ievaluation iof ithe icompatibility iof iproject igoals iwith ithe iprevailing
igoals iof ithe ipolitical isystem.

3.3.9. Environmental Feasibility:

i i

Often ia ikiller iof iprojects ithrough ilong, idrawn-out iapproval iprocesses iand
ioutright iactive iopposition iby ithose iclaiming ienvironmental iconcerns. iThis iis ian
iaspect iworthy iof ireal iattention iin ithe ivery iearly istages iof ia iproject. iConcern
imust ibe ishown iand iaction imust ibe itaken ito iaddress iany iand iall ienvironmental
iconcerns iraised ior ianticipated. iA iperfect iexample iwas ithe irecent iattempt iby
iDisney ito ibuild ia itheme ipark iin iVirginia. iAfter ia ilot iof ifunds iand iefforts,
iDisney icould inot iovercome ithe ilocal iopposition ito ithe ienvironmental iimpact
ithat ithe iDisney iproject iwould ihave ion ithe ihistoric iManassas ibattleground iarea.

42
3.3.10. Market Feasibility:
i i

Another iconcern iis imarket ivariability iand iimpact ion ithe iproject. iThis iarea
ishould inot ibe iconfused iwith ithe iEconomic iFeasibility. iThe imarket ineeds
ianalysis ito iview ithe ipotential iimpacts iof imarket idemand, icompetitive iactivities,
ietc. iand i"divertible" imarket ishare iavailable. iPrice iwar iactivities iby icompetitors,
iwhether ilocal, iregional, inational ior iinternational, imust ialso ibe ianalyzed ifor
iearly icontingency ifunding iand idebt iservice inegotiations iduring ithe istart-up,
iramp-up, iand icommercial istart-up iphases iof ithe iproject.

Figure 3.1- Feasibility Studies

i i i

43
3.4. Feasibility Areas
i i

The iFeasibility iStudy iis ithe ipreliminary istudy ithat idetermines iwhether ia
iproposed isystems iproject iis itechnically, ifinancially, iand ioperationally iviable.
iThe iAlternatives iAnalysis, iusually iincluded ias ipart iof ithe iFeasibility iStudy,
iidentifies iviable ialternatives ifor ithe isystem idesign iand idevelopment. iBetween
ithem, ithe idocuments iprovide: iAn ianalysis iof ithe isystem iobjectives, ifunctional
irequirements, iand isystem idesign iconcepts:

● A idetermination iof ithe ifeasibility iof iapplying iautomated isystems ito

ieffectively, iefficiently, iand ieconomically iimprove iprogram ioperations;

● An ievaluation iof ialternative iapproaches ifor ireasonably iachieving ithe

iobjectives iand igoals; iand

● Identification iof ia iproposed iapproach

44
 CHAPTER 4 i

SOFTWARE REQUIREMENT SPECIFICATION

i i

4.1. Overview
i

An iaccurate iand ithorough iunderstanding iof isystem irequirements iis iessential ito
ithe isuccess iof iany iSoftware iDevelopment iProcess. iAll ifurther istages iof iSDLC
ilike isystem ianalysis, idesign iand icoding idepend ion ihow iaccurate iwell iprepared
iand ithoroughly iunderstood ithe iSystem iRequirements iSpecification iis. iPoorly
ianalyzed irequirements iwill idisappoint ithe iuser ino imatter ihow iwell idesigned
iand ithe iwell icoded ithe isoftware iis. iRequirement ispecification iappears ito ibe ia
irelatively isimple itask ibut ithe ichances iof imisinterpretation iis ivery ihigh,
iambiguity iis iprobable iand icommunication igap ibetween icustomer iand ideveloper
iis ibound ito ibring iconfusions. iRequirement iSpecifications ibegin iwith ia iclear
iand iconcise iheading istating iin ia isentence ithe itask ito ibe iperformed i(i.e. iwork
iobjective). iFor ithis, iwe ihave ito iidentify ithe iproblem ifirst. iProblem
ispecifications iserve ias ithe ibasis ifor iidentifying iwork iobjective ithat ihelps iin
idescribing ithe irequirements iin itechnical iand iprecise istatements. iAfter ithe iinitial
ispecification ireports iare ireceived, ithey iare ianalyzed iand irefined ithrough
icustomer-developer iinteraction. iSystem iAnalysis ifollows ito idetermine ifeasibility
iand iCost iBenefit iAnalysis.

A icomplete iunderstanding iof irequirement ispecification iof ithe inew isystem iis
ivery iimportant ifor ithe isuccessful idevelopment iof ithe isoftware iproduct.
iRequirement ispecification iis ithe ifoundation iin ithe iprocess iof isoftware

45
idevelopment. iAll ifurther idevelopment ilike iSystem iAnalysis, iSystem iDesign,
iand iCoding iwill idepend ion ihow iaccurate iand iwell iprepared ithe irequirement.

Overall Description
i

Requirement ispecification iappears ito ibe irelatively isimple itask, ibut iappearances
iare ioften ideceiving. iThere iis ialways ia ichance iof iwrong ispecification ibecause
iof icommunication igap ibetween iuser iand ideveloper, iambiguity iin irequirement
ior ia iwrongly ispecified iproblem.

Requirement iSpecification ibegins iwith ia iclear istatement iof ithe iproblem iand ithe
itask ito ibe iperformed. iThen irequirements iare idescribed iin ia itechnical imanner
iin iprecise istatements. iAfter ithe iinitial ispecification ireports iare ireceived, ithey
iare ianalyzed iand irefined ithrough iuser ideveloper iinteraction. iSystem iAnalysis
ifollows ito idetermine iand icost ibenefit ianalysis.

An iSRS iis ibasically ian iorganization's iunderstanding i(in iwriting) iof ia icustomer
ior ipotential iclient's isystem irequirements iand idependencies iat ia iparticular ipoint
iin itime i(usually) iprior ito iany iactual idesign ior idevelopment iwork. iIt's ia itwo-
way iinsurance ipolicy ithat iassures ithat iboth ithe iclient iand ithe iorganization
iunderstand ithe iother's irequirements ifrom ithat iperspective.

i
iii

46
 Figure 4.1- SRS Validation
i i i

The iSRS idocument iitself istates iin iprecise iand iexplicit ilanguage ithose ifunctions
iand icapabilities ia isoftware isystem i(i.e., ia isoftware iapplication, ian iecommerce
iWebsite, iand isoon) imust iprovide, ias iwell ias istates iany irequired iconstraints iby
iwhich ithe isystem imust iabide. iThe iSRS ialso ifunctions ias ia iblueprint ifor
icompleting ia iproject iwith ias ilittle icost igrowth ias ipossible.

47
The iSRS iis ioften ireferred ito ias ithe i"parent" idocument ibecause iall isubsequent
iproject imanagement idocuments, isuch ias idesign ispecifications, istatements iof
iwork, isoftware iarchitecture ispecifications, itesting iand ivalidation iplans, iand
idocumentation iplans, iare irelated ito iit.

It's iimportant ito inote ithat ian iSRS icontains ifunctional iand inon-functional
irequirements ionly; iit idoesn't ioffer idesign isuggestions, ipossible isolutions ito
itechnology ior ibusiness iissues, ior iany iother iinformation iother ithan iwhat ithe
idevelopment iteam iunderstands ithe icustomer's isystem irequirements ito ibe. iIt
iconsists ifollowing iphases

4.2. Modules of the Project

i i i i

● Text iChat iWindow

● Code iEditor

● Video iCall iWindow

● Login/ iRegister

● Create iNew iTask

48
4.3. Functional Requirements
i i

I. The iapplication ishould ibe iable ito istore ithe iuser idetails iin ithe idatabase
i(MongoDB).

II. There iwill ibe ione isign iin imethod iusing iusername iand ipassword.

III. There iwill ibe ian ioption iof ichat iwhere iyou ican ichat iand iget ihelp
ifrom others.

IV. A ipush inotification iis ito ibe isend ito ithe iusers iwhom ithe imessage iwill
ibe isend iin ichat.

V. When ithe inotification iis iaccessed iby ithe iuser, ithe ichat iscreen iwill ibe

iopened.

VI. On ithe itime iof isignup iuser iwill ibe iable ito icreate ian iaccount ifor icode
iediting.

VII. There iis itwo iway ichatting ieither ione ito ione ior igroup ichat.

4.4. iNon-Functional iRequirements

I. i i i i iPerformance iRequirements

The iprimary iperformance irequirement iis ispeed iof ithe inetwork ito isign iup
ithe iapplication.

II. Safety Requirements

iiii i i

iiiiiiiii i iThere iare ino isafety irequirements ifor ithis iapplication.

49
 III. Software Quality Attributes
iiii i i

The iprimary iattribute iof ithis iapplication iwill ibe iusability igiven ithe ilarge
iamounts iof idata iand iinformation ithat iwill ibe ipresented ion isuch ia ismall
iscreen, ias iwell ias ithe iuser’s iability ito iinput idata iinto ithe idevice iin ia
ireasonable imanner ithat ishould inot ibe ithat imuch imore idifficult ithan iif
ithey iwere iat ian iactual icomputer. iAs iusability iis ihard ito iquantify, i

Substantial iuser itesting iwill ibe ineeded iand ifeedback igathered iin iorder ito
idetermine iif ithe iapplication ican igenerally ibe iconsidered iusable.

Because ithis iapplication iwill ibe ion ia iphone. iWe idon’t iwant iit ito itake up iso
imuch ispace ior ibe itoo islow icausing ithe iuser’s ito inot ibe iable ito ifit iit ion ithe
idevice.

4.5. Approach To Develop The System

i i i i i

System/Information
iiiiiiiii Engineering

Analysis iiii Design i i iii iiiiii Code i i i iiiiiiiii Test i i i i i i iii

iApplication ii

Figure 4.2- Approach to Develop the system

i i i i i i

50
The iprototype iparadigm ibegins iwith irequirement igathering. iDevelopment iand
icustomer imeet iand idefine ithe ioverall iobjectives ifor ithe isoftware, iidentify
iwhatever irequirements iare iknown, iand ioutline iareas iwhere ifurther idefinition iis
imandatory. iA i―quick idesign‖ ioccurs.

The iquick idesign ifocuses ion ia irepresentation iof ithose iaspects iof ithe isoftware
ithat iwill ibe ivisible ito ithe icustomer/user. iThe iquick idesign ileads ito ithe
iconstruction iof ia iprototype. iThe iprototype iis ievaluated iby ithe icustomer/user
iand iused ito irefine irequirements ifor ithe isoftware ito ibe ideveloped.

Iteration ioccurs ias ithe iprototype iis ituned ito isatisfy ithe ineeds iof ithe icustomer,
iwhile iat ithe isame itime ienabling ithe ideveloper ito ibetter iunderstand iwhat ineeds
ito ibe idone.

After idesign iphase iis iapproved, iwe ifollow ithe ilinear imodel ito idevelop ithe
icomplete isystem. iAfter idesign iphase iwe imove ito icoding iand itesting ithen
iimplementation iphase.

In iprototyping imodel, iwe ifirst idevelop ia iworking iprototype iof ithe isoftware
iinstead iof ideveloping ithe iactual isoftware. iThe iworking iprototype iis ideveloped
ias iper icurrent iavailable irequirements.

The idevelopers iuse ithis iprototype ito ireefing ithe irequirements iand iprepare ithe
ifinal ispecification idocument. iBecause ithe iworking iprototype ihas ibeen ievaluated
iby ithe icustomer, iit iis ireasonable ito iexpect ithat ithe iresulting ispecification
idocument iwill ibe icorrect.

When ithe iprototype iis icreated, iit iis ireviewed iby ithe icustomer. iTypically, ithis
ireview igives ifeedback ito ithe idevelopers ithat ihelps ito iremove iuncertainties iin
ithe irequirements iof ithe isoftware, iand istarts ian iiteration iof irefinement iin iorder
ito ifurther iclarify irequirements.

51
The iprototype ibeing ideveloped iis inot ithe ifinal iproduct ito ibe idelivered iand ithe
icode igenerated iin ithe iprototype iis ibeing iget ithrown iaway ibut ithe iexperience
igathered ifrom ideveloping ithe iprototype ihelps iin ideveloping ithe iactual isystem.

iThe idevelopers ishould idevelop iprototype ias iearly ias ipossible ito ispeed iup ithe
isoftware idevelopment iprocess.

Figure i4.3- iSoftware iDevelopment iProcess

52
4.6. Prototyping Model
i i

Working iof iPrototype imodel ican ibe idescribed ias:

Fig i4.4 iPrototype iModel

53
 CHAPTER 5 i

ii i SYSTEM DESIGN
i

5.1. Architecture Design

i i

It iprovides iunderstanding iand inecessary idetail ifor iimplementation iof ithe isystem
iwhich iis ithe imost iimportant. iEmphasis iis ion ithe iperformance irequirements iinto
idesign ispecifications. iThe iDesign iphase iis irequired ito ibe icheck iby ithe iuser ior
iwe ican isay ithat iit iwill ibe ias iper ithe iuser irequirement. i(System iproposal) ito ia
idocumented ioriented ito ithe iprogrammers ior idatabase ipersonnel.

Feature of Three-tier Architecture:

i i i

It ihas ithe ior ithis isoftware ihas ithree-tier iarchitecture. iThe iarchitecture ilayers iare
ithe idatabase ilayer iand ithe iapplication iserver ilayer iand ithe iclient ilayer. iCompiled
iis idone iin ithe iapplication iserver. iThe iapplication iserver ilayer iand ithe idatabase
iserver iwill icommunicate iand ithe idetails iare igiven ito ithe ilistener. iThree-tier
iarchitecture iis iconsidered ito ibe ithe imost isuitable iand iconvenient iarchitecture ifor
ilarge iapplications. iThe idivision iof ithe iapplication ienables irapid idesign iof ithe
isystem iand idevelopment iof ithe isystem. iThe imodular idesign imakes iit ieasier ito
imake ichanges ito ijust ione itier iwithout iaffecting ithe iothers isystem. iSeparating ithe
ifunctions iinto idistinct itiers imakes iit ieasier ito imonitor iand ioptimize ithe
iperformance iof ieach ilayer. iLoad ibalancing iand iadding imore icapacity ican itake
iplace iindependently iat ieach ilayer. iMulti-tier iarchitecture ialso imakes iit isimpler ito
imeasure ithe isystem iacross imultiple iprocessors ion idifferent imachines.

54
Three-tier iarchitecture iintroduces ia iserver ibetween ithe iclient iand ithe iserver.
iManifolds iis ithe irole iof iagent. iIt ican iprovide iservice iof itranslation i(as iin
iadapting ia ilegacy iapplication ion ia imainframe ito ia iclient/server ienvironment),
imetering iservices i(as iin iacting ias ia itransaction imonitor ito ilimit ithe inumber iof
isimultaneous irequest ito ia igiven iserver), ior iintelligent iagent iservices i(as iin
imapping ia irequest ito ia inumber iof idifferent iservers, icollating ithe iresults iand
ireturning ia isingle iresponse ito ithe iclient

I. The ipresentation ilayer idelivers ithe iapplication ito ithe iend iusers ion ithe
iweb.

II. iThe ibusiness ilogic ilayer imaintains iand iexecutes ithe irules ithat irun ithe i i
i i i iapplication.

III. iThe idatabase ilayer imanages ithe idata irequired iby ithe iapplication.

5.2. Process Design

i i

5.2.1. V –Model of development

i i i

V imodel isdlc iProcess iis ia iwhole ilife-cycle iprocess. iThis isdlc iProcess imust ibe
iapplied iat ieach istage iin ithe isoftware iprocess.

55
 Figure i5.1- iLifecycle iProcess iModel

The iV-Model i(Lifecycle iProcess iModel) isoftware idevelopment ilife icycle iregulates
ithe isystem iprocess idevelopment iand ithe imaintenance iand imodification iof
isystems.

This istandard ihelps ito iachieve ithe ifollowing iobjectives: iImprovement iand
iguarantee iof ithe iquality. iThe idiscovery iof idefects iin ia isystem.

56
● The ichecking iof ithe isystem iwhether iit iworks ior inot iin ithe ioperational
isituation.

● The iresult ishould ibe icomplete iin istandardized iprocess ito imaintain ithe
ibalance.

● Defined iinterim iresults imake itesting ior iassessment iof ithe isystem ivery
ieasy. iUniform iproduct icontents ialleviate ithe ireadability iof ithe iproducts
iand ithe iassessment iprocedures.

● To icalculate ithe icost ifor ithe iwhole ilife icycle.

● To isimplify ithe iassessment iand itesting iand ito imaintain ithe istandard iso ithe
isystem ican ibecome ithe imore itransparent.

● This istandardized iprocedure imakes ithe icost icalculation imore itransparent

iaccurate iand ieasy. iAny irisks iin iconnection iwith ithe icosts ican ibe
irecognized ibetter.

● Uniform istandards ireduce ifriction ilosses ibetween ibuyer iand imanager ias
iwell ias ibetween ilead imanager iand isubcontractor.

● Standardized iprocedures iallow ifor ithe ireduction iin ithe iuse iof iresources.

● In icase iof ia istandardized iprocedure iuniversal iapproaches ito ithe isolutions

ibecome itransparent iand ican ithus ibe ireused.

● Undesirable idevelopments iare irecognized iat ian iearlier istage.

57
 ● The itraining icosts iare ireduced.

● The iinterim iresults/final iresults iare istandardized ito isuch ian iextent ithat
iother iparties iinvolved ior istaff iof iother icompanies iare iable ito isettle iin
iwithout ivery imuch ieffort, iif inecessary.

5.3. ER Diagram
i i

Figure i5.2- iER iDiagram

5.4. Modular design

i i

This iproject icontains imany imodules. iBut ithis iis ione iof ithe ilatest inode.js
iapplications, iwhich iis iincreasing ipopularity ialong iwith ithe istudent ikind iof

58
iapplication. iIt iis imade ifor iweb iplatform iand iit iis iportable iso iwe ican iuse iit ifor
iany ibrowsing idevice.

It iis ibased ion isingle ibasic ifunctionality. iJust istart iup ithe iapplication iand iit
iimmediately istarts igiving iyou ia icode ieditor iwith imodules iof ivideo iand itext
ichat. iThere iis ino ineed ito idefine isomething ipersonal. iWe iare ifetching idata ifrom
ithe imongodb idatabase. iAll iyour icode iis ibeing isaved itime ito itime iin iit. iAfter
ifetching, ithe istoring iof idata iin ito idatabases itaken iplace, iso ithat iwe icould
iincrease ithe iperformance.

Modules of the project

i i i

● Login/Register

● Create iNew iTask

● Text iChat iWindow

● Video icall itab

● Code iEditor

59
 CHAPTER 6 i

DATA DESIGN
i

6.1. Data Flow Diagram

i i i

Data iFlow iDiagrams irepresent ione iof ithe imost iimportant itools iused ifor
istructure irequirement iand ianalysis. iA iData iFlow iDiagram ior iDFD ias iit iin
ishort icalled ior ialso iknown ias ia ibubble ichart. iIt ihas ithe iway iof ispecifying
isystem irequirement iand itesting imajor itransformation ithat iwill ibecome iprograms
iin isystem idesign. iIt iis ithe imajor istart ipoint iin ithe idesigning iphase ithat
ifunctionally ibreaks iinto ithe irequirements ispecification idown ito ithe ilowest ilevel
iof idetails. iA isystem ifunctions ibreaks iinto ithe irequirements ispecification idown
ito ithe ilowest ilevel iof idetails. iit iis iDFD iconsists iof ia iseries iof ibubble ijoined
iby ilines. iThe ibubble ior idot irepresents idata itransformation iand iline irepresents
idata iflow iin ithe isystem. iIn ithe inormal iway ia iDFD ihas ifour ibasic isymbols.

I. Square, that defined the source or destination of data

i i i i i i i i

II. i i iArrow ithat ishows ithe idata iflow.

60
 III. i iCircle ithat irepresent ia iprocess ithat itransformation iincoming idata iin ito
ioutgoing iflow

The iDFD iat ithe isimple ilevel iis iknown ito ias ithe i=zero ilevel iDFD ior iwe ican
isay iin ithe isimple iwords ia i=Context iAnalysis iDiagram. iThese iare iincreases
ilevel iby ilevel ieach iterm iexplaining iits iprocess iin ithe idetail. iProcesses iare
inumbered ifor ieasy iidentification iand iare inormally ilabelled iin iblock iletters.
iEach idata iflow iis ilabelled ifor ieasy iunderstanding.

6.2. Context Flow Diagram

i i i

Figure 6.1- Context Flow Diagram

i i i i

61
6.3. Data Flow Diagram
i i i

Figure i6.2 i- iLEVEL i1 iDFD

Figure i6.3 i- iLEVEL i2 iDFD ifor iLogin

62
 Figure i6.4 i- iLEVEL i2 iDFD iFOR iChat

6.4. Database Designi

Data iin icomputer iis itermed ia idatabase. iThere iis isoftware ithat iallows ione ior
imore ipersons ito iuse iand i/ imodify ithis idata iis ia idatabase imanagement isystem
i(DBMS). iA imajor irole iof ithe iDBMS iis ito iallow ithe iuser ito ideal iwith ithe idata
iin iabstract iterms, irather ithan ias ithe icomputer istores ithe idata. iThe iDBMS imeets
ias ian iinterpreter ifor ia ihigh ilevel iprogramming ilanguage; iideally iallowing ithe
iuser ito ispecify iwhat imust ibe idone iwith ilittle ior ino iattention ion ithe iuser‘s ipart
ito ithe idetailed ialgorithm ior idata irepresentation iused iby ithe isystem. iHowever iin
ithe icase iof ia iDBMS ithere imay ibe ifar iless irelationship ibetween ithe idata ias
iseen iby ithe iuser iand ias istore iin ithe icomputer, ithan ibetween iarrays ias idefined
iin ia itypical iprogramming ilanguage iand ithe irepresentation iof ithose iarrays iin ithe
imemory. iThe idata ibase imanagement isystem iis ione iof ithe imost icomplex
ivarieties iof isoftware iin iexistence. iOne iway ito iget ia ifield ifor ithe idifferent
iaspects iof ithe iDBMS iis ito iconsider ithe ivarious ikinds iof iusers iof isuch ia isystem
iand iways ithey iinteract iwith ithe isystem iand iwith ieach iother.

In irelational idatabase iapproach, idata iis iorganized iin ilogical imathematical isets iin
itabular istructure. iThe idata ifilled ibecomes ia icolumn iin ia itable iand iunder
irelational imodel iand ieach irecord ibecomes ia irow iin ia itable. iRelationship
ibetween ivarious itable iareas iis idefined ithrough ithe iuse iof ia imathematical
ifunction isuch ias iJOIN iand iUNION. iThe icost iimportant iadvantages iof irelational
imodel iare iits iflexibility iin idescribing ithe irelationship ibetween ithe ivarious idata
iitems.
63
Primary ipurpose ibehind ithe irelational imodel iis ithe ipreservation iof idata iintegrity,
iwhich iimplies ithat ithe idata imust ibe istored iin ia iformat ithat ipreserves iit ifrom
ibeing iaccessed ifrom ioutside ithe iDBMS ithat icreated iit.

The iemphasis ion ithe idata iintegrity imakes ithe irelational imodel iideal ifor
itransactional iprocessing isystems, iand ithus ifor imulti iuser iand iclient iserver
idatabase. iThe irelational imodel ialso irequires ithat ithe idate ibe iaccessed ithrough
iprograms ithat ido inot irely iin ia idata iin ithe idatabase.

The imost iimportant iaspect iof ibuilding iof iapplication iis ithe idesign iof itables ior

the idatabase ischema. iThe idata istored iin ia itable imust ibe iorganized iin isome

manner, iwhich iis imeaningful. iThe ioverall iobjective iin ithe iprocess iof itable

design ihas ibeen ito itreat ias ian ito iachieve ithree imajor iobjectives iare igiven ibelow:

● Data iIntegration

● Data iIntegrity

● Data iIndependence

Several idegrees iof inormalization ihave ito ibe iapplied iduring ithe iprocess iof itable
idesign. iThe imajor iaim iof ithe iprocess iof inormalization iis ito ireduce idata
iredundancy iand iprevent ilosing idata iintegrity. iRedundancy irefers ito iunwanted
iand iunnecessary irepetition iof idata. iData iintegrity ihas ito iconvert iat iall ilevels.
iPoor inormalization ican icause iproblems irelated ito istorage iand iretrieval iof idata.
iDuring ithe iprocess iof inormalization, idependencies ican ibe iidentified iwhich icause
iserious iproblem iduring ideletion iand iupdating. iNormalizing ialso ihelp iin
isimplifying ithe istructure iof itable.

The itheme ibehind ia idatabase iis ito ihandle iinformation ias ian iintegrated iwhole
ithus imaking iaccess ito iinformation ieasy, iquick, iinexpensive iand iflexible ifor iuser.
iThe ientire ipackage idepends ion ihow ithe idata iare imaintained iin ithe isystem ieach
itable ihas ibeen idesigned iwith ia iperfect ivision. iMinor itables ihave ibeen icreated
iwhich ithought itakes imuch ispace ifacilities ithe iprocess iof iQuerying ifast iand
iaccurate.

64
Normalization iprovides ia itable ioptimization ithrough ithe ienquire iof ientity
irelationships. iMain ipurpose iof inormalization iis ito iignore iData iredundancy iand
isome iunforeseen iscalability ifactors. iNormalization iis idone ito iremove iInsertion,

Updating iand iModification ianomalies iand iredundancy iof idata. iA icertain ilevel iof
inormalization iof itables iin idatabase igives ia iparticular inormal iform ibased iof
iparticulars isteps ifollowed. iDatabase iwill ibe inormalized iup ito iany itype iof
idefined inormal iforms iaccording ito ithe irequirement iof iapplication iand iits
iefficiency.

6.5. Normalization
i

Database iof icost iEstimation iis inormalized iup ito iThird iNormal iForm. iFurther
inormalization iof idatabase iwas inot iconsidered itaking iinto iaccount ithe ineed iof
iapplication iand iease iof iworking iwith idatabase.

The idatabase iis iin iFirst iNormal iForm ias iall ithe ifields iof iall itables iare
iatomic. iThere iis ino imulti-valued ifield iin iany itable.

The idatabase iis iin iSecond iNormal iForm ias iit isatisfies ithe iconstraint iof ifull
ifunctional idependency. iAll ithe ifields iof iall itables iare ifully ifunctional
idependent ion ithe iprimary ikey.

The idatabase iis iin iThird iNormal iForm ias iall iits itables isatisfy ithe
iconstraint ithat ithere ishould ibe ino itransitive idependency. iNo ifield ihas
itransitive idependency ion ithe ikey ifield. iThus idatabase ialso isatisfies ithe
iconstraints iof ithird inormal iform.

65
6.6. User Interface Design
i i i

The iinterface idesign idescribes ihow ithe isoftware iwill icommunicates iwithin iitself,
ito isystem ithat iinter-operates iwith iit iand iwith iperson iwho iuse iit. iUser iinterface
iis ithe idoorway iinto ithe iinteractive isoftware iapplication. iThe iinterface itells ithe
isystem iwhat iaction iis ito ibe itaken ifor ientering, ichanging, ior iretrieving idata. iIt
ishould iallow iusers ito iaccomplish iprocessing iaction iis ito ibe itaken ifor ientering,
ichanging ior iretrieving idata. iThe iinterface iwill ibe iin isuch ia iway ithat iit iincludes
imethods ithat iwill inot ibe iwrong ior iunacceptable ito ifrequent iusers iwho ibecome
ifamilies iwith ithe isystem, ibut iit iwill ifacilitate iequally ieffective iuse iby inovice
iusers. iIt ishould iprevent iany iaction ithat iwill icreate ia iprocessing ierror.

Interface idesign icreates ian ieffective icommunication imedium ibetween ia ihuman

iand ia imobile. iDesign iidentifies iinterface iobjects iand iactions ithen icreate ia
iscreen ilayout ithat iforms ithe ibasis ifor ia iuser iinterface.

Interface idesign ifocuses ion:

I. The idesign iof iinterfaces ibetween isoftware icomponents

II. i i iThe idesign iof iinterfaces ibetween isoftware iand iother inon-human
iproducers iand iconsumers iof iinformation

66
 CHAPTER 7 i

SYSTEM TESTINGi

7.1. Test Plan

i

Test iPlan idescribes ithe itesting istrategy iand iapproach ito itesting. iQA iis ito
ivalidate ithe iquality iof ithe iproduct iprior ito irelease. iIt ialso icontains ivarious
iresources irequired ifor ithe isuccessful icompletion iof ithis iproject.

7.1.1. iTEST iSCRIPTS

A itest iscript iis ia iset iof iinstructions ithat iexecutes ia itest isuite iof itest icases.

The igoals iof ia itest iscript iare ito iautomate ior idocument ithe ifollowing:

● Automate ithe iexecution iof itest icases.

● Support iregression itesting.

The isupport ithese igoals, ithe iobjectives iof ia isingle itest iscript iinclude:

● Execute ieach itest icase iin ithe itest isuite.

67
 ● Report ithe iresult iof ithe itest isuite.

A itest iscript iprovides ithe ifollowing ibenefits:

● It isupporting iregression itesting.

● Failure ito iproduce itest iscripts imakes iregression itesting iless ilikely ito
ioccur iand imore iexpensive.

7.1.2. GUIDELINES
i

Three test iscripts iwill ibe iused iat iall ilevels iof itesting i(e.g., iunit itesting,
iintegration itesting, isystem itesting, iand ilaunch itesting).

If ithe iquality iof ithe itest iscripts iis inot iat ileast ias igood ias ithe iquality iof ithe
iitem iunder itest ithen iit iwill ibe idifficult ito iknow iif ithe idefect icausing ithe
ifailure iof ithe itests, iwhich iare idocumented iin ithe iassociated itest ireports.

7.2. System Testing

i

Testing iis ithe istage iof iimplementing, iwhich iis iaimed iat iearning isystem irunning
iaccurately iand iefficiently. iThe ipurpose iof ithe isystem itesting iis ito iidentify iand
icorrect ierrors iin ithe inew isystem. iThe iperformance ifactors ilike iturnaround itime,
iback iup, ifile iprotection iand ihuman ifactors iare isome iof ithe iperformance

68
icriteria ifor isystem itesting. iA isystem iis itested ifor ionline iresponse, idisplay,
irecovery ifrom ifailure iand iusability.

Effective itesting iearly iin ithe iprocess itranslates idirectly iinto ilong-term icost
isavings ifrom ia ireduced inumber iof ierrors. iBack iup ifiles iare ineed iwhen ithe
isystem iis ifailure ior idown. iThe iusability itest iverifies ithe iuser-friendly inature iof
ithe isystem. iAccurate iand icomplete idocumentation iis inecessary ifor ithe iuser
ifriendly inature iof ithe isystem.

System itesting iis idesigned ito iuncover iweaknesses ithat iare inot ifound iin ithe
iearlier itests. iThis iincludes iforced isystem ifailure iand ivalidation iof ithe itotal
isystem, ias iits iusers iin ithe ioperational ienvironment iwill iimplement iit. iThe itotal
isystem iis itested ifor irecovery iand ifallback iafter ivarious imajor ifailures ito
iensure ithat ino idisplay iis ilost iduring ithe iemergency. iAll ithis iis idone iwith ithe
iold isystem istill iin ioperation. iAfter ithe icandidate isystem ipasses ithe itest, ithe
iold isystem iis idiscontinued.

System itesting iinvolves iunit itesting, iintegration itesting, iacceptance itesting.

Careful iplanning iand ischeduling iare irequired ito iensure ithat imodules iwill ibe
iavailable ifor iintegration iinto ithe ievolving isoftware iproduct iwhen ineeded. iA
itest iplan ihas ithe ifollowing isteps:

● Prepare itest iplan

● Specify iconditions ifor iuser iacceptance itesting

● Prepare itest idata ifor iprogram itesting

69
 ● Prepare itest idata ifor itransaction ipath itesting

● Plan iuser itraining

● Compile/assemble iprograms

● Prepare ijob iperformance iaids.

System itesting iis ithe istage iof iimplementation ithat iis iaimed iat iensuring ithat ithe
isystem iworks iaccurately iand iefficiently ibefore ilive ioperation icommences. iThe
isystem ion ia iwhole iwas itested ifor ithe ifollowing:

Speed iof idata ifetching ifrom ifirebase.

Display iis isame ifor iall iandroid idevices.

● Sequential itests

● Consistency iof ithe iapplication

System itesting, iasks ia ilogical iassumption ithat iif iall ithe iparts iof ithe isystem iare
icorrect, ithe isystem iwill ibe isuccessfully iachieved. iThe iobjective iof itesting iis ito
idiscover ierrors. iTo ifulfil ithese iobjectives ia iseries iof itests iwere iplanned iand
iexecuted. iThe ilogical idesign iand ithe iphysical idesign ishould ibe ithoroughly iand
icontinually iexamined ion ipaper ito iensure ithat ithey iwill iwork iwhen
iimplementation ishould ibe ia iconfirmation ithat iall iis icorrect iand ian iopportunity
ito ishow ithe iusers ithat ithe isystem iworks.

70
7.2.1. Unit Testing
i i

Here, ieach iindividual iprogram iwas itested iusing ithe itest idata. iThe ioutputs ias
iper ithe irequirements iwere ifound isatisfactory. iThus iit iwas ipossible ito iconclude
ithat ievery iprogram iin ithe isoftware iwas ifunctionally icorrect. iThe iinterrelated
imodules iwere ialso itested iin ian iexhaustive ithat iwill imake ithe iwhole isoftware
iwork iproperly.

● Module iinterface iis ichecked ito iconfirm ithat iinformation iflows iproperly
iand iput iof ithe iprogram iunder itest.

● Local idata istructures iare iexamined ito iconfirm ithat idata istored
itemporarily imaintains iits iintegrity iduring ialgorithm iexecution.

● All idisplay iis ichecked ito iconfirm ithat iit iis icompatible ifor iall iandroid
idevices.

● All iindependent ipaths iare iexecuted iat ileast ionce ito iconfirm ithat ithe
ievery imodule iis iexecuted iat ileast ionce.

● Error ihandling ipaths iare ialso itested.

This itest ifocuses iverification ieffort ion ithe ismallest iunit iof isoftware idesign, ithe
imodule. iHere, ithe imodule iinterfaces, ilocal idata istructure, idisplays, iand iall
iindependent ipaths iand ilast ibut inot ithe ileast, iall ierror ihandling ipaths iwere
iverified iby iinputting ifalse idata. iTests iof idata iflow iacross ieach imodule
iinterface iof ithis isoftware iwere idone ibefore iany iother itest iwas iinitiated.

71
A iunit itesting ifocuses ion ithe iverification ieffort ion ithe ismallest iunit iof ithe
isoftware idesign. iUsing ithe iunit itest iplan iprepared iin ithe idesign iphase iof ithe
isystem, iimportant icontrol ipaths ibe itested ito iuncover ithe ierrors iwithin ithese
imodules. iThis itesting iwas icarried iout idoing ithe icoding iitself. iIn ithese itesting
isteps, ieach imodule iis igoing ito ibe iworking isatisfactorily ias ithe iexpected ioutput
ifrom ithe imodule.

7.2.2. Integrated Testing

i i

The iindividual iprograms iare icombined itogether ito iform imodules. iIntegrated
itests iwere iperformed ion ieach iof ithe imodules iand iagain ithe ivalidity iwas
ichecked. iAfter ithat, iall imodules iwere ibrought iunder ia isingle imodule iand ithe
iintegrity itest iwas ifound ito ibe isuccessful.

This isystem iwas ivalidated iin isuch ia iway ithat ieven ithe islightest ideviation iin
iinputting ithe idata iwill iinvoke ierror imessages iand iprovide iguidelines iregarding
ithe iinput. iBefore ithe isoftware iis ibeing ireleased, ithe idevelopers ito ido itesting
iby iimplementing ithe icommercial isecurity ipackage ifor isecurity.

This iensures ithat ithe isoftware iworks iproperly. iThese itests ican ialso ibe
iperformed

● Top idown iintegration

● Bottom iup iintegration

72
It iis isystematic itechnical ifor iconstructing ithe iprogram istructure iwhile iat ithe
isame itime iconducting itest ito iuncover ierrors iassociated iwith ithe iinterface. iThe
iobjective iis ito itake iunit itested imodule iand ibuild ithe iprogram istructure ithat
ihas ibeen idetected iby idesign.

All imodules iare icombined iin ithis itesting istep, iand ithe ientire iprogram iis itested
ias ia iwhole. iIf ia iset iof ierrors iare iencountered icorrection iis idifficult ibecause
ithe iisolation iof icauses iis icomplicated iby ivastness iof ithe ientire iprogram.

Using iintegrated isystem itest iplan iprepared iin ithe idesign iphase iof ithe isystem
ideveloped ias ia iguide, ihe iintegration iwas icarried iup.

7.2.3. System Testing

i i

When ia isystem iis ideveloped, iit iis ihoped ithat iit iperforms iproperly. iIn ipractice
ihowever isome ierrors ialways ioccur. iThe imain ipurpose iof itesting iand
iinformation isystem iis ito ifind ithe ierrors iand icorrect ithem. iA isuccessful itest iis
ione iwhich ifinds ian ierror.

The imain iobjectives iof isystem itesting iare

● To iensure iduring ioperation ithe isystem iwill iperform ias iper ispecifications.

73
 ● To imake isure ithat ithe isystem imeets iuser‘s irequirements iduring
ioperation.

● To iverify ithat ithe icontrols iincorporated iin ithe isystem ifunction ias
iintended.

● To isee ithat iwhen icorrect iinputs iare ifed ito ithe isystem ithe ioutputs iare
icorrect.

● To imake isure ithat iduring ioperation iincorrect iinput iand ioutput iwill ibe
ishow ierror imessage.

The iscope iof ia isystem itest ishould iinclude icomputerized ioperation. iOperations
isystem itesting iis ia icomprehensive ievaluation iof ithe iprograms, imanual
iprocedures, icomputer ioperations iand icontrols. iSystem itesting iis ithe iprocess iof
ichecking iif ithe ideveloped isystem iis iworking iaccording ito ithe ioriginal
iobjectives iand irequirements. iAll itesting ineeds ito ibe iconducted iin iaccordance
ito ithe itest iconditions ispecified iearlier.

7.2.4. Validation Testing

i i

Validation itesting iis idone ito iensure icomplete iassembly iof ithe ierror-free
isoftware. iValidation ican ibe itermed isuccessful ionly iif iit ifunctions iin imanner
ithat iis ireasonably iexpected iby ithe icustomer.

Under ivalidation iis ialpha iand ibeta itesting. iAlpha itesting iis iwhere ithe iend iuser
itests ithe isystem irather ithan ithe ideveloper, ibut iin ia icontrolled ienvironment.

74
iThe isoftware iis iused ion ia inatural isetting iwith ithe ideveloper imonitoring ithe
iuser iusing ithe isystem. iThe ideveloper irecords ithe ierrors iand iusage iproblems
iencountered iby ithe iuser.

The isales iperson iconducts ibeta itesting iat ione imore isites. iThe ideveloper iis inot
ipresent iduring ithese itests. iHence, ibeta itest ican ibe isaid ias ithe ilive iapplication
iof ithe isoftware ion ian ienvironment ithat icannot ibe icontrolled iby ithe ideveloper.
iThe isales iperson itakes idown ithe iproblems iencountered iduring ibeta itesting iand
ireports ithese ito ithe ideveloper iat iregular iintervals. iThe ideveloper imakes
isuitable imodifications ito ithe isoftware ihenceforth.

The ifirst istep iin isystem itesting iis ito idevelop ia iplan ithat itests iall ithe iaspects
iof ithe isystem. iCompleteness, icorrectness, ireliability iand imaintainability iof ithe
isoftware iare ito ibe itested ifor ithe ibest iquality iassurance-an iassurance ithat ithe
isystem imeets ithe ispecification iand irequirements ifor iits iintended iuser iand
iperformance. iSystem itesting iis imost iuseful ipractical iprocess iof iexecuting ia
iprogram iwith iexplicit iintention iof ifinding ierrors ithat imakes ithe iprogram ifail.

The ifollowing iphases iwere ideveloped.

7.2.5. Module Testing

i i

Each iindividual iprograms imodule iis itested ifor iany ipossible ierrors. iThey iwere
ialso itested ifor ispecifications, ii.e. ito isee iwhether ithey iare iworking ias iper iwhat
ithe iprogram ishould ido iand ihow iit ishould iperform iunder ivarious iconditions.

7.2.6. Display Testing

i i

75
The idisplay iprocedures iwere itested isince ithe idisplayed iis iof imost iimportance.
iThe idata iwas iinput iin ithe idifferent imodules iand iit iwas ichecked iwhether ithe
iinformation iis iproperly idisplayed iin ithe iother idependent imodules. iThe
iconsistency iof ithe idisplay iand iattractiveness iof ithe idisplay iwere ialso itested.
iThe ifollowing itests iwere ialso iconducted iover ithe isystem ideveloped:

● Integration: iThese itest ithe iintegration ibetween ibrowsers iand iservers,

iapplications iand idata, ihardware iand isoftware.

● Usability: iThese itest ithe ioverall iusability iof ia iweb ipage ior ia iweb
iapplication, iincluding iappearance iclarity iand inavigation.

● Security: iThese itest ithe iadequacy iand iaccuracy iof ithe isecurity icontrols.

76
 CHAPTER 9 i

FUTURE ENHANCEMENT
i

I. i i i i i iWe iwill ishift ithe idatabase ifrom iMongoDB ito iown iHeroku.

II. i i i i iIn ifuture iwe iwill iprovide ithe ifunctionality iof iGithub.

III. i i i iIn iFuture iWe iwill iget imore iusers iinteract iin ione isession.

IV. i i i iWe iwill iprovide ithe iImage isending ifacility iin ichat isection

V. i i iWe iwill iprovide ialternate ilogin ioption ilike iLogin iwith iGoogle iand iG.

VI. i i i iShortening iof iUser iId iinto iunique iidentifiers.

VII. i i i iIn iQuick ichat ithere iwill ibe ioption ifor iattachment ifor idocuments.

77
CONCLUSION

CODET - Code Together is a user-friendly interactive Application for

i i i i i i i i i

i browsers and requires no prior knowledge of software. All the suggestions

i i i i i i i i i i

i forwarded during the software proposal have been successfully completed

i i i i i i i i

i and final threshold of application has been crossed.

i i i i i i i

Some ierrors iwere ispotted iout iduring ithe isystem itesting iand iwere icorrected. iYou
imay iencounter ichallenges inot icovered iby ithe ibook, isince ievery iproject iis
idifferent iand ievery ipossible iscenario ican’t ipossibly ibe icovered, ibut ihopefully iwe
ihave iat ileast iprovided iyou iwith ithe iframework ithat iwill iguide iyou ithrough ithe
iprocess iso iit igoes ismoothly iand iallows iyou ito iavoid icommon ipitfalls ithat imany
iapp idevelopment iprojects iusing ian ioutsourced ideveloper ican iencounter.

78
 REFRENCES

1. https://www.androidhive.info/

2. https://developers.google.com

3. https://www.tutorialspoint.com

4. https://www.mongodb.com/

5. https://www.simplifiedcoding.net/

6. https://in.udacity.com/

7. https://stackoverflow.com/

79
80