Які речі ви поклали на документ про аналіз впливу?

Отже, ви виправляєте помилки, тоді ви стикалися з одним, який може вплинути на інші модулі програмного продукту. Ваших даних недостатньо для підтвердження ваших тверджень про наслідки виправлення, і вас попросили створити документ про аналіз впливу.

1. Чи визначений процес, як це зробити?
2. Яка необхідна ключова інформація?
3. Чи є якісь відомі формати / шаблони для цього документа?

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

• Вплив на вимоги: У цьому розділі аналітик пише те, що потрібно змінити у випадках використання, щоб підтримувати запитувані зміни.
• Вплив на дизайн та архітектуру: У цьому розділі архітектор та дизайнер згадують, які частини моделі потрібно модифікувати чи переробити для підтримки змін.
• Вплив на тест: КК записує тестові випадки, які потрібно оновити.
• Оцінка та вплив на графік: Керівник проекту оцінює необхідні зусилля та вартість змін та вплив на графік проекту.

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

Ми використовували вищезазначене замовлення, оскільки дизайнерові необхідно знати вплив з точки зору аналітика, щоб краще зрозуміти зміни, і тому тестеру потрібно знати думку аналітика та архітектора. Так само, прем'єр-міністру потрібна вся інформація, щоб знати вартість та графік.

Ми використовували це з CR, але ви можете використовувати його з помилками так само. Крім того, якщо вам потрібно зробити це для вибору між декількома рішеннями виправлення, щоб вирішити помилку, вам потрібно буде повторити аналіз впливу для кожного можливого рішення та консолідувати всі дані в одну форму аналізу та вирішення (DAR) рішення, щоб знати, яке рішення є кращий. У форму DAR слід додати деякі фактори оцінки, такі як майбутня ремонтопридатність чи інші фактори, які не включені неявно в аналіз впливу. Потім дайте кожній вазі коефіцієнт і дайте кожний бал рішення у кожному факторі. Нарешті помножте та підсумовуйте бал * ваги та виберіть найкращий. Зауважте, що вартість може бути включена до факторів, або у прем'єр-міністра може бути інша думка.

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

Шаблони можуть бути корисними як контрольний список, але я б не вимагав заповнення кожного розділу для невеликих або низьких ризиків змін. Для зміни однієї лінії, можливо, вам взагалі не потрібен документ. Я ніколи не використовував шаблон для документа аналізу впливу, але регулярно маю справу з вимогами бізнесу або технічними характеристиками. Шаблон може бути занадто обмежуючим; натомість хорошим керівництвом є розгляд того, ким буде аудиторія. Якщо це менеджери, які не є технічними, зосередьтеся на виправданні бізнесу для зміни. Якщо це стосується технічних людей, надайте трохи досвіду, щоб нова людина в команді не загубилася, і дайте їм достатньо для того, щоб рухатися, якщо їм доведеться підтримати зміни. Крім того, якщо ви хочете чогось ще більш легкого і нелегкого тертя, взагалі не використовуйте документ, поставте його на вікі.

Інформація для включення:

• Короткий опис випуску
• Поясніть або покажіть приклад того, як дефект викликає збій та / або неефективність
• Включити оцінку складності
• Включайте кошторис вартості та часу на виправлення

Це гідний мінімум. В іншому дописі висвітлено деякі досить важкі речі CMMi від IBM; це чудово, якщо у вас є час і ресурси для цього (і коли ви будуєте системи для NASA, де загрожує життя людей, тоді люди краще серйозно ставляться до цього), але для невеликих команд вам, мабуть, не потрібно бути таким важким . Будьте уважні з оцінкою, як завжди. Менеджери схильні вважати, що оцінка є фактичною.

Зауважте, що в спритному підході є небезпеки. Деякі розробники вважають, що це означає, що "ніяких документів не потрібно, просто почніть злому" (що може бути нормальним у деяких ситуаціях). Крім того, інші візьмуть на себе широту задачі та просто напишуть справді хитрі документи, які не дуже допомагають (не обов’язково в більшості ситуацій). Частина проблеми полягає в тому, що писати добре вимагає певних зусиль, навичок та часу; більшості з нас не вистачає принаймні двох речей;)

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

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

Документ з аналізу впливу повинен бути затверджений керівником, щоб переконатися, що зміна не вплине на інший компонент, який працює добре у виробництві.

Аналіз впливу необхідний для того, щоб переконатися, що вимога повністю зрозуміла та ідентифіковано всі компоненти, які потрібно змінити, щоб уникнути повторної роботи

Аналіз впливу необхідний і для підзвітності клієнтів. В іншому випадку, коли виникає проблема після розгортання, розробник стає козлом відпущення.

Аналіз впливу є основою для оцінки. Без цього оцінка не має жодної позиції. Він може бути занадто високим або занадто низьким. Якщо аналіз впливу впливає, якщо фактичні зусилля перевищують, це також легко пояснити.

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

Посилання: http://www.itu.int/en/itu-d/projects/documents/templateimpactanalysis.pdf

Ура