Главная

Категории:

ДомЗдоровьеЗоологияИнформатикаИскусствоИскусствоКомпьютерыКулинарияМаркетингМатематикаМедицинаМенеджментОбразованиеПедагогикаПитомцыПрограммированиеПроизводствоПромышленностьПсихологияРазноеРелигияСоциологияСпортСтатистикаТранспортФизикаФилософияФинансыХимияХоббиЭкологияЭкономикаЭлектроника






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


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

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

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

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

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

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

· налаштуванням призначених для користувача інтерфейсів (генерацією екранних форм і звітів);

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

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

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

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

 

Лекція 15

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

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

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

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

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

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

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

 

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

На цій фазі виконуються наступні роботи:

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

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

· проводиться опис інформаційних потреб;

Примітка

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

· обмежується масштаб проекту;

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

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

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

 

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

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

Примітка

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

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

Примітка

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

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

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

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

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

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

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

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

Примітка

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

 

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

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

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

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

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

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

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

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

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

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

 

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

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

 

Примітка

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

 

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

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

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

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

Лекція 16

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

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

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

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

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

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

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

 

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

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

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

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

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

Примітка

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

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

· методика Oracle CDM (Custom Development Method) no розробці прикладних інформаційних систем під замовлення;

· міжнародний стандарт ISO/IEC 12207:1995- 08-01 на організацію життєвого циклу продуктів програмного забезпечення;

· вітчизняний комплекс стандартів ГОСТ 34.

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

 

Методика Oracle CDM

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

Основу CASE -технологии і інструментального середовища фірми ORACLE складають:

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

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

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

· наявність централізованої бази даних, репозитария, для зберігання специфікацій проекту прикладної системи на усіх етапах її розробки. Такий репозитарий є базою даних спеціальної структури, СУБД ORACLE, що працює під управлінням;

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

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

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

 

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

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

· стратегія (визначення вимог);

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

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

· реалізація (написання і тестування застосувань);

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

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

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

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

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

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

Примітка

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

Методика Oracle CDM виділяє наступні процеси, що протікають на протяже-нии життєвого циклу інформаційної системи;

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

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

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

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

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

· конвертація даних;

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

· тестування;

· навчання;

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

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

Процеси складаються з послідовностей завдань, завдання різних процесів взаи-мосвязаны за допомогою явних посилань.

 



Последнее изменение этой страницы: 2016-06-09

headinsider.info. Все права принадлежат авторам данных материалов.