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

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

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

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

Відповідно до міжнародного стандарту ISO / IEC 12207 «інформаційні технології - Процеси життєвого циклу ПО» процес розробки ПО містить наступні етапи життєвого циклу ПО:

1) аналіз системних вимогі області застосування;

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

3) аналіз вимог до ПЗ (специфікації, зовнішні інтерфейси,);

4) проектування архітектури ПЗ;

5) детальне проектування кожної одиниці ПО;

6) кодування ПО (програмування)

7) тестування одиниць ПО;

8) інтеграція (об'єднання ПО) і тестування сукупності одиниць ПО;

9) кваліфікаційні випробування ПО (комплексне тестування);

10) інтеграція системи одиниці структури ПО повинні бути об'єднані з одиницями апаратних засобів;

11) кваліфікаційні випробування системи;

12) установка ПО.

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

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

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

Спіральна модель життєвого циклу ПО. «Важкі і полегшені» (швидкі) технології розробки ПЗ

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

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

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

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

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

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

Існує напрямок «Швидких технологій» розробки ПО (Agile Software Development), що дає ідеологічне обгрунтування поглядів, пов'язаним з спіральної моделлю ЖЦ. Ці технології базуються на чотирьох ідеях:

Інтерактивна взаємодія індивідуумів важливіше формальних процедур і інструментів,

Працююче ПО важливіше наявності документації на нього,

Співпраця з замовником важливіше формальних договорів,

Швидке реагування на зовнішні зміни важливіше строгого дотримання наміченим планам.

Мал. 8.2 - Схема спірального ЖЦ ПО

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

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

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

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

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

«Важкі і полегшені» технології розробки ПЗ . Розробники багатьох видів ПО вважають каскадну модель життєвого циклу занадто регламентованої, занадто документованої і важкої і тому нераціональною. Існує напрямок «Швидких технологій» (легких технологій) розробки ПО (Agile Software Development), що дає ідеологічне обгрунтування цим поглядам. Ці технології базуються на чотирьох ідеях:

1. інтерактивна взаємодія індивідуумів важливіше формальних процедур і інструментів,

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

3. співпраця з замовником важливіше формальних договорів з ним,

4. швидке реагування на зовнішні зміни важливіше строгого дотримання наміченим планам.

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

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

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

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

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

У великих колективах розробників проблема управління - виходить на передній план.

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

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

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

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

Презентацію до даної лекції Ви можете завантажити.

Мета лекції:

Отримати уявлення про призначення та основні принципи гнучкої розробки програмного забезпечення.

Вступ

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

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

Принципи і значення гнучкої розробки

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

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

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

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

Для створення високопродуктивних команд в гнучких методологіях крім ефективної команди і хороших комунікацій необхідний досконалий програмний інструментарій.

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

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

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

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

1. Вищим пріоритетом вважати задоволення побажань замовника за допомогою поставки корисного програмного забезпечення в стислі терміни з подальшим безперервним оновленням. Гнучкі методики мають на увазі швидку поставку початковій версії і часті оновлення. Метою команди є поставка працездатною версії з протягом декількох тижнів з моменту початку проекту. Надалі програмні системиз поступово розширюється функціональністю повинні поставлятися кожні кілька тижнів. Замовник може почати промислову експлуатацію системи, якщо вважатиме, вона досить функціональна. Також замовник може просто ознайомитися з поточною версією програмного забезпечення, надати свій відгук із зауваженнями.
2. Чи не ігнорувати зміну вимог, нехай навіть на пізніх етапах розробки. Гнучкі процеси дозволяють враховувати зміни для забезпечення конкурентних переваг замовника. Команди, що використовують гнучкі методики, прагнуть зробити структуру програми якісної, з мінімальним впливом змін на систему в цілому.
3. Постачати нові працюючі версії ПЗ часто, з інтервалом від одного тижня до двох місяців, віддаючи перевагу меншим термінами. При цьому мається на меті поставити програму, що задовольняє потребам користувача, з мінімумом супровідної документації.
4. Замовники і розробники повинні працювати спільно на протязі всього проекту. Вважається, що для успішного проекту замовники, розробники і всі зацікавлені особи повинні спілкуватися часто і по багато для цілеспрямованого вдосконалення програмного продукту.
5. Проекти повинні втілювати в життя цілеспрямовані люди. Створюйте команді проекту нормальні умови роботи, забезпечте необхідну підтримку і вірте, що члени команди доведуть справу до кінця.
6. Найефективніший і продуктивний метод передачі інформації команді розробників і обміну думками всередині неї - розмова віч-на-віч. У гнучких проектах основний спосіб комунікації - просте людське спілкування. Письмові документи створюються і оновлюються поступово в міру розробки ПО і тільки в разі потреби.
7. Працююча програма - основний показник прогресу в проекті. Про наближення гнучкого проекту до завершення судять по тому, наскільки наявна в даний момент програма відповідає вимогам замовника.
8. Гнучкі процеси сприяють довгостроковій розробці. Замовники, розробники і користувачі повинні бути в змозі підтримувати незмінний темп як завгодно довго.
9. Невпинне увагу до технічної досконалості і якісному проектування підвищує віддачу від гнучких технологій. Члени гнучкою команди прагнуть створювати якісний код, регулярно проводячи рефакторинг.
10. Простота - мистецтво досягати більшого, роблячи менше. Члени команди вирішують поточні завдання максимально просто і якісно. Якщо в майбутньому виникне якась проблема, то в низькоякісний продукт є можливість внести зміни без великих витрат.
11. самі кращі архітектури, Вимоги та проекти видають самоорганізуються команди. У гнучких командах завдання доручаються не окремим членам, а команді в цілому. Команда сама вирішує, як найкраще реалізувати вимоги замовника. Члени команди спільно працюють над усіма аспектами проекту. Кожному учаснику дозволено вносити свій вклад в загальну справу. Немає такого члена команди, який одноосібно відповідав би за архітектуру, вимоги або тести.
12. Команда повинна регулярно замислюватися над тим, як стати ще більш ефективною, а потім відповідно коригувати та підлаштовувати свою поведінку. Гнучка команда постійно коригує свою організацію, правила, угоди і взаємини.

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

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

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

Базовими принципами структурного підходу є:

o принцип " розділяй і володарюй";

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

Основними з цих принципів є:

o абстрагування - виділення істотних аспектів системи;

o несуперечності - обґрунтованість і узгодженість елементів системи;

o структурування даних - дані повинні бути структуро-вані і ієрархічно організовані.

Методичні основи технологій створення програмного забезпечення

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

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

o труднощів проектованої системи;

o необхідної повноти її опису;

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

o часу, відведеного на проектування.

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

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

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

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

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

принцип "розділяй і володарюй" (див. підрозділ 2.1.1);

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

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

принцип абстрагування - виділення істотних аспектів системи і відволікання від несуттєвих;

принцип несуперечності - обгрунтованість і узгодженість елементів системи;

принцип структурування даних - дані повинні бути структуровані і ієрархічно організовані.

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

DFD (Data Flow Diagrams) - діаграми потоків даних;

SADT (Structured Analysis and Design Technique - метод структурного аналізу і проектування,) - моделі і відповідні функціональні діаграми;

ERD (Entity-Relationship Diagrams) - діаграми "сутність-зв'язок".

Діаграми потоків даних і діаграми "сутність-зв'язок" - найбільш часто використовувані в CASE-засобах види моделей.

Конкретний вид перерахованих діаграм і інтерпретація їх конструкцій залежать від стадії ЖЦ ПО.

На стадії формування вимог до ПЗ SADT-моделі і DFD використовуються для побудови моделі "AS-IS" і моделі "ТО-ВЕ", відображаючи, таким чином, існуючу і пропоновану структуру бізнес-процесів організації і взаємодія між ними (використання SADT-моделей , як правило, обмежується тільки даною стадією, оскільки вони спочатку не призначалися для проектування ПО). За допомогою ERD виконується опис використовуваних в організації даних на концептуальному рівні, що не залежному від засобів реалізації бази даних (СКБД).

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

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

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

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

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

1. Принцип «розділяй і володарюй»;

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

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

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

2. Принцип несуперечності, обгрунтованість і узгодженість елементів системи.

3. Принцип структурування даних- даніповинні бути структуровані і ієрархічно організовані.

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

· DFD (Data Flow Diagrams) - діаграми потоків даних;

· SADT (Structured Analysis and Design Technique - методологія структурного аналізу і проектування) - моделі і відповідні функціональні діаграми: нотації IDEF0 (функціональне моделювання систем), IDEF1х (концептуальне моделювання баз даних), IDEF3х (побудова систем оцінки якості роботи об'єкта; графічне опис потоку процесів, взаємодії процесів і об'єктів, які змінюються цими процесами);

· ERD (Entity - Relationship Diagrams) - діаграми «сутність-зв'язок».

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

1. Діаграми, що ілюструють функції, які система повинна виконувати, і зв'язку між цими функціями - DFD або SADT (IDEF0).

2. Діаграми, що моделюють дані і їх відносини (ERD).

Конкретний вид перерахованих діаграм і інтерпретація їх конструкцій залежать від стадії ЖЦ ПО.

На стадії формування вимог до ПЗ SADT-моделі і DFD використовуються для побудови моделі "AS-IS" і моделі "TO-BE", відображаючи таким чином існуючу і пропоновану структуру бізнес-процесів організації і взаємодія між ними (використання SADT-моделей, як правило, обмежується тільки даною стадією, оскільки вони спочатку не призначалися для проектування ПО). За допомогою ERD виконується опис використовуваних в організації даних на концептуальному рівні, не залежно від засобів реалізації бази даних (СКБД).