44
Корпус MidiTower / PSU 665W(1);
Процессор Intel® C612 / 1х CPU Intel Xeon E5-2620 v4, 2.1-3.0 GHz,
8core/16T upto 2 CPU max;
ОЗУ 32Gb (2*16Gb) DDR4 2133MHz ECC REG upto 512Gb 8xDIMM;
HDD 2x 300Gb, SAS3, 12Gb/s, 10K, 24x7 + HDD 2x 2000Gb, SATA3,
6Gb/s, 7.2K, 24x7 upto 4x3.5/2.5" HP;
DVD-RW 1xPCI-E 3.0 x16, 5xPCI-E 3.0 x8;
Видеокарта: 2x1GbE(Intel® i210);
Блок питания: Reset, Power, Unit ID.
Анализируя перечень аппаратного обеспечения, что применяется в ООО
«НПО Мидасот», можно сделать вывод, что они соответствуют в полной мере
всем поставленным целям автоматизации процесса приема платежей.
45
II ПРОЕКТНАЯ ЧАСТЬ
2.1.Разработка проекта автоматизации
2.1.1.Этапы жизненного цикла проекта автоматизации
Модель жизненного цикла ПО – это структура, содержащая разные
процессы действия, а также и задачи, которые часто осуществляются в ходе
процесса разработки, использования или сопровождения программного продукта.
Такие модели можно разделять на 3 главных группы:
– с учетом специфики задач;
– инженерный подход;
– современные технологии для быстрой разработки.
Рассмотрим существующие непосредственно модели (подклассы) и также
оценим их недостатки и преимущества.
Модель устранения и кодирования ошибок – это совершенно простая
модель, которая характерна для студентов.
По этой модели именно большинство студентов разрабатывают самые
простые проекты.
Данная модель имеет такой алгоритм:[3]
– остановка задачи;
– выполнение задачи;
– проверка результата задачи;
– при необходимости возврат к первому пункту.
На рисунке 23 рассмотрена структурная схема терминологии, что связанная
с определением ЖЦ ПО.
Стоит также заметить, что каждый ЖЦ является только одним с базовых
терминов по теории проектирования для современных программных продуктов
[12].
Основным нормативным положением, что выполняет регламентацию
разработки жизненного цикла, считают сертифицированный международный
стандарт с разработки ISO 122207 Информационная технология. Системная и
программная инженерия. Процессы жизненного цикла программных средств.
46
Рисунок 23. Типовая структура понятий для ЖЦ
Он выполняет определение типичной (традиционной) схемы ЖЦ, которая
также использует, задачи, разнообразные действия, которые надо во время
проектирования ПС выполнять.
Сама структура указанного цикла основана по уже действующему
стандарту ISO 12207 с группами (рисунок 24): [13]
– вспомогательные;
– основные (главные);
– организационные.
Рисунок 24. Типовая структура ЖЦ
Структура
жизненного
цикла
Основная группа
Вспомоготельная
группа
Организационная
группа
47
Все основные группы процессов по ЖЦ в себя включают перечень
определенных действий, что связаны с задачами, которые всегда должны быть
выполнены при выполнении ЖЦ. [1]
Процесс приобретения в большинстве случаев охватывает действия
заказчиков на приобретение непосредственно программного продукта.
По таким действиям относят:[8]
Подготовка выходных предложений – это процесс разработки и
составление самых первичных предложений, которые должны удовлетворять
требованиям непосредственно к разрабатываемой системе; а также множество
необходимых подпрограмм и программных средств; разные условия или
соглашения.
Подготовка, корректировка имеющихся договоров реализует такие
основные задачи:
– выбор самого лучшего предложения;
– выбор разработчиков;
– заключение контракта с разработчиками;
– выполнение изменений для договора по реализации ПС на основании
требований клиентов.
– надзор за работой поставщика также осуществляется с помощью
действий аудита;
– определенное приобретения может подразумевать также много
задач: определение клиентом практически всех потребностей при разработке ПС.
Окончание разного рода работ по проектированию ПС
На окончательном этапе подготавливаются разнообразные виды
окончательных тестов.
Завершение работ может также осуществляться в случае их удовлетворения
абсолютно всем условиям с технического задания.
Поставка ПС охватывает также разные действия с требованиями
поставщиков при получении готового ПС. [2]
Непосредственно процессы по разработке охватывают самые различные
используемые действия, а также и задачи для разработчиков:[5]
48
Создание ПО и его компонентов с помощью ранее описанных требований,
при этом включая непосредственное оформление промежуточной и результатной
документации;
Подготовка различных материалов, что являются обязательными при
проверке ПС;
Подготовка самых различных материалов, что используются для
организации у клиентов поднятия квалификационного уровня для работы с ПО.
Процесс эксплуатации охватывает все предусмотренные ранее действия и
другие задания оператора, что занимаются непосредственной работой с ПО.
К таким действиям часто относят: [9]
– эксплуатационное тестирование ПО;
– подготовительная работа с ПО;
– эксплуатация непосредственно ПО;
– поддержка ПО.
Процесс сопровождения также активизируется часто при выполнении
изменений ПС, соответствующей документации, что были вызваны некоторыми
уже возникшими проблемами.
Основными целями для таких процессов часто бывает проектирование
надежного, удовлетворяющего всем требованиям заказчика ПС непосредственно
в сроки договора.
Каскадная модель ЖЦ ПО (водопадная модель) имеет алгоритм,
приведенный на рисунке 25, имеет ряд преимуществ перед описанным
алгоритмом в предыдущей модели, но имеет также и ряд недостатков.
Основные преимущества модели:
– последовательное выполнение этапов разработки проекта в строгом
порядке;
– позволяет оценить качество продукта для каждого этапа.
Недостатками являются следующие факты:
– отсутствие обратных связей с этапами;
– нет соответствия реальным условиям для разработки программного
продукта.
49
Рисунок 25. Водопадная модель ЖЦ
Стоит отметить, что для устранения недостатков часто применяется
каскадная модель с так называемым промежуточным контролем (водоворотная
модель). Она является почти эквивалентной алгоритму предыдущей модели, но
при этом имеет также обратную связь с каждым этапом ЖЦ, порождая при этом
очень весомый недостаток, а именно 10-ти кратное увеличение разных затрат на
разработку проекта.
V-модель или разработка с применением тестирования имеет более
приближенный для современных методов алгоритм, но все еще имеет перечень
недостатков.
Является также одной из главных практик экстремального
программирования (рисунок 26).
50
Рисунок 26. V-модель
Модель на базе разработки прототипа – основывается на разработке
прототипов, а также прототипирования продукта.
Процесс прототипирования используется на самых ранних стадиях ЖЦ
программного обеспечения:[3]
– прояснить все не ясные требования к разработке (прототип UI);
– выбрать одно с ряда концептуальных решений;
– проанализировать осуществимость проекта.
Рассмотрим классификацию прототипов:
– вертикальные и горизонтальные;
– одноразовые и эволюционные;
– раскадровки и бумажные.
Горизонтальные прототипы дают возможность моделировать
исключительно UI вовсе не затрагивая логику для обработки и непосредственно
базу данных.
Вертикальные прототипы – это проверка архитектурных решений для
разработки.
51
Одноразовые прототипы применяются для быстрой разработки (RAD).
Эволюционные прототипы применяется в качестве первого приближения
эволюционной системы.
Спиральная модель ЖЦ ПО представляет собой процесс для разработки
ПО, сочетающий в себе и проектирование, и постадийное прототипирование для
сочетания преимуществ нисходящей и концепции (рисунок 27):
Рисунок 27. Схема спиральной модели
Преимущества данной модели в следующем:
– быстрое получение результатов;
52
– увеличение конкурентоспособности;
– гибкости при изменении требований.
Недостаток (более или менее существенный) один – отсутствие
регламентации стадий модели.
В результате выполненного рассмотрения моделей жизненного цикла
создания ПО можно сделать вывод, что для автоматизации управления
поставками наиболее целесообразно применять каскадную модель.
Внедрение систем – это комплекс специфических задач, выполнение
которых позволяет добиться реальной эксплуатации решения в организации.
Процесс внедрения состоит из:
– подготовительных работ технического и административного плана;
– тестовой (опытной) эксплуатации;
– промышленной эксплуатации.
При крупных внедрениях выделяют 3 уровня организации проекта
внедрения:
– управляющая команда (руководство);
– рабочая команда (предметные специалисты);
– внедренцы (исполнители).
Есть 3 способа начала использования новой системы:
– Параллельная стратегия – для случая, когда старую работающую
систему необходимо заменить новой.
– Скачок означает, что прежняя система работала еще в пятницу, а в
понедельник начала работать по новой системе. Если данные не столь точные, как
хотелось бы, если люди не обучены, тогда есть риск ввергнуться в хаос, сорвать
поставки и финансовые расчеты.
– Опытная эксплуатация пилотного проекта – это тактика скачка, но
применяемая к ограниченному числу изделий. Область применения стратегии –
малый участок деятельности. Такой подход наиболее надежен, он снижает риск,
и сегодня практически все фирмы применяют эту тактику.
– Узкое место – это наиболее критичная малая часть
производственного процесса. При внедрении узкого места план внедрения
выполняется только для узкого места и для людей, работающих в нем.
53
При стратегии узкого места объем работ уменьшается значительно, и при
заданных ресурсах узкое место может быть завершено в более короткие сроки,
чем внедрение во всей фирме.
Свойство этой стратегии — сосредоточение на узком месте в
производственном процессе — упрощает внедрение.
Узкое место служит испытательным полигоном для дальнейших работ. Оно
может явиться успешным примером, помогающим внедрению во всей фирме.
В рассматриваемом проекте будет выбрана стратегия внедрения пилотный
проект.
2.1.2. Ожидаемые риски на этапах жизненного цикла и их описание
Основной риск на первом этапе – это недостаточное определение основных
свойств проектируемой ИС, что требуются для решения задачи, а также
неправильный выбор исходных задач проектирования.
Заметим, что это может потребовать на следующих этапах, дополнительной
доработки программы или хранилища данных, что приведет к возрастанию
финансового риска.
Риск можно предотвратить использованием популярных CASE-средств при
построении модели бизнес-процессов. При непосредственном возникновении
риска проводится дополнительный процесс моделирования с использованием
указанных выше CASE-средств.
При определении функций ИС, а также стратегий автоматизации большой
риск вызывает неправильное определение функций системы и стратегии
автоматизации.
Этот риск предотвращается основательным системным анализом всех
имеющихся вариантов. В случае непосредственного возникновения, риск
устраняется реализацией повторного анализа варианта выбора ИС. Риск
взаимосвязан также с риском неправильного определения основных функций ИС,
а также стратегии автоматизации. Этот риск устраняется и предотвращается
использование CASE-средств.