Автоматизированная информационная система ветеринарной клиники, Базы данных

Содержание

Введение5

1Системно-комплексный анализ объекта автоматизации10

1.1Цели и задачи организации, оказывающей ветеринарный услуги населению10

1.2Концептуальная модель объекта автоматизации11

1.2.1Организационная страта системы13

1.2.2Материальная и информационная страты ветеринарной клиники17

1.3Информационная страта объекта автоматизации21

1.3.1Разработка функционального аспекта информационной страты объекта автоматизации21

1.3.2Анализ входных информационных векторов23

1.3.3Анализ выходных информационных векторов26

1.3.4Функция преобразования системы27

1.3.5Структура пользовательского интерфейса29

1.3.6Структурный аспект информационной страты29

2Концептуальная модель данных32

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

2.2Проектирование базы данных методом анализа функциональных зависимостей40

2.2.1Выделение функциональных зависимостей40

2.2.2Проектирование отношений, находящихся в НФБК47

2.3Структурно-функциональный аспект информационной страты объекта52

2.4Обоснование выбора СУБД52

2.4.1MySQL57

2.4.2Oracle8i61

2.4.3СУБД Microsoft SQL Server63

2.4.4IBM DB264

2.4.5СУБД от Informix65

2.4.6Выводы66

2.5Генерация базы данных автоматизированной информационной системы67

2.6Ссылочная целостность данных71

3Разработка пользовательского интерфейса73

3.1Организация интерфейса взаимодействия пользователя с автоматизированной информационной системой73

3.2Визуальное объектно-ориентированное программирование74

3.2.1Архитектура приложений баз данных в Delphi74

3.2.2Модуль данных79

3.2.3Использование технологии ADO средствами Delphi81

3.3Создание форм пользовательского интерфейса106

3.3.1Создание и использование модуля данных106

3.3.2Создание главных форм пользовательского интерфейса107

3.3.3Создание пользовательского интерфейса109

3.3.4Создание пользовательского интерфейса для пользователей-администраторов113

3.4Программно-аппаратные средства АИС114

4Руководство пользователя АИС «Регистратура ветклиники»115

4.1Инструкция по применению для массового пользователя115

4.2Инструкция по применения для администратора125

5Организационно-экономическая часть129

5.1Организация и планирование работ129

5.1.1Назначение АИС «Регистратура ветеринарной клиники»129

5.1.2Анализ рынка сбыта131

5.1.3План маркетинга132

5.1.4План производства132

5.1.5Организационный план135

5.1.6Юридический план137

5.1.7Оценка риска137

5.2Определение затрат и договорной цены разработки138

5.2.1Расходы на материалы и покупные изделия139

5.2.2Расходы на специальное оборудование139

5.2.3Расчёт основной заработной платы139

5.2.4Расчет дополнительной заработной платы142

5.2.5Расчёт отчислений на социальные нужды142

5.2.6Расчёт накладных расходов142

5.2.7Расчёт договорной цены143

5.3Экономическая целесообразность проекта144

5.3.1Конкурентоспособность АИС144

5.3.2Маркетинг146

5.3.3Оценка эффективности147

5.4Выводы148

6Охрана труда. Организация оптимального рабочего места инженера-разработчика150

6.1Освещение рабочего места150

6.2Микроклимат помещений155

6.2.1Выбор расчетных параметров наружного воздуха.157

6.2.2Выбор расчетных параметров внутреннего воздуха.158

6.2.3Составления теплового и влажностного баланса помещения159

6.2.4Графоаналитическое построение процессов термовлажностной обработки воздуха161

6.3Выводы167

Заключение169

Библиографический список172

Выдержка из текста работы

ИНФОРМАЦИОННАЯ СИСТЕМА, РАБОТА С ДАННЫМИ, ИНТЕФЕЙС, ТРЕБОВАНИЯ, МОДЕЛЬ ЖИЗНЕННОГО ЦИКЛА, МОДЕЛИРОВАНИЕ, ПРОЕКТИРОВАНИЕ, РЕАЛИЗАЦИЯ, БАЗА ДАННЫХ, ТЕСТИРОВАНИЕ, ФИЗИЧЕСКОЕ ПРЕДСТАВЛЕНИЕ СИСТЕМЫ, ЛОГИЧЕСКОЕ ПРЕДСТАВЛЕНИЕ СИСТЕМЫ.

Темой дипломного проекта является «Разработка автоматизированной информационной системы учета для расчёта заработной платы ОАО РПТ «Авторемонтник»».

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

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

Результаты работы могут быть применены на базе ОАО РТП «Авторемонтник» для повышения качества условий труда бухгалтеров и сотрудников отдела кадров.

ABSTRACT

The diploma project contains 102 pages of graduation work 47 drawings,10 tables, 6 applications, 45 references.

KEY WORDS: INFORMATION SYSTEM USING DATA INTEFEYS, REQUIREMENTS, LIFE CYCLE MODEL, SIMULATION, DESIGN, IMPLEMENTATION, DATA BASE, TESTING, PHYSICAL REPRESENTATION OF SYSTEM LOGIC SYSTEM PERFORMANCE.

The theme of the diploma project is «Development of an automated information system of accounting for payroll of RPT» refinishing «.»

The data sources for this diploma project were books, periodicals, electronic resources used as a theoretical basis for the problem. Thus, the literary sources were used as practical tools for implementation of the project.

The project implemented a software module «Payroll» that automates the activities of the HR staff and employees of the accounting department.

The results can be applied on the basis of OAO RTP «Avtoremontnik» to improve the quality of working accountants and employees of the personnel department.

СОДЕРЖАНИЕ

ВВЕДЕНИЕ

1. РАЗРАБОТКА ТРЕБОВАНИЙ К ПРОГРАММНОМУ ОБЕСПЕЧЕНИЮ

1.1 Анализ существующих решений по автоматизации предметной области

1.2 Выбор методологии проектирования информационной системы

1.3 Анализ предметной области

1.4 Сбор требований

1.5 Анализ и моделирование требований

1.6 Спецификация требований

1.7 Аттестация требований

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

2. ПРОЕКТИРОВАНИЕ ИНФОРМАЦИОННОЙ СИСТЕМЫ

2.1 Архитектурное проектирование

2.2 Проектирование баз данных

2.3 Проектирование пользовательского интерфейса

2.4 Обоснование выбора платформы

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

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

3. РЕАЛИЗАЦИЯ И АТТЕСТАЦИЯ ИС

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

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

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

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

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

4. УПРАВЛЕНИЕ ИНФОРМАЦИОННЫМ ПРОЕКТОМ

4.1 Выбор жизненного цикла разработки ПО

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

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

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

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

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

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

4.8 Оценка эффективности проекта

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

ЗАКЛЮЧЕНИЕ

СПИСОК СОКРАЩЕНИЙ

CПИСОК ИСПОЛЬЗУЕМЫХ ИСТОЧНИКОВ

ПРИЛОЖЕНИЕ А — СПЕЦИФИКАЦИЯ ТРЕБОВАНИЙ К ПРОГРАММНОМУ ОБЕСПЕЧЕНИЮ

ПРИЛОЖЕНИЕ Б — ТЕХНИЧЕСКОЕ ЗАДАНИЕ

ПРИЛОЖЕНИЕ В — ТЕСТОВЫЕ ПРИМЕРЫ

ПРИЛОЖЕНИЕ Г — ОБОСНОВАНИЕ МОДЕЛИ ВЫБОРА ЖИЗНЕННОГО ЦИКЛА

ПРИЛОЖЕНИЕ Д — ДИАГРАММА ГАНТА

ПРИЛОЖЕНИЕ Е — РЕЗУЛЬТАТЫ ЭКСПЕРНОГО ОПРОСА

информационная система модуль база данных

ВВЕДЕНИЕ

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

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

На современном этапе развития информатизации и автоматизации характерно использование распределенной обработки информации. Наиболее перспективной сферой использования концепции распределенной обработки информации является автоматизация планово-управленческих функций на базе персональных компьютеров, установленных непосредственно на рабочих местах специалистов. Системы, выполняющие эти функции, получили широкое распространение под названием автоматизированные рабочие места (АРМ) [1].

Цель данной работы является разработка информационной системы «Расчёт зарплаты» для предприятия ОАО РТП «Авторемонтник». Для достижения данной цели необходимо решить следующие задачи:

– сбор, анализ, аттестация требований;

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

– реализация и тестирование системы;

– развертывание системы;

– экспертная оценка системы.

1. РАЗРАБОТКА ТРЕБОВАНИЙ К ПРОГРАММНОМУ ОБЕСПЕЧЕНИЮ

1.1 Анализ существующих решений по автоматизации предметной области

На данный момент на рынке существуют множество средств для расчёта заработной платы на предприятии. Наиболее популярные из них являются «1С: Предприятие» и «БухСофт: Предприятие».

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

1С: Предприятие — это и технологическая платформа, и пользовательский режим работы. Технологическая платформа предоставляет объекты (данных и метаданных) и механизмы управления объектами. Объекты (данные и метаданные) описываются в виде конфигураций. При автоматизации какой-либо деятельности составляется своя конфигурация объектов, которая и представляет собой законченное прикладное решение. Конфигурация создаётся в специальном режиме работы программного продукта под названием «Конфигуратор», затем запускается режим работы под названием «1С: Предприятие», в котором пользователь получает доступ к основным функциям, реализованным в данном прикладном решении (конфигурации) [2]. Пример работы 1С:Предприятие изображён на рисунке 1.1.

Достоинствами «1С: Предприятие» является:

— платформа приспособлена под российское законодательство и позволяет легко подстраиваться под регулярно меняющиеся законы;

— обладает высокой производительностью, что дает возможность решать с ее помощью самые сложные задачи;

— возможность использовать MS SQL Server.

Недостатки:

— достаточно сложна в освоении и требует специального обучения пользователей;

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

— программа является платной;

— из-за уникальности предприятий конфигурации требуют доработки.

Программа «БухСофт: Предприятие» предназначена для комплексной автоматизации бухгалтерского, налогового, управленческого, кадрового, складского и оперативного учета на предприятии в полном соответствии с требованиями бухгалтерского, налогового и трудового законодательства [3]. Пример работы программы показан на рисунке 1.2.

Достоинства программы:

— формирование отчётов в Microsoft Exel;

— высокая производительность.

Недостатки программы:

— программа является платной;

— в программе не предусмотрено взаимодействие с удалённым сервером базы данных.

Рассматривая аналогичные прикладные решения можно сделать вывод, что они не удовлетворяют требованиям поставленной задачи. В связи с этим принято решение разработать программу «Расчёт зарплаты» в рамках данного дипломного проекта, которая позволит вести учет заработной платы сотрудникам предприятия ОАО РТП «Авторемонтник».

1.2 Выбор методологии проектирования информационной системы

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

Основополагающей идеей ООП является объединение данных и обрабатывающих их процедур в единое целое — объект.

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

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

ООП дает возможность создавать расширяемые системы (extensible systems). Это одно из самых значительных достоинств ООП и именно оно отличает данный подход от традиционных методов программирования. Расширяемость (extensibility) означает, что существующую систему можно заставить работать с новыми компонентами, причем без внесения в нее каких-либо изменений. Компоненты могут быть добавлены на этапе выполнения [5].

Компонентно-ориентированное программирование — это своеобразная «надстройка» над ООП, набор правил и ограничений, направленных на построение крупных развивающихся программных систем с большим временем жизни. Программная система в этой методологии представляет собой набор компонентов с хорошо определёнными интерфейсами. Изменения в существующую систему вносятся путём создания новых компонентов в дополнение или в качестве замены ранее существующих. При создании новых компонентов на основе ранее созданных запрещено использование наследования реализации — новый компонент может наследовать лишь интерфейсы базового. Таким образом, компонентное программирование обходит проблему хрупкости базового класса [6, 7].

Для разработки данного программного средства выбран объектно-ориентированный подход к программированию в силу следующих факторов:

– возможность повторного использования кода;

– отсутствие необходимости разработки классов с нуля, за счет наследования;

– повышение безопасности кода за счет инкапсуляции;

– гибкость при модификации и расширении системы;

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

1.3 Анализ предметной области

Строительство ОАО РТП «Авторемонтник» началось в мае 1964 года на бывшем пустыре в юго-восточной части города Сальска рядом с Сальской текстильно-галантерейной фабрикой. Проектно-сметная документация была разработана в 1963 году Ростовским отделением института «Гипроавтотранс». Проектная мощность авторемонтного завода составила 1600 условных ремонтов автомобилей ГАЗ-51 в год (1000 шт. автомобилей, 1000 шт. двигателей, 1000 шт. КПП, и по 1000шт. задних и передних мостов).

Направление деятельности предприятия:

– производит установку на автобусы марки ЛАЗ, ЛИАЗ, «Икарус», автомобиль марки КАМАЗ и другую технику двигатели марки ЯМЗ-236, ЯМЗ-238, на автомобиль марки УАЗ-469 утепленную металлическую крышу и дизельный двигатель марки Д-21;

– производит ремонт автобусов марки ЛАЗ, ЛИАЗ, КАВЗ, ПАЗ, «Кубань», и реализация прошедших капитальный ремонт автобусов марки «Кубань»;

– производит установку ремней безопасности на пассажирские автобусы;

– производит окраску грузовых и легковых автомобилей;

– производит продажу тепловой энергии физическим и юридическим лицам. Организационная структура предприятия изображена на рисунке 1.3.

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

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

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

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

1. обязательные удержания, на которые не требуется соглашение работника;

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

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

Трудовые доходы, т.е. все виды оплаты труда, облагаются по единой ставке 13 %.

Пассивные доходы облагаются по более высоким фиксированным ставкам:

– 30 % — суммы дивидендов, доходы, полученные лицами, не являющимися налоговыми резидентами Российской Федерации;

– 35 % — доходы в виде выигрышей по лотереям, тотализаторам и другим играм, основанным на риске; стоимость призов и выигрышей, полученных на конкурсах и др.;

– 9 % — доходы в виде дивидендов, получаемых физическими лицами, являющимися резидентами.

1.4 Сбор требований

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

Требования — это описание необходимых или желаемых свойств продукта.

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

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

Сбор требований проводился методом интервьюирования, который заключается в беседе между разработчиком системы и заказчиком. Этот метод применяется, когда большим объемом знаний обладает ограниченный круг людей, и обычно используется для беседы с одним человеком [9, 10].

В таблице 1.1 приведены вопросы и ответы из интервью с бухгалтером.

Таблица 1.1 — Сбор требований способом «интервью»

Вопрос	Ответ
Для чего проектируется информационная система?	Целью информационной системы является расчёт заработной платы сотрудникам ОАО РТП «Авторемонтник».
Какая система оплаты труда используется на предприятии?	Повременная система оплаты труда
Чем занимается администратор ИС?	Администратор системы подготавливает ПК к установке, настройке и последующей эксплуатации информационной системы.
Какую роль играет работник отдела кадров в ИС?	Заполняет лицевые счета работников и ведёт их личные дела.
На какой операционной системе будет запускаться ИС?	Windows XP.
Какую форму отчёта должна выгружать информационная система?	Расчетный листок.

Таблица 1.1 — Сбор требований способом «интервью» продолжение

Какой вид интерфейса более предпочтителен?

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

Какие дополнительные возможности должны будут реализованы в ИС?

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

- Расчёт удержаний и других вычетов из заработной платы;

- Возможность сохранения данных и просмотр данных за предыдущие периоды.

1.5 Анализ и моделирование требований

Цель анализа — качественно и подробно описать требования, которые позволят менеджерам реалистично оценить все затраты на проект, а разработчику — начать проектирование, разработку и тестирование [11].

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

Диаграмма вариантов использования — диаграмма, на которой отражены отношения, существующие между актёрами и вариантами использования.

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

В информационной системе используются три роли:

– администратор ИС;

– работник отдела кадров;

– бухгалтер.

Таблица 1.2- Описание ролей информационной системы

Название роли	Описание
Администратор ИС	Создаёт и удаляет пользователей, следит за работой информационной системы. Устраняет неисправности в работе системы.
Сотрудник отдела кадров	Заполняет, редактирует данные о сотрудниках в информационной системе. Ведёт их личные дела.
Бухгалтер	Производит расчёт заработной платы. Выводит отчёты.

Диаграмма классов — статическая структурная диаграмма, описывающая структуру системы, демонстрирующая классы системы, их атрибуты, методы и зависимости между классами [8]. Диаграмма классов предоставлена на рисунке 1.5.

Таблица 1.3-Описание классов

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

1.6 Спецификация требований

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

Описание требований заказчика осуществляется по четырем категориям. Категории представлены и описаны в следующей таблице 1.1.

Таблица 1.4 — Категории описания требований

Категория	Описание
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 этапа её разработки:

1. концептуальное моделирование;

2. логическое моделирование;

3. физическое моделирование.

Концептуальная модель данных — записанные знания о физических и логических объектах реального мира (люди, компоненты инфраструктуры, наряды на работу, договора, соглашения и т. д.), которыми необходимо управлять наиболее рациональным образом. Концептуальная модель информационной системы представлена на рисунке 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.

ADO.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 — Реляционная СУБД (Система управления реляционными базами данных). 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 — сумма оплаты труда;

O — сумма фиксированного оклада;

T — количество дней (часов) в рабочем месяце,

P — отработанное время.

Метод, выполняющий расчёт оплаты труда показан на рисунке 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 этапа:

1. Выбор методов тестирования

2. Создание плана тестирования

3. Разработка тестовых примеров

4. Анализ результатов тестирования

Существует несколько методов тестирования, рассмотрим два из них.

Метод «Белого ящика» используется в случае, когда тестировщиком является человек, который знает все процессы, происходящие в приложении. Как правило, в таких случаях тестировщиком является сам разработчик приложения. Тестирование компонентов форм на стадии разработки осуществляется в режиме отладки с использованием специального средства 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

V_k — вес k-го критерия эффективности проекта, 0 ? V_k ? 1, ;

E_ik — оценка i-м экспертом k-го критерия, 0 ? E_ik ? 1 ;

M — количество экспертов;

N — количество критериев эффективности проекта.

Весовой коэффициент вычисляется по формуле 4.2:

,(4.2)

где- весовой коэффициент, баллы;

— оценка, баллы.

Расчет оценки ведется по формуле 4.3:

, (4.3)

где- минимальное значение ранга, баллы;

— сумма рангов, баллы.

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

,(4.4)

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

— количество экспертов.

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

Определяя показатели работы системы можно свести их в таблицу. В ней же следует указать показатели этих критериев (таблица 4.1). Так же можно выделить 5 критериев оценки ИС:

– Технический уровень;

– Социальные цели;

– Получение отчетности;

– Простота использования

– Коммуникации.

Таблица 4.1 -критерии оценки работы ИС

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

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

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

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

Представленные результаты сведены в таблице на рисунке 4.7.

Определив весовые коэффициенты, по формуле 4.3, можно рассчитать общий показатель эффективности АИС.

Y=(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.

During the performance of the diploma project was designed and developed a software payroll module.

In 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.

In 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.

In the second section, performed architectural design AIS, database design and user interface design.

AIS 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#.

The 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.

Demonstrated 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.

The 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.

Compiled 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.

The efficiency of the AIS, which showed that the implementation of the project feasible.

During 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.

In conclusion it is possible to draw a conclusion: the objectives of the work achieved, and the task is executed.

The result of intellectual activity:

Specialty: «IT» (in management).

Topic: Creating a payroll system (in the example of RTP «Avtoremontnik»).

Prospective RIA:

Payroll 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.

System requirements for the hardware and software environment in which the software works:

Architecture — client-server, operating system — Windows XP and above, the programming language C #; data warehouse — MySQL 5.1.40.

The developed software is provided with the application deployment method. Thematic database information sources — 45 items.

The intended users (Customer) RIA: The organization uses time-based payroll system.

Список сокращений

АИС — автоматизированная информационная система;

АРМ — автоматизированное рабочее место;

БД — база данных;

ГИП — графический интерфейс пользователя;

ЖЦ — жизненный цикл;

ИС — информационная система;

ООП — объектно-ориентированное программирование;

ПО — программное обеспечение;

СУБД — система управления базами данных;

CLR — Common Language Runtime;

GUI — графический интерфейс пользователя;

JAD — Joint application design;

JRP — Joint Requirements Planning;

RAD — Rapid Application Development;

SQL — Structured Query Language;

SRS — Software Requirements Specification.

CПИСОК ИСПОЛЬЗУЕМЫХ ИСТОЧНИКОВ

1.Гарсиа, М.Ф. Справочник системного администратора. 3-е издание. Перевод с английского. — М.: СП Эком, 2005. -976с.

2.Помощь в 1С http://help1c.com/faq/print/1354.html [Электронный документ], проверено 01.05.2013.

3.Официальный сайт компании «Бухсофт» http://www.buhsoft.ru/?title=bp2.php [Электронный документ], проверено 01.05.2013.

4.Основы программирования на C++, PASCAL http://kufas.ru/programming94.htm [Электронный документ], проверено 01.05.2013.

5.»Плюсы и минусы объектно-ориентированного программирования» http://www.uni-vologda.ac.ru/oberon/infoart/plus&min.htm [Электронный документ], проверено 01.05.2013.

6.Грехмен. Объектно-ориентированные методы. Принципы и практика. 3-е издание. — М.: Вильямс, 2004. -960с.

7.Буч, Г. Объектно-ориентированный анализ и проектирование. Перевод с английского. — М: «Издательство Бином», 1999.

8.Буч, Г. UML — руководство пользователя. — М: ДМК, 2001.

9.Вигерс, К. И. Разработка требований к программному обеспечению.: Пер. с англ. К. Вигерс. — М.: Издательско-торговый дом «Русская Редакция», 2004.

10.Мацяшек, Л. А. Анализ требований и проектирование систем. Разработка информационных систем с использованием UML.: Пер. с англ. Л.А. Мацяшек.- М.: Издательский дом «Вильямс», 2002.

11.Леффингуэлл, Д. Принципы работы с требованиями к программному обеспечению. Унифицированный подход.: Пер. с англ. Уидриг Д., Леффингуэлл, Д. — М.: Издательский дом «Вильямс», 2002 — 448 с.

12.ГОСТ 19.202-78 «ЕСПД Спецификация. Требования к содержанию и оформлению».

13.Соммервилл, И. Инженерия программного обеспечения — М: 6-е издание. «Вильямс», 2002.

14. Джалота, П. Управление программным проектом на практике. Из-во: Лори, 2005.

15. Шмуллер, Д. Освой самостоятельно UML 2 за 24 часа. Практическое руководство — М.: «Вильямс», 2005.

16. Роб, П., Коронел, К. Системы баз данных: проектирование, реализация и управление. — 5-е изд. СПб.: БХВ-Петербург, 2004.

17. Избачков, Ю.С., Петров, В.Н. Информационные системы. Учебник для вузов. 2-е изд. — СПб.: Питер, 2005.

18. Гайдамакин, Н. А. Автоматизированные информационные системы, базы и банки данных. Вводный курс., 2002.

19. Коннолли, Т., Бегг, К. Базы данных. Проектирование, реализация и сопровождение. Теория и практика. 3-е издание.: Пер. с англ. — М. : Издательский дом «Вильямс», 2003. — 1440 с.

20. Диго, С.М. Проектирование и использование баз данных. — М.: Финансы и статистика. 1995. — 216с.

21. Microsoft Corporation. Проектирование и реализация баз данных Microsoft SQL Server 2005. Учебный курс MCAD/MCSE, MCDBA. Пер. с англ. — 3-изд., испр. — М.: Издательско-торговый дом Русская Редакция, 2006.

22. Мандел, Т. Дизайн интерфейсов: Модели пользовательского интерфейса; Объектно-ориентированные интерфейсы; Этапы разработки интерфейса; Web-интерфейсы. Самоучитель.: Пер. с англ. Мандел, Т. — М.: ДМК Пресс. 2005. — 425 с.

23. Ганеев, Р. М. Проектирование интерфейса пользователя средствами Win32 API. Из-во: Горячая Линия — Телеком, 2001.

24. Бизнес-правила http://www.tadviser.ru/index.php/Статья:Бизнес-правила [Электронный документ], проверено 01.05.2013.

25. Библиотека MSDN по-русски http://msdn.microsoft.com/library [Электронный документ], проверено 01.05.2013

26. Нейгел К., Ивьен Б., Глинн Дж., Уотсон К., Скиннер М. Visual С# 2008. Базовый курс. Из-во: Вильямс, 2009.

27. Малик, С. Microsoft ADO.NET 2.0 для профессионалов: «Вильямс», 2006.

28. Гандерлой, М. ADO и ADo.NET. Полное руководство. Перевод с английского. — К.: «ВЕК+». 2003. -912с.

29. Фатрелл, Т. Управление программными проектами: достижение оптимального качества при минимуме затрат: Пер. с англ — М.: Издательский дом «Вильямс», 2004.

30. Microsoft Press. Разработка Windows-приложений на Microsoft Visual Basic .NET и Microsoft Visual C#. Из-во: Москва,2003

31. Дунаев, В.В. Базы данных. Язык SQL. — СПб.: БХВ — Петербург, 2006.

32. Лапыгин, Ю.Н. Управление проектами: от планирования до оценки эффективности — Омега-Л «Москва», 2008.

33. Тамрле, Л. Введение в тестирование программного обеспечения.: Пер. с англ.. — М.: Издательский дом «Вильямс», 2003. — 368 с.

34. Благодатских В.А., Волкин В.А., Поскакалов К.Ф. Стандартизация разработки программных средств. — М.: Финансы и статистика, 2005

35. Дейтел, Х. C#. Наиболее полное руководство. Из-во: БХВ — Петербург, 2006.

36. Арчибальд, Р. Управление высокотехнологичными программами и проектами: Пер. с англ. Мамонтова Е. В.; Под ред. Баженова А. Д., Арефьева А. О. — 3-е изд., перераб. и доп. — М.: Компания АйТи ; ДМК Пресс, 2004.-472 с.: ил.

37. Джалота, П.. Управление программным проектом на практике.: Пер. с англ. — М. : Издательство «Лори», 2005. — 242 с. : ил.

38. Богданов, В.В. Управление проектами в Microsoft Project: Учебный курс. — СПб.: Питер, 2003.

39. Сингаевская, Г.И. Управление проектами в Microsoft Project 2007 / М.: «Диалектика», 2008.

40. Таунсенд К., Фохт Д., Кондратенко В., Трубицына В. Проектирование и программная реализация экспертных систем/ — М.: Финансы и статистика, 2000.

41. Марченко А.Л. Основы программирования на С# 2.0. Из-во: Интернет-университет информационных технологий, 2007.

42. Ахо, А.В., Хопкрофт Дж., Ульман Дж. Д. Структуры данных и алгоритмы — М.: «Вильямс», 2000.

43. Курс MS Project 2010 http://www.microsoftproject.ru/ [Электронный документ] проверено 01.05.2013.

44. Бонни Бьяфоре Все по плану! Успешное управление проектами с использованием MicrosoftProject = OnTime! On Track! On Target!: Managing Your Projects Successfully with Microsoft Project. — М.: Microsoft Press, 2006. — С. 304.

45. Экспертные оценки http://www.spc-consulting.ru/app/expert.htm [Электронный документ] проверено 01.05.2013.

Приложение А — Спецификация требований к программному обеспечению

Введение

Назначение

Эта спецификация требований описывает функциональные и нефункциональные требования для разрабатываемой АИС «Расчёт зарплаты» для ОАО РТП «Авторемонтник» г. Сальск. Система предназначена для расчёта заработной платы по временной системе оплаты труда и вывода отчёта в виде расчётного листка. Цель

Итоговой целью разработки является разработка автоматизированной информационной расчёта заработной платы «Расчёт зарплаты».

Область действия

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

Общее описание

Описание продукта

Функциональные возможности

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

? ведение базы данных личных дел сотрудников предприятия;

? расчёт налога на доход физических лиц.

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

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

Классы и характеристики пользователей

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

Категория пользователя	Описание
Администратор ИС	Создаёт и удаляет пользователей, следит за работой информационной системы. Устраняет неисправности в работе системы.
Сотрудник отдела кадров	Заполняет, редактирует данные о сотрудниках в информационной системе. Ведёт их личные дела.
Бухгалтер	Производит расчёт заработной платы. Выводит отчёты.

Общие ограничения

Операционная среда-1.Минимальные требования к операционной системе — Windows XP SP2. Ограничения дизайна и реализации-1. База данных должна быть спроектирована на MySQL 5.1.40.

Документация для пользователей

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

Требования к системе

Требование	Описание
Архитектура	Клиент-серверная
Среда разработки	Visual Studio 2008
Язык программирования	С#, Transact SQL
Операционная система рабочей станции	Windows XP
Программное обеспечение рабочей станции	.NET Framework 2.0

Функциональные требования

Функция	Требование
Добавление пользователя в систему	Система должна иметь модуль для создания новых пользователей в систему
Просмотр событий	Система должна обеспечивать просмотр событий пользователей

Требования к внешнему интерфейсу

Интерфейсы пользователя-1. Экраны вывода должны соответствовать общепринятым стандартам.

Интерфейсы пользователя-2. Формы должны предоставлять полную возможность навигации и выбор при помощи клавиатуры и мыши.

Требования к производительности

Требования к производительности-1.Обмен между приложением и БД должен осуществляться с задержками ответа на запрос не более 7 сек.

Требования к производительности-2.Формирование отчета должно производиться за время, приемлемое для непрерывной работы пользователя (не более 25 сек).

Требования к охране труда

Требования к охране труда не определены.

Требования к безопасности

Система имеет разграничение доступа.

Атрибуты качества ПО

Доступность-1.Система должна быть доступна в рабочее время с 08.00 до 17:00 и во время проведения испытаний.

Приложение б — Техническое задание

Техническое задание на разработку программы «Расчёт зарплаты»

Содержание

1. Введение

1.1. Наименование программы

1.2. Назначение и область применения

2. Требования к программе

2.1. Требования к функциональным характеристикам

2.2. Требования к надежности

2.2.1. Требования к обеспечению надежного функционирования программы

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

2.2.3. Отказы из-за некорректных действий пользователей системы

3. Условия эксплуатации

3.1. Требования к квалификации и численности персонала

3.2. Требования к составу и параметрам технических средств

3.3. Требования к информационной и программной совместимости

3.3.1. Требования к информационным структурам и методам решения

3.3.1.1. Структура баз данных

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

3.3.2. Требования к исходным кодам и языкам программирования

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

3.3.4. Требования к защите информации и программ

3.4. Специальные требования

4. Требования к программной документации

4.1. Предварительный состав программной документации

5. Стадии и этапы разработки

5.1. Стадии разработки

5.2. Этапы разработки

5.3. Содержание работ по этапам

6. Порядок контроля и приемки

6.1. Виды испытаний

6.2. Общие требования к приемке работы

1. Введение

1.1. Наименование программы

Наименование программы: «Расчёт зарплаты»

1.2. Назначение и область применения

Программа предназначена для расчёта заработной платы на предприятии ОАО РТП «Авторемонтник» и включает следуещее:

1.2.1. Расчёт повременной оплаты труда

1.2.2. Расчёт удержаний из зарплаты

1.2.3. Вывод отчёта в виде расчётного листка

Программа представляет собой клиент-серверное приложение работающее под управлением Microsoft Windows XP.

2. Требования к программе

2.1. Требования к функциональным характеристикам

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

2.1.1. Разделение пользователей на группы:

2.1.1.1. Бухгалтера

2.1.1.2. Специалисты отдела кадров

2.1.1.3. Администраторов ИС

2.1.2. Возможность авторизации в инормационной системе

2.1.3. Возможность добавление, редактирование личных данных сотрудников

2.1.3. Возможность расчёта повременной оплаты труда

2.1.4. Возможность вывода отчёта за определённый период

2.1.5. Возможность добавления новых пользователей в систему

2.2. Требования к надежности

2.2.1. Требования к обеспечению надежного функционирования программы

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

а) организацией бесперебойного питания технических средств;

б) использованием лицензионного программного обеспечения;

в) регулярным выполнением рекомендаций Министерства труда и социального развития РФ, изложенных в Постановлении от 23 июля 1998 г. Об утверждении межотраслевых типовых норм времени на работы по сервисному обслуживанию ПЭВМ и оргтехники и сопровождению программных средств»;

г) регулярным выполнением требований ГОСТ 51188-98. Защита информации. Испытания программных средств на наличие компьютерных вирусов

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

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

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

2.2.3. Отказы из-за некорректных действий пользователей системы

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

3. Условия эксплуатации

3.1. Требования к квалификации и численности персонала

Минимальное количество персонала, требуемого для работы программы, должно составлять не менее 3 штатных единиц — администратор ИС, бухгалтер испециалист отдела кадров. Администратор должен иметь высшее профильное образование и сертификаты компании-производителя операционной системы. В перечень задач, выполняемых администратором, должны входить:

а) задача поддержания работоспособности технических средств;

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

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

г) задача создания резервных копий базы данных.

3.2. Требования к составу и параметрам технических средств

3.3.1. В состав технических средств должен входить IВМ-совместимый персональный компьютер (ПЭВМ), включающий в себя:

3.3.1.1. процессор Pentium-IV 2GHz, не менее;

3.3.1.2. оперативную память объемом, 512Мегабайт, не менее;

3.3.1.3. HDD, 20 Гигабайт, не менее;

3.3.1.4. операционную систему Windows XP;

3.3. Требования к информационной и программной совместимости

3.3.1. Требования к информационным структурам и методам решения

База данных работает под управлением MySQL 5.1.40.

3.3.1.1. Структура баз данных

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

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

3.3.2. Требования к исходным кодам и языкам программирования

Дополнительные требования не предъявляются.

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

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

3.3.4. Требования к защите информации и программ

Требования к защите информации и программ не предъявляются.

3.4. Специальные требования

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

4. Требования к программной документации

4.1. Предварительный состав программной документации

Состав программной документации должен включать в себя:

4.1.1. техническое задание;

4.1.2. программу и методики испытаний;

4.1.3. руководство оператора;

5. Стадии и этапы разработки

5.1. Стадии разработки

Разработка должна быть проведена в три стадии:

1. разработка технического задания;

2. рабочее проектирование;

3. внедрение.

5.2. Этапы разработки

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

На стадии рабочего проектирования должны быть выполнены перечисленные ниже этапы работ:

1. разработка программы;

2. разработка программной документации;

3. испытания программы.

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

5.3. Содержание работ по этапам

На этапе разработки технического задания должны быть выполнены перечисленные ниже работы:

1. постановка задачи;

2. определение и уточнение требований к техническим средствам;

3. определение требований к программе;

4. определение стадий, этапов и сроков разработки программы и документации на неё;

5. согласование и утверждение технического задания.

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

На этапе испытаний программы должны быть выполнены перечисленные ниже виды работ:

1. разработка, согласование и утверждение и методики испытаний;

2. проведение приемо-сдаточных испытаний;

3. корректировка программы и программной документации по результатам испытаний. На этапе подготовки и передачи программы должна быть выполнена работа по подготовке и передаче программы и программной документации в эксплуатацию на объектах Заказчика.

6. Порядок контроля и приемки

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	17	16	16
Ранг минимальный	15
Оценка	0,68	0,75	0,88	0,94	0,94
Общая оценка	4,19

Рисунок Е.1 — Результаты опроса

Расчет весового коэффициента:

Размещено на