Методы первичного сбора требований. Модели системы. Языки специфики требований. Оценка требований

Министерство образования и  науки Российской Федерации

Федеральное государственное бюджетное  образовательное

учреждение высшего профессионального  образования

«ТВЕРСКОЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ»

 

Математический факультет

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

 

КУРСОВАЯ РАБОТА

по дисциплине “Методы  программирования”

на тему:

 

МЕТОДЫ ПЕРВИЧНОГО СБОРА  ТРЕБОВАНИЙ. МОДЕЛИ СИСТЕМЫ. ЯЗЫКИ СПЕЦИФИКАЦИИ ТРЕБОВНИЙ (СЦЕНАРИИ, PDL, ПОТОКОВЫЕ ДИАГРАММЫ И ДР.). ОЦЕНКА ТРЕБОВАНИЙ (ГОСТ Р ИСО/МЭК 12207)

 

 

Выполнила: студентка 35                                                                     группы математического факультета, специальность Компьютерная безопасность  Сидорова Дарья Александровна   Проверила: доцент кафедры КБиММУ Цирулева Валентина Михайловна

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Тверь,  2013 г.

Оглавление

ВВЕДЕНИЕ 2

МЕТОДЫ ПЕРВИЧНОГО СБОРА ТРЕБОВАНИЙ. 3

Формирование и  анализ  требований. 3

С-требования и D-требования 3

Причины написания требований. 3

Типичная схема процесса анализа требований 4

Преимущества анализа требований и проблемы, связанные с ним. 5

Взаимодействие с заказчиком 6

Методы сбора требований 7

ЯЗЫКИ СПЕЦИФИКАЦИИ ТРЕБОВНИЙ (СЦЕНАРИИ, PDL, ПОТОКОВЫЕ ДИАГРАММЫ) 11

Структурированный язык спецификаций. 11

Создание спецификаций с помощью PDL 12

Сценарии. 13

Сценарии событий 14

Варианты использования 14

Диаграммы потоков данных 14

Диаграммы переходов состояний 15

МОДЕЛИ СИСТЕМ 16

Назначение, недостатки, типы. 16

Модели системного окружения. 17

Поведенческие модели 19

Модели данных 21

Объектные модели 23

Инструментальные CASE-средства 26

ОЦЕНКА ТРЕБОВАНИЙ (ГОСТ Р  ИСО/МЭК 12207) 28

 

Список литературы: 36

 

 

 

 

ВВЕДЕНИЕ

Проблемы, которые  приходится решать специалистам в процессе создания программного обеспечения, обычно очень сложны. Природа этих проблем не всегда ясна, особенно если разрабатываемая программная система инновационная. В частности, трудно четко описать те действия, которые должна выполнять система. Описание функциональных возможностей и ограничений, накладываемых на программную систему, называется требованиями к этой системе, а сам процесс формирования, анализа, документирования и проверки этих функциональных возможностей и ограничений — разработкой требований (requirements engineering). Здесь внимание концентрируется на самих требованиях и способах их описания,  языках спецификации требований и основных моделях системы.

Также мы рассмотрим нормативные документы, применяемые  при разработке программного обеспечения, а именно ГОСТ Р ИСО/МЭК 12207

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

МЕТОДЫ ПЕРВИЧНОГО СБОРА ТРЕБОВАНИЙ.

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

Чтобы создать  какую-либо систему нам нужно  понять, что она должна из себя представлять, чем она должна быть. Процесс понимания, сбора, систематизации и  документирования всех данных называется анализом (сбором) требований.

Процесс формирования и анализа требований является одним из самых главных этапов разработки программного обеспечения. На этом этапе команда разработчиков ПО работает с заказчиком и конечными пользователями системы для выяснения области применения, описания системных сервисов, определения режимов работы системы и ее характеристик выполнения, аппаратных ограничений и т.д, т.е. требования обычно выражают, что приложение должно делать, а вопрос о том,  как это сделать не затрагивается. Результатом анализа требований является документ, который обычно называют спецификацией требований, или спецификацией требований к программному обеспечению.

С-требования и D-требования

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

Первый уровень  документирует желания и потребности  заказчика и пишется на языке, понятном заказчику. Результаты иногда называют требованиями заказчика, или С-требованиями. Первичной аудиторией для С-требований будет сообщество заказчиков, а уже вторичной - сообщество разработчиков.

Второй уровень  документирует требования в специальной, структурированной форме. Эти документы называются требованиями разработчика, или D-требованиями. Первичной аудиторией для D-требований будет сообщество разработчиков, а уже вторичной — сообщество заказчиков.

Хотя целевые  аудитории для С- и D-требований различны, заказчики и разработчики тесно сотрудничают при создании успешных продуктов. Один из способов, позволяющих обеспечить хорошее взаимодействие, — совместная работа представителей заказчика и разработчиков. Некоторые организации-разработчики даже отказываются браться за работу без предоставления такой возможности.

Причины написания требований.

Даже новичку  может показаться очевидным, что  следует письменно формулировать, как должна вести себя завершенная программа. Однако этот процесс написания часто игнорируется или делается с ошибками. В таких случаях иногда считают, что исходный код выражает все требования: поскольку мы не можем обойтись без исходного кода, почему бы не свести весь процесс к этому единственному документу? Ответ на этот вопрос — так не пойдет. Теория разработки программ и самые опытные инженеры настаивают на аккуратном документировании требований. Без таких документов команда практически не знает, каких целей она пытается достичь, не может корректно проверить свою работу, проследить свою производительность, получить адекватные данные по своей работе, предсказать объем и усилия в своей следующей работе и удовлетворить своих заказчиков. Короче говоря, не может быть профессиональной разработки без письменных требований.

Ниже приведен список действий, которые следует  выполнить для этого и других требований. Каждое требование должно:

• быть четко выражено;
• быть легко доступно;
• быть пронумеровано;
• сопровождаться подтверждающими тестами;
• предусматриваться проектом;
• быть учтено кодом;
• быть протестировано отдельно;
• быть протестировано вкупе с другими требованиями;
• быть подтверждено тестированием после того, как выполнена сборка приложения.

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

Типичная  схема процесса анализа требований

Типичная  схема процесса анализа и сбора С-требований, на рисунке ниже. На каждой итерации мы будем заново смотреть на эту схему. На последнем шаге схемы предусматривается сбор детальных D-требований — процесс, описанный в следующей главе. Команда проводит измерения по стадиям процесса, чтобы дать возможность оценить будущие итерации и будущие приложения.

 

Рис. 1 Схема для С-требований заказчика.

  Преимущества анализа требований и проблемы, связанные с ним.

Несовершенные требования (то есть не исправленные до полного  завершения документа) обходятся очень  дорого. По оценкам, их в 20-50 раз дороже исправить, если они попали в процесс разработки. Убытки, связанные с отрицательным опытом работы заказчика с приложением, являются добавочным фактором при оценке расходов.

Почему же так много  проектов понесло убытки от скудного или не проведенного анализа требований, если известна значительная прибыль от обнаружения ошибок во время формулирования? Основная причина заключается в том, что заказчики обычно не знают в начале проекта, чего они хотят или в чем нуждаются. Инженеры, использующие хорошо организованный итерационный процесс, собирают требования, проводят проектирование и выполняют реализацию согласованными итерациями.

Анализ требований —  это необходимость, а не роскошь. Давайте убедимся в его эффективности  на примере. Большинство организаций-разработчиков  считают тестирование абсолютно  необходимым. Но если бы кто-то дал вам  просто черный ящик с одним фиолетовым, одним розовым и одним оранжевым колесиком и попросил вас протестировать этот ящик, вы бы, наверное, отказались. Тестирование было бы невозможным, если вы не знаете, что должно произойти! Другими словами, без требований продукт нельзя протестировать должным образом.

Многие организации не справляются с написанием требований. Это не значит, что они не пользуются требованиями — это только означает, что требования существуют в головах конкретных разработчиков приложения. После того как определены неэффективность незаписанных требований, наличие большого числа требований к каждому конкретному приложению и реалии текучести кадров, остаются ли еще вопросы относительно того, почему большая часть программных проектов никогда не доводится до конца? Более острая проблема создается организациями, которые пишут требования для начальной итерации, начинают по ним разработку, но не поддерживают изменения в документе с требованиями на последующих итерациях. Причина в том, что часто труднее обновить документ с требованиями, чем написать его первую версию. (Это подчеркивает важность хорошей организации документа с требованиями.) Тот факт, что обновление может быть более сложной задачей, однако, не отменяет банального утверждения о том, что неспособность сформулировать требования создаст очень много проблем.

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

Большинству из нас говорили, что «писать — значит думать», и частично это справедливо при  формулировании требований. Довольно много разработчиков пытаются избежать формулирования требований, нетерпеливо  приступая прямо к написанию  кода. По опыту автора книги один разработчик, отрицательно относящийся к процессу, вдруг начинает производить поразительное количество кода. Затем он объявляет команде: «Я выполнил свою часть — теперь вы, ребята, можете тратить свое время на составление всех сопровождающих документов. А я пошел». Такое кодирование сравнимо с выливанием тонн бетона для постройки моста, не зная, откуда и куда он должен в итоге быть построен (не говоря уже о его финальном дизайне). Автор считает, что нежелание писать требования связано не с тем, что написание считается слишком простым, чтобы о нем беспокоиться, а с тем, что корректное написание требований на самом деле довольно сложно. Конкретные, реалистичные и измеряемые процедуры для написания требований являются профессиональным испытанием.

Взаимодействие  с заказчиком 

Определение заинтересованных лиц

Люди, имеющие  долю в результирующем продукте, называются людьми, финансово заинтересованными в проекте. Вообще говоря, они являются заказчиками приложения. Как пример, представьте себе создание сайта для электронной коммерции. Один набор финансово заинтересованных лиц состоит из посетителей сайта: их типичное первое требование — легкость, с которой они могут найти и купить необходимые товары. Владельцы компании также финансово заинтересованные лица: их основным требованием может быть прибыльность, краткосрочная или долгосрочная. По этой причине они, возможно, захотят, чтобы на сайте был сделан акцент на дорогих товарах. Менеджеры — другая группа финансово заинтересованных лиц — могут потребовать, чтобы приложение вело учет посетителей. Разработчики приложения также являются финансово заинтересованными: они могут захотеть рискнуть использовать новую технологию, чтобы идти в ногу со временем.

В случае готовых  к употреблению («коробочных») приложений, таких как системы обработки  текстов, электронные таблицы и  среды разработки, разработчики уделяют основное внимание доступности приложения как можно большему числу пользователей. Хотя это может быть сложной рыночной проблемой, очевидно, что пользователи являются наиболее значительными финансово заинтересованными лицами. Для большинства крупных проектов, однако, определение наиболее важных финансово заинтересованных лиц является сложной проблемой. Заказчик часто является стороной, оплачивающей разработку приложения, но даже это не всегда корректно. Например, морской флот может платить за разработку, но каждодневными заказчиками разработчиков могут быть государственные служащие, а не морские офицеры. Но тогда разве не являются налогоплательщики заказчиками, поскольку на самом деле это они платят за приложение? Заказчиком субподрядчика является основной подрядчик. Заказчиком коробочного приложения — множество потенциальных покупателей, установленное отделом маркетинга. Когда приложение разрабатывается для внутреннего использования в компании, такого как обработка заявок в страховой фирме, заказчиком является сама компания.

Конфликтующие интересы финансово заинтересованных лиц могут легко привести к противоречивым требованиям. Пример этого — когда две разных группы в компании по разным мотивам заказывают «одно и то же» приложение. Как результат, требования могут быть не согласованными. Когда требования нельзя согласовать, проекты имеют тенденцию продвигаться с трудом и часто прекращаются. Даже когда требования финансово заинтересованных лиц согласованы, они могут быть слишком дорогими, чтобы их полностью удовлетворить.