2.2 Связь программной инженерии с другими сферами науки
advertisement
Программная инженерия
Чем программирование отличается от программной инженерии? Тем, что первое является
некоторой абстрактной деятельностью и может происходить во многих различных
контекстах. Можно программировать для удовольствия, для того, чтобы научиться
(например, на уроках, на семинарах в университете), можно программировать в рамках
научных разработок. А можно заниматься промышленным программированием. Как
правило, это происходит в команде, и совершенно точно – для заказчика, который платит
за работу деньги. При этом необходимо точно понимать, что нужно заказчику, выполнить
работу в определенные сроки и результат должен быть нужного качества – того, которое
удовлетворит заказчика и за которое он заплатит. Чтобы удовлетворить этим
дополнительным требованиям, программирование "обрастает" различными
дополнительными видами деятельности: разработкой требований, планированием,
тестированием, конфигурационным управлением, проектным менеджментом, созданием
различной документации (проектной, пользовательской и пр.).
Разработка программного кода предваряется анализом и проектированием (первое означает
создание функциональной модели будущей системы без учета реализации, для осознания
программистами требований и ожиданий заказчика; второе означает предварительный
макет, эскиз, план системы на бумаге). Трудозатраты на анализ и проектирование, а также
форма представления их результатов сильно варьируются от видов проектов и
предпочтений разработчиков и заказчиков.
Требуются также специальные усилия по организации процесса разработки. В общем виде
это итеративно-инкрементальная модель, когда требуемая функциональность создается
порциями, которые менеджеры и заказчик могут оценить, и тем самым есть возможность
управления ходом разработки. Однако эта общая модель имеет множество модификаций и
вариантов.
Разработку системы также необходимо выполнять с учетом удобств ее дальнейшего
сопровождения, повторного использования и интеграции с другими системами. Это значит,
что система разбивается на компоненты, удобные в разработке, годные для повторного
использования и интеграции. А также имеющие необходимые характеристики по
быстродействию. Для этих компонент тщательно прорабатываются интерфейсы. Сама же
система документируется на многих уровнях, создаются правила оформления
программного кода – то есть оставляются многочисленные семантические следы,
помогающие создать и сохранить, поддерживать единую, стройную архитектуру,
единообразный стиль, порядок…
Все эти и другие дополнительные виды деятельности, выполняемые в процессе
промышленного программирования и необходимые для успешного выполнения заказов и
будем называть программной инженерией (software engineering)1). Получается, что так
мы обозначаем, во-первых, некоторую практическую деятельность, а во-вторых,
специальную область знания. Или другими словами, научную дисциплину. Ведь для
облегчения выполнения каждого отдельного проекта, для возможности использовать
разнообразный положительный опыт, достигнутый другими командами и разработчиками,
этот самый опыт подвергается осмыслению, обобщению и надлежащему оформлению. Так
появляются различные методы и практики (best practices) – тестирования, проектирования,
работы над требованиями и пр., архитектурных шаблонов и пр. А также стандарты и
методологии, касающиеся всего процесса в целом (например, MSF, RUP, CMMI, Scrum).
Вот эти-то обобщения и входят в программную инженерию как в область знания.
Необходимость в программной инженерии как в специальной области знаний была
осознана мировым сообществом в конце 60-х годов прошлого века, более чем на 20 лет
позже рождения самого программирования, если считать таковым знаменитый отчет фон
Неймана "First Draft of a Report on the EDVAC", обнародованный им в 1945 году.
Рождением программной инженерии является 1968 год – конференция NATO Software
Engineering, г. Гармиш (ФРГ), которая целиком была посвящена рассмотрению этих
вопросов. В сферу программной инженерии попадают все вопросы и темы, связанные с
организацией и улучшением процесса разработки ПО, управлением коллективом
разработчиков, разработкой и внедрением программных средств поддержки жизненного
цикла разработки ПО. Программная инженерия использует достижения информатики,
тесно связана с системотехникой, часто предваряется бизнес-реинжинирингом. Немного
подробнее об этом контексте программной инженерии.
Информатика (computer science) – это свод теоретических наук, основанных на
математике и посвященных формальным основам вычислимости. Сюда относят
математическую логику, теорию грамматик, методы построения компиляторов,
математические формальные методы, используемые в верификации и модельном
тестировании и т.д. Трудно строго отделить программную инженерию от информатики, но
в целом направленность этих дисциплин различна. Программная инженерия нацелена на
решение проблем производства, информатика – на разработку формальных,
математизированных подходов к программированию.
Системотехника (system engineering) объединяет различные инженерные дисциплины по
разработке всевозможных искусственных систем – энергоустановок,
телекоммуникационных систем, встроенных систем реального времени и т.д. Очень часто
ПО оказывается частью таких систем, выполняя задачу управления соответствующего
оборудования. Такие системы называются программно-аппаратными, и участвуя в их
создании, программисты вынуждены глубоко разбираться в особенностях
соответствующей аппаратуры.
Бизнес-реинжиниринг (business reengineering) – в широком смысле обозначает
модернизацию бизнеса в определенной компании, внедрение новых практик,
поддерживаемых соответствующими, новыми информационными системами. При этом
акцент может быть как на внутреннем переустройстве компании так и на разработке нового
клиентского сервиса (как правило, эти вопросы взаимосвязаны). Бизнес-реинжиниринг
часто предваряет разработку и внедрение информационных систем на предприятии, так как
требуется сначала навести определенный порядок в делопроизводстве, а лишь потом
закрепить его информационной системой.
Связь программной инженерии (как области практической деятельности) с информатикой,
системотехникой и бизнес-реинжинирингом показана на рис. 1.1.
Программное обеспечение
Определение. Будем понимать под программным обеспечением (ПО) множество
развивающихся во времени логических предписаний, с помощью которых некоторый
коллектив людей управляет и использует многопроцессорную и распределенную систему
вычислительных устройств.
Это определение, данное Харальдом Милсом, известным специалистом в области
программной инженерии из компании IBM, заключает в себе следующее.
1. Логические предписания – это не только сами программы, но и различная
документация (например, по эксплуатации программ) и шире – определенная
система отношений между людьми, использующими эти программы в рамках
некоторого процесса деятельности.
2. Современное ПО предназначено, как правило, для одновременной работы со
многими пользователями, которые могут быть значительно удалены друг от друга в
физическом пространстве. Таким образом, вычислительная среда (персональные
компьютеры, сервера и т.д.), в которой ПО функционирует, оказывается
распределенной.
3. Задачи решаемые современным ПО, часто требуют различных вычислительных
ресурсов в силу различной специализации этих задач, из-за большого объема
выполняемой работы, а также из соображений безопасности. Например, появляется
сервер базы данных, сервер приложений и пр. Таким образом, вычислительная
среда, в которой ПО функционирует, оказывается многопроцессорной.
4. ПО развивается во времени – исправляются ошибки, добавляются новые функции,
выпускаются новые версии, меняется его аппаратная база.
Свойства. Таким образом, ПО является сложной динамической системой, включающей в
себя технические, психологические и социальные аспекты. ПО заметно отличается от
других видов систем, создаваемых (созданных) человеком – механических, социальных,
научных и пр., и имеет следующие особенности, выделенные Фредериком Бруксом в его
знаменитой статье "Серебряной пули нет".
1. Сложность программных объектов, которая существенно зависит от их размеров.
Как правило, большее ПО (большее количество пользователей, больший объем
обрабатываемых данных, более жесткие требования по быстродействию и пр.) с
аналогичной функциональностью – это другое ПО. Классическая наука строила
простые модели сложных явлений, и это удавалось, так как сложность не была
характеристической чертой рассматриваемых явлений. (Сравнение
программирования именно с наукой, а не с театром, кинематографом, спортом и
другими областями человеческой деятельности, оправдано, поскольку оно возникло,
главным образом, из математики, а первые его плоды – программы –
предназначались для использования при научных расчетах. Кроме того,
большинство программистов имеют естественнонаучное, математическое или
техническое образование. Таким образом, парадигмы научного мышления широко
используются при программировании – явно или неявно.)
2. Согласованность – ПО основывается не на объективных посылках (подобно тому,
как различные системы в классической науке основываются на постулатах и
аксиомах), а должно быть согласовано с большим количеством интерфейсов, с
которыми впоследствии оно должно взаимодействовать. Эти интерфейсы плохо
поддаются стандартизации, поскольку основываются на многочисленных и плохо
формализуемых человеческих соглашениях.
3. Изменяемость – ПО легко изменить и, как следствие, требования к нему постоянно
меняются в процессе разработки. Это создает много дополнительных трудностей
при его разработке и эволюции.
4. Нематериальность2) – ПО невозможно увидеть, оно виртуально. Поэтому,
например, трудно воспользоваться технологиями, основанными на предварительном
создании чертежей, успешно используемыми в других промышленных областях
(например, в строительстве, машиностроении). Там на чертежах в схематичном виде
воспроизводятся геометрические формы создаваемых объектов. Когда объект
создан, эти формы можно увидеть. А на чем мы основываемся, когда изображаем
ПО?
1.1 2. Лекция: Процесс разработки программного обеспечения
Понятие процесса разработки ПО. Универсальный процесс. Текущий процесс. Конкретный
процесс. Стандартный процесс. Совершенствование процесса. Pull/Push стратегии.
Классические модели процесса: водопадная модель, спиральная модель. Фазы и виды
деятельности.
Без процесса не понять….
Из деловой переписки менеджера программного проекта
1.1.1 [править] Процесс
Как мы работаем, какова последовательность наших шагов, каковы нормы и правила в
поведении и работе, каков регламент отношений между членами команды, как проект
взаимодействует с внешним миром и т.д.? Все это вместе мы склонны называть процессом.
Его осознание, выстраивание и улучшение - основа любой эффективной групповой
деятельности. Поэтому не случайно, что процесс оказался одним из основных понятий
программной инженерии.
Центральным объектом изучения программной инженерии является процесс создания ПО
– множество различных видов деятельности, методов, методик и шагов, используемых для
разработки и эволюции ПО и связанных с ним продуктов (проектных планов,
документации, программного кода, тестов, пользовательской документации и пр.).
Однако на сегодняшний день не существует универсального процесса разработки ПО –
набора методик, правил и предписаний, подходящих для ПО любого вида, для любых
компаний, для команд любой национальности. Каждый текущий процесс разработки,
осуществляемый некоторой командой в рамках определенного проекта, имеет большое
количество особенностей и индивидуальностей. Однако целесообразно перед началом
проекта спланировать процесс работы, определив роли и обязанности в команде, рабочие
продукты (промежуточные и финальные), порядок участия в их разработке членов
команды и т.д. Будем называть это предварительное описание конкретным процессом,
отличая его от плана работ, проектных спецификаций и пр. Например, в системе Microsoft
Visual Team System оказывается шаблон процесса, создаваемый или адаптируемый (в
случае использования стандартного) перед началом разработки. В VSTS существуют
заготовки для конкретных процессов на базе CMMI, Scrum и др.
В рамках компании возможна и полезна стандартизация всех текущих процессов, которую
будем называть стандартным процессом. Последний, таким образом, оказывается
некоторой базой данных, содержащей следующее:
информацию, правила использования, документацию и
инсталляционные пакеты средств разработки, используемых в проектах
компании (систем версионного контроля, средств контроля ошибок,
средств программирования – различных IDE, СУБД и т.д.);
описание практик разработки – проектного менеджмента, правил
работы с заказчиком и т.д.;
шаблоны проектных документов – технических заданий, проектных
спецификаций, планов тестирования и т.д. и пр.
Также возможна стандартизация процедуры разработки конкретного процесса как
"вырезки" из стандартного. Основная идея стандартного процесса – курсирование внутри
компании передового опыта, а также унификация средств разработки. Очень уж часто в
компаниях различные департаменты и проекты сильно отличаются по зрелости процесса
разработки, а также затруднено повторное использование передового опыта. Кроме того,
случается, что компания использует несколько средств параллельных инструментов
разработки, например, СУБД средства версионного контроля. Иногда это бывает оправдано
(например, таковы требования заказчика), часто это необходимо – например, Java, .NET
(большая компетентность оффшорной компании позволяет ей брать более широкий спектр
заказов). Но очень часто это произвольный выбор самих разработчиков. В любом случае,
такая множественность существенно затрудняет миграцию специалистов из проекта в
проект, использование результатов одного проекта в другом и т.д. Однако при организации
стандартного процесса необходимо следить, чтобы стандартный процесс не оказался всего
лишь формальным, бюрократическим аппаратом. Понятие стандартного процесса введено
и подробно описано в подходе CMMI.
Необходимо отметить, что наличие стандартного процесса свидетельствует о наличии
"единой воли" в организации, существующей именно на уровне процесса. На уровне
продаж, бухгалтерии и др. привычных для всех компаний процессов и активов единство
осуществить не трудно. А вот на уровне процессов разработки очень часто каждый проект
оказывается сам по себе (особенно в оффшорных проектах) – "текучка" захватывает и
изолирует проекты друг от друга очень прочно.
1.1.2 [править] Совершенствование процесса
Определение. Совершенствование процесса (software process improvement) – это
деятельность по изменению существующего процесса (как текущего, в рамках одного
проекта, так и стандартного, для всей компании) с целью улучшения качества создаваемых
продуктов и/или снижения цены и времени их разработки. Причины актуальности этой
деятельности для компаний-производителей ПО заключается в следующем.
1. Происходит быстрая смена технологий разработки ПО, требуются
изучение и внедрение новых средcтв разработки.
2. Наблюдается быстрый рост компаний и их выход на новые рынки, что
требует новой организации работ.
3. Имеет место высокая конкуренция, которая требует поиска более
эффективных, более экономичных способов разработки.
Что и каким образом можно улучшать.
1. Переход на новые средства разработки, языки программирования и т.д.
2. Улучшение отдельных управленческих и инженерных практик –
тестирования, управления требованиями и пр.
3. Полная, комплексная перестройка всех процессов в проекте,
департаменте, компании (в соответствии, например, с CMMI).
4. Сертификация компании (CMM/CMMI, ISO 9000 и пр.).
Мы отделили п. 3 от п. 4 потому, что на практике 4 далеко не всегда означает
действительную созидательную работу по улучшению процессов разработки ПО, а часто
сводится к поддержанию соответствующего документооборота, необходимого для
получения сертификации. Сертификат потом используется как средство, козырь в борьбе за
заказы.
Главная трудность реального совершенствования процессов в компании заключается в том,
что она при этом должна работать и создавать ПО, ее нельзя "закрыть на учет".
Отсюда вытекает идея непрерывного улучшения процесса, так сказать, малыми порциями,
чтобы не так болезненно. Это тем более разумно, что новые технологии разработки,
появляющиеся на рынке, а также развитие уже существующих нужно постоянно
отслеживать. Эта стратегия, в частности, отражена в стандарте совершенcтвования
процессов разработки CMMI.
Pull/Push стратегии. В контексте внедрения инноваций в производственные процессы
бизнес-компаний (не обязательно компаний по созданию ПО) существуют две следующие
парадигмы.
1. Organization pull – инновации нацелены на решение конкретных
проблем компании.
2. Technology push – широкомасштабное внедрение инноваций из
стратегических соображений. Вместо конкретных проблем, которые
будут решены после внедрения инновации, в этом случае
рассматриваются показатели компании (эффективность,
производительность, годовой оборот средств, увеличение стоимости
акций публичной компании), которые будут увеличены, улучшены
после внедрения инновации. При этом предполагается, что будут
автоматически решены многочисленные частные проблемы
организации, в том числе и те, о которых в данный момент ничего не
известно.
Пример использования стратегии organization pull – внедрение новых средств тестирования
в ситуации, когда высоки требования по качеству в проекте, либо когда качество
программной системы не удовлетворяет заказчика.
Пример использования стратегии technology push – переход компании со средств
структурной разработки на объектно-ориентрованные. Еще один пример использования
той же стратегии – внедрение стандартов качества ISO 9000 или CMMI. В обоих этих
случая компания не решает какую-то одну проблему или ряд проблем – она хочет
радикально изменить ситуацию, выйти на новые рубежи и т.д.
Проблемы применения стратегии technology push в том, что требуется глобальная
перестройка процесса. Но компанию нельзя "закрыть на реконструкцию" – за это время
положение на рынке может оказаться занято конкурентами, акции компании могут упасть
и т.д. Таким образом, внедрение инноваций, как правило, происходит параллельно с
обычной деятельностью компании, поэтапно, что в случае с technology push сопряжено с
большими трудностями и рисками.
Использование стратегии organization pull менее рискованно, вносимые ею изменения в
процесс менее глобальны, более локальны. Но и выгод такие инновации приносят меньше,
по сравнению с удачными внедрениями в соответствии со стратегией technology push.
Необходимо также отметить, что существуют проблемы, которые невозможно устранить
точечными переделками процесса, то есть необходимо применять стратегию technology
push. Приведем в качестве примера зашедший в тупик процесс сопровождения и развития
семейства программных продуктов – компания терпит большие убытки, сопровождая уже
поставленные продукты, инструментальные средства проекта безнадежно устарели и
находятся в плачевном состоянии, менеджмент расстроен, все попытки руководства
изменить процесс наталкиваются на непонимание коллектива, ссоры и конфликты.
Возможно, что в таком случае без "революции" не обойтись.
Еще одно различие обеих стратегий: в случае с organization pull, как правило, возврат
инвестиций от внедрения происходит быстрее, чем в случае с technology push.
1.1.3 [править] Классические модели процесса
Определение модели процесса. Процесс создания программного обеспечения не является
однородным. Тот или иной метод разработки ПО, как правило, определяет некоторую
динамику развертывания тех или иных видов деятельности, то есть, определяет модель
процесса (process model).
Модель является хорошей абстракцией различных методов разработки ПО, позволяя
лаконично, сжато и информативно их представить. Однако, сама идея модели процесса
является одной из самых ранних в программной инженерии, когда считалось, что удачная
модель – самое главное, что способствует успеху разработки. Позднее пришло осознание,
что существует множество других аспектов (принципы управления и разработки,
структуру команды и т.д.), которые должны быть определены согласовано друг с другом. И
стали развиваться интегральные методологии разработки. Тем не менее существует
несколько классических моделей процесса, которые полезны на практике и которые будут
рассмотрены ниже.
Фазы и виды деятельности. Говоря о моделях процессов, необходимо различать фазы и
виды деятельности.
Фаза (phase) – это определенный этап процесса, имеющий начало, конец и выходной
результат. Например, фаза проверки осуществимости проекта, сдачи проекта и т.д. Фазы
следуют друг за другом в линейном порядке, характеризуются предоставлением
отчетности заказчику и, часто, выплатой денег за выполненную часть работы.
Редко какой заказчик согласится первый раз увидеть результаты только после завершения
проекта. С другой стороны, подрядчики предпочитают получать деньги постепенно, по
мере того, как выполняются отдельные части работы. Таким образом, появляются фазы,
позволяющие создавать и предъявлять промежуточные результаты проекта. Фазы полезны
также безотносительно взаимодействия с заказчиком – с их помощью можно
синхронизировать деятельность разных рабочих групп, а также отслеживать продвижение
проекта. Примерами фаз может служить согласование с заказчиком технического задания,
реализация определенной функциональности ПО, этап разработки, оканчивающийся
сдачей системы на тестирование или выпуском альфа-версии.
Вид деятельности (activity) – это определенный тип работы, выполняемый в процессе
разработки ПО. Разные виды деятельности часто требуют разные профессиональные
навыки и выполняются разными специалистами. Например, управление проектом
выполняется менеджером проекта, кодирование – программистом, тестирование –
тестировщиком. Есть виды деятельности, которые могут выполняться одними и теми же
специалистами – например, кодирование и проектирование (особенно в небольшом
проекте) часто выполняют одни и те же люди.
В рамках одной фазы может выполнятся много различных видов деятельности. Кроме того,
один вид деятельности может выполняться на разных фазах – например, тестирование: на
фазе анализа и проектирования можно писать тесты и налаживать тестовое окружение, при
разработке и перед сдачей производить, собственно, само тестирование. На настоящий
момент для сложного программного обеспечения используются многомерные модели
процесса, в которых отделение фаз от видов деятельности существенно облегчает
управление разработкой ПО.
Виды деятельности, фактически, присутствуют, под разными названиями, в каждом
методе разработки ПО. В RUP они называются рабочими процессами (work flow), в CMM –
ключевыми областями процесса (key process area). Мы будем сохранять традиционные
названия, принятые в том или ином методе, чтобы не создавать путаницы.
Водопадная модель была предложена в 1970 году Винстоном Ройсом. Фактически, впервые
в процессе разработки ПО были выделены различные шаги разработки и поколеблены
примитивные представления о разработке ПО в виде анализа системы и ее кодирования.
Были определены следующие шаги: разработка системных требований, разработка
требований к ПО, анализ, проектирование, кодирование, тестирование, использование – см.
рис. 2.1.
Достоинством этой модели явилось ограничение возможности возвратов на произвольный
шаг назад, например, от тестирования – к анализу, от разработки – к работе над
требованиями и т.д. Отмечалось, что такие возвраты могут катастрофически увеличить
стоимость проекта и сроки его выполнения. Например, если при тестировании
обнаруживаются ошибки проектирования или анализа, то их исправление часто приводит к
полной переделке системы. Этой моделью допускались возвраты только на предыдущий
шаг, например, от тестирования к кодированию, от кодирования к проектированию и т.д.
Наконец, в рамках этой модели было введено прототипирование, то есть предлагалось
разрабатывать систему дважды, чтобы уменьшить риски разработки. Первая версия –
прототип – позволяет увидеть основные риски и обосновано принять главные
архитектурные решения. На создание прототипа отводилось до одной трети времени всей
разработки.
В 70-80 годах прошлого века эта модель прочно укоренилась в разработке ПО в силу своей
простоты и сходности с моделями разработки иных, не программных систем. В
дальнейшем, в связи с развитием программной инженерии и осознанием итеративного
характера процесса разработки ПО эта модель активно критиковалась, практически,
каждым автором соответствующих статей и учебников. Стало общепринятым мнение, что
она не отражает особенностей разработки ПО. Недостатками водопадной модели являются:
отождествление фаз и видов деятельности, что влечет потерю гибкости
разработки, в частности, трудности поддержки итеративного процесса
разработки;
требование полного окончания фазы-деятельности, закрепление
результатов в виде подробного исходного документа (технического
задания, проектной спецификации); однако опыт разработки ПО
показывает, что невозможно полностью завершить разработку
требований, дизайн системы и т.д. – все это подвержено изменениям; и
причины тут не только в том, что подвижно окружение проекта, но и в
том, что заранее не удается точно определить и сформулировать многие
решения, они проясняются и уточняются лишь впоследствии;
интеграция всех результатов разработки происходит в конце, вследствие
чего интеграционные проблемы дают о себе знать слишком поздно;
пользователи и заказчик не могут ознакомиться с вариантами системы
во время разработки, и видят результат только в самом конце; тем
самым, они не могут повлиять на процесс создания системы, и поэтому
увеличиваются риски непонимания между разработчиками и
пользователями/заказчиком;
модель неустойчива к сбоям в финансировании проекта или
перераспределению денежных средств, начатая разработка, фактически,
не имеет альтернатив "по ходу дела".
Однако данная модель продолжает использоваться на практике – для небольших проектов
или при разработке типовых систем, где итеративность не так востребована. С ее помощью
удобно отслеживать разработку и осуществлять поэтапный контроль за проектом. Эта
модель также часто используется в оффшорных проектах1) с почасовой оплатой труда.
Водопадная модель вошла в качестве составной части в другие модели и методологии,
например, в MSF.
Спиральная модель была предложена Бэри Боемом в 1988 году для преодоления
недостатков водопадной модели, прежде всего, для лучшего управления рисками. Согласно
этой модели разработка продукта осуществляется по спирали, каждый виток которой
является определенной фазой разработки. В отличие от водопадной модели в спиральной
нет предопределенного и обязательного набора витков, каждый виток может стать
последним при разработке системы, при его завершении составляются планы следующего
витка. Наконец, виток является именно фазой, а не видом деятельности, как в водопадной
модели, в его рамках может осуществляться много различных видов деятельности, то есть
модель является двумерной.
Последовательность витков может быть такой: на первом витке принимается решение о
целесообразности создания ПО, на следующем определяются системные требования, потом
осуществляется проектирование системы и т.д. Витки могут иметь и иные значения.
Каждый виток имеет следующую структуру (секторы):
определение целей, ограничений и альтернатив проекта;
оценка альтернатив, оценка и разрешение рисков; возможно
использование прототипирования (в том числе создание серии
прототипов), симуляция системы, визуальное моделирование и анализ
спецификаций; фокусировка на самых рисковых частях проекта;
разработка и тестирование – здесь возможна водопадная модель или
использование иных моделей и методов разработки ПО;
планирование следующих итераций – анализируются результаты, планы
и ресурсы на последующую разработку, принимается (или не
принимается) решение о новом витке; анализируется, имеет ли смысл
продолжать разрабатывать систему или нет; разработку можно и
приостановить, например, из-за сбоев в финансировании; спиральная
модель позволяет сделать это корректно.
Отдельная спираль может соответствовать разработке некоторой программной компоненты
или внесению очередных изменений в продукт. Таким образом, у модели может появиться
третье измерение.
Спиральную модель нецелесообразно применять в проектах с небольшой степенью риска, с
ограниченным бюджетом, для небольших проектов. Кроме того, отсутствие хороших
средств прототипирования может также сделать неудобным использование спиральной
модели.
Спиральная модель не нашла широкого применения в индустрии и важна, скорее в
историко-методологическом плане: она является первой итеративной моделью, имеет
красивую метафору – спираль, – и, подобно водопадной модели, использовалась в
дальнейшем при создании других моделей процесса и методологий разработки ПО.
1.2 [править] 3. Рабочий продукт, дисциплина обязательств, проект
Рабочий продукт. Дисциплина обязательств. Проект. Управление проектами.
В силу творческого характера программирования, существенной молодости участников
разработки ПО, оказываются актуальными некоторые вопросы обычного промышленного
производства, ставшие давно общим местом. Прежде всего, это дисциплина обязательств и
рабочий продукт. Данные знания, будучи освоенными на практике, чрезвычайно полезны в
командной работе. Кроме того, широко применяемые сейчас на практике методологии
разработки ПО, поддержанные соответствующим программным инструментарием, активно
используют эти понятия, уточняя и конкретизируя их.
1.2.1 [править] Рабочий продукт
Одним из существенных условий для управляемости промышленного процесса является
наличие отдельно оформленных результатов работы – как в окончательной поставке так и
промежуточных. Эти отдельные результаты в составе общих результатов работ помогают
идентифицировать, планировать и оценивать различные части результата Промежуточные
результаты помогают менеджерам разных уровней отслеживать процесс воплощения
проекта, заказчик получает возможность ознакомиться с результатами задолго до
окончания проекта. Более того, сами участники проекта в своей ежедневной работе
получают простой и эффективный способ обмена рабочей информацией – обмен
результатами.
Таким результатом является рабочий продукт (work product) – любой артефакт,
произведенный в процессе разработки ПО, например, файл или набор файлов, документы,
составные части продукта, сервисы, процессы, спецификации, счета и т.д.
Рис. 3.1.
Ключевая разница между рабочим продуктом и компонентой ПО заключается в том, что
первый необязательно материален и осязаем (not to be engineered), хотя может быть
таковым. Нематериальный рабочий продукт – это, как правило, некоторый налаженный
процесс – промышленный процесс производства какой-либо продукции, учебный процесс в
университете (на факультете, на кафедре) и т.д.
Важно отметить, что рабочий продукт совсем не обязательно является составной частью
итоговой поставки. Например, налаженный процесс тестирования системы не поставляется
заказчику вместе с самой системой. Умение управлять проектами (не только в области
программирования) во многом связано с искусством определять нужные рабочие
продукты, настаивать на их создании и в их терминах вести приемку промежуточных
этапов работы, организовывать синхронизацию различных рабочих групп и отдельных
специалистов.
Многие методологии включают в себя описание специфичных рабочих продуктов,
используемых в процессе – CMMI, MSF, RUP и др. Например, в MSF это программный
код, диаграммы приложений и классов (application diagrams и class diagrams), план
итераций (iteration plan), модульный тест (unit test) и др. Для каждого из них точно описано
содержание, ответственные за разработку, место в процессе и др. аспекты.
Остановимся чуть детальнее на промежуточных рабочих продуктах. Компонента ПО,
созданная в проекте одним разработчиком и предоставленная для использования другому
разработчику, оказывается рабочим продуктом. Ее надо минимально протестрировать,
поправить имена интерфейсных классов и методов, быть может, убрать лишнее, не
имеющее отношение к функциональности данной компоненты, разделить public и private, и
т.д. То есть проделать некоторую дополнительную работу, которую, быть может,
разработчик и не стал делать, если бы продолжал использовать компоненту только сам.
Объем этих дополнительных работ существенно возрастает, если компонента должна быть
представлена для использования в разработке, например, в другой центр разработки
(например, иностранным партнерам, что является частой ситуацией в оффшорной
разработке). Итак, изготовление хороших промежуточных рабочих продуктов очень важно
для успешности проекта, но требует дополнительной работы от их авторов. Работать
одному, не предоставляя рабочих продуктов – легче и для многих предпочтительнее. Но
работа в команде требует накладных издержек, в том числе и в виде трат на создание
промежуточных рабочих продуктов. Конечно, качество этих продуктов и трудозатраты на
их изготовление сильно варьируются в зависимости от ситуации, но тут важно понимать
сам принцип.
Итак, подытожим, что промежуточный рабочий продукт должен обязательно иметь ясную
цель и конкретных пользователей, чтобы минимизировать накладные расходы на его
создание.
Рис. 3.2.
1.2.2 [править] Дисциплина обязательств
В
основе
разделения
обязанностей
в
бизнесе
и
промышленном
производстве,
корпоративных правил и норм лежит определенная деловая этика, форма отношений –
дисциплина обязательств. Она широко используется на практике и является одной из
возможных форм социального взаимоотношения между людьми. Привнесение в бизнес и
промышленность иных моделей человеческих отношений – семейных, сексуальных,
дружеских и т.д. часто наносит делам серьезный урон, порождает конфликтность,
понижает эффективность.
Основой этой формы отношений являются обязательства, которые:
даются добровольно;
не даются легко – работа, ресурсы, расписание должны быть тщательно
учтены;
между сторонами включает в себя то, что будет сделано, кем и в какие
сроки;
открыто и публично сформулированы (то есть это не "тайное знание").
Кроме того:
ответственная сторона стремится выполнить обязательства, даже если
нужна помощь;
до наступления deadline, как только становится очевидно, что работа не
может быть закончена в срок, обсуждаются новые обязательства.
Отметим, что дисциплина обязательств не является каким-то сводом правил, законов, она
отличается также от корпоративной культуры. Это – определенный групповой психический
феномен, существующий в обществе современных людей. Приведенные выше пункты не
являются исчерпывающим описанием этого феномена, но лишь проявляют и обозначают
его, так сказать, вызывают нужные воспоминания.
Дисциплина обязательств, несмотря на очевидность, порой, не просто реализуется на
практике, например, в творческих областях человеческой деятельности, в области обучения
и т.д. Существуют отдельные люди, которым эта дисциплина внутренне чужда вне
зависимости от их рода деятельности.
С другой стороны, люди, освоившие эту дисциплину, часто стремятся применять ее в
других областях жизни и человеческих отношений, что оказывается не всегда
оправданным. Подчеркнем, что данная дисциплина является далеко не единственной
моделью отношений между людьми. В качестве примера можно рассмотреть отношения в
семье или дружбу, что, с очевидностью, не могут быть выражены дисциплиной
обязательств. Так, вместо точности и пунктуальности в этих отношениях важно
эмоционально-чувственное сопереживание, без которого они невозможны.
Дисциплине обязательств уделяется много внимания в рамках MSF, поскольку там в
модели команды нет лидера, начальника. Эта дисциплина реализована также в Scrum:
Scrum-команда имеет много свобод, и в силу этого – большую ответственность.
Регламентируются также правила действий, когда обязательства не могут быть выполнены
такой командой.
1.2.3 [править] Проект
Классическое операционное разделение труда идет еще от Адама Смита и является сутью
массового индустриального производства. То есть существует четко налаженный процесс
работы и имеются области специализации – один цех точит, другой строгает, третий
собирает, четвертый красит и т.д. Пропускная способность такого производства намного
превосходит выполнение всей работы одним человеком или одной группой. Таким образом
в XIX веке операционное разделение труда стало основой мануфактур, вытеснивших
индивидуальное, ремесленное производство. В начале XX века эту структуру работ
перенесли и на управление – то есть многочисленные менеджеры контролировали
отдельные участки работ.
Однако высокий уровень сложности ряда задач в промышленности и бизнесе не позволяет
(к счастью!) так работать везде. Существует много творческих, новых задач, где, быть
может, в будущем и удастся создать конвейеры, но в данный момент для их решения
требуется существенная концентрация сил и энергии людей, неожиданные решения, а
также удача и легкая рука. Это и есть область проектов.
Проект – это уникальная (в отличии от традиционной пооперационного промышленного
производства) деятельность, имеющая начало и конец во времени, направленная на
достижение определённого результата/цель, создание определённого, уникального
продукта или услуги, при заданных ограничениях по ресурсам и срокам, а также
требованиям к качеству и допустимому уровню риска.
В частности, разработка программного обеспечения, является, преимущественно,
проектной областью.
Необходимо различать проекты промышленные и проекты творческие. У них разные
принципы управления. Сложность промышленных проектов – в большом количестве
разных организаций, компаний и относительной уникальности самих работ. Пример –
строительство многоэтажного дома. Сюда же относятся различные международные
проекты и не только промышленные – образовательные, культурные и пр. Задача в
управлении такими проектами – это все охватить, все проконтролировать, ничего не
забыть, все свести воедино, добиться движения, причем движения согласованного.
Творческие проекты характеризуются абсолютной новизной идеи – новый сервис,
абсолютно новый программный продукт, какого еще не было на рынке, проекты в области
искусства и науки. Любой начинающий бизнес, как правило, является таким вот
творческим проектом. Причем новизна в подобных проектах не только абсолютная –
такого еще не было. Такое, может, уже и было, но только не с нами, командой проекта. То
есть присутствует огромный объем относительной новизны для самих людей, которые
воплощают этот проект.
Проекты по разработке программного обеспечения находятся между двумя этими
полюсами, занимая в этом пространстве различное положение. Часто они сложны потому,
что объемны и находятся на стыке различных дисциплин – того целевого бизнеса, куда
должен встроиться программный продукт, и сложного, нетривиального программирования.
Часто сюда добавляется еще разработка уникального электронно-механического
оборудования. С другой стороны, поскольку программирование активно продвигается в
разные сферы человеческой деятельности, то происходит это путем создания абсолютно
новых, уникальных продуктов, и их разработка и продвижение обладают всеми чертами
творческих проектов.
Управление проектами (project management) – область деятельности, в ходе которой, в
рамках определенных проектов, определяются и достигаются четкие цели при нахождении
компромисса между объемом работ, ресурсами (такими как время, деньги, труд,
материалы, энергия, пространство и др.), временем, качеством и рисками.
Отметим несколько важных аспектов управления проектами.
Stakeholders – это люди со стороны, которые не участвуют
непосредственно в проекте, но влияют на него и или заинтересованы в
его результатах. Это могут быть будущие пользователи системы
(например, в ситуации, когда они и заказчик – это не одно и то же),
высшее руководство компании-разработчика и т.д. Идентификация всех
stakeholders и грамотная работа с ними – важная составляющая
успешного проектного менеджмента
Project scope – это границы проекта. Это очень важное понятие для
программных проектов в виду изменчивости требований. Часто бывает,
что разработчики начинают создавать одну систему, а после,
постепенно, она превращается в другую. Причем для менеджеров по
продажам, а также заказчика, ничего радикально не произошло, а с
точки зрения внутреннего устройства ПО, технологий, алгоритмов
реализации, архитектуры – все радикально меняется. За подобными
тенденциями должен следить и грамотно с ними разбираться проектный
менеджмент.
Компромиссы – важнейший аспект управления программными
проектами в силу согласовываемости ПО. Важно не потерять все
согласуемые параметры и стороны и найти приемлемый компромисс.
Одна из техник управления компромиссами будет рассказана в
контексте изучения методологии MSF.
При разработке программных проектов, следуя MSF 3.1, важны следующие области
управления.
Область
управления проектами
Описание
Планирование
и
мониторинг
проекта,
Интеграция и синхронизация планов проекта;
контроль за изменениями
организация процедур и систем управления и
в
проекте
(Project
мониторинга проектных изменений
planning / Tracking /
Change Control)
Управление
Определение и распределение объема работы
рамками проекта (Scope (рамок проекта); управление компромиссными
Management)
решениями в проекте
Составление календарного графика исходя из
Управление
оценок
трудозатрат,
упорядочивание
задач,
календарным графиком
соотнесение доступных ресурсов с задачами,
проекта
(Schedule
применение статистических методов, поддержка
Management)
календарного графика
Управление
стоимостью
Management)
Оценки стоимости исходя из оценок
временных затрат; отчетность о ходе проекта и его
(Cost
анализ; анализ затратных рисков; функциональностоимостной анализ (value analysis)
Управление
Планирование
ресурсов;
формирование
персоналом
(Staff проектной команды; разрешение конфликтов;
Resource Management)
планирование и управление подготовкой
Управление
коммуникацией
(Communications
Management)
Коммуникационное планирование (между
проектной
группой,
заказчиком/спонсором,
потребителями/пользователями,
др.
заинтересованными лицами); отчетность о ходе
проекта
Управление
рисками
Management)
Организация процесса управления рисками в
(Risk команде
и
содействие
ему;
обеспечение
документооборота управления рисками
Управление
снабжением
(Procurement)
Анализ цен поставщиков услуг и/или
аппаратного/программного
обеспечения;
подготовка
документов
об
инициировании
предложений (requests for proposals – RFPs), выбор
поставщиков и субподрядчиков; составление
контрактов и переговоры об их условиях; договора;
заказы на поставку и платежные требования
Управление
Планирование
качества,
определение
качеством
(Quality применяемых
стандартов,
документирование
Management)
критериев качества и процессов его измерения
1.3 Интегрированная система поддержки жизненного
цикла
Андрей
Алямовский
15.04.2001
Выбор систем автоматизированного проектирования
и их конфигураций в условиях дефицита средств —
весьма
нетривиальная
задача.
Формальное
или,
наоборот, слишком личностное отношение на этапе
выбора приводит к потерям средств и значительной
временной задержке достижения целей. В статье
рассматривается возможный подход к построению
интегрированной системы на базе одной из САПР
среднего уровня.
Как показывает опыт, нет ни одного заказчика, потребности которого — в том числе и
подкрепленные финансовыми ресурсами ограничивались бы приобретением только
графического редактора. Такую тенденцию проявляют все группы потребителей,
независимо от степени использования ими средств автоматизированного проектирования.
Распространенной — и благоприятной для бизнеса — является ситуация, когда изменение
идеологии в сфере автоматизации совпадает с объективной потребностью перехода от
чертежных систем к трехмерным твердотельным и гибридным параметрическим
моделировщикам. При этом запросы заказчика к степени «интегрированности» и
«полноты» решения даже для средних производств зачастую превосходят необходимые
потребности и, несмотря на усилия разработчиков, часто находятся на грани возможностей
надежных отчуждаемых продуктов.
Попытка охватить весь жизненный цикл изделия предпринята на сегодняшний день
многими отечественными и зарубежными разработчиками. Явно выражены две тенденции:
автоматизация «от функции» (на базе собственно инженерных компонентов САПР) и
автоматизация от соответствующей системы PDM (product data management). Оба
направления зачастую конкурируют, поскольку проблема интеграции самостоятельной
PDM с имеющимися или предполагаемыми к внедрению прикладными системами весьма
нетривиальна. Такой путь не порождает энтузиазма на уровне исполнителей, да и у
руководства среднего звена не всегда находит сторонников. Причина — продолжительный
«нулевой» цикл, отвлечение части персонала на решение задач, весьма далеких от текущих
и среднесрочных вопросов. Естественным является также опасение, что реализация
декларируемых преимуществ касающихся, как правило, весьма далеких перспектив, в
конце концов, останется на уровне «внедрения», характерного для систем АСУП 10-15летней давности. Сегодня оказывается, что только содержание и поддержка таких АСУП
требовали штатов, сопоставимых с числом работников основного производства, и,
соответственно, вносили весомый вклад в характерные для того времени 500 — 800%
накладных расходов. Современная универсальная PDM-система — заведомо недешевый
продукт, комплектуемый к тому же соответствующей лицензионной СУБД. Прибавьте
затраты на содержание персонала «актуальных» профессий, весьма актуальных в регионах,
и аргументы налицо.
Существенно более реалистичным на фоне дефицита финансовых ресурсов является
вариант, когда инженерные решения первичны. Эта позиция тем более аргументирована,
поскольку проекты уже есть, и менять графическую среду и, тем более «образ жизни»,
ради неочевидных перспектив весьма рискованно. Поэтому наиболее характерным
является внедрение интегрированных систем на фоне имеющейся ситуации,
приспосабливаясь к ней, не прерывая производственного процесса. Здесь возможны
варианты.
Первый — графическая система с интегрированными модулями для поддержки
жизненного цикла, которые разрабатываются тем же производителем, что и базовый
продукт, или же поставляются под общей торговой маркой: Dassault Systemes, Unifraphics
Solutions, PTC, «Toп Системы», «Аскон», НИЦ АСК. Достоинства импортных продуктов, с
точки зрения отечественного потребителя, обычно ассоциируются с немалой ценой,
отсутствием локализованных версий и русскоязычной документации, и, в конце концов,
фундаментальными различиями в «менталитете». Кроме того, в ходе принятия решения о
выборе базы для построения интегрированной системы необходим анализ стабильно
работающих у отечественных заказчиков аналогов. Число их в России ограничивается
единицами и далеко не все попытки внедрения, указываемые производителем в success
story можно назвать удачными. Отечественные продукты свободны от этих проблем, но в
них ощущается ориентация на «родную» графическую систему, что особенно проявляется
при эксплуатации системы в гетерогенных средах. Кроме этого, по крайней мере сейчас, в
этих системах многие аспекты проектирования, изготовления и сопровождения изделий
моделируются поверхностно или отсутствуют.
Второй вариант предполагает построение интегрированной среды на базе
«системообразующего» графического продукта, обладающего достаточной собственной
универсальностью и развитыми интерфейсными возможностями. Одной из таких
известных нам САПР является SolidWorks. Даже в базовой поставке — это больше, чем
параметрический редактор, а принятая в системе концепция открытости, предполагающая
интеграцию с ведущими производителями программного обеспечения из ряда отраслей
делает ее устойчивым «скелетом» для построения функционально и организационноориентированных сред. Важным элементом такой интеграции является существование и, в
некотором смысле, поддержка альтернативных конфигураций, что гарантирует
возможность нахождения вполне приемлемых решений в реальных производственных
ситуациях.
В таблице 1 приведена принципиальная схема применимости SolidWorks и приложений
на всех этапах жизненного цикла изделия (см. терминологический словарь по CALSтехнологиям, РД-1-000-99, www.cals.ru).
Заметим, что наличествует программное обеспечение, реализующее библиотеки деталей,
менеджеры ведения проекта, расчетные модули.
В каждую группу могут входить приложения, имеющие сходное назначение, но
отличающиеся по способу реализации, полноте функциональных возможностей, цене и т.д.
Например, в группу «Численные методы анализа» вошли конечно-элементные и
разностные модули для решения задач прочности, устойчивости, колебаний,
моделирования
литьевых
процессов,
аэрогидродинамики,
теплового
расчета,
электромагнетизма, оптимального проектирования и т.д. К группе «Листовой металл»
относятся приложения для получения разверток, решения задачи оптимального раскроя,
генерации управляющих программ.
Поскольку номенклатура решений весьма широка, постоянно изменяется и дополняется, то
я ограничусь лишь перечислением пакетов, апробированных нашей компанией или
знакомым нам по достоверной информации, свидетельствующей
универсальности и надежности решения.
о достаточной
Следует отметить, что значительная часть приложений — это не «усеченные»
модификации популярных программных продуктов, а самостоятельные продукты,
использующие преимущества параметрического твердотельного и поверхностного
моделирования. В частности, задача оптимального проектирования, ранее считавшаяся
весьма экзотической и реализованная в специальных модулях «тяжелых» САПР, в связке с
параметрической системой стала атрибутом настольных систем, где она входит в
стандартную поставку, или отгружается дополнительно за незначительную доплату.
Аналогична ситуация с процедурами построения разверток — благодаря
«параметрической» идеологии, данный модуль включен в «стандартный» вариант
SolidWorks и его возможности позволяют строить развертки призматических и круговых
тонкостенных элементов с учетом параметров материала.
При создании интегрированной системы по описанной технологии, возникает проблема
экспорта данных или интеграции с имеющимися графическими и расчетными
программами. Задача решается двояко. Некоторые приложения (в частности, большинство
«управленческих») имеют развитые интерфейсные возможности. Доступ к другим может
осуществляться через SolidWorks, имеющий средства обмена для многих популярных
графических форматов.
На рисунке 1 приведен пример конструкции,
разработанной посредством SolidWorks. Модель на
100% параметризована, имеет 4280 компонентов, из
которых оригинальных — 327, сопряжений — 428.
Возможен произвольный доступ к элементам всех
уровней: сборка ; узел ; деталь ; элемент детали, а
также
к
топологической
информации
о
Рис.
1.
Пример геометрических и кинематических взаимосвязях для
конструкции, реализованной в любого объекта или их совокупности. При
SolidWorks
использовании
интегрированных
приложений
соответствующие данные помещаются в файлы сборок, что дает возможность оперативно
получать все данные об изделии на этапах проектирования, изготовления, поставки и
сопровождения.
Описанная технология построения интегрированной системы позволяет подобрать нужную
конфигурацию программно-аппаратных средств применительно к разнообразным и
меняющимся потребностям, осуществлять процесс построения системы поэтапно, не
прерывая производственного процесса, исходя как из функциональных критериев, так и
финансовых ресурсов заказчика.
Андрей Алямовский (catia@dol.ru) — сотрудник компании «СиКоP» (Москва)
Таблица 2. Области применения и
соответствующие программные продукты
PDM/ERP
SAP
R/3
Integration
for
SolidWorks,
Production*,
Корпорация*
Omega
Босс
Управление
Search*
документооборотом
SolidWorks
Анимация
Animator
Фотореалистически
е изображения
Численные методы
анализа
PhotoWorks
Cosmos/Works,
FloWorks, ProCAST
Трассировка
EMbassyWorks
кабелей
Моделирование
геометрии
электронных
CircuitWorks
компонентов
Трубопроводы
SolidWorks Piping
Библиотеки
Технорма*,
стандартных
StandartWorks*,
компонентов
Toolbox/SE
Трансляторы
SolidWorks,
данных
CIMSW-Cat
Расширенное
Rhinoceros,
геометрическое
SurfaceWorks
моделирование
Воспроизведение
FeatureWorks
геометрии
Детали
машин
и
ТММ
MechSoft,
CamTrax, GearTrax
Моделирование
кинематики и динамики
Dynamic
Designer/Motion,
visualNastran Motion
TechCard,
Производство
MasterCAM,
CAMWorks,
SURFCAM
Литье пластмасс и
проектирование
прессформ
Моделирование
Moldflow
Plastics
Advisers, MoldWorks
TracePro
оптических
систем
и
явлений
Прототипирование
Листовой металл
Анализ точности
3D Lightyear
SolidWorks,
Flex3DSW
Sigmund 1D, 3D
1.4 Введение
В настоящее время история развития систем, предназначенных для хранения и обработки
информации с использованием ЭВМ, насчитывает уже более полувека. Еще относительно
недавно в ходу были перфораторы в качестве устройств ввода данных, листинги в виде
рулонов бумаги длиной порою до нескольких метров - в качестве носителя результатов
машинной обработки, недельные, либо месячные временные интервалы - в качестве
нормативных сроков обработки информации.
В последнее десятилетие ушедшего века ситуация претерпела качественные изменения.
Если попытаться сформулировать "портрет" современной информационной системы
масштаба предприятия в виде десятка тезисов, то мы увидим, что она имеет:
в основе - методологию управления, направленную на достижение
стратегических целей высшего менеджмента предприятия, выраженной в
информационной системе в виде системы управляющих воздействий,
регламентирующей деятельность пользователей,
возможность доступа к данным для множества пользователей, объединенных в
локальную сеть предприятия, а зачастую - и для пользователей, удаленных от
центрального офиса на сотни и тысячи километров,
наличие средств коммуникации и элементов корпоративного решения задач
коллективом пользователей;
развитый, дружественный графический интерфейс конечного пользователя,
режимы обработки оперативной информации, близкие к режиму реального
времени,
средства аутентификации и разграничения доступа, позволяющие дозировать
информацию в соответствии с должностными обязанностями пользователя;
высокий уровень защищенности от несанкционированного доступа,
один или более серверов баз данных, суммарный объем которых измеряется в
гига- или терабайтах; возможность обработки тысяч и миллионов записей при
составлении отчетности,
инвариантность (в определенных пределах) к аппаратным и операционным
средам функционирования серверных и клиентских приложений,
использование стандартизованных языков и протоколов для представления и
манипулирования данными.
Основу информационной системы составляют "три кита". Это - база данных, как правило,
реляционного типа, поддерживающая доступ на основе стандарта SQL, программные
средства, обеспечивающие логику обработки данных, интерфейс пользователя.
Определение ИС
Далее по тексту информационной системой (ИС)1), либо автоматизированной ИС, АИС,
будем называть программно-аппаратную систему, предназначенную для автоматизации
целенаправленной деятельности конечных пользователей, обеспечивающую, в
соответствие с заложенной в нее логикой обработки, возможность получения,
модификации и хранения информации.
Ключевым моментом в этом определении является понятие "целенаправленной
деятельности". Речь идет о деятельности, направленной на решение конкретной задачи,
стоящей перед пользователем (коллективом пользователей).
Некоторые исследователи (см., например, [1.1]) определяют ИС несколько иным образом.
ИС в широком смысле - взаимосвязанная совокупность средств, методов и персонала,
используемых для хранения, обработки и выдачи информации в интересах достижения
поставленной цели.
Основные отличия такого подхода: 1) ввод пользователей системы "внутрь" ИС, 2)
необязательность использования средств вычислительной техники. Такой подход также
имеет право на жизнь. Так, например, в нем удобно прослеживать общую историю
возникновения и развития систематических средств обработки информации в бизнесе,
которая началась, очевидно, в докомпьютерную эпоху. Однако, так как целью нашего
курса является изучение анализа требований к компьютерным системам обработки
информации, будем пользоваться приведенным выше первым определением.
Рассмотрим примеры некоторых программных средств, являющихся, либо не являющихся
ИС.
1С-Бухгалтерия 8.0. Используется в целях формирования бухгалтерской
отчетности предприятия перед налоговыми органами. Является информационной
системой.
MS Excel. Программное средство универсального характера, предназначенное для
манипуляций с данными, представленными в табличной форме автоматизации
расчетов, формирования разнообразных диаграмм для анализа данных. Не
является информационной системой.
Книга MS Excel, содержащая сведения о штатном расписании, работниках
предприятия и оснащенная макросами, позволяющими рассчитывать заработную
плату и формировать платежные ведомости. Является информационной системой.
Система Axapta Retail комплексной автоматизации деятельности сети розничных
магазинов. Является информационной системой.
Реляционная база данных DB-2 фирмы IBM. Не является информационной
системой.
Классификация ИС
Информационные системы могут быть классифицированы по различным признакам.
Рассмотрим наиболее важные из них.
Классификация по масштабу
По масштабу ИС
корпоративные.
будем
подразделять
на
однопользовательские,
групповые
и
Однопользовательские ИС, как это ясно из названия, предназначены для использования на
одном рабочем месте. В настоящее время на мировом и отечественном рынке представлено
множество решений, предназначенных для автоматизации деятельности отдельно взятого
пользователя. Как правило, это - решения, ориентированные на специалиста в той или иной
области, будь то составление спецификаций для сборки изделий из комплектующих,
планирование ремонтов оборудования, учет расходов и доходов частного предпринимателя
оптовой торговли, либо составление расписаний занятий в деканате.
В настоящее время альтернативу таким узкоспециализированным системам составили
табличные процессоры, не имеющие проблемной специализации, в первую очередь - MS
Excel. Системы этого класса трудно отнести к классу ИС, но зачастую они позволяют
непрограммирующему специалисту создать и, что очень важно, самостоятельно развивать
собственные решения, заменяющие, а местами и перекрывающие функционал
однопользовательских систем образца 90-х годов.
В основе большинства однопользовательских систем лежит стандарт X-Base (Clipper,
FoxPro, dBase). Широко используются также решения на базе систем Paradox, Clarion, MS
Access. Каждая из перечисленных конкурирующих систем обладает собственной
высокоуровневой инструментальной средой, позволяющей спроектировать базу данных,
логику обработки, пользовательский интерфейс, отчеты с помощью "помощников"построителей. На рубеже тысячелетий появились также и однопользовательские решения
на базе промышленных реляционных СУБД. В этом случае ПО сервера инсталлируется
непосредственно на рабочую станцию пользователя. Примером может служить Personal
Oracle. Данные решения предъявляют значительные требования к ресурсам рабочей
станции, однако несут в себе многие преимущества промышленных СУБД.
Групповые системы предназначены для автоматизации деятельности в рабочей группе
(отделе, кластере, группе проекта и т.д.). В отличие от однопользовательских ИС,
групповые системы, как правило, представляют специализированные клиентские решения
(их часто называют автоматизированными рабочими местами, АРМ) для различных
участников группы. Например, для оптовой фирмы, ИС может представлять набор таких
АРМ, как "Менеджер по продажам", "Кладовщик", "Снабженец", "Директор". Для учебного
планирования - "Преподаватель", "Работник бюро планирования", "Работник учебного
отдела", "Специалист по планированию на кафедре", "Работник деканата".
Групповое использование решений на базе табличных процессоров возможно, но имеет
существенные ограничения, связанные с разграничением доступа, регламентацией и
синхронизацией вносимых изменений. По сути единственный режим их использования,
обеспечивающий корректность данных - "файловый сервер, один автор, N читателей".
При создании групповых ИС в целом используются те же средства и инструментальные
среды, что и при создании однопользовательских ИС. Следует, однако, отметить, что для
использования в группе при выборе между системами с файловым и реляционным
сервером следует отдавать предпочтение реляционному серверу, причем целесообразно
использование выделенного сервера. Это может быть, например, сервер Oracle, DB2, MS
SQL, Sybase, Informix.
Корпоративные ИС (КИС) предназначены для автоматизации деятельности предприятия. В
англоязычной литературе понятие "КИС" неразрывно связано с понятием "ERP" (Enterprise
Resource Planning). В основе ERP-систем лежит международный стандарт управления
предприятием MRP-II (Manufacture Resource Planning), обеспечивающий возможность
учета, анализа и планирования основных ресурсов - финансов, человеческих,
материальных. Соответственно, корпоративные ERP-системы - набор интегрированных
приложений, которые комплексно, в едином информационном пространстве поддерживают
все основные аспекты управленческой деятельности предприятий: планирование ресурсов
(финансовых, человеческих, материальных) для производства товаров (услуг), оперативное
управление выполнением планов (включая снабжение, сбыт, ведение договоров), все виды
учета и анализ результатов хозяйственной деятельности.
Среди требований, предъявляемым к современным КИС:
централизация данных в единой базе (в основе - всегда промышленная СУБД),
близкий к реальному времени режим работы,
сохранение общей модели управления для предприятий разных отраслей,
поддержка территориально-распределенных структур,
работа на широком круге аппаратно-программных платформ и СУБД.
Примеры ERP-систем - SAP R3, "Галактика", MS Navision Axapta.
Классификация по архитектуре
1. Архитектура "Файл-сервер". Исторически первая архитектура информационных
систем. Как исполняемые модули, так и данные размещаются в отдельных файлах
операционной системы. Доступ к данным осуществляется путем указания пути
(path) и использования файловых операций (открыть, считать, записать). Для
хранения данных используется выделенный сервер (отдельный компьютер),
который и является файловым сервером. Исполняемые модули хранятся либо на
рабочих станциях, либо на файловом сервере. В последнем случае упрощается
процедура их администрирования, но при этом возрастают требования к
надежности сети.
2. Архитектура "Клиент-сервер". Клиент-сервер - это не только архитектура, это новая парадигма, пришедшая на смену устаревшим концепциям. Суть ее
заключается в том, что клиент (исполняемый модуль) запрашивает те или иные
сервисы в соответствии с определенным протоколом обмена данными. При этом, в
отличие от ситуации с файловым сервером, нет необходимости в использовании
прямых путей операционной системы: клиент их "не знает", ему "известны" лишь
имя источника данных и другие специальные сведения, используемые для
авторизации клиента на сервере. Сервер, который физически может находиться на
том же компьютере, а может - на другом конце земного шара, обрабатывает запрос
клиента и, произведя соответствующие манипуляции с данными, передает клиенту
запрашиваемую порцию данных.
В рамках направления "клиент-сервер" существуют два основных "диалекта":
"тонкий" и "толстый" клиент.
В системах на основе тонкого клиента используется мощный сервер баз данных, это
- высокопроизводительный компьютер и библиотека так называемых хранимых
процедур, позволяющих производить вычисления, реализующие основную логику
обработки данных, непосредственно на сервере. Клиентское приложение,
соответственно, предъявляет невысокие требования к аппаратному обеспечению
рабочей станции. Основное достоинство таких систем - относительная дешевизна
клиентских станций.
Системы с толстым клиентом, напротив, реализуют основную логику обработки на
клиенте, а сервер представляет собой в чистом виде сервер баз данных,
обеспечивающий исполнение только стандартизованных запросов на манипуляцию
с данными (как правило - чтение, запись, модификацию данных в таблицах
реляционной базы данных). В системах такого класса требования к рабочей станции
выше, а к серверу - ниже. Достоинство архитектуры - переносимость серверной
компоненты на серверы различных производителей: все промышленные серверы баз
данных реляционного типа поддерживают работу со стандартизованным языком
манипулирования данными SQL, но внутренний встроенный язык обработки
данных, необходимый для реализации логики обработки на сервере у каждого из
серверов свой.
3. Трехслойная архитектура. Базируется на дальнейшей специализации компонент
архитектуры: клиент занимается только организацией интерфейса с
пользователем, сервер баз данных - только стандартизованной обработкой
данных. Для реализации логики обработки данных архитектура предусматривает
отдельный слой - слой бизнес-логики. Этот слой может представлять собой либо
выделенный сервер (сервер приложений), либо размещаться на клиенте в
качестве динамической библиотеки. Данная архитектура позволила соединить
достоинства тонкого и толстого клиентов: хорошая переносимость соединяется в
ней с невысокими требованиями к клиенту.
С развитием интранет-интернет технологий появилась разновидность трехслойной
архитектуры на основании использования web-технологий. В этой разновидности
роль сервера приложений играет web-сервер, а в качестве клиента используется
стандартный web-браузер. Достоинства - в пониженных требованиях к клиенту и в
легкой встраиваемости данной архитектуры в мировые информационные сети.
Основной недостаток - известные ограничения, накладываемые на интерфейс
пользователя web-браузерами.
Классификация
по
информации
характеру
использования
С некоторой степенью приближения все ИС можно разделить на 2 класса: информационнопоисковые и управляющие.
Конечные пользователи информационно-поисковых систем (ИПС), как правило, имеют
доступ к хранимым данным только "по чтению" и используют данные системы для поиска
ответов на те или иные вопросы. Доступ по модификации данных имеет администратор
системы, в функции которого входит обеспечение актуальности информации, устранение
ошибок.
Классические примеры ИПС - системы поиска в библиотеках, на транспорте (справки о
наличии билетов). На современном этапе развития информационных технологий
классические ИПС постепенно вытесняются поисковыми серверами Интернет - общего
назначения и специализированными.
Альтернатива ИПС - управляющие системы автоматизируют (полностью или частично)
деятельность, связанную с принятием решений. Действия конечных пользователей таких
систем приводят к модификации информации, что, конечно, не исключает возможности
просто получать информацию, как в ИПС.
Примеры управляющих систем - системы бухгалтерского учета, системы планирования
производственных ресурсов и т.п.
Классификация по системе представления данных
Среди наиболее распространенных средств и моделей представления данных следует
выделить:
"самодельные" форматы хранения данных, хранящихся в файлах (текстовых,
бинарных);
специализированные форматы хранения данных, использовавшиеся в
"дореляционный" период (например, x-Base, paradox);
языки структурированной разметки на основе формата xml;
реляционная модель; SQL сервер;
объектная, объектно-реляционная модель;
документоориентированное хранилище (IBM Lotus/Domino).
Классификация
по
поддерживаемым
стандартам
управления и технологиям коммуникации
Эпоха
стихийной
разработки
АИС
закончена.
Современные
автоматизированные
информационные системы разрабатываются, исходя из сложившихся реалий
автоматизированного управления бизнесом. Существует значительное количество
концепций, технологий, подходов, нашедших свое эффективное применение в различных
отраслях промышленности по всему миру. Некоторые из них приобрели статус
международных стандартов. В спецификации АИС, разрабатываемой для массовой
продажи, как правило, указывается - какие стандарты и технологии управления она
поддерживает. Менее строги требования к АИС, создаваемым под заказ для конкретного
предприятия. Однако и в этом случае не учитывать сложившийся в мире позитивный опыт
просто неразумно. Ниже перечислены некоторые, наиболее важные, технологии и
стандарты.
MRP (Material Requirements Planning) - планирование поставок материалов, исходя из
данных о комплектации производимой продукции и плана продаж.
CRP (Capacity Requirements Planning) - планирование производственных мощностей,
исходя из данных о технологии производимой продукции и прогноза спроса.
MRPII (Manufacture Resource Planning) - планирование материальных, мощностных и
финансовых ресурсов, необходимых для производства. Стандартизовано ISO.
ERP (Enterprise Resource Planning) - финансово-ориентированное планирование ресурсов
предприятия, необходимых для получения, изготовления, отгрузки и учета заказов
потребителей на основе интеграции всех отделов и подразделений компании.
SCM (Supply Chain Management) - управление цепочками поставок. Реализация бизнеспроцессов на базе внешних предприятий и торговых площадок Основано на референтной
модели SCOR, стандартизованной Supply Chain Council.
CRM (Customer Relationship Management) - управление взаимоотношениями с заказчиками.
Комплекс методов и средств, нацеленный на завоевание, удовлетворение требований и
сохранение платежеспособных клиентов.
ERPII (Enterprise Resource & Relationship Processing) - управление ресурсами и
взаимоотношениями предприятия. Объединяет в себе 3 вышеперечисленные технологии.
Workflow - технология, управляющая потоком работ при помощи программного
обеспечения, способного интерпретировать описание процесса, взаимодействовать с его
участниками и при необходимости вызывать соответствующие программные приложения.
OLAP (Online Analytical Processing) - оперативный анализ данных. Технология поддержки
принятия управленческих решений на основе концепции многомерных кубов информации.
Project Management - управление проектами. Поддерживается рядом международных
стандартов.
CALS (Continuous Acquisition and Lifecycle Support) - непрерывная информационная
поддержка поставок и жизненного цикла. Описывает совокупность принципов и
технологий информационной поддержки жизненного цикла продукции на всех его стадиях.
Объединяет в себе практически все вышеперечисленные подходы и технологии.
Столь лаконичные определения, конечно же, позволяют лишь ознакомиться с современной
терминологией. Задача их детального изучения не входит в план занятий. Тех, кто захочет
получить подробный материал по этим вопросам, можно порекомендовать следующие
литературные источники [1.2-1.6].
Классификация по степени автоматизации
Приводится классификация из [1.1].
Ручные ИС характеризуются отсутствием современных технических средств переработки
информации и выполнением всех операций человеком. Например, о деятельности
менеджера в фирме, где отсутствуют компьютеры, можно говорить, что он работает с
ручной ИС.
Автоматические ИС выполняют все операции по переработке информации без участия
человека.
Автоматизированные ИС предполагают участие в процессе обработки информации и
человека, и технических средств, причем главная роль отводится компьютеру. В
современном толковании в термин "информационная система", как правило, вкладывается
понятие автоматизированной системы.
Роль требований в задаче внедрения АИС
Какие можно сделать выводы из рассмотренной классификации АИС? Даже не говоря о
многообразии производителей АИС, не рассмотренного в настоящей лекции, на основании
только сформулированных признаков становится очевидным, что существует значительное
количество АИС и данные АИС существенно различаются между собой. Следовательно,
выбор АИС для предприятия - достаточно нетривиальная задача. Для того, чтобы успешно
ее решить, необходимо хорошо знать объект внедрения (автоматизируемое предприятие),
особенности его деятельности, стратегию развития и многие другие аспекты,
предопределяющие характеристики закупаемой АИС. Указанные знания в конечном итоге
формализуются в документе требований к АИС, на основе которого и осуществляется
выбор и последующая настройка АИС. В еще большей степени требования к АИС важны
при разработке АИС на заказ. Подробнее об этом - в следующих лекциях.
1.5 Понятие требования. Классификации требований
1.5.1 Определение понятия требования
Л.Новиков в русской редакции нотации RUP [2.9] приводит следующее определение:
"Требование - это условие или возможность, которой должна соответствовать система".
В IEEE Standard Glossary of Software Engineering Terminology (1990) [2.1] данное понятие
трактуется шире. Требование - это:
1. условия или возможности, необходимые пользователю для решения проблем или
достижения целей;
2. условия или возможности, которыми должна обладать система или системные
компоненты, чтобы выполнить контракт или удовлетворять стандартам,
спецификациям или другим формальным документам;
3. документированное представление условий или возможностей для пунктов 1 и 2.
Введем еще одно определение. Требования - это исходные данные, на основании которых
проектируются и создаются автоматизированные информационные системы. Первичные
данные поступают из различных источников, характеризуются противоречивостью,
неполнотой, нечеткостью, изменчивостью. Требования нужны в частности для того, чтобы
Разработчик мог определить и согласовать с Заказчиком временные и финансовые
перспективы проекта автоматизации. Поэтому значительная часть требований должна быть
собрана и обработана на ранних этапах создания АИС. Однако собрать на ранних стадиях
все данные, необходимые для реализации АИС, удается только в исключительных случаях.
На практике процесс сбора, анализа и обработки растянут во времени на протяжении всего
жизненного цикла АИС, зачастую нетривиален и содержит множество подводных камней;
подробнее о процессе - в лекциях 4 - 8.
1.5.2 Классификация требований
Существует значительное количество различных методов классификации требований [2.2-
2.7], наиболее существенные из которых будут рассмотрены в лекции.
Требования к продукту и процессу
Требования к продукту. В своей основе требования - это то, что формулирует заказчик.
Цель, которую он преследует - получить хороший конечный продукт: функциональный и
удобный в использовании. Поэтому требования к продукту являются основополагающим
классом требований. Более подробно требования к продукту детализируются в следующих
ниже классификациях.
Требования к проекту. Вопросы формулирования требований к проекту, т.е. к тому, как
Разработчик будет выполнять работы по созданию целевой системы, казалось бы, не лежат
в компетенции Заказчика. Без регламентации процесса Заказчиком легко можно было бы
обойтись, если бы все проекты всегда выполнялись точно и в срок. Однако, к сожалению,
мировая статистика результатов программных проектов говорит об обратном. Заказчик,
вступая в договорные отношения с Разработчиком, несет различные риски, главными из
которых является риск получить продукт с опозданием, либо ненадлежащего качества.
Основные мероприятия по контролю и снижению риска - регламентация процесса создания
программного обеспечения и его аудит.
Насколько подробно Заказчику следует регламентировать требования к проекту - вопрос
риторический. Ответ на него зависит от множества факторов, таких, как ценность
конечного продукта для Заказчика, степень доверия Заказчика к Разработчику, сумма
подписанного контракта, увязка срока сдачи продукта в эксплуатацию с бизнес-планами
Заказчика и т.д. Однако, со всей определенностью можно сказать следующее:
1. регламентация процесса Заказчиком позволяет снизить его риски;
2. мероприятия Заказчика по регламентации процесса приводят к дополнительным
накладным расходам. Требуется найти разумный компромисс между степенью
контроля рисков и величиной расходов.
В качестве требований к проекту могут быть внесен регламент отчетов Разработчика,
совместных семинаров по оценке промежуточных результатов, определены характеристики
компетенций участников рабочей группы, исполняющих проект, их количество, указана
методология управления проектом. Ниже сформулирован пример формулировки
требования к оффшорному проекту (Заказчик и Разработчик физически находятся в разных
государствах) - в этой ситуации Заказчику требуется жесткий контроль над Разработчиком.
1. Разработчик представляет Заказчику согласованный план работ c детализацией
(WorkBreakdownStructure - WBS) с точностью до конкретных исполнителей.
2. Разработчик осуществляет ежедневные сборки, регрессионное тестирование
компонент разрабатываемого продукта и тестирование продукта в целом.
3. Все управленческие и проектные артефакты, исходные коды и тестовые примеры
размещаются в режиме online в интегрированной среде разработки Rational
ClearCase с возможностью для Заказчика осуществления online-мониторинга на
базе web-технологий.
Уровни требований
Внедрение ИС на предприятии всегда преследует конкретные бизнес-цели - такие, как,
например, повышение прозрачности бизнеса, сокращение сроков обработки информации,
экономия накладных расходов и т.д. Современные информационные системы - это
крупные программные системы, содержащие в себе множество модулей, функциональных,
интерфейсных элементов, отчетов и т.д. Как охватить единым взором такие разнородные
вещи, как цели, преследуемые топ-менеджером предприятия Заказчика, описание
интерфейса пользователя и характеристики модуля, осуществляющего расчет
себестоимости изделия?
К счастью, человечество уже давно изобрело приемы борьбы со сложностью, широко
применяемые в моделировании сложных объектов - абстракцию и декомпозицию.
Применительно к дисциплине анализа требований к программным системам эти принципы
работают следующим образом. Требования разделяются по уровням. Уровни требований
связаны, с одной стороны, с уровнем абстракции системы, с другой - с уровнем управления
на предприятии.
Обычно выделяют три уровня требований.
На верхнем уровне представлены так называемые бизнес-требования (business
requirements). Примеры бизнес-требования: система должна сократить срок
оборачиваемости обрабатываемых на предприятии заказов в три раза. Бизнестребования обычно формулируются топ-менеджерами, либо акционерами
предприятия.
Следующий уровень - уровень требований пользователей (user requirements).
Пример требования пользователя: система должна представлять диалоговые
средства для ввода исчерпывающей информации о заказе, последующей
фиксации информации в базе данных и маршрутизации информации о заказе к
сотруднику, отвечающему за его планирование и исполнение. Требования
пользователей часто бывают плохо структурированными, дублирующимися,
противоречивыми. Поэтому для создания системы важен третий уровень, в
котором осуществляется формализация требований.
Третий уровень - функциональный (functional requirements). Пример
функциональных требований (или просто функций) по работе с электронным
заказом: заказ может быть создан, отредактирован, удален и перемещен с
участка на участок.
Существуют объективные противоречия между требованиями различных уровней. Так,
очевидным бизнес-требованием является требование о полноте информации, собираемой
на рабочих местах пользователей в единую базу данных. Чем полнее информация - тем
глубже база для анализа деятельности и принятия решений. С другой стороны,
конкретному пользователю системы вполне может быть достаточно использования только
той части информации, которая влияет на выполнение его основных функций.
Важные правила внедрения и использования АИС на предприятии - "Одна точка сбора",
"Данные собираются там, где они появляются". Использование этих правил позволяет
избежать затрат на необоснованное дублирование информации и, что важнее - потерь от
ошибок учета, неизбежно возникающих при дублировании точек ввода.
Внедрение АИС на предприятии приводит к необходимости оснащения всех точек ввода
информации автоматизированными рабочими местами (АРМ), обучению персонала и,
зачастую, оптимизации и повышению уровня формализации рабочих процессов,
выполняемых персоналом. Поэтому внедрение АИС - непростой процесс, часто
требующий "перекройки человеческого материала" и встречающий сопротивление со
стороны пользователей, которые не готовы, либо не хотят работать по-новому.
Системные
требования
программному обеспечению
и
требования
к
Существуют различные трактовки понятия "Системные требования" (system requirements).
К. Вигерс формулирует данный термин, как "высокоуровневые требования к продукту,
которые содержат многие подсистемы, то есть системе" [2.2]. При этом под системой
понимается программная, программно-аппаратная, либо человеко-машинная система.
Данная система является сложной, структурированной системой и системные требования
являются подмножеством функциональных требований к продукту. В данное
подмножество целесообразно относить наиболее важные, существенные требования,
которые относятся в целом к системе и не содержат избыточной детализации.
INCOSE (International Council on Systems Engineering) дает более детальное определение
системы: "комбинация взаимодействующих элементов, созданная для достижения
определенных целей; может включать аппаратные средства, программное обеспечение,
встроенное ПО, другие средства, людей, информацию, техники (подходы), службы и
другие поддерживающие элементы". Таким образом, происходит разделение между
системными требованиями, как обобщающему понятию и требованиями к программному
обеспечению, как выделенному подмножеству системных требований, направленных
исключительно на программные компоненты системы. Этот же подход прослеживается в
стандарте ГОСТ Р ИСО/МЭК 12207/99 [2.8]: работы, связанные с системой в целом и с
программным обеспечением выделяются в отдельные группы в целях удобства
оперирования.
В практике компьютерной инженерии бытует другой, более узкий контекст использования
данного понятия: под системными требованиями в узком смысле понимается требования,
выдвигаемые прикладной программной системой (в частности - информационной) к среде
своего функционирования (системной, аппаратной). Пример таких требований - тактовая
частота процессора, объем памяти, требования к выбору операционной системы.
Функциональные, нефункциональные требования и
характеристики продукта
Функциональные требования регламентируют функционирование или поведение системы
(behavioral requirements). Функциональные требования отвечают на вопрос "что должна
делать система" в тех или иных ситуациях. Функциональные требования определяют
основной "фронт работ" Разработчика, и устанавливают цели, задачи и сервисы,
предоставляемые системой Заказчику.
Функциональные
требования
записываются,
как
правило,
при
посредстве
предписывающих правил: "система должна позволять кладовщику формировать
приходные и расходные накладные". Другим способом являются так называемые варианты
использования (uses cases) - популярный и весьма продуктивный способ представления
требований.
Это - основной, определяющий вид требований, который будет рассматриваться на
протяжении всего лекционного курса.
Нефункциональные требования, соответственно, регламентируют внутренние и внешние
условия или атрибуты функционирования системы. К. Вигерс [2.2] выделяет следующие
основные группы нефункциональных требований:
Внешние интерфейсы (External Interfaces),
Атрибуты качества (Quality Attributes),
Ограничения (Constraints).
Среди внешних интерфейсов в большинстве современных АИС наиболее важным является
интерфейс пользователя (User Interface, UI). Кроме того, выделяются интерфейсы с
внешними устройствами (аппаратные интерфейсы), программные интерфейсы и
интерфейсы передачи информации (коммуникационные интерфейсы).
Основные атрибуты качества:
Применимость,
Надежность,
Производительность,
Эксплуатационная пригодность,
достаточно хорошо раскрыты в модели FURPS (см. ниже).
Ограничения [2.2] - формулировки условий, модифицирующих требования или наборы
требований, сужая выбор возможных решений по их реализации. Выбор платформы
реализации и/или развертывания (протоколы, серверы приложений, баз данных, ...),
которые, в свою очередь, могут относиться, например, к внешним интерфейсам (конец
цитаты).
Характеристики продукта. К.Вигерс [2.2] формулирует характеристику, "фичу" (feature),
как набор логически связанных функциональных требований, которые обеспечивают
возможности пользователя и удовлетворяют бизнес-цели.
Существует и более общий взгляд на данное понятие [2.9]: "features могут быть как
относящимся к функциональным, так и к нефункциональным требованиям и могут
изменяться от версии к версии продукта".
С.Орлик в [2.6] отмечает, что "с точки зрения инженерии требований, features являются
самостоятельным артефактом, который может быть соотнесен как с функциональными
требованиями, так и с нефункциональными".
Роль характеристик проявляется в первую очередь в области маркетинга: не всякий
потенциальный потребитель продукта станет читать его функциональные описания, а
набор ключевых характеристик, характеризующих конкурентные преимущества, можно
сделать лаконичным и уместить на одной странице рекламной листовки, либо напечатать
на компакт-диске.
Классификация RUP
В спецификациях Rational Unified Process при классификации требований используется
модель FURPS+ со ссылкой на стандарт IEEE Std 610.12.1990 [2.1].
Акроним FURPS обозначает следующие категории требований:
Functionality (Функциональность)
Usability (Применимость)
Reliability (Надежность)
Performance (Производительность)
Supportability (эксплуатационная пригодность).
Символ "+" расширяет FURPS-модель, добавляя к ней:
ограничения проекта,
требования выполнения,
требования к интерфейсу,
физические требования,
часть из которых уже была рассмотрена выше.
Кроме того, в спецификациях RUP выделяются такие категории требований, как
требования, указывающие на необходимость согласованности с некоторыми
юридическими и нормативными актами;
требования к лицензированию,
требования к документированию.
1.5.3 Методологии и стандарты, регламентирующие
работу с требованиями
Среди основополагающих нормативных документов в области работы с требованиями
можно выделить следующие.
1. Разработки IEEE:
IEEE 1362 "Concept of Operations Document".
IEEE 1233 "Guide for Developing System Requirements Specifications".
IEEE Standard 830-1998, "IEEE Recommended Practice for Software Requirements
Specifications"
IEEE Standard Glossary of Software Engineering Terminology/IEEE Std 610.12-1990
IEEE Guide to the Software Engineering Body of Knowledge (1) - SWEBOK®, 2004.
2. Отечественные ГОСТ:
ГОСТ 34.601-90. Информационная технология. Автоматизированные системы.
Стадии создания.
ГОСТ 34.602-89. Информационная технология. Техническое задание на создание
автоматизированной системы
ГОСТ 19.201-78. Единая система программной документации. Техническое
задание. Требования к содержанию и оформлению.
1.6 Свойства требований
Ф. Брукс в своем, теперь уже ставшим классическим, эссе1), следующим образом
охарактеризовал роль требований в разработке программного обеспечения.
Строжайшее
и
единственное
правило
построения
систем
программного
обеспечения (ПО) - решить точно, что же строить. Никакая другая часть концептуальной
работы не является такой трудной, как выяснение деталей технических требований, в
том числе и взаимодействие с людьми, с механизмами и с иными системами ПО. Никакая
другая часть работы так не портит результат, если она выполнена плохо. Ошибки
никакого другого этапа работы не исправляются так трудно.
Наука
извлечения
и
формализации
качественных
(иногда
говорят
"хороших",
"правильных") требований носит во многом эмпирический характер. Однако, в практике
разработки программных систем накопились определенные представления о том, какими
свойствами должны обладать требования к программной системе. Это:
полнота,
ясность,
корректность,
согласованность,
верифицируемость,
необходимость,
полезность при эксплуатации,
осуществимость,
модифицируемость,
трассируемость,
упорядоченность по важности и стабильности,
наличие количественной метрики.
Большинство из этих свойств раскрыто в первом разделе стандарта IEEE [3.1] и широко
обсуждается в работах [3.3,3.5]. Рассмотрим указанные выше свойства подробнее.
Полнота.
Как известно из теории искусственного интеллекта, неполнота - одно из фундаментальных
свойств человеческого знания. При создании программных систем нам приходится иметь
дело с характеристиками еще несуществующей системы. Идея о том, что необходимо
сформулировать все требования полностью, т.е. исчерпывающим образом, до начала
проектирования, а тем более - реализации системы, изжила себя вместе с так называемым
каскадным подходом2) [3.2], который поддерживал последовательную модель реализации
системы. Спиральный3) [3.2] подход, на котором базируется большинство современных
методологий, предусматривает поэтапное выделение и детализацию требований на всем
протяжении цикла разработки системы.
Тем не менее, требование полноты предъявляется к требованиям, формулируемым к
системе. Надо понимать, что данное требование - это скорее тенденция, цель, к которой
нужно постараться максимально приблизиться на как можно более ранних стадиях
проекта.
Требование полноты можно рассматривать в двух аспектах: полнота отдельного
требования и полнота системы требований.
Полнота отдельного требования - свойство, означающее, что текст требования не требует
дополнительной детализации, то есть в нем предусмотрены все необходимые нюансы,
особенности и детали данного требования.
Полнота системы требований - свойство, означающее, что совокупность артефактов,
описывающих требования, исчерпывающим образом описывает все то, что требуется от
разрабатываемой системы.
Ясность
(недвусмысленность,
однозначность спецификаций).
определенность,
Каждый из совладельцев4) разрабатываемой системы обладает своим личным опытом
восприятия событий внешнего мира. Слово, произнесенное вслух, вызывает
индивидуальные ассоциации в семантическом пространстве каждого отдельного
воспринимающего субъекта. То, что является ясным, допустим, для кардиохирурга, совсем
необязательно будет таковым для специалиста в области программной инженерии.
Соответственно, требование обладает свойством ясности, если оно сходным образом
воспринимается всеми совладельцами системы. На практике ясность требований
достигается в том числе и в процессе консультаций, в ходе которых происходит
"выравнивание тезаурусов" совладельцев системы. Хорошим подспорьем в этом служит
согласованный сторонами глоссарий ключевых понятий предметной области.
К.Вигерс [3.3] дает следующий совет по повышению ясности документов: "Пишите
документацию просто, кратко и точно, применяя лексику, понятную пользователям".
Еще одной стороной понятия "ясность требования" является его прослеживаемость (см.
также понятие трассируемости ниже по тексту). Требование, которое сформулировано
ясно, может быть прослежено, начиная от того документа, где оно сформулировано
впервые, вплоть до рабочих спецификаций.
Корректность
(непротиворечивость).
и
согласованность
Корректность - одно из важнейших свойств требований. К. Вигерс в [3.3] вводит понятие
корректности требования через точность описания функциональности. В этом смысле
корректность в определенной степени конкурирует с полнотой. Но есть и различие: если
свойство полноты носит скорее качественный характер: абсолютная полнота представляет
недостижимый идеал, к которому можно приближаться, то свойство корректности носит
оценочный характер и задает дихотомию: каждое из требований либо корректно, либо нет.
Кроме того, можно рассуждать о взаимной корректности требований или согласованности
(непротиворечивости): если два требования вступают в конфликт, значит - как минимум
одно из них некорректно. В иерархии требований (см. материалы лекции 2) можно
выделить вертикальную и горизонтальную согласованность. Иными словами, требования
не должны противоречить, соответственно, требованиям своего уровня иерархии и
требованиям "родительского" уровня. Так, требования пользователей не должны
противоречить бизнес-требованиям, а функциональные требования - требованиям
пользователя.
Верифицируемость (пригодность к проверке).
Признаки (свойства) требований, рассматриваемые в настоящей лекции, нельзя считать
независимыми.
В
математической
статистике
такие
признаки
называются
кореллируемыми. Так, свойство верифицируемости существенно связано со свойствами
ясности и полноты: если требование изложено на языке, понятном и одинаково
воспринимаемым участниками процесса создания информационной системы, причем оно
является полным, т.е. ни одна из важных для реализации деталей не упущена - значит, это
требование можно проверить. При этом в ходе проверки у сторон (принимающей и
сдающей работу) не должно возникнуть неразрешимых противоречий в оценках. Методы
верификации требований будут рассмотрены в лекции Проверка требований. Так как
хорошо сформулированные требования составляют основу успешного создания системы роль верифицируемости трудно переоценить. Требования к системе представляют основу
контракта между Заказчиком и Исполнителем и если данные требования нельзя проверить
- значит и контракт не имеет никакого смысла, следовательно, успех или неудача проекта
будут зависеть только от эмоциональных оценок сторон и их способности договориться, а
это - слишком шаткая основа для осуществления работ.
1.7 Процесс анализа требований
1.7.1 Рабочий поток анализа требований
Анализ требований - один из основных рабочих потоков (workflow) программной
инженерии, наряду, допустим, с такими, как проектирование интерфейса пользователя,
либо программирование.
Для его обозначения в англоязычной литературе, как правило, используется понятие
"Requirement Process". В отечественной практике, наряду с обобщающим термином "анализ
требований", принятым, в частности, в ГОСТ Р ИСО/МЭК 12207-99, встречаются также
такие термины, как "поток работ "требования", "работа с требованиями", "определение
требований" и т.д., что вносит изрядную путаницу. Для того, чтобы внести некоторую
ясность, рассмотрим декомпозицию рабочего потока Requirement Process на составляющие,
принятую в SWEBOK, и введем терминологию, которой будем придерживаться на
протяжении лекционного курса.
SWEBOK предлагает выделить в Requirement Process следующие основные составляющие:
Requirements
Requirements
Requirements
Requirements
Elicitation (Извлечение требований),
Analysis (Анализ требований в узком смысле),
Specification (Специфицирование требований),
Validation (Проверка требований).
В качестве примера альтернативной декомпозиции потока работ можно рассмотреть
взгляд, предложенный в RUP [4.1]. RUP предлагает выделить в основном потоке анализа
требований такие компоненты, как:
Analyze the Problem (Анализ проблемы),
Understand Stakeholder Needs (Понимание потребностей совладельцев),
Define the System (Определение системы),
Manage the Scope of the System (Управление контекстом системы),
Refine the System Definition (Уточнение определения системы).
Обобщая указанные выше декомпозиции, а также подходы, описанные в [4.4,4.5-4.7],
далее будем придерживаться следующей, более удобной в методическом плане схемой
декомпозиции потока работ "Работа с требованиями":
Формирование видения;
Выявление требований;
Классификация и спецификация требований;
Расширенный анализ требований (моделирование и прототипирование);
Документирование требований;
Проверка требований;
Управление требованиями;
Совершенствование процесса работы с требованиями.
Первые 6 работ в лекционном курсе рассматриваются, как компоненты процесса анализа
требований.
Для того, чтобы успешно создать автоматизированную информационную систему (или
шире, программную систему), необходимо, во-первых, определить компоненты потока
работ, которые будут использоваться командой разработчиков и, во-вторых, правильно их
организовать. В вопросы организации входит упорядочение работ во времени, интерфейсы
между ними, параллелизм, работа с рисками и многое другое.
Найти ответ на первый вопрос может помочь общая классификация задач, работ и
операций программной инженерии, представленная в ГОСТ Р ИСО/МЭК 12207-99. Другая,
более поздняя по времени классификация, присутствует в SWEBOK. Однако нужно
отметить, что данные руководящие документы рассматривают общий случай, а в частном
проекте может быть задействован далеко не весь арсенал работ.
Сложнее - с решением второго вопроса. На сегодня существуют и имеют примеры
успешного применения десятки и сотни различных методологий (процессов), среди
наиболее известных - MSF, RUP, Oracle PJM, XP, FDD, SCRUM, PSP, Crystal, DSDM.
Методологии подразделяются на 3 "волны": каскадные (исторически первые),
прогнозирующие (например, RUP) и "быстрые" (agile), вошедшие в широкую практику на
рубеже тысячелетий [4.3].
Описания методологий существенно разнятся объемом (от десятков до тысяч страниц
текста), наборами базовых работ и рабочих квалификаций, акцентами (работа с моделями,
управление рисками, построение команды и пр.). Но авторы их описаний обычно сходятся
в одном: лучшая из методологий, которой нужно следовать, чтобы добиться успеха именно та, которую предлагает (описывает, рекламирует) автор. Редким исключением
являются работы А. Коберна, автора группы методологий Crystal (см., в частности, [4.3]),
где он предлагает брать за основу не "самый лучший" из процессов, а тот, который, вопервых, наилучшим образом соответствует проектной задаче, а во вторых - команде,
которая будет его реализовывать. В [4.3] вводится несколько метрик, позволяющих
частично формализовать процесс подбора методологии.
1.7.2 Почему нужно анализировать требования?
Из сказанного выше следует, что не все работы и операции, известные в программной
инженерии, используются в той или иной методологии и, тем более, конкретном проекте.
Возникает вопрос: является ли рабочий поток АТ необходимым в цепочке рабочих потоков
создания информационной системы, стоит ли тратить на него время? Каков требуемый
объем результатов, ожидаемых от АТ?
Со всей очевидностью можно утверждать: да, АТ, как этап разработки ИС, невозможно
пропустить: этот этап закладывает фундамент всего процесса проектирования и реализации
системы. Степень проработки АТ может быть различной: от совершенно неформальной
записки, представленной на одной странице, до развернутой системы документов, моделей
и прототипов, построенной в соответствии с принципами одной из прогнозирующих
методологий, например, RUP. Она зависит от следующих основных факторов: размеров
проекта, величины имеющихся ресурсов и степени рисков. Невысокая глубина проработки
приемлема для небольших проектов, характеризующихся небольшим ресурсом и
невысокими рисками. Хорошо проработанные требования позволяют:
выработать общее понимание между Заказчиком и Разработчиком;
определить рамки проекта;
более точно определить финансовые и временные характеристики проекта;
обезопасить Заказчика от риска получить продукт, в котором он не сможет
работать,
обезопасить Разработчика от риска попасть в ситуацию "неконтролируемого
размытия границ", которое может привести к непредвиденным затратам ресурсов
сверх начальных ожиданий.
Анализ требований - это процесс (бизнес-процесс) и, следовательно, к нему подходят
методы и средства процессного подхода к управлению (см., например, [1]).
Один из ключевых вопросов, позволяющих оценить результативность процесса - что
является выходом (результатом) процесса. В чем результат АТ? Результатом рабочего
потока "анализ требований" является набор артефактов. Это могут быть текстовые
документы, модели UML, либо других языков моделирования, прототипы программного
обеспечения.
Другой важный вопрос - какие цели преследует процесс.
RUP предлагает следующие цели для потока работ АТ:
добиться одинакового понимания с заказчиком и пользователями о том, что
должна делать система;
дать разработчикам наилучшее понимание требований к системе;
определить границы системы;
определить интерфейс пользователя и системы.
1.7.3 Кто создает и использует требования
Как и кем используются требования?
Специалист по АТ - постановка задачи, определение рамок проекта;
Представитель заказчика - постановка задачи, определение рамок проекта,
контроль работы исполнителя, приемка результатов работы;
Архитектор системы - разработка архитектуры, проектирование подсистем;
Программист - разработка программного кода;
Тестировщик - составление тест-плана, тестовых сценариев;
Менеджер проекта - планирование и контроль исполнения работ.
В рамках курса лекций для всех упомянутых выше лиц будем использовать обобщающий
термин "Совладельцы (заинтересованные стороны)" (stakeholders). Совладельцами, вслед за
разработчиками RUP и MSF (см., например, [4.4,4.8]), будем называть всех участников
проекта создания программной системы, прямо или косвенно заинтересованных в его
успехе. Авторы большинства современных методологий разработки программных систем
сходятся в том, что в группе совладельцев ключевую роль играют две группы
представителей Заказчика - те, кто ставит стратегические цели и выделяет финансирование
и те, кто будет непосредственно использовать разработанный продукт. Причем, в отличие
от каскадных методов, где Заказчик подключался в начальной фазе - составлении
технического задания и конечной - приемке готовой работы, в современных методологиях
Заказчик, действительно заинтересованный в успехе проекта автоматизации, должен
участвовать в нем непрерывно.
1.7.4 Организация
примере MSF
работы
с
требованиями
на
В MSF для обозначения роли участников команды софтверного проекта используется
понятие ролевых кластеров [4.9].
MSF основан на постулате о шести качественных целях, достижение которых определяет
успешность проекта. Эти цели обуславливают модель проектной группы. В то время как за
успех проекта ответственна вся команда, каждый из ее ролевых кластеров, определяемых
моделью, ассоциирован с одной из упомянутых шести целей и работает над ее
достижением.
Шесть ролевых кластеров модели проектной группы - это "Управление продуктом"
(product management), "Управление программой" (program management), "Разработка"
(development), "Тестирование" (test), "Удовлетворение потребителя" (user experience) и
"Управление выпуском" (release management). Они ответственны за различные области
компетенции (functional areas) и связанные с ними цели и задачи.
MSF организован на базе комбинации каскадной и спиральной моделей. Отдельная стадия
работы содержит в себе 5 фаз:
Envisioning (выработка концепции),
Planning (планирование),
Developing (разработка),
Stabilizing (стабилизация),
Deploying (внедрение).
В фазе выработки концепции работа с требованиями наиболее интенсивна (см. табл. 4.1).
Таблица 4.1.
Ролевой
кластер
Управление
продуктом
Управление
Фокус
Общие цели проекта; выявление нужд и требований
заказчика; документ общего описания и рамок проекта.
Цели дизайна; концепция решения; структура проекта.
программой
Разработка
Прототипирование;
анализ
технологических
возможностей; анализ осуществимости.
Удовлетворение
потребителя
Тестирование
Необходимые эксплуатационные характеристики решения
и их влияние на его разработку.
Стратегии
тестирования;
критерии
приемлемости,
их
влияние на разработку решения.
Управление
выпуском
Требования
внедрения
и
их
влияние
на
разработку
решения; требования сопровождения.
Как видно из таблицы, все 6 кластеров работают со своими группами требований.
Продолжается плотная работа с требованиями и на следующей фазе - фазе планирования,
см. табл. 4.2.
Таблица 4.2.
Ролевой
Фокус
кластер
Управление
Анализ бизнес-требований
продуктом
Управление
Функциональная спецификация
программой
Удовлетворени
е потребителя
Сценарии/примеры
требования,
требования
использования,
локализации
пользовательские
и
общедоступности
(accessibility).
Тестирование
Требования тестирования.
Управление
Эксплуатационные требования.
выпуском
В фазах разработки и внедрения работа с требованиями сосредотачивается в кластерах
управления продуктом и программой, см., соответственно, табл. 4.3,4.4.
Таблица 4.3.
Ролевой
Фокус
кластер
Управление
Ожидания заказчика.
продуктом
Управление
Управление функциональной спецификацией.
программой
Таблица 4.4.
Ролевой
Фокус
кластер
Управление
продуктом
Управление
программой
Получение отзывов и оценок заказчика; акт о приеме
выполненной работы.
Сопоставление рамок проекта с поставленным решением;
управление стабилизацией.
1.8 Контекст задачи анализа требований
1.8.1 Анализ требований,
проблемной области
бизнес-анализ,
анализ
В настоящее время существуют уже сотни методик, методологий, процессов, стандартов,
регламентирующих те или иные детали выбора и комплексирования потоков работ при
разработке автоматизированных информационных систем. То, что в АТ стоит в начале
цепочки работ и что ее результаты во многом определяют успех проекта мало у кого
вызывает сомнения. Другое дело - работы, связанные с бизнес-анализом и бизнесмоделированием. Их роль не столь очевидна и принимается далеко не всеми
методологиями. Итак, стоит ли собирать информацию о предприятии, для которого
разрабатывается (выбирается) АИС в виде бизнес-моделей или стоит пропустить этот этап
и сразу формировать артефакты АТ?
Авторы [5.1], "отцы-основатели" RUP и UML, в этом вопросе дают определенную
свободу: можно создавать бизнес-модели при помощи соответствующих расширений UML
и рекомендаций RUP, а можно ограничиться выработкой глоссария объектов предметной
области. Как и в вопросе выбора глубины проработки артефактов АТ, вопрос - проводить
или не проводить бизнес-анализ (или, точнее говоря, анализ проблемной области),
решается в зависимости от конкретной задачи.
Роль глоссария при АТ.
Несколько утрируя, можно сказать, что Заказчик и Разработчик всегда говорят на разных
языках. Общее понимание вырабатывается с трудом, этот процесс занимает время, но
важность его трудно переоценить: ведь успешная реализация проекта в области и
внедрения АИС во многом зависит от того, удастся ли выработать и документировать их
общее представление о предмете разработки. Если же Разработчик идет еще дальше и
вникает в особенности ведения дел на предприятии Заказчика - он, во-первых, сможет
добиться лучшего понимания требований к АИС и, во-вторых, участвовать наряду с
Заказчиком в формулировке этих требований, анализе пропущенных требований и пр.
Глоссарий (подробнее см. в лекции 8) можно рассматривать, как документ,
удостоверяющий общее понимание основной терминологии Заказчиком и Разработчиком.
Задачу анализа бизнес-процессов (деловое моделирование), столь популярную в последние
десятилетия ввиду устойчивой конъюнктуры, следует рассматривать, как часть более
общей задачи, анализа проблемной области. Работы, посвященные анализу проблемной
области, появились в отечественной литературе в середине прошлого века; данная
тематика неразрывно связана с задачным подходом и инженерией экспертных систем.
Применимы ли методы, принятые при построении интеллектуальных систем для такой
"более приземленной" задачи, как задача построения АИС - безусловно, да. Так, стратегии
извлечения знаний, рассмотренные в [5.2], во многом пересекаются с рекомендациями по
работе аналитика [5.3], методы решения задачи путем редукции на подзадачи и поиска в
пространстве состояний нашли свое отражение во множестве методик бизнес-анализа,
анализа и синтеза программных систем и этот список можно продолжать. Другой вопрос насколько результативно применение тех или иных моделей и методов при описании
организационных систем.
Ключ к решению этого вопроса лежит в следующем: вначале надо определить цели и
задачи самого бизнес-анализа, как этапа построения КИС.
С позиций моделирования, анализ требований (АТ) и анализ проблемной области (АПО) принципиально разные процессы.
АПО преследует классические цели создания модели: налицо объект (автоматизируемое
предприятие или организационная система, ОС) и задача аналитика - отразить этот объект
в создаваемой модели с требуемой степенью точности (рис. 5.1).
Анализ требований, напротив, направлен на моделирование воображаемого, еще не
существующего объекта (АИС) (рис. 5.2). Т.е. сначала создается модель, а затем, на ее
основании, синтезируется объект.
Для того, чтобы прояснить связь между этими процессами, необходимо заметить, что
создаваемая АИС также является моделью, по отношении к ОС. Таким образом, создавая
документ АТ, мы тем самым порождаем как бы "модель второго порядка", т.к. документ
АТ является ничем иным, как моделью модели ОС. Не обладая моделью АПО, мы,
конечно, можем создать модель АТ. Но при этом мы рискуем тем, что при синтезе
оригинала модели (т.е. АИС), не обладая знаниями об ОС, мы можем попасть в ситуацию
рассогласования: результирующая АИС не будет ингерентна (согласована с) ОС и, тем
самым, не станет жизнеспособной.
Рис. 5.1.
Следует ли из этого, что этап АПО является необходимым звеном создания КИС? Нет, не
всегда. Здесь уместно обратиться к классификации задач и методологий А. Коберна [5.4].
Кроме того, это зависит от состава третьей компоненты "треугольника моделирования" моделирующего субъекта, в нашем случае - коллектива Разработчика. Если моделирующий
субъект обладает неявными знаниями об ОС в достаточном объеме - значит, АПО можно
исключить. На практике это возможно в следующих случаях:
Разработчик является частью (структурным подразделением, дочерним
предприятием и т.д.) ОС, в коллектив Разработчика входят эксперты, хорошо
знающие предметную область;
Заказчик наравне с Разработчиком участвует в создании документа АТ и
разделяет с ним ответственность за принятие решений. Это - путь "agile
методологий" (см. материалы лекции 15).
Рассмотрим теперь обобщенную "формулу" создания АИС. ОС->М(ОС)->М(АИС)>М’(АИС)->М’’(АИС)->М’’’(АИС)->АИС (рис. 5.1).
Анализ организационной системы позволяет создать ее модель М(ОС). Это - модель
бизнес-анализа (проблемной области).
Анализируя модель проблемной области, в ней можно вычленить,
с одной стороны, задачи и функции, реализуемые внутри ОС и функции
коммуникации ОС и среды,
с другой - устройство предметной области (в начале - на уровне концептуальной
модели),
с третьей - требования к информации и ее обработке.
Выделив среди функций те, которые подлежат автоматизации, мы получаем основу для
выявления функциональных требований к системе. Остальная, собранная на этапе АПО,
информация служит для поиска нефункциональных требований. В результате получаем
модель АТ, как первое приближение модели АИС, М(АИС).
Затем, путем углубленного анализа и проектирования, формируются, соответственно,
аналитическая модель М’(АИС), проектная модель М’’(АИС) и модель реализации
М’’’(АИС).
Модель уровня реализации позволяет синтезировать собственно АИС, как совокупность
программных, информационных, организационных и др. артефактов.
АИС в свою очередь представляет собой модель организационной системы М’(ОС),
замыкая цикл моделирования.
1.8.2 Методологии бизнес-анализа
Методологии бизнес анализа можно разделить на три категории по типам моделей:
модели, преследующие цель анализа и улучшения организационной системы
(например, SWOT , VCM, BPR, CPI/TQM/ISO9000, BSC),
модели общего назначения, такие, как SADT, DFD, IDEF1, IDEF3, IDEF5 и другие,
модели, специально разработанные для использования при автоматизации
(например, ISA, BSP, ARIS, RUP).
Наиболее развитая модель описания проблемной области предлагается в методологии
ARIS.
Архитектура ARIS [5.5] выделяет в организации следующие подсистемы.
Организационная. Определяет структуру организации - иерархию подразделений,
должностей и конкретных лиц, многообразие связей между ними, а также
территориальную привязку структурных подразделений.
Функциональная. Определяет функции, выполняемые в организации.
Подсистемы входов/выходов. Определяют потоки используемых и производимых
продуктов и услуг.
Информационная (подсистема данных). Описывает получение, распространение и
доступ к информации (данным).
Подсистема процессов управления. Определяет логическую последовательность
выполнения функций посредством событий и сообщений. Можно сказать, что
подсистема управления - это совокупность разнесенных во времени сообщений
разного рода.
Подсистема целей организации. Описывает иерархию целей, достигаемых в ходе
выполнения того или иного процесса.
Подсистема средств производства. Описывает жизненный цикл основных и
вспомогательных средств производства.
Подсистема человеческих ресурсов. Описывает прием на работу, обучение и
продвижение по службе персонала организации.
Подсистема расположения организационных структур. Описывает
территориальное расположение организационных единиц.
Данное разделение является в определенной мере условным; выделенные "подсистемы" не
являются подсистемами в смысле системного анализа, т.к. взаимопроникают и
пересекаются. Они представляют скорее совокупность предметов исследования, разных
взглядов на исследуемый объект.
Слушателю курса предлагается самостоятельно проанализировать, какие группы и
категории требований к системе позволяет прояснить та или иная компонента принятой в
ARIS структуризации объекта исследования.
1.8.3 Требования и архитектура АИС
Говоря об архитектуре АИС, обычно подчеркивают деление на аппаратные, программные,
информационные, организационные компоненты, их связность и детализацию.
Метафора архитектуры RUP описывается в виде 4+1 представлений: логическое,
представление процессов, представление реализации и физическое представление
связываются между собой представлением вариантов использования (use case), которое
играет центральную роль в выработке архитектуры системы (рис. 5.2).
Требования первичны по отношению к архитектуре. Но это не значит, что требования и
архитектура должны разрабатываться последовательно.
Рис. 5.2.
Напротив, эти процессы взаимоувязаны и должны быть существенно запараллелены. Как
только собран минимальный набор ключевых требований, дающих понимание о том, что
нужно делать - должна быть найдена архитектура, объясняющая, как это может быть
реализовано. В крупных, ответственных проектах обычно рассматривается несколько
альтернативных архитектур, их достоинства и недостатки применительно к исходным
требованиям.
В процессе работы с требованиями они детализируются, детализируется и архитектура. В
случае множественности альтернативных архитектур на определенном уровне детализации
необходимо остановиться на одной, чтобы не распылять ресурсы. Но природа требований
такова, что, помимо детализации они еще и изменяются. С изменением требований
изменяются
и
детали
архитектуры.
Устойчивость
архитектуры
проявляется
в
незначительных ее изменениях при добавлении, детализации и изменении требований.
Если наступил момент, при котором появление новой информации о требованиях
перестала оказывать влияние на архитектуру - значит, архитектура стабилизировалась.
Это - нормальный, естественный путь развития требований и архитектуры. Но что делать,
если требования изменились настолько, что архитектура перестала им соответствовать?
Причин тому могут быть разные, например: неопытная архитектурная группа не проявила
достаточно дальновидности; группа по сбору требований пропустила на ранних стадиях
критичные, архитектурно значимые требования; в бизнес-сфере Заказчика произошли
большие перемены, вызвавшие коренное изменение требований к системе. Следствия
также могут быть различными: договоренность об увеличении сроков и сумм по контракту;
исправление ситуации за счет Разработчика; разрыв контракта.
Альтернативный выход предлагается в методологии XP: архитектура - не догма, а всего
лишь метафора. Если требования вошли вразрез с существующей архитектурой - значит,
архитектуру нужно просто изменить. Следует понимать, что путь и рецепты XP при
кажущейся простоте ориентированы далеко не на любой коллектив. Команда XP состоит из
профессионалов, имеющих позитивный опыт работы в этой методологии.
1.8.4 Анализ требований и другие рабочие потоки
программной инженерии
Рассмотрим краткий обзор рабочих потоков RUP и их связь с потоком работ АТ (рис. 5.3).
Рис. 5.3.
Поток работ "деловое моделирование" служит основой для анализа и формирования
требований к АИС, позволяет избежать ошибок.
Поток работ "управление средой" предоставляет исходную информацию для рабочей
группы АТ, регламентирующую форматы оформления, CASE-средства, регламенты
работы.
Поток работ "управление проектом" основывается на спецификации требований.
Стратегическое и тактическое планирование, формирование промежуточных вех
(ожидаемых результатов) тесно увязано с требованиями к системе.
Поток работ "анализ и проектирование" осуществляется на основе исходных данных,
предоставленных АТ. В определенной мере эти потоки работ проводятся параллельно. При
обнаружении проблем, связанных с требованиями, возникает обратная связь от этого
потока работ к потоку работ АТ.
Поток работ "испытание" во многом базируется на модели требований и дополнительных
спецификациях, регламентирующих процесс тестирования (тестовые сценарии и пр.).
Для потока работ "реализация" связь с требованиями не указана. Между тем автор считает,
что требования должны анализироваться и учитываться во ВСЕХ рабочих потоках проекта,
даже если это формально не предусмотрено выбранным группой процессом. Людям
свойственно ошибаться и ошибки, совершенные на ранних стадиях проекта, при движении
от этапа к этапу нарастают, как снежный ком. Поэтому любому участнику команды,
заинтересованному в успехе проекта, нелишне заглянуть в спецификацию требований и
убедиться в том, что та работа, которая ему поручена, соответствует тому или иному
требованию. Это позволяет организовать обратную связь, позволяющую отследить ошибки
в спецификациях. Многие проекты зашли в тупик именно из-за оторванности группы,
отвечающей за реализацию от группы сбора и анализа требований.
1.9 Выявление требований
1.9.1 Источники требований
Основным источником требований к информационной системе, безусловно, являются
соображения, высказанные представителями Заказчика. В соответствие с иерархической
моделью требований данная информация структурируется как минимум на 2 уровня:
бизнес-требования и
требования пользователей.
Проблема состоит в том, что требования формулируются к создаваемой, еще не
существующей системе, т.е. по сути решается начальная подзадача задачи проектирования
АИС, а представители Заказчика далеко не всегда бывают компетентны в данном вопросе.
Поэтому, наряду с требованиями, высказанными Заказчиком, целесообразно собирать и
требования от других совладельцев системы: сотрудников аналитической группы
исполнителя, внешних экспертов и т.д.
Результирующий, часто достаточно сырой материал рассматривается, как документ
"Требования совладельцев"1). На требования совладельцев обычно не накладывается
никаких специальных ограничений.
Продолжая рассуждения, начатые в предыдущей лекции, модель создаваемой
информационной системы в определенной мере должна отражать модель ОС.
Поэтому другим важным источником информации, помимо выявления требований,
являются артефакты, описывающие предметную область. Это могут быть документы с
описанием бизнес-процессов предприятия, выполненные консалтинговым агентством, либо
просто документы (должностные инструкции, распоряжения, своды бизнес-правил),
принятые на предприятии. Одной из немногих методологий, в которой специально
выделяется рабочий поток делового моделирования, является Rational Unified Process.
Еще одна альтернатива, используемая при выявлении требований - так называемые
"лучшие практики", широко используемые в настоящее время в бизнес-консалтинге и при
внедрении корпоративных информационных систем. Лучшие практики представляют
собой описания моделей деятельности успешных компаний отрасли, используемые
длительное время в сотнях и тысячах компаний по всему миру.
Подытоживая сказанное, отметим, что основными источниками, образующими "вход"
процесса выявления требований, являются требования, высказанные совладельцами, как
таковые или (и) артефакты, описывающие объект исследования. Однако, это - достаточно
упрощенный взгляд: чтобы данные поступили "на вход", аналитики требований должны
проделать немалую работу, связанную с подбором респондентов и информационных
материалов, организацией интервью и т.д.
1.9.2 Стратегии выявления требований
Интервью
Ключевой стратегией выявления требований было и остается интервью с экспертами.
В ставшей уже классической, но ничуть не утерявшей актуальность монографии Д.Марко
[6.1] в процессе проведения интервью предлагается выделить три подчиненных процесса:
подготовку, проведение интервью (опроса) и завершение. Ниже приводится краткий обзор
рекомендаций Д.Марко с акцентом на выявление требований (в монографии даны
рекомендации по интервьюированию с целью формирования модели объекта
исследования).
1. Подготовка
Подготовка позволяет спланировать процесс опроса и выработать стратегию управления
этим процессом. Важность подготовительного этапа вырастает, если респондент является
"дефицитным" полезным ресурсом, например - президентом крупной компании.
При подготовке Д.Марко рекомендует следующие шаги:
выберите нужного собеседника;
договоритесь о встрече;
установите предварительную программу встречи;
изучите сопутствующую информацию;
согласуйте свои действия с группой проектирования2).
При выборе собеседника для целей сбора требований определяющими являются две вещи:
Он действительно является экспертом по данному вопросу;
Его мнение действительно является ценным при формировании целевого набора
требований3).
Важно заранее оговорить цель встречи и ограничить беседу в пределах часа или менее.
Практика показывает, что активное общение в процессе интервью, как правило,
ограничивается часом. Если этого времени недостаточно, можно спланировать несколько
встреч.
Полезными приемами являются формирование программы беседы и ознакомление с ней
респондента, подробное планирование беседы вплоть до записи подготовленных вопросов.
Подготовленное таким образом интервью называют структурированным [6.2]. В
дополнение к так построенному интервью автор [6.2] предлагает проводить
неструктурированное интервью, "представляющее собой неформальную встречу, которой
не свойственны заготовленные впрок вопросы или заранее поставленные цели". Цель
такого интервью - пробудить респондента к креативу в области, в которой интервьюер
недостаточно хорошо ориентируется.
2. Проведение опроса
Ниже приведена цитата из [6.1], с некоторыми сокращениями и исключениям материала,
не относящегося к АТ.
В проведении опроса самое важное - правильно организовать и поддерживать
поток информации от эксперта к вам. Рекомендуется потратить время на обдумывание
верного начала опроса, при сборе информации по возможности использовать записи,
заканчивать разговор плавно. Обсудим подробнее каждый из этих пунктов.
Начиная разговор, не забудьте представиться и сформулировать цель встречи.
Это поможет избежать недоразумений и даст беседе правильное направление. Кроме
того, обговорите возможность ведения записей.
Затем сформулируйте первый вопрос. Помните, что первый вопрос часто задает
тон всему разговору, поэтому хорошо продумайте его.
Собирайте информацию, делая записи обо всем (о специальных терминах,
взаимосвязях между частями системы и т.п.) и ограничивая время беседы. Запишите
SADT-функции и данные, попытайтесь набросать диаграмму. Поддерживайте поток
информации, задавая вопросы, которые уточняют и подтверждают ответы.
Прежде всего, не возражайте.
Никогда не задавайте наводящих вопросов или вопросов с короткими ответами
"да" или "нет". Вместо этого записывайте то, что вам говорят, и просите подвести итог
или дать пояснения.
Вы получите от опроса больше, если вы дадите эксперту возможность говорить
то, что он хочет сказать, а не то, что вы хотите услышать.
Завершение
Следите за возникновением следующих ситуаций [6.1]:
вы уже получили достаточно информации;
вы получаете большой объем неподходящей информации;
обилие информации вас подавляет;
эксперт начинает уставать;
у вас с экспертом часто возникают конфликты.
Любая из этих причин - достаточное основание для завершения беседы.
Когда вы считаете нужным закончить опрос, завершайте беседу плавно. Кратко
подытожьте основные пункты и сделайте обзор полученных сведений, которые могут быть
опущены или неверно истолкованы. Договоритесь о времени следующей встречи, если она
нужна, и получите рекомендации для ближайших опросов. Поставьте эксперта в
известность, когда и как вы собираетесь использовать полученную информацию и когда вы
пришлете ему материал на рецензирование.
Всегда оформляйте материалы опроса сразу же после встречи с экспертом. В этом случае
немедленно возникает обратная связь, и вы минимизируете возможность потери важной
информации.
Что нужно помнить при опросе
Следующие рекомендации помогают поддерживать непрерывность потока и достоверность
информации, поступающей от эксперта [6.1]:
делайте паузы, пока эксперт думает. Дайте эксперту возможность решать, что
сказать дальше. Никогда не перебивайте, подсказывая ответ или задавая другой
вопрос;
старайтесь не задавать наводящих вопросов, вопросов-подсказок, вопросов,
содержащих ответ, потому что это не позволяет эксперту делиться своими
знаниями. Старайтесь не задавать контрольных вопросов, так как это прерывает
поток информации;
делайте записи, чтобы сосредоточиться на предмете разговора и чтобы
подготовиться к следующему вопросу, но не становитесь стенографом, иначе вы
можете потерять контроль над опросом.
Анкетирование
Анкетирование - самый малозатратный для аналитика способ извлечения информации, он
же - и наименее эффективный. Обычно применяется как дополнение к другим стратегиям
выявления требований.
Недостатки анкетирования очевидны: респонденты часто бывают неспособны, либо слабо
мотивированы в том, чтобы хорошо и информативно заполнить анкету. Велика
вероятность получить неполную или вовсе ложную информацию. Преимущество - в том,
что подготовка и анализ анкет требуют небольшой ресурс.
Л.Мацяшек [6.2] рекомендует формулировать в анкетах вопросы с замкнутым циклом
ответов в одной из следующих трех форм.
Многоальтернативные вопросы. Эта форма анкеты известна всем, кто когда либо проходил
тестирование; может расширяться комментариями респондента в свободной форме.
Рейтинговые вопросы. Представляют
предопределенный
набор
ответов
на
сформулированные вопросы. Используются такие значения, как "абсолютно согласен",
"согласен", "отношусь нейтрально", "не согласен", "абсолютно не согласен", "не знаю".
Вопросы с ранжированием. Предусматривает ранжирование (упорядочивание) ответов
путем присваивания им порядковых номеров, процентных значений и т.п.
Наблюдение
Наблюдение за работой моделируемой организационной системы - полезная стратегия
получения информации (хотя, строго говоря, по результатам наблюдения можно получить
модель ОС, а не модель АТ).
Различают пассивное и активное наблюдение. При активном наблюдении аналитик
работает, как участник команды, что позволяет улучшить понимание процессов.
Через наблюдение, а возможно, и участие аналитики получают информацию о
происходящих день за днем операциях из первых рук. Во время наблюдения за работой
системы часто возникают вопросы, которые никогда бы не появились, если бы аналитик
только читал документы или разговаривал с экспертами.
Недостатком этой стратегии является то, что наблюдатель, как и всякий "измерительный
прибор", вносит помехи в результаты измерений: сотрудники организации, находясь "под
колпаком" могут начать вести себя принципиально по другому, чем обычно.
Самостоятельное описание требований
Документы - хороший источник информации, потому что они чаще всего доступны и их
можно "опрашивать" в удобном для себя темпе. Чтение документов - прекрасный способ
получить первоначальное представление о системе и сформулировать вопросы к
экспертам.
Если опытный аналитик уже исследовал большое число систем такого же типа, что и на
предприятии внедрения, он обладает фундаментальными знаниями в соответствующей
предметной области, относительно определенного класса систем. Авторы методологии
SADT рекомендуют проводить самоопрос с тем, чтобы получить максимальную пользу от
своих знаний.
По результатам анализа документов и собственных знаний аналитик может составить
описание требований и предложить его представителям Заказчика в качестве информации
к размышлению, либо - основы для формирования технического задания.
Недостаток этой стратегии - опасность пропуска знаний, специфичных для объекта
исследования (в случае самоопроса), либо - неформализованных знаний, эмпирических
правил и процедур, широко используемых на практике, но не вошедших в документы.
Совместные семинары
Помимо классического интервью "тет а тет", существует значительное количество
методик, предполагающих широкое участие представителей Заказчика и Исполнителя.
Правила мозгового штурма предполагают полную раскрепощенность и свободу мнений,
даже самых вычурных и на первый взгляд "бредовых". Первое правило мозгового штурма "полный запрет на любую критику". Всякое высказанное мнение представляет ценность, а
полное отсутствие запретов позволяет полноценным образом подключить творческую
фантазию.
Затем, на втором этапе, все высказанные мнения тщательным образом обсуждаются,
заведомо неприемлемые варианты отсеиваются, формируются коллективные предложения.
Правила JAD-метода, считающегося одним из современных способов извлечения
требований, были впервые сформулированы в конце 1970-х годов компанией IBM.
Участники JAD-совещания:
Ведущий - специалист в области межличностных коммуникаций. Должен ориентироваться
в предметной области, но не обязательно хорошо ориентироваться в проблемах IT.
Секретарь - стенографист встречи. Фиксирует ее результаты на компьютере. Возможно
применение CASE-средств.
Заказчики - пользователи или руководители, основные участники, формирующие,
обсуждающие требования и принимающие решения.
Разработчики - аналитики и другие участники проектной команды. Работают в большей
части в пассивном режиме с целью наилучшего понимания проблемной области.
Совместные семинары, сохраняя все преимущества режима интервью, привносят
дополнительные бонусы: работа в группе более продуктивна, группы быстрее обучаются,
более склонны к квалифицированным заключениям, позволяют исключить многие ошибки.
Эта стратегия, очевидно, одна из самых затратных, однако она окупается за счет меньшего
количества ошибок и отказе от формализации в пользу живого общения, выработке общего
языка и пр. Некоторые методологии (например, XP) зиждутся на постоянном тесном
контакте между Заказчиком и Исполнителем и, если такой возможности нет - XP-проект
просто не сможет состояться.
"Разъясняющие встречи" [6.3] или "запланированный мозговой штурм" - термин,
пришедший из общей практики менеджмента и базирующийся на идеях сотрудничества
заинтересованных лиц для совместного анализа путей решения проблем, определения и
предупреждения рисков и т.п.
Как и проведение интервью, организация семинара требует соблюдения правил, с
которыми можно познакомиться в [6.2,6.4].
Прототипирование
Прототипирование - ключевая стратегия выявления требований в большинстве
современных методологий (подробнее см. в лекции 10). Программный прототип "зеркало", в котором видно отражение того, как понял Исполнитель требования Заказчика.
Процесс выявления требований путем прототипирования тем более интенсивен, чем это
зеркало кривее. Документальный способ выявления требований всегда уступает живому
общению. Анализ того, что сделано в виде интерфейсов пользователя дает еще больший
эффект. Подключается правополушарный канал восприятия, который, как известно,
работает у большинства людей на порядок эффективнее, чем вербальный.
Метод RAD - один из наиболее известных способов быстро создавать прототипы1).
RAD базируется на следующих базовых принципах:
Эволюционное прототипирование;
CASE-средства, как основной инструмент, включая возможности прямого и
обратного проектирования и автоматической генерации кода;
Высококвалифицированные специалисты, хорошо владеющие развитыми
инструментальными средствами;
Интерактивный JAD-метод, в котором общение совмещается с разработкой в
режиме online;
Жесткие временные рамки, как противоядие от "расползания границ" проекта:
если команда не укладывается в срок - функционал сужается.
1.10 Формирование видения
1.10.1 Видение продукта и границы проекта
Работы по формированию видения продукта и границ проекта обычно начинаются на
самой ранней фазе проекта, до начала широкомасштабных консультаций по выявлению
подробных требований, хотя в целом наличие и последовательность данных шагов зависит
от выбранной методологии. На практике данные работы зачастую совмещаются. Правила
извлечения требований, рассмотренные в лекции 6, могут быть использованы и при
формировании видения.
Анализируя литературу по рассматриваемой тематике, можно выделить следующие
широко употребимые ключевые слова: с одной стороны - концепция, видение, образ, с
другой - рамки, границы, контекст.
В первом случае речь идет о видении того, какой должна быть система. Обсуждаются
высокоуровневые требования (возможности, свойства) продукта и наиболее существенные
ограничения. Ряд авторов, напротив, настаивает на том, что видение должно быть "ничем
не ограниченным".
Понятие видения широко употребимо в бизнес-анализе. Если у топ-менежмента компании
имеется представление о том, какие ключевые цели, сегменты рынка, товарные позиции,
прибыль должны быть достигнуты, допустим, через 5 лет - значит, компания имеет
долгосрочное видение себя на рынке. Способ снятия ограничений при выработке видения
позволяет выработать новый взгляд на вещи, "подняться над ситуацией", планировать
будущее, отталкиваясь не от текущих ресурсов и ограничений, а от стратегических целей,
применяя инновации, ноу-хау и т.п.
Данный опыт формирования видения во многом переносим и на процесс разработки
информационных систем: нужно "увидеть" в горизонте средне- и (или) долгосрочного
планирования, как АИС впишется в организационные процессы предприятия, какие
ключевые выгоды она даст, какие проблемы позволит разрешить. При поиске новых
методов и средств управления предприятием на основе информационных технологий
зачастую приходится "перекраивать" существующие бизнес-процессы; по сути внедрение
АИС, затрагивающей существенный процент процессов предприятия, неизбежно приводит
к перестройке этих процессов с целью оптимизации деятельности предприятия,
достижения ключевых факторов эффективности и пр.
Во втором случае (рамки, границы, контекст) обсуждаются такие вопросы, как граница
системы и среды, требуемые ресурсы на создание системы, сроки. Построив "ничем не
ограниченное видение", рано или поздно приходится вернуться к таким прозаическим
вещам, как бюджет, календарное планирование, подбор персонала, вехи проекта.
Всегда ли нужно создавать документ "Концепция"? Следует ли разделять видение и
границы?
Зачастую Заказчик осознает необходимость автоматизации, как способ решения
накопившихся проблем. Сформулировав для себя проблему, Заказчик часто видит и
вариант ее решения, с которым приходит к Исполнителю ("мне нужен сайт", "требуется
CRM-система" и т.п.). Квалифицированный Исполнитель не должен, сломя голову,
спешить решать задачу в формулировке Заказчика. По образному выражению Г.Калянова1)
автоматизировать процессы "как есть" - все равно, что асфальтировать дорожки, по
которым ходят коровы.
В нотации RUP присутствует важная метафора: "Увидеть проблему за проблемой".
Концепция как раз и служит для того, чтобы помочь Заказчику выявить именно те
требования к системе, которые помогут ему оптимизировать работу своего предприятия в
долгосрочной перспективе.
Поэтому этап формирования концепции важен, но он предъявляет и к Заказчику и к
Исполнителю достаточно высокие требования: Заказчик должен выделить ресурсы и быть
готовым к трудозатратам на совместный поиск решений; Исполнитель должен обладать
достаточной квалификацией как в сфере IT-, так и в сфере управления предприятиями,
чтобы разрабатываемое средство автоматизации действительно принесло пользу. Все
вышесказанное ничуть не исключает возможность работы без концепции: либо речь идет о
небольшом проекте, закладывать в бюджет которого этап выработки концепции просто
нерентабельно, либо Заказчик сам обладает достаточной квалификацией, чтобы
сформулировать требования к АИС, имея "концепцию в голове" и время для
консультирования Разработчика.
Некоторые аргументы за разделение видения и границ были приведены выше. Провести
четкую границу между этими понятиями предлагает, в частности, процесс MSF. В
конечном итоге, вопрос "разделять или не разделять" определяется выбранной
методологией.
Рассмотрим основные требования к выработке концепции, заложенные в отечественных
ГОСТ, методологиях RUP и MSF.
1.10.2 Концепция в ГОСТ РФ
В соответствии с ГОСТ 34.601-90 "Автоматизированные системы. Стадии создания" [7.2],
после этапа формирования (выявления) требований к системе выполняется этап разработки
концепции системы.
Основные работы этапа:
Изучение объекта;
Проведение научно-исследовательских работ (НИР);
Разработка вариантов концепции АС;
Оформление отчета о выполненной работе.
Так как данный этап хронологически стоит на втором месте, к его началу у Разработчика
на руках уже имеется документ, в котором собраны основные требования пользователей.
Работы над концепцией начинаются с обследования объекта автоматизации. Выполняются
НИР, направленные на исследование принципиальной реализуемости требований и
возможных вариантов реализации.
ГОСТ, в отличие от большинства современных методологий, в общем случае закладывает
многоальтернативность вариантов концепции системы и планов их реализации. Каждый из
проработанных вариантов оценивается с позиций требуемых ресурсов и
функциональности. Для вариантов должны быть представлены оценки преимуществ и
недостатков. Полезность проработки нескольких вариантов концепции заключается в том,
что Заказчику трудно сформулировать самостоятельно видение системы, в то время, как
выбор из набора вариантов, представленных Разработчиком - вполне посильная задача.
Кроме того, концепция должна отражать оценки качества, условия приемки системы,
оценку эффекта, ожидаемого от реализации. При оформлении отчета необходимо привести
обоснование предлагаемого варианта.
1.10.3 Видение в RUP
Шаги, которые необходимо пройти для формирования документа "Видение":
Формулировка проблем.
Идентификация совладельцев
Определение границ системы
Идентификация ограничений
Формулировка постановки задач
Определение возможностей системы
Оценка результатов
Для описания проблем предлагается шаблон, показанный в табл. 7.1.
Таблица 7.1.
Проблема
(описание проблемы)
Затрагивает
(совладельцы, затрагиваемые проблемой).
Ее
(каково влияние проблемы).
следствием
является
Успешное
решение
(список некоторых ключевых преимуществ от успешного
решения).
Идентификация совладельцев предполагает поиск и фиксацию интересантов проекта представителей Заказчика и Исполнителя, инвесторов, внешних экспертов и пр.
Определение границ системы представляет собой нетривиальный процесс. Для этого
используют контекстные диаграммы [7.1] (см. материалы лекции 9). RUP в поиске
границ предлагает отталкиваться от акторов и вариантов использования.
Среди источников ограничений обычно выделяют:
Политические,
Экономические,
Среды,
Технические,
Выполнения,
Системные.
Описание возможностей системы представляет собой формулировку высокоуровневых
требований.
Шаблон документа "Vision" RUP содержит следующие основные разделы:
1. Введение
2. Позиционирование
3. Описания совладельцев и пользователей
4. Краткий обзор изделия
5. Возможности продукта
6. Ограничения
7. Показатели качества
8. Старшинство и приоритеты
9. Другие требования к изделию
10. Требования к документации
11. Приложение.
Во введении описываются цель документа, его контекст (связь и взаимовлияние с
различными проектами), определения, акронимы и сокращения, ссылки на другие
документы, краткое содержание.
В разделе "позиционирование" помещается определение решаемой проблемы (проблем),
указывается целевой заказчик и исследуются деловые преимущества изделия перед
аналогичными на рынке.
В описании совладельцев и пользователей, помимо собственно описания этих двух групп,
исследуется демография рынка: целевые рыночные сегменты, размер и темпы роста рынка,
существующие конкурентные предложения на рынке, репутация Разработчика на рынке.
Краткий обзор изделий содержит резюме изделия, описание его перспектив и ключевых
возможностей, предположения и зависимости, указывается стоимость и ее калькуляция,
рассматриваются вопросы лицензирования и инсталляции.
В разделе, посвященном возможностям продукта, они описываются более подробно,
каждая - в отдельном параграфе.
В раздел "Ограничения" следует выносить существующие технические, технологические и
др. обстоятельства, которые необходимо учитывать на данной стадии.
Раздел
"Показатели
качества"
нефункциональных
требований
отказоустойчивости и др.).
содержит
описание наиболее
к
системе
(эффективности,
существенных
надежности,
Раздел "Старшинство и приоритеты" ранжирует сформулированные ранее требования и
возможности системы по степени важности, очередности реализации и т.п.
Раздел "Другие требования к изделию" описывает применяемые стандарты, системные
требования, эксплуатационные требования, требования к окружающей среде.
В требованиях к документации приводятся ключевые характеристики руководства
пользователя, интерактивной справки, руководства по установке и конфигурированию,
файла Read Me.
В приложение выносятся атрибуты возможностей. RUP рекомендует следующий набор
атрибутов: статус, выгода, объем работ, риск, стабильность, целевой выпуск, назначение,
причина.
1.10.4 Видение / рамки в MSF
Согласно белой книге MSF [7.3], на фазе выработки концепции (envisioning phase)
закладывается одна из фундаментальных основ успеха проекта - создание и сплочение
проектной группы на основе выработки единого видения. Проектная группа должна
четко представить себе, что она хочет сделать для заказчика и сформулировать свою цель
таким образом, чтобы максимально мотивировать как заказчика, так и саму проектную
команду. Выработка высокоуровневого взгляда на цели и условия проекта может
рассматриваться как ранняя форма планирования; она подготавливает почву для процессов
создания детальных планов, которые будут осуществлены непосредственно во время фазы
планирования.
Основными задачами фазы выработки концепции являются создание ядра проектной
группы (см. ниже) и подготовка документа общего описания и рамок проекта
(vision/scope document). Формирование видения проекта и специфицирование его рамок не одно и тоже, хотя для успеха проекта необходимо и то, и другое. Видение (vision) - это
ничем не ограничиваемое представление о том, каким должно быть решение . Рамки
(scope) же дают четкие границы того, что из предложенного этим видением будет
реализовано в условиях существующих проектных ограничений.
Управление рисками представляет собой итеративный процесс, осуществляемый на
протяжении всего жизненного цикла проекта. Во время фазы выработки концепции
проектная группа готовит документ оценки рисков и представляет главные риски проекта
вместе с общим описанием и рамками проекта. Для получения дальнейшей информации об
управлении рисками, см. "Белую книгу" дисциплины управления рисками MSF.
Также во время фазы выработки концепции производится выявление и анализ бизнестребований. Более детально эти требования рассматриваются во время фазы
планирования.
Ведущим ролевым кластером на фазе выработки концепции является "Управление
продуктом".
Шаблон MSF содержит следующие разделы:
• Бизнес-преимущества,
Описание преимуществ
Формулировка видения
Анализ выгод
• Концепция решения
Цели, задачи, предположения и ограничения
Анализ применимости
Требования
• Рамки
Список характеристик/функций
Вне рамок
Стратегия подготовки релизов
Критерии применимости
Эксплуатационные критерии
• Стратегии проектирования решения
Стратегия проектирования архитектуры
Стратегия технического проектирования
1.11 Классификация и специфицирование требований
1.11.1 Акторы и варианты использования
Результатом выявления требований, см. лекцию 6 является реестр требований.
Требования совладельцев обычно оформляются в простой письменной форме, без какойлибо особой регламентации. Типовой пример оформления требования к программе
электронной почты - "Система должна позволять набирать текст сообщения с
возможностью форматирования текста и вставки смайликов". Данные требования далеко
не во всем могут удовлетворять критериям, сформулированным в лекции 3: они могут
противоречить друг другу, быть неясными, неточными и т.д. Тем не менее, документ
"Требования совладельцев", несмотря на невысокий уровень формализации, играет очень
важную роль: в нем собраны мнения всех заинтересованных сторон и главная цель сбора
начальных требований заключалась в том, чтобы получить по возможности как можно
более полный набор требований, не пропустив чего-то важного.
Для того, чтобы повысить уровень информативности требований, устранить взаимные
противоречия и добиться выполнения их других основных характеристик, осуществляется
переход от полностью неформализованных текстов к частично регламентированным
(например, шаблонами MS Word) текстам, классификация, присвоение наборов атрибутов,
построение моделей, прототипирование.
Самым популярным и весьма эффективным способом повышения информативности
требований является оформление их в виде вариантов использования (use case),
предложенный И.Якобсоном (см., например, [8.1]).
Прежде, чем приступить собственно к специфицированию требований в форме вариантов
использования, RUP рекомендует выявить реестр акторов1) (actors) и вариантов
использования.
Актор - это некто или нечто, обладающее активностью по отношению к программной
системе. Если вы разрабатываете простой текстовый редактор, то, скорее всего, выбор
актора не составит особого труда: это будет пользователь, набирающий текст. Однако не
всегда все так просто. Помимо пользователя в качестве актора может рассматриваться
другая программная система, аппаратное устройство, в ряде случаев - активная компонента
самой системы. Поиск акторов корпоративной информационной системы обычно сводится
к анализу ролей различных пользователей. Менеджер по продажам, старший менеджер и
начальник отдела продаж - один актор, два или три? Это зависит от их функциональных
обязанностей, разграничения доступа, способов использования информационной системы.
Поиск акторов может осуществляться, например методом мозгового штурма. В
дальнейшем при необходимости найденные акторы могут обобщаться, пересматриваться и
объединяться.
Вариант использования в первом приближении можно рассматривать, просто, как
функцию, реализуемую системой. Однако, современный взгляд на организацию бизнеса
говорит о том, что всякая функция должна иметь ценность для конечного потребителя
продукта или услуги. Философия варианта использования предполагает выделение среди
всего функционала системы подмножества, полезного конкретному конечному
пользователю (точнее говоря, типу конечного пользователя). Другая сторона - вариант
использования должен не только быть полезен, а еще и позволять получать КП конкретные
законченные результаты. Так, одной из функций текстового редактора, очевидно, является
создание пустого файла. Но вряд ли КП будет использовать редактор с целью изготовления
пустых файлов. Следовательно, создание пустого файла - функция, но не вариант
использования системы. Вариантом использования может быть, например, подготовка в
текстовом редакторе служебной записки. Вариант использования реализуется через
функции системы.
1.11.2 Глоссарий
Помимо формирования требований совладельцев другим результатом начальной фазы
выявления требований является концептуальный анализ проблемной области. Самым
первым результатом его является формирование глоссария (словаря) основных
используемых терминов. Значение глоссария трудно переоценить: он является основой,
ключом для единообразного понимания описаний требований Заказчиком и
Разработчиком.
Кроме того, глоссарий является отправной точкой для построения более развернутых
моделей проблемной области, которые, на стадии реализации информационной системы,
ложатся в основу объектной модели (для объектно-ориентированных приложений) и
модели данных (для генерации схемы базы данных).
Глоссарий оформляется, как текст, состоящий из абзацев, каждый из которых определяет
значение одного из терминов проблемной области. Термин обычно выделяют полужирным
кеглем. Иногда проблемную область целесообразно сегментировать на ряд "подобластей"
(subject areas). Тогда каждой из них в глоссарии выделяется отдельный параграф.
1.11.3 Спецификация варианта использования
Существуют различные шаблоны описания вариантов использования. Так, в монографии
[8.2] рассматриваются следующие основные стили описания:
Свободный формат,
Полный формат (предложенный А. Коберном),
Таблица в две колонки,
Таблица в три колонки,
Стиль RUP.
Кроме того, иногда целесообразно использовать:
Псевдокод,
Диаграмму активности UML (см. лекцию 9),
Другие графические модели.
Свободный формат
Свободный формат предполагает описание действий пользователя и системы в
повествовательном стиле, например: "Менеджер запрашивает у Системы список заказов за
период. Система отображает на экране найденные заказы данного Менеджера с указанием
их основных атрибутов". Свободный стиль допускает использование конструкций "Если
то". "Если Менеджер имеет полномочия Начальника Отдела, то Система предоставляет
возможность просмотра заказов всех менеджеров этого отдела".
Шаблон полного описания варианта использования
по А. Коберну
Название <краткая фраза в виде глагола в неопределенной форме совершенного вида,
отражающая цель>
Контекст использования <уточнение цели, при необходимости - условия ее нормального
завершения>.
Область действия <ссылка на рамки проекта>. Например - подсистема бухгалтерского
учета.
Уровень <один из трех: обобщенный, цели пользователя, подфункции>. Автор задает
предопределенную трехуровневую классификацию требований, в целом соответствующую
классификации требований на бизнес-требования, требования пользователей и
функциональные требования, см. лекцию 2.
Основное действующее лицо <имя роли основного актора или его описание>.
Участники и интересы <список других акторов-участников прецедента с указанием их
интересов>.
Предусловие <то, что ожидается, уже имеет место>.
Минимальные гарантии <что гарантируется акторам-участникам>. Например - в случае
неудавшейся транзакции все данные, имевшиеся в системе до ее начала, сохраняются
неизменными.
Гарантии успеха <что получат акторы-участники в случае успешного достижения цели>.
Триггер <то, что "запускает" вариант использования, обычно - событие во времени>.
Основной сценарий <здесь перечисляются шаги основного сценария, начиная от триггера
и вплоть до достижения гарантии успеха>.
Формат описания: <Номер шага> <Описание действия>
Расширения <здесь последовательно описываются все альтернативные сценарии>. Каждая
из альтернатив привязана к шагу основного сценария.
<Номер
шага.Номер
расширения>
<Условие>:<Действие или ссылка на подчиненный вариант
использования>.
Формат
описания:
Любой из шагов основного сценария может иметь 1 или более ветвлений. Каждое
ветвление оформляется в виде расширения. В блоке "Расширения" все расширения
описываются последовательно.
В случае, если альтернативный сценарий не удается описать одной строкой - применяется
следующий формат.
Начиная со строки, следующей после описания расширения, идет описание его действий в
формате основного сценария:
<Номер шага.Номер
<Действие>
расширения.Номер
шага
расширения>
Описание расширения заканчивается описанием выхода из расширения. Основные
варианты выхода из расширения: возврат к очередному по номеру шагу основного
сценария, окончание прецедента, переход к другому шагу основного сценария.
Список изменений в технологии и данных <что гарантируется акторам-участникам>.
Например - в случае неудавшейся транзакции все данные, имевшиеся в системе до ее
начала, сохраняются неизменными.
Вспомогательная информация <дополнительная информация, полезная при описании
варианта использования>.
Табличные представления варианта использования
Иногда представляется удобным помещать сценарии вариантов использования в таблицу,
как это показано ниже. Информация при этом принимает более структурированный вид.
Таблица 8.1. Таблица в 2 колонки:
Актор
Действие
Пользователь
Формирует запрос на поиск заказов
Система
Отображает список заказов
Пользователь
Выбирает требуемый заказ
Система
Показывает подробную информацию по заказу
Таблица 8.2. Таблица в 3 колонки:
№ шага
1
Пользователь
Система
Делает запрос на
Отображает список заказов
поиск заказов
2
Выбирает
требуемый заказ
Показывает
подробную
информацию по заказу
Шаблон варианта использования RUP
С шаблоном описания варианта использования RUP и примерами можно ознакомиться в
интерактивной версии RUP1).
Ниже приведен краткий обзор его разделов.
1. Наименования и краткое описание. В этом разделе указывается:
наименование варианта использования, акторы варианта использования, краткое
(в один абзац) описание варианта использования.
2. Поток событий
2.1. Основной поток событий
Так же, как в "Основной сценарий".
2.2. Альтернативные потоки событий
Каждый из альтернативных сценариев описывается в отдельном параграфе, в том же
стиле, что и основной поток событий. Альтернативные сценарии описывают
поведение системы при любых отклонениях от основного сценария, а также
поведение в исключительных ситуациях.
3. Специальные требования
Здесь перечисляются нефункциональные требования, имеющие непосредственное
отношение именно к этому варианту использования.
4. Предусловия
События, описываемые предусловиями или постусловиями, должны быть
состояниями, которые пользователь может наблюдать [8.3]. Предусловие
описывает состояние, в котором система должна находиться до начала исполнения
прецедента.
5. Постусловия
Постусловие RUP по сути описывает то же, что и минимальная гарантия у Коберна.
Л.Новиков [8.3] акцентирует внимание на том, что корректно сформулированное
постусловие должно быть истинным при любом возможном сценарии прецедента, а
не описанном в основном потоке.
6. Точки расширения
Данный параграф определяет положение точек, расширяющих поток событий.
1.12 Расширенный анализ требований. Моделирование
1.12.1 Какие модели использовать
Вербальные описания вариантов использования системы, рассмотренные в предыдущей
лекции, на сегодня являются стандартом де-факто для формулировки соглашения между
Заказчиком и Исполнителем. Если обе стороны готовы выделить достаточное количество
времени на внимательный и всесторонний анализ требований к системе и на начальной
фазе ее создания сформулировали 80% всех возможных сценариев использования системы
на понятном сторонами языке - значит, ключевые риски создания системы - риск
различного понимания проблемы и риск размытия границ во многом преодолены.
Однако, далеко не всякий Заказчик готов скрупулезно обсуждать скучные тома описания
вариантов использования, которые даже для систем среднего размера могут достигать
сотни страниц.
Чтобы облегчить процесс формулировки и понимания требований для Заказчика,
существует ряд приемов. Во-первых, требования можно формулировать на разных уровнях
абстракции. Так, уровень описания требований, поддерживаемый в документе "Видение",
является достаточно сбалансированным. То же можно сказать и про краткие (в один абзац)
описания ключевой функциональности системы. Действуя таким образом, мы, очевидно,
решим проблему вовлечения Заказчика в анализ задач, однако указанные выше риски
будут снижены недостаточно: концептуальные описания функциональности оставляют
много свободы для толкования в ту или иную сторону.
Хорошим подспорьем в решении задачи является применение визуальных средств
описания требований. Как известно, у большинства людей правополушарное (образное)
мышление позволяет воспринимать информацию в разы и порядки более ускоренном
темпе, чем левополушарное (вербальное).
На сегодня в арсенале аналитика существуют десятки методик, языков, визуальных
представлений, позволяющих моделировать требования к системе. При создании
информационных систем стандартом де-факто является универсальный язык
моделирования, UML [9.1,9.2]. Некоторые другие нотации были упомянуты в лекции 5.
Как уже отмечалось в лекции, посвященной анализу контекста АТ, процесс анализа
требований тесно связан, с одной стороны, с анализом проблемной области, с другой - с
архитектурным анализом и проектированием. Часто на практике бывает трудно вычленить
границы компетенций этих потоков работ. Так, модель анализ потоков данных, широко
используемая в анализе проблемной области, упоминается многими авторами, как модель,
полезная в анализе требований. Ряд исследователей считает целесообразным
иллюстрировать описания требований диаграммами классов, хотя, строго говоря,
выделение классов относится не к анализу требований, а к архитектурному анализу.
Как определить целесообразность использования тех или иных приемов, методик, языков
моделирования при анализе требований? Здесь можно предложить три практические
рекомендации.
Во-первых, анализ требований призван изучать взаимодействия автоматизированной
информационной системы и ее среды, т.е. пользователей, сетевых и системных компонент,
находящихся вне системы. Следовательно, бизнес-модели, описывающие взаимодействия
между компонентами организационной системы, строго говоря, можно рассматривать
лишь как "сырье" для извлечения требований, но не как модели, описывающие требования.
Во-вторых, анализ требований должен находить ответ на то, ЧТО делает система,
абстрагируясь от деталей реализации, т.е. того, КАК она это делает. Поэтому, допустим,
диаграмма взаимодействия объектов, реализующих тот или иной вариант использования,
можно рассматривать скорее, как иллюстрацию внутреннего устройства системы,
полезную для программиста, чем модель для заказчика.
Однако, наиболее важным является третье соображение, в чем-то "оппозиционное" по
отношению к первым двум. Для моделирования анализа требований следует применять
модели, наиболее адекватно проясняющие функциональность системы и особенности ее
использования. Однако, аналитик волен выбирать те языки и методики, которые позволят
добиться целевой функции: снижения рисков непонимания между Исполнителем и
Заказчиком и размытия границ. Поэтому, иллюстрируя варианты использования, начинайте
с "канонических" способов, которые будут рассмотрены чуть ниже, но, если посчитаете
целесообразным отклониться от них - экспериментируйте смело.
1.12.2 Модели UML, поясняющие функциональность
системы
Диаграмма вариантов использования
Диаграмма вариантов использования UML, Use Case Diagram - одно из самых простых
представлений системы. Ее базовые "строительные элементы" - акторы и варианты
использования. Диаграмма задумана так, чтобы дать наиболее общее представление о
функциональности системы (ее компоненты), не вдаваясь в детали взаимосвязей функций.
Поэтому основной вид отношения, используемый в диаграмме - ассоциация между актором
и вариантом использования.
Рис. 9.1.
Другие виды отношений - отношение включения (include), расширения (extend) и
обобщения/генерализации.
Включение служит для обозначения подчиненных вариантов использования (когда один
или более вариантов использования содержат вызовы одной и той же функциональности).
Рис. 9.2.
Расширение в точности соответствует точке расширения, используемой при описании
варианта использования, см. лекцию 8.
Рис. 9.3.
Отношение обобщения может применяться как к акторам, так и к вариантам
использования, с целью указания специализации одних относительно других.
Рис. 9.4.
Диаграмма действий
Если диаграмма вариантов использования дает "вид сверху" на функциональность
системы, диаграмма действий UML, напротив, позволяет подробно иллюстрировать
отдельный вариант использования и его сценарии.
Основные компоненты описания системы:
Функции (действия),
Символы "старт" и "стоп",
Потоки управления,
Разветвители,
Линейки синхронизации.
Рис. 9.5.
Диаграмма действий позволяет проиллюстрировать вариант использования с требуемой
степенью подробности. Линейный вариант использования приводит к диаграмме действий
с линейным потоком управления между действиями. Действия варианта использования с
альтернативными сценариями реализуется через разветвители. Линейки синхронизации
позволяют описывать такие сложные конструкции, как синхронизацию начала (окончания)
параллельных во времени процессов.
Помимо стандартного формата описания, UML предлагает вариант с "плавательными
дорожками". Этот формат удобен для описания случая, когда в варианте использования
участвуют несколько акторов.
Диаграмма состояний
Диаграмма состояний в анализе требований используется, когда требуется исследовать
поведение системы, как конечного автомата. Это представление пришло в UML из теории
систем.
В общем случае диаграмма состояний описывает, как система себя ведет в более, чем
одном варианте использования. Синтаксис диаграмм состояний во многом совпадает с
синтаксисом диаграмм действий.
Основные компоненты описания системы:
Простые состояния,
Составные состояния,
Символы "старт" и "стоп",
Переходы,
Линейки синхронизации.
В языке UML под состоянием понимается абстрактный метакласс, используемый для
моделирования отдельной ситуации, в течение которой имеет место выполнение
некоторого условия [9.2]. Состояние может быть задано в виде набора конкретных
значений атрибутов класса или объекта, при этом изменение их отдельных значений будет
отражать изменение состояния моделируемого класса или объекта.
Рис. 9.6.
Переход системы из состояния в состояние осуществляется при наступлении событий. При
этом говорится, что переход срабатывает. Переход может быть безальтернативным, либо
содержать альтернативы. Во втором случае переход обусловлен наступлением сторожевых
условий. Наконец, событие может сопровождаться выражением действия, которое
происходит в случае, если срабатывает переход. Полный синтаксис описания перехода
(надписи на стрелке) следующий:
Событие [сторожевое условие] / выражение действия
Иногда бывает полезным объединить часть состояний в одно мета-состояние. Графически
это выглядит, как символ состояния (прямоугольник со скругленными углами),
содержащий внутри себя несколько символов состояний. При этом возможны переходы
между подчиненными состояниями, переходы между подчиненным и внешним
состояниями и переходы между составным и внешним состоянием.
1.12.3 Диаграммы
устройство системы
UML,
поясняющие
внутреннее
Некоторые авторы [9.3] рекомендуют использовать при описании требований диаграммы
UML, описывающие создаваемую систему через ее компоненты (классы, объекты),
отношения и взаимодействия между ними. Данный подход имеет свои ограничения (см.
Принцип 2).
Диаграмма классов
Для создания диаграммы классов необходимо:
1. Осуществить поиск классов (ключевых компонент проблемной области).
2. Для каждого найденного класса определить его имя, основные атрибуты,
операции и (или) ответственности.
3. Исследовать отношения найденных классов.
Классы на диаграмме представляются в виде прямоугольников, отношения - в виде линий,
связывающих прямоугольники. Линии разного типа графически отличаются различной
штриховкой и стрелками.
Принято выделять [9.1] 3 уровня абстракции классов:
концептуальный уровень,
уровень спецификации,
уровень реализации.
Анализ требований разумно сопровождать диаграммами, отражающими концептуальный
уровень. На данном уровне при описании классов целесообразно указать их наименования
и ответственности. Атрибуты и операции можно не указывать, либо ввести только самые
основные, отложив их исследование на более поздние стадии детализации.
Отношения, подлежащие анализу на концептуальном уровне - это:
Рис. 9.7.
Диаграмма классов показывает статическую структуру проблемной области. Для анализа
взаимодействия объектов - экземпляров класса в ходе реализации варианта использования
в UML предусмотрены две диаграммы взаимодействия: диаграмма кооперации и
диаграмма последовательности.
По мнению автора, если диаграмма классов в ряде случаев и может рассматриваться, как
артефакт, поясняющий структуру проблемной области, то диаграммы взаимодействия вряд
ли стоит рассматривать в качестве выразительного языкового средства, иллюстрирующего
требования к системе в диалоге "Заказчик-Исполнитель". Тем не менее, в соответствие с
Принципом 3 свободы выбора языковых средств, аналитик, решивший использовать
данные диаграммы, может ознакомиться с ними в специальной литературе [ 9.1-9.2].
1.12.4 Альтернативные языки моделирования
Диаграмма потоков данных
Диаграмма потоков данных (data flow diagram, DFD) - один из основных инструментов
структурного анализа и проектирования информационных систем, существовавших в
"доюмээльную" эпоху. Несмотря на имеющее место в современных условиях смещение
акцентов от структурного к объектно-ориентированному подходу к анализу и
проектированию систем, "старинные" структурные нотации по-прежнему широко и
эффективно используются как в бизнес-анализе, так и в анализе информационных систем.
Исторически сложилось так, что для описания диаграмм DFD используются две нотации Йодана (Yourdon) и Гейна-Сарсона (Gane-Sarson), отличающиеся синтаксисом. На
приведенной ниже иллюстрации использована нотация Гейна-Сарсона.
Рис. 9.8.
Информационная система принимает извне потоки данных. Для обозначения элементов
среды функционирования системы используется понятие внешней сущности. Внутри
системы существуют процессы преобразования информации, порождающие новые потоки
данных. Потоки данных могут поступать на вход к другим процессам, помещаться (и
извлекаться) в накопители данных, передаваться к внешним сущностям.
Модель DFD, как и большинство других структурных моделей - иереархическая модель.
Каждый процесс может быть подвергнут декомпозиции, т.е. разбиению на структурные
составляющие, отношения между которыми в той же нотации могут быть показаны на
отдельной диаграмме. Когда достигнута требуемая глубина декомпозиции - процесс
нижнего уровня сопровождается мини-спецификацией (текстовым описанием).
Кроме того, нотация DFD поддерживает понятие подсистемы - структурной компоненты
разрабатываемой системы.
Нотация DFD - удобное средство для формирования контекстной диаграммы, т.е.
диаграммы, показывающей разрабатываемую АИС в коммуникации с внешней средой. Это
- диаграмма верхнего уровня в иерархии диаграмм DFD. Ее назначение - ограничить рамки
системы, определить, где заканчивается разрабатываемая система и начинается среда.
Другие нотации, часто используемые при формировании контекстной диаграммы диаграмма SADT1), диаграмма Диаграмма вариантов использования.
Другие виды моделей
Среди многообразия моделей, использующихся в анализе систем, хочется особо отметить
еще две нотации, позволяющие описать сложные многоальтернативные взаимодействия
компонент информационной системы - нотацию IDEF3 [9.4] и ee PC-диаграмму ARIS
[9.6].
Для моделирования требований к системам с разветвленной логикой К.Вигерс рекомендует
использовать таблицы и деревья решений [Вигерс]. Часто на практике бывают полезны
диаграммы сущность-связь и SADT-диаграммы [Маклаков].
1.13 Расширенный анализ требований. Иллюстрированные
сценарии и прототипы
Вы действительно хотите, чтобы я поставил свою подпись под этим документом?
- Разумеется, ведь в нем сосредоточено развернутое описание основных требований к
автоматизированной информационной системе, которую мы должны для вас создать.
- Хорошо, я подпишу, но это ровным счетом ничего не значит.
- ??
- Ведь это всего лишь бумага, слова… А мне нужна программа, которая реально облегчит
жизнь сотрудникам моего предприятия. Подпишу я сейчас документ или не подпишу - не
имеет никакого значения. Важно лишь - сможете Вы или нет сделать такую систему,
которая действительно принесет пользу. А это выяснится лишь, когда я смогу ее
"пощупать".
Такой или примерно такой диалог состоялся у автора с генеральным директором
полиграфического предприятия - заказчиком системы комплексной автоматизации его
деятельности при подписании эскизного проекта.
И эта ситуация - не нонсенс. Каждый, кто выполнял проекты автоматизации рано или
поздно сталкивается с ней. Что же делать - отказываться от выгодного проекта? Или взять
на себя риск, что проект не будет принят в эксплуатацию: ведь при таком подходе к
документу описания требований наверняка найдется что-то, очевидное для Заказчика,
неожиданное для Исполнителя и не вошедшее в ТЗ. Хорошо, если придется переделывать
5% функций. А что, если 30% или 50%?
К счастью, выход существует. И этот выход - создание прототипов. Прототипы позволяют
увидеть за сухими строчками документа описания требований фрагменты реальной
системы, "поиграть" в эксплуатацию системы до ее создания.
1.13.1 Цели прототипирования
Все то, что говорилось в предыдущей лекции об особенностях восприятия человеком
вербальной и невербальной информации по отношению к моделям, в еще большей степени
следует отнести и к визуальным прототипам.
Рассмотрим основные цели, требующие применения прототипов [10.1-10.2]:
прояснить неясные требования к системе;
выбрать одно из различных концептуальных решений;
проанализировать осуществимость.
1. Неясные требования. Часто Заказчику бывает трудно сформулировать
требования к тому, что он ожидает от системы. В этом случае прототип
интерфейса пользователя (User Interface, UI), оперативно созданный по
результатам интервью, дает ему возможность увидеть схематичную реализацию
того, как Исполнитель увидел соответствующую часть системы. Что интересно - в
данном случае полезен любой исход прототипирования: если Исполнитель понял
требования хорошо - польза очевидна; если не очень - польза заключается в том,
что Заказчик может указать, в чем заключается непонимание, тем самым решив
основную задачу - сделать неясное ясным.
2. Разные варианты решения. Любую техническую задачу можно решить
различными способами. Это касается как задачи формулировки требований, так и
ее реализации в UI.
Рассмотрим пример. Снабженцу поступает входной поток требований на
комплектацию заказов материалами. Разные позиции одного и того же требования
могут быть закуплены у различных поставщиков. Снабженец должен сопоставить
поставщика каждой позиции каждого из требований. Есть как минимум два
сценария решения этой задачи.
А) Сценарий последовательной обработки требований.
o
o
А1. Система отображает реестр требований, имеющихся во входной
очереди.
А2. Пользователь выбирает очередное требование.
o
o
o
o
А3. Система отображает перечень материалов требования и справочник
поставщиков.
А4. Пользователь сопоставляет каждой из позиций требования поставщика
из справочника поставщиков.
А5. Система придает требованию статус "обработано", высылает по
электронной почте автору требования уведомление.
А6. Продолжать с шага А1, пока очередь не опустеет.
Б) Сценарий группировки по материалам.
o
o
o
o
o
Б1. Система отображает позиции всех требований и справочник
поставщиков.
Б2. Пользователь группирует позиции по типу (так, чтобы однотипные
позиции, поставляемые одним и тем же поставщиком, находились рядом).
Б3. Пользователь выбирает группу позиций и сопоставляет ей поставщика.
Б4. Система проверяет - не появились ли полностью обработанные
требования. При положительном исходе проверки присваивает этим
требованиям статус "обработано" и высылает по электронной почте автору
требования уведомление.
Б5. Продолжать с шага Б1, пока очередь не опустеет.
Первый сценарий удобен тем, что позволяет снабженцу работать в разрезе авторов
требований, начать с самых критичных по времени требований, контролировать
процесс их обработки. Второй сценарий удобен тем, что позволяет одновременно
наблюдать на экране строки разных требований, объединяя их в единый заказ.
После реализации прототипов UI по первому и второму сценариям Заказчик, оценив
их достоинства и недостатки, смог в диалоге с Разработчиком сформулировать
третий, комбинированный сценарий, сочетающий достоинства первых двух.
3. Анализ осуществимости. Часто бывает так, что комбинация функциональных,
нефункциональных требований и ограничений такова, что возникает риск
невозможности их реализации. Как правило, такой риск связан с требованиями к
быстродействию системы при известных ограничениях среды ее реализации. В
этом случае создаются прототипы (не обязательно, связанные с UI), реализующие
соответствующую часть системы, имитирующие потоки данных, поступающие на
ее вход и их обработку.
1.13.2 Классификация прототипов
Вслед за К. Вигерсом [10.2] рассмотрим следующие классификации прототипов:
горизонтальные и вертикальные;
одноразовые и эволюционные;
бумажные и электронные, раскадровки1).
Горизонтальный прототип
Горизонтальный или поведенческий прототип (horizontal prototype, behavioral prototype)
моделирует интерфейс пользователя приложения, не затрагивая логику обработки и базу
данных.
Если в разработанном интерфейсе используются фрагменты базы данных - они
имитируются в программном коде. При этом тексты, отображаемые на экране, должны
отражать реальную специфику проблемной области, иначе пользователю будет трудно
сосредоточиться. Если при нажатии на элемент управления должны производиться какието расчеты или запросы во внешние системы - результаты запросов также имитируются.
Желательно реализовать ту часть кода, которая отвечает за перемещение между экранами в
процессе исполнения вариантов использования, чтобы пользователь смог понять, как будет
действовать система в ответ на его действия.
Горизонтальные прототипы следует использовать для достижения цели прояснения
неясных, либо многоальтернативных требований.
Вертикальный прототип
Вертикальный или структурный прототип (vertical prototype, structural prototype) не
ограничивается интерфейсом пользователя. Он реализует вертикальный "срез" системы,
затрагивая все уровни ее реализации. При создании такого рода прототипов рекомендуется
использовать те языки и среды реализации, что и при изготовлении целевой системы (что,
вообще говоря, совсем не обязательно для горизонтальных прототипов).
Основные цели применения такого рода прототипов - анализ применимости, проверка
архитектурных концепций.
Одноразовый прототип
Одноразовый или исследовательский прототип (throwaway prototype, exploratory prototype)
создается, когда нужно быстро промакетировать те или иные аспекты и компоненты
системы.
Целям создания исследовательских прототипов служит технология RAD (rapid application
development) - быстрая разработка приложений , см. лекцию 6.
Одноразовый прототип должен создаваться быстро. При его разработке не следует уделять
внимание вопросам повторного использования кода, качества, быстродействия,
технологичности и т.п.
В результате получается "сырой" код, который может содержать значительное количество
дефектов. Необходимо принять меры к тому, чтобы фрагменты кода, реализующие такого
рода прототипы, не стали частью целевой системы.
К. Вигерс приводит следующую схему перехода от одноразового прототипа к детально
проработанному UI:
увеличить
изображение
Рис. 10.1.
На рисунке присутствует новое, не раскрытое ранее понятие: "карта диалога", говорят
также "схема диалога". Прежде, чем создавать горизонтальный прототип, необходимо
определиться - какие основные экраны будут присутствовать, какие окна будут
открываться, какие правила перехода между ними будут поддерживаться. Информация
такого рода хорошо ложится на модель диаграммы состояний, см. лекцию 9., где разным
экранам (окнам) сопоставляются состояния, а активным элементам управления,
вызывающим закрытие одних интерфейсных элементов и открытие других - переходы.
Эволюционный прототип
Эволюционный прототип (evolutionary prototype) создается, как первое приближение
системы, призванное стать впоследствии самой системой.
Код эволюционного прототипа должен последовательно, в течении одной или более
итераций, перерасти в код целевого приложения. Поэтому данный вид прототипов требует
всего того, от чего следует отказаться при создании одноразовых прототипов:
скрупулезной разработки, применения технологических методов и приемов, тестирования
результатов и т.п.
В таблице приведено соотношение между рассмотренными выше 4 видами прототипов
[10.2].
Таблица 10.1.
Одноразовые
Горизонт
альные
Вертикал
ьные
Эволюционные
Прояснение и уточнение
примеров использования и
функциональных
требований
Выявление пропущенных
требований
Исследование возможных
вариантов интерфейса
пользователя
Демонстрация технической
осуществимости
Реализация базовых
вариантов использования
Реализация дополнительных
вариантов использования по
приоритетам
Реализация и доработка webсайтов
Адаптация системы к быстро
меняющимся требованиям
бизнеса
Реализация и наращивание
ключевой клиент-серверной
функциональности и уровней
коммуникации
Реализация и оптимизация
основных алгоритмов
Тестирование и настройка
производительности
Бумажный прототип
Бумажный прототип (paper prototype) - отличная альтернатива рассмотренным выше
разновидностям электронных прототипов в случае, когда Разработчик ограничен в
ресурсах. Наброски интерфейсов на бумаге, конечно, не заменят интерфейс, созданный в
среде разработки. Однако, при всех недостатках, у таких прототипов есть два
существенных достоинства.
1. Заказчик не станет акцентировать внимание на цветовом решении, форме кнопок
и т.п., отвлекаясь от анализа функциональности.
2. Заказчик никогда не скажет, глядя на бумажный интерфейс: "Да вы, я вижу, уже
создали систему на 85%! Давайте закончим ее в течении недели".
Раскадровка
Решением промежуточного между электронным и бумажным вариантами прототипов UI
класса, является презентации, изготовленные при помощи средств электронного офиса
(например, комбинации Microsoft Visio и Microsoft PowerPoint). В этом случае
пользователь лишен свободы выбора, предоставляемой ему поведенческим прототипом. Но
идею пошаговой смены экранов в процессе реализации сценария варианта использования
вполне можно реализовать. Данный вид решения определяется в [10.3], как пассивная
раскадровка. Активная раскадровка является дальнейшим развитием понятия пассивной
раскадровки, с применением средств анимации и т.п. Третий вид раскадровки, вводимый в
[10.3] - интерактивная представляет собой электронный одноразовый горизонтальный
прототип.
1.13.3 Иллюстрированные сценарии прецедентов
Иллюстрированные сценарии прецедентов, ИСП [10.4], наряду с прототипами позволяют
достичь лучшего понимания между Заказчиком и Разработчиком. Но если прототипы
адресованы скорее Заказчику, нежели Разработчику, то с ИСП ситуация обстоит наоборот:
они содержат дополнительные сведения, помогающие Разработчику лучше понять
специфику проблемной области и, тем самым, лучше отразить ее в интерфейсе
пользователя.
Основная идея ИСП - "разбавить" текст описания сценария варианта использования
аспектами применимости.
Аспект применимости - информация, позволяющая расширить описание прецедента
описаниями, конкретизирующими те или иные его особенности и, в конечном итоге,
повысить степень комфортности пользователя.
Различают [10.4] 3 разновидности аспектов применимости: ориентиры, средние значения
атрибутов и объемы объектов, средняя интенсивность использования.
Ориентиры
Ориентиры - это описание опциональных функциональных возможностей системы.
Отсутствие таких возможностей не приводит к фатальной неудаче. Присутствие - улучшает
применимость, снабжая полезной информацией. Ориентиры следует расценивать не как
требования, а как пожелания или рекомендации.
Пример. Описание потока событий ИСП для прецедента "Оформить заказ", расширенного
ориентирами (текст в квадратных скобках).
В процессе выполнения прецедента менеджер по приему заказов выбирает заказчика из
клиентской базы, определяет товарные позиции из справочника и указывает их количество.
Система отображает на мониторе наименование позиций, цену, сумму и количество на
складе. Менеджер назначает скидку и определяет порядок оплаты. Система рассчитывает
итоговую сумму. [Менеджер должен иметь возможность видеть текущее сальдо расчетов с
клиентом и данные по последним десяти сделкам со статистикой по дисциплине
соблюдения договорных обязательств].
Средние значения атрибутов и объемы объектов
Данная информация позволяет оптимальнее построить пользовательский интерфейс и
оценить на ранних стадиях проекта "узкие места" в обработке данных, которые могут
повлиять на производительность системы.
Так, при выборе из 2 возможностей лучше подойдет элемент управления checkbox, при
выборе, ограниченном 2-3 десятками позиций - выпадающий список, при многообразии,
измеряемом тысячами вариантов, потребуются дополнительные средства фильтрации и
поиска.
Пример. Описание потока событий ИСП для прецедента "Оформить заказ", расширенного
объемами и средними значениями объектов (текст в фигурных скобках).
В процессе выполнения прецедента менеджер по приему заказов выбирает заказчика из
клиентской базы {до 10000 клиентов}, определяет товарные позиции из справочника
{товары разбиты на 10 категорий, количество позиций в категории не превышает 500} и
указывает их количество {до 100 позиций, средняя закупка - 8 позиций}. Система
отображает на мониторе наименование позиций, цену, сумму и количество на складе.
Менеджер назначает скидку и определяет порядок оплаты {на данный момент существуют
3 варианта порядка оплаты}. Система рассчитывает итоговую сумму.
Средняя интенсивность использования
Средняя интенсивность использования позволяет выделить сценарии "массового"
использования, в которых все должно быть идеально (быстродействие, удобство
пользования, минимум действий на выполнение операций). Например - интерфейс кассира
в супермаркете. Другая крайность - сценарии, выполняемые от случая к случаю, не каждый
день и не требующие особой оперативности (например, расчет заработной платы за месяц).
Эти данные позволяют, структурировать подачу информации, убрать из "главных"
интерфейсов редко используемые опции и т.п.
Пример. Фрагмент описания потока событий ИСП для прецедента "Оформить заказ для
нового клиента", расширенного объемами и средними значениями объектов (текст в
круглых скобках).
В процессе выполнения прецедента менеджер по приему заказов выбирает заказчика из
клиентской базы (в 95% случаев), либо вызывается интерфейс регистрации нового клиента
(в 5% случаев).
1.14 Документирование требований
Чтобы требования, выявленные и описанные (см. лекциию 6 и лекцию 8) приняли силу
соглашения между Заказчиком и Разработчиком, их необходимо оформить в виде
документа. В российской практике для этого обычно используется документ "Техническое
задание", ТЗ, в западной - "Software Requirements Specification", SRS (спецификация
программных требований). По сути это - один и тот же документ, поэтому далее по тексту
будем употреблять термин "ТЗ", рассматривая различные шаблоны его построения - как на
основе российских ГОСТ, так и западных методологий и стандартов.
1.14.1 Документирование требований в соответствие
с ГОСТ РФ
Документирование
требований
регламентировано
российскими
ГОСТ
19.201-78
"Техническое задание, требования к содержанию и оформлению" и ГОСТ 34.602-89
"Техническое задание на создание автоматизированной системы" (ТЗ на АС) [11.4-11.5].
Второй документ, по сути, является более проработанной версией первого, адаптированной
к созданию автоматизированных информационных систем, поэтому далее рассмотрена
структура ТЗ в соответствие с ГОСТ 34.602-89.
Несмотря на то, что для сферы IT 17 лет - это целая эпоха, данный документ практически
не устарел: его авторам удалось разработать сбалансированные рекомендации,
абстрагируясь от конкретных технических и технологических решений. Кроме того, он попрежнему играет роль государственного стандарта РФ и при заключении контрактов с
государственными предприятиями Разработчика могут обязать оформить ТЗ в
соответствии с духом и буквой этого документа.
Структура ТЗ в соответствие с ГОСТ 34.602-89
В задачи лекции не входит перечисление всех правил и рекомендаций данного ГОСТ,
желающие могут ознакомиться с ним непосредственно. Ниже будут перечислены разделы,
предусмотренные ГОСТ и рассмотрены основные моменты, на которые следует обратить
внимание.
Общие сведения - в этом разделе, помимо юридических реквизитов сторон и прочей
деловой информации ГОСТ рекомендует указать источники и порядок финансирования
работ.
Назначение и цели создания (развития) системы - здесь необходимо указать показатели
объекта автоматизации, которые должны быть достигнуты и критерии оценки достижения
этих показателей. Данным разделом на практике часто пренебрегают и совершенно
напрасно - ведь именно в этом разделе закладываются высокоуровневые бизнес-требования
и формулируются критерии их достижения.
Характеристика объектов автоматизации - достаточно важный раздел. Его основные
"разрезы" - организационная структура, структура управления, структура расположения
предприятия и его филиалов. Хорошее описание объекта автоматизации позволяет
сэкономить время на определение классов пользователей, для крупных территориальнораспределенных систем - заложить структуру и топологию сетевых коммуникаций.
Требования к системе - ключевой раздел настоящего документа, поэтому он будет
рассмотрен ниже, более подробно.
Раздел "Состав и содержание работ по созданию системы", говоря современным
языком, описывает процесс создания системы, включая выбор методологии,
определяющий содержание стадий, этапов и фаз и его конкретизацию для проекта
(количество этапов и итераций, их основное содержание).
Порядок контроля и приемки системы - также один из ключевых компонент ТЗ. Он
распределяет роли Заказчика и Разработчика в подготовке системы к испытаниям и
проведению испытаний. Здесь уместно оговорить правила проведения испытаний,
сформулировать основные тестовые сценарии и критерии приемки.
Требования к составу и содержанию работ по подготовке объекта автоматизации к
вводу системы в действие, опять же, аппелируя к современной терминологии,
оговаривают порядок проведения реинжиниринга предприятия, который необходимо
осуществить для того, чтобы добиться от внедрения АИС должного эффекта (подбор и
обучение персонала, изменения в организационной структуре и т.п.).
Документ заканчивается разделами "требования к документированию" и "источники
разработки", определяющими, соответственно, перечень и формы документации,
подлежащей разработке и перечень уже имеющихся документов, содержащих предпосылки
для разработки.
В качестве приложений ГОСТ рекомендует использовать расчет
эффективности системы и оценку научно-технического уровня системы.
ожидаемой
Описание требований к системе в соответствие с
ГОСТ 34.602-89
ГОСТ разделяет все требования к системе на три класса:
требования к системе в целом;
требования к функциям (задачам), выполняемым системой;
требования к видам обеспечения.
Среди требований к системе в целом (системные требования) указываются требования к:
структуре системы (здесь закладываются высокоуровневые архитектурные
решения, либо структурные ограничения, вводится деление на подсистемы,
комплексы и модули, решаются вопросы коммуникации компонент системы и
системы с внешним миром),
режимам функционирования системы;
персоналу (указывается численность, требуемая квалификация и режим работы);
надежности;
безопасности;
эргономике и технической эстетике;
транспортабельности для подвижных АС;
эксплуатации, техническому обслуживанию, ремонту и хранению компонентов
системы;
защите информации от несанкционированного доступа;
сохранности информации при авариях;
защите от влияния внешних воздействий;
патентной чистоте;
стандартизации и унификации,
а также показатели назначения (параметры, характеризующие степень соответствия
системы ее назначению) и дополнительные требования (распространяются на обучающие
подсистемы, средства контроля работоспособности системы и др.).
Требования ГОСТ к функциям (задачам), в переводе на современный язык, подразделяются
на:
перечень функциональных требований в привязке к подсистемам и очередям
автоматизации;
временной регламент реализации функциональных требований;
требования к качеству реализации каждого из функциональных требований (в
том числе - форме представления выходной информации, характеристики
необходимой точности и времени выполнения, требования одновременности
выполнения группы функций, достоверности выдачи результатов);
перечень и критерии отказов для каждого функционального требования, по
которому были заданы требования по надежности.
Требования к видам обеспечения. Среди видов обеспечения ГОСТ указывает
математическое, информационное, лингвистическое, программное, техническое,
метрологическое, организационное, методическое.
1.14.2 Документирование требований в RUP
Шаблон SRS, предложенный в RUP1), по сути представляет собой контейнер, в который
необходимо "упаковать" артефакты, полученные в процессе специфицирования требований
(см. материалы лекции 8). Кроме того, SRS частично перекликается с документом
"Видение" (см. материалы лекции 7). Шаблон удобен своей компактностью и
лаконизмом.
1. Введение.
1.1. Цель. Документ должен исчерпывающим образом описывать внешнее
поведение системы, а также нефункциональные требования и ограничения.
1.2. Краткая сводка возможностей.
1.3. Определения, акронимы и сокращения.
1.4. Ссылки.
1.5. Краткое содержание.
2. Обзор системы
2.1. Обзор прецедентов. Содержит список имен и кратких описаний вариантов
использования и акторов с иллюстрациями в виде диаграмм прецедентов.
2.2. Предположения и зависимости. Данная секция описывает ключевые
технические возможности, компоненты, подсистемы, связанные проекты, которые
могут влиять на жизнеспособность разрабатываемой системы.
Предположением (assumption) называется положение, которое считается истинным
при отсутствии доказательства или определяющей информации. [1].
При определении зависимостей (dependencies) проекта от внешних факторов,
необходимо проанализировать, какие новые операционные системы, регламенты
бизнес-процессов, стандарты качества, информационные системы могут появиться
на предприятии внедрения и как это может повлиять на функционирование
изготовляемой АИС.
3. Описание требований
3.1. Описание вариантов использования. Параграф содержит описание вариантов
использования и связанных с ними нефункциональные требований, либо ссылки на
соответствующие артефакты.
3.2. Специальные требования. Параграф содержит описание функциональных
требований (не описанных, как варианты использования), а также описание
нефункциональных требований общего характера (не сопоставленных ни одному
прецеденту в предыдущем разделе), либо ссылки на соответствующие артефакты.
4. Вспомогательная информация. Сюда включается информация, облегчающая
понимание документа. Это может быть оглавление и приложения, например,
описывающие прототипы пользовательского интерфейса.
1.14.3 Документирование требований на основе IEEE
Standard 830-1998
Рассмотрим шаблон документа описания требований, составленный К.Вигерсом [11.1] на
основе стандарта [11.2]. Данный стандарт содержит развернутое описание требований,
которое может быть оптимизировано для нужд конкретной организации.
1. Введение
1.1 Назначение документа.
1.2. Поддерживаемые соглашения.
1.3. Предполагаемая аудитория и рекомендации по последовательности работы с
документом для каждого класса читателей.
1.4. Границы проекта. Здесь содержится ссылка на документ "Концепция", если
таковой имеется, либо краткое резюме продукта.
1.5. Ссылки.
2. Общее описание.
2.1. Общий взгляд на продукт. Здесь необходимо определить - является ли
описываемый продукт новым членом растущего семейства продуктов, новой
версией существующей системы, заменой существующего приложения или
совершенно новым продуктом. Если спецификация требований определяет
компонент более крупной системы, укажите, как это ПО соотносится со всей
системой и определите основные интерфейсы между ними.
2.2. Особенности продукта. Перечисляются ключевые особенности продукта или его
главные свойства. Здесь уместно поместить контекстную диаграмму (в виде
диаграммы вариантов использования, потоков данных или др. спецификаций).
2.3. Классы и характеристики пользователей. Документируется процесс поиска
акторов, в котором выявляются все пользователи системы и осуществляется
обобщение (выделение классов) пользователей. Найденные классы описываются
(например - уровень квалификации, доступный функционал и т.д.).
2.4. Операционная среда. Рассматривается среда функционирования АИС, включая
аппаратные средства, операционные системы, для распределенных систем географическое расположение пользователей и серверов, топология сети.
2.5. Ограничения проектирования и реализации. Рассмотрим классификацию
ограничений [11.1]:
o
o
определенные технологии, средства, языки программирования и базы
данных, которые следует использовать или избегать;
ограничения, налагаемые операционной средой продукта;
o
o
o
o
o
o
обязательные соглашения или стандарты разработки;
обратная совместимость с продуктами, выпущенными ранее;
ограничения, налагаемые бизнес-правилами;
ограничения, связанные с оборудованием, например требования к
быстродействию, ограничения памяти или процессора;
соглашения, связанные с пользовательским интерфейсом существующего
продукта, которые необходимо соблюдать при его улучшении
форматы и протоколы обмена данными.
2.6 Документация для пользователей.
2.7 Предположения и зависимости
3. Функции системы
Для каждой i-й функции составляется следующее описание.
З.i Наименование i-й функции системы.
З.i.1 Описание и приоритеты. Приводится краткое описание функции и указывается
ее приоритет (степень важности/очередности реализации).
З.i.2 Последовательности "воздействие - реакция". Необходимо перечислить
последовательность воздействий, оказываемых на систему (действия пользователей,
сигналы внешних устройств и др.), и отклики системы, определяющие реакцию
конкретной функции.
З.i.З Функциональные требования. Необходимо дать детализацию i-й функции,
перечислить детализированные функциональные требования, включая реакцию на
ожидаемые ошибки и неверные действия. Каждому детальному функциональному
требованию присваивается уникальный идентификатор.
1.14.4 4. Требования к внешнему интерфейсу
Ниже рассмотрены конкретные рекомендации по написанию разделов этого параграфа,
согласно [11.1]:
4.1 Интерфейсы пользователя
Основные характеристики UI:
ссылки на стандарты графического интерфейса пользователей или стилевые
рекомендации для семейства продукта, которые необходимо соблюдать;
стандарты шрифтов, значков, названий кнопок, изображений, цветовых схем,
последовательностей полей вкладок, часто используемых элементов управления
и т.п.;
конфигурация экрана или ограничения разрешения;
стандартные кнопки, функции или ссылки перемещения, одинаковые для всех
экранов, например кнопка справки;
быстрые клавиши;
стандарты отображения сообщений;
стандарты конфигурации для упрощения локализации ПО;
специальные возможности для пользователей с проблемами со зрением.
4.2 Интерфейсы оборудования
Опишите характеристики каждого интерфейса между компонентами ПО и оборудования
системы. В описание могут входить типы поддерживаемых устройств, взаимодействия
данных и элементов управлений между ПО и оборудованием, а также протоколы
взаимодействия, которые будут использоваться.
4.3 Интерфейсы ПО
Опишите соединения продукта и других компонентов ПО (идентифицированные по имени
и версии), в том числе базы данных, операционные системы, средства, библиотеки и
интегрированные коммерческие компоненты. Укажите назначение элементов сообщений,
данных и элементов управления, обмен которыми происходит между компонентами ПО.
Опишите службы, необходимые внешним компонентам ПО, и природу взаимодействия
между компонентами. Определите данные, к которым будут иметь доступ компоненты ПО.
4.4 Интерфейсы передачи информации
Укажите требования для любых функций взаимодействия, которые будут использоваться
продуктом, включая электронную почту, Web-браузер, протоколы сетевого соединения и
электронные формы. Определите соответствующие форматы сообщений. Опишите
особенности безопасности взаимодействия или шифрования, частоты передачи данных и
механизмов синхронизации.
1.14.5 5. Другие нефункциональные требования
В этом разделе описываются остальные нефункциональные требования, не относящиеся к
требованиям к интерфейсу, которые представлены в разделе 4, и к ограничениям,
описываемым в разделе 2.5.
5.1 Требования к производительности
Укажите специальные требования к производительности для различных системных
операций. Обоснуйте их необходимость для того, чтобы помочь разработчикам принять
правильные решения, касающиеся дизайна. Например, из-за жестких требований к времени
отклика базы данных разработчики могут зеркализовать базу данных в нескольких
географических метаположениях или денормализовать связанные таблиц баз данных для
получения более быстрого ответа на запрос.
Приложение А. Словарь терминов (глоссарий).
Приложение Б. Модели анализа. В этот раздел помещаются все модели,
построенные в процессе анализа требований (см. материалы лекции 9).
Приложение В. Список вопросов.
Это динамический список еще не разрешенных проблем, связанных с требованиями.
Это могут быть элементы, помеченные как "ТВD" (to be determined - необходимо
определить), отложенные решения, необходимая информация, неразрешенные
конфликты и т.п.
1.14.6 Документирование требований в MSF
В начале фазы проектирования проектная группа работает с проектными требованиями.
Они подразделяются на:
бизнес-требования,
требования к эксплуатации,
системные требования,
требования пользователя.
Одним из основных результатов фазы проектирования является функциональная
спецификация, которая служит:
инструкцией команде разработчиков о том, что они должны будут создать;
основой для оценки объема работ;
четкое соглашение с Заказчиком о том, что должно быть сделано;
основой для синхронизации работы всей проектной команды.
С шаблонами соответствующих документов можно ознакомиться на сайте Microsoft,
[11.3].
1.15 Проверка требований
1.15.1 Верификация и валидация
Термин "верификация" (verification) в русскоязычной литературе обычно переводят, как
"проверка". Термин
"утверждение".
"валидация"
-
как
"проверка
правильности",
"аттестация",
Согласно стандарту IЕЕЕ 1012-1986, верификация представляет собой процесс оценивания
системы или компонента с целью определить, удовлетворяют ли результаты некой фазы
условиям, наложенным в начале данной фазы. Валидация в этом же стандарте
определяется, как процесс оценивания системы или компонента во время или по окончании
процесса разработки с целью определить, удовлетворяет ли она указанным требованиям.
Трудно ожидать от читателя, впервые столкнувшегося с этой терминологией и ее
определениями в этом и других стандартах, ясности понимания. По крайней мере, у автора
настоящего курса лекций при первом знакомстве с определениями тех же понятий в ISO
IEC 12207 возникло четкое ощущение, что авторы стандарта явно чего-то не договаривают.
Посудите сами: согласно данному стандарту, верификация - это подтверждение
экспертизой и представлением объективных доказательств того, что конкретные
требования полностью реализованы. С другой стороны, валидация - это подтверждение
экспертизой и представлением объективных доказательств того, что конкретные
требования к конкретным объектам полностью реализованы. Правда, к чести авторов
последнего стандарта, они приводят примечание, которое несколько приближает читателя
к пониманию: "валидация связана с экспертизой продукта в целях определения его
соответствия потребностям пользователя". В этом и заключается суть отличия: если
верификация связана с выяснением того, удовлетворяет ли разрабатываемый объект, либо
процесс его создания сформулированным требованиям, то валидация отвечает на вопрос правильно ли разработан целевой объект (продукт), удовлетворяет ли он потребностям
заказчика. Другой аспект валидации заключается в том, что она обычно увязывается с
формальной приемкой (аттестацией) системы.
Некоторые стандарты, например SWEBOK, IEEE 1059-93 "IEEE Guide for Software
Verification and Validation Plans", вводят для этих двух процессов обобщающее понятие
V&V (Validation and Verification). Согласно IEEE 1059-93, верификация и валидация
программного обеспечения - упорядоченный подход в оценке программных продуктов,
применяемый на протяжении всего жизненного цикла. Усилия, прилагаемые в рамках
работ по верификации и валидации, направлены на обеспечение качества как
неотъемлемой
характеристики
программного
обеспечения
и
удовлетворение
пользовательских требований.
Из вышесказанного ясно, как осуществить верификацию и валидацию АИС и (или)
процесса ее создания: в первом случае необходимо убедиться, что АИС (компонента,
процесс) соответствует сформулированным требованиям, во втором - что АИС
действительно работает! Но если критерием проверки АИС служат требования, то что
может послужить критерием проверки самих требований? Ответ заключается в том, что
требования должны удовлетворять свойствам, сформулированным в лекции 3, Кроме
того, следует убедиться в том, что [12.1]:
в спецификации требований к ПО должным образом описаны предполагаемые
возможности и характеристики системы, которые удовлетворят потребности
различных заинтересованных в проекте лиц;
требования к ПО точно отражают системные требования, бизнес-правила и др.;
требования обеспечивают качественную основу для проектирования и сборки ПО.
1.15.2 Некоторые типичные проблемные ситуации
процесса формирования и оценки требований
Двусмысленность требований
В ряду проблем и недостатков требований двусмысленность, является, пожалуй, наиболее
критичным фактором риска проекта, закладываемого в фазе формирования требований.
Двусмысленность (несоответствие свойству ясности, определенности) закладывает под
проект "бомбу замедленного действия". На практике требование, сформулированное
двусмысленным образом, может привести к различным его интерпретациям
представителями Разработчика и Заказчика. Разработчик, руководствуясь своей
интерпретацией, определит на ее основе архитектурную основу, создаст аналитические и
проектные модели и в конечном итоге создаст программный код. Как показывают
исследования, цена исправления ошибки вырастает примерно на порядок при переходе
между рабочими потоками (от анализа требований к проектированию, от проектирования к
реализации и т.д.).
Тем самым, если не заложить средства на проверку требований на предмет
двусмысленности в момент их формирования - существует риск непринятия готовой
системы в момент приемо-сдаточных испытаний, т.к. каждая из сторон будет
придерживаться своей версией интерпретации требований, что ведет к убыткам, судебным
процессам и т.п. и тому есть масса примеров.
"Золочение" продукта
Под
"золочением"
[12.1]
понимают
такие
ситуации,
когда
разработчики
добавляют функции, которых нет в спецификации, но им кажется, что это понравится
пользователям. Зачастую же клиентам не нужны такие избыточные возможности,
получается, что время, отведенное на реализацию, тратится впустую.
Эта ситуация возникает в случае, когда, во-первых, в коллективе Разработчика
присутствуют творческие личности (ведь далеко не всякая команда станет проявлять
инициативу и делать сверх того, о чем ее просили), во вторых - существует разрыв в
прохождении информации от Заказчика к Разработчику. Инициативный разработчик
"золотит" продукт из самых лучших побуждений, но, возможно, он плохо знаком с бизнеспроцессом Заказчика и заложенные им "фичи" попросту не будут востребованы.
Другая сторона "золочения" заключается в том, что группа представителей Заказчика
неоднородна по своей структуре и может возникнуть ситуация, когда представитель
Заказчика, формулирующий "дорогие" требования, не обладает соответствующими
полномочиями. Это - специфика российских предприятий, где часто все бывает устроено
существенно неформально.
Автору пришлось однажды присутствовать в одном очень показательном диалоге, где он
участвовал в качестве Разработчика, сдающего продукт (АИС для склада материалов), еще
присутствовали пользователь новой системы и инвестор проекта. Ирина (пользователь):
мне неудобно работать в этой программе. Она не учитывает размеры баночек в литрах.
Павел (инвестор): без этого спокойно можно обойтись, достаточно того, что есть учет
материалов по классификатору и 2 единицы измерения - в литрах и килограммах. Ирина: а
мне этого недостаточно, я веду учет в баночках! Павел: а я тут хозяин, здесь все мое и мне
твой баночный учет не нужен! Ирина: а я все равно буду работать, как я привыкла! Диалог
длился около получаса и последнее слово осталось, кончено, за Павлом, программу
переписывать не пришлось.
Минимальная спецификация
Создавать полную документацию требований в соответствии с вышеизложенными
принципами, или ограничиться наброском требований на 2-3 страницы, как это зачастую
делает автор лекций в небольших проектах - как говориться, дело вкуса.
Однако, для работы "не по правилам", во-первых, должны быть объективные предпосылки,
во-вторых - следует отдавать себе отчет в выгодах и рисках этого выбора.
Минимальная спецификация уместна, если имеет место наличие одновременно трех
обстоятельств (объединение по "И"):
а) цена контракта и размеры проекта таковы, что разработка развернутого ТЗ
экономически нецелесообразна;
б) коллектив Разработчика обладает достаточной степенью профессионализма и
опыта выполнения проектов в смежных областях, чтобы уметь создавать по
краткой спецификации продукт, который пройдет приемку Заказчиком;
в) между Заказчиком и Разработчиком существуют конструктивные отношения и
обе стороны понимают и принимают риски мини-спецификации.
Другой вариант работы по мини-спецификации: Заказчик и Разработчик понимают, что
создание развернутой спецификации оттягивает окончание выпуска готового продукта, что
главная цель проекта - продукт, а не документация и готовы к плотному сотрудничеству в
процессе его создания. Это - путь так называемых agile-методологий разработки ПО,
подробнее см. в http://www.agile.org.
Основной риск применения мини-спецификации заключаются в том, что они базируются
на человеческом факторе. Хорошие и конструктивные отношения между сторонами "на
берегу" должны сохраниться на всем протяжении проекта, в противном случае у сторон
возникнут существенные проблемы в формальном доказательстве того - что должна делать
программа, т.к. мини-спецификация для этого недостаточно полна.
Пропуск типов пользователей
Корпоративные АИС создаются для того, чтобы быть использованными различными
группами пользователей. Может сложиться ситуация, в которой в группу представителей
Заказчика, участвующих в формировании требований, попадут наиболее инициативные
персоны предприятия, которые, по всей видимости, смогут донести свой голос до
представителей Разработчика. Те же категории пользователей, у которых не найдется
активных представителей, могут оказаться "за бортом" автоматизации. Именно эта ошибка
формирования требований называется "пропуск классов пользователей". Чтобы ее
избежать, представитель Разработчика должен объективно оценить организационную
структуру предприятия и его бизнес-процессы и вдумчиво подойти к выбору ключевых
персон, проведение интервью с которыми поможет сформировать целостную картину
требований к создаваемой АИС.
1.15.3 Методы и средства проверки требований
Наработано значительное количество методов и средств проверки требований [12.1-12.5].
Они разнятся по ряду параметров. Так, различают:
по широте анализа - просмотр (выборочная проверка) и сквозной контроль
(тотальная проверка);
по степени формализации - неофициальные процедуры, процедуры, проводимые
по формальным правилам (инспекции, экспертизы);
по составу группы проверки - с (без) участием автора, с (без) участием
менеджера проекта, с (без) участием представителей внешних организаций;
по используемым средствам - тексты требований, тестовые сценарии, критерии
приемлемости, прототипы.
Понятие и методы прототипирования были рассмотрены в лекции 10. Некоторые другие,
наиболее важные из перечисленного выше, методы и средства, рассмотрены далее по
тексту.
Неофициальные просмотры требований
Различают [12.1] несколько способов неофициальных просмотров требований:
просмотр "за столом",
коллективная проверка,
критический анализ.
В первых двух случаях автор требований обращается за помощью к коллегам
(соответственно, к одному, либо к нескольким) с целью выдачи практических
рекомендаций по улучшению продукта. В третьем случае автор осуществляет презентацию
разработанные им требования на совещании с последующим обсуждением.
Неофициальные просмотры используют для знакомства с разработкой, сбора отзывов,
формирования обратной связи. По статистике, приведенной в [12.4], неофициальные
просмотры позволяют выявить до 60% ошибок в требованиях.
Инспекции
Понятие инспекции, применительно к IT-индустрии, впервые было сформулировано
Майклом Фэганом (Michael Pagan) из IBM в середине 70-х гг.1).
Согласно стандарту IEEE2), проведение инспекций, в отличие от неформальных
просмотров, базируется на своде формальных требований и правил. Представленный ниже
обзор правил приведен, основываясь на работе [12.5]. Кроме того, слушателям следует
порекомендовать ознакомиться с параграфом "Проведение экспертизы" главы 15
монографии [12.1], где представлено детальное описание процедуры экспертизы.
Лица, занимающие управленческие позиции (менеджеры) в отношении к любым членам
команды инспектирования, не должны участвовать в инспекциях.
Инспекция должна вестись под руководством непредвзятого (независимого от проекта и
его целей) лидера, обученного техникам инспектирования.
Инспектирование всегда вовлекает авторов промежуточного или конечного продукта.
В группу инспекции входят лидер, регистратор, рецензент и несколько (от 2 до 5)
инспекторов. Члены команды инспектирования могут специализироваться в различных
областями экспертизы (обладать различными областями компетенции), например,
предметной области, методах проектирования, языке и т.п. В заданный момент
(промежуток) времени инспекции проводятся в отношении отдельного небольшого
фрагмента продукта (в большинстве случаев, фокусируясь на отдельных функциональных
или других характеристиках; часто, отталкиваясь от отдельных бизнес-правил,
функциональных требований или атрибутов качества, прим. автора). Каждый член
команды должен исследовать оцениваемый продукт и другие входные данные до
проведения инспекционной встречи, применяя, возможно, те или иные аналитические
техники к небольшим фрагментам продукта или к продукту, в целом, рассматривая в
последнем случае только один его аспект, например, интерфейсы. Любая найденная
аномалия должна документироваться, а информация передаваться лидеру инспекции. В
процессе инспекции лидер руководит сессией и проверяет, что все подготовились к
инспектированию. Общим инструментом, используемым при инспектировании, является
проверочный лист (checklist), содержащий аномалии и вопросы, связанные с аспектами,
вызывающими интерес. Результирующий лист часто классифицирует аномалии и
оценивается командой с точки зрения его завершенности и точности. Решение о
завершении инспекции принимается в соответствии с одним (любым) из трех критериев:
1. Принятие с отсутствием либо малой необходимостью переработки
2. Принятие с проверкой переработанных фрагментов
3. Необходимость повторной инспекции.
Разработка тестов
Механизм вариантов использования (uses cases), рассмотренный в лекции 8, позволяет
ответить на вопрос: как будет использоваться система. Чтобы проверить систему,
используется аналогичный механизм: тестовых сценариев (test cases).
Тестовые сценарии (ТС) рекомендуется создавать уже на ранних стадиях работы с
требованиями, в идеале - после получения запросов совладельцев, параллельно с
разработкой вариантов использования.
Тестовые сценарии, как и варианты использования, могут поддерживать разные уровни
абстракции. Различаются концептуальные и детальные ТС. Концептуальный уровень
предполагает проработку процедуры тестирования, инвариантную к конкретной
реализации UI.
Как использовать тестовые сценарии для тестирования требований? В [12.1] предлагается
следующая процедура.
1. Построить матрицу, где по вертикали отмечены функциональные требования, а
по горизонтали - тестовые сценарии.
2. Убедиться, что каждый из ТС осуществим на существующем наборе требований.
3. Убедиться, что для каждого требования представлен как минимум один ТС.
4. Прочертить "путь" каждого из ТС на карте диалогов. Это позволит: обнаружить
некорректные или пропущенные требования, исправить ошибки на карте
диалогов и отшлифовать варианты тестирования.
Как быть с тестированием нефункциональных требований? Согласно [12.6], процедура
анализа требований считается выполненной только тогда, когда все требования,
включенные в спецификацию, обладают методами оценки соответствия им создаваемого
программного продукта.
Для того, чтобы нефункциональные требования были измеримы, каждому из них в идеале
необходимо сопоставить количественную метрику. Если это не удается - возможно,
требование следует переформулировать, либо детализировать.
Определение критериев приемлемости
При формальной приемке продукта существуют две типовые процедуры: демонстрация
продукта Разработчиком на тестовых сценариях и проверка продукта Заказчиком. Далеко
не каждого Заказчика можно убедить, что он не должен "тыкать кнопки", лежащие за
пределами тестовых сценариев. Однако, в период стабилизации продукта, для Заказчика
важнее даже не количество выявленных дефектов, а возможность проверки - годится ли
разработанная АИС для решения поставленных им задач.
Чтобы не откладывать столь важный вопрос до момента приемки системы, крайне важно,
наряду с формированием требований, вовлечь Заказчика на ранних стадиях создания
продукта в процесс формирования критериев приемлемости. Критерии приемлемости
(acceptance criteria) должны отразить точку зрения Заказчика на то, что он считает
правильной системой.
Делегирование разработки тестов на приемлемость пользователям - эффективная стратегия
разработки требований [12.1]. Это позволяет уже на этапе сбора информации перейти от
формулировки вопроса с "Что вам нужно делать с помощью системы?" к "Как вы делаете
вывод о том, что система удовлетворяет вашим потребностям?". Если клиент не может
описать, как он оценит, что конкретное требование удовлетворено системой, значит,
требование сформулировано недостаточно ясно.
Раннее формирование тестов для проверки приемлемости позволяет обнаружить дефекты в
требованиях.
Проверка приемлемости базируется на ключевых (существенных) вариантах
использования. При этом следует абстрагироваться от альтернативных сценариев и
исключений и сосредоточить внимание на основном потоке событий. Необходимо учесть
также и нефункциональные требования, такие, как производительностью, легкость и
простота использования.
1.16 Введение в управление требованиями.
Пройдя этапы выявления, всестороннего анализа, формализации, спецификации,
проверки, требования к АИС приобретают статус документа. Стороны ставят на
документе свои подписи, тем самым, удостоверяя, что именно этот (представленный в
SRS) набор требований представляет свод законов, по которому создается система.
Затем осуществляется проектирование и реализация системы. Готовая АИС передается
Заказчику, который, совместно с Разработчиком осуществляет ее приемку и ввод в
эксплуатацию. Такая схема была заложена в подходе, который известен в литературе,
как "каскадный" или "водопадный"1) (см. рис. 13.1). В этой схеме нет места управлению
требованиями, т.к. они статичны, сформулированы в начале проекта и неизменны во
времени.
Рис. 13.1.
Каскадный подход представлял собой одну из первых систематизаций потоков
работ программной инженерии и на момент своего появления представлял безусловную
ценность. Однако практика выполнения проектов автоматизации в рамках данного
подхода показала низкий (порядка 20%) процент успешных проектов. Первая причина лавинообразное разрастание цены исправления ошибок, возникших на ранних этапах
создания системы от этапа к этапу (схема не имела обратных связей и, соответственно,
ошибки копились вплоть до этапа внедрения). Вторая - статичность схемы. Крупный
проект автоматизации может длиться 2, 3 года, а требования, замороженные в SRS,
перестают соответствовать бизнес-реалиям предприятия внедрения, которое за столь
долгий период может существенно измениться.
Подавляющее большинство современных методологий управления проектами
разработки программного обеспечения2) при всем своем разнообразии сходятся в одном:
требования могут меняться! Причем практически на любой фазе производства АИС. Эта
новая парадигма работы с требованиями, безусловно, импонирует Заказчикам. Теперь
они имеют право ошибиться и исправить свою ошибку. Они могут дать волю своему
креативу и постоянно изобретать новые возможности и формы реализации продукта. Но
каково Разработчику? Если "двусмысленность - страшилка любой спецификации
требований3)", то неконтролируемое изменение и разрастание требований - ходячий
кошмар Разработчика. Вопрос контроля процесса изменений требований и его влияния
на другие рабочие потоки программной индустрии настолько серьезен, что породил
отдельную
инженерную
дисциплину
управление
требованиями.
Подробно
ознакомиться со всеми этапами, артефактами, приемами и методами данной дисциплины
можно, изучив третью главу монографии [13.1], краткое изложение которой легло в
основу этой лекции.
Согласно RUP4), управление требованиями - это систематический подход к
выявлению, организации и документированию требований к системе, а также установка
и поддержание соглашения между клиентом и группой разработки по поводу изменений
требований к системе. Данное соглашение, как и тексты исходных требований,
подлежит документальному оформлению.
Согласно [13.1], к действиям по управлению требованиями относятся:
определение основной версии требований (моментальный срез требований для
конкретной версии продукта);
просмотр предлагаемых изменений требований и оценка вероятности воздействия
каждого изменения до его принятия;
включение одобренных изменений требований в проект установленным способом;
согласование плана проекта с требованиями;
обсуждение новых обязательств, основанных на оцененном влиянии изменения
требований;
отслеживание отдельных требований до проектирования, исходного кода и
вариантов тестирования;
отслеживание статуса требований и действий по изменению на протяжении всего
проекта.
1.16.1 Принципы
требованиями
и
приемы
управления
Базовая версия требований
Чтобы договориться об изменении требований, сначала нужно их зафиксировать в
"первозданном виде".
Базовая версия (baseline) - это набор функциональных и нефункциональных требований,
которые разработчики обязались реализовать в определенной версии (итерации).
Управление требованиями - это рабочий процесс, следовательно, он должен подчиняться
определенным правилам и процедурам.
Процедуры управления требованиями
Процедуры управления требованиями базируются на:
инструментах, приемах и соглашениях по управлению версиями различных
документов требований и отдельных требований;:
правилах составления базовой версии требований;
статусах требований, которые будут использоваться, и категориях лиц, которые
имеют право изменять их;
способах, с помощью которых новые требования и изменения существующих
требований предлагаются, обрабатываются, обсуждаются и передаются всем
заинтересованным лицам;
методах анализа влияния предложенного изменения;
отслеживании связей планов и обязательств проекта с изменением требований.
Контроль версий
Каждая версия документа требований должна содержать историю переработки, где
указываются внесенные изменения, дата каждого из них, лицо, внесшее изменение, а также
причина. Целесообразно добавлять номер версии к названию каждого отдельного
требования, который можно последовательно увеличивать при модификации требований.
Для документирования версий используются текстовые процессоры, электронные таблицы.
Существуют специализированные средства для контроля версий и конфигураций 1)
Атрибуты требований
С позиций управления, каждое из требований представляет собой самостоятельный объект.
Изменения осуществляются в описательной части данного объекта. Контроль изменений
удобнее осуществлять с помощью атрибутов требований. Набор атрибутов подбирается
для каждого проекта индивидуально, исходя из максимальной результативности для
команды проекта. При первом внедрении средств управления изменениями рекомендуется
использовать не более пяти атрибутов. Это количество можно будет расширить
впоследствии, когда команда "войдет во вкус" процесса управления изменениями и в том
случае, если добавление новых атрибутов оправдано практическими соображениями.
В качестве шаблона описания атрибутов требований К.Вигерс [13.1] предлагает
следующий набор:
дата создания требования;
номер его текущей версии;
автор требования;
лицо, ответственное за удовлетворение требования;
ответственный за требование или список заинтересованных лиц (чтобы
принимать решения о предложенных изменениях);
состояние требования;
происхождение или источник требования;
логическое обоснование требования;
подсистема (или подсистемы), для которых предназначено требование;
номер версии продукта, для которого предназначено требование;
используемый метод проверки или критерий тестирования приемлемости;
приоритет реализации;
стабильность требования
Контроль статуса требований
В автоматизированных средствах управления проектами, например MS Project, для
контроля степени выполнения той или иной работы используется понятие степени
выполнения (progress), выражаемой в процентах. Данный способ слабо применим в
программистских разработках, где, в силу их слабой формализованности, трудно оценить
работу в процентах. При управлении требованиями рекомендуется оперировать не
процентом, а статусом. К.Вигерс предлагает следующий шаблон для определения статуса
требования:
Таблица 13.1.
Состояни
Определение
е
Proposed
Требование запрошено авторизированным источником
(Предложено)
Approved
(Одобрено)
Требование
проанализировано,
его
влияние
на
проект
просчитано, и оно было размещено в базовой версии определенной
версии. Ключевые заинтересованные в проекте лица согласились с
этим требованием, а разработчики ПО обязались реализовать его
Implement
Код,
реализующий
требование,
разработан,
написан
и
ed
протестирован. Требование отслежено до соответствующих элементов
(Реализовано)
дизайна и кода
Verified
(Проверено)
Корректное
функционирование
реализованного
требования
подтверждено в соответствующем продукте. Требование отслежено до
соответствующих
вариантов
тестирования.
Теперь
требование
считается завершенным
Deleted
(Удалено)
Rejected
(Отклонено)
Утвержденное требование удалено из базовой версии. Опишите
причины удаления и назовите того, кто принял это решение
Требование предложено, но не запланировано для реализации
ни в одной будущих версий. Опишите причины отклонения требования
и назовите того, кто принял это решение
Измерение
трудозатрат,
управления требованиями
необходимых
для
Управление требованиями, как и всякий другой процесс, требует ресурсов. Контроль
усилий также позволяет выяснить, выполняют ли разработчики предполагаемые задачи для
управления требованиями.
Основные трудозатраты по управлению требованиями [13.1]:
предложение изменения требований и новых требований;
оценка предложенных изменений, включая оценку влияния изменения;
изменение работы;
обновление документации требований или базы данных;
сообщение об изменениях требований заинтересованным группам и отдельным
лицам;
контроль и отчет о состоянии требования;
сбор информации о трассируемости требований.
1.16.2 Управление изменениями
Управление незапланированным ростом объема
Незапланированный рост объема ставит под удар1):
80% проектов по разработке систем управления информацией;
70% проектов по разработке военных систем ПО;
45% проектов по созданию ПО, выполняемых по контракту.
Незапланированным
изменением
требований
считается
предложение
новой
функциональности и существенной модификации после утверждения базовой версии
требований к проекту. Чем дольше продолжается работа над проектами, тем больше их
объем.
Проблема заключается не в изменении требований, а в том, что запоздалые изменения
оказывают существенное влияние на уже проделанную работу. Если каждый запрос на
изменение будет удовлетворяться - проект, возможно, никогда не будет завершен.
Ключевая стратегия ограничения роста незапланированных требований - разработка
хороших требований, руководствуясь приемами и методами, рассмотренными в
предыдущих лекциях, в максимальном контакте с Заказчиком.
Другая стратегия - это умение сказать: "Нет" . Психология большинства людей устроена
так, что им тяжело отказывать, что в данном случае может привести к состоянию
постоянного прессинга. К.Вигерс предлагает "смягчить" этот подход, заменив "Нет", на
"Не сейчас" (требование обязательно будет выполнено, но не в текущей версии). Автор
лекционного курса, соответственно, хотел бы добавить в эту копилку фразу "Зачем?". Опыт
показывает, что данная фраза значительно упрощает общение и позволяет сподвигнуть
представителя Заказчика на размышления: а действительно ли его идея хороша, а какую
конкретную пользу она принесет бизнесу его предприятия?
Однако, не следует делать вывод из всего вышесказанного, что изменения не нужны.
Изменения неизбежны, приемлемы и в ряде случаев благоприятны. Бизнес-процессы,
рыночные возможности, конкурирующие продукты, и технологии - все они могут меняться
в ходе разработки продукта, и менеджеры могут определить, как в ответ на эти изменения
необходимо откорректировать направление работы.
Процесс контроля изменений
Процесс
контроля
изменений
позволяет
руководителю
проекта
принимать
информированное бизнес-решение, которое удовлетворяет клиента и имеет коммерческую
ценность, при этом контролируются затраты на жизненный цикл продукта. Вы можете
отслеживать статус всех предложенных изменений и убедиться, что предложенные
требования не были потеряны или упущены. После утверждения базовой версии набора
требований придерживайтесь этого порядка для внесения всех предлагаемых изменений в
нее.
Клиенты и другие заинтересованные лица часто уклоняются от нового процесса, однако
процесс контроля изменений - не препятствие для модификации. Это механизм
суммирования и фильтрации, дающий уверенность, что в проект включены наиболее
ценные изменение.
Если предложенное изменение не настолько важно, чтобы заинтересованное в проекте
лицо потратило пару минут на передачу его через стандартные, простые каналы, то стоит
задуматься о его ценности вообще. Процесс управления должен быть тщательно
задокументирован, максимально прост и, что важнее всего, эффективен.
После регистрации запроса на изменение необходимо принять решение о его дальнейшей
судьбе. Совет по управлению изменениями (change control board, CCB) (иногда его
называют советом по управлению конфигурацией) был признан лучшим практическим
решением при разработке ПО . На практике функции Совета могут быть делегированы и
одному человеку (в зависимости от размеров проекта).
Запрос на изменение может быть принят, либо отклонен. В первом случае его необходимо
включить в план работ над проектом, во втором - сформулировать мотивированный отказ.
При принятии решения по запросу необходимо исходить:
а) из степени важности запроса для Заказчика и
б) из его стоимости для Разработчика. Стоимость определяется на основании
анализа влияния изменения.
Анализ влияния изменения
Анализ влияния обеспечивает точное понимание подтекста предложенного изменения, что
помогает команде принимать информированные бизнес-решения о том, какое изменение
одобрить. Анализ позволяет выявить компоненты, которые может понадобиться создать,
изменить или отклонить, и оценить затраты, связанные с реализацией изменения. До того,
как разработчик ответит: "Конечно, без проблем", он должен потратить время на анализ
результата изменения.
Председатель совета по управлению изменениями обычно просит опытного разработчика
выполнить анализ результата определенного.
Анализ результатов изменений затрагивает три аспекта [13.1].
1. Определите возможные последствия изменения. Часто они вызывают
значительный волновой эффект. Включение множества функций в продукт может
снизить его производительность до неприемлемого уровня, например, когда
системе, запускаемой ежедневно, потребуется 24 часа для завершения одного
запуска.
2. Определите все файлы, модели и документы, которые, возможно, придется
изменить, если команда включит все запрошенные изменения.
3. Определите задачи, необходимые для реализации изменения, и оцените усилия,
необходимые для выполнения этих задач.
Трассируемость требований
Связи трассируемости помогают следить за развитием требования в обоих направленияхот первоисточника к реализации и наоборот. Трассируемость представляет собой одну из
качеств хороших требований, см. лекцию 3.
Для осуществления анализа трассируемости каждое требование должно быть уникально
идентифицировано.
Рис. 13.2. Основные типы трассируемости требований
Требования
пользователей
отслеживаются
в
направлении
к
формально
специфицированным функциям системы, чтобы понять, которые требования будут
затронуты, если потребности клиентов изменятся. Это также позволяет убедиться в том,
что в спецификации требований отражены все потребности клиента. Можно осуществить
анализ и в обратном направлении, чтобы определить происхождение каждого требования к
ПО.
В процессе анализа, проектирования и реализации компонент системы можно отслеживать
связи, ведущие от требований к артефактам (документам, моделям, программным модулям
и т.п.) системы. Этот тип связи гарантирует, что каждое требование удовлетворено,
поскольку вы знаете, какой компонент соответствует каждому требованию.
Четвертый тип связи контролирует отдельные артефакты в направлении к требованиям для
того, чтобы вы знали причину созданию каждого из них.
Предположим, тестеровщик обнаружит незапланированную функциональность при
отсутствии соответствующего требования. Этот фрагмент кода может свидетельствовать,
что разработчик реализовал официальное требование, которое аналитик теперь может
добавить к спецификации. Или же это может быть код-"сирота", украшающий фрагмент,
который не относится к продукту. Связи трассируемости помогут вам отсортировать
подобные ситуации и получить более полное представление о том, как именно фрагменты
вашей системы составляют одно целое. И наоборот, варианты тестирования, которые
созданы на основе отдельных требований и которые можно проследить до этих
требований, также представляют собой механизм выявления нереализованных требований,
поскольку ожидаемой функциональности не будет.
Наиболее типичный способ представления связей между требованиями и другими
элементами системами - матрица трассируемости требований, которую также называют
матрицей отслеживания требований или таблицей трассируемости (requirements traceability
matrix). В таб. 13.2 показана иллюстрация части такой матрицы из [13.1].
Таблица 13.2.
Пользовател
ьское требование
Функционал
ьное требование
UC-28
Эл
кода
дизайна
catalog.query.
sort
Модуль
емент
Ка
талог
Вариант
тестирования
catalog.sort
()
search.7
search.8
класса
UC-29
catalog.query.i
mport
Ка
catalog.imp
search.12
талог
ort()
search.13
класса
catalog.validate()
search.14
Другая форма представления связей трассируемости - дерево трассировок [13.2].
1.17 Совершенствование процессов работы с требованиями
Парадигма управления качеством, как способ организации производства, появилась давно.
Идеи, заложенные в группе стандартов ISO90001), уходят корнями, в частности, и в такие
"советские"
изобретения,
как
поддержка
рационализаторских
предложений,
наставничества и др.
В современной концепции процессно-ориентированной организации бизнеса процесс
непрерывного совершенствования качества занимает одну из ключевых позиций.
Применительно к софтверной индустрии, помимо серии ISO9000, наиболее успешно себя
зарекомендовавшими стандартами качества являются SEI CMM, SEI CMMI, ISO/IEC 15504
(SPICE), Bootstrap, TickIT.
1.17.1 Модели совершенствования
ISO9000
Активное внедрение методов управления качеством на Западе началось в начале 1960-х
годов. В основу стандартов серии ISO9000 легла философия подходов CPI (Continuous
Process Improvement) и TQM (Total Quality Management) [14.1]. Подъем экономики
послевоенной Японии во многом был обусловлен идеям, заложенным в TQM.
Качество - термин, который для одних означает необходимость делать то, что желает
потребитель, для других - то, что отвечает его потребностям. Менеджмент качества, как он
определен в ИСО 9001:2000, исходит прежде всего из того, что люди работают лучше, если
им известно то, чем они занимаются. [14.1].
Поэтому прежде, чем приступить к какому-либо действию, следует получить ответы на
вопросы: что нужно делать, кто будет проверять сделанное, как это нужно делать и как
определить, что работа завершена? Необходимо также продумать, как вы собираетесь
управлять данным процессом и как его можно усовершенствовать.
Основные принципы ISO9000:
Концентрация на потребностях заказчика;
Активная лидирующая роль руководства;
Вовлечение исполнителей в процессы совершенствования;
Реализация процессного подхода;
Системный подход к управлению;
Обеспечение непрерывных улучшений;
Принятие решений на основе фактов;
Взаимовыгодные отношения с поставщиками.
Безусловное достоинство стандартов этой группы связано с тем, что они апробированы на
множестве предприятий мира. Однако рекомендации данных стандартов носят достаточно
общий характер и не учитывают специфику предприятий отрасли IT. Для этого были
разработаны специализированные подходы, рассмотренные ниже.
SEI-CMM, SEI-CMMI
Стандарт СММ (the Capability Maturity Model) разработан институтом инженерии
программного обеспечения (SEI) при университете Карнеги-Меллон.
Назначение стандарта - оценка уровня "зрелости" (maturity levels) организации разработчика программного обеспечения. Выделяются пять уровней: начальный,
повторяемый, определенный, управляемый и оптимизирующий (подробнее см. в [ 14.2-
14.3]). Данный стандарт получил широкую известность, значительное количество
западных IT-компаний сертифицировано по CMM.
В 2000 г. SEI выпустил CMMI-SE/SW, интегрированную модель совершенствования как
ПО, так и возможностей конструирования систем [14.3].
CMMI-SE/SW имеет две формы. Ступенчатое представление (the staged representation)
соответствует структуре SW-CMM с небольшими уточнениями наименований уровней.
Пять уровней зрелости содержат 22 области технологических процессов, показанных в
таблице 14.1. (CMU/SEI, 2000а). Непрерывное представление (continuous representation),
содержит другой взгляд: те же 22 области структурируются по 4 категориям: управление
процессами, управление проектами, конструирование и поддержка (CMU/SEI, 2000b).
В непрерывном представлении вместо уровней зрелости определяются шесть уровней
способностей (capability levels) для каждой области технологических процессов. Это
представление позволяет каждой организации решать, какой уровень способностей ей
соответствует в каждой из 22 областей технологических процессов.
Как и в CMM, в рассматриваемом стандарте на уровне 2 имеется область, именуемая
"Управление требованиями", но, в отличие от предыдущего стандарта, на уровне 3 есть и
отдельная область "Разработка требований". Размещение этой области на уровне 3 не
подразумевает, что требования для проектов организации, не достигших уровня 2, собирать
и документировать не нужно. Управление требованиями рассматривается как способ,
помогающий создавать более предсказуемые и менее хаотичные проекты, что составляет
сущность уровня 2 СММ. Приняв порядок управления изменениями и проверки статуса
требований, организация может больше внимания уделять разработке высококачественных
требований [14.3].
Таблица 14.1.
Уро
вень
Название
Области процессов
зрелости
1
Начальный
(нет)
2
Управляемы
Управление требованиями Планирование проекта
й
Мониторинг
и
контроль
проекта
соглашениями
с
поставщиками
Обеспечение
качества
Управление
Измерения
процессов
и
и
анализ
продуктов
Управление конфигурацией
3
Определенн
ый
Разработка
Интеграция
продуктов
Концентрация
процесса
требований
внимания
организацией
Интегрированное
Техническое
Верификация
на
процессе
Валидация
Определение
Организационное
управление
проектом
решение
обучение
Управление
риском Анализ и разрешение вопросов
4
Количестве
нно управляемый
5
Оптимизиру
ющий
Производительность организационных процессов
Количественное управление проектом
Организационные
нововведения
и
их
развертывание Случайный анализ и разрешение
Область процессов "Управление требованиями"
Ключевые темы включают в себя то, как команда разработчиков должна приобретать
понимание требований и разрешать вопросы с клиентами, вовлекать участников проекта в
работу с требованиями и управлять изменениями. В отличие от SW-CMM, трассирование
(одно из ключевых свойств требований) включено в рассматриваемую область
процессов. В стандарте обсуждаются следующие качества трассирования:
обеспечение записи источников низкоуровневых или вторичных требований;
трассирование каждого требования вниз, к вторичным требованиям, и его
размещение по функциям, объектам, процессам и исполнителям;
установка горизонтальных связей между требованиями, принадлежащими к
одному типу.
Область процессов "Разработка требований"
В CMMI-SE/SW описаны три набора приемов разработки требований:
приемы, определяющие полный набор требований клиентов, которые затем
используются для разработки требований для продукта (выявить нужды
заинтересованных в проекте лиц; преобразовать нужды и ограничения в
требования клиентов);
приемы, определяющие полный набор требований для продукта (установить
компоненты продукта; разместить требования по компонентам продукта;
определить требования к интерфейсу);
приемы получения вторичных требований, понимания требований и их
подтверждения (установить оперативные концепции и сценарии; определить
требуемую функциональность системы; проанализировать вторичные требования;
оценить стоимость, сроки и риск создания продукта; утвердить требования).
Как в СММ, так и в CMMI формулируются цели, к которым проект или организация по
разработке ПО должны стремиться в различных областях процессов. В них также
рекомендуются технические приемы, помогающие достичь этих целей.
CMMI-SE/SW регламентирует взаимосвязи между управлением
разработкой требований и другими областями процессов (рис. 14.1).
требованиями,
Рис. 14.1.
1.17.2 Принципы совершенствования
В
[14.3]
сформулированы
следующие
принципы
совершенствования
качества
программных систем:
поэтапность,
непрерывность,
цикличность,
наличие стимула,
ориентация на цели,
проектный подход.
Мероприятия по совершенствованию процессов следует вводить поэтапно. Людям нередко
бывает тяжело отказываться от старых привычек, привыкать к новому. Предложенные
изменения должны пройти проверку опытом; не все из предложенного обязательно даст
эффект, какие-то новации придется пересмотреть, от чего-то - отказаться.
Непрерывность - один из ключевых принципов управления качеством: часто мероприятия
проводятся в виде кампании, которая затухает после получения сертификата. Организация,
которая стремится к лидерству, должна поддерживать "дух качественной работы"
постоянно.
Бизнес-процесс улучшения требований характеризуется цикличностью (см. Процесс
совершенствования): его основные этапы повторяются на все более высоком уровне.
Циклы оптимизации в софтверных организациях удобно приурочивать к проектам,
выполняемых в рабочих группах. Анализ недостатков целесообразно производить тогда,
когда они в "оперативной памяти" группы проекта, например - один раз в середине проекта
и один - сразу после его окончания. Каждый проект по-своему уникален и несет в себе
потенциал для улучшения процессов.
Основным стимулом к изменениям К.Вигерс считает трудности, с которыми столкнулась
команда проекта, например:
разработчики не уложились в график, потому что непонятные и неоднозначные
требования попали к ним поздно;
разработчикам пришлось много работать сверхурочно, потому что непонятные
или расплывчатые требования были уточнены слишком поздно в процессе
разработки;
попытка тестирования системы не удалась, потому что тестировщики не
понимали, что продукт должен делать;
нужная функциональность была реализована, но пользователи не удовлетворены
вялой производительностью, неудобством работы или другими недостатками
качества продукта;
организации пришлось пойти на высокие расходы на сопровождение, потому что
клиентам потребовалась масса дополнительных функций, которые следовало
определить во время составления требований;
организация-разработчик ПО приобрела плохую репутацию поставщика
продуктов, которые не нравятся клиентам.
Изменения технологических процессов должны быть целеориентированы. Примеры целей:
уменьшение объема работы, вызванного проблемами с требованиями;
повышение точности планирования и реалистичности планов;
снижение (исключение) числа ситуаций появления новых требований на
финишных этапах проекта.
Действия по совершенствованию процессов должны планироваться, контролироваться и
управляться, как мини-проекты. Это упрощает выделение
отслеживание перемен и оценки результативности изменений.
требуемых
ресурсов,
1.17.3 Процесс совершенствования
На рис. 14.2 показан типовой цикл совершенствования процессов при создании
программного обеспечения [14.3].
Рис. 14.2.
Оценка текущих приемов
В соответствие с принципом целенаправленности, в работы по совершенствованию
необходимо начать с формулировки целей и оценкой, насколько существующие процессы
соответствуют данным целям. Для целей оценки применимы известные в бизнесмоделировании и анализе требований методы и приемы: от проведения интервью и
постановочных семинаров до фиксации модели "Как есть".
Эффективным способом является привлечение внешних консультантов, которые могут
составить непредвзятый взгляд на положение в вашей компании.
Результатами оценки является список обнаруженных сильных и слабых сторон в текущих
процессах, а также, начальные рекомендации по совершенствованию (переходу к модели
"Как надо").
Планирование
В соответствии с принципом проектного подхода к проведению мероприятий по
совершенствованию, для мини-проекта совершенствования необходимо проделать все то,
что обычно делается при инициации проектов: осуществить декомпозицию работ;
выделить ресурсы, назначить исполнителей; создать планы работ.
Стратегический план описывает общую программу совершенствования процессов в вашей
организации. Тактические планы действий затрагивают конкретные области
совершенствования, например процесс сбора требований или процедуру назначения
приоритетов [14.3]. В каждом плане действий должны быть указаны цели действий по
совершенствованию, участники и отдельные задачи. План также дает возможность
отслеживать выполнение процесса совершенствования, отмечая выполнение отдельных
задач.
В плане действий не должно быть более 10 пунктов; срок его реализации не должен
превышать 2-3 месяца.
Ниже приведен шаблон декомпозиции задачи управления требованиями [14.3].
1.
2.
3.
4.
составить проект процедуры управления изменениями;
проверить и модифицировать процедуру управления изменениями;
провести пробное испытание процедуры управления изменениями для проекта;
модифицировать процедуру управления изменениями на основе обратной
реакции по пробному испытанию;
5. оценить инструментальные средства выявления проблем и выбрать одно из них
для поддержки процедуры управления изменениями;
6. приобрести выбранное инструментальное средство выявления проблем и
настроить его для поддержки конкретной процедуры;
7. внедрить новую процедуру управления изменениями и инструментальное
средство в организации.
Создание и апробация новых процессов
Принцип поэтапности призывает не делать "революций" в совершенствовании процессов.
Любая новация, описание которой найдено в литературе, заимствована из опыта коллег или
разработана лично вами, должна пройти испытание на вашей команде и ваших проектах.
Известный неполиткорректный принцип "что русскому хорошо - то немцу смерть" на
языке современного менеджмента IT-проектов звучит, как "учет системы ценностей,
принятых в команде разработчиков" [14.5].
Апробация на реальных задачах - единственный гарантированный способ проверить годится ли тот или иной инструмент для вашей команды. Чтобы не вовлекать в
масштабные эксперименты значительные ресурсы существует способ пилотных (пробных)
проектов.
К.Вигерс предлагает следующие методические приемы при апробации новых процессов:
выбирайте для участия в пробных проектах людей, которые будут относиться к
новым приемам беспристрастно и смогут дать им оценку. Это могут быть как
сторонники, так и скептики, но они не должны быть ярыми противниками
предлагаемых приемов;
чтобы результаты было легко истолковать, определите количество критериев, по
которым команда будет оценивать пробный проект
определите заинтересованных лиц, которых следует проинформировать о том,
что представляет собой пробный проект и почему он выполняется;
подумайте о возможности испытания новых процессов по частям в разных
пробных проектах. Так вам удастся вовлечь в испытание больше людей, что
увеличивает осведомленность, количество откликов и сторонников;
для более полной оценки поинтересуйтесь у участников пилотных проектов, что
бы они почувствовали, если бы им пришлось вернуться к существующим приемам
работы.
Оценка результатов и принятие решений
Оценка результатов апробации новых процессов должна показать - достигнуты ли
поставленные цели, стоит ли осуществлять широкомасштабное внедрение новаций,
апробированных на пилотном проекте, либо "овчинка выделки не стоит".
Среди ключевых вопросов в области оценки результатов можно выделить следующие
[14.3].
Насколько гладко прошли пробные проекты и как эффективно они разрешили
неопределенности в отношении новых процессов?
Собираетесь ли вы менять что-либо в следующих пилотных проектах?
Как прошло общее внедрение новых технологических процессов?
Удалось ли вам довести до сведения каждого информацию о пользе новых
процессов или шаблонов?
Смогли ли участники понять и эффективно применить новые процессы?
Собираетесь ли вы менять что-либо при проведении следующего внедрения?
При оценивании результативности достижения поставленных целей следует различать
мероприятия, польза от которых проявляется сразу и те, выгода от которых проявится
через значительное время. Необходимо учитывать эффект "кривой обучения" (learning
curve) [14.3]: производительность падает, пока люди приспосабливаются к новым
способам работы. Кратковременное падение производительности, иногда называемое
"лощиной отчаяния" - в - это часть необходимого вклада, который ваша организация
вносит в совершенствование процессов.
Невзирая на все возможные трудности, мероприятия по улучшению качества при
внимательном к ним отношении неизбежно приведут к повышению эффективности работы
команды.
1.18 Требования в управлении проектом
Чтобы определить сметную стоимость и продолжительность работ по проекту
автоматизации без грубых ошибок, необходимо выявить и проанализировать требования, а
также сформировать архитектурную основу, крайне желательно создать прототипы. И это как минимум. Иными словами, для того, чтобы создать АИС, сначала нужно
проанализировать возможность создания.
Такая постановка вопроса вполне логична и обоснована, это подтвердит любой
Разработчик. Однако, она вызывает много вопросов, например:
Где найти Заказчика, который согласится ждать 2-3 месяца, пока Разработчик
составит для него коммерческое предложение?
Кто оплатит работы по анализу требований? (очевидно, Заказчик)
Как быть, если цена вопроса окажется непомерной и от проекта придется
отказаться - кто возместит Заказчику убытки на проведение исследований?
Разумный Заказчик сможет найти выход из этого непростого положения, например:
подыскав Разработчика, обладающего богатым опытом выполнения подобных
проектов, который сможет дать требуемую оценку значительно быстрее (но риск
ошибки при этом остается);
взяв на себя риски возможного прекращения проекта на ранних стадиях, в
случае, если выявится его несоответствие бюджетным ограничениям (в сложных
рискованных проектах лучше потерять 5% или 10% от закладываемого бюджета,
чем все 100%, как это было в "каскадных" схемах разработки) - путь
прогнозирующих методологий
разделив с Разработчиком ответственность за конечный продукт, приготовившись
день за днем работать с ним рука об руку вплоть до появления результата - путь
гибких (agile) методологий.
1.18.1 От рамок проекта к экспресс-планированию
Начальную, самую грубую оценку проекта можно сделать на основании документа
"Видение".
Так,
шаблон
Vision/Scope
MSF
содержит
список
ключевых
характеристик/функций, критерии приемлемости и (что очень важно) перечень
характеристик/функций, которые лежат "вне рамок" проекта. Параллельно с проработкой
концепции, первая фаза MSF содержит работы по анализу рисков: выявляются и
оцениваются главные риски проекта.
Чтобы сделать первое приближение плана и сметы проекта на ранних этапах анализа, в
[15.1] предлагается следующий подход:
Выделить 25 - 99 функций, характеризующих систему (совместно, Заказчик и
Разработчик);
Установить приоритеты для каждой из функций (Заказчик);
Оценить трудозатраты (Разработчик);
Оценить риски (Разработчик, возможно привлечение Заказчика);
Все оценки делаются по 3-балльной шкале (высокий, низкий, средний; критический,
важный, полезный и т.п.) и сводятся в таблицу:
№
пп.
Ф
ункция
При
оритет
Трудое
мкость
Р
иск
Затем, в процессе консультаций Заказчика и Разработчика на основе полученной
информации определяется набор функций, который войдут в базовую версию проекта.
Результаты планирования на концептуальном уровне, проделанные, например, на основе
вышеуказанного шаблона, позволяют дать первую оценку размерам проекта. Такая оценка
не отличается особой точностью, но при определенных условиях (опыт решения
Разработчиком аналогичных задач; доверительные отношения между Заказчиком и
Разработчиком) может служить отправной точкой для заключения контракта на всю
систему.
1.18.2 Планирование проекта на основе требований,
путь RUP
RUP поддерживает двухуровневую схему планирования работ над проектом, разделяя план
проекта и план итерации. Исходя из базовой концепции планирования итерационных
проектов, план проекта разбивается на фазы:
Начало,
Уточнение,
Конструирование,
Переход.
Исходя из рекомендаций методологии по декомпозиции работ проекта в зависимости от
степени сложности проекта и квалификации команды, в каждой фазе выделяется одна или
более итераций.
Назначаются даты главных вех (окончания фаз):
целей жизненного цикла (конец фазы начала, рамки проекта и его бюджет);
архитектуры жизненного цикла (конец фазы уточнения, законченная
архитектура);
начальной работоспособности (конец фазы конструирования, бета-версия
продукта);
выпуска изделия (конец фазы перехода и полного цикла разработки).
Назначаются даты малых вех, приуроченные к окончанию итераций и их главные цели.
Основные цели итераций - выпуск релизов, демонстрируемых, либо передаваемых
Заказчику, однако не всякая итерация приводит к выпуску релиза.
План проекта создается как можно раньше в начальной фазе и модифицируется по мере
необходимости.
Что это означает на практике:
1. укрупненный план работ составляется "как можно раньше", например - через
месяц после начала работ;
2. бюджет появляется лишь к окончанию первой фазы (а она, в зависимости от
сложности проекта может длиться месяц, а может и полгода);
3. как план, так и бюджет проекта представляют собой лишь прогноз, который
может корректироваться на протяжении работ над проектом;
4. на момент появления плана и бюджета должно появиться подробное описание
лишь 20% ключевой функциональности системы и "широкое, но неглубокое"
[15.2] описание 80% функциональности.
Таким образом, концепция укрупненного планирования в RUP, как типичном
представителе класса прогнозирующих методологий, предполагает базировать отношения
между Заказчиком и Разработчиком на прогнозах, степень достоверности которых зависит
от таких факторов, как качество проработки требований, квалификация команды
Разработчика, сложность и новизна проекта.
Более конкретная информация представлена в плане итерации. Основные его особенности:
1. План итерации базируется на функциональных требованиях. К моменту начала
итерации совершенно точно известно, какие требования должны быть
обработаны (детализированы, спроектированы, запрограммированы) в данной
итерации.
План итерации составляется, исходя из сформулированных выше оценок
требований - приоритетности, степени риска, трудоемкости.
2. План итерации имеет жесткие сроки. В случае проявления незапланированных
рисков удовлетворительным вариантом является достижение договоренности о
реализации требований данной итерации не в полном объеме, либо переносе
требований в следующую итерацию; переносить сроки текущей итерации не
рекомендуется;
3. Точный план составляется на одну, очередную итерацию. К моменту окончания
текущей итерации должен быть сверстан план очередной итерации. Такой подход
позволяет более гибко работать с рисками.
Таким образом, следует отметить, что требования являются решающим фактором в
планировании итерационного проекта.
1.18.3 Требования в гибких методологиях
В противовес прогнозирующим методологиям создания программного обеспечения,
относительно недавно сформировалась парадигма гибких (agile) методологий. В феврале
2001 г. инициативная группа из 17 специалистов объединилась в Альянс гибкой разработки
программного обеспечения. Эта группа разработала и приняла Манифест гибкой
разработки:
Индивидуальности и взаимодействия ВЫШЕ процессов и инструментов
Работающее программное обеспечение ВЫШЕ всесторонней документации
Сотрудничество с клиентами ВЫШЕ переговоров по контракту
Реакция на изменения ВЫШЕ следования плану и 12 приложений (в столь же
лаконичной форме) к нему1).
В определенной степени в противовес всему тому, что было сказано в предыдущих
лекциях, члены Альянса ставят под сомнение необходимость всестороннего
моделирования и документирования требований и даже посягают на святое святых - планы
и контракты.
На сегодня "быть гибким" стало модным. Апологеты методологий, заклейменных членами
Альянса, как "прогнозирующие" и даже "тяжеловесные" вступают в дискуссии - можно ли
считать адаптировать ту или иную методологию на "гибкие рельсы". Так, опубликованы
как минимум два варианта гибкой трансформации для RUP; MSF опубликовало нотацию
agile MSF.
Артефакты для работы с требованиями в гибких
методологиях
С позиций работы с требованиями основными средствами, которыми оперируют гибкие
методологии, являются карты представления системы, истории пользователей, приемочные
тесты и CRC-карты [15.3-15.4].
Карта представления в определенной степени заменяет документ "концепция", принятый
в прогнозирующих методологиях. В отличие от концепции, представление - это текст
размером в 20-30 слов, умещающийся на небольшой (размером с визитную) карточке.
Истории пользователей (user story)очень сильно напоминают краткие описания вариантов
использования. Особенности историй пользователя - в том, что они, во-первых, должны
быть действительно краткими (также умещаться на карточке), во-вторых - в том, что это действительно истории пользователей, т.е. рассказы о том, как они планируют
использовать систему. Использование историй пользователя исключает ситуацию, когда
аналитик что-то придумал (домыслил) за пользователя - отнюдь, эти артефакты создают
сами пользователи. Истории пользователя должны иметь осмысленные наименования и
номера.
Истории пользователя, помимо базового функционала, могут содержать декорации, очень
напоминающие ориентиры RUP (см. лекцию 10).
Приемочные тесты обычно пишут на обратной стороне карты с соответствующей
историей пользователя. Шаблон, используемый в методологии XP, содержит 3
предложения:
Установка (контекст; инициирующее событие),
Операция (функция с количественными характеристиками),
Подтверждение (результаты исполнения функции).
CRC-карты (Класс-Ответсвенность-Кооперация), как и предыдущие 3 артефакта,
представляют собой небольшие карточки, в заголовке которых представлено название
класса, а ниже - таблица в две колонки. В левой колонке перечислены ответственности (т.е.
высокоуровневый взгляд на его методы) класса, в правой - классы, состоящие в кооперации
с рассматриваемым классом.
Планирование на основе требований на примере XP
Планирование включает следующие работы:
оценивание,
планирование версий и итераций.
Оценивание представляет собой определение объема работ в разрезе историй пользователя.
Каждая история оценивается в пунктах. Один пункт равен "идеальной" (сорокачасовой)
неделе, целиком посвященной программированию. Если оценка лежит в пределах от 1 до 3
пунктов - то он ставится на карточке истории. Если оценка менее 1 - на карточке ставится
0. Это - так называемый "песок". Если оценка превышает 3 пункта - мы имеем дело с
"эпопеей". В этом случае карточка помечается, как "split" и подлежит процедуре
разделения. Другая стратегия работы с такой карточкой -попытаться вместить ее в
оптимальный срок путем исключения декораций. В случае, если история пользователя
сложна для экспресс-оценки - необходимо провести исследование или "гвоздь"
планирования.
Планирование версий и итераций
Планирование в XP базируется на следующих основных понятиях: производительность,
приоритеты, стоимость версии, составление плана версий, составление плана итераций.
Производительность или быстродействие команды базируется на оценках пунктов истории.
Однако необходимо учитывать, что пункты представляют идеальные оценки, кроме того
существенную роль имеет опыт команды в оценивании (для начинающих команд возможна
значительная погрешность).
Ключевую роль в назначении приоритетов играет, безусловно, заказчик. Однако и
Разработчик имеет право голоса при отборе историй, которые должны попасть в версию
(вопросы архитектуры, ключевой функциональности и т.п.).
Стоимость версии определяется, базируясь на производительности, приоритетах и сроках.
План версий дает Заказчику начальное понимание стоимости проекта. Эта оценка дает ему
возможность отказаться от проекта в начальной его стадии, если сроки и (или) цена
являются неприемлемыми.
В случае, если план версий принят - составляется план итераций, отражающий шаги
(итерации), которые необходимо проделать, чтобы добиться требуемой функциональности
продукта.
1.18.4 Анализ требований и управление рисками
Риск в реализации программных проектов - это потенциальная проблема, которая имеет
существенную вероятность отрицательно повлиять на успешность проекта, например - на
сдачу его в срок, удовлетворение бюджетных ограничений, качество продукта,
эффективность работы команды.
Управление риском - комплекс мероприятий по выявлению, оценке, предотвращению и
контролю рисков проекта.
Как пишет К.Вигерс [15.5], "Если что-либо нехорошее уже произошло с вашим проектом,
то это - проблема, а не риск… Управление риском означает работу потенциальной
опасностью до того, как она перейдет в кризисную фазу". Менеджеры проектов должны
выявлять риск и управлять им, начиная с факторов, связанных с требованиями, в
сотрудничестве с представителями Заказчика.
1.18.5 Стратегии и работы по управлению риском
Управление риском включает в себя действия, показанные на рис. 15.1 [15.5].
Рис. 15.1.
Работы по оцениванию риска (risk assessment) начинаются с определения потенциальных
опасностей для проекта. В качестве методики выявления может быть рекомендована
методика мозгового штурма. Хорошим подспорьем для этого этапа работ является
имеющаяся у Разработчика классификация рисков.
Так, все риски принято для делить на прямые (те, на которые Разработчик может так или
иначе влиять) и косвенные (независимые от Разработчика) [15.6].
М. Фаулер [15.7] предложил разделить все риски на четыре категории:
риски, связанные с требованиями,
технологические риски,
риски, связанные с квалификацией персонала,
политические риски.
Распространенные факторы риска, связанные с требованиями, включают неверное
понимание требований, недостаточное вовлечение пользователей, неточности или
изменения в масштабах и целях проекта, постоянно нестабильные требования. Подробный
анализ этих видов рисков можно найти в [15.5], глава 23.
Анализ риска сводится к исследованию и описанию потенциальных последствий
конкретных факторов риска для проекта, а также вероятности их проявления.
Определение приоритетов состоит из поиска ответов на два вопроса: насколько вероятно
проявление риска в проекте; насколько разрушительны могут быть последствия его
проявления.
Обнаруженные риски помещаются в специальный документ - risk list.
Существуют три основные стратегии поведения в отношении рисков:
Предотвращение риска, передача риска, принятие риска.
Предотвращение риска (risk avoidance) - это процесс реорганизации проекта таким образом,
чтобы риск не мог на него воздействовать. Например - отказаться от вновь появившихся
передовых инструментов в пользу испытанных, не включать в план те функции, которые
требуют освоения новых технологий.
Передача риска - перераспределение работ проекта таким образом, чтобы кто-то другой
(Заказчик, партнер и т.п.) отвечал за работу с ним.
Принятие риска обязывает Разработчика "заботиться" о нем. Мероприятия по контролю
риска (risk control) включают планирование, разрешение и мониторинг.
Планирование управления риском подразумевает создание плана действий для каждого
отдельного фактора, включая методы смягчения, планы на случай непредвиденных
обстоятельств, ответственных лиц и сроки исполнения. Цель действий по смягчению
воздействия риска - либо не позволить риску стать проблемой, либо уменьшить его
вредное воздействие.
Некоторые риски могут быть разрешены в процессе работы над проектом, они удаляются
из списка рисков, другие - напротив, обнаружены в ходе выполнения проекта и добавлены
в этот документ.
Мониторинг рисков призван осуществлять наблюдение над рисками из списка,
отслеживать их продвижение вплоть до разрешения, работать с их приоритетами.
1.19 Заключение
1.19.1 Современные тенденции в развитии АИС и
технологий их создания
Индустрия производства АИС претерпела за 2 последних десятилетия качественные
изменения. Это связано с такими тенденциями компьютерного мира и мировой экономики,
как:
развитием и появлением новой элементной базы,
наступлением эпохи персональных компьютеров,
появлением и развитием интегрированных сред разработки,
появлением глобальных сетей передачи данных,
глобализацией бизнеса,
ростом конкуренции,
переходом к экономике, ориентированной на потребителя,
появлением и развитием электронного бизнеса и др.
АИС прошли путь от однопользовательских систем к системам масштаба рабочей группы,
малого предприятия, холдинга, транснациональной корпорации.
Среди современных тенденций в развитии технологий создания АИС следует отметить:
быстрые методы прототипирования,
ориентацию на варианты использования,
переход от разработки к настройке.
1.19.2 Покупное или заказное ПО - критерии выбора
В мире IT существует определенная конкуренция между заказными и покупными
системами. Основной аргумент сторонников заказных систем - "каждый серьезный бизнес
уникален и требует собственной разработки; универсализм - синоним бедности".
Аргументы их противников - "количество типовых решений конечно и невелико. Одни и те
же организационные решения работают в различных отраслях промышленности".
Существует значительное количество аргументов в пользу покупных систем, например:
1. ERP-система X разрабатывается вендором Y уже Z лет. За это время он освоил
рынки крупнейших стран Запада, позади тысячи внедрений, что говорит о
высоком качестве системы.
2. КИС базируется на референтной (эталонной) модели бизнеса. Данная модель
апробирована на предприятиях десятков государств и отраслей промышленности
и помимо собственно системы вы (покупатель) получите подробные инструкции о
том, как правильно вести бизнес и побеждать в конкурентной борьбе.
На порождение этих аргументов работают отделы маркетинга таких гигантов этого
сегмента IT-индустрии, как SAP, Oracle, SAGE, Microsoft, SSA Global и др. И эти
аргументы действительно и серьезны и убедительны. Тем не менее, несмотря на мощный
прессинг лидеров производства КИС, по данным обзоров, соотношение заказных и
покупных систем автоматизации предприятий в мире оценивается, примерно, как 50:50.
По сути, выбор осуществляется даже не из 2, а из 3 вариантов:
1. закупить решение у вендора;
2. заказать эксклюзивное решение у фирмы-производителя прикладного
программного обеспечения.
3. изготовить решение самостоятельно.
Основные критерии выбора:
цена;
степень уникальности бизнеса компании;
уровень сервисного обслуживания.
Ценовые вопросы сводятся к анализу затрат на:
закупку (или разработку),
мероприятия по внедрению решения,
владение (включая необходимые доработки).
Степень уникальности бизнеса компании характеризуется степенью
особенностей бизнеса компании в решениях, представленных на рынке.
отражения
Уровень сервисного обслуживания характеризуется наличием поддержки покупного
программного обеспечения по месту размещения предприятия компании, политикой
вендора (разработчика) в области поддержки, наличием горячей линии и т.п.
На практике зачастую используется комбинация 1 и 3, либо 2 и 3 вариантов: система
закупается, либо разрабатывается на стороне, внедряется, затем ее сопровождение и
развитие переходит к отделу автоматизации предприятия.
1.19.3 Стратегии выбора решения
Перед специалистом IT-отдела, либо независимым консультантом, которому поручен
выбор решения в области автоматизации предприятия, стоит нелегкая задача. Ведь на
рынке представлены сотни решений в области автоматизации и чтобы хотя бы бегло
ознакомиться с каждым из них может потребоваться несколько человеко-лет.
На практике, конечно, вряд ли путь подробного изучения всех известных на рынке
решений можно рассматривать всерьез. В простейшем случае рассматриваются
аналитические обзоры, подготовленные независимыми экспертами, оцениваются
финансовые возможности предприятия внедрения и на третейский суд инвестора
предоставляются 2-3 решения.
Чтобы сделать выбор обоснованным, используются стратегии выбора решения. Основные
из них:
анализ требований,
анализ несоответствия,
подход на основе "лучших практик".
Анализ требований
Рациональным приемом, позволяющим снизить затраты на подготовку вариантов решения,
а заодно снизить риски, является формирование документа требований (не только ко вновь
создаваемому, но и к выбираемому продукту). Тем самым, часть работы можно переложить
на представителей маркетинговых отделов вендоров - пусть
продемонстрируют, как на практике реализуются Ваши требования.
они
объяснят
и
Практическое применение методов анализа требований, рассмотренных на протяжении
лекционного курса, применительно к задаче выбора покупного решения, требует ответа на
следующие вопросы:
рамки проекта;
широта анализа требований;
глубина проработки требований;
требуемые ресурсы.
Рамки проекта. Какие бизнес-процессы, подразделения, отделы предприятия необходимо
автоматизировать? Практика внедрения ERP-систем показывает, что даже на самых
передовых в информационном смысле предприятиях степень охвата бизнеса
информационными технологиями редко превышает порог в 90%. Возможно,
крупномасштабный проект автоматизации следует разбить на несколько этапов, начав,
допустим, с планки в 30%. Другая стратегия - "все и сразу" предполагает попытку сразу
выйти на максимально возможный охват функций.
Широта анализа требований. Сколько требований вы в состоянии сформулировать в
течение разумного промежутка времени? Сколько времени уйдет у вендоров на анализ
документа требований, который вы подготовите? Д. О'Лири в [16.1] дает следующий
порядок: документ описания требований для предприятия с годовым оборотом в $40 млн.,
содержит около 1000 позиций (требований).
Глубина проработки требований. Какую выбрать степень детализации требований?
Уровень документа "Концепция" вряд ли окажется достаточным для серьезного
рассмотрения. Необходимо отражать как функциональные, так и нефункциональные
требования. Можно остановиться на кратких формулировках функций (лаконично, трудно
проверяемо). Можно перейти на язык сценариев (появляется возможность доскональной
проверки, но это потребует значительных ресурсов). Хорош вариант с комбинацией этих
способов описания: критичный функционал описать в форме сценариев, остальное - в виде
функций.
Требуемые ресурсы. Ключевой ресурс предприятия - человеческий ресурс. Найдут ли топменеджеры предприятия время на скрупулезную оценку требований к системе? Насколько
хорошо смогут сформировать требования руководители линейных подразделений?
Насколько удастся задействовать ресурс поставщиков решений? Стоит ли привлекать
внешних консультантов?
Какова цена обследования? Как быстро удастся сформировать требования? Какое время
следует выделить на получение ответов от вендоров, на анализ этих ответов перед
окончательным выбором?
Анализ несоответствия
Анализ несоответствия при выборе КИС базируется на классических методах бизнесанализа, предпологающих построения моделей "как есть", "как надо" и переходной модели,
показывающей путь реформирования предприятия [16.2].
Нюанс заключается в том, что в данном случае анализ "как есть" применяется не к бизнессистеме в чистом виде, а к ее комбинации с имеющейся автоматизированной системой. Он
призван высветить слабые стороны и имеющегося решения и связанные с ним проблемы
бизнеса.
Анализ "как надо" может производиться по одному из следующих сценариев:
"реинжиниринга чистого листа" и "реинжиниринга, запускаемого технологией" [16.1].
В первом случае используются классические подходы к реинжинирингу предприятий
[16.2,16.3] в комбинации с методами анализа и формирования требований.
Во втором случае речь идет о реинжиниринге под конкретное ERP-решение. В этом случае
основой для пересмотра действующих бизнес-процессов и уровня их автоматизации
являются "лучшие практики", заложенные в соответствующей ERP-системе.
Как и в стратегии анализа требований, стратегия анализа несоответствия оставляет
множество подводных камней и вопросов. Допустим, мы составили модель "надо" и
рассматриваем спецификации конкурирующих ERP-системы. Как сопоставить эти два
документа? Как измерить степень соответствия - по количеству функций? Где гарантии
того, что функции, называющиеся
действительно одинаково работают?
одинаково
в
рассматриваемых
документах,
Альтернативой рассмотренным выше стратегиям, позволяющей снизить степень
неопределенности принятия решений, в определенной мере является подход на основе
лучших практик [16.1].
Подход на основе лучших практик
Подход основан на отказе от моделей "как есть". Предлагается не зацикливаться на
существующих на предприятии бизнес-процессах, а запустить процесс реинжиниринга,
основываясь на "лучших практиках" внедряемого ERP-решения. Основные доводы за
применение данного подхода [16.1].
1. Каждый пакет ERP соответствует нуждам организации. Выбранная ERP-система
имеет приблизительно тот же набор лучших практик, что и любая другая и все
они примерно эквивалентны.
2. Копировать существующие процессы не имеет смысла. Организация должна
осуществлять автоматизацию, основываясь на "реинжиниринговом потенциале"
ERP-системы.
3. Априорный анализ лучших практик не должен использоваться. Анализ лучших
практик должен осуществляться в контексте конкретной части ПО выбранной
ERP-системы.
4. Следует не "загибать решение под существующий бизнес", а, напротив,
реорганизовать бизнес на основе лучших практик так, чтобы изменения в ERPсистемы были минимальны. Это позволит снизить цену внедрения и цену
владения ERP-системами.
1.19.4 Процесс выбора решения
Выбор решения для построения на предприятии корпоративной АИС - очень
ответственный процесс, связанный с вопросами защиты инвестиций и выживания на
рынке. Значительное количество проектов по внедрению ERP-систем заканчивается
провалом, особенно это касается российской практики. Более того, на Западе существуют
прецеденты, когда предприятия, поставившие "на карту ERP" свое благосостояние и
связавшие с ними планы развития, попросту обанкротились, не справившись с задачей
"реинжиниринга под ERP".
Поэтому задачу выбора решения следует рассматривать в рамках проектного и
процессного подходов, со всеми вытекающими отсюда последствиями.
В формально проработанных процессах внедрения решений недостатка нет. Как правило,
они разрабатываются и поставляются вендорами вместе с самими решениями. Вопросы
организации выбора решений проработаны в литературе значительно хуже.
Ниже рассмотрен практический процесс, принятый компанией Chesapeake Display &
Packaging при выборе ERP-решения - процесс быстрого выбора для быстрого внедрения1)
на базе обзора, представленного в [16.1].
Процесс организован достаточно просто. Он предусматривает выполнение следующих
этапов:
cформировать команду "выборщиков";
организовать демонстрацию КИС поставщиками;
осуществить предварительный отбор;
осуществить выбор.
Сформировать команду. Команда должна быть небольшой и тщательно подобранной.
Критерии отбора - знание бизнеса и бизнес-процессов; включение людей с различными
взглядами, сочетание узкоспециализированных специалистов и специалистов широкого
профиля. Ограничение на размеры команды - не более 10 человек.
Организовать демонстрацию КИС поставщиками. Выбор ограниченного количества
производителей высококачественных КИС. Предложение выбранным производителям
подготовить демонстрацию для команды "выборщиков". Ограничение доступа
представителей производителей к членам команды до момента демонстрации. Срок
подготовки - 3 недели. Продолжительность демонстрации - 2 дня. Свобода выбора для
вендора оборудования и СУБД.
Осуществить предварительный отбор. Поставщикам высказываются следующие
требования:
показать, что КИС сможет работать с вашим бизнесом;
показать, что вы сможете внедрить его в течение требуемого времени;
показать свое понимание отрасли.
После проведения демонстрации на основе указанных требований осуществляется выбор
тройки лидеров.
Осуществить выбор. Выбор осуществляется на основе голосования, большинством
голосов. Голосование производится на основе двух факторов:
наиболее подходящие функциональные возможности;
лучший персонал по внедрению.
Каждая из опций ПО оценивается в трехбалльной шкале (3 - наивысший балл). Оценки
осуществляются членами команды по группам компетенции
1.20 Список литературы
1. Макарова Н.В
Информатика: Учебник
М.: Финансы и статистика, 2003. - 768 с
2. Дэниел О'Лири
ERP системы. Современное планирование и управление ресурсами
предприятия. Выбор, внедрение, эксплуатация
М.: ООО "Вершина", 2004. - 272 с, [Пер. с англ. Ю.И.Водопьяновой
3. Меняев М.Ф
Информационные технологии управления: Книга 3: Системы управления
организацией
М.: Омега-Л, 2003. - 464 с
4. Автоматизированные информационные системы, базы и банки данных.
Вводный курс: Учебное пособие
М.: Гелиос АРВ, 2002. - 368 с., ил
5. Б.Н. Гайфуллин, И.А. Обухов
Автоматизированные системы управления предприятиями стандарта
ERP/MRPII. Производственное издание
М. "Богородский печатник", 2001, 104 с
6. Петров В. Н
Информационные системы
СПб.: Питер, 2002. - 688 с
7. IEEE Standard Glossary of Software Engineering Terminology
IEEE Std 610.12-1990
8. Вигерс Карл
Разработка требований к программному обеспечению
Пер, с англ. - М.:Издательско-торговый дом "Русская Редакция", 2004. -576с.: ил
9. Леффингуелл Д., Уидриг Д
Принципы работы с требованиями к программному обеспечению
М.: ИД "Вильямс", 2002
10. Алистер Коберн
Современные методы описания функциональных требований к системам
М.: издательство "Лори", 2002. - 263 с
11. Мацяшек Лешек
Анализ требований и проектирование систем. Разработка
информационных
Пер. с англ. - М.: Издательский дом "Вильямс", 2002. - 432 с.: ил. - Парал. тит.
Англ
12. Орлик С., Булуй Ю
Введение в программную инженерию и управление жизненным циклом
ПО Программная инженерия. Программные требования
13. IEEE Guide to the Software Engineering Body of Knowledge
14. ГОСТ Р ИСО/МЭК 12207/99. Государственный стандарт РФ.
Информационная технология. Процессы жизненного цикла
информационных систем
Издание официальное. - М., 1999
15. Л.Новиков
Введение в Rational Unified Process
16. Белые страницы MSF
17. Analyzing requirements and defining Microsoft .Net solution architectures
2000 г. 491 стр. Microsoft Press
18. Ф. Кратчен
Введение в Rational Unified Process
19. А. Якобсон, Г. Буч, Дж. Рамбо
Унифицированный процесс разработки программного обеспечения
20. IEEE 1362 - Concept of Operations Document
21. IEEE 1233 - Guide for Developing System Requirements Specifications
22. IEEE Standard 830-1998, "IEEE Recommended Practice for Software
Requirements Specifications"
23. Петров В. Н
Информационные системы
СПб.: Питер, 2002. - 688 с
24. Microsoft Solutions Framework. Модель процессов MSF, версия 3.1
25. Каменова, Громов
Моделирование бизнеса. Методология ARIS
М.: Весть-МетаТехнология, 2001
26. Коберн А
Быстрая разработка программного обеспечения
М.: Лори, 2002. 314 с
27. Брауде Э
Технологии разработки программного обеспечения
СПб: Питер, 2004. - 655 с.: ил
28. А. Якобсон, Г. Буч, Дж. Рамбо
Унифицированный процесс разработки программного обеспечения
СПб.: Питер , 2002. - 496 с
29. Э.В.Попов
Искусственный интеллект: в 3 книгах, кн. 2. Модели и методы
М.: Радио и связь. - 1990
30. Марка Д.А
Методология структурного анализа и проектирования
СПб.: Питер, 1995. - 235 с
31. Марка Д., МакГоуэн К
Методология структурного анализа и проектирования
М.: МетаТехнология, 1993
32. ГОСТ 34.601-90. Информационная технология. Автоматизированные
системы. Стадии создания
33. Фаулер М, Скотт К
UML в кратком изложении. Применение стандартного языка объектного
моделирования
Пер. с англ. - М.:Мир, 1999. - 191 с., ил
34. Алистер Коберн
Современные методы описания функциональных требований к системам
35. Леоненков
Самоучитель UML
36. Маклаков С.В
Bpwin Erwin Case-средства разработки информационных систем
Москва "ДиалогМифи " - 2000
37. Орлов C
Технологии разработки программного обеспечения: Учебник
СПб.: Питер, 2002. - 464 с.: ил
38. ГОСТ 19.201-78 "Техническое задание, требования к содержанию и
оформлению"
39. ГОСТ 34.602-89 "Техническое задание на создание автоматизированной
системы" (ТЗ на АС)
40. Соммервилл, Иан
Инженерия программного обеспечения, 6-е издание
Пер. с англ. - М.: Издательский дом "Вильямс", 2002. - 624 с.: ил. - Парал. тит.
англ
41. Орлик С
Программная инженерия. Качество программногообеспечения (Software
Quality)
42. Калянов Г. Н
Консалтинг при автоматизации предприятий: Научно-практическое
издание
Серия "Информатизация России на пороге XXI века". - М.: СИН-ТЕГ, 1997
43. А.Л. Раскин
Руководство по применению стандарта ИСО 9001:2000 при разработке
программного обеспечения
М.: РИА "Стандарты и качество", 2002. - 104 с. - ("Дом качества", вып. 9 (18))
44. Астелс, Дэвид; Миллер Гранвилл; Новак, Мирослав
Практическое руководство по экстремальному программированию
Пер. с англ. - М.: Издательский дом "Вильямс", 2002. - 320 с.: ил. - Парал. тит.
англ
45. Бек К
Экстремальное программирование
СПб.: Питер, 2002. - 224 с
ВВЕДЕНИЕ
Настоящие
Правила
функционирования
Системы
добровольной
сертификации программного обеспечения (ПО) (программных продуктов (ПП))
средств измерений (СИ) и информационно-измерительных систем (далее
СДС ПО СИИИС), созданной Всероссийским научно-исследовательским
институтом метрологической службы (ФГУП «ВНИИМС») (119361, г. Москва, Г-361,
ул. Озерная, 46), устанавливают: перечень объектов, подлежащих добровольной
сертификации; требования, на соответствие которым они сертифицируются;
организационную структуру СДС ПО СИИИС и функции ее участников; правила
выполнения работ по добровольной сертификации. Правила предназначены для
юридических лиц и индивидуальных предпринимателей, разрабатывающих и
использующих программное обеспечение (программные продукты) средств
измерений и информационно измерительных систем и желающих подтвердить
соответствие программного обеспечения (программного продукта) средств
измерений и информационно измерительных систем требованиям:
ГОСТ Р ИСО/МЭК 17025-2000 «Общие требования к компетентности
испытательных и калибровочных лабораторий»; ГОСТ Р 8. 596-2002 «ГСИ.
Метрологическое обеспечение измерительных систем. Общие положения»;
Рекомендации МИ 2891-2004 «ГСИ. Общие требования к программному обеспечению средств измерений»
Кроме того, перечисленное выше программное обеспечение (программные
продукты) должно также соответствовать требованиям: ГОСТ Р ИСО/МЭК 121992000 «Информационная технология. Пакеты программ. Требования к качеству и
тестирование»;
Актуализированных ГОСТов «Единой системы программной документации»;
ГОСТ Р 34.11-94 «Информационная технология. Криптографическая
защита информации. Функция хеширования»;
«ГОСТ Р 34.10-2001. Информационная технология. Криптографическая
защита информации. Процессы формирования и проверки электронной
цифровой подписи».
Перечисленные нормативные документы программного обеспечения
(программных продуктов) в дальнейшем обозначаются аббревиатурой НД
ПО.
1 АТТЕСТАЦИИ И ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
При проведении аттестации комиссией экспертов (экспертом) организации,
проводящей аттестацию, составляется методика аттестации, содержащая
детальное описание всех действий, выполняемых в процессе аттестации. При этом
в методике аттестации должны быть предусмотрены следующие основные этапы:
- выбор методов испытаний (тестирования) в соответствии с целями
испытаний и степенью их жесткости ----составление тестовых заданий в
соответствии с требованиями к ПО и с указанием контролируемых параметров и
характеристик, исходных данных и критериев, которым должны удовлетворять
результаты, полученные тестируемым ПО- проведение испытаний (тестирования)
и получение результатов
функционирования испытываемого (тестируемого) ПО в соответствии с
тестовыми заданиями;
- обработка результатов испытаний (тестирования) (сравнение результатов,
полученных испытываемым (тестируемым) ПО, с эталонными).
Методика аттестации оформляется для каждого отдельного ПО СИ, с учетом
его назначения, функциональных особенностей и применяемых методов
испытаний (тестирования).
Испытания (тестирование) ПО СИ при выбранной жесткости могут
проводиться на основе изучения документации, сопровождающей ПО, испытаний
(тестирования) с использованием аппаратных и программных средств, а также на
комплексной основе с использованием как документации, так и аппаратных и
программных средств.
При выполнении этапов, указанных в начале, т.е. при составлении методики
аттестации, рекомендуется придерживаться следующей последовательности
действий: - области применения;
- риска намеренных искажений результатов измерений;
- требуемой степени соответствия утвержденному типу;
- специфических задач аттестации.
По согласованию с разработчиком (заказчиком аттестации) устанавливается
жесткость испытаний ПО СИ с учетом
При выбранной жесткости в программу испытаний рекомендуется включать
следующие виды испытаний:
Низкая жесткость Средняя жесткость Высокая жесткость 1 2 3
1. Проверка документации.
1. Проверка документации.
1. Проверка документации.
2. Проверка разделения ПО и наличия защищенных интерфейсов (на основе
анализа документации).
2. Проверка разделения ПО и наличия защищенных интерфейсов (на основе
анализа документации и с использованием программных средств).
2. Проверка разделения ПО и наличия защищенных интерфейсов(с
использованием программных средств, в том числе на основе анализа исходного
кода).
3. Проверка соответствия утвержденному типу (на основе анализа
документации).
3. Проверка соответствия утвержденному типу (идентификация) (на основе
анализа документации и с использованием программных средств).
3. Проверка соответствия утвержденному типу (идентификация) (на основе
анализа документации и с использованием программных средств, в том числе на
основе анализа исходного кода).
4. Испытание (тестирование) функций ПО (с использованием аппаратных и
программных средств).
4. Испытание (тестирование) ПО с целью u1091 установления правильности
функционирования
и определения его свойств и характеристик, в том числе тестирование
обработки данных (с использованием аппаратных и программных средств).
4. Испытание (тестирование) ПО с целью установления правильности
функционирования и определения его свойств и характеристик и тестирование
обработки данных (с использованием аппаратных и программных
средств, в том числе на основе анализа исходного кода).
5. Установление степени защищенности ПО и данных (на основе анализа
документации).
5. Тестирование защищенности ПО и данных (с использованием
программных средств).
5. Тестирование защищенности ПО и данных (с использованием
программных средств, в том
числе на основе анализа исходного кода).
Примечание - Высокая жесткость испытаний с использованием анализа
исходного кода применяется в тех случаях, когда имеют дело с ПО сложных и
ответственных измерительных систем, в том числе систем, используемых при
коммерческих расчетах, или когда к таким системам предъявляются
исключительные требования по безопасности их функционирования. В обычных
случаях ограничиваются низкой и средней жесткостью испытаний, при которых
тестирование ПО осуществляется методом «черного ящика».
Определяются методы испытаний в соответствии с установленной
жесткостью испытаний, которые должны найти отражение в тестовых заданиях.
Составляются тестовые задания с учетом того, что эти задания
и/или исходные данные для их формирования, а также методы их
выполнения
должны
обеспечить
проверку
всех
основных
режимов
функционирования испытываемого (тестируемого) ПО, а также его соответствие
требованиям нормативной документации.
Тестовые задания разрабатываются с учетом установленных видов
испытаний, руководства пользователя, а также другой необходимой технической
документации, представляемой на аттестацию. Каждому требованию и/или
контролируемой функции u1076 должно соответствовать не менее одного
тестового задания.
В тестовых заданиях определяются контролируемые свойства, параметры и
характеристики ПО, методы испытаний тестируемого ПО, необходимые для этого
исходные данные, программные продукты, с которыми сравниваются результаты,
получаемые в процессе испытаний (эталонное ПО), а также критерии,
позволяющие производить оценку характеристик тестируемого ПО.
Описывается последовательность действий при проведении процедуры
испытаний (тестирования) в соответствии с установленной жесткостью испытаний
и перечнем разработанных тестовых заданий.
Результаты испытаний ПО признаются положительными, если:
- программа соответствует функциональным возможностям, описанным в
документации, и выполняет в рамках тестовых заданий все функции,
декларируемые в документации;
- полученные значения параметров и характеристик программы при
выполнении всех тестовых заданий удовлетворяют установленным критериям или
находятся в допустимых пределах отклонений от них;
- в программе реализованы необходимые методы защиты и идентификации
в соответствии с требованиями;
- программная документация соответствует требованиям нормативных
документов.
Если в процессе выполнения какого-либо из тестовых заданий произойдет
отказ программы, ее «зависание» или искажение результатов, то данное тестовое
задание может быть модифицировано для подтверждения
ошибки функционирования и повторено. Выявленные ошибки фиксируются в
протоколе испытаний.
По результатам испытаний ПО СИ составляется акт о результатах его
исследования (тестирования) неотъемлемой частью которого является протокол
испытаний,
подписанный
непосредственными
исполнителями
испытаний
(тестирования) .
Дальнейшие разделы рекомендации конкретизируют виды испытаний
(тестирования).
Система сертификации программного обеспечения средств измерений и
информационно-измерительных систем Правила функционирования
1.1 ПЕРЕЧЕНЬ ОБЪЕКТОВ, ПОДЛЕЖАЩИХ СЕРТИФИКАЦИИ, И ИХ
ХАРАКТЕРИСТИКИ
Объектами, подлежащими добровольной сертификации, являются:
- программное обеспечение средств измерений как автономное, так и
встроенное;
программное
обеспечение
измерительных
и
информационноизмерительных систем;
- программное обеспечение контроллеров и вычислительных блоков, не
входящих в состав информационно-измерительных систем.
Каждая позиция в перечне программного обеспечения (программных
продуктов), подаваемом заявителем для прохождения процедуры добровольной
сертификации, должна содержать следующую информацию:
- описание структуры ПО (ПП) и выполняемых функций, в том числе
последовательность обработки данных;
- описание функций и параметров ПО (ПП), подлежащих метрологическому
контролю (в соответствии с Рекомендацией МИ 2891-2004);
- описание реализованных в ПО (ПП) расчетных алгоритмов, а также их
блок-схемы;
- описание модулей ПО (ПП);
- перечень интерфейсов и перечень команд для каждого интерфейса,
включая заявление об их полноте;
- список, значение и действие всех команд, получаемых от клавиатуры,
мыши и других устройств ввода;
- описание реализованной методики идентификации ПО (ПП);
- описание реализованных методов защиты ПО (ПП) и данных;
- описание интерфейсов пользователя, всех меню и диалогов;
- описание хранимых или передаваемых наборов данных;
- руководство пользователя;
- характеристики требуемых системных и аппаратных средств, если эта
информация не приведена в руководстве пользователя.
Перечень документов, сопровождающих ПО (ПП), может корректироваться
соглашением между исполнителем и заказчиком сертификации ПО.
Графическая и текстовая информация в документации выполняется таким
образом, чтобы она была пригодна для полного и однозначного понимания.
Характеристиками ПО СИИИС, подлежащими процедуре добровольного
подтверждения
соответствия,
являются
характеристики,
являющиеся
количественными u1080 или качественными представлениями требований,
предъявляемых к ПО (ПП) и устанавливаемых НД ПО, а именно:
а) требований к структуре, т.е. к выделению частей, подлежащих
метрологическому контролю, а также к наличию и правильности функционирования
защищенных интерфейсов;
б) требований к идентификации;
в) требований к защите измерительной и иной хранимой и передаваемой
информации;
в) требований к соответствию характеристик тем, которые были установлены
и приписаны ПО (ПП) при испытаниях СИ и других устройств с целью утверждения
типа;
г) требований к степени влияния на метрологические и информационные
характеристики средств измерений, информационноизмерительных систем.
Для подтверждения гарантий обеспечения соответствия ПО (ПП)
установленным СДС ПО СИИИС требованиям в любой период деятельности
заявителя в организации (фирме) должна быть организована документально
оформленная Система контроля ПО СИИИС.
2 ОЦЕНКА ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
Представление всей необходимой документации на u1072 аттестацию в
соответствии с требованиями рекомендации МИ 2891, а также стандартов ГОСТ Р
ИСО/МЭК 12119 и ГОСТ Р ИСО 9127, является необходимым условием ее
проведения. Рекомендуемые виды проверки документации применяются при всех
степенях жесткости испытаний.
В соответствии с требованиями указанных нормативных документов
проверяется
наличие,
достаточность
и
правильность
представленной
документации. При этом проверяются следующие разделы документации:
Описание структуры ПО и последовательности обработки данных. Структура
ПО может быть представлена в виде одного или нескольких взаимосвязанных
модулей, реализующих функции ПО, с учетом разделения
ПО. Описание структуры ПО может быть осуществлено в графическом виде
с пояснениями и/или в текстовой форме. Описание каждого модуля ПО должно
включать:
- наименование модуля;
- функции, реализуемые модулем, и реализованные в модуле алгоритмы;
- данные, используемые и/или изменяемые модулем;
- названия связанных (вызываемых) модулей.
Проверяется
описание
всех
входных
и
выходных
данных,
последовательность обработки входных данных в структуре ПО и других
программноаппаратных компонентах системы. Данный раздел документации
должен содержать информацию о методе связи (интерфейсе) СИ и ПО, о данных,
получаемых от и передаваемых в СИ программным обеспечением, описание всех
аппаратных и программных компонент СИ, а также описание исполняемых файлов
(название, размер в мегабайтах).
Описание всех выполняемых функций и параметров ПО, с учетом
выделения частей, подлежащих метрологическому контролю (аттестации) с
внесением контролируемых функций и параметров в отдельный список.
Для всех функций ПО должны быть описаны входные и выходные данные, а
также результат выполнения.
Описание реализованных в ПО расчетных алгоритмов, а также их блоксхемы.
Должны быть приведены описания или логические схемы алгоритмов,
функции, реализуемые алгоритмами в ПО, а также все величины, рассчитываемые
с их помощью, и их формулы, данные о степени округления при расчетах (точность
алгоритмов).
Описание интерфейсов, меню, диалогов и перечень команд для каждого
интерфейса, включая заявление об их полноте, а также список, значение и
действие всех команд, получаемых от клавиатуры, мыши и других
устройств ввода.
Описание реализованного метода идентификации ПО. Проверяется наличие
информации о методе (алгоритме) идентификации ПО, способах идентификации
ПО в соответствии с реализованным методом,
о системе кодификации номера версии.
Описание реализованных методов защиты ПО и данных. Проверяется
описание реализованных методов (авторизация пользователя, журнал событий,
кодирование данных и т.д.) защиты ПО и данных от недопустимых изменений и искажений, а также наличие сообщений об
ошибках.
Примечания
1 Некоторые требования к документации в МИ 2891-04 охватывают
требования,приведенные в стандартах ГОСТ Р ИСО/МЭК 12119-2000, ГОСТ Р ИСО
9127-94. Поэтому при проверке соответствия документации указанным стандартам,
проверяются те требования к документации ПО, которые не регламентируются МИ
2891-04.2 Вся документация ПО проверяется на однозначность понимания и
непротиворечивость.
Все данные, в том числе выявленные несоответствия, полученные при
анализе документации ПО, заносятся в протоколы испытаний. Перечень
документов, сопровождающих ПО, объем и методы проверки документации могут
корректироваться соглашением между исполнителем и заказчиком аттестации ПО.
Под проверкой структуры ПО понимается проверка правильности выделения
его частей, подлежащих метрологическому контролю (аттестации), а также
проверка наличия и правильности функционирования защищенных интерфейсов.
Проверка правильности разделения ПО.
При низкой и средней жесткости испытаний правильность разделения ПО
проверяется посредством анализа документации, представленной заявителем
аттестации, а также с помощью программных средств.
Все функции и параметры ПО, которые используются при обработке
результатов измерений, влияют на них, или используются во вспомогательных
функциях должны быть отнесены к части ПО, подлежащей метрологическому
контролю (аттестации). На основе документации устанавливается реализованный
метод разделения ПО или отсутствие разделения.
Проверяются сведения о наличии защищенного интерфейса между частями
ПО, подлежащими и не подлежащими метрологическому контролю (аттестации).
В случае отсутствия разделения, все ПО подлежит метрологическому
контролю (аттестации), однако документация должна содержать перечень функций
и параметров, относящихся к контролируемым.
Этот перечень функций и параметров также подлежит проверке.
Для встроенного ПО его разделение и проверка разделения не проводятся.
При высокой жесткости испытаний правильность разделения ПО
дополнительно проверяется при помощи анализа его исходного кода.
По исходному коду ПО проверяется правильность реализации защищенного
интерфейса. Все модули, подпрограммы, процедуры, функции, параметры,
переменные и т.д., участвующие в обработке информации должны быть охвачены
защищенным интерфейсом.
По исходному коду рекомендуется составить структурную схему ПО (граф),
отображающую потоки данных в ПО и способы их управления. Это позволяет
проверить поступление измерительной информации только в
части ПО, подлежащие метрологическому контролю (аттестации), а также
убедиться в возможности обращения к функциям ПО, к его параметрам и к
данным, подлежащим метрологическому контролю (аттестации), только через
защищенный интерфейс.
Сведения о разделении ПО заносятся в протокол испытаний. По
результатам проверки может быть сделано замечание о неправильном разделении
ПО и дана рекомендация о соответствующих коррективах.
Проверка интерфейса(ов) ПО.
Проверяется возможность недопустимого воздействия на ПО и данные
через интерфейс(ы) ПО (СИ).
При низкой/средней жесткости, испытания проводятся на основе анализа
документации и тестирования ПО с использованием программных средств.
С помощью программных средств выполняются все функции ПО,
подлежащие метрологическому контролю (аттестации), и определяется их
соответствие представленной документации. Исследуются меню, подменю,
диалоги ПО с целью выявления не соответствующих документации функций,
параметров и команд.
Проверяется фильтрация ввода данных через интерфейс и возможность
введения недопустимых данных.
Для этой проверки в ПО могут вводиться данные:
- из диапазона допустимых значений;
- из диапазона недопустимых значений;
- данные на границах ограничений диапазона ввода;
- комбинации вышеуказанных категорий данных.
При высокой жесткости испытания проводятся на основе анализа исходного
кода ПО При этом:- выявляются недокументированные функции, процедуры,
параметры, переменные, команды и их использование в ПО;
- проверяется соответствие действия вводимых команд (с помощью
диалогов, командной строки и т.д.) представленной документации.
Возможно использование других методов проверки правильности
функционирования интерфейса(ов) ПО.
Под проверкой соответствия понимается проверка конкретного ПО на
соответствие тому типу, который был утвержден (зафиксирован) при его
аттестации, если такая аттестация ранее проводилась, а также проверка методов и
способов идентификации.
Проверка соответствия.
При низкой и средней жесткости испытаний проверка соответствия
утвержденному типу проводится на основе анализа представленной документации,
а также с использованием программных средств. При этом может приниматься во
внимание заявление заказчика аттестации об отсутствии изменений и
модификаций части ПО, подлежащей метрологическому u1082 контролю
(аттестации).
В случаях, когда имеются сомнения в полном соответствии конкретного ПО
утвержденному типу, может быть проведено выборочное тестирование тех
функций и частей ПО, относительно которых имеются указанные сомнения.
Проверка методов и способов идентификации программного обеспечения.
При низкой и средней жесткости испытаний методы и средства
идентификации ПО проверяются на основе документации и выполнения
функциональных испытаний (тестирования) ПО.
На основе документации проверяется описание реализованного метода
идентификации и способа работы с ним. В случае разделения ПО на программном
уровне устанавливается соответствие метода идентификации
принципу разделения ПО.
На основе анализа документации получают информацию обо всех частях
(модулях) ПО (с учетом его разделения), охватываемых идентификацией. Все
части ПО, подлежащие метрологическому контролю (аттестации) должны быть
охвачены алгоритмом идентификации.
Оценивается соответствие метода идентификации уровню требуемой
защиты. В качестве метода идентификации ПО может быть рекомендован номер
версии с учетом. МИ 2891.
Проверяется наличие номинального значения, идентифицирующего ПО
(номер версии, контрольная сумма и др.). Номинальное значение идентификации
ПО вносится в свидетельство об аттестации.
Проверяется функция идентификации ПО, например, выводом номера
версии на экран.
При высокой жесткости испытаний проводятся дополнительные испытания
на основе анализа исходного кода ПО. При этом устанавливается:
- охват идентификацией всех частей ПО, подлежащих метрологическому
контролю (аттестации), например, формирование номинального закрепляемого
значения идентификации;
- охват идентификацией частей ПО, не подлежащих метрологическому
контролю (аттестации);
- соответствие метода идентификации представленной документации.
Примечание - В случае изменения файлов, входящих в состав ПО и
охваченных
алгоритмом
идентификации,
изменение
значения,
идентифицирующего ПО, устанавливается при испытаниях по проверке защиты от
искажений ПО и данных.
3 СИСТЕМЫ СЕРТИФИКАЦИИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ И ЕЕ
СТАНДАРТЫ
Схема организационной структуры СДС ПО СИИИС представлена в
Приложении.
Организацией,
создавшей
систему,
является
ФГУП
«ВНИИМС»,
разработавшее ГОСТ Р 8.596-2002 «ГСИ. Метрологическое обеспечение из
мерительных систем. Общие положения» и рекомендацию МИ 2891-2004
«ГСИ. Общие требования к программному обеспечению средств
измерений».В качестве органа по
сертификации выступает Автономная
некоммерческая организация «Межрегиональный испытательный центр» (АНО
«МИЦ»), имеющая статус юридического лица, печать, штамп и расчетный счет в
банке.
Реквизиты органа по сертификации представлены в Приложении.
Организация, создавшая СДС ПО СИИИС, выполняет следующие функции:
- разрабатывает и утверждает Правила функционирования СДС ПО СИИИС,
знак соответствия СДС ПО СИИИС и порядок его применения, а также другие
внутренние документы Системы;
- участвует в рассмотрении u1089 спорных вопросов, возникающих при
функционировании СДС ПО СИИИС, и принимает по ним решения;
- осуществляет подготовку экспертов СДС ПО СИИИС. В соответствии с
требованиями указанных нормативных документов проверяется наличие,
достаточность и правильность представленной документации. При этом
проверяются следующие разделы документации:
Описание структуры ПО и последовательности обработки данных. Структура
ПО может быть представлена в виде одного или нескольких взаимосвязанных
модулей, реализующих функции ПО, с учетом разделения
ПО. Описание структуры ПО может быть осуществлено в графическом виде
с пояснениями и/или в текстовой форме. Описание каждого модуля ПО должно
включать:
- наименование модуля;
- функции, реализуемые модулем, и реализованные в модуле алгоритмы;
- данные, используемые и/или изменяемые модулем;
- названия связанных (вызываемых) модулей.
Проверяется
описание
всех
входных
и
выходных
данных,
последовательность обработки входных данных в структуре ПО и других
программноаппаратных компонентах системы. Данный раздел документации
должен содержать информацию о методе связи (интерфейсе) СИ и ПО, о данных,
получаемых от и передаваемых в СИ программным обеспечением, описание всех
аппаратных и программных компонент СИ, а также описание исполняемых файлов
(название, размер в мегабайтах).
Описание всех выполняемых функций и параметров ПО, с учетом
выделения частей, подлежащих метрологическому контролю (аттестации) с
внесением контролируемых функций и параметров в отдельный список.
Для всех функций ПО должны быть описаны входные и выходные данные, а
также результат выполнения.
Описание реализованных в ПО расчетных алгоритмов, а также их блоксхемы.
Должны быть приведены описания или логические схемы алгоритмов,
функции, реализуемые алгоритмами в ПО, а также все величины, рассчитываемые
с их помощью, и их формулы, данные о степени округления при расчетах (точность
алгоритмов).
Описание интерфейсов, меню, диалогов и перечень команд для каждого
интерфейса, включая заявление об их полноте, а также список, значение и
действие всех команд, получаемых от клавиатуры, мыши и других
устройств ввода.
Описание реализованного метода идентификации ПО. Проверяется наличие
информации о методе (алгоритме) идентификации ПО, способах идентификации
ПО в соответствии с реализованным методом,
о системе кодификации номера версии.
Описание реализованных методов защиты ПО и данных. Проверяется
описание реализованных методов (авторизация пользователя, журнал событий,
кодирование данных и т.д.) защиты ПО и данных от недопустимых изменений и искажений, а также наличие сообщений об
ошибках.
В соответствии со ст. 21 Федерального закона «О техническом
регулировании» орган по сертификации:
- осуществляет подтверждение соответствия объектов добровольного
подтверждения соответствия, в том числе при необходимости создает или
привлекает на договорной основе испытательные лаборатории, в которых
организует проведение испытаний ПО (ПП) по согласованным с заказчиком
методикам;
- выдает Сертификаты соответствия на объекты, прошедшие добровольную
сертификацию;
- предоставляет заявителю право на применение знака соответствия;
- приостанавливает или прекращает действие выданных им Сертификатов
соответствия.
Испытательные лаборатории выполняют следующие функции:
- проводят испытания ПО (ПП) по согласованным с заказчиком методикам;
- оформляют результаты испытаний соответствующими протоколами, на
основании которых орган по сертификации принимает решение о выдаче или об
отказе в выдаче Сертификатов соответствия.
Порядок
проведения
сертификации
программного
обеспечения
(программных продуктов) в СДС ПО СИИИС включает:
- подачу заявки на сертификацию;
- принятие решения по заявке на сертификацию, в том числе назначение
экспертов на проведение основных работ по сертификации из числа экспертов
органа по сертификации;
- оформление договора на проведение работ по сертификации;
- проведение сертификационной проверки ПО СИИИС, в том числе при
необходимости проведение испытаний ПО (ПП) по согласованным с заказчиком
методикам;
- принятие решения о выдаче Сертификата соответствия и разрешения
использования знака соответствия либо об отказе в выдаче Сертификата
соответствия;
- выдача Сертификата соответствия и разрешения использования знака
соответствия;
- занесение юридического лица или индивидуального предпринимателя и
перечня сертифицированного ПО (ПП) в Реестр СДС ПО СИИИС;
Все данные, в том числе выявленные несоответствия, полученные при
анализе документации ПО, заносятся в протоколы испытаний. Перечень
документов, сопровождающих ПО, объем и методы проверки документации могут
корректироваться соглашением между исполнителем и заказчиком аттестации ПО.
Под проверкой структуры ПО понимается проверка правильности выделения
его частей, подлежащих метрологическому контролю (аттестации), а также
проверка наличия и правильности функционирования защищенных интерфейсов.
Проверка правильности разделения ПО.
При низкой и средней жесткости испытаний правильность разделения ПО
проверяется посредством анализа документации, представленной заявителем
аттестации, а также с помощью программных средств.
Все функции и параметры ПО, которые используются при обработке
результатов измерений, влияют на них, или используются во вспомогательных
функциях должны быть отнесены к части ПО, подлежащей метрологическому
контролю (аттестации). На основе документации устанавливается реализованный
метод разделения ПО или отсутствие разделения.
Проверяются сведения о наличии защищенного интерфейса между частями
ПО, подлежащими и не подлежащими метрологическому контролю (аттестации).
В случае отсутствия разделения, все ПО подлежит метрологическому
контролю (аттестации), однако документация должна содержать перечень функций
и параметров, относящихся к контролируемым.
Этот перечень функций и параметров также подлежит проверке.
Для встроенного ПО его разделение и проверка разделения не проводятся.
При высокой жесткости испытаний правильность разделения ПО
дополнительно проверяется при помощи анализа его исходного кода.
По исходному коду ПО проверяется правильность реализации защищенного
интерфейса. Все модули, подпрограммы, процедуры, функции, параметры,
переменные и т.д., участвующие в обработке информации должны быть охвачены
защищенным интерфейсом.
По исходному коду рекомендуется составить структурную схему ПО (граф),
отображающую потоки данных в ПО и способы их управления. Это позволяет
проверить поступление измерительной информации только в
части ПО, подлежащие метрологическому контролю (аттестации), а также
убедиться в возможности обращения к функциям ПО, к его параметрам и к
данным, подлежащим метрологическому контролю (аттестации), только через
защищенный интерфейс.
Сведения о разделении ПО заносятся в протокол испытаний. По
результатам проверки может быть сделано замечание о неправильном разделении
ПО и дана рекомендация о соответствующих коррективах.
Проверка интерфейса(ов) ПО.
Проверяется возможность недопустимого воздействия на ПО и данные
через интерфейс(ы) ПО (СИ).
При низкой/средней жесткости, испытания проводятся на основе анализа
документации и тестирования ПО с использованием программных средств.
С помощью программных средств выполняются все функции ПО,
подлежащие метрологическому контролю (аттестации), и определяется их
соответствие представленной документации. Исследуются меню, подменю,
диалоги ПО с целью выявления не соответствующих документации функций,
параметров и команд.
Проверяется фильтрация ввода данных через интерфейс и возможность
введения недопустимых данных.
Для этой проверки в ПО могут вводиться данные:
- из диапазона допустимых значений;
- из диапазона недопустимых значений;
- данные на границах ограничений диапазона ввода;
- комбинации вышеуказанных категорий данных.
При высокой жесткости испытания проводятся на основе анализа исходного
кода ПО При этом:- выявляются недокументированные функции, процедуры,
параметры, переменные, команды и их использование в ПО;
- проверяется соответствие действия вводимых команд (с помощью
диалогов, командной строки и т.д.) представленной документации.
Возможно использование других методов проверки правильности
функционирования интерфейса(ов) ПО.
Под проверкой соответствия понимается проверка конкретного ПО на
соответствие тому типу, который был утвержден (зафиксирован) при его
аттестации, если такая аттестация ранее проводилась, а также проверка методов и
способов идентификации.
Проверка соответствия.
При низкой и средней жесткости испытаний проверка соответствия
утвержденному типу проводится на основе анализа представленной документации,
а также с использованием программных средств. При этом может приниматься во
внимание заявление заказчика аттестации об отсутствии изменений и
модификаций части ПО, подлежащей метрологическому u1082 контролю
(аттестации).
В случаях, когда имеются сомнения в полном соответствии конкретного ПО
утвержденному типу, может быть проведено выборочное тестирование тех
функций и частей ПО, относительно которых имеются указанные сомнения.
Проверка методов и способов идентификации программного обеспечения.
При низкой и средней жесткости испытаний методы и средства
идентификации ПО проверяются на основе документации и выполнения
функциональных испытаний (тестирования) ПО.
На основе документации проверяется описание реализованного метода
идентификации и способа работы с ним. В случае разделения ПО на программном
уровне устанавливается соответствие метода идентификации
принципу разделения ПО.
На основе анализа документации получают информацию обо всех частях
(модулях) ПО (с учетом его разделения), охватываемых идентификацией. Все
части ПО, подлежащие метрологическому контролю (аттестации) должны быть
охвачены алгоритмом идентификации.
Оценивается соответствие метода идентификации уровню требуемой
защиты. В качестве метода идентификации ПО может быть рекомендован номер
версии с учетом. МИ 2891.
Проверяется наличие номинального значения, идентифицирующего ПО
(номер версии, контрольная сумма и др.). Номинальное значение идентификации
ПО вносится в свидетельство об аттестации.
Проверяется функция идентификации ПО, например, выводом номера
версии на экран.
При высокой жесткости испытаний проводятся дополнительные испытания
на основе анализа исходного кода ПО. При этом устанавливается:
- охват идентификацией всех частей ПО, подлежащих метрологическому
контролю (аттестации), например, формирование номинального закрепляемого
значения идентификации;
- охват идентификацией частей ПО, не подлежащих метрологическому
контролю (аттестации);
- соответствие метода идентификации представленной документации.
- проведение инспекционного контроля сертифицированного ПО (ПП).
При разработке методик сертификационных испытаний ПО (ПП) СИИИС
могут быть использованы ГОСТ Р 8. 596-2002 «ГСИ. Метрологическое обеспечение
измерительных систем. Общие положения», а также рекомендации:
МИ 2955-2005. «ГСИ. Типовая методика аттестации программного
обеспечения средств измерений и порядок ее проведения»,
МИ 2174-91. «ГСИ. Аттестация алгоритмов и программ обработки данных
при измерениях. Основные положения»,
МИ 2517-99. «ГСИ. Метрологическая аттестация программного обеспечения
средств измерений параметров физических объектов и полей с использованием
компьютерных программ генерации цифровых тестовых сигналов»,
МИ 2518-99. «ГСИ. Метрологическая аттестация алгоритмов и программ
генерации цифровых тестовых сигналов».
4 ВИДЫ ИСПЫТАНИЙ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
Погрешность ПО представляет собой отличие результатов, полученных с
помощью испытываемого (тестируемого) ПО, от результатов, полученных при тех
же условиях эталонным ПО. При этом под эталонным понимается ПО, отвечающее
наивысшим требованиям к его точностным и функциональным характеристикам,
подтвержденным (в ряде случаев независимыми методами) при его неоднократном
тестировании.
Критерии отнесения ПО к эталонному условны и при проведении аттестации
ПО СИ являются предметом соглашения между заказчиками аттестации и ее
исполнителями. В качестве эталонного может быть использовано аттестованное
ПО.
К основным источниками погрешностей ПО относятся:
- программные ошибки вследствие неправильной записи исходного текста
программы на выбранном языке программирования, а также ошибки трансляции
программы в объектный код;
- алгоритмические ошибки, связанные с неполной или ошибочной
формулировкой необходимых условий решения;
- применение неустойчивых алгоритмов при решении плохо обусловленных*
измерительных задач;
- ошибки программного преобразования входных данных перед обработкой и
ошибки обратной процедуры, если она проводится;
- ошибки округления и др.
Порядок проведения испытаний (тестирования) ПО определяется тестовым
заданием и может включать в себя:
- анализ ПО и его алгоритмов, выбор контролируемых параметров,
характеристик и свойств;
- определение методов испытаний (тестирования) в соответствии с
выбранной жесткостью испытаний;
- определение критериев оценки погрешности, характеристик и параметров
ПО;
- выбор (или разработка) эталонного ПО;
- выбор (определение) исходных данных и/или их получение методом
генерации или какими-либо другими методами;
- получение результатов u1086 обработки исходных данных в испытываемом
(тестируемом) ПО (получение тестовых результатов);
- получение оценки погрешности ПО посредством обработки результатов
испытаний (тестирования) (сравнения тестовых результатов с эталонными);
- дополнительные исследования свойств, параметров и характеристик
используемых алгоритмов (адекватность измерительной задаче, область
устойчивости, время, затрачиваемое на обработку результатов измерений и т.п.).
Основными методами, применяемыми при оценке погрешности ПО,
являются:
* Обусловленность является мерой чувствительности решения к изменениям
входных данных. Хорошо обусловленная задача обладает свойством малого
изменения решения при малом же изменении входных данных, в то время как
плохо обусловленная задача при тех же условиях повлечет за собой
существенные изменения решения.
- сравнительные испытания с применением эталонного (аттестованного) ПО;
- в отсутствие эталонного (аттестованного) ПО сравнительные испытания с
использованием моделей исходных данных или с
применением метода генерации эталонных данных;
- испытания на основе исходного кода ПО, а также комбинации указанных
методов.
Метод оценки погрешности ПО выбирают с учетом наличия или возможности
разработки того или иного вида эталонного ПО, а также возможности применения
указанных методов в каждом конкретном случае.
При низкой/средней жесткости, испытания проводятся с применением одного
из методов сравнительных испытаний.
При высокой жесткости испытания проводятся на основе исходного кода ПО.
Сравнительные испытания с применением эталонного (аттестованного) ПО.
Данный метод испытания применяется при наличии эталонного
(аттестованного) ПО, с помощью которого могут быть идентично воспроизведены
функции испытываемого (тестируемого) ПО. В качестве эталонного
ПО при оценке погрешности ПО может быть применено:
- аттестованное ПО СИ аналогичного функционального u1085 назначения;
- специально разработанное ПО с функциями, идентичными тестируемому;
- стандартные пакеты коммерческого ПО (например, электронные таблицы,
пакеты математического и статистического ПО и т.д.).
К разработке эталонного ПО прибегают в тех случаях, когда испытываемое
(тестируемое) ПО является не очень сложным, а его алгоритмы достаточно
просты. Это означает, что затраты на разработку эталонного ПО должны быть
разумными и сопоставимыми со стоимостью работ по аттестации ПО. Данный
метод позволяет максимально учитывать особенности аттестуемого ПО, а также
метрологические характеристики соответствующего СИ, и может быть
рекомендован, в частности, при аттестации встроенного ПО.
Разрабатываемое эталонное ПО может содержать только функции и
параметры, подлежащие метрологическому контролю (аттестации). При этом в
некоторых случаях могут не учитываться особенности графического интерфейса
пользователя, а также функции, не участвующие в обработке результатов
измерений (например, функции отображения, хранения данных и т.д.).
К разработке эталонного ПО могут привлекаться специалисты организаций,
занимающихся разработкой программных средств.
Сравнительные испытания с использованием моделей исходных данных.
Метод аттестации с использованием моделей исходных данных
рекомендуется методикой МИ 2174 для аттестации алгоритмов обработки
результатов измерений. Метод позволяет оценить погрешность алгоритмов
сравнением результатов обработки тестируемыми алгоритмами заданных моделей
исходных данных с параметрами этих моделей.
Наборы моделей исходных данных выбираются таким образом, чтобы они
соответствовали частной измерительной задаче, решаемой тестируемыми
алгоритмами.
Генерация эталонных наборов данных
Метод генерации эталонных наборов данных применяется как альтернатива
использованию эталонного ПО (в случае его отсутствия или невозможности
использования) при оценке отдельных u1092 функций, реализуемых тестируемым
ПО, и, по сути, имитирует случайный характер измерительного процесса.
Эталонные данные получают путем генерации таких данных с помощью
специально разработанной программы – генератора эталонных данных, который
представляет собой алгоритм, предназначенный для моделирования эталонных
данных на основе выбранных (заданных) исходных данных.
Генератор эталонных данных реализуют на одном из алгоритмических
языков программирования или при помощи стандартного математического или
статистического программного пакета.
Исходные данные для испытаний, в том числе и для генерации эталонных
данных, формируются с учетом свойств реализованных алгоритмов. При этом
наборы исходных данных должны охватывать как можно
больший диапазон возможных значений, поступающих на обработку.
В наборы исходных данных могут быть включены:
- данные, близкие к наибольшим и наименьшим значениям, а также ряд
промежуточных значений;
- особые значения входных переменных - точки резкого возрастания или
разрыва производных, нулевые, единичные и предельно малые численные
значения переменных и т.п.
Если значения некоторой переменной зависят от значения другой
переменной, то испытания проводят при особых сочетаниях этих переменных
таких, как равенство обеих переменных, малое и предельно большое их различие,
нулевые и единичные значения и т.п.
Испытания на основе исходного кода ПО
При испытаниях на основе исходного кода ПО проверяется:
- соответствие структуры алгоритма представленной документации;
- запись алгоритма на выбранном языке программирования;
- адекватность выбранного алгоритма измерительной задаче (выявление
неустойчивых алгоритмов).
При проверке соответствия структуры алгоритма представленной
документации, по тексту программы может быть составлена блок-схема
реализуемого алгоритма, которая сравнивается с алгоритмом, изложенным в
документации. В случае нахождения u1088 различий в структуре алгоритмов
проводится дополнительный анализ элементов блок-схемы, в которых обнаружены
различия.
Проверяется правильность записи алгоритма на выбранном языке
программирования. При этом устанавливается соответствие кода правилам
программирования, наличие тупиков и висящих вершин, пустых переменных,
операторов, правильность организации циклов и т.д.
Соответствие выбранного алгоритма измерительной задаче осуществляется
путем математического анализа реализованного алгоритма обработки данных. При
этом исследуются логические и точностные характеристики реализованных
алгоритмов, анализируется пригодность и оптимальность примененных численных
методов к решению измерительной задачи.
Методы оценки погрешности ПО на основе исходного кода могут
корректироваться исполнителем и заказчиком аттестации ПО.
Обработка результатов испытаний (тестирования) ПО.
На основе полученных результатов испытаний (тестирования) рассчитывают
характеристики точности тестируемых алгоритмов: относительную погрешность
алгоритма и его исполнительную характеристику.
Могут быть оценены и другие характеристики алгоритмов такие, как их
сложность, скорость исполнения, адекватность измерительной задаче, выбор
численной схемы расчета, коэффициент обусловленности (устойчивости), область
устойчивости и т.п.
Относительная погрешность алгоритма. Вычисление относительной
погрешности алгоритма производится по формуле:
Исполнительная характеристика алгоритма .
Исполнительная характеристика алгоритма вычисляется по формуле:
Исполнительная характеристика показывает число потерянных цифр точности в
тестируемом программном обеспечении по сравнению с эталонным.
Перечень характеристик аттестуемого ПО может корректироваться
соглашением между исполнителем и заказчиком аттестации ПО.
Все определенные и оцененные характеристики и свойства алгоритмов
заносятся в протокол испытаний.
Критерии, которым должны удовлетворять определенные и оцененные
характеристики алгоритмов ПО, а также допускаемые значения характеристик
могут быть установлены на основе требований к точности решения измерительной
задачи, если они имеются, точности выполняемых расчетов (степени округления)
и.т.п. Критерии и допуски на значения характеристик фиксируются в тестовых
заданиях и согласовываются в рамках методики аттестации ПО с ее заказчиком.
Большинство процессов разработки программного обеспечения — это
процессы решения некоторых задач. Внешнее проектирование сводится к
решению такой задачи: «Переведите множество целей системы во внешние
спецификации», где цели — данные, а внешние спецификации — неизвестные.
В задаче проектирования логики модуля даны внешние спецификации модуля,
а неизвестное — текст его программы. Отладка — это задача на
построение исправления ошибки (неизвестное) по описанию
ее симптомов (данные).
Стандартизация — это деятельность, направленная на разработку и
установление требований, норм, правил, характеристик, как обязательных для
выполнения, так и рекомендуемых, обеспечивающая право потребителя на
приобретение товаров надлежащего качества, а также право на безопасность и комфортность труда. Цель стандартизации — достижение оптимальной степени упорядочения в
той или иной области посредством широкого и многократного использования
установленных положений, требований, норм для решения реально существующих,
планируемых или потенциальных задач. Основными результатами деятельности по
стандартизации должны быть повышение степени соответствия продукта (услуги),
процессов их функциональному назначению, устранение технических барьеров в международном товарообмене, содействие научно-техническому прогрессу и сотрудничеству в
различных областях.
Стандартизация связана с такими понятиями, как объект стандартизации и
область стандартизации. Объектом стандартизации обычно называют продукцию,
процесс, услугу, для которых разрабатывают те или иные требования, характеристики,
параметры, правила и т.п. Стандартизация может касаться либо объекта в целом, либо его
отдельных составляющих (характеристик). Областью стандартизации называют
совокупность взаимосвязанных объектов стандартизации.
Стандартизация
осуществляется
на
разных
уровнях.
Уровень
стандартизации зависит от того, участники какого географического, экономического,
политического региона мира принимают стандарт. Если участие в стандартизации
открыто для соответствующих органов любой страны, то это международная стандартизация. Региональная стандартизация — деятельность, открытая только для
соответствующих органов государств одного географического, политического или
экономического региона. Региональная и международная стандартизация осуществляется
специалистами стран, представленных в соответствующих региональных и
международных организациях (рис. 1.1).
Национальная стандартизация — стандартизация в одном конкретном государстве. При этом национальная стандартизация также может
осуществляться на разных уровнях: на государственном, отраслевом, в том или
ином секторе экономики (например, на уровне министерств), на уровне
ассоциаций, производственных фирм, предприятий (фабрик, заводов) и
учреждений.
ПРИНЦИПЫ РАЗРАБОТКИ ПО.
Процесс приобретения (acquisition process) состоит из действий и задач заказчика,
приобретающего программное средство (рис. 2.2). Инициирование приобретения включает
следующие задачи:
• определение заказчиком своих потребностей в приобретении, разработке или
усовершенствовании системы, программных
продуктов или услуг;
• анализ требований к системе;
• принятие решения относительно приобретения, разработки или
усовершенствования существующего ПС;
• проверку наличия необходимой документации, гарантий, сертификатов,
лицензий и поддержки в случае приобретения программного продукта;
• подготовку и утверждение плана приобретения, включающего требования к
системе, тип договора, ответственность сторон и т. д.
Заявочные предложения должны содержать:
• требования к системе;
• перечень программных продуктов;
• условия и соглашения;
• технические ограничения (например, среда функционирования
системы).
Заявочные предложения направляются выбранному поставщику (или нескольким
поставщикам в случае проведения тендера). Поставщик — это организация, которая
заключает договор с заказчиком на поставку системы, ПС или программной услуги на
условиях, оговоренных в договоре.
Подготовка и корректировка договора включают следующие задачи:
• определение заказчиком процедуры выбора поставщика, включающей критерии
оценки предложений возможных поставщиков;
• выбор конкретного поставщика на основе анализа предложений;
• подготовку и заключение договора с поставщиком;
• внесение изменений (при необходимости) в договор в процессе
его выполнения.
Надзор за деятельностью поставщика осуществляется в соответствии с действиями,
предусмотренными в процессах совместной оценки и аудита.
В процессе приемки подготавливаются и выполняются необходимые тесты.
Завершение работ по договору осуществляется в случае удовлетворения всех условий
приемки.
Процесс поставки (supply process) охватывает действия и задачи,
выполняемые поставщиком, который снабжает заказчика программным
продуктом или услугой (рис. 2.3).
Инициирование
поставки
заключается
в
рассмотрении
поставщиком
заявочных
предложений и принятии решения о согласии с выставленными требованиями и условиями
или предложение своих.
Планирование включает следующие задачи:
• принятие решения поставщиком относительно выполнения
работ своими силами или с привлечением субподрядчика;
• разработку поставщиком плана управления проектом, содер
жащего организационную структуру проекта, разграничение
ответственности, технические требования к среде разработки
и ресурсам, управление субподрядчиками и др.
Процесс разработки (development process) предусматривает действия и задачи,
выполняемые разработчиком, и охватывает работы по созданию ПС и его компонентов
в соответствии с за данными требованиями, включая оформление проектной и эксплуатационной документации; подготовку материалов, необходимых для проверки
работоспособности и соответствующего качества программных продуктов,
материалов, необходимых для организации обучения персонала, и т. д. (рис. 2.4).
Подготовительная работа начинается с выбора модели ЖЦ ПС, соответствующей
масштабу, значимости и сложности проекта. Действия и задачи процесса разработки
должны соответствовать выбранной модели. Разработчик должен выбрать, адаптировать к условиям проекта и использовать согласованные с заказчиком стандарты,
методы и средства разработки, а также составить план выполнения работ.
Анализ требований к системе подразумевает определение ее функциональных
возможностей, пользовательских требований, требований к надежности и безопасности,
требований к внешним интерфейсам и т. д. Требования к системе оцениваются исходя из
критериев реализуемости и возможности проверки при тестировании.
Проектирование архитектуры системы на высоком уровне заключается в
определении компонентов ее оборудования, ПС и операций, выполняемых
эксплуатирующим
систему
персоналом.
Архитектура
системы
должна
соответствовать требованиям, предъявляемым к системе, а также принятым
проектным стандартам и методам.
Анализ требований к ПС предполагает определение следующих характеристик для
каждого компонента ПС:
• функциональных возможностей, включая характеристики производительности и
среды функционирования компонента;
• внешних интерфейсов;
• спецификаций надежности и безопасности;
• эргономических требований;
• требований к используемым данным;
• требований к установке и приемке;
• требований к пользовательской документации;
• требований к эксплуатации и сопровождению.
Требования к ПС оцениваются исходя из критериев соответствия требованиям к
системе, реализуемости и возможности проверки при тестировании.
Проектирование архитектуры ПС включает следующие задачи (для каждого
компонента ПС):
• трансформацию требований к ПС в архитектуру, определяющую на высоком
уровне структуру ПС и состав его компонентов;
• разработку и документирование программных интерфейсов ПС и баз данных;
• разработку предварительной версии пользовательской документации;
• разработку и документирование предварительных требований к тестам и плана
интеграции ПС.
Архитектура компонентов ПС должна соответствовать требованиям, предъявляемым
к ним, а также принятым проектным стандартам и методам.
Детальное проектирование ПС включает следующие задачи:
• описание компонентов ПС и интерфейсов между ними на более
низком уровне, достаточном для их последующего самостоятельного кодирования и
тестирования;
• разработку и документирование детального проекта базы данных;
• обновление (при необходимости) пользовательской документации;
• разработку и документирование требований к тестам и плана
тестирования компонентов ПС;
• обновление плана интеграции ПС.
Кодирование и тестирование ПС охватывают следующие задачи:
• разработку (кодирование) и документирование каждого ком
понента ПС и базы данных, а также совокупности тестовых
процедур и данных для их тестирования;
• тестирование каждого компонента ПС и базы данных на соот
ветствие предъявляемым к ним требованиям. Результаты тес
тирования компонентов должны быть документированы;
• обновление (при необходимости) пользовательской докумен
тации;
• обновление плана интеграции ПС.
Интеграция ПС предусматривает сборку разработанных компонентов ПС в
соответствии с планом интеграции и тестирование агрегированных компонентов. Для
каждого из агрегированных компонентов разрабатываются наборы тестов и тестовые
процедуры, предназначенные для проверки каждого из квалификационных требований
при последующем квалификационном тестировании. Квалификационное требование — это
набор критериев или условий, которые необходимо выполнить, чтобы квалифицировать
программный продукт как соответствующий своим спецификациям и готовый к
использованию в условиях эксплуатации.
Квалификационное тестирование ПС проводится разработчиком в присутствии
заказчика (по возможности) для демонстрации того, что ПС удовлетворяет своим
спецификациям и готово к использованию в условиях эксплуатации. Квалификационное
тестирование выполняется для каждого компонента ПС по всем разделам требований при
широком варьировании тестов. При этом также проверяются полнота технической и
пользовательской документации и ее адекватность самим компонентам ПС.
Интеграция системы заключается в сборке всех ее компонентов, включая ПС и
оборудование. После интеграции система, в
свою очередь, подвергается
квалификационному тестированию на соответствие совокупности требований к ней. При
этом также производятся оформление и проверка полного комплекта документации на
систему.
Установка ПС осуществляется разработчиком в соответствии с планом в той
среде и на том оборудовании, которые предусмотрены договором. В процессе
установки проверяется работоспособность ПС и баз данных. Если устанавливаемое ПС
заменяет существующую систему, разработчик должен обеспечить их параллельное
функционирование в соответствии с договором.
Приемка ПС предусматривает оценку результатов квалификационного тестирования
ПС и системы и документирование результатов оценки, которые проводятся
заказчиком с помощью разработчика. Разработчик выполняет окончательную передачу
ПС заказчику в соответствии с договором, обеспечивая при этом необходимое обучение
и поддержку.
Процесс эксплуатации (operation process) охватывает действия и задачи оператора —
организации, эксплуатирующей систему (рис. 2.5).
Подготовительная работа включает проведение оператором следующих задач:
• планирование действий и работ, выполняемых в процессе эксплуатации, и
установку эксплуатационных стандартов;
• определение процедур локализации и разрешения проблем, возникающих в
процессе эксплуатации.
Эксплуатационное тестирование осуществляется для каждой очередной редакции
программного продукта, после чего она передается в эксплуатацию.
Эксплуатация системы выполняется в предназначенной для этого среде в
соответствии с пользовательской документацией.
Поддержка пользователей заключается в оказании помощи и консультаций при
обнаружении ошибок в процессе эксплуатации ПС.
Процесс сопровождения (maintenance process) предусматривает действия и задачи,
выполняемые сопровождающей организацией (службой сопровождения). Данный
процесс активизируется при изменениях (модификациях) программного продукта и
соответствующей документации, вызванных возникшими проблемами
или
потребностями в модернизации либо адаптации ПС. В соответствии со стандартом
IEEE-90 под сопровождением понимается внесение изменений в ПС в целях
исправления ошибок, повышения производительности или адаптации к изменившимся
условиям работы или требованиям.
Изменения, вносимые в существующее ПС, не должны нарушать его целостность.
Процесс сопровождения включает перенос ПС в другую среду (миграцию) и
заканчивается снятием ПС с эксплуатации (рис. 2.6).
Подготовительная работа службы сопровождения включает следующие задачи:
• планирование действий и работ, выполняемых в процессе со
провождения;
• определение процедур локализации и разрешения проблем, возникающих в
процессе сопровождения.
Анализ проблем и запросов на модификацию ПС, выполняемый службой
сопровождения, включает следующие задачи:
• анализ сообщения о возникшей проблеме или запроса на модификацию ПС
относительно его влияния на организацию, существующую систему и интерфейсы с другими
системами. При этом
определяются следующие характеристики возможной модификации: тип
(корректирующая, улучшающая, профилактическая или адаптирующая к новой среде);
масштаб (размеры модификации, стоимость и время ее реализации); критичность (воздействие на производительность, надежность или безопасность);
• оценку целесообразности проведения модификации и возможных вариантов ее
проведения;
• утверждение выбранного варианта модификации.
Модификация ПС предусматривает определение компонентов ПС, их версий и
документации, подлежащих модификации, и внесение необходимых изменений в
соответствии с правилами процесса разработки. Подготовленные изменения тестируются и
проверяются по критериям, определенным в документации. При подтверждении
корректности изменений в программах проводится корректировка документации.
Проверка и приемка заключаются в проверке целостности модифицированной системы и
утверждении внесенных изменений.
При переносе ПС в другую среду используются имеющиеся или разрабатываются новые
средства переноса, затем выполняется конвертирование программ и данных в новую
среду. С целью облегчить переход предусматривается параллельная эксплуатация ПС в
старой и новой среде в течение некоторого периода, когда проводится необходимое
обучение пользователей работе в новой среде.
Снятие ПС с эксплуатации осуществляется по решению заказчика при участии
эксплуатирующей организации, службы сопровождения и пользователей. При этом
программные продукты и соответствующая документация подлежат архивированию в
соответствии с договором. Аналогично переносу ПС в другую среду с целью облегчить
переход к новой системе предусматривается параллельная эксплуатация старого и нового
ПС в течение некоторого периода, когда выполняется необходимое обучение
пользователей работе с новой системой.
Стандартизация ПО.
В процессе стандартизации вырабатываются нормы, правила, требования,
характеристики, касающиеся объекта стандартизации, которые оформляются в виде
нормативного документа. Рассмотрим разновидности нормативных документов, которые
рекомендуются руководством 2-й Международной организации по стандартизации и
Международной электротехнической комиссии (ИСО/МЭК), а также принятые в
государственной системе стандартизации Российской Федерации (РФ). Руководство
ИСО/МЭК рекомендует: стандарты, документы технических условий, своды правил,
регламенты (технические регламенты), положения (рис. 1.2).
Стандарт (от англ. standard — норма, образец) — в широком смысле слова
образец, эталон, модель, принимаемые за исходные для сопоставления с ними других
подобных объектов. Стандарт как нормативно-технический документ устанавливает
комплекс норм, правил, требований к объекту стандартизации. Стандарт может быть
разработан как на материальные предметы (продукцию, эталоны, образцы веществ),
так и на нормы, правила, требования в различных областях. В переносном смысле —
шаблон, трафарет, не содержащий ничего оригинального.
Стандарт — это нормативный документ, разработанный на основе консенсуса,
утвержденный признанным органом, направленный на достижение оптимальной степени
упорядочения в определенной области. В стандарте устанавливаются для всеобщего и
многократного использования общие принципы, правила, характеристики, касающиеся
различных видов деятельности или их результатов. Стандарт должен быть основан на
обобщенных результатах научных исследований, технических достижений и практического
опыта, тогда его использование принесет оптимальную выгоду для общества.
Предварительный стандарт — это временный документ, который принимается
органом по стандартизации и доводится до широкого круга потенциальных
потребителей, а также до тех, кто может его применить. Информация, полученная в
процессе использования предварительного стандарта, и отзывы об этом документе
служат базой для решения вопроса о целесообразности принятия стандарта.
Стандарты
бывают
международными,
региональными,
национальными,
административно-территориальными. Они принимаются соответственно международными,
региональными, национальными, территориальными органами по стандартизации. Все эти
категории стандартов предназначены для широкого круга потребителей. По существующим
нормам стандартизации стандарты периодически пересматриваются для внесения
изменений, чтобы их требования соответствовали уровню научно-технического прогресса,
или, согласно терминологии ИСО/МЭК, стандарты должны представлять собой «признанные
технические правила». Нормативный документ, в том числе и стандарт, считается признанным
техническим правилом, если он разработан в сотрудничестве с заинтересованными
сторонами путем консультаций и на основе консенсуса.
Указанные выше категории стандартов называют общедоступными. Другие же категории
стандартов, такие, как фирменные или отраслевые, не являясь таковыми, могут, однако,
использоваться и в нескольких странах согласно существующим там правовым нормам.
В практике термин «стандарт» может употребляться и по отношению к эталону,
образцу или описанию продукта, процесса (услуги). По существу это не является
принципиальной ошибкой, хотя эталон правильнее относить к области метрологии, а термин «стандарт» использовать применительно к нормативному документу.
Документ технических условий (technical specification) устанавливает технические
требования к продукции, услуге, процессу. Обычно в документе технических условий
должны быть указаны методы или процедуры, которые следует использовать для
проверки соблюдения требований данного нормативного документа в таких ситуациях,
когда это необходимо.
Свод правил, как и предыдущий нормативный документ, может быть самостоятельным
стандартом либо самостоятельным документом, а также частью стандарта. Свод правил
обычно разрабатывается для процессов проектирования, монтажа оборудования и
конструкций, технического обслуживания или эксплуатации объектов, конструкций,
изделий. Технические правила, содержащиеся в документе, носят рекомендательный
характер.
Все указанные выше нормативные документы являются рекомендательными. В
отличие от них регламент носит обязательный характер. Регламент — это документ, в
котором содержатся обязательные правовые нормы.
Кроме стандартов нормативными документами являются также ПР — правила по
стандартизации, Р — рекомендации по стандартизации и ТУ — технические условия.
Особое требование предъявляется к нормативным документам на продукцию, которая
согласно российскому законодательству подлежит обязательной сертификации. В них
должны быть указаны те требования к продукции (услуге), которые подтверждаются
посредством сертификации, а также методы контроля (испытаний), которые следует
применять для установления соответствия, правила маркировки такой продукции и виды
сопроводительной документации.
Государственные стандарты разрабатывают на продукцию, работы и услуги,
потребности в которых носят межотраслевой характер.
Отраслевые стандарты разрабатываются применительно к продукции определенной
отрасли. Их требования не должны противоречить обязательным требованиям
государственных стандартов, а также правилам и нормам безопасности, установленным
для отрасли. Принимают такие стандарты государственные органы управления
(например, министерства), которые несут ответственность за соответствие требований
отраслевых стандартов обязательным требованиям ГОСТ Р.
Объектами отраслевой стандартизации могут быть:
• продукция, процессы и услуги, применяемые в отрасли;
• правила, касающиеся организации работ по отраслевой стан
дартизации;
• типовые конструкции изделий отраслевого применения (инст
рументы, крепежные детали и т.п.);
• правила метрологического обеспечения в отрасли.
Диапазон применяемости отраслевых стандартов ограничивается предприятиями,
подведомственными государственному органу управления, принявшему данный стандарт.
На добровольной основе возможно использование этих стандартов субъектами
хозяйственной деятельности иного подчинения. Степень обязательности соблюдения
требований стандарта отрасли определяется тем предприятием, которое применяет его, или
по договору между изготовителем и потребителем. Контроль за выполнением обязательных
требований организует ведомство, принявшее данный стандарт.
Стандарты предприятий разрабатываются и принимаются самими предприятиями.
Объектами стандартизации в этом случае обычно являются составляющие подсистем
организации и управления производством, совершенствование которых — главная цель
стандартизации на данном уровне. Кроме того, стандартизация на предприятии может
затрагивать и продукцию, производимую этим предприятием. Тогда объектами
стандарта предприятия будут составные части продукции, технологическая оснастка и
инструменты, общие технологические нормы процесса производства этой продукции.
Стандарты предприятий могут содержать требования к различного рода услугам
внутреннего характера.
Закон РФ «О стандартизации» рекомендует использовать стандартизацию на предприятии
для освоения данным конкретным предприятием государственных, международных,
региональных стандартов, а также для регламентирования требований к сырью, полуфабрикатам и т.п., закупаемым у других организаций. Эта категория стандартов обязательна
для предприятия, принявшего этот стандарт. Но если в договоре на разработку,
производство, поставку продукта или предоставление услуг имеется ссылка на стандарт предприятия, он становится обязательным для всех субъектов хозяйственной деятельности —
участников такого договора.
Правила и рекомендации по стандартизации по своему характеру соответствуют
нормативным документам методического содержания. Они могут касаться порядка
согласования нормативных документов, предоставления информации о принятых
стандартах отраслей, обществ и других организаций в Госстандарт РФ, создания службы
по стандартизации на предприятии, правил проведения государственного контроля за
соблюдением обязательных требований государственных стандартов и многих других
вопросов организационного характера. Правила и рекомендации по стандартизации
разрабатываются, как правило, организациями и подразделениями, подведомственными
Госстандарту РФ. Проект этих документов обсуждается с заинтересованными сторонами,
утверждается и издается этими комитетами.
Технические условия разрабатывают предприятия и другие субъекты хозяйственной
деятельности в том случае, когда стандарт создавать нецелесообразно. Объектом ТУ
может быть продукция разовой поставки, выпускаемая малыми партиями и т.п.
Стандарты в области промышленного обеспечения.
В Толковом словаре по информатике В.И. Першикова и В.М. Савинкова [52]
понятие стандартизация определяется как принятие соглашения по спецификации,
производству и использованию аппаратных и программных средств вычислительной техники; установление и применение стандартов, норм, правил и т.п.
Стандарты имеют большое значение - они обеспечивают возможность разработчикам
программного обеспечения использовать данные и программы других разработчиков,
осуществлять экспорт/импорт данных.
Такие стандарты регламентируют взаимодействие между различными программами.
Для этого предназначены стандарты межпрограммного интерфейса, например OLE
(Object Linking and Embedding — связывание и встраивание объектов). Без таких
стандартов программные продукты были бы «закрытыми» друг для друга.
Стандарты занимают все более значительное место в направлении развития индустрии
информационных технологий. Более 250 подкомитетов в официальных организациях по
стандартизации работают над стандартами в области информационных технологий. Более
1000 стандартов или уже приняты этими организациями, или находятся в процессе
разработки. Процесс стандартизации информационных технологий далеко не закончен (да,
по нашему мнению, вряд ли когда-либо будет закончен, так как область информационных
технологий постоянно динамично развивается).
Все компании-разработчики должны обеспечить приемлемый уровень качества
выпускаемого программного обеспечения (ПО). Для этих целей предназначены стандарты
качества программного обеспечения или отдельные разделы в стандартах разработки
программного обеспечения, посвященные требованиям к качеству программного
обеспечения.
С точки зрения пользователя, все многообразие ПО должно управляться
единообразно. Должна быть единообразная навигация — перемещение по программе,
единообразные органы управления ПО и единая реакция программного обеспечения на
действия пользователя. Для этого разработаны стандарты на пользовательский
интерфейс — GUI (Graphical User Interface). Все это регламентируется стандартами,
действующими в сфере информационных технологий.
Необходимость стандартизации разработки программного обеспечения наиболее
удачно описана во введении в стандарт ISO/ IEC 12207: «Программное обеспечение
является неотъемлемой частью информационных технологий и традиционных систем,
таких, как транспортные, военные, медицинские и финансовые. Имеется множество
разнообразных стандартов, процедур, методов, инструментальных средств и типов
операционной среды для разработки и управления программным обеспечением. Это разнообразие создает трудности при проектировании и управлении программным
обеспечением, особенно при объединении программных продуктов и сервисных
программ. Стратегия разработки программного обеспечения требует перехода от этого
множества к общему порядку, который позволит специалистам, практикующимся в
программном обеспечении, «говорить на одном языке» при разработке и управлении
программным обеспечением. Этот международный стандарт обеспечивает такой общий
порядок».
Попробуем внести порядок в многообразие стандартов, действующих в сфере ИТ, и
классифицировать их (рис. 1.3).
Как видно, верхняя часть классификации напоминает указанные выше виды стандартов.
Однако здесь появляются и свои особенности. Это относится прежде всего к стандартам
«де-юре» и «де-факто». Давайте сразу определим эти понятия.
Стандарт «де-факто» — термин, обозначающий продукт какого-либо поставщика,
который захватил большую долю рынка и который другие поставщики стремятся
эмулировать, копировать или использовать для того, чтобы захватить свою часть рынка.
Одна из главных причин значимости современной программы стандартизации —
осознание опасности злоупотребления стандартами «де-факто». В 60-е и 70-е годы XX
века создание стандартов «де-факто» ставило пользователей в зависимое от производителей
положение при использовании основных средств обработки данных и телекоммуникаций.
Важный аспект сегодняшней работы по стандартизации — преодоление этой зависимости
через продвижение стандартных интерфейсов. Долгое время такими стандартами были
SQL (Structured Query Language) и язык диаграмм Д. Росса SADT (Structured Analysis
and Design Technique).
Стандарт «де-юре» создается формально признанной стандартизующей организацией. Он
разрабатывается при соблюдении правил консенсуса в процессе открытой дискуссии, в
которой каждый имеет шанс принять участие. Ни одна группа не может действовать
независимо, создавая стандарты для промышленности. Если какая-либо группа поставщиков
создаст стандарт, не учитывающий требования пользователей, она потерпит неудачу. То же
самое происходит, если пользователи создают стандарт, с которым не могут или не будут
соглашаться поставщики, — этот стандарт также не будет успешным. Стандарты «де-юре»
не могут быть изменены, не пройдя процесс согласования под контролем организации,
разрабатывающей стандарты. Стандарты OSI (Open Systems Interconnection reference
model), Ethernet, POSIX, SQL и большинство стандартов языков — примеры такого рода
стандартов.
В качестве примера перехода стандарта «де-факто» в стандарт «де-юре» рассмотрим
историю развития и стандартизации языка SQL.
Работы по созданию языка SQL были начаты в 70-х годах прошлого столетия в
исследовательских лабораториях компании IBM. В настоящее время он стал одним из
главных стандартов в области информационных систем и обеспечил технологию базового
языка для целого поколения СУБД, основанных на реляционной модели. Несмотря на то,
что он был коммерчески реализован в начале 80-х годов лишь для небольшой группы
программных продуктов, SQL, бесспорно, получил признание с принятием ANSI и ISO
стандарта SQL-86. Позднее, при подготовке стандарта SQL-89, в язык был включен ряд
дополнительных возможностей.
Истоки SQL следует отнести к периоду рождения реляционной модели данных
(описанной в статье Э.Ф. Кодда) [65]. Поскольку в течение нескольких последующих лет
не появилось никаких языков, подобных SQL, в исследовательских проектах, инициированных компанией IBM после публикации статьи Э.Ф. Кодда, придавалось
особое значение необходимости создания языков интерфейса создаваемых СУБД для
проверки возможностей реляционной модели. Историю разработки языка SQL иллюстрирует рис. 1.4.
В исследовательских лабораториях IBM в начале 70-х годов 20 века одновременно с
работой над будущим языком SQL разрабатывались и другие проекты по созданию и
экспериментальной реализации реляционных языков. Вероятно, наиболее известным из
них является созданный М. Злуфом из лаборатории IBM в Йорктаун-Хейтс примерно в
одно и то же время с SEQUEL (ранней версией SQL) реляционный язык Query-By-Example
(QBE). Этот язык используется в настоящее время во многих коммерческих программных
продуктах наряду с SQL.
В 1974 г. Дональд Д. Чамберлин из Исследовательской лаборатории IBM в Сан-Хосе
предложил спецификации реляционного языка, названного SEQUEL (Structured
English QUEry Language). Пересмотренная версия этого языка (SEQUEL/2) была
разработана в 1976—1977 годах, и он приобрел свое окончательное название — SQL
(Structured Query Language).
Еще перед тем, как коммерческие продукты IBM в начале 80-х годов 20 века вышли на
рынок программного обеспечения, компания Relation Software Inc. (называющаяся
теперь Oracle Corporation) объявила о выпуске реляционной СУБД, основанной на
языке SQL. Эта система в результате ее эволюции стала одной из доминирующих
коммерческих систем и носит название ORACLE.
Продукт ORACLE с его языком SQL столкнулся с конкуренцией в сфере средних ЭВМ
и мини-ЭВМ со стороны продуктов ряда других разработчиков, в частности СУБД Ingres с
языком QUEL компании Relation Technology Inc., а также продукта Rdb/ VMS с языком
RDML компании Digital Equipment Corporation.
Одной из причин преуспевания SQL послужило формирование Американским
национальным институтом стандартов (American National Standards Institute, ANSI)
комитета ХЗН2, учрежденного для разработки стандартов языков баз данных. Представитель
IBM предложил использовать в качестве предварительных спецификаций реляционного
языка результаты ранее проведенной IBM работы над SEQUEL/2, и разработчики стандарта
приступили к работе. Документ, озаглавленный «SQL», представлял собой по большей части
трактат о различных формах SQL, используемых в коммерческих программных
продуктах.
Международная организация по стандартизации (International Standards Organization,
ISO) в рамках технического комитета ТС97 (называемого теперь как ISO/IEC JTC1) также
вела работу по созданию стандарта языков реляционных баз данных. В середине 80-х годов
как ANSI, так и ISO одобрили стандарты SQL (ANSI — в 1986 г., a ISO — в начале 1987 г.).
Первый стандарт SQL в связи со способом его разработки был весьма неполным в части
функциональных возможностей систем баз данных, и многие из поставщиков продолжали
вносить в свои программные продукты большой ряд расширений к стандарту. В 1989 г.
была принята пересмотренная версия стандарта SQL, которая отличалась от стандарта
1986 г. главным образом именно возможностями поддержки целостности по ссылкам.
Однако еще до 1989 г. как в ANSI, так и в ISO началась работа по радикальным
расширениям SQL. Эта работа, первоначально идентифицированная как «SQL2», началась в
1987 г., и ее результаты были спустя пять лет приняты в качестве стандарта SQL-92.
Добавляет путаницы еще и то обстоятельство, что работа над SQL2 перекрывалась
работой над SQL3, новой версией стандарта SQL, которая еще до сих пор находится в
стадии разработки. Работа над SQL3 началась еще в 1990 г. параллельно с SQL2, главным
образом как над «запасным резервуаром» для возможностей, которые предполагалось не
включать по тем или иным причинам в SQL2. SQL3 включает объектно-ориентированные
расширения языка, а также дополнительные реляционные возможности, которым не
нашлось места в SQL2 [53].
Проиллюстрируем на рис. 1.5 с привязкой к оси времени процесс разработки различных
стандартов SQL.
Следует отметить, что в области информационных технологий существуют два
основных исторически сложившихся подхода к разработке стандартов. Первый — когда
назревает проблема, — необходимость в стандарте. В этом случае собирается группа экспертов в каком-то разделе информационных технологий и обсуждает локальные решения,
придуманные отдельными компаниями — производителями программного обеспечения и
научными организациями, проводит анализ этих решений и разрабатывается единый
интегральный стандарт, который включает в себя лучшие идеи и наработки.
Но рынок живет по несколько иным законам. Первый подход обладает инертностью,
проблема уже назрела, ее надо решать, и неизвестно, когда соберутся эксперты и
разработают необходимый стандарт. Во втором случае компании — разработчики ПО
разрабатывают каждая свое решение, и самое популярное, массовое с точки зрения
частоты использования решение обретает статус стандарта (необязательно юридически).
Так, SQL стал стандартом языка обращения к базам данных, что называется «де-факто»,
хотя потом статус стандарта был закреплен юридически.
Недостаток этого подхода состоит в том, что стандартом становится не самое сильное, а
самое массовое коммерческое решение.
В качестве еще одного примера появления стандарта можно привести появление ныне
популярного UML — Unified Modeling Language. Основные разработки по методам
объектно-ориентированного анализа и проектирования появились между 1988 и 1992 гг.
К 1994 г. было большое количество неформальных лидеров разработчиков-практиков
(около полутора десятков), которые продвигали свои методологии. Все их методы были
схожи, при этом зачастую отличия между ними заключались во второстепенных деталях.
Назревал разговор о стандартизации. Команда из OMG пыталась рассмотреть проблему
стандартизации, но в ответ получила открытое письмо с протестом от всех авторов. В 1996 г.
три ведущих специалиста в области объектно-ориентированного анализа и проектирования
Джеймс Рамбо (James Rumbaugh), Гра-ди Буч (Grady Booch), Ивар Якобсон (Ivar Jacobson)
объединились, и появился на свет Унифицированный метод версии 0.8, в 1996 г. «трое
друзей» работали над своим методом, который получил название Unified Modeling Language.
В январе 1997 г. различные организации представили свои предложения по стандартизации
методов, предусматривающие в первую очередь возможность обмена информацией между
различными моделями. В результате сейчас имеется единственное предложение — стандарт
UML.
СЕРТИФИКАЦИЯ ПО.
Для удостоверения качества, надежности и безопасности применение сложных, критических
ИС используемые в них ПС следует подвергать обязательной сертификации аттестованными,
проблемно-ориентированными испытательными лаборатория»» Такие испытания
необходимо проводить, когда программы управляют сложными процессами или
обрабатывают столь важную информацию, что дефекты в них или недостаточное качество
м> гут нанести значительный ущерб. Сертификационные испытания должны
устанавливать соответствие комплексов программно* документации и допускать их к
эксплуатации в пределах изменения параметров внешней среды, исследованных при
проведении проверках. Эти виды испытаний характеризуются наибольшее строгостью и
глубиной проверок и должны проводиться специалистами, не зависимыми от
разработчиков и заказчиков (пользователей). Испытания ПС должны опираться на
стандарты, формализованные методики и нормативные документы разных уровней.
Множество видов испытаний целесообразно упорядочивать и проводить поэтапно в
процессе разработки для сокращения затрат на завершающихся сертификационных
испытаниях.
Сертификация комплексов программ является их испытанием в наиболее жестких
условиях тестирования особым третейским коллективом специалистов, имеющим право на
официальный государственный или ведомственный контроль функций и качеств ПС и
гарантирующим их соответствие стандартам и другим нормативным документам, а также
надежность и безопасность применения. Получение и обобщение результатов испытаний, а
также принятие решения о выдаче сертификата являются прерогативой испытательных
лабораторий. Они должны быть специализированными для проведения испытаний объектов
определенных классов, целенаправленно и систематически работать по созданию и
совершенствованию методик и средств автоматизации испытаний ПС конкретного
функционального назначения.
Специалисты-сертификаторы имеют право на расширение условий испытаний и на
создание различных критических и стрессовых ситуаций в пределах нормативной
документации, при которых должны обеспечиваться заданное качество и надежность
рвения предписанных задач. Если все испытания проходят успешно, то на
соответствующую версию ПС оформляется специальный документ — сертификат
соответствия. Этот документ официально подтверждает соответствие стандартам,
нормативен и эксплуатационным документам функций и характеристик «пытанных
средств, а также допустимость их применения в определенной области.
Методология принятия решений о допустимости выдачи сертификата на ПС
определяется оценкой степени его соответствия действующим и/или специально
разработанным документам. В исходных нормативных документах должны быть
сосредоточены все функциональные и эксплуатационные характеристики ПС,
обеспечивающие заказчику и пользователям возможность корректного применения
сертифицированного объекта во всем многообразии его функций и показателей качества.
Выбор и ранжирование показателей должны проводиться с учетом классов ПС, и
функционального назначения, режимов эксплуатации, степени критичности и жесткости
требований к результатам функционирования и проявлениям возможных дефектов и
ошибок. При этом могут привлекаться документы предшествующих этапов испытаний и
документы, подтверждающие соблюдение аттестованных технологий при разработке
программ на всех этапах. Испытания ПС в конкретных проблемно-ориентированных
системах проводятся по правилам и методикам, принятым для соответствующих классов
критических информационных систем, например, Авиационных или космических
комплексов.
Работы по сертификации объединяются в технологический процесс, на каждом этапе
которого регистрируются документы, отражающие состояние и качество результатов
разработки ПС. В зависимости от характеристик объекта сертификации на ее
выполнение выделяются ресурсы различных видов. В результате сложность программ, а
также доступные для сертификации ресурсы становятся косвенными критериями или
факторами, влияющими на выбор методов испытаний, а также на достигаемые качество и
надежность ПС.
Сертификационные испытания удостоверяют качество и надежность ПС
только в условиях, ограниченных конкретными стандартами и нормативными документами,
с некоторой конечно» вероятностью. В реальных условиях эксплуатации принципиально
возможны отклонения от характеристик внешней среды функционирования ПС за
пределы, ограниченные сертификатом.
ситуации, не проверенные при
сертификационных испытания. Эти обстоятельства способны вызывать катастрофические
последствия, угрожающие надежности функционирования и безопасности применения ПС.
Наличие сертификата у ПС для критически систем является необходимым условием их
допуска к эксплуатации. Однако любой сертификат на сложные системы не может
гарантировать абсолютную их надежность применения, и всегда остается некоторый риск
возникновения отказовых ситуаций.
Отсутствие гарантии достижения в процессе создания ПС абсолютной надежности их
функционирования за счет использования высоких технологий, тестирования и
сертификации заставляет искать дополнительные методы и средства повышения надежности ПС. Для этого разрабатываются и применяются методы оперативного
обнаружения дефектов и искажений при исполнении программ путем введения в них
временной, информационной и программной избыточности. Эти же виды избыточности используются для оперативного восстановления искаженных программ и данных и
предотвращения возможности развития результатов реализации угроз до уровня,
нарушающего надежность функционирования ПС. Основная задача ввода избыточности
состоит в ограничении или исключении возможности аварийных последствий от
возмущений, соответствующих отказ> системы. Любые аномалии при исполнении
программ необходимо блокировать и по возможным последствиям сводить до уровня сбоя
путем быстрого восстановления.
Особенности обеспечения надежности функционирования импортных программных
средств. При использовании зарубежных ПС в принципе в них возможны как
злоумышленные, так и случайные, непредумышленные искажения вычислительного
процесса, программ и данных, отражающиеся на надежности их функционирования.
Злоумышленные вирусы и «закладки», хотя и маловероятны в серийных, широко
тиражируемых в мире ПС, тем не менее требуют особых методов и средств
целенаправленного ил обнаружения и устранения. Зарубежным специалистам свойственно
ошибаться так же, как и отечественным, однако более высоких качество используемых
технологий разработки и современен проектировочная культура позволяют значительно
снижать уровень дефектов в изделиях, поступающих на рынок и в эксплу-1~±шпо. Тем не
менее в любых сложных импортных ПС всегда не гарантировано полное, абсолютное
отсутствие случайных ошибок, которые остаются важнейшими дестабилизирующими факторами. Их применение в критических отечественных ПС требует соответствующего
дополнительного контроля качества и спе-114альных работ по обеспечению надежности
при эксплуатации.
Представленные выше объекты уязвимости, дестабилизирую факторы и угрозы
надежности присущи любым программам t данным независимо от фирм-разработчиков.
Однако методы предотвращения и снижения влияния угроз надежности для зарубежных
ПС значительно отличаются. Разрыв в пространстве и 1ремени при проектировании
конкретного ПС между первичными зарубежными создателями программных
компонентов и потребителями, интеграторами, непосредственными создателями
отечественных ИС затрудняет взаимодействие по предотвращению ошибок за счет
применения CASE-технологий. Отечественный покупатель импортных ПС обычно не
знает, какая технология была применена при их разработке и какие классы ошибок могли
быть оставлены. В составе пользовательской документа, как правило, отсутствуют
исходные тексты программ и номенклатура тестов, использованных при их отладке.
Поэтому методы предотвращения ошибок в импортных программах и данных почти
всегда остаются недоступными и неизвестными отечественным специалистам. Это
отражается на хроническом недоверии к качеству и надежности применения зарубежных
программных компонентов или на слепой вере в их абсолютную безупречность.
Комплексирование готовых импортных прикладных ПС в конкретной отечественной
ИС создает условия для их функционирования, не всегда адекватные предусмотренным
разработчиками и проверенным при испытаниях, хотя и не выходящие за пределы
требований эксплуатационной документации. Это способствует проявлению ранее скрытых
дефектов и ошибок проектирования и их устранению. Для этого ответственные и квалифицированные поставщики зарубежных ПС имеют службы сопровождения, регистрации и
накопления претензий пользователей и быстрого реагирования для устранения реальных
дефектов функционирования. Легальная закупка и использование лицензионно чистых ПС,
обеспеченных сопровождением солидной фирмы-поставщика, позволяют в значительной
степени снижать влияние на надежность ПС дефектов, не предотвращенных в процессе
проектирования.
Этому же может способствовать применение разработчиками ИС той же CASEтехнологии, которая использовалась зарубежными решателями применяемых ПС. Для
этого, в частности, наиболее популярные СУБД при продаже комплектуются средствами
соответствующей CASE-технологии. Поставки прикладных программ различного
назначения могут содержать рекомендации по использованию определенных CASEтехнологий при комплексировании импортных компонентов в составе конкретной ИС.
Применение той же CASE-технологии позволяет более полно понимать функциональные
и технические возможности закупленных ПС в процессе их комплексирования в
проблемно-ориентированной ИС. Это предотвращает наиболее сложные системные
ошибки при использовании и интегрировании импортных ПС. Таким образом, хотя
непосредственное предотвращение и исправление ошибок импортных ПС
отечественными потребителями в процессе разработки ИС затруднительны, при
соответствующем взаимодействии с конкретными зарубежными фирмами надежность ИС
при использовании зарубежных программных продуктов можно поставить под
достаточно жесткий контроль.
Систематическое тестирование импортных ПС в процессе проектирования
производится самими разработчиками ИС. При отработке критических ПС целесообразны
создание или закупка комплектов и генераторов тестов для тестирования конкретных ПС в
составе ИС или автономно. Такое дополнительное тестирование повышает уверенность в
качестве и надежности применяемых импортных продуктов в конкретном окружении, а
также может приводить к обнаружению некоторых ошибок проектирования и
комплексирования зарубежных программных компонентов. Их устранение в большинстве
случаев целесообразно проводить силами зарубежной фирмы-разработчика с использованием организационно и юридически оформленного механизма сопровождения изделий
поставщиком. Обязательная сертификация зарубежных ПС для сложных, критических ИС
предполагает сопровождение закупаемых, лицен-зионно чистых изделий сертификатом
соответствия, выданным специализированной испытательной фирмой. Такое юридическое
утверждение качества и надежности применения импортного изделия может быть
недостаточным для особо важных, критических ИС, так как сертификат соответствия не
всегда сопровождается протоколами испытаний и использованными при этом тестами,
что не позволяет оценить полноту испытаний. В этих случаях следует ориентироваться на
дополнительную сертификацию импортных ПС отечественными проблемно-ориентированными, аттестованными сертификационными лабораториями.
Такие испытания позволяют удостовериться в надежности применяемых зарубежных
ПС, а также дополнительно выявить некоторые некорректности программ или
документации. Их устранение требует взаимодействия с зарубежной фирмой-поставщиком для корректировки изделий и исключения дефектов. Самостоятельное исправление
выявленных ошибок отечественными специалистами сопряжено с риском внесения
дополнительных вторичных ошибок из-за недостаточной квалификации и неполной
информации о детальном содержании текстов программ и описаний данных. Кроме того,
любые изменения в сертифицированных изделиях помимо фирмы-поставщика приводят к
автоматическому аннулированию выданного ею сертификата. Дополнительное
подтверждение сертификата соответствия отечественными специалистами может
значительно повысить уверенность в надежности зарубежных ПС.
Оперативные
методы
повышения
надежности
функционирования
ПС
предусматриваются в некоторых зарубежных изделиях и, в частности, в механизмах
обеспечения целостности информации баз данных в реляционных СУБД. Однако
разнообразие условий функционирования импортных ПС в сложных отечественных ИС не
позволяет удовлетвориться только штатными методами оперативного обнаружения
аномалий и восстановления вычислительного процесса, программ и данных. Методы и
средства для этого могут быть в ряде случаев достаточно автономными и ориентированными на оперативное повышение надежности конкретной ИС в целом, а не
только отдельных используемых ПС. Эти специализированные методы и средства могут
разрабатываться отечественными специалистами для обеспечения комплексной надежности
с использованием всех импортных компонентов. Такой подход позволяет обеспечить
комплексирование разнородных ПС различных зарубежных поставщиков и
специализированной отечественной системы оперативной защиты в едином комплексе
программ. При этом важно использовать концепцию и стандарты открытых систем при
взаимодействии между как закупаемыми, так и вновь разрабатываемыми компонентами
ПС, а также при их взаимодействии с внешней средой. Применение стандартизированных
интерфейсов открытых систем между прикладными программами и CASE-технологией
является эффективным современным методом повышения надежности информационных
систем при наличии разнородных поставщиков компонентов.
Таким образом, для обеспечения надежности функционирования зарубежных ПС в
составе отечественных ИС прежде всего следует полностью отказаться от применения
нелегальных импортных программ и баз данных. Процессы закупки, контроля и
применения импортных ПС для сложных отечественных ИС должны быть организованы и
поддержаны дополнительными испытаниями. Использование лицензионно чистых ПС и
тесное взаимодействие с их зарубежными фирмами-поставщиками позволяют эффективно
продолжать тестирование программ при их комплексировании в отечественных ИС,
оценивать и повышать надежность функционирования. При закупке зарубежных ПС целесообразно требовать сертификат соответствия и сопроводительную документацию по
методам, тестам и результатам испытаний. В ряде случаев может быть необходима
дополнительная сертификация импортных программ отечественными сертификационными
лабораториями. Кроме того, для каждой критической ИС должна разрабатываться
специализированная система обеспечения надежности ее функционирования путем
оперативного контроля, выявления дефектов и восстановления вычислительного процесса,
программ и данных при искажениях, угрожающих надежности и безопасности
применения.
В импортных программах, кроме случайных ошибок, возможны преднамеренные
фрагменты — «закладные элементы» и вирусы с целью реализации вредных для
эксплуатации функций, которые не описаны в документации. До наступления
определенного события «закладной элемент» остается неактивным, а при выполнении
некоторого условия осуществляет разрушительные действия, приводящие к отказу и не
предусмотренные функциональным назначением и документацией. Сертификация
импортных программ для удостоверения отсутствия в них вирусов или «закладных
элементов» может осуществляться в двух ситуациях:
• при наличии в составе поставляемой документации исходных текстов программ
на языке программирования и описаний алгоритмов обработки информации;
• при наличии только эксплуатационной документации, недостаточной для анализа
содержания и текстов программ.
В первом случае определение наличия в программе посторонних компонентов может
производиться последовательной сверкой текста программы на языке программирования с
описанием программы и спецификации. По тексту программы составляется блок-схема
анализируемого алгоритма, которая сравнивается с алгоритмом, изложенным в описании
программы. Если логическая структура алгоритмов различается, то следует проводить
дополнительный анализ элементов блок-схем, в которых обнаружены различия. Такие
различия могут быть обусловлены дефектами документации на программу, случайными
или предумышленными дефектами самой программы. Дефекты программы подлежат
подробному анализу, классификации и корректировке, после чего ее следует
подвергнуть полному тестированию и повторной сертификации на полное соответствие
всей документации и отсутствие вредных компонентов.
Во втором случае, который является наиболее массовым, задача значительно
усложняется, так как исходные документы о структуре и содержании программ и алгоритмов
не поставляются. Для получения текста программы и алгоритма необходимо провести
дизассемблирование объектного кода программы и выразить каждую функциональную
команду кода ассемблера в виде логической процедуры для представления как оператора
блок-схемы алгоритма. Построенная блок-схема подлежит анализу на наличие сомнительных
конструкций, тупиков и висячих вершин, которые могут оказаться «закладными
элементами». Каждая сомнительная группа процедур подлежит дальнейшему анализу на
возможность ее принадлежности «закладному элементу», вирусу или случайной ошибке.
Выявленные участки программы, содержащие случайные и предумышленные дефекты,
должны корректироваться. После их исключения программа подлежит полному
тестированию на соответствие эксплуатационной документации.
Четкое экономическое и юридическое взаимодействие с определенными
фирмами — поставщиками импортных ПС позволяет держать под контролем не только
достижимую надежность ИС, но и значительно снижает вероятность злоумышленных
аномалий в поставляемых ими изделиях. Обнаружение и публикация сведений о
предумышленных негативных компонентах в программных продуктах способны нанести
значительный ущерб репутации и бизнесу фирмы.
ЗАКЛЮЧЕНИЕ.
Программное обеспечение является важной составляющей многих сфер жизни,
используется повсеместно в промышленности, медицине, активно начинает
использоваться в образовании (дистанционное образование, открытое образование). От
программного обеспечения зависит не только эффективность производственного
процесса, но и жизнь людей (медицина, военная, космическая сфера). По этой причине
встает вопрос о качестве программного обеспечения.
Существует множество определений качества, в основе понятия качества продукта
или услуги лежит идея об удовлетворении потребностей конечного пользователя —
реального или потенциального потребителя. Вот определение этого понятия в соответствии со стандартом ISO 8402:1994.
Качество — совокупность характеристик объекта, относящихся к его способности
удовлетворить установленные и предполагаемые потребности.
Можно выделить три большие группы факторов, влияющих на качество
программного обеспечения:
• функциональная — связана с полнотой и удобством использования
реализованных функций программного средства;
• административная — связана с квалификацией персонала, организационной
структурой и управлением персоналом;
• программно-архитектурная — связана с процессом разработки программного
обеспечения, выбранными методологиями, инструментальными средствами,
использованными на различных этапах жизненного цикла программного обеспечения, а также архитектурой программного средства.
Современная техника управления качеством (например, концепция Total Quality
Management (TQM)) базируется именно на управлении качеством. На современном этапе
уже недостаточно иметь только методы оценки качества произведенного и используемого
программного средства (выходной контроль), необходимо иметь возможность планировать
качество, измерять его на всех этапах жизненного цикла программного средства и
корректировать процесс производства программного обеспечения для улучшения качества.
Международные стандарты серии ISO 9000 регламентируют создание системы управления
качеством. Однако они являются общими, лишь рекомендательными. Каждая компания,
производящая программное обеспечение и желающая внедрить у себя действенную систему
управления качеством на основе стандартов ISO 9000-й серии, должна учесть специфику
своей отрасли и разработать систему показателей качества, которая бы отражала реальное
влияние факторов качества на программный продукт.
Программное обеспечение как продукт имеет некоторые отличия от других
промышленных продуктов:
• наращивание объемов выпуска какого-то вида программного продукта происходит
практически мгновенно и имеет низкую стоимость, так как производство следующей
единицы программного продукта связано только с копированием информации на
носитель (компактдиск, дискету или жесткий диск);
• большие ресурсы затрачиваются на стадии планирования, реализации и
тестирования;
• сильное влияние человеческого фактора на производство программного
продукта, так как производство программного продукта — интеллектуальная и творческая
деятельность;
• в жизненном цикле программного продукта, как правило, отсутствует этап
утилизации;
• программный продукт не подвержен физическому старению, а только
моральному.
Все эти, а также многие другие особенности должны быть учтены в программе оценки
качества и управления качеством.
Сейчас остро стоит задача измерения качества программного обеспечения с целью
оперативного воздействия на процесс производства программного продукта. Для
измерения некоторых показателей качества могут служить тестирование, тестирование
пользователем (так называемое (3-тестирование), а также информация от пользователя о
найденных
проблемах,
получаемая
от
службы
технической
поддержки.
Вышеперечисленные действия дают обильную пищу для анализа (выраженную в
количественных единицах, а значит, измеряемую). Главное — найти между ними
зависимости (например, зависимость количества ошибок, обнаруженных специалистом
по тестированию, и количества ошибок, зафиксированных пользователем, может служить
показателем надежности программного средства), тогда можно будет говорить об
измерении качества программного средства.
При построении системы качества могут быть использованы математические методы:
методы корреляционного анализа (для выяснения выявления зависимости и тесноты связи
между отдельными свойствами программного продукта и степенью удовлетворения
пользователя), методы факторного анализа (для построения функции качества), методы
кластеризации.
Сегодня наступил этап планирования качества программного обеспечения,
мониторинга качества и управления им в процессе производства. Заинтересованность
пользователя и производителя программных средств есть; аппарат для управления
качеством программного обеспечения разрабатывается зарубежными и российскими
учеными.
Мероприятия, обеспечивающие приемлемый уровень качества программного средства,
можно условно разделить на административные и технологические.
К административным можно отнести следующие мероприятия:
1. Проведение обучения персонала, переподготовки.
2. Тщательное документирование всех изменений в структуре программного средства.
Для этого используются средства поддержки версионности.
3. Назначение ответственных лиц за каждую доработку программного средства.
4. Уделение внимания текущему контролю качества и заключительному контролю
качества.
5. Обеспечение мониторинга качества, например, фиксирование ошибок, поступивших от
пользователя программного средства. Использование систематических испытательных
методов, где
испытания будут разработаны параллельно с разработкой программы.
6. Введение внутренних стандартов. Такие стандарты обычно содержат соглашения о
именовании переменных в программном коде, наименовании файлов данных,
процедур и функций.
7. Организация отдела тестирования как самостоятельного подразделения.
8. Проведение совместных аттестаций с пользователем.
9. Обращение внимания на уровень и простоту обслуживаемости программного
обеспечения. Здесь речь идет как о решениипроблем, возникших у пользователя, так и
о простоте и надежности внесения изменений в программное обеспечение. Даже если
очень надежный кусок программного обеспечения был разработан, он может вскоре
стать ненадежным, если сложно сделать изменения в программе. Часто изменения
должны быть выполнены
вследствие новых потребностей внешней среды, например вследствие изменений в
законодательстве или требований заказчика.
К технологическим относятся следующие мероприятия.
1. Выбор стандарта качества и четкое следование ему на всех этапах. Создание
модели проекта с регулярными проверками, которые будут выполняться независимыми
командами экспертизы. Такая модель может быть построена, например, на основе
стандартов качества (например, ISO 9000).
2. Единая среда разработки. Лучшие результаты дают программные продукты
разработки, которые поддерживают несколько или все этапы жизненного цикла
программного обеспечения.
На данный момент такими комплексными решениями являются,
например, продукты Oracle Designer, продукты фирмы Rational.
3. Использовать формальный язык спецификаций (например,UML, DESIGN IDEF).
4. Выбор надежной СУБД (если программное средство работает с массивами
информации и использование СУБД оправдано).
5. Тщательное тестирование программного обеспечения.
6. Широкое внедрение автоматизации тестирования.
7. Использование полностью проверенной программной среды окружения (ОС) и
языка программирования, которые минимизируют опасность внесения ошибки.
8. Использование статистических методов для сбора информации о качестве ПС.
9. Изучение результатов испытаний (тестов) и ошибок для использования в
постоянном усовершенствовании программы. Источник в случае возникновения отказа
должен быть найден и устранен. Недостаточно найти ошибку в программном обеспечении
и исправить ее. Изменения должны быть сделаны в процессеразработки ПО.
10. Использование испытательной среды, которая предостережет от передачи
пользователю ненадежного программного обеспечения.
Для анализа рынка ПО представляется целесообразным посмотреть на
его структуру с точки зрения самих программных средств. При этом можно
воспользоваться такой классификацией программных продуктов, в основу
которой положены тираж и широта охвата круга пользователей: от
единичного исполнения до сотен тысяч и более:
внутрифирменные программные средства;
продукты вертикальных (специальных) решений;
коммерческие продукты широкого применения.
Внутрифирменное ПО разрабатывается, как правило, по специальным
заказам собственными или сторонними программистами (его иногда
называют также "заказное ПО") для единичных установок на конкретных
предприятиях.
ПО вертикальных решений является коммерческим и предназначено для
использования ограниченным кругом пользователей в определенных
предметных областях (автоматизация проектирования, издательские системы,
научные пакеты и пр.). Последняя группа продуктов ориентирована на самого
массового пользователя, сюда же относятся программы, необходимые для
работы практически на каждом ПК (операционные системы, офисные
программы и т.д.).
Грань между последними двумя группами продуктов является весьма
условной. Наверное, одним из основных критериев этого деления является
степень отчужденности ПО от его авторов. В секторе специальных решений
пользователь, как правило, заинтересован в получении той или иной
поддержки со стороны самого разработчика в ходе его эксплуатации. А для
использования продуктов широкого назначения вполне достаточно
сопроводительной документации.
Это определяет и различия в способах их распространения: ПО
широкого применения изначально ориентировано на использование
разветвленной сети поставщиков и в этом плане его можно охарактеризовать
как "коробочное" ПО (в коробке есть все необходимое для работы).
Специальное ПО распространяется, прежде всего, самими разработчиками
(для России это особенно характерно), и только самые его лучшие образцы —
через третьих продавцов.
О конкретных оценках соотношений перечисленных выше трех
сегментов ПО говорить достаточно сложно, но в качестве общей тенденции
можно отметить относительное сокращение объемов "заказного ПО" за счет
роста объемов продуктов широкого применения. Хотя следует сказать, что
именно на "внутрифирменных" программистов ложатся основные затраты,
связанные с сопровождением ПО.
И все-таки определяющую роль в формировании программного рынка
играют именно коммерческие продукты широкого применения. Можно смело
сказать, что на их долю приходится существенно больше половины общего
объема. Однако чисто коммерческой оценки недостаточно — именно этот
сегмент затрагивает интересы практически всех пользователей и в решающей
степени определяет общее состояние и направления развития всего
компьютерного рынка.
Структура современного рынка ПС и нынешняя ситуация на рынке
ПС
Мировой рынок ПС продолжает оставаться одной из наиболее
динамично развивающихся отраслей. По данным IDC, его объем составил
в 2005 году около $33 млрд. В дальнейшем рост продолжают прогнозировать
на уровне 15 — 20 % в год.
При сохранении стабильно высоких (для мировой отрасли ИТ в целом)
темпов роста на рынке ПС, его объем достигнет к 2009 г. $60 млрд. Однако
если рассматривать отдельно основные сегменты рынка (программное
обеспечение, аппаратное обеспечение и сервисы безопасности), то окажется,
что они демонстрируют разную динамику.
Как можно было предположить, наименьший рост — в сегменте
программного обеспечения, порядка 14 % в год. В 2005 г. его объем составил
около $12 мдрд, и можно ожидать дальнейшего уменьшения его доли в общем
объеме рынка. Несмотря на сравнительно низкий темп роста данного
сегмента, некоторые из его составляющих по-настоящему «горячие».
К таковым относится управление безопасностью контента (secure content
management) и управление безопасностью и уязвимостями (secure and
vulnerability management).
Наибольший же рост ожидается в сфере предоставления сервисов
безопасности. И это с учетом того, что уже сейчас объем рынка услуг в сфере
ИБ достиг $15 млрд. Сложность современных технологий обеспечения
безопасности и реальная зависимость жизнедеятельности предприятий
от уровня
их информационной
безопасности
являются
основными
«двигателями прогресса» в этой области. Прогнозируемый уровень роста
может составить до 19 % ежегодно.
Уверенный рост демонстрирует и третья составляющая, а именно
аппаратные средства обеспечения безопасности. Объем этого сегмента достиг
2005 году $6 млрд. и будет расти, по прогнозам аналитиков, примерно на 18 %
ежегодно. Этот рост, во многом, обеспечен высоким уровнем интереса
заказчиков к решениям в области многофункциональных платформ
безопасности с поддержкой, в том числе, технологий контроля контента.
Динамика
безопасности
и структура
мирового
рынка
информационной
2
005
2
006
2
007
2
008
2
009
2
Среднего
довой рост, %
5
,93
6
,95
7
,72
8
,71
9
,61
4
,83
2
,88
2
,22
3
,6
3
,98
3
,34
2
,59
1
,91
1
,27
2
,66
2
,11
3
,37
1
,62
1
,55
1
,63
1
,78
1
,89
1
,34
1
,45
3
13
4
52
4
94
4
38
5
42
3
76
1
3,7
1
5,6
1
7,4
1
9,2
1
0
1
1,9
2
25
4
80
6
90
9
,34
1
,73
1
004
Программные решения
Управление
безопасностью контента
Identity&Access
management
Управление
безопасностью
и уязвимостями
Threat management
Другое
Всего:
16,1
11,3
17,8
7,1
9,5
14
Аппаратные решения
Управление
безопасностью контента
49
47,3
Межсетевые
экраны/VPN
1
,49
1
,41
1
,35
1
,32
1
,67
1
,58
6
79
8
,06
1
,23
1
,34
1
96
4
92
Многофункциональн
ые устройста защиты
34
3
77
6
47
9
,28
1
,87
1
,36
2
SSL-VPN решения
3
70
4
35
6
62
7
99
8
02
2
27
5
89
5
62
6
45
7
64
7
85
4
32
2
90
2
10
3
20
3
30
3
36
2
70
1
,07
2
,35
2
,67
2
,02
3
,55
1
,8
6
,41
7
,7
8
0,3
1
1,8
1
,24
5
,31
4
,13
5
,09
6
,23
7
,51
8
6
,23
7
,65
8
0,3
1
2,2
1
2
,02
3
,6
3
,31
4
,28
5
Системы
обнаружения
и предотвращения
вторжений
Аппаратная
аутентификация
Secure content
application delivery
Другое
Всего:
and
-4,8
22
47,9
34,9
9,5
7
14,2
17,6
Услуги информационной безопасности
Консалтинг
Внедрение
,64
3
,31
5
,02
Сопровождение/подд
ержка
,15
2
,54
18,5
19,4
19,7
Обучение
Всего:
Итого
1
,91
1
,24
2
,66
2
,02
3
,41
1
,63
1
7,3
1
0,6
2
4,5
2
9
2
2,2
1
4,5
3
8,4
3
4,9
4
2,2
5
0
6
7,5
2
2,7
16,5
18,9
16,9
Источник: IDC, 2005
Программное обеспечение, предназначенное для защиты от вторжений,
является самым медленнорастущим видом защитного ПО. При этом
положительная
динамика
достигается
в первую
очередь
за счет
компьютерных систем обнаружения и предотвращения вторжений.
В отношении же межсетевых экранов и систем предотвращения вторжений
пользователи однозначно сделали выбор в сторону аппаратных средств.
Можно отметить, что стандартные межсетевые экраны, преодолев порог
технологической зрелости, начали свою дорогу к вымиранию. Заменой им
являются
унифицированные
средства
предотвращения
вторжений,
сочетающие в себе одновременно множество функций защиты. Именно
их появление замедлило темпы роста и аппаратных средств предотвращений
вторжений, так как эти функции входят в джентльменский набор
возможностей многофункциональных устройств.
Очень интересно также посмотреть на рынок систем управления
контентом. С одной стороны, именно они обеспечивают рост рынка
программных средств защиты. С другой стороны, это одна из двух наиболее
динамично развивающихся категорий аппаратных средств защиты. На самом
деле это является подтверждением важной тенденции — программные
средства позволяют быстрее реагировать на изменяющиеся угрозы, при этом
все равно наблюдается интеграции их функциональности в аппаратные
решения. Что интересно, и в этих быстрорастущих сегментах рынка мы
продолжаем наблюдать конкуренцию хорошо знакомых производителей.
Мифическое противостояние
Отмечая различные темпы роста в трех сегментах рынка ПС,
необходимо отдельно сказать о «мифическом» противостоянии программных
средств обеспечения безопасности и программно-аппаратных комплексов,
иногда называемых в просторечии просто аппаратными. Нужно отдавать себе
отчет в том, что любое, так называемое, аппаратное решение состоит
из того же программного обеспечения установленного на обычный
или на специализированный компьютер.
Причины, обеспечивающие быстрый рост сегмента, могут быть легко
перечислены.
Из очевидных
преимуществ —
простота
установки
и сопровождения. Заказчику нет необходимости самому мучиться выбором
аппаратной платформы для установки защитного программного обеспечения,
заниматься поиском необходимых драйверов, вопросами совместимости и пр.
Поставщику/производителю конкретного продукта нет необходимости искать
источник проблемы, возникшей у заказчика, с аппаратной ли платформой,
операционной системой, или его собственным продуктом. Причем,
как показывает практика, в этом случае часто возникает эффект «пинг-понга»,
когда каждый производитель конкретного компонента считает, что проблема
не у него. При использовании программных решений заказчик или вынужден
решать свои проблемы сам или платить дополнительные деньги
«высокоинтеллектуальным»
компаниям-консультантам
и системным
интеграторам, которые, возможно, обеспечат функционирование программноаппаратного комплекса, состоящего из различных продуктов.
Таким образом, предложение производителями готовых программноаппаратных комплексов преследуют несколько целей. Во-первых, снять
с заказчиков головную боль по установке и сопровождению решения. Вовторых, снять с себя головную боль, связанную с поддержкой нестандартного
решения.
И в-третьих,
получить
дополнительные
деньги
за счет
предоставления заказчику как аппаратного, так и программного обеспечения
в «едином флаконе».
Еще одним дополнительным преимуществом «аппаратных» платформ
является возможность интеграции в них аппаратных ускорителей тех
или иных операций. Это могут быть и специализированные сетевые адаптеры,
умеющие сами «разбирать» стек протокола TCP/IP, и программируемые
сетевые процессоры, выполняющие такие операции, как трансляция сетевых
адресов, анализ приложений и много другое. Поэтому можно утверждать, что
помимо простоты установки и сопровождения, аппаратные средства
обеспечивают и более высокую производительность.
Хотя, говоря о более высокой производительности не надо лукавить.
Эта самая производительность зависит от многих параметров, и, может
оказаться, что собранное умелыми руками на коленке решение покажет
результаты лучше, чем готовый комплекс. Поэтому тут следует говорить
не просто о более высокой производительности аппаратных средств,
а о предсказуемой производительности. Имеется в виду, что при выборе
аппаратного решения мы заранее знаем, что нам обещает его производитель.
Выбирая же программное решение, подбирая под него аппаратную
платформу, занимаясь «тюнингом» операционной системы, мы играем в игру
«попал/не попал», что может быть неприемлемо с точки зрения обеспечения
гарантированных характеристик функционирования информационных систем
предприятия.
Ключевым преимуществом ПО является его гибкость, а именно
широкие возможности по адаптации к современным, быстро меняющимся
условиям. Это приводит к тому, что стандартные функции обеспечения
безопасности, по достижении определенного уровня технологической
проработки, мигрируют в аппаратные платформы. Те же продукты, которые
требуют постоянного обновления и частых изменений, остаются в виде чисто
программных продуктов. При этом ряд компаний уже начал выпускать
специализированные аппаратные комплексы для подобных программных
продуктов. Т.е. сейчас мы все чаще сталкиваемся с программно/программноаппаратными комплексами, где основные функции защиты реализованы
на специализированной аппаратной платформе, а дополнительные функции —
за счет интеграции часто изменяемого программного обеспечения,
как с использованием внутренних интерфейсов, так и с использованием
внешних протоколов взаимодействия. Примером такого протокола
взаимодействия может являться протокол ICAP, стандартизированный IETF,
и позволяющий системам кэширования трафика эффективно интегрироваться
с системами контроля контента.
Тенденция говорит о том, что в дальнейшем можно ожидать
постепенный переход дискуссии о выборе программных или программноаппаратных
средств
к вопросам
обеспечения
гарантированного
функционирования, простоты установки и эксплуатации, а также к вопросам
развитости системы технической поддержки.
Структура современного рынка программных средств
В 2004 г., на основании полученных CNews Analytics данных, в структуре
отечественного рынка программных средств доминировали программные
средства защиты (47%). 31% приходилось на аппаратные и программноаппаратные средства, 22% — на услуги и послепродажные сервисы.
Структура суммарного дохода компаний в сфере защиты информации
Источник: CNews Analytics, 2005
Интеграторы ведут
В структуре рейтинга CNewsSecurity 2004 на долю компаний,
специализирующихся на аппаратных и программно-аппаратных комплексах,
приходится 37%. 27% составляет доля системных интеграторов, 16% —
разработчиков защитного ПО и 10% — дистрибьюторов.
Структура рейтинга CNewsSecurity 2004 по направлениям деятельности
компаний
Источник: CNews Analytics, 2005
Наибольший рост по итогам года продемонстрировали дистрибьюторы
защитного ПО — 54,3%. При этом выручка по направлению информационной
безопасности компании «1С» увеличилась по сравнению с 2003 г. на 76%.
Немаловажно, что все три вошедшие в рейтинг CNewsSecurity 2004 компании
— «1С», SoftLine и Softkey — являются одновременно, по данным CNews100,
крупнейшими дистрибьюторами ПО в России.
Бизнес разработчиков программных средств защиты вырос за 2004 г.
на 47,8%. Значительный вклад в этот показатель сделала
«Лаборатория Касперского», которая по обороту опережает идущую за ней
следом «КриптоПро» в два раза, а «Диалог Науку» (3 место в рейтинге) —
почти в четыре.
Динамика роста компаний CNewsSecurity 2004 по направлениям
деятельности (%)
Источник: CNews Analytics, 2005
Совокупная выручка системных интеграторов, занявших половину первой
десятки рейтинга, выросла за 2004 г. на 33%. Как прокомментировали CNews
представители ведущих компаний этой группы, сегодня большинство
реализованных проектов по построению информационной структуры
включают системы защиты информации. Они отмечают, что клиенты все
чаще обращаются непосредственно за услугами в сфере обеспечения
информационной безопасности вне рамок каких-либо проектов. По мнению
экспертов, это свидетельствует о том, что современный заказчик все чаще
задумывается о стоимости своей информации.
Наибольший рост среди интеграторов, вошедших в рейтинг
CNewsSecurity 2004, продемонстрировали «Открытые технологии» — 157%.
Представители компании связывают подобный успех с возросшими
потребностями отечественного бизнеса в области обеспечения ИБ. В
соответствии с этим был заметно увеличен штат сотрудников по данному
направлению. Со своей стороны, некоторое уменьшение выручки в 2004 г. по
сравнению с 2003 г. интегратор «ICL-КПО ВС» (14 позиция) списывает на то,
что сдача нескольких крупных объектов была перенесена на 2005 г. по вине
заказчика.
Наиболее широко представленные в рейтинге компании,
специализирующиеся на программно-аппаратных комплексах, увеличили за
год свою суммарную выручку на 24%. Игроки этого сектора в первую очередь
ощутили на себе последствия Административной реформы 2004 г., несколько
затормозившей ИТ-проекты. Впрочем, как комментируют представители
компаний, уже в первой половине 2005 г. ситуация вернулась в прежнее
русло, и работа по отложенным контрактам возобновилась.
Структура доходов
Приоритеты интеграторов, вошедших в рейтинг CNewsSecurity 2004, в сфере
безопасности несколько различаются. Так, например, программные средства
защиты являются доминирующим направлением для «Инфосистем Джет»,
составляя 63% выручки компании по этому направлению. В то же время в
обороте «Компьюлинк» на безопасное ПО приходится только 10%.
Выручка от программных средств защиты
Источник: CNews Analytics, 2005
Программно-аппаратные средства защиты — главное направление компании
«Ланит», на него приходится 40% от общей выручки по направлению ПС. У
других ведущих интеграторов, таких как Tops BI и «Компьюлинк», этот
показатель составляет 20%-30%.
Выручка от аппаратных и программно-аппаратных средств защиты
Источник: CNews Analytics, 2005
Услуги традиционно играют большую роль в бизнесе системных
интеграторов. Аудит систем безопасности, разработка политик безопасности,
аттестация объектов пользуются все большей популярностью у заказчиков.
Некоторые интеграторы, например «Компьюлинк», до 70% прибыли
получают от оказания услуг консалтинга и послепродажных сервисов.
Выручка от услуг консалтинга и послепродажных сервисов
Источник: CNews Analytics, 2005
Основной тенденцией, которую отмечают сегодня все игроки отечественного
рынка ПС, является постоянно растущий спрос на услуги консалтинга, аудита
и послепродажных сервисов. В первую очередь это связано с тем, что
заказчики стали более серьезно подходить к вопросам организации защиты
информации. Компании уделяют все больше внимания вопросам
эффективности систем защиты — особенно от внутренних угроз. Данная
тенденция нашла свое отражение и в рейтинге CNewsSecurity 2004. Так,
компания Aladdin, специализирующаяся на решениях этого класса, показала
наибольший рост в сегменте аппаратно и программно-аппаратных
комплексов.
2 Введение в программную инженерию
2.1 Программная инженерия
Проектирование экономических информационных систем – логически
сложная, трудоемкая и длительная работа, требующая высокой квалификации
участвующих в ней специалистов. Однако до настоящего времени
проектирование ЭИС нередко выполняется на интуитивном уровне
неформализованными методами, включающими в себя элементы искусства,
практический опыт, экспертные оценки и дорогостоящие экспериментальные
проверки качества функционирования ЭИС. Кроме того, в процессе создания
и функционирования ЭИС информационные потребности пользователей
постоянно изменяются и уточняются, что еще более усложняет разработку и
сопровождение таких систем.
Основная доля трудозатрат при создании ЭИС приходится на
прикладное программирование и базы данных. Производство ПО – это
крупнейшая отрасль мировой экономики, в которой занято около трех млн.
специалистов.
Потребность контролировать процесс разработки ПО, прогнозировать и
гарантировать стоимость разработки, сроки и качество результатов привела в
конце 70-х годов к необходимости перехода от кустарных к индустриальным
способам создания ПО и появлению совокупности инженерных методов и
средств создания ПО, объединенных общим названием «программная
инженерия». Впервые этот термин был использован как тема конференции,
проводившейся под эгидой НАТО в 1968 г. Спустя 7 лет, в 1975г. в
Вашингтоне была проведена первая международная конференция,
посвященная программной инженерии.
В процессе становления и развития программной инженерии можно
выделить два этапа: 70-е и 80-е годы - систематизация и стандартизация
процессов создания ПО (на основе структурного подхода) и 90-е годы начало перехода к сборочному, индустриальному способу создания ПО (на
основе объектно-ориентированного подхода).
В основе программной инженерии лежит одна фундаментальная идея:
проектирование ПО является формальным процессом, который можно
изучать и совершенствовать. Освоение и правильное применение методов
и средств создания ПО позволяет повысить качество ЭИС, обеспечить
управляемость процесса проектирования ЭИС и увеличить срок ее жизни.
Тенденции развития современных информационных технологий
определяют постоянное возрастание сложности ПО ЭИС. Современные
крупные проекты ЭИС характеризуют, как правило, следующие особенности:
– Сложность описания (достаточно большое количество функций,
процессов, элементов данных и сложные взаимосвязи между ними),
требующая тщательного моделирования и анализа данных и процессов.
– Наличие совокупности тесно связанных подсистем, имеющих
локальные задачи и цели функционирования.
– Отсутствие полных аналогов, ограничивающее возможность
использования каких-либо типовых проектных решений и прикладных
систем.
– Необходимость
интеграции
существующих
и
вновь
разрабатываемых приложений.
– Функционирование в неоднородной среде на нескольких аппаратных
платформах.
– Разобщенность и разнородность отдельных групп разработчиков по
уровню квалификации и сложившимся традициям использования тех или
иных инструментальных средств.
– Значительная временная протяженность проекта, обусловленная с
одной стороны, ограниченными возможностями коллектива разработчиков и
различной степенью готовности отдельных ее подразделений к внедрению
ЭИС.
Для успешной реализации проекта объект проектирования (ПО ЭИС)
должен быть прежде всего адекватно описан, т.е. должны быть построены
полные и непротиворечивые модели архитектуры ПО, включающие
совокупность структурных элементов системы и связей между ними,
поведение элементов системы в процессе их взаимодействия, а также
иерархию подсистем, объединяющих структурные элементы.
Под моделью понимается полное описание системы ПО с определенной
точки зрения. Модели представляют собой средства для визуализации,
описания, проектирования и документирования архитектуры системы.
Моделирование является центральным звеном всей деятельности по
созданию качественного ПО. Модели строятся для того, чтобы понять и
осмыслить структуру и поведение будущей системы, облегчить управление
процессом ее создания и уменьшить возможный риск, а также
документировать принимаемые проектные решения.
Разработка модели архитектуры системы ПО промышленного характера
на стадии, предшествующей ее реализации или обновлению, также
необходима, как и наличие проекта для строительства большого здания.
Программное средство (изделие) – программа или логически
связанная совокупность программ:
записанная на носителях данных;
являющаяся продуктом промышленного производства;
снабженная программной документацией;
предназначенная для широкого распространения посредством
продажи или методами freeware, shareware или OEM.
Информационная
технология
–
совокупность
методов,
производственных и программно-технологических средств, объединенных в
технологическую цепочку, обеспечивающую сбор, хранение, обработку,
вывод и распространение информации. Информационные технологии
предназначены для снижения трудоемкости процессов использования
информационных ресурсов.
2.2 Связь программной инженерии с другими сферами науки
Информатика (computer science) – это свод теоретических наук,
основанных на математике и посвященных формальным основам
вычислимости. Сюда относят математическую логику, теорию грамматик,
методы построения компиляторов, математические формальные методы,
используемые в верификации и модельном тестировании и т.д. Трудно строго
отделить программную инженерию от информатики, но в целом
направленность этих дисциплин различна. Программная инженерия нацелена
на решение проблем производства, информатика – на разработку
формальных, математизированных подходов к программированию.
Системотехника
(system
engineering)
объединяет
различные
инженерные дисциплины по разработке всевозможных искусственных систем
– энергоустановок, телекоммуникационных систем, встроенных систем
реального времени и т.д. Очень часто ПО оказывается частью таких систем,
выполняя задачу управления соответствующего оборудования. Такие системы
называются программно-аппаратными, и участвуя в их создании,
программисты
вынуждены
глубоко
разбираться
в
особенностях
соответствующей аппаратуры.
Бизнес-реинжиниринг (business reengineering) – в широком смысле
обозначает модернизацию бизнеса в определенной компании, внедрение
новых
практик,
поддерживаемых
соответствующими,
новыми
информационными системами. При этом акцент может быть как на
внутреннем переустройстве компании так и на разработке нового клиентского
сервиса (как правило, эти вопросы взаимосвязаны). Бизнес-реинжиниринг
часто предваряет разработку и внедрение информационных систем на
предприятии, так как требуется сначала навести определенный порядок в
делопроизводстве, а лишь потом закрепить его информационной системой.
Связь программной инженерии (как области практической
деятельности) с информатикой, системотехникой и бизнес-реинжинирингом
показана на рис.:
3 Жизненный цикл ПС
Жизненный цикл (ЖЦ) программного средства (ПС) определяется как
период времени, который начинается с момента принятия решения о
необходимости создания ПС и заканчивается в момент его полного изъятия из
эксплуатации.
Основным нормативным документом, регламентирующим состав
процессов ЖЦ ПО, является международный стандарт ISO/IEC 12207: 1995
“Information Technology - Software Life Cycle Processes” (ISO - International
Organization for Standardization - Международная организация по
стандартизации, IEC - International Electrotechnical Commission Международная комиссия по электротехнике. Он определяет структуру ЖЦ,
содержащую процессы, действия и задачи, которые должны быть выполнены
во время создания ПС.
Процесс определяется как совокупность взаимосвязанных действий,
преобразующих некоторые входные данные в выходные. Каждый процесс
характеризуется определенными задачами и методами их решения,
исходными данными, полученными от других процессов, и результатами.
Каждый процесс разделен на набор действий, каждое действие – на
набор задач. Каждый процесс, действие или задача инициируется и
выполняется другим процессом по мере необходимости, причем не
существует заранее определенных последовательностей выполнения
(естественно, при сохранении связей по входным данным).
Основные процессы:
– приобретение;
– поставка;
– разработка;
– эксплуатация;
– сопровождение.
Вспомогательные процессы:
– документирование;
– управление конфигурацией;
– обеспечение качества;
– верификация;
– аттестация;
– совместная оценка;
– аудит;
– разрешение проблем.
Организационные процессы:
– управление;
– усовершенствование;
– создание инфраструктуры;
– обучение.
4 Процесс создания ПС
4.1 Стадии разработки ПС
Теперь рассмотрим набор типовых стадий создания ПС, изучение
которого позволит понимать процесс разработки и более осознанно
относиться к созданию качества ПС. Эти стадии предусмотрены ГОСТ 19.10277 ЕСПД. Стадии разработки.
Стадии – наиболее укрупненные составляющие процесса разработки,
для завершения которых характерно получение ПО в определённой стадии
готовности.
Выделяют следующие стадии разработки программного обеспечения:
1 Стадия технического задания (предпроектная стадия) состоит из:
сбора исходных данных;
определения цели разработки – желаемого набора основных свойств
и функций разрабатываемого ПС;
обоснования и выбора критерия эффективности и качества
разработки;
формирования на верхнем уровне состава входной и выходной
документации по решаемой задаче;
выбора принципиальных методов решения задач;
определения требований к комплексу технических средств и
операционному окружению;
определения инструментальных средств, используемых для
разработки;
планирования, т.е. декомпозиции процесса на стадии и этапы с
установлением сроков их выполнения;
разработки документа, называемого «Техническое задание».
2 Эскизное проектирование
На данной стадии выполняется:
детализация состава и структуры входной и выходной информации;
детализация метода решения задач.
На этапе эскизного проектирования нужно создать предварительную
версию программного средства (возможно в виде модели) и выяснить
принципиальные вопросы, устраняя возможные разногласия между
разработчиком и заказчиком. При этом выполняется:
определение предварительной технологии решения задачи;
прогнозирование эффективности решения задачи на конкретном
объекте;
ведется освоение инструментальных средств (апробирование,
обучение персонала).
3 Техническое проектирование (технический проект)
На данном этапе:
окончательно определяется состав и структура информации;
разрабатывается интерфейс во всех его компонентах;
технология решения задачи доводится автоматизма;
полностью определяется конфигурация тех средств, на которых
ведется разработка ПС;
определяется структура базы данных, где храниться информация о
работе ПС;
разрабатывается тестовый набор для проверки правильности
программной реализации;
начинается разработка программной документации;
полностью определяется структура ПС (модули, компоненты).
Технический проект может рассматриваться как постановка задачи,
передаваемой специалистом-постановщиком специалисту по программной
реализации.
4 Рабочее проектирование (рабочий проект)
Результат рабочего проектирования – получение ПС в состоянии
операционной готовности, в котором устранены синтаксические и
семантические ошибки, как в программном коде так и в программной
документации.
Основные работы этой стадии:
программная реализация (написание программного кода, привязка
его к специфике конкретного объекта, адаптация и настройка программных
модулей);
отладка (автономная – в лабораторных условиях и комплексная – на
объекте);
разработка эксплуатационной документации;
организация внедрения ПС.
5 Внедрение
На этапе внедрения осуществляют:
подготовку персонала к эксплуатации;
подготовку базы данных;
проверку работоспособности ПС на реальных данных (опытная
эксплуатация);
доводка – окончательное устранение всех ошибок в коде и
документации.
По отдельным компонентам может быть откат на предыдущие стадии.
В процессе разработки стадии могут объединяться. Объединяют
эскизный и технический или технический и рабочий проекты. Иногда могут
сразу объединять эскизный, технический и рабочий проекты. Обычно это
производится, если в разрабатываемом ПС можно использовать значительный
объём предыдущих разработок.
4.2 Понятие метода и технологии проектирования ПС
4.2.1 Определение метода и технологии
Метод проектирования ПС представляет собой организованную
совокупность процессов создания ряда моделей, которые описывают
различные аспекты разрабатываемой системы с использованием четко
определенной нотации. На более формальном уровне метод определяется как
совокупность составляющих:
Концепций и теоретических основ. В качестве таких основ могут
выступать структурный или объектно-ориентированный подход.
Нотаций, используемых для построения моделей статической
структуры и динамики поведения проектируемой системы. В качестве таких
нотаций обычно используются графические диаграммы, поскольку они
наиболее наглядны и просты в восприятии (диаграммы потоков данных, и
диаграммы «сущность – связь» для структурного подхода, диаграммы
вариантов использования, диаграммы классов и др. – для объектноориентированного подхода.
Процедур, определяющих практическое применение метода
(последовательность и правила построения моделей, критерии, используемые
для оценки результатов).
Методы реализуются через конкретные технологии и поддерживающие
их методики, стандарты и инструментальные средства, которые обеспечивают
выполнение процессов ЖЦ ПО.
Технология проектирования определяется как совокупность
технологических операций проектирования в их последовательности и
взаимосвязи, приводящая к разработке проекта ПО.
4.2.2 Требования к технологии
Современная технология проектирования должна обеспечивать:
1. Соответствие стандарту ISO/IEC 12207: 1995 (поддержка всех
процессов ЖЦ ПО).
2. Гарантированное достижение целей разработки ЭИС в рамках
установленного бюджета, с заданным качеством и в установленное время.
3. Возможность декомпозиции проекта на составные части,
разрабатываемые группами исполнителей ограниченной численности (3-7
чел.), с последующей интеграцией составных частей.
4. Минимальное время получения работоспособного ПО ЭИС. Речь
идет не о сроках готовности всей ЭИС, а о сроках реализации отдельных
подсистем. Практика показывает, что даже при наличии полностью
завершенного проекта внедрение ЭИС идет последовательно по отдельным
подсистемам.
5. Независимость получаемых проектных решений
от средств
реализации ЭИС (СУБД, ОС, языков и систем программирования).
6. Поддержка комплексом согласованных CASE – средств,
обеспечивающих автоматизацию процессов, выполняемых на всех стадиях
ЖЦ ПО.
Реальное применение любой технологии проектирования ПО ЭИС в
конкретной организации и конкретном проекте невозможно без выработки
ряда стандартов (правил, соглашений), которые должны соблюдаться всеми
участниками проекта. К таким стандартам относятся:
1. Стандарт проектирования.
2. Стандарт оформления проектной документации.
3. Стандарт интерфейса конечного пользователя с системой.
Стандарт проектирования должен устанавливать:
– Набор необходимых моделей (диаграмм) на каждой стадии
проектирования и степень их детализации.
– Правила фиксации проектных решений на диаграммах, в том числе
правила именования объектов (включая соглашения по терминологии), набор
атрибутов для всех объектов и правила их заполнения на каждой стадии,
правила оформления диаграмм (включая требования к форме и размерам
объектов) и т.д.
– Требования к конфигурации рабочих мест разработчиков, включая
настройки ОС, настройки CASE – средств и т.д.
– Механизм обеспечения совместной работы над проектом, в том
числе правила интеграции подсистем проекта, правила поддержания проекта в
одинаковом для всех разработчиков состоянии (регламент обмена проектной
информацией, механизм фиксации общих объектов и т.д.), правила анализа
проектных решений на непротиворечивость и т.д.
Стандарт оформления проектной документации. Он должен
устанавливать:
– комплектность, состав и структуру документации на каждой стадии
проектирования (в соответствии со стандартом ГОСТ Р ИСО 9127 – 94
«Системы обработки информации. Документация пользователя и информация
на упаковке потребительских программных пакетов»);
– требования к оформлению документации (включая требования к
содержанию разделов, подразделов, пунктов, таблиц и т.д.);
– правила подготовки, рассмотрения, согласования и утверждения
документации с указанием предельных сроков на каждой стадии;
– требования к настройке издательской системы, используемой в
качестве встроенного средства подготовки документации;
– требования к настройке CASE – средств для обеспечения подготовки
документации в соответствии с установленными правилами.
Стандарт интерфейса конечного пользователя с системой. Он
должен регламентировать:
– Правила оформления экранов (шрифты и цветовая палитра), состав и
расположение окон и элементов управления.
– Правила использования клавиатуры и мыши.
– Правила оформления текстов помощи.
– Перечень стандартных сообщений.
– Правила обработки реакций пользователя.
Стандарт
пользовательского
интерфейса
для
диалоговых
информационных технологий фирмы IBM с некоторыми пояснениями
приведен в приложении 1 данной работы.
5 Подходы к проектированию ПО
5.1 Нисходящий и восходящий подходы к разработке программ
Имеется 2 принципиально различных метода структурного
проектирования программ: метод нисходящего (сверху вниз) и метод
восходящего (снизу вверх) проектирования. Более прогрессивный
современный метод разработки программ предполагает использование
структурного программирования и метода нисходящего проектирования
программ.
Нисходящим методом проектирование программы ведется от общего к
частному, ко все большей детализации на каждом этапе. При этом сначала определяется задача в целом, в виде последовательности этапов, реализующих
самостоятельные смысловые части алгоритма. Затем она поэтапно детализируется. Процесс детализации алгоритма продолжается до тех пор, пока реализуемые части алгоритма не станут достаточно простыми и легко программируемыми. Результатом этого процесса может быть структура программы.
Это направленный граф, определяющий взаимосвязи подпрограмм в виде блоков подпрограмм и их вызовов. На последнем этапе каждый модуль представляется в виде детального описания его функций, например с помощью схемы
алгоритма. Схема алгоритма – это направленный граф, который определяет
процесс обработки данных.
Альтернативным методом по отношению к методу нисходящего
проектирования является метод восходящего проектирования. При этом
вначале разрабатываются модули низшего уровня, а затем они объединяются с
помощью модулей более высокого уровня. Сложные программные системы
восходящим методом создавать значительно труднее и дольше, чем
нисходящим. На практике часто используют смешанный метод, т. е. в
основном используют метод нисходящего проектирования, а в некоторых
случаях, по мере необходимости, – восходящее проектирование.
5.2 Макетирование
Макетирование (прототипирование) – это процесс создания модели
требуемого программного продукта. Основная цель макетирования – снять
неопределенности в требованиях заказчика.
Модель может принимать одну из трех форм;
бумажный макет или макет на основе ПК (изображает или рисует
человеко-машинный диалог);
работающий макет (выполняет некоторую часть требуемых функций);
существующая программа (характеристики которой затем должны
быть улучшены).
Макетирование основывается на многократном повторении итераций, в
которых участвуют заказчик и разработчик (рис. 1.2):
построение или уточнение модели;
оценка макета заказчиком;
ожидание заказчика.
Рис. 1.2. Итерации макетирования
Достоинство макетирования: обеспечивает определение полных
требований к ПО.
Недостатки макетирования:
заказчик может принять макет за продукт;
разработчик может принять макет за продукт.
Когда заказчик видит работающую версию ПО, он перестает
сознавать, что в погоне за работающим вариантом оставлены нерешенными
вопросы качества и удобства сопровождения ПО. Очень часто это
отрицательно сказывается на управлении разработкой ПО.
Для быстрого получения работающего макета разработчик часто идет
на определенные компромиссы. Могут использоваться не самые подходящие
язык программирования или операционная система.
5.3 Структурное программирование
Структурное программирование (СП) – это совокупность
рекомендуемых технологических приемов, охватывающих выполнение всех
этапов разработки ПО.
В основе СП лежит декомпозиция сложных систем с целью реализации в
виде отдельных небольших подпрограмм (до 40 ... 50 операторов).
Структурный подход требует представления задачи в виде иерархии
подзадач простейшей структуры. Для получения такой иерархии применяется
метод пошаговой детализации, который заключается в следующем:
определяется общая структура программы в виде одного из трех
вариантов:
последовательности
подзадач
(например,
ввод
данных,
преобразование данных, вывод данных),
альтернативы подзадач (например, добавление записей к файлу или
их поиск),
повторения подзадачи (например, циклически повторяемая
обработка данных);
каждая подзадача, в свою очередь, разбивается на подзадачи с
использованием тех же структур;
процесс продолжается, пока на очередном уровне не получается
подзадача, которая достаточно просто реализуется средствами используемого
языка (1 - 2 управляющих оператора языка).
Методика
процедурной
декомпозиции
является
основой
алгоритмического (процедурного) подхода к программированию, при котором
основное внимание концентрируется на определении последовательности
действий.
Поддержка принципов СП была заложена в основу процедурных языков
программирования. Они включали основные «структурные» операторы
управления, поддерживали вложение подпрограмм, локализацию и
ограничение области «видимости» данных. Наиболее известные – PL/I,
ALGOL-68, Pascal, С.
5.4 Модульное программирование (МП)
Архитектура МП позволяет:
выделить группы подпрограмм, использующих одни и те же
глобальные данные, в отдельно компилируемые модули (библиотеки
подпрограмм), например, модуль графических ресурсов, модуль подпрограмм
вывода на принтер.
осуществлять связи между модулями через специальный интерфейс,
запретить доступ к реализации модуля (телам подпрограмм и
некоторым «внутренним» переменным).
Технологию МП поддерживают современные версии языков Pascal и С
(C++), языки Ада и Modula.
Использование МП упрощает разработку программ несколькими
программистами:
внутренняя организация модулей скрыта и потому может изменяться
независимо;
взаимодействие модулей осуществляется через специально
оговоренные интерфейсы модулей;
модули в дальнейшем могут использоваться в других разработках,
что увеличивает производительность труда программистов.
Практика программирования показывает, что структурный подход в
сочетании с МП позволяет получать достаточно надежные программы,
размер которых не превышает 100000 операторов.
Узкие места МП:
ошибка в интерфейсе при вызове подпрограммы выявляется только
при выполнении программы (из-за раздельной компиляции модулей
обнаружить эти ошибки раньше невозможно).
при увеличении размера программы свыше 100 000 операторов
возрастает сложность межмодульных интерфейсов, и предусмотреть
взаимовлияние отдельных частей программы становится практически
невозможно.
Стремление уменьшить количество связей между отдельными частями
программы приводит
к появлению объектно-ориентированного
программирования (ООП).
5.5 Формирование структуры модулей программы
Формирование
структуры
модулей
программного
средства
осуществляется на основании нескольких методов. Наиболее известным из
них является метод структурно-функциональной декомпозиции поставленной
задачи и формирования на её основе набора взаимосвязанных
функциональных модулей.
На первом этапе формируется перечень базовых функций программного
средства, к числу которых относятся целевые функции, необходимые для
пользователя (поиск, хранение файлов, редактирование содержимого,
сохранение в базу данных и т.д.) и сервисные функции, необходимые для
эффективной работы самой программы (инициация переменных, управление
реестром и памятью и т.д.).
Далее формируется структура функций программного средства,
показывающая состав главных и подчинённых функций. Она выполняется в
виде дерева функций.
На основании структуры функций определяются логические связи
между ними. Для этого могут использоваться как средства графического
моделирования, так и CASE-средства.
Когда логические связи между функциями определены, функции
трансформируются в модули, с учётом правил их реализации в языке
программирования. На этом этапе некоторые функции могут быть
объединены, модернизированы и т.п.
После формирования структуры модулей программы, на основании
логических связей формируются каналы передачи информации между
модулями. Эти каналы должны включать описание передаваемой между
модулями информации вплоть до переменных.
5.6 Подход к разработке программных средств, используемых для
автоматизации организационных процессов
При разработке программных средств, используемых для автоматизации
организационных процессов, используют следующие этапы:
1) Анализ предметной области (организационного процесса) и
выявление проблемных областей, обычно включающих:
функции, которые следует выполнять с использованием
создаваемого программного средства;
документы, данные из которых нужно вносить в базу данных
программного средства;
документы, которые следует формировать с помощью него.
Анализ предметной области проводится с помощью различных методов
сбора информации, включающих:
наблюдение за работой специалистов в предметной области;
интервьюирование или анкетирование этих специалистов;
анализ доступных нормативных документов, описывающих
предметную область;
анализ документов, используемых в автоматизируемом процессе.
2) Выбор инструментария для создания программного средства,
включающего, как правило, язык программирования и СУБД, используемой для
хранения данных.
Выбор инструментария осуществляется при помощи метода анализа
иерархии, семантических таблиц или при помощи других средств на основе,
например, следующих критериев:
потребность в распределённом доступе к информации и расстояния
между участниками процесса;
объём хранимой в базе данных информации;
требования к скорости работы системы;
цена;
доступность;
стоимость сопровождения и т.д.
3) Разработка программного средства:
формирование алгоритма его работы;
создание базы данных и таблиц её реквизитов;
разработка кода программного средства.
4) Документирование программного средства и создание тестовых
наборов для проверки её работоспособности.
На этом этапе модели и расчёты, применяемые для определения
требований к ПС обобщаются и оформляются в соответствии с требованиями
стандартов, ПС тестируется, формируется комплект эксплуатационных и
сертификационных документов.
6 Управление требованиями
6.1 Определение требования и заинтересованного лица
Требование – условие или особенность, которой должна удовлетворять
система.
Требованием может быть:
– функциональность, необходимая заказчику или пользователю для
разрешения проблем (или получения прибыли).
– функциональность, которая должна быть реализована в системе в
соответствии с контрактом, стандартом, спецификацией, инструкцией или
другим официальным документом.
– ограничение, наложенное заинтересованным лицом.
Под заинтересованным лицом понимают личность, на которую оказывает
влияние разрабатываемая система. Два главных типа заинтересованных лиц –
это пользователи и заказчики. Пользователи – это лица, которые будут
пользоваться системой. Заказчики – лица, кто заказывает систему и отвечает в
дальнейшем за приемку системы. Обычно заказчики платят за разработку
системы. Кроме заказчиков и пользователей, есть и другие типы
заинтересованных лиц.
В качестве заинтересованного лица можно рассматривать:
– Любого, участвующего в разработке системы (бизнес-аналитики,
дизайнеры, кодировщики, тестеры, менеджеры проектов, менеджеры по
внедрению, дизайнеры сценариев использования, графические дизайнеры).
– Любого, кто привносит свои знания в систему (эксперты предметной
области, авторы документов, которые были использованы для сбора
требований, собственники веб-сайтов, ссылки на которые были
предоставлены).
– Руководство (президент компании, которого представляют заказчики,
директор отдела информационных технологий компании, проектирующей и
разрабатывающей систему).
– Лица, вовлеченные в управление, настройку и сопровождение системы
(хостинговая компания, справочная служба).
– Поставщики стандартов и регламентов (стандарты устанавливаются
поисковыми механизмами согласно содержанию веб-сайта, политическим
нормам, а также порядку налогообложения в конкретном штате).
6.2 Пирамида Требований
В зависимости от формата, источника и общих характеристик,
требования могут быть разделены на различные типы. Несколько типов
требований, наиболее часто использующихся в проектах:
– Потребности
заинтересованного
лица:
требование
от
заинтересованного лица.
– Функциональная
особенность:
предоставляемая
системой
функциональность, обычно формулируемая бизнес-аналитиком; назначение
особенности – удовлетворить потребности заказчика.
– Сценарий Использования (Use Case): описание поведения системы в
терминах последовательности действий.
– Дополнительное
требование:
другое
требование
(обычно
нефункциональное), которое не может быть охвачено сценариями
использования.
– Тестовые сценарии (Test Cases): спецификация тестовых исходных
данных, условий выполнения и ожидаемых результатов.
– Сценарий (Алгоритм, Scenario): особая последовательность действий;
определенный путь по сценариям использования.
Эти типы требований могут быть представлены в виде пирамиды, как
показано на Рисунке 1.1.
На верхнем уровне располагаются потребности заинтересованного лица.
На последующих уровнях находятся функциональные особенности, сценарии
использования и дополнительные требования. Достаточно часто на разных
уровнях этих требований могут быть выяснены детали различного уровня.
Чем ниже уровень, тем более детально описывается требование.
Например, потребность может быть следующей: «Данные должны
быть неизменными». Функциональная особенность этого требования будет:
«Система должна использовать реляционную базу данных». На уровне
дополнительных требований, требование еще более точное: «Система
должна использовать базу данных Oracle 9i».
Чем дальше вниз, тем более детальным становится требование. Один из
лучших способов управления требованиями – обобщать требования, по
крайней мере, на двух различных уровнях.
Например, документ Концепция («Vision») содержит высокоуровневые
требования (особенности), а низшие уровни пирамиды представляют
требования на более детальном уровне. У вышестоящих заинтересованных
лиц (таких, как вице-президент) нет времени читать 200 страниц детально
описанных требований. Но можно надеяться, что они смогут прочитать 12
страниц Концепции.
ПОТРЕБНОСТИ
ФУНКЦИОНАЛЬНЫЕ
ОСОБЕННОСТИ
USE CASES (СЦЕНАРИИ
ДОПОЛНИТЕЛЬНЫЕ
ИСПОЛЬЗОВАНИЯ)
ТРЕБОВАНИЯ
СЦЕНАРИИ
(АЛГОРИТМЫ)
ТЕСТОВЫЕ
ТЕСТОВЫЕ
СЦЕНАРИИ
СЦЕНАРИИ
Рисунок. Пирамида требований.
Главное отличие между потребностями и функциональными
особенностями – в источнике требований. Потребности поступают от
заинтересованных лиц, а функциональные особенности формулируются
бизнес-аналитиками.
Роль тестовых сценариев – проверить, корректно ли были реализованы
сценарии использования и дополнительные требования. Алгоритмы помогают
получить сценарии использования из тестовых сценариев, а также
способствуют проектированию и реализации определенных путей через
сценарии использования.
6.3 Трассировка (Связь) между Требованиями
Трассировка – это способ представления отношений между
требованиями различного уровня в системе. Она помогает определить
источник любого требования. Каждая потребность обычно соответствует
нескольким функциональным особенностям. Обычно это отношение «многиеко-многим», т.к. одна потребность может трассироваться ко
многим
функциональным особенностям, но из нескольких потребностей может быть
получена одна функциональная особенность. Одна потребность,
соответствующая одной функциональной особенности – это также общий
случай. Функциональные
особенности соответствуют сценариям
использования в отношении «многие-ко-многим». Функциональные
особенности также соответствуют дополнительным требованиям в отношении
«многие-ко-многим».
Каждый сценарий использования соответствует одному или более
сценарию (алгоритму), таким образом, их тип отношений – «один-комногим». Сценарии (алгоритмы) соответствуют тестовым сценариям в
отношении «один-ко-многим».
Трассировка играет несколько важных ролей:
– Подтверждение, что реализация удовлетворяет всем требованиям: Все,
что требовал заказчик, было реализовано.
– Подтверждение, что приложение делает только то, что было заказано:
Не реализовывать то, что заказчик никогда не просил.
– Анализ воздействия: Какие элементы будут затронуты при добавлении
новых требований или изменении текущих?
– Помощь в управлении изменениями: Когда некоторые требования
изменяются, мы хотим знать, какие тестовые сценарии должны быть
изменены, чтобы протестировать данное изменение.
Элемент трассировки – это элемент проекта, который должен быть
получен (трассирован) из другого элемента. В терминах RequisitePro под ним
понимается все, что принадлежит какому-либо типу требований. Примеры
типов требований в RequisitePro: потребности заинтересованных лиц,
функциональные особенности, сценарии использования, действующие лица и
термины справочника. В RequisitePro есть очень удобный способ отображения
трассировки (связи) с помощью специальных представлений (views).
6.4 Характеристики Хорошего Требования
Хорошее требование должно иметь следующие характеристики:
Недвусмысленность
Правдоподобность (реальность,
выполнимость)
Тестируемость (возможность
проверки)
Ясность (краткость, сжатость,
Независимость
простота, точность)
Элементарность
Корректность
Необходимость
Понятность
Независимость от реализации
(абстрактность)
Помимо этих критериев для отдельных требований, для набора
требований применяются три критерия. Требования должны быть:
– Постоянными.
– Немногословными.
– Завершенными.
Недвусмысленность
Должен существовать только один путь интерпретации требования.
Иногда двусмысленность проявляется в виде неопределенных акронимов.
Пример:
Треб.1: Система не должна принимать пароли более 15-ти символов.
Не совсем ясно, что система должна делать:
– Система не должна позволять пользователю вводить более чем 15
символов.
– Система должна отсекать введенную строку до 15-ти символов.
– Система не должна отображать сообщение об ошибке, если
пользователь вводит более чем 15 символов.
Исправленное требование содержит пояснение:
Треб.1: Система не должна принимать пароли более 15-ти символов.
Если пользователь вводит более 15-ти символов при выборе пароля,
сообщение об ошибке должно информировать пользователя о необходимом
исправлении пароля.
Тестируемость (Возможность Проверки)
Тестеры должны иметь возможность проверить, было ли требование
реализовано корректно. Тестирование должно быть либо пройдено, либо нет.
Чтобы быть пригодным для тестирования, требование должно быть ясным,
точным и недвусмысленным. Использование некоторых слов может сделать
требование невозможным для тестирования:
– Некоторые прилагательные: устойчивый, безопасный, точный,
эффективный, целесообразный, гибкий, настраиваемый, надежный,
дружелюбный, адекватный.
– Некоторые наречия и фразы с ними: быстро, безопасно, своевременно.
– Неспецифичные слова или акронимы: и т.д., и/или, TBD (to be
determined).
Треб.1: Система должна препятствовать одновременному доступу
большого числа пользователей.
Какое количество здесь имеется в виду под «большим числом» - 10, 100
или 1000?
Ясность (Краткость, Сжатость, Простота, Точность)
Требования не должны содержать ненужных выражений
информации. Они должны быть изложены кратко и просто:
или
Треб.1: Иногда пользователь будет вводить Airport Code (Код
Аэропорта), который система будет распознавать. Но иногда код можно
заменить близлежащим городом, и тогда пользователю не нужно знать код
аэропорта, т.к. система будет понимать название города.
Это предложение может быть заменено на более простое:
Треб.1: Система должна идентифицировать аэропорт на основании
Airport Code (Кода Аэропорта) или City Name (Названия Города).
Корректность
Если требование содержит факты, эти факты должны быть достоверны:
Треб.1: Цены на аренду машин должны включать все
соответствующие налоги (включая налог штата - 6%)
Налог зависит от штата, так что представленная цифра в 6 % некорректна.
Понятность
Требования должны быть грамматически правильные, написаны в
соответствующем стиле. Должны быть использованы стандартные
соглашения. Слово «должен» должно быть использовано вместо «будет»,
«обязан» или «может».
Правдоподобность (Реальность, Выполнимость)
Требование должно быть выполнимо в рамках существующих
ограничений, таких как время, деньги и доступные ресурсы.
Треб.1: Система должна иметь интерфейс на естественном языке,
который будет понимать команды на английском языке.
Это требование может быть нереальным из-за короткого периода
времени разработки.
Независимость
Чтобы понять требование, не нужно знать какое-либо другое
требование.
Треб.1: Список доступных рейсов должен включать номер рейса, время
отправления и время прибытия для каждого отрезка пути.
Треб.2: Он должен быть отсортирован по ценам.
Слово «Он» во втором предложении относится к предыдущему
требованию. И если порядок требований изменить, это требование будет
непонятно.
Элементарность
Требование должно содержать отдельный трассируемый элемент (для
которого возможно отслеживание связи):
Треб.1: Система должна предоставлять возможность бронировать
рейс, покупать билет, бронировать номер в гостинице, бронировать машину,
а также предоставлять информацию о развлечениях.
Это требование содержит пять элементарных требований, которые
затрудняют трассировку. Предложения, включающие предлоги «и» или «но»
должны быть пересмотрены на предмет разделениях их на элементарные
требования.
Необходимость
В требовании нет необходимости, если:
– Ни одному заинтересованному лицу требование не нужно.
– Удаление требования не повлияет на систему.
Пример требования, которое может быть удалено, т.к. оно не
предоставляет никакой новой информации:
Треб.1: Все требования, указанные в документе Концепции должны
быть реализованы и протестированы.
Независимость от Реализации (Абстрактность)
Требования не должны содержать ненужной информации о дизайне и
реализации системы:
Треб.1: Информация должна храниться в текстовом файле.
Решение того, каким образом информация будет храниться, и затем
передаваться пользователю, должно приниматься дизайнерами или
архитекторами системы.
Постоянство
Не должно существовать конфликтов между требованиями. Конфликты
могут быть прямые и косвенные.
Прямые конфликты возникают, когда ожидается различное поведение
системы в одной и той же ситуации:
Треб.1: Дата должна отображаться в формате мм/дд/гггг.
Треб.1: Дата должна отображаться в формате дд/мм/гггг.
Иногда возможно разрешить конфликт путем анализа условий, которые
явились источником данных требований. Например, если Треб.1 поступило от
американского пользователя, а Треб.2 от французского, то предыдущие
требования могут быть переписаны следующим образом:
Треб.1:
Для пользователей США дата должна отображаться в
формате мм/дд/гггг.
Треб.2: Для пользователей Франции дата должна отображаться в
формате дд/мм/гггг.
Немногословность
Каждое требование должно быть обозначено только один раз, и не
должно перекрываться другим требованием:
Треб.1: Для удобства ввода даты рейса в системе должен быть
доступен календарь.
Треб.2: Система должна отображать всплывающее окно с календарем
при вводе любой даты.
Первое требование (относящееся только к дате рейса) является частью
второго требования (относящееся к любой дате, вводимой пользователем).
Завершенность
Требование должно быть описано для всех возможных условий.
Хорошее требование должно удовлетворять как можно большему
количеству критериев. Однако они могут быть выражены в виде комбинации
вышеперечисленных критериев:
– Изменяемый: Если требование элементарное и немногословное, то
оно обычно изменяемое.
– Трассируемое: Если оно краткое и имеет уникальный идентификатор
(ID), то оно обычно трассируемое (способное к отслеживанию связи).
6.5 Процесса Управления Требованиями
Самое простое описание процесса управления требованиями содержит
следующие основные пункты:
– Формирование плана управления требованиями.
– Сбор требований.
– Разработка документа Концепции (Vision).
– Создание сценариев использования (Use Cases).
– Дополнительная спецификация.
– Создание тестовых сценариев (Test Cases) из сценариев
использования (Use Cases).
– Создание тестовых сценариев (Test Cases) из дополнительной
спецификации.
– Проектирование системы.
Первый шаг (план управления требованиями) определяет пирамиду
требований. На каждом из последующих семи шагов строится один элемент
пирамиды. Таблица 1.1. описывает, какие типы требований и какая
документация создаются на каждом шаге. Как Вы видите, процесс проходит
через пирамиду сверху вниз и слева направо.
Таблица 1.1. Требования и документы, созданные на каждом шаге.
Шаг
Тип требований
Документы
Сбор требований
Потребности
Запросы
заинтересованного лица
заинтересованного лица
Разработка документа
Функциональные
Концепция
Шаг
Тип требований
Концепции (Vision)
особенности
Создание сценариев
Сценарии использования,
использования (Use cases) алгоритмы
Дополнительная
спецификация
Создание тестовых
сценариев (test cases) из
сценариев использования
(use cases)
Создание тестовых
сценариев (test cases) из
дополнительной
спецификации
Проектирование системы
Документы
Дополнительные
требования
Тестовые сценарии
Спецификация
Сценариев
Использования
Дополнительная
спецификация
Тестовые сценарии
Тестовые сценарии
Тестовые сценарии
Диаграммы классов,
диаграммы
взаимодействий
UML-диаграммы
Управление требованиями – это интерактивный процесс. На типичной
итерации предполагается полное прохождение по пирамиде. На любой
итерации мы можем вернуться назад на несколько шагов и повторить
действия. Например, в процессе создания тестовых сценариев, мы можем
обнаружить, что отсутствует некоторая информация, и нам нужно получить ее
от заинтересованного лица. Таким образом, мы возвращаемся на шаг сбора
требований. Для обеспечения целостности модели, важно обновлять все
соответствующие требования. На начальных итерациях акцент делается на
первых нескольких шагах (в вершине пирамиды), а затем, на последующих
итерациях, больше времени проводится на низших уровнях пирамиды.
7 Модели жизненного цикла ПС
7.1 Каскадный жизненный цикл
При классическом жизненном цикле ПО (каскадная или водопадная
модель) разработка рассматривается как последовательность этапов, в
которой переход на следующий, иерархически нижний этап происходит
только после полного завершения работ на текущем этапе.
Рис. 1 . 1 . Классический жизненный цикл разработки ПО
Характеристика основных этапов:
Разработка начинается на системном уровне и проходит через анализ,
проектирование, кодирование, тестирование и сопровождение. При этом
моделируются действия стандартного инженерного цикла.
Системный анализ задает роль каждого элемента в компьютерной системе
и взаимодействие элементов друг с другом. Поскольку ПО является частью
большой системы, то анализ начинается с определения требований ко всем
системным элементам и назначения подмножества этих требований ПО.
На этапе системного анализа начинается решение задачи планирования
проекта ПО. В ходе планирования проекта определяются:
объем проектных работ и их риск,
необходимые трудозатраты,
формируются рабочие задачи и план-график работ.
Анализ требований относится к программному элементу – уточняются и
детализируются функции ПО, его характеристики и интерфейс.
Все определения документируются в спецификации анализа. На этапе
анализа требований завершается решение задачи планирования проекта.
Проектирование состоит в создании следующих представлений:
архитектуры ПО;
модульной структуры ПО;
алгоритмической структуры ПО;
структуры данных;
входного и выходного интерфейса (входных и выходных форм данных).
Исходные данные для проектирования содержатся в спецификации анализа.
В ходе проектирования выполняется трансляция требований к ПО во
множество проектных представлений.
При решении задач проектирования основное внимание уделяется качеству
будущего программного продукта.
Кодирование состоит в переводе результатов проектирования в текст на
языке программирования.
Тестирование – выполнение программы для выявления дефектов в
функциях, логике и форме реализации программного продукта.
Сопровождение - это внесение изменений в эксплуатируемое ПО.
Цели изменений:
исправление ошибок;
адаптация к изменениям внешней для ПО среды;
усовершенствование ПО по требованиям заказчика.
Сопровождение ПО состоит в повторном применении каждого из
предшествующих шагов (этапов) жизненного цикла к существующей
программе, но не в разработке новой программы.
Достоинства классического жизненного цикла:
дает план и временной график по всем этапам проекта,
упорядочивает ход конструирования.
Недостатки классического жизненного цикла:
реальные проекты часто требуют отклонения от стандартной
последовательности шагов;
цикл основан на точной формулировке исходных требований к ПО
(реально в начале проекта требования заказчика определены лишь частично);
результаты проекта доступны заказчику только в конце работы.
7.2 Спиральная модель
Спиральная модель включает следующие этапы:
1 – начальный сбор требований и планирование проекта;
2 – та же работа, но на основе рекомендаций заказчика;
3 – анализ риска на основе начальных требований;
4 —анализ риска на основе реакции заказчика;
5 —переход к комплексной системе;
6 – начальный макет системы;
7 – следующий уровень макета;
8 – сконструированная система;
9 —- оценивание заказчиком
Рис. 1.6. Спиральная модель:
Модель определяет четыре действия, представленные четырьмя
квадрантами спирали:
Планирование – определение целей, вариантов и ограничений.
Анализ риска – анализ вариантов и распознавание/выбор риска.
Конструирование – разработка продукта следующего уровня.
Оценивание – оценка заказчиком текущих результатов конструирования.
С каждой итерацией по спирали строятся все более полные версии ПО.
В первом витке спирали:
определяются начальные цели, варианты и ограничения;
распознается и анализируется риск.
если анализ риска показывает неопределенность требований, то
осуществляется макетирование (используется в квадранте конструирования).
для определения проблемных и уточненных требований может быть
использовано моделирование.
заказчик оценивает инженерную (конструкторскую) работу и вносит
предложения по модификации (квадрант оценки заказчиком).
Следующая фаза планирования и анализа риска базируется на
предложениях заказчика.
В каждом цикле по спирали результаты анализа риска формируются в
виде «продолжать, не продолжать».
Если риск слишком велик, проект может быть остановлен.
В большинстве случаев движение по спирали продолжается с каждым
шагом продвигает разработчиков к более общей модели системы.
В каждом цикле по спирали требуется конструирование (нижний правый
квадрант), которое может быть реализовано классическим жизненным циклом
или макетированием.
Количество действий по разработке (происходящих в правом нижнем
квадранте) возрастает по мере продвижения от центра спирали.
Достоинства спиральной модели:
наиболее реально (в виде эволюции) отображает разработку
программного обеспечения;
позволяет явно учитывать риск на каждом витке эволюции
разработки;
включает шаг системного подхода в итерационную структуру
разработки;
использует
моделирование
для
уменьшения
риска
и
совершенствования программного изделия.
Недостатки спиральной модели:
повышенные требования к заказчику;
трудности контроля и управления временем разработки.
7.3 Подход RAD
Одним из возможных подходов к разработке прикладного ПО в рамках
спиральной модели ЖЦ является получивший широкое распространение
способ так называемой быстрой разработки приложений, или RAD (Rapid
Application Development). RAD предусматривает наличие трех составляющих:
– небольших групп разработчиков (3-7 чел.), выполняющих работы по
проектированию отдельных подсистем ПО. Это обусловлено требованием
максимальной управляемости коллектива;
– короткого, но тщательного проработанного производственного графика
(до 3 месяцев);
– повторяющегося цикла, при котором разработчики по мере того, как
приложение начинает приобретать форму, запрашивают и реализуют в продукте
требования, полученные в результате взаимодействия с заказчиком.
Команда разработчиков должна представлять собой группу
профессионалов, имеющих опыт в проектировании, программировании и
тестировании ПО, способных хорошо взаимодействовать с конечным
пользователем и трансформировать их предложения в рабочие прототипы.
ЖЦ ПО в соответствии с подходом RAD включает 4 стадии:
1. Анализ и планирование требований предусматривает действия:
– определение функций, которые должна выполнять система;
– выделение наиболее приоритетных функций, требующих проработки в
первую очередь;
– описание информационных потребностей. Формулирование требований к
системе осуществляется в основном силами пользователей под руководством
специалистов-разработчиков.
Кроме того, на данной стадии реализуются следующие задачи:
– ограничивается масштаб времени;
– устанавливаются временные рамки для каждой из последующих
стадий. Определяется сама возможность реализации проекта в заданных
рамках финансирования, на имеющихся аппаратных средствах.
Результатом стадии должны быть список расставленных по приоритету
функций будущего ПО ЭИС и предварительные модели ПО.
2. Проектирование. На этой стадии часть пользователей принимает
участие в техническом проектировании системы под руководством
специалистов-разработчиков. Для быстрого получения работающих
прототипов приложений используются соответствующие инструментальные
средства (CASE – средства). Пользователи, непосредственно взаимодействуя с
разработчиками, уточняют и дополняют требования к системе, которые не
были выявлены на предыдущей стадии:
– более детально рассматриваются процессы системы;
– при необходимости для каждого элементарного процесса создается
частичный прототип: экранная форма, диалог, отчет, устраняющий неясности и
неоднозначности;
– устанавливаются требования разграничения доступа к данным;
– определяется состав необходимой документации.
После детального
определения состава процессов оценивается
количество так называемых функциональных точек разрабатываемой системы
и принимается решение о разделении ЭИС на подсистемы, поддающиеся
реализации одной командой разработчиков за приемлемое время (до 3
месяцев). Под функциональной точкой понимается любой из следующих
элементов разрабатываемой системы:
– входной элемент приложения (входной документ или экранная форма);
– выходной элемент приложения (отчет, документ, экранная форма)
– запрос (пара «вопрос/ответ»);
– логический файл (совокупность записей данных, используемых внутри
приложения);
– интерфейс приложения (совокупность записей данных, передаваемых
другому приложению или получаемых от него).
Далее проект распределяется между различными командами
разработчиков. (Опыт показывает, что для повышения эффективности работ
необходимо разбить проект на отдельные слабо связанные по данным и
функциям подсистемы. Реализация подсистем должна выполняться
отдельными группами специалистов. При этом необходимо обеспечить
координацию ведения общего проекта и исключить дублирование результатов
работ каждой проектной группы, которое может возникнуть в силу наличия
общих данных и функций).
Результатом данной стадии должно быть:
– общая информационная модель системы;
– функциональные модели системы в целом и подсистем, реализуемых
отдельными командами разработчиков;
– точно определенные интерфейсы между автономно разрабатываемыми
подсистемами;
– построенные прототипы экранных форм, отчетов, диалогов.
3. На стадии реализации выполняется непосредственно сама быстрая
разработка приложения.
Разработчики производят итеративное построение реальной системы на
основе полученных на предыдущей стадии моделей, а также требований
нефункционального
характера
(требования
к
надежности,
производительности и т.д.).
Пользователи оценивают получаемые результаты и вносят коррективы,
если в процессе разработки система перестает удовлетворять определенным
ранее требованиям. Тестирование системы осуществляется в процессе
разработки.
После окончания работ каждой отдельной команды разработчиков
производится постепенная интеграция данной части системы с остальными,
формируется полный программный код, выполняется тестирование
совместной работы данной части приложения, а затем тестирование системы в
целом. Реализация системы завершается выполнением работ:
– Осуществляется анализ использования данных и определяется
необходимость их распределения.
– Производится физическое проектирование базы данных
– Формируются требования к аппаратным ресурсам.
– Устанавливаются способы увеличения производительности.
– Завершается разработка документации проекта.
Результатом стадии является готовая система, удовлетворяющая всем
согласованным требованиям.
4. На стадии внедрения производится обучение пользователей,
организационные изменения и параллельно с внедрением новой системы
продолжается эксплуатация существующей системы (до полного внедрения
новой). Так как стадия реализации достаточно продолжительна, планирование
и подготовка к внедрению должны начинаться заранее, как правило, на стадии
проектирования системы. Приведенная схема разработки ЭИС не является
абсолютной. Возможны различные варианты, зависящие, например, от
начальных условий, в которых ведется разработка:
– разрабатывается совершенно новая система;
– уже было проведено обследование организации и существует модель ее
деятельности.
В организации уже существует некоторая ЭИС, которая может быть
использована в качестве начального прототипа или должна быть
интегрирована с разрабатываемой системой.
Следует отметить, что подход RAD, как и любой другой подход, не
может претендовать на универсальность. Он хорош в первую очередь для
относительно небольших проектов, разрабатываемых для конкретного
заказчика. Если же разрабатывается крупномасштабная система (например,
масштаба отрасли),
которая не является законченным продуктом, а
представляет собой комплекс программных компонентов, адаптируемых к
программно-аппаратным платформам, системам управления базами данных
(СУБД), средствам телекоммуникаций, то на первый план выступают такие
показатели проекта как управляемость и качество, которые могут войти в
противоречие с простотой и скоростью разработки. Для таких проектов
необходимы высокий уровень планирования и жесткая дисциплина
проектирования, строгое следование заранее разработанным протоколам и
интерфейсам, что снижает скорость разработки.
Подход RAD не применим для построения сложных расчетных
программ, операционных систем.
Не годится этот подход и для приложений, в которых отсутствует ярко
выраженная интерфейсная часть, наглядно определяющая логику работы
системы и приложений, от которых зависит безопасность людей, так как
итеративный подход предполагает, что первые несколько версий наверняка не
будут полностью работоспособны, что в данном случае исключается.
Перечислим основные принципы подхода RAD.
– Разработка приложений итерациями.
– Необязательность полного завершения работ на каждой стадии ЖЦ ПО.
– Обязательность вовлечения пользователей в процесс разработки ЭИС.
– Целесообразность применения CASE – средств, обеспечивающих
целостность проекта и генерацию кода приложений.
– Целесообразность применения средств управления конфигурацией,
облегчающих внесение изменений в проект и сопровождение готовой системы.
– Использование прототипирования, позволяющее полнее выяснить и
удовлетворить потребности пользователей.
– Тестирование и развитие проекта, осуществляемые одновременно с
разработкой.
– Ведение разработки немногочисленной хорошо управляемой командой
профессионалов.
– Грамотное руководство разработкой системы, четкое планирование и
контроль выполнения работ.
8 Ресурсы для жизненного цикла сложных программных средств
Общее понятие - доступные ресурсы жизненного цикла ПС включает
реальные финансовые, временные, кадровые и аппаратурные ограничения, в
условиях которых происходит создание и совершенствование комплексов
программ. В зависимости от характеристик объекта разработки на ее
выполнение выделяются ресурсы различных видов и объема. Эти факторы
проявляются как дополнительные характеристики программных продуктов и
их рентабельности, которые следует учитывать и оптимизировать, начиная с
системного анализа ЖЦ ПС. В результате доступные ресурсы становятся
косвенными критериями или факторами, влияющими на выбор методов
разработки, на достигаемые качество и эффективность применения ПС.
Многие проекты информационных систем терпели и терпят неудачу из-за
отсутствия у разработчиков и заказчиков при подготовке контракта четкого
представления о реальных финансовых, трудовых, временных иных ресурсах,
необходимых для их реализации. Поэтому одной из основных задач при
системном проектировании ПС является экономический анализ и
определение необходимых ресурсов для создания и всего ЖЦ ПС в
соответствии с требованиями контракта и технического задания.
Наиболее общим видом ресурсов, используемых в жизненном цикле
ПС, являются допустимые финансово-экономические затраты или
эквивалентные им величины трудоемкости соответствующих работ. При
разработке, тестировании и анализе качества этот показатель может
применяться или как вид ресурсных ограничений, или как оптимизируемый
критерий, определяющий целесообразную функциональную пригодность ПС.
При этом необходимо также учитывать затраты на разработку, закупку и
эксплуатацию системы качества, на технологию и комплекс автоматизации
проектирования программ и баз данных, которые могут составлять
существенную часть совокупной стоимости и трудоемкости разработки и
всего ЖЦ ПС.
Время или допустимая длительность разработки определенных
версий ПС является "невосполнимым ограниченным ресурсом реальных
проектов. Этот ресурс все больше определяет достижимое качество
комплексов программ в процессе их разработки и сопровождения. Высокие
требования заказчиков к сжатым срокам реализации проектов, естественно,
ограничивают разработчиков и испытателей в продолжительности и объеме
возможного системного анализа и проектирования, разработки и, особенно,
тестирования программ. Увеличение числа, привлекаемых для этого
специалистов, при опытной эксплуатации или тестировании, только в
некоторых пределах позволяет ускорять разработку и увеличивать совокупное
число тестов при проверках, для повышения качества программ.
Кадры специалистов можно оценивать численностью, а также
тематической и технологической квалификацией, которые всегда ограничены.
В создании крупномасштабных ПС участвуют системные аналитики и
руководители различных рангов, программисты и вспомогательный
обслуживающий персонал в некотором, желательно, рациональном сочетании.
Определяющими являются совокупная численность и структура коллектива, а
также его подготовленность к коллективной разработке конкретного типа ПС
и к применению им системы обеспечения качества функционирования.
Доступные разработчикам ПС вычислительные ресурсы объектных и
технологических ЭВМ являются одним из важнейших факторов,
определяющим достижимое качество сложных ПС. В процессе
проектирования целесообразно выделять определенные ресурсы ЭВМ на
оперативное обеспечение качества, повышение защищенности и надежности
функционирования. Допустимая величина и рациональное распределение
ресурсов ЭВМ на отдельные методы улучшения определенных
конструктивных характеристик качества ПС, оказывают существенное
влияние на достигаемые их значения.
Обобщенными ресурсами проекта ПС являются доступные
стоимость или совокупные трудовые, временные и материальные
затраты, необходимые для приобретения, создания, модификации и
эксплуатации компонентов и всего комплекса программ. Эти характеристики
непосредственно влияют практически на все показатели качества и
определяют рентабельность покупки или создания заново конкретного
программного продукта. Это означает, что качество является относительным
понятием, которое зависит от ресурсов и субъектов, осуществляющих его
оценку с позиции эффективности использования, а также от состояния рынка
соответствующей продукции, ее производителей и технологий. Ориентация на
потребителей подразумевает анализ их нужд и определение возможностей
рынка удовлетворить эти потребности. При этом следует учитывать
рыночную конкуренцию двух видов: между поставщиками готовых к
применению программных средств с фиксированным качеством и между
разработчиками, способными обеспечить жизненный цикл ПС или его
существенную часть, с характеристиками качества, требующимися
конкретному заказчику. В последнем случае на требуемое качество могут
оказывать влияние не только заказчик и непосредственные пользователи, но и
различные посредники, организационные и торговые структуры, а также
исполнители проекта.
В начале проектирования ПС всегда возникает задача оценивания
ресурсов, которые необходимы и доступны для создания и обеспечения всего
ЖЦ ПС, а также возможной экономической эффективности последующего
применения комплекса программ по назначению при условии реализации
требуемых характеристик качества. Экономическая эффективность и затраты
имеют самостоятельное значение и методологию при анализе ЖЦ ПС. При
планировании проектов программных средств, часто инициатором разработки
является разработчик-поставщик, который самостоятельно принимает все
решения о проектировании за счет собственных ресурсов и предполагает
возместить затраты при реализации ПС на рынке. В других случаях имеется
определенный заказчик потребитель, который способен задать основные цели,
характеристики качества и обеспечить ресурсы для реализации проекта.
Таким образом, при экономическом анализе проектов ПС возможны два
сценария:
– создание и весь жизненный цикл комплекса программ и/или базы
данных ориентируется разработчиком на массовое тиражирование и
распространение на рынке, для заранее не известных покупателейпользователей в различных сферах применения, при этом отсутствует
приоритетный внешний потребитель-заказчик, который определяет и диктует
основные требования, а также финансирует проект;
– разработка проекта ПС и/или БД предполагается поставщиком
разработчиком для конкретного потребителя-заказчика, который его
финансирует, с определенным, необходимым ему тиражом и известной,
ограниченной областью применения результатов разработки.
9 Показатели качества программных средств
Для того чтобы получить представление о качестве программного
средства, необходимо сформировать некоторые общие, однозначно
поминаемые показатели, используемые при его оценке.
Качество программного средства – совокупность свойств программного
продукта, которые обуславливают возможность удовлетворить определенные
потребности пользователя в соответствии с назначением.
Основные затруднения в определении показателей связаны с тем, что
они носят качественный характер и должны оценивать различные свойства
сопоставляемых программных изделий. А эти свойства присущи не самому
программному изделию, а связаны с объектом применения ПИ. Таким
образом, качество ПИ относительное понятие, которое имеет смысл только
лишь в связи с реальными условиями применения.
ГОСТ Р ИСО/МЭК 9126:1993 регламентирует 6 основных
характеристик качества ПП и детализация их.
1. Функциональная пригодность – наиболее неопределенная и
объективно трудно оцениваемая характеристика программного средства.
Области применения, номенклатура и функции комплексов программ
охватывают столь разнообразные сферы деятельности человека, что
невозможно выделить и унифицировать небольшое число атрибутов для
оценки и сравнения этой характеристики в различных комплексах программ.
Функциональная пригодность ПП и конкретные показатели для её
оценки:
пригодность по применению для решения задач – связь
функционального назначения ПИ с задачами, которые оно должно решать;
точность – возможность ведения БД,
насколько алгоритм
формирования результата обеспечивает точность его получения;
защищенность – требования к надежности из ТЗ (от ошибок,
несанкционированного доступа, возможность восстановления)
способность к взаимодействию – с другими ПИ;
согласованность со стандартами отрасли;
согласованность со стандартами проектирования.
2. Надежность – измерение количественных метрик атрибутов
характеристик в использовании: завершенности, устойчивости к дефектам,
восстанавливаемости и доступности/готовности.
Надежность характеризуется:
уровнем завершенности (отсутствие остаточных ошибок после ввода
в эксплуатацию);
обратной связью по оценке продукта потребителем;
устойчивостью к ошибкам эксплуатацию;
перезапускаемостью – возможностью восстановления БД в случае
нарушения её работы.
3. Практичность (применимость) программных средств включает
определение понятности, простоты использования, изучаемости и
привлекательности программного средства. В основном это качественная (и
субъективная) оценка в баллах, однако некоторые атрибуты можно оценить
количественно по трудоемкости и длительности выполнения операций при
использовании программного средства, а также по объему документации,
необходимой для их изучения.
Применимость включает:
понятность пользовательского интерфейса (насколько интерфейс
приспособлен к уровню подготовки пользователя);
характер предоставления эксплуатирующей документации (её вид,
носит ли она функциональную направленность);
обучаемость (тематические справочники).
4. Потребность в ресурсах памяти и производительности
компьютера (эффективность) в процессе решения задач значительно
изменяется в зависимости от состава и объема исходных данных. Для
корректного
определения
предельной
пропускной
способности
информационной системы с данным программным средством нужно измерить
экстремальные
и
средние
значения
длительностей
исполнения
функциональных групп программ и маршруты, на которых они достигаются.
Если предварительно в процессе проектирования производительность
компьютера не оценивалась, то, скорее всего, понадобится большая доработка
или даже замена компьютера на более быстродействующий.
Эффективность включает:
ресурсная эффективность – насколько требования к использованию
ресурсов применимы к результатам решения задач;
временная эффективность.
5. Сопровождаемость можно оценивать полнотой и достоверностью
документации о состояниях программного средства и его компонентов, всех
предполагаемых и выполненных изменениях, позволяющей установить
текущее состояние версий программ в любой момент времени и историю их
развития. Она должна определять стратегию, стандарты, процедуры,
распределение ресурсов и планы создания, изменения и применения
документов на программы и данные.
Сопровождаемость включает:
удобство для анализа (удобство локализации ошибок, хорошо
структурированных ПИ);
изменяемость;
стабильность;
тестируемость.
6. Мобильность (переносимость) – качественное определение
экспертами адаптируемости, простоты установки, совместимости и
замещаемости программ, выражаемое в баллах. Количественно эту
характеристику программного средства и совокупность ее атрибутов можно (и
целесообразно) оценить в экономических показателях: стоимости,
трудоемкости и длительности реализации процедур переноса на иные
платформы определенной совокупности программ и данных.
Переносимость характеризуется:
адаптируемостью – как легко происходит адаптация пользователя и
аппаратных средств;
стуктурируемостью;
замещаемостью – ПИ должно замещать свою предыдущую версию,
возможность испытания элементов ПИ в следующих версиях замещающего
его ПИ;
внедряемостью – насколько трудоемки работы по установке ПИ.
Помимо стандарта ISO 9126 существуют отечественные стандарты:
ГОСТ 21195-89 «Оценка качества программных средств. Общие
положения»
ГОСТ 28806-90 «Качество программных средств. Термины и
определения».
10 Модели качества процессов конструирования
В условиях жесткой конкуренции, важно гарантировать высокое качество
процесса конструирования ПО.
10.1 CMM/CMMI
Наверное, самым именитым стандартом качества следует считать
Capability Maturity Model (CMM) – модель оценки уровня зрелости процессов
разработки вместе с его производными. Он был создан SEI (Software
Engineering Institute), который финансируется за счет Министерства обороны
США и является структурной единицей Университета Карнеги-Меллона.
Первая официальная версия стандарта вышла в 1993 г., хотя работы над ним
начались гораздо раньше – основные его положения были опубликованы еще
в 1986 г.
Успех CMM предопределило несколько факторов. Этот стандарт был
одним из первых, изначально учитывающих специфику создания ПО. Он
оказался достаточно прост и прозрачен как для понимания, так и для
использования, и регламентировал, «что», а не «как» делать, а потому
подходил для различных моделей жизненного цикла, методологий разработки
и не накладывал каких-либо ограничений на стандарты документирования,
инструментарий, среду и языки, применяемые в проектах. И, пожалуй,
основным фактором, предопределившим популярность CMM, явилось
сотрудничество SEI с Министерством обороны США, что де-факто означало
использование стандарта при реализации проектов по заказу этого ведомства.
Модель CMM (табл. 1) предусматривает пять уровней зрелости,
каждому из которых соответствуют определенные ключевые области
процессов (Key Process Areas, KPA).
Таблица 1. Уровни модели CMM
№
Название
Ключевые области процесса
уровня
уровня
1
Начальный
2
Повторяющийся
Если организация находится на этом уровне, то ключевых
областей процессов для нее не предусмотрено
Управление программными конфигурациями. Обеспечение
№
уровня
Название
уровня
3
Определенный
4
Управляемый
5
Оптимизируемый
Ключевые области процесса
качества программных продуктов. Управление контрактами
подрядчиков. Контроль за ходом проектов. Планирование
программных проектов. Управление требованиями
Экспертные оценки. Координация взаимодействий проектных
групп. Инженерия программного продукта. Комплексный
менеджмент ПО. Программа обучения персонала. Определение
организационного
процесса.
Область
действия
организационного процесса
Менеджмент качества ПО. Управление процессом на основе
количественных методов
Управление
изменением
процесса.
Управление
технологическими изменениями. Предотвращение дефектов
Деление на уровни и определение KPA для каждого из них позволяет
последовательно внедрять CMM, используя стандарт в качестве руководства,
которое может обеспечить постоянное совершенствование процесса
разработки.
Стандарт CMM оказался весьма успешным, и впоследствии на его
основе была создана целая серия стандартов (табл. 2). Притом он получил
новое имя – SW-CMM (Capability Maturity Model for Software), точнее
отражающее его положение в достаточно многочисленном семействе
стандартов.
Таблица 2. Развитие стандартов CMM
Название
Описание
стандарта
System Engineering
CMM (SE-CMM)
Trusted CMM (TCMM)
System Security
Engineering CMM
(SSE-CMM)
People CMM (P-CMM)
Software Acquisition
CMM (SA-CMM)
Integrated Product
Development CMM
(IPD-CMM)
Ориентирован на вопросы системного инжиниринга – разработку
продуктов (анализ требований, проектирование систем продукта и их
интеграция) и их производство (планирование производственных линий и
функционирование)
Предназначен для обслуживания чувствительных и закрытых
программных систем, которые требуют гарантии высокого качества ПО
Сфокусирован на аспектах безопасности программной инженерии,
обеспечивает безопасный процесс разработки, в том числе и безопасность
членов команды создателей
Рассматривает вопросы развития персонала в софтверных организациях
Охватывает вопросы приобретения программных продуктов у внешних
организаций
Служит средой для интеграции усилий по разработке на всех этапах
жизненного цикла и со стороны каждого отдела компании
Однако практическое применение стандартов серии CMM показало, что
они не обеспечивают безоговорочного успеха в разработке ПО. Эти стандарты
не были хорошо согласованы между собой – одновременное внедрение
различных модификаций CMM могло оказаться достаточно сложной задачей
и приводило в недоумение специалистов организаций, которые с этим
сталкивались.
Также существенная проблема CMM состоит в необходимости
«выравнивания»
всех
процессов.
Если
организация
пытается
сертифицироваться на определенный уровень, то она должна обеспечить
соответствующий уровень для всех своих процессов. Даже если специфика,
методология или особенности разработки не располагают к выполнению
определенных процессов, сертификация это требует.
Еще одна проблема вызвана тем положением, которое заняли стандарты
CMM в современной индустрии ПО. Поскольку организация, обладающая
высоким уровнем в соответствии с CMM, должна обеспечивать более высокие
показатели программных продуктов по сравнению с теми, кто
сертифицирован на низших уровнях, то стандарт стал применяться в качестве
критерия отбора для участия в тендерах на разработку ПО или в
аутсорсинговых проектах. Спрос на сертифицированные организации породил
предложение по «быстрой и безболезненной сертификации».
Подобная ситуация стала возможной благодаря недостаткам процесса
сертификации. Сертификации подлежит не вся организация в целом, а только
определенный проект. Ничто не мешает организации создать «образцовопоказательный» проект, выполняемый с учетом всех требований высоких
уровней стандарта CMM, получить соответствующий уровень сертификации
и заявить о том, что все продукты отвечают такому-то уровню стандарта.
Разрешить большинство проблем CMM призван новый стандарт SEI –
Capability Maturity Model Integrated (CMMI) – Интегрированная модель
оценки уровня зрелости процессов разработки. Стандарт CMMI изначально
создавался таким образом, чтобы объединить существующие варианты CMM
и исключить какие-либо противоречия при его практическом применении в
различных сферах деятельности высокотехнологичных компаний.
Для того чтобы устранить необходимость «выравнивания» процессов
организации и быть более приспособленным к ее бизнес-потребностям, а не
наоборот, стандарт CMMI имеет две формы представления – классическую,
многоуровневую, соответствующую CMM, и новую, непрерывную.
Непрерывная форма представления рассматривает не уровни зрелости
(Maturity Levels), а уровни возможностей (Capability Levels), которые
оцениваются для отдельных областей процессов (Process Areas, PA). В табл. 3
дано соответствие уровней зрелости стандарта CMM, а также уровней
зрелости многоуровневого представления CMMI и уровней возможностей
непрерывного представления CMMI.
Таблица 3. Соответствие уровней CMM/CMMI
№
уровня
Уровень
зрелости
CMM
Уровень зрелости
многоуровневого
представления CMMI
Уровень
возможностей
непрерывного
представления CMMI
0
1
2
3
4
5
–
Начальный
Повторяющийся
Определенный
Управляемый
Оптимизируемый
–
Начальный
Управляемый
Определенный
Управляемый количественно
Оптимизируемый
Незавершенный
Выполнимый
Управляемый
Определенный
Управляемый количественно
Оптимизируемый
SEI отказывается от CMM и взамен активно продвигает CMMI, обещая
ужесточить контроль за процессом сертификации, вводя новые классы,
позволяющие сократить затраты на него и сделать его более привлекательным
для небольших организаций; обеспечивая совместимость со стандартами ISO.
Однако факт остается фактом: в современных условиях наличие сертификата
определенного уровня CMM/CMMI не является таким значимым фактором,
как несколько лет назад, и принимается без дополнительных вопросов разве
что в проектах, выполняемых по государственному заказу.
10.2 Стандарты ISO
Стандарты ISO 9000 – обширная и наиболее распространенная во всем
мире серия стандартов качества. Они охватывают множество отраслей
современной индустрии и периодически обновляются.
Изначально стандарты ISO 9000 слабо учитывали специфику отрасли
ПО и были больше ориентированы на производственную сферу. Однако в
конце 1980-х годов в Великобритании был создан первый ориентированный
на области разработки ПО стандарт, получивший название ISO 9000-3:1997.
Несмотря на то, что ISO 9000-3 оперировал терминологией, которая
используется при разработке ПО, и рассматривал характерные для
программной индустрии вопросы, он являлся не более чем расширенным
вариантом ISO 9001:1994, а потому не всегда соответствовал специфике
программных проектов.
Сегодня на смену ISO 9000-3 пришел стандарт ISO/IEC 90003:2004,
который, в свою очередь, является проекцией промышленного стандарта ISO
9001:2000 на программную индустрию. По сравнению с предыдущим он
гораздо более приспособлен к специфике отрасли, в частности, ссылается на
модели жизненного цикла программных систем и детально рассматривает
вопросы, характерные для разработки ПО. Однако стандарт ISO 90003:2004 –
это стандарт обеспечения качества и не может быть использован для оценки
уровня зрелости и предсказания результата программного проекта. В таких
случаях прибегают к стандарту ISO/IEC 15504. Стандарт ISO/IEC 15504
предназначен для оценки процесса разработки информационных систем, в
частности, программного обеспечения. Он изначально был спроектирован
таким образом, чтобы в значительной степени соответствовать
существующим в отрасли стандартам оценки процесса создания ПО. Именно
это требование определило схожесть стандарта с основными принципами
CMM/CMMI. Его текущая версия предусматривает шесть уровней
возможностей (от нулевого до пятого), которые соответствуют уровням
возможностей непрерывного представления стандарта CMMI (табл. 4).
Таблица 4. Уровни CMMI (2004)
№
Название уровня
уровня
возможностей стандарта
ISO/IEC 15504
0
1
2
3
4
5
Незавершенный
Выполнимый
Управляемый
Установленный
Предсказуемый
Оптимизируемый
Название уровня возможностей
непрерывного представления
CMMI
Незавершенный
Выполнимый
Управляемый
Определенный
Управляемый количественно
Оптимизируемый
Следует отметить, что в целом стандарты ISO/IEC 15504 и CMMI
взаимозаменяемы, в частности, для CMMI предусматривается режим
сертификации, в соответствии с которым одновременно проводится и
сертификация по ISO/IEC 15504.
Качество программного продукта регламентирует стандарт ISO/IEC
9126, состоящий из отдельных частей, которые выпускаются независимо (на
текущий момент их четыре: модель качества, внешние метрики, внутренние
метрики и качество при использовании метрик). ISO/IEC 9126 предлагает
комплексную иерархическую структуру для описания качественных
характеристик ПО. Так, характеристиками качества наиболее высокого уровня
являются
функциональность,
надежность,
удобство
применения,
эффективность, сопровождаемость, переносимость. Каждая из них, в свою
очередь, подразделяется на другие, более детальные. На текущий момент
ISO/IEC 9126 – пожалуй, самый авторитетный стандарт, определяющий
качество программного продукта.
Несмотря на то, что ISO позже, чем SEI взялась за разработку
стандартов для программной индустрии, она имеет немало шансов завоевать
передовую позицию. Стандарты ISO весьма обширны, процедура
сертификации хорошо отработана. Отметим, что ISO требует периодической
ресертификации, чего SEI не проводила для CMM.
10.3 Шесть сигм
Начало методологии шести сигм (Six Sigma) было положено в Motorola
в конце 1980-х годов. Motorola провозгласила курс на повышение качества
производимой продукции, одним из направлений которого было снижение
количества дефектов до уровня 6σ (где σ – дисперсия) – 3,4 дефекта на
миллион возможных (на самом деле 3,4 дефекта на миллион возможных
означает не 6, а 4,5 сигмы, однако разработчики методологии добавили
полторы сигмы для того, чтобы учесть нестабильность процессов).
Подобное значение было избрано не случайно – в результате проведенных в
компании исследований было установлено, что именно такой уровень
качества обеспечит, кроме явных преимуществ в виде повышения
конкурентоспособности продукции, также сокращение издержек за счет
уменьшения затрат на доводку некачественных разработок и устранение
дефектов.
Реализация шести сигм происходит в виде процесса DMAIC (Define,
Measure, Analyze, Improve, Control):
определение;
измерение;
анализ;
совершенствование;
управление.
Этот процесс построен на количественных методах принятия решений.
Сильная сторона шести сигм – ориентация на интенсивное применение
математического аппарата.
Несмотря на промышленное происхождение, методология шесть сигм
получила популярность среди разработчиков ПО. Ориентация на
количественные методы позволила применять шесть сигм как инструмент для
обеспечения постоянного совершенствования процесса. Особенно заметно его
преимущество при использовании в организациях, которые достигли высоких
уровней зрелости в соответствии с CMM/CMMI и ISO/IEC 15504.
Недостатки:
1 Основное преимущество шести сигм одновременно является и
основным недостатком методологии: ориентация на количественные методы
предусматривает наличие возможностей для их применения. Организация
должна приложить определенные усилия для того, чтобы внедрить методы
количественной оценки производительности труда, показателей качества и т.
д. Количественная оценка в отрасли ПО – весьма сложная задача.
2 Шесть сигм ориентирована на совершенствование процесса и не
предусматривает изначального повышения показателей его эффективности.
Для этих целей необходимы другие подходы.
На практике шесть сигм очень часто успешно применяется совместно с
другими стандартами и системами обеспечения качества, позволяя выявить
причины проблем и помочь их устранить.
10.4 ITIL
Весьма популярная в Европе методология ITIL (IT Infrastructure Library)
ориентирована на обеспечение функционирования IT-инфраструктуры. ITIL
разработана при участии правительства Великобритании в конце 80-х –
начале 90-х годов XX в. и первоначально получила распространение в
правительственных проектах этой страны.
ITIL – это зрелая и обширная методология, охватывающая практически
все вопросы, связанные с разворачиванием и использованием
информационных систем. В настоящий момент она имеет следующие
составляющие, соответствующие ключевым вопросам взаимодействия
технологий и бизнеса: служба поддержки, оказание услуг, управление
безопасностью, IT-инфраструктурой, цепочками поставок, программными
проектами и активами, бизнес-вопросы обеспечения IT-проектов, в том числе
и аутсорсинг. ITIL хорошо согласуется со стандартами серии ISO 9000 и
может служить основой для проведения по ним последующей сертификации.
Однако данная методология не затрагивает непосредственно процессов
разработки ПО, а потому обычно в софтверных компаниях применяется
совместно с другими, более ориентированными на специфику ПО
стандартами, например CMMI. Особую популярность ITIL получила в таких
смежных с разработкой ПО областях, как служба поддержки, внедрение и
сопровождение ПО, предоставление услуг по поддержке IT-инфраструктуры.
Заметим, что эта методология допускает достаточно неоднозначную
интерпретацию, поэтому ее внедрение должно происходить при участии
опытных специалистов во избежание упрощения и неверной трактовки ее
положений.
11 Стандартизация ПС
11.1 Стандартизация программных продуктов
Стандартизация на современном этапе определяет суть технической
политики в народном хозяйстве всех стран мира и по существу является
техническим законодательством.
Деятельность по стандартизации весьма динамична, она всегда
соответствует изменениям, происходящим в различных сферах жизни
общества, прежде всего в экономической, должна стремиться успевать и даже
предвосхищать их, чтобы стандарты способствовали развитию, а не
отставанию отечественного производства.
Система стандартизации представляет возможность для широкого
участия в процессе создания стандарта всех заинтересованных сторон. Это
реализуется законным правом изготовителей продукции, потребителей,
разработчиков проектов, представителей общественных организаций,
отдельных специалистов участвовать в работе технических комитетов.
В процессе стандартизации вырабатываются нормы, правила,
требования, характеристики, касающиеся объекта стандартизации, которые
оформляются в виде нормативного документа.
Документирование разработки, сопровождения и эксплуатации
программ выполняют в соответствии с группой стандартов ГОСТ 19.ХХХХХ.
Предусматривается построение обозначений стандартов в следующем
порядке:
номер 19 – класс стандартов ЕСПД;
после 19 ставится точка и далее одна цифра – код классификационной группы стандартов, определенной группы стандартов;
далее идет двузначное число – порядковый номер стандарта
в группе;
через тире за ним ставится двузначное число – год регистрации
стандарта.
Ниже приведены государственные стандарты на компоненты,
стандартизируемой продукции.
ГОСТ 19.101—77, введен с 1981 г. Виды программ и программных
документов.
ГОСТ 19.102—77. Стадии разработки.
ГОСТ 19.103—77. Обозначения программ и программных продуктов.
ГОСТ 19.104—78, введен с 1981 г. Основные надписи.
ГОСТ 19.105—78, введен с 1981 г. Общие требования к программным
документам.
ГОСТ 19.106—78, введен с 1981 г. Требования к программным
документам, выполненным печатным способом.
ГОСТ 19.201—78, введен с 1981 г. ТЗ. Требования к содержанию и
оформлению.
ГОСТ 19.202-78. Спецификация.
ГОСТ 19.301—79, введен с 1983 г. Программа и методика испытаний.
ГОСТ 19.401—78, введен с 1983 г. Текст программы.
ГОСТ 19.402—78, введен с 1981 г. Описание программы.
ГОСТ 19.403—79. Ведомость держателей подлинников.
ГОСТ 19.404—79. Пояснительная записка.
ГОСТ 19.501-78. Формуляр.
ГОСТ 19.502—78, введен с 1981 г. Описание применения.
ГОСТ 19.503—79, введен с 1981 г. Руководство системного программиста.
ГОСТ 19.504—79, введен с 1981 г. Руководство программиста.
ГОСТ 19.505—79, введен с 1981 г. Руководство оператора.
ГОСТ 19.506—79, введен с 1981 г. Описание языка.
ГОСТ 19.507—79, введен с 1981 г. Ведомость эксплуатационных
документов.
ГОСТ 19.508—79. Руководство по техническому обслуживанию.
ГОСТ 19.601—78. Общие правила дублирования, учета и хранения.
ГОСТ 19.602—78. Правила дублирования, учета и хранения программных
документов, выполненным печатным способом.
ГОСТ 19.603—78, введен с 1981 г. Общие правила внесения изменений.
ГОСТ 19.604—78, введен с 1981 г. Правила внесения изменений в
программные документы, выполненные печатным способом.
ГОСТ 19.701—90, введен с 1992 г. Схемы алгоритмов, программ, данных и
систем.
Стандартизация помогла унифицировать и автоматизировать процесс
создания программ на базе инструментальных и программных средств, создать
системы автоматизированного программирования
с использованием
инструментальных и программных средств. К настоящему времени АС
позволяют унифицировано выполнять следующие процессы:
анализ задачи, разбиение её на подзадачи;
анализ структур данных;
запись требований к программе и разработку ее общей структуры;
выделение модулей, написание их спецификаций, определение
интерфейса между ними;
вычерчивание блок-схем алгоритмов;
непосредственно программирование (кодирование);
отладку и тестирование;
анализ качества и количества затраченного труда на разработку ПИ.
Стандартизация улучшает контроль и регламентацию труда программистов, поэтому иногда она встречает у них психологический барьер.
11.2 Виды стандартных программных документов
Программные документы и их содержание:
спецификация – перечень и назначение всех файлов ПС, включая
файлы документации;
ведомость держателей подлинников – список предприятий, хранящих
подлинники программных документов, составляется только для сложных ПС;
текст программы – запись кодов программы и комментарии к ним;
описание программы – информация о логической структуре и
функционировании программы;
программа и методика испытаний – перечень и описание
требований, которые должны быть проверены в ходе испытания программы,
методы контроля;
техническое задание – документ, в котором излагаются назначение
и область применения программы, требования к ПС, стадии и сроки
разработки, виды испытаний;
пояснительная записка – обоснование принятых и примененных
технических и технико-экономических решений, схемы и описание
алгоритмов, общее описание работы ПС.
К программным документам отнесены также документы, обеспечивающие
функционирование и эксплуатацию программ – эксплуатационные документы:
ведомость эксплуатационных документов – содержит список
эксплуатационных документов на ПИ, к которым относятся формуляр,
описание применения, руководство системного программиста, руководство
программиста, руководство оператора, описание языка, руководство по
техническому обслуживанию;
формуляр – содержит основные характеристики ПИ, состав и
сведения об эксплуатации программы;
описание применения – содержит информацию о назначении и
области применения ПИ, ограничениях при применении, классе и методах
решаемых задач, конфигурации технических средств;
руководство системного программиста – содержит сведения для
проверки, настройки и функционирования программы при конкретном
применении;
руководство программиста – содержит сведения для эксплуатации
ПИ;
руководство оператора – содержит подробную информацию для
пользователя, обеспечивающую его общение с ЭВМ в процессе выполнения
ПИ;
описание языка – содержит синтаксис и семантику языка;
руководство по техническому обслуживанию – содержит сведения для
применения тестовых и диагностических программ при обслуживании
технических средств.
Необходимость составления остальных документов устанавливается при
разработке и утверждении технического задания (ТЗ).
Кроме формуляра и ведомости допускается объединять отдельные виды
эксплуатационных документов. Например, часто разрабатывают документ,
называемый «Руководство пользователя», в который включают различные
сведения из руководства системного программиста, руководства программиста и
оператора. «Руководство пользователя» должно учитывать все требования
инструкций, необходимых пользователю и содержать, как правило, общие
сведения о ПИ, описание установки и запуска, подробные инструкции по работе, т. е. описание режимов работы, форматов ввода-вывода информации,
различных настроек и другой необходимой информации для пользователя.
Большую роль для унификации при программировании играет стандарт
ГОСТ 19.701-90 (ИСО 5807-85) «Схемы алгоритмов, программ, данных и
систем», где приведены условные обозначения в схемах алгоритмов, программ,
данных и систем, устанавливаются правила выполнения схем для решения
различных задач. В этом стандарте описаны последовательности описания схем:
данных (отображают путь данных, этапы обработки, носители);
программы (отображают последовательность операций в программе);
работы системы (отображают управление операциями и поток
данных в системе);
взаимодействия программ (отображают путь активаций программ и
взаимодействий с соответствующими данными);
ресурсов системы (отображают конфигурацию блоков: данных и
обрабатывающих).
Виды программных документов и их содержание
Код Вид программного Содержание программного документа
документа
Спецификация
Состав программы и документации на нее
05 Ведомость
Перечень предприятий, на которых хранят подлинники
держателей
программных документов
подлинников
12 Текст программы
Запись программы с необходимыми комментариями
13 Описание
Сведения о логической структуре и функционировании
программы
программы
51 Программа и
Требования, подлежащие проверке при испытании программы, а
методика
также порядок и методы их контроля
испытаний
Техническое
Назначение и область применения программы, технические,
задание
технико-экономические и специальные требования,
предъявляемые к программе, необходимые стадии и сроки
разработки, виды испытаний
81 Пояснительная
Схема алгоритма, общее описание алгоритма и (или)
записка
функционирования программы, а также обоснование принятых
технических и технико-экономических решений
Эксплуатационные Сведения для обеспечения функционирования и эксплуатации
документы
программы
Виды эксплуатационных документов и их содержание
Код Вид
Содержание эксплуатационного документа
эксплуатационного
документа
20 Ведомость
Перечень эксплуатационных документов на программу
эксплуатационных
30
документов
Формуляр
31
Описание
применения
32
Руководство
системного
программиста
Руководство
программиста
Руководство
оператора
Описание языка
Руководство по
техническому
обслуживанию
33
34
35
46
Основные характеристики программы, комплектность и сведения
об эксплуатации программы
Сведения о назначении программы, области применения,
применяемых методах, классе решаемых задач, ограничениях для
применения, минимальной конфигурации технических средств
Сведения для проверки, обеспечения функционирования и
настройки программы на условия конкретного применения
Сведения для эксплуатации программы
Сведения для обеспечения процедуры общения оператора с
вычислительной системой в процессе выполнения программы
Описание синтаксиса и семантики языка
Сведения для применения тестовых и диагностических программ
при обслуживании технических средств
11.3 Стандартизация программных документов
Согласно ГОСТ 19.106-78* (Общие требования к программным
документам, выполненным печатным способом) общие правила для
печатного способа выполнения программных документов следующие:
1 Требования не распространяются на программный документ
«Текст программы».
2 Программный документ состоит из следующих условных носителей:
титульной;
информационной;
основной;
регистрации изменений
Информационная часть должна состоять из аннотации и содержания.
В аннотации приводят сведения о назначении документа и краткое
изложения его основной части.
Содержание включает перечень записей о структурных документах
основной части. Документа, в каждую из которых входят:
обозначение структурного элемента ( номер раздела. Подраздела и
т.п. );
наименование структурного элемента;
адрес структурного элемента на носителе данных (например,
номер страницы, номер файла и т.п.).
3 Программный документ выполняют на одной стороне листа, через
два интервала, допускается через один или полтора интервала.
Программные документы оформляют на листах формата А4 (ГОСТ
2.301-68) – при изготовлении документа машинописным или рукописным
способом. Допускается оформление на листах формата А3.
Рисунок 1
Материалы программного документа располагают в следующей
последовательности:
титульная часть:
o лист утверждения (не входит в общее количество листов
документа);
o титульный лист (первый лист документа);
информационная часть:
o аннотация;
o лист содержания;
основная часть:
o текст документа (с рисунками, таблицами и т.п.);
o приложения;
o перечень терминов, перечень сокращений, перечень
рисунков, перечень таблиц, предметный указатель,
перечень ссылочных документов;
часть регистрации изменений:
o лист регистрации изменений.
Аннотацию размещают на отдельной (пронумерованной) странице с
заголовком «АННОТАЦИЯ» и не нумеруют как раздел. В аннотации
указывают издание программы, кратко излагают назначение и содержание
документа. Если документ состоит из нескольких частей, в аннотации
указывают общее количество частей.
Содержание
документа
размещают
на
отдельной
(пронумерованной) странице (страницах) после аннотации, снабжают
заголовком «СОДЕРЖАНИЕ», не нумеруют как раздел и включают в общее
количество страниц документа.
Заголовки разделов пишут прописными буквами и размещают
симметрично относительно правой и левой границ текста. Заголовки
подразделов записывают с абзаца строчными буквами (кроме первой
прописной). Переносы слов в заголовках не допускаются. Точку в конце
заголовка не ставят. Расстояние между заголовком и последующим
текстом, а также между заголовками раздела и подраздела должно быть
равно двум интервалам.
Для разделов и подразделов, текст которых записывают на одной
странице с текстом предыдущего раздела, расстояние между последней
строкой текста и последующим заголовком должно быть равно трём
машинописным интервалам. Разделы, подразделы, пункты и подпункты
следует нумеровать арабскими цифрами с точкой. В пределах раздела
должна быть сквозная нумерация по всем подразделам, пунктам и
подпунктам, входящим в данный раздел. Нумерация подразделов включает
номер раздела и порядковый номер подраздела, входящего в данный раздел,
разделённые точкой (2.1; 3.1 и т. д.). При наличии разделов и подразделов к
номеру подраздела после точки добавляют порядковый номер пункта и
подпункта (3.1.1, 3.1.1.1 и т.д.). Пример структуры текста программного
документа и нумерации его разделов, подразделов, пунктов и подпунктов.
Рисунок 2
4 Текст документа должен быть кратким, четким, исключающим
возможность неверного толкования. Термины и определения должны быть
едиными и соответствовать установленным стандартам, а при их
отсутствии - общепринятым в научно-технической литературе, и
приводиться в перечне терминов. Необходимые пояснения к тексту
документа могут оформляться сносками. Сноска обозначается цифрой со
скобкой, вынесенными на уровень линии верхнего обреза шрифта, например:
«печатающее устройство2)...» или «бумага5)». Если сноска относится к
отдельному слову, знак сноски помещается непосредственно у этого слова,
если же к предложению целом, то в конце предложения. Текст сноски
располагают в конце страницы и отделяют от основного текста линией
длиной 3 см, проведённой в левой части страницы.
5 Иллюстрации, если их в данном документе более одной, нумеруют
арабскими цифрами в пределах всего документа.
6 Формулы в документе, если их более одной, нумеруются арабскими
цифрами, номер ставят с правой стороны страницы, в скобках на уровне
формулы. Значение символов и числовых коэффициентов, входящих в
формулу, должны быть приведены непосредственно под формулой. Значение
каждого символа печатают с новой строки в той последовательности, в
какой они приведены в формуле. Первая строка расшифровки должна
начинаться со слова «где», без двоеточия после него.
7 В программных документах допускаются ссылки на стандарты
(кроме стандартов предприятий), технические условия и другие документы
(например, документы органов Государственного надзора, правила и нормы
Госстроя СССР). При ссылках на стандарты и технические условия
указывают их обозначение. Ссылаться следует на документ в целом или на
его разделы (с указанием обозначения и наименования документа, номера и
наименования раздела или приложения). При повторных ссылках на раздел
или приложение указывают только номер.
8 В примечаниях к тексту и таблицам указывают только справочные
и пояснительные данные. Одно примечание не нумеруется. После слова
«Примечание» ставят точку. Несколько примечаний следует нумеровать по
порядку арабскими цифрами с точкой. После слова «Примечание» ставят
двоеточие.
9 Сокращения слов в тексте и надписях под иллюстрациями не
допускаются.
10 Иллюстрированный
материал,
таблицы
или
текст
вспомогательного характера допускается оформлять в виде приложений.
Каждое приложение должно начинаться с новой страницы с указанием в
правом верхнем углу слова «ПРИЛОЖЕНИЕ» и иметь тематический
заголовок, который записывают симметрично тексту прописными буквами.
12 Тестирование ПС
12.1 Аттестация ПС
При проведении аттестации комиссией экспертов (экспертом)
организации, проводящей аттестацию, составляется методика аттестации,
содержащая детальное описание всех действий, выполняемых в процессе
аттестации. При этом в методике аттестации должны быть предусмотрены
следующие основные этапы:
выбор методов испытаний (тестирования) в соответствии с целями
испытаний и степенью их жесткости составление тестовых заданий в
соответствии с требованиями к ПО и с указанием контролируемых
параметров и характеристик, исходных данных и критериев, которым должны
удовлетворять результаты, полученные тестируемым ПО – проведение
испытаний (тестирования) и получение результатов функционирования
испытываемого (тестируемого) ПО в соответствии с тестовыми заданиями;
обработка результатов испытаний (тестирования) (сравнение
результатов, полученных испытываемым (тестируемым) ПО, с эталонными).
Методика аттестации оформляется для каждого отдельного ПО СИ, с
учетом его назначения, функциональных особенностей и применяемых
методов испытаний (тестирования).
12.2 Испытания ПС
Испытания (тестирование) ПО при выбранной степени жесткости могут
проводиться на основе изучения документации, сопровождающей ПО,
испытаний (тестирования) с использованием аппаратных и программных
средств, а также на комплексной основе с использованием как документации,
так и аппаратных и программных средств.
По согласованию с разработчиком (заказчиком) устанавливается
последовательность испытаний ПО с учетом следующих этапов:
1. Проверка документации.
2. Проверка разделения ПО и наличия защищенных интерфейсов (с
использованием программных средств, в том числе на основе анализа
исходного кода).
3. Проверка соответствия утвержденному типу (идентификация) (на
основе анализа документации и с использованием программных средств, в
том числе на основе анализа исходного кода).
4. Испытание (тестирование) ПО с целью установления правильности
функционирования и определения его свойств и характеристик и
тестирование обработки данных (с использованием аппаратных и
программных средств, в том числе на основе анализа исходного кода).
5. Тестирование защищенности ПО и данных (с использованием
программных средств, в том числе на основе анализа исходного кода).
Примечание – Высокая жесткость испытаний с использованием
анализа исходного кода применяется в тех случаях, если разрабатывается
ПО сложных и измерительных систем, в том числе систем, используемых
при коммерческих расчетах, или если к таким системам предъявляются
исключительные требования по безопасности функционирования. В обычных
случаях ограничиваются низкой и средней степенью жесткости испытаний,
при которой тестирование ПО осуществляется методом «черного ящика».
Определяются методы испытаний в соответствии с установленной
жесткостью испытаний, которые должны найти отражение в тестовых
заданиях. Составляются тестовые задания с учетом того, что эти задания
и/или исходные данные для их формирования, а также методы их выполнения
должны обеспечить проверку всех основных режимов функционирования
испытываемого (тестируемого) ПО, а также его соответствие требованиям
нормативной документации.
Тестовые задания разрабатываются с учетом установленных видов
испытаний, руководства пользователя, а также другой необходимой
технической документации, представляемой на аттестацию. Каждому
требованию и/или контролируемой функции должно соответствовать не менее
одного тестового задания.
В тестовых заданиях определяются контролируемые свойства,
параметры и характеристики ПО, методы испытаний тестируемого ПО,
необходимые для этого исходные данные, программные продукты, с
которыми сравниваются результаты, получаемые в процессе испытаний
(эталонное ПО), а также критерии, позволяющие производить оценку
характеристик тестируемого ПО.
Описывается последовательность действий при проведении процедуры
испытаний (тестирования) в соответствии с установленной жесткостью
испытаний и перечнем разработанных тестовых заданий.
Результаты испытаний ПО признаются положительными, если:
программа
соответствует
функциональным
возможностям,
описанным в документации, и выполняет в рамках тестовых заданий все
функции, декларируемые в документации;
полученные значения параметров и характеристик программы при
выполнении всех тестовых заданий удовлетворяют установленным критериям
или находятся в допустимых пределах отклонений от них;
в программе реализованы необходимые методы защиты и
идентификации в соответствии с требованиями;
программная
документация
соответствует
требованиям
нормативных документов.
Если в процессе выполнения какого-либо из тестовых заданий
произойдет отказ программы, ее «зависание» или искажение результатов, то
данное тестовое задание может быть модифицировано для подтверждения
ошибки функционирования и повторено. Выявленные ошибки фиксируются в
протоколе испытаний.
По результатам испытаний ПО СИ составляется акт о результатах его
исследования (тестирования) неотъемлемой частью которого является
протокол испытаний, подписанный непосредственными исполнителями
испытаний (тестирования).
Дальнейшие разделы рекомендации конкретизируют виды испытаний
(тестирования).
Система сертификации программного обеспечения средств измерений и
информационно-измерительных систем Правила функционирования
12.3 Оценка ПС
Представление всей необходимой документации на аттестацию в
соответствии с требованиями рекомендации МИ 2891, а также стандартов
ГОСТ Р ИСО/МЭК 12119 и ГОСТ Р ИСО 9127, является необходимым
условием ее проведения. Рекомендуемые виды проверки документации
применяются при всех степенях жесткости испытаний.
В соответствии с требованиями указанных нормативных документов
проверяется наличие, достаточность и правильность представленной
документации. При этом проверяются следующие разделы документации:
Описание структуры ПО и последовательности обработки данных.
Структура ПО может быть представлена в виде одного или нескольких
взаимосвязанных модулей, реализующих функции ПО, с учетом разделения
ПО. Описание структуры ПО может быть осуществлено в графическом виде с
пояснениями и/или в текстовой форме. Описание каждого модуля ПО должно
включать:
наименование модуля;
функции, реализуемые модулем, и реализованные в модуле
алгоритмы;
данные, используемые и/или изменяемые модулем;
названия связанных (вызываемых) модулей.
Проверяется описание всех входных и выходных данных,
последовательность обработки входных данных в структуре ПО и других
программно-аппаратных компонентах системы. Данный раздел документации
должен содержать информацию о методе связи (интерфейсе) СИ и ПО, о
данных, получаемых от и передаваемых в СИ программным обеспечением,
описание всех аппаратных и программных компонент СИ, а также описание
исполняемых файлов (название, размер в мегабайтах).
Описание всех выполняемых функций и параметров ПО, с учетом
выделения частей, подлежащих метрологическому контролю (аттестации) с
внесением контролируемых функций и параметров в отдельный список.
Для всех функций ПО должны быть описаны входные и выходные
данные, а также результат выполнения.
Описание реализованных в ПО расчетных алгоритмов, а также их блоксхемы.
Должны быть приведены описания или логические схемы алгоритмов,
функции, реализуемые алгоритмами в ПО, а также все величины,
рассчитываемые с их помощью, и их формулы, данные о степени округления
при расчетах (точность алгоритмов).
Описание интерфейсов, меню, диалогов и перечень команд для каждого
интерфейса, включая заявление об их полноте, а также список, значение и
действие всех команд, получаемых от клавиатуры, мыши и других устройств
ввода.
Описание реализованного метода идентификации ПО. Проверяется
наличие информации о методе (алгоритме) идентификации ПО, способах
идентификации ПО в соответствии с реализованным методом, о системе
кодификации номера версии.
Описание реализованных методов защиты ПО и данных. Проверяется
описание реализованных методов (авторизация пользователя, журнал
событий, кодирование данных и т.д.) защиты ПО и данных от недопустимых
изменений и искажений, а также наличие сообщений об ошибках.
Примечания
Некоторые требования к документации в МИ 2891-04 охватывают
требования,приведенные в стандартах ГОСТ Р ИСО/МЭК 12119-2000, ГОСТ
Р ИСО 9127-94. Поэтому при проверке соответствия документации
указанным стандартам, проверяются те требования к документации ПО,
которые не регламентируются МИ 2891-04.2 Вся документация ПО
проверяется на однозначность понимания и непротиворечивость.
Все данные, в том числе выявленные несоответствия, полученные при
анализе документации ПО, заносятся в протоколы испытаний. Перечень
документов, сопровождающих ПО, объем и методы проверки документации
могут корректироваться соглашением между исполнителем и заказчиком
аттестации ПО.
Под проверкой структуры ПО понимается проверка правильности
выделения его частей, подлежащих метрологическому контролю (аттестации),
а также проверка наличия и правильности функционирования защищенных
интерфейсов.
Проверка правильности разделения ПО
Проверяются сведения о наличии защищенного интерфейса между
частями ПО, подлежащими и неподлежащими метрологическому контролю
(аттестации).
В случае отсутствия разделения, все ПО подлежит метрологическому
контролю (аттестации), однако документация должна содержать перечень
функций и параметров, относящихся к контролируемым.
Этот перечень функций и параметров также подлежит проверке.
По исходному коду ПО проверяется правильность реализации
защищенного интерфейса. Все модули, подпрограммы, процедуры, функции,
параметры, переменные и т.д., участвующие в обработке информации должны
быть охвачены защищенным интерфейсом.
Сведения о разделении ПО заносятся в протокол испытаний. По
результатам проверки может быть сделано замечание о неправильном
разделении ПО и дана рекомендация о соответствующих коррективах.
Проверка интерфейса ПО
Проверяется возможность недопустимого воздействия на ПО и данные
через интерфейс ПО (СИ).
С помощью программных средств выполняются все функции ПО,
подлежащие метрологическому контролю (аттестации), и определяется их
соответствие представленной документации. Исследуются меню, подменю,
диалоги ПО с целью выявления не соответствующих документации функций,
параметров и команд.
Проверяется фильтрация ввода данных через интерфейс и возможность
введения недопустимых данных.
При высокой жесткости испытания проводятся на основе анализа
исходного кода ПО. При этом:
выявляются недокументированные функции, процедуры, параметры,
переменные, команды и их использование в ПО;
проверяется соответствие действия вводимых команд (с помощью
диалогов, командной строки и т.д.) представленной документации.
Проверка соответствия
Под проверкой соответствия понимается проверка конкретного ПО на
соответствие тому типу, который был утвержден (зафиксирован) при его
аттестации, если такая аттестация ранее проводилась, а также проверка
методов и способов идентификации.
При низкой и средней жесткости испытаний проверка соответствия
утвержденному типу проводится на основе анализа представленной
документации, а также с использованием программных средств. При этом
может приниматься во внимание заявление заказчика аттестации об
отсутствии изменений и модификаций части ПО, подлежащей
метрологическому контролю (аттестации).
Проверка методов и способов идентификации программного
обеспечения
При низкой и средней жесткости испытаний методы и средства
идентификации ПО проверяются на основе документации и выполнения
функциональных испытаний (тестирования) ПО.
На основе документации проверяется описание реализованного метода
идентификации и способа работы с ним. В случае разделения ПО на
программном уровне устанавливается соответствие метода идентификации
принципу разделения ПО.
На основе анализа документации получают информацию обо всех
частях (модулях) ПО (с учетом его разделения), охватываемых
идентификацией. Все части ПО, подлежащие метрологическому контролю
(аттестации) должны быть охвачены алгоритмом идентификации.
Оценивается соответствие метода идентификации уровню требуемой
защиты.
Проверяется наличие номинального значения, идентифицирующего ПО
(номер версии, контрольная сумма и др.). Номинальное значение
идентификации ПО вносится в свидетельство об аттестации.
Проверяется функция идентификации ПО, например, выводом номера
версии на экран.
При высокой жесткости испытаний проводятся дополнительные
испытания на основе анализа исходного кода ПО. При этом устанавливается:
охват
идентификацией
всех
частей
ПО,
подлежащих
метрологическому контролю (аттестации), например, формирование
номинального закрепляемого значения идентификации;
охват
идентификацией
частей
ПО,
не
подлежащих
метрологическому контролю (аттестации);
соответствие метода идентификации представленной документации.
12.4 Виды испытаний ПО
Погрешность ПО представляет собой отличие результатов, полученных
с помощью испытываемого (тестируемого) ПО, от результатов, полученных
при тех же условиях эталонным ПО. При этом под эталонным понимается ПО,
отвечающее наивысшим требованиям к его точностным и функциональным
характеристикам, подтвержденным (в ряде случаев независимыми методами)
при его неоднократном тестировании.
Критерии отнесения ПО к эталонному условны и при проведении
аттестации ПО СИ являются предметом соглашения между заказчиками
аттестации и ее исполнителями. В качестве эталонного может быть
использовано аттестованное ПО.
К основным источниками погрешностей ПО относятся:
программные ошибки вследствие неправильной записи исходного
текста программы на выбранном языке программирования, а также ошибки
трансляции программы в объектный код;
алгоритмические ошибки, связанные с неполной или ошибочной
формулировкой необходимых условий решения;
применение неустойчивых алгоритмов при решении плохо
обусловленных* измерительных задач;
ошибки программного преобразования входных данных перед
обработкой и ошибки обратной процедуры, если она проводится;
ошибки округления и др.
Порядок проведения испытаний (тестирования) ПО определяется
тестовым заданием и может включать в себя:
анализ ПО и его алгоритмов, выбор контролируемых параметров,
характеристик и свойств;
определение методов испытаний (тестирования) в соответствии с
выбранной жесткостью испытаний;
определение критериев оценки погрешности, характеристик и
параметров ПО;
выбор (или разработка) эталонного ПО;
выбор (определение) исходных данных и/или их получение методом
генерации или какими-либо другими методами;
получение результатов u1086 обработки исходных данных в
испытываемом (тестируемом) ПО (получение тестовых результатов);
получение оценки погрешности ПО посредством обработки
результатов испытаний (тестирования) (сравнения тестовых результатов с
эталонными);
дополнительные исследования свойств, параметров и характеристик
используемых алгоритмов (адекватность измерительной задаче, область
устойчивости, время, затрачиваемое на обработку результатов измерений и
т.п.).
Основными методами, применяемыми при оценке погрешности ПО,
являются:
сравнительные
испытания
с
применением
эталонного
(аттестованного) ПО;
в отсутствие эталонного (аттестованного) ПО сравнительные
испытания с использованием моделей исходных данных или с применением
метода генерации эталонных данных;
испытания на основе исходного кода ПО, а также комбинации
указанных методов.
13 Сертификация ПС
13.1 Правовые акты по сертификации программных продуктов
Прежде всего, программист должен хорошо знать действующие в стране
законы, регламентирующие области работ, с которыми он соприкасается. Ему
должны быть хорошо известны основные положения следующих федеральных
законов:
1. «О сертификации продукции и услуг» от 27 апреля 1993 г. № 5151-1
(в ред. от 27 декабря 1995г. № 211-ФЗ; от 2 марта 1998 г. № 30-ФЗ; от 31 июля
1998 г. № 154-ФЗ);
2. «Об информации, информатизации и защите информации» от 20
февраля 1995 г. № 24-ФЗ;
3. «О правовой охране программ для электронных вычислительных
машин и баз данных» от 23 сентября 1992 г. № 3523-1;
4. «Об участии в международном информационном обмене» от 4 июля
1996 г. № 85-ФЗ;
5. «Об авторском праве и смежных правах» от 9 июля 1993 г. № 5351-1
(в ред. от 19 июля 1995 г. № 110-ФЗ).
В соответствии со первым законом «сертификация продукции (далее –
сертификация) – процедура подтверждения соответствия, посредством которой
независимая от изготовителя (продавца, исполнителя) и потребителя
(покупателя) организация удостоверяет в письменной форме, что продукция
соответствует установленным требованиям».
Сертификация осуществляется в целях:
содействия потребителям в компетентном выборе продукции;
зашиты потребителя от недобросовестности изготовителя (продавца,
исполнителя);
контроля безопасности продукции для окружающей среды, жизни,
здоровья и имущества;
подтверждения показателей качества продукции, заявленных
изготовителем.
Сертификация может иметь обязательный и добровольный характер».
Обязательная сертификация проводится в случаях, предусмотренных
законодательными актами РФ. Организация и проведение работ по
обязательной сертификации возложены на Госстандарт России и другие
федеральные органы исполнительной власти РФ.
Добровольная сертификация проводится по инициативе заявителей
(изготовителей, продавцов, исполнителей) для того, чтобы подтвердить
соответствие продукции требованиям стандартов, технических условий и
других документов, определяемых заявителем. Проводится она на условиях
договора между заявителем и органом по сертификации.
Во втором законе определены основные принципы разработки,
производства, сертификации и лицензирования информационных систем,
технологий и средств их обеспечения (а следовательно и ПО).
В третьем законе установлены многие основные понятия и определения
создания и использования программ. Например, программа для ЭВМ
определяется как «объективная форма представления совокупности данных и
команд, предназначенных для функционирования ЭВМ и других компьютерных
устройств с целью получения определенного результата, включая
подготовительные материалы, полученные в ходе разработки программы для
ЭВМ, и порождаемые ею аудиовизуальные отображения». База данных определяется как «объективная форма представления и организации совокупности
данных, систематизированных таким образом, чтобы эти данные могли быть
найдены и обработаны с помощью ЭВМ».
В четвёртом законе определен правовой режим участия в международном информационном обмене и установлены правила контроля и
ответственности при осуществлении международного информационного
обмена.
В пятом законе даны основные понятия авторского права, правила
использования и зашиты авторских произведений, в том числе программ для
ЭВМ. В ст. 25 этого закона «Свободное воспроизведение программ для ЭВМ
и баз данных. Декомпилирование программ для ЭВМ» описаны условия, при
которых можно использовать программу без получения разрешения автора
или иного обладателя прав на нее. Это только лица, правомерно владеющие
экземпляром программы для ЭВМ или БД. Ни при каких обстоятельствах не
должны быть ущемлены законные интересы автора или иного обладателя
исключительных прав на программу для ЭВМ или БД.
13.2 Сертификация ПС
Имеется два сертификационных документа: сертификат соответствия и
знак соответствия.
Сертификат соответствия – это документ, выданный по правилам
системы сертификации для подтверждения соответствия сертифицированной
продукции установленным требованиям.
Знак соответствия – это зарегистрированный в установленном порядке
знак, которым по правилам определенной системы сертификации
подтверждается соответствие маркированной им продукции установленным
требованиям
Система сертификации – совокупность участников сертификации,
которые проводят сертификацию продукции по устанавливаемым в этой
системе определенным правилам в соответствии с законом. Система
сертификации создается федеральными органами исполнительной власти.
Сертификация включает следующие этапы:
1) подача заявки на сертификацию;
2) рассмотрение и принятие решения по заявке;
3) проведение необходимых проверок (анализ документов, испытания,
проверка и т. п.);
4) анализ полученных результатов и принятие решения о возможности
выдачи сертификата соответствия;
5) выдача сертификата и лицензии (разрешения) на применение знака
соответствия;
6) инспекционный контроль за сертифицированным объектом в
соответствии со схемой сертификации.
Все данные, в том числе выявленные несоответствия, полученные при
анализе документации ПО, заносятся в протоколы испытаний. Перечень
документов, сопровождающих ПО, объем и методы проверки документации
могут корректироваться соглашением между исполнителем и заказчиком
аттестации ПО.
В соответствии со ст. 21 Федерального закона «О техническом
регулировании» орган по сертификации:
осуществляет подтверждение соответствия объектов добровольного
подтверждения соответствия, в том числе при необходимости создает или
привлекает на договорной основе испытательные лаборатории, в которых
организует проведение испытаний ПО (ПП) по согласованным с заказчиком
методикам;
выдает Сертификаты соответствия на объекты, прошедшие
добровольную сертификацию;
предоставляет заявителю право на применение знака соответствия;
приостанавливает или прекращает действие выданных им
Сертификатов соответствия.
Испытательные лаборатории выполняют следующие функции:
проводят испытания ПО (ПП) по согласованным с заказчиком
методикам;
оформляют результаты испытаний соответствующими протоколами,
на основании которых орган по сертификации принимает решение о выдаче
или об отказе в выдаче Сертификатов соответствия.
Схема сертификации – определенная совокупность действий, официально
принимаемая в качестве доказательства соответствия продукции заданным
требованиям.
При разработке методик сертификационных испытаний ПО (ПП)
СИИИС могут быть использованы ГОСТ Р 8. 596-2002 «ГСИ.
Метрологическое обеспечение измерительных систем. Общие положения», а
также рекомендации:
МИ 2955-2005. «ГСИ. Типовая методика аттестации программного
обеспечения средств измерений и порядок ее проведения»,
МИ 2174-91. «ГСИ. Аттестация алгоритмов и программ обработки
данных при измерениях. Основные положения»,
МИ 2517-99. «ГСИ. Метрологическая аттестация программного
обеспечения средств измерений параметров физических объектов и полей с
использованием компьютерных программ генерации цифровых тестовых
сигналов»,
МИ 2518-99. «ГСИ. Метрологическая аттестация алгоритмов и
программ генерации цифровых тестовых сигналов».
13.3 Перечень
характеристики
объектов,
подлежащих
сертификации
и
их
Объектами, подлежащими добровольной сертификации, являются:
программное обеспечение средств измерений как автономное, так и
встроенное;
программное обеспечение измерительных и информационноизмерительных систем;
программное обеспечение контроллеров и вычислительных блоков,
не входящих в состав информационно-измерительных систем.
Каждая позиция в перечне программного обеспечения (программных
продуктов), подаваемом заявителем для прохождения процедуры
добровольной сертификации, должна содержать следующую информацию:
описание структуры ПО (ПП) и выполняемых функций, в том числе
последовательность обработки данных;
описание функций и параметров ПО (ПП), подлежащих
метрологическому контролю (в соответствии с Рекомендацией МИ 28912004);
описание реализованных в ПО (ПП) расчетных алгоритмов, а также
их блок-схемы;
описание модулей ПО (ПП);
перечень интерфейсов и перечень команд для каждого интерфейса,
включая заявление об их полноте;
список, значение и действие всех команд, получаемых от
клавиатуры, мыши и других устройств ввода;
описание реализованной методики идентификации ПО (ПП);
описание реализованных методов защиты ПО (ПП) и данных;
описание интерфейсов пользователя, всех меню и диалогов;
описание хранимых или передаваемых наборов данных;
руководство пользователя;
характеристики требуемых системных и аппаратных средств, если
эта информация не приведена в руководстве пользователя.
Перечень
документов,
сопровождающих
ПО
(ПП),
может
корректироваться соглашением между исполнителем и заказчиком
сертификации ПО.
Графическая и текстовая информация в документации выполняется
таким образом, чтобы она была пригодна для полного и однозначного
понимания.
Характеристиками
ПО
СИИИС,
подлежащими
процедуре
добровольного подтверждения соответствия, являются характеристики,
являющиеся количественными или качественными представлениями
требований, предъявляемых к ПО (ПП) и устанавливаемых НД ПО, а именно:
а) требований к структуре, т.е. к выделению частей, подлежащих
метрологическому контролю, а также к наличию и правильности
функционирования защищенных интерфейсов;
б) требований к идентификации;
в) требований к защите измерительной и иной хранимой и
передаваемой информации;
г) требований к соответствию характеристик тем, которые были
установлены и приписаны ПО (ПП) при испытаниях СИ и других устройств с
целью утверждения типа;
д) требований к степени влияния на метрологические и
информационные характеристики средств измерений, информационноизмерительных систем.
Для подтверждения гарантий обеспечения соответствия ПО (ПП)
установленным СДС ПО СИИИС требованиям в любой период деятельности
заявителя в организации (фирме) должна быть организована документально
оформленная Система контроля ПО СИИИС.
13.4 Сертификационные испытания ПС
Для удостоверения качества, надежности и безопасности применение
сложных, критических ИС используемые в них ПС следует подвергать
обязательной сертификации аттестованными, проблемно-ориентированными
испытательными лаборатория»» Такие испытания необходимо проводить,
когда программы управляют сложными процессами или обрабатывают столь
важную информацию, что дефекты в них или недостаточное качество могут
нанести значительный ущерб. Сертификационные испытания должны
устанавливать соответствие комплексов программной документации и
допускать их к эксплуатации в пределах изменения параметров внешней
среды, исследованных при проведении проверках. Эти виды испытаний
характеризуются наибольшее строгостью и глубиной проверок и должны
проводиться специалистами, не зависимыми от разработчиков и заказчиков
(пользователей). Испытания ПС должны опираться на стандарты, формализованные методики и нормативные документы разных уровней.
Множество видов испытаний целесообразно упорядочивать и проводить
поэтапно в процессе разработки для сокращения затрат на завершающихся
сертификационных испытаниях.
Сертификация комплексов программ является их испытанием в наиболее
жестких условиях тестирования особым третейским коллективом
специалистов, имеющим право на официальный государственный или
ведомственный контроль функций и качеств ПС и гарантирующим их
соответствие стандартам и другим нормативным документам, а также
надежность и безопасность применения. Получение и обобщение результатов
испытаний, а также принятие решения о выдаче сертификата являются
прерогативой испытательных лабораторий. Они должны быть специализированными для проведения испытаний объектов определенных классов,
целенаправленно
и
систематически
работать
по
созданию
и
совершенствованию методик и средств автоматизации испытаний ПС
конкретного функционального назначения.
Специалисты–сертификаторы имеют право на расширение условий
испытаний и на создание различных критических и стрессовых ситуаций в
пределах нормативной документации, при которых должны обеспечиваться
заданное качество и надежность рвения предписанных задач. Если все
испытания проходят успешно, то на соответствующую версию ПС
оформляется специальный документ – сертификат соответствия. Этот
документ официально подтверждает соответствие стандартам, нормативен и
эксплуатационным документам функций и характеристик «пытанных
средств, а также допустимость их применения в определенной области.
Методология принятия решений о допустимости выдачи сертификата на
ПС определяется оценкой степени его соответствия действующим и/или
специально разработанным документам. В исходных нормативных
документах должны быть сосредоточены все функциональные и
эксплуатационные характеристики ПС, обеспечивающие заказчику и
пользователям возможность корректного применения сертифицированного
объекта во всем многообразии его функций и показателей качества. Выбор и
ранжирование показателей должны проводиться с учетом классов ПС, и
функционального назначения, режимов эксплуатации, степени критичности и
жесткости требований к результатам функционирования и проявлениям
возможных дефектов и ошибок. При этом могут привлекаться документы
предшествующих этапов испытаний и документы, подтверждающие
соблюдение аттестованных технологий при разработке программ на всех
этапах. Испытания ПС в конкретных проблемно-ориентированных системах
проводятся по правилам и методикам, принятым для соответствующих классов
критических информационных систем, например, Авиационных или
космических комплексов.
Работы по сертификации объединяются в технологический процесс, на
каждом этапе которого регистрируются документы, отражающие состояние и
качество результатов разработки ПС. В зависимости от характеристик
объекта сертификации на ее выполнение выделяются ресурсы различных
видов. В результате сложность программ, а также доступные для
сертификации ресурсы становятся косвенными критериями или факторами,
влияющими на выбор методов испытаний, а также на достигаемые качество
и надежность ПС.
Сертификационные испытания удостоверяют качество и надежность ПС
только в условиях, ограниченных конкретными стандартами и нормативными
документами, с некоторой конечно» вероятностью. В реальных условиях
эксплуатации принципиально возможны отклонения от характеристик
внешней среды функционирования ПС за пределы, ограниченные
сертификатом.
ситуации, не проверенные при сертификационных
испытания. Эти обстоятельства способны вызывать катастрофические послед-
ствия, угрожающие надежности функционирования и безопасности
применения ПС. Наличие сертификата у ПС для критически систем является
необходимым условием их допуска к эксплуатации. Однако любой сертификат
на сложные системы не может гарантировать абсолютную их надежность
применения, и всегда остается некоторый риск возникновения отказов.