Розробка ПЗ неможлива без розуміння так званого життєвого циклу програм. Пересічному користувачеві це, можливо, і не потрібно знати, але основні стандарти бажано засвоїти (далі буде сказано, навіщо це потрібно).
Що це таке у формальному розумінні?
Під життєвим циклом будь-якого прийнято розуміти час його існування, починаючи зі стадії розробки та до моменту повної відмовивід використання у вибраній сфері застосування аж до повного вилучення програми з ужитку.
Говорячи простою мовою, інформаційні системи у вигляді програм, баз даних або навіть «операційок» є затребуваними лише у разі актуальності даних та можливостей, які вони надають.
Вважається, що визначення життєвого циклу жодною мірою не застосовується до тестових додатків, наприклад, до бета-версій, які є найнестійкішими в роботі. Сам же життєвий цикл ПЗ залежить від безлічі факторів, серед яких одну з головних ролей відіграє середовище, в якому програма використовуватиметься. Однак можна виділити і Загальні умови, що застосовуються щодо поняття життєвого циклу.
Початкові вимоги
- постановка задачі;
- аналіз взаємних вимог майбутнього ПЗ до системи;
- проектування;
- програмування;
- кодування та компіляція;
- тестування;
- налагодження;
- впровадження та супровід програмного продукту.
Розробка програмного забезпечення складається з усіх вищезгаданих стадій і не може обійтися хоча б без однієї з них. Але для контролю таких процесів встановлено спеціальні стандарти.
Стандарти процесів життєвого циклу програмного забезпечення
Серед систем, що визначають умови і вимоги до таких процесів, сьогодні можна назвати лише три основні:
- ГОСТ 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.
Такими аспектами є:
- договірний аспект, в якому замовник та постачальник вступають у договірні відносинита реалізують процеси придбання та постачання;
- аспект управління, який включає дії управління особами, які беруть участь у ЖЦ ПЗ (постачальник, замовник, розробник, оператор та ін.);
- аспект експлуатації, що включає дії оператора щодо надання послуг користувачам системи;
- інженерний аспект, який містить дії розробника або служби супроводу щодо вирішення технічних завдань, пов'язаних із розробкою або модифікацією програмних продуктів;
- аспект підтримки, пов'язаний з реалізацією допоміжних процесів, за допомогою яких служби підтримки надають необхідні послуги решті учасників робіт. У цьому аспекті можна виділити аспект управління якістю ПЗ, що включає процеси забезпечення якості, верифікацію, атестацію, спільну оцінку та аудит.
Організаційні процеси виконуються на корпоративному рівні або на рівні всієї організації в цілому, створюючи базу для реалізації та постійного вдосконаленняпроцесів ЖЦ ПЗ.
5.6. Моделі та стадії ЖЦ ПЗ
Під моделлю ЖЦ ПО розуміється структура, що визначає послідовність виконання та взаємозв'язку процесів, дій та завдань протягом ЖЦ ПО. Модель ЖЦ залежить від специфіки, масштабу та складності проекту та специфіки умов, у яких система створюється та функціонує.
Стандарт ISO/IEC 12207 не пропонує конкретну модель ЖЦ та методи розробки ПЗ. Його положення є спільними для будь-яких моделей ЖЦ, методів та технологій розробки ПЗ. Стандарт описує структуру процесів ЖЦ ПЗ, але не конкретизує, як реалізувати або виконати дії та завдання, включені до цих процесів.
Модель ЖЦ будь-якого конкретного ПЗ визначає характер процесу його створення, який є сукупністю упорядкованих у часі, взаємопов'язаних і об'єднаних у стадії (фази) робіт, виконання яких необхідне і достатньо для створення ПЗ, що відповідає заданим вимогам.
Під стадією (фазою) створення ПЗ розуміється частина процесу створення ПЗ, обмежена деякими часовими рамками і закінчується випуском конкретного продукту (моделей ПЗ, програмних компонентів, документації та ін.), Який визначається заданими для даної стадії вимогами. Стадії створення ПЗ виділяються з міркувань раціонального планування та організації робіт, що закінчуються заданими результатами. До складу ЖЦ ПЗ зазвичай включаються такі стадії:
- формування вимог до ПЗ;
- проектування (розробка системного проекту);
- реалізація (може бути розбита на підетапи: детальне проектування, кодування);
- тестування (може бути розбите на автономне та комплексне тестуваннята інтеграцію);
- введення у дію (впровадження);
- експлуатація та супровід;
- зняття з експлуатації.
Деякі фахівці додатково вводять початкову стадію – аналіз здійсненностісистеми. Тут мають на увазі програмно-апаратна система, на яку створюється, купується чи модифікується ПЗ .
Стадія формування вимог до ПЗ є однією з найважливіших і визначає значною (навіть вирішальною!) ступенем успіх усього проекту. Початком цієї стадії є отримання схваленої та затвердженої архітектури системи з включенням основних угод про розподіл функцій між апаратурою та програмами. Цей документ повинен також містити підтвердження загального уявлення про функціонування програмного забезпечення з включенням основних угод про розподіл функцій між людиною та системою.
Стадія формування вимог до ПЗ включає такі етапи.
- Планування робіт, що передує роботі над проектом. Основними завданнями етапу є визначення цілей розробки, попередня економічна оцінкапроекту, побудова плану-графіка виконання робіт, створення та навчання спільної робочої групи.
- Проведення обстеження діяльності автоматизованої організації (об'єкта), в рамках якого здійснюються попереднє виявлення вимог до майбутньої системи; визначення структури організації, визначення переліку цільових функцій організації, аналіз розподілу функцій за підрозділами та співробітниками, виявлення функціональних взаємодійміж підрозділами, інформаційних потоків усередині підрозділів та між ними, зовнішніх по відношенню до організації об'єктів та зовнішніх інформаційних впливів, аналіз існуючих засобів автоматизації діяльності організації.
- моделі "AS-IS" ("як є"), що відображає існуючий на момент обстеження стан справ в організації і дозволяє зрозуміти, яким чином ця організація працює, а також виявити вузькі місця і сформулювати пропозиції щодо поліпшення ситуації;
- моделі "TO-BE" ("як має бути"), що відображає уявлення про нові технології роботи організації.
Побудова моделі діяльності організації (об'єкта), що передбачає обробку матеріалів обстеження та побудову двох видів моделей:
p align="justify"> Кожна з моделей повинна включати повну функціональну та інформаційну модель діяльності організації, а також (при необхідності) модель, що описує динаміку поведінки організації. Зауважимо, що побудовані моделі мають самостійне практичне значення, незалежно від того, чи буде на підприємстві розроблятися та впроваджуватись інформаційна система, оскільки з їх допомогою можна навчати співробітників та удосконалювати бізнес-процеси підприємства.
Результатом завершення стадії формування вимог до ПЗ є специфікації ПЗ, функціональні, технічні та інтерфейсні специфікації, для яких підтверджена їхня повнота, перевірюваність та здійсненність.
Стадія проектування включає такі етапи.
Розробка системного проекту ПЗ. На цьому етапі дається відповідь на питання "Що має робити майбутня система?", а саме: визначаються архітектура системи, її функції, зовнішні умовифункціонування, інтерфейси та розподіл функцій між користувачами та системою, вимоги до програмних та інформаційних компонентів, склад виконавців та терміни розробки, план налагодження ПЗ та контроль якості.
Основу системного проекту складають моделі проектованої системи, що будуються на моделі "TO-BE". Результатом розробки системного проекту має бути схвалена та підтверджена специфікація вимог до ПЗ: функціональні, технічні та інтерфейсні специфікації, для яких підтверджена їхня повнота, перевірюваність та здійсненність.
- Розробка детального (технічного) проекту. На цьому етапі здійснюється власне проектування ПЗ, що включає проектування архітектури системи та детальне проектування. Таким чином, дається відповідь на запитання: "Як побудувати систему, щоб вона задовольняла вимоги?"
Результатом детального проектування є розробка верифікованої специфікації ПЗ, що включає:
- формування ієрархії програмних компонентів, міжмодульних інтерфейсів за даними та управління;
- специфікація кожного компонента ПЗ, імені, призначення, припущень, розмірів, послідовності викликів, вхідних та вихідних даних, помилкових виходів, алгоритмівта логічних схем;
- формування фізичної та логічної структур даних до рівня окремих полів;
- розробку плану розподілу обчислювальних ресурсів (часу центральних процесорів, пам'яті та ін.);
- верифікацію повноти, несуперечності, здійсненності та обґрунтованості вимог;
- попередній план комплексування та налагодження, план керівництва для користувачів та приймальних випробувань.
Завершенням стадії детального проектування є наскрізний
Анотація.
Вступ.
1. Життєвий цикл ПЗ
Вступ.
Кроки процесу програмування по Райлі
Вступ.
1.1.1. Постановка задачі.
1.1.2. Проектування рішення.
1.1.3. Кодування алгоритму.
1.1.4. Супровід програми.
1.1.5. Програмна документація
Висновок до п. 1.1
1.2. Визначення ЖЦПО за Леманом.
Вступ.
1.2.1 Визначення системи.
1.2.2. Реалізація.
1.2.3. Обслуговування.
Висновок до п. 1.2.
1.3. Фази та роботи ЖЦПО по Боему
1.3.1. Каскадні моделі.
1.3.2. Економічне обгрунтуваннякаскадної моделі.
1.3.3. Вдосконалення каскадної моделі.
1.3.4. Визначення фаз життєвого циклу.
1.3.5. Основні роботи над проектом
Література
Вступ
Промислове застосування комп'ютерів і зростання попиту на програми поставили актуальні завдання суттєвого підвищення. продуктивності розробки ПЗ, розробки індустріальних методів планування та проектування програм, перенесення організаційно-технічних, техніко-економічних та соціально-психологічних прийомів, закономірностей та методів зі сфери матеріального виробництва у сферу застосування комп'ютерів. Комплексний підхіддо процесів розробки, експлуатації та супроводу ПЗ висунув ряд нагальних проблем, вирішення яких виключить «вузькі місця» у проектуванні програм, зменшить терміни завершення робіт, покращить вибір та адаптацію існуючих програм, і може бути визначить долю систем із вбудованими ЕОМ.
У практиці розробок великих програмних проектів часто немає єдиний підхіддо оцінювання витрат праці, термінів проведення робіт та матеріальних витрат, що стримує підвищення продуктивності розробки ПЗ, а зрештою – ефективне управлінняжиттєвим циклом ПЗ. Оскільки програма будь-якого типу стає виробом (крім, можливо, навчальних, макетних програм), підхід до її виготовлення багато в чому має бути аналогічним підходу до виробництва промислової продукції, і питання проектування програм стають надзвичайно важливими. Ця ідея є основою книги Б.У. Боема «Інженерне проектування програмного забезпечення», яку ми використовували для написання даної курсової роботи. У цій книзі під проектуванням програмного забезпечення розуміється процес створення проекту програмного виробу.
1 Життєвий цикл ПЗ
ВСТУП
ЖЦПО - це безперервний процес, який починається з моменту прийняття рішення про необхідність створення ПЗ і закінчується в момент повного вилучення з експлуатації.
Існує кілька підходів щодо фаз і робіт життєвого циклу програмного забезпечення (ЖЦПО), кроків процесу програмування, каскадна і спіральна моделі. Але вони містять загальні основні компоненти: постановка завдання, проектування рішення, реалізація, обслуговування.
Найбільш відомою і повною, мабуть, є структура ЖЦПО Боему, що включає вісім фаз. Вона і буде представлена надалі докладніше.
Одним з можливих варіантів може бути опис верхнього рівня по Леману, що включає три основні фази і представляє опис ЖЦПО в загальному випадку.
І, для різноманітності – наведемо кроки процесу програмування, представлені Д.Райлі у книзі «Використання мови Модула-2». Це уявлення, на мою думку, є дуже простим і звичним, з нього і почнемо.
1.1 Кроки процесу програмування по Райлі
Процес програмування включає чотири кроки (рис. 1):
постановка завдання, тобто. отримання адекватного ставлення до тому, яку завдання має виконати програма;
проектування рішення вже поставленої задачі (загалом, таке рішення є менш формальним, ніж остаточна програма);
кодування програми, тобто переведення спроектованого рішення у програму, яка може бути виконана на машині;
супровід програми, тобто. процес усунення в програмі неполадок і додавання нових можливостей.
Мал. 1.Чотири кроки програмування.
Програмування починається з того моменту, коли користувач, тобто. той, хто потребує програми для вирішення завдання, викладає проблему системного аналітика.Користувач та системний аналітик спільно визначають постановку завдання. Остання потім передається алгоритмісту, що відповідає за проектування рішення. Рішення (або алгоритм) є послідовністю операцій, виконання яких призводить до вирішення задачі. Оскільки алгоритм часто не пристосований до виконання машиною, його слід перевести в машинну програму. Ця операція виконується кодувальником. За наступні зміни у програмі несе відповідальність супроводжуючий програміст. І системний аналітик, і алгоритміст, і кодувальник, і програміст, що супроводжує – всі вони є програмістами.
У разі великого програмного проекту кількість користувачів, системних аналітиків та алгоритмістів може виявитися значною. Крім того, може виникнути потреба повернутися до попередніх кроків через непередбачені обставини. Все це є додатковим аргументом на користь ретельного проектування програмного забезпечення: результати кожного кроку мають бути повними, точними та зрозумілими.
1.1.1 Постановка задачі
Одним із найважливіших кроків програмування є постановка задачі. Вона виконує функції контракту між користувачем та програмістом (програмістами). Як і юридично погано складений контракт, погана постановка завдання марна. При хорошій постановці завдання як користувач, і програміст ясно і недвозначно представляють завдання, яку потрібно виконати, тобто. у разі враховуються інтереси як користувача, і програміста. Користувач може планувати використання ще нествореного програмного забезпечення, спираючись на знання того, що може. Хороша постановка завдання є основою формування її розв'язання.
Постановка задачі (специфікація програми); по суті означає точний, повний і зрозумілий опис того, що відбувається при виконанні конкретної програми. Користувач зазвичай дивиться на комп'ютер, як на чорну скриньку: для нього не має значення, як працює комп'ютер, а важливо, що може комп'ютер з того, що цікавить користувача. При цьому основна увага фокусується на взаємодії людини із машиною.
Характеристики Гарної Постановки Завдання:
Точність, тобто. виняток будь-якої неоднозначності. Не повинно виникати запитань щодо того, яким буде виведення програми при кожному конкретному введенні.
Повнота, тобто. розгляд усіх варіантів для заданого введення, включаючи помилкове або непередбачене введення, та визначення відповідного висновку.
Ясність, тобто. вона має бути зрозумілою і користувачеві та системному аналітику, оскільки постановка завдання – це єдиний контракт між ними.
Часто вимога точності, повноти та ясності перебувають у протиріччі. Так, багато юридичних документів важко зрозуміти, тому що вони написані формальною мовою, яка дозволяє гранично точно сформулювати ті чи інші положення, виключаючи будь-які незначні різночитання. Наприклад, деякі питання в екзаменаційних квитках іноді сформульовані настільки точно, що студент витрачає більше часу на те, щоб зрозуміти питання, ніж на те, щоб на нього відповісти. Більше того, студент взагалі може не вловити основний зміст питання через велику кількість деталей. Найкраща постановка завдання та, коли він досягається баланс всіх трьох вимог.
Стандартна форма постановки задачі.
Розглянемо таку постановку завдання: «Ввести три числа та вивести числа у порядку».
Така постановка не задовольняє наведеним вище вимогам: вона не є точною, ні повною, ні зрозумілою. Справді, чи мають числа вводитися по одному на рядку чи всі числа на одному рядку? Чи означає вираз «у порядку» упорядкування від більшого до меншого, від меншого до більшого або той самий порядок, у якому вони були введені.
Очевидно, що подібна постановка не відповідає на багато запитань. Якщо ж врахувати відповіді на всі питання, то постановка завдання стане багатослівною та складною для сприйняття. Тому Д. Райлі пропонує для постановки завдання користуватися стандартною формою, яка забезпечує максимальну точність, повноту, ясність і включає:
найменування задачі (схематичне визначення);
Загальний опис (короткий викладзавдання);
помилки (явно перераховані незвичайні варіанти введення, щоб показати користувачам та програмістам ті дії, які зробить машина у подібних ситуаціях);
приклад (добрий приклад може передати сутність завдання, і навіть проілюструвати різні випадки).
приклад. Постановка завдання у стандартній формі.
НАЗВА
Сортування трьох цілих чисел.
ОПИС
Введення та виведення трьох цілих чисел, відсортованих від меншого числа до більшого.
Вводяться три цілих числа по одному числу на рядку. При цьому цілим числом є одна або кілька послідовних десяткових цифр, яким може передувати знак плюс + або знак мінус -.
Виводяться три введені цілих числа, причому всі три виводяться на одному рядку. Суміжні числа поділяються пробілом. Числа виводяться від меншого до більшого, зліва направо.
1) Якщо введено менше трьох чисел, програма чекає на додаткове введення.
ЖЦ ПЗ – період часу, який починається з моменту прийняття рішення про необхідність створення програмного продукту та закінчується в момент його повного вилучення з експлуатації.
Процеси ЖЦ ПЗ:
Основні,
Допоміжні,
Організаційні.
Основні:
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. Ітераційна модель ЖЦ ПЗ
Життєвий цикл програмного забезпечення
Життєвий цикл програмного забезпечення - період часу, який починається з прийняття рішення про необхідність створення програмного продукту і закінчується у його повного вилучення з експлуатації. (Стандарт IEEE Std 610.12)
Необхідність визначення етапів життєвого циклу (ЖЦ) ПЗ обумовлена прагненням розробників до підвищення якості ПЗ за рахунок оптимального управління розробкою та використання різноманітних механізмів контролю якості на кожному етапі, починаючи від постановки завдання та закінчуючи авторським супроводом ПЗ. Найбільш загальним уявленням життєвого циклу ПЗ є модель у вигляді базових етапів - процесів, до яких належать:
Системний аналіз та обґрунтування вимог до ПЗ;
Попереднє (ескізне) та детальне (технічне) проектування ПЗ;
Розробка програмних компонентів, їх комплексування та налагодження ПЗ в цілому;
Випробування, дослідна експлуатація та тиражування ПЗ;
Регулярна експлуатація ПЗ, підтримка експлуатації та аналіз результатів;
Супровід ПЗ, його модифікація та вдосконалення, створення нових версій.
Дана модель є загальноприйнятою і відповідає як вітчизняним нормативним документамяк у галузі розробки програмного забезпечення, так і зарубіжним. З погляду забезпечення технологічної безпеки доцільно розглянути докладніше особливості подання етапів ЖЦ у зарубіжних моделях, оскільки саме зарубіжні програмні засоби є найімовірнішим носієм програмних дефектів диверсійного типу.
Стандарти життєвого циклу ПЗ
ГОСТ 34.601-90
ISO/IEC 12207:1995 (російський аналог - ГОСТ Р ІСО/МЕК 12207-99)
Графічне уявлення моделей ЖЦ дозволяє наочно виділити їх особливості та деякі властивості процесів.
Спочатку була створена каскадна модель ЖЦ, у якій великі етапи починалися один за одним із використанням результатів попередніх робіт. Вона передбачає послідовне виконання всіх етапів проекту у строго фіксованому порядку. Перехід на наступний етап означає повне завершення робіт на попередньому етапі. Вимоги, визначені на стадії формування вимог, суворо документуються як технічного завдання і фіксуються весь час розробки проекту. Кожна стадія завершується випуском повного комплекту документації, достатньої для того, щоб технологія могла бути продовжена іншою командою розробників. Неточність будь-якої вимоги або некоректна його інтерпретація в результаті призводить до того, що доводиться «відкочуватися» до ранньої фази проекту і необхідна переробка не просто вибиває проектну команду з графіка, але часто призводить до якісного зростання витрат і, не виключено, до припинення проекту у тій формі, в якій він спочатку замислювався. Основна помилка авторів водоспадної моделі полягає в припущеннях, що проект проходить через весь процес один раз, спроектована архітектура хороша і проста у використанні, проект здійснення розумний, а помилки в реалізації легко усуваються в міру тестування. Ця модель виходить з того, що всі помилки будуть зосереджені в реалізації, тому їх усунення відбувається рівномірно під час тестування компонентів і системи. Таким чином, водоспадна модель для великих проектів є мало реалістичною і може бути ефективно використана тільки для створення невеликих систем.
Найбільш специфічною є спіралеподібна модель ЖЦ. У цій моделі увага концентрується на ітераційному процесі початкових етапівпроектування. На цих етапах послідовно створюються концепції, специфікації вимог, попередній і детальний проект. На кожному витку уточнюється зміст робіт і концентрується образ створюваного ПЗ, оцінюється якість отриманих результатів та плануються роботи наступної ітерації. На кожній ітерації оцінюються:
Ризик перевищення термінів та вартості проекту;
Необхідність виконання ще однієї ітерації;
Ступінь повноти та точності розуміння вимог до системи;
Доцільність припинення проекту.
Стандартизація ЖЦ ПЗ проводиться за трьома напрямками. Перший напрямок організується та стимулюється Міжнародною організацією зі стандартизації (ISO – International Standard Organization) та Міжнародною комісією з електротехніки (IEC – International Electro-technical Commission). На цьому рівні здійснюється стандартизація найзагальніших технологічних процесів, що мають значення для міжнародної кооперації. Другий напрямок активно розвивається в США Інститутом інженерів електротехніки та радіоелектроніки (IEEE – Institute of Electrotechnical and Electronics Engineers) спільно з Американським національним інститутом стандартизації (American National Standards Institute-ANSI). Стандарти ISO/IEC та ANSI/IEEE в основному мають рекомендаційний характер. Третій напрямок стимулюється Міністерством оборони США (Department of Defense-DOD). Стандарти DOD мають обов'язковий характер для фірм, які працюють на замовлення Міністерства оборони США.
Для проектування програмного забезпечення складної системи, особливо системи реального часу, доцільно використовувати загальносистемну модель ЖЦ, засновану на об'єднанні всіх відомих робіту межах розглянутих базових процесів. Ця модель призначена для використання при плануванні, складанні робочих графіків, управлінні різними програмними проектами.
Сукупність етапів даної моделі ЖЦ доцільно ділити на дві частини, що істотно відрізняються особливостями процесів, техніко-економічними характеристиками та факторами, що впливають на них.
У першій частині ЖЦ проводиться системний аналіз, проектування, розробка, тестування та випробування ПЗ. Номенклатура робіт, їх трудомісткість, тривалість та інші показники цих етапах істотно залежить від об'єкта і середовища розробки. Вивчення подібних залежностей для різних класів ПЗ дозволяє прогнозувати склад та основні характеристики графіків робіт для нових версій ПЗ.
Друга частина ЖЦ, що відображає підтримку експлуатації та супроводу ПЗ, відносно слабо пов'язана з характеристиками об'єкта та середовища розробки. Номенклатура робіт цих етапах більш стабільна, які трудомісткість і тривалість можуть істотно змінюватися, і залежить від масовості застосування ПО. Для будь-якої моделі ЖЦ забезпечення високої якостіпрограмних комплексів можливе лише при використанні регламентованого технологічного процесукожному з цих етапів. Такий процес підтримується засобами автоматизації розробки, які доцільно вибирати з наявних чи створювати з урахуванням об'єкта розробки та адекватного йому переліку робіт.
