5. Зворотна інженерія та ре інженерія програмного забезпечення.

Реінжиніринг визначається як детальна оцінка (examination) і перебудова програмного забезпечення для формування розуміння, відтворення (на рівні моделі і, в ряді випадків, вимог) та подальшої реалізації його <функцій> в новій формі (наприклад, з використанням нових технологій і платформ, при збереженні існуючої і розширенням і полегшенням можливостей додавань нової функціональності). Відзначається, що в індустрії існують різні позиції щодо реінжинірингу - одні вважають, що реінжиніринг є найбільш радикальною і витратною формою змін програмних систем, інші, що такий підхід може застосовуватися і для не настільки кардинальних змін (наприклад, як зміна платформи чи архітектури). Реінжиніринг, зазвичай, провидится не стільки для поліпшення можливостей супроводу (maintainability), скільки для заміни застарілого програмного забезпечення. В принципі, реінжиніринг можна розглядати як самостійний проект, що включає в себе, як зазначає SWEBOK, формування концепції, застосування відповідних інструментів і технік, аналіз і застосування досвіду проведення реінжинірингу, а також оцінку ризиків і переваг, пов'язаних з такими роботами.

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

"Зворотний" інжиніринг (часто плутають з реинжинирингом, в тому числі, в розумінні SWEBOK) або це процес аналізу програмного забезпечення з метою ідентифікації програмних компонент і зв'язків між ними, а також формування уявлення про програмне забезпечення, з подальшою перебудовою в новій формі (вже , в процесі реінжинірингу). Зворотній інжиніринг є пасивним, припускаючи відсутність діяльності щодо зміни або створення нового програмного забезпечення. Зазвичай, в результаті зусиль по зворотному інжинірингу створюються моделі викликів (call graphs) і потоків управління (control flow graphs) на основі вихідного коду системи. Один з типів зворотного інжинірингу - створення нової документації на існуючу систему (redocumentation). Інший з поширених типів - відновлення дизайну системи (design recovery).

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

5. Версійність програмного забезпечення.

Якщо розробнику доводиться покладатися на позаштатних тестерів, у версії може вказуватися рівень зрілості програми: альфа-версія, бета-версія, реліз-кандидат, остаточний випуск, виправлення помилок (service release).

Наприклад, 2.0 alpha1 <2.0 alpha2 <2.0 beta <2.0 rc1 <2.0 <2.0 sr1.

Існують різні схеми позначення стадій розробки. Наприклад, третє число може означати:

• 0 - альфа

• 1 - бета

• 2 - реліз-кандидат

• 3 - публічний реліз

Наприклад:

• 1.2.0.1 замість 1.2-a

• 1.2.1.2 замість 1.2-b2 (бета з кількома виправленими помилками)

• 1.2.2.3 замість 1.2-rc3 (реліз-кандидат)

• 1.2.3.0 замість 1.2-r (для комерційного розповсюдження)

• 1.2.3.5 замість 1.2-r5 (для комерційного розповсюдження з багатьма виправленими помилками)

Пре-альфа

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

Альфа

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

Бета

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

Реліз-кандидат

• Реліз-кандидат або RC (англ. release candidate), Пре-реліз або Pre - стадія-кандидат на те, щоб стати стабільною. Програми цієї стадії пройшли комплексне тестування, завдяки чому були виправлені всі знайдені критичні помилки. Але в той же час існує ймовірність виявлення ще деякого числа помилок, не помічених при тестуванні.

Реліз

• Основна стаття: Реліз (програмне забезпечення)

• Реліз або RTM (англ. release to manufacturing промислове видання) - видання продукту, готового до тиражування. Це стабільна версія програми, що пройшла всі попередні стадії, в яких виправлені основні помилки, але існує ймовірність появи нових, раніше не помічених, помилок. RTM передує загальної доступності (GA), коли продукт випущений для громадськості.

Пост-реліз

• Пост-реліз або Post-RTM (англ. post-release to manufacturing), видання продукту, у якого є декілька відмінностей від RTM і позначається як найперша стадія розробки наступного продукту. Такі релізи не випускаються на продаж, а лунають бета-тестувальникам. Це видання може бути або стабільним (якщо не помічено помилок), або з помилками.