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