Анализ подходов применения программного обеспечения для проектирования изделия под заданную стоимость на этапах жизненного цикла

За последние тридцать лет в экономике наметилась четкая тенденция к значительному сокращению жизненного цикла (ЖЦ) продукции в результате ускорения научно-технического прогресса, в связи с чем возможность управлять жизненным циклом продукта и осуществлять его разработку в более короткие сроки становится важным конкурентным преимуществом.

Возникает необходимость в принятии решений в быстро меняющихся условиях, что требует применение новых методов, подходов, одним из которых является анализ затрат жизненного цикла (Life cycle cost analysis – LCCA). LCCA это инструмент для определения наиболее экономичного варианта среди различных конкурирующих альтернатив покупки, владения, эксплуатации, обслуживания и, наконец, утилизации объекта или процесса [1].

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

Материалы и методы

Постановка задачи по разработке программного модуля для оценки стоимости жизненного цикла требует рассмотрение следующих вопросов:

• 1)    Рассмотреть существующие механизмы применения программного обеспечения для оценки стоимости жизненного цикла изделия в разных отраслях.

• 2)    Дать описаниепроцессам разработки программного обеспечения для оценки стоимости жизненного цикла изделия, с учетом выбора облачного сервис.

• 3)    Выбор программного метода.

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

Таблица 1 Сравнение методов проектирования ПО

Методы проектировани – программного обеспечения	Условия использования методики
Модель водопада	•    только когда требования известны, поняты и фиксированы. Нет противоречивых требований •    нет проблем с наличием программистов необходимой квалификации •    в относительно небольших проектах
V-модель	•    если требуется тщательное тестирование продукта, то V-модель оправдает основную идею: валидация и верификация •    для малых и средних проектов, где требования четко определены и зафиксированы •    в условиях наличия инженеров с необходимой квалификацией, особенно тестировщиков
Инкрементальная модель	•    когда основные требования к системе четко определены и поняты. В то же время некоторые детали могут быть улучшены со временем. •    необходим ранний вывод продукта на рынок •    есть несколько рискованных функций или целей
Модель RAD	только в присутствии высококвалифицированных и узкоспециализированных архитекторов. Бюджет проекта большой, чтобы оплатить этих специалистов, равно как и стоимость готовых автоматизированных сборочных инструментов. Модель RAD можно выбрать при уверенном знании целевого бизнеса и необходимости срочного производства системы в течение 2-3 месяцев.
Гибкая модель (Agile)	•    когда потребности пользователей постоянно меняются в динамичном бизнесе •    гибкие изменения реализуются с меньшими затратами из-за частых приращений •    в отличие от модели водопада, в гибкой модели достаточно лишь небольшого планирования, чтобы начать проект
Итерационная модель	• повторные требования к окончательной системе четко определены и понятны заранее

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

Описание этапов разработки программного обеспечения для расчета стоимости жизненного цикла изделия представлено на рисунке 1.

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

Рис. 1. Этапы разработки программного обеспечения для расчета стоимости жизненного цикла изделия [3]

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

Проект, концепция которого выглядит приемлемой для реализации, входит в стадию разработки требований. Цели этапа - выявить все скрытые потребности, разрешить конфликты требований, сформировать целостное техническое решение и проанализировать осуществимость подготовленного решения [4].

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

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

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

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

Что касается приложений жизненного цикла изделия (Productlifecycle – PLM), частные облака больше подходят для систем автоматизированного проектирования (САПР), поскольку они имеют более широкие каналы передачи данных, или гибридные, в которых рабочие станции проектировщиков будут расположены локально, а другие рабочие станции и хранилища данных будут находиться в публичном облаке. Но для этого сначала нужно решить вопрос с производительностью обработки графики на виртуальных рабочих станциях [5].

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

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

• •    расчет стоимости жизненного цикла – анализ общей стоимости владения различными конструктивными альтернативами и компонентами системы на протяжении всего прогнозируемого жизненного цикла системы;

• •    анализ затрат – расчет стоимости дерева продуктов, которая позволяет встроить параметры дерева продуктов в модель жизненного цикла и рассчитать любые требуемые категории / элементы затрат (например, стоимость запасных частей для каждого уровня ремонта) для всех компонентов дерева продуктов;

• •    общая стоимость владения - рассчитывается с использованием существующей или вновь созданной структуры распределения затрат (Cost breakdown structure – CBS) и присвоения переменных затрат каждому первичному элементу CBS. Система обеспечивает оценку затрат в порядке возрастания, поддерживает подробное изучение затрат и параметров, влияющих на жизненный цикл, выполняет анализ чистых текущих затрат;

• •    чистая приведенная стоимость (Net Present Cost – NPC). При анализе бюджета и финансов необходимым требованием является определение текущей стоимости будущих денежных потоков, а также сравнение вариантов с разными уровнями инфляции и ставками

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

• •    оценка прибыльности, которая обычно рассчитывается на основе операционных затрат на единицу затрат;

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

• •    анализ чувствительности – рассчитывает изменения в жизненном цикле / общей стоимости владения на основе изменений определенных глобальных переменных. Анализ чувствительности определяет основные детерминанты стоимости (принцип Парето 20/80), поддерживает сравнительный анализ и показывает результаты изменений конкретного критического параметра и ключевых допущений;

• •    библиотека данных – набор глобальных переменных, которые приемлемы для модели стоимости и влияют на большое количество элементов, например, инфляцию и ставки дисконтирования [6].

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

Примеры функций программного обеспечения представлены ниже:

Рис. 2. Структуру распределения затрат (CBS) и структурную декомпозицию изделия (PBS), предоставляет расчет по восходящей с учетом времени (фаз жизненного цикла) на примере D-LCC

Cost Profile

■*■ Improvement

■w New Design

Period

Рис. 3. Оценка кривой затрат

Результаты

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

Заключение

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