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

– легко определить сроки и затраты на проект.

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

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

Итерационная модель

Альтернативой последовательной модели является так называемая модель итеративной и инкрементальной разработки (англ. iterative and incremental development, IID), получившей также название эволюционной модели.

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

По выражению Т. Гилба, «эволюция – прием, предназначенный для создания видимости стабильности. Шансы успешного создания сложной системы будут максимальными, если она реализуется в серии небольших шагов и если каждый шаг заключает в себе четко определённый успех, а также возможность „отката“ к предыдущему успешному этапу в случае неудачи. Перед тем, как пустить в дело все ресурсы, предназначенные для создания системы, разработчик имеет возможность получать из реального мира сигналы обратной связи и исправлять возможные ошибки в проекте».

Недостатки подхода IID:

– отсутствие целостного понимания возможностей и ограничений проекта на ранних итерациях;

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

– снижение добросовестности специалистов при выполнении работ (всё равно всё можно будет переделать и улучшить позже).

Различные варианты итерационного подхода реализованы в большинстве современных методологий разработки (RUP, MSF, XP).

Спиральная модель

Спиральная модель (англ. 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).