Управление качеством программного обеспечения

недостаточноеколичество высокопрофессиональных консультантов по созданию ИТ- бизнесов (менторов) в стране.

Среди факторов, ограничивающих развитие ИТ в России, необходимо отметить низкий престиж ИТ в стране, недостаточное количество и уровень подготовки ИТ-специалистов, высокий уровень коррупции и недостаточный спрос на ИТ со стороны государства (по данным McKinsey, в 2011 г. 13% всех затрат на ИТ в России произвело государство, в то время как доля госсектора в общих ИТ-затратах мировой экономики приближается к 20%).

Выводы: Необходимыми условиями увеличения вклада России в мировой ИТ-рынок и укрепления позиций страны в глобальном разделении труда в области ИТ являются: реализация предлагаемого Стратегией системного подхода государства к улучшению условий для развития ИТ-отрасли в России и повышению привлекательности российской юрисдикции для работы ИТ-компаний при сохранении возможностей свободного рыночного развития отрасли.

 

1.2 Современные требования  к программному обеспечению

 

В результате, созданные программно-технические комплексы автоматизированных систем, не соответствуют в требуемом объеме своему назначению. Их приходится долго дорабатывать для достижения необходимого качества функционирования, что приводит к дополнительным затратам средств и времени. [3]

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

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

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

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

Требования к программному обеспечению, правильно сформулированные в техническом задании, обеспечивают до 40% успеха конечного программного продукта.

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

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

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

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

Фактически существуют следующие способы определения требований к программному обеспечению:

• при разработке требований, управляемой пользователем;
• при разработке требований, контролируемой пользователем;
• при разработке требований, независимой от пользователя.

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

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

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

На сегодняшний день существует 3 основных требования по уровням это:

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

Рассмотрим более подробно данные уровни.

Бизнес-требования содержат высокоуровневые цели организации или заказчиков системы. Как правило, их высказывают те, кто финансируют проект, покупатели системы, менеджер реальных пользователей, отдел маркетинга. В этом документе объясняется, почему организации нужна такая система, то есть описаны цели, которые организация намерена достичь с ее помощью. Необходимо записывать бизнес-требования в форме документа об образе и границах проекта, который еще иногда называют уставом проекта или документом рыночных требований. Определение границ проекта представляет собой первый этап управление общими проблемами увеличения объема работ.

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

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

После определения основных уровней ПО, необходимо рассмотреть Источники требований, на которые необходимо ссылаться при разработке программного обеспечения.

• Федеральное и муниципальное отраслевое законодательство (конституция, законы, распоряжения)
• Нормативное обеспечение организации (регламенты, положения, уставы, приказы)
• Текущая организация деятельности объекта автоматизации
• Модели деятельности (диаграммы бизнес-процессов)
• Представления и ожидания потребителей и пользователей системы
• Журналы использования существующих программно-аппаратных систем
• Конкурирующие программные продукты

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

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

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

Характеристики качественных требований по-разному определены различными источниками. Следующие характеристики являются общепризнанными, и приведены в таблице 1.

Таблица 1 – Характеристика качественных требований к программному обеспечению.

Характеристика	Объяснение
Единичность	Требование описывает одну и только одну вещь.
Завершенность	Требование полностью определено в одном месте и вся необходимая информация присутствует.
Последовательность	Требование не противоречит другим требованиям и полностью соответствует внешней документации.
Атомарность	Требование «атомарно». То есть оно не может быть разбито на ряд более детальных требований без потери завершённости.
Отслеживаемость	Требование полностью или частично соответствует деловым нуждам как заявлено заинтересованными лицами и документировано.
Актуальность	Требование не стало устаревшим с течением времени.
Выполнимость	Требование может быть реализовано в пределах проекта.
Недвусмысленность	Требование кратко определено без обращения к техническому жаргону, акронимам и другим скрытым формулировкам. Оно выражает объективные факты, не субъективные мнения. Возможна одна и только одна интерпретация. Определение не содержит нечётких фраз. Использование отрицательных утверждений и составных утверждений запрещено.
Обязательность	Требование представляет определённую заинтересованным лицом характеристику, отсутствие которой приведёт к неполноценности решения, которая не может быть проигнорирована. Необязательное требование – противоречие самому понятию требования.
Проверяемость	Реализованность требования может быть определена через один из четырёх возможных методов: осмотр, демонстрация, тест или анализ.

 

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

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

• требуют много времени для разработки, иногда даже рискуют устареть к концу разработки;
• ограничивают возможные способы реализации;
• являются слишком дорогостоящими.

Для поддержания работоспособности программного обеспечения и соответствия требований, необходимо проводить проверку.

Все требования должны быть поддающимися проверке. Наиболее общепринятая методика проверки — тесты. Если проверка тестами невозможна, тогда должен использоваться другой метод проверки (анализ, демонстрация, осмотр или обзор дизайна).

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

Нефункциональные требования, которые являются неподдающимися проверке на программном уровне, все равно должны быть сохранены как документация намерений клиента; Такие требования к продукту могут быть преобразованы в требования к процессу. Например, нефункциональное требование, чтобы ПО не содержало «потайных ходов», может быть удовлетворено заменой на требование использовать парное программирование.

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

 

 

1.3 Развитие подходов  к управлению качеством программного  обеспечения