33
Все указанные недостатки отсутствуют у программ, изначально написанных
для нужд конкретного заказчика («под заказ») и находящихся на сервисном обслу-
живании у производителя. Поэтому для решения выбранной задачи предлагается
самостоятельное написание программы для автоматизации работы менеджера
учебного центра.
1.3.2 Выбор и обоснование стратегии автоматизации задачи
На сегодняшний день существует четыре стратегии автоматизации:
хаотичная (кусочная) автоматизация,
по участкам,
по направлениям,
комплексная (полная) автоматизация.
Хаотичная автоматизация предполагает, что компания приобретает или раз-
рабатывает программный продукт, не имея четкого плана по автоматизации дея-
тельности. Основным критерием автоматизации в такой стратегии является реше-
ние сиюминутных задач. Итогом хаотичной стратегии является наличие в компа-
нии программных продуктов, которые зачастую с трудом «уживаются» друг с дру-
гом, принося огромные неудобства сотрудникам. Программные продукты, которые
приобретаются и устанавливаются хаотично не способны оказать реальной пользы
предприятию в целом. Дальнейшее развитие информационной системы предприя-
тия связано с новыми, значительными затратами.
Автоматизация по участкам предусматривает автоматизацию отдельных
бизнес процессов, объединенных по набору выполняемых функций. Этот способ
автоматизации выбирается при условии, если существуют участки, где применение
автоматизированных систем дает значительный экономический эффект, например
за счет сокращения персонала, или сокращения времени работы с документами.
Автоматизация по направлениям подразумевает автоматизацию отдельных
направлений деятельности компании. В этом случае компания получает полную
автоматизацию работы. Такой подход к автоматизации вполне нормален и в даль-
нейшем интеграция уже автоматизированных направлений в рамках всего пред-
приятия не будет связана с серьезными препятствиями.
34
Комплексная автоматизация, соответственно, предполагает полную автома-
тизацию все существующих бизнес процессов компании [12].
В случае с автоматизацией работы менеджера компьютерных курсов, наибо-
лее подходящей является автоматизация по участкам.
Выбор стратегии основан на том, что выполняется набор функций одного
сотрудника при выполнении определенной работы. При этом деятельность других
сотрудников автоматизирована другими программными продуктами.
Процесс автоматизации поставленной задачи сводится к последовательному
выполнению стандартного набора этапов по созданию информационной системы:
— оценка рисков проекта;
— детальный анализ предметной области;
— составление технического задания на систему;
— покупка готового или создание, тестирование и доработка систем;
— внедрение, опытная эксплуатация и поддержка.
На первом этапе планируется выявить и оценить все риски, связанные с реа-
лизацией создания автоматизированной системы, как то: людские, технические,
непредвиденные ситуации и прочее.
Затем необходимо проанализировать предметную область, определить функ-
ции системы, потоки данных и информационные накопители, пожелания пользова-
теля к системе.
На основе анализа предметной области создается база данных, как основной
компонент системы и спроектировано клиентское приложение. Затем создается
приложение, выполняется тестирование, исправление ошибок и коррекция.
Конечный этап проекта автоматизации – внедрение системы и опытная экс-
плуатация.
1.3.3 Выбор и обоснование способа приобретения ИС для автоматизации
задачи
Автоматизация задачи может быть осуществлена несколькими способами
(рисунок 8) .
35
Рисунок 8 – Способы приобретения ИС
Самым очевидным способом для компании является приобретение готового
продукта. Однако ранее были перечислены недостатки такого решения:
1. Излишний функционал, который делает работу с программами неудоб-
ной.
2. Высокая стоимость программы.
3. Невозможность доработки, модернизации.
Другой вариант приобретения ИС - покупка и доработка готового продукта,
если есть такая возможность. Данный вариант удобен тем, что основной функцио-
нал уже заложен в программе, но добавить недостающие функции всегда возмож-
но. Остальные недостатки, присущие готовым продуктам, остаются.
Третий вариант – заказ продукта у разработчика «под ключ» имеет следую-
щие преимущества:
- учитывает все требования заказчика вплоть до интерфейса системы;
- обычно предполагает обучение персонала и сопровождение системы, то
есть возможность доработки и модернизации;
- отсутствуют излишние функции в программе.
Основным недостатком данного варианта является высокая стоимость по-
добной разработки.
Последний вариант – это создание собственной системы своими силами. В
этом случае все недостатки готового решения устраняются. Стоимость такого ре-
шения складывается в основном из стоимости платформы разработки, но если ис-
пользовать уже имеющиеся средства (например, платформу «1С:Предприятие»), то
стоимость решения минимизируется.
Приобретение ИС
Покупка готового
решения
Покупка и доработка
решения
Собственная
разработка
Заказ решения "под
ключ"
36
В результате принято разработать собственную систему на платформе
«1С:Предприятие 8.3».
1.4 Обоснование проектных решений
1.4.1 Обоснование проектных решений по информационному обеспече-
нию
Для решения поставленной задачи необходимо спроектировать информаци-
онное хранилище, содержащее информацию следующего рода:
1. Исходная информация:
- Информация об обучающихся (безработных): ФИО, адрес, опыт работы,
имеющиеся компьютерные навыки, пожелания к будущей профессии. Берется из
направления на обучение.
- Информация о преподавателях: ФИО, степень/звание, основное место ра-
боты, специализация, перечень проводимых курсов, требования к времени прове-
дения курсов. Берется из личной карточки преподавателя.
- Информация о проводимых курсах: название, количество часов, требования
к слушателям (обучающимся), наличие рабочей программы, требуемые программ-
ные продукты. Берется из рабочей программы курса.
2. Результирующая информация:
- Информация о результатах ведения курса: перечень прошедших и не про-
шедших итоговую аттестацию.
- Информация о ходе проведения курса: даты и время занятий, посещение
занятий. Данная информация оформляется соответствующими документами.
Информация должна быть объединена в единую информационную базу с
поддержкой целостности данных.
1.4.2 Обоснование проектных решений по программному обеспечению
Реализация программного обеспечения проекта выполняется на платформе
«1С:Предприятие 8.3». Это обусловлено следующими факторами:
• в учреждении уже используется система «1С:Предприятие 8.3» для ре-
шения финансово-хозяйственных задач, а следовательно, не потребуется дополни-
тельных затрат на приобретение средства программирования;
37
• поскольку в учреждении используется система «1С:Предприятие 8.3», то
в перспективе возможна интеграция разрабатываемой системы с учетной програм-
мой без дополнительных затрат на создание системы интеграции;
• разработанный в системе «1С:Предприятие 8.3» программный продукт
легко масштабируется, дорабатывается, модифицируется без дополнительных за-
трат;
• в системе «1С:Предприятие 8.3» достаточно легко выполнять операции
администрирования, решать вопросы обработки транзакций, разграничения прав
пользователей и интеграции с программными продуктами, входящими в состав
Microsoft Office, поскольку все эти вопросы платформа берет на себя. Поэтому для
решения задачи достаточно реализации бизнес-логики приложения, не тратя время
на решения технических вопросов.
Таким образом, выбор для реализации системы на платформе
«1С:Предприятие 8.3» обоснован.
1С предприятие поддерживает 5 видов СУБД:
файловый вариант самого 1С;
IBM DB2;
MS SQL;
Oracle BD;
PostgreSQL.
Каждая из этих СУБД имеет ограничения при работе с 1С: в СУБД
PostgreSQL сильно уменьшается производительность в режиме интенсивной рабо-
ты, система как можно чаще требуется реиндексирование; DB2 чувствительная к
регистру строковых значений при сравнении, а также в ней существенно снижается
производительность от использования подзапросов в условии соединения; на рабо-
ту СУБД Oracle DB очень сильное влияние оказывает статистика планов запроса
1C. Наименьшее число ограничений накладывается на использование MS SQL, по-
этому для реализации системы будет использоваться именно она.
В качестве языка программирования выбирается встроенный язык 1С как
наиболее понятный и наилучшим образом использующий объекты конфигурации
1С.
38
1.4.3 Обоснование проектных решений по техническому обеспечению
Поскольку разрабатываемая система будет реализована в системе
«1С:Предприятие 8.3», необходимо, чтобы техническое обеспечение удовлетворя-
ло следующим требованиям:
32-разрядный сервер 1С:Предприятия:
Процессор Intel Pentium IV/Xeon 2,4 ГГц и выше
Оперативная память 1024 Мб и выше
Жесткий диск 40Гб и выше
Устройство чтения компакт-дисков
USB-порт
SVGA-видеокарта
64-разрядный сервер 1С:Предприятия:
Процессор с архитектурой x86-64 (Intel с поддержкой EM64T, AMD с
поддержкой AMD64).
Оперативная память 2048 Мб и выше
Жесткий диск 40Гб и выше
Устройство чтения компакт-дисков
USB-порт
SVGA-видеокарта
Сервер баз данных:
Технические характеристики компьютера и операционная система долж-
ны соответствовать требованием Microsoft SQL Server, PostgreSQL, IBM DB2,
Oracle Database.
Клиентское приложение - это программа, работающая на компьютере поль-
зователя и обеспечивающая интерактивное взаимодействие системы
1С:Предприятие 8 с пользователем, в отличие от других компонент системы (про-
грамм и рабочих процессов), предназначенных исключительно для программного
взаимодействия с другими частями системы или с другими программными объек-
тами.
В системе 1С:Предприятие 8 существует 3 клиентских приложения:
1) Толстый клиент, который позволяет реализовывать полные возможности
1С:Предприятия 8.3 в плане исполнения прикладного кода. Однако он не поддер-
39
живает работу с информационными базами через интернет, требует предваритель-
ной установки на компьютер пользователя и имеет довольно внушительный объем
дистрибутива. Требования к толстому клиенту:
Процессор Intel Pentium Celeron 2400 Мгц и выше
Оперативная память 1024 Мб и выше
Жесткий диск 40Гб и выше
Устройство чтения компакт-дисков
USB-порт
SVGA-видеокарта
2) Тонкий клиент может работать с информационными базами через интер-
нет. Он также требует предварительной установки на компьютер пользователя, но
имеет значительно меньший размер дистрибутива, чем толстый клиент. Системные
требования:
Процессор Intel Pentium Celeron 1800 Мгц и выше
Оперативная память 256 Мб и выше
Жесткий диск 40Гб и выше
Устройство чтения компакт-дисков
USB-порт
SVGA-видеокарта
Веб-клиент не требует какой-либо предварительной установки на компью-
тер. В отличие от толстого и тонкого клиентов, он исполняется не в среде операци-
онной системы компьютера, а в среде интернет-браузера. Поэтому пользователю
достаточно всего лишь запустить свой браузер, ввести адрес веб-сервера, на кото-
ром опубликована информационная база – и веб-клиент «сам приедет» к нему на
компьютер и начнет исполняться. Требования к веб-клиенту:
Процессор Intel Pentium Celeron 1800 Мгц и выше
Оперативная память 256 Мб и выше
Жесткий диск 40Гб и выше
Устройство чтения компакт-дисков
SVGA-видеокарта
Компьютеры должны быть укомплектованы мышью, клавиатурой, сетевыми
шнурами.
40
Компьютер должен предоставляться для сертификации в той программно-
аппаратной конфигурации, в которой он будет поставляться потребителю [16].
Вместе с компьютером должен поставляться комплект необходимых драйве-
ров под соответствующие операционные системы.
Конфигурация компьютера должна соответствовать спецификации
(Hardware Compatibility List) для используемых операционных систем.
Разрабатываемая система должна использоваться одним пользователем (ме-
неджер компьютерных курсов). Однако для интеграции данной системы с другими
системами предприятия желательно использовать выделенный сервер баз данных и
толстого клиента 1С.
Существующая техническая архитектура предприятия полностью удовле-
творяет заявленным требованиям.
41
II ПРОЕКТНАЯ ЧАСТЬ
2.1 Разработка проекта автоматизации
2.1.1 Этапы жизненного цикла проекта автоматизации
Для создания модели жизненного цикла используются различные стандарты.
Стандарт ГОСТ Р ИСО/МЭК 15288—2005 устанавливает общие основы для
описания жизненного цикла систем, созданных людьми, определяет детально
структурированные процессы и соответствующую терминологию. В стандарте
представлены также процессы, которые поддерживают определение, контроль и
совершенствование процессов жизненного цикла внутри организации или в рамках
какого-либо проекта. Организации и проекты могут применять эти процессы при
приобретении и поставке систем. Стандарт применим к полному жизненному цик-
лу системы, включая замысел, разработку, производство, эксплуатацию и снятие с
эксплуатации, а также приобретение и поставку систем, осуществляемых внутри
или вне организации. Процессы жизненного цикла, представленные в стандарте,
могут применяться однократно, многократно и рекурсивно по отношению к систе-
ме и ее элементам.
Стандарт ГОСТ Р ИСО/МЭК 12207-99 охватывает жизненный цикл про-
граммных средств от концепции замыслов через определение и объединение про-
цессов для заказа и поставки программных продуктов и услуг. Стандарт устанав-
ливает, используя четко определенную терминологию, общую структуру процессов
жизненного цикла программных средств, на которую можно ориентироваться в
программной индустрии. Стандарт определяет процессы, работы и задачи, которые
используются: при приобретении системы, содержащей программные средства,
или отдельно поставляемого программного продукта; при оказании программной
услуги, а также при поставке, разработке, эксплуатации и сопровождении про-
граммных продуктов.
Жизненный цикл процесса создания АСУ согласно ГОСТ 34 включает сле-
дующие стадии: Формирование требований к АС, разработка концепции АС, тех-
ническое задание, эскизный проект, технический проект, рабочая документация,
ввод в действие, сопровождение АС. Процесс создания АС представляет собой со-
вокупность упорядоченных во времени, взаимосвязанных, объединённых в стадии
и этапы работ, выполнение которых необходимо и достаточно для создания АС,
42
соответствующей заданным требованиям. Стадии и этапы создания АС выделяют-
ся как части процесса создания по соображениям рационального планирования и
организации работ, заканчивающихся заданным результатом. Работы по развитию
АС осуществляют по стадиям и этапам, применяемым для создания АС.
Microsoft Solutions Framework (MSF) — методология разработки программ-
ного обеспечения, предложенная корпорацией Microsoft. Модель проектной груп-
пы MSF описывает подход Майкрософт к организации работающего над проектом
персонала и его деятельности в целях максимизации успешности проекта. Данная
модель определяет ролевые кластеры, их области компетенции и зоны ответствен-
ности, а также рекомендации членам проектной группы, позволяющие им успешно
осуществить свою миссию по воплощению проекта в жизнь. В соответствии с мо-
делью MSF проектные группы строятся как небольшие многопрофильные коман-
ды, члены которых распределяют между собой ответственность и дополняют обла-
сти компетенций друг друга. В проектную группу входят такие ролевые кластеры:
управление программой, управление продуктом, разработка, тестирование, управ-
ление релизом, удовлетворение потребителя. Модель процессов включает такие
основные фазы процесса разработки: Выработка концепции, планирование, разра-
ботка, стабилизация, внедрение.
Rational Unified Process (RUP) — методология разработки программного
обеспечения, созданная компанией Rational Software. RUP использует итеративную
модель разработки. В конце каждой итерации проектная команда должна достичь
запланированных на данную итерацию целей, создать или доработать проектные
артефакты и получить промежуточную, но функциональную версию конечного
продукта. Итеративная разработка позволяет быстро реагировать на меняющиеся
требования, обнаруживать и устранять риски на ранних стадиях проекта, а также
эффективно контролировать качество создаваемого продукта. Полный жизненный
цикл разработки продукта состоит из четырех фаз, каждая из которых включает в
себя одну или несколько итераций: начало (формируются видение и границы про-
екта, создается экономическое обоснование), уточнение (документирование требо-
ваний, спроектированная, реализованная и оттестированная исполняемую архи-
тектура), построение (реализация большей части функциональности продукта,