Having looked at the current options available, the following configuration will be used to build the system:
· PHP will be used to generate XHTML pages, connect to the database and perform scripting functions
· Cascading Style Sheets (CSS) will be used for presentation and formatting of PHP generated XHTML documents
· MySQL will be used to store data pertaining to authentication credentials, document use logs and users' level of access
· Microsoft Office documents will be stored in the Windows server filesystem and only accessible by the proposed system interface, rather than directly as in the current solution. The file access/security will be maintained using NTFS permissions that are controlled using cacls/icacls.exe (within PHP files in the system)
· XAMPP and PHPMyAdmin within are used for the development environment and, if the artefact is successful, by the company in the final rolled out commercial system
John Neesham Page 18 of 102
Chapter 5 - Designing, Building and Testing the Artefact 5.1 Chapter Overview
This chapter starts with a discussion on the testing methods used and why. It is then split into three sections; these are for each iteration of the Incremental Waterfall Model discussed in 3.3 which covers the design, build and test of the artefact at each stage.
The first iteration is concerned with implementing functionality regarding system security, document access, document monitoring and also compatibility. These are high priority requirements detailed in R1-11, R18 & R19 in 2.3.3.
The second iteration is concerned with stopping staff bypassing the artefact to access documents directly, legal ramifications of data storage and users’ document monitoring, and also the
interface in terms of ‘look and feel’, navigation and familiarity. These are medium priority requirements detailed in R12 & R14-17 in 2.3.3.
The third iteration is concerned with the management team being able to manage the artefact without technical support and also browser compatibility. These are low priority requirements detailed in R13 & R14 in 2.3.3.
The Build Diary can be seen in Appendix H and details the system build process; it may be a little unpolished but records the genuine evolutionary process of building the artefact, making/rectifying mistakes, looking for solutions, changes of mind, and more.
To familiarise the reader with the working artefact, it is recommended that the artefact is installed at this stage by following the Installation Guide (detailed in Appendix I) and also reading the User Guide (detailed in Appendix J).
5.2 Testing Methods
Hambling (2007, p.14) defines Software Testing is a 'systematic exploration of a component or system with the main aim of finding or reporting defects'. If defects can be found and then rectified the software will be of a higher quality and can this can be used to evaluate the success of the artefact in meeting the client's needs.
Software testing was used in this project at three stages, listed in the Incremental Waterfall Model in chapter 3/methodology. As previously mentioned, each iteration reflects the prioritised requirements of the client; the artefact was designed and built to meet these, then tested at each iteration and finally rectified before moving on the next lower priority set of requirements.
Testing was done early and throughout as it is much cheaper to fix an identified defect at an early stage rather than fixing that same defect at a later stage (Agile Modelling 2012).
Compatibility, Unit and a method of Functional testing were employed. These different types of tests were used as they are testing for different errors, explained below.
Kaner et al. (1993, p.56) state that Compatibility Testing checks that one product works with another product and my compatibility checks were for my artefact within the existing environment. A virtualised domain that replicates the SVS IT infrastructure was used as a sandbox to develop the artefact; therefore compatibility testing was performed throughout, as the system was essentially being built in SVS's environment and any issues were apparent as the build process progressed. This also has the benefit of any user testing being performed in a familiar environment.
Unit testing is a type of White Box testing that tests programming code / modules in isolation, by the programmer, and are rectified as they occur. These units are then linked and form the
John Neesham Page 19 of 102 complete application. Examples of these in each iterative stage are discussed but not all were recorded, as Hambling states is often the case (2007, p.40).
Functional testing is a Black Box testing technique. This tests if the requirements ascertained during the requirements analysis process were implemented and working in the artefact. This usually involves testers rather than users, but in this project there is only a developer and users;
therefore this part of the testing was performed with users rather than testers. The author's experience of technical support with the client and other companies influenced the decision to test with users directly as many issues or suggestions can arise when the end user gives their perspective; therefore this leans a little toward usability testing too. Additionally, testing if the requirements are present and work correctly is a good measure of success.
Other relevant types of testing such as Regression, Load/Performance and Beta were not used due to time constraints.
5.3 Iteration 1 Design and Build 5.3.1 Replicated / Virtual Environment
A near replica of the SVS IT infrastructure was created using virtualisation. The server,
workstations, operating systems, hardware, network addressing and domain were replicated in a virtual environment using an instance of VMWare Player for each separate network node. This was done to ensure that the artefact would work fully in their environment, aided compatibility testing and would be easier to implement in the live environment if the system were to eventually be used by SVS. This satisfies R19.
5.3.2 Securing the Server
To ensure that the server itself was secure, direct access to XAMPP pages, PHPMyAdmin and the root SQL server were blocked from network access with separate usernames (un) and passwords (pw). Incoming port 80 needed to be opened on the server so that workstations could access the PHP pages, but was only opened for the 192.168.1.x/24 range. For a more detailed list of security measures, please see Appendix I.
5.3.3 Ascertaining the PC Name
Ascertaining the PC name of workstations logged on in order to track their document use PHP has a function (‘gethostbyadd’) that gets the IP address of PCs using the site. Therefore, as using a LAN, the IP address can be mapped to a PC name and the PC name is then known.
Various ways to do this mapping were investigated. The first was to have a batch file that ran an 'nbtstat -a 192.168.1.1 (server address)' command then opened the login page; this was decided against as it required local administrator rights and was deemed a security risk. Secondly Windows Management Instrumentation Command-line (WMIC) was considered but was decided against as it also required local administrator rights and the modification of Remote Procedure Call (RPC) settings. The technique chosen was to use Windows Internet Naming Service (WINS), which is already present in the form of Domain Name System (DNS) in the SVS infrastructure; as a PC joins the network then the PC name is automatically added to the Domain Controller's (DC) cache (viewable by the entering 'nbtstat -c' in the command line on the DC). Therefore the function returns a PC name, not an IP address (see Figure 5.1)
John Neesham Page 20 of 102 Figure 5.1 shows the code that checks if the client’s IP address was returned
5.3.4 Single Sign on
Users log onto the artefact using the same un/pw that allows them domain access; without this they cannot gain access to the system. This also assists with document use tracking.
In order for this to work, PHP Lightweight Directory Access protocol (LDAP) functions were required; these can only be used if the 'extension=php_ldap.dll' line in the php.ini file is uncommented (PHP 2013a).
This code allows the login page (login.php and logintest.php) to have several outcomes when a user is trying to authenticate, ranging from their details are correct but they have not been added to the system yet, to successful login where cookies for username, PC name and access level are set and form the basis of document use tracking. This satisfies part of R18.
5.3.5 The Use of Cookies
Cookies are used throughout the site. These are some of their uses:
· To set the user's access level (the value is taken from the database)
· Add/remove the presence of navigation bar tabs giving access to authorised areas
· Stop direct access to unauthorised areas (if cookies are not set or at the wrong level for the page then users are ousted to the login page or home page respectively)
· To aid with tracking 5.3.6 Database Modelling
During 4.4 & 4.5 using a MySQL DB to store information pertaining to the user, their document use, instead of arrays was discussed. As the coding stage developed it was found that this is the limit that a DB needs to be used for in this system. Using directories to store files and access them with PHP functions proved to be a more successful and streamline method to dynamically store documents, without the need for paths within a DB field pointing to the location of the files; this technique lessened the need to consult a DB each time files were accessed/modified and lessened the associated overhead.
The user information stored in the DB includes their username and access level:
· Access level 1 enables users to access the system, Your Documents and Shared Documents
· Access level 2 additionally enables users to access Restricted Documents
· Access level 3 additionally enables users to access the Management Area
The document information stored in the DB includes the current status (checked out or in), date
& time (My SQL 2013), location, user and pc.
The DB is relational and normalised to the third normal form.
The Entity Relationship Diagram (ERD) and associated scripts can be seen in Appendix K.
John Neesham Page 21 of 102 5.3.7 Accessing, Modifying and Adding Documents
Documents are stored in directories on the server, protected by NTFS, and not directly
accessible by the user but only via the system. This follows on from arguments made in chapters 1 & 4 that NTFS is a secure and viable solution but only if not accessed directly by the end user, management team or technical support staff.
Within the system each user has access to their own documents (Your Documents) and shared documents (Shared Documents). If the user has access level 2 then they also have access to sensitive documents (Restricted Documents); this is discussed further in manage users section.
Each set of documents (e.g. Your Documents, Shared Documents) is stored within a single directory in an undisclosed location on the server. Via the interface/system the user can view (PHP 2013b: Stackoverflow 2013a: Stackoverflow 2013b) then download and upload documents to this location but never know where they are downloading from (PHP 2013c); this is one of the 'indirect access' designs used for security. A single directory was used, rather than allowing users to create directories within their directory, as this has caused problems historically
(discussed in Appendix A). The NTFS permissions are set on the server and local library folders and files take on those parent permissions when moved (Yildirimoglu 2009).
When a document is downloaded (to the user's Local Library folder on the desktop that is only accessible by that user and the domain administrator) a copy is left on the server; this was done in case the document is accidentally deleted, the PC malfunctions or the Local Area Network (LAN) goes down and therefore the user can keep accessing and working on the document.
When uploaded again the local copy is deleted (using the PHP ‘unlink’ function) and original server copy is overwritten.
In addition to this, if the document is Shared or Restricted, rather than in Your Documents, a line is added to the database document table detailing on who downloaded/uploaded it, from which pc, the date and time, weather it was checked in or out and weather it was Shared or Restricted. Reasons for this are:
· Management document logging
· To ensure a document cannot be checked out again if it is downloaded already. Details of who logged it out and on which PC are listed onscreen to the user who is trying to check it out
· The only user who can return the document is the user that checked it out, from the same PC and back to the same area (e.g. Shared).
· This allows one copy of the document to be checked out (stopping the Lost Update issue).
Documents with apostrophes are not accepted as they cause issues with DB inserts; this can be rectified with the PHP ‘str_replace’ function but there are many scripts involving a document download/upload, there would be slightly different document names in the directory and in the Document DB table, and this was seen as a cleaner less problematic way of doing it.
Code has been created to catch errors relating to a different user and/or different PC uploading documents, returning a document to a different area than it was borrowed from (e.g. borrowed from Shared but returned to Restricted), incorrect management configuration of the Local Library folder (i.e. the server cannot access the Local Library folder in order to upload and unlink), apostrophes, trying to check out documents that are currently checked out and duplicate document names. Each error stops the download/upload and displays an understandable onscreen message; this assists with the robustness of the system, informing the user and document versioning.
Adding a document can be done by clicking the 'add a document to the library' button on the homepage and following the onscreen instructions.
These features ensure R1-10 are met and assist with R11 & R18.
It was felt that these measures struck a central balance between Confidentiality, Integrity and Availability in the CIA security triad (Summers and Tickner year unknown).
John Neesham Page 22 of 102 Examples include:
· Confidentiality - A users documents stored within the Your Documents area are available only for that user.
· Integrity - Only authorised users can borrow, modify and return documents; therefore the contents can only be changed by authorised users and integrity is maintained.
· Availability - a user’s own document stored within Your Documents available to that user at any one time. Shared and Restricted documents are available at any time also (if access to that area is authorised), providing they have not already been borrowed by another user.
5.3.8 Document Management
As mentioned in 5.3.7 when a document is successfully checked out/in it adds a row to the document DB table. Aside from the aforementioned reasons for this, it is also so that the management team can monitor or investigate its activity. The Manage Documents page enables the management team (access level 3) to search for documents and then view their activity (Stackoverflow 2013c); this can be the current activity, last five activities or all previous activities.
There is not an option for searching by user as this could be construed as monitoring the users activity (rather than document activity) and could be legally cumbersome (5.5.2).
Although deleting was not discussed as a requirement with the client, it was included in order to maintain system efficiency. Within the further document details page there is a delete button that will delete the document but not the logs pertaining to it; it simply adds a row with a status of deleted. Also the document cannot be deleted if the document is currently checked out; this was to stop the document being resurrected by the user checking it back in and therefore possibly confusing the log system. This fulfils R11.
5.3.9 PHP Page Map
This can be seen in Appendix L. At this stage many of the pages were empty (e.g. User
Management) and was just used to test functionality but ended up being the finished version of the map. Figure 5.3 shows the look of ‘searchrestdocs.php’ at the stage.
Figure 5.3 shows the look of ‘searchrestdocs.php’ at the stage 5.4 Iteration 1 Testing
5.4.1 Compatibility
This worked in the replicated virtualised environment (R19). However there was some
'requirement creep' after testing as the management team announced that they may be moving to Windows7 OS as support for Windows XP SP3 is being withdrawn by Microsoft. This was not part of the project requirements but was relatively quick and non-problematic to resolve by installing a Windows7 VM, changing the settings as before (Appendix I Section 3 in the User Guide) and successfully adding it to the domain. For the browser the inbuilt IE8 in 'Browser Mode: IE7' was used. There were no additional issues to the current XP workstation setup.
John Neesham Page 23 of 102 5.4.2 Unit
There were too many examples to list here of modules that issues were checked and resolved;
they are therefore included in Appendix M.
5.4.3 Functional
Users performing the tests were Management Team members Phil Lee and Vicky Smith and members of staff Julie Marron, Louise Evans and Rowena Singh. The later three were chosen simply as they were end users, in a near room and were free for an hour; this is a known as Hallway testing and is a type of usability testing.
Different tests were issued by myself to different members of staff and reflected the high level requirements. Examples include:
· Asking users to borrow a document, modify it, then return it (R3,4,6,7,9 & 10)
· Asking users to log into the system (R18)
· Asking users to create a new document and add it to the library (R2,5 & 8)
· Asking users with level 1 access to try to access level 2 documents (R1)
· Asking the management team to locate a chosen document's activities (R11) 5.4.4 Issues Identified by Tests and Rectified
· There were several issues with users feeling 'unclear' about trying to borrow, return or create a document. The users were given a quick demonstration and they could then borrow and return documents to all areas they had access to. The conclusion made was that the system was not intuitive enough to use without instruction. A User Guide (Appendix J) was created to resolve this.
· The management team queried why the activity regarding Your Documents was not logged, as it was with Shared and Restricted. They were informed that this could have legal implications, even with a login agreement message in place (5.5.2)
· Phil Lee noticed that if you knew the full path to the document, including the extension, then you could access the document directly but only if you had NTFS permissions to do so; for example by entering '\\svr\svs\svs document library\shared\doc1.txt' into the run box, the document would open up outside of the application. This was actually an error the developers part as when configuring the workstation VM, local administrator rights had been left on; once these were removed this was no longer possible and this change did not affect functionality.
· Following a successful logon a welcome message was coded to appear stating the users name, PC and access level but the Management Team wanted this to appear on all pages.
This was changed in iteration 2 to appear in the watermark on all pages.
· The Management Area was originally named the Admin Area but Vicky Smith wanted this renamed to deter curious access level 1 and 2 users. This was changed to the 'Management Area' as requested.
· There were many comments about the basic look of the system. The users were informed that this iteration's purpose was to provide functionality and little effort was
· There were many comments about the basic look of the system. The users were informed that this iteration's purpose was to provide functionality and little effort was