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

Анотація.

Вступ.

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) Якщо введено менше трьох чисел, програма чекає на додаткове введення.

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

Що це таке у формальному розумінні?

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

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

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

Початкові вимоги

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

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

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

Серед систем, що визначають умови і вимоги до таких процесів, сьогодні можна назвати лише три основні:

• ГОСТ 34.601-90;
• ISO/IEC 12207:2008;
• Oracle CDM.

Для другого міжнародного стандарту є російський аналог. Це ГОСТ Р ІСО/МЕК 12207-2010, що відповідає за системну та програмну інженерію. Але життєвий цикл програмного забезпечення, що описується в обох правилах, є ідентичним. Пояснюється це досить просто.

Види ПЗ та апдейти

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

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

Приклад на основі програми FL Studio

Спочатку віртуальна студія-секвенсор FL Studio мала назву Fruity Loops. Життєвий цикл ПЗ у його первинній модифікації минув, але додаток дещо трансформувався і набув нинішнього вигляду.

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

• створення барабанного модуля за типом ритм-машин на зразок Yamaha RX, але із застосуванням one-shot-семплів або секвенцій у форматі WAV, записаних у студіях наживо;
• інтеграція до операційних систем Windows;
• можливість експорту проекту у форматах WAV, MP3 та OGG;
• сумісність проектів із додатковим додатком Fruity Tracks.

На стадії розробки були використані засоби мов програмування «Сі». Але платформа виглядала досить примітивно і не давала кінцевому користувачеві необхідної якостізвучання.

У зв'язку з цим, на стадії тестування та налагодження розробникам довелося піти шляхом німецької корпорації Steinberg і застосувати в вимогах до основного звукового драйвера підтримку режиму Full Duplex. Якість саунду стала вищою і дозволило змінювати темп, висоту тону та накладати додаткові FX-ефекти в режимі реального часу.

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

Цим не обмежилося. На стадії управління проектом було введено підтримку підключення плагінів формату VST (спочатку другої, а потім і третьої версії), свого часу розробленого компанією Steinberg. Грубо кажучи, будь-який віртуальний синтезатор, який підтримує VST-host, міг підключатися до програми.

Не дивно, що невдовзі будь-який композитор міг використовувати аналоги залізних моделей, наприклад, повні комплекти звуків колись популярного Korg M1. Далі більше. Застосування модулів типу Addictive Drums або універсального плагіна Kontakt дозволило відтворювати живі звуки реальних інструментів, записаних з усіма відтінками артикуляції в професійних студіях.

При цьому розробники постаралися досягти і максимальної якості, створивши підтримку для драйверів ASIO4ALL, які опинилися на голові вище за режим Full Duplex. Відповідно підвищився і бітрейт. На сьогоднішній день якість звукового файлу, що експортується, може становити 320 кбіт/с при частоті дискретизації 192 кГц. А це професійний звук.

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

Перспективи розвитку

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

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

Навіть у випадку з Windows такі тенденції можна помітити неозброєним поглядом. Навряд чи сьогодні знайдеться хоч один користувач, який використовує системи як модифікацій 3.1, 95, 98 або Millennium. Їхній життєвий цикл закінчився після виходу версії XP. Але серверні версії на основі технологій NT все ще актуальні. Навіть Windows 2000 на сьогоднішній день є не тільки дуже актуальною, але й за деякими параметрами установки або безпеки, що навіть перевершує нові розробки. Те саме стосується системи NT 4.0, а також спеціалізованої модифікації Windows Server 2012.

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

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

Деякі додаткові питання

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

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

Але в комп'ютерних технологіях сьогодні віддається перевага розвитку автоматизованих системуправління (АСУ), що застосовуються на виробництві. Навіть операційні системи у порівнянні зі спеціалізованими програмами програють.

Ті ж середовища на основі Visual Basic залишаються набагато популярнішими за Windows-системи. А про прикладне ПЗ під UNIX-системи не йдеться взагалі. Що говорити, якщо практично всі комунікаційні мережі тих самих Сполучених Штатів працюють виключно на них. До речі, системи на зразок Linux та Android теж спочатку створювалися саме на цій платформі. Тому, швидше за все, у UNIX перспектив набагато більше, ніж у інших продуктів, разом узятих.

Замість підсумку

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

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

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

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

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

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

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

Рис. 5.2.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Стандарт ДЕРЖСТАНДАРТ ІСО/МЕК 12207-2010 не пропонує конкретну модель життєвого циклу. Його положення є спільними для будь-яких моделей життєвого циклу, методів та технологій створення ІВ. Він описує структуру процесів життєвого циклу, не конкретизуючи, як реалізувати чи виконати дії та завдання, включені до цих процесів.

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

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

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

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

Слід зазначити, що у Радянському Союзі, та був у Росії створення програмного забезпечення ( ПЗ ) спочатку, у роки минулого століття, регламентувалося стандартами ГОСТ ЕСПД ( Єдиної системипрограмної документації – серії ГОСТ 19.ХХХ), орієнтовані на клас щодо простих програм невеликого обсягу, створюваних окремими програмістами. Нині ці стандарти застаріли концептуально і формою, їх терміни дії закінчилися і використання недоцільно.

Процеси створення автоматизованих систем (АС), до складу яких входить і ПЗ, регламентовані стандартами ГОСТ 34.601-90 "Інформаційна технологія. Комплекс стандартів на автоматизовані системи. Стадії створення", ГОСТ 34.602-89 "Інформаційна технологія. Комплекс стандартів на автоматизовані Технічне завданняна створення автоматизованої системи" та ГОСТ 34.603-92 "Інформаційна технологія. Види випробувань автоматизованих систем". Проте багато положень цих стандартів застаріли, а інші відображені недостатньо, щоб їх можна було застосовувати для серйозних проектів створення ПС. Тому у вітчизняних розробках доцільно використовувати сучасні міжнародні стандарти.

Відповідно до стандартом ISO/ IEC 12207 всі процеси ЖЦ ПЗ поділені на три групи (рис.5.1).

Рис. 5.1.

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

5.2. Основні процеси ЖЦ ПС

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

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

Ініціювання придбання включає такі завдання:

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

Заявні пропозиції повинні містити:

1. вимоги до системи;
2. список програмних продуктів;
3. умови придбання та угоди;
4. технічні обмеження (наприклад, серед функціонування системи).

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

Підготовка та коригування договору включає такі завдання:

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

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

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

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

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

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

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

Процес розробки включає такі дії:

1. підготовчу роботу;
2. аналіз вимог, що висуваються до системи;
3. проектування архітектури системи;
4. аналіз вимог до програмного забезпечення;
5. проектування архітектури програмного забезпечення;
6. детальне проектування програмного забезпечення;
7. кодування та тестування програмного забезпечення;
8. інтеграцію програмного забезпечення;
9. кваліфікаційне тестування програмного забезпечення;
10. інтеграцію системи;
11. кваліфікаційне тестування системи;
12. встановлення програмного забезпечення;
13. приймання програмного забезпечення.

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

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

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

Аналіз вимог до програмного забезпечення передбачає визначення наступних характеристик для кожного компонента:

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

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

Проектування архітектури ПЗ включає наступні завдання для кожного компонента ПЗ:

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

Детальне проектування ПЗ включає такі завдання:

1. опис компонентів ПЗ та інтерфейсів між ними на нижчому рівні, достатньому для подальшого кодування та тестування;
2. розробку та документування детального проектубази даних;
3. оновлення (при необхідності) документації користувача;
4. розробку та документування вимог до тестів та плану тестування компонентів ПЗ;

Кодування та тестування ПЗ включає такі завдання:

1. кодування та документування кожного компонента ПЗ та бази даних, а також підготовку сукупності тестових процедур та даних для їх тестування;
2. тестування кожного компонента ПЗ і БД на відповідність вимогам, що пред'являються до них, з подальшим документуванням результатів тестування;
3. оновлення документації (за потреби);
4. оновлення плану інтеграції ПЗ.

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

Кваліфікаційне тестування ПЗ проводиться розробником у присутності замовника (

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

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

   1. планування дій та робіт, що виконуються в процесі експлуатації, та встановлення експлуатаційних стандартів;
   2. визначення процедур локалізації та вирішення проблем, що виникають у процесі експлуатації.
2. Експлуатаційне тестування, яке здійснюється для кожної чергової редакції програмного продукту, після чого ця редакція передається в експлуатацію.
3. Власне експлуатація системи, яка виконується у призначеному для цього середовищі відповідно до користувальницької документації.
4. аналіз проблем та запитів на модифікацію ПЗ (аналіз повідомлень про проблему або запиту на модифікацію, оцінка масштабу, вартості модифікації, одержуваного ефекту, оцінка доцільності модифікації);
5. модифікацію ПЗ (внесення змін до компонентів програмного продукту та документацію відповідно до правил процесу розробки);
6. перевірку і приймання (у частині цілісності системи, що модифікується);
7. перенесення ПЗ в інше середовище (конвертування програм та даних, паралельна експлуатація ПЗ у старому та новому середовищі протягом деякого періоду часу);
8. зняття програмного забезпечення з експлуатації за рішенням замовника за участю експлуатуючої організації, служби супроводу та користувачів. При цьому програмні продукти та документації підлягають архівуванню відповідно до договору.