Life cycle of software systems. Prolozova N.O., Nazarova O.B., Davletkireeva L.Z. Analysis of standards in the field of maintenance of automated information systems IEEE 90 standard maintenance elements
The structure of software lifecycle in accordance with the ISO / IEC 12207 standard is based on three groups of processes (Fig. 1):
· Basic processes of software lifecycle (purchase, delivery, development, operation, maintenance);
Auxiliary processes that ensure the execution of the main processes (documentation, configuration management, quality assurance, verification, certification, assessment, audit, problem solving);
· Organizational processes (project management, creation of project infrastructure, definition, assessment and improvement of the life cycle itself, training).
Figure: 1. Processes life cycle software.
Acquisition process(acquisition process). It consists of actions
and the tasks of the customer purchasing software. This process covers the following steps:
1) initiation of the acquisition;
2) preparation of application proposals;
3) preparation and correction of the contract;
4) supervision of the supplier's activities;
5) acceptance and completion of work.
Delivery process(supply process). It covers the activities and tasks performed by a vendor who supplies a customer with a software product or service. This process includes the following steps:
1) initiation of delivery;
2) preparation of a response to application proposals;
3) preparation of the contract;
4) planning;
5) implementation and control;
6) verification and evaluation;
7) delivery and completion of works.
Development process(development process). It provides for the actions and tasks performed by the developer, and covers work on the creation of software and its components in accordance with the specified requirements, including the preparation of design and operational documentation, preparation of materials necessary to check the operability and appropriate quality of software products, materials necessary for organizing training staff, etc.
The development process includes the following steps:
1) analysis of system requirements;
2) design of the system architecture;
3) analysis of software requirements;
4) software architecture design;
5) detailed software design;
6) software coding and testing;
7) software integration;
8) software qualification testing;
9) system integration;
10) qualification testing of the system;
11) software installation;
12) software acceptance.
Operation process(operation process). It covers the actions and tasks of the operator - the organization operating the system. This process includes the following steps:
1) operational testing;
2) system operation;
3) user support.
Maintenance process(maintenance process). It provides for the actions and tasks performed by the escorting organization (escort service). This process is activated in case of changes (modifications) of the software product and the corresponding documentation caused by problems or needs for modernization or adaptation of the software. In accordance with the IEEE-90 standard, maintenance means making changes to the software in order to fix errors, improve performance, or adapt to changed operating conditions, or
requirements. Changes to existing software must not violate
its integrity. The maintenance process includes transferring software to another environment (migration) and ends with software retirement.
The maintenance process covers the following activities:
1) analysis of problems and requests for software modification;
2) software modification;
3) inspection and acceptance;
4) software transfer to another environment;
5) software removal from service.
The group of auxiliary processes includes:
Documentation;
Configuration management; quality assurance;
Verification; certification;
Joint assessment;
Resolution of problems.
Documentation process(documentation process). It provides for a formalized description of the information created during the life cycle of software. The documentation process includes the following steps:
1) design and development;
2) release of documentation;
3) documentation support.
Configuration management process(configuration management process). It involves the application of administrative and technical procedures throughout the software life cycle to determine the status of software components in the system, manage software modifications, describe and prepare reports on the status of software components and requests for modification, ensure the completeness, compatibility and correctness of software components, manage storage and delivery. BY. According to the IEEE-90 standard, software configuration is understood as a combination of its functional and physical characteristics.
characteristics established in technical documentation and implemented in software.
Configuration management allows you to organize, systematically take into account and control changes in software at all stages of the life cycle. General principles and recommendations for software configuration management are reflected in the draft standard ISO / I EC CD 12207-2: 1995 "Information Technology - Software Life Cycle Processes. Part 2.
Configuration Management for Software. "The configuration management process includes the following steps:
1) configuration identification;
2) configuration control;
3) accounting for the state of the configuration;
4) configuration assessment;
5) release management and delivery.
Quality assurance process(quality assurance process). It provides adequate assurance that the software and its lifecycle processes meet the specified requirements and approved plans. Software quality is understood as a set of properties that characterize the software's ability to meet specified requirements. To obtain reliable estimates of the software being created, the process of ensuring its quality must occur independently of the subjects directly related to software development. In doing so, the results of other supporting processes such as verification, validation, joint assessment, audit and problem resolution can be used. The quality assurance process includes the following activities:
1) product quality assurance;
2) quality assurance of the process;
3) ensuring other indicators of the quality of the system.
Verification process(verification process). It consists in determining that software products, which are the results of some action, fully satisfy the requirements or conditions caused by the previous actions (verification in the narrow sense means formal proof of the correctness of the software).
Certification process(validation process). It provides for determining the completeness of compliance of the specified requirements and the created system or software product with their specific functional purpose. Attestation usually refers to the confirmation and assessment of the reliability of software testing.
Joint Assessment Process(joint review process). It is designed to assess the status of work on the project and software created when performing these works (actions). It focuses primarily on overseeing the planning and management of resources, personnel, hardware and project tools.
Audit process(audit process). It is a determination of compliance with requirements, plans and terms of the contract.
Troubleshooting process(problem resolution process). It provides for the analysis and resolution of problems (including detected nonconformities) regardless of their origin or source, which are discovered during development, operation, maintenance or other processes. Each problem found must be identified, described, analyzed and resolved.
The group of organizational processes in the life cycle of software includes:
Control;
Infrastructure creation;
Improvement;
Release of new versions;
Training.
Management process(management process). It consists of actions and tasks that can be performed by any party that controls their own processes. This party (manager) is responsible for managing the release of the product, managing the project and managing the tasks of the related processes, such as acquisition, supply, development, operation, maintenance, etc.
Infrastructure creation process(infrastructure process). It covers the selection and support (maintenance) of technology, standards and tools, the selection and installation of hardware and software used for the development, operation or maintenance of software. The infrastructure should be modified and maintained in accordance with the changes in the requirements for the respective processes. Infrastructure, in turn, is one of the objects of configuration management.
Improvement process(improvement process). It provides for the assessment, measurement, control and improvement of software life cycle processes. Improvement of life cycle software processes is aimed at increasing the labor productivity of all specialists participating in them by improving the technology used, management methods, the choice of tools and training
staff.
Learning process(training process). It covers initial training and subsequent continuing education of personnel.
International standard IEEE Std 830-1993. Recommendations for the development of software requirements specifications.
Approved December 2, 1993 by the IEEE Standards Committee
Abstract: The content and quality of a good software requirements specification (SRS) is described and several different sample SRS schemas are presented. These guidelines are aimed not only at defining the requirements for the software being developed, but can also be applied to the selection of existing internal and commercial software products.
Keywords: contract, client, prototyping, software requirements specification, supplier, system requirements specification
Introduction
(The introduction is not part of "IEEE Std 830-1993 Guidelines for Developing Software Requirements Specifications") This document describes recommended approaches for creating a software requirements specification. It is based on a model in which the software requirements specification development process results in an unambiguous and complete specification document. This should help
a) To the customers of the software, describe exactly what they want
b) Software providers understand exactly what the customer wants
c) Individuals fulfill the following objectives:
1) Develop a standard software requirements specification scheme for their own organizations
2) Determine the format and content of your own software requirements specifications
3) Include additional requirements items such as a quality checklist or a writer's handbook requirements specification.
Good specifications should provide customers, suppliers, and other individuals with several distinct benefits, such as:
a) Establish the basis for an agreement between customers and suppliers on what the software should do. A complete description of the functions to be performed by the software identified in the SRS will help the potential user determine if the software meets their needs or how the software needs to be modified to fulfill their needs.
b) Reduce development effort. SRS preparation forces various stakeholder groups in the client's organization to rigorously review all requirements prior to project development and further reduces redesign, re-coding, and retesting efforts. A close examination of the requirements in an SRS can reveal omissions, misunderstandings and inconsistencies in the early stages of development, when these problems are more easily corrected.
c) Provide a basis for cost estimates and timetables. The product description that will be designed as defined in the SRS is a realistic basis for project cost estimates and can be used to negotiate proposals or estimate costs.
d) Provide a basis for validation and verification. Organizations can develop their own test and audit plans much more productively with good SRS. As part of the development contract, the SRS provides a framework against which conformity can be measured.
e) Facilitate transmission. SRS provide an easier transfer of software products to new users or installation on new machines. This makes it easier for customers to transfer software to other parts of their organization, and it is easier for suppliers to transfer software to new customers.
f) Serve as a basis for improvement. Since SRS describe the product, but not the project that is developing, then SRS can serve as a basis for further improvement of the finished product. The SRS is subject to change, but it provides a foundation for continuous production evaluation.
1 Overview
The standard describes approaches to creating a software requirements specification. The section has five points.
Clause 1 explains the capabilities of this standard.
Clause 3 contains the definitions used.
Clause 4 provides information basis for the development of SRS.
Clause 5 discusses each of the essential parts of an SRS.
The standard also has annexes that provide alternative templates for SRS formats.
1.1 Scope
Provides guidelines for creating software requirements specifications. Describes the content and attributes of a good software requirements specification (SRS) and presents several sample SRS schemas.
These guidelines are aimed at defining the requirements of the software being developed. It can also be used to assist in the selection of domestic and commercial software products. However, applying these guidelines to software already created can be counterproductive.
When software is included in any large system, such as medical equipment, questions may arise that are outside the scope of this standard.
The standard describes the process of creating a product and the content of the product. Product is a specification of software requirements. The standard can be used to create a software requirements specification directly, or it can be used as a model to define a more specific standard.
The standard does not define any specific methods, terminology (nomenclature) or tools for the preparation of an SRS.
2 References
ASTM 1340-90, Standard Guide for Rapid Prototyping of Computerized Systems
IEEE Std 610.12-1990, IEEE Standard Glossary of Software Engineering Terminology (ANSI).
IEEE Std 730-1989, IEEE Standard for Software Quality Assurance Plans (ANSI).
IEEE Std 828-1990, IEEE Standard for Software Configuration Management Plans (ANSI).
IEEE Std 982.1-1988, IEEE Standard Dictionary of Measures to Produce Reliable Software (ANSI).
IEEE Std 982.2-1988, IEEE Guide for the Use of IEEE Standard Dictionary of Measures to Produce Reliable Software (ANSI).
IEEE Std 983-1986, IEEE Guide to Software Quality Assurance Planning.
IEEE Std 1002-1987, IEEE Standard Taxonomy for Software Engineering Standards (ANSI).
IEEE Std 1012-1986, IEEE Standard for Software Verification and Validation Plans (ANSI).
IEEE Std 1016-1987, IEEE Recommended Practice for Software Design Descriptions (ANSI).
IEEE Std 1028- 1988, IEEE Standard for Software Reviews and Audits (ANSI).
IEEE Std 1042-1987, IEEE Guide to Software Configuration Management (ANSI).
IEEE Std 1058.1-1987, IEEE Standard for Project Management Plans (ANSI).
IEEE Std 1074-1991, IEEE Standard for Developing Software Life Cycle Processes (ANSI).
3 Definitions
In general, the definitions of the terms used in this document follow those set forth in IEEE Std 610.12-1990.5. Key terms are defined below as they are used in this document.
3.1 contract
Legally mandatory documentagreed by the customer and the supplier. It includes technical and organizational requirements, cost and calendar plan for the product. The contract may also contain informal but useful information such as the obligations or expectations of the parties involved.
3.2 customer.
The person or people who pay for the product and usually (but not necessarily) define the requirements. In the context of this document, a customer and a supplier can be members of the same organization.
3.3 supplier
The person or people who make the product for the client. In the context of this document, may be members of the same organization.
3.4 user
A person, or people who work or interact directly with the product. User (s) and client (s) are often not the same person (s).
4 Considerations for producing a good SRS
This clause provides an informational basis for the development of an SRS. Includes the following:
a) The essence of the SRS
b) SRS context
c) Characteristics of good SRS
d) Joint SRS preparation
e) SRS change process
f) Prototyping
g) Inclusion of the project in the SRS
h) Incorporation of design requirements into an SRS
4.1 Nature of the SRS
SFC - technical conditions for a single software product, program, or set of programs that perform specific tasks in a specific environment. An SRS can be created by one or more supplier representatives, one or more client representatives, or both. Clause 4.4 recommends development with the participation of supplier and client representatives.
The main questions that an SRS developer should consider:
a) Functionality. What should the program do?
b) External interfaces. How does software interact with people, system hardware, other hardware, and other software?
c) Performance. What is the speed, availability, response time, recovery times of various software features, etc.?
d) Attributes. What is portability, correctness, maintainability, security, etc.?
e) The design constraints imposed on the implementation. Requirements of any existing standards, execution language, database integrity policy, resource constraints, operating environment (s) of execution, etc.?
SRS developers should avoid placing any development or design requirements in the SRS.
4.2 Environment of the SRS context
It is important to consider the role that SRS plays in general plan project, which is defined by the standard IEEE Std 610.12-1990. The software may contain essentially all of the functionality of a project, or it may be part of larger system... In the latter case, there is usually an SRS that defines the interfaces between the system and the piece of software and contains the requirements for the characteristics and functionality of that piece of software. Of course, the SRS in this case should be agreed upon and expanded with system-wide requirements.
IEEE Std 1074-1991 describes the stages of the software life cycle and the corresponding inputs for each stage. Other standards, such as those listed in clause 2, relate to other stages of the software life cycle and may also complement software requirements.
Since SRS plays a special role in the software development process, the author (s) of SRS must be careful not to go beyond the boundaries of this role. This means that STP
a) Must correctly identify all software requirements. The software requirements are determined by the nature of the problem to be solved, or by a special characteristic of the project.
b) Should not describe any design or implementation details. They should be described at the design stage of the project.
c) Must not impose additional restrictions on the software. Correct if they are defined in other documents such as the quality plan. Therefore, it is correct if the created SRS limits the design framework, but does not define any design details.
4.3 Characteristics of a good SRS
SRS should have the following characteristics
d) Correct
e) Unambiguous
g) Serial
h) Scored for importance and / or stability
i) Verifiable
j) Modifiable
k) Traceable
4.3.1 Correct
SRS are correct if and only if each requirement stated in them must be satisfied in software. There is no tool or procedure that determines correctness. The SRS should be compared with any relevant higher-level specifications, such as a system requirements specification, other design documents, and other relevant standards, to ensure that there is compliance. Additionally, the client or user can determine if the SRS correctly reflects the actual needs. Traceability makes this procedure easier and less error prone (see 4.3.8).
4.3.2 Unambiguous
SRS are inconsistent if and only if each stated requirement has only one interpretation. It is necessary, at a minimum, that each characteristic of the final product be described using a single unique term. In cases where a term used in a particular context could have several meanings, it should be included in the glossary, where its meaning is made more specific.
SRS is an important part of the software life cycle and is used in design, implementation, project control, inspection, testing, and training as described in IEEE Std 1074-1991. An SRS must be interpreted unambiguously by both those who create the SRS and those who use it. However, these groups often do not have the same background and therefore tend to interpret software requirements in different ways. Views that improve the requirements specification for the developer can be counterproductive for the user to understand, and vice versa.
4.3.2.1 Natural language pitfalls
Requirements are often written in natural language (such as English). Natural language is inherently ambiguous. In order to identify ambiguous natural language use, the SRS should be reviewed by an independent party so that the identified ambiguities are corrected.
4.3.2.2 Requirements specification languages
One way to avoid the ambiguity inherent in natural language is to write the SRS in a specific requirements specification language. Language processors automatically detect many lexical, syntactic and semantic errors.
Such languages \u200b\u200bhave disadvantages. They take time to master, and many users find them confusing. In addition, these languages \u200b\u200bare best suited for expressing certain requirements and are related to certain types of systems. Thus, they can have an indirect effect on requirements.
4.3.2.3 Representation tools
In general, the methods for creating requirements, the languages \u200b\u200band the tools that support them fall into three general categories - objects, processes, behavior. Object-oriented approaches are organized in terms of real objects, their attributes, and the services performed by those objects. Process-based approaches organize requirements in a hierarchy of functions that are linked through data streams. Behavioral approaches describe the external behavior of a system in terms of some abstract concept (such as a computable predicate), mathematical functions, or a finite automaton.
The usefulness of such tools and techniques in creating an SRS depends on the size and complexity of the program. No attempt is made here to describe or recommend any particular tool.
When using any of these approaches, it is best to keep the descriptions in natural language. At the same time, those clients who are not familiar with the notation of the language will understand the SRS.
4.3.3 Complete
SRS are complete if, and only if, they include the following elements:
a) Any significant requirements regarding functionality, performance, design constraints, performance, or external interfaces. In particular, any external requirements imposed by the system specification must be identified and addressed.
b) All reactions of the software to all possible types of inputs in all possible situations. It is important to define reactions to both valid data values \u200b\u200band invalid ones.
4.3.3.1 Use of the phrase “to be determined” (Use of TBDs)
Any SRS that use the phrase “to be determined” (TBD) are not complete, however, they are sometimes necessary and must be accompanied by the following
a) By describing the conditions that give rise to the phrase “will be determined” (eg why the answer is not known) in such a way that the situation can be resolved.
b) A description of what must be done to eliminate the phrase “it will be determined” who is responsible for the elimination, when should be eliminated.
4.3.4 Consistent
Integrity refers to inner integrity. If the SRS contradicts higher-level documents, such as the system requirements specification, then this is incorrect (see 4.3.1).
4.3.4.1 Internal consistency
SRS are internally integral if and only if there are no subsets of the individual requirements described in the SRS that are in conflict with each other. There are three types of potential conflicts in an SRS:
a) The specified characteristics of objects may be in conflict. For instance,
1) The output report can be described in one requirement as tabular, and in the other as text.
2) One requirement may state that all indicators should be green, and another requirement that they be blue.
b) There may be a logical or temporary conflict between the two specified actions. For instance.
1) One requirement can determine that the program will add two input values, another - will multiply them.
2) One requirement states that event “A” must always follow event “B”, while another requirement states that events “A” and “B” occur simultaneously.
3) Two or more requirements can describe the same object, but use different terms for that object. For example, a program's request for user input might be called "prompt" in one request and "cue" in another. The use of standard terminology and definitions improves integrity.
4.3.5 Ranked for importance and / or stability
An SRS is rated for importance and / or stability if each requirement has an identifier that identifies the importance and / or stability of that requirement.
Usually, not all software requirements are equally important. Some requirements may be required, especially for critical applications, while others may only be desirable.
Each requirement in an SRS must be assessed in order to make these distinctions clear and explicit. Requirements identification helps:
a. Consumers give a more accurate interpretation of each requirement, which often reveals implicit assumptions,
b. Developers accept correct design solutions and pay the necessary attention to the various parts of the software product.
4.3.5.1 Degree of stability
One method of identifying requirements uses a measure of stability. Stability can be expressed in terms of the number of expected changes to any requirement based on experience and knowledge of likely events affecting the organization, functions and personnel supported by the software.
4.3.5.2 Degree of necessity
Another way to evaluate requirements is to distinguish between requirement classes as mandatory, conditional, and optional.
a) Required. Implies that the software will not be acceptable if these requirements are not included and agreed upon.
b) Conditional. Implies that these requirements will improve the software product, but the software product will be acceptable in their absence.
c) Optional. Implies a class of functions that may or may not deserve attention. This gives the supplier the opportunity to offer opportunities beyond the scope of the SRS.
4.3.6 Verifiable
An SRS is verifiable if and only if every requirement defined in it is verifiable. A requirement is verifiable if, and only if, there is a finite, affordable process by which a person or machine can verify that the software meets the requirement. Any ambiguous requirement is not testable.
Unverifiable requirements include statements like "work well", "good human interface", "will usually happen". These requirements are not testable because it is impossible to define the terms "good", "good", or "usually". The statement "a program should never enter infinite recursion" is untestable, because testing this quality is theoretically impossible.
Example of a verifiable assertion
Completion of the program must be done within 20 seconds in 60% of cases and within 30 seconds in l00% of cases.
This statement is testable because it uses specific terms that are quantifiable.
If no process can be devised to determine whether this requirement in software, the requirement should be removed or revised.
4.3.7 Modifiable
An SRS is modifiable if and only if it has a structure and style such that any changes to requirements can be made easily, completely, consistently and while maintaining the structure. In general, mutability requires in SRS
a) Have a consistent and easy-to-use structure with table of contents, index, and explicit reciprocal links
b) Do not be redundant; that is, the same requirement should not appear in more than one place in the SRS
c) Express each requirement separately rather than mixed with other requirements
Redundancy itself is not an error, but it can easily lead to errors. Redundancy can sometimes help make the SRS readable, but problems can arise when the document is modified. For example, if a requirement was changed in only one of the places where it appears, then the SRS becomes ambiguous. Where redundancy is required, the SRS should include explicit cross-references.
4.3.8 Traceable
An SRS is traceable if the origin of each of the requirements is clear and if the SRS provides easy access to each requirement from documentation generated by subsequent development or from documentation that extends the SRS. Two types of traceability are recommended.
a) Traceability back (i.e. to previous stages of development). It depends on each requirement explicitly referencing the source in earlier documents.
b) Forward traceability (that is, to all documents generated by an SRS). This depends on each requirement in an SRS having a unique name or reference number.
Forward traceability of SRS is especially important when the software enters the operational and maintenance phase. As codes and design documents change, it is necessary to be able to establish a complete set of requirements that could be impacted by such changes.
4.4 Joint preparation of the SRS
The software development process should begin with an agreement between the supplier and the customer on what the finished software should do. This SRS agreement should be jointly prepared. This is important because usually neither the client nor the supplier is qualified to develop a good document individually.
c) Clients usually do not have a good understanding of the software creation and development process to create a usable SRS.
d) Suppliers generally have insufficient understanding of the customer's domain to determine the requirements for a satisfactory system.
Therefore, the client and supplier must work together to produce a well-written and fully understandable SRS.
There is a situation when the system and its software are being developed simultaneously. Then the functionality, interfaces, performance and other characteristics and limitations of the software are not predetermined, but jointly defined more precisely during the development process and are subject to negotiations and changes. This is more difficult, but not less important, since it is necessary to ensure the characteristics stated in 4.3. In particular, an SRS that does not fulfill the requirements of the parent system specification is incorrect.
It does not discuss style, language use, or good language techniques. This is very important because SRS must have good language. Technical book creation tutorials can be used for guidance.
4.5 SRS evolution
SRS can evolve as software products improve. It may not always be possible to determine certain details by the time the project starts. For example, it may not be possible to define all screen formats for a dialog program at the requirements stage. Additional changes may arise when missing parts, deficiencies and errors are found in the SRS.
There are two main points to consider in this process:
a) Requirements should be defined as fully and thoroughly as possible at the current point in time, even if evolutionary changes can be foreseen as inevitable. The fact that the requirements are incomplete should be reflected in the notes.
b) A formal change process should be initiated to identify, manage, track and report changes. Approved changes to requirements should be incorporated into the SRS so that
1) Provide accurate and complete control of changes.
2) Allow viewing of the current and changed parts of the SPS
4.6 Prototyping
Prototyping is often used during the requirements phase of a project. There are many tools that allow you to quickly and easily prototype a system from a template by setting parameters. See also ASTM Std 1340-90.
Prototypes are useful for three reasons:
a) It is very likely that the client will want to review the prototype and respond to it, rather than read the SRS and react to it. So the prototype provides quick feedback.
b) The prototype shows unforeseen aspects of systems behavior. Thus, he not only answers the questions that have arisen, but also asks new ones. This helps to achieve completion of SRS development.
c) Prototype-based SRS tend to undergo fewer changes during development, thus shortening development time.
The prototype should be used as a way to identify software requirements. Some characteristics such as screen types or message formats can be derived directly from the prototype. Other requirements can be obtained by experimenting with the prototype.
4.7 Embedding design in the SRS
The requirement defines the externally visible function or characteristic of the system. The project describes a separate subcomponent of the system and / or interfaces with other subcomponents. SRS creators should clearly distinguish between identifying the required design constraints and designing a specific design. Note that each requirement in the SRS limits the design alternatives. This does not mean that every requirement is a project.
SRS should define what functions should be performed, what data to produce, what result is obtained, where it is located, for whom. SRS should focus on the services to be provided. An SRS generally should not define project items such as the following:
a) Dividing the software into modules
b) Distribution of functions by modules
c) Description of information flow or interaction between modules
d) Choice of data structures
4.7.1 Necessary design requirements
In special cases, some requirements can severely limit the project. For example, privacy or security requirements can be reflected directly in the design. These are requirements like
a) Keep some functions in separate modules
b) Allow limited communication between certain areas of the program
c) Check data integrity for critical variables
Examples of acceptable design constraints are physical requirements, performance requirements, software development standards support requirements, software quality standards.
Therefore, requirements must be formulated from a purely external point of view. When using models to illustrate requirements, remember that the model only indicates external behavior and does not define the design.
4.8 Embedding project requirements in the SRS
The SRS should define the software product, not the process for creating it.
The design requirements provide an understanding between the customer and the supplier regarding contractual issues related to the production of the software and thus should not be included in the SRS. Usually these are items
a) Cost
b) Delivery Schedules
c) Reporting activities
d) Software development techniques
e) Quality assurance
f) Tests and verification criteria
g) Acceptance procedures
Design requirements are defined in other documents, usually a software development plan, software test plan, or work acceptance certificates.
5 The parts of an SRS
This section discusses each of the required parts of the SPET. The sections located in the diagram shown in fig. 1 can serve as a model for developing an SRS.
1. Introduction
1.2 Application limits
1.3 Terms, acronyms, abbreviations
1.5 Overview
2. General description
2.1 Product perspective
2.2 Product functions
2.3 User characteristics
2.4 Limitations
2.5 Assumptions and Dependencies
3. Detailed Requirements (See 5.3.1-5.3.8 for an explanation of possible detailed requirements. See also Appendix A for several different structures of this SRS section)
Applications
Indexes
Figure 1 Sample SRS Scheme
While an SRS does not have to follow the outline or use these section titles, a correct SRS should include all the information discussed here.
5.1 Introduction (Section 1 SRS)
The introduction of an SRS should provide an overview of the entire SRS. It should contain the following subsections:
b) Application limits
c) Definitions, acronyms (abbreviations) and abbreviations
d) Overview
5.1.1 Purpose (1.1 from SRS)
This subsection should do the following:
a) Outline the purpose of the detailed SRS
b) Determine the audience for which the SRS is intended
5.1.2 Scope (1.2 from SRS)
This subsection should
c) Identify the software product (s) to be produced, name (for example, “Server DBMS”, “Report Generator”, etc.)
d) Explain what the software product (s) will and, if necessary, will not do
e) Describe the applications of the software being defined, including important benefits, objects and goals.
f) Consistent with similar statements in higher-level specifications (e.g., system requirements specification), if any.
5.1.3 Terms, acronyms (abbreviations), abbreviations (Definitions, acronyms, and abbreviations) (1.3 from SRS)
This subclause should provide definitions of all terms, acronyms (abbreviations) and abbreviations that are necessary to interpret the SRS properly. This information can be provided through links to one or more annexes to the SRS or through links to other documents.
This subsection should
a) Provide a complete list of all documents mentioned elsewhere in the SRS
b) Identify each document by name, number (if periodical), date, issuing organization.
This information can be provided through links to one or more annexes to the SRS or through links to other documents.
5.1.5 Overview (1.5 from SRS)
This subsection should
a) Describe what the rest of the SRS contains
b) Explain how the SRS is structured
5.2 Overall description (Section 2 of the SRS
This section of the SRS should describe the general factors that affect the product and requirements. This section does not define specific requirements. Instead, it provides a framework for defining them in detail in section 3, and makes them easier to understand.
This section usually consists of the following six subsections:
a) Product Description
b) Product functions
c) User characteristics
d) Limitations
e) Assumptions and dependencies
f) Requirement subsets
5.2.1 Product perspective (2.1 from SPTO)
In this subsection of the SRS this product needs to be considered in terms of related products. If the product is independent and completely autonomous, this should be stated here. If the SRS defines a product that is a component of a larger system, as is often the case, then this subclause should relate the requirements of that larger system to the functionality of that product and should identify the interfaces between that system and that product.
A diagram showing the major components of a larger system, their interactions and external interfaces can be helpful.
This subsection should also describe how the software complies with various internal constraints. For example, it could include:
a) System interfaces
b) User interfaces
c) Computer hardware interfaces
d) Software interfaces
e) Communication interfaces
f) Memory limits
g) Operations
h) Requirements for setting up workplaces
5.2.1.1 System interfaces
In order to meet system requirements, interface descriptions, and system compliance, each system interface must be listed and the functionality of its software identified.
5.2.1.2 User interfaces
It is necessary to determine:
a) The logical characteristics of each interface between the software product and users. It is necessary to include those configuration characteristics (for example, required screen formats, page or window arrangement, content of any messages or menus, availability of programmable function keys) that are required to fulfill software requirements.
b) All aspects of optimizing the interface between the software product and the users who use this product. It may simply include a list of what the system should and should not do from the user's point of view. One example is requiring you to select long or short error messages. Similarly to other requirements, these requirements should be verifiable, for example, "a 4th grade typist can do X in Z minutes after 1 hour of training" rather than "a typist can do X" (This can also be defined in the system specifications of the software under the section entitled “Ease of Use”).
5.2.1.3 Hardware Interfaces
Here it is necessary to define the logical characteristics of each interaction (invoice) between the software product and the hardware components of the system. This includes configuration characteristics (port numbers, instruction sets, etc.), and covers issues such as list of supported devices, support methods, protocols. For example, a terminal can be specified to support full screen or otherwise support a string.
5.2.1.4 Software Interfaces
Here you define the use of other required software items (for example, a data management system, an operating system, or a math package) and interfaces with other application systems (for example, the relationship between the accounts receivable system and the general ledger management system). For each software item required, the following must be provided:
a) Name
b) Mnemonic name
c) Specification number
d) Version number
e) Source For each interface, the following should be provided:
a) Discussion of the purpose of interoperable programs in relation to this product.
b) Defining the interface in terms of message content and format. Correctly registered interfaces do not require a detailed description, but a link to the document describing the interface is necessary.
5.2.1.5 Communications interfaces
Here it is necessary to define various communication interfaces such as local network protocols, etc.
5.2.1.6 Memory constraints
It is necessary to define any applicable characteristics and their values \u200b\u200bfor the main and permanent memory.
5.2.1.7 Operations
Here you need to define normal and special actions, necessary for users, like
a) Different modes of action in the user's organization; e.g. user initiated operations
b) Periods of Conversational Action and Periods of Unresponsive Action
c) Data processing support functions
d) Backup and restore actions
NOTE - This clause is sometimes defined as part of the user interfaces section.
5.2.1.8 Site adaptation requirements
It is necessary here
a) Define requirements for any data or command strings (initialization sequences) that are defined for a given workplace, task, or mode of operation, for example, grid values, safety limits, etc.
b) Determine the characteristics of the workplace or tasks that need to be changed to customize the software for a specific configuration.
5.2.2 Product functions (2.2 from SRS)
This subsection of the SRS should contain a summary of the main functions that the software performs. For example, SRS for the program accounting can use this subsection to define customer account service functions, customer statement and invoice preparation without mentioning the vast amount of detail each of these functions requires.
Sometimes a function summary that is necessary for this part can be obtained directly from the higher-level specification clauses (if any) that fix specific functions in the software product. Note that for the sake of clarity:
a) Functions should be organized into groups that make the list of functions understandable to the client or to someone who reads the document for the first time.
b) Text or graphics techniques can be used to show the various functions and their relationships. Such diagrams are not intended to show the design of a product, but they simply show the logical relationship between variables.
5.2.3 User characteristics (2.3 from SRS)
This subsection of the SRS should describe those general characteristics users for whom the products are intended, including educational level, experience, and technical qualifications. This section should not be used to prevent Page 22
External standards
IEEE Std 830-1993
to formulate detailed requirements, it is rather necessary to explain the reasons why these requirements will appear later in section 3 of the SRS.
5.2.4 Constraints (2.4 from SRS)
This subsection of the SRS should provide a general description of any other factors that limit the developer's choice. They include:
a) Regulatory policy
b) Hardware limitations (e.g. selection time requirements)
c) Interfaces with other applications
d) Parallel work
e) Logging functions
f) Management functions
g) Requirements for high-level languages
h) Signal timing interface protocols (e.g. XON-XOFF, ACK-NACK)
i) Reliability requirements
j) Application criticality
k) Security and privacy considerations
5.2.5 Assumptions and dependencies (2.5 from SRS)
This subsection of the SRS defines a list of factors that affect the requirements defined in the SRS. These factors are not restrictions on the software of the project, but any change may affect the requirements in the SRS. For example, it may be assumed that a particular operating system will be available on the computer hardware intended for the software product. If, in fact, the operating system is not available, the SRS would have to change.
5.2.6 Apportioning of requirements (2.6 from SRS)
This subsection of the SRS should define requirements that may be deferred to future versions of the system.
5.3 Specific requirements (Section 3 of the SRS)
This section of the SRS should contain all the software requirements in sufficient detail to enable developers to design and testers to test a system that satisfies these requirements. Throughout this section, each requirement must provide interaction with users, operators, or other external systems. These requirements should include, as a minimum, a description of all inputs to the system, all outputs of the system, and all functions that are performed by the system in response to inputs or to produce outputs.
As this is often the largest and most important part of an SRS, the following principles should be applied:
a) Detailed requirements shall be declared in accordance with the rules described in 4.3 of this standard.
b) Detailed requirements should be cross-referenced to earlier documents to which they relate.
c) All requirements must be uniquely identified.
d) To improve readability, special attention should be paid to the structuring of requirements.
Before exploring specific ways to structure requirements, it is useful to consider the various sections of the requirements below.
5.3.1 External interfaces
There should be a detailed description of all inputs and outputs of the software system. This subsection is an addition to the interface description in section 5.2. He must not repeat the information in section 5.2.
a) Item name
b) Description of purpose
c) Source of input or destination of output
d) Range, accuracy and / or tolerances
e) Units
f) Timing
g) Relationship to other inputs / outputs
h) Screen Formats / Organization
i) Window formats / organization
j) Data formats
k) Command formats
l) End messages
5.3.2 Functions
Functional requirements define the fundamental activities that must take place in software when receiving and processing input data and when generating output data. They are usually listed as "should" at the beginning of a functional requirement definition. "The system should ..."
Description includes:
a) Validation of data on inputs
b) The exact sequence of actions
c) Dealing with exceptions, including
1) Overflow
2) Communication facilities
3) Error handling and recovery
d) Influence of parameters
e) The relationship of input to output, including
1) Sequences of Input / Output Data
2) Formulas for converting input data to output
The division of functional requirements into sub-functions or sub-processes can be defined. This does not imply that the software under development will have the same division.
5.3.3 Performance requirements
This subsection defines the requirements for static and dynamic numerical characteristics. These requirements may include:
a) Number of terminals to be supported
b) The number of concurrent users to be supported
c) Amount and type of information to be processed
Requirements for static numerical characteristics are sometimes outlined in a separate section called System Load.
Dynamic numerical requirements can include, for example, the number of transactions and tasks, the amount of data that will be processed within certain time intervals for normal and peak workload conditions.
All of these requirements must be stated in terms of units of measurement.
For example, 95% of transactions must be processed in less than 1 s rather than the operator should not have to wait to complete the transaction.
NOTE - Numerical constraints applied to one specific function are usually defined as part of a sub-paragraph describing the operation of that function.
5.3.4 Logical database requirements
This defines the logic requirements for any information that needs to be put into the database. May include:
d) Types of information used by different functions
e) Frequency of use
f) Access methods.
g) Data entities and their relationships
h) Integrity constraints
i) Data storage requirements
5.3.5 Design constraints
This defines design constraints that may be imposed by other standards, hardware constraints, and so on.
5.3.5.1 Standards compliance
This subclause should define the requirements that follow from existing standards or guidelines. It can include:
a) Message format
b) Data naming
c) Accounting procedures
d) Audit tracing
For example, you can define a software requirement to log the processing. Such a protocol is required for some applications to meet the minimum requirements of regulatory or financial standards. A logging requirement may, for example, specify that all changes to the payroll database must be logged in a log file with the values \u200b\u200bthat were before and after the changes.
5.3.6 Software system attributes
There are many characteristics of software that can serve as requirements. It is important that these requirements are defined in such a way that they can be objectively verified. The following points provide examples of some of the characteristics.
5.3.6.1 Reliability
This defines the factors required to establish the required reliability of the system software at the time of delivery.
5.3.6.2 Availability
It defines the factors required to guarantee a certain level of availability for the entire system, such as checkpoints, recovery and restart.
5.3.6.3 Security
It defines the factors that must ensure that the software is protected from accidental or malicious access, use, modification, destruction or disclosure. Specific requirements in this area could include the following:
a) Use some encryption methods
c) Assign some functions to different modules
d) Limit links between certain areas of the program
e) Check data integrity for critical variables
5.3.6.4 Maintainability
It defines software parameters that directly relate to the ease of maintenance of the software. There may be some requirements for defining modularity, interfaces, complexity, etc. Requirements should not be placed here just because they are believed to be good design practice.
5.3.6.5 Portability
It defines software parameters that relate to the ease of porting the software to other machines and / or operating systems. May include:
f) Percentage of components with machine dependent code
g) Percentage of code that is machine dependent
h) Using a tested portable language
i) Using a specific compiler or subset of languages
j) Using a specific operating system
5.3.7 Organizing the specific requirements
For non-trivial systems, the detailed requirements can be extensive. For this reason, it is recommended that they be structured in such a way that they are optimal for understanding. There is no optimal structure for all systems. Different ways of structuring requirements for different classes of systems are provided in Section 3 of the SRS. Some of the structures are described in the following subsections.
5.3.7.1 System mode
Some systems behave very differently depending on the mode of operation. For example, a control system may have different sets of functions depending on its use: training, normal or emergency. When organizing the division into modes, use the diagrams shown in sections 1 or 2 of Appendix A. The choice is determined by whether the interfaces and program execution depend on the mode of operation.
5.3.7.2 User class
Some systems provide different sets of functions for different classes of users. For example, a lift control system presents various options for passengers, service workers and firefighters. When organizing this section, use the diagram shown in Section 3 of Appendix A.
5.3.7.3 Objects
Objects are real entities that have a duplicate within the system. For example, in a patient monitoring system, objects are patients, sensors, nurses, rooms, doctors, medications, etc. Associated with each object is a set of attributes (of that object) and functions (performed by that object). These functions also call services, methods, or processes. When organizing this section, use the outline
shown in Section 4 of Appendix A. Note that feature sets can be categorized by attributes and services. They are grouped together as classes.
5.3.7.4 Feature
A feature is an externally desired service provided by a system that may require a sequence of inputs to produce the desired result. For example, in a telephone system, features include intercity calling, expedited calling, and conference calling. Each feature is generally described in a sequence of action-reaction pairs. When organizing this section, use the diagram shown in Section 5 in Appendix A.
5.3.7.5 Stimulus
Some systems can be better organized if their functions are described in terms of impact. For example, the functions of an automatic aircraft landing system can be organized into sections for the following effects: loss of power, gust of wind, sudden change in roll, excessive vertical speed, etc. When organizing this section, use the diagram shown in Section 6 of Appendix A.
5.3.7.6 Response
Some systems can be better organized if their functions are described in terms of generating a reaction. For example, the functions of the personnel accounting system can be organized into sections corresponding to all the functions associated with the creation of a payroll, corresponding to all the functions associated with the creation of the current list of employees, etc. Use section 6 in Appendix A (replace all words “impact” with “reaction”).
5.3.7.7 Functional hierarchy
When none of the above organizational charts not suitable, full functionality can be organized into a hierarchy of functions organized by shared inputs, shared outputs, or shared internal data. Data flow diagrams and data dictionaries can be used to show the relationship between functions and data. Use diagram 7 in Appendix A to organize this section.
5.3.8 Additional comments
When a new requirement is defined, it can follow several structuring methods described in 5.3.7.7. In such cases, structure the detailed requirements into multiple hierarchies tailored to the specific needs of the specified system. For example, see 8 in Appendix A for an organization combining user class and trait. Any additional requirements can be placed in a separate section at the end of the SRS.
There are a large number of descriptions, methods, and automated support tools available to assist in documenting requirements. Mainly, their value is the structuring function. For example, when organizing by mode, state machines or state diagrams can be useful; when structuring by object, object-oriented analysis can be helpful; when structuring by characteristics, exposure-response sequences can be useful; at
structuring by functional hierarchy, data flow diagrams and data dictionaries can be useful.
In any of the diagrams in 1-8, sections that are referred to as "Functional Requirements" may be written in their own language (for example, English language), in pseudo-codes, in the system description language, or in the form of four subsections: Introduction, Inputs, Processing, Outputs.
5.4 Information support (Supporting information)
Information support facilitates the use of SRS. It includes
b) Indices
c) Applications
5.5 Appendixes
Applications are not always considered part of the actual requirements specification and are not always necessary. They can include
a) Sample I / O formats, cost-of-training analysis descriptions, or user survey results
b) Accompanying or background information that may assist readers of an SRS
c) Description of the problems to be solved by the software
d) Special packaging instructions for code and media needed for security, export, bootstrap or other requirements
If there are applications, the SRS should explicitly declare whether or not the applications are considered part of the requirements.
6 Appendix A (Informative)
6.1 Template for SRS Section 3 organized by mode: Version 1
3 Detailed requirements
3.1 Requirements for external interfaces
3.1.4 Communication interfaces
3.2.1 Mode 1
3.2.2 Mode 2
3. 2. m. Mode m
3. 2.m.1 Functional requirement m.
3. 2. m.n Functional requirement m.n
3.3 Performance requirements
3.4 Project limitations
3.6 Other requirements
6.2 Template for SRS Section 3 organized by mode: Version 2
3. Detailed requirements
3.1. Functional requirements
3.1.1 Mode 1
3.1.1.1 External interfaces
3.1.1.1.1 User interfaces
3.1.1.1.2 Computer hardware interfaces
3.1.1.1.3 Software interfaces
3.1.1.1.4 Communication interfaces
3.1.1.2 Functional requirements
3.1.1.2.1 Functional requirement 1
3.1.1.2.n Functional requirement n
3.1.1.3 Performance requirements
3.1.2 Mode 2
3.1.m. Mode m.
3.2 Project limitations
3.3 System software specifications
3.4 Other requirements
6.3 Template for SRS Section 3 organized by user class
3 Detailed requirements
3.1.1 User interfaces
3.1.2 Computer hardware interfaces
3.1.3 Software interfaces
3.1.4 Communication interfaces
3.2 Functional requirements
3.2.1 User class 1
3.2.1.1 Functional requirement 1.1
3.2.1.n Functional requirement 1.n
3.2.2 User class 2
3.2.m. User class m.
3.3 Performance requirements
3.4 Project limitations
3.5 System software specifications
3.6 Other requirements
6.4 Template for SRS Section 3 organized by facility
3 Detailed requirements
3.1 External interface requirements
3.1.1 User interfaces
3.1.2 Computer hardware interfaces
3.1.3 Software interfaces
3.1.4 Communication interfaces
3.2 Classes / objects
3.2.1 Class / Object 1
3.2.1.1 Attributes (native or inherited)
3.2.1.1.1 Attribute 1
3.2.1.1.n Attribute n
3.2.1.2 Functions (methods. Own or inherited)
3.2.1.2.1 Functional requirement 1.
3.2.1.2.m Functional requirement m
3.2.1.3 Messages (received or sent)
3.2.2 Class / Object 2
3.2.p Class / object p
3.3 Performance requirements
3.4 Project limitations
3.5 System software specifications
3.6 Other requirements
6.5 Template for SRS Section 3 organized by features
3 Detailed requirements
3.1 External interface requirements
3.1.1 User interfaces
3.1.2 Computer hardware interfaces
3.1.3 Software interfaces
3.1.4 Communication interfaces
3.2 System features
3.2.1 System Feature 1
3.2.1.1 Introduction / purpose
3.2.1.2 Sequence of action / reaction
3.2.1.3 Related functional requirements
3.2.1.3.1 Functional requirement 1
3.2.1.2.n Functional requirement n
3.2.2 System Feature 2
3.2.m A specific feature of the m.
3.3 Performance requirements
3.4 Project limitations
3.5 System software specifications
3.6 Other requirements
6.6 Template for SRS Section 3 organized by impact
3 Detailed requirements
3.1 External interface requirements
3.1.1 User interfaces
3.1.2 Computer hardware interfaces
3.1.3 Software interfaces
3.1.4 Communication interfaces
3.2 Functional requirements
3.2.1 Impact 1
3.2.1.1 Functional requirement 1.1
3.2.1.n Functional requirement l.n
3.2.2 Impact 2
3.2.m Impact m
3.2.m.1 Functional requirement m.1
3.2.m.n Functional requirement m.n
3.3 Performance requirements
3.4 Project limitations
3.5 System software specifications
3.6 Other requirements
6.7 Template for SRS Section 3 organized by functional hierarchy
3 Detailed requirements
3.1 External interface requirements
3.1.1 User interfaces
3.1.2 Computer hardware interfaces
3.1.3 Software interfaces
3.1.4 Communication interfaces
3.2 Functional requirements
3.2.1 Information flows
3.2.1.1 Data flow diagram 1
3.2.1.1.1 Data entities
3.2.1.1.2 Pertinent processes
3.2.1.1.3 Topology
3.2.1.2 Data flow diagram 2
3.2.1.2.1 Data entities
3.2.1.2.2 Pertinent processes
3.2.1.2.3 Topology
3.2.1.n Data flow diagram n
3.2.1.n.1 Data Entities
3.2.1.n.2 Pertinent processes
3.2.1.n.3 Topology
3.2.2 Description of processes
3.2.2.1 Process 1
3.2.2.1.1 Input data entities
3.2.2.1.2 Process algorithm or formula
3.2.2.1.3 Affected data entities
3.2.2.2 Process 2
3.2.2.2.1 Input data entities
3.2.2.2.2 Process algorithm or formula
3.2.2.2.3 Affected data entities
3.2.2.m Process m
3.2.2.m.1 Input data entities
3.2.2.m.2 Process Algorithm or Formula
3.2.2.m.3 Affected data entities
3.2.3 Data structure specifications
3.2.3.1 Structure 1
3.2.3.1.1 Record type
3.2.3.1.2 Elementary fields
3.2.3.2 Structure 2
3.2.3.2.1 Record type
3.2.3.2.2 Elementary fields
3.2.3.p The p structure
3.2.4 Data Dictionary
3.2.4.1 Data Element 1
3.2.4.1.1 Name
3.2.4.1.2 Presentation
3.2.4.1.3 Units / Format
3.2.4.1.4 Precision / Accuracy
3.2.4.1.5 Range of values
3.2.4.2 Data Element 2
3.2.4.2.1 Name
3.2.4.2.2 Presentation
3.2.4.2.3 Units / Format
3.2.4.2.4 Precision / Accuracy
3.2.4.2.5 Range of values
3.2.4.1.q Data Item q
3.2.4.q.1 Name
3.2.4.q.2 View
3.2.4.q.3 Units / Format
3.2.4.q.4 Precision / Accuracy
3.2.4.q.5 Range
3.3 Performance requirements
3.4 Project limitations
3.5 System software specifications
3.6 Other requirements
6.8 SRS Section 3 Template Showing Multiple Organization
3 Detailed requirements
3.1 External interface requirements
3.1.1 User interfaces
3.1.2 Computer hardware interfaces
3.1.3 Software interfaces
3.1.4 Communication interfaces
3.2 Functional requirements
3.2.1 User class 1
3.2.1.1 Feature 1.1
3.2.1.1.1 Introduction / purpose
3.2.1.1.2 Sequence of action / reaction
3.2.1.1.3 Related functional requirements
3.2.1.2 Feature 1.2
3.2.1.2.1 Introduction / Purpose
3.2.1.2.2 Stimulus / response sequence
3.2.1.2.3 Related functional requirements
3.2.1.m. Feature 1.m
3.2.1.m.1 Introduction / Purpose.
3.2.1.m.2 Sequence of exposure / response
3.2.1.m.3 Related functional requirements
3.2.2 User class 2
3.2.n User class n
3.3 Performance requirements
3.4 Project limitations
3.5 System software specifications
3.6 Other requirements
- In contact with
Maintenance has always been recognized as one of the main stages of the software life cycle. By the mid-70s, it was recognized that maintenance is a stage that takes more than 50% of the development and implementation of a software tool (PS).
Continuity of business processes and safety depend on the efficiency of work at the stage of support and maintenance. corporate informationnecessary for the life of companies.
For complex software systems involving long-term use and maintenance of many versions, there is an urgent need to regulate their life cycle, to formalize and apply standards profiles and certification of software quality.
The use of regulatory and normative documents makes the life cycle of the software system more definite, predictable in structure, content, quality and cost. Documentation, informativeness and comprehensibility determine the composition and quality of support documentation.
In order to correctly and effectively organize the longest and most important stage of the PS life cycle - Maintenance of the PS, which requires the most time, labor and material resources, it is necessary to consider the recommendations set out in international and national standards containing provisions for the optimal organization of this stage.
First, you need to analyze the interpretation of the maintenance stage in various standards.
Software maintenance is defined by the IEEE Standard for Software Maintenance (IEEE 1219) as the modification of a software product after release to service to eliminate failures, improve performance and / or other characteristics (attributes) of the product, or adapt the product for use in a modified environment. Interestingly, this standard also deals with the issues of preparation for maintenance before transferring the system into operation, however, structurally this is done at the level of the corresponding information application included in the standard.
In turn, the 12207 life cycle standard (IEEE, ISO / IEC, GOST R ISO / IEC) positions maintenance as one of the main life cycle processes. This standard describes maintenance as a process of modifying a software product in terms of its code and documentation to solve emerging problems during operation or to realize the needs for improving certain characteristics of the product. The challenge is to modify the product while maintaining its integrity.
The international standard ISO / IEC 14764 (Standard for Software Engineering - Software Maintenance) defines software maintenance in the same terms as standard 12207, emphasizing the work of preparing for maintenance activities before putting the system into real operation, for example, planning issues regulations and support operations.
After the transfer of the PS to operation, it becomes necessary to maintain its operability at the level of the requirements enshrined in the terms of reference. This task includes both the elimination of software glitches and errors, and the possible increase in functionality. To streamline these works, you must refer to the provisions prescribed in the standards.
A number of sources, in particular the IEEE 1216 standard, define three categories of maintenance work: correction, adaptation and improvement. This classification has been updated in iSO standard/ IEC 14764 introduction of the fourth component.
Thus, today they talk about four categories of accompaniment:
1. Corrective maintenance assumes changes caused by the need to eliminate (correct) actual errors in the software product. Corrective maintenance is carried out in case of non-compliance of the software product with the established requirements.
2. Adaptive maintenance associated with the need to adapt the software product to the changed environment (conditions). These changes are related to the implementation of new requirements for the system interface, the system itself, or hardware.
3. Full support identifies changes to improve the performance of the software and its maintainability. These changes may result in the provision of new functionality to users, revision of the technology for developing the accompanying documents, or changes in the documents themselves.
4. Preventive maintenance is aimed at changes caused by the need to eliminate (fix) potential (hidden) errors in the software product. Preventive maintenance is usually carried out for software products related to ensuring or protecting human life.
Maintainability is one of the quality indicators of the software system, as well as an important characteristic for the customer, supplier and user.
The maintainability or maintainability of a software system is defined, for example, by the IEEE Glossary (610.12-90 Standard Glossary for Software Engineering Terminology, 2002 update) as the ease of maintenance, extension, adaptation, and adjustment to meet specified requirements. The ISO / IEC 9126-01 standard (Software Engineering - Product Quality - Part 1: Quality Model, 2001) considers the possibility of maintenance as one of the characteristics of quality.
Maintainability must be determined prior to software development, that is, a corresponding agreement between the customer and the supplier has been prepared as part of the “preparation” work from the ordering process according to (ISO / IEC, # M12291 1200009075 GOST R ISO / IEC) 12207 # S. The developer forms a maintenance plan, which should reflect specific methods for ensuring the maintenance of the software, the corresponding resources and the algorithm for performing work.
The quality of the software is an important aspect of the maintenance of a software product. Maintainers should have a software quality assurance program that encompasses the six quality characteristics specified in ISO / IEC 9126. Software maintenance should implement an appropriate process for defining, describing, selecting, applying and improving methods for evaluating (measuring) the performance of the software.
To reduce the cost of further maintenance, throughout the entire development process, it is necessary to specify, evaluate and control the characteristics that affect the ability to maintain. Regular implementation of such work facilitates further maintenance, increasing its maintainability (as a quality characteristic). This is quite difficult to achieve, since such characteristics are often ignored during development.
As already discussed earlier, software support is a costly stage of the life cycle, to optimize the work of which, it is necessary to apply various methods to assess the cost of support.
The cost of maintenance work is influenced by many different factors. ISO / IEC 14764 specifies that "there are two most popular methods for estimating maintenance costs: - a parametric model and the use of experience." Most often, both of these approaches are combined to improve the accuracy of the estimate.
There are various methods of internal performance assessment of support staff to compare performance different groups accompaniment. The maintainer should define the metrics against which the related work will be evaluated. The standards IEEE 1219 and ISO / IEC 9126-01 (Software Engineering - Product Quality - Part 1: Quality Model, 2001) offer specialized metrics focused specifically on maintenance issues and related programs.
Maintenance work should be strictly regulated and described, contain detailed inputs and outputs of processes. These processes are covered in the standardsIEEE 1219 and ISO / IEC 14764.
The maintenance process begins according to the IEEE 1219 standard from the moment the software is put into operation and deals with issues such as planning maintenance activities.
The ISO / IEC 14764 standard clarifies the provisions of the 12207 life cycle standard related to the maintenance process. The maintenance work described in this standard is similar to the work in IEEE 1219, except that it is grouped slightly differently.
Let us consider in more detail the excerpts from the GOST R ISO / IEC 14764-2002 standard, which contains the full authentic text of the international standard ISO / IEC 14764.
In accordance with GOST R ISO / IEC 14764-2002, which describes the software maintenance process, the details of the software maintenance process must be documented so that the maintenance personnel act within a single process. The system of indicators (metrics) of quality should facilitate the implementation of the maintenance process and contribute to the improvement (modernization) of this software system.
The maintainer must (5.5.2.1 GOST R ISO / IEC 12207) analyze the report (message) on the problem or proposal for modification on their impact on organizational issues, the existing system and interface links with other systems.
Based on the analysis carried out, the maintainer should (5.5.2.3 GOST R ISO / IEC 12207) develop options for implementing the change. Before making changes to the system, the maintainer must (see 5.5.2.5 GOST R ISO / IEC 12207) obtain approval of the selected change option in accordance with the contract and confirmation that the change made meets the requirements established in the contract (see 5.5.4.2 GOST R ISO / IEC 12207). The maintainer must (5.5.2.4 GOST R ISO / IEC 12207) document: a problem report or proposal for a modification, the results of their analysis and options for implementing changes.
For appropriate control of the system transfer, a facility transfer plan must be developed, documented and executed (5.5.5.2 GOST R ISO / IEC 12207). Users should be involved in the planned work.
For support activities, there are a number of unique jobs and practices that must be taken into account when organizing support. SWEBOK (Software Engineering Body of Knowledge) provides the following examples of these unique characteristics.
Broadcast: controlled and coordinated software transfer activities from developers to a group, service, or organization responsible for further support.
Accepting / rejecting modification requests : requests for changes can both be accepted and transferred to work, and rejected for various justified reasons - the volume and / or complexity of the required changes, as well as the effort required for this. Relevant decisions can also be made on the basis of priority, assessment of feasibility, lack of resources (including the lack of the ability to involve developers in solving modification tasks, if there is a real need), approved planning for implementation in the next release, etc.
Means of notifying maintenance personnel and tracking the status of modification requests and error reports : an end-user support function that initiates activities to assess the need, prioritize and cost-benefit modifications associated with a request or reported problem.
Impact analysis: analysis of the possible consequences of changes made to the existing system.
Software support: work to advise users in response to their information requests, for example, regarding the relevant business rules, validation, data content and specific user questions and their reports of problems (errors, failures, unexpected behavior, misunderstanding of aspects of working with the system, etc.); P.).
Contracts and commitments: these include the classic Service Level Agreement (SLA), as well as other contractual aspects, on the basis of which the support group / service / organization performs the relevant work.
In addition, there are additional workthat support the maintenance process, described by SWEBOK as the work of maintenance personnel, not involving explicit interaction with users, but necessary to carry out the corresponding activity. Such activities include: maintenance planning, configuration management, verification and validation, software quality assessment, various aspects of review, analysis and evaluation, audit and user training. Also such special (internal) work includes training of support personnel.
Table 1 below provides a brief overview of the main standards used in the organization of maintenance. information systems.
Table 1. Standards in the field of information systems maintenance
|
Standard |
Name |
Description |
At the exit |
|
12207 IEEE, ISO / IEC, GOST R ISO / IEC |
Software life cycle processes |
This International Standard establishes, using well-defined terminology, a general framework for software life cycle processes that can be guided in the software industry. |
1) Excerpts from user reports on detected defects and proposed corrections (cl.5.5.2.1 GOST R ISO / IEC 12207) 2) Adjustment proposals (p.5.5.2.3 # M12291 1200009075 GOST R ISO / IEC 12207 # S) 3) Notification to users about the release of a new version of the AU (p.5.5.2.5 # M12291 1200009075 GOST R ISO / IEC 12207 # S) 4) Object transfer plan (p.5.5.5.2 # M12291 1200009075 GOST R ISO / IEC 12207) |
|
14764 ISO / IEC GOST R ISO IEC |
Software maintenance (Standard for Software Engineering - Software Maintenance) |
This International Standard details the maintenance process specified in 12207 (ISO / IEC, # M12291 1200009075 GOST R ISO / IEC) |
|
|
9126 ISO / IEC GOST R ISO / IEC |
Information technology. Evaluation of software products. Quality characteristics and guidelines for their application |
Maintainers must have a software quality assurance program covering six quality characteristicsestablished in # M12291 1200009076 GOST R ISO / IEC 9126 # S. When maintaining a software tool, an appropriate process must be implemented to determine, describe, select, apply and improve methods for assessing (measuring) the characteristics of this tool. |
Quality characteristics: 1) Functionality 2) Reliability 3) Practicality 4) Efficiency 5) Maintenance 6) Mobility |
|
GOST 34.603-92 |
Types of tests of automated systems |
The standard establishes the types of tests for the AU and general requirements to their implementation. AU tests are carried out at the stage of "Putting into operation" in accordance with GOST 34.601 in order to check the compliance of the created AU with the requirements of the technical task (TZ) |
To plan for all types of tests, a document is developed "Program and test procedure". The autonomous test program indicates: 1) list (functions to be tested; 2) a description of the relationship of the test object with other parts of the software; 3) conditions, procedure and methods of testing and processing of results; 4) acceptance criteria for parts based on test results. During trial operation, substations are work log, in which information is entered on the duration of the NPP operation, failures, failures, emergency situations, changes in the parameters of the automation object, corrections of the documentation and software, adjustment of technical means. |
|
IEEE 1219-1998 |
IEEE Standard for Software Maintenance (Standard for Software Maintenance) |
This standard describes an iterative process for the management and implementation of software maintenance activities. The use of this standard is not limited by the size, complexity, criticality, or application of the software product. |
|
In addition to international and national standards governing the process of maintaining information systems discussed above, there are various guidance documents and internal (corporate) standards, which are based on international standards. At the same time, special attention is paid to the quality of documentation, which largely determines the competitiveness of software. When creating complex software products and ensuring their life cycle, it is necessary to make a selection of the necessary standards and form the entire set of documents, that is, a profile that provides regulation of all stages and maintenance work.
Let's consider the application of standards for the maintenance of information systems on a specific example.The high-quality functioning of the system implies constant adaptation to the changing business processes of the organization, as well as quick response to failures and troubleshooting. In this regard, the management of CJSC "Firm" SoftInKom "made a decision on the need to conclude an agreement with the developers of the corporate information system (CIS)" Eastern Express "to update and maintain the system.
Maintenance of the Vostochny Express CIS includes several types of maintenance (according to GOST R ISO IEC 14764-2002). Namely, corrective support, which is associated with changes caused by the need to eliminate (correct) actual errors in the software product. Corrective maintenance is carried out in case of non-compliance of the software product with the established requirements. As well as adaptive and full support that modernizes the software product.
The need for corrective maintenance appears when system errors occur, as well as errors caused by the user. Failures caused by the user include, for example, the accidental deletion of important data, which leads to the need to use a system backup. System errors occur quite often, especially after installing new releases, since new releases involve quite serious changes in existing data processing technologies, the connection of new modules.
The need for adaptive support arises when changes in the functioning of a business process (holding a promotion, changing external printing forms, orders from the head office, etc.), or when performing any operations inconveniently, which requires changes in the system interface.
Full support is much less common than other types of support. It is carried out when there are a lot of similar incidents, requests and wishes of users, as well as after the CIS designers have analyzed the capabilities of the system.
Maintenance work can be roughly divided into four stages: analysis of defects and modifications, implementation of modifications, assessment and acceptance of maintenance results, transfer to another platform. Each of these steps contains specific inputs, outputs, and must be documented.
Table 2 summarizes the main stages of maintenance and exit in the paragraph of the accompanying documentation.
Table 2. Stages of the information system maintenance process
|
Input data |
Escort stage |
Output |
Exit in paragraph |
|
Basic version of the speaker, error messages from users |
Analysis of defects and modifications |
Confirmation (not confirmation) of an error or defect, an example of modification |
Excerpts from user reports of detected defects and suggestions for correction. |
|
Modification proposals accepted as documented in the Defect Log |
Modification implementation |
Implemented and documented changes |
Determination of what is subject to modification (analysis of the log of detected defects and suggestions for correction). |
|
Modifications made, documented in the log of prepared and approved adjustments |
Evaluation and acceptance of maintenance results |
Approval for satisfactory completion of the modification as defined in the maintenance contract |
Prepared notice to users about the release of a new version of the AU |
|
Migration plan |
Porting to another platform (to another environment) |
Completed migration plan, notifying users of migration |
Description of the migration plan. Notifying the user about plans and actions to move. |
In accordance with GOST R ISO / IEC 12207 5.5.2.1, the maintainer should review user reports of the problem. The MantisBT incident registration system is used to automate the registration and accounting of requests from users of the Vostochny Express CIS. Based on data registered in the system MantisBT generates a document "Report on defects identified by users" containing the following fields: incident number, creation date, category, essence of the incident, proposed solution.
On the basis of the analysis carried out, the maintainer must (5.5.2.3 GOST R ISO / IEC 12207) develop options for implementing changes. For this, a document “Journal of prepared and approved adjustments of the new basic version of the CIS” is being developed, containing the following data: category, defect identified by the accompanying organization, defect identified by users of the corporate information system, correction.
Further, the maintainer must (5.5.4.2 GOST R ISO / IEC 12207) receive confirmation that the change made meets the requirements specified in the contract. For these purposes, a document "Notice to users about the release of a new version of CIS" is formed and confirmation of consent to install a new release is expected.
To properly control the transfer of the system, there must be
Goals and objectives of the design methodologyBY... Main areas of designBY... Stages of creationBY.
Software (Software) is an intellectual product that does not depend on the environment on which it is written, including programs, rules, and related data, which, when loaded into the execution area of \u200b\u200ba computer program, ensures its operation.
Software (Software product) A collection of computer programs, procedures, and possibly associated documentation and data.
Software (Software product) - any set of computer programs, procedures and associated documentation and data resulting from the development of software and intended for delivery to the user [ISO / IEC 12207]. Note. Products include intermediate products and products intended for users such as developers and maintenance personnel.
Software development (Software engineering) is a form of development that applies principles of computer science, information technology, mathematics and the application field to achieve cost-effective solutions to practical problems through software.
Software design is the process of building applications of real size and practical value that meet specified functionality and performance requirements.
Programming - it is one of the activities included in the software development cycle.
Stages of software development
1. Understand the nature and scope of the proposed product.
2. Choose a development process and create a plan.
3. Collect the requirements.
4. Design and assemble the product.
5. Test the product.
6. Release and maintain the product.
By the life cycle of a program we mean a set of stages:
Analysis of the subject area and creation of technical specifications (interaction with the customer)
Designing the program structure
Coding (set of program code according to project documentation)
Testing and Debugging
Implementation of the program
Program support
Recycling
The concept of the life cycle (LC) of software. Lifecycle definition by the international standard ISO / IEC 12207: 1995. The main processes of the life cycle of software.
The software life cycle is an ongoing process that begins from the moment a decision is made about the need to create it and ends at the moment it is completely retired from service.
The life cycle (LC) of software (software) is defined as the period of time that begins from the moment a decision is made on the need to create software and ends at the moment of its complete withdrawal from service.
The main regulatory document regulating the composition of software life cycle processes is the international standard ISO / IEC 12207: 1995 "Information Technology - Software Life Cycle Processes" (ISO - International Organization for Standardization - International Organization for Standardization, IEC - International Electrotechnical Commission - International Commission on It defines the structure of the life cycle, containing the processes, actions and tasks that must be performed during the creation of software.
In this standard Software (or software product) is defined as a collection of computer programs, procedures, and possibly associated documentation and data.
Process is defined as a set of interrelated actions (a set of interrelated activities) that transform some initial (input data) into output (results). Each process is characterized by certain tasks and methods of their solution, initial data obtained from other processes, and results.
Each processdivided into a set of actions, each act - per set tasks... Each process, action or task is initiated and executed by another process as needed, and there are no predetermined execution sequences (of course, while maintaining the connections according to the input data).
Basic lifecycle processes :
Order (purchase);
Action - initiating an acquisition
Action - preparation of application proposals
Action - preparation and amendment of the contract
Action - Supervision of supplier activities
During acceptance the necessary tests are prepared and performed. Completion of work under the contract is carried out in case of satisfaction of all conditions of acceptance
Supply;
Delivery initiation
Planning
Development;
The development process includes the activities and tasks performed by the developer and includes the following activities
Preparatory work
Analysis of system requirements
System architecture design at a high level is to determine the components of its equipment, software and operations performed by the personnel operating the system. The system architecture should be consistent with the system requirements as well as accepted design standards and practices.
Analysis of software requirements
Software architecture design
Software coding and testing
Software integration
Software qualification testing
System integration
Installing software
Software acceptance
Exploitation; covers the actions and tasks of the operator - the organization operating the system and includes the actions:
Preparatory work includes the following tasks by the operator:
planning activities and works to be performed during operation and setting operational standards;
determination of procedures for localization and resolution of problems arising during operation.
Operational testing is carried out for each next edition of the software product, after which it is transferred to operation.
System operation
User support
Processescorts provides for the actions and tasks performed by the escort service. In accordance with the IEEE-90 standard under escort means making changes to the software in order to fix bugs, improve performance, or adapt to changed operating conditions or requirements.
Preparatory work escort service includes the following tasks:
planning of actions and work performed in the process of maintenance;
determination of procedures for localization and resolution of problems arising in the process of maintenance.
Analysis of problems and requests for software modification
Software modification
Inspection and acceptance
Removing software from operation carried out at the decision of the customer with the participation of the operating organization, support service and users. In this case, software products and related documentation are subject to archiving in accordance with the contract.
The concept of the life cycle (LC) of software. Lifecycle definition by the international standard ISO / IEC 12207: 1995. Auxiliary processes of the life cycle of software.
See point 2
Supporting Lifecycle Processes :
Documenting; a formalized description of information created during the life cycle of software.
The documentation process includes actions:
preparatory work;
design and development;
release of documentation;
escort
Configuration managementto her; to determine the status of software components in the system, manage software modifications, describe and prepare reports on the status of software components and requests for modification, ensure completeness, compatibility and correctness of software, manage software storage and delivery. According to IEEE standard - 90 under configuration Software is understood as the totality of its functional and physical characteristics established in the technical documentation and implemented in the software.
{!LANG-5d3f630781f302860168aaeb2fdfa194!}
{!LANG-935984ffc4476255e69639a5466617b7!} {!LANG-981350ba387fe4c4e8aea92f3c033606!}
{!LANG-67328f6fc1cee4d0033a69f60408970b!} {!LANG-a7ccf865dd21344d2d5c0a015ea34c48!}
{!LANG-4e7cd4a276fb5727df5eaa149adcc05a!} {!LANG-6f1ade5ff7a8b4c5a59b6ba6d3906259!}
{!LANG-3036bc91f06a01225e1cfb7e07d9f993!} {!LANG-e3f007acc56d86163163e11ffe4ab2be!}
{!LANG-2f477a50dee76acda7cbe9d1b77b99b1!} {!LANG-6e1abcc2f496082d54d736980c9b8d44!}
{!LANG-3290667384dd2445dbf2d800412ba75b!}
{!LANG-3bf0554750a9766ca3b86a78aee6386a!}{!LANG-7285b8a03571778f9f5e55a02d1fe73a!} {!LANG-7a09fcb7ef7a8fe1d509faf08f96406a!} {!LANG-a19758131a5899516be55b8ddfa43fd6!}
{!LANG-f991aab4ee090ec18d8fc68f90e0c713!}
{!LANG-a6049a28c8a9cd1cbc9f2c8246f21169!}
{!LANG-67415b39e1430c91f933bab83d121edb!}
{!LANG-1d783b65717919c70e913ecc77e35f67!}
{!LANG-ad59d2301ccbf93e87667c0e4e7478b2!}{!LANG-fbd20468ebde5291088a271b7c97d4ee!}
preparatory work;
{!LANG-412b04a0344110b756c0c7d01f788ebb!}
{!LANG-96f50355f75a40e6a85e83d4a4c0ffec!}
{!LANG-984f4cea7f4300466ea6b0851e014ba5!}
{!LANG-edf0cde035c9ae5e37f344d2f5121671!}
{!LANG-18243f81ce8cf78dea2622f6fdb128c0!}
{!LANG-09a3ec35a8e1afb0a60573eb22ae40c2!}
{!LANG-64d3663c51436a24b580c17ea0c78fdd!}
{!LANG-93dc21b9a2156485fc2cbaa7dcca465f!}
{!LANG-0f660d2b6ac2fce06cc545ba55022254!}
{!LANG-86bfe850f30fe220867141d9fecdf991!}
{!LANG-80799e3d685d4b51b1e711e1796fa50f!}
{!LANG-455271ab0fed31e72f3bf13092e0cc1c!}
{!LANG-610ec6325356d26bd369aa08e8310de0!};
{!LANG-2485ed36ae13ac627be97c6ce713d784!}
{!LANG-e9d2e4d912bfcc486c7f15d654be1b47!}{!LANG-2e1c590d9154311640adbc753442c597!}
{!LANG-6bb1da6f8feba3400e5d32fceb9c9076!}
{!LANG-2721a6eb1f1c75d4316a6571900e92e7!}
preparatory work;
{!LANG-aa400d089d24054b579ddf2b33f50f2e!}
{!LANG-e3d3c56f06c65ebadbef56e36b843ad5!}
{!LANG-adb12d4d77c9381fa66ce4569892e192!};
{!LANG-2a5d65944a865c6a972deec1a541982d!} {!LANG-69c55194f4fb4644472780ff0fdf0850!}
{!LANG-8365daf907a630b3865465187a20d45b!}{!LANG-a160f8e8cc206527b98f4c85b212dd9c!} {!LANG-fa2830acdf5b9f8535d19dd85fb588cb!}.
{!LANG-b836a6289ddd23a30b4046478b0ead54!}
{!LANG-189b26d0054dfbbe5d56790ee92e84ff!}
{!LANG-2f32f64cac86699708d46561234adaa0!}
{!LANG-f5135456082202248d35e1360a83f44e!} :
Control;
{!LANG-05d98d2768540a56dc69a64a3c547b9a!}
{!LANG-1b25c4a2b6e8f361b80457dbb70427de!}
{!LANG-4959ba4bd03704790637e9292668e2a0!} . {!LANG-993d1c61e1d5828fff88e7b02da442d3!}
{!LANG-c5e59d61743d693003df6f89bd9d7f12!} {!LANG-f88fb64086696b5c89271bdd286dfb44!}
{!LANG-08ca24abf1393c4985002d69d627b402!}
{!LANG-5d5880cd21c6e237c4457e02bccfc1a0!}
{!LANG-c4629ee373d379c6cd2e53761e9639dd!}
{!LANG-abfbf26b122226e995aa0bfe201ccc5b!}
{!LANG-ff0c160c60d2ae7eb26abe5a9b584a2c!}
{!LANG-d8284eb22cae87936f930f99e921375e!}
{!LANG-82f0be8ac47bd7d293b2eee0eecbe72c!}
{!LANG-c46c1df19f7266a8b3184be658a70099!}
{!LANG-00aaa518c733d66f211344524e8c3516!}
{!LANG-77d2b2304df1b9b52cb8e62d885544a8!}
{!LANG-5d02886cb15f07ecba4804e9958956cf!}
Improvement;
{!LANG-50d2a5c78225f8f51321113f5ad7c63a!}
Training.
{!LANG-312e3b3027db967cf08420d332c58123!}
{!LANG-2cc09164c16e9f7dc3d7de5917b13acf!}
{!LANG-2bbfd05921b3609d4617a12009830f13!}
{!LANG-1e4a5b2a4bba5a3f085de3b27bfaedc5!}
{!LANG-472ba17252304f5fa5640bfc535cd764!}
{!LANG-e544cf420989c0aea4599562ce744dd7!}
{!LANG-47188c6fddc33b81a29cf5f1f4652791!}
{!LANG-640a05f26d2b4c207d29f6b824a60a41!}
{!LANG-7ae8c6f2d32d01df2d824465be48de83!} {!LANG-e6174f352ff48c6cd6e84c2f7450ed74!} {!LANG-b030dd0e85c5a739c76910e4d54f8945!} {!LANG-bd28bcbb91045d253bc50e095214cc8a!} {!LANG-b81ed17312cb77bfdef592243b4ede7b!} {!LANG-f3c87d6d46767c33f8b167182b4f6de8!} {!LANG-146eb314eb401ab14b6e87251db0fec5!} {!LANG-9288590cb99f7366c41fd4af8eb9dc8a!} {!LANG-56faa3d5ff990afff40dbd4f45354d3f!} {!LANG-7e6441c6a65cf9dcd2c92b8fe02fae9a!} {!LANG-e352eb55226a45a82bc0880b566aabce!}
{!LANG-5ad4c2f2ac2eee584639c866b5253491!} {!LANG-7ec11a383611a97e0262e885caf6a478!} {!LANG-7bee8c692779cb2ccdc42ec33890a7db!} {!LANG-6acaec302900a6c47166b101c92fa22b!} {!LANG-fb23af89f43bb02cf228d983827519c2!}
{!LANG-0ead04904a56c258c4ec19a25828a642!}.
{!LANG-23c048afddee9e110d4d0f3d37374b63!} {!LANG-33c07ccc81dc842230612079d40a83e7!}/ {!LANG-08cc53cf3b59242db39abbd6da972aad!} 12207: 1995 {!LANG-9928eab8bfedce3de41b94c89c112c23!}
{!LANG-623e087bd5bc3de4e2c6308959f8e0b5!}
2) {!LANG-77c0f88f9729aeb334c9499c25d1a82f!}{!LANG-9928eab8bfedce3de41b94c89c112c23!}
{!LANG-c9634517da07405c37a81b43e0fe1e76!}
{!LANG-c4f9b404bba5101b98777c4d5b856f94!} {!LANG-f30d71999581a07d2e4a9fc3b478e869!} {!LANG-0b0b608856e42a3bb643ca5bf2ef01f0!}
{!LANG-7e3a1a31847ae5b28514dcdf5a3b63eb!}
{!LANG-87389e6d7167acc541360af28b86fba4!}
{!LANG-5205fc2b3956cb80bf044dd86dd8d2c0!}
{!LANG-672d2d4f686fc7157806478d7314239a!}
{!LANG-c8e78bef9929931178ef5e8c8ca80842!}
{!LANG-6ab05d1bb83017eb0ee84c82caa7f7ce!}
{!LANG-466991636d4e773a6fa10c31513b7624!}
{!LANG-68507f9bbacfc909517c57feb7af7379!}
{!LANG-0f54e935b608ac08b31bba7c711bf1e8!}
{!LANG-c042816168e6062d2fcc151113183ac2!}
{!LANG-640e4eb21d6ac7227f76625410dc6a6f!}
{!LANG-1c9e58c631d64f8d841f6422b2e35dfe!} :
{!LANG-6b26d018dfd2b481328ad13dbfcb7876!}
{!LANG-28455be9131a6e888ca10fedd0d0bd18!}
{!LANG-089cae2478390a1e069a45df97d33024!}
{!LANG-b600bf4b3d19c55653bc9a5bd3ef193a!} {!LANG-5f6cf0af2db84c998a8210e0e341b78b!}
{!LANG-1b513c4cc8bb2c303dcfc40b2cea1629!} {!LANG-673ffc855438b5b4a62f607280f8d6d2!}{!LANG-43a0b70d960cec36cd42858c31afa248!} 
{!LANG-a5aa6aa549d000f38bb0403245c98531!}
{!LANG-919a74cdfe490fb43a40b317cd334b01!}{!LANG-257036848af2cdf3d26714c21615183b!}
{!LANG-2747362e5e40c0076c2768dda3b01662!}
{!LANG-1bb7371f4e87f81ba47a78d87c941f9e!}
{!LANG-5e4c8b38b4635599d367cc6c7d21b3b4!}
{!LANG-f9bbdbc47c8b3085eba84a7c4a71a74f!}
{!LANG-9a4ab0b02310bc05942be3a4a6044b4d!}
{!LANG-f395fd7ca016e3a18b8de798cd9c3784!} {!LANG-631cadd5007d0ec95eb8fa4d79a9c2c7!} :
{!LANG-0b05778e99c93fa2b6ecf9a7ca369e1a!} {!LANG-217ecb5d6b04b59c40a29b8166315f5f!}
{!LANG-4342b855cba33dab2d1a8b18578f6abf!} {!LANG-83608ac2d83ca78dda4b9664456a1d69!}
{!LANG-9879cdf48e1fc4faa548f63d2f48ece9!} {!LANG-4c45be282c504c4e315198ceb768ea8a!}
{!LANG-347a437600c485e8b5b3c93bb4547fdf!} {!LANG-04d52c863acfd6460aa92c4d0aeda269!}
{!LANG-54d0e02cdc7a54d48cd3e9258802778c!} {!LANG-e5cdbf6ab27953d17752b9a23017bebd!}
{!LANG-991177857927b7a8c7303a6f5b41243e!}
{!LANG-0ea740c3e0313a346e24373b67a374d0!} {!LANG-7db4093933cc68f0fdea6865524b6d4d!} :
{!LANG-e2097a524e79bdab1b68b7fd909a5b08!}
{!LANG-c4036cc24dad247e309700494c1973ff!}
{!LANG-574e5e6200e51faa2b4948e93c0b0efc!}
{!LANG-508e44faeeadf2ef7d2022092af97fa8!}
{!LANG-c5ec3befbb06f671ff929de680fc7934!}
{!LANG-b0c8f7c1c08560938478cd382398ec7d!}
{!LANG-5681cff430da5ec954387dc1bebcc7da!}
{!LANG-b8b5316210026f49d3d9be85c25e78e4!}
{!LANG-6893d8db1543aa7b2f863168fda9a06a!}
{!LANG-684e0c7709c52e31b73e9dc1026c056c!}
{!LANG-82816d5a13eab5f60c156a5839310459!} {!LANG-9eb1a2aa268eaaeed6c6963a549a0342!}
{!LANG-753155a91b86f176bdd7304cf5cbbb1c!} {!LANG-8991a19cde9467876ec2c72773434f8d!}
{!LANG-d66a9e9ad81c831166705c04e23dc092!} {!LANG-31cca918e1c74c14924e17390ec9522f!}
{!LANG-d82e0ba42463e540c1a1d5a0e581b8f3!} {!LANG-b36b0c60cb6d320e044da27a8c316661!}
{!LANG-275e3308976885ecf743f25fed524751!} {!LANG-8195f7b7395a9924e5b6d96f9e102d1f!}
{!LANG-34690bf8793726e1cc086c1779ef5813!} {!LANG-243383b399168c2f5dad9a257f0ecbde!}
{!LANG-a2373308488cb23c869425415596f541!} {!LANG-1dfc1ebaaba260f966ecafa3fa5bd2b5!}
{!LANG-8ac463a863bc351f54ed162d3edb77cc!} {!LANG-62867057a306da19a27d1197854424f1!}
{!LANG-0708cfcbd3874dbdf0be9a2a9dca9477!} {!LANG-9cf74b3cf8aeb135451d75c132c5a7ab!}
{!LANG-632efe716b1876c28b0c55da16f4cc0b!} {!LANG-b9926788adb6c861ad938770e41737b7!}
{!LANG-be80731f968b421e11aa19fca9ad3a5f!}
{!LANG-3b502449d7fcb31db1be020b8bf99ee5!}
{!LANG-e40c63db26c5ae34beaffd9845663526!}
{!LANG-3267f61798c1a6bfb0b027e79a7e69c2!}
{!LANG-e66976b469ee5e809df5987cb6abfa3d!}
{!LANG-e25248a83de318aa3256fc0be649f8dc!}
{!LANG-04397cf8196b19ef11b6ff387193f835!}
{!LANG-61d2d1d142b6edf0e3d8cdda3dc4a4dc!}:
{!LANG-63fa89808b6f88506cbefc9e622bf7c5!}
{!LANG-a5e3cd9d12a8bb8cef860f1a0c9af13e!}
{!LANG-043d1f83596990b2b1fd28a297bd5dd0!}
{!LANG-7816ff361188c24e81fbfa3d070aaaf8!}
{!LANG-6a203eaf5823720e164b0d8b95b96a37!}
{!LANG-6d6f36d6aa8b3f591fc4e9df8faaf231!}
{!LANG-ccc2a989f0c1238e35533d6f93c27640!}
{!LANG-b5bbd3fc1b721b9fa49a9c66f74a09fb!}
{!LANG-3030553fd4cf81e2dcda485074c494e5!}
{!LANG-ee91deb9efa9d725c03dee8d068e302d!}
{!LANG-7e75ddfdb7007a83eba20fe8a9c33d59!} {!LANG-95391fa15baaa0f49f22140b5946a24b!}
{!LANG-166df469610d7e6b321075cc38c2f683!}
{!LANG-481bf6c49f4d5e30428d7a21f3195e2c!}
{!LANG-a07e645078cb87dfe4db0437519bc64f!}
{!LANG-c9abd79c94464a3499406f3aae91dc64!}
{!LANG-cfbf5b7cddffdd7c5adfea570f9a6b97!}
{!LANG-4e05a56aa412880890c5d5c97d05ca98!}
Management process{!LANG-c3da6552f0ee6d1b5b01f8cc92f7fcd5!}
{!LANG-d329cdf998bfa132c1f7bafabf661dff!} {!LANG-056e32d449a7e3d2784d868721e3571d!}{!LANG-f89e3a134fc4b5fcac8a2b29e8e608a5!}
Management process{!LANG-32131ac2c07c47e19879b0d643470a40!}
- {!LANG-4c4577ef4ba506c7ada3a4e4368a0a13!}
- {!LANG-a7b627f7e50d980c171b958c8806a185!}
- {!LANG-a65ef8987d0fdbe6e9cf5bfdd67670e9!}
- {!LANG-ba97b44785fff697e152c9476e79c674!}
- {!LANG-e1308c13d3becece5b9baf4df004588d!} {!LANG-2fe096cd346a2cbac710abdfb5e86010!}{!LANG-6816d82be7cdd83f3c311bb96ed2f0af!}
- {!LANG-cf2d34fd1911c6fc45006e367fa08ee5!}
{!LANG-4f78d98930511fd12c925ec7d6b8ec92!}{!LANG-3809714de53b63bc2d2e616cc2c96ba9!} {!LANG-c02ea2913c8da6d0efef36790acfa654!}{!LANG-13a7f257553a0594cbf776e77a35b336!}
{!LANG-4f78d98930511fd12c925ec7d6b8ec92!}{!LANG-dc9a10cb6593d5e525f27e64ba752162!}
- {!LANG-72bce04d753d70e51d9a4f27fdad7bb6!}
- {!LANG-9b818826797e7254d59370a421d6150b!}
- {!LANG-5faafdb6f520bf985a22a60906183252!}
- {!LANG-fb83967f5bfcf02e7a0b4e31ebe2cd34!}
{!LANG-5487f71c033314a2c799e552c07a7921!}
{!LANG-57eb8148b81edf728dc8b1e30f234cd9!}
- {!LANG-5a5499270e040a5228bba18b31d84b72!}
- {!LANG-b38df7d041d1bc00c47a4d97c6db65cf!}
- {!LANG-1a58b6df9837b986249b9c080e5d12f8!}
- {!LANG-28ed191636af3932ba255611bc21cb0f!}
- {!LANG-6f4d8ef85afd46bf7fbf004e1cfcb6b6!}
- {!LANG-886faee149b8030089e42b0f22c9b10f!}
- {!LANG-7d4d7375206c724110f12c68899d31fb!}
- {!LANG-26a8634b80fe5616b49d825348cdd296!}
- {!LANG-49f3591bf12e7a65c1721a1b50322b6d!}
- {!LANG-b379560e321819c0dd2d42c3b53ee439!}
{!LANG-532b871ad2abb92fd3484e53b4d1c566!}
{!LANG-bfb1cc46726b9918a45b389bd91ef5de!}
{!LANG-0bcb42a5887941514c93cd28bc6c73df!} {!LANG-253c67af4ac467abe0e954c26093ec57!}{!LANG-e008d2e58bce0d38e2e67831f8c5deaf!}
{!LANG-b56eeba6d256e7b12510b984ef41f8d9!}
{!LANG-0a6cdd97bb5f0db9367f4c8f20e6c72f!}
{!LANG-07fc81d87b0a8d1f6591a26156262a85!}
{!LANG-104d0afb06e02987984d56cc13f2d87c!} {!LANG-f6446105567a9e329bf6057585138d41!}{!LANG-b0738b0e664be24414af856cabf5254d!}
{!LANG-10a6a01ad7b0bfacd0100a31b91b698d!}
{!LANG-39fc28f778e546ff1079b9e37c4c64d1!}
Management process{!LANG-acc224c9a5ad78dfbc4b4dbeda78bfb6!}