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

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

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

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

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

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

Спиральная модель является усовершенствованным вариантом эволюционной модели (модели 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).

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

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

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

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

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

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

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

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

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

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

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

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

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

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