2.2 Планування конструювання (Construction Planning)

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

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

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

2.3 Вимірювання в конструюванні (Construction Measurement)

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

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

Останнім часом, велику увагу багато професійних розробники, тобто інженери-конструктори програмного забезпечення, приділяють рефакторинг коду, як методи його реструктурування, покликані без зміни змісту (тобто функціональності та функціональної цілісності) забезпечити вирішення завдань мінімізації складності, готовності до змін (гнучкості), прозорості документування і багатьох інших актуальних аспектів конструювання. Але, на жаль, багато хто забуває про необхідність мотивованості змін, навіть на рівні рефакторинга. Застосування вимірювань, зокрема, метрик, дозволяє визначити необхідність внесення таких змін, проведення рефакторинга. І не тому що "так, напевно, буде все ж краще, красивіше ...", а тому, що в ієрархії спадкоємства з 10 поколінь класів - 9 є абстрактними (" з любові до мистецтва "), а на 10-м ( в силу перевищень термінів проекту, після того, як довго і "в кайф" створювали архітектурно-красивий код) "повішено" 20 (!) бізнес-методів. Ось це - дійсно обгрунтована причина для рефакторинга, який, навіть із застосуванням найдосконаліших інструментів, разом з обмірковуванням необхідності рефакторинга, а потім, іноді, і боротьбою з його наслідками через неузгодженості членів команди (а це вже життя, навіть в самому ідеальному колективі, де люди розуміють один одного з півслова) часто є просто тратою часу. Якщо застосовується рефакторинг, але не застосовуються метрики - у переважній більшості випадків, це негативно впливає на проект. І таких прикладів робіт, що вимагають застосування вимірювань, але, на жаль, ігнорують їх, можна наводити досить довго. Ви, напевно, самі можете розповісти на цю тему багато прикладів з життя. Чому "авторизований переклад" цієї теми SWEBOK виявився настільки емоційний? Практика автора показує, що в гонитві за "красою", розробники дуже часто забувають про мету їх роботи і сприймають діяльність з управління проектами (не буду сперечатися, іноді лише формальну, для "прикриття" все, що тільки можна ...) з боку менеджерів і , тим більше, будь аудит - як однозначну перешкоду "польоту думки". Даремно. Якщо все саме так йде у вашому випадку - проект, з великою ймовірністю, а іноді й просто, "якщо не станеться чудо", можна вважати хай і не провальним ("фуух ... не закрили ...."), те, напевно, вийдущім за рамки тих чи інших обмежень, будь то терміни, гроші, якість або, нарешті, час, який розробник міг провести з родиною. І не сидіти вночі, дописуючи функціональність або відловлюючи чергову помилку за кілька днів до передачі проекту в експлуатацію. Всі ці питання переслідують одну єдину мету - передбачуваність робіт і результату. І виміру - важливий інструмент досягнення цієї мети. Область знань "Software Engineering Process" приділяє спеціальну увагу питанням вимірювань при створенні програмного забезпечення.