Евгений Шуремов - Методологические подходы и средства поддержки процессов разработки программного обеспечения организационно-экономических систем. Коротко о главном

Спиральная модель (англ. spiral model) была разработана в середине 1980-х годов Барри Боэмом. Она основана на классическом цикле Деминга PDCA (plan-do-check-act). При использовании этой модели ПО создается в несколько итераций (витков спирали) методом прототипирования.

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

На каждой итерации оцениваются:

– риск превышения сроков и стоимости проекта;

– необходимость выполнения ещё одной итерации;

– степень полноты и точности понимания требований к системе;

– целесообразность прекращения проекта.

Спиральная модель является усовершенствованным вариантом эволюционной модели (модели IID). Ее отличительной особенностью является специальное внимание, уделяемое рискам, влияющим на организацию разработки. Наиболее распространёнными являются следующие группы рисков.

– Дефицит специалистов.

– Нереалистичные сроки и бюджет.

– Реализация несоответствующей функциональности.

– Разработка неправильного пользовательского интерфейса.

– Перфекционизм, ненужная оптимизация и оттачивание деталей.

– Непрекращающийся поток изменений.

– Нехватка информации о внешних компонентах, определяющих окружение системы.

– Недостатки в работах, выполняемых внешними (по отношению к проекту) ресурсами.

– Недостаточная производительность получаемой системы.

– Разрыв в квалификации специалистов разных областей.

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

– Concept of Operations (COO) – концепция (использования) системы;

– Life Cycle Objectives (LCO) – цели и содержание жизненного цикла;

– Life Cycle Architecture (LCA) – архитектура жизненного цикла; здесь же возможно говорить о готовности концептуальной архитектуры целевой программной системы;

– Initial Operational Capability (IOC) – первая версия создаваемого продукта, пригодная для опытной эксплуатации;

– Final Operational Capability (FOC) – готовый продукт, развернутый (установленный и настроенный) для реальной эксплуатации.

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

Требования могут выражаться в виде текстовых утверждений и графических моделей.

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

Этапу разработки требований часто предшествует технико-экономическое обоснование, или концептуальная фаза анализа проекта. Для ЭИС это, как правило, бизнес-моделирование.

Стадиифазы разработки требований:

– выявление;

– оценка целостности и реализуемости;

– документирование;

– согласование.

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

Уровнитребований к ПО.

– Бизнес-требования – определяют назначение ПО, описываются в документе о видении (vision) и границах проекта (scope).

– Пользовательские требования – определяют набор пользовательских задач, которые должна решать программная система, а также способы (сценарии) их решения.

– Функциональные требования – характеризуют предполагаемое поведение системы в виде набора определенных действий, которые описываются в системной спецификации (англ. system requirement specification, SRS).

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

К нефункциональнымтребованиям относятся:

– Ограничения на программные интерфейсы, в том числе к внешним системам.

– Требования к атрибутам качества.

– Требования к применяемому оборудованию и ПО.

– Требования к документированию.

– Требования к дизайну.

– Требования к безопасности и надёжности.

– Требования к показателям назначения (производительность, устойчивость к сбоям и т.п.).

– Требования к эксплуатации и персоналу.

– Прочие требования и ограничения (мобильность, автономность и т.п.).

Источники требований:

– Федеральное и муниципальное отраслевое законодательство (конституция, законы, распоряжения)

– Нормативное обеспечение организации (регламенты, положения, уставы, приказы)

– Текущая организация деятельности объекта автоматизации

– Модели деятельности (диаграммы бизнес-процессов)

– Представления и ожидания потребителей и пользователей системы

– Журналы использования существующих программно-аппаратных систем

– Конкурирующие программные продукты

Свойства требований

Методы выявления требований

– Интервью, опросы, анкетирование.

– Мозговой штурм, семинар.

– Наблюдение за производственной деятельностью.

– Анализ нормативной документации.

– Анализ моделей деятельности.

– Анализ конкурентных продуктов.

– Анализ статистики использования предыдущих версий системы.

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

Нефункциональные требования, неподдающиеся проверке на программном уровне, должны быть отдельно документированы. Во многих случаях они могут быть преобразованы из требования к продукту в требования к процессу. Например, нефункциональное требование, чтобы ПО не содержало «потайных ходов», может быть удовлетворено заменой на требование использовать парное программирование. Сложные требования безопасности авиационного программного обеспечения могут быть удовлетворены следованием процессу разработки DO-178B.

Текст предоставлен ООО «ЛитРес».

Прочитайте эту книгу целиком, на ЛитРес.