CC BY
28
В.Г. Власов
канд. техн. наук, доцент, кафедра программного обеспечения, ФГБОУ ВПО «Ижевский государственный технический университет имени М. Т. Калашникова»
ИСПОЛЬЗОВАНИЕ МЕТОДИК ИНЖЕНЕРИИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
ПРИ ПРОЕКТИРОВАНИИ
Аннотация. В статье рассмотрены ряд практических методик, применение которых позволяет повысить качество разработки программного обеспечения (ПО). Также представлен ряд методик по подготовке студентов, позволяющих достичь более детального понимания предмета инженерии ПО.
Ключевые слова: инженерия ПО, методики проектирования ПО, требования к ПО, стандарты разработки ПО, итерационный подход, абстракция, классификация требований, спецификация требований, классы анализа, классы проектирования, классы кодирования.
V.G. Vlasov, Kalashnikov Izhevsk State Technical University
SOFTWARE DESIGN METHODOLOGIES BY SOFTWARE ENGINEERING
Abstract. The article describes a number of practical techniques, the use of which allows to improve the quality of software development. Also presents a number of techniques to prepare students, allowing to achieve a more detailed understanding of the subject software engineering.
Keywords: software engineering, software design methodologies, software requirements, software development standards, iterative approach, abstraction, classification of requirements, specification of requirements, analysis classes, classes design, coding classes.
Введение
Разнонаправленность и большой технологический разброс требований современных программных систем не позволяет выполнить разработку всех их по каким-либо стандартным методикам проектирования. Поэтому в настоящее время требуется выделить контрольные точки, которые в пределах допустимой «погрешности» позволяли бы унифицировать разработку для большинства видов программных проектов.
Нахождение «формулы» для решения разнородных программных проектов, можно назвать одной из главных целей инженерии ПО. Наиболее подходящее определение термина «Инженерия ПО» можно найти в статье [1]. Следует понимать, что «формула» решения проекта содержащего 20 тыс. требований (сложный проект), будет выглядеть «больше», чем «формула» для проекта с 20-ю требованиями (простой проект). В данной статье будет рассматриваться разработка «формулы» для сложного проекта, которую будут решать специалисты с назначенными ролями: «архитектор», «проектировщик», «кодировщик».
Проблемы с начальными требованиями
При получении первоначального технического задания (ТЗ) от заказчика оказывается, что набор требований к ПО разбросан по нескольким несвязанным документам, и там встречаются требования противоречащие друг другу. Для скорейшего их выявления и устранения таких противоречий можно составить такие документы, как классификация требований, спецификация требований.
Классификация требований - это таблица, в которой описательный текст из базового ТЗ переводится в отдельные строки таблицы в технической формулировке вида: «система должна...», «контроллер должен...» и т.д. После этого уже наборы требований сводятся в группы для снижения сложности первоначального набора требований системы. После этого для каждой из групп составляется т.н. спецификация требований, которая содержит наборы требований, которые становится возможным передать различным группам разработчиков, тем самым, обеспечив снижение сложности разработки всей системы.
Начало проектирования
По ранее составленной спецификации требований группа разработчиков сможет начать проектировать свою подсистему. Перед началом работы необходимо представить проект как набор классов анализа (КА). Класс анализа - часть системы, которая находится на верхнем уровне иерархии разработки ПО. Интерфейсная часть класса анализа представляется в виде списков функций, выраженных в терминах предметной области. Никакие программные термины на этом уровне не должны использоваться, поскольку сразу необходимо понять, что специалисты заказчика, которые будут эксплуатировать систему, не являются программистами. Иначе говоря, не стоит возлагать на плечи специалиста по контрольно-измерительным приборам и автоматике (КИПиА) задачи программиста системы.
Следует отметить, что на данном этапе проектирования обычно возникают вопросы по технологии (физическим принципам) работы системы. Эти вопросы следует незамедлительно передавать заказчику системы. Если поступить иначе, т.е. додумывать требования самостоятельно, то получаем риск выполнить проектирование «не той системы». Задачи данного уровня решаются специалистами с ролью «архитектор».
Проблема требований после первой итерации
Класс проектирования (КП) является структурным элементом КА и позволяет приблизить требования предметной области и требования к конечному программному продукту. Разработка ведется методом декомпозиции требований к КА. На данном уровне рекомендуется использовать так называемый «псевдокод» [2, с. 209], т.е. использовать совмещение терминов из предметной области и области программирования.
Выполнив разработку КП, обычно выявляются т.н. недоработки в интерфейсах КА, что устраняется путем итерации с возвратом к перепроектированию соответствующего КА. На этом этапе возникают вопросы технической реализации системы. Для повышения качества системы эти вопросы стоит незамедлительно передать заказчику и перейти к разработке следующего КП. Задачи данного уровня решаются специалистами с ролью «проектировщик».
Детализация проекта
По описанию предыдущих этапов разработки КА и КП можно заметить, что они применимы не только для разработки ПО, но и в других областях (при смене определений КА и КП на соответствующие формулировки).
Пройдя уровни КА и КП, обычно сразу же приступают к кодированию, но это не совсем верный подход, особенно для сложных систем. Здесь можно выделить такой специфический для создания ПО этап, как разработка классов кодирования (КК), т.е. их интерфейсных функций (пока что без самой реализации). При этом документирование описания КК в графическом виде позволяет более понятной форме задать (определить) принадлежность конкретного КК к конкретной группе классов по функциональной или структурной принадлежности. Это значительно снижает сложность, поскольку следить за структурой проекта даже в современной IDE человеку значительно сложнее, чем когда она (структура) представлена в виде схемы на рисунках. Следует отметить, что в дальнейшем наличие таких схем повышает качество сопровождения уже созданной программной системы. Задачи данного уровня все еще решаются специалистом с ролью «проектировщик».
Реализация проекта
Только имея на руках полностью либо частично готовый набор КК, можно приступать к написанию проекта. Следует не забывать, что в настоящее время имеется ряд технических средств, обеспечивающих разработку классов кодирования на конкретном языке программирования. На этом этапе конкретизируются вопросы интерфейсов (для языка C++ - классов, для Delphi - типов). Задачи данного уровня решаются специалистом с ролью «кодировщик».
Методы подготовки специалистов
Представленная выше схема работы предполагает естественную лестницу развития специалиста: кодировщик - проектировщик - архитектор. То есть для подготовки качественного архитектора необходимо начинать с подготовки студента-кодировщика.
Начальное обучение студентов соблюдению стандартов создания программного обеспечения (ПО) не является простой задачей, поскольку количество материала, необходимого для понимания, представляет из себя набор объемных стандартов IEEE [3]. Для качественного донесения материала при подготовке студентов к применению стандартов при проектировании ПО [4] используется методика обучения, основанная не на заучивании IEEE стандартов дословно, а донесение до студентов набора реперных точек [2, 5], таких как конвенции кодирования, эвристика при поиске решения, абстрагирование объектов и требований, контроль сложности и т.п.
Для более ясного пояснения шагов при декомпозиции исходного ТЗ по рекомендациям их была использована только основная часть правил UML для составления диаграмм, поскольку UML представляют собой большой набор правил, который сложно донести до студента без потери качества передаваемого материала [6].
Также для повышения качества специалистов при выполнении лабораторных работ они объединялись в группы по 2-3 человека. Процесс выборов выполнялся на основе понравившегося студенту «проекта» из набора проектов. Для контроля качества выполнения лабораторных работ на ресурсе «github.com» был создан отдельный репозиторий для хранения лабораторных работ с указанием правил заполнения подкаталогов с их проектами [7]. Это позволяет как объективно, так и оперативно обеспечивать мониторинг качества подготовки специалистов.
Заключение
В статье рассмотрены подходы к организации процессов создания качественного ПО с применением технологий программной инженерии, где для снижения количества ошибок в ПО необходимо:
• составлять документы «классификация требований» и «спецификация требований» перед началом выполнения проектирования;
• выполнять проектирование ПО «сверху-вниз» с постоянным использованием итеративного подхода;
• выполнять разбивку проекта на классы: анализ, проектирование, кодирование;
• выполнять документирование создания как документации проекта (схемы классов анализа, проектирования, кодирования), так и исходного кода путем использования систем контроля версий;
• выполнять разделение на роли: «архитектор», «проектировщик», «кодировщик».
Представленные методики были отработаны на площадках:
- «ИжГТУ» - обучение магистрантов кафедры «Программное обеспечение» принципам разработки ПО;
- «Ижевский радиозавод» - разработка навигационных проектов (IAR производства «IAR Systems», VisualStudio);
- «ООО «Радиосистемы» г. Ижевска - разработка ПО для SCADA систем («System Platform» производства Wonderware и «RSLogix5000» производства «Rockwell Automation»).
Список литературы:
1. Макконнелл С. Совершенный код. Мастер-класс: пер. с англ. - М.: Русская редакция, 2010. - 896 с.
2. Джазайери М. Основы инженерии программного обеспечения: пер. с англ. / М. Джа-зайери, К. Гецци, Д. Мандриоли. - 2-е изд. - СПб.: БХВ-Петербург, 2005. - 832 с. - (Серия «Внесерийные книги»).
3. Павловский Е.Н. Инженерный подход к подготовке специалистов по программной инженерии // Программная инженерия. - 2011. - № 1. - С. 39-44.
4. Рекомендации по преподаванию программной инженерии и информатики в университетах / пер. с англ. [Н.И. Бойко и др.]. - М., 2007. - 462 с.
5. Позин Б.А. Проблемы программной инженерии на современном этапе ее развития // Программная инженерия. - 2011. - № 1. - С. 2-6.
6. Марков А.В. Разработка программного обеспечения при совместном использовании ит1-диаграмм и сетей Петри (обзор) // Сборник научных трудов НГТУ. - 2013. - № 1 (71). - С. 96-131.
7. Липаев В.В. Развитие базовых стандартов программной инженерии // Программная инженерия. - 2012. - № 6. - С. 2-7.
