Методы и средства выявления и представления требований к разработке ПО - Дипломная работа

ГЛАВА 1. ТРЕБОВАНИЕ КАК СВОЙСТВО ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ 1.1 Понятие требования к разработке ПО. Предложение расширенной классификации с дополнительными атрибутами 1.3 Определение основных заинтересованных лиц проекта ГЛАВА 2. ПРОЦЕСС ВЫЯВЛЕНИЯ ТРЕБОВАНИЙ К РАЗРАБОТКЕ ПО ДЛЯ ИХ ПОСЛЕДУЮЩЕГО АНАЛИЗА 2.1 Стадии разработки программного обеспечения. Место этапа выявления требований 2.2 Предложение общего подхода к выявлению требований 2.3 Основные источники требований ГЛАВА 3. МЕТОДЫ И СРЕДСТВА ВЫЯВЛЕНИЯ И ПРЕДСТАВЛЕНИЯ ТРЕБОВАНИЙ 3.1 Анализ существующих методов и средств выявления требований 3.1.1 Интервьюирование заинтересованных лиц 3.1.2 Анкетирование заинтересованных лиц 3.1.3 Наблюдение за бизнесом заказчика 3.1.4 Изучение документов и программных систем 3.1.5 Современные методы выявления требований 3.2 Согласование и проверка обоснованности требований 3.3 Достоинства и недостатки основных существующих методов выявления и представления требований 3.4 Комбинированный подход выявления и представления требований. Структуризация требований в базе знаний на основе расширенной классификации 3.4.1 Моделирование целей и стратегий бизнеса 3.4.2 Моделирование бизнес-процессов компании ЗАКЛЮЧЕНИЕ БИБЛИОГРАФИЧЕСКИЙ СПИСОК ОБЩАЯ ХАРАКТЕРИСТИКА РАБОТЫ Актуальность темы магистерской диссертации. Опыт индустрии информационных технологий однозначно показывает, что вопросы, связанные с управлением требованиями, оказывают критически-важное влияние на программные проекты, в определенной степени - на сам факт возможности успешного завершения проектов [1]. Недопонимание между аналитиком и пользователем, упущение тех или иных аспектов, на первый взгляд кажущихся второстепенными, неоднозначность или тем более некорректность интерпретации информации, полученных от пользователей - все это наиболее типичные причины сверх затрат (времени, денег и т.п.), а иногда, и полного провала проектов. Тем не менее многие организации до сих пор применяют неэффективные методы на стадии анализа требования, в частности, на этапе их выявления и сбора. Типичный исход данного подхода - неожидаемые пробелы в функционале ПО, а также различия между тем, что разработчики собираются реализовать и тем, в чем клиенты реально нуждаются. В связи с этим изучение и анализ возможных процессов этапа выявления требований и предложение эффективного метода их выявления и представления, позволяющего снизить ошибки в требованиях на этапе их выявления, свидетельствуют об актуальности выбранной темы магистерской диссертации «Методы и средства выявления и представления требований к разработке ПО». Удельная стоимость их исправления быстро растет по мере продвижения продукта к стадии эксплуатации. В различных литературных источниках указывается, что стоимость исправления дефекта допущенного при определении требований после ввода системы в эксплуатацию от 100 до 1000 (в зависимости от масштаба проекта) раз превышает аналогичную стоимость исправления допущенной ошибки в период непосредственной разработки требований. Требования анализируются, в них вносятся изменения, они пересматриваются и утверждаются. Это первая стадия формирования видения автоматизирования бизнес-процессов, при которой формулируются цели и задачи проекта, выделяются основные сущности и связи между ними. Определение и извлечение требований. программный обеспечение требование бизнес Определение требований и их назначения описываются во многих стандартах программной инженерии, основные из которых представлены на рисунке 1. Существуют различные методики выявления требований, которые будут подробно рассматриваться в следующих главах диссертации. Классический пример высокоуровневого структурирования групп требований как требований к продукту описан в работах одного из классиков дисциплины управления требованиями - Карла Вигерса [2]. Пример требования пользователя: система должна представлять диалоговые средства для ввода исчерпывающей информации о заказе, последующей фиксации информации в базе данных и маршрутизации информации о заказе к сотруднику, отвечающему за его планирование и исполнение.