Головна

ПРИМІТКА

  1.  Примітка
  2.  Примітка
  3.  Примітка
  4.  Примітка
  5.  Примітка
  6.  Примітка
  7.  Примітка

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

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

забезпечувати мінімальний час отримання працездатною системи;

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

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

Методологія RAD

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

Основні особливості методології RAD

Методологія створення інформаційних систем, заснована на використанні коштів швидкої розробки додатків, отримала останнім часом широкого поширення і придбала назву методології швидкої розробки додатків (Rapid Application Development, RAD). Дана методологія охоплює всі етапи життєвого циклу сучасних інформаційних систем.

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

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

невеликій команді програмістів (зазвичай від 2 до 10 осіб);

ретельно опрацьований виробничому графіку робіт, розрахованому на порівняно короткий термін розробки (від 2 до 6 міс.);

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

Основні принципи методології RAD можна звести до наступних:

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

повне завершення робіт на кожному з етапів життєвого циклу не обов'язково;

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

застосовуються CASE-засобу та засоби швидкої розробки додатків;

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

використовуються прототипи, що дозволяють повніше з'ясувати і реалізувати потреби кінцевого користувача;

тестування і розвиток проекту здійснюються одночасно з розробкою;

розробка ведеться нечисленної і добре керованою командою професіоналів;

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

Об'єктно-орієнтований підхід

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

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

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

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

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

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

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

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

візуальне програмування

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

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

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

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

спеціалізовані засоби розробки орієнтовані тільки на створення додатків баз даних. Причому, як правило, вони прив'язані до цілком певних систем управління базами даних. Як приклад таких систем можна привести системи Power Builder фірми Sybase (природно, призначену для роботи з СУБД Sybase Anywhere Server) і Visual FoxPro фірми Microsoft.

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

подієве програмування

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

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

Фази життєвого циклу в рамках методології RAD

При використанні методології швидкої розробки додатків життєвий цикл інформаційної системи складається з чотирьох фаз:

аналізу і планування вимог;

проектування;

побудови;

впровадження.

Розглянемо кожну з них більш детально.

Фаза аналізу і планування вимог

На фазі аналізу і планування вимог визначаються:

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

найбільш пріоритетні функції, що вимагають розробки в першу чергу; Q інформаційні потреби;

масштаб проекту;

тимчасові рамки для кожної з наступних фаз;

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

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

фаза проектування

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

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

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

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

На цій же фазі відбувається визначення набору необхідної документації.

Результатами цієї фази є:

загальна інформаційна модель системи;

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

точно визначені за допомогою CASE-засобу інтерфейси між автономно розробляються підсистемами;

побудовані прототипи екранів, діалогових вікон і звітів.

фаза побудови

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

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

Завершується фізичне проектування системи, а саме:

визначається необхідність розподілу даних;

проводиться аналіз використання даних;

проводиться фізичне проектування бази даних;

визначаються вимоги до апаратних ресурсів;

визначаються способи підвищення продуктивності;

завершується розробка документації проекту.

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

фаза впровадження

Фаза впровадження в основному зводиться до навчання користувачів розробленої інформаційної системи.

Так як фаза побудови досить нетривала, планування і підготовка до впровадження повинні починатися заздалегідь, ще на етапі проектування системи.

Обмеження методології RAD

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

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

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

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

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

Профілі відкритих інформаційних систем

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

Поняття профілю інформаційної системи

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

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

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

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

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

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

Зазвичай розглядають дві групи профілів, що регламентують:

архітектуру і структуру інформаційної системи;

процеси проектування, розробки, застосування, супроводу і розвитку системи.

Залежно від області застосування профілі можуть мати різні категорії і, відповідно, різні статуси затвердження:

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

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

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

Принципи формування профілю інформаційної системи

Профілі інформаційних систем покликані вирішити такі завдання:

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

підвищення якості компонентів інформаційних систем;

забезпечення розширюваності та масштабованості розроблюваних систем;

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

забезпечення переносимості прикладного програмного забезпечення.

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

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

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

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

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

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

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

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

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

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

стандартизовані описи функцій, які виконуються даною системою;

функції взаємодії системи із зовнішнім для неї середовищем;

стандартизовані інтерфейси між додатками і середовищем інформаційної системи;

профілі окремих функціональних компонентів, що входять в систему. Для ефективного використання конкретного профілю необхідно:

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

ідентифікувати стандарти і нормативні документи, варіанти їх використання та параметри, які необхідно включити в профіль;

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

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

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

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

Структура профілів інформаційних систем

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

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

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

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

визначення цілей використання профілю;

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

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

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

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

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

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

прикладного програмного забезпечення;

середовища інформаційної системи;

захисту інформації в інформаційній системі;

інструментальних засобів, вбудованих в інформаційну систему.

Профіль прикладного програмного забезпечення

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

Профіль середовища інформаційної системи

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

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

графічного призначеного для користувача інтерфейсу;

реляційних або об'єктно-орієнтованих СУБД (наприклад, стандарту мови SQL-92 і специфікації доступу до різних баз даних);

операційних систем з урахуванням мережевих функцій, які виконуються на рівні операційної системи;

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

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

Профіль захисту інформації

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

функції, що реалізовуються операційною системою;

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

функції управління даними, реалізовані СУБД;

функції захисту програмних засобів, включаючи засоби захисту від вірусів;

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

функції адміністрування засобів безпеки.

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

Профіль інструментальних засобів

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

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

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

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

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

перенастроюванням додатків в зв'язку зі змінами прикладних функцій інформаційної системи;

настроюванням користувальницьких інтерфейсів (екранних форм і звітів);

веденням баз даних системи;

відновленням працездатності системи після збоїв і аварій.

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

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

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

Методологія і технологія розробки інформаційних систем

Стандарти і методики

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

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

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

на продукти і послуги;

на процеси та технології;

на форми колективної діяльності, або управлінські стандарти.

види стандартів

Існуючі на сьогоднішній день стандарти можна умовно розділити на кілька груп.

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

За стверджує організації. Тут можна виділити офіційні міжнародні, офіційні національні або відомчі національні стандарти (наприклад, ГОСТ, ANSI, IDEFO / 1), стандарти міжнародних консорціумів і комітетів по стандартизації (наприклад, OMG), стандарти де-факто - офіційно ніким не затверджені, але фактично діючі (наприклад, стандартом де-факто довгий час були мову взаємодії з базами даних SQL і мова програмування с), фірмові стандарти (наприклад, Microsoft ODBC).

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

Коротенько розглянемо методику CDM (Custom Development Method) фірми Oracle по розробці прикладних ІС під замовлення і Міжнародний стандарт ISO / IEC 12207: 1995-08-01 01 на організацію життєвого циклу продуктів програмного забезпечення.

Методика CDM фірми Oracle

Одним з уже сформованих напрямків діяльності фірми Oracle стали розробка методологічних основ і виробництво інструментальних засобів для автоматизації процесів розробки складних прикладних систем, орієнтованих на інтенсивне використання баз даних. Методика CDM є розвитком давно розробленої методики CASE-Method фірми Oracle, яка застосовується в CASE-засобі Oracle CASE (в нових версіях - Designer / 2000).

Перелічимо основні складові CASE-технології та інструментального середовища фірми Oracle.

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

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

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

Наявність централізованої бази даних - сховища. Репозитарій призначений для зберігання специфікацій проекту прикладної системи на всіх етапах її розробки. Він являє собою базу даних спеціальної структури, яка працює під управлінням СУБД Oracle.

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

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

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

Загальна структура

Життєвий цикл формується з певних етапів (фаз) проекту і процесів, кожен з яких виконується протягом декількох етапів.

Методика CDM визначає наступні фази ЖЦ ІС:

стратегію;

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

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

реалізацію (написання та тестування додатків);

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

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

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

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

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

функціональні, що описують особливості вирішуваних завдань.

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

На етапі реалізації створюються програми, що відповідають всім вимогам проектних специфікацій.

Методика СDМ виділяє наступні процеси, що протікають протягом ЖЦ ІС:

визначення виробничих вимог;

дослідження існуючих систем;

визначення технічної архітектури;

проектування і побудова бази даних;

проектування і реалізацію модулів;

конвертування даних;

документування;

тестування;

навчання;

перехід до нової системи;

підтримку і супровід.

Особливості методики СDМ

Відзначимо основні особливості методики CDM, що визначають область її застосування і властиві їй обмеження.

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

класична модель передбачає всі етапи;

швидка розробка орієнтована на використання інструментів моделювання і програмування Oracle;

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

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

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

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

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

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

Методика CDM є цілком конкретний матеріал, деталізований до рівня заготовок проектних документів, розрахованих на пряме використання в проектах інформаційних систем з опорою на інструментальні засоби і СУБД фірми Oracle.

Міжнародний стандарт ISO / IEC 12207: 1995-08-01

Перша редакція ISO Г2207 була підготовлена ??в 1995 р підкомітетом SC7 (Проектування програмного забезпечення) об'єднаного технічного комітету JTC1 (Інформаційні технології) ISO / IEC.

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

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

Згідно ISO 12207, система - це об'єднання одного або декількох процесів, апаратних засобів, програмного забезпечення, обладнання і людей для задоволення певних потреб чи цілям.

Загальна структура

У стандарті ISO 12207 не передбачено будь-яких етапів (фаз або стадій) ЖЦ ІС. Даний стандарт визначає лише ряд процесів, причому в порівнянні з CDM стандарт ISO 12207 складається з набагато більших узагальнених процесів (придбання, постачання, розробка і т. П.). Трохи перебільшуючи, можна сказати, що один процес ISO 12207 можна порівняти з усіма процесами CDM разом узятими.

Згідно ISO 12207, кожен процес підрозділяється на ряд дій, а кожна дія - на ряд завдань.

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

Основні і допоміжні процеси ЖЦ

У стандарті ISO 12207 описані п'ять основних процесів ЖЦ програмного забезпечення.

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

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

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

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

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

Крім основних, стандарт ISO 12207 обумовлює 8 допоміжних процесів, які є невід'ємною частиною всього ЖЦ програмного вироби і забезпечують належну якість проекту ПО. До допоміжних процесів відносяться:

рішення проблем;

документування;

управління конфігурацією;

забезпечення якості;

верифікація;

атестація;

спільна оцінка;

аудит.

У стандарті ISO 12207 також визначаються чотири організаційних процесу:

управління;

створення інфраструктури;

удосконалення;

навчання.

 Використання загальноприйнятих, стандартних нотацій і угод |  ПРИМІТКА


 інформаційний процес |  Тема 2 Життєвий цикл інформаційних систем. |  ПРИМІТКА |  ПРИМІТКА |  Тема 4. Загальні принципи проектування АІС |  ПРИМІТКА |  Тема №7 |  Тема №8. Рівні подання інформаційних систем |  Файл-серверні додатки |  Призначення. |

© 2016-2022  um.co.ua - учбові матеріали та реферати