Правила Екстремального Програмування

Основні правила Екстремального Програмування:

Планування

• Пишуться User Stories.

• Власне план створюється в результаті Планування Релізу.

• Випускати часті невеликі Релізи.

• Вимірюється Швидкість проекту.

• Проект ділиться на Ітерації.

• Кожна ітерація починається зі зборів по плануванню.

• Люди постійно міняються завданнями.

• Щодня починається з ранкових Зборів стоячи. 

• XP правила коректуються якщо щось не так.

37. Основні правила Екстремального Програмування: дизайн

Дизайн

• Простота.

• Обов'язково вибрати Метафору системи.

• Використовувати CRC карточки для дизайну.

• Писати Пробні рішення для зменшення рисків.

• Не додавати ніяких функцій раніше часу.

• Рефакторіть безжально.

Вибирайте найпростіше рішення

"Ускладнювати - просто, спрощувати - складно" Народна мудрість

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

Рефакторіть чужий код якщо він здається вам складним. Якщо щось виглядає складним - це вірна ознака проблеми в коді.

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

38. Основні правила Екстремального Програмування: тестування

Unit Test-и

Unit тести грають ключову роль в XP. Вони дозволяють швидко міняти код не боячись наробити нових помилок. Unit тест пишеться для кожного класу, тест повинен перевіряти всі аспекти роботи класу - тестувати все що може не працювати.

Коли виявлена помилка

Якщо виявляється помилка, то створюється тест, щоб запобігти її повторній появі. Помилка, що відбулася в робочій системі (вже встановленою), вимагає написання функціонального тесту. Створення функціонального тесту безпосередньо перед діагностикою помилки дозволяє замовникам чітко описати проблему і довести цю проблему до розробників. Функціональний тест, що не виконався, вимагає створення Unit Test. Це допомагає сфокусувати зусилля по відладці і чітко показує коли помилка виправлена

Функціональні тести

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

39. Що сприяє зростанню проблеми захиста інформації?

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

Цьому сприяє:

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

2. Зосередження в єдиних базах даних інформації різного призначення і приналежності.

3. Розширення кола користувачів, маючих доступ к ресурсам обчислювальної системи і масивам даних.

4. Поява електронних грошей.

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