Поможем в ✍️ написании учебной работы

Имя

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

Выберите тип работыЧасть дипломаДипломная работаКурсовая работаКонтрольная работаРешение задачРефератНаучно - исследовательская работаОтчет по практикеОтветы на билетыТест/экзамен onlineМонографияЭссеДокладКомпьютерный набор текстаКомпьютерный чертежРецензияПереводРепетиторБизнес-планКонспектыПроверка качестваЭкзамен на сайтеАспирантский рефератМагистерская работаНаучная статьяНаучный трудТехническая редакция текстаЧертеж от рукиДиаграммы, таблицыПрезентация к защитеТезисный планРечь к дипломуДоработка заказа клиентаОтзыв на дипломПубликация статьи в ВАКПубликация статьи в ScopusДипломная работа MBAПовышение оригинальностиКопирайтингДругое

Нажимая кнопку "Продолжить", я принимаю политику конфиденциальности

Производительность

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

Надежность и доступность

Надежность – это вероятность работы системы без сбоев в течение определенного времени. Для измерения надежности может быть использовано среднее время работы системы до сбоя.

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

Безопасность

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

Удобство и простота обслуживания

Этот атрибут связан с большим числом факторов, определяющих, по словам пользователей, дружелюбие системы к пользователю. Другими словами система должна использоваться эффективно и необременительно. Достаточно подробно эти характеристики, определяющие практичность системы рассмотрены в [4].

 

Для разработчиков и специалистов по обслуживанию от системы требуются другие характеристики. Приведем некоторые из таких атрибутов качества.

Легкость сопровождения и эксплуатации

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

Мобильность

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

Повторное использование

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

Тестируемость

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

1.2.2.2. Нефункциональные требования к процессу

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

1.2.2.3. Внешние нефункциональные требования

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

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

Требования должны удовлетворять определенным характеристикам качества. Основные характеристики – это полнота, корректность, необходимость, осуществимость, приоритет, недвусмысленность, непротиворечивость (согласованность), проверяемость и прослеживаемость (см. рис. 1.1).

Рис. 1.1

Полнота и корректность

Требование должно полно и точно описывать функцию, которую необходимо реализовать в продукте, содержать всю необходимую для разработчиков информацию. Контроль над корректностью требований возлагается на пользователей, т.к. только требование, согласующееся с источником (пожеланиями пользователей) считается корректным.

Приоритет

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

Анализ предметной области

Одна из первых задач, с решением которых сталкивается разработчик программной системы – это изучение, осмысление и анализ предметной области. Дело в том, что предметная область сильно влияет на все аспекты проекта: требования к системе, взаимодействие с пользователем, модель хранения данных, реализацию и т.д.

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

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

Функциональная область действия определяет услуги, предоставляемые системой, и вначале до конца неизвестны. В определении услуг системы может помочь список «Действующее лицо/Цель», в котором перечислены все цели пользователя, поддерживаемые системой. При его разработке в первую графу вписываются имена основных действующих лиц, т.е. тех, кто имеет цели, во вторую графу – цель каждого действующего лица, а в третью – приоритет или предположение о том, в какую версию войдет эта услуга.

Для определения основных функций продукта можно использовать, например, краткое описание варианта использования. Описание каждой функции можно представить также в виде списка, состоящего из трех граф: действующее лицо, цель и краткое описание варианта использования.

Анализ предметной области является основой для анализа осуществимости проекта и определения образа (концепции) продукта и границ проекта.

Анализ осуществимости

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

1. Отвечает ли система бизнес-целям организации-заказчика и организации-разработчика?

2. Можно ли реализовать систему, используя известные технологии и не выходя за пределы заданной стоимости и заданного времени?

3. Можно ли объединить систему с другими уже эксплуатируемыми системами?

Для ответа на первый (и главный) вопрос нужно опросить заинтересованных лиц, например, менеджеров подразделений, в которых будет использоваться система, для выяснения того,

· что произойдет с организацией, если система не будет введена в эксплуатацию;

· как система будет способствовать целям бизнеса;

· какие текущие проблемы поможет решить система и т.д.

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

Вопросы для самоконтроля

1. Каковы основные цели анализа предметной области?

2. Как используется методика «будет – не будет» при определении области действия проекта?

3. Кто выполняет анализ предметной области?

4. Для каких программных систем должен проводиться анализ осуществимости?

5. Что определяют бизнес-требования и бизнес-правила?

6. Почему пользовательские и функциональные требования должны соответствовать бизнес-требованиям?

7. Что определяет образ продукта и границы проекта?

8. Перечислите основные разделы документа, описывающего образ продукта и границы проекта?

3. Выявление требований

Изучив тему, Вы будете знать:

§ источники возникновения требований;

§ основные процессы разработки требований и отношения между ними;

§ методы формирования и анализа требований.

При освоении темы необходимо акцентировать внимание:

§ на источниках возникновения требований;

§ на проведении интервью и совместных семинаров;

§ на определении ролей и выполнении правил проведения сеансов ”мозгового штурма”;

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

§ на выявлении различных точек зрения.

3.1. Определение способа сбора и анализа требований

3.1.1. Источники возникновения требований

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

· требования, определяемые предметной областью;

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

Под требованиями, определяемыми предметной областью здесь понимаются ограничения, накладываемые на программную систему законами природы и, которые поэтому нельзя изменить. Источниками остальных требований являются люди. Чем меньше объективных ограничений имеет проблема, тем большее количество ее ограничений должно быть получено от людей. Для большинства распространенных («офисных») приложений этот источник поставляет более 80% требований.

Опрос (интервью)

Проведение опроса состоит из трех этапов: подготовка опроса, его проведение и определение последующих действий [9, 10].

Подготовка

При подготовке опроса должны быть разработаны вопросы, выбраны опрашиваемые пользователи и спланированы контакты.

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

Обычно имеется несколько заинтересованных в разработке лиц (групп лиц), ценность системы для которых, определяется различными ее характеристиками, например:

· повышение производительности;

· повышение надежности;

· снижение себестоимости;

· легкость и простота использования и т.д.

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

Для определения групп заинтересованных лиц нужно понимать, что их можно классифицировать по различным признакам, например:

· по правам доступа к системе, например администратор и обычный пользователь;

· по частоте использования системы;

· по опыту в предметной области;

· по опыту работы с компьютерными системами и т.д.

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

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

· объяснить цель встречи, каким образом данный человек попал в перечень участников опроса;

· подчеркнуть, что он является тем человеком, который может дать правильные ответы на вопросы;

· указать продолжительность интервью;

· согласовать способ записи опроса и т.д.

Проведение опроса

Опрос можно провести по телефону, при помощи Internet, но наиболее эффективный способ – это личная встреча, которая позволяет создать правильную атмосферу, обеспечивающую комфорт участников.

Для создания атмосферы доверия и взаимопонимания, которая позволит задавать как общие, так и более глубокие вопросы в [10] рекомендуется:

· демонстрировать искренний интерес относительно вклада данного человека в дело разработки программного обеспечения;

· слушать, т.к. самая лучшая мотивация для опрашиваемого – полное внимание спрашивающего;

· быть откровенным и честным;

· предложить помощь в составлении отчета о проекте и т.д.

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

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

Рекомендуется [10] задавать не только вопросы, непосредственно относящиеся к бизнесу, процессу или программному продукту. Например, некоторые из таких вопросов:

· Может ли эта система причинять какие-либо проблемы?

· Существует ли необходимость решения тех проблем, которые могут быть неочевидными?

· Может ли кто-то еще решить поставленную задачу?

· Что будет делать новая система из того, что в данный момент недостижимо при помощи существующих систем?

Совместные семинары

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

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

При организации семинаров, основной целью которых является выявление требований, необходимо пользоваться определенными приемами, например [4]:

· Основные правила. Участники семинара должны договориться об основных правилах проведения семинара, например: своевременно начинать и заканчивать семинар, не проводить несколько обсуждений одновременно, следить, чтобы каждый участвовал в работе, критиковать решения, а не людей их предложивших.

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

· Темы для дальнейшего обсуждения. Если на семинаре пойдет разговор о случайных, нарушающих текущие рамки, но важных для дальнейшей работы сведениях, то запишите их. Это позволит, с одной стороны, не потерять что-то важное, а с другой – продемонстрировать уважение к участнику семинара. К таким сведениям часто относятся нефункциональные требования: показатели качества, ограничения на продукт, особенности интерфейса и т.п.

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

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

· Все участвуют в обсуждении. Организатор семинара должен следить за тем, чтобы в обсуждении участвовали все. Может оказаться так, что участник семинара уступает право голоса более активному сотруднику не потому, что у него нет своего (возможно ценного) видения проекта, а из-за неуверенности в себе и своих идеях.

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

3.4. ”Мозговой штурм”

Концепция мозгового штурма, позволяющая быстро генерировать идеи, не оценивая и не преобразуя их, в литературе описана достаточно подробно.

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

Большое количество требований позволяет не только классифицировать их, разбивать по приоритетам, но и выбрасывать ненужные.

Рассмотрим подробно правила проведения сеансов “мозгового штурма” [10].

Роли во время сеансов

Каждый участник исполняет одну из ролей:

· Лидер (арбитр, председатель). В его обязанности входит слушать и направлять процесс в правильное русло. Он обеспечивает объявленный порядок, если нужно, начинает процесс генерирования идей, помогает секретарю в записи идей.

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

· Участник. Обычно это несколько организаторов проекта, имеющие различные точки зрения. Главная задача участников – это генерирование требований и стимулирование к высказыванию своих мыслей других участников сеанса. Число участников может быть достаточно большим, но наилучшие результаты достигаются в группах из 6-7 человек.

Правила проведения сеанса

1.Общие правила.

Основные правила проведения сеансов “мозгового штурма”:

· Принимаются любые идеи, все идеи потенциально хороши. Важно количество, а не качество идей.

· Идея принадлежит всей группе, а не только тому, кто ее высказал.

· Ценной является каждая точка зрения, т.к. уникальный подход к ситуации позволяет сформировать различные решения.

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

· Обсуждение идей происходит после завершения сеанса.

2.Правила для участников сеанса.

Правила для лидера:

· Идеи должны высказываться устно или в виде записок.

· Объявите участникам основные правила сеанса.

· Определите цель или тему сеанса.

· Получите как можно больше идей от участников, поощряйте “дикие” или нелепые идеи.

· Помогайте участникам генерировать идеи, изменять и комбинировать их.

· Не допускайте критики, обсуждений и споров.

· Установите ограничения во времени, поддерживайте высокий темп для уменьшения задержек и исключения оценки идей.

Правила для секретарей:

· Кратко записывайте суть идей, если нужно, попросите короткое пояснение, для формулировок используйте слова автора идеи.

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

Правила для участников:

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

· Проявляйте творческий подход, будьте открыты для новых оригинальных идей, не бойтесь рисковать, подключайте воображение, дополняйте и расширяйте идей других участников.

· Не оценивайте идеи других, не критикуйте и не осуждайте, не прерывайте других докладчиков.

· Думайте быстро, высказывайте каждую идею кратко, размышлять будете после.

Подготовка к сеансу

Для повышения успеха сеанса “мозгового штурма” он должен быть подготовлен. При подготовке нужно выполнить следующие работы.

· Определить и пригласить участников. Определить правила и роли участников. Сообщить им информацию о месте, времени и продолжительности сеанса.

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

· Подготовить помещение и необходимую технику для проведения сеанса.

Проведение сеанса

Рекомендуется следующий сценарий проведения “мозгового штурма”.

· Перед началом сеанса укажите его тему, обсудите правила и представьте участников.

· Для создания атмосферы уверенности и готовности генерировать идеи проводится 5-10 минутная разминка, тема которой должна быть нейтральной и понятной всем участникам, но не связанной с основной темой сеанса.

· “Мозговой штурм”. Предложите высказывать любые (рациональные, радикальные, необычные) идеи, которые приходят на ум. Активно работайте 10 – 15 минут и сделайте перерыв. Останавливайтесь до того, как утихнет энтузиазм. После перерыва продолжайте работать.
Если поток идей иссякает, то рассмотрите и уточните записанные идеи, убедитесь, что идеи понятны всем участникам. Объедините подобные идеи, удалите дубликаты. Определите критерии оценки идей.

· Достижение единодушного мнения. Попросите каждого члена группы проголосовать за первые 10 - 15 идей доработанного списка и анонимно представить его решение. Отведите на это достаточное время.

· Завершение сеанса. Поблагодарите участников сеанса, попросите заполнить форму оценки и сообщите, когда оцененные идеи будут им возвращены.

Сценарии

Люди (пользователи) часто лучше воспринимают и описывают примеры из реальной жизни, поэтому им проще ответить на вопрос "как работает система?", чем "что делает система?" Другими словами, пользователи легко понимают и могут оценить сценарий взаимодействия с программной системой, чем ее абстрактное описание.

Сценарий – это способ описания структуры задачи, представляющий собой повествовательный рассказ о совершаемых действиях, происходящих в данных временных рамках и в данном контексте [8].

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

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

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

Событийные сценарии (event scenarios) используются для документирования поведения системы, представленного определенными событиями. В большинстве случаев сценарий включает в себя:

· Описание начального состояния системы.

· Описание нормального протекания событий.

· Описание исключительных ситуаций и способов их обработки.

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

· Описание конечного состояния системы.

Описание сценария может быть представлено простым (или структурированным) текстом или при помощи схем сценариев, которые позволяют идентифицировать входные и выходные данные системы, управляющую информацию, внутрисистемные данные и исключительные ситуации [9].

Пример 3.1.

На рисунке 3.1 приведен сценарий события “Регистрировать программу”, который описывает процесс регистрации новой программы в реестре организации-разработчика.

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

· Полномочия недостаточны. Отказ в регистрации программы.

· Незарегистрированный контракт. Отказ в регистрации программы.

Следующий этап – проверка наличия программы – позволяет выявить исключительную ситуацию “Программа зарегистрирована”, при которой разработчику выдается номер, ранее присвоенный программе, и выполняется отказ в регистрации.

 

Рис. 3.1

Завершается сеанс регистрацией программы, т.е. занесением ее характеристик (наименования, сведений о контракте и других атрибутов) в реестр программ, разработанных организацией, и выдачей ее регистрационного номера разработчику (регистрирующему).

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

Варианты использования – это методика формирования требований, основанная на сценариях.

Вариант использования описывает поведение системы при ее ответах на запрос одного из участников (пользователей) системы, называемого основным действующим лицом, в различных условиях [7].

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

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

При написании варианта использования нужно помнить о трех понятиях, которые служат основой при написании варианта и любого его предложения. Это следующие понятия:

1. Область действия, которая определяет, насколько велика разрабатываемая система.

2. Основное действующее лицо – участник, который обращается к системе, чтобы она обеспечила достижение его цели.

3. Уровень, который определяет, насколько высока эта цель.

Требования должны быть короткими и ясными, поэтому основные рекомендации по написанию варианта использования могут быть следующими [7]:

· Начните со стратегического варианта. От него будут ветвиться варианты использования уровня цели пользователя.

· Именуйте варианты использования с помощью коротких глагольных конструкций, объявляющих цель, которая должна быть достигнута.

· На каждом шаге четко определяйте действующее лицо и его намерения.

· Для описания альтернативного поведения применяйте расширения, а не предложения типа «если … то … иначе» в теле главного варианта использования.

· Для записи шагов варианта использования применяйте только предложения в настоящем времени, с глаголом действия в действительном залоге, и описывающее как действующее лицо успешно достигает цели, продвигающей весь процесс.

Пример 3.2.

Вариант использования “Принять программу в архив”.

Основное действующее лицо: Приемщик.

Область действия: Архив.

Уровень: Цель пользователя.

Основной сценарий:

1.  Разработчик сообщает свои характеристики приемщику.

2. Приемщик проверяет полномочия разработчика.

3. Разработчик сообщает регистрационный номер программы.

4. Приемщик проверяет отсутствие программы в архиве.

5. Приемщик получает от разработчика:

ü носитель-оригинал с программой;

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

6. Приемщик контролирует соответствие содержимого носителя и его ведомости.

7. Приемщик копирует содержимое носителя-оригинала на проверенный и зарегистрированный архивный носитель.

8. Приемщик регистрирует копию в качестве подлинника программы.

9. Приемщик передает сведения о приеме программы в архив разработчику.

Расширения:

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

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

4а. Программа уже находится в архиве:

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

6а. Носитель содержит “лишние” файлы:

6а1. Разработчик уточняет состав файлов программы.

6а2. Приемщик переходит к пункту 7.

6б. Неверные контрольные характеристики файла (файлов):

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

Применение модели MSC UML

UML (Unified Modeling Language) – это унифицированный язык моделирования. UML представляет собой формальный искусственный язык, который постоянно развивается. Описание UML [3] по большей части формальное, но содержит и явно неформальные составляющие, что заметно отличает его от языков, которые, по общему мнению, являются образцами формализма. UML предназначен для моделирования. Сами авторы UML определяют его как графический язык моделирования общего назначения, предназначенный для спецификации, визуализации, проектирования и документирования всех артефактов, создаваемых при разработке приложений.

Для общего представление функционального назначения системы в UML предназначены диаграмма использования (use case). Диаграмма использования призвана ответить на вопрос: что делает система во внешнем мире?

На диаграмме использования применяются два типа основных сущностей: варианты использования и действующие лица, между которыми устанавливаются следующие основные типы отношений:

· ассоциация между действующим лицом и вариантом использования;

· обобщение между действующими лицами;

· обобщение между вариантами использования;

· зависимости (различных типов) между вариантами использования.

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

Семантически вариант использования – это описание множества возможных последовательностей действий (событий), приводящих к значимому для действующего лица результату. Каждая конкретная последовательность действий называется сценарием.

Пример 3.3

На рисунке 3.2 приведена диаграмма использования “Принять программу в архив”, описывающая процесс сдачи программы в архив организации-разработчика.

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

Диаграмма содержит два варианта использования (овала), имена которых идентифицируют функции: «Управление разработчиком» и «Управление архивом».

 

Рис. 3.2

Диаграмма описывает процесс на очень высоком уровне и здесь явно не достает более подробного описания вариантов (см. пример 3.2).

Диаграмма использования UML показывает объединение и декомпозицию вариантов использования, но не их содержание. Для описания варианта использования нужно использовать другие средства, например, диаграммы состояний и диаграммы последовательности.

3.6. Выявление требований на основе различных
точек зрения. Метод VORD

Любая достаточно большая программная система имеет несколько различных групп конечных пользователей. Каждая группа пользователей имеет свой взгляд на систему, свои интересы (свою точку зрения на систему) и поэтому должна участвовать в формировании требований. Эти различные точки зрения могут быть независимыми или пересекаться, но главное, они позволяют рассматривать систему с разных сторон и учитывать интересы всех ее пользователей.

Один из подходов к формированию требований основан на учете различных опорных точек зрения (viewpoint-oriented elicitation) и позволяет обнаруживать на ранних этапах проектирования противоречия в требованиях различных групп пользователей.

Существуют различные интерпретации понятия точки зрения. Приведем некоторые из них [9]:

Точка зрения – это источник информации о системных данных. В этом случае точка зрения – основа для построения модели создания и использования данных в системе.

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

Точка зрения – это получатель системных сервисов. В этом случае точка зрения (точнее ее носитель) является внешним по отношению к системе и помогает определить данные, необходимые для выполнения системных сервисов и управления ими.

При проектировании интерактивных систем нужно учесть, что взаимодействуют с системой, получая от нее сервисы и поставляя ей данные и управляющие сигналы, конечные (внешние) пользователи. Использование внешних опорных точек зрения позволяет:

· более естественно структурировать процесс формирования требований (по точкам зрения);

· упростить выбор опорных точек зрения, каждая из которых представляет собой способ взаимодействия пользователя с системой;

· выявить нефункциональные требования.

На основе такого подхода к интерпретации и выбору опорных точек был разработан метод VORD (Viewpoint-Oriented Requirements Definition) для формирования и анализа требований.

Метод VORD состоит из четырех основных этапов:

1.Идентификация точек зрения.

2.Структурирование точек зрения.

3.Документирование точек зрения.

4.Отображение системы точек зрения.

Идентификация точек зрения

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

«Мозговой штурм» направлен на решение следующих задач:

· идентификация потенциальных опорных точек зрения;

· идентификация системных сервисов;

· определение входных системных данных;

· определение нефункциональных требований;

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

Источниками информации для создания первоначального образа системы являются:

· документы, описывающие назначение системы,

· знания о предыдущих разработках,

· опыт пользователей,

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

Результат «мозгового штурма» – документ, идентифицирующий опорные точки зрения и сервисы системы (см. рис. 3.3).

Этнографический подход

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

Для определения среды функционирования системы и учета ее в требованиях разработчик должен «погрузиться» в эту среду, каждодневно наблюдая и фиксируя все реальные действия, выполняемые (потенциальными) пользователями, такой подход называется этнографическим [9].

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

Этнографический подход используется для выявления требований обычно совместно с другими методами. На рис. 3.5 приведена схема одной из возможных комбинаций методов:

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

· Начальные требования обсуждаются и уточняются на совместных семинарах.

· Для дальнейшей работы по выявлению и уточнению требований строится прототип системы.

Рис. 3.5

 

Вопросы:

1. Опрос: подготовка

2. Опрос: проведение опроса

3. UML-диаграммы

4. Выявление требований на основе различных точек зрения. Метод VORD.

5. Идентификация точек зрения

6. Структурирование точек зрения

7. Документирование и отображение системы точек зрения

8. Этнографический подход

 

4. Разработка системных требований

Изучив тему, Вы будете знать:

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

§ виды и типы системных моделей;

§ принципы прототипирования и роль прототипов при разработке требований;

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

При освоении темы необходимо акцентировать внимание:

§ на способах построения системных моделей;

§  на методиках экспериментального и эволюционного прототипирования и их связи с различными видами прототипов;

§ на способах описания системных требований.

4.1. Детализация требований пользователей

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

Системные требования состоят из полного списка конкретных свойств и функциональности, которую должна иметь программа, сформулированных в подробностях [10]

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

В основе моделирования лежат такие структурные методы, как структурный анализ систем и объектно-ориентированный анализ. Эти методы определяют процесс, который используется для построения моделей и набор правил их моделирования. Структурные методы анализа имеют и существенные недостатки, поскольку:

· не обеспечивают поддержку формирования нефункциональных требований;

· модели часто слишком детализированы и трудны для понимания, а суть требований может скрываться за множеством несущественных деталей;

· выбор метода и типов моделей зависит от решаемой задачи и достаточно ответственен (и сложен).

Системные модели

В процессе анализа систем могут разрабатываться различные модели: модели системного окружения, поведенческие модели и модели данных [9].

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

Модели системного окружения служат для определения границ системы и строятся на ранних этапах выявления требований. Трудоемкость построения модели зависит от характера разрабатываемого приложения.

Например, если новое приложение заменит существующую систему, то его окружение, скорее всего, будет совпадать с окружением заменяемой системы. Если же новое приложение использует уже существующие компоненты, например, базу данных, то определение границ между ними (разграничение полномочий, функций и т.д.) – достаточно сложная техническая и, возможно, управленческая задача. Граница системы может определяться не только техническими факторами, т.е. на определение системного окружения могут влиять социальные и организационные ограничения.

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

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

При разработке требований к программной системе часто проще ответить на вопрос “как работает система?”, чем “что делает система?”. Ответ на этот вопрос дает модель поведения. (Заметим, что поведение реальной программной системы определяется кодом ее программы, таким образом, модель поведения – это описание алгоритма работы системы). Требования, предъявляемые к модели поведения, используемой на этапе разработки требований можно сформулировать следующим образом:

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

2. Средства моделирования поведения должны быть знакомы и привычны для большинства заинтересованных лиц.

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

Большинство бизнес-систем служит для управления данными, и поэтому довольно мало занимаются обработкой внешних событий. Для таких систем модель потоков данных достаточно хорошо описывает их поведение. Для описания поведения систем реального времени, которые управляют событиями и имеют минимум обработки данных, лучше использовать модель конечного автомата. Если система управляет и данными и событиями, то для ее представления необходимо использовать оба типа поведенческих моделей.

Рассмотрим основные модели, используемые для описания общего поведения системы.

Модели потоков данных

Модели потоков данных – это простой и понятный способ описания последовательности обработки данных внутри системы. Для описания модели потоков данных используются диаграммы потоков данных (data flow diagram, DFD), во всем многообразии нотаций которых, можно выделить основные компоненты [5]:

· процесс (трансформационный процесс, системная функция, обрабатывающая единица) – механизм, описывающий способ получения выходных данных из входных данных;

· поток данных – определяющий перемещение данных (материалов) между процессами;

· хранилище – места хранения данных (базы данных, например);

· внешние сущности – объекты внешнего (по отношению к системе) мира.

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

Ценность моделей потоков данных в том, что они позволяют:

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

· проследить и документировать перемещение данных по системе, помогая понять этот процесс;

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

· описывать (при проектировании) принятые решения.

Наивысший уровень диаграммы потока данных – контекстная диаграмма – представляет систему, как единый процесс. Контекстная диаграмма содержит внешние, по отношению к системе, сущности, которые являются источниками или потребителями системных потоков данных. Выделив важнейшие процессы системы, можно разработать диаграмму потока данных уровня 0, в которой, кроме внешних сущностей и системных потоков данных, определенных в контекстной диаграмме, содержит эти процессы и те потоки данных, которыми они обмениваются. Каждый процесс из диаграммы нулевого уровня может быть детализирован в виде диаграммы следующего уровня (уровень 1), содержащего всю его функциональность. Детализация может быть продолжена до тех пор, пока процессы на диаграмме не станут содержать только простейшие операции. Функциональные требования в спецификации требований к системе должны точно определить, что происходит в ходе каждого простейшего процесса.

Пример 4.1.

На рис. 4.1 приведена контекстная диаграмма информационной системы архива, которая позволяет:

· записывать в архив подлинники программ;

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

· выполнять тиражирование программ.

Рис. 4.1

С системой общаются:

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

· сотрудники архива, выполняющие прием и регистрацию подлинников программ, и внесение в них изменений (ИИ – извещение об изменении);

· магнитотека (хранилище) программ.

Единственный процесс «Обслужить» не раскрывает функций системы, поэтому для более детального описания необходима более детальная диаграмма (диаграмма 0-го уровня). На рис. 4.2 приведена диаграмма 0-го уровня, которая показывает процессы, выполняемые системой и потоки входных и выходных данных для процессов. Процессы на диаграмме нумеруются и могут, при необходимости, быть описаны более подробно на следующих уровнях детализации.

 

Рис. 4.2

При разработке диаграмм потоков данных следует придерживаться следующих общих правил:

· размещать на диаграмме не более 7 – 10 процессов;

· не загромождать диаграммы несущественными на данном уровне деталями;

· декомпозицию потоков данных выполнять параллельно с декомпозицией процессов;

· однократно определять функционально идентичные процессы и ссылаться на них, на нижних уровнях.

Модели конечных автоматов

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

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

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

Пример 4.2.

На рис. 4.3 приведена диаграмма конечного автомата, описывающего процесс «Принять программу в архив».

Рис. 4.3

Система находится в начальном состоянии и ожидает запроса. После его получения она переходит в состояние «Контроль запроса», где выясняет, имеет ли разработчик полномочия для сдачи программы в архив. Если полномочий недостаточно или программа уже находится в архиве, то система возвращается в начальное состояние.

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

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

ER-диаграммы

Наиболее широко используется моделирование данных типа “сущность – связь – атрибут”, определяющее структуру данных, их атрибуты и отношения между ними [9].

Для разработки моделей данных, обеспечивающих стандартный способ определения данных и отношений между ними, служат диаграммы “сущность-связь” (Entity-Relationship Diagrams, ER-диаграммы). ER-диаграммы позволяют идентифицировать сущности (объекты, важные для предметной области), свойства сущностей – атрибуты – и связи (отношения) между сущностями.

Под сущностью (entity) в ER-диаграммах понимается множество экземпляров реальных или абстрактных объектов (людей, предметов, событий и т.д.). Любой объект системы может быть представлен только одной уникально идентифицированной сущностью, имя которой должно отражать тип (класс) объектов, а не его конкретный экземпляр. Связь (relation) – это именованное отношение между двумя и более сущностями, а атрибут (attribute) – любая характеристика сущности, причем множество значений всех атрибутов должно однозначно идентифицировать экземпляр сущности. Более подробно описание ER-диаграмм и методика их использования для моделирования структур данных приведены в [9], а мы ограничимся примером.

Пример 4.3.

На рис. 4.4. приведена диаграмма, описывающая запрос на запись программы в архив. Разработчик может дать несколько запросов, каждый из которых содержит не менее одной программы. Каждая программа расположена на отдельном носителе, содержание, которого определяется ведомостью.

 

Рис. 4.4

Словарь данных

Недостатком ER-диаграмм является их недостаточная детализация данных, поэтому они часто дополняются более подробным описанием, которые собираются в словари данных.

Словарь данных позволяет:

· определить механизм управления именами, позволяющий избежать дублирования;

· связать различные этапы проектирования системы.

Словарь данных содержит описание именованного объекта (сущности, потока данных, хранилища), включающего в себя определение его атрибутов, структуры – для сложных объектов, – а также дополнительные сведения, например, единицы измерения и диапазоны изменения атрибутов, цель определения такого объекта, сведения о его разработчике и времени создания и т.д.

Прототипы

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

4.3.1. Роль прототипов при разработке требований

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

Прототип полезен в решения следующих задач:

1.Разработка требований.

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

2.Проверка требований.

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

3.Разработка взаимодействия с пользователем.

Прототип позволяет реализовать различные варианты взаимодействия, исследовать альтернативные решения и выбрать оптимальный вариант.

4.Спецификация системных требований.

Прототип может служить основой для написания высококачественных системных требований.

Виды прототипов

Горизонтальные прототипы

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

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

Вертикальные прототипы

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

Разработка прототипов

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

Риски прототипирования

Прототипирование позволяет уменьшить риски проекта, но имеет и свои собственные риски [19, 23]:

1.Заинтересованные в проекте лица могут принять работающий прототип за начальную версию системы.

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

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

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

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

Если при разработке прототипа использовались быстрые, но менее эффективные средства и алгоритмы, то соответствующей будет и его производительность.

4.Разработчики могут много сил и средств потратить на разработку прототипа.

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

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

4.5. Системные требования

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

Учитывая важность спецификации и различные группы ее читателей, основные требования к спецификации – это ясность и понятность.

Требования в спецификации могут быть записаны при помощи:

· структурированного естественного языка,

· языков описания программ,

· различных графических нотаций,

· математических спецификаций или специальных языков описания требований.

Языки описания программ

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

Примером такого подхода является язык описания программ PDL (program description language). Этот язык строится по образцу языков программирования, управляющие операторы которых определяют:

· внешний синтаксис, т.е. описание структуры управления;

· внутренний синтаксис – описание структур данных и процедур их обработки – не определен и выбирается проектировщиком.

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

Пример 4.4.

Если использовать в описании процесса на PDL предложения, написанные на естественном языке, то описание будет достаточно простым для понимания. На рис. 4.7 приведено описание процесса «Принять программу в архив», рассмотренного в разделе 3.

Рис. 4.7

Графические нотации

Для описания требований применяются различные графические нотации. Наиболее часто используются уже рассмотренные графические средства: диаграммы потоков данных, модели конечных автоматов, диаграммы “сущность-связь”, сценарии, варианты использования, диаграммы использования, диаграммы состояний и диаграммы последовательности UML.

4.6. Документирование системных требований

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

Вопросы для самоконтроля

Вопросы:

1. Модели потоков данных

2. Модели конечных автоматов

 

5. Документирование требований

Изучив тему, Вы будете знать:

§ Состав спецификации требований;

§ Рекомендации по разработке требований;

§ Стандартные шаблоны спецификации;

§ Особенности документирования требований в соответствии со стандартами России.

При освоении темы необходимо акцентировать внимание:

§ на содержание разделов спецификации требований;

§ рекомендации по написанию спецификации;

§ на использование стандартных шаблонов спецификаций;

§ на вопросы организации требований в спецификации.

5.1. Спецификация требований

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

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

Спецификация требований – основной документ, описывающий разрабатываемую систему, и она необходима различным группам заинтересованных лиц. Это клиенты и специалисты по продажам, менеджеры проекта, разработчики, пользователи и т.д.

Учитывая важность спецификации и различные группы ее читателей, к ней предъявляются противоположные требования. С одной стороны, она должна быть простой, ясной и понятной пользователю неспециалисту, а с другой, для разработчика, – точной, подробной и формальной. Для учета этих требований спецификация, обычно, состоит из двух частей, первая из которых описывает пользовательские требования, а вторая – системные требования.

5.2. Состав спецификации требований

Существует достаточно большое число шаблонов (схем) спецификации требований, отличающихся структурой или способом упорядочения требований. Но каждый из шаблонов требует включения в спецификацию следующей информации.

Введение

Этот раздел должен содержать обзор спецификации, позволяющий читателю разобраться в структуре и принципах ее построения. Здесь определяется специфицируемая далее система или подсистема, указывается ее редакция и версия; перечисляются стандарты, используемые при написании спецификации, а также все документы, на которые есть ссылки в спецификации.

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

Общее описание

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

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

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

Окружение. Описывают рабочую среду программной системы: аппаратные средства, операционные системы. Здесь же перечисляют другие программные компоненты, с которыми система должна быть совместима.

Ограничения реализации. Перечисляют все факторы, ограничивающие возможности разработчика, например:

· технологии, языки программирования, базы данных, стандарты разработки, которые следует (или не следует) использовать;

· ограничения операционной среды, аппаратуры;

· ограничения, связанные с продуктами, разработанными ранее;

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

Функции системы

Для каждой функции системы должно быть указано:

· название и приоритет;

· системные входные и выходные данные, или последовательности «воздействие – реакция»;

· детальные функциональные требования;

· реакция на ошибки ввода данных или неверные действия пользователя.

Внешний интерфейс

Раздел должен содержать описание логических характеристик каждого пользовательского интерфейса, например:

· ссылки на стандарты графического интерфейса, шрифтов, элементов управления и т.п.;

· конфигурация экрана, стандартные кнопки и функции навигации;

· стандарты отображения сообщений и т.д.

Здесь же описывают характеристики интерфейсов программных и аппаратных компонентов системы, протоколы их взаимодействия. Кроме этого – интерфейсы между системой и другими программными компонентами и интерфейсы передачи информации.

Нефункциональные требования

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

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

5.3. Рекомендации по разработке требований

Не существует определенной методики написания идеальных требований. Качество требований определяется опытом и здравым смыслом. Хорошую спецификацию требований отличает технический стиль изложения и пользовательская терминология, а не компьютерный сленг [4]. Литература по разработке требований содержит большое число рекомендаций.

Приведем некоторые из них.

· Абзацы и предложения должны быть краткими и ясными. Следите за правильностью правописания, грамматики и пунктуации, используйте действительный залог (например, «Система выполнит …», а не «Произойдет …»).

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

· Нечеткие пользовательские требования должны быть детализированы так, чтобы стать ясными системными требованиями.

· Применяйте визуальное представление информации: списки, таблицы, графики, диаграммы и рисунки, чтобы не утомлять читателя большими объемами сплошного текста.

· Точно сформулированные требования повышают вероятность того, что ожидания клиентов будут реализованы; менее строгие формулировки дают разработчикам больше свободы для интерпретаций.

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

· Нельзя тратить слишком много времени на попытки сделать требования идеальными. Ваша цель – написать требования, которые достаточно хороши, чтобы разработчики могли приступить к конструированию продукта при приемлемом уровне риска.

При документировании пользовательских требований можно пользоваться следующими рекомендациями:

1.Если требование независимое и простое, то оно может быть записано в виде нескольких простых предложений.

2.Если требование представляет собой взаимодействие (пользователя и системы), то его можно описать с помощью варианта использования.

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

4.Если требование определяет состояния системы, то для его фиксации можно применить конечный автомат.

Рекомендации для документирования системных требований:

1.Перед написанием спецификации системных требований необходимо выбрать стиль описания.

2.Для каждого требования нужно выполнить следующие работы:

· определить требование как функциональное или нефункциональное; оценить сложность функционального требования (требование большое – трудно управлять, очень маленькое – нет смысла рассматривать отдельно);

· сделать требование прослеживаемым и проверяемым (написать проверочный тест), доопределить требование для случая нештатных ситуаций;

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

Вопросы для самоконтроля

1.Какая информация вносится в спецификацию требований?

2.Кто основные читатели спецификации?

3.Какие рекомендации по документированию требований должны быть выполнены?

4.Зачем разрабатываются шаблоны спецификации?

5.От чего зависит тип применяемого шаблона?

6.На основе каких стандартов разрабатываются шаблоны?

7.Какие классификации могут быть использованы для организации требований?

8.В чем особенности организации требований по классам?

6. Анализ спецификации требований

Изучив тему, Вы будете знать:

§ характеристики качества, предъявляемые спецификации требований;

§ методы;

§ методику тестирования требований.

При освоении темы необходимо акцентировать внимание:

§ на определении характеристик качества;

§ на методах и средствах аттестации требований;

§ на методах планирования тестирования требований.

6.1. Оценка качества спецификации требований

Учитывая важность спецификации и различные группы ее читателей, к ней предъявляются противоположные требования. С одной стороны, она должна быть простой, ясной и понятной пользователю неспециалисту, а с другой, для разработчика, – точной, подробной и формальной.

Полнота и согласованность

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

Способность к модификации

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

Трассируемость

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

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

6.1.2. Аттестация требований

Существует ряд методов аттестации требований, которые можно использовать совместно или каждый в отдельности:

· экспертиза спецификации,

· прототипирование,

· автоматизированный анализ.

Экспертиза спецификации

Экспертиза спецификации [4, 7] требований позволяет эффективно выявить неполные и некорректные требования, требования неясные или неподдающиеся проверке, несогласованные и не тестируемые требования.

Неофициальные экспертизы проводится во время разработки спецификации, знакомства с продуктом и не носят регулярный характер. Такие просмотры могут проводиться в виде «проверки за столом», когда автор просит коллегу исследовать спецификацию, или коллективной проверки – параллельного исследования спецификации несколькими людьми.

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

 

 

Рис. 6.1

Процесс экспертизы начинается с ее планирования (см. рис. 6.1). Председатель (координатор) совместно с автором спецификации определяют число и состав участников, материалы, которые должны получить эксперты до первого совещания, количество совещаний, темп проведения экспертизы.

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

 

Рис. 6.2

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

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

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

Для организации помощи экспертам в проведении экспертизы спецификации требований разрабатываются контрольные списки дефектов [4]. На рис. 6.2. приведен список дефектов для варианта использования. Список содержит вопросы, на которые должен ответить эксперт при проведении анализа. Списки могут изменяться, сообразуясь с требованиями проекта. Если список велик, то его можно разбить на подсписки, которые эксперты будут использовать при подготовке.

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

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

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

Прототипирование

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

Автоматизированный анализ

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

6.5. Тестирование требований

Экспертиза спецификации требований – это просмотр документа, для которого не требуется компьютер. Тестирование – процесс динамический, который выполняется на компьютере, и поэтому может быть применен только для функциональных требований [9].

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

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

Планирование процесса тестирования должно производиться параллельно с проектированием. Виды планов, разрабатываемых на разных этапах проектирования, хорошо иллюстрируются на примере V-образной модели жизненного цикла (см. рис. 6.3).

 

Рис. 6.3

Пунктирными линиями здесь соединены этапы, которые нужно рассматривать параллельно [10]. Остановимся на первых двух связях.

Требования к проекту и планирование

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

Требования к продукту и анализ спецификации

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

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

Вопросы для самоконтроля

1.Какие характеристики определяют качество спецификации?

2.Как определяется полнота и согласованность требований?

3.Почему важны способность к модификации спецификации и трассируемость требований?

4.Что такое экспертиза спецификации? Почему этот процесс должен быть документирован?

5.Каковы основные роли участников экспертизы?

6.Чем тестирование требований отличается от аттестации?

7.Что определяет критерий приемлемости?

8.Кто должен разрабатывать тесты приемочных испытаний?

7. Управление требованиями

Изучив тему, Вы будете знать:

§ почему изменяются требования, виды изменяемых требований;

§ принципы управления требованиями, изменениями и версиями;

§ связанные с требованиями риски.

При освоении темы необходимо акцентировать внимание:

§ на методах и средствах управления версиями спецификации и отдельных требований;

§ на методах анализа влияния и стоимости внесения изменения;

§ на управлении статусом требований;

§ на анализе рисков, связанных с требованиями.

7.1. Причины изменений требований

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

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

· понимание пользователями возможностей системы, решаемых ею задач, может измениться;

· происходят изменения в деловой среде, техническом, программном (и т.д.) обеспечении системы, которые должны быть учтены;

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

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

С точки зрения разработки требования можно разделить на два класса:

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

2.Изменяемые требования отображают изменения, происходящие во время разработки и эксплуатации системы. На рис. 7.1 приведена классификация изменяемых требований и источники их возникновения.

 

Рис. 7.1

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

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

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

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

7.2. Принципы управления требованиями

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

К действиям по управлению требованиями относятся:

1.Определение основной (базовой) версии спецификации требований для конкретной версии продукта;

2.Анализ предлагаемых изменений требований, оценка воздействия и стоимости каждого изменения до его принятия;

3.Включение одобренных изменений при помощи определенной процедуры;

4.Согласование плана проекта с требованиями;

5.Отслеживание отдельных требований от проектирования до кода приложения и его тестирования;

6.Отслеживание статуса требований и действий по изменению на протяжении всего проекта.

Базовая версия требований

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

Процесс управления требованиями

В организации (или проекте) должны быть определены действия по управлению требованиями. Эти действия должны быть задокументированы и выполняться всеми участниками проекта. При разработке процесса нужно определить:

· методы и средства управления версиями спецификации и отдельных требований;

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

· процесс присвоения, контроля и изменения статуса требования;

· процесс передачи новых требований и изменений существующих требований заинтересованным лицам;

· методы анализа влияния и стоимости внесения изменения.

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

Контроль версий

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

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

Идентификация отдельных требований

Минимальной единицей управления в спецификации требований является отдельное требование, поэтому вопрос идентификации требования достаточно важен.

Форма представления требования может быть различной (текстовая, графическая и т.д.), поэтому для идентификации требования обычно используют связанный с ним набор атрибутов. Атрибутами могут быть: дата создания требования, номер текущей версии требования, номер версии продукта, для которой предназначено требование, автор требования, ответственный за реализацию требования, состояние требования, происхождение и обоснование требования, подсистема, для которой предназначено требование и т.д. Главное при выборе атрибутов, чтобы они однозначно идентифицировали требование его состояние и статус.

Статус требования

В процессе выполнения проекта требование, обычно, изменяет свое состояние от начального («предложено»), до конечного, например, «реализовано». Статус требований позволяет оценить степень готовности проекта. В [4] рекомендуют использовать состояния требования, приведенные в табл. 7.1.

Таблица 7.1.

Состояние	Определение
Предложено (proposed)	Требование запрошено авторизированным источником
Одобрено (approved)	Требование проанализировано, его влияние на проект просчитано, и оно было размещено в базовой версии определенной версии продукта. Ключевые заинтересованные в проекте лица согласились с этим требованием, а разработчики обязались его реализовать
Реализовано (implemented)	Код, реализующий требование разработан, написан и протестирован. Требование отслежено до соответствующих элементов дизайна и кода
Проверено (verified)	Корректное функционирование реализованного требования подтверждено в соответствующем продукте. Требование отслежено до соответствующих вариантов тестирования. Теперь требование считается завершенным
Удалено (deleted)	Утвержденное требование удалено из базовой версии. Зафиксируйте причины и лицо, принявшее это решение
Отклонено (rejected)	Требование предложено, но не запланировано для реализации ни в одной из будущих версий. Зафиксируйте причины и лицо, принявшее это решение

В процессе управления требованиями должны быть определены лица, которые могут изменить статус требования. Управление статусом позволяет численно определить степень готовности проекта, считая, например, что основная часть работы закончена, если все требования имеют статус «Проверено» или «Удалено».

Управление изменениями

После разработки, согласования и утверждения спецификация требований становится основным документом в проектировании системы (версии системы). Изменения в этот документ разрешается вносить только через определенный в организации (или проекте) процесс внесения изменений.

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

1.Все изменения должны вноситься в соответствии с документированным и утвержденным процессом. Неофициальные запросы на изменение не рассматриваются. Запрос на изменение не гарантирует его выполнение. Текст запроса не должен изменяться или удаляться.

2.Для каждого изменения должен выполняться анализ его влияния. Обоснование утверждения или отклонения запроса на изменение должно быть документировано.

3.Реализовывать неутвержденные изменения запрещено.

Диаграмма переходов состояний для типового процесса внесения изменений в спецификацию требований приведена на рис. 7.2.

Рис. 7.2

Процесс инициируется запросом на внесение изменения, или предложением об изменении, оформленным в соответствии с утвержденными правилами и поступивший по официальным каналам. Если запрос не содержит требования, то процесс переходит в состояние «Разработка требования», в котором аналитик и инициатор изменения формируют требование. Полученное требование анализируется для определения ожидаемого от него эффекта и определения стоимости внесения изменения в спецификацию требований и в структуру и код системы. Принимается решение об одобрении или отклонении изменения. В случае положительного решения оформляется документ, содержащий решение об изменении и изменение (например, извещение об изменении, или ИИ), после чего вносится изменение в спецификацию и систему.

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

Стандарты достаточно строго и точно определяют процессы оформления и внесения изменения в спецификацию (документ), но действия по анализу требования и его стоимости, принятия решения об изменении, внесение изменений в код системы – должны быть определены в организации (или проекте).

Описание процесса контроля изменений должно содержать:

1.Границы применения процесса. Должны быть перечислены те продукты или изменения, которые не принадлежат процессу.

2.Роли и ответственность. Должны быть определены члены проекта (роли), участвующие в контроле изменений и их ответственность.

3.Описание процедуры прохождения запроса на изменение.

4.Описание процедур анализа и оценки запроса на осуществимость, влияния и стоимости изменения, принятия решения и изменения состояния запроса.

Стоимость внесения изменения в требования сильно зависит от фазы жизненного цикла, на котором находится система и может быть очень велика [1, 4, 10], поэтому принятие решения об изменении – достаточно сложная и ответственная проблема. Лучшее практическое решение этой проблемы – совет по управлению изменениями [4]. Совет по управлению изменениями – это небольшая группа людей, принимающая решение о том, какие предлагаемые изменения требований, новые функции, интерфейс будут включены в продукт. Для эффективной работы совет должен иметь утвержденные структуру, полномочия и рабочие процедуры (устав).

Управление версиями

Следующая функция, направленная на поддержание целостности, точности и актуальности спецификации требования – это управление версиями спецификации.

Управление версиями требует выполнения следующих видов деятельности:

1.Определение конфигурации требований: именование отдельных требований и версий спецификации.

2.Определение состава версии спецификации.

3.Управление процессом внесения изменений.

4.Хранение истории каждой версии спецификации, содержащей сведения о внесенных изменениях.

5.Проведение аудита для обеспечения целостности имеющихся требований.

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

Наиболее надежный способ контроля версий – это использование соответствующих программных средств.

7.5. Управление связями требований

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

Трассируемость требований позволяет решить следующие задачи.

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

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

3.Упростить внесение изменения на поздних фазах проектирования, а также фазе эксплуатации и сопровождения продукта.

4.Зафиксировать опыт проектирования, упростить повторное проектирование и повторное использование.

5.Упростить поиск, локализацию и исправление ошибок при тестировании.

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

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

Матрица трассируемости требований

Трассирование требований – это определение связей между требованием и другими артефактами проекта. Такая информация обычно представляется в виде матрицы [1, 4]. На рис. 7.3 приведен один из возможных форматов такой матрицы.

Рис. 7.3

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

Дополнительным достоинством матрицы является то, что по ней можно выполнять как прямую (от требования к коду и далее) трассировку, так и обратную трассировку. Кроме этого, разрешив определять несколько позиций в ячейке матрицы, мы получаем возможность фиксировать не только бинарные отношения, но и связи вида «один ко многим» или «многие ко многим». Дело в том, что одно функциональное требование, например, может проверяться несколькими вариантами тестирования, а несколько вариантов использования могут порождать множества функциональных требований, пересечение которых не пусто. Другие варианты матриц трассируемости требований можно найти в [4].

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

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

Существующие средства управления требованиями позволяют: импортировать требования из исходных документов, определять значения атрибутов, контролировать связи трассирования требований, соединять требования с элементами, хранящимися в других средствах разработки и т.д. В [4] правильно замечено, что, несмотря на большой объем функций, выполняемых этими средствами, они не являются средствами разработки требований, а значит, не могут помочь в определении заинтересованных лиц (пользователей) или выявлении и сборе требований.

7.6. Риски, связанные с требованиями

Риск отражает возможные потери при выполнении программного проекта, которые оказывают на него негативное влияние. С каждым из этапов разработки требований связаны свои риски. В [4, 6] рассматриваются вопросы управления рисками их отслеживание и контроль. Приведем основные риски, связанные с требованиями.

7.6.1. Риски этапа выявления требований

Наименование риска	Причина возникновения	Методы уменьшения риска
Концепция проекта	Если лица, заинтересованные в проекте не имеют ясного мнения о том, что должен представлять собой продукт, то вероятность расползания границ системы возрастает	Разработайте документ об образе и границах продукта, который содержит бизнес-требования и используйте его при выработке решений о принятии или изменении требований
Время, затраченное на разработку требований	Жесткие сроки проекта заставляют разработчиков и пользователей пренебрегать разработкой требований и сразу переходить к кодированию	Собирайте статистику о времени и усилиях, затраченных на разработку требований в каждом проекте, и используйте ее для улучшения планирования следующего проекта
Полнота и корректность спецификации требований	Жесткие сроки проекта	Концентрируйтесь на определении пользовательских задач, используйте для определения потребностей пользователя наиболее понятные для него средства: сценарии использования, прототипы и т.п.
Определение нефункциональных требований	Основное внимание уделяется на функциональность продукта	Выясняйте у пользователей качественные характеристики продукта: надежность, производительность, простота использования и т.п. Документируйте эти требования и критерии их оценки в спецификации
Единство мнений пользователей относительно требований	Отсутствие или неполное согласование требований со всеми пользователями	Определите основных пользователей, сторонников продукта для получения нужного представительства. Удостоверьтесь, что вы полагаетесь на правильно выбранных людей, имеющих полномочия для принятия решений

7.6.2. Риски этапа анализа и спецификации требований

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

7.6.3. Риски управления требованиями

Наименование риска	Причина возникновения	Методы уменьшения риска
Изменение требований	Изменение понимания пользователями и разработчиками решаемых системой задач, изменения в деловой среде, техническом, программном обеспечении	Для уменьшения расползания границ проекта используйте документ, описывающий его концепцию. Активное участи пользователей в выявлении требований, контроль качества требований уменьшают вероятность изменений требований, проектируйте легко модернизируемую систему
Процесс изменения требований	Не документированность процесса изменения	Разработайте, документируйте, утвердите и контролируйте процесс внесения изменений

Вопросы для самоконтроля

1.Перечислите несколько причин изменения требований.

2.Чем отличаются постоянные и изменяемые требования?

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

4.Что такое базовая версия требований?

5.Для чего используются атрибуты требований? Назовите несколько атрибутов и обоснуйте их выбор.

6.Что такое статус и состояние требования?

7.Кто принимает решение о внесении изменений в требования?

8.Какие задачи позволяет решить трассируемость требований?

 

8. CASE-средства для управления требованиями

Изучив тему, Вы будете знать:

§ каковы достоинства CASE-средств управления требованиями;

§ чем определяется выбор CASE-средств управления требованиями;

§ возможности некоторых CASE-средств управления требованиями.

При освоении темы необходимо акцентировать внимание:

§ на недостатках документального хранения требований;

§ на взаимосвязи между уровнями зрелости и используемыми инструментами;

§ на возможностях CASE-средств управления требованиям.

8.1. Выбор CASE-средств для управления требованиями

Как было уже замечено документальное хранение требований весьма трудоемко и имеет много недостатков, основные из которых – это трудности:

· во внесении изменений, поддержке непротиворечивости и актуальности документов;

· в хранении атрибутов, управлении статусом требований;

· в управлении версиями и т.д.

Поэтому использование инструментальных средств является необходимым условием успешности выполнения проекта. Средства автоматизации и поддержки, используемые в процессе разработки программных систем, принято называть CASE-средствами (Computer-Aided Software Engineering). Нас интересуют средства, которые можно использовать на этапе разработки и анализа требований к программной системе, т.е. средства, поддерживающие: выявление и документирование требований пользователей, разработку системных требований, анализ требований и управление требованиями.

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

· при определении заинтересованных лиц, пользователей системы;

· при выявлении и сборе требований.

CASE-средства не могут заменить «ручные» методы выявления требований.

CASE-средства позволяют более точно и производительно управлять требованиями, но не всегда внедрение автоматизации в этот процесс приводит к успеху. Многие авторы [4, 6] говорят о том, что даже лучшие средства могут не оправдать ожиданий, если их используют разработчики, не имеющие должной квалификации и мотивации. Дело в том, что для перехода к оперативным приемам работы с требованиями необходим новый образ мышления, достаточный уровень зрелости функциональных возможностей.

Управление версиями

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

8.3. Возможности CASE-средств управления требованиями

Коммерческие средства управления требованиями [4] позволяют определять различные типы требований: бизнес-требования, варианты использования, функциональные требования, ограничения и требования к оборудованию. Эти средства обладают большими возможностями определения атрибутов для перечисленных типов требований, что очень трудно сделать при использовании обычных средств документирования.

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

Инструментальные средства позволяют выводить требования в виде документа заданного формата или в виде табличного отчета.

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

Средства IDF-моделирования

Совокупность методик и моделей концептуального проектирования IDEF (Integrated DEFinition) была разработана в США. В настоящее время имеются методики функционального, информационного и поведенческого моделирования, в которые входит достаточно большое число моделей. Например:

1.IDEF0 – функциональное моделирование. Реализует методику функционального моделирования сложных систем, основой которой является методология SADT (Structured Analysis and Design Technique).

2.IDEF2, IDEF3 – поведенческое моделирование, или моделирование деятельности. В основе лежат модели и методы имитационного моделирования систем массового обслуживания, сети Петри, конечные автоматы.

Перечисленные методики относятся к структурным методам.

Platinum BPwin

Platinum BPwin – это наиболее распространенный пакет, поддерживающий технологию моделирования IDEF. В него включены три методологии моделирования: функциональное моделирование (IDEF0), описание бизнес-процессов (IDEF3) и диаграммы потоков данных (DFD).

При создании новой модели достаточно в начальном диалоге выбрать нужную методологию. Рабочий стол BPwin состоит из нескольких окон, панель меню соответствует стандартам Windows и обеспечивает доступ ко всем функциям, а стандартная панель инструментов обеспечивает быстрый доступ к часто выполняемым задачам. Особенностью BPwin является наличие дерева модели, которое позволяет просматривать (в разных режимах) созданные модели, действия и объекты диаграмм, согласно уровням их декомпозиции и т.д. В своем составе BPwin имеет программу «Наставник», позволяющую быстро ознакомиться с нужной методикой и ее реализаций в пакете.

BPwin позволяет печатать диаграммы и строить отчеты по моделям. Определено большое число стандартных отчетов, например:

· отчет по диаграммам, который включает информацию об объектах в активной диаграмме;

· отчет о связях в модели;

· отчет об объектах диаграммы, содержащий информацию об объектах, размещенных на диаграмме (функциональных блоках, хранилищах данных и внешних ссылках);

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

Более подробное описание пакета BPwin и его применения для моделирования (требований) можно найти в [5].

Средства UML

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

UML имеет средства – диаграммы использования – для общего представление функционального назначения системы ее положения во внешнем мире. Для описания варианта использования используются другие средства, например, диаграммы состояний и диаграммы последовательности.

Rational Rose

Пакет Rational Rose – мощный инструмент анализа и проектирования объектно-ориентированных программных систем. Модель Rose [2] поддерживает четыре представления: представление вариантов использования, логическое представление, представление компонентов и представление размещения.

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

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

Together

Программный пакет Together позволяет:

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

2. Строить диаграммы видов деятельности, связанные с требованиями, представленными диаграммами использования или свойствами.

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

В основе Together лежат следующие идеи:

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

2. Сотрудничество с использованием средств управления конфигурацией, что позволяет использовать один механизм для управления моделями, документами и исходным кодом.

3. Автоматизация рутинных операций.

4. Постоянный контроль качества. Аудит позволяет проверить соответствие стандартам, используя встроенные правила или формулируя свои правила контроля. Применяя метрики, определенные в Together, можно провести количественный анализ исходного кода.

Достаточно подробное описание Together и его использование в процессе разработки программных систем можно найти в [6].

 

Вопросы для самоконтроля

1.Какие недостатки имеет документальное хранение требований?

2.Почему используются CASE-средства управления требованиями?

3.Отчего зависит внедрение автоматизации в процесс управления требованиями?

4.Какие ключевые области процесса, которые определены для разработки требований и на каком уровне зрелости?

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

6.Какие инструменты поддерживают модели концептуального проектирования IDEF ?

7.Что представляет собой пакет Rational Rose?

8.Какие идеи лежат в основе пакета Together?

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

1. Брауде Э. Технология разработки программного обеспечения. – Спб.: Питер, 2004.

2. Боггс Уэнди. UML и Rational Rose 2002 – М.: Лори-Пресс , 2004

3. Буч Г., Рамбо Д., Джекобсон А. Язык UML. Руководство пользователя: Пер. с англ. – М.: ДМК, 2000.

4. Вигерс К. Разработка требований к программному обеспечению /Пер. с англ. – М.: Издательско-торговый дом «Русская редакция», 2004.

5. Дубейковский В. И. Практика функционального моделирования с AllFusion Process Modeler 4.1. Где? Зачем? Как? – М.: ДИАЛОГ-МИФИ, 2004.

6. Кармайкл Э., Хейвуд Д. Быстрая и качественная разработка программного обеспечения : Пер. с англ. – М.: Издательский дом «Вильямс», 2003.

7. Коберн А. Современные методы описания функциональных требований к системам. – М.: Издательство “Лори”, 2002.

8. Константайн Л., Локвуд Л. Разработка программного обеспечения. – СПб.: Питер, 2004.

9. Соммервилл И. Инженерия программного обеспечения, 6-ое издание. : Пер. с англ. – М.: Издательский дом «Вильямс», 2002.

10. Шафер Д., Фатрелл Р., Шафер Л. Управление программными проектами: достижение оптимального качества при минимуме затрат. : Пер. с англ. –М.: Издательский дом «Вильямс», 2003

Карта памяти к разделу 1

Карта памяти к разделу 2

 

Карта памяти к разделу 3

 

Карта памяти к разделу 4

 

Карта памяти к разделу 5

 

Карта памяти к разделу 6

 

Карта памяти к разделу 7

 

Карта памяти к разделу 8

 

Содержание

1. Виды, взаимосвязь и свойства требований. 1

1.1. Что такое «требование»?. 1

1.2. Виды требований. 2

1.2.1. Функциональные требования. 3

1.2.2. Нефункциональные требования. 4

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

1.3.1. Полнота и корректность. 6

1.3.2. Необходимость и осуществимость. 7

1.3.3. Приоритет. 7

1.3.4. Недвусмысленность и непротиворечивость. 7

1.3.5. Проверяемость и прослеживаемость. 7

1.4. Особенности разработки требований к программным системам. 7

1.5. Вопросы для самоконтроля. Ошибка! Закладка не определена.

2. Определение образа и границ проекта. 9

2.1. Анализ предметной области. 9

2.2. Анализ осуществимости. 10

2.3. Определение целей и области действия. 11

2.4. Документирование образа и границ проекта. 12

2.5. Вопросы для самоконтроля. 14

3. Выявление требований. 14

3.1. Определение способа сбора и анализа требований. 15

3.1.1. Источники возникновения требований. 15

3.1.2. Заинтересованные в проекте лица. 15

3.2. Опрос (интервью) 16

3.2.1. Подготовка. 16

3.2.2. Проведение опроса. 17

3.2.3. Определение последующих действий. 18

3.3. Совместные семинары.. 19

3.4. ”Мозговой штурм”. 20

3.4.1. Роли во время сеансов. 20

3.4.2. Правила проведения сеанса. 20

3.4.3. Подготовка к сеансу. 21

3.4.4. Проведение сеанса. 22

3.4.5. Обработка результатов сеанса. 22

3.5. Сценарии. 23

3.5.1. Сценарии событий. 23

3.5.2. Варианты использования. 25

3.5.3. Применение модели MSC UML. 27

3.6. Выявление требований на основе различных точек зрения. Метод VORD 28

3.6.1. Идентификация точек зрения. 29

3.6.2. Структурирование точек зрения. 30

3.6.3. Документирование и отображение системы точек зрения. 30

3.7. Этнографический подход. 32

3.8. Вопросы для самоконтроля. Ошибка! Закладка не определена.

4. Разработка системных требований. 33

4.1. Детализация требований пользователей. 34

4.2. Системные модели. 34

4.2.1. Модели потоков данных. 36

4.2.2. Модели конечных автоматов. 38

4.2.3. Модели данных. 39

4.3. Прототипы.. 41

4.3.1. Роль прототипов при разработке требований. 41

4.3.2. Виды прототипов. 42

4.4. Разработка прототипов. 42

4.4.1. Экспериментальное прототипирование. 43

4.4.2. Эволюционное прототипирование. 43

4.4.3. Риски прототипирования. 44

4.5. Системные требования. 45

4.5.1. Структурированный естественный язык. 46

4.5.2. Языки описания программ. 46

4.5.3. Графические нотации. 47

4.6. Документирование системных требований. 48

4.7. Вопросы для самоконтроля. 48

5. Документирование требований. 48

5.1. Спецификация требований. 48

5.2. Состав спецификации требований. 49

5.3. Рекомендации по разработке требований. 51

5.4. Стандартные шаблоны спецификации. 52

5.5. Вопросы для самоконтроля. 57

6. Анализ спецификации требований. 57

6.1. Оценка качества спецификации требований. 57

6.1.1. Характеристики качества спецификации. 57

6.1.2. Аттестация требований. 58

6.2. Экспертиза спецификации. 58

6.3. Прототипирование. 61

6.4. Автоматизированный анализ. 61

6.5. Тестирование требований. 61

6.6. Вопросы для самоконтроля. 63

7. Управление требованиями. 63

7.1. Причины изменений требований. 64

7.2. Принципы управления требованиями. 65

7.3. Управление изменениями. 68

7.4. Управление версиями. 70

7.5. Управление связями требований. 70

7.6. Риски, связанные с требованиями. 72

7.6.1. Риски этапа выявления требований. 73

7.6.2. Риски этапа анализа и спецификации требований. 74

7.6.3. Риски управления требованиями. 75

7.7. Вопросы для самоконтроля. 75

8. CASE-средства для управления требованиями. 76

8.1. Выбор CASE-средств для управления требованиями. 76

8.2. Уровень зрелости и используемые инструменты.. 77

8.2.1. Моделирование требований. 79

8.2.2. Трассировка требований. 79

8.2.3. Управление версиями. 79

8.3. Возможности CASE-средств управления требованиями. 79

8.3.1. Средства IDF-моделирования. 80

8.3.2. Средства UML. 81

8.4. Вопросы для самоконтроля. 83

Список литературы.. 83

Карта памяти к разделу 1. 84

Карта памяти к разделу 2. 85

Карта памяти к разделу 3. 86

Карта памяти к разделу 4. 87

Карта памяти к разделу 5. 88

Карта памяти к разделу 6. 89

Карта памяти к разделу 7. 90

Карта памяти к разделу 8. 91

 

Производительность

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

Надежность и доступность

Надежность – это вероятность работы системы без сбоев в течение определенного времени. Для измерения надежности может быть использовано среднее время работы системы до сбоя.

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

Безопасность

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

Удобство и простота обслуживания

Этот атрибут связан с большим числом факторов, определяющих, по словам пользователей, дружелюбие системы к пользователю. Другими словами система должна использоваться эффективно и необременительно. Достаточно подробно эти характеристики, определяющие практичность системы рассмотрены в [4].

 

Для разработчиков и специалистов по обслуживанию от системы требуются другие характеристики. Приведем некоторые из таких атрибутов качества.