ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 06.11.2023
Просмотров: 825
Скачиваний: 6
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
163 крементальная разработка и подтверждающие концепцию прототипы позволяют проверить осуществимость требования.
4. Необходимость. Каждое требование должно отражать возмож- ность, которая действительно необходима пользователям или которая нужна для соответствия внешним системным требованиям или стандар- там. Кроме того, требование должно исходить от лица, которое имеет полномочия на запись положения. Необходимо отследить каждое тре- бование вплоть до стадии сбора мнений пользователей, когда выявля- лись варианты использования, бизнес-правила или другие источники.
5. Назначение приоритетов. Каждому функциональному требова- нию, характеристике или варианту использования необходимо назна- чить приоритеты, чтобы определить, что нужно для каждой версии про- дукта. Если все положения одинаково важны, менеджеру проекта будет трудно справиться с уменьшением бюджета, нарушением сроков, поте- рей персонала или добавлением новых требований в процессе разработ- ки.
6. Однозначность. Все читатели требований должны интерпретиро- вать их одинаково, но естественный язык зачастую грешит многознач- ностью. Документация должна быть написана просто, кратко и точно, лексика должна быть понятна пользователям. Ясность – цель качества требований, связанная с точностью: читатели должны четко понимать каждое положение.
7. Проверяемость. Если требование не проверяется, вопрос его кор- ректной реализации становится предметом заключения, а не целью ана- лиза. Неполные, несогласованные, невыполнимые или двусмысленные требования также не проверяются.
В 80-х – 90-х годах 20 века для описания функциональных требова- ний широко использовался полуформальный метод HIPO-диаграмм (Hi- erarchy plus Input – Process - Output): иерархия плюс ввод – обработка – вывод [11, 12]. HIPO-диаграмма строится для каждой основной требуе- мой функции. В ней дается обобщенная характеристика входных и вы- ходных данных для этой функции и основных шагов обработки. Для отображения иерархической организации таких функций строится ог- лавление.
При использовании этого метода диаграммы обычно готовит органи- зация-разработчик, а затем предъявляет их пользователю для проверки.
Задача HIPO-диаграмм – дать пользователю наглядное представление о будущем продукте в надежде услышать от него: “Да, я хотел, чтобы программа делала именно это”. Важно понимать, что HIPO-диаграммы, также как и диаграммы вариантов использования, отображают в основ- ном функциональные требования. Другие требования должны быть описаны отдельно.
4.4.4.
Определение нефункциональных (эксплуатационных) требований
164
Варианты использования системы охватывают часть нефункцио- нальных требований, специфичных для конкретного варианта использо- вания. Однако большая часть нефункциональных требований не может быть привязана к конкретному варианту использования системы. Такие требования должны быть вынесены в отдельный список дополнитель- ных требований к системе.
Нефункциональные (эксплуатационные) требования определяют ха- рактеристики программной системы, проявляемые в процессе ее ис- пользования. К таким характеристикам относятся: правильность, т.е. функционирование программной системы в соот- ветствии с техническим заданием. Никакое тестирование не дает
100% гарантии правильности, поэтому может идти речь об опреде- лении вероятности наличия ошибок; обеспечение правильности работы при любых допустимых данных и защиты от неправильных данных; надежность и помехозащищенность – обеспечение полной повто- ряемости результатов, т.е. обеспечение их правильности при нали- чии различного рода сбоев и отказов технических и программных средств системы в целом, а также неправильных действий людей, работающих с этими средствами; проверяемость – возможность проверки получаемых результатов
(например, путем фиксации исходных данных, режимов работы и другой информации, которая влияет на результаты); точность результатов – обеспечение погрешности результатов не выше заданной; защищенность (безопасность) – обеспечение конфиденциальности информации; программная совместимость – возможность совместного функцио- нирования с другим программным обеспечением (в основном связа- но с работой ПС под управлением заданной операционной системы, но, может быть, с обменом данными с другой программной систе- мой); аппаратная совместимость - возможность совместной работы с определенным оборудованием. Это требование может быть сформу- лировано в форме минимально возможной конфигурации оборудо- вания, на котором будет работать программная систем (например, объем памяти, тип процессора и др.); эффективность (производительность), например время ответа тер- минала, пропускная способность (некоторое количество полных ра- бот, выполняемых за определенный период времени), время обра- ботки сообщения и др.; адаптивность – возможность быстрой модификации с целью при- способления к изменяющимся условиям функционирования; повторная входимость – возможность повторного выполнения без перезагрузки с диска (требование, обычно предъявляемое к рези- дентным программа, например, драйверам);
165 реентерабельность – возможность параллельного использования несколькими процессами (для удовлетворения этого требования ре- ентерабельная программа должна создавать копию изменяемых дан- ных для каждого процесса).
1 ... 10 11 12 13 14 15 16 17 ... 37
4.5. Анализ и управление требованиями
Требования склонны к проблемам двусмысленности, неполноты, и несогласованности. Их устранение на этапе разработки требований сто- ит на несколько порядков меньше, чем устранение этих те же проблемы на поздних стадиях разработки. Анализ требований направлен на реше- ние данных проблем. Единственной важной функцией анализа требова- ний является выявление таких проблем. Правильное решение этого во- проса привело бы к полному и непротиворечивому набору требований.
Требования должны однозначно определять конечный продукт разра- ботки и методы разработки, но не подход к проектированию. Это про- тиворечие лежит в используемом языке, на котором представляются методы разработки, а не в подходе к проектированию, что является главной причиной трудности разработки хорошего набора требований.
Требования служат для описания общих целей всех участников раз- работки проекта. Язык требований должен иметь такие семантические качества, которые лучшим образом взаимосвязывают всех участников проекта, даже если между ними имеются разногласия по конкретным путям разработки. Пожалуй, одним из таких языков в настоящее время является язык UML [7].
Требования анализируются на протяжении всего времени разработки проекта. Анализ можно разбить на три шага. Первым шагом является набор требований, основанный на определенных начальных условиях.
Этот шаг наиважнейший из трех и самый сложный. Второй шаг соот- ветствует последовательному распределению требований по более низ- шим уровням иерархии системы с возрастающей детализацией. Именно на этом шаге возникают детализированные требования к ПС. И, нако- нец, когда начинается процесс разработки, то исходя из реальных сооб- ражений разработки, кодирования и тестирования происходит итера- тивная модификация требований, идущая в направлении снизу вверх.
Одной из причин плохой разработки систем программного обеспе- чения является неумелая реализация двух первых шагов анализа требо- ваний. При этом могут возникнуть следующие проблемы [11]: декомпозиция архитектуры системы на подсистемы (компоненты) и разработка многоуровневой (послойной) архитектуры на основе концепций уровней абстракции и метода проектирования сверху вниз станет невозможной; тестирование становится невозможным; из разработки исключается пользователь (заказчик); управление теряет силу контроля.
166
Все это результат слабого управления. Хорошее управление разра- боткой ПС невозможно без каких-либо направляющих требований. Если установленные требования туманны, то перед разработчиком возникает множество вопросов. Для эффективного использования труда разработ- чиков необходимо разбить процесс разработки на части. Если этого не сделать формально, разбиение произойдет само собой. Каждый разра- ботчик, приступая к первоначальной или конечной разработке, будет принимать массу решений, основанных на его узком собственном вос- приятии собственной части разработки. Наконец, когда отдельные части разработки стыкуются некоторыми методами, то в результате получает- ся разработка, возникшая на основе синтеза снизу вверх.
Возможно, при наличии достаточных средств и времени с помощью насильственной реализации некоторых написанных требований подоб- ную разработку и можно будет довести до рабочего состояния, однако это бывает сделать очень сложно. Синтезированная методом снизу вверх программная система неизбежно становится неэффективной по следующим причинам: имеет место высокая степень ненаправленной работы, приводящей к снижению продуктивности; определенные функции дублируются (перекрывающаяся разработ- ка); отсутствие необходимых функций остается необнаруженным вплоть до завершающих шагов разработки (недостаточность разработки).
Еще одним последствием плохого определения требований является то, что персонал, проводящий тестирование, должен будет перед нача- лом тестирования сам выполнить анализ требований. Было бы значи- тельно лучше проводить анализ требований, используя системных ана- литиков, чем впоследствии для этой цели использовать специалистов по тестированию.
Анализ требований тесно связан с управлением разработкой ПС, так как набор обоснованных требований является средством управления разработкой программной системы. Без правильного набора требований управление разработкой сталкивается со следующими объективными препятствиями [22]: перерасход первоначальных средств и времени является неуправ- ляемым, так как необходимые средства и время являются результа- том личной оценки разработчиков по мере продвижения проекта, ко- торая неизбежно бывает оптимистической. Если разработчик должен будет отчитываться в том, как он выполняет требования, то при этом возможно получение объективных оценок; пользователь исключается из процесса разработки набора требова- ний. Он может только наблюдать за процессом и воспринимать то что ему будет говорить разработчик о содержимом системы. Пользо- ватель во многом зависит от разработчика, который по ряду вопро- сов может оказаться некомпетентным, что и приведет его к непра- вильным решениям.
167
Результатом неправильного предсказания возможностей разрабаты- ваемой системы, как правило, является то, что на завершающих этапах приходится многое делать заново. Этого можно избежать, если пользо- ватель будет иметь доступ к понятному ему набору требований и пре- образовывать их по собственному желанию. Он заинтересован в этом в наибольшей степени, так как в случае ошибочной разработки страдать от этого больше всех придется ему.
Скоординированный набор требований – лучшее средство взаимо- увязки ожидаемых разработчиками и пользователями возможностей будущей системы. Язык требований является достаточно детализиро- ванным для предварительной оценки стоимости и времени разработки и достаточно общим для выбора лучшего подхода к разработке. Без набо- ра требований достижение согласия между разработчиками и пользова- телями является проблематичным.
Для эффективного управления требованиями необходимо: проанализировать проблему. Сформулировать ее совместно с заин- тересованными лицами. Определить границы в рамках, которых ре- шается проблема, и ограничения, накладываемые на ее решение; определить потребности заинтересованных лиц. Результатом опре- деления потребностей заинтересованных лиц является описание их потребностей в различной форме; описать систему. Результатом описания является ее описание на ес- тественном языке и в графике с использованием моделей; управлять проектом. Определить ресурсы для управления (время, люди, финансы); управлять изменяющимися требованиями. Управление требования- ми включает отслеживание истории изменений требований, установ- ление связей между требованиями, поддержку различных версий требований.
Не секрет, что заказчик может поменять требования по тем или иным причинам. Для проекта важно оценить, какие требования влияют на это требование, и как данное требование влияет на другие. После того, как требования определены и одобрены, изменения должны под- падать под контроль внесения изменений. Для многих проектов требо- вания изменяются до завершения создания системы. Это происходит частично из-за сложности программного обеспечения и того факта, что пользователи не знают что им нужно на самом деле. Эта особенность требований привела к появлению управления требованиями.
Инструментальное средство IBM Rational Requisite Pro [1] позволяет очень легко получить матрицу, в которой видно, как повлечет за собой изменение того или иного требования. Прослеживаемость или, по- другому, трассируемость (traceability) требований является возможно- стью проследить связь между требованиями различных типов.
Целями прослеживания связей между требованиями и элементами проекта являются: определение источников требований;