Какая цель программного продукта

Вторым процессом начального этапа проектирования программных систем является разработка (постановка) и описание целей для создаваемой программной системы. При правильной постановке целей не делается никаких предположений о конкретной реализации, но указывается, каким образом на последующих этапах проектирования следует принимать компромиссные решения. Например, невероятно важно иметь в качестве целей конкретного проекта такую формулировку [11]: «Обеспечить максимальную надежность, эффективность, адаптируемость и безопасность системы, минимизируя стоимость и время разработки, требуемую память и время реакции терминала». Такого рода формулировки бессмысленны, поскольку многие из перечисленных факторов противоречат друг другу. Таким образом, назначение раздела проекта постановки целей программного продукта – не только сами цели, но и, если нужно, компромиссы между этими целями.

К общим ошибкам, совершаемым в процессе разработки и описания целей, относятся следующие:

• 1) цели не формулируются явно;
• 2) противоречивость в описании сформулированных целей (конфликт целей);
• 3) наличие поверхностно выявленных целей, не отражающих специфические особенности разрабатываемой программной системы;
• 4) цели программной системы с точки зрения пользователя (цели продукта) и цели проекта с точки зрения разработчика противоречивы.

Работы по созданию программной системы должны обеспечить выполнение двух различных множеств задач (целей): задач продукта разработки, определяющих его цели с точки зрения пользователя (цели продукта), и задач проекта, отображающих цели в рамках проекта (график выполнения работ, стоимость, степень тестирования, степень надежности и др.). В силу противоречивости целей ошибка, выражающаяся в отсутствии необходимого уровня достижения компромисса на системной основе, является достаточно распространенной. Для понимания путей нахождения компромисса между противоречивыми целями следует рассмотреть отношения между различными категориями компромиссов. Поскольку одной из важнейших задач разработки программных систем является достижение надежной работы системы, далее рассмотрим компромиссы между надежностью и другими наиболее важными требованиями.

• 1. Универсальность (общность) выступает в качестве меры количества, мощности и объема функций, запрашиваемых пользователем. Не следует ставить перед проектировщиком задачу достижения максимальной универсальности, необходимо представить ему перечень специфических функций применения продукта. Следует помнить, что универсальность и надежность работы ПС противоречат друг другу. Уже одно увеличение объема ПС при росте числа выполняемых функций приведет к росту числа ошибок при программировании. Поэтому каждая функция должна быть взвешена в смысле ее реальной пользы для потребителя и сопоставления с ее влиянием на надежность.
• 2. Человеческие факторы являются мерой легкости понимания результатов, легкости использования, защищенности от неправильного употребления и, как результат, частоты ошибок пользователя. Хотя интеллектуальность интерфейса пользователя может увеличить сложность системы и, таким образом, иметь отрицательное влияние на надежность, психологические факторы и надежность обычно не вступают в конфликт. Хороший учет психологических факторов позволяет свести к минимуму возможность неожиданных действий пользователя, что уменьшает возможность проявления скрытых ошибок в программном коде.
• 3. Адаптируемость ПС к различным условиям применения и классам пользователей является качественной мерой легкости использования и расширения за счет добавления новых функций. Адаптируемость и надежность в общем случае могут рассматриваться как совместимые. Более того, реализация мер по повышению надежности оказывает положительное влияние на адаптируемость и расширяемость системы в процессе ее сопровождения.
• 4. Удобство сопровождения характеризует меру затрат времени и средств на исправление ошибок в работающей системе. Это требование согласуется с требованиями надежности, поскольку оно тесно связано с адаптируемостью. Кроме того, такие методы обеспечения надежности, как обнаружение и изоляция ошибок, способствуют повышению надежности.
• 5. Безопасность определяется мерой вероятности того, что один пользователь может случайно или преднамеренно уничтожить данные, являющиеся собственностью другого пользователя, или препятствовать действию системы. Меры безопасности включают анализ ожидаемых угроз, тщательную взаимную изоляцию пользователей по данным и программам, обособление программ пользователей от операционной системы, разработку контрмер по противодействию проникновения в систему. Разработка и внедрение мер безопасности положительно сказывается на надежности.
• 6. Документация. Задачи документации связаны с количеством и качеством публикаций в интересах пользователей. Документация и человеческие факторы сходны в том, что они связаны с облегчением понимания и использования программной системы. В связи с этим решение проблем документирования не противоречит достижению заданного уровня надежности.
• 7. Стоимость программной системы включает затраты, связанные с созданием и сопровождением системы. Стоимость в значительной мере связана с количеством ошибок в программном продукте, а следовательно, с затратами на их исправление. Поэтому достижение высокой надежности и минимизация затрат на проектирование и разработку ПС в известной степени противоречат друг другу.
• 8. График работ. Одной из ключевых задач любого проекта является получение программного продукта к определенной дате. При этом предполагается, что экономический эффект продукта связан с датой его доступности. Многие из связей между надежностью и стоимостью также существенны и для графика работы и надежности. Одной из причин изменения графика работ является задача обеспечения заданной надежности. Например, имеет место тенденция недооценивать время, необходимое для тестирования. Фактическое время тестирования связано с числом ошибок, оставшихся в продукте. Отсюда задача довести до минимума время, затрачиваемое на разработку, и до максимума – надежность является совместимой при условии, что сроки не сокращены до такой крайности, когда на надлежащее проектирование просто не остается времени.
• 9. Эффективность (производительность). Связи между производительностью ПС и надежностью достаточно сложны. Многие приемы повышения надежности работы программ связаны с увеличением объема системы в числе таких команд, как, например, контроль и обработка исключений, контрольные точки, двойной (а иногда тройной) просчет и др. Это приводит к увеличению времени выполнения программ и росту объема необходимой памяти. С другой стороны, ненадежная программная система не может считаться эффективной независимо от того, как быстро она работает.

К этому надо добавить стремительный рост производительности компьютеров и их ресурсов, в том числе памяти, что ставит на первое место надежность работы ПС, так как именно ненадежность программ становится основной причиной, сдерживающей дальнейшее развитие информационных технологий во всех сферах деятельности человеческого общества. Практика отработки и сопровождения программных систем показывает, что неэффективность системы, если в этом есть необходимость, может быть исправлена позднее, в то время как ненадежность достаточно трудно устранить. Абсолютная надежность программных систем была и остается недостижимой целью.

В порядке обсуждения ниже автором предлагается подход, который может быть использован для выбора тех требований, предъявляемых к системе, которые наиболее совместимы с другими требованиями [14]. Для наглядности рассмотрения и анализа рассмотренных зависимостей между основными требованиями, предъявляемыми к программным системам, и установления оптимального компромисса между конфликтующими требованиями, можно построить матрицу оценки уровня совместимости (или конфликтности) требований конкретного проекта (рис. 4.9). Элементы /и,у матрицы М принимают конкретные значения в зависимости от совместимости требований:

• • т,у — 1, если г-е требование 7} полностью совместимо с требованием 7);
• • ш;у = 0,75, если г-е требование Г, скорее совместимо с требованием 7};
• • ш,у = 0,5, если г-е требование Г, частично совместимо с требованием 7};
• • ту – 0,25, если г-е требование 7) скорее несовместимо с требованием 7};
• • пу — 0, если г-е требование 7} несовместимо с требованием 7}.

Матрица совместимости строится экспертом (опытным высококвалифицированным разработчиком) следующим образом. Рассматривается г-я строка матрицы и, учитывая введенную шкалу совместимости, для каждого у-го требования 7} определяется, по мнению эксперта, значение ту, определяющее его совместимость с требованием Г,. Заметим, что матрица не является симметричной относительно диагонали. Это связано с тем, что, рассматривая некоторое требование 7} как основное, можно определить его совместимость с некоторым другим требованием 7} иначе, чем в том случае, когда требование 7} рассматривается как основное.

Сбалансированность требований можно оценить следующим образом. Если для каждой г-й строки матрицы получить сумму ее элементов, то значение этой суммы 7?, будет характеризовать степень (рейтинг) совместимости требований 7} (гдеу = 1, 2, …, п, у Ф г) с требованием 7), которое считается основным. Таким образом, для каждой строки матри-цы г = 1, 2, …, п находим значение:

к; = Е“=1ти ’ ) ф 1 (4-3)

С другой стороны, получив сумму для каждого столбца матрицы, найдем рейтинг совместимости требования Г, для тех случаев, когда оно не является основным. Рейтинг совместимости в этом случае определяется следующим образом: для каждого столбца матрицы/= 1, 2, …, п находим значение

(4.4)

Общее значение рейтинга совместимости Я- некоторого требования 7} можно определить, складывая соответствующие ему значения Я, и 7?/, т.е.

(4.5)

Я? – Я1 +Я , у – г.

У П А С Б Д Ст. Г Пр. Н Рейт.

Универсальность ^И0Д5 1 0,25 0,3 0,3 0,3 0,25 0,25 0 2,8 5,25

Псих, факторы 1 1 1 0,8 0,75 1 1 6,3 11,75

Адаптируемость 1 0Д5]^И0Д5 0,5 0,3 0,3 0,25 0,25 0,5 2,5 5,5

Сопровождаемость 0,3 1 1 Щ 1 1 0,3 0,25 0,25 1 5,8 9,75

Безопасность 0,3 1 0,3 0,3 0,5 0,5 1 4,8 10,25

Документация 0,3 1 0,8 1 1~ЩИ(^5 0,5 0,5 1 6,3 11

Стоимость 0,3 0,25 0,3 0,25 0,3 ТГ1Щ0Д5 0,25 0,3 2 4,75

График 0,3 0,25 0,3 0,25 0,3 0,3 оТ^ЩоД5 0,3 2 4,75

Производительность 0,3 0,5 0,3 0,5 0,5 0,5 0,3 ОД5|^Що^5 3,3 6,5

Надежность 0 1 0,3 0,5 1 0,5 0,3 0,25 0Д5^Н 4 9,5

Рис. 4.9. Матрица уровня совместимости

Проведенные вычисления для матрицы, изображенной на рис. 4.9, показывают, что наилучшую совместимость с другими рассмотренными выше требованиями имеют требования по психологическим факторам, документации, безопасности, сопровождаемости и надежности.