47
параллельных и многопользовательских функций, а также обмена данными
между рабочими станциями.
Выбор системы управления БД для хранения информации
представляет многопараметрическую задачу, а также является одним с
важнейших этапов при выполнении процесса разработки приложения.
Выбранный тип ПО должен удовлетворять всем будущим, так и
нынешним потребностям отдела техподдержки, а также следует учти
самые разнообразные финансовые затраты, так как оче нь часто
руководство стоит перед выбором:
– получить полностью рабочий продукт за большую стоимость, а
ее поддержка бу дет выполняться за символическую цену;
– купить по низкой цене базовую платформу, а ее поддержка и
внедрение будут стоить больших денег.
Кроме этого, надо убедиться, что выбранная СУБД может принести
предприятию реальную выгоду.
В данной работе будет использоваться СУБД SQL Server, поскольку
данная СУБД является одной из самых популярных и
многофункциональных. Стоит от м ет и т ь , что в современно е время
используются так называемые специализированные СУБД (или
платформы) для создания разного рода конфигураций ПО, что позже могут
внедряться в серверную часть.
Непосредственно разработка ПО будет выполняться на основании
платформы 1С: Предприятие 8.3.
1С:Предприятие – это гибкой наст раиваемая система, при
использовании которой можно разрешать широкий спектр задач в
направлении автоматизации деятельности разного рода предприятий.
Основным отличием 1С: Предприятие от иных ERP-систем является
распределение используемых мет аданных с представлением системы
метода управления данными с использованием специа льного языка
обработки хранящихся данных.
48
Специфические алгоритмы, которые присутствуют в конфигурации
описываются в системе с применением программной составляющей
Конфигуратор, что содержат тексты на специальном языке системы.
Система дает возможность решать очень обширный круг задач.
В основе этой системы лежит очень гибкая технологическая
платформа, которой возможности позволяют модифицировать и создавать
самые разнообразные программы.
Такой уровень универсальности достигается, в основном, благодаря
тому, что платформа 1С:Предприятие – не просто программа, что
существует в виде набора постоянных файлов, а множество программных
инструментов работают пользователи и разработчики.
Основным концептуальным решением, что отлич ает систему
1С:Предприятие от других универса льных систем является четкое
распределение ее на 2 составляющие:
– платформу;
– прикладное решение.
1.4.3.Обоснование проектных решений по техническому обеспечению
Под техническим обеспечением (ТО) пон имается следующий набор
аппаратных средств:
– ПК;
– линии связи;
– периферийные устройства;
– сетевое оборудование;
– организационная техника.
Комплекс аппаратных средств имеет такие составляющие:
– компьютер;
– устройства для выполнения сбора, обработки, передачи, а
также вывода на печать данных;
49
– устройства для реализации передачи информации по
локальным и глобальн ым сетям;
– эксплуатационные и монтажные материалы.
При выполнении выбора ПК надо руководствоваться целым радом
характеристик:
К таким характеристикам можно отнести:
– стоимостные затраты;
– надежность;
– простота использования;
– производительность и прочие.
От значения требуемых параметров зависят возможности работы с
уже имеющимися программными средствами, а в результате – и успех
создания автомати зированной системы.
Для каждого с элементов указанной схемы выделяет ся ряд
критериев, которые считаются самыми важными при осуществлении
выбора аппаратного обеспечения:
– разрешение дисплея монитора;
– тактовая частота процессора ПК;
– объем используемой оперативной памяти.
Для обработки документов в электронной форме, а именно, печати,
копирования и сканирования документов, должно использоваться
специализированное оборудование – МФУ. В данном случае руководству
необходимо приобрести МФУ Konica Minolta 1380.
Также, для обеспечения уровня сохранности данных при аварийном
отключени и электропитания ПК должен быть оборудован модулем
бесперебойного питания.
Анализируя уже применяемое в АКБ «Тинькофф Банк» АРМ,
можно в итоге сделать вывод, что они полностью соответствуют
поставленным целям для разработки ИС.
50
II. ПРОЕКТНАЯ ЧАСТЬ
2.1.Разработка проекта автоматизации
2.1.1.Этапы жизненного цикла проекта автоматизации
Жизненный цикл (ЖЦ) в современных автоматизированных ИС
(АИС) – это полностью конт ролируемый непрерывный процесс, что также
может выполняться с с амого момента непосредственного утверждения
надобности для создания АИС и до изъятия ее с эксплуат ации.
Стои т также заметить, вс е ЖЦ являются толь ко одним с
совокупности базовых терминов при рассмотрении теории проектирования
для многих современных АИС [11].
Основным нормативным положением для регламентации
разработки жизненного цикла, считают сертифицированный
международный документ с разработки под названием Международной
организации стандартизации программ.
Каскадная модель часто может характеризоваться разбиением
процесса разработки определенного программного средства сразу на
некоторые этапы, и, стоит отметить, что все их переходы между этими
этапами к следующему будут реализовываться только после завершения
предшествующих (рисунок 13).[3]
51
Рисунок 13 – Структура каскадной модели
Рассмотрим некоторые положител ьные свойства описываемой
модели ЖЦ:
– при реализации каждого этапа этапе создается закон ченный
набор документации;
– все этапы создания АИС, должны быть реализованы строго в
нужной последовательности, тогда они дают возможность спланировать
конкретные сроки.
Рассмат риваемый подход прекрасно зарекомендовал себя при
реализации проектирования АИС самой разной сложности, при которых
можно на начальных этапах разработки АИС практически точн о
выполнить описание всех требований.
Для преодоления проблем, что описаны выше при использовании
каскадной структуры, еще в начале 70-х годов 20 века предложена
спиральная модель построения АИС.
Непосредственная реализация для указанных технических фаз
также выполняется при помощи прототипов (рисунок 14).
52
Рисунок 14 – Структура спиральной модели
При рассмотрении такой структуры рассмат ривался упор на
некоторые исходные этапы описанной выше каскадной модели:[14]
– анализ проблемы построения;
– проектирование АИС.
Прототипы – это действующие модули АИС для реализации всех ее
отдельных функций.
Создание прототипов также может осуще ствляться часто и за
несколько целых итераций, которыми являются воображаемые витки
спирали.
Все такие итерации могут соответствовать также созданию
некоторого эт апа АИС (прототипа), где уточняются новые цели,
характери стик и программного осуществления, а также оценивается
суммарное качество имеющихся результатов.
53
В качестве еще улучшенной структуры ЖЦ можно рассматривать
такую модель, что показана на рисунке 15:
Рисунок 15 – Структура улучшенной спиральной модели АИС
Спиральная модель ЖЦ АИС имеет свои достоинства, например: [8]
– заказчики могут влиять непосредственно на разрабатываемую
для них АИС на всех этапах;
– непосредственно в модели могут воплощаться полностью все
преимущества рассмотренного ЖЦ.
Инкрементная модель ЖЦ АИС является классическим прототипом
для инкрементного поведения при создании ПО.
Стоит отметить тот факт, что в ней объединены также элементы
последовательной модели при использовании итерационной структуры
Боэма для модернизации, приведенной выше каскадной модели.
Каж да я из по следовательно стей может сама проектировать
специальный необходимый инкремент АИС.
54
Самой главной реализацией указанного подхода счи т ают
специальную технологию экстремального программирования, что
ориентировано также на малые приросты в их функциональности.
Рисунок 16 – Структура функционирования для инкрементной
модели
Преимущество указанной модели состоит непосредственно и в том,
что вовсе нет надобности вкладывать самые разные средства уже ранее,
которые выделяются на всю АИС.
В результате проведенного ана лиза ЖЦ можно сделать вывод, что
для создания системы автоматизации приема и анализа заявок технической
поддержки АКБ «Тинькофф Банк», нужно применить каскадную модель.
2.1.2. Ожидаемые риски на этапах жизненного цикла и их описание
Рассмотрим основные риски, которые присутствуют при
использовании ЖЦ (рисунок 17).
55
Рисунок 17 – Риски, ожидаемые при выполнении ЖЦ
Первый риск – недостаточное определение свойств проектируемой
системы автоматизации, может потребовать на последующих этапах,
дополнительной разработки программ или хранилища информации, что
приведет также к возрастанию финансовых рисков, которые связаны с
проектом.
Риск можно предотвратить при применении CASE-средств для
построения модели БП.
Риск под названием «Неправильное определение функций системы»
предотвращается основательным анализом всех используемых вариантов
таких функций. Также можно этот риск устрани ть реализацией повторного
анализа выбора ИС.
Риски, которые кроются разработке некорректного плана-графика
процесса автоматизации, а именно, применение лишних ресурсов, их
недостаточн ость. Этот риск является, в основном, финансовым можно его
Риски, ожидаемые при выполнении ЖЦ
Недостаточное определение основных
свойств проектируемой ИС
Неправильное определение функций
системы
Неправильная разработка плана-
графика создания ПО
Неправильная разработка ПО
Неправильное внедрение и
тестирование ПО
56
предотвратить с применением современных средств про ектирования, а
также устранить повторной корректировкой процесса автоматизации.
Риск в некорректной разработке АИС устраняется при
использовании так называемого модульного тестирования.
Риск при внедрении предотвращается применением современного
лицензионного стендового оборудования, а также может быть устранен
двойным те стированием.
2.1.3.Организационно-правовые и программно-аппаратные средства
обеспечения информационной безопасности и защиты информации
К организационно правовым средствам безопасности информации
можно отнести разграничение уровня до ступа между несколькими
подсистемами (рисунок 19):
Рисунок 19 – Применяемые подсистемы
Подсистема «Руководство» используется для непосредственного
контроля деятельности АКБ «Тинькофф Банк», а также выполнения
анализа основных операций по предоставлению услуг техподдержки.
Подсистема «Техподдержка» применяется для выполнения приема
заявок на предоставление консультационных услуг.
Стоит отметить, что каждая из подсистем имеет доступ только к тем
объектам конфигурации, которые можно указать при разработке.
Подсистемы
Техподдержка
Руководство