1.4.1 Обоснование проектных решений по техническому обеспечению

Техническое обеспечение представляет собой комплекс технических средств, предназначенных для обработки данных. В состав комплекса входят:

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

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

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

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

Каждый персональный компьютер должен иметь достаточный объемом оперативной памяти, наличие дисковых накопитель HDD, сетевую карту, монитор, принтер для печати. Компьютеры должны входить в локальную сеть. Требования по техническому обеспечению отображены в таблице 3

Таблица 3

1.4.2 Обоснование проектных решений по информационному обеспечению

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

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

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

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

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

· к унифицированным системам документации;

· к унифицированным формам документов различных уровней управления;

· к составу и структуре реквизитов и показателей;

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

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

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

«Чек на оплату» - документ предназначен для оформления продажи услуг и фиксация данного факта на ККМ. Предполагается, что расчет с клиентом производится немедленно и наличными деньгами или картой.

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

«Размещение» - документ осуществляет операцию размещения в номере и операцию изменения параметров проживания. При групповом размещении, документ вводится на основании документа «Бронирование», на каждый номер создается отдельный документ размещения. Документ предназначен как для размещения гостей в номере так и для изменения параметров текущего размещения гостей.

«Приходный кассовый ордер» - (ПКО) предназначен для учета поступлений наличных денежных средств.

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

· Оплата от покупателя (гостя).

· Возврат денежных средств подотчетником.

· Прочий приход денежных средств.

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

«Акт об оказании услуг» - документ предназначен для фиксации факта реализации услуг гостям. Увеличивает сумму долга гостя на регистре «Взаиморасчеты с гостями», фиксирует стоимость оказанных услуг на регистре «Продажи».

«Бронирование» - документ предназначен для бронирования номеров в гостинице. Описывает как индивидуальное, так и групповое бронирование. Бронирование возможно как с указанием гостей, которые будут проживать в номерах, так и без гостей. Забронированные в документе "Бронирование" номера (а так же прочие параметры) могут быть изменены при размещении, т.е. бронь не определяет, что селить надо так и только так, а является рекомендацией к заселению. При групповом бронировании, "главным в группе" считается гость, указанный в шапке документа.

«Ночной аудит» - производит начисление дебиторской задолженности гостям за оказанные услуги тарифа (с момента последнего ночного аудита). Также фиксируются продажи услуг.

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

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

· Оплата поставщику.

· Возврат денежных средств гостю.

· Выдача денежных средств подотчетнику.

· Прочий расход денежных средств.

«Распределение оплат» - документ предназначен для распределения предоплаченной суммы контрагента на долги гостей, проживающих за счет данного контрагента.

Выходные документы:

«Путевка» - документ предназначен для отражения данных по путёвке.

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

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

Экранную форму полного счета гостя можно увидеть на рисунке 8.

Рисунок 8: Экранная форма «Полного счета гостя»

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

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

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

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

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

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

· совместимость данных; соответствие данных реальному состоянию объекта;

· удобство и увеличение скорости совместной обработки данных;

· поддержка целостности данных.

База данных (БД) -- поименованная совокупность данных, отражающая совокупность объектов и их отношений в рассматриваемой предметной области.

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

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

· иерархическую;

· сетевую;

· реляционную модель.

Основными компонентами любой из этих моделей являются файлы (или таблицы).

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

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

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

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

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

1.4.3 Обоснование проектных решений по программному обеспечению

Программное обеспечение (ПО) включает совокупность компьютерных программ, описаний и инструкций по их применению на персонаотном компьютере или сервере.

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

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

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

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

К факторам, определяющим выбор конкретной ОС относятся:

ь требования к аппаратным средствам - IBM PC-совместимый компьютер;

ь поддержка сетевой технологии, и в частности поддержка стека протоколов TCP/IP;

ь надежность;

ь быстродействие.

Принимая во внимание тот факт, что выбранная ОС должна работать на платформе IBM PC, выбор, по большому счету, ограничивается двумя вариантами: можно выбрать либо ОС «семейства» MS Windows, или какой-либо свободно распространяемый клон ОС UNIX.

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

В качестве серверной операционной системы выбрана Microsoft Windows 2008 Server Standart Edition.

В качестве операционной системы для компьютеров пользователей выбрана Microsoft Windows XP.

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

Для реализации данной системы выбрана СУБД Microsoft SQL Server версии 2008. Такой выбор обоснован тем, что система 1С: Предприятие 8.1 в клиент-серверном варианте работы может работать только с данной СУБД - это требование системы 1С:Предприятие. К тому же данная СУБД уже установлена и успешно работает на предприятии.

Среди причин такой популярности следует отметить:

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

· глубоко развитые возможности интеграции с другими программными продуктами, входящими в состав MS Office и прочих, а также с любыми программными Продуктами, поддерживающими технологию OLE;

· богатый набор визуальных средств разработки.

В качестве специального программного обеспечения используется система 1С:Предприятие 8.1. Эта система используется и в качестве системы разработки и в качестве платформы функционирования разработанной конфигурации.

2. Проектная часть

2.1 Разработка проекта автоматизации

2.1.1 Этапы жизненного цикла проекта автоматизации

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

Обычно выделяют следующие общие этапы разработки информационной системы:

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

· технического задания на разработку информационной системы.

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

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

· Тестирование, ввод в опытную эксплуатацию. На этом этапе производится комплексная отладка подсистем информационной системы, поэтапное внедрение системы в эксплуатацию по подразделениям предприятия. По окончании этапа оформляется акт о приемке-сдаче системы в промышленную эксплуатацию.

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

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

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

1) Каскадная модель (рисунок 9), которая предусматривает последовательное выполнение всех вышеуказанных этапов в строго фиксированном порядке, причем переход на следующий этап возможен только после полного завершения предыдущего. Таким образом, эта модель предполагает разработку законченных продуктов на каждом этапе, что фактически исключает какое-либо изменение или уточнение требований пользователей. Эта «жесткая» модель хорошо работает только при разработке относительно простых ИС.

2) Итерационная модель (рисунок 10) тоже предусматривает последовательное выполнение этапов, но допускает возвраты на предыдущие этапы после выполнения очередного этапа, если возникнет необходимость корректировки их результатов с учетом результатов более поздних этапов. Эта модель более соответствует реальному процессу создания ИС, но и она не всегда позволяет оперативно учитывать возникающие изменения и уточнения.

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

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

Рисунок 9: Каскадная модель ЖЦ ИС

Рисунок 10: Поэтапная модель с промежуточным контролем

Рисунок 11: Спиральная модель ЖЦ ИС

Спиральная модель жизненного цикла может быть реализована с использованием прототипной или RAD-технологии (Rapid Application Development - быстрая разработка приложений). По этой технологии ИС разрабатывается путем последовательного расширения прототипов, начиная с детализации требований и заканчивая детализацией программного кода. Важной особенностью этой технологии является возможность активного участия на всех этапах разработки будущих пользователей системы. При использовании такой технологии возникает меньше ошибок и несоответствий между итерациями и требованиями пользователей, что позволяет, во-первых, сократить время разработки, а, во-вторых, в итоге получить систему, максимально удовлетворяющую заказчиков.

Существуют целый ряд стандартов, в которых регламентируется жизненный цикл ИС (и вообще программных систем) и предлагается определенная модель жизненного цикла. Базовым международным стандартом является стандарт ISO/IEC 12205, принятый в 1995г. В нем регламентированы основные группы процессов, включаемых в жизненный цикл ИС. Их всего пять:

· Договорные процессы, связанные с приобретением и поставкой ИС.

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

· Проектные процессы.

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

· функционирования системы.

· Специальные процессы (не рассматриваем).

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

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

· ГОСТ 34.601-90 - распространяется на автоматизированные системы и устанавливает стадии и этапы их создания. Кроме того, в стандарте содержится описание содержания работ на каждом этапе. Стадии и этапы работы, закрепленные в стандарте, в большей степени соответствуют каскадной модели жизненного цикла.

· ISO/IEC 12207:1995 - стандарт на процессы и организацию жизненного цикла. Распространяется на все виды заказного ПО. Стандарт не содержит описания фаз, стадий и этапов.

· Custom Development Method (методика Oracle) по разработке прикладных информационных систем - технологический материал, детализированный до уровня заготовок проектных документов, рассчитанных на использование в проектах с применением Oracle. Применяется CDM для классической модели ЖЦ (предусмотрены все работы/задачи и этапы), а также для технологий "быстрой разработки" (Fast Track) или "облегченного подхода", рекомендуемых в случае малых проектов.

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

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

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

· Extreme Programming (XP). Экстремальное программирование (самая новая среди рассматриваемых методологий) сформировалось в 1996 году. В основе методологии командная работа, эффективная коммуникация между заказчиком и исполнителем в течение всего проекта по разработке ИС, а разработка ведется с использованием последовательно дорабатываемых прототипов.

В соответствии с базовым международным стандартом ISO/IEC 12207 все процессы ЖЦ ПО делятся на три группы:

1. Основные процессы:

· приобретение;

· поставка;

· разработка;

· эксплуатация;

· сопровождение.

2. Вспомогательные процессы:

· документирование;

· управление конфигурацией;

· разрешение проблем;

· аудит;

· аттестация;

· совместная оценка;

· верификация.

3. Организационные процессы:

· создание инфраструктуры;

· управление;

· обучение;

· усовершенствование.

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

Позднее был разработан и в 2002 г. опубликован стандарт на процессы жизненного цикла систем (ISO/IEC 15288 System life cycle processes). К разработке стандарта были привлечены специалисты различных областей: системной инженерии, программирования, управления качеством, человеческими ресурсами, безопасностью и пр. Был учтен практический опыт создания систем в правительственных, коммерческих, военных и академических организациях. Стандарт применим для широкого класса систем, но его основное предназначение - поддержка создания компьютеризированных систем. Именно поэтому данный стандарт подходит для реализации в моем проекте.

Таблица 4.

Содержание основных процессов ЖЦ ПО ИС (ISO/IEC 12207)

Согласно стандарту ISO/IEC серии 15288 в структуру ЖЦ следует включать следующие группы процессов:

1. Договорные процессы:

· приобретение (внутренние решения или решения внешнего поставщика);

· поставка (внутренние решения или решения внешнего поставщика).

2. Процессы предприятия:

· управление окружающей средой предприятия;

· управление ЖЦ ИС;

· управление ресурсами;

· управление качеством.

3. Проектные процессы:

· планирование проекта;

· оценка проекта;

· контроль проекта;

· управление рисками;

· управление конфигурацией;

· управление информационными потоками;

· принятие решений.

4. Технические процессы:

· определение требований;

· интеграция;

· верификация;

· переход;

· аттестация;

· эксплуатация;

· сопровождение;

· утилизация.

5. Специальные процессы:

· определение и установка взаимосвязей исходя из задач и целей.

Стадии создания системы, предусмотренные в стандарте ISO/IEC 15288, несколько отличаются от рассмотренных выше. Перечень стадий и основные результаты, которые должны быть достигнуты к моменту их завершения, приведены в таблице 5.

Таблица 5

Стадии создания систем (ISO/IEC 15288)

Язык UML (Unified Modelling Language, стандарт ISO, 2005г.) - это графический язык разработки и спецификации проектов программных систем, предназначенный для описания, визуализации и документирования всех этапов процесса разработки: начиная от этапов анализа и обследования предметной области, построения логической модели данных для БД и кончая описанием структуры системы и ее программной реализации. Исторически при разработке информационных систем использовались три графических нотации:

· Диаграммы сущность-связь (Entity-Relationship Diagrams, EDR), предназначенны для графического описания модели данных предметной области: наборов сущностей и связей между ними.

· Диаграммы функционального моделирования (Structured Analysis and Design Technique, SADT), предназначенные для описания процессов функционирования системы. Диаграммы строятся по иерархическому принципу и позволяют в наглядной форме отобразить последовательность действий, необходимых для выполнения каждой функции системы. Было разработано несколько типов таких диаграмм:

o IDEF0, используемых для моделирования и документирования процессов производства (бизнес-процессов);

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

o IDEF2, предназначенных для описания поведения системы во времени. Следует заметить, что эта нотация не была полностью реализована.

· Диаграммы потоков данных (Data Flow Diagrams, DFD).

Ввиду того, что разрабатываемая доработка не является сложной и будет применяться только в условиях рассматриваемого предприятия, выберем каскадную модель. В качестве стандарта к разрабатываемой системе выбираем ISO/IEC 12207:1995.

Состав проектной команды ограничится одним программистом.

2.1.2 Ожидаемые риски на этапах жизненного цикла и их описание

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

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

2. Иллюзия снижения рисков участников проекта (заказчика и исполнителя). Каскадная модель предполагает разработку законченных продуктов на каждом этапе: технического задания, технического проекта, программного продукта и пользовательской документации. Разработанная документация позволяет не только определить требования к продукту следующего этапа, но и определить обязанности сторон, объем работ и сроки, при этом окончательная оценка сроков и стоимости проекта производится на начальных этапах, после завершения обследования. Очевидно, что если требования к информационной системе меняются в ходе реализации проекта, а качество документов оказывается невысоким (требования неполны и/или противоречивы), то в действительности использование каскадной модели создает лишь иллюзию определенности и на деле увеличивает риски, уменьшая лишь ответственность участников проекта. При формальном подходе менеджер проекта реализует только те требования, которые содержатся в спецификации, опирается на документ, а не на реальные потребности бизнеса. Есть два основных типа контрактов на разработку ПО. Первый тип предполагает выполнение определенного объема работ за определенную сумму в определенные сроки (fixed price). Второй тип предполагает повременную оплату работы (time work). Выбор того или иного типа контракта зависит от степени определенности задачи. Каскадная модель с определенными этапами и их результатами лучше приспособлена для заключения контракта с оплатой по результатам работы, а именно этот тип контрактов позволяет получить полную оценку стоимости проекта до его завершения. Более вероятно заключение контракта с повременной оплатой на небольшую систему, с относительно небольшим весом в структуре затрат предприятия. Разработка и внедрение интегрированной информационной системы требует существенных финансовых затрат, поэтому используются контракты с фиксированной ценой, и, следовательно, каскадная модель разработки и внедрения. Спиральная модель чаще применяется при разработке информационной системы силами собственного отдела ИТ предприятия.

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

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

Главным недостатком этих нотаций является отсутствие в них явных средств для объектно-ориентированного представления моделей сложных систем, что часто существенно ограничивает возможности создания адекватных моделей таких систем. Язык UML поддерживает концепцию объектно-ориентированного анализа и моделирования (ООАП), основанную на методологии представления предметной области в виде объектов, являющихся представителями соответствующих классов. С помощью UML строится ОО- модель программной системы, которая наглядно описывается с использованием определенных в языке диаграмм.

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

2.2 Информационное обеспечение задачи