Quality Standards
To have an efficient system, which performs to the satisfaction of any organization, the value of Quality assurance should not be overlooked. A quality system enables a company to deliver its promises with due professionalism and ease. Several factors quantify the efficiency of a better system.
The first factor is the technical standard. Technical standard looks into the system requirements, which include the input and output should be defined in tandem with organizational objectives or needs (Galin, 2004, p.33). The second factor is the testing standard. The testing standard refers to system testing, which should follow a set procedure to ensure the system meets the operational specifications (Galin, 2004, p.69). This should be done to establish reliability of the system in place. The third factor is the safety and performance standards. There should be auditing of the process involved in establishing the system this should be in connection with the laid down policy of the company.
An evaluation of the responses from the system should be encouraged to measure the progress of the development (Galin, 2004, p.78). This ensures responses that come from the system are used to further enhance the system quality to meet the standards of the company. Auditing should be done periodically to determine the output, technicality, maintainability and performance of the system (Galin, 2004, p.90). Auditing is important because it will be known what kind of output is generated in the system and if changes need to be done. Auditing will establish whether the system needs though maintenance to make it perform to the required standard. When auditing is performed, it provides detailed information about the system and this helps in decision making.
Costs
It is costly to have a new system in place, however, when meticulous plans are instituted, the costs are kept at a minimum hence having a quality functional, cost-effective system. A project team entrusted to carry on the project should in advance have to perform a thorough feasibility study and problem analysis (Webb, 2003, p.67). The requirements of the system; input, processes and output should be outlined. This will prevent going back to perform the same thing when the project is nearing completion and hence repeating the same work, which can be costly.
Documentations should be encouraged at every stage. Records can be referred to when certain information is being sorted. This precaution will improve coordination during development (Galin, 2004, p.100). The documentation should be detailed about the process flow and the system requirements.
Testing should be done at every design stage to ensure the program executes what it is supposed to execute, the test is systematic and performed with laid down procedures so that errors established are dealt with before the next stage is preceded. This eliminates a situation where the whole system has to be reworked when a bug is discovered in later stages during the development period (Webb, 2003, p.78). With this in mind, it’s a possibility of delivering a system that meets the company’s needs and the chances of being redone are very minimal. This saves the budget and time for both the project team and the company.
Self Assure Software
Office consumables such as; office stationery, laser and ink cartridges are costly in the long run to acquire. Automation procedure to be adopted by Self Assure in its policy and claims departments will allow the establishment of a paperless office and thereby saving the company costs of purchasing these consumables. Automation will make it possible for the company to keep the entire policy and claims request in a centralized database thereby allowing only important documents to be printed.
System Development Risks
System development like any other project offers myriad challenges, risks and merits that have to be addressed by the programmers and organization’s management. However, to focus on the ultimate goal, major risks have to be tackled earlier to allow proper management and remedies to be infused in the system development process.
Cost risk is one of the major risks associated with project development. When the budget has not been set aside to allow the project to propel to completion then, it’s likely that the project will be thwarted along the way (Webb, 2003, p.123). Enough budgets should be set aside for the duration of the project to avoid project stalling.
Time Risk is also a major risk when developing a new system. Sometimes a project may involve many modules and thus require more time to complete. The project team should develop a timeline showing the milestone and what should be done at every stage. This makes it easier to work within an allocated time span.
Quality output is also a major area of concern. Sometimes the project team may misinterpret the requirement of the system. This may occur as a result of miscommunication between the team members and the users. This makes the team develop a program not in conformity with what the company wants. Proper communication between the company’s needs and the project team should be precise to enable the attainability of exact project needed.
Technology availability is a major consideration in IT system development. The project should use the language which is readily available in the market. The use of language that is available in the market allows the developers to work on the project effectively and hence when one of the programmers leaves the team it’s relatively easier to have a replacement because of the familiarity of the technology and the language. Relevant technology allows future upgrades and facilitates addition of more modules when the company expands and has new needs.
Quality Plan Execution
For an efficient quality plan to be established, some aspects have to be considered in order to have a plan which reflects the true picture of the organization and management responsibilities. The quality plan will allow the organization to measure the exact strength of the developed system to justify the time and costs allocated to it. Nevertheless this the management will be interested in the quality execution.
The program developed should have the requirements of the company compliant with the management (Mezgá, 2006, p.90). Both parties i.e. the project and the management team have to agree on the developments of the project.
The next consideration in quality plan execution is Design control. The system should specify a detailed procedure in each and every phase of design; this includes changes in design or what actions have been taken in a given stage during the design. Once design control has been established, the system builder should ensure proper documentation. Each stage should be accompanied by documentation that defines the project (Mezgá, 2006, p.96). This facilitates easier understanding of the systems by the users who are not familiar with technicality of the program.
Testing and inspection is the second last step in quality plan execution. During testing phase, an elaborate procedure showing how plans for testing will be implemented has to be outlined. A plan detailing corrective actions and describing corrective actions for the errors witnessed during program execution should be shown.
The final phase of quality control execution should involve training of users. Training requirements for the new system should be defined and the training methods and requirements are outlined (Mezgá, 2006, p.102). Resources to facilitate and the target audience should be established and the venue for training decided in advance.
Project planning
Planning is important element in system development. It is a tool that helps to guide the development team to know when making progress. Effective system planning through the stages of development allows the project executors to concisely analyze individual stages. The analysis helps to justify if considerations and all requirements have been incorporated or met.
Terms of reference set when the project was beginning should be constantly reviewed by the team and the company management to ensure that no details have been omitted (Webb, 2003, p.145). This allows the management to confirm the capability of performance of the system and approve. It allows smooth flow of progress when the project starts. Terms of reference should be kept for future purposes. It serves as record to confirm if the project implemented is what actually the company needed.
Change is invariably important in an organization when a new system is implemented. A plan should be put in place on how effectively this has to be done (Mezgá, 2006, p.113). The users of the new system have to be identified and the method of training formulated. Training resources and time should be planned earlier and budget allocated if it was not budgeted for during the start of the project.
Testing of the program should be planned for and methods of facilitating outlined. User acceptance and integration testing, or unit testing should be involved to ensure that the system works to the expectation of the company (Blanchard, 2004, p. 35). Errors should be identified if present in the program and appropriate corrective action implemented. Planning facilitates having a working system that is based on the user requirements and can solve the task targeted (Blanchard, 2004, p. 68). Proper planning cuts down the costs and allows completion of the project on scheduled time.
Qualities of a Good Manual
Manuals help users, developers and the management to understand the system at a deeper level. A good manual should be well documented. It should be able to outline the capabilities of the system, what the system can do and what the system can not do (Blanchard, 2004, p. 98). It should also have good documentation on the input, output requirements of the system. The documentation should also give some explanation when a user is stuck what he should do and should also provide contact information for the technical support of the same.
A good manual should be easy to read and follow. Complexity should be avoided. And when technical phrases or words are used, they should be accompanied by an explanation at the end of the manual (Blanchard, 2004, p. 104). This helps the users who are not technically familiar with the system understand it better.
The manual should have a clear title, table of contents explaining what is contained in every chapter. Furthermore, it manual should have an introduction. An introduction gives brief description of the company and the aim of the manual. the index should be provided at the end of the manual that the complex and technical jargon used in the manual can be explained. It is important to have the title so that any person reading the manual may know what the manual is all about. The table of contents outlines what has been covered in the manual and helps a user to jump quickly to a specific part of the topic.
Referencing
A reference facility elaborating the company objectives and requirements for the system is important to be in place for constant referrals. It should be well outlined and documented. The facility should explain the capability of the system. The program for Self Assure will have the ability to create a paperless office. It will automate all print works and only important documents printed by authorized personnel. The policy and claims applications will be stored in a database. This will facilitate faster retrieval when needed. Automation will reduce the costs spend on purchasing office consumables such as ink and office stationeries. The referencing facility will entail documentation on specifications, policy applications, claims and quality assurance manual operational procedures of the system.
Timeline
Project planning and development involve many aspects and time is paramount. A well elaborated and accurate time should be made available during each individual stage to ensure that no phase is done in a hurry in order to best the dateline. To ensure that enough time is available for the project, a chart detailing the order of events and phases in development may be considered and broken down into manageable stages and each stage is assigned a specific time. This allows comfortability of working without rush hence enabling the development to be complete within an agreed period.
The following outline shows the milestone of how the project will be carried out in phases.
Stage/Phase Duration
Preliminary system Investigation August 2010 – June 2011
System Analysis July 2011 – December 2011
System Design January 2012 – October 2012
System Coding January 2013 – October 2013
System Testing December 2013 – May 2014
System Implementation August 2014
System Maintenance Ongoing
Design Questions
To facilitate design phase, there are a number of poignant questions the project team has to look into so that they realize the goals of the system. When it comes to testing, project teams have to ask questions like; what type of testing will be employed in the new system? Which methods should be employed to test the new system? Various methods of testing should be explored e.g. unit testing, user integration testing or structured through should be assessed and the best one chosen. Testing should be done using test data. Both valid and invalid data should be run through the system. It enables to identify and check only the correct data is accepted in the system and invalid data rejected.
Another critical question for the project team is ‘Who are the users of system?’ The users of the new system should be identified and their ability for using the system in place analyzed. Some users are experienced whereas others are not. Based on the users’ needs, consideration has to be taken into account that.
The Interface is an important component of an IT system. With regard to the interface, the project team should consider questions like ‘ What type of external interface will be needed?’ Users need a graphical interface that’s easy to manipulate and use. In design, an external interface should be dealt with before moving to the next stage (Blanchard, 2004, p. 134).
Maintainability or availability of maintainers is highly dependent on programming language used. Project team ought to ask itself the question ‘What programming language to use?’ A programming language used should be relevant in the market and allow future maintainability of the program.
Organizational Models
Several system development methods exist. This model works better in different environments and has similar working characteristics.
V-Shaped Model, this model involves the program being executed in a linear sequential method. At every stage, execution is completely performed before the next stage is involved. In this model, testing is performed at every stage to eliminate bugs and it’s performed early during program development.
Water Fall Model, is the method that is mostly used in system development. It is used because of its simplicity of use. The program development at every development stage has to be complete before the next step is worked upon. This method of development is flexible. However, a program is not functional until the whole program is fully developed.
General Model, this model involves producing deliverables that are required in the stages of program development (Lewis, 2000, p.83). These deliverables are then transformed into design. The code is then translated into the program during program testing and implementation. Testing for this model verifies the deliverables of the implemented phase.
Test Designs
Input Domain test, this testing involves data structures and logic elements in the program being tested (Lewis, 2000, p.97). Data structures are inputted into the computer system and the results are known, if there is a bug, the system halts. Data structure makes up the attributes of each identity and data represented in the program.
Program Logic test, the flow of program direction is tested singly one at a time. The complexity of the flow determines how the correctional procedure has to be implemented. In this method, a program module follows a unique path that every unit is allowed to pass through the path to attest to its authenticity and error-free (Lewis, 2000, p.104).
User Interface Test
User Interface testing involves testing the user interface with usual and unusual input. It’s performed to see ascertain the quality of the system. It is made up of user-based and functional testing of the system which is inputted through the user interface (Lewis, 2000, p.112). It’s done to determine if capability and reliability of the system.
Control Models
Interrupt control model. This model is centered on interrupts. It involves events relying on information to interrupt handler and their actions being determined by the handler. This model tends to be fast and flexible because it optimizes speed and it facilitates quick responses to the system events. But, it’s very hard to debug when an error is noticed Lewis, 2000, p.122). Interrupt-driven control systems are mostly used where instant response is needed and in emergency situations.
Broadcast control. The execution of this event involves broadcasting; this is where an event tends to communicate from a far distance. The event handler broadcasts the information to the available entity and that any component that is free to handle that event can respond to it. Many components can be made to interact with one another despite the location (Lewis, 2000, p.136). Nevertheless, there are uncertainties because some components are not sure when their events will be acted upon.
Interface Testing
Interface testing is an important aspect of the system development cycle. It facilitates and justifies the importance of having the new system in place. This is because it helps the project team and management to see if the requirement that was outlined in the terms of reference has been achieved. The system needs to be subjected to interface testing because sometimes errors pass through other testing checks without being realized. Due to detailed tests involving three phases, it makes it harder for errors to pass undetected.
References
Blanchard, B. S., 2004, System Engineering Management, John Wiley and Sons, New Jersey
Galin, D., 2004, Software Quality Assurance: from Theory to Implementation, Pearson/Addison Wesley, London
Lewis, E. W., 2000, Software Testing and Continuous Quality Improvement, CRC Press, Boca Raton, FL
Mezgá, I., 2006, Integration of ICT in Smart Organization, Idea Group Inc (IGI), Maryland
Webb A., 2003, The Project Manager’s Guide to Handling Risk, Gower Publishing Ltd, Hampshire