Quality Assurance
Quality assurance is very vital for designing and developing valuable software. Quality assurance is important as it ensures the organization identifies its real needs and provides justification for having a quality solution that can enable the organization to achieve its business software management requirements. To have a better functioning and up-to-date software solution, quality has to be embraced in its development. This ensures that it will perform to its best and for the organization to get sound results out of it. Several quality standards to facilitate this are of paramount importance. Reliability of the software is one key concern; the software should be able to perform the tasks that have been formulated in the feasibility study and analysis stage (Nee, 1996, p. 12). The software should be understandable and clear to the user.
The language employed in developing and its design should be simple and easy to understand. Proper detailed documentation should be provided to enable both the users and the management to fully understand what is needed in the program (Nee, 1996, p. 58). The program should be complete i.e. all codes input and parameters used to design it should be included and made available. The program should be portable and also it should be able to run on multiple hardware and operating systems with different configurations. Maintainability of the program is also of vital importance (Nee, 1996, p. 55). Moreover, the program should be able to accommodate future updates and current changes. A good program utilizes the system memory, hard disk space and other resources for efficiency (Nee, 1996, p. 57).
Cost Considerations
Costs in developing a new system when not budgeted for correctly can result in the process not going on well as planned. To facilitate the smooth take-off of the project and to keep the costs at minimum checks have to be instituted to prevent recurring expenses during system development and hence realize quality work (Lancrin, 2007, p. 12). There should be clear and well-documented requirements. With clear functions defined there is less vulnerability of the system being delivered which does not meet the user’s expectations this will prevent a situation whereby the system has to be reworked upon (Lancrin, 2007, p. 13). Testing of the system should start early during the design stage. This should be done with programmers who know how to test it effectively and with proper testing skills. Testing is done in conjunction with the designers of the system to ensure that the system fulfills its intended objectives.
Software for Self Assure
The Self Assure Company experiences costs on laser, Ink cartridges, paper and office stationery. This is a result of every aspect of a client’s policy and claims forms being printed. This has been costly in terms of purchasing the stationary and the ink cartridges. To enable Self Assure to bring down these costs, the automation of these services will be of great help. Software to track down and monitor prints when employed will greatly create a print-free environment whereby only vital documents will be printed hence creating a paperless environment. Software to track printing, store clients’ policy, and claims in a database will help Self Assure to cut down the costs of stationery and the amount spent in buying the ink and laser cartridges.
Major Risks
In program development, there sometimes occur seen and unforeseen risks. But to deliver a quality and dependable system, these risks have to be understandable. Benefit-risk is one of the risks that are associated with project development (Thornton, 2004, p. 36). This risk occurs when the new system developed does not meet the expectation of the user’s business needs and requirements as based on problem definition. His/ her requirements are not met and the whole process has been a waste of time and resources. This is such a scenario that even if the system is brought in it’s not able to perform based on users’ expectations and it’s prone to underutilization making it obsolete. This risk is brought in circumstances where the project activity to develop and design the new system exceeds the limits of the budget available and so it needs more time for it to be complete. Communication risk is another common risk to contend with when developing a software program (Thornton, 2004, p. 33). When giving information for the new system, the customer has to communicate clearly what the new system should do. He/she has to specify the needed requirements and the expectation which the program has to deal with. The information should be submitted timely. Technology risk is also a major risk (Thornton, 2004, p. 38). Improper specification of the most useful important technology available in the market can cause huge impact on the project. The technology employed should be relevant to the market; it should be compatible with the market and allow room for future updates and maintainability.
To prevent the occurrence of risks, clear checks should be employed. Sound feasibility and problem analysis should be clearly and deeply be done and comprehended before the actual design is started, precise input, output and processes have to be considered to ensure that the system has the expected development tools to enable exact system development (Thornton, 2004, p. 21). Delivery risk should also be considered. An apt guideline has to be formulated and a financial resource has to be put aside for the project and team members. A time frame should be drawn to enable the team and the customer to know when to expect the results. This will ensure that system development has enough budgets for its operations and a clear period to complete the project. Proper feasibility research will help in eliminating technological risk; the team should have a clear programming language that is already available in the market and which will be easier for upgrading and maintenance in the future when a new expansion is needed (Thornton, 2004, p. 32).
Quality Plan
For delivering an efficient system, quality is of the essence. Several quality plans have to be factored in or put into consideration towards the development of a properly functioning system. This is important to enable the organization to feel assured that what they have is what was expected.
Requirement definition
The first step in creating a quality plan is clearly defining the objectives and goals of the new system. The project should also be in line with the formulated company missions and guidelines; this will facilitate program practices that have to be re-engineered before or during implementation to be aptly considered.
Architecture
The system should reflect the technological changes that are already in the market. The design and installation of the system should conform to the nature and current of the business which will allow future improvement when new changes are introduced.
Formal education
Formal education for implementation should be considered. Planning and scheduling time and resources should be provided or included in the project. Good curricular and the mechanism for delivering to the target audience should be known. If the users of the system are to be involved, resources and training support should be defined.
Design reviews and code inspections
Design reviews and Code Inspections should be done and if errors are detected should be worked upon and acceptable standards established. Change should be developed by the company and appropriate actions taken.
Project planning
It’s important to plan the project at every phase because it helps the development team to assess its viability and develops an exact system based on the facts and information gathered. This is paramount and ensures that all the stages outlined in program developments are followed to the latter. Planning offers the opportunity to soundly plan, set the project on course and monitor the progress (Barkley, 2007, p. 123). An appropriate statement of work detailing the whole project plan should be reviewed and put together for approval by the management to eliminate any hitches when the work is in progress. This is important because it will serve as a record and a check back for your original plan when a certain change needs to be effected (Barkley, 2007, p. 123). Sometimes it will serve as a defending tool for yourself when the management questions why the project has taken longer than expected.
If the plan is to affect the end-users, a user acceptance training contract should be used whereby the users should be willing to read and sign, in cases where there might be reluctance from them(Barkley, 2007, p. 130). If some issue crops up during testing, and then you could point it to either user who didn’t realize it although it’s normal. And this would serve to defend you in case such scenarios happen. Any successful project planning is all about preventing the occurrence of the system not performing to the expectation and the earlier it’s covered the better the desired results (Barkley, 2007, 133).
Qualities of a Good Manual
A good system has to have good and understandable documentation to facilitate a proper understanding of the system. For quality to be achieved for manual justification, the manual should describe the system fully and explain how the quality requirements are to be met by the system. It should also offer a sound guideline for implementation and serve as a clear definition of the developed system. The manual should also be in a position to teach about quality requirements to those who are involved, especially the users and the management. It should offer quality practices pertaining to control and other management activities within the company.
The Manual for Self Assure should have a title, to indicate what the manual is all about. It should again have a table of contents to outline what topics the manual has and brief discussion of the same. It should also have a manual overview and why it was designed. The manual should in addition have the company introduction detailing what the company is engaged in. the quality policy and objectives should also be part of the manual to elaborate the strength of the system that has been developed. A reference list should be provided to check for words or phrases which are complex or understandable.
Referencing Facility
A well-referencing facility should be well-drawn and documented. It should show a clear picture of what the system can do and what the system cannot perform. This system has to manage print jobs, handle customer policy applications and customer claims. For the system, only vital reports will be printed and other applications will be stored in the company’s database system, this will cut down the cost of ink and papers creating a paperless office. Only the authorized personnel will be allowed to print vital documents by authorization from the management. The system documentation will contain detailed specifications, policy applications, claims, types of prints to be printed, and quality assurance manual and its operational procedures which meet international standards and code of ethics
TimeLine
Self Assure project will take more time for it to be implemented. The timeline below shows a breakdown of the implementation tasks into the more manageable time frame:
Design stage Questions
The design stage is critical in the design of the new system. Several questions have to be asked regarding the system. The external interface of the system has to be asked (Wang, 2002, p. 39). It can not be controlled but some interfaces that cross the boundaries like programming languages need a special mention and special considerations. The external interface should be dealt with before moving on with the program design. The user of the system, this is another question to ask you when in the design stage. Assess your user’s ability to use the system, more professional users have demanding requirements than ordinary use (Wang, 2002, p. 41). It is also important to consider if the system will need a database or not. If it needs a database, another distributed interface will come in handy (Wang, 2002, p. 50).
The components to use are also a major consideration. You have to know what components to use and the components that the existing project is likely to be reused in the future. Care should be exercised in their reuse because it may be hard to make the current system infeasible (Wang, 2002, p. 56). The security policy of the project is also a concern during the design stage. Proper security has to be constructed into the system. It’s good if they are integrated and tested along with the system (Wang, 2002, p. 60).
Organizational Modes
There exist a variety of software engineering methodologies that are currently used to develop systems. And they clearly describe the phases and order in which they are executed, different models work better for different platforms. But they all have a similar pattern.
General Model
In this mode of software engineering, its development produces deliverables that are required in the next stage of system development (Wasson, 2005, p. 50). The requirement is transformed into the design. The code is then translated into the program during program implementation. Testing for this model verifies the deliverables of the implemented phase (Wasson, 2005, 66). The core business information is collected in this phase and it’s where the project lies.
Water Fall Model
This is the common and modern form of system development life cycle. It is approach is simple to use and understand (Wasson, 2005, p. 66). In each phase, the program has to be completed in its whole before the preceding phase begins. It’s simple and easy to use, easy to manage due to the inflexibility of the model. However, there is no working software that’s produced until all stages are complete and amount to high risks (Wasson, 2005, p. 68).
V-Shaped Model
In this model, a sequential path of program execution is followed. Each phase is completed before the next stage is embarked on. In every stage, testing is done to eliminate the risks of bugs (Wasson, 2005, p. 80). A test plan is developed in its early cycle before coding is done.
User Interface Test Case
This involves testing the graphical user interface of the product to determine if the system performs its intended objectives correctly (Wasson, 2005, p. 45). It includes testing the system with usual and unusual input; this is done to determine its reliability and efficiency. It is made up of user-based and functional testing of the system via the user interface.
Program Logic-based test design
In this testing; the program flow path is tested uniquely at least one at a time (Wasson, 2005, p. 52). In this testing procedure, the complexity of flow determines the actions that have to be taken.
Input Domain-based test design
In this form of testing, data structures and logic are the key elements forming up the program (Wasson, 2005, p. 53). The data structures modeled in form of data models makes up the input procedures of the system. It describes the entities and corresponding relationships in the program and defines the attributes of each entity and the data.
Control Models
We have two types of event-driven controls models that are common. The first one is the Broadcast control model. In this model, the event being executed is based on broadcast where communication of the events tends to spread over a wide area. The event handler broadcasts the information to available components and that any company that is allowed to handle that event can respond to it. Its advantage is that it is a quick way of responding while being flexible and that any component can interact with one another without knowing its location or name. However, some components are not sure when their events will be handled.
The second type is the Interrupt driven control model. Here, the events are centered on the concept of interrupts and how these interrupts are passed to interrupt handlers. In some situations, interrupts can be similar to event handlers, that the control events. The advantage of this is that there is more fast and flexible because it optimizes speed and it facilitates quick responses to the system events. However, it’s very hard to debug when an error is noticed. Interrupt-driven control for real-time systems is mostly used where the instant response is critical. The interrupt control model is used in processes of emergency conditions such as in security checks and violations.
Interface Testing
Interface testing is the merging and testing of programs to see if they perform to the desired objectives (Lewis, 2000, p. 22). I think the program must be subjected to interface testing because some errors would have slipped through without being noticed since interface testing involves three phases of testing; program integration, subsystem integration and system integration and each phase has been designed to keep check against specific errors (Lewis, 2000, p. 37).
References
Barkley, B., 2007, Project Management in New Product Development, McGraw-Hill Professional, New York
Lancrin, S. V., 2007, Cross-Border Tertiary Education: A Way towards Capacity Development, OECD Publishing, Paris
Lewis, E. W., 2000, Software Testing and Continuous Quality Improvement, CRC Press, Boca Raton, FL
Nee, P. A., 1996, ISO 9000 in Construction, Wiley-IEEE, New Jersey
Thornton, A. C., 2004, Variation Risk Management: Focusing Quality Improvements in Product Development and Production, John Wiley and Sons, New Jersey
Wang X. J. 2002, What Every Engineer Should Know About Decision Making Under Uncertainty, CRC Press, Boca Raton, FL
Wasson, S. C., 2005, System Analysis, Design, and Development: Concepts, Principles, and Practices, John Wiley and Sons, New Jersey