john neesham dissertation

Introductory Information

Abstract I Declaration II Acknowledgements III Word Count IV Table of Contents V

I

Abstract

This paper investigates the tailored solution to a voluntary organisation's problems regarding the storage, security and monitoring of their documents. The current solution entails members of staff navigating to the company's server and accessing the documents directly, using only Windows New Technology File System (NTFS) permissions for security; this has caused numerous issues including staff being able to access documents they should not be able to, staff not being able to access documents that they should be able to, staff deleting and moving documents, and the management team not being able to track document access. The project's objectives are to develop a browser based solution that allows users the correct level of access to documents within a secure system. This access is also logged so that high level users, such as the management team, can view the activity of any shared document and administer their staffs' levels of access so that document access is controlled. The system must also work with the current infrastructure, be an initially free and on-going solution, and adhere to laws pertaining to data storage. Various options are investigated including cloud storage and database storage. The final solution consists of users being able to access documents that are stored and secured using NTFS. However, the documents are only available via a browser based interface, which is implemented using a scripting language and backed by a database (which are open source and free for commercial use). Therefore there is no navigation to, and direct access of, the documents without using the system's interface. This fulfils the objectives by controlling user access and enabling the management team to both administer the system and track document use.

II

Declaration

III

Acknowledgements

I would like to thank Dr Richard Gunstone for his continual assistance and guidance throughout the project. I would also like to thanks Mrs Emily Chuang-Neesham for her unwavering support and understanding.

IV

Word Count

The word count, excluding appendices, is 12776.

V

Table of Contents

Chapter 1 - Introduction 1.1 Chapter Overview 1 1.2 The Importance of File Level Security 1 1.3 About the Client 1 1.4 The Current Infrastructure 1 1.5 Involvement with the Client 2 1.6 The Current Problem 2 1.7 Objectives 2 1.8 Proposed Solution 3 1.9 What Can Be Learned From This Project 3 1.10 Project Roadmap 3 1.11 Chapter Summary 3 Chapter 2 - Assessing Feasibility, Requirements and Risk 2.1 Chapter Overview 4 2.2 Feasibility Study 4 2.3 Requirements Analysis 4 2.3.1 Eliciting Requirements 5 2.3.2 Categorising Requirements 5 2.3.3 Requirement Reiteration and Prioritization 6 2.4 Risk Analysis 7 2.5 Chapter Summary 7 Chapter 3 - Project Planning and Methodology 3.1 Chapter Overview 8 3.2 The Need for a Methodology 8 3.3 Project Criteria 8 3.4 Chosen Methodology and Model 8 3.5 Other Similar Models 10 3.6 Project Plan 10 3.7 Chapter Summary 12 Chapter 4 - Literature and Technology Review 4.1 Chapter Overview 13 4.2 OS Filesystems 13 4.2.1 Windows NTFS Permissions 13 4.2.2 Linux FHS 13 4.3 3rd Party Tools 13 4.4 Remote Storage 14 4.5 Database Use within the System 14 4.5.1 NoSQL 14 4.5.2 OODB and RDBMS 14 4.6 Database Use for Storing Office Documents 15 4.7 Languages and Development Tools 15 4.7.1 Scripting or Programming Language 15 4.7.2 Languages Used 16 4.7.3 Development Tools 16 4.8 Chapter Summary 17

V

Chapter 5 - Designing, Building and Testing the Artefact 5.1 Chapter Overview 18 5.2 Testing Methods 18 5.3 Iteration 1 Design and Build 19 5.3.1 Replicated / Virtual Environment 19 5.3.2 Securing the Server 19 5.3.3 Ascertaining the PC Name 19 5.3.4 Single Sign-on for User Login 20 5.3.5 The Use of Cookies 20 5.3.6 Database Modelling 20 5.3.7 Accessing, Modifying and Adding Documents 21 5.3.8 Document Management 22 5.3.9 PHP Page Map 22 5.4 Iteration 1 Testing 22 5.4.1 Compatibility 22 5.4.2 Unit 23 5.4.3 Functional 23 5.4.4 Issues Identified by Tests and Rectified 23 5.5 Iteration 2 Design and Build 24 5.5.1 Document Access Using the System 24 5.5.2 Legal Implications of Monitoring User Activity 24 5.5.3 System Interface Design 24 5.5.3.1 Accessibility 26 5.5.3.2 Human Computer Interaction 26 5.6 Iteration 2 Testing 26 5.6.1 Compatibility 26 5.6.2 Unit 26 5.6.3 Functional 26 5.6.4 Issues Identified by Tests and Rectified 27 5.7 Iteration 3 Design and Build 27 5.7.1 User Management 27 5.7.2 Sign Sign-on for Management Administration 28 5.7.3 Browser Compatibility 28 5.8 Iteration 3 Testing 28 5.8.1 Compatibility 28 5.8.2 Unit 28 5.8.3 Functional 29 5.8.4 Issues Identified by Tests and Rectified 29 5.9 Chapter Summary 29 Chapter 6 - Project Evaluation 6.1 Objectives and Requirements 30 6.2 The Project Process 30 6.3 The Artefact and Other solutions 31 6.4 What Has Been Learned from the Project? 31 6.5 Future of the Artefact 31 6.5.1 Issues with the System 31 6.5.2 Developer Improvements 32 6.5.3 Client Improvements 32 6.6 Project Conclusion 33

V

Referencing and Bibliography 34 Appendices Appendix A Additional Factors That Can Affect File Access 44 Appendix B Feasibility Report 46 Appendix C Eliciting Requirements 48 Appendix D Snow Cards 49 Appendix E Risk Analysis Table 59 Appendix F Justification for the Chosen Methodology and Model 62 Appendix G Further Literature and Technology Review Investigations 63 Appendix H Artefact Build Diary 69 Appendix I Virtual Domain and SVS Document Library Installation Guide 76 Appendix J SVS Document Library User Guide for Staff and Management 78 Appendix K Entity Relationship Diagram & Database Create Scripts 88 Appendix L PHP Page Map 89 Appendix M Iteration 1 & 2 Unit Testing Examples 91 Appendix N Legal Implications of Monitoring User Activity 92 Appendix O Adherence to Accessibility Guidelines 93 Appendix P HCI for Artefact Design and Build 95 Appendix Q Project Proposal 96 Appendix R Plagiarism Report 100 Appendix S Ethics Research Check List 101

A Browser Based Application that Secures and Tracks Shared Resources for a Voluntary Organisation

John Neesham Page 1 of 102

Chapter 1 - Introduction

1.1 Chapter Overview This chapter begins with a discussion of the importance of file level security within businesses. Then details of the clients business and their current IT infrastructure are used to give context to the problem. The problem itself is then discussed with a dissection of the current solution and the issues that this is causing the business and why. The clients overarching objectives for a solution are listed and a brief view of how these will be resolved in the proposed solution. Furthermore we discuss what can be learned by all parties throughout the process of this project. Finally, there is a roadmap that briefly points to contents and aims of each forthcoming chapter.

1.2 The Importance of File Level Security File level security on a corporate Local Area Network (LAN) can sometimes be given a lower priority by companies in comparison to other types of IT security, for example network access or website security. This may be because there are solutions for this built into most Operating Systems (OS) such as Windows' New Technology File System (NTFS) or Linux's Filesystem Hierarchy Standard (FHS), or because companies are not aware of the current implications (legal, ethical or otherwise) of incorrectly configured file security. Often it is done using LAN security such as Virtual LANs (VLANS) or different resources are kept on different servers. Sometimes companies are not even aware that there is a security issue/breach. Whatever the reason, inefficient file level security can cost a business time, money, damage to reputation or even legal issues. With this project the author hopes to highlight the issues that can be caused by reliance on and erroneous configuration of using only an OSs inbuilt file level security system. The result of this project will be a piece of software that secures documents, simplifies the security process and tracks their use. 1.3 About the Client The client is Southampton Voluntary Services (SVS) based in Southampton, Hampshire. They are an umbrella body for local voluntary and community groups working in Southampton and provide a wide range of services including specialist support, advice and training to their membership (Southampton Voluntary Services 2013). SVS also provide and promote information to individuals and organisations on volunteering in the city. They have 50 employees or volunteers in their charge and work across two sites; some are permanent whilst others are temporary. The charity/volunteering sector which they are part of does not have recognised bespoke software as is apparent in other industries. Instead they utilise more mainstream software but are eligible for discounted licenses (Charity Express Ware 2013). The company that are currently SVS's contracted technical support are called Healthcare Computing Limited (HCL). They can resolve IT issues relating to daily operational needs but other work to resolve an on-going issue would be outside the bounds of the contract and therefore chargeable. Therefore HCL will modify NTFS folder and file permissions as and when required for daily document use, but will not review the overall folder hierarchy or create bespoke software to alleviate on-going issues. 1.4 The Current Infrastructure As the aforementioned discounted licenses allow use of mainstream software but at less cost, SVS have maximised their use of this and applied it to all solutions. They use Windows Server



2008 Standard R2 (SP1) as the OS on their single server, Windows XP (SP3) as the OS on their 40 workstations, and Microsoft Office (2003) for their email, text, presentation and spread sheet document solutions. This extends to their current solution for file level security which is Windows NTFS permissions. Therefore any solution to a problem would need to fit in with the current infrastructure and also be initially and permanently Free Of Charge (FOC). 1.5 Involvement With The client The author worked as Service Desk Engineer within the Technical Support department of Healthcare Computing Limited (HCL) for five years. Throughout this time SVS were a client of HCL and therefore the author is familiar with their IT infrastructure, staff and management team. The author is also aware of reoccurring issues that SVS have, which is what led to the idea for this project; a more permanent solution rather than repeated short-term successful solutions. 1.6 The Current Problem As previously stated, the current solution uses NTFS permissions to secure documents. These documents are categorised as personal (e.g. created by a user and only for their use), shared for all (e.g. word document templates and company logo headed paper) or restricted to a specific set of users (e.g. private information pertaining to clients' Criminal Records Bureau (CRB) checks or company records including financial information). Members of staff have two mapped drives on their desktops that link directly to the file shares on the local server. One (mapped as H) links to each member of staffs personal documents folder, whilst the second (mapped as G) links to the shared and restricted folder areas; the permitted level of access from Deny to Full Control depends on the user and is set by the management team. Staff can use these mapped drives or navigate to the server then through the folder hierarchy to their chosen file. This may seem like a viable file security solution for a company of this size if correctly implemented. However, problems are manifesting themselves in the following ways:

Staff are able to access/modify/move/delete files that they should not be able to Staff are not being able to access/modify/move/delete files that they should be able to Staff are able to modify NTFS permissions of shared and restricted documents The management team are not being able to track file

access/modification/movement/deletion or NTFS permission changes to see when the changes were made and by who

From experience of technical support with SVS, discussions with the management team and research into file security in a Windows domain environment, many reasons have been ascertained as to why this is happening. NTFS permissions alone are complex but combined with other factors that can affect file access they can be even more so. Please see Appendix A for a list of additional factors that can affect file access for SVS. The SVS management team, staff and HCL technical support are not always aware of the pitfalls when trying to rectify document access problems by modifying NTFS permissions and have previously inadvertently caused further issues when trying to resolve only one. 1.7 Objectives Following is a list of high level requirements, otherwise known as objectives:

The system shall provide secure document storage The system needs to work within the current SVS IT infrastructure and be FOC Staff will use a browser based interface to access documents that they are authorized to

by the management team.



The interface will be simple and intuitive to use, with a familiar layout and include company branding

Staff will not be able to bypass the system and access documents directly Document access will be logged and can be viewed by the management team in a secure

area The management team will be able to manage staff authentication to the system, without

the need to contact technical support Documents storage will be legally compliant

Within the requirements analysis section each objective has been broken down into interlinking requirements. 1.8 Proposed Solution The proposed solution takes into account the context of the business, problems of the current solution, broad objectives and specific requirements. The solution is a system with a browser based interface, backed by a database. Users will be able to create, access and modify their authorized personal, shared or restricted documents. The management team will be able access a secured area that allows them to reset users' passwords and view logs of document activity. The system will provide SVS with an initial and on-going FOC solution to their secure document access issue. 1.9 What Can Be Learned From This Project The author will gain a deeper understanding of the interactions between PHP, MySQL, Windows file security and command line applications such as icalcs.exe in a domain environment as well as gaining further knowledge and understanding of them individually. The author will also learn about working on a solution within an environment with non-permeable constraints such as delivering a system that works within the current infrastructure, is delivered FOC using FOC development software, within a tight schedule, fulfilling specific requirements and is directly answerable to the company's Deputy Chief Executive. SVS may learn about the legal aspects of data storage, specifically laws relating to data protection. They may also become aware of current unknown security lapses. Additionally they could learn what is capable FOC in their current environment as a by-product of our meetings and user tests. 1.10 Roadmap Chapter 1 has fully defined the problem within the context of the business, listed the projects objectives, given a brief overview of the proposed solution and detailed what could be learned from the project. Chapters 2 & 3 investigate the artefacts requirements in detail and plan the project process. Chapter 4 reviews relevant work in other areas and details methods and tools used to design the solution. Chapter 5 details the construction of the artefact that solves the problem. Chapter 6 evaluates the solution and success of the project overall by comparing it to other relevant work and the against the success criteria; then possible future work is suggested. 1.11 Chapter Summary Now that the importance of file level security is known, the affect that it is having on SVS, their objectives for a solution and a brief overview of the proposed solution, we can start to plan, research, design, build and implement that solution.



Chapter 2 - Assessing Feasibility, Requirements and Risk 2.1 Chapter Overview This chapter has three sections; the Feasibility Study & Report, Requirements Analysis and Risk Analysis. The Feasibility Study produces a Feasibility Report. This is presented to the decision makers (SVS management team) at this early stage in order for them to decide whether to proceed with the project or not. The purpose of the Requirements Analysis process is to determine and document stakeholders' needs and expectations for a new system in a formal manner. Risks are problems that might occur in the project; this can be managed proactively using Risk Analysis in order to lessen the likelihood of project failure. Therefore by the end of the chapter it is known if the project is going ahead, the requirements of the artefact are known and documented and a contingency plan concerning risks is formulated and documented. 2.2 Feasibility Study Feasibility studies were carried out prior to the system development process in order to find out if the new system is worth implementing. They took into consideration factors that include budget, schedule, integration with the existing system and weather the proposed system met the required objectives at that stage. Sommerville (2011, p.37) states that Feasibility Studies should be quick and cheap and the results gained are documented as a Feasibility Report and used by decision makers as to whether to go ahead or not. Information can be obtained from various sources including managers and end users, and also by various methods including structured or unstructured interviews and observation of work patterns. To obtain the information required unstructured interviews and also observed work patterns were used; the interviewees (sources) were SVS employees Phil Lee (Deputy Chief Executive), Vicky Smith (Senior Administrator) and Auran Sood (End User). Bryce's (2013) Elements of a Good Feasibility Study was followed to construct the Feasibility Report in Appendix B. As this was done at an early stage, more detailed information and analysis in areas such as requirements analysis, analysis of current solution and alternative solutions and can be found in sections 2.3, 1.6 and 3 respectively. As a by-product and a pre-cursor to Chapter 3, it was discovered that many Agile methodologies state that this report is a waste of time (Bryce, 2013), therefore by including it the project may be leaning toward a Plan Driven methodology at this time. 2.3 Requirements Analysis The requirements analysis / engineering process was performed after the decision maker has allowed the project to proceed following the Feasibility Report, but before a methodology has been decided or any prototyping. The process benefits all parties in the following ways:

It is an early opportunity for two way communication and the client knows that the developer is listening to them so are more inclined to feel included in the process

The resulting documentation can be used and referred to by all parties, can protect against miscommunication and records the details and source of each requirement request (IEEE Computer Society 1998)

The developer can understand more about the SVS domain, where the system will be implemented



The developer can talk to different sources within SVS to get more perspectives on the system's requirements

Additionally, from a financial view the importance is stressed by 8-15% of company budget for the project being taken by requirements analysis. Also, the cost of correcting requirements errors later on in the project is 100 times more than a simple error at the same stage (Kotonya and Sommerville 1998). Initially the author interacted with the identified stakeholders and the requirements were elicited. Secondly the requirements were categorised and formally documented, then finally they were reiterated with the client for clarity and prioritization. This three part process is discussed in more detail in the following three sections. 2.3.1 Eliciting Requirements Gathering requirements was the first step in the requirements analysis process and, as requirements form the basis of the system, was done with consideration. This process, including the methods discussed and used, can be seen in Appendix C Eliciting Requirements. 2.3.2 Categorising Requirements Once the requirements are gathered they were then categorised as either Functional Requirements (FR) or Non-Functional Requirements (NFR). FRs captures the behaviour, capabilities and functions that the system must be able to perform. These can be high level or detailed and must be understood by all parties. NFRs capture the specific, precise and quantifiable constraints and qualities of a system. Examples could be availability, portability, scalability of a system or concerning its interface and design. Kotonya and Sommerville (1998) use a tree model to sub-categorise NFRs into product, organisational and external, and then further subcategorise these again for a total of 14 NFR categories. This method was not chosen as it is very wordy and a requirement would need to be categorised (FR or NFR), sub-categorised (product, organisational, external) then sub-categorised again (performance, space, accounting, etc...). It was decided that Atomic Requirements Shell (AKA "Snow Card") within the Volere Requirements Specification (Robertson and Robertson 2000) would be used. This uses a single card for each unique requirement. Each requirement is classified into FR or NFR and NFRs are sub-categorised further using an easily identifiable acronym such as LFR for Look and Feel Requirement. Robertson and Robertson (2006, p.242) states that each snow card also allows for individual requirements (Requirement Number field) to be documented (Description field), measurable/quantifiable (Fit Criterion field), linked to other associated requirements (Dependencies field), explain the rationale behind the requirements (Rationale field), trace who initiated the requirement (Originator field) and prioritize the requirement (Customer Satisfaction, Customer Dissatisfaction and Priority fields). The completed Snow Cards can be seen in Appendix D. This also enabled complex requirements such as 'Staff will be able to create, access and modify their own documents' to be decomposed into several more simple ones such as 'Staff will be able to create their own documents' that can be implemented individually.



There were other fields that were omitted due to them being unsuitable for the project. These include Business Event Number, conflicts (there were no conflicting requirements) and supporting materials. Additionally the whole Volere Requirements Specification Template was not used as was not in-keeping with the Agile methodology side of the project plan; there was no need for this heavy documentation prior to coding, as used with purely Plan-driven methodologies. This approach fulfils most criteria listed in IEEE Standard 1233 (1998, p.13) as it states that requirements should be categorized by their identification, priority, criticality, feasibility, risk, source, and type. Identification, priority, criticality and source are covered by the Volere method, whilst feasibility is covered 2.2 and risk in 2.4. Some the types listed such as Safety, Environmental conditions and transportability were not relevant to the system so FR and NFR sub categories within the Volere method were chosen. The Volere method also fulfilled the IEEE Standard 1233 definition of a well formed document (1998, p.10) as each snow card contains a function within the system that will solve the related client requirement and can be tested. 2.3.3 Requirement Reiteration and Prioritization MoSCoW methodology was initially considered as a means of prioritizing already categorized requirements. It was originally used in Rapid Application Development and is now used in DSDM and other agile methodologies (Coley 2012). The prioritization is done under the Must have, Should have, Could have and Won't have headings. However, MoSCoW was not used as Volere requirements shell has inbuilt numerical prioritization of requirements, ascertained by the customer satisfaction and dissatisfaction fields, that was considered to be more precise. Once the Snow Cards were written up they were discussed again with the SVS management team. The requirements were found to not be in need of adjustment but the prioritization was not clearly stated. SVS were therefore asked to given numeric values to the Customer Satisfaction and Customer Dissatisfaction fields and this was used to calculate a high, medium and low value to the Priority field. These values will be used to implement the requirements at each evolutionary system prototype respectively (i.e. iteration 1 implemented high priority requirements, iteration 2 implemented medium priority requirements and iteration 3 implemented low priority requirements). These results are summarised below. High priority:

R1 The system will provide secure document storage R2,3,4 The system will allow staff to create, read/access/update their own documents R5,6,7 Staff will be able to create/read/update documents that are shared with all

members of staff R8,9,10 Authorized staff will be able to create/read/update restricted documents that

can be accessed by other authorized users only R11 Document access will be logged and can be accessed by the management team (Phil

Lee & Victoria Smith) only R18 System access and level of access will be protected using a unique username and

password for each user R19 The system must work on the platforms within the current infrastructure



Medium priority: R12 Staff will not be able to bypass the system and access documents directly R14 The system needs to be legally compliant regarding data laws R15 The system must use company branding and colour scheme R16 The system will use a familiar interface with a common layout R17 The navigation system will be simple and intuitive to use

Low priority:

R13 The management team will be able to manage system access authentication without the need to contact technical support

R20 The system must work across different versions of Internet Explorer (IE) 2.4 Risk Analysis Schwalbe defines Project Risks as 'problems that might occur on the project and how they might impede project success' (2002, p.425). The management of these risks are done in a proactive way and as a type of contingency planning. Lock argues that Risk Analysis is important because, if not done, can potentially cause effects on the project ranging from trivial inconvenience to disaster (2003, p.573). The process is to identify the risk, quantify the risk, develop a mitigation strategy, and then finally reassess the risk. Schmidt (2001) agrees that risk identification is the first step in the process, but argues that this is difficult due to no formal and validated list of common risk factors; therefore he created one called the Risk Factor List. This list was used to identify risks in this project. Each Risk Event was uniquely identified (e.g. Risk07) and listed. Each risk event is given a rank of low, medium or high for both its likelihood to happen and the potential harm this could do to the project. The risk rating, before any mitigation strategy is developed, is calculated by using the two aforementioned values with a probability/impact matrix (Burke 2006, p.261; Schwalbe 2002, p.439). The resulting pre-mitigation rating value was also used to prioritize the risk events. A mitigation strategy is then developed to decrease the likelihood of the risk occurring and the harm to the project if it does. The pre-mitigation rating is then reassessed using the now developed mitigation strategy. This creates a post-mitigation low, medium or high value. The Risk Analysis Table is used to list the preceding points in a concise orderly manner. This project's table is a modification of Burke's (2006, p262) Work Breakdown Structure (WBS) table. It includes the risk id, risk event, likelihood, and potential harm to project, pre-mitigation rating, mitigation and post mitigation rating. Please view the complete table in Appendix E. The table can be reviewed periodically and risk events reprioritised if deemed necessary. 2.4 Chapter Summary The Feasibility Report was presented to the decision makers who decided that the project should go ahead. The requirements were gathered, clarified, prioritized, and then finally documented; these will act as a list of all features of the artefact and a measure of project success. The project risks were identified and a mitigation strategy applied to each as a form of contingency planning. Therefore the project planning could the go ahead.



Chapter 3 - Project Planning and Methodology 3.1 Chapter Overview This chapter initially discusses the need for a methodology, then followed by the chosen Methodology and Model (based on the project criteria), the justification for this choice and a discussion of other similar models. With this decided it can be included in a project plan that will show the planned order of work as milestones that can be used to measure project progress. 3.2 The Need for a Methodology Avison and Fitzgerald define a methodology as:

a collection of procedures, techniques, tools, and documentation aids which will help the systems developers in their efforts to implement a new information system...and help them plan, manage, control, and evaluate information systems projects (2006, p.24).

Sommerville argues that without a methodology's fundamental process activities of specification, development, validation and evolution (2011, p.29) a project can be over budget, not be on schedule, not thoroughly tested and/or not meet the stakeholders' requirements. Aken (2008) also argues the incorrect choice or application of a methodology is a factor in project failure. Therefore the use, choice and application of a methodology are critical to the project. 3.3 Project Criteria When developing the project solution the methodology was chosen based on the following project criteria rather than requirements:

1. Set time to finish (cut-off date) with measurable progress (milestones) 2. SVS were willing to work with me in order to produce the required system but were

difficult to meet up with as too busy 3. No mock-ups were available in the meeting with SVS so they wanted to see

something early on 4. All requirements were collected prior to starting 5. SVS were not concerned with documentation, just intuitive use 6. Software is security critical so the artefact needed to be iteratively tested before the

final version 3.4 Chosen Methodology and Model Methodologies are categorised as either Plan-Driven (e.g. Software Development Life Cycle (SDLC)/Waterfall, Cleanroom) or Agile (e.g. XP, Scrum, Agile Unified Process), but some have attempted to develop a hybrid such as Boehm's Spiral development model. The project criteria leans toward both Plan-Driven and Agile methodologies; for example the lack of concern with documentation and request for an early prototype point toward an Agile methodology being adopted, but a set cut-off date and awareness of all requirements at outset lean more toward Plan-Driven. With this in mind the methodology chosen was the Plan-Driven Traditional Waterfall but with modifications that enable the Agile concepts such of early prototyping, no need for thorough upfront documentation and also iterative design, building and testing. The model is called the Incremental Waterfall Model and can be seen in Figure 3.1.



Figure 3.1 The Incremental Waterfall Model The requirements were gathered and prioritized (2.3), and then the model uses these to design, build and test the artefact a follows:



High requirements are separated off and these are used to design the first prototype. This

is built and then presented/tested with the client. They give feedback and this feedback is added to the medium priority requirements

The next iteration process starts. This builds on the existing prototype by incrementally adding functionality based on the first prototype feedback and medium requirements (this is evolutionary prototyping, not throwaway prototyping). This second iteration of the software is then tested with the client

The cycle is repeated for the final time by starting with the second prototype feedback and low priority requirements, then final testing

The deployment and integration into SVS infrastructure is done, if SVS state that they want to implement the artefact at this stage

The full justification for the chosen methodology and model can be seen in Appendix F. 3.5 Other Similar Models There are similar models to this in existence but each is slightly different and often has different names such as Incremental Model (Sikder 2009; Expert Program Management 2011), Incremental SDLC Model (Berra year unknown; Root Infocomm LTD 2011) or Phased Development Model (Masud year unknown). There are also other iterative models used to address the shortcomings of the traditional Waterfall model such as the Spiral model and Rapid Application Development (RAD) model; however the fundamental difference between those and the Incremental Waterfall Model is that they have an unlimited number of iterations from 1->N, whilst the Incremental Waterfall Model is fixed at three. In addition to this the Avison and Fitzgerald argue that the Spiral model is difficult to manage and control and is better for larger projects (2006, p.122) so was not used, whilst the RAD, like models that incorporate Agile techniques, are used for programming teams (Konstantinou year unkown). 3.6 Project Plan The project must also have an overall plan from start to completion, which includes the artefact design, built and test process stated above within. Figure 3.2 shows the project schedule expressed as a timeline of all project activities that must be completed. These act as milestones to check progress against also. Some, such as Meetings with Client and Requirements Analysis Section, have already been completed. Those marked in orange show the parts of the plan that are specific to the artefacts design, build and test process. As stated in the penultimate milestone, each section or milestone will be written up at the time and collated toward the end of the project process.



Figure 3.2 The project schedule, expressed as a timeline



3.7 Chapter Summary The projects Methodology and Model have been established, and the overall schedule documented. These will guide the processes of both the overall project and the artefact itself, and the schedules milestones can be used to measure progress.



Chapter 4 - Literature and Technology Review 4. 1 Chapter Overview This chapter analyses current relevant solutions, techniques and technologies that could be imported to the solution to resolve the problem (1.6). As the current solutions were analysed they were either dismissed or some parts are considered, and this progressively aided the design of the solution. Solutions analysed include inbuilt filesystem security, third party tools, remote storage, databases (Object Oriented, NoSQL and Relational), Binary Large Objects, scripting/programming languages and development tools. The research and investigations were thorough and therefore generated a large amount of information and analysis. Therefore sections that were not imported in any way into the solution were moved to the appendices; this is noted at various points throughout the chapter. 4.2 OS File Systems Within OSs there are inbuilt filesystems that if used correctly can securely store files, including office documents. Two common server OSs filesystems are Windows' NTFS and Linux's Filesystem Hierarchical Standard (FHS). 4.2.1 Windows NTFS Permissions Windows NTFS permissions, if configured correctly, ensure that only authorised users can access documents and only to the correct level. These are built in to the Windows OS from Windows NT (both server and client) onwards. Advantages of using NTFS for securing SVS's office documents are that it can achieve complex, fine grained and robust file access security at folder and file level (Wang 2012), it affects users regardless of the PC where they have logged in and making changes to the upper levels of the hierarchy can cascade down (be inherited) therefore lessening administration. Additionally, SVS already have the infrastructure in place and are familiar with its use. This fulfils the requirements of being FOC and having a familiar and easy to navigation interface. The disadvantages are their complexity and what factors can have an effect (see Appendix A), their decentralised nature and only having a date created and last modified for tracking. In addition to this is the unarguable point that this is the current solution and has proven to be unsuccessful, hence the need for this project. For these reasons a simple re-do of the NTFS permissions will not be performed as history has proven that there will be forthcoming problems pertaining to this. However, the problems only arise as NTFS permissions are misunderstood and users are accessing and modifying them directly. If the permissions were configured at outset and access was indirect, for example via an interface, then the robust security that they offer could be utilised. 4.2.2 Linux FHS Linux FHS was investigated but was not imported as part of the solution. The investigation can be seen in Appendix G Section 1. 4.3 3rd Party Tools Various 3rd party tools were investigated but were not imported as part of the solution. The investigation can be seen in Appendix G Section 2.



4.4 Remote Storage This section encompasses solutions that store documents remotely. This includes a Secure File Transfer Protocol (SFTP) solution and Cloud solutions such as Microsoft Office 365, WebDAV and PERMIS. However, after investigating each subject in turn, none were imported as part of the solution. The investigation of these can be seen in Appendix G Section 3. 4.5 Database Use within the System Databases can be used in the system, but will only be part of the solution. They are not accessed directly and are used in conjunction with a user interface, enabling user interaction such as logging onto the system. Information such as authentication credentials (username/password), document use logs and a user's level of access need to be stored; storing such information in an array is possible but a database is ideal due to its robust and dynamic nature. Many types of database exist including NoSQL, Object Oriented (OODBMS) and Relational (RDBMS). 4.5.1 NoSQL NoSQL, created in 1998, is an acronym for Not Only SQL and co-exists with SQL for mass data storage. It scales out to interconnect large data sources such as those used in social media sites. There are many variants of NoSQL including Amazon's Dynamo, Facebook's Cassandra (open source), CouchDB (open source) and Google's BigTable (Perdue 2013). The advantages of NoSQL are that it has quick performance on mass data, is easy to expand (Jing et al. 2011) and already has cloud solutions (Burtica et al. 2012). Disadvantages are that is does not support SQL (Jing et al. 2011), the aforementioned variants all use different querying mechanisms (Perdue 2013) and it does not conform to ACID (Atomic, Consistent, Isolated, Durable) (Tudorica and Bucur 2011). It will not be used in the system as it was designed for Big Data and not for our smaller scale needs, is still in its early stages and may not be open source depending on variant chosen. Additionally, cloud solutions have previously been discussed and dismissed. 4.5.2 OODB and RDBMS OODBMS offer a tight coupling of programming languages with database systems and Batory (Prabhakaran et al. 1990) argues are the future of databases. As there is no clear separating line (as there is with a language connecting to a database) the benefits that are inherent to OOP languages are available to OODBMS such as encapsulation, code reuse and also generalisation/specialisation/inheritance, overriding/overloading/polymorphism; this can allow for increased security and less code required (Atkinson et al. 1989). Advantages include data models are based on real world objects, new objects are easily added (compared to adding a RDBMS entity which could require an ERD redesign) and OODBMS's can be quicker as only one language is used throughout; this also stops disparity between object structure and table structure (impedance mismatch) (2004, p.844). Additionally there is an open source OO database engine that can be used in Java and .NET (Db4objects 2013).



There are many stand-alone disadvantages to using an OODBMS and some from comparisons to RDBMS. RDBMS have been used since the 1970's and as such are widespread, stable and more supported. OODBMS are comparatively new (1980s) and have less standardisation, even with the querying language Object Query Language (OQL) that Connolly and Begg state is the most predominant (2010, p.897). Connolloy and Begg also argue that RDBMSs are less complex to use and implement, and work quickly on smaller datasets (2010, p.852). OODBMS is overly complicated for a database of this size and a system of this scope. OODBMS's have known security flaws whilst RDBMS has been used long enough to have been secured. As mentioned above there is an open source software for OODBMS but RDBMSs have many including 'Oracle SQL 11g lite'. In addition to this a further reason for not using OODBMS is the authors knowledge gap on the important development procedure of UML design, OODBMS normalisation which is different to RDBMS normalisation (Lee 1995), the OO querying language QQL and not enough detailed use of OOP languages; the author has a previous learning, understanding and use of UML and Java but not enough to fulfil the requirements needed. This may appear to be using a database system that is convenient to the author but if the author took the required time to study UML, OODB normalisation, QQL and OOP to the level required then there is a very real possibility that the finished software could be over schedule and not fulfil functionality and security requirements. A RDBMS will be used as it is stable, supported, uses standard SQL dialects, is less complex, simpler to implement, secure and within the author's ascertainable skill range within the permitted time. These will assist with completing the system on time with requirements fulfilled. 4.6 Database Use for Storing Office Documents In relation to storage of the Microsoft Office documents themselves using a DB there were two options discussed, but neither was imported as part of the solution. These are discussed in Appendix G Section 4. Taking this and previous findings into account, the system at this stage will store information pertaining to users, document use logs and user's level of document access and more in a RDBMS, but Office Documents themselves within the filesystem, possibly using NTFS permissions. 4.7 Languages and Tools 4.7.1 Scripting or Programming Language A programming or scripting language is required to create a user interface, connect to the database and access Microsoft Office documents that are stored in the filesystem (so documents cannot be accessed by end users directly). Scripting language such as Ruby, Perl and PHP use interpreters to translate source code as they go, whilst programming languages such as C, C++ and Java use compilers to translate source code into binary that is understood by the CPU. Scripting and programming languages can be used separately or together and Ousterhout argues in his 1998, but still relevant paper, which one(s) chosen should depend on the application in hand. If the application is broad, has a GUI and evolving functions then a scripting language is



best, but if complex algorithms, large datasets and well defined functions are required then a programming language is best. Advantages specific to this project of scripting over programming languages include quicker build speed due to less lines of code required for the same result (Loui 2008), easier debugging, ties with RAD (used within the Incremental Waterfall model), have better choices to build GUI applications (Perl has 139 colours whilst Java has 13) and there is no client side software required which uses the existing infrastructure. The advancement in hardware technology has led to scripting languages no longer being a performance concern, again using SVS's current infrastructure without a hardware increase. The Java client software can also be deleted or updated which can affect functionality. Even though Object Oriented Programming has benefits such as code reuse and inheritance for cutting down time, taking into account the advantages to the project previously listed, a scripting language will be used. 4.7.2 Languages Used For the scripting language PHP Hypertext Pre-processor (PHP) was chosen as it was open source, contains library functions that connect to the database, can be used to create the XHTML user interface and also contains functions that aid file retrieval and NTFS permission changes. It is a server side scripting language and therefore cannot be turned off (as for example JavaScript can) and can be made more secure by tweaking settings such as turning off 'register_globals'. Sensitive data, for example passwords, can be encrypted using one of PHP's hashing functions such as MD5. The library of functions can be used to reduce Lines Of Code (LOC) and as code re-use; both save time and input. MySQL was chosen as it works well with PHP in dynamic websites and a development environment (Xiaosheng 2010) and is also open source. 4.7.3 Development Tools Different packages can facilitate the required software development environment including WAMP and XAMPP. XAMPP was chosen as it includes Apache Server, as PHP is a server side scripting language, and MySQL in one package. It also includes the PHPMyAdmin interface that provides a developer friendly GUI. Cacls/icacls.exe is a Windows command line utility that can modify NTFS permissions. Also, Windows command line commands can be run within PHP. Therefore NTFS permissions can be modified using PHP (using cacls/icacls.exe, within the command line, within PHP). This takes away the manual elements where users have navigated directly to documents with only Windows authentication for security. The system enables a second layer of authentication and more importantly to SVS there is now traceability/culpability. Also, direct access and therefore end user control is lessened. NTFS will still partially be used for security but permissions will be set at outset and as documents are not accessed directly, cannot be changed by end users.



4.8 Chapter Summary 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



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



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)



Figure 5.1 shows the code that checks if the clients 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.



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).



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 users 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.



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 made for display, but that would be one of the focuses of iteration 2.



5.5 Iteration 2 Design and Build 5.5.1 Document Access Using the System The documents are stored within directories on the server. The directories are protected using NTFS permissions and the documents within take on the permissions of these parent folders. The only way to access the documents is via the system, which cannot be bypassed so there is no direct access to the documents (R12). Users do not have rights to browse to the server shared folders, and in the case of rights being accidentally given there are two high level directories ('SVS' and 'SVS Document Library') that are used to block navigation to the lower level User, Shared and Restricted directories; therefore you cannot navigate to documents either. Direct access to the document library system is blocked by un/pw for XAMPP, SQL DB and the server itself (detailed further in Appendix I). The management team (level 3 users) also cannot directly modify NTFS permissions and need to do this via the interface (discussed further in 5.5.3). 5.5.2 Legal Implications of Monitoring User Activity Details on the legal implications of SVS using the artefact and the steps taken to safeguard them are discussed in Appendix N. 5.5.3 System Interface Design Rather than creating an interface design from scratch, a template was chosen and merged with the functional code detailed in 5.3, as this seemed a more efficient use of time. The template was selected from Open Source Web Design (OSWD) (WebTom 2013) and can be seen prior to integration with my system in Figure 5.4.

Figure 5.4 Shows original template, prior to integration with the system



It was chosen as there were parts that fit the systems needs (e.g. watermark, header, navigation bar, footer) and unwanted other parts that could easily be removed (e.g. sidebar menu and text advertisements area). The template code was then streamlined by removing unrequired HTML and excess CSS. The header logo was added and colours changed to fulfil the company's requirement to use their logo, branding and colour scheme (R15). These were ascertained by investigating the company's existing website (http://www.southamptonvs.org.uk/), which can be seen in Figure 5.5. This will also assist with R16.

Figure 5.5 Shows the SVS website with colour scheme and company branding Following this, recoding, tables, buttons, scrollbars (quackit.com 2013), commenting, indenting, general tidying and XHTML validation (W3C 2012) was done for each page within the system. Although this is browser based, rather than web based, the author still considered XHTML validation beneficial as it produces neater, more uniform code that is easier to understand and add to. Some of these features can be seen in Figure 5.6



Figure 5.6 Shows the functionality code merged with the modified template and the use of buttons, table and scrollbar 5.5.3.1 Accessibility Accessibility was also considered. The steps taken to ensure that the artefact meets all minimum and some intermediate and advanced accessibility guidelines are documented in Appendix O. 5.5.3.2 Human Computer Interaction (HCI) HCI is the study of relationships between users and the computer systems they use to perform their various tasks; Faulkner argues that the success of the system can depend on this (2002, p.9). The changes made in the design and build process regarding HCI are discussed in Appendix P. 5.6 Iteration 2 Testing 5.6.1 Compatibility This works with IE7 on Windows XP and Windows7 (IE8 in 'Browser Mode: IE7') PCs in the replicated virtualised environment (R19). 5.6.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.6.3 Functional Users performing the tests were Management Team members Phil Lee and Vicky Smith, and member of staff Auran Sood.



Different tests were issued by myself to different members of staff and reflected the medium level requirements. Examples include:

Asking users and members of the management team to try and access documents directly, bypassing the system (12)

Asking users if they understood the 'consent' popup message (R14) Asking users to navigate around the system and asses it's familiarity and simplicity (R16

& R17) 5.6.4 Issues identified by tests and rectified

This was very much as 'look and feel' exercise and was therefore hard to quantify, but the users reported being positive about the interface additions on this iteration of the artefact

The management team asked for a favicon to be included, so a red book icon was added The users queried the functionality of the Log Out button as it appeared to them to just

be a hyperlink to the homepage; it was explained that it was but this also included clearing the cookies and therefore the user was no longer authenticated

5.7 Iteration 3 Design and Build 5.7.1 User Management The Manage Users section allows the management team (access level 3) to add a new user, change a user's access level and/or delete a user. It also has information on how to reset a user's password. The Add User section details the current AD users and those who have been added to the system. It allows you to add a new user who is currently in AD but not in the system yet and catches errors relating to duplicate names and blank input boxes. The Change User Access Level or Delete User section allows you to increase or decrease a users access level or delete that user from the system and catches errors such as inputting a new access level outside of the 1-3 remit. This whole section heavily uses command line inputs, command line application icacls.exe (Windows Server 2012), PHP functions and DB scripts, as these examples show:

Add a new user checks if the user exists, adds them to the DB, creates a new Your Documents directory & secures NTFS access only for them, adds an ACE to the ACL of Shared documents directory for that username and then returns a successful message

Changing user level to access level 3 modifies the database, adds an ace to the ACL of Restricted documents for that username (this is because you may have been promoted directly from level 1 to 3) and then returns a successful message

Deleting a user removes the user from the DB and their log files (using MySQL's ondelete cascade), the Restricted Documents ACL (in case they were an access level 2 user), the Shared Documents ACL, deletes the users Your Documents directory and all documents within and returns a successful message. This is shown in Figure 5.7.



Figure 5.7 The deleteuser.php script deletes all traces of a user from the system including log files pertaining to them Once again users (in this case members of the management team) do not know where users' directories are located and what NTFS permissions they have, but are able to manage them successfully but in an indirect way. This fulfils R18 and assists with R1. 5.7.2 Single Sign On For the user to access the system the un/pw details are checked against AD and then cookies are set; this forms the authentication process. Therefore this is a single sign on as the same un/pw for Windows is used for system access. This makes password resets easier as you can just reset the password in AD, which the management team are familiar with (R13). 5.7.3 Browser Compatibility SVS currently use IE7 which this system has been designed for, but three separate CSS file have been created so that the system also works with IE8 & 9 (R20). 5.8 Iteration 3 Testing 5.8.1 Compatibility Using the artefact in the replicated virtualised environment (R19) with IE7, 8 & 9 worked fine, but looked a little different (e.g. button shading) in each version of IE. 5.8.2 Unit

Ensuring that following a successful login, logintest.php sets 3 cookies Ensuring when a user is added, removed or their access level changed that the DB and

ACL in Users, Shared or Restricted directories do change accordingly If the user already exists in the system but you try to add them again, is the error caught

and the correct message displayed



If you try to change the user level to a character or integer outside of the 1-3 remit, is the error caught and the correct message displayed

The correct CSS file is used depending on version of IE used (R20) If a user is added to the DB, do they appear in the middle list in addusermain.php

5.8.3 Functional As this iterations testing is predominantly for the Manage Users area, then only Management Team members Phil Lee and Vicky Smith were present. Different tests were issued to the management team and reflected the low level requirements. Examples include:

Adding a user to the system (R13) Deleting a user from the system (R13) Changing a user's access level (R13)

5.8.4 Issues Identified by Tests and Rectified

This was a clear testing session with no user queries or errors with no explanation of how to perform tasks was required. Therefore a conclusion was reached that this part of the system was usable and intuitive

There were a few requests regarding adding or changing areas within the artefact, but these referred to sections within previous iterations and were not mentioned at the appropriate time (i.e. after those iteration's functional test sessions). This was therefore discussed these with the client and ones with an agreed solution were added to the evaluation section. Examples were the inclusion of a breadcrumb trail (iteration 2) and a change of layout in the contents section of the homepage (iteration 2)

5.9 Chapter Summary This chapter discussed the artefacts design, build and test process at each iteration. During each test process, errors were identified and rectified. The artefact is complete for the purposes of the project.



Chapter 6 - Project Evaluation

6.1. Objectives and Requirements As stated in 1.7, the overarching objectives were broken down into requirements. These in turn were gathered, clarified, prioritized and documented (in Appendix D) so expectations of the artefact between developer and client were clear. The prioritized requirements were designed and built into the artefact in each iteration of the Incremental Waterfall Model. User (function) testing specific to each requirement was performed and the user gave feedback also. As errors were identified and resolved and SVS signed off the current artefact version at each stage, and therefore meeting requirements, it can be concluded that the artefact was successful. 6.2. The Project Process The schedule and Incremental Waterfall Model formed the base of the project process with risk analysis helping to limit potential problems. The schedule (3.6) was correct in terms of time allotted to each section and this was used to measure progress and not over run on any one section, but was not performed in the order stated. For example the local prototyping of the artefact was performed quite early on, as the developer had not done any software development work recently and also wanted to test PHP directory functions prior to a full scale-up. The Incremental Waterfall Model was followed strictly and worked well. The only issue with the timing of the artefacts design, build and test was that it over ran by one week in the tasks prior to starting and

john neesham dissertation

Documents

chapter overview

chapter summary

document access

user access

direct access

correct level of access

v table of contents

staffs levels of access