Файл: Учебное пособие.doc

Предотвращение пустой траты времени на предложенные требования, которые, как видно из прототипа, не нужны (то есть минимум три ненужных требования из 100; на этап требований выделено 300 000, сэкономлено 9000).
Разработка программного проекта «примерка одежды», что уменьшает риски разработки (то есть оценка того, что это сэкономит минимум одну человека-неделю времени проектирования = 2000).
Переработка, которая может возникнуть из-за изменения требований клиентом после того, как он увидит окончательный продукт (то есть переработка минимум трех требований по 3000 каждое = 9000).

Существует минимальная экономия, эквивалентная 9000 + 2000 + 9000 = 20 000.

Рис. 3.51. Выгода от прототипа

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

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

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

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

Таблица 3.19

Оценка программы по продаже одежды

Часть прототипа	Оценка стоимости	Общая прибыль без повторного использования кода		Процентная часть кода прототипа, повторно использованная в приложении	Чистая выгода
	Оценка стоимости	Мин.	Макс.		Мин.	Макс.	В среднем
	В	D	Е	С	D-(1-C)B	Е-(1-С)В
Экранные снимки пользовательского интерфейса	10 000	10 000	80 000	50%	5 000	75 000	40 000
Безопасность транзакций	50 000	10 000	300 000	80%	0	290 000	145 000
Завершение транзакций	80 000	10 000	400 000	50%	-30 000	200 000	85 000
Примерка одежды клиентом	120000	20 000	140 000	30%	-64 000	56 000	-4 000

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

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

3.2.1.Метод вариантов использования и его применение

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

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

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

3.2.1.1.Построение модели вариантов использования

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

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

Второй шаг описывает системное поведение, т.е. то, как пользователи взаимодействуют с системой, осуществляя некоторые последовательности действий, для достижения определенных целей (Рис. 3 .52).

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

Рис. 3.52 Диаграмма вариантов использования

3.2.1.2.Спецификация вариантов использования

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

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

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

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

Альтернативный поток событий.

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

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

Выявление пред- и постусловий

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

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

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

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

3.2.1.3.Преимущества

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

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

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

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

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

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

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

3.2.2.Псевдокод

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

Императивных предложений с одним глаголом и одним объектом.

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

Решений, представленных формальной структурой IF-ELSE-ENDIF.

Итеративных действий, представленных структурами DO-WHILE и FOR-NEXT.

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

Фрагменты текста на псевдокоде расположены уступами; такой формат используется для того, чтобы выделить логические "блоки". Сочетание синтаксических ограничений, формата и разбивки существенно уменьшает неоднозначность требования, которое в противном случае было бы очень сложным и расплывчатым. В то же время такое представление требования вполне понятно для человека, не являющегося программистом. Не нужно быть выдающимся ученым, чтобы понимать псевдокод, и нет необходимости знать C++ или Java.

Frame4 Рис. 3.53 Пример спецификации с использованием псевдокода

3.2.3.Конечные автоматы

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

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

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

На рисунке 4.6 приведён пример диаграммы состояний и переходов для объекта заказ.

Рис. 3.54. Диаграмма состояний и переходов объекта «заказ»

3.2.4.Графические деревья решений

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

Рис. 3.55. Графическое дерево решений

3.2.5.Диаграммы деятельности

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

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

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

Рис. 3.56. Диаграмма деятельности покупателя в Интернет-магазине

3.3.Техническое задание (ГОСТ 34.602-89)

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

3.3.1. Общие сведения

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

3.3.2.Назначение и цели создания (развития) системы

3.3.2.1.Назначение системы

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