Home

Interactive Door Sign - Department of Computer and Information

1. Problems and risks Summary of cutomer meeting 154 Summary of last advisor meeting Plan for the next week Other Week workload Team member Meeting Lecture Individual Group Total Andreas Nordahl David Andr ssy Eilertsen Elise Boinnot Igoris Tirmailovas Knut Esten Melandsg Neksa Michal Kraj ek Sibel Ayper Tasdemir Week total hours Individual work description Team member Description Andreas Nordahl David Andr ssy Eilertsen Elise Boinnot Igoris Tirmailovas Knut Esten Melandse Neks Michal Kraj ek Sibel Ayper Tasdemir 155 Appendix C Gantt chart 156 SE pE EE 7E TT OT YT UJ TT OT bT H4 s p 0 pajajduuoo 14 yuuds oor 9 TE ITODLvVI Wd TT OT p anL s p 8 Aatliqesn zo oot SE 1 TTOTVTI TT OT Y n sAp 8 seqezep 94 soot YE TE TT OT YT Uy TT OT p any skp 8 Ajajowas a3essauu ajepdn z4 oor EE TE LOTT Wd TT OT Y an s pg uoneuuojur Su Aejdsip T4 ot ZE 6c TT OT Y an TT OT E UON Ap T Suruuejd 3uuds o0T TE TOT eT Hd TT OT E UON SAP 6 T 1uds x oot OE LC TT OT E UON TT 6 97 UON skp S aunpanyauy o0T
2. 133 follow as nearly everything was finished on time It was also one of the easiest ones to break No deadlines meant we could decide how long we were going to work on our parts We could perhaps have had more deadlines or milestones to help with this rule Not too many beers were bought as we did not keep track of who was late and it was decided later on in the project that this was not a suitable punishment It would have been enough for the project manager to simply have a private chat with those who for example were late to meetings or did not hand in their work on time Implementation We followed the coding convention mentioned in the Planning and Quality assurance chapters see section 6 1 2 and 2 7 2 All class names methods and variables are written in English and classes and variables are described using Javadoc Thus it was as predicted very easy to maintain the code and for others developers to understand it and be able to connect everything Also for further developers it will be quite easy to understand the code thanks to Javadoc and comments in the code As mentioned in section 2 1 2 we used SVN as a revision control system It was a very good choice for us because we did not have any issues with it not a lot of conflicts no merging etc So it was an easy way to share the code between developers and to maintain the current version of it Documentation Using Dropbox we got a full overview of the various section
3. All the following functional and non functional requirements stated in this section are elabo rated by the customer through the compendium meetings and e mail and interpreted by the project group 3 2 1 Functional requirements e BR1 The door sign shall display non sensitive information about the person working in the office e BR2 The owner of the door sign should be able to create edit and delete a message that shall be displayed on it from a remote device e BR3 The door sign should be interactive to people wishing to contact the person in the office with a video call button camera microphone and display e BR4 If the receiving device to the owner of the office is connected to the Internet it should be able to answer calls if nothing else is stated by people at the door sign e BR5 If the receiving device to the owner of the office is not connected to the Internet the caller will be able to leave a short video audio message e BR6 If the owner of the office does not wish to be contacted e g stated in a short message it should not be possible to make a call to him her Only the option to leave a short video audio message is available 17 e BR7 When the receiving device to the owner of the office has established a connection to the Internet it should receive any messages sent to him her during the offline period with additional information e g a timestamp e BR8 The recording of a video audio message to t
4. On the other hand at the end of the project we were able to provide a fully functional ap plication with all requirements fulfilled even though our workload was below the expected amount The picture 11 1 shows our weekly workload Work done before the first advisory meeting when our effort registration began was added to week 36 The chart reflects our progress During week 38 and 39 we faced problems with our original device and the device limited simultaneous work This caused delay and prolonged the preliminary studies and so we had only one week week 40 to finish our architecture studies The next four weeks were dedicated to implementing the system and during this period to gether with week 45 we faced problems with our workload as described earlier in this section During week 45 we prepared a plan for our usability study and executed it The last two weeks were spent mostly on finalizing the report and making a presentation 139 Working hours 200 150 100 50 36 37 38 39 40 41 42 43 44 45 46 47 Week No Figure 11 1 Weekly workload 140 Chapter 12 Conclusion This chapter serves as a summary of our project We will answer two questions whether or not we managed to create the product our customer wanted and whether or not we accomplished our oum goals and expectations We will end the chapter with an explanation of the future development of our product by giving a rundown of its limitations and t
5. Responsible Elise Boinnot Requirements F8 Precondition The application is launched Execution steps Expected result 1 Press the button Calendar 2 Press the button Cancel After pressing the button Calendar office owners schedule for the current day is displayed Pressing the Back button will return you to the main screen Table 7 10 Calendar test case 80 Chapter 8 Sprint 1 As part of our project our system has requirements that must be implemented This requires planning which is covered in this chapter When the requirements in our first sprint have been implemented they need to be tested to make sure they have been fulfilled 8l 8 1 Planning Given the small amount of requirements and rather large implementation team there will only be two sprints In the first sprint we will to fulfill all high priority requirements and prepare foundation for the second sprint 9 During the second sprint we will finish the implementation part and test the system 8 1 1 Duration The start of sprint 1 was planned to October 3th and it lasted for two weeks The first sprint was started as soon at the software architectural work was done The first day of the sprint was dedicated to planning and the actual duration of the implementation was 9 days 8 1 2 Resources Total estimated resources for this sprint were 180 person hours Our team has 5 developers and with respect to 25 hours of work during one week we estimate
6. 31 32 25 viewforum php f 112 amp start amp sid 4c263d0467b63d7178ec586bfff14efc 2011 Vis ited 21 09 2011 Lti civil org CIVIL Capturing Images and Video In a Library online http 1ti civil org 2011 Visited 27 10 2011 Microsoft MSDN Academic Alliance online http msdn microsoft com en us academic bb250591 2011 Visited 07 09 2011 Mimomonitors com Mimo Support site online http www mimomonitors com pages customer support 2011 Visited 28 10 2011 Dong Ngo Mimo um 740 monitor http reviews cnet com displays mimo um 740 monitor 4505 3174 7 33513709 html Visited 15 11 2011 Oracle Documentation for class Socket Java http download oracle com javase 1 4 2 docs api java net Socket html 2011 Visited 21 09 2011 Oracle com Sun Oracle s Java Media Framework online http www oracle com technetwork java javase tech index jsp 140239 html 2011 Visited 23 10 2011 OWASP Microsoft Threat Modeling Process online https www owasp org index php Threat Risk Modeling 2011 Visited 10 11 2011 OWASP OWASP Risk Rating Methodology online https www owasp org index php OWASP Risk Rating Methodology 2011 Visited 10 11 2011 Winston W Royce Managing the development of large software systems http www cs umd edu class spring2003 cmsc838p Process waterfall pdf 1970 Vis ited 10 09 2011 Jeff Sauro Measuring Usability with the System Usability
7. of the owner of the office has established a connection to the Internet it should receive all messages sent to him her during the offline period with additional information e g timestamp e Q1 You should not be able to exit the DoorSign application and access other parts of the device e Q3 You should be able to have a normal conversation through the video conference Use cases of these requirements with detailed descriptions can be found in section 4 1 3 Low Level Use Cases 9 2 Implementation 9 2 1 Recording and storing video message The Mimo device we received from the customer was communicating perfectly with certain software available on the Windows OS However official Windows software like Windows Media Player Sound recording etc was not able to detect the hardware see appendix D 3 Skype was able to both pick up the video and sound of the device when plugged in into a computer with the Mimo UM 740 drivers obtained from their website 17 But other components like Windows Media Player did not discover the device The official standard Java Media Framework JMF developed by Sun Oracle 20 was only able to detect the the microphone but not the integrated web cam A fair amount of the hours spent on these two requirements was searching for third party libraries that would discover both the web cam and microphone on the device The implementation consists of three parts Recording audio recording video and
8. the tester has to understand the code and the system He also needs to have technical knowledge to design and run the tests Black box In black box testing the tester does not need to know or even understand the code The tester only needs to know the possible inputs and the expected outputs associated The inputs and outputs are based around the requirements 74 7 2 2 Testing levels There are different levels of testing Low level tests focus on the small parts of the system whilst high level test are concerned with the system as a whole Low level tests should be completed before starting on the higher level tests Therefore all tests in this chapter will be ordered from low level to high level Unit test Unit test is a low level test Small units of the project are tested Classes methods variables etc to make sure that each small part works as expected Modul test Modul tests are used to test entire modules Module testing will make sure that the coordination and communication between the different entities works as expected System and integration tests Once each module works as expected we want to assure that the different modules that the system consist of works correctly when put together This is the purpose of system and integration tests Testing the coordination and communication between modules and interfaces 7 2 3 Templates The table 7 2 presents the template for each test Item Descript
9. 2 From figure 10 5 we can see that each task was evaluated as being very easy or easy by more than 8096 of the participants These results are sufficient given the success criteria presented in section 10 5 6 Part 3 SUS questionnaire The last part of the usability test was answering a System Usability Scale assessment see section 10 3 The figure 10 6 presents the results of this assessment and the distribution of the different scores obtained 128 65 70 75 80 85 90 95 100 Score OSUSscores W Average score Figure 10 6 SUS evaluation Part 3 As we can see in figure 10 6 almost all the score are higher than 75 and the average is around 89 5 This score is excellent according to figure 10 1 and more than what was expected in section 10 5 6 which was a score higher than 70 Summary A summary of the results for the different parts of the questionnaire is shown in table 10 20 Part question Success Failure Part 1 question 1 J Part 1 question 2 V Part 2 V Part 3 v Table 10 20 Summary of results Even though many of the participants did not fully understand the purpose of the system most of them were able to recognize all the available functionality Moreover the participants rated most of the tasks given to them as very easy or easy and the average SUS score is excellent So we can conclude that our application has good usability It is easy to use easy to learn and useful However given the
10. 5 to obtain the overall value 10 6 6 Success criteria Goals defining whether or not usability was achieved were prepared based on metrics The numbers in the following descriptions refer to the usability metrics in section 10 6 5 123 1 More than 8096 of the answers regarding the tasks should be in the very easy or easy part of the questionnaire 2 The ratio between the number of successful operations compared to total operations should not be below 8 10 3 SUS score should be higher than 70 see figure 10 1 for meaning 10 6 7 Questionnaire The questionnaire consists of two parts The first part utilizes a five point rating scale with appropriate labels and will be used for evaluating tasks see table 10 12 The participants will circle the appropriate number on the scale as well as write any comments they may have in the comments section The second utilizes System Usability Scale see section 10 3 Questionnaire part 1 Tasks question Very difficult Very easy 1 Add door sign contact name tdt4290 password tdt4290 Oo OF OF n DO 2 Update a message O O O O o 3 Answer a call O o o0 rl n 4 Receive a video message E o o O O 6 Remove door sign contact Oo o O O O Comments Table 10 18 Task list questionnaire office owner s perspective 124 Questionnaire part 2 Tasks question Strongly disagree Strongly agree gt I think that I
11. 6 TT OT 8Z 144 TT 6 97 UON SAP ET bT uonequawajdwy oor 8 ST 07 97 TT 6 9Z UON TT 6 97 UON skp O pa1ejduuoo aseyd Suiuuejd 9 uorjonpoau y oot LTC SCvc ll 692 UO TT 6 EZ ly APT leaoudde syuawasinbay oot 9 TI6OZANL TT 6 6 H4 sAp 4 sisA eue stu oot SZ EZ TT 6 EZ Uy TT 6 ETANL skp 8 uoleas9 ase esf oor VC TIGELANL TT 6 6 H4 S pz uoneznionud oot EZ 6 TT 6 6 H4 TT 6 Z ui skp S 3uL 3yje2 sjuawasinbay oot CC TT 6 97 UON TT67 14 SAP 9T suoyyeo9ads syuawasinbay oot LC 6r TT 6 EZ ui TT 6 TZ PIM S P 6 T sanss yun9as o00T OT LUST IT 6 TZ PAM TT 6 07 NL Apr A891es JuaWdojanaq oor 6L 6 TT 6 07 aNL TT6 7 Uy sAp ZT suonnios e qissod o0T ST 6 TT 6 9T Uy TV Uy S p OT is jeue 19 q81 x oot L TT 6 EZ ui TT67 H4 S P 6 VT saipnis ald oot 9T VI TT 6 EZ ui TT E ZZ NUL skp Z uoneaJ uejd jeuly oor ST l TT 6 TZP M TT 6 LT IS S p suejd ssa oot YT rai TT 6 9T uj TT 6 ETANL S p y suoneuunsa au oot ET ITI TT6ZTUOMN TT 6 6 ly skp 7 syse Suowe sdiysuoije ay xoot CL 6 TT 6 8 NUL IT 67 ui sAp y sam soot TT TT 6 EZ 14 IT 67 Hd S P T ST Sujuuejd paforg oot OT 8 TT67 Wd TT 6 T NUL APT spJepuezs pue s zejdwa L y oot 6 TT 6 T NUL TT 6 T NUL siy 9 K80jouu e1 uonesadoo 8 9 TT 6 T NUL TTS TE PIM APT uoleziuesio weal 96001 L TT 8 TE PIM TT 8 0 en Apr 440 pb 199014 96001 9 TT 6 EZ Hd TT 8 0 enl S P 88 81 ennoourp 1991014 oo S TT TT EZ P M TT 8 0 anL sAp T9 quawaseuew paloid
12. A AA e Oe ng 53 tons Physical view 2 Loi Fur as gre x eA te oA d obo D dea 53 5 924 JrOGOSS VIOW X stoke dede A te ele te Belk ut 57 5 6 Architectural rationale LA A A A OS AA 60 5 7 Resulting architetural changes y uod ue i b e e e ES 60 5 7 1 Realized logical MEW RA ue ILE NIRE MO Sed os 60 Quality assurance 68 6 1 Communication s comen tao A 8m deat Ue ao qs WIS 69 6 1 1 External communication ooa b uie een dog ere CENE 6 ed 69 6 1 2 Internal communication e opens ew af hve ARMED UR ENNCOSMECA eee Se RS 69 Gu Templates Ets arte a e ee E tan a ce Be Pe ral 6 2 1 o meetihgg sc c oti a ee ER o ge tel Re a Rl a er ot ies 71 6 2 2 Customer meetings asta ia a GB e fn 71 6 2 3 Weekly report oa veu rA uid as di aa 71 A a S ae dS a Rut us o eB e pe a Aah wA EB as S er eee E E eed 72 Testing 73 SL Orales plant 45 5 Ea ERAS amet deed ede ut dn 74 2 a AA IO n 74 T2 4 Test methods cl A A A eg 74 1 4527 a A A Vout o d AE oe o s 75 EA Templates Si A an i na A a a a eS D ah 75 Midi est CASES T m nec Bay De age ae ae ee e Oe ee eg E opes RE DIS 75 Sprint 1 81 Silo APIS dra hh Stig Als a ds EC AA a A 82 sdil Duration a a a ta eic tenus ibn tenue a tu Aes 82 SD R SOUICeS caia a a a ER o deo 82 8 13 prat goale a 6 a cn o gree ae Bee rats a 82 Sido Sprint backlog da nla uem eo a a A et it ke 82 Boo Implementation s ati a sp io el do ra 83 8 2 1 sabi and GUL 0 da m ls Ale hod A A E AA E e ts 83 322 Database roto Pal
13. F Project charter Project Interactive Door Sign Created by Michal Kraj tek project manager Date 3 9 2011 Phone 45126315 E mail michalk stud ntnu no Version no 3 Introduction Our project Interactive Door Sign is solved within the NTNU course TDT4290 Customer Driven Project Its purpose is to give students the opportunity to go through all the phases of a real software project and gain experience from it The project is given by IDI NTNU and must be solved in close cooperation with their representatives Mission Our customer NTNU university IDI department has given us a monitor that can be used with a computer running Windows The mission of this project is to develop a software system that will enable us to use this monitor as an interactive door sign Stakeholders e Project realization team Group 7 e Customer NTNU IDI represented by Torstein Hjelle torstein hjelle idi ntnu no e Advisor Muhammad Asif muhammaQidi ntnu no The role of the project team is to fulfill all requirements given by the customer The team must go through all phases of a typical software project be able to provide a final report and defend the results in front of the customer and external censors Our project realization team has 7 members Michal Kraj ek michaklGstud ntnu no Project manager David Andr ssy Eilertsen davidae stud ntnu no Scrum master Customer contact 162 Sibel Ayper Ta demir tasde
14. GUI components This framework will be very useful for the implementation of our application 3 9 3 SQL SQL is a query language used for managing data in relation to database management systems It is used for creating updating and searching data from databases In our system it will be used to fetch an office owner s data name title contact information etc from a MySQL database 3 9 3 Eclipse We decided to use Eclipse Integrated Development Environment IDE in our project because a majority of the implementation team has had experience with it from earlier projects Moreover Eclipse has a good plug in called Subclipse for Subsversion SVN which is very easy to use even for people who are not familiar with SVN SVN is a software versioning and a revision control system distributed under a free license It is used to maintain current and historical versions of files such as source code 32 Chapter 4 Requirement specification This chapter introduces the requirement specifications of our project It covers the behav ioral requirements through use case descriptions and functional and non functional requirements through the derivation of several sources included but not limited to use cases customer meet ings and the problem set The purpose of introducing this chapter is to give any individual with or without any technical background a straightforward explanation of the system s functionality behavior overall pre sent
15. Hardware security Deliverables e Software application e Client software running on the office owner s computer 163 Budget The project is non commercial Schedule The project starts on August 30 2011 and its duration will be 13 weeks The final presentation will be on November 24 2011 High Level Work Breakdown Structure 1 Project directive Project planning Preliminary studies Requirement specifications Architecture studies 2 3 4 5 6 Scrum sprint 1 7 Scrum sprint 2 8 Project evaluation and conclusion 9 Presentation and demonstration Communication and meetings The team is going to have at least one meeting per week with all members and smaller meetings in compliance with needs There will also be at least one meeting per week with the advisor Meetings with the customer will be planned as needed The communication language will be exclusively English Initial project risks Risk assessment Probability Impact Inaccurate project plan Lack of motivation Lack of communication internally Lack of communication externally Problems with the implementation Problems with hardware Sickness Lack of expertise with SCRUM M Oo 10o 0t dg C2 b2 cro e CET E OE mundum Change control If the device has limitations so that certain requirements cannot be fulfilled we should be al lowed to change them All changes to the requirements or the project
16. Scale SUS http www measuringusability com sus php February 2011 Visited 04 11 2011 Skype com Skype App online http www skype com m 2011 Visited 12 09 2011 Peter Stevens A simple scrum sprint review http agilesoftwaredevelopment com blog peterstev simple scrum sprint review 01 21 2009 Visited 13 09 2011 Usability gov Usability test plan template http www usability gov templates docs u test plan template doc Visited 30 10 2011 waterfall model com Waterfall model all about the waterfall model http www waterfall model com Visited 28 10 2011 Wikipedia Scrum development http en wikipedia org wiki Scrum development Visited 02 11 2011 Wikipedia Usability http en wikipedia org wiki Usability 04 11 2011 Visited 09 11 2011 Wikipedia Waterfall model supporting arguments http en wikipedia org wiki Waterfall modelfsSupporting arguments 06 05 2011 Visited 10 09 2011 Wikipedia Software testing http en wikipedia org wiki Software testing 16 09 2011 Visited 28 09 2011 146 33 Wikipedia Java s garbage collection online http en wikipedia org wiki Garbage_ collection 428computer science 429 2011 Visited 27 10 2011 34 Xuggle com Xuggler online http www xuggle com xuggler 2011 Visited 27 10 2011 147 Appendix A User and installation guide A 1 Installation guide 1 Mimo Drivers The links below will guide to to a site where
17. This is a good way to gain experience quickly during a project Structure and guidance The Waterfall model is very vague What each phase should or should not do is oftentimes unclear It is also outdated The Waterfall model has remained more or less unchanged since its inception 23 while software has increased in complexity and time Scrum on the other hand is clearer because it has a set of predefined rules roles and tasks This makes each step of the model easier to understand and follow Development The tangible results are achieved more quickly in Scrum because of the incremental sprints There is little focus on documentation and more on actual develop ment contrary to the Waterfall model 3 9 Development technologies Java will be our main programming language due to our customer s requirements integrate Skype We will be using SQL to communicate with the database 3l 3 9 1 Java Java is an object oriented programming language that has been around since 1995 Since then it has grown to be powerful yet simple enough to understand It is widely used today to develop applications of various scales It will be used to develop our device application We chose this language because most of the implementation team has had a previous experience with it and Skype has a Java API which will be used for our application More over Java has a Graphical User Interface GUI framework called Swing which provide a predefined set of
18. Usability Q2 Designing GUI M H 6 Record video M d Store video M 8 Video conference M H 9 Send video messages L 10 Performance M 11 Calendar M Table 4 11 Product backlog 46 Chapter 5 Software architecture In this chapter we will discuss what our architectural drivers are and how they will affect our overall architecture We will cover tactics patterns and views we have chosen to use which will be rationalized at the end of the chapter Attribute driven design was used to create the software architecture In this section you will find an explanation of the architectural drivers and the tactics and patterns that will be implemented to satisfy them There is also a section with different views that explain the architecture in more detail from different perspectives 47 5 1 Architectural drivers The architectural drivers for this application will be the functional requirements F1 and F2 found in table 4 9 and the non functional requirements Q2 and Q3 found in table 4 10 The functional requirements are concerned with how information is stored and how it is updated Quality requirement Q2 describes how information is to be displayed visually so that the user interface is easy to learn and understand Q3 sets certain demands to the performance of the video conference functionality 5 1 1 Requirement F1 It is important that the application displays the correct information about the owner of the office All info
19. a solution where he did not have to use a custom made client application to update the messages Another drawback with Java Sockets is that the server part of the Java Sockets would need a static IP address for us to be able to connect to it Either that or we would have to route traffic to the port we are using through the NAT to the IP of our specific device There is a possibility of streaming video files avi mpeg etc between a server and a client by breaking down the file and or image into datagrams at the sender s side and then rebuilding them at the receiving side The issue here is whether or not it is possible to this with a video 25 conference to have a continuous bidirectional stream of data between the users through Java Sockets Another issue is that the datagram Sockets in an Android application may be reliant on the SIP library which is not available for Android 2 2 Regardless this is the only possible solution that we can with certainty implement on the Android device but the customer as explained in the introduction see Section 3 6 1 Mimo Monitor delivered a new device in hope of utilizing Skype or another third party chat software Twitter Introduction As the selection of a third party VoIP streaming and a messaging service was limited and we did not find a suitable solution we explored the possibility of separating the VoIP streaming and messaging part The best solution we could find was Twitter wh
20. after two 2 seconds of dialog Leave a video message to the office owner Start recording a video message for the office owner and cancel the recording after two 2 seconds Find out if the office owner has had a free time slot at 1 PM today Table 10 1 Task list The description of each task will follow the template given in table 10 2 Item Description Task ID Id of the task Name Name of the task Preconditions Conditions that have to be met in order to start the test Execution steps Steps to perform Expected result The expected results of the test Table 10 2 Task description template Description of the tasks 112 Item Description Task ID 1 Name Identify the office owner and his contact information Preconditions Database filled with testing data Execution steps Expected result 1 Participants are not allowed to touch the device Participant identified the office owner and his contact information Table 10 3 Task 1 description Item Description Task ID 2 Name Read the office owner s status message Preconditions Status message was updated Execution steps Expected result 1 Participants are not allowed to touch the device Participant read the status message of the office owner Table 10 4 Task 2 description Item Description Task ID 3 Name Make a call to the office owner Preconditions Person representing the office owner is ready to answer the call Exe
21. and other important components that had to be finished before the second sprint 9 could be started All the features from the sprint backlog were implemented with exception of usability study which was postponed successfully tested see section 8 3 and we received a very positive response from our customer As this was out first sprint we encountered several problems using SCRUM methodology and we took appropriate measures Sprint 1 prepared background for the next sprint by implementing communication between our application and the SkypeKit which is the basic building block for sprint 2 9 91 Chapter 9 Sprint 2 Our final batch of requirements is in our second sprint This chapter is structured like the previous one and will include the same sections planning implementation and testing 92 9 1 Planning The last sprint focused on implementation of remaining requirements and finishing the applica tion At the end of sprint 1 we wanted to have a fully tested and documented final product With the experience from sprint 1 we decided to adjust the way of our estimations and not focus on the worst case but rather on the most probable case Moreover we tried to set up more team meetings and do more of our work within a group As we have a good feeling from sprint 1 there were no other needs for improvements 9 1 1 Duration Sprint 2 was planned to start on October 18th Its duration was two weeks This sprint started
22. by pressing the button Cancel C 1 Press the button Record a video message 2 Press the button Start recording 3 Talk Expected result A The recording is stored and sent to the owner B The recording is cancelled and deleted Nothing is sent to the owner C The recording stops after 30 seconds Table 7 7 Record video test case 78 Item Description ID MOD 002 Name Audio call alias Video conference Date During sprint 2 Responsible Elise Boinnot Requirements F5 Precondition The application is launched and the owner is connected to his Skype Execution steps Expected result account 1 Press the button Call 2 a The owner answers Talkes fo a while and ends the call b The owner rejects the call c No response a The call was successful conversation took place and ended b The call was rejected c The call was canceled automatically Table 7 8 Audio call test case Item Description ID MOD 003 Name Download messages Date During sprint 2 Responsible Elise Boinnot Requirements F7 Precondition The application is launched Execution steps Expected result 1 The owner just connects to his skype account The owner can see and play all messages sent to him when he was offline For each message sent the date and an hour of the recording is displayed Table 7 9 Download messages test case 79 Item Description ID MOD 004 Name Calendar Date During sprint 2
23. customer found all the given tasks very easy to perform Even if one participant is not enough make any conclusions we are very satisfied with this result and it is more than what was expected in section 10 6 6 For the SUS questionnaire the score of our customer was 95 which is excellent according to figure 10 1 Summary One participant is clearly insufficient make any conclusions about the usability of our appli cation for the owner s perspective we are very satisfied with the feedback we got from our customer Thus from our customer s perspective the owner s perspective of our application has is very usable 130 Chapter 11 Evaluation and discussion In this chapter we will evaluate our process during the project to see what we did well and what we could have done better We will start with an assessment of our planning and use of the Scrum methodology before we move on to our architecture We defined some standards in our Quality assurance chapter that we will discuss here to see whether or not they were followed and how they worked out in general To sum up this section we will discuss our group dynamics on an overall basis and give a recap of how we handled our risks and if our planned risk management was good enough In the next section of the chapter we will evaluate our results meaning the fulfillment of our requirements how our architecture worked and the results from our usability study The latter will give great in
24. deca 28 46 Test id ntificat rs ds sale bee Rights AR en E Aden CUP dh od VO AAA 74 Testing template Fado a a e ened a dior dp 75 Display information test case oaoa a a a a 76 Database testcase e ubi d veu DA A eee Se Seu as 76 Display message test Cases ra c 25 a A E RE we 76 Update message remotely test case 2 TT Record video test case al S Ree Ro ho TROU ee 78 AMOO CALL testcase a erint erbe AAA AA AA a 79 Download messages test Case caos ala ae eos xU ms 79 Calendar test case y di dar la esrb eor Ria ena dues 80 SpriHt se Tibacklog c oa era a A e Ee a Rug 82 Description of ER diagram amp 21 cer oua diga te Rer dar nane ie P de ou AA 87 Display information test result a Seo OR O EA 88 Database test results ete ame a ri a e ME en dpud 88 Display message test result v uu edt oe a ve ES IeE EE Bae was 89 Update message remotely test result aa a a 89 Sprint 4 2 backlog o3 ubera mer ey aa pae m 93 Likelihood and Impact Levels e e 101 SOVEL E eim E so Sek E AA Gy se pus O o A dod 101 Access control likelihood 00 A A Id 101 Access control technical impact aci A GE x 102 9 6 9 7 9 8 9 9 9 10 9 11 9 12 9 13 10 1 10 2 10 3 10 4 10 5 10 6 10 7 10 8 10 9 10 10 10 11 10 12 10 13 10 14 10 15 10 16 10 17 10 18 10 19 10 20 Data corruption likelihood 1 34 ALEA a et a os SE edes 102 Data corruption technical impact y e x ere A AA ey 102 Databa
25. dis tributed under a free license It is used to maintain current and historical versions of files such as source code web pages and documentation Use case A description of a requirement can be represented through an use case It shows the steps one or more actors must perform in order to do something useful with the system Waterfall model A sequential development process which flows downwards you will not have the change to revisit renew already completed phases of the development White box testing White box testing is a method of testing software that tests the internal structure of an application The testers has to understand the code and the system They also need to have technical knowledge to design and run the tests Work breakdown structure A project management method tool used to break down larger tasks into smaller components tasks This makes them more tangible and easier to controll measure and schedule 167 Acronyms API Application Programming Interface CIVIL Capturing Images and Video In a Library CPU Central Processing Unit CVS Current Version System ERD Entity relationship diagram FPS Frames Per Second GUI graphical User Interface ICT Information and communications technology IDE Integrated Development Environment IM Instant Message IRC Internet Relay Chat JMF Java Media Framework RAM Random Access Memory RIAs Rich Internet Applications RTMFP Real Time Message Flow Protocol SDK S
26. guarantee this we will need coding standards As mentioned in section 2 7 2 all class names methods and variables should be written in English so that they are easily understandable for anyone who might look at the code at a later time Methods classes and variables should be described using Javadoc Formal descriptions explain exactly what something is meant to do and will make the code maintainable on a broader level Our programmers are coordinating their work using Eclipse and to prevent major problems all code should be formatted and all errors must be corrected by the individual programmer before the code is committed Documentation We also use Dropbox as a tool to share various files To prevent miscommunication and confu sion all files in our folder should have English names that reflect the files content If the file name is not descriptive we will have problems getting a full overview of which files we have and where they belong in the final document With correctly named files we do not have to open each document to find out what it contains we can simply look at the file name This also makes it easier for us to see what still needs to be done as documents can not be hidden in any way As well as being descriptive the file names should only contain lower case letters and num bers For spacing between words and numbers we will use underscores to prevent any errors associated with empty spaces in file names As the pro
27. have regular meetings as will be mentioned in the next section see 11 1 4 it would have been easier to follow and regulate Our weekly reports helped set the agenda for the advisory meetings This way we would get specific feedback on our work instead of vague comments we might have gotten if we had shown 134 up without a plan for what we wanted to discuss with our advisor The advisor also got a feel of our progress as our hours and work were presented at these meetings and in the report and would therefore try to give us some extra motivation to work even harder Testing A detailed evaluation of our testing has been presented at the end of our Usability study chapter see section 10 7 Here we have described the procedure of the testing and which standards we have had for our tests which helped ensure the overall quality of our product and evaluated the results 11 1 4 Group dynamics Despite different backgrounds of our team members our team worked well together and was able to handle the different situations that occurred during this extensive project There were not any major conflicts or disagreements among team members and minor problems were successfully solved The communication process in general could have been better As it is discussed in next section we had problems finding common time slots for meetings and this limited us Another point and great experience for the future is a value of investment into the team W
28. helped us create a large professional looking document with comfortable navigation without using additional time to format it Version control Subversion was chosen because some group members had used it before Since all members of the implementation team are also using Eclipse IDE it was easy to set up and maintain Dropbox For file sharing we chose to use Dropbox Even though there are better more powerful al ternatives offering more space and functionality such as Tonido Wuala and Live Mesh to mention a few Dropbox was chosen mostly because of its popularity and the fact that most of the group members were already familiar with it Other reasons included the lack of need in extra functions offered by the alternatives Even though alternatives offered the same ease of use it might have taken extra time for the group to get comfortable using them We used Dropbox mainly to share and store more static documents and informational material Below is our Dropbox folder structure listing content and explanations e Diagrams contains graphical use case and organizational diagrams in PNG format e Doc contains all ready to use files for the final report and the latest version of the compiled report in PDF format e Meetings amp Reports contains summaries of all meetings with the advisor customer and group It also contains our weekly reports e Planning contains a project plan in form of a Gantt chart e Reports from
29. his hers personal message through an application on the remote device 2 The message is received and possibly parsed by the door sign device s pri mary application 3 The message is displayed on the door sign 2a The message is never received due to packet drop parsing error the Internet con nection or something else technical 2al Return to 1 As an owner of the office I want to be able to upload a a short message remotely to the door sign with an Wi Fi Internet device Table 4 2 Update message 37 TED Visitor Use case name Actors related Trigger Objective Preconditions Post conditions Normal event flow Variations in the event flow Scenario User story UC3 Record message Visitor Primary amp Owner Secondary The Owner is not available to receive any conference call and the visitor leaves a recording instead To record a video audio message via the door sign as a voicemail to the owner The device of the owner for receiving confer ence calls is offline The visitor must be in teract with the door sign A specific amount of recording time is only available The recording must be stored on the door sign device ready to be uploaded to the Owner per request 1 The Visitor confirms he wants to leave a recording 2 The Visitor interacts with the door sign camera 3 The Visitor gets a confirmation that the recording has been restored 2a There door sign
30. meeting 29 Normally this new requirement would be implemented in the next sprint but we did not have any more sprints planned So we decided to add this new functionality to the sprint backlog and implement it during this sprint despite the possibility of not meeting our schedule During the sprint we encountered several issues regarding implementation The most problem atic requirement was recording of a video message JMF 20 which we had planned to use did not detect the Mimo monitor s web cam After a number of unsuccessful attempt to make it work we decided to use another library However using this new library we had to record video and audio separately and then merge them together afterwards Our implementation team also faced several conflicting project deadlines and other work which contributed to the delay Despite the fact that the sprint was not finished according to the plan and had to be prolonged we implemented all required functionality Sprint retrospective meeting revealed some troubles in communication within the implemen tation team mainly caused by not attending all meetings One of the problems was that not everyone had access to the Mimo monitor This meeting also showed that setting up more regular weekly meetings would be more effective than ad hoc meetings because team members would consider it as a permanent item in their timetables This problem would be completely solved if we were able to have daily SCRUM
31. meetings This would be hard to manage in practice however because of different timetables and interfering activities of team members 105 What went well e The sprint resulted in the fully working application with all requirements implemented e Positive customer feedback e Audio part of video conference and sending video message e Security requirement e Good communication with our customer e Mutual agreement on requirement change with our customer Problem encountered e Change of requirements e Problems with recording message requirement e A lot of interfering projects and other work e Communication within implementation team during last several days of the sprint Improvements suggested e Have the device available for everyone at the university e Set up regular meetings instead of ad hoc meetings 9 5 4 Burn down chart The burn down chart of sprint 2 can be seen in figure 9 6 The chart reflects our progress with the implementation work The two days delay was caused by the requirement change and by interfering activities of team members 9 5 5 Sprint conclusion During sprint 2 all requirements except the cancelled one were implemented from the sprint backlog despite several days delay Risk of delay during implementation work caused by interfering activities of team members was recognized during risk analysis As a measure project plan contained appropriate buffer and therefore this delay did not cause any proble
32. milestones what still needs to be done various problems or issues we might have encountered or are still working on and what our plans are for the next week 71 The template in Appendix B has been changed by the advisor and we no longer have to write who will attend the meetings If a team member is unable to attend the advisor meeting he or she has to send the advisor and the rest of the team an e mail stating the reason for their absence 6 3 Testing To make sure that our final product does what it is supposed to do we need to test it All the requirements that have been implemented need to be tested to confirm their functionality Non functional requirements or in other words quality requirements also need to be tested These tests need to have a uniform structure and strict guidelines as to how they are being executed to ensure a high level of quality Our test plan and details of each individual test can be found in chapter 7 and both sprint chapters where results of tests are stated The test results will show whether or not the product needs more improvement We have set limits for the test results and only the best performances will be approved If the results are under par we will have to make some adjustments and test again T2 Chapter 7 Testing To be able to properly test our product we must have a selection of tests we can perform In this chapter these tests will be presented and explained The actual testing
33. nobody answered the video call In other words this view will imitate a phone call where you try to reach the user perhaps with a ringing sound There are 3 possible outcomes of this function e The Owner does not answer the call e g he is busy or indisposed e The Owner rejects the call e The Owner answers the call In the first two points the visitor gets redirected to the RecordingInformation View If the owner of the office answers the call the visitor stays in the CallView until the call has ended RecordingInformationView This view will display a static message informing the visitor that the owner is currently un available but that the visitor can leave a recorded video message that the owner will receive once he is available RecordingView This view is intended to facilitate video message recording functionality that will be imple mented in Sprint 2 9 In this sprint buttons and actions were added to these views to 85 Calling Kai Torgeir Dragland Cancel call Figure 8 3 The calling view simulate e video message recording and sending to office owner e video message recording canceling When actions are cancelled in any of these two views the application goes back to Informa tionView 8 2 2 Database A database is used to keep various information used by the system An Entity Relationship diagram is shown in figure 8 4 title person id description D room nr skype login tel nr building s
34. our user interface is one of our architectural drivers separating the user interface from the rest of the application will help to localize changes To achieve this in practice the model view controller pattern will be used in this application This architectural pattern separates the model containing the information to be displayed from the controller which updates the model and the view the graphical user interface In general it works like this 1 Someone interacts with the GUI 49 The controller interprets the interaction in a way the model can understand The controller notifies the model of the interaction The model updates CU A Ww N The view listening to changes made to the model updates as soon as the model propa gates the changes Java has a good support for the model view controller pattern through the java beans library Therefore it should not be much of a challenge to implement 5 3 2 Event Driven Architecture With this pattern we can create one to many dependency between objects so that when one object updates this change will be propagated to all the ones that are listening This will be used in the MVC structure as well as for buttons on the screen or device Creating events and listeners in Java is well supported through the standard libraries There should be no problems in implementing this functionality 5 4 Design patterns 5 4 1 Singleton The singleton pattern is used to ensure that only o
35. owner of the office e Q2 You should be able to learn how to use the system by yourself in a short amount of time Use cases of these requirements with detailed descriptions can be found in section 4 1 3 Low Level Use Cases 8 2 Implementation During the first sprint our goal was to fulfill functional requirements that we marked with high priority We broke down these requirement to tasks e Display office owners information e Display rooms information e Create user friendly interface e Update office owners message using Skype application e Create database to store office owners and rooms information We started off by creating a package and class skelleton resembling our initial architecture and from there we added functionality that was required in this sprint 8 2 1 Usability and GUI Java Swing Swing is a Java GUI framework that provides a predefined set of GUI components for example buttons labels radio buttons panels and so on By using this framework we can easily convey a model view controller architecture by creating multiple views with Swing Each view represents a possible screen that the visitor must interact with in order to fulfill his her goal Figure 8 1 displays how each view is constructed with their core Swing components To represent the functionality we created a user friendly graphical user interface and all views were added to reflect the future functionality that will be implemented in the
36. project report She has a good overview of what is finished and what still needs to be done for the final report She also writes the summaries of the group meetings and advisor meetings and has to book the rooms for all meetings e Architecture manager Igor The architecture manager supervises the system designer s team He is also responsible for the architecture of the software He should make sure that the architecture respects the model view controller pattern e Test Manager Elise The test manager prepares the test plan what kind of tests should be done execute tests and monitors results e Quality assurance manager Andreas The quality assurance manager should check if the implementation team respects stan dards in programming files documentation for each method indentation etc and make sure that the quality of the product is high e Scrum master David The Scrum master guides the team in the Scrum process 2 2 2 Plan of meetings We agreed on regular weekly meetings which all the group members should attend They are held on Tuesdays from 9 15 to 12 00 Date Room Week September 06 R59 36 September 13 R59 37 September 20 R59 38 September 27 R59 39 October 04 R59 40 October 11 R59 41 October 18 K25 42 October 25 S21 43 November 01 S21 44 November 08 R59 45 November 15 R59 46 November 22 R59 47 Moreover we have other meetings in accordance with needs usually 2 3 times a week A
37. recent years examples of other groups final reports e Scrum materials informational material on Scrum 14 e Templates templates for the customer and group meetings and the weekly report Google Docs Everyone in the group worked on the final report so to make document sharing and editing in real time by more than one team member easy and accessible we chose to use Google Docs It also provided us with means to share spreadsheets for filling in our weekly hours report and a way to post ideas questions and suggestions to other group members Not all members of the group were familiar with LXTEX so for the friendlier user interface we used latexlab Communication within the group Our primary line of communication was e mail It is free everyone uses it and it guaranties that recipients get the information as it was sent The use of e mail also eliminates the need to inform everyone individually As for instant messaging two means were chosen e Skype popular and accessible to all instant messaging applications e IRC popular amongst IT people and mainly used by the implementation team Microsoft Project 2010 We used Microsoft Project 2010 for planning purposes We are in possession of a license for this software from the MSDN Academic Alliance program 16 This software helped us create the WBS structure and connections among tasks as well as define milestones and the length of particular tasks and sprints Th
38. reserved rooms This affected mainly our usage of the agile Scrum methodology especially daily Scrum meetings and led to an overload of cooperation activities The software planned for communication and cooperation worked fine during the project We were able to handle problems that occurred due to a lack of regular meetings One exception 135 was Internet Relay Chat IRC which was used rarely because its console GUI was not user friendly Skype and e mails were adequate replacements We usually used the reply to all function when we sent e mails about the project which made it easier for the whole team to stay updated but we could have done it more consistently One reason why it did not work 10096 of the time could have been because we failed to include it in our ground rules We also could have set a deadline so that no e mails would be sent after a certain time for example 6 PM eliminating uncertainty as to whether or not there was going to be a meeting the following day The way we did it we would sometimes get e mails only a few hours before meetings We would also have had more time to prepare to meetings if we had known about them earlier With today s experience we would have set up more regular meetings preferably four and reserved rooms for them in spite of the fact that they could only be attended by a small part of the team We would probably set up a ground rule obligating a team member to attend at least two or three of
39. the DoorSign s that it has been updated Table 10 14 Task 2 description Item Description Task ID 3 Name Answer a call Preconditions Person representing the visitor calls the owner of the office Execution steps Expected result 1 Click on Answer call Participant was able to answer the call as he would any other Skype call Table 10 15 Task 3 description Item Description Task ID 4 Name Receive a video message Preconditions Person representing the visitor left a video message Execution steps Expected result 1 Accept the video file Participant was able to receive the video message Table 10 16 Task 4 description Item Description Task ID 5 Name Remove door sign contact Preconditions None Execution steps Expected result 1 Open a conversation with the DoorSign s Skype account 2 Send tdt4290 DoorSign s Skype account password as an In stant Message Participant was able to remove the DoorSign Skype account from his contact Table 10 17 Task 5 description 122 10 6 3 Estimated time of the test Estimated time for a participant to complete a usability test is 8 minutes 10 6 4 Roles In this section we will list all the roles in our usability test plan An individual may play multiple roles and tests may not require all roles to be present The list of roles follows e Facilitator Conducts the test Provides guidance to the test subject and responds to the
40. the application As described in section 10 5 5 all answers to the first questions were discussed by the team to conclude whether or not the participant understood the purpose of the system The results for this question are presented in figure 10 2 Completely misunderstood 796 Partially understood Fully understood 36 57 Figure 10 2 End user s comprehension of the application s purpose Part 1 1 As we can see in figure 10 2 only 57 of the participants successfully recognized the purpose of the application This is less than expected in section 10 5 6 more than 80 For the second question figure 10 3 presents the results We can see how often each functionality was recognized correctly wrongly or was missing 126 100 80 60 Percentage 40 1 20 0 YE T T T T a office owner and status message call the owner record a video see owner s calendar contact information message Functionalities E Recognized Missing Wrong Figure 10 3 Identification of each functionality recognized by the participants Part 1 2 We can see from figure 10 3 that all the functionalities were recognized However the function ality office owner and contact information and status message were recognized only by 5796 of the participants Unlike the others functionalities they didn t have a specific button As for the two less recognized functionalities they are obvious when the application is lanch
41. the office owner and his contact information 115 e head the status message left by the office owner e Gain information about the office owner s time table from the calendar e Make a call to the office owner e Leave a video message The evaluation of the test subjects answers will be done within the whole team The entire team must unanimously agree on whether or not the participant correctly identified the individual functions of the application The metric expresses percentage of successfully recognized roles of the solution Users rating of particular tasks regarding difficulty of the operation Participants are given tasks to perform and they will assess the difficulty of the operation A five point rating scale with appropriate labels will be used see questionnaire in section 10 5 7 The metric expresses the difficulty of each task Tasks are evaluated independently SUS evaluation Participants are asked to answer ten question from System Usability Scale see section 10 5 7 SUS calculation procedure 6 1 Sum the score contributions from each item range from 0 to 4 e To For items 1 3 5 7 and 9 the score contribution is the scale position minus 1 e For items 2 4 6 8 and 10 the contribution is 5 minus the scale position 2 Multiply the sum of the scores by 2 5 to obtain the overall value 10 5 6 Success criteria Goals defining whether or not usability was achieved is evaluated based on the output from the usability s
42. the perspectives The first part focuses on visitors and the second one to the office owner 10 3 System Usability Scale SUS As a part of our usability study we used the System Usability Scale this provides a robust and reliable evaluation tool which is considered as an industry standard 24 System usability scale is a simple ten item scale giving a global assessment of the systems usability 6 The SUS is used after the test participant has had the opportunity to use the system but before any discussion took place The result of SUS usage is a score ranging from 0 to 100 Interpretation of this score can be seen in figure 10 1 NOT ACCEPTABLE MARGINAL ACCEPTABLE ESAME 0 0 0 0 0 cow Lain I SCALE ADJECTIVE WORST BEST RATINGS IMAGINABLE POOR OK GOOD EXCELLENT MAGINABLE 0 10 20 30 40 50 60 70 80 90 100 Figure 10 1 SUS score 3 109 10 4 List of terms This section describes terms used in the usability study e The DoorSign application the software application developed during this project e The device the Mimo monitor Mimo UM 740 e The product the Mimo monitor together with the DoorSign application e The DoorSign solution the Mimo monitor together with the DoorSign application e The office owner the occupant of an office associated with a device asd 10 5 Usability test plan designed for visitors This section describes a test plan scenario for conducting a usability study The basic outlin
43. things in an easier and more efficient way we need to follow certain standards to maintain consistency in our documentation and our process in general This allows us to create the best version possible of our product so that our customer is satisfied 68 6 1 Communication 6 1 1 External communication The customer An important thing to note is that all features and requirements presented at customer meetings must be implemented in order to give the impression of a completed product Promises we have made must be kept to preserve the credibility of our team A lack of communication with the customer could result in the team creating a partially working prototype that only meets a few of the customer s requirements This could give undesirable consequences such as losing the customer and thus losing money gaining a bad reputation and not getting future projects It is therefore vital to communicate with the customer to let them know early on if their requirements do not have a possibility of being correctly implemented or if their requests are unrealistic Only then will we have the chance to negotiate and come up with new ways and requirements that will satisfy our customer To make it easier for the customer to reach out to us and for us to keep a steady flow of communication with them without stepping on each other s toes we have appointed a customer contact The customer contact will maintain communication with the customer and pro
44. used in UML to describe the communication between components in the systems in form of message passing Entity relationship diagram A tools that is used to describe database modeles that in cludes the relationship between two or more entities For example one to many and many to many relationships Gantt chart A chart illustrating a project s schedule The left part of the chart shows project s WBS and in the right part are start and finish dates of the particular tasks Grey box testing Grey box testing is a method of testing software It is a combination of black box and white box testing The testers are not required to have a full access to the code but at least the internal structure Model View Controller MVC MVC is an architectural pattern used in software archi tecture This pattern separates the domain logic the business logic and the user interface permitting independent development testing and maintenance of each MySQL A popular relation database management system this is used to for example create update maintain delete and insert database entries tables and other structures Prototype This a test sample or a concept built into something tangible and testable 166 Sprint A term used in SCRUM an agile software development methodology A Sprint is equivalent to an iteration in terms of software development management vocabulary Subversion SVN Subversion is a software versioning and a revision control system
45. will be covered in the sprint chapters 8 9 and 9 4 This section explains the procedures for the testing 32 of the DoorSign The purpose of testing is to make sure that the product is working according to the expectations i e functional and non functional requirements We also used testing to find bug errors and fir them Thus our tests will be based around the functional requirements and the quality requirements 73 7 1 Overall test plan Each sprint will have a testing part The result of each test will be given in the chapter of each sprint During the tests the tester should follow the following points e Plan the test e Implement the test e Run the test e Evaluate and document the test result To document each test we prepared a template see table 7 2 Each test should have an identifier This identifier is structured as indicates in table 7 1 Type of test test identificator Unit test UNExxx Modul test MOD xxx System test SYS xxx Table 7 1 Test identificators 7 2 Test planning This section describes how we are going to organize the tests We will present the different methods and levels we are going to use and the template that each test should follows 7 2 1 Test methods There are three ways of testing black box white box and grey box which is a combination of the two preceding All testing in this project will be either black box and white box testing White box In white box testing
46. would like to use this system frequently Oo OF OF n d I found the system unnecessarily complex Oo OF OF Ed I thought the system was easy to use Oo OF 0 Y I think that I would need the support of a technical person to be able to 1 0O OF L1 O use this system I found the various functions in this system were well integrated Oo OF OF 0 Y I thought there was too much inconsistency in this system Oo OF 0 Y I would imagine that most people would learn to use this system very 1 OF OF L1 O quickly I found the system very cumbersome to use Oo OF OF Lu Y I felt very confident using the system Oo OF OF 0 Y I needed to learn a lot of things before I could get going with this system O OF OF L1 O Comments Table 10 19 SUS questionnaire visitor s perspective 10 7 Usability study results and evaluation 10 7 1 Visitor s perspective For our usability study 14 people were asked for the visitor s perspective As described in the test plan designed for visitors section 10 5 the questionnaire were divided in three parts In this section we will describe for each part the result of the test 125 Part 1 Purpose and functionalities To test if the end user understood the purpose of the application we asked two questions The first one required the participants to describe the purpose of the application after exploring it The second one required them to list the functionality of
47. you must choose different driver for XP Vista Mac and Windows 7 Follow the instructions on the webpage and installation files beginenumerate 2 Display driver http www mimomonitors com pages customer support 3 Touchscreen driver http www mimomonitors com pages customer support endenu merate 4 The newest Java JKD Java 7 Download link http www oracle com technetwork java javase downloads jdk 7u1 download 513651 html 5 Xuggler A third party library for Java you need to record and store video Follow the instructions on the webpage and installation files Download link http www xuggle com xuggler downloads A bit down on the page you will find xuggle xuggler setup exe it says it s for XP and Vista but it works with Windows 7 as well 6 Restart you computer this is necessary After the 4 steps above is completed you should be able to run the Java application Please proceed to following way 1 Plug in the Mimo mintor a Configure the display setup to your preference via the installed Mimo display driver 2 Open the folder USB or DVD given by Group 7 a Under Compiled_Code folder run the file run bat 148 b Follow the instructions given A 2 User guide There is two actors for the door sign We will provide a user guide for each actor The first actor is the Office owner He is the owner of the office where the door sign is located The second actor is a Visitor A Visitor is a person i
48. your Google calendar on the door sign by sharing your Google calendar with the Google account of the door sign A 2 2 Visitor The different functionalities for the visitor are the following 1 View the calendar 2 Place a call 3 Record a video message A description for each functionality is given below View the calendar To view the calendar press the button Calendar on the main screen This will show a calendar of today s events from the owner of the office Google calendar Press Cancel to return to the main screen The door sign will automatically go back to the main screen after 1 minute Place a call To call the owner of the office press the button Call You can cancel the call and return to the main screen by pressing the button Cancel If the owner does not answer or if he rejects your call a message indicating that the owner is not available will be displayed From this new screen you can return to the main screen by pressing the button Cancel or record a video message by pressing the button Record a video message 150 Record a video message Press Record a video message Press Start recording Now you have one minute to record your message Ee WO b HL When you are done press Send to send your recording to the office of the owner and return to the main screen At any time you can cancel the record and return to the main screen by pressing Cancel the recording if started will not be sent to the
49. 1 VideoAndAudioMerger merge MP3 and MP4 1 Redirect user to Information View VideoAndAudioSender Redirect user to delete MP3 and MP4 1 InformationView VideoAndAudioSender send file via Skype End of Thread 1 Figure 9 1 The work flow of the recording and merging The execution and merging We were able to concurrently record audio and video through JMF CIVIL and Xuggler and then store these two files one MP3 file and one MP4 file locally on the computer Then the two files were merged together to create a single file before we could send the recording over Skype Xuggler was used for the merging by braking down the audio and video file to two streams and then creating a new MPA file with two channels one for audio and one for video The merging was successful As a result of using this method the new MP4 file was able to produce both audio and video but with major synchronization issues There are also limitations to the size of two files that needs be merged if they are too large there is a chance of running out of memory 33 9 3 Software security To analize how secure our application is we will be using Microsoft Threat Modeling Process 21 This is a well documented and popular approach for security analysis and evaluation 95 9 3 1 Threat Modeling Microsoft Threat Modeling Process was chosen to perform threat risk modeling This is a five step process 1 Identify Security Objectives 2 Applicati
50. 4 1 The Android tablet The WonderMedia WM8650 is a cheap Chinese made tablet running Android 2 2 It does not support all the functions that one might expect from such a device For instance it does not support the normal Android Market but has a Chinese rip off instead Another concern with the device is that it does not seem to have a Windows driver so connecting to your Windows 18 computer seems impossible The touch screen on the device is also of poor quality You have to press hard for it to register changes Multi touch is not supported Figure 3 1 WonderMedia WM8650 Specification and details There are no official specifications for the device We sent an e mail see appendix D 2 to the company making the WM8650 but we never got a reply The specifications below are the ones given by the seller of one of these tablets and are not the official specifications e Name WonderMedia WM8650 e CPU VIA 8650 800Mz e RAM Installed Size DDR2 256MB e Storage 2GB Nand Flash e Screen 7 touch panel 800x480 e Audio Built in 0 5W speaker e Microphone Integrated e Wi Fi Built in 802 11B G wireless card Android and Android 2 2 Android is an operating system owned by Google developed for use mainly on tablets and mo bile phones Some of the largest mobile phone brands like Samsung Sony Ericsson Motorola LG HTC use Android OS for their smart phones Applications such as the one we are developing run compile
51. CS do edm a db bedeutete ute to ib ena 123 10605 a b s eat cta cedido O as 123 10 6 7 Questionnaite lea de uta etie BA Er tene getestet 124 10 7 Usability study results and evaluation ee teo Ro toe RR RES Rs 125 10 7 1 Visitors perspective la see ar ade a deb oer p dia 125 10 7 2 Owner s perspective eus A audeat el gr E RA Sene S uis 129 11 Evaluation and discussion 131 BM MET NM NN 132 TRAD RIANNINE 6 vin ac tbe e 1s nune a Feat nta dei de o e ade 132 11 1 2 Scrum methodology nu scd ee a Oe e DOS Res 132 TID v Quality assura hce 2s are vetas qe ui Seed QUA Mab CA SU SEI ms dfi qe und 133 11 1 4 Group dynamics 11 1 5 Risk management 11 2 The result 223 12 4037 ee eS 11 2 1 Requirements fulfillment 11 2 2 Architecture 11 2 3 Usability study 11 2 4 Planned effort 12 Conclusion 12 1 Requirements and expectations of the customer 0 12 2 Goals and expectations of our team 22e 12 3 Limitations of the product 12 4 Future work supiese 4 Bibliography Appendix A User and installation guide A 1 Installation guide A 2 User guide A 2 1 Office owner A 2 2 Visitor A orte Appendix B Templates B 1 Group meeting B 2 Customer meeting B 3 Weekly report Appendix C Gantt chart Appendix D E mail conversation D 1 Skype A exei D 2 WonderMedia D 3 Mimo customer support Appe
52. Cn CM A D Carls 2 Sila aaa el etch kt natn Tar ad a 34 4 1 1 Use case diagrams and actors 2922 193212 339 34 4 1 2 High level use case diagrams ine ay e RE e e a deRORIR e 34 4 1 3 Low level use cases a die I a a oe doe A AA 34 4 2 Red irements ee gri und vd eo e DOT IECUR 44 4 2 1 Functional requirements e 2 sese aree qe ort Bak ls dee 44 212 2 Non t nctional requirements voa ee reu HEURE E UE a RS 44 Lg Prod ct backlogs 8 puros deas adu ie des le dee e ese rub de Pre D d de 45 Software architecture 47 5al Architect ral drivers La SS SAA A Ee A ele S38 48 od P Requirement Pte oo ache y en Grn EE Ee iE 48 9 1 2 Requirement PO x ea ore un m Au ata x OE te x E db Rt os 48 513 Requirements dad pl EA depu ES 48 ALA Requirement du us lech ks A ADA AAA t a 48 5 2 Architectural tactics A eundo Eee ee ed Eh eB de Ewa wes 49 A e ret dete A n n RR n nodu e all de Ga 49 DOE Performante Es psu doe peli Di oe hoe Capo s ce diuisa Ga edo 49 5 9 Architectural patterns id e oec Y Se 49 5 3 1 Model View Controller z 1222 54 a wwe Se Ga Women 49 5 93 Event Driven Architecture ues inv af eke ak NEUE ROR UE RC I Ros 50 54e o o e a sadades ae dede nass ida let c us hence p rb Ael a o eb bid IVO CEA E 50 UL Sineleton 22 Leg ede Ha acm uv ad Mea EA POE Be SS 50 5 5 Architectural 7S de fee fo ante Qe er nt woe esp dU Ned 1G Er dh eer ned 50 Es 2o D E ace etta feet a Bote bns 51 5 5 2 Development view cie puta oie edi eR
53. Customer contact Negative approach of one or more team members Risk number 6 Activity All Probability Low Consequences Conflicts inside the team lack of motivation quality issues Contingency Motivate team members to do their work better com plan munication reassign responsibilities Responsible Project manager Problems with the implementation Risk number 7 Activity Implementation Probability Medium Consequences Delay unable to finish prototype Contingency Obtain as much information as possible about the solu plan tion during preliminary studies and focus on the archi tecture buffers in plan Responsible Implementation manager Problems with hardware Risk number 8 Activity Preliminary studies and implementation Probability High Consequences Delay unable to finish prototype Contingency Focus on preliminary studies buffers in plan plan Responsible Implementation manager 11 Failure of file storage Google Documents Risk number Activity Probability Consequences Contingency plan Responsible Reservation issues 9 All Low Unable to deliver a working prototype and or report delay stress Regular backups Project manager e g printer Risk number Activity Probability Consequences Contingency plan Responsible Illness 10 Conclusion Low Unable to deliver the final report delay Include the reservation of important technical equip
54. H DatabaseConnector E AbstractModel Attributes Attributes protected PropertyChangeSupport propertyChangeSupport Operations H SkypeConnector Attributes Y Operations H Model Unnamed Attributes private String name Steel private String title Dr private String message Hello world controller private String pictureLocation picture jpg private String tlfNr 81549300 private String eMail dr steel gmail com HButtonListener Attributes Operations view E AbstractView Attributes Operations H Main E Attributes i TVA Operations E CallView EjRecordingview public void main String args 0 z Attributes H InformationView Attributes Operations Attributes Operations Operations Figure 5 1 Class diagram Class diagram description Figure 5 1 is a a picture of our class diagram Here is a short description of the classes of each package e root folder The Main class contains the main method that is called when the program is started e model Contains two classes an AbstractModel and a Model class The Model class will extend AbstractModel and contain all the information to be displayed on the different views AbstractModel uses java beans Property ChangeS
55. It would be easier and more efficient to develop a system which seamlessly integrated Skype s video and audio features than to create the same features from scratch Since the full project would have to be finished in 13 weeks creating the whole system from scratch would therefore not be an option When we determined that Skype was not a possibility and we had to cut down on some of our requirements it led to the introduction of a new device the Mimo monitor see Section 3 6 1 Mimo monitor With this we could make a Windows based system that supported Skype and in dialogue with the customer we ultimately agreed to use SkypeKit see Section 3 6 1 Skype and SkypeKit to create our prototype This solution fulfills every point we have in our evaluation criteria We have our customer s approval especially due to the fact that this is the solution they would prefer to use in the first place and the entire team has agreed to go with SkypeKit With our team s combined Java skills this will give us enough time to finish our prototype which will include our most important requirements Our chosen solution also adds the possibility for further development in the future 3 8 Software process model 3 8 1 Scrum Scrum is an agile project management framework often used in software development There are several agile software methodologies and they all share common characteristics which surrounds an iterative and incremental development method The a
56. MPP is an open standard communications protocol To incorporate it with Google Talk a library has been developed libjingle BSD license Issues and evaluation Google Talk support is integrated in Android devices but voice and video calls work only on Android 2 3 4 As our device can only run Android 2 2 see Section 3 4 1 Android and Android 2 2 this is not a suitable solution for us Google Talk with video and voice chat will gradually roll out to Nexus S devices in the next few weeks as part of the Android 2 3 4 over the air update and will launch on other Android 2 3 devices in the future 8 Adobe LiveCycle Collaboration Service 1 Introduction Adobe LiveCycle Collaboration Service formerly Adobe Flash Collaboration Service is a hosted service that enables organizations to incorporate real time multi user collaboration into rich Internet applications RIAs that drive revenue and improve customer acquisition and retention It provides a ready made solution with a comfortable SDK Adobe provides communication using its new and improved RTMFP Real Time Message Flow Protocol RTMFP is a UDP based protocol that enables peer to peer communication between Flash Player or AIR clients The most important features of RTMFP include low latency end to end peering capability security and scalability Services provided e VoIP Improve productivity by enabling multiple users in dispersed teams to speak to one an other through a b
57. N TNU Trondheim Norwegian University of Science and Technology Customer Driven Project Interactive Door Sign Fall 2011 Group 7 Advisor Elise Boinnot Muhammad Asif David Andr ssy Eilertsen Michal Krajicek Knut Esten Melandso Neks Andreas Nordahl Sibel Ayper Tasdemir Igoris Tirmailovas Preface TDT4290 Customer Driven Project is claimed to be one of the most useful courses at NTNU As students we get a unique opportunity to get to work on real world projects with real world customers and because we have to work together as a team to succeed this gives us even more experience and hopefully an edge when applying for jobs in the future The process of software system development is imperative in our project and towards the end of it we will hopefully have accumulated much needed knowledge in the field that we can use in the working world Working on the documentation has taught us a great deal about how to structure write and edit the full report of a project This is knowledge we will definitely be able to use in future projects We wanted this experience to be as realistic as possible Therefore our documentation was written without any obvious connections to the course to keep the authenticity of the project We would like to express our acknowledgement to our customer for his responsive approach to the changes in the project and his willingness to make compromises as well as his feedback that helped make our syste
58. OEE OR He SRG o4 s 61 The view package 2k Rem ee Rem ee Se ee eee ee Oe ee 62 The connector package ea a grade ea ed ho ee ha Ro ewe eae 63 Audio call communication diagram oce 4444 RO XD a 64 Message update communication diagram 64 Calendar communication diagram 2 44 26 dee av ee ee a RC d 65 Record video message communication diagram 66 Startup communication diagram usus dox odd ae Bek de we 67 GUL Swing build s sse catius ag ad Tautai E aua i ae m 84 Theinformation VIEW e cc e ss aopa a x RS Y EU once Eee E o PES 85 The calling view ea RUE UR wx oe UR a RO CORREO COR ORDER UR EU RE de UR 86 Entity Relationship diagram lee 86 Burn down chart for sprint l 2 2022 2 look errar ORO 91 The work flow of the recording and merging 0 95 Threat Model Flow e e e s ro be ae ok Np eec ee eee Eo ee 96 Data Flows sos sote cona sg pioa eS POE oak Ee Oe Oe RS he ee ee 97 Attack on the application e xw he dose dede do Rex e xod d ee xe 98 Attack on Skype ce son Roe e eai ORR eRe RC ende AA 98 Burn down chart for sprint 42 4529 Roe y EO A BIRD XX lA 107 10 1 10 2 10 3 10 4 10 5 10 6 10 7 12 1 C 1 G2 SUS sc r 3 uox ewe ob m RARO as BESS 109 End user s comprehension of the application s purpose Part 1 1 126 Identification of each functionality recognized by the participants Part 1 2 127 Percentage of the overall functio
59. OOT Y TUTTEZ PIM TI 80 enr s p T9 uoneyuaunooq or TT TT EZ PIM TT 8 0 enr sAp T9 Apnjs j as pue seJn3281 96001 c TUTE yz NUL TTS 0 eni S P 88 z9 peafoig UIQ 4aWO sND oor T TT AON TZ TT PO TE TT PO OT TT das 61 TT 3NV ec a1ajduwo SJ0sso2opoeJd Usiut4 yes uoljeing 9UJEN SE 1 al Gantt chart 1 2 Figure C 1 157 Irvc tS IUIDvZnul TTT NUL s po paysiuy p fosd oor ES IS ILTITvZnul LETT pz NUL APT uorejuaseud yalorg oor CS OS TUTTEZPIM TITT9TPIM s p 9 uoisnjuoo 3 uonenjeae pafod o00T TS 6v TUTESTANL ILIT YI UON Shp Z uoneaJ uonejuasaJd oor OS IT II Lv 8y TUTTE ud TUTUTI US skp 0 paysiuy uoneyuaum2oq oot 6v 9v TUTTII HI TT TT L UON SAP S uonejuaunoop eur 3u1ea19 oo 8Y Sy TUTTZP M ITIUZP9M 1yT uoneAJasaJ Ja uld oo V sv TUTTY M4 TTOTTE UON skp S Apnis Aupiqesm oo 9v or v CvTV Op 6 TT OT 8Z ud TT OT 87 Uy s p 0 pajajduioo uonejuauis duu oo SY 8 TT OT 8Z H4 TT OT 8T oni SAP 6 quinoas TO oo tV 8 TT OT8Z UJ TT OT 81 anL skp 6 aouewoysad eo oo EV 8 TT OT 8Z H4 TT 0T 8T NL s p 6 seSesseui Suipeojuwop Z4 oor CV 8 TT OT 8Z HJ TT OT 8T ant SAP 6 82ua18juoo oap S4 oo TV 8 TT OT 8Z uj TT OT 8T on skp 6 oapia 8uuo15 4 oot OV 8 TT OT 8Z UJ TT OT 8T anL spe oapra 3uip10221 4 oor 6 9 ITLOLZIUON TT OT ZT UON Apt Suruuejd uds oor 8 ILOUS
60. ZU4 ITOLZI UON SAP OT zi uuds oot LE TT AON IC TT PO TE TT PO OT TT das 6T TT 8nv ec a a duwo SJ0SS3I3P9Jd ysiul4 neis uoneang owen sel al Gantt chart 2 2 Figure C 2 158 Appendix D E mail conversation D 1 Skype From Skype Developer Access Support e mail address retracted Hi SkypeKit can be used to develop applications on android devices TV s and set top boxes etc however there is a restriction on developing for mobile phones and tablets There is no waiting list you just need to visit http developer skype com signup and then pay the 10 membership fee Thanks name retracted Skype Developer Support D 2 WonderMedia To WonderMedia e mail address retracted Subject Specifications for the WonderMedia WM8650 Dear Sir or Madam I have bought a WonderMedia WM8650 running Android OS 2 2 However I have not been able to locate the exact specifications for this device if you could send them to me it would be much appreciated Model number WonderMedia WM8650 Build number generic eng 2 2 Froyo v1 2 3 20110409 211203 Sincerely name retracted 159 D 3 Mimo customer support Hello name retracted Although the Mimo UM 740 has been discontinued for a couple years now it uses the same drivers as our current models and so you can download any drivers you need from our support page of our website Note that the webcam does not require come with any special webcam driver
61. ae dna ee it A AS Sa Poe Ld Arm 86 Ss ESO de e e ra o pr a BS 88 POLL Testexecuted A A A densa SY ooa See decani e a 88 3 3 2 Test reslis 2 4 422 4 ate oh A e A a Ale Ed Ad 88 8 3 3 Evaluation of tests sind ete ae amp ee ee BS ed elu oe ee ex 89 8 4 Sprint evaluation esc eir ei m bo es an oe ee ee ER PERI EORR all a oe 89 8 4 1 Customer feedback 43e ep Dista oe d ey e su ees 89 8 4 2 Sprint retrospective o 6i oec a EO A el 89 8 43 Burn down chart 90 84 4 pri conclusion Las iaa ieee eck he E a se Ow RO 91 Sprint 2 92 OS SPISSIBERE sonum uuu Wr NA 93 91 ADIOS 93 LD Resources uos mud VS Pa a eo etd XR RU E RATS 93 91 3 soph SOs IE 93 OA Sprint backlogs p fk td obtestor a 93 92 implementation dt a e A hg aber et y eto A oto Et ng 94 9 2 1 Recording and storing video message 94 9 3 Software security ou a eode do de Pd a a A AAA 95 Orgel Threat Modeling a ec A ADA AAA Bk aad 96 9 3 2 Risk evaluation ou ut aa eS A Se XGA 99 9 3 3 Factors estimating impact ox cce A A S 100 9 3 4 Identify and threat vulnerabilities llle 103 9 3 9 a Se cB te Se is mast e Ud mune o cM ris c a iori Du ee ett A UA 103 OE UIGSUNO e uA vA ak Bee og ahs E erae s eke dud qu Gade euer ux m ee oo 103 DUET Testexecuted s aa to uper dr hp et A AE EM ete ee ee DEURI Pj 103 DE il II A gt eet sh engin oh Si den oe ad 103 0473 cEeyaluabiom Of teste hal ww servus RA ee HOG Gat ks 104 9 5 Sprint eyal a
62. all Visitor Figure 4 1 High level use case diagram 35 Visitor Use case name Actors related Trigger Objective Pre conditions Post conditions Normal event flow Variations in the event flow Scenario User story UC1 View information Visitor A person is visiting an office with an interac tive door sign To get information about the owner of the office and see if he she is available The visitor must physically view the door sign Information about the owner of the office 1 The visitor reads the static information owner s name title room number and similar 2 The visitor read the personal message 2a There is no personal message for the vis itor to read As a visitor I want to have an overview of person working in the office also I want to be able to read his personal message able 4 1 View information 36 Update message Owner Use case name Actors related Trigger Objective Post conditions Normal event flow Variations in the event flow Scenario User story UC2 Update message Owner The owner updates it s personal message through a remote device To display and update a personal and cus tomizable message on the door sign Pre conditions The owner s deceive must be con nected to the Internet An application able to upload the message to the door sign The personal message on the door sign is up dated 1 The owner types in
63. and so if Windows is not recognizing it possibly it is no longer functioning name retracted Mimo Monitors Suite 15 743 Alexander Road Princeton NJ 08540 www mimomonitors com On 9 26 11 7 45 AM name retracted e mail address retracted wrote Hi I ve lost my driver CD so I used the drivers listed at the homepage Display and touchscreen drivers and it seems I cannot get the webcamera working Windows does not recognize it and there is no recording device mic either Can you steer my in the right direction The device is Mimo UM 740 thanks V MV NNNM OM OM Cheers 160 Appendix E Ground rules 1 You should be on time for meetings If you know you re going to be late let people know If you don t have a valid excuse for being late for each started 10 minute session from the start of the meeting you need to bring a bottle of beer 2 Unless you re taking notes it s not allowed to use computers during discussions in group meetings 3 People should be able to speak freely without being interrupted If you feel that what you have to say is important and someone else is talking write it down and we ll come back to it later 4 Finish your work before the deadlines If you can t finish your responsibilities on time and you don t have a valid excuse you need to buy a beer 5 The group s official language is English When talking to team members about the project please speak English 161 Appendix
64. ar 1 vulnerability is hidden 4 vulnerability is obvious 7 vulnerability is pub licly known 10 9 3 3 Factors estimating impact To estimate the impact the attacks may have we can break down the impact into two cate gories Technical impact and business impact Even though Business impact ultimately is more important this project is none profit and it is impossible to evaluate the financial part Technical Impact factors To calculate the impact we need to define impact factors and assign a value from 1 10 to them The goal is to estimate how much impact the exploited vulnerability will have on the system e Loss of confidential information How much data can be discovered and how sensitive is it Some none sensitive data 1 a lot of sensitive data 5 all the data 10 e Loss of integrity How much data can be corrupted and level of corruption Some data to minimal extend 1 a lot of sensitive data to medium extend 5 all the data totally corrupted 10 e Loss of availability How much service would be lost and how dependent on these services in the application Some services are unavailable for short time that don t disrupt overall application perfor mance 1 most services are disrupted but the application still runs 5 total disruption of the services application cannot run without 10 100 Determining the severity of the risk All estimations made have to consider the worst case scenario Keeping this in mind it is
65. ase test case Item Description ID UNI 003 Name Display message Date During sprint 1 Responsible Elise Boinnot Requirements F1 Precondition None Execution steps Expected result 1 Launch the application The last message update is displayed At the first launch of the application a default message is displayed Table 7 5 Display message test case 76 Item Description ID UNI 004 Name Update message remotely Date During sprint 1 Responsible Elise Boinnot Requirements F2 Precondition The application is launched Execution steps Expected result Sprint 2 1 Launch Skype Application 2 Send a contact request to the Skype account of the device with the password of that account as the request message 3 Send an instant message The device displays the new message within one minute after it has been sent Table 7 6 Update message remotely test case TT Item Description ID MOD 001 Name Record video and stored it Date During sprint 2 Responsible Elise Boinnot Requirements F3 and F4 Precondition The application is launched Execution steps Re 1 Press the button Record a video message 2 Press the button Start recording 3 Talk 4 Stop the recording by pressing the button Stop 5 Send the recording by pressing the button Send B 1 Press the button Record a video message 2 Press the button Start recording 3 Stop the recording by pressing the button Stop 4 Cancel the recording
66. ation and desired goals set by the implementation team together with the customer This will make the design implementation and testing phases much easier since we have clearly stated what needs to be done This reduces amy potential ambiguity of the project The scope of this chapter and its contents is to sufficiently satisfy our customer s needs and to deliver a software product that meets our goals We have not added any functionality that was not requested by the customer as one of our top goals is to create a product that is based on their needs and not on ours This also gives us extra time and enables us to maintain our focus on the tasks with the highest priority in order to make the software product a success 33 4 1 Use cases A use case can consist of several parts for example textual descriptions and diagrams Its main purpose is to describe a series of actions that need to be done in order to fulfill a requirement stated in the requirement documentation or to display a desired behavior in a system 4 1 1 Use case diagrams and actors A use case diagram is a type of behavioral diagram that works as a visual representation of the functionality of the system in the context of an actor An actor is a user interacting with the system in whatever way that may be There can be many different actors in a system some examples being End user Owner and Student These actors each have certain constraints and responsibilities in the syste
67. cally It should be possible to have a video confer ence with the owner The system should have a database with the information of the people who will be using it When the receiving device to the owner of the office has established a connection to the Internet it should receive all messages sent to him her during the offline period with ad ditional information e g timestamp A visitor should be able to view a calendar regarding the office owner s workday and in dicate via a coloring schema his hers avail ability in equally divided timeslots Table 4 9 Functional requirements Description 2 20 40 20 Complexity points H Priority Ql Q2 Q3 You should not be able to exit the DoorSign application and access other parts of the de vice You should be able to learn how to use the system by yourself in a short time You should be able to have a normal conver sation through the video conference 20 13 N A Table 4 10 Non functional requirements M H M H 4 3 Product backlog As described in section 3 8 1 the product backlog is a part of the Scrum methodology which is a complied list describing all potential implementation features of the system derived from for example from the requirements as in this case 45 Feature No Taks Priority 1 Displaying Information H 2 Update message remotely H 3 Database H 4 Security Q1 Application restriction M H 5
68. ce with this evaluation method by members of the implementation team To evaluate the risks we need to look at threat agent factors and vulnerability factors Threat Agent Factors The goal of this evaluation is to find out how likely the threat agent is to succeed with the attack e Skill Level The technical skill level of the attacker or attackers Minimal technical skills 1 some technical skills 4 advanced technical skills 7 profes sional 10 e Motive Level of motivation based on the reward Small or no reward 1 possible reward 5 high reward 10 e Opportunity What resources are required to exploit this vulnerability of the system Full access to the system or expensive resources are required 1 special access or some resources are required 5 just by interacting with the system 10 99 Vulnerability Factors These are the factors connected to the specific vulnerability The goal of these estimations is to find out how likely it is for the vulnerability to be found and exploited by the threat agents e Ease of discovery How easy is it to discover this vulnerability for the selected threat agents impossible 1 difficult 4 easy 7 the vulnerability is obvious 10 e Ease of exploit How easy is it to exploit this vulnerability for the selected threat agents impossible 1 difficult 4 easy 7 the vulnerability exploit is obvious 10 e Awareness How familiar are the threat agents with the vulnerability unfamili
69. cel button Participant was able to start recording a video message for the office owner and canceled the recording after two seconds Table 10 8 Task 6 description Item Description Task ID 7 Name Find out whether the office owner has had a free time slot at 1 pm today Preconditions none Execution steps Expected result 1 Press the button Calendar 2 Observe the today s timetable for the office owner 3 Press the Back button Participant was able to see if the office owner has had a free time slot at 1 PM today Table 10 9 Task 7 description 10 5 3 Estimated time of the test Estimated time for a participant to complete a usability test is 8 minutes 114 10 5 4 Roles An individual may play multiple roles and tests may not require all roles to be present The list of roles follows e Facilitator Conducts the test and provides guidance to the test subject and responds to the test subjects questions or requests e Data logger Records the test subject s actions and comments and takes notes e Office owner representative Answers a test subject s calls updates messages e Observers Assist the data logger in taking notes They are not allowed to speak during testing e Test subjects Carry out a set of required actions to test the usability of the product 10 5 5 Usability Metrics Usability metrics allows us to measure user performance against specific performance goals i e t
70. charter must be approved by the representatives from the implementation team and by the customer 164 Michal Kraj ek Torstein Hjelle Muhammad Asif Project manager Customer Advisor 165 Glossary BibTgX A tool typically used together with the IX enabling to cite sources in a consistent manner by separating bibliographic information from the presentation part ETFX Macro package based on TEX a low level markup language with high quality typeset ting allowing users to focus on content instead of visual part Its purpose is to simplify TeX typesetting Activity diagram An UML notation that describes to workflow of a procedure through a set of activities or actions These are represented graphically Black box testing Black box testing is a method of testing software that tests the function alities of an application The testers does not need to know or even understand the code They only need to know the possible inputs and the expected outputs associated The inputs and outputs are based around the requirements Burn down chart This is an artifact in SCRUM showing the remaining work in the sprint backlog i e how much we have done how much if left and our original assumptions Class diagram An UML notation that describes the structure of the system by representing it with it s class their attributes most important methods and their relationship to other classes and artifacts in the system Communication diagram A notation
71. cution steps Expected result 1 Press Call button 2 Wait for the office owner to pick up Participant made a successful call for the office owner Table 10 5 Task 3 description Item Description Task ID 4 Name Make a call to the office owner and cancel the call after two seconds of dialog Preconditions Person representing the office owner is ready to answer the call Execution steps Expected result 1 Press Call button 2 Wait for the office owner to hang up 3 Wait for 2 seconds 4 Press Cancel button Participant started dialoging with the person representing the office owner and canceled the call after 2 seconds Table 10 6 Task 4 description 113 Item Description Task ID 5 Name Leave a video message to the office owner Preconditions none Execution steps Expected result 1 Press the button Record a video message 2 Press the button Start recording 3 Speak loudly while looking into the camera and wait for the recording to stop Participant was able to leave a video message to the office owner Table 10 7 Task 5 description Item Description Task ID 6 Name Start recording a video message for the office owner and cancel the recording after two seconds Preconditions none Execution steps Expected result 1 Press the button Record a video message 2 Press the button Start recording 3 Speak loudly while looking into the camera for 2 seconds 4 Press the Can
72. d Java code on a virtual machine This means that we mostly will be using Java code in our implementation of this application 19 More specifically we will be using a customized version of Java This customized version of Java is very well supported by the IDE Eclipse 11 which will make our lives as developers a lot simpler There is also a lot of sample code and tutorials published by Google so getting familiar with general Android coding should not be a problem even though most of our group does not have any experience with Android Android in general should not be much of a problem for us However what version of Android our tablet is able to run is of more concern As of today it is running an old version and there is no official update for it The problem with this is that much of the functionality we need to complete the implementation of our requirements was first added in later versions of Android than the one our tablet is running The version our tablet is running is Android 2 2 at least before the update made by Hardcore Hacker 14 Android 2 2 does not have the SIP VoIP library as this was added in Android 2 3 1 Google talk and other possible solutions for the requirement concerning video conference will not be supported in this version of Android either Because developing software for sending live video and audio over an Internet connection is out of the question all requirements con cerning video conference concerning b
73. d customer meetings We have one full group meeting every Tuesday which is documented in each summary but we can also have extra group meetings or group meetings with only a few team members on other days of the week If we plan to have such meetings we have to write the time and place for them using the text Next group meeting followed by the time and place for the full group meeting using the text Next full group meeting so that there will be no confusion 6 2 2 Customer meetings The customer meetings are not set on a certain day of the week like the group and advisor meetings so there is no line stating when the next meeting is When a new meeting is scheduled the customer contact e mails the rest of the team informing them about the time and place for the meeting 6 2 3 Weekly report The advisor meetings have their own summaries the template for this is similar to the template for group and customer meetings but a weekly report is also required This report will be presented at the advisor meeting and things we discuss will be part of the new advisor meeting summary The weekly report needs to include an agenda for the meeting meaning what to discuss and the summaries of the week s meetings which include group and customer meetings as well as last week s advisor meeting The team s workload needs to be included including a description of what each individual has worked on Other topics include what we have accomplished so far
74. d workload of one programmer to 4 hours per day The duration of the implementation work was 9 days 5 4 9 180 8 1 3 Sprint goal The goal of the sprint 1 was to fulfill all requirements with high priority This included the database for storing data about office owners displaying information on the screen and remote message updating Quality requirement Q2 was also part of sprint 1 Q2 can be considered as a testing of GUI Moreover sprint 1 built the foundation for the next sprint This means establishing communication with Skype API and preparing the database As this is our first sprint one of our goals is to apply theoretical knowledge about SCRUM methodology in practice and learn how to work as a SCRUM team 8 1 4 Sprint backlog The sprint 1 backlog can be seen in table 8 1 together with priorities and estimations of workload Feature numbers refer to the product backlog in section 4 3 Feature No Description Priority Est hours 1 Displaying Information H 25 2 Update message remotely H 70 3 Database H 35 5 Usability H 50 Table 8 1 Sprint 1 backlog 82 The sprint backlog covers following requirements e F1 The device should be able to display a picture the first and last names of the owner the owner s title and a short message on its screen e F2 It should be possible to update the short messages remotely e F6 The system should have a database with the information about the
75. de viewing another day s schedule or requesting an appointment The application could do with better exception handling At this point most of the errors caused by external factors e g Skype Google Calendar MySQL will cause the application to crash During the usability study we received a lot of useful feedback from potential users of the device We got suggestions from the test subjects and our advisor regarding additional features When or if these have been implemented a new usability study can be conducted The new usability could then be greater in scale as the one we conducted was limited due to our project s scale 144 Bibliography 6 7 8 10 11 12 13 Adobe Adobe livecycle collaboration service http www adobe com products livecycle collaborationservice 2011 Visited 19 09 2011 Angrybirds com Angry Birds online http www angrybirds com 2011 Visited 12 09 2011 Aaron Bangor Philip Kortum and James A Miller Determining What Individual SUS Scores Mean Adding an Adjective Rating Scale http www usabilityprofessionals org upa_publications jus 2009may JUS_Bangor_May2009 pdf May 2009 Visited 04 11 2011 Len Bass Paul Clements and Rick Kazman Software Architecture in Practice Addison Wesley second edition edition 2003 Mike Beedle Arie van Bennekum Ward Cunningham Martin Fowler Jim Highsmith Andrew Hunt Ron Jeffries Jon Kern Brian Marick Robert C Ma
76. ded Disabling buttons may prove difficult without rooting it first and rooting the device is not necessarily an easy task It seems the device does not have the proper drivers for us to connect it to a computer This will prohibit effective debugging and testing of or program on the device in the implementation phase as we may have to upload the apk file to a web server and then download it on the device to install the program Another possible solution is to use an SD card to transfer the file Rooting or installing a ROM might at least partially solve this problem however 3 5 Components and technical constraints This section will elaborate what components we are using to solve our requirements These components will themselves limit the solution space and contain specific technical constraints we must solve or bypass which will be described in this section 3 5 1 The Mimo monitor On Monday 26 09 2011 the customer presented us with a new device a monitor This would greatly simplify and bypass the technical constraints of the Android device The customer yet again emphasized his desire for Skype to be integrated with the application Introduction Mimo UM 740 is a small LCD monitor with some additional features it has a touch screen a microphone and a web camera It can connected to a Windows computer through a 2 0 USB cable and be used as an external screen This will allow us to use any available third party software applicati
77. device cannot store more video audio 2al Remove oldest video entry or more if is not enough 2a2 Return to 3 As a visitor I want to be able to record a video message to the owner of the office via the door sign camera and I want to be able to end the message at my preference As an owner of the office I want the recording of a video message to end after a certain amount time so I does not take too much space and time to upload Table 4 3 Record message 38 Initiate conference call Visitor Use case name Actors related Trigger Objective Preconditions Post conditions Normal event flow Variations in the event flow Scenario User story UCA Initiate conference call Visitor The Visitor wishes to contact the owner To have a video conference with the Owner of the office via the door sign The Owner of the office s receiving device must be connected to the Internet The Vis itor must interact with the door sign The owner answers the call or doesn t an swer 1 The Visitor initiates the conference call by pressing a Call Contact button on the Door Sign 2 The Visitor wait for an answer from the Owner 2a The Owner rejects the call 2al Return to 1 As a visitor I want to be able to initiate a video conference with the owner of the office via the door sign Table 4 4 Initiate conference call 39 Receive conference call Owner Use case name Actors related Tr
78. dvisor meetings are held every Thursday from 14 15 to 15 00 Date Room Week September 15 R54 37 September 22 R54 38 September 29 R54 39 October 06 S24 40 October 13 R54 41 October 20 R54 42 October 27 R54 43 November 03 R54 44 November 10 R54 45 November 17 R54 46 Customer meetings are arranged in compliance with needs 2 3 Gantt chart We replaced the common Gantt chart with a more advanced TSTETIL diagram created in Microsoft Project 2010 This diagram shows the WBS together with a time axis duration of particular tasks and the logical connection among them The TSTETIL diagram of our project can be seen in appendix C 2 4 Milestones Our plan contains five milestones The first one is at the end of initiation phase containing planning preliminary studies and requirement specification This milestone is planned to cor respond with the pre delivery of the project report The next two milestones are for completing the Scrum sprints The fourth is the completion of our report and the last one is the conclusion of the project Timing of the milestones can be seen from TSTETIL diagram in appendix C e Introduction amp planning phase completed e Sprint 1 completed e Sprint 2 completed e Documentation finished e Project finished 2 5 Work Breakdown structure Work breakdown structure is a method for dividing a project into smaller parts work packages Its purpose is to identify all packages and logically connect
79. e We created a fully functional prototype implementing most of our customer s requirements Visitors can interact with the office owner indirectly by reading their status message schedule or by leaving them a video recorded message They can also interact with the office owner directly by placing an audio call to the office owner s Skype account using the door sign as a means of communication Our usability tests have shown that it is intuitive and easy to use The remaining requirements and also other features can be implemented at a later date Due to its architecture the application itself is flexible and can be adapted to run on a different device Our solution if deemed suitable can be used by people in the entire IDI department or even the entire university as a way to save time and therefore also money From there it would be easy to assume it could also be used by companies all over the world Trondheim November 23 2011 Elise Boinnot David Andr ssy Eilertsen Michal Kraj ek Knut Esten Melandso Neksa Andreas Nordahl Sibel Ayper Tasdemir Igoris Tirmailovas Contents Contents I List of Figures VI List of Tables VIII 1 Project directive 1 1 1 Project purpose and background bona Be amp AA A ERAS EC RULES IA 2 1 2 OS CCTV ES oa exo aporte ede ke moe PAR WR EORR ETE ee oar 2 L3 Project SCOPE us de ues n x ums nho S b 2 es nc Ee MON eet ers 2 1 4 Measurement of project effects te A os Wee b See Sy oes EO e
80. e of the plan uses the Usability Test Plan template 27 The test itself consists of three major parts e Simulation of real life usage of the system e Assessment of easy of use of particular tasks reflect requirements e SUS assessment 10 5 1 Participants The expected end users of our DoorSign solution from the visitors perspective are students university staff and external visitors The largest expected group are students coming to visit a professor We cannot expect that visiting students and professors will be from the ICT domain IDI de partment respectively Therefore the subjects of the usability testing will be mostly students and some professors from NTNU in any field of study who are not connected to the application in any way There will be approximately 15 test subjects in our usability study and they will participate individually Each team member will be responsible for two subjects where at least one will be from a different field of study than ICT As there are three international students in our team we will also have several foreign students participating in the usability test The participants do not require any prior knowledge of our product or other software systems to participate in the usability test 10 5 2 Methodology The methodology we are utilizing will be explained through the training prior to the test then the location the equipment the procedure and finally the tasks 110 Training T
81. e you have to pay 10 dollars for it so the community is rather limited 3 6 2 The Android tablet We choose to include the Android tablet in this section even though it will not be used in the final product We found it important to show the amount of research work and time put into this device especially since a lot of that research was very relevant for our second device The following five sections will show solutions that were tested and concluded to be undesirable Skype and SkypeKit Introduction See section 3 6 1 Services Provided See section 3 6 1 Issues and evaluation The complication with this solution is that Skype has no available API for us to integrate with Android specifically only with pure Java There is a restriction on developing for mobile phones and tablets see appendix D 1 Since we would be using an outdated Android tablet we concluded that this was not a good solution for us 24 Session Initiation Protocol Introduction Session Initiation Protocol or SIP is a communication protocol over IP which allows sessions like VoIP Voice over IP streaming and file transferring A session could be a simple two way telephone call or it could be a collaborative multi media conference session This was the best solution for our Android device after Skype failed because it required no third party software or similar Services provided This protocol provides easy ready made solutions for voice chat over t
82. e communication with our customer was done mainly during meetings arranged by our customer contact These meetings were not regular but reflected our team s needs to consult important points and get agreement on the results of the sprints The feedback we got from the customer after meetings and especially after our demonstrations of our product was very beneficial and helped us stay on the right track There were not any problems in the relationship and communication process with the customer despite the many changes in our project At the beginning we had an agreement on the project charter and were able to create a shared view of the requirements specification During the project we were able to handle a device change when preliminary studies showed that we would not be capable of meeting requirements with the original device The final requirement change during the second sprint and negotiating about new functionality led to an acceptable solution for both sides Advisor Although we had the opportunity to contact him through e mail communication with our advisor was held almost exclusively during our weekly advisory meetings on Thursdays Our preparation for these meetings included a weekly report which contained the agenda of the meeting and questions for the advisor and the most recent version of our final report Our questions were answered and feedback to particular parts of our work was given during these meetings On the other hand w
83. e did not set up any team building meetings that would have provided us with opportunities to get to know other team members better If it had been done it would probably have brought the team work to a higher level Our team also encountered troubles with team members being late as mentioned earlier in this chapter We set up ground rules which should have handled this and similar matters but their concept was not elaborated enough The project manager should have paid more attention to them repeated them on regular basis and enforced them Another useful operation would probably be elaboration and promotion of the list of ground rules to the group contract This contract would be signed by all team members and obligated them to follow them Communication within the team At the very beginning of the project we found out that arranging regular meetings would be problematic due to the fact that each team member had a different schedule This became even more clear when we used the web service Doodle to compare our schedules Our difficulties arranging common meetings during our project were intensified in later phases by travel activ ities illness conflicting project deadlines and other issues We were only able to establish one common team meeting on Tuesdays and one advisor meeting on Thursdays from the beginning of the project As a result we had to arrange many ad hoc meetings which were attended by only a part of our team and did not have
84. e lor cooperation and planning 421 2 29 1 440 400 14 3 Preliminary studies 16 ely BT S DOr A A O eee en BURN Ge ered se 17 3 1 1 The situation and solutions of today ln 17 Salo Thedestred solution ae AA A ts 17 3 2 Customer requirements a a are OR gon E Bos te 17 3 2 1 Functional requirements up a A AAA 17 3 2 2 Non functional requirements A a INIRE LOB t det 18 3 3 Evaluation criteria ood A a 18 3 4 Rejected device A A E ei ERE IRI ERR I RUM ERU 18 3 4 1 The Android tablet dot Y ub cre SR olet te GG dein 18 3 4 2 Issues and evaluation i A EO ees 20 3 5 Components and technical constraints ej 2224 039394 9 ee 21 oou Th Mimo monit r e orea NAS A e AUS Res 21 GO AEVDOISID a2 eus Na lts A Dt e da E op A 23 9 0 Possible solutions i se SSA a EIA 23 3 6 1 The Mimo monitor aoaaa a 23 3 6 2 The Android tablet oco aro Pep ar re AY SERRA Exe IR GR SS feri p ROS 24 pur Chosen solution s a 3 Gio eet ie Rp o uen Cae anas dr du dee Hie ade 28 3 8 Software process model aote kg mre eere Ren cu e Sen e pe px I do pon 28 al E ns xe AUS ce e enki e e kA eI MO Brice I e Gk Oe 28 Qupd Waterfall aara utc Saute ain O Rt 30 3 8 3 Scrum versus Waterfall 5 24 2 5 sk og o TR Rus RE od ae ee 31 3 9 Development technologies le pal dy eld Re OR dE eR dT Y 31 SA MEI RM hr IA E IRIS E aoe AT A A A a 32 DU A o D soot sor A A E V rue wp e ieu al at 32 39 34 Eclipse CT 32 Requirement specification 33 Asi U S
85. e to use the Model View Controller MVC arcitectrual patter it was the best way to ensure the creation of a good graphical user interface A GUI often needs to be changed throughout development process to suit a wide variety of users so it was important for us to separate it from the rest of the code The Singleton pattern is used more for aesthetics rather for its functionality to avoid using global variables thus saving some resources We will also use it to insure that only one object of a class is initialized to avoid complications 5 7 Resulting architetural changes This section will present the changes that have been made to the architecture during the implementation phase Most of these changes were made to the logical and communication view and the overall logic described in the physical view is still intact Therefore the overall structure of the architecture has been consistan throughout the whole implementation process we ve successfully avoided any major architectural drift and or architectural erosion 5 7 1 Realized logical view Class Diagrams Below is the description of changes made to the class diagram during implementation Figure 5 11 Root classes e root folder 5 11 The StartupScreen is used for user input to select the appropriate video output device e model 5 12 This package has three new classes Message Container class responsible for representing the message received from the office owne
86. e would appreciate a more consistent approach from our advisor in team dynamics matters There were several personal discussions between team members and the advisor but these were not reflected during general discussion with the whole team Our advisor gave us much needed feedback and gave the process a push if we seemed to be stuck Several important topics were discussed and subsequent actions were taken after our weekly advisory meetings Overall it was a useful hour we spent every week that helped ensure our project s quality although at times we would have preferred longer meetings Internal communication Ground rules Our evaluation of the communication within the team is explained in greater detail in the Group dynamics section of this chapter see section 11 1 4 We only had a few ground rules to follow see appendix El and due to stress and lack of motivation towards the end of the project some of these rules were forgotten The third rule was one of the only ones that got better as time went on People were able to speak freely without being interrupted and if someone interrupted another team member they would apologize and let them finish The more we got to know each other the more we respected each other of which this is clearly a reflection The language slipped a few times but we mainly spoke English so that everyone would under stand As for deadlines we ended up having only a few of them thus making this rule easy to
87. eKit integration overview 9 56 Figure 5 8 Block diagram 5 5 4 Process view The activities diagrams in figures 5 9 and 5 10 focus on the dynamic aspects of the doorSign The figure 5 9 presents the different activities when a visitor wants to call the owner of the office Once the call is initiated three events are possible 1 The user wants to cancel the call Then the call is simply ended 2 The owner answer the call Then the video conference starts It could stop at any time as soon as one of the two hang up 3 The owner does not answer Then the call is ended after warning the user Whichever event occurs the result is always the same the call is ended The figure 5 10 presents the different activities of the system when the user starts recording a message Once the recording starts three events are possible 1 The user wants to cancel the recording Then the recording is deleted and not sent 2 The user manually stops the recording Then the recording is stopped and sent to the owner of the office 3 The timer runs out As in the previous event the recording is stopped and sent to the owner 97 Entering VideoView Figure 5 9 Activity diagram 1 Calling ecording stopped or timer runs out Save and send recording Figure 5 10 Activity diagram 2 Starting recording 58 At the end of these three events the recording is stopped 59 5 6 Architectural rationale We chos
88. ective During the testing members of our team will act as the office owner and visitor respectively By executing these tests and filling in the questionnaires our test subjects will be a tremendous help in verifying that our product meets our standards At the beginning of this chapter we will describe our goals of the usability study itself and how we approached the process of developing tests that matched our needs We will also introduce a standard way of calculating and interpreting the questionnaire scores with an explanation of which scores we think of as satisfactory Our usability test plans will start with the plan from the visitors point of view In this section we will explain which groups of visitors we imagine will use our product The practical part of our usability study follows this section Here we will describe what kind of materials we will need for the testing and the procedure itself i e how the test subjects will be prepared before the testing starts and details of how the testing will be carried out After this follows a list of tasks that the test subject will try to finish during the testing Our usability metrics section shows how we will interpret the test subjects answers to the questionnaires Our success criteria are linked to these questionnaires and the tasks given to the test subjects The next section contains the test plan from the office owner s point of view with details about materials needed and the proced
89. ed our conclusion leads us to believe that many participants took them for granted and did not mention them when answering question 2 Missing 16 Recognized Figure 10 4 Percentage of the overall functionality recognized by the participants Part 1 2 As shown in figure 10 4 8296 of the overall functionality was recognized by the participants This score is satisfactory given the success criteria described in section 10 5 6 more than 80 127 Part 2 Task questionnaire In the second part the participants were asked to complete a set of given tasks and then evaluate the difficulty of performing them Figure 10 5 presents the results For each task we can see how many participants evaluated it as very easy easy intermediate or difficult very difficult Percentage 096 2096 4096 6096 8096 10096 LI 1 Identify the office owner and his contact information 2 Read office owner s status messag 3 Make a cal to the office owner As 4 Make a call to the office owner and cancel the call after two seconds of Ij dialing 5 Leave a viden message for the office over AAA B D 6 Start a recoding of a message for the office owner and cancel the recording KA after two seconds 7 Find out whether the office owner has had a free time slot at 1 pm today Tasks m Very easy and easy Intermediate Difficult and very difficult Figure 10 5 Difficulty level of tasks as perceived by the participants Part
90. ed rooms Skype ID Make sure rooms Skype account accepts messages only from office owners Skype account Keep rooms Skype ID and password in a secure way Figure 9 5 Attack on Skype An attacker might be able to change the office owner s personal message se figure 9 5 Allowing 98 an attacker to change the office owner s personal message can lead to potential application exposure and loss of reputation An attacker might gain access to the database If the attacker gains access to the database he will be able to change the office owner s personal information Possible attackers Threat Agents It is very important to identify possible attackers to understand how secure the application has to be The level of security has to be a lot higher if there is a possibility that some attackers will have strong a motivation to attack the system Curious Attacker Security researcher independent tester or more likely a colleague wanting to brighten up the office owner s day Script kiddie Computer criminals who attack or deface applications for respect or political reasons Motivated attacker A student who wants to gain access to the lecturers computer to access private information or to take revenge for a bad grade by defacing lecturers DoorSign 9 3 2 Risk evaluation Risk evaluation was performed using OWASP Risk Rating Methodology 22 OWASP was cho sen because of good experien
91. eness as a team in a very good manner What went well e No problems during implementation e Almost all tasks were completed e Good feedback from our customer e Good task assignments e Good planning Problems encountered e Problems in finding common time slots for meetings e Difficulties in cooperation at the beginning of the second part of the sprint e Not enough detailed sprint backlog limiting reassigning task during the sprint Improvements suggested e Set up more SCRUM meetings and focus on collaboration and awareness about the work of other team members e Do more implementation work within a group work e Elaborate the sprint backlog 8 4 3 Burn down chart The burn down chart of sprint 1 can be seen in figure 8 5 A very sharp drop in the first days of the sprint is caused by as was already discussed overestimation of our work especially Skype part Our stagnation in the middle of sprint is also clearly visible in the burn down chart A package of approximately 15 hours of work left at the end of the sprint is caused by postponing the usability tests till after the end of second sprint 9 because the SCRUM methodology does not allow to change the sprint backlog 90 200 180 mum Daily Progress 160 140 deal Progress 120 100 80 60 40 20 1 2 3 4 5 6 7 8 9 10 Iteration timeline days Figure 8 5 Burn down chart for sprint 1 8 4 4 Sprint conclusion Sprint 1 focused on high priority requirements
92. equirements as well as our overall execution of the project 1 7 1 Goals Our goal as a team is first of all to be able to develop a software system that complies with the requirements provided by our customer To us this means a functional prototype of an interactive door sign that can be used by IDI at NTNU We also want to create accurate documentation for our work that is close to the level of those in real world projects This documentation will hopefully show our progress and general effort during the project Secondly we want to learn more about working with team members with different backgrounds and different levels of experience as we could encounter great diversity throughout our careers 1 7 2 Expectations of team members This project will be a success if we are able to e Learn enough from the experience to feel we can use it in future projects e Work as a team regardless of our different backgrounds and international students e Understand and do what the customer wants e Generate a good product that the customer likes e Make a working prototype e Get a good group dynamic and manage to work well together without too many problems 1 8 Project charter The project charter can be found in appendix F Chapter 2 Planning This chapter explains how we have organized our group divided the project into manageable parts and chosen our milestones Our risks are listed here including ways to handle them The Lifecycle model
93. fied that there are recordings left on the Door Sign 2 The Owner chooses one of the record ings 3 The Owner plays one of the recordings 3a It is not possible to play the recording due to a bad Internet connection 3al Return to 2 As an owner of the office I want to be able to receive and play any recorded messages from visitors that may have happened during the period my receiving device was offline and additional information like timestamps Receive recording s A Visitor Owner Use case name Actors related Trigger Objective Preconditions Post conditions Normal event flow Participate in a video conference UC7 Participate in a video conference Owner Visitor The Owner accepts the incoming call from a Visitor The have an successful video conference F4 Initiate conference call F5 Receive con ference call Satisfying streaming quality achieved 1 The two Actors engage in a conversa tion Variations in the event flow la Due to bad Internet access it is impossi ble to have an understandable conversation 1b Due to bad streaming protocols it is im possible to have an understandable conversa tion Scenario User story N A Table 4 7 Participate in a video conference 42 Visitor Use case name Actors related Trigger Objective Preconditions Post conditions Normal event flow Variations in the event flow Scenario User story UCS Vie
94. gile software development process can be summarized in the Agile Manifesto 5 Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan By following the rules and manifesto of agile software development we see that the focus is on rapid development with incremental improvements implementation of functionality and the constant change of requirements risks and all other dynamic parts of the project Scrum is a derivation of the agile development process which comes with a set of rules guidelines and predefined roles see figure 3 3 Roles e Scrum Team The Scrum Team is the main core of the project group and is responsible for developing and delivering the product according to the product owner s requirements 28 ScrumMaster B M Input fram End Users Product Baily Scrum pom Team and Backlog Meeting and il is Refinement Artifacts Update ner eam l Review E jew y EE aem ar re A f print s En Fl Potentially ae SEL NES No Changes Shippable Product Sprint Planning Sprint in Duration or Goal Increment Meeting Backlog Parts One and Two unti Product Backlog Retrospective Figure 3 3 Scrum workflow 7 e Scrum Master The Scrum Master is responsible for keeping the Scrum Team on track making sure the team accomplishes the goals of each sprin
95. gress 11 2 The result 11 2 1 Requirements fulfillment We were able to implement all final requirements One original requirement F5 video confer ence was implemented partially meaning only the audio part was available and was replaced by the new requirement F8 calendar see section 9 5 2 A short summary of our requirement specification can be seen in table 11 1 Requirement F5 together with other potential improvements are discussed in section 12 4 Quality requirement Q1 Security was fulfilled by the security analysis described in section 9 3 and requirement Q2 Usability by our usability study described in section 10 The last quality 137 Short description Priority Finished Finished in F1 Displaying Information H J sprint 1 F2 Update message remotely H V sprint 1 F3 Record video message M V sprint 2 F4 Store video message M V sprint 2 F5 Video conference M H x F6 Database H V sprint 1 F7 Send video messages L V sprint 2 F8 Calendar M J sprint 2 Ql Security M H J sprint 2 Q2 Usability M H V after implementation Q3 Performance M J sprint 2 Table 11 1 Requirement fulfillment requirement Q3 Performance means to be able to have a normal conversation through the video conference As we used the Skype platform for the audio part of the video conference we were not able to influence the performance of the call in any way 11 2 2 Architecture One of the most important archi
96. he Internet and has a possibility of starting a video conference with other devices SIP provides a wide variety of services that our project requires such as voice call via Wi Fi video call via Wi Fi and instant messaging for device state control Issues and evaluation The main problem using SIP is that it is supported by Android SDK for Android 2 3 and up Our device so far is only Android 2 2 compatible see section 3 4 1 Android and Android 2 2 This restriction stops us from using SIP as our means of communication between the device and other possible client applications Java Sockets 19 Introduction Java Sockets is probably the most obvious approach to solve the requirement about updating a message through a network It is fairly easy to implement and provides communication through a reliable TCP connection There are some downsides to this approach These will be discussed later Since this is one of the standard Java libraries we are not dependant on any third party interfaces or software when implementing these solutions and there are several examples and guides available on the topic of Java Sockets Services provided e Reliable TCP connection e Simple data transfer Issues and evaluation There are quite a few disadvantages of using Java Sockets One problem is that we will have to make a client application that establishes a connection to the application on the device Our customer was clear on the fact that he would prefer
97. he actual result from the usability test versus our initial expectations A list of usability metrics with a description follow 1 Successful recognition of the application s purpose without any knowledge of it described in a percentage 2 Successfully recognized functions of the application without any prior knowledge of them described in a percentage 3 Users rating of particular tasks regarding difficulty of the operation 4 SUS evaluation Percentage of successful recognition of the application s purpose and final location without any knowledge of it As described in the methodology section 10 5 2 test subjects are given the product without any additional information about it s purpose After 30 seconds of examining it they will briefly describe the purpose of the solution Their descriptions are evaluated against the fol lowing statement The purpose of this solution is to serve as an interactive door sign The evaluation of the test subject s answers will be done within the whole team The entire team must unanimously agree on whether or not the participant fully understood the purpose of the solution The metric expresses the number of correctly identified functions of the solution Percentage of successfully recognized functions of the application without any prior knowledge of them Participants write down functionalities of the solution Their responses are evaluated against the following list e Identify
98. he device the user has to have a Skype account The application does not support any other means of message updating and voice calls e A video recorded message cannot be longer than 30 seconds Hardware limitations e While being touched the touch screen goes into a loop of clicks that creates navigational problems There is no way to change settings defining interaction with the touch screen 12 4 Future work In this section we will describe the various things that can be developed further or added to our product To attract a wider range of users the application could be adjusted to work on different platforms other than Windows and have more than one way to interact with the device through internet to change the status message or receive calls As mentioned in earlier chapters and the first section of this chapter the requirement we did not implement was the video conference feature The application functionality can be expanded 143 to include a video conference between the office owner and visitors This will be possible as soon as Skype releases the new version of SkypeKit that supports video conferencing Video recordings can be improved to capture video recordings with a higher quality and length if a better video capture device that is supported by JMF is used The design of the calendar could be improved and the calendar itself could have more func tionality for example letting people interact with it This could inclu
99. he owner of the office must stop auto matically after a reasonable amount of time 3 2 2 Non functional requirements e Q1 Security You should not be able to access other parts of the system than the door sign application e Q2 Usability You should be able to learn all the system features by yourself in a short amount of time e Q3 Performance You should be able to have a normal conversation through the video conference 3 3 Evaluation criteria These are the criteria that must be met regarding the possible solutions see section 3 6 possible solutions we have researched and found as plausible solutions to our requirements and it will justify our choice of a solution to some extent 1 The solution must reflect the customer s preferences 2 The solution must be approved of by the customer 3 Group 7 must unanimously agree on the solution 4 Time estimates and complexity points must be within a realistic range 5 The solution must be able to fulfill the requirements with the highest priority 3 4 Rejected device The biggest issue in our preliminary study was definitely the analysis and complications with the initial device presented to us by the customer the Android tablet After three weeks of research documented in this section and the possible solutions section we had to conclude that it would not be possible to implement all requirments on this device This section will justify why we made this conclusion 3
100. he potential future work that can be done 141 12 1 Requirements and expectations of the customer The main requirement of our customer was a working prototype of the door sign application The detailed descriptions of the requirements can be found in chapter 4 There were also two major quality requirements to focus on the usability and security of the application Our customer was set on using the Skype platform as a solution for the office owner s part which we had in mind when choosing our solution Towards the end of our second and final sprint we had created a fully functional application with all final requirements implemented A Java application was created for the client part and includes most of the original require ments except one The video conference feature was not possible to implement so instead we implemented a calendar enabling the office owner to share their Google calendar and make it visible to visitors This also adds as an extra clue as to whether or not the office owner is available The evaluation of our software security described in sprint 2 ensured the security of the application To make sure our product fulfilled the requirements and expectations of our customer we had two demonstrations one after each sprint Our customer expressed that he was happy with what we had done and that the product design was even better than he had expected Based on this information we have come to the conclus
101. he questionnaire 9 Facilitator expresses the team s gratitude towards the participants for time spent on testing 10 The test is finished If the participants do not have a Skype account and or a Google account a default one is given to them Tasks Table 10 12 gives an overview of the actions that will be carried out during the usability test All tasks have the prerequisite that the application is fully functional Task ID Description 1 Add DoorSign contact name tdt4290 password tdt4290 Update the personal message Answer a call Receive a video message Remove door sign contact oe W bb Table 10 12 Task list Template The description of each task will follow the template given in table 10 2 Description of the tasks Item Description Task ID 1 Name Add door sign contact Preconditions None Execution steps d 1 Press Add contact in Skype 2 Find username tdt4290 3 Type tdt4290 the password of the DoorSign s Skype account as the request message 4 Press Send request Expected result Participant added the door sign account in the contact list Table 10 13 Task 1 description 121 Item Description Task ID 2 Name Update a message Preconditions None Execution steps Expected result 1 Open a conversation with the DoorSign s Skype account 2 Enter a message in the text field 3 Send the message Participant was able to send a message and receive a reply from
102. here will be no training provided either for the user or the test personell The test is based on zero knowledge of the application participants may have some information about the device Location There will be more than one location for the testing of the device depending on the group of participants Most of the testing if not all will be done on the Gloshaugen campus The location of the testing will be a random place capable of supporting the required equipment Equipment In order to be able to run the usability test the following equipment must be available e Personal computer with all the necessary drivers and the Skype application installed e Personal computer operator who will simulate the office owner s activities through the Skype application e The DoorSign device Mimo UM 740 e The DoorSign application with all interaction functionality implemented can be in a form of prototype e Internet connection e Questionnaire in a paper form Procedure 1 Participants are welcomed by the test facilitator 2 Participants are given a basic overview of the test This includes information about usability testing in general and about the purpose of this particular test The participants are given a brief explanation of the test procedure and are informed of the duration of the test The term DoorSign wil not be used in the briefing The participants will not be given any information revealing the purpose of the appl
103. his part of the project as the priorities and complexity might shift after the review A simple sprint review needs to 26 1 Confirm that the team has delivered on its commitments 2 Confirm that the overall project is on track 3 Examine the implemented functionality e Sprint retrospective The sprint retrospective is a team oriented self reflection meeting focused on continuous process improvements 3 8 2 Waterfall The Waterfall model is a sequential software development process Its name Waterfall can be interpreted as an analogy of the fundamental process steps the phases requirements design implementation verification and maintenance see figure 3 4 EM ro RN oo N Maintenance Figure 3 4 Waterfall workflow 28 These phases are somewhat similar to the Scrum sprint phases but there are no iterations in the Waterfall model Each phase is only visited once through the entire project lifetime so the 30 flow of the project is like a waterfall The central idea behind the Waterfall model is that when you are done with a phase there is no possibility of returning to it later Therefore the team needs to make sure that the requirements and the design are correct early on in the project This can save a lot of time and effort later on 31 The reason for this is that when you are done with a phase there is no possibility of returning to it later 3 8 3 Scrum versus Waterfall There are several reasons w
104. hy we chose Scrum over other agile software development processes and most importantly why we chose Scrum over the Waterfall method These points are the most relevant to us regarding the project size project time and complexity Adaptability This is one of the most important points Scrum allows us to be much more reactive and responsive to changes in the project requirements and risks much thanks to the iterative sprints and what each sprint contains as explained above The Waterfall model is strictly sequential It is impossible to make changes to already committed phases requirements and similar topics Relationship with customer In Waterfall the only place where the customer has any say is in the Requirements phase There is little or no feedback throughout the project until the final evaluation verification phase In Scrum however the customer is much more involved with the project team during the development This is good for both parties There is continuous feedback and evaluation throughout the project s duration This will help us avoid bigger mistakes focus on what is important and deliver the desired product to the customer Estimations and priorities Our team has limited experience in dealing with estimations in larger projects By using Scrum we will have more than one sprint By the completion of the first sprint we will have learned more about estimations and the estimations for the next sprint will be improved
105. ication itself 3 Participants are given the device with the application installed without any additional information 4 Participants are told that they have time to explore the application 5 Participants are given prepared forms which includes the questionnaire This step must not be carried out before step 4 as the questionnaire might be able to reveal some aspects of the solution 6 Participants are asked to write what the purpose of the solution is in the prepared form T Participants are asked to write down the discovered functionalities of the solution in the prepared form 111 8 Participants are told to perform a particular task see table 10 1 and fill in the corre sponding part in the form Their behavior while performing this action is observed and measured 9 The previous step is repeated until all tasks are carried out 10 Participants are asked to fill in the rest of the questionnaire 11 Facilitator expresses the team s gratitude towards the participants for time spent on testing Tasks Table 10 1 gives an overview of the actions that will be carried out during the usability test All tasks have the prerequisite that the application is fully functional Task ID Description Template 1 2 3 4 al Identify the office owner and his contact information Read the office owner s status message Make a call to the office owner Make a call to the office owner and cancel the call
106. ich was also suggested by the customer as an option to look into Twitter is an online social networking and microblogging service that enables its users to send and read text based posts of up to 140 characters informally known as tweets Services provided Twitter is a very popular and accessible service It allows users to post tweets from anywhere with an Internet connection Because of its popularity there are many ways to embed reading of the tweets in Android applications The best way we found was the TWITTER4J Java lib e 10096 pure Java Works on any Java Platform version 1 4 2 or later e Android compatible e Zero dependency No additional jars required e Multi platform approach makes message updating a lot more comfortable and accessible Issues and evaluation This approach will satisfy all our message transferring requirements but alone it will not solve all our requirements see Section 3 2 Customer requirements Google Talk 13 Introduction Google Talk is a free voice over Internet protocol VoIP and streaming client application created by Google It uses an open protocols Jabber and or Extensible Messaging and Presence Protocol XMPP It is possible for us to use our own client to connect and use the service Services provided e IP voice e File sharing e Instant messaging e Video conference e Voicemail can be 10 minutes long 26 To provide such services Google uses Jingle which is an extension of XMPP X
107. iews to show on the screen and the logic for changeing between them e connector 5 15 This package was expanded and now contains these classes AudioConnector class responsible for handling all things concerning audio recording converting and storing CalendarConnector class responsible for handling the connection to GoogleCalen dars and fetching data from it skype package contains KeyManager is responsible for managing keys used to connect to the Skype runtime LoginLogoutManager manages loging in and out of the Skype account MySkype detects personal hardware settings of the machine running the appli cation and set up Skype to use the audio and video devices properly SessionListener is used to listen for Skype events during at runtime SkypeMessageParser parses the office owners messages 62 doorSign connector doorSign connector skype Key Manager LoginLogoutManager SkypeConnector SkypeMessageParser AudioConnector AbstractCamConnector A CalendarConnector n Figure 5 15 The connector package video package contains x CamConnector handles the connection to the internal web cam of the Mimo monitor x AbstractCamConnector The CamConnector will extend this class Communication Diagrams The first communication diagram figure 5 16 shows what happens when the user presses the Call button 1 User interacts with the device by pressing the Call button 2 The ButtonL
108. igger Objective Preconditions Post conditions Normal event flow Variations in the event flow Scenario User story UC5 Receive conference call Owner A Visitor trying to contact the owner through a conference call To have a video conference with the Visitor through the door sign F3 Initiate conference call N A 1 The Owner receives a call from the Door Sign 2 The Owner chooses to reject or accept the incoming conference call 2a The Owner might not have time to reject or accept the incoming call the Visitor hangs up 2al Return to 1 As an owner of the office I want to be able to receive any incoming conference calls from visitors when my receiving device is con nected to the Internet able 4 5 Receive conference call 40 Receive recoding s Owner Use case name Actors related Trigger Objective Preconditions Post conditions Normal event flow Variations in the event flow Scenario User story Table 4 6 UC6 Receive recording s Owner The Owner s receiving device connects to the Internet and one or more unheard recordings are available To receive any recorded messages left by any visitors during an offline period Owner s receiving device must be online The Visitor s must have left a recorded mes sage during the Owner s receiving device was offline The ability to stream the recorded message left by the Visitor s 1 The Owner gets noti
109. ill our customer s expectations The customer seemed to be very pleased with the results The only comment was that the font size of the phone number and e mail address should be bigger but other than that it looked professional 8 4 2 Sprint retrospective During this sprint we started the implementation part of our project using SCRUM methodol ogy As we had no experience with SCRUM and we expected a lot of problems with SkypeKit we calculated with the worst case during our estimations But all implementation work went fine and we managed to implement all features from the sprint backlog Exception are usability studies which were after discussion with our advisor excluded from sprints and will create a separate part of our project Project plan was appropriately updated We encountered several problems especially in the middle of the sprint we had problems to set up regular meetings because of different timetables This caused two days delay in integration 89 of modules Because of overestimations in difficulty of the Skype part this delay did not cause any problems at the end of the sprint One of our goals for this particular sprint was larning to use the SCRUM methodology This goal was met but some improvements were presented and will be discussed in the next sections During this sprint and especially in the planning part we managed to divide work based on our skills and compensated for our weaknesses This affected our effectiv
110. immediately after finishing sprint 1 The first day of the sprint was dedicated to planning and the actual duration of the implementation was 9 days 9 1 2 Resources Total estimated resources for this sprint were the same as for the previous one 180 person hours Our team has 5 developers and with respect to 25 hours of work during one week we estimated workload of one programmer to 4 hours per day Duration of the implementation work was 9 days 5x Ax 9 180 9 1 3 Sprint goal The goal of sprint 2 was to finish the implementation work This includes implementing all remaining requirements and finalizing the application 9 1 4 Sprint backlog The sprint 2 backlog can be seen in table 9 1 together with priorities and estimations of our workload Feature numbers refer to the product backlog 4 3 Feature No Description Priority Est hours 6 Record video M 2b Js Store video H 25 8 Video conference M H 55 9 Send video messages L 15 4 Security Q1 Application restriction M H 15 10 Performance L 15 Table 9 1 Sprint 2 backlog 93 The sprint backlog covers the following requirements e F3 It should be possible to start recording a short audio and video message If not stopped manually the recording will stop automatically after 30 seconds e F4 A recorded message should be stored locally e F5 It should be possible to have a video conference with the owner e F7 When the receiving device
111. important to look at the vulnerabilities from a point of view of experienced highly motivated attacker To calculate the overall likelihood this formula was used Overall likelihood Skill Level Motive Opportunity Ease of discovery Loss of integrity Awareness 6 To transform the threat numeric value into HIGH MEDIUM LOW table 9 2 is used Likelihood and Impact Levels 1 to lt 3 LOW 3 to lt 6 MEDIUM 6 to 10 HIGH Table 9 2 Likelihood and Impact Levels To determine the overall severity of the risk we used table 9 3 Overall risk severity HIGH Medium High Critical Impact MEDIUM Low Medium High LOW Note Low Medium LOW MEDIUM HIGH Likelihood Table 9 3 Severity An estimation for the likelihood and technical impact has been made for each of the different threats introduced earlier in this section e Attacker may be able to access other parts of the system Se table 9 4 and 9 5 for the estimation of likelihood and technical impact Threat agent factors Skill Level Motive Opportunity 7 10 10 Vulnerability factors Ease of discovery Ease of exploit Awareness 10 10 T Overall likelihood 9 HIGH Table 9 4 Access control likelihood 101 Loss of confidential information Loss of integrity Loss of availability 10 6 0 Overall technical impact 5 33 MEDIUM Overall severity the threat is High Table 9 5 Access control technical impact e At
112. inued However research for both the devices will be presented in this chapter This is to justify why we had to change the device as well as show that much of the research that was done was relevant also for our new device 16 3 1 The DoorSign 3 1 1 The situation and solutions of today As of today there is no solution that satisfies the customer s needs at NTNU The standard door sign is a plaque which contains the room number name and title of the person who is occupying the office the owner It does not contain any kind of contact information or notifications that can easily be changed if we disregard any post it like solutions The ability to leave a message is restricted the person must physically write them beforehand which is impossible to do if you are not physically near the office e g indisposed or late 3 1 2 The desired solution The wanted situation is to have an interactive door sign installed outside the office doors This door sign will be able display customized messages via a remote device e g a web app mobile app e mail or something similar People can also leave audio and video messages by interacting with the door sign when the owner of the office is indisposed which the owner can then check remotely any time via an application Streaming video and audio in real time is also desirable as it will allow the door sign to act as an intercom regardless of the whereabouts of the owner 3 2 Customer requirements
113. ion ID Identifier of the test see table 7 1 Name Name of the test Date Date of the test Responsible Name of the person responsible for the testing by default the test man ager Requirements What requirements will be tested Precondition Conditions that have to be met in order to start the test Execution steps Steps to perform Expected result The expected results of the test Results Results of the testing Table 7 2 Testing template 7 3 Test cases In this section we will describe each test The result of each test will be given in the chapter of each sprint 75 Sprint 1 Item Description ID UNI 001 Name Display information Date During sprint 1 Responsible Elise Boinnot Requirements F1 Precondition None Execution steps Expected result 1 Launch the application The owner s picture and information first and last names title e mail mobile number are displayed Table 7 3 Display information test case Item Description ID UNI 002 Name Database Date During sprint 1 Responsible Elise Boinnot Requirements F6 Precondition UNI 001 Display information Execution steps Expected result 1 Update MyName MyLastName MyTitle MyPicture MyMail MyMobileNumber in the database 2 Launch the application The information displayed reflects the information stored in the database This means that the application is able to query the database for information Table 7 4 Datab
114. ion that the product we created met the customer s expectations and we are therefore classifying it as a success f I Will be back at 19 00 Kai Torgeir Dragland Senior Engineer Tif 92666301 E mail kaitorge idi ntnu no Figure 12 1 The final product 142 12 2 Goals and expectations of our team At the beginning of our project we wrote down the goals and expectations of our team First and foremost we wanted to develop a functional prototype fulfilling the requirements provided by our customer together with accurate documentation The second goal was to learn more about working with team members with different backgrounds and different levels of experience During one of our first group meetings we collected expectations from every team member Below is a list of these expectations and a check mark showing whether or not we feel they were fulfilled Expectations Fulfilled Learn enough from the experience to feel we can use it in future projects Work as a team regardless of our different backgrounds and inter national students Understand and do what the customer wants Generate a good product that the customer likes Make a working prototype Get a good group dynamic and manage to work well together with out too many problems Sud deu See USES 12 3 Limitations of the product Software limitations e The application was created and tested on a Windows platform e To successfully use the application with t
115. is software also helped us create a Time scaled tasks with explicit task interdependency linkage TSTETIL diagram and was useful during basic tracking of our progress 15 Chapter 3 Preliminary studies In our preliminary studies we will give a short description of our customer s requirements We will show our research on the devices we were given and discuss various solutions on how to best implement our requirements We will also mention components and technical constraints that must be taken into consideration In our evaluation criteria we have written which conditions must be met in order to deem a solution optimal This solution will then be described and justified thus concluding the chapter We found it important to describe and discover new concepts methodologies technology and techniques necessary to succeed in the given project task Any possible issues will be important to find as early as possible in the requirement phase Another important point is project size the amount of time we get to finish the project conveys the size and importance of it compared to any other course project to date The main focus of this chapter will be on the technical and technological constraints with the different devices After extensive research it was concluded that it would not be possible to implement many of the requirements on the first device given to us Therefore we were given a new device and development for the old device was discont
116. istener receives the button event and invoking setActivePanel cal in the View class 3 When this method is called the View class removes the current view and shows the Call View 4 CallView then tires to start an audio call by invoking placeCall in SkypeConnector 5 When the call is over the Call View invokes setActivePanel inf in View 6 The View class then switches back to the default view which is the nformation View The second communication diagram figure 5 17 shows what happens when the office owner updates his status message 1 SessionListener catches a new event reception of a new message from the office owner 2 A message is received by SkypeConnector 3 SkypeConnector then it invokes setMessage in Model 63 Information View 3 l stopTaskQ 6 2 startTaskQ user presses call button ButtonListener Figure 5 16 Audio call communication diagram l updates message SessionListener InformationView 756 updateQ 5 changes are propagated to all listeners java beans PropertyChangeSupport Figure 5 17 Message update communication diagram 4 firePropertyChangel 64 4 When the new value is set Model uses the method firePropertyChange in the java beans Property ChangeSupport class 5 The change is propagated to all listeners 6 InformationView that is listening to changes made to Model notices the change and updates the correct variable Info
117. ization team Organizational structure of our team is described in detail in section 2 2 1 6 2 The customer IDI department of NTNU university represented by Torstein Hjelle The customer s main concern is that the final product does what they want it to do After all they are the ones who are going to use it Name E mail Torstein Hjelle torstein hjelleGidi ntnu no Table 1 2 Customer 1 6 3 The course staff and the advisor The course staff meaning the course responsible and the course coordinator is part of the evaluation team and will take into consideration all the different factors that have played a part in our project Our advisor Muhammad Asif will have followed us through our process functioning as our steering committee giving us the incentive to work harder Collaborating with him is essential to our final report Name E mail Muhammad Asif muhammaQidi ntnu no muhammad asif idi ntnu no Table 1 3 Advisor 1 6 4 The external examiner It is important that the pre delivery and the final presentation have a high quality and are as understandable as possible showing clearly what we have accomplished The external examiner will be part of the team that will evaluate our work 1 7 The team What we are mainly working towards is a good group dynamic that will allow us to create a quality product Our final report depends on this and on how well we have understood and implemented the given r
118. ject grows the number of files grows with it Files that belong in the same category should be placed in the same folder so as to make navigation easier This will help us organize our documents so we can find what we are looking for without wasting time References and quotations will be generated using BIBTEX This tool separates different types of references such as articles books and web pages and automates the whole process for the 70 writers of the document This prevents bad or incorrect references which is especially useful when you have multiple individuals working on the same set of documents 6 2 Templates To make the writing process faster we have created templates for writing summaries of meet ings We have three kinds of meetings customer meetings advisor meetings and group meet ings Another template we need is for the weekly report a document we need to send our advisor every week These templates can be found in Appendix DB and show the general structure of our summaries and the weekly report The date time duration and place for the meeting must always be documented as well as who attended the meeting Then follows a short summary in the form of short sentences or full text documenting decisions and explaining in detail what was discussed during the meeting The time and place for the next meeting will be found at the end of the document 6 2 1 Group meetings Group meetings slightly differ from advisor an
119. kype pass mob nr e mail picture Figure 8 4 Entity Relationship diagram 86 Our main database table is Room which contains references to the other two tables Each room can contain one office owner or can be empty that is shown by the 0 to 1 connection between Room and Person tables Each room has only one Skype account that is represented by the 1 to 1 connection between Room and Skype tables Table name Field name Field description Person person id identification number Used for reference name name of the office user This field contains all the names like first last and middle names title title of the office owner This field contains the scientific degree of the office owner tel nr phone number of the office owner This field con tains land line phone number mob nr mobile phone number of the office owner This field contains personal or work mobile phone num ber of the office owner e mail E mail of the office owner picture office owners picture Link to the picture depicting office owner Room room id identification number of the table entity Used for reference person id identification nubmer of the user This fields con tains reference to the person table to identify the person residing in the room room nr room number This field contains actual room number building building name This field contains a name of the building Skype skype id identification number Used for reference room id ide
120. low we also wrote some ground rules that all members of the team should follow They are listed in appendix E 2 2 1 Roles and responsibilities e Project manager Michal The main responsibility of the project manager is the whole project itself The project manager should resolve conflicts make sure that everyone is informed about the progress of the project and the work of other members He should make sure everyone has some thing to do and that the team meets the deadlines He is the leader of the group meetings and prepares agendas e Customer contact David The customer contact has the responsibilities to receive and send information to the customer he maintains communication with the customer To avoid misunderstanding he is the only one in contact with the customer by mail or telephone Then he has to relay the information to the team He arranges and helps organize the meetings with the customer and has to write the customer summaries e Advisor contact Sibel The advisor contact has the responsibility to maintain communication with the advisor She has to send the required documents every week weekly report Figure 2 1 Project organization e Implementation manager Knut The implementation manager supervises the implementation team He is responsible of the implementation of the software He should divide the work between the developers e Document manager Sibel The document manager is responsible for the
121. m The actors in our use cases are Owner and Visitor Actor ID A1 Owner Description This is the owner of the door sign The door sign is displayed outside the owner s office The owner will only interact with the door sign through a remote device Examples of actions Has an application with a simple minimalistic GUI and the ability to write messages and to stream video Actor ID A2 Visitor Description The Visitor will only interact through the door sign Examples of actions Viewing information on the door sign interacting with it and making calls to the owner of the office through the door sign This shows that the Owner and Visitor are using two different systems independently that are connect through the Internet 4 1 2 High level use case diagrams This diagram below displays our desired behavioral requirements for the two actors Owner and Visitor The circles represent what kind of functionality the actors can perform each explained in more details in section 4 1 3 Low Level Use Case Diagrams 4 1 3 Low level use cases This section consists of 8 low level use cases which consist of a diagram and a textual use case These low level use cases are a derivation of the high level use case diagram presented in picture 4 1 34 Receive recording s Receive conference call A Update message Owner Participate in a video conference View view calendar lt Record message message Initiate conference c
122. m better We would also like to thank our advisor who gave us much needed guidance and revision that shaped our documentation and our test subjects who were a tremendous help in deciding whether or not our system met our standards Abstract The amount of technology we use every day has increased since the introduction of personal computers and mobile phones As our lives become more and more digitalized we seek even more ways to integrate technology and ordinary everyday items At IDI NTNU they wish to take it a step further Door signs are not only a good way to inform people who the owner of an office is they often also give information about whether or not that person is available A potential problem with this is that even if the office owner has left a note saying when they will return there is no way to inform people of delays There is therefore no certain way to tell the exact time they will be coming back An interactive door sign could be a solution to this problem With the added functionality of remote status updating and an interactive calendar that will inform visitors about the office owner s whereabouts and schedule the interactive door sign could save people a lot of time that they otherwise might have spent waiting To create this door sign we decided to develop a JAVA application using the newly developed SkypeKit The application is to be run on a small USB monitor equipped with touch screen a web camera and a microphon
123. ment to the plan make reservation in advance Documentation manager Risk number Activity Probability Consequences Contingency plan Responsible 11 All High Delay problems with communication Buffers in plans proper documentation of work enabling it to be taken over by other team members Project manager Serious family emergency long term illness Risk number Activity Probability Consequences Contingency Plan Responsible 12 All Low Delay problems with communication Buffers in plans proper documentation of work enabling it to be taken over by other team members Project manager Interfering work activity of a team members Risk number Activity Probability Consequences Contingency plan Responsible 13 All High Delay Do work in advance buffers in plans proper documen tation of work enabling it to be taken over by other team members Project manager 12 2 6 1 Risk handling Table 2 2 shows how we approached risks The first row describes consequences Minor Sig nificant Critical and the first column describes probability Low Medium High Minor Significant Critical High monitor take measures take measures Medium neglect monitor take measures Low neglect neglect monitor Table 2 2 Table for risk handling 2 7 Templates and standards 2 7 1 Templates For the purpose of this project we created the following templates e Group meeting template e C
124. merging the audio and video files together Because there was no third party software that could detect and record both audio and video we had to record them separately and then merge them together before sending The Audio part Seeing that JMF was capable of discovering the microphone we agreed to use this solution to capture the incoming audio independently of the video The Video part The only third party library that discovered the Mimo web cam through Java was the LTI CIVIL Larson Technologies Inc Capturing Images and Video In a Li brary 15 CIVIL was only able to capture images more specifically images of the format java awt image BufferedImage There was no recording option in this library only receiving X amounts of buffered images per second X FPS Therefore we needed a new library capable of storing these buffered images and converting them into a video format 94 The Java media library Xuggler 34 allows you to uncompress modify and re compress any media file or stream from Java This made it possible to convert the series of buffered images into a MPEG 4 Part 14 MP4 video on the fly After the stream of buffered images ended the video was stored locally m User action Event flow backend C Output Recording View CamConnector starting stream of webcam Start recording CamConnector record video AudioConnector record audio VideoAndAudio Sender delete MP3 and MP4
125. mirGstud ntnu no Document manager Advisor contact Knut Esten Melandsg Neks knutesteGstud ntnu no Implementation manager Andreas Nordahl andrnordGstud ntnu no QA manager Elise Boinnot emboinnoGstud ntnu no Test manager Igoris Tirmailovas igorist stud ntnu no Architecture manager Customer IDI NTNU represented by Torstein Hjelle will provide requirements for the soft ware product Advisor Muhammad Asif will control the work of the project realization team and pro vide guidance Project manager Our project manager is Michal Kraj ek He is responsible for governing the whole project His competences are planning problem solving leading group meetings distribution of work and controlling progress He is allowed to delegate his powers to other team members Objectives e Create a working prototype of the application as described by the customer with all high priority functional requirements implemented e The customer has mentioned two main areas to focus on Security and usability Different tests will ensure that the prototype meets certain standards regarding both security and usability e Create a broad documentation of our work and the prototype e Be able to present our final product Project scope The project includes e Prototype of the application e Documentation e Presentation e Small database only for testing and presenting the application The project does not include e Hardware installation e
126. more when they were asked to realize some tasks they found most of them to be very easy or easy still without any prior knowledge Even if these results are very good they can still be improved see section 12 4 An example can be the calendar Its GUI could have been more elaborated This study also allowed us 138 to get some feedback from end users especially about the user interface For example some participants thought that some of the names of the buttons could be improved such as Place call Some participants were also wondering who they were actually calling and how via Skype cell phone etc Even if we did not get the chance to have more participants for the owner s perspective see section 10 7 2 we were very satisfied with the answers given by our customer as he thought the application was a success 11 2 4 Planned effort As written in section 2 1 1 our estimated workload was 325 person hours in 13 weeks which means 2275 working hours in total Our final workload was 1913 working hours which is a considerably lower number During our project we found it difficult to reach the expected amount of working hours per person per week which was 25 The reason was absences often up to a week due to traveling activities and illnesses among other things resulting in the necessity to work 25 additional hours during the next several weeks This showed to be unrealistic The same applies to conflicting projects and other work
127. ms for the project as a whole Our customer had several small objections regarding the visual part of the application but these were minor problems and were adjusted Otherwise the feedback was positive Sprint resulted in the fully working application with all the requirements implemented except the cancelled one which was now ready to be used in the the usability testing phase 106 160 140 120 100 80 60 40 20 mu Daily Progress deal Progress 3 4 5 6 7 8 9 10 11 12 Iteration timeline days Figure 9 6 Burn down chart for sprint 2 107 Chapter 10 Usability study To determine whether or not the product is a success we need to determine if users can use this product to it s full extent creating the product is only one part of the job The another crucial part is to make sure it can actually be used by the end user The product should be easy to use easy to learn and most importantly it should be useful Based on ISO s definitions of usability 30 this means that users should not have any difficulties figuring out how to use the product and once they have learned how they should be able to perform tasks quickly To make sure this is the case with our product we have developed usability tests for our two groups of users Most of our test subjects will execute the usability test from the visitor s perspective while the rest will execute the usability test from the office owner s persp
128. n front of the door sign who wants to use it A 2 1 Office owner The different functionalities for the office owner are the following 1 Add door sign contact Remove door sign contact Update message Answer a call Receive video message Q Oo AeA C N Display calendar A a escription for each functionality is given below Add door sign contact 1 Press Add contact in Skype 2 Find the proper Skype name of the door sign 3 Enter the password of the door sign Skype account as the request message 4 Press Send request Remove door sign contact 1 Open a conversation with the door sign Skype account 2 Send the door sign account s password as an nstant Message 3 You would then be removed from the door sign contact list Update message 1 Open a conversation with the door sign Skype account 2 Enter your personal message in the text field 3 Send the message and wait for a reply from the door sign that it has been updated 149 Editing the last message you sent to the device will also edit the personal message on the door sign Answer a call Answer calls from the door sign account as you would for any other Skype call Receive video message The door sign account will send you a video file if a video message has been left by a user of the door sign You can receive this message the same way you would receive any other file using Skype Display calendar You can display today s events from
129. nality recognized by the participants Part 1 2 127 Difficulty level of tasks as perceived by the participants Part 2 128 SUS evaluation Part 3 aud ace ea redeo ques v ue ad x REO 129 Difficulty level of tasks as perceived by the participants Part 1 130 Weekly workload sx 9 aro a a Oe eee 140 The inal product AA II 142 Gantt Chart resido Pood ee ut A O Ac e A E e de dcs 157 Gantt chart ao dex ADA sk GAG ut E e a bai dedu AA 158 VII List of Tables id EZ 1 3 2 1 2 2 4 1 4 2 4 3 4 4 4 5 4 6 4 7 4 8 4 9 4 10 4 11 7 1 2 7 3 7 4 7 5 7 6 T T 7 8 7 9 7 10 8 1 8 2 8 3 8 4 8 5 8 6 9 1 9 2 9 3 9 4 9 5 Project realization team ada Xon E me me 6 eee e Roe es 3 A 3 ISO RA aa EP e PRIN PEE NX SEE a e o b eii 4 OvernensoL TISKSS e E is SUR TORO EE T Gecko A o OE eg 9 Table for risk handling llle 13 View information a oe aset A A o RO RI ee d eel Des 36 IHRE ciu P a Aa is ra ai Se 37 Record messages tos se teal a da a O A The eG 38 Initiate conference call o a A oe RE BS a A 39 Receive conference call 5 OE Rue hue kt OM Ren EA amp 40 Receive recording s e dc ede qnte eren Y deb er P dep wes e 41 Participate in a video conference s isa a RI OY a 42 VMiewcalendar soia ee Aetius Rican e e oS Gah aed ea eto vial dde ata 43 Functional requirements 00 noy eoe dre ee eso Rem s 45 Non functional requirements oo a 45 Product backlog ti e el e 62 8 e P A
130. ndix E Ground rules Appendix F Project charter Glossary Acronyms 141 142 143 143 143 145 148 148 149 149 150 152 152 153 154 156 159 159 159 160 161 162 166 168 List of Figures 2 1 3 1 3 2 3 3 3 4 4 1 5 1 5 2 5 3 5 4 5 5 5 6 5 7 5 8 5 9 5 10 5 11 5 12 5 13 5 14 5 15 5 16 5 17 5 18 5 19 5 20 8 1 8 2 8 3 8 4 8 5 9 1 9 2 9 3 9 4 9 5 9 6 Project organization aooaa ch aee cha Set ee eek oe bats Chad T7 WonderMedia WM8650 Ys de aae a eee Oe Ge e Et 19 Mimo LMSTAU I8 uus dE Rex e pace ee A EC RS Rog y E a 22 Scrum workflow f lt s i arrasar caia QHECREUN weed esa 29 Waterfall workflow 28 o o o RR Rd RR 30 High level use case diagram ele 35 Class diagrati a socs s BY Seo p E EROS a a e a ese 51 Communication diagram Video conference ll 52 Communication diagram Update message a a 00 53 Communication diagram Startup ooo a 54 Packagediagrain 0 p acus cedex e ne be DRY UE AA A AA n 54 Deployment diagram 2l 55 SkypeKit integration overview 9 o o o o ooo o 56 Block diagram circa ea E RO e 9d OE e Ee ooh b OR 57 Activity diagram 1 Calling on A de d 58 Activity diagram 2 Starting recording a ln 58 Root class s G r a od Pee ee ea hee bee eR ARA 60 The model packige 2 i ke he mom eee eee Oe OS Go 61 The controller package cis redil risa
131. ne object is allowed to be initiated from a specific class Very intuitive and easy to implement 5 5 Architectural views We decided to use 4 1 architectural view model because it suited our approach of designing our architecture Using this approach we decomposed our system into 4 views These views are targeted at different stakeholders to make the system easier to understand for the customer and users and to give the development team overview of what needs to be done and how the system is structured To make system comprehensible for the end users we used use case view This view consists of use case diagrams with short description Logical and Development view are made for the implementation team These views describe structure of the system and relationship between system components Process view consists of activity diagrams that show possible scenarios of how the system can be used These diagrams are also useful for the implementation team to get an overview of the system run time processes and do some brainstorming on how to implement these processes This view is also usable for the end user to see all possible actions and their results 50 Physical view describes how our system is connected to various hardware components This view provides high level overview of the system with short description of components that system is connected to 5 5 1 Logical view connector model
132. nector that will result in sending the video file to the office owner through Skype The last communication diagram figure 5 20 shows what happens when the program starts The only change made to this diagram is that information from the database will be fetched by one method call to DatabaseConnector instead of multiple method calls 1 Program starts 66 DatabaseConnector 4 fetchPersonalData 5 1 setName 5 2 setTitle Figure 5 20 Startup communication diagram Main class initiates all views Information View Video View Recording View etc Main class connects to Skype by calling login in SkypeConnector Main fetches information about the owner of the office from the database CU 4 W N Then Main sets the correct values in the Model 67 Chapter 6 Quality assurance Every project needs quality assurance to ensure an overall quality of the project or process We have our own definitions of quality and will therefore strive to uphold the standards we have created to maintain consistency in our documentation and our process in general Our customer s happiness is as crucial in this project as it is in any other project in the working world Customers have their own definition of quality and their happiness depends on the quality of the product Therefore it is natural that we have some level of quality assurance so we can create the kind of system that the customer really wants To do
133. negotiate a requirement change Another problem was with Java library which did not detect our device This resulted in problematic syn chronization of audio and video that was recorded separately using a different library These problems resulted in several days delay of the second sprint As a result not all team members could work on the usability study as was intended e Interfering work activity of a team member This was a very common problem within all phases of the project Problems caused by this risk were handled by keeping minutes from all meetings which kept team members updated and delegation of work to other team members e Illness This was a quite common problem causing trouble during all phases of the project Problems caused by this risk were handled by keeping minutes from all meetings which kept team members updated and delegation of work to other team members e Lack of communication internally We encountered this problem during several days of the second sprint as a result of the interfering work activity of a team member risk described above This problem contributed to delay caused by the problem with implementation risk described above From the described risks we can see the way they have been solved using buffers in the plan by reducing time dedicated to particular phases or by delegating work to other team members Our risk analysis was precise and we did not encounter any new risks during our pro
134. next sprint 9 We had the following views implemented during sprint 1 1 Information View 2 CallView 83 javax swing JFrame javax swing JPanel javax swing Figure 8 1 GUI Swing build 3 RecordingView 4 RecordingInformationView Information View This is the main view of the system that comes up at start up All the functionality of our application in this sprint was added to this particular view Most of the information to fill this view is taken from a database e Room number e Name of the office owner e Office owner s title e Office owner s contact information e Office owner s picture At the first startup the personal message is set to a default text The personal message can be updated by sending a Skype IM to the device s Skype account After the initial change of the message the default message is changed to the last message sent to the device s Skype account CallView This is intended to facilitate video conference functionality that will be implmented in next sprint In this sprint buttons and actions were added to these views to simulate e Call initiation 84 Room 258 Default message Kai Torgeir Dragland Senior Engineer TIf 92666301 E mail kaitorge idi ntnu no Posted on 01 01 1970 01 00 Record a Calendar Place call video message Figure 8 2 The information view e Call cancelation e Reception of automated message in case
135. ng as the CPU and Wi Fi connection are sufficiently fast The microphone is not of high quality but is more than good enough for us to record someone just talking The camera has video quality that is comparable to any standard web cam which is sufficient for our needs 20 If the CPU is as good as it is suppose to be it should not be problem to run a video conference on it The other requirements do not demand much of the system as long as the device is able to connect to the Internet we should be fine Testing the tablet with different apps and web pages gave mixed results It was able to run games like AngryBirds 2 and Pac Man 12 but with very low frame rate So low in fact that the games where not really playable Streaming YouTube videos worked fine though Whether the CPU performance will be a problem for us depends on if we are using the SkypeKit 10 or a open source protocol The open source protocol choice might demand more of the system than the choosing SkypeKit for our implementation Installing Skype 25 did not work our device was not supported Wi Fi connection seems to be the only part of the device that works well We will be able to get a good steady connection to the NTNU wireless network It should not be a problem to send or receive a video and audio through the Internet connection We may have to disable one or more of the buttons on the device so that you can not easily access other parts of the system than inten
136. ntification number of the room This fields con tains reference to the room table to identify skype account of the room skype login Skype account login This field contains login name to the rooms Skype account skype pass Skype account password This field contains pass word to the rooms Skype account building building name This field contains a name of the building Table 8 2 Description of ER diagram Room information is identified by the MAC address of the machine the system is running on Each room has a corresponding reference to the Person table that contains personal information about the office owner Each room has its own Skype account through which the DoorSign users can communicate to the office owner and vice versa Detailed description of the ER diagram can be seen from table 8 2 All information is pulled from the database once during the start up of the application It takes about 16 ms to get the resulting data 87 8 3 Testing In this section we will show the results of the tests done in sprint 1 Descriptions of test cases can be found in chapter 7 3 8 3 1 Test executed In sprint 1 we executed the following tests e Test case UNI 001 e Test case UNI 002 e Test case UNI 003 e Test case UNI 004 Usability testing has been postponed till after the sprints when all the functionality has been implemented 8 3 2 Test results The result of the four test cases are shown below Item De
137. ocumentation of our work and the prototype e Be able to present our final product 1 3 Project scope The project includes e Prototype of the application e Documentation e Presentation e Small database only for testing and presenting the application The project does not include e Hardware installation e Hardware security 1 4 Measurement of project effects e Utilization of the Mimo device this monitor is too small for serious work e Possibility of an easy interaction between a visitor and the office owner e Time saving for both visitors and the office owner 1 5 Duration The project starts on August 30 2011 and its duration will be 13 weeks The final presentation will be on November 24 2011 1 6 Stakeholders 1 6 1 Group 7 The role of the project team is to fulfill all requirements given by the customer The team must go through all phases of a typical software project be able to provide a final report and defend the results in front of the customer and external censors Our project realization team has 7 members Names and contact information can be seen from table 1 1 Name E mail Michal Kraj cek michaklGstud ntnu no David Andr ssy Eilertsen davidaeGstud ntnu no Sibel Ayper Tasdemir tasdemir stud ntnu no Knut Esten Melandsg Neks knutesteQ stud ntnu no Andreas Nordahl andrnord stud ntnu no Elise Boinnot emboinno stud ntnu no Igoris Tirmailovas igoristQ stud ntnu no Table 1 1 Project real
138. oftware Development Kit SIP Session Initiation Protocol SUS System Usability Scale SVN Subversion TSTETIL Time scaled tasks with explicit task interdependency linkage Gantt chart with linkages among tasks WBS Work Breakdown Structure WiFi Wireless Fidelity XMPP Extensible Messaging and Presence Protocol 168
139. okes startInformationView 6 The Main class then switches back to the default view which is the Information View 52 l updates message InformationView 756 setMessage 5 changes are propagated to all listeners java beans PropertyChangeSupport Figure 5 3 Communication diagram Update message Made 3 firePropertyChange The second diagram figure 5 3 shows how the program responds when the message is updated through Skype 1 A message is received by Skype 2 SkypeConnector invokes setMessage in Model 3 When the new value is set Model uses the method firePropertyChange in the java beans Property ChangeSupport class 4 The change is propagated to all listeners 5 InformationView that is listening to changes made to Model notices the change and updates the correct value The last communication diagram figure 5 4 shows what happens when the program starts 1 Program starts 2 Main class initiates all Views Information View Video View Recording View etc 3 Main class connects to Skype by invoking login in SkypeConnector 4 Main fetches information about the owner of the office from the database 5 Then Main sets the correct values in the Model 5 5 2 Development view The package diagram figure 5 5 is very simple as the scale of the system is quite small The arrows explain the association between the different packages 5 5 3 Physical view Here is a shor
140. on Overview 3 Decompose Application 4 Identify Threats 5 Identify Vulnerabilities Identify Security Ne Objectives v Application Overview Identify Decompose Vulnerabilities Application NN Identify Threats ME Figure 9 2 Threat Model Flow Identify security objectives To ensure that our application is secure we have to determine what parts of it need to be protected e Identity The office owner s identity does not need to be protected The private infor mation about the room has to stay private Since each room has a unique Skype account that communicates with the office owner directly rooms Skype ID and password need to be protected e Reputation Since somebody already hacked the IDI map monitors the possibility that people will try to mess with the DoorSign is high The application has to withstand all known attacks that were used on the IDI map monitors e Privacy and regulatory The application will run on the office owner s personal computer so in an indirect way the application should protect the office owner s personal data Application overview and application decomposition Our system consists of three parts 96 e Database e Skype Kit e Application Application DataBase Skype KIT Figure 9 3 Data Flows The application gets its information from a remote database The data traveling between the ap plication and the da
141. ons interfaces or anything similar that we may need as long as it s supported by the Windows operating system Therefore the constraints will be few and limited Specification and details e Name Mimo UM 740 21 Figure 3 2 Mimo UM 740 18 e Screen 7 widescreen LCD touch screen 800 x 480 WXGA resolution e Microphone Integrated e Camera 1 3 megapixel Webcam e USB 2 0 e Other Touch controls for on off and volume e OS Windows Issues and evaluation The biggest constraint is the software drivers required to utilize this device A Windows 64 bit operating system cannot correctly install all the drivers leaving the web camera and microphone disabled There are no available speakers on the Mimo monitor which means the final software product will require an external sound source to support the audio part of the video conference The Mimo device is working smoothly alongside Windows 7 32 bit with all the features described in the specification 22 3 5 2 SkypeKit Introduction SkypeKit 10 gives us access to all the functionality of Skype including chat messages file transfer VoIP and video conference We will use SkypeKit for all communication between the owner and the DoorSign This will give the user access to the DoorSign through any device that can run Skype Specification and details All Skype functionality is available through an application called SkypeKit Runtime The DoorSign application has
142. ook a usability test the office owner s perspective The results were very satisfying Every task from our questionnaire see section 10 6 7 was considered as very easy and the final system usability scale score see section 10 3 was 95 which means grade A 9 5 2 Requirement change One of the major issues that influenced this sprint was a requirement change We were not able to implement the video part of video conference as SkipeKit 10 does not support this functionality yet As a result of this discovery we arranged a meeting with our customer and discussed the problem We explained why it would not be possible to implement video conference and also announced that this functionality probably will be available in the next release of SkypeKit Our customer agreed on postponing this requirement to the future work and proposed a new requirement to be implemented instead calendar functionality Implementation of calendar functionality was estimated to 40 hours and replaced the video part of our video conference requirement which was canceled 9 5 3 Sprint retrospective Sprint 2 was the last sprint in our project and all implementation work had to be finished We focused on the remaining requirements from the product backlog and finalizing the application The requirement change which happened during the sprint influenced our progress Using the SCRUM methodology sprint backlog cannot be changed is frozen after the sprint planning
143. order to be able to run the usability test the following equipment must be available e Personal computer with the Skype application installed e Personal computer connected to the DoorSign installed with all the necessary drivers e The DoorSign device Mimo UM 740 e The DoorSign application with all interaction functionality implemented can be in a form of prototype e Internet connection e Questionnaire in a paper form e User guide for the office owner Procedure 1 Participants are welcomed by the test facilitator 2 Participants are given a basic overview of the test This includes information about usability testing in general and about the purpose of this particular test The participants are given a brief explanation of the test procedure and are informed of the duration of the test The participants will be given some information revealing the purpose of the application itself 3 Participants are given the office owner user guide and asked to read it 4 Participants are given the personal computer with Skype application installed 120 Participants are given prepared forms which includes the questionnaire Participants are told to perform a particular task see table 10 12 and fill in the cor responding part the form Their behavior while performing this action is observed and measured 7 The previous step is repeated until all tasks are carried out 8 Participants are asked to fill in the rest of t
144. ot Results Everything works according to the test case Table 9 10 Record video test result Item Description ID MOD 002 table 7 8 Date 06 11 2011 Executioner Elise Boinnot Results Everything works according to the test case Table 9 11 Audio call test result Item Description ID MOD 003 table 7 9 Date 08 11 2011 Executioner Elise Boinnot Results Everything works according to the test case Table 9 12 Download messages test result Item Description ID MOD 004 table 7 10 Date 06 11 2011 Executioner Elise Boinnot Results Everything works according to the test case Table 9 13 Calendar test result 9 4 3 Evaluation of tests During sprint 2 we executed the test cases MOD 001 table 7 7 MOD 002 table 7 8 MOD 003 table 7 9 and MOD 004 table 7 10 As seen in table 9 10 table 9 11 table 9 12 and table 9 13 our tests were all successful All implemented functionality has been tested and is working correctly 9 5 Sprint evaluation 9 5 1 Customer feedback At the end of the implementation a customer meeting was arranged in order to present the finalized application to our customer Because of the new requirement see section 9 5 2 this 104 meeting was especially important Demonstration revealed several small bugs in the code but the functionality of the final application was successfully demonstrated Our customer had several comments regarding button labels and font sizes The customer also t
145. oth audio and video will not be possible to implement unless we are able to update the device to a later version of Android This was later deemed impossible see Section 3 4 1 Uberoid WM8650 HYBRiD HoneyCombMOD Uberoid WM8650 HYBRiD HoneyCombMOD To improve the overall performance of the device and update it to a newer version of Android it was decided that we would try installing a custom ROM on the tablet After a lot of searching we have concluded that the only ROM available for this particular device is the Uberiod HYBRiD HoneyCombMOD made by HardcoreHacker 14 Universal Uberoid WM8650 1 5 2 HoneyCombMOD v8 After installing v8 of the MOD every thing about the device got better It was running a lot smoother and the response from it was much faster The MOD did not update the tablet to a newer version of Android it is still running 2 2 The drawback with installing the MOD was that the Wi Fi no longer worked It was able to search and detect different wireless networks but unable to connect to them properly Uberiod WM8650 1 5 1 HoneyCombMOD v7 1 Installing v7 1 of the MOD gave us another GUI as well as a slightly improved performance It did not fix our issue with the wireless not working properly Uberoid WM8650 1 3 0 HYBRiD HoneyCombMOD v6 3 This version had worse performance than v8 and v7 1 and did not fix our Wi Fi issue 3 4 2 Issues and evaluation Using the display to show a video conference should not be a problem as lo
146. owner of the office If you do not press the button Send before the end of the minute your recording will be stopped and not send to the owner of the office You would still return to the main screen 151 Appendix B Templates B 1 Group meeting Date Time Place Attendees Andreas Nordahl David Andr ssy Eilertsen Elise Boinnot Igoris Tirmailovas Knut Esten Melandsg Neks Michal Kraj ek Sibel Ayper Tasdemir Agenda Item Topic Time minutes 1 Ou Cb Next meeting scheduled for Notes 152 B 2 Customer meeting Date Time Place Customer Attendees Andreas Nordahl David Andr ssy Filertsen Elise Boinnot Igoris Tirmailovas Knut Esten Melandsg Neksa Michal Kraj ek Sibel Ayper Tasdemir Agenda Item Topic Time minutes 1 OU gt Co bo Next meeting scheduled for Notes 153 B 3 Weekly report Group no Week no Date Attendees Andreas Nordahl David Andr ssy Filertsen Elise Boinnot Igoris Tirmailovas Knut Esten Melandso Neks Michal Kraj ek Sibel Ayper Tasdemir Agenda of next advisor meeting Item Topic Time minutes 1 Oy A Ww N Status report
147. pecomector Figure 5 19 Record video message communication diagram The forth communication diagram figure 5 19 shows what happens when the user presses the Record Message button 1 User interacts with the device by pressing the Record Message button 2 The ButtonListener receives the button event and invokes setActivePanel rec in the View class after that the application is waiting for user input 3 The ButtonListener receives the button event and invokes run method in VideoCon nector and AudioConnector and the recording of the message starts After that the application is waiting for user input or for the timer to run out 4 The ButtonListener receives the button event and invokes stop method in VideoCon nector and AudioConnector and the recording of the message stops After that the application is waiting for user to press send button 5 The ButtonListener receives the button event and invokes send method in VideoAn dAudioSender that start the process of sending the recording to office owner 6 While sending the video file to office owner the Recording View invokes setAc tivePanel inf in View T The View class then switches back to the default view which is the Information View 8 In the mean time the VideoAndAudioSender invokes send method in VideoAndAu dioMerger that will merge the audio and video files to one video file 9 When the mergind is done VideoAndAudioSender invokes sendFile in SkypeCon
148. quickly I found the system very cumbersome to use Oo OF OF Lu Y I felt very confident using the system Oo OF OF 0 Y I needed to learn a lot of things before I could get going with this system O OF OF L1 O Comments Table 10 11 SUS questionnaire visitors perspective 10 6 Usability test plan designed for office owners This section describes a test plan for conducting a usability study for the office owner perspec tives The basic outline of the plan uses the Usability Test Plan template 27 10 6 1 Participants The expected end users of our DoorSign solution from the point of view of the office owner are university staff especially from IDI department 119 We do not require any prior knowledge of our product or other software systems for participating in the usability test 10 6 2 Methodology This section describes the methodology we will use for testing usability For describing this methodology we will first explain the training prior to the test then the location the equip ment the procedure and finally the tasks Training Training consists of reading the user manual of our application Location There will be more than one location for the testing of the device depending on the group of participants Most of the testing if not all will be done on the Gl shaugen campus The location of the testing will be a random place capable of supporting the required equipment Equipment In
149. r Skype supports instant messaging voice calls video calls file sharing and much more Since Skype works as a P2P application it does not have a server through which users commu nicate instead users communicate to each other directly or by using supernodes user clients with public IP s acting as directory service that form Skype infrastructure There is a server that contains all users information but is used for authentication purposes only To maintain stable fast good quality connection Skype is breaking down sent information into small packages before sending them through Internet This top level block diagram figure 5 8 shows overall overview of our architecture The WMS650 device interacts with the user via touch screen microphone and a speaker The device connects to the office users pc via USB 2 0 Our system consists of custom made appli cation with integrated SkypeKit SkypeKit connects to the Skype infrastructure that has P2P architecture consisting of authentication server and SuperNodes to direct traffic The system gets office owners information from the MySQL database located on a remote server 95 Built by Developer NH Provided by SkypeKit Optionally built by Developer pra S UL Chat i m T SkypeKit Application Interface Runtime Audio PCMHost for PCM Audio Skype Audio VoiceHost for RTP Audio Library SAL Video 7 Library SVL VideoHost for RTP Video Figure 5 7 Skyp
150. r through Skype VideoMessage Container class responsible for keeping and representing the video message recorded by the device e controller 5 13 recoridngHandlers package was added This package is responsible for handling the video and audio data received by the application from the device VideoAndAudioSender is responsible for invoking VideoAndAudioMerger and send ing the file to the office owners Skype account 60 group7 doorSign model AbstractModel Message VideoMessage CalendarEvent Figure 5 12 The model package doorSign controller doorSign controller recordingHandlers VideoAndAudioMerger VideoAndAudioSender ButtonListener Figure 5 13 The controller package 61 VideoAndAudioMerger handles the merging of audio and video files to one video recorded message group7 doorSign view Panellnterface RecordingView InformationView CalendarView CallView RecordingInformationView Calendarlmage Figure 5 14 The view package e view 5 14 Contains all the views we will be using Addidional views created RecordingInformation View was created to give office visitors some feedback on failed calls if the office owner did not answer a call Calendar View is used to inform the office visitors about office owners current days schedule CalendarImage is a container class used to store and maintain as in repaint the calendar image View maintains what v
151. results y te ce la E AU A CR DIE 0 BS 129 Requirement fulfillment x roe a a Ane dn EE REO e 138 IX Chapter 1 Project directive Qur project directive functions as a general introduction to our project The purpose background and scope of the project will be presented as will our objectives We will then introduce the team and our project s stakeholders before we describe our team s goals and expectations for a successful project 1 1 Project purpose and background As written in the project description given by IDI NTNU t he goal of this project is to design and implement a functional prototype of an interactive door sign to be used outside for instance office doors We have been provided with a monitor that we are going to use as a door sign This monitor should display information about the owner of the office such as name title and e mail address It should also display a customizable message that can be updated so that people will know without a doubt when the person they are looking for will be available The name of our project is Interactive Door Sign 1 2 Objectives e Create a working prototype of the application as described by the customer with all high priority functional requirements implemented e The customer has mentioned two main areas to focus on Security and usability Different tests will ensure that the prototype meets certain standards regarding both security and usability e Create a broad d
152. rmation View 6 1 stopTaskQ CalendarView 4 1 repaintQ Calendarlmage Figure 5 18 Calendar communication diagram The third communication diagram figure 5 18 shows what happens when the user presses the Calendar button 1 User interacts with the device by pressing the Calendar button 2 The ButtonListener receives the button event and invokes setActivePanel ca in the View class 3 When this method is called the View class removes the current view and shows the Calendar View 65 4 CalendarView then tires to show the office owners schedule by invoking repaint in Calen darImage The method repaint is called at all times continuesly while the Calendar View is shown to display real time information 5 When the Timer runs out or the user presses cancel thr Calendar View invokes setAc tivePanel inf in Model 6 The View class then switches back to the default view which is the Information View InformationView 3 1 stopTaskO 10 3 startTask user presses Record a video message button 2 setActivePanel rec ButtonListener 3 2 startTaskO 10 2 stopTaskO 9 setActivePanel inf 5 1 runQ 5 2 runQ 7 1 stopO X 9 1 sendO 6 user presses stop button 8 user presses Send button 4 user presses record button AudioConnector VideoAndAudioSender VideoConnector 11 1 send9 N11 2 sendFileQ Videoandandiontereer sts
153. rmation about the owner will be stored in a database The information should update automatically if changes are made to the database or if you get a new remote message through the Internet connection 5 1 2 Requirement F2 One of the main functionalities of this application is to update your status remotely To do this the application will need to be able to receive information through an Internet connection and then update the proper information We will need a networking part that takes care of all connections to the outside world This networking part should be separate from the rest of the system to localize changes 5 1 3 Requirement Q2 The part of the program that has to do with the visual representation of information and it should be separate form the rest of the program Given our focus on usability the user interface will probably change many times during the development phase of the project Therefore it will be a good idea to maintain the code for the user interface separate from the rest of the system to localize changes 5 1 4 Requirement Q3 For the video conference functionality to be usable it is important that the delay of the con versation does not exceed 300 ms One way to ensure this kind of performance is to use a third party software 48 5 2 Architectural tactics 5 2 1 Usability Design time tactics To ensure good usability we will have to make regular changes to the user interface to reflect users inpu
154. rowser without the need to install additional software e Web cam video broadcasts Enable meeting hosts and participants to use a web cam to broadcast live video in meet ings enhancing the effectiveness of overall communication Hosts and participants can pause share or stop their cameras at any time during the meeting e Text chat Leverage the flexibility to conduct one on one or community chat in context within an existing or new application interface without having to launch or run separate desktop chat applications Issues and evaluation The service is not free Usage of the compiled software is free of charge and does not require any additional software that is not free Development of the software is also possible using open source software The only fee Adobe takes is for server traffic All servers get 15 worth of traffic free each month but we are not sure that traffic is enough for multiple devices There are no guides or tutorials for Android development and we do not even know if it is possible 27 3 7 Chosen solution The most important factor in deciding which solution to choose is whether or not it fulfills our evaluation criteria see Section 3 3 Evaluation criteria or comes close to fulfilling each point Even while we were working on the Android device we were given at the start of the project our customer expressed a wish to integrate Skype or a similar third party chat and video service in the final solution
155. rtin Ken Schwaber Jeff Sutherland and Dave Thomas Manifesto for agile software development http agilemanifesto org iso en 2001 Visited 10 09 2011 John Brooke SUS A quick and dirty usability scale http hell meiert org core pdf sus pdf Visited 04 11 2011 Wittawat Chaisaraseree Scrum methodology with software development works http software document blogspot com 2011 07 scrum methodology with software html Visited 28 10 2011 Product Manager Colin Gibbs and Tech Lead Wei Huang Video chat on your android phone http googlemobile blogspot com 2011 04 video chat on your android phone html 28 04 2011 Visited 20 09 2011 Developer skype com Skypekitoverview https developer skype com images SkypeKitOverview png Visited 28 10 2011 Developer skype com SkypeKit online http www developer skype com 2011 Vis ited 12 09 2011 Eclipse The eclipse foundation open source community website http www eclipse org 2011 Visited 21 09 2011 Freewarelovers com PacMan online http www freewarelovers com android app pac man 2011 Visited 12 09 2011 Google Open communication google talk for developers http code google com intl en apis talk open communications html 2011 Visited 17 09 2011 145 14 HardcoreHacker Uberoid universal honeycombmod http techknow freeforums org 15 16 17 18 19 20 21 22 23 24 26 27 28 29 30
156. s a nuisance and a distraction We experienced that it was difficult to reach 25 working hours per week and that to replace a week s absence is almost impossible in a close time frame team member had an excused week long absence in the first week and this could cause trouble in commitments to compare the workload to other team members The project manager fulfilled all required work by delegating task but reaching a balanced workload of all team members using this approach is very difficult especially when there are planned traveling activities unpredicted illnesses conflicting projects and many other similar issues 136 11 1 5 Risk management In this section we will discuss the risk identified during the risk analysis see section 2 6 which were encountered and the way we handled them e Problems with hardware The original device caused many problems during our prelim inary studies We spent a lot of time trying to update the operating system in order to be able to fulfill requirements In the end we had to reject the device and do some parts of the preliminary studies again for the new device The result was a delay which was handled using a buffer in our plan and a reduction of the time dedicated to architecture studies e Problem with implementation We encountered problems with implementation espe cially during the second sprint We were not able to implement the video part of the video conference feature and had to
157. s minimize and close buttons Since the device has no other means to control the application this solution should solve this threat Attacker may be able to change the office owners message threat has two levels of defense Application accepts messages only from the office owners Skype account Only the office owner knows rooms Skype ID the ID will be kept on a secure MySQL server Attacker may gain access to the database this threat is harder to treat as the database where the office owners information will be kept is supposed to be secure by default and we have no control over it A highly skilled attacker might be able to access this database but it would have impact on other IDI applications and would be treated by IDI system administrators 9 3 5 Conclusion Building software security is an ongoing process Most software that is safe today might not be safe tomorrow but we feel that our application is safe enough for it is current usage 9 4 Testing In this section we will show the result of the tests executed in sprint 2 Descriptions of test cases can be found in chapter 7 3 9 4 1 Test executed In sprint 2 we executed the following tests e Test case MOD 001 e Test case MOD 002 e Test case MOD 003 e Test case MOD 004 9 4 2 Test results The result of the four test cases are shown below 103 Item Description ID MOD 001 table 7 7 Date 08 11 2011 Executioner Elise Boinn
158. s of our final report We ended up using only lower case letters in our Latex files while the files in our other folders included capital letters Most of the documents used underscores instead of spaces The ones who did not were still functional and no one experienced any errors and as we had made the standards after we had already created some of these documents we decided against changing their names just so they would meet them We made sure every file name was in English and as descriptive as possible As the project grew so did the number of folders in Dropbox Each folder was structured so that navigation would be as easy as possible and reflected the structure of the final re port Documents regarding the report were in separate folders than for example summaries of meetings This was done so that they would not be confused with each other All references were generated using BIBTEX which made our job a lot easier Templates Writing summaries of meetings and the weekly report went fast as we used our templates It shaved off a lot of the time we would have spent setting up the documents and figuring out how to write them All we had to do was follow their structure with some minor modifications and it would be finished within minutes The last part of the summaries that had information about future meetings could have been utilized by better planning Had all meetings been planned before the end of the last or had we decided to
159. s we could choose from are covered here as well as the one we ultimately chose With the inclusion of this chapter in our final report it will be easier to show our team s planned progress during the 13 weeks we had for this project compared to how it went in reality The fact that we have a project plan we should follow is a test of our cooperation and organizational skills Every project is defined by the three dimensional target triple constraint and each of the dimension has its relative importance As our project is non commercial and has static resource allocation the most important constraint is time Therefore a feasible plan is crucial for the success of the whole project 2 1 Resources 2 1 1 Human resources The estimated workload of every team member is approximately 25 person hours per week during 13 weeks This makes 325 hours per person for the whole project Our team consists of 7 members and therefore human resources in total are 2200 person hours 2 1 2 Technical resources e Workstations in P15 building e Virtual servers with software e 500 pages of Printouts e Copier in IT 154 e Electronic mailing list e CVS SVN configuration tool 2 2 Project organization In this section we describe our different roles and responsibilities which reflect our skills and what we generally feel we can contribute with This information was mapped early on during the first group meetings To maintain group communication and f
160. scription ID UNI 001 table 7 3 Date 13 10 2011 Executioner Elise Boinnot Results Everything works according to the test case All information dis played correctly Table 8 3 Display information test result Item Description ID UNI 002 table 7 4 Date 13 10 2011 Executioner Elise Boinnot Results Everything works according to the test case Table 8 4 Database test result 88 Item Description ID UNI 003 table 7 5 Date 14 10 2011 Executioner Elise Boinnot Results Everything works according to the test case A default message is displayed at first launch otherwise the last message updated is displayed Informaiton about the message date time is also displayed Table 8 5 Display message test result Item Description ID UNI 004 table 7 6 Date 14 10 2011 Executioner Elise Boinnot Results Everything works according to the test case Table 8 6 Update message remotely test result 8 3 3 Evaluation of tests During sprint 1 we executed the test cases UNI 001 table 7 3 UNI 002 table 7 4 UNI 003 table 7 5 and UNI 004 table 7 6 As seen in table 8 3 table 8 4 table 8 5 and table 8 6 our tests were all successful So all implemented functionalities are tested and working 8 4 Sprint evaluation 8 4 1 Customer feedback At the end of sprint we set up a customer meeting to demonstrate our product in its current state and ensure that the application fulf
161. se access control dica y IRA ato Ete X ROS BOR t o 102 Database access control technical impact 102 Record video test result ata due RA AA da 104 Audio call test LESI N 104 Download messages test result a a a 104 Calendar tesbresullo uo ter cach ia su dz ee diuo iocis es duode dedo de 104 Task sb aute us cate M ete cun did E Rar iced muon E eM SOME RENE 112 Task description template 2 lt 3 2o pom 484 mA a RE xe 112 Task desplace e do ava 113 Task 2 descripta Gh a 113 Task 3 descriptiones a natur e er a oI a a E Xa 113 Task 4 descriptioh irs A E eot En de een Re a Eaa IA 113 Task destap le Sed pna eir prop dep teer Aem err irt es 114 asko WES CEIDIdODI ns RO Ub aca E A bte db t A Eo IR Cds 114 Task Tedescnptiotes xoa e epar ar ERR EYE EAT eat 114 Task list questionnaire visitors perspective llle 118 SUS questionnaire visitors perspective 4 2 Soy doe X E Gp o Ae d ER 119 as oA Rit s Ate ema see iHi stet E eM cir M ooi Me e 121 Task tdescription ud ouod s xeu a A queue dh ques Pie re x 121 Task 2 description cda La ack ot dia E Ae FER IGIES ee 122 Task 3 desc LION s 5 34 tsb ue Ke ene E A ee ae is Pe ae Ee 192 Task 4 description L4 ssw a cd de O 122 Fask 5 des ription a doner o ul eser dard qeu ted a AL e Me Hen od 122 Task list questionnaire office owner s perspective les 124 SUS questionnaire visitors perspective o 125 Summary of
162. separate requirements and avoid moving from one task to another This decision determined our planning During sprint planning meetings requirements were estimated as a whole and were not broken down into smaller work packages Smaller work packages would have probably led to more accurate estimations and made it necessary to go deeper into the design of particular application functionality During the self study of the Scrum methodology and its processes especially the sprint planning meeting we obtained new information that the lecture about Scrum had not revealed The new information was that during daily Scrum meetings the small tasks making up the sprint backlog are dynamically assigned to team members who have finished their previous tasks This is a completely different approach than what we did From today s perspective it would probably have been better Daily Scrum meetings were evaluated as a very beneficial tool to maintain awareness among the members of the development team However we could have benefited more from this process if we had used task assignment as described earlier The same applies for the burn down chart it was a beneficial tool for monitoring our progress but smaller task would have made it more accurate In spite of these issues we consider Scrum as one of the best methodologies for managing implementation of projects such as ours 132 11 1 3 Quality assurance External communication Customer Th
163. sight as to how good our product is As a closing argument we will discuss our planned effort versus our actual effort 131 11 1 The process 11 1 1 Planning During the project directive phase we created a project plan using Microsoft Project soft ware The original plan underwent four revisions during the project These changes reflected new information gained during our progress and changes in our project The most important circumstances that affected the project plan were e Delayed preliminary studies caused by device change a lot of time was lost with the original device e Decision to postpone the usability study until after sprints and extend its scale e Delay at the end of the second final sprint The original project plan proved to be flexible enough to handle these issues The plan contained appropriate buffers and enabled us in spite of many changes to our project to implement all required functionalities The final version of our project plan can be seen in appendix C 11 1 2 Scrum methodology The decision to use the Scrum methodology was evaluated as good despite several problems with its usage The core concept of Scrum sprints enabled us to divide our implementation work into independent logical parts The first sprint focused on high priority requirements and the second one on finishing remaining requirements We decided to choose only two sprints as we wanted everyone from the development team to work on
164. small amount of participants the accuracy of this usability test might be low Given more time we could have included more test subjects to complete the test as well as using the results to improve the system 10 7 2 Owner s perspective Results For the owner s perspective only our customer participated Firstly because of a lack of time and secondly because the most important part was the visitor s perspective Since our appli 129 cation has integrated Skype and Google functionality all of the interaction with the DoorSign will be done through either Skype or Google this is part of the reason why we found this perspective less important than that of the visitor For this perspective the questionnaire was divided into two parts In the first part the partic ipant was asked to do some tasks and evaluate their difficulties after reading the user guide The second part was a SUS assessment just like part 3 of the visitor s perspective see section 10 3 The figure 10 7 presents how our customer evaluated the difficulty of the different tasks in the owner s perspective test part 1 Percentage 96 20 40 60 80 100 o de 1 Add door sign contact 2 Update a message Tasks 3 Answer a call 4 Receive a video message 5 Display calendar T 6 Remove door sign contact E Very easy Figure 10 7 Difficulty level of tasks as perceived by the participants Part 1 As we can see in figure 10 7 our
165. sponsible Lack of motivation 2 Planning and preliminary studies Low Project team is unable unable to deliver a working pro totype and or report stress for all members of the team Focus on preliminary studies buffers in plan Project manager Risk number Activity Probability Consequences Contingency plan Responsible 3 All Low Project team gets behind schedule conflicts low quality of final product Assign responsibilities for particular phases and deliver ies maintain a good atmosphere within the team mo tivate the team Project manager Lack of communication internally Risk number Activity Probability Consequences Contingency plan Responsible 4 All Medium Team members will not know what their assignments and responsibilities are unaware of the current progress problems during the connection of software modules lack of cooperation overlapping work Set up team meeting on regular bases daily scrum meet ings Project manager 10 Lack of communication externally Risk number 5 Activity Requirements all Probability Medium Consequences Creating the product based on bad unapproved require ments lack of guidance problems during presentation of the final product Contingency Regular meetings with customer and advisor maintain plan contact with customer and inform him about progress and relevant issues signed requirements and project charter Responsible
166. stumer showed great interest in us implementing an application that has Skype integrated with it This solution would allow the owner of the office to interact with the door sign using several different devices The only thing required by the user would be 23 to have a Skype account and add the door sign as a contact Both updating the message and making a video call are things Skype would provide an intuitive and well known interface for doing This would increase the usability of the product as no new software would be required for the user of the system because most people working at IDI would already be familiar with and users of Skype Skype has made a developer toolkit for their program available through SkypeKit which is a collection of software and APIs 10 See 3 5 2 for more information about the SkypeKit Services Provided e Voice chat e Video chat conference e Message chat e Calls to landline and mobile phones Issues and evaluation After our initial evaluation of Skype and SkypeKit as a possible solution for the Android tablet we saw the potential in using this solution but unfortunately it did not work with our Android tablet see Section 3 6 1 Skype and SkypeKit After receiving the Mimo monitor we could use pure Java do develop the solution so Skype and SkypeKit were again a possibility The developer site contains multiple tutorials with Java and a good support team The only issue is that this API is not open sourc
167. t enforcing the Scrum frame work and holding the daily Scrum meetings Product Owner The Product Owner conveys their vision of what the finished product should look like and how it should behave i e the requirements It is then up to the Scrum Team to produce a set of technical requirements that fulfills the Product Owner s visions The Process e Product backlog The product backlog contains a set of features functional and non functional requirements elaborated by the Product Owner and specified by the Scrum Team Here the Scrum Team prioritizes each feature e g by planning poker and receives feedback from the Product Owner e Sprint planning meeting During the planning phase of the project the features in the product backlog are distributed over a number of sprints determined by the features priorities complexities and the dependencies between them e Sprint backlog The features of each sprint are placed in the sprint backlog of that sprint e Sprint There are usually 2 4 sprints in a small to medium sized project each allotted with a fixed amount of time In each sprint features are incrementally implemented into the final product The typical steps are 1 Design 2 Implementing Coding 29 3 Testing 4 Integration e Sprint review At the end of each sprint the Product Owner Scrum Team and Scrum Master meet up to review the completed sprint The product backlog will often be rede fined in t
168. t and to make improvements if our usability test gives bad results Therefore we will be using the model view controller MVC pattern witch separates the user interface from the rest of the application Runtime Tactics We will also maintain a model of the system to help us achieve good usability The user should be able to see what state the system is in at any time and should intuitively understand what actions if any he or she can make for example through progress bars The system will also support user initiative in form of buttons to initiate stop or cancel video call With system responding to user actions in form of labels we get a mixed initiative that requires event listeners and event handlers 5 2 2 Performance To solve possible performance issues connected with video conference we decided to use third party software in form of SkypeKit 10 SkypeKit provides a runtime that does all the opti mization work for us Skype has its own optimization techniques and requires as little as 128 kbps connection speed to initiate a low quality video call Our only concern is that Skype operates in super node mode using up bandwidth thus inter fering with connection speed and integrity Fortunately this feature can be manually disabled System parts not including Skype consist of a small Java application that will hardly use any resources at all 5 3 Architectural patterns 5 3 1 Model View Controller Since high usability of
169. t description of the deplyment diagram shown in figure 5 6 e Laptop Laptop represents a pc smartphone with Skype application installed on it Through this application office owner gets some control over Office client application 93 DatabaseConnector 4 1 fetchNameQ 4 2 fetchTitleO 5 1 setName 5 2 setTitle controller Figure 5 5 Package diagram 54 Skype server Office client Internet Figure 5 6 Deployment diagram For example office owner can update the message simply by sending an instant message to Officeclient as to any other person in his contact list Through this client office owner will also be able to receive video calls and recorded messages from Office Client users e Office client Office client consists of our application and integrated Skype run time com ponents to communicate with Laptop The application will get it s primary information about office owner from the Data Base each time it starts Integrated Skype compo nents will allow users communicate to office owner using video conference or by leaving a recorded video message Below is a diagram figure 5 7 showing how Skype is integrated into our application e Database MySQL database will be running on a remote server This database will keep information about all office owners such as office owners picture name title etc e Skype Skype is a P2P application that allows users to interact with each othe
170. t ek n ds 2 b DULIN n Wn selbe 2 RAE cL oe Redi D eie lt rn 3 1 6 Stakeholders A 4 rape amp Sy eee be qu ee eqs dp ee es x 3 EOF Group CIV et Og Da eg Pe ave 3 IR CS BEC OIM tasty ot og Aes eve rs hae So ae OC A Sn On ee E ee AA 3 1 6 3 The course staff and the advisor woes o o a a a a OR Ke DER 3 1 6 4 The external examiner ae ooa aaa aep eue tam ut ep rad 4 L1 De o3 nim euius ae ak ow weet bce ere S Ein qued UR dete m RU 4 A PEERS TCI 4 1 7 2 Expectations ot team members tape xem ESTE EST 4 1 8 Project Charter 2 i Med aw bh end a AE RT d Ee d 4 2 Planning 5 Dae Resources a A EA AS om Dre ut ro eset ea d me A A d 6 2 1 1 Human resources Lara ede Erb ere RCM ANTE 6 23 2 Technical TOeSoU SS e araca malp aa hed s et rS CS dr x SR ud 6 2 4 Project organization A a wu oben e teg pote ura gg 6 2 2 1 Roles and responsibilities a 6 2 212 Plan of meetihgs o LM Tos E eM cele e cag a o VUA gs du IP eh do 7 20 Ganttehart qm A a a dae ele Od ae Ue ie dos ela eo dc TTE 8 24 wWIlestOR See E os Sees o e ok E E EIE Sh ed ek Ss TS XR 8 2 5 Work Breakdown structure uS Gist a kel AIME MC REA a Se 9 2 67 Risk management abe dete Na La e dace oe i er dg p cen dfi n dca o AA 9 203 Risk handing x 3264 nud Th neg ee ete n ONE TOR A 13 2 7 Templates and standards o cade e got and Os fe med da Ph ge vfi c pent e 13 2rd Lempa A Ep ar m npe ume DER E UID d eV Rt BS 13 is MM PT RN od Sede as D E 13 2 8 Softwar
171. t with regards to the overall quality of the software If implemented it will greatly enhance the software and project but the project is not deemed a failure if not implemented e High A requirement with a high priority represents a crucial part of the software If not implemented the project will be seen as a failure 4 2 1 Functional requirements The functional requirements state what the system must be able to do This list will satisfy both the use cases and business requirements that focus on the functionality of the system 4 2 2 Non functional requirements Non functional requirements also known as system quality attributes and functional require ments are orthogonal 4 It describes the desired qualities of how a system should operate and what it should focus on Examples of non functional requirement categories are availability security performance modifiability usability and maintainability 44 Requirement No Description Complexity points Priority F1 F2 F3 F4 F5 F6 F7 F8 Requirement No The device should be able to display a pic ture the first and last names of the owner the owner s title and a short message on its screen It should be possible to update the short mes sages remotely It should be possible to start recording a short audio and video message If not stopped manually the recording will auto matically stop A recorded message should be stored lo
172. tabase is not encrypted The application communicates with SkypeKit 10 by receiving and sending packages to it This communication provided by SkypeKit s out of our control Identifying threats To identify possible threats we needed to find similar systems to learn of their experience One of these systems is touch screen monitors with maps in NTNU IT building According to the designer of the system the most obvious way to mess with the system was to simulate right mouse click on the touch screen monitor using various techniques Other more obvious threats like closing minimizing crashing the application were identified using previous experience of the implementation team 97 Attacker may be able to access other parts of the system User managed to User managed to eee SOR Magen an Application crashed close application minimize application Disable system right Disable application Disable minimize Ensure stability of mouse click function exit button button the application Figure 9 4 Attack on the application An attacker might be able to access other parts of the system than what is intended se figure 9 4 Allowing the attacker to access other parts of the system can expose the office owner s computer and data kept on it Attacker may be able to change office owners message Attacker obtained rooms Skype ID and passowrd Attacker obtain
173. tacker may be able to change office owners message Se table 9 6 and 9 7 for the estimation of likelihood and technical impact Threat agent factors Skill Level Motive Opportunity T 6 5 Vulnerability factors Ease of discovery Ease of exploit Awareness 4 4 4 Overall likelihood 2 5 MEDIUM Table 9 6 Data corruption likelihood Loss of confidential information Loss of integrity Loss of availability 3 3 3 Overall technical impact 3 LOW Overall severity of the threat Medium Table 9 7 Data corruption technical impact e Attacker may gain access to the database Se table 9 8 and 9 9 for the estimation of likelihood and technical impact Threat agent factors Skill Level Motive Opportunity 7 6 0 Vulnerability factors Ease of discovery Ease of exploit Awareness 4 4 4 Overall likelihood 4 8 MEDIUM Table 9 8 Database access control Loss of confidential information Loss of integrity Loss of availability 3 3 7 Overall technical impact 4 3 MEDIUM Overall severity of the threat Medium Table 9 9 Database access control technical impact 102 9 3 4 Identify and threat vulnerabilities Using threat evaluation we can now prioritize vulnerabilities and treat them accordingly An attacker may be able to access other parts of the system threat can be lessened by disabling monitors functions to simulate right mouse click and by removing application
174. tatus message O g O O O 3 Make a call to the office owner DO O O O O 4 Make a call to the office owner and cancel the call after two seconds O O O O O of dialing 5 Leave a video message for the office owner E Eb El eps El 6 Start a recoding of a message for the office owner and cancel the OO OF 0 0 O recording after two seconds 7 Find out whether the office owner has had a free time slot at 1 pm O 0 OF 0 O today Strongly disagree Strongly agree c gt The system would be useful for me as a student Oo OF OF n Ed Using the system would increase the efficiency of my daily work Oo OF OF 0 Y The idea of an interactive door sign is good Oo OF OF 0 d Comments Table 10 10 Task list questionnaire visitors perspective 118 Questionnaire part 3 Tasks question Strongly disagree Strongly agree gt I think that I would like to use this system frequently Oo OF OF n d I found the system unnecessarily complex Oo OF OF Ed I thought the system was easy to use Oo OF 0 Y I think that I would need the support of a technical person to be able to 1 0O OF L1 O use this system I found the various functions in this system were well integrated Oo OF OF 0 Y I thought there was too much inconsistency in this system Oo OF 0 Y I would imagine that most people would learn to use this system very 1 OF OF L1 O
175. tectural decisions we made was to use the Model View Con troller MVC pattern This pattern was used to comply with the quality requirement for the usability of the final product Throughout the implementation process we kept to this pattern only expanding the number of classes used in the packages The resulting class diagrams 5 7 1 looks a lot bigger compared to diagram 5 1 planned in the architectural stage The amount of classes used in packages grew mostly because the team was not familiar with the software solutions used for this project SkypeKit JMF Most of the class and method names used in the architectural stage were kept intact Some of the class and method names were changed because as the team got more comfortable with used software solutions more appropriate names were chosen Considering the size of the application and the requirements we consider the architectural decisions made to be sufficient enough 11 2 3 Usability study The usability study see chapter 10 allowed us to measure how easy our application is to use from the owner and visitor s perspectives This study was a big issue and took much more time than was originally expected because no one in our team had previous experience with it Nevertheless the results of this study for the visitor s perspective see section 10 7 1 were very good because most of the participants figured out the functionalities without any prior knowledge of the application Further
176. test subjects questions or requests e Data logger Records the test subject s actions and comments and takes notes e Visitor representative Call the office owner record video messages and send them to the office owner e Observers Assist the data logger in taking notes They are not allowed to speak during testing e Test subjects Carry out a set of required actions to test the usability of the product 10 6 5 Usability Metrics Usability metrics allow us to measure user performance against specific performance goals The list of usability metrics and their description follow 1 Users rating of particular tasks regarding difficulty of the operation 2 SUS evaluation Users rating of particular tasks regarding difficulty of the operation Participants are given tasks to perform and they will assess the difficulty of the operation A five point rating scale with appropriate labels will be used see questionnaire in section 10 6 7 The metric expresses the difficulty of each task Tasks are evaluated independently SUS evaluation Participants are asked to answer ten question from System Usability Scale see section 10 5 7 SUS calculation procedure 6 1 Sum the score contributions from each item range from 0 to 4 e To For items 1 3 5 7 and 9 the score contribution is the scale position minus 1 e For items 2 4 6 8 and 10 the contribution is 5 minus the scale position 2 Multiply the sum of the scores by 2
177. them The work breakdown structure of our project can be seen on the left part of the Gantt chart 2 6 Risk management During our risk analysis we identified 13 potential risks to our project The list and summary is in table 2 1 Case studies of particular risks follow No Risk Probability Consequence L Inaccurate project plan M critical ps Underestimation of workload L critical 3 Lack of motivation L significant 4 Lack of communication internally M critical 5 Lack of communication externally M critical 6 Negative approach of team member s L significant T Problems with the implementation M significant 8 Problems with hardware H significant 9 Failure of file storage Google Documents L significant 10 Reservation issues e g printer L significant 11 Illness H minor 12 Serious family emergency long term illness L significant 13 Interfering work activity of a team member H minor Table 2 1 Overview of risks Inaccurate project plan Risk number Activity Probability Consequences Contingency plan Responsible 1 Planning and monitoring Medium Project team is unable to meet milestones and finish the project stress for all members of the team Continuous monitoring of the project progress and tak ing appropriate measures buffers in the plan Project manager Underestimation of workload Risk number Activity Probability Consequences Contingency plan Re
178. them with some allowed exceptions This would increase our effectiveness and decrease the amount of cooperation activities We would also have set up some extra rules about e mailing so that there would be as little confusion as possible about meetings while everyone would be fully updated Roles Role and work distribution was a strong part of our team Our team had three international students and was very heterogeneous almost all team members had different backgrounds This diversity was clarified at the beginning of the project and we benefitted from it and utilize the strong sides of particular team members Based on knowledge of our strong sides we were able to divide work so that team members did what they were good We also gave everyone the opportunity to work on various tasks strictly to improve their skills Of course there were many cases where this was not applicable and team members had to do other tasks that were necessary or tasks where they were not so skilled But in general roles and responsibilities were stated well and influenced our project in a very good way Distribution of work A big issue in our group was balancing the workload Our team did not work as a self organizing structure where everyone was committed to reaching the required amount of working hours Filling in the workload table required for weekly reports did not come naturally during the progress of our project and had to be reminded It was mainly seen a
179. ti li wah tom Tera der acd Te Rey dec BM We a dr UM NI Meares di GMAT EL a es I A eee 104 9 5 1 Customer feedback esa para af ees es OSS cie D Ru 104 9 5 2 Requirement change sm ne ELE Ie Bee Co HE ern dy TO DM he 105 9 5 3 Sprint retrospective s nans a ce mq eret ae e be we de pe 105 004 Burn down Chart sta Bk a E ESAE A A e S 106 9 5 5 gt Sprint CONC IMSION s ts m A a a o ta GE boom RE BIRDS ce ROS 106 10 Usability study 108 MAA Beth te ES dd o iS las Si tas Dec SY er i e Lo mc 109 TO o IE noel y Ros A S lle rl SR dire co OR sata 109 10 3 System Usability Scale SUS ue rt m Rude meet VR 109 10 4 List of A e dnd t dete IN E ert M ts 110 10 5 Usability test plan designed for visitors a 110 10 5 1 Participants 22 ose ue e EXER SIS cedi oe Oh 110 T0322 Me thodology SE a d xe A AS d ENSE E e dE 110 10 5 3 Estimated time ot the Test at tex UR s RES ee ee SE 114 10 074 ales dee Catia aol He HR cei af po n cnm ee E A 115 Io Usability MODE d ut onu Rh nere veter a HOO TE D E 115 Mob Success Criteria aio jo a rr ant Osc a Oa E ls end 116 10 5 Questionnaire v swt wipe uy Bt amp ie anh E A RA 116 10 6 Usability test plan designed for office owners 119 IN to n m t s ean meg a Govt oe eR ei enu qe ES dr arp 119 106 2 Methodology ais esae poke SIE ST Ro BRE TORO CIOS de tc 8 120 10 6 3 Estimated time of the test eiu a ur eae ek eee ek be qe PROS 123 ISO MIU Cc 123 10 65 Usability VIGUEI
180. tion To be able to collectively create a coherent product we will need to follow set standards for communication in general implementation work and documentation A short description of these standards can be found in section 2 7 2 in our Planning chapter 69 Communication within the team The basic foundation was set early on when we wrote our ground rules If these rules are broken it could result in disruptions in work flow a failure to communicate a lack of motivation in one or more team members and a lack of progress of the project To prevent this from happening everyone will have to get familiar with these rules and do what they can to uphold them Communicating through e mail is easy but to make sure every team member knows what is going on at all times it is important to use the reply to all feature when you reply to an e mail sent to all the team members Otherwise information of significant importance may be lost To ensure that all team members stay up to date summaries must be written after each meeting Team members are required to read the summaries and can also add to them if needed The templates for these summaries will be discussed later in this chapter Implementation We will have a majority of our team working on the implementation of the different require ments When a piece of code is done other team members as well as future developers and maintainers should be able to understand perfectly what it does To
181. to communicate with the SkypeKit Runtime through a Java wrapper Getting this to work will probably be the most challenging part SkypeKit Runtime will take care of the actual P2P connection between the DoorSign and the owner s device Issues and evaluation SkypeKit has a large amount of tutorials and a forum where you can get help if you have problems with the implementation so we should not have too many problems using the software As long as it gives us access to all the functionality of Skype like it promises we should be fine 3 6 Possible solutions This section presents all the solutions we have researched and tested in order to fulfill our project s requirements These solutions arranged in independent sub sections will have a short introduction then give an overview of the services provided which we would benefit of in the implementation phase And finally we will discuss any potential issues and give a short evaluation of the solution 3 6 1 The Mimo monitor There is only one possible solution discussed under the Mimo monitor and that is Skype and SkypeKit The reason for this is that we did a lot of research on different solutions with the Android tablet see 3 4 1 Therefore when presented with this device which allowed us to use pure Java we knew that a solution using Skype and SkypeKit would satisfy all our requirements and have limited constraints Skype and SkypeKit Introduction This was a solution that the co
182. tudy testing The numbers in the following descriptions refer to the usability metrics in section 10 5 5 1 The percentage of successful recognition of the application s purpose should be more than 8096 2 The percentage of successful recognition of the functions of the application should be more than 8096 3 More than 80 of the answers regarding the tasks should be in the very easy or easy part of the questionnaire 4 SUS score should be higher than 70 see figure 10 1 for meaning 10 5 7 Questionnaire The questionnaire consists of three parts The first one is separate because questions and tasks from the second part would influence the answers The first part s purpose is to provide a place for responds to the first section of the usability test where participant has no knowledge about the application details in section 10 5 2 116 The second part utilizes a five point rating scale with appropriate labels and will be used for evaluating tasks see table 10 1 The participants will circle the appropriate number on the scale as well as write any comments they may have in the comments section The third part utilizes System Usability Scale see section 10 3 Questionnaire part 1 What is the intended purpose of the application 117 Questionnaire part 2 Tasks question Very difficult Very easy 1 Identify the office owner and his contact information O L1 O O o 2 Read office owner s s
183. upport to propagate changes made to the model e controller Only contains ButtonListener which will detect if the user is pressing buttons on the screen and take proper action 51 e view Contains all the views we will be using The nformation View wil be the default view and will display information about the owner of the office Recording View is used when you record e connector This package handles all connections SkypeConnector takes care of all communication with skype and the DatabaseConnector gives us access to the database containing name title picture etc Communication view description A few communication diagram were made to show how the system responds to certain events initiated by the user or the system Information View 3 1 hideO user presses video button ButtonListener 2 startVideoView Q 4 placeCallQ Figure 5 2 Communication diagram Video conference The first communication diagram figure 5 2 shows what happens when the user presses the video conference button 1 User interacts with the device by pressing the video conf button 2 The ButtonListener receives the button event and invoking start VideoView in the Main class 3 When this method is called the Main class hides the current view and shows the Video View 4 Video View then tires to start a video conference by invoking placeCall in SkypeConnec tor 5 When the conference is over the Video View inv
184. ure used Then follows a description of the tasks that the test subjects who are playing the role of the office owner will be given Our roles during these tests along with the usability metrics and success criteria will be described summing up the chapter This section also includes a questionnaire specifically designed for the office owner that the test subjects will fill out 108 10 1 Goals The desired result of our implementation is a working prototype We will not be executing another sprint modifying the application based on the results of this usability test therefore the main goal of our usability testing is to assess the product and find out whether or not it is valuable for both visitors and the office owner The execution of the usability scenario and its evaluation will show us the limitations of the product and reveal potential future work and development 10 2 Approach The usability of the DoorSign can be observed from two different perspectives e The visitors perspective e The office owners perspective The most important factor to test during our usability study from our visitor s perspective is the immediate understanding of the functionality and features the application and to be able to use it without any assistance For the owner of the office it is important to have an integrated easy to use solution that enables communication with visitors The usability study is divided into two parts each reflecting one of
185. ustomer meeting template e Weekly report template Templates are stated in appendix B 2 7 2 Standards Dropbox e Files should be named only in English and the name should represent the content e File names should be all in lower case and contain only letters and numbers They should have underscores instead of spaces e Files should be structured in folders to make navigation easier Coding convention Since most of the group will be involved in implementation and might have individual coding style it is write to follow more general style e Classes methods variables etc should be named using only English words e JavaDOC should be used to describe methods classes and variables The description should include what the method is used for with a brief explanation on how it is used if necessary e Since we will all be using Eclipse our code should be formatted before committing using source 13 e Correct all errors before committing the code Quotation standards We used BIBTpXfor quotations BIBTpXis a tool for generating bibliography in the IXTEX en vironment 2 8 Software for cooperation and planning Because of our group members disagreeing schedules it was essential to set up good working and accessible remote communication lines and ways to share documents in an accessible format BTEX We chose to use PITFXbecause it allowed us to concentrate more on the content of the document rather than its looks That
186. vide them with information on how we are progressing and what could potentially cause problems in the immediate future That way if any issues arise the customer will be aware of them and we will be able to find solutions without having wasted too much time This will also allow the customer to steer the project in a more preferable direction giving them a sense of control and involvement in the whole process The advisor We will have weekly meetings with our advisor where we can discuss our progress and the project in general The advisor will be able to give us important feedback so maintaining communication with him will be very useful for our project With valuable feedback our advisor is making sure our report is as good as possible and that we are progressing nicely We have the option to send him e mails if there are things we would like to ask or discuss The communication is otherwise limited to the weekly meetings By creating weekly reports for him we are able to steer the conversation in any direction of our choice It is therefore important that we create good agendas before each meeting so that we can get as much feedback as possible as this will be necessary for the overall quality of our project Having an advisor contact is helpful because the advisor will have a specific team member to contact There will be little to no confusion This person will then relay the message to the other team members 6 1 2 Internal communica
187. w calendar Visitor The visitor selects the calendar option in the information view To see when the owner of the office is avail able and or unavailable today The Visitor must interact with the door sign An overview of the workday of the owner 1 The Visitor views to calendar 2 Views to actual timeslots with empha sized colors indecating the availibility As a Visitor I want to be able to view the owner s current workday displaying when he is available in a meeting working and simi lar Table 4 8 View calendar 43 4 2 Requirements In this section the functional and non functional requirements will be presented with additional information regarding priorities complexity and more Both the functional and non functional requirements are described in a list and each list contains the following four columns Requirement No A short and unique notation describing what requirement we are dis cussing Description A description of the functional requirement stating the most important aspects regarding the functionality the system must fulfill Complexity By connecting one or more user stories to the requirement the project group assigned complexity points through Scrum s planning poker Priority The priority of each functionality is assigned to be low medium or high e Low This is not a vital requirement in the context of succeeding the project goals rather an option e Medium An important requiremen

Interactive Door Sign - Department of Computer and Information

Contents

Download Pdf Manuals

Related Search

Related Contents