Управление масштабом и модели процесса разработки ПО 1. Модель водопада [Выявление требований] +--->[Проектирование] +--->[Кодирование и тестирование модулей] +--->[Сборка системы] | +-->[Тестирование системы] Масштаб +-->[Сопровождение] ] ] Если к этой модели определить масштаб, который оказался перезаказанным на 200%, то получатся такие результаты: ^ 2. Спиральная модель | 1) План требований, план ЖУ /|\ 2) Анализ рисков / | \ 3) Создание прототипа /5/|\ \ 4) Тестирование и уточнение требований / /1|2\ \ 5) План разработки -----+------------------ 6) Функциональный прототип \ 4|3 / /6 7) Кодирование \ | / /7 8) Тестирование системы \ |/ /8 9) Проверка работоспособности \| /9 10) Внедрение |/10 3. Итеративный подход (технология RUP) +-----------v [Анализ требований] | [ ] . v | v . [Проектирование] | [ ] . v | v | [Кодирование] | [ ] | v | v | [Тестирование и интеграция] | [ ] | +--------------------+ +---------+ Преимущества: 1) последовательное уточнение требований и снижение их вариаций; 2) легче управлять масштабом: если в первой итерации процент невыполнения составил 30% или более, то можно сделать вывод, что масштаб проекта задан неправильно и его следует сокращать. Требования к программному обеспечению Принципы определения требований к ПО Ранее мы занимались анализом проблемы, выделением потребностей пользователей, сбором и документированием желаемых функций продукта. На данном этапе необходимо уточнить спецификации до уровня детализации, пригодной для выполнения проектирования, написания программного кода и тестирования. Ранее намеренно давали определение функций на высоком уровне абстракции. Это было удобно для выполнения следующих действий: понимание формы системы: сосредоточив внимание на её функциях и на том, как они выполняют требования пользователя; оценки полноты и целостности системы, а также её соответствию среде; определение возможности построения системы и управления её масштабом перед тем, как будут произведены значительные инвестиции. Требования к ПО - это то, что данная программа делает для пользователя, устройства или другой системы. Рекомендуют начинать с того, что входит и что выходит из системы. В этом плане предложено рассматривать 5 основных категорий элементов: 1) вводы системы: содержимое ввода, устройства и протокол (форма, внешний вид, структура); 2) выводы системы: нужно описать поддерживаемые устройства вывода, а также протокол и форматы генерируемой системой информации; 3) функции системы: здесь должно быть отображение вводов в выводы и их различные комбинации; 4) атрибуты системы: типичные поведенческие требования, такие как: надёжность, удобство сопровождения, доступность и пропускная способность, которые должны учитывать разработчики; 5) атрибуты системной среды: это такие дополнительные неповеденческие требования, как способность системы функционировать в условиях определённых операционных ограничений и нагрузок, а также совместимость с операционной системой. Взаимосвязь между функциями и требованиями к ПО В документе "Концепция" функции были описаны на языке пользователя. Требования к ПО должны быть более конкретными. На их основе мы собираемся создавать код, поэтому они должны быть тестируемые. Например: -------------------------+-------------------------------- Концепция |Программные требования -------------------------+-------------------------------- Функция 61. Система обна-|ПФ 61.1. Информация о неполадках ружения неполадок будет |будет предоставляться в виде от- предоставлять информацию |чёта-гистограммы, где по оси X об обнаруженных дефектах,|откладывается время, а по оси Y чтобы помочь пользователю|- количество обнаруженных дефек- оценить состояние прило- |тов жения |ПФ 61.2. Пользователь может за- |дать временной интервал для по- |лучаемой информации в днях, не- |делях или месяцах |ПФ 61.3. Вид отчёта представлен |на след. рисунках У к . в| .| +-+ +-+ и| | | | | с| | | +-+ +-+ | п| | | | | | | .| | | | | | | -+-+++-++-+--+-+-++---- Время Исключение информации, связанной с управлением проектом Требования к ПО не должны содержать информацию о системной архитектуре и техническом проекте. В противном случае можно ненамеренно ограничить команду в выборе наиболее подходящих для данного приложения вариантов проектирования. Исключение из требований деталей, связанных с проектированием, не всегда очевидно. Например: Информация о ... гистограммы, составленной с помощью Visual Basic ... Возможны 3 варианта: 1) один из членов группы разработчиков при уточнении концепции решил указать Visual Basic как наилучшее решение; 2) это может быть указанием заказчика: опасаясь дорогих решений, заказчик решил, что нужно использовать технологию Visual Basic; 3) это может быть политическое решение, принятое организацией-разработчиком: все приложения должны разрабатываться на Visual Basic. 1) - нелегитимное решение; 2) - требование должно было попасть в ограничения на разработку; 3) - пункт соглашения с заказчиком. Дальнейшее уточнение требований Полезно разбить требования на три категории: 1) функциональные требования к ПО; 2) нефункциональные требования к ПО; 3) ограничения проектирования. Функциональные требования к ПО - это требования, обычно ориентированные на действия. Большинство таких требований можно сформулировать в виде простых декларативных определений или декларативных прецедентов. Нефункциональные требования - это практичность, надёжность, производительность, возможность обслуживания. Практичность зависит от точки зрения наблюдателя. Имеются следующие рекомендации для уточнения этого понятия: 1) указать необходимое время подготовки пользователя для достижения минимальной производительности; могут понадобиться отдельные описания для начинающих, средних и опытных пользователей; 2) указать время выполнения типичных задач или транзакций, выполняемых конечным пользователем; 3) сравнить практичность новой системы с уже существующими современными системами; 4) оговорить существование систем интерактивных подсказок, программ-помощников, средств предупреждения, руководств пользователя и т. д.; 5) следовать соглашениям и стандартам для человеко-машинного интерфейса (напр., стандарт Home User Access компании IBM). Попытка создания более точного определения практичности содержится в "Билль о правах пользователей": 1) пользователь всегда прав; если возникает проблема с использованием системы, то проблема в системе; 2) пользователь имеет право на программное и аппаратное обеспечение, которое легко монтируется и демонтируется без негативных последствий; 3) пользователь имеет право на то, чтобы система делала в точности то, что обещано; 4) пользователь имеет право на простые в использовании инструкции, которые позволяют ему понимать систему и использовать её для достижения своих целей, а также выходить из сложных ситуаций; 5) пользователь имеет право на внимание со стороны системы и получение ответа на запрос о внимании; 6) пользователь имеет право на то, чтобы система предоставляла чёткую, понятную и точную информацию о выполняемой задаче и ходе её выполенения; 7) пользователь имеет право на то, чтобы его информировали о всех системных требованиях для успешного использования ПО либо аппаратуры; 8) пользователь имеет право общаться с провайдером технологий и получать полные и исчерпывающие ответы; 9) пользователь имеет право знать о пределах возможностей системы; 10) пользователь должен быть хозяином программных и аппаратных технологий, а не наоборот; продукты должны использоваться естественно и интуитивно. Надёжность. Понятно, что полного отсутствия ошибок не бывает. В документе нужно указать, в какой степени система должна вести себя приемлемым для пользователя образом. Для этого рассмотрим основные составляющие надёжности: 1) доступность: система должна быть доступна для пользователя в течение указанного периода времени; 2) среднее время между отказами; 3) среднее время восстановления (90% сбоев должны ликвидироваться за 5 минут); 4) точность (до копейки, до минуты, до сантиметра и т. д.); 5) максимальный коэффициент ошибок: обычно это число ошибок на тысячу строк кода или на одну функцию; 6) количество различных ошибок: обычно ошибки делятся на незначительные, серьёзные и критические; в документе нужно дать полные определения этой классификации. Производительность: 1) время ответа для транзакции (обычно указывают среднее и максимальное); 2) пропускная способность: число транзакций, например, в секунду; 3) ёмкость: сколько пользователей или транзакций может обслужить система; 4) режимы снижения производительности (допустимые режимы работы при ухудшении параметров системы). Возможность обслуживания и сопровождения. Возможность обслуживания заключается в способности легко модифицировать ПО с целью внесения изменений и исправлений. В некоторых предметных областях можно заранее предвидеть вероятную природу будущих изменений. В этом случае требования должны содержать "время ответа" группы поддержки для простых, средних и сложных изменений. Ограничения проектирования Ограничения проектирования налагаются на проект системы или процессы, с помощью которых система создаётся. Они не влияют на внешнее поведение системы, но должны выполняться для удовлетворения технических, деловых или контрактных обязательств. Источники ограничений на проектирование следующие: 1) программные среды; 2) совместимость с существующими системами; 3) прикладные стандарты (напр., использовать опр. библиотеку классов); 4) корпоративные практические наработки и стандарты; 5) отраслевые стандарты (напр., стандарты управления по санитарному надзору за продуктами и медикаментами, правительственная комиссия по средствам связи, требования по технике безопасности и т. д.): подобные ограничения в оригинале очень ёмкие, поэтому рекомендуется использовать ссылки на них. Общие рекомендации по оформлению ограничений проектирования: 1) рекомендуется заключать все ограничения проектирования в специальный раздел требований; 2) необходимо указывать источник каждого ограничения; 3) нужно документировать объяснения для каждого ограничения проектирования; 4) рекомендуется использовать дочерние требования: многие проекты выигрывают от использование дочерних требований в качестве средств дополнения базовых требований; дочерние требования служат для повышения уровня конкретизации родительских требований, например: базовое требование - пример должен работать от стандартной электросети Украины; дочернее требование: прибор должен работать в диапазоне от XXX до YYY вольт; прибор должен потреблять XXX ампер; для нормальной работы прибора диапазон изменения частоты от XX до YY герц. Варианты использования Вариант использования фиксирует соглашение между участниками разработки системы о её поведении. Он описывает поведение системы при её ответах на запрос одного из участников, называемого основным действующим лицом в различных условиях. Основное действующее лицо инициирует взаимодействие с системой, чтобы добиться некоторой цели. Система отвечает, соблюдая интересы всех участников. Различные модели поведения (сценарии) развёртываются в зависимости от определённых запросов и условий, при которых делаются эти запросы. Вариант использования собирает вместе эти сценарии. Вариант использования - это описание взаимодействия пользователя с будущей системой при соблюдении интересов всех заинтересованных лиц. Пользователь называется основным действующим лицом. Принято различать три уровня вариантов использования: 1) уровень обобщённой цели (уровень системы); 2) уровень пользователя; 3) уровень подфункций. Пример: онлайновый аукцион [Проект в целом] v-------------------+-v---------------v [Организация рекламы] [Оформление заказа] [Работа со счётом] Уровень системы (объединение цели) | +-----------------------------------------------------+----------------+--------------+ v---+-------------------------v--------------------------v v v v [Начать продвижение] [Выдать справку о продвижении] [Проследить продвижение] [Разместить заказ] [Оформить счёт] [Выставить счёт] Цели пользователя | +----|--------------------|--+-----+ +------------------+-----------|---+------------+ | +---+-----+----|-------------------+| | +---|----------+-------|-----------+ | | v v v vv v v vv---------v-------v---v-----------v----------v----------------+ [Определить продвижение] [Зарегистрировать пользователя] [Идентифицировать продукт] [Идентифицировать клиента] Подфункции