Файл: Практические задания.pdf

6 

Знать:  



основные  факты,  концепции,  принципы  и  теории,  связанные  с  инфор-

матикой; 



теоретические  основы  архитектуры  и  программной  организации  вы-

числительных и информационных систем; 



основы  моделирования  и  анализа  программных  систем,  разработки, 

выявления, спецификации и управления требованиями. 

Уметь:  



разрабатывать и специфицировать требования; 



работать с современными системами программирования; 



оценивать бюджет, сроки и риски разработки программ. 

Владеть: 



языками процедурного объектно-ориентированного программирования; 



навыками разработки и отладки программ на алгоритмических языках 

программирования;  



методами конструирования программного обеспечения и проектирова-

ния человеко-машинного интерфейса; 



методами  и  средствами  разработки  и  оформления  технической  доку-

ментацией. 

Приобрести опыт деятельности  в разработке требований к разработке и 

проектированию программного обеспечения.  

7 

1   Практическое   занятие   №1.  

Введение в разработку и анализ 

требований 

На  основании  изучения  предметной  области,  согласно  варианту  выпол-

нить следующее: 

1. Определить концепцию программного продукта. 

Провести  интервью  с  представителем  заказчика    (инвестором).  Опреде-

лить желания и потребности, определить инструменты разработки и поддерж-

ки,  определить  конфигурацию  оборудования  (задать  не  менее  пяти  вопросов).  

Создать черновик графического интерфейса пользователя.  

2. Осуществить сбор требований с предполагаемым заказчиком. 

Методические рекомендации для выполнения практической работы 

Требования  к  программному  обеспечению –  совокупность  утверждений 

относительно атрибутов, свойств или качеств программной системы, подлежа-

щих реализации. 

Этапы сбора и анализа требований 

Процесс работы с требованиями к продукту можно разделить на 4 этапа: 



Определение концепции продукта. 



Сбор требований. 



Анализ требований. 



Проектирование системы 

Определение концепции продукта 

На этапе определения концепции продукта, проводится работа с его инве-

стором, целью которой является выработка единого видения будущего продук-

та (рис.1).  По окончанию этого этапа производится вывод о том, будет ли этот 

продукт разрабатываться или нет. 

8 

Рисунок 1 – Этапы разработки концепции продукта 

Результатом разработки концепции является Product Vision Document (до-

кумент  образа  продукта,  если  продукт  разрабатывается  под  заказ)  или 

Marketing  Requirement  Document  (документ  рыночных  требований,  если  про-

дукт предназначен для открытого рынка). Эти документы содержат подробную 

информацию о требованиях заказчика, возможностях продукта, которые долж-

ны удовлетворять эти требования, а также ориентировочные сроки его реализа-

ции и бюджет. Различием между PVD и MRD является то, что в MRD обычно 

более  детально  описаны  целевые  сегменты  рынка  и  сделан  детальный  обзор 

конкурентов.  

По окончании разработки концепции продукта делается вывод о целесо-

образности разработки продукта. 

Сбор требований 

На этапе сбора требований основная работа ведется с заказчиком системы 

и еѐ будущими пользователями. Цель этапа  – точно определить функции про-

дукта и способы его интеграции в существующие процессы. 

Качественное выполнение работ на этом этапе гарантирует то, что буду-

щий продукт будет соответствовать ожиданиям заказчика. Четкая расстановка 

приоритетов обеспечивает реализацию наиболее востребованной функциональ-

9 

ности и исключение второстепенной/невостребованной функциональности, что 

сэкономит бюджет и сроки. 

Первым  и  самым  важным  этапом  в  разработке  продукта  является  сбор 

бизнес требований. Цель этой работы – определить основные требования биз-

неса  (исходные  данные,  истинные  цели,  которым  должен  служить  продукт  и 

проблемы, которые нужно преодолеть). 

Для продуктов под заказ и продуктов для открытого рынка процесс сбора 

бизнес требований существенно различается. 

Продукт  под заказ –  заказчик  определен  с самого  начала,  ему  известны 

начальные  предпосылки  (стимулы)  для  инициации  проекта  и  проблемы,  кото-

рые  продукт  должен  решать.  В  связи  с  этим,  сбор  требований  начинается  с 

определения исходных предпосылок, целей продукта и описания сценариев ра-

боты  пользователей  с  будущим  продуктом.  Анализ  конкурентных  продуктов, 

которые могут удовлетворять схожие сценарии, делается в самом конце. 

Продукт  для  открытого  рынка  –  сектор  рынка  с  самого  начала  может 

быть не определен, а цели продукта основываются на конкурентном анализе. 

В  результате,  сразу  за  определением  исходных  предпосылок  (стимулов) 

идет обзор конкурентов, далее идет определение целевого сегмента рынка и по-

требностей его заказчиков и только после этого определяются цели продукта и 

критерии  его  успеха.  Последовательность  задач,  выполняемых  на  этапе  сбора 

бизнес требований для продукта под заказ и для открытого рынка, приведена в 

таблице 1. 

Анализ требований 

На  этапе  анализа  требований  проходит  структуризация  уже  собранных 

ранее  требований.  Цель  этапа  –  предоставить  четкий  список  не  дублируемых 

требований  к  системе,  которые  должны  быть  выделены  из  избыточных  и  ча-

стично дублирующихся сценариев и пользовательских историй, которые были 

полученных на предыдущем этапе. 

10 

Таблица 1 – Последовательность задач, выполняемых на этапе сбора биз-

нес требований 

Продукт под заказ

Продукт для открытого рынка

Определение исходных стимулов

Определение исходных стимулов

Определение целей продукта 
и критериев успеха

Обзор конкурентов 

Определение потребностей клиента

Определение целевого сегмента рынка

Обзор конкурентов

Определение потребностей клиента

Определение целей продукта 
и критериев успеха 

Правильно сгруппированные требования помогут обойтись минимальным 

количеством функционала для удовлетворения максимально большего количе-

ства целей, а это, в свою очередь, поможет сэкономить бюджет и не даст рас-

ползтись рамкам проекта. 

В течение некоторого времени проходили споры относительно того, кому 

«принадлежат»  требования:  заказчику  или  разработчикам.  Для  решения  этого 

вопроса разделяют анализ требований на два уровня. Первый уровень докумен-

тирует желания и потребности заказчика и пишется на языке, понятном заказ-

чику.  Результаты  иногда  называют  требованиями  заказника,  С-требованиями. 

Первичной  аудиторией для  С-требований будет  сообщество  заказчиков,  а  уже 

вторичной – сообщество разработчиков. Второй уровень документирует требо-

вания  в  специальной,  структурированной  форме.  Эти  документы  называются 

требованиями  разработчика,  или  D  –  требованиями  (детальные  требования). 

Первичной  аудиторией  для  D-требований  будет  сообщество  разработчиков,  а 

уже вторичной – сообщество заказчиков.  

Проектирование системы 

Целью всех предыдущих этапов был сбор информации о том, кому и за-

чем необходим будущий продукт. Этап проектирования  – это первый этап, на 

котором группа разработки принимает проектные решения о том, какую функ-