Visual FoxPro -- визуальная среда разработки систем управления реляционными базами данных, выпускаемая в настоящее время корпорацией Майкрософт. Последней версией является 9.0. Использует язык программирования FoxPro. Версия системы 7.0 может работать в операционных системах Windows 9x и ядра NT, версии 8.0 и 9.0 - только в Windows XP, 2000, 2003.

FoxPro (Фокс-про?) -- один из диалектов языка программирования xBase. Применяется в основном для разработки реляционных СУБД, хотя возможно применять для разработки и других классов программ.Как уже отмечалось выше, язык VFP это сильно дополненный и расширенный язык xBase. В Visual FoxPro язык программирования, то есть базовой конструкцией языка является понятие класса. Исходный же вариант xBase это чистейший структурный язык, с базовым понятием процедур и функций. Таким образом, современный язык программирования Visual FoxPro допускает совмещать как и программирование "по старинке" описанием массы процедур, так и в стиле ООП, создавая сложную иерархию классов.

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

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

- Современная организация реляционных баз данных, позволяющая хранить информацию о таблицах базы, их свойствах, индексах и связях, задавать условия соблюдения ссылочной целостности, создавать локальные и удаленные представления (Views), связи с серверами, хранимые процедуры, исполняемые при наступлении более 50 различных видов событий (VFP 7.0-9.0).

- Высокая скорость работы с большими базами данных.

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

- Высокая скорость разработки приложений с использованием Мастеров (Wizard), Конструкторов (Designer), Построителей (Builder), режим подсказок IntelliSense при написании текста программ, системы отладки и тестирования программ.

- Возможность разработки приложений, работающих по технологии "клиент-сервер" с данными, размещенными на серверах баз данных Oracle и Microsoft SQL Server и с другими приложениями Microsoft Windows с использованием ODBC и OLE

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

2.5 Проектирование модулей

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

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

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

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

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

Менеджер открывает форму Приход.

Менеджер ставит дату заявки.

Менеджер ставит наименование товара.

Менеджер вносит количество поступаемого товара.

Менеджер вносит сумму заявки.

Менеджер закрывает форму.

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

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

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

3 Реализация и аттестация информационной системы

3.1 Реализация приложения

Реализация приложения по своей сути, является одним из трудоемких этапов для разработчика информационной системы, потому что, те требования, которые выдвигает заказчик, должны быть четко и корректно интегрированы в систему. Пока нет таких программных продуктов, которые могли бы «подстраиваться» под требования так называемого заказчика и выдавать определенный набор функций для реализации системы, которые будут соответствовать этим требованиям. Поэтому каждый разработчик должен выбрать для себя оптимальную среду для разработки системы, но следует заметить, что при реализации приложения никак не обойтись без написания программного кода. Именно при написании программного кода, будут реализовываться некие функции, которые должна выполнять система. В зависимости от выбранной среды реализации системы, программный код будет выглядеть по-разному, в такой среде как Microsoft Visual FoxPro будет один программный код, в Visual Basic другой и т.д.

В данном случае реализация приложения выполнялась в Microsoft Visual FoxPro.

Ниже будут описаны основные функции системы:

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

2. Кнопка меню приход. Даная кнопка позволяет провести учет поступающих товаров на склад магазина рис 3.2.

3. В кнопке меню расход ведется учет отпущенного товара со склада рис 3.3.

4. В кнопке меню доступа регулируются права пользования данной программой рис 3.4.

5. В кнопке меню остатки хранится информация о хранящихся материалах на складе магазина рис 3.5.

6. В кнопке меню касса храниться информация о приходных кассовых ордерах и расходных кассовых ордерах рис 3.6.

7. В кнопке меню переоценка проходит изменения цены на новую цену товара рис.3.7.

Рисунок 3.1 - Стартовая форма системы

Рисунок 3.2 - Форма учета поступлений материала на склад.

Рисунок 3.3- Форма учета отпущенного товара.

Рисунок 3.4- Форма регулирующая права доступа к программе.

Рисунок 3.5- Форма остатков товара на складе.

Рисунок 3.5-Форма о приходных кассовых ордерах и расходных кассовых ордерах.

Рисунок 3.6-Форма операций по товару.

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

На входе процесса тестирования три потока:
текст программы;
исходные данные для запуска программы;
ожидаемые результаты.
Выполняются тесты, все полученные результаты оцениваются. Это значит, что реальные результаты тестов сравниваются с ожидаемыми результатами. Когда обнаруживается несовпадение, фиксируется ошибка - начинается отладка.
После сбора и оценивания результатов тестирования начинается отображение качества и надежности ПО. Если регулярно встречаются серьезные ошибки, требующие проектных изменений, то качество и надежность ПО подозрительны, констатируется необходимость усиления тестирования.
Результаты, накопленные в ходе тестирования, могут оцениваться и более формальным способом. Для этого используют модели надежности ПО, выполняющие прогноз надежности по реальным данным об интенсивности ошибок.
Существуют 2 принципа тестирования программы:
функциональное тестирование (тестирование «черного ящика»);
структурное тестирование (тестирование «белого ящика»).
При тестировании методом «белого ящика» известна внутренняя структура программы. Объектом тестирования здесь является не внешнее, а внутреннее поведение программы. Проверяется корректность построения всех элементов программы и правильность их взаимодействия друг с другом.
Тестирование «черного ящика» (функциональное тестирование) позволяет получить комбинации входных данных, обеспечивающих полную проверку всех функциональных требований к программе //. Программное изделие здесь рассматривается как «черный ящик», чье поведение можно определить только исследованием его входов и соответствующих выходов.
Принцип «черного ящика» не альтернативен принципу «белого ящика». Скорее это дополняющий подход, который обнаруживает другой класс ошибок.
Тестирование «черного ящика» обеспечивает поиск следующих категорий ошибок:
некорректных или отсутствующих функций;
ошибок интерфейса;
ошибок во внешних структурах данных или в доступе к внешней базе данных;
ошибок характеристик (необходимая емкость памяти и т. д.);
ошибок инициализации и завершения.
Подобные категории ошибок способами «белого ящика» не выявляются.
В отличие от тестирования «белого ящика», которое выполняется на ранней стадии процесса тестирования, тестирование «черного ящика» применяют на поздних стадиях тестирования. При тестировании «черного ящика» пренебрегают управляющей структурой программы. Здесь внимание концентрируется на информационной области определения программной системы. При тестировании на этом этапе основное внимание уделяется пригодности решения для работы в условиях живого производства. Основное внимание уделяется исправлению ошибок и определению их важности, а также подготовки продукта к выпуску.
На этапе тестирования решают две основные задачи:
Тестирование решения - выполняются планы тестирования, созданные на этапе планирования и расширенные и опробованные на этапе разработки;
Пилотная эксплуатация - развертывание решения в тестовой среде и тестирование с привлечением будущих пользователей и реализацией реальных сценариев использования системы. Эта задача выполняется до начала этапа развёртывания.
Цель этапа тестирования - снижение риска, возникающего при вводе решения в промышленную эксплуатацию.
Для успеха этапа тестирования необходимо, чтобы произошла смена отношения к проекту и разработчик переключился с разработки новых функций на обеспечение должного качества решения.
На данной стадии разработки информационной системы необходимо провести следующие типы тестирования:
Базовое тестирование - низкоуровневое техническое тестирование. Проводится самим разработчиком в процессе написания программного кода. Применяется метод «белого ящика», высокий риск ошибок.
Тестирование на пригодность к использованию - высокоуровневое тестирование, выполняется тестировщиком и будущими пользователями продукта. Применяется метод «чёрного ящика».
Альфа- и бета-тестирование - в терминах MSF альфа-код - это в основном все исходные тексты, созданные на этапе разработки модели процессов MSF, а бета-код - код, прошедший тестирование на этапе тестирования. Поэтому на этапе разработки модели процесса MSF тестируется альфа-код, а на этапе тестирования - бета-код.
Тестирование совместимости - от разрабатываемого решения требуется возможность интеграции и способность к взаимодействию с существующими системами и программными решениями. Данная форма тестирования ориентирована на проверку интегрируемости и способности разрабатываемого решения взаимодействовать с существующими системами. В данном конкретном случае будет проверятся корректность работы приложения на оборудовании пользователя и используемым пользователем программным обеспечением.
Тестирование производительности - ориентировано на проверку того, удовлетворяет ли приложение требованиям по производительности и уровню комфортности работы по скорости.
Тестирование документации и справочной системы - тестируются все разработанные сопровождающие документы и справочные системы.
Пилотная эксплуатация - это тестирование решения в промышленной среде. Основная задача пилотной эксплуатации - продемонстрировать, что решение способно стабильно работать условиях промышленной эксплуатации и удовлетворяет требованиям бизнеса. В процессе пилотной эксплуатации решение испытывается в реальных условиях. Пилотная эксплуатация дает возможность пользователям высказать свое мнение о работе продукта. Руководствуясь этим мнением разработчиком устраняются все возможные неполадки или создается план действий на случай непредвиденных обстоятельств. В конечном итоге, пилотная эксплуатация позволяет принять решение, стоит ли начинать полномасштабное развертывание или отложить до устранения неполадок, способных сорвать развертывание.
План процесса пилотной эксплуатации для разрабатываемой информационной системы приведен в таблице 3.2.
Таблица 3.2 - План пилотной эксплуатации
Действие
Описание
1. Выбор критериев успеха
Разработчик и участники опытного тестирования определяют критерии успешности и согласовывают их
2. Выбор пользователей и места установки
Формируется команда участников опытного тестирования со стороны пользователей и разработчиков. Определяется место развертывания пилотного процесса.
3. Подготовка пользователей и места установки
Проводится обучение пользователей - участников испытания. Подготавливается место установки.
4. Развёртывание опытной версии
Устанавливается опытная версия и включается в работу.
5. Поддержка и мониторинг опытной версии
Контроль работы пользователей и системы, оказание помощи в эксплуатации, сбор сведений о работе системы
6. Обратная связь с пользователями и оценка результатов
Пользователи высказывают своё мнение о работе системы, указывают на недочёты и ошибки.
7. Внесение изменений и дополнений
Исправляются обнаруженные ошибки, вносятся изменения в дизайн или процесс. Исправленные результаты предоставляются для работы и оценки пользователям.
8. Решения о развертывании
Если результаты работы опытного тестирования удовлетворяют пользователей принимается решение о развертывании системы.
3.2 Методика развертывания приложения

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

Цели этапа развертывания:

ѕ ? перенести решение в промышленную среду;

ѕ ? признание заказчиком факта завершения проекта.

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

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

Для развертывания разрабатываемой системы был составлен план действий, который приведен в таблице 3.1.

Таблица 3.1 - План развертывания приложения

Действие	Описание действия
1. Резервное копирование	Производится резервное копирование данных пользователя при его участии и согласовании путем переноса информации на сменные носители (СD, DVD)
2. Установка базовых компонентов решения	Применение технологий, обеспечивающих работу решения. В данном случае - установка компонента Visual FoxPro
3. Установка клиентского приложения	Перенос на компьютер пользователя и установка окончательного варианта разработанной ИС и базы данных
4. Обучение	Производится обучение пользователей по работе с системой, разработчик убеждается в правильности и понимании работы ИС клиентами
5. Передача базы знаний проекта клиенту	Заказчику передаётся вся проектная документация
6. Закрытие проекта	Составляется отчёт о закрытии проекта. Заказчик подписывает акт приёмки.

Для нормального функционирования АРМ требуется операционная система Microsoft WindowsXP.

4 Управление информационным проектом
4.1 Выбор жизненного цикла разработки

Одним из базовых понятий методологии проектирования ИС является понятие жизненного цикла ее программного обеспечения (ЖЦ ПО). ЖЦ ПО - это непрерывный процесс, который начинается с момента принятия решения о необходимости его создания и заканчивается в момент его полного изъятия из эксплуатации.

Основным нормативным документом, регламентирующим ЖЦ ПО, является международный стандарт ISO/IEC 12207 (ISO - International Organization of Standardization - Международная организация по стандартизации, IEC - International Electro technical Commission - Международная комиссия по электротехнике). Он определяет структуру ЖЦ, содержащую процессы, действия и задачи, которые должны быть выполнены во время создания ПО.

Стандарт ISO/IEC 12207 не предлагает конкретную модель ЖЦ и методы разработки ПО. Под моделью ЖЦ можно понимать структуру, определяющую последовательность выполнения и взаимосвязи процессов, действий и задач, выполняемых на протяжении ЖЦ. Модель ЖЦ зависит от специфики ИС и специфики условий, в которых создается и функционирует.

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

спиральная модель (смотри рисунок 4.1);

итерационная модель.

Рисунок 4.1 - Спиральная модель ЖЦ ПО

Для создания информационной системы, т.е. «Автоматизированное рабочее место сотрудника склада оптовая база», была выбрана итерационная. Отличительным свойством итерационной модели можно назвать то, что она представляет собой формальный метод, она состоит из независимых фаз, выполняемых последовательно, и подвержена частому обзору (рисунок 4.2). Итерационный подход хорошо зарекомендовал себя при построении ИС, для которых в самом начале разработки можно достаточно точно и полно сформулировать все требования, с тем, чтобы предоставить разработчикам свободу реализовать их как можно лучше с технической точки зрения.

Преимущества итерационной модели:

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

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

стабильность требований;

модель доступна для понимания;

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

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

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

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

Рисунок 4.2 - Итерационная модель ЖЦ ПО

Фазы модели:

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

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

на стадии реализации идет разработка системы;

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

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

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

- Анализ отличительных категорий проекта, помещённых в таблицах.

- Ответить на вопросы, приведённые для каждой категории, подчеркнув слова «да» и «нет».

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

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

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

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

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

Целями программного проекта будут являться - создание и развертывание системы по учету товара. Данная система предназначена для внутреннего использования персоналом «Cleonelly» , в большей части сотрудниками склада предприятия.

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

Программный проект должен быть:

для внутреннего использования в организации;

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

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

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

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

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

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

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

разработка требований к программному обеспечению;

проектирование информационной системы;

реализация и аттестация информационной системы;

внедрение системы.

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

Пооперационный перечень работ (рисунок 4.3) был спроектирован с помощью программного продукта такого, как MS Project 2003.

Рисунок 4.3 - Пооперационный перечень работ

4.4 Оценка длительности и стоимости разработки ПО

Оценка длительности. Она определяется после построения пооперационного перечня работ (рисунок 4.3, пункт 4.3). Данную оценку длительности можно увидеть при помощи диаграммы Ганта (приложение К).

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

Диаграмма Ганта -- это один из наиболее популярных способов графического представления плана проекта, применяемый во многих программах управления проектами. [34]

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

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

Оценка затрат

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

Важное свойство ресурсов -- стоимость (Cost (Затраты)) их использования в проекте. В MS Project есть два типа стоимости ресурсов: повременная ставка и стоимость за использование.

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

В данном случае использовалась повременная ставка (рисунок 4.4) Общие затраты на использование ресурсов можно на рисунке 4.5.

Рисунок 4.4 - Повременная ставка в использовании ресурса

На данном рисунке можно увидеть, что разработчик системы при выполнении проекта получает 50 рублей в час; бизнес-аналитик получает 45 рублей в час, тестер 38 рублей в час. Ставка сверхурочных не учитывается.

Рисунок 4.5 - Общие затраты на использовании ресурсов проекта

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

Фрагмент распределения ресурсов для системы «Учета товара на складе» можно увидеть на рисунке 4.6

Рисунок 4.6 - Фрагмент распределения ресурсов проекта

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

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

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

Входные данные.

Дополнительная прибыль от реализации проекта (DP) = 38000 рублей. Дополнительна прибыль была спрогнозирована экспертами предприятия.

Стартовые инвестиции (IC) = 39396,47 рублей. Стартовые инвестиции соответствуют общим затратам на использование ресурсов проекта (рисунок 4.5 пункта 4.6)

Ставка дисконтирования (i) = 12%.

Срок, на который рассчитан проект (n) = 2 года.

Дополнительная прибыль от реализации проекта (DP) = 38000 рублей.

Ежегодные затраты на реализацию проекта (Z1) = 15000 рублей.

Ежегодные затраты на реализацию проекта (Z2) = 10000 рублей.

Годовые денежные поступления можно рассчитать по формуле 4.1.

(4.1)

Годовые денежные поступления (R1) = 23000 рублей.

Годовые денежные поступления (R2) = 28000 рублей.

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

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

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

Чистый приведенный доход (NPV) рассчитывается по формуле 4.2

(4.2)

Rk - годовые денежные поступления в течении n лет.

k - количество лет на сколько рассчитан проект.

IC - стартовые инвестиции.

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

По расчетам данной формулы NPV = 3460,67 руб.

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

Коэффициент возврата инвестиций (ROI) рассчитывается по формуле 4.3

(4.3)

По расчетам (ROI) = 108,78%

Далее необходимо рассчитать срок окупаемости проекта по упрощенной формуле: nок = Число лет до года окупаемости + (Не возмещенная стоимость на начало года окупаемости / Приток наличности в течение года окупаемости)

Таблица 4.1 ? Вспомогательная таблица расчёта срока окупаемости проекта

Показатели	Значения
Период (лет)	0	1	2
Денежный поток	-39396,47	23000	28000
Дисконтированный денежный поток	-39396,47	20535,71	22321,43
Накопленный дисконтированный денежный поток	-39396,47	-18860,76	3460,67

= 1,84

Срок окупаемости nok = 1,84 года (1 год и 11 месяцев)

Так как ROI = > 100% ( а именно = 108,78%) то проект считается прибыльным.

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

(4.4)

Таким образом, индекс прибыльности равен (PI) =1,2

Страницы: 1, 2