Зміст
Анотація.
Введення.
1. Життєвий цикл ПЗ
Введення.
Кроки процесу програмування по Райлі
Введення.
1.1.1. Постановка завдання.
1.1.2. Проектування рішення.
1.1.3. Кодування алгоритму.
1.1.4. Супровід програми.
1.1.5. Програмна документація.
Висновок до п. 1.1
1.2. Визначення ЖЦПО по Леману.
Введення.
1.2.1 Визначення системи.
1.2.2. Реалізація.
1.2.3. Обслуговування.
Висновок до п. 1.2.
1.3. Фази і роботи ЖЦПО по Боемі
1.3.1. Каскадна модель.
1.3.2. Економічне обгрунтування каскадної моделі.
1.3.3. Удосконалення каскадної моделі.
1.3.4. Визначення фаз життєвого циклу.
1.3.5. Основні роботи над проектом.
Висновок.
Література.
Введення
Промислове застосування комп'ютерів і зростаючий попит на програми поставили актуальні завдання істотного підвищення продуктивності розробки ПЗ, розробки індустріальних методів планування і проектування програм, перенесення організаційно-технічних, техніко-економічних і соціально-психологічних прийомів, закономірностей і методів зі сфери матеріального виробництва в сферу застосування комп'ютерів . Комплексний підхід до процесів розробки, експлуатації і супроводу ПЗ висунув ряд нагальних проблем, вирішення яких виключить «вузькі місця» у проектуванні програм, зменшить терміни завершення робіт, поліпшить вибір і адаптацію існуючих програм, а може бути і визначить долю систем з вбудованими ЕОМ.
У практиці розробок великих програмних проектів часто відсутній єдиний підхід до оцінювання витрат праці, термінів проведення робіт і матеріальних витрат, що стримує підвищення продуктивності розробки ПЗ, а в кінцевому рахунку - ефективне управління життєвим циклом ПЗ. Оскільки програма будь-якого типу стає виробом (крім, може бути, навчальних, макетних програм), підхід до її виготовлення в чому повинен бути аналогічний підходу до виробництва промислової продукції, і питання проектування програм стають надзвичайно важливими. Ця ідея лежить в основі книги б.у. Боемі «Інженерне проектування програмного забезпечення», яку ми використовували при написанні даної курсової роботи. У цій книзі під проектуванням ПО розуміється процес створення проекту програмного виробу.
1 Життєвий цикл ПЗ
ВСТУП
ЖЦПО - це безперервний процес, який починається з моменту прийняття рішення про необхідність створення ПЗ і закінчується в момент його повного вилучення з експлуатації.
Існує декілька підходів при визначенні фаз та робіт життєвого циклу програмного забезпечення (ЖЦПО), кроків процесу програмування, каскадна і спіральна моделі. Але всі вони містять загальні основні компоненти: постановка завдання, проектування рішення, реалізація, обслуговування.
Найбільш відомою і повної, мабуть, є структура ЖЦПО по Боемі, що включає вісім фаз. Вона і буде представлена надалі найбільш детально.
Одним з можливих варіантів може послужити опис верхнього рівня з Леману, що включає три основні фази і що представляє опис ЖЦПО в самому загальному випадку.
І, для різноманітності, - наведемо кроки процесу програмування, представлені Д. Райлі в книзі «Використання мови Модула-2». Це подання, по-моєму, є досить простим і звичним, з нього і почнемо.
1.1 Кроки процесу програмування по Райлі
Введення
Процес програмування включає чотири кроки (рис. 1):
постановка задачі, тобто отримання адекватного уявлення про те, яке завдання має виконати програма;
проектування рішення вже поставленого завдання (загалом, таке рішення є менш формальним, ніж остаточна програма);
кодування програми, тобто переклад спроектованого рішення в програму, яка може бути виконана на машині;
супровід програми, тобто безперервний процес усунення в програмі неполадок і додавання нових можливостей.
SHAPE \ * MERGEFORMAT
Рис. 1.Четире кроку програмування.
Програмування починається з того моменту, коли користувач, тобто той, хто потребує програми для вирішення завдання, викладає проблему системного аналітику. Користувач і системний аналітик спільно визначають постановку задачі. Остання потім передається алгорітмісту, який відповідає за проектування рішення. Рішення (або алгоритм) представляє послідовність операцій, виконання яких призводить до вирішення завдання. Оскільки алгоритм часто не пристосований до виконання на машині, його слід перевести в машинну програму. Ця операція виконується кодувальником. За наступні зміни в програмі несе відповідальність супроводжуючий програміст. І системний аналітик, і алгорітміст, та кодер, і супроводжуючий програміст - всі вони є програмістами.
У разі великого програмного проекту число користувачів, системних аналітиків і алгорітмістов може виявитися значним. Крім того, може виникнути необхідність повернутися до попередніх кроків в силу непередбачених обставин. Все це служить додатковим аргументом на користь ретельного проектування програмного забезпечення: результати кожного кроку повинні бути повними, точними і зрозумілими.
1.1.1 Постановка завдання
Одним з найбільш важливих кроків програмування є постановка задачі. Вона виконує функції контракту між користувачем і програмістом (програмістами). Як і юридично погано складений контракт, погана постановка задачі марна. При гарній постановці завдання як користувач, так і програміст ясно і недвозначно представляють завдання, яку необхідно виконати, тобто в цьому випадку враховуються інтереси як користувача, так і програміста. Користувач може планувати використання ще нествореного програмного забезпечення, спираючись на знання того, що воно може. Гарна постановка завдання служить основою для формування її рішення.
Постановка завдання (специфікація програми); по суті, означає точне, повне і зрозуміле опис того, що відбувається при виконанні конкретної програми. Користувач зазвичай дивиться на комп'ютер, як на чорний ящик: для нього неважливо, як працює комп'ютер, а важливо, що може комп'ютер з того, що цікавить користувача. При цьому основна увага фокусується на взаємодії людини з машиною.
Характеристики Доброю Постановки Завдання:
Точність, тобто виключення будь-якої неоднозначності. Не повинно виникати питань щодо того, яким буде висновок програми при кожному конкретному введенні.
Повнота, тобто розгляд всіх варіантів для заданого введення, включаючи помилковий або непередбачений введення, і визначення відповідного висновку.
Ясність, тобто вона повинна бути зрозумілою і користувачеві і системного аналітику, оскільки постановка завдання - це єдиний контракт між ними.
Часто вимога точності, повноти і ясності знаходяться у протиріччі. Так, багато юридичних документи важко зрозуміти, тому що вони написані на формальній мові, що дозволяє гранично точно сформулювати ті чи інші положення, виключаючи будь-які самі незначні різночитання. Наприклад, деякі питання в екзаменаційних білетах іноді сформульовані настільки точно, що студент витрачає більше часу на те, щоб зрозуміти питання, ніж на те щоб на нього відповісти. Більше того, студент взагалі може не вловити основний зміст питання з-за великої кількості деталей. Найкраща постановка задачі та, при якій досягається баланс усіх трьох вимог.
Стандартна форма постановки завдання.
Розглянемо наступну постановку завдання: «Ввести три числа і вивести числа в порядку».
Така постановка не задовольняє наведеним вище вимогам: вона не є ні точної, ні повної, ні зрозумілої. Дійсно, чи повинні числа вводитися по одному на рядок або всі числа в одному рядку? Чи означає вираз «в порядку» упорядкування від більшого до меншого, від меншого до більшого або той же порядок, в якому вони були введені.
Очевидно, що така постановка не відповідає на безліч питань. Якщо ж врахувати відповіді на всі питання, то постановка задачі стане багатослівною і важкою для сприйняття. Тому Д. Райлі пропонує для постановки задачі користуватися стандартною формою, яка забезпечує максимальну точність, повноту, ясність і включає:
найменування завдання (схематичне визначення);
загальний опис (короткий виклад завдання);
введення;
висновок;
помилки (явно перераховані незвичайні варіанти введення, щоб показати користувачам і програмістам ті дії, які зробить машина в подібних ситуаціях);
приклад (хороший приклад може передати сутність завдання, а також проілюструвати різні випадки).
Приклад. Постановка завдання в стандартній формі.
НАЗВА
Сортування трьох цілих чисел.
ОПИС
Введення і виведення трьох цілих чисел, відсортованих від меншого числа до більшого.
ВВЕДЕННЯ
Вводяться три цілих числа по одному числу на рядку. При цьому цілим числом є одна або кілька послідовних десяткових цифр, яким може передувати знак плюс «+» або знак мінус «-».
ВИСНОВОК
Виводяться три введених цілих числа, причому всі три виводяться на одному рядку. Суміжні числа розділяються пропуском. Числа виводяться від меншого до більшого, зліва направо.
ПОМИЛКИ
1) Якщо введено менше трьох чисел, програма чекає додаткового введення.
2) Рядки введення, крім перших трьох, ігноруються.
3) Якщо будь-яка з перших трьох рядків містить більше одного цілого числа, то програма завершує роботу і видає повідомлення.
ПОМИЛКА ВВЕДЕННЯ - допускається тільки одне ціле число на рядку.
ПРИКЛАД:
введення ® - 3
2
+ 17
висновок ® - 3 2 + 17
1.1.2. Проектування рішення
Цей крок програмування є найбільш важким. На даній стадії постановка задачі має бути перетворена на алгоритм. Тому алгорітміст повинен володіти достатнім досвідом програмування і підходити до кожної нової задачі, спираючись на твердо встановлену методику проектування. На жаль, в даний час всі великі програми містять помилки, що призводить до кепським проектам. Погані проекти в свою чергу є наслідком складності завдань і використання неадекватних методів проектування. Щоб уникнути помилок в програмах, алгорітмісти повинні використовувати ретельно розроблені процедури конструювання, засновані на правилах логічного висновку.
Існують дві основні моделі висновку:
Перша модель відома як дедуктивний висновок. Цю форму логічного мислення обезсмертив знаменитий детектив Шерлок Холмс. Дедуктивна логіка застосовує загальні правила до конкретних випадків. Наприклад, Холмс міг вивести конкретне твердження «Дворецький є вбивцею» з більш загальних відомостей «Вбивця-блондин», а «Дворецький є єдиним блондином, якого можна підозрювати».
Друга модель - це індуктивний висновок, який є протилежністю дедуктивного висновку. Індуктивна логіка витягує загальні висновки з окремих випадків. Наприклад, індуктивний висновок може бути використаний, щоб обгрунтувати загальний висновок «сонце піднімається на сході» на підставі багатьох окремих спостережень того, що сонце завжди піднімалося на сході.
Ці два процеси виведення умовиводів - дедукція (від загального до конкретного) та індукція (від приватного до загального) - тісно пов'язані з двома найбільш широко поширеними методами проектування: «згори донизу» і «знизу вгору». Подібно дедукції, проектування «зверху вниз» починається з великого завдання, яка розбивається на підзадачі. Наприклад, проектувальник нового холодильника-морозильника на підставі вихідної безлічі специфікацій агрегату (тобто постановки задачі) повинен дати детальні схеми і специфікації остаточного продукту (тобто проект).
Якщо при цьому він використовує метод проектування «зверху вниз», то єдине завдання проектування може бути розбита на дві менші підзадачі: (1) проектування холодильного агрегату і (2) проектування морозилки.
Проте можна скористатися методом проектування «знизу вгору» і почати з проектування холодильного компресора, а потім охолоджують труб, агрегату або холодильної камери. У такому випадку цей вибір буде накладати певні обмеження на весь проект.
Завдання проектувальника - створення алгоритму, що виконує функції сполучної ланки між постановкою завдання і готова для виконання програмою. Перевірку створеного алгоритму, тобто наскільки останній відображає постановку завдання, здійснює системний аналітик. У силу цього і системний аналітик, і проектувальник повинні вміти читати і розуміти алгоритм. Кожен алгоритм записується на деякій псевдомова. Алгоритми, звані також псевдокод, не можуть бути виконані ні на якому комп'ютері.
1.1.3 Кодування алгоритму
Робота кодувальника полягає в перекладі алгоритму в програму. Для створення повної, точної та зрозумілої програми необхідні відповідні методи запису програм. Наприклад, кулінарні рецепти зазвичай записуються на природних мовах, таких, як англійська, французька, російська або японська. Програми ж пишуться на мовах програмування. В даний час жоден з природних мов не можна використовувати в якості мови програмування, так як вони занадто складні, щоб їх могли «розуміти» машини. На відміну від природних, мови програмування створені спеціально для такого подання рішення завдання, яке може бути виконано комп'ютером.
1.1.4 Супровід програми
Перш ніж завершити роботу, кодіровщік повинен переконатися, що програма відповідає псевдокод. Потім системний аналітик, алгорітміст і, що найголовніше, користувач повинні протестувати і підтвердити, що вона працює правильно. Після цього можна вважати, що програма готова для передачі користувачеві в комплекті з усією необхідною документацією.
Однак на цьому програмування не закінчується, далі слід крок супроводу. Справа в тому, що в програмі можуть бути помилки, зумовлені або неадекватною постановкою завдання, або тим, що проект не задовольняє постановці задачі або програма не відповідає проекту. Яка б не була причина, користувач має право вимагати коригування програми, оскільки він не уявляв, що програма буде працювати таким чином. Виправлення помилок є однією з головних завдань супроводу програм. Інший не менш важливим завданням супроводу програм є її модифікація, тобто додавання в програму нових можливостей або зміна існуючих. Користувач може змінити вимоги до роботи програми, що, у свою чергу, призведе до необхідності її переписати. Складність операцій із супроводу програми залежить від типу змін, які повинні бути зроблені: у гіршому випадку може знадобитися повна переробка програми від постановки до кодування. Зазвичай на супровід програми витрачається більше часу, ніж на її створення.
1.1.5 Програмна документація
Останньою складовою процесу програмування є документування. Воно включає широкий спектр описів, що полегшують процес програмування і збагачують результуючу програму. Постійне документування має становити невід'ємну частину кожного кроку програмування. Постановка завдання, проектні документи, алгоритми і програми - все це документи. Внутрішня документація, зазначена безпосередньо в програму, полегшує читання коду. Призначення навчального посібника (ще однієї форми документації) - навчити користувача застосовувати нову програму; довідкове керівництво дозволяє ознайомитися з описом команд програмного забезпечення.
Висновок до п.1.1.
Відповідно до моделі, представленої в цьому розділі, програмування можна розділити на чотири кроки: постановку задачі, проектування рішень, кодування програми, супровід програми. Додатково модель включає документування програми як дії, які необхідно виконувати протягом всього процесу програмування.
Анотація.
Введення.
1. Життєвий цикл ПЗ
Введення.
Кроки процесу програмування по Райлі
Введення.
1.1.1. Постановка завдання.
1.1.2. Проектування рішення.
1.1.3. Кодування алгоритму.
1.1.4. Супровід програми.
1.1.5. Програмна документація.
Висновок до п. 1.1
1.2. Визначення ЖЦПО по Леману.
Введення.
1.2.1 Визначення системи.
1.2.2. Реалізація.
1.2.3. Обслуговування.
Висновок до п. 1.2.
1.3. Фази і роботи ЖЦПО по Боемі
1.3.1. Каскадна модель.
1.3.2. Економічне обгрунтування каскадної моделі.
1.3.3. Удосконалення каскадної моделі.
1.3.4. Визначення фаз життєвого циклу.
1.3.5. Основні роботи над проектом.
Висновок.
Література.
Введення
Промислове застосування комп'ютерів і зростаючий попит на програми поставили актуальні завдання істотного підвищення продуктивності розробки ПЗ, розробки індустріальних методів планування і проектування програм, перенесення організаційно-технічних, техніко-економічних і соціально-психологічних прийомів, закономірностей і методів зі сфери матеріального виробництва в сферу застосування комп'ютерів . Комплексний підхід до процесів розробки, експлуатації і супроводу ПЗ висунув ряд нагальних проблем, вирішення яких виключить «вузькі місця» у проектуванні програм, зменшить терміни завершення робіт, поліпшить вибір і адаптацію існуючих програм, а може бути і визначить долю систем з вбудованими ЕОМ.
У практиці розробок великих програмних проектів часто відсутній єдиний підхід до оцінювання витрат праці, термінів проведення робіт і матеріальних витрат, що стримує підвищення продуктивності розробки ПЗ, а в кінцевому рахунку - ефективне управління життєвим циклом ПЗ. Оскільки програма будь-якого типу стає виробом (крім, може бути, навчальних, макетних програм), підхід до її виготовлення в чому повинен бути аналогічний підходу до виробництва промислової продукції, і питання проектування програм стають надзвичайно важливими. Ця ідея лежить в основі книги б.у. Боемі «Інженерне проектування програмного забезпечення», яку ми використовували при написанні даної курсової роботи. У цій книзі під проектуванням ПО розуміється процес створення проекту програмного виробу.
1 Життєвий цикл ПЗ
ВСТУП
ЖЦПО - це безперервний процес, який починається з моменту прийняття рішення про необхідність створення ПЗ і закінчується в момент його повного вилучення з експлуатації.
Існує декілька підходів при визначенні фаз та робіт життєвого циклу програмного забезпечення (ЖЦПО), кроків процесу програмування, каскадна і спіральна моделі. Але всі вони містять загальні основні компоненти: постановка завдання, проектування рішення, реалізація, обслуговування.
Найбільш відомою і повної, мабуть, є структура ЖЦПО по Боемі, що включає вісім фаз. Вона і буде представлена надалі найбільш детально.
Одним з можливих варіантів може послужити опис верхнього рівня з Леману, що включає три основні фази і що представляє опис ЖЦПО в самому загальному випадку.
І, для різноманітності, - наведемо кроки процесу програмування, представлені Д. Райлі в книзі «Використання мови Модула-2». Це подання, по-моєму, є досить простим і звичним, з нього і почнемо.
1.1 Кроки процесу програмування по Райлі
Введення
Процес програмування включає чотири кроки (рис. 1):
постановка задачі, тобто отримання адекватного уявлення про те, яке завдання має виконати програма;
проектування рішення вже поставленого завдання (загалом, таке рішення є менш формальним, ніж остаточна програма);
кодування програми, тобто переклад спроектованого рішення в програму, яка може бути виконана на машині;
супровід програми, тобто безперервний процес усунення в програмі неполадок і додавання нових можливостей.
SHAPE \ * MERGEFORMAT
Постановка завдання |
Проектування рішення |
Кодування алгоритму |
Супровід програми |
ДокументДокументДокумент |
Рис. 1.Четире кроку програмування.
Програмування починається з того моменту, коли користувач, тобто той, хто потребує програми для вирішення завдання, викладає проблему системного аналітику. Користувач і системний аналітик спільно визначають постановку задачі. Остання потім передається алгорітмісту, який відповідає за проектування рішення. Рішення (або алгоритм) представляє послідовність операцій, виконання яких призводить до вирішення завдання. Оскільки алгоритм часто не пристосований до виконання на машині, його слід перевести в машинну програму. Ця операція виконується кодувальником. За наступні зміни в програмі несе відповідальність супроводжуючий програміст. І системний аналітик, і алгорітміст, та кодер, і супроводжуючий програміст - всі вони є програмістами.
У разі великого програмного проекту число користувачів, системних аналітиків і алгорітмістов може виявитися значним. Крім того, може виникнути необхідність повернутися до попередніх кроків в силу непередбачених обставин. Все це служить додатковим аргументом на користь ретельного проектування програмного забезпечення: результати кожного кроку повинні бути повними, точними і зрозумілими.
1.1.1 Постановка завдання
Одним з найбільш важливих кроків програмування є постановка задачі. Вона виконує функції контракту між користувачем і програмістом (програмістами). Як і юридично погано складений контракт, погана постановка задачі марна. При гарній постановці завдання як користувач, так і програміст ясно і недвозначно представляють завдання, яку необхідно виконати, тобто в цьому випадку враховуються інтереси як користувача, так і програміста. Користувач може планувати використання ще нествореного програмного забезпечення, спираючись на знання того, що воно може. Гарна постановка завдання служить основою для формування її рішення.
Постановка завдання (специфікація програми); по суті, означає точне, повне і зрозуміле опис того, що відбувається при виконанні конкретної програми. Користувач зазвичай дивиться на комп'ютер, як на чорний ящик: для нього неважливо, як працює комп'ютер, а важливо, що може комп'ютер з того, що цікавить користувача. При цьому основна увага фокусується на взаємодії людини з машиною.
Характеристики Доброю Постановки Завдання:
Точність, тобто виключення будь-якої неоднозначності. Не повинно виникати питань щодо того, яким буде висновок програми при кожному конкретному введенні.
Повнота, тобто розгляд всіх варіантів для заданого введення, включаючи помилковий або непередбачений введення, і визначення відповідного висновку.
Ясність, тобто вона повинна бути зрозумілою і користувачеві і системного аналітику, оскільки постановка завдання - це єдиний контракт між ними.
Часто вимога точності, повноти і ясності знаходяться у протиріччі. Так, багато юридичних документи важко зрозуміти, тому що вони написані на формальній мові, що дозволяє гранично точно сформулювати ті чи інші положення, виключаючи будь-які самі незначні різночитання. Наприклад, деякі питання в екзаменаційних білетах іноді сформульовані настільки точно, що студент витрачає більше часу на те, щоб зрозуміти питання, ніж на те щоб на нього відповісти. Більше того, студент взагалі може не вловити основний зміст питання з-за великої кількості деталей. Найкраща постановка задачі та, при якій досягається баланс усіх трьох вимог.
Стандартна форма постановки завдання.
Розглянемо наступну постановку завдання: «Ввести три числа і вивести числа в порядку».
Така постановка не задовольняє наведеним вище вимогам: вона не є ні точної, ні повної, ні зрозумілої. Дійсно, чи повинні числа вводитися по одному на рядок або всі числа в одному рядку? Чи означає вираз «в порядку» упорядкування від більшого до меншого, від меншого до більшого або той же порядок, в якому вони були введені.
Очевидно, що така постановка не відповідає на безліч питань. Якщо ж врахувати відповіді на всі питання, то постановка задачі стане багатослівною і важкою для сприйняття. Тому Д. Райлі пропонує для постановки задачі користуватися стандартною формою, яка забезпечує максимальну точність, повноту, ясність і включає:
найменування завдання (схематичне визначення);
загальний опис (короткий виклад завдання);
введення;
висновок;
помилки (явно перераховані незвичайні варіанти введення, щоб показати користувачам і програмістам ті дії, які зробить машина в подібних ситуаціях);
приклад (хороший приклад може передати сутність завдання, а також проілюструвати різні випадки).
Приклад. Постановка завдання в стандартній формі.
НАЗВА
Сортування трьох цілих чисел.
ОПИС
Введення і виведення трьох цілих чисел, відсортованих від меншого числа до більшого.
ВВЕДЕННЯ
Вводяться три цілих числа по одному числу на рядку. При цьому цілим числом є одна або кілька послідовних десяткових цифр, яким може передувати знак плюс «+» або знак мінус «-».
ВИСНОВОК
Виводяться три введених цілих числа, причому всі три виводяться на одному рядку. Суміжні числа розділяються пропуском. Числа виводяться від меншого до більшого, зліва направо.
ПОМИЛКИ
1) Якщо введено менше трьох чисел, програма чекає додаткового введення.
2) Рядки введення, крім перших трьох, ігноруються.
3) Якщо будь-яка з перших трьох рядків містить більше одного цілого числа, то програма завершує роботу і видає повідомлення.
ПОМИЛКА ВВЕДЕННЯ - допускається тільки одне ціле число на рядку.
ПРИКЛАД:
введення ® - 3
2
+ 17
висновок ® - 3 2 + 17
1.1.2. Проектування рішення
Цей крок програмування є найбільш важким. На даній стадії постановка задачі має бути перетворена на алгоритм. Тому алгорітміст повинен володіти достатнім досвідом програмування і підходити до кожної нової задачі, спираючись на твердо встановлену методику проектування. На жаль, в даний час всі великі програми містять помилки, що призводить до кепським проектам. Погані проекти в свою чергу є наслідком складності завдань і використання неадекватних методів проектування. Щоб уникнути помилок в програмах, алгорітмісти повинні використовувати ретельно розроблені процедури конструювання, засновані на правилах логічного висновку.
Існують дві основні моделі висновку:
Перша модель відома як дедуктивний висновок. Цю форму логічного мислення обезсмертив знаменитий детектив Шерлок Холмс. Дедуктивна логіка застосовує загальні правила до конкретних випадків. Наприклад, Холмс міг вивести конкретне твердження «Дворецький є вбивцею» з більш загальних відомостей «Вбивця-блондин», а «Дворецький є єдиним блондином, якого можна підозрювати».
Друга модель - це індуктивний висновок, який є протилежністю дедуктивного висновку. Індуктивна логіка витягує загальні висновки з окремих випадків. Наприклад, індуктивний висновок може бути використаний, щоб обгрунтувати загальний висновок «сонце піднімається на сході» на підставі багатьох окремих спостережень того, що сонце завжди піднімалося на сході.
Ці два процеси виведення умовиводів - дедукція (від загального до конкретного) та індукція (від приватного до загального) - тісно пов'язані з двома найбільш широко поширеними методами проектування: «згори донизу» і «знизу вгору». Подібно дедукції, проектування «зверху вниз» починається з великого завдання, яка розбивається на підзадачі. Наприклад, проектувальник нового холодильника-морозильника на підставі вихідної безлічі специфікацій агрегату (тобто постановки задачі) повинен дати детальні схеми і специфікації остаточного продукту (тобто проект).
Якщо при цьому він використовує метод проектування «зверху вниз», то єдине завдання проектування може бути розбита на дві менші підзадачі: (1) проектування холодильного агрегату і (2) проектування морозилки.
Проте можна скористатися методом проектування «знизу вгору» і почати з проектування холодильного компресора, а потім охолоджують труб, агрегату або холодильної камери. У такому випадку цей вибір буде накладати певні обмеження на весь проект.
Завдання проектувальника - створення алгоритму, що виконує функції сполучної ланки між постановкою завдання і готова для виконання програмою. Перевірку створеного алгоритму, тобто наскільки останній відображає постановку завдання, здійснює системний аналітик. У силу цього і системний аналітик, і проектувальник повинні вміти читати і розуміти алгоритм. Кожен алгоритм записується на деякій псевдомова. Алгоритми, звані також псевдокод, не можуть бути виконані ні на якому комп'ютері.
1.1.3 Кодування алгоритму
Робота кодувальника полягає в перекладі алгоритму в програму. Для створення повної, точної та зрозумілої програми необхідні відповідні методи запису програм. Наприклад, кулінарні рецепти зазвичай записуються на природних мовах, таких, як англійська, французька, російська або японська. Програми ж пишуться на мовах програмування. В даний час жоден з природних мов не можна використовувати в якості мови програмування, так як вони занадто складні, щоб їх могли «розуміти» машини. На відміну від природних, мови програмування створені спеціально для такого подання рішення завдання, яке може бути виконано комп'ютером.
1.1.4 Супровід програми
Перш ніж завершити роботу, кодіровщік повинен переконатися, що програма відповідає псевдокод. Потім системний аналітик, алгорітміст і, що найголовніше, користувач повинні протестувати і підтвердити, що вона працює правильно. Після цього можна вважати, що програма готова для передачі користувачеві в комплекті з усією необхідною документацією.
Однак на цьому програмування не закінчується, далі слід крок супроводу. Справа в тому, що в програмі можуть бути помилки, зумовлені або неадекватною постановкою завдання, або тим, що проект не задовольняє постановці задачі або програма не відповідає проекту. Яка б не була причина, користувач має право вимагати коригування програми, оскільки він не уявляв, що програма буде працювати таким чином. Виправлення помилок є однією з головних завдань супроводу програм. Інший не менш важливим завданням супроводу програм є її модифікація, тобто додавання в програму нових можливостей або зміна існуючих. Користувач може змінити вимоги до роботи програми, що, у свою чергу, призведе до необхідності її переписати. Складність операцій із супроводу програми залежить від типу змін, які повинні бути зроблені: у гіршому випадку може знадобитися повна переробка програми від постановки до кодування. Зазвичай на супровід програми витрачається більше часу, ніж на її створення.
1.1.5 Програмна документація
Останньою складовою процесу програмування є документування. Воно включає широкий спектр описів, що полегшують процес програмування і збагачують результуючу програму. Постійне документування має становити невід'ємну частину кожного кроку програмування. Постановка завдання, проектні документи, алгоритми і програми - все це документи. Внутрішня документація, зазначена безпосередньо в програму, полегшує читання коду. Призначення навчального посібника (ще однієї форми документації) - навчити користувача застосовувати нову програму; довідкове керівництво дозволяє ознайомитися з описом команд програмного забезпечення.
Висновок до п.1.1.
Відповідно до моделі, представленої в цьому розділі, програмування можна розділити на чотири кроки: постановку задачі, проектування рішень, кодування програми, супровід програми. Додатково модель включає документування програми як дії, які необхідно виконувати протягом всього процесу програмування.
Модель програмування побудована спеціально для вирішення великих проблем, так як саме вони представляють інтерес для фахівців у галузі інформатики. Тим не менш, на практиці важливо використовувати ретельно вибрані інженерні методики проектування програм незалежно від розміру завдань: навички, набуті в процесі вирішення більш дрібних завдань, можуть бути закріплені і успішно реалізовані при вирішенні великих завдань.
Слід пам'ятати, що гарне програмування - це не кодування швидко знайденого рішення за допомогою будь-якої зручної методики, а ретельно інструментованого інженерна процедура, що дозволяє створити повне, точне і легко розуміється (ясна) програмне забезпечення.
1.2 Визначення ЖЦПО по Леману
Введення
У самому загальному випадку можна вважати, що життєвий цикл програмної системи складається з трьох фаз:
визначення;
реалізації;
обслуговування.
1.2.1 Визначення системи
Процес створення ПЗ починається з практичних пошуків, провідних до системного аналізу, завдання якого полягає у визначенні загальних вимог до системи і програм. Такий аналіз повинен, перш за все, встановити реальні потреби і цілі і по можливості виявити наявні методи, що дозволяють досягти поставленої мети. При необхідності аналіз може грунтуватися на математичних чи інших формальних схемах. Вважається, що при будь-якому підході зазначений аналіз повинен мати певну структуру і проводитися у відповідності з деякою теорією. Аналіз та внесення уточнень, здійснювані спільно з аналітиками та потенційними користувачами, повинні привести до вироблення остаточної специфікації вимог.
Процес складання такої специфікації має на меті одержання правильної технічного завдання, повного в сенсі відображення вимог і узгодженого з визначенням реалізації. За складанням специфікацій слід фаза проектування, сенс якої полягає в ідентифікації та структуризації даних, їх перетворення і організації їх передачі. Крім того, на цій фазі необхідно домогтися в певному сенсі оптимального розподілу функції системи, вибрати алгоритм і процедури, а також позначити системні компоненти й зв'язок між ними.
1.2.2 Реалізація
Завершивши проектування можна починати реалізацію системи. Однак на практиці фаза проектування та реалізації перекриваються. Таким чином, в міру здійснення ієрархічного процесу розбиття аналіз деяких елементів системи може бути визнаний достатньо повним для переходу до реалізації, в той час як інші елементи вимагають подальшого уточнення.
У ході процесу реалізації необхідно встановлювати правильність програми. Сучасні процедури здебільшого засновані на тестуванні, хоча в останні роки розширилося використання методів наскрізного структурного контролю та атестації програм.
У будь-якому випадку, тестування за допомогою виконання програми зазвичай здійснюється знизу вгору, на початку на блочному (модульному або процедурному рівні), потім функціонально, компонент за компонентом. У міру перевірки окремих компонентів вони об'єднуються в систему в процесі її компонування, після чого починаються системні випробування. У кінцевому підсумку, після того як незалежно буде засвідчено якість функціонування системи та оцінено її параметри, вона вважається готовою до випуску.
1.2.3 Обслуговування
Процес обслуговування починається відразу після випуску системи. Помилки підлягають виявленню і виправленню. Якщо нормальній роботі користувача перешкоджає помилка, то помилкову програму можна тимчасово виключити з системи або ж внести тимчасові або постійні виправлення до деяких або у всі використовувані системи. Постійне виправлення або зміну можна потім внести в новий випуск системи. Для того, щоб врахувати всі зміни і їх комбінації, створюються численні версії системних елементів. Головним завданням стає управління системної конфігурацією. Вирішальна роль в управлінні програмування належить допоміжним службам, які автоматично збирають і регулюють усі зміни в системі.
Висновок до п.1.2.
Метасистема, в рамках якої розвивається програма, містить істотно більшу кількість контурів зворотного зв'язку, ніж зазначено вище. Багато видів діяльності перекриваються, складним чином переплітаються і систематично повторюються. Тому досить обгрунтована модель ЖЦПО представлена Боемі.
1.3 Фази та роботи ЖЦПО по Боемі
1.3.1 Каскадна модель
Каскадна модель була введена в 70 - 80 рр.. Вона зручна для однорідних ПП, коли кожен додаток являло собою єдине ціле.
Основні характеристики моделі:
- Життєвий цикл розбивається на етапи (фази);
- Перехід з етапу на етап - тільки після повного завершення поточного етапу;
- Етап завершується випуском повного комплекту документації, достатньої для того, щоб робота могла бути виконана іншою командою розробників.
Головні характерні риси каскадної моделі наступні:
завершення кожної фази верифікацією і підтвердженням, мета яких - усунути можливо більше число проблем, пов'язаних з розробкою вироби;
циклічні повторення реалізованих фаз з можливо більш ранньої фази.
SHAPE \ * MERGEFORMAT
Рис.2. Каскадна модель ЖЦПО.
У каскадної моделі успішне закінчення однієї з фаз ЖЦПО означає досягнення відповідної мети інженерного програмування (див. п. 2.4.). До цих підцілі необхідно додати ще дві:
Детальна проектованих - отримання повних верифікованих специфікацій і структур управління і даних, інтерфейсних зв'язків, характеристик, основних алгоритмів та визначення умов роботи кожного програмного компонента.
Кодованого - отримання повного, веріфіцированного набору компонентів програми.
Основні переваги:
Формування повного набору проектної документації в кінці роботи над етапом. Документація відповідає критеріям повноти і завершеності;
Можливість планування термінів і витрат. Для цілого ряду ПП ця модель реалізована - це для систем, для яких на етапі аналізу можна точно і повно сформувати всі вимоги. Наприклад, складні обчислювальні програми.
Основні недоліки:
- Великі терміни від аналізу до завершення;
- Вимоги до ПЗ «заморожені» у вигляді ТЗ до кінця розробки.
1.3.2 Економічне обгрунтування каскадної моделі
Не заглиблюючись в економічний аналіз, якому б.у. Боемі приділяє велику увагу у книзі «Інженерне проектування програмного забезпечення», скажемо лише, що економічне обгрунтування каскадної моделі, орієнтованої на послідовне досягнення цілей, базується на двох головних передумовах:
Для отримання якісного програмного вироби (тобто такого, яке в повній мірі задовольняє всім цілям необхідного програмного вироби) необхідно в будь-якому випадку здійснити всі підцілі на кожному етапі.
Будь-яке інше впорядкування підцілей призводить до створення менш якісного програмного виробу.
1.3.3 Удосконалення каскадної моделі
Розглянемо одне з удосконалень ідеальної каскадної моделі - покрокову розробку.
Покрокова розробка є удосконаленням методу повторної розробки зі створенням прототипу і поуровневой розробкою зверху - вниз. Цей метод передбачає покрокове збільшення функціональних можливостей ПЗ в процесі розробки.
SHAPE \ * MERGEFORMAT
Як удосконаленої каскадної моделі покрокова розробка успішно застосовувалася при створенні як дуже великих, так і невеликих програмних виробів.
Головними перевагами покрокової розробки перед абсолютно повторної розробкою і поуровневой розробкою зверху - вниз є наступні:
використання послідовних розширень програми забезпечує набагато менш дорогий спосіб обліку в удосконаленому виробі досвіду користувачів, ніж при повторній розробці;
розширення функціональних можливостей набагато спрощує перевірку і корисніше, ніж проміжні вироби при поуровневой розробці.
Значення покрокової розробки полягає головним чином у зміні розподілу витрат праці на проект. Варіант каскадної моделі при покрокової розробки показаний на малюнку 3.
1.3.4 Визначення фаз життєвого циклу
Нижче будуть дані формулювання кінцевих цілей кожної фази для переходу до наступної фази. Для покрокової розробки наведені формулювання відносяться до кордонів фаз кожного кроку розширення.
Почати фазу планування та аналізу вимог. (Завершення концептуального огляду ЖЦПО.)
Отримання схваленої та підтвердженої архітектури системи з включенням основних угод про розподіл функцій між апаратурою і програмами. Отримання схваленого і підтвердженого загального уявлення про функціонування ПЗ з включенням основних угод про розподіл функцій між людиною і системою.
Формування загального плану ЖЦПО з визначенням основних етапів, ресурсів, обов'язків, термінів і головних робіт.
Завершити фазу планування та аналізу вимог. Почати фазу проектування виробу. (Завершення огляду вимог до ПЗ).
Формування детального плану розробки: детальних показників завершення етапів розробки, планів розподілу ресурсів, схем організаційної структури, обов'язків, термінів, робіт, методів і виробів.
Формування детального плану використання: пунктів плану розробки, зміст яких орієнтовано на навчання, перенесення програм, впровадження, експлуатацію та підтримку.
Формування детального плану налагодження вироби - план управління конфігурацією технічного забезпечення, план контролю якості, загальний план верифікації та підтвердження.
Схвалена і підтверджена специфікація вимог до ПЗ: функціональні, технічні та інтерфейсні специфікації, для яких підтверджені їх повнота, несуперечність, перевірюваність і здійсненність.
Схвалений (формально або неформально) договір на розробку, заснований на наведених вище пунктах.
Закінчити фазу проектування виробу. Почати фазу детального проектування. (Завершення аналізу результатів проектування виробу.)
Розробка верифікованої специфікації проекту програмного вироби:
формування ієрархії програмних компонентів, міжблокових інтерфейсів за даними і управління;
формування фізичної і логічної структур даних до рівня окремих полів;
розробка плану розподілу обчислювальних ресурсів (часу, пам'яті, точності);
верифікація повноти, несуперечності, здійсненності та обгрунтованості вимог.
Встановлення і вирішення всіх протиріч розробки, які підвищують ступінь ризику.
Розробка попереднього етапу комплексування та налагодження, плану керівництва для користувачів та прийомних випробувань.
Закінчити фазу детального проектування. Почати фазу кодування і автономного налагодження. (Завершення наскрізного контролю проекту або критичного поблочної аналізу проекту.)
Верифікований детальна специфікація кожного блоку:
специфікація кожної підпрограми, імені, призначення, припущень, розмірів, послідовності викликів, помилкових виходів, вхідних і вихідних даних, алгоритмів і логічної схеми;
опис бази даних до рівня окремих параметрів, символів і бітів;
верифікація повноти, несуперечності та відповідності вимогам проектних специфікацій системи і планам розподілу ресурсів.
Схвалений план приймальних випробувань.
Керівництва користувачеві, а також завершений попередній план комплексування і налагодження.
Закінчити фазу копіювання та налагодження. Почати фазу комплексування і налагодження. (Задоволення критеріїв автономного налагодження.)
Перевірка роботи всіх блоків не тільки для номінальних, але також для виняткових і граничних значень.
Перевірка всіх варіантів введення і виведення, включаючи повідомлення про помилки.
Виконання всіх операторів і всіх гілок передачі управління.
Перевірка виконання стандартів програмування.
Завершення поблочної документування внутрішньої структури.
Закінчити фазу комплексування і випробувань. Почати фазу впровадження. (Завершення аналізу результатів приймальних випробувань.)
Перевірка задоволення тесту прийомних випробувань програм:
перевірка задоволення вимогам до ПЗ;
демонстрація прийнятності зазначених у специфікаціях характеристик роботи в нештатних умовах.
Приймання поставляються програмних виробів, звітів, посібників, баз даних, специфікацій внутрішньої структури.
Закінчити фазу впровадження. Почати фазу експлуатації та супроводу. (Завершення аналізу приймання системи.)
Перевірка задовільності результатів приймальних випробувань системи.
Перевірка задовільності системних вимог.
Перевірка виробничої готовності ПЗ, апаратури, засобів обслуговування і персоналу.
Приймання поставляються та входять в систему виробів: апаратури, ПО, документації, засобів навчання та обслуговування.
Завершення всіх специфікованих робіт та введення системи в дію.
Закінчити фазу експлуатації та супроводу (шляхом зняття з виробництва).
Виконання всіх пунктів плану зняття з виробництва: перенесення програм, документування, створення архіву, перехід до нової системи.
1.3.5 Основні роботи над проектом
Аналіз вимог.
Проектування вироби.
Програмування.
Планування налагодження.
Верифікація та підтвердження.
Управління проектом.
Управління конфігурацією і контроль якості.
Документування.
Висновок
Отже, було розглянуто три підходи до визначення життєвого циклу ПЗ. На мій погляд, всі вони мають право на існування, тому що в тій чи іншій мірі відображають практику програмування. Тим більше, що легко можна виявити загальні моменти (ставиться завдання - визначається система - аналізуються вимоги; супровід програми - обслуговування - експлуатація та супровід).
Проте, треба зауважити, що визначення фаз і робіт ЖЦПО Боемі найбільш обгрунтовано, тому що спирається на більш орієнтований підхід в інженерному програмуванні (спрямований на отримання якісного програмного виробу та реалізацію ефективного процесу розробки та супроводу ПО) і обгрунтовується економічно.
Виходячи з даного звіту видно як важливо і необхідно знати потреби сучасного світу при складанні програмного продукту (вироби). Важливо при складанні програми для автоматизації, який або системи, враховувати те, що сучасний світ постійно змінюється, а значить повинна бути здатною до зміни і програма.
Важливо так само, при складанні програми, враховувати те, що програма повинна бути точною; повної за своїм змістом і придатною для роботи як з маленькими, так і з великими проблемами у відповідності зі своїм призначенням; ясною - для того, щоб користувач міг спокійно, без труднощів працювати з нею. А так само щоб програму в будь-який момент можна було б легко виправити або доповнити відповідно до зміненими вимогами в сучасному світі.
Слід пам'ятати, що гарне програмування - це не кодування швидко знайденого рішення за допомогою будь-якої зручної методики, а ретельно інструментованого інженерна процедура, що дозволяє створити повне, точне і легко розуміється (ясна) програмне забезпечення.
Література
1. Б.у. Боемі «Інженерне проектування програмного забезпечення». М.: Радіо і зв'язок. 1985.
2. Д. Райлі. «Використання мови Модула-2». М.: Мир. 1993.
3. Ю.В. Іванов «Програми та їх життєві цикли» (реферат з дисципліни «Метрологія ПЗ»). 1998.
Слід пам'ятати, що гарне програмування - це не кодування швидко знайденого рішення за допомогою будь-якої зручної методики, а ретельно інструментованого інженерна процедура, що дозволяє створити повне, точне і легко розуміється (ясна) програмне забезпечення.
1.2 Визначення ЖЦПО по Леману
Введення
У самому загальному випадку можна вважати, що життєвий цикл програмної системи складається з трьох фаз:
визначення;
реалізації;
обслуговування.
1.2.1 Визначення системи
Процес створення ПЗ починається з практичних пошуків, провідних до системного аналізу, завдання якого полягає у визначенні загальних вимог до системи і програм. Такий аналіз повинен, перш за все, встановити реальні потреби і цілі і по можливості виявити наявні методи, що дозволяють досягти поставленої мети. При необхідності аналіз може грунтуватися на математичних чи інших формальних схемах. Вважається, що при будь-якому підході зазначений аналіз повинен мати певну структуру і проводитися у відповідності з деякою теорією. Аналіз та внесення уточнень, здійснювані спільно з аналітиками та потенційними користувачами, повинні привести до вироблення остаточної специфікації вимог.
Процес складання такої специфікації має на меті одержання правильної технічного завдання, повного в сенсі відображення вимог і узгодженого з визначенням реалізації. За складанням специфікацій слід фаза проектування, сенс якої полягає в ідентифікації та структуризації даних, їх перетворення і організації їх передачі. Крім того, на цій фазі необхідно домогтися в певному сенсі оптимального розподілу функції системи, вибрати алгоритм і процедури, а також позначити системні компоненти й зв'язок між ними.
1.2.2 Реалізація
Завершивши проектування можна починати реалізацію системи. Однак на практиці фаза проектування та реалізації перекриваються. Таким чином, в міру здійснення ієрархічного процесу розбиття аналіз деяких елементів системи може бути визнаний достатньо повним для переходу до реалізації, в той час як інші елементи вимагають подальшого уточнення.
У ході процесу реалізації необхідно встановлювати правильність програми. Сучасні процедури здебільшого засновані на тестуванні, хоча в останні роки розширилося використання методів наскрізного структурного контролю та атестації програм.
У будь-якому випадку, тестування за допомогою виконання програми зазвичай здійснюється знизу вгору, на початку на блочному (модульному або процедурному рівні), потім функціонально, компонент за компонентом. У міру перевірки окремих компонентів вони об'єднуються в систему в процесі її компонування, після чого починаються системні випробування. У кінцевому підсумку, після того як незалежно буде засвідчено якість функціонування системи та оцінено її параметри, вона вважається готовою до випуску.
1.2.3 Обслуговування
Процес обслуговування починається відразу після випуску системи. Помилки підлягають виявленню і виправленню. Якщо нормальній роботі користувача перешкоджає помилка, то помилкову програму можна тимчасово виключити з системи або ж внести тимчасові або постійні виправлення до деяких або у всі використовувані системи. Постійне виправлення або зміну можна потім внести в новий випуск системи. Для того, щоб врахувати всі зміни і їх комбінації, створюються численні версії системних елементів. Головним завданням стає управління системної конфігурацією. Вирішальна роль в управлінні програмування належить допоміжним службам, які автоматично збирають і регулюють усі зміни в системі.
Висновок до п.1.2.
Метасистема, в рамках якої розвивається програма, містить істотно більшу кількість контурів зворотного зв'язку, ніж зазначено вище. Багато видів діяльності перекриваються, складним чином переплітаються і систематично повторюються. Тому досить обгрунтована модель ЖЦПО представлена Боемі.
1.3 Фази та роботи ЖЦПО по Боемі
1.3.1 Каскадна модель
Каскадна модель була введена в 70 - 80 рр.. Вона зручна для однорідних ПП, коли кожен додаток являло собою єдине ціле.
Основні характеристики моделі:
- Життєвий цикл розбивається на етапи (фази);
- Перехід з етапу на етап - тільки після повного завершення поточного етапу;
- Етап завершується випуском повного комплекту документації, достатньої для того, щоб робота могла бути виконана іншою командою розробників.
Головні характерні риси каскадної моделі наступні:
завершення кожної фази верифікацією і підтвердженням, мета яких - усунути можливо більше число проблем, пов'язаних з розробкою вироби;
циклічні повторення реалізованих фаз з можливо більш ранньої фази.
SHAPE \ * MERGEFORMAT
Проектування вироби Верифікація |
Детальне проектування Верифікація |
Кодування Автономна налагодження |
Впровадження Системна налагодження |
Комплексування Верифікація вироби |
Функціонування і супровід Повторне підтвердження |
Рис.2. Каскадна модель ЖЦПО.
У каскадної моделі успішне закінчення однієї з фаз ЖЦПО означає досягнення відповідної мети інженерного програмування (див. п. 2.4.). До цих підцілі необхідно додати ще дві:
Детальна проектованих - отримання повних верифікованих специфікацій і структур управління і даних, інтерфейсних зв'язків, характеристик, основних алгоритмів та визначення умов роботи кожного програмного компонента.
Кодованого - отримання повного, веріфіцированного набору компонентів програми.
Основні переваги:
Формування повного набору проектної документації в кінці роботи над етапом. Документація відповідає критеріям повноти і завершеності;
Можливість планування термінів і витрат. Для цілого ряду ПП ця модель реалізована - це для систем, для яких на етапі аналізу можна точно і повно сформувати всі вимоги. Наприклад, складні обчислювальні програми.
Основні недоліки:
- Великі терміни від аналізу до завершення;
- Вимоги до ПЗ «заморожені» у вигляді ТЗ до кінця розробки.
1.3.2 Економічне обгрунтування каскадної моделі
Не заглиблюючись в економічний аналіз, якому б.у. Боемі приділяє велику увагу у книзі «Інженерне проектування програмного забезпечення», скажемо лише, що економічне обгрунтування каскадної моделі, орієнтованої на послідовне досягнення цілей, базується на двох головних передумовах:
Для отримання якісного програмного вироби (тобто такого, яке в повній мірі задовольняє всім цілям необхідного програмного вироби) необхідно в будь-якому випадку здійснити всі підцілі на кожному етапі.
Будь-яке інше впорядкування підцілей призводить до створення менш якісного програмного виробу.
1.3.3 Удосконалення каскадної моделі
Розглянемо одне з удосконалень ідеальної каскадної моделі - покрокову розробку.
Покрокова розробка є удосконаленням методу повторної розробки зі створенням прототипу і поуровневой розробкою зверху - вниз. Цей метод передбачає покрокове збільшення функціональних можливостей ПЗ в процесі розробки.
SHAPE \ * MERGEFORMAT
Детальне проектування Верифікація |
Кодування Автономна налагодження |
Комплексування Верифікація вироби |
Впровадження Системна налагодження |
Експлуатація та супровід Переподтвержденіе |
Аналіз здійсненності моделі Підтвердження |
Планування і аналіз вимог до ПЗ Підтвердження |
Проектування вироби Верифікація |
Детальне проектування Верифікація |
Кодування Автономна налагодження |
Комплексування ... |
Детальне проектування Верифікація |
Кодування ... |
Рис.3. Каскадна модель з використанням покрокової розробки. |
Як удосконаленої каскадної моделі покрокова розробка успішно застосовувалася при створенні як дуже великих, так і невеликих програмних виробів.
Головними перевагами покрокової розробки перед абсолютно повторної розробкою і поуровневой розробкою зверху - вниз є наступні:
використання послідовних розширень програми забезпечує набагато менш дорогий спосіб обліку в удосконаленому виробі досвіду користувачів, ніж при повторній розробці;
розширення функціональних можливостей набагато спрощує перевірку і корисніше, ніж проміжні вироби при поуровневой розробці.
Значення покрокової розробки полягає головним чином у зміні розподілу витрат праці на проект. Варіант каскадної моделі при покрокової розробки показаний на малюнку 3.
1.3.4 Визначення фаз життєвого циклу
Нижче будуть дані формулювання кінцевих цілей кожної фази для переходу до наступної фази. Для покрокової розробки наведені формулювання відносяться до кордонів фаз кожного кроку розширення.
Почати фазу планування та аналізу вимог. (Завершення концептуального огляду ЖЦПО.)
Отримання схваленої та підтвердженої архітектури системи з включенням основних угод про розподіл функцій між апаратурою і програмами. Отримання схваленого і підтвердженого загального уявлення про функціонування ПЗ з включенням основних угод про розподіл функцій між людиною і системою.
Формування загального плану ЖЦПО з визначенням основних етапів, ресурсів, обов'язків, термінів і головних робіт.
Завершити фазу планування та аналізу вимог. Почати фазу проектування виробу. (Завершення огляду вимог до ПЗ).
Формування детального плану розробки: детальних показників завершення етапів розробки, планів розподілу ресурсів, схем організаційної структури, обов'язків, термінів, робіт, методів і виробів.
Формування детального плану використання: пунктів плану розробки, зміст яких орієнтовано на навчання, перенесення програм, впровадження, експлуатацію та підтримку.
Формування детального плану налагодження вироби - план управління конфігурацією технічного забезпечення, план контролю якості, загальний план верифікації та підтвердження.
Схвалена і підтверджена специфікація вимог до ПЗ: функціональні, технічні та інтерфейсні специфікації, для яких підтверджені їх повнота, несуперечність, перевірюваність і здійсненність.
Схвалений (формально або неформально) договір на розробку, заснований на наведених вище пунктах.
Закінчити фазу проектування виробу. Почати фазу детального проектування. (Завершення аналізу результатів проектування виробу.)
Розробка верифікованої специфікації проекту програмного вироби:
формування ієрархії програмних компонентів, міжблокових інтерфейсів за даними і управління;
формування фізичної і логічної структур даних до рівня окремих полів;
розробка плану розподілу обчислювальних ресурсів (часу, пам'яті, точності);
верифікація повноти, несуперечності, здійсненності та обгрунтованості вимог.
Встановлення і вирішення всіх протиріч розробки, які підвищують ступінь ризику.
Розробка попереднього етапу комплексування та налагодження, плану керівництва для користувачів та прийомних випробувань.
Закінчити фазу детального проектування. Почати фазу кодування і автономного налагодження. (Завершення наскрізного контролю проекту або критичного поблочної аналізу проекту.)
Верифікований детальна специфікація кожного блоку:
специфікація кожної підпрограми, імені, призначення, припущень, розмірів, послідовності викликів, помилкових виходів, вхідних і вихідних даних, алгоритмів і логічної схеми;
опис бази даних до рівня окремих параметрів, символів і бітів;
верифікація повноти, несуперечності та відповідності вимогам проектних специфікацій системи і планам розподілу ресурсів.
Схвалений план приймальних випробувань.
Керівництва користувачеві, а також завершений попередній план комплексування і налагодження.
Закінчити фазу копіювання та налагодження. Почати фазу комплексування і налагодження. (Задоволення критеріїв автономного налагодження.)
Перевірка роботи всіх блоків не тільки для номінальних, але також для виняткових і граничних значень.
Перевірка всіх варіантів введення і виведення, включаючи повідомлення про помилки.
Виконання всіх операторів і всіх гілок передачі управління.
Перевірка виконання стандартів програмування.
Завершення поблочної документування внутрішньої структури.
Закінчити фазу комплексування і випробувань. Почати фазу впровадження. (Завершення аналізу результатів приймальних випробувань.)
Перевірка задоволення тесту прийомних випробувань програм:
перевірка задоволення вимогам до ПЗ;
демонстрація прийнятності зазначених у специфікаціях характеристик роботи в нештатних умовах.
Приймання поставляються програмних виробів, звітів, посібників, баз даних, специфікацій внутрішньої структури.
Закінчити фазу впровадження. Почати фазу експлуатації та супроводу. (Завершення аналізу приймання системи.)
Перевірка задовільності результатів приймальних випробувань системи.
Перевірка задовільності системних вимог.
Перевірка виробничої готовності ПЗ, апаратури, засобів обслуговування і персоналу.
Приймання поставляються та входять в систему виробів: апаратури, ПО, документації, засобів навчання та обслуговування.
Завершення всіх специфікованих робіт та введення системи в дію.
Закінчити фазу експлуатації та супроводу (шляхом зняття з виробництва).
Виконання всіх пунктів плану зняття з виробництва: перенесення програм, документування, створення архіву, перехід до нової системи.
1.3.5 Основні роботи над проектом
Аналіз вимог.
Проектування вироби.
Програмування.
Планування налагодження.
Верифікація та підтвердження.
Управління проектом.
Управління конфігурацією і контроль якості.
Документування.
Висновок
Отже, було розглянуто три підходи до визначення життєвого циклу ПЗ. На мій погляд, всі вони мають право на існування, тому що в тій чи іншій мірі відображають практику програмування. Тим більше, що легко можна виявити загальні моменти (ставиться завдання - визначається система - аналізуються вимоги; супровід програми - обслуговування - експлуатація та супровід).
Проте, треба зауважити, що визначення фаз і робіт ЖЦПО Боемі найбільш обгрунтовано, тому що спирається на більш орієнтований підхід в інженерному програмуванні (спрямований на отримання якісного програмного виробу та реалізацію ефективного процесу розробки та супроводу ПО) і обгрунтовується економічно.
Виходячи з даного звіту видно як важливо і необхідно знати потреби сучасного світу при складанні програмного продукту (вироби). Важливо при складанні програми для автоматизації, який або системи, враховувати те, що сучасний світ постійно змінюється, а значить повинна бути здатною до зміни і програма.
Важливо так само, при складанні програми, враховувати те, що програма повинна бути точною; повної за своїм змістом і придатною для роботи як з маленькими, так і з великими проблемами у відповідності зі своїм призначенням; ясною - для того, щоб користувач міг спокійно, без труднощів працювати з нею. А так само щоб програму в будь-який момент можна було б легко виправити або доповнити відповідно до зміненими вимогами в сучасному світі.
Слід пам'ятати, що гарне програмування - це не кодування швидко знайденого рішення за допомогою будь-якої зручної методики, а ретельно інструментованого інженерна процедура, що дозволяє створити повне, точне і легко розуміється (ясна) програмне забезпечення.
Література
1. Б.у. Боемі «Інженерне проектування програмного забезпечення». М.: Радіо і зв'язок. 1985.
2. Д. Райлі. «Використання мови Модула-2». М.: Мир. 1993.
3. Ю.В. Іванов «Програми та їх життєві цикли» (реферат з дисципліни «Метрологія ПЗ»). 1998.