Abstracts

As stated in the case study of Hi-Tech Company. Which in the context is all about regarding HiTech Corporation, Hi Tech is a company that produces generic software control system devices for a class of digital devices. Recently the customers that patronise the company product are said to have reported many issues regarding the Hi Tech product quality which are loss of availability, loss of specific service, or erroneous service and product with defects. Hi Tech implements spiral methodology to deliver the software in chucks. The release chucks typically 9-12 months each, the will be a need for a new software development methodology, so as to tackle the problem and bring in new improvement to the company. For them to meet up with new design features, each percentage increase of the product contains defects. The company does not remove or change the defects after release of percentage increase but it tries to remove defects at the end of developing complete or finish product. Every release of the Hi Tech product contain defect due to methodology of correcting there prototype product because the correction is only done when the product is finally design which is unable to correct the whole problem leaving some defects at the end of the software product. Due to these problems the company has gain high loss in availability and reliability, the company is known with an awful reputation of been reliable. Is it common logic that such issue arising in a software development enterprise cannot be a CMMI certificate or mostly a CMMI level 2. In order to let the organization overcome such issue and maintain customer satisfaction, the company itself should think and dream to be a CMMI-3 certified, where at this point in time, the software product will be released on time with very good quality, efficient, reliable, affordable and usable. It is accepted that if customers are satisfied, then definitely it show that the organization or the company as in this case. Hi Tech achieves the satisfactory quality build-in within the processes of the software product.

Aims and objectives

The aim of this paper is to analyze and evaluate the Hi Tech companys status using different models and technique through analyzing the current software and quality project assurance condition or problem of the company, and the problem behind getting affecting by these conditions. After evaluating critically, the author of the report will then suggest a software quality assurance plan (SQAP) standard approach for the company. The objective of this case study is to give a compressive solution with the implementation plan. The processes to the case study problem are as follow

Assumption
As the Hi Tech report, has already covered some of the key process areas (KPAs) of CMMIs level 2. The hi-tech company has 20 staffs working. The company also practice system development for business application and the software methodology they apply is spiral modethology. Therefore, most of these users usually comment on the system functionalities and they ask for further system improvement. In addition, development team of Hi Tech are well versed with object oriented programming language such as java and C++, and the company is also ready to purchase software tools for the purpose of reviewing and testing applications and systems. Problems Identification As said in the case study that Hi Tech software development process does not have a proper standard for developing software their products. The software development methodology being applied by the company is spiral methodology. Because of this Hi Tech requires methodology that will let the organization service well and achieve good change and results for the customers satisfaction.

Analysis of the current issues in Hi Tech Company

In analyzing of the case study can be done through evaluating of the company in terms of Hi Techs software Assurance plan (SQAP) perspectives. As we all know that system phil osophy is the best model of thinking about things like system (Schwable, 2009). These will quite us to understanding Hi Teach Company as a hybrid software manufacturing and service environment. And furthermore, particular models to tap the potential will be use. This Hi Teach report or the case study intention is to produce a quality system plan to ensure that each release is of sufficiently high quality with particular focus on the effectiveness of the

companys plan. It is clear in the case study that the main objective of Hi-Tech is to provide customer satisfaction by producing reliable quality products.

The Hi tech company report can be solve if a proper software quality assurance plan (SQAP) is applied in the implementation of the plan, if the performance of the software quality is measured, It is common logic that increases in customer satisfaction and business productivity derives from the production of high and standard quality services as in the case of the Hi Tech company.

Possible solution and analysis of some major quality model that can be applied to the Hi Tech Company
The problem of the Hi Tech cooperation can be tackled or solve with the software quality assurance related approaches such as McCalls quality Model, Boehms quality model, and ISO quality model. This shall form a basis for understanding how to deal with each particular problem and to recommend solutions. The analysis of the above mentioned models, the companys level of quality certification can be marked as higher level quality certified organization within near future. Software quality assurance plan (SQAP) will help Hi-Tech to improve its main areas of producing software products like standards of software design, standards of coding, tools and techniques and the relevant methodologies related with software development. After implementing SQAP on Hi-Tech it can be marked as a CMMI-level organization in the coming years in feature. SQAP will enable the Hi-Tech to improve their main areas of developing products such as coding standards, design standards, tools and techniques and software development methodology with the effectiveness of software quality assurance plan (SQAP).

Quality Models
Evaluation of quality models Three requirements that a quality model should possess to be a foundation for Software Quality Engineering have been identified: A quality model should support the 5 different perspectives of quality as defined by Kitchenham and Pfleeger (1996);

 A quality model should be usable from the top to the bottom of the lifecycle as defined by IEEE Std 1061-1998 (IEEE, 1998), i.e. should allow for defining quality requirements and their further decomposition into appropriate quality characteristics, subcharacteristics and measures; A quality model should be usable from the bottom to top of the lifecycle as defined by IEEE Std 1061-1998 (IEEE, 1998), i.e. should allow for required measurements and subsequent aggregation and evaluation of obtained results. Four quality models will be evaluated with respect to these requirements. McCall McCall (McCall, Richards & Walters, 1977) introduced his quality model in 1977. According to Pfleeger (2001), it was one of the first published quality models. Each quality factor on the left hand side of the figure represents an aspect of quality that is not directly measurable. On the right hand side are the measurable properties that can be evaluated in order to quantify the quality in terms of the factors. McCall proposes a subjective grading scheme ranging from 0 (low) to 10 (high). Regarding this model, Pressman notes that unfortunately, many of the metrics defined by McCall et al. can be measured only subjectively (Pressman, 2001). It is therefore difficult to use this framework to set precise and specific quality requirements. Furthermore, some of the factors and measurable properties, like traceability and self-documentation among others, are not really definable or even meaningful at an early stage for non-technical stakeholders. This model is not applicable with respect to the criteria outlined in the IEEE Standard for a Software Quality Metrics Methodology for a top to bottom approach to quality engineering. Furthermore, it emphasises the product perspective of quality to the detriment of the other perspectives. It is therefore not suited as a foundation for Software Quality Engineering according to the stated premises.

McCall quality factors and sup factors

Dromey has built a quality evaluation framework that analyzes the quality of software components through the measurement of tangible quality properties. Each artifact produced in the software lifecycle can be associated with a quality evaluation model. Dromey gives the following examples of what he means by software components for each of the different models: Variables, functions, statements, etc. can be considered components of the implementation model; A requirement can be considered a component of the requirem ents model; A module can be considered a component of the design model; e.t.c According to Dromey (1995), these components all possess intrinsic properties that can be classified into four categories: Correctness: Evaluates if some basic principles are violated. Internal: Measure how well a component has been deployed according to its intended use. Contextual: Deals with the external influences by and on the use of a component. Descriptive: Measure the descriptiveness of a component (for example, does it have a meaningful name?).

Dromeys Quality Model These properties are used to evaluate the quality of the components. : Dromeys Quality Model : Quality evaluation of a variable component

It seems obvious from the inspection of the previous figures that Dromey's model is focused on the minute details of quality. This is stated explicitly: What we can do is identify and build in a consistent, harmonious, and complete set of product properties (such as modules without side effects) that result in manifestations of reliability and maintainability. (Dromey, 1996) For Dromey, the high level characteristics of quality will manifest themselves if the components of the software product, from the individual requirements to the programming language variables1, exhibit quality-carrying properties. Dromey's hypothesis should be questioned. If all the components of all the artifacts produced during the software lifecycle exhibit qualitycarrying properties, will the resulting product manifest characteristics such as maintainability, functionality, and others? The following analogy will be useful in answering this question: If you buy the highest quality flour, along with the highest quality apples and the highest quality cinnamon, will you automatically produce an apple pie that is of the highest quality? The answer is obviously negative. In addition to quality ingredients, at least three more things are needed in order to produce an apple pie of the highest quality: A recipe (i.e. an overall architecture and an execution process). Dromey acknowledges this by identifying process maturity as a desirable high level characteristic. However, it is only briefly mentioned in both his publications on the subject (Dromey, 1995; Dromey, 1996). The consumer's tastes must be taken into account. In order for the result to be considered of the highest quality by the consumer, it needs to be tuned to his tastes. This is akin to what is commonly called user needs in software engineering. User needs are completely ignored by Dromey. However, as it was demonstrated in the introduction, they are an integral and non-negligible part of software quality. Someone with the qualifications and the tools to properly execute the recipe. While Dromey's work is interesting from a technically inclined stakeholder's perspective, it is difficult to see how it could be used at the beginning of the lifecycle to determine user quality needs. Dromey (1995) states that software quality must be considered in a systematic and structured way, from the tangible to the intangible. By focusing too much on the tangible, Dromey fails to build a model that is meaningful for stakeholders typically involved at the beginning of the lifecycle. Do end users care about the variable naming convention or module coupling? In most cases, it is doubtful that this question can be answered affirmatively.

Therefore, this model is rather unwieldy to specify user quality needs. This does not mean that it cannot be useful later on as a checklist for ensuring that product quality is up to standards. It can definitely be classified as a bottom to top approach to software quality.