Файл: Инфрам.pdf

180 граммном продукте, а следовательно с затратами на их исправление.
Поэтому достижение высокой надежности и минимизация затрат на проектирование и разработку ПС в известной степени противоречивы.
8. График работ. Одной из ключевых задач любого проекта является получение программного продукта к определенной дате. При этом предполагается, что экономический эффект продукта связан с датой его доступности. Многие из связей между надежностью и стоимостью так- же существенны и для графика работы и надежности. Одной из причин изменения графика работ является задачи обеспечения заданной надеж- ности. Например. Имеет место тенденция недооценивать время, необхо- димое для тестирования. Фактическое время тестирования связано с числом ошибок, оставшихся в продукте. Отсюда задача довести до ми- нимума время, затрачиваемое на разработку, и до максимума надеж- ность является совместимой при условии, что сроки не сокращены до такой крайности, когда на надлежащее проектирование просто не оста- ется времени.
9. Эффективность (производительность). Связи между производи- тельностью ПС и надежностью достаточно сложны. Многие приемы повышения надежности работы программ связаны с увеличением объе- ма системы в числе команд, например, контроль и обработка исключе- ний, контрольные точки, двойной (а иногда, тройной) просчет и др. Это приводит к увеличению времени выполнения программ и росту объема необходимой памяти. С другой стороны, ненадежная программная сис- тема не может считаться эффективной независимо от того, как быстро она работает.
К этому надо добавить стремительный рост производительности компьютеров и их ресурсов, в том числе памяти, что ставит на первое место надежность работы ПС, так кА именно ненадежность программ становится основной причиной, сдерживающей дальнейшее развитие информационных технологий во всех сферах деятельности человеческо- го общества. Практика отработки и сопровождения программных сис- тем показывает, что неэффективность системы, если в этом есть необ- ходимость, может быть исправлена позднее, в то время как ненадеж- ность достаточно трудно устранить. Абсолютная надежность программ- ных систем была и остается недостижимой целью.
В порядке обсуждения ниже автором предлагается подход, который может быть использован для выбора тех требований, предъявляемых к системе, которые наиболее совместимы с другими требованиями [14].
Для наглядности рассмотрения и анализа рассмотренных зависимостей между основными требованиями, предъявляемыми к программным сис- темам, и установления оптимального компромисса между конфлик- тующими требованиями, можно построить матрицу оценки уровня со- вместимости (или конфликтности) требований конкретного проекта
(рис. 4.9). Элементы m ij матрицы M принимают конкретные значения в зависимости от совместимости требований:

181 m ij
= 1, если i – е требование T
i полностью совместимо с требовани- ем T
j
; m ij
= 0,75, если i – е требование T
i скорее совместимо с требованием
T
j
; m ij
= 0,5, если i – е требование T
i частично совместимо с требовани- ем T
j
; m ij
= 0,25, если i – е требование T
i скорее несовместимо с требова- нием T
j
; m ij
= 0, если i – е требование T
i несовместимо с требованием T
j
Матрица совместимости строится экспертом (опытным высококва- лифицированным разработчиком) следующим образом. Рассматривает- ся i-я строка матрицы и, учитывая введенную шкалу совместимости, для каждого j-го требования T
i определяется, по мнению эксперта, значение m ij
, определяющее его совместимость с требованием
T
i
. Заметим, что матрица не является симметричной относительно диагонали. Это связа- но с тем, что, рассматривая некоторое требование T
i как основное, мож- но определить его совместимость с некоторым другим требованием T
j иначе, чем в том случае, когда требование T
j рассматривается как ос- новное.
Рис. 4.9. Матрица уровня совместимости

182
Сбалансированность требований можно оценить следующим обра- зом. Если для каждой i-ой строки матрицы получить сумму ее элемен- тов, то значение этой суммы R
i будет характеризовать степень (рейтинг) совместимости требований T
j
(где j
= 1, 2,…, n, j ≠ i)
c требованием T
i
, которое считается основным. Таким образом, для каждой строки матри- цы i = 1, 2,…, n находим значение
R
i
= ∑ m ij
,
j
= 1, 2,…, n, j ≠ i.
С другой стороны, получив сумму для каждого столбца матрицы, найдем рейтинг совместимости требования T
i для тех случаев, когда оно не является основным. Рейтинг совместимости в этом случае опре- деляется следующим образом: для каждого столбца матрицы j = 1, 2,…, n находим значение
Общее значение рейтинга совместимости R
S i
некоторого требова- ния T
i можно определить, складывая соответствующие ему значения R
i и
R
j
, т.е.
Проведенные вычисления для матрицы, изображенной на рис. 9, по- казывают, что наилучшую совместимость с другими рассмотренными выше требованиями имеют требования по психологическим факторам, документации, безопасности, сопровождаемости и надежности.
4.9. Постановка целей для программной системы
При правильной постановки целей для программной системы не де- лается никаких предположений о конкретной реализации, но указывает- ся, каким образом на последующих этапах проектирования следует принимать компромиссные решения. Как отмечалось выше, должны быть поставлены цели двух типов: цели программного продукта и цели проекта.
4.9.1.
Цели продукта
Это цели сточки зрения пользователя системы. Они должны вклю- чать следующую информацию.
1. Резюме. Здесь кратко описывается общее назначение разрабаты- ваемого программного продукта и его функции.
2. Определение пользователя. Описывается круг возможных пользо- вателей системы. При множестве типов пользователей требуется опре- делить специфические особенности каждой группы пользователей.
3. Подробное описание функций. Подробное описание функций, ко- торые должны обеспечиваться системой. Это необходимо для того, что- бы гарантировать однозначное восприятие требований пользователей проектировщиками.

183 4. Публикации. Должны быть определены цели для документации, поставляемой пользователям, в том числе типы документации и пред- полагаемый круг читателей для каждого типа.
5. Эффективность. Данная категория объединяет все цели эффек- тивности (производительности), такие, как время реакции на действия пользователей, пропускная способность (число обрабатываемых тран- закций в единицу времени), использование ресурсов (загрузка процес- соров, памяти, каналов связи и т. п.), а также необходимые средства измерения производительности и средства настройки и оптимизации системы.
6. Совместимость. Если конкретный программный продукт должен быть совместимым с другими, эти цели указываются в этом разделе.
Следует также указать относящиеся к делу международные и государ- ственные стандарты и внутренние стандарты компании.
7. Конфигурации. Здесь указываются различные конфигурации аппа- ратуры и программного обеспечения, в которых система может работать
(компьютеры, операционная система, аппаратура связи др.), а также другие программные продукты (например, СУБД), от которых система зависит. Должны быть указаны дополнительные возможности выбора отдельных частей системы, если это предусматривается.
8. Безопасность. Сюда относится описание целей в отношении безо- пасности. Если система связана с финансовой деятельностью (напри- мер. банковская система, игорная система, система управления запаса- ми, учет материальных ценностей и т. п.) должны быть указаны средст- ва надзора. Если предусматривается обработка информации ограничен- ного использования (в системах государственного управления, военного назначения и т. п.), то требования к защите повышаются.
9. Обслуживание. Данная категория целей содержит сведения по за- тратам и времени на исправление ошибок, а также функции и средства для достижения этих целей, например, диагностические программы.
10. Установка. Сюда относятся методы и средства настройки систе- мы на конкретные условия эксплуатации.
11. Надежность. Цели в области надежности, как и другие цели, существенно зависят от конкретного типа системы. Следующие вопро- сы должны рассматриваться обязательно для каждого типа системы: a) для каждого типа отказов должно быть определено (задано) среднее время между отказами (отказ системы, ошибка пользователя, отказы конкретных функций) с учетом серьезности такого отказа; b) среднее время восстановления системы после отказа каждого типа; c) ориентиры в отношении числа ошибок в программной системе, рас- классифицированные по серьезности и времени обнаружения; d) последствия отказов системы или отказа наиболее важных функций; e) допустимый объем данных, утрачиваемых в случае отказа; f) жизненно важная информация, которая должна быть защищена от разрушения; g) функции, необходимые для обнаружения и исправления ошибок; h) функции, необходимые для обеспечения устойчивости к ошибкам;

184 i) возможности обнаруживать ошибки пользователя и сбои аппарату- ры, а также восстанавливать работоспособность.
4.9.2.
Цели проекта
Множество целей проекта – это цели, которые должны быть достиг- нуты в процессе проектирования. Для набора этих целей характерно то, что они непосредственно не проявляются в конечном продукте. Цели проекта должны быть формально установлены, так как противоречивые и непредусмотренные (неожиданные) результаты получаются тогда, когда проектировщики не работают над общей системой целей проекта.
Цели проекта должны содержать следующую основную информацию:
1) ориентировочную стоимость каждого процесса и стоимостные огра- ничения;
2) календарный план работы над проектом;
3) цели каждого процесса тестирования;
4) цели в области адаптируемости, указывающие степень адаптируемо- сти, или расширяемости, которая должна быть достигнута;
5) вопросы сопровождения создаваемой системы, которые необходимо учитывать при разработке;
6) уровни надежности, достигаемые после каждого этапа разработки
ПС для достижения заданной надежности продукта;
7) внутренняя документация при работе над проектом;
8) критерии для оценки готовности продукта к использованию.
Крайне важно, чтобы цели были четкими, ясными, разумными и из-
меряемыми. Цель, которую нельзя понять, бесполезна. Ни в коем случае нельзя скрывать цели от разработчиков программной системы; они должны быть известны все участникам проекта. Цели должны быть дос- тижимы – исследования классических проектов показали, что разверты- вание работ с недостижимыми целями часто являются главной причи- ной неудачи. Все цели должны быть сформулированы по возможности в количественных терминах, чтобы можно было оценить, в какой мере в окончательном продукте эти цели достигнуты.
Каждая цель должна быть сформулирована достаточно детально, чтобы могли осуществляться процессы проектирования, но не должна предполагать конкретного проектного решения. Должны быть опреде- лены зависимости между целями, чтобы в случае, когда изменяется или не может быть достигнута конкретная цель, проектировщик мог опре- делить, как это скажется на других целях. Для каждой цели должен быть установлен приоритет (например, по шкале от “абсолютно необхо- димо” до “хорошо, но не обязательно”), чтобы иметь основу для приня- тия компромиссных решений.
Очень полезный прием – перечислить в документации конкретные
“нецели” вместе с целями. Это предотвращает многие случаи ошибоч- ных “предположений” или “чтения между строк”, явно показывая, что рассматриваемая система не предполагает делать.

185
Разработанные цели проекта должны пройти оценку. Правило “n – плюс минус – один” предполагает привлечь к оценке целей автора тре- бований и проектировщика исходных внешних спецификаций. По- скольку, однако, цели – самый важный аспект проекта, необходимо уча- стие в их оценке дополнительных сил. К оценке должны быть привле- чены полномочные представители пользователей, а также те лица, кото- рые будут заниматься проектированием, тестированием, сопровождени- ем системы и подготовкой публикаций.
Первый шаг – сопоставление целей с требованиями, чтобы убедить- ся в том, что все требования правильно переведены на язык целей. Каж- дая цель должна оцениваться с учетом правил, изложенных выше. Так как этот вопрос очень важен, каждая из целей должна лично быть оце- нена представителями нескольких уровней руководства, как в организа- ции-пользователе, так и организации-разработчике.