CC BY
166
16. Артемов И.И. Модель развития фреттинг-коррозии в поверхностном слое листа рессоры / Артемов И.И., Кревчик В.Д., Меньшова С.Б., Келасьев В.В., Маринина Л.А. // Известия высших учебных заведений. Поволжский регион. Технические науки. 2011. № 1. С. 213-224.
17. Шаймарданов Л.Г., Фурманова Е.А., Численное имитационное моделирование безотказности не-восстанавливаемых систем с последовательным соединением элементов Материалы XVIII Междунар. науч. конф., Решетневские чтения, СибГАУ. - Красноярск, 2014. -Ч1. С 366-368.
УДК 519.95
Власов А.И., Карпунин А.А., Ганев Ю.М.
Московский государственный технический университет им. Н.Э. Баумана, Москва, Россия СИСТЕМНЫЙ ПОДХОД К ПРОЕКТИРОВАНИЮ ПРИ КАСКАДНОЙ И ИТЕРАТИВНОЙ МОДЕЛИ ЖИЗНЕННОГО ЦИКЛА
Введение
Если обратиться к руководствам по системному анализу и проектированию, то можно обнаружить насколько важным считается возможность заменить толстые тома компактными диаграммами [1-4]. Но и наличие самой подробной документации не всегда обеспечивает качественные параметры разработки. Не существует единого наилучшего уровня формализации процесса, он должен выбираться каждый раз для каждого конкретного проекта. Разработка идет значительно быстрее, а ошибок совершается значительно меньше, если помимо документации есть эксперт, который знает, что в ней написано, и может объяснить это всем заинтересованным лицам. Точно так же, как постоянный контакт с заказчиком и возможность быстро получить ответ на любой вопрос ускоряют работу, так же возможность обратиться непосредственно к эксперту предметной области и уточнить детали рассматриваемого решения ускоряет работу. Кроме того, такие контакты позволяют участникам разработки получить объективную оценку качества предложенных ими решений и накопить опыт. Представляя процесс разработки в виде n-мерного пространства свойств [3] необходимо учитывать оси качества и надежности чья оценка крайне важна при выборе метода проектирования.
Обобщенный алгоритм выбора подхода к проектированию для конкретного проекта, основанный на оценке параметров проекта и получении уровней ключевых характеристик (компетенций) представлен на рисунке 1.
На начальных этапах данного алгоритма происходит оценка параметров проекта с целью определения уровней ключевых характеристик проектирования. На основе полученных уровней определяется положение реализуемого процесса в трехмерном пространстве свойств, что позволяет выбрать наилучший проектный подход.
Различными методики проектирования сложных систем отличаются набором используемых инструментов, которые должны быть способны, во-первых, представлять информацию о предметной области.
Во вторых, должны иметь возможность описания процессных моделей и достижения им определенного состояния, соответствующей технической документации.
Являясь этапами более общего процесса «разработка - производства - эксплуатация - утилизация» (жизненного цикла изделия), применяемые методы проектирования определяют в конечном итоге общие потребительские свойства создаваемого продукта. При таком подходе, используемые визуальные среды моделирования должны предоставлять синхронный инструментарий описания функционально законченных объектов в рамках комплексной сквозной информационной поддержки жизненного цикла.
Классическая каскадная модель, получившая название Waterfall по аналогии с водопадом за свою линейность и последовательность, была разработана в 1970 году.
Основой каскадной модели жизненного цикла является разбиение работы над продуктом на логичную последовательность этапов, причем каждый последующий этап начинается только после полного завершения текущего. Данная модель хорошо подходит для больших проектов благодаря высокой степени формализованности, возможности долго-
срочного планирования этапов, а значит снизить риски и сделать процесс более прозрачным [5].
К недостаткам каскадной модели жизненного цикла продукта следует отнести:
Линейность процесса разработки. Как следствие - возвращение к прошедшим этапам приведет к необходимости серьезных изменений в плане работ и их стоимости.
Начало ^
Этап 1. Выбор уровня формализации
Оценивается масшгаб проекта, его критичность, новизна, ожидаемая долговечность, распределенность группы разработчиков, требования заказчика. На основании -акой оценки выбирается уровень формализации процесса проектирования, применяемого дин данного проекта.
Этап 2. Выбор уровня каскадности/итердтивности
Оценивается распределенность группы разработчиков, уровень неопределенности проекта, доступные инструментальные средства дни управления проектом. На основании такой оценки выбирается уровень каскадности/итеративности процесса проектирования, применлеуого для данного проек-а.
Этап 3. Выбор уровня регламента
Оценивается опыт группы разработчиков, уровень критичности проекта, его новизна. На оснопа^ии такой оценки выбирается уровень жесткости регламента процесса проектирования, применяемого для данного проекта.
Этап 4. Выбор методологии
На основании порученных уровней ключевых характеристик методологий визуального проектирования, с использованием положения методологий в трехмерном пространстве свойств, производится выбор оптимальной для денного проекта методологии.
Конец
Рисунок 1 - Алгоритм выоора наилучшего метода с учетом решаемой задачи
Невозможность оперативного изменения требований к программному продукту
Невозможность получить оперативную реакцию заказчика по причине его недостаточного участия в проекте (в начале проекта на этапе определения требований к системе и в конце проекта на этапе User Acceptance Test) [1]. Как следствие - неоправданные ожидания.
Обнаружение ошибок взаимодействия отдельных компонентов системы на поздних этапах, как следствие - необходимость тотальной переработки, срыв сроков, рост стоимости системы. Интеграция компонентов при использовании каскадной модели происходит, как правило, на завершающем этапе разработки.
Итеративная модель жизненного цикла проекта призвана устранить недочеты каскадной модели. Процесс разработки сводится к коротким итерациям, каждая из которых включает в себя такие
Рисунок 2 - Каскадная модель жизненного цикла
1 Анализ рисков заказчика и исполнителя
Существует два вида контрактов, которые заключаются между заказчиком и исполнителям. Существует, конечно, и другие виды, но эти два являются наиболее распространенными на сегодняшний день.
Fixed-price контракты (контракты с фиксированной стоимостью) представляют собой набор некоторых условий, которыми являются фиксированный объем работ, фиксированное время и фиксированное качество. В условиях большой неопределенности основные риски приходятся на исполнителя, так как он зажат в рамках фиксированных условий. Чтобы избежать потери, учесть возможность изменения некоторых направлений, продиктованных заказчиком, исполнитель вынужден закладывать большее количество времени и денег на проект, чем на самом деле, нужно. С одной стороны, это может обезопасить исполнителя, но, с другой, заказчик вынужден платить больше.
Второй вид контрактов - time & material. В этом случае большему риску подвержен заказчик, так как он не имеет никаких четких границ по времени и по объему работ. Исполнитель просто выполняет задания заказчика, ответственность за проект полностью лежит на заказчике. Исполнителю всё равно когда закончится проект и сколько исправлений ему предстоит сделать.
2 Сравнительный анализ Agile методик
Agile - это методологии, основывающиеся на подходах итеративной разработки [6-10]. Ключевые отличия гибких методологий заключаются в том, что они позволяют максимально оперативно отслеживать прогресс, вносить изменения, корректировки плана, списка работ, сокращая тем самым риски и со стороны исполнителя, и со стороны заказчика.
Весь проект разбивается на короткие промежутки длительностью в 1-2 недели (итерации). В ходе каждой итерации проводятся все основные стадии жизненного цикла, такие как выявление требований, анализ, разработка, тестирование, внедрение. После чего заказчику демонстрируется рабочий прототип, происходит процесс сбора отзывов, разработки новых требований к системе и переопределения старых. По сути, каждая итера-
стадии как Проектирование, Анализ, Документирование, Разработка и Тестирование, что позволяет каждый раз выпускать рабочую версию продукта, постепенно наращивая функционал системы.
ция представляет собой реализацию проекта в миниатюре.
В связи с этим выделим несколько ключевых преимуществ:
Реакция на изменения, новые требования и идеи в случае применения итеративных методологий разработки - максимально оперативная, так как представитель заказчика является участником процесса разработки.
Стоимость изменения требований невелика, т к выпуски происходят достаточно часто, и каждое приращение функциональности системы мгновенно оценивается заказчиком.
Сокращение рисков исполнителя - риски распределяются между заказчиком и исполнителем.
Предсказуемость результата. Процесс разработки прозрачен для заказчика, в каждый момент времени имеется четкое представление о текущем состоянии системы и о соответствии ее реализованного функционала запланированному.
3 Анализ особенностей применения Agile-методов
По сравнению с каскадной моделью методы Agile предполагают несколько другое взаимодействие между заказчиком и исполнителем. Как было сказано выше два основных вида контрактов предполагают отношения сверху вниз - от заказчика к
исполнителю. Agile же предлагает другой вариант взаимодействия - партнерство. Тогда целью разработчиков становится не просто выполнение заказа в указанные сроки, с непонятным объемом и качеством, а поиск действительно правильного и подходящего решения. Партнеры тесно общаются и контактируют на протяжении всего проекта, именно этим способом достигается быстрая обратная связь. Agile преследует не слепое повиновение исполнителя заказчику, а желание помочь заказчику найти правильное решение для достижения своих целей. И это решение не всегда может находиться в области разработки, возможны и другие варианты решения, и чем опытнее и разностороннее команда, тем вероятность нахождения правильного решения больше.
Гибкость этих методологий позволяет выстраивать процесс производства в каждой компании индивидуально. Именно благодаря этому их свойству Agile-методологии никогда не дают ответ на вопрос «Как?» Agile не имеет четких указаний как быть в той или иной ситуации, какие решения принимать, как обрабатывать ту или иную информацию. Он представляет собой набор из 4 принципов и 12 правил. Они не являются сводом четких формализованных указаний, а являются начальной ступенью для экспериментов над процессами разработки. Каждая компания уникальна, имеет свои процессы и свою специфику, чтобы оптимально выстроить процесс производства необходимо постоянно совершенствовать сам процесс, получать обратную связь не только от заказчика, но и от сотрудников, которые непосредственно в этот процесс вовлечены. Основой для такого роста и развития организации является, прежде всего, общение между сотрудниками, именно процесс взаимодействия людей между собой позволяет улучшать качество продукта, сокращать сроки и получать обратную связь от заказчика.
Помимо общения между собой, сотрудники (разработчики, бизнес-аналитики и так далее) должны не просто предложить какое-либо решение заказчику, а просто понять его проблему. Заказчик приходит к организации по разработке с проблемами, он же (заказчик) думает, что качественное ПО или сложная система может решить его проблемы. Но это только его предположения, все решения в условиях большой неопределенности основываются исключительно на нашей интуиции и контексте, в котором мы находимся. Контекст разработчиков и заказчиков совершенно разный, именно поэтому и требуется постоянное взаимодействие. Поэтому первым пунктом в любой разработке будет стоять: Понять проблему заказчика. Только после этого этапа можно фантазировать и придумывать какое самое удачное решение поможет эту проблему решить. И третий пункт, после того как решение придумано, необходимо обязательно его про-валидировать, протестировать, проверить на практике, даже если продукт еще не готов к использованию. Именно это раннее тестирование своих идей дает наиболее плодотворные результаты, помогает избежать будущих ошибок, взглянуть на проблему под другим углом.
4 Ключевые принципы и компоненты гибких методологий
Главные принципы Agile описаны в документе под названием Agile Manifesto
(http://www.agilemanifesto.org/iso/ru/). Данный документ не является перечнем практических указаний, но наиболее точно описывает идеи, лежащие в основе подхода.
- люди и их взаимодействия важнее, чем процессы и инструменты;
- работающее программное обеспечение важнее, чем полная документация;
- сотрудничество с заказчиком важнее, чем контрактные обязательства;
- реакция на изменения важнее, чем следование плану.
Процессы и инструменты - достаточная важная составляющая в области разработки, но за любым процессом и инструментом всегда стоят люди,
которые их используют [11]. Невозможно сделать качественный продукт, если люди, которые над ним работают будут иметь разные представления о нем, двигаться в разные стороны и изолированно совершенствовать его свойства. За процессами и инструментами легко спрятать главную цель, которую преследует проект.
Главной ценностью проекта всегда является исправно работающий продукт, все процессы и административные движения во время проекта направлены исключительно на соблюдение качества разработки и сроков, сама документация на продукт не является целью, она лишь дополняет готовый продукт. К сожалению, в современном мире достаточно часто документация на продукт становится на передний план.
Наиболее часто встречающаяся ситуация, когда заказчик протестировав некоторую часть готового функционала, хочет что-либо изменить, улучшить, добавить. В случае жестких контрактных обязательств зачастую это невозможно. Однако Ад^е-подход предполагает наиболее гибкую реакцию на эти изменения. Важны не контрактные условия, а решение проблемы.
Однако, несмотря на все преимущества Ад^е-подхода, не все компании согласны делить ответственность за продукт вместе с разработчиками. Заказчики боятся, что:
- их ожидания будут обмануты, так как нет четкого плана и представления о конечном продукте в виде большой спецификации.
- стоимость продукта окажется выше предполагаемой.
- будут отсутствовать четкие сроки.
Существует несколько способов как продолжить
взаимодействие с заказчиком, который сильно подвержен таким страхам. Чаще всего советуют с такими заказчиками не работать, так как «заразить» их Ад^е-подходом сложно и практически невозможно, результат такого взаимодействия может пагубно сказаться как на разработчиках, так и на заказчике. С другой стороны, существует много компаний, которые готовы к внутренним изменениям и готовы сотрудничать. В любом случае на каждом этапе заказчик может:
- остановить проект;
- откорректировать функциональность проекта;
- тестировать проект;
- запустить проект в работу и оценивать его экономическую эффективность.
Существует несколько ключевых техник, которые являются основами гибкого метода управления. Данные техники могут быть использованы в любом методе управления процессом разработки, но наиболее эффективными они становятся вместе с Agile-подходом:
Визуальный контроль. Все процессы лучше визуализировать с помощью карточек или стикеров на свободной стене. Визуальная доска с задачами дает большее представление о проекте и о том, кто и чем занимается в этом проекте, чем файлы в компьютере.
Расположение рабочей команды в одном помещении. Если представители разных направлений и профессий работают в одной комнате, их взаимодействие намного упрощается, быстрее решаются административные и мелкие вопросы.
Разработка с помощью тестирования. Во время сбора требований почти всегда параллельно начинают разрабатывать тесты. Под каждое требование разрабатывают свой набор тестов. Если какое-либо требование сложно или невозможно протестировать, это говорит о том, что оно не до конца разработана и требует большей проработки.
Руководитель является лидером, а не контроллером. Лидерство руководителя обуславливает самостоятельность и автономность команды во время принятия решений. Самостоятельной команде не нужно по каждому вопросу обращаться к руководителю проекта, большинство решений она может принимать самостоятельно.
Усвоение полученных уроков. Все учатся на своих ошибках, главной задачей является выявле-
ние этих ошибок на ранней стадии без губительных для проекта последствий. Каждый обретенный навык и знание должны обязательно усваиваться всей командой.
5 Инструменты для анализа производительности и качества проектной команды
Следующие инструменты хорошо зарекомендовали себя в качестве метрики успешности выполнения проекта/производительности команды [12-14]:
- Burndown Chart (диаграмма сгорания задач);
- Velocity Chart (диаграммы производительности);
- вычисление среднего времени выполнения задачи.
Burndown Chart - график показателей степени выполнения задач в рамках одной итерации. На горизонтальной оси расположены даты, вертикальная ось отображает число невыполненных задач.
Начало графика располагается в начале итерации при 100% невыполненных задач. Две линии соответствуют запланированному и фактическому прогрессу. Цель - достичь нуля задач к концу итерации проекта.
Velocity Chart - универсальная метрика для измерения производительности команды. Показыьа-
ет число запланированных и выполненных задач с разделением по итерациям. Позволяет определить, насколько хорошо команда справляется с планом и запланировать будущие итерации. На горизонтальной оси отмечены спринты, на вертикальной -число выполненных задач согласно плану и по факту.
Рисунок 4 - График «Burndown Chart»
Рисунок 4
Диаграмма типа Velocity Chart
Вычисление среднего времени выполнения задачи (LeadTime). Параметр, который используется при расчете любого проекта. У каждой команды собственное время выполнения определенных задач, из проекта в проект это время меняется незначительно (если команда слаженная и самостоятельная), поэтому отслеживание этого параметра даёт возможность корректировать расчеты и свои представления о проекте. Также этот параметр может являться показателем успеха и развития команды разработки.
Анализируя закон Литтла, который гласит: «Чем меньше задач на стадии разработки, тем меньше среднее время выполнения задачи», вычисление среднего времени выполнения задачи может быть представлено по следующей формуле:
МР
где
LeadTime^ =
1p DeliveryRate-
LeadTime■
I p
I p
среднее время выполнения зада-
чи за определенный промежуток времени;
WIP (Work In Progress) - количество задач, которые находятся на этапе разработки;
DeliveryRate^p - временной промежуток, во время которого задачи находятся на этапе разработки.
Однако все эти показатели являются эмпирическими и накапливаются только по мере опыта и экспериментирования. Для каждой команды оптимальные показатели могут быть разными. Однако общая тенденция сводится к тому, что есть опре-
деленный максимум задач, которые могут находиться на этапе разработки, превышение которого ведет к беспорядку и хаосу в задачах. Из-за которого снижаются показатели скорости выполнения задач и качество выполнения.
Метрики помогают проектной команде в общих чертах определить текущее положение дел. Однако наиболее точные результаты и достоверные данные можно получить лишь при использовании совокупности данных показателей эффективности. Анализ отдельных метрик может привести к необъективным и ошибочным суждениям.
Заключение
В ходе сравнительного анализа двух семейств методологий: водопадной модели разработки и Agile-подхода продемонстрированы их основные возможности, рассказано о преимуществах Ад^е-метода, освящены основные его аспекты и техники. Agile-методология предполагает быструю разработку, тесное взаимодействие команды разработки и заказчика, разделение ответственности между ними. Все приведенные техники и принципы могут быть использованы в любой модели управления производством, но большего эффекта можно добиться, если использовать их все вместе.
Все выводы и расчеты в Ад^е-подходе являются результатом эмпирического исследования, оптимальные цифры и показатели выбираются на основе опытных данных. Диаграммы и графики, посвященные скорости выполнения проекта являются инструментом для отслеживания продуктивности и эффективности команды.
ЛИТЕРАТУРА
1. Блэк Р. Ключевые процессы тестирования. Планирование, подготовка, проведение, совершенствование. 2006. - 566 с.
2. Вигерс К. Разработка требований к программному обеспечению. 2004. - 576 с.
3. Власов А.И. Пространственная модель оценки эволюции методов визуального проектирования сложных систем // Датчики и системы. 2013. №9. С. 10-28.
4. Перегудов Ф.И., Тарасенко Ф.Л. Введение в системный анализ - М: ВШ, 1989.
5. Иванов А.М., Власов А.И. Верификация программных моделей коммуникационных сетей // Наука и образование: электронное научно-техническое издание. 2012. № 10. С. 24.
6. Власов А.И., Лыткин С.Л., Яковлев В.Л. Краткое практическое руководство разработчика по языку PL/SQL - М.: Машиностроение. 2000. Том 2. Библиотека журнала "Информационные технологии". -64 с.
7. Калянов Г.Н. CASE технологии. Консалтинг при автоматизации бизнес - процессов. - М.: Горячая линия - Телеком, 2000. - 320 с., ил.
8. В.В. Репин, В.Г.Елиферов Процессный подход к управлению. Моделирование бизнес-процессов. -РИА "Стандарты и качество", Москва 2004 г., 404 стр.
9. А.Закис RUP и другие методологии разработки ПО: Принципы сравнения методологий разработки ПО // КомпьютерПресс. - 2006. - N 8. - С. 158-159.
10. Власов А.И. Системный анализ технологических процессов производства сложных технических систем с использованием визуальных моделей// Международный научно-исследовательский журнал -2013. - №10. - С.17-26.
11. Гришко А.К. Информационная поддержка изделий на этапах жизненного цикла - основа системной работы по качеству // Труды международного симпозиума «Надежность и качество». - Пенза, 2010. Т. I. - С. 281-283.
12. Артемов И.И. Дислокационная модель фреттинг-усталости в условиях вибрационного нагружения металла / Артемов И.И., Кревчик В.Д. // Проблемы машиностроения и надежности машин. 2004. № 5. С. 42-45.
13. Граб В.П., Паникова Т.В. Процессный подход при управлении качеством изделий // Труды международного симпозиума «Надежность и качество». - Пенза, 2006. Т. 2. - С. 255-258.
14. А.И.Власов, Э.Н.Камышная, В.В.Маркелов Визуальные методы системного анализа при управлении качеством изделий электронной техники // Труды международного симпозиума «Надёжность и качество». - Пенза, 2014. Т I. - С.246- 249.
15. Юрков Н.К., Руляев Е.Ю., Полтавский А.В. Взгляд на теорию алгоритмов с позиции философии // Надежность и качество сложных систем. - 2014. - №2. - С 40-46.
УДК 519.95
Годунов1 А.Иг Мандриков1 В.И, Сущик2 Д.М.
пензенский государственный университет, Пенза, Россия
2Военный институт Сил воздушной обороны Республики Казахстан им. Т.Я. Бегельдинова, Актобе, Казахстан
ФОРМАЛИЗОВАННЫЕ МОДЕЛИ КОНТРОЛЯ ДЕЙСТВИЙ ЛЁТНОГО ЭКИПАЖА ПО УПРАВЛЕНИЮ ЛЕТАТЕЛЬНЫМ АППАРАТОМ
Работа экипажа по управлению летательным аппаратом (ЛА) относится к наиболее сложным формам человеческой деятельности. Специфическими особенностями этой деятельности являются: сложность и разнообразие действий по управлению ЛА и его системами; высокая ответственность за исход полета; высокие требования к темпу выполнения необходимых действий, приближающихся к пределам физиологических возможностей человека; возникновение различного рода непредвиденных ситуаций, в отдельных случаях, связанных с риском для жизни.
Сложность работы экипажа определяется необходимостью восприятия в каждый момент времени большого количества различных сигналов, принятием решения на основе всей получаемой информации, выполнением необходимых действий в соответствии с принятым решением за ограниченные промежутки времени.
Рассматривая управление ЛА, реализуемое человеком-оператором, следует отметить, что такое взаимодействие носит кусочно-непрерывный характер и представляет собой совокупность отдельных операций. При этом под операцией понимается такое действие лётного экипажа по управлению ЛА, для которого существует совокупность условий, определяющих его начало и конец. Понятие операции не предполагает обязательной непрерывности в действиях человека во времени при рассмотрении данного элемента процесса. Операция может состоять из нескольких этапов с изменяемыми в зависимости от текущего состояния временными интервалами между ними. Важным в понятии операции являются не условие непрерывности в действиях человека, а смысловое значение объединения этапов в операцию. Человек-оператор может на основании оценки общего состояния подключаться к управлению различных объектов в режиме разделения времени. Возможность подобного характера деятельности определяется свойст-
вом инерционности управляемых объектов, а также свойством человека последовательно выполнять элементы различных операций.
В комплексе условий, определяющих существование моментов начала и окончания операций помимо смыслового единства составляющих их элементов включается также длительность операции.
Всё многообразие действий экипажа по управлению ЛА может быть квалифицировано на действия по: пилотированию ЛА; управлению бортовыми системами; контролю значений параметров бортовых систем; контролю динамики изменения параметров бортовых систем; связи с инструктором.
Контроль точности пилотирования. Экипаж, выполняя полет по заданной траектории, должен управлять процессом движения ЛА. Если экипаж обнаруживает отклонения от курса движения, либо от заданной высоты и скорости, то в штурвальном и директорном режимах такие отклонения ликвидируются действиями самого экипажа. Оценка точности пилотирования рассмотрена в рабате [1]. Для оценки точности пилотирования необходимо фиксировать не только отклонение фактической траектории от заданной, но и определять длительность того или иного отклонения, что требует определения обоснованной частоты контроля отклонения параметров движения.
Таким образом, для контроля точности пилотирования необходимо через интервалы времени ДЬ определять величину бокового уклонения, величины отклонений по высоте и скорости, фиксировать случаи прерывания этих отклонений от заданных нормативов и длительность таких превышений, а также определять максимальные отклонения за время выполнения контролируемых действий.
Рассмотрим алгоритм, реализующий указанные действия для каждого из контролируемых параметров. Исходными данными для работы алгоритма являются значения параметра г, измеряемого с определенной частотой, текущее значение времени
