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

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

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

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

В качестве языка программирования, при помощи которого, реализована проектируемая система, выбран язык C#.

Для доступа к данным используется технология ADO. Net, которая представляет собой набор библиотек, поставляемых с Microsoft. Net Framework, и предназначена для взаимодействия с различными хранилищами данных из. Net-приложений.

Для взаимодействия между удаленными узлами, на которых расположены компоненты проектируемого приложения, используется технология. Net Remoting, которая является объектно-ориентированной архитектурой для поддержки распределенных приложений в Microsoft.NET.

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

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

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

4. Управление информационным проектом

4.1 Выбор жизненного цикла разработки информационной системы

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

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

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

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

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

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

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

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

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

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

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

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

Характеристика	Каскадная	V-образная	Прототипирование	Спиральная	RAD	Инкрементная
Требования	2	5	2	5	4	2
Участники команды разработчиков	6	6	4	6	3	6
Коллектив пользователей	1	2	0	3	1	2
Типы проектов и рисков	3	4	6	8	7	6
Итого	12	17	12	22	15	16

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

4.2 Определение цели и области действия программного проекта

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

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

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

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

- внутренним;

- предназначен для автоматизации процесса планирования бюджета;

- использоваться в финансовом управление администрации Новоегорлыкского сельского поселения.

Проект не будет:

- предназначаться для использования всеми отделами администрации Новоегорлыкского сельского поселения;

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

4.3 Создание структуры пооперационного перечня работ

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

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

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

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

- происходит управление проектом;

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

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

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

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

Рисунок 4.1 - Схема декомпозиции работ

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

4.4 Идентификация задач и действий

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

В качестве программы управления проектами была выбрана Microsoft Office Project 2007. В MS Project предусмотрен обширный набор возможностей по гибкому конфигурированию вида ленточных диаграмм.

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

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

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

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

Проект представлен в виде графика Ганта на рисунке 4.2.

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

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

Рисунок 4.2 - Диаграмма Ганта. Лист 1

4.5 Распределение ресурсов проекта

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

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

Ресурсное планирование позволяет:

- оценить потребность в ресурсах конкретного типа;

- спланировать рациональное распределение потребности в ресурсах во времени;

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

- оценить суммарную стоимость проекта;

- контролировать расходование ресурсов при реализации проекта.

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

Ресурсы проекта представлены в сводной таблице загрузки ресурсов.

Рисунок 4.4 - Сводная таблица загрузки ресурсов

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

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



Рисунок 4.5 - Детальная таблица загрузки ресурсов

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

Уровень интеграции периодов реализации проекта может определятся пользователем.

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



Рисунок 4.6 - График использования ресурсов специалиста по вариантам использования

Рисунок 4.7 - Статистика проекта

Таким образом, общая стоимость работ составляет 93900 рублей.

4.6 Расписание проектных работ

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



Рисунок 4.8 - Фрагмент сетевой диаграммы

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

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

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

В сетевой диаграмме содержится следующая информация:

- название действия или идентификатор узла;

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

- время быстрейшего завершения действия;

- продолжительность этапа;

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

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

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

4.7 Оценка размера и возможности повторного использования ПО

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

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

- подсчет сток кода в качестве единиц оценки размера;

- подсчет функциональных точек в качестве единиц оценки размера;

- подсчет точек свойств в качестве единиц оценки размера;

- применение блиц-модели;

- применение модели Wideband Delphi.

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

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

4.8 Оценка экономической эффективности проекта

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

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

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

- повысить прозрачность процессов управления;

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

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

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

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

При разовой инвестиции расчет чистого приведенного дохода можно вычислить по следующей формуле:

Формула расчета чистого приведенного дохода:

где - чистый приведенный доход;

n - месяц;

- величина денежного потока в течение n месяцев, рубли;

- ставка дисконтирования;

- стартовые инвестиции, рубли;

Формула для расчета величины денежного потока:

где - величина денежного потока, рубли;

- выгоды от реализации проекта;

- суммарные ежемесячные затраты на реализацию проекта;

Затраты на реализацию проекта в первом месяце составляют 20000 рублей, во втором - 25000 рублей, в третьем - 30000 рублей, в четвертом т - 19000 рублей. Ставка дисконтирования равна 10,5%.

В таблице 21 представлен денежный поток за каждый месяц в отдельности.

Таблица 21 - Денежный поток по каждому месяцу

Месяц	0	1	2	3	4	5	6
Rk	-20000	-25000	-30000	-10000	25000	30000	35000

NPV=2170 рублей.

Поскольку величина чистой текущей стоимости 2170 рублей, то есть NPV > 0, то проект можно принять.

Коэффициент возврата инвестиций ROI позволяет оценить прибыльность инвестиций, вложенных в проект.

Формула для расчета коэффициента возврата инвестиций:

где  - чистый приведенный доход;

 - стартовые инвестиции, рубли;

При ROI > 100% - инвестиции прибыльны, при ROI < 100% - инвестиции убыточны.

.

Поскольку ROI = 102%, то есть ROI > 100% - инвестиции прибыльны.

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

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

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

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

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

Заключение

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

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

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

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

Список используемых источников

1. Анализ требований и создание архитектуры решений на основе Microsoft.NET. Учебный курс MSCD/Пер. с англ. - М.: Издательско-торговый дом «Русская редакция», 2004. - 416 с.: ил.

2. Бизнес-правила в среде разработки и моделирования. Проверено 19.01.2008.

3. Богданов, В. Управление проектами в Microsoft Project 2002 / В. Богданов. ? СПб.: Питер, 2003. - 604 с.

4. Буч, Г. Объектно-ориентированный анализ и проектирование с примерами приложений на С++./ Г. Буч. - М.: «Бином», СПб: «Невский диалект», 2001. - 560 с.

5. Бюджетный кодекс Российской Федерации. Постатейный научно-практический комментарий. Второе, дополнительное издание. - М: Агентство «Библиотечка «Российской газеты», 2006 - 288 с.

6. Бюджетные финансовые технологии. Проверено 25.04.2008.

7. Вендров, А.М. CASE-технологии. Современные методы и средства проектирования информационных систем. / А.М. Вендров. - Проверено 05.02.2008.

8. Вигерс, К. Разработка требований к программному обеспечению. / К. Вигерс. - М.: Изд.-торг. Дом «Русская Редакция», 2004. - 576 с.

9. Гамма, Э. Приемы объектно-ориентированного проектирования. Паттерны проектирования / Э. Гамма, Р. Хелм, Р. Джонсон, Дж. Влиссидес. - СПб: «Питер», 2001. - 368 с.

10. Грехэм, И. Объектно-ориентированные методы. Принципы и практика / И. Грехэм - М.: «Вильямс», 2004. - 1024 с.

11. Коберн, А. Быстрая разработка программного обеспечения.: Пер. с англ. / А. Коберн. - М.: ЛОРИ, 2002. - 462 с.

12. Коберн, А. Современные методы описания функциональных требований к системам.: Пер. с англ. / А. Коберн. - М.: ЛОРИ, 2002. - 364 с.

13. Конноли, Т. Базы данных. Проектирование, реализация и сопровождение. Теория и практика./ Т. Конноли, К., Бегг, А. Страчан. - М.: «Вильямс», 2001. - 632 с.

14. Концептуальное проектирование реляционный баз данных с использованием языка UML. . Проверено 05.02.2008.

15. Ларман, К. Применение UML и шаблонов проектирования. 2-е издание / К. Ларман - М.: «Вильямс», - 2002. - 496 с.

16. Леффингуэлл, Д. Принципы работы с требованиями к программному обеспечению. Унифицированный подход. / Д. Леффингуэлл, Д. Уидриг. - М.: «Вильямс», 2002. - 462 с.

17. Маклин, С. Microsoft.NET Remoting.: Пер. с англ. / С. Маклин, Дж. Нафтел, К. Ульямс. - М.: Издательско-торговый дом «Русская редакция», 2003. - 384 с.

18. Мацяшек Л.А. Анализ требований к проектированию систем. Разработка информационных систем с использованием UML / Л.А. Мацяшек. М.: Изд. Дом «Вильямс», 2002. - 432 с.

19. Мюллер Р.Дж. Базы данных и UML / Р. Дж. Мюллер. М: «ЛОРИ», 2002. - 420 с.

20. Нейбург, Э. Дж. Проектирование баз данных с помощью UML. / Э.Дж. Нейбург, Р.А. Максимчук. - М.: «Вильямс», 2002. - 420 с.

21. Олифер, В.Г. Основы сетей передачи данных./ В.Г. Олифер, Н.А. Олифер. Проверено 19.01.2008.

22. Описание предметной области с использованием UML при разработке программных систем. . Проверено 19.01.2008.

23. Проектирование и реализация баз данных Microsoft SQL Server 2000. Учебный курс MCAD, MCSE, MCDBA/Пер. с англ. - 2-е изд., испр. - М.: Издательско-торговый дом «Русская редакция», 2003. - 512 стр.: ил.

24. Полякова, Л.Н. Основы SQL БИНОМ. Лаборатория знаний, Интернет-университет информационных технологий. / Л.Н. Полякова. - ИНТУИТ.ру, - 2007. - 462 с.

25. Рамбо, Дж. UML: специальный справочник. / Дж. Рамбо, А. Якобсон, Г. Буч. - СПб: «Питер», 2001. - 632 с.

26. Разработка Windows-приложений на Microsoft Visual Basic. Net и Microsoft Visual C#.Net. Учебный курс MCAD, MCSD/Пер. с англ. - М.: Издательско-торговый дом «Русская редакция», 2003. - 512 стр.: ил.

27. Розенберг, Д. Применение объектного моделирования с использованием UML и анализ прецедентов. / Д. Розенберг, К. Скотт. - М.: «ДМК Пресс», 2002. - 436 с.

28. Скрипкин, К.Г. Экономическая эффективность информационных систем. К.Г. Скрипкин. - М.: ДМК Пресс, 2002. - 420 с.

29. Смирнова, Г.Н. Проектирование экономических информационных систем: Учебник Г.Н. Смирнова, А.А. Сорокин Под ред. Ю.Ф. Тельнова. ? М.: Финансы и статистика, 2003. - 512 с.

30. Тамре, Л. Введение в тестирование программного обеспечения: Пер. с англ. / Л. Тамре. - М.: Издательский дом «Вильямс», 2003. - 314 с.

31. Уилсон С. Принципы проектирования и разработки программного обеспечения. Учебный курс MCSD/Пер. с англ. - 2-е изд., испр. С. Уилсон, Б. Мейплс, Т. Лэндгрейв. - М.: Издательско-торговый дом «Русская редакция», 2002. - 736 стр.: ил.