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



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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Формирование требований и проектирование программной системы

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

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

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

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

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

– выявление;

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

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

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

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

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

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

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