Мелихов А.Ю. Проектирование автоматизированных систем обработки информации и управления

Подождите немного. Документ загружается.

121

Сервер

Клиент

<<слой представления>>

ъект

переноса

анных

<<сервисный слой >>

<<слой домена>>

<<слой источника данных>>

сбо

щик

интерфейс

удаленного

доступа

сбо

щик

ъект

переноса

анных

БД

шлюз

внешний

источник

данных

межкомпоне

нтный

интерфейс

Подсис-

тема 1

Подсис-

тема 2

Рисунок 78 – Пример организации двухуровневой архитектуры типа «клиент-сервер»

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

обсуждаются в литературе. В частности, в [62, 80, 95, 98] описаны основные концепции организации

интерфейсов и приведены примеры их реализации.

8.2. НОТАЦИЯ UML ДЛЯ ПРОЕКТИРОВАНИЯ БАЗ ДАННЫХ

Проектирование БД зависит от типа используемой для хранения данных СУБД –

объектной или реляционной. Для объектных БД никакого проектирования не требуется,

поскольку классы-сущности непосредственно отображаются в БД. Для реляционных БД

классы-сущности объектной модели должны быть отображены в таблицы реляционной БД.

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

классов, которая по существу является ER-диаграммой. Набор правил, применяемых при

отображении классов в таблицы БД, фактически совпадает с правилами преобразования

сущностей и связей.

Для описания схемы БД применяется следующий набор элементов языка UML со

своими стереотипами (профиль UML):

• таблица представляется в виде класса со стереотипом «Table»;

• представление изображается в виде класса со стереотипом «View»;

• столбец таблицы представляется в виде атрибута класса с соответствующим типом

данных;

• обычная ассоциация и агрегация представляются в виде ассоциации со стереотипом

«Non-Identifying» (в терминологии IDEF1X – неидентифицирующая связь);

• композиция представляется в виде ассоциации со стереотипом «Identifying» (в

терминологии IDEF1X – идентифицирующая связь);

• схема БД представляется в виде пакета со стереотипом «Schema», содержащего классы-

таблицы;

• контейнер хранимых процедур представляется в виде класса со стереотипом «SP

Container»;

• ограничения целостности, индексы и триггеры представляются в виде операций классов-

таблиц со стереотипами «РК» (Primary Key), «FK» (Foreign Key), «Unique», «Check»,

«Index» и «Trigger»;

122

• физическая база данных представляется в виде компонента со стереотипом «Database».

Кроме создания структуры при проектировании БД, как правило, перечисляются все

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

функционирования, а также приводят синтаксис и описание типовых SQL-запросов,

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

осуществлять мониторинг за состоянием

БД, с другой стороны, решить задачу построения

сложно-структурированных запросов к БД, тем самым повысив надежность и расширяемость

системы, а также упростив программирование клиентской части приложения.

Стандарт IEEE 1016-1987 для проектной документации программного обеспечения

(SDD – Software Design Document) содержит руководство по составлению и ведению

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

соответствии с IEEE 1016-1987, помещается в приложение Е ПЗ. Пример составления

проектной документации см. в [48].

8.3. ПРАКТИЧЕСКИЕ АСПЕКТЫ ПРОЕКТИРОВАНИЯ ПОЛЬЗОВАТЕЛЬСКОГО

ИНТЕРФЕЙСА

8.3.1. Общие вопросы проектирования пользовательского интерфейса

Поскольку проектированию и разработке интерфейса посвящена обширная

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

рассмотрим лишь некоторые практические рекомендации, которые должны быть учтены при

разработке прототипа интерфейса в рамках курсового проекта.

Существует четыре основных критерия качества любого интерфейса: скорость работы

пользователей, количество человеческих ошибок, скорость обучения и субъективное

удовлетворение (подразумевается, что соответствие интерфейса задачам пользователя

является неотъемлемым свойством интерфейса). Интерфейс, удовлетворяющий указанным

критериям, будем называть эффективным.

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

психо-физиологическими особенностями восприятия информации человеком.

Один из наиболее известных сборников стандартом, регламентирующих разработку

пользовательских

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

был опубликован в 1987 IBM и, назывался Общий пользовательский доступ - Common User

Access (CUA). C тех появлялось множество стандартов и, в настоящее время, многие

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

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

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

элементам интерфейса:

1. правило в

1954 году сформулировал Поль Фитс: «Время достижения цели прямо

пропорционально дистанции до цели и обратно пропорционально размеру цели». В

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

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

времени тратил на позиционирование курсора мыши. Нарушение этого правила –

кнопка «Пуск» в Windows, которая обрамлена 3-х пиксельной окантовкой не смотря

на то, что расположена в углу экрана.

2. Принцип «релевантное – вперед»: чаще всего используемые элементы должны быть

расположены в левой верхней части экрана, реже используемые – в правой нижней

части.

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

накладываемое кратковременной памятью: запоминаются 7±2 пункта. При этом

лучше ориентироваться в среднем на 7 – 1 (1 для обработки) = 6 элементов.

123

Общие рекомендации организации интерфейса, связанные с физиологическими

особенности пользователей:

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

каждый экран снабжать подсказками.

2. Пользователи плохо запоминают информацию на нескольких следующих друг за

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

пользователь должен знать:

a. на каком шаге он остановился

b. какие команды и параметры он уже дал системе (сделать так, что бы от

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

экрана)

c. что именно он должен сделать на текущем шаге

d. куда было обращено его внимание на момент отвлечения (последний активный

элемент с фокусом ввода)

3. При борьбе с ошибками пользователей нужно направлять усилия на:

a. плавное обучение пользователей в процессе работы

b. снижение требований к бдительности

c. повышение разборчивости и заметности индикаторов при выполнении

ответственных (необратимых) операций. Самое важное в интерфейсе должно

быть наиболее заметно.

d. снижение чувствительности системы к ошибкам. Для этого есть три основных

способа, а именно:

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

подтверждения правильности действия (не делайте опасные для

пользователя кнопки кнопками «по умолчанию»);

ii. проверка системой всех действий пользователя перед их принятием;

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

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

современных направлений развития пользовательского интерфейса –

построение адаптивного интерфейса, который запоминает последние

настройки пользователя и сокращает число пунктов настройки в

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

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

окончательного совершения действия, всегда свидетельствует о

недостаточно хорошем дизайне.

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

зависит от контекста

v. Необходимо предусмотреть возможность отмены пользователем своих

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

типа отменяемых действий

e. Тщательно продумайте сообщение об ошибках:

i. Идеальное сообщение об ошибке должно отвечать всего на три вопроса:

В чем заключается проблема? Как исправить эту проблему сейчас? Как

сделать так, чтобы проблема не повторилась?

ii. не забывайте показывать текст сообщений об ошибке техническому

писателю.

iii. старайтесь делать текст сообщения возможно более коротким.

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

ошибках, во всяком случае в ПО. Пузырь (balloon), по сравнению с

диалоговым окном, имеет существенные достоинства: он гораздо слабее

сбивает фокус внимания, по сравнению с окном; чтобы закрыть пузырь,

пользователям не обязательно нажимать на какую-либо кнопку,

124

достаточно щелкнуть мышью в любом месте экрана; он не перекрывает

значимую область системы; самое главное - он показывает, в каком

именно элементе управления была допущена ошибка.

4. При проработке интерфейса:

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

яркостью, и мягкостью (т. е. не бьющих по глазам). На экране их значительно

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

цветом, так и текстурой, с чем на экране есть проблемы.

b. Избегайте острых углов в визуале.

c. Старайтесь сделать визуал максимально более легким и воздушным.

d. Старайтесь добиваться контраста не сменой насыщенности элементов, но

расположением пустот.

e. Старайтесь сделать

интерфейс максимально насыщенным визуальными

закономерностями. Есть универсальное правило – чем больше

закономерностей, тем больше гармонии. Даже самые незначительные

закономерности всё равно воспринимаются. Под закономерностью здесь

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

объектов, например, высота кнопок может быть равна удвоенному полю

диалогового окна.

f. Старайтесь использовать модульные сетки, т. е.

привязывайте все объекты к

линиям (лучше узлам) воображаемой сетки, которую выдерживайте во всем

интерфейсе.

g. Старайтесь привязывать все размеры и координаты (как минимум пропорции

диалоговых окон) к золотому сечению (0.618 х 0.382).

В литературе приводится множество примеров удачного дизайна. Один из них сайт

Реймского университета (Франция) - http://www.univ-reims.fr/, в котором интерфейс

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

эволюции, то можно отметить, что пик красоты пришелся на первую версию, а затем с

каждой новой версией интерфейс становился все скромнее и скромнее. В настоящий момент

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

цвета. Несмотря на внешнюю пустоту окна, все функции доступны

одним нажатием кнопки.

8.3.2. Элементы управления пользовательского интерфейса

Критерий эффективности элементов управления состоит в улучшении понимания их

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

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

Кнопка – элемент прямого действия. Должна быть оформлена как текстовая ссылка,

если она перемещает пользователя на другой фрагмент контента

(как в интернете), и как

кнопка – если она запускает действие. Кнопка должны быть максимально большой.

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

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

выраженными в виде глаголов в форме инфинитива (Прийти, Увидеть, Победить).

разработчики создают диалоговое окно, внизу которого располагают три кнопки: Ок,

Применить и Отмена (триединство ошибки). Помимо текста, на кнопках можно выводить

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

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

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

создание, значительны.

Чекбоксы и радиокнопки – это кнопками отложенного действия, т. е. их нажатие не

должно инициировать какое-либо немедленное действие. С их помощью пользователи

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

125

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

поскольку это значительно ускоряет поиск нужного элемента. Каждая подпись должна

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

быть позитивными (т. е. не содержать отрицания). Повторять одни и те же слова, меняя

только окончания подписей (например, «Показывать пробелы» и «Показывать табуляции»), в

нескольких кнопках нельзя, в таких случаях лучше перенести повторяющееся слово в рамку

группировки. Нажимабельной должна быть не только элемент, но ещё и подпись, просто

потому, что закон Фитса однозначно требует больших кнопок. При необходимости

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

подпись.

Списки. Ширина списка как минимум должна быть достаточна для того, чтобы

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

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

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

элементов (http:/ya.ru…/1.jpg). Поскольку нужно максимально ускорить работу

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

существенное повышение субъективной привлекательности интерфейса и сканируются

быстрее «голого» текста. Раскрывающийся список, в котором помимо собственно элементов

есть «мета-элемент», включающий все элементы из списка, делают пустым, что

неправильно. Такой мета-элемент нужно снабжать названием, например, «Все значения» или

«Ничего». В Интернете раскрывающийся список часто используется как навигационное

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

список не является элементом управления прямого действия и пользователь, совершая

моторную ошибку, будет переходить к одному разделу, думая, что переходит к другому. В

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

действие.

Поля ввода. Ширину поля ввода нужно подбирать под максимальную длину

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

объема вводимого в него текста, и при этом объем вводимого текста ограничен,

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

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

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

(чтобы всегда восприниматься и тем самым сокращать количество ошибок).

Крутилка (spinner, little arrow) есть поле ввода, не такое универсальное, как обычное,

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

(его лучше настроить именно так), но

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

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

определенного времени. Во-вторых, при вводе значения мышью система может позволить

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

корректном

формате.

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

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

возможность выбрать значение, стоящее в хорошо ранжирующемся ряду, если:

• значений в ряду много;

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

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

их количества (в таких случаях ползунок оказывается самым эффективным

элементом, хотя и опасен возможными человеческими ошибками).

Меню. Под меню понимаю метод взаимодействия пользователя с системой, при котором

пользователь выбирает из предложенных вариантов, а не предоставляет системе свою

команду. В этом смысле диалоговое окно с несколькими кнопками (и без единого поля

ввода) также является меню. На эффективность меню наибольшее влияние оказывают

126

устройство отдельных элементов (к наименованию элементов меню нужно подходить весьма

тщательно и не использовать негативных формулировок) и их группировка. Несколько менее

важны другие факторы, такие как выделение элементов и стандартность меню. Пиктограммы

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

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

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

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

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

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

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

быстрее обычного, поскольку в таком меню больше «точек привязки» (так же, как и в меню с

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

накладываемое кратковременной памятью: запоминаются 7±2 пункта. При этом лучше

ориентироваться в среднем на 7 – 1 (1 для обработки) = 6 элементов. В качестве

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

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

пунктов меню привлекают пользователей и используют т.н. способ карточной сортировки.

При этом, все понятия, которые требуется классифицировать, пишутся на бумажных

карточках из расчета «одно понятие – одна карточка». После этого группе пользователей из

целевой аудитории предлагается эти карточки рассортировать (при этом каждый субъект

получает свой набор карточек). Получившиеся кучки из карточек нужно разобрать на

составляющие и свести результаты от разных субъектов в один способ классификации. Не

делайте контекстные меню (так же как панель инструментов) единственным способом

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

меню – в виде круга, когда до каждого пункта одинаковое расстояние от центра).

Структура окна. Пожалуй, самым существенным фактором, влияющим на качество

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

пользователей порой можно повысить вдвое, просто изменив расположение элементов

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

учитывать следующее:

1. окно должно хорошо сканироваться взглядом, т. е. его основные части должны быть

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

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

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

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

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

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

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

грамматику языка).

3. окно должно удовлетворять закону «релевантное – вперед». Чаще всего используемые

элементы должны быть расположены в

левой верхней части экрана, реже

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

взглядом точно так же, как происходит процесс чтения – сначала взгляд переходит в

левый верхний угол, затем перемещается вправо, затем переходит на следующую

«строку» и т.д. В этой связи, терминационные кнопки помещают снизу или справа,

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

8.3.3. Процесс проектирования пользовательского интерфейса

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

происходить в последовательности: проектирование, создание прототипа, затем

тестирование/модификация, опять тестирование/модификация и т.д. Собственно

проектирование интерфейса начинается на стадии проработки эскизного проекта, когда

127

имеется черновой вариант, составленный при формировании требований. К моменту

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

взаимодействия с пользователями, обеспечивая 100% требуемой функциональности. Таким

образом, проектирование интерфейса состоит в последовательном проектировании

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

вариантов реализации из которых необходимо выбрать наиболее эффективный. Можно,

сделать несколько прототипов и протестировать их на пользователях, но это довольно

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

быстро выбрать лучший вариант. В 1983 году Кард, Моран и Ньювел создали метод оценки

скорости работы с системой, названный аббревиатурой GOMS (Goals, Operators, Methods,

and Selection Rules – цели, операторы, методы и правила их выбора). Идея состоит в

следующем: все действия пользователя можно разложить на составляющие (например, взять

мышь или передвинуть курсор). Можно замерить время их выполнения на массе

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

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

зная продолжительность каждой составляющей, всё сложить и узнать длительность всего

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

Правила GOMS:

• Нажатие на клавишу клавиатуры, включая Alt, Ctrl и Shift (К): 0,28 сек

• Нажатие на кнопку мыши (М): 0,1 сек

• Перемещение курсора мыши (П): 1,1 сек

• Взятие или бросание мыши (В): 0,4 сек

• Продолжительность выбора действия (Д): 1,2 сек

В среднем, за 1.2 секунды пользователь принимает решение, какое именно действие

он должен совершить на следующем шаге. В большинстве случаев достаточно считать, что

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

установленным фокусом, перед всеми командами, инициированными мышью и после

существенных изменений изображения на экране.

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

глянца и вообще стремление сделать прототип возможно более похожим на

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

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

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

возможностей бумажной версии прототипа стоит создать новую версию (исправив,

разумеется, уже обнаруженные проблемы). Для этого точно так же рисуется интерфейс, но

уже не на бумаге, но в какой-либо презентационной программе (MS PowerPoint, например).

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

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

установки гиперссылок). В тех случаях, когда в интерфейсе появляются нестандартные

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

системой, создается еще одна версия прототипа – реально выглядящая, но лишенная каких-

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

Один из самых простых видов тестирования интерфейса состоит в том, что

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

фиксируются для дальнейшего анализа какой-либо программой записи состояния экрана

(удобен Lotus ScreenCam). Такой метод полезен для выявления неоднозначности элементов

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

каждая такая ошибка фиксируется, обнаружить их при просмотре записанного материала

очень легко.

128

СПИСОК ЛИТЕРАТУРЫ

1. «Advanced Software Engineering: Expanding the Frontiers of Software Technology», IFIP 19th World

Computer Congress. (2006 ; Santiago, Chile). First International Workshop on Advanced Software

Engineering, 26-28 April 2006 / Edited by S.F. Ochoa. – New York : Springer, 2006. – 178 p.

2. «Advances in Databases and Information Systems», ADBIS 2008. (2008 ; Pori, Finland). 12th East

European Conference, 5-9 September 2008 / Edited by Hannu Jaakkola. – Berlin : Springer, 2008. – 331

3. «Agile Processes in Software Engineering and Extreme Programming», 8th International Conference,

XP 2007 (2007 ; Como, Italy). 18–22 June 2007 / Edited by Giancarlo Succi. – Germany : Springer-

Verlag Berlin Heidelberg, 2007. – 289 p.

4. «Database and XML Technologies», XSym 2003. (2003 ; Berlin, Germany). First International XML

Database Symposium, 8 September 2003 / Edited by Rainer Unland. – Berlin : Springer, 2003. – 293 p.

5. «Empirical Software Engineering Issues Critical Assessment and Future Directions», International

Workshop (2006; Dagstuhl Castle, Germany), 26-30 June 2006 / Edited by R. Selby. – Berlin : Springer,

2007. – 209 p.

6. «Fundamental Approaches to Software Engineering», ETAPS 2004 (2004 ; Barcelona, Spain). 7th

International Conference, Held as Part of the Joint European Conferences on Theory and Practice of

Software, March 29 –April 2 2004 / Edited by Tiziana Margaria-Steffen. – Berlin : Springer, 2005. –

404 p.

7. «Information Systems Development», Thirteenth International Conference on Information Systems

Development Advances in Theory, Practice and Education (2004 ; Vilnius, Lithuania). 9–11 September

2004 / Edited by Olegas Vasilecas. – New York : Springer, 2005. – 550 p.

8. «Programming Languages and Systems», APLAS 2008 (2008 ; Bangalore, India). 6th Asian

Symposium, 9-11 December 2008 / Edited by G. Ramalingam. – Berlin : Springer, 2008. – 350 p.

9. «Web Information Systems Engineering», International Workshops (September 1–4, 2008 ; Auckland,

New Zealand). 1–4 September 2008 / Edited by Markus Kirchberg. – Berlin : Springer, 2008. – 199 p.

10. Abmann U. Invasive Software Composition. / U. Abmann. – Germany: Springer, 2003. – 334 p.

11. Andersson E. Software Engineering for Internet Applications / E. Andersson, P. Greenspun, A. Grumet.

– London: MIT Press, 2006. – 411 p.

12. Arnowitz J. Effective Prototyping for Software Makers / J. Arnowitz, M. Arent, N. Berger. – Canada:

Elsevier, 2007. – 625 p.

13. Aurum A.·Engineering and Managing Software Requirements / A. Aurum; edited by C. Wohlin. –

Berlin: Springer, 2005. – 487 p.

14. Bamford R. ISO 9001:2000 for Software and Systems Providers / R. Bamford, W.J. Deibeler. – London:

CRC Press, 2004. – 309 p.

15. Bass L. Software Architecture in Practice / L. Bass, P. Clements, R. Kazman. – 2nd edition. – London :

Addison Wesley, 2003. – 560 p.

16. Bean J. SOA and Web Services Interface Design. Principles, Techniques and Standards / J. Bean. –

Burlington: Morgan Kaufmann, 2010. – 360 p.

17. Bernus P. Handbook on Architectures of Information Systems / P. Bernus, K. Mertins, G. Schmidt. –

Berlin : Springer, – 2006. – 869 p.

18. Boucher T. Design of Industrial Information Systems / T. Boucher, A. Yaçin – Canada : Elsevier, 2006.

– 431 p.

19. Brandon D.M. Software Engineering for Modern Web Applications: Methodologies and Technologies /

D.M. Brandon – Hershey: IGI Global, 2008. – 403 p.

20. Buschmann F. Pattern-Oriented Software Architecture. A System of Patterns, Volume 1 / F.

Buschmann, R. Meunier et al. Chichester : John Willey & Sons, 2001. – 487 p.

21. Buschmann F. Pattern-Oriented Software Architecture: A Pattern Language for Distributed Computing /

F. Buschmann, K. Henney, D.C. Schmidt. - Glasgow: John Wiley & Sons, Ltd., 2007. – 639 p.

22. Buschmann F. Pattern-Oriented Software Architecture: On Patterns and Pattern Languages / F.

Buschmann, K. Henney, D.C. Schmidt. - Glasgow: John Wiley & Sons, Ltd., 2007. – 491 p.

23. Cassidy A. A Practical Guide to Information Systems Process Improvement / A. Cassidy, K.

Guggenberger – Florida: CRC Press LLC, 2001. – 286 p.

24. Cecelja F. Manufacturing Information and Data Systems / F. Cecelja – London: Penton Press, 2002. –

201 p.

129

25. Clements P. Documenting Software Architecture / P. Clements, F. Bachmann et al. – London: Addison

Wesley, 2001. – 342 p.

26. Cockburn A. Agile Software Development: The Cooperative Game / A. Cockburn - London: Addison

Wesley, 2006. – 504 p.

27. Construx. Software Development Best Practices [Электронный ресурс] / Официальный сайт

Construx; Steve McConnell – Электрон. дан. – Bellevue : Construx, 2009 – . – Режим доступа :

http://www.construx.com, свободный. – Загл. с экрана. – Яз. англ.

28. Ebert C. Best Practices in Software Measurement. How to Use Metrics to Improve Project and Process

Performance / C. Ebert, R. Dumke, M. Bundschuh, A. Schmietendorf. – Berlin: Springer-Verlag, 2005.

– 299 p.

29. Ellis H.J.C. Software Engineering: Effective Teaching and Learning Approaches and Practices / H.J.C.

Ellis, S.A. Demurjian, J.F. Naveda. - New York: Information science reference, 2009. – 433 p.

30. Erl T. SOA Design Patterns / T. Erl. – Boston: Prentice Hall, 2009. – 856 p.

31. Georgakopoulos D. Service-Oriented Computing / D. Georgakopoulos, M.P. Papazoglou. - Cambridge:

The MIT Press, 2009. – 387 p.

32. Giorgini P. Agent-Oriented Methodologies / P. Giorgini. – Hershey: Idea Group Inc., 2005. – 429 p.

33. Goodman F.A. Defining and Deploying Software Processes / F.A. Goodman. – New York : Taylor &

Francis Group, 2006. –246 p.

34. Gorton I. Essential Software Architecture / I. Gorton. – Berlin: Springer-Verlag, 2006. – 292 p.

35. Greenfield J. Software Factories: Assembling Applications with Patterns, Models, Frameworks, and

Tools / J. Greenfield, K. Short et al. - New York: John Wiley & Sons, 2004. – 666 p.

36. Handbook of Enterprise Integration / edited by M.H. Sherif – New York : CRC Press, 2010. – 730 p.

37. Hohmann L. Beyond Software Architecture: Creating and Sustaining Winning Solutions / L. Hohmann.

– London: Addison Wesley, 2003. – 352 p.

38. Horstmann C.

Object-Oriented Design & Patterns / C. Horstmann. - Hoboken: John Wiley & Sons, Inc.,

2006. – 473 p.

39. International Function Point Users Group. [Электронный ресурс] / Официальный сайт International

Function Point Users Group; President Tom Cagley – Электрон. дан. – Princeton : IFPUG, 2009 – . –

Режим доступа : http://www.ifpug.org, свободный. – Загл. с экрана. – Яз. англ.

40. Jalote P. An Integrated Approach to Software Engineering / P. Jalote. – New York : Springer, 2005. –

571 p.

41. Kaisler S.H. Software Paradigms / S.H. Kaisler. – New Jersey : John Wiley & Sons, Inc., 2005. – 458 p.

42. Khosrow-Pour M. Cases on Information Technology: Planning, Design and Implementation / M.

Khosrow-Pour. – London : Idea Publishing, – 2006. – 385 p.

43. Kircher M. Pattern-Oriented Software Architecture: Patterns for Resource Management, Volume 3 / M.

Kircher, J. Prashant. - New Jersey : John Wiley & Sons, Inc., 2004. – 310 p.

44. Kirn S. Multiagent Engineering Theory and Applications in Enterprises / S. Kirn, O. Herzog, P.

Lockemann ; edited by O. Spaniol. – Berlin: Springer, 2006. – 617 p.

45. Krishnamurthy N. Building Software. A Practitioner’s Guide / N. Krishnamurthy, A. Saran. – New York

: Taylor & Francis Group, 2008. – 380 p.

46. Krogstie J. Conceptual Modeling in Information Systems Engineering / J. Krogstie, A.L. Opdahl ; edited

by S. Brinkkemper. – Berlin: Springer, 2007. – 356 p.

47. Laird L.M. Software Measurement and Estimation. A Practical Approach / L.M. Laird, M.C. Brennan. –

New Jersey: IEEE Computer Society, 2006. – 276 p.

48. Langer A.M. Analysis and Design of Information Systems / A.M. Langer. – London: Springer, 2008. –

437 p.

49. Lattanze A.J. Architecting Software Intensive Systems. A Practitioner’s Guide / A.J. Lattanze. –

London: Taylor&Francis Group, 2009. – 464 p.

50. Lauesen S. User Interface Design. A Software Engineering Perspective / S. Lauesen. – Harlow :

Addison Wesley, 2005. – 623 p.

51. Lemos R. Architecting Dependable Systems / R. Lemos, С. Gacek, A. Romanovsky (Eds.). – New York

: Springer-Verlag, 2003. - 312 p.

52. Meszaros G. xUnit Test Patterns. Refactoring Test Code / G. Meszaros. – Boston: Pearson Education,

2007. – 948 p.

53.

Nilsson J. Applying Domain-Driven Design and Patterns: With Examples in C# and .NET / J. Nilsson. -

Harlow : Addison Wesley Professional, 2006. – 576 p.

54. Olivé A. Conceptual Modeling of Information Systems / A. Olivé. – Berlin : Springer, 2007. – 471 p.

130

55. Övergaard G. Use Cases Patterns and Blueprints / G. Övergaard, K. Palmkvist. – Harlow: Addison

Wesley Professional, 2004. – 464 p.

56. Pressman R.S. Software Engineering. A Practitioners Approach / R.S. Pressman. – New York :

McGraw-Hill, 2001. – 888 p.

57. Pugh K. Interface-Oriented Design / K. Pugh. – Texas: The Pragmatic Programmers LLC, 2006. – 220

58. Rosenberg D. Use Case Driven Object Modeling with UML. Theory and Practice / D. Rosenberg, M.

Stephens. - New York: Springer-Verlag, 2007. – 471 p.

59. Salzman H. Software by Design. Shaping Technology and the Workplace / H. Salzman, S.R. Rosenthal.

– New York : Oxford, 1994. – 361 p.

60. Sametinger J. Software Engineering with Reusable Components / J. Sametinger. – Berlin: Springer-

Verlag, 1997. – 285 p.

61. Schmidt M. Implementing the IEEE Software Engineering Standards / M. Schmidt. – Indianapolis :

SAMS, 2000. – 255 p.

62. Shalloway A. Design Patterns Explained A New Perspective on Object-Oriented Design / A. Shalloway,

J.R. Trott. New York : Addison Wesley Professional, 2004. – 480 p.

63. Sherif M.H. Handbook of Enterprise Integration / M.H. Sherif. – London: CRC Press, 2010. – 730 p.

64. Shoval P. Functional and Object-Oriented Analysis and Design: An Integrated Methodology / P. Shoval.

– Hershey : Idea Group Publishing, 2007. – 357 p.

65. Spolsky J. User Interface Design for Programmers / J. Spolsky. –New York: Springer-Verlag, 2001. –

101 p.

66. Szyperski C. Component Software. Beyond Object-Oriented Programming / C. Szyperski, D. Gruntz, S.

Murer. – New York : Addison-Wesley, 2002. – 625 p.

67. Tang X. Web Content Delivery / X. Tang, J. Xu, S.T. Chanson. – New York : Springer, 2005. – 387 p.

68. Vasilecas O. Information Systems Development : Advances in Theory, Practice and Education / O.

Vasilecas, A. Caplinskas et al. – New York : Springer, 2005. – 550 p.

69. Volter M. Remoting Patterns. Foundations of Enterprise, Internet and Realtime Distributed Object

Middleware / M. Volter, M. Kircher, U. Zdun. – Chichester : John Wiley & Sons Ltd, 2005. – 424 p.

70. Wang L. Modern Industrial Automation Software Design / L. Wang, K. Tan. – New Jersey : John Wiley

& Sons, Inc., 2006. – 349 p.

71. Wang Y. Software Engineering Foundations. A Software Science Perspective / Y. Wang. – New York:

Auerbach Publications, 2008. – 1419 p.

72. Wodtke С. Information Architecture: Blueprints for the Web / С. Wodtke, A. Govella. – Berkeley : New

Riders, 2009. – 313 p.

73. Wout J. The Integrated Architecture Framework Explained / J. Wout, M. Waage, et al. - New York,

Springer, 2010. – 263 p.

74. Yacoub S.M. Pattern-Oriented Analysis and Design: Composing Patterns to Design Software Systems /

S.M. Yacoub, H.H. Ammar. - New York : Addison Wesley, 2003. – 416 p.

75. Амблер С. Гибкие технологии: экстремальное программирование и унифицированный процесс

разработки. Библиотека программиста / С. Амблер. – СПб: Питер, 2005. – 412 с.

76. Арлоу Д. UML 2 и Унифицированный процесс. Практический объектно-ориентированный анализ

и проектирование / Д. Арлоу, А. Нейштадт. – 2-е изд. – СПб: Символ-Плюс, 2007. – 624 с.

77. Бек К. Экстремальное программирование: разработка через тестирование / К. Бек. – СПб

.: Питер,

2003. – 224 с.

78. Белладжио Д. Стратегия управления конфигурацией программного обеспечения с

использованием IBM Rational ClearCase / Д. Белладжио, Т. Миллиган. – М.: ДМК Пресс, 2007. –

384 с.

79. Благодатских В.А. Стандартизация разработки программных средств / В.А. Благодатских, В.А.

Волнин, К.Ф. Поскакалов ; под ред. О.С. Разумова. – М.: Финансы и статистика, 2005. – 288 c.

80. Брауде Э.

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

655 с.

81. Буч Г. Объектно-ориентированный анализ и проектирование с примерами приложений / Г. Буч,

Р. Максимчук, М. Энгл и др. – 3-е изд. – М.: ООО «И.Д. Вильямс», 2008. – 720 с.

82. Вендров А.М. Проектирование программного обеспечения экономических информационных

систем / А.М. Вендров. – М.:

Финансы и статистика, 2006. – 544 с.