12
функциями и назначением.
АРМ, или в зарубежной версии, рабочая станция, обычно представляет
из себя место пользователя-специалиста любой профессии, которое
оборудовано необходимыми средствами для автоматизации выполняемых
задач или функций. Таким средством зачастую является обычный ПК,
дополняемый в зависимости от исполняемых задач другими периферийными
средствами: накопителями, печатными устройствами, считывателями
данных, устройствами графического ввода, средствами соединения с
другими АРМ или локальными вычислительными сетями (ЛВС).
В литературе АРМ обычно представляют, как профессионально-
ориентированный программный комплекс, который позволяет обеспечить
решение пользовательских задач непосредственно на рабочем месте. При
этом сам ПК может функционально и эргономически подстроиться под
каждого пользователя. С позиции обеспечения АРМ специалиста
представляет комплекс технических, программных, информационных и
методических средств, которые предназначаются для увеличения качества
обработки данных на момент принятия решения.
Поэтому более правильным будет определение, когда под АРМ
понимается рабочее место, которое имеет комплекс программных,
технических и информационных средств, которые позволяют нормально
работать квалифицированному сотруднику совместно с ПК,
предназначенным для автоматизации действия работника непосредственно в
рамках рабочего места. Сам АРМ – это совокупность аппаратно-
программных средств, которые позволяют взаимодействовать человеку и
ЭВМ для уменьшения доли ручного труда.
Создание и внедрение АРМ можно назвать сложной задачей,
направленной на решение ряда вопросов: технических, организационных,
лингвистических, математических, программных, экономических. Само
13
решение основано на изучении предметной области, выборе средств и
методов проектирования, учете общесистемных и специфичных принципов
реализации программных продуктов.
Внимательно рассмотрим общесистемные принципы создания АРМа.
Принцип единства системы на этапе проектирования АРМ включает в
себя следующие работы:
1) постановку задачи;
2) структуризацию;
3) параметризацию условия;
4) итоговую реализацию.
При создании АРМ важно определять:
• Методы кодирования и хранения всех данных (текстовых,
графических, видео- и аудиоматериалов);
• Актуальное соотношение графики и текста для лучшего
понимания менеджера, который принимает решения, всей представленной
информации;
• Интенсивность запросов и время их обработки в самой системе,
если речь идет о многопользовательском варианте построения системы;
• Средства и методы архивации данных при их сохранении или
обмене между подсистемами АРМ.
5) гибкость;
6) стабильность;
7) единообразие;
8) результативность.
Важную роль при определении функционального назначения АРМ
играет его целевое использование, профориентация, базовые процессы,
внутренняя структура хозяйствующего субъекта.
Вся материальная база с информационными ресурсами отражается в
14
АРМ. Внедрение подобной системы предполагает, что все главные операции
по накоплению, переработке, хранению данных передается вычислительной
технике, а сам пользователь лишь выполняет часть ручной работы и те
операции, которые требуют творческого подхода при составлении
управленческих решений.
ПЭВМ всегда были основой для АРМ как руководителя, так и
специалиста. Они функционально, эргономически и физически позволяют
подстроиться под каждого пользователя (персональное рабочее место) или
группу пользователей. АРМ можно называть совокупностью технических и
программных средств, которые дают возможность специалисту отдельного
профиля решать свои профессиональные задачи непосредственно на ПК.
1.2 Жизненный цикл и модели жизненного цикла
информационных систем
Методология проектирования ИС включает в себя описание процесса
создания и сопровождения систем в виде жизненного цикла (ЖЦ) ИС,
отождествляя его с некоторой последовательностью стадий и исполняемых
на них процессов. Для каждой стадии выявляется состав и
последовательность производимых работ, итоговые результаты, методы и
средства, нужные для реализации работ, ответственность и роль участников
и т.д. Подобное формальное описание ЖЦ ИС дает возможность
спланировать и подготовить процесс совместной разработки и поддерживать
управление этим процессом.
Жизненный цикл (ЖЦ) ИС представляется, как ряд событий,
случающихся с системой с момента ее внедрения и до окончания
использования.
15
Модель ЖЦ отражает различные состояния системы, от момента
возникновения необходимости в данной ИС и до момента ее окончательного
вывода из эксплуатации. Модель жизненного цикла представлена некой
структурой, которая содержит процессы, действия и задачи, реализуемые в
ходе создания, работы и сопровождения ПО в течение всей жизни системы,
от выявления требований до окончания ее использования.
Сегодня известны и применимы следующие модели жизненного цикла:
• Каскадная модель включает в себя последовательную
реализацию всех этапов проекта в заранее определенном порядке. Начало
следующего этапа говорит о полном завершении работ на предыдущем этапе.
• Поэтапная модель с периодичным контролем. Создание ИС
реализовано в виде итераций с циклами обратной связи между этапами.
Межэтапные проверки позволяют учесть реально существующее
взаимовлияние итогов разработки на различных этапах; ЖЦ каждого из
этапов продлевается на весь срок разработки.
• Спиральная модель. На любом витке спирали выполняется
генерация очередной версии продукта, корректируются требования проекта,
выражается его качество и планируются работы уже следующего витка.
Особое внимание при этом обращается на начальные этапы разработки -
анализ и проектирование, где возможность создания тех или иных
технических решений обосновывается и проверяется благодаря построению
прототипов.
Каскадный подход отлично зарекомендовал себя в процессе создания
относительно простых ИС, когда в самом начале разработки можно с
большой точностью и полнотой составить все требования к системе.
Главным недостатком такого подхода является то, что основной процесс
разработки системы не может полностью уложится в такие жесткие рамки,
постоянно есть потребность в возврате к уже завершенным этапам для
16
уточнения или изменения ранее принятых решений. В итоге реальный
процесс разработки ИС становится соответствующим поэтапной модели с
периодичным контролем.
Все стадии создания системы предусматривают выполнение
некоторого объема работ, представляемых в виде процессов ЖЦ. Процесс
выражается как совокупность объединенных действий, изменяющих входные
данные в выходные. Описание любого процесса состоит из перечня
решаемых задач, исходных данных и итоговых результатов.
Есть целый ряд стандартов, определяющих ЖЦ ПО, а в отдельных
случаях и процессы разработки.
Среди самых известных стандартов выделяют следующие:
• ГОСТ 34.601-90 - распространяется на АИС и указывает в себе
стадии и этапы их создания. Также в нем имеется описание содержания работ
на всех этапах. Стадии и этапы работы, отраженные в стандарте, зачастую
соответствуют каскадной модели жизненного цикла.
• ISO/IEC 12207:1995 - стандарт на процессы и реализацию
жизненного цикла. Применяется ко всем видам заказного ПО. Стандарт не
имеет описания стадий, фаз и этапов.
• Custom Development Method по созданию прикладных ИС -
технологический материал, углублённый до уровня заготовок проектных
документов, которые рассчитаны на применение в проектах совместно с
Oracle. Используется CDM для типовой модели ЖЦ (имеются все
работы/задачи и этапы), а также для случаев "быстрой разработки" (Fast
Track) или "облегченного подхода", которые будут оптимальны в малых
проектах.
• Rational Unified Process (RUP) включает в себя итеративную
модель разработки, имеющую четыре фазы: старт, анализ, создание и
использование. Все эти фазы могут быть разделены на этапы (итерации), по
17
итогу которых имеется версия для внутреннего или внешнего использования.
Реализация четырех основных фазы считается циклом разработки, и любой
такой цикл завершается созданием версии системы. В случае, если работа
над проектом не прекращается и после этого, полученный продукт
продолжает оптимизироваться и снова проходит те же фазы. Суть
реализации в рамках RUP - это разработка и сопровождение моделей на базе
UML.
• Microsoft Solution Framework (MSF) похож на RUP, так же имеет
четыре фазы: исследование, построение, создание, стабилизация, является
итерационным, включает в себя применение объектно-ориентированного
моделирования. MSF в отличии от RUP в сильнее ориентирован на создание
бизнес-приложений.
• Extreme Programming (XP). Экстремальное программирование
(самая молодая среди остальных методологий) было реализовано в 1996 году.
В основе методологии лежит командная работа, четкая коммуникация между
исполнителем и заказчиком в течение всего срока проекта, а сама разработка
реализуется методом последовательной доработки прототипов.
• Стандарт ISO/IEC серии 15288.
При выборе стандарта основным определяющим фактором является
более полное и подробное описание работ на стадиях и этапах разработки
АС(автоматизируемых систем). Стандарт ISO/IEC 12207 не содержит
подробное описание работ на разных стадиях и этапах разработки АС.
Стандарт CDM рассчитан на использование в проектах с применением Oracle
технологий, который в данном проекте не используются. Стандарт MSF, как
было ранее сказано, в большей степени ориентирован на разработку бизнес-
приложений. Стандарт XP ориентирован на командную работу. В данном
проекте будет использоваться ГОСТ 34.601-90, так как он содержит описание
работ на каждом этапе разработки АС.
18
Стадии создания ИС.
1. Формирование требований к системе,
2. Разработка концепции,
3. Техническое задание,
4. Технический проект,
5. Оформление документации,
6. Внедрение.
На этапе “Формирование требований к системе”, производится
следующие работы: обследование объекта, формирование требований
пользователя, обоснование необходимости разработки системы. На данном
этапе задействованы следующее участники: IT-менеджер, начальник отдела
по работе с клиентами. После выполнения всех работ формируется отчет о
проделанных работах - характеристика объекта автоматизации, описание
требований к системе, определение затрат на разработку, введение в
эксплуатацию и сопровождение, ожидаемый эффект от системы и условия
создания и эксплуатации системы.
После выполнения этапа “Формирования требований к системе”
разрабатываются варианты концепции. Производят разработку
альтернативных вариантов концепции и планов реализации, оценку
необходимых ресурсов на реализацию ИС и дальнейшее функционирование,
оценка преимуществ и недостатков каждого варианта, сопоставление
требований пользователя и характеристик предлагаемой системы. На этапе
“Разработка концепции” участвует IT-менеджер. После выполнения данных
работ выбирается один из подходящих вариантов концепции
удовлетворяющий всем требованиям.
После этапа “Разработка концепции” разрабатывается ТЗ (техническое
задание) проекта автоматизации. После разработки и оформления ТЗ,
необходимо его согласовать и утвердить. Участники на данном этапе работ:
19
IT-менеджер, начальник отдела по работе с клиентами. В результате данный
пункт определяет: функции ИС, функции подсистем, состав комплекса задач
и отдельных задач, концепция информационной базы, функции систем
управления базой данных, а также функции и параметры программных
средств.
Следующим этапом после разработки и утверждения ТЗ идет
разработка проектного решения. IT-менеджер, совместно с программистом,
разрабатывают физическую и логическую модель БД, определяют
организацию базы данных. По завершению этапа “Технический проект” IT-
менеджером совместно с программистом производится оформления рабочей
документации, включающие в себя: технические требования, программные
требования, руководство пользователя.
После выполнения всех работ и оформления рабочей документации
остается этап внедрения разрабатываемого проекта. На этапе внедрения
происходит: подготовка объекта автоматизации, обучение персонала,
производятся строительно-монтажные работы, пусконаладочные работы,
проведение предварительных испытаний, проведение опытной эксплуатации
и проведение приемочных испытаний. Участники данного этапа: IT-
менеджер, системный администратор, начальник отдела работы с клиентами..
После чего анализируются испытания ИС, проверка на соответствие ТЗ,
устраняются неполадки и подписываются необходимые акты.
На этапе эксплуатации системы производится ее эксплуатация.
1.3 Оценка качества разработки программного обеспечения
Экспертизу качества модуля реализуют на фазах ЖЦ в рамках ГОСТ
28195-89 «Оценка качества программных средств» (ПС). Состоит она из
определения номенклатуры параметров, их оценку и сравнение значений,
20
полученных по итогу сравнения с исходными показателями. Эти параметры
качества соединены в систему из 4 уровней, описанных ниже. Допускается
использовать дополнительные показатели на любом уровне.
Для поддержания доступности реализации интегральной оценки по
группам показателей качества применяют факторы качества (уровень 1):
стабильность ПС, настройка, удобство применения, результативность,
универсальность, скорость работы.
Каждому фактору качества ставится в соответствии набор критериев
качества (совокупные показатели – уровень 2): стабильность работы,
работоспособность, упорядоченность, легкость конструкции, адекватность,
повторяемость, простота обучения, доступность обучающей литературы,
логичность эксплуатации и обслуживания, автоматизировалось, текущая
эффективность, гибкость, мобильность, возможность обновления,
грамотность реализации, согласованность, корректность работы функций,
готовность документации, контроль доступом, резервирование,
защищенность.
Критерии качества выражаются одной или несколькими метриками
(уровень 3). В случае, если критерий качества выражен одной метрикой, то
уровень пропускается.
Метрики включают оценочные элементы (одинарных показателей –
уровень 4), отражающих указанное в метрике свойство. Общая сумма
оценочных элементов, которые сводят в метрику, не ограничивается.
Параметры качества являются иерархической многоуровневой
системой, где показатели высших уровней выражаются через показатели
нижних уровней, и лишь на завершающем уровне оценка значений
показателей реализована в рамках данных, относящихся только к ПС.
Оценка качества реализуется на всех этапах ЖЦ ПС при:
Утверждении параметров качества ПС;
21
Отслеживание качества на некоторых этапах разработки (ТЗ,
технический и рабочий проект);
Отслеживание качества в рамках производства ПС;
Отслеживание эффективности обновления ПС в рамках
сопровождения.
Оценка качества реализуют:
Разработчики в процессе создания ПС;
Фонд держатель в рамках приемки ПС в фонд;
Центры сертификации и проведения испытаний ПС в рамках
внедрения;
Изготовитель в рамках копирования ПС;
Пользователь в рамках внедрения, поддержки и использования
ПС.
Базовые задачи, которые решаются при оценке качества ПС:
Выделение номенклатуры уровней качества;
Выделение уровней параметров качества;
Определение методов контроля параметров качества ПС;
Отслеживание значений параметров качества;
Выполнение решений по соответствию реальных показателей
качества текущим требованиям.
Способы выявления параметров качества ПС различаются:
По методике получения данных о показателе:
По измерению,
По регистрации,
По расчету,
По восприятию человеком;
По источникам выражения информации о ПС: