Программная инженерия. Учебное пособие для магистрантов направления подготовки 09.04.02 – Информационные системы и технологии

–Способность к взаимодействию;

–Простота работы;

–Краткость;

–Полнота протоколирования;

–Информативность;

–Расширяемость;

–Широта использования;

–Модульность;

–Независимость от программной платформы;

–Независимость от аппаратной платформы;

–Унификация интерфейсов;

–Унификация данных.

Поэтому смысл ревьюирования качества программных продуктов – в улучшении качества продукта.

Особенностью т. н. модели Мак-Кола в процессе ревьюирования является качество программного обеспечения может использоваться в качестве требований

кпрограммному продукту и в оценке качества ПО.

Всвою очередь, модель Боэма в системе ревьюирования отражает факторы и критерии качества программного продукта.

Вчем заключается сущность и предназначение первой, второй и третьей частей стандарта ISO 9126?

В1 части стандарта ISO 9126-1 качество ПО рассматривается в разрезе 6 структурных наборов характеристик. Каждая из которых имеет свои субхарактеристики (подхарактеристики).

– Функциональность

– Надежность

– Практичность

– Эффективность

– Сопровождаемость

– Мобильность

2 и 3 части стандарта ISO 9126 посвящены формализации внешних и внутренних метрик для характеристик качества сложных программных средств. Они содержат унифицированную рубрикацию, где отражены имя и назначение метрики, метод ее применения, способ измерения, тип шкалы метрики, тип измеряемой величины, исходные данные для измерения и сравнения, а также этапы жизненного цикла программного средства, к которым применима метрика.

Четвертая часть стандарта ISO 9126-4 предназначена для покупателей, поставщиков, разработчиков, сопровождающих, пользователей и менеджеров качества программных средств. В ней рассматриваются рекомендуемые виды характеристик программных средств.

Таким образом, краткая описательная сравнительная характеристика моделей ревьюирования программных модулей и модели оценки ISO 9126 сводится к следующим тезисам.

Модель Мак-Колда имела 3 направления анализа:

71

–Использование;

–Модификация;

–Переносимость.

Модель Боэма была разработана для определения качества ПО заданным набором показателей и метрик.

Модель FURPS/FURPS+ построена аналогично предыдущим, но в отличие от них состоит из 2 слоев:

–1 слой определяет характеристики;

–2 – связанные м ними атрибуты.

Модель качества ISO 9126-1 различает понятия внутреннего качества, связанного с характеристиками ПО самого по себе, без учета его поведения; внешнего качества, характеризующего ПО с точки зрения его поведения; и качества ПО при использовании в различных контекстах – того качества, которое ощущается пользователями при конкретных сценариях работы ПО. Для всех этих аспектов качества введены метрики, позволяющие оценить их. Кроме того, для создания надежного ПО существенно качество технологических процессов его разработки.

Отсюда – основные виды деятельности при управлении разработкой и проектированием программного средства:

–составление плана-проспекта по разработке ПС;

–планирование и составление расписаний по разработке ПС;

–управление издержками по разработке ПС;

–текущий контроль и документирование деятельности коллектива по разработке ПО;

–подбор и оценка персонала коллектива разработчиков ПС.

Рассмотрим, в чем заключается различие между обычными бригадами, неформальными демократическими бригадами и бригадами ведущего программиста?

Вобычной бригаде старший программист (лидер бригады) непосредственно руководит работой младших программистов. Недостатки такой организации непосредственно связаны со спецификой разработки ПС: программисты разрабатывают сильно связанные части программной подсистемы, сам процесс разработки состоит из многих этапов, каждый из которых требует особенных способностей от программиста, ошибки отдельного программиста могут препятствовать работе других программистов. Успех работы такой бригады достигается в том случае, когда ее руководитель является компетентным программистом, способным предъявлять к членам бригады разумные требования и умеющим поощрять хорошую работу.

Внеформальной демократической бригаде поручаемая ей работа обсуждается совместно всеми ее членами, а задания между ее членами распределяются согласованно в зависимости от способностей и опыта этих членов. Один из членов этой бригады является лидером (руководителем) бригады, но он также выполняет и некоторые задания, распределяемые между членами бригады. Неформальные демократические бригады могут весьма успешно справляться с

72

порученной им работой, если большинство членов бригады являются опытными

икомпетентными специалистами. Если же неформальная демократическая бригада состоит, в основном, из неопытных и некомпетентных членов, в деятельности бригады могут возникать большие трудности. Без наличия в бригаде хотя бы одного квалифицированного и авторитетного члена, способного координировать

инаправлять работу членов бригады, эти трудности могут привести к неудаче проекта.

Вбригаде ведущего программиста за разработку порученной программной подсистемы несет полную ответственность один человек, называемый ведущим программистом (chief programmer) и являющийся лидером бригады: он сам конструирует эту подсистему, составляет и отлаживает необходимые программы, пишет документацию к подсистеме.

Ведущий программист выбирается из числа опытных и одаренных программистов. Все остальные члены такой бригады, в основном, создают условия для наиболее продуктивной работы ведущего программиста. Организацию такой бригады обычно сравнивают с хирургической бригадой. Ядро бригады ведущего программиста составляют три члена бригады: помимо ведущего программиста в него входит дублер ведущего программиста и администратор базы данных разработки.

Менеджер сферы разработок отвечает за управление разработками программных средств (систем) определенного типа. Ему непосредственно подчинены менеджеры проектов, относящихся к его сфере. Получив поручение директора по выполнению некоторого проекта, он организует формирование коллектива исполнителей по этому проекту. Он участвует в обсуждении плана-проспекта программного проекта, относящегося к сфере разработок, за которую он отвечает, а также в обсуждении и решении возникающих проблем в развитии этого проекта. Он организует обобщение опыта разработок программных средств в его сфере и накопление программных средств и документов для повторного использования.

По каждому программному проекту назначается свой менеджер, который управляет развитием этого проекта. Менеджер проекта осуществляет планирование и составление расписаний работы этих бригад по разработке соответствующего ПС.

Важное место в управлении разработкой ПС отводится управление обеспечением качества. Для руководства этой деятельностью назначается специальный менеджер, подчиненный непосредственно директору, – менеджер по качеству. Ему непосредственно подчинены формируемые бригады по контролю качества.

Какие структурные составляющие входят в псевдокод по планированию и разработке программного средства?

– Определить ограничения, с которыми проект должен быть доведен до конца.

– Сделать начальную оценку параметров проекта.

– Установить этапы развития проекта и их сроки.

– Если проект не является завершенным или прекращенным (аннулированным) – необходимо составить расписание проекта.

73

–Инициировать процессы, соответствующие расписанию.

–Просмотреть развитие проекта.

–Скорректировать параметры проекта.

–Оценить влияние изменения параметров проекта на расписание проекта.

–Уточнить ограничения и сроки.

–При возникновении проблем – инициировать технический пересмотр и возможную ревизию проекта.

Напомним, что аттестация программного средства (ПС) – это авторитетное подтверждение качества ПС. Обычно для аттестации ПС создается аттестационная комиссия из экспертов, представителей заказчика и представителей разработчика.

Уточним, что такое метрика – по отношению к программе, программному продукту, их качеству? Метрика программного обеспечения – мера, позволяющая получить численное значение некоторого свойства программного обеспечения. Метрика – числовое значение, влияющее на выбор маршрута в компьютерных сетях. В случае статической маршрутизации это значение обычно не изме-

няется в пределах сессии. Ме́трика програ́ммного обеспе́чения (англ. software metric) – мера, позволяющая получить численное значение некоторого свойства программного обеспечения или его спецификаций.

Чем характеризуется спецификация требований к программному обеспечению?

Спецификация требований программного обеспечения (англ. Software Requirements Specification, SRS) – структурированный набор требований (функциональность, производительность, конструктивные ограничения и атрибуты) к программному обеспечению и его внешним интерфейсам. Предназначено для того, чтобы установить базу для соглашения между заказчиком и разработчиком (или подрядчиками) о том, как должен функционировать программный продукт. Может включать ряд пользовательских сценариев (англ. use cases), которые описывают варианты взаимодействия между пользователями и программным обеспечением.

Какие компоненты (составляющие) включает в себя набор используемых метрик?

1.порядок роста (имеется в виду анализ алгоритмов в терминах асимптотического анализа и O-нотации),

2.количество строк кода,

3.цикломатическая сложность,

4.анализ функциональных точек,

5.количество ошибок на 1000 строк кода,

6.степень покрытия кода тестированием,

7.покрытие требований,

8.количество классов и интерфейсов,

9.метрики программного пакета от Роберта Сесиль Мартина,

10.связность.

74

Перечислим основные информационные характеристики функциональности

иполезности программного продукта.

1)Количество внешних вводов. Подсчитываются все вводы пользователя, по которым поступают разные прикладные данные. Вводы должны быть отделены от запросов, которые подсчитываются отдельно.

2)Количество внешних выводов. Подсчитываются все выводы, по которым к пользователю поступают результаты, вычисленные программным приложением. В этом контексте выводы означают отчеты, экраны, распечатки, сообщения об ошибках. Индивидуальные единицы данных внутри отчета отдельно не подсчитываются.

3)Количество внешних запросов. Под запросом понимается диалоговый ввод, который приводит к немедленному программному ответу в форме диалогового вывода. При этом диалоговый ввод в приложении не сохраняется, а диалоговый вывод не требует выполнения вычислений. Подсчитываются все запросы – каждый учитывается отдельно.

4)Количество внутренних логических файлов. Подсчитываются все логические файлы (то есть логические группы данных, которые могут быть частью базы данных или отдельным файлом).

5)Количество внешних интерфейсных файлов. Подсчитываются все логические файлы из других приложений, на которые ссылается данное приложение.

Уточним системные параметры метрики указателей основных свойств.

1. Передачи данных – Сколько средств связи требуется для передачи или обмена информацией с приложением или системой?

2. Распределенная обработка данных – Как обрабатываются распределенные данные и функции обработки?

3. Производительность – Нуждается ли пользователь в фиксации времени ответа или производительности?

4. Распространенность используемой конфигурации – Насколько распространена текущая аппаратная платформа, на которой будет выполняться приложение?

5. Скорость транзакций – Как часто выполняются транзакции? (каждый день, каждую неделю, каждый месяц)

6. Оперативный ввод данных – Какой процент информации надо вводить в

режиме онлайн?

7. Эффективность работы конечного пользователя – Приложение проектировалось для обеспечения эффективной работы конечного пользователя?

8. Оперативное обновление – Как много внутренних файлов обновляется в онлайновой транзакции?

9. Сложность обработки – выполняет ли приложение интенсивную логическую или математическую обработку?

10. Повторная используемость – Приложение разрабатывалось для удовлетворения требований одного или многих пользователей?

11. Легкость инсталляции – Насколько трудны преобразование и инсталляция приложения?

75

12.Легкость эксплуатации – Насколько эффективны и/или автоматизированы процедуры запуска, резервирования и восстановления?

13.Разнообразные условия размещения – была ли спроектирована, разработана и поддержана возможность инсталляции приложения в разных местах для различных организаций?

14.Простота изменений – была ли спроектирована, разработана и поддержана

вприложении простота изменений?

Уточним, чем характеризуются количественные метрики.

Данная метрика была изначально разработана для оценки трудозатрат по проекту. Однако из-за того, что одна и та же функциональность может быть разбита на несколько строк или записана в одну строку, метрика стала практически неприменимой с появлением языков, в которых в одну строку может быть записано больше одной команды. Поэтому различают логические и физические строки кода.

Логические строки кода – это количество команд программы. Данный вариант описания так же имеет свои недостатки, так как сильно зависит от используемого языка программирования и стиля программирования.

Кроме SLOC к количественным характеристикам относят также:

–количество пустых строк,

–количество комментариев,

–процент комментариев (отношение числа строк, содержащих комментарии

кобщему количеству строк, выраженное в процентах), среднее число строк для функций (классов, файлов), среднее число строк, содержащих исходный код для функций (классов, файлов), среднее число строк для модулей.

Возникает закономерный вопрос: для чего необходимо использовать метрики сложности потока управления программой?

Метрики сложности потока управления программой - большой класс метрик, основанный уже не на количественных показателях, а на анализе управляющего графа программы, называется метрики сложности потока управления программ.

Перед тем, как непосредственно описывать сами метрики, для лучшего понимания будет описан управляющий граф программы и способ его построения.

Пусть представлена некоторая программа. Для данной программы строится ориентированный граф, содержащий лишь один вход и один выход, при этом вершины графа соотносят с теми участками кода программы, в которых имеются лишь последовательные вычисления, и отсутствуют операторы ветвления и цикла, а дуги соотносят с переходами от блока к блоку и ветвями выполнения программы. Условие при построении данного графа: каждая вершина достижима из начальной, и конечная вершина достижима из любой другой вершины.

Продолжая тему анализа управляющего графа программы, можно выделить еще одну подгруппу метрик – метрики Харрисона, Мейджела. Данные меры учитывает уровень вложенности и протяженность программы.

Каждой вершине присваивается своя сложность в соответствии с оператором, который она изображает. Эта начальная сложность вершины может вычисляться любым способом, включая использование мер Холстеда. Выделим для каждой

76

предикатной вершины подграф, порожденный вершинами, которые являются концами исходящих из нее дуг, а также вершинами, достижимыми из каждой такой вершины (нижняя граница подграфа), и вершинами, лежащими на путях из предикатной вершины в какую-нибудь нижнюю границу. Этот подграф называется сферой влияния предикатной вершины.

Приведенной сложностью предикатной вершины называется сумма начальных или приведенных сложностей вершин, входящих в ее сферу влияния, плюс первичная сложность самой предикатной вершины.

Важно рассмотреть вопрос: где находят свое применение метрики сложности потока управления данными?

Метрика Чепина: суть метода состоит в оценке информационной прочности отдельно взятого программного модуля с помощью анализа характера использования переменных из списка ввода-вывода. Все множество переменных, составляющих список ввода-вывода, разбивается на 4 функциональные группы:

1)P – вводимые переменные для расчетов и для обеспечения вывода,

2)M – модифицируемые, или создаваемые внутри программы переменные,

3)C – переменные, участвующие в управлении работой программного модуля (управляющие переменные),

4)T – не используемые в программе («паразитные») переменные. Поскольку каждая переменная может выполнять одновременно несколько

функций, необходимо учитывать ее в каждой соответствующей функциональной группе.

Рассмотрим основные характеристики метрики надежности программного обеспечения.

Это метрики, близкие к количественным, но основанные на количестве ошибок и дефектов в программе. Нет смысла рассматривать особенности каждой из этих метрик, достаточно будет их просто перечислить: количество структурных изменений, произведенных с момента прошлой проверки, количество ошибок, выявленных в ходе просмотра кода, количество ошибок, выявленных при тестировании программы и количество необходимых структурных изменений, необходимых для корректной работы программы.

Для больших проектов обычно рассматривают данные показатели в отношении тысячи строк кода, т. е. среднее количество дефектов на тысячу строк кода. И, наконец, что означает понятие гибридные метрики программы? Метрики данного класса основываются на более простых метриках и представляют собой их взвешенную сумму. Первым представителем данного класса является метрика Кокола.

Таким образом, ревьюирование, или – инспекция программного кода (Code review) – это систематический и периодический анализ программного кода, направленный на поиск необнаруженных на ранних стадиях разработки программного продукта ошибок, а также, на выявление некачественных архитектурных решений и критических мест в программе. Большую роль в данном процессе играют различные качественные метрики программного продукта, что является важной задачей программной инженерии.

77

Контрольные вопросы:

1.Каковы особенности метрик сложности программного обеспечения?

2.Основные характеристики надежности кода программного продукта

3.Какова методология проектирования информационных систем в аспекте программной инженерии?

4.Какова роль информационных технологий и алгоритмов ревьюирования программных продуктов?

Литература:

Основная:

1.Лаврищева Е.М. Технология программирования и программная инженерия. Учебник для вузов. – М.: Ось-М, 2018. – 287 с.

2.Лешек А.М. Практическая программная инженерия на основе учебного примера. – Новосибирск: ЦРНС, 2017. – 254 с.

3.Черткова Е.А. Программная инженерия. Визуальное моделирование программных систем. М.: Академкнига, 2017. – 356 с.

Дополнительная:

1.Беркун С. Искусство управления IT-проектами. – СПб.: Питер, 2018. – 186

с.

2.Гайдышев И.Н. Решение научных и инженерных задач средствами Excel, VBA и C/C++. – М.: Инфра-М, 201. – 288 с.

78

Заключение

Программная инженерия это – ИТ-деятельность, связанная с систематическим, дисциплинированным, измеримым подходом к разработке, функционированию и сопровождению программного обеспечения, а также само исследование этих подходов. Другими словами, программная инженерия это – приложение дисциплины инженерии к программному обеспечению.

Термин «программная инженерия» появился впервые в 1968 году и предназначался для стимулирования поиска решений происходившего в то время «кризиса программного обеспечения». С тех пор это переросло в профессию программного инженера (англ. software engineer) и самостоятельную область исследований, посвящённых созданию программного обеспечения, более качественного, доступного, лучше поддерживаемого и оптимально разрабатываемого.

Институт программной инженерии предлагает сертификацию по конкретным специальностям, таким как: безопасность, оптимизация ИТ-процессов, а также архитектура программного обеспечения. С другой стороны, системная инженерия – междисциплинарный подход и средство для создания эффективных систем; междисциплинарный подход, охватывающий все технические усилия по развитию и верификации интегрированного и сбалансированного в жизненном цикле множества системных решений, касающихся людей, продукта и процесса, которые удовлетворяют потребности заказчика.

В свою очередь, системотехника – советская инженерная дисциплина, появившаяся как аналог системной инженерии (англ. systems engineering) – направления науки и техники, охватывающего проектирование, создание, испытание и эксплуатацию сложных систем технического и социально-технического характера.

Особое значение в исследовании проблем программной инженерии имеет архитектура системы – принципиальная организация системы, воплощенная в её элементах, их взаимоотношениях друг с другом и со средой, а также принципы, направляющие её проектирование и эволюцию. Понятие архитектуры в значительной мере субъективно и имеет множество противоречивых толкований; в лучшем случае оно отображает общую точку зрения команды ИТ-разра- ботчиков на результаты проектирования информационной системы.

Цель создания архитектуры – структурирование. Структурирование может означать превращение формы в функцию, извлечение порядка из хаоса, или преобразование частично сформированных идей клиента в пригодную для работы концептуальную модель.

Особое место и роль в исследовании различных аспектов программной инженерии играет жизненный цикл информационной системы. Жизненный цикл ИТ- системы – это стадии процесса, охватывающие различные ее состояния, начиная с момента возникновения необходимости в такой системе и заканчивая её полным выводом из эксплуатации; конечный набор общих фаз и этапов, через которые система может проходить в течение своей истории жизни.

79

Жизненный цикл – это не временной период существования, а процесс последовательного изменения состояния, обусловленный видом производимых воздействий. Под термином «жизненный цикл системы» обычно понимают эволюцию новой системы в виде нескольких ступеней, включающих такие важные стадии, как концепция, разработка, производство, эксплуатация и окончательное выведение из эксплуатации. В стандартах системной инженерии описаны четыре основных принципа моделирования жизненного цикла.

Вструктуре программной инженерии особое место принадлежит управлению разработкой программного средства (ПС) (software management). Это – деятельность, направленная на обеспечение необходимых условий для работы коллектива разработчиков ПС, на планирование и контроль деятельности этого коллектива с целью обеспечения требуемого качества ПС, выполнения сроков и бюджета разработки ПС. Часто эту деятельность называют управлением программным проектом (software project management). Здесь под программным проектом (software project) понимают всю совокупность работ, связанную с разработкой ПС, а ход выполнения этих работ называют развитием программного проекта

(software project progress).

Существенную роль в управлении качеством ПС играют программные (софтверные) стандарты. Они фиксируют удачный опыт высоко квалифицированных специалистов по разработке ПС для различных их классов и для разных моделей их качества. Следование подходящим стандартам может существенно облегчить достижение поставленных целей относительно качества ПС, а также упростить контроль качества. Кроме того, стандарты способствуют формированию взаимопонимания внутри коллектива разработчиков и упрощают процесс обучения новых членов этого коллектива.

Вархитектуре программной инженерий завершающим этапом разработки ПС является аттестация ПС, подводящая итог всей разработке. Аттестация

(certification) ПС − это авторитетное подтверждение качества ПС. Обычно для аттестации ПС создается аттестационная комиссия из экспертов, представителей заказчика и представителей разработчика. Эта комиссия проводит приемо-сда- точные испытания ПС с целью получения необходимой информации для оценки его качества. Под испытанием ПС здесь понимают процесс проведения комплекса мероприятий, исследующих пригодность ПС для успешной его эксплуатации (применения и сопровождения) в соответствии с требованиями заказчика.

В этом процессе проверяется полнота и исследуется качество представленной программной документации, производится необходимое тестирование программ, входящих в состав ПС, а также исследуются и другие свойства ПС, декларированные в его спецификации качества. На основе полученной информации специальная комиссия должна установить, в какой степени ПС выполняет декларированные функции и в какой степени ПС обладает декларированными примитивами и критериями качества. Решение аттестационной комиссии о произведенной оценке качества ПС фиксируется в соответствующем документе (сертификате), который подписывается членами комиссии.

80