SQL Server 2005 и Visual Studio 2005 вместе предоставляют более глубокие уровни интеграции между базой данных и средой разработки приложений, чем это было возможно ранее. Разработчики теперь могут создавать управляемые хранимые процедуры, функции, пользовательские типы и пользовательские агрегаты непосредственно из среды Visual Studio. Они также могут развёртывать эти новые объекты базы данных непосредственно из Visual Studio без переключения в другие инструменты. Visual Studio 2005 непосредственно поддерживает все новые типы данных SQL Server, такие как встроенный XML. Также существует возможность добавить все управляемые объекты базы данных в ту же систему контроля версий, которая используется для проектов Visual Studio, что позволяет ещё теснее интегрировать и сделать более безопасным процесс разработки [1].

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

В настоящее время обязательной возможностью считается визуальное проектирование, когда программист строит свои приложения, используя готовые модули. Примером могут служить все современные пакеты для разработчиков - Borland Delphi, ,Microsoft Visual Studio 2005 и т.д.

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

В .NET Framework поддерживается прямая и обратная совместимость. В контексте .NET Framework обратная совместимость означает, что любое приложение, созданное в .NET Framework более ранней версии, будет выполняться и в более поздней версии. Прямая совместимость означает возможность выполнения приложения, созданного в более поздней версии .NET Framework SDK v 2.0, в .NET Framework более ранней версии.

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

Структура ADO.NET создана для решения задач современной модели разработки приложений. В то же время модель программирования по возможности приближена к ADO, что упрощает переход разработчиков ADO к новой среде. ADO.NET является неотъемлемой частью .NET Framework, оставаясь понятной программистам ADO [34].

.NET представляет собой совершенно новый способ создания распределенных настольных и встроенных приложений. Для типов .NET не нужны ни фабрики классов, ни поддержка Unknown, ни регистрация в системном реестре. Эти основные элементы СОМ не скрыты - их просто больше нет.

Специально для новой платформы Microsoft разработала новый язык программирования - С#, который впитал в себя многое из того лучшего, что есть в самых разных языках программирования, и так же является составной частью Microsoft Visual Studio 2005.

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

Основные возможности .NET следующие:

- полные возможности взаимодействия с существующим кодом;

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

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

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

- отсутствует сложность СОМ;

- действительное упрощение процесса развертывания приложения.

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

Microsoft Visual Studio 2005 продолжает поддерживать технологии Microsoft .NET Framework уже в версии Microsoft .NET Framework SDK v2.0, которые предоставляют общеязыковую среду выполнения и унифицированные классы программирования. Также в Visual Studio включена библиотека MSDN, содержащая документацию по данным инструментам разработки.

Платформа Microsoft.NET для отображения данных на компьютере конечного пользователя и его интерактивного взаимодействия с системой. предоставляет класс System.Windows.Forms.Form и большое разнообразие классов элементов управления, дочерних от класса Control. Функциональность уровня представления во многом определяется составом элементов управления, входящих в коллекцию Controls для конкретной формы.

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

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

Бизнес-логика описывается набором методов, реализующих бизнес-транзакцию. Для платформы Microsoft.NET это типовое решение сценарий транзакций использует прямой доступ к базе данных и базируется на использовании объектов классов DataCommand и DataReader технологии ADO.NET, а так же используя bindingSource, TableAdapter, DataSet . Класс, реализующий сценарий транзакций, обеспечивает прямой доступ к источнику данных и необходимую функциональность бизнес-логики. Для данного типового решения все обязанности по реализации бизнес-логики возлагаются на методы сценария транзакций.

Для разрабатываемой информационной системы выбрана платформа Microsoft Visual Studio 2005. В качестве языка реализации приложения выбран C#.

Выводы к разделу

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

На основании концептуальной модели данных для Microsoft SQL Server 2000 разработана физическая модель данных.

В качестве СУБД обосновано применение Microsoft SQL Server 2005 Enterprise Edition. Для разрабатываемой информационной системы была выбрана платформа Microsoft Visual Studio 2005. В качестве языка реализации приложения выбран C#.



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

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

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

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

.NET Framework -- это управляемая среда для разработки и исполнения приложений, обеспечивающая контроль типов. Эта среда управляет выполнением программы: она выделяет память под данные и команды, назначает разрешения программе или отказывает в их предоставлении, начинает исполнение приложения и управляет его ходом, а также отвечает за освобождение и повторное использование памяти, занятой ресурсами, более ненужными программе. .NET Framework состоит из двух основных компонентов: общеязыковой исполняющей среды (CLR) и библиотеки классов .NET Framework.

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

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

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

Размещено на http://www.allbest.ru/

Рисунок 3.1 - Пространство имен

Входящий в состав Microsoft .NET Framework SDK v2.0, в данном проекте использовалось следующее пространственное имя для подключения к базе данных (рисунок 3.2)

Размещено на http://www.allbest.ru/

Рисунок 3.2 - Пространственное имя для подключения к базе данных

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

В результате работы мастера проекта реализуется каркас формы являющийся экземпляром классов, унаследованного от System.Windows.Forms.Form. При отображении формы во время выполнения программы, этот класс будет использоваться как шаблон для отображения окна. Файлы С# имеют расширение «.cs». Код главной формы изображен на рисунке 3.3. Данная форма является диспетчерской, запускающей дочерние окна данного модуля.



Размещено на http://www.allbest.ru/

Рисунок 3.3 - Инициализация компонентов формы «Start.cs»

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

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



Размещено на http://www.allbest.ru/

Рисунок 3.4 - Пример обращения к базе данных

SQL используется для реализации всех функциональных возможностей, которые СУБД предоставляют пользователю:

- организация данных;

- выборка данных;

- обработка данных;

- совместное использование данных;

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

- целостность данных.

Взаимодействие приложения с источником данных осуществляется при помощи запросов языка SQL. SQL является инструментом для выборки и обработки информации, содержащейся в базе данных. SQL является языком программирования, который применяется для организации взаимодействия пользователя с базой данных [31]. Если пользователю необходимо получить информацию из базы данных, он запрашивает её у СУБД при помощи SQL. СУБД обрабатывает запрос, находит требуемые данные и посылает их пользователю [32]. Процесс запрашивания данных и получения результата называется запросом к базе данных.

На рисунке 3.5 представлен sql-запрос по составлению об установленном оборудовании.

Размещено на http://www.allbest.ru/

Рисунок 3.5 -Пример sql-запрос

На рисунке 3.6 показан результат выполнения предыдущего sql-запроса.

Рисунок 3.6 - Результат sql-запрос

Также для взаимодействия с источником данных используются хранимые процедуры, написанные на Transact-SQL - это диалект языка SQL, разработанный компанией Microsoft для использования в СУБД Microsoft SQL Server.

Использование хранимых процедур дает несколько очевидных преимуществ:

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

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

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

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

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

Размещено на http://www.allbest.ru/

Рисунок 3.7 - Код сценария создания хранимой процедуры
Report_order_client



Размещено на http://www.allbest.ru/

Рисунок 3.8 - Внешний вид отчета Форма принятия заказа

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

На рисунке 3.9 представлен класс MsSQLDataAdapter.

Рисунок 3.9 - Класс «MsSqlDataAdapter»



Функции CreateConnection() , OpenConnection(), CloseConnection() создают, открывают и закрывают соединение с сервером соответственно. Функции CreateCommand(), CreateParametrizedCommand() предназначены для создания параметризованных и обычных sql-команд. Для параметризованной команды необходимы параметры, которые создаются функциями CreateSqlParameter().

Рисунок 3.10 - Класс «UserGateWay»

Класс UserGateWay содержит специализированные функции. Например, функция GetUser() определяет идентификатор пользователя по логину и паролю, используется для проверки данных о пользователе при попытке авторизации. Функция GetStatusModules() получает список модулей, к которым разрешен доступ для пользователя с определенным статусом. Функция GetUserName() возвращает данные пользователя по его идентификатору. Функция GetPasswordHash() возвращает хэшированную строку пароля.

2.3 Тестирование приложения

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

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

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

Процесс тестирования представляет собой эксплуатацию приложения в контролируемых условиях и изучение полученных результатов [39]. При этом проверяется работа приложения с нормальными и ошибочными данными и событиями. Следует изучить и реакцию на неожиданные ситуации.

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

Для тестирования разрабатываемого проекта была выбрана методика тестирования «черного ящика». Эта методика применяется в качестве средства тестирования функционала разрабатываемого программного обеспечения.

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

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

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

Таблица 3.1 наращиваемый подход к тестированию

Действие	Ожидаемый результат	Реальный результат
Ввести информацию о поставщиках	Внесенная информация о поставщиках	Внесенная информация о поставщиках
Сформировать заказ	Сформированный заказ	Сформированный заказ
Внесение изменений в заказ	Заказ с изменениями	Заказ с изменениями
Утвердить заказ	Утвержденный заказ	Утвержденный заказ
Составить план работ	Составленный план работ	Составленный план работ
Утвердить план работ	Утвержденный план работ	Утвержденный план работ
Составить акт о выполненной работе	Составленный акт	Ошибка
Сформировать прайс	Сформированный прайс	Сформированный прайс

Рисунок 3.11 - Ошибка приложения при составлении акта

Для наибольшего избегания ошибок в составлении запросов используются инструменты SQL Server. Первоначально запрос создается в SQL Server, там же тестируется (рисунок. 3.12).



Рисунок 3.12 Составление sql - запроса

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

2.4 Методика развертывания приложения

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

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

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

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

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

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

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

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

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

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

Для создания установочного файла setup.exe была использована программа CreateInstall.

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

Рисунок 3.13 - Рабочее пространство программы

Для нормального функционирования АРМ требуется операционная система Microsoft Windows XP, а также система управления базами данных MS SQL Server 2005. Платформа .NET Framework должна быть установлена до установки приложения. Для развертывания приложения необходимо, чтобы на жестком диске объем свободного места был не менее 20 Мб. Для установки приложения был создан файл setup, автоматически сгенерировавший инсталляционный пакет проекта. Для установки системы достаточно запустить файл setup.exe, и далее следовать инструкциям мастера установки.

Рисунок 3.14 - Окно мастера установки

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

Рисунок 3.15 - Окно мастера установки, запрашивающее путь для установки

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

Рисунок 3.16 - Процесс установки

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

Выводы к разделу

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

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

Продемонстрирована реализация взаимодействия компонента с СУБД. Описана методика развертывания приложения средствами программы CreateInstall.



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

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

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

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

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

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

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

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

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

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

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

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

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

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

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



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

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

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

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

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

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

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

Задачи:

- выполнить сбор, спецификацию и аттестацию требований;

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

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

- провести тестирование программного продукта.

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

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

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

- применяться в операционных системах Windows;

- предназначен для автоматизации процессов предприятия.

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

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

- использоваться в системах отличных от Windows.

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

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

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

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

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

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

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

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

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

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

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



Рисунок 4.1 - Структура пооперационного перечня работ

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

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

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

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

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

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

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

Идентификации задач и действий структуры пооперационного перечня работ изображена на рисунке 4.2

Рисунок 4.2 - Идентификация задач и действий

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

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

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

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

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

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

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

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

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

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

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

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



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

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

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

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

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

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

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

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

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

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

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

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

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

Любой разрабатываемый проект состоит из задач, которые необходимо выполнить для достижения определенного (необходимого) результата. Для того чтобы стало возможным выполнение той или иной задачи необходимо что-либо сделать для этого, то есть затратить какие-либо ресурсы (трудовые, материальные, интеллектуальные) [16].

Одним из наиболее важных свойств любого ресурса является стоимость (Cost (Затраты)) его использования в проекте. В MS Project выделяется два типа стоимости ресурсов: повременная ставка и стоимость за использование. Повременная ставка (Rate) выражается в стоимости использования ресурса в единицу времени, например 100 рублей в час или 1000 рублей в день. Повременная ставка используется для людских, а также для каких-либо материальных ресурсов. В таком случае стоимость участия ресурса в проекте составит время, в течение которого он работает в проекте, умноженное на почасовую ставку. В разработанном проекте использовалась повременная ставка (рисунок 4.4) Общие же затраты на использование ресурсов по всему проекту можно увидеть на рисунке 4.5.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Общая стоимость работ составляет 68 000 рублей.

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

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

Существует ряд методик оценки эффективности проектов, основанных на единой методологической базе и отличающихся условиями применимости и предметными областями. Эффективность проекта - это категория, отражающая соответствие проекта целям и интересам его участников [23]. Некоторые специалисты считают, что возможна только качественная оценка эффективности внедрения информационных системы, и невозможно оценить эффективность вложения средств в цифрах и существуют только косвенные показатели [35]. В результате внедрения информационной системы предприятия удастся достичь следующих результатов:

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

- увеличить эффективность процесса взаимодействия с клиентами и поставщиками;

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

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

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

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

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

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

(4.1)

где		-	чистый приведенный доход;
	n	-	месяц (k = 1, 2, …, n);
		-	величина денежного потока в течение n месяцев, рубли;
		-	ставка дисконтирования;
		-	стартовые инвестиции, рубли;

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

(4.2)

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

В таблице 4.2 представлены затраты на реализацию проекта.

Таблица 4.2 - Затраты на реализацию проекта

Месяц	0	1	2	3
Zk	14000	20000	24000	10000

Ставка дисконтирования равна 11,5% /30/.

Денежный поток проекта - это зависимость от времени денежных поступлений и платежей при реализации проекта, определяемая для всего расчетного периода [23]. В таблице 4.3 представлен денежный поток за каждый месяц в отдельности.

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

Ме сяц	0	1	2	3	4	5	6
	убыток	прибыль	убыток	прибыль	убыток	прибыль	убыток	прибыль	убыток	прибыль	убыток	прибыль	убыток	прибыль
Rk	14000		20000		24000		10000			20000		23000		31000

NPV=3474 рублей.

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

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

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

(4.3)

где		-	чистый приведенный доход;
		-	стартовые инвестиции, рубли;

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

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

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

Выводы к разделу

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