Життєвий цикл програмного забезпечення (ЖЦ ПЗ). Життєвий цикл програми Поняття життєвого циклу програми і його етапи

Тема: Класичні та гнучкі моделі ЖЦПП: визначення, опис, відмінні особливості, Послідовність етапів. Методи вибору моделі ЖЦПП при розробці ПЗ різних предметних областей.

Джерело інформації https://www.intuit.ru/studies/courses/3632/874/print_lecture/14297

Моделі і стадії ЖЦ ПО

Під моделлю ЖЦ ПО розуміється структура, що визначає послідовність виконання і взаємозв'язку процесів, дій і завдань протягом ЖЦ ПО. Модель ЖЦ залежить від специфіки, масштабу і складності проекту і специфіки умов, в яких система створюється і функціонує.

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

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

Під стадією (фазою) створення ПО розуміється частина процесу створення ПО, обмежена деякими тимчасовими рамками і закінчується випуском конкретного продукту (моделей ПО, програмних компонентів, документації тощо.), Що визначається заданими для даної стадії вимогами. Стадії створення ПО виділяються з міркувань раціонального планування і організації робіт, що закінчуються заданими результатами. До складу ЖЦ ПО зазвичай включаються такі стадії:

формування вимог до ПЗ;
проектування (розробка системного проекту);
реалізація (може бути розбита на підетапи: детальне проектування, кодування);
тестування (може бути розбите на автономне та комплексне тестування і інтеграцію);
введення в дію (впровадження);
експлуатація та супровід;
зняття з експлуатації.

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

Стадія формування вимог до ПЗ є однією з найважливіших і визначає значною (навіть вирішальною!) Мірою успіх всього проекту. Початком цієї стадії є отримання схваленої і затвердженої архітектури системи з включенням основних угод про розподіл функцій між апаратурою і програмами. Цей документ повинен також містити підтвердження загального уявлення про функціонування ПО з включенням основних угод про розподіл функцій між людиною і системою.

Стадія формування вимог до ПЗ включає наступні етапи.

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

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

моделі "AS-IS" ( "як є"), що відбиває існуюче на момент обстеження стан справ в організації і дозволяє зрозуміти, яким чином працює дана організація, а також виявити вузькі місця і сформулювати пропозиції щодо поліпшення ситуації;
моделі "TO-BE" ( "як повинно бути"), що відбиває уявлення про нові технології роботи організації.

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

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

Стадія проектування включає наступні етапи.

Розробка системного проекту ПО. На цьому етапі дається відповідь на питання "Що повинна робити майбутня система? ", А саме: визначаються архітектура системи, її функції, зовнішні умови функціонування, інтерфейси і розподіл функцій між користувачами і системою, вимоги до програмних і інформаційним компонентів, Склад виконавців і терміни розробки, план налагодження ПО і контроль якості.

Основу системного проекту складають моделі проектованої системи, які будуються на моделі "TO-BE". Результатом розробки системного проекту повинна бути схвалена і підтверджена специфікація вимог до ПО: функціональні, технічні та інтерфейсні специфікації, для яких підтверджена їх повнота, проверяемость і здійсненність.
Розробка детального (технічного) проекту. На цьому етапі здійснюється власне проектування ПО, що включає проектування архітектури системи і детальне проектування. Таким чином, дається відповідь на питання: "Як побудувати систему, щоб вона задовольняла вимогам?"

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

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

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

Стадія реалізації - виконання таких робіт.

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

Зовнішні специфікації повинні містити такі відомості:
- ім'я модуля - вказується ім'я, яке використовується для виклику модуля (для модуля з декількома входами для кожного входу повинні бути окремі специфікації);
- функція - дається визначення функції або функцій, які виконуються модулем;
- список параметрів (число і порядок руху), що передаються модулю;
- вхідні параметри - точний опис всіх даних, що повертаються модулем (повинно бути визначено поведінку модуля при будь-яких вхідних умовах);
- зовнішні ефекти (друк повідомлення, читання запиту з терміналу і т. п.).
Проектування логіки модулів і програмування (кодування) модулів.
Перевірка правильності модулів.
Тестування модулів.
Опис бази даних до рівня окремих параметрів, символів і бітів.
План приймальних випробувань.
Керівництво користувачеві.
Попередній план комплексування і налагодження. Зміст наступних стадій в основному збігається з відповідними процесами ЖЦ ПО. Взагалі технологічні стадії виділяються виходячи з міркувань розумного і раціонального планування і організації робіт. Можливий варіант взаємозв'язку і стадій робіт з процесами ЖЦ ПО показаний на малюнку.

Мал. 1.

Види моделей ЖЦ ПО

Каскадна модель (класичний життєвий цикл)

Ця модель зобов'язана своєю появою У. Ройс (1970 р). Модель має й іншу назву - водоспад (waterfall). Особливість моделі - перехід на наступний щабель здійснюється тільки після того, як буде повністю завершена робота на попередній стадії; повернень на пройдені стадії не передбачено.

Мал. 2.

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

переваги каскадної моделі:

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

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

недоліки каскадної моделі:

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

Ітераційна модель ЖЦ ПС

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

Мал. 3.

У итерационной моделі недоліки проектування і програмування можуть бути усунені пізніше шляхом часткового повернення на попередню стадію. Чим нижче рівень виявлення помилки, тим дорожче її виправлення. Якщо вартість зусиль, необхідних для виявлення та усунення помилок на стадії написання коду, прийняти за одиницю, то вартість виявлення і усунення помилки на стадії вироблення вимог буде в 5-10 разів менше, а вартість виявлення і усунення помилки на стадії супроводу - в 20 разів більше.

Мал. 4.

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

макетування

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

Модель може набувати таких форм.

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

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

Мал. 5.

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

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

замовник може прийняти макет за продукт;
розробник може прийняти макет за продукт.

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

Мал. 6.

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

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

Стратегії конструювання ПО

Існує три стратегії конструювання програмних систем:

одноразовий прохід (каскадна стратегія, розглянута вище) - лінійна послідовність етапів конструювання;
інкрементна стратегія. На початку процесу визначаються всі призначені для користувача і системні вимоги, решта конструювання виконується у вигляді послідовності версій. Перша версія реалізує частину запланованих можливостей, наступна версія реалізує додаткові можливостіі т. д., поки не буде отримана повна система;
еволюційна стратегія. Система також будується в вигляді послідовності версій, але на початку процесу визначаються не всі вимоги. Вимоги уточнюються в результаті розробки версій. Характеристики стратегій конструювання ПО з відповідно до вимог стандарту IEEE / EIA 12207 наведені в таблиці 1.

Інкрементна модель

Інкрементна модель є класичним прикладом инкрементной стратегії конструювання. Вона об'єднує елементи послідовної Водоспадної моделі з итерационной філософією макетування (запропонована Б. Боема як удосконалення каскадної моделі). Кожна лінійна послідовність тут виробляє поставляється інкремент ПО. Наприклад, ПО для обробки слів в 1-м Інкремент (версії) реалізує функції базової обробки файлів, функції редагування та документування; у 2-му Інкремент - більш складні можливості редагування та документування; в 3-м Інкремент - перевірку орфографії і граматики; в 4-му Інкремент - можливості компонування сторінки.

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

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

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

Мал. 7.

Спіральна модель ЖЦ ПО

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

Мал. 8.

Планування - визначення цілей, варіантів і обмежень.
Аналіз ризику - аналіз варіантів і розпізнавання / вибір ризику.
Конструювання - розробка продукту наступного рівня.
Оцінювання - оцінка замовником поточних результатів конструювання.

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

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

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

Ці дії пронумеровані і мають такий зміст:

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

переваги спіральної моделі:

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

недоліки спіральної моделі:

порівняльна новизна (відсутня достатня статистика ефективності моделі);
підвищені вимоги до замовника;
труднощі контролю і управління часом розробки.

Модель спірального процесу розробки є найбільш поширеною в даний час. Найвідомішими її варіантами є RUP (Rational Unified Process) від фірми Rational і MSF (Microsoft Solution Framework). В якості мови моделювання використовується мова UML (Unified Modeling Language). Створення системи передбачається проводити ітераційно, рухаючись по спіралі і, проходячи через одні й ті ж стадії, на кожному витку уточнювати характеристики майбутнього продукту. Здавалося б, тепер все добре: і планується тільки те, що можна передбачити, розробляється то, що заплановано, і користувачі починають знайомитися з продуктом заздалегідь, маючи можливість внести необхідні корективи.

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

Раціональний уніфікований процес

раціональний уніфікований процес(Rational Unified Process, RUP) - одна з кращих методологій розробки програмного забезпечення. Грунтуючись на досвіді багатьох успішних програмних проектів, RUP дозволяє створювати складні програмні системи, ґрунтуючись на індустріальних методах розробки. Передумови для розробки RUP зародилися на початку 1980-х рр. в Rational Software corporation. На початку 2003 р Rational придбала IBM. Одним з основних стовпів, на які спирається RUP, є процес створення моделей за допомогою уніфікованої мови моделювання (UML).

RUP - одна з спіральних методологій розробки програмного забезпечення. Методологія підтримується і розвивається компанією Rational Software. В якості мови моделювання в загальній базізнань використовується мова Unified Modelling Language (UML). Ітераційна і інкрементна розробка програмного забезпечення в RUP передбачає поділ проекту на кілька проектів, які виконуються послідовно, і кожна ітерація розробки чітко визначена набором цілей, які повинні бути досягнуті в кінці ітерації. Кінцева ітерація передбачає, що набір цілей ітерації повинен в точності збігатися з набором цілей, зазначених замовником продукту, тобто всі вимоги повинні бути виконані.

Процес передбачає еволюцію моделей; ітерація циклу розробки однозначно відповідає певній версії моделі програмного забезпечення. Кожна з ітерацій містить елементи управління життєвим циклом програмного забезпечення: Аналіз і дизайн (моделювання), реалізація, інтегрування, тестування, впровадження. У цьому сенсі RUP є реалізацією спіральної моделі, Хоча досить часто зображується у вигляді графіка-таблиці ..

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

Мал. 9.

По осі часу життєвий цикл ділиться на чотири основні фази.

Початок (Inception) - формування концепції проекту, розуміння того, що ми створюємо, уявлення про продукт (vision), розробка бізнес-плану (business case), підготовка прототипу програми або часткового вирішення. Це фаза збору інформації та аналізу вимог, визначення способу проекту в цілому. Мета - отримати підтримку і фінансування. У кінцевій ітерації результат цього етапу - технічне завдання.
Проектування, розробка (Elaboration) - уточнення плану, розуміння того, як ми це створюємо, проектування, планування необхідних дій та ресурсів, деталізація особливостей. Завершується етап виконується архітектурою, коли всі архітектурні рішення прийняті і ризики враховані. Виконується архітектура являє собою працює програмне забезпечення, яке демонструє реалізацію основних архітектурних рішень. У кінцевій ітерації це - технічний проект.
Реалізація, створення системи (Construction) - етап розширення функціональності системи, закладеної в архітектурі. У кінцевій ітерації це - робочий проект.
Впровадження, розгортання (Transition). Створення кінцевої версії продукту. Фаза впровадження продукту, постачання товару конкретного користувача (тиражування, доставка і навчання).

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

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

Бізнес-аналіз та моделювання (Business modeling) забезпечує реалізацію принципів моделювання з метою вивчення бізнесу організації і накопичення знань про нього, оптимізації бізнес-процесів і прийняття рішення про їх часткової або повної автоматизації.
Управління вимогами (Requirements) присвячено отриманню інформації від зацікавлених осіб та її перетворення в набір вимог, що визначають зміст запропонованої системи і детально описують очікування від того, що система повинна робити.
Аналіз і проектування (Analysis and design) охоплює процедури перетворення вимог в проміжні описи (моделі), що представляють, як ці вимоги повинні бути реалізовані.
Реалізація (Implementation) охоплює розробку коду, тестування на рівні розробників і інтеграцію компонентів, підсистем і всієї системи відповідно до встановлених специфікаціями.
Тестування (Test) присвячено оцінці якості створюваного продукту.
Розгортання (Deployment) охоплює операції, які відбуваються при передачі продуктів замовникам і забезпеченні доступності продукту кінцевим користувачам.
Конфігураційне управління і управління змінами (Configuration management) присвячено синхронізації проміжних і кінцевих продуктів і управління їх розвитком в ході проекту і пошуком прихованих проблем.
Управління проектом (Management) присвячено плануванню проекту, управління ризиками, контролю ходу його виконання та безперервної оцінки ключових показників.
Управління середовищем (Environment) включає елементи формування середовища розробки інформаційної системи і підтримки проектної діяльності.

Залежно від специфіки проекту можуть бути використані будь-які засоби IBM Rational, а також третіх фірм. У RUP рекомендовано дотримуватися шести практикам, що дозволяє успішно розробляти проект: ітеративна розробка; управління вимогами; використання модульних архітектур; візуальне моделювання; перевірка якості; відстеження змін.

Невід'ємну частину RUP складають артефакти (artefact), прецеденти (precedent) і ролі (role). Артефакти - це деякі продукти проекту, породжувані або використовуються в ньому при роботі над остаточним продуктом. Прецеденти - це послідовності дій, які виконуються системою для отримання спостережуваного результату. Фактично будь-який результат роботи окремих людей чи груп є артефактом, будь то документ аналізу, елемент моделі, файл коду, тестовий скрипт, опис помилки і т. П. За створення того чи іншого виду артефактів відповідають певні фахівці. Таким чином, RUP чітко визначає обов'язки - ролі - кожного члена групи розробки на тому чи іншому етапі, тобто коли і хто повинен створити той чи інший артефакт. Весь процес розробки програмної системи розглядається в RUP як процес створення артефактів - починаючи з первинних документів аналізу і закінчуючи виконуваними модулями, посібниками користувача і т.п.

Для комп'ютерної підтримки процесів RUP в IBM розроблено широкий набір інструментальних засобів:

Rational Rose - CASE- засіб візуального моделюванняінформаційних систем, що має можливості генерування елементів коду. Спеціальна редакція продукту - Rational Rose RealTime - дозволяє на виході отримати виконуваний модуль;
Rational Requisite Pro - засіб управління вимогами, яке дозволяє створювати, структурувати, встановлювати пріоритети, відстежувати, контролювати зміни вимог, що виникають на будь-якому етапі розробки компонентів додатка;
Rational ClearQuest - продукт для управління змінами та відстеження дефектів в проекті (bug tracking), тісно інтегрується із засобами тестування і управління вимогами і представляє собою єдине середовище для зв'язування всіх помилок і документів між собою;
Rational SoDA - продукт для автоматичного генерування проектної документації, що дозволяє встановити корпоративний стандарт на внутрішньофірмові документи. Можливо також приведення документації до вже існуючим стандартам (ISO, CMM);
Rational Purify, Rational Quantify Rational PureCoverage, - кошти тестування і налагодження;
Rational Visual Quantify - засіб вимірювання характеристик для розробників додатків і компонентів, що програмують на C / C ++, Visual Basic і Java; допомагає визначати і усувати вузькі місця в продуктивності ПО;
Rational Visual PureCoverage - автоматично визначає області коду, зміст яких не повинен тестування;
Rational ClearCase - продукт для управління конфігурацією програм (Rational "s Software Configuration Management, SCM), що дозволяє проводити версійність контроль всіх документів проекту. З його допомогою можна підтримувати кілька версій проектів одночасно, швидко переключаючись між ними. Rational Requisite Pro підтримує оновлення та відстежує зміни у вимогах для групи розробників;
SQA TeamTest - засіб автоматизації тестування;
Rational TestManager - система управління тестуванням, яка об'єднує всі пов'язані з тестуванням інструментальні засоби, артефакти, сценарії і дані;
Rational Robot - інструмент для створення, модифікації та автоматичного запуску тестів;
SiteLoad, SiteCheck - кошти тестування Web-сайтів на продуктивність і наявність непрацюючих посилань;
Rational PerformanceStudio - вимір і передбачення характеристик продуктивності систем.

Цей набір продуктів постійно вдосконалюється і поповнюється. Так, наприклад, недавній продукт IBM Rational Software Architect (RSA) є частиною IBM Software Development Platform - набору інструментів, що підтримують життєвий цикл розробки програмних систем. Продукт IBM Rational Software Architect призначений для побудови моделей розробляються програмних систем з використанням уніфікованої мови моделювання UML 2.0, перш за все моделей архітектури розробляється. Проте, RSA об'єднує в собі функції таких програмних продуктів, як Rational Application Developer, Rational Web Developer і Rational Software Modeler, тим самим надаючи можливість архітекторам і аналітикам створювати різні уявлення розробляється інформаційної системи з використанням мови UML 2.0, а розробникам - виконувати розробку J2EE, XML, веб-сервісів і т.д.

Дотримуючись принципів RUP, Rational Software Architect дозволяє створювати необхідні моделі в рамках робочих процесів таких дисциплін, як:

бізнес-аналіз і моделювання (Business modeling);
управління вимогами (Requirements);
аналіз і проектування (Analysis and Design);
реалізація (Implementation).

Крім того, Rational Software Architect підтримує технологію розробки, керованої моделями (model-driven development, MDD), яка дозволяє моделювати програмне забезпечення на різних рівнях абстракції з можливістю трасуванню.

MSF (Microsoft Solution Framework)

У 1994 році, прагнучи досягти максимальної віддачі від IT-проектів, Microsoft випустила в світ пакет посібників з ефективного проектування, розробки, впровадження та супроводу рішень, побудованих на основі своїх технологій. Ці знання базуються на досвіді, отриманому Microsoft при роботі над великими проектамипо розробці і супроводу програмного забезпечення, досвід консультантів Microsoft і кращому з того, що накопичила на даний момент IT-індустрія. Все це представлено у вигляді двох взаємопов'язаних і добре доповнюють один одного областей знань: Microsoft Solutions Framework (MSF) і Microsoft Operations Framework (MOF).

Слід зазначити, що Microsoft розробила на базі загальних методів MSF методики для прикладного та спеціалізованого застосування. Причому Microsoft сертифікує експертів саме по прикладних знань в застосуванні MSF (наприклад, сертифікація MCTS 74-131 з експертизи в методиці управління проектами). Перед тим як вивчати методи MSF, слід спочатку визначити, який прикладної варіант MSF мається на увазі.

Найбільш популярні прикладні варіанти MSF, розроблені Microsoft:

методика впровадження рішень в області управління проектами;
методика управління IT-проектами на базі методологій MSF і Agile.

Важливість прикладних варіантів MSF підкреслює той факт, що в "чистому варіанті" саму методику MSF в своїх IT-проектах компанія Microsoft не використовує. У проектах Microsoft Consulting Services застосовується гібридна методологія MSF і Agile. Незважаючи на зовнішні істотні відмінності прикладних варіантів MSF, розроблених експертами Microsoft, база методів MSF для них залишається спільною і відображає загальні методологічні підходи до ітеративному ведення проектів.

MOF покликаний забезпечити організації, що створюють критично важливі (mission-critical) IT рішення на базі продуктів і технологій Майкрософт, технічним керівництвом по досягненню їх надійності (reliability), доступності (availability), зручності супроводу(Supportability) і керованості (manageability). MOF зачіпає питання, пов'язані з організацією персоналу і процесів; технологіями і менеджментом в умовах складних (complex), розподілених (distributed) і різнорідних (heterogeneous) IT-середовищ. MOF заснований на кращих виробничих методиках, зібраних в IT Infrastructure Library (ITIL), складеної Central Computer and Telecommunications Agency - Агентством уряду Великобританії.

Створення бізнес-рішення в рамках відведених часу і бюджету вимагає наявності випробуваної методологічної основи. MSF пропонує перевірені методики для планування, проектування, розробки та впровадження успішних IT-рішень. Завдяки своїй гнучкості, масштабованості і відсутності жорстких інструкцій MSF здатний задовольнити потреби організації або проектної групи будь-якого розміру. Методологія MSF складається з принципів, моделей і дисциплін з управління персоналом, процесами, технологічними елементами і пов'язаними з усіма цими факторами питаннями, характерними для більшості проектів. MSF складається з двох моделей і трьох дисциплін. Вони докладно описані в 5 whitepapers. Починати вивчення MSF краще з моделей (модель проектної групи, модель процесів), а потім перейти до дисциплін (дисципліна управління проектами, дисципліна управління ризиками, дисципліна управління підготовкою).

Модель процесів MSF (MSF process model) представляє загальну методологію розробки та впровадження IT-рішень. Особливість цієї моделі полягає в тому, що завдяки своїй гнучкості та відсутності жорстко нав'язуваних процедур вона може бути застосована при розробці досить широкого кола IT-проектів. Ця модель поєднує в собі властивості двох стандартних виробничих моделей: каскадної (waterfall) і спіральної (spiral). Модель процесів в MSF 3.0 була доповнена ще одним інноваційним аспектом: вона покриває весь життєвий цикл створення рішення, починаючи з його відправної точки і закінчуючи безпосередньо впровадженням. Такий підхід допомагає проектним групам сфокусувати свою увагу на бізнесотдаче (business value) рішення, оскільки ця віддача стає реальною лише після завершення впровадження та початку використання продукту.

Процес MSF орієнтований на "віхи" (milestones) - ключові точки проекту, що характеризують досягнення в його рамках будь-якого істотного (проміжного або кінцевого) результату. Цей результат може бути оцінений і проаналізований, що має на увазі відповіді на питання: "Прийшла чи проектна групадо однозначного розуміння цілей і рамок проекту? "," Чи достатньою мірою готовий план дій? "," Чи відповідає продукт затвердженої специфікації? "," Чи задовольняє рішення потреби замовника? "і т. д.

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

Особливостями моделі процесів MSF є:

підхід, заснований на фазах і віхи;
ітеративний підхід;
інтегрований підхід до створення та запровадження рішень.

Модель процесів включає такі основні фази процесу розробки, як:

вироблення концепції (Envisioning);
планування (Planning);
розробка (Developing);
стабілізація (Stabilizing);
впровадження (Deploying).

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

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

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

Ітеративний підхід до процесу розробки вимагає використання гнучкого способу ведення документації. "Живі" документи (living documents) повинні змінюватися в міру еволюції проекту разом зі змінами вимог до кінцевого продукту. В рамках MSF пропонується ряд шаблонів стандартних документів, які є артефактами кожної стадії розробки продукту і можуть бути використані для планування і контролю процесу розробки.

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

Федеральним агентством з технічного регулювання і метрології РФ 01.03.2012 р натомість ДСТУ ISO / IEC 12207-99 прийнятий стандарт ДСТУ ISO / IEC 12207-2010 «Інформаційна технологія. Системна і програмна інженерія. Процеси життєвого циклу програмних засобів», Ідентичний міжнародному стандарту ISO / IEC 12207: 2008« System and software engineering - Software life cycle processes ».

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

Процеси життєвого циклу ПО

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

процеси угоди - два процеси;
процеси організаційного забезпечення проекту - п'ять процесів;
процеси проекту - сім процесів;
технічні процеси - одинадцять процесів;
процеси реалізації програмних засобів - сім процесів;
процеси підтримки програмних засобів - вісім процесів;
процеси повторного застосування програмних засобів - три процесу.
Основні:
- Придбання (дії і завдання замовника, котре купує ПО)
- Поставка (дії і завдання постачальника, який постачає замовника програмним продуктом або послугою)
- Розробка (дії і завдання, що виконуються розробником: створення ПО, оформлення проектної та експлуатаційної документації, підготовка тестових і навчальних матеріаліві т.д.)
- Експлуатація (дії і завдання оператора - організації, що експлуатує систему)
- Супровід (дії і завдання, що виконуються супроводжує організацією, тобто службою супроводу). Супровід - внесень змін до ПО з метою виправлення помилок, підвищення продуктивності або адаптації до умов, що змінилися роботи або вимогам.
допоміжні
- Документування (формалізоване опис інформації, створеної протягом ЖЦ ПО)
- Управління конфігурацією (застосування адміністративних і технічних процедур на всьому протязі ЖЦ ПО для визначення стану компонентів ПО, управління його модифікаціями).
- Забезпечення якості (забезпечення гарантій того, що ІС і процеси її ЖЦ відповідають заданим вимогам і затвердженим планам)
- Верифікація (визначення того, що програмні продукти, які є результатами певної дії, повністю задовольняють вимогам або умовам, обумовленим попередніми діями)
- Атестація (визначення повноти відповідності заданих вимог і створеної системи їх конкретному функціональному призначенню)
- Спільна оцінка (оцінка стану робіт по проекту: контроль планування та управління ресурсами, персоналом, апаратурою, інструментальними засобами)
- Аудит (визначення відповідності вимогам, планам і умовами договору)
- Дозвіл проблем (аналіз і рішення проблем, незалежно від їх походження або джерела, які виявлені в ході розробки, експлуатації, супроводу або інших процесів)
організаційні
- Управління (дії і завдання, які можуть виконуватися будь-якою стороною, що управляє своїми процесами)
- Створення інфраструктури (вибір і супровід технології, стандартів і інструментальних засобів, вибір і установка апаратних і програмних засобів, які використовуються для розробки, експлуатації або супроводу ПО)
- Удосконалення (оцінка, вимір, контроль і удосконалення процесів ЖЦ)
- Навчання (початкове навчання і подальше постійне підвищення кваліфікації персоналу)

Кожен процес включає ряд дій. Наприклад, процес придбання охоплює наступні дії:

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

Кожна дія включає ряд завдань. Наприклад, підготовка заявочних пропозицій повинна передбачати:

Формування вимог до системи
Формування списку програмних продуктів
Встановлення умов і угод
Опис технічних обмежень (середовище функціонування системи і т. Д.)

Стадії життєвого циклу ПО, взаємозв'язок між процесами і стадіями

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

Стандарт ДСТУ ISO / IEC 12207-2010 не пропонує конкретну модель життєвого циклу. Його положення є загальними для будь-яких моделей життєвого циклу, методів і технологій створення ІС. Він описує структуру процесів життєвого циклу, що не конкретизуючи, як реалізувати або виконати дії і завдання, включені в ці процеси.

Модель ЖЦ ПО включає в себе:

стадії;
Результати виконання робіт на кожній стадії;
Ключові події - точки завершення робіт і прийняття рішень.

Мал. 5.2.

Такими аспектами є:

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

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

5.6. Моделі і стадії ЖЦ ПО

формування вимог до ПЗ;
проектування (розробка системного проекту);
реалізація (може бути розбита на підетапи: детальне проектування, кодування);
тестування (може бути розбите на автономне та комплексне тестування і інтеграцію);
введення в дію (впровадження);
експлуатація та супровід;
зняття з експлуатації.

Стадія формування вимог до ПЗ включає наступні етапи.

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

моделі "AS-IS" ( "як є"), що відбиває існуюче на момент обстеження стан справ в організації і дозволяє зрозуміти, яким чином працює дана організація, а також виявити вузькі місця і сформулювати пропозиції щодо поліпшення ситуації;
моделі "TO-BE" ( "як повинно бути"), що відбиває уявлення про нові технології роботи організації.

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

Стадія проектування включає наступні етапи.

Розробка системного проекту ПО. На цьому етапі дається відповідь на питання "Що повинна робити майбутня система?", А саме: визначаються архітектура системи, її функції, зовнішні умови функціонування, інтерфейси і розподіл функцій між користувачами і системою, вимоги до програмних і інформаційних компонентів, склад виконавців і терміни розробки, план налагодження ПО і контроль якості.

Основу системного проекту складають моделі проектованої системи, які будуються на моделі "TO-BE". Результатом розробки системного проекту повинна бути схвалена і підтверджена специфікація вимог до ПО: функціональні, технічні та інтерфейсні специфікації, для яких підтверджена їх повнота, проверяемость і здійсненність.
Розробка детального (технічного) проекту. На цьому етапі здійснюється власне проектування ПО, що включає проектування архітектури системи і детальне проектування. Таким чином, дається відповідь на питання: "Як побудувати систему, щоб вона задовольняла вимогам?"

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

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

Завершенням стадії детального проектування є наскрізною

Анотація.

Вступ.

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):

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

проектування рішення вже поставленого завдання (в загальному, таке рішення є менш формальним, ніж остаточна програма);

кодування програми, т. е. переклад спроектованого рішення в програму, яка може бути виконана на машині;

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

Мал. 1.Четире кроку програмування.

Програмування починається з того моменту, коли користувач, Тобто той, хто потребує програми для вирішення завдання, викладає проблему системному аналітику.Користувач і системний аналітик спільно визначають постановку задачі. Остання потім передається алгоритмісти, Який відповідає за проектування рішення. Рішення (або алгоритм) представляє послідовність операцій, виконання яких призводить до вирішення завдання. Оскільки алгоритм часто не пристосований до виконання на машині, його слід перевести в машинну програму. Ця операція виконується кодувальником. За наступні зміни в програмі несе відповідальність сопровождающійпрограмміст. І системний аналітик, і алгоритмісти, і кодировщик, і супроводжуючий програміст - всі вони є програмістами.

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

1.1.1 Постановка завдання

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

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

Характеристики Доброю Постановки Завдання:

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

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

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

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

Стандартна форма постановки завдання.

Розглянемо наступну постановку задачі: «Ввести три числа і вивести числа в порядку».

Така постановка не задовольняє наведеним вище вимогам: вона не є ні точної, ні повної, ні зрозумілої. Дійсно, чи повинні числа вводитися по одному на рядку або все числа на одному рядку? Чи означає вираз «в порядку» впорядкування від більшого до меншого, від меншого до більшого або той же порядок, в якому вони були введені.

Очевидно, що подібна постановка не відповідає на безліч запитань. Якщо ж врахувати відповіді на всі питання, то постановка задачі стане багатослівній і важкою для сприйняття. Тому Д. Райлі пропонує для постановки завдання користуватися стандартною формою, яка забезпечує максимальну точність, повноту, ясність і включає:

найменування завдання (схематичне визначення);

загальний опис (короткий виклад завдання);

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

приклад ( гарний прикладможе передати сутність завдання, а також проілюструвати різні випадки).

Приклад. Постановка завдання в стандартній формі.

НАЗВА

Сортування трьох цілих чисел.

ОПИС

Введення і виведення трьох цілих чисел, відсортованих від меншого числа до більшого.

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

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

1) Якщо введено менше трьох чисел, програма чекає додаткового введення.

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

Етапи життєвого циклу:

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

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

4. Складання, тестування, випробування

5. Впровадження (випуск)

6. Супровід

Розрізняють 2 випадки виробництва ПО: 1) ПО робиться для конкретного замовника. В цьому випадку потрібно прикладну задачу преврашается в програмістську. Потрібно зрозуміти як функціонує те середовище, яку потрібно автоматизувати (аналіз бізнес-процесів). В результаті з'являється документація-специфікація вимоги, де вказані які саме завдання д.б.н. вирішені і за яких умов. Цю роботу виконує системний аналітик (аналітик бізнес-процесів).

2) ПО розробляється для ринку. Потрібно проводити маркетингові дослідження і знайти якогось продукту на ринку немає. Це пов'язано з великим ризиком. Мета - розробка специфікації вимог.

проектування

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

Реалізація

Написання програмного коду. Реалізація включає і розробку, і тестування, і документацію.

Збірка, тестування, іспитніе

Збірка всього, що зроблено різними програмістами. Тестування за все програмного комплексу. Налагодження - пошук і усунення причин помилок. Випробування - уточнення технічних характеристик. В результаті - гарантія работоспособносіт програми.

Впровадження (випуск)

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

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

Якщо на ринок випускається принципово новий ПО, то можливо кілька бета-тестувань. Після бета-тестування - випуск комерційної версії.

супровід

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

Моделі життєвого циклу

1. Waterfall ( «водоспад», каскадна модель)

2. Прототипування

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

3. Ітераційна модель

Завдання поділяється на підзадачі і визначається черговість їх реалізації таким чином, щоб кожна наступна підзадачі розширювала можливості ПО. Успіх істотно залежить від того наскільки вдало розділені завдання на підзадачі і як обрана черговість. Переваги: 1) можливість активної участі замовника в розробці, він має можливість уточнити свої вимоги в ході розробки; 2) можливість тестування розроблених нових частин спільно з раніше розробленими, це зменшить витрати на комплексне налагодження; 3) під час розробки можна починати впровадження по частинах.

Популярне

НПЗ Росії: основні заводи і підприємства

« Нафтопереробний завод - промислове підприємство, основною функцією якого є переробка нафти в бензин, авіаційний гас, мазут, ... »

Нова нафту - нові умови видобутку

« У світі залишилося не так багато невивчених регіонів. Одне з цих місць - Арктика. Вивчення Арктики почали ще з часів Середньовіччя. Освоєння регіону ... »

Принципи. Піраміда Мінто. Принципи Логіка в міркуваннях

« Коли Геродот у другому томі своєї "Історії" написав, що Велика піраміда Гізи будувалася зверху вниз, ніхто нічого не зрозумів. Народ дивувався, як ... »