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

Размещено на http: //www. allbest. ru/

1. Життєвий цикл програмного забезпечення

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

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

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

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

Найбільшого поширення набули дві моделі: каскадна (водоспадна), створена в 1970-1985 pp., та спіральна, створена в 1986-1990 рр.

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

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

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

Переваги застосування каскадної моделі:

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

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

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

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

Рис. 1 Каскадна модель життєвого циклу 1С

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

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

Для подолання перерахованих проблем у середині 1980-х років була запропонована спіральна модель ЖЦ ПЗ (рис.).

Рис. 2 Модель спірального процесу розроблення 1С

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

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

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

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

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

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

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

Інженерія вимог

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

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

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

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

4) побудову двох видів моделей:

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

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

o відмовостійкість;

o кількість клієнтів, що одночасно мають доступ до системи;

o вимоги безпеки;

o час очікування відповіді на звернення до системи;

o виконавські властивості системи (обмеження щодо ресурсів пам'яті, швидкість реакції на звернення до системи тощо).

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

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

Автоматизація проектування ІС

На етапі проектування ІС побажання замовників перетворюються у проектні рішення у формі певної системи програмування.

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

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

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

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

o концепцій і теоретичних основ (наприклад, структурний або об'єктно орієнтований підхід);

o нотацій, що використовуються для побудови моделей статичної структури і динаміки поведінки ІС (діаграми потоків даних і діаграми "сутність - зв'язок" для структурного підходу, діаграми варіантів використання, діаграми класів в об'єктно орієнтованому підході);

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

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

Методи реалізуються через конкретні технології і методики, стандарти й інструментальні засоби, що забезпечують виконання процесів ЖЦ ПЗ. Розрізняють методи оригінального проектування, коли створюється оригінальна ІС, та типового проектування, коли ІС компонується з готових типових рішень. Комбінація різних методів проектування зумовлює характер технології проектування ІС. Найвідоміші технології проектування ІС - це канонічна (ручна технологія індивідуального проектування) та індустріальна, що у свою чергу поділяється на автоматизовану (з використанням САSЕ-тех-нологій) і типову (модельно орієнтовану або параметрично орієнтовану).

Більшість існуючих САвЕ-засобів засновано на методах структурного або об'єктно орієнтованого аналізу і проектування, що використовує специфікації у вигляді діаграм або текс-

Перехід від моделі ияк є" до моделі "як має бути" може відбуватися двома способами:

1) удосконалюванням діючих технологій на основі оцінки їхньої ефективності;

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

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

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

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

Моделі ІС уточнюються і деталізуються до необхідного рівня. На кожній стадії проектування може виконуватися кілька процесів, що визначаються у стандарті ШО/ІЕС 12207. Кожна програма - це певний перетворювач, поведінку і властивості якого визначають у процесі створення системи так, щоб вирішити певну проблему.

Вимоги до програмної системи - це властивості, які слід мати системі для адекватного виконання своїх функцій.

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

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

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

o оператори, що обслуговують функціонування системи;

o розробники системи.

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

Джерела відомостей про вимоги:

o мета та завдання системи, як їх формулює замовник;

o діюча система або колектив, що виконує її функції;

o загальні знання щодо проблемної галузі замовника;

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

Методи збирання вимог:

o інтерв'ю з носіями інтересів замовника та операторами;

o спостереження за роботою діючої системи;

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

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

1) такі, що відображають можливості, які повинна забезпечити система, - функціональні;

2) такі, що відображають обмеження, пов'язані з функціонуванням системи, - нефункціональні.

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

o вимоги конфіденційності;

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

Рис. 3. Контекст технологічної операції проектування

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

o відповідність стандартові ІБО/ІЕС 12207;

o гарантоване досягнення цілей розробки БС у межах бюджету з дотриманням якості й установленого часу;

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

o мінімальний час одержання працездатного ПЗ ІС;

o незалежність проектних рішень від засобів реалізації 1С (СУБД, операційних систем, мов і систем програмування);

o підтримка САSЕ-засобів, що забезпечують автоматизацію процесів, виконуваних на всіх стадіях ЖЦ.

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

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

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

в) вимоги до конфігурації робочих місць розробників, включаючи настроювання операційної системи та САSЕ-за-собів;

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

Стандарт оформлення проектної документації установлює:

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

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

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

г) вимоги до засобів підготовки документації;

д) вимоги до настроювання САSЕ-засобів для забезпечення підготовки документації відповідно до встановлених правил.

Стандарт інтерфейсу користувача із системою регламентує:

а) правила оформлення екранних елементів і елементів управління;

б) правила використання клавіатури і миші;

в) правила оформлення текстів допомоги;

г) перелік стандартних повідомлень;

д) правила обробки реакції користувача.

Размещено на Аllbеst.ru