Engineering of software development processes quality by means of Petri Nets
Analysis of software development processes models can contribute to the early detection of errors. By analyzing the models it is possible to prove specific properties of these models, and to gain deeper insights into their nature. In given paper the formal modelling technique of Petri nets is applie...
Збережено в:
| Дата: | 2026 |
|---|---|
| Автор: | |
| Формат: | Стаття |
| Мова: | Російська |
| Опубліковано: |
PROBLEMS IN PROGRAMMING
2026
|
| Теми: | |
| Онлайн доступ: | https://pp.isofts.kiev.ua/index.php/ojs1/article/view/912 |
| Теги: |
Додати тег
Немає тегів, Будьте першим, хто поставить тег для цього запису!
|
| Назва журналу: | Problems in programming |
| Завантажити файл: |  |
Репозитарії
Problems in programming| _version_ | 1866844936568045568 |
|---|---|
| author | Matveeva, L.E. |
| author_facet | Matveeva, L.E. |
| author_institution_txt_mv | [
{
"author": "L.E. Matveeva",
"institution": "Glushkov Institute of Cybernetics NAS of Ukraine"
}
] |
| author_sort | Matveeva, L.E. |
| baseUrl_str | https://pp.isofts.kiev.ua/index.php/ojs1/oai |
| collection | OJS |
| datestamp_date | 2026-06-01T06:02:58Z |
| description | Analysis of software development processes models can contribute to the early detection of errors. By analyzing the models it is possible to prove specific properties of these models, and to gain deeper insights into their nature. In given paper the formal modelling technique of Petri nets is applied and is based on linear algebra methods of analysis in order to research some properties of auditing process developed by the author.Problems in programming 2010; 2-3: 277-283 |
| first_indexed | 2026-06-02T01:01:08Z |
| format | Article |
| fulltext |
Методи та засоби програмної інженерії
©. Л.Е. Матвеева, 2010
ISSN 1727-4907. Проблеми програмування. 2010. № 2–3. Спеціальний випуск 277
УДК 681.3.06
ИНЖЕНЕРИЯ КАЧЕСТВА
ПРОЦЕССОВ ПРОИЗВОДСТВА ПРОГРАММНЫХ СИСТЕМ
С ПОМОЩЬЮ СЕТЕЙ ПЕТРИ
Л.Е. Матвеева
Институт кибернетики имени В.М. Глушкова НАН Украины,
Киев-03187, проспект Академика Глушкова, 40,
факс: 526 7418, тел: 526 0058,
e-mail: luda@iss.org.ua, lmatveeva@luxoft.com
Моделирование процессов производства программных продуктов и сервисов является важной частью их анализа и позволяет
обнаруживать ошибки и слабые места на ранних стадиях жизненного цикла проектов, тем самым минимизируя затраты на их
исправление. В данной работе применяется формализм сетей Петри для моделирования разработанной автором и внедренной в
производство процедуры аудита качества с целью ее анализа, улучшения и настройки. Для анализа модели в виде ординарной сети
Петри с одноцветными фишками решаются системы линейных однородных диофантовых уравнений над множеством натуральных
чисел.
Analysis of software development processes models can contribute to the early detection of errors. By analyzing the models it is possible to
prove specific properties of these models, and to gain deeper insights into their nature. In given paper the formal modelling technique of Petri
nets is applied and is based on linear algebra methods of analysis in order to research some properties of auditing process developed by the
author.
Введение
Мотивация. Начиная с середины восьмидесятых годов 20-го века и до настоящего времени в индустрии
программного обеспечения продолжает наростать интерес к применению различных моделей и стандартов
процессов с целью обеспечения качества продуктов и сервисов. В частности, растущее количество организаций,
внедряющих CMMI [1], привело в последние годы к созданию крупномасштабных программ по улучшению
процессов разработки программного обеспечения. Положительные результаты внедрения таких программ
достигаются, к сожалению, не всегда, и большие инвестиции не оправдываются. Вероятность успешного
внедрения таких программ можно существенно увеличить, анализируя процессы и ключевые индикаторы их
эффективности, поскольку они определяют успех или неудачу таких программ. Начальное описание процессов
является лишь стартовой точкой работы по их внедрению. Только анализируя процессы в ходе реальной
работы, регулярно определяя слабые места или возможность их появления, можно обнаружить системные
проблемы и несоответствия и провести процедуру усовершенствования процессов.
Моделирование процессов. Моделирование процессов является важной частью их анализа и,
соответственно, усовершенствования [2]. Модель процесса – это, как правило, структурированный набор
элементов, который описывает характеристики эффективного процесса.
Известны различные способы моделирования процессов, например, с помощью построения: диаграмм
состояний (state chart), диаграмм деятельности (activity diagram) или блок-схем (flow chart), диаграмм потоков
данных (data-flow diagrams), а также Модели Показателей Процесса (Process Performance Model) и т. п. ([2–4]).
Выбор типа модели зависит от целей, преследуемых в ходе усовершенствования процесса, задач, которые
нужно решить и которые задают определенный аспект моделируемого процесса, например, требуется
подвергнуть анализу, посредством моделирования последовательность выполняемых действий, ресурсы,
данные или функции.
Модель Эффективности Процесса (Process Performance Model) включает набор базовых метрических
данных атрибутов процессов (baselines) [2] и может использоваться для прогнозирования и анализа рабочих
характеристик и эффективности стандартных процессов организации; оценивания прогресса в достижении
целей по показателям проекта, а также для прогнозирования уровня возврата инвестиций в построение и
усовершенствование процессов в организации.
Диаграмма деятельности обеспечивает представление процесса в виде определенного шаблона
деятельности (т. е. набора активностей или последовательности действий), обеспеченного соответствующими
ресурсами, с определенными ролями и ответственностями. Такая модель также может включать описание
исключений, интерфейсов и рабочих продуктов, которые поставляются заказчику. Язык моделирования
процесса должен обеспечить компактное представление модели, поскольку модели процессов разработки
программного обеспечения обычно достаточно сложные. Требуется представлять основные объекты как
атомарные единицы описания, что означает, например, рассматривать используемые в процессах
инструментальные средства как черные ящики, описывающие их входное / выходное поведение, а не
внутреннюю структуру.
mailto:luda@iss.org.ua
Методи та засоби програмної інженерії
278
Пример простой модели. Рассмотрим в качестве примера разработанную автором и внедренную в
производство процедуру планирования и проведения аудитов качества [2] и построим ее модели разных типов.
Аудит качества – это объективная оценка соответствия процессов, продуктов и сервисов принятым в
организации стандартам и процедурам. Данная деятельность является частью процесса Обеспечения Качества
(Quality Assurance – QA), который в целом включает:
определение целей по качеству и плана по управлению качеством в организации;
отслеживание и сбор метрической информации и данных проектов;
проведение аудитов качества (audits) в проектах.
Объективность оценки соответствия обеспечивается использованием критериев, относительно которых
идет проверка индикаторов внедрения и институционализации производственных практик. Использование
критериев означает наличие списков пунктов проверки, которое содержится в контрольных листах (checklists)
аудитов, согласованных всеми участвующими в аудите сторонами.
Начнем с построения простой модели данной процедуры в виде одной из разновидностей диаграмм
деятельности (activity diagram). Дадим необходимые определения для такой модели.
Процесс (Process) – набор активностей, которые имеют последовательность во времени, входные и
выходные условия и данные. Примеры процессов – анализ требований, проектирования архитектуры
продукта, системное тестирование, проведение аудитов качества и т. п.
Активность (Activity) имеет четкую постановку задания и, в целом, атомарный характер, является
ответственностью одной персоны или группы. Примеры активностей процесса аудита качества –
планирование аудита, проведение аудита, регистрация результов, устранение несоответствий, выявленных
в ходе аудита.
Роль (Role) – это определенная зона ответственности. Примеры ролей: менеджер проекта (project manager),
тестовый инженер (test engineer), инженер по обеспечению качества (QA engineer или quality engineer).
Условие (Condition) – это или входное условие, которое должно выполняться перед началом определенного
процесса или действия, или постусловие, которое будет выполняться по окончании данного процесса.
Могут также оказаться полезными (хотя и не используются в примере на рис.1) следующие элементы
модели [2]:
Поставка (Deliverable) — материальный выход/результат процесса.
Исключение (Exception) – описание того, как изменить процесс, если происходит определенное ожидаемое
или непредвиденное событие. Примеры исключений процесса: согласованное отклонение от стандартного
процесса (Deviation Note), процедура временного замещения исполнителя определенной роли (substitution
procedure).
Взаимодействия (Communication) могут быть неформальные или формальные. Формальные
взаимодействия – это, например, процедура утверждения поставки проектным менеджером; неформальные
взаимодействия – это, например, обмен электронной почтой по поводу двусмысленности в документе.
С учетом данных определений модель процесса проведения аудита качества выглядит следующим
образом (рис. 1).
Рис. 1. Модель процесса аудита качества
Как видно из рис. 1, имеется элемент модели «Процесс», который представлен в виде овала.
Предусловием является то, что аудит должен быть запланирован; постусловием модели является то, что все
несоответствия, выявленные в ходе аудита, устранены; на входе в процесс имеется согласованный и настроен-
ный для данного проекта контрольный лист (checklist) аудита; выходные данные процесса – это отчет
о проведении аудита и исправлении обнаруженных несоответствий.
Проведем декомпозицию общего описания процесса на подпроцессы. В итоге данный процесс может
быть представлен набором диаграмм последовательно выполняемых функций, состоящих из нескольких
элементов «Активность», которые изображены в овалах (окантованных штриховой линией), на следующей
схеме (см. рис. 2).
Для каждой активности в свою очередь могут быть представлены входные и выходные условия и
данные. Однако, дальнейшая детализация этой модели не является целью данной работы.
Методи та засоби програмної інженерії
279
Accept master plan of
audits in a project
Resolve all audit
findings
Negotiations on audit
findings content
1
st
part without interview,
documents studying
Tailor the audit
checklist
2
nd
part – interview with
project manager
Submit audit findings
to audit database
Verify all audit
findings closure
Agree the audit
schedule
Communicate audit
findings to all
relevant
stakeholders
Close audit
Audit planning –
планирование
аудита
Audit
conducting –
проведение
аудита
Audit results
registering –
регистрация
результов
Noncompliance
elimination –
устранение
несоответствий
Рис. 2. Активности модели процесса аудита качества
Постановка задачи
В данной работе предлагается метод моделирования с помощью ординарных сетей Петри с
одноцветными фишками [5, 6]. При этом используются известные определения теории сетей Петри [5 – 7]
[5, 6]. Напомним лишь, что Сеть Петри представляет собой двудольный ориентированный граф, состоящий из
вершин двух типов — мест и переходов, соединенных между собой дугами, вершины одного типа не могут
быть соединены непосредственно. В местах могут размещаться фишки, способные перемещаться по сети.
Событием называют срабатывание перехода, при котором фишки из входных мест этого перехода
перемещаются в выходные места. События происходят при выполнении некоторых условий.
Данная математическая модель является адекватным механизмом описания свойств дискретных
реактивных систем, которые включают асинхронные элементы и распределенные части. Известно, что
математический аппарат сетей Петри может применяться для описания параллелизма моделируемой системы,
планирования распределения ресурса, координации разных целей и т. д. [7, 8]. Для анализа модели в виде сети
Петри в данной работе применяются методы линейной алгебры [9, 10]. Решаются системы линейных
однородных диофантовых уравнений над множеством натуральных чисел. При этом используем известные
определения – [7, 10, 11].
Инженерия (разработка) программного обеспечения ([1], [12–16]) и теория сетей Петри являются
дисциплинами различной природы, хотя инженерия программного обеспечения имеет тесные связи со своей
базовой дисциплиной – информатикой. Исследования в области разработки программного обеспечения
ориентированы на поиск решений, которые покрывают различные аспекты промышленного производства
сложных больших программных систем. В то время как исследования в области сетей Петри основываются на
изучении приложений и свойств специальной математической модели.
Однако. моделирование и анализ систем с помощью сетей Петри может применяться на различных фазах
процесса разработки программного обеспечения. Известной областью применения формализма сетей Петри
является формальная спецификация и верификация требований и дизайна программной системы ([10, 11, 17]),
[8]. Покажем, что и другие задачи инженерии программного обеспечения могут решаться с помощью
применения формализма сетей Петри. В данной работе приведен пример того, как можно применить сети
Петри для моделирования одного из процессов производства программного обеспечения с целью его анализа,
улучшения и настройки, а именно: процесса аудита качества. Анализ моделей процессов в виде сетей Петри
может содействовать раннему обнаружению ошибок в процессах. Что очень важно, так как качество продукта в
значительной мере определяется качеством процесса производства этого продукта; и потому в результате
анализа процессов разработки и последующего усовершенствования, которое ориентировано на качество
продукта, улучшается качество продукта. Анализируя такие модели, можно доказать их специфические
свойства и приобрести более глубокие знания об их природе, а значит обнаружить возможные области для
улучшения тех процессов, которых они моделируют. Анализ модели позволяет улучшать управление
процессами.
Моделирование процесса сетью Петри и ее анализ
На рис. 3 представлена еще одна более детальная, чем во Введении, модель процесса аудита качества.
Формат данной диаграммы соответствует требованиям стандарта ISO/TS 16949:2002. Роли процедуры
аудирования (горизонтальные полосы на схеме): Инженер по Обеспечению Качества (QA Engineer),
Руководитель Проекта (Project Manager или PM). AF (audit finding) – это несоответствие, выявленное в ходе
аудита.
Методи та засоби програмної інженерії
280
Основные шаги процедуры, представленной на рис. 3.
1. Инициация проведения аудита качества состоит в обеспечении предварительных условий его проведения и
входных данных: подразумевается наличие плана аудитов проекта и предварительно согласованных
контрольных листах (checklists) аудитов. Всякий контрольный лист адаптируется к нуждам конкретного
проекта и утверждается Руководителем Проекта. Настройка аудита и его контрольного листа производится
с целью учесть специфику проекта и проводить аудирование более целенаправленно.
2. Согласовывается план-график аудита.
3. Аудит проводится.
4. Данные аудита регистрируются. Заполняется отчет о проведении аудита, который рассылается всем
заинтересованным сторонам, после соответствующего согласования с указанием обнаруженных
несоответствий.
5. Обеспечивается исправление несоответствий, обнаруженных в ходе аудита.
6. Инженер по Обеспечению Качества производит проверку устраненных несоответствий.
7. Если все зарегистрированные несоответствия устранены, аудит считается завершенным.
Рис. 3. Схема проведения аудита качества
Теперь представим модель данной процедуры на рис. 4, используя формализм ординарных сетей Петри
с одноцветными фишками ([5 – 7]), а затем проанализируем ее свойства, используя определения и метод,
представленный в [9–11, 18] и [19].
Места сети (рис. 4) интерпретируем следующим образом: P1 – условие инициации проведения аудита
(см. первый шаг процедуры в начале данного раздела); P2 – условие достижения договоренности о дате
проведения аудита; P3 – условие выделения Руководителем Проекта необходимых ресурсов; P4 – условие
наличия графика проведения аудита; P5 – проведение первой части аудита – изучение проектных документов;
P6 – проведение второй части аудита – интервью с Руководителем Проекта, регистрация обнаруженных
несоответствий; P7 – согласование обнаруженных несоответствий с Руководителем Проекта; P8 – Инженер по
Обеспечению Качества уточняет формулировку обнаруженных несоответствий; P9 – согласование уточненной
формулировки обнаруженных несоответствий; P10 – дополнительные аргументы по выявленным несоответ-
ствиям; P11 – условие наличия графика устранения выявленных несоответствий; P12 – условие готовности к
проверке Инженером по Обеспечению Качества устраненных несоответствий; P13 – имеются аргументы по
недостаточным действиям для устранения выявленных несоответствий; P14 – условие принятия решения по
результатам проверки устраненных несоответствий; P15 – условие закрытия аудита.
Переходы сети (рис. 4) интерпретируем следующим образом: t1 – событие инициации проведения
аудита; t2 – заявлено несогласие с предварительными условиями его проведения или входными данными; t3 –
достигнуто согласие с предварительными условиями проведения аудита и входными данными; t4 – проведение
первой части аудита (изучение проектных документов); t5 – проведение второй части аудита (интервью); t6 –
регистрация обнаруженных несоответствий; t7 – несогласие с формулировкой несоответствий; t8 –
планирование работ по устранению несоответствий; t9 – отклонить несоответствие, как такое, которое не
является нарушением процесса, и согласовать это всеми сторонами; t10 – планирование работ по устранению
несоответствий; t11 – событие устранения несоответствий; t12 – событие проверки устранения несоответствий;
t13 – событие перепланирования работ по устранению несоответствий; t14 – событие закрытия несоответствий;
t15 – событие завершения аудита качества.
Возможна начальная разметка сети: 0M = (1,0,1,0,0,0,0,1,0,1,0,0,1,0,0), интерпретация которой следую-
щая: проведение аудита инициировано – контрольный лист согласован, аудит в проекте запланирован, то есть
выделены все необходимые ресурсы (Руководитель Проекта выделил время и обеспечил инструментальные
средства для автоматизации процесса); в проекте имеется выделенный Инженер по Обеспечению Качества,
который готов проводить аудит и согласование с Руководителем Проекта, давать необходимые разъяснения, а
также производить проверку того, что все выявленные в ходе аудита несоответствия действительно устранены.
Методи та засоби програмної інженерії
281
P1
P3
P2
t1
t2
t3
t4
t5
t6
P4
P5
P6
P7
P8
t7
t8
P9 P11
P10
P12
P13
P14
P15
t9
t10
t11
t12
t13
t15
t14
Рис. 4. Сеть Петри моделирующая процедуру проведения аудита качества
Для анализа свойств данной модели строим по сети (рис. 4) ее матрицу инцидентности А:
t1 t2 t3 t4 t5 t6 t7 t8 t9 t10 t11 t12 t13 t14 t15
P1 -1 1 0 0 0 0 0 0 0 0 0 0 0 0 1
P2 1 -1 -1 0 0 0 0 0 0 0 0 0 0 0 0
P3 0 0 0 0 0 0 -1 -1 0 0 0 0 0 1 0
P4 0 0 1 -1 0 0 0 0 0 0 0 0 0 0 0
P5 0 0 0 1 -1 0 0 0 0 0 0 0 0 0 0
P6 0 0 0 0 1 -1 0 0 0 0 0 0 0 0 0
P7 0 0 0 0 0 1 -1 -1 0 0 0 0 0 0 0
P8 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
P9 0 0 0 0 0 0 1 0 -1 -1 0 0 0 0 0
P10 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
P11 0 0 0 0 0 0 0 1 0 1 -1 0 1 0 0
P12 0 0 0 0 0 0 0 0 0 0 1 -1 0 0 0
P13 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
P14 0 0 0 0 0 0 0 0 1 0 0 1 -1 -1 0
P15 0 0 0 0 0 0 0 0 0 0 0 0 0 1 -1
Методи та засоби програмної інженерії
282
Вычисляем минимальное порождающее множество Т-инвариантов, решая однородную систему
уравнений Ax = 0, где A – матрица инцидентности верифицируемой сети Петри; данное множество
представлено 5 векторами, которые соответствуют последовательностям срабатывания переходов:
T1= (1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0)
T2= (1, 0, 1, 1, 1, 1, 1, 0, 1, 0, 0, 0, 0, 1, 1)
T3= (0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 1, 1, 0, 0)
T4= (1, 0, 1, 1, 1, 1, 0, 1, 0, 0, 1, 1, 0, 1, 1)
T5= (1, 0, 1, 1, 1, 1, 1, 0, 0, 1, 1, 1, 0, 1, 1)
Затем решим однородную систему уравнений 0yAT , где
TA – транспонированная матрица инцидент-
ности верифицируемой сети Петри. Вычисляем минимальное порождающее множество S-инвариантов, оно
представлено 5 векторами:
S1= (0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0)
S2= (0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0)
S3= (0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0)
S4= (0, 0, 1, 0, 0, 0, 0, 0, 1, 0, 1, 1, 0, 1, 0)
S5= (1, 1, 0, 1, 1, 1, 1, 0, 1, 0, 1, 1, 0, 1, 1)
Результаты анализа данных инвариантов.
Из минимального порождающего множества Т-инвариантов следует, что все переходы покрыты
Т-инвариантами, и, значит, сеть обладает структурным свойством L3-живости.
Сеть является повторяемой, то есть любая последовательность срабатываний переходов может повториться
теоретически бесконечное число раз.
Сеть является непротиворечивой, так как каждый переход встречается хотя бы один раз при переходе
от начальной разметки к ней же.
Из минимальногое порождающего множества S-инвариантов следует, что все места покрыты
S-инвариантами, что говорит о том, что все места данной СП ограничены, и, следовательно,
Данная СП структурно ограничена.
Из анализа модели можно сделать вывод, что система, представленная данной моделью, не содержит
дедлоков и ограничена по ресурсам.
Усовершенствование процесса в результате анализа модели. Данная сеть и результаты ее анализа
могут использоваться для усовершенствования процедуры аудита качества, представленной на рис.1, 2 и 3. При
создании модели процедуры в виде сети Петри выяснилось, что Руководителя Проекта должен запланировать
время для работы над результатами аудита (анализ и устранение несоответствий). Действительно, связь между
переходами Т7, Т8 и Т3 и местом Р3 моделирует распределение ресурса Руководителя Проекта. Инженер по
Обеспечению Качества обязан это учесть при описании данной процедуры. Схема (рис. 3) и описание должны
быть соответствующим образом отредактированы, в процедуру (представленную в начале данного раздела)
должен быть добавлен шаг, описывающий выделение времени для обработки выявленных в ходе аудита и
согласованных с Инженером по Обеспечению Качества несоответствий.
Для полноты представления темы моделирования процессов нужно указать на риски такого внедрения
процессов в организации, которое основано на их моделировании. Эти риски связаны с тем, что, во-первых, при
внедрении модели существует опасность слишком больших расходов, которые не являются обоснованными
бизнес-целями организации; во-вторых, все модели являются неполными; в-третьих, для корректного
использования модели с пользой для производства нужно глубокое профессиональное ее понимание и оценка.
Заключение и выводы
Инженер Группы Обеспечения Качества обнаруживает возможности усовершенствования процессов,
занимаясь анализом процессов, поиском типов образцов низкой эффективности, дефектов или других проблем
[2]. Моделирование процессов является важной частью их анализа. Модель является важной потому, что
обеспечивает отправную точку анализа, общий язык и виденье, а также использование опыта всех участвующих
в создании модели процесса. Кроме того модель процесса дает метод оценивания и проведения диагностики
состояния текущих процесcных практик; помогает обнаруживать ошибки и слабые места на ранних стадиях
жизненного цикла проектов, тем самым минимизируя затраты на их исправление; помогает устанавливать цели
и приоритеты по усовершенствованию процессов.
В данной работе рассмотрены различные модели процедуры проведения аудита качества, в том числе
построена модель с использованием формализма ординарных сетей Петри с одноцветными фишками ([5,6]).
Проводится анализ свойств сети с применением методов линейной алгебры [7, 9, 10]. Приведен пример того,
как результаты моделирования могут использоваться для усовершенствования данной процедуры.
Методи та засоби програмної інженерії
283
1. CMMI for Development, Version 1.2 // http://www.sei.cmu.edu/pub/documents/06.reports/pdf/06tr008.pdf
2. Матвєєва Л.Є., Волков В. А. Процес розробки програмного забезпечення. Від теорії до практики. – Київ. – 2008.
3. DeMarco T. Structured Analysis and Systems Specification // Englewood Cliffs, N.J.: Prentice-Hall, 1979. – 352 p.
4. Yourdon E. Just Enough Structured Analysis // 2006. – http://www.yourdon.com/jesa/jesa.php
5. Peterson J.L. Petri Net Theory and the Modelling of Systems // Prentice-Hall, Englewood Cliffs, New Jersey, (April 1981). – 290 p.
6. Котов В. Е. Сети Петри // М.:Наука, 1984. – 157 с.
7. Murata T. Petri Nets: Properties, Analysis and Applications // In Proc. of the IEEE. – 1989. –Vol. 77. – N 4. – P. 541–580.
8. E.M. Clark, J.M. Wing. Formal methods: State of the Art and Future Directions // ACM Computing Surveys. – Vol. 28. – N 4. –1996.
– P. 626-643.
9. Матвеева Л.Е. Анализ сетей Петри с помощью инвариантов // Искусственный интеллект. – 2001. – № 3. – С. 243–250.
10. Крывый С.Л., Матвеева Л.Е. Формальные методы анализа свойств систем // Кибернетика и системный анализ.–2003. – № 2.
– С. 15–36.
11. Матвеева Л.Е. Автоматическая система анализа и верификации телекоммуникационной системы, описанной на языке MSC,
с помощью формализма сетей Петри // Проблемы программирования. – 2004. – № 2–3. – С. 108–117.
12. Е.М. Лаврищева. Программная инженерия – научная и инженерная дисциплина // Кибернетика и системный анализ. – 2008. – № 3.
– С. 19 – 28.
13. Е.М. Лаврищева. Классификация дисциплин программной инженерии. – Кибернетика и системный анализ. – 2008. – № 6. – С. 5 – 14.
14. Ф.И. Андон, Г.И. Коваль, Т.М. Коротун, Е.М. Лаврищева, В.Ю Суслов. Основы инженерии качества программных систем // Второе
издание. НАНУ Институт программных систем. Издательский дом «Академпериодика», Киев – 2007.
15. W.S. Humphrey. Managing the software process // SEI series in software engineering, Addison-Wesley. – 1989.
16. J.M. Juran, M. G. Frank, Jr. Quality Planning and Analysis // 2nd ed., New York: McGraw-Hill. – 1980.
17. Gold R. Petri Nets in Software Engineering // Arbeitsberichte - Working Papers, Ingolstadt. – 2004.
18. Kryvyy S., Matvyeyeva L., Lopatina M. Automatic Modeling and Analysis of MSC-specified Systems // Fundamenta Informaticae, Vol.67,
N. 1 – 3, August 2005. – Р. 107–120.
19. Крывый С.Л., Матвеева Л.Е., Лопатина М.В. Алгоритм Построения TSS-множества для СЛОДУ в натуральных числах // «Алгебра,
логика и кибернетика» (АЛиК-2004). – Матер. Междунар. конф., посвященной 75-летию со дня рождения А.И. Кокорина, Россия,
Иркутск, 25–28 августа, 2004. – С. 169–171.
http://www.yourdon.com/jesa/jesa.php
|
| id | pp_isofts_kiev_ua-article-912 |
| institution | Problems in programming |
| keywords_txt_mv | keywords |
| language | Russian |
| last_indexed | 2026-06-02T01:01:08Z |
| publishDate | 2026 |
| publisher | PROBLEMS IN PROGRAMMING |
| record_format | ojs |
| resource_txt_mv | ppisoftskievua/78/c0aaf9387bd09740853fc46815d59d78.pdf |
| spelling | pp_isofts_kiev_ua-article-9122026-06-01T06:02:58Z Engineering of software development processes quality by means of Petri Nets Инженерия качества процессов производства программных систем с помощью сетей Петри Matveeva, L.E. UDC 681.3.06 УДК 681.3.06 Analysis of software development processes models can contribute to the early detection of errors. By analyzing the models it is possible to prove specific properties of these models, and to gain deeper insights into their nature. In given paper the formal modelling technique of Petri nets is applied and is based on linear algebra methods of analysis in order to research some properties of auditing process developed by the author.Problems in programming 2010; 2-3: 277-283 Моделирование процессов производства программных продуктов и сервисов является важной частью их анализа и позволяет обнаруживать ошибки и слабые места на ранних стадиях жизненного цикла проектов, тем самым минимизируя затраты на их исправление. В данной работе применяется формализм сетей Петри для моделирования разработанной автором и внедренной в производство процедуры аудита качества с целью ее анализа, улучшения и настройки. Для анализа модели в виде ординарной сети Петри с одноцветными фишками решаются системы линейных однородных диофантовых уравнений над множеством натуральных чисел.Problems in programming 2010; 2-3: 277-283 PROBLEMS IN PROGRAMMING ПРОБЛЕМЫ ПРОГРАММИРОВАНИЯ ПРОБЛЕМИ ПРОГРАМУВАННЯ 2026-06-01 Article Article application/pdf https://pp.isofts.kiev.ua/index.php/ojs1/article/view/912 PROBLEMS IN PROGRAMMING; No 2-3 (2010); 277-283 ПРОБЛЕМЫ ПРОГРАММИРОВАНИЯ; No 2-3 (2010); 277-283 ПРОБЛЕМИ ПРОГРАМУВАННЯ; No 2-3 (2010); 277-283 1727-4907 ru https://pp.isofts.kiev.ua/index.php/ojs1/article/view/912/981 Copyright (c) 2026 PROBLEMS IN PROGRAMMING |
| spellingShingle | UDC 681.3.06 Matveeva, L.E. Engineering of software development processes quality by means of Petri Nets |
| title | Engineering of software development processes quality by means of Petri Nets |
| title_alt | Инженерия качества процессов производства программных систем с помощью сетей Петри |
| title_full | Engineering of software development processes quality by means of Petri Nets |
| title_fullStr | Engineering of software development processes quality by means of Petri Nets |
| title_full_unstemmed | Engineering of software development processes quality by means of Petri Nets |
| title_short | Engineering of software development processes quality by means of Petri Nets |
| title_sort | engineering of software development processes quality by means of petri nets |
| topic | UDC 681.3.06 |
| topic_facet | UDC 681.3.06 УДК 681.3.06 |
| url | https://pp.isofts.kiev.ua/index.php/ojs1/article/view/912 |
| work_keys_str_mv | AT matveevale engineeringofsoftwaredevelopmentprocessesqualitybymeansofpetrinets AT matveevale inženeriâkačestvaprocessovproizvodstvaprogrammnyhsistemspomoŝʹûsetejpetri |