Добавил:
ivanov666
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз:
Предмет:
Файл:Разработка требований к программному продукту. Учебное пособие
.pdf
Министерство науки и высшего образования Российской Федерации
НОВОСИБИРСКИЙ ГОСУДАРСТВЕННЫЙ ТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ
Н. И. ЛЫГИНА, О. В. ЛАУФЕРМАН
РАЗРАБОТКА ТРЕБОВАНИЙ
К ПРОГРАММНОМУ ПРОДУКТУ
Утверждено Редакционно-издательским советом университета
в качестве учебного пособия
НОВОСИБИРСК
2023
1
УДК 004.41(075.8)
Л88
Рецензенты:
С. В. Моторин, д-р техн. наук, профессор, СГУВТ
Д. Н. Достовалов, канд. техн. наук, доцент
Работа подготовлена на кафедре автоматизированных
систем управления
Лыгина Н. И.
Л88 Разработка требований к программному продукту : учеб-
ное пособие / Н. И. Лыгина, О. В. Лауферман. – Новосибирск :
Изд-во НГТУ, 2023. – 76
с.
ISBN 978-5-7782-4987-5
Учебное пособие посвящено вопросам обеспечения качества документирования требований, а также выбору и использованию специализированных программных средств управления требованиями. Рассмотрены показатели качества отдельных требований и набора требований
к разрабатываемой информационной системе в проекте в целом, приведены конкретные способы достижения качества требований и примеры, иллюстрирующие действенность их использования
Материалы учебного пособия по дисциплине «Документальная
поддержка и сопровождение информационных систем и технологий»
адресованы магистрантам факультета автоматики и вычислительной
техники направления подготовки 09.04.01 «Информатика и вычислительная техника» профиля «Компьютерное моделирование систем»,
а также всем, кто интересуется вопросами организации эффективной
разработки программных продуктов различного назначения.
.
УДК 004.41(075.8)
ISBN 978-5-7782-4987-5 © Лыгина Н. И., Лауферман О. В., 2023
© Новосибирский государственный
технический университет, 2023
2
ВВЕДЕНИЕ
Качество разработки требований определяет качество разрабатываемой информационной системы в целом. Материалы настоящего учебного пособия связаны с проектированием качественных требований
к информационным системам и предназначены для использования при
изучении дисциплины «Документальная поддержка и сопровождение
информационных систем и технологий», входящей в учебный план магистерской подготовки по направлению 09.04.01 «Информатика и вы
числительная техника» профиля «Компьютерное моделирование систем».
К настоящему времени издано много работ, в которых описывается
проектирование информационных систем и, в частности разработка
и управление требованиями [1–8]. Некоторые из них приведены в библиографическом списке учебного пособия.
Рассмотрение особенностей разработки требований ограничено вопросами обеспечения качества документирования требований, а также
выбора
управления требованиями.
риала «от вопроса», что предполагает предварительное «погружение»
читателя (магистранта) в тему и обеспечивает возможность получения
быстрого ответа на конкретный запрос.
фессионального стандарта № 70769 от 31.10.2022 «Технический писатель (специалист по
онных технологий)». Для этого отобрана обобщенная трудовая функция
«3.2
зователя, на продукцию в сфере информационно-коммуникационных
и использования специализированных программных средств
В настоящем учебном пособии принят способ структуризации мате-
Ниже показано соответствие целей обучающихся требованиям про-
технической документации в области информаци-
1
. Разработка документации, ориентированной на конечного поль-
-
1
Сохранена нумерация профессионального стандарта.
3
технологий, разработка стандартизированных технических документов
на основе предоставленного материала».
В табл. 1 приведены трудовая функция, трудовые действия, необходимые умения и знания, соответствующие обобщенной трудовой функции, а также цели обучающегося, которые могут быть им достигнуты
при успешном освоении материала дисциплины, в том числе представленного в настоящем учебном пособии.
В
учебном пособии рассмотрены показатели качества отдельных
требований и набора требований к разрабатываемой информационной
системе в проекте в целом, а также приведены конкретные способы достижения качества требований и примеры, иллюстрирующие действенность их использования. Приложение 1 содержит рекомендации по
устранению неоднозначностей в текстах.
Выбранная форма подачи материала в виде вопросов и ответов
позволяет по вопросу быстро найти нужный материал; сами вопросы определяют содержание ответа. Анализ формулировок вопросов в оглавлении дает целостное представление о характере задач, которые нужно решать при разработке требований. Одни вопросы порождают другие –
правильные, т. е. своевременные и нужные для развития или поддержания интереса к
теме работы. Вопросы учитывают определенный уровень подготовки обучающихся и позволяют «обойти» известные им сведения. Однако лучше этого не делать, поскольку есть вероятность
«пройти мимо» нового для себя.
Часть примеров размещена в приложениях 2–8. Таким образом сохраняется общий подход в раскрытии ответов, что очень важно, поскольку необходимо осмысливать
именно общие рекомендации для решения определенных задач в любом проекте. Примеры иллюстрируют
работоспособность общих подходов и рекомендаций в частных случаях,
и в этом смысле ограничены. Примеры в приложениях ценны иллюстрацией полезности графических форм представления материала для проектирования требований. Ценность предлагаемых образцов не определяется их принадлежностью к конкретной
предметной области – наоборот, «уход» от конкретной предметной области, для работы в которой
предназначена разрабатываемая информационная система, позволяет
сосредоточиться на более общих вопросах разработки и документирования требований.
После ознакомления с примерами целесообразно проанализиро-
вать нормы качества требований. В работе качество понимается как
4
соответствие нормам. Нормы являются ориентиром, следуя которому
можно получить качественный результат проектирования.
Таблица 1
Соответствие целей обучающихся требованиям
профессиональных стандартов
Трудовая функция
Разработка эксплуатационной документации, адресованной
Изучение целевой аудитории документа, выяснение
ее задач, потребностей в информации, уровня подготовки.
Изучение основ предметной области.
Изучение темы технического документа с точки
зрения целевой аудитории и с учетом ее информационных потребностей.
Составление текста документа, подготовка иллю-
страций.
Преобразование технического документа в требуе-
мый выходной формат
Необходимые умения
Исследовать техническую
документацию, извлекать
из нее сведения, необходимые для решения поставленной задачи.
Составлять требования
к эксплуатационному документу
конечному пользователю продукта (В/01.5)
Трудовые действия
Необходимые знания
Основные типы экс-
плуатационных документов, адресованных
пользователям, их особенности.
Основные стандарты
эксплуатационной документации, в том числе
документации пользователя.
Методика и стиль из-
ложения документации
пользователя (технических средств, программных средств).
Информационно-спра-
вочный и поисковый аппарат документа
Цели обучающегося
Уметь:
представлять информацию
о бизнес-процессах и процессах обработки информации
в корпоративной информационной системе с использованием моделей данных;
использовать модели данных
для обеспечения качества отдельных требований и набора
требований в целом;
выбирать специализирован-
ное программное средство
для конкретного проекта.
Знать:
показатели
ных требований и набора требований в целом;
приемы устранения неодно-
значности требований, поиска
пропущенных и лишних требований;
типы моделей данных.
Их особенности и возможности;
виды источников требова-
ний;
возможности ссылочной си-
стемы между требованиями;
возможности специализиро-
ванных программных систем
управления
качества отдель-
требованиями
5
В приложении 9 представлена анкета, предназначенная для оценки
качества требований разрабатываемой информационной системы. При
этом полезно соотнести личные нормы качества (они всегда есть, но не
всегда осознаются) с предлагаемыми нормами и при необходимости
скорректировать личные нормы.
Следует иметь в виду, что именно качество требований (аналога целей в любом проекте) определяет
успех проекта в целом. Управление
требованиями в проекте, начиная от их выявления и заканчивая проверкой качества их реализации, дает максимальный эффект в том случае,
когда разработчики имеют и используют продуктивные методы и способы разработки требований. Только тогда применение дополнительных специализированных программных средств в ходе проектирования
может способствовать повышению
качества разработки.
6
ВОПРОСЫ И ОТВЕТЫ ПО РАЗРАБОТКЕ
ТРЕБОВАНИЙ
1. Почему важно разрабатывать качественные требования?
Некачественные требования нередко являются причиной внесения
изменений в разрабатываемый проект на разных стадиях его жизненного цикла, что может привести к увеличению бюджета проекта, сроков
его исполнения, а также к реализации функциональности и качества
проекта, не удовлетворяющих запросам пользователей.
Разработка качественных требований счи-
Внимание!
тается инвестицией,
Краткое описание основных действий при
разработке требований размещено на социальной платформе tproger.ru.
2. Зачем привлекать заинтересованных лиц к работе
над проектом на ранних стадиях разработки?
а не затратами в проекте.
Заинтересованные лица проекта пред-
Заинтересованные лица
ставляют собой группы людей с примерно
одинаковыми потребностями, уровнем подготовки в предметной области и владения ITтехнологиями.
В проекте по разработке информационных систем к заинтересован-
ным лицам относят
заказчика, пользователей и команду разработчиков
(аналитиков, программистов, тестировщиков, технических писателей,
менеджеров проекта, дизайнеров интерфейсов и др.).
Организация эффективного взаимодей-
Делаем!
ствия с заинтересованными лицами в процессе всей разработки проекта позволяет
7
своевременно обнаруживать ошибки и устранять их на этапе возникновения. Позднее обнаружение ошибок на стадии программирования
или тестирования может привести к срыву сроков окончания проекта
и увеличению затрат.
Заказчики, как правило, недооценивают степень влияния качества
подготовленных требований на успех всего проекта, поэтому не считают необходимым включать в план
работ задачи по взаимодействию
с заинтересованными лицами в нужном объеме.
Разработчики нередко завышают ценность собственного профессионального опыта для конкретного проекта, «назначая себя» самым важным источником знания о потребностях пользователей и поэтому ограничивая общение с потенциальными пользователями. Разработчики
также могут не понять и неверно или неточно задокументировать потребности
пользователей либо бизнес-правила. Это приводит к реализации в проекте таких способов решения задач пользователей, которыми
они не будут пользоваться, так как это не их способы.
Регулярные встречи с заинтересованными лицами и их участие
в проверке качества проделанной работы, особенно на начальных этапах при формулировании требований, существенно уменьшают
вероятность ошибок из-за недопонимания. При этом важно высокое качество
проверки пользователями результатов работы на каждом этапе жизненного цикла разработки, иначе риск возникновения ошибок возрастает.
3. К чему приводит небрежное планирование в проекте?
«У меня есть классная идея для нового проекта! Когда можно это
сделать?» – подобные вопросы может задать
любое заинтересованное
лицо при случайной встрече (например, за чашкой кофе или в коридоре
на бегу) с ответственным за разработку требований в проекте. Нельзя
включать в список реализуемых требований подобные предложения без
предварительного обдумывания и обсуждения с заинтересованными лицами, даже если на первый взгляд требование представляется разумным
и странно, что
оно было пропущено. Реализация таких требований в бу-
дущем может негативно повлиять на успех проекта.
Под успехом проекта понимают реализа-
Критерии
успешного
проекта
цию функциональности и качества проекта,
удовлетворяющих запросам пользователей
при соблюдении бюджета проекта и сроков
его исполнения.
8
В процессе работы несоблюдение сроков и увеличение бюджета
проекта возникают, как правило, при изменении существующих требований, включении новых требований в разработку, высоком уровне
общности требований в техническом задании и отсутствии проработки
их детализации, а также эпизодическом, нерегулярном взаимодействии
с пользователями.
Оценивать трудоемкость и сроки выполнения проекта нужно на основе требований, при этом определяющим становится их объем, сложность и уровень подготовки команды разработчиков.
4. Как уменьшить «разрастание» требований пользователей?
В процессе разработки требования могут меняться, из-за чего
проект часто выходит за установленные рамки как по срокам, так
и по бюджету.
Включение нового требования или изменение имеющихся требова-
зависит от их соответствия и влияния на стратегическое видение
ний
и бизнес-цели проекта, ограничения и критерии успеха. При планировании необходимо предусмотреть резервы бюджета и сроков проекта для
внесения изменений в требования.
В проектах гибкой методологии принято новые требования размещать в резерве и на каждой итерации переопределять приоритет требо-
для их реализации на данной итерации таким образом, чтобы со-
ваний
блюсти сроки и остаться в рамках бюджета проекта.
Изменения требований могут оказать значи-
Важно!
тельное влияние на успех проекта в целом, но на
их реализацию всегда нужно потратить время и
часть бюджета.
5. Как влияет на успех проекта использование
требований «по умолчанию
»?
Давно и успешно работающая команда специалистов, как правило,
имеет широкий профессиональный контекст, что может существенно
влиять на объем материала, помещаемый командой в документацию
проекта. Некоторая часть нужного материала используется в режиме
умолчания, в данном случае как подразумеваемые требования. Члены
команды считают такую информацию очевидной для всех, не учитывая
9
при этом, что у других категорий заинтересованных лиц проекта, скорее
всего, другой контекст. Наличие подразумеваемых требований может
привести к негативным последствиям в работе над проектом.
«Команда разработчиков реализовывала ин-
формационный портал, который должен был
Пример
выполнять много функций, в том числе загрузку,
редактирование и публикацию информации на
веб-сайте.
портале уже было примерно тысяча элементов информации, объ-
В
единенных в иерархию. В команде управления содержимым сайта предполагали, что пользователи получат возможность быстро перемещаться по иерархии и находить нужную информацию.
Члены команды не удосужились сформулировать требование к навигации пользователей по сайту.
Однако когда разработчики реализовали пользовательский интерфейс
для навигации по содержимому в виде одного уровня, а не иерархии, с отображением на странице 20 элементов, были части содержимого, для поиска которого требовалось пролистать свыше 50 страниц» [1, с. 162].
Регулярные совместные обсуждения и анализ
Делаем!
требований всех заинтересованных лиц проекта,
в том числе разработчиков и пользователей, дают
возможность
выявить требования «по умолчанию»
на соответствующем этапе жизненного цикла проекта и избежать значительных переделок в будущем.
6. Почему возникают двусмысленные требования?
Важно!
Заинтересованные лица, в том числе разработчики и пользователи, могут по-разному понимать
одни и те же требования в силу опыта, используе-
мой терминологии и контекста. В этой ситуации
важно анализировать
(и тем более утверждать) только задокументированные требования.
Ответственность за понимание текста возлагается на читателя, а от-
ветственность за успех проекта несет команда разработчиков.
Неоднозначное понимание требований ведет к появлению различающихся ожиданий результата проекта у разных групп заинтересованных лиц. Зачастую результат может быть неприемлемым, при этом
10
Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]