The Role of Information Technology Studies in Software Product Quality Improvement

The Role of Information Technology Studies in Software Product Quality Improvement RUDITE CEVERE, Dr.sc.comp., Professor Faculty of Information Technologies SANDRA SPROGE, Dr.sc.ing., Head of Department Studies Centre Latvia University of Agriculture Liela Street, 2, Jelgava LATVIA rudite.cevere@llu.lv sandra.sproge@llu.lv http://www.llu.lv Abstract: - This paper deals with problems associated with software product quality improvement activities. Software nowadays is a part of different information systems and therefore participates in functioning of many sectors. Thus, directly or indirectly, its quality may affect performance of the whole industry. In the information technology sector a lot of attention is paid to Software Quality Assurance. But, as it is not feasible to develop a program that does not contain errors, methods and techniques of software quality improvement are still being developed intensively. Based on years of experience in IT companies, the article discusses quality improvement activities that were successfully implemented in practice in development processes. This experience has shown that the improvement would be desirable, starting from the information technology study courses. During the studies students should already develop knowledge of the possible effects on a variety of software product quality attributes. The inclusion of quality assurance elements into the courses is carried out on the basis of experience gained during implementation of quality system requirements in the software development processes in IT companies. Practical observations in the development processes in IT firms, and in information technology studies show that a combination of experiences and interchange of best practice in both areas may give possibility to improve the students' knowledge. Therefore raising the qualification of software development staff in software quality issues is one of the ways, how to increase the quality of software itself. Key Words: - Quality Requirements, Software Product Quality, Quality Systems, Internal and External Quality Model, Quality Assurance, Study Programme, Study Courses 1 Introduction Specialists of information technology are in great demand today in Europe and globally. Consequently, the information technology (IT) education also is paid a lot of attention internationally. EURO-INF Framework Standards and Accreditation Criteria for Informatics Degree Programmes can be referred to as one of examples of such efforts. It defines the requirements for the knowledge and skills that must be learned in Bachelor and Master studies. They have been ranged in the following four categories: Underlying Conceptual Basis for Informatics; Analysis, Design and Implementation; Technological and methodological Skills, and Other Professional Competences. The standard also provides detailed recommendations for each of these categories of requirements [1]. However, the information technology sector is characterized by its extremely fast-growing. For students of the Bachelor s study programme the situation in the IT sector at the end of the study can vary greatly in comparison with that was at the beginning of the study. There is also a very large number of information technology methods and tools, which could be taught during the study period [2]. Only the number of programming languages known in the world is around 500. In addition to direct software development tools and technologies, software engineering methods which gather software development best practice are also important. The number of these methods and recommendations is also very large. Thus, the question of what and how exactly to teach in information technology study programs is a very topical issue of the sector. ISBN: 978-1-61804-276-7 110

Quality assurance is another issue that is difficult for learning. As information systems (i.e., applications) are used in all spheres of life, their quality can affect significantly the progress of each sector. A wide range of concepts and terms is found in software development related to quality: quality assurance, quality certification, quality evaluation, quality improvement, quality measurement, quality systems, quality models, quality standards, etc. Typically, in each case, an understanding of quality can be different [3]. Analysing the software life cycle, you can see that the first errors and deviations from the required quality of software occur during the development processes. The employees engaged in creation of programs are one of the main causes of it. In order to improve information technology studies, detailed recommendations have been developed in the current paper. We tried to define what knowledge of the quality of software product should be learned in a Bachelor study programme, and how teaching of the courses should be organized. The aim is to improve the professional training of future IT specialists by creation a single view to the quality throughout the whole software life cycle. The proposed solution shows how to ensure the path to the software product quality through study programmes. 2 Problem Formulation Thinking about improvement of IT studies, the views of the two main stakeholders should be taken into account. On the one hand, it is an existing or potential employer (IT firm) in real software development projects. On the other hand, it is a higher education institution with the undergraduate study programmes and students or potential workers in the information technology sector. The recommendations described in this article are based on the more than 15 years of practical experience in information technology companies and universities. Software development starts with requirements specification, during which it is necessary to define the quality requirements, too. In accordance with the standard ISO/IEC 25030 [4] software quality requirements are defined, identifying and analysing quality needs of all stakeholders. We face with the first difficulties here, because the needs formulated by users do not always reflect the real needs. The individual user may not always know his real needs. Needs may change after they have been defined, different users can have different operating environment, and it may be impossible to consult with all possible kinds of users. Software today should be considered as a part of a larger system. Around each system throughout its life cycle a great diversity of stakeholders exists. The stakeholders of a system include all persons (for example end users), organisations (end user organisations or development organisations) and bodies (statutory and regulatory authorities or the general public) having a legitimate interest in the system. Each of the stakeholders has its own needs and expectations in relation to the system, as well as its own quality requirements. Standard ISO/IEC 25030 reflects the sequence of activities of gathering and analysis of the information for quality requirements definition (Fig 1). Fig.1 Software quality requirements definition and analysis [4] Although formally the requirements are defined by software acquirer, practically it is the work carried out by IT specialists, or at least in which they are closely involved. 2.1 Quality assurance experience in software development projects More than fifteen years of work related to quality assurance of software systems development projects in IT Company, have allowed to accumulate a great experience. The main issues of it are listed below. 1. IT development companies pay much attention to quality issues due to specificity of the product and marketing reasons. Company-wide common solution of quality issues is development of a quality system. Quality systems in accordance with ISO/IEC 9000, ISO/IEC 20000, ISO/IEC 27000 series of standards, as well as the requirements of other Standards are widespread and have proved their usefulness in IT sector. The importance of IT industry in quality systems sphere is also demonstrated by the development of specific standards. The basic standard in ISBN: 978-1-61804-276-7 111

ISO/IEC 9000 group is ISO 9000 - Quality management. In addition, there are specific interpretative standards of quality systems for IT companies: 90003:2014. Software engineering -- Guidelines for the application of ISO 9001:2008 to computer software, and Certification program TickITplus. TickIT is a guidance document which explains ISO 9001 for specific application to software development. 2. An expertly designed quality system is the first thing that is necessary for its effective operation. Just as important is the senior management understanding and support of the implementation of the system in all development processes. One of the shortcomings observed in practice is an attempt to force all employees to talk in terms of quality and the introduction of new quality documents and records. Practical experience has shown that an effective implementation of a quality system is a user experience approach. It means that there is no need to impose a new agenda and a new terminology to all project members. Quality Manager should help people to find the required quality activities in the existing operation of the projects. 3. With regard to the information to be recorded (quality documents and records), the most important thing is to identify time and place of emergence of the necessary information, and to create a more rational form of its documentation. This approach means that development of a separate quality assurance process requires identifying all activities of the primary processes in which information relevant for quality occurs. Identified development activities, if necessary, should be supplemented by a small additional activity for quality assurance needs. 4. In order to understand this approach, let's look at implementation of one of the support processes. Configuration management is one of the most important project support processes for the successful operation. Its main task is storage and version control of the project items. Procedures, actions and type of information to be maintained should be determined by the quality manager. The process is implemented by all other project staff during development of the project intermediate results and deliverables. For process realization small activities (mini tasks) are detected, which complement the software product development activities. Quality activities and the performers are as follows: Quality Manager - prepares a project repository, develops the form of identifiers and file names of projects items, implements configuration control; Systems Analyst - assigns a specific identifier to deliverable documents, gives determined file name, stores the document in the repository in a certain way; Programmer - gives a specific identifier to the program item, gives a determined file name, stores the item in the repository in a certain way. 5. The aim of the quality system is based on the principle that there is a greater expectation that the quality of the end product will be better if the development process is qualitative. According to quality conception described in standard ISO/IEC 9126 [5], the quality of life cycle processes defined in ISO/IEC 12207 [6], helps to improve the software product quality, and the quality of a software product helps to improve software quality in use. Of course, it is impossible to verify this idea, but a long and successful use of quality systems in IT companies, may be an indirect evidence that it is true. At the same time, it should be noted that during the development and implementation of quality systems nobody talks about quality of software product, produced in these qualitative processes. 6. There is not a single view in software projects about what a software quality is. Quality attributes are often discussed separately from the functional requirements. Quality is usually defined as attributes of the designed system (or software), such as the correctness, reliability, availability, maintainability, security, and portability. The extensive use of standardised software product model ISO 9126 in practice is not observed. Having regard to the fact that these attributes (or in standard terminology, quality characteristics) may be interconnected and contradictory, insufficient attention is paid to the determination of priorities. 7. Often a different understanding may exist between the client and the developer of the software quality definition. In addition, customers often define their quality requirements insufficiently accurately. It is possible that customer s quality requirements appear only when starting to use the program. ISO 90003 standard requires IT companies, to "ensure that its personnel are aware of the relevance and importance of their activities and how they contribute to the achievement of the quality objectives". IT companies undoubtedly ISBN: 978-1-61804-276-7 112

contribute to the professional development of their employees, but it's more to do with new programming languages, technologies and mastering of new tools. 8. Implementation of functional and quality requirements by software project staff is often considered as two independent tasks, rather than two components of a single task. Development staff should change the perception from "to write a program which allows you to enter the electronic declarations and to realize the requirements of safety and high-speed operation to to write a reliable program that allows you to enter the electronic declarations with sufficiently high speed. 9. It has been observed, that the more experienced project staff shows a relatively greater opposition to introduction of new working methods or forms of documentation required by quality assurance, and to use new or different terminology. 10. The quality requirements cannot be fully defined before the product design. As functional and other software requirements, they are gradually detailed throughout the development processes. At the same time, the definition of quality requirements should not be overstated. It is not the aim to achieve perfect quality, but to achieve the necessary and sufficient quality in the context of the use, to meet the real needs of the user. In summary we can say that the quality management system operates successfully if all quality assurance processes are integrated into the development primary processes, without putting to them troublesome large additional actions. Assessment and improvement of the processes can be the means for the product quality improvement, those are still not used sufficiently. It should be noted that for young professionals starting to work in real software projects, it would be useful to have a better basic knowledge of software quality and possible measures for its improvement. 2.2 Quality Assurance Acquisition in study process Tasks, that need to be addressed to software developers to implement defined or indirectly identified quality requirements of the software, require from the involved staff to master specific knowledge and skills in the quality assurance issues. As mentioned above, in many cases, the level of these skills is not sufficient. Undergraduate study programs of Information Technology almost always include courses in basic IT skills and knowledge: programming, databases, computer networks, system analysis and modelling, and project management [7]. Implicitly, the courses, that teach the quality assurance, are also included. They talk about individual activities, like process quality assurance, verification, validation, risk management, inspection or testing. The software product quality is also included, but, like the development projects, the quality features are treated as separate software requirements. This leads to a detachment of basic development activities from quality of the result. In order to improve the final product quality indicators in software development projects, it would be desirable first of all to improve information technology study programmes. The foundations should be placed for a strengthened usage of common software product quality model, the integration of quality assurance activities into software development primary processes, and creation of the perception of the development as a decision-making process. 3 Problem Solution Analysing the real progress of software projects, it is evident, that during the software development processes it may be necessary for all employees continuously to accept smaller or greater decisions at all levels. Usually, decision-making is based on the specific requirements of a task. In order to make this process more integrated, we propose to look at the entire software development as a continual decision-making process. As the main criterion for each activity its impact on the quality of the end product may be chosen. 3.1 Decision-making process in a project Traditional decision-making process consists of the following steps [8]: 1) Define the problem or goal, 2) Gather the necessary information, 3) Identify possible alternatives, 4) Assess alternatives, 5) Choose among alternatives, 6) Implement, 7) Reassess. Let us look at the situation when in the IT company, development or maintenance of specific software or system is being organised by the project principle. Each project may have another customer. In this case, the first step of the decision-making process must be establishing a common framework for the whole project: ISBN: 978-1-61804-276-7 113

1) Define the problem or goal. From the total system or software requirements choose clearly defined and indirectly perceived quality requirements. It is recommended, that you choose a quality description form that can be used during the entire project life cycle, for example, the quality model defined in Standard 9126. Determine quality features essential for a specific project, and rank them in order of importance 2) Gather the necessary information. The main part of information should be searched within the project, mostly in contract and requirements documentation; some information may be found in the company's project database (repository). 3) Identify possible alternatives. Information about similar situations (assurance of similar quality indicators) can be found in the company's project repository (history database). Alternatives can be built using other quality features or different ranking. 4) Assess alternatives. Evaluate all available resources necessary for implementation of the various alternatives (personnel, methods, software tools, hardware, etc.). Determine which tasks will be monitored for quality improvement of the particularly chosen feature and what verification activities will be taken (measurements, testing, inspection, etc.). 5) Choose among alternatives. In the result of the evaluation, quality features and their ranking are selected and co-ordinated with the customer. In practice it may be a part of the coordination of project requirements. 6) Implement. Execute the established procedure during development of the first deliverable. 7) Reassess. Evaluate the progress of the development and the quality of the obtained results and determine benefits and disadvantages of the development. If necessary correct the decision-making for future development. Further every development process of the project can be organized according to this established procedure. For example, during coding according to the defined quality requirements different source code constructions can be used to improve the speed of operation, safety, understandability or maintainability of the program. The described approach may be feasible for any project regardless of the development life cycle model. It does not require all the project staff "to speak in terms of decision-making". This approach mainly can be realized through review and testing processes by including the necessary questions in the review checklist and preparing the appropriate test cases. For example, the software requirements specification review checklist may be supplemented by the following questions: 1. Are the product quality requirements defined clear enough: 1.1. - reliability 1.2. - usability 1.3. - efficiency 1.4. - maintainability 1.5. - portability 1.6. - other quality requirements It must be noted that the staff should be more or less prepared for this type of development. During implementation of the real project developers must take into account the project deadlines and specific limitations. This is not the time when you can deal with staff training of such kind. The foundations of knowledge should be placed already during the study period. 3.2 Quality requirements acquisition in study process As mentioned above, the development of a quality system is based on an assumption that there is a greater expectation of obtaining high-quality software products if development processes are of better quality. Similarly we can assume that the software product quality can be improved if we involve in the software development young specialists who during their studies along with programming techniques have mastered the impact of programming decisions over software quality. When you are working in a given project you may not be able to devote additional time and resources for staff training in quality characteristics and their interactions. The study process is the first step in the education of young specialists. If the content of existing study courses is supplemented with small additional information it will be possible for students to learn the importance of software product quality, its impact and assessment methods in all special study courses related to software development [9]. In order to realize such approach, determination of the quality characteristics useful for acquiring in the particular courses is necessary. For that purpose useful information can be obtained from the feedback of the software quality in use to the study programme (Fig 2). ISBN: 978-1-61804-276-7 114

Curriculum Software Software quality in use characteristics Table 1 Matrix of mutual influence between study courses and quality characteristics Course 1 Course 2 Course 3 Fig.2 Mutual influence of study programs and software quality A Matrix of mutual influence between study courses and software product quality characteristics was developed. Characteristics of the software product quality are taken from the software quality model defined in Standard ISO 9126 (Fig.3). Names of special study courses included into the matrix are taken from LUA IT undergraduate study programs. Functionality Suitability Accuracy Interoperability Security Functionality Reliability Maturity Fault tolerance Recoverability Reliability Internal and external quality Usability Understandability Learnability Operability Attractiveness Usability Efficiency Time behaviour Resource utilisation Efficiency Maintainability Analyzability Changeability Stability Testability Maintainability Effectiveness Productivity Safety Satisfaction Portability Adaptability Instability Co-existence Replaceability Portability Fig.3 Software internal and external quality model [5] Analysing the relationships, a matrix of mutual influence between quality characteristics and study courses has been developed. This matrix is designed to help to determine which quality characteristic should be taught in more detail in which courses. Sequence of analysing the feedback from the quality in use until the study courses has been described in [X]. Eleven study courses were included in the matrix of mutual influence. The content of these courses is the most appropriate for additional training about factors influencing the quality characteristics of software product (Table 1). The study courses teaching on software development support and organisational processes are not among them (for example, Software Engineering, Software Project Management, Software Testing). These courses are entirely devoted to quality assurance and evaluation issues. The aim is to show how software quality assurance can be integrated into courses, the primary purpose of which is to teach programming techniques. In the following table (Table 1) with + are marked those courses in which the particular quality characteristic should be taught. Quality Characteristics / Study Courses Programming Fundamentals Windows Programming Database Access Applications Algorithms and Structures Database Technologies Large Databases Web programming WWW Technologies Data Security Computer Networks Administration of Computer Networks Functionality Reliability Usability Efficiency Maintainability + + + Portability + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + The Matrix of mutual influence shows that all quality characteristics should not be included in all study courses to the same extent. Each course should include only about one or two quality characteristics, modification of which can be demonstrated with examples. Thus, in relation with quality characteristic functionality study courses that teach programming should focus on quality subcharacteristics suitability and accuracy. For study courses that teach data bases and data protection, the most appropriate subcharacteristic to teach is safety. On the basis on the selected 11 study courses a survey at Faculty of Information Technology of LUA was carried out in 2013. The lecturers were offered to mark those quality characteristics and subcharacteristics in mutual influence matrix, assurance of which should be taught in a particular study course. The lecturers of all special study courses were involved in the survey. They were asked to assess all study courses related to programming and data bases, not only those taught by themselves. In total 12 lecturers of the Department of Computer Systems participated in this survey. ISBN: 978-1-61804-276-7 115

The results of the survey showed that the staff of the higher education institution has the opinion that each of quality characteristics could be taught almost in all study courses. Such method of implementation may be hazard for a study programme. If it is overloaded with quality issues then instead of improvement this could call the opposite effect. To avoid this, the modification was recommended for all programming and database design-related courses (Web Programming, Database Access Applications, Windows Programming, and Large Databases). Modification means that during the course on the bases on practical examples students are taught how and what affects a certain software quality characteristic (indicator, feature) improving and weakening it. For example, teaching the coding the necessity of comments and correct definition of variables and parameters are explained as a way how to improve the maintainability characteristic of the software end product. According to the lectures' opinion the greatest emphasis in the study process should be put on such software product quality characteristics as functionality, maintainability and usability. 3.3 Analysis of employers' point of view Throughout more than 10 years of functioning of LUA ITF study programmes have been developed and updated in close cooperation with employers. This allows to use the software developer practical experience in study process. Lecturers should know what the customers requirements to the final product quality are today. Developers experience provides information what activities are the most significant for software quality improvement during the development, and to what issues we should exactly pay attention during the study process. To check our ideas for conformity to production purposes, a similar survey as for lecturers, was also prepared for employees of IT companies. A survey was carried out in 2013 for the period from May to September. The questionnaire was sent to 30 companies, responses were received from 17 respondents, representing 11 companies (36.7). The questionnaire consisted of two parts: The first part was asking entrepreneurs opinion on the quality of the actual software product development projects. the second part was looking for the business point of view as to which quality characteristics it is necessary to pay attention in IT curricula. Since the names of all courses are well known to lecturers, in their questionnaires the opinion was asked directly about the specific courses. Such information could be confusing for employees, because they are not aware about a content of separate study courses. Therefore, in the survey for employees instead of 11 study courses 4 units of information were given: Algorithm development, Database development, Coding and Testing. These blocks cover content of all 11 individual courses. Employee s point of view about the importance of different development phases on software quality characteristic are summarized in the table below. Figures show how many % of employees consider that the particular development stage is essential for the quality characteristic. Table 2 Quality feature and study mutual relationship employers assessment Quality Characteristic Algorithm development Database development Coding Testing Functionality Suitability 41.2 52.9 41.2 41.2 Accuracy 64.7 58.8 58.8 52.9 Interoperability 17.6 17.6 29.4 29.4 Security 35.3 35.3 41.2 47.1 Reliability Maturity 11.8 11.8 11.8 17.6 Fault tolerance 35.3 17.6 47.1 29.4 Recoverability 11.8 17.6 11.8 11.8 Usability Understandability 23.5 0.0 35.3 35.3 Learnability 0.0 0.0 5.9 11.8 Operability 29.4 35.3 29.4 23.5 Attractiveness 5.9 0.0 11.8 29.4 Effectivity Time behaviour 11.8 17.6 5.9 11.8 Resource utilisation 29.4 29.4 23.5 17.6 Maintainability Analysability 5.9 23.5 17.6 0.0 Changeability 29.4 29.4 35.3 11.8 Stability 17.6 35.3 17.6 17.6 Testability 35.3 29.4 35.3 52.9 Portability Adaptability 11.8 11.8 17.6 11.8 Installability 23.5 23.5 23.5 11.8 Co-existence 5.9 0.0 5.9 5.9 Replaceability 11.8 5.9 11.8 0.0 ISBN: 978-1-61804-276-7 116

Data in the table shows that, in business professionals opinion the most important quality subcharacteristics include: development of algorithm: the suitability, accuracy, security, fault tolerance and testability; database development: suitability, accuracy, security, stability, and operability; coding: suitability, accuracy, security, fault tolerance, understandability, changeability, and testability; testing: suitability, accuracy, security, understandability, and testability. 3.4 Recommendations for the study process organization As a result of the described analysis recommendations have been developed on how to integrate issues of software end product quality into a study programme. Recommendations consist of two parts: Common organization of the study program; Topics inclusion in special courses. Study Programme Organization Bachelor study programs usually consist of special courses or associated blocks. In general, all the knowledge and skills that should be mastered by information technology specialists in primary education are taught in them. However, this type of a study program is a compilation of individual courses. What is missing is a common goal unifying all of them. In software development projects the fact that everyone is working on the creation of a common product consolidates individual employees in a team. On the bases of this experience we propose to organize the acquisition of a study programme in a similar way. It requires a little additional training of all lecturers involved in the programme implementation and substantial increase of the role of study program s director. The director of the study programme like the project quality manager determines the overall procedure of the study programme and the sequence of course acquisition. In addition he coordinates insertion of the additional topics about the software product quality modification in each course. These additional issues are taught by the lecturers during their classes. Activities of the study programme implementation and task performers are as follows: Program Director prepares recommendations for the sequence and interaction of study courses, develops a common framework for decisionmaking process that should be implemented in special courses, oversees the conduction of the study program; Lecturer teaches basic material of his course; presents some of the software product quality characteristics, prepares examples that illustrate how the characteristics can be changed (increased or decreased). Special study courses In order to prepare proposals for inclusion the change of quality characteristics in specific examples, it is useful to apply the metrics recommended by the standard ISO 9126. The model for software quality in use contains four characteristics: effectiveness, productivity, safety, satisfaction (Fig 2). So far we have looked at the feedback from software quality in use to the study courses. It is possible to use another feedback, too. It is a feedback from the quality in use to software external and internal quality [10]. Internal quality is the totality of characteristics of the software product from an internal view. Internal quality may be evaluated to a nonexecutable software product during its development stages (such as a request for proposal, requirements definition, design specification or source code). External Quality is the totality of characteristics of the software product from an external view. It is the quality when the software is executed, which is typically measured and evaluated while testing. The Model that describes the software quality in use stated the users' satisfaction as one of the most important characteristics. Satisfaction metrics measure the extent to which a product meets the needs of specified users to achieve specified goals with satisfaction in a specified context of use. Satisfaction is influenced by how the user perceives the software product features such as those measured by external factors (ISO 9126-4). Quality characteristics which improve the internal and external software quality in order to achieve satisfaction are usability and maintainability. According to the quality model, usability has four quality subcharacteristics: understandability, learnability, operability and attractiveness. Analysis of the metrics of these subcharacteristics shows that certain metrics are used only for measurement of internal or external quality, but most can be used in both cases (Table 3). ISBN: 978-1-61804-276-7 117

Table 3 External and internal quality metrics for usability External metrics Internal metrics Understandability Completeness of Completeness of description description Demonstration Demonstration accessibility accessibility Demonstration accessibility in use Demonstration effectiveness Evident functions Evident functions Function Function understandability understandability Understandable input and output Learnability Ease of function learning Ease of learning to perform a task in use Effectiveness of the user documentation and/or help system Effectiveness of user documentation and/or help system in use Help accessibility Help frequency Completeness of the user documentation and/or help facility Operability Operational consistency in use Error correction Error correction in use Default value availability in use Message Message clarity understandability in use Self-explanatory error messages Operational error recoverability in use Time between human error operations in use Undoability (User error User operation correction) undoability Customisability Customisability Operation procedure reduction Physical accessibility Physical accessibility External metrics Internal metrics Input validity checking User operation cancellability Operation status monitoring capability Operational consistency Interface element clarity Operational error recoverability Attractiveness Attractive interaction Interface appearance customisability Attractive interaction User interface appearance customisability Metrics can be applied to the assessment of all intermediate and end products created during the software development, such as software requirements specification, design description, user interface, software source code, and user documentation (Help). The metrics can be used for practical work in study courses to demonstrate the impact of particular activities on quality characteristics. Using such metrics during practical work means that in parallel with the main task execution students are also acquiring job evaluation and decision-making skills. For example, understandability metrics assess how new users can understand whether the software is suitable and how it can be used for particular tasks. One of understandability metrics can be Completeness of description. It can be used both as internal and external metric. Internal metrics is used to help answer the question what proportion of functions (or types of function) is described in the product description. It can be used to evaluate such intermediate products as a Software Requirements Specification, Design Description, as well as the information contained in Review Reports. External metrics can be used to evaluate software User Documentation or information contained in the Test Reports. It gives an answer to the question what proportion of functions (or types of functions) is understood after reading the product description ISBN: 978-1-61804-276-7 118

4 Conclusion It is impossible to achieve a complete software product quality in practice. Considering widespread use of software in all sectors of life and its impact on the effective functioning of each sector we must continue to seek ways to improve the overall quality. There is a need to strengthen the feedback between the software development companies and higher education institutions to improve information technology studies. The IT employers survey showed that the issues of quality development have become a part of the daily work, although in most cases it is realized as a separate list of quality requirements. Quality models recommended by software engineering standards are not being widely used in software development projects. At the same time, employers want to improve acquisition of the quality assurance issues of young professionals already during their studies. As the key moments, employers mention the following: young professionals should be familiar with the entire software development life cycle, quality requirements should be taught in close conjunction with the software development life cycle, in particular at every its stage; quality should be assured from the very beginning of the development process, not trying to improve quality of already developed objects; comprehensive assurance of the product (intermediate product) quality during the process of its development and before that in the planning process should be taught in each study course; a variety of quality control and assurance methods in different software development methodologies should be taught, in particular, test methods and automated testing tools; Students should learn that quality is a part of daily work of every project participant. Software project development experience in IT companies can be used as an example for the quality assurance activities inclusion into the study course content. Students should be taught to use a single software product quality model during the entire software life cycle. A systematic and purposeful decision-making should be demonstrated during acquisition of software development techniques and tools. Quality characteristics of the end product should be used as the criteria in decision making. The described approach of improvement of the study courses is beginning to be implemented in two bachelor degree programmes of Faculty of Information Technologies. Since it is not possible to conclusively assess the results of such improvement in a short term, it is intended to supplement a little an existing students survey to get at least a minimal feedback from students. References: [1] EURO-INF Framework standards and accreditation criteria for Informatics programmes. Version II, 2007, online at - www.kbs.cs.tu-berlin.de/ecss/docs/euro-inf.pdf. [2] IEEE Computer Society/ACM Joint Task Force on Computing Curricula: Software Engineering 2004: Curriculum Guidelines for Undergraduate Degree Programs in Software Engineering, online at - http://sites.computer. orgccse/se2004volume.pdf [3] Guide to the Software Engineering Body of Knowledge (SWEBOK), 2004, online at - http://www.computer.org/portal/web/swebok/ht mlformat [4] ISO/IEC 25030:2007 Software engineering Software product Quality Requirements and Evaluation (SQuaRE) Quality Requirements. International Organization for Standardization. [5] ISO/IEC 9126 1:2001 Software Engineering Product Quality Part 1: Quality Model. International Organization for Standardization [6] ISO/IEC 12207:2008 Information technology Software life cycle processes. International Organization for Standardization. [7] T. Hilburn, M. Towhidnejad, Software Quality: A Curriculum Postscript? In: Proceedings of the 31 st SIGCSE Technical Symposium on Computer Science Education. New York, pp. 167 171, 2000 [8] N. Bhushan, K. Rai Strategic decision making: applying the analytic hierarchy process. Springer, 2004 [9] S. Sproge, R. Cevere Position and role of feedback in the software quality life cycle. Quality Issues and Insights in the 21st Century, vol. 1, p. 29 40, 2012 [10] ISO/IEC 9126 4:2004 Software engineering Product quality Part 4: Quality in use metrics. International Organization for Standardization ISBN: 978-1-61804-276-7 119