CC BY
1222
Управление требованиями к программному обеспечению для поддержки контроля достижения целей
В.О. Каковский, Т.Н. Заболотняя кафедра программного обеспечения компьютерных систем, Национальный технический университет Украины «Киевский политехнический институт» г. Киев, Украина slavkoff@ gmail. com
Аннотация. Данная статья посвящена вопросу управления требованиями к программному обеспечению, предназначенному для поддержки контроля достижения целей, а именно решению задач идентификации, анализа и документирования требований к ПО, являющихся составляющими процесса управления требованиями, с целью разработки спецификации требований к программному обеспечению (SRS). На основании результатов исследования существующих программных средств, используемых для учета целей, а также анализа отзывов их пользователей сформулированы требования к разрабатываемой системе.
Ключевые слова: выбор задач для исполнения, контроль достижения целей, управление задачами, управление требованиями.
Актуальность прикладной задачи
Ежедневно миллионам людей приходится сталкиваться с большими объемами информации - начиная от специализированной литературы и заканчивания новостями в социальных сетях. Соответственно, возрастает и количество задач, связанных с обработкой этих данных и принятием необходимых решений. По мнению авторов, наиболее актуальной для человека является та информация, использование которой влияет на скорость достижения поставленных им целей. К этим сведениям относятся:
1. Информация о поставленной цели - желательно, чтобы цель соответствовала SMART-критериям [1] (тогда ее достижение проще всего отслеживать).
2. Перечень шагов или действий, которые следует предпринять для достижения данной цели.
3. Данные о выполненных и начатых задачах, которые описывают текущее соостояние достигаемой цели и позволяют оценивать прогресс.
Анализируя эти сведения, человек имеет возможность выбрать для выполнения именно те приоритетные задачи, успешное завершение которых приведет к достижению необходимого результата.
Автоматизация обработки вышеописанных данных должна предоставить возможность оперативного получения ответа на вопрос «что я должен сделать в ближайшее время для достижения этой цели». Особенно важным это становится тогда, когда выделение подобной информации из обширного потока входных данных перестает быть тривиальной задачей.
Таким образом, разработка программного обеспечения, в функции которого входят поддержка учета шагов, направленных на достижение целей, приоритизация этих шагов, а также оценка прогресса в получении необходимого результата, является актуальной задачей.
Для того, чтобы разрабатываемое ПО удовлетворяло потребностям пользователей, необходимо тщательно определить требования к системе. Решению именно этой задачи посвящена статья.
Классификация требований к ПО
В соответствии со стандартом разработки требований ISO/IEC 29148, требование — это утверждение, которое идентифицирует эксплуатационные, функциональные параметры, характеристики или ограничения проектирования продукта или процесса, а также является однозначным, проверяемым и измеримим.
Существует несколько подходов к классификации требований, выдвигаемых к программному обеспечению:
1. Классификация требований согласно SWEBOK [2] выделяет следующие категории: требования к продукту и процессу его создания, функциональные и нефункциональные, системные требования, а также независимые свойства (требования, которые не могут быть адресованы одному из компонентов системы, а проявляются при их взаимодействии).
2. Схема Лефингвелла [3] отражает подход, рекомендованный RUP, и имеет следующие уровни требований: потребности, характеристики продукта (features) и, собственно, требования к ПО.
3. Модель Вигерса [4] является удобным способом организации представления и группировки требований.
Рис. 1. Уровни требовании согласно модели Вигерса
В качестве основы для определения спецификации требований к разрабатываемому ПО авторами выбран именно последний упомянутый подход, т.к. модель Карла Вигерса позволяет отобразить требования на структуры документов, определяемые методологиями и стандартами IEEE 830, ГОСТ 34.
Основная идея классификации требований согласно модели Вигерса базируется на определении групп (функциональные, нефункциональные) и уровней требований к продукту (см. рис. 1).
Верхний уровень описывает саму задачу или проблему, которая должна быть решена, благодаря системе. Суть этих бизнес-требовании сводится к постановке задачи и описанию назначения програмного обеспечения в повествовательной форме; называется этот документ концепцией проекта (Vision Document).
Следующий уровень - пользовательские требования (User Requirements), которые детально описывают цели/задачи пользователей системы, которые должны достигаться/выполняться пользователями при помощи создаваемой программной системы. Эти требования часто представляют в виде диаграмм вариантов использования (Use Cases).
Нефункциональные требования этого же уровня - это бизнес-правила и атрибуты качества. Бизнес-правила (Business Rules) - требования, которые основываются на корпоративных регламентах, политиках, стандартах, законодательных актах, алгоритмах, и т.д. Атрибуты качества (Quality Attributes) -дополнительные характеристики продукта, важные для пользователей и/или разработчиков. Функциональные и нефункциональные требования второго уровня описываются в Спецификации вариантов использования (Use Case Document).
Третий уровень требований - собственно функциональные требования и системные требования. Функциональные требования (Functional Requirements) -определяют функциональность (поведение) программной системы, которая должна быть создана разработчиками для предоставления возможности выполнения пользователями своих обязанностей в рамках бизнес-требований и в контексте пользовательских требований. Системные требования (System
Requirements) классифицируются как составная часть группы функциональных требований и описывают высокоуровневые требования к программному обеспечению, содержащему несколько или много взаимосвязанных подсистем и приложений.
Существуют следующие виды нефункциональных требовании этого уровня:
1. Ограничения (Constraints) - условия, ограничивающие выбор возможных решений по реализации отдельных требований или их наборов.
2. Внешние интерфейсы (External Interfaces) - требования, которые содержат конкретизацию аспектов взаимодействия разрабатываемого ПО с другими системами, например, операционной средой, аппаратным оборудованием, пользователями и т.д.
Все вместе функциональные требования и нефункциональные требования составляют последнюю ступень модели Вигерса - Спецификацию требований к программному обеспечению (Software Requirement Specification).
В данной статье основное внимание уделено выявлению и формулировке требований первых двух уровней модели Вигерса, так как их достаточно для понимания общей картины функционирования ПО. Получение конечного программного продукта не является целью исследования, поэтому требования третьего уровня тут не определены.
Ниже приведены рекомендации к разрабатываемому ПО, на основании которых в данной статье сформулированы требования двух вышеупомянутых уровней модели Вигерса.
Характеристики ПО
Вначале определим базовые понятия предметной области, используемые далее в статье.
Веха - контрольная точка или ключевой момент (например, переход к следующей фазе) во время достижения цели.
Декомпозиция - процесс, в результате которого решение сложной проблемы представляется в виде решения серии более простых взаимосвязанных задач.
Задача - деятельность, которая должна быть завершена в указанный срок.
Игрофикация - применение подходов, характерных для компьютерных игр, в программных инструментах для неигровых процессов с целью повышения вовлечённости пользователей в решение прикладных задач [5].
Цель - является желаемым результатом действия или действий человека.
Ценность - любое явление, которое имеет значение для человека; то, ради чего он действует, тратит силы и живет. Примеры ценностей: здоровье, семья, дружба, самореализация, работа, социальный статус, свобода, материальное благосостояние.
В результате исследования предметной области, проведенного ранее авторами [6], были определены следующие рекомендации, которые целесообразно принять во внимание при разработке нового ПО для поддержки контроля достижения целей:
1. Соответствие целей методике SMART и возможность присвоения задачам приоритета. Приоритет задачи является именно тем критерием, на который можно опираться при выборе задач для выполнения среди множеств возможных вариантов.
2. Обеспечение управления как целями, так и задачами, выполнение которых приближает к достижению желаемого результата. Удобным является выделение вех. Декомпозиция цели на задачи позволяет получить список простых шагов, отслеживание выполнения которых делает возможным наблюдение за прогрессом в целом.
3. Поддержка работы програмного обеспечения в наиболее распространенных операционных системах (Linux, Windows, Mac OS).
4. Возможность просмотра прогресса по достижениюкак конкретной цели, так и группы целей, которые соответствуют одной и той же жизненной ценности.
5. Возможность просмотра ожидаемой загруженности человека на определенный период времени. Позволяет оценить вероятность достижения определенной цели или выполнения задач в течение определенного промежутка времени. Данный функционал должен учитывать все актуальные цели и задачи.
Также после изучения возможностей существующих программных средств был определен перечень дополнительных функций, которые стоит реализовать в ПО, предназначенном для поддержки контроля достижения целей:
1. Интеграция с Google Calendar - позволит визуализировать задачи и вехи в виде событий на календаре.
2. Возможность выбора цели из определенного списка популярных целей, который формируется пользователями ресурса.
3. Наличие настраиваемого генератора отчетов, который позволит получить статистику по целям и задачам.
В следующем разделе статьи описанные выше рекомендации преобразованы в требования к программной системе для поддержки контроля достижения целей.
Формализованные требования к системе
Первый уровень требований
Бизнес-требования к системе можно представить в виде Vision: Программное обеспечение предназначено для поддержки контроля достижения целей. ПО должно предоставить возможность хранить информацию о целях, которые соответствуют SMART-критериям. Информация о цели включает данные о тех задачах, выполнение которых ведет к достижению результата. ПО позволит планировать путь достижения цели, отслеживать прогресс в получении необходимого результата, а так же оценивать ожидаемую загруженность человека в определенный период времени. Система должна быть реализована в виде веб-приложения.
Как видим, бизнес-требования к системе полностью совпадают с постановкой задачи разработки, приведенной выше.
Второй уровень требований. Функциональные требования
Требования пользователей удобно сопровождать диаграммами вариантов использования (Use Case). Для разрабатываемого ПО определен следующий перечень вариантов использования:
1. Ознакомиться с информацией о возможностях системы
2. Зарегистрироваться
3. Авторизоваться
4. Пройти интерактивный тур
5. Работать с главным меню
6. Управлять данными о ценностях, целях, задачах
7. Вносить данные о выполненных задачах и достигнутых целях
8. Управлять статистикой.
Диаграммы вариантов использования системы, которые несут наибольшую тематическую нагрузку, приведены ниже.
Use Case 1: "Пройти интерактивный тур". После первой авторизации пользователю предлагается пройти интерактивный тур по возможностям приложения (см. рис. 2). Тур состоит из следующих шагов:
1. Пользователь определяет жизненные ценности, к которым будут относиться цели.
2. Пользователь вносит в систему информацию о SMART-целях и мечтах (цели, которые не соответствуют критериям SMART).
3. Пользователь совершает декомпозицию целей на задачи.
В результате прохождения тура пользователь ознакамливается с ключевыми функциями ПО. Также в любой момент использования системы он имеет возможность снова пройти этот тур.
О—-о
Определить Выполнить
цели декомпозицию
целей на задачи
Рис. 2. UseCase "Пройти интерактивный тур"
Use Case 2: "Управлять данными о ценностях" - описывает работу пользователя с объектом класса «ценность» (см. рис. 3).
1. Пользователь просматривает список ценностей.
2. Пользователь создает/редактирует/удаляет экземпляр класса ценность.
3. Пользователь просматривает список целей, которые соответствуют выбранной ценности.
4. Пользователь просматривает статистику о ценности.
Структура объектов (ценности-цели-задачи) системы для поддержки контроля управления целей реализована в веб-приложении Lifetick [7].
Рис. 3. Use Case "Управлять ценностями"
Рис. 4. Use Case "Управлять целями"
Use Case 3: "Управлять данными о целях" - описывает работу пользователя с объектом класса «цель» (см. рис. 4).
1. Пользователь просматривает список целей.
2. Пользователь создает/редактирует/удаляет экземпляр класса «цель».
3. Пользователь отмечает цель как уже не актуальную, то есть блокирует ее.
4. Пользователь просматривает список задач, которые соответствуют выбранной цели.
5. Пользователь просматривает статистику о цели.
Use Case 4: "Управлять задачами" - описывает работу пользователя с объектом класса «задача» (см. рис. 5).
1. Пользователь просматривает список задач.
2. Пользователь создает новые списки задач.
3. Пользователь создает/редактирует/удаляет экземпляр класса задача.
4. Пользователь отмечает цель как неактуальную (блокирует ее).
5. Пользователь просматривает статистику о задаче или списке задач.
Use Case 5:"Управлять статистикой" - описывает работу пользователя со статистикой (см. рис. 6).
1. Пользователь просматривает общую статистику достигнутых целей.
2. Пользователь просматривает прогресс.
3. Пользователь просматривает данные о планируемой загруженности.
Функционал «просмотр планируемой загруженности» является уникальным относительно проанализированных систем.
Use Case 6: "Работать с главным меню" - описывает навигацию по системе (см. рис. 7).
1. Пользователь управляет объектами (ценностями, целями, задачами).
2. Пользователь управляет статистикойданных о достижении целей.
3. Пользователь формирует список задач для исполнения.
4. Пользователь просматривает календарь событий.
Реализация функции «Сформировать список задач для исполнения» обеспечивает оперативное получение ответа на вопрос «что я должен сделать в ближайшее время для достижения своих целей».
Второй уровень требований. Нефункциональные требования Бизнес-правило в системе одно - целями являються только те цели, которые можно поставить в соответствии критериям SMART.
Рис. 5. Use Case "Управлять задачами"
Рис. 6. Use Case "Управлять статистикой"
Смотреть календарь
Рис. 7. Use Case "Работать с главным меню "
Атрибуты качества описывают важные для пользователей характеристики продукта. Отметим, что требования, описываемые в этом разделе, сделаны на основе приведенных выше рекомендаций к ПО, поэтому они не содержат всех без исключения видов требований, выделяемых в теории (например, требований к времени хранения данных или к доступности системы).
Требования к безопасности приложения описаны в табл. 1.
Таблица 1. Требования к безопасности
Код Описание требования
SE-1 Учетные данные пользователей должны храниться в зашифрованном виде.
SE-2 Приложение должно обеспечивать защиту от выполнения стороннего кода (DB Injection, XSS, CSRF).
SE-3 Приложение должно производить проверку всех данных, поступающих от пользователя.
SE-4 Личные данные пользователя должны быть доступны для чтения и редактирования только ему.
Надежность приложения зависит от конфигураций сервера, исполняющего
серверный код приложения.
Требования к удобству использования представлены в табл. 2. Требования к производительности приложения представлены в табл.3.
Таблица 2. Требования к удобству использования
Код Описание требования
US-1 Для авторизованного пользователя на каждой странице веб-приложения должно присутствовать меню, которое позволяет попасть к каждому из функциональных разделов веб-приложения не более, чем за 3 перехода.
US-2 Для мотивации пользователей к достижению своих целей в системе должны быть использованы элементы игрофикации.
Таблица 3. Требования к производительности
Код Описание требования
PE-1 Максимальное время полной загрузки страницы, которая является результатом запроса пользователя к серверу, при использовании Интернет-подключения со скоростью ЗМбит/сек - 4 секунды.
PE-2 Максимальное количество одновременных подключений к веб-приложению -1000.
PE-3 Необходимо обеспечить кросплатформенную работу приложения. Поддерживаемые ОС - Windows (2000 и выше), Linux, Mac OS.
PE-4 Необходимо обеспечить адекватную работу приложения в следующих версиях браузеров: Google Chrome версии 15.0.874 и выше, Mozilla Firefox 8.0 и выше, Opera 12.00 и выше, Safari 5.1.1 и выше.
Ограничения. Апаратное обеспечение состоит из сервера, с установленной операционной системой FreeBSD, который удовлетворяет следующим требованиям:
1. Мощность центрального процессора - 2 GHz.
2. Объем оперативной памяти - 2 GB.
3. Свободное место на диске, выделенное для кода и файлов приложения - 10GB.
Компьютер пользователя веб-приложения должен отвечать следующим требованиям:
1. Наличие установленой одной из операционных систем Windows (2000 и выше), Linux, Mac OS;
2. Наличие одного из браузеров: Google Chrome версии 15.0.874 и выше, Mozilla Firefox 8.0 и выше, Opera 12.00 и выше, Safari 5.1.1 и выше;
3. Наличие подключения к Интернет.
Модульность. Компоненты приложения необходимо реализовать в виде подключаемых модулей.
Остальные атрибуты качества в статье не определены, т.к. они не являются существенными для эффективной работы ПО.
Выводы
В данной статье сформулированы требования к ПО для поддержки контроля достижения целей, соответствующие двум верхним уровням модели К.Вигерса. Наличие этих данных существенно упрощает последующую разработку системы, поскольку система, которую разработают программисты, будет соответствовать потребностям пользователей.
Требования, описанные в статье, могут быть основой для построения требований третьего уровня модели Вигерса, которые, в свою очередь, лягут в основу разработки SRS, определения структурно-алгоритмической организации ПО, а также рекомендаций по его тестированию.
Список литературы
1. Meyer P. Attitude Is Everything: If You Want to Succeed Above and Beyond.
Waco : Meyer Resource Group, 2003, p. 26.
2. ISO IEC TR 19759 - 2005, Software Engineering - Guide to the Software
Engineering Body of Knowledge (SWEBOK). URL:
http://materjalid.tmk.edu.ee/heikki_eljas/SWEBOK.pdf (дата обращения: 22.01.2013).
3. Леффингуэлл Д., Уидриг Д. Принципы работы с требованиями к программному обеспечению. Унифицированный подход. М.: Вильямс, 2002. 448 с.
4. Вигерс К. Разработка требований к программному обеспечению, М. : Русская редакция, 2004. 576 с.
5. Cunningham C., Zichermann G. Gamification by Design: Implementing Game Mechanics in Web and Mobile Apps. Sebastopol, California : O'Reilly Media, 2012, p. 288.
6. Каковський В.О. До питання вибору програмного забезпечення для тдтримки контролю досягнення цшей // МХжнародна науково-практична конференщя астрант!в i студенпв «1нженерХя програмного забезпечення 2012»: Зб. тез доповвдей. - К., 2012. С. 15.
7. Lifetick. Online goal setting software. URL: http://lifetick.com (дата обращения: 22.01.2013).
