Содержание к диссертации
Введение
Глава I. Современные проблемы обеспечения качества программных средств (ПС) 12
1.1. Цена ошибок программных средств 12
1.2. История развития автоматизированных банковских систем в России (АБС). Краткая характеристика рынка 18
1.3. Роль АБС в коммерческом банке, взаимодействие АБС с другими информационными системами 21
1.4. Проблемы качества и жизненный цикл АБС 26
Выводы по главе 1 35
Глава II Комплексный подход к решению проблем качества программных средств 36
2.1. Анализ понятия «качество» программных средств 36
2.2. Проблема обеспечения качества программных средств 43
2.3. Комплексный подход к обеспечению качества программных средств. 47
2.4. «Куб качества» программных средств. Требования к многомерной комплексной модели качества ПС 51
Выводы по главе II 55
Глава III. Формирование общей многомерной комплексной модели управления качеством программных средств 56
3.1. Уточнение измерения «куба качества» «взгляд на качество» 56
3.1.1. Уточнение измерения «куба качества» «взгляд на качество» с учетом ролей участников жизненного цикла программных средств 56
3.1.2. Анализ локальных «полей качества» 62
3.2 Таксономия современных стандартов в области разработки и обеспечения качества программных средств 72
3.3 Распределение современных стандартов программной инженерии по «кубу качества» 76
3.4 Эталонные модели «куба качества» потребителя и производителя...87
3.5 Построение многомерной комплексной модели качества 89
Выводы по главе III 102
Глава VI. Инструментальное средство поддержки комплексной многомерной модели качества для автоматизированных банковских систем. Учет затрат на качество в жизненном цикле программных средств 103
4.1 Анализ особенностей разработки и эксплуатации АБС 103
4.2 Адаптация комплексной многомерной модели качества для области разработки и эксплуатации АБС 104
4.3 Затраты на качество в жизненном цикле программных средств 107
4.4 Инструментальное средство поддержки многомерной комплексной модели качества программных средств 125
Выводы по главе IV 129
Заключение 130
Список использованной литературы 132
- Роль АБС в коммерческом банке, взаимодействие АБС с другими информационными системами
- «Куб качества» программных средств. Требования к многомерной комплексной модели качества ПС
- Распределение современных стандартов программной инженерии по «кубу качества»
- Адаптация комплексной многомерной модели качества для области разработки и эксплуатации АБС
Введение к работе
Актуальность темы исследования. В связи с активным развитием информационно-коммуникационных технологий (ИКТ) программное обеспечение (ПО) играет возрастающую роль в жизни современного общества и в современной экономике. Большое значение имеет качество создаваемого программного обеспечения. Именно сегодня, по мнению многих исследователей, возможностям эксплуатации существующих программных средства угрожает низкое качество их разработки.
Из-за ошибок в ПО происходят техногенные катастрофы, гибнут люди, компании несут прямые и косвенные потери. Вместе с тем, стоит отметить ежегодный рост объемов мирового рынка разработки и эксплуатации программных средств (ПС). Поэтому высокое качество разрабатываемых и эксплуатируемых ПС является неоспоримым конкурентным преимуществом.
Ошибки в программном обеспечении для кредитных организаций приводят к серьезным прямым и косвенным потерям, таким как: утрата репутации и доли на рынке, штрафам за неисполнение договорных обязательств или нормативных требований, выдвигаемых регулирующими органами, отзыву банковской лицензии из-за неисполнения требований Банка России. Вследствие этого банковская отрасль предъявляет особо высокие требования к качеству программных средств. Хотя не в интересах кредитных организаций разглашать сведения о сбоях программного обеспечения, подобные сообщения периодически появляются в открытых источниках. Общие проблемы разработки и эксплуатации программных средств нашли свое отражение и в жизненном цикле автоматизированных банковских систем (АБС).
Систематические исследования проблем, связанных с качеством ПО, начались в 70-е годы XX века. Качество ПС носит сложный (комплексный) характер, который необходимо учитывать при их разработке и эксплуатации, однако существующие подходы и модели для обеспечения качества ПС обладают рядом недостатков и не в полной мере учитывают его комплексный характер. В соответствии с исследованиями в области управления качеством, оно должно рассматриваться с точек зрения различных экономических субъектов - потребителя и производителя, зависит как от самого продукта, так и от процессов его создания. Для управления качеством необходимо иметь численную оценку его составляющих.
На практике возникают проблемы, связанные с отсутствием системной основы и методических рекомендаций по обеспечению качества ПС. Использование международных стандартов информационных технологий является одним их действенных методов обеспечения качества. Однако отдельные аспекты обеспечения качества ПС распределены по большому количеству стандартов, которые не систематизированы относительно этого вопроса. Стоит отметить, что часть используемых стандартов устарела, в их разных версиях встречаются противоречия и их применение для обеспечения качества при отсутствии системной основы затруднено.
Кроме того, в настоящее время практически невозможно сравнить достижения различных организаций в области качества разработки и эксплуатации программных средств с учетом его комплексного характера. Такая задача часто стоит перед потребителем при выборе поставщика ПС.
Таким образом, создание модели обеспечения качества ПС для различных областей экономики, учитывающей комплексный характер и особенности предметной области с использованием современных стандартов информационных технологий, является актуальной научной задачей, требующей скорейшего решения.
Цель и задачи исследования. Цель исследования состоит в разработке модели обеспечения качества программных средств с учетом его комплексного характера (на основе опыта разработки и эксплуатации АБС), а также построении инструментального средства поддержки модели. Для достижения поставленной цели определены следующие задачи:
Исследовать комплексный характер качества ПС для определения его свойств;
Выполнить анализ существующих моделей качества ПС с учетом комплексного характера;
Проанализировать и систематизировать стандарты программной инженерии на основе комплексного характера качества ПС;
Разработать модель качества программных средств, которая удовлетворяет следующим критериям: основывается на комплексном характере ПС; может применяться различными экономическими субъектами; использует современные стандарты программной инженерии; позволяет сравнивать текущее состояние в области качества различных компаний; предоставляет данные для оценки качества ПС; позволяет формализовать программу качества;
Провести адаптацию предложенной модели качества ПС к особенностям разработки и эксплуатации АБС;
Разработать инструментальное средство, поддерживающее предложенную комплексную модель качества разработки и эксплуатации ПС;
Предложить метод определения затрат на качество ПС, основанный на анализе существующих подходов к определению затрат на качество продукции применяемых в промышленном производстве.
Объект и предмет исследования. Объектом исследования является процесс разработки и эксплуатации программных средств. Предметом исследования являются методы и модели обеспечения качества программных средств.
Теоретическую и методологическую основу исследования составили работы отечественных и зарубежных специалистов в областях программной инженерии, управления качеством, стандартизации и сертификации программных средств, системного анализа. В диссертационном исследовании использованы положения, разработанные зарубежными авторами: Баллой К., Фентоном Н., Каном С, Китченхамом Б., Флегером С, Боэмом Б., Макколом, Вигерсом К.
Рассматриваемым вопросам посвящены работы отечественных авторов: Липаева В.В., Мхитаряна Ю.И., Лагутина B.C., Лавриченко Н.И., Герасимова Б.И., Шуракова В.В., Баутова А.Н.
Методологической базой исследования послужили общенаучные методы анализа и синтеза, системный подход. При решении задач использовался инструментарий теории графов.
Информационная база исследования. В процессе исследований применялись результаты работы российских компаний, выполняющих разработку и эксплуатацию автоматизированных банковских систем, в т.ч. разработки ЗАО «Банковские информационные системы», ОАО «Банк ВТБ», ОАО «Банк ВТБ24».
Научная новизна исследования заключается в разработке комплексной модели качества программных средств, а также создании инструментального средства для ее поддержки. Наиболее существенными результатами, полученными автором лично и составляющими научную новизну, являются:
1. Уточнено положение о комплексном характере качества программного средства. В результате чего в научный оборот введено
новое понятие «куб качества», которое наиболее полно отражает его комплексный характер.
Систематизированы стандарты разработки и эксплуатации программных средств с применением понятия «куб качества», что позволило определить области для дальнейшей стандартизации и гармонизации стандартов информационных технологий.
Предложена методика определения уровня зрелости исследуемой компании в области качества ПС, основанная на использовании стандартов программной инженерии и «кубе качества», которая в отличие от используемых в настоящее время методик позволяет оценивать различные аспекты качества компании, определять «слабые места» и направления улучшения того или иного аспекта качества ПС.
Реализована многомерная комплексная модель качества ПС на основе системного характера качества, которая в отличие от ранее предложенных наиболее полно учитывает сложный характер качества ПС.
Проведена адаптация модели, учитывающая специфику автоматизированных банковских систем. Составной частью адаптации является определение степени важности общепринятых характеристик качества ПС для различных участников жизненного цикла АБС.
Разработан программный инструментарий, поддерживающий многомерную комплексную модель качества. К достоинствам инструмента относится информационная база, которая позволяет получать полнотекстовые версии стандартов, соотнесенные с теми или иными аспектами качества, а также подсистема определения оптимальной программы качества, основанной на применении теории графов.
Синтезирован метод определения затрат на качество ПС, отличительными особенностями которого являются: уточненная автором классификация затрат на качество ПО, использование процессного подхода, а также стандартов процессов ЖЦПС и принципов пооперационного учета затрат.
Отмеченные результаты соответствуют пункту 2.7 «Проблемы стандартизации и сертификации информационных услуг и продуктов для экономических приложений» паспорта научной специальности 08.00.13. «Математические и инструментальные методы экономики». Экономический эффект от внедрения модели заключается в улучшении
управляемости компании, а также в повышении обоснованности принимаемых управленческих решений.
Теоретическая и практическая значимость работы. Основные положения работы представляют собой прикладной вклад в программную инженерию, а также в практику управление качеством продукции.
Выводы и результаты исследования могут быть использованы компаниями, производящими и использующими ПС, в частности, осуществляющими эксплуатацию, сопровождение, поставку, разработку, и заказ АБС.
Самостоятельное практическое значение имеют:
многомерная комплексная модель качества программных средств;
методика, позволяющая системно оценивать уровень достижений компаний в области качества (для организаций осуществляющих разработку и эксплуатацию ПО);
инструментальное средство поддержки модели.
Отдельные положения могут использоваться в учебном процессе экономических ВУЗов по подготовке специалистов в области информационных технологий. Разработанное инструментальное средство поддержки многомерной комплексной модели качества ПС позволяет объективно определять программу качества и может быть использовано как инструмент консалтинга в области качества.
Апробация и внедрение результатов исследования Основные положения и выводы диссертации докладывались и получили положительную оценку на международных и всероссийских форумах и конференциях: «Актуальные проблемы программной инженерии», Москва, МЭСИ, 10-11 ноября 2009; IV Международная научно-практическая конференция «Актуальные вопросы и современные тенденции развития системы противодействия легализации преступных доходов и финансированию терроризма в финансовом секторе России», Москва, 22 мая 2006; XI международный форум разработчиков интегрированных банковских систем, Москва, 19-22 сентября 2005 года; II международная конференция «Технологии банковского бизнеса: управление банком», Москва, 12-13 апреля 2004; VII Форум разработчиков ИБС, Москва, 25 сентября 2002 года. Отдельные результаты используются в деятельности компаний ЗАО «Банковские информационные системы», Управлении мониторинга банковских операций ОАО «Банк ВТБ», ЗАО «Чистюля», что подтверждается актами о внедрении. Отдельные положения используются в учебном процессе МЭСИ в рамках дисциплины «Разработка и
стандартизация программных средств и информационных технологий», а также включены в учебное пособие «Экономико-правовые основы рынка программного обеспечения», электронное учебное пособие «Базовый курс по программированию».
Публикации. По материалам диссертационного исследования опубликовано 14 научно-практических работ общим объемом 33,6_ п.л. ( в т.ч. авторских 12,9 п.л.), две в из них в изданиях, входящих в Перечень ведущих рецензируемых научных журналов и изданий.
Структура работы. Диссертационная работа состоит из введения, четырех глав, заключения, общим объемом 145 страниц, включая 24 рисунка, 13 таблиц и списка литературы из 141 позиции, 9 приложений.
Роль АБС в коммерческом банке, взаимодействие АБС с другими информационными системами
АБС является центом обработки и хранения информации в банке. АБС взаимодействует с другим программным обеспечением - системным, прикладным и специальным. Системное программное обеспечение (операционные системы, утилиты, сетевые службы) и специальное (пакеты криптозащиты информации) в силу их специфики рассматриваться не будут. Построим и проанализируем типовую схему взаимодействия АБС с внешними информационными системами. Элементы схемы могут отличаться для различных банков, возможные отличия обусловлены следующими факторами: перечень услуг, предоставляемых банком; наличие филиальной сети; региональные особенности банка и различных государственных органов; другие причины (например, наличие внешнего хранилища данных). Большое разнообразие используемых программных средств, обусловлено перечнем услуг, которые оказывает банк, и взаимодействием с различными государственными органами. Так в ОАО «Банк ВТБ», одном из крупнейших российских банков, для обеспечения деятельности используется более трех тысяч наименований программных средств. Основными путями снижения количества программных средств является унификация используемого программного обеспечения, интеграция новых функций в АБС. Так, ОАО «Банк ВТБ» вместо десятка различных АБС разных производителей перевел все свои филиалы на две АБС двух производителей - «БИСквит» фирмы БИС и «Новую Афину» компании «ПрограммБанк». Выбор одной единственной системы не был сделан по причинам экономической безопасности. Если бы банк выбрал одного единственного поставщика АБС для своей филиальной сети, то единственная компания-разработчик стала бы монополистом и могла бы диктовать банку свои условия.
Необходимость взаимодействия АБС с внешними информационными системами можно разделить на группы в зависимости от причины необходимости такого взаимодействия: регламентировано государственными органами, регламентировано вышестоящей организацией (головным банком), необходимо для предоставления банковских услуг. Рассмотрим подробнее каждую группу, представленную на рисунке 1.2. Представленный перечень взаимодействия АБС с другими программными средствами не претендует на полноту и может варьироваться в зависимости от реальных условий работы банка.
Группа программных средств, взаимодействие с которыми регламентировано государственными органами. - ПО для передачи информации в Федеральную службу финансового мониторинга (ФСФМ) в рамках противодействия легализации (отмыванию) доходов и финансированию терроризма (6); - ПО для передачи обязательной отчетности в Банк России. Для этих целей существует несколько пакетов программ, список которых варьируется в зависимости от региона (7); - ПО обмена информацией с подразделениями министерства по налогам и сборам. Банк обязан передавать информацию о факте открытия и закрытия счета в МНС. Информация может передаваться как на бумажном носителе, так и в электронном виде. Из МНС поступает информация о приостановлении операции по счетам, подтверждения о приеме информации (5); - ПО для обмена с расчетно-кассовыми центрами Банка России (РКЦ). Для участия в системе электронных расчетов ЦБР АБС должна взаимодействовать с комплексами региональных РКЦ, передавая и принимая электронные платежные документы (ЭПД) и электронные служебные информационные сообщение в унифицированном формате обмена электронными банковскими сообщениями (УФЭБС) [81] (ранее использовалось более десяти региональных форматов). Помимо сообщений, производится передача нормативно-справочной информации, например, справочник банков, информация о возможности электронного обмена с ними. Группа программных средств, взаимодействие с которыми регламентировано вышестоящей организацией (головным банком). - ПО для передачи информации в головную организацию. В случае, когда представленная схема относится к филиалу кредитной организации, головная организация может обязать филиал передавать отчеты о деятельности филиала и иную информацию (например, сведения о клиентах филиала, их счетах и операциях (8); ПО взаимодействия с хранилищем данных. В случае если АБС не в состоянии самостоятельно подготовить необходимую отчетность или по иным причинам, для составления отчетности первичная информация может выгружаться в специальные хранилища данных, которые позволяют строить различные обязательные и аналитические отчеты. Зачастую, в случае многофилиального банка, хранилище находится в головной организации, и информационный обмен с ним предписан головной организацией (10). Группа программных средств, взаимодействие с которыми с обусловлено предоставляемыми банком услугами. - ПО для взаимодействия с CRM (client relation management) системами. В случае, когда АБС не способна накапливать и обрабатывать разнообразную информацию о клиенте, используется внешняя CRM система, обмен с которой необходимо обеспечить (9); - ПО для взаимодействия с банками корреспондентами. В случае установления банком прямых корреспондентских отношений, банки договариваются о формате обмена и используемом программном обеспечении для обмена электронными платежами, выписками и прочей финансовой и служебной информацией (12); -ПО для взаимодействия с платежными системами «электронных денег». Обеспечивает взаимодействие с платежными системами, таких как «Яндекс-деньги», «Web-money», «Рапида» и пр. (13).
«Куб качества» программных средств. Требования к многомерной комплексной модели качества ПС
Де-факто определение качества состоит их двух уровней. Первое -присуще качеству продукта (еще обозначается как маленькое q - от "качество"). Более широкое определение качества включает качество продукта, качество процессов и удовлетворение пользователя и обозначается как большое Q. Этот второй подход широко используется во многих областях промышленности (включая отрасль программного обеспечения).
В узком смысле слова качество понимается как отсутствие ошибок в программном обеспечении, что в большой степени связано с концепцией соответствия требованиям. Это определение обычно выражают двумя путями: как интенсивность отказов и надежность. Удовлетворенность клиента обычно измеряется процентным соотношением удовлетворенных и неудовлетворенных клиентов. Так, IBM следит за удовлетворением с помощью уровня CUPRJMDSO (capability [functionality], usability, performance, reliability, installability, maintainability, documentation/information, service, overall). Hewlett-Packard использует свою концепцию FURPS (functionality, usability, reliability, performance, and serviceability). Другие компании также используют подобные практики измерения степени удовлетворения клиента.
Кан отмечает, чтобы улучшить качество, оно должно учитываться при планировании и создании ПО. Однако характеристики качества зачастую являются взаимоисключающими. В зависимости от пользователей программного обеспечения та или иная характеристика качества приобретает вес. Некоторые взаимосвязи между атрибутами качества являются взаимоисключающими, другие согласованы, третьи не определены четко и зависят от типов потребителя и приложения. Для ПО с разнообразным набором потребителей, таким образом, установка целей для различных атрибутов качества и требований клиента становится сложным процессом.
Через призму подходов «соответствия требованиям» и «пригодности к использованию» С. Кан делает попытку адаптировать понятие «качество» к области разработки программного обеспечения. Он полагает, что качество -это соответствие требованиям клиента. Не удивительно, что ошибки требований составляют одну из главных категорий проблем при разработке программного обеспечения. Согласно Джонс (Jones) [128], 15 % или больше всех дефектов программного обеспечения - ошибки требований. Процесс разработки, который не обращает внимание на качество требований, имеет на выходе низкокачественное программное обеспечение.
С. Кан (Кап) также отмечает еще одну точку зрения - качество процесса разработки против качества конечного продукта. Также существует точка зрения, которая расширяет представление пользователя о качестве и применяется к качеству процесса — разделение внешних и внутренних пользователей. Если после каждой стадии процесса разработки требования промежуточного пользователя (по отношению к следующему шагу) будет выполнено, то конечный продукт будет удовлетворять установленным требованиям. По мнению Кана, для улучшения качества во время разработки, необходимы модели процесса разработки. В пределах процесса должны быть развернуты определенные модели и подходы, и использованы надлежащие инструменты и технологии. Необходимо измерять характеристики и параметры качества процесса разработки.
Джон Хорч (John W. Horch) [104] не дает определения качеству, но выделяет цели Системы качества программного обеспечения (Software Quality System - SQS). Первая цель — встроить качество в ПО с самого начала разработки. Для обеспечения этой цели требования к ПО должны быть четко определены и задокументированы. Вторая цель SQS состоит в том, чтобы поддерживать качество программного обеспечения по всему ЖЦПС (Software Life Cycle - SLC). В качестве элементов системы качества выступают: стандарты, обзоры (которые выполняются в процессе выполнения фазы разработки и в конце фазы), тестирование, анализ дефектов,. управление конфигурацией, защищенность, образование, управление поставщиками, безопасность, управление рисками.
Джеф Тиан [140] отмечает важность деятельности по обеспечению качества и определяет качество программного обеспечения через его ожидаемые характеристики. По его мнению, ПО можно считать качественным, если оно способно выполнять те задачи, для которых оно предназначено, правильно или удовлетворительно. Поэтому, основной характеристикой ПО, согласно Тиану, является функциональная корректность. В этом плане аналогичное мнение разделяет Липаев В.В. [39] относительно функциональной пригодности ПО (функциональная корректность является одной из подхарактеристик функциональной пригодности). Основанная задача разработки программного обеспечения гарантировать качество через деятельность по валидации и верификации. Джеф Тиан выделяет две группы людей, связанных с программным обеспечением: производители и потребители. Потребители подразделяются на внешних и внутренних. При желании концепцию можно расширить, включив «невидимых» пользователей (аппаратные средства, эксплуатационная среда, в которой ПО работает и взаимодействует) [141]. К производителям относятся — кто-либо связанный с разработкой, управлением, маркетингом и обслуживанием программных продуктов. Таким образом, качество тесно связано с ожиданиями на стороне потребителя и на стороне производителя. На основе выполненного анализа выделим свойства понятия «качество». 1. Качество зависит от точки зрения группы людей, связанных с разработкой и эксплуатацией программных средств. Можно выделить две большие группы - производители и потребители ПС. 2. Качество ПС, это не только программное обеспечение, но также и связанные с ним продукты и услуги (документация, сопровождение, консультации). 3. Помимо качества продукта, необходимо говорить о качестве процесса его создания. 4. Качество необходимо рассматривать в динамике, в процессе использования продукта, при взаимодействии его с окружающей средой и различными системами и людьми. 5. Качество может быть управляемо через измерение его характеристик и выработку на основании полученных данных управляющего воздействия.
Распределение современных стандартов программной инженерии по «кубу качества»
Для дальнейшего уточнения ролей в «кубе качества», рассмотрим локальные поля качества, входящие в куб в зависимости от «взгляда на качество». В этом контексте локальное поле качества - аспекты качества, выраженные в системе координат «Сущность качества - степень детализации» для одной роли участника ЖЦПС. Предположим, что для различных ролей по объективным причинам не все узлы (элементы качества) на поле качества будут заполнены. Исследуем заполнение локальных полей качества для различных ролей участников ЖЦГТС. Если рассматриваемый аспект качества характерен для данной роли, то точка на локальном поле «качества» показана на рисунке черным цветом, если не характерен - то точка отсутствует. Если точка обозначена на схеме белым цветом, то соответствующий элемент качества может присутствовать или отсутствовать в зависимости от условий. Выполним анализ по сущностям качества продукт, технический процесс, управление проектом. Целью предварительного анализа локальных «полей качества» является установить наличие или отсутствия элементов качества, без точного соотнесения с конкретными концепциями и стандартами.
Продукт.Заказчик должен владеть терминами в области качества программного обеспечения, знать и применять стандарты, связанные с качеством ПО (особенно стандарты, связанные с внешним качеством и качеством в использовании). Для определения характеристик качества заказчик использует набор характеристик из стандарта ISO/IEC 9126-1, 2, 4 [124,125, 127], а также характеристики, которые содержатся в отраслевых стандартах предметной области. В частности, заказчики банковского программного обеспечения, должны принимать во внимание характеристики качества программного обеспечения, которые содержатся в стандарте СТО БР ИББС-1.0-2006 «Стандарт банка России. Обеспечение информационной безопасности организаций банковской системы Российской Федерации» [76] и в ряде других документов. В зависимости от отрасли различные характеристики качества могут иметь различный вес. Так, например, для автоматизированных банковских систем важны такие характеристики как функциональность, надежность, масштабируемость. Обычно вопрос важности той или иной характеристики качества программного продукта для конкретной отрасли может решаться путем опроса экспертов. Метрики для определения характеристик качества, важных для заказчика, определяются на основании стандарта ISO/IEC 9126-2, 4.
Технический процесс. Основной процесс для заказчика - процесс заказа, описанный в стандарте ISO/IEC 12207. Для выбора надежного разработчика и поставщика заказчик должен разбираться в большинстве процессов разработки программного обеспечения, знать характеристики качества этих процессов и уметь их определять. В области технических процессов заказчик также может использоваться стандарт ISO/1EC 15504 [120], в котором описана собственная модель процессов ЖЦПС, не идентичная модели, описанной в стандарте ISOAEC 12207. Для контроля за процессами заказа и поставки, заказчику необходимы характеристики и метрики этих процессов.
Управление проектом. Согласно стандарту ISO/IEC 12207 процесс заказа управляется на проектной основе. Заказчик должен знать терминологию в области управления проектами, т.к. он является одной из сторон, участвующих в проекте. Некоторые характеристики проекта (такие как, точность сроков завершения проекта или его отдельных этапов, точность исполнения бюджета) также важны для заказчика. Соответственно, необходима методика для определения характеристик качества управления проектом с точки зрения заказчика. Для управления проектами используется стандарт ANSI/PMI 99-001-2004, а также стандарт ISOAEC 16326. Графическая интерпретация заполнения поля качества заказчика представлена ниже (См. рис. 3.3.).
Продукт. Пользователь должен владеть терминами в области качества программного обеспечения, знать и применять стандарты, связанные с качеством ПО (особенно стандарты, связанные с внешним качеством и качеством в использовании). Для определения характеристик качества пользователь применяет набор характеристик из стандарта ISO/IEC 9126-1, 2, 4, а также те характеристики, которые содержатся в отраслевых стандартах предметной области. Метрики для определения важных для пользователя характеристик качества определяются на основании стандарта ISO/IEC 9126-2, 4. Набор характеристик качества и метрик для их определения для пользователя отличается от аналогичного набора для заказчика.
Технический процесс. Основным процессом для пользователя является процесс эксплуатации (согласно стандарту ISOAEC 12207). При разработке ПС пользователь может привлекаться разработчиком при формировании требований, при проведении аттестации программного обеспечения и различных приемочных испытаний. При эксплуатации ему приходится сталкиваться с сопровождающей организацией. Основными характеристиками, важными для пользователя в этом аспекте, являются режим сопровождения, скорость реакции сопровождающей организации на возникающие у пользователя проблемы, быстрота доработок. Пользователю необходимо владеть метриками для определения этих характеристик. В области технических процессов также используется стандарт ISO/TEC 15504, в котором содержатся основные характеристики процесса эксплуатации. Управление проектом. Привлечение конечного пользователя к разработке и поставке информационных систем является одним из ключевых факторов создания и поставки качественного продукта, поэтому в области управления проектом пользователь должен знать терминологию для облегчения общения с менеджерами проекта и отстаивания своих интересов. С точки зрения пользователя важной характеристикой проекта является точность соблюдения сроков окончания проекта и начала эксплуатации. Поэтому необходимы метрики для определения этих характеристик. В соответствии с ISO/IEC 12207 процесс эксплуатации также управляется с применением проектной организации работ, хотя автор допускает процессный режим эксплуатации ПС. Графическая интерпретация заполнения поля качества пользователя представлена ниже (рис. 3.4.).
Адаптация комплексной многомерной модели качества для области разработки и эксплуатации АБС
Основополагающим в области разработки и эксплуатации программных средств и информационных технологий является международный стандарт «ISO 12207: 1995. ИТ. Процессы жизненного цикла программных средств». Идеологически стандарт связан со стандартом ISO/IEC 15288:2002 «Системное проектирование. Процессы жизненного цикла системы», так как программное средство обычно является подсистемой другой системы. Стандарт определяет процессы, используемые в ЖЦПС. Согласно ему выделяют: основные процессы жизненного цикла, вспомогательные процессы, организационные процессы. В стандарте выделено 5 основных процессов (по количеству ролей участников жизненного цикла программных средств): заказ (5.1); поставка (5.2); разработка (5.3); эксплуатация (5.4); сопровождение (5.5). Вспомогательный процесс . инициируется и используется другим процессом. К вспомогательным процессам относят процессы: документирование (6.1); управление конфигурацией (6.2); обеспечение качества (6.3); верификация (6.4); аттестация (6.5); совместный анализ (6.6); аудит (6.7) ; решение проблем (6.8). Организационные процессы применяются для создания и реализации основной структуры, охватывающей взаимосвязанные процессы жизненного цикла и персонал, а также для постоянного совершенствования организационной структуры и процессов. Обычно организационные процессы являются типовыми, независимо от области реализации конкретных проектов и исполнения условия договоров. К организационным процессам жизненного цикла относят процессы: управления (7.1); создания инфраструктуры (7.2); усовершенствование (7.3); обучение (7.4). Помимо прочего, стандарт содержит (в приложении А, В) описание процесса адаптации стандарта к условиям реальных проектов разработки программного обеспечения. Каждый процесс стандарта должен быть определен в терминах составляющих его работ, каждая из которых должна быть определена в терминах составляющих ее задач. Работа в процессе состоит из набора связанных задач. В таблице 3.4. представлено распределение работ и задач в разрезе по классам процессов.
Стандарт определяет область технических процессов, в нем содержатся основные определения из данной области, но он не содержит требования к характеристикам процессов жизненного цикла программных средств и метрик для их определения. Технологический процесс разработки программных средств отличается большим разнообразием и зависит от многих факторов (модель жизненного цикла, тип разрабатываемого ПС, организационная структура компании разработчика, вид продута, предметная область и пр.). Стандарт ISO/IEC 12207 определяет лишь перечень процессов разработки и их возможную взаимосвязь. Необходимым условием применением стандарта является его адаптация к конкретным условиям разработки. Рекомендации по доработке содержит как сам стандарт ISOAEC 12207, так и стандарт ISO/IEC 15271 «ИТ. Руководство по применению ISO/IEC 12207 (Процессы жизненного цикла программных средств)» [22]. Пользователь стандарта ISO/IEC 12207 должен выбрать, практически применить и скомпоновать данные блоки соответственно целям своей организации и проекта. При его применении должны быть сохранены его архитектура, сущность и целостность, например, с включением элементов стандарта с пометкой «не применяется» и объяснением причины. Предпочтительнее начинать с процессов, от которых может быть получена максимальная отдача, а не выполнять внедрение всего ISO/IEC 12207. Согласно ISO/IEC 12207 на адаптацию влияют следующие условия выполнения проекта: модель жизненного цикла; влияние жизненного цикла существующей системы; требования к системе и программным средствам; организационные цели, процедуры; условия выполнения проекта; размер, критичность и типы системы, программного продукта или услуги; количество задействованного персонала и участвующих в проекте сторон. Ключевым моментом использования ISO/IEC 12207 является адаптация процессов связанных с качеством, проведенная до начала реализации проекта, а также распределение ролей данных конкретных процессов, реализуемых в проекте. Стандарт формулирует эту важную задачу в виде подготовки плана обеспечения качества, подкрепленного, при необходимости, другими связанными с ним планами, такими как планы верификации и аттестации. Стандарт ISCVIEC 15271 устанавливает рекомендации по оценке продуктов, услуг и процессов [22]. Стандарт ISO/IEC 15271 содержит разъяснения по применению каждого процесса ЖЦПС, также для каждого процесса представлены типы выходных результатов. В стандарте (таблица В.1) содержатся возможные результаты основных процессов жизненного цикла, выходные результаты вспомогательных, организационных процессов и процесса адаптации содержатся в таблицах В.2-В.4 стандарта. На основе рекомендаций, содержащихся в стандарте ISO/IEC 15271 можно сформировать недостающие характеристики и отсутствующие метрики для определения этих характеристик. В качестве характеристик могут быть разработаны метрики длительности процесса, его результативности и эффективности. В качестве характеристик входов и выходов процессов (промежуточных продуктов) могут выступать объем программного кода, объем спецификаций и документации разработки, тестовых кейсов, объем документации пользователя, объем отслеживаемых функциональных требований и пр.
