Перегляди

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

Перегляди можуть бути формальними і неформальними. Формальні це, наприклад: технічний перегляд, наскрізний контроль, аудит.

Технічний перегляд

Технічний перегляд - перевірка на відповідність елементів ПЗ плану розробки (деталі можна знайти в ANSI/ IEEE Std 1028 -1988 "Стандарт для переглядів програмного забезпечення".

Наскрізний контроль

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

Аудит

Аудит - це вид наскрізного контролю, який використовується для перевірки відповідності ПЗ вимогам, специфікаціям, рекомендаціям, стандартам, процедурам, умовам контрактів і ліцензіям. Об'єктивність аудиту вимагає незалежних експертів-професіоналів. Аудити повинні проводитися аудитною групою або персонами з відповідними ліцензіями. Правила визначаються стандартом ANSMEEE Std 1028-1988 IEEE - стандарт для переглядів програмного забезпечення.

Команда з оцінки пз

Оцінка ПЗ - дуже важливе завдання, яке повинне вирішуватися професіоналами.

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

У тестуванні приймають участь наступні особи: супервізор, секретар, члени команди, серед яких є представники користувачів, супервізор проекту розробки ПЗ, розробники ПЗ, персонал гарантії якості проекту, незалежний персонал перевірки і незалежні експерти.

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

Аудит проекту розробки ПЗ

Мета аудиту - отримати цілісну інформацію про проект.

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

Суб'єкти і перспективи аудиту

Суб'єктами аудиту можуть бути процеси і/або продукти проекту.

Мета аудиту процесу - перевірити, чи правильно виконується робота, її відповідність принципам і стандартам.

Мета аудиту продукту (проміжного або кінцевого) - перевірити, чи відповідає він вимогам і очікуванням.

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

Інспекціювання

Інспекціювання - формальна техніка оцінки персоною, або групою персон, проекту на наявність помилок у коді і вимогах, його відповідність стандартам, а також пошуку інших проблем в процесі розробки ПЗ [IEEE Std. 729-1983].

Інспекціювання повинно бути добре сплановане і організоване. Всі помилки і проблеми повинні бути позначені. Супервізори не повинні брати участь в інспекції - її результати надаються супервізорам у формі звітів, без особистої інформації про інспекторів.

Нарада після інспекції - справжня мозкова буря тих, хто приймав участь в ній.

Мета наради - зробити висновки про те, які проблеми повинні бути усунені і які дії виконані для уникнення проблем в майбутньому.

рис 1.3. Процес інспекції.

На рис. 1.3. зображені наступні етапи інспекції:

• Ініціація – визначення членів інспекції і її голови.

• Планування - голова викликає членів, формує план і визначає ретельність контролю.

• Ініціююча нарада - формулювання завдань, очікувань, створення документів.

• Індивідуальний контроль - члени інспекції перевіряють документи, використовуючи критерії контролю (для того, щоб знайти максимальну кількість помилок).

• Контрольна нарада (мозкова буря) - збір думок кожного інспектора, які можуть допомогти виявити невідповідність (потенціальну помилку), визначити шляхи удосконалення процесу, допомогти виявити можливі джерела інших невідповідностей.

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

• Доопрацювання: голова перевіряє, чи всі невідповідності виправлені; він перевіряє завершеність, а не правильність.

• Рішення про завершеність: голова інспекції дає оцінку того, чи готовий продукт (чи знаходиться кількість помилок у допустимих межах).

• Розробка документів.

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

Продуктивність в результаті інспекції збільшується на 30% - 100%, час на розробку проекту зменшується на 10% - 30%, вартість тестування зменшується в 5 - 10 разів (менше помилок, менше регресивних помилок), підтримка - в 10 разів. Було зазначено, що інспекції мотивують команди: робота виконується вчасно, а її якість збільшується. Продукт оцінюється з більшою компетентністю. Витрати стають меншими, оскільки не потрібно маскувати низьку якість продукту.

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