Logo Море(!) аналитической информации!
IT-консалтинг Software Engineering Программирование СУБД Безопасность Internet Сети Операционные системы Hardware
Скидка до 20% на услуги дата-центра. Аренда серверной стойки. Colocation от 1U!

Миграция в облако #SotelCloud. Виртуальный сервер в облаке. Выбрать конфигурацию на сайте!

Виртуальная АТС для вашего бизнеса. Приветственные бонусы для новых клиентов!

Виртуальные VPS серверы в РФ и ЕС

Dedicated серверы в РФ и ЕС

По промокоду CITFORUM скидка 30% на заказ VPS\VDS

VPS/VDS серверы. 30 локаций на выбор

Серверы VPS/VDS с большим диском

Хорошие условия для реселлеров

4VPS.SU - VPS в 17-ти странах

2Gbit/s безлимит

Современное железо!

2004 г.

Современные технологии создания программного обеспечения. Обзор

А.М. Вендров ,
Jet Info Online , # 4/2004

Технологии создания программного обеспечения

Требования, предъявляемые к ТС ПО

ТС ПО в общем случае можно описать следующей системой понятий:

Технология создания ПО - упорядоченная совокупность взаимосвязанных технологических процессов в рамках ЖЦ ПО.

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

Технологическая операция - основная единица работы, выполняемая определенной ролью, которая:

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

Рабочий продукт - информационная или материальная сущность, которая создается, модифицируется или используется в некоторой технологической операции (модель, документ, код, тест и т.п.). Рабочий продукт определяет область ответственности роли и является объектом управления конфигурацией.

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

Руководство - практическое руководство по выполнению одной или совокупности технологических операций. Руководства включают методические материалы, инструкции, нормативы, стандарты и критерии оценки качества рабочих продуктов.

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

Основным требованием, предъявляемым к современным ТС ПО, является их соответствие стандартам и нормативным документам, связанным с процессами ЖЦ ПО и оценкой технологической зрелости организаций-разработчиков (ISO 12207, ISO 9000, CMM и др.). Согласно этим нормативам, ТС ПО должна поддерживать следующие процессы:

  • управление требованиями;
  • анализ и проектирование ПО;
  • разработка ПО;
  • эксплуатация;
  • сопровождение;
  • документирование;
  • управление конфигурацией и изменениями;
  • тестирование;
  • управление проектом.

Полнота поддержки процессов ЖЦ ПО должна поддерживаться комплексом инструментальных средств (CASE-средств).

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

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

Внедрение ТС ПО в организации

При внедрении ТС ПО следует руководствоваться рекомендациями, приведенными в стандартах [27], [28], [29] (их краткий перевод приведен в [4]). Эти рекомендации достаточно актуальны и ценны, поскольку отражают опыт, накопленный многими зарубежными пользователями и разработчиками ТС ПО в течение длительного периода их существования.

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

  1. Определение потребностей в ТС ПО, характеристик объекта внедрения и проектов создания ПО.
  2. Определение требований, предъявляемых к ТС ПО (анализ характеристик объекта внедрения и проектов, обоснование требований к ТС ПО, определение приоритетов требований).
  3. Оценка вариантов ТС ПО. Предварительная экспертная оценка заключается в анализе доступных ТС ПО на предмет соответствия требованиям, неудовлетворительные варианты (с точки зрения реализации наиболее приоритетных требований) отвергаются, формируется список претендентов. При детализированной оценке для каждой ТС ПО-претендента формируется ее детальное описание. Источники информации для описания - техническая документация поставщика, доступные данные о реальных внедрениях, результаты выполнения пилотных проектов.
  4. Выбор ТС ПО. Производится сравнительный анализ технологий и окончательный выбор ТС ПО с помощью экспертной оценки.
  5. Адаптация ТС ПО к условиям применения. Производится формирование конкретной рабочей конфигурации ТС ПО, адаптированной к условиям объекта внедрения.

В процессе внедрения ТС ПО собирается статистика и оценивается эффективность ее внедрения с точки зрения ряда критериев (минимум трудоемкости сопровождения ПО, минимум затрат на сопровождение ПО и др.). При изменении условий объекта внедрения и по результатам анализа эффективности внедрения ТС ПО принимается решение: а) о внесении изменений в рабочую конфигурацию ТС ПО; б) о переходе на новую ТС ПО. В случае перехода повторяются пп. 3)-4)-5).

Оценка и выбор ТС ПО

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

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

Процесс выбора включает в себя следующие действия:

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

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

Исходные данные для оценки и выбора - набор параметров (технико-экономических характеристик) ТС ПО:

  1. Функциональные характеристики, ориентированные на процессы жизненного цикла ПО (управление проектом, управление требованиями, управление конфигурацией и изменениями, анализ и проектирование ПО и др.).
  2. Функциональные характеристики применения (среда функционирования, совместимость с другими ТС ПО, соответствие технологическим стандартам).
  3. Характеристики качества (надежность, удобство использования, эффективность, сопровождаемость, переносимость).
  4. Общие характеристики (затраты на технологию, лицензионная политика, оценочный эффект от внедрения ТС ПО, инфрастуктура, требуемая для внедрения ТС ПО, доступность и качество обучения, сертификация поставщика, поддержка поставщика).

На основе данного набора параметров анализируются и классифицируются существующие ТС ПО. Общий набор критериев, применяемых для оценки ТС ПО, приведен в Таб. 1.

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

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

Критерий

Определение

Минимум трудоемкости создания ПО

Количество человеко-месяцев, затрачиваемых на создание ПО с использованием ТС ПО

Максимум продуктивности

Объем работы (измеряемый в количестве строк кода или функциональных точек), приходящийся на единицу трудоемкости (человеко-месяц) при использовании данной ТС ПО

Максимум качества создаваемого ПО

Количество дефектов в рабочих продуктах при использовании данной ТС ПО

Возврат инвестиций

(Доход от использования ПО - Затраты на создание и сопровождение ПО) / (Затраты на создание и сопровождение ПО)

Минимум затрат на сопровождение ПО

Отношение стоимости сопровождения ПО при использовании данной ТС ПО к совокупным затратам на информационные ТС ПО в организации

Минимум времени внедрения ТС ПО

Временной интервал от начала внедрения ТС ПО до выхода на безубыточный уровень (начало возврата инвестиций в ТС ПО)

Минимум затрат на внедрение ТС ПО

Суммарная стоимость приобретения, обучения и сопровождения ТС ПО

Минимальный срок окупаемости затрат на внедрение ТС ПО

Временной интервал от начала внедрения ТС ПО до полной окупаемости затрат на ее внедрение

Выполнение пилотного проекта

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

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

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

Пилотный проект должен обладать следующими характеристиками:

  • Типичность предметной области. Чтобы облегчить окончательное определение области применения ТС ПО, предметная область пилотного проекта должна быть типичной для обычной деятельности организации. Пилотный проект должен помочь определить любую дополнительную технологию, обучение или поддержку, которые необходимы для перехода от пилотного проекта к широкомасштабному использованию ТС ПО. В рамках этих ограничений пилотный проект должен иметь небольшой, но значимый размер.
  • Масштабируемость. Результаты, полученные в пилотном проекте, должны показать масштабируемость ТС ПО. Цель - получить четкое представление о масштабах проектов, для которых данная ТС ПО применима.
  • Представительность. Пилотный проект не должен быть необычным или уникальным для организации. ТС ПО должна использоваться для решения задач, относящихся к предметной области, хорошо понимаемой всей организацией.
  • Критичность. Пилотный проект должен иметь существенную значимость, чтобы оказаться в центре внимания, но не должен быть критичным для успешной деятельности организации в целом.
  • Авторитетность. Группа специалистов, участвующих в проекте, должна обладать высоким авторитетом, при этом результаты проекта будут всерьез восприняты остальными сотрудниками организации.
  • Готовность проектной группы. Проектная группа должна обладать готовностью к нововведениям, технической зрелостью и приемлемым уровнем опыта и знаний в данной ТС ПО и предметной области. С другой стороны, группа должна отражать в миниатюре характеристики организации в целом.

В процессе оценки пилотного проекта организация должна определить свою позицию по следующим трем вопросам:

  • Целесообразно ли внедрять ТС ПО?
  • Какие конкретные особенности пилотного проекта привели к его успеху (или неудаче)?
  • Какие проекты или подразделения в организации могли бы получить выгоду от использования ТС ПО?

Возможным решением должно быть одно из следующих:

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

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

План перехода должен охватывать:

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

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

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

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

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

Назад       Содержание        Дальше

Бесплатный конструктор сайтов и Landing Page

Хостинг с DDoS защитой от 2.5$ + Бесплатный SSL и Домен

SSD VPS в Нидерландах под различные задачи от 2.6$

✅ Дешевый VPS-хостинг на AMD EPYC: 1vCore, 3GB DDR4, 15GB NVMe всего за €3,50!

🔥 Anti-DDoS защита 12 Тбит/с!

VPS в 21 локации

От 104 рублей в месяц

Безлимитный трафик. Защита от ДДоС.

🔥 VPS до 5.7 ГГц под любые задачи с AntiDDoS в 7 локациях

💸 Гифткод CITFORUM (250р на баланс) и попробуйте уже сейчас!

🛒 Скидка 15% на первый платеж (в течение 24ч)

Новости мира IT:

Архив новостей

IT-консалтинг Software Engineering Программирование СУБД Безопасность Internet Сети Операционные системы Hardware

Информация для рекламодателей PR-акции, размещение рекламы — adv@citforum.ru,
тел. +7 495 7861149
Пресс-релизы — pr@citforum.ru
Обратная связь
Информация для авторов
Rambler's Top100 TopList liveinternet.ru: показано число просмотров за 24 часа, посетителей за 24 часа и за сегодня This Web server launched on February 24, 1997
Copyright © 1997-2000 CIT, © 2001-2019 CIT Forum
Внимание! Любой из материалов, опубликованных на этом сервере, не может быть воспроизведен в какой бы то ни было форме и какими бы то ни было средствами без письменного разрешения владельцев авторских прав. Подробнее...