Table  of  Contents  SOFTWARE  PROJECT  ENGINEERING  .........................................................................................  2    INTRODUCTION  .............................................................................................................................................  2  

 REQUIREMENTS  ............................................................................................................................................  2  

 DESIGN  DOCUMENT  ....................................................................................................................................  4  

 TEST  PLAN  ......................................................................................................................................................  6  

 Meeting  Minutes  ...........................................................................................................................................  6  

 Back  and  Frond  End  Design  code  and  Graphical  User  Interface  .............................................  7  

                                                                     

 

SOFTWARE  PROJECT  ENGINEERING    

INTRODUCTION    For  this  project  module,  we  were  required  to  work  in  as  a  team  (students  from  Robert  Gordon  University,  Aberdeen  and  students  from  International  Institute  of  Information  Technology,  Bangalore)  to  design,  build,  test  and  evaluate  a  mobile  software  application  using  the  Agile  methodology.  The  aims  and  objectives  of  the  project  were  to  provide  students  with  the  opportunity  to:  

• Gain   first-­‐hand   experience   of   the   principles   and   techniques   required   to  become  an  effective  member  of  a  software  development  team  

• Use  selected  techniques  software  project  management  best  practices  • Undertake   software   development   activities   including,   project   planning,  

requirements   gathering   and   analysis,   system   design,   software  implementation  and  testing  

• Perform  object-­‐oriented  analysis  and  design  • Consider   the   broader   legal,   social,   ethical   and   professional   issues  

associated  with  developing  software  applications  • Work with others to develop software in a collaborative project to satisfy a

customer demand  • Use  software  engineering  best  practices  in  the  course  of  the  project  • Use Internet hosted collaboration tools  • Learn about mobile device software development  

REQUIREMENTS    The  requirement  models  are  classified  as  follows:    

Software  Development  Tools    We  were  required  to  use  Android  Software  Developer’s  kit  (SDK),  which  includes  a  fully  configured  update  version  of  Eclipse  development  environment.  We  were  also   required   to   use   the   Android   Gingerbread   (V2.3)   release   as  mobile   phone  Operating  System  version    

Software  Development  Process    We  were   required   to   use   a   combination   of   Scrum   (Schwaber   &   Beedle,   2001)  (Schwaber   2004)   and   Extreme   Programming   (Beck   &   Andres,   2004).   These  methods   requirement   process   role   definitions   in   scum   and   the   following   roles  were  defined:  

• Product   owner:   The   customer's   representative   on   the   project.  Responsible   for   explaining   requirements   and   deciding   priorities.  Academic  staff  will  be  the  product  owners  on  the  project.  

• Scrum   master:   The   scum   master   is   a   team   leader.   Responsible   for  ensuring  the  team  follows  the  scrum  method  correctly.  Also,  responsible  for   protecting   the   team   from   any   distractions   or   blockages   confronting  the   team.  The  scrum  master  will  make  resolve  disputes  within   the   team  and  make  the  final  decision  where  team  members  can't  reach  agreement.  

• Team  members:   The   rest   of   the   development   team   are   team  members.  This  includes  (at  least)  designers,  requirements  analysts,  developers  and  testers.  

a. Testers   work   with   developers   to   define   and   execute   test   plans.   Tests  scenarios  and  results  should  be  recorded  

b. Requirements  analysts  liaise  with  the  product  owners  to  understand  and  elaborate  requirements.  They  may  prepare  storyboards,  use  cases  or  class  diagrams   (depending   on   the   types   of   product)   to   disseminate   details   to  team  members.  

c. Developers  write  and  unit  test  code  d. Integrator   integrates   code   releases   to  maintain   a  working   repository   of  

code  for  the  team.    

Application  Requirements  (User  stories)    High-­‐Level  Requirement  Epics  

1. As  a  survey  participant,  I  want  to  be  able  to  fill-­‐in  survey  questionnaires  while  I  am  on  the  move,  in  order  to  inform  and  influence  survey  owners.  

2. As  a  survey  owner,  I  want  to  be  able  to  gather  qualitative  and  quantitative  information,  in  order  to  allow  evidence-­‐based  decision-­‐making.  

3. As  an  administrator  I  want  to  be  able  to  create  and  test  surveys  in  order  to  meet  the  needs  of  survey  owners.  

1. ,   I   want   to   see   the   collated   scores   of   my   survey   results,   in   order   to  understand  survey  participant  responses.  

2. As   a   survey   participant,   I   want   to   complete   surveys   easily,   in   order   to  provide  information  quickly.  

3. As   an   administrator,   I   want   to   create   a   survey   question   using   a   5   or   7  value  Likert  scale,  in  order  to  meet  the  needs  of  the  survey  owner.  

   User  Stories:  User   stories  were  defined  and  divided   into   three   sprints/iterations.  Below   is   a  list  of  all  the  User  stories.  I. As  a  survey  owner,  I  want  to  see  collated  survey  response  data  presented  

clearly,  so  I  can  easily  understand  survey  participant  responses,  so  I  can  make  good  decisions.  

II. As  an  administrator   a   I  want   to  define   the  question   text   on  Likert   scale  survey  questions,  in  order  to  meet  the  needs  of  the  survey  owner.  

III. As   an   administrator   a   I   want   to   define   the   legend   text   on   Likert   scale  survey  questions,  in  order  to  meet  the  needs  of  the  survey  owner.  

IV. As   an   administrator   a   I   want   to   define   the   legend   text   on   Likert   scale  survey  questions,  in  order  to  meet  the  needs  of  the  survey  owner.  

V. As  a  survey  participant,   I  want  to  give  yes  or  no  answers  to  appropriate  questions  in  order  to  express  my  opinion  to  the  survey  owner.  

VI. As  a  survey  participant,   I  want  to  type  written  responses  to  open  ended  questions  in  order  to  express  my  opinion  to  the  survey  owner.  

VII. As   a   survey   participant,   I   want   to   navigate   forwards   and   backwards  between   survey   questions,   in   order   to   compare   and   refine   my   survey  responses.  

VIII. As   a   survey   participant,   I  want   to   be   able   to   save   (and   later   resume)   a  partially   completed   survey   in   order   to   choose   convenient   times   to  respond  to  survey  questions.  

IX. As  a  survey  participant,   I  want   feedback   that  my  survey  responses  have  been  received  in  order  to  express  my  opinion  to  the  survey  owner.  

   

DESIGN  DOCUMENT    

 Fig  1(Class  Diagram)  

 Fig  (1)  shows  the  UML  class  diagram  for  the  survey  application.  It  contains  eight  classes   which   represent   the   different   activity   platforms   on   the   android  application.  This  includes;  

• openEnded  activity:  creates  and  manages  an  open  ended  question.  

• YesNoQue   activity:   creates   and  manages   yes   and   no   questions  with   the  functionality   of   having   the   survey   participant’s   responses   saved   so   that  when  he/she  navigates  back  and  forth,  data  is  not  lost.  

• LikertScale  activity:  creates  and  manages  either  a  5  or  7  point  likert  scale  question.   Also   allows   the   survey   owner   flexibility   on   choosing   the  different  options  for  the  lickert  scale  question-­‐type  chosen.  

• Survey   activity:   this   manages   the   survey   created   by   the   survey   owner  differentiating   it   from   other   surveys   and   allowing   the   survey   owner   to  receive   the   right   responses   for   the   survey   requested   by   means   of   the  survey  name.  

• Question  activity:  This  activity  generates  the  different  types  of  questions  requested  by   the  survey  owner   to  be   included   in   the  survey.   It  uses   the  createQuestion  method  to  invoke  methods  from  the  different  classes  that  contain  the  question  templates.  

• Admin   activity:   Concerned   with   the   creation   of   questions   for   a   new  survey,   deleting   questions   and   responses   from   the   database   and  displaying  the  data  from  the  database.    

• SurveyOwner  activity:  Takes  care  of  data  from  the  survey  and  responses  from  the  survey  participant.  

• DatabaseHandler   activity:   Handles   the   connection   of   the   different  activities   to   the   database   with   the   HTTPpost   parameters  method   using  PHP,   JSON   (JavaScript   Object   Notation)   Parser   and   then   JavaScript   and  Ajax  for  the  web  end.  

 

 Fig  2  (Use-­‐Case  Diagram)  

 

Fig   (2)   illustrates  how   the  user   communicates  with   the  application  and   can  be  further   divided   into:  Main   scenario,   and  Extension.   This   is   briefly   explained   in  the  use  case  text  depicted  in  the  figure  below.                Mid-­‐Level  Requirements  As  a  survey  owner                            

TEST  PLAN  Our  test  plan  was  subject   to   the  each  task  set  within  each   iteration.  The  points  listed  below  form  the  core  of  our  test  plan  across  the  different  iterations  

• Testing  was  done  across   the  Eclipse  and  Android  software  development  kit  (SDK)  platforms  on  different  Android  Virtual  Devices  (AVD’s)  

• Unit  testing  was  done  after  implementation  of  every  functionality  • Database  connectivity  functionality  was  tested  within  local  environments  

as  well  as  on  distant  live  server  • Final  integration  testing  was  done  to  ensure  the  application  runs  properly  

on  a  real  mobile  device      

Meeting  Minutes  • We  held  general  meetings  with  the  product  owners  twice  every  week  • Every   meeting   began   with   a   status   update   where   each   member   of   the  

team  explained  what  he  or   she  had  been  working  on  since   the  previous  status   update.   We   were   also   expected   to   indicate   if   we   had   caused   or  experienced  any  blockers  during  these  status  updates.  

• We   held   side   meetings   between   team   members   (without   the   product  owners)  at  least  once  every  week.  This  provided  us  with  opportunities  to  resolve  pending  issues  that  were  unattended  

Use  Case  Level:  Sea  Level  Main  Scenario:  

1. Survey  participant  launches  the  Application  2. System  Initializes  survey  and  welcomes  the  user  3. Survey  participant  begins  the  survey  4. Survey  participant  answers  survey  questions  5. Survey  participant  ends  the  survey  6. System  saves  responses  in  the  database  7. System  Initializes  the  survey  questions  

Extensions:  4a:  Survey  participant  navigates  backwards  and  forward  

.1:  Survey  participant  returns  to  change  a  previous  response  

.2:  System  saves  responses  made  by  the  user  4b:  Survey  participant  returns  to  complete  a  partially  filled  

survey  6a:  Survey  participant  receives  feedback  message  that  responses  have                    been  received  

 

• Team  members  were  also  expected   to   relay  any  challenge  or  difficulties  experienced  as  well  as  proposed  difficulties  and  this  helped  to  structure  our  project  development  for  futuristic  additions  and  modifications  

   

Back  and  Frond  End  Design  code  and  Graphical  User  Interface    

 Fig  3:  .java  and  .XML  codes  from  back  end  used  on  Android  for  designing  the  

mobile  GUI    

 Fig  4:  .java  and  PHP  scripts  used  to  send  and  receive  data  between  mobile  device  

and  remote  Database      

 Fig5:  Front  end  webpage  design  where  surveys  are  created  by  the  survey  owner  

 Fig  6:  A  template  for  creating  a  7  likert  scale  question  

                                       

REFERENCES    Beck,  K.  &  Andres,  C.  2004.  Extreme  Programming  Explained    2nd  ed.,  Addison  Wesley.    Schwaber,  K.  &  Beedle,  M.  2001.  Agile  Software  Development  with  Scrum  ,  Upper  Saddle  River,  NJ,  USA:  Prentice  Hall.    Schwaber,  K.  2004.  Agile  Project  Management  With  Scrum  ,  Redmond,  WA,  USA:  Microsoft  Press.