Життєвий цикл програмного забезпечення. Життєвий цикл програми Стадії життєвого циклу програмного забезпечення

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

Моделі Життєвого циклу програмного забезпечення

Життєвий цикл можна у вигляді моделей. В даний час найбільш поширеними є:каскадна, інкрементна (поетапна модель із проміжним контролем ) та спіральнамоделі життєвого циклу

Каскадна модель

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

p align="justify"> Процес розробки реалізується за допомогою впорядкованої послідовності незалежних кроків. Модель передбачає, що кожен наступний крок починається після завершення виконання попереднього кроку. На всіх кроках моделі виконуються допоміжні та організаційні процеси та роботи, що включають управління проектом, оцінку та управління якістю, верифікацію та атестацію, менеджмент конфігурації, розробку документації. У результаті завершення кроків формуються проміжні продукти, які можуть змінюватися наступних кроках.

Життєвий цикл традиційно поділяють такі основніетапи:

1. Аналіз вимог,
2. Проектування,
3. Кодування (програмування),
4. Тестування та налагодження,
5. Експлуатація та супровід.

Переваги моделі:

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

Недоліки моделі:

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

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

Область застосування Каскадної моделі

Обмеження сфери застосування каскадної моделі визначається її недоліками. Її використання найефективніше у таких випадках:

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

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

(Поетапна модель з проміжним контролем)

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

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

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

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

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

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

Переваги:

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

Недоліки моделі:

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

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

Спіральна модель

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

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

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

Життєвий цикл на кожному витку спіралі можуть застосовуватися різні моделі процесу розробки ПЗ. Зрештою на виході виходить готовий продукт. Модель поєднує в собі можливості моделі прототипування таводоспадні моделі. Розробка ітераціями відбиває об'єктивно існуючий спіральний цикл створення системи. Неповне завершення робіт на кожному етапі дозволяє переходити на наступний етап, не чекаючи повного завершення роботи на поточному. Головне завдання— якнайшвидше показати користувачам системи працездатний продукт, тим самим активізуючи процес уточнення та доповнення вимог.

Переваги моделі:

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

Недоліки моделі:

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

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

Область застосування спіральної моделі

Застосування спіральної моделі доцільно у таких випадках:

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

Життєвий цикл. Стадії та етапи

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

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

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

Традиційно виділяються такі основні етапи ЖЦ ПЗ:

Аналіз вимог,

Проектування,

Кодування (програмування),

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

Експлуатація та супровід.

Життєвий цикл. Каскадна модель

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

Основним досягненням каскадної моделі є завершеність стадій. Це дає можливість планування витрат та термінів. Крім того, формується проектна документація, що має повноту та узгодженість.

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

Життєвий цикл. Поетапна модель із проміжним контролем

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

Основні етапи розв'язання задач

Метою програмування є опис процесів обробки даних (надалі - просто процесів).

Дані (data) - це уявлення фактів та ідей у ​​формалізованому вигляді, придатному передачі та переробки у певному процесі, а інформація (information) - це сенс, який надається даним за її представленні.

Обробка даних (data processing) - виконання систематичної послідовності дій з даними. Дані подаються та зберігаються на носіях даних.

Сукупність носіїв даних, що використовуються при будь-якій обробці даних, називається інформаційним середовищем (data medium).

Набір даних, які в будь-який момент в інформаційному середовищі - стан інформаційного середовища.

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

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

Критерії якості ПЗ

Комерційний виріб (продукт, послуга) має відповідати вимогам споживача.

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

Характеристики якості:

› Працездатність– система працює та реалізує необхідні функції.

› Надійність– система працює без відмов та збоїв.

› Відновлюваність.

› Ефективність– система реалізує свої функції якнайкраще.

› Економічна ефективність - Мінімальна вартість кінцевого продуктуза максимального прибутку.

Характеристики якості:

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

› Переносність(мобільність) – переносимість коду на іншу платформу чи систему.

› Функціональна повнота– можливо найповніша реалізація зовнішніх функцій.

› Точність обчислення

Властивості алгоритму.

Результативність означає можливість одержання результату після виконання кінцевої кількості операцій.

Визначеність полягає у збігу одержуваних результатів незалежно від користувача та застосовуваних технічних засобів.

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

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

Способи опису алгоритмів

Існують такі способи опису (подання) алгоритмів:

1. словесний опис;

2. опис алгоритму з допомогою математичних формул;

3. графічний опис алгоритму як блок-схемы;

4. опис алгоритму за допомогою псевдокоду;

5. комбінований спосіб зображення алгоритму з використанням словесного, графічного та ін. .

6. з допомогою мереж Петрі.

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

Графічний описалгоритму у вигляді блок-схеми- Це опис структури алгоритму за допомогою геометричних фігур з лініями зв'язку.

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

Символи, у тому числі складається блок-схема алгоритму, визначає ГОСТ 19.701-90. Цей ГОСТ відповідає міжнародному стандартуоформлення алгоритмів, тому блок-схеми алгоритмів, оформлені згідно з ГОСТ 19701-90, в різних країнах розуміються однозначно.

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

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

Рисунок 1 – Приклад опису алгоритму у вигляді блок-схеми

Опис цього алгоритму на псевдокоде:

2. Введення чисел: Z, X

3. Якщо Z > X то Висновок Z

4. Інакше висновок Х

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

Види алгоритмів

лінійні;

розгалужені;

циклічні.

· Лінійний алгоритм- Набір команд (вказівок), що виконуються послідовно один за одним.

· Розгалужуваний алгоритм- Алгоритм, що містить хоча б одну умову, в результаті перевірки якого ЕОМ забезпечує перехід на один з двох можливих кроків.

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

Сі. Типи даних.

Тип даних – це опис діапазону значень, які може набувати змінна, зазначеного типу. Кожен тип даних характеризується:
   1. кількістю займаних байт (розміром)
   2. діапазон значень, які може приймати змінна даного типу.

Усі типи даних можна розділити на такі види:
   1. прості (скалярні) та складні (векторні) типи;
   2. базові (системні) та користувацькі (які визначив користувач).
  У мові СІ систему базових типів утворюють чотири типи даних:
   1. символьний,
   2. цілісний,
   3. речовий одинарної точності,
   4. речовий подвійний точності.

Структура програми на Сі.

1. Оператори мови C++

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

try (<операторы> }
catch (<объявление исключения>) { <операторы> }
catch (<объявление исключения>) { <операторы> }
...
catch (<объявление исключения>) { <операторы> }

Умовний оператор

if (<выражение>) <оператор 1>

Оператор-перемикач

switch (<выражение>)
( case<константное выражение 1>: <операторы 1>
case<константное выражение 2>: <операторы 2>
...
case<константное выражение N>: <операторы N>
}
Оператор-перемикач призначений для вибору одного з кількох альтернативних шляхіввиконання програми. Обчислення оператора-перемикача починається з обчислення виразу, після чого управління передається оператору, позначеному константним виразом, що дорівнює обчисленому значенню виразу. Вихід із оператора-перемикача здійснюється оператором break. Якщо значення виразу не дорівнює жодному константному виразу, то керування передається оператору, позначеному ключовим словом default, якщо він є.
Оператор циклу з передумовою

while (<выражение>) <оператор>

Оператор циклу з постумовою

do<оператор>while<выражение>;
У мові C++ цей оператор відрізняється від класичної реалізації циклу з тим, що з істинності висловлювання відбувається продовження роботи циклу, а чи не вихід із циклу.
Оператор покрокового циклу

for ([<начальное выражение>];
[<условное выражение>];
[<выражение приращения>])
<оператор>
Тіло оператора for виконується до тих пір, поки умовний вираз стане помилковим (рівним 0). Початковий вираз та вираз збільшення зазвичай використовуються для ініціалізації та модифікації параметрів циклу та інших значень. Початковий вираз обчислюється один раз до першої перевірки умовного виразу, а вираз збільшення обчислюється після кожного виконання оператора. Будь-який із трьох виразів заголовка циклу, і навіть всі три можуть бути опущені (не забувайте лише залишати крапки з комою). Якщо опущено умовний вираз, воно вважається істинним, і цикл стає нескінченним.
Оператор покрокового циклу мови С++ є гнучкою і зручною конструкцією, тому оператор циклу з передумовою while використовують у мові З++ дуже рідко, т.к. Найчастіше зручніше користуватися оператором for.
Оператор розриву

break;
Оператор розриву перериває виконання операторів while, do, for та switch. Він може утримуватися лише у тілі цих операторів. Керування передається оператору програми, що йде за перерваним. Якщо оператор розриву записаний всередині вкладених операторів while, do, for, switch, він завершує лише оператор, що його безпосередньо охоплює.
Оператор продовження

continue;
Оператор продовження передає управління наступну ітерацію в операторах циклу while, do, for. Він може утримуватися лише у тілі цих операторів. У операторах do і while наступна ітерація починається з обчислення умовного висловлювання. В операторі for наступна ітерація починається з обчислення виразу збільшення, а потім відбувається обчислення умовного виразу.
Оператор повернення

return [<выражение>];
Оператора повернення закінчує виконання функції, в якій він міститься, і повертає управління в функцію, що викликає. Управління передається в точку зухвалої функції

If (логічний вираз)

оператор;

If (логічний вираз)

оператор_1;

оператор_2;

<логическое выражение> ? <выражение_1> : <выражение_2>;

Якщо значення логічного виразу істинно, то обчислюється вираз_1, інакше обчислюється вираз_2.

switch (вираз цілого типу)

case значення_1:

послідовність_операторів_1;

case значення_2:

послідовність_операторів_2;

case значення_n:

послідовність_операторів_n;

default:

послідовність_операторів_n+1;

Гілку default можна не описувати. Вона виконується, якщо жодне з вищих виразів не задоволене.

Оператор циклу.

У Турбо Сі є такі конструкції, що дозволяють програмувати цикли: while, do while і for . Їхню структуру можна описати так:

Цикл із перевіркою умови нагорі:

Оператор вибору

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

switch (змінна)
{
case значення1:
дії1
break;

case значення2:
дії2
break;
...

default:
дії за умовчанням
}

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

switch (змінна)
{
case значення1:
case значення2:
дії1
break;

case значення3:
дії2
break;
...
}

Приклад використання вибору:

int n, x;
...
switch(n)
{
case 0:
break; //якщо n дорівнює 0, то не виконуємо жодних дій

case 1:
case 2:
case 3:
x = 3*n; //якщо n дорівнює 1, 2 або 3, то виконуємо деякі дії
break;

case 4:
x = n; //якщо n дорівнює 4, то виконуємо інші дії
break;

default:
x = 0; //при всіх інших значеннях n виконуємо стандартні дії
}

Сі.Цикл: цикл із параметром

Загальна форма запису

for (ініціалізація параметра; перевірка умови закінчення; корекція параметра) (

блок операцій;

for – параметричний цикл (цикл із фіксованою кількістю повторень). Для організації такого циклу необхідно здійснити три операції:

§ ініціалізація параметра- Надання параметру циклу початкового значення;

§ перевірка умови закінчення- Порівняння величини параметра з деяким граничним значенням;

§ корекція параметра- Зміна значення параметра при кожному проходженні тіла циклу.

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

приклад

#include
int main() (

for(num = 1; num< 5; num++)

printf("num = %d\n", num);

Сі. Цикл із передумовою

Загальна форма запису

while (вираз) (

блок операцій;
}

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

приклад

int k=5;
int i=1;
int sum=0;
while(i<=k) {

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

блок операцій;
}

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

Сі. Цикл із постумовою

Цикл з постумовою do...while

Загальна форма запису

блок операцій;

) while (вираз);

Цикл із постумовою

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

Використовувати цикл do...while краще використовувати у тих випадках, коли має бути виконана хоча б одна ітерація, або коли ініціалізація об'єктів, що беруть участь у перевірці умови, відбувається всередині тіла циклу.

приклад. Ввести число від 0 до 10

#include
#include
int main() (

system("chcp 1251");

printf("Введіть число від 0 до 10:");

scanf("%d", &num);

) while((num< 0) || (num > 10));

printf("Ви ввели число %d", num);

getchar(); getchar();

Визначення функцій

Розглянемо визначення функції з прикладу функції sum.

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

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

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

Це в основному три види інформації та відповідно три класи завдань, для вирішення яких використовуються комп'ютери:

1) Обчислювальні завдання, пов'язані з обробкою числової інформації. До них належить, наприклад, завдання розв'язання системи лінійних рівнянь великої розмірності. Раніше була основною, домінуючою областю використання ЕОМ.

2) Завдання з обробки символьної інформації, пов'язані зі створенням, редагуванням та перетворенням текстових даних. З вирішенням таких завдань пов'язана праця, наприклад, секретаря-машиністки.

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

4) Завдання з обробки алфавітно-циврової інформації – ІС. В даний час стало однією з основних областей застосування ЕОМ і завдання ускладнюються.

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

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

Технології зручно характеризувати у двох вимірах – вертикальному (що представляє процеси) і горизонтальному (що представляє стадії).

Малюнок

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

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

Розробка ПЗ підпорядковується певному життєвому циклу.

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

а) морального старіння;

б) втрати необхідності розв'язання відповідних завдань.

Технологічні підходи – це механізм реалізації життєвого циклу.

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

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

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

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

Реалізація

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

Впровадження, експлуатація та супровід.

Найпростіше уявлення ЖЦ програми (каскадний технологічний підхід до ведення життєвого циклу):

Процеси

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

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

Тестування

Супровід

Аналіз Проектування Реалізація ТестуванняВпровадженняексплуатація

та налагодження та супровід

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

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

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

Етап реалізаціївключає написання програми.

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

ЖЦ ПЗ регламентується багатьма стандартами зокрема й міжнародними.

Мета стандартизації ЖЦ складних ПС:

Узагальнення досвіду та результатів досліджень безлічі фахівців;

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

Стандарти включають:

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

Встановлюють правила контролю технологічних процесів;

Встановлюють вимоги до оформлення результатів;

Регламентують зміст технологічних та експлуатаційних документів;

Визначають організаційну структуруколективу розробників;

Забезпечують розподіл та планування завдань;

Забезпечують контроль за перебігом створення ПС.

У Росії діють стандарти, які регламентують ЖЦ:

Стадії розробки ПО-ГОСТ 19.102-77

Стадії створення АС – ГОСТ 34.601 –90;

ТЗ створення АС - ГОСТ 34.602-89;

Види випробування АС – ГОСТ 34.603-92;

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

У зв'язку з цим слід наголосити на міжнародному стандарті ISO/IEC 12207-1999 – « Інформаційні технології- Процеси життєвого циклу програмного забезпечення».

ISO - International Organization of Standardization - Міжнародна організаціязі стандартизації, IEC – International Electrotechnical Commission – Міжнародна комісія з електротехніки.

Він визначає структуру ЖЦ ПЗ та його процеси.

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

Структура ЖЦ ПЗ за міжнародним стандартом ISO/IEC 12207-95 базується на трьох групах процесів:

1) основні процеси ЖЦ ПЗ (придбання, постачання, розробка, експлуатація, супровід). Ми основну увагу приділимо останнім.

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

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

2. Верифікація-це процес визначення того, чи відповідає поточний стан ПЗ, досягнуте на даному етапі, вимогам цього етапу

3. Атестація– підтвердження експертизою та поданням об'єктивних доказів того, що конкретні вимоги до конкретних об'єктів повністю реалізовані.

4. Спільний аналіз (оцінка) – систематичне визначення ступеня відповідності об'єкта встановленим критеріям

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

3) організаційні процеси (управління проектами, створення інфраструктури проекту, визначення, оцінка та покращення самого ЖЦ, навчання).

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

Ми розглядатимемо ЖЦ ПЗ з погляду розробника.

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

За стандартом життєвий цикл ПЗ ІС включає наступні дії:

1) виникнення та дослідження ідеї (задуму);

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

3) аналіз вимог до інформаційної системи - визначення її

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

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

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

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

7) детальне проектування програмного забезпечення - докладне

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

8) кодування ПЗ -– розробка та документування

кожного програмного компонента;

9)тестування ПЗ – розробка сукупності тестових процедур та даних для їх тестування, тестування компонентів, оновлення документації користувача, оновлення плану інтеграції ПЗ;

10) інтеграція ПЗ–складання програмних компонентів у відповідності з

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

11) кваліфікаційне тестування ПЗ – тестування ПЗ в

присутності замовника для демонстрації його відповідності

вимогам та готовності до експлуатації; при цьому перевіряється також готовність і повнота технічної та користувальницької документації;

12) інтеграція системи – збирання всіх компонетів інформаційної системи, включаючи ПЗ та обладнання;

13) кваліфікаційне тестування ІВ – тестування системи на

відповідність вимогам до неї та перевірка оформлення та повноти документації;

14) встановлення ПЗ – встановлення ПЗ на обродження замовника та перевірка його працездатності;;

15) приймання ПЗ – оцінка результатів кваліфікованого

тестування ПЗ та інформаційної системи в цілому та

документування результатів оцінки спільно із замовником, атестація та остаточна передача ПЗ замовнику.

16) Управління та розробка документації;

17) експлуатація

18) супровід - процес створення та впровадження нових версій

програмного продукту;

19) завершення експлуатації.

Зазначені дії можна згрупувати, умовно виділивши такі основні етапи розробки:

· Постановка завдання (ТЗ) (за ГОСТ 19.102-77 стадія «Технічне завдання»)

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

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

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

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

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

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

Програмні вироби з малою тривалістю експлуатації

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

чого життєвий цикл програмного виробу рідко перевищує 3 роки.

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

Програмні вироби з великою тривалістю експлуатації

Їх проектуванням та експлуатацією займаються великі колективи фахівців, для чого необхідна формалізація програмної системи, а також формалізовані випробування та визначення досягнутих показників якості кінцевого продукту. Їхній життєвий цикл становить 10...20 років. До 70...90 % цього часу припадає на експлуатацію та супровід. Внаслідок масового тиражування та тривалого супроводу сукупні витрати в процесі експлуатації та супроводу таких програмних виробів значно перевищують витрати на системний аналізта проектування.

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

Узагальнена модель життєвого циклу програмного виробу може виглядати так:

I. Системний аналіз:

а) дослідження;

б) аналіз здійсненності:

Експлуатаційний;

Економічній;

Комерційної.

II. Проектування програмного забезпечення:

а) конструювання:

Функціональна декомпозиція системи, її архітектура;

Зовнішнє проектування програмного забезпечення;

Проектування баз даних;

Архітектура програмного забезпечення;

б) програмування:

Внутрішнє проектування програмного забезпечення;

Зовнішнє проектування програмних модулів;

Внутрішнє проектування програмних модулів;

Кодування;

Налагодження програм;

Компонування програм;

в) налагодження програмного забезпечення.

III. Оцінка (випробування) програмного забезпечення.

IV. Використання програмного забезпечення:

а) експлуатація;

б) супровід.

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

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

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

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

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

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

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

- здійсненність експлуатаційна , Чи буде виріб досить зручним для практичного використання?

- здійсненність економічна , чи прийнятна вартість виробу, що розробляється? Яка ця вартість? Чи буде виріб економічно ефективним інструментом у руках користувача?

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

Ці та інші питання необхідно вирішувати головним чином під час розгляду зазначених вище вимог.

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

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

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

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

II. Проектування програмного забезпечення.Проектування є основною і вирішальною фазою життєвого циклу програмного забезпечення, під час якого створюється і на 90% набуває своєї остаточної форми програмного виробу.

Ця фаза життя охоплює різні видидіяльності проекту і може бути розділена на три основні етапи: конструювання, програмування та налагодження програмного виробу.

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

На момент затвердження вимог робота у фазі конструювання буде у розпалі.

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

Функціональну декомпозицію розв'язуваної задачі, на основі якої визначається архітектура системи цієї задачі;

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

Проектування бази даних, якщо це необхідно;

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

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

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

p align="justify"> Фаза програмування завершується, коли розробники закінчать документування, налагодження і компонування окремих частин програмного виробу в одне ціле.

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

III. Оцінка (випробування) програмного забезпечення.У цій фазі програмний виріб зазнає суворого системного випробування з боку групи осіб, які не є розробниками.

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

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

Вона продовжується так само довго, як і програмування.

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

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

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

Це час, протягом якого виріб перебуває у дії і використовується ефективно.

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

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

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

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

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

Супровід відіграє роль необхідної зворотний зв'язок від етапу експлуатації.

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

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

Перекриття між фазами життєвого циклу програмного виробу

Можливі та зазвичай бажані перекриття між різними фазами життєвого циклу програмного виробу. Однак не повинно бути перекриття між несуміжними процесами.

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

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

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

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

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

Процеси ЖЦ ПЗ:

Основні,

Допоміжні,

Організаційні.

Основні:

1. Придбання – дії та завдання замовника, що набуває ПЗ;

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

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

4. Експлуатація – дії та завдання оператора організації, яка експлуатує систему;

5. Супровід – внесення змін до ПЗ з метою виправлення помилок, підвищення продуктивності або адаптації до умов роботи або вимог, що змінилися.

Допоміжні:

1. Документування – формалізоване опис інформації, створеної протягом ЖЦ ПЗ;

2. Управління конфигурацией– застосування адміністративних і технічних процедур протягом ЖЦ ПО визначення стану компонентів ПО, управління його модифікаціями;

3. Забезпечення якості – забезпечення гарантій того, що ПЗ та процеси її ЖЦ відповідають заданим вимогам та затвердженим планам;

4. Верифікація – визначення того, що програмні продукти повністю задовольняють вимоги або умови, зумовлені попередніми діями;

5. Атестація – визначення повноти відповідності заданих вимог та створеної системи їхньому конкретному функціональному призначенню;

6. Спільна оцінка - оцінка стану робіт за проектом: контроль планування та управління ресурсами, персоналом, апаратурою, інструментальними засобами;

7. Аудит – визначення відповідності вимогам, планам та умовам договору;

8. Вирішення проблем - аналіз та вирішення проблем, незалежно від їх походження або джерела, які виявлені в ході розробки, експлуатації, супроводу або інших процесів.

Організаційні:

1. Управління – дії та завдання, які можуть виконуватися будь-якою стороною, яка керує своїми процесами;

2. Створення інфраструктури – вибір та супровід технології, стандартів та інструментальних засобів, вибір та встановлення апаратних та програмних засобів, що використовуються для розробки, експлуатації або супроводу ПЗ;

3. Удосконалення – оцінка, вимірювання, контроль та удосконалення процесів ЖЦ;

4. Навчання - початкове навчання та подальше постійне підвищення кваліфікації персоналу.

У 2002 р. було опубліковано стандарт на процеси життєвого циклу систем (ISO/IEC 15288 System life cycle processes). До розробки стандарту було залучено фахівців різних областей: системної інженерії, програмування, управління якістю, людськими ресурсами, безпекою та ін. Було враховано практичний досвід створення систем в урядових, комерційних, військових та академічних організаціях. Стандарт застосовується для широкого класу систем, але його основне призначення - підтримка створення комп'ютеризованих систем.

Відповідно до стандарту ISO/IEC серії 15288 до структури ЖЦ слід включати такі групи процесів:

1. Договірні процеси:

Придбання (внутрішні рішення чи рішення зовнішнього постачальника);

Постачання (внутрішні рішення або рішення зовнішнього постачальника);

2. Процеси підприємства:

Управління довкіллямпідприємства;

Інвестиційне управління;

Управління ЖЦ ІВ;

Управління ресурсами;

Управління якістю;

3. Проектні процеси:

Планування проекту;

Оцінка проекту;

Контроль проекту;

Управління ризиками;

Управління конфігурацією;

Управління інформаційними потоками;

Ухвалення рішень.

4. Технічні процеси:

Визначення вимог;

Аналіз вимог;

Розробка архітектури;

Впровадження;

Інтеграція;

Верифікація;

Перехід;

Атестація;

Експлуатація;

Супровід;

Утилізація.

5. Спеціальні процеси:

Визначення та встановлення взаємозв'язків виходячи із завдань та цілей.

Створення основних процесів ЖЦ ПЗ з ІС (ISO/IEC 15288)

Процес (виконавець процесу)	Дії	Вхід	Результат
Придбання (замовник)	- ініціювання - підготовка заявкових пропозицій - підготовка договору - контроль діяльності постачальника - приймання ІС	- Рішення про початок робіт з впровадження ІВ - Результати обстеження дій замовника - Результати аналізу ринку ІВ/ тендера - План постачання/розробки - Комплексний тест ІВ	- Техніко-економічне обґрунтування впровадження ІВ - Технічне завдання на ІВ - Договір на поставку/розробку - Акти приймання етапів роботи - Акт приймально-здавальних випробувань
Постачання (розробник ІВ)	- Ініціювання - Відповідь на заявні пропозиції - Підготовка договору - Планування виконання - Постачання ІС	- Технічне завдання на ІВ - Рішення керівництва про участь у розробці - Результати тендеру - Технічне завдання на ІВ - План управління проектом - Розроблена ІВ та документація	- Рішення про участь у розробці - Комерційні пропозиції/конкурсна заявка - Договір на поставку/ розробку - План управління проектом - Реалізація/ коригування - Акт приймально-здавальних випробувань
Розробка (розробник ІВ)	- Підготовка - Аналіз вимог до ІВ - Проектування архітектури ІВ - Розробка вимог до ПЗ - Проектування архітектури ПЗ - Детальне проектування ПЗ - Кодування та тестування ПЗ - Інтеграція ПЗ та кваліфіковане тестування ПЗ - Інтеграція ІС та кваліфіковане тестування ІВ	- Технічне завдання на ІВ - Технічне завдання на ІВ, модель ЖЦ - Підсистеми ІВ - Специфікації вимоги до компонентів ПЗ - Архітектура ПЗ - Матеріали детального проектування ПЗ - План інтеграції ПЗ, тести - Архітектура ІС, ПЗ, документація на ІВ, тести	- модель, що використовується, ЖЦ, стандарти розробки - План робіт - Склад підсистем, компоненти обладнання - Специфікації вимоги до компонентів ПЗ - Склад компонентів ПЗ, інтерфейси з БД, план інтеграції ПЗ - Проект БД, специфікації інтерфейсів між компонентами ПЗ, вимоги до тестів - Тексти модулів ПЗ, акти автономного тестування - Оцінка відповідності комплексу ПЗ вимогам ТЗ - Оцінка відповідності ПЗ, БД, технічного комплексута комплекту документації вимогам ТЗ

Стадії створення систем (ISO/IEC 15288)

СРС: Створити технічне завдання проекту «Черга» на сайті www.mastertz.ru

Моделі ЖЦ ПЗ:

1. каскадна,

2. спіральна,

3. ітераційна.

Каскадна модельжиттєвого циклу («модель водоспаду», англ. Waterfall model) була запропонована в 1970 Уінстоном Ройсом. Вона передбачає послідовне виконання всіх етапів проекту у строго фіксованому порядку. Перехід на наступний етап означає повне завершення робіт на попередньому етапі.

Вимоги, визначені на стадії формування вимог, суворо документуються як технічного завдання і фіксуються весь час розробки проекту.

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

Розробка вимог

Формування

Спіральна модель(англ. spiral model) була розроблена в середині 1980-х Баррі Боемом. Вона заснована на класичному циклі Вільямса Едварда Демінга PDCA (plan-do-check-act). При використанні цієї моделі програмне забезпечення створюється в кілька ітерацій (витків спіралі) методом прототипування.

Прототип – компонент ПЗ, що діє, реалізує окремі функції та зовнішні інтерфейси.

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

Мал. 21. Спіральна модель ЖЦ ПЗ

На кожній ітерації оцінюються:

1. Ризик перевищення строків та вартості проекту;

2. Необхідність виконання ще однієї ітерації;

3. Ступінь повноти та точності розуміння вимог до системи;

4. Доцільність припинення проекту.

Один із прикладів реалізації спіральної моделі – RAD.

Основні принципи RAD:

1. Інструментарій має бути націлений на мінімізацію часу розробки;

2. створення прототипу для уточнення вимог замовника;

3. Циклічність розробки: кожна нова версія продукту ґрунтується на оцінці результату роботи попередньої версії замовником;

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

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

6. Управління проектом має мінімізувати тривалість циклу розробки.

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

Мал. 22. Ітераційна модель ЖЦ ПЗ