47
необходимо наличие соответствующей СУБД.
MySQL — свободная реляционная система управления базами данных.
Широко применяется в различных системах – в корпоративных системах,
ERP/CRM-приложениях, Live-support systems (хэлп центры, чаты), очень
распространён в вебе – cms, форумы (тот же 1С-Битрикс поддерживает работу с
MySQL).
MySQL портирована на большое количество платформ: AIX, BSDi,
FreeBSD, HP-UX, Linux, Mac OS X, NetBSD, OpenBSD, OS/2 Warp, SGI IRIX,
Solaris, SunOS, SCO OpenServer, UnixWare, Tru64, Windows 95, Windows 98,
Windows NT, Windows 2000, Windows XP, Windows Server 2003, WinCE,
Windows Vista и Windows 7. Существует также порт MySQL к OpenVMS. Важно
отметить, что на официальном сайте СУБД для свободной загрузки
предоставляются не только исходные коды, но и откомпилированные и
оптимизированные под конкретные операционные системы готовые
исполняемые модули СУБД MySQL.
Разработка представляет собой внешнюю обработку для 1С: Предприятие
8.3 и позволяет просматривать структуру баз данных под управлением MySQL,
просматривать таблицы, выполнять произвольные запросы.
Также необходимо дать удаленному пользователю который
подсоединяется к базе, права на чтение, запись, изменение данных на
компьютере, который будет хранить базу данных.
Для реализации информационной системы для АО "АФЕС" была выбрана
среда разработки 1С Предприятие 8.3 [17].
1С Предприятие 8.3 – это программный продукт компании 1С,
предназначенный для автоматизации деятельности на предприятиях
всевозможной направленности. Изначально продукт 1С: Предприятие был
предназначен для автоматизации бухгалтерского и управленческого учета. Но
сегодня этот продукт находит свое применение в областях, далеких от
актуальных бухгалтерских задач. «1С: Предприятие» является (одновременно)
технологической платформой и режимом работы пользователя. Технологическая
платформа предоставляет объекты (данные и метаданные) и механизмы
управления объектами. Набор объектов (данные и метаданные), а также ссылки
48
между ними, установленные программистом, являются конфигурацией. При
автоматизации любого действия компилируется его собственная конфигурация
объектов и соединений между ними, устанавливаемая программно, что является
законченным прикладным решением. Конфигурация создается в специальном
режиме работы программного продукта под названием «Конфигуратор», и
параллельно с созданием этой конфигурации можно сразу проверить ее
производительность в режиме «1С: Предприятие», выполняя отладку.
Пользователи работают исключительно в режиме «1С: Предприятие», в котором
они получают доступ ко всем функциям (в соответствии с правами каждого
конкретного пользователя), реализованным в этом прикладном решении
(конфигурации).
1.4.3. Обоснование проектных решений по техническому обеспечению
Техническое обеспечение - комплекс технических средств,
предназначенных для работы информационной системы, а также
соответствующая документация на эти средства и технологические процессы.
Для установки толстого клиента компьютер конечного пользователя
должен удовлетворять требованиям [11]:
операционная система Windows XP Service Pack 2 и выше, Windows
Server 2003 и выше, Ubuntu 12.04 LTS и выше, Alt Linux СПТ 6.0 и выше;
процессор Intel Pentium/Celeron 1800 МГц и выше;
оперативная память 1 Гбайт и выше;
жесткий диск (при установке используется около 300 Мбайт);
SVGA-дисплей.
Если данный компьютер будет использоваться для разработки
конфигураций, тогда он должен отвечать следующим требованиям:
операционная система Windows XP Service Pack 2 и выше, Windows
Server 2003 и выше,Ubuntu 12.04 LTS и выше, Alt Linux СПТ 6.0 и выше;
процессор Intel Pentium/Celeron 2400 МГц и выше;
оперативная память 2 Гбайт и выше (рекомендуется 4 Гбайт);
жесткий диск (при установке используется около 300 Мбайт);
SVGA-дисплей.
49
II Проектная часть
2.1. Разработка проекта автоматизации
2.1.1. Этапы жизненного цикла проекта автоматизации
Программное обеспечение жизненного цикла (ЖЦ) (ПО) представляет
собой непрерывный процесс, начиная с момента принятия решения о создании и
заканчивая по завершении его работы. Базовым стандартом, который
определяет стратегию и общий порядок в создании и эксплуатации ПО, является
ISO/IEC 12207 - стандарт на процессы и организацию жизненного цикла.
Распространяется на все виды заказного ПО.
Под моделью ЖЦ ПО понимается как структура, определяющая
последовательность выполнения и взаимосвязь процессов, действий и задач на
всем протяжении ЖЦ. Наиболее широко используемые модели - каскадные,
промежуточные и спиральные.
Структура ЖЦ ПО согласно ISO / IEC 12207 основана на трех группах
процессов:
1. Основные процессы программного обеспечения (приобретение,
поставка, разработка, эксплуатация, обслуживание).
2. Поддержка процессов, обеспечивающих реализацию основных
процессов (документация, управление конфигурацией, обеспечение качества,
проверка, сертификация, оценка, аудит, решение проблем).
3. Организационные процессы (управление проектом, развитие
Основные процессы для разработки программного обеспечения в
соответствии с заданными требованиями:
1. Процесс приобретения. Результатом данного процесса являются
технико-экономические обоснование внедрения, техническое задание.
2. Процесс поставки. Результатом данного процесса являются: договор на
поставку, установленная ИС и документация.
3. Процесс разработки. Результатом данного процесса являются:
используемая модель ЖЦ, состав подсистем, компоненты оборудования,
спецификации требования к компонентам ПО, состав компонент ПО,
интерфейсы БД.
4. Процесс функционирования.
50
5. Процесс сопровождения.
Каскадная модель предполагает строго последовательную реализацию
представленных этапов жизненного цикла. Преимущества модели:
формирование на каждом этапе полного комплекта документации и умение
планировать сроки завершения и связанные с этим расходы. Недостаток:
несоблюдение фактического процесса разработки программного обеспечения,
который обычно не укладывается в жесткую схему и требует возврата к
предыдущим этапам до выяснения или пересмотра решений.
Модель с промежуточным управлением приближает жизненный цикл к
реальному процессу создания и применения программного обеспечения. В
отличие от каскадной модели, она позволяет каждому этапу жизненного цикла
вернуться к любому предыдущему этапу, чтобы выполнить пошаговую
настройку. Это обеспечивает большую надежность ПО, но в то же время
увеличивает продолжительность периода разработки.
Модель спирального жизненного цикла (рисунок 2.1) устраняет
недостатки предыдущих моделей. Основное внимание уделяется начальным
этапам: анализу и проектированию. На них осуществимость технических
решений проверяется путем создания опытных образцов.
Рис. 2.1. Спиральная модель жизненного цикла ИС
Благодаря спиральной схеме развития, неполное завершение работ на
51
следующем этапе позволяет перейти к следующему этапу. Незавершенная
работа может быть выполнена на следующем витке спирали. Таким образом,
можно представить пользователям системы некоторую работоспособную
версию, чтобы уточнить требования.
Целью выпускной квалификационной работы является разработка
системы автоматизации учета полисов ипотечного страхования для АО
«АФЕС». Из-за высокой сложности разработки будет использоваться модель
спирального жизненного цикла.
В спиральной модели на начальных этапах жизненного цикла
разрабатывается стратегия автоматизации процессов обработки информации,
определяются и анализируются общие требования к разрабатываемой системе,
изучаются направления и интенсивность информационных потоков, общие
затраты. и сроки развития ИС оцениваются. Далее основные функциональные
области и блоки и их интерфейс идентифицируются и проектируются, на основе
чего существующие прототипы разрабатываются и тестируются на этапе
внедрения. Интеграция функционально-ориентированных моделей позволяет
получить предварительный рабочий вариант решения, аналитическая оценка
которого дает возможность проверить обоснованность выбора и
целесообразность технико-экономических решений.
Следующий раунд спирали уточняет и детализирует требования к ИС,
более детальный дизайн и реализацию функциональных возможностей
обработки информации, что позволяет создавать и оценивать более
совершенные прототипы ИС.
В будущем процесс повторяется циклически по мере необходимости для
уточнения требований, расширения процедур обработки информации и
приведения версии проекта к согласованному решению технического задания.
Обеспечивая более высокую эффективность и окончательную
выполнимость разработанных проектов, спиральная модель также выявила
недостатки, в первую очередь связанные с большим количеством возвратов к
ранее пройденным этапам из-за постоянных уточнений и изменений требований
ИС:
усложнение управления проектами;
52
проблемы гармонизации отношений и управления данными между
различными частями проекта;
трудности контроля и управления временем разработки;
трудности в определении времени окончательного завершения
этапа перехода к следующему этапу;
необходимость постоянного контакта заказчика с разработчиками с
целью системного анализа и оценки новых решений.
Несмотря на эти недостатки, преимущества спиральной модели
превалировали, поэтому в течение многих лет эта модель использовалась,
претерпевая доработки и модификации.
В 1988 году известный американский ученый и практик Барри В. Бём
предложил новую интерпретацию спиральной модели, связав ее с рисками,
влияющими на организацию жизненного цикла (рис. 2.2). Исследователь
определил и упорядочил десять наиболее распространенных рисков по
приоритетам, отметив, что большинство из них связаны с организационными и
процессными аспектами взаимодействия специалистов в команде проекта:
нехватка квалифицированных специалистов;
нереальные сроки и бюджет;
реализация проекта, не соответствующая запланированным
решениям;
разработка неудобного, неинформативного пользовательского
интерфейса;
«золотой сервировкой» - перфекционизм, чрезмерная оптимизация
и оттачивание принципиально несущественных деталей компонентов проекта;
постоянный поток изменений в проекте;
отсутствие информации о внешних компонентах, которые
определяют среду системы или участвуют в интеграции;
недостатки в работе, выполняемой внешними ресурсами по
отношению к проекту;
недостаточная производительность созданной системы;
«разрывом в квалификации специалистов в разных областях знаний,
задействованных в проекте.
53
Рис. 2.2. Модифицированная спиральная модель жизненного цикла ИС (по
Б. Боэму)
В модифицированной модели Боэма на этапе планирования проекта и его
жизненного цикла определяются цели, альтернативы и ограничения, связанные с
разработкой или приобретением ИС, оцениваются стоимость и сроки этих задач.
Проводится аналитическое сравнение альтернативных решений, исследуются
риски, выбирается более предпочтительный вариант и формируется первое
приближение прототипа ИС, для которого оценивается производительность и
моделируется концепция работы.
После уточнения и согласования требований к ИС планируются
дальнейшие меры в соответствии с функциональным наполнением системы.
Проводится оценка, анализируются и проверяются альтернативы, выявляются и
устраняются возможные риски, разрабатывается второе приближение прототипа,
оценивается сто эксплуатационных характеристик, определяются спецификации
требований ИС.
Планируется дальнейшее развитие функциональных подсистем. При
необходимости рассматриваются индивидуальные проектные решения.
54
Разработаны и внедрены соответствующие прототипы, выполнен дизайн-проект.
Проводится тестирование и интеграция разработанных решений, а также их
оценка заказчиком.
В дальнейшем итерационный процесс продолжается. Устраняет
несоответствие разработки проекта и документации, уточнение процедур
обработки данных, завершается проектирование пользовательского интерфейса.
Комплексное тестирование ИС, уточненная техническая документация. При
отсутствии возражений со стороны заказчика, а также функционального
соответствия проекта требованиям технического задания, интеллектуальная
собственность передается пилотной, а затем коммерческой эксплуатации; в
противном случае разработка ИС продолжается.
Таким образом, суммируя вышесказанное, в спиральной модели
жизненного цикла мы можем условно выделить четыре этапа, циклически
повторяющиеся на более высоких уровнях.
1. Планирование - формирование текущих целей проекта в соответствии с
выбранной стратегией его создания, определение вариантов их реализации с
учетом текущих ограничений.
2. Анализ рисков - изучение возможностей реализации текущих решений
по установленным вариантам и оценка рисков для каждого из них.
3. Дизайн - реализация текущих решений для создания проекта с
использованием выбранной (наименее рискованной) опции.
4. Оценка - оценка клиентом текущего состояния проекта.
Во время каждой итерации оцениваются:
риск превышения сроков и стоимости разработки;
необходимость продолжения итеративного процесса разработки
проекта;
степень полноты, точности и однозначности в понимании
системных требований;
целесообразность продолжения или завершения проекта.
С каждой итерацией спирали все больше и больше совершенных проектов
создаются ИС. Моделирование на каждом повороте снижает риски прикладных
решений.
55
2.1.2 Ожидаемые риски на этапах жизненного цикла и их описание
Стандарт MSF дает определенную гарантию минимизации рисков, так как
весь проект разделен на этапы, на каждом этапе есть роли, которые назначаются
для достижения целей, и все же на каждом этапе есть некоторые риски:
На этапе разработки концепции могут возникнуть следующие риски:
1. Недальновидный анализ сроков и бюджета проекта.
Чтобы устранить этот вид риска, необходимо более детально проработать
задачи и цели проекта, установить больше контрольных точек.
2. Неправильно подобранные сотрудники проекта могут привести к
полному отсутствию командной работы
Этот риск снижается благодаря более тщательному отбору специалистов в
проектной команде путем проверки не только профессиональных навыков, но и
личных качеств.
На этапе планирования риски могут возникать из-за неправильной или
неправильно сформированной архитектуры выбранного решения.
Возможность этого риска зависит от компетенции руководителя проекта,
который принимает решение выбрать архитектуру разрабатываемого решения
На этапе разработки возможны следующие риски:
1. Неправильная интерпретация спецификации и как следствие
неправильное программирование архитектуры и смещение сроков.
Минимизация этого риска - более ясное написание технических
спецификаций, понятных программисту
2. Другим важным риском в этом проекте является отсутствие
надлежащей квалификации программиста на языке, на котором решено
реализовать клиентскую программу, которая будет распределять приложения
между инженерами.
Если программист не укладывается в указанные сроки графика проекта,
используйте стороннего разработчика, так называемый «аутсорсинг» или
«внештатный сотрудник».
На этапе тестирования может существовать риск неполного тестирования.
Может случиться так, что программный продукт не будет полностью
протестирован. Это решается повторным тестированием на следующей итерации
56
разработки.
На этапе реализации может возникнуть риск принятия неверного решения
о полноте части проекта. Появление этих рисков приводит к проблеме неполных
решений и возможности несоответствий с другими частями разрабатываемой
ИС.
2.1.3. Организационно-правовые и программно-аппаратные средства
обеспечения информационной безопасности и защиты информации
Реализация организационных и технических мер поможет сформировать
политику информационной безопасности и создать структуру службы
информационной безопасности, адаптированную к потребностям каждого
конкретного банка. Также эти меры позволяют внедрять законные технические
решения. В качестве основы для разработки законных решений предлагается
использовать разработку реестра рекомендуемых аппаратных и программных
средств защиты информации, методических указаний по выбору и построению
системы защиты информации.
Меры, направленные на детальное регулирование деятельности
персонала, основаны на алгоритмах действий персонала для безопасного
обращения с информацией.
Правовые меры, направленные на предотвращение несанкционированных
действий с информацией, позволяют построить систему постоянного
внутреннего мониторинга системы информационной безопасности Банка.
Меры по созданию условий для страхования информационных рисков
основаны на выборе унифицированных решений, направленных на
минимизацию рисков.
При использовании любого программного продукта необходимо
придерживаться нескольких основных правил, а именно:
использовать только лицензионное программное обеспечение;
следить за выпуском обновлений программного обеспечения и
своевременно их устанавливать;
устанавливайте только проверенное программное обеспечение,
приобретенное у авторизованных поставщиков.
Для обеспечения информационной безопасности и защиты информации