анізаціях прийнята практика поділу ідентифікації вимог і вибору архітектури, але коли переходять на технологію моделювання об'єктів в стилі Буча, то слухають раді та об'єднують ці завдання. Коли ми поділяємо навички розробки і тестування, ми можемо отримати з цього додаткові переваги, контролюючи взаємодію між стадіями таким чином, що мисленню інженера-тестера не загрожує мислення проектувальника. Був менеджер проекту, швидше за все паковщік. Він не мав ясного розуміння того, що він робив і чому, а відсутність який-небудь позитивної моделі своєї роботи привело його до думки, що ключова мета полягає в запобіганні якого б то не було взаємодії. Тестери не повинні були знати, як встановити (створити) умови для компонентів, які вони повинні були тестувати, а проектувальник не дозволялося про це говорити. Запеклі суперечки тривали днями. Це реально сталося тоді, коли ми втратили відчуття великої картини.
Ми повинні упевнитися, що взаємодія між розподіленими завданнями ефективно, і це означає, що ми повинні, крім відповідності протоколу, тримати в голові потреби один одного. Все, що вам потрібно тримати в голові для виконання свого завдання і передачі її іншому, також повинні пам'ятати ваші колеги. Ваш результат не допоможе нікому, якщо він не говорить про те, що їм потрібно для виконання наступного дії. Нам потрібно використовувати наші власні здатності виконувати роботу один одного, не важливо наскільки невміло, щоб контролювати власну роботу.
Нарешті, ми повинні зрозуміти, що в команді все ще існує чорний ящик окремого програміста. Потік інформації - це не лінійна послідовність перетворень, як на конвеєрі автозаводу, для проектувальника це скоріше розходиться віяло можливостей, що зводиться до єдиного рішення. Інтуїція проектувальника поки ще не розподілена. Таке досягнення було б найзначнішим результатом штучного інтелекту (ШІ).
Щоб зрозуміти програмну інженерію, ми повинні зрозуміти програміста. Давайте дозволимо програмісту визначати вимоги (ідентичні вимогам користувача) і досліджуємо сценарій, який закінчується створенням найпростіших можливої ??програми.
Ада сидить у кімнаті.
Увечері в кімнаті стає темно.
Ада вмикає світло.
Це фундаментальне дію програмування. Є проблемна область (кімната), яка динамічна (стає темною). У динаміці проблемної області є порядок (темно буде до ранку), який можна аналізувати. Є система, яка може функціонувати в проблемної області (лампочка), і у цієї системи є семантика (стан вимикача).
Є бажання (в кімнаті має бути світло), і є розуміння (що вплив на вимикач задовольнить бажання).
Динамічні предметні області, системи і семантика детально десь обговорюються. Але тут ми концентруємося на кращому усвідомленні, що є бажання і що є розуміння.
Тут варто відзначити, що ми розуміємо під словом «програміст». Робот, що пише все ту ж RPG 3 для роздруківки рахунків, все ще не робить ніякого реального програмування взагалі, але менеджер проекту, використовуючи Excel для отримання інтуїтивного розуміння того, коли бюджет скоротиться і в чому головні причини, безсумнівно займається реальним програмуванням.
2.2 Засоби розробки ПЗ
Засоби розробки складаються з усіх тих інструментів (включаючи текстові процесори), які використовують програмісти, а також машин і мережевої інфраструктури, на якій вони працюють. Хороші засоби розробки повинні бути якомога простіше. Як і в програмах, які ви розробляєте: чим більше складності, тим більше місця для проблем, тим вище вартість експлуатації.
Гарне загальне правило - тримати всю свою роботу, включаючи кошти конфігурації (у файлах скриптів, якщо потрібно) у вигляді простого тексту. Майте можливість при необхідності стерти все, крім вихідного тексту, і автоматично перекомпілювати.
Найголовніше завдання репозитария і системи управління конфігурацією - забезпечити вашу безпеку. Кожен елемент складності збільшує небезпеку падіння системи. Команда, перекладають контроль на систему управління конфігурацією з клієнт-серверною архітектурою, ризикує втратити проект через втрату посилальної цілісності в системі. Добутий хаос, коли вся робота зупиняється, примушує знайти спосіб забезпечення безпеки в створення резервної копії, люди починають з'ясовувати, що необхідно переробити заново, і дух падає. Не так складно побудувати хорошу систему управління конфігурацією на основі скриптів з використанням списків розсилки, на основі чогось простого, типу SCCS або RCS, для забезпечення контролю версій.
Та ж сама логіка, що метою є безпека, і тому простота збільшує надійність і безпеку, коли система і користувачі в стресі, застосовна і до ст...
