Добавил:
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Основы разработки информационных систем. Учебное пособие.pdf
Скачиваний:
0
Добавлен:
07.09.2026
Размер:
2 Мб
Скачать
☆
ложение по-разному (Lawrence, 1996). Другой симптом состоит в том, что у не­скольких читателей требования возникает разное понимание, что оно означает.
Двусмысленность ведёт и к формированию различных ожиданий у заин­тересованных лиц. Впоследствии некоторые из них удивляются результату. Разработчики же впустую тратят время, занимаясь не теми задачами. А тес­тировщики готовятся к провер
ке не тех особенностей поведения системы.
Один из способов избавиться от двусмысленности – пригласить различ­ных представителей пользователей для официальной экспертизы требова­ний [9]. Неформальная дружественная оценка, в которой участники просто самостоятельно читают требования, часто не обнаруживает двусмысленности. Если они интерпретируют требования различными способами, но это имеет смысл для каждого из них, то неяс
ность не проявится. Совместное выявление и проверка требований стимулирует обсуждение и уточнение требований в группе в рамках совещания. Другой способ обнаружить двусмысленность – написать вариант тестирования для требования и построить прототип.
5. Требования-«бантики». Под «бантиками» (gold plating) понимают отсутствующие в спецификации требований функции, добавленные разра­ботчиками, потому что им кажется, что это понравится по
льзователям. Если избыточные возможности оказываются ненужными для клиентов, получает­ся, что время, отведённое на реализацию, тратится впустую. Прежде чем про­сто вставлять новые функции, разработчики и бизнес-аналитики должны представить свои творческие идеи на суд заказчиков. Задача команды – чётко соблюдать требования спецификации, а не действовать за спиной клиентов без их од
обрения.
Пользователи иногда требуют функции или элементы интерфейса, кото­рые выглядят красиво, но не представляют особой ценности для продукта. Всё, что вы захотите добавить, стоит времени и денег, поэтому постарайтесь максимизировать пользу от будущего продукта. Чтобы снизить количество «бантиков», отслеживайте каждый элемент функциональности до его источни­ка, чтобы чётко понимать, по
чему именно он включён в продукт. Убедитесь,
что всё специфицируемое и разрабатываемое находится в рамках проекта.
6. Пропущенные классы пользователей. Большинство продуктов предназначены для нескольких групп пользователей, которые могут применять различные наборы функций с разной частотой и иметь самый разный опыт работы с ПО. Если вы не определили важные классы пользователей для вашего
родукта заранее, некоторые потребности клиентов не будут учтены. После
п идентификации всех классов удостоверьтесь, что голос каждого услышан. Помимо очевидных пользователей не забудьте о сотрудниках поддержки, у которых есть собственные требования, функциональные и нефункциональные. У сотрудников, которые конвертируют данные из унаследованных систем, есть требования по переходу, которые не влияют на конечный п
родукт, но опреде­лённо влияют на успех решения. Могут быть заинтересованные лица, которые даже не знают о существовании проекта, например государственные учрежде­ния, определяющие стандарты, которые могут влиять на вашу систему, и вы должны знать о таких заинтересованных лицах и их влиянии на проект.
81

6.8. ВЫГОДЫ ОТ ВЫСОКОКАЧЕСТВЕННОГО ПРОЦЕССА РАЗРАБОТКИ ТРЕБОВАНИЙ

Многие люди ошибочно считают, что время, которое тратится на обсу­ждение требований, просто отсрочивает выпуск продукта. Они предполага­ют, что работа с требованиями не повышает рентабельность проекта. На са­мом деле, затраты на получение хороших требований практически всегда возвращаются с излишком.
В удачных процессах создания требований к совместной партнёрской работе над п
роектом привлекаются множество заинтересованных лиц, при­чём на протяжении всего проекта. Сбор требований позволяет команде раз­работчиков лучше понять пользователей или реалии рынка, что критически важно для любого проекта. Делая упор на задачи пользователей, а не на внешне привлекательные функции, команда избежит необходимости перепи­сывать код, который даже не понадобится. Вовлечение клиенто
в в процесс снижает вероятность появления ложных ожиданий, возникающих из-за раз­личия того, в чём пользователи нуждаются, и того, что разработчики выпус­кают. Рано или поздно вы начнёте получать отзывы заказчиков. Причём на­много дешевле добиться взаимопонимания до начала разработки продукта, чем после финальной поставки.
Ясное разделение требований на те, что отн
осятся к ПО, оборудованию или подсистемам, взаимодействующим с людьми, позволяет применять сис­темный подход к разработке продукта. Эффективные процессы управления изменениями минимизируют неблагоприятные последствия от изменения требований. Недвусмысленно составленные документы облегчают тестиро­вание продукта. В совокупности всё это повышает шансы создать высокока­чественный продукт, который удовлетворит всех пользователей.
Никто не ста
нет обещать конкретный возврат инвестиций в процесс улучшения требований. Вы можете мысленно проанализировать, как более качественные требования могут помочь вашим командам (Wiegers, 2006). Стоимость более качественных требований складывается из стоимости раз­работки новых процедур и шаблонов документов, тренинга команды и по­купки инструментов. Наибольшая инвестиция – это время, которое ваша ко­манда тратит на сбор, до
кументирование, просмотр и управление требова-
ниями. Возможные выгоды таковы:
• меньше дефектов в требованиях и в готовом продукте;
• меньше переделок;
• быстрее разработка и поставка готового продукта;
• меньше ненужных и неиспользуемых функций;
• ниже стоимость модификации;
• меньше недопонимания;
• меньше расползания границ проекта;
• меньше беспорядка в п
роекте;
• выше удовлетворение заказчиков и членов команды;
82
• продукты, которые делают то, что от них ожидается. Даже если вы не можете количественно оценить все преимущества, они
всё равно реальны.

6.9. ИНСТРУКЦИЯ ПО ИСПОЛЬЗОВАНИЮ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

Инструкция по использованию программного обеспечения (или просто
«Инструкция пользователю», или «Руководство для пользователя») – это вы-
держка из полной документации, предназначенная для эксплуатации про­граммного обеспечения. Она представляет собой независимый документ, в котором описывается: что делает программное обеспечение и как им поль­зоваться. «Инструкция пользователю» должна содержать всю необходимую для пользователя информацию и до
лжна быть ему понятна без дополнитель­ных материалов (без обращения к другим спецификациям). Следовательно, необходимая для этой инструкции информация переписывается полностью из соответствующих спецификаций. Первая часть инструкции является описа­тельной и должна содержать:
• наименование программного обеспечения;
• краткое описание программного обеспечения;
• перечень выполняемых им функций;
• краткую ха
рактеристику метода (или методов), его достоинство и
недостатки;
• полную библиографическую ссылку на полное описание метода;
• описание входных и выходных данных.
Вторая часть документа должна описывать порядок работы с программ­ным обеспечением. Она должна содержать описание всех режимов работы программного обеспечения, а также содержание всех печатей и диагностиче­ских сообщений, кот
орые выдаются по ходу выполнения программы.
Следует помнить, что пользователь по своей квалификации не является программистом и поэтому его работа с программным обеспечением описыва­ется на понятном ему языке и достаточно подробно, а именно:
• как запустить программное обеспечение;
• как продолжить работу с программным обеспечением (описывается
подробный интерактивный режим ег
о работы с ПО);
• подготовка и ввод исходных данных в программное обеспечение;
• как реагировать на запросы программного обеспечения;
• как вести работу в исключительных ситуациях;
• как реагировать на ошибки;
• как восстановить работу программного обеспечения в случае ава-
рийного его завершения;
• как получить требуемый результат;
• как пр
авильно закончить работу с программным обеспечением (за-
планированный программой выход).
83

ЗАКЛЮЧЕНИЕ

В учебном пособии рассмотрены отдельные вопросы разработки ин­формационных систем.
При изучении данного пособия студенты познакомятся с:
− методическими аспектами проектирования;
− понятием жизненного цикла информационной системы;
− методологией разработки программного обеспечения;
− вопросами документирования процесса разработки и сопровождения
программного обеспечения;
− процессом разработки документации программных средств и её
стандартизации;
овными правилами организации диалога информационной систе-
− осн
мы с пользователем;
− вопросами разработки требований к программному обеспечению.
Также учебное пособие содержит примеры документирования требова­ний, рамки и ограничения проекта, спецификации требований к ПО;
В результате освоения пособия студенты получат представление о спо­собах разработки информационных систем, общих правилах разработки интерфейсов ПО, а также о на примере документирования требований смогут самостоятельно разрабо­тать спецификацию требований к ПО.
собенностях документирования разработки ПО,
84

СПИСОК ЛИТЕРАТУРЫ

1. Вольфсон, Борис. Гибкие методологии разработки [Электронный
ресурс] / Вольфсон Борис. – Режим доступа : http://adm-lib.ru/books/10/Gibkie-
metodologii.pdf
2. Хенрика, Книберга. Scrum и Kanban: выжимаем максимум [Элект-
ронный ресурс] / Хенрика Книберга, Маттиаса Скарина. – Режим доступа : http://www.agilemoldova.com/p/scrum-kanban.html
3. Сайт о гибкой разработке программного обеспечения. Agilerussia.ru
[Электронный ресурс]. – Режим доступа : http://agilerussia.ru
4. Архитектура информационных систем : учебник для студ. учреж-
дений высш. п кий, В. В. Цехановский. – М. : Издательский центр «Академия», 2012. –
288 с.
5. Вендров, А. М. Проектирование программного обеспечения эконо-
мических информационных систем : учебник для вузов / А. М. Вендров. – М. : Финансы и статистика, 2005. – 544 с.
6. Липаев, В. В. Программная инженерия. Методические осн
[Электронный ресурс] : учебник для вузов / В. В. Липаев. – М. : ТЕИС, 2006. – 608 с. – Режим доступа : http://window.edu.ru
7. Проектирование информационных систем. Проектный практикум
[Электронный ресурс] : учебное пособие для студ. напр. 09.03.03 днев. и заоч.
отд. / А. В. Платенкин, И. П. Рак, А. В. Терехов, В. Н. Чернышов. – Тамбов : ФГБОУ ВПО «ТГТУ», 2015. – 96 с.
8. Вигерс, Карл. Разработка требований к п
Вигерс Карл, Битти Джой. – 3-е изд., доп. ; пер. с англ. – М. : Изд-во «Русская редакция» ; СПб. : БХВ-Петербург, 2014. – 736 с. : ил.
9. Якобсон, А. Унифицированный процесс разработки программного
обеспечения / А. Якобсон, Г. Буч, Дж. Рамбо. – СПб. : Питер, 2002. – 496 с. : ил.
10. Чернев, Д. А. Техн
учебное пособие / Д. А. Чернев. – Ташкент : Mehnat, 2004. – 224 с.
роф. образования / Б. Я. Советов, А. И. Водяхо, В. А. Дубенец-
овы
рограммному обеспечению /
ология разработки программного обеспечения :
85

ПРИЛОЖЕНИЕ

Примеры документации требований.
В данном приложении на примере небольшого гипотетического проекта под названием «Кафетерий» проиллюстрированы некоторые описанные в этом пособии документы и диаграммы, необходимые при разработке требо­ваний. К ним относятся:
• рамки и ограничения проекта;
• часть спецификации требований к ПО;
• несколько фрагментов моделей анализа, в том числе дерево функций,
контекстная д состояний;
• фрагмент словаря данных;
• несколько бизнес-правил.
Поскольку это лишь пример, эти элементы документации требований намеренно не приводятся в законченном виде. Здесь просто показаны в об­щих чертах, как различные типы информации, необходимой при создании требований, относятся друг к другу и как можн ждого раздела. Информацию в этих примерах можно организовывать и груп­пировать по-разному в зависимости от задачи – объединять в единый доку­мент в маленьком проекте или хранить в средстве управления требованиями. Ясность, полнота и простота использования документации требований – важнейшие задачи при её составлении. Документы обычно строятс лонам, описанным в предыдущих главах, но здесь из-за малых масштабов этого проекта некоторые разделы шаблона объединены. Для каждого проекта необходимо учитывать, как адаптировать стандартные шаблоны организации, чтобы они лучше соответствовали размеру и природе проекта.
FE-1 Заказ и оплата блюд из меню кафетерия для получения в кафете­рии или с доставкой.
FE-2 Заказ и оплата блюд с доставкой из близлежащих ресторанов.
FE-3 Создание, просмотр, изменение и удаление одинарной или регу- лярной заявок на питание или на ежедневные специальные блюда.
FE-4 Создание, просмотр, изменение и удаление меню кафетерия.
FE-5 Просмотр списка ингр в меню кафетерия.
FE-6 Обеспечение доступа к системе через корпоративную интрасеть,
смартфон, планшет или через внешнее подключение к Интернету для автори­зованных сотрудников.
86
иаграмма, диаграмма «сущность-связь» и диаграмма переходов
о записывать содержание ка-
я по шаб-
1. РАМКИ И ОГРАНИЧЕНИЯ ПРОЕКТА
1.1. Основные функции
едиентов и сведения о питательности блюд
Рис. 1. Частичное дерево функций системы «Кафетерий»
1.2. Состав первого и последующих выпусков системы
Функция Выпуск 1 Выпуск 2 Выпуск 3
FE-1. Заказ в кафетерии
FE-2.
Заказы из ресторанов
FE-3. Подписки на стандартные блюда
FE-4. Меню Создание и просмотр
FE-5. Список ингредиентов
FE-6.
Доступ к системе
Только стандартные
функции из меню
обедов; оплата заказов
производится только
посредством удержа-
ния из зарплаты Не реализована Блюда доставляются
Не реализована Реализация,
меню
Не реализована Реализована полностью
Интрасеть и доступ
через Интернет
извне
Приём платежа
кредитной или
дебетовой картой
только на территории
компании
если позволит время
Модификация, удаление
и архивирование меню
Приложения
для телефонов
и планшетов с iOS
и Android
Приём заказов
на завтрак
и ужин
Реализована
полностью
Реализована
полностью
Приложения для телефонов и планшетов с
Windows Phone
87
1.3. Спецификация требований к ПО
1. Введение
1.1. Назначение
Эта спецификация требований к ПО описывает функциональные и не­функциональные требования к выпуску 1.0 «Кафетерий». Этот документ предназначен для команды, которая будет реализовывать и проверять кор­ректность работы системы. Кроме специально обозначенных случаев, все указанные здесь требования имеют высокий приоритет и приписаны к вы­пуску 1.0.
1.2. Соглашения, принятые в документах
В этой спецификации нет никаких типографских усло
вных обозначений.
1.3. Границы проекта
«Кафетерий» позволит сотрудникам компании заказывать блюда в кафе­терии компании через Интернет для доставки в указанные пункты на терри­тории компании. Детальное описание продукта приведено в документе «Ка­фетерий» Vision and Scope Document» [1], где перечислены функции, полная или частичная реализация которых запланирована в эт
ом выпуске.
Рис. 2. Контекстная диаграмма для выпуска 1.0 системы «Кафетерий»
88
1.4. Ссылки
Wiegers, Karl. «Кафетерий» Vision and Scope Document, www. processim­pact.com/projects/КАФЕТЕРИЙ/КАФЕТЕРИЙ Vision and Scope.docx
Beatty, Joy. Process Impact Intranet Development Standard, Version 1.3, www. processimpact.com/corporate/standards/PI Intranet Development Standard.pdf
Rath, Andrew. Process Impact Internet Application User Interface Standard, Version 2.0, www.processimpact.com/corporate/standards/PI Internet UI Stan­dard.pdf
2. Общее описание
2.1. Общий взгляд на продукт
«Кафетерий» – это новая система, которая заменяет текущие ручные процессы заказа и получения обедов в кафетерии Process Impact. Контекстная диаграмма на рис. 2 показывает внешние объекты и системные интерфейсы для версии 1.0. Предполагается выпустить несколько версий системы, чтобы в конечн
ом итоге удалось встроить её в службу заказов нескольких близле­жащих ресторанов, работающую через Интернет, а также в службы авториза­ции кредитных и дебетовых карт.
Класс
пользователей
Клиент (привилеги­рованный)
2.2. Классы и характеристики пользователей
Описание
Клиент – это сотрудник Process Impact, желающий заказывать питание с доставкой из кафетерия компании. Всего потенци­альных клиентов – 600, из которых 400, как ожидается, будут использовать «Кафетерий» в среднем 5 раз в неделю. Иногда клиенты будут заказывать питание на нескольких человек (мероприятия или гости). Ожидается, что 60% заказов будут поступать через корпоративную интрасеть, а 40% – с домаш­них компьютеров или с применением приложений для смарт­фонов или планшетов
Сотрудники кафетерия
В кафетерии Process Impact в настоящее время работает около 20 сотрудников, которые будут получать заказы через «Кафе­терий», готовить блюда, упаковывать их для доставки, печа­тать инструкции по доставке и запрашивать доставку. Боль­шинство сотрудников кафетерия придётся обучать работе с компьютером и использованию «Кафетерий»
Менеджер меню
Менеджер меню – это сотрудник кафетерия, отвечающий за создание и поддержку меню на каждый день, в котором ука­зано, какие блюда имеются в наличии в кафетерии. Некоторые блюда в меню могут быть недоступны для доставки. Менед­жер меню также определяет спецпредложение дня кафетерия. Менеджер меню должен периодически редактировать меню
89
Класс
пользователей
Курьер
Описание
Готовя заказы к доставке, сотрудники кафетерия будут отрав-
Продолжение табл. 2.2
лять запросы на доставку на смартфон курьера. Курьер будет забирать заказ и доставлять их клиентам. Главное взаимодей­ствие сотрудника по доставке с системой будет заключаться в подтверждении успеха (или неудачи) доставки
2.3. Операционная среда
OE-1. Система «Кафетерий» работает со следующими браузерами: Windows Internet Explorer версии 7, 8 и 9, Firefox версии с 12 по 26, Google Chrome (все версии) и Apple Safari версии с 4.0 по 8.0.
OE-2. Система «Кафетерий» установлена на сервере, работающем под управлением текущих утверждённых корпорацией версий Red Hat Linux и Apache HTTP Server.
OE-3. Система «Кафетерий» должна допускать доступ пользователей
через корпоративную интрасеть, VPN-канал и со смартфонов и планшетов под упр
соответствовать Process Impact Intranet Development Standard, версия 1.3 [2].
являющуюся корпоративным стандартом.
чий день компании, когда предполагается пр чих местах.
расчёта зарплат, позволяющих принимать запросы на оплату за питание, за­казанное через систему «Кафетерий».
учёта запасов кафетерия, позволяющих обновлять информацию о наличии блюд по мере принятия заказов системой «Кафетер
набор блюд либо с доставкой в указанное место на территории компании, либо для получения его в кафетерии. Клиент может отменить или изменить заказ, если блюда ещё не приготовлены. Приоритет – высокий.
90
авлением Android, iOS и Windows.
2.4. Ограничения дизайна и реализации
CO-1. Документация системы по дизайну, коду и сопровождению должна
CO-2. Система должна использовать текущую версию СУБД Oracle,
CO-3. Весь код HTML должен соответствовать стандарту HTML 5.0.
2.5. Предположения и зависимости
AS-1. Кафетерий открыт для завтраков, обедов и ужинов каждый рабо-
исутствие сотрудников на рабо-
DE-1. Работа системы «Кафетерий» зависит от изменений в системе
DE-2. Работа системы «Кафетерий» зависит от изменений в системе
ий».
3. Системные функции
3.1. Заказ блюд из кафетерия
3.1.1. Описание
Клиент кафетерия, личность которого подтверждена, может заказывать
Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]