Программная инженерия. Учебное пособие для магистрантов направления подготовки 09.04.02 – Информационные системы и технологии
.pdfоперационных систем. Кроме выбора платформы, на этапе проектирования определяются следующие характеристики архитектуры:
–будет ли это архитектура "файл-сервер" или "клиент-сервер";
–будет ли это 3-уровневая архитектура со следующими слоями: сервер, ПО промежуточного слоя (сервер приложений), клиентское ПО;
–будет ли база данных централизованной или распределенной. Если база данных будет распределенной, то какие механизмы поддержки согласованности
иактуальности данных будут использоваться;
–будет ли база данных однородной, то есть, будут ли все серверы баз данных продуктами одного и того же производителя (например, все серверы только Oracle или все серверы только DB2 UDB). Если база данных не будет однородной, то какое ПО будет использовано для обмена данными между СУБД разных производителей (уже существующее или разработанное специально как часть проекта);
–будут ли для достижения должной производительности использоваться параллельные серверы баз данных (например, Oracle Parallel Server, DB2 UDB и
т.п.).
Этап проектирования завершается разработкой технического проекта ИС. На этапе реализации осуществляется создание программного обеспечения си-
стемы, установка технических средств, разработка эксплуатационной документации.
Этап тестирования обычно оказывается распределенным во времени.
После завершения разработки отдельного модуля системы выполняют автономный тест, который преследует две основные цели:
–обнаружение отказов модуля (жестких сбоев);
–соответствие модуля спецификации (наличие всех необходимых функций, отсутствие лишних функций).
После того как автономный тест успешно пройдет, модуль включается в состав разработанной части системы, и группа сгенерированных модулей проходит тесты связей, которые должны отследить их взаимное влияние.
Далее группа модулей тестируется на надежность работы, то есть проходят, во-первых, тесты имитации отказов системы, а во-вторых, тесты наработки на отказ. Первая группа тестов показывает, насколько хорошо система восстанавливается после сбоев программного обеспечения, отказов аппаратного обеспечения. Вторая группа тестов определяет степень устойчивости системы при штатной работе и позволяет оценить время безотказной работы системы. В комплект тестов устойчивости должны входить тесты, имитирующие пиковую нагрузку на систему.
Затем весь комплект модулей проходит системный тест - тест внутренней приемки продукта, показывающий уровень его качества. Сюда входят тесты функциональности и тесты надежности системы.
Последний тест информационной системы – приемо-сдаточные испытания. Такой тест предусматривает показ информационной системы заказчику и
61
должен содержать группу тестов, моделирующих реальные бизнес-процессы, чтобы показать соответствие реализации требованиям заказчика.
Необходимость контролировать процесс создания ИС, гарантировать достижение целей разработки и соблюдение различных ограничений (бюджетных, временных и пр.) привело к широкому использованию в этой сфере методов и средств программной инженерии: структурного анализа, объектно-ориентиро- ванного моделирования, CASE-систем.
Контрольные вопросы:
1.Классификация информационных систем в среде программной инженерии.
2.Функциональное назначение модулей корпоративной ИС.
3.Классификация рынка информационных систем.
4.Что является конечными продуктами этапа проектирования.
Литература:
Основная:
1.Лаврищева Е.М. Технология программирования и программная инженерия. Учебник для вузов. – М.: Ось-М, 2018. – 287 с.
2.Лешек А.М. Практическая программная инженерия на основе учебного примера. – Новосибирск: ЦРНС, 2017. – 254 с.
3.Черткова Е.А. Программная инженерия. Визуальное моделирование программных систем. М.: Академкнига, 2017. – 356 с.
Дополнительная:
1.Беркун С. Искусство управления IT-проектами. – СПб.: Питер, 2018. – 186
с.
2.Гайдышев И.Н. Решение научных и инженерных задач средствами Excel, VBA и C/C++. – М.: Инфра-М, 201. – 288 с.
3.3. Информационные технологии и алгоритмы ревьюирования программных продуктов и программного обеспечения
Ревьюирование (или – инспекция) программного кода (Code review) – систематический и периодический анализ программного кода, направленный на поиск необнаруженных на ранних стадиях и основных этапах разработки программного продукта ошибок, а также, на выявление некачественных архитектурных решений и критических мест в программе.
Задачи и цели проведения формальных инспекций. Не всегда возможна разработка автоматических или хотя бы четко формализованных ручных тестов для проверки функциональности программной системы. В некоторых случаях выполнение тестируемого программного кода невозможно в условиях, создаваемых тестовым окружением. Такая ситуация возможна во встроенных системах, если программный код предназначен для обработки исключительных ситуаций,
62
создаваемых только на реальном оборудование. В тех случаях, когда верифицируется не программный код, а проектная документация на систему, которую нельзя «выполнить» или создать для нее отдельные тестовые примеры, также обычно прибегают к методу экспертных исследований программного кода или документации на корректность или непротиворечивость.
Такие экспертные исследования называют инспекциями или просмотрами. Существует два типа инспекций – неформальные и формальные. Такие экспертные исследования называют инспекциями или просмотрами. Существует два типа инспекций – неформальные и формальные. При неформальной инспекции автор некоторого документа или части программной системы передает его эксперту, а тот, ознакомившись с документом, передает автору список замечаний, которые тот исправляет. Сам факт проведения инспекции и замечания нигде отдельно не сохраняются, состояние исправлений по замечаниям также нигде не отслеживается. Формальная инспекция является четко управляемым процессом, структура которого обычно четко определяется соответствующим стандартом проекта. Таким образом, все формальные инспекции имеют одинаковую структуру и одинаковые выходные документы, которые затем используются при разработке. Факт начала формальной инспекции четко фиксируется в общей базе данных проекта. Также фиксируются документы, подвергаемые инспекции, и списки замечаний, отслеживаются внесенные по замечаниям изменения. Этим формальная инспекция похожа на автоматизированное тестирование: списки замечаний имеют много общего с отчетами о выполнении тестовых примеров.
В ходе формальной инспекции группой специалистов осуществляется независимая проверка соответствия инспектируемых документов исходным документам. Независимость проверки обеспечивается тем, что она осуществляется инспекторами, не участвовавшими в разработке инспектируемого документа. В ходе формальной инспекции группой специалистов осуществляется независимая проверка соответствия инспектируемых документов исходным документам. Независимость проверки обеспечивается тем, что она осуществляется инспекторами, не участвовавшими в разработке инспектируемого документа. Входами процесса формальной инспекции являются инспектируемые документы и исходные документы, а выходами – материалы инспекции, включающие список обнаруженных несоответствий и решение об изменении статуса инспектируемых документов.
Рассмотрим этапы формальной инспекции и роли ее участников. Процесс формальной инспекции состоит из пяти фаз: инициализация, планирование, подготовка (экспертиза), обсуждение, завершение. В некоторых случаях подготовку и обсуждение целесообразно рассматривать не как последовательные этапы, а как параллельные подпроцессы. В частности, такая ситуация может сложиться при использовании автоматизированной системы поддержки проведения формальных инспекций.
Процедура формальной инспекции проекта должна точно описывать порядок проведения формальных инспекций в данном проекте. Процедура формальной инспекции проекта должна точно описывать порядок проведения формальных
63
инспекций в данном проекте. После устранения обнаруженных в ходе формальной инспекции несоответствий процесс формальной инспекции повторяется, возможно, в другой форме и с другим составом участников. Процедура формальной инспекции должна регламентировать возможные формы проведения повторной инспекции в зависимости от объема и характера изменений, внесенных в объект инспекции. Как правило, допускается упрощение процесса повторной инспекции (проведение инспекции одним инспектором, отсутствие фазы обсуждения) при внесении в объект инспекции незначительных изменений относительно ранее инспектировавшейся версии.
Говоря об инициализации, руководитель проекта или его заместитель запрашивает из базы, хранящей все данные проекта (например, из системы конфигурационного управления), список объектов, готовых к инспекции, выбирает объект инспекции, затем назначает участников формальной инспекции: автора, ведущего и одного или нескольких инспекторов. Ведущий также может выполнять роль инспектора; остальные участники выполняют только одну роль. На роль ведущего или инспектора не допускается назначать сотрудников, участвовавших в разработке объекта инспекции. В роли автора выступает один из разработчиков объекта инспекции, но возможны ситуации, когда разработчик недоступен - например, переведен в другой проект или находится в отпуске. Тогда на роль автора назначается сотрудник, который будет исправлять обнаруженные несоответствия в инспектируемых документах. При инспектировании документов, разработанных заказчиком, автор может не назначаться.
Говоря об инициализации, рекомендуется назначать не менее 2 инспекторов. Их количество может быть увеличено, если инспектируются документы особой сложности или новизны понятий, а также, если в качестве инспекторов привлекаются сотрудники с недостаточным опытом. Рекомендуемое общее число участников инспекции не должно превышать 5. В обоснованных случаях процедура формальной инспекции проекта может допускать проведение инспекции единственным инспектором, например, когда объект инспекции отличается особой простотой и оцениваемые характеристики такого объекта инспекции тривиальны. В случае, если проводится повторная инспекция по сокращенной форме, ведущий самостоятельно инициирует процесс повторной инспекции без участия руководителя проекта. Процедура формальной инспекции проекта может разрешать ведущему самостоятельно инициировать процесс повторной инспекции (в том же составе участников), даже когда она проводится в полной форме, если это диктуется спецификой проекта.
Что касается планирования, то по завершении процесса инициализации ведущий проверяет, что инспектируемые документы размещены в базе данных проекта, а их статус соответствует готовности к формальной инспекции. Если это не так, инспекция откладывается. Затем ведущий должен изменить статус инспектируемых документов так, чтобы отметить факт начала инспекции и ограничить доступ к инспектируемой документации. Во время инспекции изменение документов невозможно, а соответствующий статус сохраняется до конца инспекции. Этот статус называется Review. После этого ведущий должен скопировать из БД
64
проекта бланк инспекции и занести в него идентификаторы инспектируемых и исходных документов и номера их версий, список участников с указанием их ролей и дату фактического начала процесса инспекции, т.е. того момента, когда инспектируемые документы были переведены в состояние Review.
Ведущий должен оценить время, необходимое инспекторам для подготовки,
ипродолжительность обсуждения. Время, отводимое на этап подготовки, не может быть менее одного часа. Также ведущий должен определить дату, время и место обсуждения, если оно будет проходить в форме собрания. При этом может потребоваться согласование с другими участниками инспекции. Если оценка продолжительности обсуждения в форме собрания превышает 2 часа, то необходимо запланировать несколько собраний, каждое из которых будет длиться не более двух часов. Ведущий должен оценить время, необходимое инспекторам для подготовки, и продолжительность обсуждения. Время, отводимое на этап подготовки, не может быть менее одного часа. Также ведущий должен определить дату, время и место обсуждения, если оно будет проходить в форме собрания. При этом может потребоваться согласование с другими участниками инспекции. Если оценка продолжительности обсуждения в форме собрания превышает 2 часа, то необходимо запланировать несколько собраний, каждое из которых будет длиться не более двух часов. Процедура формальной инспекции проекта может допускать проведение повторной инспекции без собрания, если итогом предыдущей инспекции было решение о проведении повторной инспекции в сокращенной форме. Также допускается не проводить собрание, если результаты формальной инспекции ведутся и хранятся в электронном виде. В этом случае процедура формальной инспекции проекта должна регламентировать взаимодействия участников формальной инспекции между собой. Кроме того, процедура формальной инспекции проекта должна определять механизм подготовки, проведения обсуждения и принятия решения.
Подготовив бланк инспекции и определив время и место собрания, ведущий должен известить участников инспекции о времени и месте проведения собрания
иразослать им подготовленный бланк инспекции. Подготовив бланк инспекции
иопределив время и место собрания, ведущий должен известить участников инспекции о времени и месте проведения собрания и разослать им подготовленный бланк инспекции. Процедура формальной инспекции проекта может предусматривать использование бланка, заполненного в ходе предыдущей инспекции, если проводится повторная инспекция в сокращенной форме и при этом ведущий является единственным инспектором.
Вчем заключается отработка умения строить алгоритмы кода инспекции кода review? Что такое качественный код?
Не существует точного определения этого термина. Как правило, понимание того, как должен выглядеть качественный исходный код, основывается на многолетнем опыте специалиста.
Впрофессиональной среде судят ещё по нескольким свойствам:
– Восприятие. Код не перегружен сложными конструкциями, поэтому его легко понять даже без дополнительной документации или комментариев;
65
–Сопровождение. В продуманный код легко вносить изменения: менять конфигурации или даже платформы;
–Расширение. В него просто добавить новую функциональность без риска сломать алгоритм кода. Даже если возникнут какие-то неполадки, их можно быстро устранить;
–Передача. Хороший код можно передать другим разработчикам для поддержки или доработки, и у них не возникнет трудностей с его прочтением;
–Покрытие тестами. Чем выше процент покрытия кода тестами, тем больше вероятность избежать ненужных багов в будущем.
Плюсы и минусы code-review. Плюсы:
–Техника Code Review помогает на ранних стадиях находить некоторые ошибки и избавляться от непонятных и запутанных решений.
–Код легко передавать между участниками процесса.
–Благодаря Code Review снижается так называемый bus-фактор, или «фактор автобуса».
Минусы:
–Приходится тратить время на то, чтобы посмотреть и при необходимости прокомментировать код, а разработчику — на исправление ошибок.
–Новые дополнения попадают на этап тестирования не сразу, а только после прохождения review, из-за чего немного сдвигается график внутри этапа.
Что такое качественный код?
Не существует точного определения этого термина. Как правило, понимание того, как должен выглядеть качественный исходный код, основывается на многолетнем опыте специалиста.
В профессиональной среде судят ещё по нескольким свойствам:
–Восприятие. Код не перегружен сложными конструкциями, поэтому его легко понять даже без дополнительной документации или комментариев;
–Сопровождение. В продуманный код легко вносить изменения: менять конфигурации или даже платформы;
–Расширение. В него просто добавить новую функциональность без риска сломать алгоритм кода. Даже если возникнут какие-то неполадки, их можно быстро устранить;
–Передача. Хороший код можно передать другим разработчикам для поддержки или доработки, и у них не возникнет трудностей с его прочтением;
–Покрытие тестами. Чем выше процент покрытия кода тестами, тем больше вероятность избежать ненужных багов в будущем.
Процесс Code Review достаточно прост, а его плюсы заметно преобладают над минусами, но в ряде ситуаций вы легко обойдетесь без него.
К примеру, нет смысла проводить Code Review при разработке прототипа или MVP – минимально жизнеспособного продукта. Главная задача такого проекта – получить от пользователей обратную связь, чтобы построить гипотезы для дальнейшего развития. Структура этих приложений делается максимально простой,
ив дальнейшем код всё равно предстоит переписывать кардинальным образом.
66
Ещё Code Review не нужен в работе над простыми приложениями, которые делаются раз и навсегда. Так что, если вы не планируете в будущем изменять или дорабатыват свой проект, можно сэкономить время.
Нулевой этап ревьюирования заключается в самом процессе по созданию программного обеспечения (ПО). Но в чем заключается роль специалистов в команде проекта по созданию ПО?
Аналитик – специалист, хорошо разбирающийся в предметной области разрабатываемого проекта. Аналитик исследует проблемы, анализирует потребности заказчиков, планирует, что необходимо сделать при разработке продукта, и доносит эту информацию до команды разработчиков.
Бизнес-аналитик занимается анализом бизнес-области и формализует бизнеспроцессы данной области.
Системный аналитик отвечает за перевод требований, которые вытекают из бизнес-процессов заказчика, в конкретные функциональные требования к разрабатываемому ПО.
Разработчик архитектуры проекта разрабатывает архитектуру проектов. Команда программистов – разработчики ПО. В команде могут быть выде-
лены: администратор базы данных (занимается ее проектированием), проектировщик (проектирует компоненты системы).
Тестировщик – сотрудник, проверяющий корректность работы приложения в соответствии с требованиями и спецификациями для данного программного продукта.
Дизайнер – сотрудник, разрабатывающий внешний вид (интерфейс) программного продукта.
Руководитель проекта несет общую ответственность за проект, контролирует строки и качество выполнения задач, стимулирует и мотивирует сотрудников.
Администратор проекта помогает руководителю решать вопросы функционирования команды.
Специалист по подготовке пользователей разрабатывает учебную документацию о работе с ПО, обучает пользователей.
Сервисный инженер организует установку и сопровождение установленного продукта.
Специалист по маркетингу занимается продвижением продукта на рынке, его развитием и улучшением.
От каких факторов зависят методы организации работы в команде разработчиков?
Метод организации работы зависят от следующих факторов:
1.Какие задачи стоят перед командой;
2.Какие сотрудники входят в команду;
3.Какова структура команды;
4.Как происходит распределение обязанностей среди членов команды;
5.Каким образом взаимодействуют члены команды и какие вопросы требуют совместных решений;
6.Какие методы руководства и управления выбраны.
67
Какие существуют уровни групповой работы при разработке ПО?
1.Разработчик разрабатывает ПО;
2.Команда – организованное взаимодействие между разработчиками, требуются коммуникационные навыки;
3.Проект – объединяет несколько команд; требуется внимательное отношение к обмену данными, планированию и управлению ресурсами;
4.Бизнес-подразделение – каждому сотруднику необходимо решать задачи бизнес-подразделения. На работу влияют политика компании и корпоративная культура;
5.Компания – взаимодействие с другими компаниями, клиентам и поставщиками, возникают бизнес-стратегии.
Перечислим основные инструменты по организации слаженной работы команды программистов:
1.Методология разработки;
2.План проекта;
3.Средства автоматизации групповой работы;
4.Система управления версиями;
5.База данных ошибок.
Уточним основные возможности системы контроля версий VSC.
– Хранение нескольких версий одних и тех же файлов проекта;
– Возврат к определенным версиям файлов и проекта, сделанным ранее;
– Получение последних, актуальных на данный момент версий файлов проекта;
– Фиксация, кто и когда сделал изменение;
– Синхронизация работы команды по объединению изменений, выполненных разными разработчиками.
Таким образом, ревьюирование программных продуктов это – анализ, разбор, некоторая оценка публикации, произведения или продукта. Один из стандартных методов программной инженерии, направленный на проверку кода, его анализ. От английского review (обзор, рецензия).
Уточним основные методы ревьюирования программного кода. Одним из наиболее эффективных методов поиска и устранения недостатков кода является его рецензирование. В ходе этого процесса код подвергается проверке и критике, что помогает находить широкий класс ошибок и недоработок, с трудом детектируемых или недетектируемых компьютерной техникой и соответствующим ПО.
Нередко ревьюирование кода осуществляется одним посторонним лицом. Ревьюирование кода может осуществляется парами. При такой стратегии код
разрабатывает пара программистов за одним терминалом: один из них является ведущим – разрабатывает код, другой обдумывает сделанное и осуществляет контроль, исправляя ошибки до того, как код будет полностью написан.
Нередко применяется официальная инспекция кода группой разработчиков. Это регламентированная процедура проверки кода группой разработчиков, которая планируется заранее в строго определённые дату и время.
68
Рассмотрим преимущества и недостатки ревьюирования кода одним посторонним лицом.
Преимущества:
–Метод оценки более объективен в отличие от ревьюирования автором кода
–Могут быть даны советы сторонних разработчиков по доработке кода и исправлению ошибок
–Не требует большого количества времени и дополнительных формальных процедур
–Простота
–Резидент может проверить код в любое удобное для него время Недостатки:
–Проверяющий поверхностно знаком с кодом, следовательно, проверка может быть неэффективной
–Для проверки один из разработчиков отвлекается от своей основной работы
–Могут потребоваться дополнительные комментарии к коду автора, которые не всегда просто получить.
Рассмотрим этапы процедуры ревьюирования:
1. Автор сообщает, что код готов к ревьюированию
2. Определяется группа разработчиков для ревьюирования кода 3. Определяется дата и время работы группы для совместного ревьюирова-
ния, о чём оповещаются все члены группы 4. Решается вопрос, в какой форме будет происходить ревьюирвания 5. Определяется повестка собеседования
6. Подготавливаются необходимые ресурсы
7. Автора кода предоставляет его заранее всем членам группы
8. Члены группы изучают код до начала собрания Основные задачи, решаемые посредством ревьюирования программных про-
дуктов (кода):
–Всесторонняя проверка и улучшение качества кода;
–Уменьшение дефектов в коде;
–Обмен знаниями и опытом;
–Обучение молодых программистов;
–Повышение личной ответственности за разработку кода;
–Лучшее знакомство с проектом;
–Постепенная выработка единой стратегии к написанию кода;
–Совместное инспектирование наиболее сложных участков проекта и его завершающих этапов;
–Разработка более простого в сопровождении кода;
–Простота последующего тестирования кода;
–Удовлетворённость клиентов при работе с ПО, которое работает без оши-
бок.
Уточним цели анализа программных продуктов. Очевидно, что цель определяет направление исследования и необходимые результаты, от цели анализа
69
программных продуктов будет зависеть набор критериев для анализа того или иного объекта, в нашем случае – программного продукта.
Сравнительная характеристика моделей ревьюирования программных модулей
Корректность анализа программных продуктов означает верную оценку программного продукта.
Перечислим основные направления анализа программных продуктов:
1.Использование (корректность, надежность, эффективность, целостность, практичность);
2.Модификация (тестируемость, гибкость, сопровождаемость качества, важные для разработки новой версии ПО);
3.Переносимость (мобильность, возможность многократного использова-
ния).
Уточним критерии анализа и оценки программного обеспечения.
Критерии анализа любого объекта, в том числе и программного обеспечения, могут быть объективными и субъективными. Для корректной оценки субъективного критерия необходимо:
– Разработать шкалу оценки того или иного критерия;
– Опросить группу пользователей в соответствии с разработанной шкалой;
– Найти среднее значение оценки.
Выбор критериев для анализа ПО зависит от следующих составляющих:
– Цель;
– Анализ;
– Объект исследования.
Для чего необходима модель качества программного обеспечения?
Для определения качества ПО заданным набором показателей и метрик была разработана данная модель. Определяет характеристики и связанные с ними атрибуты.
Перечислим основные факторы качества ПО: корректность, надежность, эффективность, целостность, практичность, тестируемость, гибкость, сопровождаемость, возможность многократного использования, функциональная совместимость, мобильность.
Уточним основные критерии качества ПО:
– Функциональная полнота;
– Последовательность проектирования;
– Правильность;
– Устойчивость к ошибкам;
– Эффективность выполнения;
– Управление доступом;
– Контроль за доступом;
– Удобство работы;
– Удобство обучения;
70