Similar presentations:
Стандарты в разработке требований. Тема 4
1.
Тема 4Стандарты в разработке требований
2.
• Стандарты в разработке SRS• Существует множество стандартов системной инженерии,
опубликованных:
Международная организация по стандартизации (ISO)
Международная электротехническая комиссия (IEC)) и
Институт инженеров по электротехнике и электронике (IEEE),
Многие стандарты имеют перекрестные ссылки, а некоторые,
Кроме того, по мере изменения технологий некоторые стандарты
устаревают или устаревают.
3.
• Международный стандарт является результатом гармонизацииследующих источников:
- ISO/IEC/IEEE 29148:2011 Systems and software
engineering — Life cycle processes — Requirements
engineering
- ISO/IEC 12207:2017 (IEEE Std 12207-2017), Systems and software
engineering — Software life cycle processes
ISO/IEC 15288:2015 (IEEE Std 15288-2015), Systems and software
engineering — System life cycle processes
ISO/IEC/IEEE 15289:2019, Systems and software engineering —
Content of life-cycle information products (documentation)
ISO/IEC/IEEE 24765- 2017, Systems and software engineering —
Vocabulary
ISO/IEC/IEEE 24766-2009, Systems and software engineering —
Guide for requirements engineering tool capabilities
4.
- ISO/IEC/IEEE 24748-4:2016(en) Systems and software engineeringLife cycle management Part 4: Systems engineering planning
- ISO / IEC 25010 : 2011 Systems and software engineering — Systems
and software Quality Requirements and Evaluation ( SQuaRE ) —
System and software quality models
• ISO/IEC 25030:2019 Systems and software engineering —
Systems and software quality requirements and evaluation
(SQuaRE) — Quality requirements framework
- ISO/IEC TR 19759, Software Engineering — Guide to the Software
Engineering Body of Knowledge (SWEBOK)
- IEEE Std 730™-2014 - IEEE Standard for Software Quality Assurance
Processes
5.
20172007
2015
2017
2019
2018
6.
ISO/IEC/IEEE 24766-2009,Systems and software engineering
Guide for requirements
engineering tool capabilities
Se aliniează
Se aliniează
Folosește termeni
Folosește
termeni
ISO/IEC/IEEE 24765-2017
Systems and software engineering
Vocabulary
ISO/IEC/IEEE 15288:2015,
Systems and software engineering
System life cycle processes
ISO/IEC/IEEE 24748:2018(en)
Systems and software engineering
Life cycle management
Part 4: Systems engineering planning
IISO/IEC 25030:2019
Systems and software engineering —
Systems and software quality
requirements and evaluation (SQuaRE)
Quality requirements framework
SO/IEC/IEEE 12207:2017,
Systems and software engineering
Software life cycle processes
contribue
ISO / IEC 25010 : 2011
Systems and software engineering
- Systems and software Quality
Requirements and Evaluation ( SQuaRE )
- System and software quality models
contribue
Poate fi utilizată
în conjuncție
ISO/IEC/IEEE 15289:2019,
Systems and software engineering
Content of life-cycle information
products (documentation)
Poate fi utilizată
în conjuncție
ISO/IEC/IEEE 29148:2011
Systems and software engineering
— Life cycle processes
— Requirements engineering
7.
Краткое описание стандартов8.
• ISO/IEC/IEEE 29148 МЕЖДУНАРОДНЫЙ СТАНДАРТСтандарт триггер при разработке требований к
информационной системе или программному продукту
Настоящий международный стандарт устанавливает требования
для разработки набора требований к ИТ-продуктам, которые
должны быть созданы в течение жизненного цикла системы,
продукта или услуги.
утверждение о соответствии продуктов ИТ настоящему
стандарту означает, что пользователь стандарта производит
требуемые ИТ элементы в соответствии с положениями
настоящего стандарта и пользователь стандарта демонстрирует,
что разработанные ИТ-продукты, соответствуют требованиям к
содержанию, определенным в этом стандарте.
9.
• Этот стандарт определяет необходимые процессы, которые должныбыть реализованы при разработки требований к системам и
программным продуктам (включая услуги) на протяжении всего
жизненного цикла.
• Он содержит руководство по применению требований и процессов,
описанными в стандартах:
ISO / IEC/IEEE 12207: 2017 și
ISO / IEC/IEEE 15288: 2015,
- Он определяет необходимые элементы ИТ-продуктов, которые должны
быть разработаны путем внедрения процессов разработки требований,
- Он определяет содержание, необходимое для требуемых ИТэлементов, и - Предоставляет рекомендации по формату ИТ элементов
и связанным с ними модулями.
10.
SO/IEC/IEEE 12207:2017,Systems and software engineering
Software life cycle processes
contribue
contribue
ISO/IEC/IEEE 15288:2015,
Systems and software engineering
System life cycle processes
ISO/IEC/IEEE 29148:2011
Systems and software engineering
— Life cycle processes
— Requirements engineering
11.
• Стандарт применяется теми, кто использует или намереваетсяиспользовать ISO / IEC 15288 и ISO / IEC 12207 для проектов, которые
относятся к:
• системы искусственного интеллекта,
• программно-интенсивные системы,
• программно-аппаратные продукты
• и услуги, связанные с этими системами и продуктами,
несмотря на:
Область проекта (продукты),методология, размер или сложность,
Любое лицо, осуществляющее деятельность по разработке требований для
обеспечения того, что применение процессов разработки требований
соответствуют стандартам: - ISO/IEC/IEEE 15288: и/или- ISO/IEC/IEEE 12207
12.
• Содержание документа по Разделам:4. Термины, определения и сокращения
5. Концепции.
6. Процессы.
7. Информационные элементы
8. Руководство по информационным элементам
9. Содержание информационного элемента
9.3 Документ спецификации требований заинтересованных сторон (StRS)
9.4 Документ спецификации системных требований (SyRS)
9.5 Документ спецификации требований к программному обеспечению (SRS)
13.
ISO / IEC / IEEE 15288 "Sisteme şi Software Engineering-Proceseale ciclului de viaţă al sistemului"
https://www.acq.osd.mil/se/docs/15288-Guide-2017.pdf
14.
• Стандарт ISO / IEC / IEEE 15288 " определяет процессы,разделенные на четыре категории:
- процессы согласования;
-процессы организации проекта;
-технологические процессы управления;
-технические процессы.
Каждый процесс определяется целью, результатами и действиями.
ISO 15288 включает 30 процессов, которые дают 123 результата,
полученных в результате 403 действий.
Примерами этапов жизненного цикла, описанных в документе,
являются: концепция, разработка, производство,
использование, поддержка и вывод из эксплуатации.
15.
• Рамочный стандарт ISO/IEC 12207• Областью применения стандарта является «Стандартизация в области систем
информационных технологий (включая микропроцессорные системы) и
оборудования».
• Стандарт устанавливает высокоуровневую архитектуру жизненного цикла
программного обеспечения.
• Жизненный цикл начинается с идеи или потребности, которые могут быть
полностью или частично удовлетворены программным обеспечением, и
заканчивается с выводом программного обеспечения из эксплуатации. Архитектура
построена с набором процессов и взаимозависимостей между этими процессами.
• Вывод процесса основан на двух фундаментальных принципах: модульность и
ответственность.
• Модульность. Процессы являются модульными; то есть они максимально связаны и
минимально связаны в практически возможной степени. Отдельный процесс
посвящен одной функции.Ответственность. Считается, что процесс отвечает за часть
жизненного цикла программного обеспечения. Другими словами, каждая сторона
имеет определенные обязанности. Ответственность – один из ключевых принципов
управления качеством
16.
• Управление процессами основано на двух фундаментальныхпринципах: модульность и ответственность.
• Модульность. Процессы являются модульными;
то есть они максимально взаимосвязаны и минимально
взаимозависимы. Отдельный процесс посвящен одной функции.
• Ответственность. Считается, что один процесс отвечает
за часть жизненного цикла программного обеспечения.
Другими словами, каждая сторона имеет определенные
обязанности. Ответственность является одним из ключевых
принципов всеобщего управления качеством.
17.
• Процессы жизненного цикла Рамочного стандарта ISO/IEC 12207.• Процессы сгруппированы в три класса:
• Первичные процессы;
• Поддерживающие процессы;
• Организационные процессы
-Первичные процессы представляют наиболее важные движения жизненного
цикла; - приобретение, поставка, разработка, эксплуатация и
обслуживание;
Поддерживающими процессами являются документация, управление
конфигурацией, обеспечение качества, совместная проверка, аудит,
верификация, валидация и решение проблем.
Организационные процессы поддерживает другой процесс при выполнении
специализированной функции;организационными процессами являются
управление, инфраструктура, совершенствование и обучение.
Организация может запустить организационный процесс для установления,
контроля и улучшения процесса жизненного цикла.
18.
Procesele ciclului de viaţă.Standardul cadru ISO/IEC 12207
19.
Proiectarea canonicăEtape de proiectare
Etapa 1. Studiul SI existent şi
definirea cerinţelor noului
sistem
Etapa 8. Mentenanţa
Sistemului proiectat
Etapa 7. Lansarea în
exploatare
Etapa 2. Elaborarea
Concepţiei Sistemului
Informaţional
Etapa 3. Elaborarea
Caietului de Sarcini
Etapa 4. Elaborarea
Proiectului tehnic
Etapa 6. Implementarea codului
şi perfectarea documentaţiei
Etapa 5. Elaborarea
Proiectului de detaliu
20.
21.
• Стандарт ISO/IEC/IEEE 15289:2019, Системная и программнаяинженерия. Содержание информационных продуктов жизненного
цикла (документация)
• Область применения
• Этот документ определяет цель и содержание всех идентифицированных
систем и информационных элементов (документации) относительно
жизненного цикла программного обеспечения и управления услугами.
• Содержание информационной статьи определяется в соответствии с
типовыми видами документов, указанными в пункте 7, и конкретным
назначением документа, указанным в пункте 10 Стандартa.
• Этоn документе предполагаеn, что организация выполняет процессы
жизненного цикла или предоставляет услуги по разработке систем или
программного обеспечения, используя один или оба из следующих
стандартов:
- ISO/IEC/IEEE 12207:2017 процессы жизненного цикла программного
обеспечения;
- ISO/IEC/IEEE 15288: 2015 процессы жизненного цикла системы
22.
• ISO/IEC/IEEE 15289: Наконец-то ясность в документации по программномуобеспечению?
Название ISO/IEC/IEEE 15289: «Системная и программная инженерия.
Содержание элементов информации о жизненном цикле (документация)».
Как следует из названия, он устанавливает спецификации для содержания
документации по программному обеспечению.
Это делает стандарт идеальным для:
Помощь во внедрении других стандартов, таких как ISO/IEC/IEEE 12207:2017.
Проверка соответствия этим стандартам
Определение документов, необходимых для документации программного
обеспечения
Определение содержания этих документов
Это означает, что ISO/IEC/IEEE 15289:2019 является стандартом, который
затрагивает каждую организацию, разрабатывающую программное
обеспечение.
23.
ISO/IEC/IEEE 15288:2015,Systems and software engineering
System life cycle processes
SO/IEC/IEEE 12207:2017,
Systems and software engineering
Software life cycle processes
contribue
contribue
ISO/IEC/IEEE 15289:2019,
Systems and software engineering
Content of life-cycle information
products (documentation)
ISO/IEC/IEEE 29148:2011
Systems and software engineering
— Life cycle processes
— Requirements engineering
24.
• Для каждого процесса или услуги жизненного цикла можноподготовить политику, план, процедуры и отчеты,
-а также многочисленные записи, запросы, описания и
уточнения.
Такая разработка схемы документации будет более строгой, чем
указано в:
- ISO/IEC/IEEE 12207:2017
- или
- ISO/IEC/IEEE 15288:2015.
25.
• Пользователи данного Стандарта несут ответственностьза выбор модели жизненного цикла проекта и сопоставление
процессов, действий и задач, описанных в этом документе, с этой
моделью.
• Стороны также ответственны за выбор и применение
методологий, методов, моделей и приемов,
соответствующие проекту».
• Таким образом, информационные элементы объединяются
или подразделяются в соответствии с моделью жизненного
цикла, как это необходимо для целей проекта или
организации, как определено в Разделе 4 и Разделе 5 данного
стандарта.
26.
a) Целевая аудитория: кто должен читать этот стандарт?Стандарт адресован людям, занимающимся документацией
программного обеспечения в следующих ролях:
Rol
Руководитель проекта
Обязанности в контексте ISO/IEC/IEEE 15289
Определение процесса управления информацией
Определение требований к документации (и,
следовательно, документов и их содержания)
Покупатель (программного Определение требований к документации, которую
обеспечения)
должен выпускать производитель
Разработчик ( реализация, Написание документации по разработке
тестирование)
программного обеспечения и систем
Менеджер по качеству
Проверка соответствия стандартам (в этом отношении
упоминаются ISO/IEC/IEEE 12207 и ISO/IEC/IEEE 15288)
Повышение качества процессов, устройств и услуг
27.
• рекомендуетя создавать конкретные требования кдокументам в рабочих инструкциях и контрольных
списках для проверки документов.
• Например, для спецификации требований к программному
обеспечению должна явным образом требоваться проверка
того, определена ли среда выполнения на основе аппаратного
обеспечения и операционной системы (включая версию).
28.
29.
TitleSection
Summary
The standard wants to describe the content of all documents in a software
documentation but not a management system
1
Scope
2
Normative references References to ISO/IEC/IEEE 12207 and ISO/IEC/IEEE 15288
3
4
5
6
7
8
9
10
Terms, definitions and
29 definitions. But the document classes are only defined for the first time in section 7
abbreviated terms
Purpose, intended users, applicability (software systems and software projects of all
Applicability
kinds)
The standard can be used to check conformity with ISO/IEC/IEEE 12207 and
Conformance
ISO/IEC/IEEE 15288
Life-cycle data and
General requirements for documents and records and the difference between them.
information items
See section TODO
Generic types of
Overview of seven document classes and their generic content (see below)
information items
Mapping of
information items to Mapping to the standards ISO/IEC/IEEE 12207 and ISO/IEC/IEEE 15288
the life cycle processes
Specific information on records, which the standard interprets slightly differently to
Records
ISO 9000
Specific information item
Specific guidance for individual document types, e.g., “software architecture description”
(document) contents
30.
• In section 10, ISO/IEC/IEEE 15289 describes a total of 74document types, such as Release Plan or System architecture
description.
• The standard splits all these document types into seven
document classes.
• However, it does not use the term document class, preferring
to use the term Generic type of information items.
31.
Doc
cla
ss
Document class
1
Description
2
Plan
3
Policy
4
Procedure
5
Report
6
Request
7
Specification
Description
Examples
Representation of a planned or actual function, Software architecture, service
service, product, component, etc.
catalog, operational concept
V&V plans, software
Defining when and how specific processes or
development plan, risk
activities will be carried out and by who
management plan
Quality policy, risk policy
Defining the top-level aims of an organization
(although is not specified by ISO
to achieve specific goals
15289)
Detailed definition of when and how a certain Instructions for use, test
process, a certain activity or task should be
instructions, SOP on processing
carried out, including, if applicable, the tools complaints
Test report, problem report,
Description of the results of activities
incident report, review minutes
Change request, customer
Information to ask for a response or reaction satisfaction survey, RFP (request
for proposal)
Contract, software requirements
Requirements for a service, product or process
specification, SLA
32.
Цель- Стандарт описывает содержание всех документов вдокументации по программному обеспечению, но не в системе
управления.
Ссылки на ISO/IEC/IEEE 12207 and
ISO/IEC/IEEE 15288
33.
34.
35.
36.
ISO/IEC/IEEE 24765:2017 Systems and softwareengineering — Vocabulary
37.
Se alinieazăFolosește
termeni
ISO/IEC/IEEE 24765-2017
Systems and software engineering
Vocabulary
ISO/IEC/IEEE 15288:2015,
Systems and software engineering
System life cycle processes
SO/IEC/IEEE 12207:2017,
Systems and software engineering
Software life cycle processes
contribue
contribue
ISO/IEC/IEEE 15289:2019,
Systems and software engineering
Content of life-cycle information
products (documentation)
ISO/IEC/IEEE 29148:2011
Systems and software engineering
— Life cycle processes
— Requirements engineering
38.
• ISO/IEC/IEEE 24765:2017 содержит общий словарь, применимый ковсем работам по разработке систем и программного
обеспечения.
• Он разработан для сбора и стандартизации терминологии.
• ISO/IEC/IEEE 24765:2017 предназначен для использования в
качестве полезного справочника для тех, кто занимается
информационными технологиями, и для поощрения
использования систем и стандартов разработки программного
обеспечения,
• ISO/IEC/IEEE 24765:2017 включает ссылки на стандарты активных
источников для определений, чтобы можно было дополнительно
изучить концепции и требования системной и программной
инженерии.
39.
• Цель стандарта - определить термины,используемые в настоящее время в данной
области, и стандартные определения этих
терминов.
• Этот стандарт содержит общий словарь,
применимый ко всем работам по разработке
систем и программного обеспечения.
• Словарь ISO/IEC/IEEE 24765:2017 содержит 4633
терминов и определений.
https://www.iso.org/obp/ui/#iso:std:iso-iecieee:24765:ed-2:v1:en
40.
• Области системной и программной инженериипродолжают развиваться по мере развития
информационных технологий.
• Генерируются новые термины, и для существующих
терминов принимаются новые значения.
• Этот международный стандарт был подготовлен для
сбора и стандартизации терминологии.
• Его цель - определить термины, используемые в
настоящее время в этой области, и стандартные
определения для этих терминов.
41.
• Термины исключаются, если они:- считается ограниченным по отношению к одной группе
или организации;
- Является собственностью компании или торговой марки;
- это термин, состоящий из нескольких слов, значение
которых можно вывести из определений словкомпонентов;
- термины, значение которых в области информационных
технологий (ИТ) можно вывести непосредственно из их
общего значения в словаре английского языка.
42.
• Структура Словаря• Словарные статьи расположены в алфавитном порядке.
• Пробелы предшествуют всем остальным символам в алфавите.
• Дефисы и косые черты (- и /) следуют за всеми остальными символами в
алфавите.
• Предпочтительные термины выделены жирным шрифтом.
• Синонимы или принятые термины (термины с тем же значением, что и
предпочтительный термин) перечислены ниже предпочтительного
термина в виде обычного текста и могут быть найдены с помощью
поиска.
• Термины, определения и примечания используют предпочтительное
правописание США.
• Использование заглавных букв было сведено к минимуму и, как правило,
ограничивалось именами собственными и аббревиатурами.
43.
• Предполагаемые читатели этого документа включают, но неограничиваются:
44.
• Включаю т, но не ограничиваются:покупатели: оценивают, соответствуют ли система/программные
продукты/данные их критерию ценности, т.е. соответствуют
ожидаемому качеству,
разработчики: проектируют, внедряют и тестируют
систему/программные продукты/данные, чтобы убедиться, что они
соответствуют ожидаемому качеству;
тестировщики: проверяют и подтверждают, что
система/программные продукты/данные соответствуют
ожидаемому качеству;
руководители проектов: планируют, отслеживают и контролируют
достижение ожидаемого качества и
независимые оценщики: оценивают систему/программные
продукты/данные по объективным критериям.
45.
• Стандарты ISO/IEC 25010 и ISO/IEC 25012 Требования к качеству• используются для классификации требований к качеству и
обеспечения основы для их количественной оценки с точки
зрения показателей качества в подразделении измерения
качества ISO/IEC 2502n.
46.
ISO/IEC/IEEE 24748:2018(en)Systems and software engineering
Life cycle management
Part 4: Systems engineering planning
Poate fi utilizată
în conjuncție
IISO/IEC 25030:2019
Systems and software engineering —
Systems and software quality
requirements and evaluation (SQuaRE)
Quality requirements framework
SO/IEC/IEEE 12207:2017,
Systems and software engineering
Software life cycle processes
contribue
ISO / IEC 25010 : 2011
Systems and software engineering
- Systems and software Quality
Requirements and Evaluation ( SQuaRE )
- System and software quality models
contribue
Poate fi utilizată
în conjuncție
ISO/IEC/IEEE 29148:2011
Systems and software engineering
— Life cycle processes
— Requirements engineering
47.
• Важно определить и указать требования к качеству как частьтребований к системе, программному обеспечению и данным,
поскольку поиск баланса между требованиями к качеству в
дополнение к четко определенным функциональным требованиям
является критическим фактором успеха для достижения целей
заинтересованных сторон.
• Требования к качеству необходимы для:
- спецификация системы, включая договорные соглашения и спроспредложение;
- планирование проекта, включая анализ осуществимости;
- разработки системы, включая определение архитектурных драйверов
или потенциальных проблем с качеством во время разработки; а также
- оценки системы, включая объективную оценку и сертификацию
качества.
48.
• Стандарт фокусируется на определении, использовании иуправлении требованиями к качеству.
• Если они не определены четко, они могут по разному
рассматриваться, интерпретироваться, реализовываться и
оцениваться соответствующими заинтересованными сторонами.
• Это может привести к:
-систем, которые не соответствуют ожиданиям
пользователей и имеют низкое качество; а также
- перерасход времени и средств на восстановление системы.
Таким образом, требования к качеству системы
должны быть четко определены на самой ранней стадии
процесса разработки или приобретения, чтобы обеспечить
критический вклад в разработку или приобретение.
49.
Требования к качеству системы?Вернемся к Теме 2
50.
• Качество любого проекта основано на выявлении требованийзаказчика
• Для управления качеством проекта крайне важно понимать, что
такое качество и как оно связано с проектом.
• Качество это - совокупность свойств, признаков продукции,
товаров, услуг, работ, труда, обусловливающих их способность
удовлетворять потребности и запросы людей,
соответствовать своему назначению и предъявляемым
требованиям.
• Качество определяется мерой соответствия товаров, работ,
услуг условиям и требованиям стандартов, договоров, контрактов,
запросов потребителей.(экономический словарь)
(https://dic.academic.ru/dic.nsf/econ_dict/7330
7/25/2022
ASCS dr. ing. conf. Pavel Chirev
50
51.
• Джозеф М. Джуран, широко известный как отец качества,определил качество как: «Пригодность к использованию»,
которая позже была изменена на «соответствие
назначению».
• В контексте качества проекта важно удовлетворить
потребности клиента,
• Джозеф Мозес Джуран (Joseph Moses Juran) – американский
специалист в области качества, академик Международной
академии качества (МАК). Один из главных архитекторов
всемирной революции в области управления ради достижения
качества.
• «Самое главное, чтобы высшее руководство было
ориентировано на качество. В отсутствие искреннего
проявления интереса наверху мало что произойдет внизу»
7/25/2022
ASCS dr. ing. conf. Pavel Chirev
51
52.
• Joseph Moses Juran (December 24, 1904 – February 28,2008) was a Romanian-born American engineer and
management consultant
• Juran's quality management approach is based on three key
principles. ...
• These three elements are:
- quality planning (the design stage),
- quality control (ongoing inspections to ensure that processes
are in control) and
- quality improvement (including proactive refinement of
processes to improve processes).
7/25/2022
ASCA
ASCS dr. ing. conf. Pavel Chirev
52
53.
• Pentru voi ce înseamnă cuvântul „ calitate“?• Что для вас означает слово «качество»?
7/25/2022
ASCS dr. ing. conf. Pavel Chirev
53
54.
• Институт управления проектами определяет качество как:«Степень, в которой набор неотъемлемых характеристик
соответствует требованиям».
Важно просто выполнить требования, указанные в контракте по
проекту. «Почему, что и как», описывает простой набор
утверждений, связанных со спецификациями проекта:
- Если вы не выполняете требованя спецификаций, вы
нарушаете условия контракта.
- Если вы хотите завершить текущий контракт, пожалуйста,
соблюдайте условия контракта.
- Если вы хотите выиграть следующий контракт, оправдайте или
превзойдите ожидания клиента.
7/25/2022
ASCS dr. ing. conf. Pavel Chirev
54
55.
• THE QUALITY PLANNING SOLUTIONQuality planning provides the process, methods, tools, and techniques
for closing each of these component gaps and thereby ensuring that the
final quality gap is at a minimum.
• Quality planning steps
1)
2)
3)
4)
5)
6)
Establish the project
Identify the customers
Discover the customer needs
Develop the product
Develop the process
Develop the controls and,
transfer to operations
7/25/2022
ASCS dr. ing. conf. Pavel Chirev
55
56.
Спираль качества по Joseph Moses Juran1. Исследование рынка;
2. Разработка проектного задания;
3. Проектно-конструкторские работы;
4. Составление технических условий;
5. Разработка технологии и подготовка производства;
6. Материально-техническое обеспечение;
7. Изготовление инструмента приспособлений и контрольноизмерительных средств;
8. Производство;
9. Контроль процесса производства;
10. Контроль готовой продукции;
11. Испытания рабочих характеристик продукции;
12. Сбыт;
13. Техническое обслуживание;
14. Исследования рынка.
Таким образом, по мнению Джозефа Джурана, указанные процессы
обеспечивают непрерывное формирование и улучшение качества
продукции.
7/25/2022
ASCS dr. ing. conf. Pavel Chirev
56
57.
• Требования к качеству могут быть классифицированы нахарактеристики/подхарактеристики с использованием моделей
качества, определенных в семействе стандартов ISO/IEC 2501n.
• Метрики этих характеристик/подхарактеристик, определенные в
семействе стандартов ISO/IEC 2502n, могут использоваться для
определения требований к качеству и оценки качества целевой
системы или данных.
• Многие системы в настоящее время глубоко встроены в
социально-экономическую инфраструктуру, используемую в
повседневной жизни. Это требует от систем достижения гораздо
более высокого качества;
• например, подключенные системы должны быть совместимыми
и безопасными, надежными, ремонтопригодными и удобными в
использовании.
58.
59.
60.
• ISO/IEC 2500n — Раздел управления качеством. Стандарты, составляющие этотраздел, определяют все общие модели, термины и определения, используемые
всеми другими стандартами серии SQuaRE. Подразделение также предоставляет
требования и рекомендации по планированию и управлению проектом.
• ISO/IEC 2501n — Раздел моделей качества. Стандарты, формирующие этот
раздел, обеспечивают модели качества родуктов для систем/программ,
качества при использовании quality in use (QIU), качества данных и ИТ-услуг.
Также предоставляется практическое руководство по использованию модели
качества.
• ISO/IEC 2502n — Раздел измерения качества. Стандарты, составляющие этот
раздел, включают эталонную модель измерения качества продукта
систем/программ, определения показателей качества и практические
рекомендации по их применению. В этом разделе представлены внутренние
показатели качества программного обеспечения, внешние показатели
качества программного обеспечения, показатели качества при
использовании quality in use (QIU) и показатели качества данных.
Определены и представлены элементы показателей качества, формирующие
основу для показателей качества.
61.
• — ISO/IEC 2503n — Раздел требований к качеству. Стандарт,формирующий этот раздел, помогает определить требования к
качеству. Эти требования к качеству можно использовать в
процессе выявления требований к качеству разрабатываемой
системы/программного продукта, разработки процесса
достижения необходимого качества или в качестве исходных
данных для процесса оценки.
• — ISO/IEC 2504n —Раздел оценки качества. Стандарты,
формирующие этот раздел, содержат требования, рекомендации
и руководства по оценке продуктов систем/программ независимо
от того, выполняются ли они независимыми оценщиками,
приобретателями или разработчиками. Также представлена
поддержка документирования модуля оценки в качестве меры.
62.
ISO/IEC 25010 - System and software quality models: Describes
the model, consisting of characteristics and subcharacteristics, for
software product quality, and software quality in use.
• ISO/IEC 25012 - Data Quality model: defines a general data quality
model for data retained in a structured format within a computer
system. It focuses on the quality of the data as part of a computer
system and defines quality characteristics for target data used by
humans and systems.
63.
• ISO / IEC 25010 : 2011 Systems and software engineering — Systems andsoftware Quality Requirements and Evaluation ( SQuaRE ) — System and
software quality models
(ISO / IEC 25010: 2011 Системная и программная инженерия. Требования к
качеству систем и программного обеспечения и их оценка (SQuaRE) —
Модели качества систем и программного обеспечения)
• Домен приложения
Этот стандарт определяет:
a) Модель качества использования, состоящая из пяти характеристик
(некоторые из которых далее подразделяются на подхарактеристики),
которые относятся к результату взаимодействия, когда продукт
используется в определенном контексте использования.
Эта системная модель применима ко всей системе человек-компьютер,
включая используемые компьютерные системы и программные продукты.
64.
б) Модель качества продукта, состоящая из восьмихарактеристик (которые подразделяются на подхарактеристики),
которые относятся к статическим свойствам программного
обеспечения и динамическим свойствам компьютерной системы.
Модель применима как к компьютерным системам, так и к
программным продуктам.
Характеристики, определяемые обеими моделями, относятся ко
всем программным продуктам и компьютерным системам.
Функции и подфункции обеспечивают согласованную
терминологию для определения, измерения и оценки качества
системных и программных продуктов.
Они обеспечивают набор характеристик качества, с которыми
можно сравнить заявленные требования к качеству на полноту.
65.
66.
• Область применения моделей качества включает в себяподдержку спецификации и оценки программного обеспечения и
информационно-емких систем с точек зрения, отличных от тех,
которые связаны с приобретением, требованиями, разработкой,
использованием, оценкой, поддержкой, обслуживанием,
обеспечением и контролем качества, а также аудитом.
• Модели могут, например, использоваться разработчиками,
покупателями, персоналом по обеспечению и контролю
качества, а также независимыми оценщиками, особенно
теми, кто отвечает за определение и оценку качества
программных продуктов.
67.
• Действия при разработки продукта, которые могутиспользовать модели качества, включают:
определение требований к программному обеспечению и системе;
проверка полноты определения требований;
определение целей проектирования программного обеспечения и
систем;
определение целей тестирования программного обеспечения и
систем;
определение критериев контроля качества как части обеспечения
качества;
определение критериев приемки программного продукта и/или ИТсистемы с интенсивным использованием программного обеспечения;
установление метрики характеристик качества в поддержку
этой деятельности.
68.
• ISO/IEC 2503n – Quality Requirements Division• The standard that forms this division helps specifying quality requirements.
These quality requirements can be used in the process of quality
requirements elicitation for a software product to be developed or as input
for an evaluation process. This division consists of the following standard:
ISO/IEC 25030 - Quality requirements: Provides requirements and
guidance for the process used to develop quality requirements, as well as
requirements and recommendations for quality requirements.
69.
ISO/IEC TR 24748 -2018, Systems and software engineering — Lifecycle management. Part 4, Systems engineering planning
70.
• Этот стандарт предоставляет информацию о концепцияхжизненного цикла и описания целей и результатов
репрезентативных этапов жизненного цикла.
• Он иллюстрирует использование модели жизненного
цикла для систем в контексте ISO / IEC 15288 и обеспечивает
соответствующую
• Иллюстрирует использования модели жизненного
цикла для программного обеспечения в контексте ISO
/ IEC 12207.
71.
• ISO/IEC/IEEE 24748 содержит унифицированное иконсолидированное руководство по управлению жизненным
циклом систем и программного обеспечения.
• Этот документ фокусируется на процессах, необходимых для
успешного планирования и управления усилиями по разработке
программного обеспечения проекта и
• для разработки плана разработки программного обеспечения
(Software Development Plan (SDP)) в качестве средства для
представления приложения проекта процессов жизненного цикла
программного обеспечения.
72.
73.
• SDP — это документ технического планирования высокого уровнядля проекта, в котором рассматриваются процессы
технического управления, установленные четырьмя
основными источниками:
проектный контракт,
организационные и технические процессы управления
проектная группа по разработке программного обеспечения,
задачи, связанные с проектом.
Элементы, необходимые для успешной разработки
программного обеспечения.
74.
• Стандарт обеспечивает общую основу дляпланирования и контроля процессов и
технических действий по производству и
поддержке программных продуктов.
• Этот документ охватывает полный жизненный
цикл, от концепции идеи до вывода программного
продукта из эксплуатации.
75.
Part 1: Guidelines for life cycle management [Technical Specification]Part 2: Guide to the application of ISO/IEC 15288 (System life cycle
processes)
Part 3: Guide to the application of ISO/IEC 12207 (Software life cycle
processes)
Part 4: Systems engineering planning [ISO/IEC/IEEE]
Part 5: Software development planning [ISO/IEC/IEEE]
• The following parts are under preparation:
Part 6: Guide to system integration engineering
76.
• IEEE Std 730™-2014 - IEEE Standard for SoftwareQuality Assurance Processes
77.
• Этот стандарт устанавливает требования кинициированию, планированию, контролю и выполнению
процессов обеспечения качества программного
обеспечения (SQA) проекта разработки или
сопровождения программного обеспечения.
• Этот стандарт гармонизирован:
- с процессами жизненного цикла программного обеспечения
стандарта ISO/IEC/IEEE 12207 и
- требованиями к информационному содержанию
ISO/IEC/IEEE 15289:2011.
78.
• This standard is organized into clauses and annexes:Clause 1 contains scope, purpose, and introductory material.
Clause 2 identifies the normative references used in this standard.
Clause 3 defines terms and acronyms used in this standard.
Clause 4 describes the context for the SQA processes and SQA activities, and covers expectations
for how this standard will be applied.
Clause 5 specifies the SQA processes, activities, and tasks. Sixteen activities are identified in this
clause and are grouped into three major areas: process implementation, product assurance, and
process assurance. These activities implement the required outcomes for SQA specified by 7.2.3 of
ISO/IEC/IEEE 12207:2008.
Refer to Annex A for the mapping of the four required outcomes to the subclauses of this standard.
Refer to Annex B for information about mapping between the SQA plan outlines in IEEE Std
730-20023,4 and IEEE Std 730-2014.
Refer to Annex C for information about guidance for creating a Software Quality Assurance Plan
(SQAP).
Refer to Annex D for information about mapping between IEEE Std 730-2014 and ISO/IEC
15504-1:2004 [B34].