|
На этапе программирования и тестирования выполняется программиро- вание, тестирование, сборка и квалификационные испытания программных средств, сборка и квалификационные испытания инкремента (соответствует ра-
ботам 5.3.7 – 5.3.11 на рис. 7).
На этапе ввода в действие и обеспечения приемки выполняется ввод ин- кремента в действие в среде эксплуатации и обеспечение его приемки пользо- вателем (соответствует работам 5.3.12 – 5.3.13 на рис. 7).
Достоинства инкрементной модели:
необходимость изначального формулирования характеристик системы (требований к ней);
пригодность для использования промежуточного продукта;
естественное разделение системы на наращиваемые компоненты (ин- кременты);
возможности наращивания привлекаемого персонала и средств.
Использование инкрементной модели затруднено в следующих случаях:
требования к объектам определены недостаточно точно;
необходимо предусмотреть сразу все возможности системы (реализо- вать все требования к ней);
возможны текущие изменения требований к системе;
возможности привлечения ресурсов (средств или персонала) на дли- тельный период ограничены;
предполагаются скорые изменения в технологиях работ.
С вышеперечисленными ограничениями связаны основные недостатки ин- крементной модели.
Эволюционная модель
При использовании эволюционной фундаментальной модели ЖЦ, как и в предыдущем случае, система разрабатывается в виде последовательности кон- струкций (версий). Однако требования изначально определяются только час- тично и уточняются в каждой последующей версии.
При разработке каждой версии, как правило, используется каскадная мо- дель ЖЦ с возможностью частичного перекрытия работ или задач.
Работы и задачи процесса разработки обычно выполняются многократно. Процессы сопровождения и эксплуатации могут быть реализованы параллельно с процессом разработки. Процессы заказа, поставки, вспомогательные и орга- низационные процессы выполняются параллельно с процессом разработки.
Один из вариантов эволюционной модели приведен на рис. 39. На данном рисунке используются те же этапы процесса разработки, что и на рис. 38.
Достоинства эволюционной модели:
итерационное определение возможностей системы (требований к ней);
пригодность для использования промежуточного продукта;
естественное разделение системы на наращиваемые компоненты;
привлечение персонала и средств по мере необходимости;
необходимая обратная связь с пользователем для полного понимания требований;
упрощение надзора за изменением технологии.
Использование эволюционной модели затруднено в следующих случаях:
все возможности системы (требования к ней) определены изначально;
возможности долговременного привлечения ресурсов (например средств или персонала) ограничены.
С вышеперечисленными ограничениями связаны основные недостатки эволюционной модели.
Версия 1
Рис. 39. Вариант эволюционной модели по ГОСТ Р ИСО/МЭК ТО 15271–2002
Примеры адаптации ИСО/МЭК 12207
Приложение D стандарта ИСО/МЭК ТО 15271 содержит несколько приме- ров адаптации требований стандарта ИСО/МЭК 12207 к условиям конкретного применения. Данные примеры основаны на использовании макетирования. В
настоящее время макетирование достаточно часто применяется в современных реализациях моделей ЖЦ.
Пример макетирования небольшой системы
При разработке небольших систем полное применение стандарта ИСО/МЭК 12207 может оказаться излишним, поскольку потребует нецелесооб- разных затрат времени, стоимости и других ресурсов. В этом случае наиболее экономически эффективным решением при выборе модели ЖЦ может оказать- ся макетирование (прототипирование) системы.
На рис. 40 приведен пример адаптации стандарта ИСО/МЭК 12207 к моде- ли ЖЦ, основанной на макетировании небольшой системы. На данном рисунке в скобках приведены номера работ или процессов вышеназванного стандарта, входящих в состав соответствующих стадий модели ЖЦ.
Рис. 40. Пример адаптированной модели ЖЦ, использующей макетирование, по ГОСТ Р ИСО/МЭК ТО 15271–2002
Основой эффективного макетирования системы является максимально возможная детализация на ранних стадиях проекта (анализ требований к систе- ме и проектирование системной архитектуры). Данные стадии выполняются в модели ЖЦ один раз и только в том случае, если ПС входит в состав системы. Однократное выполнение этих стадий достигается за счет тесных связей разра- ботчиков с пользователями проекта. Требования к системе, в первую очередь,
функции системы и внешние интерфейсы определяются пользователями в на- чале ЖЦ, деловые процессы уточняются при проведении пользователем серии оценок прототипов системы.
Рассматриваемая модель ЖЦ основана на применении эволюционной стра- тегии разработки ПС, в которой при создании каждой версии ПС вместо кас- кадной модели используется прототипирование. При разработке каждого про- тотипа уточняются требования к нему. Для быстрого проектирования и сборки ПС (работы 5.3.5, 5.3.6, 5.3.8 процесса разработки ИСО/МЭК 12207, см. рис. 7, пособия), а также оперативного наращивания, изменения и уточнения ПС ис- пользуется инструментальная система 4GL (Fourth Generation Language – язык программирования четвертого поколения). Языки 4GL осуществляют автома- тическую кодогенерацию ПС, поэтому работа 5.3.7 процесса разработки (про- граммирование и тестирование ПС, см. рис. 7) в модели ЖЦ не учитывается.
Проверка и оценка каждого макета (прототипа) осуществляется пользова- телем в реальной эксплуатационной среде.
В модели определен фиксированный период проведения макетирования и произвольное количество итераций.
Разработчик ПС контролирует макетирование с помощью:
установления приоритетов требований к ПС;
ужесточения ограничений временного интервала;
привлечения конечного пользователя.
Пример ускоренной разработки приложения
В данном примере макетирование (прототипирование) применяется для полной разработки большой системы. Для ускорения разработки используется RAD-модель ЖЦ (RAD – Rapid Application Development – ускоренная разработ- ка приложения).
Для успешной реализации RAD-модели разработчики должны тесно взаи- модействовать с конечными пользователями, иметь навыки работы с соответст- вующими технологиями и инструментальными средствами, а область примене- ния приложения не должна быть критичной.
Do'stlaringiz bilan baham: |
