22
Создание АРМ под собой предполагает проведение процесса структуризации
и параметризации многих решаемых специалистом заданий на стадии
проектирования.
Особенное место уделяется пакетам для прикладных программ по созданию
автоматизированных ИС, которые могут использовать различное назначение
(рисунок 1.12):
Рисунок 1.12 – Категории пользователей
Пакеты для обработки графической информации позволяют представить в
компактном и максимально наглядном виде процессы и состояние, свойственные
объектам, а также проиллюстрировать результаты выполнения анализа.
Профессиональная ориентация АРМ используется функциональной частью
ПО.
Именно здесь и закладывается ориентация на определенного специалиста,
обеспечивается процесс решение задач для определенной предметной области.
Типы ПО для АРМ
для обработки
таблиц
справочные
ведения массивов
информации
проектирования БД
документальные
23
При разработке функционального ПО большое внимание надо уделять
вопросам организации по взаимодействию «человек-машина».
АРМ обычно основывается на ПК индивидуального или коллективного
использования. [2]
Под технологическим обеспечение АРМ подразумевается процесс
организации технологического процесса применения АРМ применительно к
совокупности решаемых задач, что соответствуют функциям специалиста.
Методическое обеспечение – методические указания, положения и
рекомендации по внедрению и эксплуатации системы, а также выполнении оценки
эффективности ее работы.
Организационное обеспечение в себя включает методы и средства
организации функционирования, развития и совершенствования АРМ, а также
повышения и подготовки квалификации кадров.
Стоит отметить, что для коллективных и групповых АРМ в подсистему
данного обеспечения включаются и функции администрирования АРМ (рисунок
1.13):
Рисунок 1.13 – Категории пользователей
Функции
администрирования АРМ
планирование
анализ
регулирование
учет
контроль
организационные связи и
прочее
24
Организационное обеспечение также предусматривает определение и
оформление обязанностей и прав пользователей АРМ. [8]
Правовое обеспечение включается в систему нормативно-правовой
документации, четко определяющих обязанности и права специалистов в условии
функционирования АРМ, что регламентируют порядок хранения и выполнения
защиты информации, правил ревизии данных, обеспечения юридической
подлинности всех совершаемых операций на АРМ и т.д.
Рассмотрим классификацию АРМ.
С учетом направления применения возможно выполнение классификации
АРМ по функциональным признакам (рисунок 1.14):
Рисунок 1.14 – Классификация АРМ
Крайне важным классификационным признаком для АРМ является его режим
эксплуатации:
– одиночный режимы эксплуатации – каждый АРМ реализуется на
локальном ПК, все ресурсы которого находятся в одном монопольном распоряжении
пользователей.
Классификация АРМ
АРМ административно -
управленческого отдела
АРМ проектировщика АСУ
АРМ специалиста в направлении
экономики, физики, математики, и
других наук
АРМ для производственно-
технологического назначения
25
– при групповом режиме использования на базе одного ПК реализуется
сразу несколько рабочих мест, что объединены по принципу функциональной и
административной общности. В данном случае требуются более мощные ПК и
достаточно сложное ПО.
– сетевой режим эксплуатации объединяет достоинства для первого и
второго.
1.3. Способы разработки АРМ, их структура
Жизненный цикл для разработки ПО начинается непосредственно с стадии
анализа требований к создаваемому продукту, во время которого все участники
процесса разработки (заказчик, программисты, их представители) обсуждают
постановку задачи, предъявляемую к результатному продукту. Цель
рассматриваемой стадии – определение подробных требований к проектируемой
системе.
Кроме того, необходимо убедиться и в том, что участники правильно поняли
все поставленные задачи, а также то, как именно данные требования будут
реализованы на практике.
К главным процессам, которые имеются в ЖЦ относят такие:
– разработку ПС;
– эксплуатацию;
– приобретение ПС;
– поставку;
– сопровождение ПС.
Процесс приобретения в большинстве случаев охватывает действия
заказчиков на приобретение непосредственно программного продукта.
По таким действиям относят:[8]
1. Подготовка выходных предложений – это процесс разработки и
составление самых первичных предложений, которые должны удовлетворять
требованиям непосредственно к разрабатываемой системе; а также множество
необходимых подпрограмм и программных средств; разные условия или
соглашения.
26
2. Подготовка, корректировка имеющихся договоров реализует такие
основные задачи:
– выбор самого лучшего предложения;
– выбор разработчиков;
– заключение контракта с разработчиками;
– выполнение изменений для договора по реализации ПС на основании
требований клиентов.
3. надзор за работой поставщика также осуществляется с помощью
действий аудита;
4. определенное приобретения может подразумевать также много задач:
определение клиентом практически всех потребностей при разработке ПС.
5. Окончание разного рода работ по проектированию ПС
На окончательном этапе подготавливаются разнообразные виды
окончательных тестов.
Завершение работ может также осуществляться в случае их удовлетворения
абсолютно всем условиям с технического задания.
Поставка ПС охватывает также разные действия с требованиями поставщиков
при получении готового ПС. [2]
К таким действиям можно отнести:
Инициирование поставки – это непосредственное рассмотрение поставщиком
своих предложений.
1. Подготовка ответов на предложения по результатам проверки;
2. Подготовка договоров осуществляется после процедуры определения
поставщика;
3. Процесс реализации планирования часто используется также и после
утверждения разных договоров и выполняет задачи:
– принятие решений для поставщиков с точки зрения выполнения самых
различных работ;
– выполнение разработки целевого плана по управлению ПС, что в себе также
содержит организацию проектов, их разграничение ответственности по
интегрированной среде разработки.[17]
27
Субподрядчик (или подрядчик) является организацией или корпорацией
(индивидуум), заключившие договоры по разработке и исполнении работ.[1]
4. Выполнение работы, контроль выполнения.
5. Проверка работоспособности ПО.
6. Доставка ПС, а также завершение некоторых основных работ, что
выполняются строго по условиям, которые оговорены в процессе его
непосредственного подписания, а также при инициировании работами по
реализации приемки работ.
Непосредственно процессы по разработке охватывают самые различные
используемые действия, а также и задачи для разработчиков:[5]
1. Создание ПО и его компонентов с помощью ранее описанных
требований, при этом включая непосредственное оформление промежуточной и
результатной документации;
2. Подготовка различных материалов, что являются обязательными при
проверке ПС;
3. Подготовка самых различных материалов, что используются для
организации у клиентов поднятия квалификационного уровня для работы с ПО.
Процесс эксплуатации охватывает все предусмотренные ранее действия и
другие задания оператора, что занимаются непосредственной работой с ПО.
К таким действиям часто относят: [9]
– эксплуатационное тестирование ПО;
– подготовительная работа с ПО;
– эксплуатация непосредственно ПО;
– поддержка ПО.
Процесс сопровождения также активизируется часто при выполнении
изменений ПС, соответствующей документации, что были вызваны некоторыми уже
возникшими проблемами.
Основными целями для таких процессов часто бывает проектирование
надежного, удовлетворяющего всем требованиям заказчика ПС непосредственно в
сроки договора.
28
Зачастую, при обсуждении участвуют специалисты по выполнению
тестированию, что уже на этапе разработки требований вносят собственные
пожелания, корректируют процесс.
В зависимости выбранной модели разработки, также могут сильно отличаться
подходы непосредственно к определению момента переходов с одного этапа на
другой.
К примеру, в V-модели или каскадной модели стадия анализа требований
постоянно закрепляется в специальном документе – спецификации по требованиям
к ПО, оформление которого закончено до перехода в следующую стадию.
В результате, этот этап под собой предполагает выполнение сбора требований
к создаваемому программному обеспечению, а также их систематизацию, анализ,
документирование, выявление и разрешение появившихся противоречий.
Выбор методик разработки АРМ становится важной задачей в условиях
стремительного возрастания рынка. Согласно исследованию компании Gartner на
ПО для предприятий в 2018 году было по миру затрачено более 310 млрд. долларов.
Разработка методологии RAD (Rapid Application Development) является
основой для создания адаптивной системы разработки ПО, которая была бы
некоторым противовесом для жёсткой «водопадной» модели (рисунок 1.15).
Рисунок 1.15 – Сравнение методов разработки АИС
29
За появление и применение быстрой разработки приложения надо
благодарить неидеальность Waterfall-модели при создании АИС.
То есть, изначально водопадная система для разработки была обоснована на
инженерной традиционной модели, применяемой для проектирования или
возведения зданий.
Если Waterfall использовала за основу жесткую структуру последовательных
этапов по разработке, то применение RAD стало попыткой разработки гибкого
процесса, в рамках которого могут быть использованы знания, что получены на
протяжении жизненного цикла проекта.
Самую первую версию RAD использовал Барри Боэм в 1985 году, который её
назвал «спиральная модель».
При этом, каждый виток спирали может быть разбит на 4 основные сектора и
соответствует так называемой разработке версии или фрагмента ПО. С каждым
витком идёт уточнение и углубление целей, спецификаций проекта. Также, в
результате появляется возможность выбора более обоснованного варианта.
Применив идеи Барри, британец Д. Мартин разработал систему RAD на
протяжении своей работы в компании IBM, и сформулировал окончательно их в
своей книге.
Методология RAD – это процесс разработки ПО, что комбинирует
постадийное прототипирование и проектирование.
Основы (принципы), которые применяются в быстрой разработки
приложений показаны на рисунке 1.16.
Принципы RAD сосредотачиваются на том, чтоб обеспечить основные
преимущества этой методологии.
С последним принципом возникает больше проблем, потому что
разработчики и заказчики видят предмет разработки часто по-разному.
30
Рисунок 1.16 – Принципы использования RAD
Для устранения таких проблем Джеймсом Мартином, а также его
последователями выделены следующие критерии качества RAD:
– цикличность разработки программного продукта;
– минимизация временных затрат;
– итерационный подход;
– прототипирование программных продуктов;
– сотрудничество с заказчиками;
– комбинирование разработки и тестирования системы.
Принципы RAD часто используются не только для реализации, а и для
распространяются на полностью все этапы ЖЦ, в частности, на стадии обследования
организации.
На рисунке 1.17 показан основные достоинства рассматриваемой
методологии.
Приниципы применения
RAD
повышенная
скорость разработки
низкая стоимость
высокое качество
31
Рисунок 1.17 – Достоинства методологии RAD
Гибкая методология разработки (Agile) – это серия подходов к процессу
разработки АИС, ориентированных на применение интерактивной разработки,
формирование динамических требований, а также обеспечение их реализации при
постоянном взаимодействии внутри самоорганизующихся групп, состоящих со
специалистов самого различного профиля.
Стоит отметить, что есть несколько методик, которые относятся к классу
гибких, в частности:[4]
– экстремальное программирование;
– Scrum;
– DSDM.
Множество гибких методологий сразу нацелены на выполнение минимизации
рисков путём сведения процесса разработки к серии очень коротких циклов, что
называются итерациями (рисунок 1.18).