1. Охарактеризуйте основні етапи процесу розробки програмного забезпечення (від виникнення ідеї розробки до прийняття рішення про виведення з експлуатації). Які програмні системи призначені для автоматизації процесу розробки програмного забезпечення на різних етапах?

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

Основні етапи процесу розробки програмного забезпечення:

1. Виникнення і дослідження ідеї-це класичний процес має наступні дії: виникнення та первинне дослідження ідеї; детальне дослідження ідеї, вироблення концепції, постановка задачі; експертиза ідеї фахівцями, прийняття рішення про початок процесу планування. Тут використовують пошукові інформаційні системи (google, yandex ...), системи пошуку рішень.

2. Управління - цей процес триватиме майже весь життєвий цикл програмного продукту, одним з найважливіших дій управління є планування, яке починається слідом за прийняттям рішення, про те, що проект потрібно реалізувати. Тут використовують 3 групи інструментів-системи управління проектами (Microsoft project, time line), організаційні засоби (електронна пошта, електронний календар ...), засоби оцінки якості (metricate)

3. Аналіз вимог і проектування двох тісно пов'язаних процесу, вони виконують загальну задачу , результатом кіт має стати чітке уявлення про систему на основі якого буде створено програмний код. Аналіз вимог це процес життєвого циклу програми під час якого вимоги замовника уточнюються, формалізується і документуються. Проектування - це процес життєвого циклу програми під час кіт досліджуються її структура та взаємозв'язки елементів. Проектування, як правило, є ітераційний процесом. Проектування та аналіз вимог можуть різнитися різними способами декомпозиції систем-структурна декомпозиція (розглядає структуру системи в термінах ієрархії функцій та передачі інформації) і об'єктна декомпозиція (розглядає структуру об'єктів та зв'язків між ними, а також поведінка системи в термінах обміну повідомлень між об'єктами). Тут використовують при структурному підході (Erwin, Oracle Designer), при об'єктно-орієнтованому підході (Rational Rose ...)

4. Програмування (реалізація). Тут використовують С #, c + +, Delphi, java

5. Тестування та налагодження. Тестування - це процес виконання програми з метою виявлення факту наявності помилок. Налагодження - це процес локалізації та усунення помилок. Тестування починається з розробки безлічі тестів і їх виконання на основі однієї з обраних методик. Після порівняння результатів з еталонними починається або діагностика проблеми або оцінка достатності повноти тестування. Тут використовують Prodelphi, rational purecoverage

6. Запровадження програми в дію - істотно залежить від того чи була ця розробка для конкретного замовника або вона є продуктом розрахованим на широкого користувача. Існує 3 основних способи доставки програми до користувача-індивідуальна доставка, коробкова доставка, доставка через Інтернет. Тут використовують Create install, InstallShild

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

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

Життєвий цикл ІС можна представити як ряд подій,відбуваються з системою в процесі її створення та використання.

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

В даний час відомі і використовуються наступні моделі життєвого циклу:

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

• Поетапна модель з проміжним контролем. Розробка ІС ведеться итерация з циклами зворотного зв'язку між етапами. Межетапние коректування дозволяють враховувати реально існуюче Взаємовплив результатів розробки на різних етапах;час життя кожного з етапів розтягується на весь період розробки.

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

 

2. Структурний підхід до розробки програмного забезпечення. Низхідне та висхідне проектування та програмування. Використання заглушок.

У структурному аналізі та проектуванні використовуються різні моделі, які описують:

- Функціональну структуру системи;

- Послідовність виконуваних дій;

- Передачу інформації між функціональними процесами;

- Відносини між даними.

Найбільш поширеними моделями перших трьох груп є:

- Функціональна модель SADT (Structured Analysis and Design Technique);

модель IDEF3;

• DFD (Data Flow Diagrams) – діаграми потоків даних.

Метод SADT являє собою сукупність правил і процедур, призначених для побудови функціональної моделі об’єкта будь-якої предметної області. Функціональна модель SADT відображає функціональну структуру об’єкта, тобто вироблені їм дії й зв’язки між цими діями.

Моделі SADT (IDEF0) традиційно використовуються для моделювання організаційних систем (бізнес-процесів).Слід зазначити, що метод SADT успішно працює тільки при описі добре специфікованих і стандартизованих бізнес-процесів в закордонних корпораціях, тому він і прийнятий в США в якості типового. Достоїнствами застосування моделей SADT для опису бізнес-процесів є:

- Повнота опису бізнес-процесу (управління, інформаційні та матеріальні потоки, зворотні зв’язки);

- Жорсткі вимоги методу, що забезпечують отримання моделей стандартного вигляду;

- Відповідність підходу до опису процесів стандартам ISO 9000.

Метод моделювання IDEF3 призначений для таких моделей процесів, в яких важливо зрозуміти послідовність виконання дій і взаємозалежності між ними. Основою моделі IDEF3 служить так званий сценарій процесу, який виділяє послідовність дій і 1роектує мог аналізованої системи.

Діаграми потоків даних (Data Flow Diagrams – DFD) представляють собою ієрархію функціональних процесів, пов’язаних потоками даних. Мета такого подання – продемонструвати, що кожен процес перетворює свої вхідні дані у вихідні, а також виявити відносини між цими процесами.

Для побудови DFD традиційно використовуються дві різні нотації, що відповідають методам Йордона-Демарк і Гейне-Серсона.Ці нотації незначно відрізняються один від одного графічним зображенням символів. Згідно з даними методами модель системи визначається як ієрархія діаграм потоків даних, що описують асинхронний процес перетворення інформації від її введення в систему до видачі споживачеві.

Найбільш поширеним засобом моделювання даних (предметної області) є модель «сутність-зв’язок» (Entity-Relationship Model – ERМ). Ця модель традиційно використовується в структурному аналізі та проектуванні, однак, по суті, являє собою підмножину об’єктної моделі предметної області.

При проектуванні, реалізації та тестуванні компонентів структурної ієрархії, отриманої при декомпозиції, застосовують два підходи:

• висхідний;

• низхідний.

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

Для тестування й налагодження компонентів проектують і реалізують спеціально 1роектує програми.

Підхід має такі недоліки:

• збільшення ймовірності неузгодженості компонентів внаслідок неповноти специфікацій;

• наявність витрат на проектування і реалізацію 1роектує про ¬ грам, які не можна перетворити на компоненти;

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

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

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

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

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

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

Комбінований метод враховує наступні фактори, що впливають на послідовність розробки:

• досяжності модуля – наявність всіх модулів в ланцюжку виклику даного модуля;

• залежність з даними – модулі, які формують деякі дані,повинні створюватися раніше обробних;

• забезпечення можливості видачі результатів – модулі виводу результатів повинні створюватися раніше обробних;

• готовність допоміжних модулів – допоміжні модулі, наприклад, модулі закриття файлів, завершення програми, повинні створюватися раніше обробних;

• наявність необхідних ресурсів.

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

Спадний підхід забезпечує:

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

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

• можливість низхідного тестування і комплексної налагодження.

3. Об’єктно-орієнтований підхід до розробки програмного забезпечення. Дайте визначення поняття класу, об’єкту, поля, методу. З чого складається життєвий цикл об’єкту?

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

Цей підхід полягає в декомпозиції завдання на об'єкти або поняття(книга, каталог.) Полдійний підхід – реакція на якусь подію. Об'єктно-орієнтована методологія (ООМ) включає 3 частини - об'ектно-оріентірованний аналіз (ООА), об'єктно-орієнтоване проектування (ООП) і об'єктно-орієнтоване програмування (ООР) - і використовується программістамі як засіб для преодоленія складності створюваних систем. Об'єктно-орієнтований підхід в рамках об'єктної парадигми (програмування в іменниках) структурується в 4 етапи - аналіз, проектування, еволюція і модифікація - і є по¬следова¬тельний ітеративним процесом, який дозволяє безболез¬ненно вносити які-небудь зміни вже відлагоджений программ¬ний про¬дукт і в якому результати одного з етапів можуть впливати на рішення, прийняті на попередніх.

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

Фундаментальними поняттями ООР є поняття класу і об'єкту. Об’єкт – відчутна сутність, що чітко віявляє свою поведінку. Кожній об’єкт характерізується властівостямі (розмір, колір, смак і таке інше) та діямі ( ходити їсть, сидіть і таке інше). За збігом основніх ознак мі можемо віділіті групі об’єктів – класи. Клас – це сукупність об’єктів одного типові, тобто схожих за своїмі властівостямі та прізначенням. Іншими словами, кожен об’єкт є екземпляром певного класу.

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

Життєвий цикл об'єкту складається з конструктора (для створення екземпляру об’єкту вікорістовують спеціальній метод, який назівається конструктором і має ім’я Create. Прізначення конструктора Create:

• віділення пам’яті для об’єкта.

• ініціалізація полів об’єкту нулями), дій, кіт. являються реакцією на деяку подію. Ці дії виконує об'єкт за допомогою своїх методів і деструкції ( Деструкція Destroy не має параметрів та віконує такі дії:

• віклік методу Cleanupinstance.

• віклік Instancesize для візначення розміру об’єкту, що відаляється. Найчастіше для зніщення об’єкта вікорістовується не сама деструкція, а метод Free, який також спадкується об’єктамі від Tobject. Цей метод спочатку перевіряє, чи не дорівнює покажчик на об’єкт NIL, якщо ні, то віклікає деструкція цього об’єкту.):