Remote Document Vault OCD - Essay Example

? REMOTE DOCUMENT VAULT OCD and number: submitted: REMOTE DOCUMENT VAULT OCD Executive Summary This project is built on the principles of operational concept document, of which document management is a key component. The idea was to construct a remote document vault that has a characteristic that allows for text file storage, retrieving and queries. The main architecture is thus composed of two major features of operational concept document namely document vault and client vault. Even though there are existing document vaults that are used in various enterprise architectures, the core essence of this project was to bring on a new dimension of source code repository architecture document that is founded on the principles of remote sensing. As far uses are concerned, the remote document vault is built on a principle of user friendliness and easy interactivity. This means that the component features and technical dimensions of the system are made in such a way that one would not have to be technologically inclined to use the system. The rationale for doing this was to ensure that the architecture fits into as many enterprises as possible, where the need to use basic text files is not the sole prerogative of a reserved few within the enterprise. The structure of the remote document vault is designed as a cyclical framework that makes the exchange of data between users and the remote source a constant process. Within the process, there is constant insertion and extraction of files to and from the remote with Windows Communication Foundation (WCF) serving as the vault server. Among the critical issues that the project addresses are performance issues, test server issues, data transfer security issues, and test result log issues. Introduction Document management is fast becoming a phenomenon with modern operational concept document (OCD). This is certainly because of the advantages that document management systems bring unto the architecture network and connectivity. In today’s era of enabled OCD, the use of paper and pencil files in the storage and management of key information and for that matter documentation is fast becoming ineffective and inefficient in use. The application obligation of this research work is therefore aimed at the development f Document Vault, which works from a client and server interfaces (Ambrose, 1998). The Document Vault shall be operational based on a remote tracking system, giving way for the core provision of operational concept document and document management system to be covered. In effect, a remote document vault will be needed to quicken the process of documentation within the enterprise by enabling insertion and extraction of text files to a remote location. In enterprises with such remote document vault OCD, it has been noticed that a twofold merit of processing and storage are all taken care of. What is more, text files that are stored within the remote system can easily display information about their properties and relationship with other files on the system. Indeed as this happens, it is certain that decision making on the text files will be easier and enhanced (Barber and Delwyn, 2001). This is where it is said that remote document vault brings about efficiency as it enables architecture users to have more done within very short time frame. There are key organization principles and key architectural ideas that shall be incorporated in the remote document vault creation. First and foremost, there shall be a purpose to consider the impact of specific uses on design. This is meant to mean that there shall be different uses to be tested for a single design of the document vault. For the test of results, each specific use shall be critically tested for each design before making decisive choice for an approved design. Specifically, there is also expected to be document parent-child relationships where various software specification documents (SSD) shall be used as a child. Meanwhile, this software specification document (SSD) shall have a designed software design document (SDD) to be used as child. For each SDD also, Software Acceptance Test Document (SATD) shall prevail as children. Because of the multi-variant availability of children repositories, it is expected that this project aiming for the creation of remote document vault would have a tool designed with the focus of making the acquisition of parent relationships for each file within the repository easier. This is necessary because the faster parent relationships can be drawn the easier it will be for users to do more within a very short time frame. In totality however, what will be created is a metadata file that enables child dependency relationships and file properties sharing and display. Project Obligations It is important to define the scope of any software development process so as to ensure that developers stay within a limited area of creation and do not exceed their architectural mandate (Boling, 2002). It is also very necessary in ensuring that the developer will not under produce based on his system specification. This section of the paper therefore outlines the scope of the remote document vault that will be created. As a component of content management system (CMS), the document vault will generally be expected to allow a multi-facet of operational manipulations including viewing, editing, and publishing. This is however a generalized enablement of the remote document vault created under the hemisphere of operational concept document. Maintenance of text files that are input into the computer program can also undertaken from a central interface that is provided within the stakes of the document vault (Davis, McEver and Wilson, 2002). Looking into all these project enablement, it is clear that covering them all in the current research will be highly time consuming and may affect effective deployment of the software modeling and analysis. To avoid the temptation therefore, specific obligations that will be covered to ensure that the document vault gives off procedures for the management workflow within a coordinated environment are: Create Graphic User Interface through the use of Windows Presentation Foundation (WPF) so as to enable communication between Vault Client and the Document Vault Preparation of a Vault Client platform that supports insertion and extraction of files, that are taken from and sent to a remote source. The remote source makes use of a Value Server that is enabled under a Windows Communication Foundation (WCF). Creation of a tool for searching metadata files to be used in the development of a map of parents for each file in the Vault. To build a two pane navigation system aimed at the metadata and text files separately. The mounting of a second file management system, that enables users that browse through files to insert the files into the remote repository. Enablement of a text query messages system Creations of a metadata files editing platform for users From the above, it would be noted that the project is focused directly at the design of a user-centered Document Vault that allows users to decide on how to structure their own child relationships and how to interpret the meanings of the relationships that are structured. Top Level Architecture The context from which the remote document vault is created depends on a number of factors and conditions such as whether it is server or client vault. In the current context however, because of the need to make the document vault a user controlled paradigm, there is the combination of document vault server and client. The server shall purposely be focused on the remote source where the text files and other data blocks will be stored. Under this context, User Input/Output User input and output are aimed at resulting in the possibility that the user will have total control on how to populate top level systems without necessarily having to download several files that can create system jamming and crash ups. Users shall therefore be allowed to initiate document vault inputting through the use of Graphic User Interface provided as part of the core obligations of the project. With this, a message passing input shall be allowed for passing all transactions between client and vault. The major transactions are expected to entail text files debugged in .Net Framework Class Library (FCL). A typical example of this is the C# version 4.5 that EECS clusters provide. User input shall also involve the browsing of text files that are found within the network. They shall also be requested to confirm file properties in relation to their parent before forwarding these to the client vault. The output of the system shall entail a feedback process that informs the user of the status of the document vault as pertains to conformity with children. The output shall be in a visual display form made up of progress and error messages. Network Resources A core functional component of the remote document vault is the network resources that will be put in place to link users of various documents in the architecture to the remote sources. In the absence of network resources, there cannot be that linkage between remote sources and the user’s interface of systems (The DCDC Strategic Trends Program, 2007). The network resources shall therefore assume three major states in document vault communication process. These three states are vault client, document vault and windows communication foundation (WCF). Within the three states, the windows communication foundation (WCF) shall be the resource interface that shall be distributing communication codec between client vault and document vault. In effect, the network resources shall be built on the platform of windows communication foundation. As part of the core roles to be played by the network resources, it is expected that there will be the copying and transfer of category view file. This way, it becomes easier for the use to choose which file becomes the current file by clicking on one of the category files. Setting the current file also means determining which file should take attributes of the client vault. Windows Communication Foundation (WCF) Already, mention has been made of the windows communication foundation (WCF) as being the main platform on which network resources will take place. Certainly, the presence of the windows communication foundation (WCF) in the remote document vault shall not come by default but by plan and process building. The architecture of a WCF is such that it is enabled to make the implementation and deployment of service-oriented architecture (SOA) possible (Denmark and Mulvenon, 2010). It is for this reason that is can be made to lie in-between the client vault and the document vault. As part of the top level architecture of the current project, it is important to explain that the WCF shall be designed to make use of distributed computing aimed at giving service to remote users as part of the report document vault. By distributed computing, it is expected that there will be key components of the software system being designed that will be placed specifically on the networked computer frame to coordinate actions that will come in strictly by passing messages (Flournoy and Shawn, 2009). A decentralized distributed programming shall therefore briefly be undertaken to make the WCF component a distributed system. Query Metadata Messages Commonly, when creating user interface elements that are linear in their user interactivity such as lookup controls, there is no need to access the metadata in the given code that is being used (Denmark and Mulvenon, 2010). The reason for this is that such lookup controls are always hard-coded and so do not require access to metadata for such common business logic (Daly, 2013). But in this project, the case for query metadata is not of such common business logic. This is because there shall be the identification of one or more user-defined categories for each metadata for all the stored files on the system. Such linkage between one or more user-defined categories will certainly bring about complexities that will be designed to support efficient queries. Meanwhile Daly (2013) notes that the creation of such tools for custom user interfaces as the remote document vault seeks to achieve requires access to the metadata so as to make the tools adaptable to differences between enterprises and entities. There shall therefore be query metadata messages that allows for text query searches that is executed concurrently across files and accepts not just one but several categories. Test Harness Test harness have been thought by some to be necessary and useful only in cases where there is the creation of Test related operational content document (OCD) such as Remote Test Configure Tool. But this is a wrong notion as test harness is needed in almost every form of OCD where guarantee on accuracy and conformity to scope is a priority. For the current project, there will be test harness to create test files that will be stored within a superficial Test Configuration panel. As much as the end user shall have access to and use the test files, the key usability of the test file shall be made to rest with the document vault. This way, test harness shall be run internally by the system so that what comes to the user shall be a refined end result that can be fit for all forms of decision making within the system. As part of the architecture of the project, there shall be the creation of a Framework Loader that will be responsible for the creation of test libraries to facilitate the testing process in-between the server vault and user vault. File System If perhaps there was something that could be referred to as the topmost level of architecture, it would be the file system. This is because the remote document vault that is being created has a core theoretical and applicable notion of making use of files, which are specifically text files. This gives the underlying need for there to be a framework that will make the inputting and outputting, as well as the processing, editing and storage of files possible. The file system shall therefore be in place to purposely ensure that there is the facilitation of services on the text files that will be running in and out of the system. Without the file system, the remote document vault will only become useful for the direct in-taking and out-going of files. The reception of messages from the server for onward transmission to the client vault for decoding, action and decision making shall all be dependent on the file system. Source: Rogers (2013) The diagram above gives indication of the various aspects of the architecture in general, out of which the top level architecture has been outlined above. The diagram outlines the essence of bringing on board an external party to undertake the task of quality assurance in ensuring that technical functionality of the system is not compromised. User-Interface There is a user interface that generally defines the control of end-users over the system. Generally, the user interface sets of the functionality of the system as by prompting users to select text files to be used in the vault. The functionality of the user interface is backed by the presence of Graphic User Interface, which makes it possible for users to browse through text files found on the local database within their systems, as well as the remote source of the vault server. Generally, user interface involves the user, making necessary selection of text files to use in program updates, and generally interacting with the Graphic User Interface that has been supplied by the vault server. A very crucial essence of the user interface is its simplicity towards the interaction and manipulation with the system. This is because it is going to be created with the idea that users are not going to be technically inclined people but ordinary members on the enterprise who would have regular and constant need of various forms of text file applications. In sum, the user interface is a very simple one that easily displays desired processes to users in a simple graphical language. The user is not expected, for example to relate the software usage to any generation of tools that bring results to the document vault. This role is however expected to be played by a technical monitoring team for the system. User Categorization The users of the remote document vault are an important part of the entire project development. It is for this reason that the project was prepared with an idea of making it a user-based software. Because of this understanding, the system is higher user-friendly, not requiring much technical knowhow in its manipulation and use. Within the organization, almost every one with access to computer would be classified as a user. There shall however two main categorizations of users. The first group is classified as elementary users. They shall be made up of all workers within the departments of the organization, whose daily duties at work require them to make use of text files such as in the creation of MS Office applications. For these elementary users, what the project seeks to achieve is that there shall be a high and open level of insertion and extraction of text files to a remote location. The idea of the remote location brings in the second class of users, who are core users. By core users, reference is made to a more technically inclined team of IT specialists who shall control the remote location and the processing of data that gets into it. Special Design Consequences The special design consequences of the project mainly applies to the core users who are expected to have some level of technical inclination to the technicalities under which they Vault functions. For example the Vault is expected to show its information about its file categories and general files in a Graphical User Interface (GUI). Due to the need for guided and assisted interpretation of the file categories and files, the display that is done shall be done with a collection of panes, each of which will also display its own metadata properties available. The first level of decision making on the file categories and files in GUI shall therefore be done based on the metadata properties and text of the current categories and file. It is not expected that access to categories and files will be a complex terrain for the core users, especially when it comes to making categories and files current items for onward decision making, editing and usage. One other special design consequence is the parent-child relationships that are expected to exist among the applications documents. Generally the ratings of children shall be done based on the perspective from which the applications document is being taken. The perspectives available shall be Operational Concept Document (OCD), Software Specification Documents (SSD), Software Design Document (SDD) and Software Acceptance Test Document (SATD). Within this framework, OCD has SSD as a child, SDD has SDD as a child, and SDD has SATD as child. Expansion of Product This remote document vault is regarded as a very fundamental version because of its user-interface, which has been modeled to be very easy and generally practical among elementary users. But going into the future, it is expected that there will be some levels of change based on the expansion of the product. The first idea of expansion is based on the format of file that can be handled by the system. It would be noted that the current Vault is made to handle text files but this could be expanded to include image files. Again, the project is being implemented in C# but expanded versions would be expected to be implemented using C++ and mounted on higher versions of .Net Framework Class Library (FCL) other than the version 4.5 current being used. With regards to the tool that searches metadata files for the creation of map of parents, which is currently isolated from the main system, future expansions would seek to input this tool into the main function of the system. Finally, authenticated check-in and versioning shall be enabled on the project. Data Flow The data flow section of the project is dedicated to making known users and technical experts, the nature of data that will be used in the system and how this data is going to be shared from one level of one point of the system cycle to the other within the remote document vault. The first process within the data flow is library construction. With this, reference is being made to the situation whereby users make selection of the text files they want to use in their documents. After this, there is a codification of the text files to ensure that they all conform to a specific source code to make them compatible with the remote source. Next on the data flow process shall be metadata construction, which shall have a purpose of being an authentication system for documents for inclusion in the vault. It is important to note that at this point reference is made to the term, document instead of file because with the library construction, files that are accepted into it are finalized as part of the document to be used in the remote document vault. Once inclusion is made into the vault after the metadata construction flow, data will fall to the text query message, to be accepted by the vault. This will be done so that all files with fully qualified names will be returned to the vault for what would now be a metadata query message to be performed or undertaken. From this point, text files will be ready for use by users. For example, editing of metadata files will be enabled. Application Activities Because there have been details under the data flow on the major tasks that are required of the system, not much of that will be dealt with in this section. Rather, other key areas of the application’s activities and its relation to users in general shall be discussed. First of all, the context of the various activities within the system is explained. Generally, activities like loading of text files into the library, presenting text files for codification, metadata construction, text query messaging, metadata query messaging, and user editing of metadata files forms the activities within the system. The context of this nature of flow of activity is that authentication for certainty on compatibility of text files is very paramount. This is because when tags and values are created in the vault for various files, all those with repetitive values will be replaced. Because there shall be linkage with children for parent files also, it is important to ensure that the process activity flow is cyclical so that the possible mistakes of replacing non-deserving files will not take place. The question of what users need from the system also comes to mind under the application activities. This question is answered in context to what the overall remote document vault will represent after it has been created. In line with this, the remote document vault will be identified as a usage model rather than a loading model. What this implies is that users would want and be given authority to manipulate and play as many functional roles on text files as possible. At all times, a usage model is used in association with other key dimensions of the enterprise architecture to create a business model (Friedman, 2002). The figure below exemplifies how the usage model will be used with resources, competitors and customers to ensure that a business model is created. Source: Software Marketing Adviser (2013) Under the usage models, the questions of who clients and users are asked to refer to the organization seeking for the entire system to be created, as well as staff or employees who will directly interact with the system. The question of how they use the system has been explained under the section of ‘users’ whiles the service providers will also be known to offer technical support for the technical characteristics of the application, some of which include the creation of both document vault and client vault. Finally, the application activities consider impact of uses on application design. Generally, there shall be monitoring component of the application activities to ensure that it matches up its usage in a very high efficiency rate. In effect, the first and major, or most significant impact of use on application design will be the level of efficiency that will be achieved with usage. Where application activities are not able to achieve most of its desired goals or tasks, there will be partial or total redesigning of that part of the system. Again, user interactivity shall be an important determinant in the application design, where non-formidable adherence or difficulty to adhere to the system by users may cause the need for partial to total redesigning. Partitions Because of the need to make the remote document vault user friendly and user centered, a lot will go into the partitions to ensure that the whole system is broken down into constitute packages, where various tasks under the system are broken in package candidates (Gatchell, 1996). The packages are expected to make understanding and breakdown of functionality between the document vault and client vault easier. However, a critical feature of the packages is that they will be used not as independent constituents of the system but as a collective and interrelated unit. As shown in the diagram below, the partitions are aimed at achieving a decentralized system, where instead of having just one package to control the entire system, there will be interactions in the various packages. Source: Project Manager (2013). From the package diagram above, it would be noted that there are five major packages, each of which is made to interact with data sources, external services, users, and external systems. External systems as used in this context are an exemplification of the remote source where data sources, which are expected to be text files, will be sent. Within each of the five packages namely presentation layer, service layer, business layer, data layer, and cross cutting, there are some levels of autonomous partitions that must all be fulfilled to ensure that the overall package is achieved. For instance within the data layer, data access and service agents must come together to ensure that there is a cementing of the data flow within the system. Critical Issues There are very key issues that must be considered in order to ensure that the project, when completed will not produce the likelihood of being brought back by client for underperformance of possible faults. There are four of such key issues. Performance Issues Performance issues generally deal with the functional compatibility of the system, spanning around aspects of process performance such as load and memory usage. Issue # 1: When data load experience a sudden increase in network transfer to uncontrollable levels, what should be done? Text files are expected to be sent to the remote source after a thorough test has been done by the metadata query and a confirmation metadata query message has been received. This notwithstanding, there could be possibility of experiencing data load transfers that are beyond the capacity of the remote server. In such case, the possible result is the overall slowing of the performance of the system due to excessive loads. Possible Solution: Since caching could be a major cause to over load of remote server, a mechanism to cache suspicious data inflow to the system is very important. There should also be a serve load processing monitoring display that updates users on the levels of data load so that when the system is full to taking up any more load, they will be prompted to avoid further load. Remote Server Issues The remote server is the most outstanding feature and component of the system that is being designed. It is therefore expected that the server will execute functionality in a manner that will meet the core needs of the entire system. Issue # 2: Issues of parent and child naming system on the server There are number of parent and child relationships that are expected on the server to make decision making on text files easier. Generally, it is expected that OCD would have SSD as children and SSD would have SDD as children, with SSD having SATD as children. A mix up could however be possible, leading to remote serve inaccuracies. Possible Solution: A possible solution to this problem is have a naming authentication mechanism in place within the server to ensure that right at the server level, there is a check and re-check-system that ensures that a naming test directory is in place to verify all domain associations with each other before feeding this out to the user. It is expected that process will be performed using C# and thus not posing itself as a very critical issue. Data Transfer Security Issues Issue # 3: Issues of data hacking during the transmission and flow of data Because of the composite characteristic feature of the system as an external network that emphases on the use of a remote source, there could be the possibility that external hackers will hack onto data in the course of data transmission. Because text files that are to be used in and out of the system flow could be anything from passwords to key financial figures, hackers may be interested in having access to these data. Possible solution: A tri-sectional security composition is recommended for instances of data transfer security to be addressed. The first of these is the encrypting of all data in their original states before they are transferred to the remote server or any other end of the system. The second is decryption of the data at the destination point, before finally interpretation takes place on data for their holistic authentication. Even though this may come at the expense of extra resource and finances, the security of the data must rather be the paramount concern. Test Result Log Issues It is expected that for the sake of authenticity of data flow, constant testing of log be run. There could however be issues with test result logs. Issue #4: Issues Remaining of Replacement of Logs Because tests are expected to be undertaken on a constant basis by different users, there is that prevailing risk that there will be frequent test logs whenever a log is retrieved (Friedman, 2002). For instance single text files that are pulled ahead may be replaced after each type of old logs is lost. The question is then posed as, how can test logs be performed in a unique way without causing undue replacements? Possible Solution: This is not a very critical issue and can easily be addressed by using similar file names as directory name for the test directory. Reference Ambrose, S. E. (1998). Eisenhower, the Intelligence Community, and the D Day Invasion.Wisconsin Magazine of History, 261-277. Barber, A. H. III and Delwyn L. G.(2001). Maritime Access: Do Defenders Hold All the Cards? Defense Horizons 4: 1-8. Boling, J. L. (2002). Rapid Decisive Operations: The Emperor’s New Clothes in Modern Warfare. Essays 2002: Chairman of the Joint Chiefs of Staff Essay Competition. Washington, DC: NDU Press, 2002: 41-62. Daly, T. (2013). Query Metadata using JavaScript. Accessed October 19, 2013 from http://msdn.microsoft.com/en-us/library/jj919080.aspx Davis, P. K., McEver, J. Wilson B. (2002). Measuring Interdiction Capabilities in the Presence of Anti Access Strategies. Santa Monica, CA: RAND Corporation. Denmark, A. M., and Mulvenon J. (2010). Contested Commons: The Future of American Power in a Multipolar World. Washington, DC: Center for a New American Security. Flournoy, M. and Shawn B. (2009). The Contested Commons, U.S. Naval Institute Proceeding 135, no. 7 (Jul09): 17. Friedman, N. (2002) Globalization of Antiaccess Strategies? Globalization and Maritime Power, edited by Sam J. Tangredi. Washington, DC: National Defense University Press, Gatchell, T. L. (1996). At the Water’s Edge: Defending Against the Modern Amphibious Assault. Annapolis, MD: Naval Institute Press Project Manager (2013). UML Package Diagram Examples. Accessed October, 21, 2013 from http://www.uml-diagrams.org/package-diagrams-examples.html Rogers L. (2013). OER Workflow Diagram. Accessed October 18, 2013 from http://www.macs.hw.ac.uk/~mthljr/workflow.html Software Marketing Adviser (2013). Software Service Strategy. Accessed October 19, 2013 from http://www.software-marketing-advisor.com/software-services-strategy.html The DCDC Strategic Trends Programme 2007-2036, Her Majesty’s Government, Ministry of Defence, Development, Concepts, and Doctrine Center, Jan07: 66. Read More