Добавил:
ivanov666
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз:
Предмет:
Файл:Основы разработки информационных систем. Учебное пособие.pdf
X
- •ВВЕДЕНИЕ
- •1. МЕТОДИЧЕСКИЕ АСПЕКТЫ ПРОЕКТИРОВАНИЯ ИНФОРМАЦИОННЫХ СИСТЕМ
- •1.2. ПОНЯТИЕ ЖИЗНЕННОГО ЦИКЛА ИНФОРМАЦИОННОЙ СИСТЕМЫ
- •1.3. ПОНЯТИЕ CASE
- •1.4. ЭТАПЫ РАЗРАБОТКИ ИНФОРМАЦИОННЫХ СИСТЕМ
- •1.5. МОДЕЛИРОВАНИЕ БИЗНЕС-ПРОЦЕССОВ
- •2.2. ОСНОВНЫЕ ПРИНЦИПЫ ГИБКИХ МЕТОДОЛОГИЙ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
- •2.3. КРАТКИЙ ОБЗОР ОСНОВНЫХ ГИБКИХ МЕТОДОЛОГИЙ
- •2.4. ИНЖЕНЕРНЫЕ ПРАКТИКИ
- •3.1. АРХИТЕКТУРНАЯ/ПРОЕКТНАЯ ДОКУМЕНТАЦИЯ
- •3.2. МАРКЕТИНГОВАЯ ДОКУМЕНТАЦИЯ
- •3.3. ТЕХНИЧЕСКОЕ ЗАДАНИЕ
- •4.3. ОСНОВНЫЕ ОПРЕДЕЛЕНИЯ СТАНДАРТА ISO/IEC 15910:1999
- •4.4. ВЫПОЛНЕНИЕ ПРОЦЕССА ДОКУМЕНТИРОВАНИЯ
- •4.6. ТРЕБОВАНИЯ К СОДЕРЖАНИЮ СПЕЦИФИКАЦИИ СТИЛЯ ДОКУМЕНТАЦИИ
- •5. ОСНОВНЫЕ ПРАВИЛА ОРГАНИЗАЦИИ ДИАЛОГА ПРОГРАММНОГО ИЗДЕЛИЯ С ПОЛЬЗОВАТЕЛЕМ
- •5.1. РАЗРАБОТКА ПОЛЬЗОВАТЕЛЬСКИХ ИНТЕРФЕЙСОВ
- •5.1.1. Критерии оценки интерфейса пользователем
- •5.3. АНАЛИЗ ПОЛЬЗОВАТЕЛЬСКОГО ИНТЕРФЕЙСА
- •5.4. ПОЛЬЗОВАТЕЛЬСКИЕ ИНТЕРФЕЙСЫ И СПЕЦИФИКАЦИЯ ТРЕБОВАНИЙ К ПО
- •6. РАЗРАБОТКА ТРЕБОВАНИЙ К ПО
- •6.1. ОПРЕДЕЛЕНИЕ ТРЕБОВАНИЙ К ПО
- •6.1.2. Определение термина «требование» в словаре
- •6.2. ТРИ УРОВНЯ ТРЕБОВАНИЙ
- •6.3. ТРЕБОВАНИЯ К ПРОДУКТУ И ТРЕБОВАНИЯ К ПРОЕКТУ
- •6.4. РАЗРАБОТКА И УПРАВЛЕНИЕ ТРЕБОВАНИЯМИ
- •6.5. РАЗРАБОТКА ТРЕБОВАНИЙ
- •6.5.1. Выявление и сбор требований
- •6.5.2. Анализ
- •6.5.3. Документирование
- •6.5.4. Утверждение
- •6.6. УПРАВЛЕНИЕ ТРЕБОВАНИЯМИ
- •6.7. КОГДА ПОЯВЛЯЮТСЯ ПЛОХИЕ ТРЕБОВАНИЯ?
- •6.8. ВЫГОДЫ ОТ ВЫСОКОКАЧЕСТВЕННОГО ПРОЦЕССА РАЗРАБОТКИ ТРЕБОВАНИЙ
- •6.9. ИНСТРУКЦИЯ ПО ИСПОЛЬЗОВАНИЮ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
- •ЗАКЛЮЧЕНИЕ
- •СПИСОК ЛИТЕРАТУРЫ
- •ПРИЛОЖЕНИЕ

ложение по-разному (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. processimpact.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 Standard.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. Описание
Клиент кафетерия, личность которого подтверждена, может заказывать
Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]
