|
Категория
|
Описание
|
|
F
|
Функциональные требования,
описывающие требуемую функциональность или прецеденты системы
|
|
S
|
Системные требования, такие
как используемые платформы
|
|
P
|
Требования к представлению
|
|
R
|
Требования, определяющие
риски, которым должно быть уделено основное внимание при разработке системы
|
Функциональные требования категории F представляют собой перечень
сервисов, которые должна выполнять система. При этом необходимо указать, как
система реагирует на входные данные.
Описание функциональных требований представлены в таблице 1.2.
Таблица
1.5 - Функциональные требования
|
Требование
|
Тип
|
Описание
|
|
Аутентификация пользователя
|
F
|
Для работы в системе
необходимо пройти аутентификацию
|
|
Непротиворечивый ввод
данных
|
F
|
Проверка типов данных на
стадии ввода
|
|
Отчеты по требованию
|
F
|
Отчеты, которые запрашивают
вышестоящие органы
|
Второй категорией в описании требований является категория системных
требований - S. Описания системных требований представлены в таблице 1.3.
Таблица
1.6 - Системные требования
|
Требование
|
Тип
|
Описание.
|
|
Архитектура
|
S
|
Pentium IV 1GHz CPU
|
|
Платформа
|
S
|
Windows XP
|
|
СУБД
|
S
|
MySQL 5.1.40
|
|
Язык программирования
|
S
|
.NET Framework C#
|
|
Информационно-логический
язык
|
S
|
Язык структурированных
запросов SQL Transact-SQL расширение языка SQL
|
Требования к представлению (Р) относятся к третьей категории. Они
описывают формирование требований заказчика к интерфейсу программного
обеспечения. Описания требований к представлению показаны в таблице 1.4.
Таблица
1.7 - Требования к представлению
|
Требование
|
Тип
|
Описание.
|
|
Интерфейс рабочего окна
|
P
|
Простая и строгая, не
раздражающая глаза цветовая гамма
|
|
Корректный ввод данных
|
P
|
Данные несоответствующих
типов не принимаются, выдается предупреждение
|
|
Простота интерфейса
|
P
|
Интуитивно понятный
интерфейс
|
К четвертой категории относятся требования к рискам (R). Данная категория
требований направлена на общую безопасность системы и решает такие вопросы как
сохранение непротиворечивости состояния баз данных, защиту от вторжений,
резервное копирование и восстановление. Описания требований к рискам
представлены в таблице 1.5.
Таблица
1.8 - Требования к рискам
|
Требование
|
Тип
|
Описание
|
|
Соответствие значений в
таблицах внесенным данным
|
R
|
Поля в таблицах должны
соответствовать типу введенных данных
|
|
Построение отчетов
|
R
|
Полное соответствие
содержимому в таблицах
|
|
Сохранность и целостность
данных
|
R
|
Система должна обеспечивать
сохранность данных в случае непредвиденных сбоях
|
На основе описания требований составляется документ, именуемый
Спецификацией. Спецификация требований - документ, в котором точно указываются
функции и возможности, которыми должно обладать ПО, а также необходимые
ограничения.
Спецификация требований (Software Requirements Specification, SRS)
используется для текущего сопровождения проекта и представления требований,
сформулированных по отношению к проекту. SRS позволяет определить предметную
область программного продукта, рассматриваемого относительно трех его основных
составляющих: данных, процесса и поведения. Спецификация SRS позволяет от
определения предметной области проекта перейти к области решений, определив три
модели требований, отображающие характеристики данных, процесса и поведения
[11, 12]. Данный документ должен содержать состав и наименование комплексов
задач, требования по изменению организационной структуры, состав обеспечивающих
подсистем [13]. Спецификация требований к программному обеспечению представлена
в Приложении A.
1.7 Аттестация требований
Данный раздел включает в себя формирование «Технического задания».
Техническое задание - исходный документ на проектирование технического
объекта. ТЗ устанавливает основное назначение разрабатываемого объекта, его
технические характеристики, показатели качества и технико-экономические
требования, предписание по выполнению необходимых стадий создания документации
(конструкторской, технологической, программной и т. д.) и её состав, а также
специальные требования.
Задание как исходный документ на создание чего-то нового существует во
всех областях деятельности, различаясь по названию, содержанию, порядку
оформления и т. п. (например, проектное задание в строительстве, боевое
задание, домашнее задание, договор на литературное произведение и т. д.).
В соответствии с Гражданским кодексом, проектирование - это один из видов
подрядных работ, результатом которых является продукция (проект), то есть
комплект проектной документации на другой продукт (объект проектирования).
Проект предназначен для создания объекта, его эксплуатации, ремонта и
ликвидации, а также для проверки или воспроизведения промежуточных и конечных
решений, на основе которых этот объект был разработан.
Участников проектных работ разделяют на потребителей (заказчиков этих
работ) и поставщиков (исполнителей этих работ, подрядчиков).
Исполнителя-специалиста называют проектировщиком или разработчиком.
Поставщиком, как и потребителем продукции, может быть организация (юридическое
лицо) или конкретный человек (физическое лицо).
Техническое задание является юридическим документом - как приложение
включается в договор между заказчиком и исполнителем на проведение проектных
работ и является его основой: определяет порядок и условия работ, в том числе
цель, задачи, принципы, ожидаемые результаты и сроки выполнения. Все изменения,
дополнения и уточнения формулировок ТЗ обязательно согласуются с заказчиком и
им утверждаются. Это необходимо и потому, что в случае обнаружения в процессе
решения проектной задачи неточностей или ошибочности исходных данных возникает
необходимость определения степени вины каждой из сторон-участниц разработки,
распределения понесенных в связи с этим убытков.
Целью разработки ТЗ проекта АИС является оценка основных параметров,
ограничивающих проект информационной системы, обоснование выбора и оценка
основных проектных решений по отдельным компонентам проекта.
Подробно техническое задание описано в Приложение Б.
К современным методам выявления требований относится использование
программных прототипов.
Прототипирование - это наиболее часто используемый современный метод
выявления требований. Программные прототипы конструируются для визуализации
системы или ее части для заказчиков с целью получения их отзывов.
Прототип - это эффективный способ выявления требований, которые трудно
получить от заказчика с помощью других средств. Прототипы позволяют решать три
основные задачи:
– прояснение и завершение процесса формулировки требований;
– исследование альтернативных решений;
– создание конечного продукта.
Прототип представляет собой демонстрационную систему - сделанную рабочую
модель решения, которая представляет графический пользовательский интерфейс
(GUI) и моделирует поведение системы при инициировании пользователем различных
событий.
Сложность современных GUI-интерфейсов делают прототипирование
обязательным элементом разработки ПО. Прототипы позволяют оценить реализуемость
и полезность разрабатываемой системы до начала ее реализации [14].
Иерархия окон приложения для клиента Администратор показана на рисунке
1.6.
На данной схеме обычное диалоговое окно показано в виде прямоугольника с
удвоенной границей. Окно сообщений показано прерывистой границей. Вкладки окон
показаны прямоугольником использующую левую сторону для соединения.
Иерархия окон приложения для клиента сотрудника отдела кадров показана на
рисунке 1.7.
Иерархия окон приложения для клиента бухгалтера показана на рисунке 1.8.
Прототип диалогового окна показан на рисунке 1.9.
Прототип главного окна показан на рисунке 1.10.
Выводы к разделу
В данном разделе пройдены следующие этапы проектирования:
– в качестве возможных решений проанализированы две программы: «1С:Предприятие»
и «БухСофт: Предприятие»;
– методологией проектирования информационной системы выбран
объектно-ориентированный подход;
– проанализирована предметная область;
– проведено интервью с бухгалтером предприятия о требованиях к
информационной системе;
– простроена диаграмма вариантов использования и диаграмма классов.
– результатом стало создание технического задания, на основании
которого будет создаваться информационная система.
2.
Проектирование информационной системы
2.1 Архитектурное проектирование
Информационная система «Расчёт зарплаты» имеет клиент-серверную
архитектуру.
В компьютерных технологиях клиент-серверная архитектура предполагает
наличие следующих компонентов приложения: клиентское приложение (обычно говорят
«тонкий клиент» или терминал), подключенное к серверу, который в свою очередь
может быть подключен к серверу базы данных. В качестве сервера может выступать
система управления базами данных. Пример клиент-серверной архитектуры показан
на рисунке 2.1.
Клиент - это интерфейсный (обычно графический)
компонент, который представляет собственно приложение для конечного
пользователя.
Сервер базы данных обеспечивает хранение данных.
Обычно это стандартная реляционная или объектно-ориентированная СУБД.
Достоинства:
– масштабируемость;
– конфигурируемость - изолированность уровней
друг от друга позволяет быстро и простыми средствами переконфигурировать
систему при возникновении сбоев или при плановом обслуживании на одном из
уровней;
– высокая безопасность;
– высокая надёжность;
– низкие требования к скорости канала (сети)
между терминалами и сервером приложений;
– низкие требования к производительности и
техническим характеристикам терминалов, как следствие снижение их стоимости.
Диаграмма компонентов для ИС «Расчёт зарплаты»
показана на рисунке 2.2 [16].
Диаграмма развертывания для ИС «Расчёт зарплаты» показана на рисунке 2.3.
2.2 Проектирование баз данных
База данных (БД) - это совокупность структурированных и взаимосвязанных
данных и методов, обеспечивающих добавление выборку и отображение данных [17].
База данных - это единое, большое хранилище данных, которое однократно
определяется, а затем используется одновременно многими пользователями из
разных подразделений [18].
Проектирование базы данных - процесс создания проекта базы данных, предназначенной
для поддержки функционирования предприятия и способствующей достижению его
целей.
Основными целями проектирования базы данных являются:
– представление данных и связей между ними, необходимых для всех
основных областей применения данного приложения и любых существующих групп его
пользователей;
– создание модели данных, способной поддерживать выполнение любых
требуемых транзакций обработки данных;
– разработка предварительного варианта проекта, структура которого
позволяет удовлетворить все основные требования, предъявляемые к
производительности системы [19].
При создании базы данных проходят 3 этапа её разработки:
. концептуальное моделирование;
2. логическое моделирование;
. физическое моделирование.
Концептуальная модель данных - записанные знания о физических и
логических объектах реального мира (люди, компоненты инфраструктуры, наряды на
работу, договора, соглашения и т. д.), которыми необходимо управлять наиболее
рациональным образом. Концептуальная модель информационной системы представлена
на рисунке 2.4.
Логическая модель данных - описание объектов предметной области, их
атрибутов и взаимосвязей между ними в том объеме, в котором они подлежат
непосредственному хранению в базе данных системы. Строится на основе
концептуальной модели данных.
При проектировании логической структуры реляционной базы данных
определяется оптимальный состав таблиц для хранения исходной информации. Для
каждой таблицы указывается ее название, перечень полей и первичный ключ.
Идентифицируются связи между таблицами. В рамках логического проектирования БД
могут формулироваться ограничения целостности, приниматься решения о создании
индексов [20].
Логическая модель предоставлена на рисунке 2.5.
2.3 Проектирование пользовательского интерфейса
Интерфейс пользователя (UI) - это часть программы, которая находится на
виду у пользователя и призвана обеспечивать отображение данных, управление или
диалог с пользователем.
Графический интерфейс пользователя (ГИП), графический пользовательский
интерфейс (ГПИ) - разновидность пользовательского интерфейса, в котором
элементы интерфейса (меню, кнопки, значки, списки и т. п.), представленные
пользователю на дисплее, исполнены в виде графических изображений.
В отличие от интерфейса командной строки, в ГПИ пользователь имеет
произвольный доступ (с помощью устройств ввода - клавиатуры, мыши, джойстика и
т. п.) ко всем видимым экранным объектам (элементам интерфейса) и осуществляет
непосредственное манипулирование ими. Чаще всего элементы интерфейса в ГИ
реализованы на основе метафор и отображают их назначение и свойства, что
облегчает понимание и освоение программ неподготовленными пользователями
(рисунок 2.6).
Чаще всего заказчик судит о качестве разработанного программного продукта
по интерфейсу. Пользовательский интерфейс представляет собой совокупность
программных и аппаратных средств, обеспечивающих взаимодействие пользователя с
компьютером. Основу такого взаимодействия составляют диалоги. Под диалогом
понимается регламентированный обмен информацией между человеком и компьютером,
осуществляемый в реальном масштабе времени и направленный на совместное решение
конкретной задачи: обмен информацией и координация действий. Диалог состоит из
отдельных процессов ввода-вывода, которые физически обеспечивают связь
пользователя и компьютера [23]. Пример диалогового окна показан на рисунке 2.7.
2.4 Обоснование выбора платформы
При разработке автоматизированной информационной системы «Расчёт
зарплаты» были использованы следующие программные продукты:
– MS Office Visio 2007;
– MS Office Project 2007;
– MS Visual Studio 2008, язык программирования C#;
– MySQL 5.1.40;
– Rational Rose v 7.0.
Для разработки информационной системы «Расчёт зарплаты» будет
использована платформа Microsoft .NET и объектно-ориентированный язык
программирования C# [25].
Совокупность средств, с помощью которых программы пишутся,
корректируются, преобразуются в машинные коды, отлаживаются и запускаются,
называют средой разработки или оболочкой. Платформа .Net или .Net Framework
-это среда разработки программ, которая объединенияет новейшие технологии
компании Microsoft, позволяющие разрабатывать разнотипные приложения на
различных языках программирования под различные операционные системы.
.NET Framework является надстройкой над операционной системой, в качестве
которой может выступать любая версия Windows, Unix и состоит из ряда
компонентов. Так, .NET Framework включает в себя:
– Четыре официальных языка: С#, VB.NET, Managed C++ и JScript .NET;
– Общеязыковую объектно-ориентированную среду выполнения CLR
(Common Language Runtime), совместно используемую этими языками для создания
приложений;
– Ряд связанных между собой библиотек классов под общим именем FCL
(Framework Class Library).
C# - это язык программирования, предназначенный для разработки самых
разнообразных приложений, предназначенных для выполнения в среде .NET
Framework. Язык C# прост, строго типизирован и объектно-ориентирован. Благодаря
множеству нововведений C# обеспечивает возможность быстрой разработки
приложений, но при этом сохраняет выразительность и элегантность, присущую
языкам C. Visual C# является реализацией языка C# корпорацией Майкрософт.
Visual Studio поддерживает Visual C# с полнофункциональным редактором кода,
компилятором, шаблонами проектов, конструкторами, мастерами кода, мощным и
простым в использовании отладчиком и многими другими средствами. Библиотека
классов .NET Framework предоставляет доступ ко многим службам операционной
системы и другим полезным, правильным классам, что существенно ускоряет цикл
разработки.
Среда разработки Visual Studio 2008 представляет собой полный набор
инструментов для создания как настольных приложений, так и корпоративных
веб-приложений для совместной работы групп. Используя эффективные инструменты
разработки Visual Studio 2008, основанные на использовании компонентов, и
другие технологии, можно не только создавать эффективно работающие настольные
приложения, но и упрощать совместное проектирование, разработку и развертывание
корпоративных решений.
В платформе .NET определено множество типов (организованных в
соответствующие пространства имен) для взаимодействия с локальными и удаленными
хранилищами данных. Общее название пространств имен с этими типами - ADO.NET.
.NET - это библиотека управляемого кода и взаимодействие с ней производится как
с обычной сборкой .NET. Типы ADO.NET используют возможности управления памятью
CLR и могут использоваться во многих .NET - совместимых языках. При этом
обращение к типам ADO.NET (и их членам) производится практически одинаково вне
зависимости от того, какой язык используется [27].
В состав ADO.NET включены два управляемых провайдера: провайдер SQL и
провайдер OleDb. Провайдер SQL специально оптимизирован под взаимодействие с
Microsoft SQL Server версии 7.0 и последующих. Для других источников данных
предлагается использовать провайдер OleDb, который можно использовать для
обращения к любым хранилищам данных, поддерживающим протокол OLE DB. Следует
отметить, что провайдер OleDb работает при помощи «родного» OLE DB и требует
возможности взаимодействия при помощи СОМ.- Реляционная СУБД (Система
управления реляционными базами данных). MySQL является небольшой и быстрой
реляционной СУБД основанной на Hughes Technologies Mini SQL (mSQL).
Преимущества MySQL по сравнению с другими СУБД:
– многопоточность. Поддержка нескольких одновременных запросов;
– кроссплатформенность;
– оптимизация связей с присоединением многих данных за один проход;
записи фиксированной и переменной длины;
– гибкая система привилегий и паролей;
– до 16 ключей в таблице. Каждый ключ может иметь до 15 полей;
– поддержка ключевых полей и специальных полей в операторе;
– поддержка чисел длинной от 1 до 4 байт, строк переменной длины и
меток времени;
– основанная на потоках, быстрая система памяти;
– утилита проверки и ремонта таблицы (isamchk);
– все данные хранятся в формате ISO8859_1;
– все операции работы со строками не обращают внимания на регистр
символов в обрабатываемых строках;
– псевдонимы применимы как к таблицам, так и к отдельным колонкам в
таблице;
– все поля имеют значение по умолчанию;
– легкость управления таблицей, включая добавление и удаление
ключей и полей.
2.5 Проектирование
модулей
Основной задачей проектирования является превращение модели анализа в
документы детализированного проектирования, на основе которых реализуется система.
Логическая модель проектируемой подсистемы строится на основе технологии
Rational и использует основные объектно-ориентированные подходы языка UML.
В процессе проектирования используются нефункциональные требования к
системе и ограничения налагаемые на архитектуру, в результате чего модель
анализа приобретает новую форму - модель проектирования, которая затем может
быть напрямую реализована в виде программного кода.
Для автоматизации всех требований Заказчика, собранных в разделе 1,
информационная система должна содержать следующие модули:
– модуль расчёта зарплаты;
– модуль вывода отчёта;
– модуль ввода информации о сотрудниках;
– модуль управления пользователями;
На основе этих данных можно построить диаграмму деятельности и диаграмму
состояний.
Диаграмма деятельности - диаграмма, на которой показано разложение
некоторой деятельности на её составные части. Диаграмма деятельности изображена
на рисунке 2.8.
Данная диаграмма показывает как происходит основной процесс расчёта
заработной платы.
Диаграмма состояний - это, по существу, диаграмма состояний из теории
автоматов cо стандартизированными условными обозначениями которая может
определять множество систем от компьютерных программ до бизнес-процессов.
Диаграмма состояний изображена на рисунке 2.9.
Данная диаграмма описывает состояния системы при авторизации пользователя
на одном из клиентов информационной системы.
Выводы к разделу
В этом разделе было проведено архитектурное проектирование, в рамках
которого были построены диаграммы компонентов и размещения. Построена
концептуальная и логическая модели базы данных. Описан пользовательский
интерфейс программы. Проведено проектирование баз данных, удовлетворяющая
требованиям разрабатываемой информационной системы. Выбрана платформа для
создания информационной системы. Для реализации приложения выбран язык
программирования C# в среде Visual Studio 2008 на платформе Microsoft .NET.
3.
Реализация и аттестация ИС
3.1 Реализация приложения
Реализация программного обеспечения - это процесс перевода системной
спецификации в работоспособную систему. Итогом реализации приложения является
работоспособная информационная система [29].
Разработка набора элементов информационной системы осуществляется в
едином рабочем пространстве. На рисунке 3.1 показана система классов
информационной системы.
В качестве основных инструментов для разработки приложения
использовались:
– интегрированная среда Visual Studio 2008, имеющая специализированные
мастера, в которых можно перетаскивать элементы управления прямо на форму;
– сервер баз данных MySQL 5.1.40, который обслуживает запросы
клиентского приложения и позволяет перенести часть реализуемых задач
непосредственно на базу данных, а так же предоставляет возможность получения
необходимой пользователю информации в удобном виде.
Среда визуальной разработки показана на рисунке 3.2.
В результате работы мастера проекта реализуется каркас формы, являющийся
экземпляром классов, унаследованного от System.Windows.Forms [25].
Программная реализация логики приложения разбита на несколько файлов, это
сделано для того, чтобы не «нагружать» его во время работы в фоновом режиме.
Код главной формы содержит в себе файлы MainFrom.cs, MainFrom.Designer.cs,
MainFrom.resx. Инициализация класса MainFrom,объявленного с ключевым словом
partial, и главной формы клиента «Администратор» показана на рисунке 3.3.
Разработка приложения начинается с разработки окна входа в систему, т. к.
это первое окно которое видит пользователь при запуске приложения. Окно входа в
систему у всех клиентов ИС выглядит одинаково с незначительными изменениями и
работает аналогичным образом.
Код метода для входа в систему показан на рисунке 3.4.
Авторизация происходит в три этапа:
– авторизация на сервере базы данных;
– проверка соответствий версий клиента;
– запись информации о входе пользователя в систему.
После разработки интерфейса форм важно правильно спроектировать их
взаимодействие [35].
Примером взаимодействия может служить активация одной формы при помощи
другой. На рисунке 3.5 представлен фрагмент кода клиента ИС «Администратор»,
реализующий активацию формы со списком пользователей по событию
«списокПользователейToolStripMenuItem_Click».
На рисунке 3.6 представлен фрагмент кода клиента ИС «Бухгалтер»,
реализующий активацию форм «Удержания», «Налоговые вычеты», «Алименты»,
«Начисления» и «Профсоюзные взносы». Элементы «ToolStripMenuItem», позволяющие
это сделать, расположены на форме главного окна программы.
Важней задачей ИС является выполнение бизнес-правил.
Бизнес-правила - набор условий, которые управляют деловым событием, чтобы
оно происходило так, как нужно для предприятия (или клиента) [24].
Основное условие которое должна выполнять АИС «Расчёт зарплаты» это
расчёт повременной оплаты труда, который производиться по формуле имеющий
следующий вид(3.1):
(3.1)
где S - сумма оплаты труда;- сумма фиксированного оклада;- количество
дней (часов) в рабочем месяце,- отработанное время.
Метод, выполняющий расчёт оплаты труда показан на рисунке 3.7.
Еще одной важной частью реализации приложения является ее адекватное
реагирование на те, или иные ошибки во время работы. Примером ошибки может
являться разрыв соединения с базой данных. Чтобы избежать непредвиденных
«вылетов» программы, необходимо использовать оператор «try - catch». Оператор
«try-catch» состоит из блока «try», за которым следует одно или несколько
предложений «catch», в которых определяются обработчики для различных
исключений. При возникновении исключения среда CLR ищет оператор «catch»,
который обрабатывает это исключение. Если выполняющийся в данный момент метод
не содержит такого блока «catch», то среда CLR рассматривает метод, который
вызвал текущий метод, и т. д. по стеку вызовов. Если блок «catch» не найден, то
среда CLR отображает пользователю сообщение о необработанном исключении и
останавливает выполнение программы.
Блок «try» содержит защищаемый код, в котором могут происходить
исключения. Этот блок выполняется до момента возникновения исключения или до
своего успешного завершения [25]. Пример кода программы с оператором
«try-catch» представлен на рисунке 3.8.
В данном примере описан метод для сохранения данных о взносах во
внебюджетные фонды в базу данных ИС (клиент «Бухгалтер»). При возникновении
каких-либо неполадок, например, обрыв сети в организации, приложение не
закроется с выводом критической ошибки на экран (рисунок 3.9), а завершит свою
работу, сохранив сообщение об ошибке в специальную переменную и возвратит
значение, указывающее на неправильное завершение метода, для последующей
обработки.
3.2 Взаимодействие приложения с источниками данных
SQL (Structured Query Language) - язык структурированных запросов,
является инструментом для выборки и обработки информации, содержащейся в базе
данных. SQL - универсальный компьютерный язык, применяемый для создания,
модификации и управления данными в реляционных базах данных, то есть
непосредственно для организации взаимодействия пользователя с базой данных.
Если пользователю необходимо получить информацию из базы данных, он запрашивает
её у СУБД с помощью SQL. СУБД обрабатывает запрос, находит требуемые данные и
посылает их пользователю. Процесс запрашивания данных и получения результата
называется запросом к базе данных. SQL используется для реализации всех
функциональных возможностей, которые СУБД предоставляют пользователю. К ним
относятся:
– организация данных;
– выборка данных;
– обработка данных;
– управление доступом;
– совместное использование данных;
– целостность данных [31].
Для дальнейшей работы с источником данных надо построить физическую модель
базы данных.
Физическое проектирование базы данных - процесс создания описания
конкретной реализации базы данных, размещаемой во вторичной памяти.
Предусматривает описание структуры хранения данных и методов доступа,
предназначенных для осуществления наиболее эффективного доступа к информации. В
физической модели (рисунок 3.10) содержится информация обо всех объектах БД.
Если в логической модели не имеет большого значения, какой конкретно тип
данных у атрибута, то в физической модели важно описать всю информацию о
конкретных физических объектах - таблицах, колонках, индексах, процедурах и
т.д. [21].
В качестве примера взаимодействия приложения с источниками данных можно
рассмотреть форму «Новое начисление» клиента «Бухгалтер», которая также
используется для редактирования начисления.
Первоначальной задачей реализации является визуальное проектирование
самой формы, представленной на рисунке 3.11, средствами Visual Studio 2008.
Для корректной работы с базой данных использовались следующие классы:
– MySQLConnection используется для установления соединения с конкретным
источником данных;
– MySQLCommand выполняет команду в источнике данных;
– MySQLDataReader считывает из источника данных однопроходный поток
данных только для чтения.
Второй задачей реализации является создание запроса в базу данных,
который будет передавать значения из полей формы в таблицу «NACHISLENIE».
Создавая этот запрос необходимо учитывать передаваемые типы данных.
Пример SQL-запроса добавления записи в таблицу представлен на рисунке 3.12.
Для успешной реализации запроса, необходимо создать метод, который будет
формировать строку запроса для базы данных. Фрагмент кода представлен на
рисунке 3.13.
Третьей задачей реализации является создание запроса в БД, который будет
обновлять данные в таблице «NACHISLENIE», заменяя их данными с полей формы.
Важно учитывать соответствие типов данных таблицы и полей формы. Пример
SQL-запроса представлен на рисунке 3.14.
По аналогии с запросом на добавление данных для так же необходимо
разработать метод, который будет формировать строку запроса на обновление
данных. Фрагмент кода метода представлен на рисунке 3.15.
Результаты работы формы «Новое начисление» приведены в Приложении В.
Исходя из данных результатов, можно сделать вывод о том, что программный модуль
работает корректно.
3.3 Тестирование приложения
Тестирование приложений, а также разработанных модулей и компонентов
является одним из самых важных этапов в реализации ИС [32, 34].
Тестирование приложения подразумевает 4 этапа:
. Выбор методов тестирования
2. Создание плана тестирования
. Разработка тестовых примеров
. Анализ результатов тестирования
Существует несколько методов тестирования, рассмотрим два из них.
Метод «Белого ящика» используется в случае, когда тестировщиком является
человек, который знает все процессы, происходящие в приложении. Как правило, в
таких случаях тестировщиком является сам разработчик приложения. Тестирование
компонентов форм на стадии разработки осуществляется в режиме отладки с
использованием специального средства Visual Studio 2008 - Debug [33, 34].
Удобство этого средства тестирования заключается в возможности пошаговой
отладки создаваемого приложения в ходе выполнения программы.
Метод «черный ящик» - метод, при котором тестировщик является человеком,
не проектировавший данное ПО. Тестировщику дают тестируемое приложение и дают
тестовые случаи. В ходе тестирования он должен вносить результаты тестов.
В качестве метода тестирования выбран «Белый ящик», т. к. при
тестировании принимается во внимание структура всей программы, что облегчает
обнаружение ошибок. План тестирования представляет собой таблицу, в которой
указывается название модуля и описание результата работы этого модуля. План
тестирования модулей клиента «Сотрудник отдела кадров» методом «Белый ящик»
показан в таблице 3.1.
Таблица-3.1. План тестирования клиента «Сотрудник отела кадров» методом
«Белый ящик»
|
Название тестируемого
модуля
|
Требуемый результат
|
|
Отделы
|
Позволяет добавлять,
изменять или удалить информацию об отделах в базе данных информационной системы.
А также следить за корректным вводом информации.
|
|
Категории
|
Позволяет добавлять,
изменять или удалить информацию о категориях плательщиков в базе данных
информационной системы. А также следить за корректным вводом информации.
|
|
Лицевые счета
|
Позволяет добавлять,
изменять или удалить информацию о сотрудниках предприятия в базе данных
информационной системы. А также следить за корректным вводом информации.
|
Примеры тестирования разрабатываются для тестирования модуля для тех или
иных конкретных случаев. В приложении В представлены тестовые примеры для
тестирования модулей клиента «Сотрудник отдела кадров».
Результаты тестирования приложения включают сравнение фактического и
ожидаемого результатов.
При тестировании клиента «Сотрудник отдела кадров», состоящему из 7
тестовых примеров, не выявлено ни одной ошибки. Все тесты прошли успешно.
Подводя итог этапу тестирования можно сделать вывод о том, что
программный продукт работает стабильно, ошибки не выявлены.
3.4 Методика развертывания приложения
Развертывание компонентов происходит на тех компьютерах системы, на
которых расположены рабочие места пользователей, использующих бизнес процессы,
связанны с данным компонентом. Следовательно, разработанные программные модули
будет установлены на рабочих местах бухгалтера, сотрудника отдела кадров,
системного администратора.
В качестве СУБД на сервере баз данных должен быть установлен MySQL
5.1.40.
Для настройки сервера баз данных необходимо запустить программу
«CreateDb.exe».
После этого появляется окно с настройками подключения, показанное на
рисунке 3.16.
После ввода имени сервера и пароля администратора БД (если он установлен)
необходимо нажать на кнопку «Подключиться». После этого появляется окно,
информирующее о процессе настройки базы данных показанное на рисунке 3.17.
После завершения настройки базы данных, последняя запись информирует об
этом.
Все автоматизированные рабочие места (АРМ) должны соответствовать
следующим системным требованиям:
– Microsoft Windows XP;
– Процессор Pentium IV 2GHz CPU;
– .NET Framework 2.0;
– мышка, клавиатура;
– 512 Mb RAM.
На АРМ участников ИС должна быть установлена операционная система
Microsoft Windows XP. Для работоспособности приложения необходимо наличие
компонента NET Framework 2.0, т.к. оно разрабатывалась на языке программирования
C#.Установочная конфигурация клиентского приложения была выполнена с
использованием инструмента Setup and Deployment MS Visual Studio.
Для того чтобы установить клиентское приложение необходимо запустить файл
установки «setup.exe».
Установка начинается с запуска мастера установки Setup Wizard, как
показано на рисунке 3.18.
В мастере установки используется интуитивно понятный интерфейс. Для
продолжения установки необходимо нажать кнопку «Next» . Затем выбрать путь
установки программы, как показано на рисунке 3.19 и снова нажать «Next».
На следующем шаге мастер установки попросит подтвердить
Для изменений настроек следует щелкнуть на кнопке «Back» и вернуться к
одному или нескольким диалоговым окнам, чтобы проверить выбор, а затем
вернуться в данное окно и щелчком на кнопке «Next» подтвердить выбор настроек.
После выбора настроек и его подтверждения необходимо подождать пока Setup
Wizard мастер выполнит установку программного обеспечения (рисунок 3.21) и
нажать кнопку «Close» для завершения установки.
Для удаления программы либо ее переустановки необходимо еще раз запустить
установочный файл setup.exe и выбрать соответствующий пункт меню (рисунок
3.22).
Выводы к разделу
В данном разделе рассмотрена реализация информационной системы. Описана
методика развертывания данной информационной системы. Описан способ установки
приложения. Рассмотрена методика взаимодействия информационной системы с СУБД
MySQL 5.1.40. Проведено тестирование ИС. Программный продукт работает
стабильно, ошибок не найдено.
4. Управление
информационным проектом
4.1 Выбор жизненного цикла разработки ПО
Вопросы управления информационными системами целесообразно рассматривать
в контексте, определяемом жизненным циклом программного обеспечения.
Проект - это уникальный процесс, в ходе выполнения которого получают
уникальный продукт. Разработчик может воспользоваться обобщенной, проверенной
на практике методикой, адаптировав ее для конкретного проекта. Как правило,
всегда есть возможность выбора среди нескольких «начальных» жизненных циклов.
Жизненный цикл - непрерывный процесс, который начинается с момента
принятия решения о необходимости создания ИС и заканчивается в момент ее
полного изъятия из эксплуатации.
Модель жизненного цикла ИС - структура, определяющая последовательность
выполнения и взаимосвязи процессов, действий и задач на протяжении жизненного
цикла. Модель жизненного цикла зависит от специфики, масштаба и сложности
проекта и специфики условий, в которых система создается и функционирует [36].
На предыдущих этапах разработки модель жизненного цикла всего проекта
была определена как инкрементная. На новом этапе разработки необходимо еще раз
проанализировать отличительные категории проекта, такие как: требования,
команда разработчиков, коллектив пользователей, риски и тип проекта. Далее,
следует ответить на вопросы по каждой категории и проранжировать полученные
данные. На основе этого результата определяется наиболее приемлемая модель ЖЦ
для новой подсистемы.
Таблицы с вопросами, ответы на которые будут определять оптимальную
модель жизненного цикла для информационной системы, приведены в Приложении Г.
На рисунке 4.1 представлены итоговые результаты выбора модели жизненного
цикла.
По результатам суммы баллов таблицы ярко выражены инкрементная и RAD -
модели ЖЦ.
Инкрементная модель ЖЦ предполагает следующее: первая создаваемая
промежуточная версия системы (выпуск 1) реализует часть требований, в
последующую версию (выпуск 2) добавляют дополнительные требования и так до тех
пор, пока не будут окончательно выполнены все требования и решены задачи
разработки системы. Для каждой промежуточной версии на этапах ЖЦ выполняются
необходимые процессы, работы и задачи, в том числе, анализ требований и
создание новой архитектуры, которые могут быть выполнены одновременно. В
соответствии с данной моделью ЖЦ, процессы которой практически такие же, что и
в каскадной модели, ориентир делается на разработку некоторой законченной
промежуточной версии, а задачи процесса разработки выполняются последовательно
или частично параллельно для ряда отдельных промежуточных структур версии.
Работы и задачи процесса разработки следующей версии системы с дополнительными
требованиями или функциями могут выполняться неоднократно в той же
последовательности для всех промежуточных версий системы. Процессы сопровождения
и эксплуатации могут быть реализованы параллельно с процессом разработки версии
путем проверки частично реализованных требований в каждой промежуточной версии
и так до получения законченного варианта системы. Вспомогательные и
организационные процессы ЖЦ обычно выполняются параллельно с процессом
разработки версии системы и к концу разработки будут собраны данные, на
основании которых может быть установлен уровень завершенности и качества
изготовленной системы [37].
При применении данной модели необходимо учитывать следующие факторы
риска:
– требования составлены с учетом возможности их изменения при реализации
продукта;
– все возможности системы требуется реализовать с начала;
– быстрое изменение технологии и требований к системе может
привести к нарушению полученной структуры системы;
– ограничения в ресурсном обеспечении (исполнители, финансы) могут
привести к затягиванию сроков сдачи системы в эксплуатацию.
Данную модель ЖЦ целесообразно использовать, в случаях когда:
– желательно реализовать некоторые возможности системы быстро за счет
создания промежуточной версии продукта;
– система декомпозируется на отдельные составные части, которые
можно реализовывать как некоторые самостоятельные промежуточные или готовые
продукты;
– возможно увеличение финансирования на разработку отдельных частей
системы.
RAD (от англ. Rapid Application Development - быстрая разработка
приложений) - концепция создания средств разработки программных продуктов,
уделяющая особое внимание быстроте и удобству программирования, созданию
технологического процесса, позволяющего программисту максимально быстро
создавать компьютерные программы.
Характерной чертой «RAD» является короткое время перехода от определения
требований до создания полной системы. Метод основывается на последовательности
итераций эволюционной системы или прототипов, критический анализ которых
обсуждается с заказчиком. В процессе такого анализа формируются требования к
продукту.
При использовании модели RAD относительно разрабатываемого проекта, для
которого она в достаточной степени приемлема, проявляются следующие
преимущества:
– требуется меньшее количество специалистов (поскольку разработка
системы выполняется усилиями команды, осведомленной в предметной области);
– уменьшаются затраты (благодаря сокращенному времени цикла и
усовершенствованной технологии, а также меньшему количеству задействованных в
процессе разработчиков);
– постоянное присутствие заказчика сводит до минимума риск
неудовлетворения продуктом и гарантирует соответствие системы коммерческим потребностям
и надёжность программного продукта в эксплуатации;
– в состав каждого временного блока входит анализ, проектирование и
внедрение (фазы отделены от действий);
– повторное использование компонент уже существующих программ [37].
Информационная система «Расчёт зарплаты» разрабатывался, основываясь на
RAD модели ЖЦ.
4.2 Определение цели и области действия программного проекта
Программный продукт, разрабатываемый в рамках данного дипломного проекта,
является полностью автономных проектов. «Расчёт зарплаты» позволит
автоматизировать процесс расчёта заработной платы и подготовки отчётности.
Цель данного проекта - создание удобного инструмента сотрудников отдела
бухгалтерии и отдела кадров, заменяющего бумажный аналог, в целях экономии
рабочего времени, увеличения эффективности работы и поддержания современного
уровня информационных технологий.
Задачи проекта:
– выполнить сбор, спецификацию и аттестацию требований;
– выполнить проектирование информационного и программного
обеспечения системы;
– разработать базу данных и программные коды приложения;
– провести тестирование программного продукта.
Программный проект может:
– произвести расчёт повременной оплаты труда, а также начисления к ним;
– сохранять данные в СУБД MySQL 5.1.40;
– производить вывод отчёта в виде расчётного листка.
Программный проект не может производить расчёт сдельной оплаты труда.
Программный проект должен быть:
– продуктом для внутреннего использования в ОАО РТП «Авторемонтник»;
– проектом для осуществления доступа для бухгалтера и сотрудника
отдела кадров;
– проектом, который будет осуществлять формирование отчетности.
Программный проект не должен быть доступным для посторонних лиц.
4.3 Создание структуры пооперационного перечня работ
Структура пооперационного перечня работ разрабатывалась в приложении
Microsoft Office Project 2007. Основная задача планирования проекта заключается
в достаточно точной оценке сроков исполнения этих работ. Чтобы добиться
наивысшего качества плана проекта необходимо дать как можно более точную оценку
сроков исполнения работ. Точную оценку можно дать только в том случае, если
хорошо представлен состав работ по выполнению проекта, то есть те работы,
которые необходимо выполнить для получения необходимого результата [38].
Показанный на рисунке 4.2 перечень действий и задач, представляет собой
схему жизненного цикла АИС, состоящую из четырех фаз:
– этап планирования требований - сбор требований выполняется при
использовании рабочего метода, называемого совместным планированием требований
(Joint requirements planning, JRP), который представляет собой структурный
анализ и обсуждение имеющихся коммерческих задач;
– пользовательское описание - совместное проектирование приложения
(Joint application design, JAD) используется с целью привлечения пользователей;
на этой фазе проектирования системы, не являющейся промышленной, работающая над
проектом команда зачастую использует автоматические инструментальные средства,
обеспечивающие сбор пользовательской информации;
– фаза конструирования («до полного завершения») - эта фаза
объединяет в себе детализированное проектирование, построение (кодирование и
тестирование), а также поставку программного продукта заказчику за определенное
время. Сроки выполнения этой фазы в значительной мере зависит от использования
генераторов кода, экранных генераторов и других типов производственных
инструментальных средств;
– перевод на новую систему эксплуатации - эта фаза включает
проведение пользователями приемочных испытаний, установку системы и обучение
пользователей.
4.4 Идентификация задач и действий
Создание структуры пооперационного перечня работ влечет за собой
подробнейшую декомпозицию всего проекта. Этот процесс продолжается до тех пор,
пока не будут подробно описаны все детали предстоящей работы, что в свою
очередь, позволит реализовать надлежащее управление этой работой.
Управление проектом связано с вопросами планирования и организации работ,
создания коллективов разработчиков и контроля за сроками и качеством
выполняемых работ. Техническое и организационное обеспечение проекта включает
выбор методов и инструментальных средств для реализации проекта, определение
методов описания промежуточных состояний разработки, разработку методов и
средств испытаний ПО, обучение персонала и т.п. Обеспечение качества проекта
связано с проблемами верификации, проверки и тестирования ПО.
Для успешного создания уникального продукта необходимо наиболее точно
сформулировать последовательность работ, наиболее точно определить оценку
сроков исполнения и стоимость этих работ, с расчетом выделения необходимых
ресурсов для их выполнения [39].
Грамотно идентифицированные задачи и действия позволяют четко
распределить время, для каждого этапа разработки программного обеспечения,
начиная с анализа предметной области и заканчивая внедрением системы.
Все задачи и ресурсы для реализации этих задач представлены на рисунке
4.3.
4.5 Оценка размера и возможности повторного использования ПО
В большинстве программных проектов применяется повторное использование
некоторых программных модулей. Это возможно в том случае, если созданные ранее
программные продукты, частично состоят из компонентов, приблизительно
удовлетворяющих требованиям разрабатываемых компонентов. Эти компоненты
изменяются в соответствии с новыми требованиями, и затем включаются в состав
другой системы.
Основные достоинства процесса разработки ПО с повторным использованием
ранее созданных компонентов заключаются в том, что сокращается количество
непосредственно разрабатываемых компонентов, в связи с этим время разработки и
объем труда уменьшаются, исходя из этого уменьшается общая стоимость
создаваемой системы [40, 41].
Главными недостатками такого метода являются: неизбежные компромиссы,
которые могут возникать при определении требований, что может привести к тому,
что законченная система не будет удовлетворять всем требованиям заказчика; а
так же затруднение процесса модернизации системы, заключающееся в отсутствии
возможности влияния на появление новых версий компонентов, используемых в
системе.
Разрабатываемая информационная система создавалась для использования
сотрудников отдела бухгалтерии и сотрудников отдела кадров ОАО РТП
«Авторемонтник», но способы и методы начислений заработной платы во многом
совпадают с другими предприятиями. Поэтому, в дальнейшем разработанные
компоненты, такие как классы, методы, а также интерфейс, могут быть
использованы при автоматизации учета заработной платы другими организациями.
4.6 Оценка длительности и стоимости разработки ПО
Оценку длительности разработки любого программного продукта можно
определить только после того, как будет определен пооперационный перечень работ
необходимых для создания и внедрения данного продукта. Перечень необходимых
работ для разработки и внедрения программного продукта «Расчёт зарплаты»
представлен на рисунке 4.3. Оценку длительности можно изобразить с помощью
диаграммы Ганта. Диаграммы являются графическим средством отображения
содержащейся в проектном файле информации. Диаграммы дают визуальное
представление о последовательности задач, их относительной длительности и
длительности проекта в целом.
Диаграмма Ганта - это один из наиболее популярных способов графического
представления плана проекта, применяемый во многих программах управления
проектами [42].
Диаграмма Ганта представляет собой отрезки (графические плашки),
размещенные на горизонтальной шкале времени. Каждый отрезок соответствует
отдельной задаче или подзадаче. Задачи и подзадачи, составляющие план,
размещаются по вертикали. Начало, конец и длина отрезка на шкале времени
соответствуют началу, концу и длительности задачи. На некоторых диаграммах
Ганта также показывается зависимость между задачами. Диаграмма может
использоваться для представления текущего состояния выполнения работ: часть
прямоугольника, отвечающего задаче, заштриховывается, отмечая процент
выполнения задачи; показывается вертикальная линия, отвечающая моменту
«сегодня».
В MS Project 2007 диаграмма Ганта является основным средством
визуализации плана проекта. Эта диаграмма представляет собой график, на котором
по горизонтали размещена шкала времени, а по вертикали расположен список задач.
При этом длина отрезков, обозначающих задачи, пропорциональна длительности
задач.
На диаграмме Ганта рядом с отрезками может отображаться дополнительная
информация (рядом с задачами отображаются названия задействованных в них
ресурсов и их загрузка при выполнении задачи).
Наиболее типичное использование диаграммы Ганта - визуальное отражение
хода выполнения какого-либо проекта.
Диаграмма Ганта может использоваться для наглядного представления таких
данных как:
– ход выполнения проекта;
– график рабочего времени;
– графиков отпусков;
– использование оборудования;
– занятость помещений и другие.
На рисунке 4.4 отображен лист ресурсов, использованных в проекте.
Диаграмма Ганта представлена в Приложении Д.
Длительность проекта равна 93 дням. Общие затраты на разработку проекта
составили 22 580 рублей, при учете того, что компьютером пользовался не только
программист и стоимость одного часа работы за компьютером равна 15 рублей
(рисунок 4.5).
4.7 Распределение ресурсов проекта
Для эффективного управления проектом, необходимо назначать каждой задаче
ресурсы, требуемые для ее исполнения.
Ресурсное планирование - это процесс назначения ресурсов задачам проекта,
а также связанное с ним редактирование предварительного варианта календарного
плана.
Ресурсное планирование позволяет:
– оценить потребность в ресурсах;
– спланировать рациональное распределение потребности в ресурсах во
времени;
– определить участки проекта, являющиеся критическими с точки
зрения потребностей в ресурсах;
– контролировать расходование ресурсов при реализации проекта.
Для успешного распределения ресурсов необходимо наиболее точно учесть
компетенцию и уровень знаний каждого члена команды, а также распределить в
соответствии с полученными сведениями действия и задачи,имеющие определенную
степень сложности [43, 44].
На рисунке 4.6 представлен список ресурсов, необходимых для выполнения
задач.
4.8 Оценка эффективности проекта
Целью создания АИС является автоматизация процесса расчёта заработной
платы.
Программа должна обеспечивать:
– работу со входными данными;
– получение выходных отчетов;
– формирование отчетов.
Расчет экономической эффективности для данного дипломного проекта не
целесообразен, так как разрабатываемая АИС не несет в себе экономической
выгоды. В связи с этим эффективность внедрения системы можно оценивать по
критериям качества предоставляемых услуг.
Для оценки эффективности необходимо воспользоваться методом экспертных
оценок [32].
Эксперт - это специалист, суждения которого наиболее компетентны в данной
отрасли знаний. Уровень компетентности - понятие субъективное, поэтому эксперты
должны подлежать оценке по результатам своей работы.
Процедура экспертного опроса может быть организована и проведена открыто
или анонимно. Открытые опросы проводятся как в виде коллективного обсуждения,
так и в индивидуальном порядке. Групповой опрос преследует цель выработки
наиболее согласованного решения. Если эксперты независимы в своих суждениях и
дискуссия носит открытый и доброжелательный характер, то итоги такого обсуждения
будут наиболее эффективными, а обобщенное мнение экспертов наиболее корректным
[45].
Данный метод состоит из следующих этапов:
– выявление критериев оценки ИС;
– определение весовых коэффициентов целей;
– определение показателя, характеризующего определенный критерий;
– расчет общего показателя эффективности разрабатываемой АИС;
Формула расчета общего показателя эффективности имеет следующий вид
(4.1):
,(4.1)
где Y -общий показатель эффективности АИС, 0 ≤ Y ≤ 1
Vk
- вес k-го критерия эффективности проекта, 0 ≤ Vk ≤ 1, 
;ik - оценка i-м экспертом k-го критерия, 0
≤ Eik ≤ 1 ;- количество экспертов;- количество критериев
эффективности проекта.
Весовой коэффициент вычисляется по формуле 4.2:
,(4.2)
где
- весовой коэффициент, баллы;
- оценка, баллы.
Расчет оценки ведется по формуле 4.3:
, (4.3)
где
- минимальное значение ранга, баллы;
- сумма
рангов, баллы.
Для
расчета суммы рангов необходимо воспользоваться формулой 4.4:
,(4.4)
где
- значение, выставленное экспертом, баллы;
-
количество экспертов.
Рассмотрев
общие положения методики оценки информационной системы можно переходить к
расчету конкретного показателя эффективности работы АИС.
Определяя показатели работы системы можно свести их в таблицу. В ней же
следует указать показатели этих критериев (таблица 4.1). Так же можно выделить
5 критериев оценки ИС:
– Технический уровень;
– Социальные цели;
– Получение отчетности;
– Простота использования
– Коммуникации.
Таблица 4.1 -критерии оценки работы
ИС
|
Критерий
|
Показатель
|
|
технический уровень
|
- автоматизированный
процесс заполнения и расчёта зарплаты
|
|
социальные цели
|
- улучшение условий труда -
удобство работы - уменьшение времени выполнения работ
|
|
получение отчетности
|
- автоматическое получение
отчетов - уменьшение объема рутинной работы бухгалтера и сотрудника отдела
кадров
|
|
простота использования
|
- интуитивно понятный
интерфейс пользователя - возможность сохранения, извлечения и редактирования
данных
|
|
Коммуникация
|
- оперативность - удобство
использования
|
Следующим этапом является определение весовых коэффициентов при помощи
проведения экспертного опроса шести человек. Список опрошенных и результаты
опроса, а так же расчет весового коэффициента представлены в Приложении Е.
Результатом этого этапа будут расчеты сумм рангов и суммы оценок.
Задачей эксперта является на основании его представлений о субъективных
связях между компонентами исследуемой системы и воздействующих на нее внешних
факторов дать количественную оценку степени влияния различных факторов на
функционирование системы как единого объекта. В зависимости от сложности задачи
и квалификации экспертов существует ряд способов оценивания искомых
коэффициентов. Их можно получить несколькими путями. Самый простой способ
заключается в прямой расстановке коэффициентов, исходя из требования, чтобы их
сумма была равна единице или 100%. При внешней легкости достижения результата
простота эта кажущаяся, поскольку достаточно трудно, даже при высокой
квалификации экспертов, расставить коэффициенты в долях единицы или процентах
при каждом влияющем факторе. Причем затруднения возрастают по мере увеличения
числа факторов, количество которых может быть несколько десятков.
Следовательно, и статистическая значимость весовых коэффициентов будет
невысокой, что автоматически влечет за собой снижение качества разрабатываемой
экспертной модели. Не решает проблемы разбиение факторов на участки по уровню
компетентности экспертов, поскольку это приводит к нарушению однородности
условий оценивания и снижению статистической достоверности оценок весовых
коэффициентов.
В другой группе методов от экспертов требуется произвести ранжирование,
т.е. упорядочить исследуемые факторы по степени проявления их свойств в порядке
возрастания или убывания. Сводные оценки весовых коэффициентов получаются в
результате осреднения частных рангов или расчетом по специальным формулам.
Недостатком такого подхода является сильное сглаживание весовых коэффициентов,
тем большее, чем меньшее число факторов рассматривается [18].
Представленные результаты сведены в таблице на рисунке 4.7.
Определив весовые коэффициенты, по формуле 4.3, можно рассчитать общий
показатель эффективности АИС.=(0,16*(0,9+0,9+0,88+0,92+0,84+0,89)+0,19*(0,91+0,85+0,92+0,89+0,9+0,92)+0,21*(0,88+0,9+0,89+0,84+0,91+0,92)+0,22*(0,93+0,9+0,87+0,9+0,92+
0,93)+0,22*(0,83+0,87+0,93+0,87+0,89+0,87))/6=0,89
Таким образом, можно сказать, что эффективность работы разработанной
автоматизированной информационной системы по отношению к заданным целям
составляет 0,89 баллов, то есть на 89% система работает оптимально.
Неэффективность работы ИС составляет 11%.
На основании представленных расчетов можно утверждать, что реализация и
внедрение программного модуля АИС «Расчёт зарплаты» является целесообразным.
Выводы к разделу
В этой главе произведено обоснование выбора жизненного цикла
информационной системы и выделено, что наиболее оптимальным вариантом модели
жизненного цикла является модель RAD. Определены цели и область действия
программного продукта, создана структура пооперационного перечня работ (проект
создания информационной системы реализован в Microsoft Project 2007).
Определены используемые в проекте ресурсы и на последнем этапе проведена оценка
эффективности проекта, общий показатель эффективности составил 89%. Таким
образом, внедрение проекта целесообразно.
ЗАКЛЮЧЕНИЕ
Дипломный проект состоит из введения, четырех разделов, заключения,
списка литературы, списка сокращений и приложений.
В ходе выполнения дипломного проекта был спроектирован и разработан
программный модуль расчёта заработной платы сотрудникам ОАО РТП
«Авторемонтник».
Во введении обоснована актуальность дипломного проектирования выбранной
темы «Разработка автоматизированной информационной системы расчёта заработной
платы «Расчёт зарплаты ОАО РТП Авторемонтник». Поставлены цели и сформулированы
задачи для их достижения.
В первом разделе были проанализированы существующие решения по
автоматизации рассматриваемой области. Была выбрана объектно-ориентированная
методология проектирования информационной системы и разработаны диаграмма
вариантов использования и диаграмма классов. Произведен сбор, аттестация и
спецификация требований заказчика.
Во втором разделе проведено архитектурное проектирование АИС,
проектирование базы данных и проектирование пользовательского интерфейса.
Для разрабатываемой АИС была выбрана платформа Microsoft Visual Studio
2008 и СУБД MySQL 5.1.40. В качестве языка реализации приложения выбран C#.
В третьем разделе была рассмотрена реализация информационной системы.
Было приведено описание классов и методов, приведены примеры кода и рассмотрены
основные алгоритмы, обеспечивающие работу программы с учетом выбранной
платформы реализации.
Была продемонстрирована методика взаимодействия приложения с СУБД MySQL
5.1.40 с представлением запросов, которые обеспечивают запись и обновление
данных из базы данных.
Четвертый раздел посвящен вопросам управления информационным проектом. В
этом разделе дипломного проекта определена цель и область действия
разработанного программного продукта. Осуществлён выбор модели жизненного цикла
процесса разработки. В качестве модели жизненного цикла разработки АИС является
модель RAD.
Составлена структура пооперационного перечня работ и на её основе
построен график выполнения работ. Также определены ресурсы и распределены на
каждую задачу. Разработана диаграмма Ганта, наглядно показывающая длительность
и очередность выполнения задач, решаемых в ходе разработки системы.
Проведена оценка эффективности АИС, которая показала, что внедрение
проекта целесообразно.
Во время выполнения дипломного проектирования были использованы следующие
программные продукты:
– MS Office Visio 2007;
– MS Office Project 2007;
– MS Visual Studio 2008, язык программирования C#;
– MySQL 5.1.40;
– Rational Roze v 7.0.
В заключении можно сделать вывод: цели, поставленные в работе,
достигнуты, а задачи - выполнены.
Результат интеллектуальной деятельности:
Специальность: «ИТ» (в управлении).
Тема: Создание системы расчёта заработной платы (на примере ОАО
РТП «Авторемонтник»).
Предполагаемый РИД:
Система расчёта зарплаты, которая позволяет реализовать следующие
функции: расчёт заработной платы по системе повременной оплаты труда, вывод
отчёта в виде расчётного листка, расчёт налога на доход физических лиц, ведение
личных дел сотрудников и сохранение их в базе данных ИС.
Системные требования к программно-аппаратной среде, в которой работает
ПО:
Архитектура - клиент-серверная; операционная система - Windows XP и выше;
язык программирования C#; хранилище данных - MySQL 5.1.40.
Разрабатываемый программный продукт снабжен методикой развёртывания
приложения.
Тематическая база данных по информационным источникам - 45 наименований.
Предполагаемые пользователи (Заказчика) РИД: организации использующую
повременную систему расчёта заработной платы.
CONCLUSION
The diploma project consists of an introduction, four chapters,
conclusions, bibliography, list of abbreviations and applications.the
performance of the diploma project was designed and developed a software
payroll module.introduction the urgency of the diploma of the selected theme
" Development of an automated information system payroll
"Payroll"". Purpose and objectives for their achievement were
set and solved.the first section we have analyzed the existing solutions to
automate the treated area. Was chosen as the object-oriented design methodology
and information system developed use case diagrams. Produced collection,
validation and specification requirements.the second section, performed
architectural design AIS, database design and user interface design.has been
developed for the selected platform Microsoft Visual Studio 2008 and DBMS MySQL
5.1.40. As the language of the application is selected C#.third section was
considered the implementation of an information system. It was a description of
the classes and methods, code examples, and the basic algorithms providing the
program with the selected platform implementation.the technique of interaction with
the database application MySQL 5.1.40 with the representation of queries that
provide a record and update data from the database.fourth section is devoted to
the management information project. This section of the graduation project is
defined goal and scope of the developed software. Implemented model selection
process lifecycle development. As a model of the development life cycle model
AIS is RAD.a list of works of operational structure and, based on the work
schedule is built. Also identified and allocated resources for each task.
Developed the Gantt chart, clearly showing the duration and sequence of tasks
undertaken during the development of the system.efficiency of the AIS, which
showed that the implementation of the project feasible.the execution of
graduate design used the following software products:
MS Office Visio 2007;
MS Office Project 2007;
MS Visual Studio 2008, C# programming language;
MySQL 5.1.40;
Rational Rose v 7.0.conclusion it is possible to draw a conclusion: the
objectives of the work achieved, and the task is executed.result of
intellectual activity:: "IT" (in management).: Creating a payroll
system (in the example of RTP "Avtoremontnik").RIA:system, which
allows the following functions: payroll system for time-based pay, the report
output in the form of a payslip, the calculation of the tax on income of
individuals, maintaining personnel files and stores them in a database of
IP.requirements for the hardware and software environment in which the software
works:- client-server, operating system - Windows XP and above, the programming
language C #; data warehouse - MySQL 5.1.40.developed software is provided with
the application deployment method. Thematic database information sources - 45
items.intended users (Customer) RIA: The organization uses time-based payroll
system.
Список
сокращений
АИС - автоматизированная информационная система;
АРМ - автоматизированное рабочее место;
БД - база данных;
ГИП - графический интерфейс пользователя;
ЖЦ - жизненный цикл;
ИС - информационная система;
ООП - объектно-ориентированное программирование;
ПО - программное обеспечение;
СУБД - система управления базами данных;- Common Language Runtime;-
графический интерфейс пользователя;- Joint application design;- Joint
Requirements Planning;- Rapid Application Development;- Structured Query
Language;- Software Requirements Specification.
CПИСОК ИСПОЛЬЗУЕМЫХ ИСТОЧНИКОВ
1.Гарсиа, М.Ф. Справочник системного администратора. 3-е
издание. Перевод с английского. - М.: СП Эком, 2005. -976с.
.Помощь в 1С #"723722.files/image013.gif">
3.3.1.2. Требования к запросам пользователей данных из базы
Пользователи и администраторы работают с базой данных через клиенты
информационной системы.
3.3.2. Требования к исходным кодам и языкам программирования
Дополнительные требования не предъявляются.
3.3.3. Требования к программным средствам, используемым
программой
Системные программные средства, используемые программой, должны быть
представлены лицензионной локализованной версией операционной системы Windows
XP.
3.3.4. Требования к защите информации и программ
Требования к защите информации и программ не предъявляются.
3.4. Специальные требования
Программа должна обеспечивать одновременную работу пользователей
посредством клиент-серверной архитектуры.
4. Требования к программной документации
.1. Предварительный состав программной документации
Состав программной документации должен включать в себя:
.1.1. техническое задание;
.1.2. программу и методики испытаний;
.1.3. руководство оператора;
5. Стадии и этапы разработки
.1. Стадии разработки
Разработка должна быть проведена в три стадии:
. разработка технического задания;
. рабочее проектирование;
. внедрение.
5.2. Этапы разработки
На стадии разработки технического задания должен быть выполнен этап
разработки, согласования и утверждения настоящего технического задания.
На стадии рабочего проектирования должны быть выполнены перечисленные
ниже этапы работ:
. разработка программы;
. разработка программной документации;
. испытания программы.
На стадии внедрения должен быть выполнен этап разработки подготовка и
передача программы.
5.3. Содержание работ по этапам
На этапе разработки технического задания должны быть выполнены
перечисленные ниже работы:
. постановка задачи;
. определение и уточнение требований к техническим средствам;
. определение требований к программе;
. определение стадий, этапов и сроков разработки программы и документации
на неё;
. согласование и утверждение технического задания.
На этапе разработки программы должна быть выполнена работа по
программированию (кодированию) и отладке программы.
На этапе разработки программной документации должна быть выполнена разработка
программных документов в соответствии с требованиями к составу документации.
На этапе испытаний программы должны быть выполнены перечисленные ниже
виды работ:
. разработка, согласование и утверждение и методики испытаний;
. проведение приемо-сдаточных испытаний;
. корректировка программы и программной документации по результатам
испытаний. На этапе подготовки и передачи программы должна быть выполнена
работа по подготовке и передаче программы и программной документации в
эксплуатацию на объектах Заказчика.
6. Порядок контроля и приемки
.1. Виды испытаний
Приемо-сдаточные испытания должны проводиться на объекте Заказчика в
оговоренные сроки. Приемо-сдаточные испытания программы должны проводиться
согласно разработанной Исполнителем и согласованной Заказчиком Программы и
методик испытаний.
Ход проведения приемо-сдаточных испытаний Заказчик и Исполнитель
документируют в Протоколе проведения испытаний
6.2. Общие требования к приемке работы
На основании Протокола проведения испытаний Исполнитель совместно с
Заказчиком подписывает Акт приемки-сдачи программы в эксплуатацию
приложение в
- Тестовые примеры
|
Название модуля
|
Действия
|
Результат
|
|
Отелы
|
1. Открыть форму «Добавить
отдел» 2. Набрать название отдела 3. Нажать кнопку «Добавить»
|
1. Откроется
соответствующая форма 2. Ожидание ввода информации 3. Новый отдел
отобразиться в списке отделов
|
|
Отелы
|
1. Открыть форму «Добавить
отдел» 2. Нажать кнопку «Добавить»
|
1. Откроется
соответствующая форма 2. Появиться сообщение об ошибке
|
|
Отелы
|
1. Открыть форму «Отделы»
2. Выбрать существующий отдел 3. Нажать кнопку «Изменить»
|
1. Откроется
соответствующая форма 2. Ожидание ввода 3. Откроется соответствующая форма с
заполненными полями
|
|
Отелы
|
1. Открыть форму «Изменить
отдел» 2. Изменить название отдела 3. Нажать кнопку «Изменить»
|
1. Откроется
соответствующая форма с заполненными полями 2. Ожидание ввода 3. Изменения
отобразятся в списке отделов
|
1. Открыть форму «Отделы»
2. Выбрать существующий отдел 3. Нажать кнопку «Удалить» 4. В окне сообщения
нажать «Да»
|
1. Откроется
соответствующая форма 2. Ожидание ввода 3. Появляется сообщение с
предупреждением 4. Изменения отобразятся в списке отделов
|
|
Категории
|
1. Открыть форму «Добавить
категорию» 2. Заполнить поля корректными данными 3. Нажать кнопку «Добавить»
|
1. Откроется
соответствующая форма 2. Ожидание ввода 3. Изменения отобразятся в списке
категорий
|
|
Категории
|
1. Открыть форму «Добавить
категорию» 2. Оставить любое поле пустым 3. Нажать кнопку «Добавить»
|
1. Откроется
соответствующая форма 2. Ожидание ввода 3. Появиться предупреждение об ошибке
|
Приложение Г - обоснование модели выбора
жизненного цикла
Таблица Г.1 - Выбор модели ЖЦ на
основе характеристик требований
|
Требования
|
Каскадная
|
V-образная
|
Прото-типирование
|
Спиральная
|
RAD
|
Инкрементная
|
|
Являются ли требования
легко определимыми и/или хорошо известными
|
Да
|
Да
|
Нет
|
Нет
|
Да
|
Нет
|
|
Могут ли требования заранее
определяться в цикле
|
Да
|
Да
|
Нет
|
Нет
|
Да
|
Да
|
|
Часто ли изменяются
требования в цикле
|
Нет
|
Нет
|
Да
|
Да
|
Да
|
Нет
|
|
Нужно ли демонстрировать
требования с целью определения
|
Нет
|
Нет
|
Да
|
Да
|
Да
|
Нет
|
|
Требуется ли демонстрация
возможностей проверка концепции
|
Нет
|
Нет
|
Да
|
Да
|
Да
|
Нет
|
|
Будут ли требования
отражать сложность системы
|
Нет
|
Нет
|
Да
|
Да
|
Нет
|
Да
|
|
Обладает ли требование
функциональными свойствами на раннем этапе
|
Нет
|
Нет
|
Да
|
Да
|
Да
|
Да
|
|
6
|
6
|
1
|
1
|
4
|
5
|
Таблица Г.2 - Выбор модели ЖЦ на
основе характеристик участников команды разработчиков
|
Команда разработчиков
проекта
|
Каскадная
|
V- образная
|
Прото-типирование
|
Спиральная
|
RAD
|
Инкрементная
|
|
Являются ли проблемы
предметной области проекта новыми для большинства разработчиков
|
Нет
|
Нет
|
Да
|
Да
|
Нет
|
Нет
|
|
Является ли технология
предметной области проекта новой для большинства разработчиков
|
Да
|
Да
|
Нет
|
Да
|
Нет
|
Да
|
|
Являются ли инструменты,
используемые проектом, новыми для большинства разработчиков
|
Да
|
Да
|
Нет
|
Да
|
Нет
|
Нет
|
|
Изменяются ли роли
участников проекта во время ЖЦ
|
Нет
|
Нет
|
Да
|
Да
|
Нет
|
Да
|
|
Могут ли разработчики
проекта пройти обучение
|
Нет
|
Да
|
Нет
|
Нет
|
Да
|
Да
|
|
Является ли структура более
значимой для разработчиков, чем гибкость
|
Да
|
Да
|
Нет
|
Нет
|
Нет
|
Да
|
|
Будет ли менеджер проекта
строго отслеживать прогресс проекта
|
Да
|
Да
|
Нет
|
Да
|
Нет
|
Да
|
|
Важна легкость
распределения ресурсов
|
Да
|
Да
|
Нет
|
Нет
|
Да
|
Да
|
|
Приемлет ли команда
равноправные обзоры инспекций, менеджмент/обзоры заказчиков, а так же стадии
|
Да
|
Да
|
Да
|
Да
|
Нет
|
Да
|
|
3
|
4
|
6
|
5
|
5
|
6
|
Таблица Г.З - Выбор модели ЖЦ на
основе характеристик типа проектов и рисков
|
Тип проекта и риски
|
Каскадная
|
V- образная
|
Прото-типирование
|
Спиральная
|
RAD
|
Инкрементная
|
|
Будет ли проект
идентифицировать новое направление продукта для организации
|
Нет
|
Нет
|
Да
|
Да
|
Нет
|
Да
|
|
Будет ли проект иметь тип
системной интеграции
|
Нет
|
Да
|
Да
|
Да
|
Да
|
Да
|
|
Будет ли проект являться
расширением существующей системы
|
Нет
|
Да
|
Нет
|
Нет
|
Да
|
Да
|
|
Будет ли финансирование
проекта стабильным на всем протяжении ЖЦ
|
Да
|
Да
|
Да
|
Нет
|
Да
|
Нет
|
|
Ожидается ли длительная
эксплуатация продукта в организации
|
Да
|
Да
|
Нет
|
Да
|
Нет
|
Да
|
|
Должна ли быть высокая
степень надежности
|
Нет
|
Да
|
Нет
|
Да
|
Нет
|
Да
|
|
Будет ли система
изменяться, возможно, с применением непредвиденных методов, на этапе
сопровождения
|
Нет
|
Нет
|
Да
|
Да
|
Нет
|
Да
|
|
Является ли график
ограниченным
|
Нет
|
Нет
|
Да
|
Да
|
Да
|
Да
|
|
Являются ли «прозрачными»
интерфейсные модули
|
Да
|
Да
|
Нет
|
Нет
|
Нет
|
Да
|
|
Доступны ли повторно
используемые компоненты
|
Нет
|
Нет
|
Да
|
Да
|
Да
|
Нет
|
|
Являются ли достаточными
ресурсы (время, деньги, инструменты, персонал)
|
Нет
|
Нет
|
Да
|
Да
|
Нет
|
Нет
|
|
4
|
7
|
4
|
7
|
8
|
7
|
Таблица Г.4 - Выбор модели ЖЦ на
основе характеристик пользователей
|
Коллектив Пользователей
|
Каскадная
|
V- образная
|
Прото-типирование
|
Спиральная
|
RAD
|
Инкрементная
|
|
Будет ли присутствие
пользователей ограниченно в ЖЦ
|
Да
|
Да
|
Нет
|
Да
|
Нет
|
Да
|
|
Будут ли пользователи
знакомы с определением системы
|
Нет
|
Нет
|
Да
|
Да
|
Нет
|
Да
|
|
Будут ли пользователи
ознакомлены с проблемами предметной области
|
Нет
|
Нет
|
Да
|
Нет
|
Да
|
Да
|
|
Будут ли пользователи вовлечены
во все фазы ЖЦ
|
Нет
|
Нет
|
Да
|
Нет
|
Да
|
Нет
|
|
Будет ли заказчик
отслеживать ход выполнения проекта
|
Нет
|
Нет
|
Да
|
Да
|
Нет
|
Нет
|
|
1
|
1
|
4
|
1
|
4
|
3
|
приложение д
- диаграмма ганта
приложение е
- Результаты эксперного опроса
Таблица Е.1 - Список опрошенных
|
ФИО опрошенного
|
Должность
|
|
Юльченко Г. И.
|
Бухгалтер
|
|
Анастисенко Ю. В.
|
Кассир
|
|
Фидоревская А. Н.
|
Главный бухгалтер
|
|
Лобова А. Г.
|
Заместитель главного
бухгалтера
|
|
Анисипова А. С.
|
Помощник руководителя
отдела кадров
|
|
Джуров П. В.
|
Руководитель отдела кадров
|
|
Эксперты
|
Критерии оценки
|
|
технический уровень
|
социальные цели
|
получение отчётности
|
простота ипользования
|
коммуникация
|
|
1
|
4
|
2
|
3
|
1
|
5
|
|
2
|
4
|
5
|
4
|
2
|
1
|
|
3
|
3
|
1
|
2
|
4
|
5
|
|
4
|
4
|
3
|
2
|
5
|
1
|
|
5
|
4
|
5
|
1
|
2
|
3
|
|
6
|
3
|
4
|
5
|
2
|
1
|
|
Ранг R
|
22
|
20
|
16
|
16
|
|
Ранг минимальный
|
15
|
|
Оценка
|
0,68
|
0,75
|
0,88
|
0,94
|
0,94
|
|
Общая оценка
|
4,19
|
Рисунок Е.1 - Результаты опроса
Расчет весового коэффициента: