Какой анализ проводят при выборе программных обеспечений

Обновлено: 28.06.2024

Джейкоб Морган, основатель консалтинговой компании Chess Media Group, автор нескольких книг по оптимизации бизнес-процессов, в своем блоге делится методикой оценки поставщиков программных решений для бизнеса на основе восьми простых критериев. Предлагаем вашему вниманию перевод его статьи.

Я уверен, вы заметили, что многие поставщики программного обеспечения выглядят очень похоже, и не только внешне, но и по функциональности. Это очевидно и для самих вендоров, и для клиентов, поэтому оценка и выбор конкретного поставщика – довольно непростая задача. Я предлагаю использовать для оценки восемь переменных, которые, по сути, являются основными конкурентными преимуществами в этой сфере.

Цена

Итак, сколько поставщик запрашивает за использование своей платформы? Здесь обычно используется два подхода – оплата за каждого пользователя, либо некая общая фиксированная сумма. Поэтому важно понять, какое количество ваших сотрудников будет непосредственно работать с системой. При этом желательно сделать примерный расчет на перспективу – сколько это будет вам стоить сейчас, сколько – через полгода, год, два или более. Не обязательно делать точные прогнозы, важно понимать общую стратегию. Например, в первый год вам понадобится 100 пользователей системы, а со временем это число может вырасти в несколько раз. Или наоборот. Поэтому нужно подробно рассмотреть все условия – зависит ли стоимость предлагаемого решения от количества пользователей, как она меняется при масштабировании системы, и так далее.

Особенности

Что именно эта платформа может сделать для вас такого, что не могут другие? Большинство платформ имеют очень похожие наборы функций, поэтому наличие специфических возможностей бывает весьма весомым аргументом при выборе. Лучший способ определить, какие возможности вам нужны – это сначала продумать все возможные варианты использования системы, и затем сопоставлять их с предлагаемым функционалом.

Люди

Наверняка вы захотите убедиться, что работаете с поставщиком, которые не только предлагает отличный продукт, но и отличный сервис. Как правило, сотрудничество с поставщиками программного обеспечения для бизнеса носит долговременный характер – любая платформа развивается, обновляется, дорабатывается по мере появления новых потребностей клиента. Поэтому послепродажное обслуживание и техническая поддержка – один из крайне важных аспектов, которые следует учитывать при выборе поставщика.

Безопасность

Некоторые компании ориентируются только на замкнутые корпоративные системы, другие выбирают облачные решения, третьи используют смешанные подходы. У каждой компании свое отношение к безопасности и свои требования к ее обеспечению. Но независимо от вашего выбора, необходимо убедиться, что предлагаемая поставщиками платформа обеспечивает безопасность ваших данных, и в то же время достаточно гибка, чтобы обеспечить все ваши потребности.

Настройка и интеграция

Большинство клиентов заинтересованы в возможности интеграции предлагаемых программных решений с уже использующимися в компании. Иногда это может иметь решающее значение. Однако далеко не все поставщики могут обеспечить быструю и эффективную интеграцию с другими программами, поэтому этот аспект желательно учитывать заранее, и одним из первых.

Простота в освоении и использовании

Грамотные поставщики уделяют особое внимание этому параметру. Многие из них стараются делать свои интерфейсы максимально легкими и интуитивно понятными, при этом используя элементы, уже знакомые пользователям – например, используемые в социальных сетях.

Стоимость поддержки и обслуживания

Убедитесь, что поставщик предлагает адекватную стоимость поддержки своего продукта. Цены здесь варьируются очень широко – одни производители взимают более 20 процентов от годовой лицензии, другие, наоборот, предлагают бесплатную поддержку. Есть поставщики, которые настраивают систему, и затем оставляют за собой только решение проблемных вопросов. Другие берут на себя обязательства по постоянному обновлению и настройке платформы по мере выхода новых версий.

Оценка опыта поставщика

Я не сторонник того, чтобы рассматривать этот фактор как решающий. Да, часть поставщиков специализируются на компаниях какой-то определенной отрасли – например, финансовой, или фармацевтической, или ритейла. Однако многие решения могут быть внедрены в компаниях самых разных отраслей. Если у поставщика уже есть в клиентах несколько компаний вашей отрасли – это безусловный плюс. Но лучше анализировать платформу с точки зрения соответствия именно вашим потребностям.

И, пожалуй, еще один фактор, который я не стал включать в основной список, но тоже считаю существенным. Особенно если вы оказались в ситуации, когда нужно сделать выбор между практически равнозначными поставщиками. Советую обратить внимание, выступает ли поставщик в качестве эксперта в своей отрасли, и каковы его ресурсы по обучению пользователей. Регулярный выпуск образовательных материалов, мануалов, проведение семинаров и тому подобное – хороший признак того, что вы имеете дело с профессионалами. В столь изменчивой и стремительно развивающейся индустрии, как IT, мне нравится работать с людьми, которые являются для своих клиентов источниками актуальных знаний. Это помогает в достижении общих целей.

Анализ и проектирование программного обеспечения включают все действия, которые помогают преобразовать спецификацию требований в реализацию. Спецификации требований определяют все функциональные и нефункциональные ожидания от программного обеспечения. Эти спецификации требований представлены в форме удобочитаемых и понятных документов, к которым компьютер не имеет никакого отношения.

Анализ и проектирование программного обеспечения — это промежуточный этап, который помогает преобразовать понятные человеку требования в реальный код.

Давайте рассмотрим несколько инструментов анализа и проектирования, используемых разработчиками программного обеспечения:

Диаграмма потока данных

Диаграмма потока данных — это графическое представление потока данных в информационной системе. Он способен отображать входящий поток данных, исходящий поток данных и сохраненные данные. В DFD ничего не говорится о том, как данные проходят через систему.

Существует заметная разница между DFD и блок-схемами. Блок-схема изображает поток управления в программных модулях. DFD отображают поток данных в системе на разных уровнях. DFD не содержит элементов управления или ветвления.

Типы ДФД

Диаграммы потоков данных являются либо логическими, либо физическими.

Логический DFD — этот тип DFD концентрируется на системном процессе и потоке данных в системе. Например, в банковской системе программного обеспечения, как данные перемещаются между различными объектами.
Физический DFD — этот тип DFD показывает, как поток данных фактически реализуется в системе. Это более конкретно и близко к реализации.

DFD Компоненты

DFD может представлять источник, место назначения, хранилище и поток данных, используя следующий набор компонентов:

Объекты — объекты являются источником и местом назначения информационных данных. Сущности представлены прямоугольниками с соответствующими именами.
Процесс — Действия и действия, предпринятые с данными, представлены прямоугольниками с круглыми или круглыми краями.
Хранение данных. Существует два варианта хранения данных: оно может быть представлено в виде прямоугольника с отсутствием обеих меньших сторон или в виде прямоугольника с открытой стороной с отсутствующей только одной стороной.
Поток данных — движение данных показано стрелками. Движение данных показано от основания стрелки в качестве источника к направлению стрелки в качестве пункта назначения.

Уровни DFD

Уровень 0 — DFD самого высокого уровня абстракции известен как DFD уровня 0, который изображает всю информационную систему в виде одной диаграммы, скрывающей все базовые детали. DFD уровня 0 также известны как DFD контекста уровня.

Уровень 2 — На этом уровне DFD показывает, как данные передаются внутри модулей, упомянутых на уровне 1.

DFD более высокого уровня могут быть преобразованы в более конкретные DFD более низкого уровня с более глубоким уровнем понимания, если не будет достигнут желаемый уровень спецификации.

Уровень 2 — На этом уровне DFD показывает, как данные передаются внутри модулей, упомянутых на уровне 1.

Структурные диаграммы

Структурная диаграмма — это диаграмма, полученная из диаграммы потока данных. Он представляет систему более подробно, чем DFD. Он разбивает всю систему на низшие функциональные модули, описывает функции и подфункции каждого модуля системы более подробно, чем DFD.

Структурная схема представляет собой иерархическую структуру модулей. На каждом слое выполняется определенная задача.

Вот символы, используемые при построении структурных схем —

Модуль — представляет процесс, подпрограмму или задачу. Модуль управления разветвляется на несколько подмодулей. Библиотечные модули можно использовать повторно и вызывать из любого модуля.
Состояние — он представлен маленьким бриллиантом у основания модуля. Он показывает, что модуль управления может выбирать любую подпрограмму на основании некоторого условия.
Прыжок — внутри модуля показана стрелка, показывающая, что элемент управления будет прыгать в середине субмодуля.
Петля — изогнутая стрелка представляет петлю в модуле. Все подмодули, охватываемые циклом, повторяют выполнение модуля.
Поток данных — направленная стрелка с пустым кружком в конце представляет поток данных.
Контрольный поток — направленная стрелка с заполненным кружком на конце представляет контрольный поток.

Диаграмма HIPO

Диаграмма HIPO (иерархический ввод-вывод) представляет собой комбинацию двух организованных методов для анализа системы и предоставления средств документирования. Модель HIPO была разработана IBM в 1970 году.

Диаграмма HIPO представляет иерархию модулей в программной системе. Аналитик использует диаграмму HIPO, чтобы получить общее представление о функциях системы. Он разбивает функции на подфункции в иерархическом порядке. Он изображает функции, выполняемые системой.

Диаграммы HIPO хороши для целей документирования. Их графическое представление позволяет дизайнерам и менеджерам получить наглядное представление о структуре системы.

В отличие от диаграммы IPO (Input Process Output), которая отображает поток управления и данные в модуле, HIPO не предоставляет никакой информации о потоке данных или потоке управления.

пример

Обе части диаграммы HIPO, иерархического представления и диаграммы IPO используются для проектирования структуры программного обеспечения, а также для документации по ним.

Структурированный английский

Большинство программистов не знают об общей картине программного обеспечения, поэтому они полагаются только на то, что им говорят их менеджеры. Ответственность за предоставление точной информации программистам для разработки точного, но быстрого кода лежит на высшем руководстве программного обеспечения.

Другие формы методов, которые используют графики или диаграммы, могут иногда по-разному интерпретироваться разными людьми.

Проектирование электронных схем осуществляется с применением систем программного обеспечения, но в настоящее время таких систем достаточно много предлагается разработчиками. В статье предлагается способ оценки и выбора систем программного обеспечения.

Введение

Сегодня этот метод используют уже повсеместно: от риэлтеров при оценке недвижимости до кадровиков при замещении вакантных должностей. С помощью МАИ можно решить задачи по выбору систем ПО и других подобного рода в аналитическом планировании. Воспользуемся этим методом и мы для выбора ПО электромонтажа.

Системы программного обеспечения широко применяются в проектировании и производстве электронных схем. Хорошо известно ПО таких фирм, как Mentor Grafics, Altium, Cadence.

Применение МАИ позволяет структурировать проблему выбора в виде иерархии или сети. В наиболее элементарном виде иерархия строится с вершины (цели), через промежуточные уровни-критерии (технико-экономические параметры) к самому нижнему уровню, который в общем случае является набором альтернатив. После иерархического воспроизведения проблемы устанавливаются приоритеты критериев и оценивается каждая из альтернатив по критериям. В МАИ элементы задачи сравниваются попарно по отношению к их воздействию на общую для них характеристику. Система парных сведений приводит к результату, который может быть представлен в виде обратносимметричной матрицы. Элементом матрицы a(i,j) является интенсивность проявления элемента иерархии i относительно элемента иерархии j, оцениваемая по шкале интенсивности от 1 до 9, предложенной автором метода, где оценки имеют следующий смысл (табл. 1).

Таблица 1. Шкала относительной важности

Если при сравнении одного фактора i с другим j получено a(i,j) = b, то при сравнении второго фактора с первым получаем a(j,i) = 1/b.

Опыт показал, что при проведении попарных сравнений в основном ставятся следующие вопросы:

Какой из них важнее или имеет большее воздействие?
Какой из них более вероятен?
Какой из них предпочтительнее?

Относительная сила, величина или вероятность каждого отдельного объекта в иерархии определяется оценкой соответствующего ему элемента собственного вектора матрицы приоритетов, нормализованного к единице. Процедура определения собственных векторов матриц поддается приближению с помощью вычисления геометрической средней.

Пусть: A₁–A_n — множество из n элементов; W₁–W_n — соотносятся, как показано в таблице 2.

A₁	…	A_n
A₁	1	…	W₁/W_n
…	…	1	A_n
A_n	W_n/W₁	…	1

Оценка компонентов вектора приоритетов производится по схеме, представленной в таблице 3.

Таблица 3. Оценка компонентов вектора приоритетов

A₁	…	A_n
A₁	1	…	W₁/W_n	X₁ = [1×(W₁/W₂)×… ×(W₁/W_n)]1/n	Вес (A₁) = X₁/сумма (X_i)
…	…	1	A_n	…	…
A_n	W_n/W₁	…	1	X_n = [(W_n/W₁)×… ×(W_n/W_n–1)×1]1/n	Вес (A_n) = X_n/сумма (X_i)
Сумма (X_i)

Приоритеты синтезируются начиная со второго уровня вниз. Локальные приоритеты перемножаются на приоритет соответствующего критерия на вышестоящем уровне и суммируются по каждому элементу в соответствии с критериями, на которые воздействует элемент. Весьма полезным побочным продуктом теории является так называемый индекс согласованности (ИС), который дает информацию о степени нарушения согласованности. Вместе с матрицей парных сравнений мы имеем меру оценки степени отклонения от согласованности. Если такие отклонения превышают установленные пределы, то тому, кто проводит суждения, следует перепроверить их в матрице:

Теперь сравним эту величину с той, которая получилась бы при случайном выборе количественных суждений из нашей шкалы и образовании обратносимметричной матрицы. В таблице 4 приведены средние согласованности для случайных матриц разного порядка.

Таблица 4. Значения случайной согласованности

Если разделить ИС на число, соответствующее случайной согласованности матрицы того же порядка, получим отношение согласованности (ОС). Величина ОС должна быть порядка 10% или менее, чтобы быть приемлемой. В некоторых случаях допускается ОС до 20%, но не более, иначе нужно проверить свои суждения.

В список критериев, по которым мы будем сравнивать ПО по технологии электромонтажа, вошли:

конструкции и технологии плат печатного монтажа;
автоматизация расчетов плат в програм-мных продуктах;
возможность импорта библиотек;
удобство пользования.

Дополнительные критерии, естественно, могут быть и другими. Их количество также может отличаться от выбранного. В любом случае должна существовать возможность собрать информацию по каждому дополнительному критерию для всех систем, а количество критериев не должно превышать 7–8, чтобы не увеличивать трудоемкость обработки данных до неразумных пределов.

Оценка критериев. Начнем с построения матрицы попарных сравнений для критериев, то есть со второго уровня иерархии (на первом уровне наша цель — выбор ПО, на третьем — альтернативы, рисунок). Для этого строим матрицу размерностью 4×4 (по числу критериев) и подпишем строки и столбцы наименованиями сравниваемых критериев.

Рисунок. Иерархическая структура МАИ

Заполняем таблицу 5. Для этого попарно сравниваем критерий из строки с критерием из столбца по отношению к цели. Значения из шкалы относительной важности (табл. 1) вписываем в ячейки, образованные пересечением соответствующей строки и столбца.

Таблица 5. Оценка критериев

Таблица 7. Автоматизация расчетов плат в программных продуктах

Таблица 8. Возможность импорта библиотек

Таблица 9. Удобство пользования

Результат будет получен с помощью простых арифметических действий.

Заполняем таблицу 10. В самую верхнюю строку переносим из таблицы 5 значения вектора приоритета для каждого критерия. Для каждой из альтернатив заполняем столбцы критериев значениями локальных векторов приоритета, полученными соответственно в таблицах 6–9.

Таблица 10. Расчет глобального приоритета

Подсчитываем значения глобального приоритета для каждой из альтернатив как сумму произведений значения вектора приоритета для критерия и значения вектора локального приоритета этой альтернативы в отношении данного критерия, то есть для альтернативы Zuken это будет:

Выбранной считается альтернатива с максимальным значением глобального приоритета. В данном случае это Altium, на котором следует остановить свой выбор.

Заключение

Сейчас многие фирмы предлагают свои продукты по технологии электромонтажа. Существует как платное программное обеспечение, так и бесплатное, с которым пользователь может легко ознакомиться, а затем принять решение в пользу того или иного ПО. Каждая фирма, которая рекламирует свой продукт потенциальному покупателю, дает возможность протестировать его на так называемых демоверсиях, либо существуют бесплатные ключи к ПО, дающие право пользоваться программой в течение положенного срока, установленного самой фирмой.

В статье предложен способ оценки ПО, который прежде всего зависит от конструкции и технологии платы печатного монтажа, а также требований к автоматизации расчетов по плате (это может быть, например, автоматизированный расчет печатных или объемных проводников, тепловой расчет, проверка на целостность сигнала и помехоустойчивость). Экспертную оценку дает сам разработчик платы печатного монтажа предприятия. Приведенные в статье расчеты следует принимать как ориентировочные: они служат для обоснования метода анализа иерархий при выборе ПО. В настоящее время существует большое количество систем программного обеспечения, но нет методики оценки систем и выбора наилучшей в каждом конкретном случае.

Для проведения работ необходима передача исходного кода.

Музалевский Фёдор Александрович

Ведущий эксперт компьютерно-технического направления

Задать вопрос эксперту: Музалевский Фёдор Александрович Задать вопрос эксперту Все эксперты

Чайковский Андрей Сергеевич

Эксперт компьютерно-технического направления

Опыт: Профессиональный опыт в сфере информационных технологий и информационной безопасности с 2012 года

Задать вопрос эксперту: Чайковский Андрей Сергеевич Задать вопрос эксперту Все эксперты

Волокитин Сергей Анатольевич

Ведущий эксперт компьютерно-технического направления

Опыт: Профессиональный опыт в сфере информационных технологий и информационной безопасности с 2008 года

Задать вопрос эксперту: Волокитин Сергей Анатольевич Задать вопрос эксперту Все эксперты

Кому необходимо проводить оценку соответствия по ОУД4

Банкам, согласно положению 719-П

В Положении 719-П указаны требования к сертификации в отношении прикладного программного обеспечения прошедших сертификацию в системе сертификации ФСТЭК или оценку соответствия по требованиям к оценочному уровню доверия не ниже, чем ОУД4.

Банкам необходимо применять платежное ПО, имеющее сертификат ФСТЭК, либо прошедшее оценку по ОУД4 у проверяющей организации.

НФО, согласно положению 757-П

В перспективе банкам, согласно проекту изменений Положения 683-П

В проекте изменений в Положении 683-П указана оценка соответствия по ОУД4, вместо анализа уязвимостей.

Новое Положение с изменениями в 683-П вступит в силу предположительно с 01.04.2022 года.

Оценка соответствия и анализ уязвимостей по ОУД – в чем различия?

Основное различие между оценкой и анализом уязвимости заключается в наборе компонентов доверия, которые надо подтвердить, и как следствие, количеством мероприятий. В таблице ниже (рис. 1) зеленым отмечено все то, что относится к анализу уязвимости, оранжевым – к оценке соответствия.

Рисунок 1. Таблица различия между оценкой и анализом уязвимости

Для проведения оценки соответствия необходимо внедрить поддержку жизненного цикла и самостоятельное тестирование кода и сборок (как функциональное, так и по безопасности).

Разумеется, внедрение поддержки жизненного цикла требует определенной документации и перестроения процессов разработки.

На схемах приведены примеры соответствия документации (справа) и компонент доверия из ОУД4. Зеленым обозначены компоненты и документы, относящиеся только к анализу уязвимостей, синим – к оценке соответствия.

Схема 2. Руководства

Схема 3. Поддержка жизненного цикла

Схема 4. Оценка задания по безопасности

Схема 5. Тестирование

Что делать тем, кто уже провёл анализ уязвимостей

Во-первых, необходимо разработать и внедрить документацию по поддержке жизненного цикла, оценки задания по безопасности и тестированию.

Отчетность по оценке соответствия по ОУД4 будет шире, чем по анализу уязвимостей. Если по анализу уязвимости достаточно было одного отчета об оценке, то при оценке соответствия по ОУД4 необходимо еще выдать подтверждение соответствия – документ по оценке заданий по безопасности, и провести выборочное функциональное тестирование.

В среднем объем работ вырастает примерно в три раза по сравнению с анализом уязвимостей.

В то же время те, кто уже провели анализ уязвимостей по ОУД4, могут использовать его результаты при проведении оценки соответствия.

Профиль защиты

По отношению к оценке соответствия добавляет не так много, как по отношению к анализу уязвимостей, но все равно порядочно.

Требования профиля защиты гораздо жестче, чем у ОУД4 — получить соответствие с применением профиля крайне тяжело!

Кто может проводить оценку соответствия по ОУД4

Для банков – проводить оценку соответствия может только лицензиат ФСТЭК. В перспективе (по проекту 683-П) – можно самостоятельно.

Для НФО – проводить оценку соответствия можно самостоятельно или с привлечением лицензиата ФСТЭК.

Согласно п. 1.8 Положения 757-П некредитная финансовой организации принимает решение: самостоятельно ли проводить ей оценку по ОУД4 или с привлечением проверяющей организации — лицензиата ФСТЭК.

Почему RTM Group?

Эксперты компании RTM Group успешно завершили проекты по аудитам и оценке соответствия по ОУД4 для:
- Значимых банков;
- Некредитных финансовых организаций;
- Операторов платежной системы;
- Разработчиков банковского ПО.
- Лицензия ФСТЭК России на деятельность по технической защите конфиденциальной информации
- Лицензия ФСТЭК России на деятельность по разработке и производству средств защиты конфиденциальной информации
- Лицензия ФСБ России на работу со средствами криптозащиты
Для уточнения стоимости и сроков звоните или пишите нам:

Читайте также: