Материал: u_lectures

количество на складе. Менеджер назначает скидку и определяет порядок оплаты. Система рассчитывает итоговую сумму. [Менеджер должен иметь возможность видеть текущее сальдо расчётов с клиентом и данные по последним десяти сделкам со статистикой по дисциплине соблюдения договорных обязательств].

Средние значения атрибутов и объёмы объектов

Данная информация позволяет оптимальнее построить пользовательский интерфейс и оценить на ранних стадиях проекта «узкие места» в обработке данных, которые могут повлиять на производительность системы.

Так, при выборе из 2 возможностей лучше подойдёт элемент управления checkbox, при выборе, ограниченном 2-3 десятками позиций – выпадающий список, при многообразии, измеряемом тысячами вариантов, потребуются дополнительные средства фильтрации и поиска.

Пример. Описание потока событий ИСП для прецедента «Оформить заказ», расширенного объёмами и средними значениями объектов (текст в фигурных скобках).

В процессе выполнения прецедента менеджер по приёму заказов выбирает заказчика из клиентской базы {до 10000 клиентов}, определяет товарные позиции из справочника {товары разбиты на 10 категорий, количество позиций в категории не превышает 500} и указывает их количество {до 100 позиций, средняя закупка – 8 позиций}. Система отображает на мониторе наименование позиций, цену, сумму и количество на складе. Менеджер назначает скидку и определяет порядок оплаты {на данный момент существуют 3 варианта порядка оплаты}. Система рассчитывает итоговую сумму.

Средняя интенсивность использования

Средняя интенсивность использования позволяет выделить сценарии «массового» использования, в которых всё должно быть идеально (быстродействие, удобство пользования, минимум действий на выполнение операций). Например – интерфейс кассира в супермаркете. Другая крайность – сценарии, выполняемые от случая к случаю, не каждый день и не требующие особой оперативности (например, расчёт заработной платы за месяц). Эти данные позволяют, структурировать подачу информации, убрать из «главных» интерфейсов редко используемые опции и т.п.

Пример. Фрагмент описания потока событий ИСП для прецедента «Оформить заказ для нового клиента», расширенного объёмами и средними значениями объектов (текст в круглых скобках).

В процессе выполнения прецедента менеджер по приёму заказов выбирает заказчика из клиентской базы (в 95% случаев), либо вызывается интерфейс регистрации нового клиента (в 5% случаев).

Литература к лекции

14.Фаулер М., Скотт К. UML в кратком изложении. Применение стандартного языка объектного моделирования: Пер. с англ. – М.:Мир, 1999. – 191 с., ил.

15.Леоненков. Самоучитель UML.

16.Мацяшек Лешек, А. Анализ требований и проектирование систем. Разработка информационных систем с использованием UML.: Пер. с англ. - М.: Издательский дом "Вильямс", 2002. - 432 с.: ил. - Парал. тит. Англ.

17.Маклаков С.В. Bpwin Erwin Case-средства разработки информационных систем. – Москва “ДиалогМифи ” – 2000

18.Вигерс Карл Разработка требований к программному обеспечению/Пер, с англ.

— М.:Издательско-торговый дом «Русская Редакция», 2004. —576с.: ил.

19.Орлов C. Технологии разработки программного обеспечения: Учебник. – СПб.:

Питер, 2002. – 464 с.: ил.

20.Каменова, Громов. Моделирование бизнеса. Методология ARIS. — М.: ВестьМетаТехнология, 2001.

21.Брауде Э. Технологии разработки программного обеспечения. – СПб: Питер, 2004. – 655 с.: ил.

22.Леффингуелл Д., Уидриг Д. Принципы работы с требованиями к программному обеспечению. М.: ИД “Вильямс”, 2002.

23.Л.Новиков. Введение в Rational Unified Process.

http://www.interface.ru/rational/interface/151199/rup/main.htm

6. Документирование и проверка требований

План лекции

Документирование требований в соответствие с ГОСТ РФ Структура ТЗ в соответствие с ГОСТ 34.602-89

Описание требований к системе в соответствие с ГОСТ 34.602-89 Документирование требований в RUP

Документирование требований на основе IEEE Standard 830-1998

Документирование требований в MSF Верификация и валидация.

Двусмысленность требований "Золочение" продукта Минимальная спецификаций

Пропуск типов пользователей Методы и средства проверки требований

Неофициальные просмотры требований Инспекции Разработка тестов

Определение критериев приемлемости

Чтобы требования, выявленные и описанные (см. материалы лекции 3 и лекции 4) приняли силу соглашения между Заказчиком и Разработчиком, их необходимо оформить в виде документа. В российской практике для этого обычно используется документ

«Техническое задание», ТЗ, в западной – «Software Requirements Specification», SRS (спецификация программных требований). По сути это – один и тот же документ, поэтому далее по тексту будем употреблять термин «ТЗ», рассматривая различные шаблоны его построения – как на основе российских ГОСТ, так и западных методологий и стандартов.

Документирование требований в соответствие с ГОСТ РФ

Документирование требований регламентировано российскими ГОСТ 19.201-78 «Техническое задание, требования к содержанию и оформлению» и ГОСТ 34.602-89 «Техническое задание на создание автоматизированной системы» (ТЗ на АС) [27-28].

Второй документ, по сути, является более проработанной версией первого, адаптированной к созданию автоматизированных информационных систем, поэтому далее рассмотрена структура ТЗ в соответствие с ГОСТ 34.602-89.

Несмотря на то, что для сферы IT 17 лет – это целая эпоха, данный документ практически не устарел: его авторам удалось разработать сбалансированные рекомендации, абстрагируясь от конкретных технических и технологических решений. Кроме того, он по-прежнему играет роль государственного стандарта РФ и при заключении контрактов с государственными предприятиями Разработчика могут обязать оформить ТЗ в соответствии с духом и буквой этого документа.

Структура ТЗ в соответствие с ГОСТ 34.602-89

В задачи лекции не входит перечисление всех правил и рекомендаций данного ГОСТ, желающие могут ознакомиться с ним непосредственно. Ниже будут перечислены разделы, предусмотренные ГОСТ и рассмотрены основные моменты, на которые следует обратить внимание.

Общие сведения – в этом разделе, помимо юридических реквизитов сторон и пр. деловой информации ГОСТ рекомендует указать источники и порядок финансирования работ.

Назначение и цели создания (развития) системы – здесь необходимо указать показатели объекта автоматизации, которые должны быть достигнуты и критерии оценки достижения этих показателей. Данным разделом на практике часто пренебрегают и совершенно напрасно – ведь именно в этом разделе закладываются высокоуровневые бизнес-требования и формулируются критерии их достижения.

Характеристика объектов автоматизации – достаточно важный раздел. Его основные «разрезы» - организационная структура, структура управления, структура расположения предприятия и его филиалов. Хорошее описание объекта автоматизации позволяет сэкономить время на определение классов пользователей, для крупных территориально-распределённых систем – заложить структуру и топологию сетевых коммуникаций.

Требования к системе – ключевой раздел настоящего документа, поэтому он будет рассмотрен ниже, более подробно.

Раздел «Состав и содержание работ по созданию системы», говоря современным языком, описывает процесс создания системы, включая выбор методологии, определяющий содержание стадий, этапов и фаз и его конкретизацию для проекта (количество этапов и итераций, их основное содержание).

Порядок контроля и приемки системы – также один из ключевых компонент ТЗ.

Он распределяет роли Заказчика и Разработчика в подготовке системы к испытаниям и проведению испытаний. Здесь уместно оговорить правила проведения испытаний, сформулировать основные тестовые сценарии и критерии приёмки.

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

Документ заканчивается разделами «требования к документированию» и «источники разработки», определяющими, соответственно, перечень и формы документации, подлежащей разработке и перечень уже имеющихся документов, содержащих предпосылки для разработки.

В качестве приложений ГОСТ рекомендует использовать расчет ожидаемой эффективности системы и оценку научно-технического уровня системы.

Описание требований к системе в соответствие с ГОСТ 34.602-89

ГОСТ разделяет все требования к системе на три класса:

требования к системе в целом;

требования к функциям (задачам), выполняемым системой;

требования к видам обеспечения.

Среди требований к системе в целом (системные требования) указываются требования к:

структуре системы (здесь закладываются высокоуровневые архитектурные решения, либо структурные ограничения, вводится деление на подсистемы, комплексы и модули, решаются вопросы коммуникации компонент системы и системы с внешним миром),

режимам функционирования системы;

персоналу (указывается численность, требуемая квалификация и режим работы);

надежности;

безопасности;

эргономике и технической эстетике;

транспортабельности для подвижных АС;