28. Модель етапу пост архітектури.

Модель этапа постархитектуры используется в период, когда уже сформирована архитектура и выполняется дальнейшая разработка программного продукта.

Основное уравнение постархитектурной модели является развитием уравнения предыдущей модели и имеет следующий вид:

ЗАТРАТЫ = А х К~req х РАЗМЕРB х Мр +3ATPATЫauto [чел.-мес],

где

коэффициент К~req учитывает возможные изменения в требованиях;

показатель В отражает нелинейную зависимость затрат от размера проекта (размер выражается в KLOC), вычисляется так же, как и в предыдущей модели;

в размере проекта различают две составляющие — новый код и повторно используемый код;

множитель поправки Мр зависит от 17 факторов затрат, характеризующих продукт, аппаратуру, персонал и проект.

Изменчивость требований приводит к повторной работе, требуемой для учета предлагаемых изменений, оценка их влияния выполняется по формуле

К~req =l + (BRAK/100),

где BRAK — процент кода, отброшенного (модифицированного) из-за изменения требований.

Размер проекта и продукта определяют по выражению

РАЗМЕР = PA3MEPnew + PA3MEPreuse [KLOC],

где

PA3MEPnew — размер нового (создаваемого) программного кода;

PA3MEPreuse — размер повторно используемого программного кода.

Формула для расчета размера повторно используемого кода записывается следующим образом:

PA3MEPreuse =KASLOC x ((100 - AT)/100) x (AA + SU + 0,4 DM + 0,3 CM + 0,3 IM)/100,

где

KASLOC — количество строк повторно используемого кода, который должен быть модифицирован (в тысячах строк);

AT — процент автоматически генерируемого кода;

DM — процент модифицируемых проектных моделей;

CM — процент модифицируемого программного кода;

IM — процент затрат на интеграцию, требуемых для подключения повторно используемого ПО;

SU — фактор, основанный на стоимости понимания добавляемого ПО; изменяется от 50 (для сложного неструктурированного кода) до 10 (для хорошо написанного объектно-ориентированного кода);

АА — фактор, который отражает стоимость решения о том, может ли ПО быть повторно используемым; зависит от размера требуемого тестирования и оценивания (величина изменяется от 0 до 8).

29. Структурний аналіз.

Структурний аналіз — метод дослідження статичних (сталих) характеристик ієрархічно впорядкованої системи шляхом виділення в ній підсистем і елементів різного рівня і визначення відносин і зв'язків між ними. Об'єктами дослідження структурного аналізу є різні варіанти структур, які можуть бути виявлені в процесі декомпозиції системи, що дозволяють всебічно оцінити властивості системи в цілому.

30. Основи проектування програмних систем.

Проектування - це етап життєвого циклу розроблення програмних систем, наступний після інженерії вимог. Завданням цього етапу є перетворення побажань замовників системи, які ми подали як моделі вимог, у проектні рішення, що забезпечать здійснення згаданих побажань у формі відповідної системи програмування. Таким чином, під час проектування виконується трансформація простору вимог у простір проектних рішень. При цьому можна виділити процеси, котрі можна вважати відносно незалежними одне від одного і виконувати як послідовно, так і паралельно, окремими командами виконавців. Це такі процеси:

• концептуальне проектування полягає в уточненні розуміння й узгодження деталей вимог;

• архітектурне проектування полягає у визначенні головних структурних особливостей системи, яку будують;

• технічне проектування полягає у відображенні вимог середовища функціонування і розроблення системи та у визначенні всіх конструкцій як композицій компонент;

• детальне проектування полягає у визначенні подробиць функціонування та зв’язків для всіх компонент системи.

В основі проектування будь-якого продукту лежить парадигма подолання складності загального завдання шляхом декомпозиції цільового продукту на окремі його складові або компоненти. Це твердження діє і для програмних систем як продуктів програмної інженерії.