Класичний життєвий цикл ПЗ

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

Етапи (стадії) ЖЦ (створення ПЗ)

ЖЦ розробки ПЗ може бути представленим з різним ступенем деталізації етапів. Умовність визначення етапів пов'язана з тим, що на будь-якому етапі можливо прийняття рішень, які вимагають перегляданню рішень, які прийняти раніше. Етапи ЖЦ з найменшим ступенем деталізації можна представити таким чином:

1. Аналіз.

2. Проектування.

3. Реалізація.

Якщо говорити коротко, аналіз вказує на ті, що робити, проектування - на ті як за допомогою обраної технології зробити ті "Що треба зробити", реалізація здійснення задуманого на попередніх етапах у вигляді програмного продукту для замовника. На деталізованому рівні ЖЦ можна розділити на такі етапи:

1. Постановка задачі.

2. Аналіз вимог та визначення специфікацій.

3. Проектування.

4. Реалізація.

· Програмування.

· Тестування та налагодження.

5. Супроводження

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

Аналіз вимог і визначення специфікацій. Специфікаціями називають точний формалізований опис функцій (сервісів) і обмежень, які накладаються на функціональні можливості та розробку розроблювального програмного забезпечення. Цей процес заразом часто називають "Розробка вимог" (requirements engineering). Розробка вимог часто є критичним етапом в створенні ПЗ, оскільки помилки, які допущені на цьому етапі викликають проблеми на етапах проектування та розробки. Відповідно розрізняють функціональні й експлуатаційні специфікації. Сукупність специфікацій являє собою загальну логічну модель проектованого програмного забезпечення.

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

На цьому етапі також доцільно сформувати тесті для пошуку помилок у проектованому програмному забезпеченні, обов'язково вказавши очікувані результати.

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

Архітектурне проектування, тобто проектування загальної структури - визначення основних компонентів (підсистем) і їхніх взаємозв'язків.

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

Узагальнена специфікація. Для шкірного компонента (підсистеми) розробляється узагальнена специфікація на її сервіси та обмеження.

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

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

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

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

Прийнято розрізняти також два аспекти проектування:

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

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

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

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

· необхідність виправлення помилок, виявлених у процесі експлуатації попередніх версій;

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

· зміна середовища функціонування, наприклад, поява нових технічних засобів і/чи програмних продуктів, з якими взаємодіє супроводжуване програмне забезпечення.

На цьому етапі в програмний продукт вносять необхідні зміни, що таке саме, як в інших випадках, можуть зажадати перегляданню проектних рішень, прийнятих на будь-якому попередньому етапі. Зі зміною моделі життєвого циклу програмного забезпечення роль цього етапу істотно зросла, тому що продукти тепер створюються ітераційно (еволюційно): спочатку випускається порівняно проста версія, потім з великими можливостями, потім наступна і т.д. Саме це і послужило причиною виділення етапу супроводу в окремий процес життєвого циклу відповідно до стандарту ISO/IEC 12207. У нашу годину чітке відокремлення процесів розробки та супроводження зникає. Тільки невелику кількість ПЗ можна назвати абсолютно новою. Тому можна розглядати процес супроводження як неперервне продовження процесу розробки. Замість двох окремих процесів приймають еволюційний підхід, для якого ПЗ впродовж свого ЖЦ неперервно змінюється (еволюціонує) у відповідь на зміну системних вимог та потреб користувачів.

Не нашли, что искали? Воспользуйтесь поиском: