Глава 19
Конструювання, тестування
і розгортання продукту
Існує багато форм утілення проектних рішень, але одна з них, що вважається кінцевою формою матеріалізації проекту, призначена для розгортання продукту в користувачів. Усі невизначеності знімаються, коли програмне забезпечення компонується заради демонстрації функцій, зовнішнього вигляду, поводження, необхідних користувальницьких дій, допомоги, навчання, часу відгуку, надійності, практичності й інших програмних можливостей.
Етап реалізації називають по-різному - зборкою, програмуванням, конструюванням і, крім іншого, розробкою. Тут використовується термін "конструювання". Рамки етапу конструювання охоплюють проект реалізації, реалізацію, тестування компонентів, системне тестування й інші види тестів, користувальницькі приймальні іспити, а також остаточну оцінку продукту на предмет задоволення вимог (мал. 19.1)
У процесі конструювання основна мета полягає в тому, щоб завершити перехід від проекту і прототипу до завершального продукту, що як і раніше задовольняє критеріям і чеканням, установленим на більш ранніх етапах. При конструюванні можливе проведення завершальних ітерацій і тонке настроювання компонент ПІ, однак якщо проектна бригада працювала з ретельністю, не слід очікувати численних ітерацій проектних рішень. Може існувати і чимало проблем практичності, причому не повинно бути ніяких перешкод, що серйозно впливають на терміни, обмеження і вимоги.
У цій главі розглядаються наступні питання.
" Забезпечення плавного переходу від проектування до етапу конструювання.
" Проект реалізації, програмування і тестування компонентів.
" Системний і інший види тестування.
" Труднощі, рішення й уроки
" Поступки, компроміси і несподіванки.
" Розгортання.
" Конструювання продукту згідно проекту.
Вчасно завершення конструювання готовий робітник продукт, що задовольняє встановленим для нього вимогам і критеріям.
Забезпечення плавного переходу від
проектування до етапу конструювання
Вимоги знаходять своє втілення в документації і конкретних проектні рішеннях. Конкретні проектні рішення матеріалізуються у виді специфікацій макетів, розкадрування, прототипи й інформації, що усе ще знаходиться в голова: учасників проектної бригади. Обсяг робіт зі створення ЇЙ може змінюватися ог 30 до 50% від загального обсягу робіт із програмного продукту в залежності від тип; продукту, його апаратної і програмної архітектури, а також від інфраструктури Розроблювачі програмних продуктів звичайно зіштовхуються з великими обсягам! програмування ПІ, строгими вимогами до ПІ, обмеженнями на чи терміни обмеженими професійними ресурсами, що впливають на продуктивність конструювання ПІ.
Корисне правило. Ніколи не виходить виконати завдання настільки легке, як представляється.
Експерти затверджують, що фактичний календарний час програмування складає всего 15% від усього терміну розробки. Це може бути справедливо для деяких невеликих проектів, однак укластися в дану цифру для середньо- і великомасштабних проектів навряд чи удасться.
Якісний проект скорочує етап конструювання. Суще-ствует багато ускладнюють факторів, що перетворюють скромну оцінку в значно велику цифру, - порядок величини росту в логіку, деталях і складності не повинний дивувати. Крім того, при роботі зі складними і вимогливими мовами програмування і засобами реалізації звичайно приходиться зіштовхуватися з деякими дивинами в поводженні мов і засобів. Аналіз подібного поводження вимагає часу і хитрувань, а також концентрації уваги на деяких елементах чи керування перемальовування екранів. На щастя, "чудності" у мовах і засобах проробляються на ранніх етапах або для них маються відомі рішення, засновані на досвіді.
Проектна бригада враховує те, які професійні навички необхідні і які навички володіють члени бригади у відношенні застосовуваних у проекті мов і засобів розробки. Бригада також повинна знати і чуйно реагувати на такі фактори, як стислі строки розробки, стабільність вимог, повнота і якість вихідних проектних рішень.
Корисне правило. ПО користувальницького інтерфейсу аналогічно будь-якому іншому ПО - тільки складніше.
Перехід від специфікації ПІ. Конструювання ПІ точно в соответ-ствии з документально оформленою специфікацією - складна задача, але небагато все-таки залишається на частку уяви. Навіть дуже деталізовану і добре написану специфікацію важко прочитати і зрозуміти через обсяг інформації, що необхідний, щоб пояснити статичний і динамічний зовнішній вигляд і поводження ПІ, уведення користувальницької інформації, а також методи взаємодії користувача із системою, що маються в наявності для доступу до можливостей ПО.
Після того як бажаний результат усвідомлений, проектна бригада повинна зробити вирішальний стрибок, щоб перетворити необхідний результат у конкретні дії, які необхідно виконати з використанням наявних у распоря-жении бригади мов і засобів конструювання. Найчастіше цим стрибком прихо-дится переборювати дуже велику прірву засобів і обмежень, що з легкістю підтримують саме небажаний результат.
Перехід від прототипів ПІ. Найлегший спосіб переходу - від існуючих прототипів. Однак навіть при розробці інтерактивних прототипів з використанням передбачуваних засобів розробки продукту можуть існувати методи створення прототипів, що володіють наступними особливостями.
" Прототип спроектований, але ще не реалізований яким-небудь способом.
" Прототип реалізований як імітаційна модель ПІ, але навіть приблизно не схожий на підхід до реалізації ПІ.
" Реалізований повноцінний прототип (тобто основні алгоритми і/чи структури даних працюють, але не вважаються прийнятними для реалізації в рамках продукту по тим чи іншим причинам).
Корисне правило.
" Подбайте про те, щоб розробка функціональних прототипів, аналіз і припасування найбільш важких алгоритмів і структур даних виконувалися тими, хто повинний їх реалізовувати.
" Оскільки мови і засоби звичайно являють собою не зовсім те, що говориться про їх у рекламі, подбайте, щоб межі їхнього використання і властиві їм обмеження були усвідомлені й адекватний образ враховані в планах.
" Оціните, яка частина ПО прототипи може бути повторно використана для продукту і спирайтеся на відповідні припущення.
Важкі випадки. Сутужніше всего передати інформацію, що залишається в головах розроблювачів. Незважаючи на обсяг і складність проектних деталей, завжди залишається деяка інформація, не представлена в чи специфікації прототипі. Розробка виявляється в ще гіршій ситуації, коли проектувальники переходять на інші проекти, а їхні знання і проектні задуми ідуть разом з ними. Компенсувати загублені знання завжди важко.
Корисне правило. Протягом етапу конструювання проектувальників варто тримати поблизу.
Кращий випадок. У кращому випадку в наявності мається специфікація і прототип, а перші проектувальники - носії недокументированных знань - є частиною бригади по реалізації. Подібну ситуацію варто планувати і керувати нею. Це допомагає передачі знань і чіткому установленню відповідальності за проект.
Деталі, деталі і ще раз деталі. На даному етапі розробки усі во-просы, що стосуються інших видів ПО, застосовні й у випадку ПО користувальницького інтерфейсу (сюди відносяться обсяг роботи, якість, продуктивність, навички, терміни). Приходиться мати справа з всіма аспектами поводження ПО, включаючи особливі ситуації, комбінації вхідної і вихідної інформації, обробку помилок і сооб-щения. Питання глибини і широти прототипирования більше не актуальні. Також зачіпаються проблеми взаємодії з не интерфейсными функціями і функ-циями підтримки.
Корисне правило.
" Остерігайтеся компромісів, викликаних несподіванками і стислими строками.
" Уникайте іти на компроміс у відношенні цілісності проекту і требо-ваний.
Проект реалізації, програмування і тестування компонентів
Навіть у припущенні, що для побудови ПІ мається вся необхідна і достатня проектна інформація, ще потрібно пройти чималий шлях, щоб завершити конструювання і розгортання продукту в користувачів. Потрібно виконати проект реалізації, програмування, компонентне тестування й інші види тестування, що покликані продемонструвати, чи задовольняє продукт вимогам і чи може він вважатися готовим до розгортання.
Найчастіше продукти підходять до запланованому терміну завершення іспитів з багатьма невирішеними проблемами. Проблеми можуть бути зв'язані з дефектами функцій, ПІ, практичності, продуктивності й інших типів недоліків. Найчастіше деякі вимоги задовольняються частково, у результаті чого звичайно виноситься формальне й остаточне позитивне чи негативне рішення про тім, чи приступати до розгортання продукту, а якщо приступати, те при яких умовах.
Проект реалізації. Проект реалізації, спрямований на створення ПІ, що забезпечує доступ до можливостей ПО з використанням різних ме-тодов, стосується способів здійснення цієї задачі за допомогою алгоритмів, методів, структур даних і джерел даних набору інструментальних засобів програмування і розробки. У кінцевому рахунку, проект реалізації використовує один чи кілька мов програмування, інструкції мови, компоненти набору інструментальних засобів, а також команди і ресурси баз даних і ОС.
Розглянуті питання включають внутрішню структуру, модульность, потік керування, межмодульные інтерфейси і логіку для конкретних функціональних і інформаційних можливостей ПО, а також можливостей програмного ПІ. На цьому рівні необов'язковий розгляд конкретних інструкцій, досить загальних підходів до способів рішення представлених питань.
Корисне правило. Щоб задовольнити вимоги, досліджуйте альтернативи і здійснюйте ітерації.
Реалізація. Вибір, організація, написання й упорядкування інструкцій і коментарів мови програмування й ОС для досягнення конкретного результату звичайно називають програмуванням. Для розробки програмних інструкцій і ресурсів на зразок графічних файлів застосовуються призначені для цього інструментальні набори засобів розробки програм. Використання програмних інструкцій і інструментальних засобів дозволяє матеріалізувати проект реалізації і проект ПІ.
На шляху виконання цієї роботи зустрічається безліч труднощів (вибір і написання відповідних інструкцій і звертань до ОС, методи і деталі реалізації, ефективність використання ресурсів і т.д.). Типові задачі включають використання правил іменування, прийомів програмування, бібліотек повторно використовуваних компонентів і методів, контроль і керування змінами ПО, а також відстеження дефектів.
Навіть використання засобів розробки ПІ на основі графічних мов програмування четвертого і п'ятого поколінь (4GL і 5GL відповідно) не виключає написання програм, що реалізують наступні функції.
" Відкриття, установка стану і закриття чи екрана вікна.
" Розміщення чи екрана вікна стосовно іншого чи екрана вікну.
" Установка фокуса й установка стану вибору.
" Ініціалізація елемента керування.
" Перевірка допустимості значення полючи (для введення і висновку даних).
" Тестування вмісту елементів керування.
" Розблокування і блокування елементів керування.
" Поводження, зв'язане з обробкою подій, инициируемых чи клавіатурою покажчиком.
" Зворотний зв'язок з користувачами, обробка помилок і повідомлення.
Корисне правило.
" Створення прототипів на ранніх етапах розробки допомагає виявити огра-ничения мов і засобів, а також перевірити методи роботи ПІ. Починати створення прототипів випливає якомога раніше .
" Щоб задовольнити вимоги, досліджуйте альтернативи і здійснюйте ітерації.
На етапі конструювання розроблювачі переборюють щоденні проблеми контролю програмного коду, резервного копіювання ПО, використання извест-ных платформ розробки, ефективності, супроводи і документування ПО. На даному етапі продовжуються перевірки за столом, ревізії якості і наскрізний контроль програмного коду.
Корисне правило. Подбайте про використання засобів керування версіями для керування програмним кодом ПІ й іншими складовими програмного продукту.
По можливості варто передбачати проблеми (наприклад, час відгуку, підданий помилкам ПО і надійність). При прояві обмежень ОС чи мови програмування необхідно розробити обхідні шляхи.
Корисне правило. Кожній мові програмування й інструментальному засобу присущи свої проблеми.
Нарощування програмного коду. Фактична розробка проводиться з використанням нарощуваного і наскрізного підходу до конструювання. Аналогічно тому, як проект і прототипи ПІ розробляються итеративно з нарощуванням можливостей, повинний розроблятися і реальний продукт. Іншими словами, спершу здійснюється невеликий крок у розробці з наступним тестуванням, потім ледве більший крок у розробці з тестуванням усього, що розроблено на сучасний момент, і так доти , поки розробка не буде виконана цілком. Необхідно зосередитися на якості програмного коду, якості ПІ, практичності, часу відгуку, надійності і задоволенні інших вимог. Якщо це ще не зроблено, подбайте про документування спеціальних алгоритмів і методів у міру розробки ПО. Згодом вам може знадобитися модифікувати програмний код.
Тестування компонентів. Точне визначення компонентного тестування (іноді називаного також блоковим чи модульним тестуванням) говорить, що це тестування, що вимагає наскрізної перевірки в передбачуваному середовищі використання коректності таких можливостей продукту, як функції продукту, ПІ, доступ до бази даних, APІ (Applіcatіon Programmіng Іnterface - інтерфейс прикладного програмування) і т.д. При цьому необхідна інтеграція з всіма аспектами програмного чи пакета системи. У дійсності потрібно продемонструвати, що конкретна функція працює відповідно до її специфікації і/чи так, як передбачається і потрібно.
Найчастіше буває важко створити реальне користувальницьке середовище внаслідок з-стояння зв'язаного з нею ПО, недостатнього знайомства з засобами розробки і відсутності доступу до реальних виробничих баз чи даних мережам. Час, необхідне для настроювання подібного середовища, може бути непомірно великим через обмежені чи ресурси недостатнього знання особливостей середовища.
Корисне правило. Якщо реальне середовище не може бути створена на ранніх етапах розробки, необхідно врахувати в календарному плані час на створення середовища, на виконання додаткових тестів і на керування непередбаченими ситуаціями.
Якщо, наприклад, доступ до деякої функції здійснюється за допомогою Web-броузера, компонентне тестування функції не може вважатися закінченим доти , поки вона не буде протестирована в середовищі цього Web-броузера. Для тестування функціональних можливостей досить оцінки функцій у рамках програми перегляду апплетов, що, однак, не в змозі продемонструвати обмежень методів доступу ПІ, диктуемых Web-броузером.
Багато дефектів ПІ надзвичайно важко усунути. Іноді проблеми виникають через взаємодію між можливостями мови, системи й інструментарію, часом причина проблем криється в послідовності і синхронізації інструкцій.
Корисне правило. Виявляйте і розв'язуйте проблемы по ходу розробки, особливо це стосується передбачуваного користувальницького середовища. Якщо проблему не удається вирішити відразу, документуйте її і знову поверніться до неї пізніше.
Критерії завершення компонентного тестування. Стосовно до кожного програмного компонента необхідно вміти оцінити завершенность етапу компонентного тестування. Щоб виключити неоднозначності, застосовуються наступні специфічні критерії успішного виходу з процесу компо-нентного тестування:
" заплановані користувальницькі функції доступні за допомогою ПІ (тобто до всіх доступних користувачів можливостям можна звернутися за допомогою використання екранів, команд, зв'язків, наборів клавіш і т.д.)
" і всі можливості ПІ працюють на рівні компонентних тестів (тобто функції виконуються коректно з погляду кращого розроблювача і його колег - тестировщика)
" і доступ до допомоги/навчанню/EPS (Electronіc Publіshіng System - електронна видавнича система) інтегрований у систему і працює коректно (довідкова й інша користувальницька інформація доступна і коректна)
" і збільшення дефектів мінімально (відсутність відомих дефектів неза-висимо від серйозності)
" і нарощування програмного коду мінімально й обумовлено тільки виправленням дефектів (програми не розростаються без видимої причини)
" і іспиту практичності були проведені разом з користувачами і їхніми результатами відповідали встановленим критеріям (наприклад, задоволеності користувачів задачею і т.д.)
" і продуктивність (час відгуку) була оцінена чи обмірювана і виявилася в межах, установлених критеріями
" і розроблювач упевнений, що ПО готово до початку системного тестування (розроблювач і його коллега-тестировщик не можуть більше знайти дефектів у програмному коді)
" і час, виділений на програмування, минуло (у противному випадку усі обертається поліпшенням/уточненням коду без необхідності).
Розповсюджені проблеми програмування. Представляється, що деякі дефекти поводження ПІ з завидною регулярністю повторюються в багатьох програмних продуктах.
" Фокус клавіатури не встановлюється саме в тих місцях екрана, у яких потрібно користувачу.
" Використання клавіші табуляції приводить до утрати фокуса клавіатури на екрані (іноді він більше не повертається).
" Упущена зворотний зв'язок за часом відгуку (піскова годинник) чи індикація ходу процесу.
" Нестандартне поводження для клавіші <Enter> чи покажчика миші при подвійному щиглику.
Дані питання спеціально включаються в інформацію з чи проекту прототипу разом з підходом, присвяченим тому, яким образом остаточна реалізація справляється з цими проблемами.
Подібний підхід мінімізує утрати від тривіальних дефектів ПІ і допомагає тримати в центрі уваги функції, практичність, продуктивність і надійність.
Корисне правило. Зверніть увагу на етап сертифікації продукту, що покликаний продемонструвати, що всі стандарти, інструкції і деталі, що стосуються ПІ, реалізовані коректно.
Орієнтована на користувачів проектна бригада несе відповідальність і звітує за успішне виконання даного етапу до виходу з етапу компонентного тестування.
Оцінка практичності в процесі програмування і ком-понентного тестування. Як звичайно, у процес програмування і ком-понентного тестування утягують користувачі. Завжди існують подробиці, які необхідно обговорити з користувачами (наприклад, обновлювана графіка і компонування, припасування розмірів полів і стовпців, а також незліченна кількість інших проектних фрагментів і несподіванок, що можуть не розглядатися користувачами детально). Участь користувачів приносить відчутну вигоду при необхідності йти на поступки і приймати рішення на дуже низькому рівні деталізації проекту, враховуються рекомендації користувачів щодо важливих деталей проекту. Подробиці розглядаються з чи низкою високою точністю в залежності від ситуації. По можливості використовуються евристичні, неформальні і формальні методи оцінки.
Системний і інший види тестування
Системне, інтеграційне (компоновочное) і інші види тестування (мал. 19.2) призначені для перевірки можливостей продукту в більш широкому середовищі разом з іншим ПО, що функціонує в цьому ж середовищі і конкуруючим за загальні ресурси з продуктом, що випробується. Крім того, ПО проходить перевірку в різних умовах експлуатації, зокрема при граничних і неприпустимих значеннях вхідних даних, стресових вхідних навантаженнях і незвичайних комбінаціях вхідних даних.
Оцінка ПО в передбачуваному середовищі. До цього моменту ПО виразно функціонує в передбачуваному середовищі. У наявності маються ПІ, засобу допомоги і навчання, а також інші артефакти користувальницького досвіду. Програмне забезпечення може не бути полнофункциональным, цілком налагодженим чи надійним, навіть якщо воно пройшло компонентне тестування. Звичайно необхідно усунути ще багато залишкових дефектів. Більш ясними стають питання продуктивності і часу відгуку.
Участь користувачів у розробці продовжується. Формальні оцінки практичності проводяться в лабораторії і, по можливості, у користувальницькому середовищі. На ранніх етапах тестування повний прогін задачі не завжди здійснимо, однак він стає можливим на завершальних стадіях подібного тестування.
Корисне правило. Подбайте про те, щоб бригада, що виконує системне тестування, була підготовлена до роботи з платформою і її базовими стилями ПІ.
Оцінка довгострокового використання. В міру придбання системою стабільності стає можливої робота користувачів у режимі ими-тации протягом більш тривалих періодів часу й у більш широких ка-лендарных тимчасових рамках. Проведені до цього іспиту практичності носи-ли відносно короткочасний характер і були спрямовані на проблеми крат-косрочного навчання і використання системи. Однак користувачі, що випробують ПО протягом декількох тижнів по кілька годин у день, звертають увагу на проблеми іншого роду - довгострокового навчання і використання. У процесі такої роботи з ПО проходять тестування всі аспекти системи, включаючи рідко використовувані галузі, незначні, але істотні галузі і т.д.
Корисне правило. У процесі проведення системного тестування залучайте невеликий колектив користувачів для оцінки ПО протягом більш тривалого часу.
Користувачі виконують заздалегідь визначені тестові прецеденти, здійснюють незаплановане тестування і забезпечують організований зворотний зв'язок із проектною бригадою.
Труднощі, рішення й уроки
Області ризику. Оскільки етап реалізації відрізняється порівняно великою тривалістю, складністю і масою деталей, починають виявлятися деякі нові види ризику. В перших, стан реалізації і тестування по більшій частині невідомо. До інших областей ризику відносяться час відгуку, надійність складного ПО і навчання нового персоналу.
Плани. Календарний план повинний включати стільки етапів, скільки необхідно всій бригаді, щоб знати, де вона знаходиться в процесі реалізації. Один з ефективних методів планування полягає в тім, щоб, відштовхуючи від кінця планованого періоду, рухатися до його початку. При цьому відслідковується завершення конкретних функцій ПІ й основних компонентів ПО.
Необхідно стежити за фактичним ходом процесу в порівнянні з чеканнями просування до мети. Твердження, що завдання виконане на 80 чи 90% може бути неточним, якщо на останній отрезок роботи приходиться від 80 до 90% допол-нительного календарного часу. Реальність сувора, тому планувати роботу випливає невеликими частинами, також необхідно постійно звірятися з планом, щоб можна було переконатися в його рівномірному і точному виконанні і забезпечити коректну звітність про хід робіт.
Корисне правило. Щоб підвищити свої шанси на успіх, варто планувати роботу, відслідковувати виконання планів і формувати звітність про стан проекту.
Час відгуку. Подбайте про повсюдне встановлення зворотного зв'язку з користувачами. Для всіх команд, виконання яких може виявитися тривалим, передбачите використання графічного символу піскових годин.
Корисне правило. Ніж пізніше ви встановите зворотний зв'язок з користувачами, тим дорожче вам це обійдеться.
Залучення необхідних фахівців.Післятогоякроздався"сигнальнийпостріл"пропочатокреалізації,необхідноматиусвоємурозпорядженніпідготовленийперсонал,здатнийнадатизамовникамсамете,щовониочікують.Вартоуникатитакогопідходу,яккадровезабезпеченняточневтермін.Дляуспішноговиконанняпроектубригадінеобхідноволодітивсіманеобхідниминавичкамиізнаннями,щонайчастішевиявляєтьсянереальним.
Оскількивмірунаближеннядоетапуконструюваннябригадарозширюється,дляпідготовкиновихчленівбригадивартовикористовуватирозкадрування,навчання,наскрізнийконтроль,атакожбібліотекидокументаціїіпрезентацій.
Кориснеправило.Дляосмисленогозв'язуваннязнаньупроектнійдокументаціїіпрототипахкорисновикористовуватигіперпосилання.
Партнерство.Вмірурозширенняпроектноїбригадифахівці,безумовно,повиннібутипідготовленіувідношенніпродуктуівикористовуванихзасобів,аперсоналповиннийкупуватиакції,тобтобутизацікавленимупродукті.Формуваннябригадиізв'язанізнимаспектимаютьважливезначеннядляпідвищенняступеняприхильності,необхідноїдляуспішногостворенняпродукту.
ВідділенняПІвідбізнес-логіки.ЗвичайневідділенняпрограмногозабезпеченняПІвідбізнес-логіки-непростазадача.Воназдійсненна,алезанеюкоштуєдодатковийчаспроектуванняівитратинареалізацію.Наприклад,якщобізнес-правилаконтролюютьдопустимістьзначеньполівіваріантіввиборуелементівменю,необхідноспроектуватиіреалізуватимеханізмрішенняцієїзадачіпозачистоюлогікоюПІ.
Крімтого,створенняПОзподіломПІібізнес-логікиволодієпреимуще-ствомпотенційнобільшнезалежноїрозробкиіповторноговикористанняпрограмнихкомпонентів.
Керуваннявимогамиізмінами.Зчасомділовіпотребиікористувачізмінюються,з'являютьсяновіідеїщодопроектуванняіреалізаціїсистеми.НацьомупізньомуетапірозробкибригадаповиннапротивитисявнесеннювипадковихзмінуПОдляудосконаленнябізнес-чипроцесіввіншихцілях.Необґрунтованізміниозначають,щовдійсностівнихнемаєнеобхідностідляданоїверсіїпрограмногопроекту.Вониможутьпочекатидонаступноїверсії.
Кориснеправило.Пізнішізміниповиннівідіграватиістотнурольуділовомучиуспіхууспіхупроекту,щобїхможнабулосерйознорозглядати.Перетвореннянапізньомуетапірозробкизв'язанізризикомзатримкивнаданніпроектукористувачамійогоорганізації,щофінансує.
Продуктивність.Допроцесуконструюваннязастосовуютьсярізніметрики.Нижчеприведеніприкладидеякихметрик,щомаютькритичнезна-чениедлявідстеженняпросуванняйуспіхупродукту.
"Навігаційнаструктураміжсистемою,екранамиідовідкамиреалізована.
"Екраниідовідкиспроектованііреалізованізвикористаннямзасобіврозробки.
"Підтримкадопомогийексплуатаціїспроектованаіреалізованазвикористаннямзасобіврозробки.
"Користувальницьківізуальніданііметодиреалізовані.
"Частотадефектівіїхнюсерйозністьлежатьуприпустимихмежах.
"Відсотокпереробокневеликий.
Повторневикористання.Йоговартопланувати,проектуватиівідслідковувати.Продовжуйтепошукприкладіввихідногопрограмногокодудляметодівпроектуванняіреалізації,використовуванихупроекті.Ефективнеповторневикористанняповиннебутиобмірюванеівознаграждено.
Кориснеправило.Уникайтенесистемних,випадковихпідходів.ВмірузбільшеннябригадиіростиобсягуПОвиконатицюрекомендаціюстаєсутужніше.Помнете,щоцільскладаєтьсявздачіпроекту.
Документуванняпрограмногокоду.Оскількифахівці,на-чинавшиереалізацію,якправило,неберутьучастьуреалізаціїісупроводінаступнихверсій,документаціявідіграєістотнурольупоясненніпроисходящегодлятих,хтоприходитьназмінупершимрозроблювачам.Наступнірозроблювачіможутьвиявитисяменшдосвідченими,чимви.