книги / Надежность программного обеспечения систем обработки данных
..pdf5.1.ФОРМУЛИРОВКА ТРЕБОВАНИЙ
КСИСТЕМЕ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
Среди совокупности проектов программного обеспе чения можно условно выделить три группы: проекты, разработкой которых управляют пользователи; проекты, утверждаемые пользователями, и проекты, независимые от пользователей. Подобная классификация важна для определения ответственности за разработку требований
ксистеме ПО.
Впроектах, разработкой которых управляют пользо ватели, совокупность требований к системе ПО создается
иутверждается непосредственно организацией потреби теля, и они входят в качестве составной части договора иа разработку. Организация-проектировщик ПО высту
пает в данном случае как субподрядчик организациипотребителя. Так, большинство проектов систем ПО для правительственных организаций США относится именно к этой группе. Специальное правительственное агентство разрабатывает и утверждает требования к ПО, которые должны удовлетворяться фирмами-разработчи- ками.
Для проектов, утверждаемых организацией пользова телей, совокупность требований разрабатывается проек тировщиками или проектировщиками совместно с орга низацией потребителей. Право утверждения системных требований остается за организацией-потребителем. Утверждению также подлежат внешние спецификации проекта.
В проектах, не зависимых от пользователей, ответ ственность за разработку требований несет организацияпроектировщик ПО. Для качественного выполнения работ на начальной стадии проектирования целесообразно при влекать для обсуждения системных требований пользова телей с учетом специфики проекта.
Целью сформулированных системных требований яв ляется отражение потребностей пользователей в конкрет ном программном обеспечении. Наиболее полное отраже ние потребностей можно предположить в проекте, утверж даемом пользователем. Наиболее благоприятные резуль таты может дать совместная работа над требованиями потенциальных пользователей и проектировщиков ПО. В проекте, где проработка требований производится поль зователем, проблемой является то, что проектировщики ПО не привлекаются к выработке требований, а это может
Ю *
послужить увеличению возможности ошибочной интерпре тации или неправильного их понимания.
В общем случае разработку системных требований выполняет группа пользователей и проектировщиков, ре шающих следующие задачи:
1) выявление наличия информации, необходимой для выполнения планируемых функций;
2)выработка заключения по трудоемкости предстоя щей работы;
3)обеспечение полноты и точности определения функ ций, подлежащих выполнению системой ПО, и их взаимо
связей.
Требования для систем ПО среднего и большого раз мера должны разрабатываться небольшой группой лиц, например по два представителя от пользователей и про ектировщиков. Пользователи должны быть представлены ведущим специалистом, наделенным правом принятия окончательных решений, и специалистом, являющимся "непосредственным пользователем проектируемой системы ПО Проектировщики должны быть представлены спе циалистом, который будет играть ведущую роль во внеш нем проектировании системы ПО, и лицом, которое будет в последующем участвовать в одном из внутренних про цессов проектирования. Подобный подход к формирова нию группы гарантирует, что системные требования поль зователя были установлены по возможности более точно при условии, что проектировщики смогут перевести эти требования в систему ПО с минимальным числом ошибок.
Анализ требований. Единственной важной функцией анализа требований является определение проблемы Пра вильное решение этого вопроса привело бы к полному и непротиворечивому набору требований. Требования долж ны однозначно определять конечный продукт разработки и метод разработки, но не подход к проектированию. Это противоречие лежит в используемом языке, иа кото ром представляются методы разработки, а не в подходе к проектированию, что является главной причиной труд ностей разработки хорошего набора требований.
Требования служат также для описания общих целей всех участников разработки проекта. Язык требований должен иметь такие семантические качества,, которые лучшим образом взаимосвязывают всех участников раз работки проекта, даже если между ними имеются разно гласия по конкретным путям разработки.
Требования анализируются иа протяжении всего вре-
102
меня разработки проекта. Анализ можно разбить на три шага. Первым шагом является набор требований, осно ванный на определенных начальных условиях. Этот шаг — важнейший из трех и самый сложный. Второй шаг соот ветствует последовательному распределению требований по более низким уровням иерархии системы с возрастаю щей детализацией. Именно на этом этапе возникают де тализированные требования к ПО. Когда начинается процесс разработки, то исходя из реальных соображений разработки, кодирования и тестирования происходит ите ративная модификация требований, идущая в направле нии «снизу вверх». Единственной причиной плохой раз работки систем программного обеспечения является не умелая реализация первых двух шагов анализа требо ваний.
Когда анализ требований проводится плохо, то возни кают следующие основные проблемы:
1) разработка методом «сверху вниз» становится не возможной;
2)тестирование становится невозможным;
3)из разработки исключается пользователь;
4)управленце теряет силу контроля (суть заключа
ется в |
небрежном подходе к |
анализу требований). |
Все |
это — результаты слабого |
управления. Хорошее |
управление разработкой ПО невозможно без каких-либо направляющих требований.
Если установленные требования туманны, то перед разработчиками возникает множество вопросов. Для наи более эффективного использования труда разработчиков необходимо разбить процесс разработки на части, коли чество которых равно количеству разработчиков. Если это не будет сделано формально, то разбиение произой дет само по себе. Каждый разработчик, приступая к перво начальной или конечной разработке, будет принимать сотни решений, основанных на его узком восприятии собственной части разработки. Наконец, когда отдельные части разработки стыкуются некоторыми грубыми мето дами стыковки, то в результате получается разработка, возникшая на основе синтеза методом «снизу вверх». Возможно, при наличии достаточных средств и времени с помощью насильственной реализации некоторых напи санных требований подобную разработку методом «снизу вверх» и можно будет довести до рабочего состояния. Однако часто это бывает сделать очень сложно.
Синтезированное методом «снизу вверх» программное
103
обеспечение неизбежно становится неэффективным по следующим причинам: имеет место высокая степень не направленной работы, приводящей к снижению продук тивности; определенные функции дублируются (перекры вающаяся разработка); отсутствие необходимых функ ций остается необнаруженным вплоть до завершающих шагов разработки (недостаточность разработки).
Еще одним следствием плохого определения требова ний является то, что персонал, проводящий тестирова ние, должен' будет перед началом тестирования сам вы полнить анализ требований. Было бы значительно лучше проводить анализ требований, используя системных аналитиков, чем впоследствии для этой цели исполь зовать специалистов по тестированию.
Анализ требований тесно связан с управлением раз работкой ПО, так как набор обоснованных требований является средством управления разработкой программно го обеспечения. Без правильного набора требований управление разработкой сталкивается со следующими объективными препятствиями:
перерасход первоначальных средств и времени явля ется неуправляемым, так как необходимые средства и время являются результатом личной оценки разработчи ков по мере разработки проекта, которая неизбежно бывает оптимистической. Если разработчик должен будет отчитываться о том, как он выполняет требования, то при этом возможно получение объективных оценок;
пользователь исключается из процесса разработки набора требований. Он может только наблюдать за про цессом и воспринимать то, что ему будет говорить разра ботчик о содержимом системы. Пользователь во многом зависит от разработчика, который по ряду вопросов мо жет оказаться некомпетентным, что и приведет его к не правильным решениям.
Результатом неправильного предсказания возможно сти разрабатываемого ПО, как правило, является то, что на завершающих стадиях разработки многое прихо дится делать заново. Приходится прибегать к средствам, далеким от лучших практикуемых, а в результате непред полагаемые последствия приводят к гибели всей системы.
Этого можно избежать, если пользователь будет иметь’доступ к понятному ему набору требований и пре образовывать их по собственному желанию. Он заинтере сован в этом в наибольшей степени, так как в случае оши бочной разработки страдать от этого больше всех при дется ему.
!<Ч
И наконец, набор требований — это язык, с помощью которого взаимодействуют все участники разработки на предмехластвження сомютення. по принципиальным кон-, структивным решениям.
Скоординированный набор требований — это лучшее средство взаимоувязки ожидаемых разработчиками и пользователями возможностей будущей системы. Язык требований является достаточно детализированным для предварительной оценки стоимости и времени разработ ки и достаточно общим для выбора лучшего, подхода к разработке. Без набора, требований достижение соглаше ния между разработчиками и пользователями является проблематичным.
Так как отсутствие анализа требований совершенно очевидно пряводогг к неудаче, то возникает вопрос: почему он не всегда проводится? Анализ требований — это очень сложная работа. Аналитическая деятельность включает рассудительность, интуицию, способность к обобщению, эвристический подход. Очень редко имеется воамежность дедуктивного или математического подтверждения.
Многие инженеры характеризуют эту работу как неве щественную. Если им предоставить выбор, то они подой дут к разработке на основе принципов, строго обоснован ных физическими науками и математическими законами, а не на основе анализа требований, и именно поэтому они неизбежно Поведут разработку методом «снизу вверх».
Другая причина, заставляющая людей отказаться от анализа требований, заключается в том, что это не является необходимым шагом. Действительно, необходимыми являются только разработка и ее продукт. Подобно тести рованию. которое включается только благодаря тому, что люди делают ошибки, анализ требований включается по тому, что он является средством установления целей» дня'достижения которых все будут работать.
Если бы разработчик*' были достаточно опытны и подготовлены, то для них не требовалось бы установления направления разработки и осуществления контроля над ними. Применение подобных аргументов к сложным сис темам ПО является абсурдным. На практике если человек пропускает формулировку требований й начинает разра ботку, то сначала возникает кратковременное чувство удивительно быстрого, успешного Продвижения работы, а кончается-серьезным разочарованием, за которым сле дует переработка готового продукта ГЮ.
Существуют две возможнеетн-улучшшшя ПО. Одна —
Ю5
количественная оценка процесса, другая — тестирование требований перед началом разработки.
Другая цроблема заключается в том, чтобы требова ния были последовательными н чтобы они поэтапно реали зовывалась в разработке. Для этого необходима согласо ванность действий.
Анализ требований главным ооразом имеет отношение К взаимодействию пяти элементов: стоимости, времени, полноты, методов реализации и риска реализации. Вза имодействия между этими пятью элементами образуют систему, в которой каждый параметр функционально за висит от других.
Проверка требований. Возможность тестирования тре бований на всех стадиях разработки является необхо димым условием их подтверждения. Преобладающим под ходом подтверждения является моделирование системы с' учетом ее основных операционных характеристик. С целью моделирования система подвергается экспери ментальному тестированию с использованием строгого диапазона представления параметров, которые получают ся на основе различных наборов требований. Если резуль таты моделирования достаточно достоверны, то аналитик сможет сразу увидеть операционные последствия входных требований и точно выбрать лучший их набор для управ ления системой. Существуют пять подходов к проверке требований: количественное вычисление, моделирование известным способом, новое моделирование, разработка прототипов и двойной счет.
Количественное вычисление — самый дешевый и наи менее надежный метод. Его обычно используют в край нем случае. Разница между методами моделирования важна потому, что применение специально созданного для данной системы метода моделирования ведет к сни жению стоимостных и временных затрат. Однако при не достатке средств и времени используются уже разрабо танные методы моделирования. Улучшение качества про верки может быть достигнуто определением критических проблем разработки и созданием их прототипов.
Процесс разработки требований включает анализ су ществующих систем, опрос потребителей, исследование осуществимости и предварительный расчет эффективно сти разрабатываемой системы ПО. Методика проведения Зтих работ не отличается от общепринятой для больших систем. Методы проверки корректности требований к системе ПО пока еще находятся на начальной стадии раз
ню
вития. Ответственным за полноту и точность сформули рованных требований к системе ПО является пользов?- тель, проектировщик же отвечает за качество описания требований и их реализуемость.
При описании требований рекомендуется ранжировать их в порядке важности реализации, с тем чтобы указать проектировщику последовательность выполнения при не обходимости принятия компромиссных решений в процессе проектирования.
В заключение перечислим средства, повышающие значение анализа требований.
1. Должно существовать автоматическое средство ана лиза полноты, постоянства, распределения и просмотра набора требований. Технология проста и представляет со бой набор операций 'по сортировке и выдаче списков, однако ею не всегда пользуются. Причина кроется в пло хом представлении требований, а именно в многословии. Такой формат трудно преобразовать в машинный. Кро ме того, перекрывающиеся или совместно использующие ся требования отдельно не выделяются. Все это не являет ся очень сложным, однако не всегда автоматизируется.
2.Требуются улучшенные методы выбора требований. Необходимы модели взаимодействия стоимости, времени, риска с системными параметрами, управляющими разра боткой. Для таких моделей необходима улучшенная входная информация.
3.Необходимы разработанные методы моделирования, которые после небольшой переделки можно использовать для конкретной проблемы. Необходимо создание обоб щенного метода моделирования.
4.Для моделирования необходим эффективный язык моделирования.
Перечисленные средства не автоматизируют анализ требований, они только совершенствуют работу по ана лизу. Анализ требований — это процесс, основанный на интуиции, на предвидении успеха. Важнейшей функцией управления является обеспечение проведения анализа требований в качестве первого шага разработки. Игнори рование этого требования является самой частой причи ной разработки неудачных проектов ПО.
5.2. ОПИСАНИЕ ЦЕЛЕЙ
Вторым процессом начального этапа проектирования систем ПО являются разработка и описание целей. Характерная особенность этого процесса в том, что его
107
продукт является результатом компромиссов. Например, невероятно иметь в качестве целей конкретного проекта такие, как доводить до максимума надежность, эффек тивность, универсальность, адаптируемость и безопас ность системы ПО при сведении к минимуму величины стоимости системы, времени ее разработки и реализа ции. Выполнение этих целей не реально, так как они про тиворечат друг другу. Таким образом, основной задачей обсуждаемого процесса будет установление взаимно согласованных целей разработки системы ПО.
К общим ошибкам, совершаемым в процессе разра ботки и описания целей, относятся следующие:
противоречивость в описании сформулированных це лей,
наличие поверхностно выявленных целей, не отражаю щих специфических особенностей разрабатываемого ПО, цели создания системы ПО с точки зрения пользовате ля (цели продукта) и цели проекта с точки зрения проек
тировщика противоречивы.
Работы по созданию систем ПО должны обеспечи вать выполнение двух различных множеств задач (целей). задач продукта разработки, определяющих его цели с точки зрения пользователя, и задач проекта, отображаю щих цели в рамках проекта (график выполнения работ, стоимость, степень тестирования, степень надежности
ит. д.).
Всилу противоречивости целей ошибка, выражаю
щаяся в отсутствии необходимого уровня достижения компромисса на системной основе, является достаточно распространенной В общем случае цели разработки ПО могут быть сгруппированы в десять достаточно самостоя тельных категорий, одной из которых является надеж ность Для понимания путей нахождения компромисса между противоречивыми целями важно знать отношения между ними. Основным предметом рассмотрения явля ется надежность, и поэтому обсудим отношения между надежностью и девятью другими категориями.
Универсальность. Универсальность выступает в каче стве меры количества, мощности и объема функций, запрашиваемых пользователем. Не следует ставить перед проектировщиком задачу достижения максимальной уни версальности, необходимо представить ему перечень спе цифических функций применения продукта
Универсальность и надежность противоречат друг другу, так как уже одно то, что объем программы, удовлет
108
воряющей требованию универсальности, будет больше, накладывает ограничение на надежность Попытка раз решения этого противоречия не может и не должна ре шаться по пути узкой специализации проектируемого ПО. Решать проблему целесообразно путем избежания обоб щений результатов, которые не помогают пользователю. Например, некоторые компиляторы включают большое количество возможных для использования режимов ра боты. Однако в практических целях используется только небольшая часть режимов Это обстоятельство может послужить дополнительным источником ошибок.
Противоречие между универсальностью и надежно стью ПО является наиболее трудно решаемым компро миссом. Необходимо помнить, что даже небольшой эле мент интерфейса пользователя оказывает определенное отрицательное влияние на надежность. Каждая функция. ПО должна быть взвешена в терминах ее реальной поль зы для потребителя в сопоставлении с ее влиянием на надежность
Человеческие факторы. Эти факторы являются мерой легкости понимания результатов, легкости использования, трудности неправильного употребления и получаемых ошибок пользователей. Хотя «очеловечивание» интерфей са пользователя может увеличить сложность системы и, таким образом, иметь отрицательное влияние на надеж ность, человеческие факторы и задачи достижения на дежности обычно не вступают в конфликт Многие из скрытых ошибок в действующих системах возникают, когда внезапно создаются новые условия как результат непредвиденных действий пользователя
Продуманные и реализованные человеческие факторы сводят к минимуму возможности непредвиденных дейст вий пользователя, уменьшая тем самым возможность столкновения с любыми скрытыми ошибками.
Адаптируемость. Адаптируемость ПО к различным условиям применения и классам пользователей является качественной мерой легкости использования и расшире ния за счет добавления новых функций Адаптируемость И надежность ПО в общем случае могут рассматриваться как совместимые Реализация мер по повышению надеж ности оказывает положительное влияние на адапти руемость и расширяемость системы в процессе сопро вождения.
С о п р о в о ж д е н и е . Сопровождение ПО представляет со бой меру стоимости и времени, необходимых для обна-
10»
руженкя и исправление ошибок ПО в действующей систе ме. Сопровождение и надежность совместимы и взаимосвязаны, так как обнаружение и изоляция ошибок спо собствуют повышению надежности.
Безопасность. Безопасность определяется мерой веро ятности того, что одни пользователь системы может случайно или преднамеренно обратиться или уничтожить данные, являющиеся собственностью другого пользова теля, илн препятствовать действию системы. Меры безо пасности включают анализ ожидаемых угроз, тщатель ную взаимную изоляцию пользователей по данным и программам, обособление программ пользователей от опе рационной системы, разработку контрмер по противо действию проникновения в систему. Разработка и внедре ние мер безопасности положительно сказываются на на дежности.
Документация. Задачи документации связаны с коли чеством и качеством публикаций в интересах пользова теля. Документация и человеческие факторы сходны в Трм, что оии связаны с облегчением понимания и исполь зования ПО. В связи с этим решение проблем докумен тации не противоречит достижению заданного уровня надежности.
Стоимость ПО. Стоимость ПО включает расходы, связанные с его созданием и сопровождением. В гл. 4 было показано, что стоимость ПО в значительной мере связана с большим количеством ошибок. Этим обстоя тельством подчеркивается, что достижение высокой на дежности и минимизация затрат иа проектирование и разработку ПО в известной мере противоречивы
График работ. Одной из ключевых задач любого про екта является получение продукта разработки к опреде ленной дате. При этом предполагается, что экономичес кий эффект продукта связан с датой его доступности. Многие из связей между надежностью и стоимостью ПО также существенны и для графика работы и надежности. Одной из основных причин изменения графиков работ яв ляются задачи обеспечения заданной надежности. Напри мер, имеет место тенденция недооценивать время, необ ходимое для тестирования. Однако фактическое время тестирования тесно связано с числом ошибок ПО, остав шихся в продукте Отсюда задача получения приемлемой надежности в ограниченное время может быть достигнута при условии, что выделенного времени достаточно для проектирования.