Infernowear is a new company Essay Example

Infernowear is a new company Essay Example Infernowear is a new company Essay Infernowear is a new company Essay Essay Topic: Inferno Infernowear is a new company run by a self-employed creative designer aiming to producing clothing at reasonable prices aimed at young teenagers who are into the skateboard clothing fashion. As this company has just been set up all orders are phoned through and then written down on any spare paper lying around. At the moment the owner has too much freelance work coming through and is unable to spend the time properly designing and implementing an order system even though he is quite capable. This system will be used to record orders as they are phoned through and also to keep track of the different garments and number in stock. User requirements: Specifically the system should be able to carry out the following procedures. * Store the details of customers and their orders * Keep a list of all garments and garment logos * Record and update stock levels automatically after each order has been recorded * Ability to print out shipping labels for each order placed * Ability to expand the product range by adding new types of garment and garment logos to the system * Each logo and garment should have a simple product code that makes identification and inserting into the database easy and fast. * A search option should be included so that stock level and customer orders can be quickly displayed * A variety of data should be printed in reports including shipping labels and the order line. * As personnel details will be stored it is essential that the system is password protected so that it keeps this data safe and complies with the data protection act. Feasibility study: I will now carry out a feasibility study, as it is the first stage of the systems life cycle. After this I will then make a full detailed investigation into the current system and requirements of the new proposed system. The feasibility study will be based on the well know TELOS mnemonic for the five feasibility factors which are explored in depth below. This study covers all potential problem areas that could effectively stop the project from going ahead. It also covers the advantages that this new system would bring to the company after implementation. Technical feasibility: There is nothing too complicated with the proposed system so I am sure that there is no technical reason why this new system cant be built. There is also no problem why the system cant be built in Access so I am confident that I will not have a problem with the technical side of this new solution. Economic feasibility: As this new system is being built for my A level course I will not be charging the owner of Infernowear. As this is the case the benefits of having a well-made order system for free will defiantly out way the costs. Legal feasibility: Appropriate security measures shall be taken against unauthorised access to, or alteration, disclosure or destruction of, the data and against their accidental loss or destruction section 2(1)(d) of the Act This above act was taken from the data protection act; it states that security methods should be used to protect unauthorized access to personal details. As my system will be handling customer details including addresses and phone numbers it is essential that the system is password protected and secure. The data shall be accurate and, where necessary, kept up-to-date section 2(1)(b) of the Act This next snippet from the data protection act states that all data held should be accurate and when necessary be kept up to date. As the Infernowear system will be holding customer details its important that its accurate. To do this validation rules will be introduced to key fields making sure that only numbers can be entered into a telephone number field for example. The act also states that the data held should be kept up to date where necessary. The data will only be updated when a customer makes an order, the telephone operator will ask if the data is up to date and correct. If the company expands it would be necessary to include an operation that would delete customer details after a prolonged inactive period of time where no orders where made. Operational feasibility: This section looks at whether the right work practises and procedural infrastructure is in place to accommodate the new proposed electronic computer system. If not the implementation of this system would cause more problems than it would solve making the company less productive and probable lowing morel due to the newly arisen difficulties. After having a brief look at the current pen and paper work practises used by the owner I have decided that this new system could be implemented and would help to keep the whole operation tidy and all information in one place which is easily accessible and updateable. As the owner and user of this new system is already competent with Access there is no reason why there would be any difficulties with implementation. This section also looks at the probable social repercussions once the system has been installed. As the company consists of one, (a creative freelance designer) I can see no negative side effects of implementing this new proposed system. The only thing that will change is that all orders will be booked using the computer system instead of using pen and paper. This will drastically improve productivity and the speed at which orders are placed, it will also increase reliability, as there is no fileing system at present of order and customer details. Schedule feasibility: The schedule feasibility looks at setting out a time frame for the completion of the proposed system. The deadline given is for a fully functioning system ready for implementation by Easter 2003 including an in depth high quality write up. I see no reason why this system cannot be ready for implementation by the time set out above. This gives me plenty of time to produce a complex fully functioning system as well as a well documented write up. Analysis: Before I can continue I will conduct an initial investigation into the current procedures and work practises so that I can find out exactly what the new proposed data base system has to do. Interview with Company Director Mr B Hull: I conducted an interview with Mr Hull to discover in more detail what the current work practises are and what the new system has to do. I will use this interview method, as I will be able to extract large amounts of information from a single interview. I will not be using questioners because there is only one member of staff and I feel that interviews on the whole will be more productive. Current work practises: Orders: Orders are phoned through to Mr Hull on his own house number, these are then jotted down onto plain A4 paper. Each order consists of a garment type e.g. a hoodie or a T-shit and a logo like the orange Gecko or the flaming heart. After Mr Hull has several orders he contacts his printing suppliers. He places a master order consisting of all individual orders pays them up front and waits for the supplier to produce the order. After this the supplier ships the master order to Mr Hull who then distributes them to the individual customers. Payments: Payments are either made in cash or in cheque form. The cheques are either posted to Mr Hull or hand delivered by the customer, all cash payments are hand delivered. Mr Hull then adds the customers order to the master order and is sent to the supplier, this is explained in the above Order section. There is no record of payment once received except for a hand written note. This obviously needs addressing when designing the system, as strict records need to be kept about receiving payment. Delivery: Once Mr Hull has received the master delivery form the suppliers he then breaks it down into individual orders and manually writes out address labels to go with each order. These are then delivered via the standard postal service or collected by the customer. There is also no record of what has been shipped and to whom. This will also be taken into account when designing the system. Mr Hulls idealistic view of what the system should be able to do: Before I list what Mr Hull wants from the system there are a few new developments that need to be noted. As this system will not be ready much before Easter for implementation Mr Hull would like it to include aspects which arent needed at this point in time, but which will be needed come Easter. Mr Hull would like to have a stockroom in a couple of weeks within which are a quantity of pre-printed garments that are available to the customers. This means that Mr Hull wont have to wait to get a number of orders together to send to the printer. Instead he can do individual orders as they get telephoned through, this speeds up delivery times and keeps things moving. Orders: When customers place an order their details should be taken down including shipping address. Then it should be possible to attach an order or orders consisting of garments and the logos that should be printed on each one to each customer. By the time this system is implemented Mr Hull will have a storeroom of pre-printed garments, there for it is vita that stock levels are recorded and updated when orders are processed. Payment: Payment will take much the same form as before where by a customer is required to send a cheque or cash through the post or deliver it directly to Mr Hull. On the new system a simple yes/no check box will be used to verify that payment has been received. Mr Hull is also looking into making the company strictly a phone order company where the only way to pay for goods is with a credit card e.g. Visa or Switch. If Mr Hull can have a credit card payment system set up before the implementation date of Easter he would stop receiving cheques and cash which will speed up orders again as he does not have to wait for the money or cheques to come through the post. This will only mean that the new data base system will not need to print out invoices for each customer. Delivery: After an order has been inputted into the system an order line will have to be printed so that Mr Hull can compile each customers individual order from the available stock. After each order has been assemble customer-shipping labels will have to be printed by the system as this would save a lot of tedious hand written work. After this the orders will be delivered the same as before via the standard postal service. Before I break this interview down into simple objectives I will first find out what computer system and software Mr Hull has. Because he is also a freelance creative designer I presume that he will have a fairly reasonable spec computer with a good variety of software packages. Current Hardware and software: Mr Hull has a Windows based PC with the following specs: * Windows 98 * AMD 1.4 GHz * 512mb of ram * 60 gigabyte hard drive * Laser colour printer * Other media storage options including Zip drive, CD Rom drives and a CD re-writer. He also has a basic 1.44mb floppy drive. He has many software packages but the ones that need mentioning are: * Word 2000 * Access 2000 * Visual basic 6.0 As I have mentioned before Mr Hull is a competent Access user who does not have the available free time to produce a fully functioning system. His competency with Access means that the system can be quite sophisticated and I wont have to spend as much time making the system user friendly as he will be able to navigate Access with ease. Data flow diagram: The DFD below shows how the new computerised system will take orders and how the data will flow through out the system starting with the customer placing an order and ending with the orders being shipped to the customer. A customer makes and order over the phone, the operator checks the stock levels of the requested items. If the items are available then they are booked out and the operator checks to see whether the customers details are on file. If not they are manually entered and payment is then taken via a credit or debit card. Then the completed order updates the stock level and the order is added to the order line. The order line is then printed along with the shipping labels and this is where the computer system ends. After this the items are manually gathered from the stock and packaged. The shipping labels are then added to each delivery package, which are then posted to the customer. Objectives of the new system: Now that it is clear what the new computerised system has to do I will state the key features of the system below for easy reference and quick reading. * Enable customer details and customer orders to be recorded and easily edited this should also be done in a fast time, faster than a handwritten note * Produce a complete order line of all customer orders so that all required items could be taken from the stock room * Customer shipping labels will also be produced and added to each package * Security features will be introduced to comply with the data protection act like passwords and validity checks Design: Even though I am almost certainly going to use Access 2000 I first must look into other software solution and explain why they are not going to be used. Software choice: After using Excel, a spreadsheet program for other subject coursework assignments I have gained a good knowledge of its advantages and its limitations. It is very good for calculating and carrying mathematical operations on large amounts of data in a very quick time. Unfortunately it does not function as well as a simple data input device as customising sheets and performing validity checks are complicated and slow. This package is not designed for customised application layouts and therefore making the resulting system seem complicated and untidy. Because of the inability to customise individual sheets to a high degree I have decided that I will not use a spreadsheet program as the main backbone to my system. It is also possible to buy off the shelf solutions to this product order system. These packages are complex and contain everything needed to implement straight away. These packages have been written by highly skilled individuals and have been tested and updated using the well know evolutionary model by which improvements are made to solve pervious problem which have been discovered by the vast array of users. These improvements are released in the form of updates and patches. Because this type of package has a very high reliability and a wide tried and tested audience, it would make sense to seriously consider one of these packages in the future if the company expand greatly in the next few years. But as the company is just starting out it would cost a lot of money to purchase an advanced of the shelf system. This is not needed at this current time in the companys life cycle, because of this I will not be recommending spending vast amounts of money on this type of solution. The next type of system that could be used would be a custom made solution. This would most probably be created in Access due to its flexibility in relationship databases and the ability to customise forms and printouts based on queries run past selected data sources. Access 2000 is also currently installed on Mr Hulls system as well as my home computer and the school network. This makes building the system easy as it can be worked on at home in school and even in the final workplace. Because of the outweighed benefits of using a customised database system that can be purpose built to solve the clients needs I will be recommending using this type of solution. Final software solution: After a careful investigation into different software solutions I have decided that the new system will be built using Access 2000. This is because the software package is already available to Mr Hull and myself so no software purchasing is needed. Access also has many advantages over other technical solutions some of these are mentioned above in the software choice section. Database design: Entity-relationship diagram: With in my database solution I will have four entities each joined with the following relationships. Table design: I will have separate tables for each of the above entities being linked by the relationships shown on the previous page. Some of the tables will need input masks to make sure that the data which is inputted is correct, this will also help the system to meet the data protection act of keeping data accurate. Table names: Customers: The customers table will have the following fields: * Customer ID (this will be an auto number) * Contact first name (text form) * Contact last name (text form) * House number (numerical) * Street name (text form) * City (text form) * Postcode (text form) * Country (text form) * Phone number (numerical) * Email address (text form) * Notes (used for attaching notes to customer, could include any complaints) (text form) Clothing: This table will contain the following fields: * Clothing ID (text form) * Units in stock (numerical) * Product name (text form) * Product description (text form) * Unit price (currency) Logos: This table will contain the following fields: * Clothing ID (text form) * Units in stock (numerical) * Product name (text form) * Product description (text form) * Unit price (currency) Orderline: This table will pull together a customer ID number with a clothing ID and a logo ID, the fields are stated below: * Order ID * Customer ID * Clothing ID * Logo ID * Payment received Form design: My database will consist of four forms for data entry and five for navigation, product information and customer information. I will first give a description of the data entry forms with screen shots where necessary. Form name: Customers: This form will be where new customers can be added to the system and where existing customers details can be updated and amended. The input fields on this form will include; Customers names, address, postcode, phone number and email address. There will also be an auto customer ID number assigned to each new customer. Also I would like to insert a memo text box so that any special information about the customer can be logged here, this could include previous complaints and any payment problems. editClothing editLogos: These two forms will enable the user to add different types of garment and logos whenever new designs are produced. This will make updating the system easy and hassle free because you dont have to manually enter the new products into the complicated forms. FrmOrderline: This form will be where all orders are made; it will use a query called qryOrderline that combines the customer, clothing and logo tables. This data will then be displayed in a sub form within the qryOrderline form. After an order has been made it will then be added to the Orderline table. Report design: My system will include four reports, one for printing shipping labels, two for logos and garment labels these will be stuck to the deliveries as they come in from the printer so that each box of products are easily identifiable when looking in the stock room. The other report will be the master order line consisting of all the customer orders so that Mr Hull can take this into the store room and gather all items needed with out needing individual customer order sheets. Report names: LabelCustomer: This report will be based on the query qryOrderline showing each customer who has an order ; with there shipping address. LogoLables: This report will be based on the Logos table giving the user the ability to print out identification labels for labelling the stock. ClothingLables: This report will be based on the Clothing table giving the user the ability to print out labels for identifying the stock. OrderLine: This report will be produced from the query qryOrderline showing all orders with only the customers name and ID; this saves space, paper and ink. Query design: There are two very similar queries used in my database solution. One is used in the Orderline report to show all customer orders that have been paid for, to do this a simple = yes was needed in the criteria box of the payment received field. The other query is used in the form named FrmOrderline, it shows all the orders even if they have not been paid for, so when confirmation of payment comes through the payment received check box can be ticked. To do this the criteria for the payment received box was left empty to show all data. Screen shots of the two queries are also supplied in the appendix section at the end of this document. Macro design: Through out this system there will be many macros, most of these will be focusing on opening and closing forms. Three of these macros will be used to open the reports so what they can be printed. One other macro will be used to simple maximise each from when it is loaded. SQL statements: As I will have to update the stock level after each item has been booked out I will be using some short but complex SQL statements. To do this I will base my SQL code on the pseudo code that I have written below which will be run each time an item is booked out. The pseudo code below is for updating the clothing stock level but is easily modified to update the logos as well. Update table Clothing set field stock levels to = stock levels -1 where field clothing ID = selected clothing ID Menu design: I will be using a menu system for navigation around my database starting with a login screen this will then open up a main option menu. Below is the structure I hope to have in my final system. Performance indicators of the new system: * It should be easy and quick to add a customer to the system taking no longer than 20 seconds for a competent system user. * All orders should be completed with in 30 seconds otherwise the customer will be spending a long time on the phone and the system will not be efficient. * Any one customer should be able to have as many orders as he/she wants * The customer shipping labels should be printable on standard A4 label paper * Payment is made through another system but there must be an option that can be check to show which customers have given correct payment. * The stock level should be updated each time an item is booked out. Test strategy: Now that I have a functioning system it is vita that I thoroughly test each form, report, query, macro and any other code that I have to make sure that any problems are sorted before the system is installed onto Mr Hulls computer system. The parts of my database system that will be tested are: * Each and every form, report, query, macro and all other code as it is created. * Testing each button and rollover under different circumstances e.g. is it possible to close the order form is only half of the order is compete * Tests will be carried out to ensure that improper, invalid and extreme data cannot be entered * Combined module testing in which one aspect of the system is thoroughly tested like creating an order from start to finish or printing out customer shipping labels. * The last type of testing will be to see whether the system meets the end users (Mr Hulls) requirements. Test Plan: I will now carry out a variety of tests on as many menu options as possible without going hugely over my word limit. These test carried out below will check that all operations work properly every time with out fail, if there are any problems I will fix them, and state how, and redo the test to prove that it now works. I will first test the system starting at the login screen and work my way through the different forms and menus testing each as I go. Password test: When the correct password is typed in it should load the main menu form, the correct test password is inferno Test result successful, system does not login if wrong password is typed in. Roll over test (main menu): When the mouse is rolled over a link to another form the link colour changes to make the user aware to which link they are hovering over and to show that the link has go focus. The test will make sure that all link rollovers work. Test successful, as you can see the link with the focus has changed colour. Validity checks: I will now check that irrelevant data cannot be entered into the wrong text field. On my system there are way to many text fields to list each individual test result here. I will show an example of one of these tests below so you can see the result. The test below tests to see whether a letter can be entered into a numerical text box. From the above screen shot you can see that an error message pops up when a letter is wrongly entered into the house number field. The above shows an example of the customer table design, all other table screen shots can be found in the appendix. You may have noticed that the PhoneNumbers data type is text this is because when entering area codes like 0117 with a numerical data type the 0 is remove automatically. Obviously I need to be able to enter full area codes that begin with 0 so I have had to change the data type to text. These are the types of errors that rigours testing can find and iron out. The above screen shot shows the validation input mask used for the PhoneNumber input field. The mask only allows numbers to be entered, this fixes the text data type explained previously. The mask enables a user to type in a phone number with the option of adding area codes if needed and extra digits, the 9 represents optional number input and the 0 are compulsory number input. Other validation techniques and input masks for all other table can be found in the appendix. The above screen shot was taken from the order form. Unfortunately it is possible to change customer details here, this should only happen in the add edit delete customer form. To fix this all field were locked by choosing yes by the locked option in the text field options. Record deletion: When I decide to delete a record I need to make sure that a verification message pops up, this will make sure that any accidental deletions of any field type are very low. The below screen shot show the default Access verification pop up, this will do the job perfectly and needs no altering. Stock level adjustments: When orders are completed the stock levels need to be updated to take account of each booked out item. To do this a SQL statement was used and called from within some VB code. The code I eventually used was: DoCmd.RunSQL UPDATE [Logos] SET [UnitsInStock] = [UnitsInStock]-1 where [logo ID]=' ; LogoID ; The above code works with no problem even though it took a while to get the syntax correct. When you book out an item this code is run and a default Access verification box pops up double-checking that you want the order to go ahead. This is very useful, as I dont have to make my own verification dialogue boxes. Payment received testing: After an order has been placed and the payment has been taken a simple check box by each order line should be checked to show that the customer has paid. If the payment received box is not check the order will not appear on the final master order report. As you can see from the above screen shot only one order line of Simons whole order has been paid for, therefore on the master order line report Simon should only have one entry. After printing out the report it is plane to see that this test is yet another success, the report is in the appendix of the project for all to see. Report testing: The last piece of testing that I will write about is the testing of the reports. To test that these work I will just need to press print on the form (screen shot below) and see if the printouts meet the designated criteria set out in the previous sections. After examining the printed reports I can safely say that they work and all the necessary detail is in place. They could do with some tidying up but these are small problems which if I do not have time to fix I am sure that Mr Hull can change them at his discretion if he so wishes. System maintenance: Once the system has been installed it is vital that there is a structured system maintenance program in place so that any modification or problem fixes can be made. There are three types of system maintenance that are used almost all the time when new systems go live onto clients computers, these are then used throughout the softwares life cycle. A Technical manual will also be written in my spare time but will not be added to this report, as it does not count towards any of the marks. A technical manual will enable other individuals who are competent with Access to gain a quick understanding of how I put the system together and how to change key options. This manual would also include reports of know problems and their possible cause, this would help and system designer to quickly identify the problem and fix it with in a shot time period. Corrective maintenance: This type of maintenance will be used very frequently just after the software has been installed. Corrective maintenance deals with fixing major problems that were not found even though the system was thoroughly tested prior to the final implementation. After Mr Hull installs the system I would be more than willing to come back to his company and attempt to fix any problems that arise even though he is more than capable of fixing them himself. As this system is not built by a highly skilled professional I would expect many problems to arise within the first few weeks of operations. Fixing these problems could take a long time, as I have no one else working for me who could fix the system. The only thing I could do is try my hardest to fix each problem as it arises but keeping on top of all of them would prove hard. Perfective maintenance: This type of system maintenance is also ongoing there are many things with in the project which could be done just the little bit better. These minor updates and fixes can in some cases be very time consuming for the rewards that they reap. Before starting out to fix any problem no matter how small it is vital that the time and costs of fixing the problem dont outweigh the end result. One part of the system that I would like to change is the way orders are booked out. After each item has been booked out you have to click yes on the check pop up box, it would be much easier if all the items were booked out for one customer then a only one single check pop up box appears to make sure that you do want to book out the current selected items. Adaptive maintenance: Adaptive maintenance is concerned with adapting the current system as the needs of the company change. There are two major changes that could happen with Mr Hulls Infernowear Company that would result in the system being adapted. If the company expands it would be necessary to employ extra telephone staff to take orders. If this were to happen the system would have to adapt from a single user station to a multi user environment installed over different types of network. Mr Hull would also like to modify the system slightly in the future so that a similar system could be uploaded onto the Internet so that the customer does not need to phone up instead they can order any item over the Internet. User manual: This manual will give a brief overview of the system and how it works. It will include step-by-step guides for the most communally used tasks. As this software and user manual is purpose written for Mr Hull who is competent with Access I will not have to go into great detail on how to get to the design views on tables so large amounts of data can be entered quickly and other simple tasks. If you are updating from a manual pen and paper system you should hold the SHIFT key while the program loads. This will bypass the main login screen and will allow you to manual enter customer details from your old paper files into the blank customer table. Once you have entered in all the details follow the guide below. When first loading up the program you should be confronted with a password screen like the one below. Enter the password that you have been given when you brought this software and click the login button. You will now be logged onto the main option menu, follow any of the links to the separate forms. If at any time you want to return to the main menu or just shut down the form you are on just press the back out button, top left: If you want to create an order click on the create booking order button this will then bring you to a screen like the one below: To create an order first find a customer using the navigation provided. Then form the sub form choose a type of clothing and a logo via the dropdown combo box. Repeat this as many times as needed to keep adding orders to an individual customer. After each item has been book you will have to click ok to a confirmation pop up box. After payment is taken make sure that the payment received boxes are checked by the side of each order line. To add edit or delete customers and to add edit or delete clothing/logos simple choose the relevant option from the menu and follow the simple onscreen instructions. If you are going to add edit or delete clothing/logos make sure you know what you are doing as any changes cannot be undone. It would make sense to make a backup copy of the database just in case you lose important data. If you want to print any reports click on the print reports option from the main menu. You will now see a selection of reports that you can either preview or print straight way by clicking the appropriate button. The screen you should see is the one below: To exit the system back out to the main menu and press the log out button, this will bring you back to the password screen where the program can then be shut down via the X in the top right hand corner. Evaluation: I will evaluate the system I have made based on the performance criteria outlined earlier in the design section. The first criterion was to be able to enter a customers full details within 20 seconds. After trying and timing my self the best time I have been able to achieve is 18 seconds. This is just within the propose time limit but looking back on it 20 seconds is a very fast time to enter in over 10 lines of details. There is no problem with the system here but its down to the speed of the user. The second performance indicator was to be to make an order within 30 seconds. After timing myself again I have been consistently able to create an order with in 15 seconds, this is very quick and even surprise me. This shows that I have met this performance indicator very well and have succeeded here. The third indicator was for any customer to have more than one order line. This has not been a problem at all, I have made of 50 order lines for one customer and it still let me add more. This performance indicator has been easily met. The next option was to print customer-shipping labels on A4 label paper. I have not been able to test this part of the system, but the report is set up to print on standard A4 labels so I see no reason why it would not work, obviously the label paper would have to match what the system is set up to print. A payment-received option has been added thus only showing orders that have been paid for, on the main master order report. This is a complete success and works with out any glitches or problems. The last performance indicator stat that the stock level should be updateable after each item is booked out. This has eventually been done after a lot of research into SQL and after a lot of time spent getting the syntax just right. It is a small simple piece of code that has fulfilled this last performance criterion. Future enhancements: At this point in time there is no report for printing customer recites, this is quite important but is easily doable and will be completed after Mr Hull gets back from his holiday cruise. Each item could be given a stock location as well as an amount. This would then make sure that if the stock room were to grow the system would already be able to store the individual stock location of any one item. Last but not least it would be a nice idea to include some sort of mail merge so that whenever a letter has to be sent out to all customers it can be automated saving a lot of time manual work. Mr Hull is currently using this system to see whether its the sort of program that can do the tasks he specified earlier in this document. If this system proves to b built to a high standard he will use it until it needs updating or extra more complicated features are needed, at this point he may be forced to invest in an off the shelf package solution. Unfortunately Mr Hull is on holiday and I am unable to contact him and get any further feedback.