Lecture 9. Quality software
Under software quality we will understand the totality of software properties that determine its suitability to satisfy the specific needs of users and specialists involved in the creation and maintenance of software. From the above formulation it follows that not all properties of software are included in its quality, but only that combination of them that is determined by the need for this software. The quality of a software product can be defined as “suitability for use.” Quality must be guaranteed by the development process. Quality control of a software product is systematic actions confirming the suitability for use of the software product as a whole. The purpose of quality control is to provide quantitative measures of the quality of a software system.
Under property (characteristic) Software we will understand the objective feature of software (programs and documentation), which manifests itself during its development, operation and maintenance. Software properties can be divided into functional and constructive. Functional properties reflect the capabilities and specifics of the application of the program and determine the degree of its compliance with its intended purpose. They characterize a program in terms of how it actually runs. The design properties of a program are more or less independent of its functionality and appointments. They characterize the program in terms of how it is actually designed.
To objectively assess the quality of software, its properties must be characterized quantitatively. Level of quality Software is a quantitative characteristic of a software property, which is part of its quality and is considered in relation to certain conditions of its creation, operation and maintenance. Along with quality indicators, qualitative (verbal) assessments, called signs.
Quality indicators based on the number of characterized properties can be single And comprehensive (group). A single indicator refers to only one of the properties, while a complex indicator characterizes several properties of the software.
Methods for determining software quality indicators vary:
- by methods of obtaining information about software- measuring, registration, organoleptic, calculation;
- by sources of information- traditional, expert, sociological.
Measuring method is based on obtaining information about the properties and characteristics of software using tools. For example, using this method, the volume of software is determined - the number of lines of source text of programs and the number of lines of comments, the number of operators and operands, the number of executed statements, the number of branches in the program, the number of entry (exit) points, execution time of a program branch, reaction time and other indicators.
Registration method is based on obtaining information during testing or operation of the software, when certain events are recorded and counted, for example, the time and number of failures and failures, the time of transfer of control to other modules, the start and end time of work.
Organoleptic method is based on the use of information obtained as a result of analysis of the perception of the senses (vision, hearing), and is used to determine such indicators as ease of use, efficiency, etc.
Calculation method is based on the use of theoretical and empirical dependencies (in the early stages of development), statistical data accumulated during testing, operation and maintenance of software. Using the calculation method, the duration and accuracy of calculations, reaction time, and required resources are determined.
Expert method used in cases where the problem cannot be solved by any other existing methods, or other methods are much more labor-intensive. The expert method is recommended to be used when determining indicators of clarity, completeness and accessibility of program documentation, ease of learning, and structure. Determining the values of software quality indicators using the expert method is carried out by a group of expert specialists competent in solving this problem, based on their experience and intuition.
Sociological methods based on the processing of special questionnaires.
Software quality assessment is carried out in phases life cycle and includes the selection of a nomenclature of indicators, their assessment and comparison of the indicator values obtained as a result of comparison with the basic values.
Quality indicators are combined into a system of four levels. Each higher level contains indicators of lower levels as components. It is allowed to enter additional indicators at each level.
To ensure the possibility of obtaining an integral assessment for groups of quality indicators, use quality factors(1st level): software reliability, maintainability, ease of use, efficiency, versatility (flexibility) and correctness. Each quality factor corresponds to a specific set quality criteria(comprehensive indicators - level 2) given below. Quality criteria are determined by one or more metrics(3rd level). If the quality criterion is determined by one metric, then the metric level is omitted. Metrics are made up of assessment elements(single indicators - 4th level), defining the property specified in the metric. The number of evaluation elements included in the metric is not limited.
For quality indicators at all levels (factors, criteria, metrics, evaluation elements), a single rating scale from 0 to 1 is adopted.
Quality indicators at each higher level (except for the level of assessment elements) are determined by the quality indicators of the lower level.
Let's consider the main indicators of software quality:
1. RELIABILITY INDICATORS. Characterize the software's ability to
specific areas of application to perform specified functions in accordance with program documents in the conditions of deviations in the operating environment caused by failures of technical means, errors in input data, service errors and other destabilizing influences:
1.1. Stability of operation. The ability to ensure that the program continues to operate after deviations occur due to technical failures, errors in input data and maintenance errors;
1.2. Performance. The ability of a program to function in specified modes and volumes of processed information in accordance with program documents in the absence of technical failures.
2. SUPPORT INDICATORS. Characterize technological
aspects that make it easy to eliminate errors in the program and program documents and keep the software up to date:
2.1. Structurality. Organizing all interconnected parts of the program into a single whole using logical structures “sequence”, “choice”, “repetition”;
2.2. Simplicity of design. Construction of a modular structure-program in the most rational way from the point of view of perception and understanding;
2.3. Visibility. Availability and presentation of source modules in the most easily understandable form, their full description in the relevant program documents;
2.4. Repeatability. The extent to which standard design solutions or components included in the software are used.
3. USABILITY INDICATORS. Characterize the properties of the software,
facilitating the rapid development, application and operation of software with minimal labor costs, taking into account the nature of the tasks being solved and the requirements for the qualifications of operating personnel:
3.1. Ease of learning. Performance program documents and the program in a form that facilitates understanding of the logic of the functioning of the program as a whole and its parts;
3.2. Availability of operational program documents. Clear, visual and complete description of user interaction with the program in operational program documents;
3.3. Ease of operation and maintenance. Correspondence of the data processing process and forms of presentation of results to the nature of the tasks being solved.
4. PERFORMANCE INDICATORS. Characterize the degree to which the user’s needs for data processing are met, taking into account economic, computing and human resources:
4.1. Level of automation. The level of automation of the functions of the data processing process, taking into account the rationality of the functional structure of the program in terms of user interaction with it and the use of computing resources;
4.2. Temporary efficiency. The ability of a program to perform specified actions in a time interval that meets certain requirements;
4.3. Resource intensity. Minimum required computing resources and number of maintenance personnel to operate the software.
5. INDICATORS OF VERSATILITY. Characterize software adaptability
to new functional requirements arising from changes in the scope of application or other operating conditions:
5.1. Flexibility. Possibility of using software in various fields of application;
5.2. Mobility. Possibility of using the software without significant additional labor costs on a computer of a similar class;
5.3. Modifiability. Ensuring ease of making necessary changes and modifications to the program during operation.
6. INDICATORS OF CORRECTNESS. Characterize the degree of software compliance
requirements established in the technical specifications, data processing requirements and general system requirements:
6.1. Completeness of implementation. Completeness of implementation of specified software functions and sufficiency of their description in the software documentation;
6.2. Consistency. Unambiguous, consistent description and use of identical objects, functions, terms, definitions, identifiers, etc. in various parts of program documents and program text;
6.3. Logical correctness. Functional and software compliance of the data processing process when performing a task with system-wide requirements;
6.4. Verification. Completeness of checking possible program execution routes during testing.
Etc.) Cleanroom OpenUP RAD RUP MSF DSDM TDD
Software quality- characteristics of the software (software) as the degree of its compliance with the requirements. At the same time, the requirements can be interpreted quite broadly, which gives rise to a number of independent definitions of the concept. The most commonly used definition is ISO 9001, according to which quality is “the degree to which inherent characteristics meet requirements.”
Source code quality
Code quality can be determined by various criteria. Some of them are only meaningful from a human perspective. For example, how the text of a program is formatted is completely unimportant for the computer, but can have serious implications for subsequent maintenance. Many of the existing coding standards, which define language-specific conventions and set a number of rules that improve code readability, are intended to facilitate future software maintenance, including debugging and updating. There are other criteria that determine whether the code is “well” written, for example, such as structuredness - the degree to which the code is logically divided into a number of manageable blocks.
- Code readability
- Ease of support, testing, debugging, bug fixing, modification and portability
- Low code complexity
- Low resource usage: memory and CPU time
- Correct exception handling
- Few warnings during compilation and linking
Methods for improving code quality: refactoring.
Quality factors
A software quality factor is a non-functional requirement for a program that is usually not described in the contract with the customer, but is nevertheless a desirable requirement that improves the quality of the program.
Some of the quality factors are:
Understandability The purpose of the software should be clear from the program itself and the documentation. Completeness All necessary parts of the program must be presented and fully implemented. brevity Absence of unnecessary, duplicate information. Repeated parts of code should be converted into a common procedure call. The same applies to documentation. portability Ease of adapting a program to another environment: another architecture, platform, operating system or its version. Consistency The same conventions, formats, and notations must be used throughout the program and documentation. maintainability How difficult it is to change a program to meet new requirements. This requirement also specifies that the program must be well documented, not too confusing, and have room for growth in resource usage (memory, processor). testability Whether the program allows you to check acceptance characteristics, whether the ability to measure performance is supported. ease of use Simplicity and ease of use of the program. This requirement applies primarily to the user interface. reliability, the absence of failures and failures in the operation of programs, as well as the ease of correcting defects and errors: structured efficiency How rationally a program treats resources (memory, processor) when performing its tasks. safety
From the user's point of view
Besides technical view on software quality, there is also an assessment of quality from the user’s perspective. The term "usability" is sometimes used for this aspect of quality. It is quite difficult to obtain a usability rating for a given software product. The most important issues affecting the assessment:
- Is the user interface intuitive?
- How easy is it to perform simple, frequent operations?
- How easy are complex operations to perform?
- Does the program produce clear error messages?
- Does the program always behave as expected?
- Is there documentation and how complete is it?
- Is the user interface self-descriptive/self-documenting?
- Are program response delays always acceptable?
see also
Links
| Famous figures |
|
|---|---|
| Process | |
| Concepts | |
| Directions | |
| Models development |
|
| Other models | |
| Other | |
Wikimedia Foundation. 2010.
- NLite
- Midnight in the Cemetery (film)
See what “Software quality” is in other dictionaries:
Software quality- the ability of a software product to validate its specification, provided that the specification is focused on the characteristics that the user desires. See also: Software quality Software Financial… … Financial Dictionary
Software development- While Grace Hopper was working on the Harvard Mark II computer at Harvard University, her colleagues discovered this moth stuck in a relay and thus interfering with the device's operation, after which she noted that they were "debugging" the system.... ... Wikipedia
Software testing- Software development Software development process Process steps Analysis Design Programming Document ... Wikipedia
Software Manufacturer- Software development (eng. software engineering, software development) is a type of activity (profession) and a process aimed at creating and maintaining the functionality, quality and reliability of software using ... Wikipedia
Software crisis- "Software crisis" is a term once used in computer science to describe the consequences of the rapid growth in the computing power of computers and the complexity of the problems that can be solved with their help. In essence, this is... ... Wikipedia
Software Engineering- The new Airbus A 380 uses quite a lot of software to create a modern cockpit on the plane. The software engineering method made it possible to create aircraft software described in millions of lines... Wikipedia
Software mobility- the ability of the software to run on different hardware platforms or under different operating systems. Synonyms: Software portability See also: Software quality Open systems… … Financial Dictionary
User-friendliness of the software- characteristics of a software product that: allow minimizing the efforts of users to prepare initial data, use the software product and evaluate the results obtained, and also allow them to evoke positive emotions... ... Financial Dictionary
Software maintainability- characteristics of a software product that allow minimizing efforts to make changes to it: to eliminate errors; or for modification to meet changing user needs. See also: Software quality... ... Financial Dictionary
Software functionality- the ability of a software product to perform a set of functions: defined in its external description; and satisfying the specified or implied needs of users. Synonyms: Software interoperability See also: Quality... ... Financial Dictionary
Books
- Electricity losses. Reactive power. Power quality. Management, Zhelezko Yuri Stanislavovich, Fundamental issues in the field of planning and control of electrical network modes are considered: electricity losses, reactive power compensation, quality... Category:
Quality criteria are measurable numerical indicators, in the form of some target function, characterizing the degree to which an object fulfills its purpose. In general, quality criteria should reflect the generalized “usefulness” for society, the analyzed object, and the effectiveness of design technology. Software is primarily characterized by the complexity and duration of creation, as well as the achieved quality of programs when using appropriate technologies.
Analysis of the quality criteria of the PS life cycle program is the basis for assessing the effectiveness of the design technology. In the process of forming the technical specifications for the software, the dominant indicators are identified, the relative importance of each of them is established and a generalized function of the required quality of a particular software is constructed, in addition, acceptable costs and development duration are established software that the appropriate technology should provide.
As a set of programs is created, after debugging and testing is completed, the achieved real value of each of the indicators and the generalized quality functions of the entire complex are clarified. Quality indicators can also be refined during operation.
Software developers strive to identify and define a single criterion for the effectiveness of programs:
1. Numerically and in the most general form characterize the degree to which the system fulfills its main target function.
2. Let identify and evaluate the degree of influence on the efficiency of the system of various factors and parameters, including costs various types for its implementation.
3. Be simple and have low variance, i.e. little to depend on uncontrollable, random factors.
The ability to implement a system that satisfies certain quality criteria naturally depends on the provision of resources and technical means performing basic functions. The high cost of complex systems and the long lead times for their design and manufacture pose a particularly acute problem of estimating the costs at which this or that efficiency is achieved. It is especially difficult in software complexes containing hundreds of modules to ensure the best use of the complex's resources, from the point of view of the main efficiency criterion, while maintaining a number of private quality indicators within acceptable limits.
The numerous and complex ways of using programs require their high stability, both in relation to errors in input information and in relation to internal failures of the computer running the program. To ensure such stability, complex programs usually contain control operations various types and have special adaptation and self-organization modules for changing the structure of programs. And in some cases, the entire control system during reboots, failures and partial failures.
Commands and data included in program modules do not have absolute reliability of correct execution. Therefore, it is necessary to use special hardware and software to improve the reliability of program execution to obtain correct results and control actions.
Quality indicators can also be refined during operation, resulting in a long-term perspective of objective measurement and improvement of program quality.
1. Functional criteria qualities reflect the main specifics of the application and the degree of compliance of the PS with its intended purpose. For control programs, they include indicators of the accuracy of output data, ranges of parameter changes, response time, adaptability to external influences etc. In data processing systems, functional indicators reflect the nomenclature of source data, the reliability of results, the variety of functions, and more. Functional criteria are very different and correspond to the variety of intended purposes, functions and areas of application of the software. They are the most important for each system (the list of source documents is specific).
2. Design criteria the qualities of PS are more or less invariant to their intended purpose and main functions. These include the complexity of programs, reliability of operation, resources used, correctness of programs, etc. Some design criteria may be important from a direct standpoint functional purpose, determined by software (reliability).
The division of criteria into two groups is arbitrary and aims to highlight the criteria that are most common for all types of software and least dependent on their main functional purpose.
Particular attention should be paid to the temporary indicators of the life cycle of programs:
1. design duration
2. duration of operation of the next version
3. duration of each modification
Duration and modification carrying out this work in some cases may be a more important criterion than labor intensity. In some cases, the total duration of effective operation is dominant criterion PS quality. For each of the developments, it is advisable to carry out ranking (ranks) of criteria and factors at the stages of the PS life cycle.
Software (software) currently there are hundreds of thousands of programs that are designed to process a wide variety of information for a variety of purposes. Depending on what tasks a particular software performs, all software can be divided into several groups:
1. System software (or System programs) – intended for use and Maintenance PC, management and organization of the computing process when solving any specific problem on a PC, etc. System software is a mandatory part of the software, it includes
OS
Operating system shells.
Utility programs
2. Application software (or packages application programs) – designed to solve a certain class of problems, i.e. These are programs used as a tool for creating documents in everyday activities. Or programs with which the user solves his information tasks without resorting to programming. These include.
2.2. Assessing the quality of software creation processes
The transition from piece-by-piece software development to industrial programming has led to increased requirements for the quality of created software. Currently, there are several standards related to assessing the quality of these processes, which is provided by the development company. The most interesting to consider include:
international standards of the ISO 9000 series (ISO 9000 - ISO 9004);
CMM - Capability Maturity Model - a model of maturity (improvement) of software creation processes, proposed by SEI (Software Engineering Institute -
Programming Institute at Carnegie Mellon University);
The process of certifying programs based on information about their use.
2.2./. ISO 9000 series
One of the most important problems in ensuring the quality of software is the formalization of quality characteristics and the methodology for their assessment. To determine the adequacy of the quality of operation, the availability of technical capabilities of software tools for interaction, improvement and development, it is necessary to use standards in the field of assessing the characteristics of their quality. The basis for regulating software quality indicators was previously international standard ISO 9126:1991 (GOST R ISO/IEC 9126-93) “Information technology. Software product evaluation. Quality characteristics and guidelines for their use." The final draft of the four-part ISO 9126-1-ISO 9126-4 standard is being completed and formalized to replace the minor 1991 edition. The project consists of the following parts under the general heading “Information technology - software quality characteristics and metrics”: “Part 1 .Characteristics and subcharacteristics of quality; Part 2. External quality metrics"; “Part 3. Internal quality metrics”; "Part 4: Quality Metrics in Use".
In Russia, in the field of ensuring the life cycle and quality of complex software packages, a group of outdated GOST standards are mainly used, which lag behind the world level by 5-10 years.
The first part of the standard, ISO 9126-1, categorizes software quality attributes into six characteristics used in the remaining parts of the standard. Based on the fundamental possibilities of their measurement, all characteristics can be combined into three groups, to which different categories of metrics are applicable:
quantitative metrics are applicable to measure the reliability and effectiveness of complex software packages;
Quality metrics are most consistent with usability, maintainability, and portability of software.
Part of the ISO 9126-1 standard provides definitions with clarifications from the rest of its parts for each software characteristic, as well as for quality sub-characteristics.
Over the past few years, many ISO standards have been created that regulate the processes and products of the software life cycle and databases, which can serve as the basis for software quality assurance systems.
The second and third parts of the standard - ISO 9126-2 and ISO 9126-3 - are devoted to formalizing, respectively, external and internal metrics for the quality characteristics of complex software. All tables contain a unified heading, which reflects the name and purpose of the metric; method of its application; method of measurement, type of metric scale; type of measured quantity; baseline data for measurement and comparison; as well as the stages of the software life cycle (according to ISO 12207) to which the metric is applicable.
The fourth part of the standard, ISO 9126-4, is intended for buyers, suppliers, developers, maintainers, users and software quality managers. It justifies and comments on the selected indicators of the sphere (context) of software use and the group of selected metrics for users.
Choiceindicatorsquality
The initial data and highest priority when choosing quality indicators in most cases are the purpose, functions and functional suitability of the corresponding software tool. A fairly complete and correct description of these properties should serve as the basis for determining the values of most other characteristics and quality attributes. The fundamental and technical capabilities and accuracy of measuring the values of attributes of quality characteristics are always limited in accordance with their content. This defines rational ranges of values for each attribute that can be selected based on common sense as well as by analyzing precedents in requirements specifications of real projects.
The processes of selecting and establishing metrics and scales to describe software quality characteristics can be divided into two stages:
selection and justification of a set of initial data reflecting the general features and stages of the life cycle of a software project and its consumers, each of which affects certain quality characteristics of the software package;
selection, establishment and approval of specific metrics and scales for measuring the characteristics and quality attributes of the project for their subsequent assessment and comparison with the requirements of the specifications in the process of qualification testing or certification at certain stages of the software life cycle.
At the first stage, the entire basic nomenclature of characteristics, subcharacteristics and attributes standardized in ISO 9126 should be taken as a basis. It is advisable to pre-order their descriptions by priority, taking into account the purpose and scope of a particular software project. Next, it is necessary to identify and prioritize consumers who need certain indicators of the quality of a software project, taking into account their specialization and professional interests. The preparation of initial data is completed by identifying a range of basic, priority quality indicators that determine the functional suitability of the software for certain consumers.
At the second stage, after fixing the initial data, which must be performed by the consumer of quality assessments, the selection processes of nomenclature and metrics begin with the ranking of characteristics and subcharacteristics for a specific project and their consumer. Next, these specialists must establish and agree on a metric and rating scale for subcharacteristics and their attributes for each of the selected indicators for the project and the consumer of the analysis results. For indicators represented by qualitative characteristics, it is desirable to define and record in specifications descriptions of the conditions under which it should be considered that this characteristic implemented in software. The selected values of quality characteristics and their attributes must be previously checked by developers for their feasibility, taking into account the available resources of a particular project and, if necessary, adjusted.
Gradequality
The international standard ISO 14598, consisting of six parts, is devoted to the methodology and standardization of assessing the quality characteristics of finished software tools and their components (software product) at various stages of the life cycle. The following general scheme of processes for assessing program quality characteristics is recommended:
setting initial requirements for assessment - defining test goals, identifying the type of software metrics, identifying adequate indicators and required values of quality attributes;
planning and designing processes for assessing characteristics and quality attributes in the life cycle of a software tool;
performing measurements for assessment, comparing results with criteria and requirements, summarizing and evaluating results.
For each quality characteristic, it is recommended to create measures and a measurement scale highlighting required, acceptable and unsatisfactory values. The implementation of the assessment processes must be correlated with the life cycle stages of a specific software project in accordance with the applicable, adapted version of the ISO 12207 standard.
Functional suitability is the most uncertain and objectively difficult to evaluate subcharacteristic of a software tool. The areas of application, nomenclature and functions of software complexes cover such diverse areas of human activity that it is impossible to single out and unify a small number of attributes for assessing and comparing this subcharacteristic in various software complexes.
Assessing the correctness of software consists of formally determining the degree of compliance of a set of implemented programs with the original requirements of the contract, technical specifications and specifications for the software and its components. Through verification, compliance with the initial requirements of the entire set of components of the software package, down to modules and program texts and data descriptions, must be determined.
Assessing Interoperability is to determine the quality of collaboration of software and database components with other application systems and components on various computing platforms, as well as interaction with users in a style convenient for transition from one computing system to another with similar functions.
Software security assessment includes determining the completeness of the use of available methods and means of protecting the software from potential threats and the achieved security of the information system. The most widespread and detailed methodological and systemic tasks for assessing the comprehensive protection of information systems are set out in three parts of the ISO 15408:1999-1- ISO 15408:1999-3 “Methods and means of ensuring security. Safety assessment criteria information technologies».
Reliability assessment- measurement of quantitative metrics of attributes of subcharacteristics in use: completeness, defect tolerance, recoverability and availability/readiness.
Memory and performance requirements the computer in the process of solving problems varies significantly depending on the composition and volume of the initial data. To correctly determine the maximum throughput of an information system with a given software tool, it is necessary to measure the extreme and average values of the execution durations of functional groups of programs and the routes along which they are achieved. If the computer's performance was not previously assessed during the design process, then most likely a major modification or even replacement of the computer with a faster one will be required.
Usability assessment The software assessment is conducted by experts and includes a determination of the software's understandability, ease of use, learnability, and attractiveness. This is mainly a qualitative (and subjective) assessment in points, but some attributes can be assessed quantitatively by the complexity and duration of operations when using the software, as well as by the amount of documentation required to study them.
Maintainability can be assessed by the completeness and reliability of documentation about the states of the software and its components, all proposed and completed changes, which makes it possible to establish the current state of program versions at any time and the history of their development. It should define the strategy, standards, procedures, allocation of resources, and plans for the creation, modification, and application of program and data documents.
Mobility assessment is a qualitative determination by experts of adaptability, ease of installation, compatibility and replaceability of programs, expressed in points. Quantitatively, this characteristic of a software tool and the set of its attributes can (and is appropriate) be assessed in economic indicators: cost, labor intensity and duration of implementation of procedures transfer to other platforms of a certain set of programs and data.
Systemmanagementquality
Selecting characteristics and assessing the quality of software is only one of the tasks in the field of ensuring the quality of products produced by software development companies. A comprehensive solution to the problems of ensuring software quality involves the development and implementation of one or another quality management system. In world practice, the most widely used system is based on international standards of the ISO 9000 series, which includes more than a dozen documents, including the standard regulating software quality assurance (ISO 9000/3). These standards should serve as a guide for leading specialists in custom software development companies.
Definitions of quality characteristics and subcharacteristics (ISO 9126-1):
Functionality - the ability of a software tool to provide problem solving, satisfying the formulated needs of customers and users when using a set of programs under given conditions.
Functional suitability is a set and descriptions of a subcharacteristic and its attributes that define the purpose, nomenclature, basic, necessary and sufficient functions of a software tool that correspond to the technical specifications and specifications of the customer or potential user.
Correctness (correctness)- the ability of a software tool to provide correct or acceptable results and external effects to the user.
Interoperability- the property of software and their components to interact with one or more components of the internal and external environment.
Security- the ability of software components to protect programs and information from any negative influences.
Reliability- providing a set of programs with a sufficiently low probability of failure during the operation of the software in real time.
Efficiency- properties of the software that provide the required performance for solving functional problems, taking into account the amount of computing resources used under the established conditions.
Practicality (applicability)- properties of a software tool that determine the complexity of its understanding, study and use, as well as its attractiveness for qualified users when used in the specified conditions.
Maintainability- adaptability of the software to modification and change of configuration and functions.
Mobility- readiness of the software for transfer from one hardware operating environment to another.
2.2.2. SMM
In November 1986, the Software Engineering Institute (SEI), in collaboration with Miter Corporation, began developing a software development process maturity survey that was intended to help improve their internal processes.
The development of this review was prompted by a request from the US federal government to provide a method for evaluating software development subcontractors. The real problem was the inability to manage large projects. In many companies, projects were completed significantly late and over budget. It was necessary to find a solution to this problem.
In September 1987, SEI released short review software development processes describing their maturity levels, as well as a questionnaire designed to identify areas in the company where improvements were needed. However, most companies considered this questionnaire as a ready-made model, so after 4 years the questionnaire was converted into a real model, the Capability Maturity Model for Software (CMM). The first version of the CMM (Version 1.0), released in 1991, was revised in 1992 by participants in a workshop of about 200 software professionals and members of the development society.
As a result, the CMM standard, Version 1.1, was released, which is still actively used throughout the world.
The reasons for such interest in SMM are clear. Despite the fact that both software developers themselves and their management are often very aware of their ongoing problems, they cannot come to a consensus about what changes the company needs first. Without developing a unified improvement strategy, management cannot find mutual understanding with its employees regarding the highest priority improvement tasks. To achieve maximum results from the efforts spent on improving processes, it is necessary to have a phased development strategy that will improve the maturity of development processes gradually, in an evolutionary way.
Continuous process improvement is based on incrementally nurturing a company's culture rather than pursuing revolutionary innovation. The CMM provides a framework for such incremental improvement, divided into five levels of process maturity. These five levels represent a scale (Figure 2.4) for assessing the level of maturity of software development processes in a company and for measuring their parameters.
Here are the main characteristics of each level:
First level. The development process is chaotic. Only a few of the processes are defined, and the success of projects depends on specific implementers.
Repeatability. Basic project management processes have been established: tracking costs, work schedules and functions
Development
Control
nality. Streamlined some processes necessary to replicate previous achievements on similar projects (projects with similar applications).Development. The processes of software development and project management are described and implemented into a unified system of company processes. All projects use a standard software development and support process for the organization, adapted for a specific project.
Control. Detailed quantitative data is collected on the functioning of development processes and the quality of the final product. The meaning and dynamics of these data are analyzed.
Quality improvement. Continuous process improvement is based on quantitative process data and the trial implementation of new ideas and technologies.
IN Explanatory dictionary in computer science V.I. Pershikov and V.M. Savinkov, the concept of standardization is defined as the adoption of an agreement on the specification, production and use of computer hardware and software; establishment and application of standards, norms, rules, etc.
Standards are of great importance - they provide the ability for software developers to use data and programs from other developers, and export/import data.
Such standards regulate the interaction between various programs. Interprogram interface standards are designed for this, for example OLE (Object Linking and Embedding - linking and embedding objects). Without such standards software products would be “closed” to each other.
Standards are playing an increasingly important role in the development of the information technology industry. More than 250 subcommittees within formal standards organizations work on information technology standards. More than 1,000 standards have either already been adopted by these organizations or are in the process of being developed. The process of standardization of information technology is far from finished (yes, in our opinion, it is unlikely to ever be completed, since the field of information technology is constantly developing dynamically).
All development companies must ensure an acceptable level of quality for the software they produce. For these purposes, software quality standards or separate sections in software development standards devoted to software quality requirements are intended.
From the user's point of view, all the variety of software must be managed uniformly. There should be uniform navigation - movement through the program, uniform software controls and a uniform reaction of the software to user actions. For this purpose, standards have been developed for the user interface - GUI (Graphical User Interface). All this is regulated by standards in force in the field of information technology.
The need for standardization of software development is best described in the introduction to the ISO/IEC 12207 standard: “Software is an integral part of information technology and traditional systems such as transportation, military, medical and financial. There are many different standards, procedures, methods, tools tools and operating environment types for software development and management.This diversity creates challenges in software design and management, especially when combining software products and service programs. Software development strategy requires moving from this multitude to a common order that will allow software practitioners to “speak the same language” when developing and managing software. This international standard provides that general order."
Let's try to bring order to the variety of standards operating in the IT field and classify them (Fig. 1.3).
As you can see, the upper part of the classification resembles the types of standards indicated above. However, there are also some peculiarities here. This applies primarily to the “de jure” and “de facto” standards. Let's immediately define these concepts.
A de facto standard is a term for a vendor's product that has captured a large market share and that other vendors seek to emulate, copy, or use to capture their share of the market.
One of the main reasons for the importance of the modern standardization program is the awareness of the danger of misuse of “de facto” standards. In the 1960s and 1970s, the creation of de facto standards placed users at the mercy of manufacturers when using basic data processing and telecommunications tools. An important aspect of today's standardization work is overcoming this dependency through the promotion of standard interfaces. For a long time These standards were SQL (Structured Query Language) and D. Ross' SADT (Structured Analysis and Design Technique) diagramming language. A de jure standard is created by a formally recognized standardizing organization. It is developed by following the rules of consensus through a process of open discussion in which everyone has a chance to participate. No one group can act independently to create standards for industry. If any vendor group creates a standard that does not take user requirements into account, it will fail. The same thing happens if users create a standard that suppliers cannot or will not agree to - that standard will also not be successful. De jure standards cannot be changed without going through a process of approval under the control of the organization developing the standards. OSI standards (Open Systems Interconnection reference model), Ethernet, POSIX, SQL and most language standards are examples of such standards. As an example of the transition of a “de facto” standard to a “de jure” standard, let us consider the history of the development and standardization of the SQL language.
Work on the creation of the SQL language began in the 70s of the last century in the research laboratories of IBM. Currently, it has become one of the main standards in the field information systems and provided technology base language for a whole generation of DBMSs based on the relational model. Although it was commercially implemented in the early 1980s for only a small group of software products, SQL undeniably gained acceptance with the adoption of the ANSI and ISO standard SQL-86. Later, during the preparation of the SQL-89 standard, a number of additional features were included in the language.
Rice. 1.3. Information Technology Standards Classification Scheme
The origins of SQL should be attributed to the birth of the relational data model (described in the article by E.F. Codd). Since no SQL-like languages appeared over the next few years in the research projects initiated by IBM after the publication of E.F. Codd, special importance was attached to the need to create interface languages for the DBMS being created to test the capabilities of the relational model. The history of the development of the SQL language is illustrated in Fig. 1.4.
In IBM research laboratories in the early 70s of the 20th century, simultaneously with work on the future SQL language Other projects were also developed to create and experimentally implement relational languages. Probably the most famous of these is the relational language Query-By-Example (QBE), created around the same time as SEQUEL (an early version of SQL) by M. Zloof of IBM's Yorktown Heights laboratory. This language is currently used in many commercial software products along with SQL.
In 1974, Donald D. Chamberlin of the IBM San Jose Research Laboratory proposed specifications for a relational language called SEQUEL (Structured English QUEry Language). A revised version of this language (SEQUEL/2) was developed in 1976-1977, and it acquired its final name - SQL (Structured Query Language).
Even before commercial IBM products entered the software market in the early 1980s, Relation Software Inc. (now called Oracle Corporation) announced the release of a relational DBMS based on the SQL language. This system, as a result of its evolution, has become one of the dominant commercial systems and is called ORACLE.
The ORACLE product with its SQL language faced competition in the field of mainframe computers and minicomputers from the products of a number of other developers, in particular the Ingres DBMS with the QUEL language from Relation Technology Inc., as well as the Rdb/VMS product with the RDML language from Digital Equipment Corporation .
One of the reasons for SQL's success was the formation of the American National Standards Institute (ANSI) committee HZN2, established to develop database language standards. An IBM representative suggested using the results of IBM's earlier work on SEQUEL/2 as preliminary specifications for a relational language, and the standard's developers began work. The document, entitled "SQL," was largely a treatise on the various forms of SQL used in commercial software products.
The International Standards Organization (ISO), through technical committee TC97 (now called ISO/IEC JTC1), also worked to create a standard for relational database languages. In the mid-1980s, both ANSI and ISO approved SQL standards (ANSI in 1986 and ISO in early 1987).
The first SQL standard, due to the way it was developed, was very incomplete in terms of database system functionality, and many of the vendors continued to add a wide range of extensions to the standard in their software products. In 1989, a revised version of the SQL standard was adopted, which differed from the 1986 standard mainly in its ability to support referential integrity.
However, before 1989, both ANSI and ISO had begun work on radical extensions to SQL. This work, initially identified as "SQL2", began in 1987, and its results were adopted as the SQL-92 standard five years later.
Adding to the confusion is the fact that work on SQL2 overlapped with work on SQL3, new version SQL standard, which is still under development. Work on SQL3 began back in 1990 in parallel with SQL2, mainly as a "spare tank" for features that were not intended to be included in SQL2 for one reason or another. SQL3 includes object-oriented language extensions, as well as additional relational capabilities that were not found in SQL2.
Let's illustrate in Fig. 1.5 time-based process for developing various SQL standards.
It should be noted that in the field of information technology there are two main historical approaches to the development of standards. The first is when a problem is brewing - the need for a standard. In this case, a group of experts gathers in some section of information technology and discusses local solutions invented by individual software companies and scientific organizations, analyzes these solutions and develops a single integrated standard that includes the best ideas and developments.
But the market lives by slightly different laws. The first approach is inert, the problem has already matured, it needs to be solved, and it is not known when experts will gather and develop the necessary standard. Secondly, software development companies each develop their own solution, and the most popular, widespread solution in terms of frequency of use acquires the status of a standard (not necessarily legally). Thus, SQL became the standard language for accessing databases, which is called “de facto,” although later the status of the standard was legally secured.
The disadvantage of this approach is that it is not the strongest, but the most widespread commercial solution that becomes the standard.
Another example of the emergence of a standard is the emergence of the now popular UML - Unified Modeling Language. Major developments in object-oriented analysis and design methods appeared between 1988 and 1992. By 1994, there were a large number of informal leaders of practicing developers (about one and a half dozen) who promoted their methodologies. All their methods were similar, but often the differences between them were in minor details. A conversation about standardization was brewing. The OMG team tried to address the standardization issue, but received an open letter of protest from all authors. In 1996, three leading experts in the field of object-oriented analysis and design, James Rumbaugh, Grady Booch, and Ivar Jacobson, teamed up, and the Unified Method version 0.8 was born in 1996 g. “three friends” worked on their method, which was called Unified Modeling Language. In January 1997, various organizations presented their proposals for standardization of methods, primarily providing for the possibility of exchanging information between different models. As a result, there is now only one proposal - the UML standard.
Loading...
