Feasibility Study Essay Example for Free

Feasibility Study Essay Technical Feasibility: It is technically possible to design a script remarking system because computers can be used to sort, search and update data input using a database management system such as Microsoft Access. The current hardware of the United Kingdom Awarding Body is sufficient, as all they will need to run the system is a computer (preferably with 64Mb RAM, 10Gb hard disk drive, 3.5/1.4Mb floppy disk drive and a 8Mb or higher graphics card), a standard keyboard and mouse, a printer and a visual display unit to run the system effectively and efficiently. Economic Feasibility: It is economically feasible to design and use this script remarking system because fewer people would need to be employed to do the work of remarking a script and producing the reports manually and more work can be done in a shorter time span, therefore also saving on overheads such as light and heating as well as employee wages, Legal Feasibility: It is legally feasible to use this script remarking system because all the data used will be used for the specific purpose of remarking the candidates script and nothing else. The data will not be kept longer than necessary and at the candidates request; the data may be destroyed after a certain period of time. The data is also secure as both administrators and clerical staff need to have their group name and passwords to log into the system successfully, but also the system database password, without both of these, the data cannot be accessed. Operational feasibility: Current work practices and procedures will benefit from the implementation of this new script remarking system as it allows more work to be done in a shorter time span, therefore providing a quicker and more efficient service to the candidates whose scripts are being remarked. The social factors will be greatly improved by the organisational change of using this remark system, both clerical and administration staff can get more work done in a smaller time period allowing more leisure time to the workers for the same amount of pay in wages. Schedule feasibility: The designing, testing and documentation of the script remarking system can be completed before the deadline, there are 6 weeks to complete this. Data Flow Diagram What are the user needs? The user needs an easy-to-learn and manageable interface to be able to monitor the UKABs (United Kingdom Awarding Body) post-examination remarks. In doing so, the user needs to be able to input data (candidate information, the original mark, the date the script was received, the remark mark and the date the script was marked) and get the desired outputs in queried reports. The user needs to know that all data entered will be secure and not tampered with or altered by hackers, so security measures have been taken. What Entities are to be considered? The entities to be considered for this system are: Script Request and Grade Criteria. The attributes to be considered for the Script Request entity are: * Candidate Number * Candidate Name (Forename Surname) * Centre Number * Subject Reference Code * Original Mark * Re-mark Mark (changed or unchanged) * Whether the centre requested the return of the script With the additional attributes of: * The date the script was received * The date the script was remarked Entity Relationship Diagram The attributes to be considered for the Grade Boundaries entity are: * Subject Reference Code * Grade Boundaries for grades A-E and U What procedures will be required to achieve the desired outputs? Clerical staff using the remark system will need to input the data required via forms using a keyboard and (or) a mouse. This will automatically update the queries in place, which will update the reports. The reports will then be outputted using a printer. Evaluation During this systems design, there were many problems encountered. When designing the entities, it was not known that many of the attribute lengths needed to be shortened to save memory, primary keys to ensure each record of data is unique or validation rules had to be set to decrease user errors. The attribute lengths, validation rules and primary keys were set during the design stage (See Validation). An entity had to be linked to another to allow data from one entity to appear several times in another entity and was used in querying. Reading into how linking entities was completed and the tables were linked successfully. Forms were designed to aid user input and stop clerks altering the design and (or) contents of each entity. At first, some buttons worked incorrectly, but were fixed once further reading into using and creating buttons was finished (See Design). Queries were designed to support the creation of reports. These queries search the entities for predefined criterion which is requested by the user. Some criterion needed much deliberation, such as the outstanding remarks query/report. Two extra attributes had to be considered and implemented, these were: script_received_date and script_remark_date. Then the query for remarks which took longer than 3 weeks could be completed, with the search criterion as follows: [Script_remark_date]-[Script_received_date]21 (See Design). Reports needed to be created, as they were the desired output to be sent off to the centres after scripts were remarked. Reports were created using the queries. A user interface was also designed to make the remarking system user friendly. At first, much like the forms, some buttons did not work correctly and there were other aesthetical issues also, such as a colour scheme for the interface. Buttons were fixed and a simple yet attractive colour scheme was chosen for the interface. Also there was difficulty in producing a suitable formula to calculate the original grades from the original marks and the re-mark mark and the re-mark grades. After consultation with a tutor, a solution was found and the following formula was devised: IIF(Expression), True, False. Afterwards, the grading formula was designed and is as follows: Grades:IIf([Original_Mark]=[A],A,IIf([Original_Mark]=[B],B,IIf([Original_Mark]=[C],C,IIf([Original_Mark]=[D],D,IIf([Original_Mark]=[E],E,U))))). A re-mark grading formula was also considered and implemented and is as follows: Remark_Grade: IIf([Re-mark_Mark]=[A],A,IIf([Re-mark_Mark]=[B],B,IIf([Re-mark_Mark]=[C],C,IIf([Re-mark_Mark]=[D],D,IIf([Re-mark_Mark]=[E],E,U))))). Effectiveness: The system re-grades papers and produces reports on the papers that are re-graded when candidate information is inputted via the candidate information input form. Usability: The system is easy for the users to use the interface, it has buttons which open files and forms and have a simplistic design and are attractive to use. Maintainability: The system will be easy to maintain because of its simplicity and will be easy to manipulate to accommodate new requests for different types of information without changing how the system runs excessively. Maintenance Perfective maintenance: For the perfective maintenance, the admin staff can change the queries that create the reports to get the desired results. I.e. changing a query so that the Scripts requested by a selected centre report shows a different centre. Adaptive maintenance: For the adaptive maintenance, staff could use new hardware to help reduce clerical errors. Staff could use OCR and MCR scanners to read the scripts information instead of inputting them manually and therefore reducing human errors.