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 artefact’s design, build and test was that it over ran by one week in the tasks prior to starting and therefore worked the hours allotted to 6 weeks into 5 weeks.
Some of the risks identified in the Risk Analysis Table (Appendix E) did happen and therefore the mitigation was applied. Risk01 occurred with 5.8.4 and 5.4.1; this shows the importance of Requirements Analysis. Risk05 occurred many times thorough developer (unit) and user (function) testing; this shows that the Incremental Waterfall Model was practically useful as it was the right balance of Plan-Driven and Agile methodologies and was therefore a solid base but also flexible when needed.
The feasibility report (2.2) proved to provide the decision makers with the information needed to make the correct decision to continue.
The Agile technique of Timeboxing proved a viable technique as the artefact development process ran to plan; in addition to this, functionality was only a little compromised.
When comparing the project proposal (Appendix Q) to the actual project process and final artefact, there are some parts kept the same whilst others differed.
The details of the problem/list of issues caused are the same and have not been expanded upon by the client.
The overall objectives of the artefact and structure that will resolve specific problems are mostly unchanged. The changes are the idea of document storage using a DB being changed to document storage within the filesystem, and MoSCoW prioritisation was mentioned in the project proposal but decided against in the actual project process.
Regarding the project plan, the list of tasks was similar but the actual project had a few inclusions such as Requirements Analysis and Risk Analysis. The order in which tasks were carried out was also different and the time allotted to each was changed in the actual project plan.
John Neesham Page 31 of 102 6.3. The Artefact and Other Solutions
Chapter 4 analysed the current solutions available and discussed the inclusion/exclusion of these.
As the artefact is now complete it was contrasted with these solutions.
The inclusion of NTFS has proven reliable and secure but, as argued in 4.1.2, only if it is not directly accessed/modified.
The exclusion of 3rd party tools (4.2) has proven to be the correct decision as it was felt that they were not practical for hierarchical file structures and a domain environment.
Remote storage tools (4.3) on the whole were excellent but all needed WAN connectivity and/or were not FOC, whilst using a DB for document storage (4.5) was considered over complex for the task at hand.
Using the artefact as a solution worked well as it was designed, built and tailored specifically for SVS's issues by a technician that had knowledge of the company and their procedures, regular experience of the issues and an understanding of the tools and technologies chosen to create the solution. It is felt that the unrequired parts of chapter 4's investigation were not chosen and that the required parts were carefully chosen and included in the solution, thus creating a solution that mixes the most relevant technologies, techniques and tools for the identified problem.
6.4. What Has Been Learned from the Project?
The following has been learned during the course of this project:
· The importance of documented Requirements Analysis as, without this, requirement creep could have caused the project to run over schedule
· Both SVS and the author have learned more about the legal aspects of data storage
· Working with Virtual Machines
· A new and/or deeper understanding of a variety of current technologies that were investigated and discussed in chapter 4
· New concepts were encountered such as Plan-Driven and Agile Methodologies, Feasibility Study/Report and Risk Analysis
· Software Testing was a new topic that had to be learned, a method chosen and then employed
· Developing a system with an initial and on-going FOC solution that works within an existing infrastructure with no ‘wiggle room’
· Deeper understanding of PHP, SQL, CMD Line, ICACLS, LAN networks and domains
· The importance of sticking to a schedule
· How charity and voluntary organisations work as a business and the less expensive Windows licensing they can use
6.5. Future of the Artefact
There are several ideas on how the project could be extended or artefact improved, if time allowed. These have been split into sections that are detailed below:
6.5.1 Issues with the System
These were issues that were noticed during the development process or unit testing but, as Timeboxing was employed and the time for that iteration had passed, could not be rectified at that stage:
· If a user does not log off (just closes browser with x) then bypasses the login page (which is possible as they will have cookies set) they can avoid logging in again. This is not a security issues or an audit issue, but just worth a mention
· If a user selects a document in shared or restricted areas to download (by searching for then clicking on it) but then just cancels or opens, rather than saving, the document is recorded as downloaded/checked out. Therefore the document will not have been
John Neesham Page 32 of 102 downloaded but cannot be accessed either as the system will report that that user current has it. This would be rectified by using a PHP exec function that utilises a Command Line ‘copy’ script
· If a user logs onto Windows as one user then SVS Document Library as another user this can cause problems with tracking. They will be able to download a doc still, but not upload a document as it has been coded this to be blocked and display an information message (e.g. in shareduploader.php). However, this should not be a problem as all users have unique domain un/pw’s (no generic or shared ones), therefore they should only know their own credentials
· If you download a document from Your Documents, you can then add it to restricted documents or shared docs. This is ok in itself as it will be treat as a new document to the system within those areas. However, there may then be multiple versions of your doc floating around (one in Your Documents and another in shared or restricted). This was caused by Your Documents activities not being recorded and not in the DB (therefore cannot check 'area' of doc you are trying to upload to restricted documents area against the DB)
· Only users with access level 3 can delete Shared and Restricted docs. There is currently no way for any user (at any level) to delete Your Documents. In a further iteration a feature would be included that allowed users to delete their own documents or those they had access to; this would be tracked, as shared and restricted document activities are
· If the password box is left blank on the login.php page, the logintest.php page displays the appropriate output information message, but the CSS does not correctly display the frame
6.5.2 Developer Improvements
These are afterthoughts, by the developer that were noted after the artefact completion but before completing the report, that at felt improve the artefact:
· Comment and validate CSS
· Code reuse was bad for some pages. This could have lessened LOC rather than big if/else. A good example of this is in fileauditresults.PHP
· The artefact should work in the Mozilla Firefox browser
· The artefact should work in IE10 6.5.3 Client Improvements
These are improvements that the client wanted made to the artefact. They were connected to iteration 1 and 2, but mentioned after iteration 3 function testing and therefore, due to
Timeboxing, the requirements analysis process and the Incremental Waterfall model, could not be done within the project timescale. These could be done as a forth iteration, prior to
implemented, if SVS were to adopt the artefact within their IT system:
· Move 'add a document' button that is currently on the homepage to the navigation bar
· The five buttons should on the homepage should be a ‘grid’ pattern rather than vertically ordered
· When the Log Out button is pressed, a message should appear reminding users which documents they have borrowed but not returned (i.e. those still in the Local Library folder)
· A message to appear at login to let users know that they can work on the documents locally from their Local Library within being logged onto the system still
· A breadcrumb trail just below the navigation bar
John Neesham Page 33 of 102 6.6 Project Conclusion
The project objectives were to create a browser based system that securely stores documents, is FOC, integrates into the existing IT infrastructure and can be administered by the client. This was achieved within the allotted timeframe, as it evidenced by the testing/feedback process, and therefore the project and artefact can be considered a success.
John Neesham Page 34 of 102