CC BY
113
108
Вестник СГСЭУ. 2019. № 2 (76)
Pavel Vladimirovich Strubalin,
PhD in Economics,
associate professor of the department of information systems in economy, Saratov socio-economic institute (branch) of Plekhanov Russian University of Economics
Anna Alekseyevna Fatyanova,
PhD in Economics,
associate professor of the department of information systems in economy, Saratov socio-economic institute (branch) of Plekhanov Russian University of Economics
УДК 004.41
Павел Владимирович Струбалин,
кандидат экономических наук, доцент кафедры информационных систем в экономике, Саратовский социально-экономический институт (филиал)
РЭУ им. Г.В. Плеханова
Анна Алексеевна Фатьянова,
кандидат экономических наук, доцент кафедры информационных систем в экономике, Саратовский социально-экономический институт (филиал)
РЭУ им. Г.В. Плеханова
УПРАВЛЕНИЕ КАЧЕСТВОМ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
В статье рассматриваются особенности управления качеством программного обеспечения. Проанализированы подходы к определению данного понятия, международный опыт по оценке качества программного обеспечения и имеющиеся модели качества, отраженные в стандартах серии SQuaRE. На основе проведенного анализа предложена авторская концепция управления качеством при индивидуальных процессах разработки (PSP) и командном процессе разработки (TSP) программного обеспечения.
Ключевые слова: программное обеспечение, качество, модели качества, SQuaRE, модель зрелости возможностей.
QUALITY MANAGEMENT FOR SOFTWARE
The article discusses various aspects of software quality management. The authors analyze various approaches to the definition of this concept, study international experience in the evaluation of software quality and describe the existing quality assurance models presented in the SQuaRE standard. Based on their original analysis, the author suggest a concept of quality management for individual development processes (PSP) and team development process (TSP).
Keywords: software, quality, quality models, SQuaRE, capacity maturity model.
Современные экономические информационные системы имеют сложную структуру, миллионы строк программного кода, разнообразную документацию. Качество программного обеспечения влияет на стоимость и сроки разработки, неисправленные ошибки на этапах проектирования и разработки приводят к серьезным материальным потерям. Например, корпорация Ashton Tate, входящая вместе с Microsoft и Lotus в тройку самых крупных ИТ-компаний, разорилась из-за проблем с качеством разрабатываемых информационных систем.
Отметим, что разработчики часто используют системы тестирования для повышения качества программного обеспечения. Однако данный подход не соответствует современным требованиям, так как он позволяет только находить ошибки в коде, причем если после тестирования остается порядка 10-20% ошибок, то данный программный продукт считается достаточно качественным. Тестирование - это дорогостоящий процесс, так как до 80% стоимости разработки программного обеспечения тратится на обнаружение и исправление ошибок.
По опубликованным исследованиям Национального института стандартов и технологии установлено, что сбои программного обеспечения обходятся экономике США примерно в 59,5 млрд долл. ежегодно, или около 0,6% ВВП. Отметим, что по-
ловину расходов несут пользователи программного обеспечения, далее разработчики и поставщики, причем половина ошибок была найдена уже в процессе эксплуатации. Возрастающая сложность программного кода с уменьшением среднего срока жизненного цикла программного обеспечения увеличивает экономические издержки по поиску и обнаружению ошибок.
В последнее время появляются запросы на использование совокупности критериев для оценки качества программного обеспечения, так как ошибки в коде являются лишь одним из видов дефектов и только по данному критерию нельзя судить о качестве, поэтому немаловажное значение имеют такие критерии, как защита информации [1, с. 14] или удовлетворение потребностей потребителей в удобном интерфейсе и т.д.
Для того чтобы правильно сформулировать требования к качеству программного обеспечения, рассмотрим подходы к определению понятия качества. По мнению академика Международной академии качества Фила Кросби, «качество - это соответствие пользовательским требованиям», качество можно выразить количественно и измерить. Уотс Хамфри, автор концепции модели оценки зрелости СММ, описывает качество как «достижение отличного уровня пригодности к использова-
ISSN 1994-5094 ♦-
109 -♦
нию» [4]. Компания IBM определяет требования как «качество, управляемое рыночными потребностями (market-driven quality)» [2, с. 87].
Так или иначе, все эти определения указывают на то, что при управлении качеством программного обеспечения можно использовать количественные методы для оценки достижения поставленных целей.
Понятие качества чаще используется в соответствии с определением системы менеджмента качества ISO 9001 как степень соответствия присущих характеристик требованиям. В 2015 г. в России был принят стандарт ГОСТ Р ИСО/МЭК 25010-2015 «Информационные технологии (ИТ). Системная и программная инженерия. Требования и оценка качества систем и программного обеспечения (SQuaRE)», идентичный международному стандарту ИСО/МЭК 25010:2011 и являющийся составной частью серии международных стандартов SQuaRE. В этом стандарте определяется качество системы как степень удовлетворения системой заявленных и подразумеваемых потребностей различных заинтересованных сторон, которая позволяет, таким образом, оценить достоинства. Эти потребности представлены в международных стандартах серии SQuaRE посредством моделей качества, рассматривающих качество продукта в виде набора классов характеристик, которые, в свою очередь, разбиваются на подхарактеристики. Такая иерархическая структура наглядна и удобна для изучения.
К настоящему времени в серии SQuaRE имеются три модели качества:
- модель качества при использовании, определяет воздействие программного продукта на потребителя, которое зависит не только от качества программного обеспечения, но и от используемых аппаратных средств, характеристик пользователей, задач и социальной среды;
- модель качества продукта, применяется не только для отдельного программного продукта, но и для компьютерной системы в целом, в состав которой входит программное обеспечение;
- модель качества данных.
Совместное использование моделей качества дает основание считать, что учтены все характеристики качества. Данные модели предлагают набор характеристик качества, в которых заинтересован широкий круг лиц: владельцы, заказчики, разработчики, системные администраторы, подрядчики, специалисты обеспечения и управления качеством, менеджеры и пользователи.
Так, в модель качества при использовании входят пять характеристик:
- эффективность;
- производительность;
- удовлетворенность запросов пользователей, связанная в первую очередь с удобным интерфейсом;
- свобода от риска, учитывается смягчение отрицательных последствий от экономического ри-
ска, риска для здоровья и безопасности и других видов риска;
- покрытие контекста, учитывается как полнота контекста, так и его гибкость.
В модели качества продукта анализируется качество программного продукта на основе восьми характеристик:
- функциональная пригодность, которая отражает полноту, целесообразность и корректность функционала;
- уровень производительности, включающий в себя временные характеристики, использование ресурсов и потенциальные возможности;
- совместимость с другими программными средствами;
- удобство использования, в первую очередь оценивается доступность и эстетика пользовательского интерфейса, защищенность от ошибок пользователей, управляемость и легкость обучения;
- надежность, включающая в себя такие характеристики, как отказоустойчивость, восстанавливаемость, завершенность;
- защищенность, в большинстве случаев подразумевается конфиденциальность, целостность, отслеживаемость и подлинность данных;
- сопровождаемость, состоящая из модульности, возможности многократного использования, модифицируемости и т. д.;
- переносимость, адаптируемость, взаимозаменяемость различных компонентов программного обеспечения.
Целью модели качества продукта является компьютерная система, в которую входит целевой программный продукт, а цель модели качества при использовании - это совокупная человеко-машинная система, которая включает в себя и целевую компьютерную систему, и целевой программный продукт. В целевую компьютерную систему входят также компьютерное оборудование, нецелевые программные продукты, нецелевые данные и целевые данные, которые, в свою очередь, являются объектом анализа модели качества данных. Целевая компьютерная система является частью информационной системы, в состав которой могут быть также включены одна или более компьютерных систем и системы связи, такие как локальная сеть и интернет. В состав информационной системы в более крупной человеко-машинной системе (такой как корпоративная система, встроенная система или крупномасштабная система управления) могут входить пользователи, техническая и физическая среда использования. Рамки целевой системы определяются исходя из области применения требований или оценки и из того, кто рассматривается в качестве пользователей.
Практически невозможно определить или измерить все характеристики для всех частей большой компьютерной системы или программного продукта. Аналогично в большинстве случаев практически не применимо определение или измерение
110 ♦-
Вестник СГСЭУ. 2019. № 2 (76) -♦
качества при использовании для всех возможных сценариев задач пользователя. Относительная важность характеристик качества зависит от целей высокого уровня и целей проекта. В связи с этим перед использованием для выделения из требований тех характеристик, которые наиболее важны, модель должна быть соответствующим образом адаптирована, а ресурсы распределены между различными типами показателей в зависимости от целей заинтересованных лиц и целей продукта.
Утверждения о качестве программного обеспечения в данной статье основываются на свойствах модели зрелости возможностей (CMM), индивидуальных процессах разработки (Р5Р) и командном процессе разработки (Т5Р).
Индивидуальный процесс разработки (Р5Р) [4] основан на следующих принципах планирования и качества.
Производится оценка единицы разработчика, оценивается его эффективность, его планы работы и соответствие планов, что помогает разработчикам улучшать производительность.
Для последовательного повышения производительности разработчики используют четко определенные процессы, которые можно измерить, так как производство качественной продукции требует от разработчиков личной ответственности. Данные принципы базируются на следующих утверждениях: стоимость исправления дефектов на начальном этапе разработки меньше, чем исправление дефектов на поздних этапах; эффективнее предотвращать дефекты, чем находить и исправлять дефекты на поздних этапах разработки; тщательное планирование этапов разработки дешевле, чем исправление выявленных ошибок.
Последовательное следование планам при разработке программного обеспечения позволяет разработчикам оценивать свою личную эффективность, измерять время, которое они тратят на каждом шаге работы, дефекты, которые они находят и устраняют, и объем работы. Для стабильного производства качественной продукции разработчики должны планировать, измерять и отслеживать качество продукции с самого начала работы. Разработчики должны анализировать результаты каждого этапа разработки и использовать эти результаты для улучшения личного процесса разработки.
Таким образом, после определения требований к программному продукту следующим шагом в процессе Р5Р является планирование. Создается сценарий планирования, который регулирует процесс планирования и позволяет составлять базы для записи данных планирования. Так как разработчики следуют сценарию выполнения работ, разработчики отражают время этапов разработки и дефектные данные в журналах времени и дефектов. В конце разработки суммируются данные о времени и дефектах, измеряется объем программы и эти данные вводятся в форму сводки плана. На заклю-
чительном этапе готовый продукт сопоставляется с заполненной формой сводки плана.
Однако Р5Р не дает ответа, как должна быть выполнена работа по разработке программного продукта. На этот вопрос отвечает командный программный процесс (Т5Р) - это процесс, который точно определяет, как должна быть выполнена работа. Так как большинство плохо определенных программных процессов - это большие и полные текстовые описания, которые хранятся в книгах по определению процессов, операционный процесс больше похож на сценарий, он предназначен для использования членами команды, когда они выполняют разработку.
Командный программный процесс (Т5Р) позволяет определить операционный процесс для руководства разработчиками и менеджерами на этапах создания команды. Этот процесс определяет шаги, необходимые для создания эффективной среды работы в коллективе. Без конкретного руководства разработчики должны самостоятельно проработать детали создания команды и работы в команде. Поскольку определение этих деталей требует значительных навыков и усилий и поскольку немногие разработчики имеют опыт или время для разработки всех необходимых деталей, команды разработчиков обычно следуют формальным процессам построения команды и командной работы, что ведет к пустой трате времени и в конечном счете к плохому функционированию команды.
В командном программном процессе (Т5Р) определяются этапы разработки и план, разработчики выполняют свою работу эффективно, если следуют процессам, запланированным в этапах разработки. Если в плане нет описанного процесса, то разработка должна останавливаться на каждом шаге, чтобы понять, что делать дальше и как это сделать. Большинство процессов разработки достаточно сложны и включают в себя множество этапов. Без конкретного руководства разработчики скорее всего пропустят шаги, сделают шаги в непродуктивном порядке или потеряют время, выясняя, что делать дальше. Т5Р обеспечивает оперативные процессы, необходимые для формирования групп разработчиков, создания эффективной командной среды и руководства группами в выполнении работы.
Прежде чем члены команды смогут участвовать в команде Т5Р, они должны знать, как выполнять разработку, поэтому применение индивидуального процесса разработки (Р5Р) является одним из требований для обеспечения разработчиков знаниями и навыками использования Т5Р.
Есть много способов создания команд. Все они требуют, чтобы сотрудники работали вместе для решения сложной задачи. В Т5Р задача по созданию команды - это двух-четырехдневный процесс планирования, который называется запуском команды. Во время запуска все члены команды разрабатыва-
ISSN 1994-5094 ♦-
111 -♦
ют стратегию, процесс и план выполнения своего проекта. После завершения запуска команда следует своему определенному процессу для выполнения работы. Поскольку процесс TSP следует итеративной и эволюционирующей стратегии развития, необходимы периодические перезапуска, с тем чтобы каждый этап или цикл можно было планировать на основе знаний, полученных в предыдущем цикле. Перезапуск также необходим для обновления подробных планов разработчиков, которые уточняются на несколько месяцев.
Рассматривая жизненный цикл разработанного продукта, применяют интеграцию модели зрелости возможностей (CMM) - это модель зрелости совершенствования процесса для разработки продуктов и услуг. Модель состоит из передовых методов, которые касаются деятельности по разработке и обслуживанию, охватывающей жизненный цикл продукта от концепции до поставки и обслуживания.
Однако такая интеграция создает проблемы, так как организации, которые хотели бы применять более одной модели, отметили, что дублирование и коллизии в содержании и различия в архитектуре и руко-
водстве увеличивают стоимость и трудности общеорганизационного совершенствования [3, с. 132].
Не все рассмотренные в данных моделях характеристики качества одинаково важны для отдельного заинтересованного лица. Тем не менее интересы всех участников процесса должны быть учтены при анализе важности характеристик качества для каждой модели и при выборе тех, которые будут использоваться в каждом конкретном случае.
1. Волошин И.П. Защита информации в информационных системах персональных данных // Информационная безопасность регионов. 2016. № 1 (22). С. 12-15.
2. Информационные технологии и математические модели в инновационном развитии российской экономики / Хачатурова А.Э., Филиппов В.И., Чернышова Г.Ю., Гама-нюк Н.Г. и др. Саратов, 2018.
3. Струбалин П.В., Фатьянова А.А. Модель оценки управленческой информации // Вестник Саратовского государственного социально-экономического университета. 2017. № 4 (68). С. 130-132.
4. Хамфри У. Процесс персонального программного обеспечения (PSP). CMU / SEI-2000-TR-022. Pittsburgh, PA: Software Engineering Institute. URL: http://www.sei.cmu.edu/ reports/00tr022.pdf (дата обращения: 04.03.2019).
