А   Б  В  Г  Д  Е  Є  Ж  З  І  Ї  Й  К  Л  М  Н  О  П  Р  С  Т  У  Ф  Х  Ц  Ч  Ш  Щ  Ю  Я 


Зовнішній проект

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

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

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

Докладний зовнішній проект для кожної функції користувача повинен специфікувати наступні види інформації.

Детальний зовнішній проект кожної функції користувача повинен висвітлювати такі питання.

Фаза III Чи задовольняє зовнішній проект потребам користувача в поточний момент часу і чи слід виділяти кошти для завершення робіт.

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

Які види інформації специфицируются в зовнішньому проекті.

Хвильовий ефект в розробці модулів програмного вироби. Іншими словами, в даному випадку доцільно закінчити не тільки зовнішній проект, в.о. і весь внутрішній проект і тільки після цього прийматися за кодування програм.

Інший областю підвищення надійності є доведення до мінімуму складності зовнішнього проекту для того, щоб довести до мінімуму внутрішню складність системи, а також звести до мінімуму помилки користувача. Загальною думкою є те, що олюднений зовнішній проект повинен бути більш складним, включаючи складні системи повідомлень і автоматичне виправлення помилок.

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

Безпосереднє відношення до надійності має ще одне завдання - мінімізація складності зовнішнього проекту з метою зменшення внутрішньої складності майбутньої системи і мінімізації помилок користувачів.

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

Раніше зовнішній проект представлявся як що складається з двох процесів: первинного і докладного зовнішніх проектів. Допускаючи, що специфікація є ієрархічно організованою, ці два процеси просто представляють контрольні точки в проектуванні системи відповідно до ієрархії. На першому етапі описуються основні засоби (то, що відповідає розбиття на першому рівні), потім кошти, функції користувача і подробиці для кожної функції користувача.

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

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

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

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

Інший областю підвищення надійності є доведення до мінімуму складності зовнішнього проекту для того, щоб довести до мінімуму внутрішню складність системи, а також звести до мінімуму помилки користувача. Загальною думкою є те, що олюднений зовнішній проект повинен бути більш складним, включаючи складні системи повідомлень і автоматичне виправлення помилок.

Фаза проектування закінчується твердженням зовнішніх специфікацій, що надає зовнішньому проекту сталість і стимулює завершення внутрішнього проекту. Затвердження зовнішніх специфікацій означає заборони проводити зміни зовнішнього проекту, а лише стримує їх потік і дозволяє іншим функціональним групам виконувати свою роботу, не чекаючи подальшого уточнення проекту. Для внесення нових змін до затверджених зовнішні специфікації використовуються заявки на розширення (розд. Ці заявки необхідно ретельно вивчати, щоб не допустити небажаних змін календарних термінів робіт, особливо тих, які проводяться в рамках інших функцій, що реагують на додаткові зміни непередбачуваним чином. Вони унікальні по своїх достоїнствах як засіб спілкування між розробником - зовнішнього проекту, користувачем і програмістом. З одного боку, в них легко може розібратися користувач, який переглядає зовнішні специфікації. З іншого боку, вони служать ідеальними вихідними даними для програміста, який розробляє внутрішню логіку програми. Це подвійне застосування таблиць рішень скорочує число помилок перекладу. Наприклад, можна було б застосувати ці методи до таблиці на рис. 4 3 для перевірити, чи всі умови на вході передбачені. оскільки багато помилок в програмному забезпеченні викликаються непередбаченими умовами, такі механічні засоби дуже цінні.

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

У пошуках недоліків і помилок в структурі програми можна послідовно застосувати три методи: метод л плюс-мінус один, статичну перевірку і наскрізний контроль. Метод п плюс-мінус один - це офіційна перевірка проектної документації розробниками етапу п - 1 (авторами архітектури системи і зовнішніх специфікацій), які шукають помилки перекладу, і розробниками етапу п 1 (творцями зовнішнього проекту модуля), які перевіряють, наскільки здійснимо і зрозумілий проект, чи узгоджується він з мовою програмування і операційною системою, які передбачається використовувати.

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

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

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

Правильність програми доводиться тільки по відношенню до вхідного і вихідного твердженнями. Якщо вихідна твердження неправильне або неповно, може бути доведена правильність програми, а помилки в ній залишаться невиявленими. Крім того, помилки, зроблені на більш ранніх етапах проектування (цілі зовнішній проект), не будуть виявлені при доказі.

Щоб ще більше уточнити поняття зовнішнього і внутрішнього проектів, звернемося до рис. 77і 7.8. Деревоподібна структура, зображена на рис. 7.7 побудована за схемою, представленої на рис. 76і показує, де використовується кожен модуль. Будемо вважати, що а зовнішній контур кожного блоку з рис. 7.7 відображається сукупність параметрів, що належать відповідному модулю. Контур Р, зображений на рис. 7.8 на який відображаються всі параметри, видимі при розгляді програмного вироби ззовні відповідає зовнішньому проекту. Внутрішні специфікації описують параметри, що належать іншим контурам блоків.

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

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

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