Затонский А.В. Пособие по полному жизненному циклу информационных систем
Подождите немного. Документ загружается.
161
этих требований составляет содержание дальнейшей работы коллектива
разработчиков.
Руководитель
Пользователь
Руководитель
Разработчик
договор
должностная
инструкция
распоряжение
Предприятие-заказчик Предприятие-исполнитель
потребности
требования
требования
согласование
Рис. 21. Основные стороны-составители внешнего описания
Неправильное понимание требований заказчиком, пользователями и
разработчиками связано обычно с различными взглядами на роль требуемого
ПС в среде его использования [36]. Поэтому важной задачей при создании
определения требований является установление контекста использования ПС,
включающего связи между этим ПС, аппаратурой и людьми. Лучше всего этот
контекст в определении требований представить в графической форме (в виде
диаграмм) с добавлением описаний сущностей используемых объектов (блоков
ПС, компонент аппаратуры, персонала и т.п.) и характеристики связей между
ними.
Известны три способа разработки определения требований к ПС:
• управляемая пользователем разработка,
• контролируемая пользователем разработка,
• независимая от пользователя разработка.
В управляемой пользователем разработке определения требований к ПС
определяются заказчиком, представляющим организацию пользователей. Это
происходит обычно в тех случаях, когда организация пользователей (заказчик)
162
заключает договор на разработку требуемого ПС с коллективом разработчиков
и требования к ПС являются частью этого договора. Роль разработчика ПС в
создании этих требований сводится, в основном, в выяснении того, насколько
понятны ему эти требования с соответствующей критикой рассматриваемого
документа. Это может приводить к созданию нескольких редакций этого
документа в процессе заключения указанного договора.
В контролируемой пользователем разработке требования к ПС
формулируются разработчиком при участии представителя пользователей. Роль
пользователя в этом случае сводится к информированию разработчика о своих
потребностях в ПС, а также к контролю того, чтобы формулируемые
требования действительно выражали его потребности в ПС. Разработанные
требования, как правило, утверждаются представителем пользователя.
В независимой от пользователя разработке требования к ПС определяются
без какого-либо участия пользователя (на полную ответственность
разработчика). Это происходит обычно тогда, когда разработчик решает
создать ПС широкого применения в расчете на то, разработанное им ПС найдет
спрос на рынке программных средств.
С точки зрения обеспечения надежности ПС наиболее предпочтительным
является контролируемая пользователем разработка.
Качество и сертификация информационных систем
Дефектологические свойства ИС и ПС
В зависимости от целей исследования и этапов жизненного цикла ИС
дефектологические свойства разделяют на дефектогенность, дефектабельность
и дефектоскопичность [18].
Дефектогенность определяется влиянием следующих факторов:
• численностью разработчиков ИС, их профессиональными и
психофизиологическими характеристиками;
• условиями и организацией процесса разработки ИС;
• характеристиками инструментальных средств и компонент ИС;
• сложностью задач, решаемых ИС;
• степенью агрессивности внешней среды (потенциальной возможностью
внешней среды вносить преднамеренные дефекты, например, воздействие
вирусов).
Дефектабельность характеризует наличие дефектов ИС и определяется их
количеством и местонахождением. Другими факторами, влияющими на
дефектабельность являются:
• структурно-конструктивные особенности ИС;
• интенсивность и характеристики ошибок, приводящих к дефектам.
Дефектоскопичность характеризует возможность проявления дефектов в
виде отказов и сбоев в процессе отладки, испытаний или эксплуатации. На
дефектоскопичность влияют:
• количество, типы и характер распределения дефектов в ИС;
163
• устойчивость ИС к проявлению дефектов;
• характеристики средств контроля и диагностики дефектов;
• квалификация обслуживающего персонала ИС.
Иерархическая модель качества ИС
В настоящее время наибольшее распространение получила иерархическая
модель взаимосвязи компонент качества ИС. Вначале определяются
характеристики качества, в числе которых. могут быть, например, общая
полезность, исходная полезность, удобство эксплуатации. Далее формируются
показатели, к числу которых могут быть отнесены: практичность, целостность,
корректность, удобство обслуживания, оцениваемость, гибкость,
адаптируемость, мобильность, возможность взаимодействия. Каждому
показателю качества ставится в соотвествие группа критериев. Надо отметить,
что один и тот же критерий может характеризовать несколько показателей:
• практичность – работоспособность, возможность обучения,
коммуникативность, объем ввода, скорость ввода-вывода;
• целостность – регулирование доступа, контроль доступа;
• эффективность – эффективность использования памяти, эффективность
функционирования;
• корректность – трассируемость, завершенность, согласованность;
• надежность — точность, устойчивость к ошибкам, согласованность,
простота;
• удобство обслуживания – согласованность, простота, краткость,
информативность, модульность;
• оцениваемость – простота, наличие измерительных средств,
информативность, модульность;
• гибкость – распространяемость, общность, информатированность,
модульность;
• адаптируемость – общность, информативность, модульность, аппаратная
независимость, программная независимость;
• мобильность – информативность, модульность, аппаратная
независимость, программную независимость;
• возможность взаимодействия – модульность, унифицируемость
процедур связи, унифицируемость данных.
С помощью метрик можно дать количественную или качественную оценку
качества ИС. Различают следующие виды метрик и шкал для измерения
критериев [Советов].
Первый тип – метрики, которые используют интервальную шкалу,
характеризуемую относительными величинами или реально измеряемыми
физическими показателями, например, временем наработки на отказ,
вероятностью ошибки, объемом информации и др.
Второй тип – метрики, которым соответствует порядковая шкала,
позволяющая ранжировать характеристики путем сравнения с опорными
значениями.
164
Третий тип – метрики, которым соответствуют номинальная или'
категорированная шкала, определяющая наличие рассматриваемого свойства
или признака у рассматриваемого объекта без учета градаций по этому
признаку. Так, например, интерфейс может быть «простым для понимания»,
«умеренно простым», «сложным для понимания».
Развитием иерархического подхода является представленная на рис. 22
модель классификации критериев качества информационных систем. С
помощью функциональных критериев оценивается степень выполнения ИС
основных целей или задач. Конструктивные критерии предназначены для
оценки компонент ИС, не зависящих от целевого назначения.
Рис. 22. Модель классификации критериев качества информационных систем
Одним из путей обеспечения качества ИС является сертификация. В США
«Сертификация – процесс официального утверждения государственным
полномочным органом ... выполняемой функции системы ... путем
удостоверения, что функция ... удовлетворяет всем требованиям заказчика, а
также государственным нормативным документам». К сожалению, в настоящее
время не существует стандартов, полностью удовлетворяющих оценке качества
ИС. В западно-европейских странах имеется ряд стандартов, определяющих
основы сертификации программных систем. Стандарт Великобритании
описывает структурные построения программных систем, при соблюдении
которых может быть получен документ, гарантирующий качество на
государственном уровне. Имеется международный аналог указанного стандарта
и аналог для стран членов НАТО. Существующая в нашей стране система
нормативно-технических документов относит программное обеспечение к
«продукции производственно-технического назначения», которая
рассматривается как материальный объект. Однако программное обеспечение
165
является скорее абстрактной нематериальной сферой. Существующие ГОСТы
(например, ГОСТ 28195 — 89. «Оценка качества программных средств. Общие
положения») явно устарели и являются неполными.
Спецификация качества программного средства
Разработка спецификации качества сводится, по существу, к построению
своеобразной модели качества требуемого ПС [68]. В этой модели должен быть
перечень всех тех достаточно элементарных свойств, которые необходимо
обеспечить в требуемом ПС и которые в совокупности образуют приемлемое
для пользователя качество ПС. При этом каждое из этих свойств должно быть в
достаточной степени конкретизировано с учетом определения требований к ПС
и возможности оценки его наличия у разработанного ПС или необходимой
степени обладания им этим ПС.
Для конкретизации качества ПС по каждому из критериев используется
стандартизованный набор достаточно простых свойств ПС, однозначно
интерпретируемых разработчиками [20], которые называются примитивами
качества ПС. Некоторые из примитивов могут использоваться по нескольким
критериям. Ниже приводится зависимость критериев качества от примитивов
качества ПС.
Функциональность: завершенность.
Надежность: завершенность, точность, автономность, устойчивость,
защищенность.
Легкость применения: П-документированность, информативность (только
применительно к документации по применению), коммуникабельность,
устойчивость, защищенность.
Эффективность: временнáя эффективность, эффективность по ресурсам
(по памяти), эффективность по устройствам.
Сопровождаемость. С данным критерием связано много различных
примитивов качества. Однако их можно распределить по двум группам,
выделив два подкритерия качества: изучаемость и модифицируемость.
Изучаемость − это характеристики ПС, которые позволяют минимизировать
усилия по изучению и пониманию программ и документации ПС.
Модифицируемость − это характеристики ПС, которые позволяют
автоматически настраивать на условия применения ПС или упрощают внесение
в него вручную необходимых изменений и доработок.
Изучаемость: С-документированность, информативность (здесь
применительно к документации по сопровождению), понятность,
структурированность, удобочитаемость.
Модифицируемость: расширяемость, модифицируемость (в узком
смысле, как примитив качества), структурированность, модульность.
Мобильность: независимость от устройств, автономность,
структурированность, модульность.
Ниже даются определения используемых примитивов качества ПС.
166
Завершенность (completeness) − свойство, характеризующее степень
обладания ПС всеми необходимыми частями и чертами, требующимися для
выполнения своих явных и неявных функций.
Точность (accuracy) − мера, характеризующая приемлемость величины
погрешности в выдаваемых программами ПС результатах с точки зрения
предполагаемого их использования.
Автономность (self-containedness) − свойство, характеризующее
способность ПС выполнять предписанные функции без помощи или поддержки
других компонент программного обеспечения.
Устойчивость (robustness) − свойство, характеризующее способность ПС
продолжать корректное функционирование, несмотря на задание неправильных
(ошибочных) входных данных.
Защищенность (defensiveness) − свойство, характеризующее способность
ПС противостоять преднамеренным или нечаянным деструктивным
(разрушающим) действиям пользователя.
П-документированность (u. documentation) − свойство, характеризующее
наличие, полноту, понятность, доступность и наглядность учебной,
инструктивной и справочной документации, необходимой для применения ПС.
Информативность (accountability) − свойство, характеризующее наличие в
составе ПС информации, необходимой и достаточной для понимания
назначения ПС, принятых предположений, существующих ограничений,
входных данных и результатов работы отдельных компонент, а также текущего
состояния программ в процессе их функционирования.
Коммуникабельность (communicativeness) − свойство, характеризующее
степень, в которой ПС облегчает задание или описание входных данных, и
способность выдавать полезные сведения в достаточно простой форме и с
простым для понимания содержанием.
Временнa5я эффективность (time efficiency) − мера, характеризующая
способность ПС выполнять возложенные на него функции в течение
определенного отрезка времени.
Эффективность по ресурсам (resource efficiency) − мера, характеризующая
способность ПС выполнять возложенные на него функции при определенных
ограничениях на используемые ресурсы (используемую память).
Эффективность по устройствам (device efficiency) − мера,
характеризующая экономичность использования устройств машины для
решения поставленной задачи.
С-документировапнность (documentation) − свойство, характеризующее с
точки зрения наличия документации, отражающей требования к ПС и
результаты различных этапов разработки данного ПС, включающие
возможности, ограничения и другие черты ПС, а также их обоснование.
Понятность (understandability) − свойство, характеризующее степень, в
которой ПС позволяет изучающему его лицу понять его назначение, сделанные
допущения и ограничения, входные данные и результаты работы его программ,
тексты этих программ и состояние их реализации. Этот примитив качества
167
синтезирован нами из таких примитивов ИСО, как согласованность,
самодокументированность, четкость и, собственно, понятность (текстов
программ).
Структурированность (structuredness) − свойство, характеризующее
программы ПС с точки зрения организации взаимосвязанных их частей в
единое целое определенным образом (например, в соответствии с принципами
структурного программирования).
Удобочитаемость (readability) − свойство, характеризующее легкость
восприятия текста программ ПС (отступы, фрагментация, форматированность).
Расширяемость (augmentability) − свойство, характеризующее способность
ПС к использованию большего объема памяти для хранения данных или
расширению функциональных возможностей отдельных компонент.
Модифицируемость (modifiability) − мера, характеризующая ПС с точки
зрения простоты внесения необходимых изменений и доработок на всех этапах
и стадиях жизненного цикла ПС.
Модульность (modularity) − свойство, характеризующее ПС с точки зрения
организации его программ из таких дискретных компонент, что изменение
одной из них оказывает минимальное воздействие на другие компоненты.
Независимость от устройств (device independence) − свойство,
характеризующее способность ПС работать на разнообразном аппаратном
обеспечении (различных типах, марках, моделях компьютеров).
Функциональное моделирование предметной области
Разновидности функциональных моделей предметной области
При создании функциональной модели исследуемой системы приходится
выбирать одну из трех доминирующих методологий [33]:
• Data Flow Diagrams (DFD) – диаграммы потоков данных
• Structured Analysis and Design Technique (SADT) – методика построения
активностных моделей. Примером практической реализации SADT
является стандарт IDEF0 построения функциональных моделей разных
уровней детализации.
• Integrated computer automated manufacturing DEFinition (IDEF3) – методика
документирования процессов, происходящих в системе.
Полное описание этих методологий выходит за рамки курса. Однако на
практике приходится выбирать, какую функциональную модель использовать, в
связи с чем необходимо знать сравнительные достоинства и недостатки
упомянутых подходов к моделированию.
Метод функционального моделирования SADT (IDEF0)
Метод SADT (Structured Analysis and Design Technique) считается
классическим методом процессного подхода к управлению [44]. Основной
принцип процессного подхода заключается в структурировании деятельности
организации в соответствии с ее бизнес-процессами, а не организационно-
168
штатной структурой. Именно бизнес-процессы, формирующие значимый для
потребителя результат, представляют ценность, и именно их улучшением
предстоит в дальнейшем заниматься. Модель, основанная на организационно-
штатной структуре, может продемонстрировать лишь хаос, царящий в
организации (о котором в принципе руководству и так известно, иначе оно бы
не инициировало соответствующие работы), на ее основе можно только внести
предложения об изменении этой структуры. С другой стороны, модель,
основанная на бизнес-процессах, содержит в себе и организационно-штатную
структуру предприятия.
В соответствии с этим принципом бизнес-модель должна выглядеть
следующим образом:
1. Верхний уровень модели должен отражать только контекст системы —
взаимодействие моделируемого единственным контекстным процессом
предприятия с внешним миром.
2. На втором уровне модели должны быть отражены основные виды
деятельности (тематически сгруппированные бизнес-процессы)
предприятия и их взаимосвязи. В случае большого их количества
некоторые из них можно вынести на третий уровень модели. Но в любом
случае под виды деятельности необходимо отводить не более двух
уровней модели.
3. Дальнейшая детализация бизнес-процессов осуществляется посредством
бизнес-функций — совокупностей операций, сгруппированных по
определенным признакам. Бизнес-функции детализируются с помощью
элементарных бизнес-операций.
4. Описание элементарной бизнес-операции осуществляется посредством
задания алгоритма ее выполнения.
Метод SADT реализован в одном из стандартов этого семейства — IDEF0,
который был утвержден в качестве федерального стандарта США в 1993 г., его
подробные спецификации можно найти на сайте http://www.idef.com.
Существует также российская версия данного стандарта. Вместе со стандартом
IDEF0 обычно используются стандарт моделирования процессов IDEF3 и
стандарт моделирования данных IDEF1Х.
Метод SADT представляет собой совокупность правил и процедур,
предназначенных для построения функциональной модели объекта какой-либо
предметной области. Функциональная модель SADT отображает
функциональную структуру объекта, т.е. производимые им действия и связи
между этими действиями. Основные элементы этого метода основываются на
следующих концепциях:
•
Графическое представление блочного моделирования. Графика блоков и
дуг SADT-диаграммы отображает функцию в виде блока, а интерфейсы
входа/выхода представляются дугами, соответственно входящими в блок
и выходящими из него. Взаимодействие блоков друг с другом
описывается посредством интерфейсных дуг, выражающих
«ограничения», которые, в свою очередь, определяют когда и каким
образом функции выполняются и управляются.
169
•
Строгость и точность. Выполнение правил SADT требует достаточной
строгости и точности, не накладывая в то же время чрезмерных
ограничений на действия аналитика. Правила SADT включают:
ограничение количества блоков на каждом уровне декомпозиции
(правило 3-6 блоков — ограничение мощности краткосрочной памяти
человека), связность диаграмм (номера блоков), уникальность меток и
наименований (отсутствие повторяющихся имен), синтаксические
правила для графики (блоков и дуг), разделение входов и управлений
(правило определения роли данных).
•
Отделение организации от функции, т.е. исключение влияния
административной структуры организации на функциональную модель.
Метод SADT может использоваться для моделирования самых
разнообразных процессов и систем. В существующих системах метод SADT
может быть использован для анализа функций, выполняемых системой, и
указания механизмов, посредством которых они осуществляются.
Состав функциональной модели
Результатом применения метода SADT является модель, которая состоит
из диаграмм, фрагментов текстов и глоссария, имеющих ссылки друг на друга
[33].
Вход
Выход
Управление
Механизм
00р.
Функция
Рис. 23. Функциональный блок и интерфейсные дуги
Диаграммы – главные компоненты модели, все функции организации и
интерфейсы на них представлены как блоки и дуги соответственно. Место
соединения дуги с блоком определяет тип интерфейса. Управляющая
информация входит в блок сверху, в то время как входная информация, которая
подвергается обработке, показана с левой стороны блока, а результаты (выход)
170
показаны с правой стороны. Механизм (человек или автоматизированная
система), который осуществляет операцию, представляется дугой, входящей в
блок снизу (рис. 23).Одной из наиболее важных особенностей метода SADT
является постепенное введение все больших уровней детализации по мере
создания диаграмм, отображающих модель.
На рис. 24, где приведены четыре диаграммы и их взаимосвязи, показана
структура SADT-модели. Каждый компонент модели может быть
декомпозирован на другой диаграмме. Каждая диаграмма иллюстрирует
«внутреннее строение» блока на родительской диаграмме.
Управление
Механизм
Вход 1
Выход
Вход 2
Вход 3-1
Управление 2-3
Выход 3-4
10р.
Процесс 1
20р.
Процесс 2
30р.
Процесс 3
40р.
Процесс 4
Механизм
Управление 2-3
Вход 3-1
Выход 3-4
Вход 2
10р.
Процесс 3-1
20р.
Процесс 3-2
30р.
Процесс 3-3
Рис. 24. Декомпозиция диаграмм
Построение SADT-модели заключается в выполнении следующих
действий: