- оформления документации проекта;

- имитации объекта управления.

Возможные варианты затрат:

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

- аренда инструментального ПО в составе арендуемых СВТ;

- создание уникального инструментального ПО (редко встречающийся случай);

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

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

Зинфр -- затраты "на инфраструктуру", то есть на все необходимые для нормальной работы проектировщиков условия: оплата помещений, коммунальных услуг, электроэнергии, охраны, работы АУП и вспомогательного персонала и т.д.

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

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

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

Зтс (формула 1) - могут быть реализованы в следующих формах:

- приобретение СВТ для эксплуатации системы (возможно отнесение на систему некоторого процента от стоимости СВТ, пропорционально используемому ресурсу рабочего времени СВТ);

- аренда СВТ, в том числе лизинг оборудования.

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

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

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

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

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

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

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



Раздел 3. Практическая реализация

3.1 Rational Rose

Проектируемая система должна выполнять следующие функции:

- Учет информации о клиентах: возможность добавления, изменения, удаления.

- Учет информации о персонале: график работы, расписание использования залов.

- Информацию о абонентских картах;

- Информацию об оплате

Опишем процессы, происходящие в фитнес клубе.

Администратор:

- Регистрирует (заносит данные в базу) новых клиентов.

- Отмечает существующих (постоянных) клиентов.

- Редактирует записи.

- Удаляет записи.

Фитнес-менеджер:

- Составляет расписание работы тренеров.

- Вычисляет рейтинг тренеров.

- Контролирует состояние зала.

Бухгалтер:

- Принимает оплату услуг.

- Начисляет зарплату.

Построим диаграмму прецедентов, отображающую описанные процессы.



Рисунок 1 - Диаграмма прецедентов, отображающая процессы фитнес клуба

Построим основное логическое представление модели проектируемой ИС. В Rational Rose это диаграмма классов.

В проектируемой системе будет пять классов:

- Клиенты;

- Тренеры;

- Карты;

- Место тренировки;

- Оплата.

Определим атрибуты для каждого класса:

- Клиенты:

o ID Клиента (Номер карты)

o Фамилия

o Имя

o Контакты

o ID Тренера (Табельный номер)

- Тренеры:

o ID Тренера (Табельный номер)

o ФИО

o Контакты

o Оклад

o Рейтинг

- Карты

o Номер карты

o Вид карты

o Номер зала

o Стоимость

- Место тренировки (вид зала):

o Номер зала

o Описание

- Оплата

o ID клиента

o Месяц оплаты

o Наличие оплаты.

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

Рисунок 2 - Логическая модель информационной системы (диаграмма классов)

3.2 Создание базы данных

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

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

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

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

Между двумя сущностям, например, А и В возможны четыре вида связей.

Первый тип - связь ОДИН-К-ОДНОМУ (1:1): в каждый момент времени каждому представителю (экземпляру) сущности А соответствует 1 или 0 представителей сущности В:

Второй тип - связь ОДИН-КО-МНОГИМ (1:М): одному представителю сущности А соответствуют 0, 1 или несколько представителей сущности В.

Так как между двумя сущностями возможны связи в обоих направлениях, то существует еще два типа связи МНОГИЕ-К-ОДНОМУ (М:1) и МНОГИЕ-КО-МНОГИМ (М:N). В проектируемой модели такие связи отсутствуют.

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

- Текстовый. Текст или числа не требующие проведения расчётов.

- МЕМО. Поле этого типа предназначено для хранения небольших текстовых данных (до 64000 символов). Поле этого типа не может быть ключевым или проиндексированным.

- Числовой. Этот тип данных содержит множество подтипов. От выбора подтипа (размера) зависит точность вычислений.

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

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

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

- Дата/Время. Дата и время хранятся в специальном фиксированном формате.

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

- Гиперсвязь. Содержит адреса Web-страниц.

Определим типы данных для полей таблиц информационной системы в Таблице 2.



Таблица 2 - Типы данных

Клиенты
Поле	Тип Данных
ID Клиента	Числовой
Фамилия	Текстовый
Имя	Текстовый
Контакты	Текстовый
ID тренера	Числовой
Тренеры
ID тренера	Числовой
ФИО	Текстовый
Контакты	Текстовый
Оклад	Числовой
Рейтинг	Числовой
Место тренировки
Номер зала	Числовой
Описание	Текстовый
Карта
Номер	Числовой
Вид	Текстовый
Номер зала	Числовой
Стоимость	Числовой
Оплата
ID клиента	Числовой
Месяц оплаты	Текстовый
Наличие оплаты	Логический

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

Для создания базы данных нужно сначала запустить программу Microsoft Office Access 2010, для этого нужно проделать следующие действия: Пуск > Программы > Microsoft Office > Microsoft Office Access 2010.

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

Рисунок 3 - Создание БД в программе MS ACCESS 2010

Создадим таблицы заполним, определим типы данных у полей и ключевые атрибуты. Файл - Создание - Таблица. Как показано на рисунке 4.

Рисунок 4 - Создание таблиц в программе MS ACCESS 2010

Построим схему данных и определим связи. Работа с базами данных - Схема данных. Представим её на рисунке 5.



Рисунок 5 - Схема данных

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

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

Рисунок 6 - Запрос "Размер оклада в зависимости от рейтинга"



Рисунок 7 - Запрос "Контакты клиента"

Рисунок 8 - Перекрестный запрос "Занятие у тренера"

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

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



Рисунок 9 - Отчет "Тренеры"

Рисунок 10 - Отчет "Клиенты"

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

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

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

Источником данных для формы являются записи таблицы или запроса.

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

Рисунок 11 - Форма "Клиенты"



Раздел 4. Экономические аспекты проекта

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

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

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

1. Апостериорный подход - объединяет методы непосредственной оценки результатов внедрения информационных систем на этапе эксплуатации системы. Данные методы учитывают различные ключевые факторы до и после внедрения информационной системы и сравнение результата с затраченными усилиями на реализацию проекта внедрения системы.

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

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

Среди различных методов оценки эффективности внедрения информационных систем, наиболее привлекательны те методы, которые позволяют оценить искомую эффективность до реализации самого проекта, на этапе технико-экономического обоснования, другими словами, методы в рамках априорного подхода. К ним относятся такие хорошо известные методы, как оценка IRR (Internal Rate of Return), ROI (Return on Investment), TEI (Total Economic Impact), NPV (Net Present Value), BSC (Balanced Scorecard), EVA (Economic Value Added) и другие.

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

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

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

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

- Методология Total Economic Impact (TEI). С помощью методологии TEI компании могут продемонстрировать, обосновать и помочь понять осязаемую ценность проектов по внедрению информационных технологий руководству и главным акционерам. Если кратко, методология TEI состоит из четырех компонентов оценки инвестиционной стоимости: выгоды, расходы, риски и гибкость. Результатом модели является рассчитанные показатели ROI и Payback Period. К достоинствам модели можно отнести наглядный и понятный каждому лицу, принимающему решения о финансировании проекта, результат. Основной трудностью модели является непрозрачность определения прогнозных значений экономических выгод от внедрения, что является ноу-хау компании-разработчика данного метода.

- Методология Rapid Economic Justification (REJ). REJ - это методология экономической оценки, которая помогает организациям внедрять ИТ-решения в бизнес-процессы, а затем определять абсолютную финансовую прибыльность этих решений. Сущность методологии REJ состоит в том, что она гарантирует, что инвестиции в информационные технологии определяются в соответствии с поставленными целями, важными для данной организации. Методология REJ применяется к бизнес-процессам, в наибольшей степени влияющим на рост эффективности деятельности предприятия. Целью методологии REJ является разработка бизнес-плана, который поможет главным менеджерам лучше понять достоинства конкретных вложений в ИТ. Модель REJ состоит из пяти шагов: оценка бизнеса, выработка решения, оценка прибыли и затрат, выявление и учет потенциальных рисков, расчет финансовых показателей. По своей сути, методология REJ подобна методологии TEI и имеет схожие достоинства и недостатки. Кроме упомянутого выше, методология REJ помогает найти общий язык ИТ-специалистам и бизнес-менеджменту.

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

1. Определение затратной части проекта с использованием метода Total Cost of Ownership (TCO). Для расчета TCO необходимо учитывать такие показатели, как:

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

- стоимость программного обеспечения и его поддержка вендором;

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

- стоимость дальнейшей поддержки реализованного продукта;

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

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

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

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

3. Учет рисков, связанных с проектом внедрения.

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



Заключение

При разработке дипломного проекта были решены следующие задачи:

- Проведен анализ предметной области - фитнес-индустрии.

- Построена логическая модель данных с помощью программного средства Rational Rose.

- Построена Информационная система фитнес клуба с помощью программы MS ACCESS 2010.

- Изучены методики затрат и расчета окупаемости создания ИС.

Размещено на Allbest.ru