F454 Whole Project Template (2)

7/26/2019 F454 Whole Project Template (2)

1/15

A2 Unit F454Computing Project

Name:Candidate Number:

Centre Name: Watford Grammar Schoo for !o"#Centre: $%&55


2/15

'A!() *F C*N')N'S

$ +)F,N,',*N----------------------------------------------------------------------------------------------------------------------------.

2 ,N/)S',GA',*N AN+ ANA(0S,S------------------------------------------------------------------------------------------5

2.1 Hardware and software requirements...............................................................................6

2.2 Requirements Specification..............................................................................................7

. +)S,GN-----------------------------------------------------------------------------------------------------------------------------------1

3.1 Nature of the solution........................................................................................................8

3.2 Alorithms....................................................................................................................... 11

3.3 !est strate" # plan........................................................................................................ 12

4 S*F'WA) +)/)(*P3)N' AN+ ')S',NG---------------------------------------------------------------------$.

5 +*CU3)N'A',*N--------------------------------------------------------------------------------------------------------------- $4

& )/A(UA',*N------------------------------------------------------------------------------------------------------------------------ $5

6.1 $eree of success in meetin oriinal o%&ecti'es...........................................................1(

6.2 )ser*s response to the s"stem....................................................................................... 1(

6.3 $esira%le e+tensions................................................................................................. ..... 1(

,-(- pro&ect 2 "our name/


3/15


4/15

;utput $escription ,ormat

:em%ership


5/15

2 ,N/)S',GA',*N AN+ ANA(0S,S

11 mar0s "ou need user in'ol'ement throuhout to et full mar0s)se inter'iews questionnaires documentation and o%ser'ation whate'er is appropriate for "our pro&ect.

,ntroduction

>ein with a %rief pararaph statin that followin on from "our initial in'estiation "ou will now %e conductinan in depth anal"sis to ascertain the %est solution to the pro%lem and to ascertain the requirements of "ourend user.

,n6e#tigation Pan

n this section discuss how "ou will carr" out "our in'estiation usin one or more of the followin methods toather data.


6/15

nclude $ata ,low $iarams 4$,$s5 or S"stem flowcharts of how the current s"stem wor0s. A flowchart isuseful to add to illustrate the current s"stem e.. how a new mem%er is added to the s"stem or how stoc0 ischec0ed in a shop.

,dentification of Pro#pecti6e U#er#

State e+actl" who will %e usin the new s"stem it ma" not %e "our end user it ma" %e an administrator orother mem%er of the oranisation. !here could %e se'eral users of the s"stem.

Genera *bjecti6e# of the ne S"#tem

)se 3 sections. Here are some e+amples

,nput *bjecti6e#:em%er $etails=roduct $etails

Proce##ing *bjecti6e#


7/15

2-2 euirement# Specification

!his needs to %e a separate document that should %e sined off %" "our end user a detailed list of e+actl"what "our application needs to do. @ettin the requirements riht is 0e" to actuall" producin "our code andwritin "our e'aluation which will %e %ased on how successfull" "ou were a%le to meet each indi'idualrequirement.

!hese could %e split into essential and desira%le functionalit". >rea0 it down into input output and processinrequirements. =ut the requirements in a ta%le and include the user*s sinature at the end.

,or e+ample

)##entia +e#irabe

,nput reuirement#

Proce##ing reuirement#

*utput reuirement#

Prepared !" CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC4Role5

Appro6ed !" CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC4Role5

CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC4Role5

Appro6a +ateCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC



8/15

. +)S,GN

.-$ Nature of the #oution

6 mar0s to et full mar0s "ou must show that "our end user has seen and areed these desins

*6era #"#tem de#ign

=ro'ide a clear o'er'iew of how "ou intend to implement the s"stem. :ention colour scheme if there is ane+istin s"stem or if the compan"oranisation has a standard colour that "ou should use.


9/15

+efinition of +ata euirement#

ecord Structure

9ou need somethin li0e %elow. :a0e sure "ou identif" which are 0e" fields.

Cu#tomer 'abe

,tem +ata'"pe +e#cription '"pica +ata Source of +ata


10/15

)ntit" eation#hip +iagram

Here is an e+ample howe'er it doesn*t necessaril" ha'e to %e a relational data%ase.

B+plain %riefl" how the ta%les will lin0 toether. Jhat are the primar" and forein 0e"s in the each ta%le. How willthis help to ma0e data more consistent and reduce data redundanc"K 9ou need to e+plain how a 1 to man" or

man" to man" relationship wor0s.

/aidation

!al0 a%out the different t"pes of 'alidation techniques "ou will use.

!hen do a ta%le for each 'alidation "ou will use as %elow

Fied 'abe /aidation )rror 3e##age Format of )rror3e##age

Num%er;rdered

;rders Rane chec0 ? /L1and L(F

9ou can onl" order%etween 1 and (F

units for this item

$ialoue >o+ ,orm a%el

+ata ,nput#

eg-

Fied 'abeNum%er;rdered

;rders


11/15

3enu +e#ign

$raw a site map st"le structure diaram for "our forms showin how the" na'iate %etween each other.

Securit" of +ata$iscuss whether there is a need for password protection. f there are different t"pes of user "ou ma" wish toconsider the use of different user access le'els. Alternati'el" it ma" %e appropriate to specif" differentprorams for different uses such as end of "ear procedures file set up or house0eepin functions. :a0e sure

that "our s"stem complies with the requirements of the $ata =rotection Act.

Also descri%e %ac0up strate" e+plainin the followin

Jho does the %ac0upHow lon it will ta0eJhen is it done:edia usedSie of files to %ac0upStorae of media

Archi'in of %ac0ups

+ata Si;e Cacuation

nclude a ta%le as %elow to show the estimated ma+imum sie of the %ac0up

Fie 'ota Si;e of $ecord

Appro< ma


12/15

.-. 'e#t #trateg" > pan

( mar0s

'e#t #trateg"

A test strate" is not &ust a standard test plan to %e applied to the e'entual solution %ut should include details ohow the solution will %e tested durin de'elopment and post de'elopment acceptance testin %" the end user.

=ro'ide the rationale %ehind "our choice of test data for each stae of the de'elopment and testin process.

!al0 a%out how "ou will use each of the followin

>lac0 >o+ !estin ? !his tests if the s"stem performs its o'erall functions e.. performs sorts or sa'es

the record. t tests the output and not how it achie'es the output.

Jhite >o+ !estin ? !ests each procedure or module indi'iduall".

Palidation !estin Normal B+treme Brroneous

Acceptance !estin How will "ou decide if it meets the oriinal criteria and requirements of the user.

!here should %e end user in'ol'ement.

'e#t Pan

'e#t NumberWhat to

'e#t'"pe of

'e#t'e#t +ata

U#ed)


13/15

4 S*F'WA) +)/)(*P3)N' AN+ ')S',NG

Software de'elopment 16 mar0s!estin 1- mar0s

9ou can structure this as "ou wish %ut what wor0s well is to co'er one module of the proram at a time. ncludethe code for a module 4suita%l" annotated and indented of course5 and show what the module does for

e+ample with a screenshot. !hen include e'idence of the rele'ant tests for this module as screenshots photos'ideos or other.

!o %e in the top mar0 %and "ou need to include testin durin de'elopment post de'elopment and usertestin.

,or %eta testin "ou could i'e "our end user a questionnaire to allow them to chec0 the requirements weremet and identif" impro'ements that are needed.

!he %est pro&ects show clearl" the proress of the solution and the pro%lems that were o'ercome. !here arestron lin0s to the desin section when "ou carr" out "our test plan and when "ou show how "ou ha'e coded"our alorithms.

A suita%le structure for the documentation would include a section for each unit containin

the section of code correspondin to each 0e" alorithm

how "ou tested the unit at the time with some e'idence such as screenshots

how "ou o'ercame an" pro%lems

reasons for an" ma&or decisions a%out the code "ou wrote

the code for the unit 4perhaps lea'in Q%orin %its* in a supportin file5

After the documentation of each unit "ou need to document the %eta testin. Some students repeat their testplan ta%le with the results of the tests. 9ou need interation testin to show a path throuh the 'arious units

once the proram is complete and "ou can show this in a 'ideo. 9ou should aim to show a complete paththrouh the proram in "our final demonstration.

All of the followin contri%ute to hih mar0s

@ood choice of identifiers

Jell commented code includin a description of what each routine achie'es 4where this is not o%'ious5

B+tensi'e 'alidation and other features to ma0e the application user?friendl"

9our own procedures and functions with parameters to ma0e them 'ersatile

Sophisticated sortin and searchin

B'idence pro'ided for unit testin %eta testin and end?user testin

!horouh testin with t"pical e+treme and in'alid data !estin of alorithms

As with the rest of the report appropriate use of the terminolo" learned durin the course



14/15

5 +*CU3)N'A',*N

1F mar0s

;n screen help is the ma&or element for the documentation mar0 and "ou must pro'ide e'idence of this to etfull mar0s. f "ou*'e shown screenshots elsewhere in the pro&ect then "ou could refer to those paes.

Help should include

clear uidance oranisation of input and output

help features

useful error messaes as appropriate to the proram

Also include supportintechnical documentation the user requires to ma0e use of the pro&ect. !he user uidecan %e in an appendi+.

)se these headins

nstallation

!"pical use

!rou%leshootin >ac0up

;n?screen help

,-(- pro&ect 1- "our name/


15/15

& )/A(UA',*N

&-$ +egree of #ucce## in meeting origina objecti6e#

- mar0s

!he e'aluation should co'er each of the o%&ecti'es and pro'ide references to the e'idence from testin anduser testin and feed%ac0 to show how well these ha'e %een achie'ed.B+plain how the o%&ecti'es ha'e %een met don*t &ust list them and sa" Qmet*. =ro'ide the pae reference to

e'idence such as a screenshot.

&-2 U#er?# re#pon#e to the #"#tem

3 mar0s

As0 the user to summarise their deree of satisfaction with the s"stem and discuss an" faults that could %efi+ed in the future. ,or e+ample is the s"stem user?friendl"K

&-. +e#irabe e

Documents

F454 Whole Project Template (2)